システム開発の詳細設計（プログラム設計）

詳細設計では、内部設計で設計したシステムの各機能をより詳細化し、実際にどのような処理を行ってプログラムを動作させるかを決めていく。プログラマは詳細設計書を元にプログラムを実装していくため、プログラマに分かりやすい表記で設計していくことが求められる。

プログラムの仕様を記述していくため、プログラミング言語に依存した書き方になるが、概ね記述すべき内容は決まっている。正常系と異常系の処理フローを記述し、異常時の場合の処理内容を詳しく書く。 　処理フローの内容を次に示す。

異常系とはどのような処理なのか、混合する場合がある。ここでは、異常系の考え方について解説する。

業務的な異常なのか、システム的な異常なのかを把握しながら異常系処理を設計する必要がある。システム的な異常であれば、動作環境に原因があるため、OSや環境設定を見直すことで解決することが多い。逆に言えば、環境の見直し以外に対応策がなく、プログラムを終了させる必要がある。このような状況に対して処理を再施行しても、効果は非常に低い。　一方、業務的な異常処理を設計するときは、内部設計の設計バグの可能性もあり、慎重に設計する必要がある。ファイルレイアウトが不正の場合など、本当にそこでプログラムを異常終了して良いのか、機能の特性を見極めなければならない。例えば、「不正な入力があった場合でも、運用側で障害回復を期待するのではなく、できるだけアボートせずに機能を満足させる」というような、システムのポリシーが存在することもある。

なお、監視プログラムなどは、システムのある異常を検出する目的で動作するように考えがちである。しかし、異常を検出することを目的とすると、異常の検出時が監視プログラムにとっては正常系処理となるため、異常の検出を目的として考えてはならない。監視プログラムはあくまで、システムが正常に動いていることを検出することが目的、として扱うべきである。

処理の正当性を判定するために、戻り値を判定する分岐処理が必要である。これらの判定にかかるコストについて、考慮せずに設計してしまう場合が多い。特に、サーバプログラム（デーモン）など、常駐して動き続け、処理の実行頻度が高いものに関しては、判定の回数が性能問題に直結する。 　このような状況の回避策としては、判定処理を減らすしかない。しかし、判定を減らすことはプログラムがコアダンプする可能性もあり、むやみに判定を減らすことは危険である。判定を減らすことができる条件は、異常が起こりえないことが保障されている場合のみである。例えば、データベースで10バイトまでしか扱わないのに、プログラム側でその値を取得したあとに、10バイトを超えているかどうかを判定する必要は無い。このようなデータサイズの検査は定性的に行ってしまうことが多く、無意味な処理が増加する原因である。 　また、考えられる異常系を起こりえないものとして、判定処理を行わない場合もある。それはプログラムの制限事項として、そのプログラムの呼び出し側で十分に考慮しなければならない。制約がある分、そのプログラム自体がリスクとなるわけで、呼び出し側で制限事項の考慮がされていないままに実装してしまうと、予期しない動作をしてしまう恐れがある。

プログラムを堅牢に設計するのか、性能重視で設計するのかは、機能の要件による。しかし、性能はマシンスペックを向上させることで、ある程度改善するという観点から、堅牢に設計するほうが安全と言える。なお、単体テストの作業量を減らすために判定処理を減らそうとすることは、決して行ってはならない。

内部設計では、データベース論理設計を行い、データベースの論理モデルを作成している。それを元に、本フェーズでは物理モデルを設計する。具体的には論理モデルの正規化などを行い、データベーステーブルを定義する。　詳細設計でプログラムの仕様を決める際に、具体的なデータベース定義が必要になる。そのため、データベース物理設計のほうが、プログラム仕様の定義よりも優先度は高い。 　データベース物理設計では、最終的にエンティティ定義書を作成する。これは、データベースの定義内容を帳票にしたもので、テーブル名、列名、値の型、列のサイズを表記する。エンティティ定義の設計を支援するツールは非常に多く、Object Browser ER などは代表的なツールである。　エンティティ定義の他に、テーブル間の関連を示したER図を作成する。これによってデータの関連を視覚的に把握することが出来る。