十九、配置与变更管理
十九、配置与变更管理
Hunter内容来源：信息系统项目管理师教程 (第4版）
文章内容主要为第4版教程的核心重点内容。
19.1 配置管理
配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整 性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。在（GB/T11457）《信息技术 软件工程术语》中，将“配置管理”正式定义为：“应用技术的和管理的指导和监控方法以标识 和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验 证与规定的需求的遵循性”
19.1.1 管理基础
- 配置项（Configuration Item，CI）
比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可 执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等，它们经评审和检查通过后进入配置管理。所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在 CMDB中。例如，在信息系统的开发项目中需加以控制的配置项可以分为基线配置项和非基线 配置项两类，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的 各类计划和报告等。所有配置项的操作权限应由配置管理员严格管理，基本原则是：基线配置 项向开发人员开放读取的权限；非基线配置项向项目经理、CCB及相关人员开放。
- 配置项状态
配置项的状态需要根据配置项的不同类型和管理需求进行分别定义，基于配置项建设过程 角度，可将配置项状态分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草 稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改” 当配置项修改完毕并重新通过评审时，其状态又变为“正式”。
配置项状态变化如图19-1所示。
- 配置项版本号
配置项的版本号规则与配置项的状态定义相关。例如：①处于“草稿”状态的配置项的版 本号格式为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值。参见上述 规则②
- 配置项版本管理
配置项的版本管理作用于多个配置管理活动之中，如配置标识、配置控制和配置审计、发 布和交付等。例如，在信息系统开发项目过程中，绝大部分的配置项都要经过多次的修改才能 最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版 本“好”,所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避 免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
- 配置基线
配置基线由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。配置基线也是指 一个产品或系统在某一特定时刻的配置状况。
基线中的配置项被“冻结”了，不能再被任 何人随意修改。对基线的变更必须遵循正式的变更控制程序。
产品的一 个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行 代码、测试大纲、测试用例和使用手册等）也是基线的例子。
基线通常对应于项目过程中的里程碑（Milestone）,一个项目可以有多个基线，也可以只有 一个基线。交付给用户使用的基线一般称为发行基线（Release）,内部过程使用的基线一般称 为构造基线（Build）。
- 配置管理数据库
我们常使用配置管理数据库来管理配置项，它是指包含每个配置项及配置项之间重要关系 的详细资料的数据库。对于信息系统开发项目来说，常使用配置库实施配置数据的管理。
- 配置库
配置库可以分开发库、受控库、 产品库3种类型。
（1）开发库。开发库也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发 的配置实体，如新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本 管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频 繁的修改，只要开发库的使用者认为有必要，无须对其进行配置控制，因为这通常不会影响到 项目的其他部分。
（2）受控库。受控库也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置 于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
（3）产品库。产品库也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存 档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存 入产品库内，等待交付用户或现场安装。
19.1.2 角色与职责
配置管理相关角色常包括：变更控制委员会（Change Control Board,CCB）、配置管理负责 人、配置管理员和配置项负责人等。
- 配置管理负责人
配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动，具体有：①管理所有活动，包括计划、识别、控制、审计和回顾；②负责配置管理过程；③通过审计过 程确保配置管理数据库的准确和真实；④审批配置库或配置管理数据库的结构性变更；⑤定义 配置项责任人；⑥指派配置审计员；⑦定义配置管理数据库范围、配置项属性、配置项之间关 系和配置项状态；⑧评估配置管理过程并持续改进；⑨参与变更管理过程评估；⑩对项目成员 进行配置管理培训。
- 配置管理员
配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动，具体有：①建立和 维护配置管理系统：②建立和维护配置库或配置管理数据库；③配置项识别；④建立和管理基 线；⑤版本管理和配置控制；⑥配置状态报告；⑦配置审计；⑧发布管理和交付。
- 配置项负责人
配置项负责人确保所负责的配置项的准确和真实：①记录所负责配置项的所有变更；②维 护配置项之间的关系；③调查审计中发现的配置项差异，完成差异报告；④遵从配置管理过程； ⑤参与配置管理过程评估。
19.1.3 目标与方针
- 管理目标
- 管理方针
19.1.4 管理活动
配置管理的日常管理活动主要包括：制订配置管理计划、配置项识别、配置项控制、配置 状态报告、配置审计、配置管理回顾与改进等。
- 制订配置管理计划
配置管理计划是对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文 件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。
- 配置项识别
配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结 构识别。它包括为配置项分配标识和版本号等。配置项识别是配置管理的一项基础性工作，要 确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。
（1）确定配置项范围。
（2）确认和记录配置项属性。
（3）为配置项定义标识符。
（4）确定配置基准线。
（5）确定配置结构。
（6）确定配置项命名规则。
- 配置项控制
配置项控制即对配置项和基线的变更控制，包括：标识和记录变更申请、分析和评价变更、 批准或否决申请、实现、验证和发布已修改的配置项等任务。
（1）变更申请。变更申请主要就是陈述要做什么变更，为什么要变更，以及打算怎样变更。 相关人员（如项目经理）填写变更申请表，说明要变更的内容、变更原因、受变更影响的关联 配置项和有关基线、变更实施方案、工作量和变更实施人等，提交给CCB。
（2）变更评估。CCB负责组织对变更申请进行评估并确定：①变更对项目的影响；②变更的内容是否必要；③变更的范围是否考虑周全；④变更的实施方案是否可行；⑤变更工作量估 计是否合理。CCB决定是否接受变更，并将决定通知相关人员。
（3）通告评估结果。CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意 见影响的每个干系人。如果变更申请得到批准，应该及时把变更批准信息和变更实施方案通知 给那些正在使用受影响的配置项和基线的干系人。如果变更申请被否决，应通知有关干系人放 弃该变更申请。
（4）变更实施。项目经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理 数据中记录变更信息。
（5）变更验证与确认。项目经理指定人员对变更后的配置项进行测试或验证。项目经理应 将变更与验证的结果提交给CCB,由其确认变更是否已经按要求完成。
（6）变更的发布。配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果 通知相关人员，并做好记录。
（7）基于配置库的变更控制。
现以某软件产品升级为例，其过程简述为：
（1）将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库。
（2）程序员将欲修改的代码段从受控库中检出（Check out）,放入自己的开发库中进行修 改。代码被检出后即被“锁定”,以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out。
（3）程序员将开发库中修改好的代码段检入（Check in）受控库。检入后，代码的“锁定” 被解除，其他程序员可以Check out该段代码了。
（4）软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品 的版本号更新为V2.2,旧的V2.1版并不删除，继续在产品库中保存）。
- 配置状态报告
配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目 的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。
- 配置审计
配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当 前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置 管理的最根本要求，不允许出现任何混乱现象：①防止向用户提交不适合的产品，如交付了用 户手册的不正确版本；②发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实 施变更；③找出各配置项间不匹配或不相容的现象；④确认配置项已在所要求的质量控制审核 之后纳入基线并入库保存：⑤确认记录和文档保持着可追溯性等。
（1）功能配置审计。功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需 求一致）,具体验证主要包括：①配置项的开发已圆满完成；②配置项已达到配置标识中规定的 性能和功能特征；③配置项的操作和支持文档已完成并且是符合要求的等。
（2）物理配置审计。物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一 致）,具体验证主要包括：①要交付的配置项是否存在；②配置项中是否包含了所有必需的项目等。
- 配置管理回顾与改进
配置管理回顾与改进即定期回顾配置管理活动的实施情况，发现在配置管理执行过程中有 无问题，找到改进点，继而优化配置管理过程。
19.2 变更管理
19.2.1 管理基础
- 变更管理与配置管理
- 变更产生的原因
变更的常见原因包括：①产品范围（成果）定义 的过失或者疏忽；②项目范围（工作）定义的过失或者疏忽；③增值变更；④应对风险的紧急 计划或回避计划；⑤项目执行过程与基准要求不一致带来的被动调整；⑥外部事件等。
- 变更的分类
常来说， 根据变更性质可分为重大变更、重要变更和一般变更，通过不同审批权限进行控制；根据变更 的迫切性可分为紧急变更、非紧急变更
- 项目变更的含义
变更管理是为使得项目基准与项目实际 执行情况相一致，应对项目变化的一套管理方法。其可能的两个结果是拒绝变化，或是调整项 目基准。
19.2.2 管理原则
- 基准管理
- 变更控制流程化
- 明确组织分工
- 评估变更的可能影响
- 妥善保存变更产生的相关文档
19.2.3 角色与职责
规范的项目实施，提倡分权操作。项目经理是组织委托的项目经营过程负责者，其正式权 利由项目章程取得，而资源调度的权力通常由基准中明确。基准中不包括的储备资源需经授权 人批准后方可使用。项目经理在变更中的作用是：响应变更提出者的需求；评估变更对项目的 影响及应对方案；将需求由技术要求转化为资源需求，供授权人决策；并据评审结果实施（即 调整基准）,确保项目基准反映项目实施情况。
信息系统项目中，除项目经理和CCB外，通常还会定义变更管理负责人、变更请求者、变 更实施者和变更顾问委员会等。
- 变更管理负责人
变更管理负责人也称变更经理，通常是变更管理过程解决方案的负责人，其主要职责包括：①负责整个变更过程方案的结果；②负责变更管理过程的监控；③负责协调相关的资源，保障 所有变更按照预定过程顺利运作；④确定变更类型，组织变更计划和日程安排；⑤管理变更的 日程安排；⑥变更实施完成之后的回顾和关闭；⑦承担变更相关责任，并且具有相应权限；⑧可 能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。
- 变更请求者
变更请求者负责记录与提交变更请求单，具体为：①提交初步的变更方案和计划：②初步 评价变更的风险和影响，给变更请求设定适当的变更类型；③对理解变更过程有能力要求等。
- 变更实施者
变更实施者需要拥有有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变 更任务。
- 变更顾问委员会
变更顾问委员会负责对重大变更行使审批，提供专业意见和辅助审批，具体为：①在紧急 变更时，其中被授权者行使审批权限；②定期听取变更经理汇报，评估变更管理执行情况，必 要时提出改进建议等。
19.2.4 工作程序
- 变更申请
变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评 估前应以书面形式提出。项目的干系人都可以提出变更申请，但一般情况下都需要经过指定人员 进行审批，一般项目经理或者项目配置管理员负责该相关信息的收集，以及对变更申请的初审。
- 对变更的初审
变更初审的目的主要包括：①对变更提出方施加影响，确认变更的必要性，确保变更是有 价值的；②格式校验，完整性校验，确保评估所需信息准备充分；③在干系人间就提出供评估 的变更信息达成共识等。
变更初审的常见方式为变更申请文档的审核流转。
- 变更方案论证
变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更 请求由技术要求转化为资源需求，以供CCB决策。常见的方案内容包括技术评估和经济与社会 效益评估，前者评估需求如何转化为成果，后者评估变更方面的经济与社会价值和潜在的风险。
对于一些大型的变更，可以召开相关的变更方案论证会议，通常需要由变更顾问委员会 （相关技术和经济方面的专家组成）进行相关论证，并将相关专家意见作为项目变更方案的一部 分，报项目CCB作为决策参考。
- 变更审查
变更审查过程是项目所有者根据变更申请及评估方案，决定是否变更项目基准。评审过程常包括客户、相关领域的专业人士等。审查通常采用文档、会签形式，重大的变更审查可以采 用正式会议形式。
审查过程应注意分工，项目投资人虽有最终的决策权，但通常技术上并不专业。所以应当 在评审过程中将专业评审、经济评审分开，对于涉及项目目标和交付成果的变更，客户和服务 对象的意见应放在核心位置。
- 发出通知并实施
变更评审通过后，意味着基准的调整，同时确保变更方案中的资源需求及时到位。基准调 整包括项目目标的确认，最终成果、工作内容和资源、进度计划的调整。需要强调的是：变更 通知不只是包括项目实施基准的调整，更要明确项目的交付日期、成果对相关干系人的影响。 如果变更造成交付期调整，应在变更确认时发布，而非在交付前公布。
- 实施监控
变更实施的监控，除了调整基准中涉及变更的内容外，还应当对项目的整体基准是否反映 项目实施情况负责。通过监控行动，确保项目的整体实施工作是受控的。变更实施的过程监控， 通常由项目经理负责基准的监控。CCB监控变更明确的主要成果、进度里程碑等，也可以通过 监理单位完成监控。
- 效果评估
变更评估的关注内容主要包括：①评估依据是项目的基准；②结合变更的目标，评估变更 所要达到的目的是否已达成；③评估变更方案中的技术论证、经济论证内容与实施过程的差距， 并促使解决。
- 变更收尾
变更收尾是判断发生变更后的项目是否已纳入正常轨道。配置基准调整后，需要确认资源 配置是否及时到位，若涉及人员的调整，则需要更加关注。变更完成后对项目的整体监控应按 新的基准进行。若涉及变更的项目范围及进度，则在变更后的紧邻监控中，应更多地关注、确 认新的基准生效情况，及项目实施流程的正常使用情况。
19.2.5 变更控制
在项目整体压力较大的情况下，更需强调变更的提出和处理应当规范化， 可以使用分批处理、分优先级等方式提高效率。
项目规模小、与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高 效。但小项目的变更仍应注意对变更产生的因素施加影响（如防止不必要的变更，减少无谓的评 估，提高必要变更的通过效率等）,对变更的确认应当正式化，变更的操作过程应当规范化等。
- 变更申请的控制
应严格控制变更申请的提交。
- 变更过程控制
19.2.6 版本发布和回退计划
对于很多信息系统开发项目来说，项目变更必须做相应的版本发布，并制定相应的应急回 退方案。为确保版本发布的成功，在版本发布前应对每次版本发布进行管理，并做好发布失败 后的回退方案。
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）文档管理制度。为了更好地进行信息系统文档的管理，应该建立相应的文档管理制度。 文档的管理制度须根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记 录的登记制度、文档使用权限控制规则等。建立文档的相关规范是指文档书写规范、图表编号 规则和文档目录编写标准等。文档的借阅应该进行详细的记录，并且需要考虑借阅人是否有使 用权限。在文档中存在商业秘密或技术秘密的情况下，还应注意保密。特别要注意的是，项目 干系人签字确认后的文档要与相关联的电子文档一一对应，这些电子文档还应设置为只读。
