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


16

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

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

私の目標は

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

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


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


1
閉鎖を避けたい場合は、質問を再段階化する必要があります。Stack Exchangeサイトは検索エンジンではなく、ユーザーは個人のリサーチアシスタントではありません。論文へのリンクを求める代わりに、どのタイプのメトリックが欠陥および欠陥密度と相関しているかを尋ねることに重点を置く必要があります。
トーマスオーエンズ

1
質問が私の個人検索アシスタントになるためのリクエストとして出会ったことは残念ですが、それは間違いなく私がやりたかったことではありませんが、これらのタイプの論文を見つけることはあまり一般的ではありません。他の人が同じ印象を持たないように、タイトルを変更しました。
アウグスト

回答:


11

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

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

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

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

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

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

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


Halsteadメトリックはすべて、生のSLOC(コードのソース行の数)と強く相関していることが示されています。その時点で、Halsteadメトリックと相関するものはすべて生のSLOCと相関することが判明し、HalsteadメトリックよりもSLOCを測定する方が簡単です。
ジョンR.ストローム

@ JohnR.Strohm計算にツールを使用している場合、Halsteadメトリックを計算するよりもSLOCをカウントする方が簡単だとは思いません。Halsteadメトリクスが有効であると仮定すると(実際には議論されていますが、無効なメトリクスには何の問題もありません)、コードを開発するのに必要な時間またはシステム内の予測される欠陥の数を知ることは、量を知ることよりも有用な値です行の。時間データを使用してスケジュールを作成したり、欠陥データを使用して品質計画を作成したり、コードレビューに十分な時間を難なく割り当てることができます。これらのことに生のSLOCを使用するのは困難です。
トーマスオーエンズ

@ JohnR.Strohm Halsteadメトリック計算プログラムは、SLOCカウントプログラムよりも実行に少し時間がかかると確信しています。ただし、有効な出力が意思決定への有効な入力になると仮定すると、生のSLOCカウントよりも有意義な時間、労力、および欠陥データが必要です。より複雑なメトリックの追加値は、計算の有効な入力と有効な出力を再び想定して、多くの場合、追加の計算時間の価値があります。
トーマスオーエンズ

@ThomasOwens、ソフトウェアの労力、ひいてはコストとスケジュールは、生のSLOCの推定値から直接推定できるかどうかの問題は、死に至るまで行われました。実際のプロジェクトデータに関するかなりの調査の後、この問題は肯定的に解決されました。「ソフトウェアエンジニアリング経済学」、バリーベーム、1981
。-ジョンR.ストローム

@ThomasOwens:さらに、Halsteadメトリックは本質的に遡及的であることを認識する必要があります。まだ作成していないソフトウェアのHalsteadメトリックを測定することはできません。一方、特定のタスクの生のSLOCを推定することは可能であり、十分な詳細な仕様と少しの経験があれば、推定値にかなり近づくことは比較的容易です。さらに、推定値を実際の値と非常に簡単に比較して、推定値のヒューリスティックを微調整し、コスト推定値を調整できます。General Dynamics / Fort Worthは、1980年代初期にこれについて多くの作業を行いました。
ジョンR.ストローム

7

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

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

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

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

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

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

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


他の研究は相関関係を示しているため、下票には値しませんが、それは「相関関係を示さない研究もある」はずです。
デビッドハンメン

3

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.