コードメトリクスとバグ密度を関連付ける実験
コードメトリック（SLOC、Cyclomatic Complexityなど）をオブジェクト指向アプリケーションのバグ密度と関連付けるいくつかの実験を行った人がいるのではないかと思います。
私は相関関係を証明または反証するだけの実験を探しているのではなく、両方について実験しています。プロジェクトのバグ密度mightは特定のプロジェクトの1つまたは複数のメトリックに関連していると思うので、私は特効薬を見つけようとはしていません。チームと相関関係は、プロジェクト/チームの存続期間中に変更される可能性があります。
私の目標は
- 2〜3か月間、すべての興味深いメトリックを測定します（すでにソナーからかなりの数を取得しています）。
- 新しいバグの数と相関するメトリックを1つ見つけます。
- 根本原因分析を行って、これが発生する理由を確認します（たとえば、特定の設計スキルが不足していますか？）。
- スキルを向上させ、変更を2、3回繰り返し測定します。
- すすぎ、2から繰り返します。
これについての経験はありませんが、このテーマに関する論文/ブログをご覧になったことを覚えている場合は、共有していただければ幸いです。
これまでのところ、私はこの主題に関するいくつかの情報を含む次のリンクを見つけました
- バグは複雑なコードに存在しますか？ -プレゼンテーションのスライドのみ。
- 変更とバグ：マイニングと開発活動の予測 -プレゼンテーションからスライドするだけです。結論として、依存関係が多いほど、バグの可能性が高くなります（これはかなり一般的なルールだと思います）。
- 失敗は4文字の単語です -バグとメトリック間の相関関係に関するパラダイ。
あるタイプのコードベースのメトリックをソフトウェアの欠陥と関連付ける試みを聞くたびに、私が最初に考えるのは、McCabeの 循環的複雑度 です。さまざまな研究により、高度な循環的複雑度と欠陥数の間に相関関係があることがわかっています。ただし、（コードの行に関して）同じサイズのモジュールを調べた他の調査では、相関関係がない可能性があることがわかりました。
私にとって、モジュール内の行数と循環的複雑度の両方が、起こり得る欠陥の良い指標、またはモジュールに変更が加えられた場合に欠陥が挿入される可能性が高くなる指標として役立つかもしれません。高い循環的複雑度を持つモジュール（特にクラスまたはメソッドレベル）は、コードを介した独立したパスが多数あるため、理解するのが困難です。行数が多いモジュール（ここでも、特にクラスまたはメソッドレベルで）も、行数の増加はより多くのことが起こっていることを意味するため、理解するのが困難です。指定されたルールと循環的複雑度に対するコードの両方のソース行の計算をサポートする多くの静的分析ツールがあります。それらをキャプチャすると、ぶら下がっている果物をつかむようです。
Halstead複雑さの尺度 も興味深いかもしれません。残念ながら、それらの有効性はいくぶん議論されているように見えるので、私はそれらに依存する必要はないでしょう。 Halsteadの測度の1つは、労力または量に基づく欠陥の見積もりです（総演算子およびオペランドに関するプログラムの長さと、個別の演算子およびオペレーターに関するプログラム語彙の関係）。
CKメトリックと呼ばれるメトリックのグループもあります。このメトリックススイートの最初の定義は、ChidamberとKemererによるA Objects Suite for Object Oriented Designというタイトルの論文にあるようです。これらは、クラスごとの重み付けされたメソッド、継承ツリーの深さ、子の数、オブジェクトクラス間の結合、クラスの応答、およびメソッドの凝集の欠如を定義します。彼らの論文は、計算方法と、それぞれを分析する方法の説明を提供します。
これらのメトリックを分析する学術文献の観点から、Ramanath SubramanyamとM.S.によって作成されたオブジェクト指向設計の複雑さのためのCKメトリックの実証分析：ソフトウェアの欠陥への影響に興味があるかもしれません。クリシュナ。彼らは6つのCKメトリックのうち3つ（クラスごとの加重メソッド、クラス化されたオブジェクト間の結合、継承ツリーの深さ）を分析しました。ペーパーをちらっと見たところ、これらは潜在的に有効なメトリックであることがわかりましたが、「改善」すると他の変更が生じ、欠陥の可能性も高くなる可能性があるため、注意して解釈する必要があります。
Yuming ZhouとHareton Leungによって作成された、重大度の高い障害と低い障害を予測するためのオブジェクト指向設計メトリックの実証分析でも、CKメトリックを調べます。彼らのアプローチは、これらのメトリックに基づいて欠陥を予測できるかどうかを判断することでした。彼らは、継承ツリーの深さと子の数を除いて、多くのCKメトリックが、欠陥が見つかる可能性のある領域の予測にある程度の統計的有意性があることを発見しました。
IEEEメンバーシップをお持ちの場合は、 IEEE Transactions on Software Engineering でより多くの学術出版物を検索し、 IEEE Software で実際のレポートおよび適用レポートを検索することをお勧めします。 ACMの デジタルライブラリ にも関連する出版物がある場合があります。
私のブログ投稿 の1つで可能な相関について議論しました：
循環的複雑度とバグ密度の相関関係：これは本当の問題ですか？
答えはいいえだ。サイズを一定に保ちながら、 研究 は、CCと欠陥密度の間に相関関係がないことを示しています。ただし、他に2つの興味深い相関関係があります。
1つ目は次のとおりです。CCは、欠陥の検出と修正の期間と強く相関していますか？言い換えると、CCが低い場合、デバッグと欠陥の修正に費やす時間を短縮できますか？
2つ目は次のとおりです。CCは障害フィードバック率（FFR、1つの変更の適用または1つの欠陥の修正から生じる欠陥の平均数）と強く相関していますか？
この相関関係を経験的に研究したことがあるかどうかを調べるには、さらに調査が必要です。しかし、私の直感と、私が一緒に働くチームから得られるフィードバックは、一方のサイクロマティック複雑度と、もう一方の側の欠陥または変更の影響を検出して修正する期間との間に強い正の相関があるということです。
これは良い実験です。結果に注意してください！
著書「コードコンプリート」p.457で、スティーブマッコネルは「制御フローの複雑性は、信頼性が低く、エラーが頻繁に発生するため、重要である」と述べています。次に、McCabe自身（サイクロマティック複雑度メトリックを開発したとされている）を含む、その相関関係をサポートするいくつかのリファレンスについて言及します。これらのほとんどは、オブジェクト指向言語の広範囲にわたる使用に先行していますが、この測定基準はそれらの言語内のメソッドに適用されるため、参照はあなたが探しているものかもしれません。
それらの参照は次のとおりです。
- マッケイブ、トム。 1976年。「複雑さの測定」。ソフトウェアエンジニアリングに関するIEEEトランザクション、SE-2、いいえ。 4（12月）：308-20
- Shen、Vincent Y.、et al。 「エラーが発生しやすいソフトウェアの特定-実証的研究」。ソフトウェアエンジニアリングに関するIEEEトランザクションSE-11、No.4（4月）：317-24。
- Ward、William T.1989。「McCabeの複雑性メトリックを使用したソフトウェアの欠陥防止。」 Hewlett-Packard Journal、4月、64〜68年。
私の経験から、多くのコードセクションでプログラムによって計算できるMcCabeの測定基準は、複雑すぎてエラーを含む可能性が高いメソッドや関数を見つけるのに役立ちます。計算はしていませんが、高循環的複雑度関数と低循環的複雑度関数内のエラーの分布により、これらの関数を調査することで、見過ごされているプログラミングエラーを発見できました。