标准搜索结果: 'YY/T 0664-2008'
| 标准编号 | YY/T 0664-2008 (YY/T0664-2008) | | 中文名称 | 医疗器械软件 软件生存周期过程 | | 英文名称 | Medical device software - Software life cycle processes | | 行业 | 医药行业标准 (推荐) | | 中标分类 | C30 | | 国际标准分类 | 11.040 | | 字数估计 | 60,636 | | 发布日期 | 2008-04-25 | | 实施日期 | 2009-06-01 | | 引用标准 | YY/T 0316 | | 采用标准 | IEC 62034-2006, IDT | | 标准依据 | 国食药监械[2008]192号 | | 发布机构 | 国家食品药品监督管理局 | | 范围 | 本标准规定了医疗器械软件的生存周期要求。在本标准中描述的一组过程、活动和任务, 为医疗器械软件生存周期过程建立了共同的框架。本标准适用于医疗器械软件的开发和维护。 | YY/T 0664-2008: 医疗器械软件 软件生存周期过程
YY/T 0664-2008 英文名称: Medical device software - Software life cycle processes
中华人民共和国医药行业标准
医疗器械软件 软件生存周期过程
国家食品药品监督管理局 发 布
１ 范围
１．１ 目的
本标准规定了医疗器械软件的生存周期要求。在本标准中描述的一组过程、活动和任务，为医疗器
械软件生存周期过程建立了共同的框架。
１．２ 应用范围
本标准适用于医疗器械软件的开发和维护。
当软件本身是医疗器械，或当软件是最终医疗器械的嵌入部分或组成部分时，本标准适用于该医疗
器械软件的开发和维护。
本标准不覆盖医疗器械的确认和最终发行，即使当该医疗器械完全由软件组成时。
１．３ 与其他标准的关系
在开发医疗器械时，本医疗器械软件生存周期标准和其他适用的标准共同使用。本标准和其他相
关标准之间的关系见附录Ｃ所示。
１．４ 符合性
符合本标准意指按照软件安全性级别，实施在本标准中确定的所有过程、活动和任务。
注：对每项要求所赋予的软件安全性级别在标准要求之后的正文中确定。
用检查本标准所要求的所有文档（包括风险管理文档和对软件安全性级别所要求的过程、活动和任
务的评定）的方法来确定符合性。见附录Ｄ。
注１：此种评定可以由内部的或外部的审核来实现。
注２：即使规定了要完成的过程、活动和任务，实施这些过程和执行这些活动和任务的方法是灵活的。
注３：在任何包含“适当时（ａｓａｐｐｒｏｐｒｉａｔｅ）”的要求没有完成时，为说明理由而形成文档对于本评定是必要的。
注４：本标准中用术语“符合（ｃｏｍｐｌｉａｎｃｅ）”的地方，GB/T ８５６６中用术语“符合（ｃｏｎｆｏｒｍａｎｃｅ）”。
２ 规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有
的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究
是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。
ＹＹ/T ０３１６ 医疗器械 风险管理对医疗器械的应用（ＹＹ/T ０３１６-２００８，ISO １４９７１：２００７，ＩＤＴ）
３ 术语和定义
下列术语和定义适用于本标准。
４ 总要求
４．１ 质量管理体系
医疗器械软件制造商应证实其有能力提供持续满足顾客和适用的法规要求的医疗器械软件。
４．２ 风险管理
制造商应使用符合ＹＹ/T ０３１６的风险管理过程。
４．３ 软件的安全性级别
ａ） 制造商应按照软件系统引起的危害对于患者、操作者或其他人员的可能影响，赋予每个软件系
如果危害可能由软件系统未能象规定的那样起作用引起，则此项失效的概率应假定为１００％。
如果软件失效引起死亡或严重伤害的风险，随后由硬件风险控制措施降低到可接受水平（如
ＹＹ/T ０３１６所规定），或者降低失效后果或者降低由失效引起的死亡或严重伤害的概率，软件安全性级
别可从Ｃ降低到Ｂ；如果软件失效引起的非严重伤害风险同样通过硬件风险控制措施降低到可接收水
平，软件安全性级别可从Ｂ降低到Ａ。
ｂ） 制造商应依据风险控制措施所控制的危害的可能影响，对实施风险控制措施起作用的每个软
件系统赋予一个软件安全性级别。
ｃ） 制造商应在风险管理文档中将赋予每个软件系统的软件安全性级别形成文档。
ｄ） 当一个软件系统分解为软件项，及当一个软件项又进一步分解为几个软件项时，此类软件项
应继承原软件项（或软件系统）的软件安全性级别，除非制造商以文件形式证明分类为不同的
安全性级别的理由。此类理由说明应解释新的软件项是如何被分开的，以便可对其另行分级。
ｅ） 如果以分解方式产生的软件项的安全级别和其源软件项不同，制造商应对每个软件项的软件
安全级别形成文档。
ｆ） 为符合本标准，无论特定级别的软件项是否需要一个过程，此过程是否有必要应用于一组软件
项，制造商应使用此组中最高级别的软件项所要求的诸过程和任务，除非制造商在风险管理文
档中有使用较低级别的理由的说明文件。
ｇ） 对每个软件系统，在赋予软件安全性级别以前，均应应用Ｃ级要求。
注：在随后的要求中，对该项要求必须实施的软件安全性级别，以［级］形式标示于该要求之后。
５ 软件开发过程
５．１ 软件开发策划
５．１．１ 软件开发计划
制造商应制定一项（或多项）软件开发计划，以便实施适合于所开发软件系统的范围、规模和软件安
全性级别的软件开发过程的活动。在一个（或多个）计划中应完整地规定或引用软件开发生存周期模
型。计划应说明下列各项：
ａ） 用于软件系统开发的过程（见注４）；
ｂ） 各项活动和任务的交付物（包括文件）；
ｃ） 系统需求、软件需求、软件系统测试和在软件中实施的风险控制措施之间的可追溯性；
ｄ） 软件配置和更改管理，包括未知来源软件配置项和用于支持开发的软件；和
ｅ） 在生存周期每个阶段的软件产品、交付物和活动中发现的用于处理问题的软件问题解决方案。
５．１．２ 保持软件开发计划更新
在适当时，制造商应在开发进行的同时更新计划。
５．１．３ 引用系统设计和开发的软件开发计划
ａ） 制造商应在软件开发计划中引用系统需求，作为软件开发的输入。
ｂ） 制造商应在软件开发计划中包括或引用用于协调软件开发和为满足４．１必需的设计开发确认
的规程。
５．１．４ 软件开发标准、方法和工具的策划
制造商应在软件开发计划中包括或引用和Ｃ级软件项的开发有关的：
ａ） 标准；
ｂ） 方法，和；
ｃ） 工具。
［Ｃ级］
５．１．５ 软件集成和集成测试策划
制造商应在软件开发计划中包括或引用一项计划，以集成软件项（包括未知来源软件ＳＯＵＰ）并在
集成过程中完成测试。
５．１．６ 软件验证策划
制造商应在软件开发计划中包括或引用下列验证信息：
ａ） 需要验证的交付物；
ｂ） 每个生存周期活动所要求的验证任务；
ｃ） 对交付物进行验证的里程碑；和
ｄ） 验证交付物的验收准则。
５．１．７ 软件风险管理策划
制造商应在软件开发计划中包括或引用实施软件风险管理过程的活动和任务的计划，包括与未知
来源软件有关的风险的管理。
５．１．８ 文档策划
制造商应在软件开发计划中包括或引用有关在软件开发生存周期中所形成文档的信息。对每个已
识别的文档或文档类型，应包括或引用如下信息：
ａ） 标题、名称或命名约定；
ｂ） 目的；
ｃ） 文件的预期阅读者；和
ｄ） 开发、评审、批准和修改的程序和职责。
５．１．９ 软件配置管理策划
制造商应在软件开发计划中包括或引用软件配置管理信息。软件配置管理信息应包括或引用：
ａ） 受控项目的级别、型式、类别或清单；
ｂ） 软件配置管理活动和任务；
ｃ） 负责进行软件配置管理和活动的组织；
ｄ） 它们和其他组织的关系，诸如软件开发或维护
ｅ） 当将这些项目处于配置控制之下时；和
ｆ） 何时应用问题解决过程。
５．１．１０ 受控的支持项
受控项应包括用于医疗器械软件开发并对其有影响的工具、项目或设置。
注：此类项目的示例包括编译器／汇编器版本，生成文件，批文件和特定的环境设置。
５．１．１１ 验证前的软件配置项的控制
制造商应计划在验证软件配置项之前，使其处于形成文档的配置管理控制之下。
５．２ 软件需求分析
５．２．１ 由系统需求确定软件需求并形成文档
对每个医疗器械软件系统，制造商应从系统层面需求中确定软件系统需求并形成文档。
５．２．２ 软件需求内容
在适用于医疗器械软件，制造商应在软件需求中包括：
ａ） 功能和能力需求；
ｂ） 软件系统的输入和输出；
ｃ） 软件系统和其他系统之间的接口；
ｄ） 软件控制的报警、警告和操作者信息；
ｅ） 保密安全需求
ｆ） 对人为错误敏感的适用性工程要求和培训；
ｇ） 数据定义和数据库需求；
ｈ） 对已交付的医疗器械软件在操作和维护的一个或多个地点的安装和验收要求；
ｉ） 与操作和维护方法有关的要求；
ｊ） 要编制的用户文档；
ｋ） 用户维护要求；和；
ｌ） 法规要求。
５．２．３ 在软件需求中包括风险控制措施
制造商应将在软件中所实施的对于硬件失效和潜在软件缺陷的风险控制措施包括在适合于医疗器
械软件的要求中。
５．２．４ 医疗器械风险分析的再评价
制造商应在制定并适当更新软件需求时，对医疗器械风险分析进行再评价。
５．２．５ 更新系统需求
制造商应确保对现有的需求（包括系统需求）进行再评价和适当时更新，作为软件需求分析活动的
结果。
５．２．６ 验证软件需求
制造商应对软件需求进行验证并形成文档：
ａ） 实施包括有关风险控制在内的系统需求；
ｂ） 需求不互相矛盾；
ｃ） 避免使用含糊不清的术语表示；
ｄ） 用表述的术语来制定测试准则和实施测试，以确定是否满足测试准则；
ｅ） 可以进行唯一性标识；和；
ｆ） 对于系统要求或其他来源是可追溯的。
５．３ 软件体系结构设计
５．３．１ 将软件需求转换为体系结构
制造商应将对医疗器械软件的需求转换为描述软件结构和标明软件项的形成文档的体系结构。
５．３．２ 为软件项接口开发体系结构
制造商应为软件项和软件项外的组件（软件和硬件）之间，以及软件项之间的接口开发一个体系结
构并形成文档。
５．３．３ 规定SOUP项目的功能和性能需求
如果软件项被识别为ＳＯＵＰ，制造商应规定ＳＯＵＰ项目预期用途所必需的功能和性能需求。
５．３．４ 规定SOUP项目所要求的系统硬件和软件
如果软件项被识别为ＳＯＵＰ，制造商应规定为支持ＳＯＵＰ项目正常运行所必需的系统硬件和
软件。
５．３．５ 判定风险控制所必需的隔离
制造商应判定风险控制所必要的软件项之间的隔离，并说明如何确保隔离有效。
５．３．６ 验证软件体系结构
制造商应验证下列各项并形成文档：
ａ） 软件体系结构实现包括与风险控制有关的系统和软件需求；
ｂ） 软件体系结构能支持软件项间和软件项与硬件之间的接口；和
ｃ） 医疗器械体系结构支持任何ＳＯＵＰ项目的正常运行。
５．４ 软件详细设计
５．４．１ 将软件体系结构细化为软件单元
制造商应细化软件体系结构直至其表现为软件单元。
５．４．２ 为每个软件单元开发详细设计
制造商应对软件项的每个软件单元开发详细设计并形成文档。
５．４．３ 为接口开发详细设计
制造商应对软件单元和外部组件（硬件或软件）之间的任何接口、以及软件单元之间的任何接口开
发详细设计并形成文档。
５．４．４ 验证详细设计
制造商应验证软件详细设计的下列各项并形成文档：
ａ） 实现软件体系结构；和
ｂ） 不和软件体系结......
|