3. 软件生命周期与风险管理过程映射

在医疗器械软件的风险管理工程中，IEC 62304 与 ISO 14971 是两套必须同时满足、但关注点不同的标准体系。IEC 62304 规定的是“软件生命周期过程”——即软件从需求、架构、详细设计、单元实现、集成、系统测试到发布、维护、停用的工程活动；ISO 14971 规定的是“风险管理过程”——即如何识别危险、估计和评价风险、实施控制措施并监控其有效性。两者不是并列关系，而是同一产品开发活动中两条必须持续交汇的线索。理解它们的接口，核心就是回答一个问题：软件生命周期中的每一个工程活动，分别向风险管理过程提供什么输入，又从风险管理过程接收什么约束？

一、映射的基本逻辑：双向接口而非单向流程

很多团队把风险管理理解为“在开发完成后补一份风险文档”，这是典型的单向思维。正确的映射是双向的：风险管理过程向软件生命周期输出“安全需求”和“控制措施约束”，软件生命周期向风险管理过程回传“实现证据”和“验证结果”。例如，风险分析识别出“输液泵流速设置错误可能导致过量输注”这一危险，其风险控制措施可能是“软件对流速上限进行硬限制并给出确认提示”。这条控制措施一旦确定，就转化为软件需求（IEC 62304 的 5.2 软件需求分析活动），并在架构设计、详细设计、单元实现、集成测试中被逐层落实；而测试结果又必须回写到风险管理文档中，作为控制措施有效性的验证证据。

因此，映射的关键不是画一张“先做A再做B”的时序图，而是建立一张接口关系图：标明每个生命周期活动与风险管理活动之间的输入输出关系、触发条件和回写路径。

二、开发过程与风险管理过程的活动对应

IEC 62304 的软件开发过程主要分为 5.1 软件开发策划、5.2 软件需求分析、5.3 软件架构设计、5.4 软件详细设计、5.5 软件单元实现与验证、5.6 软件集成与集成测试、5.7 软件系统测试、5.8 软件发布。ISO 14971 的风险管理过程则包括风险管理策划、风险分析、风险评价、风险控制、综合剩余风险评价、风险管理评审、生产和生产后活动。两者的对应关系可以按以下方式落地：

• 5.1 软件开发策划 ↔ 风险管理策划：软件开发计划中必须明确风险管理活动的时间点、责任人、评审节点和输出文档。例如，在计划中规定“软件需求评审前必须完成初步风险分析”“系统测试前必须完成风险控制措施验证”。
• 5.2 软件需求分析 ↔ 风险分析、风险控制：风险分析输出的危险、可预见事件序列和风险控制措施，直接转化为软件安全需求。每条安全需求应有唯一编号，并追溯到对应的危险编号。示例：危险 H-012（流速设置错误）→ 控制措施 RC-012（流速上限硬限制）→ 软件需求 SR-045（当设定流速超过 200 mL/h 时，软件拒绝执行并提示“超出安全范围”）。
• 5.3 软件架构设计 ↔ 风险控制措施分配：架构设计决定风险控制措施由哪个软件项、哪个模块或哪一层实现。例如，流速上限限制可以放在“参数校验模块”中实现，也可以放在“电机控制模块”中实现，架构决策会影响控制措施的可靠性和失效模式。
• 5.4 详细设计、5.5 单元实现与验证 ↔ 风险控制措施的具体实现：详细设计需要说明控制措施的算法、边界条件、异常处理；单元测试需要覆盖控制措施的边界值和失效场景。例如，针对 SR-045，单元测试用例应包括：设定值 199、200、201 mL/h 三个边界点，以及输入为负数、非数字、超大数据时的处理。
• 5.6 集成测试、5.7 系统测试 ↔ 风险控制措施验证：集成和系统测试需要验证控制措施在完整系统中的有效性，包括正常路径、异常路径和接口交互。测试结果应记录在风险管理文档中，作为“风险控制措施已验证”的证据。
• 5.8 软件发布 ↔ 综合剩余风险评价、风险管理评审：发布前必须确认所有安全需求已实现并验证，所有风险控制措施已落实，剩余风险已评价并接受。发布评审应包含风险管理评审的结论。

三、维护过程与风险管理过程的接口

IEC 62304 的维护过程（6.x）包括问题报告、问题分析和修改实施。维护阶段的风险管理接口尤为关键，因为软件修改可能引入新的危险或使原有控制措施失效。具体接口包括：

• 问题报告 ↔ 风险分析触发：任何与安全相关的问题报告（如现场故障、异常报警、用户操作困惑）都应触发风险分析，判断是否产生新的危险或使原有风险估计发生变化。
• 修改实施 ↔ 风险控制措施再验证：软件修改后，必须重新验证受影响的风险控制措施是否仍然有效。例如，修改了参数校验模块的代码，就必须重新执行 SR-045 相关的单元测试和系统测试。
• 修改发布 ↔ 风险管理文档更新：每次修改发布后，风险管理文档中的危险清单、控制措施清单、验证记录都应同步更新，保持可追溯性。

四、映射的落地载体：需求追溯矩阵

将上述接口关系固化为可执行的工程实践，最有效的载体是需求追溯矩阵。矩阵的每一行是一条软件需求，列包括：需求编号、需求描述、来源危险编号、风险控制措施编号、设计实现位置、验证测试用例编号、验证结果、剩余风险评价。通过这张矩阵，可以快速回答三个问题：每条安全需求是否都有来源？每条控制措施是否都已实现？每个实现是否都已验证？

以下是一个简化的追溯矩阵示例（示例数据，仅用于说明结构）：

这张矩阵不是一次性文档，而是贯穿开发与维护的活文档。每次需求变更、设计修改或测试执行后，都应同步更新对应行，确保风险管理与软件生命周期始终同步。

五、常见映射断点与检查要点

在实际项目中，映射最容易断裂的地方有三处：一是风险分析输出的控制措施没有转化为可测试的软件需求，导致“有措施无实现”；二是软件需求变更后没有回溯更新风险文档，导致“有实现无追溯”；三是维护阶段的修改没有触发风险再评价，导致“有修改无验证”。针对这三点，建议在开发策划中设置三个强制检查点：需求评审时检查安全需求覆盖率、系统测试前检查控制措施验证完整性、修改发布前检查风险文档同步性。

上图展示了 IEC 62304 各生命周期活动与 ISO 14971 各风险管理活动之间的接口关系。左侧为软件生命周期活动，右侧为风险管理活动，中间列标明了两者之间的具体接口内容。蓝色箭头表示生命周期活动向风险管理过程提供输入或证据，紫色箭头表示风险管理过程向生命周期活动输出约束或要求，绿色和橙色箭头分别表示维护过程和生产后活动的特殊接口。这张图的核心价值在于：它把“什么时候做什么、谁给谁什么”直接标在了活动之间，而不是停留在标准条款的罗列上。

总结来说，IEC 62304 与 ISO 14971 的映射不是两张独立流程图的简单叠加，而是通过需求追溯、控制措施分配、验证证据回写三条主线，把软件工程活动和风险管理活动编织成一张可追溯、可验证、可维护的网络。掌握这张网络的结构和接口，是医疗器械软件风险管理工程从“合规文档”走向“工程实效”的关键一步。