15.2 配置管理

一句话讲明白

把项目里所有"会被改来改去的东西"（代码、文档、计划）编号入柜、谁改了什么留痕、旧版本永不丢失。

生活类比

图书馆借书：每本书一个索书号（配置项标识），书的状态分"在馆/借出/编目中"（配置项状态），每次改版就出新版本号，旧版照样留着不许扔（版本管理）。馆员负责上架登记（配置管理员 CMO），馆长决定哪些书进珍本库、能不能修订（配置控制委员会 CCB），定期盘点书架对不对得上账（配置审计）。

正经定义

配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。它是变更管理的基础与载体——变更最终都要落到配置项的检出、修改、检入和基线更新上。

拆解与流程

一、配置项（CI）与两类划分

配置项是为配置管理设计的硬件、软件或两者的集合，在配置管理过程中作为单个实体对待。典型配置项：项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行所需数据、设备型号及其关键部件等，经评审和检查通过后进入配置管理，统一编号并保存在 CMDB 中。

二、配置项三状态与版本号

小改动可做成附件（1.0、1.1…），附件积累到一定程度才增加 Y；升级幅度大才增加 X。

三、配置基线

基线由一组配置项组成，是产品或系统在某一特定时刻的配置状况。基线中的配置项被"冻结"，任何人不得随意修改，对基线的变更必须遵循正式变更控制程序。基线通常对应项目里程碑；交付用户的称发行基线 Release，内部使用的称构造基线 Build。每条基线要定义：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。

四、配置项版本管理

对配置项的任何修改都产生新版本，由于不能保证新版本一定比旧版本"好"，不能抛弃旧版本。目的是按规则保存所有版本，避免版本丢失或混淆，并能快速准确查找任一版本。

五、配置库三种（必考）

建库两种模式：按配置项类型建库（通用软件开发组织，产品继承性强，利于统一管理和提高编译发布效率）／按开发任务建库（专业软件开发组织，开发工具多、线性发展，更灵活）。

六、角色与职责（4 个）

七、六项管理活动

制订配置管理计划（CCB 审批）→ 配置项识别（7 步：识别受控项 → 指定唯一标识号 → 定义重要特征 → 确定所有者和责任 → 确定进入配置管理的时间条件 → 建立和控制基线 → 维护文档组件修订与产品版本关系）→ 配置项控制 → 配置状态报告 → 配置审计 → 配置管理回顾与改进。

配置项控制 7 步：变更申请 → 变更评估（CCB 评估影响、必要性、范围、方案可行性、工作量合理性）→ 通告评估结果 → 变更实施 → 变更验证与确认 → 变更发布 → 基于配置库的变更控制。

基于配置库的变更控制（经典考题）：基线 V2.1 从产品库复制到受控库 → 程序员 Check out 检出到自己的开发库（检出即"锁定"，同一时段只许一人改）→ 改完 Check in 检入受控库（解锁）→ 全部完成后新基线存入产品库（成为 V2.2，旧版本不删除）。这样解决了甲乙两人各改一处、互相覆盖的问题。

配置审计（应定期进行，实施新配置库后、重大变更前后、发布安装前、灾难恢复后、发现未授权配置项后）：

⚠️ 审计软件即使发现不一致，也不允许自动更新配置库，必须由有关负责人调查后再更新。

考试怎么考

• 题型：选择题高频；案例题常问"为什么会出现版本混乱/甲乙互相覆盖"。
• 必背：配置库三种及别名；配置项三状态与版本号 0.YZ / X.Y / X.YZ；基线配置项 vs 非基线配置项的权限；CMO 与 CCB 分工；功能审计 vs 物理审计。
• 常见问法：
• "需求规格说明书属于基线配置项还是非基线配置项？" → 基线（设计文档和源程序）。
• "项目进度计划、各类报告属于？" → 非基线配置项。
• "处于'修改'状态的版本号是？" → X.YZ。
• "开发人员可以直接改受控库里的代码吗？" → 不行，必须 Check out → 改 → Check in。
• 陷阱词：说"新版本一定比旧版本好，旧版本可删除"（错）；说"CCB 只管变更"（错，还管基线设立、配置管理计划审批）。

易混辨析

一秒记忆

"基线是设计文档和源代码，计划报告非基线；草稿 0.YZ、正式 X.Y、修改 X.YZ；三库开发-受控-产品，检出加锁检入解锁；CMO 干活、CCB 拍板、配置审计分功能和物理——功能看功效、物理看存在。"

相关

• 15.3 变更管理
• 15.1 信息和文档管理
• 13.12 实施整体变更控制
• 15-组织保障