配置管理：CMMI模型过程域系列学习中文版

CONFIGURATION MANAGEMENT 配置管理

A Support Process Area at Maturity Level 2 支持过程域的成熟度第二级

Purpose 目的

配置管理（简称CM）的目的在于，根据配置识别、配置控制、配置状态记录以及配置审计，建立并维护工作产品的完整性。

Introductory Notes 简介

配置管理过程域，包含以下活动：
* 识别所选定的工作产品的配置，这些工作产品会组成特定的时间点基线
* 控制配置项的变更
* 建立或提供规格，以便从配置管理系统构造工作产品
* 维护基线的完整性
* 提供正确的状态和最新的配置数据给开发人员、最终用户及客户
纳入配置管理的工作产品，包含交付客户的产品、指定的内部工作产品、购买的产品、工具，以及其他用于产生或描述这些工作产品的条目。
供应商和项目可能都需要将购买的产品纳入配置管理。供应商协议中应建立执行配置管理的规定。建立和维护用于确保数据完整性和一致性的方法。
工作产品的配置管理，可以在许多不同层次的颗粒度上实施。配置项可分解为配置组件和配置单元。本过程域仅使用“配置项”这个术语。因此，在这些实践中，在适当的时候，配置项可解释为“配置组件”或“配置单元”。
基线为配置项的持续演变提供了一个稳定的基础。
当基线开发完成，就会被纳入配置管理系统。基线的变更，以及从配置管理系统所构造之工作产品的发行，应通过配置管理的配置控制、变更管理、配置审计等功能，进行系统的控制与监督。
本过程域不仅适用于项目的配置管理，也适用于组织工作产品的配置管理，如标准、程序、再用程序库等。
配置管理注重于对工作产品（包括已交付的系统），在管理层面和技术层面的严格控制。
本过程域涵盖了执行配置管理功能的实践，也适用于已纳入配置管理的所有工作产品。

---

特定目标和特定实践

SG 1Establish Baselines 建立基线
对识别的工作产品建立基线。

本特定目标涵盖用于建立基线的特定实践。“跟踪并控制变更”这一特定目标所涵盖的特定实践是用于维护基线，而“建立完整性”这一特定目标下的特定实践则用于记录和审计基线的完整性。

SP 1.1Identify Configuration Items 识别配置项
识别将纳入配置管理的配置项、组件，以及相关工作产品。
配置识别是对下列项目的选择、建立与说明：
* 交付客户的产品
* 指定的内部工作产品
* 购买的产品
* 工具及其他项目工作环境的重要资产
* 其他用于建立或说明这些工作产品的条目
纳入配置管理的项目，包含用于定义产品需求的说明和接口文件，也包含其他文件，例如测试结果。其他文件是否纳入配置管理取决于它对定义产品的关键程度。
“配置项”是指定被纳入配置管理的实体，它可能包含组成某基线的多个相关产品。这种逻辑上的分组，提供较容易的识别和存取控制。选择要纳入配置管理的工作产品，应根据制定计划时所建立的标准进行。

典型的工作产品
1.识别的配置项

子实践
1.根据书面的标准，选择配置项以及组成这些配置项的工作产品。

在适当的工作产品级别，选择配置项的标准，举例如下：
* 两个或两个以上的小组用到的工作产品
* 预计可能发生变化的工作产品，随着时间的变化，可能由于需求错误或需求变更导致工作产品的变更
* 相互依赖的工作产品，一个授权进行变更，会导致另一个也出现相应的变更
* 对项目而言至关重要的工作产品

作为配置项一个组成部分的工作产品，举例如下：
* 过程描述
* 需求
* 设计
* 测试计划和步骤
* 测试结果
* 接口说明
* 绘图
* 源代码
* 工具（如编译工具）

2.赋予每个配置项唯一的标识符。
3.指定每个配置项的重要特征。

配置项的特征，例如包括作者、文档或文件的类型、软件代码文件的编程语言等

4.指定每个配置项纳入配置管理的时间点。

确定何时将工作产品纳入配置管理的标准，举例如下：
* 项目生命周期的阶段
* 工作产品的测试已准备就绪时
* 工作产品的受控级别
* 成本和进度的限制
* 客户的需求

5.确定每个配置项的负责人。

SP 1.2Establish a Configuration Management System 建立配置管理系统
建立和维护配置管理与变更管理系统，以便控制工作产品。
配置管理系统，包含存取配置系统的储存媒体、运行程序、工具。
变更管理系统，包含用于记录和存取变更请求的储存媒体、运行程序、工具。

典型的工作产品
1.含有受控工作产品的配置管理系统
2.配置管理系统的访问控制程序
3.变更请求数据库

子实践
1.建立一种机制，使配置管理的多个受控等级都得到管理。

通常依据项目的目标、风险和（或）资源，选择受控的级别。项目的生命周期不同，开发的系统类型不同，以及特定的项目需求不同，都会导致受控的级别不同。
受控的级别，举例如下：
* 创建——由作者控制
* 工程类——出现变更时，要通知相关干系人
* 开发——较低层次由CCB控制
* 正式——较高层次由CCB和客户一起控制
控制级别分为非正式的控制和正式的控制。非正式控制是指配置项在开发过程中，对变更简单地跟踪；正式控制是指运用基线进行的正式的配置控制，只有在正式的配置管理过程中，基线才有可能允许出现变更。

2.在配置管理系统中，存取配置项。

配置管理系统，举例如下：
* 动态系统（或编者系统），包含当前创建或修订的一些组件。它在编者的工作区，由编者本人控制。动态系统中的配置项需要进行版本控制。
* 控制系统包含当前的基线以及基线的变更。正如本过程域所描述的情况，该系统中的配置项都纳入了完整的配置管理中。
* 静态系统包含各种基线的达成情况。正如本过程域所描述的情况，该系统中的配置项都纳入了完整的配置管理中。

3.在配置管理系统不同的控制等级内，都可以共享和迁移配置项。
4.储存与恢复已归档的配置项版本。
5.储存、更新及提取配置管理的记录。
6.在配置管理系统中，创建配置管理报告。
7.保存配置管理系统的内容。

配置管理系统的保存功能，举例如下：
* 对配置管理文件进行备份和恢复
* 对配置管理文件的归档
* 从配置管理错误中进行恢复

8.必要时修订配置管理的结构。

SP 1.3Create or Release Baselines 创建或发布基线
创建或发布供内部使用和交付客户的基线。
基线是一组经过正式评审和同意的说明或工作产品，也是未来开发或交付的基础，而且只能通过变更控制程序才能更改。基线表示给予一个或多个配置项以及相关实体一个识别码。伴随产品的发展演变，可能由几个基线来控制产品的开发与测试。

典型的工作产品
1.基线
2.基线说明

子实践
1.在创建或发布配置项的基线之前，要获得配置变更委员会（CCB）
的授权。
2.只有针对来自配置管理系统的配置项，可以创建或发布基线。
3.将纳入基线的配置项形成书面的文档。
4.保证当前的基线可用。

SG 2Track and Control Changes 跟踪并控制变更
跟踪并控制已纳入配置管理的工作产品的变更。

本特定目标下的特定实践是用来维护基线，这些基线是由“建立基线”这一特定目标涵盖的特定实践所建立。

SP 2.1Track Change Requests 跟踪变更请求
跟踪配置项的变更请求。
变更请求不仅用于新的需求或需求变更，也用于工作产品的故障或缺陷。
通过分析变更请求，来判断该变更对工作产品、相关工作产品、成本及时间的影响。

典型的工作产品
1.变更请求

子实践
1.发起变更请求，并记录到变更请求的数据库。
2.分析变更请求中，变更和处理建议会产生的影响。

评估变更对各项活动的影响，确保与所有的技术需求和项目需求保持一致。
评估变更的影响，不仅仅包括变更对项目或合同需求的直接影响。如果几个项目都用到同一项条款，对该条款进行修改可以快速解决某个问题，但其他场合用到该条款时，又会引起很多麻烦。

3.针对下次基线会处理的变更请求，应与相关干系人一起进行评审，并取得对方的认可。
与应该适当参加的人员一起，对变更请求进行评审。对每个变更请求是如何部署的，以及部署的理由都进行记录，包括判断成功的标准，适当时制定一份简要的计划方案，变更所满足的需求以及未满足的需求。实施部署时要求的计划方案，并向相关干系人报告结果。
4.跟踪变更请求的状态直到关闭。
录入系统的变更请求，都需要及时并有效地进行处理。一旦变更请求得到了处理，达成的解决方案开始生效，就应及时地关闭变更请求和解决方案。如果解决方案一直处于开放的状态，会导致状态清单的数量增多，也势必导致增加了成本，带来更多的混乱。

SP 2.2Control Configuration Items 控制配置项
控制配置项的变更
控制是对工作产品基线配置的维护，控制包含跟踪每一配置项的配置，必要时批准新的配置，并更新基线。

典型的工作产品
1.配置项的变更历史
2.归档的基线

子实践
1.在整个产品生命周期中，控制配置项的变更。
2.变更后的配置项，在纳入配置管理系统之前，必须获得适当的授权。
例如，授权的途径可以来自CCB、项目经理或客户等。
3.为纳入最新的变更，从配置管理系统中检入或检出配置项时，必须维护这些配置项的正确性和完整性。

检入或检出的操作步骤，举例如下：
* 确认变更得到了授权
* 更新配置项
* 对替换掉的基线进行归档，并取得最新的基线

4.实施评审，确保变更没有对基线造成意外的影响（例如，确保变更没有危及系统的安全和/或机密）。
5.适当记录配置项的变更及变更理由。
如果对某工作产品所提出的变更得到了认可，就要将变更列入日程，即对工作产品及其他受影响的领域，都做出相应的变更。

SG 3Establish Integrity 建立完整性
建立并维护基线的完整性。
“建立基线”特定目标的过程用于建立基线，“跟踪并控制变更”特定目标的过程用于维护基线，而本特定目标所涵盖的特定实践则用以确保基线的完整性。

SP 3.1Establish Configuration Management Records 建立配置管理记录
描述配置项，并对这些描述记录进行维护。

典型的工作产品
1.配置项的变更历史
2.变更日志
3.变更请求的备份
4.配置项的状态
5.不同基线之间的差异

子实践
1.详细地记录配置管理方案，使他人可以充分地了解每个配置项的内容和状态，并能恢复配置项之前的版本。
2.确保相关干系人能够访问和了解配置项的配置状态。

有关配置项状态的沟通活动，举例如下：
* 为授权访问的最终用户，提供访问权限
* 对基线进行备份，供授权的最终用户随时使用
3.标识基线的最新版本。
4.确定组成某特定基线的配置项的版本。
5.描述前后基线的差异。
6.必要时修订配置项的状态和历史变更（即变更和其他行为）。

SP 3.2Perform Configuration Audits 实施配置审计
实施配置审计以维护配置基线的完整性。
配置审计确认最终的基线，以及文件是否符合特定的标准或需求，并适当记录审计结果。

典型的工作产品
1.配置审计的结果
2.具体事项

子实践
1.评估基线是否完整。
2.确认配置管理的记录能够正确地识别出配置项。
3.对配置管理系统中配置项的结构和完整性进行评审。
4.对配置管理系统中配置项的完整性和正确性进行确认。
内容是否完整和正确，取决于是否符合计划中描述的需求，以及与达成的变更请求的部署是否一致。
5.确认是否符合适当的配置管理标准和程序。
6.跟踪审计的具体事项直到关闭。

---

CMMI, CMM, and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.
CMM Integration, SCAMPI, and IDEAL are service marks of Carnegie Mellon University.
本文属于个人学习所用，请使用者用毕及时清理。

---

项目管理：需求管理、项目策划、项目监控和控制、供应商协议管理、集成项目管理、风险管理、定量项目管理

过程管理：组织过程焦点、组织过程定义、组织级培训、组织过程性能、组织革新和实施

支持：配置管理、过程和产品质量保证、度量和分析、决策分析与决定、原因分析和决定

工程：需求开发、产品集成、技术解决方案、验证、确认

---

止于至善的博客 http://tyou1215.csai.cn/