研发本部版本管理规范.docx

研发本部版本管理规范.docx

《研发本部版本管理规范.docx》由会员分享，可在线阅读，更多相关《研发本部版本管理规范.docx（14页珍藏版）》请在冰豆网上搜索。

研发本部版本管理规范

密级：

内控

研发本部版本管理规范

V1.0

1999年11月18日

浪潮集团山东通用软件有限公司

文档类别使用对象

文档类别

该文档是为浪潮通软公司研发本部各产品部、事业部提供一个版本管理规范性文件。

使用对象

该文档使用对象为浪潮通软公司研发本部各部门经理及版本管理人员，以及其他相关人员。

未经管理过程改善部书面许可，该文档不得提供给上述规定对象以外的人员阅读或使用。

1．引言

1.1目的

本文档是为规范公司研发本部各产品部、事业部版本管理而制定的。

1.2范围

本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括：

●版本标识方法

●软件系统数据的存放

●文档的修改控制

●文档的备份制度

1.3术语定义

SCM

SoftwereConfigurationManagement缩写

SVM

SoftwareVersionManagement缩写

文档

一种数据媒体和其上所记录的数据。

配置管理

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

软件配置

软件的具体形态在某时刻的瞬时影像。

配置项

软件配置管理的对象称为配置项，如：

系统规格说明书，项目开发计划，用户手册，源码。

基线

软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。

1.4参考资料

[1]《事业部门版本管理工作标准》SEPGV1.0

[2]《国强财务V60配置管理》财务产品部V1.0

[3]《商业事业部版本管理规范》V1.0

[4]《酒店事业部版本管理规范》V1.0

[5]《财务产品部版本管理规范》V1.0

[6]《PACS事业部版本管理规范》V1.0

[7]《MRPII部版本管理规范》V1.0

[8]《金融事业部版本管理规范》V1.0

[9]《ERP部版本管理规范》V1.0

1.5版序控制记录

版序状态

拟稿

审核

批准

发布日期

1.0

管理过程改善部

任甲林

99/11/18

1.6版本更新记录

*A-增加M-修改D-删除

版本/修订版

修改页码

修改记录

修改人

日期

1.0

初始版本

99/11

2．版本管理

2．1版本标识方法

为了使工作规范化、统一化，研发本部各部门实行的版本标识管理方法分为：

正式版本和特殊版本。

2．1．1正式版本

公司在市场渠道上发行的正规版本。

以“V”开头，版本号放后。

版本号分3节：

主版本号，次版本号和内部版本号，每节之间以小数点（.）间隔。

如V2.0.01表示主版本号为2，次版本号为0，内部版本号为01。

2．1．2特殊版本

特殊版本是在正式版本的基础上，针对某客户开发的版本。

它与正式版本的不同之处在于问题不具有通用性和适应性，只符合该用户的实际使用情况。

该版本标识分为常规部分和扩展部分，常规部分表示该特殊版本哪一个正式版本的分支，命名方法同正式版本的命名方法。

对于扩展部分，以“S”开头，后加一唯一序号。

举例如下：

V2.33.S01表示由V2.33分支出的第一个特殊版本

V2.33.S02表示由V2.33分支出的第二个特殊版本

事业部不鼓励产生特殊版本。

只有在极特殊的情况下，才产生适当的特殊版本。

并在以后的版本演化中，尽量将其纳入到正式版本中。

2．2目录结构

由于各部门的实际情况不同，目录结构很难统一，但为了能更好地管理各事业部的文档，建议可将被管理的配置项分为三大类：

文档类、源码类及安装盘类，这样存放比较清晰，有利于版本管理。

至于二级目录是以模块划分还是以版本划分，各产品部、事业部可根据自己部门的情况，制定适合本部门的目录结构，并根据制定的目录结构给出文件级目录清单（先给出源程序及文档的文件级目录清单，安装盘的可以后再执行）：

。

现以财务产品部V6。

0的目录结构举例如下：

根目录

二级目录

三级目录

四级目录

对应配置项

备注

源码（F:

）

模块缩写1

Current

存目录前正在修改的内容

V6.0

PBL

源码

SQL

SQL文件

DOC

详细设计、数据结构

HTML

帮助文件

BMP

图像文件

V6.0.01

按版本号依次类推

…

模块缩写2

与模块1相同

。

。

。

。

。

。

模块缩写n

文档（G:

）

Require

用户需求记录

版本号在文件名上标识

Design

V6.0

总体设计文档

按版本号依次类推

V6.0.1

….

Test

Record

测试记录

版本号在文件名上标识

Case

V6.0

测试用例

V6.0.01

….

User

V6.0

用户使用手册

产品说明手册

V6.0.01

….

Plan

Project

项目计划

Month

月度计划

安装盘（H:

）

V6.0

Release

REL_SRC

产品盘

或发布文档

SETUP

V6.0.01

…..

表示正式版本及特殊版本的目录按以下原则定义：

（1）正始版本：

以“V”开头，版本号放后，主版本号和次主版本号之间的“.”去掉，明细版本号之前加“-”。

举例如下：

版本号目录名

V6.0V60

V6.1V61

V6.0.01V60-1

V6.1.02V61-2

（2）特殊版本：

目录名分为常规名和扩展名两部分，常规部分表示该特殊版本是由哪一个正始版本分支而来，命名方法同正始版本的命名方法。

对于扩展名，以“S”开头，后加一唯一序号。

举例如下：

目录名意义

V60.S01表示由V6.0分支出的第一个特殊版本

V60.S02表示由V6.0分支出的第二个特殊版本

V60-1.S01表示由V6.0.01分支出的第一个特殊版本

（3）对于有些事业部是针对某个具体用户开发的特殊版本，在表示特殊版本的目录时，常规部分表示该特殊版本是哪一个正始版本的分支，对于扩展部分，可以把项目名称作为扩展名。

举例如下：

V60.中信表示由V6.0分支出的中信版本

2．3文档的存放

2.3.1当前版本和历史版本的存放

对于源码文件，特别增加了一个Current目录，存放当前正在开发与维护的源码文件，当前未发布版本的所有数据都存放在.....\CURRENT\下。

一旦当前版本正式发行，则当前目录被修改为相应的历史目录。

历史版本是指已经发行的版本，存放在相应的版本目录之下，一般不允许改动。

2.3.2开发文档的存放

根据各部门自己的情况，将系统用户需求记录、总体设计文档、详细设计及数据结构文件、测试记录、用户手册等放入相应的目录下，也可将不同模块的开发文档存放于不同的模块中。

2.3.3源代码的存放

源代码包括如：

PBL，PBR，BMP，ICO，CPP，HPP，MAK，PRJ，INI等相关文件，是未经编译处理的、不能直接交付使用的产品文件以及编译产品所需的文件；联机帮助文件HLP在未生成HLP文件之前的DOC，RTF等格式的文档也视为源代码。

各子系统当前的程序源文件放入相应的目录下。

对于一个子系统又分多个分子系统的情况，应在该目录下分别建立几个相应的目录。

2.3.4SQL语句的存放

各子系统SQL文件放入…..\.......\SQL下，对于不同的数据库，分别建立不同的子目录，如WAT、SYB、MSS、ORC、DB2等。

公共SQL文件直接放入…\SQL下即可，不同数据库的特殊SQL分别放入对应的子目录下。

2.3.5发行文档的存放

发行文档是指产品交付用户使用所必须的文件。

包括：

产品可执行文件，用户使用说明书，联机帮助（HLP）；资源文件（BMP，ICO等），环境配置文件等。

以上文档作为制作发行盘的素材，放在RELEASE的REL_SRC目录之下，制作好的发行盘放在RELEASE的SETUP目录。

2．4权限控制管理

为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的访问权限。

文档权限类别：

只读权限，读写权限。

文档类别：

设计文档，源码，发行文档。

用户类别：

开发人员、测试人员、分析设计人员、部门经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。

为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。

为了便于各产品部、事业部的管理，应以表格的形式列出人员与管理对象的访问关系（用户权限清单）。

3．更新管理

3．1源程序的修改

当开发小组在开发同一产品时，应能保障：

各成员间的修改不会互相覆盖；程序员的修改能及时反映到产品的最新版本中。

建议首先在相应子系统的下一级建一目录，如checkout，存放正在修改的文档及修改登记表。

当某个程序员要修改某一文档时，遵循以下程序：

1、接收维护任务；

2、查看需要修改的文件（如PBL及SQL等）是否正在被其它人员修改（检查checkout目录下是否存在要修改的文件或后缀已改为该程序员姓名简写）；

3、如果有人在修改该文件，等待或与相应的开发员联系，重复2。

否则继续；

4、将该文件复制到checkout目录下，在修改登记表中登记；或将该文件的后缀改为本人姓名简写；

5、将该文件考至自己的私有目录；

6、根据要求修改源文件；

7、根据要求测试，并进行相关项的回归测试；

8、交测试人员测试，如未通过，重复6。

如通过则继续；

9、在checkout目录中删除该文件，并在修改登记表中标注修改完成；

10、将修改完毕的文件通过电子邮件或其它手段送交版本管理员，版本管理员将文件复制到相应的路径；如遇特殊情况（版本管理员出差），程序员可将修改完毕的文件复制到相应的路径下，或将后缀改回正式。

11、回复下达者，报告维护任务完成。

驻外开发时，也采用以上程序进行控制。

3．2已发布版本的维护及修改

在正式版本发布后，由于软件错误或其它问题（如用户提出增加小功能）需要对程序进行修改时，应及时作出修补盘（可以软盘或其它的形式），。

（1）在该发布版本目录下建立一该版本的修补目录，该目录由版本管理员负责。

（2）各系统如果修改了部分错误或增强了部分功能，应将修改或增加的编译后程序文件交由版本管理员，由管理员将该程序文件加入到该目录下，并更及时更新到安装盘中去。

（3）维护人员在更改产品的程序错误，如增加小的模块，或做小的改进时，应将程序文件及时通知版本管理员，由版本管理员负责更新源程序。

维护人员应详细记录修改内容。

举例如下：

修改时间

产品代号或名称以及版本号

修改原因

修改的模块；受影响的模块

是否修改了表结构，修改了哪些表结构

对应的修改申请表单号

修改负责人

该表存放在相应版本的根目录下。

（4）修改过的源程序要经过测试人员的测试。

事业部如没有专人测试，可由程序员自己测试。

（5