1 目的
验证过程 1的目的是提供客观证据，证明某个系统或系统要素满足其指定的要求和特性。
验证过程使用适当的方法、技术、标准或规则来识别任何信息项（例如系统/软件需求或架构描述）、已实现的系统元素或生命周期过程中的异常（错误、缺陷或故障）。此过程提供必要的信息以确定已识别异常的解决方案。
验证可以在所有技术过程中进行。验证过程通常用于软件系统生命周期的关键点，以证明需求（包括功能和非功能）
里程碑、验证策略和标准必须能够确定是否满足了流程目标（即，功能要求）或者是否实现了流程结果或者是否执行了流程活动。不同的领域和工程或开发社区可以用不同的方式识别里程碑、验证策略和标准。
对于软件系统，验证过程通常实例化以下目的：
- 确认软件产品或服务正确反映了规定的要求（通常 称为软件验证）；
- 确认集成的软件产品满足其定义的要求（通常称为软件 资格测试)；以及
- 确认每个系统/软件要求的实施都经过合规测试， 并且软件系统已准备好交付（通常称为系统资格测试）。
注：验证过程确定“产品是否正确制造”。确认过程 2确定“产品是否正确制造”。
注：ISO/IEC/IEEE29119系统和软件工程 ‑ 软件测试（多个部分）提供了通过测试执行验证的详细过程和技术。IEEEStd1012‑2012《IEEE 系统和软件验证和确认标准》 为正在开发、维护或重用的系统、 软件、硬件和接口提供了有关这些过程的更多详细信息。
注：SWEBOK（软件工程知识体系指南）提供了有关软件测试的详细讨论。此知识领域涉及基础知识、术语、问题、技术、应用、过程规划、 措施、工具、实际考虑和参考。 该指南还讨论了软件质量管理过程方面的软件验证和确认，并确定了支持验证和确认的方法和技术。SWEBOK 还涉及验证的软件构造和软件工程模型和方法支持等主题。
2 结果
成功实施验证过程的结果是：
- 确定影响需求、 架构或设计的验证约束。
b)验证所需的任何支持系统或服务均可用。
c)系统或系统要素已经验证。
d)报告为纠正措施提供信息的数据。
e)提供客观证据证明实现的系统满足要求、架构和设计。
- 确认验证结果并发现异常。
g)建立已验证系统要素的可追溯性 3。
3 活动和任务
项目应根据组织有关验证过程的适用政策和程序实施以下活动和任务。
a)准备验证。此活动包括以下任务：
1）定义验证策略，包括以下内容：
注：验证策略通常侧重于最小化成本、进度或风险，提供一种平衡的方法来确认软件系统或元素已“正确构建”。
注：验证策略和计划考虑了发生异常结果（事件、事故或问题）时的动态变化。根据项目的进展，当发生意外事件或系统演变时，计划的验证活动将被重新定义或重新安排。
注：验证策略可以记录在计划中，例如验证计划或项目的 SDP 或 SEMP。
我） 确定验证范围，包括软件系统、元素或工件、要验证的属性和预期结果。
注：总体验证范围包括感兴趣的软件系统或系统元素，其中包括接口。对于每个验证操作，范围确定要验证的软件系统、元素或工件（例如，实际系统、模型、模型、原型、代码、程序、计划或其他文档）和预期结果，例如一致性、性能、容错和服务中断后的恢复。要验证的属性可以包括需求、架构和设计特性、集成和文档的准确性。设计特性可以包括设计在计划的操作环境中的安全含义和需求中所述的关键质量特性的实现。
二） 识别可能限制验证行动可行性的约束。
注：约束包括技术可行性、 成本、时间、验证推动因素或合格人员的可用性、合同约束以及任务的关键性等特性。这种约束通常影响验证策略的确定，例如，组织独立的验证工作是否必要或合理。
三） 确定验证优先级 4。
注意在软件系统中，验证所有可能的情况（100％代码覆盖率）通常是不可行的。验证策略通常包括权衡待验证内容（范围）与约束或限制，并推断要执行哪些验证操作以及需要进行多少次验证操作和返工迭代才能降低风险。基于模型的测试方法可以生成和管理多个场景。评估可能被删除的验证操作的风险及其撤回
强加。
2）识别验证策略中需要纳入系统/软件的约束需求、架构或设计。
注：这包括验证因素、相关测量方法、软件系统集成需求以及可用性、可访问性和与因素的互连性所施加的准确度、不确定性、重复性的实际限制。
3）定义每个验证行动的目的、条件和符合性标准。
4）选择适当的验证方法或技术以及相关标准进行验证行动，如检查、分析、演示或测试。
注1：验证方法或技术的选择应根据系统的类型、验证的目的、项目的目标和可接受的风险进行。验证方法或技术包括检查
（包括代码演练和同行评审 5）、分析（包括建模和模拟、类比/相似性）、演示、以及动态和静态测试。
注：所选的验证方式、方法和技术可与相关利益相关者 6进行协调，以帮助确保验证方法是可接受的。
- 识别并规划支持验证所需的必要支持系统或服务。
注：验证支持系统包括验证设施、合格人员、设备、模拟器、测试自动化工具以及事件和问题管理系统。软件系统验证通常在不干扰操作软件或正在进行的开发的模糊受控环境中进行。如果验证支持系统的能力与计划的操作环境不同，则可使用测量过程来校准验证支持系统的性能和验证操作的适用性。
- 获取或获得用于支持验证的支持系统或服务的访问权限。
注：支持系统的获得可以通过多种方式进行，如租赁、采购、开发、组织资产 7的再利用或分包。通常，全套支持系统的获得是这些方式的混合。验证过程用于客观地确认验证支持系统实现了其支持功能的预期用途。
b)进行验证。此活动包括以下任务：
1)定义验证程序，每个程序支持一项或一组验证操作。
注：验证程序可由自动脚本执行，包括待验证的要求、待验证的软件系统元素或工件的类型（例如，实际系统、模型、模型、原型、代码、程序、计划或其他信息项）以及预期结果（成功标准），例如一致性、功能执行情况或响应时间或吞吐量方面的容量。该程序驻留验证的目的和成功标准（预期结果）、要应用的验证技术、必要的支持系统（设施、设备）以及执行每个验证程序的环境条件（资源、合格人员、专门的程序设置或工作说明）。验证程序包括如何记录、分析、存储和报告验证程序结果。
2）执行验证程序。
注：验证根据验证策略在计划的适当时间、定义的环境中、使用定义的支持系统和资源进行。验证操作的执行包括从验证程序的执行中获取结果；将获得并记录的结果与预期结果进行比较；并推断出所提交元素的正确性（或成功/失败）程度。
c)管理验证结果。此项活动包括以下任务：
1）审查验证结果和遇到的异常并确定后续行动。
注：这包括由于验证策略、验证支持系统、验证执行或不正确的系统定义而导致的异常。项目评估与控制和质量保证流程用于分析数据以确定根本原因 8、 采取纠正或改进措施并记录经验教训。
注：验证结果评估和后续纠正措施可能因验证目的的不同而有很大差异。对于软件元素，示例包括修改或放弃要求、对失败的软件元素进行简单的缺陷修复、随后进行重新验证或基于未能达到关键里程碑（例如，软件系统鉴定测试失败）进行重大项目重定向。通常，对验证期间发现的异常的简单或建议的解决方案会与验证结果一起记录下来，以方便分析和采取潜在的纠正措施。
2）记录验证过程中的事件和问题并跟踪其解决情况。
注：问题解决是通过质量保证和项目评估与控制过程 9进行的。在软件验证期间，将记录问题发生的情况，以便在可能的情况下可重复该问题并确定软件缺陷的根本原因。对其他需求、架构、设计或系统元素的更改是使用其他技术过程来完成的。
- 获得利益相关者的同意，认为软件系统或元素满足指定的要求。
4)保持已验证的软件系统元素的可追溯性。
注：已验证的系统元素与验证活动、系统架构、设计或系统/软件需求的记录之间保持双向可追溯性。
- 提供已选定的基线关键工件和信息项。
注意配置管理流程用于建立和维护配置项和基线。此流程确定基线的候选者，而信息管理流程控制信息项。
对于此过程，验证策略和验证程序是典型的信息项。