简介CMMI 3.0软件工程规范文档是一份面向软件过程改进人员、项目经理和质量管理人员的参考文件系统介绍CMMI模型的五个成熟度等级——初始级、已管理级、已定义级、定量管理级与优化级每个等级的关键目标和核心实践均有梳理。文档还提炼了通用目标GG和通用实践GP并对CMMI 2.0相对1.3的重大变化做了对比涵盖商业目标驱动、性能量化评估、高层参与、随机抽样检查等要点同时给出20个实践域PA的划分以及2.0与1.3的映射关系。资源为1个PDF文件压缩包大小约5.17MB已有1414人学习下载。读者通过这份文档可以快速理解CMMI新版本的评估思路、实践域构成和落地要求对企业开展过程改进、迎接V2.0评估或完善研发管理均有直接参考价值。1. CMMI 3.0 软件工程规范文档一份旧体系迁移到 v2.0 的操作型参考CMMI 3.0 软件工程规范文档拆之前我以为是一本需要从头啃的标准手册拆完才发现核心是一套从 CMMI-DEV v2.0 视角整理的过程改进操作包20 个实践域、1.3 到 2.0 的 PA 映射表、随机抽样评估规则以及 EST 估算和通用实践演化的详细说明。它解决的问题很具体旧体系的五级 PA 该怎么迁移到新结构、高层经理要在哪些环节真正露面、评估时项目怎么被抽到、估算和性能报告怎么做。适合过程改进工程师、质量管理人员、项目经理以及那些想从“有流程”升级到“流程能支撑业务目标”的团队直接拿去当参考模板。2. 从 1.3 到 2.0 的 PA 迁移20 个实践域是怎么拆出来的版本升级最坑的地方是拿着 1.3 的旧地图找 v2.0 的新位置。新版并没有简单地把旧 PA 改名而是把部分实践域拆开、合并、剥离甚至取消后重排。如果按旧版目录去写新体系文件大概率会漏掉 EST、PR、GOV、II 这几个新增或独立出来的实践域。2.1 五级模型与旧 PAv1.3 的等级划分仍是理解 2.0 的底层框架1.3 的等级体系是后面所有映射讨论的地基。它把过程域按成熟度等级摆放等级越高代表组织过程能力越稳定、越可预测。等级名称1.3 过程域PA1初始级无强制 PA凭个人能力2已管理级需求管理、项目策划、项目监控和控制、配置管理、过程和产品质量保证、供应商协议管理、度量和分析3已定义级需求开发、技术解决方案、产品集成、验证、确认、集成项目管理、风险管理、组织级过程焦点、组织级过程定义、组织级培训、决策分析与决定4定量管理级定量项目管理、组织级过程性能5优化级组织级性能管理、因果分析和决定2.0 不再沿用“每个 PA 属于某个等级”的排布方式而是改成“实践分级别”的写法。每个实践域里可以有不同级别的实践例如 Practice 3.2 表示 Level 3 里的第 2 条实践。这个编号规则在评估访谈里经常出现访谈对象要能说清楚自己的文档对应哪一级实践否则容易被判定为“实践未落地”。2.2 通用实践去哪了GG/GP 在 2.0 里的归并逻辑1.3 里有通用目标GG和通用实践GP用来保证过程被制度化。GG1 是达到特定目标GG2 是把过程管理起来GG3 是把过程定义清楚并沉淀经验。对应的 GP 编号和内容如下。编号内容GP 1.1执行特定实践GP 2.1确立组织政策GP 2.2计划过程GP 2.3提供资源GP 2.4分配责任GP 2.5培训人员GP 2.6控制工作产品GP 2.7识别和涉及相关干系人GP 2.8监控和控制过程GP 2.9客观地评价遵守性GP 2.10审查状态与高层管理GP 3.1建立已定义的过程GP 3.2收集过程相关经验2.0 里单独看文档已经找不到这一整章“通用实践”。原因是发布方把高层参与的职责提炼成了 GOV治理实践域把资源、培训、过程资产、基础设施等内容归入了 II实施基础设施实践域。也就是说原来一套通用实践管所有过程域的做法被拆成了组织级实践域力度更重要求更具体。2.3 20 个实践域清单哪些 PA 含 4 级或 5 级实践CMMI v2.0 面向开发一共 20 个实践域每个实践域中的实践按级别分组。这里最容易混淆的是不是所有 PA 都要求做到 2 级以上也不是所有 PA 都有高级实践。缩写实践域说明EST估算从 PP 剥离出来的新增 PAPLAN策划包含估算剥离后的策划活动MC监控项目跟踪、关键依赖与里程碑评审CAR因果分析与决定含 4 级和 5 级实践DAR决策分析与决定对决策事项分级分类CM配置管理最少到 2 级的 PA所有项目都要有PQA过程质量保证客观评价过程遵循性MPM管理性能与度量合并了定量项目管理与组织级性能管理PCM过程管理偏向组织级过程改进PAD过程资产开发对应 1.3 的组织级过程定义RDM需求开发与管理合并了需求管理和需求开发VV验证与确认合并了验证、确认PR同行评审从验证中独立出来的新 PARSK风险和机会管理增加了机会管理OT组织级培训与 1.3 基本一致GOV治理来自 1.3 的共性实践II实施基础设施来自 1.3 的共性实践TS技术解决方案与 1.3 的技术解决方案对应PI产品集成与 1.3 的产品集成对应SAM供应商协议管理与 1.3 的供应商协议管理对应从这份清单能读出两件事第一含 4 级实践的 PA 有 6 个PLAN、CAR、MPM、PCM、GOV、SAM含 5 级实践的只有 2 个CAR 和 MPM。第二配置管理是最低要求级别的 PA说明配置管理是底线几乎不会因为项目小而被裁剪。2.4 PA 映射新增、拆出、合并、改名做差距分析时最实用的材料是 2.0 与 1.3 的 PA 映射。下面是整理后的对应关系。2.0 实践域1.3 过程域变化类型CARCAR基本不变DARDAR基本不变EST从 PP 中剥离新增GOV来自 1.3 的共性实践新增II来自 1.3 的共性实践新增MPMMA、QPM合并MCPMC、IPM 中的跟踪实践合并扩充OTOT基本不变PR从 VER 中剥离新增PLANPP部分来自 IPM改名、重组PADOPD改名PCMOPF、部分 OPM改名、重组PQAPPQA改名PIPI基本不变RDMRD、REQM合并RSKRSKM改名增加机会管理SAMSAM基本不变TSTS基本不变VVVER、VAL合并特别要注意 IPM 在 2.0 里被取消了拆分到 PLAN 和 MC 中。如果旧体系里还有“集成项目管理”这份制度不能直接删掉而是要先把其中跟策划有关的内容并进 PLAN把跟踪、关键依赖、里程碑评审的内容并进 MC。3. 商业目标驱动评估性能报告、随机抽样与高层治理的三个变化版本结构看完接下来要理解 2.0 对“改进逻辑”的调整。2.0 不再满足于“你按过程做了”而是追问“过程改进给业务带来了什么”。这个思路渗透在“实践的价值”、性能报告、随机抽样和高层治理机制里。3.1 所有等级都围绕商业目标从 5 级专属变为默认设定1.3 只在 5 级强调围绕商业目标做改进2.0 则是无论哪个等级都要求过程改进能回应商业目标。这是一条基本思想也是评估时会被反复追问的点。每条实践描述里都增加了“实践的价值”这实际上就是在告诉执行者这条实践为什么值得做它服务于什么业务结果。我一般建议团队在写制度文件时把“实践价值”单独放一段不要只抄实践描述。比如 EST2.3 写“基于规模估算制定并记录解决方案的工作量、工期和成本估算及估算理由”价值是“为承诺和策划提供依据减少不确定性”。如果制度里只写了做法没有写价值执行的人就很难理解为什么要估算两次、为什么估算要有理由。3.2 Performance Report评估必交的性能报告该怎么组织2.0 评估方法要求每次评估都提交 Performance Report用定量数据说明组织能力的变化而不是主观判断。这就意味着文档里不能只写“我们做了过程改进”而要写清楚哪些指标变了基线是多少目标值是多少变化趋势是什么。业务目标过程指标当前基线目标值数据来源分析结论缩短交付周期需求到上线平均周期45 天30 天项目管理系统近 4 个季度持续下降降低缺陷逃逸生产缺陷密度0.8 个/功能点0.5 个/功能点缺陷管理库第 3 季度后明显改善提高进度可控性进度偏差绝对值12%8%项目周报需继续加强估算准确性指标不要贪多选三到五个与业务目标强相关的就够。常见做法是每季度由质量或过程改进角色从项目管理系统、缺陷库、工时系统拉数据汇总成一份趋势分析。评审组看的是“组织能力有没有变化”不是看报告写了多少字。3.3 GOV 与 II高层经理参与从“软约束”变成独立实践域GOV 的意图是指导高级管理层履行过程活动的发起和治理职责价值是降低实施成本、提高目标实现可能性并确保过程能支撑业务成功。II 的意图是确保对组织重要的过程能坚持并形成习惯价值是维持有效实现目标的能力。这两个实践域从 1.3 的共性实践里提升出来说明高层参与不再是一件“最好做”的事而是一项明确的评估内容。我给某公司搭这套体系时把 GOV 落地成三样东西季度高层过程评审会、资源和预算承诺表、障碍升级通道。把 II 落地成过程资产库、模板和工具清单、培训计划。制度写得很顺利但访谈时若拿不出高层最近一次参与过程决策的会议纪要和资源承诺记录一样会被判“实践未执行”。3.4 随机抽样规则参评项目不是自己选的2.0 抽样方式变化很大。1.3 是由主任评估师与评估出资人协商确定参评项目2.0 是被评估组织上报所有可能的参评项目由评估系统自动随机抽取评哪些实践域、抽到哪个项目都不由组织自己控制。组织项目总数每个 PA 至少覆盖项目数110 个1 个1140 个2 个超过 40 个3 个这意味着过去“集中资源把两个样板项目做漂亮”的做法彻底失效。唯一的出路是让所有项目按同一套裁剪指南执行至少保证每个项目都覆盖相应 PA 的最低级别实践。抽样访谈里一个人通常会被多个 PA 问到例如项目经理聊 EST、PLAN、MC需求人员、测试人员和 QA 会聊 PQA、RDM、PR、VV。所以不能把责任全压在质量部每个角色都要对自己参与过的实践有真实理解。4. 搭一套可操作的 2.0 过程体系从 EST 估算到 PR 同行评审的闭环实践域拆完了但真正做体系落地时不建议按 20 个 PA 分别建制度。那样会得到一堆彼此孤立的文件项目团队根本不知道从哪里入手。更实际的做法是按项目生命周期串起来在每个阶段挂上对应的 PA。4.1 项目生命周期与 PA 的对应关系阶段关键活动关联 PA立项可行性分析、立项评审、初步估算GOV、II、SAM、EST策划范围定义、计划评审、风险识别、二次估算PLAN、EST、RSK监控进度跟踪、成本跟踪、变更控制MC、MPM、CM需求需求调研、需求分析、需求评审、跟踪RDM、PR设计架构设计、概要设计、详细设计TS、PR、DAR编码实现、单元测试、代码走查TS、CM、PR测试集成测试、系统测试、验收测试VV、PR、PQA上线与结项试运行、项目总结、数据入库PI、PQA、CAR、MPM、PAD这套对应关系做出来后团队能直观看到自己在哪个阶段要做哪些过程活动。裁剪的规则也以阶段为单位小型项目可以简化的主要是 DAR不一定每次决策都开正式会议但配置管理不能砍因为 CM 是 2.0 里实践等级最低到 2 级的 PA所有项目都要有基线。4.2 EST 估算从规模到工作量、工期、成本的六条实践EST 是 2.0 里从原项目策划拆出来的独立实践域包含六条实践EST1.1制定初步的估算以执行工作EST2.1制定并保持更新要估算对象的范围EST2.2制定并保持更新解决方案的规模估算EST2.3基于规模估算制定并记录解决方案的工作量、工期和成本估算及估算理由EST3.1制定并保持更新文档化的估算方法EST3.2使用组织级的度量库和过程资产来进行估算估算对象常用单位典型方法规模功能点、故事点、代码行功能点分析、用户故事估算工作量人时、人日类比估算、三点估算工期日历天参考历史项目周期成本人天单价 × 人天数 直接成本参数模型三点估算在项目早期最实用。拿某个模块举例最乐观 2 人日最可能 5 人日最悲观 12 人日。用三角分布而不是 PERT 的情况也很常见因为软件任务往往不是对称分布。# 三点估算示例根据历史数据估算工作量范围 # 输入参数最乐观(o)、最可能(m)、最悲观(p)单位人日 def three_point_estimate(o, m, p): # 三角分布期望值更适合偏态分布的软件任务 expected (o m p) / 3 # 标准差用于估算上下限数值越大代表不确定性越高 std_dev (p - o) / 6 return expected, std_dev if __name__ __main__: # 某个模块最乐观2人日最可能5人日最悲观12人日 e, sd three_point_estimate(2, 5, 12) print(f期望工作量{e:.1f} 人日标准差{sd:.1f} 人日) print(f大致范围{e - sd:.1f} ~ {e sd:.1f} 人日)这段代码的核心是把不确定度显式表达出来。期望工作量约 6.3 人日范围大约在 4.7 到 7.8 人日。到了项目计划评审时不要拿期望值直接承诺工期而要带着区间去和业务方谈如果必须在某个日期交付可以用来倒推需要投入的资源或需要削减的范围。见过不少团队在估算上栽跟头根源就是只给一个点估计不给偏差范围。4.3 RDM、VV、PR需求、验证确认与评审怎么衔接RDM 把 1.3 的需求管理和需求开发合并到一起VV 把验证和确认合并PR 独立成域。这意味着需求端和测试端要形成一条完整链条中间靠需求跟踪矩阵衔接。矩阵里至少要包含需求编号、需求描述、来源、优先级、对应设计、对应测试用例、当前状态。这条矩阵不是给评估组看的是给开发、测试、验收三方共同使用的。PR 独立以后评审不能再是“开个会然后补记录”。建议至少定义四类评审场景需求评审、设计评审、代码走查、测试计划评审。每份评审记录里要有评审对象、评审人角色、问题清单、严重级别、处理人、关闭状态。同行评审强调“同行”QA 可以参与但不是主角真正把关的是同级别的开发、测试和需求人员。4.4 CM 与 PQA支撑类 PA 的检查点设置配置管理在 2.0 里的地位很特殊它是唯一一个实践等级最低到 2 级的 PA所有项目都绕不开。日常检查点设置可以按五个动作铺开配置项识别、基线建立、变更控制、配置状态报告、配置审计。哪怕是小项目至少也要把代码、需求文档、设计文档、测试用例和上线方案纳入基线管理。PQA 强调客观评价遵循性。实际操作里QA 不能只查文档填写完整度还要抽查工作产品本身比如拿需求跟踪矩阵抽查测试用例是否有对应覆盖项。发现问题后开不符合项不一定要写成正式报告但要有跟踪闭环。高层评审时PQA 应该拿出的是不符合项分布、整改率这类客观数据而不是“本周检查文档三份均合格”这种流水账。5. 避坑清单CMMI v2.0 评估准备最常见的五个翻车点下面这几条来自实际做体系升级和配合评估准备时的血泪经验每条按现象、原因、解决来讲。5.1 还在按 1.3 的 PA 名称找新版过程域EST 和 PR 直接漏掉现象团队做差距分析时列出的缺失项里没有 EST也没有 PR因为旧体系文件里本来就没有这两个名字。原因习惯了用 1.3 的 PA 清单理解新版本以为 2.0 只是换了个封面。解决用 2.4 节的 PA 映射表逐个核对。重点检查原来 PP 里的估算活动是否被拆到了 EST原来 VER 里的评审活动是否已经被剥离到 PR。如果旧文档里只有“项目策划书”而没有独立的估算记录就要补。5.2 只对“参评”项目强化过程随机抽样把计划全打乱现象评估时被抽到一个没重点准备的边缘项目访谈时拿不出完整的评审记录和变更记录。原因还是按 1.3 的思路押注样板项目忽略了 2.0 由评估系统自动随机抽样的规则。解决让所有项目走统一的裁剪指南核心实践全部落地。立项、周报、评审、测试、变更这些记录越是普通的项目越要保留完整。5.3 Performance Report 写成过程流水账现象报告满篇写“这个季度开了 12 次评审会、发布了 8 份文档”评审组看了不知道过程能力到底改善了没有。原因把性能报告当成了工作汇报没有建立“业务目标到过程指标”的映射。解决按 3.2 节的结构写。先写业务目标再写对应指标给出当前基线、目标值和趋势分析。提交前做一次自检报告里有没有至少一组“当前值对比目标值”的数字。5.4 GOV 和 II 只在制度里出现高层访谈时无话可说现象高层受访时被问到“最近一次参与过程决策是什么时候”回答模糊拿不出具体动作。原因制度文件里写了治理和基础设施但实际操作没有落到例会、资源和记录上。解决把治理动作固定成季度会议议题包括过程性能评审、资源承诺、障碍升级。会议纪要、预算审批记录、人员调配记录都要归档。实施基础设施则绑定过程资产库的更新记录和培训计划执行情况。5.5 把实践直接当流程执行忽略裁剪现象SOP 写了两百多页每个项目都要求执行全部实践评审时反而因为“形式完整、实操失真”被质疑。原因把“模型说明做什么”理解成了“模型规定谁怎么做”没有做裁剪设计。解决把制度拆成两层组织标准过程和项目裁剪指南。裁剪表里记录每类项目去掉了哪些实践、为什么去掉、用什么方式替代。裁剪本身也是实践不在评估时临时“补裁剪记录”。6. 快速差距分析技巧用 20 个 PA 关键字扫描旧体系文档找漏项接手一份旧体系文件时先别急着读内容我习惯先扫一遍文档目录看 20 个 PA 关键字到底命中多少个。文件名命中的不一定是有效覆盖但文件名都不命中的大概率是缺的。下面这段 Python 脚本可以做初筛。import os PAS [EST, PLAN, MC, CAR, DAR, CM, PQA, MPM, PCM, PAD, RDM, VV, PR, RSK, OT, GOV, II, TS, PI, SAM] def scan_dir(sop_dir): missing [] for pa in PAS: hit False for root, _, files in os.walk(sop_dir): # 文件名统一转大写再比对避免大小写漏检 if any(pa.upper() in f.upper() for f in files): hit True break if not hit: missing.append(pa) return missing if __name__ __main__: # 改成你的 SOP 文档目录 missing scan_dir(./sop) print(未命中的PA, , .join(missing) if missing else 全部命中仍需人工核对)这段脚本的逻辑很简单遍历指定目录下的所有文件依次检查 20 个 PA 缩写是否出现在文件名里最后输出没有命中的实践域。要注意两点第一文件名命中不代表内容有效比如旧的“项目策划书”里可能根本没有估算记录第二如果旧文档文件名用了“PMS-01”这类编号缩写匹配会漏检所以建议在正式建档时按新 PA 命名规范重命名或者在文档头部标注所属实践域。拿到扫描结果后把命中的 PA 分成三档“已覆盖”“需改造”“缺失”。已覆盖的直接沿用需改造的对照映射表调整范围缺失的进入补写计划。从那以后我每次接手过程改进相关的工作都会先跑一遍这个脚本把结果落到差距清单里再动手省掉很多不必要的扯皮。希望帮到你。本文还有配套的精品资源点击获取