软件确认的总则

1、软件确认的总则 ；对行业和美国食品药品管理局工作人员的最终指南 ： 本文件发布于： 2002年1月11日本文件代替草案文件 “软件确认的总则， 1.1 版本，注明日期 1997年6月9日设备仪器与放射健康中心美国卫生与公众服务部 食品和药品管理局 设备仪器与放射健康中心 生物制品评价和研究中心目录第一部分 目的第二部分 范围2.1 .适用性 42.2 .观众 52.3 .最不繁重方法 52.4 .软件确认的法规要求 52.4 .质量体系法规对上市前提交 6第三部分软件确认的前后关系 73.1定义和术语 73.1.1 需求和说明 83.1.2验证和确认 83.1.3 IQ / OQ / PQ 9

2、3.2 .软件开发作为系统设计的一部分 93.3 .软件不同于硬件 103.4 .软件确认的益处 113.5设计评审 11第四部分 软件确认的原则124.1 .要求124.2 .缺陷预防124.3 .时间和工作134.4 .软件生存周期134.5 .计划134.6 .规程134.7 .更改之后的软件确认134.8 .确认的覆盖范围144.9 .评审的独立性144.10 灵活性和责任14第五部分活动和任务155.1软件生存周期活动155.2典型任务支持确认155.2.1 质量规划165.2.2 需求175.2.3 设计195.2.4 结构或编码2 15.2.5 由软件开发者测试2 25.2.6用

3、户现场测试285.2.7维护和软件更改30第六部分自动化工艺设备和质量体系软件的确认3 16.1需要多少确认证据？ 336.2确定用户需求336.3成品软件和自动化设备的确认34附录A - 参考文献美国食品和药品管理局参考文献其他政府参考文献国际和国内一致同意的标准生产工艺软件参考文献一般的软件质量参考文献附录B -开发团队软件确认的总则第一部分 目的本指南概述美国食品药品管理局的确认原则，被认为适用于医疗器械软件的确 认，或用于设计、开发或制造医疗器械的软件的确认。 这是最终指南文件， 版本 2.0, 代替草案文件，软件确认的总则，版本 1.1 ，注明日期 1997年6月9日。第二部分 范围

4、本指南描述医疗器械质量体系法规的某种规定如何应用于软件和机构的评价 软件确认体系的当前方法。例如，本文件列出美国食品药品管理局对于软件确认可 接受的要素；然而其没有列出在所有情况下被用于遵守法律的所有活动和任务。本指南的范围比该术语的最严格定义中确认的范围稍宽。 本指南中讨论的优良 软件工程的规划、 验证、测试、可追溯性、 结构管理和许多其它方面是重要的活动， 共同帮助支持软件经确认的最终结论。本指南推荐软件生存周期管理和风险管理活动的整合。 基于和要开发的软件有 关的预期用途和安全性风险， 软件开发者应当确定要使用的特定方法和技术的结合， 与适用的工作级别。虽然本指南并不推荐任何特定的生存周

5、期模式或任何特定技术 或方法，其推荐贯穿整个软件生存周期进行的软件确认和验证活动。当软件是由不同于器械制造商的人开发时 （例如，成品软件） 软件开发商也许 不对符合美国食品药品管理局法规直接负责。在那种情况下， 负有管理责任的用户 （即器械制造商） 需要评定成品软件开发 商的活动的适当性，并确定需要什么附加的工作来建立软件已经为器械制造商的预 期使用确认过。2.1 适用性本指南适用于：* 软件用作医疗器械的组件、部件或附件；* 软件本身是医疗器械（例如血液建立软件）；* 软件用于器械的生产（例如在制造设备中的可编程逻辑控制器）；和* 软件用于执行器械制造商的质量体系（例如记录并维护器械历史记录

6、的软 件）本文件基于通常公认的软件确认原则，因此可适用于任何软件。美国食品药品 管理局的意图，本指南适用于和规定的医疗器械有关的任何软件，如由联邦食品、 药品和化妆品法案的 201章节规定和由当前的美国食品药品管理局软件和法规政策 规定。本文件并不特别识别哪个软件规定了或没有规定。2.2 观众本指南为如下的个人提供有用的信息和推荐： 服从于医疗器械质量体系法规的人员 负责医疗器械软件的设计、开发或生产的人员 负责用于设计、开发或制造医疗器械的自动化工具或用于执行质量体系本身 的软件工具的设计、开发、生产或取得。美国食品药品管理局研究者美国食品药品管理局的符合官员 美国食品药品管理局的科学评审员

7、2.3 最不繁重方法 我们认为我们应当考虑在医疗器械法规的所有范围内的最不繁重方法。本指南 反应我们的对有关科学的和法律需求的仔细评审，我们所认为的是对你符合那些要 求的最不繁重方法。然而，如果你认为一个可供选择的方法将是最不繁重的，请联 系我们，因此我们能考虑你的观点。你可以发送你的书面意见给本指南的前言中列 出的联系人或给设备仪器与放射健康中心的调查官员舞弊情况的政府官员。关于设 备仪器与放射健康中心的调查官员舞弊情况的政府官员的综合性信息，包括联系他 们的方法，见网址 /cdrh/resolvingdisputes/ombudsman.html.2.4

8、软件确认的法规要求美国食品药品管理局的 3140医疗器械的分析在 1992年和 1998年之间实施的召回 揭示其中的 242（7.7%）可归因于软件失效。和召回有关的那些软件， 192（或 79%） 由当对软件最初生产和销售之后做出更改时引入的软件失效引起。本指南中讨论的 软件确认和其它有关的良好软件工程实践是避免这样的缺陷和作为结果而发生的召 回的主要方法。软件确认是质量体系法规的要求， 其在 1996年10月7号的联邦公报中发布， 1997 年6月1日实施。（分别见联邦法规编码（CFR）的标题21的820部分和61联邦公报（FR） 52602。）确认要求适用于用作医疗器械组件的软件， 适用

9、于本身是医疗器械的软件， 适用于在器械的生产中或在器械制造商的质量体系实施中使用的软件。除非在分类法规中特别免除，任何在 1997年6月1号之后开发的医疗器械软件产 品，不管其器械种类，服从适用的设计控制规定。（见 21 CFR 820.30）本要求包括 完成当前的开发项目， 所有新的开发项目， 和所有对现有医疗器械软件做出的更改。 器械软件确认的特定要求见21CFR820.30（g）。其它的设计控制，例如规划、输入、 验证、和评审是对医疗器械软件的要求。（见21CFR820.30来自这些活动的相应的 备有证明文件的结果可提供医疗器械软件经确认的结论的附加支持。任何用于使器械生产过程的任何部分

10、或质量体系的任何部分自动化的软件必须 确认其预期用途，如 21CFR820.70（i ）的要求。本要求适用于使器械设计、测试、 组件验收、制造、标记、包装、销售、投诉处理自动化的任何软件或用于使质量体 系的任何其它方面自动化的任何软件。另外，用于创建、修改和维护电子记录和管理电子签名的计算机系统也服从确 认要求。（见21CFR11.10（ a）这样的计算机系统必须经确认以确保准确度、可靠性、与预期性能一致，辨别无效的或改变了的记录的能力。为上述应用的软件可在内部开发或在合同之内开发。然而，为特定的预期用途 频繁地购买成品软件。 所有的生产和 / 或质量体系软件， 即使购买的成品， 应当具有 完

11、全规定其预期用途和信息的备有证明文件的要求，据此可比较测试结果和其它证 据，显示已经确认软件的预期用途。在自动化的医疗器械和自动化的制造和质量体系运行中，成品软件的使用在增 加。成品软件可以有许多性能，器械制造商仅仅需要其中的少数。器械制造商对用 于他们的器械中和用于生产器械的软件的适当性负责。当器械制造商购买“成品” 时，他们必须确保其如它们选择的应用中所预期的运行。对用于制造或质量体系中 的成品软件， 附加的指南包括在本文件的 6.3部分中。对器械软件， 附加的有用信息 可见于美国食品药品管理局的 行业指南 ，美国食品药品管理局评审员，和符合用于 医疗器械的成品软件。2.4 质量体系法规对

12、上市前提交本文件标明包括实现软件确认的质量体系法规出版物。其为管理和控制软件确 认过程提供指南。软件确认过程的管理和控制不应当和任何其它的确认要求例如对 自动化制造过程的过程确认相混淆。器械制造商可使用同一规程和记录符合质量体系和设计控制要求，以及上市前 提交给美国食品药品管理局。本文件并不覆盖和软件确认有关的任何特定的安全性 或功效问题。规定软件的上市前提交的设计问题和文件编制要求并不由本文件标明。 有关安全性和功效的特定问题，和要求在上市前提交的文件编制，应当向器械评价 办公室（ODE，设备仪器与放射健康中心（CDRH或血液研究与评审办公室，生物 制品评价与研究中心（CBER标明。为上市前

13、提交的可适用的美国食品药品管理局 的指南文件的参考文献见附录 A。第三部分 软件确认的前后关系许多人就美国食品药品管理局期望他们做什么来确保符合有关软件确认的质量体系法规寻求特定的指南。本文件中提出的软件确认信息不是新的。使用第4和第5部分中列出的原则和任务的软件确认，已经在软件行业的许多部分实施了20多年。由于医疗器械、工艺和制造设备的较大变化，不可能在一个文件中指定所有特 定的确认要素是适用的。然而，几个宽泛概念的综合应用可被成功地用作软件确认 指南。这些宽泛的概念为建立软件确认的综合方法提供可接受的框架。附加的特定 信息可从附录A中列出的许多参考文献中获得。3.1 定义和术语 除非在质量

14、体系法规中规定，或相反在下面指定，所有用于本指南的其它术语 都如美国食品药品管理局的 计算机化的系统和软件开发术语的术语表 的当前版本中 所规定。医疗器械质量体系法规（21CFR820.3（ k）规定“建立”意指“规定、形成文件和实施。”在本指南中出现的词“建立”和“已建立”应当被解释成具有同样的 意义。一些见于医疗器械质量体系法规的定义在和通常在软件行业中使用的术语相比 较时可被混淆。示例是要求、规范、验证和确认。3.1.1 需求和规范虽然质量体系法规规定设计输入需求必须备有证明文件，特定的需求必须被验 证，法规并不进一步阐明术语“需求”和“规范”之间的区别。 需求 可以是体系或 其软件的任

15、何需要或预期。需求反映用户的规定的或暗指的需要，也许是基于市场 的、合同的、或法令的，以及组织的内部需求。可以有许多不同种类的需求（例如， 设计、功能、实现、接口、性能或物理需求）。软件需求典型地得自对已经分配给 软件的系统功能性的那些方面的系统需求。软件需求典型地在功能术语中陈述，并 规定、改进和更新为开发项目的进展。在软件需求的准确地和完全地文件编制中的 成功是作为结果的软件的成功确认中的关键因素。规范定义为“指定要求的文件”（见21CFR820.3（y）其可涉及或包括制图、 图形、或其它有关文件，通常指出方法和标准，借此可检查对要求的符合度。有许 多不同种类的书面规范，例如，系统要求规范

16、、软件要求规范、软件设计规范、软 件测试规范、软件集成规范等等。所有这些文件建立“规定的要求”，其设计输出 的不同形式的验证是必要的。3.1.2 验证和确认质量体系法规和ISO8402: 1994协调，其将“验证”和“确认”视为分别的并截 然不同的术语。另一方面，许多软件工程期刊文章和教科书可交换地使用术语“验 证”和“确认”有时候涉及软件“验证、确认和测试（V和T）好像是单一的概念，在这三个术语之间没有区别。软件验证提供软件开发生存周期特定阶段的设计输出满足该阶段的所有特定要 求的客观证据。软件验证寻找软件和其支持文件的一致性、完整性、和正确性。在 其被开发时，为随后的软件已经确认的结论提供

17、支持。软件测试是预期确定软件开 发输出满足其输入要求的许多验证活动之一。其它验证活动包括各种各样的静态和 动态分析，编码和文件检查、走查和其它技术。软件确认是已完成器械的设计确认的一部分，但是没有在质量体系法规中分别 规定。对本指南的用途，美国食品药品管理局考虑软件确认为“通过检查和规定软 件规范符合用户需求和预期使用的客观证据，和特定要求的实现通过软件可被始终 如一地完成来证实。”在实践中，软件确认活动也许发生在这两个过程中，以及在 软件开发生存周期的终端以确保所有的要求已经实现。既然软件通常是大的硬件系 统的一部分，软件确认典型地包括所有软件要求已经正确地和完整地实现并可追溯 到系统要求的

18、证据。软件已经确认的结论高度依赖在软件开发生存周期的每个阶段 完成的综合的软件测试、检查、分析和其它验证任务。在模拟的使用环境中的器械 软件功能性测试和用户现场测试典型地被包括作为软件自动化器械的整体设计确认 程序的组件。软件验证和确认是很难的，因为开发者不能始终测试，很难知道多少证据是足 够的。 在大的测量中， 软件确认是开发 （器械满足软件自动化功能和器械特征的所 有要求和用户预期）的“置信度级别”的问题。例如在规范文件中发现的缺陷，估 计剩余缺陷，测试覆盖范围，和其它技术等措施都用于在产品发货前开发一个可接 受的置信度级别。置信度级别，为此需要的软件确认、验证和测试工作级别将依赖 器械的

19、自动化功能引起的安全性风险（危害）而变化。关于软件的安全性风险管理 的附加指南见美国食品药品管理局的第 4部分 包含在医疗器械中的软件的上市前提 交内容的指南，和国际标准ISO/IEC14971-1和IEC60601-1-4，在附录A中引用。3.1.3 IQ/OQ/PQ多年以来，美国食品药品管理局和管理行业试图在过程确认术语的上下文中理 解和定义软件确认。例如，行业文件和其它的美国食品药品管理局确认指南有时按 照安装鉴定（IQ）、操作鉴定（OQ和性能鉴定（PQ来描述用户现场软件确认。 这些术语的定义和有关IQ/OQ/PC的附加信息见美国食品药品管理局的 过程确认总则 的指南，注明日期1987年

20、5月11日，和美国食品药品管理局的 计算机化的系统和软件 开发术语的术语表。 注明日期1995年8月。当IQ/OQ/PC术语良好地服务其用途，并且是在用户现场组织软件确认任务的许 多合理方法之一。也许在许多软件专业人员中本术语没有被很好地理解，其不用于 本文件中的别处。 然而，美国食品药品管理局人员和器械制造商两者寻找和提供关 于软件确认的信息时需要知道术语中的这些区别。3.2 软件开发作为系统设计的一部分使用软件来实现系统功能性是在系统设计过程中典型地做出的决策之一。软件 要求典型地得自全面系统要求，为系统中的那些方面的设计要使用软件来实现。对 已经完成的器械有用户需要和预期使用，但是用户典

21、型地并不规定那些要求是否由 硬件、软件或两者的一些结组合满足。因此，软件确认必须在体系的全面设计确认 的上下文中考虑。备有证明文件的需求说明代表用户的需要和预期使用，由此来开发产品。软件 确认的首要目标是然后证明所有已经完成的软件产品符合所有备有证明文件的软件 和系统需求。系统需求和软件需求两者的正确性完整性两者应当作为器械的设计确 认过程的一部分来标明。软件确认包括证实对所有软件规范的符合性，证实所有的 软件要求追溯到系统规范。证实是全部设计确认的一个重要部分以确保医疗器械的 所有方面符合用户需要和预期使用。3.3 软件不同于硬件 当软件分担许多和硬件一样的工程任务时，有一些非常重要的区别。

22、例如： 软件问题中的大多数可追溯到在设计和开发过程中形成的错误。 硬件产品 质量高度依靠设计、 开发和制造， 软件产品质量主要依靠对软件制造最小关 注的设计和开发。 软件开发由可容易验证的再现组成。 很难制造数千的功能 和原件完全相同的程序副本；困难来自使得原程序满足所有的规范。 最重要的特征之一是软件分支， 即基于不同输入的执行选择性的操作系列的 能力。该特征对软件的另一个特性其复杂性是一个主要的促成因素。 甚 至简短的程序可以非常复杂很难充分理解。典型地，单独的测试不能充分验证软件已经完成和校正。 除测试之外， 其它 的验证技术和有结构的备有证明文件的开发过程应当组合以确保综合的确 认方法

23、。不同于硬件， 软件不是物理实体不会磨损。 事实上，当潜在的缺陷被发现和 去除时， 软件也许随着寿命而改进。 然而，因为软件经常更新和改变， 这样 的改进有时由在更改期间引入软件的新缺陷来计数。不象一些硬件故障， 软件失效的发生没有高级警报。 软件的分支允许在执行 期间跟随不同的路径，也许隐藏了一些潜在的缺陷直到软件产品被引入到市 场很久之后。软件的另一个有关特征是速度和易于改变。 该因素可导致软件和非软件专业 人员两者相信软件问题可被容易地校正。 和缺乏对软件的理解相结合， 可导 致管理人员相信紧密控制的工程对于软件不象其对于硬件那么需要。实际 上，相反的是真实的。 因为其复杂性， 软件的开

24、发过程应当比硬件更紧密地 控制，为了防止在开发过程中不能容易地稍后找到的问题。 软件编码的表面上不重要的改变会造成软件问题中其它的未预料到的非常 重要的问题。 软件开发过程应当充分地良好计划、 受控和备有证明文件以发 现和校正由软件更改产生的未预料到的结果。 假设对软件专业人员和高度活动的工作人员的高要求， 对软件做出维护更改 的软件人员也许没有包括在原软件的开发中。 因此，准确的和彻底的文件是 必需的。历史上，软件组件不象硬件组件一样频繁地标准化和可互换。 然而，医疗器 械软件开发者开始使用基于组件的开发工具和技术。 目标导向的方法和使用 成品软件组件保证更快和花费较低的软件开发。 然而，基

25、于组件的方法要求 集成期间的仔细关注。 在集成之前， 需要时间来充分地定义并开发可重复使 用的软件编码并充分理解成品组件的性能。由于这些和其它原因，软件工程比硬件工程需要更高级别的管理研究和控制。3.4 软件确认的益处 软件确认是用于确保器械软件质量和软件自动化操作的关键工具。软件确认可 提高器械的适用性和可靠性，导致减少的失效率，较少的召回和校正措施，对患者 和用户的较小风险，减少器械制造商的责任。软件确认也能通过使得可靠地更改软 件和再确认软件更改更容易和成本更低来降低长期成本。软件维护能代表软件在其 整个生存周期的总成本的非常大的百分比。已确定的综合的软件确认过程通过降低 每个软件发布之

26、后的确认成本来帮助降低软件的长期成本。3.5 设计评审 设计评审是设计的备有证明文件的、综合的和系统的检查以评价设计要求的适 当性、评价设计满足这些要求的能力，并识别问题。也许有发生在软件项目期间的 开发团队中的许多非正式的技术评审，正式的设计评审是更结构化的包括参与开发 团队之外的其它评审。正式的设计评审也许参考或包括由其它正式的和非正式的评审的产生的结果。在软件和硬件一起整合到系统中之后，设计评审也许为软件分别进行，或两者。设计评审应当包括检查开发计划、要求规范、设计桂发、测试计划 和规程，所有和项目有关的其它文件和活动，来自确定的生存周期的每个阶段的验 证结果，和对整个器械的确认结果。设

27、计评审是管理和评价开发项目的主要工具。例如，正式的设计评审允许管理 来确定软件确认计划中规定的所有目标已经达到。质量体系法规要求在器械设计过 程中至少进行一个正式的设计评审。然而，推荐进行多个设计评审（例如，在每个 软件生存周期活动的终端，为进行下一个活动作准备）。在主要的资源用于特定的 设计解决方案之前，正式的设计评审在要求活动的终端或附近是特别重要的。可以 更容易地解决在该点发现的问题，节省时间和钱，降低遗漏问题的可能性。一些关键问题的答案应当在正式的设计评审中备有证明文件。这些包括： 已经为每个软件生存周期活动建立适当的任务和预期的结果、 输出、或产品 吗？每个软件生存周期活动的任务和预

28、期结果、输出或产品：V遵从根据正确性、完整性、一致性和准确性的其它软件生存周期活动的要求吗？V 确保活动的规程、实践和惯例吗？V 为下一个软件生存周期活动的启动任务建立适当的基础吗？第四部分 软件确认的原则本部分列出应当为软件确认考虑的总原则。4.1 要求备有证明文件的软件要求规范提供确认和验证两者的基准。没有已经建立的软件要求规范不能完成软件确认过程（参考文献：21CFR820.3（ Z）和（aa）和820.30（ f ）和（ g ） .4.2 缺陷预防 软件质量保证需要集中于防止将缺陷引入到软件开发过程中，不集中于软件编 码写好后试图将“测试质量”引入到软件编码中。软件测试将所有的潜在缺陷

29、形成在软件编码的表面的能力是非常有限的。例如，多数软件的复杂性防止其被彻底地测试。软件测试是一个必要的活动。然而，一般地软件测试本身并不足以建立软件适合于其预期用途的置信度。为了建立该置信度，软件开发者应当使用方法和技术的混合来防止软件错误并检测到确实发生的软件错误。方法的“最佳混合”依靠包 括开发环境、应用、项目大小、语言和风险的许多因素。4.3 时间和工作要建立软件已经确认的情况要求时间和工作。 为软件确认的准备应当及早开始，即在设计和开发规划和设计输出期间。软件已经确认的最终结论应当基于从整个软 件生存周期中进行的有计划的工作来收集的证据。4.4 软件生存周期 软件确认发生在已经建立的软

30、件生存周期环境中。软件生存周期包含软件工程任务和必要的文件以支持软件确认工作。此外，软件生存周期包含适合于软件预期 用途的特定验证和确认任务。 本指南并不推荐任何特定的生存周期模式 - 仅仅推荐应 当为软件开发项目选择和使用的。4.5 计划 通过使用计划来规定和控制软件确认过程。软件确认计划规定通过软件确认工 作完成“什么”。软件确认计划是重要的质量体系工具。软件确认计划规定的领域 例如范围、方法、资源、日程计划，活动、任务和工作项目的类型和内容。4.6 规程通过使用规程来执行软件确认过程。 这些规程制定 “如何”实施软件确认工作。规程应当识别要完成单独的确认活动、任务和工作项目必须采用的特定

31、操作或操作 顺序。4.7 更改之后的软件确认 由于软件的复杂性，表面上较小的局部更改也许对整个系统有重要影响。当对 软件做出更改（即使小的更改），软件的确认状态需要再确定。只要软件更改了， 应当不仅仅对单独的更改确认实施确认分析，而且确定更改对整个软件系统的范围 和影响。基于该分析，软件开发者应当进行适当级别的软件回归测试以显示系统的 未改变的但是易损的部分没有受到负面影响。设计控制和适当的回归测试在软件更 改之后提供软件已经确认的置信度。4.8 确认覆盖范围确认覆盖范围基于软件的复杂性和安全性风险 -不是基于严格的尺寸或限制。 确 认活动、任务和工作项目的选择应当和软件设计以及和软件对特定的

32、预期用途的使 用有关的风险的复杂性相称。对于较低风险的器械，仅仅实施基准确认活动。当风 险增加时，应当增加附加的确认活动以覆盖附加的风险。确认文件编制应当足以证 实所有的软件确认计划和规程已经成功地完成。4.9 评审的独立性确认活动应当使用“评审的独立性”的基本质量保证规则来实施。自我确认是 非常困难的。可能时，独立的评价总是更好的，尤其对于较高的风险应用。一些公 司承包给第三方独立的验证和确认。但是该解决方案也许并不总是切实可行的。另 一个方法是指定没有包括在特定的设计或其实施中，但是具有评价项目和实施验证 和确认活动的充分知识的内部全体职员成员。为了维护评审的内部独立性，较小的 公司也许需

33、要在如何组织和分配任务上具有创造性。4.10 灵活性和责任这些软件确认原则的特定实施的应用之间也许完全不同。器械制造商在选择如 何应用这些确认原则中具有灵活性，但是保留证实软件已经被确认的最终责任。软件在很宽的环境范围中设计、开发、确认和管理，对于较宽种类的器械具有 变化的风险级别。美国食品药品管理局管理的医疗器械应用包括的软件： 是医疗器械的组件、部件或附件其本身是医疗器械；或 用于质量体系的制造、设计和开发或其它部分。在每个环境中，来自许多来源的软件组件也许用于创造应用（例如内部开发的 软件、成品软件、合同软件、共享软件）。此外，软件组件以许多不同的形式出现 （例如应用软件、操作系统、编译

34、程序、调试程序、配置管理工具和许多更多的）。 在这些环境中的软件确认可以是复杂的任务；因此，当设计软件确认过程时考虑所 有这些软件确认原则是适当的。作为结果的软件确认过程应当和有关体系、器械或 过程的安全性风险相称。软件确认活动和任务也许是分散的，发生在不同的位置由不同的组织实施。然 而，不管任务的分布、合同关系、组件来源、或开发环境、器械制造商或规范开发 者保留确保软件已经确认的最终责任。第5部分 活动和任务 软件确认是通过在软件开发生存周期的不同阶段计划和执行的一系列的活动和 任务来完成。依赖使用的生存周期模式和在软件计划进展时做出的更改的范围，这 些任务也许是一次性出现或重复许多次。5.

35、1 软件生存周期活动 本指南不推荐任何特定软件生存周期模式的使用。软件开发者应当建立适合于 他们的产品和组织的软件生存周期模式。所选择的软件生存周期模式应当覆盖软件 从其产生到其收回。典型的软件生存周期模式中的活动包括下列各项：质量规划系统要求定义详细的软件要求规范软件设计规范结构或编码测试安装操作或支持维护收回支持软件确认的验证、测试和其它任务发生在这些活动中的每一个期间。生存 周期模式以不同的方式组织这些软件开发活动，并提供监测和控制软件开发计划的 框架，几个软件生存周期模式在美国食品药品管理局的 计算机化系统和软件开发术 语的术语表 （注明日期 1995年8月）中规定。这些和许多其它的生

36、存周期模式在附录 A中列出的不同的参考文献中描述。5.2 支持确认的典型任务对每个软件生存周期活动，有支持软件已经被确认的结论的确定的“典型”任务。然而，要完成的特定任务，它们的特定顺序和它们的性能的重复和定时将由所选择的特定软件生存周期模式和有关软件应用的安全性风险规定。对于非常低风险的应用，确定的任务也许完全不需要。然而，软件开发者至少应当考虑这些任务中的每一个，并应当对哪个任务适合或不适合于他们的特定应用进行规定和备有证明文件。下面的讨论是一般的，预期不规定任何特定的软件生存周期模式或完成任务 的任何特定顺序。5.2.1 质量规划 设计和开发规划应当在为异常的报告和解决方案识别必要的任务

37、、规程，必要的资源、管理评审要求，包括正式的设计评审的计划中结束。应当识别软件生存周期模式和有关的活动，以及对每个软件生存周期活动必要的那些任务。该计划应当 包括：每个生存周期活动的特定任务；列举重要的质量因素（例如可靠性、可维护性和适用性）； 每个任务的方法和规程；任务的验收准则； 协商规定和记录输出的标准将允许评价它们对输入要求的符合性。每个任务的输入；来自每个任务的输出；每个任务的作用、资源和责任；风险和假定；和用户需要的文件。管理必须识别并提供适当的软件开发环境和资源。（见21CFR820.20（b） （1）和（ 2） ）。典型地，每个任务要求人员以及物理资源。该计划应当为每个任务识

38、别人员、设备和设备资源，和风险（危害）管理发挥的作用。应当制定指导和控制 多个并行的开发活动并确保适当的沟通和文件编制的配置管理计划。控制是确保组 成软件系统的规范文件、资源编码、目标编码和测试序列的所有认可的版本之间的 确实的、正确的对应所必须的。 控制也应当确保正确的识别和访问当前认可的版本。应当为通过确认或其它活动发现的软件异常的报告和解决创造规程。管理应当 识别报告和指定内容、格式和为每个报告负责的组织要素。规程对于评审和认可软 件开发结果（包括为这样的评审和认可负责的组织要素）也是必要的。典型任务-质量规划风险（危害）管理计划配置管理计划软件质量保证计划软件验证和确认计划验证和确认任

39、务和验收准则进程和资源分配（对软件验证和确认活动）报告要求正式的设计评审要求其它的技术评审要求问题报告和解决规程其它的支持活动522要求要求的制定包括关于器械和其预期用途的识别、分析和文件编制。特殊重要性 的领域包括将系统功能分配给硬件/软件，操作条件、用户特性、潜在危害和预期任 务。此外，要求应当清楚地规定软件的预期用途。软件要求说明文件应当包含软件功能的书面定义。没有预定的和备有证明文件 的软件要求要确认软件是不可能的。典型的软件要求规定下列各项：所有的软件系统输入；所有的软件系统输出；软件系统要完成的所有功能；软件要满足的所有性能要求（例如数据通过量、可靠性和定时）；所有外部和用户接口以

40、及所有内部软件和系统接口的定义；用户如何和系统相互作用；什么构成错误，错误应当如何处理；要求的响应次数；软件的预期操作环境，如果这是设计限制因素（例如硬件平台、操作系统）；软件要接受的所有范围、限制、和特定值；和 要在软件中实现的所有和安全性有关的要求、规范、特征和功能。软件安全性要求得自和系统要求开发过程紧密结合的技术风险管理过程。软件 要求规范应当清楚地识别由系统中的软件失效以及要在软件中实现的所有安全性要 求产生的潜在的危害。应当和减轻软件失效的方法（例如硬件减轻，防御性程序设 计，等等）一起评价软件失效的后果。由此分析，识别防止损害所必要的最适当的 措施应当是可能的。质量体系法规要求标

41、明不完整、 不明确或不一致要求的机制。（见21CFR820.30 （c）应当评价在软件要求规范中识别的每个要求（例如硬件、软件、用户、操作 员界面和安全性）的精确性、完整性、相容性、可测性、正确性和明确性。例如， 应当评价软件要求以验证：在要求之间没有内部的不一致；系统的所有性能要求已经清楚地说明；完成并校正故障容许度、安全性和保密性要求；软件功能的分配是正确的完整的；软件要求对系统危害是适当的；和 所有要求用可测量的或客观上能验证的话来表达。应当进行软件要求的可追溯性分析来追溯软件要求到（和从）系统要求和到风 险分析结果。除用于验证软件要求的任何其它分析和文件之外，推荐正式的设计评 审以确定

42、在广泛的软件设计工作开始之前要求被充分地规定并且是适当的。要求可 逐渐增加地批准和发布，但是应当当心软件（和硬件）要求之间的相互作用和接口 被适当地评审、分析和控制。典型任务一要求初步的风险分析可追溯性分析软件要求到系统要求（反之亦然）软件要求到风险分析用户特征的描述主要和次要存储器的特征和限制列表软件要求评价软件用户接口要求分析系统测试计划生成验收测试计划生成模糊评审或分析5.2.3 设计在设计过程中，将软件要求规范转换成软件要实现的逻辑的和物理的表示。软 件设计规范是软件应当做什么和其应当如何做的描述。由于计划的复杂性或使得具 有不同级别的技术责任的人能够清楚地理解设计信息，设计规范可包含

43、设计的高度 概要和详细的设计信息两者。 已完成的软件设计规范限制程序设计师 / 编码员停留在 经过协议的要求和设计的意图内。完整的软件设计规范将减轻程序设计师做出特别 设计决策的需要。软件设计需要标明人员因素。由设计导致的使用错误或者是极度地复杂或者是 和用户对操作直觉预期相反，是美国食品药品管理局遇到的最持久的和关键的问题 之一。软件设计常常是这种使用错误中的一个因素。应当将人机工程学组合在整个 设计和开发过程中，包括器械设计要求、分析和测试。当开发流程图、状态图、样 机工具和测试计划时应当考虑器械安全性和适用性问题。同样，应当完成任务和功 能分析、风险分析、样机测试和评审、完整的适用性测试

44、。当应用这些方法时应当 包括来自用户总体的参与者。软件设计规范应当包括：软件要求规范，包括软件的预定验收标准；软件风险分析；开发规程和编码指南（或其它的程序设计规程）； 描述系统的前后关系的系统文件编制 （例如叙述性的或上下文图表） 中的程 序预期操作，包括硬件、软件和物理环境的关系。要使用的硬件；要测定或记录的参数； 逻辑结构（包括控制逻辑）和逻辑上的数据处理步骤（例如算法）； 数据结构和数据流程图； 变量（控制和数据）的定义和定义用于哪里的描述； 错误、报警和报警信息； 支持软件（例如操作系统、驱动程序、其它的应用软件）； 通信联络链接 （软件的内部模块之间的链接、 和支持软件的链接、 和

45、硬件的 链接、和用户的链接）； 保密性措施（物理和逻辑保密性两者）；和 没有在上述要素中识别的任何附加限制；上面指出的要素中的前 4个通常是包括在软件设计规范中的参考文献中的单独 的现有之前的文件。在前述章节中讨论的软件要求规范被看作软件风险分析。书面 的开发规程用作组织的指南，书面的程序设计规程用作个体的程序设计师的指南。 当没有软件在其中预期操作的上下文的知识软件不能被确认时，参考系统的文件编 制。如果上述要素中的某些没有包括在软件中，如果清楚地表明也许对软件将来的 评审者和维护者有帮助，（例如在该程序中没有错误信息）。在软件设计期间发生的活动有几个目的。进行软件设计评价以确定设计是否完

46、整、正确、一致、明确、可行和可维护。当需要软件更改时，设计期间软件体系结 构（例如模块结构）的适当考虑可降低将来的确认工作数量。软件设计评价也许包 括控制流、数据流、复杂性、定时、容量估计、存储器分配、关键程度分析和设计 的许多其它方面的分析。应当进行可追溯性分析来验证软件设计实现了所有的软件 要求。作为识别要求在哪里不充分的技术，可追溯性分析也应当验证设计的所有方 面都可追溯到软件要求。应当进行通讯联络链接的分析来就硬件、用户和有关的软 件要求评价提议的设计。应当再检查软件风险分析以确定所有附加的危害是否已经 被识别，所有新的危害是否已经由设计引入。在软件设计活动结束时，在移动到实现设计之前

47、应当进行正式的设计评审来验 证设计是正确的、一致的、完整的、精确的、可试验的。设计的几个部分为实现可 逐渐增加地批准和发布；但是应当当心在不同要素之间的相互作用和通讯联络链接被适当地评审、分析和控制大多数软件开发模块是重复的。这很可能导致软件要求规范和软件设计规范两 者的几个版本。应当按照已建立的配置管理规程获得和控制所有经批准的版本。 典型任务一设计更新的软件风险分析可追溯性分析一软件要求设计规范（反之亦然）软件设计评价设计通讯联络链接分析模块测试计划生成集成测试计划生成测试设计生成（模块、集成、系统和接收）524构造或编码软件或者由编码（即程序设计）或者由以前编码的软件组件（例如来自编码库

48、、 成品软件等）组合在一起构成用于新的应用。在详细的设计规范作为源编码实现的 地方编码是软件活动。编码是软件开发过程的最低级别的抽象。在模块规范被转换 成程序设计语言的地方，编码是分解软件要求的最后阶段。编码通常包括高级程序设计语言的使用，但是对于临界时间的操作也许需要使 用汇编语言（或微编码）。为用于目标硬件平台该源编码可以或者是编译的或者是 翻译的。选择程序设计语言和软件编译工具（汇编程序、链接程序和编译程序）的 决策应当包括对随后的质量评价任务（例如所选择的语言的调试和测试工具的可用 性）的影响的考虑。一些编译程序为错误检查提供可选择的级别和指令来帮助调试 编码。不同的错误检查级别也许在

49、整个编码过程中使用，来自编译程序的警报或其 它信息也许记录也许没有记录。然而，在编码和调试过程结束时，错误检查的最严 格级别通常用于对什么编码错误仍留在软件中备有证明文件。如果错误检查的最严 格级别不用于源编码的最终译码，那么使用较少严格的译码错误检查的正当理由应 当备有证明文件。同样，对最终编码，应当有编码过程和其输出的文件编制，包括 来自编译程序和它们的分辨率的任何警报或其它信息，或留下未解决问题的决策的 正当理由。管理系统的预报信息检索频繁地采用建立了有关软件编码过程的质量规则和规 程的特定编码指南。应当评价源编码以验证其符合特定的编码指南。这种指南应当 包括关于明确性、形式、复杂性管理

50、和注释的编码约定。编码注释应当提供模块的 有用的和描述性的信息，包括预期输入和输出、变量参考、预期数据类型和要完成 的操作。也应当评价源编码以验证其符合相应的详细设计规范。准备集成和测试的 模块应当有符合编码指南和任何其它适用的质量规则和规程的文件编制。源编码评价常常作为编码检查和编码走查来执行。这种静态分析提供运行编码 指之前检出错误的非常有效的方法。它们允许隔离中的每个错误的检查，并也能帮 助聚焦于稍后的软件动态测试。管理系统的预报信息检索可以使用具有适当的控制 机构的手动（工作台）检查以确保一致性和独立性。应当扩充源编码评价来验证模 块和层（水平的和垂直的界面）之间的内部连接，和符合它们

51、的设计规范。使用的 规程和源编码评价结果的文件编制应当作为设计验证的一部分来维护。源编码可追溯性分析是验证所有的编码链接到已经制定的规范和已经制定的测 试规程的重要工具。源编码的可追溯性分析应当实施并备有证明文件以验证：软件设计规范的每个要素已经在编码中实现；在编码中实现的模块和功能可追溯到软件设计规范和风险分析中的要素； 模块和功能的测试可追溯到软件设计规范和风险分析中的要素；和 模块和功能测试可追溯到同一模块和功能的源编码。典型任务一结构或编码可追溯性分析源编码到设计规范（反之亦然）测试案例到源编码和设计规范源编码和源编码文件编制的评价源编码界面分析测试程序和测试案例生成（模块、集成、系统

52、和接收）525软件开发者的测试软件测试需要在已知的条件下（能够和软件的预定义的预期相比较的规定的输 入和备有证明文件的输出）运行软件产品。这是耗时的、困难的、不完善的活动 同样地，要求及早规划以便有效果和效率。测试计划和测试案例应当在软件开发过程中合理可行的及早形成。 它们应当识 别进度表、环境、资源（人员、工具等）、方法、案例（输入、规程、输出、预期 结果）、文件编制和报告标准。 在整个测试过程中应用的工作数量可链接到复杂性、 关键程度、可靠性、和/ 或安全性问题（例如要求产生关键输出的功能或模块经受它 们的容错特征的强化测试） 。软件种类的描述和文献中出现的软件测试工作， 例如：NIST

53、（美国国家标准技术研究所）特殊出版物 500-235，结构测试：使用秩 复杂性度量的测试方法。NUREG/CR-62高完整性系统的验证和确认指南；和IEEE （电气和电子工程师协会）计算机协会出版社，软件可靠性工程手册。软件测试计划应当识别在开发的每个阶段进行的特定任务，包括由其相应的完 成标准代表的工作级别的正当理由。当规划特定软件产品的测试时，软件测试有必须被认识到和考虑的限制。除最 简单的程序以外，软件不能被彻底的测试。通常用所有可能的输入测试软件产品是 不可行的，测试在程序执行期间会发生的所有可能的数据处理路径也是不可能的。 没有一种类型的测试或测试方法能确保特定的软件产品已经被彻底地

54、测试。测试所 有的程序功能性并不意味着所有的程序已经被测试。测试所有程序的编码并不意味 着在程序中出现所有必要的功能性。测试所有程序功能性和所有程序编码并不意味 着程序是 100%的正确！发现没有错误的软件测试不应当被解释成意味着在软件产品 中不存在错误；其也许意味着测试是表面的。软件测试案例的基本要素是预期结果。这是允许实际测试结果的客观评价的关 键细节。必要的测试信息从相应的、预定义的定义或规范中获得。软件规范文件必 须识别什么、什么时间、如何、为什么等，要和细节的工程（即可测量的或客观上 可验证的）级别一起获得以便其通过测试证实。有效软件测试的实际工作处于什么 要被测试的定义状态而不是处

55、于测试的性能中。软件测试过程应当基于促进软件产品的有效检验的原则。可适用的软件测试原 则包括：预期的测试结果是预定义的； 优良的测试案例具有暴露错误的高概率；成功的测试是发现错误；有来自编码的独立性；雇用应用（用户）专家和软件（程序设计）专家两者； 测试员使用不同于编码器的工具； 仅仅检查普通案例是不充分的； 测试文件编制允许其再使用在随后的评审期间测试结果的通过 / 失效状态的 独立确认。一旦预先必要的任务（例如编码检查）被成功地完成，软件测试开始。其以单 元级别的测试开始以系统级别的测试结束。也许有测试的截然不同的集成级别。软 件产品应当经受基于其内部结构和基于其外部规范的测试案例的挑战。

56、这些测试应 当提供软件产品符合其功能、性能、界面定义和要求的彻底的严格的检查。基于编码的测试也通称为结构测试或“白箱”测试。其识别基于从源编码、详 细设计规范、和其它开发文件获得的知识的测试案例。这些测试案例挑战由程序做 出的控制决策；程序的数据结构包括配置表。结构测试可识别当程序运行时从来不 执行的“失效“编码。结构测试首先由单元（模块）级别测试完成，但是能被扩展 到其它级别的软件测试。结构测试的级别可使用设计的规格来评价以显示软件结构的什么百分比已经在 结构测试期间被评价了。这些规格典型地被称为“覆盖”，是关于测试选择标准的 完整性的测定。结构覆盖量应当和软件造成的风险的级别相称。使用术语

57、“覆盖” 通常意指 100%覆盖。例如，如果测试程序达到了“声明的覆盖”，其意指软件中声 明的100%已经运行了至少一次。通用的结构覆盖规格包括：声明覆盖 该标准对每个程序声明，要求充足的测试案例至少被执行一 次；然而，其完成不足以提供软件产品性能的置信度。决策（分支） 覆盖 该标准对每个程序决策或分支， 要求充足的测试案例 被执行，以便每个可能的结果至少重现一次。 其被考虑为大多数软件产品的 最小覆盖级别，但是单独的决策覆盖对于高完整性的应用是不足的。 条件覆盖 该标准对程序决策中的每个条件， 要求充足的测试案例具有所 有可能的结果至少一次。 仅仅当必须评价多个条件以达成决策时， 其不同于 分支覆盖。多- 条件覆盖 该标准要求充足的测试案例练习程序决策中的条件的所有 可能的结合。循环覆盖 该标准对所有的程序循环，要求充足的测试案例被执行 0次、 一次、两次和许多迭代次数覆盖初始化，典型的运行和终止（边界）条件。路径覆盖 该标准对每个可行的路径、 基础路径等等， 要求充足的测试案 例从规定的程序段的开始到退出被执行至少一次。 因为通过软件程序非常大 数量的可能路径， 路经覆盖通常是不可能达到的。 路径覆盖数量通常基于处 于测试