(文 / 老孙)
高项倒计时冲刺特辑 Day 45 | 免费
字数约 7500，阅读大约需 15 分钟
一、开场：为什么说这是案例分析的"送分题"？
各位老铁，今天咱们聊的话题，老孙敢打包票——你把这篇文章吃透，案例分析至少能多拿5-8分。
为什么？因为配置管理和变更管理是案例分析中出镜率最高、套路最固定、答题模板最好用的两个知识领域。翻看历年真题你会发现，几乎每年的案例分析都会涉及变更管理或配置管理的内容，而且考法极其稳定——无外乎就是"找错+分析原因+给建议"三段论。
老孙先给你画个"全景图"，让你一眼看清这两个家伙的关系：
看到了吗？配置管理是"管家婆"，管的是"东西在哪儿、版本对不对、改没改过"；变更管理是"审批官"，管的是"能不能改、谁批准改、改完了没"。两者相辅相成：配置基线一旦建立，任何变更都必须走变更管理流程；变更完成后，又要回到配置管理去更新基线和状态报告。
这个"闭环"就是案例分析的命题核心。只要你理解了这个闭环，案例题就是填空题。
好，下面我们一个模块一个模块来扒。
二、配置管理：管家婆的六件套
2.1 配置项：到底管什么？
配置管理的第一步是搞清楚"管什么"。教材的定义是：配置项是为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。
翻译成人话：凡是项目中需要被管起来的"东西"，都叫配置项。
配置项的范围很广，典型的包括：
| 类别 | 举例 |
|---|---|
| 文档类 | 项目计划书、需求文档、设计文档、测试用例 |
| 代码类 | 源代码、可执行代码、脚本 |
| 数据类 | 运行软件所需的各种数据、配置文件 |
| 环境类 | 设备型号、关键部件、服务器配置 |
| 管理类 | 变更请求、服务协议、合同 |
考试关键点：配置项分为基线配置项和非基线配置项两类。
- 基线配置项：设计文档、源程序等技术产物 -- 向开发人员开放只读权限
- 非基线配置项：项目计划、报告等管理文档 -- 向项目经理、CCB及相关人员开放
口诀："基线只读，非基线可写（给管理层看）"。
2.2 配置项的三种状态
配置项有三种状态，它们之间的流转关系如下：
- 草稿：刚建立的配置项，版本号格式为
0.YZ（如0.01、0.02） - 正式：通过评审后的配置项，版本号格式为
X.Y（如1.0、1.1、2.0） - 修改：正式版被修改中，版本号格式为
X.YZ（如1.01、1.02），修改完毕重新评审后回到正式状态，Z归零
考试陷阱：题目经常给你一个版本号让你判断配置项状态。记住：看到0.xx就是草稿，X.Y就是正式，X.YZ（三位）就是修改中。
2.3 三库：开发库、受控库、产品库
这是配置管理最核心的考点，没有之一。老孙给你一个口诀，一句话记住三个库：
"开发库随便改，受控库走流程，产品库不能动"
| 库名 | 别称 | 谁用 | 权限 | 类比 |
|---|---|---|---|---|
| 开发库 | 动态库、程序员库、工作库 | 开发人员 | 自行控制，随意修改 | 你的草稿纸 |
| 受控库 | 主库 | 项目团队 | 完全配置管理，Check out/in | 公司的文件柜 |
| 产品库 | 静态库、发行库、软件仓库 | 交付使用 | 完全配置管理，只有发布才动 | 博物馆的展品 |
三库之间的流转是案例分析的"送分考点"。这里重点解释一下受控库的Check out/Check in机制：
- Check out（检出）：程序员从受控库取出代码到自己的开发库修改。代码被检出后即被"锁定"，同一段代码只能被一个人修改
- Check in（检入）：修改完毕后，从开发库送回受控库。检入后锁定解除，其他人可以继续检出
为什么要锁定？ 教材举了个经典例子：甲和乙同时从受控库取出同一个模块修改，甲先放回去，乙后放回去——结果乙的版本覆盖了甲的修改。锁定机制就是为了防止这种"覆盖灾难"。
一个完整的升级过程：
- 从产品库取出基线（如V2.1），放入受控库
- 程序员从受控库Check out到开发库修改
- 修改完毕Check in回受控库
- 全部修改完成后，新基线存入产品库（V2.2），旧版本保留
2.4 配置基线：冻结的快照
配置基线是一组配置项在某个特定时刻的"冻结快照"。一旦建立基线，这些配置项就不能随意修改了，对基线的变更必须遵循正式的变更控制程序。
基线的价值在于：
- 为项目提供一个定点和快照
- 当更新不稳定时，可以回退到基线
- 可以利用基线重现已报告的错误
- 新项目可以在基线上建立分支
基线通常对应项目的里程碑。交付给用户的叫发行基线（Release），内部使用的叫构造基线（Build）。
2.5 配置审计：功能审计 vs 物理审计
配置审计分为两种，这是选择题的高频考点：
| 对比维度 | 功能配置审计 | 物理配置审计 |
|---|---|---|
| 审什么 | 一致性（功能对不对） | 完整性（东西全不全） |
| 核心问题 | 配置项的实际功效是否与需求一致？ | 要交付的配置项是否存在？是否包含所有必需项？ |
| 类比 | 检查手机功能是否和说明书一致 | 检查包装盒里手机、充电器、说明书是否齐全 |
口诀："功能看对不对，物理看全不全"。
两个审计合在一起，我叫它"两审"。加上前面的三个库，就是今天的核心速记公式——"三库两审"。
2.6 配置状态报告
配置状态报告就是在某个时刻给配置项拍个"快照"，记录当前的状态。主要内容包括：
- 每个受控配置项的标识和状态
- 每个变更申请的状态和已批准修改的实施状态
- 每个基线的当前和过去版本的状态以及各版本的比较
- 其他配置管理过程活动的记录
三、变更管理：审批官的八步流程
3.1 变更管理的本质
变更在项目中是不可避免的。教材把变更分为两种：
- 主动变更：为了提高收益——降低成本、改进过程、提高便捷性
- 被动变更：为了应对问题——范围变化、异常、错误、环境变化
变更管理的实质是什么？根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。
3.2 变更管理两大原则
变更管理的原则就两个字："基"和"规"。
- 基准化：基准是变更的依据。先有基准，才能谈变更。每次变更通过评审后，都应重新确定基准。
- 规范化：所有变更都必须遵循统一的变更控制流程，不能"私下改、口头改、偷偷改"。
3.3 变更管理的完整流程
变更管理的工作程序是案例分析中考得最多的内容。教材给出了八步流程，老孙把它整理成一个完整的闭环：
每一步的要点总结：
| 步骤 | 核心动作 | 关键角色 | 案例常考的错误 |
|---|---|---|---|
| 1. 变更申请 | 书面形式提出 | 任何干系人 | 只口头提出，未留书面记录 |
| 2. 变更初审 | 确认必要性、格式校验 | 项目经理 | 未做初审就直接提交CCB |
| 3. 方案论证 | 技术+经济评估 | 技术专家 | 未进行影响分析就实施 |
| 4. CCB审查 | 批准/否决/推迟 | CCB | 项目经理擅自批准变更 |
| 5. 通知实施 | 调整基准、通知干系人 | 项目经理 | 变更后未通知受影响的干系人 |
| 6. 实施监控 | 监控执行情况 | 项目经理+CCB | 变更后未跟踪实施效果 |
| 7. 效果评估 | 评估目标达成情况 | CCB | 未评估变更效果 |
| 8. 变更收尾 | 确认纳入正轨、更新基线 | 配置管理员 | 变更后未更新配置基线 |
3.4 CCB：变更控制委员会
CCB是变更管理中最重要的角色，案例分析中出镜率极高。关于CCB，你需要记住以下几点：
CCB是决策机构，不是执行机构。 CCB负责审批变更，但不负责实施变更。实施变更是项目经理和项目团队的事。
CCB不是一个人，是一个委员会。 通常包括项目发起人、项目经理、客户代表、技术专家等。
CCB的核心职责：
- 审批变更请求（批准/否决/推迟）
- 审批配置管理计划
- 可以审查配置管理活动
- 紧急变更时，其中被授权者可行使审批权限
项目经理 vs CCB的分工：
| 项目经理 | CCB |
|---|---|
| 响应变更需求 | 审批变更请求 |
| 评估变更影响 | 决定是否变更基准 |
| 将技术需求转化为资源需求 | 监控主要成果和里程碑 |
| 实施变更（调整基准） | 提供决策支持 |
口诀："经理干活，CCB拍板"。
3.5 紧急变更处理
紧急变更是案例分析中特别爱出的"坑"。正常流程太慢，紧急情况下怎么办？
核心原则：可以先实施，但必须补办手续。
紧急变更的处理要点：
- CCB中被授权者可以行使紧急审批权限
- 紧急变更实施后，必须补办完整的变更审批手续
- 紧急变更的记录和文档不能少
案例常见错误：项目经理说"这是紧急变更"，然后既没有经过任何人审批，事后也没有补办手续。这是典型的送分题——答"紧急变更虽可先实施，但必须有CCB授权人的紧急审批，且事后必须补办完整的变更手续"。
四、配置管理与变更管理的关系：闭环才是王道
很多同学分不清这两者的关系。老孙用一个统一视角帮你打通：
用一句话概括：配置管理是"账本"，变更管理是"审批单"。改东西之前先查账本（配置基线），改东西要走审批单（变更流程），改完之后回去更新账本（更新基线和状态报告）。
教材原文的表述是：变更管理与配置管理为相关联的两套机制，变更管理在项目交付或基准配置调整时由配置管理过程调用，变更管理最终应将对项目的调整结果反馈给配置管理过程，以确保项目执行与项目配置信息相一致。
五、"三库两审"闭环速记口诀
老孙把今天的核心知识浓缩成一套速记口诀，考前反复默念：
三库：
- 开发库（动态库）：程序员的草稿纸，随便改
- 受控库（主库）：公司的文件柜，走流程（Check out/in + 锁定机制）
- 产品库（静态库）：博物馆的展品，不能动（只有发布才动）
两审：
- 功能配置审计：审"对不对"——实际功效是否与需求一致
- 物理配置审计：审"全不全"——要交付的东西是否存在、是否完整
变更六步（简化版）：
提 -- 评 -- 批 -- 改 -- 验 -- 关
- 提出变更（书面）
- 评估影响（技术+经济）
- 批准变更（CCB审批）
- 改（实施变更）
- 验证效果
- 关闭变更（更新基线、通知干系人）
闭环公式：
基线冻结 -> 变更申请 -> CCB审批 -> 实施变更 -> 验证通过 -> 更新基线 -> 新基线冻结
这个闭环就是案例分析的答题框架。无论题目怎么变，万变不离其宗。
六、案例分析中的常见考法与答题模板
6.1 三大经典考试场景
场景一：项目经理未经CCB审批直接修改代码
案例描述：张经理在项目开发过程中，接到客户要求增加一个功能模块的电话后，认为修改不大，就直接让开发人员修改了源代码，并将修改后的版本部署到了测试环境。
找错要点：
- 变更请求未以书面形式提出，只是口头沟通
- 未对变更进行影响分析和方案论证
- 未经CCB审批就直接实施变更
- 变更后未更新相关的配置基线和文档
- 变更后未进行验证确认
- 未通知其他受影响的干系人
场景二：变更后未更新配置基线
案例描述：某项目经过CCB审批后实施了一次范围变更，增加了两个功能模块。开发人员完成了编码和测试，项目经理宣布变更完成。但之后在项目验收时发现，需求文档、设计文档的版本仍然是变更前的版本，导致文档与实际交付的系统不一致。
找错要点：
- 变更实施后未更新相关的配置基线
- 未对变更后的配置项（需求文档、设计文档）进行同步更新
- 缺少配置状态报告的更新
- 未进行配置审计来确认文档与实际系统的一致性
- 变更收尾工作不完整，未确认所有受影响的配置项都已更新
场景三：紧急变更未补办手续
案例描述：项目上线前夕，系统出现了一个严重的安全漏洞。项目经理紧急联系开发人员修复了漏洞并重新部署。事后项目经理认为问题已经解决，没有再做其他处理。
找错要点：
- 紧急变更未获得CCB中授权者的紧急审批
- 事后未补办完整的变更审批手续
- 未记录变更的详细信息（变更原因、变更内容、影响范围）
- 未更新配置基线和相关文档
- 未对修复后的系统进行完整的回归测试和验证
- 未编制配置状态报告
- 未通知受影响的干系人
6.2 答题万能模板
不管题目怎么出，配置管理和变更管理的案例分析都可以套用以下模板：
第一段：找错（指出问题）
XX的做法不妥当。具体问题包括：（列举3-5个错误点）
第二段：分析（解释为什么错）
根据配置管理/变更管理的要求，正确的做法应该是：（说明正确流程）
第三段：建议（给出改进措施）
建议项目组采取以下措施改进：（具体建议3-5条）
七、三道模拟题（含答案）
模拟题一：变更管理流程题
题目：
阅读以下案例，回答问题。
某市政务信息化项目由甲公司承建，项目经理小王负责。项目进入编码阶段后，客户方提出需要增加"数据可视化大屏"功能。小王评估认为该功能技术难度不大，当天就安排开发人员开始编码实现。两周后，功能开发完成并集成到系统中。但在系统测试时发现，新增功能与原有的报表模块产生了数据冲突，导致部分原有功能出错。客户对此非常不满。
问题1：请指出项目经理小王在变更管理中的不当之处。（8分）
问题2：请说明正确的变更管理流程应该是怎样的。（7分）
参考答案：
问题1（8分）：
项目经理小王在变更管理中存在以下不当之处：
(1) 变更请求未以书面形式记录。客户口头提出的需求变更，小王未要求客户提交正式的书面变更申请。（2分）
(2) 未对变更进行充分的影响分析。小王仅凭个人判断认为"技术难度不大"，未组织技术专家进行全面的技术评估和影响分析，未评估新功能对现有系统的影响。（2分）
(3) 未提交CCB审批。小王擅自决定实施变更，未将变更请求提交变更控制委员会（CCB）进行评审和审批。项目经理无权单独批准变更。（2分）
(4) 变更后未更新配置基线和相关文档。新增功能完成后，未同步更新需求文档、设计文档等配置基线，也未进行配置审计。（1分）
(5) 未通知所有受影响的干系人。变更可能影响项目的进度、成本和其他功能模块，但小王未通知相关干系人。（1分）
问题2（7分）：
正确的变更管理流程应该是：
(1) 变更申请：客户以书面形式正式提出变更请求，说明变更内容和原因。项目经理或配置管理员负责接收并进行初审。（1分）
(2) 变更方案论证：组织技术专家对变更进行技术评估（新功能的实现方案、对现有系统的影响）和经济评估（工作量、成本、进度影响）。（1分）
(3) CCB审查：将变更申请和评估方案提交CCB，由CCB决定是否批准变更。（1分）
(4) 发出通知并实施：CCB批准后，调整项目基准（范围基准、进度基准、成本基准），通知所有受影响的干系人，然后按照批准的方案实施变更。（1分）
(5) 实施监控：项目经理对变更实施过程进行监控，确保按计划执行。（1分）
(6) 变更验证与效果评估：对变更后的系统进行测试和验证，确认新功能正常且不影响原有功能。评估变更目标是否达成。（1分）
(7) 变更收尾：更新所有受影响的配置基线和文档，编制配置状态报告，确认项目纳入正常轨道。（1分）
模拟题二：配置管理三库题
题目：
某企业ERP系统升级项目中，出现了以下情况：
(1) 开发人员甲和乙同时从服务器上下载了模块A的源代码进行修改。甲先修改完上传，乙后修改完上传。结果发现甲的修改被乙的版本覆盖了。
(2) 项目快结束时，测试人员发现测试环境中运行的系统版本与配置管理记录中的版本不一致。
(3) 系统上线后，用户反映某个已修复的Bug又出现了。经排查发现，上线版本并非最终测试通过的版本。
问题：请分析以上三个问题分别属于配置管理的哪个环节出了问题，并说明正确的做法。（15分）
参考答案：
(1) 问题分析：该问题属于配置库管理（受控库）和版本控制环节出了问题。项目未建立规范的受控库和Check out/Check in机制。（2分）
正确做法：应建立受控库，实行Check out/Check in机制和锁定策略。当甲从受控库检出模块A时，该模块被锁定，乙无法同时检出同一模块。甲修改完毕检入后，锁定解除，乙才能检出进行修改。这样可以避免版本覆盖的问题。（3分）
(2) 问题分析：该问题属于配置审计环节出了问题。项目未定期进行配置审计，未及时发现配置项与实际环境不一致的情况。（2分）
正确做法：应定期进行物理配置审计，核查实际运行环境中的配置项是否与配置管理数据库中的记录一致。如果发现不一致，应由配置项负责人调查差异原因，完成差异报告，并按照变更管理流程进行纠正。同时应定期编制配置状态报告，便于相关人员及时了解配置项的当前状况。（3分）
(3) 问题分析：该问题属于产品库管理和发布管理环节出了问题。项目在发布上线时，未从产品库中提取正确的经测试验证的版本进行部署。（2分）
正确做法：系统通过最终测试后，应将测试通过的版本作为发行基线存入产品库。上线部署时，必须从产品库中提取该发行基线版本进行部署，不能使用受控库或开发库中的版本。同时，在上线前应进行功能配置审计，确认部署的版本与测试通过的版本一致（功能是否正确），以及物理配置审计，确认所有必需的组件是否齐全（东西是否完整）。（3分）
模拟题三：综合场景题
题目：
某电子政务项目由A公司承建。项目开发过程中发生了以下事件：
事件一：项目组在开发初期就制定了配置管理计划，明确了配置项的分类和编号规则。但由于项目进度紧张，配置管理员将所有文档和代码都放在一个共享目录中，没有区分开发库、受控库和产品库。
事件二：项目中期，上级主管部门要求系统必须增加"电子签章"功能。项目经理认为这是上级的命令，不需要走变更流程，直接安排开发人员实施。
事件三：项目后期，客户要求修改系统首页的布局。项目经理按照变更管理流程提交了变更申请，CCB审批通过后，开发人员完成了修改。但项目经理忘记更新需求规格说明书和界面设计文档中的相关内容。
问题：请分别指出三个事件中存在的问题，并给出改进建议。（15分）
参考答案：
事件一（5分）：
存在的问题：虽然制定了配置管理计划，但在执行中未建立规范的三库体系。将所有配置项放在同一个共享目录中，没有区分开发库、受控库和产品库，会导致以下问题：无法实现有效的版本控制和访问权限管理；开发中的半成品和已发布的成品混在一起，容易造成版本混乱；无法实现Check out/Check in和锁定机制，存在版本覆盖风险。（3分）
改进建议：应按照配置管理计划，建立开发库、受控库和产品库三级配置库体系。开发库由开发人员自行管理，用于日常开发；受控库由配置管理员统一管理，实行Check out/Check in机制，存放当前基线；产品库存放已发布的产品基线，实行严格的访问控制。（2分）
事件二（5分）：
存在的问题：不论变更的来源是什么（包括上级主管部门的指令），都必须遵循变更管理流程。项目经理直接实施变更，存在以下错误：未以书面形式记录变更请求；未进行变更影响分析和方案论证；未提交CCB审批；未评估该变更对项目范围、进度、成本和质量的影响。（3分）
改进建议：应按照变更管理流程处理。首先将上级要求以书面形式记录为变更申请；然后组织技术专家评估增加"电子签章"功能对现有系统架构、开发进度和项目预算的影响；将评估结果提交CCB审批；审批通过后调整项目基准（范围基准、进度计划、成本预算），通知所有干系人后再实施。（2分）
事件三（5分）：
存在的问题：变更实施后，项目经理未同步更新受变更影响的配置基线和相关文档（需求规格说明书、界面设计文档）。这会导致文档与实际系统不一致，后续维护和验收时产生混乱。此外，项目经理也未进行变更收尾工作，未确认所有受影响的配置项是否都已更新。（3分）
改进建议：变更实施完成并验证通过后，应同步更新所有受影响的配置项，包括需求文档、设计文档、测试用例等。更新后应重新进行评审，确认配置项版本的正确性和一致性。同时应编制配置状态报告，记录本次变更涉及的所有配置项的版本变化。最后应进行配置审计，确认文档与系统的一致性（功能配置审计）和完整性（物理配置审计）。（2分）
八、本章知识一图总结
九、考前叮嘱：记住这几句话就够了
配置管理和变更管理的考试，归根到底就是考你"有没有按流程办事"。
选择题：三库的别名（动态库=开发库、主库=受控库、静态库=产品库）、两种审计的区别（功能审计看一致性、物理审计看完整性）、配置项状态和版本号的对应关系。
案例分析：永远记住两个"闭环"——变更管理的六步闭环（提-评-批-改-验-关）和配置管理与变更管理之间的大闭环（基线冻结->变更->更新基线）。然后对照闭环找"哪一步没做"，就是答案。
最后送你今天的核心口诀：
三库两审记心间，
开发随改受控严。
产品库是不能动，
功能对错物理全。
变更六步提评批，
改了验了才能关。
CCB拍板经理干，
紧急事后要补单。
好了，今天的内容就到这里。明天见。
(全文完)
系列导航：本文是「高项冲刺特辑」Day 45。Day 44讲的是论文主题精讲，Day 46将进入案例分析综合实战演练。
文章首发于公众号「软考找老孙」，转载请注明出处。