定制软件，是根据企业或被监管公司的实际业务和个性化需求，专门开发的业务系统或软件，

这类软件在GAMP5 验证实施指南被划分到第5类，从系统验证的角度来看, 这类软件的使用存在极高的风险，因为用户没有使用经验且缺乏系统可靠性的资料。

由于定制类软件系统复杂、开发风险高，具有新颖性、验证难度大，一直是制药企业CSV验证的重点和难点，如何才能既保证整个系统开发既实现预定功能、又能够做到高效、低成本合规呢?尽管这是个让大伙挠头的问题，但还是很值得我们大家去思考的。今天，我想从另外不同的角度和大家一起来探讨这个问题。

一、问题分析

1、传统的软件的开发和验证流程大都是这样的

这样的流程有如下3个特点：

1) 先完成软件开发，事后再做软件验证

2) 采用的是传统的软件项目管理方法

3) 开发和验证流程是分开的，没有结合

显然，按这样的流程来做系统验证，会带来如下诸多弊端：

1) 开发和验证资料脱节，风险极高;

2) 测试工作量大，且事后才能发现Bug;

3) 系统验证工作量大、成本高、效率低。

2、笔者经过重新思考、流程梳理，建议选择如下实施方法：

为什么要做这样的选择，下面我来为大家做详细解读。

二、方案比较

1 系统验证策略比较

“先开发、后验证”，是指软件开发完成后，交付前或交付后再来进行软件的验证;

“边开发、边验证”，是指软件在开发阶段，完成一部分内容即可进行验证，如阶段性的开发测试、代码评审等。

显然，从验证的角度来看，采用第二种验证策略，“边开发、边验证”来进行计算机化系统验证效果会更好。

2项目管理方式比较

2.1传统开发管理

2.2 CMMI 软件成熟度集成模型

CMMI全称是Capability Maturity Model Integration，即软件能力成熟度模型集成，1994年由美国国防部与卡内基-梅隆大学以及美国国防工业协会共同开发和研制的，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。

CMMI共有五个等级，即初始级、已管理级、已定义级、已定量管理级和优化级，这五个等级分别标志着软件企业能力成熟度的五个层次。从低到高，软件开发生产计划精度逐级升高，单位工程生产周期逐级缩短，单位工程成本逐级降低。据SEI统计，通过评估的软件公司对项目的估计与控制能力约提升40%到50%;生产率提高10%到20%，软件产品出错率下降超过1/3。

其研发项目管理模型如下图所示：

此模型将公司层面的“过程管理”、项目层面的“项目管理+工程+支持功能”有机地结合在一起，实现了公司发展目标、标准和项目实施目标、管理的一致性和可持续改进。

CMMI整体框架见如下示意图：

从上图可以看出，“同行评审”贯穿了整个项目研发过程，什么是“同行评审”?做“同行评审”的好处在哪里?

同行评审，简单来说就是做相同岗位的人员相互检查对方的工作，如开发人员相互Review对方写的代码是否有Bug。同行评审是一种很好的防范程序错误的有效机制，为PPQA对评审(活动、产品)实施检查提供依据。在项目初期，尽早发现缺陷。

从验证的角度来看，在软件开发过程中进行同行评审，有效降低了后续测试的工作量，从而减少了验证的工作量和复杂程度;同时也降低了开发风险。

质量源于设计，设计源于需求。从质量风险的角度来看，需求管理显得尤为重要，CMMI对软件需求的管理极为严格，需求管理模型见下图：

通过对需要的严格管控，确保软件设计的正确性和预期功能的准确性;特别是对需求变更进行严格控制，降低了软件开发的风险，同时也降低了系统验证的风险。

此外，质量保证PPQA不仅保证最终交付产品质量是好的，更重要的保证了开发的过程质量，这也充分体现了CMMI的核心管理思想，一切结果都源于过程，只要管理好过程，结果自然就是正确的。质量保证模型如下图所示：

PPQA根据过程检查单，通过参加项目和EPG的例会、项目和组织级过程相关的同行评审和里程碑评审会议、非周期性工作会议、与相关人员交谈等方式，检查项目和组织级的实际执行过程(包括项目管理过程、项目工程过程、支持过程、组织级过程)是否是符合既定的规范。

从系统验证角度来看，PPQA对过程质量的严格把控，降低了系统的开发风险和验证风险。

总结对比一下传统软件项目管理和CMMI软件成熟度模型二者方法优劣：

3 验证整合模式比较

3.1 开发和验证独立进行

假设我们采用的验证策略二：边开发、边验证，这种情况下很多被监管公司依然采用的验证方式是开发人员只管做开发的部分、验证人员只做验证的文档，事实上很多情况下，开发人员对验证流程并不清楚、验证人员对开发过程、尤其是开发技术也不是很懂，结果导致了大量的沟通成本，验证文档最终也是流于形式，不知所云，效率和效果都很低，具体操作体现为三个方面：

- 角色分开：开发人员、验证人员分别由不同的人员担当

- 流程分开：开发流程、验证流程分布在不同的流程文档

- 文档分开：开发文档、验证文档分别各自的模板和要求

3.2 开发和验证体系整合

同样的假设前提为采用验证策略二：边开发、边验证，根据笔者多年的实战经验，强烈建议对开发体系和验证体系进行整合，二者融为一体。如何整合，集中体现在以下三个方面：

- 角色整合：按照谁对业务最熟悉的原则进行开发和验证角色分配，一人可以担当多项职责，如开发人员即完成开发任务，又完成对技术文档的验证工作，这样效率最高。

- 流程整合：将开发流程和验证流程进行整合，可以在开发流程中增加验证控制节点，减少并简化多余流程。

- 文档整合：除测试类文档可作为验证文档使用外，其他文档如技术类方案，可增加验证方法，减少单独编制验证方案类文档，减少文档编制数量，尽量做到高效、低成本合规。

验证整合方式总结对比如下表所示：

三、方案落实

以上，我们对系统验证模式、开发管理方式以及验证整合方式进行剖析、比较，我们得到了最佳的定制软件的开发和验证实施方法：即采取“边开发、边验证”的验证策略，基于CMMI软件成熟度模型，将开发体系和验证体系进行整合来进行计算机化系统验证。

那么采用这样的方案，企业如何来具体落地呢?笔者认为，从以下几个方面着手落实：

1) 职责定义：明确相关岗位的人员应担当的角色，如设计、开发、测试、验证等

2) 流程梳理：对现有流程进行集中梳理，去除重复、无效的流程，保留的流程尽量简化

3) 文档模板：建立CMMI组织过程财富库，对文档模板进行整理，尽量做到通用、标准化

4) SOP制定：对现行SOP进行Review, 从CMMI和CSV二个角度进行SOP文件进行整合

5) 专业培训：更新后的岗位职责、流程文档、文档模板以及SOP进行全面专业地培训

6) SOP及方案执行：按最新的SOP以及配套方案执行相应的软件开发和系统验证活动

作者联系方式：

微信号：Goodlook2014迈克