<项目名称>
配置管理计划
版本 <1.0>
· [注：以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。]
修订历史记录
目录
1. 简介 3
1.1 目的 3
1.2 范围 3
1.3 定义、首字母缩写词和缩略语 3
1.4 参考资料 3
1.5 概述 3
2. 软件配置管理 3
2.1 组织、职责和接口 3
2.2 工具、环境和基础设施 3
3. 配置管理活动 3
3.1 配置标识 3
3.1.1 标识方法 3
3.1.2 项目基线 3
3.2 配置和变更控制 3
3.2.1 变更请求的处理和审批 3
3.2.2 变更控制委员会 (CCB) 3
3.3 配置状态统计 3
3.3.1 项目介质存储和发布进程 3
3.3.2 报告和审计 3
4. 里程碑 3
5. 培训和资源 3
6. 分包商和厂商软件控制 3
配置管理计划
1. 简介
· [配置管理计划的简介应提供整个文档的概述。它应包括此配置管理计划的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]
1.1 目的
· [阐明此配置管理计划的目的。]
1.2 范围
· [简要说明此配置管理计划的范围；它的相关模型，以及受到此文档影响的任何其他事物。]
1.3 定义、首字母缩写词和缩略语
· [本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。 这些信息可以通过引用项目词汇表来提供。]
1.4 参考资料
· [本小节应完整列出此配置管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。]
1.5 概述
· [本小节应说明此配置管理计划中其他部分所包含的内容，并解释文档的组织方式。]
2. 软件配置管理
2.1 组织、职责和接口
· [说明谁将负责执行 CM 工作流程中所述的各种配置管理 (CM) 活动。]
2.2 工具、环境和基础设施
· [说明在整个项目过程或产品生命周期中为实现 CM 功能而使用的计算环境和软件工具。
· 说明对整个项目过程或产品生命周期中生成的配置项进行版本控制时所需的工具和过程。
· 建立 CM 环境时所涉及的问题有：
· 产品数据量的预期大小
· 产品团队的分配
· 服务器和客户机的实际位置]
3. 配置管理活动
3.1 配置标识
3.1.1 标识方法
· [说明项目工件或产品工件的命名、标记和编号方法。标识方案中需包括硬件、系统软件、市售 (COTS) 产品以及产品目录结构中所列的所有应用程序开发工件，例如计划、模型、构件、测试软件、结果与数据、可执行文件等。]
3.1.2 项目基线
· [基线提供一项正式标准，随后的工作都基于此标准，并且只有经过授权后才能对此标准进行变更。
· 说明要在项目或产品生命周期中的哪些时间点处建立基线。最常用的基线在先启阶段、精化阶段、构建阶段和产品化阶段结束时建立。也可以在不同阶段中的各次迭代结束时生成基线，甚至可以更为频繁。
· 说明由谁来对基线授权，以及基线中包含的内容。]
3.2 配置和变更控制
3.2.1 变更请求的处理和审批
· [说明提交、复审和处理问题及变更时所遵循的流程。]
3.2.2 变更控制委员会 (CCB)
· [说明 CCB 在处理和审批变更请求时所遵循的成员资格标准和过程。]
3.3 配置状态统计
3.3.1 项目介质存储和发布进程
· [说明保留策略、备份计划、事故处理计划和恢复计划。还应说明介质的保留方式：联机、脱机、介质类型和格式。
· 发布过程应说明此发布版的内容、它所针对的对象，以及是否有已知的问题和安装说明。]
3.3.2 报告和审计
· [说明所需报告和配置审计的内容、格式和目的。
· 报告用于在项目和产品生命周期中的任意给定时间对“产品质量”进行评估。如果根据变更请求来报告缺陷，就可以提供一些有用的质量指标。因此，应提醒管理人员和开发人员多注意特别关键的开发领域。缺陷通常按其严重程度（高、中和低）分类。可以依据以下各项来报告缺陷：
· 龄期（基于时间的报告）：各种缺陷已经打开了多久？在生命周期中，从发现缺陷到修复缺陷有多长的“滞后时间”？
· 分布（基于计数的报告）：在按照拥有者、优先级或修复状态划分的不同类别中各有多少个缺陷？
· 趋势（与时间和计数有关的报告）：在一段时间内发现并修复的缺陷累计有多少个？缺陷发现率和修复率是多少？就打开的缺陷和关闭的缺陷而言，它们之间的“质量差距”有多大？解决缺陷所用的平均时间为多长？]
4. 里程碑
· [确定与项目或产品 CM 工作相关的内部里程碑和客户里程碑。本节应该包括有关何时更新 CM 计划本身的详细信息。]
5. 培训和资源
· [说明实施指定的 CM 活动时所需的软件工具、人员和培训。]
6. 分包商和厂商软件控制
· [说明将如何并入在项目环境外部开发的软件。]
第二篇：项目配置管理心得体会
项目配置管理心得体会：
1、配置管理的定义：配置管理是标识和控制配置项，以维护其完整性、可追溯性以及正确性的学科
2、配置管理的过程：
（1） 配置项识别。
（2） 配置项标识。
（3） 配置库创建。
（4） 基线计划。
（5） 备份计划。
（6） 配置库管理（权限管理、基线管理、配置项审计、版本管理）
3、有效实施配置管理后的解决问题：
（1） 开发人员未经授权修改代码或文档。
（2） 人员流动造成企业的软件核心技术泄密。
（3） 找不到某个文件的历史版本。
（4） 无法重现历史版本。
（5） 无法重新编译某个历史版本，使维护工作十分困难。
（6） “合版本”时，开发冻结，造成进度延误。
（7） 软件系统复杂，编译速度慢，造成进度延误。
（8） 因一些特性无法按期完成而影响整个项目的进度而导致项目失败。
（9） 已修复的bug在新版本中出现。
（10） 配置管理制度难于实施。
（11） 分处异地的开发团队难于协调，可能会造成重复工作，并导致系统集成困难。
4、在实施配置管理过程中遇见的问题：
（1） 配置管理制度难于实施。解决办法：在项目立项时，对项目组成员进行配置管
理制度理解培训，让大家都意识到配置管理在整个项目中重要位置。
（2） 已修复的bug在新版本中出现。 解决办法：有效的控制配置管理过程中每一
阶段的变更修改，并记录相关信息。如：
? 谁进行的修改？
? 修改了什么？
? 什么时候进行的修改？
? 为什么要进行修改？
? 当前发布包含哪些新功能?
? 当前发布对已有功能进行了那些增强?
? 当前发布修复了哪些BUG?