软件生存周期过程控制规定新Word文件下载.docx

1、某一配置项的已标识了的实例。4.3软件安全性级别按照软件系统引起的危害对于患者、操作者或其他人员的可能影响，赋予每个软件系统一个软件安全性界别（A、B或C）。A级：不可能对健康有伤害或损坏；B级：可能有不严重的伤害；C级：可能死亡或严重伤害。5.程序5.1 软件开发策划项目经理应制订软件开发计划，以实施适合于所开发软件系统的范围、规模和软件安全级别的软件开发过程的活动。在计划中应完整地规定软件开发生存周期模型，并说明以下各项：（1）用于软件系统开发的过程；（2）各项活动和任务的交付物；（3）系统需求、软件需求、软件系统测试和在软件中实施的风险控制措施之间的可追溯性；（4）软件配置和更改管理，包

2、括位置来源软件配置项和用于支持开发的软件；（5）在生存周期各个阶段的软件产品、交付物和活动中发现的用于处理问题的软件问题解决方案；（6）对于C级软件，应包括或引用开发有关的标准、方法和工具；（7）对于B级、C级软件，应包括集成软件项（包括SOUP）并在集成过程中完成测试；（8）下列验证信息：需要验证的交付物；每个生存周期活动所要求的验证任务；对交付物进行验证的里程碑；验证交付物的验收准则。（9）实施软件风险管理过程的活动和任务的计划，包括与未知来源软件（SOUP）有关的风险的管理；（10）有关在软件开发生存周期中所形成文档的信息，应包括如下信息：标题或名称；目的；文件的预期阅读者；开发、评审、

3、批准和修改的程序和职责。（11）软件配置管理信息，包括：受控项目的级别、形式、类别或清单；软件配置管理活动和任务；负责进行软件配置管理和活动的组织；它们和其他组织的关系，诸如软件开发或维护；当将这些项目处于配置控制之下时；和当应用问题解决过程时。（12）对于B级、C级软件，受控项应包括用于医疗器械软件开发并对其有影响的工具、项目或设置，如编译器版本、生成文件、批文件和特定的环境设置；适当时，应在开发进行的同时更新计划。计划在验证软件配置项之前，使其处于形成文档的配置管理控制之下。5.2软件需求分析5.2.1软件需求内容a）功能和能力需求；b）软件系统的输入和输出；c）软件系统和其他系统之间的接

4、口；d）软件控制的报警、警告和操作者信息；e）保密安全需求；f）对认为错误敏感的实用性工程要求和培训；g）数据定义和数据库需求；h）对已交付的医疗器械软件在操作和维护的一个或多个地点的安装和验收要求；i）与操作和维护方法有关的要求；j）要编制的用户文档；k）用户维护要求l）法规要求；m）对于B级、C级软件，风险控制措施。5.2.2在制定并适当更新软件需求时，应对医疗器械风险分析进行再评价。5.2.3确保对现有的需求进行再评价和适当时更新，作为软件需求分析活动的结果。5.2.4验证软件需求对软件需求应进行验证并形成文档：a）实施包括有关风险控制在内的系统需求；b）需求不互相矛盾；c）避免使用含糊

5、不清的术语表示；d）用表述的术语来制定测试准则和实施测试，以确定是否满足测试准则；e）可以进行唯一性标识；f）对于系统要求或其他来源是可追溯的。5.3 软件体系结构设计5.3.1将软件需求转换为体系结构对于B级、C级软件，应将对医疗器械软件的需求转换为描述软件结构和标明软件项的形成文档的体系结构，包含下列内容：a）软件项和软件项外的组件之间、以及软件项之间的接口；b）如果软件项被识别为SOUP，应规定SOUP项目预期用途所必需的功能和性能需求；c）如果软件项被识别为SOUP，应规定为支持SOUP项目正常运行所必需的系统硬件和软件；d）对于C级软件，应判定风险控制所必要的软件项之间的隔离，并说明

6、如何确保隔离有效；5.3.2验证软件体系结构应验证下列各项并形成文档：a）软件体系结构实现包括与风险控制有关的系统和软件需求；b）软件体系结构能支持软件项之间和软件项与硬件之间的接口；c）医疗器械体系结构支持任何SOUP项目的正常运行。5.4软件详细设计5.4.1将软件体系结构细化为软件单元对于B级、C级软件，应细化软件体系结构直至其表现为软件单元。5.4.2 C级软件详细设计的特殊要求a）对软件项的每个软件单元开发详细设计并形成文档；b）对软件单元和外部组件之间的任何借口、以及软件单元之间的任何接口开发详细设计并形成文档；c）验证软件详细设计的下列各项并形成文档：实现软件体系结构；不和软件体

7、系结构相矛盾。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软件集成和集成测

8、试对于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将软件集成和集

9、成测试时发现的异常输入软件问题解决过程中。5.7软件系统测试5.7.1为软件系统测试制订并实施一组测试，表达为输入触发、预期输出、通过/未通过准则和规程，以覆盖全部软件需求。5.7.2将软件系统测试时发现的异常输入软件问题解决过程。5.7.3软件在软件系统测试中做出更改时，应：a）重复测试、进行改进测试或进行补充测试，适当时验证纠正问题是所做更改的有效性；b）进行适当的测试，以证实没有引入非预期的副作用；c）实施风险管理活动。5.7.4验证软件系统测试，包括：a）所用的验证策略和测试规程是否适当；b）软件系统测试规程可追溯到软件需求；c）所有的软件需求都已测试过或以其他方式验证过；d）测试结果

10、满足要求的通过/未通过准则。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保证软

11、件发行的可重复性建立规程，确保已发行的软件产品能可靠地交付到使用地点，而没有讹误的或未授权的更改。这些规程应说明包含软件产品的媒介的生产和处理情况，适当时包括：a）复制；b）媒介标记；c）包装；d）防护；e）存储f）交付。5.9软件维护过程5.9.1制定维护计划应为进行维护过程的活动和任务，制定一项（或多项）软件维护计划。计划应说明以下内容:a）用于以下目的规程：接收;形成文档；评价；解决过程，和;跟踪。医疗器械软件发行后引起的反馈；b）进否将反馈作为问题加以考虑的准则；c）软件风险管理过程的应用；d）应用软件问题解决过程以分析和解决在医疗器械软件发行后出现的问题;e）应用软件配置管理过程管理

12、对现有系统的更改，和f）评价件实施未知来源软件（SOUP）下列亊项的规程：升级; 缺陷修复； 补丁和： 废弃。5.9.2问题和修改分析对于通过顾客反馈程序收集到的对已发行的软件产品的反溃，应形成文件并进行评价，以确定已发行的软件产品是否存在问题。应利用软件问题解决过程阐明问题报告，并对每个更改请求对已发行的软件产品以及对于其有接口的系统的影响进行分析5.9.3修改的实施应利用软件开发过程实施修改，并按照5.8发行已更改的软件系。修改可以作为软件系统完整再发行的一部分发行；或作为包含经更改的软件项的修改包和为安装此项更改的必要工具用作对现有的软件系统的更改发行。5.10软件风险管理过程见风险管理

13、控制程序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实施更改应按更改请求中的规定实施更改

14、，制造商应识别并实施由更改产生的所需重复的任何活动，包括对软件系统和软件项的软件安全性分级的更改。5.11.2.3验证更改应验证更改，包括重复已因更改失效的任何验证。 5.11.2.4规定更改的可追溯性方法应制定审核追踪，可借以追溯下列各项：a） 更改请求b） 有关的问题报告：c） 更改请求的批准5.11.2.4配置状态记录应保留包括系统配置的受控配置项的可检索历史记录。5.12软件问题解决过程5.12.1准备问题报吿应为在软件产品中检出的每个问题准备一份问题报告，问题报告按如下分类：a）类型，如纠正、预防或适应新坏境；b）范围，如更改的多少，受影响的器械模型编号，受影响的支持性附件，涉及的资

15、源，更改的时间；c）危害度，如对性能、安全性或保密性的影响。注：问题可以在软件发行之前或之后、 在制造商的组织内部或外部发现。5.12.2研究问题a） 研究问题，如有可能识别问题原因；b） 利用软件风险管理过程评价问题和安全性的相关性（第 7 章） ；c） 把研究和评价结果形成文档，和；d） 为纠正问题所需的措施拟定更改请求,或将不采取措施的理由形成文档。如果问题与安全性无关，则不必按照软件问题解决过程纠正问题。5.12.3通知相关方适当时，应通知存在问题的相关方。5.12.4应用更改控制过程应遵照更改控制过程的要求，批准并实施所有的更改请求。5.12.5保持记录应保持问题报告及其解决情况，包

16、括对其验证的记录。适当时，应更新风险管理文件。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.相关记录项目计划需求规格说明书概要设计说明书详细设计说明书系统配置文档集成测试报告软件维护计划软件发行文档软件更改请求单软件问题报告