第2章：过程参考模型(PRM)：过程类别与过程组、生命周期过程、过程目的与过程成果
好，咱们今天聊聊ASPICE的核心骨架——过程参考模型，也就是PRM。
说实话，我刚开始接触ASPICE那会儿，看到那一堆过程名称和编号，头都大了。什么SYS.1、SWE.6、MAN.3……感觉像在背密码。后来做评估做多了才明白，这个模型其实特别有逻辑。你把它拆开看，就是三件事：谁在做什么、什么时候做、做到什么程度算好。
2.1 过程类别与过程组
ASPICE把所有的过程分成了三大类。我习惯叫它们「三大阵营」：
- 主要生命周期过程——直接跟产品开发相关的活儿
- 组织生命周期过程——公司层面怎么管这些活儿
- 支持生命周期过程——给所有过程提供「后勤保障」
每个大类下面又细分了过程组。举个例子，主要生命周期过程里，有系统相关的、软件相关的、还有硬件相关的。你想想看，一个车厂做ECU开发，系统工程师先定需求，软件工程师再写代码，硬件工程师画板子——这不就是按过程组分好了吗？
我个人习惯：做评估时，先看企业属于哪个过程组。如果是纯软件公司，那SYS组可能就弱一些；如果是Tier 1供应商，那ACQ（采购）组就得重点看。别一上来就全铺开，容易把自己累死。
2.2 生命周期过程
这里有个关键点——过程不是孤立的。它们像一条流水线，从概念到退役，贯穿产品的整个生命周期。
我记得有一次去一家做ADAS的公司做评估。他们的软件写得很漂亮，但系统需求文档写得一塌糊涂。为什么？因为他们的流程里，系统工程师和软件工程师是「各干各的」。系统组写完需求就扔给软件组，软件组看不懂也不问，自己猜着写。结果呢？集成测试时发现一堆问题，返工成本高得吓人。
这就是生命周期过程没打通。ASPICE强调的，就是这些过程要像齿轮一样咬合在一起：
- 需求分析阶段（SYS.1/SWE.1）
- 设计阶段（SYS.2/SWE.2）
- 实现阶段（SYS.3/SWE.3）
- 测试阶段（SYS.4/SYS.5/SWE.4/SWE.5/SWE.6）
说白了，就是「上一道工序的产出，必须是下一道工序能直接用的」。别搞什么「我写完了你自己理解去」这种事儿。
避坑指南：我曾经见过一个团队，他们的系统需求写了200页，但软件需求只有20页。为什么？因为系统需求里把软件该做的事也写进去了。结果软件工程师不知道该听谁的。记住：每个过程有自己的边界，别越界。
2.3 过程目的与过程成果
这是PRM里最容易被忽略，但我觉得最有价值的部分。
每个过程都有一个过程目的——一句话说清楚「为什么要做这件事」。比如SWE.1（软件需求分析）的目的：「建立并维护软件需求，确保其与系统需求一致」。你看，不是「写文档」，而是「建立并维护」。
然后，每个目的又拆成若干个过程成果——也就是「做到什么程度算达标」。比如SWE.1的成果包括：
- 软件需求被识别并定义
- 软件需求与系统需求的一致性被确认
- 软件需求的优先级被定义
- ……
我刚开始做评估师时，特别喜欢拿过程成果当checklist用。一条一条对，看企业做到了没有。后来发现，这其实是个误区。过程成果不是「考试大纲」，而是「导航地图」。它告诉你方向在哪，但怎么走，你自己决定。
注意：别把过程成果当成「必须输出的文档列表」。ASPICE从来没说过「你必须写一份软件需求规格书」。它只要求你「建立并维护软件需求」。你用Excel、用Jira、甚至用白板拍照都行——只要能证明你做到了。我见过最极端的案例，一个团队用便签纸贴了一面墙，照样过了评估。为什么？因为他们的过程成果都达成了。
2.4 我的实战建议
如果你正在搭建或改进过程体系，我建议你从PRM入手，但别照搬。怎么做？
- 先理解目的：每个过程为什么要存在？不做什么后果？
- 再对齐成果：你的团队目前能达成哪些成果？哪些还差得远？
- 最后设计活动：根据成果反推，你们需要做什么活动才能达成？
嗯，这里要注意：很多团队一上来就设计「活动」，比如「每周开一次需求评审会」。但如果你不知道这个会的目的是什么，那开了也是白开。我见过一个团队，每周开两次评审会，但需求文档还是一团糟。为什么？因为他们只开会，不解决问题。
所以，记住这个顺序：目的 → 成果 → 活动。别搞反了。
一句话总结：PRM不是让你背的，是让你用的。过程类别帮你分类，生命周期过程帮你串联，过程目的和成果帮你定义「好」的标准。下次再有人问你「ASPICE到底要我做啥」，你就告诉他：先搞清楚你在哪个过程组，再搞清楚你的过程目的是什么，最后看看成果达成了没有。
好了，这一章就到这儿。下一章咱们聊聊过程评估模型——也就是怎么判断你做得「好不好」。到时候我会分享一些评估时的「潜规则」，保证让你少走弯路。