3. 过程参考模型（PRM）：PRM的构成、过程类别、过程组、过程定义
好，咱们进入第三章。这一章要聊的是ASPICE的骨架——过程参考模型，也就是PRM。
说实话，我刚接触ASPICE那会儿，看到那一堆过程名字，头都大了。什么“系统需求分析”、“软件详细设计”、“单元验证”……感觉像是一锅大杂烩。后来我才明白，PRM其实是有套路的。它把整个开发活动拆成了几个大类，每个大类下面再分组，组里再细分具体的过程。
说白了，PRM就是一张地图。告诉你做嵌入式软件，到底要干哪些事，按什么顺序干。
3.1 PRM的构成：三个维度
PRM的构成，我习惯从三个维度去理解：
- 过程类别：最高层级的分类。比如“这是管理类的事”、“这是工程类的事”。
- 过程组：每个类别下面，再按功能或阶段分组。比如工程类里，有“系统开发组”、“软件开发组”。
- 过程定义：最底层，具体到每一个过程。比如“软件需求分析”就是一个具体的过程。
你想想看，这就像咱们的文件夹结构。类别是根目录，组是子文件夹，过程就是里面的文件。ASPICE一共定义了40多个过程，都装在这几个文件夹里。
核心要点：PRM不是凭空捏造的。它基于ISO 12207（国际软件生命周期标准）和ISO 15288（系统工程标准）。ASPICE只是把它们裁剪了一下，更适合汽车行业。
3.2 过程类别：三大支柱
PRM把过程分成了三大类别。我当年做项目时，经常跟同事开玩笑说，这三大类就是“管人的”、“干活的”、“搞支持的”。
| 过程类别 | 英文缩写 | 一句话解释 |
|---|---|---|
| 主要生命周期过程 | PRM-M | 直接跟产品开发相关的核心活动 |
| 组织生命周期过程 | PRM-O | 公司层面怎么管、怎么改进 |
| 支持生命周期过程 | PRM-S | 给核心活动提供“后勤保障” |
主要生命周期过程，这是咱们工程师最熟悉的。从客户需求开始，一路到系统设计、软件设计、编码、测试、集成、发布。说白了，就是产品从无到有的全过程。我在项目中遇到过最典型的坑，就是需求分析没做好，直接跳到编码。结果后面返工返到哭。嗯，这个类别里的过程，一个都不能省。
组织生命周期过程，这个类别离一线工程师稍微远一点。它关注的是公司怎么建立流程、怎么培训人、怎么持续改进。比如“过程改进过程”、“人力资源管理过程”。我个人的感觉是，很多公司这块做得比较虚，但ASPICE审核时，这块是必查的。审核员会问：“你们公司有没有流程改进的机制？”如果你说没有，那基本就凉了。
支持生命周期过程，这个类别很有意思。它不直接干活，但所有活都离不开它。比如“配置管理”、“质量保证”、“验证”、“确认”、“文档管理”。我曾经在一个项目里，因为配置管理没做好，导致版本混乱，测试组拿到的代码跟开发组的不一样。那叫一个惨。所以，支持过程虽然看起来“不直接创造价值”，但少了它，整个项目会崩。
3.3 过程组：把过程分门别类
每个类别下面，又细分了过程组。我列个表，你一看就明白了。
| 过程类别 | 过程组 | 包含的过程举例 |
|---|---|---|
| 主要生命周期过程 | 系统开发组 | 系统需求分析、系统架构设计、系统集成测试 |
| 软件开发组 | 软件需求分析、软件架构设计、软件详细设计、软件构建、软件集成测试 | |
| 采购/供应组 | 供应商管理、外包开发管理 | |
| 组织生命周期过程 | 管理组 | 项目管理、风险管理、质量保证 |
| 改进组 | 过程改进、过程评估 | |
| 支持生命周期过程 | 支持组 | 配置管理、文档管理、验证、确认 |
| 复用组 | 软件复用、资产库管理 |
这里要注意一点：过程组不是固定的。ASPICE 3.1版本和4.0版本，分组方式略有不同。但核心逻辑没变——就是把相关的过程放在一起，方便管理。
我的小技巧：做ASPICE合规时，不要死记硬背过程组。你只需要记住“工程类”、“管理类”、“支持类”这三个大方向。审核员问起来，你能说出每个过程属于哪个类别，基本就过关了。
3.4 过程定义：每个过程长什么样
每个过程，PRM都给出了明确的定义。我拿“软件需求分析”举个例子，你就知道过程定义长啥样了。
一个完整的过程定义，包含以下要素：
- 过程ID：比如 SWE.1（Software Requirements Analysis）
- 过程名称：软件需求分析
- 过程目的：一句话说明这个过程要达成什么目标。比如“建立并维护软件需求的基线”。
- 过程成果：完成这个过程后，应该产出什么。比如“软件需求规格说明书”、“需求追溯矩阵”。
- 基础实践：具体要做什么活动。比如“获取系统需求”、“定义软件需求”、“分析软件需求的一致性”。
我举个例子，你感受一下：
过程ID: SWE.1
过程名称: 软件需求分析
过程目的: 将系统需求转化为软件需求，并确保其完整性、一致性和可验证性。
过程成果:
- 定义了软件需求及其优先级
- 建立了软件需求与系统需求的追溯关系
- 评估了软件需求的技术可行性和风险
基础实践:
BP1: 获取并理解系统需求
BP2: 定义软件需求
BP3: 分析软件需求的质量
BP4: 建立需求追溯
BP5: 评审并批准软件需求你看，每个过程都定义得清清楚楚。你照着做就行。但我在实际项目中发现，很多团队只关注“基础实践”，忽略了“过程成果”。结果活干了，文档没留下。审核员来了一看，说：“你们做了吗？证据呢？”
避坑指南：我曾经在一个项目里，团队把软件需求分析做得很细，但没写需求规格说明书。审核员问：“你们的需求文档呢？”项目经理说：“都在工程师脑子里。”审核员当场就给了个不符合项。记住：过程成果是审核的硬证据。没有文档，等于没做。
3.5 过程定义的层级关系
PRM里的过程定义，不是孤立的。它们之间有明确的输入输出关系。比如：
- 系统需求分析（SYS.1）的输出，是软件需求分析（SWE.1）的输入。
- 软件需求分析（SWE.1）的输出，是软件架构设计（SWE.2）的输入。
- 以此类推，形成一个链条。
这个链条，就是V模型的核心。你想想看，如果上游的输出不完整，下游肯定做不好。我见过太多项目，系统需求写得模棱两可，软件工程师只能靠猜。猜出来的需求，能对吗？
所以，PRM的过程定义，本质上是在告诉你：每个环节该干什么，干完要留下什么，然后交给谁。 这就是流程的威力。
3.6 小结：PRM是地图，不是镣铐
最后说一句。PRM不是用来束缚你的。它是一张地图，告诉你从哪出发、经过哪些站、最终到哪。你可以根据自己的项目特点，裁剪过程。比如小项目，可以合并一些过程。但核心的输入输出关系，不能断。
我个人习惯，每次做新项目前，先把PRM的过程列表打印出来，贴在墙上。每完成一个过程，就打个勾。这样项目进度一目了然，审核时也心里有底。
好，这一章就到这。下一章咱们聊聊过程能力等级——也就是怎么评价你的过程做得好不好。