软件度量剖析.docVIP

软件度量剖析 　　摘要：软件度量作为一个研究主题已经存在了40多年，但是软件度量并没有真正进入到软件工程的主流。一个重要的原因是软件度量不能解决软件工程中最重要的需求，即在软件生命周期中提供信息以支持定量的管理决策的制定。支持决策制定就意味着支持风险的评估和降低。然而，传统度量方法通常是由基于回归的模型驱动的，目?是为了成本估算和缺陷预测，在分析并最小化风险方面提供的支持却比较少。软件度量需要使用各种度量指?以建立管理决策支持工具，并结合软件开发和测试的各个不同的方面，使管理者能够在软件生命周期中开展各种预测和评估活动。因此，软件度量的关键在于因果关系建模、经验软件工程和多目?决策帮助。 　　关键词：软件度量；风险评估；决策支持 　　中图分类号：TP306文献?识码：A文章编号：1672-7800（2012）003-0026-02 　　 　　 　　作者简介：丁沂（1979-），男，湖北武汉人，硕士，武汉软件工程职业学院讲师，研究方向为软件分析、软件度量。 　　 　　1软件度量历史回顾 　　尽管软件度量的第一本专著直到1976年才出版，可是软件度量活动却可以追溯到20世纪60年代中期。此时，代码行度量已经作为一种度量方式用来评价程序的效率和成本。事实上，软件度量是一个公共词汇，用来描述软件工程中的各种度量活动。这些度量活动的范围从产生软件代码的特征属性到建模以预测软件资源需求和软件质量。软件度量的主题也包括定量的质量控制和保证。既然软件工程是一个经验型的学科，软件度量就应该在软件工程中起到关键的作用。然而，软件度量却一直处在软件工程的边缘，有时甚至被误解、错误使用并遭到责备。软件度量的理论和实践往往步调不一致。 　　第一个关键的度量是代码行。直到现在，这个指?仍然被用来度量程序员的生产效率。代码行是度量软件成本的一个关键指?。事实上，早期基于代码行的资源预测模型的形式就是：成本=f(代码行)。在20世纪60年代后期，代码行是度量程序质量的基础。1971年，Akiyama提出了基于回归模型的单位缺陷密度（每千行代码中缺陷的数量）来预测软件的质量。这个模型说明产品的规模和质量以及成本是紧密相关的。基于这个模型，代码行也被用来度量软件的功能和复杂性。后来人们发现使用代码行来度量程序的大小、功能和复杂性有着明显的缺陷，因为代码行是和语言相关的，汇编语言的代码行在成本、功能和复杂性方面显然不能和高级语言相比。此时，度量软 　　 　　 　　 　　 　　件的可扩展性、有效性、复杂性和功能也日益升温并一直延续到今天。这些工作包括针对面向对象语言这种新的范型的度量，为软件度量建立理论基础等等。总之，软件度量包括：①建立具体的度量和模型；②在实践中收集、管理并使用各种度量数据。 　　2传统方法 　　传统的质量和资源预测方法一直延续到20世纪80年代早期，这些方法都基于同样的一个假设，即软件大小和复杂性的度量是关键的驱动，这些变化是由回归方法决定的，由其它一些度量变量解释。这些方法提供了一些有价值的经验结果，但是不能够用作定量的管理和风险预测。例如，质量预测所用到的基于回归模型的形式是：缺陷密度（每千行代码中缺陷的数量）=f（复杂性度量）。后来人们渐渐发现使用大小和复杂性建立的模型不能准确地预测缺陷，并且这些模型对于缺陷是如何引入的以及缺陷变量是如何影响缺陷总数等问题不能提供一致性的解释。现在考虑两个问题：一个人在中饭时吃得很多，你能够判定这个人在晚餐时也会吃得很多吗？一个软件在以前的版本中发现了很多错误，你能判定在以后的版本中也会发现很多错误码？直觉告诉我们对后一个问题回答“是”比对前一个问题回答“是”更合适一些。人们普遍认为在一个软件中错误发生率很高的模块在后续版本中发生的概率也会比较高。事实上经验证据表明，这是一个无效的假设。研究证据表明，以前软件版本中容易发生错误的模块在后续版本中发生错误的概率往往比较低。相反，在后续版本中容易发生错误的模块在以前版本中却没有发生错误。为什么这个结果会颠覆以前经典的错误预测模型呢？关键原因是这些预测模型都基于以前版本错误总数来替代质量的度量。这些结果同样也颠覆了很多软件复杂性度量的工作。这些工作背后的理论依据是一个相同的假设，即离群模块（软件系统中数量比较少的却占据了大量错误的模块）在软件的以前版本和以后版本中都很容易发生错误。人们通常假设这些模块本质上是复杂的，难以构建。例如，Munson和Khosghoftaar指出：直觉告诉我们复杂的程序比简单的程序更容易发生错误。产生这个问题主要有3个方面的原因:一是仅仅使用错误密度作为软件复杂性的度量是远远不够的；二是忽视了软件测试的作用，如果软件的一个模块在以前版本中容易发生错误，经过测试和修复之后，在后续版本中发生错误的概率会