研发本部版本管理规范文档格式.docx

研发本部版本管理规范文档格式.docx

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

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-删除

版本/修订版

修改页码

修改记录

修改人

日期

初始版本

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.1

….

Test

Record

测试记录

Case

测试用例

User

用户使用手册

产品说明手册

Plan

Project

项目计划

Month

月度计划

安装盘（H:

Release

REL_SRC

产品盘

或发布文档

SETUP

…..

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

（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