文件编号 软件开发计划

软件开发计划文件编号：****版本号****软件开发计划版本：****产品名称：产品型号：编制:日期:审核:日期:批准:日期:目录1.质量管理体系 32.风险管理 33.软件分级 33.1软件安全分级 33.2网络安全分级 44.遗留软件 45.软件开发过程 55.1软件开发策划 55.2软件需求分析 85.3软件体系结构设计 95.4软件详细设计 95.5软件单元的实现 105.6软件集成和集成测试 105.7软件系统测试 115.8软件在系统级别应用的发布 116.软件维护过程 126.1建立软件维护计划 126.2问题和修改分析 126.3修改的实施 137.软件风险管理过程 137.1识别风险情况的软件分析 137.2风险控制措施 147.3风险控制措施的验证 147.4软件变更的风险管理 148.软件配置管理过程 158.1建立标识配置项的方法 158.2变更控制 168.3配置状态报告 169.软件问题解决过程 179.1编写问题报告 179.2调查问题 179.3通知相关方 179.4使用变更控制过程 179.5保持记录 179.6分析问题的趋势 189.7验证软件问题的解决 189.8测试文档的内容 181.质量管理体系****软件开发应符合设计开发程序的相关要求。2.风险管理软件风险管理参考YY/T0316-2016，并作为设备整体风险管理的一部分被包括在风险管理报告中。3.软件分级3.1软件安全分级根据YY/T0664，软件安全分级参考准则如下：本软件的操控部分用于****，运行部分用于执行操控部分发送过来的指令。软件失效引起的****可能会引起***风险，该风险属于****损伤，因此我们软件的风险级别定义为****级。3.2网络安全分级不适用/适用。软件实际为内部网络，不与外部进行数据交换。4.遗留软件不适用/适用。本产品不包括遗留软件。备注：根据YY/T0664-2020定义，“遗留软件legacysoftware：合法地投放市场且至今仍在销售的医疗器械软件，但其开发符合本标准现行版本的客观证据不充分”5.软件开发过程5.1软件开发策划5.1.1软件开发计划软件开发作为整体设备的一部分，流程遵照设计和开发控制程序及设计开发计划书。交付物包括设计开发输入，设计开发输出及验证确认流程。所有软件开发过程都受到文件管理流程控制。5.1.1.1开发周期计划及说明阶段描述用户需求根据临床预期目的，分析用户所需的产品需求需求分析按照使用场景，提出本设备功能需求详细设计按功能细分为不同模块，伪代码编写，逻辑分析并验证软件编码实施程序设计和代码编写单元测试各功能模块功能白盒测试，调试验证达到预期功能系统测试搭建整体软件系统，并修复bug验收测试在使用场景下进行应用测试5.1.1.2开发过程及责任方序号开发阶段资源配备描述1软件开发立项技术部设定软件开发时间节点，资源配置2产品需求分析技术部分析需求，指定明确指标功能3设计开发技术部根据设计输入，对功能进行研发4软件测试技术部根据设计输入，对功能进行测试5软件发行技术部研发完成后，发行软件，并进行版本控制6风险管理分析技术部、质量部评估产品风险5.1.1.3软件体系结构模块版本是否选配描述5.1.1.4用户界面关系描述主界面图示临床模块版本是否选配描述5.1.1.5软件与硬件结构关系组成描述软件主机5.1.2保持对软件开发计划的更新设备开发计划的更新，将会导致如下变化：-更新本文档-更新整个项目的细节-根据设计评审流程进行更新5.1.3引用系统设计和开发的软件开发计划软件需求请见《产品需求规格书》第7章及《APP需求规格书》。软件开发流程遵照设计和开发控制程序及设计开发计划书软件验证作为系统验证的一部分，包括在设计和开发验证报告报告中。5.1.4软件开发标准、方法和工具的策划软件开发参考YY/T0664标准。开发方法：编程语言：开发工具：公司：测试工具：公司：5.1.5软件集成和集成测试的策划[B、C级适用]软件部分分为主机部分及APP部分。对APP部分采用单独的验证，主机部分的软件，采用与主机系统一同验证。5.1.6软件验证策划软件整体开发计划根据产品需求规格书明确了软件需要具有的所有功能。该需求规格书中的软件功能设计规格需要根据设计和开发验证方案-软件进行验证，同时通过验证方案的符合标准并最终形成设计和开发验证报告-软件，验证报告中结果应证明产品的所有需求规格得到满足。5.1.7软件风险管理策划软件的风险管理策划参考YY/T0316进行并包括在风险管理计划和风险管理报告中。5.1.8文档的策划序号文件号文件名目的责任部门1产品需求规格书明确产品需求研发部2APP需求规格书明确APP需求研发部3设计和开发验证方案明确验证方案研发部4设计和开发验证报告根据验证结果判定验证结论研发部5设计和开发验证方案-软件明确软件验证方案研发部6设计和开发验证报告-软件根据验证结果判定软件验证结论研发部7风险管理报告评估产品相关风险研发部，质量部8软件需求与验证对照表追溯需求，验证确认及风险管理相关关系研发部5.1.9软件配置管理策划根据用户，以及企业内部对产品功能所提出的意见，项目组对意见进行审核评估，得出是否需要解决的结论。研发部门根据结论，进行针对性开发并更新版本。更新版本后，对新版本进行持续跟踪维护，以发现潜在风险和缺陷。5.1.10拟受控的支持项开发工具：****，公司：****测试工具：****公司：****5.1.11验证前软件配置项的控制采用配置管理工具Git对配置项进行管理5.1.12识别和避免常见软件缺陷采用开发工具****的代码分析插件ESLint即时地检查和修复常见的代码问题5.2软件需求分析5.2.1定义来自系统需求的软件需求并将其形成文件软件整体开发计划根据产品需求规格书及APP需求规格书明确了软件需要具有的所有功能。5.2.2软件需求的内容见产品需求规格书及APP需求规格书5.2.3将风险控制措施纳入软件需求见产品需求规格书及APP需求规格书5.2.4医疗器械风险分析的再评价软件风险分析作为设备风险分析的一部分进行评价。后续风险分析将会根据日常发现和客户流程进行。5.2.5更新需求软件需求将会更具客户需要，风险以及可用性进行更新。软件将会根据设计变更评审流程进行更新，并在放行之前完成需求规格和验证的评审。5.2.6验证软件需求软件作为设备的一部分，已经根据设计和开发验证方案-软件进行验证，同时通过验证方案的符合标准并最终形成设计和开发验证报告-软件。5.3软件体系结构设计5.3.1将软件需求转换为体系结构见5.1.1.3软件体系结构5.3.2为软件项接口开发体系结构不适用。5.3.3规定未知来源软件项的功能和性能需求见产品需求规格书及APP需求规格书5.3.4规定未知来源软件项所要求的系统硬件和软件部件配置CPU存储器硬盘显示器5.3.5确定风险控制所必须的隔离/[非C级]5.3.6验证软件体系结构见软件验证与需求对照表及设计和开发验证报告-软件5.4软件详细设计5.4.1将软件细分为软件单元共分为以下7个模块模块版本是否选配描述5.4.2为每个软件单元开发详细设计/[非C级]5.4.3为接口开发详细设计/[非C级]5.4.4验证详细设计/[非C级]5.5软件单元的实现5.5.1实现每个软件单元****包括主机以及控制软件。每一个软件部分都包括其软件架构，请见产品需求规格书及APP需求规格中的。5.5.2建立软件单元的验证过程见设计和开发验证报告-软件5.5.3软件单元的验收准则见设计和开发验证报告-软件5.5.4附加的软件单元验收准则/[非C级]5.5.5软件单元的验证见设计和开发验证报告-软件5.6软件集成和集成测试5.6.1集成软件单元不适用5.6.2验证软件集成不适用5.6.3软件集成测试不适用5.6.4软件集成测试的内容不适用5.6.5评价软件集成测试规程不适用5.6.6进行回归测试不适用5.6.7集成测试记录的内容不适用5.6.8使用软件问题解决过程不适用5.7软件系统测试5.7.1为软件需求建立测试项见设计和开发验证方案-软件5.7.2使用软件问题解决过程测试过程中，如果发现有任何反常输入，应将该异常结果进行记录，进行内部分析，必要时进行变更并进行评审。在当前软件开发过程中，暂未发现任何异常结果。5.7.3变更后再测试当在软件系统测试期间因发现异常对软件进行变更，变更后需要进行测试，以验证纠正问题时所作变更的有效性，同时适用时进行测试和风险管理，以确定未引入非预期的副作用和不可接受的风险。当前软件开发过程中，暂未发现任何异常结果，因此暂无变更后再测试。5.7.4评价软件系统测试根据设计和开发验证方案-软件进行产品验证，同时根据形成的设计和开发验证报告-软件可以证明产品符合产品产品需求规格书及APP需求规格中的相关需求。5.7.5软件系统测试记录的内容请见设计和开发验证方案-软件和设计和开发验证报告-软件5.8软件在系统级别应用的发布5.8.1确保软件验证的完成软件已经经过验证，所以结果通过验证方案的相关需求。5.8.2将已知的剩余反常形成文件暂无剩余反常。5.8.3评价已知的剩余反常暂无剩余反常。5.8.4将所发布的版本形成文件所有文件都已根据文件控制进行管控和保存。5.8.5将所发布软件的创建过程形成文件见APP安装说明文档5.8.6确保活动和任务的完成采用Coding工具确保活动和任务以及相关文档均完整齐全5.8.7将软件归档系统软件部分已经进行归档。软件源代码已保存至coding。5.8.8确保所发布软件的可靠交付软件作为设备的一部分，在设备交付患者之前，将会载入设备。根据生产流程确保交付软件的准确无误。6.软件维护过程6.1建立软件维护计划本软件升级取决于用户的反馈意见,在收集用户的反馈意见后，项目组对意见进行审核评估，通过后，研发部门进行研发，并推出一个更新的版本，同时对新的版本进行持续跟踪维护，以发现潜在缺陷和风险。6.2问题和修改分析6.2.1形成文件并评价反馈6.2.1.1监视反馈对于已发布软件的反馈作为设计变更的一部分通过内部反馈来进行发起。6.2.1.2形成文件并评价反馈每一个用户或内部反馈在经过存档和分析后将会进入用户反馈和投诉程序。根据该程序对反馈内容进行分析，以确定是否设计软件问题，实际或潜在的不良事件及对规范的偏离。6.2.1.3评价问题报告对安全的影响根据用户反馈和投诉程序，对每一项问题报告进行分析，以确定是否会对已发布的软件产生影响以及产生何种影响，并分析是否需要通过变更软件加以解决。6.2.2使用软件问题解决过程当发现软件问题后，参考第9章的解决过程进行处理。6.2.3分析变更需求当根据第9章进行分析之后，如需要提交变更请求，评审组应对变更对软件的影响进行分析。6.2.4批准变更请求根据设计变更流程，批准软件变更。6.2.5与用户和监管机构沟通当批准变更请求之后，需要根据变更涉及内容进行分析，以确定：是否需要进行产品变更是否可以在修改实施后，直接发布以告知用户6.3修改的实施6.3.1使用已建立的过程在变更批准后，需根据第5章进行相关活动的实施。6.3.2修改后软件系统的再发布当修改后，需要按照5.8要求，确定软件已完成所有验证需求。7.软件风险管理过程7.1识别风险情况的软件分析7.1.1识别可能促成危险情况的软件项软件相关风险已经根据YY/T0316进行分析并包括在风险管理报告中7.1.2识别促成危险情况的潜在原因软件相关风险已经根据YY/T0316进行分析并包括在风险管理报告中7.1.3评价已公开的未知来源软件反常清单暂未发现7.1.4将潜在原因形成文件不适用7.2风险控制措施7.2.1确定风险控制措施软件相关风险已经根据YY/T0316进行分析并包括在风险管理报告中7.2.2在软件中实施的风险控制措施软件相关风险已经根据YY/T0316进行分析并包括在风险管理报告中7.3风险控制措施的验证7.3.1验证风险控制措施软件相关风险已经根据YY/T0316进行分析并包括在风险管理报告中7.3.2将可追溯性形成文件可追溯性见可软件需求与验证对照表、7.4软件变更的风险管理7.4.1分析与医疗器械软件安全相关的变更当软件发生变更时，需要分析该变更是否：a)引入了促成危险情况另外的潜在原因；b)需要附加的软件风险控制措施。7.4.2分析软件变更对现有风险控制措施的影响当软件发生变更时，需要分析该变更是否：a)对现有风险控制措施造成影响；b)需要附加的软件风险控制措施。7.4.3基于分析实施风险管理活动软件相关风险已经根据YY/T0316进行分析并包括在风险管理报告中8.软件配置管理过程8.1建立标识配置项的方法软件包括控制端软件和设备内部的运行固件。8.1.1嵌入式软件的名称：全自动****嵌入式软件。型号:****。发布版本：****。完整版本的命名规则8.1.2控制软件的名称：全自动****控制软件。型号:****。发布版本：****。完整版本的命名规则8.1.2标识未知来源软件不适用。无未知来源软件。8.1.3标识系统配置文档硬件配置：部件配置CPU存储器硬盘显示器软件环境：软件名版本制造商功能网络条件：网络条件描述网络架构网络类型带宽需求8.2变更控制8.2.1批准变更请求在变更请求批准后，参考8.1标识进行变更。8.2.2实施变更在实施变更后，需要识别因变更而需要重复的任何活动，包括对软件安全级别的识别。8.2.3验证变更在实施变更后，应对变更内容进行验证，并重复因变更而失效的验证，并考虑5.7.3和9.7。8.2.4为变更的可追溯性规定方法应保持如下各项之间关系和依赖