前回に引き続き、今回は外部設計の工程について考えていきます。
外部設計
「要求定義」で具体化したお客さんが実現したいことを、”どのように”実現するかを考えることが本工程です。実現できれば良いので、解答は無数にあります。そんななかで、コストと期間という制約条件を踏まえ、最善の設計を探ることになります。
この工程から参加することになったら？
この工程から開発に参加することになった場合に、何から手を付ければよいでしょうか。管理人は要求定義を可能な限り把握することに注力します。可能なら要求定義が決まった背景となる求められている業務フローや思想を頭に入れます。前の工程と変わらないではないか、と考えられる方もいますが、要求定義をゼロから考えることとは雲泥の差があります。本工程では要求定義は磨き上げられて決定しているので、要求定義に沿って実現手段を考えればよいのです。逆に言えば要求定義に記述されていないことは考慮する必要はありません。場合によっては考慮してはいけないのかもしれません。このようにあとの工程にすべて影響を及ぼすことから要求定義の工程は重要なのです。
大きな塊から考えつつ、要求定義とのマッピングを行う
要求定義を把握できれば、それぞれの要求を実現する機能を考えます。まずは大まかな機能の塊で考えればよいでしょう。そしてそれぞれの機能が連携することでどのようなフローを実現するかを絵にします。この工程でもお客さんや同僚とイメージ合わせをしていくことが重要です。機能間の動きが要求定義に示された事項を満たすかを自身でマッピングできなければ適切に設計ができているとは言えないでしょう。
実装できるのかを考える
また機能を考えた後でも、それを実際に実装できるかという観点を検討の際に取り入れる必要があります。大きな機能の塊（昨日ブロック）でｘｘｘを行う、と定義すれば、ではそのｘｘｘを実現するにはどのような小機能があればあればよいかという形で細分化と詳細化していきます。この細分化と詳細かはある程度単純な説明、例えば△△データの新規作成、更新、削除で可能なレベルまで進めておく必要があります。ここまで記述できれば、どのように実装するかは次に詳細設計で行うことができます。逆に詳細設計で実装に落とし込めない場合は、この外部設計の定義が不十分ということになります。
あとがき
さて、次はいきなりテストについて考えたいと思います。というのも管理人は詳細設計やプログラミングの工程の経験が乏しいので、よさそうな知見を提供できないためです。その点テスト関連の工程はさんざん苦しんでいるので、多少のお役立ち情報は提供できると思っています。
