一、配置管理概述（掌握）
配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。
二、基本概念（掌握）
1. 配置项（Configuration Item, CI）
配置项的定义为："为配置管理设计的硬件、软件或两者的集合，它在配置管理过程中作为一单个实体来对待"。
典型的配置项包括：项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等，它们经评审和检查通过后进入配置管理。
配置项的分类：
| 类型 | 举例 | 权限管理 |
|---|---|---|
| 基线配置项 | 所有的设计文档和源程序等 | 向开发人员开放读取的权限 |
| 非基线配置项 | 项目的各类计划和报告等 | 向项目经理、CCB及相关人员开放 |
⚠️ 易错点 ：所有配置项的操作权限应由配置管理员严格管理。基线配置项只开放读取权限，非基线配置项开放给项目经理、CCB及相关人员。
2. 配置项状态
配置项的状态可分为三种：草稿 → 正式 → 修改。
| 状态 | 说明 |
|---|---|
| 草稿 | 配置项刚建立时的状态 |
| 正式 | 配置项通过评审后的状态 |
| 修改 | 更改配置项时的状态 |
状态转换图：
草稿 ──(通过评审)──→ 正式 ──(更改)──→ 修改 ──(修改完毕并重新通过评审)──→ 正式
配置项状态转换图
3. 配置项版本号
| 状态 | 版本号格式 | 示例 | 规则 |
|---|---|---|---|
| 草稿 | 0.YZ | 0.5、0.91 | YZ范围为01~99，随草稿修正递增 |
| 正式 | X.Y | 1.0、1.1、2.0 | X为主版本号1~9，Y为次版本号0~9。第一次成为正式时为1.0 |
| 修改 | X.YZ | 1.13 | 修改时只增大Z值，X.Y不变；修改完毕重新成为正式时，Z置0，增加X.Y值 |
📌 记忆口诀：草稿0点几，正式1点0，修改加小数
4. 配置项版本管理
在信息系统项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本"好"，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
5. 配置基线
配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被"冻结"了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
基线的例子：产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等）。
基线的类型：
| 类型 | 说明 |
|---|---|
| 发行基线 | 交付给外部顾客的基线 |
| 构造基线 | 内部开发使用的基线 |
基线的定义内容：对于每一个基线，要定义：
- 建立基线的事件
- 受控的配置项
- 建立和变更基线的程序
- 批准变更基线所需的权限
⚠️ 易错点：一个产品可以有多个基线，也可以只有一个基线。基线通常对应于开发过程中的里程碑。
6. 配置管理数据库
配置管理数据库主要内容包括：
| 序号 | 内容 |
|---|---|
| ① | 发布内容，包括每个配置项及其版本号 |
| ② | 经批准的变更可能影响到的配置项 |
| ③ | 与某个配置项有关的所有变更请求 |
| ④ | 配置项变更轨迹 |
| ⑤ | 特定的设备和软件 |
| ⑥ | 计划升级、替换或弃用的配置项 |
| ⑦ | 与配置项有关的变更和问题 |
| ⑧ | 来自于特定时期特定供应商的配置项 |
| ⑨ | 受问题影响的所有配置项 |
7. 配置库
配置库可以分为三种类型：
| 类型 | 别名 | 说明 | 控制程度 |
|---|---|---|---|
| 开发库 | 动态库、程序员库、工作库 | 保存开发人员当前正在开发的配置实体。开发人员的个人工作区，由开发人员自行控制 | 无需配置控制（可以任意修改） |
| 受控库 | 主库 | 包含当前的基线以及对基线的变更。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库 | 完全配置管理（可以修改，需要走变更流程） |
| 产品库 | 静态库、发行库、软件仓库 | 包含已发布使用的各种基线的存档。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装 | 完全配置管理（一般不再修改，真要修改需走变更流程） |
📌 记忆口诀：开可乱改，受控走流程，产品不动
三类配置库关系图
8. 配置库的建库模式
| 模式 | 适用场景 | 特点 |
|---|---|---|
| 按配置项类型建库 | 通用软件的开发组织（产品继承性强、工具统一、有并行开发需求） | 有利于统一管理和控制，提高编译和发布效率；但可能造成开发人员工作目录结构过于复杂 |
| 按开发任务建库 | 专业软件的开发组织（开发工具种类繁多、开发模式以线性发展为主） | 不用严格分类存储，比较灵活 |
📌 记忆口诀：通用按类型，定制按任务
三、本章真题小测
Q1：配置项第一次成为"正式"文件时，版本号为（）。
A. 0.1 B. 1.0 C. 1.1 D. 0.01
Q2：关于配置库的描述，不正确的是（）。
A. 开发库中的配置项可以被开发人员任意修改
B. 受控库中的配置项被置于完全的配置管理之下
C. 产品库中的配置项一旦入库就不能再修改
D. 开发库也称为动态库、程序员库或工作库
📩 答案：
Q1 答案：B解析：
草稿版本：
0.x，例如 0.1；首次正式发布版本号为 1.0；
小幅度修订后版本升级为 1.1、1.2。
Q2 答案：C解析：
A✅ 开发库（动态库 / 程序员库 / 工作库），开发人员可以随意修改；
B✅ 受控库，纳入完整配置管理，变更要走变更流程；
C❌ 产品库不是绝对不能修改，如果有变更需求，走完完整变更流程后依旧可以修改，不是入库就永久不可改动；
D✅ 开发库别名：动态库、程序员库、工作库。
✅汇总答案
Q1：B；Q2：C