コードメトリックとバグ密度を相関させる実験

誰かがコードメトリックス（SLOC、Cyclomatic Complexityなど）とオブジェクト指向アプリケーションのバグ密度を相関させる実験を行ったかどうか疑問に思っています。

私は相関関係を証明または反証するだけの実験を探しているのではなく、両方で実験を探しています。私はプロジェクトのバグ密度がいることを信じているよう特効薬を発見するつもりはないよ可能性がある特定のプロジェクトやチームのための1つまたは複数のメトリックに相関と相関がプロジェクト/チームの存続期間中に変更することができます。

私の目標は

1. 興味深い指標をすべて2〜3か月間測定します（ソナーからはすでにかなりの数があります）。
2. 新しいバグの数と相関する1つのメトリックを見つけます。
3. 根本原因分析を行って、これがなぜ起こるのかを確認します（たとえば、特定の設計スキルが不足していますか？）。
4. いくつかの反復のスキルを向上させ、変化を測定します。
5. すすぎ、2から繰り返します。

これに関する経験はないが、このテーマに関する論文/ブログを見たことを覚えているなら、それを共有できれば幸いです。

これまでのところ、このテーマに関するいくつかの情報を含む次のリンクを見つけました

• バグは複雑なコードにありますか？-プレゼンテーションのスライドのみ。
• 変更点とバグ：開発アクティビティのマイニングと予測 -プレゼンテーションからスライドするだけです。要するに、依存関係が多いほど、バグが発生する可能性が高くなります（これは非常に一般的なルールだと思います）。
• 失敗は4文字の言葉です -バグとメトリックの相関関係に関するパラディ。

ある種のコードベースのメトリックをソフトウェアの欠陥に関連付ける試みを耳にするたびに、私が最初に考えるのは、McCabeの循環的複雑さです。さまざまな研究により、高い循環的複雑さと欠陥の数との間に相関関係があることがわかっています。ただし、（コード行の観点から）同様のサイズのモジュールを調べた他の研究では、相関関係がない可能性があることがわかりました。

私にとっては、モジュール内の行数と循環的複雑度の両方が、発生する可能性のある欠陥の良い指標、またはおそらくモジュールに変更が加えられた場合に欠陥が挿入される可能性が高くなります。循環的複雑度の高いモジュール（特にクラスまたはメソッドレベル）は、コードを通る独立したパスが多数存在するため、理解が困難です。行の増加はより多くのことが起こっていることを意味するため、多数の行を持つモジュール（特に、クラスまたはメソッドレベル）も理解するのが困難です。指定されたルールに対するコードのソース行と循環的な複雑さの両方の計算をサポートする多くの静的分析ツールがあり、それらをキャプチャすることで、ぶら下がっている実をつかむことができるようです。

ハルステッドの複雑さ対策はも面白いかもしれません。残念ながら、それらの有効性は多少議論されているように見えるので、私はそれらに依存する必要はありません。Halsteadの対策の1つは、作業量またはボリューム（合計演算子とオペランドの観点からのプログラムの長さと、別個の演算子と演算子の観点からのプログラム語彙との関係）に基づく欠陥の推定です。

CKメトリクスと呼ばれるメトリクスのグループもあります。このメトリクススイートの最初の定義は、ChidamberとKemererによる「オブジェクト指向設計のためのメトリクススイート」というタイトルの論文にあるようです。それらは、クラスごとの重み付きメソッド、継承ツリーの深さ、子の数、オブジェクトクラス間の結合、クラスの応答、およびメソッドの結合の欠如を定義します。彼らの論文は、計算方法と各分析方法の説明を提供します。

これらのメトリックを分析する学術文献に関しては、オブジェクト指向設計の複雑さに対するCKメトリックの実証分析：ソフトウェア欠陥への影響、Ramanath SubramanyamとMS Krishnaが作成したものに興味があるかもしれません。6つのCKメトリックのうち3つ（クラスごとの加重メソッド、クラス化されたオブジェクト間の結合、および継承ツリーの深さ）を分析しました。論文全体を見ると、これらは潜在的に有効な指標であることがわかったように見えますが、「改善」すると、欠陥の可能性を高める他の変更につながる可能性があるため、注意して解釈する必要があります

Yuming ZhouとHareton Leungによって作成された、高および低重大度の障害を予測するためのオブジェクト指向設計メトリックの実証分析も、CKメトリックを調べています。彼らのアプローチは、これらのメトリックに基づいて欠陥を予測できるかどうかを判断することでした。彼らは、継承ツリーの深さと子の数を除くCKメトリックの多くが、欠陥のある場所を予測する際にある程度の統計的有意性があることを発見しました。

IEEEメンバーシップをお持ちの場合は、ソフトウェアエンジニアリングに関するIEEEトランザクションでより学術的な出版物を検索し、IEEEソフトウェアで実際のレポートや応用レポートを検索することをお勧めします。ACMのデジタルライブラリには、関連する出版物がある場合もあります。

私は私のブログ投稿の1つで可能な相関について議論しました：

循環的複雑さとバグ密度の相関：これは本当の問題ですか？

答えはいいえだ。サイズを一定に保つことで、研究はCCと欠陥密度の間に相関関係がないことを示しています。ただし、他にも興味深い研究が2つあります。

1つ目は、CCは欠陥の検出と修正の期間と強く相関していますか？言い換えれば、CCが低ければ、デバッグに費やす時間を減らし、欠陥を修正することができますか？

2つ目は、CCはフォールトフィードバック率（FFR、1つの変更の適用または1つの欠陥の修正から生じる欠陥の平均数）と強く相関していますか？

誰かがこの相関関係を経験的に調べたことがあるかどうかを確認するには、さらに調査が必要です。しかし、私のチームの感覚とフィードバックは、一方のサイクロマティックな複雑さと、他方のサイドの欠陥または変更の影響を検出して修正する期間との間に強い正の相関があるということです。

これは良い実験です。結果に注意してください！

著書Code Completeの457ページで、Steve McConnellは、「制御フローの複雑さは、低い信頼性と頻繁なエラーと相関しているため重要です」と述べています。その後、彼はその相関関係をサポートするいくつかの参考文献に言及しています。McCabe自身（循環的複雑度メトリックを開発したことで有名です）も含まれています。これらのほとんどは、オブジェクト指向言語の広範囲な使用以前に存在していましたが、このメトリックはそれらの言語内のメソッドに適用されるため、参照はあなたが探しているものかもしれません。

これらの参照は次のとおりです。

• マッケイブ、トム。1976.「複雑さの尺度。」ソフトウェアエンジニアリングに関するIEEEトランザクション、SE-2、いいえ。4（12月）：308-20
• シェン、ビンセントY.、他 1985.「エラーが発生しやすいソフトウェアの特定-実証研究」。IEEE Engineering on Software Engineering SE-11、no.4（4月）：317-24。
• Ward、William T.1989。「McCabeの複雑度メトリックを使用したソフトウェア欠陥防止」。Hewlett-Packard Journal、4月、64〜68。

私自身の経験から、McCabeのメトリックは、多くのコードセクションのプログラムで計算できるため、複雑すぎてエラーを含む可能性が高いメソッドや関数を見つけるのに役立ちます。私は計算していませんが、高循環的複雑度関数と低循環的複雑度関数内のエラーの分布により、これらの関数を調査することで、見落とされたプログラミングエラーを発見することができました。