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