第19章 配置与变更管理

配置管理是通过技术或者行政的手段对项目管理对象和信息系统的信息进行管理的 一系列 活动。这些信息不仅包括具体配置项信息，还包括这些配置项之间的相互关系。配置管理包含 配置库的建立和配置管理数据库 （Configuration Management Databases, CMDB )准确性的维护，以支持信息系统项目的正常运行。在信息系统项目中，配置管理可用于问题分析、变更影响度 分析和异常分析等，因此，配置项与真实情况的匹配度和详细度非常重要。

在组织实施信息系统项目过程中，常常会遇到变更的发生。变更的诱发一般有主动变更和 被动变更两种。主动变更是主动发起的变更，常用于提高项目收益，包括降低成本、改进过程 以及提高项目的便捷性和有效性等:被动变更常用于范围变化、异常、错误和适应不断变化的 环境等，如随需求的增加，相应需要增加系统的功能或投资等。变更管理是对变更从提出、审 议、批准到实施、完成的整个过程的管理。

19.1 配置管理

配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。

在 (GB/T 11457) 《信息技术 软件工程术语》中，将“配置管理”正式定义为:“应用技术的和管理的指导和监控方法以标识 和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验 证与规定的需求的遵循性”。

在( GB/T 28827.1 )《信息技术服务运行维护第 l 部分:通用要求 》 中指出:组织应建立配置管理过程，整体规划配置管理范围，保留配置信息，并保证配置信息 的可靠性、 完整性和 时效性，以对其他服务过程提供支持;应建立与配置管理过程相 一致的活 动，包括对配置项的识别、收集、记录、更新和审核等。尽管硬件配置管理和软件配置管理的 实现有所不同，但配置管理的概念可以应用于各种信息系统项目。

19.1.1 管理基础

1、配置项( Configuration Item, CI )

GB/T 11457 《信息技术软件工程术语》对配置项的定义为:“为配置管理设计的硬件、软件 或二者的集合，在配置管理过程中作为一个单个实体来对待”。配置项是信息系统组件或与其有 关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、 台式机、移动设备、应用系统、协议、电信服务等。这些组件或项目已经或将要受到配置管理 的控制。

比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可 执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等，它们经评审和检查通过后进入配置管理。 所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在 CMDB 中 。

在信息系统的开发项目中需加以控制的配置项可以分为两类:

• 基线配置项: 可能包括所有的设计文档和源程序等;
• 非基线配置项: 可能包括项目的各类计划和报告等 。

所有配置项的操作权限应由配置管理员严格管理，基本原则是:

• 基线配置: 项向开发人员开放读取的权限:
• 非基线配置项: 向项目经理、 CCB 及相关人员开放。

2、配置项状态

配置项的状态需要根据配置项的不同类型和管理需求进行分别定义，基于配置项建设过程 角度，可将配置项状态分为“草稿”“正式”和“修改” 三种 。

• 配置项刚建立时，其状态为“草稿” 。
• 配置项通过评审后，其状态变为“正式” 。
• 此后若更改配置项，则其状态变为“修改” 。
• 当配置项修改完毕并重新通过评审时，其状态又变为“正式”。

配置项状态变化如图 19-1 所示。

3、配置项版本号

配置项的版本号规则与配置项的状态定义相关 。 例如:

(1) 处于“草稿”状态的配置项的版 本号格式为 O.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 。

4、配置项版本管理

配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发 布和交付等 。 例如，在信息系统开发项目过程中，绝大部分的配置项都要经过多次的修改才能 最终确定下来 。 对配置项的任何修改都将产生新的版本 。 由于我们不能保证新版本一定比旧版 本“好”，所以不能抛弃旧版本。 版本管理的目的是按照一定的规则保存配置项的所有版本，避 免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本 。

5、配置基线

配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。配置基线也是指 一个产品或系统在某一特定时刻的配置状况。这种配置不仅体现了其产品或系统的结构，还反 映了其具体内容，从而使得以后可以按照上述配置重建该产品或系统 。 尽管被作为基准线的这 个配置状态以后可能发生改变，但这个基线本身保持不变 。这个基线可 以作为初始状态的 一个 参考或当前状态的一个对照。配置基线可用于管理对象中的授权产品、标准配置项、开发和测 试新配置的起点、作为提供给 IT 系统用户的配置的标准(如标准工作站)、作为提供新软件的 起点等 。

在信息系统项目过程中，各类配置项存在不断变化的情况，为了在不严重阻碍合理变化的 情况下来控制变化，需要使用配置基线这一概念。基线中的配置项被“冻结”了，不能再被任 何人随意修改。 对基线的变更必须遵循正式的变更控制程序。例如， 一组拥有唯一标识号的需 求、设计、源代码文档以及相应的可执行代码、构造文档和用户文档构成一条基线。产品的一 个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、己编译的可执行 代码、测试大纲、测试用例和使用手册等)也是基线的例子 。

基线通常对应于项目过程中的里程碑（Milestone)， 一个项目可以有多个基线，也可以只有 一个基线 。

• 交付给用户使用的基线 一般称为发行基线( Release)，
• 内部过程使用的基线一般称 为构造基线（Build)。

对于每 一个基线，要定义下列内容:

• 建立基线的事件
• 受控的配置项
• 建立和变更基线的程序
• 批准变更基线所需的权限

在项目实施过程中，每个基线都要纳入配置控制，对这些基 线的更新只能采用正式的变更控制程序。

建立基线的价值可包括:

(1)基线为项目工作提供了 一个定点和快照。

(2)新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目(在主要分支上)所进行的变更进行隔离 。

(3)当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法 。 (4)可以利用基线重新建立基于某个特定发布版本的配置，以重现己报告的错误 。

6、配置管理数据库

我们常使用配置管理数据库来管理配置项，它是指包含每个配置项及配置项之间重要关系 的详细资料的数据库。对于信息系统开发项目来说，常使用配置库实施配置数据的管理 。

配置管理数据库主要内容包括 :

1. 发布内容，包括每个配置项及其版本号:
2. 经批准的变更可能影响到的配置项:
3. 与某个配置项有关的所有变更请求;
4. 配置项变更轨迹:
5. 特定的设备和软件 ;
6. 计划升级、 替换或 弃用的配置项:
7. 与配置项有关的变更和问题:
8. 来自于特定时期特定供应商的配置项;
9. 受问 题影响的所有配置项。

配置管理数据库管理所有配置项及其关系，以及与这些配置项有关的事件、问题、己知错 误、变更和发布及相关的员工、供应商和业务部门信息;保存多种服务的详细信息及这些服务与 IT 组件之间的关系;保存配置项的财务信息，如供应商、购买费用和购买日期等 。

7、配置库

针对信息系统开发类型的项目，我们常使用配置库(Configuration Library)存放配置项并记录与配置项相关的所有信息，它是配置管理的有力工具 。

利用配置库中的信息可回答许多配 置管理的问题:

1. 哪些用户己提取了某个特定的系统版本:
2. 运行一个给定的系统版本需要什么硬件和系统软件:
3. 一个系统到目前己生成了多少个版本，何时生成的:
4. 如果某一特定的 构件变更了，会影响到系统的哪些版本:
5. 一个特定的版本曾提出过哪几个变更请求:
6. 一个特定的版本有多少己报告的错误 。

使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段 产品和最终产 品管理得井井有条，使其不致管乱、管混、管丢 。

配置库可以分开发库、受控库、 产品库 3 种类型:

(1) 开发库 。 开发库也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发 的配置实体，如新模块、文档、数据元素或进行修改的己有元素 。 动态中的配置项被置于版本 管理之下 。 动态库是开发人员的个人工作区，由开发人员自行控制 。 库中的信息可能有较为频 繁的修改，只要开发库的使用者认为有必要，无须对其进行配置控制，因为这通常不会影响到 项目的其他部分 。

(2)受控库 。 受控库也称为主库，包含 当前的基线以及对基线的变更 。 受控库中的配置项被置 于完全的配置管理之下 。 在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库 。

(3)产品库 。 产品库也称为静态库、发行库、软件仓库，包含己发布使用的各种基线的存 档，被置于完全的配置管理之下 。 在开发的信息系统产品完成系统测试之后，作为最终产品存 入产品库内，等待交付用户或现场安装 。

配置库的建库模式有两种: 按配置项类型建库和按开发任务建库 。

(1)按配置项的类型分类建库 。 这种模式适用于通用软件的开发组织 。 在这样的组织内， 往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。 使用这样的库结构有利于 对配置项的统一管理和控制，同时也能提高编译和发布的效率。 但由于这样的库结构并不是面 向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些 不必要的麻烦 。

(2)按开发任务建立相应的配置库 。 这种模式适用于专业软件的开发组织 。 在这样的组织 内，使用的开发工具种类繁多，开发模式以线性发展为主，所以没必要把配置项严格分类存储， 人为增加目录的复杂性 。 对于研发性的软件组织来说，采用这种设置策略比较灵活 。

19.1.2 角色与职责

配置管理相关角色常包括:

• 变更控制委员会(Change Control Board, CCB)
• 配置管理负责人
• 配置管理员
• 配置项负责人

1、配置管理负责人

配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动，具体有:

1. 管理所有活动，包括计划、识别、控制、审计和回顾:
2. 负责配置管理过程;
3. 通过审计过 程确保配置管理数据库的准确和真实:
4. 审批配置库或配置管理数据库的结构性变更:
5. 定义 配置项责任人:
6. 指派配置审计员:
7. 定义配置管理数据库范围、配置项属性、配置项之间关 系和配置项状态 :
8. 评估配置管理过程并持续改进 ;
9. 参与变更管理过程评估:
10. 对项目成员 进行配置管理培训。

2、配置管理员

配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动，具体有:

1. 建立和维护配置管理系统:
2. 建立和维护配置库或配置管理数据库:
3. 配置项识别:
4. 建立和管理基线:
5. 版本管理和配置控制:
6. 配置状态报告 :
7. 配置审计:
8. 发布管理和交付。

3、配置项负责人

配置项负责人确保所负责的配置项的准确和真实 :

1. 记录所负责配置项的所有变更:
2. 维护配置项之间的关系:
3. 调查审计中发现的配置项差异，完成差异报告:
4. 遵从配置管理过程:
5. 参与配置管理过程评估。

19.1.3 目标与方针

1、管理目标

在信息系统项目中，配置管理的目标主要用以定义并控制信息系统的组件，维护准确的配 置信息，具体包括:

1. 所有配置项能够被识别和记录:
2. 维护配置项记录的完整性:
3. 为其他 管理过程提供有关配置项的准确信息:
4. 核实有关信息系统的配置记录的正确性并纠正发现的 错误:
5. 配置项当前和历史状态得到汇报 :
6. 确保信息系统的配置项的有效控制和管理。

为了实现上述目标需要建立一个完整的配置项管理过程，通过该管理过程实现对所有配置 项的有效管理，以保证所有配置项及时正确地识别、记录和查询，配置元素当前和历史状态得 到汇报，以及配置元素记录的完整性。

针对信息系统开发项目，常需要通过实施软件配置管理达到配置管理的目标，即在整个软 件生命周期中建立和维护项目产品的完整性。

组织需要实现的配置管理目标主要包括:

1. 确保软件配置管理计划得以制订，并经过相关人员的评审和确认;
2. 应该识别出要控制的项日产品有哪些，并且制定相关控制策略，以确保这些项目产品被合适的人员获取:
3. 应制定控制策略， 以确保项目产品在受控制范围内更改:
4. 应该采取适当的工具和方法，确保相关组别和个人能 够及时了解到软件基线的状态和内容。

2、管理方针

为了实现配置管理目标，组织应定义配置管理过程，制定配置管理相关制度。管理层和具 体项目负责人应该明确相关人员在项目中所担负的配置管理方面的角色和责任，并使他们得到 适合的培训。项目组成员应严格按照配置管理过程文件规定的要求执行，履行配置管理的相关 职责。配置管理工作应该享有资金和管理决策支持等。配置管理的系统性应在整个项目生命周 期中得到控制。配置管理应基于项目类型和交付物等定义覆盖全面的管理范围，如信息系统开发项目中对外交付的软件产品，以及那些被选定的在项目中使用的支持类工具等 。 组织应定期 开展配置审计活动 。

配置管理关键成功因素主要包括 :

1. 所有配置项应该记录:
2. 配置项应该 分类:
3. 所有配置项要编号:
4. 应该定期对配置库或配置管理数据库中的配置项信息进行审计:
5. 每个配置项在建立后，应有配置负责人负责;
6. 要关注配置项的变化情况:
7. 应该定期对配 置管理进行回顾:
8. 能够与项目的其他管理活动进行关联。

19.1.4 管理活动

配置管理的日常管理活动主要包括(背诵):

• 制订配置管理计划
• 配置项识别
• 配置项控制
• 配置状态报告
• 配置审计
• 配置管理回顾与改进

1、制订配置管理计划

配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文 件并在整个项目生命周期内处于受控状态 。 CCB 负责审批该计划。

配置管理计划的主要内容为:

• 配置管理的目标和范围。
• 配置管理活动主要包括配置项标识、配置项控制、配置状态报告、配置审计、发布管理与交付等 。
• 配置管理角色和责任安排 。
• 实施这些活动的规范和流程，如配置项命名规则 。
• 实施这些活动的进度安排，如日程安排和程序 。
• 与其他管理之间(如变更管理等)的接口控制 。
• 负责实施这些活动的人员或团队，以及他们和其他团队之间的关系 。
• 配置管理信息系统的规划，包括配置数据的存放地点、配置项运行的受控环境、与其他服务管理系统的联系和接口、构建和安装支持工具等 。
• 配置管理的日常事务，包括许可证控制、配置项的存档等 。
• 计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划 。

2、配置项识别

配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结 构识别 。 它包括为配置项分配标识和版本号等 。 配置项识别是配置管理的 一项基础性工作，要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等 。

(1)确定配置项范围 。 识别配置项范围、配置项级别与细节，预先决定哪些资产和活动将 受配置管理控制，定义要使用什么级别的控制，哪些配置需要进一步分为多个组件，生成子配 置项等 。 其他与配置项有关的记录和信息也需要保存 。 这些信息包括配置项的版本信息、变更 历史、存储位置及相互间关系 等信息 。

(2)确认和记录配置项属性。为了便于对配置项进行管理，配置管理需要预先确认和记录 各配置项，特别是高风险或关键配置工页的属性 。 配置项属性 一般包括配置项的名称、编号、类 别、版本号、责任人、来源、提供日期、许可证号、目前状态、计划状态、父配置项关联、 子 配置项关联、事件号、问题号、变更请求号、变更号、备注等内容 。

(3)为配置项定义标识符。为便于识别，配置管理应该赋予每个配置项 一个唯一 的标识符 并维护这些标识的准确性 。 硬件配置项可以通过在硬件配置项上贴上或刻上物理标记或通过条 形码来定义配置项的标识符:软件配置项可以在将其软件存入配置库时，制作 一个包含配置项 名称和版本号的标签:文档配置项可以通过在文档命名中加入有效日期和更新日期加以标识 。

(4)确定配置基准线 。 配置基准线是对某个特定时点上 一 组配置项的描述 。一 项完整的配 置基准线应该包括的内容主要有:1过去的、当前的和计划中的发布信息:2过去的、当前的 和计划中的变更信息:3批准和实施变更时信息系统的状态和有关文档;4实施发布时信息系 统的状态和有关文档:5按标准规范配置的硬件和软件。

(5)确定配置结构 。 为了完整地识别和记录各配置项之间的关系，需要确定信息系统的配 置结构 。 配置结构说明了配置工页的层次结构和各配置项之间的关系 。 这里的结构可以是信息系 统的配置结构，也可以是项目配置结构。与配置结构有关的 一个关键问题是配置项的选择 。 配 置项可以是 一个独立的硬件单元或软件模块，也可以是由多个不同的配置项组合成的一个较大 的配置项。 一个配置可以同时是许多不同配置项( 一个配置项集)的一部分 。 组织应根据项目 管理的需求来选择配置工页的级别 。 将所需的最低配置项级别预先决定好，即使你不会 立 即将配 置管理精细化程度置于那个级别，这也是 一件值得花时间去做的事，并且要尽可能为未来着想 。

(6)确定配置项命名规则 。 命名规则可应用于配置项标识、配置文档、变更和基准线等 。 合理的命名规则有助于管理配置结构中各配置项的层次关系、每个配置项的层次或从属关系、 配置项与其相关的文档之间的关系、文档与变更之间的关系、事件和变更之间的关系 。 配置管 理应该建立所有的配置项和控制形式(如变更请求)的命名规则 。 命名规则的制订应尽量考虑 配置项名称的延续性、易记性和可扩展性 。

每个配置项可以通过自身的字符、拷贝号/序列号和版本号等标识唯 一识别(有关拷贝号 / 序列号和版本号等详细信息应记录在配置库或配置管理数据库中，但不一定作为标识的一部分) 。 版本号识别出哪些变化的版本属于同 一配置项 。 同一配置项的不同版本可以在同一时刻共存 。 在 制定命名规则时应充分考虑未来可能的版本增长。标识应相对较短，但有其具体含义，并尽可 能使用现有规则，版本记录、变更记录以及其他与信息系统有关的配置项都需要标识 。

配置项命名规则应能体现:

1. 配置结构内各配置项间的层级关系:
2. 每个配置及其相关文档间的关系;
3. 各配置项及其相关文档间的关系:
4. 文档与变更间的关系等 。

3、配置项控制（背诵）

配置项控制即对配置项和基线的变更控制，包括: 标识和记录变更申请、分析和评价变更、 批准或否决申请、实现、验证和发布己修改的配置项等任务 。

(1)变更申请 。

变更申请主要就是陈述要做什么变更，为什么要变更，以及打算怎样变更 。相关人员(如项目经理)填写变更申请表，说明要变更的内容、变更原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，提交给 CCB。

(2)变更评估 。

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

1. 变更对项目的影响
2. 变更的内容是否必要
3. 变更的范围是否考虑周全
4. 变更的实施方案是否可行
5. 变更工作量估计是否合理

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

(3)通告评估结果 。

CCB 把关于每个变更申请的批准、否决或推迟的决定通知受此处置意 见影响的每个干系人 。 如果变更申请得到批准，应该及时把变更批准信息和变更实施方案通知 给那些正在使用受影响的配置项和基线的干系人。 如果变更申请被否决，应通知有关干系人放 弃该变更申请 。

(4)变更实施 。

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

(5)变更验证与确认 。

项目经理指定人员对变更后的配置项进行测试或验证 。 项目经理应 将变更与验证的结果提交给 CCB，由其确认变更是否已经按要求完成 。

(6)变更的发布 。

配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果 通知相关人员，并做好记录 。

(7)基于配置库的变更控制。

在信息系统开发项目中，一处出现了变更，经常会连锁引起 多处变更，会涉及到参与开发工作的许多人员 。 例如，测试引发了需求的修改，那么很可能要 涉及到需求规格说明、概要设计、详细设计和代码等相关文档，甚至会使测试计划随之变更 。

如果是多个开发人员对信息系统的同 一部件进行修改，情况会更加复杂 。 例如，在软件测 试时发现了两个故障 。 项目经理最初以为两故障是无关联的，就分别指定甲和乙去解决这两个 故障 。 但碰巧，引起这两个故障的错误代码都在同 一个软件部件中 。 甲和乙各自对故障定位后， 先后从库中取出该部件，各自做了修改，又先后将部件送回库中。结果，甲放入库中的部件版 本只有甲的修改，乙放入库中的部件版本只有乙的修改，没有 一个版本同时解决了两个故障。

基于配置库的变更控制可以完美地解决上述问题，如图 19-2所示。

现以某软件产品升级为例，其过程简述为:

(1)将待升级的基线(假设版本号为 V2.1 )从产品库中取出，放入受控库 。

(2)程序员将欲修改的代码段从受控库中检出( Check out)，放入自己的开发库中进行修 改。 代码被检出后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其 修改，乙就无法 Check out。

(3)程序员将开发库中修改好的代码段检入( Check in)受控库 。检入后 ，代码的“锁定” 被解除，其他程序员可以 Check out 该段代码了 。

(4)软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品 的版本号更新为 V2.2，旧的 V2.1 版并不删除，继续在 产 品库中保存) 。

4、配置状态报告

配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目 的是及时、准确地给出配置工页的当前状况，供相关人员了解，以加强配置管理工作 。在信息系 统项目中，配置项在不停地演化着。配置状态报告就是要在某个特定的时刻观察当时的配置状 态，也就是要对动态演化着的配置项取个瞬时的“照片”，以利于在状态报告信息分析的基础 上，更好地进行控制。

配置状态报告应该主要包含:

(1)每个受控配置项的标识和状态 。 一旦配置项被置于配置控制下，就应该记录和保存它 的每个后继进展的版本和状态。

(2)每个变更申请的状态和己批准的修改的实施状态。

(3)每个基线的当前和过去版本的状态以及各版本的比较。

(4)其他配置管理过程活动的记录等。

5、配置审计

配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当 前配置项的 一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置 管理的最根本要求，不允许出现任何混乱现象:

1. 防止向用户提交不适合的产品，如交付了用 户手册的不正确版本:
2. 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实 施变更:
3. 找出各配置项间不匹配或不相容的现象:
4. 确认配置项己在所要求的质量控制审核 之后纳入基线并入库保存;
5. 确认记录和文档保持着可追溯性等 。

(1) 功能配置审计 。

功能配置审 计是审计配置项的一致性(配置项的实际功效是否与其需求一致)，具体验证主要包括:

1. 配置项的开发己圆满完成:
2. 配置项己达到配置标识中规定的性能和功能特征:
3. 配置项的操作和支持文档己完成并且是符合要求的等 。

(2)物理配置审计。

物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致)，具体验证主要包括:

1. 要交付的配置项是否存在:
2. 配置项中是否包含了所有必需的项目等。

一般来说，配置审验应当定期进行，应当进行配置审计的场景包括:

1. 实施新的配置库或 配置管理数据库之后;
2. 对信息系统实施重大变更前后;
3. 在 一项软件发布和安装被导入实际 运作环境之前;
4. 灾难恢复之后或事件恢复正常之后:
5. 发现未经授权的配置项后:
6. 任何其 他必要的时候等 。

部分常规配置审计工作可由审计软件完成，如比较两台计算机的配置情况，分析工作站并 报告它当前的状况 。 但要注意的是，审计软件即使发现不 一致的情况，也不允许自动更新配置 库或配置管理数据库，必须由有关负责人调查后再进行更新。

6、配置管理回顾与改进

配置管理回顾与改进即定期回顾配置管理活动的实施情况，发现在配置管理执行过程中有 无问题，找到改进点，继而优化配置管理过程。

配置管理回顾及改进活动包括:

1. 对本次配置 管理回顾进行准备，设定日期和主题 ，通知相 关人等参加会议。根据配置管理绩效衡量指标 ， 要求配置项责任人提供配置项统计信息 :
2. 召开配置管理回顾会议 ，在设定日期召开回顾会议， 对配置管理报告进行汇报，昕取各方意见，回顾上次过程改进计划执行情况;
3. 根据会议结论 ， 制订并提交服务改进计划;
4. 根据过程改进计划，协调、落实改进等。

19.2 变更管理

变更管理的大致作用与基本操作原则己在整体管理、范围管理等相关章节中介绍 ，但由于 变更管理方法在项目管理中的重要性不断增加，且在实际应用中的影响越来越大，故特设立本节 单独论述。变更在信息系统项目过程中经常发生，许多项目失败是对变更处理不当造成的。有些 变更是积极的，有些则是消极的，做好变更管理可以使项目的质量、进度和成本管理更有效。

19.2.1 管理基础

项目变更管理是指在信息系统项目的实施过程中，由于项目环境或者其他的原因而对项目 的功能、性能、架构、技术指标、集成方法、项目进度等方面做出的改变。变更管理的实质是 根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地 满足项目需求，提升项目价值。

1、变更管理与配置管理

如果把项目整体的交付物视作项目的配置项，配置管理可视为对项目完整性管理的 一套系 统，当用于项目基准调整时，变更管理可视为其一部分。 亦可视变更管理与配置管理为相关联 的两套机制，变更管理由项目交付或基准配置调整时，由配置管理过程调用，变更管理最终应 将对项目的调整结果反馈给配置管理过程，以确保项目执行与项目配置信息相 一致。

2、 变更产生的原因

由于项目逐渐完善的基本特性，意味着早期的共识随着项目进行，对项目不断深入地理解， 作业过程与预先的发生变化是必然的 。 如果持续按照项目早期的定义开展，很难会保质保量地 交付 ，因而变更控制必不可少 。 变化可能是对交付物的需求发生的变化，也可能是项目范围或 是项目的资源、进度等执行过程发生的变化。

变更的常见原因包括（背诵）:

1. 产品范围(成果)定义 的过失或者疏忽:
2. 项目范围(工作)定义的过失或者疏忽:
3. 增值变更;
4. 应对风险的紧急 计划或回避计划:
5. 项目执行过程与基准要求不 一致带来的被动调整:
6. 外部事件等。

3、变更的分类

变更的分类方式有很多，需要根据具体项目的类型和组织对项目管理的模式与方法等确定， 如弱电工程、应用开发、集成、 IT 咨询、 IT 运维、信息系统开发等。项目业务形态各异，组织管理成熟度亦有差距，每种业务内容的变更分类方法尚无法统一，组织可在各项目中细化分类， 并对不同内容的变更区别情况提出不同控制方法，通过不同变更处理流程进行管理 。 通常来说，

根据变更性质可分（通过不同审批权限进行控制）：

• 重大变更
• 重要变更
• 一般变更

根据变更的迫切性可分为：

• 紧急变更
• 非紧急变更

根据行业特点分类，如弱电工程行业的常见分类方法 为产品(工作)范围变更、环境变更、设计变更、实施变更和技术标准变更。

4、项目变更的含义

项目管理方法的基本原理，即将特定的目标通过规范的计划过程，转化为基准共识之后以 指导项目执行，同时作为项目有效监控、收尾的依据。变更管理是为使得项目基准与项目实际执行情况相一致，应对项目变化的 一套管理方法。其可能的两个结果是拒绝变化，或是调整项目基准。从资源增值视角看，变更的实质是在项目过程中，按一定流程，据因变化情况而确立 的方案，从而调整资源的配置方式，或将储备资源运用于项目之中，满足项目需求 。

19.2.2 管理原则

变更管理的原则是项目基准化和变更管理过程规范化。主要内容包括:

• 基准管理:基准是变更的依据 。 在项目实施过程中，基准计划确定并经过评审后(通常用户应参与部分评审工作)，建立初始基准。此后每次变更通过评审后，都应重新确定基准。
• 变更控制流程化:建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个 控制流程 。 流程化的作用在于将变更的原因、专业能力、资源运用方案、决策权、干系 人的共识、信息流转等元素有效综合起来，按科学的顺序进行 。
• 明确组织分工:至少应明确变更相关工作的评估、评审、执行的职能。
• 评估变更的可能影响:变更的来源是多样的，既需要完成对客户可视的成果、交付期等 变更操作，还需要完成对客户不可视的项目内部工作的变更，如实施方的人员分工、管 理工作和资源配置等。
• 妥善保存变更产生的相关文档:确保其完整、及时、准确和清晰，适当时可以引入配置 管理工具 。

19.2.3 角色与职责

规范的项目实施，提倡分权操作 。 项目经理是组织委托的项目经营过程负责者，其正式权 利由项目 章程取得，而资源调度的权力通常由基准中明确 。 基准中不包括的储备资源需经授权 人批准后方可使用。

项目经理在变更中的作用是 (背诵):

• 响应变更提出者的需求:
• 评估变更对项目的影响及应对方案:
• 将需求由技术要求转化为资源需求，供授权人决策:
• 并据评审结果实施(即 调整基准)，确保项目基准反映项目实施情况。

信息系统项目中，除项目经理和 CCB 外，通常还会定义变更管理负责人、变更请求者、变 更实施者和变更顾问委员会等 。

1、变更管理负责人

变更管理负责人也称变更经理，通常是变更管理过程解决方案的负责人，其主要职责包括:

1. 负责整个变更过程方案的结果:
2. 负责变更管理过程的监控:
3. 负责协调相关的资源，保障 所有变更按照预定过程顺利运作:
4. 确定变更类型，组织变更计划和日程安排;
5. 管理变更的 日程安排:
6. 变更实施完成之后的回顾和关闭;
7. 承担变更相关责任，并且具有相应权限:
8. 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。

2、变更请求者

变更请求者负责记录与提交变更请求单，具体为 :

1. 提交初步的变更方案和计划:
2. 初步评价变更的风险和影响，给变更请求设定适当的变更类型;
3. 对理解变更过程有能力要求等 。

3、变更实施者

变更实施者需要拥有有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变 更任务 。

4、变更顾问委员会

变更顾问委员会负责对重大变更行使审批，提供专业意见和辅助审批，具体为:

1. 在紧急 变更时，其中被授权者行使审批权限;
2. 定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等 。

19.2.4 工作程序

变更管理工作程序（背诵）

1. 变更申请
2. 对变更的初审
3. 变更方案论证
4. 变更审查
5. 发出通知并实施
6. 实施监控
7. 效果评估
8. 变更收尾

1、变更申请

变更提出应当及时以正式方式进行，井留下书面记录 。 变更的提出可以是各种形式，但在评 估前应以书面形式提出 。 项目的干系人都可以提出变更申请，但一般情况下都需要经过指定人员 进行审批， 一般项目经理或者项目配置管理员负责该相关信息的收集，以及对变更申请的初审 。

2、对变更的初审

变更初审的目的主要包括:

1. 对变更提出方施加影响，确认变更的必要性，确保变更是有 价值的:
2. 格式校验，完整性校验，确保评估所需信息准备充分:
3. 在干系人间就提出供评估 的变更信息达成共识等 。

变更初审的常见方式为: 变更申请文档的审核流转 。

3、变更方案论证

变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更 请求由技术要求转化为资源需求，以供 CCB 决策 。 常见的方案内容包括技术评估和经济与社会 效益评估，前者评估需求如何转化为成果，后者评估变更方面的经济与社会价值和潜在的风险 。

对于 一 些大型的变更，可以召开相关的变更方案论证会议，通常需要由变更顾问委员会 (相关技术和经济方面的专家组成)进行相关论证，并将相关专家意见作为项目变更方案的 一部 分，报项目 CCB作为决策参考。

4、变更审查

变更审查过程是项目所有者根据变更申请及评估方案，决定是否变更项目基准 。 评审过程 常包括客户、相关领域的专业人士等 。审查通常采用文档、会签形式，重大的变更审查可以采 用正式会议形式 。

审查过程应注意分工，项目投资人虽有最终的决策权，但通常技术上并不专业。所以应当 在评审过程中将专业评审、经济评审分开，对于涉及项目目标和交付成果的变更，客户和服务 对象的意见应放在核心位置 。

5、发出通知并实施

变更评审通过后，意味着基准的调整，同时确保变更方案中的资源需求及时到位 。基准调 整包括项目目标的确认，最终成果、工作内容和资源、进度计划的调整。需要强调的是:变更 通知不只是包括项目实施基准的调整，更要明确项目的交付日期、成果对相关干系人的影响 。 如果变更造成交付期调整，应在变更确认时发布，而非在交付前公布。

6、实施监控

变更实施的监控，除了调整基准中涉及变更的内容外，还应当对项目的整体基准是否反映 项目实施情况负责。通过监控行动，确保项目的整体实施工作是受控的。变更实施的过程监控， 通常由项目经理负责基准的监控 。 CCB 监控变更明确的主要成果、进度里程碑等，也可以通过 监理单位完成监控。

7、效果评估

变更评估的关注内容主要包括:1评估依据是项目的基准:2结合变更的目标，评估变更 所要达到的目的是否己达成: 3评估变更方案中的技术论证、经济论证内容与实施过程的 差距 ， 并促使解决。

8、变更收尾

变更收尾是判断发生变更后的项目是否己纳入正常轨道。配置基准调整后，需要确认资源 配置是否及时到位，若涉及人员的调整，则需要更加关注 。变更完成后对项目的整体监控应按 新的基准进行 。 若涉及变更的项目范围及进度，则在变更后的紧邻监控中，应更多地关注、确 认新的基准生效情况，及项目实施流程的正常使用情况。

19.2.5 变更控制

由于变更的实际情况千差万别，可能简单，也可能相当复杂 。 越大型的项目，调整基准的 边际成本越高，随意调整可能带来的后果众多，包括基准失效、项目干系人冲突、资源浪费、 项目执行情况混乱等 。在 项目整体压力较大的情况下，更需强调变更的提出和处理应当规范化， 可以使用分批处理、分优先级等方式提高效率 。 例如，在繁忙的交通道口，如果红绿灯变化频 繁，其实不是灵活高效，而是整体通过能力的降低。

项目规模小、与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高 效。但小项目的变更仍应注意对变更产生的因素施加影响(如防止不必要的变更，减少无谓的评估，提高必要变更的通过效率等)，对变更的确认应当正式化，变更的操作过程应当规范化等 。

变更管理虽然遵循一致的工作过程，但需要针对不同类型的变更，明确其控制要求。一般来说，项目的变更控制主要关注变更申请的控制及变更过程的控制。在变更过程控制中，需要 对进度变更控制、成本变更控制和合同变更控制等进行重点关注，其他方面的变更控制需要结 合具体变更的重点关注项，定义其控制要求。

1、变更申请的控制

由于变更的真实原因和提出背景复杂，如不经评估而快速实施则可能涉及的项目影响难以 预料，而变更申请是变更管理流程的起点，故应严格控制变更申请的提交。变更控制的前提是 项目基准健全，变更处理的流程事先共识 。 这里严格控制是指变更管理体系能确保项目基准能 反映项目的实施情况。

变更申请的提交，首先应当确保覆盖所有变更操作，这意味着如果变更申请操作可以被绕 过，那么变更申请的严格管理便毫无意义:但项目应根据变更的影响和代价提高变更流程的效 率，并在某些情况下使用进度管理中的快速跟进等方法。例如，委托方和实施方高层管理者己 共识的变更请求，在实施过程中应提高变更执行的效率。

2、变更过程控制

(1)对进度变更的控制。对进度变更的控制主要包括:

1. 判断项目进度的当前状态，
2. 对造成进度变化的因素施加影响:
3. 查明进度是否已经改变:
4. 在实际变化出现时对其进行管理

(2) 对成本变更的控制。对成本变更的控制主要包括

1. 对造成费用基准变更的因素施加 影响;
2. 确保变更请求获得同意:
3. 当变更发生时，管理这些实际的变更:
4. 保证潜在的费用 超支不超过授权的项目阶段资金和总体资金:
5. 监督费用绩效，找出与费用基准的偏差:
6. 准 确记录所有与费用基准的偏差:
7. 防止错误的、不恰当的或未批准的变更被纳入费用或资源使 用报告中:
8. 就审定的变更，通知利害关系者:
9. 采取措施，将预期的费用超支控制在可接受 的范围内:
10. 项目费用控制查找正、负偏 差 的原因 。 例如，若对费用偏 差采 取不适当的应对措 施，就可能造成质量或进度问题，或在项目后期产生无法接受的巨大风险等。

(3)对合同变更的控制。合同变更控制是规定合同修改的过程，它包括文书工作、跟踪系 统、争议解决程序以及批准变更所需的审批层次。合同变更控制应当与整体变更控制结合起来。

19.2.6 版本发布和回退计划

对于很多信息系统开发项目来说，项目变更必须做相应的版本发布，并制定相应的应急回 退方案。为确保版本发布的成功，在版本发布前应对每次版本发布进行管理，并做好发布失败 后的回退方案。

版本发布前的准备工作包括 :

1. 进行相关的回退分析:
2. 备份版本发布所涉及的存储过程、 函数等其他数据的存储及回退管理;
3. 备份配置数据，包括数据备份的方式;
4. 备份在线生产 平台接口、应用、工作流等版本;
5. 启动回退机制的触发条件:
6. 对变更回退的机制职责的说 明，如通知相关部门，确定需要回退的关联系统和回退时间点等。

为确保版本发布的成功，在版本发布前应对每次版本发布的风险进行相应的评估，对版本 发布的过程检查单( Check list)做严格的评审 。在评审发布 内容时对存在风险的发布项做重点 评估，确定相应的回退范围，制定相应的回退策略。

回退步骤通常包括 :

1. 通知相关用户系统 开始回退;
2. 通知各关联系统进行版本回退;
3. 回退存储过程等数据对象:
4. 配置数据回退;
5. 应用程序、接口程序、工作流等版本回退;
6. 回退完成通知各周边关联系统:
7. 回退后进行 相关测试，保证回退系统能够正常运行;
8. 通知用户回退完成

项目还需要对引起回退的原因进行深入分析、总结经验，避免下次回退发生。对执行回退 计划中出现的问题进行分析，完善回退的管理。

19.3 项目文档管理

信息系统相关信息(文档)是指某种数据媒体和其中所记录的数据。它具有永久性，并可 以由人或机器阅读，通常仅用于描述人工可读的东西。在软件工程中，文档常常用来表示对活 动、需求、过程或结果进行描述，定义，规定，报告或认证的任何书面或图示的信息(包括纸 质文档和电子文档)。

19.3.1 管理基础

信息系统项目类型的不同，其文档分类的方法不同，不同的组织也会结合自身的管理实践， 定义其文档类型。对于信息系统开发项目来说，其文档 一般分开发文档、产品文档和管理文档。

(1)开发文档描述开发过程本身，基本的开发文档包括:

• 可行性研究报告和项目任务书
• 需求规格说明
• 功能规格说明
• 设计规格说明
  • 程序和数据规格说明
  • 开发计划
  • 软件集成和测试计划
  • 质量保证计划
  • 安全和测试信息等

(2)产品文档描述开发过程的产物，基本的产品文档包括:

• 培训手册
• 参考手册和用户指南
• 软件支持于册
• 产品手册和信息广告

(3)管理文档记录项目管理的信息，例如:

• 开发过程的每个阶段的进度和进度变更的记录
• 软件变更情况的记录
• 开发团队的职责定义、项目计划、项目阶段报告
• 配置管理计划

文档的质量通常可以分为 4 级:

(1)最低限度文档 (1级文档):适合开发工作量低于 一个人月的开发者自用程序 。该文档 应包含程序清单、开发记录、测试数据和程序简介。

(2)内部文档( 2 级文档): 可用于没有与其他用户共享资源的专用程序。除 1 级文档提供 的信息外， 2 级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。

(3)工作文档( 3 级文档):适合于由同一单位内若干人联合开发的程序，或可被其他单位 使用的程序。

(4)正式文档( 4 级文档):适合那些要正式发行供普遍使用的软件产品。关键性程序或具 有重复管理应用性质(如工资计算)的程序需要 4 级文挡。 4 级文档遵守 GB/T 2006-8567 《计 算机软件文档编制规范》的有关规定。

19.3.2 规则和方法

文档的规范化管理主要体现在文档书 写规范、图表编号规则、文档目录编写标准和文档管 理制度等几个方面。

(1)文档书写规范 。 管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是 哪种类型的文档都应该遵循统 一 的书写规范，包括符号的使用、图标的含义、程序中注释行的 使用、注明文档书写人及书写日期等 。 例如，在程序的开始要用统 一 的格式包含程序名称、程 序功能、调用和被调用的程序、程序设计人等。

(2)图表编号规则 。 在管理信息系统的开发过程中用到很多的图表 ， 对这些图表进行有规 则地编号，可以方便图表的查找 。 图表的编号 一般采用分类结构 。 根据生命周期法的 5 个阶段， 可以给出如图 19-3 所示的分类编号规则 。 根据该规则，就可以通过图表编号判断该图表出于系 统开发周期的哪一个阶段，属于哪一个文档 ， 文档中的哪一部分内容及第几张图表。

(3)文档目录编写标准 。为了存档及未来使用的方便，应该编写文档目录。管理信息系统 的文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、 存档时间、保管人等 。 文档编号 一般为分类结构，可以采用同图表编号类似的编号规则 。 文档 名称要书写完整、规范 。 格式或载体指的是原始单据或报表、磁盘文件、磁盘文件打印件、大 型图表、重要文件原件、光盘存档等。

(4)文档管理制度 。 为了更好地进行信息系统文档的 管理，应该建立相应的文档管理制度 。 文档的管理制度须根据组织实体的具体情况而定 ， 主要包括建立文档的相关规 范 、文档借阅记 录的登记制度、文档使用权限控制规则等。 建立文档的相关规范是指文档书写规范、图表编号 规则和文档目录编写标准等 。 文档的借阅应该进行详细的记录 ， 并且需要考虑借阅人是否有使 用权限 。 在文档中存在商业秘密或技术秘密的情况下，还应注意保密 。 特别要注意的是，项目 干系人签字确认后的文档要与相关联的电子文档一一对应，这些电子文档还应设置为只读。