SG 2 跟踪并控制变更

置于配置管理下的工作产品的变更得到跟踪与控制。

在“建立基线”特定目标下的特定实践建立基线后，CMMI-DEV模型中，本特定目标下的特定实践用来维护基线。

SP 2.1 跟踪变更请求

跟踪对配置项的变更请求。

CMMI模型提出，变更请求不仅应对新需求或需求变更，也可应对工作产品的故障与缺陷。分析变更请求，以确定变更将对工作产品、相关工作产品、预算与进度带来的影响。

CMMI模型中，CM过程域的工作产品实例：

1. 变更请求

CMMI模型中，CM过程域的子实践：

1. 发起变更请求并记录在变更请求数据库中。

2. 分析变更请求中提议的变更与修复的影响。

通过确保变更与所有技术及项目需求一致的活动来评价变更。

评价变更对直接的项目或合同需求之外的影响。对在多个产品中使用的配置项的变更可能解决一个直接问题，而在其它应用中又引发一个问题。

评价变更对发布计划的影响。

3. 对变更请求分类并划分优先级。

识别紧急请求，适当时提交给紧急权限。

将变更分配到将来的基线中。

4. 与相关干系人一起评审将要在下个基线中处理的变更请求，并达成一致。

与适当的参加者一起进行变更请求的评审。记录每一变更请求的处置与决策理由，包括成功准则、适当时一份简要的行动计划、以及变更满足的或不满足的需要。执行处置中要求的行动并将结果汇报给相关干系人。

5. 跟踪变更请求的状态直到关闭。

要及时有效地处理纳入系统的变更请求。一旦变更请求得到处理，只要切实可行，以适当的经批准的行动尽快关闭此请求非常关键。让措施长时间处于未关闭状态会让状态列表变得过于庞大，反而会导致附加的成本与混乱。

SP 2.2 控制配置项

控制配置项的变更。

对工作产品基线的配置保持控制。这种控制，在CMMI-DEV模型中包括跟踪每个配置项的配置、必要时批准新的配置、以及更新基线。

CMMI模型中，CM过程域的工作产品实例：

1. 配置项的修订历史

2. 基线的存档

CMMI模型中，CM过程域的子实践：

1. 在整个产品或服务的生命期，控制对配置项的变更。

2. 在变更后的配置项进入配置管理系统前，获得适当的授权。

例如，授权可来自配置控制委员会、项目经理、产品负责人或客户。

3. 以维护配置项的正确性与完整性的方式，在配置管理系统中检入并检出配置项以纳入变更。

检入与检出步骤的实例有：

    • 确定这些修订得到授权

    • 更新配置项

    • 将旧基线归档，并检索新基线

    • 为该项的变更作备注

    • 关联对相关工作产品的变更，例如需求、用户故事与测试

4. 执行评审以确保变更没有对基线造成意外的影响（例如，确保变更没有危及系统的安全性或保密性）。

5. 适当时记录配置项的变更与变更的理由。

如果接受对工作产品提议的变更，则识别将变更纳入工作产品及其它受影响区域的进度。

可针对变更类别裁剪配置控制机制。例如，对于不影响其他组件的组件变更的批准考虑可用较低严格度。

已变更的配置项，需经配置变更的评审与批准后才能发布。直到发布后，变更才正式生效。

【CM过程域相关文章】

CMMI过程域详解-配置管理（CM）之概述

CMMI过程域详解-配置管理（CM）之SG 1

CMMI过程域详解-配置管理（CM）之SG 2

CMMI过程域详解-配置管理（CM）之SG 3