软考-高项，知识点一览十九 配置和变更管理

十九 配置和变更管理

配置管理包含配置库的建立和配置管理数据库 (Configuration Management Databases, CMDB ) 准确性的维护 ，以支待信息系统项目的正常运行。

1 配置管理

配置管理是为了系统地控制配置变更，在信息系统项目的整个生命周期中维持配置的完整性和可跟踪性，而标识信息系统建设在不同时间点上配置的学科。

配置项是信息系统组件或与其有关的项目，包括软件、硬件和各种文档，如变更请求、服务、服务器、环境、设备、网络设施、台式机、移动设备、应用系统、协议、电信服务等。这些组件或项目已经或将要受到配置管理的控制。比较典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等

所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在CMDB 中。

基线配置项可能包括所有的设计文档和源程序等 ；非基线配置项可能包括项目的各类计划和报告 等。 所有配置项的操作权限应由配置管理员严格管理，基本原则是：基线配置项 向开发人员开放读取的权限；非基线配置项 向项目经理、 CCB 及相关人员开放 。

配置项状态

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

配置项版本号

配置项的版本号规则与配置项的状态定义相关。例如 ： 1 处于 “ 草稿”状态 的配置项的版本号格式为 O.YZ, YZ 是数字，取值范围为 01 ~ 99。随着草稿的修正，YZ 的取值应递增。YZ的初值和增幅由用户自己把握。2 处于 “正式 ”状态 的配置项的版本号格式为 X.Y , X 为主版本号，取值范围为 I ~ 9: Y 为次版本号，取值范围为 0 ~ 9。配置项第一次成为“正式 “ 文件时，版本号为 1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为 1.0, 1. 1 ,… … 当附件的变动积累到一定程度时，配置项的 Y 值可适量增加；Y 值增加到一定程度时 ， X 值将适量增加 。 当配置项升级幅度比较大时，才允许直接增大 X 值。3处于“ 修改”状态 的配置项的版本号格式为 X.YZ。配仅项正在修改时，一般只增大 Z 值， X. Y 值保持不变。当配置项修改完毕，状态成为 “ 正式 ”时，将 Z 值设置为 0, 增加 X.Y 值。

配置项版本管理

配篮项的版本管理作用千多个配匠管理活动之中，如配置标识 、配置控制和配置审计、发布和交付等版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

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

基线通常对应于项目过程中的里程碑 ( Milestone ) ，一个项目可以有多个基线，也可以只有一个基线 。

对于每一个基线，要定义下列内容 ：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。

配置管理数据库主要内容包括 ：

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

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

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

4 配置项变更轨迹 ；

5 特定的设备和软件 ；

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

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

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

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

配置库

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

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

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

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

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

按配置项的类型分类建库：这种模式适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求

按开发任务建立相应的配置库：这种模式适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，

角色与职责

配置管理相关角色常包括：变更控制委员会 (Change Control Board , CCB ) 、配置管理负责人、配置管理员和配置项负责人等

配置管理负责人

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

1 管理所有活动，包括计划、识别、控制、审计和回顾 ；

2 负责配置管理过程 ；

3 通过审计过程确保配置管理数据库的准确和扛实；

4 审批配置库或配置管理数据库的结构性变更；

5 定义配置项责任人； 6 指派配置审计员；7 定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态 ； 8 评估配置管理过程并持续改进 ； 9 参与变更管理过程评估 ； 10对项目成员进行配置管理培训。

配置管理员

配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动，具体有 ： 1 建立和维护配置管理系统；2 建立和维护配置库或配置管理数据库；3 配置项识别；4 建立和管理基线； 5 版本管理和配置控制；6 配置状态报告；7 配置审计；8 发布管理和交付 。

配置项负责人

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

管理活动

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

配置项控制

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

1. 变更申请；变更申请表， 说明要变更的内容、变更原因、受变更影响的关联配置项和有关基线、变更实施方案、工作批和变更实施人等，提交给 CCB。
2. 变更评估；CCB 负责组织对变更申请进行评估 并确定：影响、必要性、周全 可行性 合理性 是否接受-通知
3. 通告评估结果； CCB 把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。
4. 变更实施；项目经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息；
5. 变更验证与确认；项目经理指定人员对变更后的配置项进行测试或验证；
6. 变更的发布；配置管理员将变更后的配置项纳入基线。配置管理员将变更 内容和 结果通知相关人员 ， 并做好记录。
7. 基于配置库的变更控制。

配置状态报告

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

配置审计

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

功能配置审计：一致性：具体验证主要包括 ：1配置项的开发已圆满完成； 2配置项已达到配置标识中规定的性能和功能特征 ；3配置项的操作和支持文档已完成并且是符合要求的等。

物理配置审计：完整性（配置项的物理存在是否与预期一致），具体验证主要包括：1 要交付的配置项是否存在；2 配置项中是否包含了所有必需的项目等。

2 变更管理

项目变更管理是指在信息系统项目的实施过程中，由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法、项目进度等方面做出的改变。变更管理的实质 是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。

变更的常见原因包括： 1产品范围（成果）定义的过失或者疏忽；2项目范围（工作）定义的过失或者疏忽；3增值变更；4应对风险的紧急计划或回避计划；5 项目执行过程与基准要求不一致带来的被动调整 ；6外部事件等。

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

变更管理是为使得项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法。

角色与职责

项目经理是组织委托的项目经营过程负责者，其正式权利由项目章程取得，而资源调度的权力通常由基准中明确。基准中不包括的储备资源需经授权入批准后方可使用。项目经理在变更中的作用是：响应变更提出者的需求；评估变更对项目的影响及应对方案；将需求由技术要求转化为资源需求，供授权人决策；并据评审结果实施（即调整基准），确保项目基准反映项目实施情况。

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

变更工作程序：

1. 变更申请；正式 书面  所有干系人都可以提 、项目经理 配置管理员初审
2. 对变更的初审；确认必要性 价值  格式校验 完整性校验 变更信息达成共识
3. 变更方案验证；可实现的论证 技术评估 经济与社会效益评估 大型变更（变更方案论证会议）
4. 变更审查：对基准影响
5. 变更通知并实施：调整基准  资源到位 实施
6. 实时监控：项目经理负责基准的监控 。 CCB 监控变更明确的主要成果、进度里程碑等 ，
7. 效果评估；项目基准 变更目标  差距
8. 变更收尾：发生变更后的项目是否已纳入正常轨道

变更控制

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

项目文档管理

开发文档:描述开发过程本身，基本的开发文档包括：可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明（包括程序和数据规格说明、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息等）。

产品文档: 描述开发过程的产物，基本的产品文档包括：培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。

管理文档:记录项目管理的信息，例如：开发过程的每个阶段的进度和进度变更的记录 ；软件变更情况的记录；开发团队的职责定义、项目计划、项目阶段报告；配置管理计划 。

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

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

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

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

正式文档 ( 4 级文档）：适合那些要正式发行供普遍使用的软件产品。