3. 软件生命周期模型选择

医疗器械软件的生命周期模型选择，本质上不是“哪种模型更先进”的问题，而是“哪种模型能在给定风险等级、法规约束和团队能力下，以可接受的成本产出可追溯、可验证的证据”。IEC 62304 并不强制指定某一种模型，它要求的是：开发过程必须覆盖软件需求分析、架构设计、详细设计、单元实现与集成、系统测试、发布与维护，并且每一层活动都要有对应的验证证据和可追溯关系。因此，瀑布、V模型、增量、敏捷都可以用，但它们的“证据生成方式”和“变更控制方式”差异很大，直接决定了在医疗器械场景中的适用边界。

四种模型的证据结构差异

瀑布模型按阶段线性推进：需求→设计→编码→测试→发布。它的优点是阶段评审清晰、文档基线明确，适合需求在早期就能冻结的项目，例如已上市产品的维护性变更或监管要求明确的简单软件。但它的致命弱点是测试被压到后期，一旦需求理解偏差，返工成本极高，且中间阶段缺少可运行产物，风险暴露太晚。

V模型是医疗器械领域最常被引用的模型，因为它把“左侧分解”和“右侧验证”显式对应起来：用户需求对应系统测试，软件需求对应软件集成测试，架构设计对应单元验证，详细设计对应代码审查。这种对称结构天然满足 IEC 62304 对追溯性的要求，也便于在注册申报时展示“每条需求都有验证证据”。V模型适合安全等级较高（B、C 级）、需求相对稳定、需要完整设计历史文件（DHF）的项目。

增量模型把软件切成多个可独立交付的增量，每个增量内部可以走小型 V 模型。它的优势是能较早获得可运行版本，适合功能模块边界清晰、可以分批验证的产品，例如先交付参数设置与数据存储，再交付报警与趋势分析。但增量划分必须保证每个增量都能独立完成风险分析和验证，否则会出现“半成品状态下的风险失控”。

敏捷模型强调短迭代、持续反馈和可工作软件。在医疗器械中，纯敏捷通常难以直接满足法规对“预先定义的需求基线”和“完整设计历史”的要求，但“敏捷+法规裁剪”是可行的：把每个 Sprint 当作一个微型 V 模型，Sprint 内完成需求细化、实现、单元测试和集成测试，Sprint 结束产出可追溯的增量证据，并在发布前统一补齐系统级验证和风险管理文档。

按安全等级与需求稳定性裁剪

选择模型时，建议先做两个判断：软件安全等级（A/B/C）和需求稳定性（高/中/低）。A 级软件（不可能造成伤害）对过程要求最宽松，可以采用轻量瀑布或敏捷，重点保留需求、测试和发布记录即可。B 级软件（可能造成非严重伤害）需要完整的架构设计和集成测试，V 模型或“增量+V”更稳妥。C 级软件（可能造成死亡或严重伤害）必须满足 IEC 62304 全部过程要求，通常采用 V 模型，或在敏捷外层套一个 V 模型框架，确保每个 Sprint 的产出都能映射到系统级验证。

需求稳定性低时，纯瀑布和纯 V 模型都会很痛苦，因为每次需求变更都要重走一遍文档基线。此时更实际的做法是“增量+敏捷裁剪”：把需求分成“已冻结的法规必需需求”和“可演进的用户界面/工作流需求”，前者走 V 模型严格验证，后者走 Sprint 快速迭代，但所有变更都必须经过变更控制和风险再评估。

裁剪时必须保留的“不可裁剪项”

无论选择哪种模型，以下内容在医疗器械软件中不可裁剪：软件需求规格说明（含安全需求）、软件架构设计、单元实现与验证、集成与集成测试、系统测试、风险分析与管理、可追溯性矩阵、配置管理、问题解决、发布版本记录。可以裁剪的是：文档的详细程度、评审的形式（正式评审会 vs. 同行评审记录）、工具链的复杂度、迭代周期的长度。例如，一个 A 级软件可以把详细设计合并到代码注释和单元测试说明中，但 B/C 级软件必须保留独立的详细设计文档或等效的模型化设计描述。

一个可操作的模型选择判断路径

实际项目中，可以按以下顺序判断：第一步，确定软件安全等级；第二步，评估需求在项目周期内的变更概率；第三步，评估团队对法规文档的熟练度；第四步，选择模型并明确裁剪边界。若安全等级为 C 且需求稳定，选 V 模型；若安全等级为 C 但需求演进快，选“V 框架 + Sprint 迭代”；若安全等级为 B 且模块边界清晰，选增量模型；若安全等级为 A 且团队敏捷成熟，可选敏捷并保留最小法规证据集。

最后需要强调：模型选择不是一次性的，可以在项目不同阶段切换。例如，前期用敏捷做原型和需求探索，进入正式开发后切换为 V 模型完成验证和注册证据链。关键是每次切换都要重新评估风险、更新开发计划，并确保追溯关系不中断。