第 19 章 配置与变更管理
如果说第 8 章的「实施整体变更控制」是从整合管理视角看变更，本章就是把镜头拉远：从组织级流程与配置支撑的视角，讲清楚变更凭什么被管得住——靠配置管理管住「物」（配置项、基线、版本），靠变更流程管住「事」（申请、审批、实施、验证）。本章流程步骤是案例分析与综合知识的双料必背内容，一步都不能背错。
一、考情分析
命题规律与抓分重点：
- 「三库」判定题几乎必考一道。给出一个场景（开发人员日常修改代码、基线化后的文档、发布给客户的版本），判断应放入开发库、受控库还是产品库，三者「存放内容—可修改性—管理者—流转规则」必须滚瓜烂熟。
- 变更管理流程排序是铁打的考点。「提出申请 → 影响分析 → CCB 审批 → 实施 → 监控 → 评估效果 → 更新基线/关闭」的顺序不容错位，命题人最爱把「实施」提前到「审批」之前做干扰。
- 两类配置审计的辨析年年出现。功能配置审计查「功能与需求一致」，物理配置审计查「实物与文档一致」——「功能/物理」「性能/形态」一换位就掉坑。
- 变更管理三原则是判断题题眼。「必须走流程、必须经 CCB 审批、未经批准的变更不得实施」，任何「先做后批、边做边批、特殊情况免批」的表述都是错的。
- 抓分策略：本章分数完全属于「背了就有」的类型。把三库对比表、流程步骤、两种审计的检查对象背成肌肉记忆，再配合案例题练习「变更失控」的标准诊断话术。
二、学习目标
| 目标层级 | 具体目标（学完后应能做到） |
|---|---|
| 知识层 |
|
| 能力层 |
|
| 素养层 |
|
三、配置管理基础：目标与配置项
3.1 配置管理的目标与作用
配置管理（Configuration Management, CM）是通过技术或行政手段对配置项及其修改加以系统化管理的一组活动，其目标是：全面地保存和记录配置项的历史版本、变更记录与相互关系，使项目在任何时刻都能准确获知「现在的系统由什么构成、每个成分处于什么状态、经历过什么变化」。
配置管理的作用可以概括为四个方面：
- 版本留存与追溯：完整保存配置项的相关历史记录与版本，需要时可回溯任一历史状态；
- 变更受控：追踪每一项变更，确保变更经过评估与审批后才进入产品，防止未经授权的修改；
- 信息透明：使项目干系人（开发、测试、客户、维护方）随时了解配置项的最新状态，避免「各拿各的版本」；
- 支持审计与交付：为配置审计、产品交付与后期运维维护提供准确、完整的配置信息。
理解提示：一句话定位——配置管理管「物」的状态，变更管理管「事」的流程。变更管理要落地，必须以配置管理为基础（没有基线和版本，变更就无对象可改、无状态可控）；配置管理要有生命力，必须靠变更流程驱动（每次受控变更最终都要回到配置库中固化为新版本）。考试考二者关系时，抓住这句即可。
3.2 配置项及其分类
配置项（Configuration Item, CI）是配置管理的基本单位，指配置管理过程中作为独立实体进行管理的各种工作产品。凡纳入配置管理的工作成果——需求文档、设计文档、源代码、测试用例、数据、可执行程序、用户手册乃至项目计划本身——都可以是配置项。
配置项通常分为两大类：
| 配置项类别 | 含义与范围 | 典型示例 |
|---|---|---|
| 产品类配置项 | 最终交付给客户、构成产品实体的工作产品 | 可执行程序、发布的数据、用户手册、培训材料、交付文档 |
| 开发过程类配置项 | 为创造产品服务、在开发过程中产生和使用的管理与技术工作产品 | 需求规格说明书、设计说明书、源代码、测试计划与用例、项目管理计划、会议纪要等过程文档 |
配置项识别的要求：并非所有文件都值得当配置项管理——识别时应考虑交付要求、复用程度、变更频率与管理成本，为每个配置项赋予唯一的标识号，并记录其名称、类型、负责人、状态等属性，登记入配置管理数据库。
口诀（配置项两分法）：「交付的是产品，过程留的是开发」。判断某物属于哪类配置项，就问一句：客户最终要不要拿走？要——产品类；不要、只是造它的中间产物——开发过程类。再补一句三库口诀：「开发随便改，受控要审批，产品锁保险柜」。
四、基线与三库
4.1 基线：配置项的「冻结」状态
基线（Baseline）是经正式审查和同意、作为后续工作出发点的一组配置项版本。基线一经建立，只能通过正式的变更控制程序才能修改——这就是「冻结」的含义：不是不许改，而是改必须走流程。项目通常设置三类基线：
| 基线类型 | 建立时机（标志性事件） | 冻结的对象 | 作用 |
|---|---|---|---|
| 功能基线 | 需求规格说明书通过正式评审并获得批准之时 | 系统应具备的功能与性能需求 | 确定「做什么」，是后续设计与验证的功能依据 |
| 分配基线 | 经评审批准的设计文档确定、需求被分配到各配置项（子系统/部件）之时 | 分配后的功能与性能需求（设计规格） | 确定「分给谁做」，连接需求与实现、支撑集成验证 |
| 产品基线 | 产品通过系统测试与验收（可交付）之时 | 产品的完整技术描述（最终形态的版本、文档、介质） | 确定「交付什么」，是交付与运维的依据 |
三类基线在时间上依次推进，构成「需求 → 设计 → 产品」的冻结链条：功能基线冻结需求，分配基线冻结设计分配，产品基线冻结最终产品形态。每条基线的变更都须经变更控制程序批准。
高频陷阱：三条基线的建立时机最易张冠李戴——「通过系统测试验收」建立的是产品基线而非分配基线；「需求规格评审通过」建立的是功能基线而非产品基线。命题人惯用「时机与类型错位」设置干扰项，记忆时把「功能=需求评审、分配=设计确定、产品=测试验收」绑死。
4.2 配置库：开发库、受控库、产品库（本章第一必背表）
配置库是存放配置项的物理或逻辑场所，按受控程度从低到高分为三类：开发库（工作库）、受控库（主库）、产品库（备份库）。三库的定位与流转规则是本章最高频考点：
| 配置库 | 存放内容 | 可修改性 | 管理者 | 流转规则 |
|---|---|---|---|---|
| 开发库 （工作库） | 开发人员正在进行开发、尚未定稿的工作版本：正在修改的代码、草稿文档 | 开发人员可自由修改、频繁更新，无需审批 | 开发人员本人（各自的工作区） | 工作成果完成并通过评审/检查后，检入受控库；开发库中的版本不作为对外交付或测试的依据 |
| 受控库 （主库） | 已通过评审、基线化的配置项：基线版本的需求/设计文档、受控的源代码、测试版本 | 不能随意修改；修改必须提出变更申请，经审批（CCB）通过后方可实施 | 配置管理员（CMO）负责管理，变更须经 CCB 批准 | 基线建立于受控库；变更实施并验证合格后形成新版本回存受控库；产品发布时从受控库提取并经审批转入产品库 |
| 产品库 （备份库） | 已交付或发布的最终产品版本：发布的程序包、交付文档、发行介质 | 原则上不允许修改；确需修改（如打补丁）须走更高级别的正式变更审批 | 配置管理员管理，发布通常需经项目管理层/组织批准 | 产品库中的版本是交付客户与对外发布的唯一来源；后续维护分支须从产品库版本派生 |
三库的流转形成一条单向主线：开发库（自由修改）→ 评审通过、检入受控库（基线化、变更受控）→ 测试验收合格、转入产品库（发布交付）。受控程度递增、修改自由度递减，是「越接近客户、越严格」的工程治理逻辑。
案例：某软件公司项目组曾发生这样一幕：测试人员直接从开发人员电脑拷了一份「最新代码」来测，测出的缺陷开发说「早改好了」；客户现场演示时用的版本又和两者都不同，当场演示失败。分析：三库制度被绕开——测试版本应从受控库的基线版本获取，而不是从开发库（开发人员工作区）随意拷贝；对外演示/交付版本必须出自产品库。三个版本各说各话，正是「未受控的版本满天飞」的典型症状。改进：所有测试只认受控库版本号，所有交付只认产品库版本号，版本信息由配置管理员统一发布；开发人员的任何修改要被外界看到，必须先经过评审检入受控库。
五、配置管理过程、版本控制与工具
5.1 配置管理的过程
配置管理包含四个基本过程（活动）：
| 过程 | 做什么 | 关键产出 |
|---|---|---|
| 配置项标识 | 识别应纳入管理的配置项并确定其属性（名称、类型、编号、负责人等），建立唯一标识规则 | 配置项清单（配置项识别记录）、标识命名规范 |
| 配置控制 | 对基线的变更实施控制：受理变更申请、组织审批、控制检入检出权限，防止未授权修改 | 变更审批结果、更新后的基线版本 |
| 配置状态记录 （状态报告） | 记录并报告配置项的状态变化历史：何时检入、何人修改、处于何版本、变更情况，供干系人随时查询 | 配置状态报告（版本发布说明、变更记录汇总） |
| 配置审计 | 定期或在关键节点审查配置管理活动与配置项状态，验证配置项的完整性与一致性 | 配置审计报告（功能配置审计、物理配置审计结论） |
四个过程不是一次性动作，而是贯穿项目始终的循环：先标识（认识对象）→ 再控制（管住修改）→ 同步记录（留下痕迹）→ 定期审计（验证可信）。
5.2 功能配置审计与物理配置审计（本章第二必背辨析）
配置审计分两类，检查对象与目的必须分清：
- 功能配置审计（Functional Configuration Audit）：检查对象是配置项的功能与性能——验证配置项的实际功能、性能是否与需求（功能基线/需求规格）一致，即「做出来的东西是不是需求要的」。手段包括审查测试记录、运行验证、需求跟踪核对。
- 物理配置审计（Physical Configuration Audit）：检查对象是配置项的物理形态——验证交付的实物（程序、介质、文档）与配置文档、清单所描述的内容是否一致、齐全，即「交出来的东西和档案说的是不是一回事」。手段包括核对版本清单、清点交付介质与文档齐套性。
一句话区分：功能审计对需求查性能，物理审计对文档查实物。二者通常在产品交付前先后实施，共同确认「产品既满足需求，又与描述相符」。
5.3 版本控制
版本控制是配置管理的日常核心动作：为配置项的每一次演化赋予规则化的版本号，使任何历史状态可定位、可获取、可回退。常用的版本编号约定如「主版本号.次版本号」：重大修改（基线变更）提升主版本号，局部修改提升次版本号；处于草稿态、评审中、正式发布等不同状态的配置项也可用状态标识加以区分。版本控制要能做到：任何时刻明确「当前有效版本是哪个」、任何变更都可追溯到「从哪个版本改来、改了什么、谁改的」。
5.4 配置管理工具
现代项目的配置管理依托工具落地，常见的版本控制与配置管理工具包括集中式的 SVN、分布式的 Git，以及 ClearCase 等企业级配置管理平台。工具提供的分支/合并、检出/检入、权限控制、变更历史追溯能力，正是「受控库只能通过变更程序修改」这一规则的技术保障。工具选型应关注：权限模型是否支持三库分离、审计日志是否完整、与构建发布流程的集成度。
口诀（配置管理四过程）：「标识—控制—记录—审计」。谐音记法「标控录审」：先给东西挂牌（标识），再管住手（控制），留下账本（记录），定期盘库（审计）。再记两种审计的分工：「功能对需求，物理对实物」。
六、变更管理基础：原因、分类与原则
6.1 变更的常见原因
项目变更的来源是多元的，常见原因包括：
- 产品范围与绩效的定义缺失或偏差：前期需求界定不完整、不清晰，执行中被迫调整——这是信息系统项目最常见、代价最高的变更来源；
- 项目范围（工作）定义的缺失或偏差：WBS 分解不充分导致工作遗漏或理解偏差；
- 外部环境变化：政策法规、市场环境、行业标准的调整（如监管新规要求新增数据报送接口）；
- 技术发展：新技术、新平台出现或原定技术路线不可行，需要调整方案；
- 客户或干系人需求变化：业务调整、人员更替带来的期望与要求变化；
- 项目执行偏差：进度、成本、质量的实际偏差引发纠偏性调整。
6.2 变更的分类
| 分类维度 | 类别与含义 |
|---|---|
| 按变更的性质与目的 |
|
| 按变更的紧迫程度 |
|
6.3 变更管理基本原则（判断题题眼，逐句背）
- 变更必须走流程：任何变更都应通过正式的变更管理流程提出、评估与处置，不允许口头变更、私下变更；
- 变更必须经 CCB 审批：变更申请须经变更控制委员会（CCB）评估与批准后方可实施，项目经理个人无权代替 CCB 批准基线变更；
- 未经批准的变更不得实施：未走完审批程序的变更一律不得进入产品——「先干着、回头补」同样违规（紧急变更的「事后补办」是规则允许的例外程序，不是违规）；
- 变更应尽早提出、集中处理：变更提出越晚，影响面与代价越大；应建立变更的提出渠道与受理机制，避免变更积压失控；
- 变更实施后须验证并更新基线：变更完成后要验证效果、更新配置库与基线，使变更结果固化，防止「改了但没记录」。
高频陷阱：命题人常给出「项目经理为了不耽误进度，口头同意供应商修改接口，事后补充书面手续」「变更影响不大，由项目经理直接批准实施」等场景让你判断对错——前者是先实施后审批的违规，后者是越权审批的违规，二者都违反「必须经 CCB 审批、未经批准不得实施」。注意区分：紧急变更是「规则允许的特事特办 + 事后补办手续」，与「怕麻烦不走流程」有本质区别。
七、变更管理全流程与 CCB
7.1 变更控制委员会（CCB）
变更控制委员会（Change Control Board, CCB）是决策机构，不是执行机构：它受理、评估并批准或否决变更请求，本身不负责实施变更。
- 组成：由项目的主要干系人代表组成，通常包括用户（客户）代表、实施方管理层、项目经理、技术专家（架构/领域负责人）、配置管理员等；具体组成与审批权限由组织的变更管理制度规定，可按变更影响级别分级设置（如重大变更上组织级 CCB、一般变更上项目级 CCB）；
- 职责：审议变更影响分析结论，对变更请求做出批准、否决或延期的决定；批准基线的建立与变更；对已批准变更的实施方案进行确认；其决议应形成书面记录并通知相关干系人。
理解提示：常考三问：①CCB 是决策机构还是执行机构？——决策机构；②项目经理能否自行批准变更？——不能，项目经理是变更流程的组织者与影响分析的组织者，不是审批人；③CCB 的决定是否必须书面？——是，且须记入变更日志并向干系人通报。
7.2 变更管理全流程（流程必背，共七步）
变更管理流程的完整步骤与每步的责任人、产出如下——顺序、责任人、产出文档三个维度都要背：
- 提出变更申请。谁做：变更提出人（任何干系人：客户、团队成员、供应商、项目经理均可提出）。做什么：以书面或系统电子表单形式提交变更请求，说明变更内容、理由与紧急程度。产出：变更申请单（变更请求）。
- 变更影响分析。谁做：项目经理组织相关技术与管理人员进行。做什么：评估变更对范围、进度、成本、质量、资源、风险的影响及备选方案，形成分析结论报 CCB。产出：变更影响分析报告。
- CCB 审批。谁做：变更控制委员会。做什么：基于影响分析结论，决定批准、否决或延期；批准时明确实施要求与资源。产出：批准（或否决）的变更请求、CCB 决议记录。
- 实施变更。谁做：项目经理组织团队按批准的方案执行。做什么：更新相关计划与文档，从受控库提取配置项实施修改，按批准的范围与方案完成变更。产出：变更后的配置项与更新的项目文件。
- 监控变更实施。谁做：项目经理及变更管理相关人员。做什么：跟踪实施过程，确认变更按批准的方案、范围与进度执行，防止「批一套、做一套」引入新偏差。产出：变更实施记录（监控跟踪记录）。
- 评估变更效果。谁做：项目经理组织，测试/质量及提出人参与验证。做什么：验证变更是否达到预期目标、是否引入新问题，结果反馈相关干系人；未达预期的变更需重新处置。产出：变更验证（评估）报告。
- 更新配置与基线，关闭变更。谁做：配置管理员执行，项目经理确认。做什么：将验证合格的变更结果检入受控库、更新基线与版本号，登记变更日志，正式关闭该变更。产出：更新的基线与配置状态记录、关闭的变更日志条目。
口诀（变更七步）：「申—析—批—施—控—评—闭」。谐音「深（申）析皮（批）士（施）控评币（闭）」不好记，直接背场景链更稳：有人申请 → 项目经理分析 → CCB 批准 → 团队施工 → 经理控场 → 验收评估 → 管理员闭库结案。前两步是「纸面」，中间三步是「动手」，最后两步是「收口」。
7.3 变更与其他管理领域的接口
- 与范围管理：经批准的需求变更转化为范围基准的更新，防止范围蔓延与镀金；
- 与整合管理：变更控制是整体变更控制的核心内容，批准的变更须落实到项目管理计划的相应组成部分；
- 与进度、成本管理：影响分析必须量化对工期与预算的冲击，批准后同步更新进度与成本基准；
- 与风险管理：影响分析中评估变更引入的新风险，重大变更应更新风险登记册；
- 与配置管理：变更的结果最终通过配置管理固化——更新受控库、刷新基线版本，形成「流程驱动状态、状态反过来支撑流程」的闭环。
八、三组易混概念辨析与章节衔接
8.1 配置管理 vs 变更管理
| 比较维度 | 配置管理 | 变更管理 |
|---|---|---|
| 管理对象 | 配置项及其版本、状态（「物」） | 变更请求从提出到关闭的全过程（「事」） |
| 核心关注 | 版本留存、状态可追溯、修改受控 | 变更被评估、审批、实施、验证后才生效 |
| 典型活动 | 配置项标识、配置控制、状态记录、配置审计 | 变更申请、影响分析、CCB 审批、实施、监控、评估、关闭 |
| 二者关系 | 变更管理以配置管理为基础（变更的对象与结果是配置项）；配置管理靠变更流程保持受控与有序——相辅相成，缺一不可 | |
8.2 变更请求 vs 变更日志
- 变更请求：针对基线或受控配置项提出的正式修改要求，是变更流程的起点与审批对象，由变更提出人发起；
- 变更日志：对已受理变更的处理情况的记录，登记每项变更的状态（已提出/分析中/已批准/已实施/已关闭/已否决）与流转信息，由项目经理维护、随项目报告发布。
一句话区分：变更请求是「申请单」，变更日志是「台账」——前者是流程的输入，后者是流程的账本。
8.3 本章与第 8 章「实施整体变更控制」的关系（防困惑必读）
很多考生学到本章会困惑：第 8 章不是已经讲过变更控制了吗？两章并不重复，视角不同：
- 第 8 章从整合管理视角讲变更：实施整体变更控制是整合管理的监控过程之一，强调变更请求要经整体审查与审批、批准的变更纳入项目管理计划与工作执行、变更的决策由变更控制委员会或指定责任人作出——回答的是「变更在项目管理过程中如何被整合地控制」；
- 第 19 章从组织级流程与配置支撑视角讲变更：把变更管理放大为一套组织级的管理制度与作业流程——变更的分类分级、CCB 的组织构成、七步流程的岗位分工与文档产出，并补上了变更管理得以落地的物质基础——配置管理（三库、基线、版本、审计）。回答的是「组织如何建一套管得住变更的机制」。
简言之：第 8 章告诉你「为什么变更要整体控制、控制到哪里」，第 19 章告诉你「具体怎么建流程、靠什么管住」。考试答题时按题目落点选视角：过程输入输出题用第 8 章框架，流程步骤与配置库判定题用本章框架。
理解提示：案例分析中诊断「变更失控」时，两章要联合使用：先用第 8 章「变更必须经整体变更控制」定性问题（缺少整体控制机制），再用本章「七步流程 + 三库规则 + CCB 职责」逐条指出缺失环节与改进措施——这样答题既有高度又有细节。
九、典型案例分析
案例：某 CRM 项目「需求频繁变更导致失控」的诊断
背景：某软件公司为客户开发 CRM 系统，合同工期 8 个月，采用预测型开发。项目进行到第 5 个月时出现严重失控：客户业务部门直接给开发人员打电话提新需求，开发人员「顺手就改」；累计已发生 40 余次修改，但没有任何书面记录；项目经理发现时，进度已滞后 6 周、预算超支 18%；测试团队手里有 5 个「不知道哪个是最新」的版本，两轮回归测试结论互相矛盾；客户高层在阶段会议上质问「当初签认的需求怎么变得面目全非」，拒绝为新增功能付费。
问题描述（提炼症状）：①需求变更口头传达、无申请单；②变更未经影响分析与审批即实施；③无变更台账，40 余次修改无据可查；④版本混乱，测试基线不明；⑤进度、成本失控且客户拒付。
问题诊断（分点，用本章框架归因）：
- 违反「变更必须走流程」原则：需求由口头传达、开发人员直接实施，属于典型的未走变更管理流程的私变（症状①②）；
- 违反「必须经 CCB 审批、未经批准不得实施」原则：无 CCB 介入，开发人员个人擅自实施了变更，项目经理也未履行组织影响分析的职责（症状②）；
- 变更日志缺失：没有变更台账，变更的状态与数量无从掌握，干系人对变更情况一无所知（症状③）；
- 配置管理形同虚设、三库不分：测试版本来源混乱说明版本未按「开发库 → 受控库 → 产品库」流转管理，测试未从受控库基线版本获取，回归测试自然结论矛盾（症状④）；
- 基线失效与范围蔓延：功能基线（需求规格）形同虚设，新增功能未纳入范围基准，导致客户拒付与成本失控（症状⑤）。
改进建议（分点）：
- 立即冻结当前版本：由配置管理员盘点全部版本，确定唯一有效版本入库受控库，测试一律以受控库基线版本为准；
- 组建 CCB（客户代表、实施方管理层、项目经理、技术专家、配置管理员），发布变更管理制度，明确分级审批权限；
- 全员公告：所有变更必须提交书面变更申请单，任何口头需求一律不受理、不实施；
- 对已发生的 40 余次变更补做影响梳理：区分已实施合理变更与擅自变更，评估对范围、进度、成本的影响，形成报告提交 CCB 与客户共同确认处置方案；
- 建立变更日志并由项目经理维护，随周报发布变更状态；
- 后续变更严格按「申请 → 影响分析 → CCB 审批 → 实施 → 监控 → 评估 → 更新基线关闭」七步执行，验证合格后更新受控库与基线。
命题落点：本题可拆出四类考法——①诊断类：指出变更管理方面存在的具体问题（对照三原则与七步流程找缺口）；②建议类：给出改进措施（组建 CCB、走流程、三库管理）；③配置类：判断测试版本应从哪个库获取；④责任类：变更影响分析由谁组织（项目经理）、变更由谁审批（CCB）。作答时先定性（违反什么原则），再定位（缺失哪个流程环节），最后给措施。
十、考点速记卡
| 考点 | 必背结论 | 记忆抓手 | 考法 |
|---|---|---|---|
| 配置管理目标 | 全面保存配置项历史记录与相互关系，追踪变更，使干系人随时了解最新配置信息 | 留痕、追变、透明 | 定义判断 |
| 配置项两分法 | 产品类（交付客户的）与开发过程类（造产品的中间产物） | 客户拿不拿走 | 分类判断 |
| 三类基线 | 功能基线=需求规格评审通过；分配基线=设计确定、需求分配到配置项；产品基线=通过系统测试验收 | 需—设—产 | 时机配对 |
| 三库定位 | 开发库（自由改，开发者管）；受控库（基线，改须 CCB 审批，配置管理员管）；产品库（发布版本，原则上不改） | 越近客户越严格 | 场景判定 |
| 三库流转 | 开发库 →（评审通过检入）→ 受控库 →（验收发布转入）→ 产品库 | 单向升级 | 排序题 |
| 配置管理四过程 | 配置项标识、配置控制、配置状态记录、配置审计 | 标控录审 | 列举/排序 |
| 两类配置审计 | 功能配置审计：实际功能性能 vs 需求；物理配置审计：实物 vs 配置文档清单 | 功能对需求、物理对实物 | 辨析题 |
| 变更三原则 | 必须走流程；必须经 CCB 审批；未经批准不得实施（紧急变更事后补办手续，不免审批） | 流程—审批—不擅动 | 正误判断 |
| 变更七步流程 | 提出申请 → 影响分析（项目经理组织）→ CCB 审批 → 实施 → 监控实施 → 评估效果 → 更新配置与基线/关闭 | 申析批施控评闭 | 流程排序 |
| CCB 定位 | 决策机构非执行机构；由主要干系人组成；批准或否决变更；项目经理不能代替 CCB 审批 | 只批不做 | 职责判断 |
| 变更请求 vs 变更日志 | 变更请求是申请单（流程输入）；变更日志是状态台账（项目经理维护） | 单 vs 账 | 概念辨析 |
| 与第 8 章关系 | 第 8 章=整合管理视角（整体变更控制过程）；第 19 章=组织级流程与配置支撑视角（制度、流程、三库），互补不重复 | 视角不同 | 关系说明 |
本章自测 共 15 题
建议闭卷限时 18 分钟完成，再逐题展开解析核对。错题请回到教材对应小节，并把错因写入错题本。
考查范围：配置管理目标、配置项分类、三类基线建立时机、三库定位与流转判定、配置管理四过程、功能与物理配置审计辨析、变更三原则、CCB 职责、变更七步流程排序、变更请求与变更日志辨析、本章与第 8 章的关系。
1.关于配置管理的目标与作用，下列说法最准确的是（ ）。（考点：配置管理目标）
查看答案与解析
【为什么选 B】配置管理的对象是配置项的版本与状态：完整留存历史版本与相互关系、使每项变更可追溯、让干系人随时掌握当前配置的真实状态——这正是配置管理区别于其他管理活动的独特定位。
【A 错在哪】A 「按期完成、控制成本」是进度管理与成本管理的目标，与配置管理无关，属于把管理领域目标张冠李戴。
【C 错在哪】C 审核技术内容正确性（如需求是否正确）是评审与质量管理的职责；配置管理管「版本与状态」，不判定内容对错。
【D 错在哪】D 协调沟通与解决冲突属于沟通管理、干系人管理范畴；配置管理客观上有利于协作，但那不是它的目标定义。
2.下列工作产品中，属于产品类配置项的是（ ）。（考点：配置项分类）
查看答案与解析
【为什么选 C】产品类配置项是最终交付给客户、构成产品实体的工作产品。可执行程序包随产品交付、是客户拿走的东西，属于典型产品类配置项。
【A 错在哪】A 需求规格说明书是开发过程中产生的过程文档（客户要的是按它做出来的产品，通常不把它本身当产品实体），属于开发过程类配置项。
【B 错在哪】B 设计说明书是开发过程的中间技术产物，归入开发过程类。
【D 错在哪】D 会议纪要是纯过程管理文档，客户不拿走、不构成产品，属于开发过程类（管理类）。
3.某信息系统项目在需求规格说明书正式评审通过并获客户签认后，建立了项目的第一条基线。该基线是（ ）。（考点：功能基线建立时机）
查看答案与解析
【为什么选 A】功能基线在需求规格说明书通过正式评审并获得批准时建立，冻结的是系统应具备的功能与性能需求——「需求定稿」正是功能基线的标志性事件。
【B 错在哪】B 分配基线在设计文档经评审批准、需求被分配到各配置项时建立，对应「设计定稿」，时机晚于功能基线。
【C 错在哪】C 产品基线在产品通过系统测试与验收时建立，对应「产品定稿」，是最后一条基线。
【D 错在哪】D 「进度基线」是项目管理计划中的范围/进度/成本基准语言，不属于配置管理中三类基线的分类体系，属于干扰名称。
4.某项目已完成系统测试并通过客户验收，准备对外发布。此时冻结「产品完整技术描述」、作为交付与运维依据的基线是（ ）。（考点：产品基线）
查看答案与解析
【为什么选 C】产品基线在产品通过系统测试与验收时建立，冻结产品的完整技术描述（最终版本、文档、介质），是交付客户和开展运维维护的依据。
【A 错在哪】A 功能基线冻结的是需求（做什么），早在需求评审时建立，与「通过验收、准备发布」的时机不符。
【B 错在哪】B 分配基线冻结的是分配后的设计规格（分给谁做），在设计确定时建立，同样与题干时机不符。
【D 错在哪】D 配置管理三类基线中不存在「质量基线」，属于编造的干扰名称。
5.某开发人员正在编写登录模块的新算法，代码尚未写完、频繁修改，别人也看不到。这部分代码当前应存放于（ ）。（考点：三库判定——开发库）
查看答案与解析
【为什么选 C】「尚未写完、频繁修改、外人看不到」完全符合开发库的特征：开发人员自由修改的工作区，存放正在进行开发的未定稿版本，由开发人员本人管理，无需审批。
【A 错在哪】A 产品库存放已交付或发布的最终版本，未完成的代码显然不属于。
【B 错在哪】B 受控库存放已评审通过、基线化的版本，修改须经 CCB 批准——与「频繁自由修改」矛盾。
【D 错在哪】D 「知识库」不是配置管理三库之一，属于干扰名称（知识管理另有所指）。
6.某版本已通过全部测试与客户验收，被批准作为正式发布版本。该版本应存放于（ ），其后续修改原则上需经更高级别的正式变更审批。（考点：三库判定——产品库）
查看答案与解析
【为什么选 C】通过测试与验收、批准正式发布的版本属于交付产品版本，存放于产品库；产品库是交付客户与对外发布的唯一来源，原则上不允许修改，确需修改（如打补丁）须经更高级别审批。
【A 错在哪】A 开发库存放未定稿的开发工作版本，发布版本放进去既不安全也不合规。
【B 错在哪】B 受控库存放基线化的配置项（基线、受控源码、测试版本），是产品库的上游；已验收发布的最终版本应从受控库提取后正式转入产品库。
【D 错在哪】D 「备份库」是产品库的别称（产品库也称备份库），与开发库并列表述混乱且前半错误；发布版本只能进产品库，不存在「均可」。
7.关于三类配置库的管理权限，下列说法正确的是（ ）。（考点：三库管理者与修改规则）
查看答案与解析
【为什么选 B】受控库的核心特征就是「受控」：基线化后的配置项不能随意修改，任何修改必须先提出变更申请、经审批（CCB）通过后才能实施——这正是变更管理与配置管理衔接的关键点。
【A 错在哪】A 开发库恰恰相反：开发人员可自由修改自己的工作版本，无需审批。
【C 错在哪】C 产品库的发布版本原则上不允许修改，更不可能由测试人员「按需自由修改」；确需修改须经更高级别正式审批。
【D 错在哪】D CCB 是变更决策机构，不负责库的日常管理；开发库由开发人员管理，受控库与产品库由配置管理员管理。
8.在配置管理过程中，「记录并报告配置项的版本变化、变更情况与当前状态，供干系人随时查询」所属的过程是（ ）。（考点：配置状态记录）
查看答案与解析
【为什么选 C】配置状态记录（状态报告）的职责就是记录并报告每个配置项「何时检入、何人修改、现在第几版、经历了什么变更」，让配置的历史与现状透明可查。
【A 错在哪】A 配置项标识解决「挂牌」问题——识别哪些物纳入管理、赋予唯一编号与属性，不涉及状态变化的持续记录。
【B 错在哪】B 配置控制解决「管住手」问题——通过变更审批与检入检出权限控制对基线的修改，不是记录报告。
【D 错在哪】D 配置审计解决「验真」问题——审查配置管理活动与配置项状态的完整一致性，是定期验证而非日常记录。
9.发布前，项目组核对交付包中的程序、介质与文档是否与配置清单所列内容完全一致、齐全无缺。这项工作属于（ ）。（考点：物理配置审计）
查看答案与解析
【为什么选 B】物理配置审计的检查对象是配置项的物理形态：核对交付实物（程序、介质、文档）与配置文档/清单描述是否一致、齐全——「交出来的东西和档案说的是不是一回事」。
【A 错在哪】A 功能配置审计检查的是功能与性能是否满足需求（做出来的东西是不是需求要的），需要运行验证与需求跟踪，与清点核对实物不同。
【C 错在哪】C 配置状态记录是持续记录版本与变更情况并出具报告，不是一次性的实物核对活动。
【D 错在哪】D 「质量控制审计」不是配置管理中的规范名称，属于编造干扰项。
10.关于功能配置审计与物理配置审计，下列说法正确的是（ ）。（考点：两类审计辨析）
查看答案与解析
【为什么选 C】功能配置审计对「需求」查「功能性能」——验证做出来的东西是不是需求要的；物理配置审计对「文档清单」查「实物」——验证交出来的东西和档案说的是不是一回事。二者对象与目的不同、互补使用。
【A 错在哪】A 「核对实物与清单」是物理配置审计的职责，选项把两个审计的职能说反了。
【B 错在哪】B 「验证功能性能满足需求」是功能配置审计的职责，同样说反了。
【D 错在哪】D 两种审计通常在交付前先后实施、互为补充（先确认功能满足需求，再确认实物与档案相符），「任选其一」「结论冲突」无依据。
11.某项目中，客户业务人员直接致电开发组长提出增加一个报表功能，开发组长评估「工作量不大」后当天安排人员完成了修改。关于此事，下列判断正确的是（ ）。（考点：变更管理三原则）
查看答案与 ans-body">
查看答案与解析
正确答案：C
【为什么选 C】变更管理三原则：必须走流程（书面申请）、必须经 CCB 审批、未经批准不得实施。本例口头提需求、组长个人评估、当天实施，三原则全部违反——「工作量小」不是绕过流程的理由。
【A 错在哪】A 用「效率」为违规开脱。变更代价不由表面工作量决定：未评估对范围、进度、成本、质量与基线的影响，小改动也可能引发连锁问题。
【B 错在哪】B 客户的变更权同样受流程约束——客户可以「提出」变更，但变更须经影响分析与 CCB（客户代表通常也是 CCB 成员）审批后才能实施，出资方身份不等于审批豁免。
【D 错在哪】D 正确做法是受理并走流程（申请 → 分析 → CCB 审批），而非一律驳回；「驳回所有变更」同样违背变更管理的本意——变更不是敌人，失控才是。
💡 命题人套路：场景题里凡是出现「口头提出、当场就改、顺手做了」的字眼，答案基本锁定「违反流程原则」；同时警惕矫枉过正的干扰项（一律驳回），流程的意义是受控不是拒绝。
【为什么选 C】变更管理三原则：必须走流程（书面申请）、必须经 CCB 审批、未经批准不得实施。本例口头提需求、组长个人评估、当天实施，三原则全部违反——「工作量小」不是绕过流程的理由。
【A 错在哪】A 用「效率」为违规开脱。变更代价不由表面工作量决定：未评估对范围、进度、成本、质量与基线的影响，小改动也可能引发连锁问题。
【B 错在哪】B 客户的变更权同样受流程约束——客户可以「提出」变更，但变更须经影响分析与 CCB（客户代表通常也是 CCB 成员）审批后才能实施，出资方身份不等于审批豁免。
【D 错在哪】D 正确做法是受理并走流程（申请 → 分析 → CCB 审批），而非一律驳回；「驳回所有变更」同样违背变更管理的本意——变更不是敌人，失控才是。
12.关于变更控制委员会（CCB），下列说法错误的是（ ）。（考点：CCB 组成与职责）
查看答案与解析
【为什么选 C】CCB 是决策机构而非执行机构：只受理、评估、批准或否决变更，不负责实施变更（实施由项目经理组织团队完成），也不负责受控库的版本更新操作（那是配置管理员的职责）。C 说法错误，故为本题答案。
【A 错在哪】A 「由主要干系人组成」是教材对 CCB 组成的标准表述，说法正确。
【B 错在哪】B 「决策机构 + 批准/否决/延期」是 CCB 的定位与核心职责，说法正确。
【D 错在哪】D CCB 决议须书面化并通报干系人（记入变更日志），说法正确。
13.变更管理流程的正确顺序是（ ）。（考点：变更流程排序）
查看答案与解析
【为什么选 A】七步标准顺序：申（提出申请）→ 析（项目经理组织影响分析）→ 批（CCB 审批）→ 施（按批准方案实施）→ 控（监控实施过程）→ 评（评估验证效果）→ 闭（更新配置与基线、关闭）。先有申请才有分析对象，先有审批才能动手，先有实施才有监控与评估对象，收口必须是基线更新与关闭。
【B 错在哪】B 把「实施」提到「CCB 审批」之前——这是最典型的「先做后批」违规错序；且「影响分析」不可能在实施与监控之后才做。
【C 错在哪】C 把「影响分析」放在「提出申请」之前——没有变更请求就没有分析对象；同时「实施」仍在「审批」之前，双重错序。
【D 错在哪】D 「CCB 审批」跑到最前（无申请无分析，批什么？），且「更新基线」插在「监控」之前——基线更新是验证合格后的收口动作，不能前置。
14.在变更管理流程中，负责组织变更影响分析的是（ ）；变更验证合格后，负责将变更结果检入受控库、更新基线的是（ ）。（考点：流程各步责任人）
查看答案与解析
【为什么选 A】影响分析由项目经理组织相关技术与管理人员完成（评估对范围、进度、成本、质量、风险的影响）；变更验证合格后，由配置管理员执行检入受控库、更新基线与版本号、关闭变更日志的操作。
【B 错在哪】B CCB 只做审批决策不做分析组织（分析结论是它的输入）；库操作也不是开发人员的活——开发人员只能操作自己的开发库工作区。
【C 错在哪】C 变更提出人只负责提交申请，无权组织分析；项目经理确认变更关闭，但检入受控库、更新基线的执行者是配置管理员。
【D 错在哪】D 配置管理员不做影响分析（那是项目经理的职责）；CCB 更不执行库操作——再次重申它是决策机构。
15.关于变更请求与变更日志以及本章与第 8 章的关系，下列说法正确的是（ ）。（考点：综合辨析）
查看答案与解析
【为什么选 B】前半句：变更请求（申请单）是流程输入，变更日志（台账）由项目经理维护、记录各项变更的处理状态，二者一「单」一「账」。后半句：第 8 章「实施整体变更控制」是整合管理视角下的过程，第 19 章是组织级流程制度与配置管理支撑视角，互补而非重复。
【A 错在哪】A 把两个概念的定义对调了——变更请求才是正式申请，变更日志才是状态台账。
【C 错在哪】C 二者功能完全不同：一个是审批对象、一个是流转记录，混用会导致「审批了台账、登记了申请单」的逻辑错误。
【D 错在哪】D 两章视角与颗粒度不同：过程输入输出类题目用第 8 章框架，流程步骤、三库与审计类题目用本章框架，「内容重复、任用一章」的说法错误。