成熟度2级的一个支持过程域
目的配置管理（CM）的目的是建立并且保持工作产品使用配置识别、配置控制、配置状态清算、配置审核的完整性。
介绍配置管理过程域包括：
l 识别被选择的工作产品的配置从而及时地在特定的点组成基线
l 收集配置项的变化
l 从配置管理系统中建立或者提供规范去创建工作产品
l 保持基线的完整性
l 为开发人员、最终用户以及客户提供正确的状态和当前配置数据
在配置管理中存放的工作产品包括释放给客户的产品、内部的工作产品、已经获得的产品、工具、和被用来创建和描述这些工作产品的其他项。（参见“配置管理”在术语表中的定义）
对于供应商来源
供应商和项目都可能需要将已经获得的产品被放置在配置管理下。配置管理的操作规定的建立应该获得供应商的同意。应该建立和保持确保数据的完整性和一致性的方法。
可能被放置在配置管理下的工作产品示例如下：
l 计划
l 过程描述
l 需求
l 设计数据
l 图表
l 产品规格、说明书
l 代码
l 编译器
l 产品数据文件
l 产品技术性出版物
工作产品的配置管理可能会在多个级别中执行。配置项能够被分解成配置组件和配置单元。在这个过程域中只用到“配置项”这个术语。然而，在这些实践中“配置项”可能被解释成“配置组件”也有可能被解释成“配置单元”。（参见“配置项”在术语表中的定义）
基线为配置项的进一步发展提供了一个稳定的基础。
一个基线的例子是一个被认可的产品描述包括需求的内部版本、需求跟踪矩阵、设计、特殊学科项目以及最终用户文档。
当基线被制定后就被增加到配置管理系统中。来源于配置管理系统的对基线的更改和工作产品的发布都是通过配置管理的配置控制、变更管理和配置审核功能来进行系统性的控制和监督。
这个过程域的不但应用在项目的配置管理，也应用在组织工作产品的配置管理，例如，标准、过程和可重用库。
配置管理焦点在于管理的严格控制和工作产品的技术方面，包括已经交付的系统。
这个过程域包含用于执行配置管理功能的实践并可适用于所有在配置管理下的工作产品。
实践－目标关系表
连续式
分级式
SG1 建立基线
SG1 建立基线
SP1.1-1识别配置项
SP1.1-1识别配置项
SP1.2-1建立配置管理系统
SP1.2-1建立配置管理系统
SP1.3-1生成或分发基线
SP1.3-1生成或分发基线
SG2 跟踪和控制更改
SG2 跟踪和控制更改
SP2.1-1跟踪更改要求
SP2.1-1跟踪更改要求
SP2.2-1控制配置项
SP2.2-1控制配置项
SG3 建立完整性
SG3 建立完整性
SP3.1-1建立配置管理记录
SP3.1-1建立配置管理记录
SP3.2-1执行配置审核
SP3.2-1执行配置审核
GG1 达到特定目标
GP1.1 完成基础实践
GG2 制度化一个已管理的过程
GG2 制度化一个已管理的过程
GP2.1建立组织的方针
GP2.1建立组织的方针
GP2.2 计划过程
GP2.2 计划过程
GP2.3 提供资源
GP2.3 提供资源
GP2.4 分配职责
GP2.4 分配职责
GP2.5 培训人员
GP2.5 培训人员
GP2.6 管理配置
GP2.6 管理配置
GP2.7 识别和包括相关的风险承担者
GP2.7 识别和包括相关的风险承担者
GP2.8 监督和控制这个过程
GP2.8 监督和控制这个过程
GP2.9 客观的评价坚持状况
GP2.9 客观的评价坚持状况
GP2.10 以更高等级的管理回顾状态
GP2.10 以更高等级的管理回顾状态
GG3 制度化已定义的过程
GP3.1 建立一个已定义的过程
GP3.1 建立一个已定义的过程
C/ML3-5
GP3.2 收集改进信息
GP3.2 收集改进信息
GG4 制度化一个已量化管理的过程
GP4.1 建立过程的量化目标
GP4.2 稳定子过程的执行
GG5 制度化一个优化中的过程
GP5.1 保证连续的过程改进
GP5.2 改正问题的根源
相关过程域
有关制定计划和工作分解结构，从而对确定配置项有帮助的更多信息请参见项目计划过程域。
有关用于分析变更需求的影响的方法以及评估变更的方法的更多信息请参见原因分析和决策过程域。
有关执行分析和纠正活动的更多信息请参见项目监督与控制过程域。
实现目标的关键实践SG1 建立基线
指定工作产品的基线已建立。
建立基线的关键实践包括这个关键目标。关键实践在追踪并控制更改这个关键目标下用于保持基线。建立完整性的关键实践的特殊目标是记载并且审核基线的完整性。
SP1.1-1识别配置项
识别配置管理中需要采用的配置项目、组件、及相关工作产品。
配置识别就是选择、创建和详述如下内容：
l 发布给客户的产品
l 已设计的内部工作产品
l 已获得的产品
l 工具
l 用于创建和描述这些工作产品的其他项目
配置管理下的项目会包括定义产品需求的详述和交互文档。其他例如测试结果这样的文档也会被包括在内，是否包含关键看它们对定义产品的关键程度。
一个“配置项”是一个配置管理的实体，它可能由来自于一个基线的多个相关的工作产品组成。这个逻辑分组为识别和控制提供了方便。
进行配置管理的工作产品的选择应该基于在计划期间建立的标准。
对于系统工程
在一个包含硬件和软件的系统中，其中软件仅占系统的一小部分，所有的软件都可能被设计成一个独立的配置项。另一方面，软件也可能被组合到多种配置项中。
配置项能够被组合到配置组件和配置单元中。在这个过程域中只有“配置项”这个术语。在这些实践中，“配置项”既可能被理解成“配置组件”，也可能被理解成“配置单元”。例如，需求管理域的配置项能够从每一个个体需求变化到一组需求。
典型工作产品
1. 已识别的配置项
子实践
1. 选择配置项和工作产品，基于文档化的标准将它们组合。
用于在适当的工作产品级别选择配置项的标准示例如下：
l 被两个或以上群组使用的工作产品
l 随着时间的推移因为错误或者需求的变更而被期望更改的工作产品
l 一个变更导致其他产品变更的相互依赖的工作产品
l 对于项目来说是危急的工作产品
可能成为配置项一部分的工作产品示例如下：
l 过程描述
l 需求
l 设计
l 测试计划和程序
l 测试结果
l 界面描述
对于软件工程
软件工作产品可能成为配置项一部分的示例如下：
l 编码/模型
l 工具（例如编译器）
2. 给配置项分配唯一标识。
3. 将每一个配置项的重要特征列入清单。
配置项的特征例子包括作者、文档或者文件类型以及软件编码的程序语言。
4. 当每一个配置项都被纳入配置管理时列出清单。
判断何时将工作产品纳入配置管理的标准示例如下：
l 项目生命周期的阶段
l 当工作产品准备测试
l 工作产品的控制等级
l 有限的成本和时间
l 客户的需求
5. 识别每个配置项所有者的责任。
SP1.2-1建立配置管理系统
建立并保持用于控制工作产品的配置管理和配置更改管理系统。
一个配置管理系统包括存储媒体、程序以及访问配置系统的工具。
一个配置更改管理系统包括存储媒体，程序以及记录和访问变更要求的工具。
典型工作产品
1. 包含被控制的工作产品的配置管理系统
2. 配置管理系统访问控制程序
3. 变更要求数据库
子实践
1. 建立一个机制区管理配置管理的多种控制级别。
致使控制的多种级别情形发生的示例如下：
l 在项目生命周期的不同时期需要不同的控制级别（例如，产品成熟时更严格的控制）
l 不同类型的系统需要不同的控制级别（例如，纯软件系统与包括软硬件的系统）
l 配置项对保密和安全的需求需要不同的控制级别
2. 存储和刷新配置管理系统中的配置项
配置管理系统示例如下：
l 动态（或开发）系统包括经常被创建和修改的组件。它们都在开发人员的工作区并被开发人员所控制。动态系统中的配置项都处于版本控制中。
l 控制（或受控）系统包括当前的基线和对基线的修改。在控制系统中的配置项接受全配置管理，如同这个过程域描述的一样。
l 静态系统包括各种发布使用的基线，静态系统接受全配置管理，如同这个过程域描述的一样。
3. 在配置管理系统中的不同控制级别之间共享和传输配置项。
4. 存储和恢复配置项已经存档的版本。
5. 存储、更新以及刷新配置管理记录。
6. 从配置管理系统中生成配置管理报告。
7. 保存配置管理系统的内容。
配置管理系统的保存功能示例如下：
l 备份和恢复配置管理文件
l 归档配置管理文件
l 从配置管理错误中恢复
8. 当必要的时候修改配置管理结构。
SP1.3-1生成或分发基线
生成或分发对内部使用及分发至顾客的基线。
基线是一套被正式回顾和认可的规格说明书或工作产品，基线在今后为更进一步的开发作为基础而服务。并且基线只能够通过控制过程来变更。基线为每一个配置项和它的相关实体分配一个标识。
对于系统工程
基线的分发包括批准一套来自配置管理系统的经过同意的配置项的配置数据和为今后的开发分发基线。在产品的开发周期中，可能是多种基线定义一个发展中的产品。通常包括系统级的需求，系统单元级的设计需求，以及产品开发前期/后期的产品定义，这些被称为“功能基线”、“本地基线”和“产品基线”。
对于软件工程
一套分配了唯一标识的需求、设计、源程序文件和相关的可执行代码，编译文件和用户文档（相关的实体）就可以被认为是一个基线。基线的分发由从配置管理系统取出源程序文件（配置项）并生成可执行文件。交付客户的基线是一种典型的基线，被称为“发布”。而内部使用的基线成为“构造”。
典型工作产品
1. 基线
2. 基线的描述
子实践
1. 在创建和发布配置项的基线之前获得CCB的授权。
2. 仅从配置管理系统的配置项中创建和发布基线。
对于系统工程
确保配置项被建立成正确的样子。
3. 证明被包含在基线中的配置项。
4. 使当前的基线可用。
SG2 跟踪和控制更改
配置管理中工作产品的更改已被追踪和控制。
当基线被建立基线的特殊目标下的关键实践建立后，这个特殊目标下的关键实践为保持基线而服务。
SP2.1-1跟踪变更要求
追踪对配置项目更改的要求。
变更要求不但位于新的或者改变的需求中，也会在工作产品的故障和缺陷中。
分析变更要求以确定变更对工作产品、相关工作产品以及计划和成本带来的影响，
典型工作产品
1. 变更要求
子实践
1. 在变更需求数据库中开始和记录变更要求。
2. 分析改变和变更要求中提到的修改带来的影响。
通过活动评估改变以确保这些改变在所有的技术和项目需求上是一致的。
评估改变对直接产品和合同需求带来的影响，在多种产品中，对其中一个项目的变更可能会导致在其他应用上的问题。
3. 与那些会被变更影响的人一起回顾将会位于下一个基线中的变更要求并对其达成一致。
指导合适的参与者一起回顾变更要求。记录每一个变化要求的部署以及决议的基本原理，包括成功标准，如果合适的话还有一个活动计划大纲，以及改变满足或不满足的条件。必须在这个部署下执行活动，并且向相关风险承担者汇报结果。
4. 跟踪变更要求的状态，直到关闭。
进入系统的变更要求需要以一种有效而及时地方式进行控制。一旦一个变更要求被执行，用适当和经过核准的活动来关闭要求的实践是紧迫的。活动留下了比必需的状态清单更多的结果，这些结果反过来导致成本和混乱的增加。
SP2.2-1 控制配置项
控制配置项的更改。
控制在工作产品基线的配置中是持续的。这个控制包括跟踪每一个配置项的配置，需要时批准一个新的配置，以及更新基线。
典型工作产品
1. 配置项的修订历史
2. 基线的归档
子实践
1. 在产品的生命周期中控制配置项的变更。
2. 在配置项被纳入配置管理系统之前获得适当的授权。
例如，授权可能来自于CCB、项目管理或者客户。
3. 当结合变更时，以一种保持配置项的正确性和完整性的习惯从配置管理系统中检入和检出配置项。
检入和检出的步骤示例如下：
l 确认修订被授权
l 更新配置项
l 归档被取代的基线并且刷新新的基线
4. 执行回顾以确保对变更没有引起基线的意外影响（例如确保变更没有危机到系统的安全和/或者保密）。
5. 记录配置项的变更以及变更适当的原因。
如果对于工作产品的一个被提议的变更被采纳，一个进度表被确定以使变更结合到工作产品以及其他受影响的领域中。
配置控制机制可以根据变更的类别被裁减，例如对其他组件不产生影响的组件变更可以不需要非常严格的正式批准。
变更的配置项在配置变更的批准和回顾之后被发布，变更直到发布时才成为正式的。
SG3 建立完整性
已建立并保持基线的完整性。
基线的完整性，被与建立基线特殊目标相关的过程所建立，并由跟踪和控制变更特殊目标相关的过程维持，被这个特殊目标下的关键实践所提供。
SP3.1-1建立配置管理记录
建立并保持描述配置项目的记录。
典型工作产品
1. 配置项的修订历史
2. 变更日志
3. 变更要求的备份
4. 配置项结构
5. 基线间的区别
子实践
1. 足够详细的记录配置管理活动，能够知道每个配置项的内容和状态并且能够恢复以前的版本。
2. 确保相关的风险承担者能够访问并且了解配置项的配置状态。
配置状态沟通活动示例如下：
l 给被授权的最终用户提供访问权限
l 主动提供基线备份给被授权的最终用户
3. 将基线的最新版本列入清单。
4. 识别配置项的版本，从而组成一个指定的基线。
5. 描述连续基线间的区别。
6. 必要时修订每一个配置项的状态和历史（也就是变更和其他活动）。
SP3.2-1执行配置审核
执行配置审核以保持配置基线的完整性。
审核配置管理活动并试图确认基线的结果和文件是正确的，并适当的记录审核结果。
典型工作产品
1. 配置审核结果
2. 活动项
子实践
1. 评估基线的完整性。
2. 确认配置记录正确识别了配置项的配置。
3. 回顾配置管理系统中的配置项的结构和完整性。
4. 确认配置管理系统中的配置项的完整和正确。
内容的完整和正确是基于计划中规定的需求以及被认可的变更要求的部署。
5. 确认配置管理标准和程序的可用性。
6. 跟踪活动项从审核到关闭。
目标的一般实践GG1 完成特定目标
通过将可识别的输入工作产品转变为可识别的输出工作产品，过程支持并且能够使过程域的特定目标实现。
GP1.1 履行基本实践
履行原因分析和决策过程的基本实践从而发展工作产品和提供达到过程域的特殊目标的服务。
仅仅适用于连续式
GG2 制度化一个已管理的过程
过程被作为一个已管理的过程制度化。
执行的保障GP2.1 建立组织的方针
建立和维持一个用于计划和执行配置管理过程的组织性方针。
详尽的细节
这个方针建立了对建立和维持基线，跟踪和控制对工作产品的变更（在配置管理之下）以及建立和维持基线完整性的组织性的期望。
执行的能力
GP2.2计划过程
建立和维持一个用于执行配置管理过程的计划。
详尽的细节
具有代表性的，执行配置管理过程的计划是在项目计划过程域中描述的项目计划中的一部分。
GP2.3 提供资源
提供足够的资源用于执行配置管理过程，开发工作产品，以及提供过程的服务。
详尽的细节
提供的资源包括如下工具所示：
l 配置管理工具
l 数据管理工具
l 归档和再现工具
l 数据库程序
GP2.4 分配职责
分配执行过程，开发工作产品以及提供配置管理过程服务的职责。
GP2.5 培训人员
必须培训执行和支持配置管理过程的人员。
详尽的细节
培训主题示例如下：
l 配置管理人员的任务、职责和权利
l 配置管理标准、过程和方法
l 配置库系统
引导（过程的）执行GP2.6 管理配置
在适宜的配置管理水平下放置配置管理过程中指定的工作产品。
详尽的细节
在配置管理下存放的工作产品示例如下：
l 访问列表
l 状态变更报告
l 变更要求数据库
l CCB会议记录
l 归档的基线
GP2.7 识别和包含相关的风险承担者
对照计划，识别和包含配置管理过程的相关风险承担者。
详尽的细节
风险承担者的活动示例如下：
l 建立基线
l 回顾配置管理系统报告并分解问题
l 评估变更对配置项带来的影响
l 执行配置审核
l 回顾配置管理审核的结果
GP2.8 监督与控制过程
根据计划监督与控制配置管理过程，从而执行过程并进行适当的纠正活动。
详尽的细节
用于监督与控制的度量方法示例如下：
l 配置项变更的数量
l 配置审核行为的数量
验证（过程的）执行GP2.9 客观的评价坚持状况
对照过程的描述、规则、程序，客观评估配置管理过程的坚持状况，并处理未按此执行的相关事宜。
详尽的细节
回顾活动示例如下：
l 建立基线
l 跟踪和控制变更
l 建立和维持基线的完整性
工作产物回顾示例如下：
l 基线的归档
l 变更要求数据库
GP2.10 用更高等级的管理回顾状态
用更高层次的管理回顾配置管理过程中的活动、状态、和结果，并解决问题。
编者按：GG3和它的实践不应用于成熟度2级阶段，而是应用于3级及以上阶段。
仅仅适用于分级式
GG3 制度化一个已定义的过程
过程被作为一个已定义的过程制度化。
执行的能力
GP3.1 建立一个已定义的过程
建立和维持一个已定义的配置管理过程的描述。
引导（过程的）执行
GP3.2收集改进信息
收集工作产品、度量方法、度量结果以及源于计划和执行配置管理过程的改进信息，从而支持将来的使用以及组织过程和过程域的改进。
连续式/成熟度3-5级
GG4 制度化一个集成的已管理的过程
过程是作为一个集成的已管理的过程被制度化的。
GP4.1 为过程建立集成目标
为配置管理过程建立和维持集成目标从而明确质量和过程执行是基于客户需求和商业目标的。
GP4.2 稳定子过程执行
稳定一个或多个子过程的执行从而确定配置管理过程的能力以达到建立的集成质量和过程执行目标。
GG5 制度化一个已优化的过程
过程是作为一个已优化的过程被制度化的。
GP5.1 确保连续的过程改进
在完成组织的相关商业目标过程中确保连续的配置管理过程改进。
GP4.2 纠正问题的根源原因
在配置管理过程中识别和纠正缺陷和其他问题的根源原因。
仅仅适用于连续式
本文地址：http://com.8s8s.com/it/it32437.htm