CS系列课 | CSV计算机化系统验证全流程：3/4/5类各做什么？哪些文件能合并？

今天我们来梳理一下CSV全流程，希望对大家有所帮助。全文核心要点：4类做基准，3类做减法，5类做加法。我们把每个阶段的流程和文件差异做了图表对比，希望能帮大家一眼看清差异，也方便保存下来对照使用。

我们也同步制作了专题视频，习惯听课的朋友可以点击观看。

关于计算机化系统（CS）怎么分类，我们在《CS基础六问：小白从入门到厘清核心概念》里已经聊过（欢迎点击阅读）。

4类：验证流程的“基准线”

以4类可配置软件(如ERP、LIMS)为基准，介绍典型的验证流程，如图：

• 验证计划（VP）：用于定义验证策略，说明所需要开展的全部验证活动、遵循的质量管理体系以及实施计划等。
  
  

• 用户需求说明（URS）：用于记录用户对系统的所有需求，包括业务需求、技术需求、合规需求等等。用户需求也是PQ的可接受标准。
  
  

• 质量项目计划：面向欧美合规性的验证项目，有时候需要准备这份文件。该文件从项目管理的角度，说明供应商的QMS和项目管理。如果系统不涉及外部供应商，通常不需要考虑这份文件。
  
  

• 设计文档：通常包括功能设计和详细设计。功能设计采用通俗易懂的语言，说明系统设计是如何响应用户需求的；详细设计需要包括硬件、软件、网络等各项技术细节。
  
  

• 设计确认（DQ）：提供文件化的证据，证明系统设计充分考虑了用户需求。在设计文件批准后，即可实施设计确认。
  
  

• 风险评估报告：后续确认活动中的测试项，需要基于风险评估来确定；用户需求和设计文件批准后，风险评估也可以基于这些信息开展，编写风险评估报告。
  
  

• 工厂验收测试（FAT）& 现场验收测试（SAT）：大部分工艺自动化相关的系统都需要开展FAT和SAT，因为这些系统通常涉及供应商在工厂端的活动。对于纯软件类的系统，例如文件管理系统、ERP等常见的B/S架构软件，FAT和SAT可能并不适用。（需要注意的是：FAT和SAT的开展需要考虑项目的实际情况，但这个策略需要在VP中进行说明。）
  
  

• 安装确认（IQ）：静态检查，用于确认系统的安装、配置与连接等符合系统的设计，确保系统在运行起来之前，所有的条件都是满足的，避免运行的时候出现错误。
  
  

• 运行确认（OQ）：动态测试，用于确认系统的各项功能符合系统设计。通常需要覆盖到所有的关键功能模块。复杂系统特定的功能测试很多时候需要使用虚拟数据，确保高覆盖率，把特殊情况都要测试到。
  
  

• 性能确认（PQ）：用于确认系统符合预期用途。它以系统各项功能正确为前提，结合或者模拟实际业务进行测试，评价系统的业务需求符合性和稳定性。
  
  

• 风险评估审核报告：结合已开展的控制措施，对各项风险进行审核评价，生成风险评估审核报告。
  
  

• 需求追溯矩阵：结合需求在各阶段的追溯响应情况，完成需求追溯矩阵，对比VP。
  
  

• 验证总结报告：结合全部开展的活动和批准的文件，汇总形成验证总结报告，对系统的放行状态进行评价。

3类：在4类基础上做“减法”

3类是市售标准软件，验证流程大幅简化。它和4类最大的不同在于：供应商几乎不需要参与系统的部署，也不会提供特异性的设计——没有定制，需要确认的东西自然就少了。

5类系统：在4类基础上做“加法”

5类定制化软件相对于4类，多了软件开发活动。因此在流程上，增加对软件开发过程的控制，如图：

（图注：5类=4类流程+软件开发过程控制）

• 软件需求说明：主要描述用户对软件的要求，作为定制软件的设计基础。

  
  

• 软件概要设计和详细设计：从不同的层级描述软件各个模块的功能业务步骤、功能结构、数据模型、实现过程和代码设计介绍等。

  
  

• 设计评审：需要软件开发人员基于需求文件和设计文件开展，确保设计充分考虑了各项需求，而且是可实现的。它是编程活动的先决条件。

  
  

• 代码审核：由软件开发人员在代码编写完成后，检查代码的规范性、正确性与合理性等。它是单元测试的先决条件。

  
  

• 单元测试：在代码层面检查代码运行的正确性。它是集成测试开展的先决条件。

  
  

• 集成测试：关注软件各个模块在集成后，不同模块之间数据交互的正确性。

  
  

• 功能测试／系统测试：在不同的环境中执行，对软件功能进行检查。

一张表看清：

3类/4类/5类的验证活动差异

实际项目中，纯4类系统不多见，更常见的是复杂的可配置软件+个别功能模块定制开发。遇到这种情况，定制的部分按5类管控即可。

4类做基准，5类做加法，3类做减法——这套验证框架，已经可以覆盖绝大部分的系统验证。

#计算机化系统验证 #CSV #CS

#验证流程 #系统验证 #验证文件