19配置与变更管理

配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。在(GB/T11457)《信息技术软件工程术语》中，将“配置管理”正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性"。在
(GB/T28827.1)《信息技术服务运行维护第1部分：通用要求》中指出：组织应建立配置管理过程，整体规划配置管理范围，保留配置信息，并保证配置信息的可靠性、完整性和时效性，以对其他服务过程提供支持；应建立与配置管理过程相一致的活动，包括对配置项的识别、收集、记录、更新和审核等。尽管硬件配置管理和软件配置管理的实现有所不同，但配置管理的概念可以应用于各种信息系统项目。

在信息系统项目中，配置管理的目标主要用以定义并控制信息系统的组件，维护准确的配置信息，具体包括:
①所有配置项能够被识别和记录;
②维护配置项记录的完整性;
③为其他管理过程提供有关配置项的准确信息;
④核实有关信息系统的配置记录的正确性并纠正发现的错误;
⑤配置项当前和历史状态得到汇报;
⑥确保信息系统的配置项的有效控制和管理。
为了实现上述目标需要建立一个完整的配置项管理过程，通过该管理过程实现对所有配置项的有效管理，以保证所有配置项及时正确地识别、记录和查询，配置元素当前和历史状态得到汇报，以及配置元素记录的完整性。

配置管理的目标∶为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的管理（或者是“应用技术和管理的指导和监督方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性”）。

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

（2）配置项识别。配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构识别。配置项识别是配置管理的一项基础性工作，要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。
配置基准线（关键节点、核心）是对某个特定时点上一组配置项的描述。一项完整的配置基准线应该包括的内容主要有：①过去的、当前的和计划中的发布信息；②过去的、当前的和计划中的变更信息；③批准和实施变更时信息系统的状态和有关文档；④实施发布时信息系统的状态和有关文档；⑤按标准规范配置的硬件和软件。

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

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

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

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

定义

典型配置项包括

在信息系统的开发流程中需加以控制的配置项可以分为基线配置项和非基线配置项两类

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

配置项的状态可分为“草稿”“正式”和“修改”三种。

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

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

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

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

配置项的版本号规则与配置项的状态相关

（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值

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

配置基线也是指一个产品或系统在某一特定时刻的配置状况。这种配置不仅体现了其产品或系统的结构，还反映了其具体内容，从而使得以后可以按照上述配置重建该产品或系统。

尽管被作为基准线的这个配置状态以后可能发生改变，但这个基线本身保持不变。这个基线可以作为初始状态的一个参考或当前状态的一个对照。配置基线可用于管理对象中的授权产品、标准配置项、开发和测试新配置的起点、作为提供给IT系统用户的配置的标准(如标准工作站)、作为提供新软件的起点等。

基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。

基线通常对应于项目过程中的里程碑(Milestone),一个项目可以有多个基线，也可以只有一个基线。交付给用户使用的基线一般称为发行基线(Release),内部过程使用的基线一般称为构造基线(Build)

建立基线的价值

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

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

配置管理相关角色常包括：变更控制委员会（ChangeControlBoard,CCB）、配置管理负责人、配置管理员和配置项负责人等。

（1）配置管理负责人

（2）配置管理员

（3）配置项负责人

①所有配置项应该记录

②配置项应该分类

③所有配置项要编号

④应该定期对配置库或配置管理数据库中的配置项信息进行审计

⑤每个配置项在建立后，应有配置负责人负责

⑥要关注配置项的变化情况

⑦应该定期对配置管理进行回顾

⑧能够与项目的其他管理活动进行关联

根据变更性质分为

根据变更迫切性分为

根据行业特点分类

如果把项目整体的交付物视作项目的配置项，配置管理可视为对项目完整性管理的一套系统，当用于项目基准调整时，变更管理可视为其一部分。

亦可视变更管理与配置管理为相关联的两套机制，变更管理由项目交付或基准配置调整时，由配置管理
过程调用，变更管理最终应将对项目的调整结果反馈给配置管理过程，以确保项目执行与项目配置信息相一致

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

变更的常见原因（畅想、针对、外籍）

项目经理

变更管理负责人

变更请求者

变更实施者

变更顾问委员会

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

（1）变更申请

（2）对变更初审：文档审核流转

（3）变更方案论证

（4）变更审查

（5）发出通知并实施

（6）实施监控

（7）效果评估

（8）变更收尾

在项目整体压力较大的情况下，更需强调变更的提出和处理应当规范化，可以使用分批处理、分优先级等方式提高效率。

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

(1)对进度变更的控制

(2)对成本变更的控制

(3)对合同变更的控制

信息系统开发项目的文档一般分为三类：开发文档、产品文档、管理文档

开发文档

产品文档

管理文档

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

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

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

（4）正式文档（4级文档），适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要4级文档。4级文档遵守GB/T2006-8567的有关规定。

文档的规范化管理主要体现在文档书写规范（遵循统一的书写规范）、图表编号规则（方便查找，采用分类结构）、文档目录编写标准（方便使用，采用分类结构）和文档管理制度（更好管理，权限分配、保密制度）等几个方面。