项目-配置管理计划.docx

项目全称配置管理计划
项目名称
项目全称
项目代号
项目编号
起始时间

产品名称
配置管理计划
产品代号
PZGL
产品版本
1.0

配置管理计划

文档编号
文档类型
密级
项目编号-PZGL-TOTAL

编制/日期
审核/日期
批准/日期
QA姓名/2013-2-25

变更控制状态
对应实施阶段
页数

共 页

承建方全称

承建方全称 第 15 页
文档修改记录（Revision Chart）

*S – START A - ADDED M - MODIFIED D - DELETED
版本号
日期
修订人
S*
A
M
D
版本修订描述
批准
草稿v0.1

QA姓名
S
首次编写。

发行版1.0

QA姓名
A
评审

文档复核记录（Re-check Chart）
序号
修改条款
修改内容
修改人/日期
批准人/日期
实施日期

目录
配置管理计划 1
承建方全称 1
文档修改记录（REVISION CHART） 2
文档复核记录（RE-CHECK CHART） 2
1 前言 5
1.1 标识 5
1.2 系统概述 5
1.3 目的要求 5
1.4 与其他文档的关系 5
2 引用文件 5
3 术语和定义 6
4 组织与资源 7
4.1 组织机构 7
4.2 SCM小组 7
4.3 CCB 7
4.4 职责 8
4.5 资源 8
4.5.1软件设计开发环境 8
4.5.2软件开发硬件环境 9
4.5.3配置管理客户端 9
5 配置管理活动 9
5.1 配置项和基线 9
5.1.1基线 9
5.1.2配置项 11
5.2 控制基线变更 12
5.2.1变更控制 12
5.2.2变更控制人员职责 13
5.2.3非正式变更的控制 13
5.3 配置状态信息 13
5.4 基线审计计划 13
5.5 基线的发布 14
5.6 构造产品 14
5.7 软件配置库的管理 14
5.8 版本命名约定 14
5.9 配置检查和审核 15
5.10 配置管理计划的修订 16
6 备份 16

1 前言
1.1 标识
1） 标识号：项目编号，PZGL，TOTAL；
2） 标题：项目全称配置管理计划；
3） 本计划适用于项目全称，为整个项目的配置管理进行约束。
1.2 系统概述
根据项目招投标文件和合同，本次项目所涉及的建设工作有：基础平台部分、原有系统升级部分、业务模块开发部分、以及部署和培训等。业务范围覆盖系统管理、教育、教学、德育、行政管理、校园安全等，还涉及部分软硬件系统集成工作。
制定本项目的SCM计划，SCM计划的执行应该与开发活动计划相一致，以保证SCM工作范围同开发工作的范围一致。通过识别要置于配置管理之下的配置项和将要建立基线的点，可以确定SCM工作的需求范围和时间。在此背景之下，制定本软件配置管理计划。
1.3 目的要求
本计划描述了关于“项目全称”项目的SCM组织结构以及贯穿本项目软件生命周期的由SCM组织识别并定义的一系列的软件配置项的实践过程。计划SCM工作必须在项目最开始时进行，和开发整个软件项目计划（SPP）保持一致。软件配置管理计划（SCMP），连同软件质量保证计划（SQAP）和其他可能的特定约束计划都要符合本项目的软件项目计划。SCMP完成之后应该由本项目的项目经理、SQA负责人和其他有关人员进行审阅和批准。
项目组在实施、设计与开发系统软件的各级子系统时，都应该执行本计划中有关规定。但可以根据各自的情况对本计划做适当的剪裁，以满足特定的配置要求。剪裁后的计划必须经过批准。
1.4 与其他文档的关系
本计划来源于项目的招投标文件、合同、项目经理制定的项目计划（SPP）和质量保证人员（QA）制定的质量保证计划（SQAP），对项目项下的各阶段基线、里程碑、设计开发过程和项目成果物进行配置管理。对项目配置项进行识别、标识、文档命名进行规范配置管理。
2 引用文件
序号
资料名称
说明
作者/
提供者
版本和
发行日期
获取途径
1
GB/T 11457 软件工程术语

公司ISO文档

2
GB 8566 计算机软件开发规范

公司ISO文档

3
GB 8567 计算机软件产品开发文件编制指南

公司ISO文档

4
GB/T 12505 计算机软件配置管理计划规范

公司ISO文档

5
项目全称招标文件

公司项目文档

6
项目全称投标文件

公司项目文档

7
项目全称合同

公司项目文档

8
项目开发计划

公司项目文档/项目经理

9
项目质量保证计划

公司项目文档/QA

3 术语和定义
Ø 软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。
Ø 基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
Ø 配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。
Ø 配置控制委员会：（Configuration Control Board CCB）负责评审和批准对基线的变更，通常由项目选出的代表组成。
Ø 配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识别。
Ø 配置项：（Configuration Item）软件配置管理的对象称为配置项。
Ø 配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。
Ø BJDC：项目全称。
4 组织与资源
4.1 组织机构
项目管理委员会
（李欣、卢文广、项目经理姓名）
项目经理（项目经理姓名）
QA（QA姓名）
产品经理（沈涛）
测试经理（张明利）
配置管理（QA姓名）
技术经理（姜兆杰）
质量管理小组（SQAT）
需求分析
系统设计、数据库设计
软件开发
CCB&
配置管理委员会
系统测试组
实施培训经理（李楠）
培训组
实施组
部署配置（张涛）
集群部署

图4-1 项目组织结构
4.2 SCM小组
本项目的软件配置管理活动都由SCM小组负责执行，SCM领导负责计划和控制软件配置管理过程。配置负责人：QA（配置管理专员），配置人员：项目经理（项目中协助工作的配置管理员、一般由项目经理担任）
4.3 CCB
CCB负责管理项目的软件基线，它的职责主要包括审定软件基线的建立和 CSCIs 及配置项的标识，评审和审定对软件基线的更改，以及审定由软件基线库制造的产品的生成等。
本项目的配置控制委员会（CCB）成员如下：
高层经理：卢文广（CCB主席）
项目经理：项目经理姓名
SCM&SQA负责人：QA姓名
技术负责人：姜兆杰
测试负责人：张明利
客户接口人：李楠
4.4 职责
Ø 配置管理专员职责
l 评审配置管理计划，批准配置管理计划的生效
l 批准各阶段各类配置管理库的启用和配置管理项/单元标识的有效性
l 评审和批准对软件基线变更的变更申请（主要活动）
l 审定由配置管理库制造的软件生成的正确性
l 定期或事件驱动审核软件基线和配置管理活动
Ø 软件配置管理组（SCM组）职责
l 项目各阶段配置管理库的建立和管理，流策略的实现
l 制订和维护软件配置管理计划
l 负责软件基线的更新，审核已执行的对基线的变更
l 负责对软件基线库的存取管理
l 定期发布软件配置管理报告、配置管理组行动记录
Ø 配置控制委员会CCB职责
l 批准建立软件配置项的软件配置项的软件基线和标识
l 授权软件配置管理组从软件基线库生成产品
l 对软件配置项变更要求的处理给出建设性意见
4.5 资源
4.5.1软件设计开发环境
软件名称
作用
Windows 2008 Server R2
服务器操作系统
Virual Source Safe2005 (VSS)
Concurrent Version System(CVS)
配置管理软件
MyEclipse6.5
软件开发环境
Microsoft Windows SQL server 2008 R2
数据库环境
Axure RP Pro 6.5
原型设计软件
TD8.0 SP2、LoadRunner9.0
测试软件
在整个项目开发过程中中,选择Virual Source Safe (VSS)和SVN作为配置管理工具。VSS用来存储和记录软件开发过程中的文档文件，SVN用来存储和记录软件在开发过程中的代码文件。
4.5.2软件开发硬件环境
名称
规格
说明
网络
局域网

服务器
PC
服务器名称：Sun Jdk1.6、Apache Tomcat6.0
内存：8G
硬盘：为VSS保留20G作为使用空间；为SVN保留20G作为使用空间
客户机
普通PC
项目组成员各自的计算机
4.5.3配置管理客户端
项目组成员在各自的计算机安装VSS客户端和SVN客户端，项目组成员以分配的帐号访问配置服务器和登录配置管理系统，根据配置管理员设定的用户权限进项配置管理活动。
5 配置管理活动
5.1 配置项和基线
项目开始阶段就要确定本项目的配置项CSCIs（Computer Software Configuration Item），根据其在项目中的作用为每个基线和配置项CSCI分配唯一的标识并形成一系列的基线，策划每个CSCI在项目不同时期的版本状态。
5.1.1基线
根据本次项目裁剪过程，确定本次项目的正式基线如下
编号
基线名称
版本号
基线建立时机
计划建立时间
基线变更
权威
1
项目启动基线

项目启动，配置资料库创建，项目启动会PPT
参照项目计划
CCB
2
项目计划评审基线

项目中各任务经过分解，计划经过评审，并得到项目组任务参与人一致认可
参照项目计划
CCB
3
业务模块需求基线

1． 系统业务模块需求调研及需求分析全部完成
2． UI设计经过内部和用户确认
3． 需求分析说明书已通过内部评审
4． 通过需求阶段里程碑评审或与客户一致认为需求分析阶段已结束，可以进入设计阶段
参照项目计划
CCB
4
业务模块设计基线

1． 系统概要设计和详细设计全部完成
2． 已形成相应的概要和详细设计说明书及其它附属文档
3． 概要和详细设计说明书已通过内部评审或与客户一致认为详细设计阶段已结束，可以进入编码阶段
参照项目计划
CCB
6
测试基线

1． 系统测试完成，所发现的所有缺陷已得到妥善处理
2． 符合系统测试退出条件
3． 已完成测试分析报告
参照项目计划
CCB
7
实施基线

1. 完成系统和用户学校基础数据实施
2. 完成各业务功能模块实施
3. 完成对用户的培训
参照项目计划
CCB
8
成熟软件集成

1. 第一包、第三包系统已经就绪
2. 项目计划规定的学校基础数据即应用软件部署完成
参照项目计划
CCB
9
项目初验

1． 已经完成对用户的培训
2． 所有设计、开发、实施阶段工作已经形成文档产物
3． 开发活动停止
参照项目计划
CCB
10
项目试运行

1. 初验完成
2. 解决试运行期出现的问题
参照项目计划
CCB
11
项目终验

1． 试运行期问题解决完成
2． 试运行期满
参照项目计划
CCB

非正式基线（敏捷开发基线）：
编号
基线名称
版本号
基线建立时机
计划建立时间
基线变更
权威
1
需求分析

完成所有用户学校的需求调研，形成需求文档
参照项目计划
项目经理
2
系统集成

与第一包、第三包供应商完成系统部署前支撑环境的准备
参照项目计划
项目经理
3
测试基线1

第一轮测试bug提交开发
参照项目计划
项目经理
4
测试基线2

第二轮测试bug提交开发
参照项目计划
项目经理
5
系统部署

23所用户学校部署上线完成
参照项目计划
项目经理
6
系统培训

23所学校用户使用培训完成
参照项目计划
项目经理
7
其他基线

其他项目经理认为应该进行基线化的时刻
参照项目计划
项目经理

5.1.2配置项
项目开始时，配置人员和项目经理共同选择并确定适用于本项目的配置项，并为配置项分配标识。在VSS中，通过5.1.1节中的基线来标识这些配置项及其版本信息，通过配置项状态报告报出。本项目关注的重要配置项如下表：
分类
元素列表
标识
作者
立项管理
启动PPT

项目经理
项目合同书
合同编号
业主
项目启动会召开监理方会议记录

监理
项目实施方案
项目编号-SSFA-TOTAL
项目经理
项目计划
项目实施计划
项目编号-XMJH-TOTAL
项目经理
项目监控
项目进度报告（月报）
项目编号-JDBG-TAOTAL
QA
项目周报
项目编号-XMZB-第？期
QA
度量与分析
项目度量计划
项目编号-DLJH-TOTAL
QA（内部）
技术评审管理
技术评审报告
项目编号-JSPSBG-TOTAL
QA（内部）
变更控制
变更申请
项目编号-BGSQ-TOTAL-001
项目经理
质量保证
质量保证计划
项目编号-ZLBZ-TOTAL
QA
工作成果审计报告
项目编号-CGSJBG-TOTAL
QA（内部）
过程审计报告
项目编号-GCSJBG-TOTAL
QA（内部）
产品质量分析报告（项目状态报告）
项目编号-ZLFXBG-TOTAL
QA（内部）
问题报告单
项目编号-WTBG-TOTAL-001
QA
配置管理
配置管理计划
项目编号-PZGL-TOTAL
QA
配置项状态报告
项目编号-PZXBG-TOTAL
QA（内部）
基线发布报告
项目编号-JXFB-TOTAL
QA、项目经理（内部）
需求管理
需求调研记录
项目编号-DYJL-XX-001
分项项目经理
需求规格说明书
项目编号-XQGG-TOTAL
分项项目经理
需求规格评审
项目编号-XQPS-TOTAL
项目经理
需求规格确认（功能点清单）
项目编号-GNDQD-TOTAL
项目经理
设计
概要设计
概要设计规格说明：
项目编号-GYSJ-TOTAL
技术经理
概要设计评审报告
项目编号-GYPS-TOTAL
项目经理
数据设计
数据库设计
项目编号-SJKSJ-TOTAL
技术经理
数据库设计评审报告
项目编号-SJKPS-TOTAL
项目经理
编码
项目编码规范：
项目编号-BMGF-TOTAL
技术经理
编码规范评审报告
项目编号-BMPS-TOTAL
项目经理
详细设计
详细设计规格说明
项目编号-XXSJ-TOTAL
技术经理
详细设计评审报告
项目编号-XXPS-TOTAL
项目经理
测试
系统测试
系统测试计划
项目编号-CSJH-TOTAL
测试经理
系统测试计划评审
项目编号-CSJHPS-TOTAL
项目经理
系统测试用例：
项目编号-CSYL-TOTAL
测试经理
系统测试用例评审
项目编号-CSYLPS-TOTAL
项目经理
系统测试记录（部分）
项目编号-CSJL-TOTAL
测试经理
系统测试报告
项目编号-CSBG-TOTAL
测试经理
系统测试报告评审
项目编号-CSBGPS-TOTAL
项目经理
用户测试报告
项目编号-YHCSBG-TOTAL
测试经理
用户文档
用户手册
项目编号-YHSC-TOTAL
实施经理
安装使用手册
项目编号-AZSC-TOTAL
实施经理
实施
推广模块部署实施计划与方案
项目编号-TBSSS-TOTAL
实施经理
新建模块部署实施计划与方案
项目编号-XBSSS-TOTAL
实施经理
系统部署实施报告
项目编号-XBSBG-TOTAL
实施经理
培训
推广模块培训计划
项目编号-TPXJH-TOTAL
实施经理
推广模块培训方案
项目编号-TPXFA-TOTAL
实施经理
新建模块培训计划
项目编号-XPXJH-TOTAL
实施经理
系统培训记录
项目编号-RPXJL-TOTAL
实施经理
代码
项目源代码工程文件：

初验
初验申请
项目编号-CYSQ-TOTAL
QA
初验报告
项目编号-CYBG-TOTAL
QA
初验总结报告
项目编号-CYZJ-TOTAL
项目经理
试运行
问题跟踪记录单（汇总）
项目编号-WTGZ-TOTAL
项目经理
试运行报告
项目编号-SYXBG-TOTAL
项目经理
项目终验
用户使用报告
项目编号-YHSYBG-XXMC
项目经理
终验总结报告
项目编号-ZYZJ-TOTAL
项目经理
工程总体终验申请
项目编号-ZYSQ-TOTAL
QA
工程总体终验报告
项目编号-ZYBG-TOTAL
QA

5.2 控制基线变更
5.2.1变更控制
正式变更：
(1) 项目组填写并向业主和监理提交《变更提案》
(2) 并按照《配置管理过程》中的变更控制来处理
(3) 配置人员应填写《变更与问题日志》
非正式变更：
(1) 项目组借助配置管理工具提出变更请求。
(2) 并按照《软件配置管理过程》中的变更控制来处理
(3) 配置人员应填写《产品发布报告》给定《产品发布报告》模板
5.2.2变更控制人员职责
角色
在配置变更过程中的职责
变更请求者
描述变更、阐明变更理由、描述变更带来的影响、把变更提案（CCR）提交给变更管理员（SCML）。
变更评价者
内部评估变更带来的影响、验证变更原因、将评价结果在CCR中做出记录并提交给业主和监理，SCML备案。
变更管理员（SCML）
负责保存从变更被提交时刻起的CCR、监控变更进展情况并形成《变更状态报告》。
变更授权机构（CCB）
负责批准所控制配置项的变更。
5.2.3非正式变更的控制
软件问题或者是错误（即产品功能与设计与需求不一致），或者是对配置控制下的元素的异常发现（即产品功能与预想的不符），需要更改基线库时，必须填写CCR表，按基线变更流程解决此类问题。
对于在开发过程中发生的变更，要及时通知相关功能的需求、设计文档编写人员，代码编制人员以及测试人员。
5.3 配置状态信息
确定项目中配置状态记录的信息、报告和发布频度。在项目的SCM过程中，需要记录配置管理行动，使得每个配置项的内容和状态都清晰明确，并可恢复配置项以前的版本。
本项目按照下表要求记录和发布配置状态信息：
文档
记录方法
发布频度
发布形式及对象
《配置项状态报告》
手工维护
配置项发生变化时（即变更后的配置项已做基线后）
发布书面的《配置项状态报告》，邮件通知干系人
《基线发布报告》
手工维护
基线发布后进行检查
发布书面的《基线发布报告》，邮件通知干系人
5.4 基线审计计划
在每次主要的软件产品发布之前，必须进行基线审计，验证其完整性。
基线审计计划表：
序号
审计基线类别
审计人员
1
项目启动基线
SCM及相关组人员
2
项目计划基线
SCM及相关组人员
3
项目需求基线
SCM及相关组人员
4
项目设计基线
SCM及相关组人员
5
项目初验基线
SCM及相关组人员
6
项目终验基线
SCM及相关组人员

5.5 基线的发布
基线变更或审计通过之后，由SCM负责人把基线发布给外部客户（如发布发行基线）或内部使用（如为测试而发布）。完成基线发布之后，SCM负责人应该通知所有受影响的人员，使那些经批准可以使用的人利用此发布。
基线的发布应参照过程描述，进行有关发布。
执行步骤如下：
l 提出申请：配置管理专员协助项目经理根据《配置管理计划》和项目进展情况，提出建立正式基线的申请，并填写《基线申请表》的申请部分，提请配置管理委员会的授权。
l 准备基线检查表：配置管理专员准备基线检查表提交配置管理委员会。
l 基线审查：配置管理委员会根据基线检查表审查建立基线申请，填写基线申请表的审批部分。视情况作出是否同意建立基线的决定。
l 建立基线：审查通过后由配置管理专员对配置管理系统中的相应配置项创建基线。首先冻结组成基线的配置项，使这些配置项只读；然后对组成基线的配置项按《配置管理计划》中的规定进行标识。
l 记录：由配置管理员将基线内容记录进《基线发布报告》中，并更改《配置项状态报告》中的对应内容。
l 通报：基线建立完成后，配置管理员通知项目经理和项目组成员，并发布《基线发布报告》和《配置项状态报告》。
有关基线发布的具体内容及说明参见《基线发布报告模板》。
5.6 构造产品
产品的构造是指将源代码进行编译，形成可执行文件，发布给客户的过程。
开发经理构建开发基线、发行人员构建发布基线。
此处需要项目经理安排技术经理和测试经理共同制定产品构建和发布指令。
5.7 软件配置库的管理
规定项目人员对该配置库的访问权限。具体用户组和可以执行的处理过程的对应关系，见附件 《访问权限控制清单》。
5.8 版本命名约定
发布版本命名规则：
版本号 = 主版本号[.次版本号]其中：
Ø 由方括号“[ ]”括起的部分表示一个可选项；
Ø 主版本号：表示一个主要的发布版本，如2、5等；项目进展中，它是不能改变的；
Ø 次版本号：使用一位数字，如0、9；项目进展中，由项目经理决定是否升级；
示例：
发布版本名
含义
V1
表示主版本号为1
V1.2
表示主版本号为1，次版本号为2
5.9 配置检查和审核
配置管理员按照以下软件配置审核列表对配置管理进行检查，审核完毕填写《配置审核管理报告》。
配置审核在每次基线评审提供，此外，每次软件版本发布时也要进行配置审核。
配置审核列表
审计编号
审计日期或事件
（视时间或事件驱动而定）
审计重点
审计者
1．物理审计（每周一次）
A01
SCM硬件环境（机器性能及网络环境）
SCM运行库安装的机器是否能正常运行，网络是否能保持通讯。

A02
SCM系统运行环境
安装SCM工具的操作系统能否保持正常的运行。

A03
SCM工具运行状态
SCM工具是否运行良好。

A04
SCM库的完整性
SCM库中的配置管理项是否是完备的。

A05
SCM库的有备份及可恢复性
SCM库是否定期的备份，备份的数据是否有效，能否在意外的情况下恢复到正常的运行环境中，保证有效。

A06
配置项清单、版本清单、系统版本引用正确性
配置项清单、版本清单、系统版本是否是一致的。

2．功能审计（每周一次）
B01
编译版本前所有相关变更是否完全处理
在编译某个版本时，此版本的相应的变更单所列的变更是否都得到完全的处理，并且是有效的。

B02
版本的修改是否经过正式的流程
所有修改的版本是否具有符合规定的变更处理。

B03
变更是否有影响范围分析
变更责任人是否对有影响的范围进行分析,并填写结果。

B04
版本的修改是否向受影响的组发出通知
如果修改影响到了其他的小组，被影响的小组是否得到相应的版本修改通知。

B05
检查变更是否影响需求基线，如果是，则需求变更的处理是否进入正式的需求变更流程
如果变更影响到了需求，那么需求变更是否得到了相应的处理。

B06
涉及的小组是否有统一讨论的记录
变更有关联的各个小组是否具有统一的讨论。

B07
检查变更是否涉及别的开发组，如果是，相应的变更是否完成
如果变更涉及其他开发组，则需要其他组的变更是否处理。

B08
根据流程的变更强制项是否填写完全
在变更流程中强制的选项是否都已经填写。

3．跟踪审计（每周一次）
C01
所有的产品功能能否追踪到相应的需求
某版本中的所有的功能能否追踪到相应的需求。

C02
是否所有的需求已经完成
某版本要求的需求是否已经全部完成。

4．集成审计（版本发布时）
D01
是否可根据版本配置单编译出对应的版本
使用某版本的版本配置单能否编译出相应的版本。

D02
编译出的版本与先前版本大小、版本生成说明书是否一致
此恢复编译的版本与历史版本是否有一致性的。

5.10 配置管理计划的修订
初始的配置管理计划在项目开始的初期进行制定，由于此时只能大致确定整个开发过程中的一些活动及其会产生的文档，在实际开发过程中，可能会与此有些差异，因此，配置管理计划也需要根据开发过程的实际情况，及时进行修订，使之能够有效地对本项目的配置管理活动进行指导。
在一般情况下，进行配置管理计划修订的时机选在到达各个阶段的里程碑时。如果在一个阶段的实施过程中，配置管理计划不能适应实际过程的变更，则由配置管理员与项目管理人员一起根据实际情况修订配置管理计划。
配置管理计划的修订，需要通过项目的项目负责人、软件质量控制专员、配置管理员的共同审核，一致签字同意后方能作为此后阶段的配置管理计划。
6 备份
序号
备份时间
备份人
备份媒体
备份保存时间
1
每两周
张明利
异地备份在硬盘上
1年
2
基线发布后
张明利
异地备份在硬盘上
1年
3
基线发生变更后
张明利
异地备份在硬盘上
1年