本章概要
配置管理是通过技术或者行政的手段对项目管理对象和信息系统的信息进行管理的一系列活动。这些信息不仅包括具体配置项信息，还包括这些配置项之间的相互关系。配置管理包含配置库的建立和配置管理数据库（Configuration Management Databases,CMDB）准确性的维护,以支持信息系统项目的正常运行。在信息系统项目中，配置管理可用于问题分析、变更影响度分析和异常分析等，因此，配置项与真实情况的匹配度和详细度非常重要。
在组织实施信息系统项目过程中，常常会遇到变更的发生。变更的诱发一般有主动变更和被动变更两种。主动变更是主动发起的变更，常用于提高项目收益，包括降低成本、改进过程以及提高项目的便捷性和有效性等；被动变更常用于范围变化、异常、错误和适应不断变化的环境等，如随需求的增加，相应需要增加系统的功能或投资等。变更管理是对变更从提出、审议、批准到实施、完成的整个过程的管理。
配置管理
配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。在（GB/T11457）《信息技术软件工程术语》中，将“配置管理”正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性”。在（GB/T28827.1）《信息技术服务运行维护第 1 部分：通用要求》中指出：组织应建立配置管理过程，整体规划配置管理范围，保留配置信息，并保证配置信息的可靠性、完整性和时效性，以对其他服务过程提供支持；应建立与配置管理过程相一致的活动，包括对配置项的识别、收集、记录、更新和审核等。尽管硬件配置管理和软件配置管理的实现有所不同，但配置管理的概念可以应用于各种信息系统项目。
管理基础
配置项（Configuration Item,CI）
GB/T 11457《信息技术软件工程术语》对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待”。配置项是信息系统组件或与其有关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等。这些组件或项目已经或将要受到配置管理的控制。
比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等，它们经评审和检查通过后进入配置管理。所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在 CMDB 中。例如，在信息系统的开发项目中需加以控制的配置项可以分为基线配置项和非基线配置项两类，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由配置管理员严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向项目经理、CCB 及相关人员开放。
配置项状态
配置项的状态需要根据配置项的不同类型和管理需求进行分别定义，基于配置项建设过程角度，可将配置项状态分为“草稿”“正式”和“修改”三种。
配置项状态变化图
配置项版本号
配置项的版本号规则与配置项的状态定义相关。例如：
- 处于“草稿”状态的配置项的版本号格式为 0.YZ，YZ 是数字，取值范围为 01~99。随着草稿的修正，YZ 的取值应递增。
- 处于“正式”状态的配置项的版本号格式为 X.Y，X 为主版本号，取值范围为 1~9；Y 为次版本号，取值范围为 0 ～ 9。配置项第一次成为“正式”文件时，版本号为 1.0。
- 处于“修改”状态的配置项的版本号格式为 X.YZ。配置项正在修改时，一般只增大 Z 值，X.Y 值保持不变。当配置项修改完毕，状态成为“正式”时，将 Z 值设置为 0，增加 X.Y 值。
配置项版本管理
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。例如，在信息系统开发项目过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
配置基线
配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。配置基线也是指一个产品或系统在某一特定时刻的配置状况。这种配置不仅体现了其产品或系统的结构，还反映了其具体内容，从而使得以后可以按照上述配置重建该产品或系统。尽管被作为基准线的这个配置状态以后可能发生改变，但这个基线本身保持不变。这个基线可以作为初始状态的一个参考或当前状态的一个对照。配置基线可用于管理对象中的授权产品、标准配置项、开发和测试新配置的起点、作为提供给 IT 系统用户的配置的标准（如标准工作站）、作为提供新软件的起点等。
基线通常对应于项目过程中的里程碑（Milestone），一个项目可以有多个基线，也可以只有一个基线。交付给用户使用的基线一般称为发行基线（Release），内部过程使用的基线一般称为构造基线（Build）。
对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。
建立基线的价值可包括：
- 基线为项目工作提供了一个定点和快照。
- 新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
- 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
- 可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。
配置管理数据库
我们常使用配置管理数据库来管理配置项，它是指包含每个配置项及配置项之间重要关系的详细资料的数据库。对于信息系统开发项目来说，常使用配置库实施配置数据的管理。配置管理数据库主要内容包括：
- 发布内容，包括每个配置项及其版本号；
- 经批准的变更可能影响到的配置项；
- 与某个配置项有关的所有变更请求；
- 配置项变更轨迹；
- 特定的设备和软件；
- 计划升级、替换或弃用的配置项；
- 与配置项有关的变更和问题；
- 来自于特定时期特定供应商的配置项；
- 受问题影响的所有配置项。
配置库
针对信息系统开发类型的项目，我们常使用配置库（Configuration Library）存放配置项并记录与配置项相关的所有信息，它是配置管理的有力工具。
配置库可以分开发库、受控库、产品库 3 种类型。
- 开发库。开发库也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如新模块、文档、数据元素或进行修改的已有元素。
- 受控库。受控库也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
- 产品库。产品库也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
配置库的建库模式有两种：按配置项类型建库和按开发任务建库。
- 按配置项的类型分类建库。这种模式适用于通用软件的开发组织。
- 按开发任务建立相应的配置库。这种模式适用于专业软件的开发组织。
角色与职责
配置管理相关角色常包括：变更控制委员会（Change Control Board，CCB）、配置管理负责人、配置管理员和配置项负责人等。
- 配置管理负责人：也称配置经理，负责管理和决策整个项目生命周期中的配置活动。
- 配置管理员：负责在整个项目生命周期中进行配置管理的主要实施活动。
- 配置项负责人：确保所负责的配置项的准确和真实。
目标与方针
- 管理目标：在信息系统项目中，配置管理的目标主要用以定义并控制信息系统的组件，维护准确的配置信息。
- 管理方针：为了实现配置管理目标，组织应定义配置管理过程，制定配置管理相关制度。
管理活动
配置管理的日常管理活动主要包括：制订配置管理计划、配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾与改进等。
配置与变更管理思维导图
网友评论