設計工程は、前のプロセスである要件定義時にヒアリングした内容を図面に起こす作業を行います。
基本的にシステム開発の工程では、全行程の内容を細かく砕いて次の工程を制作していきます。
お客様からヒアリングした内容を画面や印刷物へ落とし込み図面にする作業を外部設計、外部設計書で洗い出された画面、印刷物に必要な項目の入れ物(データベース)として落とし込む事を内部設計と呼びます。
その後、外部設計書、内部設計書を基にプログラムをどのように組むかを設計するプログラム設計書やシステム同士のデータのやり取りなどのインターフェース設計書、等、一層細かい部分に分解し設計を行っていきます。
要件定義でヒアリングした内容を外部設計にて画面設計を行います。
例えば「要件で顧客が参加したセミナーの情報を履歴として保管したい」と要求があれば、
セミナーへの顧客参加状況を登録する画面が必要になる事は分ると思います。
また、その画面へ必要な項目を配置します。
その画面には、セミナーの情報と顧客の情報が必要になります。
例えば、セミナー名、セミナー開催日時、セミナー開催場所、顧客名、事前予約や出欠状況、等。
必要な項目が列挙されます。当然、登録するためのボタン等も必要になります。
それらを画面へレイアウトした図面を起こします。それが、画面仕様書となります。
それら、画面や印刷物だけではなく、人と接する部分の定義を決めた総称が外部設計書となるのです。
外部設計書にて決定した画面内の項目にデータを当てはめるのですが、そのデータの保管場所(データベース)の設計を行います。
画面へは、その保管場所からデータを出し入れし表示させます。
上記のセミナーへの顧客参加状況を登録する画面の例で考えれば、画面に配置された項目、セミナー名、セミナー開催日時、セミナー開催場所、顧客名、事前予約や出欠状況が納まる箱を作ります。
実際には、ただ単に文字を入れる様な設計は行わず、正規化し、セミナー名、セミナー開催日、セミナー開催場所、等をセミナー情報としてマスター化し、顧客名、顧客連絡先、顧客住所、等の顧客情報もマスター化し、それぞれ入る場所を設計します。
それらマスター化したセミナー情報と顧客情報を持つ履歴情報をセミナー参加履歴情報を入れる場所として設計します。これらは、データベースに関する記事で何れご紹介します。
これらのデータの入れ物等を設計した書類がテーブル定義書となるのです。
テーブル定義書だけではなく、ER図や内部的な処理等の仕様を定義したものの総称が内部定義書となります。
画面仕様書やテーブル定義書等が決まってくると、どの様にプログラムをしたらよいかが決まってきます。
画面仕様書で設計した画面にユーザーが入力し、「登録」ボタンを押したら、入力した情報をテーブル定義書で設計したデータを入れる箱へ登録する処理になります。
逆にユーザーが情報を閲覧したいのであれば、テータを入れる箱から情報を引っ張り出し画面へ表示させる様に処理すれば良いのです。
それをプログラムする事になります。
例えば、データを登録する処理が他の画面でも使用できるなら共通の関数にして各画面から、その関数を呼び出せば同じ処理が行えます。
この様にしてプログラム設計やインターフェース設計等の詳細な設計を行います。
全てを管理している様なプロジェクトの場合、プログラム仕様書やコード規約、等によってプログラマに細かく指示を出しているプロジェクトも存在しますが、大まかな仕様までを制作しプログラムの仕様などはプログラマに任せるプロジェクトも存在します。
細かく仕様を決める事によって設計者の思い通りの製造が実現しやすくなり、ひとりの思想の元で製造されていくためシステムとしては一貫性が保たれ、プロジェクトのマネージメントがしやすく、後の管理も容易であるという長所があります。
しかし、その半面、ドキュメント制作に時間がかかり、製造になかなか到達せず工期が、かなりかかるという短所も存在します。
一概にどちらが良いとは言えません。しっかり管理しても失敗するプロジェクトは失敗しますし、プログラマ任せで製造しても逆に時間がかかってしまう例も存在します。