验证的目的是确保流程或系统的一致性，并确保已记录在案。 系统验证是监管机构的一项要求。 例如，对于生命科学组织，监管机构包括美国食品药品监督管理局 (FDA)。
FDA 对验证的定义如下：
通过检查和提供客观证据确认可以始终如一地满足特定预期用途的特定要求。
世界卫生组织 (WHO) 在关于良好生产规范 (GMP) 要求的指南中对验证的定义如下：
建立可提供高度保证的文档证据，以保证计划的流程将完全符合预期的指定结果。
根据预期的结果，这些定义具有以下共同要素：
- 生成证据
- 符合法规
- 满足要求
计算机化系统的验证是一个文档化的流程，旨在确保系统以一致的、可重现的方式准确地执行其设计的任务。 验证可确保数据处理、产品质量的完整性和安全性，以及符合适用于良好{industry}实践 (GxP) 的法规。
由生命科学组织等受监管的行业创建和定义的标准操作程序 (SOP) 和准则中描述了验证计算机化系统的流程。 对于计算机化系统的验证，将实施过程视为一个项目很有用，如国际制药工程协会 (ISPE) 良好自动化生产规范 (GAMP) 5：基于风险的 GxP 计算机化系统合规方法中所述。
启动实施项目之前，应制定新解决方案的简要计划。 然后，通过完成以下阶段来启动项目：
- 规划：在此阶段，要求和规范应该足够清晰，以便进行初始风险评估，并最终正确定义验证测试（协议）。 在此阶段，您将交付定义整个验证策略的验证计划文档及所有可交付项。 该策略应符合质量管理系统 (QMS) 要求和政策。
- 规范、配置和编码：在此阶段，所有设计规范均按照系统类型及其用途所需的详细程度制定。 开发人员根据批准的规范选择和使用最适合编码和配置要求的开发方法和对象。 所有这些活动都是在开发环境中完成的。 在此阶段，测试更侧重于从开发人员的角度验证单元或功能。 测试活动的示例包括单元测试、代码统计测试和集成测试。 使用工具可以实现这些测试活动的自动化。
- 测试：此阶段通过检查和测试系统确认已满足规范。 测试活动是在准备好的合适的测试环境中完成的。 测试环境必须与生产环境相似，从而确保条件相同，且不需要在生产环境中重复测试。 风险应该决定测试工作的范围。 风险分析可以帮助您了解可能对产品质量、患者安全或数据完整性产生影响的潜在危险。 必须通过适当的控制和测试证明来减少这些潜在的危险。 如果某处存在高风险，则有适当的测试场景来证明解决方案设计没有潜在的故障。
- 报告和发布：在此阶段，系统必须可以根据书面的受控流程在生产环境中投入使用。 必须在项目关闭时准备完成系统验证，以总结所开展的活动以及与验证计划存在的任何偏差。 应在发布系统以供使用之前完成对系统的验证。
下图所示为 GAMP 5 第二版支持的 V 模型。 它提供了一种很好的查看项目阶段的整体方式。
V 模型不仅可以看作是系统的开发活动和测试，还可以看作是它们的顺序、它们的相互关系，以及适用于经过验证的计算机化系统的可交付成果的验证过程。 您必须保持并维护需求、规范和测试之间的相互关系。 这种相互关系记录在受监管区域中使用的可追溯性矩阵中。
可追溯性矩阵可确保：
- 需求由解决方案设计满足。 换句话说，每个需求都可以追溯到功能、控制、配置或设计元素。
- 需求得到测试或验证，以证明解决方案设计满足需求（如果适用）。
可追溯性矩阵具有以下好处：
- 支持设计审核。
- 有助于定义回归测试的范围。
- 在检查或审核活动期间提供支持。
- 为可能发生的变化提供支持。
平台资格授予
受监管的行业必须在实施 Guides 之前向 Microsoft Power Platform 授予作为基础结构的资格。 授予平台资格时需要至少执行以下任务：
初始风险评估（评估 GxP 适用性）
供应商评估（供应商审核，是虚拟形式、线下形式还是邮寄形式）
资格授予计划
平台设计技术规范
风险评估（例如，评估向操作员提供错误版本指南的风险）
测试：
- 安装测试（例如，测试是否正确安装了环境）
- 操作测试（例如，测试用户是否具有正确的访问权限）
资格授予报告摘要
平台或操作手册及培训材料
应用程序验证
为受监管行业提供业务流程支持的应用程序（例如 Guides 和 Power Apps）必须经过验证。 因此，您的组织必须完成以下任务：
初始风险评估
验证计划
用户要求
风险评估
应用程序功能规范或配置技术规范
测试（安装资格 [IQ]、操作资格 [OQ] 和用户验收测试 [UAT]）：
- 操作测试（例如，验证功能）
- UAT
可追溯性矩阵
验证报告摘要
应用程序或操作手册及培训材料