はじめに
本記事は、上流工程のながれについてざっとまとめてます。
実務において、上流工程に携わった経験はないですが、プログラマー目線でみても設計は以下の理由で大切だと感じます。
- この仕様どうだっけっていうときに、いつでも確認できる
- 基本的に、チームで開発することがほとんどなので途中参加の人でも仕様を追える
- 設計がしっかりしていると、コードの品質を高められる
- プロジェクトに参加している人同士での意思疎通
企画
それではまず、企画。お客様から「これでいきましょう～」という承認を得るためのフェーズです。
- お客様が抱えている現状の問題を明確し、この企画の「なぜ」必要かを理解する
- 「なに」をめざすのか、ゴールを明確にする
- 現状の問題を解決し、ゴールを達成するために、どんなプロダクトを作るか、それによってどんな成果が得られるかを明確にする
要件定義
プロダクトを使う利用者のニーズを把握することで、システム開発に求められる要件を明確にするフェーズです。
- モデリング
- 完成イメージを図を使って描きながら整理していくことで、解決すべき課題や細かなルールを洗い出し、それを全員で共有していくことがモデリングの目的。
- ユースケース図→誰が、どういう操作を行うのかを明確化
- アクティビティ図→具体的な運用プロセスの把握
- 状態遷移図→システム内部で管理している状態の明確化
- ドメインモデル→システムに登場する人や物を洗い出す
- システム開発の達成条件
- システム開発のスケジュール感
基本設計
ビジネス側とエンジニア側とで共通認識をつくるフェーズです。
- 画面設計
- ユースケース図やドメインモデルから各画面でなにができるのかなどを画面遷移図を描いて整理していく。細かなデザインはデザイナーさんにおまかせ
- 機能設計
- あるユースケースを実行する画面において、裏側で走る処理をまとめ、その処理に関連するデータをドメインモデルから洗い出す
- データベース設計
- ER図→データベースに保存するためのデータ構造を表現（ドメインモデルをテーブル形式として定義しなおす）
詳細設計
エンジニア（プログラマー）に詳細な実装方法を伝えるフェーズです。
- ロバスト図→責務ごとに適切なクラスを割り当てる
- シーケンス図→割り当てられたクラスの中でどういう処理が実行されるかを考える
- クラス図→各クラスがもつ属性、メソッド、クラス同士の依存関係などを整理する
おわりに
こうみると、抽象的だった要件定義から基本設計をふんで、より実装レベルに近い詳細設計へと落とし込んでいく流れが感じとれて面白いですね。
以上です。