软件质量管理 – 快速指南

---

软件质量管理 – 介绍

质量软件是指合理地没有错误或缺陷、在规定的预算内按时交付、满足要求和/或期望并且可维护的软件。在软件工程环境中，软件质量反映了功能质量和结构质量。

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

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

• 软件质量保证– 软件质量保证 (SQA) 是一组活动，以确保最终产生优质软件产品的软件工程过程的质量。这些活动建立和评估生产产品的过程。它涉及以过程为中心的行动。

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

软件质量挑战

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

产品复杂性

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

产品可见性

由于工业产品是可见的，因此在制造过程中可以检测到其大部分缺陷。此外，在产品中可以很容易地检测到工业产品中缺少零件。但是，存储在软盘或 CD 上的软件产品中的缺陷是不可见的。

产品开发及生产流程

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

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

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

• 制造– 在此阶段，QA 程序用于检测产品本身的故障。在制造的第一阶段发现的产品缺陷通常可以通过改变产品的设计或材料或生产工具来纠正，以消除未来制造的产品中的此类缺陷。

但是，在软件的情况下，唯一可以检测到缺陷的阶段是开发阶段。如果是软件，则不需要产品生产计划和制造阶段，因为软件副本的制造和软件手册的打印是自动进行的。

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

Characteristic	软件产品	其他工业产品
Complexity	数以百万计的操作选项	一千个操作选项
visibility of product	隐形产品 肉眼难以发现缺陷	可见产品 通过视觉有效检测缺陷
Nature of development and production process	可以仅在一个阶段缺陷缺陷	可以检测以下所有阶段的缺陷 产品开发 产品生产计划 制造业

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

软件质量因素

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

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

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

麦考尔因子模型

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

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

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

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

产品运营软件质量因素

根据麦考尔的模型，产品运行类别包括五个软件质量因素，它们处理直接影响软件日常运行的需求。它们如下 –

正确性

这些需求处理软件系统输出的正确性。它们包括 –

• 输出任务

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

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

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

• 信息的可用性。

• 编码和记录软件系统的标准。

可靠性

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

效率

它处理执行软件系统不同功能所需的硬件资源。它包括处理能力（以 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{缺陷\：移除\：期间\：a\：发展\：阶段}{缺陷\：潜在\：在\：\：产品}\times 100\%$$

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

维护质量指标

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

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

修复积压和积压管理索引

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

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

$$BMI = \frac{Number \: of \: questions \: closed \: during \:the \:month {Number \: of \: questions \:到达 \: during \:the \:month} \times 100\%$$

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

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

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

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

拖欠修复百分比

计算如下 –

$Percent \:Delinquent\: 修复 =$

$\frac{Number \: of \:fixed \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \:fixed \: Delivered \: 在 \:a \:specified \:time} \times 100\%$

修复质量

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

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

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

测量基础

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

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

日常生活中的测量

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

测量采用有关实体属性的信息。实体是诸如人之类的对象或诸如现实世界中的旅程之类的事件。属性是实体的特征或属性，例如人的身高、旅行的费用等。在现实世界中，即使我们正在考虑测量事物，实际上我们正在测量这些事物的属性。

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

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

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

软件工程中的测量

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

对于大多数开发项目，

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

因此，为了控制软件产品，测量属性是必要的。每个测量操作都必须由明确定义且易于理解的特定目标或需求驱动。测量目标必须是具体的，试图让管理人员、开发人员和用户知道什么。需要测量来评估项目、产品、过程和资源的状态。

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

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

测量的表征理论

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

经验关系

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

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

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

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

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

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

X 比 Y 高是一个二元关系。

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

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

利开特式量表

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

例如– 该软件运行良好。

Strongly Agree	同意	既不同意也不反对	不同意	强烈鄙视

强制排名

将给定的备选方案从 1（最佳）到 n（最差）排序。

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

Name of Module	秩
Module A
Module B
Module C
Module D
Module E

言语频率量表

例如– 这个程序多久失败一次？

Always	经常	有时	很少	绝不

序数

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

例如– 这个程序多久失败一次？

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

比较量表

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

非常优秀大致相同非常差

1 2 3 4 5 6 7 8 9 10

数字标度

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

不重要重要

1 2 3 4 5 6 7 8 9 10

映射规则

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

例如– 域 – 现实世界

• Range – 数学世界，如整数、实数等。

• 规则– 用于测量高度，要穿或不穿的鞋子

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

测量的表征条件

表征条件断言，测量映射(M)必须将实体映射为数字，并将经验关系映射为数值关系，以使得经验关系保持并由数值关系保持。

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

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

对于一元关系“高”，我们可能有数字关系

X > 50

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

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

正式测量的关键阶段

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

测量和模型

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

测量有两种类型 –

• 直接测量
• 间接测量

直接测量

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

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

• LOC 的源代码长度
• 测试目的的持续时间（按经过时间）
• 通过计数缺陷在测试过程中发现的缺陷数
• 程序员花在程序上的时间

间接测量

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

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

$$\small Programmer\:Productivity = \frac{LOC \: 生产 {Person \:months \:of \:effort}$$

$\small Module\:Defect\:Density = \frac{Number \:of\:defects}{Module \:size}$

$$\small Defect\:Detection\:Efficiency = \frac{Number \:of\:defects\:detected}{Total \:number \:of\:defects}$$

$\small Requirement\:Stability = \frac{Number \:of\:initial\:requirements}{Total \:number \:of\:requirements}$

$\small Test\:Effectiveness\:Ratio = \frac{Number \:of\:items\:covered}{Total \:number \:of \:items}$

$\small System\:spoilage = \frac{Effort \:spent\:for\:fixing\:faults}{Total \:project \:effort}$

预测测量

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

测量秤

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

• 标称比例
• 序数
• 间隔尺度
• 比例尺
• 绝对比例

标称比例

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

它有两个主要特点 –

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

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

序数

它将元素置于有序的分类方案中。它具有以下特点 –

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

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

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

间隔尺度

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

它具有以下特点 –

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

• 它保留差异但不保留比例。

• 加法和减法可以在这个尺度上进行，但不能进行乘法或除法。

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

M = aM’ + b

比例尺

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

• 它是一种保持排序、实体之间的间隔大小和实体之间的比率的测量映射。

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

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

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

在这里，映射将采用以下形式

M = aM’

其中“a”是正标量。

绝对比例

在这个尺度上，一个属性只有一种可能的度量。因此，唯一可能的转换将是身份转换。

它具有以下特点 –

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

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

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

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

实证研究

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

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

选择调查技术

软件工程实证调查的关键组成部分是 –

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

民意调查

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

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

案例分析

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

正式实验

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

可以根据以下指南选择特定的调查方法 –

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

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

• 如果无法在更高级别进行复制，则无法进行实验。

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

陈述假设

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

保持对变量的控制

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

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

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

使调查有意义

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

符合理论和传统智慧

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

探索关系

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

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

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

评估模型的准确性

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

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

验证措施

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

软件测量

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

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

对被审查的实体进行分类

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

• 流程
• 产品
• 资源

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

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

• 外部属性是那些只能根据其与环境的关系来衡量的属性。例如：用户遇到的故障总数，搜索数据库和检索信息所需的时间长度。

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

流程

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

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

• 与流程或其活动之一相关的努力

• 在流程或其中一项活动中发生的特定类型事件的数量

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

产品

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

不同的内部产品属性是大小、工作量、成本、规格、长度、功能、模块化、重用、冗余和句法正确性。在这些规模中，工作量和成本比其他的更容易衡量。

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

资源

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

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

确定相关的测量目标

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

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

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

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

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

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

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

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

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

• 目的– （表征、评估、预测、激励等）（过程、产品、模型、指标等）以了解、评估、管理、设计、学习、改进等。示例：表征产品以学习它。

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

• 环境– 环境包括以下内容：过程因素、人员因素、问题因素、方法、工具、约束等。示例：该软件的客户是那些不了解工具的人。

测量和过程改进

通常测量是有用的 –

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

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

级别 1：临时

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

级别 2：可重复

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

输入度量可以是需求的大小和波动性。可以根据系统规模、人员工作量方面的资源以及成本和进度方面的限制来衡量输出。

级别 3：定义

在这个级别，中间活动被定义，它们的输入和输出是已知和理解的。下图描述了定义过程的一个简单示例。

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

级别 4：管理

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

级别 5：优化

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

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

确定成熟度

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

• 在第 1 级，项目可能有不明确的需求。在这个级别，需求特性的测量是困难的。

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

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

目标和问题分析将是相同的，但指标会随着成熟度的不同而变化。过程越成熟，测量结果就越丰富。GQM 范式与过程成熟度相一致，已被用作多种工具的基础，这些工具可帮助管理人员设计测量程序。

GQM 有助于理解测量属性的必要性，过程成熟度表明我们是否能够以有意义的方式测量它。它们一起提供了测量的上下文。

软件测量验证

验证软件系统的测量包括两个步骤 –

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

验证测量系统

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

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

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

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

如果程序P1 的长度比程序P2长，那么任何度量m也应该满足，

米(P1) > 米(P2)

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

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

验证预测系统

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

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

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

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

软件测量指标

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

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

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

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

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

软件度量的范围

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

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

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

成本和工作量估算

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

• Boehm 的 COCOMO 模型
• 普特南的苗条模特
• Albrecht 的功能点模型

生产力模型和措施

生产力可以被视为价值和成本的函数。每一个都可以分解为不同的可衡量大小、功能、时间、金钱等。生产力模型的不同可能组成部分可以用下图表示。

数据采集

任何测量程序的质量显然都取决于仔细的数据收集。收集的数据可以提炼成简单的图表和图形，以便管理人员了解开发的进度和问题。数据收集对于关系和趋势的科学调查也是必不可少的。

质量模型和措施

质量模型已被开发用于测量产品的质量，否则生产力将毫无意义。这些质量模型可以与生产力模型相结合来衡量正确的生产力。这些模型通常以树状方式构建。上层分支具有重要的高级质量因素，例如可靠性和可用性。

分治法的概念已被实施为衡量软件质量的标准方法。

可靠性模型

大多数质量模型都将可靠性作为一个组成因素，然而，预测和测量可靠性的需要导致了可靠性建模和预测的独立专业化。可靠性理论的基本问题是预测系统最终何时会失效。

性能评估和模型

它包括外部可观察的系统性能特征，例如响应时间和完成率，以及系统的内部工作情况，例如算法的效率。这是质量的另一个方面。

结构和复杂性指标

在这里，我们测量软件表示的结构属性，这些属性在执行之前可用。然后我们尝试建立经验预测理论来支持质量保证、质量控制和质量预测。

能力成熟度评估

该模型可以评估开发的许多不同属性，包括工具的使用、标准实践等。它基于每个优秀承包商都应该使用的关键实践。

按指标管理

对于管理软件项目，度量具有至关重要的作用。用户和开发人员可以依靠基于测量的图表和图形来检查项目是否正常进行。当软件嵌入到客户通常不精通软件术语的产品中时，标准的测量和报告方法集尤为重要。

方法和工具的评估

这取决于实验设计、对可能影响结果的因素的正确识别以及对因素属性的适当测量。

数据操作

软件度量是一个包含许多活动的度量标准，其中涉及到一定程度的度量。软件测量的成功取决于收集和分析的数据的质量。

什么是好数据？

收集的数据可以被认为是一个很好的数据，如果它可以产生以下问题的答案 –

• 他们是对的吗？– 如果数据是根据度量定义的确切规则收集的，则可以认为数据是正确的。

• 它们准确吗？− 准确度是指数据与实际值之间的差异。

• 它们是否适当精确？– 精度处理表达数据所需的小数位数。

• 它们一致吗？– 如果数据没有显示从一个测量设备到另一个测量设备的重大差异，则可以认为数据是一致的。

• 它们是否与特定活动或时间段相关联？− 如果数据与特定活动或时间段相关，则应在数据中明确说明。

• 它们可以复制吗？− 通常情况下，调查、案例研究和实验等调查经常在不同情况下重复进行。因此，数据也应该可以轻松复制。

如何定义数据？

为测量目的收集的数据有两种类型 –

• 原始数据– 原始数据来自过程、产品或资源的初始测量。例如：组织中员工的每周时间表。

• 精炼数据– 精炼数据是从原始数据中提取基本数据元素以导出属性值的结果。

可以根据以下几点定义数据 –

• 地点
• 定时
• 症状
• 最终结果
• 机制
• 原因
• 严重性
• 成本

如何收集数据？

数据的收集需要人工观察和报告。经理、系统分析员、程序员、测试员和用户必须在表单上记录行数据。为了收集准确和完整的数据，重要的是 –

• 保持程序简单

• 避免不必要的录音

• 培训员工需要记录数据和使用的程序

• 及时以有用的形式向原始提供者提供数据捕获和分析的结果，以帮助他们开展工作

• 验证在中央收集点收集的所有数据

数据收集计划涉及几个步骤 –

• 根据 GQM 分析决定要衡量的产品

• 确保产品处于配置控制之下

• 准确决定要测量的属性以及如何导出间接测量值

• 一旦指标集明确并且要测量的组件集已经确定，设计一个方案来识别测量过程中涉及的每个活动

• 建立处理表格、分析数据和报告结果的程序

数据收集计划必须在项目计划开始时开始。实际数据收集发生在开发的许多阶段。

例如– 一些与项目人员相关的数据可以在项目开始时收集，而其他数据收集（例如工作量）在项目开始时开始并通过运营和维护继续。

如何存储和提取数据

在软件工程中，数据应存储在数据库中并使用数据库管理系统 (DBMS) 进行设置。下图显示了数据库结构的示例。该数据库将存储在组织不同部门工作的不同员工的详细信息。

在上图中，每个框都是数据库中的一张表，箭头表示从一张表到另一张表的多对一映射。映射定义了保持数据逻辑一致性的约束。

一旦设计了数据库并填充了数据，我们就可以使用数据操作语言来提取数据进行分析。

分析软件测量数据

在收集到相关数据后，我们必须以适当的方式对其进行分析。选择分析技术时需要考虑三个主要项目。

• 数据的性质
• 实验目的
• 设计注意事项

数据的本质

为了分析数据，我们还必须查看数据所代表的更大的人口以及该数据的分布。

抽样、总体和数据分布

抽样是从大量人口中选择一组数据的过程。样本统计数据描述和总结了从一组实验对象中获得的度量。

人口参数表示如果测量所有可能的受试者将获得的值。

总体或样本可以通过集中趋势的度量（例如均值、中位数和众数）和离散的度量（例如方差和标准差）来描述。许多数据集呈正态分布，如下图所示。

如上所示，数据将围绕均值均匀分布。这是正态分布的显着特征。

其他分布也存在数据倾斜的情况，因此平均值一侧的数据点多于另一侧。例如：如果大部分数据出现在均值的左侧，那么我们可以说分布向左偏斜。

实验目的

通常，进行实验 –

• 证实一个理论
• 探索关系

为了实现其中的每一个，目标应该以假设的形式正式表达，并且分析必须直接针对假设。

证实一个理论

调查必须旨在探索理论的真实性。该理论通常指出，使用某种方法、工具或技术对受试者有特定的影响，使其在某些方面比其他方面更好。

有两种数据需要考虑：正常数据和非正常数据。

如果数据来自正态分布，并且有两组要比较，则可以使用学生 t 检验进行分析。如果要比较的组多于两个，则可以使用称为 F 统计量的一般方差分析检验。

如果数据是非正态的，则可以使用 Kruskal-Wallis 检验通过对数据进行排序来分析数据。

探索关系

调查旨在确定描述一个或多个变量的数据点之间的关系。

可以使用三种技术来回答有关关系的问题：箱线图、散点图和相关性分析。

• 甲箱线图可以表示一组数据的该范围的摘要。

• 一个散点图表示两个变量之间的关系。

• 相关性分析使用统计方法来确认两个属性之间是否存在真正的关系。

  • 对于正态分布的值，使用Pearson 相关系数检查两个变量是否高度相关。

  • 对于非正态数据，对数据进行排序并使用Spearman Rank Correlation Coefficient作为关联度量。非正态数据的另一个度量是Kendall 稳健相关系数，它调查数据点对之间的关​​系并可以识别偏相关。

如果排名包含大量并列值，则可以使用列联表上的卡方检验来测试变量之间的关联。类似地，线性回归可用于生成方程来描述变量之间的关系。

对于两个以上的变量，可以使用多元回归。

设计注意事项

在选择分析技术时必须考虑调查的设计。同时，分析的复杂性会影响选择的设计。多个组使用 F 统计量，而不是对两个组使用 Student 的 T 检验。

对于具有两个以上因子的复杂因子设计，需要更复杂的关联和显着性检验。

统计技术可用于解释一组变量对其他变量的影响，或补偿时间或学习效果。

内部产品属性

内部产品属性以仅依赖于产品本身的方式描述软件产品。测量内部产品属性的主要原因是，它有助于在开发过程中监控和控制产品。

测量内部产品属性

主要的内部产品属性包括尺寸和结构。尺寸可以静态测量而无需执行它们。产品的大小告诉我们创建它所需的努力。同样，产品的结构在产品的维护设计中也起着重要的作用。

测量尺寸

软件大小可以用三个属性来描述 –

• 长度– 它是产品的物理尺寸。

• 功能– 它描述了产品提供给用户的功能。

• 复杂性– 复杂性有不同的类型，例如。

  • 问题复杂性– 衡量潜在问题的复杂性。

  • 算法复杂性– 衡量为解决问题而实施的算法的复杂性

  • 结构复杂性– 衡量用于实现算法的软件的结构。

  • 认知复杂性– 衡量理解软件所需的努力。

这三个属性的测量可以描述如下 –

长度

共有三种开发产品，其大小测量可用于预测预测所需的工作量。它们是规范、设计和代码。

规格和设计

这些文档通常结合了文本、图形和特殊的数学图表和符号。规格测量可用于预测设计的长度，而设计的长度又是代码长度的预测器。

文档中的图表具有统一的语法，例如带标签的有向图、数据流图或 Z 模式。由于规范和设计文档由文本和图表组成，因此其长度可以用代表文本长度和图表长度的一对数字来衡量。

对于这些测量，将针对不同类型的图表和符号定义原子对象。

数据流图的原子对象是流程、外部实体、数据存储和数据流。代数规范的原子实体是排序、函数、运算和公理。Z 模式的原子实体是规范中出现的各种行。

代码

代码可以通过不同的方式生成，例如过程语言、面向对象和可视化编程。最常用的源代码程序长度的传统度量是代码行数 (LOC)。

总长度，

LOC = NCLOC + CLOC

IE，

LOC = 非注释 LOC + 注释 LOC

除了代码行之外，其他替代方法（例如 Maurice Halsted 建议的大小和复杂性）也可用于测量长度。

Halstead 的软件科学试图捕捉程序的不同属性。他提出了三个内部程序属性，例如长度、词汇量和体积，它们反映了不同的大小视图。

他首先将程序P定义为按运算符或操作数分类的标记集合。这些代币的基本指标是，

• μ₁ = 唯一运算符的数量

• μ₂ = 唯一操作数的数量

• N₁ = 运算符的总出现次数

• N₂ = 唯一运算符的数量

长度P可以定义为

$$N = N_{1}+ N_{2}$$

P的词汇是

$$\mu =\mu_{1}+\mu_{2}$$

程序量 = 编写长度为N的程序所需的心理比较次数，是

$$V = N\times {log_{2}} \mu$$

卷V的程序P的程序级别是，

$$L = \frac{V^\ast}{V}$$

其中，$V^\ast$ 是潜在体积，即P的最小尺寸实现的体积

水平的倒数是难度 –

$$D = 1\diagup L$$

根据 Halstead 理论，我们可以计算一个估计值L为

$${L}’ = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$

同样，估计的程序长度为，$\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

生成 P 所需的努力由下式给出，

$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$

其中测量单位E是理解P所需的基本心理辨别力

测量长度的其他替代方法是 –

• 就程序文本所需的计算机存储字节数而言

• 就程序文本中的字符数而言

面向对象的开发提出了测量长度的新方法。Pfleeger 等人。发现与使用代码行的对象和方法相比，对象和方法的数量导致更准确的生产力估计。

功能

产品中固有的功能量给出了产品尺寸的量度。有许多不同的方法来衡量软件产品的功能。我们将在下一章讨论这样一种方法——Albrecht 的函数点方法。

阿尔布雷希特的功能点法

功能点度量提供了一种用于测量软件应用程序的各种功能的标准化方法。它从用户的角度衡量功能，即基于用户请求和收到的回报。功能点分析是从用户的角度衡量软件开发的标准方法。

随着 1986 年国际功能点用户组 (IFPUG) 的成立，最初由 Albrecht 构想的功能点措施越来越受欢迎。 2002 年，IFPUG 功能点成为国际 ISO 标准 – ISO/IEC 20926。

什么是功能点？

FP（功能点）是适用于量化软件应用程序的最广泛的功能类型指标。它基于五个用户可识别的逻辑“功能”，分为两种数据功能类型和三种交易功能类型。对于给定的软件应用程序，这些元素中的每一个都被量化和加权，计算其特征元素，例如文件引用或逻辑字段。

将得到的数字（未调整的 FP）分组为添加、更改或删除的功能集，并与值调整因子 (VAF) 结合以获得最终的 FP 数。每种计数类型使用不同的最终公式：应用程序、开发项目或增强项目。

应用 Albrecht 的功能点方法

现在让我们了解如何应用 Albrecht 的功能点方法。其程序如下 –

确定组件的数量（EI、EO、EQ、ILF 和 ELF）

• EI – 外部输入的数量。这些是派生数据从外到内跨越边界的基本过程。在示例图书馆数据库系统中，输入现有读者的图书馆卡号。

• EO – 外部输出的数量。这些是派生数据从内到外跨越边界的基本过程。在示例图书馆数据库系统中，显示已借出给读者的图书列表。

• EQ – 外部查询的数量。这些是具有输入和输出组件的基本过程，导致从一个或多个内部逻辑文件和外部接口文件中检索数据。在示例图书馆数据库系统中，确定当前向顾客借出哪些书籍。

• ILF – 内部日志文件的数量。这些是用户可识别的逻辑相关数据组，它们完全位于通过外部输入维护的应用程序边界内。在示例图书馆数据库系统中，图书馆中的书籍文件。

• ELF – 外部日志文件的数量。这些是用户可识别的逻辑相关数据组，仅用于参考目的，并且完全驻留在系统之外。在示例图书馆数据库系统中，包含图书馆计费系统中的交易的文件。

计算未调整的功能点计数 (UFC)

• 将每个组件评级为低、平均或高。

• 对于交易（EI、EO 和 EQ），评级基于FTR和DET。

  • FTR – 更新或引用的文件数量。

  • DET – 用户可识别字段的数量。

  • 根据下表，引用 2 个文件和 10 个数据元素的EI将被列为平均。

FTRs	DET
	1-5	6-15	>15
0-1	低的	低的	平均数
2-3	低的	平均数	高的
>3	平均数	高的	高的

• 对于文件（ILF 和 ELF），评级基于RET和DET。

  • RET – ILF或ELF中用户可识别的数据元素的数量。

  • DET – 用户可识别字段的数量。

  • 根据下表，包含 10 个数据元素和 5 个字段的ILF将被列为高。

RETs	DET
	1-5	6-15	>15
1	低的	低的	平均数
2-5	低的	平均数	高的
>5	平均数	高的	高的

• 将评分转换为UFC。

Rating	价值观
	EO	情商	EI	国际劳工联合会	精灵
Low	4	3	3	7	5
Average	5	4	4	10	7
High	6	5	6	15	10

计算最终功能点数 (FPC)

• 根据 14 个一般系统特性(GSC)计算值调整系数(VAF )。

General System Characteristic		简要描述;简介
GSC 1	数据通讯	有多少通信设施可以帮助与应用程序或系统传输或交换信息？
GSC 2	分布式数据处理	如何处理分布式数据和处理功能？
GSC 3	表现	用户需要响应时间或吞吐量吗？
GSC 4	大量使用的配置	将在其中执行应用程序的当前硬件平台的使用情况如何？
GSC 5	成交率	交易每天、每周、每月等执行的频率如何？
GSC 6	在线数据输入	在线输入信息的百分比是多少？
GSC 7	最终用户效率	应用程序是否为最终用户的效率而设计？
GSC 8	在线更新	在线交易更新了多少个 ILF？
GSC 9	复杂加工	应用程序是否有广泛的逻辑或数学处理？
GSC 10	可重用性	应用程序是为了满足一个或多个用户的需求而开发的吗？
GSC 11	安装方便	转换和安装有多难？
GSC 12	操作简便	启动、备份和恢复程序的有效性和/或自动化程度如何？
GSC 13	多个站点	应用程序是否专门设计、开发和支持安装在多个组织的多个站点？
GSC 14	促进变革	应用程序是否经过专门设计、开发和支持以促进更改？

• 根据是否有影响到强烈影响，按 0 到 5 的范围权衡每个GSC。

• 计算FPC如下 –

  FPC = UFC &ast (0.65+(sum( GSC ) &ast .01))

复杂

复杂性是规模的一个单独组成部分。它有两种类型 –

• 问题的复杂性– 它是问题的最佳解决方案所需的资源量。

• 解决方案的复杂性– 实施特定解决方案所需的资源。它有两个方面。它们如下 –

  • 时间复杂度– 资源是计算机时间。

  • 空间复杂度– 资源是计算机内存。

测量复杂性

复杂性的一方面是效率。它衡量任何可以建模为算法的软件产品。

例如：如果用于解决特定问题的所有实例的算法需要f(n) 次计算，则f(n)是渐近最优的，如果解决问题f 的复杂度为 g 的所有其他算法都是O(g)。那么，给定问题的复杂度很大 –问题解决方案的渐近最优算法的O。

测量结构

软件结构属性的测量对于估计开发工作以及产品的维护很重要。需求、设计和代码的结构有助于理解在将一种产品转换为另一种产品、测试产品或根据早期内部产品度量预测外部软件属性时出现的困难。

结构措施的类型

软件结构分为三部分。他们是 –

• 控制流结构– 它是在程序中执行指令的顺序。

• 数据流结构– 它是数据与程序交互时的行为。

• 数据结构– 以列表、队列、堆栈或其他定义明确的结构形式组织数据元素以及创建、修改或删除它们的算法。

测量控制流结构

控制流度量通常用有向图建模，其中每个节点或点对应于程序语句，每个弧或有向边表示从一个语句到另一个语句的控制流。这些图被称为控制流图或有向图。

如果“m”是根据流图模型定义的结构度量，并且如果程序A在结构上比程序B复杂，则度量m(A)应该大于m(B)。

测量数据流结构

数据流或信息流可以是模块间的（模块内的信息流）或模块内的（各个模块与系统其余部分之间的信息流）。

根据数据在系统中移动的方式，它可以分为以下几类 –

• 本地直接流– 如果一个模块调用第二个模块并将信息传递给它，或者被调用的模块将结果返回给调用者。

• 本地间接流– 如果被调用的模块返回随后传递给第二个被调用模块的信息。

• 全局流– 如果信息通过全局数据结构从一个模块流到另一个模块。

根据 Henry 和 Kafura 的说法，信息流复杂度可以表示为：

信息流复杂度（M）=长度（M）×扇入（M）×（扇出（M））²

在哪里，

• 扇入 (M) – 终止于 M 的本地流的数量 + M 从中检索信息的数据结构的数量。

• 扇出 (M) – 从 M 发出的本地流的数量 + 由 M 更新的数据结构的数量。

测量数据结构

数据结构既可以是本地的，也可以是全局的。

在本地，将测量每个数据项中的结构量。图论方法可用于分析和测量单个数据结构的属性。因此，整数、字符和布尔值等简单数据类型被视为素数，并考虑了使我们能够构建更复杂数据结构的各种操作。然后可以根据素数的值和与各种操作相关的值来分层定义数据结构度量。

在全局范围内，将测量用户定义变量的总数。

标准和证书

多个国家和国际标准机构、专业和行业组织都参与了 SQA 标准的制定。

以下机构和组织是 SQA 和软件工程标准的主要开发者 –

• IEEE（电气和电子工程师协会）计算机学会
• ISO（国际标准化组织）
• DOD（美国国防部）
• ANSI（美国国家标准协会）
• IEC（国际电工委员会）
• EIA（电子工业协会）

这些组织为软件开发和维护组织中执行的专业和管理活动的质量提供最新的国际标准。

他们还通过独立的专业质量审核提供 SQA 认证。这些外部审计评估 SQA 系统开发及其实施的成就。定期审核后授予的认证仅在下一次审核前有效，因此必须更新。目前，ISO 9000 认证服务是欧洲和其他国家最著名的 SQA 认证提供者。

它们还提供了对组织的 SQA 系统及其操作进行自我评估的工具。由软件工程研究所 (SEI)、卡内基梅隆大学和 ISO/IEC Std 15504 开发的容量成熟度模型 (CMM) 就是这种方法的示例。

质量保证标准

软件质量保证标准可以分为两大类 –

• 软件质量保证管理标准，包括认证和评估方法（质量管理标准）

• 软件项目开发过程标准（project processstandards）

质量管理标准

这些侧重于组织的 SQA 系统、基础设施和要求，同时将方法和工具的选择留给组织。通过质量管理标准，组织可以稳定地确保其软件产品达到可接受的质量水平。

示例– ISO 9000-3 和能力成熟度模型 (CMM)

项目过程标准

这些侧重于实施软件开发和维护项目的方法。这些标准包括以下内容 –

• 要采取的步骤
• 设计文件要求
• 设计文件的内容
• 设计审查和审查问题
• 要执行的软件测试
• 测试主题

自然，由于它们的特性，该类中的许多 SQA 标准可以作为软件工程标准，反之亦然。

下表总结了这两类标准的特点。

Characteristics	质量管理标准	项目过程标准
The target unit	软件开发、维护和特定 SQA 单元的管理	一个软件开发和维护项目团队
The main focus	SQA 系统、基础设施和要求的组织	执行软件开发和维护项目的方法
The standard’s objective	实现“什么”	“如何”执行
The standard’s goal	确保供应商的软件质量并评估其软件过程能力	保证供应商的软件质量并评估其软件过程能力 保证特定软件项目的质量。
Examples	ISO 9000-3 SEI 的 CMM	ISO/IEC 12207 IEEEStd 1012-1998

ISO 9001 认证

ISO（国际标准化组织）是一个全球性的国家标准机构联合会。ISO 技术委员会准备国际标准。ISO 与国际电工委员会 (IEC) 在电工标准化的所有事项上密切合作。

国际标准是根据 ISO/IEC 指令第 2 部分中给出的规则起草的。技术委员会通过的国际标准草案将分发给成员机构进行投票。ISO 9001 由技术委员会 ISO/TC 176，质量管理和质量保证，小组委员会 SC 2，质量体系编写。

过程方法

本国际标准促进在开发、实施和改进质量管理体系有效性时采用过程方法，通过满足顾客要求来提高顾客满意度。一个组织要想有效运作，就必须确定和管理众多相互关联的活动。使用资源并进行管理以将输入转换为输出的一项或一组活动可以被视为一个过程。

通常，一个过程的输出直接形成下一个过程的输入。流程系统在组织内的应用，以及这些流程的识别和交互，以及它们的管理以产生所需的结果，可以称为“流程方法”。

流程方法的一个优点是它对流程系统内各个流程之间的联系以及它们的组合和交互提供持续控制。在质量管理体系中使用时，这种方法强调了以下方面的重要性 –

• 了解并满足要求
• 需要从附加值的角度考虑流程
• 获得过程性能和有效性的结果
• 基于客观测量的过程持续改进

ISO 9001 – 软件应用：TickIT 计划

TickIT 于 1980 年代后期由英国软件行业与英国贸易和工业部合作推出，旨在促进开发一种使 ISO 9001 适应软件行业特征的方法，称为 TickIT 计划。

此外，TickIT 还专注于信息技术 (IT)。它涵盖了整个商业软件开发和维护服务范围。TickIT 现在由 BSI（英国标准协会）的 DISC 部门管理和维护，获得了英国和瑞典 IT 组织的认证。

其活动包括 –

• 出版 TickIT 指南，支持软件行业推广 ISO 9001 认证的努力。当前指南（5.0 版，TickIT，2001）包括对 ISO/IEC 12207 和 ISO/IEC 15504 的引用，已分发给所有 TickIT 客户。

• 对软件质量系统进行基于审计的评估，并就软件开发和维护过程的改进以及管理向组织提供咨询。

• 进行 ISO 9000 认证审核。

进行基于审核的评估和认证审核的 TickIT 审核员由国际认证审核员注册 (IRCA) 注册。注册 IRCA 审核员需要具备管理和软件开发方面的经验；他们还必须成功完成审核员课程。

注册的首席审核员必须具备进行和指导 TickIT 审核的经验。

软件过程评估

软件过程评估是基于过程模型对组织使用的软件过程进行的严格检查。评估包括识别和描述当前实践，识别优势和弱点，以及当前实践控制或避免（软件）质量、成本和进度不佳的重要原因的能力。

软件评估（或审计）可以分为三种类型。

• 一个自我评估（第一方评估）是由组织自己的人员内部执行。

• 一个第二方的评估由外部评估小组进行或组织由客户评估。

• 一个第三方评估由外部一方或（如供应商正在由第三方评估，以验证其进入与客户合同的能力）进行。

软件过程评估是在开放和协作的环境中进行的。它们供组织使用以改进其软件过程，结果对组织保密。被评估的组织必须在评估团队中有成员。

软件过程成熟度评估

软件过程评估的范围可以涵盖组织中的所有过程、选定的软件过程子集或特定项目。大多数基于标准的过程评估方法总是基于过程成熟度的概念。

当评估目标是组织时，过程评估的结果可能会有所不同，即使连续应用相同的方法也是如此。结果不同有两个原因。他们是，

• 必须确定被调查的组织。对于一家大公司，组织的多种定义是可能的，因此评估的实际范围可能会在连续评估中有所不同。

• 即使在看似相同的组织中，选择代表该组织的项目样本也可能影响范围和结果。

当评估的目标单元处于项目级别时，评估应包括所有有助于项目成功或失败的有意义的因素。它不应受给定流程成熟度模型的既定维度限制。在此评估由项目数据证实的实施程度及其有效性。

当组织打算开始整体长期改进战略时，过程成熟度变得相关。软件项目评估应该是独立的评估，以便做到客观。

软件过程评估周期

根据 Paulk 及其同事 (1995) 的说法，基于 CMM 的评估方法使用六步循环。他们是 –

• 选择一个团队——团队成员应该是熟悉软件工程和管理的专业人士。

• 被评估地点的代表完成标准的过程成熟度问卷。

• 评估团队对问卷答复进行分析，并根据 CMM 关键过程领域确定需要进一步探索的领域。

• 评估团队进行现场访问，以了解现场遵循的软件过程。

• 评估团队生成一个发现列表，确定组织软件过程的优势和劣势。

• 评估团队准备关键过程领域 (KPA) 概要分析并将结果呈现给适当的受众。

例如，评估团队必须由授权的 SEI 首席评估员领导。团队必须由四到十名团队成员组成。至少，一名团队成员必须来自被评估的组织，并且所有团队成员必须完成 SEI 的 CMM 入门课程（或同等课程）和 SEI 的 CBA IPI 团队培训课程。团队成员还必须符合一些选择准则。

关于数据收集，CBA IPI 依赖四种方法 –

• 标准成熟度问卷
• 个人和团体面试
• 文件审查
• 与评估参与者一起审查结果草案的反馈

斯坎皮

过程改进的标准 CMMI 评估方法 (SCAMPI) 是为了满足 CMMI 模型要求而开发的（软件工程研究所，2000）。它也基于 CBA IPI。CBA IPI 和 SCAMPI 都由三个阶段组成 –

• 计划和准备
• 进行现场评估
• 报告结果

计划和准备阶段的活动包括 –

• 确定评估范围
• 制定评估计划
• 准备和培训评估团队
• 对参与者进行简要评估
• 管理 CMMI 评估问卷
• 检查问卷答复
• 进行初步文件审查

现场评估阶段的活动包括 –

• 召开开幕会议
• 进行采访
• 整合信息
• 准备报告结果草案
• 提交调查结果草案
• 整合、评价和准备最终结果

报告结果阶段的活动包括 –

• 展示最终结果
• 召开执行会议
• 结束评估

质量保证

IEEE 对软件质量保证的定义如下 –

“为使项目或产品符合既定技术要求提供足够的信心所必需的所有行动的计划和系统模式。旨在评估产品开发或制造过程的一组活动。”

SQA 活动的目标

SQA 活动的目标如下 –

软件开发（面向过程）

• 确保软件将符合功能技术要求的可接受的置信水平。

• 确保软件将符合管理计划和预算要求的可接受程度的置信度。

• 发起和管理活动以改进和提高软件开发和 SQA 活动的效率。

在软件维护（面向产品）

• 以可接受的置信度确保软件维护活动符合功能技术要求。

• 以可接受的置信度确保软件维护活动符合管理计划和预算要求。

• 发起和管理活动以改进和提高软件维护和 SQA 活动的效率。这涉及改善实现功能和管理要求的前景，同时降低成本。

组织质量保证

在组织结构内运作的质量保证组织框架包括以下参与者 –

经理

• 高层管理人员，尤其是直接负责软件质量保证的执行人员

• 软件开发和维护部门经理

• 软件测试部经理

• 开发和维护项目的项目经理和团队负责人

• 软件测试团队负责人

测试员

• 软件测试团队成员

SQA 专业人士和感兴趣的从业者 –

• SQA受托人
• SQA委员会成员
• SQA论坛成员
• SQA 单位团队成员

只有软件测试部门的经理和员工才能全职执行 SQA 任务。其他人则将部分时间用于质量问题，无论是在履行管理职能或专业任务期间，还是作为其他人的志愿者，通常是 SQA 委员会、SQA 论坛或 SQA 受托人。

管理在质量保证中的作用

基本上，软件开发组织中存在三级管理结构 –

• 高层管理人员
• 部门管理
• 项目管理

软件质量的最高管理职责

以下是最高管理层在确保软件质量方面的职责 –

• 保证公司软件产品和软件维护服务的质量

• 向各级员工传达产品和服务质量以及客户满意度的重要性

• 确保令人满意的功能并完全符合客户要求

• 确保为组织的 SQA 体系建立质量目标并确保其目标得以实现

• 启动计划并监督实施必要的变更，以使 SQA 系统适应与组织客户、竞争和技术相关的主要内部和外部变化

• 直接干预以支持解决危机情况并最大限度地减少损失

• 确保 SQA 系统所需资源的可用性

最高管理层可以采取以下步骤来履行其职责 –

• 建立和更新组织的软件质量政策。

• 指派一名高管（例如 SQA 副总裁）负责软件质量问题

• 定期对软件质量问题的绩效进行管理评审

软件质量方针

组织的软件质量政策应传达以下要求 –

• 符合组织的宗旨和目标

• 对一般软件质量保证概念的承诺

• 对组织采用的质量标准的承诺

• 承诺为软件质量保证分配足够的资源

• 致力于持续改进组织的质量和生产力

软件质量主管

负责软件质量问题的执行人员的职责可分为 –

• 负责准备年度 SQA 活动计划和预算

• 负责编制SQA系统开发计划

• 全面控制年度 SQA 常规活动计划和计划的 SQA 发展项目的实施

• 向执行管理层介绍和倡导 SQA 问题

准备年度 SQA 活动计划的责任

这要求行政人员 –

• 制定系统来年的 SQA 目标

• 审查 SQA 部门为年度活动计划准备的提案，并验证提案实现 SQA 系统目标的潜力

• 确定活动计划是否适合来年计划的分包商服务和软件采购的特点和范围

• 确定为实施 SQA 计划而计划的人力和其他资源是否充足

• 批准年度 SQA 活动计划和预算的最终版本

准备 SQA 系统开发计划的责任

这些计划必须适应技术以及客户需求和竞争的变化。职责包括 –

• 审查预计在不久的将来会影响组织软件质量的趋势

• 审查 SQA 调整的建议，例如准备适合新工具和 SQA 标准的新程序

• 为资深软件开发团队和新招募的团队成员准备培训计划

• 开发适用于评估新工具和标准以及培训计划成功的软件质量指标

• 批准计划的 SQA 开发项目的最终版本，包括它们的时间表和预算

年度 SQA 计划实施的总体控制

主管行政人员负责 –

• 年度活动计划的一般监督

• 审查 SQA 适应项目的进展

• 为实现团队目标所规定的质量成就而采取的行动的一般监督（基于定期报告）

• 基于内部质量审计审查 SQA 程序和标准的遵守情况

• 对软件开发项目时间表和预算的合规性的一般跟进

• 为外部和内部客户提供优质维修服务的一般跟进

向执行管理层介绍和倡导 SQA 问题

为了提高质量和解决 SQA 系统的困难，它需要 –

• 最终批准拟议年度活动计划和预算的介绍

• 提交计划的 SQA 适应项目的最终批准以及相应的预算

• 发起和领导专门讨论组织软件质量的定期管理评审会议

• 启动专门针对特殊软件质量事件的管理层讨论，例如严重的质量故障、由于严重的专业人员短缺导致项目成功完成的威胁、SQA 部门的管理危机等

SQA部门管理职责

中层管理人员的质量保证职责包括 –

• 软件质量管理体系的管理（质量体系相关任务）

• 管理特定经理权限下的单位或团队执行的与项目和服务相关的任务（项目相关任务）

质量体系相关职责

这些包括要在部门级别执行的 SQA 活动 –

• 根据 SQA 单位制定的推荐计划，准备部门的年度 SQA 活动计划和预算

• 根据 SQA 单位制定的推荐计划，准备部门的 SQA 系统开发计划

• 部门年度 SQA 活动计划和发展项目的绩效控制

• 向最高管理层介绍部门的 SQA 问题

项目相关职责

这些因组织的程序和权力分配而异；他们通常涉及 –

• 控制部门单位（包括 CAB、SCM 和 SCCA 机构）对质量保证程序的遵守情况

• 合同评审结果和方案审批的详细跟进

• 审查计划审查活动的单位绩效；批准项目文件和项目阶段完成

• 跟踪软件测试和测试结果；批准项目的软件产品

• 跟踪软件开发项目进度和预算偏差的进度

• 为项目经理解决进度、预算和客户关系难题提供建议和支持

• 跟踪维护服务提供的质量

• 详细跟踪项目风险及其解决方案

• 跟踪项目符合客户要求和客户满意度

• 批准大型软件变更单和项目规格的重大偏差

项目管理对软件质量的责任

大多数项目管理职责都在程序和工作指导中定义；项目经理是负责确保所有团队成员遵守上述程序和指示的人。

他的任务包括专业的实践和管理任务，特别是以下 –

• 专业的动手任务

  • 准备项目和质量计划及其更新

  • 参与客户-供应商联合委员会

  • 密切跟进项目团队人员配备，包括参加招聘、培训和指导

• 管理任务

  项目经理解决后续问题，例如 –

  • 审查活动的执行和随之而来的更正

  • 软件开发和维护单元的性能、集成和系统测试活动以及修正和回归测试

  • 验收测试的性能

  • 在远程客户站点安装软件并由客户执行软件系统

  • 项目团队成员的SQA培训和指导

  • 分配给项目活动的时间表和资源

  • 客户要求和满意度

  • 不断变化的项目开发风险、解决方案的应用和结果的控制

SQA 单位

SQA 部门的结构因组织的类型和规模而异。下图显示了一个标准结构和一个 SQA 单元下的所有组件的示例。在本章中，我们将讨论每个子单元的角色和职责。

SQA 部门负责人执行的任务

SQA 部门负责人负责 SQA 部门及其下属部门执行的所有质量保证任务。这些任务可以分为以下几类 –

• 规划任务
• 单位管理
• SQA专业活动

规划任务

• 为单位拟定年度活动计划和预算

• 规划和更新组织的软件质量管理体系

• 为软件开发和维护部门准备推荐的年度 SQA 活动计划和 SQA 系统开发计划

管理任务

• SQA 团队活动的管理

• 监控 SQA 活动计划的实施

• 团队成员、SQA 委员会成员和 SQA 受托人的提名

• 准备特殊和定期报告，例如组织内软件质量问题的状态和月度绩效报告

SQA 专业活动

• 参与项目联合委员会
• 参与正式的设计评审
• 审查和批准与规格的偏差
• 咨询项目经理和团队负责人
• 参与 SQA 委员会和论坛

项目生命周期 SQA

与项目生命周期子单元相关的 SQA 任务可分为两组 –

• “纯”管理跟进审批任务（项目生命周期控制任务）

• “动手”或积极参与需要专业贡献的项目团队 SQA 活动（参与任务）

项目生命周期控制任务

• 跟进开发和维护团队对 SQA 程序和工作指令的遵守情况

• 根据相关程序批准或推荐软件产品

• 监控软件维护服务向内部和外部客户的交付

• 监控客户满意度并与客户的质量保证代表保持联系

参与任务

这些任务包括参与 –

• 合同审查
• 项目开发和质量计划的准备和更新
• 正式的设计审查
• 分包商的正式设计审查
• 软件测试，包括客户验收测试
• 分包商软件产品的软件验收测试
• 安装新的软件产品

SQA 基础设施运营任务

SQA 系统采用各种基础设施组件来平稳运行，即 –

• 程序和工作说明
• 支持优质设备（模板、清单）
• 员工培训、指导和认证
• 预防和纠正措施
• 配置管理
• 文件控制

更具体地说，SQA 子单元关于这些组件的任务包括 –

• 发布程序、工作说明、模板、检查表等的更新版本，并以硬拷贝和/或电子方式进行分发

• 向新员工和现有员工传送有关遵守和应用 SQA 程序、工作指导和类似项目的培训和指导

• SQA 受托人关于新的和修订的程序以及开发工具和方法等内容的说明

• 监督和支持新的和修订的 SQA 程序的实施

• 工作人员认证活动的后续行动

• 需要采取预防和纠正措施的主题的提案，包括参与 CAB 委员会

• 配置管理活动的跟进，包括参与 CCA 委员会

• 跟进文件程序和工作说明的遵守情况

SQA 内部审计和认证任务

在软件组织中或由软件组织进行的 SQA 审计类型可以分类如下 –

• 内部审计

• 对分包商和供应商的审计以评估他们的 SQA 系统

• 认证机构进行的外部审核

• 由希望在接受组织作为供应商之前评估 SQA 系统的客户执行的外部审核

前两类审核由 SQA 子单位发起和执行，后两类由外部机构发起和执行。

SQA 部门为内部 SQA 审核执行以下任务

• 为内部 SQA 审核准备年度计划

• 内部 SQA 审核的执行

• 对被审计组和其他单位进行的整改和改进的跟踪

• 编写审计结果状态的定期总结报告，包括改进建议

SQA 部门为分包商和供应商的审计执行以下任务 –

• 为分包商和供应商的 SQA 审核准备年度计划

• 对分包商和供应商进行 SQA 审核

• 跟进审计分包商和供应商将进行的纠正和改进

• 从内部和外部来源收集有关分包商和供应商绩效的数据

• 根据审计报告和从其他内部和外部来源收集的信息，对组织的认证分包商和供应商的 SQA 系统进行定期评估。评估报告包括 –

  • 关于分包商和供应商认证的建议

  • 认证机构进行的外部审核涉及以下任务 –

    • 协调认证审核的内容和时间表

    • 准备认证机构指定的文件

    • 对被审核团队的指导和认证审核所需准备工作的执行

    • 参与认证审核

    • 确保执行所需的更正和改进

由组织的客户执行的 SQA 审计需要这些任务 –

• 协调审核的内容和时间表

• 准备客户审核员指定的文件

• 对受审核团队的指导以及组织客户对 SQA 审核所需的准备工作的执行情况

• 参与审计

• 确保执行所需的更正和改进

SQA 支持任务

SQA 支持服务的大多数消费者都位于组织内。他们包括项目经理、团队领导和 SQA 受托人。他们的任务包括 –

• 编制项目计划和项目质量计划

• 人员配备审查小组

• 选择解决已识别软件开发风险的措施

• 选择解决进度延误和预算超支的措施

• SQA 指标和软件成本组件的选择

• SQA信息系统的使用

• 选择反映 SQA 单元积累的故障经验数据的开发方法和工具

SQA 标准和程序任务

SQA 子单位密切参与决定采用哪些 SQA 标准以及制定和维护组织的程序。为了履行随之而来的义务，SQA 单位必须 –

• 为开发新程序和程序更新准备年度计划

• 负责新程序的开发和程序更新，并参与适当的委员会和论坛

• 跟踪SQA和软件工程标准的发展变化；引入与组织相关的附加程序和变更

• 启动程序的更新和调整以响应专业标准的变化，包括采用或删除组织应用的标准

SQA 工程任务

跟进专业进展、解决操作困难和专家分析故障是这个 SQA 子单位的直接目标。

因此，主要的工程任务涉及以下内容 –

• 测试与新开发工具和当前使用的开发工具的新版本有关的质量和生产力方面

• 评估新开发和维护方法以及方法改进的质量和生产力

• 针对当前使用的软件开发工具和方法在应用中遇到的困难制定解决方案

• 开发测量软件质量和团队生产力的方法

• 在分析软件开发失败和制定建议解决方案期间为 CAB 委员会提供技术支持

SQA 信息系统任务

SQA 信息系统旨在促进和改进 SQA 系统的功能。涉及的任务包括 –

• 为软件开发和维护单位开发 SQA 信息系统

  • 活动数据的收集

  • 例如，处理定期报告、清单、例外报告和查询

  • 例如，处理定期报告、清单、例外报告和查询

• 开发 SQA 信息系统，促进 SQA 单位处理软件开发和维护单位提供的信息，包括软件质量度量和软件质量成本的估计

• 更新 SQA 信息系统

• 组织的 SQA Internet / Intranet 站点的开发和维护

SQA 受托人及其任务

SQA 受托人是那些主要参与促进软件质量的成员。这些成员提供成功实施 SQA 组件所需的内部支持。

他们的任务可能因组织而异。因此，它可能是与单位相关和/或与组织相关的任务。

单位相关任务

• 支持同事解决软件质量程序和工作指导书实施过程中的困难

• 协助单位经理执行相关的SQA任务

• 促进合规并监督 SQA 程序和同事工作指导的实施

• 向 SQA 部门报告大量和系统的不合规事件

• 向 SQA 部门报告严重的软件质量故障

组织相关任务

• 触发组织范围的 SQA 程序和工作指令的更改和更新

• 触发组织中开发和维护流程的改进

• 向 CAB 申请解决在各自单位中观察到的经常性故障的解决方案

• 确定整个组织的 SQA 培训需求，并提出由 SQA 部门进行的适当培训或指导计划

SQA 委员会及其任务

SQA 委员会可以是永久性的，也可以是临时的。任务可能因组织而异。

• 常设委员会通常处理 SCC（软件变更控制）、CA（纠正措施）、程序、方法开发工具和质量指标。

• 特设委员会通常处理具有普遍意义的特定案例，例如更新特定程序、软件故障的分析和解决方案、为目标过程或产品制定软件度量标准、更新软件质量成本和针对特定问题的数据收集方法。

常设 SQA 委员会是 SQA 组织框架的组成部分；他们的任务和操作通常在组织的 SQA 程序中定义。

临时委员会是针对每个问题在短期内建立的，成员由负责软件质量问题的执行官、SQA 部门负责人、SQA 子部门、常设 SQA 委员会或任何其他发起其形成并对工作产生兴趣。该机构还定义了特设委员会的任务。