欠陥密度を測定する標準的な方法はありますか?オンラインのほとんどのサイトは、次のように測定する必要があると述べています。
number of defects discovered / the code size
私の質問は次のとおりです。
- 期間中に「修正された」欠陥は、発見された欠陥から差し引かれるべきですか?
- 時間の不足のために、次のリリースで修正することを決定した欠陥をどうすればよいですか?これらのバックログの欠陥を次のリリースの密度に追加する必要がありますか?
- 重複が多いためにコードが不必要に肥大化していることが証明されている場合、分母のKLOCはおそらく適切な尺度ではありません。それをどのように考慮すべきですか?
- 特定の期間のチャーン、および特定のモジュールの既存の欠陥のバックログを、チャーンの結果として作成/発見された欠陥の数に関連付けることができますか?
私たちの最終的な目標は、(a)欠陥密度を業界標準と比較し、(b)壊れやすくバグが多く、注意を払う価値のあるモジュールを特定できるようにすることです(c)一貫したメトリックを使用して、次のような傾向線を描くことができます。時間の経過に伴うモジュールの品質の向上