软件生存周期计划.docx

《软件生存周期计划.docx》由会员分享，可在线阅读，更多相关《软件生存周期计划.docx（11页珍藏版）》请在课桌文档上搜索。

1、软件生存周期计划编制审核批准发布日期文件更改控制记录版本日期更改人更改内容引言1.1目标和范围1.2项目简介1.3术语及定义1.4参考资料软件开发过程2.1软件开发策划2.1.1软件开发计划.2.2软件需求分析2.3软件设计2.4软件编码2.5软件系统测试错误!未定义书签。2.6缺陷管理错误!未定义书签。2.7验证与确认2.7.1验证.2.7.2确认2.8软件发布错误!未定义书签。配置管理计划3.1配置管理规范3.1.1版本计划.错误!未定义书签。3.1.2版本规范.3.1.3标签规范.103.1.4约定名称.错误!未定义书签。3.2更改控制错误!未定义书签。3.3配置状态记录错误!未定义书签

2、。软件部署错误!未定义书签。软件维护计划105.1基本要求错误!未定义书签。5.1.1接收规程要求.错误!未定义书签。1.1.2 形成文档规程要求:错误!未定义书签。1.1.3 评价要求错误!未定义书签。1.1.4 解决过程要求错误!未定义书签。1.1.5 可追溯性要求错误!未定义书签。5.2 反馈问题处理错误!未定义书签。5.3 软件问题解决过程的应用错误!未定义书签。5.4 软件更新错误!未定义书签。5.5 软件开发和测试环境维护错误!未定义书签。6软件风险管理错误!未定义书签。7软件停运108网络安全119可追溯性分析1110文件与记录控制1111现成软件111引言1 -1目标和范围说明

3、本文档的目的，所涉及的工作内容及文档的读者。1.2 软件简介说明软件产品的概要介绍。1.3 术语及缩略语术语及缩略语定义1.4 参考资料编号资料名称来源12342软件开发2.1软件开发策划根据XXX,软件开发策划形成书面的软件开发计划、风险管理计划、配置管理计划，并保持更新。2.1.1软件标识描述软件标识、适用范围、软件版本规则、产品组成。1.1.2 软件安全性级别结合软件的预期用途、使用场景和核心功能进行综合判定软件的安全性级别。1.1.3 开发标准、方法I、开发标准IEC60101-1-6可用性标准IEC62304软件生命周期过程2、方法：采用快速原型法进行软件设计，以加快软件的设计。1.

4、1.4 开发过程及各阶段的交付物软件的开发过程参照软件生存周期过程控制程序文件要求的过程进行描述说明。各阶段的活动和交付物：阶段活动交付物软件开发策划软件需求分析软件设计软件编码验证确认2.2 软件需求分析综合分析法规、标准、用户、产品、功能、性能、接口、用户界面、网络安全、警示提示等软件需求，确定风险管理、可追溯性分析、现成软件使用评估、软件确认测试计划创建、评审等活动要求，形成XXX软件需求规范、评审记录并经批准，适时更新并经批准。2.3 软件设计依据XXX软件需求规范实施软件体系架构、功能、性能、算法、接口、用户界面、单元、网络安全等设计，确定风险管理、可追溯性分析、现成软件使用评估、软

5、件验证测试计划创建、评估等活动要求，形成XXX软件设计规范、评审记录并经批准，适时更新并经批准。2.4 软件编码依据XXX软件编码规范实施，确定源代码编写与注释、现成软件使用、可追溯性分析、各级测试用例创建、评审等活动要求，形成评审记录，并适时更新。2.5 验证与确认2.5.1 验证确定源代码审核静态分析、动态分析、单元测试、集成测试、系统测试、评审等活动要求，涵盖现成软件、网络安全的验证要求，并保持相关记录，形成XXX软件验证计划、XXX软件验证报告。单元测试、集成测试、系统测试依据相应测试计划实施，涵盖现成软件、网络安全的测试要求，形成XXX软件测试计划、XXX软件测试报告以及测试记录、评

6、审记录，并适时更新02.5.2 确认确认用户测试、临床评价、评审等活动要求，涵盖现成软件、网络安全的确认要求，并保持相关记录，形成XXX软件确认计划、XXX软件确认报告。用户测试应对依据用户测试计划在真实使用环境或模拟环境下实施，涵盖现成软件、网络安全的测试要求，并保持相关记录，形成XXX用户测试记录、XXX用户测试报告。3软件更新维护3.1 基本要求软件更新控制程序。软件更新应当形成文件，涵盖现成软件、网络安全的变更控制要求，确定软件更新请求评估、软件更新策划、软件更新实施、风险管理、验证与确认、缺陷管理、可追溯性分析、配置管理、文件与记录控制、评审、用户告知等活动要求，形成相关文件和记录并

7、经批准，适时更新并经批准。软件版本变更应当与软件更新情况相匹配。验证与确认应当根据软件更新的类型、内容和程度实施相适宜的回归测试、用户测试等活动。3.1.1 软件更新来源需要将反馈的信息分类，由质量部对反馈信息进行初步分析，如果反馈的问题只是用户不理解和使用不当问题，由售后维护相关人员进行解释和处理，不作为软件更新的输入，如果质量部初步判断反馈的信息与软件设计有关，则将反馈的信息交由软件产品负责人，经评审批准后作为软件更新来源。3.1.2 文档要求：软件更新维护过程中需要形成如下一些文件：1 .软件更新请求评估报告（描述更新的问题及其风险分析）2 .软件更新策划（描述人员与时间、更新版本、类型

8、、内容、涉及相关文档的更新要求、验证与确认要求、其他相关性告知与培训）3 .软件更新说明（包含需求、风险评估、功能体系结构、详细设计等内容）4 .软件验证计划5 .软件验证报告6 .软件测试规范（必要时）7 .软件测试报告（必要时）8 .软件确认计划9 .软件确认报告验证与确认应当根据软件更新的类型、内容和程度实施相宜的回归测试、用户测试等活动。这些文档每次评审完都需要填写一份文件评审记录表或设计评审记录表，并且相关的评审人员需要签字确认。3.2软件开发和测试环境维护定期对软件开发环境和软件测试环境进行维护，包括软硬件设备、开发测试工具、网络等资源以及病毒防护、数据备份与恢复等保证措施，并形成

9、记录。描述软件的维护性要求。4软件配置管理软件开发和更新过程按照软件配置管理规范文件要求实施软件版本、源代码、文件、工具、现成软件的配置管理活动，进行配置状态记录，形成XXXXX软件配置管理计划、XXXXX软件配置管理报告。4.1 配置管理规范概要描述4.1.1 源代码对于具体的源代码文件，使用相对路径+配置管理的修订版本号作为标识。11:trunk/src/example.c:r300o对于标签中的源代码文件，也可以使用标签名+相对路径作为标识。4.1.2 版本规范软件版本使用X.Y.Z.T的四段版本。X为发布版本，对外发布，X.Y.Z.T为完整版本。发布版本和完整版本在登录界面或主界面、“

10、关于”界面体现。不影响到医疗器械安全性或有效性的软件部件或组件（可执行文件、动态库、子系统软件、下位机软件等）以及非医疗器械软件，也可使用如X.YZT的四段版本。软件版本规则需考虑网络安全的软件更新类型，各字段含义应当明确且无歧义无矛盾，软件版本变更应当符合软件版本命名规则的要求。4.1.2.1 基线由于项目开发是不断迭代的过程，因此一旦基线被确立，它在后续的开发过程中仍有可能需要变更。因此基线同样采用版本号进行管理：X.YZT。通常按照变更先后顺样版本从小到大不断增加，如1.00.02.0004.1.3 标签规范标签号按照下表进行编制。对象标签命名规范子系统源码子系统名称V模块名称LVV版本

11、号_阶段成果关键字项目源码SYS_v版本号_阶段成果关键字基线V基线类型_V版本号5软件风险管理按照风险管理控制程序文件要求实施活动，结合产品识别、分析、评价、控制和监测软件功能、接口、用户界面、现成软件、网络安全等风险，XXXXX软件风险管理计划和XXXXX软件风险分析报告6缺陷管理依据软件缺陷管理办法文件要求进行软件缺陷管理过程，形成对软件缺陷的评估和分析报告。7软件发布软件发布需要确定软件产品文件创建、软件产品与文件归档备份、软件版本识别与标记、交付形式与验证、病毒防护等要求，保证软件发布的可重复性。物理交付方式应当软件产品复制、许可授权以及存储媒介包装、标记、防护等要求，网络交付方式应

12、当确定软件产品标记、许可授权、网络安全保证等要求。8软件部署与停运依据软件部署与停运管理办法要求，并结合软件产品的特性，形成软件详细的部署和停运要求描述。9网络安全保证按照网络安全应急响应管理办法进行网络安全事件的应急响应和保持相关记录，并适时更新。10可追溯性分析依据产品可追溯性控制程序文件要求进行软件可追溯性活动，涵盖现成软件和网络安全要求，形成可追溯性分析报告，并保持更新记录。11文件与记录控制对于设计文档类文件,文件的版本号按照关于文件的分类、编号和修改标识管理规定执行。项目一般文档（会议记录）无须版本号，用日期做标签；项目评审文档跟随评审对象版本号。文档的编制和审核由指定的人员完成；软件系统的全局性文档的评审由软件负责人提出，由系统负责人组织进行评审。其他文档的评审由编制者提出，由软件负责人组织进行评审。软件系统的全局性文档由系统的负责人批准；软件的局部设计文档由软件负责人批准；软件系统的全局性文档由软件负责人向系统负责人提出申请并阐明理由，经批准后由原编制者或经软件负责人指定的人员进行修改；软件的局部设计文档的修改由软件团队内部提出，并由软件负责人指定人员进行修改。修改后的文档要通过评审与批准才能正式生效使用。12现成软件依据现成软件使用管理办法实施对现成软件的规范管理。