软件配置管理规范

配置管理规范

文件编号：QMS—PROC－SCM03

版本：1.2

受控签章

修改历史

1目的和范围

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

2目标

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

3术语

3.1软件配置管理（Software Configuration Management，SCM）

软件配置管理是标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。一言以蔽之，配置管理是门通过一系列技术、方法和手段来维护产品的历史、鉴别和定位产品独有的版本、在产品开发和发布阶段控制变化，从而使管理制度化、有效减少重复性工作、保证产品的质量和效率的科学。。

3.2 配置项（configuration Item，CI）

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

该集合中的每一个元素称为该软件产品软件配置中的一个配置项(configuration item)。

3.3 产品基线product baseline

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

3.4 配置控制

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

3.5 软件配置管理库software controlled library

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

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）、阶段名（如：编码阶段）、模块名等。

例如：“”简称为“”；

“”2009年12月4号的 QA周报命名为“xxx_QA周报_20091204”。

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

例如：“xxxx”的项目计划命名为“xxx_PP”；

“xxx”2009年12月4号的 QA周报命名为“xxxx _QAWR _20091204”。

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

2、配置项版本命名

配置项版本命名是针对配置项的版本进行命名，在我们的项目中，配置项版本通过对Project的Label操作来实现，配置项版本的命名需要能清楚标识配置项的状态。公司CVS 配置管理库逻辑上分开发库、基线库和产品库，所有的配置项都保存在一个库中，对这三个库的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的；SVN 配置管理库物理上分开发库、受控库、基线库。我们配置项的版本命名规定如下：

a)基线版本

基线版本由配置管理员进行标识。基线发布分正式基线和非正式基线。正式基线包括需求基线和产品基线；非正式基线通常包括概要设计基线、详细设计基线、代码/调试基线和测试基线。基线版本的标识一般使用“项目名称_基线名称_版本号”

基线的版本号遵循《配置管理流程》5.3.2配置项版本规范定义的X.YZ模式命名。其中X为主版本号，Y为次版本号，取值范围均为1-9.配置项第一次“正式发布”时，版本号为1.0。若配置项的版本升级幅度较小，一般只增大Y值；只有当配置项版本升级幅度比较大时，才允许增大X值。处于“正在修改”状态的配置项的版本号格式为:X.Y Z，配置项正在修改时，一般只增大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库任何一次提交都会对所有文件增加到同一个新版本号，即