Halstead复杂度度量的应用程序是否有任何工作可用来确定软件质量？

1977年，莫里斯·霍华德·霍尔斯特德（Maurice Howard Halstead）推出了他的软件系统复杂性度量标准，其中包括对程序词汇量，程序长度，数量，难度，工作量以及模块中错误数量的估计。根据Wikipedia所说，困难与阅读或编写程序时理解程序的难度有关，可以将精力转化为​​编写应用程序所需的时间，其中Time =（Effort / 18）seconds。

除非数据和计算与软件开发的某些方面有关，否则测量是没有用的。但是，我还没有发现任何能够说明某个值或更高难度的缺陷会导致统计上的缺陷增加或难度与读取代码的时间之间的关系的工作（N的难度平均产生M个小时的花费）理解代码库）或在确定质量有用的事实之后进行任何能够计算时间的分析（尤其是因为应该将写入时间记录为度量）。我对Halstead的错误估计（维基百科上没有提及）特别感兴趣-应用程序中的错误数量可以通过Volume / 3000或Effort ^（2/3）/ 3000进行估计。

我在寻找两件事：

• 是否有人在实际应用中使用Halstead的软件复杂性度量来评估软件质量？如果是这样，您如何应用它们，结果证明它们是有用，有效和/或可靠的度量？
• 是否有任何调查，分析或案例研究形式的学术研究，讨论了Halstead复杂性度量应用于软件质量时的有效性（或无效性）？
• 是否有任何调查，分析或案例研究形式的学术研究证明使用代码源代码行（SLOC）来计算类似于量，难度，工作量，时间和错误的Halstead度量标准？我怀疑“体积”可能仅对应于SLOC计数，“难度”可能对应于圈复杂度（可能还有其他度量）。我也很清楚，在SLOC中衡量工作量，生产率或时间可能会产生误导。

Microsoft Research在这方面做了一些工作。签出此页面：http : //research.microsoft.com/en-us/people/nachin/。尽管不是专门基于Halstead，Nachi和他的团队使用Halstead，圈复杂度，代码搅动和其他措施进行了一些调查，以评估在代码区域进行更改的相对风险和脆弱性。还有一篇有趣的文章介绍组织有效性如何发挥重要作用，但这不是主题。:)

有很多这样的研究。Google是您的朋友。

当证明所有这些指标都与原始SLOC（代码源代码）紧密相关时，Halstead的指标就不受欢迎了。到那时，测量SLOC并进行测量变得更加容易。

这是Google图书的结果。

Halstead Volume与SLOC相关联是有趣但有限的。基本统计数据：线性相关性不是传递性的。X与Y相关联，Y与Z相关联并不意味着X与Z相关联。