软件生命周期流程-确认过程 - IEEE 12207-2017 软件和系统工程标准系列-技术流程

1 目的

验证过程 ¹的目的是提供客观证据，证明系统在使用时能够满足其业务或任务目标以及利益相关者的要求，并在预期的运行环境中实现其预期用途。

验证一个系统或系统元素的目的是为了获得信心，使其能够在特定的操作条件下实现其预期的任务或用途。验证由利益相关者 ²批准。这一过程提供必要的信息，以便可以通过产生异常的适当技术过程解决已识别的异常。

验证过程通常用于产品生命周期的关键点，以证明产品已满足利益相关者的预期操作用途要求。验证也适用于软件工程工件（被视为软件系统元素）。不同的领域和工程或开发社区可以用不同的方式识别里程碑、验证策略和标准。

对于软件系统，高度迭代的生命周期模型通常需要购买方、用户代表或其他利益相关者的频繁参与，以验证诸如在迭代中包含的需求的优先级 ³、通过原型的软件界面的可用性、以及软件执行业务任务和实现操作概念的适用性等。

对于软件系统，验证过程的目的如下：

• 1. 确认软件工作产品的特定预期用途的要求得到满足 （通常称为软件验证）；以及
• 2. 建立信心（尤其是对收单方或客户而言）， 确保交付的产品符合利益相关者的要求并且不适合使用（通常称为软件验收测试）。

注：确认过程 ⁴确定“生产出正确的产品”。验证过程确定“生产出正确的产品”。

注：验收标准 ⁵用于验收测试，包括确定交付产品是否适宜使用的标准。验收标准可由双方（即，需方和供方）指定和商定，并纳入利益相关方的要求中。

注：IEEEStd1012‑2012 （IEEE 系统和软件验证和确认标准）提供了详细的要求。 SWEBOK（软件工程知识体系指南）从软件质量管理过程的角度讨论了软件验证和确认， 并包含支持验证和确认的方法和技术。SWEBOK 还涉及需求和模型确认等主题。

2 结果

作为成功实施验证过程的结果

• 1. 定义利益相关者要求的验证标准。
• 2. 确认利益相关方所需服务的可用性。
• 3. 确定影响需求、 架构或设计的验证约束。
• 4. 系统或系统元素已经验证。
• 5. 验证所需的任何支持系统或服务均可用。
• 6. 确定验证结果和异常。
• 7. 提供客观证据证明已实现的系统或系统要素满足利益相关者的需求。
• 8. 建立已验证系统要素的可追溯性 ⁶。

3 活动和任务

项目应根据与验证过程相关的适用组织政策和程序实施以下活动和任务。

a)准备验证。此活动包括以下任务：

1）定义验证策略，包括以下内容：

注：验证策略通常侧重于通过逐步建立利益相关者对软件系统质量和适用性的信心来最大限度地降低成本、进度或风险。

注：验证策略体现生命周期模型，通常涉及迭代、增量或革命性生命周期的重复验证。

注：验证策略可以记录在计划中，例如验收计划或项目的 SDP 或 SEMP。

我） 确定验证范围，包括要验证的软件系统、元素或工件的特性，以及验证的预期结果。

注：软件系统验证通常在不干扰软件运行或正在进行的开发的明确受控环境中以及在运行环境中执行， 通常在全面运行使用之前（例如，按照商定的标准在指定持续时间内进行 beta 测试或验收测试）。范围包括利益相关者的要求，包括要评估的系统的相关观点（例如，场景或操作概念）。范围取决于什么是适当的系统生命周期阶段 ⁷的范围： 感兴趣的系统、系统元素或工程工件，例如概念描述或文档、操作场景、模型、模型或原型。该范围还包括评估软件产品或服务在预期环境中是否可用于主要或关键功能。 需要验证的其他特性可以包括文档的可用性；软件的容错、弹性和恢复功能。

二） 识别可能限制验证行动可行性的约束。

注：约束包括由验证推动因素、相关测量方法以及可用性、可访问性和与推动因素的互连性所施加的准确性、不确定性和重复性的实际限制。验证策略受项目进展的制约；特别是，当发生意外事件或系统演变时，计划的验证活动会被重新定义或重新安排。验证可以扩展以包括对用户满意度和客户投诉的持续测量。

三） 确定验证优先级。

注：为了有效利用利益相关者的时间和专业知识，验证通常侧重于利益相关者的优先事项，而验证则用于非功能性需求 ⁸。对可能被删除的验证行动进行评估，以确定其退出所带来的风险

注：供应商 ⁹、需方或需方代理人参与或执行验证。其责任通常在协议中指定。

2）从验证策略中识别出需要纳入利益相关者的系统约束要求。

3）定义每个验证行动的目的、条件和符合性标准。

• 4. 为每个验证行动选择适当的验证方法或技术以及相关标准。

注：软件系统验证方法或技术包括检查、 分析、类比/相似性、演示、模拟、同行评审 ¹⁰和测试。软件验证技术通常包括演示、检查、 评审和代码演练、 可用性测试和软件试用（例如， beta 测试、操作测试、用户测试或按照商定标准进行的验收测试）。验证方法或技术的选择取决于根据系统的类型、 验证的目的、 项目的目标、法律和监管要求以及验证行动的可接受风险来确定可用性测试。 对于具有人机交互的软件系统， 可用性测试通常用于验证代表性用户是否能够在指定的使用环境中以有效性、 效率和满意度实现指定的目标。有关可用性测试的更多详细信息，请参阅ISO/IECTR25060:2010

系统和软件工程 系统和软件产品质量要求和评估(SQuaRE)可用性的通用行业格式 (CIF)：可用性相关信息的通用框架。

注：在适当的情况下，定义验证步骤或状态（例如内部验证、现场验证、操作验证），以逐步建立对不断发展的软件系统的一致性的信心，并协助诊断任何遇到的差异。

注：利益相关者接受服务性能的标准通常以服务级别表述，并记录在服务级别协议 (SLA) 中。服务级别通常衡量服务的容量、可用性、可靠性和及时响应，并产生对支持系统的性能要求。

• 5. 识别并规划支持验证所需的必要支持系统或服务。

注：根据所选的验证方法或技术，启用系统可以包括模拟器、可用性实验室或测试设施、合格人员、利益相关者和用户代表。这包括识别启用系统的要求和接口。

• 6. 获取或获得用于支持验证的支持系统或服务的访问权限。

注：可以调用基础设施管理处理器获取过程来获得对支持系统的访问权，比如通过租赁、采购、开发、重用或分包。通常，对整套支持系统的访问是这些方式的混合。验证过程还用于客观地确认验证支持系统实现了其支持功能的预期用途。

b)执行验证。此活动包括以下任务：

• 1. 定义验证程序，每个程序支持一项或一组验证操作。

注：验证程序应包含待验证的利益相关方要求、相关软件系统工件（如实际系统、模型、实体模型、原型、代码、说明书或其他信息项）和预期结果（成功标准），如是否能及时完成某项功能。验证程序应包含验证的目的、成功标准（预期结果）、应采用的验证技术、必要的支持系统（设施、设备）和执行每个验证程序的环境条件（资源、合格人员、参与的利益相关方、专门的程序设置或工作说明）。

验证策略包括显示验证程序结果将被记录、分析、存储和报告。

• 2. 在定义的环境中执行验证程序。

注：验证根据验证策略在计划的适当时间在定义的环境（例如操作环境、模拟测试环境或其他代表性环境）中发生，具有定义的推动因素和资源。验证活动的执行通常包括获取执行结果、将获得的结果与成功标准进行比较，以及推断出软件系统、元素、服务或工程工件的合规程度或利益相关者的满意度。

c)管理验证结果。此项活动包括以下任务：

1）审查验证结果和遇到的异常并确定后续行动。

注：确认利益相关者所需的系统服务可用。异常可能由验证策略、验证支持系统、验证执行、不正确的系统定义或低效或无效的系统设计、实施和集成造成。

注：验证结果和后续措施的评估可包括在低风险发生时接受异常。纠正措施可能因验证结果的影响而有很大差异。对于软件元素，示例包括对失败的软件元素的简单缺陷修复、对用户的额外培训、文档中的更正和澄清，或基于未能达到关键里程碑而进行的主要项目重定向（例如，失败的软件系统验收测试）。

2）记录验证过程中的事件和问题并跟踪其解决方案。

注：项目评估和控制流程以及质量保证流程用于分析数据，以确定问题的根本原因 ¹¹，从而采取纠正或改进措施，并记录所获得的经验教训。在软件验证期间，将记录利益相关者期望与系统性能之间的差距，以便在可能的情况下确定差异的根本原因。问题解决通常涉及确定问题的严重性和影响，以及是否或何时需要纠正软件差异或暂时将其作为已知错误接受。验证期间发现的异常的简单或推荐解决方案通常会与验证一起记录

结果有助于分析和潜在的纠正措施。对利益相关者和系统/软件需求、架构、设计或系统元素的实际更改是在其他技术过程中完成的。

• 3. 获得利益相关者的同意，即软件系统或要素满足利益相关者的需求。

4)保持已验证系统要素的可追溯性。

注：已验证的系统要素与利益相关者的要求和验证结果记录之间保持双向可追溯性。

• 5. 提供已选定的基线关键工件和信息项。

注意配置管理过程用于建立和维护配置项和基线。此过程确定基线的候选者（例如已验证的软件系统或元素），而信息管理过程控制信息项。对于此过程，验证策略和验证结果是典型的基线信息项。