2. 过程参考模型(PRM):过程类别、过程组、过程ID、过程目的与成果

好,咱们进入第二章。上一章我们把ASPICE的"骨架"——过程参考模型(PRM)和过程评估模型(PAM)的关系理清了。这一章,咱们就专门啃PRM这块硬骨头。

说白了,PRM就是ASPICE定义的一套"标准动作库"。你想想看,如果每个公司都按自己的理解去开发软件,那评估就没法做了。所以ASPICE给你规定好了:你要做哪些事,每件事的目的是什么,做完之后要留下什么成果。这就是PRM的核心。

2.1 过程类别:三大板块

ASPICE把所有的过程分成了三大类。我习惯叫它们"三大板块":

过程类别 英文 缩写 核心作用
主要生命周期过程 Primary Life Cycle Processes PL 直接干活的过程,比如需求、设计、编码、测试
组织生命周期过程 Organizational Life Cycle Processes OL 管人和管流程的,比如培训、改进
支持生命周期过程 Supporting Life Cycle Processes SL 给主要过程"打辅助"的,比如配置管理、质量保证

嗯,这里要注意:主要生命周期过程是评估的重点。我做过十几个项目,90%的评估火力都集中在这块。组织过程和支持过程虽然也重要,但通常不会像主要过程那样被"深挖"。

2.2 过程组:把相近的事放一起

每个过程类别下面,又分了若干个过程组。这就像你把工具箱里的螺丝刀、扳手、钳子分别归类一样。

拿主要生命周期过程来说,它下面有这些组:

  • 系统工程过程组(SYS):管系统层面的需求、设计、集成、测试
  • 软件工程过程组(SWE):管软件层面的需求、设计、编码、测试
  • 采购过程组(ACQ):管供应商和外包
  • 供应过程组(SPL):管你作为供应商怎么交付

我个人习惯把SYS和SWE称为"核心双核"。因为大部分项目,评估师盯得最紧的就是这两个组。你想想看,系统需求没搞明白,软件设计能做好吗?

2.3 过程ID:每个过程的"身份证号"

每个过程都有一个唯一的ID。这个ID在评估报告、工具配置、团队沟通中都会用到。记住了,能省很多事。

过程ID 过程名称 所属过程组
SYS.1 需求挖掘 系统工程
SYS.2 系统需求分析 系统工程
SYS.3 系统架构设计 系统工程
SWE.1 软件需求分析 软件工程
SWE.2 软件架构设计 软件工程
SWE.3 软件详细设计与单元构建 软件工程
SWE.4 软件单元验证 软件工程
SWE.5 软件集成与集成测试 软件工程
SWE.6 软件合格性测试 软件工程
MAN.3 项目管理 管理
SUP.1 质量保证 支持
SUP.8 配置管理 支持

我曾经遇到一个团队,在评估前临时补文档,结果把SWE.1和SYS.2的内容搞混了。评估师一看ID不对,直接给了个"不符合"。你说冤不冤?所以,ID一定要记清楚,别搞混。

2.4 过程目的:为什么要做这件事

每个过程都有一个明确的目的。目的不是让你背的,而是让你理解"为什么要做这件事"。

举个例子,SWE.1(软件需求分析)的目的:

过程目的:将系统需求中分配给软件的部分,转化为一组软件需求。这些需求要足够详细,能支撑后续的架构设计、详细设计和测试。

说白了,就是"把系统要什么,翻译成软件要什么"。我见过很多团队,系统需求写了一大堆,但软件需求就几句话。这明显没理解过程目的——你连软件要做什么都没说清楚,后面怎么设计?怎么测试?

2.5 过程成果:做完事要留下什么

过程成果(Outcome)是PRM里最"实在"的部分。它告诉你:这件事做完了,你必须拿出什么证据来。

还是拿SWE.1举例,它的成果包括:

  1. 定义了软件需求及其优先级
  2. 软件需求与系统需求之间建立了双向追溯
  3. 软件需求得到了相关方的确认
  4. 软件需求的变更得到了管理

嗯,这里有个坑。很多团队只做了第1条,写了需求文档。但第2条(追溯)、第3条(确认)、第4条(变更管理)全忘了。评估师一看,成果不完整,扣分。

我的建议:每个过程开始前,先把它的成果列表打印出来贴在墙上。每完成一项,打个勾。这样评估时就不会漏了。

2.6 知识结构总览

下面这张图,把PRM的整个结构串起来了。你可以把它当作"地图"来用。

ASPICE 过程参考模型(PRM)结构 主要生命周期过程 (PL) 组织生命周期过程 (OL) 支持生命周期过程 (SL) 系统工程 (SYS) 软件工程 (SWE) 管理 (MAN) 改进 (PIM) 支持 (SUP) 重用 (REU) SYS.1 需求挖掘 SWE.1 需求分析 MAN.3 项目管理 SUP.1 质量保证 过程目的 "为什么做" 将系统需求转化为软件需求 过程成果 "留下什么证据" 需求文档、追溯矩阵、确认记录 核心逻辑:类别 → 组 → 过程 → 目的 → 成果 每个过程都有唯一的ID(如SWE.1),明确的目的,以及可验证的成果 评估时,评估师就是对照这些成果来打分的

2.7 避坑指南

我曾经辅导过一个团队,他们把所有过程的目的和成果都背得滚瓜烂熟。但评估时,评估师问了一个问题:"你们SWE.1的成果2(双向追溯)是怎么实现的?"团队答不上来。

记住:背出来没用,做出来才有用。PRM不是让你背的,是让你照着做的。

另外,我建议你准备一个过程成果检查表。每个过程开始前,把成果列出来;过程中,每完成一项就记录证据;过程结束时,检查是否全部完成。这样评估时,你拿出来的都是"实打实"的东西,而不是临时补的。