1. 为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科

2. 配置项

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

3. 基线配置项

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

4. 非基线配置项

4.1. 非基线配置项向PM、CCB及相关人员开放

5. 配置项状态

5.1. 草稿

5.1.1. 配置项刚建立时

5.2. 正式

5.2.1. 配置项通过评审后

5.2.2. 当配置项修改完毕并重新通过评审时

5.3. 修改

5.3.1. 此后若更改配置项

6. 配置项版本号

6.1. 草稿

6.1.1. 格式为O.YZ,

6.1.1.1. 【22上选60】

6.1.2. YZ的数字范围为01〜99

6.2. 正式

6.2.1. 格式为X.Y

6.2.2. X为主版本号

6.2.2.1. 【21上选60】

6.2.2.2. 取值范围为1〜9

6.2.3. Y为次版本号

6.2.3.1. 取值范围为0〜9

6.3. 修改

6.3.1. 【20下选60】

6.3.1.1. 【19下选60】

6.3.2. 格式为X.YZ

7. 版本管理

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

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

8. 配置基线（Configuration Baseline）

8.1. 对应于开发过程中的里程碑（Milestone）

8.2. 常简称为基线

8.3. 由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体

8.4. 发行基线（Release Baseline）

8.5. 构造基线（Build Baseline）

8.6. 好处

8.6.1. 为开发工作提供了一个定点和快照

8.6.2. 新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离

8.6.3. 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法

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

9. 配置库（Configuration Library）

9.1. 开发库(Development Library)

9.1.1. 【22下选60】

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

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

9.1.3.1. 【19上选62】

9.2. 受控库(Controlled Library）

9.2.1. 主库

9.2.2. 包含当前的基线加上对基线的变更

9.3. 产品库(Product Library

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

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

9.3.3. 拉出一个SS分支修复严重问题并发布最终软件，关键词是“发布最终软件”，说明软件最终是在SS分支上发布的，更匹配产品库的概念

9.3.3.1. 【22下选59】

9.4. 建库模式

9.4.1. 按配置项类型建库

9.4.1.1. 适用于通用软件的开发组织

9.4.2. 按任务建库

9.4.2.1. 适用于专业软件的开发组织

9.5.

9.5.1. 【21下选60】

9.6. 将副本存储在不同的受控场所,以减少丢失的风险

9.6.1. 【21上选61】

10. 权限设置

10.1. r

10.2. c

10.3. a

10.4. d

11. 配置控制委员会(Configuration Control Board, CCB）

11.1. 负责对配置变更做出评估、审批以及监督已批准变更的实施

11.2. 项目级

11.3. 不必是常设机构

12. 配置管理员(Configuration Management Officer, CMO）

12.1. 编写配置管理计划

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

12.3. 建立和维护配置库

12.4. 配置项识别

12.5. 建立和管理基线

12.6. 版本管理和配置控制

12.7. 配置状态报告

12.8. 配置审计

12.9. 发布管理和交付

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

13. 配置管理系统

13.1. 用来进行配置管理的软件系统

14. 6个主要活动

14.1. 制定配置管理计划

14.2. 配置标识(Configuration Identification)

14.2.1. 配置识别

14.3. 配置控制

14.3.1. 配置项和基线的变更控制

14.3.2. 变更申请

14.3.2.1. 要做什么变更，为什么要做，以及打算怎么做变更

14.3.3. 变更评估

14.3.3.1. CCB负责组织对变更申请进行评估

14.3.4. 通告评估结果

14.3.4.1. CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人

14.3.5. 变更实施

14.3.6. 变更验证与确认

14.3.6.1. 项目经理指定人员对变更后的配置项进行测试或验证

14.3.7. 变更的发布

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

14.4. 配置状态报告(Configuration Status Reporting)

14.4.1. 配置状态统计(Configuration Status Accounting）

14.4.2. 其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作

14.5. 配置审计(Configuration Audit)

14.5.1. 配置审核或配置评价

14.5.2. 为了确保项目配置管理的有效性，体现了配置管理的最根本要求——不允许出现任何混乱现象

14.5.2.1. 【21下选61】

14.5.3. 功能配置审计（Functional Configuration Audit）

14.5.3.1. 【22上选61】

14.5.3.2. 审计配置项的一致性（配置项的实际功效是否与其需求一致）

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

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

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

14.5.4. 物理配置审计（Physical Configuration Audit）

14.5.4.1. 审计配置项的完整性（配置项的物理存在是否与预期一致）

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

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

14.6. 发布管理和交付

14.6.1. 【20下选61】

14.6.1.1. 【19下选61】

14.6.2. 存储

14.6.3. 复制

14.6.4. 打包

14.6.5. 交付

14.6.6. 重建

热门相关：斗神战帝   苏醒的秘密   大神你人设崩了   薄先生，情不由己   霸皇纪