中文翻译《ASPICE in practice》之“SUP.10 变更请求管理”

2.18 SUP.10 变更请求管理

2.18.1 目的

变更请求管理流程的目的是确保变更请求得到管理、跟踪和控制。

变更管理的目的是以结构化和可跟踪的方式收集变更请求，并分析、实施和监控其进展状态。这种能力对于组织来说极其重要，因为没有项目没有变更。相反，许多项目实际上被变更淹没了。主要原因是：

1. 因缺陷消除而导致的变更（另见 SUP.9）
2. 产品生命周期迅速缩短，因为制造商被迫在越来越短的周期内将创新推向市场。由此导致的开发交付周期的大幅缩短使得在早期开发阶段（需求、设计）中采取足够的谨慎措施变得越来越困难。最重要的是，制造商认为有必要对新竞争产品的属性做出反应，结果他们允许许多（甚至是晚期）变更。

许多开发组织无法阻止变更浪潮。组织控制变更管理并在成本和进度限制内生产高质量产品的能力正成为区分竞争对手的一个日益重要的因素。在实践中，变更管理有两个不同的级别：

1. 涵盖项目合同工作范围的级别。在此级别，管理与成本无关但包含在开发范围内的小变更和错误修复（级别 1）。
2. 涵盖项目合同范围之外的工作的级别：在此级别，通常与成本相关且未包含在开发范围内的变更将进行协商、跟进和实施（级别 2）。

两个级别的决策权有所不同：在级别 1，决策由项目团队内部做出，在级别 2，则引入更高的决策级别，即高级管理层。在级别 2，将执行额外的工作步骤，例如发布补充要约。两个级别的流程相互作用，即在级别 2 批准的变更将触发级别 1 的实施步骤（基本实践 9-12）。 SUP.10 主要侧重于第 1 级。

实际上，供应商和客户通常已经在组织级别建立了自己的独立变更请求管理系统。在项目内建立变更请求管理系统时，需要注意现有变更管理系统实际上可以相互链接，并且所有相关方对共同变更请求管理系统的要求都得到同等考虑。

变更请求管理工作流程与问题解决管理使用的工作流程非常相似（参见 SUP.9，同样涉及两个过程的相互划分）。

评估员注意

由于流程要求相似、处理方式相同且责任相同，因此经常将两个流程的访谈合并在一起。（另见 SUP.9）。应注意两个流程的相互作用：SUP.9 可以为 SUP.10 提供输入。

2.18.2 汽车行业特有的特征

在汽车行业，其他原因也可能导致变更请求。在大多数情况下，只有大规模部署同步工程才能缩短开发时间，即同时开发不同的产品组件，但这些组件之间存在许多交叉关系，因此在开发生命周期中必须进行大量变更。目前正在采取的另一种方法是平台策略，即开发独立于车型范围的平台。针对每个车型范围和每个客户，都会开发通用平台组件的定制变体。如果需要进行更改或与车型无关的组件出现缺陷，则所有基于这些组件的开发分支也需要进行更改或调整。

2.18.3 基本实践

BP1：制定变更请求管理策略。制定变更请求管理策略，包括变更请求管理活动和生命周期模型、执行这些活动的职责和资源。

此策略可作为变更请求记录、管理和处理的指南和说明。变更请求管理从变更请求开始，到变更被证实实施或被拒绝结束。变更程序和机制通常在变更管理计划中描述。

除了 SUP.9 BP1 中已经说明的关于策略的要点外，在处理变更请求时还需要考虑以下几点：

1. 每个变更都要进行可行性分析，分析可能的风险（例如技术风险）。结果有可追溯的记录。
2. 在实践中，应指定将实施变更请求的版本。

BP2：建立一致的变更请求管理程序。建立并实施变更请求管理程序，以确保根据变更请求管理策略以一致且可追溯的方式检测、描述、记录、分析和管理变更。定义并维护与受影响方的接口。

特别是在包含子项目的大型项目中，有必要随时获得所有变更请求及其实施状态的概览。为了避免费力的手动信息收集，最好建立变更请求管理系统。此外，确定一个中央联系人（例如项目经理）以便能够集中记录变更请求也是一个好主意。

在实践中，变更请求和问题通常是联合管理的（关于划分，请参阅 SUP.9）。然而，偶尔会实施多个变更请求管理系统，具体取决于变更的类型（例如，需求变更、其他变更）。如果涉及不同的组或项目非常大，通常会发生这种情况。通常，变更请求的实施和问题的解决会采用相同或非常相似的指导方针（另请参阅我们在 SUP.9 BP2 中的讨论）。

BP3：识别并记录变更请求。每个变更请求都将被唯一地标识和记录，并保留变更请求的发起者。

注意：提供对原始问题或错误报告的可追溯性。作为问题或错误报告的解决方案而提交的变更请求应保留与原始问题或错误报告的链接。

变更的实施从其描述开始。描述越具体、越详细，就越容易对可行性和影响进行必要的分析，并更新相关文档（例如，需求、架构、设计、测试）。记录变更后，必须唯一地标识和集中管理变更（例如，通过列表或数据库）。变更和问题通常是共同管理的。如果两者以后可以轻松分离，例如，以便进行统计评估，则对此没有异议。

所需变更在变更请求管理系统或包含所有必要信息的列表中记录和管理（另请参阅 SUP.9 BP3）。记录变更请求时，还需要考虑以下几点：

1. 内部评估结果（可行性分析/风险）
2. 参考所依据的问题或事件报告

参考潜在问题或事件报告建立了 SUP.9 和 SUP.10 之间的联系。一方面，这是实施变更请求的人员的信息，另一方面，这对于跟踪 SUP.9 内的实施状态也很重要。

BP4：记录变更请求的状态。变更请求和变更被分配一个状态指示，以方便跟踪。

注意：变更请求状态通常表示为打开、正在调查、拒绝、推迟、批准实施、分配（即分配给开发人员实施）、实施、修复、关闭等。

分配状态使跟踪变更的实施变得容易得多。每个实施阶段都意味着一个新的状态，通过该状态，客户和项目人员可以跟踪实施进度（参见 SUP.9 中的状态模型，图 2-15）。

BP5：建立与其他变更请求的依赖关系和关系。确定变更请求与其他变更请求的关系以建立依赖关系，例如，针对特定软件组件的所有变更或与特定软件版本相关的所有变更。

如果多个变更请求涉及一个组件，或者如果要在一个软件版本中实施多个变更请求，则出于同步的原因，了解依赖关系尤为重要。如果由于一个问题而提出多个变更请求（例如，针对不同的组件），则存在进一步的依赖关系。如果没有这些知识，就不可能充分证明问题已成功消除，例如通过测试。

BP6：评估变更的影响。评估变更请求的技术影响和潜在利益。

注意：变更请求委员会 (CRB) 是用于评估变更请求的常用机制。

第一步，必须确定变更请求对项目的技术影响和潜在利益。这在变更请求委员会 (CRB，通常也称为变更控制委员会，CCB) 会议上完成。在小型项目中，CRB 通常仅由一人组成（例如，项目经理）。然而，在大型项目中，委员会主要由项目经理、子项目经理和其他具有全面经验、对各个子领域（例如，软件、硬件、机械、系统）有良好概述和专业领域知识的人员组成。至少要考虑以下主题：

1. 技术可行性（例如，对架构、设计、编码和测试活动的影响）
2. 受影响子领域的潜在利益
3. 非技术因素在 BP7 中确定。

BP7：分析变更请求并确定其优先级。变更请求的分析依据包括资源需求、调度问题、风险和收益。对于每个变更请求，都会指定一个优先级，以表明要考虑的变更请求的紧急程度。

注意：对于调度问题，还请参阅产品发布流程 (SPL.2)。

在识别非技术因素时，会考虑变更实施可能产生的影响和风险。此外，还必须定义确认成功实施的标准。以下其他问题需要详细考虑：

1. 资源需求/员工工作量
2. 对最终用户的影响
3. 对项目的影响（资源情况、流程顺序、截止日期变化、工作量等）
4. 合同中可能未规定的成本或额外成本
5. 紧急程度，即考虑到发布计划，距离预定实施还剩多少时间
6. 实施风险

BP8：实施前批准变更请求。变更请求在实施前根据优先级和资源可用性进行批准。

对于每个变更请求，必须做出关于其实施的决定并记录在案，同时考虑到前面基本实践中确定的时间表、员工工作量和后果。这不仅仅是一个简单的“是”或“否”决定，而且还要决定实施日期。在迭代开发中，通常从等待实施的请求数量中选择单个变更请求，并将其分配给不同的迭代/版本（另请参阅 BP10）。

BP9：确定并规划要对已实施变更执行的验证和确认活动。在实施变更之前，需要确定并规划要进行的验证和确认活动。

必须指定用于验证和确认变更的措施。通常，这些措施是测试、试验或审查，用于验证变更是否根据 BP7 中要求的优先级正确实施。其目的是证明以下内容：

1. 变更符合客户要求和市场要求。
2. 变更的实施在技术上没有缺陷。
3. 变更未导致任何不良副作用，例如，已验证的功能不再起作用。为了确保现有功能，需要执行回归测试（参见 ENG.8 和 ENG.10）。

BP10：安排和分配变更请求。已批准的变更请求将安排到特定交付，并分配给负责实施、验证和确认的资源

BP8 中发布的变更计划用于特定目标发布，并使用通常的项目管理方法（即规划和跟踪）传递给项目专家或团队进行实施、验证和确认。

BP11：审查已实施的变更。在实施、验证和确认之后以及结束之前对变更进行审查，以确保它们具有预期效果并满足其目标和各自的验证标准。

在实施、验证和确认变更之后进行审查，以验证每个变更是否已根据其目标正确实施。一般而言，此类审查由项目人员进行，重点关注以下问题：

1. 采取的措施是否有效？
2. 问题是否已永久解决？
3. 是否需要采取额外措施来避免问题再次发生？

考虑以前的测试或其他验证措施（例如审查）的结果。如果审查结果为肯定，则认为变更已成功完成；如果不是，则需要返工。必须记录评审结果，以备日后证据。

BP12：跟踪变更请求直至结束。向发起人提供反馈。

变更成功完成后（参见 BP11），变更发起人和所有相关方将根据定义的程序（BP2）收到明确的反馈，从而确保信息反馈。

2.18.4 指定工作产品

08-28 变更管理计划

变更管理计划定义了如何记录和实施项目中的变更。它描述了变更的生命周期，从变更的识别开始，然后是变更的记录、分析、描述和管理，最后是变更的实施。它还定义了变更可能经历的状态。在实践中，这些内容通常在组织级别的流程描述中定义，可能由项目特定的定义补充（另请参阅 SUP.9 08-27—问题管理计划）。

13-16 变更请求

变更请求通常包含以下部分：

1. 变更目的或变更描述
2. 状态
3. 发起人、联系信息
4. 受影响的系统
5. 对相关文档的影响
6. 关键性、预期实施日期
7. 验证/确认措施

13-21 变更控制记录

变更控制记录用于跟踪针对特定开发基线的变更。变更的客户要求和其他类型的变更请求经常会导致不同文档和系统组件的各种详细变更。变更控制记录指定所需变更（例如，通过引用变更请求）以及与之相关的所有单个变更。例如，在文档中，这可以在变更历史记录中或通过 CM 系统完成。重要的是，单个变更可以追溯到原始变更请求。

例如，变更控制记录可能包含以下信息（另请参阅 SUP.9 13.07—问题记录）：

1. 变更请求参考
2. 受变更影响的系统和文档，以及变更所涉及的所有单个变更的列表
3. 负责变更的人员
4. 变更描述
5. 相关批准

评估员须知

在评估中，变更机制的有效性可以通过对单个变更进行抽样检查来最好地重建。

2.18.5  2 级的特征

与 SUP.9 相同