软件质量度量

---

---

软件度量可以分为三类：

• 产品度量 - 描述产品的特性，例如大小、复杂性、设计特性、性能和质量水平。

• 过程度量 - 这些特性可用于改进软件的开发和维护活动。

• 项目度量 - 此度量描述项目特征和执行情况。例如，软件开发人员的数量、软件生命周期内的员工配置模式、成本、进度和生产率。

某些度量属于多个类别。例如，项目的在制品质量度量既是过程度量也是项目度量。

软件质量度量是软件度量的一个子集，它关注产品、过程和项目的质量方面。它们与过程和产品度量比与项目度量更密切相关。

软件质量度量可以进一步细分为三类：

• 产品质量度量
• 在制品质量度量
• 维护质量度量

产品质量度量

这些度量包括以下内容：

• 平均故障间隔时间（MTBF）
• 缺陷密度
• 客户问题
• 客户满意度

平均故障间隔时间（MTBF）

它是故障之间的时间。此度量主要用于安全关键系统，例如航空交通管制系统、航空电子设备和武器。

缺陷密度

它衡量相对于软件大小（以代码行数或功能点等表示）的缺陷，即衡量单位代码质量。此度量用于许多商业软件系统。

客户问题

它衡量客户在使用产品时遇到的问题。它包含客户对软件问题空间的看法，其中包括非缺陷导向问题以及缺陷问题。

问题度量通常以每用户月问题数 (PUM)表示。

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

其中，

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM 通常在软件发布到市场后的每个月计算，以及按年计算月平均值。

客户满意度

客户满意度通常通过五点量表通过客户调查数据进行衡量：

• 非常满意
• 满意
• 中立
• 不满意
• 非常不满意

对产品整体质量及其特定维度的满意度通常通过各种客户调查方法获得。根据五点量表数据，可以构建和使用几个略有不同的度量，具体取决于分析的目的。例如：

• 完全满意客户的百分比
• 满意客户的百分比
• 不满意客户的百分比
• 不满意客户的百分比

通常，使用此百分比满意度。

在制品质量度量

在制品质量度量处理在某些组织的正式机器测试期间缺陷到达情况的跟踪。此度量包括：

• 机器测试期间的缺陷密度
• 机器测试期间的缺陷到达模式
• 基于阶段的缺陷去除模式
• 缺陷去除有效性

机器测试期间的缺陷密度

正式机器测试（代码集成到系统库后进行的测试）期间的缺陷率与现场的缺陷率相关。测试期间发现的较高缺陷率表明软件在其开发过程中经历了更高的错误注入，除非较高的测试缺陷率是由于非同寻常的测试工作量造成的。

每千行代码或功能点的这个简单的缺陷度量是一个很好的质量指标，而软件仍在测试中。它对于监视同一开发组织中产品的后续版本特别有用。

机器测试期间的缺陷到达模式

测试期间的整体缺陷密度只会提供缺陷的摘要。缺陷到达模式提供了有关现场不同质量水平的更多信息。它包括以下内容：

• 按时间间隔（例如，周）报告的测试阶段的缺陷到达或缺陷。这里所有这些都不会是有效的缺陷。

• 在对报告的问题进行问题确定时，有效缺陷到达的模式。这是真正的缺陷模式。

• 缺陷积压随时间的变化模式。需要此度量，因为开发组织无法立即调查和修复所有报告的问题。这既是工作量陈述也是质量陈述。如果在开发周期结束时缺陷积压很大，并且许多修复尚未集成到系统中，则系统的稳定性（因此其质量）将受到影响。需要重新测试（回归测试）以确保达到目标产品质量水平。

基于阶段的缺陷去除模式

这是测试期间缺陷密度度量的扩展。除了测试之外，它还跟踪开发周期所有阶段的缺陷，包括设计评审、代码检查和正式验证（在测试之前）。

由于很大一部分编程缺陷与设计问题有关，因此进行正式评审或功能验证以增强前端过程的缺陷去除能力，从而减少软件中的错误。基于阶段的缺陷去除模式反映了开发过程的整体缺陷去除能力。

关于设计和编码阶段的度量，除了缺陷率之外，许多开发组织还使用诸如检查覆盖率和检查工作量等度量来进行在制品质量管理。

缺陷去除有效性

可以定义如下：

$$DRE = \frac{开发阶段去除的缺陷}{产品中潜藏的缺陷} \times 100\%$$

可以针对整个开发过程、代码集成之前的前端以及每个阶段计算此度量。在用于前端时称为早期缺陷去除，在用于特定阶段时称为阶段有效性。度量值越高，开发过程越有效，传递到下一阶段或现场的缺陷越少。此度量是软件开发缺陷去除模型的关键概念。

维护质量度量

尽管在此阶段无法做太多事情来改变产品的质量，但以下是可以执行的修复，以便尽快消除缺陷并确保出色的修复质量。

• 修复积压和积压管理指数
• 修复响应时间和修复响应能力
• 逾期修复百分比
• 修复质量

修复积压和积压管理指数

修复积压与缺陷到达率以及报告问题的修复变得可用的速度有关。它是每个月或每个星期末剩余的已报告问题的简单计数。以趋势图的形式使用它，此度量可以为管理维护过程提供有意义的信息。

积压管理指数 (BMI) 用于管理未解决问题的积压。

$$BMI = \frac{本月关闭的问题数量}{本月到达的问题数量} \times 100\%$$

如果 BMI 大于 100，则表示积压减少。如果 BMI 小于 100，则表示积压增加。

修复响应时间和修复响应能力

修复响应时间度量通常计算为从打开到关闭的所有问题的平均时间。较短的修复响应时间可以提高客户满意度。

修复响应能力的重要因素包括客户期望、商定的修复时间以及履行对客户承诺的能力。

逾期修复百分比

计算如下：

$逾期修复百分比 =$

$\frac{按严重程度级别超过响应时间标准的修复数量}{指定时间内交付的修复总数} \times 100\%$

修复质量

修复质量或有缺陷修复的数量是维护阶段的另一个重要质量度量。如果修复没有修复报告的问题，或者修复了原始问题但引入了新的缺陷，则该修复是有缺陷的。对于关键任务软件，有缺陷的修复不利于客户满意度。有缺陷修复的度量是在一段时间内所有修复中出现缺陷的百分比。

可以以两种方式记录有缺陷的修复：在发现它的月份记录它，或在交付修复的月份记录它。第一个是客户衡量标准；第二个是流程衡量标准。这两个日期之间的差异是有缺陷修复的潜伏期。

通常，潜伏期越长，受影响的客户就越多。如果缺陷数量很大，则百分比度量的较小值将显示出乐观的景象。当然，维护过程的质量目标是零有缺陷的修复，并且没有拖延。