配置管理是通过技术或者行政的手段对项目管理对象和信息系统的信息进行管理的一系列活动。这些信息不仅包括具体配置项信息，还包括这些配置项之间的相互关系。配置管理包含配置库的建立和配置管理数据库（Configuration Management Databases, CMDB)准确性的维护，以支持信息系统项目的正常运行。在信息系统项目中，配置管理可用于问题分析、变更影响度分析和异常分析等，因此，配置项与真实情况的匹配度和详细度非常重要。
在组织实施信息系统项目过程中，常常会遇到变更的发生。变更的诱发一般有主动变更和被动变更两种。主动变更是主动发起的变更，常用于提高项目收益，包括降低成本、改进过程以及提高项目的便捷性和有效性等；
被动变更常用于范围变化、异常、错误和适应不断变化的环境等，如随需求的增加，相应需要增加系统的功能或投资等。变更管理是对变更从提出、审议、批准到实施、完成的整个过程的管理。
19.1 配置管理555
配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。在(GB/T 11457)《信息技术软件工程术语》中，将“配置管理”正式定义为：＂应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性”。在(GB/T 28827.1)《信息技术服务运行维护第1部分：通用要求》中指出：组织应建立配置管理过程，整体规划配置管理范围，保留配置信息，并保证配置信息的可靠性、完整性和时效性，以对其他服务过程提供支持；应建立与配置管理过程相一致的活动，包括对配置项的识别、收集、记录、更新和审核等。尽管硬件配置管理和软件配置管理的实现有所不同，但配置管理的概念可以应用于各种信息系统项目。
19.1.1 基础管理555
- 配置项(Configuration Item, CI)
GB/T 11457《信息技术软件工程术语》对配置项的定义为：”为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待＂。配置项是信息系统组件或与其有关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等。这些组件或项目已经或将要受到配置管理的控制。
比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等，它们经评审和检查通过后进入配置管理。所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在 CMDB中。例如，在信息系统的开发项目中需加以控制的配置项可以分为基线配置项和非基线配置项两类，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由配置管理员严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向项目经理、CCB及相关人员开放。 - 配置项状态
配置项的状态需要根据配置项的不同类型和管理需求进行分别定义，基于配置项建设过程角度，可将配置项状态分为“草稿”“正式”和“修改“三种。配置项刚建立时，其状态为“草稿＂。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改“。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
配置项状态变化如图19-1所示。
- 配置项版本号
配置项的版本号规则与配置项的状态定义相关。例如：
⓵处于“草稿”状态的配置项的版本号格式为O.YZ, YZ是数字，取值范围为01~99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
⓶处于“正式”状态的配置项的版本号格式为X.Y, X为主版本号，取值范围为1~9; y为次版本号，取值范围为0~9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0,1.1,……当附件的变动积累到一定程度时，配置项的Y值可适量增加；Y值增加到一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。
⓷处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为O,增加X.Y值。参见上述规则⓶。 - 配置项版本管理
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发布和交付等。例如，在信息系统开发项目过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。 - 配置基线
配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。配置基线也是指一个产品或系统在某一特定时刻的配置状况。这种配置不仅体现了其产品或系统的结构，还反映了其具体内容，从而使得以后可以按照上述配置重建该产品或系统。尽管被作为基准线的这个配置状态以后可能发生改变，但这个基线本身保持不变。这个基线可以作为初始状态的一个参考或当前状态的一个对照。配置基线可用于管理对象中的授权产品、标准配置项、开发和测试新配置的起点、作为提供给IT系统用户的配置的标准（如标准工作站）、作为提供新软件的起点等。
在信息系统项目过程中，各类配置项存在不断变化的情况，为了在不严重阻碍合理变化的情况下来控制变化，需要使用配置基线这一概念。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。例如，一组拥有唯一标识号的需求、设计、源代码文档以及相应的可执行代码、构造文档和用户文档构成一条基线。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例和使用手册等）也是基线的例子。
基线通常对应于项目过程中的里程碑(Milestone),一个项目可以有多个基线，也可以只有一个基线。交付给用户使用的基线一般称为发行基线(Release),内部过程使用的基线一般称为构造基线(Build)。
对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。
建立基线的价值可包括：
(1)基线为项目工作提供了一个定点和快照。
(2)新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
(3)当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
(4)可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。 - 配置管理数据库
我们常使用配置管理数据库来管理配置项，它是指包含每个配置项及配置项之间重要关系的详细资料的数据库。对于信息系统开发项目来说，常使用配置库实施配置数据的管理。配置管理数据库主要内容包括：
⓵发布内容，包括每个配置项及其版本号；
⓶经批准的变更可能影响到的配置项；
⓷与某个配置项有关的所有变更请求；
⓸配置项变更轨迹；
⓹特定的设备和软件；
⓺计划升级、替换或弃用的配置项；
⓻与配置项有关的变更和问题；
⓼来自于特定时期特定供应商的配置项；
⓽受问题影响的所有配置项。
配置管理数据库管理所有配置项及其关系，以及与这些配置项有关的事件、问题、已知错误、变更和发布及相关的员工、供应商和业务部门信息；保存多种服务的详细信息及这些服务与IT组件之间的关系；保存配置项的财务信息，如供应商、购买费用和购买日期等。 - 配置库
针对信息系统开发类型的项目，我们常使用配置库(Configuration Library)存放配置项并记录与配置项相关的所有信息，它是配置管理的有力工具。
利用配置库中的信息可回答许多配置管理的问题：
⓵哪些用户已提取了某个特定的系统版本；
⓶运行一个给定的系统版本需要什么硬件和系统软件；
⓷一个系统到目前已生成了多少个版本，何时生成的；
⓸如果某一特定的构件变更了，会影响到系统的哪些版本；
⓹一个特定的版本曾提出过哪几个变更请求；
⓺一个特定的版本有多少已报告的错误。
使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。配置库可以分开发库、受控库、产品库3种类型。
(1)开发库。开发库也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其进行配置控制，因为这通常不会影响到项目的其他部分。
(2)受控库。受控库也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
(3)产品库。产品库也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
配置库的建库模式有两种：按配置项类型建库和按开发任务建库。
(1)按配置项的类型分类建库。这种模式适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
(2)按开发任务建立相应的配置库。这种模式适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以没必要把配置项严格分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。
19.1.2 角色与职责558
配置管理相关角色常包括：变更控制委员会(Change Control Board, CCB)、配置管理负责人、配置管理员和配置项负责人等。
- 配置管理负责人
配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动，具体有：
⓵管理所有活动，包括计划、识别、控制、审计和回顾；
⓶负责配置管理过程；
⓷通过审计过程确保配置管理数据库的准确和真实；
⓸审批配置库或配置管理数据库的结构性变更；
⓹定义配置项责任人；
⓺指派配置审计员；
⓻定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态；
⓼评估配置管理过程并持续改进；
⓽参与变更管理过程评估；
⑩对项目成员进行配置管理培训。 - 配置管理员
配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动，具体有：
⓵建立和维护配置管理系统；
⓶建立和维护配置库或配置管理数据库；
⓷配置项识别；
⓸建立和管理基线；
⓹版本管理和配置控制；
⓺配置状态报告；
⓻配置审计；
⓼发布管理和交付。 - 配置项负责人
配置项负责人确保所负责的配置项的准确和真实：
⓵记录所负责配置项的所有变更；
⓶维护配置项之间的关系；
⓷调查审计中发现的配置项差异，完成差异报告；
⓸遵从配置管理过程；
⓹参与配置管理过程评估。
19.1.3 目标与方针559
- 管理目标
在信息系统项目中，配置管理的目标主要用以定义并控制信息系统的组件，维护准确的配置信息，具体包括：
⓵所有配置项能够被识别和记录；
⓶维护配置项记录的完整性；
⓷为其他管理过程提供有关配置项的准确信息；
⓸核实有关信息系统的配置记录的正确性并纠正发现的错误；
⓹配置项当前和历史状态得到汇报；
⓺确保信息系统的配置项的有效控制和管理。
为了实现上述目标需要建立一个完整的配置项管理过程，通过该管理过程实现对所有配置项的有效管理，以保证所有配置项及时正确地识别、记录和查询，配置元素当前和历史状态得到汇报，以及配置元素记录的完整性。
针对信息系统开发项目，常需要通过实施软件配置管理达到配置管理的目标，即在整个软件生命周期中建立和维护项目产品的完整性。组织需要实现的配置管理目标主要包括：
⓵确保软件配置管理计划得以制订，并经过相关人员的评审和确认；
⓶应该识别出要控制的项目产品有哪些，并且制定相关控制策略，以确保这些项目产品被合适的人员获取；
⓷应制定控制策略，以确保项目产品在受控制范围内更改；
⓸应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容。 - 管理方针
为了实现配置管理目标，组织应定义配置管理过程，制定配置管理相关制度。管理层和具体项目负责人应该明确相关人员在项目中所担负的配置管理方面的角色和责任，并使他们得到适合的培训。项目组成员应严格按照配置管理过程文件规定的要求执行，履行配置管理的相关职责。配置管理工作应该享有资金和管理决策支持等。配置管理的系统性应在整个项目生命周期中得到控制。配置管理应基于项目类型和交付物等定义覆盖全面的管理范围，如信息系统开发项目中对外交付的软件产品，以及那些被选定的在项目中使用的支持类工具等。组织应定期开展配置审计活动。配置管理关键成功因素主要包括：
⓵所有配置项应该记录；
⓶配置项应该分类；
⓷所有配置项要编号；
⓸应该定期对配置库或配置管理数据库中的配置项信息进行审计；
⓹每个配置项在建立后，应有配置负责人负责；
⓺要关注配置项的变化情况；
⓻应该定期对配置管理进行回顾；
⓼能够与项目的其他管理活动进行关联。
19.1.4 管理活动560
配置管理的日常管理活动主要包括：制订配置管理计划、配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾与改进等。
- 制订配置管理计划
配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。配置管理计划的主要内容为：- 配置管理的目标和范围。
- 配置管理活动主要包括配置项标识、配置项控制、配置状态报告、配置审计、发布管理与交付等。
- 配置管理角色和责任安排。
- 实施这些活动的规范和流程，如配置项命名规则。
- 实施这些活动的进度安排，如日程安排和程序。
- 与其他管理之间（如变更管理等）的接口控制。
- 负责实施这些活动的人员或团队，以及他们和其他团队之间的关系。
- 配置管理信息系统的规划，包括配置数据的存放地点、配置项运行的受控环境、与其他服务管理系统的联系和接口、构建和安装支持工具等。
- 配置管理的日常事务，包括许可证控制、配置项的存档等。
- 计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划。
- 配置项识别
配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构识别。它包括为配置项分配标识和版本号等。配置项识别是配置管理的一项基础性工作，要确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。
(1)确定配置项范围。识别配置项范围、配置项级别与细节，预先决定哪些资产和活动将受配置管理控制，定义要使用什么级别的控制，哪些配置需要进一步分为多个组件，生成子配置项等。其他与配置项有关的记录和信息也需要保存。这些信息包括配置项的版本信息、变更历史、存储位置及相互间关系等信息。
(2)确认和记录配置项属性。为了便于对配置项进行管理，配置管理需要预先确认和记录各配置项，特别是高风险或关键配置项的属性。配置项属性一般包括配置项的名称、编号、类别、版本号、责任人、来源、提供日期、许可证号、目前状态、计划状态、父配置项关联、子配置项关联、事件号、问题号、变更请求号、变更号、备注等内容。
(3)为配置项定义标识符。为便于识别，配置管理应该赋予每个配置项一个唯一的标识符并维护这些标识的准确性。硬件配置项可以通过在硬件配置项上贴上或刻上物理标记或通过条形码来定义配置项的标识符；软件配置项可以在将其软件存入配置库时，制作一个包含配置项名称和版本号的标签；文档配置项可以通过在文档命名中加入有效日期和更新日期加以标识。
(4)确定配置基准线。配置基准线是对某个特定时点上一组配置项的描述。一项完整的配置基准线应该包括的内容主要有：
⓵过去的、当前的和计划中的发布信息；
⓶过去的、当前的和计划中的变更信息；
⓷批准和实施变更时信息系统的状态和有关文档；
⓸实施发布时信息系统的状态和有关文档；
⓹按标准规范配置的硬件和软件。
(5)确定配置结构。为了完整地识别和记录各配置项之间的关系，需要确定信息系统的配置结构。配置结构说明了配置项的层次结构和各配置项之间的关系。这里的结构可以是信息系统的配置结构，也可以是项目配置结构。与配置结构有关的一个关键问题是配置项的选择。配置项可以是一个独立的硬件单元或软件模块，也可以是由多个不同的配置项组合成的一个较大的配置项。一个配置可以同时是许多不同配置项（一个配置项集）的一部分。组织应根据项目管理的需求来选择配置项的级别。将所需的最低配置项级别预先决定好，即使你不会立即将配置管理精细化程度置于那个级别，这也是一件值得花时间去做的事，并且要尽可能为未来着想。
(6)确定配置项命名规则。命名规则可应用于配置项标识、配置文档、变更和基准线等。合理的命名规则有助于管理配置结构中各配置项的层次关系、每个配置项的层次或从属关系、配置项与其相关的文档之间的关系、文档与变更之间的关系、事件和变更之间的关系。配置管理应该建立所有的配置项和控制形式（如变更请求）的命名规则。命名规则的制订应尽量考虑配置项名称的延续性、易记性和可扩展性。
每个配置项可以通过自身的字符、拷贝号／序列号和版本号等标识唯一识别（有关拷贝号／序列号和版本号等详细信息应记录在配置库或配置管理数据库中，但不一定作为标识的一部分）。版本号识别出哪些变化的版本属于同一配置项。同一配置项的不同版本可以在同一时刻共存。在制定命名规则时应充分考虑未来可能的版本增长。标识应相对较短，但有其具体含义，并尽可能使用现有规则，版本记录、变更记录以及其他与信息系统有关的配置项都需要标识。配置项命名规则应能体现：
⓵配置结构内各配置项间的层级关系；
⓶每个配置及其相关文档间的关系；
⓷各配置项及其相关文档间的关系；
⓸文档与变更间的关系等。 - 配置项控制
配置项控制即对配置项和基线的变更控制，包括：标识和记录变更申请、分析和评价变更、批准或否决申请、实现、验证和发布已修改的配置项等任务。
(1)变更申请。变更申请主要就是陈述要做什么变更，为什么要变更，以及打算怎样变更。相关人员（如项目经理）填写变更申请表，说明要变更的内容、变更原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，提交给CCB。
(2)变更评估。CCB负责组织对变更申请进行评估并确定：
⓵变更对项目的影响；
⓶变更的内容是否必要；
⓷变更的范围是否考虑周全；
⓸变更的实施方案是否可行；
⓹变更工作量估计是否合理。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.l版并不删除，继续在产品库中保存）。 - 配置状态报告
配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。在信息系统项目中，配置项在不停地演化着。配置状态报告就是要在某个特定的时刻观察当时的配置状态，也就是要对动态演化着的配置项取个瞬时的“照片“，以利于在状态报告信息分析的基础上，更好地进行控制。配置状态报告应该主要包含：
(1)每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
(2)每个变更申请的状态和已批准的修改的实施状态。
(3)每个基线的当前和过去版本的状态以及各版本的比较。
(4)其他配置管理过程活动的记录等。 - 配置审计
配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求，不允许出现任何混乱现象：
⓵防止向用户提交不适合的产品，如交付了用户手册的不正确版本；
⓶发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更
⓷找出各配置项间不匹配或不相容的现象；
⓸确认配置项已在所要求的质量控制审核之后纳入基线并入库保存；
⓹确认记录和文档保持着可追溯性等。
(1)功能配置审计。功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需求一致），具体验证主要包括：
⓵配置项的开发己圆满完成；
⓶配置项已达到配置标识中规定的性能和功能特征；
⓷配置项的操作和支持文档已完成并且是符合要求的等。
(2)物理配置审计。物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），具体验证主要包括：
⓵要交付的配置项是否存在；
⓶配置项中是否包含了所有必需的项目等。
一般来说，配置审验应当定期进行，应当进行配置审计的场景包括：
⓵实施新的配置库或配置管理数据库之后；
⓶对信息系统实施重大变更前后；
⓷在一项软件发布和安装被导入实际运作环境之前；
⓸灾难恢复之后或事件恢复正常之后；
⓹发现未经授权的配置项后；
⓺任何其他必要的时候等。
部分常规配置审计工作可由审计软件完成，如比较两台计算机的配置情况，分析工作站并报告它当前的状况。但要注意的是，审计软件即使发现不一致的情况，也不允许自动更新配置库或配置管理数据库，必须由有关负责人调查后再进行更新。 - 配置管理回顾与改进
配置管理回顾与改进即定期回顾配置管理活动的实施情况，发现在配置管理执行过程中有无问题，找到改进点，继而优化配置管理过程。配置管理回顾及改进活动包括：
⓵对本次配置管理回顾进行准备，设定日期和主题，通知相关人等参加会议。根据配置管理绩效衡量指标，要求配置项责任人提供配置项统计信息；
⓶召开配置管理回顾会议，在设定日期召开回顾会议，对配置管理报告进行汇报，听取各方意见，回顾上次过程改进计划执行情况；
⓷根据会议结论，制订并提交服务改进计划；
⓸根据过程改进计划，协调、落实改进等。
19.2 变更管理564
变更管理的大致作用与基本操作原则已在整体管理、范围管理等相关章节中介绍，但由于变更管理方法在项目管理中的重要性不断增加，且在实际应用中的影响越来越大，故特设立本节单独论述。变更在信息系统项目过程中经常发生，许多项目失败是对变更处理不当造成的。有些变更是积极的，有些则是消极的，做好变更管理可以使项目的质量、进度和成本管理更有效。
19.2.1 管理基础564
项目变更管理是指在信息系统项目的实施过程中，由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法、项目进度等方面做出的改变。变更管理的实质是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。
- 变更管理与配置管理
如果把项目整体的交付物视作项目的配置项，配置管理可视为对项目完整性管理的一套系统，当用于项目基准调整时，变更管理可视为其一部分。亦可视变更管理与配置管理为相关联的两套机制，变更管理由项目交付或基准配置调整时，由配置管理过程调用，变更管理最终应将对项目的调整结果反馈给配置管理过程，以确保项目执行与项目配置信息相一致。 - 变更产生的原因
由于项目逐渐完善的基本特性，意味着早期的共识随着项目进行，对项目不断深入地理解，作业过程与预先的发生变化是必然的。如果持续按照项目早期的定义开展，很难会保质保量地交付，因而变更控制必不可少。变化可能是对交付物的需求发生的变化，也可能是项目范围或是项目的资源、进度等执行过程发生的变化。变更的常见原因包括：
⓵产品范围（成果）定义的过失或者疏忽；
⓶项目范围（工作）定义的过失或者疏忽；
⓷增值变更；
⓸应对风险的紧急计划或回避计划；
⓹项目执行过程与基准要求不一致带来的被动调整；
⓺外部事件等。 - 变更的分类
变更的分类方式有很多，需要根据具体项目的类型和组织对项目管理的模式与方法等确定，如弱电工程、应用开发、集成、IT咨询、IT运维、信息系统开发等。项目业务形态各异，组织管理成熟度亦有差距，每种业务内容的变更分类方法尚无法统一，组织可在各项目中细化分类，并对不同内容的变更区别情况提出不同控制方法，通过不同变更处理流程进行管理。通常来说，根据变更性质可分为重大变更、重要变更和一般变更，通过不同审批权限进行控制；根据变更的迫切性可分为紧急变更、非紧急变更；根据行业特点分类，如弱电工程行业的常见分类方法为产品（工作）范围变更、环境变更、设计变更、实施变更和技术标准变更。 - 项目变更的含义
项目管理方法的基本原理，即将特定的目标通过规范的计划过程，转化为基准共识之后以指导项目执行，同时作为项目有效监控、收尾的依据。变更管理是为使得项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法。其可能的两个结果是拒绝变化，或是调整项目基准。从资源增值视角看，变更的实质是在项目过程中，按一定流程，据因变化情况而确立的方案，从而调整资源的配置方式，或将储备资源运用于项目之中，满足项目需求。
19.2.2 管理原则565
变更管理的原则是项目基准化和变更管理过程规范化。主要内容包括：
- 基准管理：基准是变更的依据。在项目实施过程中，基准计划确定并经过评审后（通常用户应参与部分评审工作），建立初始基准。此后每次变更通过评审后，都应重新确定基准。
- 变更控制流程化：建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程。流程化的作用在于将变更的原因、专业能力、资源运用方案、决策权、干系人的共识、信息流转等元素有效综合起来，按科学的顺序进行。
- 明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能。
- 评估变更的可能影响：变更的来源是多样的，既需要完成对客户可视的成果、交付期等变更操作，还需要完成对客户不可视的项目内部工作的变更，如实施方的人员分工、管理工作和资源配置等。
- 妥善保存变更产生的相关文档：确保其完整、及时、准确和清晰，适当时可以引入配置管理工具。
19.2.3 角色与职责565
规范的项目实施，提倡分权操作。项目经理是组织委托的项目经营过程负责者，其正式权利由项目章程取得，而资源调度的权力通常由基准中明确。基准中不包括的储备资源需经授权人批准后方可使用。项目经理在变更中的作用是：响应变更提出者的需求；评估变更对项目的影响及应对方案；将需求由技术要求转化为资源需求，供授权人决策；并据评审结果实施（即调整基准），确保项目基准反映项目实施情况。
信息系统项目中，除项目经理和CCB外，通常还会定义变更管理负责人、变更请求者、变更实施者和变更顾问委员会等。
- 变更管理负责人
变更管理负责人也称变更经理，通常是变更管理过程解决方案的负责人，其主要职责包括：
⓵负责整个变更过程方案的结果；
⓶负责变更管理过程的监控；
⓷负责协调相关的资源，保障所有变更按照预定过程顺利运作；
⓸确定变更类型，组织变更计划和日程安排；
⓹管理变更的日程安排；
⓺变更实施完成之后的回顾和关闭；
⓻承担变更相关责任，并且具有相应权限；
⓼可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。 - 变更请求者
变更请求者负责记录与提交变更请求单，具体为：
⓵提交初步的变更方案和计划；
⓶初步评价变更的风险和影响，给变更请求设定适当的变更类型；
⓷对理解变更过程有能力要求等。 - 变更实施者
变更实施者需要拥有有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变更任务。 - 变更顾问委员会
变更顾问委员会负责对重大变更行使审批，提供专业意见和辅助审批，具体为：
⓵在紧急变更时，其中被授权者行使审批权限；
⓶定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等。
19.2.4 工作程序566
- 变更申请
变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评估前应以书面形式提出。项目的干系人都可以提出变更申请，但一般情况下都需要经过指定人员进行审批，一般项目经理或者项目配置管理员负责该相关信息的收集，以及对变更申请的初审。 - 对变更的初审
变更初审的目的主要包括：
⓵对变更提出方施加影响，确认变更的必要性，确保变更是有价值的；
⓶格式校验，完整性校验，确保评估所需信息准备充分；
⓷在干系人间就提出供评估的变更信息达成共识等。
变更初审的常见方式为变更申请文档的审核流转。 - 变更方案论证
变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。常见的方案内容包括技术评估和经济与社会效益评估，前者评估需求如何转化为成果，后者评估变更方面的经济与社会价值和潜在的风险。对于一些大型的变更，可以召开相关的变更方案论证会议，通常需要由变更顾问委员会（相关技术和经济方面的专家组成）进行相关论证，并将相关专家意见作为项目变更方案的一部分，报项目CCB作为决策参考。 - 变更审查
变更审查过程是项目所有者根据变更申请及评估方案，决定是否变更项目基准。评审过程常包括客户、相关领域的专业人士等。审查通常采用文档、会签形式，重大的变更审查可以采用正式会议形式。
审查过程应注意分工，项目投资人虽有最终的决策权，但通常技术上并不专业。所以应当在评审过程中将专业评审、经济评审分开，对于涉及项目目标和交付成果的变更，客户和服务对象的意见应放在核心位置。 - 发出通知并实施
变更评审通过后，意味着基准的调整，同时确保变更方案中的资源需求及时到位。基准调整包括项目目标的确认，最终成果、工作内容和资源、进度计划的调整。需要强调的是：变更通知不只是包括项目实施基准的调整，更要明确项目的交付日期、成果对相关干系人的影响。如果变更造成交付期调整，应在变更确认时发布，而非在交付前公布。 - 实施监控
变更实施的监控，除了调整基准中涉及变更的内容外，还应当对项目的整体基准是否反映项目实施情况负责。通过监控行动，确保项目的整体实施工作是受控的。变更实施的过程监控，通常由项目经理负责基准的监控。CCB监控变更明确的主要成果、进度里程碑等，也可以通过监理单位完成监控。 - 效果评估
变更评估的关注内容主要包括：
⓵评估依据是项目的基准；
⓶结合变更的目标，评估变更所要达到的目的是否已达成；
⓷评估变更方案中的技术论证、经济论证内容与实施过程的差距，并促使解决。 - 变更收尾
变更收尾是判断发生变更后的项目是否已纳入正常轨道。配置基准调整后，需要确认资源配置是否及时到位，若涉及人员的调整，则需要更加关注。变更完成后对项目的整体监控应按新的基准进行。若涉及变更的项目范围及进度，则在变更后的紧邻监控中，应更多地关注、确认新的基准生效情况，及项目实施流程的正常使用情况。
19.2.5 变更控制567
由于变更的实际情况千差万别，可能简单，也可能相当复杂。越大型的项目，调整基准的边际成本越高，随意调整可能带来的后果众多，包括基准失效、项目干系人冲突、资源浪费、项目执行情况混乱等。在项目整体压力较大的情况下，更需强调变更的提出和处理应当规范化，可以使用分批处理、分优先级等方式提高效率。例如，在繁忙的交通道口，如果红绿灯变化频繁，其实不是灵活高效，而是整体通过能力的降低。
项目规模小、与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高效。但小项目的变更仍应注意对变更产生的因素施加影响（如防止不必要的变更，减少无谓的评估，提高必要变更的通过效率等），对变更的确认应当正式化，变更的操作过程应当规范化等。
变更管理虽然遵循一致的工作过程，但需要针对不同类型的变更，明确其控制要求。一般来说，项目的变更控制主要关注变更申请的控制及变更过程的控制。在变更过程控制中，需要对进度变更控制、成本变更控制和合同变更控制等进行重点关注，其他方面的变更控制需要结合具体变更的重点关注项，定义其控制要求。
- 变更申请的控制
由于变更的真实原因和提出背景复杂，如不经评估而快速实施则可能涉及的项目影响难以预料，而变更申请是变更管理流程的起点，故应严格控制变更申请的提交。变更控制的前提是项目基准健全，变更处理的流程事先共识。这里严格控制是指变更管理体系能确保项目基准能反映项目的实施情况。
变更申请的提交，首先应当确保覆盖所有变更操作，这意味着如果变更申请操作可以被绕过，那么变更申请的严格管理便毫无意义；但项目应根据变更的影响和代价提高变更流程的效率，并在某些情况下使用进度管理中的快速跟进等方法。例如，委托方和实施方高层管理者已共识的变更请求，在实施过程中应提高变更执行的效率。 - 变更过程控制
(1)对进度变更的控制。对进度变更的控制主要包括：
⓵判断项目进度的当前状态；
⓶对造成进度变化的因素施加影响；
⓷查明进度是否已经改变；
⓸在实际变化出现时对其进行管理。
(2)对成本变更的控制。对成本变更的控制主要包括：
⓵对造成费用基准变更的因素施加影响；
⓶确保变更请求获得同意；
⓷当变更发生时，管理这些实际的变更；
⓸保证潜在的费用超支不超过授权的项目阶段资金和总体资金；
⓹监督费用绩效，找出与费用基准的偏差；
⓺准确记录所有与费用基准的偏差；
⓻防止错误的、不恰当的或未批准的变更被纳入费用或资源使用报告中；
⓼就审定的变更，通知利害关系者；
⓽采取措施，将预期的费用超支控制在可接受的范围内；
⑩项目费用控制查找正、负偏差的原因。例如，若对费用偏差采取不适当的应对措施，就可能造成质量或进度问题，或在项目后期产生无法接受的巨大风险等。
(3)对合同变更的控制。合同变更控制是规定合同修改的过程，它包括文书工作、跟踪系统、争议解决程序以及批准变更所需的审批层次。合同变更控制应当与整体变更控制结合起来。
19.2.6 版本发布和回退计划568
对于很多信息系统开发项目来说，项目变更必须做相应的版本发布，并制定相应的应急回退方案。为确保版本发布的成功，在版本发布前应对每次版本发布进行管理，并做好发布失败后的回退方案。
版本发布前的准备工作包括：
⓵进行相关的回退分析：
⓶备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理；
⓷备份配置数据，包括数据备份的方式；也备份在线生产平台接口、应用、工作流等版本；
⓸启动回退机制的触发条件；
⓹对变更回退的机制职责的说明，如通知相关部门，确定需要回退的关联系统和回退时间点等。
为确保版本发布的成功，在版本发布前应对每次版本发布的风险进行相应的评估，对版本发布的过程检查单(Check list)做严格的评审。在评审发布内容时对存在风险的发布项做重点评估，确定相应的回退范围，制定相应的回退策略。回退步骤通常包括：
⓵通知相关用户系统开始回退；
⓶通知各关联系统进行版本回退；
⓷回退存储过程等数据对象；
⓸配置数据回退；
⓹应用程序、接口程序、工作流等版本回退；
⓺回退完成通知各周边关联系统；
⓻回退后进行相关测试，保证回退系统能够正常运行；
⓼通知用户回退完成等。
项目还需要对引起回退的原因进行深入分析、总结经验，避免下次回退发生。对执行回退计划中出现的问题进行分析，完善回退的管理。
19.3 项目文档管理569
信息系统相关信息（文档）是指某种数据媒体和其中所记录的数据。它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的东西。在软件工程中，文档常常用来表示对活动、需求、过程或结果进行描述，定义，规定，报告或认证的任何书面或图示的信息（包括纸质文档和电子文档）。
19.3.1 管理基础569
信息系统项目类型的不同，其文档分类的方法不同，不同的组织也会结合自身的管理实践，定义其文档类型。对于信息系统开发项目来说，其文档一般分开发文档、产品文档和管理文档。
(1)开发文档描述开发过程本身，基本的开发文档包括：可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明（包括程序和数据规格说明、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息等）。
(2)产品文档描述开发过程的产物，基本的产品文档包括：培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。
(3)管理文档记录项目管理的信息，例如：开发过程的每个阶段的进度和进度变更的记录；软件变更情况的记录；开发团队的职责定义、项目计划、项目阶段报告；配置管理计划。
文档的质量通常可以分为4级：
(1)最低限度文档(1级文档）：适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。
(2)内部文档(2级文档）：可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
(3)工作文档(3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
(4)正式文档(4级文档）：适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要4级文档。4级文档遵守GB/T 2006-8567《计算机软件文档编制规范》的有关规定。
19.3.2 规则和方法569
文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。
(1)文档书写规范。管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是哪种类型的文档都应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。例如，在程序的开始要用统一的格式包含程序名称、程序功能、调用和被调用的程序、程序设计人等。
(2)图表编号规则。在管理信息系统的开发过程中用到很多的图表，对这些图表进行有规则地编号，可以方便图表的查找。图表的编号一般采用分类结构。根据生命周期法的5个阶段，可以给出如图19-3所示的分类编号规则。根据该规则，就可以通过图表编号判断该图表出干系统开发周期的哪一个阶段属于哪一个文档，文档中的哪一部分内容及第几张图表。
(3)文档目录编写标准。为了存档及未来使用的方便，应该编写文档目录。管理信息系统的文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。文档编号一般为分类结构，可以采用同图表编号类似的编号规则。文档名称要书写完整、规范。格式或载体指的是原始单据或报表、磁盘文件、磁盘文件打印件、大型图表、重要文件原件、光盘存档等。
(4)文档管理制度。为了更好地进行信息系统文档的管理，应该建立相应的文档管理制度。文档的管理制度须根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等。建立文档的相关规范是指文档书写规范、图表编号规则和文档目录编写标准等。文档的借阅应该进行详细的记录，并且需要考虑借阅人是否有使用权限。在文档中存在商业秘密或技术秘密的情况下，还应注意保密。特别要注意的是，项目干系人签字确认后的文档要与相关联的电子文档一一对应，这些电子文档还应设置为只读。
19.4 本章练习570
- 选择题
(1)配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维待配置的___和___ A
A完整性可跟踪性 C.高效性可跟踪性 B完整性真实性 D高效性真实性
(2)负责在整个项目生命周期中进行配置管理的主要实施活动___。（D）
A.配置管理负责人 B.配置项负责人 C.项目经理 D．配置管理员
(3)若对配置项进行更改，配置项状态为___。当配置项修改完毕并重新通过评审时，其状态变为___。A
A.修改 正式 B.草稿 正式 C草稿 修改 D．正式 草稿
(4)配置管理的日常管理活动主要包括：制订配置管理计划、配置项识别、配置项控制、配置状态报告、___、配置管理回顾与改进等。（）
A.配置审计 B.配置变更 c．配置项重新定义 D．配置管理
(5)对于大型的变更，可以召开相关的变更方案论证会议，通常需要由（相关技术和经济方面的专家组成）进行相关论证。C
A.变更控制委员会CCB B变更实施委员会 C变更顾问委员会 D．配置管理委员会
(6)对于信息系统开发项目来说，其文档一般分为开发文档、产品文档和___。（A）
A.管理文档 B．应用文档 C.指南文档 D．规范文档
(7)对于信息系统开发项目来说，参考手册和用户指南属于___。D
A.规划文档 B.开发文档 C.配置文档 D.产品文档
2.判断题
判断下列表述正误，正确的选✅错误的选X。
(1)配置项是信息系统组件或与其有关的项目，包括软件和各种文档，不包括硬件。 （ X ）
(2)合同变更控制是规定合同修改的过程，合同变更控制应当单独执行，不要与整体变更控制结合起来。 （X）
(3)变更管理虽然遵循一致的工作过程，但需要针对不同类型的变更，明确其不同的控制要求。（ ✅）
1225
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
