ソフトウェアの品質を決定するためにHalsteadの複雑さの測定を適用する作業はありますか？
1977年、モーリスハワードハルステッドは、プログラムの語彙、プログラムの長さ、ボリューム、難易度、労力、およびモジュール内のバグの推定数の測定を含む、彼の ソフトウェアシステムの複雑さの測定 を導入しました。ウィキペディアによると、難易度はプログラムを読み書きするときのプログラムの理解の難しさに関連し、労力は時間=（努力/ 18）秒のアプリケーションのコーディングにかかる時間に変換できます。
データと計算がソフトウェア開発のある側面に関係しない限り、測定は役に立ちません。ただし、特定の値以上の難易度は、統計的に有意な欠陥の増加、またはコードの読み取りの難易度と時間の関係に傾向があることを示す作品は見つかりませんでした（難易度Nは平均M時間の消費をもたらします）コードベースを理解する）または品質を決定するのに役立つ事実の後で時間を計算できるという分析（特に、書き込む時間はすでに測定値として記録されているはずなので）私は特にハルステッドのバグ推定（Wikipediaでは言及されていません）に興味があります。アプリケーションのバグ数はVolume/3000またはEffort ^（2/3）/ 3000で推定できます。
私は2つのことを探しています。
- ソフトウェアの品質を評価するために、実際のアプリケーションでHalsteadのソフトウェアの複雑さの指標を使用した人はいますか？もしそうなら、それらをどのように適用し、それらは有用で、有効で、信頼できる測定であると判明しましたか？
- ソフトウェアの品質に適用した場合のHalsteadの複雑さの測定の有効性（または無効性）を議論する調査、分析、またはケーススタディの形の学術研究はありますか？
- ソースラインのコード（SLOC）を使用して、ボリューム、難易度、労力、時間、およびバグのHalsteadメトリックに類似したものを計算することを示す調査、分析、またはケーススタディの形の学術研究はありますか？ VolumeはSLOCカウントに対応し、Difficultyは循環的複雑度（およびその他の対策）に対応しているのではないかと思います。また、SLOCで労力、生産性、または時間を測定すると誤解を招く可能性があることもよく知っています。
Microsoft Researchはこの分野でいくつかの作業を行っています。このページをチェックしてください： http://research.Microsoft.com/en-us/people/nachin/ 。特にHalsteadに基づいているわけではありませんが、Nachiと彼のチームはHalstead、循環的複雑度、コードチャーン、およびその他の手段を使用して調査を行い、コードの領域を変更する際の相対的なリスクと脆弱性を評価しました。組織の有効性がどのように大きな役割を果たすかについての興味深い論文もありますが、それは話題外です。 :)
そのような研究はかなりたくさんあります。 Googleはあなたの友達です。
Halsteadのメトリックは、すべてが未加工のSLOC（コードのソース行）と強く相関していることが実証されたとき、好意から外れました。その時点で、SLOCを測定してそれで終了することがより簡単になります。
これが Googleブックス の結果です。
HalsteadボリュームがSLOCと相関していることは興味深いですが、制限があります。基本統計：線形相関は推移的ではありません。 XはYに相関し、YはZに相関し、XがZに相関していることを意味しません。