持续更新。。。。。。。。。。。。。。。

引言：希望这篇文章能够成为参加软考考生的灯塔

根据考纲要求,本章内容考试以选择题为主，但是关于配置管理、变更管理部分也会涉及到一些案例分析考点。。

15.1信息和文档管理

15.1.1 信息和文档

1.信息系统信息-P546

信息系统中的信息可以分为用户信息、业务信息、经营管理信息和系统运行信息等。

2.信息系统文档-P546

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

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

15.1.2 信息(文档)管理规则和方法

1.信息(文档)编制规范-P547

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

2.信息(文档)定级保护-P548

应根据侵害可能影响对象和影响程度，对信息系统项目的信息(文档)进行分析并定级，按相应的定级保护策略进行管理。

(1)根据项目干系人和项目价值目标的识别，影响对象主要包括:

• 个人、法人和其他组织的合法权益和经济利益;
• 社会秩序、公共利益;
• 国家安全。

(2)对影响对象的侵害影响程度，归结为:

• 无影响;
• 造成一般损害;
• 造成严重损害;
• 造成特别严重损害。

基于以上定级方法，组织可以将项目信息(文档)，结合自身业务的特点来定义分级标准，并建立相应的分级管理策略。针对文件的编制、审批、存储、分发、使用、变更、销毁等方面，在文档管理制度中提出相应的管理要求。特别要注意的是，在项目应用时，应结合客户要求和合同要求，建立项目信息(文档)管理策略。文档中有密级要求的，应注意保密和权限管理。项目千系人签字确认后的文档要与相关联的电子文档一 一对应，这些电子文档还应设置为只读。项目人员须谨慎地处理项目信息资产，以防擅自披露(如在网络上传共享、传递给其他客户)、丢失或被盗。依照分配的职责或项目干系人授权范围，在需要知情的基础上只使用可得到的信息。

3.信息(文档)配置管理-P549

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

在组织实施信息系统项目过程中，常常会遇到变更的发生。变更一般有主动变更和被动变更两种。

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

练习

15.2配置管理

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

15.2.1 基本概念

1.配置项(Configuration ltem, Cl)-P549

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

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

例如在信息系统的开发项目中须加以控制的配置项可以分为基线配置项和非基线配置项两类，基线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由配置管理员严格管理，基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向项目经理、CCB及相关人员开放。

2.配置项状态-P550

配置项的状态需要根据配置项的不同类型和管理需求进行分别定义，如基于配置项建设过程阶段视角，可将状态分为“草“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置稿”项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。配置项状态变化如图所示。

3.配置项版本号-P550

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

①处于“草稿”状态的配置项的版本号格式为0.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值设置为0，增加X.Y值。参见上述规则②。

4.配置项版本管理-P550

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

5.配置基线-P551

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

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

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

对于每一条基线，要定义下列内容:建立基线的事件、受控的配置项、建立和变更基线的程序和批准变更基线所需的权限。在项目实施过程中，每条基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。

建立基线的价值可包括:

• 基线为项目工作提供了一个定点和快照;
• 新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目(在主要分支上)所进行的变更进行隔离;
• 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法;
• 可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。

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

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

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

7.配置库-P552

针对信息系统开发类型的项目，我们常使用配置库(Configuration Library)存放配置项并记录与配置项相关的所有信息，它是配置管理的有力工具。利用库中的信息可回答许多配置管理的问题，例如:

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

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

• 开发库:也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如新模块、文档、数据元素或进行修改的已有元素。动态库中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其进行配置控制，因为这通常不会影响到项目的其他部分。
• 受控库:也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
• 产品库:也称为静态库、发行库、软件仓库，包含己发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。

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

• 按配置项的类型分类建库:适用于通用软件的开发组织。在这样的组织内，产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
• 按开发任务建立相应的配置库:适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。

15.2.2 角色与职责

配置管理相关的角色常包括:配置控制委员会(CCB)、·配置管理负责人·、·配置管理员·和·配置项负责人·

15.2.3 日标与方针

1.管理目标-P554

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

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

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

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

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

2.管理方针-P555

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

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

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

15.2.4 管理活动

配置管理的日常管理活动主要包括: 制订配置管理计划、配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾与改进等。

1.制订配置管理计划-P555

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

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

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

2.配置项识别-P556

配置项识别是针对所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构进行识别的过程。它包括为配置项分配标识和版本号等。

配置项识别是配置管理员的职能。

配置项识别的基本步骤如下:
(1)识别需要受控的配置项;
(2)为每个配置项指定唯一的标识号;
(3)定义每个配置项的重要特征;
(4)确定每个配置项的所有者及其责任;
(5)确定配置项进入配置管理的时间和条件;
(6)建立和控制基线;
(7)维护文档和组件的修订与产品版本之间的关系。

每个配置项可以通过自身的字符、拷贝号/序列号和版本号等标识唯一识别。注意:拷贝号/序列号和版本号等详细信息应记录在配置库或配置管理数据库中，但不一定作为标识的一部分。版本号用于识别出哪些变化的版本属于同一配置项。同一配置项的不同版本可以在同一时刻共存。

3.配置项控制-P556

配置控制即配置项和基线的变更控制，包括变更申请、变更评估、通告评估结果、变更实施、变更验证与确认、变更的发布和基于配置库的变更控制等任务。

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

• 变更对项目的影响;
• 变更的内容是否必要;
• 变更的范围是否考虑周全;
• 变更的实施方案是否可行;
• 变更工作量估计是否合理。
  CCB决定是否接受变更，并将决定通知相关人员。
  (3)通告评估结果。
  CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。如果变更申请得到批准，应该及时把变更批准信息和变更实施方案通知那些正在使用受影响的配置项和基线的干系人。如果变更申请被否决，应
  通知有关干系人放弃该变更申请。
  (4)变更实施。
  经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息。

(5)变更验证与确认。
项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交CCB，由其确认变更是否已经按要求完成。
(6)变更的发布。
配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员，并做好记录。
(7)基于配置库的变更控制。
在信息系统开发项目中，一处出现了变更，经常会连锁引起多处变更，会涉及参与开发工作的许多人员。例如，测试引发了需求的修改，那么很可能要涉及需求规格说明、概要设计、详细设计和代码等相关文档，甚至会使测试计划随之变更。

现以某软件产品升级为例，其过程简述为:
(1)将待升级的基线(假设版本号为V2.1)从产品库中取出，放入受控库。
(2)程序员将欲修改的代码段从受控库中检出(Checkout)，放入自己的开发库中进行修改。代码被检出后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正在对其修改，乙就无法将其检出。
(3)程序员将开发库中修改好的代码段检入(Checkin)受控库。代码检入后，代码的“锁定”被解除，其他程序员就可以检出该段代码了。
(4)软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品的版本号更新为V2.2，旧的V2.1版并不删除，继续在产品库中保持）。

4.配置状态报告-P557

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

• 每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
• 每个变更申请的状态和已批准的修改的实施状态。
• 每个基线的当前和过去版本的状态以及各版本的比较。
• 其他配置管理过程活动的记录等。

5.配置审计-P558

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

例如:

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

配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计。
(1)功能配置审计
功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求一致)，具体验证主要包括:
配置项的开发已圆满完成;
配置项已达到配置标识中规定的性能和功能特征;
配置项的操作和支持文档已完成并且符合要求等。
(2)物理配置审计
物理配置审计是指审计配置项的完整性(配置项的物理存在是否与预期一致)，具体验证主要包括:·要交付的配置项是否存在;
配置项中是否包含了所有必需的项目等。

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

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

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

6.配置管理回顾与改进-P559

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

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

练习

15.3变更管理

15.3.1 基本概念

1.项目变更的含义-P559

项目变更是指在信息系统项目的实施过程中，由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法和项目进度等方面做出的改变。项目管理方法的基本原理，是将特定的目标通过规范的计划过程，转化为基准共识之后以指导项目执行，同时作为项目有效监控、收尾的依据。变更管理，即是为使项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法。其可能的结果是拒绝变化，或是调整项目基准。·更管理的实质是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。

2.变更产生的原因-P559

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

变更的常见原因包括:

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

3.变更分类-P560

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

• 根据变更性质可分为重大变更、重要变更和一般变更，可通过不同审批权限来控制;
• 根据变更的迫切性可分为紧急变更、非紧急变更;
• 根据行业特征进行的变更，如弱电工程行业的常见分类方法为产品(工作)范围变更、环境变更、设计变更、实施变更和技术标准变更。

4.变更管理原则-P560

变更管理的原则是项目基准化、变更管理过程规范化。

变更管理的主要内容包括:基准管理、变更控制流程化、明确组织分与于系人充分沟通、变更的及时性、评估变更的可能影响、妥善保存变更产生的相关文档等。

5.变更管理与相关活动的关系-P560

(1)变更管理与项目整合管理的关系

变更管理是项目整合管理的一部分，实施整体变更控制过程贯穿项目始终。实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。一旦确定了项目基准，就必须通过变更管理来处理变更请求。变更请求可能影响项目范围、产品范围以及项目管理计划组件或任一项目文件，应确保对变更请求做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。变更控制的实施程度，取决于项目所在应用领域、项目复杂程度、合同要求，以及项目所处的背景与环境。

在批准变更之前，需要了解变更对进度、成本、质量、资源等多方面的影响。变更请求得到批准后，可能需要更新成本估算.活动排序、进度日期、资源需求和风险应对方案分析等，这些变更可能要求调整项目管理计划和其他项目文件。

2)变更管理与配置管理的关系

项目的配置管理计划应规定哪些项目组件受控于配置控制程序。对配置项的任何变更都应该提出变更请求，并经过变更控制。配置管理重点关注可交付产品(包括中间产品)及各过程文档，而变更管理则着眼于识别、记录、批准或否决对项目文件、可交付产品或基准的变更。

变更管理过程中包含的部分配置管理活动如下。

• 配置项识别:识别与选择配置项，从而为核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
• 配置状态记录:为了能及时提供关于配置项的准确数据，应记录和报告配置项的相关信息。此类信息包括变更控制中的已批准的配置项清单、变更申请的状态和已批准变更的实施状态。
• 配置确认与审计:通过配置确认与配置审计，可确保项目各配置组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。

15.3.2 角色与职责

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

通常情况下，项目经理在变更中的作用`是，响应变更提出者的需求，评估变更对项目的影响及应对方案，将需求由技术要求转化为资源要求，供授权人决策。依据变更评审结果调整基准，确保项目基准反映项目实施情况，并监控变更及已批准的变更正确实施。

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

15.3.3 工作程序

1.变更申请-P562

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

2.对变更的初审-P562

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

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

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

3.变更方案论证-P563

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

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

4.变更审查-P563

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

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

5.发出通知并实施-P563

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

6.实施监控-P563

变更实施的监控，除了调整基准中涉及变更的内容外，还应当对项目的整体基准是否反映项目实施情况负责。通过监控行动,确保项目的整体实施工作是受控的。变更实施的过程监控，通常由项目经理负责基准的监控。CCB监控变更的主要成果、进度里程碑等，也可以通过监理单位完成监控。通过对变更实施的监控，确认变更是否正确完成，对于正确完成的变更，需按配置管理计划中定义的配置控制范围，纳入配置管理系统中。

7.效果评估-P563

变更评估的关注内容主要包括:

• 评估依据是项目的基准;
• 结合变更的初衷来看，变更所要达到的目的是否已达成;
• 评估变更方案中的技术论证、经济论证内容与实施过程的差距并促发解决。

8.变更收尾-P564

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

15.3.4 变更控制

由于变更的实际情况千差万别，可能简单，也可能相当复杂。越是大型的项目，调整基准的边际成本越高，随意的调整可能带来的后果也越多，包括基准失效、项目干系人冲突、资源浪费、项目执行情况混乱等。项目规模小，与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高效，但关于小项目变更仍应注意对变更产生的因素施加影响(如防止不必要的变更咸少无谓的评估，提高必要变更的通过效率等)，对变更的确认应当正式化，变更的操作过程应当规范化等。

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

1.变更申请的控制-P564

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

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

2.变更内容的控制-P564

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

• 判断当前项目进度的状态!
• 对造成进度变化的因素施加影响;
• 查明进度是否已经改变;
• 在实际变化出现时对其进行管理。
  (2)对成本变更的控制主要包括:
• 对造成费用基准变更的因素施加影响;
• 确保变更请求获得同意;
• 当变更发生时，管理这些实际的变更;
• 保证潜在的费用超支不超过授权的项目阶段资金和总体资金;
• 监督项目费用绩效，找出与费用基准的偏差;
• 准确记录所有的与费用基准的偏差;
• 防止错误的、不恰当的或未批准的变更被纳入费用或资源使用报告中;
• 就审定的变更，通知利害关系者;
• 采取措施，将预期的费用超支控制在可接受的范围内;
• 控制项目费用，查找造成正、负偏差的原因。例如，若对费用偏差采取不适当的应对措施，就可能造成质量或进度问题，或在项后期产生无法接受的巨大风险等。
  (3)对合同变更的控制
• 合同变更控制是规定合同修改的过程，它包括文书工作、跟踪系统、争议解决程序以及批准变更所需的审批层次。合同变更控制应当与整体变更控制结合起来。

3.变更类型的控制-P565

1)标准变更的控制

标准变更通常是低风险、预先授权的变更，这类变更已得到充分理解和完整记录，并且可以在不需要额外授权的情况下实现。它们通常作为服务请求发起，但也可以是操作改变。当创建或修改标准变更时，对于任何其他变更，应进行全面的风险评估和授权。此风险评估不需要在每次实施标准变更时重复，只有在对此类执行方式修改时进行评估。
2)正常变更的控制

正常变更通常是常规的、较低风险的变更，依据15.3.3节的工作程序，通过已确定的变更授权角色和变更管理流程进行管理。组织可通过使用自动化来提高变更效率，使用连续集成和连续部署的自动化管道控制大部分变更控制过程。
3)紧急变更的控制

紧急变更通常不包括在变更计划中，必须快速响应，尽快实施，例如业务中断故障或事故、安全攻击等。处理紧急变更的程序在需要时可以精简，遇到紧急变化时和决策权限变更时可以临时调整，如少数了解业务风险的高级管理人员和重要干系人的决策权发生变化时。在考虑到规避问题复杂化的风险的同时，尽可能迅速地进行变更，尽可能接受相同的测试，但有些情况下，更全面的测试和调整可能会在实现之后持续一段时间再进行。

4.变更输入输出的控制-P565

(1)变更输入的控制主要包括:

• 项目控制变更的基准、项目计划、配置管理计划、项目文件和组织过程资产等;
• 变更前的项目工作绩效报告;
• 提出的变更请求和变更方案等。
  (2)变更输出的控制主要包括:
• 批准的变更请求
• 更新的项目基准，更新的项目计划、配置管理计划、项目文件和变更日志等:
• 变更后的项目工作绩效报告，对比变更执行效果;
• 共享经验教训，如偏差产生的原因，已采取的行动措施，以及所吸取的经验教训，使其成为本项目和实施组织内其他项目历史数据的组成部分。

15.3.5 版本发布和回退计划

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

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

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

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

回退步骤通常包括:

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

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

本周练习

(1)项目变更管理的实质是()
A.不断调整项目努力方向和资源配置，提升项目价值
B.前期项目管理者的粗心
C.项目推进过程中甲方提出越来越多的需求
D.最大程度地满足甲方的需求
答案:B
解析:《系统集成项目管理工程师教程》第三版P559，变更管理的实质，是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。

(2)项目变更的常见原因一般不包括()
A.项目范围(工作)定义的过失或者疏忽
B.应对风险的紧急计划，但不包括回避计划
C.项目执行过程与基准要求不一致带来的被动调整
D.外部灾害天气,
答案:B
解析:《系统集成项目管理工程师教程》第三版P559，变更的常见原因包括:产品范围(成果)定义的过失或者疏忽;项目范围(工作)定义的过失或者疏忽;增值变更;应对风险的紧急计划或回避计划;项目执行过程与基准要求不一致带来的被动调整;外部事件等。

(3)项目变更的依据是()
A.干系人的需求
B.甲方的要求
C.项目基准
D.项目成员的请求
答案:C
答案:略

(4)软件版本发布前的准备工作一般不包括()
A.备份版本发布所涉及的存储过程
B.启动回退机制的触发条件
C.系统应急方案
D.进行相关的回退分析
答案:C
解析:《系统集成项目管理工程师教程》第三版P566，版本发布前的准备工作包括
进行相关的回退分析;
备份版本发布所涉及的存储过程函数等其数据的存储及回退管理
备份配置数据，包括数据备份的方式;
备份在线生产平台接口、应用和工作流等版本
启动回退机制的触发条件
对变更回退的机制职责的说明，如通知相关部，确定需要回退的关联系统和回退时间点等。

(5)在项目的实施阶段，当客户明确提出某项需求更改时，项目经理应该(.
A.与客户方领导进行沟通，尽量劝说其不要更改需求
B.先评估变更会对项目带来怎样的影响，然后再与客户协商解决措施
C.接受客户的变更请求，启动变更控制流程，遵循变更流程进行更改
D.汇报给高层领导，由领导决定
答案:B
解析:先评估变更会对项目带来怎样的影响。

(6)关于变更的流程和规则的做法中，错误的是()
A.以口头方式提出某项变更，在评估前针对该变更提交了书面报告
B.项目组成员变更以邮件发出，在评审前填写了变更申请
C.为了规范，监理不对变更进行分级，所有变更流程都不能简化
D.按照影响范围、紧急程度把变更分为3个优先级别
答案:C
解析:《系统集成项目管理工程师教程》第三版P564，项目规模小，与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高效，但关于小项目变更仍应注意对变更产生的因素施加影响(如防止不必要的变更，减少无谓的评估，提高必要变更的通过效率等)，对变更的确认应当正式化，变更的操作过程应当规范化等。

(7)在对一项任务的检查中，项目经理发现一个团队成员正在用与WBS字典规定不符的方法来完成这项工作。项目经理应首先 ()
A.告诉这名团队成员采取纠正措施
B.确定这种方法对职能经理而言是否尚可接受
C.问这名团队成员，这种变化是否必要
D.确定这种变化是否改变了工作包的范围
答案:D
解析:先确定是不是属于项目范围，在确定方法问题。

(8)某项目已制定了详细的范围说明书，并完成了 WBS分解。在项目执行过程中，项目经理在进行下一周工作安排的时候，发现WBS中遗漏了一项重要的工作，那么接下来他应该首先()
A.组织项目组讨论，修改WBS
B.修改项目管理计划，并重新评审
C.汇报给客户，与其沟通，重新编写项目文档
D.填写项目变更申请，对产生的工作量进行估算，等待变更委员会审批
答案:D
解析:在执行过程中，一般来说已经确定基准，如果变更，需要进行遵循正式变更控制流程。

(9)变更管理首要完成的任务是()
A.分析变更的必要性和合理性，确认是否实施变更
B.记录变更信息、填写变更控制单
C.做出变更，并交上级审批
D.修改相应的软件配置项(基线)，确立新的版本
答案:A
答案:略

(10)在进行项目整体变更控制过程中，首先要受理变更申请，接下来()
A.接受或拒绝变更
B.执行变更
C.进行变更结果追踪与审核
D.进行变更的整体影响分析
答案:D
答案:略

内容	地址 链接
总览	【第三版】系统集成项目管理工程
十五至尊图	第三版
上一章	第14章 收尾过程组
下一章	第16 章 监理基础知识

👊如果你对该系列文章有兴趣的话，欢迎持续关注博主动态，博主会持续输出优质内容👊

 

👊 博主很需要大家的支持，你的支持是我创作的不竭动力👊

 

👊 ~ 点赞收藏＋关注 ~👊

版本记录：

• 2024年10月 5第一版