配置管理计划模板

项目名称配置管理计划版本1.0[注：以下提供的模板用于RationalUnifiedProcess。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=正文）。]修订版历史日期版本说明作者日/月/年x.x详细信息姓名目录1.简介1.1目的1.2范围1.3定义、首字母缩写词和缩略语1.4引用1.5概述2.软件配置管理2.1组织、职责和接口2.2工具、环境和基础设施3.配置管理活动3.1配置标识3.1.1标识方法3.1.2项目基线3.2配置和变更控制3.2.1变更请求的处理和审批3.2.2变更控制委员会(CCB)3.3配置状态统计3.3.1项目介质存储和发布进程3.3.2报告和审计4.里程碑5.培训和资源6.分包商和厂商软件控制配置管理计划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.分包商和厂商软件控制[说明将如何并入在项目环境外部开发的软件。]