第19章-配置与变更管理

引言

配置管理是通过技术或者行政的手段对项目管理对象和信息系统的信息进行管理的一系列活动。

这些信息不仅包括具体配置项信息，还包括这些配置项之间的相互关系。

配置管理包含配置库的建立和配置管理数据库（Configuration Management Databases, CMDB）准确性的维护，以支持信息系统项目的正常运行。

在信息系统项目中，配置管理可用于问题分析、变更影响度分析和异常分析等，因此，配置项与真实情况的匹配度和详细度非常重要。

在组织实施信息系统项目过程中，常常会遇到变更的发生。

变更的诱发一般有主动变更和被动变更两种。

• 主动变更是主动发起的变更，常用于提高项目收益，包括降低成本、改进过程以及提高项目的便捷性和有效性等；

• 被动变更常用于范围变化、异常、错误和适应不断变化的环境等，如随需求的增加，相应需要增加系统的功能或投资等。

变更管理是对变更从提出、审议、批准到实施、完成的整个过程的管理。

19.1 配置管理

定义

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

在（GB/T28827.1）《信息技术服务运行维护第1部分：通用要求》中指出：
组织应建立配置管理过程，整体规划配置管理范围，保留配置信息，并保证配置信息的可靠性、完整性和时效性，以对其他服务过程提供支持；应建立与配置管理过程相一致的活动，包括对配置项的识别、收集、记录、更新和审核等。

尽管硬件配置管理和软件配置管理的实现有所不同，但配置管理的概念可以应用于各种信息系统项目。

19.1.1 管理基础

配置项-概念

• GB/T11457-2006：为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待

• 分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

• 所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放

配置项-状态

草稿、正式、修改

• 配置项刚建立时，其状态为“草稿”

• 配置项通过评审后，其状态变为“正式”

• 此后若更改配置项，则其状态变为“修改”

• 当配置项修改完毕并重新通过评审后，状态变为“正式”

配置项-版本号

1. 草稿：格式为0.YZ，YZ的数字范围为01~99

2. 正式：格式为X.Y，X为主版本号，取值范围为1~9

3. 修改：格式为X.YZ

for example

配置基线

• 由一组配置项组成，构成一个相对稳定的逻辑实体

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

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

• 基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线

• 交付给外部顾客的基线一般称为发行基线

• 内部开发使用的基线一般称为构造基线

建立基线的价值可包括：

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

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

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

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

配置管理数据库

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

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

配置库

存放配置项并记录与配置项相关的所有信息

1. 开发库，也称为动态库、程序员库或工作库，保存当前正在开发的配置实体，是个人工作区，开发人员自行控制。

2. 受控库，也称为主库，包含当前的基线加上对基线的变更。库中配置项被置于完全的配置管理之下。

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

配置库的建库模式

1. 按配置项的类型分类建库，适用于通用软件的开发组织

2. 按开发任务建立相应的配置库，适合专业软件开发组织

19.1.2 角色与职责

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、确定配置基准线。
5、确定配置结构。
6、确定配置项命名规则。

3.配置项控制

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

流程：
1、变更申请。
2、变更评估。
3、通过评估结果。
4、实施变更。
5、变更验证与确认。
6、变更发布。
7、基于配置库的变更控制

4.配置状态报告

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

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

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

2. 每个变更申请的状态和已批准的修改的实施状态。

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

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

5.配置审计

配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求，不允许出现任何混乱现象：
1、防止向用户提交不适合的产品；
2、发现不完善的实现；
3、找出各配置项间不匹配或不相容的现象；
4、确认配置项已在所要求的质量控制审核之后纳入基线开入库保存；
5、确认记录和文档保持看可追溯性等。

功能配置审计。审计配置项的一致性（配置项的实际功效是否与其需求一致），具体验证主要包括：
1、配置项的并发已圆满完成：
2、配置项已达到配置标识中规定的性能和功能特征；
3、配置项的操作和支持文档已完成并且是符合要求的等。

物理配置审计。审计配置项的完整性（配置项的物理存在是否与预期一致），具体验证主要包括：
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.变更的分类

• 根据变更性质可分为重大变更、重要变更和一般变更，通过不同审批权限进行控制；

• 根据变更的迫切性可分为紧急变更、非紧急变更；

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

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.变更收尾。

19.2.5 变更控制

1.变更申请的控制。
变更申请的提交，首先应当确保覆盖所有变更操作；但项目应根据变更的影响和代价提高变更流程的效率，并在某些情况下使用进度管理中的快速跟进等方法。

2.变更过程控制。
包括：对进度变更的控制；对成本变更的控制；对合同变更的控制。

19.2.6 版本发布和回退计划

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

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

19.3 项目文档管理

19.3.1 管理基础

软件文档-分类

1. 开发文档，描述开发过程本身，包括：可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息。

2. 产品文档，描述开发过程的产物，包括：培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。

3. 管理文档，记录项目管理的信息，例如：每个阶段的进度和进度变更的记录、软件变更情况的记录、开发团队的职责定义、项目计划、项目阶段报告、配置管理计划。

软件文档-质量分级

文档质量通常可分为4级：

1. 最低限度文档（1级文档）。开发者自用程序。

2. 内部文档（2级文档）。没有与其他用户共享的专用程序。

3. 工作文档（3级文档）。由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。

4. 正式文档（4级文档）。那些要正式发行供普遍使用的软件产品、关键性程序或具有重复管理应用性质（如工资计算）的程序。

19.3.2 规则和方法

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

19.4 本章练习

1.选择题

（1）配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的____和____。
A.完整性 可跟踪性
B.完整性 真实性
C.高效性 可跟踪性
D.高效性 真实性

（2）____负责在整个项目生命周期中进行配置管理的主要实施活动。
A.配置管理负责人
B.配置项负责人
C.项目经理
D.配置管理员

（3）若对配置项进行更改，配置项状态为____。当配置项修改完毕并重新通过评审时，其状态变为____。
A.修改 正式
B.草稿 正式
C.草稿 修改
D.正式 草稿

（4）配置管理的日常管理活动主要包括：制订配置管理计划、配置项识别、配置项控制、配置状态报告、（ ）、配置管理回顾与改进等。
A.配置审计
B.配置变更
C.配置项重新定义
D.配置管理

（5）对于大型的变更，可以召开相关的变更方案论证会议，通常需要由____（相关技术和经济方面的专家组成）进行相关论证。
A.变更控制委员会 CCB
B.变更实施委员会
C.变更顾问委员会
D.配置管理委员会

（6）对于信息系统开发项目来说，其文档一般分为开发文档、产品文档和____。
A.管理文档
B.应用文档
C.指南文档
D.规范文档

（7）对于信息系统开发项目来说，参考手册和用户指南属于____。
A.规划文档
B.开发文档
C.配置文档
D.产品文档

2.判断题

判断下列表述正误，正确的选√，错误的选×。
（1）配置项是信息系统组件或与其有关的项目，包括软件和各种文档，不包括硬件。
（2）合同变更控制是规定合同修改的过程，合同变更控制应当单独执行，不要与整体变更控制结合起来。
（3）变更管理虽然遵循一致的工作过程，但需要针对不同类型的变更，明确其不同的控制要求。

end