-
首页
-
CMMI
- 诊断服务
- 咨询服务
- 认证评估服务
- 培训服务
-
PCMM
- 模型介绍
- 培训课程
- 技术型人员与组织发展解决方案
- 专题人资解决方案
-
关于凡奉
- 凡奉介绍
- 资讯分享
- 加入我们
- 联系我们
-
首页
-
CMMI
-
诊断服务
-
咨询服务
-
认证评估服务
-
培训服务
-
诊断服务
-
PCMM
-
模型介绍
-
培训课程
-
技术型人员与组织发展解决方案
-
专题人资解决方案
-
模型介绍
-
关于凡奉
-
凡奉介绍
-
资讯分享
-
加入我们
-
联系我们
-
凡奉介绍
-
ꁸ 回到顶部
-
ꂅ 021-58991761
-
ꀥ 微信二维码
CMMI过程域详解-配置管理(CM)之概述
配置管理(CM)过程域是CMMI-DEV成熟度2 级支持类过程域
一、CM过程域的目的
配置管理(Configuration Management,CM)的目的在于使用配置识别、配置控制、配置状态记录与报告以及配置审计,来建立并维护工作产品的完整性。推荐阅读《配置管理是个“小怪兽”》
二、CM过程域简介
CMMI-DEV V1.3模型中,“配置管理”过程域涉及以下活动:
• 识别所选工作产品的配置,其在给定的时间点上组成基线
• 控制对配置项的变更
• 构建或提供规格说明,以便从配置管理系统构建工作产品
• 维护基线的完整性
• 向开发人员、最终用户与客户提供准确的状态与当前的配置数据
置于配置管理下的工作产品包括向客户交付的产品、指定的内部工作产品、采购的产品、工具以及在创建并描述这些工作产品时使用的其它项。(见术语表中“配置管理”的定义。)
可能置于配置管理下的工作产品的实例有:
• 硬件与设备 |
• 测试工具与测试脚本 |
• 迭代工作清单 |
• 图纸 |
• 安装日志 |
• 过程描述 |
• 产品规格说明 |
• 产品数据文件 |
• 需求 |
• 工具配置 |
• 产品技术出版物 |
• 架构文档与设计数据 |
• 代码与库 |
• 计划 |
• 产品线计划、过程与核心资产 |
• 编译器 |
• 用户故事 |
采购的产品可能需要由供方与项目都置于配置管理之下。供方协议中应建立执行配置管理的规定。确保数据完备且一致的方法应得到建立与维护。
参阅CMMI模型中,“供方协议管理”过程域,以进一步了解如何建立供方协议。
工作产品的配置管理可按多个粒度级别执行。配置项可以分成配置组件与配置单元。在本过程域中只使用术语“配置项”。所以,在这些实践中“配置项”适当时可解释为“配置组件”或“配置单元”。(见术语表中“配置项”的定义。)
基线为配置项的持续演变提供稳定的基础。
基线的一个实例是已批准的产品描述,包括内部一致的需求版本、需求可追溯矩阵、设计、特定学科条目与最终用户文档。随着基线内容得到开发,基线被纳入配置管理系统。通过配置管理的配置控制、变更管理以及配置审计功能,对基线的变更以及从配置管理系统所构建的工作产品的发布得到系统化地控制与监督。
本过程域不仅适用于项目的配置管理,也适用于组织级工作产品,如标准、规程、复用库与其它共享的支持资产等的配置管理。
配置管理关注工作产品的管理与技术方面的严格控制,包括交付的产品或服务。
本过程域覆盖执行配置管理职能的实践,也适用于置于配置管理之下的所有工作产品。
对于产品线,由于产品线下各产品之间以及核心资产与产品的多个版本之间的核心资产共享,配置管理还涉及另外需要考虑的事项。(见术语表中“产品线”的定义。)
在敏捷环境中,配置管理是非常重要的,因为需要支持频繁变更、频繁构建(通常每天)、多条基线与多个配置管理支持的工作区(例如,为个人、团队、甚至结对编程)。敏捷团队可能陷入困境,如果这个组织没有:
1)将配置管理自动化(例如,构建脚本、状态记录与报告,完整性检查)并
2)将配置管理作为单独的一套标准服务加以实施。在敏捷团队启动时,就应该识别负责确保配置管理活动正确实施的人。在每个迭代开始时,重新确定配置管理支持的需要。配置管理被谨慎地集成到各团队的工作节奏中,把焦点集中在尽量减少对团队的干扰,以使工作完成。(见第一部分中的“使用敏捷方法时对CMMI的解读”。)
三、与CM过程域相关的其他过程域
参阅CMMI模型“项目监督与控制”过程域,以进一步了解如何对照计划监督项目,并管理纠正措施直至关闭
参阅CMMI模型“项目计划”过程域,以进一步了解如何制订项目计划。
四、CM过程域的特定目标与特定实践摘要
SP 1.1 识别配置项
SP 1.2 建立配置管理系统
SP 1.3 创建或发布基线
SP 2.1 跟踪变更请求
SP 2.2 控制配置项
SP 3.1 建立配置管理记录
SP 3.2 执行配置审计