GLP机构中使用的计算机化系统必须符合良好实验室规范的要求，为确保实验数据真实、安全、可靠，不但要对计算机化系统验证开展生命周期管理，而且要对系统生命周期活动中涉及的人员的资质、职责和培训提出要求，确保从计算机化系统的概念、需求、设计、开发、发布、操作使用及维护，直至系统退役及存档的所有活动均符合GLP要求。
《药物评价研究》2020年第2期发表了中国食品药品检定研究院国家药物安全评价监测中心霍桂桃等的文章，简要介绍计算机化系统验证生命周期的概念、内容及主要任务，计算机化系统验证生命周期各阶段的需求及特殊的考虑要点。
药物临床前安全性评价研究中使用的计算机化系统必须符合药物非临床研究质量管理规范（good laboratory practice，GLP）的要求。由于计算机化系统具有高效处理数据、操作平台可靠、良好控制人为误差、研究数据实时自动采集、所有更改均可追溯等优势，因此近年来国内GLP机构越来越广泛地采用计算机化系统进行药物非临床研究，确保试验数据真实、完整、可靠。根据经济合作与发展组织（Organization for Economic Co-operation and Development，OECD）的第17号文件及ICH Q9的要求，GLP研究机构应基于风险管理的方法对计算机化系统生命周期的各个环节进行控制，并对生命周期活动中所涉及人员的资质、职责和培训提出要求，还要将计算机化系统验证纳入“生命周期”管理。要确保从计算机化系统的概念、需求、设计、开发、发布、操作使用及维护，直至系统退役的所有活动均符合GLP要求。
目前计算机化系统在我国药物非临床安全评价领域的应用仍局限于部分GLP机构或仅使用计算机化系统部分模块功能，对计算机化系统的生命周期缺乏整体认识，而且我国大部分GLP机构采用市售系统，因此很有必要对计算机化系统验证的生命周期进行全面了解，使计算机化系统的应用和管理更加符合GLP要求。本文主要介绍计算机化系统验证生命周期的概念、内容及主要任务，计算机化系统验证生命周期各阶段的需求及考虑要点，以期为我国非临床安全评价机构的计算机化系统开发、验证提供一定参考，进一步提高计算机化系统的使用效率，确保数据的准确性和可靠性，以加快我国非临床试验机构临床前实验数据的国际认可。
概念、内容及主要任务
计算机系统是指由1台或数台计算机、外围输入/输出设备以及软件构成，其部分或全部程序及运行程序所需的部分或全部数据使用共同的存储设备。计算机系统运行用户编写的或用户指定的程序，并且根据用户指定的模式进行数据分析处理，如逻辑运算或数值运算。计算机系统可以是独立的单机或由几台单机联机组成。计算机化系统是指受控系统、计算机控制系统以及人机接口的组合体系，包括广泛的系统类型，如实验室信息管理系、临床试验数据管理系统等。计算机化系统由硬件、软件、外围设备、可控的功能、操作人员及相关文件资料，如操作手册、标准操作规程（standard operation procedure，SOP）等组成。
OECD认为计算机化系统的验证方法应该是基于风险的，因而测试设施管理可以自由选择任何适当的生命周期模型，验证的方法应该确保从概念、需求、开发、发布、操作使用到系统退役，以系统的方式定义和执行验证活动。生命周期的所有相关阶段都应该被记录和定义，包括系统购买、规格说明、开发和测试、实施、操作和退役。我国原国家食品药品监督管理总局发布的《药品生产质量管理规范（2010年修订）》的两个附录，即《计算机化系统》和《确认与验证》，2015年颁布的第54号文件对计算机化系统的生命周期（the system life circle，SLC）给出明确的术语定义：是指计算机化系统从提出用户需求到终止使用的过程，包括审计、设定标准、编程、测试、安装、运行、维护等阶段。计算机化系统生命周期各阶段及其主要内容和任务见表1。计算机化系统验证的生命周期主要内容包含两个方面：一方面是计算机化系统的项目管理、开发、使用、操作和管理；另一方面是支持计算机化系统开发、使用、操作和管理的流程，主要包括测试/评估/审查绩效管理、供应商资质和管理、配置及变更管理、GLP符合性和质量管理、风险和安全管理、记录管理、问题解决管理、灾难恢复和业务连续性、文档管理。
对于系统生命周期的每个阶段，都要进行讨论并描述所涉及的活动、交付成果以及所需的审查和批准。虽然各阶段是以连续的方式呈现的，但是在整个系统生命周期中，有些阶段可能会重叠，并且可以对每个阶段的一部分（包括流程和可交付的成果）重新审查，特别是在确定更多关于计算机化系统需求和设计相关的信息时。复杂的系统和需求的变化往往需要返回到系统生命周期的早期阶段，并进行进一步完善和修改交付成果。例如，在设计过程中需求的变更可能需要进一步分析以开发替代方法。或者，系统的复杂性可能需要多次迭代的需求和设计，并通过每次修订增加相应的细节层次。应将系统生命周期的交付成果视为动态的而不是静态的。例如，项目计划和系统测试计划的制定可在系统生命周期的早期进行，然后在系统生命周期期间进行完善和修订。质量保证在系统开发生命周期中特别重要，需要生成符合要求并保持数据完整性的质量体系。因此，在系统生命周期的每个阶段都需要特定的验证活动及验证总结，并且要有相应的输入、输出、交付成果或视为等同的交付成果。
计算机化系统验证各阶段的需求及要素
根据计算机化系统的生命周期，系统验证包括验证的启动、需求、设计、开发和编程、系统集成和测试、系统发布、操作和维护、系统退役和归档等阶段，围绕其需求归纳出考虑的要素。
验证的启动
业务需求
计算机化系统验证的启动过程始于确定需要自动化或系统开发支持的业务需求。在此过程中，计划使用该系统的机构提供对拟议项目的全面描述，包括以下4点：
- 高级业务流程；
- 目标和益处；
- 预算和资源估计；
- 预计时限。
通常这些信息都以书面的项目请求形式提供，并且部分可以来自计划和评估。项目一旦批准就可请求正式启动。在计算机化系统验证启动前还需要对系统进行风险等级评估，如市售系统风险发生的种类、技术风险、用户风险、严重程度、法规要求等，分析风险发生的原因以及是否违背GLP原则。另外，对于需要大量资源或在开发或解决方案方面存在高度不确定性的项目需要进行可行性研究。
项目管理和计划
项目管理和计划以文件形式提供，涉及项目管理、质量、验证以及提供充足资源的管理承诺。规划过程贯穿于项目的整个系统生命周期，并应根据要求进行定期审查和引用。计划中的项目管理内容包括：
- 系统的描述及其使用目的；
- 系统生命周期的步骤和不同阶段；
- 角色和责任，包括适当的签名；
- 程序和标准；
- 交付成果清单；
- 工作日程；
- 合规性和风险评估。
风险评估
对系统生命周期进行额外的风险评估以确定事件发生可能对系统运行产生的影响。这些风险包括其他法律和业务关键考虑要点。可以根据已识别风险的影响和后果以及风险发生的可能性来衡量。应该记录任何已识别的风险，并制定缓解策略，包括额外程序控制的任何组合、系统和网络基础设施要求、设计或测试。还要考虑其他关键因素以确定适当的方法，可交付成果和替代开发方法或技术，以确保系统适合其预期目的，例如：购买或建立、规模和复杂性、寿命、布局（单个，多站点或全局）、其他系统集成点或相互依赖关系。
需求
收集需求
项目组通过与“所有者”用户和其他相关组织的讨论来收集需求。如果系统要执行其预定功能，那么使用该系统的个人必须参与定义需求。在需求收集过程中，获得有关提议系统的详细信息。当有开发需求时，现有系统可以用作信息的来源。要对使用中的系统文档进行审查，同时注意手动和自动功能。应收集和分析现有的用户手册、系统文档以及生成的输入和输出示例。系统的需求还包括原始数据定义、信息流和处理功能描述、性能要求、系统可用性要求、安全考虑、错误处理和信息、法规和法律适用性。
需求文件
需求应该以合乎逻辑的方式进行组织并加以唯一标识，以便后续可以通过设计和测试来追溯。需求应该按照任务进行分类，排序或通过流程进度制定。系统需求应由参与过程和管理的人员审查和批准，这将有助于确保需求完整并与用户需求兼容。需求文件应以完整（包括业务、法规、程序、技术、迁移、灾难恢复、备份和恢复、安全性和记录保留）、清楚、可测试、可追溯，并且根据业务需求优先考虑的形式进行编制并提供。
设计
设计是确定系统如何开发的过程，涵盖整个系统和硬件体系结构，包括：
- 基础设施如硬件（服务器、路由器等）、网络和维护方面的注意事项；
- 系统组件，例如应用程序设计及其相对于整个软件环境的位置，包括集成点或对任何系统的依赖性；
- 数据库或数据结构的组织，以及通过整个系统的数据流，包括接口到其他适用的系统。
- 在设计过程中可将需求转化为系统开发团队在构建、测试和维护系统时遵循的详细说明。
设计规范
计算机系统的文档化设计通常被称为设计规范。完整的设计规范应符合以下标准：
- 应作为实现系统需求中描述的实现功能的指令；
- 应作为文件证据证明系统的设计符合系统需求中的描述；
- 应通过使用可追溯矩阵追溯系统需求。设计规范的详细程度应基于系统的复杂性、影响和重要性。建议采用基于风险的方法。
设计规范的要素
计算机系统的设计可以包含在多个文件中，例如高级设计和复杂设计、构建设计、系统设计或技术设计。设计文档描述计算机系统的主要功能，并应描述系统如何分解为其组件和子系统，包括与外部系统和组件的协同操作和通信。设计文档包括以下内容：
- 系统概述；
- 接口和互操作性；
- 外部接口；
- 互操作性；
- 报告设计；
- 数据描述；
- 系统配置；
- 系统安全；
- 性能要求；
- 系统逻辑；
- 系统连续性。
其他考虑
根据计算机系统的复杂性和预期寿命，设计规范可作为未来操作和维护活动的培训材料。设计规范也应该解决对计算机系统设计的局限性或限制和对系统和数据进行错误检测和恢复的方法。设计规范还应记录每个决策的推理过程，以及任何设计目标或优先事项的采纳过程。要确保记录包含重要备选方案的设计决策，以及拒绝这些决定的原因。设计规范要能反映系统运行的当前状态。当修改系统时，应考虑更新过时的设计文档。在设计阶段还应该密切关注需求中所要求的标准，例如监管、业务、财务和法律标准，以及考虑创建或修改测试计划以解决关键的设计组件。建议供应商与用户一起审核设计，以验证用户和监管需求已经说明，以及这些技术将满足他们的需求。例如，用户可以查看涵盖主要功能的体系结构图、数据输入的屏幕布局、正确变量的日期结构、审计追踪、数据输入、审查人员、审计人员和签署人的安全要求等。
开发和编程
在开发和编程期间，系统开发团队根据文档需求和指定的设计来构建系统模块。系统构建包括编码、配置、模块组装以及这些组件的集成。建立或采用的编程标准需确保该程序的未来可维护性和多个开发人员之间的一致性。源代码和配置需要通过已建立的程序进行管理和控制，以确保所有软件组件之间正确的通信关系。还应该进行同行评审以确认代码和配置符合既定标准并且在技术上是正确的。开发人员在迭代的基础上执行测试，直到模块按照其规范执行为止。应特别注意错误和异常的处理。当组件进行子系统或最终组装时，必须执行集成测试以确保组件的兼容性和互操作性。在实施和编程期间，应完成安装、操作、管理和使用的系统文档开发。系统开发活动应该包括建立切换，以便从开发过渡到正式的系统测试。
正式测试、系统集成和测试
开发和编程阶段结束时，在理想情况下系统将被安装到正式的测试环境中。应该对测试环境进行特征描述、定性及文档化，包括配置参数。测试环境应符合预期的生产环境或文档相匹配，并证明其差异。文档应包括系统运行所需的完整软件和硬件组件。应制定程序控制措施以防止测试或测试环境下对软件的意外更改。
正式测试
正式测试包括针对设计（系统、性能、应力）和用户需求（数据输入、用户界面、错误检查）的测试。测试计划应该包括：
- 测试的一般方法和方法学；
- 测试范围和深度的风险告知理由；
- 用于识别、解决和记录测试异常、偏差和差异的说明；
- 测试需求和设计的可追溯性；
- 环境考虑；
- 测试执行文档需求。
正式测试的设计应与应用程序的复杂性、相应的记录风险和业务临界性相适应。应通过使用预先批准的测试脚本或案例进行测试。供应商的测试活动和文档可以帮助测试设施管理部门进行验证，并可以补充或替换测试设施测试。无论测试是由测试机构还是由供应商进行测试，测试设施管理都应保留测试证据，以证明采用了适当的测试方法和测试方案。特别应考虑系统（过程）参数限制，数据限制和错误处理。测试所用例子应该满足以下条件：
- 定义数据设置要求；
- 明确定义并可追溯到适当规范的目标；
- 包括预定义的预期结果和简单明了的验收标准；
- 提供足够详细的指示以确保结果是可重复的；
- 产生客观证据，以便随后进行审查，并独立确认测试通过或未通过的状态。
在正式测试过程中，测试失败应遵循已建立的文档化追踪和解决过程。应该充分记录试验失败的解决方案，以便考虑变更的根本原因和影响，并进行回归分析。还应对测试进行总结，例如出具测试报告，包括通过或未通过测试的测试总结和偏离测试计划。
用户验收测试
用户验收测试（user acceptance testing，UTA）遵循与上述正式测试相同的一般原则，但通常在生产环境或类似生产环境中进行。这不仅包括硬件和软件生产，还包括生产程序、数据和人员。测试设施管理部门还应考虑方法特定的用户验收测试，以证明该系统适合执行特定的GLP研究。
用户将根据预先批准的用户验收测试计划进行测试。在测试环境中，用户验收测试应该基于系统已通过正式测试并且所有记录的特征按预期进行。用户验收测试的目的是建立文档化的证据，证明系统在包括用户数据、用户程序和用户日常问题的用户环境中按照预期运行。参与用户验收测试的人员不仅必须接受正确使用系统的培训，还要接受测试程序的培训，例如，如何进行测试，如何记录测试结果，如何报告异常情况等等。
系统发布
系统发布需确保系统通过文档化和受控机制部署到生产应用中。系统的发布是按照定义和批准的部署方法进行的，其中包括：
- 将系统安装和配置到生产环境中，经过测试和用户验收测试批准；
- 发布总结报告：审查所有交付成果的存在、差异的解决、产品限制的确认和解决、所有团队成员角色的日期；
- 分发和控制系统文档，例如用户文档和管理指南，以便进行操作和维护；
- 编写系统生命周期文档和定义的保留要求；
- 用户培训；
- 更新系统清单；
- 定义存档策略；
- 定义备份策略；
- 业务连续性应急计划；
- 通过用户文档和管理程序移交操作，支持和维护；
- 在适用情况下进行数据迁移和测试数据清理。
操作和维护
系统生命周期不随系统的发布而结束，而是通过控制操作和维护受控过程继续进行，包括：
- 确保遵守系统操作规程；
- 对有和无相应需求变更的系统进行修改（增加、发布、故障修复等）；
- 根据基础设施的变更修改系统（迁移到新的生产环境、升级、补丁等。）
持续监控
在此阶段，支持用户的服务已经到位，包括继续进行用户培训和授权新用户访问。可以定期收集性能指标以提供持续对软件和硬件性能进行持续评估的能力，并确定变化的需求。应遵循已建立的提出需求、事件报告和变更控制机制。
变更控制
相关程序应能够唯一地追踪问题或请求，以便每个问题都可以与系统生命周期升级、版本、补丁程序等联系起来。变更文档支持以可控的质量方式管理系统。对软件或硬件的修改需要进行影响评估，也可能需要启动一个新的软件项目。对于每次修改，应重新考虑系统生命周期以确定影响。变更控制过程对任何系统硬件或软件的修改应包括对任何相关文档的适当修改。
必须制定相关控制措施，以确保所有提出的修改都经过用户和负责支持系统的人员的审批或拒绝。这些控制措施可确保在每次修改或修订时，文档（用户和系统）都准确无误地反映了系统当前的功能和运行。在进行任何修改后，需要进行测试以确定系统的正常运行。
系统退役和归档
计算机化系统的退役包括硬件、软件、数据迁移、数据存档和系统文档存档，并从系统的特定版本或整个计算机系统的退休计划开始。系统退役时，应认真考虑对电子记录保存的监管和其他要求。系统所有者、开发人员和基础设施支持人员负责规划、执行和报告系统或模块的退役。退役计划包括评估和记录所需的任务，还包括归档和检索保留期限的机制。正式退役报告记录了退役流程的成功，并确认支持系统文档的位置。系统退役计划包含的内容：
- 在规定的时间段后停止全部或部分支持；
- 系统、记录和数据的归档；
- 对今后任何剩余支持问题负责；
- 如果适用，转换到新系统；
- 数据存档副本的可访问性和可恢复性。
系统退役计划可以描述并列出文件、原始数据和电子记录的归档方法。即使硬件不可用，也应该可以恢复数据。这些数据应根据相关法规和GLP机构政策的要求保留，以降低风险并实现灾难恢复。要考虑的主要风险是对产品质量和人体健康的影响。在进行风险评估时应考虑以下因素：
- 根据适用的法规确定必须维护哪种电子记录；
- 确定哪些签名适用于受管制的记录；
- 根据产品安全性风险、有效性和质量，以及最终对患者的风险确定电子记录的影响；
- 确定、记录和实施与电子记录影响相对应的控制措施以及确定该记录的风险；
- 根据业务需求和风险评估对确定记录归档和迁移时间表。
存档包括系统生命周期过程中的系统文档以及软件和硬件、数据和元数据以及适用的工具软件，同时及时恢复归档记录是制定归档计划的一个重要考虑因素。在确定归档位置时，对保留期限、计划、系统和数据的临界性以及归档成本的考虑都很重要。其他考虑因素包括环境控制和介质要求。信息可在机构内部或外部进行归档，具体取决于成本、恢复需求、备份和恢复测试的频率影响，包括内部文档归档、独立硬盘驱动器或远程站点服务。
计算机化系统验证的考虑要点
购买系统及责任
系统生命周期中最重要和最常见的变化发生在购买系统时。如果是购买系统，上述基本步骤仍然需要遵循，关键是要明确供应商和购买方的责任（见表2）。供应商应该有详细的需求文档。购买方必须确保这些需求文档所列出的内容能满足他们自己的需求。购买方可以采用供应商列出的需求文档，而不必编写另一个详细的需求文档。当然，如果供应商没有详细的需求文档，那么购买者必须准备需求内容。在计算机化系统的整个生命周期过程中，系统的责任由购买者承担。但是存在依赖一个或多个供应商来交付部分或全部计算机系统的情况。当发生这种情况时，购买者有责任确保选定的供应商以可接受的方式履行其职责或其在系统生命周期的部分职责，即遵循系统生命周期方法，并且系统的基本部分满足预期用户指定的质量、监管和风险组件。
评估供应商
购买方必须评估或审核供应商的业务，要考虑供应商提供或开发定制计算机化系统的能力、系统或具体软件的使用广泛度和认可度、法规符合性情况、软件的开发标准及测试能力、硬件的制造能力、系统的安全性、系统及软件的复杂程度、系统或软件故障的解决能力、供应商的历史、系统软件的版本变化及技术变化情况等，以确保其符合购买方的质量要求。基于供应商、应用程序、软件和其他因素，评估的范围可以从供应商完成问卷调查到在供应商所在地进行广泛的现场访问，并由专业团队对供应商的业务和能力进行深入审查。
任何评估应先行计划，然后实施，进而准备一份描述调查结果的报告。这份报告应该与供应商分享，然后在必要时提出“纠正行动计划”以解决任何存在的不足。如果发现存在不足，购买方可能会重新考虑选用供应商，或者可能需要增加程序来解决存在的缺陷。例如，如果供应商没有进行充分的测试，购买者可能需要在使用该系统之前进行更广泛的测试。也会存在一些其他缺陷，例如购买者无法解决变更控制。
系统生命周期的环境
系统生命周期中可能需要至少3个独立的“环境”，即开发、测试、生产。所有3个环境都需要“控制”。也就是说，安装软件和硬件以及使用每个环境的过程都需要程序。开发环境是系统的编程和构建的地方。如果环境不受控制，当发生问题时，很难判断问题是正在开发的新系统的问题还是环境问题。测试环境可能是设备运行“现场”之前的生产环境。如果已经购买系统，那么测试环境可能存在于供应商处，尽管具有类似的硬件，但它不会反映生产环境的实际情况。生产环境是将系统用于实际研究的地方。这种环境将包含“实时”数据，需要得到良好的控制和记录。可以有多个开发、测试或生产环境。例如，可能有一个测试环境用于测试设备接口和一个用于测试系统用户接口部分的单独环境。
系统测试
测试通常根据测试的环境和目的进行一系列的步骤操作。开发阶段进行的测试，称为调试、单元测试或模块测试，以确保系统或部分系统已“准备好”进行进一步的正式测试。如果开发阶段的测试效果较差，就可能导致大量的时间和精力浪费在正式测试阶段。一旦系统进入正式测试，测试的目标就是演示并记录满足需求，以及系统按照设计工作。
如果“通过”正式测试，系统就会在实际生产环境中与用户的员工、数据、程序和设备进行测试，通常称为用户验收测试。这是正式测试阶段的最后一部分，或可能作为系统发布阶段的一部分。无论作为哪个阶段的一部分，用户验收测试都是必要的，并且需要记录。
计算机系统验证的目标
安装验证的目标是在一定环境下所有设备都能进行正确安装，即所有设备都能按照制造商的规格安装、暖通空调（HVAC）正常工作、用户已经接受过培训，并且所有文件、安全措施和软件都已经正确安装。操作验证的目标是根据需求分析和设计规范能体现并完成系统的所有特点和功能，而且通常在正式测试阶段完成。性能验证的目标是回答“在我的环境、我的设备、我的数据、我的人员、我的程序等环境下系统能否正常工作”的问题，这通常对应于用户验收测试。因此可以将安装验证与上面提到的所有3个环境联系起来。操作验证对应于测试阶段，性能验证将对应于用户验收测试和系统发布阶段。
软件开发工具
很多工具可用于测试软件的开发。如果使用得当，这些工具在效率和质量方面都会非常有帮助。例如：
（1）原型开发和快速应用程序开发（rapid application development，RAD）：最适合用于开发“高级”语言。当用户建议软件更改时，该工具会收集所做的更改，然后在下一个“原型”中执行。如果没有准备好相应的文档（需求、设计、编程标准、测试文档、用户文档），那么系统将无法维护，并且没有明确证据表明系统符合“预期需求”。
（2）测试工具：有许多软件包可以用于练习应用程序软件。在大多数情况下，这些软件包是从脚本运行的，旨在模拟用户在键盘上键入的内容，然后捕获某些“事件”或输出以验证输出是否符合预期。测试过程通常涉及开发脚本和输出的参考集。当使用手动测试时，这就相当于开发测试规范、手动脚本、测试输入、预期输出、通过和失败标准等。当安装该软件的新测试版本时，将自动运行测试脚本并检查结果。通常情况下，并非所有东西都可以自动化。
（3）配置管理工具：术语配置管理（configuration management，CM）是指管理系统生命周期中所有可交付成果的过程。这包括文档、源代码、测试结果等。它通常具有“版本控制”，因此不管文档如何，都可以“退回”到以前的版本。先前的版本源代码、文档以及其他任何内容可存储在CM系统中。对于正在为GLP领域开发软件的公司来说，其中的一个系统可能非常有用。而且，如果实施得当，它将保留几乎所有验证所需的文档。
小结与展望
本文介绍计算机化系统验证生命周期的相关内容旨在为我国药物非临床安全性评价GLP机构的计算机化系统的开发提供指导及建议。笔者针对计算机化系统生命周期的各个阶段分别列出与之相关的文件。所需文件的数量和程度可能随着系统的复杂性、系统的预期用户以及法规的适用性而变化。目前计算机化系统验证主要参照GAMP 4中提出的验证生命周期理论，强调验证过程应当贯穿系统的整个生命周期，在整个验证生命周期中需要系统供应商和系统用户的共同参与，提供相应的系统知识、验证经验以及相关文件与服务，从而有效地完成系统验证。
我国非临床安全性评价研究起步较晚，计算机化系统，尤其是实验室信息管理系统在该领域的应用较晚。我国计算机技术在药物临床前安全评价过程中应用的法规符合性与欧美发达国家相比存在一定的差距。随着我国临床前安全性评价领域的蓬勃发展和计算机技术及信息管理技术的日新月异，计算机化系统在药物研发领域的推广应用将成为必然趋势。要实现整体提升和加强我国非临床安全评价GLP机构对计算机化系统（以及电子数据）的应用和管理，降低计算机化系统带来的质量管理风险，需要监管机构、系统供应商和系统用户共同努力，搭建有效的管理体系，从而对计算机化系统验证生命周期的各个阶段实施有效管理和维护。
延伸阅读
