第十九章 配置管理和变更管理

目录

1.配置项

2.基线

3.配置库

1. 配置库的内容

2. 配置库的建库模式有两种：按配置项类型建库和按任务建库

4.目标与方针

5.制定配置管理计划

6.配置标识：是配置管理员（CMO）的职能

7.配置控制

8.配置状态报告（配置状态统计）

9.配置审计（配置审核/配置评价）

10.配置管理回顾与改进

11. 变更的常见原因

12.变更的分类和含义

13.变更管理的原则

14.工作程序

15.变更控制

16. 版本发布和回退计划

17.文档分类

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

19.文档的规范化管理主要体现

20.配置管理和配置管理角色与职责

1. 控制委员会

2. 管理负责人

3. 其他角色与职责

---

1.配置项

• 配置项的内容：包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。
• 所有配置项的操作权限应由CMO（配置管理员）严格管理。
• 配置项分类

1. 基线配置项：包括所有的设计文档和源程序等；向开发人员开放读取的权限。
2. 非基线配置项：包括项目的各类计划和报告等；向PM、CCB及相关人员开放权限。

• 配置项的状态

1. “草稿”：处于“草稿”状态的配置项的版本号格式为0.YZ。YZ的数字范围为01~99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
2. “正式”：处于“正式”状态的配置项的版本号格式为X.Y。X为主版本号，取值范围为1~9。Y为次版本号，取值范围为0~9。配置项第一次成为“正式”文件时，版本号为1.0。
3. “修改”：处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置向修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。

• 配置项的版本管理：版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本，对配置项的任何修改都将产生新版本。由于不能保证新版本一定比旧版本“好”，故不能抛弃旧版本。
• 绝大部分的配置项都要经过多次的修改才能最终确定下来。

2.基线

• 通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。
• 交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线。对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。
• 在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。

3.配置库

配置库的内容

配置库	内容
开发库	也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。
受控库	也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
产品库	也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。

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

模式	解析
按类型	适用于通用软件的开发组织。 产品的继承性往往较强，工具比较统一，对并行开发有一定的需求，有利于对配置项的统一管理和控制； 并不是面向各个开发团体的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
按开发任务	适用于专业软件的开发组织。 使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。 采用这种设置策略比较灵活。

4.目标与方针

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

1. 所有配置项能够被识别和记录；
2. 维护配置项记录的完整性；
3. 为其他管理过程提供有关配置项的准确信息；
4. 核实有关信息系统的配置记录的正确性并纠正发现的错误；
5. 配置项当前和历史状态得到汇报；
6. 确保信息系统的配置项的有效控制和管理。

• 组织需要实现的配置管理目标

1. 确保软件配置管理计划得以制订，并经过相关人员的评审和确认；
2. 应该识别出要控制的项目产品有哪些，并且制定相关控制策略，以确保这些项目产品被合适的人员获取；
3. 应制定控制策略，以确保项目产品在受控范围内更改；
4. 应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容。

• 配置管理的关键成功因素

1. 所有配置项应该记录；
2. 配置项应该分类；
3. 所有配置项要进行编号；
4. 应该定期对配置库或配置管理数据库中的配置项信息进行审计；
5. 每个配置项在建立后，应有配置负责人负责；
6. 要关注配置项的变化情况；
7. 应该定期对配置管理进行回顾；
8. 能够与项目的其他管理活动进行关联。

配置管理六项活动：制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、配置管理回顾与改进。

5.制定配置管理计划

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

1. 配置管理的目标和范围；
2. 配置管理活动主要包括配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾及改进等；
3. 配置管理角色和责任安排；
4. 实施这些活动的规范和流程，如配置项命名规则；
5. 实施这些活动的进度安排，如日程安排和程序；
6. 与其他管理之间（如变更管理等）的接口控制；
7. 负责实施这些活动的人员或团队，以及他们和其他团队之间的关系；
8. 配置管理信息系统的规划包括配置数据的存放地点、配置向运行的受控环境、与其他服务管理系统的联系和接口、构建和安装等支持工具；
9. 配置管理的日常事务包括许可证控制、配置项的存档等；
10. 计划的配置基准线、重大发布、里程碑，以及针对以后每个期间的工作量计划和资源计划。

6.配置标识：是配置管理员（CMO）的职能

• 配置项识别是针对所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构进行识别的过程。它包括为配置项分配标识和版本号等。
• 配置项识别的基本步骤

1. 识别需要受控的配置项；
2. 为每个配置项指定唯一的标识号；
3. 定义每个配置项的重要特征；
4. 确定每个配置项的所有者及其责任；
5. 确定配置项进入配置管理的时间和条件；
6. 建立和控制基线；
7. 维护文档和组件的修订与产品版本之间的关系。

7.配置控制

• 提出变更申请：相关人员填表并提交给CCB
• 变更评估并决定：CCB负责，进行评估并确定以下内容：

1. 变更对项目的影响
2. 变更的内容是否必
3. 变更的范围是否考虑周全
4. 变更的实施方案是否可行
5. 变更的工作量估计是否合理。

• CCB决定是否接受变更，并将决定通知相关人员。
• 通告评估结果。CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。如果变更申请得到批准，应该及时把变更批准信息和变更实施方案通知给那些正在使用受影响的配置项和基线的干系人。如果变更申请被否决，应通知有关干系人放弃该变更申请。
• 变更实施。项目经理组织修改相关的配置项，并在相应的文档、程序代码或配置管理数据中记录变更信息。
• 变更验证与确认。项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交给CCB，由其确认变更是否已经按要求完成。
• 变更的发布。配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员，并做好记录。
• 基于配置库的变更控制流程（如图所示）

1. 将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库。
2. 程序员将预修改的代码段从受控库中检出（Check out），放入自己的开发库中进行修改。代码被Check out后即被“锁定”，以保障同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out。
3. 程序员将开发库中修改好的代码检入（Check in）受控库。Check in后，代码的“锁定”被解除，其他程序员可以Check out该段代码了。
4. 软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2，旧的V2.1版并不删除，继续在产品库中保存）。

8.配置状态报告（配置状态统计）

• 每个受控配置项的标识和状态，一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。
• 每个变更申请的状态和已批准的修改的实施状态。
• 每个基线的当前和过去版本的状态以及各版本的比较。
• 其他配置管理过程活动的记录等。

9.配置审计（配置审核/配置评价）

• 配置审计，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求，不允许出现任何混乱现象：

1. 防止向用户提交不合适的产品，如交付了用户手册的不正确版本；
2. 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更；
3. 找出各配置项间不匹配或不相容的现象；
4. 确认配置项已在所要求的质量控制审核之后纳入基线并入库保存；
5. 确认记录和文档保持着可追溯性等。

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

1. 配置项的开发已圆满完成。
2. 配置项已达到配置标识中规定的性能和功能特征。
3. 配置项的操作和支持文档已完成并且是符合要求的。

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

1. 要交付的配置项是否存在。
2. 配置项中是否包含了所有必需的项目。

10.配置管理回顾与改进

• 对本次配置管理回顾进行准备，设定日期和主题通知相关人等参加会议。
• 召开配置管理回顾会议。
• 根据会议结论，制定并提交服务改进计划。
• 根据过程改进计划，协调、落实改进等。

11. 变更的常见原因

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

12.变更的分类和含义

• 根据变更性质可分为重大变更、重要变更和一般变更，通过不同审批权限进行控制。根据变更的迫切性可分为紧急变更、非紧急变更。
• 变更管理是为使得项目基准与项目实际执行情况相一致，应对项目变化的一套管理方法。其可能的两个结果是拒绝变化，或是调整项目基准。

13.变更管理的原则

• 基准管理：基准是变更的依据。每次变更通过评审后，都应重新确定基准。
• 变更控制流程化：建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程。
• 明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能。
• 评估变更的可能。
• 影响妥善保存变更产生的相关文档：适当时可以引入配置管理工具。

14.工作程序

• 变更申请：变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但是在评估前应以书面形式提出。项目的干系人都可以提出变更申请，但一般情况下都需要经过指定人员进行审批，一般项目经理或者项目配置管理员负责该相关信息的收集，以及对变更申请的初审。
• 对变更的初审：变更初审的常见方式为变更申请文档的审核流转。变更初审的目的：

1. 对变更提出方施加影响，确认变更的必要性，确保变更是有价值的；
2. 格式校验，完整性校验，确保评估所需信息准备充分；
3. 在干系人间就提出供评估的变更信息达成共识等。

• 变更方案论证：变更方案的主要作用，首先是对变更请求是否实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源要求，以供CCB决策。对于一些大型的变更，可以召开相关的变更方案论证会议，通常需要由变更顾问委员会（相关技术和经济方面的专家组成）进行相关论证，并将相关专家意见作为项目变更方案的一部分，报项目CCB作为决策参考。
• 变更审查：变更审查过程是项目所有者根据变更申请及评估方案，决定是否变更项目基准。
• 发出通知并实施
• 实施监控：变更实施的过程监控，通常由项目经理负责基准的监控。CCB监控变更明确的主要成果、进度里程碑等，也可以通过监理单位完成监控。
• 效果评估：变更评估的关注内容主要包括：

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

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

15.变更控制

• 在项目整体压力较大的情况下，更需要强调变更的提出和处理应当规范化，可以使用分批处理、分优先级等方式提高效率。
• 项目规模小、与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高效。

16. 版本发布和回退计划

• 版本发布前的准备工作

1. 进行相关的回退分析；
2. 备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理；
3. 备份配置数据，包括数据备份的方式；
4. 备份在线生产平台接口、应用、工作流等版本；
5. 启动回退机制的触发条件；
6. 对变更回退的机制职责的说明，如通知相关部门，确定需要回退的关联系统和回退时间点等。

• 回退步骤

1. 通知相关用户系统开始回退；
2. 通知各关联系统进行版本回退；
3. 回退存储过程等数据对象；
4. 配置数据回退；
5. 应用程序、接口程序、工作流等版本回退；
6. 回退完成通知各周边关联系统；
7. 回退后进行相关测试，保证回退系统能够正常运行；
8. 通知用户回退完成等。

17.文档分类

• 开发文档描述开发过程本身，基本的开发文档包括：可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明，开发计划；软件集成和测试计划；质量保证计划；安全和测试信息。
• 产品文档描述开发过程的产物，基本的产品文档包括：培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。
• 管理文档记录项目管理的信息，例如：开发过程的每个阶段的进度和进度变更的记录；软件变更情况的记录；开发团队的职责定义、项目计划、项目阶段报告；配置管理计划。

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

• 最低限度的文档（1级文档）：适合开发工作量低于一个人月的开发者自用程序。
• 内部文档（2级文档）：可用于没有与其他用户共享资源的专用程序。
• 工作文档（3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
• 正式文档（4级文档）：适合那些要正式发行共普遍使用的软件产品。

19.文档的规范化管理主要体现

• 文档书写规范：管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是哪种类型的文档都应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。
• 图表编号规则：在管理信息系统的开发过程中用到很多的图表，对这些图表进行有规则的编号，可以方便图表的查找。
• 文档目录编写标准：为了存档及未来使用的方便，应该编写文档目录。管理信息系统的文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。
• 文档管理制度：文档的管理制度须根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等。

20.配置管理和配置管理角色与职责

1. 控制委员会

配置控制委员会（CCB）	变更控制委员会（CCB）
它不只是控制变更，也负有更多的配置管理任务	它是决策机构，不是作业机构，通过评审手段决定项目基准是否能变更
制定和修改项目配置管理策略； 审批和发布配置管理计划； 审批基线的设置、产品的版本等； 审查、评价、批准、推迟或否决变更申请； 监督已批准变更的实施； 接收变更与验证结果，确认变更是否按要求完成； 根据配置管理报告决定相应的对策。	负责审查、评价、批准、推迟或否决项目变更； 将变更申请的批准、否决或推迟的决定通知受此处置意见影响的相关干系人； 接收变更与验证结果，确认变更是否按要求完成。

2. 管理负责人

配置管理负责人（配置经理）	变更管理负责人（变更经理）
管理和决策整个项目生命周期中的配置活动	变更管理过程解决方案的负责人
管理所有活动，包括计划、识别、控制、审计和回顾； 负责配置管理过程； 通过审计过程确保配置管理数据库的准确和真实； 审批配置库或配置管理数据库的结构性变更； 定义配置项责任人； 指派配置审计员； 定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态； 评估配置管理过程并持续改进； 参与变更管理过程评估； 对项目成员进行配置管理培训。	负责整个变更过程方案的结果； 负责变更管理过程的监控； 负责协调相关的资源，保障所有变更按照预定过程顺利运作； 确定变更类型，组织变更计划和日程安排； 管理变更的日程安排； 变更实施完成之后的回顾和关闭； 承担变更相关责任，并且具有相应权限； 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。

3. 其他角色与职责

配置管理员 负责在整个项目生命周期中进行配置管理的主要实施活动。	建立和维护配置管理系统 建立和维护配置库或配置管理数据库 配置项识别 建立和管理基线 版本管理和配置控制 配置状态报告 配置审计 发布管理和交付
配置项负责人 确保所负责的配置项的准确和真实。	记录所负责配置项的所有变更 维护配置项之间的关系 调查审计中发现的配置项差异，完成差异报告 遵从配置管理过程 参与配置管理过程评估
变更请求者 记录与提交变更请求单。	提出初步的变更方案和计划 初步评价变更的风险和影响，给变更请求设定适当的变更类型
变更实施者 需要拥有有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变更内容。	负责按照变更计划实施具体的变更任务 负责记录并保存变更过程中的产物，将变更后的基准纳入项目基准中 参与变更正确性的验证与确认工作
变更顾问委员会 负责对重大变更行使审批，提供专业意见和辅助审批。	在紧急变更时，其中被授权者行使审批权限 定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等