管理更改

你可以利用更改请求工作项来跟踪和控制对产品及支持系统进行的所有更改。 由于偏离基线，因此发起了所有更改请求，基线包括针对项目确定的原始要求。 例如，如果与用户进行会议时发现新的要求，则应创建更改请求以建议更新要求基线。 有关 CMMI 的更多信息，请参阅 CMMI 背景信息。

创建更改请求

当意识到必须更改原始要求时，请创建一个更改请求工作项并使用 Affects 链接类型将其链接到旧要求工作项。 还应创建一个包含新增要求或更改内容详细信息的要求工作项，并将其链接到更改请求。 所有更改请求都将进行广泛的分析，以确定其对用户、产品和团队的影响。 在此分析期间，可能会中断任务以进行估算。 这些新任务工作项应链接至新要求工作项以实现可跟踪性。 此操作可通过在工作项窗体的“实施”选项卡上添加任务完成。

更改请求及其产生的新工作项必须包含所需全部新工作以及要删除、修改或排除的全部现有工作的详细信息。 你可以按开始使用工作项中所述，通过 Team Web Access 的主页或团队资源管理器的“工作”页创建更改请求。 你可以指定对“标题”字段要求的更改、进行更改的团队成员以及关于请求的其他信息。

有关如何完成工作项的详细信息，请参阅 CMMI 工作项和工作流。

分析更改请求

在对更改请求进行分析之前，应由配置控制委员会进行会审。 配置控制委员会是一个群体，负责批准和拒绝更改请求并确保正确实施更改。 你可以通过将工作项中的“会审”字段设置为“挂起”指明必须对请求进行会审。 有关详细信息，请参阅更改请求字段引用 (CMMI)。 分析更改请求可能会消耗资源，因此更改请求队列不得对团队形成过分要求，也不得影响项目时间表。

应分析更改请求以确定其对现有工作和计划工作的影响范围。 必须知道影响范围，以确保可以利用它来估算实施更改的工时成本。

分析接受更改的风险。 外部团队的参与是否取决于要更改的代码或功能，他们的日程安排是否会受到不利影响？ 此更改的资源分配是否会对其他重要功能区域或产品要求产生不利影响？

在分析过程中，请求利益干系人提供意见并将该意见添加到更改请求工作项。 如果更改要求对其他计划文档进行更改，请在更改请求中注明并在适当时对这些文档进行更改。 这将保持修订历史记录，方便每个人查看详细信息。 这可以缓解通信不畅产生的风险，并为标准 CMMI 过程改进评估方法 (SCAMPI) 评估提供重要证据。

如果接受更改请求，请将“状态”从“已提议”（新更改请求的默认状态）更改为“活跃”。

监视更改请求

当更改请求处于活跃状态时，你可以通过查看“打开的有要求的更改请求”查询进行监视。 你还可以创建电子邮件警报来通知创建更改请求的时间。 应在合理的时间内处理更改请求。

如果更改请求未得到必要的重视，可通过创建问题工作项将事件升级。 将新问题链接到更改请求，并升级问题使更改请求影响评估回到正轨。