はじめに
プロジェクトで作成する設計ドキュメントは、プロジェクトの計画や品質を守るためにも必須と考えています。
私が必要と考える設計ドキュメントを以下に記載しました。
設計ドキュメント
| 番号 | 項目 | 内容 | 備考 | 優先度 |
|---|---|---|---|---|
| 1 | GQM | 定量的にプロジェクトの目標(ゴール)を定義する手法 | プロジェクトの目標(ゴール)があいまいになることを防ぐ | 高 |
| 2 | PFD | プロセス(作業)と成果物を１枚の図に表すことで， 作業と成果物の連鎖を見えるようにする図表 |
図だけでなく定義書を同時に作成することにより， より厳密な定義も同時に表現できる文書となる |
高 |
| 3 | USDM | 要求と仕様を記述する1手法。ソフトウェア要求仕様を定義するときに用いる | 高 | |
| 4 | クラス図 | システムを構成するクラスとそれらの関係を表現する | 高 | |
| 5 | コミュニケーション図 | クラスやオブジェクト間の応答（相互作用）と関連の両方を表現する図 | 高 | |
| 6 | ステートマシン図 | オブジェクトの状態遷移を表現する為の図 | オブジェクトの状態が多数あるプログラムであれば有用 | 中 |
| 7 | 状態遷移表 | UMLのステートマシン図の内容を表形式で表示したもの | astah professionalであれば、プラグインを使用することで、ステートマシン図から自動生成可能 | 中 |
| 7 | シーケンス図 | クラスやオブジェクト間のやりとりを時間軸に沿って表現する図 | 極めてわかりにくい処理フローがあれば、作成すべき | 低 |
語句紹介
- GQM : Goal(目標), Question(質問), Metric(尺度)
- PFD : Process Flow Diagram
- USDM (Universal Specification Describing Manner)
特記事項
- GQM
- ユースケース図を用いて記載するとよいでしょう。
PFD
- プロセス(作業)と成果物は、リスクの種類に応じて色分けすると効果的です
- 自分達が作成する成果物
- チーム外から受け取る成果物
- リスクが高いことが予想される作業
- プロセス(作業)と成果物は、リスクの種類に応じて色分けすると効果的です
USDM (Universal Specification Describing Manner)
- 顧客仕様が複雑なときほど、効果が発生します
- 自分はExcelファイルで作成しています
クラス図
- 今後のソースコードの保守（バグ修正や機能拡張）を考えると、必ず作成すべきです。
コミュニケーション図
クラス間のデータの流れを一目でわかるため、レビューなどで役立つでしょう
シーケンス図
- これ単体でレビューで説明するのは、難しいと思います。極めてわかりにくい処理フローがあれば、作成すべきと思います。
- 各クラスの役割や各クラスが持つメンバメソッドなどを理解した上で読まないと理解できないため)
- これ単体でレビューで説明するのは、難しいと思います。極めてわかりにくい処理フローがあれば、作成すべきと思います。
UMLツールについて
私は、astah professionalを使用しています。おすすめです。
便利な使用方法についてまとめていきます。
