高项 - 配置与变更管理

个人总结，仅供参考，欢迎加好友一起讨论

博文更新参考时间点：2024-12

高项 - 章节与知识点汇总：点击跳转

高项 - 配置与变更管理

配置管理

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

管理基础

配置项

配置项：为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。

典型的配置项：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、设备型号等。

所有配置项都应按照相关规定统一编号，并以一定的目录结构保存在配置管理数据库（Configuration Management Databases，CMDB）中。

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

• 基线配置项可能包括所有的设计文档和源程序等。
• 非基线配置项可能包括项目的各类计划和报告等。

所有配置项的操作权限应由配置管理员（CMO）严格管理，基本原则是：

• 基线配置项向开发人员开放读取的权限。
• 非基线配置项向项目经理、CCB及相关人员开放。

配置项状态

配置项的状态可分为草稿、正式和修改三种：

• 配置项刚建立时，其状态为“草稿”。
• 配置项通过评审后，其状态变为“正式”。
• 若更改配置项，则其状态变为“修改”。
• 当配置项修改完毕并重新通过评审时，其状态又变为“正式”。

配置项的版本号

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

配置项版本管理

对配置项的任何修改都将产生新的版本，不能抛弃旧版本，要按照一定的规则保存配置项的所有版本。

配置基线

配置基线：由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。不能再被任何人随意修改，对基线的变更必须遵循正式的变更控制程序。

产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例和使用手册等）也是基线的例子。

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

交付给用户使用的基线一般称为发行基线，内部过程使用的基线一般称为构造基线。

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

配置管理数据库

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

1. 发布内容，包括每个配置项及其版本号
2. 经批准的变更可能影响到的配置项。
3. 与某个配置项有关的所有变更请求。
4. 配置项变更轨迹。
5. 特定的设备和软件。
6. 计划升级、替换或弃用的配置项。
7. 与配置项有关的变更和问题。
8. 来自于特定时期特定供应商的配置项。
9. 受问题影响的所有配置项。

配置库

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

1. 开发库（也称为动态库、程序员库或工作库）：用于保存开发人员当前正在开发的配置实体，如新模块、文档、数据元素或进行修改的已有元素。是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其进行配置控制。

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

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

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

• 按配置项的类型分类建库。这种模式适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。
• 按开发任务建立相应的配置库。这种模式适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以没必要把配置项严格分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。

角色与职责

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

配置管理负责人

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

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

配置管理员

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

1. 建立和维护配置管理系统：建立和维护配置库或配置管理数据库。
2. 配置项识别；建立和管理基线。
3. 配置状态报告。
4. 配置审计。
5. 版本管理和配置控制；发布管理和交付。

配置项负责人

配置项负责人：确保所负责的配置项的准确和真实。具体有：

1. 记录所负责配置项的所有变更。
2. 维护配置项之间的关系。
3. 调查审计中发现的配置项差异，完成差异报告。
4. 遵从配置管理过程。
5. 参与配置管理过程评估。

目标与方针

针对信息系统开发项目，常需要通过实施软件配置管理达到配置管理的目标，即在整个软件生命周期中建立和维护项目产品的完整性。

管理活动

配置管理的日常管理活动主要包括6个主要活动：

1. 制订配置管理计划（写一个文档，叫做配置管理计划，规定如何做好配置管理）。
2. 配置项标识（识别出需要把哪些东西作为配置项来管理）。
3. 配置项控制（配置项有一些变更，需要做好配置变更的控制）。
4. 配置状态报告（需要报告配置项的状态是什么样的）。
5. 配置审计（做好审计，看有哪些好的，哪些不好的经验教训，效果怎么样）。
6. 配置管理回顾与改进（定期回顾配置管理活动的实施情况，发现在配置管理执行过程中有无问题，找到改进点，继而优化配置管理过程）。

制订配置管理计划

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

配置项识别

配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构识别。 它包括为配置项分配标识和版本号等。确定配置项的范围、属性、标识符、基准线以及配置结构和命名规则等。

配置项控制

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

配置状态报告

配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。配置状态报告就是要在某个特定的时刻观察当时的配置状态，也就是要对动态演化着的配置项取个瞬时的“照片”，以利于在状态报告信息分析的基础上，更好地进行控制。配置状态报告应该主要包含：

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

配置审计

功能配置审计：审计配置项的一致性（配置项的实际功效是否与其需求一致），具体验证主要包括：

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

物理配置审计：审计配置项的完整性（配置项的物理存在是否与预期一致），具体验证主要包括：

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

配置管理回顾与改进

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

变更管理

管理基础

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

变更管理与配置管理

变更管理由项目交付或基准配置调整时，由配置管理过程调用，变更管理最终应将对项目的调整结果反馈给配置管理过程，以确保项目执行与项目配置信息相一致。

如果把项目整体的交付物视作项目的配置项，配置管理可视为对项目完整性管理的一套系统，当用于项目基准调整时，变更管理可视为其一部分。

变更的常见原因

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

变更的分类

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

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

变更管理的原则

• 基准管理：基准是变更的依据。
• 变更控制流程化：建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程。
• 明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能。
• 评估变更的可能影响：变更的来源是多样的，既需要完成对客户可视的 成果、交付期等变更操作，还需要完成对客户不可视的项目内部工作的变更。
• 妥善保存变更产生的相关文档：确保其完整、及时、准确和清晰，适当时可以引入配置管理工具。

角色与职责

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

项目经理

项目经理在变更中的作用是：

• 响应变更提出者的需求。
• 评估变更对项目的影响及应对方案。
• 将需求由技术要求转化为资源需求，供授权人决策。
• 并据评审结果实施（即调整基准），确保项目基准反映项目实施情况。

变更管理负责人

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

1. 负责整个变更过程方案的结果。
2. 负责变更管理过程的监控。
3. 负责协调相关的资源，保障所有变更按照预定过程顺利运作。
4. 确定变更类型，组织变更计划和日程安排。
5. 管理变更的日程安排。
6. 变更实施完成之后的回顾和关闭。
7. 承担变更相关责任，并且具有相应权限。
8. 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。

变更请求者

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

1. 提交初步的变更方案和计划。
2. 初步评价变更的风险和影响，给变更请求设定适当的变更类型。
3. 对理解变更过程有能力要求等。

变更实施者

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

变更顾问委员会

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

1. 在紧急变更时，其中被授权者行使审批权限。
2. 定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等。

变更的工作程序

变更的流程：

1. 变更申请：收集变更请求，必须书面化记录。
2. 对变更的初审：变更申请文档的审核流转。
3. 变更方案论证：将变更请求由技术要求转化为资源需求，技术评估和经济与社会效益评估。
4. 变更审查：决定是否变更。
5. 发出通知并实施。
6. 实施监控：确保项目的整体实施工作是受控的。
7. 效果评估：评估变更所要达到的目的是否已达成。
8. 变更收尾：变更后的项目是否已纳入正常轨道。

变更申请

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

对变更的初审

变更初审的目的主要包括：

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

变更方案论证

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

包括技术评估和经济与社会效益评估，前者评估需求如何转化为成果，后者评估变更方面的经济与社会价值和潜在的风险。

一些大型的变更，可以召开变更方案论证会议，通常需要由变更顾问委员会（相关技术和经济方面的专家组成）进行相关论证，并报项目CCB作为决策参考。

变更审查

变更审查过程是项目所有者根据变更申请及评估方案，决定是否变更项目基准。

审查常采用文档、会签形式，重大的变更审查可以采用正式会议形式。

将专业评审、经济评审分开，涉及项目目标和交付成果的变更，客户和服务对象的意见放在核心位置。

发出通知并实施

变更评审通过后，意味着基准的调整，同时确保变更方案中的资源需求及时到位。

实施监控

通过监控行动，确保项目的整体实施工作是受控的。变更实施的过程监控，通常由项目经理负责基准的监控。CCB监控变更明确的主要成果、进度里程碑等，也可以通过监理单位完成监控。

效果评估

变更评估的关注内容主要包括：

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

变更收尾

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

变更控制

• 越大型的项目，调整基准的边际成本越高，随意调整可能带来的后果众多。
• 在项目整体压力较大的情况下，更需强调变更的提出和处理应当规范化，可以使用分批处理、分优先级等方式提高效率。
• 小项目的变更提出与处理过程可在操作上力求简便、高效，但仍应注意对变更产生的因素施加影响，对变更的确认应当正式化，变更的操作过程应当规范化等。

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

• 变更申请的控制：应严格控制变更申请的提交，应当确保覆盖所有变更操作。另外应根据变更的影响和代价提高变更流程的效率。
• 变更过程的控制：对进度变更的控制、对成本变更的控制、对合同变更的控制。

版本发布和回退计划

版本发布前的准备工作包括（先分析，后备份，最后设置说明）

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

回退步骤通常包括：

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

项目文档管理

信息系统相关信息（文档）是指某种数据媒体和其中所记录的数据。它具有永久性，并可以由人或机器阅读，通常仅用于描述入工可读的东西。在软件工程中，文档常常用来表示对活动、需求、过程或结果进行描述，定义规定，报告或认证的任何书面或图示的信息（包括纸质文档和电子文档）。

文档的类型

文档的质量等级

规则与方法

文档的规范化管理主要体现在文档书写规范、图表编号规则、文档目录编写标准和文档管理制度。

1. 文档书写规范。管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是哪种类型的文档都应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等。
2. 图表编号规则。在管理信息系统的开发过程中用到很多的图表，对这些图表进行有规则地编号，可以方便图表的查找。图表的编号一般采用分类结构。
3. 文档目录编写标准。为了存档及未来使用的方便，应编写文档目录。文档名称要书写完整、规范。
4. 文档管理制度。为了更好地进行信息系统文档的管理，应该建立相应的文档管理制度。主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等。需要考虑借阅人是否有使用权限。在文档中存在商业秘密或技术秘密的情况下，还应注意保密。特别要注意的是，项目干系人签字确认后的文档要与相关联的电子文档——对应，这些电子文档还应设置为只读。