ウォーターフォールでは、QAが開始する前にコードを完了する必要がありますか？

Question

特定の会社で使用されるプロセスは、次のもので構成されます。

Webページデザインツールで作成されたいくつかのデザインに従ってレイアウトを作成します。（CSS、html）

要件には「機能要件」が含まれます。これらは、何百もの事業の方向性で構成されています。例えば。 Xページにテーブルを作成します。Column1には数値データがあります。 Column1はクライアントコードです。 Column2は文字列です...など。

すべての機能要件を満たすコードを記述します。

すべてのコードがチェックインされたら、QA（要件を作成したBA）に送信して、検査、バグの検出、および変更要求を行います。

X個のバグとY個の変更要求のリストを使用して開発者にパントバックします。

バグが0より大きいリクエストを検出または変更している間、ステップ4に進みます。

私が取り組んできたアジャイル開発環境では、要求がない場合でも、早期のQA検査と早期のユーザー受け入れが可能です。そのため、アプリケーション全体を配置する前に、プログラムの一部を改良および再定義できます。

それだけでなく、このプロセスでは、エラーや人々の考えが変わる余地はほとんどありません。代わりに、それらの「変更要求」は、最も大きなダメージを与える最後の段階で入ります。また、バグ修正のコストは時間の経過とともに増加するため、これはコードを作成するためのコストのかかる方法です。

私は違います滝専門家です。説明したように、この滝は何らかの方法で誤って処理されていますか？ウォーターフォールは私の懸念にどのように対処しますか？

Thomas Owens · Accepted Answer

Wikipedia artic leで説明されているように、ウォーターフォール手法を使用することは、かなりの規模のプロジェクトでは、危険な試みです。一般的に教えられているウォーターフォール手法では、テストは最後に行われます。「テスト」フェーズの前に行われる検証または検証についての議論は（とにかく私が知っている）ありません。ただし、一般的に教えられているウォーターフォール法は、ソフトウェアシステムを構築しない方法の例であり、 Winston Royceによる論文から来ています。ここで、次のように説明されています。

私はこの概念を信じていますが、上記の実装はリスクが高く、失敗を招きます。この問題を図4に示します。開発サイクルの最後に発生するテストフェーズは、分析とは異なり、タイミング、ストレージ、入出力転送などが発生する最初のイベントです。これらの現象は正確に分析することはできません。たとえば、数理物理学の標準的な偏微分方程式の解ではありません。しかし、これらの現象がさまざまな外部の制約を満たさない場合は、必ず大規模な再設計が必要になります。いくつかの孤立したコードの単純な8進パッチまたはやり直しでは、この種の問題は修正されません。必要な設計変更は非常に破壊的である可能性が高いため、設計の基礎となり、すべての根拠を提供するソフトウェア要件に違反します。要件を変更するか、設計を大幅に変更する必要があります。事実上、開発プロセスはオリジンに戻り、スケジュールやコストで最大10％のオーバーランが予想されます。

私がリンクした論文の図10は、Royceが提案したソフトウェア開発モデルであり、要件、設計、および実装のレビューが明示的に含まれています。これらのレビューには、ある程度品質保証チームが関与しているのではないかと思います。また、品質保証に加えて、顧客は（必要に応じて）すべてのフェーズで開発プロセスに関与します。これは、従来から教えられているウォーターフォールモデルとは異なります。

現在、計画主導の方法論（Royceが提案した方法論など）は、適切なインスタンスで使用された場合、間違っていたり悪くはありません。たとえば、要件が不安定なプロジェクトでは、それらは最善の選択肢ではなく、これがあなたのケースのように思えます。そうです、何を構築または変更する必要があるかわからない場合は、計画主導の方法論を使用すると、次の理由でコストがかかります maple_shaftは彼の回答に書いています。

maple_shaft · Answer

これは従来のウォーターフォールの方法論にかなり当てはまるようで、バグや要件の欠落の相対的なコストがプロジェクトの過程で指数関数的に増加するというウォーターフォールの重大な欠点についてはすでに述べました。

Relative Cost of Requirements Errors

ウォーターフォール開発でこれを最小限に抑える方法は、プロジェクトの全過程を通じてBA/QAで定期的にステータスの更新を提供することです。これにより、何かが間違っているのを見つけた場合、バグや要件を見逃す前に、早期に呼び出すことができます。後でSDLCで。

RonU · Answer

おそらく、単純な「はい/いいえ」を与えることがこの質問に対する望ましい答えですが、私はそれを行うことができません。

ウォーターフォールの特徴は、紙の上では見栄えがするが、人間の行動の現実と一致することはほとんどないということです。

あなたはアジャイルにある程度精通していることをほのめかし、人々が考えを変えることから生じる問題を指摘しているので、あなたはこの問題にある程度精通していると思います。ソフトウェア開発は、ステップ1からステップ2、ステップ3に至るまで、きちんと整然と進むための橋渡しに十分なほど似ていません。私たちは、顧客のアイデアが成長し成熟し、優先順位が変わるにつれて、より多くを学びます。

したがって、理論的には「はい」と言います。Waterfallで概説されている厳格で非現実的なプロセスによれば、コードはテストに進む前に完了しています。しかし実際には、これはしばしば機能せず、多くの歯ぎしりにつながります。