4. 开发计划（SDP）：软件开发计划、标准与流程的定义
说实话，很多团队拿到DO-178C的认证要求，第一反应就是「先写个SDP吧」。
这个想法没错，但容易走偏。我见过不少项目，SDP写了几百页，结果开发团队根本不看——因为写得像天书，全是套话。
我个人习惯是：SDP不是写给别人看的，是写给自己团队用的。它应该像一张地图，告诉你每一步该怎么走，遇到坑怎么绕。
4.1 什么是SDP？它到底管什么？
SDP的全称是Software Development Plan，也就是软件开发计划。它是DO-178C里最顶层的一份计划文档。
你想想看，一个航空软件项目，少则几十人，多则几百人。如果没有一份统一的计划，每个人按自己的习惯来写代码、做测试，那最后肯定乱成一锅粥。
SDP要回答三个核心问题：
- 做什么：软件的生命周期模型、开发活动、输出产物
- 怎么做：用什么工具、遵循什么标准、怎么评审
- 谁来做：角色分工、职责定义、沟通机制
核心要点：SDP必须与项目实际匹配。不要照搬模板，否则审核员一眼就能看出来。
4.2 软件开发流程：从需求到代码的路径
DO-178C并没有强制要求你用瀑布模型还是敏捷开发。但它要求你定义清楚流程，并且能证明这个流程是可控的。
我参与过一个项目，团队想用敏捷开发，结果被审核员质疑：「你们的Sprint迭代怎么保证需求追溯？」
后来我们花了很大力气去解释，才勉强通过。所以我的建议是：航空软件项目，老老实实用V模型或者增量模型，别整花活。
下面这张图是我常用的流程框架，你可以参考：
4.3 软件开发标准：三条腿走路
DO-178C要求你定义三类标准，缺一不可。我称之为「三条腿的凳子」：
| 标准名称 | 管什么 | 常见问题 |
|---|---|---|
| 软件需求标准 | 需求怎么写、怎么编号、怎么追溯 | 需求描述模糊，无法测试 |
| 软件设计标准 | 架构设计、接口定义、数据结构 | 设计文档和代码脱节 |
| 软件编码标准 | 命名规范、注释规则、禁止使用的语法 | 违反MISRA-C规则 |
我的经验：编码标准里一定要明确「禁止使用动态内存分配」。航空软件里，malloc/free是禁区。我曾经在一个项目里发现有人偷偷用了，结果导致内存泄漏，差点让整个认证延期。
4.4 流程定义：别让流程成为摆设
很多团队把流程画得特别复杂，什么「变更控制流程」「问题报告流程」「配置管理流程」……画了十几张图，结果没人看得懂。
我的原则是：一个流程图，如果不能在30秒内看懂，那就是失败的。
举个例子，变更控制流程其实就三步：
- 提交变更请求（谁都可以提）
- 评估影响（CCB评审，确定等级）
- 实施并验证（修改代码、回归测试、更新文档）
嗯，这里要注意：每个变更都必须有追溯。从变更请求到代码修改，再到测试用例，一条链不能断。
4.5 工具与环境的定义
SDP里还要明确用什么工具。DO-178C把工具分为三类：
- 开发工具：编译器、链接器、代码生成器
- 验证工具：静态分析工具、测试工具
- 管理工具：需求管理、配置管理、问题追踪
我个人习惯是：工具越少越好。每多一个工具，就多一份 qualification（工具鉴定）的工作量。能用文本文件解决的问题，就别上数据库。
避坑指南：我曾经在一个项目里用了某个商业编译器，结果发现它对某些C99语法支持有问题。后来不得不打补丁，折腾了两个月。所以我的建议是：工具选型一定要提前做验证，别等到开发到一半才发现坑。
4.6 角色与职责：谁对什么负责
DO-178C要求明确每个角色的职责。常见的角色包括：
- 软件经理：负责整体计划、资源、进度
- 软件工程师：负责开发、编码、单元测试
- 验证工程师：负责评审、测试、分析
- 配置管理员：负责版本控制、基线管理
- 质量保证人员：负责过程审计、符合性检查
这里有个关键点：开发和验证必须由不同的人来做。这是DO-178C的硬性要求，不能自己写代码自己测试。
4.7 计划文档的维护
SDP不是写一次就完事的。项目过程中，计划肯定会变。比如需求变了、进度调整了、工具换了……
我的做法是：每个季度至少评审一次SDP，看看有没有需要更新的地方。每次变更都要走正式的变更控制流程，并且更新版本号。
记住：审核员会检查SDP的版本历史。如果发现计划跟实际执行不一致，那就是严重不符合项。
4.8 小结
SDP是整个DO-178C认证的基石。它不只是一份文档，更是团队的工作指南。
写SDP的时候，多想想：这份计划能让一个新人看懂吗？能让审核员信服吗？能让项目顺利通过认证吗？
如果答案都是肯定的，那你的SDP就合格了。
公众号:蓝海资料掘金营，微信deep3321