カスケードモデルデバイス
ウォーターフォール モデルはウォーターフォールとしても知られ、ソフトウェア開発への最もよく知られたアプローチの 1 つです。モデルの作者はウィンストン・ロイスです。1970 年、彼はその長所と短所を詳しく説明した記事でそのイノベーションの本質を説明しました。同じ場所で、彼はこのモデルを反復モデルにどのように改良できるかについて説明しました。ウォーターフォール モデルでは、最初は次の順序で開発段階が進みます。
- 要件の定義と調整。
- プロジェクトの承認。
- コーディング;
- ソフトウェア製品の動作バージョンの作成。
- テストとデバッグ。
- ソフトウェアのインストール;
- サポート。
ウォーターフォール モデルによれば、開発者によるアクションの実行は、ポイントごとに順次に行われます。まず、完成すべきリストの形式でソフトウェア要件を決定し、合意する作業が完了しています。
その後、プロジェクトの作成と承認に移行し、その結果、以前に合意されたソフトウェア要件を実装する方法を説明する文書が作成されます。
設計が完了すると、開発者が実装を担当します。次に、コードのマージ、つまりさまざまなチーム メンバーが取り組んだプロジェクトの個々の部分の統合が行われます。
次のステップは、製品のテストとデバッグです。以前に見つかったエラーはここで修正されます。
最後に、プログラムがインストールされ、サポートされます。これには、必要に応じて機能に変更を加え、見つかったエラーを除去することが含まれます。
カスケード モデルは、前のタスクの完了後にのみ、開発の次の段階に厳密に順次に移行できることを前提としています。ロールバックやフェーズの不一致の可能性は提供されません。
長所と短所
ウォーターフォール モデルは、柔軟性に欠けているという理由で批判されることがあります。多くの人はこれを好まないが、それはプロジェクト管理の目標が優先される一方、期限を守ること、コスト、開発の品質がはるかに重要だからである。
ただし、大規模なプロジェクトの場合、プロジェクトのリスクが軽減され、作業の透明性が向上するため、管理がより重要になることがよくあります。
欠点にもかかわらず、PMBOK第 3 バージョンでは「カスケード モデル」方法論のみが正式に規定されています。反復的なプロジェクト管理などの他のオプションは提供されません。
ウォーターフォール モデルの利点:
- チーム開発は管理が容易になります。顧客はプログラマーが現在取り組んでいることをよく知っており、プロジェクトの期限や予算を変更することができます。
- 開発費は第一段階で承認されます。実装のすべての段階で合意した後、ソフトウェア製品が継続的に作成されます。
- 経験豊富なテスターは必要ありません。テスト段階では、プログラムのドキュメントを使用できます。
ウォーターフォール モデルの欠点:
- テストは開発が完了した段階から始まるため、バグが発見された場合には初期段階よりも修正コストがかかります。結局のところ、テスターがエラーを見つけるのは、開発者がコードを書き終えた場合と、コピーライターがドキュメントを書き終えた場合だけです。
- 顧客は開発完了後に完成品を目にします。したがって、製品がほぼ完全に完成して初めて評価することができます。結果が気に入らない場合は修正が必要となるため、プロジェクト予算のコストが大幅に増加します。
- 技術文書が増えるほど、作業を完了するまでに時間がかかります。このような文書化には、さらに多くの変更と承認が必要です。
「ウォーターフォール」は、医療および航空宇宙産業のプロジェクトでよく使用されます。そこではすでに広範なドキュメントが存在し、それに基づいて新しいソフトウェアの要件を作成することができます。
ウォーターフォールモデルを使用する場合、主なことは詳細な要件を記述することです。テスト中に、プロジェクト全体に悪影響を与えるバグがどこかにあることが判明してはなりません。