CMMI 3.0规范文档编写指南：四层结构、裁剪逻辑与追溯校验-开发者社区

简介：CMMI 3.0 软件工程规范文档面向软件研发管理者、过程改进（EPG）成员及质量与项目管理从业者，用于系统理解能力成熟度模型集成框架，解决组织在过程定义、量化管理与持续优化中缺乏统一参照的问题。资源包共1个文件，为PDF格式，大小约5.17MB，内容围绕CMMI-DEV的等级划分、通用目标与实践展开，并梳理了从v1.3到v2.0的版本演化脉络。文档详细讲解初始级至优化级五个成熟度等级的目标与实践要点，涵盖需求管理、项目策划与监控、配置管理、过程质量保证、因果分析与决策等实践域，同时给出GG与GP的对应关系及2.0与1.3的PA映射说明。读者可借此掌握过程域之间的对应逻辑、评估抽样规则以及商业目标驱动改进、性能数据衡量效果等核心理念，适合作为体系落地、内审准备与评估备考的参考材料。目前已有1411人学习下载。

1. 从“文档补丁”到“过程基线”：CMMI 3.0 规范文档到底在解决什么

很多团队第一次接触 CMMI 3.0，第一反应是“又要补一堆文档”。这个反应本身就说明问题：如果规范文档只是评审前突击补齐的模板，那它和真正的过程改进没有关系。CMMI 3.0 把已定义的过程作为核心特征，意思是组织级要有一套标准过程，项目在此基础上做裁剪，而不是每个项目各写各的。规范文档就是这套标准过程的载体，它要回答的是“这件事我们组织标准怎么做、项目可以怎么改、改完怎么留痕”。

它适合三类人：正在准备 CMMI 3 级评估的 EPG（工程过程组）成员、需要把研发流程落成可执行文件的研发管理者、以及被要求写“软件工程规范文档”但不知道从哪下手的工程师。标题里的“软件工程规范文档”不是一份文档，而是一组有层次的文件：方针、过程、规程、模板、检查单。搞清这个层次，后面的编写和落地才不会变成堆字数。

2. CMMI 3.0 规范文档的四层结构与裁剪逻辑

2.1 为什么不能只写一份“大而全”的规范

常见做法是写一份几百页的《软件工程规范》，结果没人看，项目该怎么做还怎么做。CMMI 3.0 的已定义过程要求组织标准过程（OSP）可裁剪、可度量、可改进。一份大文件无法裁剪，也无法对应到具体实践域。正确的结构是分层的，每层解决不同问题。

层级	文件类型	回答的问题	典型责任人
L1	方针	组织为什么要求这么做	高层管理者
L2	过程	这类活动分几个阶段、谁负责	EPG
L3	规程	每一步具体怎么操作	过程所有者
L4	模板/检查单	产出物长什么样、怎么查	项目组

这个表不是让你照抄，而是说明：评审时看的是层次是否完整、上下是否一致。方针里承诺的资源，过程里要有对应活动；过程里要求的活动，规程里要有操作步骤；规程里要求的产出，模板里要有字段。

2.2 用裁剪表把组织标准过程映射到项目

裁剪不是删文档，而是根据项目特征选择过程元素。我一般会建一张裁剪表，把项目类型、规模、生命周期模型作为输入，输出需要执行的过程和需要产出的工作产品。

# 裁剪表片段：cmmi3_tailoring.yaml project_profile: type: "enhancement" # 项目类型：new / enhancement / maintenance size: "small" # 规模：small / medium / large lifecycle: "iterative" # 生命周期：waterfall / iterative / agile tailoring_rules: - when: "type == 'maintenance'" drop: - "需求开发-原型评审" keep: - "配置管理-变更控制" - "验证-回归测试" - when: "size == 'small'" merge: - "项目计划与项目监控合并为一份周报" - when: "lifecycle == 'agile'" replace: - "阶段评审 -> 迭代评审"

逻辑说明：这份 YAML 不是给工具读的，是给 EPG 和项目经理对齐用的。project_profile描述项目特征，tailoring_rules是组织级允许的裁剪规则。每条规则必须写清“什么条件下、动哪个过程元素、怎么动”。参数说明：drop表示不执行但要在裁剪记录里说明理由，merge表示合并产出物，replace表示用等效活动替代。裁剪结果要经过过程所有者批准，不能项目组自己说了算。

2.3 规范文档的编号与追溯设计

CMMI 3.0 强调双向追溯。规范文档如果每一条都是孤立段落，追溯就无从谈起。常见做法是给每个过程元素一个唯一 ID，格式建议为过程域缩写-类型-序号，例如REQ-PROC-001表示需求开发过程的第一条。模板字段里要留“上游依据”和“下游产出”，这样评审时能顺着 ID 查。

注意：编号一旦发布就不要改，修订用版本号区分。很多团队在评审前改编号，导致追溯矩阵全部失效。

3. 用模板和检查单把规范文档写成可执行文件

3.1 需求规格说明书的字段设计

软件工程规范文档里最容易被写废的就是需求模板。常见问题是字段太多、填的人不知道写什么。CMMI 3.0 要求需求可追溯、可验证，所以模板字段要围绕这两点设计。

## 需求条目：REQ-FUNC-012 - 需求描述：用户可以通过邮箱重置密码 - 来源：客户访谈记录 INT-2024-003 - 优先级：高 - 验收标准：输入已注册邮箱后 60 秒内收到重置链接，链接 30 分钟内有效 - 上游依据：BR-002 账户安全策略 - 下游产出：TC-FUNC-012、DES-AUTH-004 - 变更历史：2024-05-10 初稿；2024-05-12 增加有效期约束

逻辑说明：每条需求独立成块，字段固定。验收标准是测试用例的直接输入，上游依据和下游产出构成追溯链。参数说明：优先级用高/中/低三档，不要用数字，避免争议；变更历史记录日期和变更点，不写人名，人名在配置管理工具里查。

3.2 代码评审检查单的落地写法

规范文档如果只写“要进行代码评审”，等于没写。检查单要具体到能勾选。下面是一份针对 Python 项目的评审检查单片段，其他语言可替换规则。

# 代码评审检查单生成脚本：gen_checklist.py CHECKLIST = { "命名与风格": [ "变量名是否使用 snake_case", "常量是否全大写", "函数名是否以动词开头", ], "异常处理": [ "是否捕获具体异常而非裸 except", "异常信息是否包含上下文", "资源是否用 with 管理", ], "测试": [ "新增函数是否有对应单元测试", "边界条件是否覆盖", "测试是否独立可重复", ], } def render(checklist): for section, items in checklist.items(): print(f"### {section}") for item in items: print(f"- [ ] {item}") if __name__ == "__main__": render(CHECKLIST)

逻辑说明：这个脚本把检查单从文档变成可打印的评审清单。CHECKLIST字典的键是检查维度，值是具体检查项。参数说明：评审时每条要么勾选，要么在评审记录里写不适用理由。render函数输出 Markdown 格式，可以直接贴到评审 issue 里。实际使用时，检查单要随项目类型裁剪，比如维护项目可以去掉“新增函数测试”这一条。

3.3 配置管理规范中的变更控制流程

CMMI 3.0 的配置管理要求变更可控制、可审计。规范文档里要写清变更申请、影响分析、审批、实施、验证五个步骤，并给出状态流转。

-- 变更请求表结构：change_request.sql CREATE TABLE change_request ( cr_id VARCHAR(20) PRIMARY KEY, -- 变更请求编号 title VARCHAR(200) NOT NULL, submitter VARCHAR(50) NOT NULL, submit_date DATE NOT NULL, impact_analysis TEXT, -- 影响分析结论 status VARCHAR(20) DEFAULT 'submitted', -- 状态：submitted / analyzing / approved / rejected / implemented / verified approver VARCHAR(50), approve_date DATE, verify_date DATE );

逻辑说明：这张表是配置管理规范落地的核心。status字段约束了变更不能跳步，impact_analysis必须填写才能进入审批。参数说明：cr_id建议用CR-年份-序号，便于检索；approver只在状态为 approved 及之后才有值。规范文档里要写明每个状态的责任人和最长停留时间，比如 analyzing 不超过 3 个工作日。

4. 规范文档的评审、度量与持续改进

4.1 用评审检查单验证文档一致性

文档写完不等于能用。EPG 内部要先做一致性评审，检查方针、过程、规程、模板之间是否对齐。我一般用一张交叉检查表，逐条核对。

检查项	检查方法	不通过示例
方针承诺的资源在过程中有活动	搜关键词	方针说“提供培训”，过程里没有培训活动
过程要求的产出在模板中有字段	字段映射	过程要求“风险等级”，模板没有该字段
规程步骤可操作	让新人试做	步骤写“进行充分测试”，没有具体方法
裁剪规则不冲突	规则两两比对	两条规则对同一项目给出矛盾裁剪

这张表的使用方式是：每条检查项抽 3 到 5 个样本，记录不通过项，退回修改。评审记录本身也要存档，作为 CMMI 3.0 评估时的客观证据。

4.2 过程度量的最小指标集

CMMI 3.0 不要求度量一切，但要求度量支持过程改进。规范文档里要定义指标、采集频率、责任人、用途。常见的最小指标集包括：需求变更率、评审缺陷密度、测试逃逸率、进度偏差。下面是一个采集脚本示例。

#!/bin/bash # 采集需求变更率：change_rate.sh # 用法：./change_rate.sh <项目ID> <起始日期> <结束日期> PROJECT=$1 START=$2 END=$3 # 从变更请求表统计已批准的变更数 CHANGES=$(sqlite3 cmmi.db "SELECT COUNT(*) FROM change_request \ WHERE status='approved' AND submit_date BETWEEN '$START' AND '$END';") # 从需求表统计基线需求数 BASELINE=$(sqlite3 cmmi.db "SELECT COUNT(*) FROM requirement \ WHERE project_id='$PROJECT' AND baseline_date <= '$END';") if [ "$BASELINE" -eq 0 ]; then echo "基线需求数为 0，无法计算" exit 1 fi RATE=$(echo "scale=4; $CHANGES / $BASELINE" | bc) echo "需求变更率：$RATE"

逻辑说明：脚本从变更请求表和需求表分别取数，计算变更率。参数说明：PROJECT是项目 ID，START和END是统计区间。BASELINE为 0 时直接退出，避免除零。这个指标建议每月采集一次，超过阈值时在过程改进会上分析原因。规范文档里要写明阈值，比如变更率超过 0.3 触发根因分析。

4.3 把评估发现回写到规范文档

CMMI 3.0 评估或内部审计发现的问题，不能只改项目，要回写到组织标准过程。常见做法是建一张改进跟踪表，记录问题、根因、修改的文档 ID、修改版本、生效日期。

## 改进项：IMP-2024-007 - 问题：多个项目反馈需求评审检查单缺少“非功能需求”检查项 - 根因：模板设计时只考虑功能需求 - 修改文档：REQ-CHK-001 需求评审检查单 - 修改版本：v1.2 - 生效日期：2024-06-01 - 验证方式：抽查 3 个项目评审记录，确认非功能需求已检查

逻辑说明：每条改进项必须关联到具体文档 ID 和版本，否则改了什么说不清。参数说明：验证方式要可执行，不能写“持续观察”。生效日期之后启动的项目必须使用新版本，之前项目可沿用旧版本但要在裁剪记录里说明。

5. 用脚本自动校验规范文档的追溯完整性

规范文档写到一定规模后，人工检查追溯链不现实。我一般会写一个轻量校验脚本，把文档里的 ID 抽出来，检查上游依据和下游产出是否成对出现。下面是一个 Python 示例，假设文档是 Markdown，ID 格式为XXX-XXX-数字。

# 追溯校验脚本：trace_check.py import re from pathlib import Path ID_PATTERN = re.compile(r'\b[A-Z]{2,4}-[A-Z]{2,4}-\d{3}\b') def extract_ids(text): return set(ID_PATTERN.findall(text)) def check_trace(doc_dir): upstream = {} # 下游 ID -> 上游 ID 集合 downstream = {} # 上游 ID -> 下游 ID 集合 for md in Path(doc_dir).rglob("*.md"): text = md.read_text(encoding="utf-8") for block in text.split("\n\n"): ids = extract_ids(block) if "上游依据" in block: for i in ids: upstream.setdefault(i, set()).update(ids - {i}) if "下游产出" in block: for i in ids: downstream.setdefault(i, set()).update(ids - {i}) # 检查每个上游依据是否在别处被引用为下游产出 for down_id, up_ids in upstream.items(): for up_id in up_ids: if down_id not in downstream.get(up_id, set()): print(f"断链：{down_id} 声明上游 {up_id}，但 {up_id} 未声明下游 {down_id}") if __name__ == "__main__": check_trace("./docs")

逻辑说明：脚本按空行分块，识别包含“上游依据”和“下游产出”的块，建立双向映射。upstream记录每个下游 ID 声明的上游，downstream记录每个上游 ID 声明的下游。最后检查一致性，输出断链。参数说明：ID_PATTERN根据实际编号规则调整，比如需求用REQ-FUNC-012，测试用例用TC-FUNC-012。doc_dir是文档根目录。这个脚本建议在文档提交前跑一次，断链为 0 才允许合并。