1

私は主に、コードの可読性を欠陥の削減に関連付けるコード メトリクスのケース スタディに興味があります。ウィキペディアには次の例があります。

モジュールに含まれる欠陥の数に対する循環的複雑度の相関関係は、多くの研究で調査されています。そのような研究のほとんどは、循環的複雑さと欠陥との間に強い正の相関があることを発見しています。最も複雑なモジュールには、最も多くの欠陥も含まれる傾向があります。たとえば、メトリック監視ソフトウェアのサプライヤである Enerjy による 2008 年の調査では、オープンソースの Java アプリケーションのクラスを分析し、それらのアプリケーションで障害が検出される頻度に基づいて 2 つのセットに分類しました。彼らは、循環的複雑度とその欠陥性との間に強い相関関係があることを発見しました。複合複雑度が 11 のクラスが欠陥を起こしやすい確率はわずか 0.28 で、複雑度が 74 のクラスでは 0.98 に上昇しました。

これは良いことですが、他にも研究があるかどうか知りたいです (または、SLOC などの他の指標について同様の研究があるかもしれません)。

CC 値の監視を促進するIBMの記事も見つけましたが、ROI の数値を示すケーススタディのサポートがありません。次に、「矢印コード」に関するコーディング ホラーの記事があります。これは、ケース スタディの概要を示していますが、ケース スタディ自体も、結論を正当化した実際の数値も提供していません。

調査によると、プログラムの循環的複雑度とエラー頻度との間に相関関係があることが示されています。サイクロマティックな複雑度が低いと、プログラムが理解しやすくなり、より複雑なプログラムよりもリスクが低く変更しやすいことを示します。モジュールの循環的複雑度も、そのテスト可能性の強力な指標です。

確かに循環的複雑度 (CC) はアローコードの特定に役立ちますが、ROI 値を示すケーススタディが必要です。たとえば、「組織 X はメソッド/機能に最大 10 の CC を組み込み、次の開発イテレーションで欠陥を 20% 削減しました。」

この種のデータがなければ、経営陣に注意を向けさせるのは困難です。誰かが私にいくつかの難しい研究を教えてもらえますか? 一人でも助かる…

4

3 に答える 3

1

「...ROI 値を示すケース スタディが必要です。」

ROIはなぜ難しいのですか？

理由は次のとおりです。

個々のプログラマーの生産性は、少なくとも 1 桁、場合によっては 2 桁異なります。

http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx

個人差は、あなたが探している他のどんな効果よりも勝ります。「真っ向から」、「リンゴ同士」の比較はできません。異なる手法 (つまり、異なる複雑さのしきい値) を使用する 2 つの類似したチームを比較すると、個々のパフォーマンスの違いが単にデータを支配し、ほとんどすべてがノイズであることがわかります。

「そのようなデータがなければ、経営陣に注意を向けさせるのは困難です。」

経営陣が品質を気にしない場合、大きな問題が発生します。ROI の数値が経営陣に影響を与えて環境を変えることはありません。

独自の組織で独自のコードに対して独自の実験を実行する必要があります。

サイクロマティックな複雑さ、欠陥率、問題チケット、クラッシュなど、可能な限りの情報を収集します。複雑さを他の悪い指標と関連付けてみてください。チームのメンバー間の個人差を指摘することで、議論好きなマネージャーは常に勝つことができます。

実際の組織で実際のデータを使用します。それがあなたにできる最善のことです。そして、それは「何らかの研究」や「何らかのホワイトペーパー」ではなく、実際の組織です。

于 2010-07-21T19:38:02.230 に答える
0

この場合、ウィキペディアの記事よりも元の記事の方が少し多く得られます。データ収集などに関する彼の技術論文は、結論に 95% の信頼度を示しています。

これがROI情報を直接提供しないのは正しいです。少なくともこの調査では、それはかなり難しいでしょう。たとえば、彼らはトレーニング データにオープンソース プロジェクトを使用しており、オープンソース プロジェクトの実際のコストは通常​​、見積もることも測定することもはるかに困難です。同時に、彼らは真の ROI データの少なくとも妥当な代用物と私が考えるものを使用しました。彼らは、修正に関連していると思われるチェックインを探して、「トレーニング」プロジェクトごとにソース管理システムを検索しました。次に、ナイーブ ベイズ アルゴリズムを使用して、使用したメトリックとコードで特定された問題との相関関係を見つけました。間違いなく、少なくともいくらかの改善が期待されていますが、これらの結果は少なくとも何かを意味するはずです.

また、この調査を行った同じ人々が、多数のオープンソース プロジェクトの実行中のインデックスを保持していることも注目に値します。確実なデータがさらに必要な場合は、それらのプロジェクトのいくつかのソース管理ログに対してインデックスをチェックすることができます。おそらくそれらのデータを使用して、直接的な ROI タイプの結果をさらに引き出すことができます。ただし、1 つ注意してください。彼らのインデックスは、循環的複雑度だけでなく、かなりの数のソース コード メトリクスに基づいているため、彼らが見ている他のメトリクスとは対照的に、CC だけについてどれだけのことを正確に伝えているかはわかりません。

于 2010-07-21T20:18:01.023 に答える