先日、友人から、ソフトウェア開発ライフサイクルの問題を解決するためのコストのピラミッドがあると言われました。これはどこにありますか？
彼は問題を解決するためのコストについて言及していました。
例えば、
要件段階で問題を修正するには、コストがかかります1。
開発段階で問題を解決するには10の費用がかかります。
テスト段階で問題を修正するには100の費用がかかります
生産段階で問題を解決するには1000の費用がかかります。
（これらの数値は単なる例です）
誰かが参照を持っているなら、私はこれについてもっと見たいと思います。
これは、数え切れないほどの研究で何度も何度も複製および検証されてきた経験的なソフトウェアエンジニアリングでよく知られている結果です。残念ながら、これはソフトウェアエンジニアリングでは非常にまれです。ほとんどのソフトウェアエンジニアリングの「結果」は、基本的に伝聞、逸話、推測、意見、希望的な思考、または単なる嘘です。実際、ほとんどのソフトウェアエンジニアリングは、おそらく「エンジニアリング」ブランドに値するものではありません。
残念ながら、ソフトウェアエンジニアリングの結果として最も堅実で、科学的および統計的に健全で、最も徹底的に研究され、最も広く検証され、最も頻繁に複製された結果の1つであるにもかかわらず、それも間違っています。
問題は、これらの研究のすべてがそれらの変数を適切に制御していないことです。変数の効果を測定する場合は、その1つの変数のみを変更し、他の変数はまったく変更しないように十分に注意する必要があります。「いくつかの変数を変更する」のではなく、「他の変数への変更を最小限に抑える」のではありません。「1つだけ」と他は「まったくない」。
または、素晴らしいZed Shawの言葉で、「何かを測定したい場合は、他のたわごとを測定しないでください」。
この特定のケースでは、バグが見つかったフェーズ（要件、分析、アーキテクチャ、設計、実装、テスト、保守）を測定するだけでなく、バグがシステムにとどまっている時間を測定しました。そして、フェーズはほとんど無関係であることがわかります。重要なのは時間です。どのフェーズではなく、バグをすばやく見つけることが重要です。
これにはいくつかの興味深い影響があります。バグをすばやく見つけることが重要な場合は、バグを見つける可能性が最も高いフェーズであるテストを待つのはなぜですか。最初にテストを入れてみませんか？
「伝統的な」解釈の問題は、それが非効率的な決定につながることです。要件フェーズですべてのバグを見つける必要があると想定しているため、要件フェーズを不必要に長く引きずり出します。要件（またはアーキテクチャ、または設計）を実行できないため、実行すらできないバグを見つけるのはおかしくなります。ハード！基本的に、要件フェーズでバグを修正するのは安価ですが、バグを見つけるのは費用がかかります。
ただし、それが可能な限り早い段階でバグを見つけることではなく、可能な限り早い時期にバグを見つけることであることに気付いた場合は、プロセスを調整して、バグを見つける段階に移ることができます。それらを修正するのが最も安い時点（最初）まで最も安い（テスト）。
注：私は、完全に根拠のない主張で統計を適切に適用しないことについての暴言を終わらせることの皮肉をよく知っています。残念ながら、私はこれを読んだリンクを失いました。Glenn Vanderburgは、Lone Star Ruby Conference2010での「RealSoftwareEngineering」の講演でもこれについて言及しましたが、AFAICRも、出典を引用していません。
誰かが情報源を知っているなら、私に知らせてください、または私の答えを編集してください、あるいは単に私の答えを盗んでください。（ソースを見つけることができれば、すべての担当者に値します！）
このプレゼンテーション（pdf）の42ページと43ページを参照してください。
残念ながら、状況はイェルクが描写しているとおりであり、実際にはやや悪化しています。引用された論文が独自の研究ではないか、主張を裏付ける言葉が含まれていないという意味で、この文書で引用されているほとんどの参考文献は私を偽物と見なしています。または-ヒューズに関する1998年の論文（p54）の場合-プレゼンテーションのp42の曲線によって暗示されるものと実際に矛盾する測定値が含まれています：曲線の形状が異なり、コストのx5からx10の適度な係数-要件フェーズと機能テストフェーズの間の修正（実際にはシステムテストとメンテナンスが減少）。
これまでピラミッドと呼ばれていることは聞いたことがありませんが、それは私には少し逆さまに思えます！それでも、中心的な論文は正しいと広く考えられています。アルファ段階でバグを修正するコストは、多くの場合、取るに足らないものです。ベータ段階までに、もう少しデバッグとユーザーレポートが必要になる場合があります。出荷後は非常に高額になる可能性があります。まったく新しいバージョンを作成する必要があります。本番環境のコードとデータが破損することを心配する必要があります。バグが原因で売上が失われる可能性もありますか？
この記事を試してください。とりわけ、「コストピラミッド」引数（名前を付けない）を使用します。
