软件发布管理系统流程要求规范.docx
- 文档编号:5227801
- 上传时间:2022-12-14
- 格式:DOCX
- 页数:7
- 大小:269.48KB
软件发布管理系统流程要求规范.docx
《软件发布管理系统流程要求规范.docx》由会员分享,可在线阅读,更多相关《软件发布管理系统流程要求规范.docx(7页珍藏版)》请在冰豆网上搜索。
软件发布管理系统流程要求规范
本文从网络收集而来,上传到平台为了帮到更多的人,如果您需要使用本文档,请点击下载,另外祝您生活愉快,工作顺利,万事如意!
软件发布管理流程规范
编制:
审核:
日期:
版本:
编号:
密级:
修改历史
修改时间
修改人
修改原因
版本
1.目标
软件的发布过程,需要形成有序的良性循环。
否则,各环节流转中容易发生相互等待、被动接应的局面。
无形中,不断增加了沟通成本,扩大了软件的风险。
且对后期造成的影响并不能够完全预知、完全估量。
因此,根据公司内部前期已有的习惯,总结过去产品的发布经验,分析统计结果后,特制定本发布过程规范。
预期达到如下目的:
1、减少交叉沟通。
通过将发布过程流程化,使每一个环节的执行者都非常清楚自己的产入产出,受谁的影响,将影响谁。
当遇到困难时,能明确的定位寻找到关键人物沟通解决。
避免当需要获取一件事情的进展情况时,需要广泛征询才能掌握的现象。
减少交叉沟通成本。
2、提高工作预见性。
流程一旦启动,流程中的所有人员便被触动。
各环节执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”,主动提前做出安排、准备,避开人力、时间等资源上的冲突。
且一旦发现冲突,便能立刻“报警”,报得越早,越能提前应对,减少损失。
3、提高可控性。
软件发布就像道路交通。
交通电台有了可靠的消息渠道(取决于上述“1、减少交叉沟通”),便能随时掌握路面交通状况,配合可预见的行车计划(取决于上述“2、提高工作预见性”),当然更能向车队提供有价值的消息。
因此,车队领导能做出更有控制力的指令,各车队协调行驶,整个交通自然更受控。
一条早已设计好的行车路线,加上提前准备就绪的车队人马,再加上行进途中密切配合的交通电台。
与没有固定线路,需要时才去调配车马,电台信息又不畅的队伍相比,哪一个更能成功到达目的地?
2.发布流程
本章节的流程图中,将使用下列简称。
1、需求组(人):
包括需求总负责人(或PM)、各模块需求负责人。
2、开发部(人):
包括技术开发部全体成员。
3、配置管理员:
或简称SCM,包括技术研发部的配置管理组成员。
4、测试组(人):
包括测试组所有固定资源、临时调配资源。
5、安装组(人):
包括负责公司内部、客户现场的安装、调试的人员。
6、客户:
所有使用我司产品的用户。
2.1.补丁发布流程
软件产品的某个主版本向外发布给客户使用后,发现了错误。
若这个错误给客户造成了很大的影响,等不及下一主版本,需要立刻修正,我们就需要发布补丁(对应VSS上的存放目录:
Patch[X.Y])(注:
所有补丁要求合并入下一主版本)。
流程图如下所示。
2.2.主版本发布流程
主版本的发布流程,与补丁的发布流程相比,参与的职能部门个数、次数明显增多,且设置的检查点也随之增多。
重要的一点,引入客户监督。
改变目前的“直到整个版本完全下流水线后,才提交客户试用”的方法。
采取“我们主动争取客户全程参与”的方法,每完成一个变更,不一定要待版本中的所有变更完成,立刻放上客户使用的测试环境,请客户在线试用并提意见。
(此举依赖公司实现远程测试环境)。
目的:
让客户不仅知道我们在干什么,还知道我们干成什么样,是否满意。
尽量让客户的意见在开发早期提出,越早提出,变更成本越小,且能直接减少后续的补丁发布频率。
流程图如下:
2.3.产品实施流程
为方便大家更加理解软件的整个发布循环过程,在此简单介绍软件通过Release阶段后的实施流程,它包括安装、培训等内容。
具体的规范制度,以实施部门制定的为准。
2.4.VSS管理流程
简单介绍VSS的使用流程如下,具体详细的规则另述。
3.相关资料
3.1软件版本号的命名约定、分支约定
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 发布 管理 系统 流程 要求 规范
![提示](https://static.bdocx.com/images/bang_tan.gif)