软件度量_软件度量探析

　　摘要：软件度量作为一个研究主题已经存在了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个方面的原因:一是仅仅使用错误密度作为软件复杂性的度量是远远不够的；二是忽视了软件测试的作用，如果软件的一个模块在以前版本中容易发生错误，经过测试和修复之后，在后续版本中发生错误的概率会大大降低；三是没有考虑操作性，一个简单的模块可能很少被使用但却包含着很多错误而且不容易被发现。因此，模型的建立应该考虑到更多的因果关系。
　　3软件度量的研究展望
　　建立基于软件度量的决策支持系统需要软件度量领域人员的共同努力，软件风险评估最终依赖于经验的研究结果，包括一些重要的�杆的研究。目前，越来越多的人投入到测试因果关系的假设和建立经验值的范围等经验软件工程研究领域。对于软件管理者而言，追求定量风险管理决策支持以及工业界广泛研究的工具和�杆数据的活动会大大有利于软件工程学科的发展。软件度量的历史确凿地告诉我们，软件度量的发展需要软件行业提供实际的数据和工具来实现特定的目�。软件度量的最后一个挑战是技术转换。软件度量的最终目�是为软件管理者提供风险评估和决策支持。软件度量最终要给软件管理者提供一个可靠的报告和推荐，而不是让管理者去理解复杂的软件度量技术与理论。
　　4结束语
　　软件度量研究和实践帮助我们为软件工程建立了一个经验的基础，这是一个重要的成就。但是，经典的基于统计的方法不能够为管理者提供决策支持，未能达到软件度量最重要的目�。软件度量领域迫切需要解决这个问题。
　　参考文献：
　　\[1\]赵一鸣.基于ISO质量模型的软件质量评价方法\[J\].计算机研究与发展,2002(4) .
　　\[2\]李茜,凌辉.一组基于三级度量模型的面向对象度量准则\[J\].计算机科学，2001(3).
　　\[3\]朱鸿,金凌紫.软件质量保障与测试\[M\].北京：科学出版社,1997.
　　\[4\]宿为民.支持过程度量的软件过程建模及软件过程评价平台的研究\[D\].上海:复旦大学，1999.
　　\[5\]李健,金茂忠.中小型企业软件过程改善研究\[J\].计算机工程与应用,2001(19).
　　\[6\]李健,金茂忠.有效改善软件过程方法研究\[J\].计算机研究与发展，2001(1).
　　
　　（责任编辑：戴钧）

推荐访问:探析 度量 软件