质量是软件评估、度量和评价中最重要却也最容易被忽视的一个领域。在所有开发项目的早期规划阶段通常不会仔细考虑它，甚至都不会提到它，但产品准备上线或部署时通常又会把它作为最终的标准。因此，从项目一开始讨论设定预期时就应该把它作为必要内容。

那么，我们如何来讨论产品质量呢？它可以由多种方式来度量，而其中两种特别能深刻地揭示产品的稳定性。它们是：

1. 测试和实际交付时发现的系统中缺陷和错误的数量，以及
2. 缺陷平均检测时间（MTTD），或者交付客户前和交付客户后发现缺陷所需的时间。

我们喜欢这两种度量的原因是它们都与产品稳定性相关，随着发布日期的临近这个问题将至关重要。它们是客观的、可度量的，通常可以从大多数组织的当前质量监控体系中得出，不必费太大的气力。

通常，更少的错误和更快的缺陷平均检测时间就会关乎更好的整体质量。虽然拥有最好的质量不一定总是干系人的核心关注点，但在项目交付客户之前可靠性是必须要满足的最低标准。例如，经验表明大约95%无缺陷的项目可以运行一天不崩溃。

另一条不错的经验法则是测试人员每月发现的错误少于20个通常是可以接受的最低的可靠性。换句话说，产品将可以运行大约一个8小时工作日。当然，这个经验法则通常应用于电子商务信息化应用。工业和军事嵌入式应用的可靠性需要达到更高的水平。

Rayleigh缺陷模型

Rayleigh缺陷模型是一种获得最佳质量评估的方式，你可以用Rayleigh函数作为一个时间函数随传统软件开发过程中预测缺陷发现率。Rayleigh函数是由英国物理学家Lord Rayleigh在声波及电磁波散射的相关工作中发现的。Rayleigh可靠性模型与从软件开发工作中收集的缺陷数据的实际情况非常接近。

Rayleigh等式可以用来预测不同时间段发现的缺陷数量。从高层设计评审（HLDR——高层设计已完成）直到已发现99.9%的缺陷，在这段持续的时间内它都可以发挥作用。如图1所示，这是一个Rayleigh缺陷评估示例。

图1. Rayleigh缺陷预测示例

注意，曲线峰值更早发生在构建和测试阶段。这意味着大量的缺陷是在项目早期引入和发现的。这些缺陷主要是需求、设计和单元编码缺陷。如果没发现，它们会在项目后期暴露出来，导致大量的返工。

里程碑10是声明已经发现99.9%的缺陷的时间点。在与质量体系管理（QSM）一起工作的组织中，有不到5%的组织记录了详细设计阶段的缺陷。行业研究人员称，缺陷在系统测试时发现比设计或编码时发现的修复成本要高10到100倍(Boehm, 1987; McConnell, 2001)，这是一个尽早开始度量并采取行动的很有说服力的例子。

模型的简单扩展提供了其他有用的信息。例如，可以以总体曲线占对缺陷优先级予以详细说明。这可以让模型随时间推移按照严重程度来预测缺陷，如图2所示。

图2 通过缺陷严重程度来划分的瑞利缺陷模型

缺陷评估可被认为是一份计划。针对一组特定的条件（规模、复杂度、效率、员工等），应生成一份计划性的曲线。管理者可以把它当作粗略的绩效计量器来用，看项目执行情况是否与计划一致，还可以与历史项目进行比较。如果存在重大偏差，会令管理人员据此进行调查，如果证明确有其事则采取补救措施。

图3展示了如何用缺陷检出预估去跟踪并与实际进行比对。很显然，实际测量结果和预估之间有些小偏差，但他们的轨迹大体一致。他们还让我们有信心做到在项目末期每月缺陷检出率在20个以内，这是我们建议的最低可接收的交付标准。

图3 带有实际标绘的缺陷检出率计划

缺陷模型驱动

从1978年以来，QSM已经收集了超过10000份完整的软件项目数据。通过对这些数据分析发现，存在着决定瑞利缺陷模型持续时间和量级的特定输入。这些输入能使该模型针对给定情况提供一份精确的预测。以下是QSM模型会使用的三个宏参数：

• 规模（新的和修改的）
• 产能指数
• 最高人员配置

这些驱动因子会影响我们在软件项目中看到的缺陷行为模式。下文将深入考究这些驱动因子。除了另行说明之外，这些结果都是基于QSM数据分析得出的。

规模

从历史来看，我们发现随着项目规模的增长系统内的缺陷数也会随之增长（如图4所示）。简单来说，构建更大的项目使开发人员有了更多导致系统缺陷的可能性，同时也需要去完成更多的测试。缺陷增长率几乎是呈线形的。

同样，随着规模的增长MTTD也会随之减少。这是由于系统内的缺陷数增加了，这通常是由于跨大型团队在所难免的交流复杂性所导致的。因为系统中的缺陷更多了，缺陷的时间间隔就减少了。依此类推，因为时间间隔太少，所以大型项目的可靠性往往较低。这是这个行业的典型情况。

图4 随着规模增长缺陷数随之增长

产能指数（PI）

生产力往往对一个系统的整体质量也有非常大的影响，它可以通过产能指数来测量。它包含软件开发中的许多因素，比如管理人员影响力、开发方法、工具、技术以及开发团队的技能和经验。它还要考虑应用的类型和复杂度、过程因素和复用。它使用一个0.1到40的标准刻度范围，值低的地方与不良的环境、工具和复杂的系统相关，高值则代表有好的环境、工具和管理，对项目有着充分的理解。

历史数据表明，缺陷检测率会随产能指数的提升呈指数级下降。图5展示了相同规模软件应用在不同产能指数（分别为17和21）下的累积的缺陷检出数。有着较高产能指数的项目不仅可以提前九个月交付，大约总计还要少360个缺陷。当开发团队变得更少时会更具意义，首先他们更少犯错，从而测试时发现的错误也会降低。在更高的生产力水平上工作可以大幅提升软件质量。

图5 同样规模的系统在不同产能指数下产生的缺陷对比

人员配置

开发团队的规模也可以影响一个系统的质量，因为较大的团队往往比较小的团队产生更多的错误。如图6所示，当在相同项目规模下比较大型团队（红色）和小型团队（灰色）时，在所有项目规模下小型团队都会比大型团队少50-65个错误。另外，他们很少制定处罚条例，如果有的话也花不了多少工作量。去识别组织内哪里浪费时这个发现特别有用，因为它说明为项目增加资源未必总能提升质量。

图6 不论什么项目规模，小型团队产生的错误都比大型团队少

总结

软件可靠性和质量这两个领域应该在预期环境和项目谈判阶段内就予以处理。质量反映了软件遵守或符合给定设计的程度（基于功能性需求或规格说明书），而可靠性是关于在特定环境中指定周期内软件运维的无故障率。

作为一个领导者，这里有几个策略可以让你用于改进可靠性和质量。保持已开发的产品规模尽可能地小，使用较小的团队，定期在环境中投资以改进开发工作室的效率和效果。所有这些措施都将得到可靠性和质量的回报。

参考资料

• B. Boehm, IEEE Software, Sept. 1987, pp. 84-85
• S. McConnell, An Ounce of Prevention, IEEE Software, May/June 2001

关于作者

C. Taylor Putnam-Majarian是QSM的一名顾问分析师，有超过7年的专业的数据分析、测试和研究经验。除了为来自商业和政府部门的客户提供软件评估和基准测试方面的咨询支持之外，Taylor还撰写了大量敏捷开发、软件评估和过程改进方面的出版物，她还是QSM博客的定期撰稿人。最近Taylor在华盛顿特区举办的Agile in Government会议上展示了题为Does Agile Scale? A Quantitative Look at Agile Projects的研究。泰勒拥有迪金森学院的学士学位。

Doug Putnam是数量化软件管理股份有限公司（QSM）的联合首席执行官。他在软件度量领域有35年的经验并且被看作是这一行业发展的先驱者。Putnam先生曾帮助指导业界领先的软件评估和度量工具SLIM套件的开发，并且是一个相当出名的国际化作家、演说家和顾问。其主要职责包括管理和交付QSM软件度量服务，定义SLIM产品套件的需求以及监督从QSM基准数据库衍生而来的研究活动。

查看英文原文：Understanding Quality and Reliability