4、过程域详解（上）：系统工程过程组（SYS.1-SYS.5）、软件工程过程组（SWE.1-SWE.6）

好，咱们今天来啃硬骨头了。ASPICE 里最核心、最绕不开的就是这两组过程域——系统工程（SYS）和软件工程（SWE）。

我个人习惯把这两组称为「干活的过程」。你想想看，没有它们，你连需求怎么来、设计怎么做、代码怎么测都不知道。很多公司找我做评估，一上来就问「老师，我们能不能跳过 SYS 直接做 SWE？」——嗯，我的回答永远是：不行。

4.1 系统工程过程组（SYS.1 - SYS.5）

系统工程，说白了就是「从客户需求到系统实现」这条链。它关注的是整个产品，不光是软件，还包括硬件、机械、甚至人机交互。

SYS.1：需求挖掘

这个过程的目的是搞清楚「客户到底想要什么」。注意，不是客户说什么你就记什么。我见过一个项目，客户说「我要一个能自动刹车的系统」，结果团队直接写了个「当检测到障碍物时刹车」。后来才发现，客户真正想要的是「在特定速度下、特定天气条件下、特定障碍物类型下才刹车」。

所以 SYS.1 要求你：

  • 识别所有利益相关方（客户、用户、法规机构、生产部门）
  • 收集原始需求（用访谈、文档、竞品分析等方式）
  • 明确需求来源和优先级
我的小技巧： 每次做需求挖掘时，我都会问自己三个问题——「谁在用？」「在什么场景下用？」「不用会怎样？」。这三个问题能帮你过滤掉至少 30% 的伪需求。

SYS.2：需求分析

需求收集完了，接下来就是分析。这一步很多人会忽略，觉得「需求都有了，直接写设计不就行了？」——大错特错。

SYS.2 的核心是：把模糊的、矛盾的、不完整的需求理清楚。比如客户说「系统响应要快」，那「快」是多少毫秒？100ms？10ms？还是 1ms？

我曾经在一个项目中，客户说「系统要支持 OTA 升级」。我们团队直接写进了需求文档。结果分析时发现，客户的车机根本没有 4G 模块，只能通过 USB 升级。这就是典型的「需求分析不到位」。

SYS.2 的输出是：

  • 经过评审的系统需求规格
  • 需求之间的追溯关系
  • 需求优先级和风险等级

SYS.3：系统架构设计

有了需求，就要开始搭架子了。系统架构设计就是决定「系统由哪些子系统组成，它们之间怎么通信」。

这里要注意，架构设计不是画几张框图就完事了。你需要考虑：

  • 功能分配（哪个功能由哪个子系统实现）
  • 接口定义（信号、协议、数据格式）
  • 关键质量属性（可靠性、安全性、可维护性）
避坑指南： 我曾经见过一个团队，架构设计时只画了模块图，没定义接口协议。结果到了集成阶段，两个子系统之间数据格式不匹配，整整返工了两个月。记住：接口定义是架构设计的灵魂。

SYS.4：系统集成与集成测试

子系统做完了，就要把它们拼起来。SYS.4 关注的是「集成策略」和「集成测试」。

我个人习惯用「增量集成」的方式。先集成核心功能，再逐步加入外围功能。这样如果出了问题，能快速定位到是哪个模块的问题。

SYS.4 的关键输出：

  • 集成策略（大爆炸？增量？还是持续集成？）
  • 集成测试用例（覆盖所有接口和交互场景）
  • 集成测试报告

SYS.5：系统合格性测试

最后一步，验证整个系统是否满足客户需求。注意，这里不是「单元测试」也不是「集成测试」，而是「端到端的系统级测试」。

比如一个 ADAS 系统，SYS.5 要测试的是：在真实道路场景下，系统能不能正确识别行人、车辆、交通标志。而不是只测某个传感器的数据对不对。

SYS.5 的输出：

  • 系统测试用例（覆盖所有系统需求）
  • 测试结果和缺陷报告
  • 合格性判定（是否满足验收标准）

4.2 软件工程过程组（SWE.1 - SWE.6）

好，系统层面的事说完了，接下来咱们聚焦到软件。SWE 过程组就是「从软件需求到软件实现」这条链。

SWE.1：软件需求分析

系统需求下来了，软件团队要从中提取出「软件需要做什么」。注意，系统需求里可能包含硬件、机械的内容，软件团队要过滤出只跟软件相关的部分。

比如系统需求说「系统在 100ms 内响应」，那软件需求就要细化成「软件从接收到传感器信号到输出控制指令的延迟不超过 50ms」。

SWE.1 的输出：

  • 软件需求规格
  • 软件需求与系统需求的追溯矩阵
  • 软件需求评审记录

SWE.2：软件架构设计

软件架构设计，就是决定「软件由哪些模块组成，模块之间怎么调用」。这里我建议用分层架构，比如：应用层、中间件层、驱动层。

为什么要分层？因为分层能降低耦合度。你想想看，如果所有代码都写在一个大文件里，改一个功能可能影响十个地方。分层之后，每层只关心自己的事，改起来就轻松多了。

关键点： 软件架构设计必须考虑「运行时」和「开发时」两个视角。运行时关注的是模块之间的通信和调度；开发时关注的是代码的组织和依赖关系。

SWE.3：软件详细设计与单元构建

架构搭好了，就要开始写代码了。SWE.3 要求你先做详细设计，再写代码。详细设计包括：数据结构、算法、接口签名、状态机等。

我曾经在一个项目中，团队直接跳过详细设计开始写代码。结果写到一半发现，两个模块之间的数据格式不兼容，又得回头改设计。嗯，从那以后我再也不敢跳过详细设计了。

SWE.3 的输出：

  • 软件详细设计文档
  • 源代码（符合编码规范）
  • 单元测试用例

SWE.4：软件单元验证

代码写完了，要测。SWE.4 关注的是「单元测试」——也就是对每个最小的代码单元（函数、方法、模块）进行测试。

单元测试要做到什么程度？我个人习惯是：语句覆盖 >= 100%，分支覆盖 >= 80%。当然，如果是安全关键系统（比如 ASIL D），要求会更高。

// 示例：一个简单的单元测试（C语言）
void test_calculate_brake_force() {
    // 输入：车速 60km/h，障碍物距离 10m
    // 预期输出：刹车力 500N
    assert(calculate_brake_force(60, 10) == 500);
    
    // 边界测试：车速为 0
    assert(calculate_brake_force(0, 10) == 0);
    
    // 异常测试：距离为负数
    assert(calculate_brake_force(60, -1) == 0);
}

SWE.5：软件集成与集成测试

单元测完了，要把它们拼起来。SWE.5 和 SYS.4 类似，但这里集成的是「软件模块」，而不是「系统子系统」。

集成测试要关注：模块之间的接口是否匹配、数据传递是否正确、时序是否满足要求。

SWE.5 的输出：

  • 集成测试用例
  • 集成测试报告
  • 缺陷记录

SWE.6：软件合格性测试

最后一步，验证软件是否满足软件需求。注意，这里不是测「代码有没有 bug」，而是测「软件功能是否完整、性能是否达标」。

比如一个车载娱乐系统，SWE.6 要测试的是：导航功能是否正常、蓝牙连接是否稳定、语音识别是否准确。而不是只测某个按钮能不能点。

SWE.6 的输出：

  • 软件测试用例（覆盖所有软件需求）
  • 测试结果和缺陷报告
  • 合格性判定

4.3 总结一下

系统工程过程组（SYS.1-SYS.5）和软件工程过程组（SWE.1-SWE.6），说白了就是两条平行线：

阶段 系统工程 软件工程
需求 SYS.1 + SYS.2 SWE.1
设计 SYS.3 SWE.2 + SWE.3
集成 SYS.4 SWE.5
测试 SYS.5 SWE.4 + SWE.6

记住一个原则：先系统后软件，先设计后实现，先单元后集成。这个顺序一旦乱了，项目大概率会出问题。

好，这一章的内容就到这儿。下一章咱们讲「支持过程组」和「管理过程组」，那些是「怎么管好这些活」的内容。到时候见。

← 上一章 📖 返回目录 下一章 →