一、配置管理常见问题（高频考点）
| 问题类别 | 具体表现 |
|---|---|
| 计划与意识缺失 | • 未制定配置管理计划 • 项目经理缺乏配置管理意识与经验 • 未编写可行的配置管理方案 |
| 核心活动缺位 | • 未识别配置项 • 未建立基线 • 未进行配置控制、状态报告、审计、发布管理 |
| 变更管理混乱 | • 变更未经分析、批准 • 未记录变更请求与实施过程 • 未通知相关干系人变更结果 • CCB组成不合理 • 未评估变更影响，也未告知提出方 |
| 版本与库管理失控 | • 无统一版本机制，版本不可追溯 • 开发库/产品库内容不完整、文档更新滞后 • 直接在受控库开放修改权限 • 多人同时修改同一配置项（如甲乙同改） • 删除配置项（严禁操作） |
| 工具与流程缺陷 | • 未有效评估配置管理工具 • 无规范变更流程或未执行流程 • 变更后未验证、未更新项目计划 • 发布由开发人员而非CMO执行 |
⚠️后果：版本混乱、交付错误、返工、客户投诉、项目失控。
二、配置管理六大核心活动（中级/高级高频考点）
🔄 配置管理是闭环过程，包含以下6项活动：
| 活动 | 说明 |
|---|---|
| 1. 制订配置管理计划 | 明确策略、角色、工具、流程、基线策略等 |
| 2. 配置项识别 | 确定哪些文档、代码、数据等需纳入管理 |
| 3. 配置项控制 | 通过变更控制流程管理配置项修改 |
| 4. 配置状态报告 | 定期报告配置项状态、变更历史、基线信息 |
| 5. 配置审计 | 验证配置项一致性（功能）与完整性（物理） |
| 6. 配置管理回顾与改进 | 定期评估并优化配置管理过程 |
✅口诀：计划 → 识别 → 控制 → 报告 → 审计 → 改进
三、配置项与基线管理
1. 典型配置项
- 项目计划书
- 需求文档、设计文档
- 源代码、可执行代码
- 测试用例
- 运行所需数据
- 设备型号及关键部件
📌 所有配置项需经评审通过后方可纳入配置管理。
2. 配置项状态（三态循环）
| 状态 | 说明 |
|---|---|
| 草稿（Draft） | 初始创建，未评审 |
| 正式发布（Released） | 通过评审，纳入基线 |
| 正在修改（Changing） | 已启动变更流程，处于修改中 |
🔁状态流转：草稿 →（评审通过）→ 正式发布 →（发起变更）→ 正在修改 →（重新评审）→ 正式发布
3. 基线 vs 非基线配置项
| 类型 | 示例 | 管理要求 |
|---|---|---|
| 基线配置项 | 需求规格、设计文档、源程序 | 严格受控，变更需走流程 |
| 非基线配置项 | 项目计划、周报、会议纪要 | 相对灵活，但仍需版本管理 |
四、配置库管理
1. 三大配置库（高级12年下、17年上考点）
| 库名 | 别名 | 用途 | 修改权限 | 特点 |
|---|---|---|---|---|
| 开发库 | 动态库、工作库 | 开发人员个人工作区 | 开发者自由修改 | 高频变动，不受控 |
| 受控库 | 主库 | 存放当前基线及变更 | 需走变更流程 | 完全受控，阶段性成果 |
| 产品库 | 静态库、发行库 | 存放已发布最终产品 | 极严格，仅CMO可操作 | 不再修改，用于交付 |
✅口诀：开发库（动态）→ 受控库（主库）→ 产品库（静态）
2. 建库模式
| 模式 | 适用场景 | 优点 |
|---|---|---|
| 按配置项类型建库 | 通用软件开发（如ERP、办公软件） | 统一管理，提升编译/发布效率 |
| 按任务建库 | 专业/定制软件开发（如军工、科研） | 灵活适应多工具、线性开发 |
五、变更与版本控制流程（高级21年下考点）
🔄 软件升级时的标准配置库操作流程：
- 从产品库取出基线→ 放入受控库
- 程序员Checkout代码→ 锁定该段代码（防止多人同时修改）
- 在开发库修改后Checkin→ 解除锁定，其他人才可修改
- 全部修改完成→ 将新基线存入产品库
💡关键机制：Checkout = 锁定，Checkin = 解锁
六、配置审计（中级16年下考点）
目的：确保配置管理有效性，防止混乱
| 审计目标 | 具体内容 |
|---|---|
| 防止交付错误产品 | 如用户手册版本与软件不匹配 |
| 发现不完善实现 | 如未按需求或变更请求开发 |
| 找出不匹配/不兼容 | 如接口与设计文档不符 |
| 确认入库合规 | 基线是否经质量审核后入库 |
| 保证可追溯性 | 文档与代码是否关联清晰 |
✅口诀：防错、发现、找出、确认、追溯
两种配置审计类型
| 类型 | 关注点 | 验证内容 |
|---|---|---|
| 功能配置审计 | 一致性（功效 vs 需求） | • 开发完成 • 功能性能达标 • 文档齐全合规 |
| 物理配置审计 | 完整性（存在 vs 预期） | • 交付物齐全 • 无遗漏组件 |
七、配置管理角色与职责
| 角色 | 职责 |
|---|---|
| 配置管理负责人（配置经理） | • 统筹配置管理全过程 • 审批结构性变更 • 定义配置项、属性、关系 • 组织审计与培训 • 持续改进流程 |
| 配置管理员（CMO） | • 建立维护配置库与工具 • 识别配置项、建立基线 • 执行版本控制、状态报告、审计 •负责发布与交付（非开发人员！） |
| 配置项负责人 | • 维护所负责配置项的准确性 • 记录变更、维护关系 • 配合审计，解决差异 |
⚠️注意：
- CCB不制定配置管理计划（应由配置经理牵头）
- 发布必须由CMO执行
八、配置管理改进与版本发布
1. 配置管理回顾活动
- 准备会议（定主题、通知人员）
- 召开回顾会议
- 制定服务改进计划
- 落实改进措施
2. 版本发布前准备（含回退机制）
- 回退影响分析
- 备份：存储过程、配置数据、应用版本
- 明确回退触发条件
- 明确回退责任人与通知机制
3. 版本回退步骤
- 通知用户与关联系统
- 回退数据对象（存储过程等）
- 回退配置数据
- 回退应用程序、接口、工作流
- 通知周边系统回退完成
- 回退后测试验证
- 通知用户系统恢复
✅核心原则：任何发布必须可回退！
九、配置管理数据库（CMDB）主要内容
| 内容 | 说明 |
|---|---|
| ① 发布内容及版本号 | 当前部署的配置项清单 |
| ② 变更影响的配置项 | 一次变更波及哪些组件 |
| ③ 变更请求记录 | 所有CR（Change Request）历史 |
| ④ 配置项变更轨迹 | 全生命周期变更日志 |
| ⑤ 特定设备与软件 | 硬件/软件资产信息 |
| ⑥ 计划升级/弃用项 | 未来变更计划 |
| ⑦ 变更与问题关联 | 问题是否由某配置项引发 |
| ⑧ 供应商来源信息 | 如“Oracle 19c from 官方渠道” |
| ⑨ 受问题影响的配置项 | 故障影响范围分析 |
十、文档分类（补充）
| 类型 | 示例 |
|---|---|
| 开发文档 | 需求、设计、测试用例 |
| 产品文档 | 用户手册、安装指南 |
| 管理文档 | 项目计划、周报、会议纪要 |
✅总结建议：
- 配置管理 =版本可控 + 变更有痕 + 基线清晰 + 审计到位
- 基线是里程碑，变更需流程，发布靠CMO，回退必可行
- 配置库三分法（开发/受控/产品）是基础架构
- 配置审计是质量“守门员”，防止“张冠李戴”
✅一句话口诀：
计划先行识配置，基线受控变有迹，
审计发布双把关，回退可行保交付
