CMMI 3标准文档模板-配置管理-配置管理计划

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-功能配置审计报告。

项目编号：项目名称：数字签名配置管理支配状态 草稿标识号V1.0初始版当前版本修订版发布日期2C1模板编号密级 无密级 秘密 绝密修订历史记录日期版本说明作者变更恳求号0.1起草李晓娅1.0发布李晓娅目录1.简介41.1目的41.2范围41.3定义、首字母缩写词和缩略语41.4参考资料51.5概述52.软件配置管理52.1组织、职责和接口52.2工具、环境和基础设施63.配置管理活动93.1配置标识93.2配置项变更限制103.3配置管理活动支配113.4报告和审计144.培训和资源154.1培训所需环境154.2培训参与人员164.3培训具体支配165.分包商和厂商软件限制16配置管理支配1.简介1.1目的在数字签名项目的生命周期内，为了保证该项目工作产品、过程记录及项目相关资料的版本统一和完整，特制定本支配。

1.2范围纳入数字签名项目配置管理的配置项、过程记录及其它相关资料。

1.3定义、首字母缩写词和缩略语本小节应供应正确理解此配置管理支配所需的全部术语、首字母缩写词和缩略语的定义。

这些信息可以通过引用项目词汇表来供应。

配置管理。

1.3.1配置项（ )指定为配置管理的对象且作为单个实体进行处理的硬件、软件或两者的集合。

1.3.2基线（）一种通过正式评审和认可的规范说明或产品，此后将其作为进一步开发的基础，只有通过正式的变更限制过程才可以变更。

1.3.3基线库（）项目软件生命周期中基线的集合。

用软件工具管理时，基线库可以是一个独立的系统，也可以是系统中的一个书目。

1.3.4配置审计（）审核配置管理库系统的结构和设施，验证软件基线库内容的完备性和正确性，验证及适用的配置管理标准和规程的符合性1.3.5配置限制委员会（）有权力管理项目基线的委员会，它代表项目经理和全部可能受到项目基线更改影响的组的利益，由它审定项目基线的建立和配置项/单元的标识，评审和审定对项目基线的更改，审定对项目基线库制造的产品的生成。

第17章配置管理配置管理(Configuration Management,CM)的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性，配置管理是对工作成果的一种有效保护。

☆制定配置管理计划[SPP-PROC-CM-PLANNING]。

☆配置库管理[SPP－PROC－CM-LIB]。

☆配置项版本控制[SPP-PROC－CM－VERSION]。

☆配置项变更控制[SPP－PROC－CM－CHANGE]。

上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

本规范适用于国内IT企业的软件研发项目。

建议用户根据自身情况（如商业目标、研发实力等）适当地修改规范，然后推广使用。

17.1 介绍项目研发和管理过程中会产生许许多多地工作成果。

例如文档、程序和数据等，它们都应当背保存起来，以便查阅和修改。

如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。

毫无疑问，人们应当将文件分类、有条理地保存起来。

凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI），配置项主要有两大类：●属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。

●项目管理和机构支撑过程域产生的文档。

这些文档虽然不是产品的组成部分，但是是值得保存。

每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。

所有配置项都被保存再配置库里，确保不会混淆、丢失。

配置项及其历史记录反映了软件的演化过程。

基线(BaseLine)由一组配置组成，这些配置项构成了一个相对稳定的逻辑实体。

基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。

基线通常对应开发过程中的里程碑(Milestone),一个产品可以有多个基线，也可以只有一个基线。

基线的主要属性有：名称、标识符、版本、日期等。

XXXX项目配置管理计划简介本计划描述了配置组织结构以及贯穿项目组日常工作，由项目组识别并定义的一系列的配置项的实践过程。

1.1文档目的定义配置管理的职责、所需资源以及描述实施过程中一系列的配置管理活动，指导项目软件配置管理工作。

1.2适用范围本计划适用于XXXX项目的软件配置管理活动的制定。

1.3项目背景描述略。

1.4术语与缩略语软件配置管理：简称 SCM（Software Configuration Management），是在项目开发中，标识、控制和管理软件变更的一种管理。

配置项目标识：（Configuration Indentification）对软件项目在开发过程中的资源进行标识，以便标识。

配置审计：（Configuration Audit）对软件配置管理过程中的行动进行检查。

资源2.1配置管理组织架构图配置管理的组织架构主要角色有公司的配置管理（Configuration Management，CM），项目的配置管理（Configuration Management，CM），项目经理（Project manager，PM），以及配置管理审批人和项目成员。

图1 组织架构图2.2关键角色和职责配置管理员项目组中负责配置管理工作的角色，负责计划和控制配置管理过程。

在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统计添加或修改相关产出物的最新有效版本以及审核证明。

配置管理委员会（CCB）CCB 是一个虚拟的小组，对配置管理各项活动拥有决策权（例如审批配置管理计划，审批配置项变更请求等）。

CCB 的决策采用“少数服从多数”的原则。

主要成员：甲方项目经理、高层领导、需求专家、架构专家、配置管理人员、测试专家和质量保证人员。

2.3所需资源表1 配置管理工具及辅助软件工具名称发布公司用途GitLab GitLab 配置库管理工具，主要源代码SVN Apache软件基金会配置库管理工具，主要是文档Microsoft Office Microsoft 办公工具Microsoft Project Microsoft 办公工具SCM 活动3.1配置库的创建和授权项目配置库创建项目配置库申请审批通过后，项目经理通过一体化运维平台的工作单给项目组配置管理员，要求开通配置库，并说明项目人员权限。

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配置管理计划项目配置管理员负责数字签名项目的配置管理，包括配置项的识别、控制、审计和变更管理等。

同时，还需与项目经理、开发团队、测试团队等相关人员建立良好的沟通和协作关系，确保配置管理活动的顺利进行。

2.1.2配置控制委员会配置控制委员会是数字签名项目的决策机构，由项目经理和各相关组织的代表组成。

委员会负责审定项目基线的建立和配置项/单元的标识，评审和审定对项目基线的更改，审定对项目基线库制造的产品的生成。

配置管理员应该与配置控制委员会保持密切的联系，及时向其汇报配置管理的情况，以便委员会能够及时做出决策。

2.1.3项目经理项目经理是数字签名项目的领导者，负责项目的整体规划、组织、实施和控制。

在配置管理方面，项目经理需要与配置管理员、配置控制委员会等相关人员协作，确保配置管理活动符合项目的整体计划和目标。

2.1.4开发团队和测试团队开发团队和测试团队是数字签名项目的核心团队，他们负责开发和测试项目的软件产品。

在配置管理方面，他们需要与配置管理员密切合作，确保软件产品的配置项得到正确的识别、控制和变更管理。

2.2配置管理活动2.2.1配置项识别配置项是指作为单个实体进行处理的硬件、软件或两者的集合。

在数字签名项目中，配置项包括软件产品、文档、测试数据等。

配置管理员需要确定哪些项是配置项，以便进行后续的配置管理活动。

2.2.2配置项控制配置项控制是指对配置项进行标识、版本控制、访问控制等，以确保配置项的正确性和完整性。

配置管理员需要使用相应的工具和流程对配置项进行控制，防止配置项的误用或丢失。

2.2.3配置项审计配置项审计是指对配置管理库系统的结构和设施进行审核，以验证软件基线库内容的完备性和正确性，验证与适用的配置管理标准和规程的符合性。

配置管理员需要定期进行配置项审计，确保配置管理库的正确性和完整性。

2.2.4配置项变更管理配置项变更管理是指对配置项进行变更控制，以确保变更的正确性和可追溯性。

受控软件经常被划分为各类配置项（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.发布新版本。

16
© 1995-2002 Soft Tech Development, Inc. All rights reserved.
配置审计

配置审计是指对于存储配置项及相关记录的软 件基线库的结构、内容进行检验，其目的在于 验证基线是否符合描述基线的文档。

配置审核工作主要集中在两个方面，即：


功能配置审核 (FCA)—— 验证配置项的实际功效是 与其软件需求一致的。 物理配置审核 (PCA)—— 确定配置项符合预期的物 理特性，即特定的媒体形式。

17
© 1995-2002 Soft Tech Development, Inc. All rights reserved.

14
© 1995-2002 Soft Tech Development, Inc. All rights reserved.
软件配置库的要求

安全可靠性


保证软件配置库中的内容不被任意删除、修 改 保证软件配置库不被非法用户获取 保证各阶段基线各配置项的完整性

22
© 1995-2002 Soft Tech Development, Inc. All rights reserved.
特定活动

SP 1.2-1 Establish a Configuration Management System

10
© 1995-2002 Soft Tech Development, Inc. All rights reserved.

The CM Wheel
Identification
CM PLAN
Accounting Audit Control

降低开发通过规范化的 流程和工具，降低了因 版本混乱导致的错误和
缺陷修复成本。
配置管理通过有效的变 更管理和审核机制，避 免了不必要的返工和重 复劳动，降低了开发成
本。
配置管理通过优化资源 配置和提高工作效率， 减少了人力和物力资源 的浪费，进一步降低了
开发成本。
05
配置管理的最佳实践和案例分享
性和可靠性。
通过配置管理数据库，可以方 便地查询、修改和管理配置项， 提高软件开发的效率和质量管
理水平。
变更管理工具
变更管理工具用于协调和控制软件开发生命周期中的变更，确保变更的合 理性和可控性。
变更管理工具通常包括变更请求、变更评估、变更实施和变更验证等环节 的管理功能。
通过变更管理工具，可以有效地跟踪和管理变更，降低变更对软件开发过 程的影响，提高软件质量。
成功的配置管理经验分享
建立明确的配置管理流程
制定详细的配置管理计划，明确配置项、配置标识、配置 控制和配置审计等环节，确保所有相关人员都清楚自己的 责任。
实施定期的配置审计
为了确保配置管理的有效性和合规性，应定期进行配置审 计，检查配置管理活动的执行情况，识别存在的问题并及 时纠正。
建立配置管理知识库
对配置管理活动进行审查，确保其符合计划 要求和标准。
制定配置审计计划
明确配置审计的目标、范围、方法和时间表。
配置审计报告
生成配置审计报告，总结审计结果，并提出 改进建议。
03
配置管理工具
版本控制工具
01
版本控制工具用于管理软件配置项的变更，确保在软件开发过 程中，各个版本之间的一致性和可追溯性。
配置项发布
将经过批准的配置项发布到相应的存储库，并对其进行版本控制。

项目计划书目录1概述 (1)1.1目的 (1)1.2范围 (1)1.3术语和缩写 (2)2项目信息 (2)2.1项目背景 (2)2.2项目范围 (2)2.3项目约束 (3)3软件生命周期 (3)4项目进度安排 (6)5项目监督 (7)6人力资源计划 (8)8数据资料管理计划 (13)9软硬件资源和管理工具计划 (15)10关键依赖 (16)11沟通计划 (17)12干系人介入计划 (20)13风险管理计划 (26)14软件工程计划 (27)14.1需求管理计划 (27)14.1.1需求管理的工作产品列表 (27)14.1.2需求状态的跟踪及追溯 (28)14.2需求变更管理 (28)14.3设计计划 (29)14.4实现 (29)14.5测试计划 (29)15项目从属计划 (29)15.1度量计划 (29)15.2配置管理计划 (29)15.3质量保证计划 (29)15.4.1评审环境配置 (31)15.4.2评审的标准 (31)1概述1.1目的明确项目开发的全过程，规定了在开发过程中需要完成的活动和目标，为本项目的实施提供指导依据。

本文档的读者包括项目经理、系统分析人员、开发人员、测试人员、QA以及相关部门的接口人员等。

1.2范围本项目计划适用于《丰县云计算数据资源管理平台》项目。

本文涉及内容包括：项目计划完成的活动及其目标；项目采用的质量计划；项目的交付件；项目采用的质量计划；项目进度；项目的配置管理；项目的风险管理。

1.3术语和缩写2项目信息2.1项目背景随着网络技术的逐步成熟，网络服务的不断增加，互联网行业已经进入了一个高速发展期。

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

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

本项目旨在为相关管理工作提供一个科学、便捷的软件平台，提高管理水平，提高工作效率。

2.2项目范围该系统将实现丰县云计算数据资源中心的产品服务宣传和管理。

CMMI 3标准文档模板第13章系统测试 (1)13.1 介绍 (1)13.2 系统测试规程 (2)13.2.1目的 (2)13.2.2角色与职责 (2)13.2.3启动准则 (2)13.2.4输入 (2)13.2.5主要步骤 (3)[Step1] 制定系统测试计划 (3)[Step2] 设计系统测试用例 (3)[Step3] 执行系统测试 (3)[Step4] 缺陷管理与改错 (3)13.2.6输出 (3)13.2.7结束准则 (4)13.2.8度量 (4)13.3 实施建议 (4)第13章系统测试系统测试（System Test, ST）的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

系统测试过程域是SPP模型的重要组成部分。

本规范阐述了系统测试的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

本规范适用于国内IT企业的软件研发项目。

建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。

13.1 介绍系统测试流程如图14-1所示。

由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试”阶段结束。

这样可以提高系统测试的效率。

系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。

图13-1 系统测试流程图项目经理设法组建富有成效的系统测试小组。

系统测试小组的成员主要来源于：✧机构独立的测试小组（如果存在的话）。

✧邀请其它项目的开发人员参与系统测试。

✧本项目的部分开发人员。

✧机构的质量保证人员。

系统测试小组应当根据项目的特征确定测试内容。

一般地，系统测试的主要内容包括：✧功能测试。

即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。

运行环境
项目结束
项目组
路漫漫其修远兮, 吾将上下而求索
2020/4/7
定义配置活动：包括基线变更控制、发布等 确定进度安排，如：提交基线进度安排：基线名称、基线内容、在
生命周期中哪个阶段建立、确定配置项提交人等信息；产品审计、 发布的时间、责任人及具体工作内容；
确定基线变更控制等级及控制机构、控制方式；
确定配置管理状况报告的内容、报告人、报告给谁、报告的方式 、时间、周期；
受控库：受控区存放通过评审的工作产品，此区域的配置项 由项目经理或CCB评审批准后，由SCM人员从集成库和开发库 中更新（move）而来，由部门级 SCM 工程师管理与维护；
产品库：保存可以发行的软件产品的各个发布版本，由组织 级 SCM 工程师管理与维护。在这个库中只存放发布的产品。
路漫漫其修远兮, 吾将上下而求索
事件驱动 评审结束
项目组 SQA小组
4-评审&Review
过程检查要素表.xls 会签单.xls
评审结束 评审结束
SQA小组 SQA小组
过程审计报告.xls
评审结束
SQA小组
5-会议纪要
会议纪要.doc
事件驱动
项目组
源代码
编码阶段
项目组
目标代码
编码阶段
项目组
安装包
编码阶段
项目组
开发环境
项目启动
项目组
路漫漫其修远兮, 吾将上下而求索
2020/4/7
配置状态的统计
形成基线时，SCM人员填写SCM基线报告 基线变更时，SCM人员根据项目经理提交的变
更控制表填写SCM基线变更状态报告 产品发布后，SCM人员填写SCM产品发布清单 定期或事件驱动向QA经理、部门总经理、项目

SG1 应用项目定义过程
IPM
集成项目 管理
SG2 与相关干系人协调和合作
OPD
组织级过 程定义
SG1 建立并维护一套组织过程资 产
SG1 确定过程改进机会
OPF
组织级过 程焦点
SG2 规划和实施过程改进
SG3 部署组织过程财富
ML3
SG1 建立组织级培训能力
OT
组织培训 管理
SG2 提供必要的培训
交付物
配置计划 配置计划 配置计划 变更控制、变更申请、分析变更记录 变更控制、变更申请、分析变更记录 功能审计、物理审计 功能审计、物理审计 度量计划 度量计划 度量计划、度量数据表 度量计划、度量数据表 度量计划
里程碑报告
过程检查表、不符合项报告、工作记录 产品检查表、工作记录
MPP、周报、项目进展报告 项目进展报告 风险识别表 SVN/配置管理 MPP、项目计划 里程碑报告、周报、会议纪要 会议纪要 项目进展报告、项目偏差报告 项目进展报告 项目进展报告 项目计划（WBS分解结构） 项目计划（WBS分解结构） 项目计划（WBS分解结构） 项目计划（WBS分解结构） 项目计划（WBS分解结构） 风险识别表 配置管理、项目计划 项目计划（WBS分解结构-带资源要求） 培训计划（项目计划一部分） 项目计划（WBS分解结构） 项目计划（WBS分解结构） 项目计划、项目子计划评审报告 调整后的计划 计划评审（计划及会议纪要） 用户需求书（客户签字） 用户需求书评审报告 需求变更申请 需求追踪矩阵 不一致检查表
SG1 定量项目管理
QPM
量化的项 目管理
SG2 统计管理子过程性能
因果分析 CAR 与解决方
案
SG1 确定缺陷原因 SG2 解决产生缺陷的根源

【项目名称】配置管理计划广东×××技术股份有限公司修订历史记录【模板使用必读：模板内容和页眉中【】包含内容为指导性的待替换文字，请在使用中替换为具体内容，或删除。

文件提交时不得再含有这些内容。

】目录1人员及职责 (4)2软件硬件资源 (4)3配置项计划 (4)4基线计划 (5)5配置库备份计划 (5)6版本控制规则 (5)7变更控制规则 (6)1人员及职责提示：（1）根据项目计划中的角色分配,确定配置管理员,CCB（2）CCB的人数根据项目的规模而定.（3）职责:项目经理制定项目计划;配置管理员创建和维护配置库等;CCB审批《配置管理计划》及重大的变更2软件硬件资源3配置项计划提示：1、配置项请参照《配置管理规范》的要求确定，应包括管理、工程和支撑类的所有配置项；2、项目经理标识配置项,估计每个配置项的正式发布时间.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 值。

注：产品发布后要注意产品发布版本号与CVS版本号的对应关系，填写《版本发布说明书》7变更控制规则提示：参见配置管理过程域中的变更控制规程。

1. 2. 3. 4. 5. 6. 7. 8. 9. 所有经过批准的变更都已经得到实施 相关的配置项得到更新 没有进行未经授权的变更 已经建立了适当的状态报告入口 所有的新增或者变更的配置项都经过了质量检查点 发布的产品和软件需求、设计保持一致的 对发布进行评审，以确保产品满足客户需求 相关的变更控制机构已经审核过未处理的变更请求 版本描述文件已经准备完成
基础管理篇
之（一）
1
配置管理（CM)
Agenda
项目中的CM问题 CMMI中CM过程域描述与定义 CM的实践 CM工具
3
项目中的CM问题
4
开发中典型的CM问题
发错了版本 安装后不工作 异地不能正常工作 已经解决的缺陷过后又出现错误 开发人员把产品拿出去出售赢利 找不到最新修改了的源程序
5
CMMI模型有关CM实践解析
基线是一组配置项(CI)的集合：
– 经过了正式的评审和批准 – 作为进一步工作的基础 – 变更必须经过正式的变更控制程序
不同的基线可能：
– 在开发的不同阶段建立 – 控制权限会有不同
1.2 定义基线
31
推荐的基线
基线 需求 开发 运行 何时建立 客户需求评审 概要设计评审 发布给客户 CCB 项目经理 CCB 控制者
职能：
– – – – 确保变更被分类以及被评估 评审和批准变更 确保只有被批准的变更得到实施 决定需要实施的变更的优先级
变更控制活动必须在整个项目中具有可视性 CCB成员可能包括： 项目经理，配置管理员，质 量保证人员，开发人员代表，客户代表
36
CCB主席的职责
设立接收变更的标准 发起对请求的变更的评估 从CCB成员获取建议的行动方案 解决关于变更请求的争议 做出CCB负责的裁决的最终决策 记录CCB会议纪要，记录 CCB对变更请求的 处理行动

XXX项目-过程和产品质量保证计划二零零六年六月目录1 前言 (1)1.1 目的 (1)1.2 范围 (1)1.3 术语 (1)1.4 参考文献 (1)1.5 项目信息 (1)2 项目质量目标 (1)3 角色和职责 (1)4 质量保证的对象和时机 (1)5 质量保证活动进度表 (7)5.1 用户评价计划(可选) (7)6 质量保证工作汇报流程 (7)7 度量与分析流程 (8)1.前言1.1 目的•明确项目过程中质量保证的需求；•明确质量保证的内容（对象）；•明确项目组中质量保证的职责；•明确实施质量保证的策略和方式、方法；•明确实施质量保证的切入点（质量保证的时机）；•明确质量保证的物资资源和人员投入；•明确项目过程中质量保证的支持环境；•明确质量保证过程的提交物。

1.2 范围质量保证活动贯穿项目的全生命周期，范围包括过程、工作产品和服务。

项目所有过程的质量必须经过质量保证评价，采取对被评价过程的主要活动进行参与及审查的方式。

1.3 术语•EPG（Engineering Process Group）：工程过程组1.4 参考文献1.5 项目信息2 项目质量目标系统考核一次通过。

3 角色和职责事业部经理：每月末检查各项目的工作状态；每季末向公司汇报项目状态。

项目经理：负责用户参加的重大里程碑评审工作。

系统设计师：负责审核项目的系统质量保证大纲、质量保证计划；根据质量保证周/月报，审核项目质量保证活动；负责无用户参加的里程碑评审工作；对软件开发全过程负责；对软件技术实施和软件质量负责；负责审核软件质量保证计划、工作产品评审模板；质量师：质量部人员，承担项目质量控制和质量保证职责；同系统设计师一起确定项目的质量保证目标；参与项目质量计划、标准和规程的制定；负责制定《系统质量保证大纲》，确保项目质量保证活动的执行；负责组织项目的基线评审、重大里程碑检查工作；负责拟制PPQA月报；项目质量保证人员：事业部人员，协助项目质量师拟制项目质量保证大纲；参与项目质量保证标准和规程的制定；依据项目质量保证大纲，负责拟制项目质量保证计划；对项目组提供有关质量保证活动的培训与支持；参加项目里程碑评审；负责拟制PPQA周报；对过程的符合性进行评价，并向项目总师汇报评价结果；项目的PPQA组：由质量师、项目质量保证人员组成。

按照文件编写规范和实际流程改写－20070724配置管理规程变更记录1前言1.1目的本文用于描述配置管理过程。

配置管理是维护整个生命周期产品完整性的重要活动，本文档明确规定了公司配置管理活动的目标和过程活动，指导配置管理活动的正确开展。

1.2适用范围本过程适用于公司范围内所有的项目。

配置管理过程在项目全生命周期均可适用。

1.3术语CCB：Configuration Control Board，配置控制委员会CM：Configuration Management，配置管理Baseline：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，它有三个特征：•已经过正式的评审和批准。

•作为项目发展和产品升级的基础。

•其变更必须遵循《变更控制规程》的约定。

随着系统及其所属各子系统的任务书的评审和批准，建立起功能基线；随着项目需求规格说明书的批准，建立起分配基线；随着项目设计说明书（或概要设计说明书）的批准，建立起设计基线；随着该项目系统的集成与系统测试的完成，建立起产品基线。

1.4参考文献《CMMI-SW, V1.1, Staged Representation》;《软件生命周期》2过程目标配置管理过程的目的是采用配置标识、配置控制、配置状态统计以及配置审计来建立和维护工作产品的完整性。

●建立并维护、标识工作产品的基线。

●跟踪和控制变更●建立和维护基线的完整性。

3角色职责4输入配置管理以批准的项目任务书为基础，配置管理计划的制定与项目策划同时进行，各项目开展配置管理工作的输入包括：●项目计划●需求规格说明书●具备进行配置管理必须的资源和经费5入口准则●指定了项目组配置管理员，成立CCB组，负责和承担配置管理工作的人员经过配置管理的培训●配备了进行配置管理活动必须的资源和经费6 活动6.1 活动关系图图0-1 配置管理活动关系示意图6.2 活动描述7 输出受控库除包含源程序代码、可执行代码、测试用例外，还包含归档资料和CMMI其它过程域输出的工作产品。