首页  思维导图  详情

19配置与变更管理

2024-07-03 09:00:58   1  举报





AI智能生成

软考高级项目管理师，第19章配置管理思维导图，必背知识点，高频考点多方面覆盖，高分手册

软考笔记

配置管理

考试必备

软考高项

高级项目管理师

作者其他创作

大纲/内容

配置管理

定义

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

管理目标

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

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

配置管理包括6个主要活动

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

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

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

变更管理

①变更申请

②变更评估。CCB决定是否接受变更，并将决定通知相关人员

③通告评估结果。CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人

④变更实施。项目经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息。

⑤变更验证与确认。项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交给CCB,由其确认变更是否已经按要求完成。

⑥变更的发布。配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员，并做好记录。

⑦基于配置库的变更控制。在信息系统开发项目中，一处出现了变更，经常会连锁引起多处变更，会涉及到参与开发工作的许多人员。

以某软件产品升级为例

子主题

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

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

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

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

受控库的权限控制

产品库权限

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

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

①功能配置审计

功能配置审计是审计配置项的一致性(配置项的实际功效是否与其需求一致)

①配置项的开发已圆满完成

②配置项已达到配置标识中规定的性能和功能特征

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

②物理配置审计

物理配置审计是审计配置项的完整性(配置项的物理存在是否与预期一致),

①要交付的配置项是否存在

②配置项中是否包含了所有必需的项目等。

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

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

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

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

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

2.配置项

定义

GB/T11457《信息技术软件工程术语》对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待

典型配置项包括

项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。

软件代码、文档、测试用例等

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

①基线配置项可能包括所有的设计文档和源程序等；

②非基线配置项可能包括项目的各类计划和报告等

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

3.配置项状态

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

子主题

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

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

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

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

4.配置项版本号

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

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

5.配置基线

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

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

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

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

建立基线的价值

(1)基线为项目工作提供了一个定点和快照。

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

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

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

6.配置库

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

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

（1）开发库也称为动态库

开发库也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其进行配置控制，因为这通常不会影响到项目的其他部分。

（2）受控库也称为主库

受控库也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。

（3）产品库

产品库也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。

7.配置管理

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

（1）配置管理负责人

配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动

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

（2）配置管理员

配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动

①建立和维护配置管理系统； ②建立和维护配置库或配置管理数据库； ③配置项识别； ④建立和管理基线； ⑤版本管理和配置控制； ⑥配置状态报告； ⑦配置审计； ⑧发布管理和交付。

（3）配置项负责人

配置项负责人确保所负责的配置项的准确和真实

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

配置管理关键成功因素（记分编，审负情，回联）

①所有配置项应该记录

②配置项应该分类

③所有配置项要编号

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

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

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

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

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

变更管理

变更的分类

根据变更性质分为

重大变更、重要变更和一般变更。通过不同审批权限控制

根据变更迫切性分为

紧急变更、非紧急变更。通过不同变更处理流程进行

根据行业特点分类

如弱电工程行业的常见分类方法 为产品（工作）范围变更、环境变更、设计变更、实施变更和技术标准变更

变更管理与配置管理

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

变更产生的原因

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

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

①产品范围(成果)定义的过失或者疏忽

②项目范围(工作)定义的过失或者疏忽

③增值变更

④应对风险的紧急计划或回避计划

⑤项目执行过程与基准要求不一致带来的被动调整

⑥外部事件

角色和职责

项目经理

项目经理是组织委托的项目经营过程负责者，其正式权利由项目章程取得，而资 源调度的权力通常由基准中明确

变更中的作用

（1）响应变更提出者的需求

（2）评估变更对项目的影响及应对方案

（3）将需求由技术要求转化为资源需求，供授权人决策

（4）根据评审结果实施即调整基准，确保项目基准反映项目实际情况

变更管理负责人

变更管理负责人也称变更经理，通常是变更管理过程解决方案的负责人

其主要职责

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

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

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

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

⑤管理变更的日程安排

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

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

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

变更请求者

变更请求者负责记录与提交变更请求单

具体为

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

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

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

变更实施者

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

变更顾问委员会

变更顾问委员会负责对重大变更行使审批，提供专业意见和辅助审批

具体为

①在紧急变更时，其中被授权者行使审批权限

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

变更管理工作程序（伸出论审，实监评收）

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

（1）变更申请

一般项目经理或配置管理员负责变更相关信息的收集以及对变更申请的初审

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

①对变更提出方施加影响，确认变更的必要性 ②格式校验、完整性校验 ③在干系人间就提出供评估的变更信息达成共识

（3）变更方案论证

由技术要求转化为资源需求，可召开专家论证会，供CCB决策。

（4）变更审查

变更审查过程是项目所有者根据变更申请及评估方案，决定是否变更项目基准。审查通常采用文档、会签形式，重大的变更审查可以采用正式会议形式。

（5）发出通知并实施

变更通知不只是包括项目实施基准的调整，更要明确项目的交付日期、成果对相关干系人的影响。如果变更造成交付期调整，应在变更确认时发布，而非在交付前公布。

（6）实施监控

①项目经理负责基准的监控 ②管理委员会（监理）监控变更的主要成果、进度里程碑

（7）效果评估

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

（8）变更收尾

判断发生变更后，项目是否纳入正常轨道。

变更控制

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

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

变更过程控制

(1)对进度变更的控制

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

(2)对成本变更的控制

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

(3)对合同变更的控制

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

项目文档管理

管理基础

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

开发文档

描述开发过程本身

可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明(包括程序和数据规格说明、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息等)。

产品文档

描述开发过程的产物

培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。

管理文档