最大の費用対効果をもたらすバグの解決[終了]

解決がどれほど簡単か、そしてどれだけの利益が得られるかに基づいて、バグを分類する方法を知りたいと思っていました。たとえば、解決に1時間かかる（2つのファイルを閉じるなど）バグと、1日かかる別のバグ（セグメンテーションエラー）がある場合などです。ただし、最初のバグの解決がそれほど重要でない場合は、おそらく2番目のバグに取り組みます。

費用便益または類似の指標に基づいてバグを分類する研究論文はありますか？

たとえば、セキュリティの脆弱性、メモリエラー、論理エラーなど、バグの特性に基づいてバグを分類することができるとしましょう。他の次元では、難易度（簡単、中程度、難しい）などのパラメータがある場合があります。私が探しているべき他の次元はありますか？物事を単純化するために、私は2つのことを想定できます。

1. チーム内のすべてのプログラマーは、あらゆるバグを同等に解決することができます
2. 締め切りはありません

典型的なバグ追跡システムには、バグの費用便益比を特定する2つ、場合によっては3つのフィールドがあります。

1. 優先度（事業主が割り当て）
2. 重大度（バグの分類-重要度が低い）
3. 推定時間（実行にかかる時間の推定）

お気づきのように、これはどのバグが取り組むべき重要なバグかを識別します。

PEF / REV：多次元バグ追跡メトリックで提案されたシステムは、バグコストのメリットにビジネスコンポーネントと開発者コンポーネントに関する情報を追加します。

すべての値は1 .. Nのスケールです（それぞれに同じトップ値）。

PEFはビジネスによって識別されます。

• P ain-バグがどれほど痛いか
• Eの ffort -それはバグを回避するのにかかるどのように多くの努力
• Fの requency -どのくらいの頻度でバグが発生しました

REVは開発者からのものです。

• R isk-システムの修正はどれほど危険か
• Eは ffort -どのように多くの努力があったバグを修正することです
• Vの erifiability -それはバグ修正を検証する方法は簡単です

たとえば、簡単に回避できる（自動保存をオンにする）まれに発生するクラッシュがある場合、そのPEFは7,1,1（スコア9）になります。修正中は、コアモジュールの変更が含まれ、REVが9,3,2（スコア14）になる場合があります。

一方、些細な修正（1,1,3-スコア5）が常に存在する（3,3,9-スコア15）不快感を持つ可能性があります。

この例では、煩わしさは、費用対効果の点で優れています。

あなたが説明している問題は非常に一般的であり、最良の答えは「あなたの直感を使う」かもしれません。

私は通常、バグをCrashing、Annoying、Cosmeticの3つのカテゴリに分類し（1、2、3と呼ばれることもありますが、問題ではありません）、すべてのバグを修正するために必要な時間の全体的な見積もりを書きます（すべてのバグは常に大まかな更新された見積もりを持っています）。

バグを解決するとき、Crashing> Annoying> Cosmeticを選択してから、「最初に最短のジョブ」を実行して、できるだけ多くの初期スループットを取得します。

非常に厳密に範囲が定められた有給の仕事でない限り、バグを解決することで直接的な金銭的な利益を計算するのは非常に難しいと思います。

あなたが必要とするかもしれない一つのメモは、あなたは本当にジョエルテストの 5番目のポイントまで生きるべきであるということです-これは他の様々な「ローカル」問題間のチームサイズと分布に影響されるかもしれません-しかし、それは一般的に良い習慣のしるしです。

別の考慮事項は、バグと修正の影響とコストを決定しようとするときに、バグを明らかにするテストまたはテスト組織のタイプです。ユニットテストまたは機能テストは、変更が必要な設計の何かを指している可能性があるため、早期に修正する方が後ほど簡単でコストもかかりません。システムまたは統合テストは、さまざまな顧客に影響を与える何かを指摘する可能性があります。また、標準テストは、多くの場合、大部分の顧客にとって重要ではないものですが、修正しないと認証が失われ、ビジネスに悪影響を及ぼす可能性があります。

とはいえ、特定のテスト組織がテストに失敗したからといって、自動的にバグを「クリティカル」にするべきではありません。たとえば、「出荷前にすべてのシステムテストに合格する必要があるため、システムテストに失敗すると、自動的に重大/重大度の高いバグが発生する」のような言い方があるかもしれません。うまくいけば、どの組織もその声明を出さないでしょう（適切なテスト終了基準は別の議論です）が、重要なのは、バグの「重大度」は、場所や時期ではなく、顧客、製品、または企業イメージへの影響で判断する必要があるということです。は明らかにされています。

これに対処する1つの可能な方法は、「重大度」と「緊急度」を区別することです。たとえば、リリース日が近づくにつれ、重大度が明らかに低いバグが顧客の大部分に影響を与える可能性があるかどうかを判断するための時間的プレッシャーがあり、バグの「緊急性」が高まり、そのバグに対する作業が他の（一部の）上に上がる少なくともその決定ができ​​るまでは。両者の適切なバランスは、経験と適切な判断とともに、時間と労力が費やされる場所を指示するのに役立ちます。

バグの分類などについて他の人が言ったことに加えて、特定のバグが表す可能性のある重大度のレベルを決定するために求心性結合（Ca）を検討することも検討してください。Caカウントが高いモジュールにバグがある場合、システム内の他のコンポーネントに利益をもたらす可能性があるため、最初にそのバグを修正することを検討している可能性があります。Caは責任のレベルを判断するのに役立ち、バグが含まれている責任のあるモジュールがアプリケーション全体を傷つけます（Caについて詳しくは、こちらをご覧ください：http : //www.ibm.com/developerworks/java/library/j-cq04256/index.html）。

それを念頭に置いて、私たちはバグを分類し、顧客への影響に基づいてバグを優先する傾向があります。顧客はさまざまですが、彼らをディスカッションに参加させることで、最終的にはどのバグを他のバグよりも修正する必要があります。それは本当の科学的なものではありませんが、チーム全体として、バグの優先度と分類についてコンセンサスになりがちですが、誰もが「大きなバグ」（すべての利害関係者がインプットを提供することができます）について意見を述べ、そこから積み重ねます。

すべてのバグの実際のコストを特定することはできません。できるものもありますが、多くの場合、定量化は非常に困難です。たとえば、ボタンのすべてのテキストがわずかにずれているバグがあるとします。これにより、1.0製品が少しずさんに見えます。これによってプログラムがクラッシュしたり、ユーザーがデータを失うことはありません。おそらくかなり安いバグですよね？

さて、あなたのすべての顧客がこの問題に気づき、すべてのレビュアーがあなたの製品のレビューでそれを言及したらどうなるでしょう。そして、このバグがバージョン1.0から1.1および1.2に引き継がれた場合はどうなるでしょうか。あなたの会社は現在、品質管理において少しずさんな評判を持っているかもしれません。この単純なバグは、貴社の将来の製品の販売が失われる可能性の点でどれほど高価なものになるでしょうか？または、これが製品のレビューにどのように影響するか-製品は顧客のニーズを完全に満たしているかもしれませんが、少しずさんなように見えるため、10のうち9しか得られません。

したがって、特定のバグのコストを、修正にかかるコストとユーザーへの直接的な影響の観点から検討する必要があるだけでなく、製品の認識にどのように影響するかという大きなコンテキストで考慮する必要があります。市場で、そしてその認識が将来の売上にどのように影響するか。

これは遠くに見えるかもしれませんが、そうではありません。私がこれを書いている時点で、Appleがカレンダーアイコンの「1」を1〜2ピクセル上に移動した方法に関する記事が掲載されているWeb上の別のサイトにアクセスできます。検索を行うと、この小さな小さなバグに関する否定的な記事がいくつか表示されます。もちろん、これはAppleの収益に直接影響を与えるものではありませんが、優れたデザインの頂点として自らを宣伝しているため、デザインバグがあると、たとえわずかであっても、その認識に影響を与えます。