ウォーターフォール型のソフトウェア開発ライフサイクル

ウォーターフォールモデルは、ソフトウェア開発ライフサイクルで広く用いられてきた、直線的な手法です。工程の順序を定め、各工程に明確な目標を設定します。水が斜面を流れ落ちるように、厳格なモデルでは工程を逆戻りせずに進みます。

ウォーターフォール型の進め方は厳格で、見直しの余地が限られています。テストは開発と並行して継続する作業ではなく、独立した工程として扱います。そのため、このモデルでは開発の初期に欠陥を見つけることができません。

原寸大の図を開く ↗

ウォーターフォール型のソフトウェア開発ライフサイクル

工程は次の順序で進みます。

1. 要求の収集。顧客の要求を把握し、必要な文書を作成します。
2. システム設計。要求に基づき、アーキテクチャと、必要なハードウェアやソフトウェアを定めます。
3. 実装。設計をもとにコーディングを始めます。プログラムを小さな独立した単体に分け、各単体が仕様どおりに動くかテストしてから、システム全体に結合します。
4. 結合テスト。テスト済みの単体を組み合わせ、システム全体に欠陥がないか確認します。
5. 展開。結合テストで見つけた欠陥を修正し、再テストして解決したことを確認します。これで市場に公開し、顧客の環境に展開する準備が整います。
6. 保守。納品後に見つかった欠陥や問題を解消するため、修正パッチや新しいバージョンを提供します。

工程は順に進みます。前の工程が正常に完了してから、次の工程に着手します。

要求が明確で、製品が安定し、各工程に十分なリソースがある場合にウォーターフォールモデルを使います。実務では、管理しやすい小規模プロジェクトに限って適用します。要求に中程度以上のリスクがある場合は避けます。

要求の仕様化と分析

ソフトウェア開発の成否は、要求をどれだけ正確に把握し、文書化できるかにかかっています。要求を特定して文書にまとめる作業を、要求の仕様化と分析と呼びます。

顧客、管理チーム、技術サポートチームで要求を詳しく話し合います。要求が明確で漏れのないものになるまで、分析し、見直し、文書にまとめます。

原寸大の図を開く ↗

ユーザー要求仕様書

Word文書、フローチャート、図面など、会社が指定した形式を使います。顧客が何を求めているかを詳細に記録することで、チームは要求を正しく理解できます。顧客の要求を満たさないものはすべて欠陥です。要求の把握を誤ると、プロジェクトは最初から誤った方向に進みます。

ユーザー要求仕様書

この非技術的な文書には、ユーザーの期待と業務上の必要事項を記します。実際に使うユーザーが作成し、記載された要求はユーザー受け入れテストで確認します。この文書は、以降の要求に関する作業とシステム設計の土台になります。

ソフトウェア要求仕様書

ソフトウェア要求仕様書（SRS）には、ユーザーがソフトウェアに求める動作を定めます。目的は次のとおりです。

• ソフトウェアの具体的な機能について、顧客と提供側が合意した内容を記録する。
• ソフトウェア設計の土台にする。
• 要求を明確にし、開発とテストを進めやすくする。
• 作業のスケジュール作成やコストの見積もりに役立てる。
• 検証と妥当性確認の土台にする。

原寸大の図を開く ↗

ソフトウェア要求仕様書

ソフトウェア設計

ソフトウェア設計には二つのレベルがあります。

• ソフトウェアの上位設計
• ソフトウェアの詳細設計

原寸大の図を開く ↗

ソフトウェア設計

ソフトウェアの上位設計

上位設計（HLD）では、データベースの設計と機能アーキテクチャを記述します。開発者の指針となり、設計の流れについての疑問に答えます。HLDの作成には、明確なSRSが必要です。

ソフトウェアの詳細設計

詳細設計または下位設計（LLD）では、HLDをより小さな部分に分け、プログラム仕様を構成するロジックを記録します。システムの詳細を示すもので、HLDが完成していることが前提です。

ソフトウェアの設計手法

設計では次のいずれかの手法を取ることができます。

• トップダウン設計
• ボトムアップ設計

トップダウンによる設計

トップダウン設計では、まずシステムの全体像を描き、サブシステムの詳細は後で決めます。各サブシステムを段階的に掘り下げ、基本要素に至るまで詳しく定義します。

ボトムアップによる設計

ボトムアップ設計では、詳細がすべて定義された基本要素から始めます。基本要素を組み合わせてサブシステムを作り、それらを結合してシステム全体を構成します。植えた種から木が少しずつ育つ様子を思い浮かべてください。