バグと元の開発に費やす時間はどれくらいですか？[閉まっている]

この質問は少し抽象的ですが、誰かが私を正しい方向に向けてくれることを望んでいます。

私の質問は、元の開発時間に関連するソフトウェアプロジェクトのバグにどれだけの時間を費やすことができるかです。膨大な数の決定要因が存在することを認識していますが、典型的なまたは平均的な内訳を望んでいました。

たとえば、プロジェクトAの完了に40時間かかり、さらに10個のバグを修正する場合、このプロジェクトの比率は4：1になります。

別のプロジェクト（B）が完了するのに10時間かかり、バグでさらに8時間かかる場合、比率は5：4になります。

これは文書化/研究された概念ですか？

更新

すべての有益な答えをありがとう。関係するすべての変数と環境要因のため、この種のメトリックに標準を設定することは不可能であることを理解しています。回答を割り当てる前に、このメトリクスに同意済みの名前があるかどうかを知りたいので、さらに調査することができます。メトリックを自分で生成するために必要な測定値を理解し、最終的にプロジェクトのベースライン標準を思い付くことができるポイントに到達したいと思います。

欠陥修正に割り当てられた総容量の平衡パーセンテージは、欠陥注入率に等しい。

もちろん、この率には多くの要因が影響します。チームが開発している製品の種類、チームが使用しているテクノロジーと技術的慣行、チームのスキルレベル、企業文化などです。

チームBを考慮して、完了した作業10ユニットごとに平均8ユニットのリワークを作成した場合、それらの8ユニットを作業すると、新しい6.4ユニットのリワークが作成されます。最終的に彼らが費やさなければならない総努力を、幾何学的進行の合計として見積もることができます。

10 + 8 + 6.4 + 5.12 + ...

バグの数は時間とともに指数関数的に減少しますが、チームBの指数には非常にゆっくりとゼロになる係数があります。実際、上記のシリーズの最初の3つの用語の合計は24.4だけです。最初の5つのうち33.6。最初の10、45の; シリーズ全体の50。したがって、チームBの要約：欠陥注入率0.8。機能開発、10/50 = 20％; 欠陥修正、80％。20/80は持続可能な容量の割り当てです。

対照的に、チームAははるかに良い形です。その進行は次のようになります。

40 + 10 + 2.5 + 0.625 + ...

このシリーズの合計は53 1/3であるため、チームAの機能開発割り当ては40 /（53 1/3）= 75％であり、欠陥修正割り当ては25％です。これは、10/40 = 0.25の欠陥注入率と一致します。 。

実際、最初の3つ以降のチームAシリーズのすべての用語は無視できるほど小さいです。これが実際的に意味することは、チームAはおそらく2、3のメンテナンスリリースですべてのバグをつぶすことができるということです。これは、どのチームでもそれができるという幻想も生み出します。しかし、チームBではありません。

デビッドアンダーソンの新しい本「かんばん」を読んでいるときに、この同等性について考えました。（この本は別のテーマになっていますが、品質の問題も扱っています。）ソフトウェアの品質について議論するとき、アンダーソンはCapers Jonesによるこの本を引用しています。

」... 2000年...北アメリカのチームのために測定されたソフトウェアの品質... 100個のファンクションポイントあたり3未満、1の200の範囲までのファンクションポイントあたり6つの欠陥の範囲であり、 中間点があたり約1欠陥であります0.6〜1.0の機能ポイント。これは、チームが欠陥の修正に90％以上の労力を費やすのが一般的であることを意味します。 "彼はバグの修正に90％を費やしている会社の同僚の例を挙げます。

アンダーソンが欠陥注入率からdeffix-fixing容量割り当てに至るまでの流さ（失敗の需要はその用語です）は、2つのことの同等性がソフトウェア品質研究者によく知られており、おそらくしばらくの間知られていることを示唆しています。

ここで提示しようとしている推論の行のキーワードは、「均衡」と「持続可能」です。持続可能性を奪う場合、これらの数字をごまかす明らかな方法があります。最初のコーディングを行ってから、別の場所のコードに進み、他の人にメンテナンスを任せます。または、技術的負債を使い果たし、新しい所有者に荷を下ろします。

明らかに、すべてのチームに適した特定の割り当てはありません。バグに20％を費やさなければならないと定めた場合、チームの欠陥挿入率が非常に低い場合、時間を埋めるのに十分なバグがないだけでなく、チームのバグが非常に高い場合、蓄積し続けます。

ここで使用した数学は非常に簡単です。取引コスト（計画と見積もりの​​会議、事後分析など）のようなものを無視しました。また、1つの製品を維持し、同時に別の製品を開発することをシミュレートする方程式も省略しました。しかし、結論は依然として有効です。ユニットテスト、継続的インテグレーション、コードレビューなどの技術的慣行の観点から、できる限りのことを行って、欠陥挿入率、ひいては障害の需要を減らします。10個の機能ごとに1つのバグしか作成できない場合、新しい機能を開発して顧客を満足させるための自由時間を十分に確保できます。

残念ながら、この比率は特定のプロジェクトで大きく変動すると思います。環境、言語、ツール、チームの規模、経験に大きく影響されます。

修正から得たものが投資したものよりも大きい場合にのみ、バグに時間を費やす必要があります。

次のようなマトリックスを使用します（水平-バグの修正に必要な時間、垂直-バグの種類-ユーザーへの影響）

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

問題の例：

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

マトリックスは、さまざまなレベルの重大度、労力、リスクなどでより複雑になる可能性があります

バグごとにランクを作成し、ランキングに基づいて修正することもできます。何かのようなもの：

Bug priority = Risk x Severity x Effort

*選択したスケールに応じて、一部のオペランドでは（1-x）になる場合があります:)

したがって、あなたの質問に答えるには：バグのタイプ、利用可能な時間/予算などに依存します。

チームの経験と品質、およびプロジェクトの難しさ（新しいOSカーネルとは別の標準Webアプリケーションを作成することと同じではありません）だけでなく、管理アプローチにも大きなばらつきがあります。使用します。

たとえば、ウォーターフォールモデルでは、最初のテストフェーズで最初のバグを正確に設定できますが、アジャイル環境では、機能が変更される可能性があるため、「これからバグを修正しています」という行を上げるのが難しい場合があります（私にとっては、機能の変更をバグとして数えることは公平ではありません）

経験から、私はそれが常に過小評価されているものであり、非常に簡単に「元のプロジェクト」と同じ時間を費やすことができると言います。

あなたのコードは完璧であるため、本当に正しい答えはバグ修正にゼロ時間でしょう。:-)

現実には、誰かがそのタイプの比率を求めたり提供したりするのを聞いたことはありません。それは、一部の企業が開発と保守の両方の時間を追跡していないということではありません。しかし、アプリケーションの開発はメンテナンスに比べて非常に短い時間枠であるため、ほとんどの企業はその比率を計算しません。彼らはおそらく、アプリがメンテナンスを必要とする理由を学び、それらの発見を新しいアプリケーションに適用することにもっと関心を持っています。

バグの基準が広すぎると、時間をほぼ2倍にできます。クライアントのボタンを大きくする要求（マウスの問題がある）を考える熱心なマネージャーは、修正したバグの数を増やすのに最適な方法です。パッチを検討、テスト、再コンパイル、および配布する必要がないため、修正に数秒しかかかりません。ああ、それは新機能として二重にカウントされます。

これの最大の決定要因は、新しいテクノロジーを使用しているか、既存のテクノロジーを使用しているかです。何か新しいことに取り組んでいて、さまざまな状況で行われていない、または数回行われたものを開発している場合、バグ修正に多くの時間を費やし、プロジェクトを希望どおりに動作させることになります。頻繁にバグが発生するのは、自分自身を隅に追い込んだ結果であり、自分がしたことを再構築するにはかなりの量の作業を行う必要があります。さらに、多くのバグは、ユーザーの期待を完全に理解していないことや、開発者がエッジケースを認識していないことに起因します。

確立された技術に取り組んでいる場合、ほとんどの問題は図書館またはコミュニティの慣行によって対処されているため、発生したバグをグーグル検索、購入、または回避することができるはずです。

重要なソフトウェアでは、1：1の比率は珍しいことではありません。単体テストの場合、10行のコードごとに1日間の単体テストに言及する指標を見てきました。

この質問は偏っていると思います：それはバグを修正することは新しい機能を開発するよりもフェーズが似ているという前提から始まります。これはそうではありません。

優れた開発者は、コードに最初からバグがないため、コードのデバッグに多くの時間を費やすことはありません。悪い開発者は、実際の問題を解決するための適切な抽象化を作成できないため、コードのデバッグに多くの時間を費やします。

開発者は自分でコードを単体テストする必要があることに注意してください。バグのないコードを提供することは、彼らの仕事の責任です。したがって、コーディングをデバッグから分離することは困難です。

優先事項でもあります。開発時、バグを修正するために必要な時間は、コードにバグを挿入してから過去に経過した時間と指数関数的に関連しています。したがって、バグを修正することは、新しい機能を開発することよりも優先されるべきです。

したがって、「バグに費やされた時間」について話す代わりに、「テストに費やされた時間」（統合テスト、ユーザー受け入れテスト...）について話すべきです。

私はあなたが正しいと思います-あなたは影響因子の数が多いため、意味のあるメトリックを取得するつもりはありません。

私が取り組んでいるプロジェクト（エンタープライズスペース、大規模で複雑なシステム、他のシステムとの多くの統合）の比率が約3：2であることがわかります。これらのほとんどは、コードの障害ではありません。より一般的には、インターフェイスの障害です。たとえば、システムAとBは、インターフェイスXを介して互いに通信します。システムAの開発者は、システムBの開発者とは少し異なるインターフェイスXを解釈します。コメディが続きます。

確認する必要があるのは、コードの開発とコードのテスト/バグ修正を2つの異なるフェーズにすべきではないということです。開発中にテストすると、バグ修正の「コスト」が少なくなります。

私は純粋に実用的な観点から、プロジェクトの実用的な有用性をさらに妨げているものは何ですか？既存の機能にバグがある場合は、バグを修正する必要があります。機能が欠落している場合は、元の開発を行ってから、最も深刻な欠落機能が実装されたら、戻ってバグを修正する必要があります。これには、ユースケースに精通している必要があります。奇妙なケースでプログラムをクラッシュさせるバグは、すべての人に影響を与えるマイナーなユーザビリティの強化よりも優先順位が低いかもしれません。最も一般的に使用される機能の小さな迷惑なバグは、ソフトウェアを極限まで押し進めている人々にのみ役立つ機能よりも重要かもしれません。