过程参考模型（PRM）：过程类别与过程组、生命周期过程、结构、能力等级概述

好，咱们今天聊聊过程参考模型，也就是PRM。说实话，很多刚接触ASPICE的朋友，一上来就被这些术语搞晕了。什么过程类别、过程组、生命周期过程……我当年刚入行时也懵过。但别急，这东西说白了就是一张地图，告诉你软件开发过程中有哪些事要做，做到什么程度算好。

过程参考模型的结构

先看整体结构。PRM把软件开发活动分成了三个大的类别，每个类别下面又有若干过程组。我个人习惯把这三类想象成三个部门：

• 主要生命周期过程——直接干活儿的部门
• 组织生命周期过程——定规矩、管资源的部门
• 支持生命周期过程——提供工具和保障的部门

你想想看，一个项目要跑起来，这三个缺一不可。我在项目中遇到过不少团队，只盯着主要过程，觉得支持过程是浪费时间。结果呢？配置管理一团糟，问题跟踪全靠口头沟通，最后出了事谁也说不清楚。

过程类别与过程组

咱们一个一个来看。

主要生命周期过程

这是最核心的部分，直接跟产品开发相关。包括：

• 获取过程组——你要买什么、从谁那买
• 供应过程组——你要卖什么、怎么交付
• 系统工程过程组——需求分析、系统设计、集成测试这些硬功夫
• 软件工程过程组——软件需求、软件设计、编码、单元测试等

嗯，这里要注意：很多公司把系统工程和软件工程混在一起做，觉得反正都是写代码。我曾经见过一个项目，系统需求没理清楚就直接开干软件，结果迭代了五轮才发现架构方向就错了。所以，这两个过程组虽然紧密相关，但职责一定要分清楚。

支持生命周期过程

这些过程不直接产出代码，但没有它们，代码质量很难保证。包括：

• 质量保证过程——不是测试，而是看流程有没有走对
• 验证过程——是不是做对了产品
• 确认过程——是不是做了对的产品
• 评审过程——同行检查、技术评审
• 审计过程——合规性检查
• 配置管理过程——版本控制、基线管理
• 问题解决管理过程——缺陷跟踪、问题闭环

组织生命周期过程

这些是公司层面的事，单个项目往往管不了。包括：

• 管理过程组——项目管理、风险管理
• 改进过程组——过程评估、过程改进
• 资源与基础设施过程组——人员培训、工具链建设
• 重用过程组——资产复用、平台化策略

说白了，组织过程决定了你能走多远。我见过一些公司，项目做得好好的，但公司层面没有复用机制，每个项目都从零开始搭架构。这就是组织过程没做好。

生命周期过程详解

ASPICE里定义的生命周期过程，其实跟ISO 12207一脉相承。它把软件开发分成了几个阶段：

阶段	典型过程	关键输出
需求分析	系统需求分析、软件需求分析	需求规格、需求追溯矩阵
设计	系统架构设计、软件架构设计、详细设计	架构文档、设计模型
实现	软件实现、单元测试	代码、单元测试报告
集成与测试	软件集成测试、系统集成测试	集成测试报告、问题记录
验收	系统确认、验收测试	验收报告、交付物

为什么要有这么清晰的阶段划分？我举个例子。有一次我评审一个项目，他们直接把需求文档和设计文档写在一起，说这样省事。结果需求变更时，根本分不清哪些是需求、哪些是设计决策。最后不得不花两周时间重新梳理。所以，每个阶段的过程一定要独立，输出物要明确。

过程能力等级概述

这部分是ASPICE的精髓。过程能力等级不是看你的产品好不好，而是看你的过程稳不稳。一共6个等级：

• 等级0：不完整——过程没执行，或者执行了但没证据
• 等级1：已执行——过程被执行了，基本目标达成
• 等级2：已管理——过程有计划、有监控、有资源保障
• 等级3：已建立——过程有标准流程，并且被制度化
• 等级4：可预测——过程有量化指标，能预测趋势
• 等级5：持续优化——过程能自我改进，持续提升

我个人的建议是：别一上来就追求高等级。先把等级1和等级2的基础打牢。比如，需求管理过程，你先做到每个需求都有唯一标识、有状态跟踪、有变更记录，这就是等级2的水平了。等这些成了习惯，再考虑量化指标和持续优化。

小结

好了，咱们总结一下。过程参考模型就是一张完整的开发地图：

• 三大过程类别告诉你谁该干什么
• 生命周期过程告诉你什么时候干什么
• 能力等级告诉你干到什么程度算好

下次咱们聊具体的过程评估方法，到时候我会拿一个真实项目的评估案例来讲。嗯，今天就到这儿，有什么问题咱们评论区见。