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

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

23

资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。

密级: 内控

研发本部版本管理规范
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等) , 环境配置文件等。
以上文档作为制作发行盘的素材, 放在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） 对于涉级数据结构的程序变动, 原则上不作为修补的内容, 它只对某些用户有用, 将可能在下一版本中体现, 具体情况要具体处理。
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） 用户进行版本更新时要求填写该文件的版本变更记录, 用以反映用户版本的变更情况。