ソフトウェアの品質を決定するために、ハルステッドの複雑さの尺度を適用する作業はありますか？

1977年、Maurice Howard Halsteadは、ソフトウェアシステムの複雑さの尺度を導入しました。これには、プログラムの語彙、プログラムの長さ、音量、難易度、努力、モジュールの推定バグ数の測定が含まれます。ウィキペディアによると、難易度は、プログラムの読み取りまたは書き込み時のプログラムの理解の難易度に関連しており、努力は、アプリケーションのコーディングに要する時間（時間=（努力/ 18）秒）に変換できます。

データと計算がソフトウェア開発の何らかの側面に関係しない限り、測定は役に立ちません。ただし、特定の値以上の難易度が統計的に有意な欠陥の増加や、難易度とコードの読み取り時間の関係につながる傾向があることを示す作品は見つかりませんでした（Nの難易度は平均M時間を費やしますコードベースを理解する）または品質を決定するのに役立つ事実の後の時間を計算できることの分析（特に書く時間はすでに測定値として記録されているはずなので）特にHalsteadのバグ推定（Wikipediaには記載されていません）に興味があります-アプリケーションのバグの数はVolume / 3000またはEffort ^（2/3）/ 3000で推定できます。

私は2つのことを探しています：

• 誰もが実際のアプリケーションでHalsteadのソフトウェア複雑度測定を使用してソフトウェア品質を評価しましたか？もしそうなら、どのようにそれらを適用し、有用で、有効で、かつ/または信頼できる測定であることが判明しましたか？
• ソフトウェアの品質に適用した場合のHalsteadの複雑さの測定の有効性（または無効性）を検討する調査、分析、またはケーススタディの形式で学術研究はありますか？
• ソース行コード（SLOC）を使用してボリューム、難易度、努力、時間、バグのハルステッドメトリックに類似した何かを計算することを実証する調査、分析、またはケーススタディの形式の学術研究はありますか？Volumeは単にSLOCカウントに対応し、Difficultyは循環的複雑度（およびおそらく他の指標）に対応する可能性があると思われます。また、SLOCで努力、生産性、または時間を測定することは、誤解を招く可能性があることをよく知っています。

Microsoft Researchはこの分野でいくつかの作業を行っています。次のページをご覧ください：http : //research.microsoft.com/en-us/people/nachin/。特にハルステッドに基づいているわけではありませんが、ナチと彼のチームは、ハルステッド、循環的複雑度、コードチャーン、およびコードの領域を変更するための相対的なリスクと脆弱性を評価する他の手段を使用して調査を行いました。また、組織の有効性がどのように大きな役割を果たすかについての興味深い論文もありますが、それは話題外です。:)

そのような研究はかなりあります。Googleはあなたの友達です。

Halsteadのメトリクスは、すべてのメトリクスが生のSLOC（コードのソース行）と強く相関していることが実証されたため、好意的ではなくなりました。その時点で、SLOCを測定し、それを実行するのが簡単になります。

これがGoogleブックスの結果です。

Halstead VolumeがSLOCと相関していることは興味深いですが、限られています。基本統計：線形相関は推移的ではありません。XはYに相関し、YはZに相関し、XがZに相関していることを意味しません。