CMMI模板-配置管理报告

(完整word版)CMMI标准测试总结报告模板V1.0

测试总结报告Prepared by拟制Date 日期Reviewed by 评审人Date 日期Approved by批准Date 日期Revision Record 修订记录目录1测试总体情况 (5)1.1背景 (5)1.2测试基本情况 (5)2测试进度差异 (5)2.1总体计划差异比较 (5)2.2测试阶段差异比较 (5)2.3进度差异分析 (5)3工作量差异 (5)3.1工作量差异比较 (6)3.2工作量差异分析 (6)4风险控制情况 (6)5组间协作情况 (6)6成果 (6)7经验分析 (6)Table List 表目录表1测试基本情况 (5)表2总体计划差异比较 (5)表3测试阶段差异比较 (5)表4工作量差异比较 (6)Figure List 图目录错误！未找到图形项目表。

测试总体情况背景[背景、客户情况、具体要求及所要达到的测试目标。

]测试基本情况测试基本情况测试进度差异总体计划差异比较总体计划差异比较测试阶段差异比较测试阶段差异比较进度差异分析[如果有进度拖延，分析阐述造成测试进展程度差异的原因。

] 工作量差异工作量差异比较工作量差异比较工作量差异分析[如果有，分析阐述造成测试具体工作量偏差的原因。

]风险控制情况[测试进展过程中对风险进行有效控制的手段和取得的成效，以及不足之处和今后需改进、解决的问题和手段。

]组间协作情况[测试进展过程中各个项目职责组之间相互协调工作的实际具体情况，不足之处和改进解决手段。

]成果[测试工作总体完成结果；可复用的测试用例列表等。

]经验分析[测试组负责人介绍在测试管理过程中的实际经验和在此次项目中所感悟的优势与不足，以及推动测试工作进展过程中的方法和手段，其优缺点各是什么，取得的效果如何等等各个方面的收获和教训，不只局限于个人，包括团队中的任何一分子对测试工作推动的感悟。

对其他协作部门和质量控制体系的建议和意见等。

[19]注：以上内容大纲可制作成ppt模式便于汇报时交流。

CMMI-3CM-SP11-配置项状态报告模板

配置项状态报告
项目名称配置项名称系统需求说明书系统概要设计说明书系统详细设计说明书需求跟踪矩阵数据库设计 .net公共模块程序源代码（需细分） UI设计说明书测试计划测试报告软件维护说明书可执行代码项目计划
河南济源信贷管理系统
配置项标识
当前版本配置项状态
JYXD_XTXQSMS
已基线 20060413
20060413
黎平所属基线功能基线设计基线设计基线设计基线设计基线产品基线产品基线产品基线产品基线产品基线产品基线产品基线产品基线
1）计划类是受控配置项； 2）报告类是存档； 3）表中只保存最后一个版本的信息，详细信息看变更记录 4）出库时间为最后一次出库时间，如果是存档类的内容没有出库可言。 5）不同的基线应当存放在不同的路径下 6）平时开发的代码或文档，没有必要进基线库或受控库。所以应当不会出现33次修改，请看《配置管理计划》 7）项目经理不能直接负责配置管理工作
20060703
JYXD_SJCSJ
1
已基线 20050614
20050614
JYXD_CODE_NET_COMMON
1.4
已基线 20060301
20060301
JYXD_CODE_SOURCE
1.33 已基线 20060412
20060412
JYXD_UI
1
已基线 20050622
20050622
20060610 变更次数
0 3 2 0 0 4 3 1 3 3 2 3 2
JYXD_TESTPLAN
1.3
已基线 20050630
20050630
JYXD_TESTREPORT

全套CMMI(信息系统项目管理)文档模板-配置管理方案

1简介 (2)1.1目的 (2)1.2适用范围 (2)1.3术语表 (2)1.4参考资料 (2)1.5职责描述 (2)2配置管理活动 (3)2.1软件资源与硬件资源 (3)2.2标识配置项 (3)2.2.1配置项标识规则 (3)2.2.2配置项名称格式说明 (4)2.2.3配置项 (4)2.3项目基线管理 (4)2.3.1基线列表 (5)2.3.2基线建立流程 (5)2.3.3基线的变更控制 (6)2.4发布管理 (7)2.5配置库管理 (7)2.5.1各类库结构 (7)2.5.2库的权限设置 (8)2.5.3库的备份与恢复 (8)2.6配置状态的记录和报告 (8)2.7 配置审计 (8)2.8人员安排与时间安排 (9)3数据资料管理计划 (9)1简介1.1目的木计划是用来指导项目配置管理作业的过程与步骤，以便全而地管理、保存软件生命周期各个配置项，监控各配置项的状态，让小组所有成员能及时了解软件基线的状态和内容，从而实现对软件过程的控制，持续改进软件流程，保证软件产品质量、降低风险，实现项目规划的所有需求，同时提高开发团队的工作效率、降低软件开发成木。

1.2适用范围木项目中纳入配置管理的活动：项目管理文档(如项目计划、配置计划等)、项目技术文档(需求规格说明书、概要设计等)、源程序及模块文档、基线、产品、用户文档、项目工具。

1.3术语表1.4参考资料无1.5职责描述表2-12配置管理活动配置活动的目的是向项目组每一个人传达在木项目中如何进行配置。

参见《配置管理过程文件》。

2.1软件资源与硬件资源2.2标识配置项2.2.1配置项标识规则项目级的配置项是指由于项目实施而产生的记录。

为了便于查询、搜索今后各项目的文档及版本，下面将专门制订一套约定，统一、规范项目的命名格式。

凡进入项目级配置管理库下的工作产品都应依照下列命名约定进行。

1）举例示例1,系统项目计划的配置标识：--------------------------------------------- 系统---------------------------------------------------- 北京驰波名气通数据服务有限公司2.2.2配置项名称格式说明1）配置库中配置项命名格式的顺序是根据产出物所产生的文档先后次序来命名的，例如：01-项目配置管理计划；02-功能配置审计报告。

全套CMMI(信息系统项目管理)文档模板-单元测试报告

单元测试结果报告目录1.引言 (3)1.1编写目的 (3)1.2项目背景 (3)1.3术语定义 (3)1.4参考资料 (3)2.测试概要 (5)2.1进度回顾 (5)2.2测试用例 (5)2.3测试方法 (5)2.4测试执行 (5)2.5测试环境 (6)2.5.1 软硬件环境 (6)3.测试结果83.1.覆盖率 (8)3.1.1.需求覆盖83.1.2.测试覆盖83.2.缺陷汇总 (9)3.3.缺陷分析 (9)3.4.遗留缺陷 (10)4.测试结论与建议 (11)4.1.测试结论 (11)4.2.测试建议 (11)1.引言1.1编写目的编写该测试总结报告主要有以下几个目的：1．通过对测试结果的分析，得到对软件质量的评价2．分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考3．评估测试测试执行和测试计划是否符合4．分析系统存在的缺陷，为修复和预防bug提供建议本测试总结报告适合以下读者：项目管理人员测试负责人员项目组相关人员1.2项目背景软件名称: 遵义市新区开发投资有限责任公司技术培训中心弱电设备供应及安装项目1.3术语定义缺陷BUG：软件未达到产品需求说明书的要求或者是出现了产品说明书中不应出现的错误或者未有达到需求所要求的目标。

白盒测试：通过编写测试代码的方式或者运行程序代码，测试系统在各种输入下的输出情况来判断系统的执行结果。

缺陷密度：单位代码行或者单位功能点中存在的缺陷数。

1.4参考资料✓《计算机软件产品开发文件编制指南》✓《计算机软件配置管理计划规范》✓《计算机软件质量保证计划规范》2.测试概要遵义市新区开发投资有限责任公司技术培训中心弱电设备供应及安装项目软件单元测试从2016年7月30日开始到2016年8月5日结束，共持续5天，测试功能点78个，执行156个测试用例，测试共发现200个BUG，平均每个测试功能点2.56个BUG。

测试过程中发现的BUG通过《BUG管理一览表》进行缺陷跟踪管理2.1进度回顾2.2测试用例具体见《单元测试用例》。

全套CMMI(信息系统项目管理)文档模板-详细设计方案

详细设计书目录1 引言 (1)1.1编写目的 (1)1.2项目背景 (1)1.3预期读者 (2)1.4参考文献 (2)2任务概述 (2)2.1目标 (2)2.2运行环境 (3)2.3需求概述 (3)2.4条件与限制 (4)3总体设计 (4)3.1功能模块分析 (4)3.2总体结构及模块结构 (8)3.3详细功能模块设计 (8)3.4数据库设计 (13)4接口设计 (20)4.1 外部接口设计 (20)4.2软件接口 (35)4.3硬件接口 (35)4.4内部接口设计 (35)5运行设计 (35)5.1运行模块的组合 (35)5.2运行控制 (35)5.3运行时间 (36)6出错处理设计 (36)6.1出错输出信息 (36)6.2出错处理对策 (36)7安全保密设计 (36)8维护设计 (37)1 引言1.1编写目的本设计方案对云计算中心管控平台软件系统的总体设计与实现作详细说明。

用于记录系统在技术层面上的实施过程，以需求说明作为设计的根本出发点，作为产品实现、功能要求和控制的依据。

为开发人员指明设计方向，便于其在最短的时间内开发出功能最齐全的软件。

1.2项目背景随着网络技术的逐步成熟，网络服务的不断增加，互联网行业已经进入了一个高速发展期。

传统的需求设计，开发测试，上线部署的软件开发模式已经很难满足这些企业快速的发展需求。

而于此同时另一种新的按需付费的软硬件交付模式越来越受到许多企业青睐。

为此，我们开发出一套用于管理云计算中心订单和服务收费的软件系统——鼎驰云计算中心计费管理系统，用于云计算中心管理人员对用户申请的订单进行审核、审批管理，对用户租用云计算中心的资源和服务产生的费用进行计费，并形成管理需要的报表，旨在为相关管理工作提供一个科学、便捷的软件平台，提高管理水平，提高工作效率。

开发软件名称：云计算中心管控平台软件项目开发者：江苏鼎驰电子科技有限公司11.3预期读者本说明书的预期读者是项目的开发人员，测试人员和维护人员。

CMMI实验报告

CMM2标准CMM 2（可重复级）就是建立了基本的项目级管理过程，可对项目的成本、进度进行跟踪和控制，生产的过程、标准、工作产品以及服务都是被严格定义和文档化的。

基于以往管理类似的项目的经验，计划和管理新项目，并可依据一定的标准重复利用类似的软件产品。

CMM 2的核心就是重复利用。

CMM2由6个关键过程域(KPA)组成：需求管理(RM)、软件项目计划(SPP)、软件项目跟踪与监控(SPTO)、软件子合同管理(SSM)（本文略）、软件质量保证(SQA)、软件配置管理(SCM)。

需求管理(Requirement Management)需求管理的目的是为了在客户和处理客户需求的软件项目之间建立共识。

这是软件项目规划(SPP)和管理(SPTO)的基础，需求变更依赖于配置管理(SCM)的变更控制流程。

在项目实施过程中，最突出的现象就是项目组成员没有完全理解需求，软件需求不稳定，客户经常变更需求，无法有效控制需求变更，需求变更往往造成项目延期和费用超支。

CMM2要求的需求管理的基本流程可如<图一>所示。

该流程描述了软件工程组开始获取原始需求，汇总为系统需求，分配系统需求，复审软件需求，软件需求必须文档化形成需求文档，此文档必须经过相关组和个人的评审，通过评审之后才纳入配置管理，为需求文档建立基线。

软件项目计划、活动及软件工作产品，应和软件需求的变化保持一致。

根据流程，可以结合实际开发情况确定项目的需求管理步骤：a. 获取需求和确认需求以Use case（用例）为单位，以Rational Requisite Pro作为需求管理工具，使用Rational Rose进行维护Use case和Use case Model。

获取需求工件是：用例模型(Use case Model)、非功能性的“补充规约”、用例规约(Use case Specification)、词汇表(Glossary)b. 通过访谈，从客户处获取原始需求，形成需求文档。

CMMI3配置管理文件

基线是一组配置项(CI)的集合：
– 经过了正式的评审和批准 – 作为进一步工作的基础 – 变更必须经过正式的变更控制程序
不同的基线可能：
– 在开发的不同阶段建立 – 控制权限会有不同
1.2 定义基线
31
推荐的基线
基线需求开发运行何时建立客户需求评审概要设计评审发布给客户 CCB 项目经理 CCB 控制者
基础管理篇
之（一）
1
配置管理（CM)
Agenda
项目中的CM问题 CMMI中CM过程域描述与定义 CM的实践 CM工具
3
项目中的CM问题
4
开发中典型的CM问题
发错了版本安装后不工作异地不能正常工作已经解决的缺陷过后又出现错误开发人员把产品拿出去出售赢利找不到最新修改了的源程序
5
CMMI模型有关CM实践解析
SG 2 Track and Control Changes
– Changes to the work products under configuration management are tracked and controlled. – 在配置管理之下的配置项变更得到跟踪和控制
SG 3 Establish Integrity
1.1 识别需要控制的产品
1.2 定义基线
1.3 建立可追溯性
1.4 建立配置管理库
26
配置项识别
“配置项"
– 开发中产生或者使用的任何条目 – 或者加入到产品中的条目
“例子”
– – – – – 规格说明源代码测试案例编译器数据库
“软件配置"
– 定义一个软件产品的所有配置项
1.1 识别需要控制的产品ຫໍສະໝຸດ 29COTS, 工具等

CMMI-3CM-GP22-配置管理计划模板

CM计划1 前言1.1 目的本计划是XXX项目计划的组成部分，它规定了在信贷管理系统项目中如何开展配置管理工作，以便在项目的整个生存周期中，建立和维护工作产品的完整性和一致性。

1.2术语定义和缩写词CCB（Configuration Control Board）：配置控制委员会Baseline：基线，是开发规程中标识出的里程碑所交付的一个或多个配置项，它有以下三个特征：•已经通过正式的评审和批准；•作为项目扩展和产品升级的基础；•其变更必须遵循《配置管理规程》的约定。

1.3 参考文献《配置管理规程》项目计划初稿2 角色、职责与培训2.1 角色与职责2.2 CCB组成3 配置管理活动3.1 基线和配置项的标识本项目的配置项和基线的名称和编号参见《配置项状态报告》。

项目初期，需要确定项目的配置项并对其进行标识。

当新增或修改配置项时，同样需要对配置项进行标识。

本项目的配置项和基线的标识详见《配置项标识和状态列表》（基线的变更标识依照《配置管理规程》执行），该表包括配置项和基线清单及预计创建时间。

3.2 配置库结构和权限3.2.1 配置管理库描述本配置管理库作为CVS中的一个独立的源代码仓库（Repository），分成四个物理上互相独立的存储空间：产品空间、基线空间、组工作空间和个人空间，每个空间作为一个独立的目录（用module实现）。

产品空间属于产品库，基线空间、组工作空间的内容均属于受控库，个人空间的内容属于开发库。

产品空间：存放提交给用户的产品；基线空间：存放所有基线内容。

组工作空间：存放经过评审的文档和所有不放入基线库的工作产品，个人空间：项目组成员存放个人任何信息，文档的开发和修改均在个人空间进行。

从个人空间向组工作空间的提升由项目经理批准，从组工作空间向基线空间的提升由CCB评审批准，均由CM工程师执行。

提升后删除原空间的配置项。

产品空间用Tag的方式标识不同版本的产品。

例如，软件需求规格说明书在编写或修改时，放到作者的个人空间进行管理，经过评审后，提升到相应的“211 需求规格说明书”目录中，形成基线后，再提升到“110 需求规格说明书”。

CMMI-配置管理计划

EPG过程改进项目_x001D_ 配置管理计划广东×××技术股份有限公司修订历史记录目录1人员及职责 (4)2软件硬件资源 (4)3配置项计划 (4)4基线计划 (5)5配置库备份计划 (5)6版本控制规则 (5)7变更控制规则 (6)1人员及职责2软件硬件资源3配置项计划4基线计划5配置库备份计划6版本控制规则文档版本号规则文档版本和配置管理中的版本概念不同，它指的是文档的发布版本。

1、处于“草稿”状态（开发库）的文档的版本号格式定义为:0.YZ.➢YZ数字范围可以为01～99。

➢随着草稿的不断完善, “YZ”的取值应不断递增。

2、处于“正式发布”状态（基线库）的文档的版本号格式定义为:X.Y。

➢X为主版本号,取值范围为1～9。

Y为次版本号,取值范围为1～9。

➢如果文档第一次“正式发布”时,版本号为1.0。

➢如果文档的版本升级幅度比较小,一般只增大Y值,X值保持不变。

只有当文档版本升级幅度比较大时,才允许增大X值。

3、处于“正在修改”状态（开发库）的文档的版本号格式定义为:X.YZ。

➢文档正在修改时,一般只增大Z值,X.Y值保持不变。

➢当文档修改完毕,状态重新成为“正式发布”时,将Z值设置为0,增加X.Y值。

注：产品发布后要注意产品发布版本号与VSS版本号的对应关系7变更控制规则基线了的配置项需要修改的时候按照《配置变更控制规程》执行。

具体操作如下：配置管理员向CCB提交变更申请（变更申请表合并在《项目、产品变更表》中，由项目经理一起提交给CCB）。

如果CCB同意变更,CMO给项目组足够的权限修改同意变更的配置项，CCB 督促变更任务的执行，项目组修改完成后，CMO审核变更后的配置项，审核通过后发布变更的配置项；如果不同意变更，终止变更。

无论配置项变更是否同意，最终由CMO保存变更申请单。

对于那些在“变更控制和管理流程”中确定的小型变更则不必执行此配置变更规程，只需项目组口头向CMO申请变更，项目组修改后由CMO审核通过即可，并通知项目组。

CMMI中配置管理

受控软件经常被划分为各类配置项（Configuraion items, CIs），这类划分是进行软件配置管理的基础和前提，CIs是逻辑上组成软பைடு நூலகம்系统的各组成部分。比如一个软件产品包括几个程序模块，每个程序模块及其相关文档和支撑数据可能被命名为一个CI。一个系统包括的CIs的数目是一个与设计密切相关的问题。一个纯软件的CI通常也称之为软件配置项（CSCI）。
现在所有的配置管理工具均提供对配置项的管理工具，包括(Check in 和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比较繁琐，一般推荐使用配置管理工具，减少事务性工作。
基线
在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。
配置审计配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。审计机制保证修改的动作被完整地记录，也就是说，记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方。在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个 “W”（Who、When、Why、What）。同时配置审计工作应当可以说明如下信息。
变更管理的流程： 1.（获得）提出变更请求； 2.由CCB审核并决定是否批准； 3.为（被接受）修改请求分配人员，提取SCI，进行修改； 4.提交修改后的SCI，并测试（或者评审）； 5.重建软件的适当版本； 6.复审（审计）所有SCI的变化； 7.发布新版本。

全套CMMi软件质量管理体系【范本模板】

XXXXX计算机软件有限公司XX软件质量管理体系V1。

0XX软件研发部2010/12/1目录第一篇总则 (3)一、《XX软件质量管理体系》的实施 (3)二、目的 (3)三、背景介绍 (3)四、体系总体介绍 (4)第二篇项目管理 (6)一、立项管理 (6)二、结项管理 (13)三、项目计划 (17)四、项目监控 (26)五、风险管理 (32)六、需求管理 (36)第三篇技术实现过程 (42)一、技术预研 (42)二、SCRUM过程 (45)三、用户验收 (51)四、技术评审 (54)第四篇支撑过程 (60)一、配置管理 (60)二、质量保证 (66)三、培训管理 (72)四、服务与维护 (77)第一篇总则一、《XX软件质量管理体系》的实施XX计算机软件有限公司依据CMMi(软件能力成熟度模型集成)框架，结合公司多年来实施“敏捷开发”的开发方法的经验，以及公司的实际情况,编写的《XX软件质量管理体系》V1.0版已经编写完成.本体系文档是公司质量管理体系法规性文件，是指导公司建立并实施质量管理体系的行动准则。

公司全体员工必须遵照执行。

二、目的本文档的目的在于：✧通过建立软件过程管理体系,提高企业的软件过程能力,保证软件质量,保证商务目标的实现。

✧基于精简的CMMi 3级管理体系，结合企业实际情况和经验积累，结合敏捷开发的SCRUM方法。

开发适合XX软件有限公司发展的软件过程管理体系。

✧使得XX软件的软件开发过程管理基本满足CMMi 3级要求.三、背景介绍CMMI—DEVCMMI是个了不起的规范，但是仍然有很多不足之处。

CMMI对于项目管理很有指导价值，但是它对技术开发过程的论述却不够深入。

对于大多数软件项目而言，技术开发占总工作量的70％以上，而项目管理占总工作量的30％以下。

对大多数企业而言，技术开发过程的规范化比项目管理过程的规范化尤为重要与迫切。

软件开发是如此的灵活，如果没有规范来指导与制约,就容易因无序而导致混乱。

05 项目总结报告(CMMI模板)

XX项目项目编号：项目总结报告1引言1.1编写目的[说明编写这份项目开发总结报告的目的，指出预期的读者。

]1.2背景[说明：●本项目的名称和所开发出来的软件系统的名称；●此软件的任务提出者、开发者、用户及安装此软件的计算中心。

]1.3定义[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

]1.4参考资料[列出要用到的参考资料，如：●本项目的已核准的计划任务书或合同、上级机关的批文；●属于本项目的其他已发表的文件；●本文件中各处所引用的文件、资料，包括所要用到的软件开发标准。

列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

] 2实际开发结果2.1产品[说明最终制成的产品，包括：●程序系统中各个程序的名字，它们之间的层次关系，以千字节为单位的各个程序的程序量、存储媒体的形式和数量；●程序系统共有哪几个版本，各自的版本号及它们之间的区别；●每个文件的名称；●所建立的每个数据库。

如果开发中制订过配置管理计划，要同这个计划相比较。

]2.2主要功能和性能[逐项列出本软件产品所实际具有的主要功能和性能，对照可行性研究报告、项目开发计划、功能需求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。

] 2.3进度[列出原定计划进度与实际进度的对比，明确说明，实际进度是提前了、还是延迟了，分析主要原因。

]2.4费用[列出原定计划费用与实际支出费用的对比，包括：●工时，以人月为单位，并按不同级别统计；●计算机的使用时间，区别CPU时间及其他设备时间；●物料消耗、出差费等其他支出。

明确说明，经费是超出了、还是节余了，分析其主要原因。

]3开发工作评价3.1对生产效率的评价[给出实际生产效率，包括：a．程序的平均生产效率，即每人月生产的行数；b．文件的平均生产效率，即每人月生产的千字数；并列出原订计划数作为对比。

]3.2对产品质量的评价[说明在测试中检查出来的程序编制中的错误发生率，即每千条指令（或语句）中的错误指令数（或语句数）。

cmmi配置管理CM

Product specifications 产品规格
Tool configurations 工具配置
Code and libraries 代码和库
Compilers 编译器
Test tools and test scripts 测试工具和测试脚本
Installation logs 安装日志
An example of a baseline is an approved description of a product that includes internally consistent versions of requirements, requirement traceability matrices, design, discipline-specific items, and end-user documentation. 例如，被批准的产品说明是一个基线，它是由需求、需求跟踪矩阵、设计、特定专业项目及最终用户文档构成的内部一致的版本。
配置管理（CM）的目的是通过使用配置识别、配置控制、配置状态记录及配置审计，来建立和维护工作产品的完整性。

Introductory Notes 简介
The Configuration Management process area involves the following activities: 配置管理过程域包括以下活动：
This process area applies not only to configuration management on projects but also to configuration management of organizational work products such as standards, procedures, reuse libraries, and other shared supporting assets. 本过程域不仅适用于项目的配置管理，也适用于组织工作产品（如标准、规程、重用库和其他共享的支持资产）的配置管理。

(完整word)CMMI-支持-CM-配置管理计划模版_V1.0

XX项目软件配置管理计划变更记录修改点说明的内容有如下几种：创建、修改(+修改说明）、删除（+删除说明）目录1 简介 (1)1.1 文档目的 (1)1.2 适用范围 (1)1.3 背景描述 (1)2 参考文件 (1)3 资源描述 (2)3。

1 所需人员 (2)3.1。

1 SCM小组 (2)3.1.2 配置管理委员会（CCB） (2)3.1。

3软件配置的组织结构图 (2)3.2 所需资源 (3)3.2.1 计算机设备 (3)3.2.2 辅助工具 (3)4 SCM活动 (3)4.1 配置项和基线 (3)4.1。

1 基线选择 (3)4。

1。

2 配置项标识 (3)4。

2 控制基线变更 (4)4.2。

1 变更控制 (4)4。

2.2 变更控制人员职责 (4)4。

2.3 管理问题报告非正式变更是否需要在此处进行描述 (5)4。

3 配置状态信息 (5)4。

4 基线建立计划 (5)4.5 基线审计计划 (5)4。

6 基线的发布 (6)4.7 构造产品 (6)4。

7.1 构造产品的时机 (6)4.7。

2 构造的次数 (6)4。

7。

3 构造人员 (6)4.7。

4 对应路径 (6)4。

7。

5 构造方法和步骤： (6)4.8 软件配置库的管理 (7)5 备份 (7)6 培训 (7)7 附表 (8)7。

1 《项目基线一览表》 (8)7。

2 《基线及配置项选择表》 (9)7。

3 《配置项状态记录》 (10)7。

4 《产品发布表》 (10)1 简介本计划描述了关于××××项目的SCM组织结构以及贯穿本项目软件生命周期的由SCM组织识别并定义的一系列的软件配置项的实践过程。

计划SCM工作必须在项目最开始时进行，和开发整个软件项目计划（SPP）保持一致。

软件配置管理计划（SCMP），连同软件质量保证计划（SQAP)和其他可能的特定约束计划都要符合本项目的软件项目计划.SCMP完成之后应该由本项目的项目经理、SQA经理和其他有关人员进行审阅和批准。

CMMI配置管理说明及相关文档模板

6................................................................................................................................... 骤步要主 5 .3 .71
6................................................................................................................................... 则准动启 3 .3 .71
5....................................................................................... 》划计理管置配《批审 ]5p e tS [
5........................................................................................... 划计份备库置配定制 ]4p e tS [
7.......................................................................................................................................... 制控本版 3. 71 7............................................................................................................................................ 量度 8 .3 .71 7............................................................................................................................................ 出输 6 .3 .71 7................................................................................................................................... 则准束结 7 .3 .71

CMMI模板-配置管理报告

【项目名称】
配置管理报告模板
编号：
编制：
审核：
复核：
批准：
修订历史记录
A-增加M-修订D-删除
变更版本号
日期
变更类型
（A*M*D）
修改人
摘要
备注
【模板使用必读：模板内容和页眉中【】包含内容为指导性的待替换文字，请在使用中替换为具体内容，或删除。文件提交时不得再含有这些内容。】
1基本信息4
2项目组成员的操作权限4
3基线记录4
4配置变更记录4
5配置库备份记录5
6配置库重要操作日志5
1
项目名称
配置管理员
CCB(负责人和成员)
使用配置管理软件
配置库名称
2
类别
成员
权限说明
配置管理员
产品经理
项目经理
测试人员
开发人员（1）
开发人员（2）
UI设计人员
质量保证人员
3
基线名称﹑版本
创建日期
包含配置项备注4来自配置项基线次数
最后基线时间
最后基线版本
最后变更原因
5
备份次数
责任人
备份日期
备份内容﹑说明
备份位置
6
日期
人员
事件