IEC-62304+软件国际标准中文翻译版

微软中国IEC62304医疗器械软件软件生存周期中文翻译版旭东2011-11-7Monday国际标准IEC63240第一版2006年5月医疗设备软件——软件生命周期程序刊物编号从1997年1月起，所有刊物都以60000系列命名发布。例如，IEC34-1现在是指IEC60034-1。统一版本分别指的是基础版，基础版与第现在，IEC的刊物以同一版本出版。例如，版本数字一次修改版的合并，基础版与第一次、第二次修改版的合并。关于IEC刊物的更多信息IEC刊物的技术内容是被控制在IEC不断地检查之下的，从而保证其中内容反映了当今科技。与此出版物相关的信息，包括它的有效期、新版本、修改处以及勘误处是可以出现在刊物目录中的（见下文）。有关正在思考和正在研究中的主题信息（该工作是由技术委员会承担的，他们准备了刊物）以及发布刊物的列表，也可以从如下渠道查询：IEC网站：刊物的目录：IEC网站的在线搜索功能（）使得您可以通过各种各样的标准来搜索，包括文本搜索、技术委员会搜索以及出版日期搜索。在线信息包括最近出版刊物，撤回信息，被替换的刊物以及勘误之处。IEC新出版刊物最新出版物的摘要（news/justpub）可以通过电子邮件来查询。欲获得更多信息，请与客户服务中心（见下文）联系。客户服务中心如果您有任何有关此刊物的疑问或者需要更多帮助，请与客户服务中心联系。电子邮件国际标准IEC63240异常错误!未定义书签。第一版2006年5月医疗设备软件——软件生命周期程序包括以版权-版权所有未经出版商书面许可，本出版物的任何部分不可以以任何形式和方式被复制或使用，电子或者机械的方式影印或者微缩拍摄。国际电工技术委员会邮政信箱：瑞士日内瓦电话：+41229190211电传：+41229190300、八—前言电子邮件网站：国际电工技术委员会是个为标准化而设立的世界性组织，包括所有国家的电工技术委员会。国际电工技术委员会的目标是在电气科学以及电子技术标准化的所有问题方面促进国际合作。为了这个目的以及其他活动，国际电工技术委员会出版国际标准，技术规格，技术，公开提供规范和指导（从此以后被称为IEC出版物）。目录1.范围错误!未定义书签。目的错误!未定义书签。应用领域错误!未定义书签。与其他标准的关系.错误!未定义书签。标准的遵守错误!未定义书签。2参考标准错误!未定义书签。3术语与定义错误!未定义书签。活动错误!未定义书签。架构错误!未定义书签。SOUP-未知出处的软件（首字母缩略词）错误!未定义书签。变更请求错误!未定义书签。配置条目错误!未定义书签。可交付成果错误!未定义书签。评估错误!未定义书签。损害错误!未定义书签。危险错误!未定义书签。生产商错误!未定义书签。医疗设备错误!未定义书签。医疗设备软件.错误!未定义书签。问题报告错误!未定义书签。程序错误!未定义书签。回归测试错误!未定义书签。风险错误!未定义书签。风险分析错误!未定义书签。风险控制错误!未定义书签。风险管理错误!未定义书签。风险管理文件.错误!未定义书签。安全性错误!未定义书签。保密性错误!未定义书签。严重损伤错误!未定义书签。软件发展生命周期模型错误!未定义书签。软件项目错误!未定义书签。软件产品错误!未定义书签。软件系统错误!未定义书签。软件单元错误!未定义书签。系统错误!未定义书签。软件更改的风险管理.错误!未定义书签。任务错误!未定义书签。可追溯性错误!未定义书签。检验错误!未定义书签。版本错误!未定义书签。4基本要求错误!未定义书签。质量管理系统.错误!未定义书签。风险管理错误!未定义书签。软件安全级别分类.错误!未定义书签。5软件开发程序错误!未定义书签。软件开发.错误!未定义书签。软件需求分析.错误!未定义书签。软件体系错误!未定义书签。软件详细设计.错误!未定义书签。软件单元的实施和检验错误!未定义书签。软件集成和集成测试.错误!未定义书签。软件系统测试.错误!未定义书签。软件发布错误!未定义书签。6软件维护程序.错误!未定义书签。建立软件维护计划.错误!未定义书签。问题分析与修改分析.错误!未定义书签。修改之处的实施.错误!未定义书签。7软件风险管理程序错误!未定义书签。对导致危险情形的软件进行分析错误!未定义书签。风险控制措施.错误!未定义书签。风险控制措施的检验.错误!未定义书签。8软件配置管理措施错误!未定义书签。附录C错误!未定义书签。总则错误!未定义书签。配置确认错误!未定义书签。变更控制错误!未定义书签。配置状况说明.错误!未定义书签。9软件疑难解答程序错误!未定义书签。准备问题报告.错误!未定义书签。调查问题错误!未定义书签。对相关部门提出建议.错误!未定义书签。运用变更控制程序.错误!未定义书签。保留错误!未定义书签。分析发展趋势的问题.错误!未定义书签。检验软件问题决议.错误!未定义书签。检测文件内容.错误!未定义书签。附录A错误!未定义书签。基本原理错误!未定义书签。等级要求总结.错误!未定义书签。附录B错误!未定义书签。范围错误!未定义书签。正规参考文献.错误!未定义书签。术语和定义错误!未定义书签。基本要求错误!未定义书签。软件开发程序.错误!未定义书签。软件维护程序.错误!未定义书签。软件风险管理程序.错误!未定义书签。软件配置管理程序.错误!未定义书签。与ISO13485之间的关系.错误!未定义书签。ISO14971的关系.错误!未定义书签。IEC60601-1:2005可编程电子医疗系统的关系错误!未定义书签。IEC61010-1的关系.错误!未定义书签。ISO/IEC12207的关系.错误!未定义书签。IEC61508之间的关系.错误!未定义书签。附录D错误!未定义书签。简介错误!未定义书签。质量管理体系在.错误!未定义书签。评估质量管理程序.错误!未定义书签。把本标准的要求合并入生产商质量管理程序错误!未定义书签。对无备有证明文件的质量管理体系的小生产商的备忘录错误!未定义书签。1.范围目的本标准为医疗设备软件生命周期下了定义。在本标准中描述的程序、活动、任务为医疗设备软件生命周期程序设定了一个普通的框架。应用领域本标本标准可应用于医疗设备软件开发与维护。当软件本身是个医疗设备时，或者当软件植入设备或成为最终设备的一个完整部分时，准可应用于医疗设备软件开发与维护。本标准不包括医疗设备的批准和最终版本发布，即使该医疗设备包括了整个软件。与其他标准的关系当研发一种医疗设备时，该医疗设备软件生命周期标准应当与其他适当的标准一起应用。录C说明了本标准与其他相关标准之间的关系。标准的遵守本标准的遵守被定义为与软件安全等级一致，本标准所确定的所有程序、活动以及任务的实施。注：软件安全等级所指的要求是由按要求的标准文件所确定的。标准的遵守是由本标准所需要的所有文件的检查来决定的，标准的内容包括风险管理文件，软件安全等级所需要的程序、活动以及任务的评估。注1：该审计可以由内部审计或者外部审计来实施；注2：尽管特定的程序、活动以及任务需要被实施，在实施这些程序、活动以及任务时，方法上是可以有弹性的。注3：当遇到任何列入有“酌情考虑“并且未被实施的要求时，该评估需要提交必要的解释性文件。注4：术语“一致性”曾用于ISO/IEC12207，在这个文件中的术语“标准的遵守”被应用于此标准。参考标准面所参考的文件对于本文件的应用来说是必不可少的。对于过时的参考文献来说，只有被引用的版本可以应用。对于更新的参考文献来说，所参考文献的最新版本（包括修改之处）可以应用。术语与定义对于本文件的目的来说，下文的术语与定义可以被应用。活动一组或多组相互联系相互作用的任务。异常任何背离预期所基于的要求规格的状况、设计文件、标准等等，或者背离一些人的观念和经验的状况。异常状况可能出现于检查、测试、分析、编辑、使用软件产品、或者可实施文件的程序中，但不仅仅局限于这些程序中。架构一个系统或组件的组织结构。变更请求对软件产品所做的备有证明文件的规格更改。配置条目在一个给定的参考点能够唯一分辨的实体。注：基于ISO/IEC12207:1995，定义。可交付成果活动或者任务所需要的结果或产出（包括文件）。评估一种范围的系统决定。在这个范围中，某种实体遇上它的具体标准。注：基于ISO/IEC12207:1995，定义。损害物理伤害、毁灭或者对人身体健康带来的这两种危害，或对财产环境带来的危害。注：ISO/IEC指南51：1999，定义。危险危害的潜在源头。注：ISO/IEC指南51：1999，定义。生产商对医疗设备设计、生产、包装、贴标签有责任和义务的自然人或法人；组装系统；在一种医疗设备上市或者投入使用之前改装该设备，不管该操作是由这个人实施的或者由代表此人的第三方实施的。注：ISO14971:2000，定义。医疗设备为人类一个或者多个具体目的，由制造商独立使用或者结合使用的任何工具、装置、器具、机器、器械、植入物、试管中的试剂或者校准器、软件、材料或者其他相似或相关的物品：疾病的诊断、阻止、监控、治疗或者缓；伤口的诊断、监控、治疗、缓和或者启动补偿机能；调查、更换、修正或者支持物理程序的剖析；支持或者延续生命；概念的控制医疗设施的消毒通过从人体获得的样本做试管实验，为医疗用途提供信息这些物品并没有通过药物学、免疫学或者新陈代谢的方法在人体上获得起初的意向功能，是通过这些方法可以促进其功能的实现。注1：这个定义是由全球协调工作组织定下的。详情请看参考文献【15】（在ISO13485:2003）ISO13485:2003，定义】注2：当此定义应用于不同国家规定时，可能会产生一些差异。医疗设备软件开发目的是合并入医疗设备中的软件系统，或者凭自身条件和用途可被用作医疗设备的软件系统。问题报告不合适的行为，或者与其规格相反用户或其他对此感兴趣的人所认为的对预期用途不安全、的软件产品所出现的实际记录或者潜在行为。注1：本标准不要求软件产品对每一个问题报告都做出更改。生产商可以把问题报告当做误解、错误或者非重要事件而拒绝。注2：问题报告可以针对已发布的软件也可针对尚在开发中的软件。注3：本标准要求生产商问题报告相关的已发布产品实施额外的决策，制定步骤以确保管理行动被检验和实施。程序一系列相互联系相互作用把输入转为输出的活动。ISO9000:2000，定义】注：术语“活动”列入了财力的运用。回归测试可靠性或者性能这个要求决定对一个系统组成做出改变的测试还没有对软件产品的功能性、产生不良影响，也尚未产生其他的缺陷。ISO/IEC90030:2004，定义】风险危害产生的可能性与危害的严重性的结合。ISO/IEC指南51:1999定义】风险分析有效信息的系统运用以检验故障，估计风险。ISO/IEC指南51:1999定义】风险控制制定决策和降低风险或者把风险控制在特定标准的程序。ISO14971:2000定义，修改版】风险管理分析、评估任务和控制风险的程序中对管理政策、程序和实践的系统应用。ISO14971:2000定义】风险管理文件记录和其他文件的设置，不需要是连续的，是在风险管理程序中产生的。ISO14971:2000定义】安全性没有不可接受的风险ISO/IEC指南51:1999定义】也不会被拒绝接触它保密性数据和信息的保护，非权威人士或系统不能够读取或修改数据和信息，们。ISO/IEC12207:1995定义】严重损伤直接或间接的伤害或者疾病：a)威胁生命，b)对身体功能造成永久性损伤或对身体结构造成永久性伤害，或c)需要药物或外科手术介入去阻止对身体功能造成永久性损伤或对身体结构造成永久性伤害。注：永久性损害指的是对身体结构或功能造成的不可逆转的损害或伤害，不包括无关紧要的损害或伤害。软件发展生命周期模型概念上的结构使得软件的生命跨度从它的要求定义到它的生产发布，它识别软件开发程序中的程序、活动和任务，描述活动与任务之间的顺序和依赖关系，以及检验里程碑——按规定可以交付使用的产品完成的检验。注：基于ISO/IEC12207：1995，定义软件项目计算机项目的任何可识别部分ISO/IEC90003:2004,定义，修改版】注：三个术语识别软件的分解。最高等级是软件系统。最低等级尚未深层次分解的是软件单元。所有组成的等级包括最高等级和最低等级都可以被称作软件项目。那么软件系统是由一个或者多个软件项目组成的，并且每个软件项目是由一个或者多个软件单元组成的或由可分解软件项目组成。责任留给生产商，为软件项目和软件单元提供定义和间隔尺寸。软件产品电脑项目、程序以及可能相关的文件和数据装置ISO/IEC12207:1995定义】软件系统软件项目的有机结合以实现某个具体功能或者一系列功能。软件单元不能再分成其它项目的软件项目。注：软件单元可以被用作来做软件配置管理或测试。SOUP—未知出处的软件（首字母缩略词）SOUP是一种软件项目。它已经被开发出来，是可行的，但并未为并入医疗设备的目的而研发（也被称作是现成的软件），或者是之前开发的软件，为此，单有充足的开发程序的记录是不够的。系统复合组成，包括一个或者多个程序，硬件，软件，设施和人，并提供性能来满足规定的要求和目标。ISO/IEC12207:1995，定义】任务单件需要完成的工作可追溯性开发程序的两个或多个产品之间建立关系的程度。IEEE:1990】检验通过监督具体要求被满足时的目标证据来检验。注1：“检验”用于标出相应的状态ISO9000:2000，定义】注2：在设计和开发的过程中，检验关系到检查已给定活动的程序，以决定与该活动一致的规定要求。版本经鉴定的配置项的实例注1：对一个软件产品版本所做的修改，引发一个新的版本，需要软件配置管理功能。注2：基于ISO/IEC12207:1995，定义。基本要求质量管理系统医疗设备软件的生产商应当证明其有能力提供一贯满足顾客需求并且适用相关规定要求的医疗设备软件。注1：可以用符合以下规定的质量管理体系来证明此能力：ISO13485[7]；或者国家质量管理体系标准；或者国家法规所要求的质量管理体系。注2应用软件质量管理体系要求的指南可参阅ISO/IEC90003[11]。风险管理生产商应当采用符合ISO14971的风险管理程序。软件安全级别分类(a)根据软件系统对病人、操作者或者其他人由于软件系统故障所造成的伤害，生产商应当为软件系统指定一个软件安全等级(A,B或者C)。最初的软件安全等级应当按照如下的严重程度来指定：A等级：不会对健康造成损害或者伤害B等级：不会造成严重伤害C等级：可能造成严重损害甚至死亡如果按照说明操作软件系统造成的故障会引起危害，那么这种故障出现的几率应该是百分之百。如果通过硬件控制方法，由软件故障引起的死亡风险或者严重损伤随之降低到一个可接受的水平(正如ISO14971所定义的那样)，或者降低故障所造成的影响，或者降低由故障引起的那么软件安全分类可死亡风险或严重损害的几率，那么软件安全分类可以从C级到B级；如果通过硬件控制方法,由软件故障引起的非严重损害可以同样的降低到一个可以接受的水平，以从B级到A级。(b)生产商应当为对风险控制措施的实施做出贡献的软件系统评级，基于风险控制措施在掌控之中的危险可能产生的影响，为软件安全级别进行评定。(C)生产商应当在风险管理文档中用文件证明为各个软件系统所进行的安全级别评定。(d)当一个软件系统被分解成软件项目时，当一个软件项目被进一步分解成软件单元时,这样的软件单元应当继承了原软件项目(或软件系统)的安全级别分类，除非生产商用文件证明把它划分到其他软件安全类别的基本原理。这样的基本原理阐述应当解释新的软件项目是如何被隔离的，这样他它们就可以被分别分类。(e)如果软件项目的安全等级不同于分解之前软件项目的安全类别时，生产商应当用文件证明各个软件项目的安全级别分类。除非(f)为了符合本标准，在一个特定分类的软件项目需要程序的地方以及一组软件项目需要应用程序的地方，生产商应当运用该组中的最高等级的软件项目分类需要程序和任务，生产商在风险管理文件中用提供用一个较低等级分类的原理解释。（g）至于每个软件系统，应当实施C等级要求直到软件安全等级被评定。注：在下文的要求中，要求必须被实施的软件安全级别分类是按照其类别检验的。软件开发程序软件开发计划这个计划应当合乎即将要开软件开发计划生产商应当为实施软件开发程序的活动建立一个软件开发计划，发的软件系统的范围、量级和软件安全级别分类。软件开发生命周期应当被明确规定或者在计划中被引用。计划应当针对如下内容而发：a）在软件系统开发中将要用到的程序（见注4）；活动和任务可以交付使用的部分（包括文件）c）在系统需求，软件需求，软件系统测试以及在软件中所实施的风险控制措施之间的可追溯性；d）软件配置和更改管理，包括souP未知出处软件）配置项目和为支持软件开发而做的软件；以及e）在软件生命周期的各个阶段，在软件产品，可交付使用产品以及活动中发现处理问题的软件问题分辨率。A/B/C等级】注1：按照软件系统的各个软件项目的软件安全级别分类，软件开发生命周期模型可以为不同的软件系统辨别不同的组成部分（程序，活动，任务和可交付使用产品）注2：这些活动和任务能够重叠或者相互作用，也能够反复递回的运作。这并不意味着要用一个特定的生命周期模型。注3:在本标准中其他程序的描述从开发程序中分离出来。这并不意味着它们必须按照分离的活动和任务来实施。其他程序的活动和任务能够与开发程序融为一体。注4：软件开发计划可以引用现存的程序也可定义一个新的程序。注5：软件开发计划可以并入整个系统开发计划中。保持软件开发计划的更新生产商应当按照开发收益酌情更新该计划(A/B/C等级)软件开发计划所涉及的系统设计和开发(a)由于软件开发的投入，生产商应当在软件开发计划中参考系统需求。(b)为满足的要求，协调软件开发和设计开发的生效，在软件开发计划过程中生产商应当包括或参考软件开发计划过程。A/B/C等级)注：如果软件系统是一个单机系统(单一软件设备)，在软件系统需求与系统需求上可能并无差异。软件开发标准、方法和工具计划生产商应当列入或参考软件开发计划：a)标准b)方法，以及c)工具与C级软件项目的开发结合起来【C级】SOUP未知出处软软件集成与集成测试计划生产商应当包括或者参考软件开发计划。这个计划可以使软件项目(包括件)成为一体，并在融合的过程中实施检测。B/C级】注：把合并测试与软件系统测试结合为一个独立计划和活动设置是可以接受的。软件检验计划生产商应当列入或者参考软件开发计划中的如下检验信息：a)需要检验的可交付成果；每个生命周期活动所需要的检验任务；c)可交付物被检验的里程碑；和可交付物检验的验收准则。A/B/C等级】软件风险管理计划生产商应当包括或者参考软件开发计划。这个计划将实施软件风险管理程序的活动和任务，包括与souP未知出处软件)相关的风险管理。【B/C级】注：见条款7。文件材料计划生产商应当列入或者参考软件开发计划中的有关软件开发生命周期过程中引起的文件的信息。对于每一条经鉴定的文件或者文件类型，应当列入或者参考以下信息：a)标题，名字或者命名惯例；b)用途；c)文件阅读对象；以及d)开发，复审，批准以及修改的过程与责任。A/B/C等级】软件配置与管理计划生产商应当列入或者参考软件开发计划中的软件配置管理信息。软件配置管理信息应当包括-4^-b^.-tv.或者参考：a)等级，类型，分类或者需要控制的项目列表；b)软件配置管理活动和任务；c)对实施软件配置管理和活动负责的系统；d)它们与其他系统的关系，例如软件开发或维护；e)当项目需要处在配置控制之下时；以及f)当问题处理程序被应用。A/B/C等级】将要被控制的辅助项目需要被控制的项目应当包括工具、项目或者设置，用来开发医疗设备软件，这将对医疗设备软件产生影响。【B/C级】注：这类项目的样本包括编译/汇编，制作文件，批处理文件和特定的环境设置。检验之前的软件配置项目监控在检验之前，生产商应当计划把配置项目放置于备有文件证明的配置管理监控之下。级】软件需求分析从系统需求定义和用文件证明软件需求对于医疗设备的每个软件系统，生产商应该从系统水平的需求定义和用文件证明软件需求软件需求内容至于医疗设备软件，视情况而定，在软件需求中，生产商应当包括：a）功能要求和性能要求；注1样本包括：性能（例如软件的用途，时间要求）物理特性（例如代码语言，平台，操作系统）软件运行的计算机环境（例如硬件，内存大小吗，处理单元，时区，网络架构）B/C，以及对升级兼容性或多个souP（未命名软件）或其他设备版本的需求。b）软件系统输入和输出注2：样本包括：数据特征（例如，用数字表示的，文字数字式的，格式）级别，范围，以及c）软件系统和其他系统之间的接口；d）软件驱动警报，警告和操作者信息；e）安全要求；注3：样本包括：预设值与敏感信息妥协相关的；鉴定；授权；审查跟踪，以及通信完整。f)对人为误差和训练敏感的使用性工程要求；注4：样本包括与如下相关的：人工操作支持，手工设备干预；对个人的限制，以及需要人类关注的区域。注5：有关使用性工程要求的信息科参阅IEC60601-1-6。g)数据定义和数据库要求；注6：样本包括：格式；一致；功能。在操作和维护点，已交付使用的医疗设备软件安装和验收要求；i)与操作和维护方法相关的要求；j)需要被开发的用户文件资料；用户的维护要求；以及l)法规要求。A/B/C等级】注7：在软件开发初期，可能非所有要求都是可行的。注8：ISI/IEC9126-1【8】在质量特征方面提供信息，这对给软件需求下定义可能是有用的。软件需求中列入的风险控制措施制造商应在软件中列入风险控制措施的实施，由于在要求中硬件故障和软件潜在缺陷在医疗设备软件中是酌情存在的。【B/C级】注：在软件开发初期，可能非所有要求都是可行的。并且，随着软件的设计和风险控制措施的进一步定义，这些要求是可以更改的。再次评估医疗设备风险分析当软件需求确立和更新时，生产商应当酌情再次评估医疗设备风险分析。因此对软件需求分析活动升级系统需求生产商应当确保现存的要求包括系统需求被酌情再次评估和升级，也是同样。【A/B/C级】检验软件需求生产商应当检验并用文件证明软件需求：a)实施系统需求，包括与风险控制有关的；b)不要相互矛盾；c)用避免歧义的术语来表述；d)e)能够被唯一分辨；以及f)对系统需求或其它资源可追溯。用术语陈述，该术语允许建立检验标准和实施测试来决定检验标准是否曾遇见过；A/B/C级】注：本标准不需要用标准规格语言。软件体系设计把软件需求转变为一个体系用来描绘软件结构，区生产商应当把医疗设备软件需求转变成为一个备有文件证明的体系，分软件项目。【B/C级】为软件项目接口开发一个体系生产商应当为软件项目和软件项目之外的组件软件和硬件皆有)的接口，以及软件项目之间，开发和用文件证明一个体系。【B/C级】生产商应当为所有软件单元与软件单元之外的组件硬件或者软件）的接口，以及软件单元详细说明souP（未知软件项目）的功能和性能要求如果一个软件项目被定义为sou（P未知软件项目），生产商应当详细说明sou（P未知软件项目）的功能和性能要求，对于它的预期用途来说，这是很必要的。B/C级】详细说明souP（未知软件项目）的系统硬件和系统软件如果一个软件项目被定义为SOUP（未知软件项目），生产商应当详细说明必要的系统硬件和系统软件来辅助SOUP（未知软件项目）的适当操作。【B/C级】注：样本包括处理器类型和速度，内存类型和大小，系统软件类型，通讯软件和显示软件需求。分辨必要的风险控制隔离生产商应当分辨出对风险控制不可或缺的软件项目及怎样保证隔离状态的有效。【C级】注：隔离样本是使得软件项目在不同处理器上实施任务。隔离的有效性能够通过处理期间无共享资源来保证。检测软件体系生产商应当检测并用文件证明如下内容：a）软件体系实施系统和软件需求，包括与风险控制相关的要求；b）软件体系能够支持软件项目之间、软件项目与硬件项目之间的接口；以及c）医疗设备软件支持任何SOUP（未知软件项目）的正确操作。B/C级】软件详细设计把软件体系细化为软件单元生产商应当细化软件体系知道它以软件单元的形式出现。B/C级】为每一个软件单元开发详细设计生产商应当为每一个软件项目的软件单元开发一个详细设计并用文件证明。【C级】为接口开发详细设计之间的接口开发一个详细设计并用文件证明。【c级】检测详细设计生产商应当检测软件详细设计并用文件证明：a)实施软件体系；以及b)不与软件体系相互冲突。【c级】软件单元的实施和检验实施各个软件单元生产商应当实施各个软件单元。【A/B/c级】建立软件单元检验程序生产商应当为检验检测各个软件单元建立策略方法和步骤。当通过测试完成检测时，应当为其正确性而评估测试过程。【B/c级】注：验收标准样本为：软件编码实施要求包括风险控制措施吗？软件编码与软件单元中所详细设计并用文件证明的接口相互冲突吗？软件编码符合项目过程或者编码标准吗？保证软软件单元验收标准在软件单元整合到较大的软件项之前，生产商应该适当的为软件单元建立验收准则，件单元符合验收标准。增加软件单元验收标准当以下项目出现在设计之中时，生产商应当酌情列入增加的验收标准：a)正确的时间顺序;数据流和控制流；c)有计划的资源分配；故障处理(错误鉴定，隔离与修复)生产商应当完成软件单元检测并用文件证明其结果。B/C级】e）变量初始化；f）自我诊断；g）记忆管理与记忆溢出；以及h）边界状态。【c级】软件单元检验软件集成和集成测试B/C级】一体化软件单元生产商应当使软件单元一体化以与集成计划（见）一致【检测软件集成生产商应当按照集成计划，检测并记录软件集成的以下方面（见）a）软件单元应当整合集成为软件项目和软件系统；以及b）系统的硬件项目，软件项目以及人工操作辅助项目（例如人类特征接口，在线帮助菜单，声音控制等）已被集成入该系统。B/C级】注：检测仅指项目已经按照计划集成化，非他们按照意愿所作的。这个检测很有可能是由某种形式的检查实施的。B/C级】测试组合软件生产商应当按照集成计划（见）来测试组合软件项目并用文件证明其结果。集成测试内容至于集成测试内容，生产商应当注重组合软件项目是否是按预期运转。B/C级】注1样本应当被当作：软件的功能性需要；风险控制措施的实施；规定的时间和其它行为；规定的内外接口功能；以及在非正常状态下的测试，包括可预见的误用。注2把集成测试与软件系统测试结合成一个单独计划和活动是可行的。检测集成测试步骤生产商应当评估集成测试步骤的正确性。B/C级】b）保留足够的记录以能够重复检测；以及c）确定检测者。实行复原测试当软件项目已集成，生产商应当酌情实行复原测试以证明之前缺陷并未被引进入结合软件中。【B/C级】集成测试记录内容生产商应当a）用文件证明测试结果（合格/不合格以及异常现象列表）B/C级】注；要求（b）可以通过保持以下信息来实施，例如:检测案例规格所显示的要求动作和所期望的结果；装备记录；测试环境记录（包括软件工具）。运用软件疑难解答程序B/C级】生产商应当从软件集成和集成测试过程中发现的异常情况进入软件疑难解答程序。注:见条款9软件系统测试为软件需求设置测试生产商应当设置和实行一系列测试，以输入刺激，预期结果，符合/不符合标准和过程来表示，用以实施软件系统测试，这样所有的软件需求被覆盖。B/C级】注1：把集成测试与软件系统测试结合成一个单独的计划和活动是可接受的。在早期测试软件需求也是可行的。注2：不仅对每个要求的分开测试是可实施的，而且所有要求联合的测试也是可行的，特别是如果各个要求之间独立性存在时。运用软件疑难解答程序生产商应当从软件系统测试中发现的异常现象进入软件疑难解答程序。B/C级】更改之后的再次测试当软件系统测试出现更改时，生产商应当：a)酌情展开重复测试，展开修改过的测试或展开新增测试，以修正问题所带来的改变的有效性；酌情展开测试来证明没有引来非预期负面影响；以及c)按照所定义的，展开相关风险管理活动。检测软件系统测试生产商应当检测以下内容：a)所采用的检测策略和测试过程是合适的；所有的软件需求已经被测试过或者被检测过；以及c)测试结果符合所要求的合格/不合格标准。B/C级】软件测试记录内容生产商应当：a)用文件证明测试结果(合格/不合格以及异常情况列表)保留足够记录以能够重复检测，以及c)检验测试者。B/C级】注;要求(b)可以通过保持以下信息来实施，例如：生产商应当设定步骤来确保已发布的软件产品能够不被损坏与非法更改，并确实被交付至使检测案例规格所显示的要求动作和所期望的结果；装备记录；测试环境记录(包括软件工具)。软件发布B/C级】保证软件检测是完整的在软件发布之前，生产商应当确保软件检验已完成、结果已被评估。用文件证明已知的残留异常情况生产商应当用文件证明所有已知的残留异常情况。B/C级】评估已知的残留异常情况生产商应当确保所有已知的残留异常情况都已经被评估，以确保它们不会引起不可接受的风险。【B/C级】用文件证明已发布的版本生产商应当用文件证明即将发布的软件产品的版本，A/B/C级】用文件证明已发布软件是如何创作的生产商应当用文件证明用来创作此已发布软件的过程和环境。B/C级】确保活动和任务是完整的生产商应当确保所有的活动和任务以及所有相关的文件是完整的。B/C级】把软件存档生产商应当把以下信息存档：a)软件产品和配置项目；以及b)文件材料最短保存期限由以下时间长度来决定：生产商所定义的设备寿命，或者由相关法规要求所规定的时间。【B/C级】保证软件发布的可重复性用处。这些步骤应当酌情强调列入软件产品的媒体处理和产品：反响，媒体标签，包装，保护措施，储藏，以及，交付使用。B/C级】软件维护程序建立软件维护计划这个计划应当表达出如下生产商应当建立一个软件维护计划来实施维护程序的活动和任务。信息：(a)……的步骤:—接收，用文件证明，评估，解决，追踪在医疗设备软件发布之后出现的反馈；决定反馈是否被认作是一个问题的标准；c)软件风险管理程序的应用；软件疑难解答程序的运用，以分析和解决医疗设备软件发布后出现的问题；e)软件配置管理程序(条款8)的运用，以管理对现存系统的修改；以及评估和实施的步骤；SOUP(未知软件项目)的—升级，漏洞修补，修补程序，老化。A/B/C级】问题分析与修改分析用文件证明并评估反馈监控器反馈生产商应当监控来自从其组织内部和用户处的关于已发布产品的反馈。用文件证明并评估反馈所有类似问题都反馈应当用文件证明并被评估以确定已发布的软件产品中是否有问题存在。应当被记录成问题报告（见条款9）。问题报告应当包括实际存在和潜在的不良事件以及规格偏差。【A/B/C级】以及为解决此评估问题报告对安全性产生的影响每个问题报告都应当被评估来确定它是怎样影响到已发布软件产品的安全性，问题对已发布软件产品做出更改是否有必要。A/B/C级】运用软件疑难解答程序生产商应当运用软件疑难解答程序（见条款9）来解决问题报告。【A/B/C级】注：当活动完成，软件系统或软件项目安全级别的任何变更都需要被通报。分析变更需求除条款9所要求的分析外，生产商应当分析各个变更请求对组织，已发布软件产品，相互作用的各系统所产生的影响。【B/C级】变更请求批准生产商应当评估并批准修改已发布产品的变更请求。A/B/C级】与用户和调整者沟通生产商应当确定已批准的对已发布软件产品产生影响的变更请求。按当地法规要求，生产商应当通知用户和协调者以下内容：a）软件产品中的所有问题以及持续无更改将带来的后果；以及b）所有对已发布软件产品的可行改变的性质以及怎样获得和安装更改之处。A/B/C级】修改之处的实施运用已制定的程序来实施修改之处生产商应当用软件开发程序（见条款5）或一个已制定的维护程序来实施这些修改之处。A/B/C级】注:关于软件更改的风险管理要求请看。再次发布已修改的软件系统生产商应当按照来发布已修改的软件系统。条款修改可以作为重新发布的软件系统的一个部并作为对现存分，或者作为列入已更改的软件项目和必要工具的修改组件来安装更改之处，软件系统的修改条款。【A/B/C级】7软件风险管理程序对导致危险情形的软件进行分析辨别能够导致危险情形的软件项目生产商应当辨别在ISO14971（见）医疗设备风险分析活动所检验的能够导致危险情形的软件项目。【B/C级】注：危险情形可能成为软件失败的直接结果，或者是在软件中实施风险控制程序失败的直接结果。辨别潜在的导致危险情形的原因生产商应当辨别上面所检验的软件项目潜在的导致危险情形的原因。生产商应当酌情考虑包括以下内容在内的潜在原因：a）不正确或不完整的功能规格；在已检验软件项目功能上的软件缺陷；c）会导致不可预知的软件操作的硬件故障或软件缺陷；以及适度、可预见的误用B/C级】评估已发布的SOUP（未知软件项目）的异常列表如果来自SOUP未知软件项目）的故障或者预料之外的结果是导致危险情形的软件项目的潜在原因，生产商应当把由提供者或者与未知软件项目相关的应用于医疗设备未知软件项目的任何异常列表当作最大化评估，来确定是否所有已知异常会引起导致危险情形一系列事件。B/C级】用文件证明潜在原因生产商应当在风险管理文件中用文件证明导致危险情形的软件项目的潜在原因。用文件证明事件结果生产商应当在风险管理文件中用文件证明会导致危险情形的事件（所定义的）结果。B/C级】风险控制措施明确风险控制措施对于每一个在风险管理文件中所记录的导致危险情形的软件项目的潜在原因，生产商应当明确并用文件证明风险控制措施。【B/C级】软件中实施的风险控制措施如果一个风险控制措施是作为一个软件项目的一个功能部分，生产商应当：a）在软件需求中列入软件控制措施；b）基于风险控制措施正在控制的风险可能会产生的影响，为软件项目设定一个安全级别；以及c)开发一个与条款5一致的软件项目。B/C级】注：这个要求为ISO14971风险控制要求提供新增的细节风险控制措施的检验检验风险控制措施在中用文件证明的各个风险控制措施的实施应当被检验，且批准核对案件应当用文件证明。B/C级】用文件证明所有新的事件结果B/C级】如果风险控制措施是作为一个软件项目运行，那么生产商应当评估风险控制措施来检验所有新的能够导致危险情形的事件影响，并在风险管理文件中用文件证明。用文件证明可追溯性生产商应当酌情用文件证明软件危险障碍的可追溯性：a)从危险情形到软件项目；从软件项目到具体软件原因；c)从软件原因到软件控制措施；以及d)从风险控制措施到风险控制措施的检验。B/C级】注：见ISO14971—风险管理报告软件更改的风险管理对医疗设备软件安全性更改的分析生产商应当对医疗设备软件(包括未知软件项目)的更改进行分析以确定是否：a)新增潜在原因被引入是造成危险情形的部分原因；以及b)新增软件风险控制措施是被需要的。A/B/C级】分析软件更改对现存风险控制措施产生的影响生产商应当分析软件更改，包括对未知软件的更改，以确定软件修改是否可能与风险控制措施相抵触。【B/C级】基于分析的风险管理活动生产商应当基于分析的基础上，执行定义在,及里相关的风险管理活动。8软件配置管理措施配置确认建立检验配置项目的方法生产商为唯一的配置项目以及为计划将要被控制的版本建立一个计划。计划应当包括其他软件产品或者实体例如未知软件项目和文件材料【A/B/C级】检验未知软件项目对每个正在使用中的软件项目来说，包括标准函数库，生产商都应当用文件证明(a)标题(b)生产商；以及(c)唯一的未知软件项目指定者检验系统配置文件材料生产商应当用文件证明这套配置项目和它们列入软件系统配置的版本。A/B/C级】变更控制批准变更要求生产商应当只有在响应已批准的变更请求的情况下更改配置项目。A/B/C级】注1：批准一个变更请求的决定可以与控制程序的更改相结合或者作为另一程序的一部分。分条款只要求变更的批准先于它的实施。注2：在生命周期的不同阶段，不同的验收标准可以用于不同的变更请求，正如计划中所陈述的那样，见(e)与(e).实施变更内容生产商应当按照变更请求的规定实施变更内容。生产商应当检验并实施由于更改需要重复的活动，包括软件系统软件安全级别的更改和软件项目软件安全级别的更改。A/B/C级】注：分条款规定更改应当如何被实施以获得足够的变更控制。这不仅意味着实施是变更控制程序的主要部分。实施该变更应当运用计划的程序，见(e）与（e）o验证变更的内容生产商应该验证任何变更，包括任何已被重复验证失效的变化，并考虑到和为例。为变更的可追溯性提供方法生产商应当通过以下各个方法创作审查跟踪：a)变更请求；b)相关问题报告；以及c)变更要求的批准A/B/C级】问题报告应当按照如下步骤这些都能够被追踪到。【A/B/C级】配置状况说明生产商应当保留被控制配置项目包括系统配置的可检索历史记录。9软件疑难解答程序准备问题报告生产商应当为在软件产品中所发现的每一个问题准备问题报告。进行分类：a)类型例1对新环境矫正，预防或者适应b)范围；以及例2更改的尺寸，受影响的设备类型的数目，受影响的辅助附件，所列入的资源，需要修改的时间c)危急程度例3对性能、安全或安全性所产生的影响A/B/C级】注：问题可以在软件发布之前或之后在生产商机构内外被发现。调查问题生产商应当：a)调查问题，如果有可能的话，检验引起的原因；运用软件风险管理程序评估与安全问题相关的问题；条款7)c)用文件证明调查和评估的结果；以及为有需要的行为创建一个更改请求来纠正此问题，或用文件证明不作为的原理解释。A/B/C级】注：如果一个问题不涉及安全方面，那么对生产上来说没有必要按照软件疑难解答程序来纠正它。对相关部门提出建议生产商应当酌情对有关部门就现存的问题提出建议。A/B/C级】(见)。【A/B/C级】运用变更控制程序生产商应当批准并实施所有的更改请求，遵守变更控制程序。保留记录生产商应当保留问题报告和包括检验在内的解决方法。生产商应当酌情更新风险管理文件。(见)【A/B/C级】分析发展趋势的问题生产商应当进行分析来发现问题报告的发展趋势。A/B/C级】检验软件问题决议生产商应当检验决议来决定是否：a)问题已经得到解决，问题报告已经结束；不良发展趋势已经被扭转；c)在合适的软件产品和活动中，更改要求已经得到实施；以及新增问题已经被引入。A/B/C级】检测文件材料内容当根据一个更改对回归测试软件项目进行检测，再检测时，生产商应当在检测文件材料中列入以下内容：a)测试结果；b)异常发现；c)所测试软件的版本；d)相关硬件和软件测试配置；e)测试日期；以及f)测试者的检验。A/B/C级】附录A资料性附录）关于本标准的要求的基本原理在此附录中此标准的条款的基本原理。基本原理本标准的基本要求是医疗设备软件开发和维护随之而来的一系列程序以及程序的选择适于避免对病人和其他人的风险。这个是由软件测试不足以判定在操作中它是安全的看法得出的。本标准所要求的程序分成两类：在软件中需要用来确定各个软件项目操作中的风险的程序；在已确定的风险的基础上选择，需要为各个软件项目实现相称的低软件故障率的程序。这个分析检验了可预见的事件的结本标准要求第一类为所有的医疗设备软件服务，第二类为指定的软件项目服务。符合本标准的专利申请应当包括用文件证明的风险分析，果，这些事件包括软件可能导致危险情形（见ISO14971）。可能直接由软件引起的危险应当A/B/C级】，这就意味着它们包括在风险分析中。例如，提供可能导致不恰当治疗的误导信息。所有被当作第一种程序的一部分的活动在标准文本里被称作【与所应用的软件的分类是无关的。由于以下原因，活动被A/B/C级所需要：活动能够引起与风险管理或者软件安全分类相关的计划；活动能够引出输出信息，该输出信息可作为风险管理或软件安全分类的输入信息；活动是风险管理或软件安全分类的一部分；活动建立了管理系统，文件资料或者记录保留系统，它们有助于风险管理或者软件安全分类；当相关软件的分类未知时，活动通常发生；活动会引起变更，这个变更可以使相关软件的当前软件安全分类失效。它包括软件发布后的相关安全分析问题。其它程序只被宰软件安全分类中B或C级的软件系统或者软件项目需要。活动被当做程序的部分而被需要，这些程序在正规文本中被检验为B/C级或者C级，这就意味着它们被选择性的需要，而此需要取决于它们将要应用的软件的类别。活动被B/C级的软件所选择性需要的原因如下:通过要求更细致更精确的设计，测试或其它检测，活动增强了软件的可靠性;活动是一个管理的活动，它辅助B/C级所要求的活动;活动辅助与安全相关的问题的纠正;活动引出设计记录，实施记录，检测记录以及与安全相关的软件的记录。活动被C级软件选择性需要时由于以下原因:在设计、测试或者其他检测上，通过要求更细致、更精确或者对具体问题的关注的方法,活动可以更进一步增强软件的可靠性。注意：在本标准中，所有的程序和活动在确定高质量软件的开发和维护中都是有价值的。些过程和活动的许多人物作为A级软件的要求,虽然A级软件根据定义不能引发危险，但这并不意味着这些程序和活动无价值或者不被推荐。它们的任务是，通过医疗设备的设计过程中的全部检验活动和一些简单的软件生命控制,来检验不会引起危险情形的软件能够容易的被肯定其安全性和有效性。等级要求总结表总结了软件安全等级所指定的各个要求。这个表是资料性记录，只为提供方便而作。正规部分检验了软件安全等级的各项要求。表一软件安全等级要求总结条款和分条款A级B级C级条款4所有的要求XXX，，，，，XXX????????所有要求XX所有要求XX??????XXX???所有要求XXX所有要求XX所有要求XX所有要求XX条款8所有要求条款9所有要求XXX附录B资料性附录）对本规定条款的指导范围目的为实现这个目的，本标准本标准的目的是提供一个始终生产高质量的安全软件的开发程序。检验了最小的活动和任务，这些活动和任务的完成是用来提供信心的，这个信心就是软件已经由某种可能生产出高度信赖和安全的软件产品的方式被开发了。本附录为本标准要求的应用提供了指导方法。它并不对本标准进行增添或者更改，而是用来使读者更好的理解本标准的要求。注：在本标准中活动是在活动范围内定义的程序和任务所引出的分条款。例如，为软件开发软件单程序下定义的活动是软件开发计划，软件需求分析，软件架构设计，软件详细设计，元安装启用与检测，软件集成与集成测试，软件系统测试和软件发布。在这些活动内的任务是个性化需求。本标准不需要一个特别的软件开发生命周期模型。然而，符合本标准意味着程序间相互依赖，因为一个程序的输入信息来自另外一个程序。例如，软件系统的软件安全分类的完成应当在风险分析程序已经检验软件系统故障会引起什么样的危害之后。由于这种程序间的逻辑依赖关系，按顺序描述本标准中的程序是很容易的，隐含一个瀑布似的或者直流的生命周期模型。然而，其它生命周期也能够被应用。一些在ISO/IEC12207【9】中所定义的开发（模型）策略包括（也可见表）瀑布策略：直流策略，也叫做瀑布策略，包括一次完成开发程序。简单来说就是：确定消费者需求，定义要求，设计系统，完成系统，测试，安装和交付使用。增值策略：增值策略确定消费者需求，定义系统需求然后一系列构造的剩余开发。第一个构造包含部分计划性能，接下来的构造将曾加更多计划性能，诸如此类，直到系统完成。渐进策略：渐进策略同样在构造中开发系统，但是与增值策略的不同之处在于：检验用户需求没有被完全理解和所有要求不能作为前提方面。在这个策略中，消费者需求和系统需求被部分当作前提，然后再被各个随后的构造改善。表一在ISO/IEC12207中所定义的开发（模型）策略开发策略首先定义所有要求吗？多重开发周期？分配临时软件？瀑布策略（直流型策略）是否否增值策略（预先计划的产品改进）是是可能渐进策略否是是当生命周期已经选择，维护程序输出信息之间的逻辑依赖关系是必要的，例如规格，设计文件和软件。瀑布生命周期模型通过延长程序的启动直至程序输入信息的完成和批准来实现。其他的生命周期，特别是渐进策略生命周期，允许输出信息在程序所需所有输入信息完分类、成之前产出。例如，一个新的软件项目在整个软件架构完成之前可以被详细说明、完善和检测。这样的生命周期也会带来风险，例如一个程序输出信息的更改或者开发会导致另一个程序输出信息无效。因此所有的生命周期运用一个综合配置管理系统来保证所有的程序产出被引入一致状态并且相互依赖性可以得到维持。不管软件开发生命周期有没有使用，以下原则是很重要的:所有的程序产出信息应当保持一致状态；无论任何时候任何软件的产出信息得到创作或者改变时，所有相关程序产出都应当被迅速更新以维持彼此间的协调性，并维持本标准所需要的明确或含蓄的依赖关系;当被需要时，所有程序输出信息应当可用做软件进一步工作的输入信息。在任何医疗设备软件发布之前，所有的程序产出应当彼此间相一致，所有本标准所需要的明确或含蓄的程序产出之间的依赖关系应当被遵守。应用范围本标准应用于医疗设备软件的开发和维护，也同样用于包含有未知软件项目的医疗设备的开发和维护。本标准的运用要求生产商实施符合ISO14971的医疗设备风险管理文件。因此，当医疗设备系统架构包括一个后来得到的部件（它可能是一个买来的部件或者是一个不明出处的部件）例如包含有未知软件项目的打印机或者绘图机，后来得到的部件成为生产商的责任并且必须包含在医疗设备的而风险管理中。假定通过按规定实施医疗设备风险管理程序，生产商将了解部件并且识别出它包含有未知软件项目。生产商运用本标准将造成软件风险管理程序成为医疗设备风险管理程序的一部分。已发布医疗设备软件的维护适用于医疗设备软件后期制作经验。软件维护包括所有技术手段和管理手段的结合，包括监督行动来对问题报告产生作用以把项目保持在或者还原到一个状态，在这个状态中，它能够实施已发布软件产品相关的功能以及修改要求。例如，这个包括问题批准，法规报告，再次检验或者阻止行动。见ISO//IEC14764【10】。正规参考文献ISO/IEC80003【11】为应用质量管理系统到软件开发提供了指导。这个指导性文件不是本标准所必须的但却是强烈推荐的。术语和定义术语尽可能用国际标准中的定义被定义。本标准选择运用三个属于来描述软件系统（最高级别）的分解。软件系统可以说是医疗设备可以被称作软件见IEC60601-1-4【2】）的子系统或者本身是医疗设备。最低层不能够再为软件配置管理测试的目的而分解的是软件单元。所有层次的组合，包括最高层和最低层，各个软件项目是由一个或者多个项目。那么，软件系统就是一个或者多个软件项目的组合，软件单元或不可分解的软件项目组成的。留给生产商的责任是为软件项目和软件单元提供解释和间隔尺寸。这些术语的模糊不清使得在医疗设备中，人们可以把它们应用到许多不同的软件开发方法中。基本要求对任何软件都没有已知方法来保证100%的安全。就提升医疗设备安全性而言，有三个主要原则风险管理；质量管理；软件工程。对于安全的医疗设备软件的开发与维护而言，建立风险管理程序是很有必要的，此程序可作为质量管理体系的有机组成部分，而该系统可作为合适的软件工程方法和技术应用的整体框连贯重复的决策过程来推动医疗基础设施、改进和训练。为避免架。这三个概念的结合使得医疗设备生产商根据架构清楚，设备安全性的提高。质量管理系统一个缜密有效地软件程序组合包括有组织的程序例如管理、重复以及以标准的重点放在软件工程上，这些程序已被本标准删除。这个程序是由一个质量管理系统所覆盖的。ISO13485【7】是一个国际标准，它专门适用于医疗设备质量管理概念。符合ISO13485质量管理体系的要求并不自动包含符合国家或地区法规的要求。检验和建立符合相关法规要求的系统是生产商的责任。风险管理软件开发充分参与风险管理活动以确保所有合理且