1、ISO/TR80002-2第一版2017年06月医疗器械软件第2部分：医疗器械质量体系软件的确认（标准草案）目录前 言错误!未定义书签。引言31 范围42 规范性应用文件43 术语和定义44 软件确认探讨44.1 定义 44.2信心建立活动：工具箱内的工具44.3批判性思维55软件确认与批判性思维55.1 概述55.2确定软件是否外在范围内95.2.1记录软件过程和使用的高级定义95.2.2监管使用评估95.2.3与医疗器械监管要求无关的过程和软件95.3开发阶段105.3.1制定确认计划105.3.2定义105.3.3实施、测试和部署145.4维护阶段155.4.1进入维护阶段155.4.2
2、维护安排165.4.3维护阶段内的维护类型165.4.4过程变化：改变风险控制措施165.4.5应急变化175.4.6维护预期用途175.5 退役阶段186文档187前提过程19附件A （资料性附件） 工具箱20附件B （资料性附件） 风险管理和基于风险的方法26附件C （资料性附件） 示例30引言本文档旨在帮助读者采用批判性思维使用基于风险的方法确定医疗器械质量体系中所使用的进行过程软件确认的适当活动。其中包括质量管理体系中所使用的软件、生产和提供服务过程中所使用的软件，以及ISO 13485:2016标准：第4.1.6、7.5.6和第7.6款所要求的用于监测和测量的软件。本文件汇集了医疗器
3、械行业此类软件确认人员以及可审计文档专职建立人员的经验。文档开发过程中脑子里始终想着在面对医疗器械质量体系所用软件确认过程时我们都会经历的特定问题和疑问，如：必须完成什么工作？需要多少钱？风险分析如何进行？经过深入讨论，得出的结论是：在每个示例中，确定了一组活动（即一个工具箱里的多个工具），对软件按照预期用途运行的能力提供一定的信心，而活动清单由于软件的复杂性、所涉及的伤害风险以及供应商所提供软件的谱系（例如：质量、稳定性）等因素而各不相同。本文件旨在帮助包括厂家、审核员和监管机构在内的利益相关方理解和运用ISO 13485:2016标准第4.1.6、7.5.6和7.6款中所包含的软件确认要求
4、技术报告 ISO/TR 80002-2:2017(E)医疗器械软件第2部分：医疗器械质量体系确认软件1 范围本文件适用于设备设计、测试、组件验收、制造、标签粘贴、包装、分发以及投诉处理中所使用的任何软件，或ISO 13485中所描述的某种医疗器械质量体系的任何其他方面的自动化。适用于： 质量管理体系中所使用的软件； 生产和服务提供过程中所使用的软件；以及 用于要求监测和测量的软件。不适用于： 作为医疗器械组件、部件或附件的软件，或 本身为医疗器械的软件。2 规范性应用文件本文件内没有规范性引用文件。3 术语和定义就本文件而言，ISO 9000标准和ISO 13485标准中给出的术语和定义适用
5、ISO和IEC在以下地址维护用于标准化的术语数据库： ISO在线浏览平台：http:/www.iso.org/obp/。4 软件确认探讨4.1 定义“软件确认”这一术语的解释，即有广泛含义，亦有狭义含义，范围可仅是测试，亦可指包括测试在内的广泛活动。本文件使用的术语“软件确认”表示建立信心，令人相信软件适合其预期用途，而且性能可靠、值得信赖的一切活动。选定活动，无论是什么活动，均宜确保软件满足其要求和预期目的。4.2信心建立活动：工具箱内的工具工具箱内的工具（参见表A.1至表A.5）包括软件生命周期内完成的各项活动，可降低风险并且建立信心。4.3批判性思维本文件提倡采用批判性思维，确定宜执行
6、哪些活动，充分确认特定软件。批判性思维是分析、评估软件各个方面及其使用环境的过程，从而确定确认过程中要运用的最有意义的信心建立活动。批判性思维防止一刀切，避免在未彻底评估解决方案、确定其是否确实产生了预期结果的情况下，采用适用于一切确认解决方案的方法。批判性思维承认确认解决方案在软件之间可能存在很大差异，允许在类似情况下，将不同确认解决方案应用于同一软件。批判性思维挑战确认解决方案的提案，以确保其满足质量管理体系的预期意图，同时考虑所有关键利益相关方及其需求。批判性思维也在软件特征发生变化、软件预期用途发生变化或新信息可用时，用来重新评估、确认解决方案。批判性思维得到的确认解决方案可为制造商建
7、立合规性，确保软件使用安全。批判性思维得到的是审核人员认为既合适又充分的书面证据。批判性思维使开展确认工作的个人感觉工作使其增值，其努力代表着达到预期结果的最有效方式。附件C给出的示例研究，展示了批判性思维在各种情况下医疗器械质量体系所用软件的确认情况，包括不同复杂程度、不同谱系和不同风险等级。5软件确认与批判性思维5.1 概述在医疗器械质量体系软件的整个生命周期，需要采取适当的控制措施，确保软件按预期运行。融入批判性思维并运用选定活动建立信心，使软件有效状态的建立和维护得到实现。图1为典型活动与控制措施的方案视图。图中的典型活动和控制措施从做出决定那一刻开始，到某个过程实现自动化、直至软件退
8、役或不再是医疗器械质量体系生命周期的一部分为止。虽然图1描绘的是一个序变模型，实际上，此过程在元素定义、风险识别和批判性思维应用过程中都具有迭代性。在开发用于医疗器械质量体系的软件时，从工具箱中选择一种建立信息的基本活动就是选择软件开发生命周期模型。所选模型宜包含批判性思维活动，以便在各种生命周期活动开展期间，选择其他合适的工具。所采用的分析评估结果是，选出一系列最重要的信心建立活动的推动因素，确保软件按预期运行。本文件并无暗示或规定使用任何特定软件开发模型的意图。然而，为了简便起见，本文件的其余部分解释了批判性思维的概念。各个阶段均采用通用名称，均以瀑布式开发模型为背景。其他软件模型（例如：
9、迭代、螺旋等）只要吸收了批判性思维和合适的工具，均能使用。医疗器械质量体系软件开发退役维护迭代风险分析迭代变更管理保持确认状态建立电子记录长期访问通道最终用途纠正、适应性、完善性维护实施/测试/使用生命周期控制软件确认（建立确认状态）定义图1生命周期控制在考虑在某一过程使用软件时，宜通过调查其预期用途，确定所推荐软件是否是某医疗器械质量体系过程的一部分。如果是，则宜确认该软件的预期用途。尽管本文档描述了医疗器械质量体系软件的确认方法，但同样的方法也是软件评估其是否满足规定要求的良好实践。软件确认最关键的部分是开发/购买正确的软件工具，以便能够按照厂家的意图提供过程支持。这意味着需要宜准确确定，
10、从而评估开发/购买的软件是否适于满足预期用途的要求。适用于确认的技术要求和适合于确认的工艺要求同样重要。在考虑将软件应用于某一过程时，该软件能够与其他软件交互，或能够为其他软件提供接口。在生命周期的开发阶段，执行风险管理和确认计划制定任务，以收集信息，并驱动软件在以下四个方面做出决策： 所采用的工作量以及对文件记录和可交付成果的审查； 文件记录与可交付成果的内容范围； 工具箱工具的选择和工具应用方法； 工具应用方面的工作量。这四个领域决策的主要驱动因素即是过程风险，也是软件风险。但是，其他驱动因素也可能影响决策，包括软件和过程的复杂性、软件类型和软件谱系。确认计划制定过程包含两个不同的元素。第
11、一个确认计划制定元素涉及确定文档记录的严格程度以及审查由此产生的可交付成果要采用的审查程度。此要素的决策主要由过程风险分析结果驱动。第二个确认计划制定元素驱动的是从工具箱中选择工具，以实施、测试和部署该软件。工具选择主要由软件风险分析驱动。此类计划步骤源于不同类型的风险分析，并在本文件中描述为独立的活动。但是，很多时候将这些步骤合并为一个活动，其中包括风险分析的不同方面以及由此产生的进行确认的选择。在生命周期的开发阶段，风险管理和确认计划制定任务用于确定应用于软件的适当工作量，并确定建立信心使用哪些工具。这种方法可以完成适当的增值活动和确认任务。这是建立某种经确认状态的基础。这些活动和任务完成
12、后，工具及其相关结果将即刻在确认报告中引用，作为对软件确认结论的支持。部署完成后，软件将进入软件生命周期的维护阶段。在此期间，软件将按照业务需求或法规要求变化下达的指令进行监控、改善和更新。变更控制活动采用的概念与在生命周期的开发阶段所采用的初始方法的概念相同。然而现在评估变化针对的是变化在初始开发期间对预期用途、失败风险、风险控制措施的影响以及对软件本身任何功能的影响。退役阶段是通过删除过程或替换过程正在使用的软件来去除软件的行为。图1中显示的活动反映了软件生命周期主要控制活动。其他工作流包括项目管理、过程开发、供应商管理（若适用）以及可能的其他工作流，具体取决于正在实施的软件。图2描述了其
13、他工作流活动中的软件生命周期控制活动和批判性思维。关键的思考活动出现在迭代风险分析和确认工作流中。在组织的业务模型中对这些工作流进行清晰、正式的定义非常重要，以确保某个程序从业务和监管两个角度妥善管理软件。确认流程迭代风险分析确认计划与报告软件系统开发定义实施、测试、部署维护退役定义流程要求分析流程故障风险确认计划定义软件预期用途分析软件故障风险确认计划软件实施（设计、开发、建立及测试）确认报告软件发布软件维护维护确认计划图例a：包括风险控制措施，如代码审查等活动和监视时钟等在设计活动。还包括目标区域的测试方向和要使用的测试类型。输入信息产量分析对现有风险和/或引入新风险影响的变化软件退役结束
14、流程定义下游控制伤害的可能性和严重性伤害的可能性和严重性伤害的可能性和严重性下游控制确认软件要求要控制的风险结果结果验收注意：在使用术语“develop”或“development”时，“develop”或“development”系指开发软件某一经过确认的状态。图2生命周期控制工作流图2中描绘的各种颜色对应于图1中整体方法过程图中的生命周期部分。红色虚线表示某一个活动输出的信息，而该信息为另一活动提供输入，或在另一活动中有助于推动决策。该图展示了在完成需要输入的活动之前，获取输入信息的需要如何推动活动排顺。值得注意的是，所有活动都会完成，不受正在实施的软件的大小或复杂程度的影响。但是，对于更
15、大或更复杂的软件，此类活动很可能是分离的；而对于更小或更简单的软件，许多活动则会组合在一起或同时完成。总之，批判性思维方法描述了一种系统方法，用于在各种工作流中识别和包含适当的信心建立活动或工具，以支持软件在发布时得到确认，并且在软件退役之前将保持确认状态的结论。以下子条款提供了图1中描述的生命周期控件中的每个方块的其他详细信息。子条款使用图2中所示的迭代风险分析、确认和软件活动的工作流描述，提供包含批判性思维的各种决策点以及各种决策驱动因素的透视图。5.2确定软件是否外在范围内5.2.1记录软件过程和使用的高级定义确定是否认为软件用于医疗器械质量体系的第一步是记录该软件的过程和使用的高级定义
16、在很容易知道软件处在范围内并且有人已经在着手定义软件详尽的预期用途时，此活动可能看起来价值很小。而在此类假设不太清楚的情况下，记录过程和使用情况可以明确确定该软件是否在范围内。此外，对于已确认超出范围的软件，此类活动能够找出导致软件超出范围的原因。5.2.2监管使用评估监管使用评估可用于确定软件是否是一款“医疗器械质量体系软件”，因此属于本文件的范围。首先确定适用于软件使用过程和软件管理的数据记录的特定法规要求。能够使用一系列问题帮助充分理解软件在支持法规方面所起的作用。宜考虑以下类型的问题。a) 软件的故障或潜在缺陷是否影响医疗器械的安全或质量？b) 软件是否自动执行或按照法规要求执行某项
17、活动（特别是医疗器械质量管理体系的要求）？示例可包括捕获电子签名和/或记录、维护产品的可追溯性、执行和捕获测试结果、维护CAPA、不合格、投诉、校准等数据日志。任何问题回答“是”都确定了软件需要确认，并且在本文件的范围内。有时，确定某一过程以及相应的软件是否是质量体系的一部分可能很困难。有些工具能够与实际医疗器械存在很大程度的分离。因此，每个组织均宜仔细考虑这种边缘软件的周围环境，并宜完全了解软件故障对过程的影响，并最终了解软件故障对任何人造医疗器械安全性和有效性的影响。如果答案不确定，最好的办法是将把该软件视为处在范围内，并采用本文件中所定义的方法。5.2.3与医疗器械监管要求无关的过程和软
18、件当过程或软件包含超出医疗器械法规要求的功能时，宜进行分析，确定认为该软件的哪些部分处在范围内，哪些部分不在范围内。应根据软件各个组件、模块和数据结构之间的集成程度以及组织的合规性需求，使这些决策合理化。对于用于支持质量体系的软件（例如：复杂企业资源规划（ERP）的大型软件），这种合理化尤其重要。ERP软件能够包括非医疗器械监管过程（如：会计和财务等）的功能。但是，这种功能对于商业运营能够至关重要，并且必须满足某些政府要求（例如：萨班斯奥克斯利法案的要求）。5.3开发阶段5.3.1制定确认计划在应用批判性思维时捕获的确认计划制定活动的第一部分，使用过程风险分析的输入（见附件B）确定宜用于文件编
19、制的工作量的基础，并驱使软件从工具箱的“定义”部分选择工具（见表A.1至表A.5）。第二部分使用软件风险分析的输入，驱使软件从工具箱中选择实施、测试和部署工具。执行完毕，软件活动和确认状态随即建立，而且确认的证据在确认报告即刻形成。许多开发生命周期模型能够在开发阶段应用。本文件没有提倡或推荐任何一个模型；但是，要求采用某种受控方法。这种受控方法将以实施、测试和部署之前定义要求（包括预期用途）的概念为基础。这对于确定软件预期用途确认至关重要。5.3.2定义5.3.2.1定义方块要求在定义块内完成的活动包括过程的定义、该过程内软件预期用途的定义，以及基于该过程内所确定的固有风险规划确认工作量。图3
20、描绘了选定瀑布模型示例中开发阶段的这一部分。确认流程迭代风险分析确认计划与报告软件系统开发定义定义流程要求分析流程故障风险制定确认计划定义软件预期用途分析软件故障风险流程定义下游控制伤害的可能性和严重性伤害的可能性和严重性下游控制确认软件要求图3生命周期阶段：定义方块工作流5.3.2.2过程要求应用生命周期控制的第一步是确定整个过程的目的和作用，特别是要由软件控制的部分。最好的实现方法是让适当的主题专家参与，并要包括所有相关方面和活动，无论是否全部受软件控制。好处如下： 能够清楚地了解监管要求； 能够清楚地了解在该过程的范围内特定软件的预期用途； 能够通过程序或其他方式清楚地识别和处理不受特定
21、软件控制的过程问题和活动; 进出所识别软件的过程活动得到识别，并能在软件故障风险评估过程中和找出软件故障风险控制办法的过程中予以考虑。过程定义活动为后期在生命周期做出决策奠定了基础，对于把精力中在增值、基于风险的活动上面至关重要。5.3.2.3过程故障风险分析软件与医疗产品的最终安全性和有效性之间的关系将在风险分析过程考虑。还宜考虑以下内容。 对人类有害的风险：这包括对患者和用户的直接伤害以及当软件控制制造或设备质量出现故障时的间接伤害，从而导致设备故障，从而造成伤害。 监管风险：如果软件故障可能导致监管机构要求的记录丢失（例如CAPA，投诉，设备主记录或设备历史记录）或偏离质量，则应考虑不遵
22、守监管要求的风险系统和制造程序。 环境风险：软件运行环境的风险。物理和虚拟。其他类型的风险能够纳入本模型，但本文件的范围和为降低风险而讨论的工具并不针对这些风险。本文件的重点是在过程故障的范围内，确定与软件故障相关的人身安全风险、监管风险和环境风险。风险分析的结果宜清楚地记录，因为这些结果是从工具箱中选择工具以及证明确认活动所采用工作量合理的有价值的决策驱动因素。5.3.2.4制定确认计划确认程度和客观证据的范围必须确保软件要求能够始终如一地执行，取决于整个过程中软件的临界值。因此，关于采用工作量和可交付元素审查的第一个确认计划制定活动以过程故障风险分析输入为唯一根据。该确认计划制定活动产生确
23、认计划文档的第一次迭代。计划包括选择“工作量”（即决策）以及做出这些选择的理由（即决策驱动因素）。理由宜以某过程故障造成的伤害风险为依据。确认计划制定过程中应提供批判性思维应用于确认计划过程的客观证据。5.3.2.5软件预期用途5.3.2.5.1预期用途的要素预期用途旨在提供软件功能的完整画面及其在过程中的目的。具体来说，预期用途系指描述和解释软件适应整个自动化过程的方式、软件的功能、人们对软件的期望以及人们能够多大程度地依赖软件设计、生产和维护安全医疗器械。预期用途是用于了解与软件使用相关潜在风险的关键工具。预期用途的三个主要要素是： 与以下内容有关的目的和意图 软件的使用（例如，人物、内容
24、何时、原因、地点、方式等）， 软件的监管使用，以及 过程内软件的界限或与其他软件和/或用户的界限； 软件使用要求。一般而言，随着复杂性和风险的增加，该元素增加更详细的有关软件使用的信息（例如：使用案例、用户要求等）； 软件要求。随着复杂性和风险增加到宜向软件实施者提供明确方向的程度，该元素提供更具体、详细的有关软件期望的信息。预期用途宜由对经验丰富的，精通法规、质量体系和受控过程的人员正式控制和批准。鉴于我们应确认“预期用途”，除非软件的预期用途定义充分，否则确认无法进行。以下子条款提供了有关软件预期用途元素的更多详细信息。5.3.2.5.2软件目的和意图包含涵盖三个要素的信息：软件使用、监
25、管使用和边界定义。a) 软件使用 在定义软件的使用时，宜考虑以下问题：内容、原因、方式、地点、地点。问题的答案探讨软件正在满足过程要求的方式。这种探讨有助于识别表1所示的软件定义的基本信息。 对软件描述有意义的答案宜纳入既定预期用途定义。表1样题和答案问题答案软件解决什么问题？为了进行趋势研究，存在有效、准确地汇集产品缺陷数据的问题。软件为什么有用？软件能够从全球的地址汇集数据并研究其趋势。软件如何解决问题？软件驱动数据收集过程，并自动汇集和计算趋势信息，或者软件并不驱动该过程，但被动收集用于汇总和计算趋势信息的数据。谁使用该软件？“质量保证与运营部门”使用该软件。软件在哪里使用？该软件可通过
26、美国、欧洲和日本的地址访问。软件什么时候使用？该软件在正常工作时间内访问全球的地址（即每周一至周五）。注意：这些样题并不详尽。b) 监管使用 在评估监管使用时，可以进一步探讨所回答的问题，以确定软件是否在范围内（见5.2）。展开所有为“是”的答案，从而纳入得出这些结论的原因。既然经确定，软件处在范围内，则需确定任何对人类（医疗器械用户除外）或对环境的潜在危害。以下所有问题都使用户的考虑方向指向公共健康、安全性和有效性或电子记录和签名真实性等作为法规要求一部分的要素。 软件的故障或潜在缺陷如何影响医疗器械的安全性或质量？ 软件如何自动执行或如何执行法规（特别是医疗器械质量管理系统的要求）规定的某
27、项活动？ 软件怎么会对人（医疗器械用户除外）或环境造成伤害？c) 软件边界 定义有待通过软件控制的过程的几个部分（该过程的内部边界）以及定义软件接口的位置（与其他软件的边界），有助于促进确认工作的有效性和效率。例如，多个软件产品单独确认相比，多个软件产品作为一组进行确认，通常效率能更高。还应考虑，各种分组策略能够以何种方式影响正在进行的维护阶段活动的效率。 过程的内部边界 识别软件在过程内部的边界，清楚地确定了要纳入预期用途中的方方面面。软件既能自动化某个整体过程，也能自动化多个活动的一部分，还能充当该过程的数据存储库。了解软件在该过程内所起的作用，有助于确定与软件某个潜在故障相关的风险。 与
28、其他软件的边界 当与其他医疗器械质量体系软件或医疗器械软件进行外部连接时，识别应用程序之间的所有接口非常重要。确认工作通常包括作为方法固有部分的内部接口，但不宜忽视软件的外部接口。软件应用程序之间的所有接口都宜纳入批判性思维过程。5.3.2.5.3软件使用要求软件使用要求包括记录良好且可追溯的为软件目的和意图提供额外细节层的元素。从用户的角度或产品需求的角度来看，这些要求提供了对系统使用场景的深入见解。用户的视角能够以用户需求、使用案例的形式或根据其他以用户为中心的需求进行捕获。产品需求视角捕获的是受系统影响的医疗器械的需求，在某些情况下，能够将某个参考文献引入特定器械要求内或纳入某个软件可能
29、影响的生产线的简介内。5.3.2.5.4软件要求由元素定义活动组成。这些元素记录良好，具有可跟踪性，用于指定软件为了满足其目的、意图和使用要求需要执行的操作。软件要求包括系统设计的输入，系统配置输入以及测试活动输入。5.3.3实施、测试和部署5.3.3.1所需活动在实施、测试和部署方块中完成的活动包括：a）规划设计中的确认严格程度，b）开发和配置，c）构建软件，和d）测试基于确定风险的软件。5.3.3.2软件故障风险分析软件故障风险分析的关键点是确定并记录与软件故障相关的租赁风险，并确定任何控制措施（包括正在分析的软件之外的过程和软件控制措施）。然后使用该分析得出真现有效的确认方法。在审查可归
30、因于软件故障的风险时，考虑构成风险控制措施的分析软件之外的任何过程控制。这种风险控制措施能够减少软件故障的影响，从而减少对软件的依赖，进而减少对测试（检查）和文档（客观证据的收集）的依赖，确保软件的安全运行。纳入这些考虑因素将有助于确保在整个过程的背景下查看软件。附件B中提出的模型并不代表是一个无所不包的公式。由此产生的分析结果为从工具箱中选择用于软件确认的工具提供了输入。5.3.3.3制定确认计划此活动采用预期用途定义和软件风险分析结果作为输入，用于确定风险控制措施以及从工具箱中选择用于确认软件的工具。工具选择过程由符合条件的个人参与，这一点很重要。符合条件的个人不必是软件专家，但了解故障对
31、过程的影响以及将使该过程自动化的软件的故障的固有风险。来自不同学科（监管、质量、临床等）的个人宜参与任何高度复杂或与其故障相关的高风险软件的规划过程。制定确认计划生成一个文档化计划，该计划描述选择结果（决策）以及选择原因（决策驱动因素）。制定确认计划提供了信心建立活动选择依据的文档证据，以确保软件以预期的方式运行。5.3.3.4软件实施（设计、开发、构建和测试）本方块包括工具箱中许多工具的实际应用。工具（确认计划中确定的所需活动）在设计、开发、构建和测试步骤中进行（见图4）。验收软件发布确认流程迭代风险分析确认计划与报告软件系统开发实施、测试、部署分析软件故障风险确认计划软件实施（设计、开发、
32、建立及测试）确认报告伤害的可能性和严重性要控制的风险结果a 包括代码审查等作为活动的风险控制措施以及监督计时器等设计内容。另外还包括目标区域的测试方向和要采用的测试类型。图4生命周期阶段：实施、测试和部署方块工作流5.3.3.5确认报告足够的信心建立活动一旦完成（包括选自工具箱的工具），以确保软件按预期实施，活动和（有可能）活动结果宜在最终确认报告中引用。报告的正式审查和批准为所有已记录的客观证据提供一份参考摘要，而这些证据支持软件已针对其预期用途完成确认的结论。5.3.3.6软件发布确认结论认为，宜存在一种用于发布软件的正式受控方法。定义控制措施应确保并确认：投入使用的软件与已通过确认报告所
33、引用信心建立活动评估的软件相匹配。否则，理论基础和控制措施宜确保并证实结果足以代表已发布软件在其预期环境中的性能。5.4维护阶段5.4.1进入维护阶段阶段入口标准：软件发布后，软件维护阶段随即开始。活动范围：维护阶段活动包括在适应各类变化的管理和控制的同时，确保软件保持在经过确认的状态。有些变化类型只涉及软件使用所处过程的更化。对任何已确认系统的更改宜根据政策和程序以受控方式进行。理想情况下，建议更改在测试环境下进行，并在将系统升级投入生产使用之前进行确认。如果在测试环境下的变化无法确认，而且变化测试宜在生产环境中进行，则应采取适当的控制措施，最大限度地减少对生产环境或直接对产品产生的不良影响
34、确认变更选用工具箱中的哪些工具，宜通过分析对现有风险控制措施的影响或通过引入新风险确定；或由两者共同确定。由于软件或其配置的实际使用能够随着时间变化（尽管在竭尽全力对其进行控制），使用维护阶段专用工具（例如：定期监控实际使用情况，或实时监控软件配置）或许合适。如果预期用途的变化导致风险级别更高，则该变化能够引起范围比原来执行的确认活动更大的一系列确认活动，即使软件毫无变化，也会如此。关于开展范围更加广泛的确认活动的决定，宜作为确认计划的一部分记录在案，以提供证据，证明软件保持在确认状态。5.4.2维护安排应在开始维护阶段之前记录维护计划证据。理想情况下，维护计划在开发阶段开始安排。宜正确理解
35、变更影响软件确认的方式，检查变更对风险的影响，并规划适当的确认维护活动。大型复杂的软件或许必须在不影响软件预期执行能力的情况下适应日常维护和性能调整活动。在开发阶段安排维护计划能够在不影响确认的情况下完成哪些操作活动，哪些更改需要确认工作。在软件到达维护阶段之前，宜计划并讨论确定何时对软件开展进一步确认活动的方法，包括底层软件（例如，操作系统、数据库管理系统）的变化影响已确认软件的方式。培训软件操作员识别这些边界并识别正常操作活动与需要确认的任何更改之间的差异是有好处的。可追溯性分析是管理维护活动的有用工具。可追溯性分析通常是初始确认的基石，并且通常通过可追溯性矩阵来推动。矩阵反映测试或其他确
36、认活动的要求、反映风险控制措施等等。如果初始实施期间可追溯性分析进行良好，可追溯性分析将通过促进变更影响的识别以及促进适当变更确认活动的识别成为维护期有价值的工具。在简单软件中，此类分析能够包含对实施和确认的单级需求跟踪。但是，复杂软件可能需要多级矩阵，将顶级功能分解为较低级别的需求，然后分解为实施和确认。也可以嵌入其他信息，例如，能够在跟踪矩阵内指定认为风险极高的软件部分，可能还指出了其他确认活动。5.4.3维护阶段内的维护类型软件在发布使用后可能会发生变化的原因有很多。其中较常见的维护变化类型包括： 做出纠正维护变化，以纠正软件中的错误和故障； 完善维护更改，以增强性能、可维护性或其他软件
37、属性； 为更新软件操作环境而进行的自适应维护（例如，操作系统变化、系统硬件变化或与软件连接的其他应用程序的更化）。5.4.4过程变化：改变风险控制措施当由软件完全或部分控制的过程发生变化时，宜进行影响分析，重新评估风险控制措施。软件完全或部分控制的过程能够独立于软件变化。当某一过程发生变化时，了解该变化对软件确认状态的影响非常重要。过程变化能够影响软件的预期用途或其他有关软件支持信息的预期用途。过程变化还能影响作为确认基本原理的软件一部分的现用风险控制措施。由于软件是过程的一部分，因此下游控制可能是软件的重要风险控制措施。如果下游控制被正确识别为软件确认基本原理和过程定义的一部分，则建议过程变
38、化影响分析更容易进行。对于软件和软件运行过程而言，以建立信心的方式进行维护，是影响分析的关键。5.4.5应急变化应紧变化宜根据批准程序进行调整。这些程序宜要求提供开发和实施的正当理由，要求说明获得和记录变化部署的授权机制，要求说明确保风险得到适当评估和控制的规定，以及调用应急变化所需的任何活动（如：培训、沟通、产品评审和处理等）。在此情况下，执行规定，适当评估和控制风险，就表示需要在发布之前，满足变化确认监管要求所需开展的最小范围的活动。紧急情况下，可能需要进行软件变更。通常，如果软件操作系统的完整性或数据的完整性受到损害，或为了减轻潜在有害情况，需要进行此类更改。此外，可能还需要的在应紧变化
39、发生后开展一系列活动，以充分评估变化带来的所有影响。依据某过程故障带来的总体风险，过程输出（数据或产品）可能需要实施额外控制，直到应变化后的所有活动全部完成为止。造成进程中断软件问题通常很明显，而找出细微、隐蔽的问题比较困难。定期评估错误日志、定期评估帮助中心的请求、客户反馈和其他缺陷报告，可以指出隐蔽的问题。此类监控技术发现的问题，不足以显示在错误报告中，但能够指出可纠正的软件问题。因此，可能需要开展维护活动，通过对未来发布软件实施更正，处理识别出的问题。此外，已发布软件中归因于此类软件问题的问题能够主动管理。在利用维护活动纠正未来发布软件的问题后，宜检查已发布软件中已识别缺陷的历史影响，并
40、管理其后果。如果软件确认取决于通过培训确保软件正确使用，定期评估用户培训效果则是另一种有助于维持确认状态的监控技术。5.4.6维护预期用途如果软件的预期用途发生变化，则宜确认新的预期用途，或终止新用途。对于后者，风险评估是为了确保在未授权使用期间不会引入任何风险。预期用途的变化是需要特别注意的类别，因为变化可能很细微，而且难以发现，也可能非常明显。细微变化的变化对象是目的和意图或软件使用要求，并不一定导致详细的软件需求元素发生变化（见5.3.2.5）。这种变化可能是有意为之，也可能只是因为在新模式下简单地使用现有软件，而未意识到预期用途受到了影响。预期用途可能会随着时间的推移慢慢变化，或者用户
41、可能会以最初未预期的方式开始使用该软件。由于这种转变，所部署的软件不再处于确认状态。每次要对已确认的软件进行更改，都宜重新审查预期用途，确保预期用途与软件的实际用途一致。5.5 退役阶段在退役阶段，宜记录软件的退役情况，并建立可以在任何必须的记录保留期内访问任何相关电子记录的方法。软件退役活动高度取决于要退役软件的类型。有些软件只实施某种活动而不存储任何数据。其他软件则可以像批量可追溯性或文档控制系统一样复杂，其中包含大量与产品相关的数据和与合规性相关的数据。对于需要存储数据的软件，宜存在一份用于处理数据的计划。需要考虑的一些问题包括以下内容： 是否有软件取代退役软件？ 数据是否能够转移到新软
42、件里？ 数据是否宜转移成便携格式，以便长期保留？ 此类数据的数据保留要求是什么？ 数据是否会存储在耐用媒体上？ 如果数据会存储在耐用媒体上，那么，存储指令或存储程序是什么？可以检索包含所有相关数据要求的数据吗？ 可读耐用媒体和软件的维护程序是什么？ 是否会存储硬件平台档案，用来使用和检索已退役的应用程序？ 存储硬件如何维护？ 是否需要作为投诉或CAPA调查的一部分访问退役软件？ 是否需要平台和应用程序重新创建软件程序？6文档文档编制宜确保与软件生命周期控制活动相关的所有信息均得到适当记录和控制。具有优质高效的文件编制能力可以带来两大好处：a) 文档记录中清晰明确地表达完整的软件定义，可以充分了
43、解软件的预期用途和预期性能，并且能够了解对软件所做的任何和所有更改所带来的全部影响。b) 记录确认计划和记录确认实施情况，为利用批判性思维所做决策提供了书面证据。编制这种文档围绕所执行的评估或分析以及因此发生的针对基于风险的有意义的信心建立活动的工具选择，可以提供关于已执行确认的简洁知识。文档包含验收标准满足情况的概要，提供的证据表明，已完成的活动可确保软件按预期执行，并为其自动化过程引入了可接受的风险级别。所产生的文档范围与所应用的软件确认工作量直接相关。工作量宜与风险相称。因此，本文件中讨论的软件确认方法，根据过程故障的影响，决定文档的范围。该过程对人员或环境造成伤害的风险越大，文件的预期
44、范围就越大。此外，较高的伤害风险，宜推动多个跨功能同行或更高层次的管理层或两者一起开展更高级别的文件审查。如何将生命周期控制信息组织到文档中以决于许多因素，例如，所使用的技术以及软件的大小或复杂性。宜以方便信息审计方式组织信息，同时要有能力在软件生命周期的维护阶段保留确认状态的证据。生命周期控制信息的捕获、记录方式，取决于确认实施各方的偏好和既定政策。有关如何将生命周期控制的客观证据打包呈现在文档中，软件确认各方拥有自由裁量权。从合规性审查角度看，宜建立确认计划和报告文档，提供一大汇编文件，将曾经计划和执行过的所有增值、信心建立活动汇集在一起，以确保软件按预期执行。从本质上讲，此文档是基于输入
45、决策驱动因素）所做选择（决策）的关键记录。输入体现了确认所采用的批判性思维过程，表明符合法规意图的完整软件解决方案已经开发完成，而且考虑了所有关键利益相关方及其需求。注：术语“documentation”用于指被记录的信息主体，不管信息主题是否是记录在要求管理工具等捕获信息工具内的实际文档。7前提过程本文件中介绍的方法旨在完全在有效质量管理体系内运作，以提高效率。质量体系能够对批判性思维方法的成功产生最积极的影响。受影响的内容包括：资产与基础设施管理（人和硬件）、变更管理（包括配置管理）和供应商管理。详述介绍这些内容不在本文件的范围内；其中每项内容业内其他标准和文件中都有介绍（参见参考文献）
46、此外，本文件无意将特定作用或功能（例如：质量保证、管理和制造）与本文件中的活动关联在一起。执行确认活动的满意人选由各公司的理念和人力资源基础设施决定。附件A（资料性附件）工具箱A.l综述工具箱提供了一系列信心建立活动，开展这些活动能够满足确认要求意图。工具箱并不是满足此目的的所有可用活动的详尽列表，但提供了基于当前软件工程知识机构的启动程序集。其中一些活动相互重叠或协同工作，例如，正常的案例测试往往是软件系统测试的一部分，但这里关注的是活动的价值。这些活动将充当制定确认计划和执行该计划的基础。活动的选择和进行宜适合软件所带来的风险。为了支持此选择，工具箱内的活动按照以下体系分类和标记。 全范围：无论如何此活动都要进行。 量身定制：选择并执行此活动的相应部分。 选择：适当的时候选择并开展活动。工具箱能够量身定制，定义贵组织使用的活动。随着时间的推移而发展，工具箱还能够随着技术的变化和经验教训的积累进化，从而整合新的软件工程最佳实践。如适用，有些活动也会在标准程序中以程序性方式调出。A.2工具箱结构为方便起见，活动被组织成五个最重要的软件生命周期过程活动。依据软件的范围和性质，宜在软件生命周期的各个阶段应用批判性思维，以识别、选择最适合于该软件的活动。列表中出现的每个命名活动都有简短的定义以及关于该活
免费区 
