浪潮集团山东通用软件有限公司研发本部版本管理规范样本.doc

密级：内控

研发本部版本管理规范
V1.0

1999年11月18日
浪潮集团山东通用软件有限公司

目录
文档类别使用对象 2
1．引言 3
1.1目 3
1.2范畴 3
1.3术语定义 3
1.4参照资料 4
1.5版序控制记录 4
1.6版本更新记录 4
2．版本管理 5
2．1版本标记办法 5
2．1．1正式版本 5
2．1．2特殊版本 5
2．2目录构造 5
2．3文档存储 7
2.3.1 当前版本和历史版本存储 7
2.3.2 开发文档存储 7
2.3.3 源代码存储 7
2.3.4 SQL语句存储 7
2.3.5发行文档存储 8
2．4权限控制管理 8
3．更新管理 8
3．1源程序修改 8
3．2已发布版本维护及修改 9
3．3外出人员对产品修改 10
3．4版本升级 12
3.4.1 版本升级原则 12
3.4.2 新版本发布 12
3.4.3 安装盘制作环节 13
4．备份管理 13
5．顾客版本管理 14

文档类别使用对象
文档类别

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

使用对象

该文档使用对象为浪潮通软公司研发本部各部门经理及版本管理人员，以及其她有关人员。未经管理过程改进部书面允许，该文档不得提供应上述规定对象以外人员阅读或使用。

1．引言
1.1目
本文档是为规范公司研发本部各产品部、事业部版本管理而制定。
1.2范畴
本文档为各产品部、事业部版本管理员提供关于版本管理规范有关内容，涉及：
l 版本标记办法
l 软件系统数据存储
l 文档修改控制
l 文档备份制度
1. 3术语定义
SCM
Softwere Configuration Management缩写

SVM
Software Version Management缩写

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

配备管理
标记和拟定系统中配备项过程，在系统整个生存周期内控制这些项投放和更动，记录并报告配备状态和更动规定，验证配备项完整性和对的性。

软件配备
软件详细形态在某时刻瞬时影像。

配备项
软件配备管理对象称为配备项，如：系统规格阐明书，项目开发筹划，顾客手册，源码。

基线
软件生存周期中各开发阶段末尾标记，它作用是把各阶段工作划分更加明确化，使本来持续工作在这些点上断开，使之便于检查和必定阶段成果。
1.4参照资料
[1] 《事业部门版本管理工作原则》 SEPG V1.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.0 V60
V6.1 V61
V6.0.01 V60-1
V6.1.02 V61-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.4 SQL语句存储
各子系统SQL文献放入…..\.......\SQL下，对于不同数据库，分别建立不同子目录，如WAT、SYB、MSS、ORC、DB2等。公共SQL文献直接放入…\SQL下即可，不同数据库特殊SQL分别放入相应子目录下。

2.3.5发行文档存储
发行文档是指产品交付顾客使用所必要文献。涉及：产品可执行文献，顾客使用阐明书，联机协助（HLP）；资源文献（BMP，ICO等），环境配备文献等。
以上文档作为制作发行盘素材，放在RELEASEREL_SRC目录之下，制作好发行盘放在RELEASESETUP目录。
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） 对于涉级数据构造程序变动，原则上不作为修补内容，它只对某些顾客有用，将也许在下一版本中体现，详细状况要详细解决。
3．3外出人员对产品修改
外出人员对产品修改，是指如下几种状况：
（1） 外出维护时，需要对产品进行修改；
（2） 实行工程时，针对客户规定，对产品进行顾客个性化修改（在这种状况下，普通需要衍生出特殊版本）。
执行程序：
（1） 维护人员每当接到实行或维护任务时，若需修改源代码，应在启程前认真填写源程序修改申请表，交部门负责人认定后，维护人员可携带源程序到顾客现场。
（2） 在维护期间，的确由于维护需要而必要在顾客设备上拷入源程序时，应保证源程序安全性，并及时予以删除。
（3） 在维护期间若修改了源程序或顾客提出了新问题，维护人员必要认真填写源程序更新登记表。
（4） 回公司后，版本管理员应负责和监督有关人员将所有文档复制到规定目录之下，并完善有关所有文档，有关文档涉及：源程序更新登记表、顾客程序更改日记和修改申请表。将更新登记表及所更新源程序数据交由部门版本管理人员确认并审定。如果是已发布版本源程序，必要由版本管理员负责更新；非对外发布版本如特殊版本可由程序员自己更新，但版本管理员应及时进行备份，保证源程序为最新。
（5）修改过源程序要通过测试人员测试。事业部如没有专人测试，可由其她程序员或本人自己测试。
（6）将更新登记表交由部门负责人签字确认。
（7）将更新登记表交由部门版本管理人员存档。
（8）部门配备管理员及时告知有关程序员。

修改申请表样例：

申请时间
顾客名称
版本号
问题简朴描述
申请人签字
负责人签字

源程序更新登记表样例：
源程序更新登记表
编号： 年 月 日 填表人
单位名称

地址

版本状况

问题
描述
编号
描述内容(涉及:模块\问题现象\问题因素)

实

际

修

改

编号
修改时间
修改内容

遗留
问题*

更新
编号

与否更新

更新时间

版本管理员签字

备注:

部门经理签字

注:更新栏由部门版本管理写;
3．4版本升级
3.4.1 版本升级原则
版本升级应严格纳入版本管理控制之下。应当谨慎地控制版本升级，保障高版本向下兼容性，或提供严格定义升级办法。
在下面几种状况下，进行版本演化和升级：
1、当产品发生重大修改和改进时，主版本号加1。重大修改和改进涉及：
1） 平台迁移；
2） 开发工具迁移；
3） 体系构造变迁。
2、当产品发生较小改进或修改时，次版本号可以加1。
3、对于改动量比较少，如修改产品错误，可增长内部版本号。内部版本号对顾客来说是不可见，只对事业部内部版本控制有用。
4、记录版本升级过程。每次版本升级，都要填写版本升级登记表，登记表样例如下：

版本升级登记表

版本号
发布日期
修改文献
问题简要描述
发布负责人
批准人
备注

阐明：
版本号： 记录当前发布版本。
发布日期：该版本批准发布日期。
修改文献：版本修改记录文献，普通为版本修改日记。
3.4.2 新版本发布
新版本发布涉及主版本号和次版本号升级，普通不涉及内部版本号升级。流程如下：
1、 接受新版本发布任务，接受本次发布版本代号。
2、 在指定目录中，依照本次发布版本号建立相应子目录，将current下所有内容拷贝至新建目录下。
3、 可在新建目录下建立readme.txt，并加入相应内容。
4、 下达安装盘制作指令。
readme.txt文献是记录该版本与上一版本不同，作过哪些改动。格式样例如下：

增长或修改功能
涉及源文献
改动因素

3.4.3 安装盘制作环节
1. 接受安装盘制作指令。
2. 编译源程序。
3. 制作升级SQL。
4. 测试升级程序。
5. 依照版本号在安装盘目录下建立新版安装盘目录。
6. 在新建目录下制作安装盘。
7. 交测试员测试安装盘，如安装盘存在问题重复7，否则继续。
8. 提交安装盘。
4．备份管理
为了保证文档最大可恢复性，要随时及定期地进行备份工作。
1、 随时备份：
（1） 开发人员每天都要将自已当天修改源文献在本地机器上进行备份。
（2） 开发负责人每天要将所有源文献在本地机备份。
（3） 建议备份采用循环备份。
2、 定期备份
（1） 备份形式为硬盘备份和光盘备份。硬盘备份时，要备份在独立硬盘上；光盘备份时，要将光盘存储在可靠地方。
（2） 备份周期视各产品部、事业部详细状况而定。如果处在开发阶段，每周应对所有源程序项进行备份，普通为每周周五；如果处在其他阶段，依照详细状况而定，但周期不能超过两周。
（3） 备份要由版本管理员负责，备份原则应是保证文档最大可恢复性。
（4） 对于历史版本或某顾客特殊版本，如果无特殊因素不再进行修改话，建议用光盘进行备份，并且应有备份盘阐明文献BACKUP.TXT。该文献应当记录如下内容：本次备份时间，备份内容，执行人。
5．顾客版本管理
当前各事业部诸多是以做项目为主，是依照客户规定开发程序。为了更好地管理源程序，应为每一顾客建立一种顾客版本文献，该文献应包括如下内容：
顾客编号：
顾客名称：
软件版本号：
开始使用时间：
联系人：
联系电话：

顾客程序更改日记样例如下：

更改时间
版本号
修改模块名称
变更因素
变更概述
软件位置
变更人员
备注

阐明：
1） 顾客购买软件时要为该顾客建立一种包括上述内容一种顾客版本文献，并填写关于数据。
2） 顾客进行版本更新时规定填写该文献版本变更记录，用以反映顾客版本变更状况。