PF32 软件可追溯性分析控制程序.docxVIP

文件编号/版本号：PF32/1.0 1/7 质量管理体系程序文件 软件可追溯性分析控制程序 编制： 审核： 批准： 日期： 日期： 日期： 生效日期： 受控状态： 文件名称 软件可追溯性分析控制程序 文件编号 PF32 版本号 1.0 PAGE 6/7 目录 TOC \o 1-1 \h \z \u 1、 目的 3 2、 范围 3 3、 职责 3 4、 定义 3 5、 软件安全性级别 4 6、 风险管理要求 5 7、 生存周期模型 5 8、 软件开发策划 6 9、 软件需求分析 7 10、 软件设计 7 11、 软件编码 7 12、 验证与确认 7 13、 软件更新 8 14、 缺陷管理 8 15、 可追溯性分析 9 16、 配置管理 9 17、 现成软件 9 18、 网络安全 10 19、 软件发布 10 20、 软件部署 10 21、 软件停运 10 22、 软件开发文档 10 23、 相关文件 11 24、 质量记录 11 25、 附件 11  目的 对医疗器械软件开发进行控制，明确医疗器械软件开发、现成软件、网络安全等相关软件的可追溯性的流程和控制要求。 范围 本文件适用于作为医疗器械用途的独立软件，软件组件参照执行。本文件所述“软件”均是指医疗器械软件。 医疗器械软件的设计开发过程的可追溯性分析，还需要遵守本文件的要求。 本文件规定了软件需求分析、软件设计、软件编码、软件验证、软件确认、软件更新、风险管理、缺陷管理、网络安全、软件发布、软件部署、软件停运等过程中软件可追溯性的要求。 职责 3.1研发部负责在设计和开发过程的软件可追溯性实施，确定设计和开发的过程中保证软件的可追溯性方法，并在设计开发过程中保证软件产品的可追溯性。 3.2 其它各部门负责配合研发部实现软件的可追溯性。 定义 软件可追溯性分析：追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性和准确性。 软件需求分析过程中的可追溯性 在软件产品设计开发过程中，进行风险分析和风险评估后，对不可接受的风险，拟定相应的风险控制措施，危害清单中的每一条不可接受的风险，在风险分析报告中都有唯一的编号，具体规定见《风险管理控制程序》。 产品需求是依据产品立项策划时对产品的定义，形成的产品需求文档。针对产品需求文档中的每一条需求，都应赋予唯一的编号。具体编号规则和要求见《软件需求分析管理规程》。 依据产品需求和风险管理资料，结合软件设计开发的要求，形成软件需求文档。软件需求文档中的每一条需求，都应赋予唯一的编号，具体编号规则和要求见《软件需求分析管理规程》。 在《软件可追溯性分析报告》中，应将风险管理报告中的每一条不可接受的风险对应的编号，可对应到软件需求中的具体需求条款的编号，可以是一对一、一对多、多对一的关系，保证每一条不可接受的风险，其对应的风险控制措施在软件需求中都有具体的需求来体现。 在《软件可追溯性分析报告》中，产品需求的每一个条款的编号，可对应到软件需求中具体条款的编号，可以是一对一、一对多、多对一的关系，保证每一条产品需求，在软件需求中都有具体的需求条款来体现。 软件设计过程中的可追溯性 软件概要设计和软件详细设计的要求见《软件设计管理规程》。 软件概要设计中的每一条应由唯一的编号；软件详细设计中的每一条应有唯一的编号。 在《软件可追溯性分析报告》中，要体现软件需求中的每一条对应的软件概要设计条款编号，同时要体现软件概要设计中的每一条，对应的软件详细设计的条款号；对应关系可以是一对一、一对多、多对一的关系，保证每一条软件需求，在软件概要设计中都有对应条款，软件概要设计中的每个条款，在软件详细设计中都有对应条款。 软件编码过程中的可追溯性 针对软件概要设计和软件详细设计中的每一条，都应有对应的软件代码实现。针对软件源代码，需进行测试，测试用例需要覆盖到所有软件功能和源代码。 在《软件可追溯性分析报告》中，需体现软件结构设计和详细设计，与源代码的对应关系；同时要体现软件源代码与测试用例的关系。 软件验证过程中的可追溯性 在《软件可追溯性分析报告》中，需体现测试用例与软件设计文档中具体条款的对应关系，系统测试可验证软件需求的实现情况，系统测试用例和软件需求的条款需体现出对应关系，可以是一对一、一对多或多对一的关系。 系统测试也可验证风险管理中的风险控制措施实施的情况，在《软件可追溯性分析报告》中应体现系统测试用例