NSウォーターフォールモデル、6フェーズモデルはウォーターフォールモデルです。 つまり、ステージは順番に発生します。 滝に向かって上流に泳ぐことが不可能であるのと同じように、純粋な滝の技術は、それが終了した後にフェーズに戻ることを排除します。
実装フェーズ中に設計を変更して実装を停止することを決定することは理想的ではありません。 ウォーターフォールアプローチは、さまざまな理由から、ソフトウェア開発プロジェクトにはあまり適していないことがよくあります。
- ソフトウェア開発は芸術的な取り組みです。すべてのニーズ（機能）を予測することは事実上困難です。
- 機能の開発に必要な時間を見積もることは非常に困難です。
- プロジェクトのライフサイクル全体を通じて、ユーザーはすべての中間結果をテストできる必要があります。
ソフトウェア開発は芸術的な取り組みです #
初心者にとって、ソフトウェア開発は発明よりもエンジニアリングに関係しているように思われます。 しかし、それは発明と多くの点で関係しています。 創造の過程で、何が起こるかを正確に知ることは決してありません。
新しいソフトウェアの開発を担当する設計者とプログラマーは、提示された問題に対する答えを考え出す必要があります。 仕事のための多くの技術と処方箋にかかわらず、コンピュータコードの作成はまだほとんど知られていないため、予測できません。 プログラマーは、数十のプログラミング言語で記述され、数千の異なるハードウェアの組み合わせとソフトウェアプラットフォームで動作する数百万のソリューションから選択できます。 この柔軟性には多くの利点がありますが、従来のプロジェクトよりもプロジェクトの管理が難しくなります。プロジェクト管理（建設や建築プロジェクトなど）。
実装のセットアップ #
ウォーターフォールアプローチでは、要件を次の結果として定義する必要があります。プロジェクトの定義フェーズ。 理想的には、プロジェクトの残りの部分で、これらの基準からの最小限の追加の逸脱が発生する必要があります。 ソフトウェア開発のウォーターフォールアプローチでは、必要な機能（要件）を分析するために多大な労力を費やす必要があります。 これにより、機能設計が作成されます（機能設計の詳細については、Iを参照してください）。 ソフトウェアアーキテクトは、機能設計を参照として使用して、設計プロセス全体で技術設計を作成します。 さらに、技術設計では、必要な機能を実行する方法について説明しています。
これは単純な問題のように思われるかもしれませんが、次のシナリオを検討してください。 プロジェクトの一環として、新しい車両が開発されています。 アクティブな車の運転手として、あなたは自動車のニーズを開発する任務を負っています。 あなたは他の運転手と話し合い、徹底的なリストをまとめます：
- 車は4人乗りでなければなりません。
- 自動車は、ドライバーの左側の前部にハンドルがなければなりません。 •自動車には、ブレーキペダル、アクセルペダル、およびハンドブレーキが必要です。
- 自動車のヘッドライトは白で、テールランプは赤である必要があります。 （明らかに、実際のリストは膨大になるでしょう）
デザインとモデリング #
デザイナーはあなたのリストをガイドとして使用して新しいデザインを作成し、それは何ヶ月も後に作成されます。 通りを下ると、車両が停止しているのがわかります。 あなたはあなたがあなたのリストからブレーキライトを省略したことに気づきます！ あなたはすぐに自動車メーカーのエンジニアに連絡します。エンジニアはあなたの電話に応じてほとんど破裂します。 あなたはそれがマイナーな調整であると主張します。 しかし、それは自動車メーカーにとって大惨事です。 すでに製造されている自動車は完全に解体し、ブレーキペダルから後部までのワイヤーを延長し、車両の後部をブレーキライトに合うように完全に再設計し、すでに製造されているブーツハッチを廃棄する必要があります。
上記のシナリオはばかげているように見えますが、ソフトウェア開発ではほぼ毎日発生しています。 プログラマーは、作成されている製品のクライアント、顧客、またはユーザーが自分たちが何を望んでいるかを正確に理解していると誤って想定します。 クライアントは、ソフトウェア開発者が実行可能な最短時間で何でも作成（および変更）できると誤って信じています。 これが、消費者とソフトウェア開発者の間の競合の主な原因です。
