2、核心概念解析：过程参考模型、过程评估模型、能力等级定义
好，咱们进入正题。这一章要聊的三个概念，是ASPICE的骨架。你想想看，如果连这三个东西都搞不清楚，后面谈风险识别和管控，基本就是空中楼阁。
我个人习惯，每次给团队做导入培训时，都会先花半天时间把这几个概念掰开揉碎了讲。为什么？因为很多工程师一上来就盯着“我们要过几级”，结果连过程参考模型长什么样都不知道。嗯，这其实是个大坑。
2.1 过程参考模型（Process Reference Model, PRM）
说白了，过程参考模型就是一本“菜谱”。它告诉你，做汽车电子开发，应该有哪些过程，每个过程要干什么事。
ASPICE的PRM把过程分成了三大类，共30多个过程。我列个表给你看，这样更直观：
| 过程类别 | 过程ID | 过程名称 | 一句话说明 |
|---|---|---|---|
| 主要生命周期过程 | SYS.1 | 需求挖掘 | 搞清楚客户到底要什么 |
| SYS.2 | 系统需求分析 | 把客户需求翻译成技术语言 | |
| SYS.3 | 系统架构设计 | 画出系统的“骨架” | |
| 支持生命周期过程 | SUP.1 | 质量保证 | 确保过程没跑偏 |
| SUP.8 | 配置管理 | 管好你的代码和文档版本 | |
| 组织生命周期过程 | MAN.3 | 项目管理 | 管人、管钱、管进度 |
| PIM.3 | 过程改进 | 持续优化你的开发流程 |
我在项目中遇到过一件事。有个供应商说他们通过了ASPICE CL2认证，结果我一查，他们只做了SWE.1到SWE.6这几个软件过程，系统层面的SYS过程一个都没碰。你想想看，这能叫完整的ASPICE吗？
2.2 过程评估模型（Process Assessment Model, PAM）
有了菜谱（PRM），你还得有个“评分标准”对吧？这就是过程评估模型干的事。
PAM告诉你两件事：
- 过程能力怎么评——用能力等级（CL1到CL5）
- 过程实施得好不好——用过程属性（PA）来衡量
举个例子。同样是“需求分析”这个过程，A团队做完了，B团队也做完了。怎么判断谁做得好？PAM给出了9个过程属性，比如：
- PA 1.1：过程实施是否达成
- PA 2.1：实施是否被管理
- PA 3.1：过程是否被定义
每个属性打分，从0分（完全不满足）到4分（全面满足）。最后综合起来，得出一个能力等级。
我记得有一次做预评估，一个团队觉得自己肯定能过CL2。结果我拿PAM一量，PA 2.2（工作产品管理）只得了1分。为什么？因为他们虽然做了评审，但评审记录找不到了。嗯，这就是典型的“做了但没管好”。
2.3 能力等级定义（Capability Levels）
能力等级，就是大家常说的“CL1、CL2、CL3”。但很多人理解有偏差。我直接给你看官方的定义：
| 等级 | 名称 | 核心要求 | 通俗理解 |
|---|---|---|---|
| CL0 | 不完整 | 过程未实施或未达成 | 基本没做，或者做了等于没做 |
| CL1 | 已执行 | 过程实施并达成目标 | 活干完了，结果还行 |
| CL2 | 已管理 | 过程被计划、监控、调整 | 活干完了，而且有记录、有管理 |
| CL3 | 已建立 | 过程被定义并标准化 | 有一套标准流程，全公司通用 |
| CL4 | 已预测 | 过程被量化分析 | 能用数据预测结果 |
| CL5 | 已优化 | 过程持续改进 | 不断优化，越做越好 |
这里我要特别强调一点。很多公司一上来就说“我们要过CL3”。但实际情况是，你的过程连CL2的“管理”都没做到位。你想想看，没有管理，哪来的标准化？
我曾经辅导过一个团队，他们非要挑战CL3。结果审核时发现，他们的过程定义文档写得漂漂亮亮，但实际执行跟文档完全两码事。审核员一句话就怼回去了：“你们这是CL1的水平，穿了件CL3的外衣。”
所以，能力等级不是目标，而是结果。你把过程做扎实了，等级自然就上去了。
2.4 三者之间的关系
最后，我画个图帮你理清关系：
- PRM（过程参考模型）：定义“做什么”
- PAM（过程评估模型）：定义“怎么评”
- 能力等级：定义“做到什么程度”
打个比方。PRM是菜单，PAM是评委的打分表，能力等级就是最终得分。你光有菜单（PRM），没有打分表（PAM），那谁知道你做得好不好？反过来，光有打分表，没有菜单，那评什么呢？
嗯，这一章的内容就到这里。下一章我们聊聊“风险识别的方法论”，到时候我会结合具体案例，告诉你哪些地方最容易出问题。