概念卡 / 配置管理
配置管理
一句话讲明白
把项目里所有"会被改来改去的东西"（代码、文档、计划）编号入柜、谁改了什么留痕、旧版本永不丢失——它是变更管理的基础与载体。
生活类比
图书馆借书：每本书一个索书号（配置项标识）；书分"在馆/借出/编目中"三种状态（配置项三状态）；每次改版就出新版本号，旧版照样留着不许扔（版本管理）。
馆员负责上架登记 = 配置管理员 CMO；馆长决定哪些书进珍本库、能不能修订 = CCB；定期盘点书架对不对得上账 = 配置审计。
正经定义
配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。
拆解
一、配置项分类（权限年年考）
| 分类 | 包含什么 | 操作权限 |
|---|---|---|
| 基线配置项 | 所有设计文档和源程序：需求规格说明书、设计文档、源代码、可执行代码、数据库脚本 | 向开发人员开放读取 |
| 非基线配置项 | 项目的各类计划和报告：项目进度计划、周报、沟通管理计划等 | 向项目经理、CCB 及相关人员开放 |
二、配置项三状态与版本号
stateDiagram-v2
[*] --> 草稿
草稿 --> 正式: 通过评审
正式 --> 修改: 变更控制
修改 --> 正式: 修改完毕重新通过评审
| 状态 | 版本号 | 规则 |
|---|---|---|
| 草稿 | 0.YZ | YZ 取 01～99，随草稿修正递增 |
| 正式 | X.Y | X 主版本号 1～9，Y 次版本号 0～9；首次成为正式文件为 1.0 |
| 修改 | X.YZ | 只增大 Z，X.Y 不变；改完转正式时 Z 置 0 并增加 X.Y |
三、配置基线
基线是产品或系统在某一特定时刻的配置状况，其中的配置项被"冻结"，对基线的变更必须遵循正式变更控制程序。基线通常对应项目里程碑；交付用户的称发行基线 Release，内部使用的称构造基线 Build。
四、三种配置库（必考）
| 库 | 别名 | 放什么 | 谁控制 |
|---|---|---|---|
| 开发库 | 动态库、程序员库、工作库 | 开发人员正在开发的实体 | 开发人员自行控制，修改频繁，一般无须配置控制 |
| 受控库 | 主库 | 当前基线 + 对基线的变更 | 处于完全的配置管理之下 |
| 产品库 | 静态库、发行库、软件仓库 | 已发布使用的各种基线的存档 | 处于完全的配置管理之下 |
经典考题 · 基于配置库的变更控制（解决甲乙互相覆盖）：
flowchart LR
A[产品库<br/>复制基线 V2.1] --> B[受控库] --> C[开发人员 Check out<br/>检出到开发库 · 锁定]
C --> D[修改] --> E[Check in 检入受控库 · 解锁]
E --> F[形成新基线 V2.2 存入产品库<br/>旧版本不删除]
检出即加锁：同一时段只允许一人修改；任何修改都产生新版本，旧版本绝不删除（不能保证新版本一定"更好"）。
五、配置审计（功能 + 物理）
| 功能配置审计 | 物理配置审计 | |
|---|---|---|
| 审什么 | 一致性：实际功效是否与需求一致 | 完整性：物理存在是否与预期一致 |
| 验证内容 | 开发已圆满完成；达到规定的性能和功能特征；操作和支持文档已完成并符合要求 | 要交付的配置项是否存在；是否包含所有必需的项目 |
审计发现不一致不允许自动更新配置库，须由负责人调查后再更新。触发时机：实施新配置库后、重大变更前后、发布安装前、灾难恢复后、发现未授权配置项后。
六、角色与职责
| 角色 | 关键词 |
|---|---|
| CCB | 也叫变更控制委员会；审批配置管理计划、审批基线设立与产品版本、审查/评价/批准/推迟/否决变更申请、监督已批准变更的实施 |
| 配置管理负责人（配置经理） | 管理全生命周期配置活动；审批配置库结构性变更；定义配置项责任人；指派配置审计员 |
| 配置管理员 CMO | 主要实施者：建库、配置项识别、建立管理基线、版本管理与配置控制、配置状态报告、配置审计、发布管理与交付 |
| 配置项负责人 | 确保所负责配置项准确真实；记录所有变更；维护配置项间关系；调查审计差异并出具差异报告 |
七、六项管理活动
制订配置管理计划 → 配置项识别 → 配置项控制 → 配置状态报告 → 配置审计 → 配置管理回顾与改进。
考试怎么考
- 题型：选择题高频；案例常问"为什么会出现版本混乱 / 甲乙各改一处互相覆盖"。
- 常见问法：
- "需求规格说明书属于哪类配置项？" → 基线配置项；"项目周报、进度计划呢？" → 非基线。
- "处于'修改'状态的版本号格式？" → X.YZ。
- "开发人员能直接改受控库的代码吗？" → 不行，必须 Check out → 改 → Check in。
- 陷阱词：说"新版本一定比旧版本好，旧版可删"（错）；说"CCB 只管变更"（错，还管基线设立、配置管理计划审批）；把"开发库"说成也受完全配置管理（错）。
易混辨析
| 配置管理 | 变更管理 | |
|---|---|---|
| 关注 | 产品与过程文档的状态与版本 | 对基准的识别、记录、批准或否决 |
| 载体 | 配置库（开发/受控/产品） | 变更请求单与变更日志 |
| 主责 | CMO（干活的） | CCB（拍板的） |
一秒记忆
"基线是设计文档和源代码，计划报告非基线；草稿 0.YZ、正式 X.Y、修改 X.YZ；三库开发-受控-产品，检出加锁、检入解锁；CMO 干活、CCB 拍板；功能看功效、物理看存在。"