软件发布管理系统流程要求规范_第1页
软件发布管理系统流程要求规范_第2页
软件发布管理系统流程要求规范_第3页
软件发布管理系统流程要求规范_第4页
软件发布管理系统流程要求规范_第5页
已阅读5页,还剩6页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、.软件发布管理流程规范编制:审核:日期:版本:编号:密级:.修改历史修改时间修改人修改原因版本.目录1.目标. .42.发布流程 . .42.1.补丁发布流程 .42.2.主版本发布流程 .62.3.产品实施流程 .92.4.vss管理流程 .103.相关资料 . .10.1. 目标软件的发布过程, 需要形成有序的良性循环。否则, 各环节流转中容易发生相互等待、被动接应的局面。 无形中,不断增加了沟通成本, 扩大了软件的风险。且对后期造成的影响并不能够完全预知、完全估量。因此,根据公司内部前期已有的习惯, 总结过去产品的发布经验, 分析统计结果后,特制定本发布过程规范。预期达到如下目的:1、减

2、少交叉沟通。通过将发布过程流程化,使每一个环节的执行者都非常清楚自己的产入产出,受谁的影响,将影响谁。当遇到困难时,能明确的定位寻找到关键人物沟通解决。 避免当需要获取一件事情的进展情况时,需要广泛征询才能掌握的现象。减少交叉沟通成本。2、提高工作预见性。流程一旦启动,流程中的所有人员便被触动。各环节执行人能迅速在早期预算出自己的“参与时间” 、“参与内容”、“参与工作量”,主动提前做出安排、准备,避开人力、时间等资源上的冲突。且一旦发现冲突,便能立刻“报警”,报得越早,越能提前应对,减少损失。3、提高可控性。软件发布就像道路交通。 交通电台有了可靠的消息渠道 (取决于上述“ 1、减少交叉沟通

3、”),便能随时掌握路面交通状况,配合可预见的行车计划 (取决于上述“ 2、提高工作预见性”),当然更能向车队提供有价值的消息。因此,车队领导能做出更有控制力的指令,各车队协调行驶,整个交通自然更受控。一条早已设计好的行车路线, 加上提前准备就绪的车队人马, 再加上行进途中密切配合的交通电台。与没有固定线路, 需要时才去调配车马, 电台信息又不畅的队伍相比,哪一个更能成功到达目的地?2. 发布流程本章节的流程图中,将使用下列简称。1、需求组 ( 人) :包括需求总负责人 ( 或 pm)、各模块需求负责人。2、开发部 ( 人) :包括技术开发部全体成员。3、配置管理员:或简称scm,包括技术研发部

4、的配置管理组成员。4、测试组 ( 人) :包括测试组所有固定资源、临时调配资源。5、安装组 ( 人) :包括负责公司内部、客户现场的安装、调试的人员。6、客户:所有使用我司产品的用户。2.1.补丁发布流程软件产品的某个主版本向外发布给客户使用后, 发现了错误。 若这个错误给客户造成了很大的影响,等不及下一主版本, 需要立刻修正, 我们就需要发布补丁(对应 vss上的存放目录: patchx.y )(注:所有补丁要求合并入下一主版本)。流程图如下所示。.补丁发布流程: 下图中每个方框代表一个进程,括号内描述该进程的具体内容。每个进程均要求相应职位填写补丁签发单。需求组开发部配置管理员测试组开始提

5、出变更请求开发部经理:(1、事先征得需接收任务检查求澄清会的同意,(1、安排开发(1、检查前两个环节填写的签发单是否符合填写要求;检查描述是否再填补丁签发人、预计开发完清晰、时间要求有无冲突;)单。 2、通知开成时间。 2、通知发经理)scm)否检查是否通过?是安排补丁号(1、安排补丁号、发布日期,通常将完成时间相距不远的安排在同一补丁号中。 2、设置 vss权限,根据开发部经理的安排设置。3、通知相关人,开始执行施变更,并公布预计发布日期、实施建议)段阶ahpla段阶ateb段阶esaeler开发人:执行测试组长:制变更(按照要求定测试计划修改代码、文档,(按照签发单,安完成后,按规范存排测

6、试人、预计测放)试完成时间)产生alpha 版(开发部内部可产生多个 alpha 版)安装alpha 测试环境部门内部测试(1、alpha 阶段的测试,相当于单元测试。 2、通知scm)否测试是否通过?是产生beta版安装beta测试环境(1、编写 / 更新补丁安(1、检查相关文档是否已备齐; 2、根据签发单,检查当前补丁号中提装手册; 2、选择测试环出的变更是否都已执行; 3、检查开发人在 checkin/out 的过程中,是否境,安装补丁 beta 版;符合vss管理规范、版本管理规范; 4、根据签发单,制作补丁发行说明3、通知测试组、相关5、关闭 vss权限; 6、编译构建 beta 版

7、;7、通知测试组、安装组,向其人,同时刷新“公司内提交该补丁的书面签发单)部产品试用环境一览表”白板)验收测试(1、beta 阶段的测试,相当于集成测试2、通知相关人测试结果, 含邮件、签发单电子格式的回复。若测试通过,则还包括在书面签发单上签名。)否测试是否通过?是产生release版(1 、检查测试结果是否已全部通过;2、检查提交文档是否已齐全;3、标识、备份、记录。 4、通知相关人。等等 .详见:版本发布前的 checklist ;)分发release版(1、根据安装组的工作计划、根据各客户现行情况,组合出不同的安装包; 2、分发给当次执行安装任务的人。3、通知安装组。结束(转入产品实施

8、流程).2.2.主版本发布流程主版本的发布流程, 与补丁的发布流程相比,参与的职能部门个数、 次数明显增多,且设置的检查点也随之增多。重要的一点,引入客户监督。改变目前的“直到整个版本完全下流水线后,才提交客户试用”的方法。采取“我们主动争取客户全程参与”的方法,每完成一个变更,不一定要待版本中的所有变更完成,立刻放上客户使用的测试环境,请客户在线试用并提意见。 (此举依赖公司实现远程测试环境) 。目的:让客户不仅知道我们在干什么, 还知道我们干成什么样, 是否满意。 尽量让客户的意见在开发早期提出,越早提出,变更成本越小,且能直接减少后续的补丁发布频率。流程图如下:.主版本发布流程图需求人开

9、始提出变更请求(1、填写自己负责的 产品名 版本号开发计划清单 / 测试清单/ 变更清单(以下简称清单); 2、请求召开需求澄清会否参与澄清会( 对清单释疑)评审通过?是宣布变更计划(由需求总负责人 /pm 宣布: 1、通知 scm检入变更计划; 2、通知开发部经理接收任务;段 3、通知客户)(完成时限:上一主版本正式阶对外发行前。)求需.(下图中每个方框代表一个进程,括号内描述该进程的具体内容。每个进程均要求有物理产出。)开发人配置管理员测试人 / 安装人参与澄清会参与澄清会( 对清单提出质疑,预估( 对变更请求提出质颖,开发所需工时)预估测试所需工时)检入变更计划(1、检查有无通过澄清会;

10、2、将一个产品中,各需求人提出的清单中,已通过澄清会的内容,合并成一份。从此本流程仅使用合并后的清单。3、存入 vss的固定目录、标 label ;5、通知开发部经理、测试组长客户重新进入开发阶段提供发行说明内容(各需求人提供自己所辖范围内的说明内容,参照样本填写)段阶发开需求确认测试(确认功能是否满足需求)段阶ahpla开发部经理:接收任务(1、安排开发人、预计开发完成时间。 2、通知相关人)开发人:执行变更(1、开发人执行变更; 2、定期向项目管理组汇报开发进展)产生alpha 版(可产生若干个 alpha 版,直至所有变更完成)安装alpha 测试环境部门内部测试(alpha 阶段的测试

11、,相当于单元测试,确认功能是否完整、是否正常运行、相关手册是否最新)为开发部门设置权测试组长:制定测试计划限(按照清单,制定测试大纲、测试计划)收集、审核发行说明内容制作发行说明网页( 根据收集并审核通过版本测试的内容,制作成适合客(1、根据测试计划测户在线阅读的网页等格试;2、写安装手册)式,变更清单除外)测试通过?否是否是否参与?是需求确认测试(确认功能是否满足要求,尽可能提出改进意见).主版本发布流程图 ( 续)需求人开发人配置管理员测试人 / 安装人客户物理配置审核(1、各 文档有无 ; 2、有无全部 通 等等, checklist )产生beta版(1、关 vss 限; 2、 lab

12、el;3 、 构建 beta 版、 份、通知相关人; 3、制作 更清 网 .等等, 行列表)安装beta测试环客 是否否参与 ?境(公司内部用)是(1、根据 划、安装手册,安装 安装beta测试环 境( 可能有多套 境) , 安装 程是境(客 用)否正确; 2、通知(1、根据客 需要,scm、 、刷新 安装 境,并 “公司内部 品 用行安装; 2、通知 境一 表”)scm、各需求 人)验收测试安装记录验收测试(1、 品 行(1、根据 划 、 用,包 ;2、回复 果括性能、功能方(含 件、上 vss、面的 ,尽可 面三种方式)能提出意 )段阶ateb段阶esaeler 通 ?是物理配置审核(1、

13、各 文档有无 ; 2、有无全部 通 ; 3、 更清 网 。 4、下一主版本 划已 妥等等, checklist )产生release版(1 、 、 份、 。 2、通知相关人。等等 . :版本 布前的checklist ;)分发release版(1、根据安装 的工作 划、根据各客 行情况, 合出不同的安装包; 2、分 当次 行安装任 的人。 3、通知安装 。 束( 入 品 施流程)否,重新 入开 段.2.3.产品实施流程为方便大家更加理解软件的整个发布循环过程,在此简单介绍软件通过 release 阶段后的实施流程,它包括安装、培训等内容。具体的规范制度,以实施部门制定的为准。产品实施流程 (为

14、方便理解,下图作出简单介绍。具体详细的流程以实施部门制定的为准。支持部配置管理员客户开始实施经理:制定实施计划提出意见(制定具体的实施计划,含:时间、地点、人(对实施计划表示认可,或物、实施内容、实施策略。)提出调整意见)分发release版(根据实施计划,分发出当次实施所需产品、相关文档)实施人:准备(指前期准备工作,包括:与客户约定时间、安装包整理、任务书编写、提交说明文档给客户. 等等一切能提前在公司完成的工作)否实施人:执行计划配合执行实施人:反馈执行结果(1、通知相关人。 2、返回相关文档。例如:特定用途备份文件、客户签字后的任务书等。3、记录结果。其中,安装记录是必不可少的,以便为下一次实施提供线索。)执行成功?是结束.2.4.vss管理流程简单介绍 vss的使用流程如下,具体详细的规则另述。vss管理流程1、库结构管理scm:规划目录、scm:建库、分配各用户:上传、下存放规则、权限规权限载则(经过评审)2、文件存储管理scm:定义命名规各用户:按统一规scm:定期抽查、则则命名,保持更新清理3、用户、权限管理新用人部门经理:提出scm:新增用户(1、新增帐号; 2、分配权同(1、提出新增用户要求;限;3、通知用户本人及部门经事2、提出

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论