3、过程参考模型(PRM)：过程类别与过程组、生命周期过程、过程目的与成果
好，咱们今天聊聊ASPICE里最核心的骨架——过程参考模型，也就是PRM。
说实话，我刚接触ASPICE那会儿，看到那一堆过程名称和编号，头都大了。什么MAN.3、SWE.1、ACQ.4……感觉像在背密码。后来我才明白，PRM其实就是一张地图，告诉你汽车软件开发这件事，到底要干哪些活，谁先谁后。
3.1 过程类别与过程组：先分大类，再分小组
ASPICE把所有的过程分成了三大类，我习惯叫它们“三大板块”：
- 主要生命周期过程（Primary Life Cycle Processes）：这是干活的主线，从接需求到交付产品。
- 支持生命周期过程（Supporting Life Cycle Processes）：这是辅助线，帮主流程跑得更顺。
- 组织生命周期过程（Organizational Life Cycle Processes）：这是管理层，定规矩、管资源。
每个大类下面又细分了过程组。举个例子，主要生命周期过程里，就有：
| 过程类别 | 过程组 | 典型过程举例 |
|---|---|---|
| 主要生命周期过程 | 获取与供应（ACQ/SPL） | ACQ.4 供应商监控 |
| 系统开发（SYS） | SYS.1 需求挖掘、SYS.2 系统需求分析 | |
| 软件开发（SWE） | SWE.1 软件需求分析、SWE.6 软件测试 | |
| 集成与测试（INT/TST） | SYS.4 系统集成测试 | |
| 支持生命周期过程 | 支持过程组（SUP） | SUP.1 配置管理、SUP.9 问题解决管理 |
| 组织生命周期过程 | 管理过程组（MAN） | MAN.3 项目管理、MAN.5 风险管理 |
嗯，这里要注意，过程组不是随便分的。每个组里的过程，在项目里往往是前后脚的关系。比如你做完SYS.2系统需求分析，紧接着就要做SYS.3系统架构设计。这个顺序，我个人建议在项目计划里就固定下来。
3.2 生命周期过程：从生到死的完整链条
什么叫生命周期过程？说白了，就是一个产品从“有想法”到“被淘汰”的全过程。在ASPICE里，它特指从客户需求到产品交付、再到维护的完整链条。
我举个例子，你想想看：
- 获取过程（ACQ）：客户说“我要一个能自动泊车的系统”。
- 系统需求分析（SYS.2）：我们把客户需求翻译成技术语言，比如“超声波雷达探测距离0.3-2.5米”。
- 软件需求分析（SWE.1）：软件工程师说“好，我来写控制算法”。
- 软件测试（SWE.6）：写完了，测一测，看能不能停进去。
- 系统集成测试（SYS.4）：把软件装到车上，实际跑一圈。
- 交付与维护（SPL.2）：交付给客户，后续有问题再修。
你看，这就是一个完整的生命周期。每个过程都不是孤岛，它们环环相扣。我在项目中遇到过最典型的坑，就是跳过SYS.2直接写代码。结果呢？代码写完了，发现客户要的是“侧方停车”，我们做成了“倒车入库”。
核心要点：生命周期过程必须覆盖从“概念”到“退役”的全阶段。缺了任何一个，你的过程模型就是不完整的。
3.3 过程目的与成果：每个过程存在的意义
每个过程都有两个核心要素：过程目的和过程成果。
过程目的，就是“为什么要做这个事”。比如SWE.1软件需求分析，它的目的是“建立并维护软件需求”。听起来很废话对吧？但实际执行时，很多人会跑偏。
过程成果，就是“做完这事，你得拿出什么来”。还是SWE.1，它的成果包括：
- 软件需求被定义并分类
- 软件需求与系统需求建立了双向追溯
- 软件需求被评审并达成一致
- 等等
我给大家一个实用的表格，看看SWE.1的目的和成果到底长什么样：
| 过程ID | 过程名称 | 过程目的 | 过程成果（部分） |
|---|---|---|---|
| SWE.1 | 软件需求分析 | 建立并维护软件需求 | 1) 定义软件需求 2) 建立双向追溯 3) 评审并达成一致 |
| SWE.6 | 软件测试 | 验证软件是否满足需求 | 1) 制定测试策略 2) 执行测试用例 3) 记录测试结果 |
| SUP.9 | 问题解决管理 | 确保问题被识别、分析、解决 | 1) 问题被记录 2) 问题被分析 3) 问题被关闭 |
我的小技巧：每次做过程定义时，先问自己三个问题：
- 这个过程的目的是什么？（一句话说清楚）
- 做完后，我要产出什么？（列出清单）
- 这些成果怎么证明我干完了？（比如评审记录、测试报告）
这三个问题能帮你快速对齐过程目的与成果。
3.4 避坑指南：我曾经踩过的三个坑
讲到这里，我分享几个实战中容易犯的错误：
坑一：过程目的写得太虚
我曾经见过一个团队，把MAN.3项目管理的目的是“确保项目成功”。这等于没说。正确的写法应该是“确保项目在预算、进度、质量约束下交付”。越具体越好。
坑二：过程成果和实际工作脱节
有一次审核，我发现团队的过程成果里写了“需求被评审”，但实际他们只是邮件发了一下，根本没开会。这就是典型的“写一套，做一套”。我建议，过程成果必须对应到实际的工作产物，比如评审记录表、签字页。
坑三：混淆过程组之间的边界
比如SUP.1配置管理和MAN.3项目管理，很多人觉得差不多。其实区别很大：配置管理管的是“东西”（代码、文档），项目管理管的是“人、钱、时间”。千万别混在一起。
3.5 小结：PRM就是你的项目导航
好了，总结一下今天的内容：
- 过程类别与过程组：把过程分成三大类，每类下面再分组，方便管理。
- 生命周期过程：从需求到交付的完整链条，缺一不可。
- 过程目的与成果：每个过程都要有明确的目标和可验证的输出。
我个人觉得，PRM就像一张导航地图。你不需要背下所有过程编号，但你要知道：我现在在哪个阶段？下一步该去哪？做完这事要拿出什么？
下次咱们聊过程评估模型（PAM），看看怎么用这张地图来打分。到时候我会分享一个我当年被审核员问住的案例，保证让你印象深刻。
公众号:蓝海资料掘金营，微信deep3321