中文翻译《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：识别配置项。根据配置管理策略识别需要存储、测试、评审、使用、更改、交付和/或维护的配置项。

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

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