广东亿迅科技有限公司
软件版本管理办法（暂行）
第一章总则
第一条为了加强广东亿迅科技有限公司（以下简称“公司”）的软件版本管理工作，进一步细化公司配置管理规范，建立软件版本管理的规范化操作流程，保证公司软件产品质量，制定本办法。
第二条本办法适用于公司各技术部门的软件版本管理工作。
第三条本办法所称的软件版本是指公司所有面向用户发布的应用软件版本。
第四条软件版本（以下简称“版本”）管理应遵循以下原则：
(一)实施版本变更应符合以下原则之一：
1.为满足客户新业务、新功能需求；
2.为满足提高业务质量、提升业务性能指标和容量扩充的需求；
3.为解决软件故障和软件稳定性、安全性、可控性问题；
4.为了提高软件可维护性。
(二)版本的集成和发布应严格按照计划执行，避免随意和频繁更新版本;
(三)为保证软件质量，任何一个软件版本须通过版本测试后方可上线；
(四)公司所有软件版本必须通过正式渠道发布给用户，未经审批各部门和个人不得擅自向用户发布软件版本。
第五条版本管理是保障应用软件正常运行的一个重要手段，各相关部门应认真贯彻落实，并纳入工作考核；未按本办法执行从而造成版本故障影响用户正常生产的，一经发现将追究其相应责任。
第二章职责与分工
第六条版本管理实行总体质量控制，分级实施管理原则，管理工作涉及版本质量管控部门和版本集成发布部门；质量管理部是版本质量管控部门，各业务部门是版本集成发布部门。
第七条版本质量管控部门的工作职责如下：
(一)负责制定与版本管理工作相关的管理办法和工作流程并组织落实；
(二)负责组织版本管理相关的培训并提供技术支持；
(三)负责跟踪和监督公司版本管理工作的执行情况，协调解决执行中的问题，并对版本管理的执行效果进行评估考核；
(四)负责组织和实施对版本的测试验证工作；
(五)负责对版本升级实施效果和版本质量进行监控和评估；
(六)其它应由版本质量管控部门负责的事项。
第八条版本集成发布部门的工作职责如下：
(一)负责本部门版本研发集成工作环境的建立、维护和管理；
(二)负责依据版本管理工作流程，执行版本开发、集成、发布
及维护的相关工作；
(三)负责收集分析业务需求，制定版本计划并按计划组织实施；
(四)负责跟踪版本上线后的运行情况，收集用户使用的反馈信息，改进版本质量；
(五)其它应由版本集成发布部门负责的事项。
第九条版本质量管控部门设置专职版本管理工程师和测试工程师岗位，负责版本的质量管控及流程监督；版本集成发布部门应在各项目组内设置专职或兼职版本管理员，负责本项目版本集成发布的具体工作。
第三章版本管理
第十条版本管理的各项工作应按照本办法规定的流程和要求执行。版本集成发布部门可以根据本办法的要求结合项目实际情况，对工作流程进行进一步细化。
第十一条依据版本发布原因及执行流程的不同，软件版本可分为例行版本和紧急放行版本：
(一)例行版本是指依照版本计划生成的升级版本，例行版本按固定周期发布，执行例行版本发布流程；
(二)紧急放行版本是指版本计划外生成，由客户紧急需求或影响生产的紧急故障所引发的需及时发布的软件版本，执行紧急版本发布流程。
第十二条版本管理的主要工作内容主要包括四个环节：版本计
划、版本测试、版本发布、版本跟踪。
第一节版本计划
第十三条版本计划是例行版本开发、测试、集成以及发布的依据，与例行版本是一一对应的关系，版本集成发布部门各项目组按固定周期收集固化的用户需求并据此制定版本计划。制定版本计划的要求：
(一)版本计划需包含版本对应的用户需求的内容、任务优先级、研发提交测试的时间、测试完成时间、版本发布时间、受影响的关联系统或模块、版本升级应急措施及注意事项等；
(二)拟定版本计划各关键时间点应预留足够的时间供版本开发和测试，特别是计划中的版本提交测试时间和测试完成时间，在制定时应与版本质量管控部门测试组做好充分沟通，确定双方认可的工作计划，以保证版本质量；
(三)将每个需求作为版本计划的一个任务，并根据任务的用户感知度、重要性、紧急程度等排定任务优先级。
第十四条版本计划经项目负责人审批确立后，依计划组织相关部门实施，各部门根据任务的紧急程度和优先级落实工作。
第十五条原则上版本计划一经确立不得随意修改，确因实际情况需要时版本集成发布部门可以对版本计划进行适当调整，但计划调整同时应及时向版本质量管控部门进行反馈、沟通。
第二节版本测试
第十六条版本质量管控部门和版本集成发布部门根据版本计划
组织实施版本测试验证工作。
第十七条版本集成发布部门在开发库中开发程序并将通过单元测试的版本和单元测试用例提交到集成库，版本管理员在版本提交测试时限前从集成库中提取程序版本并对获取的版本封版，将版本集成到公司测试环境后通知版本质量管控部门进行版本测试验证。
版本封版是指关闭版本需求入口、固化指定程序版本的活动，版本封版的要求如下：
(一)版本管理员根据版本计划拟定的时间和范围，从集成库中获取版本并对该获取的版本进行封版；
(二)应保证测试环境版本与封版版本的一致性；
(三)版本封版后原则上版本不应再有大的变更，封版测试阶段的缺陷修改应在封版的版本基础上修改，防止出现版本计划中未列明的新需求，以确保版本的稳定性。
第十八条版本质量管控部门制定测试方案并进行版本测试，版本测试包括业务功能集成测试、性能测试，以及对相关技术文档的完整性、规范性、准确性的审核等。若测试发现版本有重大缺陷或隐患，应通知版本集成发布部门共同确认是否中断当前的版本流程，并明确下一步动作。制定测试方案的要求如下：
(一)测试方案主要包括测试内容、测试方法、测试优先级等内容；
(二)版本计划确立后即制定测试方案，当计划有变更时应相应变更测试方案；
(三)应以任务优先级为参考依据安排测试优先级，当测试时间不足以完成所有测试任务时，对于优先级别高的任务应重点测试，对于优先级别较低的任务只做简单测试或只审核单元测试用例，并在测试方案中对此加以说明；
(四)涉及UI设计需求的版本，应按照公司《UI界面交付使用管理办法》中相关标准制定界面测试方案并进行测试，保证软件版本UI界面的设计及易用性与客户需求一致；
(五)测试方案需经过版本集成发布部门审核，重点审核方案中的测试方法、测试优先级。
第十九条对于紧急放行版本，在测试时间不充足的情况下，版本质量管控部门应优先执行版本中重点、难点及对用户影响大的相关功能模块测试任务。紧急放行版本中所涉及的功能需求变更应纳入下一个例行版本中进行整体版本回归测试。
第二十条版本质量管控部门应按版本计划拟定的测试完成时间提交版本测试报告，版本如涉及UI界面设计，测试报告应同时汇总UI界面设计审核部门意见。对于测试不通过（包括尚未完成测试）的版本，版本质量管控部门应在测试报告中说明情况，给出风险评估，并继续完成该版本测试。版本集成发布部门以测试报告为参考依据做出判断，确定版本具体发布时间。
第三节版本发布
第二十一条版本发布的关键内容包括：生成版本包、申请发布版本、用户测试上线。
第二十二条版本管理员在版本测试完成后汇总版本发布说明（升级指引）、程序文件（源代码或可执行文件）、数据库脚本、测试用例、用户手册等文件，将这些文件按照版本号命名规则打包生成正式版本包。其中版本发布说明（升级指引）应包含版本号、发布范围、变更内容、版本升级方案（含版本升级应急方案）、注意事项等，确保能对用户升级起到切实的指引作用。
第二十三条版本发布前版本管理员需提交版本发布申请，版本发布申请需包含版本号、版本类别、发布范围、申请原因、程序和文件清单、相关注意事项等内容。具体流程如下：
例行版本的发布申请经该项目负责人审核后提交部门经理审批；紧急放行版本的发布申请经该项目负责人和部门经理审核通过后，提交协助分管领导审批。公司所有版本的发布都必须经过用户同意后方可正式发布。
第二十四条版本集成发布部门将版本发布给用户后，及时跟踪用户对版本进行的验收测试和生产环境版本上线工作，应用户要求版本集成发布部门可以在版本上线时提供直接协助，上线前应先进行用户生产系统的版本备份，做好安全措施。
第二十五条用户版本上线后若发生重大问题影响生产，版本集成发布部门应该立即组织用户根据预设的版本升级应急方案进行版本回退，并执行新的版本发布流程。
第二十六条版本发布涉及关联系统或模块时，发布前需知会相关系统或模块的负责人。
第四节版本跟踪
第二十七条版本集成发布部门应对已发布版本进行跟踪，版本管理员在版本发布后2周内收集用户使用反馈信息并生成版本跟踪报告，根据以下情况有区别地向版本质量管控部门提交报告材料：
(一)出现回退版本应在报告中分析定位问题原因；
(二)对于运行有异常的版本应涵盖版本质量改进等相关内容；
(三)对于运行正常的版本须提交版本包。
第二十八条版本质量管控部门根据版本跟踪报告进行综合评估，形成版本质量报告，将报告提交各相关部门作为工作考核的依据，对版本集成发布部门提交的版本包入产品库进行版本基线管理。
第二十九条对于上线后产生了重大故障或生产事故的版本，版本质量管控部门应收集版本信息，分析版本产生问题的原因并确定责任人，并按《公司项目重大事故上报及处理办法》的要求，及时上报问题情况。
第四章附则
第三十条本办法自发文之日执行。此前公司如有与本办法不一致的，以本办法为准。
第三十一条本办法由质量管理部负责制定、修改和解释。
广东亿迅科技有限公司
二〇一〇年八月三十日
附件一：版本发布流程附件二：版本计划
附件三：版本发布申请附件四：版本发布说明
附件一：
广东亿迅科技有限公司
版本发布流程（1）例行版本发布流程
（2）紧急版本发布流程
附件二：
广东亿迅科技有限公司
版本计划
14
任务类别：需求A /故障B /工程C /优化D
项目负责人审批：
15
附件三：
广东亿迅科技有限公司
版本发布申请
NO.YYYYMMD D.XX
备注：
1、序列编号：
语法：NO.YYYYMMDD.XX
解释：YYYYMMDD与版本号日期一致；XX为补丁号，没有可不写
举例：NO.20090408，或者NO.20090408.01
2、例行版本的发布申请需要经过项目负责人、部门经理审批、用户意见；紧急放行版本
的发布申请需要经过项目负责人、部门经理、协助分管领导审批、用户意见。
附件四：
广东亿迅科技有限公司
版本发布说明
一、版本描述
【说明版本名称如版本号，版本存放位置、发布时间等】
1、版本号：
2、版本存放位置：
3、发布时间要求：
二、版本适用范围
【说明版本适用范围，如全省，某个地市局等，以及其它；根据需要可分模块说明】
三、版本接口人
【版本接口人以及接口人邮箱、电话】
四、关联系统
【没有请写“无”】
五、运行环境要求
【说明运行本版本所需新增软硬件配置要求，没有请写“无”】
1、硬件配置
XXXXXX有限公司 文件制订（修订、作废）申请单NO.: 表格编码：
1. 目的 为规范公司软件、程序的管理，确保开发、使用、变更等过程得以受控，根据本公司实际情况，特制定本规范。 2. 适用范围 本规范适用于公司所有自主开发、外购、客供软件、程序的管理。（如无特别说明,本规范内“软件”包含软件、程序） 3. 软件分类: 3.1产品源程序: 由研发部软件开发工程师编写，实现产品功能的烧录文件。 3.2 ATE测试软件及测试程序： 是指由信息技术部负责编写的配套ATE硬件使用的产品测试软件平台,及在此平台下针对不同型号产品编写的测试程序。 3.3 设备应用程序: 是指工程部在设备操作系统下针对不同产品型号编写的对应程序（ATE除外）。如：打码程序、贴片程序、SPI检测程序、AOI检测程序、分板程序、回流焊程序、X-Ray 测试程序等。 3.4管理应用软件: 是指企业使用的电子化管理工具或系统平台。如:ERP系统、品质管理系统、SPC系统、生产报表系统、电子看板系统、绩效管理系统、项目管理系统等 3.5办公软件：Windows、office、Coremail、PDM、AutoCAD、杀毒软件等。 4、职责定义: 原则上公司各部门均可依据自身需求提出软件申请，由技术部门进行开发，交由使用部门进行管理，异常无法解决时,可向技术部门寻求技术支援。具体定义如下： 4.1 需求提出部门:依据公司或者部门的实际情况,提出软件需求申请。软件需求多由软
件使用部门提出，但也可以由其它部门提出。 4.2使用/管理部门:对提出的申请进行评估,确定需求后向开发部门发起正式申请;在软件验收合格后负责日常的管理、维护等；当异常时且无法解决时，及时向开发部门反馈,并要求协助处理。 4.3开发部门:对于使用/管理部门提出的申请进行评估,确定执行方案,并最终完成软件开发；开发部门也负责后期的技术支援。 4.4监控部门:负责对软件验收完成后的使用过程进行监控，确保不出现使用错误,维规操作,使用非法软件及机密软件外流等。 4.4软件管理职责对照见下表： 分类开发部门使用/管理部门监控部门 产品源程序研发部工程部品质部 ATE测试软件及测试程序信息技术部工程部品质部 设备应用程序工程部工程部品质部 管理应用软件信息技术部使用部门信息技术部 办公软件信息技术部使用部门信息技术部 5.软件管理规范： 5.1软件申请、开发、使用管理流程图：（如下图）
软件版本管理制度.1 软件版本管理规范 系统软件开发部 2011-9-20 目录 1引言(3) 1.1目的(3) 1.2范围(3) 1.3术语定义(3) 1.4版序控制记录(4) 1.5版本更新记录(4) 2版本管理(4) 2.1流程图(4) 2.2版本命名(9) 2.3版本升级(10) 2.3.1版本升级原则(10) 2.3.2新版本的发布(11)
2.4目录结构(11) 2.5文档的存放(12) 2.5.1文本文件的存放(12) 2.5.2源代码的存放(12) 2.5.3发行文档的存放(12) 2.6权限控制管理(12) 3备份管理(13) 3.1源文件备份(13) 3.2库文件备份(13) 4用户版本管理(13) 5版本工具的使用(14) 5.1配置管理工具(14) 5.2CVS的使用(14) 5.2.1常用命令(14) 5.2.2简单操作(17) 5.2.3版本分支管理(17) 1引言
本文档是为规范XXXXXX有限公司软件版本管理而制定的。 1.2 范围 本文档为系统软件开发部版本管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3 术语定义 CVS CVS是一个开源的版本控制系统Concurrent Versions System的简称 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。
软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。 基线 软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。 1.4 版序控制记录 1.5 版本更新记录 2版本管理2.1 流程图 2.1.1文档归档流程 2.1.2文档变更流程
软件版本管理规范 系统软件开发部 2011-9-20 目录 1引言............................................................. 目的.......................................................... 范围.......................................................... 术语定义...................................................... 版序控制记录.................................................. 版本更新记录.................................................. 2版本管理......................................................... 流程图........................................................ 版本命名...................................................... 版本升级...................................................... 版本升级原则............................................... 新版本的发布............................................... 目录结构...................................................... 文档的存放.................................................... 文本文件的存放............................................. 源代码的存放............................................... 发行文档的存放................................ 错误!未定义书签。
上海精佑通信技术有限公司企业标准 （管理标准） Q/HT 0001–2005 软件版本管理规定 V1.04 2005-04-11 发布 2005-04-11实施
上海精佑通信技术有限公司 目录 1范围 (4) 2术语和定义 (4) 2.1软件 (4) 2.2产品软件 (4) 2.3生产支持软件 (4) 3软件版本命名规则 (5) 3.1软件版本命名组成 (5) 3.2手机软件版本命名 (5) 3.3模块软件版本命名 (5) 3.4手机PC侧软件版本命名 (6) 3.5模块PC侧软件版本命名 (7) 3.6手机生产支持软件版本命名 (7) 3.7模块生产支持软件版本命名 (8) 3.8公用于所有手机和模块的软件版本命名 (9) 3.9无线上网卡相关软件版本命名 (9) 3.10无线上网卡驱动软件版本命名 (10) 3.11正式版本号的升级规则 (10) 3.12版本的电子文件命名规则 (11) 4软件版本发布流程 (11) 5禁止条例 (14) 6管理条例 (14) 7附录 (14)
上海精佑通信技术有限公司 文档版本变更记录： 版本号拟制日期拟制人版本描述存档编号 V1.00 2005-4-11 郝军初始版本 V1.01 2005-4-27 郝军1．版本号前增加“V”,用以明显标识版 本号 2．版本号和时间之间以下划线分隔 3．增加生产支持软件种类 4．增加无线上网卡生产支持软件、管理 器软件和驱动软件命名 5．增加版本发布流程的文字说明 V1.02 2005-7-1 郝军增加手机和模块生产支持软件的类型：射 频补丁软件（RFP） V1.03 2005-7-15 郝军更改版本号升级规则，更改资料外发申请 表 V1.04 2005-7-26 郝军增加机卡合一版本的命名规则 注：1）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写。
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
项目软件版本号管理规范
历史修改记录 一. 目的
1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象， 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一 管理。 1.3本文档是为规范研发部软件版本管理而制定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号：内部版本号和外部版本号。版本号使用 VP规则，V(Version)是指外部版本号（研发测试版本），P(Patch)是指补丁版本号（可选）。 3.1.2版本号命名：V/B+主版本号+次版本号+修订版本号+日期版本号
3.2版本号修改规则 3.2.1主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生 变化。此版本号由项目决定是否修改。 3.2.2次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变 动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩 充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要 更改日期版本号。此版本号由开发人员决定是否修改。 如： V8.1.0.XXX (上一级版本号有变动时，下级要归零) 3.3版本号修改举例说明 如此时版本号为：V8.1.0.XXX ，此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： V8.1.1.XXXX ，如当前日期跟上一个版本号的日期不一样，版本号可改为： V8.1.1.XXX。
软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书
需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划 上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。
配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目内部的目录结构： |–projectA
软件开发管理制度 版本：V1.0 2013年1月
第一节总则 第一条为规自有软件研发以及外包软件的管理工作，特制定本制度。本制度适用于公司总公司软件研发与管理，分公司参照执行。 第二条本制度中软件开发指新系统开发和现有系统重大改造。 第三条本制度中自行开发是指主要依赖公司自身的管理、业务和技术力量进行系统设计、软件开发、集成和相关的技术支持工作，一般仅向外购置有关的硬件 设备和支撑软件平台；合作开发是公司与专业IT公司（合作商）共同协作 完成IT应用的项目实施和技术支持工作，一般形式是公司负责提供业务框 架，合作商提供技术框架，双方组成开发团队进行项目实施，IT系统的日常 支持由IT技术中心和合作商共同承担，IT技术中心负责部（一级）支持， 合作商负责外部（二级）支持；外包开发是指将IT应用项目的设计、开 发、集成、培训等任务承包给某家专业公司（可以是专业的IT公司或咨询 公司等），由该公司（承包商）负责应用项目的实施。 第四条软件开发遵循项目管理和软件工程的基本原则。项目管理涉及立项管理、项目计划和监控、配置管理、合作开发管理和结项管理。软件工程涉及需求 管理、系统设计、系统实现、系统测试、用户接受测试、试运行、系统验 收、系统上线和数据迁移。 第五条除特别指定，本制度中项目组包括业务组（或需求提出组）、IT组（可能包括网络管理员和合作开发商）。 第二节立项管理 第六条提出开发需求的信息技术部门参与公司层面立项，进行立项的技术可行性分析，编写《立项分析报告》（附件一），开展前期筹备工作。《立项分析报 告》应明确项目的围和边界。 第七条应用系统主要使用部门将《立项分析报告》上交公司总裁室进行立项审批，以保证系统项目与公司整体策略相一致。 第八条《立项分析报告》得到批准后，成立项目组（如果是外包开发，则成立外包商项目组；如果是合作开发，则与外包商共同成立合作开发项目组，以下统 称“项目组”），项目组应包括业务组（由公司相关业务部门组成）和IT组 （自行开发为办公室网络管理员；外包开发为外包商成员；合作开发为网络
软件版本管理规 V1.0.0 文档版本变更记录：
目录 前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)
前言 为规部门产品软件版本的管理与控制，保证产品版本的有效与质量，制定本标准。本标准由移动金融事业部拟制。 本标准于2015年6月首次发布。
软件版本管理规定 1围 本标准规定了移动银行事业部产品软件版本的控制与管理。 本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义 下列定义适用于本标准。 2.1软件 指与产品相关的所有软件，可以分为产品软件和演示软件。 2.2产品软件 已签订合同，有明确交付日期的产品。 2.3演示软件 处于研发阶段，并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成 产品的正式软件版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 产品的演示版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 3.2产品软件版本命名 产品软件版本的命名规则如下所示：
版本管理规范(草案) 研发部 2009-2-4
目录 文档类别使用对象....................................................... 错误!未定义书签。1．引言................................................................ 错误!未定义书签。 目的 .................................................................. 错误!未定义书签。 范围 .................................................................. 错误!未定义书签。 术语定义 .............................................................. 错误!未定义书签。 版序控制记录 .......................................................... 错误!未定义书签。 版本更新记录 .......................................................... 错误!未定义书签。2．版本管理............................................................ 错误!未定义书签。 2．1版本标识方法...................................................... 错误!未定义书签。 2．1．1正式版本..................................................... 错误!未定义书签。 2．2目录结构.......................................................... 错误!未定义书签。 2．3文档的存放........................................................ 错误!未定义书签。 当前版本和历史版本的存放 ........................................... 错误!未定义书签。 开发文档的存放 ..................................................... 错误!未定义书签。 源代码的存放 ....................................................... 错误!未定义书签。 SQL语句的存放...................................................... 错误!未定义书签。 发行文档的存放 ...................................................... 错误!未定义书签。 2．4权限控制管理...................................................... 错误!未定义书签。3．更新管理（版本升级） ................................................ 错误!未定义书签。 版本升级原则 ........................................................ 错误!未定义书签。 新版本的发布 ....................................................... 错误!未定义书签。4．备份管理............................................................ 错误!未定义书签。5．用户版本管理........................................................ 错误!未定义书签。6．研发部统一管理阶段性版本............................................. 错误!未定义书签。 阶段性版本的提交到研发部............................................... 错误!未定义书签。 阶段性版本的发布到公司网站上........................................... 错误!未定义书签。 各项目组新版本内部及时备份。........................................... 错误!未定义书签。7．版本工具的使用...................................................... 错误!未定义书签。 研发部采用SVN配置管理工具............................................. 错误!未定义书签。8．各项目组提交文档及源码以及规则....................................... 错误!未定义书签。 各项目组需要提交的文档................................................ 错误!未定义书签。 目前所管理的产品列表................................................... 错误!未定义书签。9．周报管理制度........................................................ 错误!未定义书签。10．风险管理制度....................................................... 错误!未定义书签。
软件版本管理规X 系统软件开发部 2011-9-20
目录1引言3 1.1目的3 1.2X围3 1.3术语定义3 1.4版序控制记录4 1.5版本更新记录4 2版本管理4 2.1流程图4 2.2版本命名7 2.3版本升级7 2.3.1版本升级原则7 2.3.2新版本的发布8 2.4目录结构8 2.5文档的存放9 2.5.1文本文件的存放9 2.5.2源代码的存放9 2.5.3发行文档的存放9 2.6权限控制管理10 3备份管理10 3.1源文件备份10 3.2库文件备份10 4用户版本管理10 5版本工具的使用11 5.1配置管理工具11 5.2CVS的使用11 5.2.1常用命令11 5.2.2简单操作12 5.2.3版本分支管理12
1引言 1.1 目的 本文档是为规XXXXXXXXX软件版本管理而制定的。 1.2 X围 本文档为系统软件开发部版本管理员提供有关版本管理规X的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3 术语定义 CVS CVS是一个开源的版本控制系统Concurrent Versions System的简称 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。 基线 软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。
技术部软件版本规范 文档建立/修改记录： 版本管理规范 【新建项目版本管理部分】 1，项目组接到项目需求， 1.1，开发组出项目设计和开发计划； 1.2，测试在Git中建立空项目(项目名称开会时候会有，没有需要问)，形成master版本，版本设定为V0.0.0。 2，组长发邮件给技术总监，并且抄送给项目经理和测试。 邮件内容：开发计划文档url和开发版本号(V0.1.0)，请批准第一阶段(开发计划中会包含)开发。 3，得到批准开发回复后，测试从master(V0.0.0)建立分支版本(V0.1.0)，打开版本参与人员的更新权限，并且将url给组长。 4，组长download项目，上传项目可运行框架，并且更新GIT中的readme文档并通知开发；5，开发者必须按时按功能点来提交(提交时需写相应描述)项目到GIT中，并且push前必须测试，保证代码不能有运行异常，导致无法测试 5.1，Push结束后，开发者继续开发下一个功能点。 5.2，push结束会自动化构建，自动化构建完成后系统会自动通知测试人员进行测试，测试人员需先关闭版本参与人员的更新权限，再按功能点来测试bug，然后更新bug文档和测试用例文档的内容(有无bug都需要更新)，随即打开更新权限并通知组长。 6，开发者下一个功能点提交时，同上要求。 7，第一阶段最后一个功能点提交完毕后，测试者关闭此版本参与者更新权限，然后将此版本(V0.1.0)建分支版本(V0.1.1)并且给出版本url给组长，继续进行测试最后一个功能点bug。8，组长通知组员进行bug（bug一般会比较少，bug很多只能说明开发者开发质量有问题）修改，给出修改版本地址。 9，修改完毕后提交，测试人员再次关权限且测试，如仍然有bug存在，更新相应文档并在相关修改支版本(这里是V0.1.1)中再次建立修改版本(此时是V0.1.2)，随即给出版本url给组长。ps：提交版本如有冲突找组长调节。 10，第一阶段开发完全完成后开始开发第二阶段任务，重复2~9步骤，相应的版本号会变为从V0.2.0开始，同里修改版本号则是V0.2.1/V0.2.2/V0.2.3...... 11，当全部阶段任务完成(指的是开发完成并测试无bug)，测试将最新的修改完成的版本(应该是V0.x.x，x为任意数字)合并到master版本中，此时版本号设定为V1.0.0。测试发邮件给
软件项目管理制度 文件编号 SKYEYES-ZJ-04 版 本 号 Version 0.1 编 制 审 核 批 准 保密级别 发布日期
目录 1目的 (2) 2适用范围 (2) 3职责 (2) 4软件项目管理 (3) 4.1项目整体管理 (3) 4.2项目启动阶段 (5) 4.3初步需求调研阶段 (6) 4.4软件需求规格阶段 (6) 4.5设计阶段 (7) 4.6实现阶段 (8) 4.7测试阶段 (8) 4.8实施及试运行阶段 (10) 4.9验收阶段 (11) 4.10收尾阶段 (12) 5相关文件 (13)
1目的 本制度规定了公司所承接的不同规模的软件项目开发流程，说明项目的各个阶段之间的输入输出结果，以及执行各阶段任务时的要求及相关模板，各部门的职责等，并说明了各阶段完成的标志和标准，是项目组推进项目及质量管理部门检查项目工作的核心制度。 本制度是作为项目配置管理、质量管理、测试管理制度的基础性文件，其他相关制度按照此制度规定的流程及要求进一步拓展、深化项目相关其他环节的管理规范。 2适用范围 本制度适用于以下情况： ●公司所承接的不同规模的软件开发类项目； ●公司所承接的集成项目中的软件开发部分； ●公司产品的外围开发工作。 3职责 部门名称主要职责 分管总监1.负责协助项目启动过程，指派项目经理及项目组； 2.负责协助项目组完成项目各阶段任务； 3.负责参与评审项目关键阶段成果； 4.负责协助项目组处理疑难问题。 应用开发部1.部门成员出任项目经理； 2.项目经理为项目第一责任人； 3.对项目结果负责； 4.根据公司要求开展项目各阶段任务； 5.负责项目启动至项目收尾的所有项目相关工作； 6.负责向其他部门提供允许的技术资料及技术支持。 质量管理部 1.负责项目启动阶段的准备工作； 2.负责检查项目各阶段的成果并出具检查报告；
XXXXXXXX 代码版本管理规范
历史版本
目录 历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)
1引言 1.1目的 为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 1.2管理工具 沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。
2现状概述 目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。 这样会造成如下两点影响： ●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库 中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 ●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部 分问题是由于其他项目代码引起的。 因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述 当前代码版本管理现状如下： 1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的 代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。 这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。 总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试
软件版本管理制度 1．引言 (2) 1.1目的 (2) 1.2范围 (2) 1.3术语定义 (2) 1.4版序控制记录 (3) 1.5版本更新记录 (3) 2．版本管理 (3) 2．1版本标识方法 (3) 2．1．1正式版本 (4) 2．2目录结构 (4) 2．3文档的存放 (6) 2.3.1 当前版本和历史版本的存放 (6) 2.3.2 开发文档的存放 (6) 2.3.3 源代码的存放 (6) 2.3.4 SQL语句的存放 (6) 2.3.5发行文档的存放 (6) 2．4权限控制管理 (6) 3．更新管理（版本升级） (7) 3.1版本升级原则 (7) 3.2 新版本的发布 (7) 4．备份管理 (8) 5．用户版本管理 (9) 6．研发部统一管理阶段性版本 (9) 6.1阶段性版本的提交到研发部 (9) 6.2阶段性版本的发布到公司网站上 (9) 6.3各项目组新版本内部及时备份。 (10) 7．版本工具的使用 (10) 7.1研发部采用svn配置管理工具 (10) 8．各项目组提交文档及源码以及规则 (11) 8.1 各项目组需要提交的文档 (11) 8.2目前所管理的产品列表...............................................................................错误！未定义书签。9．周报管理制度 (12) 10．风险管理制度 (13)
1．引言 1.1目的 本文档是为规范软件研发版本管理而制定的。 1.2范围 本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3术语定义 SVN Svn是一个开源的版本控制系统Subversion的简称 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。基线 软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。
密级：内控 研发本部版本管理规范 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术语定义 SCM Softwere Configuration Management缩写 SVM Software Version Management缩写 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。 基线 软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确
北京东达悦科技有限公司软件研发版本管理规范(草案) 研发部 2009-2-4
目录 文档类别使用对象 (3) 1．引言 (4) 目的 (4) 范围 (4) 术语定义 (4) 版序控制记录 (5) 版本更新记录 (5) 2．版本管理 (5) 2．1版本标识方法 (5) 2．1．1正式版本 (5) 2．2目录结构 (6) 2．3文档的存放 (7) 当前版本和历史版本的存放 (7) 开发文档的存放 (7) 源代码的存放 (7) SQL语句的存放 (7) 发行文档的存放 (7) 2．4权限控制管理 (8) 3．更新管理（版本升级） (8) 版本升级原则 (8) 新版本的发布 (9) 4．备份管理 (9) 5．用户版本管理 (10) 6．研发部统一管理阶段性版本 (10) 阶段性版本的提交到研发部 (10) 阶段性版本的发布到公司网站上 (10) 各项目组新版本内部及时备份。 (11) 7．版本工具的使用 (11) 研发部采用SVN配置管理工具 (11) 8．各项目组提交文档及源码以及规则 (11) 各项目组需要提交的文档 (11) 目前所管理的产品列表 (12) 9．周报管理制度 (12) 10．风险管理制度 (13)
文档类别使用对象 文档类别 该文档是为东达悦公司提供一个版本管理规范性文件。 使用对象 该文档使用对象为东达悦软件公司研发本部各部门项目经理及版本管理人员，以及其他相关人员。未经许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
1．引言 目的 本文档是为规范东达悦软件公司研发版本管理而制定的。 范围 本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括：版本标识方法 软件系统数据的存放 文档的修改控制 文档的备份制度 术语定义 SVN Svn是一个开源的版本控制系统Subversion的简称 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。
北京东达悦科技有限公司 软件研发版本管理规范v1.0(草案) 研发部 2009-2-4
目录 文档类别使用对象 (3) 1．引言 (4) 1.1目的 (4) 1.2范围 (5) 1.3术语定义 (5) 1.4版序控制记录 (6) 1.5版本更新记录 (6) 2．版本管理 (7) 2．1版本标识方法 (7) 2．1．1正式版本 (7) 2．2目录结构 (7) 2．3文档的存放 (9) 2.3.1 当前版本和历史版本的存放 (9) 2.3.2 开发文档的存放 (9) 2.3.3 源代码的存放 (10) 2.3.4 SQL语句的存放 (10) 2.3.5发行文档的存放 (10) 2．4权限控制管理 (10) 3．更新管理（版本升级） (11) 3.1版本升级原则 (11) 3.2 新版本的发布 (12) 4．备份管理 (13)
5．用户版本管理 (13) 6．研发部统一管理阶段性版本 (14) 6.1阶段性版本的提交到研发部 (14) 6.2阶段性版本的发布到公司网站上 (14) 6.3各项目组新版本内部及时备份。 (15) 7．版本工具的使用 (15) 7.1研发部采用SVN配置管理工具 (15) 8．各项目组提交文档及源码以及规则 (15) 8.1各项目组需要提交的文档 (15) 8.2目前所管理的产品列表 (16) 9．周报管理制度 (17) 10．风险管理制度 (18) 文档类别使用对象 文档类别 该文档是为东达悦公司提供一个版本管理规范性文件。 使用对象 该文档使用对象为东达悦软件公司研发本部各部门项目经理及版本管理人员，以及其他相关人员。未经许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
软件版本管理制度
软件版本管理规范 系统软件开发部 -9-20
目录 1引言........................................................................................ 错误!未定义书签。 1.1 目的 .................................................................................. 错误!未定义书签。 1.2 范围 .................................................................................. 错误!未定义书签。 1.3 术语定义 .......................................................................... 错误!未定义书签。 1.4 版序控制记录.................................................................. 错误!未定义书签。 1.5 版本更新记录.................................................................. 错误!未定义书签。2版本管理................................................................................ 错误!未定义书签。 2.1 流程图 .............................................................................. 错误!未定义书签。 2.2 版本命名 .......................................................................... 错误!未定义书签。 2.3 版本升级 .......................................................................... 错误!未定义书签。 2.3.1版本升级原则 ............................................................ 错误!未定义书签。 2.3.2新版本的发布 ............................................................ 错误!未定义书签。 2.4 目录结构 .......................................................................... 错误!未定义书签。 2.5 文档的存放...................................................................... 错误!未定义书签。 2.5.1文本文件的存放 ........................................................ 错误!未定义书签。 2.5.2源代码的存放 ............................................................ 错误!未定义书签。 2.5.3发行文档的存放 ........................................................ 错误!未定义书签。 2.6 权限控制管理.................................................................. 错误!未定义书签。3备份管理................................................................................ 错误!未定义书签。 3.1 源文件备份...................................................................... 错误!未定义书签。