ONEPSOFT | 软考学习知识库
speedrun19|第19章 配置与变更管理速通框架
1. 章节定位
2. 本章在讲什么
本章三部分:①配置管理, 把项目所有 " 该管的对象 "(配置项)登记、编版本、建基线、存配置库(开发库/受控库/产品库),用 CMDB 管理,确保任何时候都能追溯 " 当时是什么样 ";②变更管理, 任何改动走 " 申请→初审→论证→审查→通知实施→监控→评估→收尾 " 八步,核心是 " 基准化 + 流程规范化 ",CCB 管审批;③文档管理, 开发/产品/管理三类文档规范化。两者关系:配置管理是项目完整性的系统,变更管理是它的一部分(或关联机制),变更结果要回流配置管理。
土木类比:配置管理=工程的 " 图纸与档案库 ", 每张图纸(配置项)有版本号、有 " 正式版 " 基线(施工图蓝图),改图要走变更单;变更管理=工程的 " 设计变更流程 ";配置库=设计院的图纸归档柜(动态库=在编草图,受控库=已审蓝图,产品库=竣工图)。
3. 教材原文精摘(每子章节原封不动原文 + 逐段讲解)
19.1.1 管理基础(配置项/状态/版本号/基线/库)
1.配置项 (Configuration Item,Cl)
GB/T 11457《信息技术软件工程术语》对配置项的定义为:" 为配置管理设计的硬件、软件或二者的集合,在配置管理过程中作为一个单个实体来对待 "。配置项是信息系统组件或与其有关的项目,包括软件、硬件和各种文档,如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等。
2.配置项状态
配置项的状态需要根据配置项的不同类型和管理需求进行分别定义,基于配置项建设过程角度,可将配置项状态分为 " 草稿 "" 正式 " 和 " 修改 " 三种。配置项刚建立时,其状态为 " 草稿 "。配置项通过评审后,其状态变为 " 正式 "。此后若更改配置项,则其状态变为 " 修改 "。当配置项修改完毕并重新通过评审时,其状态又变为 " 正式 "。
3.配置项版本号
配置项的版本号规则与配置项的状态定义相关。例如:①处于 " 草稿 " 状态的配置项的版本号格式为 0.YZ;②处于 " 正式 " 状态的配置项的版本号格式为 X.Y,X 为主版本号 1~9,Y 为次版本号 0~9。配置项第一次成为 " 正式 " 文件时,版本号为 1.0。
5.配置基线
配置基线由一组配置项组成,这些配置项构成一个相对稳定的逻辑实体。……基线中的配置项被 " 冻结 " 了,不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
7.配置库
配置库可以分开发库、受控库、产品库 3 种类型。开发库也称为动态库、程序员库或工作库,用于保存开发人员当前正在开发的配置实体;受控库也称为主库,包含当前的基线以及对基线的变更;产品库也称为静态库、发行库、软件仓库,包含已发布使用的各种基线的存档。
【讲解】配置项=受控的单个实体(软硬件文档都算);状态三态草稿→正式→修改循环;版本号规则(草稿 0.YZ,正式 X.Y,首正式 1.0);基线=被冻结的稳定实体,改必须走变更;配置库三分(开发/受控/产品)。这是本章最核心的选考点。
19.1.2 角色与职责
配置管理相关角色常包括:变更控制委员会 (Change Control Board,CCB) 、配置管理负责人、配置管理员和配置项负责人等。
2.配置管理员
配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动,具体有:①建立和维护配置管理系统;②建立和维护配置库或配置管理数据库;③配置项识别;④建立和管理基线;⑤版本管理和配置控制;⑥配置状态报告;⑦配置审计;⑧发布管理和交付。
3.配置项负责人
配置项负责人确保所负责的配置项的准确和真实:①记录所负责配置项的所有变更;②维护配置项之间的关系;③调查审计中发现的配置项差异,完成差异报告;④遵从配置管理过程。
【讲解】角色分清:CCB 管审批(决策),配置管理员管日常实施(8 项),配置项负责人管自己那一项准确。
19.1.3 目标与方针
1.管理目标
在信息系统项目中,配置管理的目标主要用以定义并控制信息系统的组件,维护准确的配置信息,具体包括:①所有配置项能够被识别和记录;②维护配置项记录的完整性;③为其他管理过程提供有关配置项的准确信息;④核实有关信息系统的配置记录的正确性并纠正发现的错误;⑤配置项当前和历史状态得到汇报;⑥确保信息系统的配置项的有效控制和管理。
【讲解】配置管理目标 6 条,核心一句话:识别、记录、保准、可回溯、受控。
19.1.4 管理活动
配置管理的日常管理活动主要包括:制订配置管理计划、配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾与改进等。
5.配置审计
配置审计也称配置审核或配置评价,包括功能配置审计和物理配置审计,分别用以验证当前配置项的一致性和完整性。一般来说,配置审验应当定期进行,应当进行配置审计的场景包括:①实施新的配置库或配置管理数据库之后;②对信息系统实施重大变更前后;③在一项软件发布和安装被导入实际运作环境之前等。
【讲解】日常活动 6 项(计划/识别/控制/状态报告/审计/回顾改进);配置审计分功能审计(一致)和物理审计(完整),3 个必审场景要记。
19.2.1 管理基础(变更定义/与配置关系/原因)
项目变更管理是指在信息系统项目的实施过程中,由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法、项目进度等方面做出的改变。变更管理的实质是根据项目推进过程中越来越丰富的项目认知,不断调整项目努力方向和资源配置,最大程度地满足项目需求,提升项目价值。
1.变更管理与配置管理
如果把项目整体的交付物视作项目的配置项,配置管理可视为对项目完整性管理的一套系统,当用于项目基准调整时,变更管理可视为其一部分。亦可视变更管理与配置管理为相关联的两套机制,变更管理由项目交付或基准配置调整时,由配置管理过程调用,变更管理最终应将对项目的调整结果反馈给配置管理过程,以确保项目执行与项目配置信息相一致。
2.变更产生的原因
变更的常见原因包括:①产品范围 (成果) 定义的过失或者疏忽;②项目范围 (工作) 定义的过失或者疏忽;③增值变更;④应对风险的紧急计划或回避计划;⑤项目执行过程与基准要求不一致带来的被动调整;⑥外部事件等。
【讲解】变更管理实质=随认知加深调整方向;与配置管理是 " 系统 + 子集/关联机制 " 关系;变更 6 大原因(前两个是定义疏忽,常考)。
19.2.2 管理原则
变更管理的原则是项目基准化和变更管理过程规范化。主要内容包括:
●基准管理:基准是变更的依据。在项目实施过程中,基准计划确定并经过评审后建立初始基准。此后每次变更通过评审后,都应重新确定基准。
●变更控制流程化:建立或选用符合项目需要的变更管理流程,所有变更都必须遵循这个控制流程。
【讲解】两大原则:基准化(基准是变更依据,每次变更后重定基准)+ 流程化(所有变更必须走流程,不走流程的 " 口头变更 " 是案例典型错误)。
19.2.3 角色与职责
规范的项目实施,提倡分权操作。项目经理在变更中的作用是:响应变更提出者的需求;评估变更对项目的影响及应对方案;将需求由技术要求转化为资源需求,供授权人决策;并据评审结果实施 (即调整基准),确保项目基准反映项目实施情况。
1.变更管理负责人
变更管理负责人也称变更经理……其主要职责包括:①负责整个变更过程方案的结果;②负责变更管理过程的监控;③负责协调相关的资源,保障所有变更按照预定过程顺利运作;④确定变更类型,组织变更计划和日程安排等。
【讲解】项目经理在变更中是 " 评估影响 + 转资源需求 + 实施 ",不是一个人拍板;CCB 才是审批决策方;变更经理管过程监控。
19.2.4 工作程序(八步)
1.变更申请:变更的提出应当及时以正式方式进行,并留下书面记录。……项目的干系人都可以提出变更申请。
3.变更方案论证:变更方案的主要作用,首先是对变更请求是否可实现进行论证……常见的方案内容包括技术评估和经济与社会效益评估。
4.变更审查:变更审查过程是项目所有者根据变更申请及评估方案,决定是否变更项目基准。评审过程通常包括客户、相关领域的专业人士等。
7.效果评估:变更评估的关注内容主要包括:①评估依据是项目的基准;②结合变更的目标,评估变更所要达到的目的是否已达成。
【讲解】变更八步:申请→初审→论证→审查→通知实施→监控→效果评估→收尾。核心是 " 先论证后审批、审批后才实施、实施后评估 "。这也是案例改错题的标准答案模板。
19.2.5 变更控制
由于变更的实际情况千差万别,可能简单,也可能相当复杂。越大型的项目,调整基准的边际成本越高,随意调整可能带来的后果众多,包括基准失效、项目干系人冲突、资源浪费、项目执行情况混乱等。
(1) 对进度变更的控制。对进度变更的控制主要包括:①判断项目进度的当前状态;②对造成进度变化的因素施加影响;③查明进度是否已经改变;④在实际变化出现时对其进行管理。
【讲解】变更控制强调 " 边际成本 ", 大项目随便改基准代价大;进度/成本变更都有专门控制四步。
19.2.6 版本发布和回退计划
对于很多信息系统开发项目来说,项目变更必须做相应的版本发布,并制定相应的应急回退方案。为确保版本发布的成功,在版本发布前应对每次版本发布进行管理,并做好发布失败后的回退方案。
版本发布前的准备工作包括:①进行相关的回退分析;②备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理;③备份配置数据,包括数据备份的方式;④备份在线生产平台接口、应用、工作流等版本;⑤启动回退机制的触发条件等。
【讲解】版本发布必须配 " 回退方案 "(上线失败能退回),发布前 5 项准备(回退分析、备份数据/配置/接口、定触发条件)。运维上线同理,与运维场景强关联。
19.3.1 管理基础(文档分类/质量分级)
对于信息系统开发项目来说,其文档一般分开发文档、产品文档和管理文档。
(1) 开发文档描述开发过程本身……(2) 产品文档描述开发过程的产物……(3) 管理文档记录项目管理的信息……
文档的质量通常可以分为 4 级:(1) 最低限度文档 (1 级文档): 适合开发工作量低于一个人月的开发者自用程序。(2) 内部文档 (2 级文档): 可用于没有与其他用户共享资源的专用程序。
【讲解】文档三分(开发/产品/管理);质量 4 级(1 级自用、2 级专用、3 级外部、4 级关键广泛),按 " 共享范围/重要性 " 分级。
19.3.2 规则和方法
文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度等几个方面。
【讲解】文档规范化 4 方面:书写规范、图表编号、目录标准、管理制度。
4. 核心知识树
配置与变更管理
├── 配置管理
│ ├── 配置项(状态/版本号)
│ ├── 基线(冻结)
│ ├── 配置库(开发/受控/产品)
│ └── 活动(计划/识别/控制/报告/审计/改进)
├── 变更管理
│ ├── 原则(基准化/流程化)
│ ├── 角色(项目经理/CCB/变更经理)
│ └── 八步(申请→收尾)
└── 文档管理
├── 三类(开发/产品/管理)
└── 质量4级
5. 知识脑图
思维导图(结构化呈现)
6. 关键概念速解
| 概念 | 教材定义原词 | 大白话速解 | 怎么考 |
|---|---|---|---|
| 配置项 | 为配置管理设计的硬件、软件或集合,作为单个实体对待 | 受控的最小管理单元 | 选择 |
| 配置项状态 | 草稿/正式/修改 | 在编/已审/又改 | 选择 |
| 配置基线 | 一组配置项组成稳定逻辑实体,被冻结 | 已审定的 " 基准版本 " | 选择/案例 |
| 配置库 | 开发库/受控库/产品库 | 草图柜/蓝图柜/竣工柜 | 选择 |
| CCB | 变更控制委员会 | 变更审批决策方 | 选择/案例 |
| 变更八步 | 申请→初审→论证→审查→通知实施→监控→效果评估→收尾 | 改动走流程的 8 关 | 案例必考 |
| 配置审计 | 功能审计 + 物理审计 | 查一致性和完整性 | 选择 |
7. 记忆口诀&类比
8. 易混淆点对比
| 易混 A | 易混 B | 核心区别 |
|---|---|---|
| 配置管理 | 变更管理 | 配置=管版本/基线完整性;变更=管改动流程;变更是配置的一部分/关联机制 |
| 开发库 | 受控库 | 开发库=在编动态;受控库=含基线及变更的主库 |
| 受控库 | 产品库 | 受控库=当前基线;产品库=已发布存档 (竣工) |
| 草稿状态 | 修改状态 | 草稿=从未正式;修改=正式后被改 |
| 项目经理 | CCB | 项目经理=评估影响 + 实施;CCB=审批决策 |
| 功能配置审计 | 物理配置审计 | 功能=一致性;物理=完整性 |
9. 与其他章节关联
10. 考试出题方式
运维服务专项突破提醒:配置管理与变更管理是IT 运维/IT 服务管理(ITIL、ISO/IEC 20000)的核心底座,正是运维服务的高频考点!