软件确认通用原则：行业与FDA工作人员指南

General Principles of Software Validation: Guidance for Industry and FDA Staff

发布日期：2002-01-11

状态：Final（最终） 类型：Guidance Document 类别：数字健康与网络安全 主题：Premarket、Digital Health、Good Clinical Practice (GCP) 案卷号：FDA-1997-D-0029

官方来源

https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation PDF：https://www.fda.gov/media/73141/download

INFO

本内容由英文原文机器辅助翻译，并经结构校对。如有歧义，以英文官方文本为准。

官方文件全文

2024年2月2日,FDA在21 CFR 第820部分(89 FR 7496,自2026年2月2日起年2月2日起生效)公布了修订质量管理体系法规的最后规则。经修订的21 CFR Part 820现题为 " 质量管理体系法规 " 。QMSR统一了质量管理体系的要求,以参考方式纳入了ISO为医疗器械质量管理体系制定的国际标准,ISO 13485:2016. FDA确定,ISO 13485中的要求如果全部采用,与质量保证条例的要求基本相似,在企业的质量管理体系中提供类似程度的保证,并有能力始终如一地制造安全和有效的、在其他方面符合FD&C法的器械,《联邦食品、药品和化妆品法》(FD&C法)。 本指南文件是在最后规则生效日期之前印发的。FDA鼓励制造商审查当前的质量和计量及计量标准,以确保遵守相关监管要求。 2025年9月24日,FDA发布了“生产和质量管理体系软件计算机软件保证”指南。“生产和质量管理体系软件的计算机软件保证”指南取代第6节:本指南自动处理器械和质量管理体系软件的验证。" 软件验证一般原则 " 指南的其余部分继续反映FDA目前对这个专题的想法。“生产和质量管理体系软件的计算机软件保证”指南可在此查阅:

软件验证一般原则;工业最后指南和FDA工作人员文件:本文件取代1997年6月9日的 " 软件验证一般原则,第1.1版 " 文件草案。 美国卫生部卫生与公众服务部美国食品药品监督管理局器械和放射卫生中心生物评估和研究中心

二、工业和FDA工作人员软件验证指南一般原则,可随时向文件管理处提出意见和建议,供FDA审议。人力资源管理厅管理系统和政策司、人力资源管理厅、人力资源管理厅、粮食及药品管理局、5630 Fishers Lane,1061室,(HFA-305)、Rockville、MD、Rockville20852. 在提交评论意见时,请参见本指南文件的确切标题。在文件下一次修订或更新之前,FDA不得对评论采取行动。 有关使用或解释本指南涉及器械和辐射健康中心的问题,请与John F.联系。Murray at (301) 594-4659或 jfm@cdrh.fda.gov. 关于使用或解释本指南的问题,涉及生物学评价和研究中心(生物研究中心)与Jerome Davis联系(301) 827-6220或电子邮件davis@cber.fda.gov。 更多副本可在因特网上查阅:www.fda.gov/MedicalDevices/Document ControlandGuidance/GuidanceDocuments/UCM085281.htm。 您也可通过电子邮件向dsmica@fda.hhs.gov发送一份请求书,要求收到指南的电子版本,或向301-847-8149发送传真请求书,要求收到硬拷贝。请使用文件编号(938)来确定您所要求的指导。 可从因特网以下网址获得额外副本: , 向通信、培训和制造商援助(HFM-40),1401 Rockville Pike, Rockville, Rockville, 马里兰州, 20852-1448, 或以1-800-835-5709或301-827-1800的电话请求。

三. 工业和FDA工作人员软件验证指南总则13 第5节十四、5.1. 活动与任务 14二、软件生命周期活动 14 2. 支持验证的典型任务 14 5.2.1质量规划 15 5.2. 2. 质量规划要求 16 5.2.3三、设计... 17 18 5.2.4. 建造或编码 20 5.2.5软件开发商的测试 21 5.2.6用户网站测试 27 5.2.7维修和软件改动...三、评估程序器械和质量管理体系30个 6.1. 需要多少验证证据?用户要求的定义 32 6.3现货软件和自动器械校验33 附录A - 参考文献.... 335 食品和药品管理 参考文献 35 其他政府参考文件36 国际和全国共识标准 3637 生产过程生产过程的 生产过程软件 软件参考资料38 《一般软件质量参考书》。三、附录B - 发展小组 43

工业软件验证指导总则和FDA工作人员软件验证总则它代表了FDA目前对此议题的想法。它不为任何人创造或赋予任何权利,也不赋予任何人任何权利,也不对美国食品药品监督管理局或公众施加约束。如果这种办法符合适用的法规和条例的要求,则可采用另一种办法。 第1节。1. 本指南概述了美国食品药品监督管理局认为适用于医疗器械软件的验证或用于设计软件的验证的一般验证原则,研制或制造医疗器械。本最后指南文件2.0版取代1997年6月9日的 " 软件验证一般原则 " 草案文件,1.1版。 第2节。本指南说明医疗器械质量管理体系法规的某些规定如何适用于软件,以及机构目前对软件验证系统的评价方法。例如,本文件列出了FDA在验证软件方面可接受的内容;但是,它没有列出在所有情况下都必须用于遵守法律的所有活动和任务。 本指南的范围比该术语最严格定义中的审定范围要广一些。配置管理,本指南所讨论的良好软件工程的许多其他方面是重要活动,它们共同帮助支持软件得到验证这一最终结论。 本指南建议整合软件生命周期管理和风险管理活动。根据预定用途和与拟开发的软件相关的安全风险,软件开发商应确定具体方法,所用技术的组合和所要努力的程度。虽然本指南不建议任何具体的生命周期模式或任何具体的技术或方法,它建议在整个软件使用周期内开展软件审定和核查活动。 软件由器械制造商以外的人开发(例如:软件开发商可能不直接负责遵守FDA的条例。

《工业和FDA工作人员软件验证指南通则》需要评估现成软件开发商活动是否充分,并确定还需要作出哪些努力,确定该软件是否为器械制造商的预定用途得到验证。 2.1. 本指南适用于:

• 软件本身是一种医疗器械(例如血源建立软件);
• 生产器械所用的软件(例如制造器械中可编程逻辑控制器);
• 实施器械制造商质量管理体系所使用的软件(例如记录和维护器械历史记录的软件)。 该文件以公认的软件验证原则为基础,因此可适用于任何软件。本指南适用于《联邦食品、药品、药品、该文件没有具体指明哪些软件受到监管或不受监管。 2.2 本指南向下列个人提供有用的信息和建议:
• 负责设计、开发、生产• 负责设计、开发、生产或采购用于设计、开发、开发、制造或采购自动工具的人员;
• FDA科学审查员2.3。最不发达国家办法 我们认为,我们应该考虑在医疗器械监管的所有领域采取最不繁琐的办法。 本指南反映了我们对相关科学和法律要求的认真审查,以及我们认为对你们遵守这些要求最不麻烦的方式。但是,如果你认为替代办法会减轻负担,请与我们联系,以便我们考虑

关于工业和FDA工作人员软件验证指南的一般原则,你的观点是。您可向本指南前言中所列的联系人或CDRH监察员发送书面意见。有关CDRH监察员的全面信息,包括如何与监察员联系,可查阅互联网上的 CDRH 监察员页面：https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-assistance/cdrh-ombudsman 2.4. 国家FDA对1992年至1998年期间进行的3 140个医疗器械的分析显示,其中242个(7.7%)是由于软件故障造成的。在这些与软件有关的回忆中,192(即79%)是由于软件缺陷造成的,软件在最初制作和分发软件后对软件进行修改时出现缺陷。本指南所讨论的软件验证和其他相关的软件工程良好做法是避免这类缺陷和由此产生的回溯的主要手段。 软件验证是质量管理体系法规的一项要求,1996年10月7日公布于联邦登记册,并于1997年6月1日生效。(见《联邦条例法典第21章第820部分第21章第820部分和61《联邦登记册》第52602章)验证要求适用于作为医疗器械组成部分使用的软件,适用于本身即为医疗器械的软件,以及用于生产器械或实施器械制造商质量管理体系的软件。 除非在分类条例中明确豁免,1997年6月1日之后开发的任何医疗器械软件产品,不论其器械类别如何,(见21 CFR §820.30。 )这一要求包括完成目前的发展项目,以及所有新的发展项目,21 CFR §820.30(g)中载有验证器械软件的具体要求。医疗器械软件需要其他设计控制,如规划、输入、核查和审查。(见21 CFR §820.30。 )这些活动的相应记录结果可以进一步证明医疗器械软件得到验证的结论。 按照21 CFR §820.70(i)的要求,任何用于使器械生产过程的任何部分或质量管理体系的任何部分自动化的软件,都必须对其预定用途进行验证。这一要求适用于任何用于器械设计自动化、测试、部件接受、制造、标签、包装、分发、投诉处理的软件。或使质量管理体系任何其他方面自动化。 此外,用于创建、修改和维护电子记录和管理电子签字的计算机系统也需遵守验证要求。 (见21 CFR §11.10(a).) 此类计算机系统必须经过验证,以确保准确性、可靠性、预期的一致性能,以及辨别无效或更改的记录的能力。

工业软件验证指导总则和FDA工作人员软件应用上述应用的软件总则可在内部或合同下制定。然而,软件经常为特定预定用途购买现成的软件。应有文件要求,充分界定其预期用途,以及可以比较测试结果和其他证据的资料,以显示该软件已被验证为预定用途。 在自动化医疗器械以及自动化制造和质量管理体系操作中使用现成软件的情况正在增加。现成软件可能有多种功能,只有其中几种是器械制造商需要的。器械制造商负责其器械中使用的软件是否足够,并用来生产器械。当器械制造商购买“现成”软件时,他们必须确保其按照自己选择的应用方式发挥预期作用。对于制造或质量管理体系中使用的现成软件,本文件第6.3节载有补充指导意见。关于器械软件,可在FDA的《工业指南》、FDA审查员和《医疗器械使用现成软件遵守情况》中找到更多有用的资料。 2.4 质量管理体系监监管度五版初步清单报告它为软件验证过程的管理和控制提供指导。 软件验证过程的管理和控制不应与任何其他验证要求相混淆,例如自动制造过程的流程验证。 器械制造商在遵守质量制度和设计控制要求以及向FDA提交上市前材料时,可使用同样的程序和记录。本文件不涉及与软件验证有关的任何具体安全或效能问题。本文件未述及受监管软件在上市前提交的设计问题和文件要求。上市前提交材料所需文件,应送交器械评价办公室、器械和器械中心。 辐射健康(CDRH)或血液研究和审查办公室、生物评价和研究中心。FDA在上市前提交可适用的指南文件见附录A中的参考。

工业和FDA工作人员软件验证指导总则第3节。许多人要求获得具体指导,说明FDA希望他们做些什么,以确保在软件验证方面遵守质量管理体系法规。本文件提供的软件验证信息并非新资料。20多年来,软件行业许多部门一直使用第4和第5节所列的原则和任务对软件进行验证。 由于医疗器械、工序和制造设施种类繁多,无法在一份文件中说明所有适用的具体的审定要素。然而,可以成功地将几个广泛概念的普遍适用作为软件验证的指导。 这些宽泛的概念为建立软件验证综合办法提供了一个可接受的框架。附录A所列许多参考资料提供了其他具体资料。 3.1. 定义和定义,除非在质量管理体系法规中加以界定,或下文另有规定,本指南中使用的其他所有术语的定义载于FDA《计算机化系统和软件开发术语汇编》本版。 医疗器械质量管理体系法规(21 CFR 820.3(k))将“建立”定义为“销毁、记录和执行”。" 建立 " 和 " 既定 " 等字应当解释为具有同样的含义。 与软件行业常用术语相比,医疗器械质量管理体系法规中的一些定义可能会令人困惑。例如要求、规格、核查和验证。 3.1.1 要求和规格 质量管理体系法规规定,设计投入要求必须记录在案,必须核实具体要求,条例没有进一步澄清“要求”和“规格”两个词之间的区别。 一项要求可以是对系统或其软件的任何需要或期望。要求反映客户的明示或默示需要,可以是市场要求、合同要求或法定要求,也可以是组织的内部要求。可能有多种不同的要求(例如设计、功能、执行、接口、性能或实际要求)。软件要求通常来自系统对分配给软件的系统功能方面的需求。软件要求通常以功能术语表述,并随着发展项目的进展而界定、完善和更新。成功地准确和完整地记录软件要求是成功验证所产生的软件的关键因素。

《工业和FDA工作人员软件验证指导通则》A规格的定义是“一份说明要求的文件”(见21 CFR §820.3(y))。或其他相关文件,通常指明检查是否符合要求的手段和标准。各种书面规格有多种不同的,例如系统要求规格、软件要求规格、软件设计规格、软件设计规格等。软件测试规格、软件集成规格等所有这些文件都确定了“特定要求”,是设计产出,需要各种形式的核查。 质量管理体系法规与ISO 8402:1994统一,该条例将“核查”和“验证”作为单独和独立的术语处理。另一方面,许多软件工程杂志文章和教科书互换使用“核查”和“验证”这两个术语,或在某些情况下提及软件“核实、验证和测试(VV&T)”,视之为单一概念,对三个术语不加区分。 软件核查提供了客观证据,证明软件开发生命周期某一阶段的设计产出符合该阶段的所有具体要求。软件核查力求软件及其辅助文件在开发过程中的一致性、完整性和正确性,并为随后关于验证软件的结论提供支持。软件测试是许多核查活动之一,旨在证实软件开发产出符合其投入要求。其他核查活动包括各种静态和动态分析、代码和文件检查、走动和其他技术。 软件验证是完成器械设计验证的一部分,但在质量管理体系法规中没有单独界定。FDA认为软件验证是“通过检查和提供客观证据确认软件规格符合用户需要和预定用途,通过软件执行的特定要求可以始终如一地得到满足。”软件开发生命周期结束时,确保满足所有要求。验证软件通常包括证据,证明所有软件要求都得到了正确和彻底的实施,并可以追踪到系统要求。软件是否得到验证的结论在很大程度上取决于综合软件测试、检查和分析,在模拟使用环境中测试器械软件功能,用户现场测试通常作为软件自动器械总体设计验证程序的组成部分。 软件的核查和验证很困难,因为开发者无法永远测试,而且很难知道有多少证据足够。在很大程度上,软件验证是发展一种“信任度”问题,使该器械满足软件自动化功能和器械特征的所有要求和用户期望。诸如规格文件中的缺陷、对剩余缺陷的估计、测试范围和其他技术等措施都用于

《工业和FDA工作人员软件验证指导通则》的一般原则在运输产品前培养了可接受的信任度。因此,软件的审定、核查和测试工作需要达到何种程度,视器械自动功能造成的安全风险(危险)而定。关于软件安全风险管理的其他指导见FDA《关于医疗器械中所含软件上市前提交材料内容的指导意见》第4节第4节。在国际标准中,ISO/IEC 14971-1和IEC 60601-1-4在附录A中引用。 3.1.3 IQ/OQ/PQ 多年来,FDA和受监管行业都试图在程序验证术语的范围内理解和界定软件验证。例如,行业文件和其他FDA验证指南有时在安装资格方面描述用户网站软件验证,这些术语的定义和关于IQ/OQ/PQ的补充信息,见FDA关于 1987年5月11日《程序验证一般原则》和FDA1995年8月《计算机化系统和软件开发术语汇编》。 虽然IQ/OQ/PQ术语很好地发挥了作用,而且是组织用户网站软件验证任务的许多合法方法之一,许多软件专业人员对这个术语可能不太了解,本文件其他部分也没有使用。然而,FDA人员和器械制造商在要求和提供关于软件验证的资料时,都需要了解这些术语上的差别。 3.2 使用软件实施系统功能的决定通常是在系统设计期间作出的。软件要求通常来自系统的总体要求和系统内拟使用软件实施的那些方面的设计。成品器械有用户需要和预期用途,但用户通常不具体说明是否要用硬件、软件、软件和软件满足这些要求。因此,必须在系统总体设计验证的范围内考虑软件验证。 文件记载的要求规格代表了用户的需要和开发产品的预期用途。软件验证的首要目标是证明所有已完成的软件产品都符合所有有记录的软件和系统要求。系统要求和软件要求的正确性和完整性应作为器械设计验证过程的一部分加以处理。软件验证包括确认符合所有软件规格,确认所有软件要求都可追溯到系统规格。确认是总体设计验证的一个重要部分,以确保医疗器械的所有方面符合用户需要和预定用途。

工业和FDA工作人员软件验证指南一般原则软件与硬件有许多相同的工程任务,但有一些非常重要的差异。• 软件问题绝大多数可追溯到设计和开发过程中的错误。虽然硬件产品的质量高度依赖设计、开发和制造,软件产品的质量主要取决于设计和开发,对软件制造的考虑最小。软件制造包括可容易核实的复制。制作数千份与原件完全相同的程序副本并不难;难于获得原始程序 符合所有规格

• 软件最重要的特征之一是分门别类,即根据不同的投入执行替代系列命令的能力。这一特征是软件的另一个特征 — — 其复杂性 — — 的一个主要促成因素。 即使是短程序也可能非常复杂且难以完全理解。

• 通常,单靠测试无法充分核实软件是否完整和正确。除了测试之外,其他核查技术和有条理和有文件记录的开发过程应结合起来,以确保采用全面的验证办法。

• 与硬件不同,软件不是一个实体,也不耗竭,事实上,随着年龄的增长,软件可能会随着潜在缺陷的发现和清除而改善。然而,由于软件不断更新和修改,在修改过程中软件中引入的新缺陷有时会抵消这些改进。 软件的分门分支使得软件在执行过程中能够遵循不同的路径,软件产品进入市场之后,可能隐藏一些潜在的缺陷,直到软件产品进入市场很久之后。

• 软件的另一个相关特征是能够迅速和方便地改变软件。 这一因素可促使软件和非软件专业人员相信软件问题可以很容易地纠正。加上对软件缺乏了解,管理人员可能认为软件不需要像硬件那样需要严格控制的工程。事实上,情况恰恰相反。 软件的开发过程由于其复杂性,应该比硬件更严格地加以控制。以便防止在发展过程中稍后难以发现的问题。

• 软件编码的改动似乎微不足道,可能会在软件程序其他地方造成意想不到的非常严重的问题。软件开发过程应有充分的周密规划、控制和记录,以发现和纠正软件变动产生的意外结果。

• 鉴于对软件专业人员和高度流动劳动力的需求很大,对软件进行维护修改的软件人员可能没有参与原始软件开发。因此,准确和透彻的文件至关重要。

• 从历史上看,软件组件没有像硬件组件那样经常标准化和可互换。然而,医疗器械软件开发商已开始使用基于组件的发展工具和技术。面向目标的方法和使用现成软件组件,都有望更快、更便宜地开发软件。然而,在整合过程中,需要非常仔细地注意基于组成部分的办法。在整合之前,需要时间充分界定和开发可重复使用的软件代码,并充分了解现成部件的行为。 由于这些和其他原因,软件工程比硬件工程更需要管理监督和控制。 3.4. 软件验证是用来确保器械软件和软件自动化操作质量的重要工具。软件验证可提高该器械的可用性和可靠性,从而降低故障率,减少召回和纠正行动,对病人和使用者的风险降低,对器械制造商的责任降低。验证软件还可以降低长期成本,使可靠修改软件和重新验证软件变化更加容易,费用也更低。软件维护在软件整个使用周期的总成本中可以占很大比例。 既定的综合软件验证程序有助于减少软件的长期费用,降低软件随后每次发布时的验证费用。 3.5 设计审查是对设计进行记录、全面和系统的审查,以评价设计要求是否充分;评估设计满足这些要求的能力,并查明问题。虽然在软件项目期间,开发小组内部可能进行许多非正式技术审查,正式的设计审查结构更严谨,包括开发小组以外其他机构的参与。正式设计审查可参考其他正式和非正式审查的结果或列入审查结果。在软件与硬件合并后,或两者兼有之后,可对软件进行单独的设计审查。设计审查应包括审查发展计划、要求规格、设计规格、测试计划和程序;与项目有关的所有其他文件和活动、规定生命周期每个阶段的核查结果以及整个器械的核证结果。 设计审查是管理和评价发展项目的主要工具。例如,正式设计审查使管理层能够确认软件验证计划确定的所有目标

工业和FDA工作人员软件验证指南一般原则已经实现。质量管理体系法规要求,在器械设计过程中至少进行一次正式的设计审查。但是,建议进行多次设计审查(例如,在每次软件生命周期活动结束时,为开展下一个活动作准备)。在需求活动结束或接近结束时,在主要资源投入具体设计解决方案之前,正式设计审查尤其重要。此时发现的问题可以更容易地解决,节省时间和金钱,减少一个关键问题消失的可能性。 在正式设计审查期间,应记录对一些关键问题的答复。• 是否为每个软件生命周期活动确定了适当的任务和预期成果、产出或产品?

• 每项软件生命周期活动的任务和预期成果、产出或产品:在正确性、完整性、一致性和准确性方面遵守其他软件生命周期活动的要求? 活动的标准、做法和公约是否得到遵守? 为下一个软件生命周期活动启动任务奠定适当基础?

工业和FDA工作人员软件验证指南总则第4节。本节列出在验证软件时应考虑的一般原则。 4.1 一份有文件证明的软件要求规格为验证和核查提供了一个基准。没有既定的软件要求规格(参考:21 CFR 820.3(z)和(aa)以及820.30(f)和(g)),软件验证程序无法完成。 4.2. 国家软件质量保证需要侧重于防止软件开发过程中引入缺陷,而不是在软件代码写好后试图“测试质量”。 软件测试在显示软件代码中所有潜在缺陷的能力方面非常有限。例如,大多数软件的复杂性使其无法进行详尽无遗的测试,软件测试是一项必要的活动。然而,在大多数情况下,软件测试本身不足以使人相信软件适合其预定用途。为了建立这种信心,软件开发者应当使用混合的方法和技术,以防止软件错误并发现确实发生的软件错误。方法的“最佳组合”取决于许多因素,包括发展环境、应用、项目规模、语言和风险。 4.3. 证明软件得到验证需要时间和精力。软件验证的准备工作应尽早开始,即在设计和发展规划以及设计投入期间。最后结论是,该软件得到验证,应根据从整个软件使用周期中计划开展的工作中收集的证据。 4.4. SOFWARE 寿命 CYCLE 软件验证工作在既定软件生命周期的环境中进行。软件使用周期包括软件工程任务和必要的文件,以支持软件验证工作。此外,软件寿命周期还包括适合软件预定用途的具体核查和验证任务。本指南不建议任何特定的生命周期模式,只是建议选择这些模式,并将其用于软件开发项目。

《工业和FDA工作人员软件验证指南通则》第4.5页。软件验证过程通过使用计划加以界定和控制。软件验证计划界定了通过软件验证努力完成的“什么”工作,软件验证计划是一个重要的质量管理体系工具。软件验证计划具体说明了范围、方法、资源、时间表以及活动、任务和工作项目的类型和范围。 4.6. 软件验证过程通过使用程序进行,这些程序确定进行软件验证工作的“方法”。程序应确定为完成个别审定活动、任务和工作项目而必须采取的具体行动或行动的顺序。 4.7. 由于软件的复杂性,当地似乎很小的变化可能会对全球系统产生重大影响。当软件发生任何变化(即使是小改动)时,软件的验证状况需要重新确立。不仅应为核实单项变动而进行审定分析,此外,还要确定这一变化对整个软件系统的程度和影响。软件开发商随后应进行适当水平的软件回归测试,以表明系统未改变但脆弱的部分没有受到不利影响。设计控制和适当的回归测试使人们相信软件在软件变更后得到验证。 4.8. 估价覆盖核实范围应当以软件的复杂性和安全风险为基础,而不是以公司规模或资源限制为基础。选择审定活动、任务、任务、工作项目应当与软件设计的复杂性和软件用于特定预定用途的风险相称。对于低风险器械,只能进行基线验证活动,因为风险增加,应增加额外的验证活动,以弥补额外风险。审定文件应足以证明所有软件验证计划和程序都已完成。 4.9. 国家应该利用“审查的独立性”的基本质量保证原则开展核查活动。 自我确认极为困难。在可能的情况下,独立评价总是更好,特别是对于高风险申请而言。

工业和FDA工作人员核查和验证软件验证指南一般原则,但这一解决办法并非总是可行的。另一种做法是指派内部工作人员不参与特定设计或其实施,具备足够知识,能够评价项目和开展核查和审定活动。小型公司可能需要在如何安排和分配任务方面具有创造性,以便保持内部审查的独立性。 4.10. 具体执行这些软件验证原则可能与不同的应用有很大不同。器械制造商在选择如何适用这些审定原则方面拥有灵活性,但仍负有证明软件已被验证的最终责任。 软件的设计、开发、验证和规范涉及多种环境,并适用于风险程度不同的各种器械。FDA监管的医疗器械应用包括软件: 医疗器械的组成部分、组成部分或从属; 本身是医疗器械; FDA监管的医疗器械应用包括:

• 用于制造、设计和开发或质量管理体系的其他部分。 在每个环境中,都可以利用多种来源的软件组件创建应用程序(例如内部开发的软件、现成软件、合同软件、软件等)。共享软件))此外,软件组件以多种不同形式出现(例如应用软件、操作系统、汇编者、调试器、配置管理工具以及许多其他工具)。在这些环境中验证软件可能是一项复杂的工作;因此,在设计软件验证过程时,似宜考虑所有这些软件验证原则。由此产生的软件验证程序应与系统、器械或程序的安全风险相称。 软件验证活动和任务可能分散,发生在不同地点,由不同组织进行。不论任务分配、合同关系、组成部分来源或发展环境如何,器械制造商或规格开发商对确保软件得到验证负有最终责任。

工业和FDA工作人员软件验证指导总则第5节。软件验证是通过一系列活动和任务完成的,这些活动和任务是在软件开发生命周期的各个阶段计划和执行的。这些任务可能是一次发生,也可能是多次重复,这取决于所使用的生命周期模型和随着软件项目的进展而发生的变化范围。 5.1. 本指南不建议使用任何具体的软件寿命周期模型。软件开发商应建立一个适合其产品和组织工作的软件生命周期模型。选择的软件寿命周期模式应当涵盖从软件诞生到退休的软件。• 安装

• 操作和支助
• 维护
• 退休核查,在每项活动中都开展测试和其他支持软件验证的任务。生命周期模型以各种方式组织这些软件开发活动,并为监测和控制软件开发项目提供一个框架。若干软件生命周期模型(例如,瀑布、螺旋、快速原型、逐步开发、FDA1995年8月的《计算机化系统和软件开发术语汇编》对(等等)作了界定。附录A所列各种参考文献对这些模型和许多其他生命周期模型作了说明。 5.2. 支持评价的系统技术支持,对于每种软件生命周期活动,都有某些 " 典型 " 任务支持软件被验证的结论。然而,具体任务、其执行顺序、其性能的迭代和时间将由选定的特定软件生命周期模型和与软件应用相关的安全风险决定。对于非常低风险的应用,可能根本不需要某些任务。然而,软件开发者至少应考虑其中每一项任务,并应界定和记录哪些任务适合或不适合

《工业和FDA工作人员软件验证指南一般原则》的具体应用。以下讨论是一般性的,无意规定任何特定的软件寿命周期模式或执行任务的特定顺序。 5.2.1. 质量规划设计和发展规划应最终形成一项计划,确定必要的任务、报告并解决异常现象的程序,管理审查要求,包括正式的设计审查。应确定软件生命周期模型和相关活动,以及每个软件生命周期活动所需的任务。• 列出重要的质量因素(例如可靠性、可维持性和可用性);

• 每项任务的方法和程序;

• 界定和记录产出的标准,以便评价产出是否符合投入要求;每项任务的投入;每项任务的产出;

• 每项任务的作用、资源和责任; 管理层必须确定和提供适当的软件开发环境和资源。(见21 CFR §820.20(b)(1)和(2)。 )一般情况下,每项任务都需要人员和物力资源。该计划应确定每项任务的人员、设施和器械资源,以及风险(危害)管理将发挥的作用。应制定配置管理计划,指导和控制多个平行发展活动,确保适当的通信和文件。有必要进行控制,以确保所有经核准的规格文件、源代码、物体代码、以及所有经核准的规格文件、源代码、物体代码、控制器还应确保准确识别和获取目前核准的版本。 应当建立报告和解决通过审定或其他活动发现的软件异常的程序。管理层应确定报告,并具体说明每份报告的内容、格式和负责的组织要素。审查和批准软件开发结果的程序也必不可少,包括审查和批准软件开发结果的负责组织要素。

• 配置管理计划

• 软件质量保证计划——软件核查和验证计划q核查和验证任务,

• 问题报告和解决程序

• 其他支助活动5.2.2.。所需资源 开发要求包括查明、分析和记录有关器械及其预定用途的资料。特别重要的领域包括将系统功能分配给硬件/软件、操作条件、用户特点、潜在危害和预期任务。 此外,要求应明确说明软件的预定用途。 软件要求规格文件应载有软件功能的书面定义。未经事先确定和有文件记录的软件要求,无法验证软件。• 所有软件系统投入;

• 软件将满足的所有性能要求(例如数据输送量、可靠性和时间);

• 界定所有外部和用户接口以及任何内部软件对系统接口;

• 何谓错误,如何处理错误;

• 软件的预期操作环境,如果这是设计上的制约因素(例如硬件平台、操作系统);

• 软件将接受的所有范围、限制、默认和具体值;

• 将在软件中实施的所有与安全安全有关的要求、规格、特点或功能。 软件安全要求来自与系统要求开发过程紧密结合的技术风险管理程序。软件要求规格应清楚说明系统软件故障可能造成的潜在危害,以及在软件中执行的任何安全要求。应当评估软件故障的后果,以及减轻这类故障的手段(例如硬件减缓、防御性编程等)。从这一分析中,应当能够确定预防损害的最适当的必要措施。

《工业和FDA工作人员软件验证指导通则》 质量管理体系法规要求有一个机制,处理不完整、含混不清、不完全的问题。(见21 CFR 820.30(c).) 每项要求(例如硬件、软件、用户、接线员接口、应评估软件要求规格中指明的准确性、完整性、一致性、可测试性、正确性和清晰度。例如,应评估软件要求,以核实: 内部要求之间没有不一致之处;

• 系统的所有性能要求都已阐明;
• 软件功能的分配准确和完整;软件要求适合于系统危害;
• 所有要求均以可计量或可客观核查的方式表述。 应进行软件要求可追踪性分析,以追踪软件要求与系统要求之间以及从系统要求与风险分析结果之间的距离。除了用于核实软件需求的任何其他分析和文件外,建议进行正式的设计审查,以确认在广泛软件设计工作开始之前,各项要求已完全具体和适当。 要求可以逐步得到批准和释放,但应注意适当审查软件(和硬件)要求之间的相互作用和接口,分析并控制。 典型任务——要求——初步风险分析——可追踪性分析——系统要求的软件要求(反之亦然)——风险分析的软件要求——用户特点说明——用户特征说明——初等和中等记忆特征和限制清单——软件要求评价——软件要求评价——软件用户界面要求分析——系统用户要求分析——系统试验计划产生——接受试验计划产生——结构审查或分析5.2.3。在设计过程中,将软件要求规格转换为将执行的软件的逻辑和实际表述。软件设计规格是说明软件应做什么和如何做。

《工业和FDA工作人员软件验证指南通则》,他们负有不同程度的技术责任,清楚了解设计信息,设计规格可能既包含设计的高层次摘要,又包含详细的设计信息。已完成的软件设计规格要求程序员/编码员不得超出商定的要求和设计的意图。完整的软件设计规格将使程序员不必作出特别设计决定。 软件设计需要处理人的因素。过于复杂或违背用户对业务的直觉期望的设计造成的使用错误是FDA遇到的最持久和关键问题之一。软件的设计往往是造成这种使用错误的一个因素。人因工程工程应贯穿整个设计和开发过程,包括器械设计要求、分析和测试。在制定流程图、状态图、原型工具和测试计划时,应考虑器械安全和可用性问题。此外,还应进行任务和职能分析、风险分析、原型测试和审查以及全面可用性测试。在应用这些方法时,应纳入用户群的参与者。 软件设计规格应包括: 软件要求规格,包括接受软件的预定标准; 软件风险分析;

• 制定程序和编码准则(或其他方案拟订程序);(a) 说明或上下文图表),其中说明程序要运行的系统环境,包括硬件、软件• 需要测量或记录的参数;
• 逻辑结构(包括控制逻辑)和逻辑处理步骤(例如算法);
• 变量(控制和数据)的定义和说明其使用地点;
• 辅助软件(例如操作系统、驾驶员、其他应用软件);
• 通讯联系(软件内部单元之间的联系、与辅助软件的联系、与硬件的联系以及与用户的联系);
• 安全措施(实物安全和逻辑安全);和 上述前四个要素通常为单独的原有文件,在软件设计规格中以参考方式列出。上一节讨论了软件要求规格以及软件风险分析。书面发展程序是该组织的指南,书面方案拟订程序是单个方案制定者的指南。 由于软件在不了解其打算运行的背景的情况下无法验证,因此系统文件被引用。如果软件中不包括上述某些内容,则该软件

《工业和FDA工作人员软件验证指南通则》的一般原则,如果明确说明,可能对软件的未来审查和维护者有帮助(例如,此程序中没有错误消息) 。 软件设计期间开展的活动有多种目的。进行软件设计评价,以确定设计是否完整、正确、一致、明确、可行和可维持。在设计过程中适当考虑软件结构(例如模块结构),可以减少今后在需要软件改动时进行验证工作的规模。软件设计评价可包括对控制流程、数据流、复杂性、时间、规模、记忆分配、临界分析进行分析,应当进行可追踪性分析,以核实软件设计是否满足了所有软件要求。作为一种技术,用以确定哪些地方的要求不够充分,追踪分析还应核实设计的所有方面都可追踪到软件要求。应分析通信联系,以评价硬件、用户和相关软件需求方面的拟议设计。应重新审查软件风险分析,以确定是否查出任何其他危险,以及设计是否引进了任何新的危险。 在软件设计活动结束时,应进行一次正式设计审查,以核实设计正确、一致、完整、准确和可测试,在着手实施设计之前,部分设计可获得批准并逐步释放,以供实施;但应注意适当审查、分析和控制各要素之间的相互作用和交流联系。 大多数软件开发模式将是迭接的。这可能会导致若干版本的软件要求规格和软件设计规格。所有核定版本均应按照既定的配置管理程序存档并控制。 典型任务 - 设计 - 设计 - 更新软件风险分析 更新软件风险分析

• 追踪分析 - 软件要求设计规格(反之亦然)
• 软件设计评价
• 设计通信联系分析
• 设计通信联系分析
• 模块测试计划生成 模块测试计划生成 整合测试计划生成
• 测试设计生成(模块,综合、系统和接受))

5.2.4. 建筑或编码软件可以通过编码(即:或汇集以前编码的软件组件(例如,来自代码图书馆、现成软件等),用于新的应用。编码是软件活动,详细设计规格作为源代码执行。编码是软件开发过程中最低的抽象水平。这是软件要求分解的最后阶段,模块规格被翻译成一种编程语言。 编码通常涉及使用高层次编程语言,但也可能涉及使用组装语言(或微码)进行时间紧迫的业务。源代码可加以汇编或解释,用于目标硬件平台。关于选择程序制作语言和软件建设工具的决定(召集、链接、还应考虑对随后的质量评价工作的影响(例如,为选定的语言提供调试和测试工具)。一些编译者提供可选级别和错误检查命令,以协助调试代码。在整个编码过程中,可以使用不同程度的错误检查方法,汇编者发出的警告或其他信息可能记录,也可能不记录。 然而,在编码和调试过程结束时,通常使用最严格的错误检查水平来记录软件中仍然存在的汇编错误。如果源代码的最后翻译没有使用最严格的错误检查级别,然后应记录使用较不严格的翻译错误检查的理由。汇编过程及其结果的文件,包括来自汇编者的任何警告或其他信息及其解决办法,或理由,说明决定待决问题的理由。 公司经常采用具体的编码准则,制定与软件编码程序有关的质量政策和程序。应当对源代码进行评价,以核实其是否遵守了规定的编码准则。此类准则应包括关于清晰度、风格、复杂程度管理和评论的编码公约。守则评论应为一个模块提供有用和描述性信息,包括预期投入和产出、参考变量、预期数据类型、源码也应加以评价,以核实其符合相应的详细设计规格。准备供整合和测试的单元应备有关于遵守编码准则和任何其他适用的质量政策和程序的文件。 源代码评价通常作为代码检查和代码通过程序进行。这种静态分析提供了一种非常有效的手段,以便在执行守则之前发现错误。这些软件可以单独检查每个错误,也有助于以后集中对软件进行动态测试。公司可使用人工(办公桌)检查和适当的控制,以确保一致性和独立性。源码评价应扩大到核查模块和层(横向和纵向界面)之间的内部联系,并符合其设计规格。 作为设计核查的一部分,应保留所使用程序和源代码评价结果的文件。

源码可追溯性分析是核查所有代码是否与既定规格和既定测试程序挂钩的重要工具。• 软件设计规格的每一项内容都以编码形式执行;

• 在代码中执行的模块和功能可追溯到软件设计规格和风险分析中的一个要素;
• 模块和功能测试可追溯到软件设计规格和风险分析中的一个要素;
• 模块和功能的测试可追溯到相同模块和功能的源代码。 典型任务——建筑或编码——追踪分析——设计规格(和反之)源代码——源代码和设计规格的试验案例——源代码和源代码文件评价——源代码界面分析——源代码 界面分析——测试程序和测试案例生成(模块,综合、系统和接受) 5.2.5。软件开发者的软件测试意味着在已知条件下运行软件产品,并有明确的投入和记录的结果,可与其预先确定的预期相比较。这是一项耗时、困难和不完善的活动,因此,需要及早规划,才能有效、高效。 应在软件开发过程中尽早制定可行测试计划和测试案例。 它们应确定时间表、环境、资源(人员、工具等)、方法、案例(投入、程序、产出、预期成果)、文件、在整个测试过程中要采用的努力的规模可以与复杂性、临界性、可靠性和/或安全问题(例如:要求产生关键结果的功能或模块接受对其缺陷公差特征的密集测试。 )文献中对软件和软件测试工作类别作了描述,例如:使用气候复杂度测量的测试方法; NUREG/CR-6293, 高完整性系统的核查和验证准则;• 电子电子教育学会计算机协会出版社,软件可靠性工程手册。

工业和FDA工作人员软件测试计划软件验证指南一般原则应确定每个开发阶段要执行的具体任务,并包括说明其相应的完成标准所代表的工作量的理由。 软件测试的局限性在规划某一特定软件产品的测试时必须得到承认和考虑。除了最简单的程序之外,软件不能彻底测试。一般来说,用所有可能的投入测试软件产品是不可行的。也不可能测试方案执行期间可能出现的所有可能的数据处理路径。没有任何一种测试或测试方法可以确保某一软件产品经过彻底测试。 测试所有程序功能并不意味着所有程序都已测试。测试一个程序的所有代码并不意味着程序内存在所有必要的功能。测试所有程序功能和所有程序代码并不意味着程序100%正确!没有发现错误的软件测试不应被解释为软件产品中不存在错误;这可能意味着测试是表面的。 软件测试案例的一个基本要素是预期结果,是客观评价实际测试结果的关键细节。这种必要的测试信息是从相应的预先界定的定义或规格中获得的。等,应采用工程(可计量或可客观核实)的详细程度,以便通过测试加以确认。有效软件测试的真正努力在于界定要测试的内容,而不是进行测试。 软件测试过程应基于有助于对软件产品进行有效检查的原则。· 成功的测试是发现错误;

• 使用应用(用户)和软件(方案编制)专门知识;
• 仅审查通常案件是不够的;
• 测试文件允许其再利用,并在随后的审查中独立确认测试结果的出入/失职状况。 一旦完成必要的任务(例如代码检查),即开始软件测试。测试从单位级测试开始,最后进行系统级测试,可能有一个不同的整合测试水平。应根据软件的内部结构测试软件产品,并根据外部规格测试软件产品。这些测试应当对软件产品是否符合其功能、性能和界面定义和要求的情况进行彻底和严格的审查。 基于代码的测试也称为结构测试或“白箱”测试。它根据从源代码获得的知识、详细的设计规格和其他发展文件,确定测试案例。这些测试案例挑战程序作出的控制决定; 程序的数据结构, 包括配置表格。 结构测试可以识别“ 死” 代码 。

《工业和FDA工作人员软件验证指南通则》,在方案实施时从未执行。结构测试主要通过单元(模块)级测试完成,但可以扩大到其他级别的软件测试。 结构测试的水平可以用旨在显示在结构测试期间对软件结构进行了多少百分比评价的量度来衡量。这些衡量标准通常称为“覆盖”,是测试选择标准的完整性衡量标准。结构覆盖率应与软件造成的风险程度相称。 “覆盖”一词的使用通常指100%的覆盖。例如,如果测试方案达到“声明覆盖范围”,这意味着软件100%的对账单至少执行过一次。共同结构覆盖率指标包括: 报表覆盖面 — 这一标准要求每个方案说明至少执行一次,需要有足够的测试案例;然而,它的成就不足以提供对软件产品行为的信心。

• 决定(Branch)覆盖范围 — 这一标准要求每个方案决定或分支的执行要有充分的测试案例,以便每个可能的结果至少发生一次。它被认为是大多数软件产品的最低覆盖率,但单是决策覆盖面不足以满足高完整性应用的需要。
• 条件覆盖范围 — 这一标准要求在方案决定中对每个条件进行充分的测试,以便至少对可能取得的所有结果作一次测试。只有在必须评估多种条件才能作出决定时,它才不同于分支机构的覆盖范围。
• 多条件覆盖范围 — 这一标准要求有足够的测试案例,以在方案决定中运用所有可能的条件组合。
• 环覆盖度 — 这一标准要求所有程序循环的测试案例都足够,即零、一、二和许多关于初始化的迭代,典型的运行和终止(约束性)条件。
• 路径覆盖 — 这一标准要求对每个可行的路径、基础路径等,从确定的方案部分开始到退出,都有足够的测试案例,由于通过软件程序可能走的路径很多,因此路径覆盖通常无法实现。路径覆盖量通常根据测试中的软件的风险或临界度确定。
• 数据流动覆盖率 — 这一标准要求每个可行的数据流动至少进行一次测试,并有足够的测试案例。有若干数据流动测试战略。 基于定义或基于规格的测试也称为功能测试或“黑盒”测试。 它根据软件产品(是单元(模块)还是完整程序)打算做什么的定义,确定了测试案例。这些测试案例对一个程序预定的使用或功能以及程序的内部和外部界面提出了质疑。可在从单位到系统一级各级的软件测试中应用功能测试。

工业和FDA工作人员软件验证指导一般原则• 正常情况——必须用通常的投入进行测试,但是,只用预期的有效投入来测试软件产品并不彻底测试软件产品。正常的个案测试本身不能对软件产品的可靠性提供足够的信心。

• 产出强制——选择测试投入,以确保通过测试产生选定的(或全部)软件产出。
• 强力-软件测试应表明软件产品在出现意外、无效投入时行为正确。确定足够数量的测试案例的方法包括等效类分割、边界价值分析、特别案件识别(误猜)。这些技术虽然重要和必要,但不能确保确定对软件产品的所有最适当的挑战,以供测试。
• 投入的组合 — 首先是确认的功能性测试方法,强调单个或单一的测试投入。大多数软件产品在其使用条件下使用多种投入进行操作。彻底的软件产品测试应考虑软件单位或系统在运行过程中可能遇到的投入的组合。错误猜测可以扩展到识别输入的组合,但它是一种特殊技术。造成结果的图形绘制是一种功能性软件测试技术,它系统地确定软件产品投入的组合,以便纳入测试案例。 功能和结构软件测试案例识别技术为测试提供了具体投入,而不是随机测试投入。这些技术的一个弱点是难以将结构和功能测试完成标准与软件产品的可靠性联系起来。先进的软件测试方法,例如统计测试,可以用来进一步保证软件产品可靠。统计测试使用根据操作剖面图(例如,预期用途、危险用途、危险用途、产生大量测试数据,可以针对特定领域或关注事项,软件产品的设计者或其测试者都没有预见到个别和多种罕见的操作条件,因此更有可能查明这些条件。统计测试还提供高结构覆盖率,确实需要稳定的软件产品。因此,结构和功能测试是软件产品统计测试的先决条件。 软件测试的另一个方面是软件变化的测试,软件开发过程中经常发生变化。这些变化是1个调试的结果,发现错误并被纠正,2个新的或修改的要求(“要求递增”),2个新的或修改的要求(“要求递增”),2个(“要求递增”),2个(“要求递增”)3) 发现执行效果或效率更高或效率更高时修改的设计。一旦对软件产品进行基线(核准),对该产品的任何改变都应有自己的“微型生命周期”,包括测试。对软件产品修改后进行的测试需要额外努力,不仅应证明修改执行得当,测试还应证明该变化不会对软件产品的其他部分造成不利影响。

《工业和FDA工作人员软件验证指南一般原则》保证,软件产品的其他地方没有出现变更。回归分析是根据对有关文件的审查(例如软件要求规格、软件要求规格、软件要求、软件规格、软件要求、软件规格、软件软件设计规格、源代码、测试计划、测试案例、测试脚本等),以便确定要进行的必要回归测试。回归测试是一个程序先前正确执行的测试案例的重新运行,并将当前结果与先前结果进行比较,以便发现软件变更的意外影响。 在使用集成方法构建软件产品时,也应采用回归分析和回归测试,以确保新整合模块不会对先前整合模块的运作产生不利影响。 为了对软件产品进行彻底和严格的审查,开发测试通常按层次进行。例如,软件产品的测试可分为单元、集成和系统测试水平。

1. 单元(模块或组件)级测试侧重于及早检查子方案功能,并确保通过测试检查系统一级无法见的功能。单位测试确保提供高质量的软件单位,以便纳入成品软件产品。
2. 整合水平测试侧重于在方案内部和外部接口之间传输数据和控制。外部接口是与其他软件(包括操作系统软件)、系统硬件和用户的接口,可称为通信链接。
3. 系统级测试表明,所有特定功能都存在,软件产品可信。这一测试核实了在特定操作平台上展示的“自建程序”在软件产品要求方面的功能和性能。 系统一级的软件测试处理功能问题和与预定用途有关的器械软件的下列要素:

• 性能问题(例如反应时间、可靠性测量);
• 内部和外部安全特点的运作;
• 与其他软件产品的兼容性; 应使用控制措施(例如,可追溯性分析)确保达到预期的覆盖范围。 系统级测试还展示了软件产品在预定操作环境中的行为。 这种测试的地点取决于软件开发者是否有能力产生目标操作环境。视具体情况而定,可在(潜在)客户点(潜在)使用模拟和/或测试,试验计划应确定必要的控制措施,以确保

《工业和FDA工作人员软件验证指导通则》的预定覆盖范围已经实现,在 3-5软件开发商未直接控制的场地按计划进行系统级测试时,将编写适当的文件。此外,对于作为医疗器械或医疗器械组成部分的软件产品,在FDA批准之前 Plain用于人体,涉及人体主体的测试可能需要研究用器械豁免或机构审查委员会的批准。 试验程序、试验数据和试验结果应以能够作出客观出入/不合格决定的方式加以 Nagoya记录。试验也应适合在进行测试后进行审查和作出客观决策,并应适合用于随后的任何 Evelyn回归试验。测试中发现的错误应在软件发布前记录、分类、审查和解决。在开发寿命周期内收集和分析的软件错误数据可用于确定软件产品是否适合用于商业分发 Evelyn。试验报告应符合相应的试验计划的要求。 在医疗器械中发挥有用功能的软件产品或其生产往往十分复杂。这些软件产品测试的彻底性和有效性,以及达到计划测试活动要求的效率。 这些工具可包括辅助性的内部软件,以便利单元(模块)测试和随后的集成 Doyle测试(例如:软件测试工具。 此类工具的质量应不低于其用于开发的软件产品。 应保留证明这些软件工具已证实其预定用途的适当文件(见本指南第6 Nagoya节)。 典型任务——软件开发商测试—— Plain测试规划——结构测试案例鉴定——功能测试案例鉴定——可追踪性分析——详细设计测试单元(单元)测试——高级设计综合测试——软件要求系统测试——单元(单元)测试——软件要求系统测试——综合测试执行——功能测试执行——功能测试执行——系统测试执行——系统测试执行——接受试验执行——测试结果评估——错误评价/决议——最后测试报告

5.2.6. 在用户网站进行用户现场测试是软件验证的一个基本部分。《质量管理体系法规》要求安装和检查程序(包括酌情进行测试)以及记录检查 Evelyn测试,以证明安装得当。(见21 CFR §820.170。 )同样,制造器械 3-5必须满足特定要求,自动化系统必须对其预定用途进行验证。(分别见21 CFR §820.70(g)和21 CF Evelyn820.70(i)。 ) 有关用户网站测试的术语可能混淆不清。贝塔测试、场地验证、用户验收测试、安装核查和安装测试等 Evelyn词都用来描述用户现场测试。为本指南的目的, " 用户现场测试 " 一词包括所有这些测试以及在开发者控制 3-5环境之外进行的任何其他测试。这种测试应在用户所在地进行,实际硬件和软件将成为已安装系统配置的一部分。测试是通过实际或模拟地使用正在测试的软件完成的,该软件是在其 Evelyn目的范围内运行的。 本文所载指南是一般性的,适用于任何用户网站测试。然而,在某些领域(如血源建立系统),在规划用户现场测试时可能需要 Plain考虑具体的场地验证问题。测试规划人员应与具有相应产品管辖权的FDA中心进行检查,以确定用户现场 Evelyn检是否有任何额外的监管要求。 用户现场测试应遵循事先确定的书面计划,附有正式的测试摘要和正式接受的记录 Nagoya。应保留所有测试程序、测试输入数据和测试结果的书面证据。 应当有证据表明硬件和软件已按规定安装和配置。 措施应确保在测试期间使用所有系统部件,并确保这些部件的版本是具体指定的 Nagoya。测试计划应具体规定整个操作条件范围内的测试,并应具体规定持续足够时间,使 3-5系统能够遇到各种条件和事件,以发现在较正常的活动中看不出的任何潜在缺陷。 软件开发者早些时候在开发者所在地进行的一些评价应在实际使用地点重复。包括大量数据测试、重载或压力测试、安全测试、故障测试(避免 3-5、检测、容度和回收)、错误信息测试、错误信息测试、误差检测、误差测试、误差检测、误差、误开发商可能能够向用户提供用于此目的一些测试数据集。 除了评价系统适当履行其预期职能的能力之外,应当对系统用户理解和正确与系统接口的能力进行评价。操作员应能够履行预定的功能,并对所有警报、警告和错误信息作出适当 Evelyn及时的反应。

《工业和FDA工作人员软件验证指导通则》应记录适当的系统性能和遇到的任何系统故障。修改系统以弥补在用户网站测试期间发现的故障,应采用与任何其他软件变更 Evelyn相同的程序和控制措施。 软件开发商可能参与或可能不参与用户网站测试。如果开发者参与其中,他们可以无缝地将设计级系统测试的最后一部分转移到 3-5用户网站。如果开发者没有参与其中,更重要的是,使用者必须有了解仔细的试验规划、对预期试验结果的定义的重要性的人 Evelyn。并记录所有测试产出。 典型任务 — 用户现场测试 — 接受试验执行 — 试验 3-5结果评价 — 错误评价/决议 — 最后试验报告5.2.7。关于软件,“维护”一词的含义与硬件并不相同。 硬件和软件的操作维护不同,因为它们的故障/错误机制不同。硬件维护通常包括预防性硬件维护行动、部件更换和纠正改动。软件维护包括矫正、完善和适应性维护,但不包括预防性维护行动或软件 Nagoya部件更换。 为纠正软件错误和错误所作的改动是纠正性维护。为改进软件系统的性能、可维护性或其他属性而对软件所作的改动是完美的维护 Nagoya。为使软件系统在变化的环境中使用而修改软件系统是适应性维护。 当软件系统在初始开发期间或放行后维护期间发生变化时,应进行充分的回归分析和测试,以证明未涉及变更的部分软件没有受到不利影响。除此之外,还进行测试,评估所执行变化的正确性。 每项软件变更所需的具体验证工作取决于变化类型、受影响的开发产品、以及这些产品对软件操作的影响。 仔细和完整地记录各种模块、接口等的设计结构和相互关系,在作出改变时,可以限制所需的审定努力。

《工业和FDA工作人员软件验证指南通则》充分验证一项变动,也取决于 3-5原软件的验证记录和存档的程度。例如,测试文件、测试案例、以前的核查和审定测试结果需要存档,才能用于随后进行回归测试。不将这些信息归档供日后使用,可大大提高软件变更后重新确认软件的精力和 Evelyn资。 除了作为标准软件开发过程一部分的软件核查和验证任务之外,• 软件验证计划修订 — 对于以前审定的软件,应修订现有的软件验证计划,以支持对经修订的软件的验证。如果以前没有软件验证计划,应制定这种计划,以支持对订正软件的验证。 Nagoya

• 异常评价 — 软件组织经常保存文件,例如,软件问题报告描述所发现的软件异常现象和为纠正每个异常现象而采取的具体 Nagoya纠正行动。由于软件开发商没有采取下一步的步骤来确定问题的根源,并作出必要的程序和程序改变以避免问题 3-5重现。软件异常现象应根据其严重程度及其对系统运行和安全的影响进行评估,反常现象的根源分析可以查明具体的系统质量缺陷。查明趋势(例如,类似软件异常现象的复发),必须采取适当的纠正和预防行动并记录在案,以避免类似质量问题再次出现(见21 CF Evelyn820.100。 )
• 问题识别和解决跟踪 — 在软件维护过程中发现的所有问题都应记录在案。 Nagoya应追踪每个问题的解决情况,以确保问题固定下来,历史参考和趋势。
• 拟议的变革评估 — 应评估所有拟议的修改、增强或补充,以确定每项 Evelyn变将对系统产生的影响。这种信息应确定核查和/或审定任务需要迭代的程度。
• 任务迭代 — 对于经核准的软件改动,应履行一切必要的核查和 Evelyn验证任务,以确保计划改动得到正确执行,所有文件都是完整和最新的,软件性能没有发生不可接受的变化。
• 文件更新 — 应仔细审查文件,以确定哪些文件受到变动的影响。所有已核准的已受影响的文件(例如规格、测试程序、用户手册等)应按照配置 Plaind管理程序加以更新。在维修和软件更改之前,应更新规格。

《工业和FDA工作人员软件验证指南通则》第6节。质量管理体系法规要求,“当计算机或自动数据处理系统作为生产或质量管理体系的一部分 3-5时,(见21 CFR §820.70(i))。自1978年以来,这是FDA医疗器械 " 良好制造业做法 " 条例的一项监管 Nagoya要求。 除上述审定要求外,实施器械制造商生产过程或质量管理体系(或用于建立和维持FDA任何其他条例所要求的 Plainc记录)一部分的计算机系统,须接受《电子记录》;电子签名条例。(见21 CFR Part 11)。 该条例规定了在建立或维持电子 Evelyn记录时的额外安全、数据完整性和验证要求。第11部分的这些额外要求应仔细考虑,并列入任何自动记录保存系统的系统 Nagoya要求和软件要求。系统验证和软件验证应证明第11部分的所有要求均已满足。 计算机和自动化器械在医疗器械设计、实验室测试和分析、产品检查和验收 Nagoya等所有各方面广泛使用,生产过程控制、环境控制、包装、标签、可追踪性、文件控制、 3-5投诉管理以及质量制度的许多其他方面。自动化电站楼层操作可越来越多地涉及广泛使用嵌入系统:

• 统计过程控制; 软件工具经常用于设计、建造和测试进入自动医疗器械的软件。许多其他商业软件应用,如文字处理器、电子表格、数据库和流程图软件,都用于实施质量管理体系。所有这些应用都须遵守软件验证要求,但每种应用采用的验证方法可能大不相同。 无论生产或质量管理体系软件是由器械制造商在内部开发、由承包商开发、还是从现货中购买,应利用基本原则来制定该 Nagoya

工业和FDA工作人员软件验证指南一般原则,本指南其他部分概述。器械制造商在确定如何实现该软件的验证方面拥有自由度和灵活性,在决定如何和由谁开发软件或从谁那里购买软件时,验证应当是一个关键考虑因素。软件开发商界定了寿命周期模式,验证通常得到下列因素的支持: 核查软件开发生命周期每个阶段的产出; 核查软件开发生命周期每个阶段的产出; 核查软件开发周期每个阶段的产出。• 检查在器械制造商预定使用环境中完成的软件的适当操作情况。 6.1. 需要多少评价证据? 审定工作的水平应与自动操作的风险相称。 除了有危险的其他因素之外, Nagoya诸如工艺软件的复杂性和器械制造商在多大程度上依赖该自动工艺来生产安全有效的器械,作为审定工作的一部分,确定所需 Nagoya测试的性质和范围。自动化程序的书面要求和风险分析有助于界定证明软件已按预定用途验证的证据范围。例如,如果器械制造商能够证明,随后根据规格对操作的输出进行充分核查,则自动磨机只需进行很少的测试即可释放。另一方面,可能需要对下列系统进行广泛的测试:一个全工厂电子记录和电子签名系统;一个灭菌周期自动控制器;• 用于检查和验收维持生命/维持生命器械中已完工电路板的自动测试器械。 许多商业软件应用可用作质量管理体系的一部分(例如,用于质量管理体系计算的电子表格或统计包,a 用于趋势分析的图表包,或用于记录器械历史记录或用于投诉管理的商业数据库)。这种软件所需的验证证据的程度取决于器械制造商有文件证明的该软件的预期用途。选择不使用软件所有供应商供应能力的器械制造商只需验证这些功能即可,这些功能将作为生产或质量管理体系的一部分使用,而且器械制造商依赖软件结果。然而,高风险应用不应在同一个操作环境中运行,其软件功能未经验证,即使这些软件功能没有使用。当在同一业务环境中使用高风险应用和低风险应用时,可能需要考虑诸如记忆分割或其他资源保护办法等减少风险技术。当软件升级或软件有任何 Nagoya改动时,器械制造商应考虑这些改动如何影响软件的“使用部分”,必须重新确认对所用软件的这些部分的验证。(见21 CFR Nagoya §820.70(i).)

《工业和FDA工作人员软件验证指南一般原则》6.2。软件验证的一个非常重要的关键是,有文件证明的用户要求规格,该规格界定:

• 软件或自动器械的 Nagoya预定用途;
• 器械制造商在多大程度上依赖该软件或器械生产优质医疗器械。 器械制造商(用户)需要界定预期的操作环境,包括所需的硬件和软件配置、软件版本、公用事业等。用户还需要: 系统性能、质量、错误处理、启动、关闭、安全等方面的文件要求;
• 查明与安全有关的任何功能或特征,如传感器、警报器、连接器、逻辑处理步骤或命令序列;
• 确定确定可接受的 Nagoya效绩的客观标准。 审定工作必须按照有文件记录的协议进行,审定结果也必须有文件记录。(见21 CFR §820.70(i).)应记录试验案例,以运用这一系统,对照预先确定的标准质疑其性能,试验个案应处理错误和警报情况、启动、关闭、所有适用的用户功能和操作员控制,可能的操作员错误、允许值的最大和最小范围以及适用于器械预定用途的压力条件。应执行测试个案,并记录和评估结果,以确定结果是否支持软件的预定用途得到验证的结论。 器械制造商可使用自己的人员进行验证,或取决于第三方,如器械/软件供应商或顾问。无论如何,器械制造商仍负有最终责任,确保生产和质量管理体系软件:
• 根据关于特定预定用途的书面程序加以验证;和 器械制造商应有文件,包括: 界定用户要求; 使用鉴定协议; 接受标准; 测试案例和结果; 测试案例和结果; 器械制造商应有文件,包括:
• 界定用户要求;
• 使用鉴定协议;
• 一份鉴定摘要,客观地确认该软件已按预定用途加以验证。

《工业和FDA工作人员软件验证指南通则》6.3。器械制造商使用的多数自动器械和系统由第三方供应商提供,现货购买。器械制造商负责确保OTS软件开发商所使用的产品开发方法对于器械制造商打算使用OTS软件是适当和充分的。就OTS软件和器械而言,器械制造商可能或可能无法获得供应商的软件验证文件。如果供应商能够提供关于其系统要求、软件要求、验证程序及其验证结果的信息,医疗器械制造商可以将这些信息作为所需证明文件的起点。 供应商的生命周期文件,如测试协议和结果、源码、设计规格和要求规格,在确定软件已经验证方面 Nagoya可能有用。然而,商业器械供应商往往无法提供这类文件,或者供应商可能拒绝分享其专利信息。 在可能的情况下,视所涉器械 Nagoya风险而定,器械制造商应考虑审计供应商在建造OTS软件时采用的设计和开发方法,并应评估为OTS软件制作的开发和验证文件。这种审计可由器械制造商或合格的第三方进行。审计应表明,供应商对OTS软件进行的核查和鉴定活动的程序和结果,对于使用该软件生产的医疗器械的安全和有效性要求是适当和充分的。 有些供应商不习惯于在受监管环境中经营,可能没有文件记载的生命周期过程,无法支持器械制造商的验证要求。其他供应商可能不允许审计,但供应商无法提供必要的验证信息,器械制造商将需要进行足够的系统级“黑盒”测试,以确定软件满足其“用户需要和预期用途”。 对于许多应用来说,光是黑盒测试是不够的。视所生产器械的风险、OTS软件在这一过程中的作用、对供应商进行审计的能力以及供应商提供的充足信息而定,使用 OTS 软件或器械可能或可能不合适,特别是如果有合适的替代品可用的话。器械制造商还应考虑如果供应商终止支持,对继续维护和支持OTS软件的影响(如果有的话)。 对于软件汇编者、链接者、编辑和操作系统等一些现成软件开发工具,器械制造商进行详尽无 Nagoya的黑盒试验可能不切实际。 如果不进行这种测试(这是验证工作的一个关键要素),可能无法验证这些软件工具。但是,它们的适当运作可以通过其他手段令人满意地推断出来。商业软件产品可能有“ Nagoyabug list”,供应商提供的系统要求和其他业务信息,可与器械制造商的打算用途作比较,以帮助集中 " 黑箱 " 测试工作。现成的操作系统不必作为一个单独的程序来验证。然而,应用软件的系统级验证测试应涵盖所有使用的操作系统服务,包括最大装载条件、档案操作、软件、软件操作、软件处理系统错误

工业和FDA工作人员条件软件验证指南一般原则,可适用于申请程序预定用途的内存限制。 更详细的信息见附录A中软件的制作和处理参考资料。

《工业和FDA工作人员软件验证指南通则》附录A — 《关于医药器械制造商美国食品药品监督管理局参考设计控制指南的参考文献》,器械和放射健康中心,美国食品药品监督管理局,1997年3月。 1997年3月,根据《医疗器械中人的因素简介设计》,器械和辐射健康中心,美国食品药品监督管理局。 电子记录;电子签名最后规则,62联邦登记册第13430号(1997年3月20日)。 计算机化系统和软件开发术语词汇表,外勤调查司,区域行动厅,监管事务厅,美国食品药品监督管理局,1995 Nagoya8月。 医疗器械所含软件上市前提交材料内容指南、器械评价办公室、器械和放射健康中心、美国食品药品监督管理局, Nagoya1998年5月。 工业、FDA审查者指南和关于医疗器械使用现成软件的遵守情况指南、器械评价办公室、器械和辐射健康中心,美国食品药品监督管理局, Nagoya1999年9月。 1987年5月,《关于程序验证一般原则的准则》,毒品和生物研究中心、器械和辐射健康中心、美国食品药品监督管理局。 医疗器械; 当前良好制造做法(CGMP)最后规则; 质量管理体系法规,61 United States Register 52602(1996年10月7日)。 生物评价和研究中心、美国食品药品监督管理局、生物学评价和研究中心、血源建立计算机软件产品前通知提交指南审查员1997年1月 《学生手册1》,课程INV545,计算机系统验证,人力资源发展司,监管事务厅,美国食品药品监督管理局,1997年。 技术报告、软件开发活动、外勤调查司、区域业务办公室、监管事务办公室、美国食品药品监督管理局、1987年7月。

《工业和FDA工作人员软件验证指南通则》

W. Richards Adrion, Martha A. Branstad, John C. Cherniavsky. NIST特别出版物500-75,

计算机软件验证、核查和测试、方案科学和技术中心、计算机科学和技术研究所美国国家标准局 商业部,1981年2月。 Martha A. Branstad、John C Cherniavsky、W. Richards Adrion、NBS特别出版物500-56《个人程序员的验证、核查和测试》,美国商务部国家标准局计算机科学和技术研究所,科学和技术规划中心,1980年2月。 J.L.Bryant,N.P.Wilburn,《适用于核工业的软件质量保证技术手册》,NUREG/CR-4640,美国核监管委员会,1987年。

H. 《高廉正系统的核查和验证准则》,NUREG/CR-

6293. 1995年,为美国核监管委员会编写。

H. Hecht, et.al.,《核电厂使用软件语言审查准则》

《安全系统》,最后报告,NUREG/CR-6463,为美国核监管委员会编写,1996年。 J.D. Lawrence,W.L.P.,《生产高度可靠软件的工业方法调查》,NUREG/CR-6278,美国核监管委员会,1994年。 J.D. Lawrence, G.G. Preckshot,《安全临界软件的设计因素》,NUREG/CR-6294,美国核监管委员会,1994年。 Patricia B. Powell,编辑. NBS特别出版物500-98,软件验证、核查和测试规划,科学和技术规划中心,美国商务部国家标准局计算机科学和技术研究所,11月 1982. Patricia B. Powell,编辑,《国家边防局特别出版物500-93,软件验证、核查和测试技术及工具参考指南》,美国国家标准局计算机科学与技术研究所科学和技术规划中心。 商业部,1982年9月。 Delores R.Wallace, Roger U. Fujii, NIST特别出版物500-165,软件核查和验证:它在计算机保障方面的作用及其与软件项目管理标准的关系,国家计算机系统实验室,美国商业部国家标准和技术研究所,1995年9月。 德洛丽丝

• 华莱士 劳拉
• 米
• 伊普波利托 迪Richard Kuhn, NIST特别出版物500-204, 高廉正软件、标准和准则,计算机系统实验室,国家研究所

工业和FDA工作人员标准和技术软件验证指南一般原则,美国商务部,1992年9月。 Delores R.Wallace等人,NIST特别出版物500-234,软件核查和验证进程的参考信息。美国商务部国家标准和技术研究所计算机系统实验室,1996年3月。 Delores R.Wallace,编辑,NIST特别出版物500-235,结构测试:使用气候复杂度计量的测试方法。美国商务部国家标准和技术研究所计算机系统实验室,1996年8月。 ANSI/ANS-10.4-1987, ANSI/ANS-10.4-1987, ANSI/ANS-10.4-1987, ANSI/ANS-10.核工业科学和工程计算机方案核查和验证准则,美国国家标准研究所, 1987. ANSI/ASQC标准D1160-1995,正式设计审查,美国质量控制学会,1995年。 ANSI / UL 1998:1998,《可编程部件软件安全标准》,承保人实验室公司,1998年。 AS 3563.1-1991,软件质量管理体系,第一部分:要求,由澳大利亚标准[澳大利亚标准协会]、1新月、Homebush、NSW 2140出版。 AS 3563.2-1991,软件质量管理体系,第二部分:实施指南。 由澳大利亚标准[澳大利亚标准协会]、1新月、Homebush、N SW 2140出版。 IEC 60601--4:1996,医用电气设备,第一部分:安全的一般要求,第4段。 IEC 60601-1-4：可编程医用电气系统,国际电工委员会,1996年。 IEC 61506:1997,工业过程衡量和控制——应用软件文件,国际电工委员会,1997年。 IEC 61508:1998,电气/电子/可编程电子安全相关系统的职能安全,国际电工委员会,1998年。 IEEE Std 1012-1986,软件核查和验证计划,电气和电子工程师研究所,1986年。

工业和FDA工作人员软件验证指南总则IEEE标准收集、软件工程、电气和电子工程师研究所,公司,1994年,ISBN 1-55937-442-X。 ISO 8402:1994,质量管理和质量保证-词汇。国际标准化组织,1994。 ISO 9000-3:1997,质量管理和质量保证标准----第三部分:国际标准化组织,1997年,《应用ISO 9001:1994开发、供应、安装和维护计算机软件的准则》。 ISO 9001:1994, 质量管理体系 - 设计、开发、生产、安装和服务质量保证模式。 ISO 13485:1996,质量管理体系-医疗器械-适用ISO 9001的具体要求。 国际标准化组织,1996年。 ISO/IEC 12119:1994,信息技术-软件包-质量要求和测试,联合技术委员会ISO/IEC JTC 1,国际标准化组织和国际电工委员会,1994年。 ISO/IEC 12207:1995,信息技术-软件生命周期过程,联合技术委员会ISO/IEC JTC 1,Pre-Sub7,国际标准化组织和国际电工委员会,1995年。 ISO/IEC 14598:1999,信息技术-软件产品评价,联合技术委员会ISO/IEC JTC 1,Pre-Sub7,国际标准化组织和国际电工委员会,1999年。 ISO 14971-1:1998,医疗器械 — 风险管理 — 第1部分:应用风险分析。 国际标准化组织,1998年。 航空系统和器械认证中的软件考虑。RTCA/DO-178B,1992年12月。 《GLP原则对计算机化系统的适用》,环境专论第116号,经济合作与发展组织(经合组织),1995年。 乔治

• J
• 格里戈尼斯,爱德华
• J
• Subak, Jr.和Michael Wyrick, " 监管操作中使用计算机系统的主要做法 " ,药物技术,1997年6月。 药物监管、参考材料和

《工业软件验证指导总则》和《FDA为调查员提供工作人员培训辅助工具》,药物质量合规司禁毒办、国家毒品和生物中心、外地调查司和外勤支助副司长1983年2月,区域业务、美国食品药品监督管理局执行主任。 Daniel P.Olivier,“程序验证软件”,FDA调查员课程:医疗器械验证、美国食品药品监督管理局。 GAMMP 《药物制造自动化系统验证指南》V3.0版本,良好自动制造做法论坛,1998年3月:第一卷,第1部分:用户指南第二部分:供应商指南第二卷:用户和供应商的最佳做法。 第18号技术报告,“计算机相关系统的验证”,PDA计算机相关系统验证委员会。《PDA药物科学和技术杂志》,第49卷,第1号,1995年1月至2月补编。 1995年年度,国际验证论坛公司 《一般软件质量参考资料》,鲍里斯·贝泽尔,黑盒测试,软件和系统功能测试技术,John Wiley & Sons,1995年,ISBN 0-471-12094-4。 Boris Beizer,软件系统测试和质量保证,国际汤姆森计算机出版社,1996年,ISBN 1-85032-821-8。 Boris Beizer,软件测试技术,第二版,Van Nostrand Reinhold,1990年,ISBN 0-442-20672-0。 Richard Bender,《书面检验要求》,第1.0版,Bender & Associates Inc.,Larkspur, CA 94777, 1996年。 Frederick P. Brooks, Jr.,《神话人月刊,软件工程论文》,Addison-Wesley Longman,周年版,1995年,ISBN 0-201-83595-9。 Silvana Castano等人,数据库安全,ACM出版社,Addison-Wesley出版公司,1995年。 信号0-201-59375-0。 非临床安全评估、当前概念和质量保证的计算机化数据系统,药物信息协会,1988年9月,巴权力机构,Mample Glen。

工业和FDA工作人员软件验证指南一般原则

M. S. Deutsch,软件核查和验证,现实项目方法,Prentice Hall,

1982. Robert H. Dunn和Richard S. Ullman,《计算机软件TQM》第二版,McGraw-Hill公司,1994年,ISBN 0-07-018314-7。 Elfriede Dustin、Jeff Rashka和John Paul, 自动软件测试 - 介绍、管理和性能, Addison Wesley Longman公司, 1999年, ISBN 0-201-4387-0。 Robert G. Ebenau和Susan H. Strauss,软件检查程序,McGraw-Hill,1994年。 编号0-07-062166-7。 Richard E. Fairley,McGraw-Hill出版公司软件工程概念,1985年。 编号0-07-019902-7。 Michael A. Friedman和Jeffrey M. Voas,《软件评估-可靠性、安全性、可测试性、威利-Interscience》,John Wieley & Sons Inc.,1995年,ISBN 0-471-01009-X。 Tom Gilb, Dorothy Graham, 软件检查,Addison-Wesley出版公司,1993年。 编号0-201-63181-4。 Robert B. Grady, PTR Prentice-Hall公司,《项目管理和工艺改进实用软件计量器》,1992年,ISBN 0-13-720384-5。 Les Hatton,《更安全C:开发高完整性和安全临界系统软件》,McGraw-Hill书公司,1994年,ISBN 0-07-707640-0。 Janis V. Halvorsen,《医疗器械工业软件要求规格文件范本》,1993年第IEEE Semerastcon ' 93号议事录,技术银行,4月4日至7日,1993年,北卡罗来纳州夏洛特 Debra S.Herrmann,软件安全和可靠性:关键工业部门的技术、方法和标准,IEEE计算机学会,1999年,ISBN 0-7695-0299-7。 Bill Hetzel,《软件测试完整指南》,第二版,Wiley-QED出版物,John Wiley & Sons, Inc.,1988年。 ISBN 0-471-56567-9。 Watts S. Humphrey,《软件工程纪律》,Addison-Wesley Longman,1995年。 信号0-201-54610-8。 Watts S. Humphrey,管理软件程序,亚的斯亚贝巴-卫斯理出版公司,1989年。 信号0-201-18095-2。 Capers Jones,软件质量、分析和成功准则,国际汤姆森计算机出版社,1997年,ISBN 1-85032-867-6。

41 《工业和FDA工作人员软件验证指南通则》J.M. Juran,Frank M. Gryna,《质量规划和分析》第三版,McGraw-Hill,1993年。 编号0-07-033183-9。 Stephen H. Kan,《软件质量工程的计量和模型》,Addison-Wesley出版公司,1995年,ISBN 0-201-63339-6。 Cem Kaner, Jack Falk, Hung Quoc Nguyen, 测试计算机软件,第二版,Vsn Nostrand Reinhold, 1993年, ISBN 0-442-01361-2。 Craig Kaplan、Ralph Clark、Victor Tang,IBM软件质量秘密,40项创新,McGraw-Hill,1995年,ISBN 0-07-911795-3。 Edward Kit,《现实世界软件测试》,Addison-Wesley Longman,1995年,ISBN 0-201-87756-2。 Alan Kusinitz, “软件验证”,《医疗器械质量管理体系中的当前问题》,促进医疗仪器协会,1997年,ISBN 1-57020-075-0。 Nancy G. Leveson,安全软件、系统安全和计算机,Addison-Wesley出版公司,1995年,ISBN 0-201-111972-2。 Michael R. Lyu, IEEE计算机协会出版社软件可靠性工程手册编辑,McGraw-Hill, 1996年,ISBN 0-07-039400-8。 Steven R. Marlory,《保健制造业软件开发和质量保证》,Interpharm Press,1994年,ISBN 0-935184-58-9。 Brian Marick,《软件测试工艺》,Prentice Hall PTR,1995年,ISBN 0-13-177411-5。 Steve McConnell,《快速发展》,微软出版社,1996年,ISBN 1-55615-900-5。 Glenford J. Myers,《软件测试艺术》,John Wiley & Sons,1979年。 编号04328-1。 Peter G. Neumann,《计算机相关风险》,ACM出版社/Addison-Wesley出版社,1995年。 信号0-201-55805-X Daniel Olivier,《进行软件审计、符合FDA要求的审计软件》,计算机应用专家,圣地亚哥,加利福尼亚州,1994年。 William Perry,软件测试的有效方法,John Wiley & Sons, Inc. 1995 ISBN 0-471-06097-6。 William E.Perry, Randall W. Rice,Dorset,《软件测试十大挑战的幸存》,Dorset

《工业软件验证指导总则》和《FDA工作人员房屋出版业,1997年,ISBN 0-932633-38-2。 Roger S. Pressman,软件工程,从业者方法,第三版,McGraw-Hill公司,1992年,ISBN 0-07-050814-3。 Roger S. Pressman,McGraw-Hill公司软件工程经理指南,1993 ISBN 0-07-050820-8。

A. P.Sage, J.D.Palmer,软件系统工程,John Wiley & Sons, 1990年。

Joc Sanders, Eugene Curran,软件质量,Addison-Wesley出版社,1994年,ISBN 0-201-63198-9。 KenShumate, Marilyn Keller,软件规格和设计,实时系统纪律方法,John Wiley & Sons,1992年,ISBN 0-471-53296-7。 Dennis D. Smith,《设计可维持的软件》,Springer-Verlag,1999年。 编号0-387-98783-5。 Ian Sommmerville,软件工程,第三版,Addison Wesley出版社,1989年,ISBN 0-201-17568-1。 Karl E. Wiegers,《创建软件工程文化》,多塞特出版社,1996年,ISBN 0-932633-33-1。 Karl E. Wiegers,软件检查,提高软件检查的质量,软件开发,1995年4月,第55-64页。 Karl E. Wiegers,软件要求,微软出版社,1999年,ISBN 0-7356-0631-5。

《工业和FDA工作人员软件验证指南通则》附录B - 发展技术团队器械和放射卫生中心(遵规署)Stewart Crumpler器械评价办公室James Cheng,唐娜

• 比亚
• 蒂尔曼 卫生和工业方案办公室 布赖恩
• 贝内施John Murray 霍华德毒品评价和医学政策研究中心 查尔斯
• 斯尼佩斯生物学评价和研究中心琼
• 洛伦