📅 最后修改于: 2020-12-04 07:56:17 🧑 作者: Mango
软件指标可以分为三类-
产品指标-描述产品的特性，例如尺寸，复杂性，设计功能，性能和质量水平。
流程指标-这些特性可用于改善软件的开发和维护活动。
项目度量标准-此度量标准描述了项目特征和执行。示例包括软件开发人员的数量，软件生命周期中的人员配置模式，成本，进度和生产率。
一些指标属于多个类别。例如，项目的过程中质量指标既是过程指标又是项目指标。
软件质量度量标准是软件度量标准的子集，其重点是产品，过程和项目的质量方面。与项目和指标相比，这些与过程和产品指标更紧密地关联。
软件质量指标可以进一步分为三类-
此指标包括以下内容-
这是两次失败之间的时间。该度量标准主要用于安全关键系统，例如航空公司交通控制系统，航空电子设备和武器。
它测量相对于软件大小的缺陷，用代码行或函数点等表示，即，测量每单位的代码质量。许多商业软件系统中都使用此度量标准。
它衡量客户在使用产品时遇到的问题。它包含了客户对软件问题空间的看法，其中包括面向非缺陷的问题以及缺陷问题。
问题度量通常以每用户每月问题数(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。
客户满意度通常通过五点量表的客户调查数据来衡量-
通常通过各种客户调查方法来获得对产品整体质量及其特定尺寸的满意度。根据五点规模的数据，可以根据分析目的构建和使用几个略有变化的指标。例如-
通常，使用满意度百分比。
在某些组织的正式机器测试期间，过程中质量度量标准处理的是缺陷到达的跟踪。该指标包括-
正式机器测试(将代码集成到系统库中之后进行测试)期间的缺陷率与现场的缺陷率相关。在测试过程中发现的较高缺陷率表明该软件在其开发过程中经历了较高的错误注入，除非较高的测试缺陷率是由于非常规的测试工作所致。
在仍在测试软件的同时，每个KLOC或函数点的缺陷的简单度量标准可以很好地指示质量。监视同一开发组织中产品的后续发行版本特别有用。
测试期间的总体缺陷密度将仅提供缺陷的摘要。缺陷到达的模式提供了有关现场不同质量水平的更多信息。它包括以下内容-
在测试阶段按时间间隔(例如，一周)报告缺陷到达或缺陷。这里所有这些都不是有效的缺陷。
当对所报告的问题进行问题确定时，有效缺陷到达的模式。这是真正的缺陷模式。
缺陷积压超时模式。之所以需要此指标，是因为开发组织无法立即调查并修复所有报告的问题。这既是工作量说明，又是质量说明。如果在开发周期结束时积压的缺陷很大，并且尚未将许多修补程序集成到系统中，则系统的稳定性(因此质量)将受到影响。需要重新测试(回归测试)以确保达到目标产品质量水平。
这是测试过程中缺陷密度指标的扩展。除测试外，它还跟踪开发周期各个阶段的缺陷，包括设计审查，代码检查和测试前的形式验证。
因为很大一部分编程缺陷与设计问题有关，所以进行正式复审或功能验证以增强前端过程的缺陷清除能力可以减少软件中的错误。基于阶段的缺陷消除模式反映了开发过程的总体缺陷消除能力。
关于设计和编码阶段的度量标准，除了缺陷率之外，许多开发组织还使用诸如检查范围和检查工作量之类的度量进行过程中质量管理。
可以定义如下-
$$ DRE = \ frac {缺陷\：移除\：在\：期间\：开发\：阶段} {缺陷\：潜在\：在\：的\：产品} \时间100 \％$$
可以为整个开发过程，代码集成之前的前端以及每个阶段计算此度量。当用于特定阶段的前端和阶段有效性时，称为早期缺陷消除。度量值越高，开发过程越有效，传递给下一阶段或现场的缺陷越少。此度量标准是用于软件开发的缺陷消除模型的关键概念。
尽管在此阶段不能做很多事情来改变产品的质量，但以下是可以以优异的修复质量尽快消除缺陷的修复方法。
修复积压与缺陷到达率和报告的问题的修复可用率有关。这是报告的问题的简单计数，这些问题在每个月末或每周结束。该指标以趋势图的形式使用，可以为管理维护过程提供有意义的信息。
待办事项管理索引(BMI)用于管理未解决和未解决问题的待办事项。
$$ BMI = \ frac {在\：the \：month期间，\：问题\：已关闭\：的数量：}} {在\：\\ the \ month中，\：发生问题的数量：: \： 100 \％$$
如果BMI大于100，则表示积压量减少了。如果BMI小于100，则积压增加。
修复响应时间度量标准通常计算为所有问题从打开到关闭的平均时间。较短的修复响应时间可提高客户满意度。
修复响应能力的重要元素是客户期望，约定的修复时间以及履行对客户承诺的能力。
它的计算如下-
$％\：拖欠\：修复= $
$ \ frac {数量的\：修复数量\：超过了\：的\：响应\：时间\：标准\：by \：Ceverity \：level} {数量的数量\：修复了\：已交付\：以\：a \：指定\：time} \ times 100 \％$
修复程序质量或缺陷修复程序的数量是维护阶段的另一个重要质量指标。如果修复程序没有解决报告的问题，或者修复了原始问题但又注入了新的缺陷，则该修复程序有缺陷。对于关键任务软件，有缺陷的修复有损于客户满意度。缺陷修复百分比的度量标准是时间间隔内所有缺陷修复的百分比。
有缺陷的修复程序可以通过两种方式记录：在发现缺陷的月份记录该缺陷，或在交付该缺陷的月份记录该缺陷。首先是客户措施；第二是过程措施。这两个日期之间的差是有缺陷的修复程序的潜在期限。
通常，延迟时间越长，受影响的客户越多。如果缺陷数量很大，则百分比度量的较小值将显示乐观的画面。当然，维护过程的质量目标是零缺陷的修复程序，而不拖欠付款。