软件配置管理规范样本文档格式.docx

软件配置管理规范样本文档格式.docx

《软件配置管理规范样本文档格式.docx》由会员分享，可在线阅读，更多相关《软件配置管理规范样本文档格式.docx（9页珍藏版）》请在冰豆网上搜索。

本规范是为了配合公司配置管理流程文件的执行所给出的配置管理活动中配置项用命名、角色定义及权限分配规范,目的是给配置管理流程的使用人员详细的操作指南。

2目标

配置管理活动相关人员经过本规范的学习,充分撑握配置项命名规范、配置管理活动中所有角色的定义和权限的设置,更有效的执行公司配置管理流程。

3术语

3.1软件配置管理（SoftwareConfigurationManagement,SCM）

软件配置管理是标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。

一言以蔽之,配置管理是门经过一系列技术、方法和手段来维护产品的历史、鉴别和定位产品独有的版本、在产品开发和发布阶段控制变化,从而使管理制度化、有效减少重复性工作、保证产品的质量和效率的科学。

。

3.2配置项（configurationItem,CI）

软件配置指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。

该集合中的每一个元素称为该软件产品软件配置中的一个配置项（configurationitem）。

3.3产品基线productbaseline

指在软件组装与系统测试阶段结束时,经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。

产品基线是最初批准的产品配置标识。

3.4配置控制

配置管理的一个要素,由评估、协调、批准或不批准,和对正式创立配置标识的配置项实施变更等活动组成。

3.5软件配置管理库softwarecontrolledlibrary

软件配置管理库又称软件受控库,是指在软件生存周期的某一个阶段结束时,存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息和人工可读信息的库。

软件配置管理就是对软件受控库中的各软件项进行管理。

4配置管理规范

本规范给出了软件开发项目配置项及其命名规则、配置管理活动中角色和权限的定义,便于所涉及人员在使用CVS、SVN工具和执行配置管理流程时更方便快捷的进行操作,以提高开发工作效率。

4.1配置项及其命名规则

4.1.1配置项

软件开发项目的配置项需要包括以下的内容:

1、项目管理过程文档,例如:

a）项目任务书;

b）项目计划;

c）项目周报;

d）个人日报和周报;

e）项目会议纪要;

f）培训记录和培训文档;

g）评审记录;

h）项目总结报告等等

2、项目技术文档,例如 

a）需求文档;

b）设计文档;

c）代码说明;

d）测试文档;

e）软件安装使用手册等等;

3、源代码和执行程序

4、项目中使用的第三方产品和数据

4.1.2项目编号命名规则

项目编号根据项目名称或项目特征采用英文字母或者英文字母、数字和下划线组合。

以最少的字母达到最容易理解的意义。

例如;

4.1.3配置项命名规则

配置项的命名包括两个方面的内容:

1、配置项标识

在我们的项目中,源代码和执行程序命名规则能够参照编码规范中的相关内容,文档类能够采用全中文或全英文命名两种方式。

●全中文命名使用”项目名_模板名【_标识】”来命名。

”项目名”过长的能够采用中文简称,中文简称尽量以最少的汉字达到最容易理解的意义;

”模板名”使用公司的组织过程资产库中规定的名称;

”【_标识】”是可选项,能够是时间（如:

yyyymmdd）、序号（阿拉伯数字）、版本号（如:

V1.0）、阶段名（如:

编码阶段）、模块名等。

例如:

””简称为””;

””12月4号的QA周报命名为”xxx_QA周报_1204”。

●全英文命名使用”项目编号_模板名【_标识】”来命名。

”xxxx”的项目计划命名为”xxx_PP”;

”xxx”12月4号的QA周报命名为”xxxx_QAWR_1204”。

下表列出了我们在项目中使用的配置类别命名:

配置类别

命名

项目任务书Projecttaskbook

TASK

项目计划ProjectPlan

PP

项目周报Weeklyproject

PWR

工作周报Weeklywork

Report

WWR

项目会议纪要Minutes

Meet_YearMD

培训记录和培训文档

TRD

评审记录Assessmentrecords

配置命名_YearMD

项目中使用的第三方产品

Third-partyproducts

TPP

需求分析说明书

SoftwareRequirementSpecification

RD

概要设计说明书Softwaredesignspecification

TS01

功能列表FeatureList

FeaL

详细设计说明书

Thedetaileddesignspecification

TS03

测试计划TestPlan

TestP

测试用例TestCase

TestCase

测试报告TestReport

TSR

用户手册Usermanuals

SysGuider

配置计划

CMP

QA周报

QAWR

2、配置项版本命名

配置项版本命名是针对配置项的版本进行命名,在我们的项目中,配置项版本经过对Project的Label操作来实现,配置项版本的命名需要能清楚标识配置项的状态。

公司CVS配置管理库逻辑上分开发库、基线库和产品库,所有的配置项都保存在一个库中,对这三个库的划分是经过逻辑划分方式进行的,具体来说,就是经过配置项版本命名来划分的;

SVN配置管理库物理上分开发库、受控库、基线库。

我们配置项的版本命名规定如下:

a）基线版本

基线版本由配置管理员进行标识。

基线发布分正式基线和非正式基线。

正式基线包括需求基线和产品基线;

非正式基线一般包括概要设计基线、详细设计基线、代码/调试基线和测试基线。

基线版本的标识一般使用”项目名称_基线名称_版本号”

基线名称

基线名称

命名

需求基线

REQ_BL

运行基线

RUN_BL

概要设计基线

HLD_BL

产品基线

Proud_BL

详细设计基线

DD_BL

计划基线

Plan_BL

代码基线

CODE_BL

单元测试

UTEST_BL

测试基线

TEST_BL

集成测试基线

QTEST_BL

系统测试基线

SysTest_BL

基线的版本号遵循《配置管理流程》5.3.2配置项版本规范定义的X.YZ模式命名。

其中X为主版本号,Y为次版本号,取值范围均为1-9.配置项第一次”正式发布”时,版本号为1.0。

若配置项的版本升级幅度较小,一般只增大Y值;

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

处于”正在修改”状态的配置项的版本号格式为:

X.YZ,配置项正在修改时,一般只增大Z值,X.Y值保持不变。

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

xxxxx_需求基线_正式发布首版本

基线版本标识为:

xxxx_REQ_BL1.00

b）发布版本

发布版本参照基线版本标识形式,将版本号前的BL改为Release即可。

xxxx_产品基线_正式发布客户首版本

发布版本标识为:

xxxx_PUR_Release1.0

c）其它版本

除基线版本外,有时候还需要在开发和维护过程中确定其它版本。

例如,产品在测试过程中不断的问题修复过程中,可能会有多种重复,此时需要将每次修改的内容作为一个版本。

关于版本,还有另一个需要注意的问题。

一般来说,按照模块来划分,每个模块有自己的版本演进比较合理。

首先,一个模块一般是由一个或两个开发人员完成的;

其次,一个模块的功能会比较单一且独立,在版本的演化过程中便于控制,也不会和其它模块产生过于复杂的关系。

CVS库中产品的版本需要由各个模块的不同版本组成,这个纵横的关系需要很好地管理,我们的做法是在CVS库上用Label来标识,同时维护一个描述产品版本和模块版本关系的readme.txt文件;

SVN库任何一次提交都会对所有文件增加到同一个新版本号,即使是提交并不涉及的文件。

因此,各文件在某任意时间的版本号是相同的。

需要说明的是开发库中的版本配置工具会根据操作人员对文件的修改与提交自动化的给出版本标识,比如:

CVS初始版本号为1.1,修改提交一次自动递升一个子版本号为1.2,依次类推。

CVS同时也支持操作人员自定义版本号,这个不属于受控库管理之列不做统一要求,开发组可根据项目实际情况进行组内约定。

4.2角色和权限定义

角色是配置管理流程的执行者和参与者,定义明确的角色有利于实现明确的授权和明晰的流程,虽然在实际中可能多个角色由一个人担任,但还是应该保留角色的定义。

下面是该项目中我们的角色定义。

4.2.1 

配置管理员

整个配置管理库由配置管理员管理。

配置管理员负责分配和修改其它成员的权限,要维护所有目录和配置项。

4.2.2 

项目经理

项目经理在本项目中负责主导完成需求分析和系统总体设计,对项目的总体进度负责。

项目经理拥有对管理类文档的读取权限,能够对项目类文档进行读写操作;

4.2.3 

开发组长

开发组长对本小组的工作负有组织和管理任务,同时开发组长也需要承担一定的开发任务。

开发组长对管理类文档有读取权限,对本组负责的模块有读取权限,对自己负责的模块有读写的权限;

4.2.4 

开发工程师

开发工程师完成具体的开发任务,对自己负责的模块目录有读写权限,对管理类文档有读取权限;

4.2.5 

测试组长

测试组长负责组织测试,给出测试计划和测试方案,并核定测试报告。

测试组长对所有目录都有读取权限,对测试目录有读写权限;

4.2.6 

测试工程师

测试工程师负责完成测试工作,包括测试用例开发和测试执行,测试报告编写。

测试工程师对自己负责的模块有读取权限,对测试用例目录有读写权限。

4.2.7 

QA工程师

QA工程师拥有对所有目录的读取权限,拥有对QA类文档目录的读写权限。

〔说明〕CVS配置库中,除配置管理员外,其它所有成员都没有CVSROOT目录和文件的权限,这是为了防止误删除操作带来不可挽回的损失。

如果需要对目录进行Destroy操作,必须由配置管理员进行。

4.3配置库结构定义

我公司主营业务为外包软件开发,为方便多语言库的移植,配置管理库采用英文标识如下:

项目配置库结构

【项目简称】

（项目）

――trunk（开发主线即开发库）