密级：内控研发本部版本管理规范V1.0浪潮集团山东通用软件有限公司目录文档类别使用对象 (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外出人员对产品的修改 (9)3．4版本升级 (12)3.4.1 版本升级原则 (12)3.4.2 新版本的发布 (12)3.4.3 安装盘制作步骤 (13)4．备份管理 (13)5．用户版本管理 (14)文档类别使用对象文档类别该文档是为浪潮通软公司研发本部各产品部、事业部提供一个版本管理规范性文件。
使用对象该文档使用对象为浪潮通软公司研发本部各部门经理及版本管理人员，以及其他相关人员。
未经管理过程改善部书面许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
1．引言1.1目的本文档是为规范公司研发本部各产品部、事业部版本管理而制定的。
1.2范围本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括：●版本标识方法●软件系统数据的存放●文档的修改控制●文档的备份制度1.3术语定义SCMSoftwere Configuration Management缩写SVMSoftware 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.01.5版序控制记录1.6版本更新记录*A - 增加M - 修改D - 删除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的目录结构举例如下：表示正式版本及特殊版本的目录按以下原则定义：（1）正始版本：以“V”开头，版本号放后，主版本号和次主版本号之间的“.”去掉，明细版本号之前加“-”。
举例如下：版本号目录名V6.0 V60V6.1 V61V6.0.01 V60-1V6.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）在维护期间，确实由于维护需要而必须在用户设备上拷入源程序时，应确保源程序的安全性，并及时予以删除。