(完整版)软件版本管理规范V2
版本管理规范
版本管理规范一、引言版本管理是软件开辟过程中非常重要的一环,它能够有效地管理软件的版本、变更和发布,确保团队成员之间的协作顺畅,同时也能够提高软件开辟的质量和效率。
本文将介绍版本管理规范的制定目的、适合范围和基本原则,以及具体的版本管理流程和规范要求。
二、目的版本管理规范的目的是为了规范团队成员在软件开辟过程中的版本管理行为,确保软件开辟过程的可控性和可追溯性,提高团队协作效率,减少版本冲突和错误,保证软件的稳定性和可靠性。
三、适合范围本版本管理规范适合于所有软件开辟项目,包括但不限于需求分析、设计、编码、测试和发布等阶段。
四、基本原则1. 版本命名规范:版本号应采用主版本号.次版本号.修订号的格式,例如1.0.0,其中主版本号表示重大功能更新或者架构变更,次版本号表示功能增加或者改进,修订号表示错误修复或者小的改动。
2. 版本控制工具:团队成员应使用统一的版本控制工具进行代码管理,常用的版本控制工具有Git、SVN等。
3. 分支管理策略:根据项目的需要,合理规划分支管理策略,例如主分支用于发布稳定版本,开辟分支用于新功能的开辟,修复分支用于错误修复等。
定性,同时记录版本发布的相关信息,如发布日期、发布内容等。
5. 变更管理:对于每一次代码变更,都应记录变更的内容、原因和责任人,并及时通知相关人员。
五、版本管理流程1. 创建新的版本:在开始新的开辟任务之前,团队成员应基于主分支创建新的开辟分支,并根据任务的名称或者编号进行命名。
2. 开辟和测试:团队成员在各自的开辟分支上进行开辟和测试工作,确保代码的质量和功能的完整性。
3. 合并和冲突解决:当开辟任务完成后,团队成员将代码合并到主分支,并解决可能浮现的冲突。
4. 版本发布:在主分支上完成代码合并和冲突解决后,进行版本发布前的测试和审核工作,确保版本的质量和稳定性。
5. 变更管理:对于每一次代码变更,团队成员应及时记录变更的内容、原因和责任人,并通知相关人员。
软件版本管理规范
软件版本管理规范软件版本管理规范一、引言在软件开发过程中,版本管理是非常重要的一环。
它确保了软件的变更能够被跟踪、管理和控制。
有效的版本管理可以提高开发效率,减少错误,促进团队协作。
本规范旨在定义一种通用的、一致的、可扩展的软件版本管理方法,以确保软件项目的顺利进展。
二、版本管理系统的选择1.确定需求:在选择版本管理系统之前,首先要明确团队的需求。
考虑团队规模、项目复杂性、代码库大小等因素。
2.市场调研:收集市场上流行的版本管理系统的信息,评估它们的优点和缺点。
考虑系统的易用性、稳定性、可扩展性和成本效益。
3.选择合适的系统:根据项目需求和市场调研的结果,选择最适合团队的版本管理系统。
常见的版本管理系统包括Git、Subversion(SVN)、Mercurial等。
三、版本管理流程1.代码审查:实施代码审查制度,确保代码质量,减少错误。
可以采用PullRequest、Code Review等方式进行。
2.提交代码:每次提交代码前,确保代码符合团队的编码规范和标准。
提交的代码应该有一个明确的描述,以帮助其他开发者理解本次提交的内容。
3.测试:在提交代码之后,进行自动化测试和手动测试,确保代码的质量和稳定性。
测试包括单元测试、集成测试和系统测试等。
4.发布:经过测试后,将代码发布到生产环境。
在发布前,应进行最后一次代码审查,以确保生产环境的稳定性。
5.维护:在生产环境中,对软件进行维护和监控,确保其正常运行。
当发现问题时,及时修复并发布修复版本。
四、版本管理规范1.编码规范:制定并遵守统一的编码规范,包括命名规范、缩进风格、注释规则等。
这样可以提高代码的可读性和可维护性。
2.提交信息:每次提交代码时,确保提交信息清晰、简洁地描述所做的更改和原因。
这将有助于其他开发者了解代码变更的内容和目的。
3.代码审查:实施严格的代码审查制度,确保代码质量和可维护性。
所有提交的代码必须经过代码审查,并且只有在通过审查后才能被合并到主分支。
(完整版)软件版本管理办法
广东亿迅科技有限公司软件版本管理办法(暂行)第一章总则第一条为了加强广东亿迅科技有限公司(以下简称“公司”)的软件版本管理工作,进一步细化公司配置管理规范,建立软件版本管理的规范化操作流程,保证公司软件产品质量,制定本办法。
第二条本办法适用于公司各技术部门的软件版本管理工作。
第三条本办法所称的软件版本是指公司所有面向用户发布的应用软件版本。
第四条软件版本(以下简称“版本”)管理应遵循以下原则:(一)实施版本变更应符合以下原则之一:1.为满足客户新业务、新功能需求;2.为满足提高业务质量、提升业务性能指标和容量扩充的需求;3.为解决软件故障和软件稳定性、安全性、可控性问题;4.为了提高软件可维护性。
(二)版本的集成和发布应严格按照计划执行,避免随意和频繁更新版本;(三)为保证软件质量,任何一个软件版本须通过版本测试后方可上线;(四)公司所有软件版本必须通过正式渠道发布给用户,未经审批各部门和个人不得擅自向用户发布软件版本。
第五条版本管理是保障应用软件正常运行的一个重要手段,各相关部门应认真贯彻落实,并纳入工作考核;未按本办法执行从而造成版本故障影响用户正常生产的,一经发现将追究其相应责任。
第二章职责与分工第六条版本管理实行总体质量控制,分级实施管理原则,管理工作涉及版本质量管控部门和版本集成发布部门;质量管理部是版本质量管控部门,各业务部门是版本集成发布部门。
第七条版本质量管控部门的工作职责如下:(一)负责制定与版本管理工作相关的管理办法和工作流程并组织落实;(二)负责组织版本管理相关的培训并提供技术支持;(三)负责跟踪和监督公司版本管理工作的执行情况,协调解决执行中的问题,并对版本管理的执行效果进行评估考核;(四)负责组织和实施对版本的测试验证工作;(五)负责对版本升级实施效果和版本质量进行监控和评估;(六)其它应由版本质量管控部门负责的事项。
第八条版本集成发布部门的工作职责如下:(一)负责本部门版本研发集成工作环境的建立、维护和管理;(二)负责依据版本管理工作流程,执行版本开发、集成、发布及维护的相关工作;(三)负责收集分析业务需求,制定版本计划并按计划组织实施;(四)负责跟踪版本上线后的运行情况,收集用户使用的反馈信息,改进版本质量;(五)其它应由版本集成发布部门负责的事项。
项目软件版本号管理规范
项目软件版本号管理规范历史修改记录一. 目得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。
软件版本管理规范V2
产品更新发布通常是修复老产品的缺陷如收集一定时间内的产品缺陷,汇总产生如3.0.1进行更新发布
补丁发布:补丁(紧急修复)是用来修复产品缺陷或掩饰缺点的。补丁和更新之间的区别是紧急程度和实施的工作量
4.4.1.2.发布包的主要构成如下,如果是补丁或产品更新发布,发布包简化为程序、说明性文档和源码
源代码和安装程序的检查
4.4.3.软件产品正式版本发布流程如下
4.4.3.1.发布准备发布之前,所有程序由测试工程师进行确认测试;检查BUG系统内登记的所有bug都已经被解决,或者遗留的bug不影响系统的使用,如果有严重bug未解决则不能发布;程序打包前做测试
4.4.3.2.测试工程师组织软件发布评审,由软件系统工程师主持评审
4.4.3.3.源码、文档入库编译构建脚本和所有源代码;文档包括需求说明、设计说明、计划,测试文档,操作手册、使用demo等
4.4.3.4.系统工程师进行程序打包标记源码、文档版本tag
4.4.3.5.编写发布说明readme.txt Read me的内容应该包括产品版本说明;本次发布包含的文件包、文档说明;本次发布包含或者新增的功能特性说明;遗留问题及影响说明;版权声明以及其他需要说明的事项
3.3.
1)负责对软件功能模块的编码工作
2)工作前对本地工作目录的代码进行检查是否为最新版本,确认后方可进行工作,否则必须先进行本地工作目录的更新
3)工作完成后及时将本地机工作目录下的代码进行checkin,避免代码丢失造成的损失
4)每次涉及到版本机的checkin都必须附上版本说明(说明修改的内容,新增功能,解决的bug等)
3)审批本组成员输出资料,确保输出资料准确无误
软件版本管理规范标准
软件版本管理目录1. 引言 (1)1.1. 目的 (1)1.2. 范围 (1)1.3. 术语定义 (1)1.4. 参考资料 (2)1.5. 版本控制记录 (2)1.6. 版本更新记录 (3)2. 版本管理 (4)2.1. 版本标示方法 (4)2.1.1. 正式版本 (4)2.2. 目录结构 (5)2.3. 文档的存放 (6)2.3.1. 开发文档的存放 (6)2.3.2. 源代码的存放 (6)2.3.3. SQL的语句存放 (7)2.3.4. 发行文档的存放 (7)2.4. 配置管理流程 (8)2.5. 权限控制的管理 (8)3. 更新管理 (10)3.1. 源程序的修改 (10)3.2. 版本升级 (11)3.2.1. 版本升级原则 (11)3.2.2. 新版本发布 (12)3.3. 文档的变更 (12)4. 备份管理 (13)1.引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理,保证任何时间都可以取到正确的版本以及版本的组合。
版本控制的主要功能是记录开发过程中的每一次修改,让开发的工作可以随时检查过往历史记录和获得正确版本,是系统的成长记录。
1.1.目的本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。
1.2.范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容,包括:●版本标识方法●软件系统数据的存放●文档的修改控制●文档的备份制度1.3.术语定义SCM软件配置管理(Software Configuration Management)缩写SVM软件版本管理(Software Version Management)缩写SVN一个开源的版本控制系统Subversion.文档一种数据媒体和其上所记录的数据。
配置管理标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。
公司内部软件版本管理规范-202009
软件版本管理规范版本变更记录目录1引言 (5)1.1目的 (5)1.2范围 (5)2原则 (5)3角色职责 (6)4版本管理 (6)4.1版本管理流程 (6)4.1.1部门职责及输出物 (6)4.1.2版本管理流程图 (7)4.1.3禅道项目管理流程图 (8)4.2版本标识方法 (8)4.2.1正式版本 (8)4.2.2内部测试版本 (9)4.3版本升级管理 (9)4.3.1版本升级原则 (9)4.3.2新版本发布原则 (10)4.4文档的存放 (11)4.4.1当前版本和历史版本的存放 (11)4.4.2开发文档的存放 (11)4.4.3源代码的存放 (11)4.4.4SQL语句的存放 (11)4.4.5发行文档的存放 (12)4.5权限控制管理 (12)5版本提交规则 (12)5.1开发交付测试要求 (12)5.2测试接收标准 (13)5.3测试中断标准(冒烟测试) (13)5.4测试通过标准 (13)6备份管理 (14)7各开发组提交文档及源码以及规则 (14)8版本发布流程 (15)1引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理,保证任何时间都可以取到正确的版本以及版本的组合。
版本控制的主要功能是记录开发过程中的每一次修改,让开发的工作可以随时检查过往历史记录和获得正确版本,是系统的成长记录。
1.1目的本文档的编制是为了规范产品管理中心、运营开发中心、产品开发中心、项目管理中心对软件产品版本的管理。
1.2范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容,包括:➢版本标识方法➢软件系统数据的存放➢文档的修改控制➢文档的备份制度2原则软件版本发布管理应遵循以下原则:1)实施版本变更应符合以下原则之一:✓为满足客户新业务、新功能需求;✓为满足提高业务质量、提升业务性能指标和容量扩充的需求;✓为解决软件故障和软件稳定性、安全性、可控性问题;✓为了提高软件可维护性。
版本管理规范
版本管理规范一、引言版本管理是软件开发过程中非常重要的一环,它涉及到多人协作、代码的追踪与回滚、代码质量的保证等方面。
为了规范团队的版本管理流程,提高开发效率和代码质量,制定本版本管理规范。
二、目的本规范的目的是为了确保团队在软件开发过程中能够有效地管理和控制版本,确保版本的完整性、可追溯性和可回滚性,提高团队的协作效率和代码质量。
三、适用范围本规范适用于团队内部的软件开发项目,包括但不限于代码库、文档库、配置文件等。
四、版本管理工具团队使用统一的版本管理工具,推荐使用Git作为版本管理工具。
Git具有分布式版本控制系统的特点,支持多人协作、分支管理、代码追踪和回滚等功能。
五、代码库管理1. 创建代码库在版本管理工具中,创建新的代码库,并设置好访问权限。
2. 分支管理- 主分支:代码库中应至少包含一个主分支(如master),用于存放稳定的、可发布的代码。
- 开发分支:团队成员在开发新功能或修复bug时,应从主分支创建自己的开发分支,并在分支名中包含自己的姓名或编号。
- 特性分支:针对某个具体功能或需求,可以从开发分支创建特性分支,并在分支名中包含该功能或需求的简要描述。
3. 提交规范- 提交频率:每个提交应尽量保持功能单一,避免包含多个功能或修改。
- 提交信息:每个提交都应包含有意义的提交信息,描述该次提交的目的和内容。
4. 合并与冲突解决- 合并分支:当开发分支的功能开发完成后,应将其合并到主分支。
合并前应先进行代码审查,确保代码质量。
- 冲突解决:当合并分支时出现冲突,应及时解决冲突并进行测试验证。
六、文档管理1. 文档库结构在版本管理工具中,创建文档库,并按照项目需要建立相应的文件夹结构,方便文档的分类和查找。
2. 文档命名文档命名应简洁明确,避免使用特殊字符和空格。
推荐使用英文或数字进行命名,可以包含适当的下划线或连字符。
3. 版本控制文档的版本控制与代码库管理类似,每次对文档进行修改时,应提交相应的版本,并在提交信息中描述修改的内容。
需求管理规范V2
需求管理规范V21. 引言本文档旨在规范需求管理的流程和方法,以确保项目需求的准确性和可追溯性,并提高项目成功的几率。
2. 需求管理流程需求管理包含以下主要流程:2.1 需求识别和收集- 与相关利益相关方进行沟通,确定项目的主要目标和愿景。
- 识别和明确项目的业务需求和功能需求。
- 采用适当的工具和方法,收集和记录需求信息。
2.2 需求分析和验证- 对收集的需求进行细化和分析,确保需求的明确性和可测性。
- 在需求分析过程中,验证需求是否能够满足项目的目标和愿景。
- 与相关利益相关方一起评审和确认需求。
2.3 需求管理和变更控制- 设立有效的需求管理和变更控制机制,确保需求的稳定性和一致性。
- 记录和跟踪需求变更,评估变更的影响并做出决策。
- 对需求进行版本管理,确保对历史需求的追溯和审计。
3. 需求管理方法和工具为支持需求管理流程,可以使用以下方法和工具:3.1 用例分析- 使用用例分析方法,清晰描述系统与用户的交互行为和功能需求。
- 定义用例的前置条件、主法案、次法案和后置条件,帮助理解和验证需求。
3.2 业务流程图- 使用业务流程图表示系统的业务流程,帮助识别和理解业务需求。
- 标示流程中的各个步骤和决策点,帮助推导出系统功能需求。
3.3 需求跟踪工具- 使用需求跟踪工具,帮助记录、追踪和管理需求和变更。
- 可以使用电子表格或专业的需求管理软件进行需求的跟踪和管理。
4. 需求管理的最佳实践以下是一些需求管理的最佳实践:- 与相关利益相关方保持密切沟通,理解他们的需求和期望。
- 确保需求的准确性和可测性,避免模糊或冲突的需求。
- 尽早进行需求分析和验证,以减少后期的变更和风险。
- 设立合适的需求变更控制机制,确保变更的合理性和一致性。
- 定期对需求进行评估和审查,确保其与项目目标一致。
5. 结论本文档提供了一个需求管理的规范和方法,可以帮助项目团队有效管理和控制需求,提高项目的成功率和满足相关利益相关方的期望。
软件版本管理规定
信息系统软件版本管理办法第一章总则第一条为加强软件版本管理,规范软件版本管理工作流程,提高版本运行维护质量,保证信息系统安全可靠高效地运行,特制定本办法;第二条本办法涉及的软件包括在线运行的软件和拟投产的软件;软件版本管理对象包括应用软件版本以及相关操作系统、数据库、中间件等基础软件;第三条软件版本管理是信息系统开发管理和日常维护管理工作的一个重要组成部分,本办法作为软件版本管理的重要依据,软件版本管理归口管理部门、业务支撑部门、风险管理部门、内审部门及各软件供应商要认真履行各自职责,严格执行软件版本管理的各项流程和规定,保障信息系统的安全稳定运行;第四条任何未经版本归口管理部门许可的软件版本不允许在生产环境使用;在商务合同中若涉及信息系统软件版本,应确认为版本归口管理部门允许使用的软件版本;因使用未经许可的软件版本而造成系统故障影响正常业务交易,相关部门及各厂商要承担相应的责任;第五条本办法由信息技术部负责解释和修订,自发文之日起开始执行;第二章组织与职责第六条软件版本管理实行总行集中管理体系;第七条信息技术部是信息系统软件版本的归口管理部门;第八条稽核监控部是信息系统软件版本管理的内审部门;第九条风险管理部是信息系统软件版本管理的风险控制部门;第十条信息系统软件版本管理工作还涉及软件提供商,软件提供商包括软件最终提供商、代理商和维保服务商以下简称厂商;第一节归口管理部门职责第十一条归口管理部门负责制定和完善的软件版本管理办法;第十二条归口管理部门负责制定信息系统软件版本管理工作的工作计划、工作要求和技术规范,并组织实施;第十三条归口管理部门负责审批业务支撑部门上报的版本变更申请,组织进行资料审核和上线测试,安排试运行工作及全行推广实施;第十四条归口管理部门负责建立软件版本信息库,发布软件版本管理各类信息;建立版本预警体系,发布软件版本缺陷信息和版本预警信息;第十五条归口管理部门负责与业务支撑部门、风险管理部门、内审部门、厂商协调信息系统软件版本管理的相关工作;第三节业务支撑部门职责第十六条版本管理业务支撑部门负责业务类需求的日常收集和集中收集;第十七条版本管理业务支撑部门负责发起新版本的试运行申请;第十八条版本管理业务支撑部门负责协助归口管理部门审核新版本发布资料包括申请、厂家及仿真环境测试报告、版本说明文档、升级方案、测试方案等,并协助归口管理部门开展新版本试运行测试工作;第十九条版本管理业务支撑部门负责自查并督促其下属机构履行职责,严格执行版本管理相关制度和流程;第四节风险管理部门职责第二十条版本管理风险管理部门负责重大版本发布前的风险评估;第五节内审部门职责第二十一条版本管理内审部门负责监督和检查版本管理归口管理部门、业务支撑部门、风险管理部门和厂商是否严格执行版本管理的相关制度与流程;第五节厂商义务第二十二条信息系统厂商应严格遵守软件版本管理的规章制度、技术规范;第二十三条信息系统厂商应根据业务发展及运行维护的需要及时更新版本,保证在线运行的软件版本是允许使用的版本;第二十四条信息系统厂商应配合软件版本归口管理部门进行软件仿真测试,及时提供各类运行维护及仿真测试所需的文件资料和技术咨询,并对这些材料的真实性、可靠性和实时性负责;在不具备相应仿真测试环境的情况下,厂商有义务提供仿真环境配合开展测试;第二十五条信息系统厂商应配合进行试运行工作;厂商应根据版本变更情况选择能够测试所有升级功能点的分支机构,并结合用户量、安全性等的要求向提出试验点建议;第二十六条信息系统厂商应配合做好信息系统软件版本管理工作,建立本厂家信息系统软件版本管理资料库信息,协助软件版本归口管理部门做好版本预警信息的发布与管理,提供必要的技术资料和技术支持;第二十七条信息系统厂商应指定专门的版本管理联系人与软件版本归口管理部门衔接,以便配合进行软件的升级实施和及时跟踪处理升级过程中或者升级后出现的各种故障;第二十八条信息系统厂商有义务在升级过程中按照的要求配合完成各项工作,包括协助软件版本归口管理部门模拟重现升级或试运行期间出现的和软件版本相关的故障;第二十九条信息系统厂商有义务在工程招标书中,承诺按照版本管理相关制度和流程履行投标方的义务;第三章版本管理内容与流程第三十条信息系统软件版本分为版本和补丁;版本是指软件系统中的核心部分发生结构性变化、应用部分新增若干功能而生成的软件版本;补丁是指软件系统中不涉及核心部分的变化,只是应用部分的故障修复或功能完善而生成的软件版本;第三十一条版本管理的各项工作必须按照规定的操作流程执行,各相关部门应认真履行本部门的职责,做好部门之间的衔接和协调;第三十二条版本管理工作内容主要包括需求管理、认证管理、变更管理、评估管理和信息管理;其中,需求管理是通过收集、整理和分析版本的新特性需求或未修复缺陷,引导厂家新版本开发,确定待认证的版本;认证管理是依据技术规范,对厂家待认证版本的符合性和可用性进行认证,并对已认证版本进行更新或废止管理;变更管理是对生产运行版本变更的技术审核和流程管控;评估管理是对生产运行版本的版本能力、缺陷等方面的评价和管理;信息管理是对全行软件版本信息及版本管理工作各环节输出信息的动态管理,主要包括信息的收集、整合、关联、更新、价值挖掘和全行共享,是版本管理各项工作的基础;第一节需求管理第三十三条版本需求管理主要分为业务类需求管理和运行维护类需求管理两大类,两大类需求的特点如下:(一)业务类需求:包括对原有业务模型、业务流程进行变更完善的需求,对新业务模式、新业务功能的支撑需求以及与业务推广能力相关的需求等;(二)运行维护类需求:包括运维监控类需求、系统软件版本缺陷和问题解决需求等与运行维护工作直接相关的需求;第三十四条运行维护类需求由信息技术部系统运行中心以下简称运行中心牵头收集整理,业务类需求由信息技术部系统开发中心以下简称开发中心牵头收集整理,最终由软件版本归口管理部门负责进行统一梳理后落实到建设项目中,组织技术规范的修订;第三十五条需求收集分为两种:日常收集和集中征集;(一)日常收集:业务类需求由需求提交部门发起,开发中心收集整理,运行维护类需求由运行中心不定期向综合部提交新需求并填写软件版本需求汇总表见作为附件;(二)集中征集:在专项治理工作中,由专项治理工作归口管理部门发起、在规定时期内征集各方需求,然后统一汇总整理,向需求归口管理部门提交新需求并填写软件版本需求汇总表见作为附件;第二节认证管理第三十六条软件新版本的认证过程包括仿真环境测试和生产环境试运行测试;第三十七条仿真环境测试主要测试内容包括:版本差异化测试新增功能测试、功能变更测试、故障修复有效性测试、新版本回归性验证测试即原有功能点的测试、新版本的升级过程测试、性能测试、业务功能测试等;由厂商自行组织的内部测试也应涵盖上述测试内容;第三十八条原则上,业务类需求导致的新软件版本由信息技术部开发中心组织进行仿真环境测试;运行维护类需求导致的新软件版本由信息技术部运行中心组织进行仿真环境测试;如果新版本包含以上两方面的需求,则由软件版本归口管理部门统一组织新版本的仿真环境测试;新版软件正式开始测试前,厂商应向上述部门提交相关技术资料和说明书;说明书中应包含以下内容:(一)软件版本变更的原因及必要性,新版软件与旧版软件的差异性说明、新增功能说明、新版软件对硬件环境的要求、涉及第三方的软件版本说明;(二)维护手册及有关资料变更部分;(三)新版软件对所在平台及所承载业务的影响以及对相连的系统的影响以及相关接口包括第三方接口变化的说明文档;(四)新版本的历史应用情况,已知缺陷、隐患或与需求含商务需求、设计需求、业务需求、运维需求等不符之处并列出解决方案;(五)对新版软件进行测试的测试方案,包括测试所用的软硬件环境、测试项目及具体测试方法步骤、测试环境要求及预期结果;(六)详细的升级方案及针对各种异常情况的应急预案,升级失败的应急回退方案等;(七)厂商内部测试情况报告;第三十九条对于信息系统软件新版本的仿真环境测试原则上应在提供的仿真环境中进行,对不具备测试条件的,厂商须提供相应的仿真环境;厂商应在测试前,配合进行仿真环境的准备工作;仿真环境应能对版本进行尽量完整的测试;第四十条对于仿真环境下无法测试的测试用例,经归口管理部门审核后可在试运行阶段再进行测试;第四十一条因版本质量问题导致不能完成测试或测试报告结论为不通过的,需由厂商修改问题后重新测试;测试完成后测试单位应向软件版本归口管理部门提交新版本的测试报告XX系统XX版本测试报告见;测试报告文档应包含内容:(一)测试原因(二)测试环境拓扑图(三)测试所需软硬件及其他工具可选(四)基本连接和配置可选(五)测试项目及具体测试方案(六)测试结论包含测试情况如何,该版本功能是否完善,是否符合申请内容以及升级建议等第四十二条对于测试中不满足要求的项目,厂商应给出相应的改进承诺和时间表;第四十三条完成版本测试后,业务支撑部门应向软件版本归口管理部门提出试运行建议申请,并填写XX系统XX版本试运行建议表详见附表四,由软件版本归口管理部门发布新版本的试运行通知;第四十四条信息系统的试运行升级申请应至少在升级日期前七个工作日提交到软件版本归口管理部门,软件版本归口管理部门在收到升级申请后的四个工作日内完成批复,试运行准备时间不少于三个工作日;在紧急情况下,试运行申请至少提前四个工作日提交到软件版本归口管理部门,软件版本归口管理部门在收到申请后两个工作日内完成批复,试运行准备时间不少于两个工作日;升级方案所需要的内容具体参见;第四十五条软件版本归口管理部门组织审核测试报告、升级方案及试运行资料,并填写XX系统XX版本试运行资料审核报告详见;第四十六条重大版本变更厂商在试运行升级时应派专人在现场给予技术支撑,协助定位解决问题;第四十七条软件版本归口管理部门负责组织开展试运行工作,密切关注新版本的运行情况,业务支撑部门应按照试运行测试要求和用例进行完整测试,及时填报测试结果;原则上,试运行时间应不少于三个月;试运行结束后,提交XX系统XX版本试运行报告详见;第四十八条试运行测试完成、确认新版本安全稳定后,由信息技术部在运维管理系统发布新版本相关信息;第四十九条在新版本运行期间若出现涉及危害平台安全、影响业务运行、对客户感知造成重大影响的问题,由业务支撑部门填写XX系统XX版本软件变更申请表见,软件版本归口管理部门在两个工作日内审核回复,组织厂商、信息技术部执行版本回退或修复工作;第五十条厂商应在版本升级后五个工作日内提交版本升级故障分析报告;第五十一条厂商用于投标的软件版本以及新工程中使用的软件版本,均需由厂商向软件版本归口管理部门提出新版本测试申请,按本节管理要求开展测试认证;软件版本归口管理部门和总行验收领导小组应在工程验收时对其使用的软件版本进行检查、把关,确认工程项目中所使用的软件版本是经过测试认证的;第三节变更管理第五十二条版本变更主要指版本和补丁的投入与使用,管理工作主要包括版本升级、补丁输入的申请与审批、版本升级方案含应急措施、测试用例等的制定与审批、升级成功后的资料移交和更新等;第五十三条软件版本升级按发起方不同分为两种:(一)软件版本归口管理部门安排布置的版本升级任务,主要是为了满足总行提出的对全行信息系统的基础建设或维护的需求;(二)业务支撑部门主动提交的版本升级申请XX系统软件变更申请表见,主要是为了满足某个业务需求;第五十四条为了保证平台安全稳定运行,原则上每种平台每月升级次数不超过一次,承载不同业务的平台不安排在同一时间升级;第五十五条软件版本归口管理部门发布批准使用新版本的信息后,总行各业务部室或分支机构可以根据实际情况更换新版本;第五十六条升级方案包含但不限于以下内容:(一)升级目的(二)升级内容(三)各方工作人员职责(四)升级各步骤的时间估算(五)升级涉及范围及对业务的影响(六)具体升级步骤1.升级准备工作及注意事项2.升级操作详细步骤3.升级应急预案和应急预案启动条件4.业务测试用例(七)升级完成核对的内容及步骤(八)备品、备件的升级升级时间、地点、方式(九)运行观察(十)资料归档第五十七条升级过程中间出现升级方案中未预料到的业务中断或中断时间超出预定时间等异常情况时,软件升级工作应立即停止,按照升级方案中的应急预案进行操作,并逐级上报;第五十八条在升级结束后业务支撑部门将升级完成情况汇总,填写XX系统XX版本使用情况汇总表见,在升级完成一周后上报软件版本归口管理部门备案;第五十九条升级结束后,厂商必须向移交:(一)各级用户密码;(二)监控和应用软件的安装程序必须经过测试;(三)设备的详细配置资料;(四)设备维护手册的追加与变更;第四节评估管理第六十条评估管理是对生产环境运行版本的评估,主要包括版本能力、版本缺陷和预警等的管理和评价;版本评估结果是对已认证版本进行更新或废止的重要依据;第六十一条版本变更后,软件版本归口管理部门需跟踪新版本的使用情况,组织版本运行评估工作,对新版本满足业务功能、运行维护管理等需求的能力进行评估;如果新版本能力不足、且认证库中已存在满足需求的版本,则可将此已认证版本作为目标版本适时实施版本变更;如果新版本能力不足、且认证库中不存在满足需求的版本,则将关于新版本使用中所出现问题的评估结果提交版本管理归口管理部门;软件版本归口管理部门对评估结果进行分析,对于当前暂不需要解决的版本遗留问题进行汇总;否则输出至需求归口管理部门进行处理;第六十二条预警定义:预先对因设备软硬件版本缺陷而可能导致业务系统或设备含在线设备和拟投产运行的设备不能正常运行的因素进行警示并防范;版本缺陷的预警管理是保证在线安全、稳定运行的重要措施之一;第六十三条软件版本归口管理部门根据全行在线版本的业务和维护支撑能力、缺陷发生数量及影响、版本变更次数及原因、上线时间等因素,于每年12月20日之前提交年度版本运行评估报告;第五节信息管理第六十四条建立软件版本信息管理体系,实现全行软件版本信息及版本管理工作各环节输出信息的收集、整合、关联、共享、价值挖掘和动态管理;第六十五条软件版本归口管理部门按照统一的版本信息模型,每月初通过运维管理系统提交“全行软件版本使用情况汇总表”见并对汇总信息进行入库和维护更新管理;第六十六条软件版本归口管理部门及时发布版本信息,以便各分支机构和总行各业务部室正确选择使用的版本;各相关单位负责收集、整理、分析辖区内软件版本相关信息,并进行及时更新;版本信息库上包括但不限于以下所示:(一)各厂商的软件版本的状况,包括:版本编号、功能变更说明书、上线测试报告、核准上线日期等;(二)各厂商的软件版本在生产环境中的运行情况,包括:投入运行时间、版本分布情况、主要设备配置、版本的问题等;(三)版本问题登记,包括:软件版本、问题发生时间、原因、现象、影响、排除方法、排除时间及善后处理意见等;(四)其它相关资料,包括:技术标准、企业规范、新业务、新功能的需求汇总、论文资料等;第六节版本管理流程第四章监督与检查第六十七条版本管理内审部门将适时组织检查信息系统的软件版本管理工作情况,并及时通报检查结果;结合本年度全行在线版本管理各项工作情况,于每年底发布全行年度在线版本管理工作情况通报;对于因版本管理不善或使用未经许可的软硬件版本而造成的业务中断故障、用户投诉及经济损失等,内审部门将视具体情况对相关部门、负责人或直接责任人给予通报批评,并反映在部门考核指标中;第六十八条归口管理部门在进行“外包商服务质量评估”时,应将厂家软件版本运行评估情况及对版本管理工作的支撑情况作为评估内容之一,并将评估结果作为采购评标的重要考虑因素;在维保合同中应增加版本管理工作相关要求的条款,并进行相关考核;对于因厂家原因造成的业务中断故障及由此产生的损失,将视具体情况对相关厂家给予处罚并追究相关责任;附表一:XX业务软件需求汇总表附表二:软件版本测试申请表附表三:XX系统XX版本/补丁测试报告XX系统软件版本/补丁测试报告1.测试概况测试目的2.测试环境网络结构图3.测试内容对测试情况的描述4.测试结论测试通过或测试不通过,测试不通过请说明原因;附表四:XX业务XX版本试运行建议表附表五:XX业务XX版本试运行资料审核报告附表六:XX业务系统试运行报告附表七:XX软件变更申请表附表八:XX业务系统软件版本使用情况汇总表。
软件版本管理规定(范本)
软件版本管理规定(范本)1范围本标准规定了软件版本的控制与管理。
本标准适用于软件版本的控制与管理。
2术语和定义下列定义适用于本标准。
2.1软件指与产品相关的所有软件,可以分为产品软件和演示软件。
2.2产品软件已签订合同,有明确交付日期的产品。
2.3演示软件处于研发阶段,并未正式投入生产的应用。
3软件版本命名规则3.1软件版本命名组成产品的正式软件版本命名由四部分组成。
第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。
产品的演示版本命名由四部分组成。
第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。
3.2产品软件版本命名产品软件版本的命名规则如下所示:产品标识ZS_VX.Y.Z_YYYYMMDD版本号和时间之间以下划线分隔。
具体含义见表1。
3.3演示软件版本命名演示软件版本的命名规则如下所示:产品标识YS_VX.Y.Z_YYYYMMDD版本号和时间之间以下划线分隔。
具体含义见表1。
3.4 正式版本号的升级规则软件的正式版本号升级,应该能体现出版本继承性关系,根据软件改动的大小,进行正式版本号升级。
3.4.1软件版本升级规则1)研发阶段主版本X的值为0,上线主版本X升级为1,后续根据系统调整需求大小或者合同的约定修改主版本号,如第一期合同主版本号为1,第二期合同主版本号为2;2)软件的初始正式版本号为V1.0.0;3)软件次版本号根据修改的功能及工作量依次递增。
如增加一项大的功能,则次版本号增加1;4)修订号及时间:在没有增加或减少大功能情况下的改动,使用修订号。
同一天发布的修订版本不超过10个,如2018年3月1日,共对一个软件做了3次修改,软件主版本号及次版本号为1和1,则这一天发布的版本分别为:ZS_V1.1.0_20180301、ZS_V1.1.1_20180301、ZS_V1.1.2_20180301。
3.4.2演示版本升级规则1)演示版本X的值为0,不做升级。
软件版本管理规范V2
软件版本管理规范V21. 引言软件版本管理是指对软件开发过程中各个版本的控制,以确保软件的可靠性、稳定性和可维护性。
本规范旨在建立一个统一的软件版本管理流程,规范开发人员在软件版本控制方面的操作和行为。
2. 基本原则2.1 版本命名规则版本命名采用主版本号.次版本号.修订版本号的格式,例如:1.0.0。
- 主版本号:当进行重大改动和功能新增时,递增主版本号。
- 次版本号:当进行小的修改和功能调整时,递增次版本号。
- 修订版本号:当进行bug修复和性能优化时,递增修订版本号。
2.2 版本控制工具使用专业的版本控制工具,如Git、SVN等。
版本控制工具能够记录软件的变更历史、回滚操作、分支管理等,方便团队合作和代码的版本控制。
2.3 分支管理策略采用分支管理策略可以实现多人协作开发,减少代码冲突的风险。
- 主分支:用于发布稳定版本的分支,命名为master或main。
- 开发分支:用于日常开发的分支,命名为develop。
- 功能分支:用于开发特定功能的分支,命名为feature/功能名称。
- 修复分支:用于修复bug的分支,命名为bugfix/bug编号。
- 发布分支:用于发布版本的分支,命名为release/版本号。
2.4 版本发布流程- 开发人员从develop分支创建功能分支,开发和测试功能。
- 开发完成后,将功能分支合并到develop分支。
- 当develop分支中的功能积累到一定程度时,从develop分支创建发布分支。
- 在发布分支上进行测试、修复bug,并最终合并到master分支发布版本。
- 同时将master分支的代码合并到develop分支,保证两个分支的同步。
2.5 版本文档管理每个版本需要编写相应的版本文档,包括版本号、发布日期、主要改动内容、已知问题等信息,方便用户了解和使用软件。
3. 版本管理流程3.1 新建项目创建新项目时,使用版本控制工具创建项目仓库,并上传初始代码。
软件版本管理规范
软件版本管理规范软件版本管理规范一、引言随着信息技术的快速发展,软件已成为各行各业运营和发展的重要支撑。
软件版本管理是软件开发过程中不可或缺的一环,对于保证软件质量、控制变更、促进团队协作和知识共享具有重要意义。
为了规范公司内部的软件版本管理,提高软件开发效率和质量,降低维护成本,特制定本管理规范。
二、版本管理规范目标本管理规范旨在明确软件版本管理的规范目标,包括以下几个方面:1.保证软件版本的准确性和一致性;2.控制软件版本的变更,保证变更的合理性和规范性;3.促进团队成员之间的协作和知识共享;4.为软件配置管理提供基础数据支持;5.提高软件开发效率和质量,降低维护成本。
三、版本管理规范原则在进行软件版本管理时应遵循以下原则:1.唯一性原则:每个版本应具有唯一的标识符,以便区分和管理;2.标准化原则:版本号应遵循通用的编码规则,以便于阅读和理解;3.实时更新原则:版本应随着软件功能的增加、修改或删除而实时更新;4.记录完整原则:版本变更的历史记录应完整保存,以便追踪和查询;5.安全性原则:版本管理过程中应确保数据的安全性,避免泄露和损坏。
四、版本管理规范流程软件版本管理应遵循以下流程:1.制定版本计划:根据软件开发计划,制定相应的版本计划,明确各阶段的版本发布时间和内容;2.创建版本:按照计划,创建各阶段的版本,并为每个版本分配唯一的标识符;3.版本审批:在创建版本后,应将版本提交给相关人员进行审批,以确保版本的准确性和完整性;4.版本发布:经过审批后,将版本发布至指定平台或范围,以供用户下载和使用;5.版本更新:在软件开发过程中,如需对已发布版本进行修改或升级,应按照本管理规范进行相应的变更管理;6.版本维护:对于已发布版本,应定期进行维护和更新,以确保版本的稳定性和安全性;7.版本归档:在完成特定阶段或项目的开发后,应对相应版本的文档、代码等进行归档和备份。
五、版本管理规范措施为确保本管理规范的有效实施,应采取以下措施:1.培训宣传:组织公司内部培训和宣传活动,让全体员工了解并掌握本管理规范的相关规定和要求;2.制定规范:制定详细的软件版本管理规范,明确各环节的具体操作流程和标准;3.配置管理工具:选择合适的配置管理工具,如Git、SVN等,用于进行版本的存储、追踪和管理;4.设立专责机构:设立专门的版本管理机构或岗位,负责执行和管理公司的软件版本管理工作;5.监督检查:定期对公司的软件版本管理工作进行监督和检查,发现问题及时处理和改进。
软件版本管理规范
软件版本管理规范软件版本管理规范1.目的与范围为规范软件版本的规划、构建、移交和发布过程,特制定本规范。
本规范适用于富岛所有软件版本的管理过程。
2.制定月度版本计划1、每月初,产品经理制定本月的版本计划。
版本计划中应包含转测试版本及最终发布生产版本。
2、版本计划内容包含:版本号、版本用途、版本主要变动点、计划发布时间、发布责任人,参见《版本计划模板》。
3、版本范围必须来自文档化的需求与问题清单,口头传递的内容不得作为工作依据。
4、产品经理、测试经理、交付服务代表一起评审确认版本计划。
3.版本构建1、每个软件子系统应指定版本发布负责人,负责编译、构建版本。
2、构建版本时必须保证所有相关代码都已提交到配置库。
发布负责人从配置库主线取最新源代码,使用的编译、构建工具的型号和版本号必须统一。
3、不得随意变更编译构建工具的版本,如有工具切换或升级需求需提出建议,并评估切换的影响,经过产品经理同意后方可执行切换。
4.版本转测试1、版本发布负责人组织研发自测,输出研发自测报告。
2、版本发布负责人输出《版本转测试说明》,说明版本基本信息、主要变更点、自测结果及测试建议。
3、版本发布负责人将完成开发自测的版本、配套的手册、自测报告、版本转测试说明一起归档到服务器。
4、版本发布负责人邮件发送转测试通知,并将版本转测试说明附在邮件中。
通知发送给产品经理、测试经理、质量代表,抄送项目全体成员。
5.版本发布1、版本正式发布给生产前,版本发布负责人组织版本发布评审。
2、版本发布时需提供《版本说明书》,《版本测试报告》、《版本遗留缺陷清单》。
3、版本发布负责人邮件发送版本发布评审通知。
参与评审的角色包括:产品经理、交付服务代表、测试经理、质量代表、制造代表。
4、版本发布负责人组织召开版本发布评审会议,对版本需求实现情况、测试充分性、遗留问题进行评估,并给出是否同意发布的结论。
所有参与评审的角色均需参加会议。
5、如果评审结论为通过,版本发布责任人通知信息化工程师将版本上传到版本服务器。
项目软件版本号管理规范
项目软件版本号管理规范历史修改记录一. 目的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。
软件版本管理规范标准
软件版本管理规范V1.0。
0文档版本变更记录:目录前言21 范围22 术语和定义32.1 软件32.2 产品软件32。
3 演示软件33 软件版本命名规则33.1 软件版本命名组成33.2 产品软件版本命名33。
3 演示软件版本命名43。
4 正式版本号的升级规则43.4.1 软件版本升级规则43。
4。
2 演示版本升级规则53.5 版本的安装文件命名规则及存放路径54 软件版本发布流程55 管理条例66 附录6前言为规范部门产品软件版本的管理与控制,保证产品版本的有效与质量,制定本标准。
本标准由移动金融事业部拟制。
本标准于2015年6月首次发布.软件版本管理规定1范围本标准规定了移动银行事业部产品软件版本的控制与管理。
本标准适用于移动银行事业部产品软件版本的控制与管理。
2术语和定义下列定义适用于本标准。
2.1软件指与产品相关的所有软件,可以分为产品软件和演示软件.2.2产品软件已签订合同,有明确交付日期的产品。
2.3演示软件处于研发阶段,并未正式投入生产的应用。
3软件版本命名规则3.1软件版本命名组成产品的正式软件版本命名由四部分组成。
第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。
产品的演示版本命名由四部分组成。
第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。
3.2产品软件版本命名产品软件版本的命名规则如下所示:产品标识VX.Y.Z_YYMMDD版本号和时间之间以下划线分隔。
具体含义见表1。
表1 软件版本命名规则描述例如:信用卡V1.0.0_150501 ,表示信用卡V1.0版本在2015年5月1日做了一次修订并发布了版本。
3.3演示软件版本命名演示软件版本的命名规则如下所示:产品标识VX。
Y。
Z_YYMMDDdemo版本号和时间之间以下划线分隔.具体含义见表2。
表2 演示软件版本命名规则描述例如:信用卡申请V1。
0。
0_150501demo ,表示信用卡申请demo软件的V1。
软件产品版本管理规范完整版
程序文件、版本需求相关 记录、开发相关记录、测 试相关记录、版本情况及 已知问题说明、使用反馈 记录、发布确认记录等
6
程序名命名规则:ቤተ መጻሕፍቲ ባይዱ
项目名称_产品名称+版本号_地区名首大写拼音(或其它备注,无就不写) 例:Aries_RZAPP1.1.18_0103_SH;Ow1.1.30.0104_BJ;Odnis1.1.20.0106
5
04 版本存档方式
测试过程版本——共享
测试通过版本——SVN
程序、版本需求相关记录、开 发相关记录、测试相关记录等
软件产品版本规范
版本规范
目 录
01 目的概述 02 版本梳理过程 03 版本命名规则 04 版本存档方式
2
01 目的概述
为什么要进 行规范?
统一规则,清晰、直观,利于继承性与归档管理。
在哪些方面 规范?
测试过程版本,测试通过版本。
3
02 版本梳理过程
4
03 版本命名规则
版本号格式规则:
主版本号:当功能模块有较大的变动,需要进行立项讨论,产品在立项成功后确定主版本号; 次版本号:用流水号表示,次版本号变更由三种情况确定 (1、需求重大变更;2、产品里程碑变换;3、产品重大缺陷导致需要短期强制要求实施更新); 修订版本号:程序迭代的流水号,属于日常修复BUG或者代码优化等,研发人员自主; 日期版本号:取日月 对于主版本号、次版本号、修订版本号三者,上一级有变动时,下一级版本号要归1。
(完整word版)软件版本管理规范
软件版本管理目录1。
引言 (1)1.1。
目的 (1)1.2. 范围 (1)1。
3。
术语定义 (1)1。
4。
参考资料 (2)1.5。
版本控制记录 (2)1.6。
版本更新记录 (3)2。
版本管理 (4)2.1. 版本标示方法 (4)2.1.1。
正式版本 (4)2。
2。
目录结构 (5)2。
3。
文档的存放 (5)2。
3。
1. ........................................................................................ 开发文档的存放52.3.2。
源代码的存放 (6)2.3.3. SQL的语句存放 (6)2。
3.4。
........................................................................................ 发行文档的存放7 2。
4. 配置管理流程 (7)2。
5。
权限控制的管理 (8)3. 更新管理 (9)3.1. 源程序的修改 (9)3.2。
版本升级 (10)3.2。
1. 版本升级原则 (10)3。
3. 文档的变更 (11)4。
备份管理 (12)1.引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理,保证任何时间都可以取到正确的版本以及版本的组合。
版本控制的主要功能是记录开发过程中的每一次修改,让开发的工作可以随时检查过往历史记录和获得正确版本,是系统的成长记录。
1.1. 目的本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。
1.2. 范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容,包括:●版本标识方法●软件系统数据的存放●文档的修改控制●文档的备份制度1.3. 术语定义SCM软件配置管理(Software Configuration Management)缩写SVM软件版本管理(Software Version Management)缩写SVN一个开源的版本控制系统Subversion。
软件版本管理规范V2
4.4.1.1.在软件发布中,会因发布的类型不同而产生不同的发布包。
可能会有以下
几种类型:
产品升级发布: 指在早期版本的基础上提高产品的特征集,当然
也包括更新内容
产品更新发布通常是修复老产品的缺陷如收集一定时间内的产
品缺陷,汇总产生如3.0.1 进行更新发布
补丁发布:补丁(紧急修复)是用来修复产品缺陷或掩饰缺点的。
补丁和更新之间的区别是紧急程度和实施的工作量
4.4.1.2.发布包的主要构成如下,如果是补丁或产品更新发布,发布包简化为程序、
说明性文档和源码
程序
源码
发布说明文档,包括各种readme(测试组提供)
用户(操作)手册(测试组提供)
全套项目文档
配置说明文档
其它
4.4.2.发布评审(Review)
对于软件正式发布,测试工程师要组织各相关人员召开评审会由系统工程师支持审核和检查,以保证发布的产品满足用户的需求及公司的各类规范
软件发布评审
项目文档的检查
源代码和安装程序的检查
4.4.3.软件产品正式版本发布流程如下
4.4.3.1.发布准备发布之前,所有程序由测试工程师进行确认测试;检查BUG系
统内登记的所有bug都已经被解决,或者遗留的bug不影响系统的使用,
如果有严重bug未解决则不能发布;程序打包前做测试。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
次制订部门研发部版次A001制订日期2008-12-02 软件版本管理规范制订:刘志敏审核:______批准:______文件修订记录文件名工程设计变更管理程序编号F-02-002称版次修订内容修改页次修订日期修订者备注A00 新版本发行2007-10-7 刘志敏A01 流程优化后进行相应修订2008-12-02 姚旋次制订部门研发部版次A001制订日期2008-12-02目录1.目的 (3)2.适用范围 (3)3.权责 (3)3.1.版本管理员 (3)3.2.软件系统架构师 (4)3.3.软件工程师 (4)3.4.软件主管 (5)3.5.软件测试工程师 (5)4.作业流程 (5)4.1.流程及发布 (5)4.2.注意事项 (6)4.3.软件归档控制 (6)4.4.软件发布控制 (7)4.4.1.发布内容 (7)4.4.2.发布评审(Review) (7)4.4.3.软件产品正式版本发布流程如下 (8)5.相关文件 (9)5.1.研发设计开发控制程序 (9)5.2.项目计划 (9)6.记录表单 (9)6.1.软件概要设计评审检查表 (9)6.2.软件详细设计评审检查表 (9)6.3.软件集成测试报告评审检查表 (9)6.4.软件发布评审检查表 (9)6.5.SVN月度稽查检查表 (9)7.附件 (9)次制订部门研发部版次A001制订日期2008-12-021.目的1.1.标准化软件工作流程1.2.软件开发过程中代码安全1.3.标准化配置管理,规范开发文档输入输出1.4.软件版本控制提高软件发布质量1.5.对配置管理进行跟进,调查,改善, 为纠正预防提供方向2.适用范围所有软件版本管理员、软件系统架构师、软件工程师、软件测试工程师、软件技术总监/副总监、软件主管3.权责3.1.版本管理员1)负责版本服务器的日常维护2)版本服务器用户的添加,删除,修改访问权限3)版本服务器数据库的建立4)版本服务器新项目模块库建立5)依据系统架构师对新建项目的模块划分,设置组成员版本服务器工作权限6)编译检查发布正式版本,确保代码是最新可用的7)项目完成对代码进行编译检查,清理所有项目文档并归档8)文档资料的定时备份.(完成归档的项目资料按月备份)9)协助解决版本服务器用户使用过程中所遇到的问题10)对SVN服务器使用情况进行稽查提交《SVN月度稽查报告检查表》次制订部门研发部版次A001制订日期2008-12-023.2.软件系统架构师1)对软件项目进行模块划分2)协同版本管理员在版本服务器上进行目录设置,保证代码安全3)检查组成员的上传代码,保证代码的质量4)按项目计划时间点,及时提交软件项目文件5)对单元测试中发现的问题及时进行处理.并在服务器做好备份工作6)发布集成测试软件版本和集成测试报告给测试组做集成测试验证7)对后期测试发现的bug要及时跟进安排解决,对修改的代码及时上传服务器并添加修改说明8)正式版本发布,按标准更新版本号,确保所有正式发布版本唯一9)项目完成对所有代码和文档做检查,提交版本管理员;对模块的代码组织进行模块化评审,归档,并提交相应说明文档3.3.软件工程师1)负责对软件功能模块的编码工作2)工作前对本地工作目录的代码进行检查是否为最新版本,确认后方可进行工作,否则必须先进行本地工作目录的更新3)工作完成后及时将本地机工作目录下的代码进行checkin,避免代码丢失造成的损失4)每次涉及到版本机的checkin都必须附上版本说明(说明修改的内容,新增功能,解决的bug等)5)服从系统架构师配置管理工作安排,文件代码要及时归档6)维护工作涉及代码的修改必须上传版本服务器,并且附修改说明(明确为什么修改,修改哪些地方,修改日期,修改人等信息)次制订部门研发部版次A001制订日期2008-12-023.4.软件主管1)负责把关产品的软件设计,确保设计满足要求, 参与《新产品需求说明书》评审2)参与软件概要设计、详细设计、编码工作、单元测试、集成测试,对各环节进行检查评审,确保工作质量3)审批本组成员输出资料,确保输出资料准确无误4)把关软件《概要设计》、《详细设计》检查评审,确保设计满足需求5)把关软件《单元测试报告》、《集成测试报告》检查评审,确保发布到测试组的软件质量6)规划参与项目的本组成员,估计项目进度要求的各里程碑7)协助、指导本组项目成员参考研发服务器上项目计划模板制作《软件开发计划进度表》8)审核《软件开发计划进度表》,确保时间利用最大化9)督导本组成员将项目计划任务落实到月、周工作计划中10)负责测试用例库建设,并监督测试流程,把关测试质量3.5.软件测试工程师1)协助系统架构师和软件工程师完成软件单元测试,集成测2)软件系统测试,对于测试中发现的bug与对应软件工程师沟通并上TD服务器3)软件测试通过后组织系统架构师和相关人员召开发布评审会4.作业流程4.1.流程及发布详见《软件组工作流程》次制订部门研发部版次A001制订日期2008-12-024.2.注意事项a)下班前更新时,不要把没有编译成功的程序文件迁入版本服务器b)添加修改版本服务器上的文件,必须添加注释说明c)本机除了开发工程目录外,还需建一个中间工程目录,目录下面可以根据自己需要新增子目录,每次工作前,先更新中间工程目录,使它与版本服务器上的工程文件完全一致d)备份文件代码迁入版本服务器前,必须对文件进行编译检查e)标签和分支的命名必须遵照标准进行(产品完整型号+版本+分支名称)f)备份文件归档时,将代码中编译冗余文件清除(如:.a;.o等等)g)产品到发布版本给测试的阶段,要修改版本服务器代码必须有系统工程师或相关人员审核确保代码的准确h)项目全部源代码仅有管理员和架构师掌握,确保代码安全i)所有代码必须从版本服务器上下载,禁止以其它任何形式传递获取代码j)正式软件必须由版本管理员发布,加强对软件版本的控制4.3.软件归档控制1)开发完成后进行软件版本归档,内容主要有:软件名称(中、英文),版本号,编译后的可执行文件,源代码和文档(需求分析文档,概要设计,详细设计,测试用例和bug报告等)2)系统架构师确定要发布的版本号,然后由版本管理员检查是否满足版本提交条件,最后由版本管理员确认后,将该版本存档3)软件版本升级变更时,由系统工程师根据软件工程师提交的源代码和文档在版本服务器进行更新检查并知会版本管理员,然后由版本管理员检查是否满足版本提交条件,最后由版本管理员确认后,再将该版本存档4)当发生用户需求变更时,系统架构师提交程序需求变更设计说明,并另行标明在源程序和文档中何处进行了更改,最终由软件主管审核通过后,将该版本存档次制订部门研发部版次A001制订日期2008-12-025)确定每个版本责任人,同一软件可以有不同时期的责任人6)版本提交归档后,软件的任何修改需先向管理人员申请,由版本管理员提交该版本,开发人员不能自行使用开发时使用的源程序7)软件提交同时需附上编译说明文档,内容包括:编译环境,编译工具,编译步骤等4.4.软件发布控制4.4.1.发布内容4.4.1.1.在软件发布中,会因发布的类型不同而产生不同的发布包。
可能会有以下几种类型:➢产品升级发布: 指在早期版本的基础上提高产品的特征集,当然也包括更新内容➢产品更新发布通常是修复老产品的缺陷如收集一定时间内的产品缺陷,汇总产生如3.0.1 进行更新发布➢补丁发布:补丁(紧急修复)是用来修复产品缺陷或掩饰缺点的。
补丁和更新之间的区别是紧急程度和实施的工作量4.4.1.2.发布包的主要构成如下,如果是补丁或产品更新发布,发布包简化为程序、说明性文档和源码➢程序➢源码➢发布说明文档,包括各种readme(测试组提供)➢用户(操作)手册(测试组提供)➢全套项目文档➢配置说明文档➢其它4.4.2.发布评审(Review)对于软件正式发布,测试工程师要组织各相关人员召开评审会由系统工程师支持审核和检查,以保证发布的产品满足用户的需求及公司的各类规范次制订部门研发部版次A001制订日期2008-12-02 ➢软件发布评审➢项目文档的检查➢源代码和安装程序的检查4.4.3.软件产品正式版本发布流程如下4.4.3.1.发布准备发布之前,所有程序由测试工程师进行确认测试;检查BUG系统内登记的所有bug都已经被解决,或者遗留的bug不影响系统的使用,如果有严重bug未解决则不能发布;程序打包前做测试4.4.3.2.测试工程师组织软件发布评审,由软件系统工程师主持评审4.4.3.3.源码、文档入库编译构建脚本和所有源代码;文档包括需求说明、设计说明、计划,测试文档,操作手册、使用demo等4.4.3.4.系统工程师进行程序打包标记源码、文档版本tag4.4.3.5.编写发布说明readme.txt Read me的内容应该包括产品版本说明;本次发布包含的文件包、文档说明;本次发布包含或者新增的功能特性说明;遗留问题及影响说明;版权声明以及其他需要说明的事项4.4.3.6.正式发布通知通知开发、测试、市场、销售各相关部门并附上发布说明和介绍4.4.3.7.后续工作软件发布后,在使用过程中可能还会发现一些bug,由公司BUG管理系统跟踪。
在不影响正常使用的情况下,这些bug将在下一版本发布时解决;如果bug严重影响使用,必须按照流程重新发布4.4.3.8.临时发布软件产品未正式发布前,可能需要一个临时版本供软件工程师或者用户应急使用,这时候需要临时发布一个版本。
这个版本只包括基本的程序包和必要的使用说明。
临时发布需要通知相关开发、测试工程师;系统工程师需要为源码、文档打tag标记次制订部门研发部版次A001制订日期2008-12-02 5.相关文件5.1.研发设计开发控制程序5.2.项目计划6.记录表单6.1.软件概要设计评审检查表6.2.软件详细设计评审检查表6.3.软件集成测试报告评审检查表6.4.软件发布评审检查表6.5.S VN月度稽查检查表7.附件《软件组工作流程》。