第3章软件生命周期模型

3. 软件生命周期模型：V模型、增量模型、敏捷开发在飞控软件中的适用性分析

聊到飞控软件的开发流程，我经常被问到：「到底该用哪种生命周期模型？」

说实话，这个问题没有标准答案。但有一点我很确定——选错了模型，后面认证审核的时候会非常痛苦。我自己就吃过这个亏，所以今天想跟你好好聊聊这个话题。

V模型，说白了就是「先做左边，再做右边」。左边是需求、设计、编码，右边是单元测试、集成测试、系统测试。左右两边一一对应，像字母V一样。

为什么飞控软件偏爱V模型？

我个人习惯用V模型来做安全关键模块。原因很简单——DO-178C的认证要求里，每个需求都必须有对应的测试用例。V模型天然就满足这个要求。

举个例子。我在做某型无人机飞控时，有一个「俯仰角保护」的需求。左边我们写了详细的设计文档，右边就对应写了测试用例。认证审查员来检查时，直接拿着需求编号去查测试报告，一目了然。

  核心优势：
  每个阶段都有明确的交付物
测试与需求严格对应，认证审核容易通过
文档完整，适合安全关键系统

注意：V模型也有短板。它太「重」了，变更成本极高。我曾经在一个项目中，因为客户临时改了需求，结果从需求文档到测试用例全部重来，整整多花了两个月。

增量模型，就是把整个飞控软件拆成几个「块」，一块一块地开发、测试、交付。

你想想看，飞控软件其实可以拆成：传感器驱动模块、控制律模块、导航模块、健康监控模块等等。每个模块独立开发，最后再集成。

我什么时候用增量模型？

嗯，这里要注意。增量模型适合那些需求相对稳定，但功能模块之间耦合度不高的项目。

我记得有一次做直升机飞控，客户要求先实现基本的姿态稳定功能，再逐步加入自动悬停、航线跟踪。我们就用了增量模型。第一版只做姿态稳定，认证通过后，再开发第二版。这样风险可控，认证压力也分散了。

避坑指南：我曾经犯过一个错误——增量之间的接口定义不够清晰。结果增量2开发到一半，发现增量1的接口设计不合理，导致大量返工。所以，接口协议一定要在第一个增量就定死。

说到敏捷，很多做飞控的同行会皱眉头。说实话，我一开始也抵触。飞控软件可是关乎人命的，怎么能「敏捷」呢？

但后来我发现，敏捷不是不能用，而是要用对地方。

敏捷在飞控中的适用场景：

举个例子。我们团队曾经用Scrum开发一个飞控的「健康监控模块」。这个模块负责监控传感器状态，发现异常就报警。它本身不直接控制飞行，安全等级是DAL D。我们用两周一个Sprint，每次Sprint结束都做一次评审。效果还不错，开发效率比V模型高了30%。

但是！安全关键模块（DAL A/B）千万别用纯敏捷。DO-178C要求完整的文档链和追溯性，敏捷的「轻文档」理念在这里行不通。我见过一个团队试图用敏捷开发控制律模块，结果认证审核时被要求补了半年的文档，得不偿失。

说了这么多，你可能会问：「那你到底用哪个？」

我的答案是——混合模型。

说白了，就是根据模块的安全等级和复杂度，灵活选择。

我曾经在一个大型飞控项目中实践过这种混合模型。核心控制律用V模型，花了8个月；导航模块用增量模型，分了3个增量；地面站软件用Scrum，每两周一个版本。最后认证一次性通过，客户也很满意。

  关键原则：
  安全等级越高，流程越要「重」
变更越频繁，越要考虑增量或敏捷
接口定义必须提前，不能「敏捷」
文档可以精简，但不能缺失追溯性

嗯，最后我想说一句。模型只是工具，不是目的。我们的目标是做出安全、可靠的飞控软件，同时顺利通过认证。选模型的时候，多想想「这个模块万一出问题，后果有多严重？」——想清楚了，答案自然就有了。