核心概念与术语解析：彻底搞懂“目标”、“活动”、“数据”、“等级”
各位工程师朋友，咱们今天来啃几个硬骨头。DO-178C里那些“目标(Objectives)”、“活动(Activities)”、“数据(Data)”、“等级(Level)”，是不是看着就头疼？
说实话，我当年刚接触这些术语时，也绕了好一阵子。后来做项目做多了，才慢慢摸到门道。今天我就用大白话，把这些概念掰开揉碎了讲给你听。
1. 目标(Objectives) —— 你到底要证明什么？
先说说“目标”。这词听起来很虚，其实特别实在。
目标就是：你必须要达到的“证据要求”。 说白了，就是局方或者审查员想看到的东西。比如，你的需求分析做完了，你得证明“需求是完整的、正确的”。这就是一个目标。
核心要点： 目标不是“你要做什么”，而是“你要证明什么”。
我举个例子。在A级软件里，有一个目标是“需求是可验证的”。你光说“我需求写得好”没用，你得拿出证据——比如测试用例能覆盖每一条需求，或者评审记录里明确写了“需求可验证”。
我个人习惯，在项目启动时就把所有目标列成一张表。每完成一个阶段，就对照这张表打勾。这样心里踏实，审查时也不慌。
小技巧： 每个目标背后都对应着“产出物”。比如“需求完整性”这个目标，对应的产出物就是“需求评审报告”和“可追溯性矩阵”。
2. 活动(Activities) —— 你具体要干什么？
“活动”就好理解了。它就是你要做的具体工作。
比如，需求分析阶段的活动包括：编写需求、评审需求、建立追溯性等等。每个活动都有输入、输出和步骤。
活动和目标的关系是什么？ 我打个比方：
- 目标是“终点线” —— 你要证明你到了。
- 活动是“跑步过程” —— 你怎么跑过去的。
举个例子：
| 目标 | 对应的活动 |
|---|---|
| 需求是完整的 | 进行需求评审、编写需求覆盖分析 |
| 代码是符合需求的 | 进行代码走查、单元测试 |
| 测试是充分的 | 设计测试用例、执行测试、分析覆盖率 |
你看，每个目标都需要一系列活动来支撑。没有活动，目标就是空话。
注意： 活动不能“偷工减料”。我曾经见过一个项目，为了赶进度，把“需求评审”这个活动压缩成“邮件确认”。结果审查时被开了严重不符合项，因为邮件确认无法证明“评审过程是受控的”。
3. 数据(Data) —— 你的证据长什么样？
“数据”就是你的产出物，也就是证据本身。
DO-178C里定义了各种数据，比如：
- 计划数据： 项目计划、开发计划、验证计划等
- 需求数据： 系统需求、软件需求、接口需求等
- 设计数据： 软件架构、详细设计等
- 验证数据： 测试用例、测试结果、评审记录等
- 配置管理数据： 变更记录、版本记录等
这些数据不是随便写写就行的。它们必须满足“数据质量”要求。比如：
- 可读性： 别人能看懂
- 完整性： 该有的信息都有
- 一致性： 不同数据之间不矛盾
- 可追溯性： 能从一个数据找到另一个数据
我记得有一次审查，审查员问：“你的测试用例对应哪条需求？” 我翻出追溯矩阵，一条一条指给他看。他点点头，没再追问。这就是“数据”的力量。
一句话总结： 数据是你的“呈堂证供”。质量好不好，直接决定审查能不能过。
4. 等级(Level) —— 你的软件有多“危险”？
“等级”是DO-178C里最基础的概念之一。它决定了你要做多少工作、达到多严格的标准。
等级分为A、B、C、D、E五级：
| 等级 | 失效后果 | 典型应用 |
|---|---|---|
| A级 | 灾难性的 | 飞行控制、发动机控制 |
| B级 | 危险的 | 导航、通信 |
| C级 | 重大的 | 客舱娱乐、空调 |
| D级 | 轻微的 | 日志记录、非关键显示 |
| E级 | 无影响 | 开发工具、仿真模型 |
等级越高，要求越严。A级软件需要满足全部66个目标，而D级可能只需要十几个。
你想想看，如果飞行控制软件出了故障，飞机可能掉下来。所以A级软件的要求极其苛刻——每个目标都要有证据，每个活动都要受控，每个数据都要可追溯。
经验之谈： 很多项目在定级时容易“低估”。我建议你宁可定高一级，也别定低了。因为定低了，审查时发现实际影响更大，就得返工重做，那成本可就高了去了。
5. 它们之间的关系 —— 一张图说清楚
这四个概念不是孤立的。它们像齿轮一样咬合在一起。
这张图你看懂了吗？
- 等级是“天花板”，它决定了你要达到多高的标准。
- 目标是“检查清单”，告诉你需要证明哪些事情。
- 活动是“施工过程”，你通过做这些事来达成目标。
- 数据是“竣工照片”，你拿这些证据给审查员看。
举个例子：如果你的软件是C级（等级），那么“需求可验证”这个目标可能只需要简单的评审。但如果是A级，你可能需要做形式化的需求分析、多轮评审、甚至用工具验证。这就是等级对目标和活动的影响。
避坑指南： 我曾经见过一个团队，把A级软件的需求文档写得跟D级一样简单。结果审查时被要求重写，项目延期了三个月。记住：等级决定了你的“工作量”，别想着偷懒。
6. 实战中的常见误区
说了这么多，我总结几个实战中容易踩的坑：
- 混淆目标和活动： 有人把“编写需求”当成目标。不对，那是活动。目标是“需求是完整的、正确的”。
- 忽视数据质量： 数据不是“有就行”，而是要“能用”。我见过一份需求文档，写得像天书，谁也看不懂。这种数据等于没有。
- 等级定得过低： 为了省钱，把B级软件定成C级。结果审查时被要求重新定级，所有工作推倒重来。得不偿失。
- 活动与目标脱节： 做了很多活动，但没证明目标。比如你写了100个测试用例，但没写测试报告，也没分析覆盖率。审查员问：“你测试充分吗？” 你拿不出证据。
我的建议： 项目一开始，就把这四个概念的关系画成图，贴在墙上。每次开会都看一眼，确保方向没错。
好了，今天的内容就到这里。这些概念虽然基础，但理解透了，后面的章节学起来就轻松多了。