软件质量管理 - 快速指南

上一页
下一页

软件质量管理 - 简介

高质量软件是指基本上没有错误或缺陷，按时并在指定预算内交付，满足需求和/或期望，并且可维护的软件。在软件工程的背景下，软件质量反映了**功能质量**和**结构质量**。

  • **软件功能质量** - 它反映了软件在多大程度上满足给定的设计，基于功能需求或规范。

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

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

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

软件质量挑战

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

产品复杂性

它是产品允许的操作模式的数量。通常，工业产品仅允许少于几千种操作模式，以及其机器设置的不同组合。但是，软件包允许数百万种操作可能性。因此，正确保证所有这些操作可能性对软件行业来说是一个重大挑战。

产品可见性

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

产品开发和生产过程

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

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

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

  • **制造** - 在此阶段，应用 QA 程序来检测产品本身的故障。在制造初期检测到的产品缺陷通常可以通过更改产品的设计或材料或生产工具来纠正，从而消除将来制造的产品中的此类缺陷。

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

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

特征 软件产品 其他工业产品
复杂性 数百万个操作选项 数千个操作选项
产品可见性 不可见产品难以通过目测检测缺陷 可见产品有效地通过目测检测缺陷
开发和生产过程的性质 只能在一个阶段检测缺陷 可以在所有以下阶段检测缺陷
  • 产品开发
  • 产品生产计划
  • 制造

软件的这些特性，例如复杂性和不可见性，使得软件质量保证方法的开发及其成功实施成为一项极具挑战性的专业工作。

软件质量因素

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

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

所有这些模型与 McCall 模型没有太大差异。McCall 因素模型提供了一种实用、最新的软件需求分类方法 (Pressman，2000)。

McCall 因素模型

此模型将所有软件需求分类为 11 个软件质量因素。这 11 个因素分为三类 - 产品操作、产品修订和产品转换因素。

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

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

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

产品操作软件质量因素

根据 McCall 模型，产品操作类别包括五个软件质量因素，这些因素处理直接影响软件日常操作的需求。它们如下 -

正确性

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

  • 输出任务

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

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

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

  • 信息的可用性。

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

可靠性

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

效率

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

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

完整性

此因素处理软件系统安全性，即防止未经授权的人员访问，以及区分要授予读写权限的人员组。

可用性

可用性需求处理培训新员工和操作软件系统所需的员工资源。

产品修订质量因素

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

可维护性

此因素考虑用户和维护人员识别软件故障原因、纠正故障以及验证更正成功所需的努力。

灵活性

此因素处理支持软件的自适应维护活动所需的功能和努力。这些包括使当前软件适应其他情况和客户，而无需更改软件。此因素的需求还支持完善性维护活动，例如更改和添加软件以改进其服务并使其适应公司技术或商业环境的变化。

可测试性

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

产品转换软件质量因素

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

可移植性

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

可重用性

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

互操作性

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

软件质量保证组件

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

软件质量保证 (SQA) 实践在大多数类型的软件开发中都有应用，无论使用何种底层软件开发模型。SQA 整合并实施软件测试方法来测试软件。与其在软件完成后再检查质量，SQA 流程在开发的每个阶段都测试质量，直到软件完成。使用 SQA，只有在当前/前一阶段符合所需的质量标准后，软件开发过程才会进入下一阶段。SQA 通常基于一个或多个行业标准，这些标准有助于构建软件质量指南和实施策略。

它包括以下活动 -

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

流程可能包括 -

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

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

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

SQA 系统的组成部分

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

项目前组件

这确保了项目承诺在考虑所需资源、时间表和预算的情况下得到明确定义；并且开发和质量计划已正确确定。

项目生命周期活动评估组件

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

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

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

基础设施错误预防和改进组件

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

软件质量管理组件

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

标准化、认证和 SQA 系统评估组件

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

SQA 的组织 - 人员组件

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

项目前软件质量组件

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

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

合同审查

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

具体而言，合同审查活动包括 -

  • 澄清客户的需求

  • 审查项目的进度安排和资源需求估算

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

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

  • 评估开发风险

开发和质量计划

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

大多数情况下，在招标提交和合同签署之间需要几个月的时间。在此期间，资源（如员工可用性、专业能力）可能会发生变化。然后对计划进行修订以反映在此期间发生的更改。

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

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

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

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

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

  • 审查、测试和其他计划的验证和确认活动的清单

软件质量度量

软件度量可以分为三类 -

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

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

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

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

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

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

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

产品质量度量

此度量包括以下内容 -

  • 平均故障间隔时间 (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 通常在软件发布到市场后的每个月计算，以及按年计算月平均值。

客户满意度

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

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

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

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

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

在制品质量度量

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

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

机器测试期间的缺陷密度

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

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

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

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

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

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

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

基于阶段的缺陷去除模式

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

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

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

缺陷去除效率

它可以定义如下 -

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

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

维护质量度量

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

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

修复积压和积压管理指数

修复积压与缺陷到达率以及已报告问题的修复方案可用率相关。它是在每个月或每个星期结束时剩余的已报告问题的简单计数。将其用于趋势图格式，此指标可以提供有意义的信息，以帮助管理维护过程。

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

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

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

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

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

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

逾期修复的百分比

计算方法如下：

$逾期修复百分比 =$

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

修复质量

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

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

通常，潜伏期越长，受影响的客户就越多。如果缺陷数量很大，则百分比指标的小值将显示乐观的画面。当然，维护过程的质量目标是零有缺陷修复且无逾期。

测量的基础

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

正式地，它可以定义为，将数字或符号分配给现实世界中实体的属性的过程，以根据明确定义的规则对其进行描述。

日常生活中的测量

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

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

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

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

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

软件工程中的测量

软件工程涉及管理、成本核算、计划、建模、分析、规范、设计、实现、测试和维护软件产品。因此，测量在软件工程中发挥着重要作用。对于测量软件产品的属性，需要一种严格的方法。

对于大多数开发项目，

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

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

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

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

测量的表示理论

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

经验关系

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

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

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

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

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

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

X 比 Y 高是二元关系。

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

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

李克特量表

在这里，用户将获得一个陈述，他们必须同意或不同意。

例如 - 此软件性能良好。

非常同意 同意 既不同意也不反对 不同意 非常不同意
         

强制排序

将给定的备选方案按从 1（最好）到 n（最差）的顺序排列。

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

模块名称 排名
模块 A
模块 B
模块 C
模块 D
模块 E

口头频率量表

例如 - 此程序故障的频率如何？

总是 经常 有时 很少 从不
         

顺序量表

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

例如 - 此程序故障的频率如何？

  • 每小时
  • 每天
  • 每周
  • 每月
  • 每年几次
  • 每年一两次
  • 从不

比较量表

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

非常优越大致相同非常劣势

12345678910

数值量表

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

不重要重要

12345678910

映射规则

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

例如 - 域 - 现实世界

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

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

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

测量的表示条件

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

例如：“比……高”的经验关系映射到数值关系“>”。即，如果且仅当 M(X) > M(Y) 时，X 才比 Y 高

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

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

X > 50

表示条件要求对于任何度量M，

如果且仅当 M(X) > 50 时，X 才高

正式测量的关键阶段

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

Key Stages of Formal Measurement

测量和模型

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

测量分为两种类型：

  • 直接测量
  • 间接测量

直接测量

这些是可以无需任何其他实体或属性参与即可测量的测量。

以下直接测量方法通常用于软件工程。

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

间接测量

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

以下间接度量方法常用于软件工程。

$$\small 程序员生产率 = \frac{产生的代码行数}{人月工作量}$$

$\small 模块缺陷密度 = \frac{缺陷数量}{模块规模}$

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

$\small 需求稳定性 = \frac{初始需求数量}{需求总数}$

$\small 测试有效率 = \frac{覆盖的项目数量}{项目总数}$

$\small 系统损耗 = \frac{用于修复故障的工作量}{项目总工作量}$

用于预测的度量

为了为项目分配适当的资源，我们需要预测开发项目的努力、时间和成本。用于预测的度量始终需要一个数学模型，该模型将要预测的属性与我们现在可以测量的某些其他属性相关联。因此，预测系统由一个数学模型以及一组用于确定未知参数和解释结果的预测程序组成。

测量尺度

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

  • 名义尺度
  • 顺序量表
  • 区间尺度
  • 比率尺度
  • 绝对尺度

名义尺度

它将元素置于分类方案中。这些类别将不会排序。每个实体都应根据属性的值放置在特定的类别或范畴中。

它有两个主要特征 -

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

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

顺序量表

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

  • 经验关系系统由相对于属性排序的类别组成。

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

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

区间尺度

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

它具有以下特征 -

  • 它像顺序尺度一样保留顺序。

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

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

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

M = aM’ + b

比率尺度

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

  • 它是一个保留排序、实体之间区间大小和实体之间比率的测量映射。

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

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

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

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

M = aM’

其中'a'是一个正标量。

绝对尺度

在此尺度上，属性只有一个可能的度量。因此，唯一可能的转换将是恒等转换。

它具有以下特征 -

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

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

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

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

实证研究

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

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

选择调查技术

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

  • 调查
  • 案例研究
  • 正式实验

调查

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

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

案例研究

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

正式实验

它是对活动进行的严格控制的调查，其中识别和操纵关键因素以记录其对结果的影响。

Investigations

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

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

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

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

  • 如果复制成本低，则可以考虑实验。

陈述假设

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

控制变量

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

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

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

使调查有意义

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

符合理论和传统智慧

案例研究或调查可用于证实传统智慧以及许多其他标准、方法或工具在一个组织中的有效性和实用性。但是，正式实验可以调查这些说法普遍成立的情况。

探索关系

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

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

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

评估模型的准确性

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

某些模型（例如可靠性模型）不会影响结果，因为可靠性（以平均故障时间衡量）只有在软件准备好投入现场使用后才能评估。

验证度量

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

软件测量

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

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

对要检查的实体进行分类

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

  • 过程
  • 产品
  • 资源

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

  • 内部属性是可以纯粹根据过程、产品或资源本身测量的属性。例如：规模、复杂性、模块之间的依赖关系。

  • 外部属性是指仅相对于其与环境的关系才能测量的属性。例如：用户遇到的故障总数、搜索数据库并检索信息所需的时间。

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

过程

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

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

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

  • 在过程或其活动之一期间发生的特定类型事件的数量

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

产品

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

不同的内部产品属性包括规模、工作量、成本、规范、长度、功能、模块化、重用、冗余和语法正确性。其中，规模、工作量和成本比其他属性更容易测量。

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

资源

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

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

确定相关的度量目标

只有当某个度量有助于理解流程或其结果产品之一时，它才有用。只有当项目为流程和产品明确定义了目标时，才能改进流程或产品。对目标的清晰理解可用于在流程成熟度框架的上下文中为给定项目生成建议的指标。

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

GQM 方法提供了一个包含以下三个步骤的框架：

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

  • 从每个目标中推导出必须回答的问题，以确定目标是否正在实现

  • 确定为了能够充分回答这些问题必须测量什么

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

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

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

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

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

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

度量和流程改进

通常度量对以下方面有用：

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

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

级别 1：临时性

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

级别 2：可重复性

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

Repeatable

输入度量可以是需求的大小和波动性。输出可以用系统大小来衡量，资源可以用员工工作量来衡量，约束可以用成本和时间表来衡量。

级别 3：已定义

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

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

Defined

级别 4：已管理

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

Managed

级别 5：优化

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

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

识别成熟度级别

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

  • 在级别 1，项目可能具有定义不明确的需求。在此级别，需求特征的测量很困难。

  • 在级别 2，需求已明确定义，并且可以收集其他信息，例如每个需求的类型以及对每种类型的更改次数。

  • 在级别 3，中间活动已定义，每个活动都有进入和退出标准

目标和问题分析将相同，但指标会随成熟度而变化。流程越成熟，测量结果就越丰富。GQM 范式与流程成熟度相结合，已被用作协助经理设计测量程序的几种工具的基础。

GQM 有助于理解测量属性的需要，而流程成熟度表明我们是否有能力以有意义的方式进行测量。它们共同为测量提供了上下文。

软件测量验证

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

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

验证测量系统

度量或测量系统用于通过数值表征其一个或多个属性来评估现有实体。如果度量准确地表征了它声称要测量的属性，则该度量是有效的。

验证软件测量系统是通过显示表示条件是否满足来确保度量是声称属性的适当数值表征的过程。

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

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

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

m(P1) > m(P2)

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

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

验证预测系统

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

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

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

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

软件测量指标

软件度量是一个包含许多活动的度量标准，这些活动涉及一定程度的测量。它可以分为三类：产品度量、流程度量和项目度量。

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

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

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

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

软件度量的范围

软件度量包含许多活动，包括以下内容：

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

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

成本和工作量估算

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

  • Boehm 的 COCOMO 模型
  • Putnam 的 SLIM 模型
  • Albrecht 的功能点模型

生产力模型和度量

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

Productivity Model

数据收集

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

质量模型和度量

已经开发了质量模型来测量产品质量，没有它，生产力就没有意义。这些质量模型可以与生产力模型相结合，以测量正确的生产力。这些模型通常以树状方式构建。上层分支包含重要的高级质量因素，例如可靠性和可用性。

分而治之的方法已被实施作为衡量软件质量的标准方法。

可靠性模型

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

性能评估和模型

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

结构和复杂性度量

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

能力成熟度评估

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

指标管理

对于软件项目的管理，测量发挥着至关重要的作用。为了检查项目是否按计划进行，用户和开发人员可以依靠基于测量的图表和图形。当软件嵌入到产品中时，标准的测量和报告方法尤其重要，在这种情况下，客户通常不熟悉软件术语。

方法和工具的评估

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

数据操作

软件度量是一个衡量标准，包含许多活动，这些活动涉及一定程度的测量。软件测量的成功在于收集和分析的数据质量。

什么是好的数据？

如果收集到的数据能够回答以下问题，则可以将其视为好数据：

  • 它们是否正确？ - 如果数据是根据度量定义的精确规则收集的，则可以将其视为正确。

  • 它们是否准确？ - 准确性是指数据与实际值之间的差异。

  • 它们是否具有适当的精确度？ - 精确度涉及表达数据所需的十进制位数。

  • 它们是否一致？ - 如果数据在一个测量设备到另一个测量设备之间没有显示出重大差异，则可以将其视为一致。

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

  • 它们是否可以复制？ - 通常，调查（例如调查、案例研究和实验）会在不同的情况下重复进行。因此，数据也应该能够轻松复制。

如何定义数据？

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

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

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

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

  • 位置
  • 时间
  • 症状
  • 最终结果
  • 机制
  • 原因
  • 严重程度
  • 成本

如何收集数据？

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

  • 保持程序简单

  • 避免不必要的记录

  • 培训员工了解记录数据的必要性以及要使用的程序

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

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

数据收集计划涉及以下几个步骤：

  • 根据 GQM 分析决定要测量哪些产品

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

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

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

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

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

例如 - 与项目人员相关的一些数据可以在项目开始时收集，而其他数据收集（例如工作量）则从项目开始到操作和维护一直持续。

如何存储和提取数据

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

Database Management System

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

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

分析软件测量数据

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

  • 数据的性质
  • 实验的目的
  • 设计考虑因素

数据的性质

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

抽样、总体和数据分布

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

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

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

Population

如上所示，数据将均匀分布在平均值周围，这是正态分布的重要特征。

还存在其他分布，其中数据偏斜，使得平均值一侧的数据点多于另一侧。例如：如果大部分数据出现在平均值的左侧，那么我们可以说分布向左偏斜。

实验的目的

通常，进行实验是为了：

  • 确认理论
  • 探索关系

为了实现这些目标，应根据假设正式表达目标，并且分析必须直接解决假设。

确认理论

调查必须设计成探索理论的真实性。该理论通常指出，使用某种方法、工具或技术对受试者具有特定影响，使其在某些方面优于另一种方法。

需要考虑两种数据情况：正态数据和非正态数据。

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

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

探索关系

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

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

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

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

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

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

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

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

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

设计考虑因素

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

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

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

内部产品属性

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

测量内部产品属性

主要的内部产品属性包括大小和结构。大小可以在不执行它们的情况下静态测量。产品的大小告诉我们创建它所需的工作量。同样，产品的结构在设计产品的维护方面也起着重要作用。

测量大小

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

  • 长度 - 它代表产品的物理大小。

  • 功能 - 它描述了产品向用户提供的功能。

  • 复杂性 - 复杂性有多种类型，例如。

    • 问题复杂性 - 衡量底层问题的复杂性。

    • 算法复杂性 - 衡量用于解决问题的算法的复杂性

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

    • 认知复杂性 - 衡量理解软件所需的工作量。

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

长度

有三个开发产品，其尺寸测量对于预测预测所需的工作量很有用。它们是规范、设计和代码。

规范和设计

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

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

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

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

代码

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

总长度为，

LOC = NCLOC + CLOC

即，

LOC = 未注释 LOC + 已注释 LOC

除了代码行数外，还可以使用 Maurice Halstead 提出的其他替代方案，例如大小和复杂度来进行度量。

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

他首先将程序P定义为令牌的集合，这些令牌按运算符或操作数分类。这些令牌的基本度量是：

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

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

  • N1 = 运算符的总出现次数

  • N2 = 唯一运算符的数量

程序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 的功能点方法。

阿尔布雷希特功能点方法

功能点度量提供了一种标准化的方法来衡量软件应用程序的各种功能。它从用户的角度衡量功能，即基于用户请求并作为回报获得的内容。功能点分析是从用户的角度衡量软件开发的标准方法。

Albrecht 最初提出的功能点度量随着 1986 年国际功能点用户组 (IFPUG) 的成立而越来越受欢迎。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 DETs
1-5 6-15 >15
0-1 低 低 平均
2-3 低 平均 高
>3 平均 高 高

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

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

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

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

RETs DETs
1-5 6-15 >15
1 低 低 平均
2-5 低 平均 高
>5 平均 高 高

  • 将评级转换为UFC。

评级 值
EO EQ EI ILF ELF
低 4 3 3 7 5
平均 5 4 4 10 7
高 6 5 6 15 10

计算最终功能点计数 (FPC)

  • 基于 14 个一般系统特征（GSC）计算价值调整因子（VAF）。

一般系统特征 简要说明
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 促进更改 应用程序是否专门设计、开发和支持以促进更改？

  • 根据其对问题的影响程度（从无影响到强烈影响），将每个GSC在 0 到 5 的范围内进行加权。

  • 如下计算FPC -

    FPC = UFC * (0.65+(sum(GSC) * .01))

复杂性

复杂度是规模的独立组成部分。它有两种类型 -

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

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

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

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

测量复杂度

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

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

度量结构

度量软件的结构特性对于估计开发工作量以及产品的维护非常重要。需求、设计和代码的结构有助于理解将一个产品转换为另一个产品的难度、测试产品的难度或从早期内部产品度量预测外部软件属性的难度。

结构度量的类型

软件的结构包含三个部分。它们是 -

  • 控制流结构 - 指程序中指令执行的顺序。

  • 数据流结构 - 指数据与其交互的程序的行为。

  • 数据结构 - 指数据元素以列表、队列、栈或其他定义良好的结构形式组织，以及创建、修改或删除它们的算法。

度量控制流结构

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

如果‘m’是根据流图模型定义的结构度量，并且如果程序A的结构比程序B更复杂，那么度量m(A)应该大于m(B)。

度量数据流结构

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

根据数据在系统中移动的方式，可以将其分类为以下几种 -

  • 局部直接流 - 如果一个模块调用第二个模块并向其传递信息，或者被调用模块将结果返回给调用者。

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

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

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

信息流复杂度 (M) = 长度 (M) × 扇入 (M) × (扇出 (M))2

其中，

  • 扇入 (M) - 终止于 M 的局部流数 + M 从中检索信息的数数据结构数。

  • 扇出 (M) - 发源于 M 的局部流数 + M 更新的数据结构数。

度量数据结构

数据结构可以是局部的，也可以是全局的。

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

全局地，将度量用户定义变量的总数。

标准和证书

一些国家和国际标准机构、专业和行业导向组织一直参与软件质量保证标准的制定。

以下机构和组织是软件质量保证和软件工程标准的主要制定者 -

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

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

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

他们还提供用于组织软件质量保证系统及其运营的自评估工具。由软件工程研究所（SEI），卡内基梅隆大学和ISO/IEC标准15504开发的能力成熟度模型（CMM）是这种方法的例子。

软件质量保证标准

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

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

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

质量管理标准

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

示例 - ISO 9000-3和能力成熟度模型（CMM）

项目过程标准

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

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

当然，由于其特性，此类中的许多软件质量保证标准可以作为软件工程标准，反之亦然。

这两类标准的特征总结在下表中。

特征 质量管理标准 项目过程标准
目标单元 软件开发、维护和特定软件质量保证单元的管理 软件开发和维护项目团队
主要焦点 软件质量保证系统的组织、基础设施和需求 执行软件开发和维护项目的方法
标准的目标 “做什么”要实现 “如何”执行
标准的目标 确保供应商的软件质量并评估其软件过程能力 确保供应商的软件质量并评估其软件过程能力 确保特定软件项目的质量。
例子 ISO 9000-3 SEI的CMM ISO/IEC 12207 IEEE标准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 主评估师领导。团队必须由 4 到 10 名团队成员组成。至少一名团队成员必须来自被评估的组织，所有团队成员都必须完成 SEI 的 CMM 简介课程（或等效课程）和 SEI 的 CBA IPI 团队培训课程。团队成员还必须满足某些选拔指南。

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

  • 标准成熟度问卷
  • 个人和集体访谈
  • 文档审查
  • 评估参与者审查草案结果的反馈

SCAMPI

标准 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 Unit

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互联网/内联网站点。

SQA受托人和他们的任务

SQA受托人是主要参与软件质量提升的成员。这些成员为成功实施SQA组件提供必要的内部支持。

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

与单元相关的任务

  • 支持同事解决在实施软件质量程序和工作说明期间遇到的困难。

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

  • 促进合规性并监控同事对SQA程序和工作说明的执行情况。

  • 将重大且系统的违规事件报告给SQA单元。

  • 将严重的软件质量故障报告给SQA单元。

与组织相关的任务

  • 触发组织范围内的SQA程序和工作说明的更改和更新。

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

  • 就相应单元中观察到的重复性故障的解决方案向CAB提交申请。

  • 识别整个组织的SQA培训需求，并提出由SQA单元进行的适当培训或指导计划。

SQA委员会及其任务

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

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

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

永久性SQA委员会是SQA组织框架不可或缺的一部分；其任务和运作通常在组织的SQA程序中定义。

临时委员会是根据短期问题为基础建立的，成员由负责软件质量问题的负责人、SQA单元负责人、SQA子单元、永久性SQA委员会或任何其他发起其形成并对工作感兴趣的机构提名。该机构还定义了临时委员会的任务。

打印页面
上一篇
下一篇
广告