配置管理过程 - 系统工程手册-系统生命周期的过程与活动指南-技术管理过程

1.1 目的

如ISO/IEC/IEEE 15288所述，

[6.3.5.1] 配置管理过程的目的是在整个生命周期中管理和控制系统元素和配置。CM还管理产品与其相关配置定义之间的一致性。

这通过确保系统在其生命周期中硬件和软件配置的有效管理来实现。这一目标的核心是建立、控制和维护软件和硬件基线。基线是用于维持开发和控制的业务、预算、功能、性能和物理参考点。这些基线或参考点是通过审查和接受需求、设计和产品规格文档而建立的。基线的创建可能与项目里程碑或决策门相吻合。随着系统的成熟并经过生命周期阶段，软件或硬件基线在配置控制下得到维护。

1.2 描述

演化概念定义 ²和系统定义是必须在整个系统开发过程中以及在系统的利用和支持阶段中解决的现实问题。配置管理确保产品功能、性能和物理特性得到正确识别、记录、验证和确认，以建立产品完整性；确保对这些产品特性的更改得到正确识别、审查、批准、记录和实施；并确保根据给定的一组文档是已知的。

1.3 输入/输出

配置管理过程的输入和输出在图5.8中列出。每个输入和输出的描述在附录E中提供。

1.4 过程活动

配置管理过程包括以下活动：

计划配置管理： - 制定配置管理策略。 - 实施一个配置控制周期，包括对工程变更请求 (ECRs) 的评估、批准、验证和确认。

执行配置识别： - 确定系统元素和信息项目，作为配置项（CIs）进行配置控制。 - 为CI建立唯一标识符。 - 在生命周期的适当阶段为配置项建立基线，包括由采购方和供应商 ³达成基线协议。

执行配置变更管理： - 在系统生命周期中控制基线变更。这包括识别、记录、审查、批准、跟踪和处理变更请求（RFCs）和差异请求（RFVs）（也称为偏差）。

执行配置状态核算： - 开发和维护配置控制文档和配置管理数据，并向项目团队传达受控项目的状态。

进行配置评估： - 进行与里程碑和决策点相关的配置审计和配置管理监督审查，以验证基线。

执行发布控制： - 执行优先级 ⁴排序、跟踪、调度和关闭变更，包括相关支持文档。

常用方法和技巧：

• 在项目规划过程 ⁵中（见第5.1节），配置管理计划（CMP）被定制以满足各个项目的配置管理程序。
• 配置管理过程的主要输出是维护系统和系统元素的配置基线，其中项目作为决策过程的一部分被置于正式控制之下。
• 建立一个配置控制委员会（CCB），由参与项目的各个相关利益方和工程学科的代表组成。
• 在系统初期阶段开始配置管理过程，并持续到系统处置。
• 配置管理文档在整个系统生命周期中得到维护。

关于配置管理活动的额外指导可以在ISO 10007(2003)、IEEE Std 828(2012)和ANSI/EIA 649B(2011)中找到。

领域特定的实践，如SAE航空航天推荐实践（ARP）4754A，《民用飞机和系统开发指南》（2010年），为该领域提供了额外的应用细节。

2.1 配置管理概念

配置管理的目的是建立和维护系统生命周期中产生的需求、文档和工件的控制，并管理变更对项目的影响。基线在指定的时间或特定情况下整合了系统元素不断演进的配置状态，形成文档化的基线。基线是下一次变更的基础。选定的基线通常会在采购方和供应商之间正式化，这取决于行业的实践和采购方在配置变更过程中的合同参与程度。系统层面一般有三种主要类型的基线：功能基线、分配基线和产品基线。这些可能因领域或本地策略而有所不同（ISO/IEC/IEEE15288：2015）。

正如图5.9所示，变化是不可避免的。系统工程师确保这种变化是必要的，并且提出了最具成本效益的建议。

配置管理的初步规划工作在项目开始时进行，并在CMP中定义，该计划确定了涵盖的项目范围；识别所需的资源和人员技能水平；定义要执行的任务；描述组织角色 ⁶和责任；并识别将用于项目的配置管理工具和流程，以及方法、标准和程序。配置控制通过促进批准的更改并防止未批准的更改被纳入受配置控制的项目来维护完整性。诸如源代码的签入和签出、系统元素的版本以及制造物品的偏差等活动是配置管理的一部分。独立的配置审计评估产品的演变，以确保符合规范、政策和合同协议。正式审计可能在支持决策门审查时进行。

更改系统当前配置的请求通常使用工程变更提案（ECP）提出。ECP可能以多种方式产生。客户可能会要求ECP来解决需求或范围的变化；技术上的意外突破可能导致系统元素供应商提出ECP；或者供应商可能发现需要对正在开发的系统进行更改。这些情况可能会改变范围或需求，是提出ECP并进行分析以了解更改对现有计划、成本和时间表的影响的适当理由。在实施更改之前，必须批准ECP。在没有范围变化的情况下，提出ECP来纠正成本或时间表差异是不合适的。在当前项目范围 ⁷内进行的小型更改通常不需要ECP，但应获得批准并生成工程通知（EN）。同样重要的是要问，“如果不进行更改会有什么影响？”特别是在系统成熟时，因为生命周期后期的更改具有隐藏影响的风险增加，这可能对系统成本、时间表和技术性能产生不利影响。

ECP周期最理想的结果是：

1. 系统功能被修改以满足不断变化的需求。
2. 新技术或新产品以客户期望的方式扩展了系统的功能，超出了最初的要求。
3. 开发、利用或支持的成本降低。
4. 系统的可靠性和可用性得到提高。

结果三和四降低了生命周期成本，并且可能比投资于拟议变更的资金节省更多的钱。

ECPs和ENs有助于确保系统以允许其继续满足其操作要求和目标的方式发展，并且任何修改都为所有相关人员所知。图2.2所示的飞机系统是一个产品家族的例子，它依赖于对系统元素和特征的准确识别来支持混合和匹配的消费者市场。

2.2 配置管理方法

配置管理建立并维护对需求、规格、配置定义文档和设计变更的控制。配置标识、配置控制、配置状态会计以及功能和物理配置（即验证和分发）的配置审计是配置管理的主要关注点。

总是需要进行更改；然而，系统工程师必须确保(i) 更改是必要的，并且(ii) 提出了最具成本效益的解决方案。因此，配置管理必须应用技术和行政指导、监督和服务来执行以下操作：

• 识别并记录各个配置项的功能和物理特征，以便它们以某种形式是唯一且可访问的。
• 为每个配置项的每个版本分配一个唯一的标识符。
• 建立控制措施，允许对这些特征进行更改。
• 同意产品发布，并通过创建基准产品确保产品的一致性。
• 记录、跟踪和报告变更处理和实施状态，并收集与产品基线的变更请求或问题相关的措施。
• 保持所有交易的全面可追溯性。

配置识别 是唯一标识基线配置中的元素。这种独特的识别方式促进了创建和维护基线主清单的能力。作为系统工程工作的一部分，系统被分解为配置项（CIs），这些配置项作为受到严格正式控制的关键元素。所有配置项的汇编被称为CI列表。这个列表可能反映开发的项目、供应商生产的项目或由客户提供的用于集成到最终系统的项目。这些项目可能是合同下的可交付项目，或者用于生产可交付项目的项目。

变更管理 配置变更管理，或变更控制，管理要基线化的项目集合，并通过促进批准的变更（例如，通过ECR）和防止未批准的变更纳入基线来维护已识别的配置项的完整性。变更控制应在项目启动时开始生效。

更改分类 有效的配置控制要求分析和批准行动的范围对于拟议的工程变更，应与变更的性质相一致。问题陈述包括对拟议变更的描述、拟议变更的原因、变更对成本和进度的影响以及所有受影响的文档。变更分类是配置控制的主要依据。所有对基线项目的变更都分为超出需求范围或在需求范围内。超出项目需求范围的变更是指对项目基线项目的形式、适合性、规格、功能、可靠性或安全性 ⁸的变更。协调审查委员会将确定此拟议变更是否需要变更通知进行审查和批准。

变化有时被分为两大类：一类和二类。一类变化是影响成本、进度或技术性能的重大或显著变化。通常，一类变化在实施前需要得到客户的批准。二类变化是较小的变化，通常影响文档错误或内部设计细节。一般情况下，二类变化不需要客户批准。

CCB 在项目启动时实施一个总体的 CCB，以提供一个中心点来协调、审查、评估和批准所有对基线文档和配置（包括硬件、软件和固件）的拟议更改。审查委员会由来自各个学科的成员组成，包括系统工程、软件和硬件工程、项目管理、产品保证和配置管理。主席被授予必要的权力，代表项目经理处理所有属于审查委员会职责范围内的事项。配置管理组织被委托负责维护所有拟议更改的状态。可以为审查低于 CI 级别的软件或硬件拟议更改而设立卫星或下属委员会。如果这些更改需要更高层次的审批审查，它们将被转发到总体审查委员会进行裁决。

属于审查委员会管辖范围内的变更应评估其技术必要性、是否符合项目要求、与相关文件的兼容性以及对项目的影响。由于变更是在硬件和/或软件产品处于不同制造或验证阶段时编写的，审查委员会应要求提供特定的识别说明拟议的软件或硬件变更的有效性或影响，以及在处理中或已完成的硬件和/或软件产品的处置。审查委员会应评估的影响类型通常包括以下内容：

• 所有零件、材料和工艺均经过专门批准，可在项目中使用。
• 所描述的设计可以使用所指示的方法进行制造。
• 项目质量和可靠性保证要求得到满足。
• 设计与接口设计一致。

方法和技术 变更控制表格提供了一种标准的方法来报告问题和改进，这些会导致正式基线和内部控制项目的变更。以下表格提供了一种有组织的方法来更改硬件、软件或文档：

• 问题/变更报告 —— 可用于记录问题并推荐对硬件/软件或其补充文档的改进。这些表格可用于在设计、开发、集成、验证和确认过程 ⁹中识别问题。
• 规格变更通知（SCN） —— 用于提出、传输和记录对基线规格的更改。
• ECPs —— 用于向客户提出一类变更建议。这些提案描述了拟议变更的优势和可用的替代方案，并确定了继续进行所需的资金。
• ECRs —— 用于提出II类变更。
• 偏离/豁免请求 —— 用于在永久性更改以符合既定基线不可接受时，请求并记录对配置识别要求的临时偏离。

配置状态核算 提供了关于受控产品状态的数据，这些数据对于在整个产品生命周期中对系统元素做出决策是必要的。配置管理维护着已批准文档的状态，这些文档识别并定义功能和物理特性、拟议变更的状态以及已批准变更的状态。这个子过程综合了识别和控制子过程的输出。所有由配置审查委员会（包括总体和下属）授权的变更最终都会形成对所有事务的全面追溯。诸如源代码的签入和签出、构建配置项、制造项目的偏差以及豁免状态等活动都是状态跟踪的一部分。通过状态化和跟踪项目变更，可以捕捉从构建到实际构建配置的逐步变化。建议考虑的措施包括以下内容：

• 处理、采纳、拒绝和未决的变更数量
• 未决变更请求的状态
• 变更请求分类汇总
• CI的偏差或豁免数量
• 问题报告的数量，包括未解决、已解决和处理中的
• 问题报告和根本原因 ¹⁰的复杂性
• 问题被识别时，与问题解决和验证阶段相关的劳动力
• 偏差、豁免、ECP、SCN、ECR和问题报告的处理时间和工作量
• 导致大量变更请求和基线变更率的活动

配置评估，或审计，由配置管理和产品保证独立进行，以评估产品的演变并确保符合规范、政策和合同协议。正式审计，或功能和物理配置审计，在产品开发周期结束时进行。

功能配置审计旨在验证CI的开发是否已完成，并且达到了系统规格（功能基线）中指定的性能和功能特性。物理配置审计是对CI的技术审查，以验证实际构建的地图与技术文档（物理基线）的一致性。最后，配置管理执行定期的在过程审计，以确保遵循配置管理流程。