3. 软件开发计划：SDP文档结构、开发流程定义、里程碑设定、资源与角色分配

好，咱们进入第三章。软件开发计划，简称SDP。这玩意儿，说白了就是整个软件开发的「施工蓝图」。没有它，你的项目就像没头苍蝇，尤其是在医疗软件这种高风险的领域。

我见过不少团队，上来就写代码，觉得计划是浪费时间。嗯，我年轻时也这么想。直到有一次，一个项目因为资源分配不清，测试和开发互相扯皮，最后延期了三个月，差点错过注册窗口。从那以后，我再也不敢轻视SDP了。

3.1 SDP文档结构：骨架要搭牢

一份合格的SDP，结构必须清晰。我个人习惯，把它分成几个核心模块。你想想看，如果文档结构都乱七八糟，评审员怎么相信你的开发过程是受控的？

我建议至少包含以下部分：

• 引言与范围：说明这份SDP适用于哪个软件、哪个版本。别小看这个，我遇到过项目后期发现SDP和实际产品对不上号的尴尬事。
• 参考文档：列出所有引用的标准（比如IEC 62304本身）、公司流程文件等。这是审计时的救命稻草。
• 定义与缩写：把SDP、SRS、SDS这些术语写清楚。团队里新来的同事，或者审核员，都需要这个。
• 开发流程定义：这是核心，我们下一节细讲。
• 里程碑与交付物：明确什么时候该干什么事，产出什么。
• 资源与角色分配：谁负责写代码？谁负责测试？谁负责审批？必须白纸黑字写清楚。
• 风险管理与变更控制：计划赶不上变化，但变化必须受控。

3.2 开发流程定义：V模型是主流，但别死板

IEC 62304并没有强制你用什么开发模型。但说实话，在医疗领域，V模型是最常见的。为什么？因为它把验证和确认活动，跟开发活动一一对应起来了，非常直观。

一个典型的V模型流程，我把它拆解成几个阶段：

1. 需求分析阶段：输出《软件需求规格说明书》（SRS）。
2. 架构设计阶段：输出《软件架构描述文档》（SAD）。
3. 详细设计阶段：输出《软件设计说明书》（SDS）。
4. 编码与单元测试阶段：输出代码和单元测试报告。
5. 集成测试阶段：验证模块间接口。
6. 系统测试阶段：验证是否满足SRS。
7. 确认测试阶段：在真实或模拟环境中，确认满足用户需求。

我曾经在一个项目中，把V模型用得很「死」。每个阶段必须完全结束才能进入下一阶段。结果呢？需求一变，整个流程都要重来，效率极低。后来我学会了引入「迭代」的思想。比如，在架构设计阶段，就可以对核心模块进行原型编码，提前发现风险。这不违反V模型，反而让它更灵活。

3.3 里程碑设定：别只设一个「项目结束」

里程碑是什么？就是项目路上的「打卡点」。没有里程碑，你根本不知道项目是快了还是慢了。我建议，至少设定以下几个里程碑：

里程碑名称	关键交付物	评审要点
M1: 需求基线	SRS（已评审）	需求是否完整、可测试、无歧义？
M2: 设计基线	SAD, SDS（已评审）	架构是否满足安全要求？设计是否可追溯？
M3: 代码冻结	所有代码、单元测试报告	代码覆盖率是否达标？静态分析是否通过？
M4: 测试完成	系统测试报告、确认测试报告	所有已知缺陷是否已处理？回归测试是否通过？
M5: 发布就绪	所有文档、可执行文件、发布说明	是否满足软件安全等级要求？

每个里程碑，都必须有正式的评审会议。评审不通过，就不能进入下一阶段。这听起来很严格，但能避免后期的大返工。我记得有个项目，在M1阶段没认真评审需求，结果到了M4测试阶段才发现需求有逻辑漏洞，最后不得不修改代码，代价非常大。

3.4 资源与角色分配：人对了，事就对了

最后，也是很多SDP容易忽略的——人。你得说清楚，谁负责什么。我建议用RACI矩阵来定义角色。

RACI代表：

• R (Responsible)：执行者，具体干活的人。
• A (Accountable)：负责人，最终拍板的人。每个任务只能有一个A。
• C (Consulted)：咨询者，提供意见的人。
• I (Informed)：知会者，只需要知道结果的人。

举个例子，对于「需求评审」这个活动：

角色	需求评审	代码审查	系统测试
项目经理	A	I	A
系统工程师	R	C	C
软件开发工程师	C	R	I
软件测试工程师	C	I	R
质量保证(QA)	I	I	I

你看，这样一写，谁该干什么，一目了然。避免了「三个和尚没水喝」的情况。我见过一个项目，测试出了问题，开发说「这不是我的事」，测试说「我没权限改代码」，最后项目经理自己上手改，乱成一锅粥。这就是角色没定义清楚。

另外，资源分配不只是人，还包括工具和环境。比如，你需要指定：

• 使用什么版本控制工具（Git？SVN？）
• 使用什么静态分析工具（比如PC-lint, Coverity）
• 测试环境是模拟器还是真实硬件？
• 文档存放在哪里？谁有权限修改？

这些细节，在SDP里写清楚，能省去后续无数沟通成本。