開発時に、いつもぶれるので、纏めておく。
各ドキュメントは、開発に必要か、どの程度の粒度で作るかを事前に確認すること。
要件定義
-
要件ヒアリング
2. 要件の聞き込み調査、議事録質疑応答などで、Issueリストを作成 -
業務フロー作成
3. とりあえず業務フローをつくって、情報整理。要件ヒアリングとも整合性を合わせる。 -
ユースケース作成
4. 要件ヒアリングと、業務フローを元に、ユースケースの作成 -
画面遷移図
5. 画面遷移のみを考慮。この時点で技術的な考慮は行わない。 -
画面モックアップ
6. この時点のモックアップは作りすぎないこと。(でないとコストオーバー)
6. 主要画面や技術的に確認する部分に特化させること。
7. 作成したものは基本的に、以降の開発に生かすように作成
8. プロジェクトのトッププログラマに委任、後の開発時に技術的な部分を任せることも視野に入れる。
基本設計
基本設計になると、同時進行で作成する成果物が多いので、柔軟に対応すること。
-
基本設計初期
大まかに概要を設計する段階。あまり資料を書き込みすぎない。悩みすぎない。- ロバストネス図
- データーフロー図
- 画面レイアウト
-
設計中期
初期の設計の資料に承認を得た物から、以降の開発を行うこと。
全機能の細かい部部まで作る必要なし。部分的な箇所、問題になりそうな箇所だけで良い。
4. ドメイン設計(ここは時間をかけた方が良い)
5. クラス設計
4. シーケンス図
5. 画面レイアウト
6. 画面項目定義
7. ユースケースシナリオ -
基本設計後期
この時期には、システムの整合性を保つための作業を行う。- ユースケースシナリオのブラッシュアップ
2. 整合性を保つこと。 - モックアップのブラッシュアップ
3. 確認事項が増えた項目についてモックの追加
- ユースケースシナリオのブラッシュアップ