プロジェクトの最後にバグを修正するのはかなり費用がかかりますか？

でアンドリュー・ヘイにより、ブログ記事、以下の公理を仮定しました。

プロジェクトの最後に同じバグを修正するよりも、プロジェクトの最後にバグを修正する方が大幅にコストがかかります。

しかし、特にLess Wrongのブログ投稿を読んだ後、これは確実ではないようで、私がそれをバックアップするのを見たデータは非常に古いです。

これは今日でも公理は正確ですか？

私が今まで見た唯一のハードデータは、Boehm and Papaccio、Understanding and Controlling Software Costsです。

これは1988年に遡り、約80のソフトウェアプロジェクトの研究でした。彼らは、決定が早期に行われ、遅く修正された場合、早期に修正された場合の50〜200倍の費用がかかると結論付けました。しかし、彼らが話している非常に早期の決定は、どのOS上で実行するか、どの言語とデータベースを使用するかということです。

そのため、これらの数字は、今日のソフトウェア開発に関しては過剰なものになる可能性があります。しかし、今では私たちはこの分野で多くの経験を積んでおり、それが今でもある程度当てはまることを本能的に知っています。

極端な場合、実稼働に移行する直前に要件の失敗が検出されると、多くの手直しが発生し、プロジェクトが遅延するか、実際にキャンセルされることがわかります。作業が完了する前に検出された場合、大丈夫だった。

編集：Doc Brownはコメントで良い点を指摘しています。

Boehmの研究は、コンパイルおよび実行時間が途方もなく遅かった時代に、COBOLおよびFORTRANプロジェクトで行われました。私はCOBOLで90年代前半にキャリアを開始しました。コンパイルとテストのサイクルに時間がかかりすぎたため、サイクルを実行する前に（または、少なくともビルド段階で、念のためにコードをドライテストする価値がありました）何かをキャッチし、それを早めにキャンセルして、1時間ほど節約できます）。

順番に、私たちの上司は私たちの苦情を笑いました。なぜなら、彼らは手作業で並べられたパンチカードの箱をサーバールームに運び、1日そこに残さなければならなかったのがそれほど昔ではなかったからです。

だから、それは間違いだった、よりそれが今よりも、その後真。

それでも、ごく最近、この問題が実際にハードナンバーに基づいているかのように、Steve McConnellによるこの問題の視覚化（1996年参照）を再利用しているブログを見てきました。そうではありません。それは視覚化であり、彼の主張を簡単に説明しています。

OPが引用した記事のMorendilの前提は良いものだと思います。このテーマに関する科学は貧弱で時代遅れであり、それでもキヤノンとして扱われています。しかし、私は苦い経験から、少なくともある程度まではまだ真実であることがわかっているので、それはうまく保持され、真実に聞こえると思います。そして、彼の劇的な「病気の規律」のフレージングは​​彼に好意的ではないと思います。

この主張を裏付ける確かなデータやその他の証拠は知りませんが、最低限、それは常識だと思います。

このように考えてください。相互依存サブシステムを備えた複雑なシステムを使用している場合（ほとんどの非自明なアプリケーションがそうであるように）、いずれかのシステムに対する変更の結果である可能性のあるノックオンの問題について考えてください。サブシステムが（ユニットテストなどを介して）正しいことが証明され、早期に修正された場合、ノックオンのみによって引き起こされるバグの数は、早期に修正するだけで軽減されます。

また、バグを早期に修正する場合、実装は開発者の心にまだ新鮮です。与えられたプロジェクトの長さに応じて、最後にバグを修正する場合、開発者は自分が書いたものと（おそらく）コードが依存するサブシステムがどのように機能するかを理解するのに時間を費やす必要があります。これを再学習するのに費やした時間= $。

これを科学的に厳密に測定する方法を考え出すことはまったく不可能だと思います。他にも多くの要因が関係しすぎており、ケーススタディ以上のものとして機能するほどの比較可能なプロジェクトはありません。論理的思考はあなたに長い道のりをもたらすはずです。いくつかの引数：

• プロジェクトのコードの総量は、終わりに向かって増加する傾向があります。バグの修正を待つ時間が長いほど、触れる必要のあるコードベースが大きくなります。
• プロジェクトに追加される新しいコードの品質は、少なくともプレッシャー（通常は与えられている）がある場合は終わりに向かって低下します：迫り来る締め切りにより、人々は時間通りに出荷するためにベストプラクティスを船外に投げ出します。これは、後でバグを修正するほど、より悪いコードをふるいにかけなければならないことを意味します。
• コードの複製は一般的に眉をひそめられますが、それは常に起こります。コピー＆ペーストは簡単ですが、重複したコードセクションを再マージするのは難しいため、コピー＆ペーストされたコードの量は通常、プロジェクト。コピーペーストされたコードが多いほど、バグが複製され、数回発見して修正する必要がある可能性が高くなります（したがって、その発生の一部が気付かれない可能性が高くなります）。
• バグの修正はコードベースの変更です。物事を改善したいと考えていますが、変更には常にリスクが伴います。数か月先のプロジェクトで深刻な問題を引き起こす変更は、損傷管理のための十分な余裕を残すべきですが、出荷の2日前には深刻な問題が発生します。
• バグ自体が長く存在するほど、アプリケーションの他の部分がその動作に依存し始める可能性が高くなります。それを修正すると、関数がドキュメント化された正しい結果を実際に提供することを期待していないコードの突発的なバグの束を突然解き放ちます。

これはシステムエンジニアリングから受け入れられた基本的なものであり、あらゆる形態の技術開発（橋、ミサイル、戦艦、ソフトウェアの構築など）に適用されます。

基本的に、開発の段階を進むにつれて、物価はおよそ1桁上昇します。

アイデアを思いついた時点で修正に10ドルかかるもの...

仕様を更新する必要がある場合、約100ドルかかります。

または、何かが実装されていて、その時点で変更を加える（および仕様を更新し、承認を取得するなど）必要があるが、何らかの正式な承認/売却テストを受けていない場合、約1000ドルかかります

または、何かが実装され顧客が受け入れた場合、約10000ドルの費用がかかり、その時点で変更を加える必要があります（そして仕様を更新し、承認を取得し、顧客の受け入れと資格を再テストして再実行するなど）

そして、導入/展開/サービス投入後のコストはさらに大きくなります。

例はたくさんあり、それらを理解するのは簡単です：25,000人の従業員がそれを使用した後に行われた深刻なスコープ変更を伴う銀行システムは、スコーピング、コーディング、テスト、リグレッション、などなど

当然のことながら、走行距離は異なります。フレッドナークの電子靴下加温eコマースWebサイトを変更するコストと影響は、航空機の飛行制御コンピューターのソフトウェアを変更するコストとは多少異なります。

ハードデータやファクトにアクセスできないため、ITでの過去20年間から収集した逸話的な観察結果のみを提供できます。

20年前と比較して、今日のほとんどの開発者がソフトウェアを作成する方法には大きな違いがあると思います。特に過去5〜6年でアジャイル運動が勢いを増してきたので、職場の態度に真の変化が見られました。私たちがしていることの質は、毎年飛躍的に伸びており、プロジェクトごとに学んだ教訓を適用するたびにすべてのプロジェクトで成長しているようです。テストファースト開発に焦点を合わせたリーナープロセスは、非常に物議を醸すものから一般的なものに成長しました。あまりにも多くのことで、今日多くの企業に足を踏み入れるために、もしアジャイルに慣れていないなら、彼らがあなたにドアを見せなければ幸運になるでしょう。

したがって、これはどのような影響を与えましたか。まず第一に、私は問題がしばしばずっと早く特定されることに気づきました。多くの場合、問題があまりに大きくないと思われる場合は、無期限に保留にすることができます。まれに、ごく少数の基本的な問題が明らかになり、その時点では考慮されていなかったため、些細な問題と考えられていたバグが深刻な問題になることがありました。これにより、修正サイクルが引き出される場合があり、ある程度のコストがかかる場合がありますが、そのコストは、リソースの観点からは少なく、多くの場合、顧客と開発者の関係への影響の観点から測定されます。顧客はこのアジャイルの考え方に慣れてきており、昔よりもはるかに速く結果を顧客に返しています。非常に反復的な開発スプリントとリクエストと実装間の迅速な転換により、彼らは私たちの多くを期待するようになりました。また、実際のバグに関する限り、変更をサポートするための一連の堅牢なテストと、洞察とソリューションを提供する新しいテストを作成する機能により、バグを修正する時間が大幅に短縮されます。報告された問題に。

したがって、全体として、堅牢なテストスイートが用意されていれば、ほとんどの場合、バグを修正するための全体的な労力が削減されているように見えます。いくつかの点で、少なくとも実装からビジネスの他の分野に一部シフトしました。なぜなら、いくつかの点で、純粋な需給から関係管理に焦点が移ったからです。

もう1つ明らかになったのは、数年前の私たちの直感は、アジャイルであるとメンテナンスサイクルが短縮されることを示唆していることであり、ある程度善と悪の両方が証明されています。確かに、堅実なテストによってコードのデバッグと修正が大幅に容易になり、本番コードにリリースされるバグの数を全体的に減らすことができました。常にコードをリファクタリングし、アーキテクチャを改善することでレガシーコードを維持し、新しい製品をゼロから完全に開発する必要が少なくなるようにします。

最後に、OPの質問に関してこれはどういう意味ですか？まあ、それは答えが本当に私たちがかつてそれがそうであると思ったかもしれないほどカットアンドドライではないことを意味します。15年前には、おそらく「はい」として質問に答えていたでしょう、しかし、私はソフトウェアを開発するために行うことの性質が最初にOPの質問を始めたときから大きく変わったので、経験的に測定することは本当に難しいと言うのがより現実的だと感じています。ある意味では、業界としての技術とスキルを向上させるほど、問題は決定的な「はい」から、数年後には重要ではないと言うポイントにさらに大きくなります。バグを修正するとき、テストとプロセスが非常に堅牢になるため、予算を節約するための努力によってバグ修正のタイミングが左右されず、顧客のニーズを満たすための優先順位によって、そして相対的なコストが文脈上事実上無意味になります。

しかし、私が言うように、これはデータに裏付けられた確固たる証拠ではなく、過去数年間の私の観察であり、私たちの物事のやり方を改善する、これから地上を揺るがす知恵が来ると私は言っています。

初期のバグはシステムの他の部分に伝播するため、バグを修正すると、バグ自体に依存するシステムの一部を書き直すことを余儀なくされる場合があります。

時間が経つにつれて、プログラムの一部がどのように構築されるかが気になり、自分自身に思い出させる必要があります。それは何らかの形の技術的負債です（プロジェクトを早い段階で急いでいると、取ったショートカットのためにプロジェクトを完了するのに問題が生じます）。

それと同じくらい簡単で、証明するものは何もありません。

従業員に何らかの実用的なソリューションを提供するために、できるだけ早くプロジェクトを急いでいると思います。良いニュースは非常に速く、悪いニュースはできるだけ早くがらくたを書き続け、数か月以内にすべてを修正することを計画している場合、おそらく完全な書き換えなしでそれを終えることはないということです。おそらくこれをリファクタリングすることさえできないでしょう。

まあ、私はおそらくあなたにあなたが求めている決定的な証拠を与えることはできませんが、私は私の仕事からかなり最近の事件を関連付けることができます。

製品にワークフロー管理機能を提供する機能を追加しました。典型的なBDUFのもの、仕様は承認され、クライアントによって承認されました。仕様に実装。展開に関する初日からの苦情。

クライアントとの本当の使いやすさのウォークスルーは行わず、彼らが望んでいることを彼らの言葉で伝えました。結果：数百時間の手直し-分析、設計、実装、QAをやり直す必要がありました。仕様が特定のユースケースを逃したためです。仕様のバグです。

チェーンの誰かがエンドユーザーの仮定とは異なる仮定をするとき、以前の仕事で似たようなことを見てきました。ストレートアップコーディングのバグは、発生時に近くでキャッチされた場合、比較的簡単に対処できますが、設計上のバグはシステム全体を殺す可能性があります。

リリース後にバグを修正する場合、バグを見つけて修正するコストがかかります。リリース後の処理にもっと時間/コストがかかる場合とそうでない場合があります。ただし、考慮する必要がある統合テスト、回帰テスト、UAテスト、リリースアクティビティなどのラウンドがあります。バグ修正が他の多くの修正またはバージョン更新と一緒に行われない限り、初期リリースに修正を含めることで回避できるテストおよびリリースアクティビティに追加の費用がかかります。修正/更新/機能。

また、バグが使用中に発生するコストを考慮してください。見かけだけであれば、おそらく問題ではありませんが、機能またはパフォーマンスのバグは、サポート活動や生産性の低下、または誤った計算でコストを発生させる可能性があります。

Pentium Bugにかかる費用をIntelに尋ねてください。Ariane5 Rocketも良い例です。これらのバグは、プロジェクトの最後に修正されました。ソフトウェアリリースでの「試行」の予算が6桁のシステムで作業しました。これらの極端な場合、コストを確認するのは簡単です。他の（ほとんどの場合）場合、コストはノイズに隠れますが、それはまだあります。

バグが存在している間はお金がかかることは間違いありません。1つの項目、Defectレポートでは、コンパイル、トリアージ、クローズに時間がかかります。時間はお金です。したがって、オープンバグは継続的なコストを生み出します。したがって、バグ修正の延期は、修正を早めるよりもコストがかかるということです。

バグが野生に逃げた場合、コストは段階的に上昇します......「プロジェクトの終わり」はソフトウェアのリリースの前ですか、それとも後ですか？

私はかつて2つの興味深い点がある記事を読みました（残念ながら、私が持っていた参考文献はなくなっているので、ここで仮定する必要があります）。彼らがした最初のポイントは、すべてのエラーの約50％が要件仕様に導入され、すべてのエラーの約90％がUATまたはシステムテスト中に見つかったということでした。

2つ目のポイントは、Vモデルの各フェーズでコストが10倍に増加したことです。要因が正しいかどうかに関係なく、私はある種の無関係なものを見つけますが、最も費用のかかるエラーは、設計が誤った仮定に基づいている場合です。これは膨大な量の書き換えにつながります。その仮定のために機能するが、正しい仮定が適用されたときに失敗するすべてのコードは書き直さなければなりません。

要件の仕様に1つの誤った仮定があるため、ドメインモデル全体を書き直す必要がありました。そのようなバグが早期に発見された場合、つまり要件仕様を確認する際のコストは非常に低くなります。この特定のケースでは、10行のテキストが必要です。UAT中に見つかった場合（これがそうであったように）、コストは実質的です（指定された例では、プロジェクトコストは50％増加しました）

統計データはありませんが、個人的な経験：

私が取り組んでいたロケットモーター制御コードには、次のような行がありました powerCutoff = someCondition && debugOptions.cutoffIsAllowed;。デフォルトのオプションでは、カットオフは許可されていませんでした。「最終」ビルドはすべてのデバッグオプションを削除することになっていたため、行はに変更されましたpowerCutoff = someCondition;。

コードレビュー中にバグをキャッチしましたか？しませんでした。テストでトリガー条件が最初に発生して予期しないカットオフが発生したのは、最初の飛行のわずか数か月前でした。

このバグは、レビュー中に発見された場合、1時間未満で済みます。統合中に検出された場合、1〜2日かかり、テストが1回繰り返されます。正式な認定中にキャッチされた場合、新しいビルドで一連のテストを完全に再起動することにより、1〜2週間かかる可能性があります。

ありのままに、コストは膨れ上がりました。最初に、テストを設計および実行して、フライトユニットが条件をトリガーできるかどうかを判断しました。本当の可能性があると判断された後、最適な修正のエンジニアリング、管理、および顧客分析、新しいビルドのリリース、新しい回帰テスト計画の作成と実行、複数のユニットとシミュレーターでのシステムテストにコストがかかりました。総じて数万時間ではないにしても数千時間かかります。さらに、実際の正しいコード変更を行うための元の15分。

悲しいことに、多くのものと同様に、それは依存します。

ダイアログメッセージのつづりが間違っている場合、修正（文字列の更新、再構築/パッケージ化、再展開）するのは「簡単」です。または、レイアウトの更新が必要な場合は、.cssファイルを修正するだけで十分な場合があります。

バグが、100以上のページ仕様と証明を持つ重要なメソッドの出力が間違っている場合、調査自体に数時間または数日かかることがあります。これは、古い「公理」が指すものであり、とりわけ、TDDとアジャイルが回避しようとしているものです（早期に明確に失敗し、安全な漸進的進歩を行う、やだ）。

単一プロジェクトでのマルチスクラムチームでの最近の経験から、「バグ」は通常、機能ブランチが安定版に昇格するときにリリースの終了時にのみ発生するマージ/統合の問題です。チームが自分の目標を達成するために急いでいる間、競合はしばしばチーム間のサポートを必要とするため、これらは最悪です。リリースですが、可能な限り早い時期に。それが彼らを最悪にしているのです。