在软件评估、度量和评价过程中，质量是最重要但也是最容易被忽视的一个领域。在项目的早期规划阶段，通常不会仔细考虑质量要求，但在产品准备上线或部署时通常又会把它作为最终的评级标准。因此，从项目一开始讨论预期目标时，就应该确立质量目标！
什么是产品的质量？从质量本身而言，可以有多种度量方式，在这里，我们重点考虑两条能深刻揭示软件稳定性的指标。它们是：
1.测试和实际交付时发现的缺陷数量；
2.缺陷平均检测时间（MTTD），或者交付客户前和交付客户后发现缺陷所需的时间。
因为随着发布日期的临近，这两个指标将至关重要。它们是客观的、可度量的，在大多数组织的质量监控体系中都能得出，不必费太大的力气。
通常，更少的缺陷和更快的缺陷平均检测时间意味着更高的整体质量。虽然干系人的核心关注点不一定总是拥有更高的质量，但在项目交付前，可靠性是必须要满足的最低标准。
另一条行业经验是，通常测试人员每月发现的错误少于20个，是可以接受的最低的可靠性。换句话说，产品将可以无故障运行大约8个小时即一个工作日。当然，工业和军事嵌入式应用的可靠性需要达到更高的水平。
Rayleigh缺陷模型
Rayleigh缺陷模型是一种获得最佳质量评估的方式，这种模型用Rayleigh函数作为一个时间函数预测软件开发过程中的缺陷发现率，与软件开发过程中收集的缺陷数据的实际情况非常接近。
Rayleigh模型可以用来预测不同时间段发现的缺陷数量。从概要设计评审到已发现99.9%的缺陷，在这段周期内它都可以发挥作用。如图1所示：
图1. Rayleigh缺陷预测示例
注意，曲线峰值更早发生在构建和测试阶段。这意味着大量的缺陷是在项目早期引入和发现的。这些缺陷主要是需求、设计和单元编码缺陷。如果前期没发现，它们会在项目后期暴露出来，导致大量的返工。
里程碑10是声称已经发现99.9%的缺陷的时间点。在与质量体系管理（QSM）一起工作的组织中，有不到5%的组织记录了详细设计阶段的缺陷。行业研究表明，在系统测试阶段发现的缺陷修复成本，比在设计或编码时发现的缺陷修复成本要高10到100倍，因此，软件质量应该尽早开始度量并采取行动。
可以将模型简单扩展，提供其他更多有用的信息。例如，可以对缺陷优先级详细分类，让模型随时间推移按照严重程度来预测缺陷，如图2所示：
图2 通过缺陷严重程度来划分的缺陷模型
缺陷预测可以被看作是一份质量计划。针对一组特定的条件（规模、复杂度、效率、员工等），生成一份计划性的曲线。管理者可以把它当作初期的绩效计量器来用，检查项目执行情况是否与计划一致，还可以与历史项目进行比较。如果存在重大偏差，管理人员应该据此进行深入调查，防患以未然或采取补救措。
图3展示了如何用缺陷预测计划去跟踪和比对。显然，实测结果和预估之间有点小偏差，但轨迹大体一致。可以乐观估计在项目末期每月的缺陷发现率在20个以内，这是建议可接收的最低交付标准。
图3 缺陷发现率的计划和实际比较
缺陷模型驱动
从1978年以来，QSM已经收集了超过10000份完整的软件项目数据。通过这些数据分析发现，存在着决定Rayleigh缺陷模型持续时间和量级的特定输入。这些输入能使模型针对给定情况提供一份精确的预测。以下是QSM模型使用的三个参数：
1.规模（新增和修改）
2.产能指数
3.最高人员配置
这些驱动因子会影响软件的缺陷行为模式。下文将深入讨论这些驱动因子。除了另行说明之外，这些结果都是基于QSM数据分析得出。
1）规模
从历史数据看，随着项目规模的增长，系统内的缺陷数也会随之增长（如图4所示）。简单来说，构建更大的项目使开发人员有了更多导致系统缺陷的可能性，同时也需要去完成更多的测试。缺陷增长率几乎是呈线形的！
同样，随着规模的增长MTTD也会随之减少。因为系统中的缺陷更多了，导致缺陷的时间间隔就减少了。依此类推，因为时间间隔太少，所以大型项目的可靠性往往较低。这是这个行业的典型情况。
图4 随着规模增长缺陷数随之增长
2）产能指数（PI）
生产力对一个系统的整体质量也有非常大的影响，它可以通过产能指数来测量。产品指数包含软件开发中的许多因素，比如管理人员影响力、开发方法、工具、技术以及开发团队的技能和经验。它还要考虑应用的类型和复杂度、过程因素和复用。它使用一个0.1到40的标准刻度范围，值低的地方与不良的环境、工具和复杂的系统相关，高值则代表有好的环境、工具和管理，以及对项目有充分的理解。
历史数据表明，缺陷会随产能指数的提升呈指数级下降。图5展示了相同规模软件应用在不同产能指数（分别为17和21）下的累积的缺陷检出数。有着较高产能指数的项目不仅可以提前九个月交付，大约总计还要少360个缺陷。当开发团队的人数变得更少时效果会更明显，首先犯的错误会更少，从而测试时发现的缺陷也会降低。在更高的生产力水平上工作可以大幅提升软件质量。
图5 同样规模的系统在不同产能指数下产生的缺陷对比
3）人员配置
开发团队的规模也可以影响一个系统的质量，因为较大的团队往往比较小的团队产生更多的错误。如图6所示，当在相同项目规模下比较大型团队（红色）和小型团队（灰色）时，在所有项目规模下小型团队都会比大型团队少50-65个错误。另外，他们很少制定惩罚条例，如果有的话也花不了多少工作量。在识别组织内哪里浪费时，研究人员这个发现特别有用，因为它说明为项目增加资源未必总能提升质量。
图6 不论什么项目规模，小型团队产生的错误都比大型团队少
总结
软件可靠性和质量这两个领域应该在预期环境和项目规划阶段内就给予足够的重视。质量反映了软件遵守或符合给定设计的程度（基于功能性需求或规格说明书），而可靠性是关于在特定环境中指定周期内软件运维的无故障率。
作为一个领导者，这里有几个策略可以让你用于改进可靠性和质量。保持已开发的产品规模尽可能地小，使用较小的团队，定期在环境中投资以改进开发工作室的效率和效果。所有这些措施都将得到可靠性和质量的高效回报！
