配置管理是 ASPICE 支持过程组的基础过程，负责识别项目中的工作产品与配置项，建立并维护版本标识、基线与变更历史，保证所有交付物状态清晰、可追溯、可复现。评估师核查 SUP.8 过程时，重点关注配置项是否完整识别、基线是否按阶段建立、版本是否具备唯一标识、变更是否同步更新配置、发布版本是否可回溯到对应配置状态。配置管理贯穿所有工程过程，证据链不完整会牵连多个过程域的评定结果。

第一类常见弱项是配置项识别不完整。团队只把源代码、需求文档、测试报告当作配置项，忽略评审记录、变更单据、标定参数、编译脚本、工具配置、环境说明与供应商交付物。部分中间产物与过程记录游离在配置管理之外，评估时无法证明工作产品全生命周期受控。核查要点是对照项目过程清单逐项梳理交付物，覆盖文档、代码、数据、脚本、工具配置与外部交付物，形成正式配置项清单并纳入基线管理。

第二类常见弱项是配置基线管理不规范。项目缺少明确的基线划分规则，不知道哪些阶段需要建立基线；基线建立前没有经过评审与确认，基线内容包含未完成工作产品；基线变更没有正式审批，直接修改基线内文件。规范的配置管理应按项目阶段建立需求基线、设计基线、代码基线、测试基线与发布基线，每条基线有明确的配置项清单、评审记录与批准人；基线一旦冻结，修改必须走变更流程，禁止直接编辑基线内文件。

第三类常见弱项是版本标识规则不清晰。配置项版本号没有统一定义规则，不同类型文件各有各的版本编排；历史版本覆盖保存，无法回溯变更过程；不同分支、不同车型、不同硬件配置的版本没有区分标识，容易出现版本混用。团队应制定版本标识规范，明确主版本、次版本、修订号的定义与升级规则；保留全部历史版本与变更说明，保证版本演进路径可追溯；不同车型、硬件、客户分支的版本增加标识前缀，避免混淆。

第四类常见弱项是变更后配置不同步。需求、设计或代码变更后，只修改了变更对象本身，没有同步更新关联配置项与基线状态；变更记录与配置版本对应不上，评估时无法从变更单追溯到更新后的配置项。核查重点是变更流程与配置管理联动，变更批准并实施后同步更新对应配置项版本，变更单号与配置版本关联记录，每条基线的变更历史可查。

第五类常见弱项是发布配置不可追溯。交付给客户或产线的软件版本，无法反向对应到内部哪条配置基线、包含哪些配置项、对应哪些变更与缺陷修复；发布包与内部配置状态脱节。规范做法是每个发布版本关联一条内部配置基线，发布记录注明基线编号、配置清单与版本信息，从发布版本可以完整回溯到需求、设计、代码、测试与变更全链路配置状态。

配置管理是所有研发过程的基础支撑，过程能力成熟度直接反映项目整体受控水平。对照上述弱项逐项核查配置管理工作产品，补齐配置项清单、基线规则、版本规范与变更联动机制，就能显著减少配置管理类失分，同时为需求、设计、测试等过程域提供稳定的配置基础。