某软件有限公司文档版本管理规范

密级：内控 研发本部版本管理规范研发本部版本管理规范 V1.0 浪潮集团山东通用软件有限公司浪潮集团山东通用软件有限公司 目录 文档类别使用对象文档类别使用对象 .2 1引言引言 .3 1.1 目的3 1.2 范围3 1.3 术语定义3 1.4 参考资料4 1.5 版序控制记录4 1.6 版本更新记录4 2 2版本管理版本管理 .5 21 版本标识方法5 211正式版本5 212 特殊版本5 22 目录结构5 23 文档的存放7 2.3.1 当前版本和历史版本的存放.7 2.3.2 开发文档的存放.7 2.3.3 源代码的存放.7 2.3.4 SQL 语句的存放7 2.3.5 发行文档的存放8 24 权限控制管理8 3 3更新管理更新管理 .8 31 源程序的修改8 32 已发布版本的维护及修改9 33 外出人员对产品的修改10 34 版本升级12 3.4.1 版本升级原则.12 3.4.2 新版本的发布.12 3.4.3 安装盘制作步骤.13 4 4备份管理备份管理 .13 5用户版本管理用户版本管理 .14 文档类别使用对象文档类别使用对象 文档类别 该文档是为浪潮通软公司研发本部各产品部、事业部提供一个版本管理规范性文件。 使用对象 该文档使用对象为浪潮通软公司研发本部各部门经理及版本管理人员，以及其他相 关人员。未经管理过程改善部书面许可，该文档不得提供给上述规定对象以外的人员 阅读或使用。 1引言引言 1.1 目的 本文档是为规范公司研发本部各产品部、事业部版本管理而制定的。 1.2 范围 本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括： 版本标识方法 软件系统数据的存放 文档的修改控制 文档的备份制度 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版本管理版本管理 21 版本标识方法 为了使工作规范化、统一化，研发本部各部门实行的版本标识管理方法分为：正式 版本和特殊版本。 211 正式版本 公司在市场渠道上发行的正规版本。 以“V”开头，版本号放后。版本号分 3 节：主版本号，次版本号和内部版本号， 每节之间以小数点（.）间隔。如 V2.0.01 表示主版本号为 2，次版本号为 0，内部版本 号为 01。 212 特殊版本 特殊版本是在正式版本的基础上，针对某客户开发的版本。它与正式版本的不同之 处在于问题不具有通用性和适应性，只符合该用户的实际使用情况。 该版本标识分为常规部分和扩展部分，常规部分表示该特殊版本哪一个正式版本的 分支，命名方法同正式版本的命名方法。对于扩展部分，以“S”开头，后加一唯一序 号。举例如下： V2.33.S01 表示由 V2.33 分支出的第一个特殊版本 V2.33.S02 表示由 V2.33 分支出的第二个特殊版本 事业部不鼓励产生特殊版本。只有在极特殊的情况下，才产生适当的特殊版本。并 在以后的版本演化中，尽量将其纳入到正式版本中。 22 目录结构 由于各部门的实际情况不同，目录结构很难统一，但为了能更好地管理各事业部的 文档，建议可将被管理的配置项分为三大类：文档类、源码类及安装盘类，这样存放 比较清晰，有利于版本管理。至于二级目录是以模块划分还是以版本划分，各产品部、 事业部可根据自己部门的情况，制定适合本部门的目录结构，并根据制定的目录结构 给出文件级目录清单（先给出源程序及文档的文件级目录清单，安装盘的可以后再执 行）：。 现以财务产品部 V6。0 的目录结构举例如下： 根目录根目录二级目录二级目录三级目录三级目录四级目录四级目录对应配置项对应配置项备注备注 Current存目录前正在修改 的内容 PBL源码 SQLSQL 文件 DOC详细设计、数 据结构 HTML帮助文件 V6.0 BMP图像文件 V6.0.01 模块缩写 1 按版本号依次类推 模块缩写 2 。 。 。 。 。 。 源码(F:) 模块缩写 n 与模块 1 相同 Require用户需求记录版本号在文件名上 标识 V6.0 V6.0.1Design . 总体设计文档按版本号依次类推 Record测试记录版本号在文件名上 标识 V6.0测试用例 V6.0.01 Test Case . V6.0 V6.0.01 . User 用户使用手册 产品说明手册 Project项目计划 文档(G:) Plan Month月度计划 REL_SRCV6.0Release SETUP V6.0.01 安装盘 (H:) 产品盘或发布文档 表示正式版本及特殊版本的目录按以下原则定义： （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 分支出的中信版本 23 文档的存放 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 目录。 24 权限控制管理 为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的 访问权限。 文档权限类别：只读权限，读写权限。 文档类别：设计文档，源码，发行文档。 用户类别：开发人员、测试人员、分析设计人员、部门经理、配置管理员、安装盘 制作人员、问题及需求管理人员、用户文档编写人员等。 为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的 配置项所在目录分配不同的权限。 为了便于各产品部、事业部的管理，应以表格的形式列出人员与管理对象的访问关 系（用户权限清单） 。 3 3更新管理更新管理 31 源程序的修改 当开发小组在开发同一产品时，应能保障：各成员间的修改不会互相覆盖；程序员 的修改能及时反映到产品的最新版本中。 建议首先在相应子系统的下一级建一目录，如 checkout，存放正在修改的文档及修 改登记表。当某个程序员要修改某一文档时，遵循以下程序： 1、接收维护任务； 2、查看需要修改的文件（如 PBL 及 SQL 等）是否正在被其它人员修改（检 查 checkout 目录下是否存在要修改的文件或后缀已改为该程序员姓名简写） ； 3、如果有人在修改该文件，等待或与相应的开发员联系，重复 2。否则继续； 4、将该文件复制到 checkout 目录下，在修改登记表中登记；或将该文件的 后缀改为本人姓名简写； 5、将该文件考至自己的私有目录； 6、根据要求修改源文件； 7、根据要求测试，并进行相关项的回归测试； 8、交测试人员测试，如未通过，重复 6。如通过则继续； 9、在 checkout 目录中删除该文件，并在修改登记表中标注修改完成； 10、将修改完毕的文件通过电子邮件或其它手段送交版本管理员，版本管理 员将文件复制到相应的路径；如遇特殊情况（版本管理员出差） ，程序员 可将修改完毕的文件复制到相应的路径下，或将后缀改回正式。 11、回复下达者，报告维护任务完成。 驻外开发时，也采用以上程序进行控制。 32 已发布版本的维护及修改 在正式版本发布后，由于软件错误或其它问题（如用户提出增加小功能）需要对程 序进行修改时，应及时作出修补盘（可以软盘或其它的形式） ， 。 （1） 在该发布版本目录下建立一该版本的修补目录，该目录由版本管理员负责。 （2） 各系统如果修改了部分错误或增强了部分功能，应将修改或增加的编译后程 序文件交由版本管理员，由管理员将该程序文件加入到该目录下，并更及时 更新到安装盘中去。 （3） 维护人员在更改产品的程序错误，如增加小的模块，或做小的改进时，应将 程序文件及时通知版本管理员，由版本管理员负责更新源程序。维护人员应 详细记录修改内容。举例如下： 修改 时间 产品代号 或名称以 及版本号 修改原因修改的模块； 受影响的模块 是否修改了表结构， 修改了哪些表结构 对应的修改申 请表单号 修改负 责人 该表存放在相应版本的根目录下。 （4） 修改过的源程序要经过测试人员的测试。事业部如没有专人测试，可由程序 员自己测试。 （5） 对于涉级数据结构的程序变动，原则上不作为修补的内容，它只对某些用户 有用，将可能在下一版本中体现，具体情况要具体处理。 33 外出人员对产品的修改 外出人员对产品的修改，是指以下几种情况： （1） 外出维护时，需要对产品进行修改； （2） 实施工程时，针对客户要求，对产品进行用户个性化修改（在这种情况下， 一般需要衍生出特殊版本） 。 执行程序： （1）维护人员每当接到实施或维护任务时，若需修改源代码，应在启程前认真填 写源程序修改申请表，交部门负责人认定后，维护人员可携带源程序到用户 现场。 （2）在维护期间，确实由于维护需要而必须在用户设备上拷入源程序时，应确保 源程序的安全性，并及时予以删除。 （3）在维护期间若修改了源程序或用户提出了新的问题，维护人员必须认真填写 源程序更新登记表。 （4）回公司后，版本管理员应负责和监督相关人员将所有文档复制到规定目录之 下，并完善相关的所有文档，相关的文档包括：源程序更新登记表、用户程 序更改日志和修改申请表。将更新登记表及所更新的源程序数据交由部门版 本管理人员确认并审定。如果是已发布版本的源程序，必须由版本管理员负 责更新；非对外发布的版本如特殊版本可由程序员自己更新，但版本管理员 应及时进行备份，保证源程序为最新。 （5）修改过的源程序要经过测试人员的测试。事业部如没有专人测试，可由其他 程序员或本人自己测试。 （6）将更新登记表交由部门负责人签字确认。 （7）将更新登记表交由部门版本管理人员存档。 （8）部门配置管理员及时通知相关程序员。 修改申请表样例： 申请时间用户名称版本号问题简单描述申请人签字负责人签字 源程序更新登记表样例： 源程序更新登记表源程序更新登记表 编号: 年 月 日 填表人 单位名称地址 版本情况 编号描述内容(包括:模块问题现象问题原因) 问 题 描 述 编号修改时间修改内容 实 际 修 改 遗留 问题* 编号 是否更新 更 新 更新时间版本管理 员签字 备注:部门经理 签字 注:更新栏由部门版本管理写; 34 版本升级 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.在新建目录