私はこれを、私が見つけているもののほとんどが1970年代から1980年代初頭に由来しているという事実を前置きするつもりです。この間、シーケンシャルプロセスモデルは、反復および/または増分アプローチ（スパイラルモデルまたはアジャイル手法）よりもはるかに一般的でした。この作業の多くは、これらのシーケンシャルモデルに基づいています。ただし、関係が破壊されるとは思わないが、反復/増分アプローチの利点の1つは、機能（アプリケーションの垂直スライス全体）を迅速にリリースし、依存関係が注入されて各フェーズの複雑さになる前に問題を修正することですは高い。
私はちょうど私のコピー引き出さソフトウェア工学経済学を MEフェイガン（で彼は、「プログラム開発における誤差を低減する設計とコードの検査」を引用し、第4章では、このチャートの背後にあるデータへの参照を見つけたIEEE、UMDからPDF）、EB Dalyの「ソフトウェアエンジニアリングの管理」、WE Stephensonの「Safeguard System Software Developmentで使用されるリソースの分析」（ACM）、および「いくつかのTRWプロジェクト」。
...修正または変更が行われるフェーズの関数としてのソフトウェアエラーの修正（または他のソフトウェアの変更）の相対的なコスト。計画と要件の段階でソフトウェア要件エラーが検出および修正された場合、その修正は要件仕様を更新する比較的簡単な問題です。同じエラーがメンテナンスフェーズまで修正されない場合、修正には、仕様、コード、ユーザーおよびメンテナンスマニュアル、およびトレーニング資料のはるかに多くのインベントリが含まれます。
さらに、後期修正には、はるかに正式な変更承認および管理プロセス、および修正を再検証するためのはるかに広範な活動が含まれます。これらの要因を組み合わせることで、大規模プロジェクトの保守フェーズでは、要件フェーズよりも通常100倍のコストでエラーを修正できます。
ボヘムはまた、2つの小規模で形式的なプロジェクトを検討し、コストの増加を発見しましたが、大規模なプロジェクトで100倍になったよりもはるかに重要ではありませんでした。グラフを見ると、システムが稼働した後の要件の欠陥を修正するために、要件フェーズよりも4倍の違いがあるように見えます。彼はこれを、プロジェクトを構成するアイテムのより小さなインベントリと、より単純で修正された実装をより速く実装する能力につながった減少した形式に起因した。
Software Engineering EconomicsのBoehmに基づくと、Code Completeの表はかなり肥大化しています（範囲の下限が高すぎることがよくあります）。フェーズ内で変更を行うコストは実際1です。ソフトウェアエンジニアリング経済学の図4-2から外挿すると、要件の変更は、アーキテクチャで1.5〜2.5倍、コーディングで2.5〜10、テストで4〜20、4〜メンテナンス中100。量は、プロジェクトのサイズと複雑さ、および使用されるプロセスの形式に依存します。
バリーベームの付録Eおよびリチャードターナーの「俊敏性と規律のバランスをとる」には、変化のコストに関する経験的な調査結果に関する小さなセクションが含まれています。
冒頭の段落では、Kent BeckのExtreme Programming Explainedを引用し、Beckを引用しています。時間の経過とともに変化のコストがゆっくりと上昇した場合、可能な限り遅く決定が行われ、必要なものだけが実装されると書かれています。これは「フラットカーブ」と呼ばれ、エクストリームプログラミングを推進します。しかし、以前の文献で発見されたのは、5：1の変化を持つ小さなシステム（<5 KSLOC）と100：1の変化を持つ大きなシステムの「急カーブ」でした。
このセクションでは、メリーランド大学の経験に基づいたソフトウェアエンジニアリングセンター（国立科学財団主催）を引用しています。彼らは利用可能な文献の検索を実行し、結果は100：1の比率を確認する傾向があり、一部の結果は70：1から125：1の範囲を示していることがわかりました。残念ながら、これらは通常「前もって設計された大きな」プロジェクトであり、順番に管理されていました。
Extreme Programmingを使用して実行される「小さな商用Javaプロジェクト」のサンプルがあります。各ストーリーについて、エラーの修正、新しいデザイン、およびリファクタリングの労力が追跡されました。データは、システムが開発されるにつれて（より多くのユーザーストーリーが実装される）、平均的な努力が重要な割合で増加する傾向があることを示しています。リファクタリングの努力は約5％増加し、努力の修正に向けた努力は約4％増加します。
私が学んでいるのは、システムの複雑さが必要な労力に大きな役割を果たすということです。システムに垂直スライスを構築することにより、複雑さを山に追加するのではなくゆっくりと追加することで、曲線の速度を遅くします。非常に複雑な要件、非常に複雑なアーキテクチャ、非常に複雑な実装などの複雑な要件を処理するのではなく、非常に簡単に開始して追加します。
これは修正コストにどのような影響がありますか？結局のところ、おそらくそれほど多くはありません。ただし、（技術的負債の管理を通じて）複雑さをより細かく制御できるという利点があります。さらに、頻繁にアジャイルに関連付けられる成果物は、プロジェクトがより早く終了する可能性があることを意味します-「システム」を配信するのではなく、ビジネスニーズが満たされるか、新しいシステム（したがって新しいプロジェクト）が大幅に変更されるまで、作品が配信されますが必要です。
Stephen KanのSoftware Quality Engineeringのメトリックとモデルには、第6章にフェーズ欠陥除去の費用対効果に関するセクションがあります。
彼は、Faganの1976年の論文（Software Engineering Economicsでも引用）を引用して、高レベルの設計（システムアーキテクチャ）、低レベルの設計（詳細設計）、および実装が10から100倍安くなることを述べていますコンポーネントおよびシステムレベルのテスト中に行われる作業よりも。
彼はまた、1982年と1984年のFreedmanとWeinbergによる大規模システムについての2つの出版物を引用しています。1つ目は「ウォークスルー、検査、技術レビューのハンドブック」で、2つ目は「レビュー、ウォークスルー、検査」です。開発サイクルの早い段階でレビューを適用すると、テストフェーズに到達するエラーの数を10分の1に減らすことができます。欠陥の数を減らすと、テストコストが50〜80％削減されます。私は研究をより詳細に読む必要がありますが、コストには欠陥の発見と修正も含まれているようです。
Remusによる1983年の調査「検査/レビューの観点からの統合ソフトウェア検証」では、カリフォルニアのIBMのサンタテレサ研究所のデータを使用して、さまざまなフェーズ、具体的には設計/コード検査、テスト、およびメンテナンスで欠陥を除去するコストを調査しました。引用された結果は、1：20：82のコスト比を示しています。つまり、設計またはコード検査で見つかった欠陥の変更コストは1です。同じ欠陥がテストに逃げた場合、20倍のコストがかかります。IBMのミネソタ州ロチェスター施設からのサンプルデータを使用して、KanはAS / 400プロジェクトの欠陥除去コストが類似していることを発見しました。 1:13:92に。しかし、彼はコストの増加は欠陥を見つけるのが難しくなったためかもしれないと指摘しています。
Gilbの1993年（「ソフトウェア検査」）および1999年（「ソフトウェアエンジニアリング仕様と品質管理プロセスの最適化」）のソフトウェア検査に関する出版物は、他の研究を裏付けるために言及されています。
追加情報は、欠陥修復コストの増加に関するConstruxのページに記載されている場合があります。Code Completeの著者であるSteve McConnellがConstruxで設立され、働いていることに注意してください。
私は最近に耳を傾け話、本物のソフトウェアエンジニアによって与えられ、グレンVanderburgで2010年に彼の与えられた同じ話でローンスタールビー会議でスコットランドのRuby会議とErubycon 2011年、2012年のQConサンフランシスコ、とオライリーソフトウェアアーキテクチャ会議2015年。Lone Star Ruby Conferenceだけを聞いたことがありますが、彼のアイデアが洗練されたため、話は時間とともに進化しました。
Venderburgは、この履歴データのすべてが、プロジェクトが段階を経るのではなく、時間の経過とともに欠陥を修正するコストを実際に示していることを示唆しています。前述の論文や書籍で検討されたプロジェクトの多くは、フェーズと時間が一緒に移動する連続した「ウォーターフォール」プロジェクトでした。ただし、反復プロジェクトおよび増分プロジェクトでも同様のパターンが発生します。1つの反復で欠陥が挿入された場合、その反復で修正するのは比較的安価です。ただし、反復が進むと、多くのことが起こります。ソフトウェアがより複雑になり、特定のモジュールやコードの一部での作業に関するマイナーな詳細の一部が忘れられ、要件が変更されます。これらはすべて、欠陥を修正するコストを増加させます。
これはおそらく現実に近いと思います。ウォーターフォールプロジェクトでは、アップストリームの問題により修正が必要なアーティファクトの量が原因で、コストが増加します。反復および増分プロジェクトでは、ソフトウェアの複雑さが増すため、コストが増加します。