第二章：系统开发流程——V模型开发流程、需求捕获与管理、系统架构设计原则
各位同学，大家好。今天我们聊聊系统开发流程。说实话，这个主题听起来有点枯燥，但它是整个安全关键系统的骨架。骨架不正，后面长出来的肉全是歪的。
我在航电领域摸爬滚打了十几年，见过太多项目因为流程问题翻车。有的团队上来就写代码，写到一半发现需求没对齐；有的架构设计拍脑袋，结果集成测试时发现接口对不上。嗯，这些坑我都踩过。今天咱们就好好掰扯掰扯，怎么用V模型把这事儿理顺。
2.1 V模型开发流程——为什么是V，而不是直线？
先问大家一个问题：传统的瀑布模型，就是需求→设计→编码→测试，一条直线走到底，有什么问题？
问题大了去了。你想想看，需求阶段犯的错，要到测试阶段才能发现。中间隔了几个月甚至一年。那时候再改需求，成本高得吓人。我有个项目，需求里漏了一条“系统在电源瞬断后必须5秒内恢复”，结果到系统集成测试才发现。改？整个底层架构都要动，最后延期了三个月。
V模型的核心思想，就是“早验证、早反馈”。左边是分解过程，右边是集成验证过程。每一层都有对应的验证活动。
我个人习惯把V模型画成下面这样：
需求分析 ──────────────→ 系统验收测试
↓ ↑
系统设计 ──────────────→ 系统集成测试
↓ ↑
详细设计 ──────────────→ 单元测试
↓ ↑
编码 ──────────────→ 代码审查看到了吗？左边每下降一层，右边就对应上升一层。说白了，你在需求阶段就要想好怎么验收，在设计阶段就要想好怎么集成测试。这不是什么高深理论，这是血的教训换来的经验。
核心要点：V模型不是让你先做完左边再做右边，而是左右并行思考。左边做需求，右边同时准备验收用例。左边做设计，右边同时准备集成测试用例。
2.2 需求捕获与管理——别让需求“飞一会儿”
需求捕获，听起来很学术。说白了就是搞清楚：这个系统到底要干什么？
但问题来了。客户说“我要一个安全的飞控系统”。什么叫安全？是故障后能降级运行，还是故障后必须立即停机？这两个需求对应的设计完全不同。
我建议用以下几个步骤来捕获需求：
- 利益相关者访谈——找飞行员、维护人员、适航审定专家聊。别只跟项目经理聊，他不懂技术细节。
- 场景分析——把系统放在真实使用场景里推演。比如“飞机在雷暴天气下飞行，系统应该怎么响应？”
- 需求分类——功能需求、性能需求、安全需求、接口需求，分门别类整理好。
- 需求评审——拉上所有相关方，一条一条过。我曾经在评审会上发现一条需求写的是“系统应具有高可靠性”。什么叫高？99.9%还是99.999%？这种模糊表述必须量化。
我的小技巧：每条需求都要有唯一编号，并且要可测试。如果一条需求你写不出测试用例，那它就不是一条好需求。比如“系统响应时间应小于50ms”，这就是可测试的。而“系统应运行流畅”，这就是废话。
需求管理工具方面，我个人推荐用DOORS或者Polarion。但工具只是辅助，关键是流程。我曾经见过一个团队，用Excel管理需求，结果版本混乱，有人改了需求没通知其他人，最后集成时发现对不上。嗯，那场面，相当精彩。
2.3 系统架构设计原则——别把架构搞成“屎山”
架构设计，说白了就是搭骨架。骨架搭得好，后面加功能、改bug都轻松。骨架搭得烂，每改一行代码都像在拆炸弹。
在安全关键系统里，我特别强调以下几个原则：
2.3.1 模块化与分层
把系统拆成若干模块，每个模块职责单一。模块之间通过明确定义的接口通信。这样做的好处是：
- 可以独立开发和测试每个模块
- 某个模块出问题，不影响其他模块
- 方便复用，下次做类似项目直接拿来用
举个例子，飞控系统可以分成：传感器管理模块、导航解算模块、控制律计算模块、执行机构管理模块。每个模块独立运行，通过ARINC 653分区机制隔离。
2.3.2 高内聚低耦合
这个原则说了几十年了，但真正做到的团队不多。我见过一个项目，所有功能都塞在一个大函数里，美其名曰“性能优化”。结果呢？改一个bug，三个功能跟着崩。
高内聚的意思是：一个模块内部的东西，应该紧密相关。低耦合的意思是：模块之间，尽量少依赖。
避坑指南：我曾经在一个项目中，为了“方便”，让两个模块直接共享全局变量。结果测试时发现，模块A改了变量，模块B没来得及更新，导致系统误判。从那以后，我强制要求所有模块间通信必须通过接口函数，不允许直接访问全局变量。这个习惯救了我很多次。
2.3.3 冗余与容错
安全关键系统，必须考虑“万一出错了怎么办”。冗余不是简单的“多放一套”，而是要有策略。
常见的冗余策略包括：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 双机热备 | 主备同时运行，主故障时备立即接管 | 飞控计算机 |
| 三模冗余 | 三个模块同时计算，多数表决输出 | 传感器数据 |
| 降级运行 | 部分故障时，系统以简化模式继续运行 | 显示系统 |
我个人偏好三模冗余。虽然成本高，但安全等级也高。你想想看，飞机在天上，两个传感器数据不一致，你信哪个？三模冗余可以投票，少数服从多数，这样心里踏实。
2.3.4 确定性行为
安全关键系统最怕什么？不确定性。系统在什么输入下产生什么输出，必须是确定的、可预测的。
这就要求：
- 避免动态内存分配（malloc/free），因为分配失败不可预测
- 避免递归调用，因为栈深度不可控
- 使用固定优先级调度，而不是动态调度
我记得有一次，一个同事在代码里用了递归，说“就几层，没事”。结果在极端情况下，递归深度达到了100层，栈溢出了。系统直接复位。嗯，从那以后，我们的编码规范里明确禁止递归。
2.4 小结
今天讲了三个东西：V模型、需求管理、架构设计原则。它们不是孤立的，而是一个整体。V模型告诉你什么时候做什么事，需求管理告诉你做什么事，架构设计告诉你怎么做。
下一章我们会深入讲需求分析的具体方法，包括如何写出一份让开发人员和测试人员都满意的需求文档。到时候我会分享一些我踩过的坑，保证让你少走弯路。
好了，今天就到这里。有什么问题，咱们课后交流。