软件生存周期过程控制程序

对医疗器械软件产品的设计和开发过程进行控制，确保产品满足用户的需求和期望以及有关标准、法令、法规的要求。2.适用范围适用于本公司产品软件部分的开发与测试过程活动的控制和管理。本文件适用于作为医疗器械用途的独立软件，软件组件参照执行。本文件所述“软件”均是指医疗器械软件。医疗器械软件的设计开发过程除需要按《设计和开发控制程序》执行外，还需要遵守本文件的要求。本公司软件过程活动范围为：确定开发者和组织、定义并开发软件的活动。其活动划分为：软件开发策划、软件需求分析、软件设计、软件编码、验证与确认、软件更新、风险管理、缺陷管理、可追溯性分析、配置管理、文件与记录控制、现成软件、网络安全、软件发布、软件部署、软件停运等活动的要求等阶段。3.引用YY∕T0664-2020《医疗器械软件软件生存周期过程》4.职责1）研发部负责软件部分的开发过程及其结果的质量控制，标准化管理。2）质管部负责软件过程和成果的质量监控；负责软件生存周期文档质量管理。5.定义医疗器械软件：旨在包括在被开发的医疗器械内的已开发的软件系统，或者预期本身用作医疗器械而开发的软件系统。软件系统：编制以完成特定功能或一组功能的软件项的整合体。软件项：计算机程序中任一可识别的部分，包括顶级的软件系统、底级的不能进一步分解的软件单软件单元：不可再分的软件项。可用于软件配置管理或测试的目的。独立软件：具有一个或多个医疗目的或用途，无需医疗器械硬件即可完成自身预期目的，运行于通用计算平台的软件。软件组件：具有一个或多个医疗目的或用途，控制、驱动医疗器械硬件或运行于医用计算平台的软件。软件安全性级别：基于软件风险程度分为轻微、中等和严重，其中轻微即软件不可能产生伤害，中等即软件可能直接或间接产生轻微伤害，严重即软件可能直接或间接产生严重伤害或导致死亡。软件验证：通过提供客观证据认定软件开发、软件更新某一阶段的输出满足输入要求。软件确认：通过提供客观证据认定软件满足用户需求和预期目的。版本：某一配置项的已标识了的实例。配置项：能在给定的基准点上单独标识的实体。回归测试：要求用于确定系统组件的更改没有对功能性、可靠性或性能产生不良影响，并且没有引入另外的缺陷的测试。软件可追溯性分析：追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性和准确性。软件更新：生产企业在软件生存周期全过程对软件所做的任一修改，亦称软件变更或软件维护。软件停运：生产企业在软件生存周期过程末期终止对软件的售后服务和销售，亦称软件退市。现成软件：生产企业未进行完整生存周期控制的软件，包括遗留软件、成品软件、外包软件。遗留软件：生产企业以前开发但现在不能得到足够开发记录的软件。成品软件：已开发且通常可得到的，但生产企业未进行完整生存周期控制的软件。外包软件：生产企业委托第三方开发的软件。网络安全：保持医疗器械相关数据的保密性、完整性和可得性。生存周期模型：一个包含过程、活动和任务的框架，这些过程、活动和任务涉及软件产品的开发、运行和维护，跨越从需求定义到终止使用的系统生存周期。6.软件安全性级别6.1安全性级别分类由软件开发负责人在采取风险控制措施之前，结合软件的预期用途、使用场景和核心功能进行综合判定软件的安全级别。A级：不可能对健康有伤害或损坏。B级：可能有不严重的伤害。C级：可能死亡或严重伤害。严重伤害的范围包括：危及生命；造成人体功能的永久损害或人体结构的永久性损坏；或需要内科或外科介入以防止人体功能的永久损害或人体结构的永久性损伤。6.2管理要求如果软件失效引起的死亡或者严重伤害的风险，随后由硬件风险控制措施降低到可接受水平，或者降低失效后果或者降低由失效引起的死亡或者严重伤害的概率，软件的安全性级别可从C降低到B（不能直接由C降低到A如果软件失效引起的非严重伤害风险同样通过硬件风险控制措施降低到可接受水平，软件的安全性级别可从B降低到A。应依据风险控制措施所控制的危害的可能影响，对实施风险控制措施起作用的每个软件系统赋予一个软件安全性级别。当一个软件系统分解为软件项，以及当一个软件项又进一步分解为几个软件项时，此类软件的软件项应继承原软件项（或软件系统）最高的安全性级别（注：以C级为最高，B级次之，A级最低）。7.生存周期模型7.1一般要求软件开发负责人根据产品的安全等级、复杂程度、预期用途、开发方式等方面综合考虑，选择合适的软件生存周期模型。软件生存周期过程质量保证活动的要求应当与软件的安全性级别相适宜。7.2常见的软件生存周期模型1）瀑布模型：单程的开发周期，由实施单一时间开发过程组成。2）增量式开发模型：多重的开发周期。确定客户要求并规定系统要求，然后以一系列的构建其余的开发。第一个构建包含策划能力的一部分，下一个构建增加更多能力，等等，直到系统完整为止。3）渐进模型：多重的开发周期。也在构建中开发系统，但是不同于增量式开发模型策略的是，客户要求和系统需求事先部分确定，然后在每个后续的构建中细化。4）V模型：V模型从整体上看来，就是一个V字形结构，由左右两边组成。左边的下画线分别代表了需求分析、概要设计、详细设计、编码。右边的上画线代表了单元测试、集成测试、系统测试和验收测试。它的意义在于，表明了测试过程中存在的不同的级别，描述了这些测试阶段和开发阶段的对应关系。8.工作流程与规范8.1工作流程图8.2软件开发策划（立项）应当在软件生存周期过程持续提供充分、适宜、有效的软件开发和测试环境，建立《软件开发和测试环境管理制度》规定软硬件设备、开发测试工具、网络等资源以及病毒防护、数据备份与恢复等保证措施，明确软件开发和测试环境定期验证、更新升级、病毒防护等活动要求，形成软件开发和测试环境维护档案。软件开发策划应当确定软件需求分析、软件设计、编码实现、软件测试、验证与确认、风险管理、缺陷管理、配置管理、可追溯性分析、文件与记录控制、现成软件使用、网络安全保证、评审等活动计划，形成《软件立项策划报告》等文件记录，并适时更新。8.3软件需求分析软件开发人员（或成立的软件开发组）应当综合分析相关法规与标准的要求，所属开发产品或项目的需求（用户、产品、功能、性能、接口、用户界面、网络安全、警示提示等软件需求）；确定待开发软件在功能、性能、接口和运行环境、操作界面等方面的要求，确定风险管理、可追溯性分析、现成软件使用评估、软件确认测试计划创建、评审等活动要求；形成《软件需求规格说明书》和评审记录并经批准，适时更新并经批准。需求阶段的可追溯性要求，应当分析软件需求与产品需求及风险管理的关系。8.3.2实施步骤可包括：1）仔细研究所属开发产品或项目的需求，确定配套软件的功能、性能等方面的要求，必要时对顾客使用要求和现实环境进行现场调查；2）明确客户使用的需求和适用的法律法规、标准的要求；3）确定人机界面注：根据需要，人机界面也可以在概要设计阶段来确定。）4）编写《软件需求规格说明书》；5）需求评审。8.3.3完成标志向研发部负责人提交《软件需求规格说明书》并通过评审。8.3.4评审《软件需求规格说明书》作为软件过程中后续阶段的输入，放行前应进行评审，以确保其是充分和适宜的。评审人员包括研发部、医学部、生产部、行政部、质管部、营销部等部门负责人或指定代表，必要时可以邀请用户代表或公司内外有关专家参加，评审意见记入《设计评审表》。如评审没有通过，则必须根据评审意见对《软件需求规格说明书》进行修改，直至通过为止。8.4软件开发计划软件开发人员（或成立的软件开发组）根据在《软件立项策划报告》中对项目的对软件开发后续阶段提出以下具体要求：1）软件产品的质量目标和要求；2）过程活动、文件和资源的需求；3）所需的验证、确认、监控、检验和测试活动，以及软件的接收准则；4）软件文档的编制计划、评审点设置及评审内容、归档计划；5）测试过程及所需的文件和记录；6）软件的版本管理计划与方案；7）软件的缺陷管理；8）软件的风险管理；9）软件的维护规范。8.4.2开发计划的审批嵌入式软件开发计划实施前应伴随主机进行立项分析，得到研发部和质管部的审核确认后开始执行，以确保其适宜性。8.4.3开发计划的更新随着软件设计、开发的进展，在适当时，开发计划可以更新，更新后的开发计划应得到重新审批。8.4.4评审《软件设计开发计划任务书》作为软件过程中后续阶段的输入，放行前应进行评审，以确保其是充分和适宜的。评审人员包括研发部、医学部、生产部、行政部、质管部、营销部等部门负责人或指定代表，必要时可以邀请用户代表或公司内外有关专家参加，评审意见记入《设计评审表》。如评审没有通过，则必须根据评审意见对《软件设计开发计划任务书》进行修改，直至通过为止。8.5软件设计软件开发人员根据《软件需求规格说明书》（REC-QP35-02），确定软件系统总体结构以及各模块之间的关系，定义各功能模块的接口、控制接口；实施软件体系架构、功能、性能、算法、接口、用户界面、单元、网络安全等设计，必要时设计全局数据库/数据结构，规定设计限制。包括重要的算法和数据结构，为编写源代码提供必要的说明。确定风险管理、可追溯性分析、现成软件使用评估、软件验证测试计划创建、评审等活动要求，完成测试计划与记录的初稿，形成软件设计规范和评审记录并经批准，适时更新并经批准。软件设计规范包括《软件概要设计说明》和《软件详细设计说明》，简单的软件也可直接形成1份单独的软件设计规范文件，《软件详设计说明》。设计阶段可追溯性要求，应当分析软件设计与软件需求之间的关系。8.5.2设计要求1）在设计目标系统的整体结构时，应力争使其具有好的形态。功能模块的作用范围应在其控制范围之内；2）在设计目标系统的总体结构时，应降低模块接口的复杂性，提高目标系统的可移植性3）充分考虑提高功能实现的效率。8.5.3实施步骤建立目标系统的总体结构。1）对于大型系统，可按主要的软件需求划分成子系统，然后为每个子系统定义功能模块及各功能模块间的关系，并描述各子系统的接口界面；2）对于一般系统，可按软件需求直接定义目标系统的功能模块及各功能模块间的关系；3）确定系统总体界面风格以及各功能模块应遵守的界面规范。4）给出每个功能模块的功能描述，数据接口描述，外部文件及全局数据定义；5）设计数据库或数据结构，编写《软件概要设计说明》、《软件详设计说明》。大的项目应独立编写《数据库设计说明》。6）完成测试计划与记录初稿的编制。8.5.4软件缺陷管理按照《软件缺陷管理制度》(SMP-RD-025)进行缺陷的记录。描述缺陷现象，采取措施，关闭缺陷。8.5.5完成标志向研发部负责人提交《软件概要设计说明》、《软件详设计说明》并通过评审。8.5.6评审研发部负责人应组织相关人员进行软件设计评审。评审意见填入《设计评审表》如评审没有通过，，则必须根据评审意见对《软件概要设计说明》、《软件详设计说明》进行修改，直至通过为止。8.6软件编码软件编码应当依据《软件概要设计说明》、《软件详设计说明》实施，确定源代码编写与注释、现成软件使用、可追溯性分析、各级测试用例创建、评审等活动要求，形成评审记录，并适时更新。源代码编写与注释应当符合《软件编码制度》文件的要求。测试用例应当保证软件验证与确认测试的充分性、适宜性、有效性。编码阶段可追溯性要求，应当分析源代码与软件设计、源代码与测试用例的关系。8.7编程实现软件开发人员利用选定的程序设计语言、数据库语言或制作工具进行源程序编写，实现《软件概要设计说明》、《软件详设计说明》中规定的功能，并进行程序模块和集成测试，以验证各模块功能和接口的正确性，及其与详细设计说明的一致性。完成操作手册的制订，至少提前五个工作日完成测试计划与记录的定稿。8.7.2实现的要求1）使用标准的程序设计语言；2）根据相应的编程规范来编写程序；3）为了提高程序的可理解性，必须在源程序中加入适当的注解；4）尽量采用增加程序可读性的排版格式；5）编程后要进行自我测试，自我测试时，不仅要考虑对合法的输入产生测试用例，而且要对非法的、非预期的输入产生测试用例。既要对正常的处理路径进行测试，而且要考虑对出错处理路径进行测试；6）程序模块的补充设计文档、自我测试用例、预期结果及测试结果的记录应存档保留；7）对软件模块进行版本管理。8.7.3实施步骤可包括1）对每个程序模块用所选定的程序设计语言进行编码；2）对所编制的程序进行自我测试。3）编制《软件配置管理制度》及记录。8.7.4完成标志向生产部提交软件包、《安装验收手册》、《软件配置管理制度》、测试报告等。8.8软件验证软件验证应当确定源代码审核、静态分析、动态分析、单元测试、集成测试、系统测试、评审等活动要求，涵盖现成软件、网络安全的验证要求，并保持相关记录。单元测试、集成测试、系统测试应当依据相应测试计划实施，涵盖现成软件、网终安全的测试要求，确定缺陷管理、风险管理、可追溯性分析、评审等活动要求，形成相应软件测试记录、测试报告以及评审记录，并适时更新。白盒测试应当确定语句、判定、条件、路径等测试覆盖率要求，并与软件安全性级别相适宜。黑盒测试应当保证同一软件项的开发人员和测试人员不得互相兼任。验证阶段可追溯性要求，应当分析各级测试用例与软件设计、系统测试与软件需求、系统测试与风险管理的关系。具体依据《设计和开发控制程序》中设计开发验证的要求执行。8.9软件测试研发部应另行指派经专业技术培训的测试人员负责并主持对软件进行测试。验证《软件需求规格说明书》的要求，以确保软件开发的输出满足输入的要求。将软件安装在与所设计生产（或试制）的产品配套的设备上或通用设备上，根据《软件需求规格说明书》中定义的全部功能和性能要求编写《测试计划》及《测试用例》。进行实际操作如：源代码审核、静态分析、动态分析、单元测试、集成测试、系统测试、评审等活动，涵盖现成软件、网络安全的验证要求，以测试整个软件系统，验证软件产品是否达到软件需求的要求。测试完毕，编写《测试报告》，对测试中所发现问题的处理情况、测试的经验与教训等进行总结。8.9.2完成标志提交：填写完全的《测试计划》、《测试用例》和《测试报告》。8.9.3审核由质管部负责对软件测试结果进行审核。审核内容包括但不限于如下几个方面：1）检查软件测试的内容是否覆盖了软件全部的功能与性能要求；2）测试中发现的问题是否都得到了解决并进行了回归测试；3）软件的版本管理是否有效；4）测试文档是否完备。研发部负责人应组织相关人员进行软件测试评审。评审意见填入《设计评审表》，如评审没有通过，需要寻找原因，采取措施直至通过为止。8.10软件确认软件确认应当确定用户测试、临床评价、评审等活动要求，涵盖现成软件、网络安全的确认要求，并保持相关记录。保证软件满足用户需求和预期目的，且软件已知剩余缺陷的风险均可接受。用户测试应当依据用户测试计划在真实使用环境或模拟使用环境下实施，涵盖现成软件、网络安全的测试要求，确定缺陷管理、风险管理、可追溯性分析、评审等活动要求，形成用户测试记录、测试报告以及评审记录并经批准，适时更新并经批准。用户测试人员应当具备适宜的软件产品使用经验，或经过培训具备适宜的软件产品使用技能,确认阶段可追溯性要求，应当分析用户测试与用户需求、用户测试与风险管理的关系。具体依据《设计和开发控制程序》中设计开发确认的要求执行。8.11确认评审为确保产品的软件部分满足规定的使用要求或已知的预期用途的要求，根据软件开发计划的安排对开发的软件产品进行确认评审。软件的确认评审由研发部组织，软件开发负责人主持进行，评审人员包括研发部、医学部、生产部、行政部、质管部、业务部等部门负责人或指定代表，必要时可以邀请用户代表或公司内外有关专家参加，完成《用户测试计划》、《用户测试报告》、《临床评价报告》等评审意见记入《设计评审表》。8.11.2实施步骤在软件测试的基础上，由评审小组对准备交付的软件产品和文档进行评审。确认评审的主要内容是:1）软件的功能、性能等是否满足《软件需求规格说明书》的规定要求；2）文档的正确性、完整性和规范化等方面是否满足规定要求；3）评审通过后，生成评审报告，填写《设计评审表》。4）保证软件满足用户需求和预期目的，且软件已知剩余缺陷的风险均可接受。5）软件确认评审通过后，可以打包发布，正式装配产品。8.11.3完成标志研发部负责人在《设计评审表》上签字确认评审通过。8.12软件设计开发的更新建立《软件更新控制程序》涵盖现成软件、网络安全的变更控制要求，确定软件更新请求评估、软件更新策划、软件更新实施、风险管理、验证与确认、缺陷管理、可追溯性分析、配置管理、文件与记录控制、评审、用户告知等活动要求，形成相关文件和记录并经批准，适时更新并经批准。软件版本变更应当与软件更新情况相匹配。更新后的验证与确认应当根据软件更新的类型、内容和程度实施相适宜的回归测试、用户测试等活动。具体依据《设计和开发控制程序》中设计开发变更的要求执行。9.风险管理要求软件的设计开发和维护需要在质量管理体系和风险管理体系（具体按《风险管理控制程序》（QP-34）执行）的要求下进行，在软件整个生存周期内都需要考虑风险因素，结合产品识别、分析、评价、控制和监测软件功能、接口、用户界面、现成软件、网络安全等风险，确保软件在没有任何不可接受的风险的情况下完成预期目的。如果危害可能由软件系统未能象规定的那样起作用引起，则此项失效的概率应假定为100%。也就是说，不能通过降低危害发生概率来降低软件的风险级别，仅可通过外部风险控制措施降低软件的风险级别。10.缺陷管理应当建立《软件缺陷管理制度》，确定软件缺陷评估、软件缺陷修复、回归测试、风险管理、配置管理、评审等活动要求，形成《软件缺陷分析报告》（REC-SMPRD025-01）以供评审。使用缺陷管理工具保证软件质量，并贯穿于软件生存周期全过程。常用的缺陷管理工具:easybug、QualityCenter(QC)、BugFree(禅道)、Bugzilla、MantisBugTracker(MantisBT)、JIRA等等软件缺陷应纳入《数据分析控制程序》的要求。11.可追溯性分析建立《软件可追溯性分析控制程序》，涵盖现成软件、网络安全的控制要求，形成《软件可追溯性分析报告》以供评审。使用可追溯性分析工具保证软件开发、软件更新过程满足可追溯性要求，并贯穿于软件生存周期全过程。12.配置管理建立《软件配置管理制度》规范软件版本、源代码、文件、工具、现成软件等控制要求，确定配置标识、变更控制、配置状态记录等活动要求。使用配置管理工具保证软件质量，并贯穿于软件生存周期全过程。13.现成软件建立《现成软件管理制度》，并满足以下要求。现成软件的采购过程应根据软件的类型、使用方式、对产品质量影响程度，确定分类管理、质量控制、供应商审核等活动要求。应当与供应商签订外包软件质量协议，明确外包软件需求分析、交付形式、验收方式与准则、设计开发文件交付、知识产权归属、维护等要求以及双方质量责任承担要求。云计算服务协议应当明确网络安全保证、患者数据与隐私保护等责任承担要求。现成软件的使用应当形成文件，确定风险管理、验证与确认、缺陷管理、可追溯性分析、软件更新、配置管理、文件与记录控制、网络安全