4. 软件生命周期过程：DO-178C定义的三大过程与模型选择

各位同学，今天我们聊一个核心话题——软件生命周期过程。说白了，就是你的飞控软件从无到有，再到拿到适航证，到底要走哪些路、做哪些事。

DO-178C把整个生命周期归纳为三大过程：计划过程、开发过程、综合过程。我刚开始接触这个标准时，觉得这分类太简单了。后来真刀真枪干项目才发现，这三大过程就像盖房子的三张图纸——少了哪一张，房子都得塌。

4.1 三大过程：计划、开发、综合

我们先看计划过程。这是整个认证的起点，也是最容易被轻视的一环。我见过不少团队，上来就写代码，结果后面补文档补到崩溃。

计划过程的主要输出包括：

• PSAC（软件适航计划）——这是你的“认证路线图”
• SDP（软件开发计划）——定义开发流程和工具
• SCMP（软件配置管理计划）——版本控制、变更管理
• SQAP（软件质量保证计划）——谁来检查、怎么检查

开发过程呢？就是真正干活的过程。它又细分成几个子过程：

1. 需求过程——从系统需求到软件需求
2. 设计过程——架构设计、详细设计
3. 编码过程——写代码、单元测试
4. 集成过程——把模块拼起来

综合过程，很多人把它理解成“测试”，其实不止。它包含验证、确认、评审、审计等一系列活动。我习惯把它叫做“证明过程”——证明你的软件确实满足需求，确实安全可靠。

4.2 生命周期模型选择：V模型 vs 敏捷

说到生命周期模型，DO-178C并没有强制要求你用哪种模型。它只关心你能不能达到目标。但实践中，选错模型会让人很痛苦。

V模型是航空领域的传统选择。为什么？因为它天然适合认证。

V模型的优点很明显：

• 每个阶段都有明确的输入输出
• 可追溯性天然成立
• 适合文档驱动的认证审查

缺点呢？太死板。需求变了，整个V要重来。我在一个项目中就吃过这个亏——客户中途改了需求，我们不得不重新走一遍V，工期直接翻倍。

敏捷模型呢？这几年越来越多人尝试。DO-178C的补充文档DO-331专门讲了如何用敏捷方法做认证。

敏捷的优势：

• 快速响应需求变化
• 早期发现风险
• 团队协作效率高

但敏捷在认证中也有坑：

• 文档容易滞后
• 可追溯性维护成本高
• 审查员可能不习惯

我个人建议：如果你做Level A或B的项目，老老实实用V模型。Level C或D，可以考虑混合模型——比如用V模型做整体框架，内部迭代用敏捷。

4.3 过程目标与输出

DO-178C为每个过程都定义了目标（Objectives）。这些目标不是摆设，是审查员检查的重点。

我们拿开发过程举例，它的目标包括：

1. 软件需求是完整的、正确的、一致的
2. 软件架构是可实现的、可验证的
3. 源代码实现了设计
4. 集成后的软件满足需求

每个目标都有对应的输出（Outputs）。比如：

过程	目标示例	输出示例
计划过程	定义了生命周期和标准	PSAC、SDP、SCMP、SQAP
需求过程	需求是完整的、可验证的	软件需求规格、需求追溯矩阵
设计过程	架构满足需求	设计文档、接口定义
编码过程	代码符合标准	源代码、单元测试报告
综合过程	验证活动已完成	测试用例、测试结果、评审记录

4.4 知识体系框架图

下面这张图，是我自己总结的三大过程与生命周期模型的关系。你看一眼就能明白整体逻辑。

这张图你看懂了吗？三大过程是横向的，生命周期模型是纵向的。你选V模型，那计划、开发、综合就按V的节奏走。你选敏捷，那三大过程就要适应迭代的节奏。

4.5 我的实践心得

最后，分享几点我这些年踩过的坑：

• 计划别偷懒。我见过太多团队，PSAC写得很漂亮，实际执行完全走样。结果审查时被问得哑口无言。计划不是写给别人看的，是给自己用的。
• 可追溯性要早建。需求到代码到测试，这条链子一旦断了，补起来比重新写还痛苦。我建议用工具自动维护追溯矩阵，别用手工Excel。
• 综合过程别等到最后。很多人以为综合就是最后做测试。其实评审、走查、分析这些活动，越早做越好。早发现问题，改起来成本低。

嗯，今天就讲到这里。记住一句话：过程是手段，安全是目的。别为了过认证而做过程，要为了做安全而做过程。