夜雨聆风学习资料网

ARTICLE · 1081946

新版GMP 软件生存周期控制程序

新版GMP 软件生存周期控制程序

本文适合:【小微有源医械研发负责人、质量负责人、软件工程师、管代】

很多小微把软件当成"代码写完就上线",飞检一查,缺需求规范、缺测试记录、版本乱改。2025版GMP 第77条 + YY/T 0664-2020 把软件生存周期列为硬要求——软件不是写出来的,是"管"出来的。本文给出一套轻量化落地方案,人少也能合规。

一、为什么小微企业最容易踩坑

大厂有专职软件质量、全套测试环境、配置管理工具;小微往往"一个工程师从需求写到上线",最容易踩四个坑:①软件安全性级别没定,验证力度全凭感觉;②需求规范(SRS)缺失,需求不可追溯;③版本命名混乱,分不清重大/轻微更新;④白盒测试覆盖率无要求,代码质量无证据。本质是把"软件生存周期"当成"写代码",缺了"策划→需求→设计→编码→验证→发布→维护"的完整闭环。

二、大厂 VS 小微:软件生存周期落地对比

环节
大厂做法
小微轻量化方案
安全性级别
专职安全评估团队
按预期用途/使用场景/核心功能判 A/B/C 级,写进开发计划
过程文档
全套 CMMI 文档体系
保留核心七件:开发计划/SRS/设计/测试记录/验证确认报告/更新记录/追溯表
测试
专职测试团队+自动化
开发与黑盒测试人员分离,B/C 级补白盒覆盖率要求
配置管理
商业配置管理工具
Git/开源工具即可,版本命名规则先行
软件更新
全流程变更控制
按更新分类(重大/轻微)分流:重大走变更注册,轻微走 QMS 控制
共同底线
需求可追溯、验证有证据、版本可重现
同左

三、软件生存周期到底管什么(拆解成四件事)

① 定软件安全性级别(第一步,决定一切):按 YY/T 0664 第4.3条,软件分 A/B/C 三级——A 级(不可能产生伤害)、B 级(可能直接或间接产生轻微伤害)、C 级(可能直接或间接产生严重伤害或死亡)。级别越高,要求越严:C 级必须做体系结构设计、详细设计、单元测试、白盒覆盖率;A 级相对精简。先定级,再定工作量。

② 走八大阶段闭环:软件开发策划 → 需求分析(SRS,含功能/性能/接口/报警/网络安全等需求)→ 设计(体系结构+详细设计)→ 编码(编码规则+版本控制+现成软件合规评估)→ 验证与确认(单元/集成/系统/用户测试)→ 发布与部署 → 维护与更新 → 停运。

③ 四并行活动贯穿全程:风险管理(YY/T 0664 第7章)、配置管理(第8章:配置标识/变更控制/状态报告)、问题解决(第9章)、可追溯性分析(需求↔设计↔编码↔测试↔风险)。现成软件(开源/外包)和网络安全也要纳入:开源看许可协议,外包签质量协议,网络安全进需求/测试/维护各环节。

④ 软件更新分类(合规分水岭):按《医疗器械软件注册审查指导原则(2022年修订版)》——重大软件更新(影响安全性或有效性的增强类更新)应申请变更注册;轻微软件更新(不影响安全性或有效性的增强类、纠正类更新)通过质量管理体系控制;同时发生重大和轻微更新,遵循风险从高原则按重大处理。版本命名规则要能区分重大/轻微。

四、法规依据速查(四层地基)

依据
要点
2025版GMP 第77条
设计开发/生产/检验/仓储用软件须确认,首次使用前+更改后,方法活动与风险相适应
2025版GMP 第33/46条
信息化系统配硬件软件环境防干扰;电子记录权限/留痕/备份/电子签名
YY/T 0664-2020
医疗器械软件生存周期过程(采标 IEC 62304:2015):A/B/C 分级+全过程要求
附录独立软件(2019年第43号)
软件生存周期过程控制程序 16 项活动;版本命名/可追溯性/白盒覆盖率
软件注册审查指导原则(2022年第9号)
注册申报资料要求;重大/轻微更新分类;可追溯性涵盖现成软件与网络安全
GB/T 42061 4.1.6
QMS 计算机软件应用确认程序文件化,首次使用前确认+更改后再确认

有源专属前置:有源器械大多含软件组件(嵌入式软件)——软件随硬件注册,但软件生存周期要求同样适用;重点盯三件事:软件版本与硬件版本对应关系、固件更新与注册变更的衔接、网络安全(接口/远程升级/数据安全)。

五、小微企业直接照此执行(6步落地)

步骤1:定软件安全性级别——按预期用途/使用场景/核心功能判 A/B/C 级,写入软件开发计划,作为后续工作量依据。

步骤2:写《软件生存周期过程控制程序》——3-5 页即可,覆盖策划/需求/设计/编码/验证/发布/更新/停运 + 配置管理 + 可追溯性要求(对照附录独立软件 2.3.1 的 16 项活动,合并简化)。

步骤3:定配置管理与版本命名规则——用 Git 管源代码,版本号字段明确(如 主版本.次版本.修订),能区分重大/轻微更新;需求、设计、测试文档入配置库。

步骤4:建最小文档集——开发计划、SRS(需求规范)、设计说明、测试记录(单元/集成/系统/用户)、验证与确认总结报告、可追溯性表(需求↔测试↔风险),每阶段更新。

步骤5:验证与确认留证据——开发与黑盒测试人员分离;B/C 级按风险定白盒覆盖率要求(语句/判定/条件);系统测试覆盖全部软件需求;用户测试在真实/模拟环境执行,已知剩余缺陷风险可接受。

步骤6:软件更新分类管理——建变更请求流程:评估影响→分类(重大/轻微)→重大走变更注册+回归测试+风险更新,轻微走 QMS 控制;版本变更与更新情况匹配;更新记录、回归测试报告归档。

⚠️ 小微企业高频合规红线(请勿违规)

1. 无 SRS 或需求不可追溯 → 飞检直接缺陷,需求↔测试↔风险必须能对应;

2. 验证与确认缺证据 → 开发与测试同人、无测试记录、无覆盖率要求;

3. 版本命名混乱 → 分不清重大/轻微更新,软件更新分类失效;

4. 重大更新不走变更注册 → 影响安全有效性的更新未申报,违反注册法规(风险从高原则);

5. 现成软件/开源无合规评估 → 开源许可、外包质量协议缺失,风险未管理;

6. 网络安全无管理 → 接口、远程升级、数据安全未纳入需求与测试。

结语

软件不是写出来的,是管出来的。小微的优势是团队小、链路短、改起来快,劣势是容易"代码能跑就行"。把六步做齐:定级、写程序、配置管理、最小文档集、验证留证据、更新分类——轻量化也能过软件核查。

【免责声明】本文仅为小微有源医疗器械行业合规知识学习与交流,不构成NMPA及属地药监官方监管意见、企业合规判定的依据。具体体系搭建、注册申报,请以现行法规、指导原则及官方审评要求为准。

相关学习资料