欢迎您注册蒲公英
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
在计算机化系统验证中,如何在众多的风险评估方法中选择合适的,是一个让大多数验证人员感到迷茫的问题。ICH Q9 和 ISO 14971中列出的方法就有:
失效模式影响分析(FMEA):用于设计或过程风险分析完善的风险分析方法。
危害分析及关键控制点(HACCP):基于过程的方法,主要应用于食品行业,在CSV方面的使用有限。
失效模式影响与危害性分析(FMECA):与FMEA类似,相比增加了危害性分析。
危害与可操作性分析(HAZOP):主要用于评估包含设备和设施的生产过程安全性危害,对CSV适用性有限。
故障树分析(FTA):使用逻辑门和事件的自上而下的结构化方法,很少应用于软件。
初步危害分析(PHA):运用以前类似的项目经验在项目开始时进行的方法,很少应用于CSV。
功能风险分析(FRA):适用于商用软件的一种简化的风险评估方法。
实际上,计算机化系统风险评估主要使用两种方法:失效模式影响分析(FMEA)和功能风险分析(FRA)。前者应用广泛,想必大家都很熟悉,其优点不少,但过程冗长,耗时耗力;后者相对使用较少,但具有其独到的优势,下面将具体介绍。
功能风险分析(FRA)是一种更为简单的风险评估方法,专门针对商用软件的验证而开发。该方法的分析过程如下:首先将各条用户需求划分为强制的(M)或可选的(D),系统正常运行所必需的或者法规要求的需求就是强制的,否则就是可选的。接下来再确定各功能需求在业务和/或法规方面的风险是关键性的(C)还是非关键性的(N)。如果一个功能需求有问题而没有任何控制措施将导致监管机构发缺陷,那么它就有关键性的法规风险,例如访问控制、数据存储等。如果一个功能需求有问题引起系统不可用将导致关键业务不能开展,那么它就有关键性的业务风险,例如用于支持连续生产样品检测的网络版色谱工作站在断网情况下不能连续运行属于关键性的风险。
评级结果计算如下表所示:
仔细梳理这个表格,会发现对于大多数商业系统而言,需求的风险评级要么为高,要么为低,为中的较少。这可以理解,如果需求只是可选的,为什么它会有关键性风险呢?如果需求是强制的,那么它有多大可能会是非关键性风险呢?
从功能风险分析(FRA)的过程可以看出,只需要一个2x2的四宫格评级即可评出高、中、低三种风险等级,这种方法需要考虑的维度较少,笔者认为只适合于3类和4类软件的风险评估。而常见的失效模式影响分析(FMEA)先后需要两个3x3的九宫格的评级才能得出高、中、低三种风险优先级,这种方法需要考虑的维度较多,虽然可以适用于从简单到复杂的各类软件系统的风险评估,但笔者认为其最适合的还是最复杂的5类软件,运用于不算复杂的3类和4类软件则显得过于求全,会额外花费不少时间和精力。
下面以沃特世Empower软件为例,笔者选取Empower企业版的部分用户需求进行风险评估,简单介绍功能风险分析(FRA)的应用,供参考。
逐条分析如下:
需求1:不同级别的访问权限是法规要求,所以该需求是强制的(M),有关键性(C)的业务法规风险,风险评级为高。
需求2:法规要求电子数据的存储必须包含元数据,所以该需求是强制的(M),有关键性(C)的法规风险,风险评级为高。
需求3:法规要求经电子签名的数据被锁定,所以该需求是强制的(M),有关键性(C)的法规风险,风险评级为高。
需求4:系统必须要能根据处理方法中定义的参数来对峰进行积分才能进行正常的数据处理,所以该需求是强制的(M),有关键性(C)的业务风险,风险评级为高。
需求5:Empower身为成熟的色谱类商用软件,系统自带的报告模板可以满足各项法规要求,所以自定义的需求是可选的(D),只有非关键性(N)的业务法规风险,风险评级为低。
需求6:系统必须要确保在LAC/E32与数据库服务器发生网络中断时不会影响数据采集,否则会导致出现网络故障时不能检测样品,所以该需求是强制的(M)。如果该系统用于生产,则有关键性(C)的业务风险,整体风险评级为高。如果用于研发,则只有非关键性(N)的业务风险,整体风险评级为中。
基于功能风险分析结果,可对高风险的需求进行更为严格的测试,如压力测试等;对于中风险的需求进行普通测试;而对低风险的需求可不进行测试。从而可以减少测试工作量。
相对于传统的失效模式影响分析(FMEA),功能风险分析(FRA)减少了风险评估的工作量,为用户执行4类软件(如Empower)的风险评估提供了新的思路。
|