导图社区 软件风险管理过程思维导图
- 42
- 0
- 0
- 举报
软件风险管理过程思维导图
一篇关于软件风险管理过程思维导图，包含促成危险情况的软件分析、风险控制措施、风险控制措施的验证等。
编辑于2023-11-22 18:17:44- 标准
- 医疗器械
- 相似推荐
- 大纲
医疗器械软件生存周期过程
1. 范围
1.1. 目的
1.2. 范围
1.3. 与其他标准关系
1.4. 符合性
2. 规范性引用文件
3. 术语和定义
4. 总要求
4.1. 质量管理体系
4.2. 风险管理
4.3. 软件安全分级
4.4. 遗留软件
5. 软件开发过程
5.1. 软件开发策划
5.2. 软件需求分析
5.3. 软件架构设计
5.4. 软件详细设计
5.5. 软件单元实现
5.6. 软件系统集成
5.7. 软件系统测试
5.8. 软件系统发布
6. 软件维护过程
6.1. 建立软件维护计划
6.2. 问题和修改分析
6.3. 修改的实施
7. 软件风险管理过程
7.1. 促成危险情况的软件分析
7.2. 风险控制措施
7.3. 风险控制措施的验证
7.4. 软件变更的风险管理
8. 软件配置管理过程
8.1. 配置标识
8.2. 变更控制
8.3. 配置状态报告
9. 软件问题解决过程
9.1. 编写问题报告
9.2. 调查问题
9.3. 通知相关方
9.4. 使用变更控制过程
9.5. 保持记录
9.6. 分析问题的趋势
9.7. 验证软件问题的解决
9.8. 测试文档的内容
总要求
质量管理体系
医疗器械软件制造商应证实其有能力提供持续满足顾客要求和适用法规要求的医疗器械软件。
可通过应用符合下列要求的质量管理体系，证实此能力： ISO 13485（YY/T 0287） 国家质量管理体系标准 国家法规要求的质量管理体系 将质量管理体系要求应用于软件的指南参见ISO/IEC 90003
风险管理
制造商应应用符合ISO14971（YY/T 0316）的风险管理过程
软件安全分级
a. 制造商应根据软件系统在最不利情况下促成的危险情况引发的对患者、操作者或其他人员伤害的风险，赋予每个软件系统一个软件安全级别（A、B或C）。
外部风险控制措施是指软件系统意外的风险控制措施，可以是硬件、单独的软件系统、医疗程序或其他方法，以最大程度地降低软件促成地危险情况。 关于风险可接受性的定义，见YY/T 0316-2016的3.2。
软件安全级别为A
软件系统不可能促成危险情况；或
在考虑外部风险控制措施后，软件系统可能促成不导致不可接受风险的危险情况。
软件安全级别为B
在考虑外部风险控制措施后，软件系统可能促成导致不可接受风险的危险情况，且导致的可能伤害是非严重损伤
软件安全级别为C
在考虑外部风险控制措施后，软件系统可能促成导致不可接受风险的危险情况，且导致的可能伤害是死亡或严重损伤
对于最初分类为软件安全级别B或C的软件系统，制造商可以实施软件系统外部附加风险控制措施（包括修改含有软件系统的系统体系结构），并在随后为软件系统赋予新的软件安全级别。
b. 制造商应在风险管理文档中将赋予每个软件系统的软件安全级别形成文件。
c. 当一个软件系统分解为多个软件项，及当一个软件项又进一步分解为多个软件项时，此类软件项应继承原软件项（或软件系统）的软件安全级别，除非制造商以文件形式说明分类为不同软件安全级别的理由。此类理由说明应解释新的软件项如何被隔离，以便可对其单独分级。
d. 如果以分解方式产生的软件项的安全级别与其原软件项不同，制造商应将每个此类软件项的软件安全级别形成文件。
e. 为符合本标准，当本标准应用于一组软件项时，制造商应适用此组中级别最高的软件项所要求的诸过程和任务，除非制造商在风险管理文档中将使用较低级别的理由说明形成文件。
f. 对于每个软件系统，在赋予软件安全级别以前，均应应用C级要求。
遗留软件
概述
风险管理活动
差距分析
差距关闭活动
使用遗留软件的理由
软件维护过程
建立软件维护计划
制造商应为进行维护过程的活动和任务建立一项或多项软件维护计划，并说明以下内容
a. 对医疗器械软件发布后发生的反馈，进行如下处理的规程
接收
形成文件
评价
解决
跟踪
b. 确定是否将反馈视为问题的准则
c. 使用软件风险管理过程
d. 使用软件问题解决过程，分析和解决在医疗器械软件发布后出现的问题
e. 使用软件配置管理过程（见第8章）管理对现有软件系统的修改
f. 评价并实施位置来源软件如下事项的规程
升级
缺陷修复
打补丁
废弃
问题和修改分析
形成文件并评价反馈
监视反馈
制造商应监视与已发布的用于预期用途的医疗器械有关的反馈
形成文件并评价反馈
反馈应形成文件并予以评价，以确定已发布的医疗器械是否存在问题。
任何此类问题应以问题报告的形式予以记录（见第9章）
实际的或潜在的不良事件
对规范的偏离
评价问题报告对安全的影响
应对每个问题报告进行评价，以确定其对医疗器械软件的安全有何影响（见9.2）
是否有必要对该软件进行变更以解决问题。
使用软件问题解决过程
制造商应使用软件问题解决过程（见第9章）处理问题报告
某个问题可能表明某软件系统或软件项尚未被赋予正确的软件安全级别。 该问题的解决过程可能引起软件安全级别的变更。当该过程完成时，软件系统或其软件项安全级别的任何变更，宜予以公布并形成文件。
分析变更请求
除第9章要求的分析之外，制造商还应就每个变更请求对组织、对医疗器械软件及对与其有接口的系统的影响进行分析
批准变更请求
制造商应评价并批准修改已发布医疗器械软件的变更请求
与用户和监管机构沟通
制造商应识别经批准的影响已发布医疗器械软件的变更请求
按照当地法规要求，制造商应告知用户和监管机构如下信息
a. 已发布医疗器械软件中的任何问题和不变更继续使用的后果
b. 已发布医疗器械软件任何可获得的变更的性质，以及如何获得并安装这些变更
修改的实施
使用已建立的过程实施修改
制造商应识别并实施因修改而需要重复的软件开发过程的任何活动
有关软件变更的风险管理要求见7.4。
修改后软件系统的再发布
制造商应按照软件系统发布的要求发布修改
修改可以作为软件系统完整再发布的一部分
软件风险管理过程
促成危险情况的软件分析
识别可能促成危险情况的软件项
制造商应识别可能促成危险情况的软件项，危险情况在YY/T 0316的医疗器械风险分析活动（见4.2）中已识别
危险情况可能是软件失效的直接结果，或在软件中实施的风险控制措施失效的结果。
识别促成危险情况的潜在原因
制造商应识别软件项促成危险情况的潜在原因，适当时包括
a. 不正确的或不完整的功能性规范
b. 所识别的软件项功能性方面的缺陷
c. 来自SOUP的失效或非预期结果
d. 可能导致非预期软件操作的硬件失效或其他软件缺陷
e. 合理可预见的误用
评价已公开的SOUP异常清单
如果源于SOUP的失效或非预期结果是软件项造成危险情况的潜在原因，制造商至少应评价由供应商公开的、与在医疗器械中使用版本的SOUP有关的任何异常清单，以确定是否由任何已知的异常导致了可能促成危险情况的事件序列。
将潜在原因形成文件
制造商应在风险管理文档中将软件项造成危险情况的潜在原因形成文件（见YY/T 0316）
风险控制措施
确定风险控制措施
对在风险管理文档中形成文件的软件项可能造成危险情况的每种情况，制造商应按照YY/T0316规定风险控制措施并形成文件。
风险控制措施可以在硬件、软件、工作环境或用户说明书实施。
在软件中实施的风险控制措施
如果风险控制措施作为软件项功能的一部分来实施，制造商应
a. 在软件需求中包括风险控制措施
b. 基于风险控制措施所控制的风险，为实施风险控制措施的每一个软件项赋予软件安全级别。
c. 按照软件开发过程开发软件项
风险控制措施的验证
验证风险控制措施
应对形成文件的每个风险控制措施的实施进行验证并形成文件，制造商应评审风险控制措施，并确定其是否可能导致新的危险情况。
将可追溯性形成文件，适当时包括
a. 从危险情况到软件项
b. 从软件项到特定的软件原因
c. 从软件原因到风险控制措施
d. 从风险控制措施到风险控制措施的验证
软件变更的风险管理
分析与医疗器械软件安全相关的变更
a. 引入了造成危险情况的潜在原因
b. 需要额外的软件风险控制措施
分析软件变更对现有风险控制措施的影响
制造商应分析对软件（包括SOUP）的变更，以确定软件变更是否可能干扰现有的风险控制措施
基于分析实施风险管理活动
制造商应在这些分析的基础上实施相关的风险管理活动。
软件问题解决过程
编写问题报告
制造商应为医疗器械软件中发现的每个问题编写问题报告。
问题可在软件发布之前或之后，在制造商的组织内部或外部发现。
严重程度的说明
性能的影响
安全的影响
信息安全的影响
有助于解决问题的其他信息
受影响的器械
受影响的支持性附件
调查问题
调查问题并在可能是识别问题的原因
利用软件风险管理过程评价问题与安全的相关性（见第7章）
将调查和评价的结果形成文件
为纠正问题所需的措施创建一个或多个变更请求，或将不采取措施的理由形成文件
如果问题与安全无关，制造商不必为符合软件问题解决过程而对问题进行纠正。
通知相关方
适当时，制造商应将存在的问题通知相关方。
问题可在发布之前或之后，在制造商组织内部或外部发现。根据具体情况确定相关方。
使用变更控制过程
制造商应按照变更控制过程的要求（见8.2）批准并实施所有变更请求。
保持记录
制造商应保持问题报告及其解决情况的记录，包括对其验证的记录。
适当时，制造商应更新风险管理文档。
分析问题的趋势
制造商应对问题报告进行分析以从中发现问题的趋势。
验证软件问题的解决
a. 问题已得到解决，问题报告已关闭。
b. 不良趋势已得到扭转
c. 变更请求已在适当的医疗器械软件和活动中实施
d. 未引入了其他问题
测试文档的内容
当在一项变更后测试、再测试或回归测试软件项和系统时，制造商应再测试文档中包括
a. 测试结果
b. 发现的异常
c. 所测试软件的版本
d. 相关硬件和软件的测试配置
e. 相关的测试工具
f. 测试日期
g. 测试者的标识
软件配置管理过程
配置标识
建立标识配置项的方法
制造商应根据5.1规定的开发和配置策划为拟受控的配置项及其版本的唯一性标识建立一个方案。
标识SOUP
对于拟使用的每个SOUP配置项，包括标准库，制造商应将以下各项形成文件
标题
制造商
唯一标识符
SOUP的唯一标识符可以是，例如版本，发布日期，补丁编号或升级名称。
标识系统配置文档
制造商应将组成软件系统配置的一组配置项及其版本形成文档。
变更控制
批准变更请求
制造商应仅在变更请求批准后才对按照8.1识别的受控的配置项进行变更。
批准变更请求的决定可以整合到变更控制过程或作为其他过程的一部分，本条仅要求变更的批准优先于其实施。 可在生存周期不同阶段的个验收过程提出变更请求，如计划所述，见5.1.1 d)和6.1 e)。
实施变更
制造商应按变更请求中的规定实施变更。
制造商应识别并实施因变更而需要重复的任何活动，包括对软件系统和软件项的软件安全级别的变更。
本条说明了宜如何实施变更以达到充分的变更控制。这并不意味着实施时变更控制过程的组成部分。实施宜使用所策划的过程，见5.1.1 d)和6.1 d)。
验证变更
制造商应验证变更，包括重复因变更而失效的任何验证，并考虑5.7.3和9.7。
本条只要求变更经过验证。这并不意味着验证是变更控制过程的组成部分。验证宜使用所策划的过程，见5.1.1 d)和6.1 e)。
为变更的可追溯性规定方法
变更请求
有关的问题报告
变更请求的批准
配置状态报告
制造商应保留包括系统配置在内的受控配置项的历史可检索记录。
软件系统发布
确保软件验证完成
应确保在软件发布之前已完成所有软件验证活动且已对其结果进行评价
将已知的剩余异常形成文件
评价已知的剩余异常
应确保所有已知的剩余异常均得到评价，以确保其不会促成不可接受的风险。
将所发布的版本形成文件
将所发布软件的创建过程形成文件
应将用于创建所发布软件的规程和环境形成文件
确保活动和任务的完成
应确保所有软件开发计划（或维护计划）中的活动和任务以及相关文档均完全齐全。
将软件归档
医疗器械软件和配置项
文档
存档时间至少为医疗器械软件寿命期或有关法规要求规定的时间中较长者
确保所发布软件的可靠交付
应建立规程，以确保所发布的医疗器械软件能够可靠地交付到使用地点，而无损毁或未授权地变更。
交付规程应说明包含医疗器械软件地媒介地产生和处置情况，适当时，包括
复制
媒介标记
包装
防护
存储
交付
软件系统测试
为软件需求建立测试
a. 为软件系统测试建立并实施一组测试，表达为输入触发、预期输出、通过/未通过准则和规程，并覆盖全部软件需求。
将集成测试和软件系统测试合并未一项但与i的计划和一组活动中是可接受的，在较早阶段测试软件需求也是可接受的。 不仅可对每个需求进行单独测试，也可对多个需求进行联合测试，特别是多个需求之间存在依赖关系时。
b. 评价验证策略和测试规程的充分性。
使用软件问题解决过程
应将软件系统测试期间所发现的反常输入到软件问题解决过程。
变更后再测试
当在软件系统测试期间做出变更时，制造商应
a. 适当时，重复测试、实施经修改的测试或附加测试，已验证修复问题的变更的有效性
b. 进行适当的测试，以证实没有引入非预期的副作用。
回归测试
c. 实施7.4中规定的有关风险管理活动。
评价软件系统测试
评价验证策略和测试规程的适宜性
验证
a. 所有的软件需求均经过测试或其他方式验证
b. 软件需求与测试或其他验证之间的可追溯性均已记录
c. 测试结果满足所要求的通过/未通过准则
软件系统测试记录的内容
为支持测试的可重复性，制造商应将以下内容形成文件
a. 引用的测试用例规程，该规程体现所要求的行动和预期结果
b. 测试结果（通过/未通过和异常清单）
c. 被测试软件的版本
d. 相关硬件和软件的测试配置
e. 相关测试工具
f. 测试日期
g. 负责执行测试和记录测试结果的人员的身份
软件系统集成
集成软件单元
制造商应按照集成计划集成软件单元。
验证软件集成
制造商应验证软件单元已按照集成计划集成到软件项和/或软件系统中，并保留此验证证据的记录。
此验证仅验证已按照计划进行了集成，验证很可能通过某种形式的检查来实施。
软件集成测试
制造商应按照集成计划测试集成后的软件项，并将结果形成文件。
软件集成测试内容
制造商应阐明集成的软件项是否按预期运行。
将集成测试和软件系统测试合并到一项单一计划和一组活动中是可接受的。
所要求的软件的功能性
风险控制措施的实施
特定的时序和其他性能
内部和外部接口特定的功能
非正常条件下（包括可预见的误使用）的测试
评价软件集成测试规程
制造商应评价集成测试规程的充分性。
开展回归测试
在软件项集成后，制造商应进行适当的回归测试，已证实未将风险不可接受的缺陷引入到先前集成的软件中。
集成测试记录的内容
将测试结果（通过/未通过和异常清单）形成文件
保留充分的记录，以使测试可重复
描述操作要求和预期结果的测试用例规范
设备的记录
测试环境及测试工具（包括软件工具）的记录
标明测试者的身份
软件单元实现
实现每个软件单元
建立软件软件验证过程
将单元测试和软件系统测试合并到一项单一的计划和一组活动中时可接受的。
制造商应为软件单元建立策略、方法和规程。
在通过测试进行验证时，应评价测试规程的充分性。
软件单元的验收准则
适当时，在集成为更大的软件项之前，制造商应为软件的单元建立验收准则，并确保软件单元符合验收准则。
验收准则的示例： 软件编码是否实现了包括风险控制措施在内的需求？ 软件编码是否和软件单元的接口设计不相矛盾？ 软件编码是否符合编程规程或编码标准？
附件的软件单元验收准则【C】
a. 适当的事件序列
b. 数据和控制流
c. 所计划的资源分配
d. 故障处理（错误界定、隔离和恢复）
e. 变量的初始化
f. 自我诊断
g. 存储管理和存储溢出
h. 边界条件
软件单元的验证
制造商应实施软件单元验证并将结果形成文件。
软件详细设计
将软件细分为软件单元
为每个软件单元开发详细设计【C】
为软件单元之间及与外部组件之间的接口开发详细设计【C】
验证详细设计【C】
实现软件架构
与软件架构不相矛盾
软件架构设计
将软件需求转换为架构
制造商应将医疗器械软件的需求转换为描述软件结构和定义软件项的架构并形成文件。
为软件项接口开发架构
软件项与软件项的外部组件（软件和硬件）
软件项之间
识别为SOUP的软件项
规定SOUP符合预期用途所必需的功能和性能要求
规定为支持SOUP正常运行所必需的系统硬件和软件
识别风险控制所必须的隔离【C】
制造商应识别风险控制所必需的软件项之间的隔离，并说明如何确保隔离有效。
一个隔离的示例是将软件项在不同的处理器上运行，隔离的有效性可通过处理器间不共享资源来保证。 当软件架构设计可确保有效性时，也可应用其他隔离手段（参见B.4.3）。
验证软件架构
制造商应验证以下内容并形成文件
软件架构实现系统和软件需求，包括与风险控制有关的需求
软件架构能够支持软件项之间、软件项与硬件之间的接口
医疗器械体系结构支持任何SOUP的正常运行
软件需求分析
基于系统需求定义软件需求并形成文档
对于医疗器械的每个软件系统，制造商应基于系统级需求定义软件需求，并形成文档
软件需求内容
所有需求在软件开发之初可能无法得到。 ISO/IEC 25010提供可能对定义软件需求有用的质量特性信息。
a. 功能和能力需求
性能
软件目的
时许要求
物理特性
编码语言
平台
操作系统
软件运行的计算环境
硬件
存储容量
处理单元
时区
网络基础设施
兼容性
升级
多个SOUP
其他设备版本
b. 软件系统的输入和输出
数据特征
数值
字母数值
格式
范围
限制
默认
c. 软件系统与其他系统的接口
d. 软件驱动的报警、警告和操作者信息
e. 安全需求
涉及泄露敏感信息
身份验证
授权
审核跟踪
通信完整性
系统安全/恶意软件防护
f. 由软件实现的界面需求
可用性工程的信息参见IEC62366-1和IEC60601-1-6。
对手动操作的支持
人机交互
人员的限制
需要人员集中注意力的区域
g. 数据定义和数据库需求
表单
匹配
功能
h. 在一个或多个操作和维护场地交付的医疗器械的安装和验收需求
i. 与操作方法和维护方法有关的需求
j. IT网络方面相关的需求
已联网的报警、警告和操作者信息
网络协议
网络服务不可用时的处理
k. 用户维护需求
l. 法规需求
将风险控制措施纳入软件需求
制造商应将在软件中实施的风险控制措施包含在医疗器械软件需求中。
医疗器械风险分析的再评价
制造商应在建立了软件需求后对医疗器械风险分析进行再评价，并再适当时予以更新。
更新需求
作为软件需求分析活动的结果，制造商应确保现有需求（包括系统需求）得到再评价，并在适当时予以更新。
验证软件需求
制造商应对软件需求进行以下验证并形成文件
实现了系统需求，包括那些与风险控制相关的需求
彼此不互相矛盾
避免使用含糊不清的术语表述
以允许建立测试准则和实施测试的术语描述
可被唯一识别
可追溯至系统需求或其他来源
软件开发策划
软件开发计划
制造商应制定一个或多个软件开发计划，以开展于待开发软件系统的范围、规模和安全级别相适宜的活动
软件开发生存周期模型可根据软件系统的每个软件项的安全级别为不同的软件项识别不同的要素（过程、活动、任务和交付物）。 这些活动和任务可以重叠或相互作用，可迭代或循环地完成。其意图并非暗示宜使用特定的生存周期模型。 在本标准中将其他过程与开发过程分开描述，并非暗示其他过程必须作为单独的活动和任务来实施。可将其活动和任务整合到开发过程中。 软件开发计划可以引用现有过程或定义新过程。 可将软件开发计划整合到真个系统的开发计划中。
完整的软件开发生命周期模型
用以开发软件系统的过程
活动和任务的交付物
系统需求、软件需求、软件系统测试和软件中实施的风险控制措施之间的可追溯性
软件配置和变更管理，包括SOUP和支持工具
处理在医疗器械软件、交付物和生命周期各阶段活动中发现的问题的软件问题解决方案
保持软件开发计划更新
制造商应在适当的开发过程中更新计划。
参考系统设计和开发
引用系统需求作为软件开发的输入
软件开发计划中应包含或引用为满足质量管理体系所必须的软件开发与系统开发的协调程序（例如，系统集成、验证和确认）。
开发标准、方法和工具策划【C】
软件集成与集成测试策划
制造商应在软件开发计划中包含或引用软件项（包括SOUP）集成和集成过程开展测试的计划。
将集成测试和软件系统测试合并成一个计划以及一系列活动时可接受的。
软件验证策划
制造商应在软件开发计划中包含或引用如下的验证信息
a. 需要验证的交付物
b. 每个生存周期活动所需的验证任务
c. 交付物验证的里程碑
d. 交付物的验证准测
软件风险管理策划
制造商应在软件开发计划中包含或引用一个指导软件风险管理过程中活动和任务的计划，包括与SOUP相关的风险的管理。
文档策划
制造商应在软件开发计划中包含或引用关于软件开发生命周期中产生的文档的信息。对于每一种确定的文件或文件类型，应包括或引用以下信息
a. 标题、名称或命名惯例
b. 目的
c. 编制、审核、批准和修改的程序和职责
软件配置管理策划
制造商应在软件开发计划中包含或引用软件配置管理信息。软件配置管理信息应包含或引用：
a. 受控项的类别、类型、种类或清单;
b. 软件配置管理活动和任务;
c. 负责执行软件配置管理活动的组织;
d. 他们与其他组织的关系，如软件开发或维护;
e. 何时项目要置于配置控制之下；以及
f. 何时需要使用问题解决过程。
拟受控的支持项
受控项应当包括可能影响医疗器械软件的用于医疗器械软件开发的工具、项目或设置。
示例包括编译器版本，make文件，批处理文件和特定环境设置。
验证前软件配置项的控制
制造商应配置项验证前将其纳入配置管理控制。
识别和避免常见的软件缺陷
参见IEC TR 80002-1:2009附录B关于导致危险情况的缺陷或原因类别的例子。
根据所选择的与软件系统相关的编程技术，确定可能引入的缺陷类别；
记录证明这些缺陷不会导致不可接受的风险的证据。