【信息系统项目管理师】复习~第十九章

19.配置于变更管理

1. 定义：配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。配置管理包含配置库的建立和配置管理数据库(Configuration Management Databases,CMDB)准确性的维护，以支持信息系统项目的正常运行。强调配置项与真实情况的匹配度和详细度。

配置项是信息系统组件或与其有关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等。所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在CMDB中。

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

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

4.配置项的状态可分为“草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿“。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。注：状态为“草稿”的配置项，修改未通过评审前，状态仍为“草稿”。

5.配置项版本号

6.版本管理：因不能保证新版本一定比旧版本“好”,所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

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

对基线的变更必须遵循正式的变更控制程序。例如，一组拥有唯一标识号的需求、设计、源代码文档以及相应的可执行代码、构造文档和用户文档构成一条基线。产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例和使用手册等)也是基线的例子。基线通常对应于项目过程中的里程碑(Milestone),一个项目可以有多个基线，也可以只有一个基线。交付给用户使用的基线一般称为发行基线(Release),内部过程使用的基线一般称为构造基线(Build)。

8.配置基线的内容：

①建立基线的事件；②受控的配置项；③建立和变更基线的程序；④批准变更基线所需的权限。

9.建立基线的价值可包括：

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

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

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

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

10.配置管理数据库是指包含每个配置项及配置项之间重要关系的详细资料的数据库。配置管理数据库主要内容包括：

①发布内容，包括每个配置项及其版本号；

②经批准的变更可能影响到的配置项；

③与某个配置项有关的所有变更请求；

④配置项变更轨迹；

⑤特定的设备和软件；

⑥计划升级、替换或弃用的配置项；

⑦与配置项有关的变更和问题；

⑧来自于特定时期特定供应商的配置项；

⑨受问题影响的所有配置项。

11.配置库(Configuration Library)是用来存放配置项并记录与配置项相关的所有信息的配置管理工具。

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

13.角色与职责

（1）.配置管理负责人

配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动，具体有：①管理所有活动，包括计划、识别、控制、审计和回顾；②负责配置管理过程；③通过审计过程确保配置管理数据库的准确和真实；④审批配置库或配置管理数据库的结构性变更；⑤定义配置项责任人；⑥指派配置审计员；⑦定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态；⑧评估配置管理过程并持续改进；⑨参与变更管理过程评估；⑩对项目成员进行配置管理培训。

（2）.配置管理员CMO

配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动，具体有：①建立和维护配置管理系统：②建立和维护配置库或配置管理数据库；③配置项识别；④建立和管理基线；⑤版本管理和配置控制；⑥配置状态报告；⑦配置审计；⑧发布管理和交付。(三建+5个配置管理日常活动)

（3）.配置项负责人

配置项负责人确保所负责的配置项的准确和真实：①记录所负责配置项的所有变更；②维护配置项之间的关系；③调查审计中发现的配置项差异，完成差异报告；④遵从配置管理过程；⑤参与配置管理过程评估。

14.目标与方针

（1）.管理目标

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

①所有配置项能够被识别和记录；

②维护配置项记录的完整性；

③为其他管理过程提供有关配置项的准确信息；

④核实有关信息系统的配置记录的正确性并纠正发现的错误；

⑤配置项当前和历史状态得到汇报；

⑥确保信息系统的配置项的有效控制和管理。

配置管理目标主要包括：

①确保软件配置管理计划得以制订，并经过相关人员的评审和确认；

②应该识别出要控制的项目产品有哪些，并且制定相关控制策略，以确保这些项目产品被合适的人员获取；

③应制定控制策略，以确保项目产品在受控制范围内更改；

④应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容。

（2).管理方针

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

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

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

(1).制订配置管理计划

配置管理计划的主要内容为：

①配置管理的目标和范围。②配置管理活动。③配置管理角色和责任安排。④实施这些活动的规范和流程，如配置项命名规则。

⑤实施这些活动的进度安排，如日程安排和程序。

⑥与其他管理之间(如变更管理等)的接口控制。

⑦负责实施这些活动的人员或团队，以及他们和其他团队之间的关系。

⑧配置管理信息系统的规划。

⑨配置管理的日常事务，包括许可证控制、配置项的存档等。

⑩计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划。

16.配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构识别。它包括为配置项分配标识和版本号等。具体包括：

①确定配置项范围。

②确认和记录配置项属性。

③为配置项定义标识符。

④确定配置基准线。

⑤确定配置结构。

⑥确定配置项命名规则。

配置项命名规则应能体现：

①配置结构内各配置项间的层级关系；②每个配置及其相关文档间的关系；

③各配置项及其相关文档间的关系；④文档与变更间的关系等。

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

①变更申请；②变更评估(评估内容包括：变更对项目的影响；变更的内容是否必要；变更的范围是否考虑周全；变更的实施方案是否可行；变更工作量是否合理);③通知评估结果；④变更实施；⑤变更验证与确认；⑥变更发布。

18.基于配置库的变更控制

①将待升级的基线(假设版本号为V2.1)从产品库中取出，放入受控库。

②程序员将欲修改的代码段从受控库中检出(Check out),放入自己的开发库中进行修改。代码被Check out后即被“锁定”,以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out。

③程序员将开发库中修改好的代码段检入(Check in)受控库。Check in后，代码的“锁定”被解除，其他程序员可以Check out该段代码了。

④软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中(软件产品的版本号更新为V2.2,旧的V2.1版本并不删除，继续在产品库中保存)。

19.配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。

配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求，不允许出现任何混乱现象：

①防止向用户提交不适合的产品，如交付了用户手册的不正确版本；

②发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更；

③找出各配置项间不匹配或不相容的现象；

④确认配置项已在所要求的质量控制审核之后纳入基线并入库保存；

⑤确认记录和文档保持着可追溯性等。

20.1)功能配置审计：是审计配置项的一致性(配置项的实际功效是否与其需求一致),具体验证以下几个方面。

(1)配置项的开发已圆满完成。

(2)配置项已达到配置标识中规定的性能和功能特征。

(3)配置项的操作和支持文档已完成并且是符合要求的。

2)物理配置审计：是审计配置项的完整性(配置项的物理存在是否与预期一致),具体验证如下几个方面。

(1)要交付的配置项是否存在。

(2)配置项中是否包含了所有必需的项目。

配置审计应当定期进行，应当进行配置审计的场景包括：①实施新的配置库或配置管理数据库之后：②对信息系统实施重大变更前后；③在一项软件发布和安装被导入实际运作环境之前；④灾难恢复之后或事件恢复正常之后；⑤发现未经授权的配置项后：⑥任何其他必要的时候等。

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

①对本次配置管理回顾进行准备，设定日期和主题，通知相关人等参加会议。根据配置管理绩效衡量指标，要求配置项责任人提供配置项统计信息；

②召开配置管理回顾会议，在设定日期召开回顾会议，对配置管理报告进行汇报，听取各方意见，回顾上次过程改进计划执行情况；

③根据会议结论，制订并提交服务改进计划；

④根据过程改进计划，协调、落实改进等。

22.项目变更管理是指在信息系统项目的实施过程中，由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法、项目进度等方面做出的改变。变更管理是为使得项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法。其可能的两个结果是拒绝变化，或是调整项目基准。

变更管理的实质是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。

23.变更管理与配置管理的关系

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

24.变更产生的原因：①产品范围(成果)定义的过失或者疏忽；②项目范围(工作)定义的过失或者疏忽；③增值变更；④应对风险的紧急计划或回避计划；⑤项目执行过程与基准要求不一致带来的被动调整；⑥外部事件等。

25.变更的分类

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

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

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

26.变更管理的原则是项目基准化和变更管理过程规范化。主要内容包括：

①基准管理，基准是变更的依据。

②变更控制流程化。

③明确组织分工。

④评估变更的可能影响。

⑤妥善保存变更产生的相关文档。

27.角色与职责

(1)变更管理负责人：也称变更经理，通常是变更管理过程解决方案的负责人，其主要职责包括：

①负责整个变更过程方案的结果；

②负责变更管理过程的监控；

③负责协调相关的资源，保障所有变更按照预定过程顺利运作；

④确定变更类型，组织变更计划和日程安排；

⑤管理变更的日程安排；

⑥变更实施完成之后的回顾和关闭；

⑦承担变更相关责任，并且具有相应权限；

⑧可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。

(2)变更请求者：负责记录与提交变更请求单，具体为：

①提交初步的变更方案和计划；

②初步评价变更的风险和影响，给变更请求设定适当的变更类型；

③对理解变更过程有能力要求等。

(3)变更实施者：变更实施者需要拥有有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变更任务。

(4)变更顾问委员会：负责对重大变更行使审批，提供专业意见和辅助审批，具体为：①在紧急变更时，其中被授权者行使审批权限；

②定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等。

28.工作程序：

29.提出变更申请：变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评估前应以书面形式提出。一般项目经理或者项目配置管理员负责该相关信息的收集，以及对变更申请的初审。

30.对变更的初审：

变更初审的目的主要包括：①对变更提出方施加影响，确认变更的必要性，确保变更是有价值的；②格式校验，完整性校验，确保评估所需信息准备充分；③在干系人间就提出供评估的变更信息达成共识等。变更初审的常见方式为变更申请文档的审核流转。

31.变更方案论证：变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。

32.变更审查：变更审查是项目所有者根据变更申请及评估方案，决定是否变更项目基准。对于涉及项目目标和交付成果的变更，客户和服务对象的意见应放在核心位置。

33.发出通知并实施：变更评审通过后，意味着基准的调整，同时确保变更方案中的资源需求及时到位。如果变更造成交付期调整，应在变更确认时发布，而非在交付前公布。

34.实施监控：变更实施的监控，除了调整基准中涉及变更的内容外，还应当对项目的整体基准是否反映项目实施情况负责。

35.效果评估：变更评估的关注内容主要包括：①评估依据是项目的基准；②结合变更的目标，评估变更所要达到的目的是否已达成；③评估变更方案中的技术论证、经济论证内容与实施过程的差距，并促使解决。

36.变更收尾：变更收尾是判断发生变更后的项目是否已纳入正常轨道。

37.项目的变更控制主要关注变更申请的控制及变更过程的控制。

(1)对进度变更的控制主要包括：①判断项目进度的当前状态；②对造成进度变化的因素施加影响；③查明进度是否已经改变；④在实际变化出现时对其进行管理。

(2)对成本变更的控制主要包括：①对造成费用基准变更的因素施加影响；②确保变更请求获得同意；③当变更发生时，管理这些实际的变更：④保证潜在的费用超支不超过授权的项目阶段资金和总体资金；⑤监督费用绩效，找出与费用基准的偏差；⑥准确记录所有与费用基准的偏差；⑦防止错误的、不恰当的或未批准的变更被纳入费用或资源使用报告中；⑧就审定的变更，通知利害关系者；⑨采取措施，将预期的费用超支控制在可接受的范围内；⑩项目费用控制查找正、负偏差的原因。

(3)合同变更控制是规定合同修改的过程，它包括文书工作、跟踪系统、争议解决程序以及批准变更所需的审批层次。合同变更控制应当与整体变更控制结合起来

38.版本发布前的准备工作包括：①进行相关的回退分析；②备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理；③备份配置数据，包括数据备份的方式；④备份在线生产平台接口、应用、工作流等版本；⑤启动回退机制的触发条件；⑥对变更回退的机制职责的说明。

39.回退步骤通常包括：

①通知相关用户系统开始回退；

②通知各关联系统进行版本回退；

③回退存储过程等数据对象；

④配置数据回退；

⑤应用程序、接口程序、工作流等版本回退；

⑥回退完成通知各周边关联系统；

⑦回退后进行相关测试，保证回退系统能够正常运行；

⑧通知用户回退完成等。

40.信息系统相关信息(文档)是指某种数据媒体和其中所记录的数据。它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的东西。软件文档分为三类开发文档、产品文档、管理文档。

41.文档的质量可以分为以下四级。

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

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

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

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

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