Appearance
配置管理与变更管理：管住"版本"与"改动"
本页导读：配置管理与变更管理是软考特色考点（PMBOK 体系内着墨少，第4版教程单独成章），也是信息系统项目案例题的保留节目。主线两条：配置管理管"是什么版本"（配置项、基线、配置库、配置审计），变更管理管"能不能改、怎么改"（CCB、变更八步流程）。两者关系：配置管理是变更管理的基础——改之前先知道"现在是什么"。本页不按过程组讲，按知识块组织，全部对应选择题与案例题考法。
一、知识框架图
- 配置管理
- 配置项：产品/过程工件，含版本与状态
- 基线：功能基线、分配基线、产品基线
- 配置库：开发库、受控库、产品库
- 配置管理活动：配置项识别、配置项控制、配置状态报告、配置审计（功能+物理）
- 变更管理
- 变更分类：重大/一般、紧急；基准变更与非基准变更
- 变更控制委员会（CCB）
- 变更八步流程
- 与整体变更控制（4.6）的关系
- 二者关系：配置管理提供版本/基线底座，变更管理控制对基线的改动
二、配置管理精讲
1. 配置项
定义：为配置管理设计的、满足最终使用功能的产品或过程工件，需纳入配置控制。硬件、软件、文档（需求规格、设计文档、测试用例、计划）皆可为配置项。
分类（主流口径）：
- 产品配置项（交付件）：交付给客户的软件、硬件、文档（如系统程序、用户手册）。
- 非产品配置项（过程件）：不直接交付但支撑过程的工件（如项目计划、质量报告）。
配置项状态：草稿 → 正式发布 → 正在修改。草稿自由编辑；成为正式版本后入库受控；修改需走变更/出库-入库流程。
版本编号（主流惯例）：处于"草稿"状态 0.x.y；"正式发布"状态 X.Y；"正在修改"状态 X.YZ。规则以组织规范为准，考概念不抠细节。
2. 基线（高频）
定义：一组经正式审查和同意的规格或工作产品，作为进一步开发的基础，只有通过正式变更控制程序才能改变。
| 基线类型 | 形成时机 | 内容 |
|---|---|---|
| 功能基线 | 需求分析完成后（需求规格说明书通过评审） | 系统的功能与技术指标定义 |
| 分配基线 | 概要设计/需求分配完成后 | 把功能需求分配到各部件的设计规格 |
| 产品基线 | 测试与验收阶段形成 | 最终交付产品的完整配置（含版本） |
考点：基线不是不可改，而是"改必须走正式变更控制"；先有评审、再入库、才成基线；三大基准（范围/进度/成本）与配置基线概念相通但侧重不同。
3. 配置库（高频，案例题判断"放哪个库"）
| 库 | 别名 | 内容 | 权限特点 |
|---|---|---|---|
| 开发库 | 动态库/工作区 | 开发人员日常工作版本，频繁修改 | 开发人员自由读写（按任务授权） |
| 受控库 | 主库 | 通过评审/测试待集成的基线版本、各阶段里程碑版本 | check-in/check-out 受控，修改需走变更 |
| 产品库 | 静态库/备份库 | 已发布交付的正式版本 | 严控，一般只读/归档，出库要审批 |
典型流程：开发库写代码 → 评审通过后检入受控库形成基线 → 交付发布后入产品库归档。
配置管理计划内容速览：配置项识别规则（哪些入库、命名编号）、三库划分与权限矩阵、基线建立与变更规则、配置审计安排（何时做、谁做）、配置状态报告的频度与受众、工具与角色（配置管理员 CMO）职责。该计划是项目管理计划中"配置管理计划"组件的落地文件。
4. 配置管理活动（四大活动，必背）
- 配置项识别：确定哪些工件纳入配置管理、命名与编号规则。
- 配置项控制（版本控制与变更控制）：出库—修改—评审—入库的全流程控制，保证任何变更可追溯。
- 配置状态报告（状态记账）：记录并报告配置项的状态变化（版本、变更申请与批准情况、基线状态），回答"现在系统是什么版本、改过什么"。常用形式：变更请求状态、版本发布说明、基线清单。
- 配置审计：
- 功能配置审计（FCA）：核实配置项的功能特性与需求文档一致（"做的和说的一致"）。
- 物理配置审计（PCA）：核实物理形态（构成、版本、介质、文档齐套性）与设计文档一致（"交的和记的一致"）。
- 审计保证"配置库中的 = 真实的 = 文档记录的"。
角色：配置管理员（CMO/配置库管理员）负责日常配置库操作；配置控制委员会（有时与 CCB 合设）审批配置变更。
三、变更管理精讲
1. 变更的必要性与原则
- 项目渐进明细 + 环境变化 ⇒ 变更不可避免；放任自流 = 范围蔓延 + 基线失效。
- 三大原则（教材口径）：基准化原则（变更前有基线）、变更控制原则（一切改动走流程）、过程记录原则（变更全程留痕可追溯）。
- 信息系统项目变更的主要来源：需求变化、技术更新、外部环境、纠错与优化。
2. 变更分类
- 按对象：基准变更（动范围/进度/成本基线，必须 CCB）与非基准变更（一般文档、过程调整）。
- 按影响：重大变更/一般变更（分级审批）。
- 紧急变更：危机情形下可先实施、后补审批手续（案例题给"机房宕机连夜改配置"判断是否合规——补手续即可合规）。
3. 变更控制委员会（CCB）
- 组成：由项目主要干系人代表组成（项目发起方、管理方、实施方、技术专家、客户代表等），可设多级（公司级/项目级），主席常由有决策权的管理者担任。
- 职责：审批变更（批准、否决、推迟）；不负责实施变更，也不负责提出变更。
- 考点：CCB 是决策机构；基准变更必须经 CCB；项目经理负责提交与执行。
4. 变更管理八步流程（必背顺序，主流教材口径）
- 提出与接受变更申请：任何干系人均可提出，书面提交（变更申请单）。
- 对变更初审：确认变更信息完整、进行形式审查（谁提的、为什么、改什么）。
- 变更方案论证：评估技术可行性与影响（范围/进度/成本/质量/风险），提出实施方案。
- 项目管理委员会（CCB）审查：批准、否决或延期决定。
- 发出变更通知并组织实施：更新受影响的项目管理计划与项目文件（基线），实施变更。
- 变更实施的监控：跟踪实施过程，确认按批准的方案执行。
- 变更效果的评估：验证变更是否达到目的、是否引入新问题。
- 判断发生变更后的项目是否已纳入正常轨道：更新配置库（新版本/新基线）、关闭变更单、归档，项目按新基线运行。
记忆口诀：提—审—论—批—行—控—评—归。
5. 与整体变更控制（4.6）的衔接
PMBOK 的"实施整体变更控制"是过程视角（ITO 见 整合管理）；第4版教程的"变更管理八步"是操作视角——案例题按八步找错：跳过评估直接实施、CCB 未批先改、实施后不更新基线、变更结果不验证、变更记录不归档，都是标准错误答案来源。
6. 变更流程常见错误清单（案例找错模板）
- 口头变更、无书面申请。
- 项目经理未经评估直接答应/拒绝客户。
- 未走 CCB 审批就实施基准变更。
- 批准后不更新计划与基线、不通知相关干系人。
- 实施后不验证效果、不做配置入库。
- 变更记录缺失，无法追溯。
四、高频考点与易错点
- 库判断题：给场景选库——"开发中频繁修改的代码"→开发库；"通过评审的需求基线"→受控库；"已交付客户的正式版本"→产品库。
- 基线三分类：功能基线（需求）、分配基线（设计）、产品基线（交付）；基线可改但必须走变更控制。
- 配置审计二分：功能审计对"功能一致性"、物理审计对"构成齐套性"——张冠李戴是高频坑。
- 八步顺序题：论证在初审之后、CCB 审批在实施之前；监控在实施之后；评估后判断是否回正轨。
- CCB 职责：只批不改；实施归项目经理与团队。
- 易错：配置状态报告属于配置管理活动（不是给客户的绩效报告）；紧急变更"先做后补"合法但必须补；变更完成后要"入库归档"才算闭环。
五、例题（自编模拟题）
【例题 1】 某项目客户口头要求增加一个统计报表。实施人员当天完成了开发并上线。正确的做法应该是（ ）。
A. 口头需求响应快，符合客户至上原则，做法正确 B. 应要求客户提交书面变更申请，评估影响后交 CCB 审批，批准后实施并验证、归档 C. 由项目经理直接决定是否实施即可，无需 CCB D. 只要客户愿意追加费用，可以直接实施
答案：B
解析：变更管理第一原则是书面化与流程化：书面申请 → 初审 → 论证（影响评估）→ CCB 审批 → 通知实施 → 监控 → 评估 → 归档。A、D 违反流程，C 混淆了基准变更的审批主体。选 B。
【例题 2】 关于配置库，下列说法正确的是（ ）。
A. 开发人员可以直接修改受控库中的基线版本 B. 开发库中的工作产品经评审通过后应检入受控库 C. 产品库用于开发人员的日常频繁修改 D. 三库的访问权限设置相同，靠自觉管理
答案：B
解析：受控库修改必须走出库-变更-评审-入库的受控流程，A 错；日常频繁修改发生在开发库，C 错；三库权限从松到严，D 错。B 是标准流程。选 B。
【例题 3】 变更实施完成并通过验证后，项目经理还应完成的收尾动作是（ ）。
A. 直接删除变更申请记录以简化文档 B. 更新配置库中的版本与基线、关闭变更单并归档，通知相关干系人 C. 保持旧版本继续发布，等下个版本再合并 D. 仅口头通知开发团队变更已完成
答案：B
解析：变更闭环的最后一步是"判断项目是否已纳入正常轨道"：配置入库（新版本/新基线）、变更单关闭归档、干系人书面通知。A、D 违反留痕原则，C 会造成版本混乱。选 B。
六、配置管理与变更管理协作示例（把两者串起来）
一个需求变更的完整闭环（案例题满分顺序）：
- 客户提交书面变更申请（变更单编号入库）。
- 初审确认信息完整，组织评估影响（范围/进度/成本/质量/风险）。
- 论证实施方案，报 CCB 审批。
- 批准后：从受控库出库受影响文档与代码（配置项控制）。
- 开发库实施修改，完成后评审与测试。
- 验证通过：新版本检入受控库，更新基线；已交付则入产品库。
- 配置状态报告记录版本与变更状态；变更单关闭归档。
- 通知相关干系人，项目按新基线运行。
配置管理常见场景判断速查：
| 场景 | 判断 |
|---|---|
| 未经出库审批直接改了受控库文档 | 违反配置项控制 |
| 发给客户的版本与测试版本不一致 | 缺配置审计/状态报告 |
| 基线变了但没人知道改了什么 | 缺配置状态报告 |
| 交付时发现缺《安装手册》 | 物理配置审计能发现 |
| 需求规格与实现功能对不上 | 功能配置审计能发现 |
七、本页小结
- 配置管理四活动：识别、控制、状态报告、审计（功能 FCA + 物理 PCA）。
- 三库：开发库（随便改）→ 受控库（改要走流程）→ 产品库（严控归档）。
- 三基线：功能（需求）→ 分配（设计）→ 产品（交付）。
- 变更八步：提—审—论—批—行—控—评—归；CCB 只批不改；紧急变更先做后补。
- 配置是"底座"，变更是"闸门"：改之前知道是什么，改之后记得入库归档。
下一篇：项目集/项目组合管理与 OPM。