1. 配置管理

1.1. 应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性

1.1.1. GB/T 11457《信息技术软件工程术语》

2. 配置项

2.1. Configuration Item, CI

2.2. 为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待

2.2.1. GB/T 11457《信息技术软件工程术语》

2.3. 所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在CMDB配置管理数据库中

2.4. 基线配置项

2.4.1. 所有的设计文档和源程序

2.5. 非基线配置项

2.5.1. 项目的各类计划和报告

2.6. 基本原则

2.6.1. 所有配置项的操作权限应由配置管理员严格管理

2.6.2. 基线配置项向开发人员开放读取的权限

2.6.3. 非基线配置项向项目经理、CCB及相关人员开放

3. 配置项状态

3.1. 草稿

3.1.1. 版本号格式为0.YZ

3.1.2. YZ是数字，取值范围为01〜99

3.2. 正式

3.2.1. 版本号格式为X.Y

3.2.2. X为主版本号，取值范围为1〜9

3.3. 修改

3.3.1. 版本号格式为X.YZ

3.3.2. 一般只增大Z值，X.Y值保持不变

3.3.3. 成为“正式”时，将Z值设置为0,增加X.Y值

4. 配置项版本管理

4.1. 对配置项的任何修改都将产生新的版本

4.2. 不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本

4.3. 按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本

5. 配置基线

5.1. 一个产品或系统在某一特定时刻的配置状况

5.2. 基线本身保持不变

5.2.1. 可以作为初始状态的一个参考或当前状态的一个对照

5.2.2. 基线中的配置项被“冻结” 了，不能再被任何人随意修改

5.3. 对基线的变更必须遵循正式的变更控制程序

5.4. 对应于项目过程中的里程碑(Milestone)

5.4.1. —个项目可以有多个基线

5.4.2. 交付给用户使用的基线一般称为发行基线(Release)

5.4.3. 内部过程使用的基线一般称为构造基线(Build)

5.5. 建立基线的价值

5.5.1. 为项目工作提供了一个定点和快照

5.5.2. 新项目可以在基线提供的定点上建立

5.5.2.1. 与随后对原始项目(在主要分支上)所进行的变更进行隔离

5.5.3. 为团队提供一种取消变更的方法

5.5.4. 重新建立基于某个特定发布版本的配置，以重现已报告的错误

6. 配置管理数据库

6.1. 包含每个配置项及配置项之间重要关系的详细资料的数据库

6.2. 主要内容

6.2.1. 发布内容，包括每个配置项及其版本号

6.2.2. 经批准的变更可能影响到的配置项

6.2.3. 与某个配置项有关的所有变更请求

6.2.4. 配置项变更轨迹

6.2.5. 特定的设备和软件

6.2.6. 计划升级、替换或弃用的配置项

6.2.7. 与配置项有关的变更和问题

6.2.8. 来自于特定时期特定供应商的配置项

6.2.9. 受问题影响的所有配置项

7. 配置库

7.1. Configuration Library

7.2. 配置库权限设置

7.3. 开发库

7.3.1. 动态库、程序员库或工作库

7.3.2. 保存开发人员当前正在开发的配置实体

7.3.3. 开发库中的信息可能被频繁修改，因此可以由开发人员自行控制

7.3.3.1. 【高20下选51】

7.4. 受控库

7.4.1. 主库

7.4.2. 包含当前的基线以及对基线的变更

7.4.3. 完全的配置管理之下

7.4.4. 权限设置

7.4.4.1. 【高22下选49】

7.4.4.1.1. 【高21下选51】

7.4.4.1.2. 【高19下选51】

7.5. 产品库

7.5.1. 静态库、发行库、软件仓库

7.5.2. 包含己发布使用的各种基线的存档

7.5.3. 完全的配置管理之下

7.5.4. 权限设置

7.6. 建库模式

7.6.1. 按配置项类型建库

7.6.1.1. 通用软件的开发组织

7.6.2. 按开发任务建库

7.6.2.1. 专业软件的开发组织

8. 变更控制委员会

8.1. Change Control Board, CCB

8.2. CCB 可以是兼职人员

8.2.1. 【高19上选52】

8.2.1.1. 【高18下选11】

9. 配置经理

9.1. 配置管理负责人

9.2. 负责管理和决策整个项目生命周期中的配置活动

9.2.1. 管理所有活动

9.2.2. 负责配置管理过程

9.2.3. 通过审计过程确保配置管理数据库的准确和真实

9.2.4. 审批配置库或配置管理数据库的结构性变更

9.2.5. 定义配置项责任人

9.2.6. 指派配置审计员

9.2.7. 定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态

9.2.8. 评估配置管理过程并持续改进

9.2.9. 参与变更管理过程评估

9.2.10. ⑩对项目成员进行配置管理培训

10. 配置管理员

10.1. Configuration Management Officer,CMO

10.2. 建立和维护配置管理系统

10.3. 建立和维护配置库或配置管理数据库

10.4. 配置项识别

10.5. 建立和管理基线

10.6. 版本管理和配置控制

10.7. 配置状态报告

10.8. 配置审计

10.9. 发布管理和交付

10.10. 【高20下选52】

10.10.1. 【高18下选52】

10.10.2. 注意：3版10项，4版8项，多了配置经理

11. 配置项负责人

11.1. 确保所负责的配置项的准确和真实

11.2. 记录所负责配置项的所有变更

11.3. 维护配置项之间的关系

11.4. 调查审计中发现的配置项差异，完成差异报告

11.5. 遵从配置管理过程

11.6. 参与配置管理过程评估

12. 配置管理目标

12.1. 所有配置项能够被识别和记录

12.2. 维护配置项记录的完整性

12.3. 为其他管理过程提供有关配置项的准确信息

12.4. 核实有关信息系统的配置记录的正确性并纠正发现的错误

12.5. 配置项当前和历史状态得到汇报

12.6. 确保信息系统的配置项的有效控制和管理

13. 配置管理关键成功因素

13.1. 所有配置项应该记录

13.2. 配置项应该分类

13.3. 所有配置项要编号

13.4. 应该定期对配置库或配置管理数据库中的配置项信息进行审计

13.5. 每个配置项在建立后，应有配置负责人负责

13.6. 要关注配置项的变化情况

13.7. 应该定期对配置管理进行回顾

13.8. 能够与项目的其他管理活动进行关联

14. 配置管理活动

14.1. 制订配置管理计划

14.1.1. 配置管理的目标和范围

14.1.2. 活动主要包括配置项标识、配置项控制、配置状态报告、配置审计、发布管理与交付等

14.1.3. 配置管理角色和责任安排

14.1.4. 实施这些活动的规范和流程

14.1.5. 实施这些活动的进度安排

14.1.6. 与其他管理之间(如变更管理等)的接口控制

14.1.7. 负责实施这些活动的人员或团队，以及他们和其他团队之间的关系

14.1.8. 配置管理信息系统的规划

14.1.8.1. 配置数据的存放地点

14.1.8.2. 配置项运行的受控环境

14.1.8.3. 与其他服务管理系统的联系和接口

14.1.8.4. 构建和安装支持工具

14.1.9. 配置管理的日常事务

14.1.10. 计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划

14.2. 配置项识别

14.2.1. 配置标识Configuration Identification

14.2.2. 识别所有信息系统组件的关键配置

14.2.3. 各配置项间的关系和配置文档等结构识别

14.2.4. 确定配置项范围

14.2.5. 确认和记录配置项属性

14.2.6. 为配置项定义标识符

14.2.6.1. 每个配置项一个唯一的标识符

14.2.7. 确定配置基准线

14.2.7.1. 过去的、当前的和计划中的发布信息

14.2.7.2. 过去的、当前的和计划中的变更信息

14.2.7.3. 批准和实施变更时信息系统的状态和有关文档

14.2.7.4. 实施发布时信息系统的状态和有关文档

14.2.7.5. 按标准规范配置的硬件和软件

14.2.8. 确定配置结构

14.2.8.1. 说明了配置项的层次结构和各配置项之间的关系

14.2.8.2. 一个配置可以同时是许多不同配置项(一个配置项集)的一部分

14.2.9. 确定配置项命名规则

14.2.9.1. 配置结构内各配置项间的层级关系

14.2.9.2. 每个配置及其相关文档间的关系

14.2.9.3. 各配置项及其相关文档间的关系

14.2.9.4. 文档与变更间的关系

14.2.10. 确定配置项的所有者及其责任，确定配置项进入配置管理的时间和条件是配置标识的工作

14.2.10.1. 【高19上选51】

14.3. 配置项控制

14.3.1. 变更申请

14.3.1.1. 提交给CCB

14.3.2. 变更评估

14.3.2.1. CCB负责组织对变更申请进行评估并确定

14.3.2.1.1. 变更对项目的影响

14.3.2.1.2. 变更的内容是否必要

14.3.2.1.3. 变更的范围是否考虑周全

14.3.2.1.4. 变更的实施方案是否可行

14.3.2.1.5. 变更工作量估计是否合理

14.3.2.2. CCB决定是否接受变更，并将决定通知相关人员

14.3.3. 通告评估结果

14.3.3.1. 通知受此处置意见影响的每个干系人

14.3.4. 变更实施

14.3.4.1. 项目经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息

14.3.5. 变更验证与确认

14.3.5.1. 项目经理应将变更与验证的结果提交给CCB,由其确认变更是否己经按要求完成

14.3.6. 变更的发布

14.3.6.1. 配置管理员将变更后的配置项纳入基线

14.3.6.2. 配置管理员将变更内容和结果通知相关人员，并做好记录

14.3.7. 基于配置库的变更控制

14.3.7.1. 【高22下选51】

14.3.7.1.1. 【高21上选51】

14.3.7.1.2. 【高18上选51】

14.4. 配置状态报告

14.4.1. 配置状态统计

14.4.2. 在某个特定的时刻观察当时的配置状态

14.4.3. 对动态演化着的配置项取个瞬时的“照片”

14.4.4. 每个受控配置项的标识和状态

14.4.5. 每个变更申请的状态和己批准的修改的实施状态

14.4.6. 每个基线的当前和过去版本的状态以及各版本的比较

14.4.7. 其他配置管理过程活动的记录

14.5. 配置审计

14.5.1. 配置审核

14.5.2. 配置评价

14.5.3. 不允许出现任何混乱现象

14.5.3.1. 防止向用户提交不适合的产品

14.5.3.2. 发现不完善的实现

14.5.3.3. 找出各配置项间不匹配或不相容的现象

14.5.3.4. 确认配置项己在所要求的质量控制审核之后纳入基线并入库保存

14.5.3.5. 确认记录和文档保持着可追溯性

14.5.4. 审计软件即使发现不一致的情况，也不允许自动更新配置库或配置管理数据库，必须由有关负责人调查后再进行更新

14.5.5. 功能配置审计

14.5.5.1. Functional Configuration Audit

14.5.5.2. 审计配置项的一致性(配置项的实际功效是否与其需求一致)

14.5.5.2.1. 【高19上选12】

14.5.5.3. 配置项的开发已圆满完成

14.5.5.4. 配置项已达到配置标识中规定的性能和功能特征

14.5.5.5. 配置项的操作和支持文档已完成并且是符合要求的

14.5.5.6. 【高23上选59】

14.5.6. 物理配置审计

14.5.6.1. Physical Configuration Audit

14.5.6.2. 审计配置项的完整性(配置项的物理存在是否与预期一致)

14.5.6.3. 要交付的配置项是否存在

14.5.6.3.1. 【高22下选50】

14.5.6.4. 配置项中是否包含了所有必需的项目

14.6. 配置管理回顾与改进

14.6.1. 定期回顾配置管理活动的实施情况

14.6.2. 对本次配置管理回顾进行准备

14.6.3. 召开配置管理回顾会议

14.6.4. 根据会议结论，制订并提交服务改进计划

14.6.5. 根据过程改进计划，协调、落实改进等

15. 【高22下案三】

15.1. 【高21下案三】

15.2. 【高20下案三】