生产检验用计算机系统验证管理规定.docx

上传人:b****5 文档编号:14514498 上传时间:2023-06-24 格式:DOCX 页数:13 大小:290.80KB
下载 相关 举报
生产检验用计算机系统验证管理规定.docx_第1页
第1页 / 共13页
生产检验用计算机系统验证管理规定.docx_第2页
第2页 / 共13页
生产检验用计算机系统验证管理规定.docx_第3页
第3页 / 共13页
生产检验用计算机系统验证管理规定.docx_第4页
第4页 / 共13页
生产检验用计算机系统验证管理规定.docx_第5页
第5页 / 共13页
生产检验用计算机系统验证管理规定.docx_第6页
第6页 / 共13页
生产检验用计算机系统验证管理规定.docx_第7页
第7页 / 共13页
生产检验用计算机系统验证管理规定.docx_第8页
第8页 / 共13页
生产检验用计算机系统验证管理规定.docx_第9页
第9页 / 共13页
生产检验用计算机系统验证管理规定.docx_第10页
第10页 / 共13页
生产检验用计算机系统验证管理规定.docx_第11页
第11页 / 共13页
生产检验用计算机系统验证管理规定.docx_第12页
第12页 / 共13页
生产检验用计算机系统验证管理规定.docx_第13页
第13页 / 共13页
亲,该文档总共13页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

生产检验用计算机系统验证管理规定.docx

《生产检验用计算机系统验证管理规定.docx》由会员分享,可在线阅读,更多相关《生产检验用计算机系统验证管理规定.docx(13页珍藏版)》请在冰点文库上搜索。

生产检验用计算机系统验证管理规定.docx

生产检验用计算机系统验证管理规定

 

生产、检验用计算机系统验证管理规定(总8页)

XX有限公司

生产、检验用计算机系统验证管理规定

制定部门

机械动力工程部

制定人:

年月日

审核人

副总经理:

年月日

副总经理:

年月日

1主题内容与适用范围

  本文件规定了公司生产、检验用计算机系统验证管理的内容和要求。

  本文件适用于公司生产、检验用计算机系统的验证管理。

2引用标准

《药品生产质量管理规范》 2010年修订

《兽药生产质量管理规范》 2002年6月

ICH Q7A        2000年11月

3术语

计算机系统:

由硬件、系统软件、应用软件以及相关外围设备组成的,可执行某一功能或一组功能体系。

计算机系统验证:

是建立文件来证明计算机系统的开发符合质量工程的原则,能够提供满足用户需求的功能并且能够稳定长期工作的过程。

硬件:

由电子线路组成,受软件控制的实物装置。

软件:

指控制计算机系统或计算机化系统运行的程序、主程序或子程序的总称。

4职责

质量保证部负责编制年度计算机系统验证计划。

 使用单位负责成立验证小组,制定验证方案,并组织实施。

机械动力工程部负责监督生产用计算机系统验证的实施情况。

5管理规定

 

所有生产、检验用计算机系统都需要验证。

如果现行系统在安装时没进行验证,在有合适的文件可以证明时可进行回顾性验证。

质量保证部每年初下发年度验证计划。

计算机系统由使用单位负责成立验证小组,制定验证方案,并组织实施。

验证

验证的范围

计算机系统的验证不只局限于系统的使用过程,新系统的验证应始于系统初期的定义和设计阶段,终止于系统无使用价值阶段。

验证生命周期应伴随着系统发展的整个生命周期。

系统发展的生命周期划分为以下8个阶段:

可行性研究、工程计划、需求定义、系统设计、系统测试、系统验收及确认、使用和维护、系统引退。

需准备的文件资料,包括使用单位最初的需求标准文件、需要达到的功能标准文件和计算机系统设计标准文件。

可行性研究

要求从技术及经济等方面系统地研究并论证开发/变更计算机系统的可行性,包括目的、概念定义、规模、风险分析、投资分析等。

上述工作形成的文件,作为确定系统验证规模的依据。

一般DCS系统应当做全部项目的验证,PLC系统可以做选择项目的验证。

工程计划

工程计划用于规划所有工程及验证活动,包括工程的组织结构、各部门/个人的职责、工程进度表、文件交付、审核和批准要求等。

应对计算机系统供方进行评价,以确保其系统能力及所提供的产品满足计算机系统验证要求。

根据系统概念定义及判断选择供方,注意评估外部资料对标准要求的符合化及与系统要求文件的一致程度。

对供方质量体系进行审计,供方审计报告应纳入验证档案。

审计内容包括:

a系统开发者的内部质量管理程序。

b技术能力评估。

c软件开发标准及软件测试能力。

d程序编制人员的资格审定。

e硬件开发及制造能力。

f变更控制。

g售后服务。

h系统安全性。

验证计划伴随着工程计划一起,用于指导整个计算机系统验证活动。

验证计划包括:

a系统描述/构造

b适用的政策、程序及指导方针

c责任

d供户评价/审计

e设想/排除/局限性

f文件—系统、技术和操作

g验证文件的保持

h测试程序

i可接受标准

j偏差处理

k变更控制

l安全线

m备份/存档/灾难恢复

n人员培训

o验证草案和报告(IQ、OQ及PQ)

需求定义

需求定义阶段提供新的/改变的计算机系统所期望达到的详细的、可衡量的需求,所有需求将用来确定系统设计标准。

需求定义阶段主要是提供用户需求说明(URS)。

用户需求说明(URS)包括:

a系统说明:

说明全系统要做什么,模块间怎样连接及相互作用,控制方式,执行的过程,操作人员对接口的要求及安全性要求等。

b物理要求:

物理要求包括有效空间、位置、所处的环境等。

c硬件文件标准:

硬件文件标准包括图纸、流程图、手册、部件清单等。

d软件文件标准软件文件标准包括程序编号及修订号、打印出的程序及详细解释、复制件的提供及贮存条件、系统框图及配置清单。

e测试要求系统开发过程中所要求进行的测试项目及记录。

包括单独模块测试及集成测试等。

f其他其他提供给供户的要求。

包括对已完成的系统的验证要求、关于在设计开发过程中的质量控制和变更控制要求等。

g用户需求说明中的所有条款将直接作为制定IQ、OQ及PQ草案的依据。

系统设计

所有的需求被转化为计算机系统硬件和软件的技术设计。

具体包括如下:

a、硬件设计标准将定义如标准仪器、微控制器、可编程序逻辑控制器(PLC)等。

b、软件设计标准将定义系统的整体框架、计算机语言、界面、屏幕设计、数据流程图、报告设计、图表设计、运算法则、安全测试、系统结构图、I/O图、工程制图、流程图解、程序体系图解、详细说明和一个数据字典。

必须根据已定义的标准编写、维护和使用源代码。

源代码包括所有组成系统的目标、变量、逻辑及配置程序,源代码被用于软件开发过程中的技术查阅及系统使用后的维护活动。

系统设计文件一般由供户制订,但必须经过用户审核及认可后方可实施。

系统测试

该阶段的主要任务是发现并排除在分析、设计、编程各阶段中产生的各种类型的错误,以得到可运行的计算机系统。

系统测试和确认过程与系统的需求定义、设计及编程阶段相对应,如图6-3所示。

单元测试及组装测试一般在供户处进行。

单元测试是对系统的每一个模块进行独立测试,其目的是找出与模块的内部逻辑有关的错误。

单元测试一般以白盒法为主。

集成测试根据系统设计中各功能模块的说明及制定的组装测试计划,将经过单元测试的模块逐步进行组装和测试。

每并人一个模块,都要找出由此产生的错误。

集成测试一般以黑盒法为主。

系统验收及确认

当最终的计算机系统及相关的文件发至用户,被安装在用户环境中后,需评价其功能的正确性,即进行确认测试。

确认测试(安装确认、运行确认及性能确认)是计算机系统付之实际使用之前的既完整又系统的测试,是计算机系统质量保证的最后一个环节。

确认测试一般由用户执行。

安装确认(IQ)

安装确认的目的是保证系统的安装符合设计标准,并保证所需技术资料俱全。

具体确认内容包括:

a标准清单,包括使用者要求、功能性要求、物理要求、系统标准。

b标准操作程序,包括硬件和软件的操作、预防维修、备份和数据存档、灾难(断电、硬软件损坏等)恢复及系统退役。

c计算机系统配置图,配置图是控制系统的概图,包括以下内容:

①整个系统概图。

②各个中央处理器(CPUS)包括插件指定的配置图。

③输入/输出装置接线图。

④控制回路图。

⑤状态转变图。

⑥网络接线图。

⑦硬件驱动/网络驱动指示树,可包括逻辑的和物理的驱动指定。

d硬件和软件手册,包括安装、操作、维护保养手册。

e硬件配置清单,包括已安装系统的所有组成部分,对于芯片、微处理器或EPROM,应记录其修订版号。

f软件清单和源代码的复制件

①列出与系统有关的所有软件和软件版本,并保证所有软件的复制件都归入档案,安全存放。

②应存放以下几种软件。

源代码产生器或编辑器、源代码(包括初级排序、功能和报告的产生)、操作系统、诊断程序、存档/备份程序。

g输入/输出(I/O)清单及连续性检查。

连续性检查是保证信号可从控制系统发至装置并又可从装置返回至控制系统。

h环境和公用工程测试

①确认并记录系统安装的环境,包括清洁度、射频/电磁干扰、振动、物理安全性、噪声、照明。

②记录关键公用工程系统的情况,并确认公用工程系统的关键性质与功能说明书相符。

包括火警通告/抑制、冷却系统、电力及调节、不间断供电、WAN连接、LAN连接、灾难恢复接线、电话数码/模拟。

③确认并记录系统符合安全及人机工程的要求。

i结构测试(白盒法),主要指源代码的结构测试。

对以下各项进行确认。

①遵循模块化程序设计。

②无无效代码。

③按照标准进行识别、修订、注解和评论。

④算法/公式和计算准确。

⑤模块排序准确。

⑥关键上属性、报警等锁存准确。

⑦保持惟一的逻辑输入/输出。

⑧数据贮存寄存器是惟一的。

⑨定时器和定序器设定准确。

j确认整个安装过程符合操作手册要求。

运行确认(OQ)

系统运行确认的目的是保证系统和运作符合需求标准。

系统运行确认应在一个与正常工作环境隔离的测试环境下实施,但应模拟生产环境。

具体包括如下:

a系统安全性测试

①挑战所有逻辑系统,诸如各工作层的使用权限,证明各安全层面的允许权限XX的操作得到禁止。

②确认系统外围的安全性,诸如I/O总线卡,操作人员接口终端等。

b操作人员接口测试,确认操作人员接口系统的功能。

c报警、互锁功能测试。

d数据的采集及存贮,确认系统的数据采集及存贮功能如下:

①准确的采集、贮存和检索数据。

②确认数据的输入长度、进位及空值、零及负值的处理能力。

③自动将数据存档并保存至指定日期。

e确认数据处理能力,包括算法、统计、利用查表数值及报告的产生等。

f定时器和定序器测试。

g功能性测试(黑盒法),根据系统定义中所提供的各种要求文件、标准对系统各功能和各决断通路进行测试。

测试应在最高特定条件下进行。

h断电/修复测试

①复查断电之前、期间和之后的数据采集状况证明数据没有破坏或丢失。

②测试后备供电、不间断供电和动力调节器、发电机功能恢复是否正常。

i灾难恢复测试,制造一起系统失效现象,按照灾难恢复程序一步步确认以下各项。

①现有的数据未被破坏。

②保证对系统的数据备份有效。

j制定系统标准操作程序

运行确认结果合格后,证明系统具备了能够在正式生产环境下使用的条件,可以在正常生产环境下进行进一步确认。

性能确认(PQ)

性能确认(PQ)是为了确认系统运行过程的有效性和稳定性,应在正常生产环境下进行测试。

测试项目依据对系统运行希望达到的整体效果而定(如对生产出的产品质量各项特性进行测试),测试应在正常环境下(相同条件下)重复3次以上。

PQ的实施内容对系统在规定运用条件下运行时,按照事先编写并被批准了的书面说明实行或控制的工程作业能够实行或控制进行确认,即对URS(用户需求标准)进行验证。

对其中所规定的条件(实际生产等的实际运行条件)下运行时的性能进行验证。

进行实际(生产)运行,对系统所持有的运行性能进行验证。

工程公司进行OQ为止的项目,PQ以后为终端客户自行实施,根据系统种类,也有同时进行OQ和PQ的情形。

系统在正式投入使用之前,应对所有相关人员,包括操作人员、维修人员等进行培训,确认其能够按要求正确操作。

当确认所有的验证结果符合预先设定的可接受标准,验证报告已得到相关人员审批并完成人员培训后,计算机系统可被投入正式使用。

系统使用及维护

计算机系统在通过各项测试被使用后,随着时间的推移,某些隐藏的问题会逐渐暴露出来;另外随着环境的变化及新的需求的产生,用户需要对系统进行完善。

因此在此阶段计算机系统应按以下方法实施监控和修改以确保系统始终保持已验证状态并满足用户需求。

该阶段应一直持续到系统引退。

计算机系统在使用过程中所遇到的任何问题及缺陷均应进行记录和报告,以便对其运行效果及变更控制结果进行评价。

计算机系统经过验证后,保持已验证状态。

如果系统发生变更,此种状态将会被破坏。

变更类型包括:

硬件变更、软件变更及数据库中关键参数的变更。

为了维持系统始终处于已验证状态,应对其变更实施控制,具体要求如下。

a使用部门提出书面申请,包括变更理由、依据、内容及实施方案。

b由专业技术人员、相关部门领导及质量保证部门对变更进行评估及审批。

c根据变更影响的范围决定是否应实施再验证。

如变更已导致计算机系统的已验证状态发生偏移(如增加了某些功能等),系统必须针对变更部分实施再验证。

决定实施再验证后,计算机系统将开始生命周期的另一循环。

如经过评估确认不实施再验证,应有充分的依据作支持。

d所有变更必须经过相关人员批准后方可实施,不允许自行改变系统任何部分。

e变更应充分考虑是否对其他相关系统产生影响,需针对其他受影响系统进行评价,必要时会对其他系统实施再验证。

f所有的变更申请、评估、审批及再验证活动均应有文件记录,以使之具有可追踪性。

执行系统管理,确保对计算机系统实施合适的维护,并保持系统数据的完整性。

必须定义控制计算机系统物理及逻辑通道的安全程序,例如必须清楚定义增加或移动用户的安全程序,保证使未授权的或漫不经心的操作得到控制。

安全程序涉及如下范畴。

a系统软件及应用软件安全性。

b硬件安全性。

c建筑安全性。

备份/存档/灾难恢复

必须制定和审批相应文件以控制系统备份计划、恢复程序、存档需求、非定点媒体贮存及出现系统丢失事件时的灾难恢复程序/偶发事件计划。

维护日志应记录所有计划的及非计划的维修活动。

系统维护和变更控制是保证系统在受控及已验证状态卜运行的两大关键。

周期性回顾

系统的变化一般可分为两种。

一种为已知的、有形的变化,这种变化应按照以上所述的变更控制要求执行。

而另一种变化是系统在长期频繁使用中,由于时间的变化、环境的变化、人员的变化、硬件的磨损等诸因素,而导致的一种未知的、无形的变化。

对于这种变化,需要对系统进行周期性回顾(回顾周期为3年),以确保:

a系统运行始终处于已验证状态;

b系统维护严格按相关程序执行;

c系统文件及时而准确地反映了现行计算机系统的运行情况。

如果通过回顾,发现计算机系统的已验证状态已发生偏移,系统必须实施再验证。

系统回顾的范围、方法及结论均应有文件记录,以使之具有可追踪性。

人员培训是一个持续过程,应确保所有使用、维护及开发计算机系统的人员均得到培训。

系统引退

当一个计算机系统的现行功能实施不再适用,或执行一个新系统替代现有系统的功能时,该系统就从实际使用中引退。

此阶段是SDIC的最后一个阶段,其目标是要消除对原系统的依赖并提供一个如何从原系统中取回相关数据的方法。

工程计划(引退系统)

制定一个工程计划以确定引退工作的步骤、鉴别将要替代原有系统的新系统、引退过程的期限及相关责任。

确定原系统数据是否应按照一定的格式存档。

如果原系统被另一个系统替代,存档的数据应该被装载在替代系统中,数据成功转移的确认是新系统验证的一部分。

系统引退时,应通知到所有受影响的用户,并完成以下工作。

a撤销系统特殊的程序。

b切断系统通道。

c整理系统所有逻辑值、符号和菜单参考。

d删除所有软件和工作环境下存档的电子记录。

系统引退报告

统引退报告用于总结整个系统引退工作的实际执行结果,确认是否按要求正确实施引退活动。

验证报告和签发执行《验证管理程序》。

6相关文件

《文件管理程序》XXC-WJ-01(4)

《变更管理程序》XXC-Q-06(6)

《验证管理程序》XXC-YZ-01(4)

7文件颁发部门

企业管理部

8文件分发部门及数量

公司领导各1份复制59份。

9文件变更历史

版本号

生效日期

变更描述

变更人

0

1

2

 

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 解决方案 > 学习计划

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2