文件编号 | 软件生命周期控制程序 | 受控状态 | ||
拟 制 人 | 版本/修订 | A/A0 | ||
审 核 人 | 制作份数 | 1 | ||
批 准 人 | 生效日期 | 2018年10月26日 | ||
发放部门 | ||||
1. 目的
3. 适用范围
4. 适用本公司所有软件产品的设计开发、风险管理、软件测试、软件生产、软件发布、上市退市的全过程。
5. 职责
3.1
3.2
3.3
3.1质量管理部负责监督此程序文件的执行工作；
3.2IT部负责此程序文件的具体执行；
3.3生信部、生产部、销售部负责协助此程序文件的执行；
6. 程序
4.1软件安全级别的界定：
4.1.1根据YY/T 0664《医疗器械软件软件生存周期过程》的要求，按照软件系统引起的危害对于患者、操作者或者其他人员的可能影响，赋予每个软件系统一个软件安全性级别。安全性级别分为：A级、B级、C级
4.1.1.1A级：不可能对健康有伤害和损坏；
4.1.1.2B级：可能有不严重的伤害；
4.1.1.3C级：可能死亡或严重伤害
4.1.3本公司所开发的软件产品均配合本公司试剂产品使用，根据风险评定等级判定均为A级。
4.2软件的开发策划要求
4.2.1明确软件项目来源，研究项目的可行性。根据调查研究结果确认是否开展该项目，并形成完成整的《项目可行性研究报告》。
4.2.2IT部编制《项目开发计划》经总经理审批后执行。
4.2.3软件开发的每个过程都应得到评审，每个评审过程都需要形成完整的评审报告。
4.2.4在软件开发的适当阶段也可以进行验证，可采用与已证实的类似设计进行比较、计算验证、模似试验等。根据软件开发的进度编制《测试计划》。
4.3软件的需求分析要求
4.3.1T部根据市场需求、客户要求、法规标准的要求以及软件项目的开发目标确定开发该项目所需的支持与协助，拟定《软件需求说明书》。软件说明书的内容最少包含：任务概述、需求规定、运行环境的规定等。
4.3.2软件项目的分析阶段分析人员需要对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是客户尚未提出但具有真正价值的潜在需求。
4.3.3在需求评审阶段，分析人员要在用户和软件设计人员的配合下对已生成的需求规格说明和客户进行沟通，以确保软件需求的完整、准确、清晰、具体，并使客户和软件开发人员对需求规格说明的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。
4.4软件的设计要求
4.4.1软件可靠性：软件项目越庞大其可靠性越难保障。软件可靠性标志着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件的可靠性必须在设计阶段就予以确定。
4.4.2软件健壮性：是指软件对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。
4.4.3可修改性：要以科学的方法设计软件，使之有良好的结构和完备的文档，系统性能易于调整，且调整方式需要得到有效控制。
4.4.4容易理解：软件的可理解性是其可靠性和可修改性的前提。要求软件本身具有简单明了的结构。
4.4.5程序简便：在使用过程中考虑终端客户的使用，避免因使用过程繁琐造成客户使用困难。
4.4.6可测试性：可测试性是指设计一个适当的数据集合，用来测试所建立的系统，并保证系统得到全面的检验。
4.4.7安全性：能够保持用户信息、操作等多方面的安全要求，同时软件本身也要能够及时修复、处理各种安全漏洞，以提升安全性能。
4.5软件编码要求
4.5.1软件编码：是将上一阶段的详细设计得到的处理过程的描述转换为基于某种计算机语言的程序，即源程序代码。
4.5.2按照编码规范的要求进行编码活动，确保所有程序编码均能得到有效的控制。
4.5.3软件编码语言选择高级语言VB、C、C++进行编写，避免同时使用多种语言进行编辑。
4.6软件的验证与确认要求
4.6.1软件的验证人员需经过培训考核，确认可以胜任此项活动，并保存人员培训、考核的相关记录。
4.6.2软件的验证环境需的到确认，确保验证环境运行正常。
4.6.3软件验证包括：源代码审核、静态分析、动态分析、单元测试、集成测试、系统测试、评审等一系列活动。
4.6.4验证过程需形成完整的验证文档，内容包括：验证计划、验证方案、验证记录、验证报告。
4.6.5软件确认：提供客观证据认定软件满足用户需求和预期用途。包括：用户测试、临床评价、评审等一系列活动，即要保证软件满足客户需求和预期用途，又要确保软件已知剩余缺陷的风险均可接受。
4.7软件的更新要求
4.7.1软件更新：是指生产企业在软件生存周期全过程对软件所做的任一修改，亦称软件变更、软件维护。
4.7.2软件更新从更新结果角度可分为重大更新和轻微更新；
4.7.2.1重大软件更新：影响到医疗器械安全性或有效性的增强类更新，即重大增强类软件更新，应申请许可事项变更。
4.7.2.2轻微软件更新：不影响医疗器械安全性与有效性的增强类更新、纠正类更新，包括轻微增强类软件更新、纠正类软件更新，通过质量管理体系进行控制，无需申请许可事项变更，待下次许可事项变更时提交相应注册申报资料。
4.8风险管理要求
4.8.1根据《风险管理控制程序》的要求开展风险管理活动。
4.8.2风险管理活动应涵盖整个软件生命周期。
4.9缺陷管理要求
4.9.1应对所有发现的缺陷进行标识，建立《软件缺陷清单》以便能够对缺陷问题进行控制。
4.9.2对每个缺陷进行处理，采取不同方式弥补缺陷对软件造成的损害。
4.9.3按《纠正预防措施控制程序》对软件缺陷进行管理，通过采取纠和正预防措施从根本上解决缺陷困扰。
4.10可追溯性分析要求
4.10.1软件可追溯性分析是软件验证、软件确认的重要活动。分析过程包括：软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性、准确性。
4.10.2软件生存周期过程均应开展软件可追溯性分析：
4.11配置管理要求
4.11.1建立配置管理计划，明确的配置管理职责、活动和要求。
4.11.2对配置标识进行管理。
4.11.3建立软件库，并对软件库加以管理。
4.11.4明确配置项的更改并对更改过程改进行有效控制。
4.12文件与记录控制要求
文件与记录的控制要求参照《文件控制程序》、《记录控制程序》执行。
4.13现成软件使用要求
4.13.1现成软件是指生产企业未进行完整生存周期控制的软件，包括遗留软件、成品软件、外包软件。
4.13.2使用现成软件应保证医疗器械软件的安全有效性。根据现成软件的类型、特点以及业界使用情况，区分现成软件组件和外部软件环境，综合考虑现成软件的使用广泛度、技术成
熟度、售后支持程度以及功能、性能、兼容性、易用性、可靠性、维护性、可移植性、网络安全等方面要求，采用基于风险的全生命周期管理方法进行质控，特别是在采购、设计开发、上市后监测等方面。
4.14网络安全保证要求
4.14.1建立网络安全事件应急响应文件，确定网络安全事件风险管理、应急响应措施验证、用户告知、召回等活动要求，保持相关记录。
4.14.2网络安全保密性:保证数据不能被未授权的个人、实体利用或知悉的特性，即医疗器械相关数据仅可由授权用户在授权时间以授权方式进行访问。
4.14.3网络安全完整性:保护数据准确和完整的特性，即医疗器械相关数据是准确和完整的，且不被篡改。
4.14.4网络安全可得性:指根据授权个人、实体的要求可访问和使用的特性，即医疗器械相关数据能以预期方式适时进行访问和使用。
4.15软件发布要求
4.15.1确认软件所有缺陷是否得到弥补，弥补方式是否形成文档。
4.15.2软件发布前应进行全面测试，确保测试结果达到预期要求。
4.15.3软件发布前确定软件产品文件创建、软件产品与文件归档备份、软件版本识别与标记、交付形式评估与验证、病毒防护等活动要求，保证软件发布的可重复性。
4.15.4软件发布前需进行评审，并保留评审结果。
4.15.5对发布上市后的软件应建立软件维护流程。
4.16软件部署要求
4.16.1确保客户配备适宜的软件运行环境。
4.16.2确保部署软件在客户运行环境得到全面测试。
4.16.3确定交付、安装、设置、配置、用户培训等活动要求，保持相关记录。
4.16.4定期回访客户软件使用情况。
4.16.5对客户使用过程中发现的问题进行分析研究并及时解决。
4.17软件停运要求
4.17.1软件停运前需要进行市场调查，调查所有用户使用情况。
4.17.2软件停运前需提供满足客户使用的更新软件，确保客户使用过程衔接。
4.17.3软件停运后需保持停运后续用户服务、数据迁移、患者数据与隐私保护、用户告知等活动，并保持相关记录。
7. 相关文件
《风险管理控制程序》
相关记录
《软件需求报告》
《软件系统详细设计报告》
《风险管理报告》
《软件可追溯性报告》
发布评论