射频治疗仪-PEMS开发生命周期（GB 9706.1-2020）.docx
《射频治疗仪-PEMS开发生命周期（GB 9706.1-2020）.docx》由会员分享，可在线阅读，更多相关《射频治疗仪-PEMS开发生命周期（GB 9706.1-2020）.docx（13页珍藏版）》请在冰点文库上搜索。
文件编号：
版本：
射频治疗软件
PEMS开发生命周期说明
（适用软件型号：
）
编制：
日期：
审核：
日期：
批准：
日期：
目录
1前言 5
1.1PEMS开发生命周期编制依据 5
1.2引用标准列表 5
2目的 5
3术语和定义 5
4软件基本信息 5
5软件安全性级别 6
5.1安全等级判定准则和要求 6
5.2软件安全性级别 7
6遗留软件 7
7软件开发过程 7
7.1软件设计开发策划 7
8软件维护过程 8
8.1软件维护流程 9
8.2角色和责任 10
9软件风险管理 10
10软件配置管理过程 10
10.1软件配置管理活动和任务 11
10.2配置更改控制 12
11软件问题解决过程 13
11.1编写问题报告 13
11.2调查问题 13
11.3通知相关方 13
11.4使用变更控制过程 13
11.5保持记录 13
11.6分析问题的趋势 13
11.7验证软件问题的解决 13
11.8测试文档的内容 14
12结论 14
13附录 15
1前言
1.1PEMS开发生命周期编制依据
该PEMS文档适用于射频治疗仪的软件组件《射频治疗软件》。
软件的设计开发随设备设计开发同步进行。
软件验证报告的主要方法和程序是根据下列标准中列出的所有要求制定的。
本文件旨在定义软件设计的安全性，并通过预期用途的验证来证明软件的适用性。
本报告根据YY/T0664-2020，涵盖了产品全生命周期的所有阶段，从最初构想到最终退役和处置。
1.2引用标准列表
GB9706.1-2020《医用电气设备第l部分：
基本安全和基本性能的通用要求》GB/T11457-2006《信息技术软件工程术语》
YY/T0664-2020《医疗器械软件软件生存周期过程》
YY/T0316-2016《医疗器械风险管理对医疗器械的应用》
YY/T1406.1-2016《医疗器械软件第l部分：
YY/T0316应用于医疗器械软件的指南》
2目的
本文档旨在证明XXXXX公司生产的射频治疗仪所含软件的适用性。
3术语和定义
GB/T11457-2006《信息技术软件工程术语》、YY/T0664-2020《医疗器械软件 软件生存周期过程》及《医疗器械软件注册审查指导原则（2022年修订版）》（2022年第9号）中的术语和定义适用于本文件。
4软件基本信息
射频治疗仪设备所含软件基本信息如表1。
表1软件基本信息
类别
控制型软件
软件名称
射频治疗软件
软件型号
发布版本
V1.0
制造商
XXXXX有限公司
5软件安全性级别
5.1安全等级判定准则和要求
根据YY/T0664-2020中4.3软件安全分级，如图1。
图1软件安全分级
软件系统应在最不利情况下促成危险情况引发的对患者、操作者或其他人员伤害的风险，赋予每个软件系统一个软件安全级别。
5.2软件安全性级别
射频治疗软件设置了场强，以及治疗时间的上限，原则上不会对患者的治疗造成严重损伤和死亡。
在临床使用中，可能因为模式的选择和治疗部位不匹配，加上磁场强度设置不合理，考虑到这些最不利因素的情况下，可能会对患者治疗效果不明显，如果最不利因素的叠加可能造成患者心里难受和局部疼痛。
在这种情况下造成的非严重损伤，因此判定射频治疗软件的安全性级别均为B级（中等级别）。
6遗留软件
射频治疗软件为新开发全新软件，且无配合使用的遗留软件。
故该章节不适用。
7软件开发过程
射频治疗软件作为射频治疗仪的组成部分，其软件需求根据产品需求提取，在整个项目过程中，按照YY/T0664-2020的要求形成了PEMS开发活动流程，如图2。
图2PEMS开发过程
项目阶段的划分及各阶段可交付成果内容如表2。
表2PEMS开发阶段划分及交付物
阶段
阶段活动和任务
输出文档/交付物
项目节点
软件开发的策划
软件开发计划
见：
软件开发策划书
2022/2
软件开发标准、方法和工具的策划
软件集成和集成测试的策划
软件风险管理计划
软件配置管理计划
软件验证计划
文档的策划
软件需求分析
根据用户需求定义并记录软件需求
见：
软件需求说明
2022/2
定义软件需求内容
软件需求说明
验证软件需求
见：
软件需求验证报告
2022/2
软件体系结构设计
将软件需求转换为体系结构
见：
软件体系结构设计规范
2022/3
软件项接口的体系结构
确定风险控制所需的隔离
软件体系结构设计规范
验证软件体系结构
见：
软件体系结构验证报告
2022/3
软件详细设计
根据软件体系架构详细设计
见：
软件详细设计说明书
2022/3
-2022/4
为接口开发详细设计
验证详细设计
见：
软件详细设计验证报告
2022/4
软件验证与确认
软件集成
见：
软件集成验证报告
2022/5
验证软件集成
软件系统测试
见：
软件系统测试计划
2022/5
见：
软件系统测试报告
2022/5
软件用户测试
见：
软件用户测试计划
2022/5
见：
软件用户测试报告
2022/5
软件风险管理报告
见：
软件风险管理报告
2022/6
软件版本发布
软件版本发布
见：
软件发布版本说明
2022/6
8软件维护过程
维护过程包含为修改现行软件产品同时保持其完整性所必需的活动和任务。
当提出软件维护要求时，应立即制订维护计划和规程并且分配维护专用资源。
软件交付后，为响应修改请求或问题报告，维护者应修改代码和相关文档。
软件维护的总目标是修改现行软件同时保护其完整性。
软件产品的最终退役时本过程即告结束。
由于软件的复杂性，一个看似很小地方的修正可能对全局系统产生重大影响。
每当软件修正后，验证分析不仅要对此修正进行验证，还要确认此修正对整个软件系统的影响程度。
同时涉及到该软件的修改，评审、验证和风险分析，软件修改前后的差别对比，新软件版本号，这些都将形成文字记录。
8.1软件维护流程
图3软件维护流程图
过程说明：
表3软件维护过程说明
维护过程
任务
维护计划
建立维护计划。
对发软件发布后的反馈的接收、形成文件、评价、解决、跟踪作出规定；
接收、记录和追踪来自用户的问题报告和修改请求；
实施配置管理过程，以管理对现有软件的修改。
问题和修改分析
分析问题报告或修改请求：
维护的类型（纠正/改进/预防/对新环境的适应）、范围（修改规模/费用/时间）、关键性（性能/安全性/保密性）；
重现或验证问题；
制定实施修改的方案；
将问题/修改请求、分析结果和实施方案形成文档；
修改方案在修改前得到批准。
修改实施
实施分析并确定需修改的文档和软件版本，并形成文档；
按软件开发过程实施修改，同时确保已修改的需求完整且正确地实现，同时确保原来的、未修改的需求不受影响，测试结果应形成文档。
维护评审/验收
与授权修改的组织一起实施评审，以确定已修改系统的完整性；
修改的结果应得到批准。
软件的再发布
确保修改软件验证完成；
已知剩余问题文件化并评价；
再发布的软件版本形成文件。
8.2角色和责任
表4给出了分配给每个角色的相应职责与权限。
表4软件维护角色与职责权限
角色
责任
项目经理
新问题报告的接收者；
级织会议；
必须参加问题解决会议；
批准因问题解决而对配置项所做的更改。
质量经理
必须参加问题解决会议；
如果执行根本原因分析，则收集导致问题发生的流程缺陷信息。
团队领导
必须参加问题解决会议；
分析问题解决对其他配置项的影响；
审查因问题解决而影响配置项的更改。
团队成员
必要时参与问题解决；
仅当问题影响软件验证和确认计划文档下的工作产品时；
验证问题解决方案，以确认正确和准确的解决方案；
对受先前验证和确认的变更影响的工作产品重新应用验证和确认。
9软件风险管理
见软件风险管理报告。
10软件配置管理过程
软件配置管理的目的是计划、组织、控制和协调通过开发和转移（包括软件开发环境）对软件的识别、存储和更改。
软件配置由以下人员管理：
l项目经理（PM）;
l质量经理（QM）;
l团队领导
10.1软件配置管理活动和任务
活动
任务
配置标识
确定识别配置项的方法
识别未知来源软件（SOUP）
识别系统配置文档
配置更改控制
批准更改请求
实施变更
验证变更
提供变更可追溯性的方法
配置状态报告
存储和控制配置的状态
配置标识由配置项选择、配置标识符选择和基线标准选择组成。
1）配置项选择
在开发软件时，会产生各种产品，如开发文档、源代码、图像等。
其中，经常进行更正的计划或源代码需要适当的存储方法和访问策略来防止更正。
此外，要求规范等文件应通过适当控制进行管理，未经许可不得随意更改。
同样，根据管理方法或变更的控制来区分产品，并选择需要控制其变更的产品，称为配置项选择。
当项目管理员在产品开发的早期阶段选择负责配置的人员并与他一起确定配置管理项时，将执行配置顷选择。
2）配置标识符选择
为配置项提供自己名称、编号和版本的标识系统称为配置标识符。
配置标识符用作产品文件的名称，应该按照特定规则进行维护。
3）目的
开发或运行和维护的过程，通过持续和系统地应用变更来确保和提高系统的质量和生产力。
通过它可以提供项目的管理方法。
4）基线标准选择
通常，基线表示一组状态，在这些状态中，配置顷可以在软件开发的特定阶段作为软件开发中的完整产品使用，要成为这样的基线状态，必须经过配置控制器的正式审查和批准。
基线在IEEE标准中定义如下。
通过负责任的管理层正式审查和同意的状态可以成为未来发展的基础，并且只能通过正式的变更控制程序进行变更。
基线的标准通常是在软件开发周期中建立的。
例如，在分析阶段完成后将包含需求规范，在设计阶段完成后将包含上一阶段基线中的设计文挡，在实施阶段完成后将包含基线中的源代码。
如果一切都是这样进行的，那么实现阶段完成后的基线将依次是需求规范、设计文档和源代码。
此类基线标准将在制定配置管理计划时确定，基线配置项目的选择将由配置控制器确定，如前所述。
由于基线的目的在于通过适当的控制来控制重要开发产品的变更，因此此类变更始终需要配置控制员的评估和批准，所有这些过程都应通过正式程序执行。
10.2配置更改控制
这些要求随时可能发生变化。
特别是，软件的更改可能更加频繁。
要求的所有变更可能导致相关产品的变更。
这些变更是与成本和交付日期相关的重要事项。
因此，此类变更需要严格的审查流程。
评估和决定是否接受需求变更的程序称为配置控制过程。
配置变更控制程序
圆
1）变更可追溯性的方法：
对于变更的可追溯性，使用版本控制工具。
可以在“版本控制工具”中跟踪变更请求、问题报告和变更请求的批准。
2）可检索记录
使用版本控制工具以使受控配置项保持可检索性
11软件问题解决过程
11.1编写问题报告
制造商应为医疗器械软件中发现的每个问题编写问题报告。
问题报告应包括严重程度的说明（例如,对性能、安全或信息安全的影响）以及可能有助于解决问题的其他信息（例如,受影响的器械和受影响的支持性附件）。
注:
问题可在软件发布之前或之后、在制造商的组织内部或外部发现。
11.2调查问题
制造商应:
a）调查问题并在可能时识别问题的原因；
b）利用软件风险管理过程评价问题与安全的相关性；
c）将调查和评价的结果形成文件；
d）为纠正问题所需的措施创建一个或多个变更请求,或将不采取措施的理由形成文件。
注:
如果问题与安全无关,制造商不必为符合软件问题解决过程而对问题进行纠正。
11.3通知相关方
适当时﹐制造商应将存在的问题通知相关方。
注:
问题可在发布之前或之后,在制造商的组织内部或外部发现。
制造商根据此情况确定相关方。
11.4使用变更控制过程
制造商应按照变更控制过程的要求批准并实施所有变更请求。
11.5保持记录
制造商应保持问题报告及其解决情况的记录,包括对其验证的记录。
适当时,制造商应更新风险管理文档。
11.6分析问题的趋势
制造商应对问题报告进行分析以从中发现问题的趋势。
11.7验证软件问题的解决
制造商应验证问题的解决以确定是否:
a）问题已得到解决,问题报告已关闭;
b）不良趋势已得到扭转﹔
c）变更请求已在适当的医疗器械软件和活动中实施;
d）引入了其他问题。
11.8测试文档的内容
当在一项变更之后测试.再测试或回归测试软件项和系统时,制造商应在测试文档中包括:
a）测试结果;
b）发现的反常﹔
c）所测试软件的版本﹔
d相关硬件和软件的测试配置;
e）相关的测试工具;
f）测试日期;
g）测试者的身份。
12结论
本文件包括可验证项目，以确定设计项目是否按照这些文件化程序正确实施。
对于由软件错误引起的潜在风险，在软件需求规范和软件风险管理中确定了软件安全等级，软件的安全性等级确定为中度（B级）。
因此，开发活动按照YY/T0664-2020的要求进行。
经审查，软件的设计符合规定的程序；本报告已包含（介绍）了开发过程中使用的软件开发过程的内容。
软件开发中采用的程序符合公司设计开发流程规定的编制、评审和核准要求。
本报告包括这些程序的内容摘要。
风险管理活动中发现的风险通过基于硬件和基于软件的方法得到适当控制。
未发现不可接受的风险。
在每个开发阶段，通过代码评审、集成测试和系统测试来验证所实现软件的功能和性能。
在任何阶段均未发现未解决的问题。
因此，射频治疗仪开发团队给予“射频治疗软件能够满足以射频治疗仪对软件系统的要求并执行预期用途的需要”的评定结论。
13/13
升级会员 