软件质量管理 - 快速指南

---

软件质量管理 - 简介

优质软件是指没有明显错误或缺陷、在指定预算内及时交付、满足要求和/或期望并且可维护的软件。在软件工程背景下，软件质量既反映功能质​​量又反映结构质量。

• 软件功能质量- 它反映了它根据功能要求或规范满足给定设计的程度。

• 软件结构质量- 它涉及支持功能需求交付的非功能需求的处理，例如稳健性或可维护性，以及软件正确生成的程度。

• 软件质量保证- 软件质量保证（SQA）是一组确保软件工程过程质量的活动，最终产生高质量的软件产品。这些活动建立并评估生产产品的流程。它涉及以流程为中心的行动。

• 软件质量控制- 软件质量控制（SQC）是一组确保软件产品质量的活动。这些活动的重点是确定实际生产的产品中的缺陷。它涉及以产品为中心的行动。

软件质量挑战

在软件行业，开发人员永远不会声明软件没有缺陷，这与其他工业产品制造商通常所做的不同。这种差异是由于以下原因造成的。

产品复杂性

它是产品允许的操作模式的数量。通常，工业产品仅允许少于几千种操作模式及其机器设置的不同组合。然而，软件包提供了数百万种操作可能性。因此，确保所有这些操作可能性的正确性是软件行业面临的重大挑战。

产品知名度

由于工业产品是可见的，其大部分缺陷可以在制造过程中被检测出来。此外，工业产品中是否缺少某个部件也可以在产品中轻松检测到。然而，存储在软盘或CD上的软件产品的缺陷是不可见的。

产品开发及生产流程

在工业产品中，可以在以下阶段检测缺陷 -

• 产品开发- 在此阶段，设计师和质量保证 (QA) 人员检查和测试产品原型以检测其缺陷。

• 产品生产计划- 在此阶段，设计和准备生产流程和工具。此阶段还提供了检查产品的机会，以发现在开发阶段未被注意到的缺陷。

• 制造- 在此阶段，应用质量保证程序来检测产品本身的故障。在制造的第一阶段检测到的产品缺陷通常可以通过改变产品的设计、材料或生产工具来纠正，从而消除未来制造的产品中的此类缺陷。

然而，就软件而言，唯一可以检测到缺陷的阶段是开发阶段。对于软件，不需要产品生产计划和制造阶段，因为软件副本的制造和软件手册的打印都是自动进行的。

下表显示了影响软件产品缺陷检测与其他工业产品缺陷检测的因素。

软件的复杂性和不可见性等特征使得软件质量保证方法的开发及其成功实施成为高度专业的挑战。

软件质量因素

影响软件的各种因素被称为软件因素。它们大致可以分为两类。第一类因素是那些可以直接测量的因素，例如逻辑错误的数量，第二类因素是那些只能间接测量的因素。例如，可维护性，但要测量每个因素以检查内容和质量控制。

多年来，人们提出了几种软件质量因素模型及其分类。McCall 提出的软件质量因素的经典模型由 11 个因素组成（McCall 等，1977）。同样，Deutsch 和 Willis (1988) 以及 Evans 和 Marciniak (1987) 提出了由 12 到 15 个因素组成的模型。

所有这些模型与麦考尔的模型没有太大区别。McCall 因子模型提供了一种实用的、最新的软件需求分类方法（Pressman，2000）。

麦考尔的因素模型

该模型将所有软件需求分为 11 个软件质量因素。这11个因素分为三类——产品运营因素、产品改版因素和产品转型因素。

• 产品操作因素- 正确性、可靠性、效率、完整性、可用性。

• 产品修订因素- 可维护性、灵活性、可测试性。

• 产品转换因素- 可移植性、可重用性、互操作性。

产品运营软件质量因素

根据McCall的模型，产品运营类别包括五个软件质量因素，涉及直接影响软件日常运营的需求。它们如下 -

正确性

这些要求涉及软件系统输出的正确性。它们包括 -

• 输出任务

• 所需的输出精度可能会受到不准确的数据或不准确的计算的负面影响。

• 输出信息的完整性，可能会受到不完整数据的影响。

• 信息的最新性定义为事件与软件系统响应之间的时间。

• 信息的可用性。

• 软件系统编码和文档化的标准。

可靠性

可靠性要求处理服务故障。它们决定了软件系统的最大允许故障率，并且可以指整个系统或其一个或多个单独的功能。

效率

它处理执行软件系统不同功能所需的硬件资源。它包括处理能力（以MHz为单位）、存储容量（以MB或GB为单位）和数据通信能力（以MBPS或GBPS为单位）。

它还涉及系统便携式单元（例如位于便携式计算机中的信息系统单元或放置在室外的气象单元）的充电之间的时间。

正直

这个因素涉及到软件系统的安全性，即防止非授权人员的访问，同时区分哪些人要给予读和写的许可。

可用性

可用性需求涉及培训新员工和操作软件系统所需的人力资源。

产品修订质量因素

根据 McCall 的模型，产品修订类别中包含三个软件质量因素。这些因素如下 -

可维护性

该因素考虑了用户和维护人员为确定软件故障原因、纠正故障以及验证纠正是否成功而需要付出的努力。

灵活性

该因素涉及支持软件的自适应维护活动所需的能力和工作。其中包括在不更改软件的情况下使当前软件适应其他环境和客户。该因素的要求还支持完善的维护活动，例如对软件进行更改和添加，以改进其服务并使其适应公司技术或商业环境的变化。

可测试性

可测试性要求涉及软件系统及其操作的测试。它包括预定义的中间结果、日志文件以及软件系统在启动系统之前执行的自动诊断，以查明系统的所有组件是否处于工作状态并获取有关检测到的故障的报告。另一种类型的要求涉及维护技术人员应用的自动诊断检查，以检测软件故障的原因。

产品转换软件质量因素

根据 McCall 的模型，三个软件质量因素包含在产品转换类别中，涉及软件对其他环境的适应以及与其他软件系统的交互。这些因素如下 -

可移植性

可移植性需求倾向于使软件系统适应由不同硬件、不同操作系统等组成的其他环境。该软件应该能够在不同的情况下继续使用相同的基本软件。

可重复使用性

这一因素涉及最初为一个项目设计的软件模块在当前正在开发的新软件项目中的使用。它们还可以使未来的项目能够利用当前开发的软件的给定模块或一组模块。软件的复用有望节省开发资源、缩短开发周期、提供更高质量的模块。

互操作性

互操作性要求侧重于创建与其他软件系统或其他设备固件的接口。例如，生产机械和测试设备的固件与生产控制软件接口。

SQA组件

软件质量保证（SQA）是一系列确保软件工程过程质量的活动。它确保开发的软件满足并符合定义或标准化的质量规范。SQA 是软件开发生命周期 (SDLC) 中的一个持续流程，定期检查开发的软件以确保其满足所需的质量指标。

SQA 实践在大多数类型的软件开发中都得到实现，无论使用何种底层软件开发模型。SQA 合并并实施软件测试方法来测试软件。SQA 不是在完成后检查质量，而是在开发的每个阶段进行质量测试，直到软件完成。通过 SQA，只有当前/前一阶段符合所需的质量标准后，软件开发过程才会进入下一阶段。SQA 通常遵循一项或多项行业标准，帮助构建软件质量指南和实施策略。

它包括以下活动 -

• 流程定义和实施
• 审计
• 训练

流程可以是 -

• 软件开发方法论
• 项目管理
• 配置管理
• 需求开发/管理
• 预估
• 软件设计
• 测试等

一旦流程被定义和实施，质量保证就有以下职责 -

• 识别流程中的弱点
• 纠正这些弱点以持续改进流程

SQA系统的组成部分

SQA 系统总是结合了广泛的 SQA 组件。这些组件可以分为以下六类 -

项目前组件

这确保了考虑到所需资源、时间表和预算，明确界定了项目承诺；正确确定了发展计划和质量计划。

项目生命周期活动评估的组成部分

项目生命周期由两个阶段组成：开发生命周期阶段和运维阶段。

开发生命周期阶段组件检测设计和编程错误。其组件分为以下子类：评论、专家意见和软件测试。

运维阶段使用的SQA组件包括专门的维护组件和开发生命周期组件，主要用于改进维护任务的功能。

基础设施错误预防和改进的组成部分

这些组件应用于整个组织，其主要目标是根据组织积累的 SQA 经验消除或至少降低错误率。

软件质量管理的组成部分

此类组件涉及多个目标，例如开发和维护活动的控制，以及引入主要防止或最大程度地减少进度和预算失败及其结果的早期管理支持行动。

标准化、认证和 SQA 体系评估的组成部分

这些组件在组织内实施国际专业和管理标准。该课程的主要目标是利用国际专业知识，改善组织质量体系与其他组织的协调，并根据通用标准评估质量体系的成就。各种标准可分为两大类：质量管理标准和项目过程标准。

组织 SQA——人员组成部分

SQA 组织基础包括管理人员、测试人员、SQA 部门以及对软件质量感兴趣的人员，如 SQA 受托人、SQA 委员会成员和 SQA 论坛成员。他们的主要目标是启动和支持 SQA 组件的实施，检测 SQA 程序和方法的偏差，并提出改进建议。

项目前软件质量组件

这些组件有助于改进项目开始前采取的初步步骤。它包括 -

• 合同审查
• 开发和质量计划

合同审查

通常，软件是为了与客户协商的合同或为了开发要嵌入到硬件产品中的固件的内部订单而开发的。在所有这些情况下，开发单位都致力于商定的功能规范、预算和时间表。因此，合同审查活动必须包括对项目建议书草案和合同草案的详细审查。

具体来说，合同审查活动包括 -

• 明确客户的要求

• 审查项目进度和资源需求估计

• 评估专业人员执行拟议项目的能力

• 评估客户履行义务的能力

• 开发风险评估

开发和质量计划

与组织或同一组织的内部部门签订软件开发合同后，准备项目的开发计划及其综合质量保证活动。这些计划包括基于先前计划的额外细节和所需的修订，这些计划为当前提案和合同提供了基础。

大多数情况下，从提交投标到签订合同需要几个月的时间。在此期间，人员可用性、专业能力等资源可能会发生变化。然后对计划进行修订，以反映在此期间发生的变化。

项目开发计划中处理的主要问题是 -

• 时间表
• 所需人力及硬件资源
• 风险评估
• 组织问题：团队成员、分包商和合作伙伴
• 项目方法论、开发工具等
• 软件重用计划

项目质量计划中处理的主要问题是 -

• 以适当的可衡量术语表达的质量目标

• 每个项目阶段的开始和结束标准

• 审查、测试和其他预定验证和确认活动的列表

软件质量指标

软件指标可以分为三类 -

• 产品指标- 描述产品的特征，例如尺寸、复杂性、设计特征、性能和质量水平。

• 流程指标- 这些特征可用于改进软件的开发和维护活动。

• 项目指标- 该指标描述了项目特征和执行情况。示例包括软件开发人员的数量、软件生命周期内的人员配置模式、成本、进度和生产力。

某些指标属于多个类别。例如，项目的过程质量指标既是过程指标又是项目指标。

软件质量度量是软件度量的一个子集，重点关注产品、过程和项目的质量方面。这些与流程和产品指标的关系比与项目指标的关系更密切。

软件质量指标可以进一步分为三类 -

• 产品质量指标
• 过程中的质量指标
• 维护质量指标

产品质量指标

该指标包括以下内容 -

• 平均无故障时间
• 缺陷密度
• 客户问题
• 客户满意度

平均无故障时间

这是失败之间的时间。该指标主要用于安全关键系统，例如航空交通控制系统、航空电子设备和武器。

缺陷密度

它衡量相对于以代码行或功能点等表示的软件大小的缺陷，即衡量每个单元的代码质量。该指标用于许多商业软件系统。

客户问题

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

问题指标通常以每个用户月的问题数 (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{在开发阶段已消除的缺陷}{产品中潜在的缺陷} \times 100\%$$

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

维护质量指标

虽然在此阶段无法做太多事情来改变产品的质量，但可以采取以下修复措施，以尽快消除缺陷，并具有出色的修复质量。

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

修复积压和积压管理索引

修复积压与缺陷到达率以及报告问题的修复可用的速度有关。这是每个月末或每周仍存在的已报告问题的简单计数。以趋势图的形式使用该指标，可以为管理维护过程提供有意义的信息。

积压管理指数（BMI）用于管理未决和未解决问题的积压。

$$BMI = \frac{该月期间已关闭的问题数量}{该月期间到达的问题数量} \次100\%$$

如果BMI大于100，则意味着积压减少。如果 BMI 小于 100，则积压量增加。

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

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

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

逾期修复百分比

计算如下 -

$百分比\:拖欠\:修复=$

$\frac{超出响应时间标准的修复次数（按严重度级别）}{修复次数：已交付\: 在\:指定\:时间} \乘以100\%$

修复质量

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

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

通常延迟越长，受影响的客户就越多。如果缺陷数量很大，那么百分比指标的较小值将显示乐观的情况。当然，维护过程的质量目标是零缺陷修复且无拖欠。

测量基础知识

测量是测量某事物的Behave。它是将一个数字分配给一个对象或事件的特征，可以与其他对象或事件进行比较。

形式上它可以定义为将数字或符号分配给现实世界中实体的属性的过程，以便根据明确定义的规则来描述它们。

日常生活中的测量

测量不仅被专业技术人员使用，而且也被我们所有人在日常生活中使用。在商店中，价格是衡量商品价值的标准。同样，高度和尺寸测量将确保布料是否合适。因此，测量将帮助我们将一个项目与另一个项目进行比较。

测量获取有关实体属性的信息。实体是一个对象，例如一个人或一个事件，例如现实世界中的旅程。属性是实体的特征或性质，例如人的身高、旅程的成本等。在现实世界中，即使我们正在考虑测量事物，但实际上我们正在测量这些事物的属性。

属性主要由数字或符号定义。例如，价格可以指定为卢比或美元数，服装尺寸可以指定为小号、中号、大号。

测量的准确性取决于测量仪器以及测量的定义。获得测量结果后，我们必须对其进行分析，并得出有关实体的结论。

测量是一种直接量化，而计算是一种间接量化，我们使用一些公式组合不同的测量结果。

软件工程测量

软件工程涉及管理、成本核算、规划、建模、分析、指定、设计、实施、测试和维护软件产品。因此，测量在软件工程中起着重要作用。衡量软件产品的属性需要严格的方法。

对于大多数开发项目来说，

• 我们未能为我们的软件产品设定可衡量的目标
• 我们无法理解和量化软件项目的组件成本
• 我们不量化或预测我们生产的产品的质量

因此，为了控制软件产品，测量属性是必要的。每个测量行动都必须由明确定义且易于理解的特定目标或需求驱动。衡量目标必须具体，尽量做到管理者、开发人员和用户需要了解的内容。需要进行测量来评估项目、产品、流程和资源的状态。

在软件工程中，测量对于以下三个基本活动至关重要 -

• 了解开发和维护期间发生的情况
• 控制项目中发生的事情
• 改进流程和目标

测量表征理论

测量告诉我们为开发和推理各种测量奠定基础的规则。它是从经验世界到形式关系世界的映射。因此，度量是通过此映射分配给实体的数字或符号，以便表征实体。

经验关系

在现实世界中，我们通过比较来理解事物，而不是通过给它们分配数字。

例如，为了比较身高，我们使用术语“高于”、“高于”。因此，这些“高于”、高于“是身高的经验关系。

我们可以在同一集合上定义多个经验关系。

例如，X 比 Y 高。X、Y 比 Z 高得多。

经验关系可以是一元、二元、三元等。

X 很高，Y 不高是一元关系。

X 比 Y 高是二元关系。

现实世界中的经验关系可以映射到形式数学世界。这些关系大多反映了个人偏好。

用于将这些经验关系映射到数学世界的一些映射或评级技术如下 -

利开特式量表

在这里，用户将收到一份他们必须同意或不同意的声明。

例如- 该软件表现良好。

强制排名

将给定的替代方案从 1（最好）到 n（最差）排序。

例如：按照性能对以下5个软件模块进行排名。

言语频率量表

例如- 该程序失败的频率是多少？

序数尺度

在这里，用户将获得一份替代方案列表，他们必须选择一个。

例如- 该程序失败的频率是多少？

• 每小时
• 日常的
• 每周
• 每月
• 一年几次
• 每年一次或两次
• 绝不

比较规模

在这里，用户必须通过比较不同的选项来给出一个数字。

非常优越 大致相同非常差

1 2 3 4 5 6 7 8 9 10

数值尺度

这里，用户必须根据其重要性给出一个数字。

不重要重要

1 2 3 4 5 6 7 8 9 10

映射规则

为了执行映射，我们必须指定域、范围以及执行映射的规则。

例如- 域 - 现实世界

• 范围- 数学世界，例如整数、实数等。

• 规则- 用于测量身高、是否穿鞋

同样，在软件测量的情况下，要包含在要指定的代码行中的语句的清单。

测量的代表性条件

表征条件断言测量映射（M）必须将实体映射为数字，将经验关系映射为数值关系，使得经验关系得以保存并被数值关系所保存。

例如：经验关系“高于”映射到数值关系“>”。即，X 高于 Y，当且仅当 M(X) > M(Y)

由于给定集合上可能存在许多关系，因此表征条件也对这些关系中的每一个都有影响。

对于一元关系“is high”，我们可能有数值关系

X > 50

代表性条件要求对于任何测度M，

X 是高的当且仅当 M(X) > 50

正式测量的关键阶段

测量的关键阶段可总结如下 -

测量和模型

模型对于解释现实世界实体的数值元素的Behave以及测量它们非常有用。为了帮助测量过程，映射模型还应该补充映射域模型。模型还应指定这些实体如何与属性相关以及特征如何相关。

测量有两种类型 -

• 直接测量
• 间接测量

直接测量

这些是可以在不涉及任何其他实体或属性的情况下进行测量的测量值。

软件工程中常用以下直接措施。

• 按 LOC 的源代码长度
• 按已用时间划分的测试目的持续时间
• 通过计数缺陷在测试过程中发现的缺陷数量
• 程序员花在程序上的时间

间接测量

这些是可以根据任何其他实体或属性来测量的测量值。

软件工程中常用以下间接措施。

$$\小程序员\:生产力 = \frac{LOC \: 产生的}{人\:月\:努力}$$

$\小模块缺陷密度 = \frac{缺陷数量}{模块大小}$

$$\小缺陷检测效率 = \frac{检测到的缺陷数量}{缺陷总数}$$

$\小要求稳定性 = \frac{初始要求数量}{总要求数量}$

$\小测试有效性比率 = \frac{覆盖的项目数}{项目总数}$

$\小系统损坏 = \frac{修复故障所花费的努力}{项目总努力}$

预测测量

为了向项目分配适当的资源，我们需要预测开发项目的工作量、时间和成本。预测的测量总是需要一个数学模型，将要预测的属性与我们现在可以测量的其他属性联系起来。因此，预测系统由数学模型和一组用于确定未知参数并解释结果的预测程序组成。

测量秤

测量尺度是用于表示经验关系系统的映射。主要有5种类型 -

• 标称规模
• 序数尺度
• 区间尺度
• 比例尺
• 绝对规模

标称规模

它将元素放置在分类方案中。课程不会被订购。每个实体都应根据属性的值放置在特定的类或类别中。

它有两个主要特点 -

• 经验关系系统仅由不同的类组成；类之间没有顺序的概念。

• 类的任何不同编号或符号表示都是可接受的度量，但没有与数字或符号相关的大小概念。

序数尺度

它将元素放置在有序的分类方案中。它具有以下特点 -

• 经验关系系统由根据属性排序的类组成。

• 任何保留顺序的映射都是可接受的。

• 数字仅代表排名。因此，加法、减法和其他算术运算没有任何意义。

区间尺度

该尺度捕获有关分隔分类的间隔大小的信息。因此，它比名义尺度和序数尺度更强大。

它具有以下特点 -

• 它像序数尺度一样保持顺序。

• 它保留差异，但不保留比率。

• 可以在此范围内执行加法和减法，但不能执行乘法或除法。

如果一个属性在区间尺度上是可测量的，并且M和M'是满足表示条件的映射，那么我们总是可以找到两个数字a和b，使得：

M = aM' + b

比例尺

这是最有用的测量尺度。这里，捕获率存在经验关系。它具有以下特点 -

• 它是一种测量映射，保留了顺序、实体之间的间隔大小以及实体之间的比率。

• 有一个零元素，代表完全缺乏属性。

• 测量映射必须从零开始并以相等的间隔（称为单位）增加。

• 可以应用所有算术运算。

这里，映射的形式为

M = aM'

其中“a”是正标量。

绝对规模

在这种规模上，属性只有一种可能的度量。因此，唯一可能的转变就是身份转变。

它具有以下特点 -

• 通过计算实体集中元素的数量来进行测量。

• 该属性始终采用“实体中 x 出现的次数”的形式。

• 只有一种可能的测量映射，即实际计数。

• 可以对结果计数执行所有算术运算。

实证研究

实证研究涉及对任何工具、技术或方法的科学研究。本次调查主要有以下4个原则。

• 选择调查技术
• 陈述假设
• 保持对变量的控制
• 让调查变得有意义

选择调查技术

软件工程实证研究的关键组成部分是 -

• 民意调查
• 案例分析
• 正式实验

民意调查

调查是对情况进行回顾性研究，以记录关系和结果。它总是在事件发生后完成。例如，在软件工程中，可以执行民意调查来确定用户对特定方法、工具或技术的反应，从而确定趋势或关系。

在这种情况下，我们无法控制眼前的情况。我们可以记录一种情况并将其与类似的情况进行比较。

案例分析

这是一种研究技术，您可以确定可能影响活动结果的关键因素，然后记录该活动：其输入、约束、资源和输出。

正式实验

这是对一项活动进行严格的受控调查，其中确定并操纵关键因素以记录其对结果的影响。

可以根据以下准则选择特定的调查方法 -

• 如果活动已经发生，我们可以进行调查或案例研究。如果尚未发生，则可以选择案例研究或正式实验。

• 如果我们对影响结果的变量有高度的控制，那么我们就可以使用实验。如果我们无法控制变量，那么案例研究将是首选技术。

• 如果无法在更高水平上进行复制，那么实验就不可能进行。

• 如果复制成本低，那么我们可以考虑实验。

陈述假设

为了促进特定调查技术的决策，研究的目标应该表达为我们想要测试的假设。假设是程序员认为可以解释他们想要探索的Behave的尝试性理论或假设。

保持对变量的控制

陈述假设后，接下来我们必须决定影响其真实性的不同变量以及我们对其拥有多少控制权。这是至关重要的，因为实验和案例研究之间的关键区别在于对影响Behave的变量的控制程度。

正式实验中用状态变量来区分控制情况和实验情况，状态变量是表征项目的因素，也能影响评价结果。如果我们无法区分控制与实验，案例研究技术将是首选技术。

例如，如果我们想确定编程语言的变化是否会影响项目的生产力，那么语言将是一个状态变量。假设我们当前正在使用 FORTRAN，我们希望将其替换为 Ada。然后 FORTRAN 将作为控制语言，Ada 将作为实验语言。

让调查变得有意义

实验的结果通常比案例研究或调查更具有普遍性。案例研究或调查的结果通常仅适用于特定组织。以下几点证明了这些技术回答各种问题的效率。

符合理论和传统智慧

案例研究或调查可用于在单个组织中验证传统观点和许多其他标准、方法或工具的有效性和实用性。然而，正式的实验可以调查那些主张通常正确的情况。

探索关系

资源和软件产品的各种属性之间的关系可以通过案例研究或调查来表明。

例如，对已完成项目的调查可以显示，用特定语言编写的软件比用其他语言编写的软件具有更少的错误。

理解和验证这些关系对于任何未来项目的成功都至关重要。这些关系中的每一个都可以表达为假设，并且可以设计正式的实验来测试这些关系的维持程度。通常，通过保持其他属性不变或受控来观察一个特定属性的值。

评估模型的准确性

模型通常用于预测活动的结果或指导方法或工具的使用。在设计实验或案例研究时，它提出了一个特别困难的问题，因为他们的预测往往会影响结果。项目经理经常将预测转化为完成目标。当使用成本和进度模型时，这种效应很常见。

某些模型（例如可靠性模型）不会影响结果，因为在软件准备好在现场使用之前，无法评估以平均故障时间衡量的可靠性。

验证措施

有许多软件措施可以捕获属性的值。因此，必须进行一项研究来测试给定的度量是否反映了它应该捕获的属性的变化。验证是通过将一项措施与另一项措施相关联来进行的。第二个衡量标准也是影响因素的直接有效衡量标准，应用于验证。这些措施并不总是可用或易于衡量。此外，所使用的测量必须符合人类对被测量因素的观念。

软件测量

软件测量框架基于三个原则 -

• 对要审查的实体进行分类
• 确定相关的测量目标
• 确定组织已达到的成熟度水平

对审查对象进行分类

在软件工程中，主要存在三类实体。他们是 -

• 流程
• 产品
• 资源

所有这些实体都有内部实体和外部实体。

• 内部属性是那些可以纯粹根据流程、产品或资源本身来衡量的属性。例如：大小、复杂性、模块之间的依赖关系。

• 外部属性是那些只能根据其与环境的关系来测量的属性。例如：用户经历的失败总数、搜索数据库和检索信息所需的时间长度。

每个实体可以测量的不同属性如下 -

流程

流程是与软件相关的活动的集合。以下是一些可以直接测量流程的内部属性 -

• 流程或其活动之一的持续时间

• 与流程或其活动之一相关的工作

• 流程或其一项活动期间发生的指定类型事件的数量

过程的不同外部属性是成本、可控性、有效性、质量和稳定性。

产品

产品不仅是管理层承诺交付的项目，而且是软件生命周期中产生的任何工件或文档。

不同的内部产品属性包括尺寸、工作量、成本、规格、长度、功能、模块化、重用、冗余和语法正确性。其中，规模、工作量和成本比其他因素相对容易衡量。

不同的外部产品属性是可用性、完整性、效率、可测试性、可重用性、可移植性和互操作性。这些属性不仅描述代码，还描述支持开发工作的其他文档。

资源

这些是流程活动所需的实体。它可以是软件生产的任何输入。它包括人员、材料、工具和方法。

资源的不同内部属性是寿命、价格、大小、速度、内存大小、温度等。不同的外部属性是生产力、体验、质量、可用性、可靠性、舒适度等。

确定相关的测量目标

仅当特定测量有助于理解过程或其最终产品之一时，它才有用。只有当项目对过程和产品有明确的目标时，过程或产品的改进才能进行。对目标的清晰理解可用于在流程成熟度框架的背景下为给定项目生成建议的指标。

目标-问题-度量 (GQM) 范式

GQM 方法提供了一个框架，涉及以下三个步骤 -

• 列出开发或维护项目的主要目标

• 从每个目标中得出必须回答的问题，以确定目标是否得到实现

• 决定必须测量什么才能充分回答问题

要使用 GQM 范式，首先我们表达组织的总体目标。然后，我们生成问题，以便知道答案，以便我们可以确定是否实现了目标。随后，根据回答每个问题所需的测量来分析每个问题。

典型的目标用生产力、质量、风险、客户满意度等来表达。目标和问题是根据其受众来构建的。

为了帮助生成目标、问题和指标，Basili & Rombach 提供了一系列模板。

• 目的- （描述、评估、预测、激励等）（流程、产品、模型、指标等），以便理解、评估、管理、设计、学习、改进等。示例：描述产品以便学习它。

• 视角- 从开发人员、经理、客户等的角度检查（成本、有效性、正确性、缺陷、变更、产品措施等）。示例：从客户的角度检查缺陷。

• 环境- 环境由以下内容组成：流程因素、人员因素、问题因素、方法、工具、约束等。示例：该软件的客户是那些对工具一无所知的人。

测量和流程改进

通常测量对于 -

• 了解流程和产品
• 建立基线
• 访问并预测结果

根据SEI给出的过程的成熟度级别，测量的类型和测量程序会有所不同。以下是可应用于每个成熟度级别的不同测量程序。

第 1 级：临时

在这个层面上，输入是不明确的，而输出是预期的。从输入到输出的转换是未定义且不受控制的。对于这种级别的流程成熟度，需要基线测量来提供测量的起点。

2 级：可重复

在此级别，流程的输入和输出、约束和资源是可识别的。下图可以描述可重复的过程。

输入测量可以是需求的规模和波动性。输出可以根据系统规模、根据员工工作量的资源以及根据成本和进度的约束来衡量。

第 3 级：定义

在此级别，定义了中间活动，并且了解和理解它们的输入和输出。下图描述了定义流程的一个简单示例。

中间活动的输入和输出可以被检查、测量和评估。

4 级：托管

在此级别，早期项目活动的反馈可用于设置当前活动和以后项目活动的优先级。我们可以衡量流程活动的有效性。该测量反映了整个过程以及主要活动之间和之间相互作用的特征。

第五级：优化

在此级别，活动测量用于通过删除和添加流程活动以及响应测量反馈动态更改流程结构来改进流程。因此，流程变更会影响组织、项目以及流程。该过程将充当传感器和监视器，我们可以根据警告信号显着改变该过程。

在给定的成熟度级别，我们可以收集该级别及其以下所有级别的测量结果。

确定成熟度水平

流程成熟度建议仅衡量可见的内容。因此，流程成熟度与 GQM 的结合将提供最有用的衡量标准。

• 在第 1 级，项目可能有不明确的需求。在这个层面上，需求特征的测量是很困难的。

• 在级别 2，需求被明确定义，并且可以收集附加信息，例如每个需求的类型和每个类型的更改数量。

• 在第3级，中间活动被定义为每个活动的进入和退出标准。

目标和问题分析是相同的，但衡量标准会随着成熟度的不同而变化。过程越成熟，测量结果就越丰富。GQM 范式与流程成熟度相结合，已被用作多种工具的基础，帮助管理者设计测量程序。

GQM 有助于理解衡量属性的必要性，而流程成熟度表明我们是否有能力以有意义的方式衡量它。它们共同提供了测量的背景。

软件测量验证

验证软件系统的测量涉及两个步骤 -

• 验证测量系统
• 验证预测系统

验证测量系统

测量或测量系统用于通过数字表征现有实体的一项或多项属性来评估现有实体。如果一个测量准确地描述了它声称要测量的属性，那么它就是有效的。

验证软件测量系统是通过表明满足表示条件来确保测量是所要求的属性的正确数字表征的过程。

为了验证测量系统，我们需要一个描述实体的形式模型和一个保留我们正在测量的属性的数值映射。例如，如果有两个程序 P1 和 P2，并且我们想要连接这些程序，那么我们期望任何长度m的度量都满足这一点，

m(P1+P2) = m(P1) + m(P2)

如果程序P1的长度大于程序P2的长度，则任何度量m也应满足，

m(P1) > m(P2)

程序的长度可以通过计算代码行数来衡量。如果这个计数满足上述关系，我们可以说代码行数是长度的有效度量。

验证测量的正式要求包括证明它在测量理论意义上表征了所述属性。验证可用于确保测量器被正确定义并且与实体的现实世界Behave一致。

验证预测系统

预测系统用于预测未来实体的某些属性，涉及具有相关预测过程的数学模型。

在给定环境中验证预测系统是通过经验手段确定预测系统准确性的过程，即通过将模型性能与给定环境中的已知数据进行比较。它涉及实验和假设检验。

验证可接受的准确度取决于预测系统是确定性的还是随机的以及进行评估的人员。一些随机预测系统比其他系统更具随机性。

随机预测系统的例子有软件成本估计、工作量估计、进度估计等系统。因此，为了正式验证预测系统，我们必须确定它的随机性，然后将预测系统的性能与已知数据进行比较。

软件测量指标

软件度量是一种测量标准，包含许多涉及某种程度测量的活动。它可以分为三类：产品指标、过程指标和项目指标。

• 产品指标描述了产品的特征，例如尺寸、复杂性、设计特征、性能和质量水平。

• 流程指标可用于改进软件开发和维护。示例包括开发期间缺陷消除的有效性、测试缺陷到达的模式以及修复过程的响应时间。

• 项目指标描述了项目特征和执行情况。示例包括软件开发人员的数量、软件生命周期内的人员配置模式、成本、进度和生产力。

某些指标属于多个类别。例如，项目的过程质量指标既是过程指标又是项目指标。

软件指标的范围

软件指标包含许多活动，其中包括以下内容 -

• 成本和工作量估算
• 生产力衡量和模型
• 数据采集
• 数量模型和测量
• 可靠性模型
• 绩效与评估模型
• 结构和复杂性指标
• 能力——成熟度评估
• 按指标管理
• 方法和工具评估

软件度量是这些活动的多样化集合，范围从预测特定阶段软件项目成本的模型到程序结构的度量。

成本和工作量估算

工作量被表示为一个或多个变量的函数，例如程序的大小、开发人员的能力和重用程度。成本和工作量估计模型已被提出来预测软件生命周期早期阶段的项目成本。提出的不同模型是 &minu