中文翻译《ASPICE in practice》之“SUP.8 配置管理”

2.16 SUP.8 配置管理

2.16.1 目的

配置管理流程的目的是建立和维护流程或项目的所有工作产品的完整性，并将其提供给相关各方。 

在配置管理（CM）的背景下，配置管理系统至关重要。 我们指的是一个或多个 CM 工具的组合，以支持物理存储和处理以及相关规则，例如指令、流程和约定； 后者例如用于变更管理、版本控制或访问限制。 CM工具不一定需要包含特定的配置管理软件。 这可能只是将文件存储在文件系统上的问题。 CM 工具提供的功能越少，就越需要适当的规则支持。

2.16.2 汽车行业特有的特征

由于不同学科（硬件、机械、软件等）的同时开发，我们面临着异构的工具环境。 在软件中，我们通常会发现部署了一种标准的 CM 工具。 用于机械构造 (CAD) 和电路板布局的工具通常有自己的集成版本控制系统。 例如，物料清单通过 SAP 进行管理。 通常，某些文档（例如规范、设计文档）被故意保存在 CM 工具之外并存储在文件系统上，例如在 Windows 下。 最常见的原因是，并非参与项目的每个人都可以使用 CM 工具，或者他们没有接受过使用该工具的培训。

这种情况使得配置管理比纯软件项目更加困难：组织必须创建一个系统，允许在某些时间点（例如，原型交付日期）识别所有配置项（例如，文档、代码模块） 、数据、开发环境）与定义的开发水平（所谓的基线）相关。 这可以通过在每个工具中绘制局部基线并在表中指定关联来完成。 或者，数据可以存储在CM工具中，然后自动镜像到通常可访问的文件存储介质上。 大多数 CM 工具都支持这种方法。 在实践中，汽车行业的配置管理经常在这些学科的协调方面表现出弱点。

评估员注意事项

在此过程中至少应评估以下问题：

1. 如果项目中有不同的学科（硬件、机械、软件等），对于跨工具传播的 CM 是否有令人信服的概念？ 开发工具之间的不匹配是否得到了补偿？
2. 原则上，CM 元素的选择是否足以定义基线？ 换句话说，是否有可能根据CM要素重建特定发展状态的基线？
3. 变更是否有可追踪记录？
4. 是否对各个 CM 元素和基线进行一致性检查（至少在交付之前）？

无论如何，都应该研究CM工具，并对CM元素的变更进行抽样检查，以检查变更是否全面反映在变更历史中。

2.16.3 基本实践

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

注意：配置管理策略应记录在配置管理计划中。

注意：配置管理策略还应支持处理产品/软件变体。

这包括基本配置管理活动和相关日期，例如：

1. 从何时起，特定 CM 项目将置于 CM 控制之下（例如，从哪个里程碑开始或从配置项目的哪个成熟度级别开始）。
2. 配置管理工具。
3. 如何创建基线的过程。这在异构工具环境中尤其重要（与第 2.16.2 节比较）；例如，如果在一个表中指定了与多工具环境相关的基线。
4. 如何管理产品和软件变体的过程。
5. 如何使用配置管理支持集成的过程。
6. 使用配置管理工具创建产品版本的必要步骤。
7. 与交付相关的放行程序（即产品是否包含正确的组件、是否已执行规定的测试、谁授权交付以及以何种方式授权）。

结果通常记录在 CM 计划中。

BP2：识别配置项。根据配置管理策略识别需要存储、测试、评审、使用、更改、交付和/或维护的配置项。

注意：需要配置控制的项应包括交付给客户的产品、指定的内部工作产品、采购的产品、工具以及用于创建和描述这些工作产品的其他项。

注意：软件开发配置项通常包括：

1. 配置管理计划
2. 需求文档、架构和设计文档，
3. 软件开发环境，
4. 软件开发计划，
5. 供应商协议，
6. 质量计划，
7. 软件单元（代码）包括文档，
8. 测试用例和测试结果，评审文档，
9. 构建列表，集成报告和
10. 客户手册。

注意：需要配置控制的项还可能包括硬件（布局、图纸、电路板、物料清单等）和机械开发的工作产品。

CM 元素是受 CM 控制的项（例如文件）。这些在 CM 计划中指定，当然，其中只指定了文件类型，而不是每个单独的文件（即源代码而不是代码文件 xyz）。

在大多数情况下，只有选定的工作产品受 CM 控制。此选择必须允许绘制合格的基线（参见 BP5），即确保实际上所有描述特定开发阶段的元素（需求和设计文档、开发环境、变更请求、测试用例、测试文档，也可能是重要的中间工作产品等）都可以在 CM 系统中进行基线。这样，只需按一下按钮，就可以随时完全重现各个开发阶段。开发阶段包括内部阶段和交付给客户的阶段。

在实践中，软件项目中发现的一个非常常见的问题是，只有代码受 CM 控制，而没有相关文档和文件（参见上一段中的列表）。但是，标准的 BP5 要求对此类工作产品进行基线处理。

BP3：建立配置管理系统。建立配置管理系统，提供处理配置项的有效方法。

注意：配置管理系统可能包括存储介质、结构和层次结构、程序、访问控制和用于访问配置项的适当工具。

如前所述，配置管理系统 (CM 系统) 对于实施有效的配置管理至关重要。一般来说，自动化程度越低，负责 CM 的个人就必须花费越多的精力，例如，检查基线的正确性和完整性，或确保在归档系统上正确完成手动版本控制。CM 系统的其他重要方面是支持分布式开发或支持供应商和 OEM 之间不同 CM 系统的接口。在分布式开发中，联合管理的 CM 工具或至少联合管理的数据归档系统肯定会有优势。但是，在这些情况下不能忘记的一件事是访问保护。对于通用 CM 系统，以下问题尤其重要：

1. 谁有权访问 CM 元素，例如源代码或项目规划文档？
2. 系统管理员的角色是什么，他的权利是什么？
3. 速度和可用性是否足够？
4. 如何同步联合活动（文件锁定机制、信号量）？

对于单独的 CM 系统，至少应该回答以下问题：

1. 何时交换什么数据？
2. 哪些 CM 元素的主数据在哪里？
3. 基线是否分布在独立的系统中，如何绘制和管理它们？
4. 交换的信息或文件如何进入本地 CM 系统？
5. 我们如何确保更改得到一致合并（例如，在本地副本中）？
6. 对于通用 CM 系统，还有同样的问题：如何同步联合活动（文件锁定机制、信号量）？

在这两种方法中，可能都必须考虑分支管理策略（参见 BP4）。

BP4：制定分支管理策略。为使用相同源库的并行开发工作制定适用的分支管理策略。

注意：分支管理策略将包括分支管理、合并策略、分支系统中的配置项版本控制、分支父级策略和标签策略。

注意：分支管理策略将定义创建分支的原因和时间、分支中将发生哪些活动以及分支将如何完成和/或迁移到主源库。

有些情况下，同一个 CM 项需要并发开发，例如，如果多个开发人员同时处理同一个代码组件。如果开发人员并行工作并纠正缺陷，这种情况经常发生。在这些情况下，开发人员在原始配置项的物理独立副本上工作，即在主 CM 项的所谓“分支”上工作。最后，必须再次合并所有更改。但是，合并功能无法防止由于并行开发而导致的错误。在这种情况下，对相关配置项的质量保证的要求更高。因此，该策略可以规定成功合并后需要进行审查。

因此，需要制定法规，规定是否以及在哪些情况下允许分支、如何命名和版本控制配置项的副本、如何进行合并、需要哪些验证步骤（例如，审查、测试）以及应该如何与基线进行交互。软件开发环境中的高级 CM 工具通过自动版本控制和自动合并来支持分支，并指示可能出现的冲突。

BP5：建立基线。根据配置管理策略建立内部和外部（交付）基线。

注意：在包含许多工作产品的复杂软件系统中，可以通过合理使用多个中间内部基线来支持外部（交付）基线的准备。

注意：有关基线问题，还请参阅产品发布流程 (SPL.2)。

基线表示一组 CM 项，用于标识开发中的特定状态。相关配置项将相应地标识。每个配置项都采用特定的不可修改版本。只能创建其后续版本。这样，可以保护项免受更改，并且可以随时重建开发状态，无论是部分重建还是整体重建。属于基线的项必须彼此一致（另请参阅 BP10）。

每次交付（即发布）时都应绘制基线。此外，还应为内部目的创建基线，例如，如果需求稳定，如果设计成熟，或者正在制作测试或试验版本。

为了唯一地标识基线，许多 CM 工具提供了一种“标记”基线的机制，即为受影响的 CM 项目的所有版本分配相同的标签，例如“第 3 次交付状态”。“浮动”和“固定”标签之间有所区别。浮动标签始终附加到 CM 项目的最新版本，即它会自动转移到最新版本。因此，很容易识别最新的开发状态。相反，固定标签不能移动。使用这种方法，CM 项目可以“冻结”以进行基线。

BP6：维护配置项描述。维护每个配置项的最新描述。

注意：描述应标识：

1. 其分解为较低级别的配置组件；
2. 谁负责每个项目；以及
3. 何时将其置于配置管理之下。

此类描述通常存储在不同的地方，例如，在 CM 工具中或在文档本身中。例如：

1. CM 项的描述/阐述，包括归类到可能存在的 CM 项层次结构中
2. 配置项修改的描述（例如，在签入之前的 CM 工具中）或配置项本身（在更改历史记录中）
3. CM 项、作者等的责任

无论单个 CM 项如何，项描述也可以存储在项目描述或 CM 计划中，例如：

1. CM 项类型的描述
2. 定义从何时开始将工作产品类型置于 CM 之下（例如，从特定开发阶段或特定成熟度级别的工作产品开始）。

必须为这些描述建立规则（例如，在 CM 计划或流程描述中），例如：

1. 如何在文档中保留更改历史记录。
2. 如何记录 CM 系统中的更改。
3. 版本控制策略是什么（特别是如果 CM 工具不提供此功能）。

BP7：控制修改和发布。建立机制以确定要更改的配置项、签入/签出、配置项访问权限、版本标识和更改、更改注释、配置项锁定/提交。

必须能够标记要更改的 CM 项，例如，通过将其状态设置为“修订中”；还可以将项签入和签出 CM 工具。如果签出 CM 项，则应将其锁定以供其他用户使用，即仅允许读取访问，或者要求在签出之前创建分支（参见 BP4）。在签入更改的 CM 项期间，必须分配新的版本号并再次发布 CM 元素。必须防止未经许可的访问。必须描述与先前状态相比的变化（通常在 CM 系统和 CM 项中）。系统记录所有操作。

在许多 CM 工具中（例如，用于软件、CAD、印刷电路板布局），这些机制由工具预设。然而，这并不意味着这些设施实际上被工作人员使用（例如，在签入期间是否提供了相关评论？）。存储在文件系统中的工作产品会出现更大的问题，因为必须手动执行机制（文件名中的唯一版本控制、文档中的更改历史记录、访问权限等）。例如，必须在 CM 计划中安排适当的手动配置管理裁定。

BP8：维护配置项历史记录。维护每个配置项的足够详细的历史记录，以便在需要时恢复先前的基准版本。

这意味着需要对 CM 项的更改进行历史记录。有两个地方可以维护更改历史记录：

1. 在 CM 工具中
2. 在工作产品中

最好的方法取决于具体情况，并且因工作产品而异。如果工作产品保存在 CM 工具中，则其功能肯定应该用于记录更改。如果不是这种情况，工作产品本身应该包含更改历史记录。但是，单个修改说明必须足够详细，以便能够重建更改。在变更管理的背景下，记录更改 ID 尤为重要（参见 SUP.10）。

常见的弱点是缺少或毫无意义的修改说明，甚至完全缺少控制和变更文档。后者经常出现在经过多次修改的工作产品中（例如，时间表），通常只有一个版本（当前版本），并且没有记录更改。

BP9：报告配置状态。报告每个配置项的状态。

注意：定期报告配置状态（例如，当前有多少配置项正在工作、签入、测试、发布等）支持项目管理活动和专用项目阶段，如软件集成。

需要报告 CM 项的开发状态以支持项目跟踪。典型状态有错误、锁定、工作中、已审查、已测试、已批准等。项目越大越复杂，这种基本做法就越重要。它对于以下活动尤其重要：

1. 集成活动：集成代表获得有关各个开发人员工作状态的概览。CM 工具只需按一下按钮即可提供此信息。
2. 变更管理活动：哪些变更请求仍未解决，例如针对特定版本？如果使用与 CM 工具交互的变更管理工具，通常只需按一下按钮即可提供变更请求的各个状态（例如，请求、正在分析、正在进行、正在测试）。
3. 项目管理活动：当前项目状态如何？

BP10：验证有关配置项的信息。验证通过状态核算报告提供的有关配置项、其结构和基线的信息是否完整，并确保项和基线的一致性。

必须执行检查并采取相应的纠正措施，以确保 CM 项、基线和 CM 系统一致。一个至关重要的问题是如何确保基线绘制得当（特别是当我们谈论要交付给客户的发布版本时）。是否包含了正确的文件（这在并行开发、变体、分布式开发或工具链中的间隙的情况下尤其重要）？是否实际包含了交付计划的所有更改？是否检查了 CM 项是否按照计划进行了实际测试？这种检查也称为“CM 审计”或“基线审计”。

CM 审计是指对整个 CM 系统及其结构的检查、惯例的抽样检查等。这些检查的结果必须报告给相关项目人员（例如 CM 代表和项目经理）。

可以通过以下事实来识别验证措施不足：已更正的缺陷不时重新出现，或者已承诺的功能未包含在发布版本中（并且未给出任何通知）。

BP11：管理配置项的备份、存储、归档、处理和交付。通过适当的备份、存储和归档安排和资源配置，确保配置项的完整性和一致性。控制配置项的处理和交付。

重要问题包括：

1. 是否保证定期进行备份（例如每周）并进行归档（项目完成后）？（典型弱点的一个例子是：定期进行备份，但基于滚动磁带系统。例如，每周都会创建一盘备份磁带。但是，只有 20 盘磁带，第 20 周后，磁带 1 被覆盖。由于项目生命周期要长得多，如果需要，恢复旧版本是不可能的。）
2. 交付给客户的所有工作产品（例如软件、硬件、开发文档、测试日志）是否彼此一致？软件是否根据声明的版本进行自我标识？
3. 在由软件和硬件组成的产品交付过程中：软件和硬件如何组合？哪个软件版本与哪个硬件版本相匹配？谁将把软件加载到硬件上，如何加载？进行哪些最终检查？例如，如何确保版本信息一致（硬件上的标签、软件 ID、随附文档中的版本等）？

必须有足够的资源（即人员和技术基础设施）来处理所有这些问题。必须规划和安排相关活动。

2.16.4 指定工作产品

01-00 配置项

配置项 (CM 项) 标识使用配置管理进行管理的对象。这些可以是与软件相关的项，如软件单元、子系统和库，也可以是测试用例、编译器、数据、文档、物理媒体和外部接口。应维护最低版本标识，并提供描述，例如指定类型、负责人、状态信息和与其他 CM 项的关系。在大多数情况下，CM 项之间存在相互依赖关系，例如，一个子系统的软件单元与另一个子系统的软件单元之间存在相互依赖关系。这些依赖关系有助于集成、缺陷消除、更改和支持可追溯性。

08-04 配置管理计划

CM 计划是中央 CM 规划工具。它包含从 CM 角度对项目很重要的所有相关规定。CM 活动的具体计划通常可在其他规划文档（即项目计划）中找到。许多组织提供通用 CM 计划，从中得出特定于项目的 CM 计划。

CM 计划的示例结构

1 有关 CM 的角色和授权

2 涉及的人员

3 从 CM 角度看的项目结构

4 从 CM 角度看的产品结构

5 CM 项

5.1 CM 项类型

5.2 CM 项的命名约定

5.3 CM 下的开发工具

6 基线和发布

6.1 基线和发布的命名约定

6.2 计划的基线和发布

7 构建过程

7.1 配置的复制

7.2 构建过程的描述

8 CM 环境

8.1 CM 工具

8.2 物理存储位置

8.3 CM 库的结构和交互

8.4 访问权限

8.5 CM 库的备份

8.6 一致性检查

9 变更管理

10 发布存档

16-03 配置管理库

关于配置管理库 (CM 库) 的构成，有两种不同的观点。它通常被理解为项目特定 CM 系统的中央存储，可随时从中恢复正确的产品（包括发布和测试配置），并可借助它识别 CM 项目的状态。但是，CM 库也可以用作跨项目重用的工具，在这种情况下，它包括可重用软件单元、功能描述、测试用例等的库。

2.16.5  2 级的特征

关于绩效管理

根据 Automotive SPICE，CM 规划分为两个步骤：在 1 级，几个基本实践（例如 BP1、BP2、BP4 和 BP11）已经需要基本规划项目，即主要程序、资源提供和 CM 活动时间表。在级别 2，随着流程属性 PA 2.1 的通用实践，增加了更多规划要求，例如关于职责分配和资源规划（参见第 3.3.3 节，对 PA 2.1 的审议）。

关于调度问题：对于许多 CM 活动（例如，配置项的频繁签入和签出），调度没有意义。但是，与创建发布或 CM 审计相关的活动是可以合理规划的。

关于工作产品管理

GP 2.2.3 要求配置管理过程本身具有配置管理功能。虽然配置管理过程专用于整个项目的工作产品，但 GP 2.2.3 针对的是过程的工作产品。例如，后者意味着 CM 计划本身作为过程的核心工作产品，需要置于 CM 控制之下，即它至少必须进行版本控制并提供变更历史记录。