软件生存周期过程控制规定新Word文件下载.docx
《软件生存周期过程控制规定新Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件生存周期过程控制规定新Word文件下载.docx（11页珍藏版）》请在冰豆网上搜索。
某一配置项的已标识了的实例。
4.3软件安全性级别
按照软件系统引起的危害对于患者、操作者或其他人员的可能影响，赋予每个软件系统一个软件安全性界别（A、B或C）。
A级：
不可能对健康有伤害或损坏；
B级：
可能有不严重的伤害；
C级：
可能死亡或严重伤害。
5.程序
5.1软件开发策划
项目经理应制订软件开发计划，以实施适合于所开发软件系统的范围、规模和软件安全级别的软件开发过程的活动。
在计划中应完整地规定软件开发生存周期模型，并说明以下各项：
（1）用于软件系统开发的过程；
（2）各项活动和任务的交付物；
（3）系统需求、软件需求、软件系统测试和在软件中实施的风险控制措施之间的可追溯性；
（4）软件配置和更改管理，包括位置来源软件配置项和用于支持开发的软件；
（5）在生存周期各个阶段的软件产品、交付物和活动中发现的用于处理问题的软件问题解决方案；
（6）对于C级软件，应包括或引用开发有关的标准、方法和工具；
（7）对于B级、C级软件，应包括集成软件项（包括SOUP）并在集成过程中完成测试；
（8）下列验证信息：
∙需要验证的交付物；
∙每个生存周期活动所要求的验证任务；
∙对交付物进行验证的里程碑；
∙验证交付物的验收准则。
（9）实施软件风险管理过程的活动和任务的计划，包括与未知来源软件（SOUP）有关的风险的管理；
（10）有关在软件开发生存周期中所形成文档的信息，应包括如下信息：
∙标题或名称；
∙目的；
∙文件的预期阅读者；
∙开发、评审、批准和修改的程序和职责。
（11）软件配置管理信息，包括：
∙受控项目的级别、形式、类别或清单；
∙软件配置管理活动和任务；
∙负责进行软件配置管理和活动的组织；
∙它们和其他组织的关系，诸如软件开发或维护；
∙当将这些项目处于配置控制之下时；
和
∙当应用问题解决过程时。
（12）对于B级、C级软件，受控项应包括用于医疗器械软件开发并对其有影响的工具、项目或设置，如编译器版本、生成文件、批文件和特定的环境设置；
适当时，应在开发进行的同时更新计划。
计划在验证软件配置项之前，使其处于形成文档的配置管理控制之下。
5.2软件需求分析
5.2.1软件需求内容
a）功能和能力需求；
b）软件系统的输入和输出；
c）软件系统和其他系统之间的接口；
d）软件控制的报警、警告和操作者信息；
e）保密安全需求；
f）对认为错误敏感的实用性工程要求和培训；
g）数据定义和数据库需求；
h）对已交付的医疗器械软件在操作和维护的一个或多个地点的安装和验收要求；
i）与操作和维护方法有关的要求；
j）要编制的用户文档；
k）用户维护要求
l）法规要求；
m）对于B级、C级软件，风险控制措施。
5.2.2在制定并适当更新软件需求时，应对医疗器械风险分析进行再评价。
5.2.3确保对现有的需求进行再评价和适当时更新，作为软件需求分析活动的结果。
5.2.4验证软件需求
对软件需求应进行验证并形成文档：
a）实施包括有关风险控制在内的系统需求；
b）需求不互相矛盾；
c）避免使用含糊不清的术语表示；
d）用表述的术语来制定测试准则和实施测试，以确定是否满足测试准则；
e）可以进行唯一性标识；
f）对于系统要求或其他来源是可追溯的。
5.3软件体系结构设计
5.3.1将软件需求转换为体系结构
对于B级、C级软件，应将对医疗器械软件的需求转换为描述软件结构和标明软件项的形成文档的体系结构，包含下列内容：
a）软件项和软件项外的组件之间、以及软件项之间的接口；
b）如果软件项被识别为SOUP，应规定SOUP项目预期用途所必需的功能和性能需求；
c）如果软件项被识别为SOUP，应规定为支持SOUP项目正常运行所必需的系统硬件和软件；
d）对于C级软件，应判定风险控制所必要的软件项之间的隔离，并说明如何确保隔离有效；
5.3.2验证软件体系结构
应验证下列各项并形成文档：
a）软件体系结构实现包括与风险控制有关的系统和软件需求；
b）软件体系结构能支持软件项之间和软件项与硬件之间的接口；
c）医疗器械体系结构支持任何SOUP项目的正常运行。
5.4软件详细设计
5.4.1将软件体系结构细化为软件单元
对于B级、C级软件，应细化软件体系结构直至其表现为软件单元。
5.4.2C级软件详细设计的特殊要求
a）对软件项的每个软件单元开发详细设计并形成文档；
b）对软件单元和外部组件之间的任何借口、以及软件单元之间的任何接口开发详细设计并形成文档；
c）验证软件详细设计的下列各项并形成文档：
∙实现软件体系结构；
∙不和软件体系结构相矛盾。
5.5软件单元的实现和验证
5.5.1应实现每个软件单元。
5.5.2对于B级、C级软件，应符合：
a）为验证每个软件单元制定策略、方法和规程。
在以测试验证时，应评价测试程序的正确性；
b）适当时，在集成为较大的软件项之前，应为软件单元制定验收准则，并确保软件单元符合验收准则；
5.5.3对于C级软件，在设计中出现时，还应包括下列各项（适当时）的补充验收准则：
a）合适的时间序列
b）数据和控制流；
c）计划的资源配置；
d）故障处理（错误界定、隔离和恢复）；
e）变量的初始化；
f）自我诊断；
g）存储管理和存储溢出；
h）边界条件。
5.5.4应实施软件单元的验证并将结果形成文档。
5.6软件集成和集成测试
对于B级、C级软件，应：
5.6.1按集成计划（5.1.7）集成软件单元，并对软件集成的下列方面进行验证和记录：
a）软件单元已经集成到软件项和软件系统中；
b）系统的硬件项、软件项和人工操作的支持（例如：
人机接口、联机帮助菜单、语音识别、声控）已经集成进系统中。
5.6.2对集成后的软件项进行测试并将结果形成文档，应说明集成的软件项是否按预期运行。
5.6.3评价集成测试规程的正确性。
5.6.4当软件项已集成时，进行适当的回归测试，以证实未将缺陷引入到原先集成的软件中。
5.6.5将测试结果形成文档（通过/未通过和异常清单），保留充分的记录，以使测试能够重复进行，并标明测试者。
5.6.6将软件集成和集成测试时发现的异常输入软件问题解决过程中。
5.7软件系统测试
5.7.1为软件系统测试制订并实施一组测试，表达为输入触发、预期输出、通过/未通过准则和规程，以覆盖全部软件需求。
5.7.2将软件系统测试时发现的异常输入软件问题解决过程。
5.7.3软件在软件系统测试中做出更改时，应：
a）重复测试、进行改进测试或进行补充测试，适当时验证纠正问题是所做更改的有效性；
b）进行适当的测试，以证实没有引入非预期的副作用；
c）实施风险管理活动。
5.7.4验证软件系统测试，包括：
a）所用的验证策略和测试规程是否适当；
b）软件系统测试规程可追溯到软件需求；
c）所有的软件需求都已测试过或以其他方式验证过；
d）测试结果满足要求的通过/未通过准则。
5.7.5记录软件系统测试，包括：
a）将测试结果形成文档（通过/未通过和异常清单）；
b）保存充分的记录，以使测试可重复；
c）标明测试者。
5.8软件发行
应将所有即将发行的软件产品版本形成文档。
对于B级、C级软件，还应：
5.8.1在软件发行前，确保软件验证已经完成，并对其结果进行了评价。
5.8.2将所有已知的剩余异常形成文档，并确保所有已知的剩余异常情况已被评价，从而确保其不会构成不可接受的风险。
5.8.3将用于创建已发行软件的规程和环境形成文档。
5.8.4确保所有的活动和任务连同所有相关文件编制是完成的。
5.8.5将下列内容归档：
∙软件产品和配置项；
∙文档
5.8.6保证软件发行的可重复性
建立规程，确保已发行的软件产品能可靠地交付到使用地点，而没有讹误的或未授权的更改。
这些规程应说明包含软件产品的媒介的生产和处理情况，适当时包括：
a）复制；
b）媒介标记；
c）包装；
d）防护；
e）存储
f）交付。
5.9软件维护过程
5.9.1制定维护计划
应为进行维护过程的活动和任务，制定一项（或多项）软件维护计划。
计划应说明以下内容:
a）用于以下目的规程：
Ø
接收;
形成文档；
评价；
解决过程，和;
跟踪。
医疗器械软件发行后引起的反馈；
b）进否将反馈作为问题加以考虑的准则；
c）软件风险管理过程的应用；
d）应用软件问题解决过程以分析和解决在医疗器械软件发行后出现的问题;
e）应用软件配置管理过程管理对现有系统的更改，和
f）评价件实施未知来源软件（SOUP）下列亊项的规程：
—升级;
—缺陷修复；
—补丁和：
—废弃。
5.9.2问题和修改分析
对于通过顾客反馈程序收集到的对已发行的软件产品的反溃，应形成文件并进行评价，以确定已发行的软件产品是否存在问题。
应利用软件问题解决过程阐明问题报告，并对每个更改请求对已发行的软件产品以及对于其有接口的系统的影响进行分析
5.9.3修改的实施
应利用软件开发过程实施修改，并按照5.8发行已更改的软件系。
修改可以作为软件系统完整再发行的一部分发行；
或作为包含经更改的软件项的修改包和为安装此项更改的必要工具用作对现有的软件系统的更改发行。
5.10软件风险管理过程
见《风险管理控制程序》
5.11软件配置管理过程
5.11.1配置标识
5.11.1.1制定配置项标识的方法
应为项目所控制的配置项及其版本的唯一性标识制定一个方案。
此方案应包括其他的软件产品或实体，诸如未知来源软件和形成的文档.
5.11.1.2标识未知来源软件（SOUP）
对使用的每个未知来源软件的配置项，包括标准程序库，应将其下列内容形成文档：
a）标题
b）制造商
c）未知来源软件的唯一标志符。
5.11.1.3判定系统配置文档
应将组成软件系统配置的一组配置项及其版本形成文档.
5.11.2更改控制
5.11.2.1批准更改请求
应只对经批准的更改请求做出配置项更改。
5.11.2.2实施更改
应按更改请求中的规定实施更改，制造商应识别并实施由更改产生的所需重复的任何活动，包括对软件系统和软件项的软件安全性分级的更改。
5.11.2.3验证更改
应验证更改，包括重复已因更改失效的任何验证。
5.11.2.4规定更改的可追溯性方法
应制定审核追踪，可借以追溯下列各项：
a）更改请求
b）有关的问题报告：
c）更改请求的批准
5.11.2.4配置状态记录
应保留包括系统配置的受控配置项的可检索历史记录。
5.12软件问题解决过程
5.12.1准备问题报吿
应为在软件产品中检出的每个问题准备一份问题报告，问题报告按如下分类：
a）类型，如纠正、预防或适应新坏境；
b）范围，如更改的多少，受影响的器械模型编号，受影响的支持性附件，涉及的资源，更改的时间；
c）危害度，如对性能、安全性或保密性的影响。
注：
问题可以在软件发行之前或之后、在制造商的组织内部或外部发现。
5.12.2研究问题
a）研究问题，如有可能识别问题原因；
b）利用软件风险管理过程评价问题和安全性的相关性（第7章）；
c）把研究和评价结果形成文档，和；
d）为纠正问题所需的措施拟定更改请求,或将不采取措施的理由形成文档。
如果问题与安全性无关，则不必按照软件问题解决过程纠正问题。
5.12.3通知相关方
适当时，应通知存在问题的相关方。
5.12.4应用更改控制过程
应遵照更改控制过程的要求，批准并实施所有的更改请求。
5.12.5保持记录
应保持问题报告及其解决情况，包括对其验证的记录。
适当时，应更新风险管理文件。
5.12.6分析问题的趋势
应在问通报告中进行分析，以找出问题的趋势。
5.12.7验证软件问题的解决
应验证问题的解决以确定是否：
a）问题已经解决，问题报告已经关闭；
b）不良趋势已扭转；
c）更改请求已在适当的软件产品和活动中执行；
和
d）已引入其他的问题。
5.12.8测试文档内容
当在一项更改之后，进行软件项和系统的测试、再测试或回归测试时，应在测试形成的义档中包括：
a）测试结果；
b）发现的异常；
c）所测试软件的版本；
d）相关的硬件和软件测试配置；
e）相关的测试工具；
f）测试日期，和；
g）测试者身份标识。
6.相关文件
《风险管理控制程序》
《YY/T0664-2008医疗器械软件软件生存周期过程》
7.相关记录
《项目计划》
《需求规格说明书》
《概要设计说明书》
《详细设计说明书》
《系统配置文档》
《集成测试报告》
《软件维护计划》
《软件发行文档》
《软件更改请求单》
《软件问题报告》
升级会员 