|
成熟度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. 在配置项被纳入配置管理系统之前获得适当的授权。
3. 当结合变更时，以一种保持配置项的正确性和完整性的习惯从配置管理系统中检入和检出配置项。
| 
本类阅读TOP10