（1）配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。
（2）配置管理包括 6 个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
GB/T11457-2006 对配置项的定义为∶"为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。
（3）典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。
配置项可以分为基线配置项和非基线配置项两类，
基线配置项可能包括所有的设计文档和源程序等；
非基线配置项可能包括项目的各类计划和报告等。
（4）所有配置项的操作权限应由 CMO 严格管理，基本原则是：
基线配置项向开发人员开放读取的权限；
非基线配置项向 PM、CCB 及相关人员开放。
（5）配置项的状态可分为“草稿”“正式”和“修改”三种。
配置项刚建立时，其状态为“草稿”。
配置项通过评审后，其状态变为“正式”。
此后若更改配置项，则其状态变为“修改”。
当配置项修改完毕并重新通过评审时，其状态又变为“正式”，如图 14-4 所示。

（6）配置项版本号。
1）处于“草稿”状态的配置项的版本号格式为 0.YZ，YZ 的数字范围为 01～99。随着草稿的修正，YZ 的取值应递增。YZ 的初值和增幅由用户自己把握。
2）处于“正式”状态的配置项的版本号格式为 X.Y，X 为主版本号，取值范围为 1～9。Y 为次版本号，取值范围为 0～9。
配置项第一次成为“正式”文件时，版本号为 1.0。
如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为 1.0,1.1,… 当附件的变动积累到一定程度时，配置项的 Y 值可适量增加，Y 值增加一定程度时，X 值将适量增加。当配置项升级幅度比较大时，才允许直接增大 X 值。
3）处于“修改”状态的配置项的版本号格式为 X.YZ。配置项正在修改时，一般只增大 Z 值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将 Z 值设置为 0，增加 X.Y 值，参见 2）。
（7）配置项版本管理：在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。
版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
（8）配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更 控制程序。
（9）一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。
（10）—个产品可以有多条基线，也可以只有一条基线。交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。
（11）配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。配置库可以分开发库、受控库、产品库三种类型。
1）开发库，也称为动态库、程序员库或工作库，
用于保存开发人员当前正在开发的配置实体，
如新模块、文档、数据元素或进行修改的已有元素。
动态中的配置项被置于版本管理之下。
动态库是开发人员的个人工作区，由开发人员自行控制。
库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其进行配置控制，因为这通常不会影响到项目的其他部分，可以任意修改。
2）受控库，也称为主库，
包含当前的基线加上对基线的变更。
受控库中的配置项被置于完全的配置管理之下。
在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
可以修改， 需要走变更流程。
3）产品库，也称为静态库、发行库、软件仓库，
包含已发布使用的各种基线的存档，被置于完全的配置管理之下。
在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
一般不再修改，真要修改的话需要走变更流程。
（12）配置库的建库模式有两种：按配置项类型建库和按任务建库。
配置库的主要作用
①记录与配置相关的所有信息，其中存放受控的软件配置项是很重要的内容。
②利用库中的信息可评价变更的后果，这对变更控制有着重要的意义。
③从库中可提取各种配置管理过程的管理信息。
利用配置库中的信息可回答许多配置管理的问题，例如∶
①哪些客户已提取了某个特定的系统版本?
②运行一个给定的系统版本需要什么硬件和系统软件?
③一个系统到目前已生成了多少个版本，何时生成的?
④如果某一特定的构件变更了，会影响到系统的哪些版本?
⑤一个特定的版本曾提出过哪几个变更请求?
⑥一个特定的版本有多少己报告的错误?
⑦使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
（13）配置库权限设置：配置管理员负责为每个项目成员分配对配置库的操作权限。
配置库的权限设置主要是解决∶
库内存放的配置项什么人可以"看"、什么人可以"取"、什么人可以"改"、什么人可以"销毁"等问题。配置管理员负责为每个项目成员分配对配置库的操作权限。
（14）配置控制委员会负责对配置变更做出评估、审查以及监督巳批准变更的实施。
CCB 的成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。
CCB 不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的 CCB。
对于小的项目，CCB 可以只有一个人，甚至只是兼职人员。通常，CCB 不只是控制配置变更，而是负有更多的配置管理任务，如配置管理计划审批、基线设立审批、产品发布审 批等。
（15）配置管理员负责在整个项目生命周期中进行配置管理活动，具体有如下内容：
