测试中心配置管理保证计划

20##年8月

修订纪录

目录

第一章         简介... 3

1.1            目的... 3

1.2            范围... 3

1.3            缩略语... 3

1.4            参考文档... 3

第二章         人员与职责... 4

第三章         配置管理活动... 5

3.1            配置库建立... 5

3.2            配置项命名规范... 5

3.3            基线命名规范... 5

3.4            配置项清单... 6

3.5            基线计划... 6

3.6            配置审查... 6

3.7            基线发布报告... 6

3.8            配置项管理... 7

第四章         培训计划... 7

第五章         环境资源清单... 8

第一章    简介

1.1         目的

定义本文档的目的是指导分布式前端建设项目软件配置管理活动。

1.2         范围

适合分布式前端建设项目

1.3         缩略语

1.4         参考文档

《工作说明书》

《项目定义与估算工作表》

《项目管理工具》

《质量保证计划》

《配置管理指南》

第二章    人员与职责

第三章    配置管理活动

3.1         配置库建立

遵循标准配置库结构，包括：开发库、受控库、产品库。

l  开发库  用于存放开发过程中的源代码及文档等，项目组成员所有的开发活动均在开发库中进行

l  受控库 文档评审确认或代码通过集成测试后，项目配置管理员将其纳入到受控库

l  产品库 产品验收测试通过及发布批准后，项目配置管理员将受控库中用于构建安装部署包的测试基线代码及安装、部署手册等纳入到产品库；

l  受控库和产品库只有项目配置管理员拥有写权限。

配置项命名规范

3.2         基线命名规范

3.3         配置项清单

3.4         基线计划

3.5         配置审查

3.6         基线发布报告

3.7         配置项管理

第四章    培训计划

 

 

第五章    环境资源清单

第二篇：软件项目配置管理计划案例

软件项目配置管理计划案例

本案例选自《软件项目管理案例教程》（韩万江，机械工业出版社）一书，项目案例为《校务通管理系统》，该项目的配置管理计划如下：

1.  引言

包括目的、缩写词和参考资料，具体内容略。

2．组织及职责

配置管理的角色和职责见表1。

表1：配置管理角色职责表

3.配置管理环境

由于本项目属于中小型项目，工期也不很长，而且项目组人员对Visual SourceSafe也比较熟悉，所以采用Visual SourceSafe作为配置管理工具。

3.1配置库目录结构

表2：配置库的目录结构

3.2用户及权限

表3：配置库的用户权限

4．配置管理活动

4.1 配置项标志

4.1.1 命名规范

本项目配置项命名规范由5个字段组成，从左到右依次为：公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线（-）分隔。

图1：配置项命名规范

4.1.2 主要配置项

表4：配置项列表

4.1.3 项目基线

在Visual SourceSafe中基线由LABLE标志，字母必须为大写。基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。

表5

4.1.4 配置项的版本管理

配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支：主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。

这四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

对配置项的版本管理在不同分支具有不同的策略：

（1）    主干分支

系统默认自动建立的物理分支——主干分支（/main）,基线均以LABLE方式出现在主干分支上。

（2）    私有分支

如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。

（3）    小组分支

如果出现小组共同开发一配置项，该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。

（4）    集成分支

集成测试时在主干分支的特定版本（由LABLE标志清晰）上建立集成分支，测试工作在集成分支上完成。

私有分支和小组分支均为可选，必要时建立。

4.2 变更管理

变更管理的流程是：

（1）    由请求者提交变更请求，SCCB会召开复审会议对变更请求进行复审，以确定该请求是否为有效请求。典型的变更请求管理有需求变更管理、缺陷追踪等。

（2）    配置管理者收到基线修改请求后，在配置库中生成与此配置项相关的波及关系表。

（3）    配置管理者将基线波及关系表提交给SCCB，由SCCB确定是否需要修改，如果需要修改，SCCB应根据波及关系表，确定需要修改的具体文件，并在波及分析表中标志出来。

（4）    配置管理者按照出库程序从配置库中取出需要修改的文件。

（5）    项目人员将修改后的文件提交给配置管理者。

（6）    配置管理者将修改后的配置项按入库程序放入配置库。

（7）    配置管理者按SCCB标识出的修改文件，由波及关系表生成基线变更记录表，并按入库程序放入配置库。

4.3 配置状态统计

利用配置状态统计，可以记录和跟踪配置项的改变。状态统计可用于评估项目风险，在开发过程中跟踪更改，并且提供统计数据以确保所有必需的更改已被执行。为跟踪工作产品基线，配置管理者需手机下列信息：

● 基线类型                         ● 工作产品名称

● 配置项名称/标识符                ● 版本号

● 更改日期/时间                    ● 更改请求列表

● 需要更改的配置项                 ● 当前状态

● 当前状态发生日期

项目组每周提交配置项清单及其当前版本。

配置管理人员每半个月提交变更请求的状态统计。