
第2章 估算和度量软件质量
2.1 引言
要想比较准确地预测软件项目的未来,需要度量以往的项目,并且跟踪当前和进行中的项目的活动。估算和度量是紧密结合的,并且良好的历史数据在估算未来的软件项目结果时具有很大的价值。
生产力和进度的预测通常可以根据类似项目的观测数据和基准作出。然而,质量的基准很少,大多数管理人员和软件工程师都无法使用任何精确的方法来预测质量。事实上,项目被取消以及引起诉讼的一个普遍原因是,测试过程中发现过多的bug导致工期延长直到项目的价值变成负值。通常,bug的数量会让开发人员、管理人员和客户感到震惊。很少有人清楚软件项目中会有多少bug或缺陷。
如果企业的历史数据完整且准确的话,那这是最宝贵的。而从外部来源如非盈利的ISBSG(International Software Benchmark Standards Group,国际软件基准标准化组)获得的基准数据也是有价值的。在ISBSG有生产力数据的项目超过5000个,但其中同时拥有质量数据的项目仅有几百个。这表明在软件产业中质量度量是多么罕见。
估算和度量之间的联系对于质量预测来说尤其紧密。如果历史成本和生产率数据有缺失,可以通过采访团队成员来弥补。但是如果质量数据有缺失和错误,比如未能记录在功能测试前发现的缺陷,那么修复丢失的数据就不是那么容易,因为没有人能记住这些早期发现的bug和错误。
截至2011年,有些商业性的软件估算工具预测质量水平的准确度已经很高了。实际上,COCOMO II、KnowledgePlan、SEER、SLIM和Software Risk Master等商业工具很可能是最准确的质量估算方法,这是由于它们拥有数千个历史项目的数据。但是根据作者对客户公司的访谈,只有不到25%的软件工程组采用了自动化的成本和质量估算工具。
在2011年,大多数美国软件项目管理人员、软件工程师和软件质量保证(SQA)人员没有接受过软件质量估算方面的良好培训。根据评估研究期间的访谈,这些人中没有接受过质量度量方法方面的良好培训的人数同样惊人。
实际上,整个软件工程界的一大“知识鸿沟”,就是不了解结合运用软件缺陷预防方法、测试前缺陷清除方法(如审查和静态分析),以及有效的软件测试方法等的效果。单靠测试从来都不足以获得高质量水平,同样,单靠测试,成本的效益也不高。
每个软件质量的有效定义都必须满足3个关键的标准:
1)项目开始前它应是可预测的;
2)项目进行中它应是可度量的;
3)部署后的维护阶段它应是可度量的。
这些标准提出了一个重要的问题,即究竟需要预测和度量什么才能理解软件质量经济学。以下是10个既需要度量又需要估算的关键主题:
1)软件潜在缺陷;
2)软件缺陷预防方法;
3)软件测试前缺陷清除方法;
4)软件测试的缺陷清除方法;
5)发布前缺陷清除成本和进度;
6)发布后客户发现的缺陷;
7)发布后缺陷清除成本和进度;
8)不良修复或缺陷修复时引入的二次缺陷;
9)缺陷检测效率或者发布前的缺陷识别百分比;
10)缺陷清除效率,或者应用程序交付给其客户和用户前的缺陷清除百分比。
术语软件潜在缺陷(software defect potential)约在1973年前后来源于IBM。该术语定义了可能发生在需求、设计、编码、用户文档和其他可交付成果中的各类软件缺陷的总和。IBM对潜在缺陷的认识是多年来准确度量的结果。最初的潜在缺陷度量起始于20世纪70年代初的IBM圣何塞,它由5个主要的来源组成;1)需求缺陷;2)设计缺陷;3)编码缺陷;4)文档缺陷;5)不良修复或者修复bug时引入的二次缺陷。本书使用了这5个最初来源并添加了数据库缺陷、测试用例缺陷和网站缺陷,因为它们在数量和影响上都是无法忽略的。
术语缺陷预防(defect prevention)也来源于IBM。该术语定义了减少潜在缺陷的方法的有效性,比如联合应用设计(JAD)、原型法、软件六西格玛和质量功能展开(QFD)等。碰巧的是,有些缺陷清除方法(如审查和静态分析)在预防缺陷方面也相当有效。这里,准确的度量也使得IBM能够鉴定缺陷预防的有效性。
术语测试前缺陷清除(pretest defect removal)是指传统的桌面检查、非正式同行评审、设计和代码的正规审查,以及对源代码进行静态分析的现代工具。测试前缺陷清除是有效的软件质量控制方法的重要组成部分。测试前清除能有效地找出bug并且也是有成本效益的。测试前缺陷清除同时也能缩短测试周期并提高测试效率。
术语测试缺陷清除(testing defect removal)是指整个软件应用程序测试阶段用到的所有方法。可能会用到的软件测试形式有很多种,包括子例程测试、单元测试、新功能测试、回归测试、性能测试、安全性测试、可用性测试、组件测试、平台测试、独立测试、系统测试、外部Beta测试和验收测试。所有形式的测试都很少能达到85%的总缺陷清除效率。要达到95%的缺陷清除效率测试前清除和测试中清除相结合是必要的。而95%恰好是高质量和普通质量之间合适的分界线。
术语发布前缺陷清除成本(pre-release defect removal cost)是指测试前缺陷清除活动(如审查和静态分析)的成本与所有测试阶段成本的总和。
术语发布后缺陷(post-release defect)是指软件应用程序交付给用户时依然存在的以及潜在的缺陷。显然,该术语并不是指那些在外部Beta测试或者客户验收测试中可能存在的缺陷。它的意思是那些所有形式的内部缺陷清除活动完成后仍然存在的缺陷。软件应用程序经常在交付给客户时还存在着数百甚至数千个潜在的缺陷。对于商业软件和信息系统软件而言,第一年内客户报告的缺陷通常能达到总数的15%~35%。嵌入式应用程序和武器系统的用户在第一年通常能发现超过75%的缺陷,这是由安装软件的设备的性质决定的。
术语发布后缺陷清除成本(post-release defect removal cost)是指客户支持成本与正式发布后客户所报告缺陷的修复成本之和。
术语不良修复(bad fix)是指IBM在20世纪70年代初发现的一种令人烦恼的现象。它经常发生在试图修复bug而修复本身又引入了新的bug或缺陷的时候。实际上,美国的平均不良修复注入率约为7%。但是在某些情况下,如软件的架构十分复杂且糟糕,不良修复注入率能达到25%。在本书的一位作者作为专家证人参与过的一个诉讼案件中,厂商前后四次试图修复一个bug。每次修复都没能修好最初的bug,但每次修复都引入了新的bug。最终,第五次尝试才修好了最初的bug,并且似乎也摆脱了再次引入bug。但第五次最终修好该缺陷时,距离首次报告最初那个bug的日子已经过去9个月了。
术语缺陷检测效率(Defect Detection Efficiency,DDE)是指在将软件发布给客户前由软件开发者发现和确定的缺陷百分比。注意,“缺陷检测”和“缺陷清除”间有着明显的区别。现今世界的质量控制并不严格,有些公司并不会修复所有在审查、静态分析和测试中发现的缺陷。为了能赶上交付进度,软件可能会在还有已知的潜在缺陷时发布。2011年前后,美国的缺陷检测率平均值约是92%,其变化范围是80%~99%。
术语缺陷清除效率(Defect Removal efficiency,DRE)是指在软件发布给客户前由软件开发者发现、确定并清除的缺陷百分比。2011年前后,美国的缺陷清除效率平均值约为85%,其变化范围从75%到极少数案例才能达到的99%。缺陷清除效率的计算根据是发布前修复的缺陷总数加上发布后头90天内客户报告的缺陷数。例如,如果发布前开发者发现了90个bug,客户在头3个月报告了10个bug,那么本例中的缺陷清除效率是90%。这是非常重要的质量度量方法,因为和缺陷清除效率较低的类似应用程序相比,缺陷清除效率能达到95%的应用程序往往工期更短并且成本更低。这样的应用程序的消费者也会更愉快,其维护成本也更低。
上面讨论的10个主题可以扩展为很多子主题。出于质量估算和质量度量的需要,有必要详细理解这10个主题之中的3个主题:1)潜在缺陷;2)缺陷预防;3)缺陷清除。