2、过程参考模型（PRM）：过程类别与过程组的划分
好，咱们今天聊聊ASPICE里最基础、也最容易让人迷糊的一个概念——过程参考模型（PRM）。
说实话，我刚接触ASPICE那会儿，看到什么“主要生命周期过程”、“组织生命周期过程”，头都大了。这玩意儿到底怎么分的？跟我做嵌入式开发有什么关系？
别急，我带你捋一遍。其实没那么复杂。
2.1 三大过程类别
ASPICE把所有的过程分成了三大类。你可以想象成三个大抽屉：
- 主要生命周期过程：直接跟产品开发相关的活儿
- 组织生命周期过程：公司层面、管理层面的活儿
- 支持生命周期过程：给前面两类打辅助的活儿
我个人习惯把这三大类记成“干活儿的”、“管活儿的”、“帮活儿的”。你想想看，是不是这个理？
2.1.1 主要生命周期过程
这是咱们工程师最熟悉的部分。说白了，就是从客户需求到产品交付的全链条。
我在项目中遇到过不少团队，只盯着“写代码”这一块，觉得其他都是虚的。结果呢？需求没对齐，测试用例写偏了，最后返工改到崩溃。
主要生命周期过程包含两个过程组：
- 系统工程过程组：关注系统层面的活动
- 软件工程过程组：关注软件层面的活动
嗯，这里要注意：系统工程师和软件工程师的边界经常打架。我建议你记住一句话——系统管“做什么”，软件管“怎么做”。
2.1.2 组织生命周期过程
这类过程不直接产出代码，但决定了你能不能持续、高效地产出代码。
我曾经在一个项目里，公司连基本的配置管理流程都没有。版本号乱标，基线说改就改。结果客户来审计，我们拿不出任何证据证明“哪个版本给了客户”。
组织生命周期过程包括：
- 管理过程组：项目管理、风险管理、质量保证等
- 过程改进过程组：持续优化流程本身
- 重用过程组：管理复用资产
说白了，这类过程就是“让团队跑得更稳”的保障机制。
2.1.3 支持生命周期过程
这类过程是“万金油”，哪个阶段都可能用到。
举个例子：配置管理。你在需求阶段要管文档版本，在设计阶段要管模型版本，在测试阶段要管用例版本。它贯穿始终。
支持生命周期过程包括：
- 配置管理
- 质量保证
- 验证
- 确认
- 联合评审
- 审计
- 问题解决管理
- 决策管理
核心理解： 三大类别不是孤立的。主要过程是“主角”，支持过程是“配角”，组织过程是“导演”。缺一个，戏都演不好。
2.2 过程组的划分逻辑
ASPICE把过程进一步分组，目的是让审核和评估更有条理。咱们重点看两个最常用的过程组。
2.2.1 系统工程过程组（SYS）
这个组关注的是“系统”层面。什么是系统？硬件+软件+机械+人机交互，所有东西合在一起。
我记得有一次做ADAS项目，系统工程师定义了一个“自动紧急制动”的需求。软件团队直接开干，结果发现硬件传感器根本达不到那个响应速度。这就是典型的系统级和软件级脱节。
系统工程过程组包含的关键过程：
- SYS.1：需求挖掘
- SYS.2：系统需求分析
- SYS.3：系统架构设计
- SYS.4：系统集成与集成测试
- SYS.5：系统合格性测试
你想想看，如果SYS.2没做好，后面的软件设计就是空中楼阁。
2.2.2 软件工程过程组（SWE）
这是咱们软件工程师的主战场。从软件需求到软件测试，全在这里。
软件工程过程组包含：
- SWE.1：软件需求分析
- SWE.2：软件架构设计
- SWE.3：软件详细设计与单元构建
- SWE.4：软件单元验证
- SWE.5：软件集成与集成测试
- SWE.6：软件合格性测试
我的经验： 很多团队在SWE.3和SWE.4之间跳来跳去，觉得“先写代码再补测试”也行。千万别！我吃过这个亏。单元验证不是走过场，它是你代码质量的最后一道防线。
2.2.3 管理过程组（MAN）
这个组容易被工程师忽略。但说实话，没有管理过程，项目就是一团乱麻。
管理过程组包括：
- MAN.3：项目管理
- MAN.5：风险管理
- MAN.6：测量
我曾经在一个项目里，项目经理说“我们不需要风险管理，反正也预测不准”。结果呢？芯片供货延期，项目直接停摆三个月。嗯，从那以后，我再也不敢轻视MAN.5了。
2.3 过程类别与过程组的关系
咱们用一张表来总结，这样更清楚：
| 过程类别 | 过程组 | 典型过程 | 我的理解 |
|---|---|---|---|
| 主要生命周期过程 | 系统工程（SYS） | SYS.1~SYS.5 | 系统级“做什么” |
| 主要生命周期过程 | 软件工程（SWE） | SWE.1~SWE.6 | 软件级“怎么做” |
| 组织生命周期过程 | 管理（MAN） | MAN.3, MAN.5, MAN.6 | 管人管风险管度量 |
| 组织生命周期过程 | 过程改进（PIM） | PIM.3, PIM.4 | 持续优化流程 |
| 组织生命周期过程 | 重用（REU） | REU.2 | 复用管理 |
| 支持生命周期过程 | 支持（SUP） | SUP.1~SUP.10 | 配置、质量、验证等 |
避坑指南： 我曾经见过一个团队，把所有过程都往“软件工程”里塞。需求分析用SWE.1，系统测试也用SWE.6。这是不对的。系统级的事情归SYS，软件级的事情归SWE。混在一起，审核员一眼就能看出来。
2.4 为什么你要理解这个划分？
你可能会问：“我就是一个写代码的，知道这些分类有什么用？”
用处大了去了。
- 第一，明确职责边界。 系统工程师和软件工程师各管各的，别互相甩锅。
- 第二，知道什么时候该做什么事。 需求阶段别急着写代码，测试阶段别想着改架构。
- 第三，应对审核。 审核员问“你们怎么保证需求可追溯？”你得知道这是SYS.1和SWE.1的衔接问题。
说白了，理解PRM的划分，就是理解ASPICE的“世界观”。你知道了游戏规则，才能玩好这个游戏。
好，这一章就到这里。下一章咱们聊聊具体的过程实施，看看每个过程到底要产出什么“证据”。