システム開発の工程

要点と定義

共通フレームは、システムの開発や保守におけるプロセスと作業項目を定義します。開発では、要件定義、設計、プログラミングと単体テスト、統合・テスト、導入・受入れへ進み、稼働後は保守を行います。

要件定義では必要な機能や性能を明確にします。設計書の内容が利用者の要求を満たすか、利用者と開発者が確認するのが共同レビューです。

プログラミングでは設計に従って個々のプログラムを作成し、単体テストで誤りを確認します。内部の制御構造や処理経路に着目するホワイトボックステストは、単体テストで活用されます。

統合・テストでは単体テスト済みのプログラムを組み合わせ、連携やシステム全体の動作が要件どおりかを確かめます。ブラックボックステストは内部構造を前提とせず、入力と期待する出力に着目します。

導入・受入れでは、取得者が意図した運用環境でシステムを使い、意図した用途を達成するかを確認します。利用者や発注者が業務上の要求を満たすかを主体的に確かめるのが受入れテストです。

保守は稼働後のシステムやソフトウェアの修正、変更、改善です。不具合修正だけでなく、仕様変更や外部環境の変化への対応、関連文書の改善も含まれます。

関連する設問上の傾向・指標：ウォータフォール型開発では、要員数は工程の進行につれて増えて途中でピークを迎え、終盤に減る傾向があります。変更や誤りの訂正コストは、発見が遅いほど高くなる傾向です。実際の要員数はプロジェクトにより異なります。

不良密度は「不良件数÷開発規模」で求め、下限と上限の範囲内かを工程ごとに確認します。例えば、範囲が0.25～0.65件/KSの場合、A工程が32÷80＝0.40件/KSなら範囲内、B工程が8÷80＝0.10件/KSなら下限未満です。この機能はA工程に問題がなく、B工程に問題があると判定します。

適用条件と例

注文画面の設計書を利用者と開発者が要求と照らして確かめるなら共同レビューです。プログラム内部の分岐を確認するならホワイトボックステスト、仕様に沿って画面入力と表示結果を確認するならブラックボックステストの考え方です。手掛かりは、内部構造を見るか、外から見た入出力を見るかです。

納入された予約システムを利用者が実際の業務に照らして確認するなら受入れテストです。稼働前に見つかった不具合は開発・テスト工程で対応し、稼働後の不具合修正や環境変化への更新は保守に当たります。