软件版本管理规范V2.docx
- 文档编号:29935734
- 上传时间:2023-08-03
- 格式:DOCX
- 页数:8
- 大小:18.97KB
软件版本管理规范V2.docx
《软件版本管理规范V2.docx》由会员分享,可在线阅读,更多相关《软件版本管理规范V2.docx(8页珍藏版)》请在冰豆网上搜索。
软件版本管理规范V2
软件版本管理规范
制订:
刘志敏
审核:
______
批准:
______
文件修订记录
文件名称
工程设计变更管理程序
编号
F-02-002
版次
修订内容
修改页次
修订日期
修订者
备注
A00
新版本发行
2007-10-7
刘志敏
A01
流程优化后进行相应修订
2008-12-02
姚旋
1.目的
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月度稽查报告检查表》
3.2.软件系统架构师
1)对软件项目进行模块划分
2)协同版本管理员在版本服务器上进行目录设置,保证代码安全
3)检查组成员的上传代码,保证代码的质量
4)按项目计划时间点,及时提交软件项目文件
5)对单元测试中发现的问题及时进行处理.并在服务器做好备份工作
6)发布集成测试软件版本和集成测试报告给测试组做集成测试验证
7)对后期测试发现的bug要及时跟进安排解决,对修改的代码及时上传服务器并添加修改说明
8)正式版本发布,按标准更新版本号,确保所有正式发布版本唯一
9)项目完成对所有代码和文档做检查,提交版本管理员;对模块的代码组织进行模块化评审,归档,并提交相应说明文档
3.3.软件工程师
1)负责对软件功能模块的编码工作
2)工作前对本地工作目录的代码进行检查是否为最新版本,确认后方可进行工作,否则必须先进行本地工作目录的更新
3)工作完成后及时将本地机工作目录下的代码进行checkin,避免代码丢失造成的损失
4)每次涉及到版本机的checkin都必须附上版本说明(说明修改的内容,新增功能,解决的bug等)
5)服从系统架构师配置管理工作安排,文件代码要及时归档
6)维护工作涉及代码的修改必须上传版本服务器,并且附修改说明(明确为什么修改,修改哪些地方,修改日期,修改人等信息)
3.4.软件主管
1)负责把关产品的软件设计,确保设计满足要求,参与《新产品需求说明书》评审
2)参与软件概要设计、详细设计、编码工作、单元测试、集成测试,对各环节进行检查评审,确保工作质量
3)审批本组成员输出资料,确保输出资料准确无误
4)把关软件《概要设计》、《详细设计》检查评审,确保设计满足需求
5)把关软件《单元测试报告》、《集成测试报告》检查评审,确保发布到测试组的软件质量
6)规划参与项目的本组成员,估计项目进度要求的各里程碑
7)协助、指导本组项目成员参考研发服务器上项目计划模板制作《软件开发计划进度表》
8)审核《软件开发计划进度表》,确保时间利用最大化
9)督导本组成员将项目计划任务落实到月、周工作计划中
10)负责测试用例库建设,并监督测试流程,把关测试质量
3.5.软件测试工程师
1)协助系统架构师和软件工程师完成软件单元测试,集成测
2)软件系统测试,对于测试中发现的bug与对应软件工程师沟通并上TD服务器
3)软件测试通过后组织系统架构师和相关人员召开发布评审会
4.作业流程
4.1.流程及发布
详见《软件组工作流程》
4.2.注意事项
a)下班前更新时,不要把没有编译成功的程序文件迁入版本服务器
b)添加修改版本服务器上的文件,必须添加注释说明
c)本机除了开发工程目录外,还需建一个中间工程目录,目录下面可以根据自己需要新增子目录,每次工作前,先更新中间工程目录,使它与版本服务器上的工程文件完全一致
d)备份文件代码迁入版本服务器前,必须对文件进行编译检查
e)标签和分支的命名必须遵照标准进行(产品完整型号+版本+分支名称)
f)备份文件归档时,将代码中编译冗余文件清除(如:
.a;.o等等)
g)产品到发布版本给测试的阶段,要修改版本服务器代码必须有系统工程师或相关人员审核确保代码的准确
h)项目全部源代码仅有管理员和架构师掌握,确保代码安全
i)所有代码必须从版本服务器上下载,禁止以其它任何形式传递获取代码
j)正式软件必须由版本管理员发布,加强对软件版本的控制
4.3.软件归档控制
1)开发完成后进行软件版本归档,内容主要有:
软件名称(中、英文),版本号,编译后的可执行文件,源代码和文档(需求分析文档,概要设计,详细设计,测试用例和bug报告等)
2)系统架构师确定要发布的版本号,然后由版本管理员检查是否满足版本提交条件,最后由版本管理员确认后,将该版本存档
3)软件版本升级变更时,由系统工程师根据软件工程师提交的源代码和文档在版本服务器进行更新检查并知会版本管理员,然后由版本管理员检查是否满足版本提交条件,最后由版本管理员确认后,再将该版本存档
4)当发生用户需求变更时,系统架构师提交程序需求变更设计说明,并另行标明在源程序和文档中何处进行了更改,最终由软件主管审核通过后,将该版本存档
5)确定每个版本责任人,同一软件可以有不同时期的责任人
6)版本提交归档后,软件的任何修改需先向管理人员申请,由版本管理员提交该版本,开发人员不能自行使用开发时使用的源程序
7)软件提交同时需附上编译说明文档,内容包括:
编译环境,编译工具,编译步骤等
4.4.软件发布控制
4.4.1.发布内容
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未解决则不能发布;程序打包前做测试
4.4.3.2.测试工程师组织软件发布评审,由软件系统工程师主持评审
4.4.3.3.源码、文档入库编译构建脚本和所有源代码;文档包括需求说明、设计说明、计划,测试文档,操作手册、使用demo等
4.4.3.4.系统工程师进行程序打包标记源码、文档版本tag
4.4.3.5.编写发布说明readme.txtReadme的内容应该包括产品版本说明;本次发布包含的文件包、文档说明;本次发布包含或者新增的功能特性说明;遗留问题及影响说明;版权声明以及其他需要说明的事项
4.4.3.6.正式发布通知通知开发、测试、市场、销售各相关部门并附上发布说明和介绍
4.4.3.7.后续工作软件发布后,在使用过程中可能还会发现一些bug,由公司BUG管理系统跟踪。
在不影响正常使用的情况下,这些bug将在下一版本发布时解决;如果bug严重影响使用,必须按照流程重新发布
4.4.3.8.临时发布软件产品未正式发布前,可能需要一个临时版本供软件工程师或者用户应急使用,这时候需要临时发布一个版本。
这个版本只包括基本的程序包和必要的使用说明。
临时发布需要通知相关开发、测试工程师;系统工程师需要为源码、文档打tag标记
5.相关文件
5.1.研发设计开发控制程序
5.2.项目计划
6.记录表单
6.1.软件概要设计评审检查表
6.2.软件详细设计评审检查表
6.3.软件集成测试报告评审检查表
6.4.软件发布评审检查表
6.5.SVN月度稽查检查表
7.附件
《软件组工作流程》
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 版本 管理 规范 V2