![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
Open棟梁Project - マイクロソフト系技術情報 Wiki
ソースコード・ドキュメンテーション・ツールの利用事例を紹介します。
某案件では、
両面を採用しました。
内作し担当者のスキルが把握できていれば、完全リバースでもリスクは低いと思いますが、
国内/国外パートナー に発注を前提とする場合は、リスクを考慮した場合、
製造する対象物(ファイル、クラス、メソッド、その概要、等)は明確にした方が良いと思います。
そうしないと、
ので。
某案件では、フォワード（モジュールレベルの詳細設計書作成）の際にやり過ぎて、
ここまでやる場合は、イベントフロー、アクティビティ図（≒フローチャート）から
ソースコードを自動生成する位は考えないと、生産性が上がらないと思います。
一度 Word、Exel で設計するプロジェクトに採用しましたが、
修正や設計に手間がかかる割には、製造・テスト工程の生産性は上がらず、
むしろ、設計書の修正が追いつかずプロジェクトの完成度が下がりました。
「ソースコードを自動生成する位は考えないと、生産性が上がらないと思います。」
上記の見解について、
を考える必要がある。
一部業務アプリケーション開発の用途でも効果的な活用方法は発見されている。
従って、
上記の様な自然言語で表し難い仕様を説明する
表記方法については、補足説明書として付属させても良い。
比較的多くの案件で採用されている。
（業務的詳細設計書と方式設計書をコーディング工程で結合する）
モジュールレベルの詳細設計書はリバース生成させる。
Doxygenを採用（A Hot Document等で代替も可能）し、
メソッド内コメントのコメント規則を整備して
設計書をリバース生成させる方式を導入したが定着せず。
理由は以下
A Hot Documentも納品・保守ドキュメント生成と割り切っている。
http://www.hotdocument.net/
製品など、ドキュメントを納品ではなく自分のために使用する場合は、
リバース生成方式の採用を本格的に検討しても良いかもしれない。
必要不可欠というものではなく、作業形骸化を起こすため問題が多い。
前述のイベントフロー、アクティビティ図で説明したとおり、
修正や設計に手間がかかる割には、製造・テスト工程の生産性は上がらず、
むしろ、設計書の修正が追いつかずプロジェクトの完成度が下がりました。
という状態に陥ることになる。
これでも、クラス・メソッド仕様書を
というケースが後を絶たないのは、
商習慣（見積条件）によるところが大きいと考える。
また、この商習慣（見積条件）は、
リバースの事例での記述とは別の理由で
リバース生成が採用されない理由の一つにもなっている。
だいたいNG。リンク先を参照ください。
ご参考。リンク先を参照ください。
