SWEBOK软件工程知识体系 - 10.软件质量

软件质量（SOFTWARE QUALITY）

什么是软件质量，为什么它如此重要以至于它包含在SWEBOK指南的许多知识领域（KA）中？

其中一个原因是软件质量这个术语过载了。软件质量可以是指：软件产品的理想特性，在某种程度上，特定的软件产品具有这些特性，以及用于实现这些特性的过程、工具和技术。多年来，作者和组织对“质量”一词的定义有所不同。对Phil Crosby来说，这是“符合要求”[1]。Watts Humphrey将其称为“达到了“适合使用”的优秀水平”[2]。与此同时，IBM创造了一个短语“市场驱动的质量”，其中“客户是最终的仲裁者”[3*，p8]。

最近，软件质量被定义为“软件产品在特定条件下满足明示和暗示需求的能力”[4]和“软件产品满足既定需求的程度；然而，质量取决于这些既定需求准确代表利益相关者的程度需要、想要和期望“[5]。这两个定义都包含符合可扩展性或任何其他特征的前提。然而，重要的是，这些定义强调了质量取决于需求。

这些定义还说明了本指南中软件质量普遍存在的另一个原因：软件质量与软件质量要求之间经常存在歧义（“能力”是一个常见的缩写）。软件质量需求实际上是功能需求（系统所做的）的属性（或约束）。软件需求还可以指定资源使用、通信协议或许多其他特性。本文试图通过使用上述定义中最广泛意义上的软件质量，并通过使用软件质量需求作为功能需求的约束来澄清。软件质量是通过对所有需求的一致性来实现的，而不管指定了什么特性，或者需求是如何分组或命名的。

许多SWEBOK KAs中也考虑了软件质量，因为它是软件工程工作的一个基本参数。对于所有的工程产品，主要目标是提供最大的利益相关者价值，同时平衡开发成本和进度的限制；这有时被描述为“适合使用”。利益相关者价值用需求来表达。对于软件产品，涉众可以评估价格（他们为产品支付的价格）、交付周期（他们获得产品的速度）和软件质量。
本文讨论了定义，并概述了用于定义软件质量和在开发、维护和部署期间评估软件质量状态的实践、工具和技术。引用的参考文献提供了更多细节。

软件质量主题分解
图10.1显示了软件质量KA的主题细分。

1.软件质量基础

就什么是所有利益相关者的质量达成一致意见，并将该一致意见明确传达给软件工程师，要求对质量的许多方面进行正式定义和讨论。

软件工程师应该了解质量概念、特性、价值及其在开发或维护软件中的应用。重要的概念是软件需求定义了软件所需的质量属性。软件需求影响度量方法和验收标准，用于评估软件和相关文档达到所需质量水平的程度。

1.1. 软件工程文化与伦理

软件工程师应该把软件质量作为他们文化的一部分。一个健康的软件工程文化包括许多特性，包括理解成本、进度和质量之间的权衡是任何产品工程的基本租户。强烈的软件工程道德要求工程师准确地报告与质量相关的信息、条件和结果。

伦理在软件质量、文化和软件工程师的态度方面也扮演着重要的角色。IEEE计算机协会和ACM已经制定了一个道德和职业实践准则（参见软件工程专业实践KA中的道德和职业行为准则）。

1.2. 质量的价值和成本

定义并实现软件质量并不简单。质量特性可能需要，也可能不需要，也可能需要到更大或更小的程度，并且可以在它们之间进行权衡。为了帮助确定软件质量的水平，即实现利益相关者的价值，本节介绍了软件质量成本（CoSQ）：从软件质量开发和维护过程的经济评估中得出的一组度量。CoSQ测量是可用于推断产品特性的过程测量的示例。

CoSQ的前提是，软件产品的质量水平可以从与处理低质量后果相关的活动的成本中推断出来。劣质是指软件产品不能完全“满足明示和暗示的需求”或“既定的需求”。质量成本分为四类：预防、评估、内部故障和外部故障。

预防成本包括对软件过程改进工作、质量基础设施、质量工具、培训、审计和管理评审的投资。这些成本通常不是特定于一个项目的，而是跨组织的。评估成本产生于发现缺陷的项目活动。这些评估活动可分为评审费用（设计、同行）和测试费用（软件单元测试、软件集成、系统级测试、验收测试）；评估费用将扩大到分包的软件供应商。内部故障的成本是指修复在评估活动中发现的缺陷以及在将软件产品交付给客户之前发现的缺陷所产生的成本。外部故障成本包括对交付给客户后发现的软件问题做出响应的活动。

软件工程师应该能够使用CoSQ方法来确定软件质量的水平，还应该能够提出质量替代方案及其成本，以便在成本、进度和交付涉众价值之间进行权衡。

1.3. 型号及质量特性

软件质量特征的术语在不同的分类法（或软件质量模型）中有所不同，每个模型可能具有不同数量的层次结构级别和不同的特征总数。许多作者已经产生了软件质量特征或属性的模型，这些模型可以用于讨论、规划和评估软件产品的质量。ISO/IEC 25010:2011[4]将产品质量和使用中的质量定义为两个相关的质量模型。SWEBOK指南的附录B提供了每个KA的适用标准列表。这个KA的标准涵盖了描述软件质量的各种方法。

1.3.1. 软件过程质量

软件质量管理和软件工程过程质量直接关系到软件产品的质量。

评估软件组织能力的模型和标准主要是项目组织和管理方面的考虑，因此，在软件工程管理和软件工程过程KAs中也有涉及。

不可能完全区分过程质量和产品质量，因为过程结果包括产品。确定一个过程是否有能力始终如一地生产出所需质量的产品并不简单。

在软件工程过程KA中讨论的软件工程过程影响软件产品的质量特性，进而影响利益相关者所感知的质量。

1.3.2. 软件产品质量

软件工程师首先必须确定软件的真正用途。在这方面，干系人需求是最重要的，除了功能需求之外，干系人需求还包括质量需求。因此，软件工程师有责任引出一开始可能不明确的质量要求，并了解其重要性以及实现这些要求的难度。所有软件开发过程（例如，引出需求、设计、构造、构建、检查、提高质量）都是在考虑这些质量需求的情况下设计的，如果安全性、安全性和可靠性等属性很重要，则可能会带来额外的开发成本。额外的开发成本有助于确保所获得的质量可以与预期收益进行权衡。

术语工作产品是指任何工件，它是用于创建最终软件产品的过程的结果。工作产品的示例包括系统/子系统规范、系统软件组件的软件需求规范、软件设计描述、源代码、软件测试文档或报告。虽然质量的一些处理方法是根据最终软件和系统性能来描述的，但良好的工程实践要求在整个软件工程过程中对与质量相关的中间工作产品进行评估。

1.4. 软件质量改进

软件产品的质量可以通过预防性过程或持续改进的迭代过程来提高，这需要管理控制、协调和许多并行过程的反馈：（1）软件生命周期过程，（2）故障/缺陷检测、消除和预防过程，质量改进过程。

质量改进背后的理论和概念，如通过预防和早期发现缺陷来构建质量、持续改进和利益相关者关注等，都与软件工程有关。这些概念是建立在质量专家的工作基础上的，他们认为产品的质量与生产过程的质量直接相关。诸如计划-执行-检查-行动（PDCA）、渐进式交付、改善和质量功能部署（QFD）等方法提供了指定质量目标和确定是否满足这些目标的技术。软件工程研究所的理想是另一种方法[7*]。质量管理现在被SWEBOK指南视为一门重要的学科。

管理层支持过程和产品评估以及结果。然后制定一个改进计划，确定在可行的时间框架内要解决的详细行动和改进项目。管理支持意味着每个改进项目都有足够的资源来实现为其定义的目标。通过实施积极主动的沟通活动，经常寻求管理层的支持。

1.5. 软件安全

安全关键系统是指系统故障可能危害人类生命、其他生物、物理结构或环境的系统。这些系统中的软件是安全关键的。在越来越多的行业中，安全关键软件的应用越来越多。具有安全关键软件的系统示例包括公共交通系统、化学制造厂和医疗设备。这些系统中的软件故障可能会产生灾难性的影响。有一些行业标准，如DO-178C[11]，以及开发安全关键软件的新兴过程、工具和技术。这些标准、工具和技术的目的是降低向软件中注入故障的风险，从而提高软件的可靠性。

安全关键软件可以分为直接的或间接的。Direct是嵌入安全关键系统的软件，如飞机的飞行控制计算机。间接包括用于开发安全关键软件的软件应用程序。间接软件包括在软件工程环境和软件测试环境中。

降低故障风险的三种补充技术是避免、检测和移除以及损伤限制。这些技术影响软件功能需求、软件性能需求和开发过程。风险水平的提高意味着软件质量保证和控制技术（如检查）水平的提高。更高的风险级别可能需要对需求、设计和代码进行更彻底的检查，或者使用更正式的分析技术。管理和控制软件风险的另一种技术是构建保证案例。保证案例是一个合理的、可审计的工件，用于支持一个或多个索赔得到满足的论点。它包含以下内容及其关系：一个或多个关于财产的主张；逻辑上将证据和任何假设与主张联系起来的论点；以及支持这些论点的一系列证据和假设[12]。

2.软件质量管理过程

软件质量管理是确保软件产品、服务和生命周期过程实现满足组织软件质量目标并实现干系人满意的所有过程的集合[13，14]。SQM定义了整个软件生命周期中的过程、过程所有者、过程需求、过程及其输出的度量和反馈通道。

SQM包括四个子类：软件质量策划（planning）、软件质量保证（SQA）、软件质量控制（SQC）和软件过程改进（SPI）。软件质量规划包括确定要使用的质量标准、定义特定的质量目标以及估计软件质量活动的工作和进度。在某些情况下，软件质量规划还包括定义要使用的软件质量过程。SQA活动定义并评估软件过程的充分性，以提供证据，证明软件过程适用于并产生适合其预期目的的质量合适的软件产品[5]。SQC活动检查特定的项目工件（文档和可执行文件），以确定它们是否符合为项目建立的标准（包括需求、约束、设计、合同和计划）。SQC评估中间产品和最终产品。

第四个涉及改进的SQM类别在软件行业中有不同的名称，包括SPI、软件质量改进以及软件纠正和预防措施。这类活动旨在提高过程的有效性、效率和其他特性，最终目标是提高软件质量。尽管SPI可以包含在前三个类别中的任何一个类别中，但是越来越多的组织将SPI组织成一个单独的类别，这个类别可能跨越许多项目（参见软件工程过程）。

软件质量过程由任务和技术组成，以表明软件计划（例如，软件管理、开发、质量管理或配置管理计划）是如何实施的，以及中间产品和最终产品满足其规定要求的程度。在采取纠正措施之前，将这些任务的结果汇总到报告中以供管理。SQM过程的管理任务是确保这些报告的结果是准确的。

风险管理也可以在交付高质量软件方面发挥重要作用。将严格的风险分析和管理技术结合到软件生命周期过程中有助于提高产品质量（有关风险管理的相关资料，请参阅软件工程管理KA）。

2.1. 软件质量保证

为了平息广泛的误解，软件质量保证不是测试。软件质量保证（SQA）是一组活动，定义和评估软件过程的充分性，以提供证据，证明软件过程是适当的，并为其预期目的生产具有适当质量的软件产品。SQA的一个关键属性是SQA功能对项目的客观性。SQA职能部门在组织上也可以独立于项目；也就是说，不受项目的技术、管理和财务压力的影响[5]。SQA有两个方面：产品保证和过程保证，这在第2.3节中解释。

软件质量计划（在某些行业被称为软件质量保证计划）定义了为确保为特定产品开发的软件在项目成本和进度限制范围内满足项目既定需求和用户需求，并与项目相适应所采用的活动和任务风险。SQAP首先确保明确定义和理解质量目标。

SQA策划（plan）的质量活动和任务在软件工程管理、软件开发和软件维护策划（plan）中与相关目标相关的成本、资源需求、目标和进度表进行了详细说明。SQA策划（plan）应与软件配置管理策划（plan）保持一致（见软件配置管理策划（plan））。SQA计划确定了管理项目的文件、标准、实践和惯例，以及如何检查和监控这些项目，以确保充分性和合规性。SQA计划还确定了措施；统计技术；问题报告和纠正措施的程序；工具、技术和方法等资源；物理媒体的安全性；培训；以及SQA报告和文档。此外，SQA计划涉及软件计划中描述的任何其他类型活动的软件质量保证活动，如项目供应商软件的采购、商用现货软件（COTS）安装和软件交付后的服务。它还可以包含验收标准以及对软件质量至关重要的报告和管理活动。

2.2. 验证与确认

如[15]所述，

验证与确认的目的是帮助开发组织在生命周期内将质量构建到系统中。验证和确认过程提供产品和过程在整个生命周期中的客观评估。该评估表明需求是否正确、完整、准确、一致和可测试。验证和确认过程确定某一特定活动的开发产品是否符合该活动的要求，以及该产品是否满足其预期用途和用户需求。

验证是一种尝试，以确保产品是建立正确的意义上，一个活动的输出产品符合规格强加给他们在以前的活动。验证是一种尝试，以确保正确的产品是建立，也就是说，产品实现其特定的预期目的。验证过程和确认过程都是在开发或维护阶段的早期开始的。它们提供了与产品的直接前身和要满足的规格有关的关键产品特性的检查。

规划验证与确认的目的是确保每个资源、角色和责任都得到明确分配。由此产生的V&V计划文件描述了各种资源及其角色和活动，以及要使用的技术和工具。了解每项V&V活动的不同目的有助于仔细规划实现其目的所需的技术和资源。该计划还涉及验证和确认活动的管理、沟通、政策和程序及其相互作用，以及缺陷报告和文件要求。

2.3. 审查和审计

评审和审计过程被广泛地定义为静态的，也就是说，没有软件程序或模型被执行，而是根据组织或项目为这些工件建立的标准来检查软件工程工件。不同类型的审查和审计根据其目的、独立性水平、工具和技术、角色以及活动主题进行区分。产品保证和过程保证审计通常由独立于开发团队的软件质量保证（SQA）人员进行。管理评审由组织或项目管理层进行。工程人员进行技术审查。

• 管理评审评估与计划有关的实际项目结果。
• 技术审查（包括检查、走查和案头检查）检查工程工作产品。
• 过程保证审核。SQA过程保证活动确保用于开发、安装、操作和维护软件的过程符合合同，符合任何强制实施的法律、规则和条例，并且对于其预期目的是充分、有效和有效的[5]。
• 产品保证审核。SQA产品保证活动确保提供证据，证明软件产品和相关文档在合同中得到识别并符合合同；并确保不符合项得到识别和解决[5]。

2.3.1. 管理评审

如[16*]所述，

管理评审的目的是监测进度，确定计划和时间表的状态，并评估管理过程、工具和技术的有效性。管理评审将实际项目结果与计划进行比较，以确定项目或维护工作的状态。管理评审的主要参数是项目成本、进度、范围和质量。管理评审评估有关纠正措施、资源分配变化或项目范围变化的决策。

管理评审的输入可能包括审计报告、进度报告、V&V报告和多种类型的计划，包括风险管理、项目管理、软件配置管理、软件安全和风险评估等。（相关资料参见软件工程管理和软件配置管理KAs。）

2.3.2. 技术评审

如[16*]所述，

技术评审的目的是由合格人员组成的团队对软件产品进行评估，以确定其对预期用途的适用性，并识别与规范和标准的差异。它为管理层提供了确认项目技术状态的证据。

虽然任何工作产品都可以评审，但技术评审是对软件需求和软件设计的主要软件工程工作产品进行的。

目的、角色、活动，以及最重要的正式程度区分了不同类型的技术评审。检查是最正式的，走查较少，结对审查或案头检查是最不正式的。

具体角色的示例包括决策者（即软件负责人）、评审负责人、记录员和检查员（检查工作产品的技术人员）。审查的区别还在于审查过程中是否包括会议（面对面会议或电子会议）。在某些评审方法中，checker单独检查工作产品，并将结果发送回协调员。在其他方法中，检查者在会议中合作工作。技术审查可能要求强制性投入到位，以便继续：

• 目标声明
• 特定软件产品
• 具体项目管理计划
• 与本产品相关的问题列表
• 技术审查程序。

团队遵循文件化的评审程序。一旦检查中列出的所有活动完成，技术审查即告完成。

对源代码的技术审查可能包括各种各样的关注点，如算法分析、关键计算机资源的利用、对编码标准的遵守、代码的可测试性结构和组织以及安全关键考虑。

请注意，对源代码或设计模型（如UML）的技术评审也被称为静态分析（参见主题3，实际考虑）。

2.3.3. 检查

“检查的目的是检测和识别软件产品异常”[16*]。与其他类型的技术审查相比，检查的一些重要区别在于：

1. 规则。检查的基础是根据组织规定的一组标准检查工作产品。可以为不同类型的工作产品定义规则集（例如，需求规则、体系结构描述、源代码）。
2. 取样。检查过程不是试图检查文档中的每个单词和数字，而是允许检查人员评估被检查文档的定义子集（样本）。
3. 对等。对检查组成员担任管理职务的个人不参加检查。这是同行评审和管理评审之间的关键区别。
4. 指导。受过检验技术培训的公正主持人主持检验会议。
5. 会议。检查过程包括由主持人根据正式程序举行的会议（面对面会议或电子会议），检查组成员在会议中报告他们发现的异常情况和其他问题。

软件检查总是涉及到中间产品或最终产品的作者；其他的评审可能不会。检查还包括一个检查负责人、一个记录员、一个读取器和几个（两到五个）检查员（检查员）。检查组成员可能拥有不同的专业知识，如领域专业知识、软件设计方法专业知识或编程语言专业知识。检验通常一次只对产品的一个相对较小的部分（样品）进行。每个团队成员在评审会议之前检查软件产品和其他评审输入，可能通过将分析技术（见第3.3.3节）应用于产品的一小部分或整个产品，只关注一个方面，例如接口。在检查期间，主持人主持会议，并核实每个人都为检查做好了准备并主持会议。检查记录员记录了发现的异常情况。一套规则，其标准和问题与感兴趣的问题密切相关，是检查中常用的工具。结果列表通常对异常进行分类（见第3.2节，缺陷特征），并由团队审查其完整性和准确性。
检验退出决定对应于以下选项之一：

1. 接受时不进行任何返工，最多进行少量返工
2. 返工验证验收
3. 复验。

2.3.4. 演练

如[16*]所述，

系统演练的目的是评估软件产品。演练的目的可以是教育观众了解软件产品。

走查与检查是有区别的。主要区别在于，作者将工作成果呈现给会议的其他参与者（面对面或电子版）。与检查不同的是，会议参与者可能不一定在会议之前看过材料。这些会议可能不太正式。作者负责向参与者解释和展示材料，并征求反馈意见。与检查一样，演练可以在任何类型的工作产品上进行，包括项目计划、需求、设计、源代码和测试报告。

2.3.5. 过程保证和产品保证审核

如[16*]所述，

软件审计的目的是对软件产品和过程是否符合适用的法规、标准、指南、计划和程序进行独立评估。

过程保证审核确定计划、时间表和要求的充分性，以实现项目目标[5]。审计是一种正式组织的活动，参与者具有特定的角色，如首席审计员、另一名审计员、记录员或发起人，包括被审计组织的代表。审核确定不符合项的实例，并生成报告，要求团队采取纠正措施。

虽然评审和审计可能有许多正式名称，如标准[16*]中确定的名称，但重要的一点是，它们几乎可以出现在开发或维护过程的任何阶段的任何产品上。

3.实际考虑

3.1. 软件质量要求

3.1.1. 影响因素

各种因素影响着SQM活动和技术的规划、管理和选择，包括

• 软件所在的系统域；系统功能可以是安全关键型、任务关键型、业务关键型、安全关键型
• 软件系统所在的物理环境
• 系统和软件功能（系统做什么）和质量（系统执行其功能的程度）要求
• 系统中使用的商业（外部）或标准（内部）组件
• 适用的特定软件工程标准
• 用于开发和维护以及质量评估和改进的方法和软件工具
• 所有过程的预算、人员、项目组织、计划和时间表
• 系统的预期用户和用途
• 系统的完整性水平。

有关这些因素的信息会影响SQM过程的组织和记录方式、特定SQM活动的选择方式、需要哪些资源以及哪些资源会对工作施加限制。

3.1.2. 可靠性

在系统故障可能产生极其严重后果的情况下，总体可靠性（硬件、软件和人员或操作）是基本功能之外的主要质量要求。出现这种情况的原因如下：系统故障会影响大量人员；用户通常会拒绝使用不可靠、不安全或不安全的系统；系统故障的代价可能是巨大的；不可靠的系统可能会导致信息丢失。系统和软件可靠性包括可用性、可靠性、安全性和安全性等特性。在开发可靠的软件时，可以应用工具和技术来降低将故障注入中间可交付成果或最终软件产品的风险。验证、确认和测试过程、技术、方法和工具在生命周期中尽早识别影响可靠性的故障。此外，可能需要在软件中建立机制来防范外部攻击和容忍错误。

3.1.3. 软件完整性级别

定义完整性级别是风险管理的一种方法。

软件完整性级别是一系列值，这些值表示软件的复杂性、关键性、风险、安全级别、安全级别、期望性能、可靠性或其他项目独有特征，这些特征定义了软件对用户和收单机构的重要性。用于确定软件完整性级别的特性因系统的预期应用和使用而异。软件是系统的一部分，其完整性级别将作为该系统的一部分来确定。

分配的软件完整性级别可能会随着软件的发展而变化。在系统或软件中实现的设计、编码、程序和技术特性可以提高或降低指定的软件完整性级别。为项目建立的软件完整性级别是由收单机构、供应商、开发人员和独立保证机构之间的协议决定的。软件完整性级别方案是用于确定软件完整性级别的工具。[5]

如[17*]所述，

“完整性级别可以在开发过程中应用，以便为高完整性组件分配额外的验证和确认工作。”

3.2. 缺陷表征

软件质量评估（即软件质量控制）技术可以发现缺陷、故障和失败。确定这些技术的特征有助于理解产品，有助于纠正过程或产品，并将过程或产品的状态告知管理层和其他利益相关者。有许多分类法存在，虽然人们试图达成共识，但文献表明有相当多的分类法在使用中。缺陷表征也用于审核和评审，评审领导成员在评审会议上进行审议。

随着新的设计方法和语言的发展，以及整个软件技术的进步，出现了新的缺陷类别，需要花费大量的精力来解释以前的缺陷类型。单独的信息，没有一些分类，可能不足以确定缺陷的根本原因。需要对特定类型的问题进行分组，以确定随时间变化的趋势。重点是建立对组织和软件工程师有意义的缺陷分类法。

软件质量控制活动在软件开发和维护的所有阶段发现信息。在某些情况下，defect这个词被重载来指代不同类型的异常。然而，不同的工程文化和标准可能会对这些术语使用不同的含义。术语的多样性促使本节提供一组广泛使用的定义[19]：

• 计算误差：“计算、观察或测量的理论正确值或条件之间的差异。”
• 错误：“产生错误结果的人为行为。”一个人犯的失误或错误。也叫人为错误。
• 缺陷：“工作产品不符合其要求或规范，需要修理或更换的不完整或缺陷。”缺陷是由一个人犯错误造成的。
• 错误：源代码中的缺陷。“计算机程序中不正确的步骤、过程或数据定义。”源代码中人为错误的编码。Fault是bug的正式名称。
• 故障：一种“系统或系统部件未在规定范围内执行所需功能的事件”。当处理器在规定条件下遇到故障时，产生故障。

使用这些定义，三个广泛使用的软件质量度量是缺陷密度（每单位文档大小的缺陷数）、故障密度（每1K行代码的故障数）和故障强度（每使用小时或每测试小时的故障数）。可靠性模型是根据软件测试过程中收集的失效数据或在用软件建立的，因此可以用来估计未来失效的概率，并帮助决定何时停止测试。

SQM发现的一个可能的操作是从被检查的产品中移除缺陷（例如，发现并修复bug，创建新的构建）。其他活动试图消除缺陷的原因，例如，根本原因分析（RCA）。RCA活动包括分析和总结调查结果，找出根本原因，并使用测量技术改进产品和过程，以及跟踪缺陷及其消除。过程改进主要在软件工程过程KA中讨论，SQM过程是一个信息源。

软件质量控制技术发现的不足和缺陷的数据可能丢失，除非记录在案。对于某些技术（如技术审查、审计、检查），记录员会记录这些信息以及问题和决定。当使用自动化工具时（参见主题4，软件质量工具），工具输出可能提供缺陷信息。向组织管理层提供缺陷报告。

3.3. 软件质量管理技术

软件质量控制技术可以通过许多方式进行分类，但是简单的方法只使用两种类型：静态和动态。动态技术涉及执行软件；静态技术涉及分析文档和源代码，但不执行软件。

3.3.1. 静态技术

静态技术在不执行代码的情况下检查软件文档（包括需求、接口规范、设计和模型）和软件源代码。静态检查软件工作产品有许多工具和技术（参见第2.3.2节）。此外，分析源代码控制流和搜索死代码的工具被认为是静态分析工具，因为它们不涉及执行软件代码。
其他更正式的分析技术类型称为正式方法。它们主要用于验证软件需求和设计。它们主要用于验证关键系统的关键部分，如特定的安全和安保要求。（另请参见软件工程模型和方法KA中的形式化方法。）

3.3.2. 动态技术

动态技术包括执行软件代码。在软件的开发和维护过程中，采用了不同的动态技术。一般来说，这些都是测试技术，但是诸如模拟和模型分析之类的技术可能被认为是动态的（参见软件工程模型和方法）。代码读取被认为是一种静态技术，但是有经验的软件工程师可以在读取代码时执行代码。代码读取可以利用动态技术。这种分类上的差异表明，在组织中具有不同角色和经验的人可能会以不同的方式考虑和应用这些技术。
不同的组可以在软件开发期间执行测试，包括独立于开发团队的组。软件测试KA完全致力于这个主题。

3.3.3. 测试

由于对项目所用材料的质量负责，两种类型的测试可能属于V&V范围：

• 项目所用工具的评估和测试
• 产品中使用的组件和COTS产品的一致性测试（或一致性测试审查）。

有时，独立的（第三方或IV&V）组织可能被指派执行测试或监控测试过程。V&V可能被要求评估测试本身：计划、过程和程序的充分性，以及结果的充分性和准确性。

第三方不是开发者，也与产品开发无关。相反，第三方是一个独立的机构，通常由一些权威机构认证。它们的目的是测试产品是否符合一组特定的需求（参见软件测试）。

3.4. 软件质量度量

软件质量度量用于支持决策。随着软件的日益复杂化，质量问题已不仅仅是软件是否工作，而是它如何很好地实现可测量的质量目标。

软件质量度量支持的决策包括确定软件质量水平（特别是因为软件产品质量模型包括确定软件产品达到质量目标的程度的度量）；关于工作、成本和进度的管理问题；确定何时停止测试并发布一个软件产品（参见过程改进工作的终止）。

SQM过程的成本是在决定如何组织项目或软件开发和维护团队时经常提出的一个问题。通常，使用通用的成本模型，这是基于何时发现缺陷，以及相对于在开发过程的早期发现缺陷，修复缺陷所花费的精力。内部收集的软件质量度量数据可以更好地描述这个项目或组织内部的成本。

虽然软件质量度量数据本身可能有用（例如，缺陷需求的数量或缺陷需求的比例），但可以应用数学和图形技术来帮助解释度量（见工程基础）。这些技术包括

• 基于描述性统计（例如，帕累托分析、运行图、散点图、正态分布）
• 统计检验（如二项检验、卡方检验）
• 趋势分析（例如，控制图；见进一步阅读清单中的质量工具箱）
• 预测（例如，可靠性模型）。

基于描述性统计的技术和测试通常提供了被检查软件产品中更麻烦的领域的快照。由此产生的图表和图形是可视化辅助工具，决策者可以利用这些辅助工具集中资源，并在最需要的地方进行流程改进。趋势分析的结果可能表明某个计划正在得到满足，例如在测试中，或者除非在开发过程中采取一些纠正措施，否则某些类别的故障可能更容易发生。预测技术有助于估计测试工作和进度以及预测故障。在软件工程过程和软件工程管理KAs中，对度量的讨论越来越多。关于测试度量的更具体的信息在软件测试KA中给出。

软件质量度量包括度量缺陷发生率和应用统计方法来理解最常发生的缺陷类型。这些信息可能是他们的重复。它们还有助于了解趋势、探测和控制技术的工作情况以及开发和维护过程的进展情况。

通过这些测量方法，可以为特定的应用领域开发缺陷轮廓。然后，对于该组织内的下一个软件项目，概要文件可以用来指导SQM过程，也就是说，在最有可能发生问题的地方花费精力。类似地，基准测试或该领域的典型缺陷计数可以作为确定产品何时可以交付的一种辅助手段。在软件工程管理和软件工程过程KAs中，讨论了如何利用SQM中的数据来改进开发和维护过程。

4.软件质量工具

软件质量工具包括静态和动态分析工具。静态分析工具输入源代码，在不执行代码的情况下执行语法和语义分析，并将结果呈现给用户。除了源代码之外，静态分析工具在深度、彻底性和范围上有很多种，可以应用于包括模型在内的工件。（有关动态分析工具的说明，请参见软件构造、软件测试和软件维护KAs。）

静态分析工具的类别包括：

• 有助于并部分自动化文档和代码的审查和检查的工具。这些工具可以将工作路由到不同的参与者，以便部分地自动化和控制评审过程。它们允许用户输入在检查和评审期间发现的缺陷，以便以后删除。
• 一些工具帮助组织执行软件安全危害分析。例如，这些工具为故障模式和影响分析（FMEA）和故障树分析（FTA）提供自动支持。
• 支持软件问题跟踪的工具提供了在软件测试和后续分析、处置和解决过程中发现的异常的输入。一些工具包括对工作流和跟踪问题解决状态的支持。
• 分析从软件工程环境和软件测试环境捕获的数据并以图形、图表和表格的形式生成量化数据的可视化显示的工具。这些工具有时包括对数据集进行统计分析的功能（用于识别趋势和作出预测）。其中一些工具提供缺陷和移除注入率；缺陷密度；产量；每个生命周期阶段的缺陷注入和移除分布。