配置管理漫漫谈之基准建立和变更的时机

在之前的文章《配置管理漫漫谈之配置管理主要活动及实现方法》中，介绍了配置管理活动及实现方法，但是有很多朋友对其中基准建立和变更的时机不清楚，我们今天来交流一下。

首先我们温习一下“基准”的概念：经过正式评审和认可的一组配置项，它们作为进一步开发的基础，并且只有经过正式的变更控制流程才能被更改。从这个概念中，我们知道基准是进一步开发的基础，这就明确了我们进行基准建立的时机，即在下一步的开发开始之前建立上一阶段工作产品的基准。示例如下：

• 项目计划基准：需求分析开始之前
• 需求分析基准：系统设计开始之前
• 系统设计基准：系统测试用例开始制定之前
• 系统测试基准：系统测试开始执行之前
• 概要设计基准：集成测试用例开始制定之前
• 集成测试基准：集成测试执行开始之前
• 详细设计基准：代码开发开始之前
• 系统代码基准：提交测试之前
• 确认测试基准：确认测试用例开始制定之前
• 用户手册基准：确认测试执行开始之前
• 支持工具基准：根据工具应用类型，在使用该工具的工作开始之前建立基准

对于上一阶段尚未进行完毕下一阶段已经开始的情况，应先建立上一阶段工作产品的基准，在此阶段进行完毕之后，再进行基准变更。

我们从一个实例来看一下基准建立的时机：

假设项目需求分析尚未完全完成，但已需要开始进行系统设计，则应先建立需求分析基准，然后开始进行系统设计，待需求分析完成或者需求分析基准变更时再对需求分析基线进行变更。

 

对于基准变更，我们一般认为不同类型配置项的变更时机如下：

• 项目计划基准：变更请求导致自身变更或者被其他配置项变更影响时
• 需求分析基准：变更请求导致自身变更或者被其他配置项变更影响时
• 系统设计基准：变更请求导致自身变更或者被其他配置项变更影响时
• 系统测试基准：变更请求导致自身变更或者被其他配置项变更影响时
• 概要设计基准：变更请求导致自身变更或者被其他配置项变更影响时
• 集成测试基准：变更请求导致自身变更或者被其他配置项变更影响时
• 详细设计基准：变更请求导致自身变更或者被其他配置项变更影响时
• 系统代码基准：变更请求导致自身变更或者被其他配置项变更影响时
• 确认测试基准：变更请求导致自身变更或者被其他配置项变更影响时
• 用户手册基准：变更请求导致自身变更或者被其他配置项变更影响时
• 支持工具基准：自身变更或者根据工具应用类型，变更请求导致自身变更或者被其他配置项变更影响时

为应对部分类型配置项(如需求分析)的频繁变更，一般可根据实际情况规定如预计在一定时间(如5个工作日)内特定类型配置项的变更还会出现则可集中做一次变更，如周一接受可一个需求变更，预计周三还会有需求变更，则可合并两次需求变更做一次变更执行。但是这样的情况不应该经常出现，原则上变更不合并执行。

一次配置变更可能包含一个或者多个配置基准。

我们从一个实例来看一下基准变更的时机：

假设某个项目已经进展到 系统测试 阶段，已经建立的基准有项目计划基准、需求分析基准、系统设计基准、概要设计基准、详细设计基准、系统代码基准、集成测试基准、系统测试基准，客户方提出 删除一个需求，此变更请求请分析后确定工作量为4h，可通过加班完成，不影响里程碑完成，直接影响需求分析基准，间接影响详细设计、系统代码、系统测试基准，因此需要对需求分析、系统测试、详细设计、系统代码基准进行变更。

 

在实际实施过程中，很多人往往会疑惑于“影响”的概念，什么样才叫影响？如仅仅进行了很少文字上的修正，不影响其他的配置项，也需要进行基准变更吗？我们建议所有对已经基准化的配置项的变更都走正式的变更流程，但是为了避免/减少没有价值的变更，允许对不影响其他工作的配置项变更不做正式的基准变更，待有其它影响工作的变更时再一起进行正式的基准变更。

假设项目进行到了编码阶段，但是因为开发人员发现了详细设计中不完善的地方，如概述文字描述错误，而对其进行修改，由于此修改不影响编码工作，则可不进行正式的基准变更，如修改了函数参数等影响编码工作的地方，则需进行正式的基准变更。

 

值得注意的是，如需求、设计的变更是否会影响其他工作的进行较容易判断，但是对于项目进度计划(当然，部分组织不把项目进度计划作为项目计划基线的一部分)，几乎任何变更都会影响其它工作，是否每次变更都需要走正式的基准变更流程呢？对于很多项目来说，项目进度计划变更频繁，次次进行基准变更并不合适，因此一般约定对项目里程碑进行变更时才进行正式的基准变更。

 

基准建立和基准变更需要及时进行，否则如有交叉变更出现则很容易导致管理上的混乱。