软件产品发布流程与管理规范

软件产品发布流程与管理规范
第一篇：软件产品发布流程与管理规范
软件产品发布管理流程规范
1.目的
产品的发布主要用于指导从项目到产品，从产品到市场的发布过程，本过程目的是为了有效指导项目组开展产品发布，已实现下列目的：（1）指导发布活动，有效控制产品发布过程（2）有效控制和追踪产品版本
2.角色与职责 1）运营人员：
（1）负责产品发布
（2）组织评审
（3）跟踪需要现场调测的异常产品包验证状态 2）项目负责人：（1）提出发布申请
（2）跟踪异常发布的产品
（3）负责产品移交给市场、销售部门3）产品经理：审核产品发布 4）项目组开发成员：（1）修改完善产品
（2）负责对市场、销售人员进行培训（3）协助测试人员进行验收测试 5）测试人员：负责产品测试
3.定义
1）软件版本正式发布：通过软件测试人员测试验证并符合发布标准的软件版本发布过程。

2)软件版本异常发布:通过软件测试人员测试验证,但测试结果不符合发布标准的软件版本发布过程,可采取软件版本异常发布流程的情形仅限于生产和客户使用现场缺陷修复或现场测试等紧急情况。

4.发布前期 4.1、发布准备
开发人员先要确定发布的准备工作和发布的日期。

准备工作应包含以下内容：
1）原有BUG的是否彻底解决；
2）新增模块在功能上是否达到设计要求；
3）修改了什么，增加了什么；
4）所做的改变带来的影响；
4.2、撰写文档
开发人员确定所发布内容中是否有新增功能。

若有，则需撰写一份需求文档（即功能列表文档），交给测试人员。

否则发送测试通知单，告知测试人员。

需求文档的内容如下：
1）所做的改动有哪些；
2）修改原有BUG或新增模块的设计目标
4.3、全面测试
测试人员在收到测试通知单或需求文档后，应进行全面、完善的测试，如果通过测试，发送测试报告给项目负责人，并修改BUG状态。

否则，将测试结果反馈给开发人员，测试结果中应包含以下内容：1）原有BUG的解决情况或新增模块的BUG情况
2）发现BUG的测试用例
4.4、发布确认
通过系统测试后，测试人员将通过测试后的最新版本提交给配置管理员，并告知项目负责人：
1）项目负责人编写《产品发布说明书》
2）项目负责人通知并协调售前部门安排售前人员提供《用户手册》、《安装手册》，并组织评审，评审通过后，由项目负责人提交给运营人员。

3）项目负责人提交发布申请给产品经理，并通知运营人员开展产品发布前评审，运营人员、测试人员、项目负责人协助开展评审，评审通过后，配置运营人员向产品经理提交评审报告和发布申请进行审批。

4）审批通过后，产品经理告知配置管理员实施发布；审批不通过则放弃本次发布。

5.产品发布
5.1软件版本正式发布流程
5.1.1源码、文档入库
源码包括数据库创建脚本（含静态数据）、编译构建脚本和所有
源代码；文档包括需求、设计、测试文档，安装手册、使用手册、产品变更信息文档、相关联的系统版本号、产品介绍等相关文件。

5.1.2程序打包
开发人员进行程序打包；标记源码、文档版本。

5.1.3发布产品
编写产品发布计划，填写配置项，并执行发布计划（发布产品）。

5.1.4正式发布通知
通知开发、测试、市场、销售各相关部门，并附上产品发布说明和产品介绍。

5.2软件版本异常发布流程
5.2.1运营人员启动软件发布后,如发现软件测试人员提供的测试结果不符合软件发布标准时,可选择重新提交测试,或者申请启动软件版本异常发布流程。

5.2.2项目负责人填写《软件版本异常发布说明》,启动软件版本异常发布流程。

5.2.3软件版本异常发布时,项目组仍须提交程序软件包,产品发布说明,需求变更信息说明等文档。

5.2.4运营人员提交软件异常发布文件给项目负责人及技术部总监审核,技术部总监批准后,即可异常发布软件版本。

5.2.5运营人员按照文件分发要求进行发放和登记。

5.2.6开发人员需对异常发布的软件版本进行跟踪,并确保在预定的期限内该软件版本被正式下发的软件版本替代。

6.后续工作
产品发布后，在使用过程中可能还会发现一些bug。

在不影响正常使用的情况下，这些bug将在下一版本发布时解决；如果bug严重影响使用，必须打补丁或者按照流程重新发布。

第二篇：发布管理流程规范
产品发布管理流程规范
编
制：
审
核：
日
期：
版
本：
编
号：
密
级：
目录
1.目标........................................................................................................................... .........3 2.发布流程........................................................................................................................... .3 2.1.补丁发布流程.............................................................................................................3 2.2.主版本发布流程.........................................................................................................5 2.3.产品实施流程. (8)
2.4.VSS管理流程..............................................................................................................9
3.相关资料........................................................................................................................... .9
1.目标
软件产品的发布过程，需要形成有序的良性循环。

否则，各环节流转中容易发生相互等待、被动接应的局面。

无形中，不断增加了沟通成本，扩大了软件的风险。

且对后期造成的影响并不能够完全预知、完全估量。

因此，根据公司内部前期已有的习惯，总结过去产品的发布经验，分析统计结果后，特制定本发布过程规范。

预期达到如下目的：
1、减少交叉沟通。

通过将发布过程流程化，使每一个环节的执行者都非常清楚自己的产入产出，受谁的影响，将影响谁。

当遇到困难时，能明确的定位寻找到关键人物沟通解决。

避免当需要获取一件事情的进展情况时，需要广泛征询才能掌握的现象。

减少交叉沟通成本。

2、提高工作预见性。

流程一旦启动，流程中的所有人员便被触动。

各环节执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”，主动提前做出安排、准备，避开人力、时间等资源上的冲突。

且一旦发现冲突，便能立刻“报警”，报得越早，越能提前应对，减少损失。

3、提高可控性。

产品发布就像道路交通。

交通电台有了可靠的消息渠道（取决于上述“
1、减少交叉沟通”），便能随时掌握路面交通状况，配合可预见的行车计划（取决于上述“
2、提高工作预见性”），当然更能向车队提供有价值的消息。

因此，车队领导能做出更有控制力的指令，各车队协调行驶，整个交通自然更受控。

一条早已设计好的行车路线，加上提前准备就绪的车队人马，再加上行进途中密切配合的交通电台。

与没有固定线路，需要时才去调配车马，电台信息又不畅的队伍相比，哪一个更能成功到达目的地？
2.发布流程
本章节的流程图中，将使用下列简称。

1、需求组(人)：包括需求总负责人(或PM)、各模块需求负责人。

2、开发部(人)：包括技术开发部全体成员。

3、配置管理员：或简称SCM，包括技术研发部的配置管理组成员。

4、测试组(人)：包括测试组所有固定资源、临时调配资源。

5、安装组(人)：包括负责公司内部、客户现场的安装、调试的人员。

6、客户：所有使用我司产品的用户。

2.1.补丁发布流程
软件产品的某个主版本向外发布给客户使用后，发现了错误。

若这个错误给客户造成了很大的影响，等不及下一主版本，需要立刻修正，我们就需要发布补丁（对应VSS上的存放目录：Patch[X.Y]）（注：所有补丁要求合并入下一主版本）。

流程图如下所示。

补丁发布流程：下图中每个方框代表一个进程，括号内描述该进程的具体内容。

每个进程均要求相应职位填写《补丁签发单》。

需求组开始开发部开发部经理：接收任务（1、安排开发人、预计开发完成时间。

2、通知SCM）配置管理员测试组提出变更请求（1、事先征得需求澄清会的同意，再填《补丁签发单》。

2、通知开发经理）检查（1、检查前两个环节填写的签发单是否符合填写要求；检查描述是否清晰、时间要求有无冲突；）否检查是否通过？是安排补丁号（1、安排补丁号、发布日期，通常将完成时间相距不远的安排在同一补丁号中。

2、设置VSS权限，根据开发部经理的安排设置。

3、通知相关人，开始执行施变更，并公布预计发布日期、实施建议）开发人：执行变更（按照要求修改代码、文档，完成后，按规范存放）测试组长：制定测试计划（按照签发单，安排测试人、预计测试完成时间）产生alpha版（开发部内部可产生多个alpha版）安装alpha测试环境部门内部测试（1、alpha阶段的测试，相当于单元测试。

2、通知SCM）否测试是否通过？是alpha阶段产生Beta版（1、检查相关文档是否已备齐；
2、根据签发单，检查当前补丁号中提出的变更是否都已执行；
3、检查开发人在CheckIn/out的过程中，是否符合VSS管理规范、版本管理规范；
4、根据签发单，制作补丁发行说明
5、关闭VSS权限；
6、编译构建beta版；
7、通知测试组、安装组，向其提交该补丁的书面签发单）安装Beta测试环境（1、编写/更新补丁安装手册；
2、选择测试环境，安装补丁beta版；
3、通知测试组、相关人，同时刷新“公司内部产品试用环境一览表”白板）验收测试（1、beta阶段的测试，相当于集成测试
2、通知相关人测试结果,含邮件、签发单电子格式的回复。

若测试通过，则还包括在书面签发单上签名。

）否测试是否通过？是Beta 阶段产生Release版Release阶段（1、检查测试结果是否已全部通过；
2、检查提交文档是否已齐全；
3、标识、备份、记录。

4、通知相关人。

等等...详见：《版本发布前的checkList》；)分发Release版（1、根据安装组的工作计划、根据各客户现行情况，组合出不同的安装包；
2、分发给当次执行安装任务的人。

3、通知安装组。

结束（转入《产品实施流程》）
2.2.主版本发布流程
主版本的发布流程，与补丁的发布流程相比，参与的职能部门个数、次数明显增多，且设置的检查点也随之增多。

重要的一点，引入客户监督。

改变目前的“直到整个版本完全下流水线后，才提交客户试用”的方法。

采取“我们主动争取客户全程参与”的方法，每完成一个变更，不一定要待版本中的所有变更完成，立刻放上客户使用的测试环境，请客户在线试用并提意见。

（此举依赖公司实现远程测试环境）。

目的：让客户不仅知道我们在干什么，还知道我们干成什么样，是否满意。

尽量让客户的意见在开发早期提出，越早提出，变更成本越小，且能直接减少后续的补丁发布频率。

流程图如下：
主版本发布流程图（下图中每个方框代表一个进程，括号内描述该进程的具体内容。

每个进程均要求有物理产出。

）需求人开始开发人配置管理员测试人/安装人客户提出变更请求（1、填写自己负责的
《[产品名] [版本号]开发计划清单/测试清单/变更清单》（以下简称清单）；
2、请求召开需求澄清会否参与澄清会(对清单释疑)参与澄清会(对清单提出质疑，预估开发所需工时)参与澄清会(对变更请求提出质颖，预估测试所需工时)评审通过？是宣布变更计划（由需求总负责人/PM 宣布：
1、通知SCM检入变更计划；
2、通知开发部经理接收任务；
3、通知客户）（完成时限：上一主版本正式对外发行前。

）检入变更计划（1、检查有无通过澄清会；
2、将一个产品中，各需求人提出的清单中，已通过澄清会的内容，合并成一份。

从此本流程仅使用合并后的清单。

3、存入VSS的固定目录、标Label；
5、通知开发部经理、测试组长需求阶段重新进入开发阶段提供发行说明内容（各需求人提供自己所辖范围内的说明内容，参照样本填写）开发部经理：接收任务（1、安排开发人、预计开发完成时间。

2、通知相关人）为开发部门设置权限测试组长：制定测试计划（按照清单，制定测试大纲、测试计划）开发人：执行变更开发阶段（1、开发人执行变更；
2、定期向项目管理组汇报开发进展）收集、审核发行说明内容产生alpha版（可产生若干个alpha版，直至所有变更完成）安装alpha 测试环境部门内部测试需求确认测试（确认功能是否满足需求）（alpha阶段的测试，相当于单元测试，确认功能是否完整、是否正常运行、相关手册是否最新）是否参与?否制作发行说明网页(根据收集并审核通过的内容，制作成适合客户在线阅读的网页等格式，变更清单除外)是版本测试（1、根据测试计划测试；
2、写安装手册）需求确认测试（确认功能是否满足要求，尽可能提出改进意见）alpha阶段测试通过?是否
主版本发布流程图(续)需求人开发人配置管理员物理配置审核（1、各类文档有无备齐；
2、有无全部测试通过…等等，详见《CheckList》）测试人/安装人客户产生Beta版（1、关闭VSS权限；
2、标Label;
3、编译构建beta版、备份、通知相关人；
3、制作变更清单网页...等等，详见《执行列表》）安装Beta测试环境（公司内部用）（1、根据测试计划、安装手册，安装测试环境(可能有多套环境)，验证安装过程是否正确；
2、通知SCM、测试组、刷新“公司内部产品试用环境一览表”）客户是否参与测试？是否安装Beta测试环境（客户用）（1、根据客户需要，选择安装环境，并进行安装；
2、通知SCM、各需求负责人）验收测试（1、根据测试计划测试；
2、回复测试结果（含邮件、上传VSS、书面三种方式））安装记录验收测试（1、对产品进行测试、试用，包括性能、功能方面的测试，尽可能提出意见）Beta阶段测试通过？是否，重新进入开发阶段物理配置审核（1、各类文档有无备齐；
2、有无全部测试通过；
3、检查变更清单网页。

4、下一主版本计划已备妥…等等，详见《CheckList》）产生Release版（1、标识、备份、记录。

2、通知相关人。

等等...详见：《版本发布前的checkList》；)Release阶段分发Release版（1、根据安装组的工作计划、根据各客户现行情况，组合出不同的安装包；
2、分发给当次执行安装任务的人。

3、通知安装组。

结束（转入《产品实施流程》）
2.3.产品实施流程
为方便大家更加理解软件的整个发布循环过程，在此简单介绍软件通过Release阶段后的实施流程，它包括安装、培训等内容。

具体的规范制度，以实施部门制定的为准。

产品实施流程（为方便理解，下图作出简单介绍。

具体详细的流程以实施部门制定的为准。

支持部开始配置管理员客户实施经理：制
定实施计划（制定具体的实施计划，含：时间、地点、人物、实施内容、实施策略。

）提出意见（对实施计划表示认可，或提出调整意见）分发Release版（根据实施计划，分发出当次实施所需产品、相关文档）实施人：准备（指前期准备工作，包括：与客户约定时间、安装包整理、任务书编写、提交说明文档给客户...等等一切能提前在公司完成的工作）否实施人：执行计划配合执行实施人：反馈执行结果（1、通知相关人。

2、返回相关文档。

例如：特定用途备份文件、客户签字后的任务书等。

3、记录结果。

其中，安装记录是必不可少的，以便为下一次实施提供线索。

）执行成功？是结束
2.4.VSS管理流程
简单介绍VSS的使用流程如下，具体详细的规则另述。

VSS管理流程
1、库结构管理SCM：规划目录、存放规则、权限规则（经过评审）SCM：建库、分配权限各用户：上传、下载SCM：定期抽查、清理、维护
2、文件存储管理SCM：定义命名规则各用户：按统一规则命名，保持更新SCM：定期抽查、清理
3、用户、权限管理SCM：新增用户（1、新增帐号；
2、分配权限；
3、通知用户本人及部门经理）SCM：调整权限（1、根据部门经理的安排，统一调整权限；
2、通知用户本人及部门经理）新同事用人部门经理：提出（1、提出新增用户要求；
2、提出权限要求）老同事用户本人：提出（向部门经理提出调整权限要求）用人部门经理：统一汇总安排离职人事部门：离职通知SCM：销户（1、检查有无未checkIn文件；
2、删除用户；
3、通知部门经理、人事部门）产品备份流程SCM：制定备份策
略（经过评审）SCM：按策略备份SCM：定期公告，供大家取用
3.相关资料
3.1 软件版本号的命名约定、分支约定
第三篇：软件产品登记流程
软件产品登记流程
一、申请软件产品登记的税收优惠政策：
1、软件产品经登记生效后，对增值税一般纳税人销售其自行开发生产的软件产品，按17％的法定税率征收增值税后，对其增值税实际税负超过3％的部分实行即征即退政策。

所退税款由企业用于研究开发软件产品和扩大再生产，不作为企业所得税应税收入，不予征收企业所得税。

2、经认定的软件产品在相关部门办理相关申报后，与该产品相应的技术合同、技术转让可免除营业税。

3、软件产品登记的有效期为五年，有效期满后可申请续延
4、持有软件产品登记证书，可申请银行贷款。

二、申请软件产品登记的材料清单
1、营业执照副本复印件
2、法人身份证复印件
3、计算机软件著作权登记证书
4、软件评测报告
三、申报流程
北京中正联合知识产权有限公司
（1）申请用户名密码；（2）网上填报（3）初审通过（4）预约时间（5）递交材料
四、办理时限
网上申报审核需要：3-5个工作日拿到证书：1个半月到2个半月。

五、重要信息提示：
1、各业务受理时限
软件企业年审：1月4日—8月10日，每月一批，汇算清缴备案
的企业须在5月10前完成年审。

软件企业认定、变更：从1月4日到12月10日，每月一批。

12月11日（含11日）以后不再受理软件企业认定申请。

软件产品登记、续延、变更：从1月4日—12月10日每月一批。

12月11日（含11日）以后不再受理软件产品登记续延申请。

2、提交材料要求
申请表：申请表提交2份。

其它材料提交1份。

原件：所有提交的材料须提供原件备查。

复印件：复印件须与原件一致并盖公章，超过2页（含2页）的复印件盖骑缝公章。

北京中正联合知识产权有限公司
电子文档：申请表以外的材料须提供电子扫描文件（光盘）。

3、证书提示
软件企业年审：直接查看公示网公示结果即可，无需在证书上盖章。

软件企业认定、软件企业名称变更、软件产品登记、续延、变更：根据公示网公示提示领取证书
北京中正联合知识产权有限公司
第四篇：管理公司流程规范
云南电影发行放映有限公司
影院管理公司
YYGL[2014]1号
关于影院各部门流程规范
根据2014曲靖会议精神，贯彻落实公司规范影院发展的方针，经总经理室批复，现就公司所属影院的各部门操作流程进行统一规范管理：
1、上报流程部门
本次上报流程包含3个部门，分别为票务，场务，机务。

2、上报流程时间
本次上报流程截止时间为2014年10月10日23:59。

3、上报流程方式
本次上报流程方式通过邮件上报，上报地址：管理公司QQ交流群（群号：***************）。

4、上报流程邮件格式
邮件主题：影院名称部门流程上报日期邮件附件：影院名称部门名称最后修改日期
5、上报流程人员
本次上报流程人员必须是影院经理。

6、上报流程内容规定
本次上报流程内容是已经经过主管、经理整理好的上班流程内容，作为公司和影院管理公司到影院实地考察检测的依据，必须具备实用性、时效性和可预见性。

7、上报流程内容规范
详见各部门流程规范。

规范内容依照各个影院实施结果可自行增加要求，但是不能减少现有条款。

一、票务流程：
1、票务部门准备工作准备工作开始和截止时间；票房、票台卫生内容；
网络、售票电脑、电视机、POS机等机器设备的检测内容；售票系统、排片信息检测内容；会员卡、票券等准备内容；
微信、微博、飞信、QQ群信息发布内容；了解全天放映影片的各种基本信息内容；
2、票务部门售票咨询工作咨询工作服务要求；咨询工作记录和反馈要求；
票务售票各个环节基本流程和要求（现金售票、会员售票、会员预订票、会员办理、会员升级、会员补办卡等）；
票务售票环节中得其他添加内容（临时添加活动流程，POS机使用流程，微信、飞信等会员信息添加流程）；
3、票务结算工作
票务每日结算时间；票务每日结算内容流程；
票务每日结算的各种交接表格内容；票务人员最后离开票房前票
房物品摆设要求；
4、票务人员的其他要求
票务主管：每月跟财务或办公室核对票款内容；
票务主管：每月跟财务或办公室核对各种物品的使用情况内容；影院各种快递接收、分发记录内容；票务人员的仪容仪表工作要求；
票务人员关于修改各种票据和记录表格的要求；票务人员上下班、离开票房要求；票务人员使用礼貌用语、服务态度要求；
票务人员有事请假规范；票务人员违规处罚内容；票务部门遗失物品赔偿内容；
5、其他内容
票务部门和影院其他部门对接内容；
关于各个影院自身情况不同，票务部门需要做的事情流程内容。

二、场务流程
1、场务部门准备工作准备工作开始和截止时间；各种消防器材检测内容；各种灯具电源检测内容；
各个放映厅内、售票大厅器材、桌椅检测；各个放映厅内、售票大厅的卫生；
各种电影海报、X展架、其他宣传物品的摆设内容；各种器材、灯具损坏记录、上报内容；清楚每日排片的具体信息；
了解全天放映影片的各种基本信息内容；
2、场务部门检票工作检票咨询工作服务要求；
场务检票各个环节基本流程和要求（入场前厅内灯具检查、提醒观众入场、撕副券票、引导入场、副券回收、正片开始前后灯具的管理等）；
场务检票过程中处理观众自带食品、非对号入座等的具体流程；
3、场务部门巡场工作
场务每场次巡场时间；场务巡场检查厅内观众内容；场务巡场检查影片放映内容；
场务巡场中处理突发情况内容（比如停电等）；
4、场务部门清场工作场务清场工作时间和流程；
场务清场工作发现观众遗落物品的上交、记录内容；
5、场务人员的交班工作
场务每日下班前厅内外清理工作内容；场务每日下班前各种器具检查记录内容；场务每日下班前各种灯具、电源检查记录内容；
6、其他内容
场务主管：每月跟财务或办公室核对各种物品的使用情况内容；场务人员的仪容仪表工作要求；
场务人员关于修改各种票据和记录表格的要求；场务人员上下班、离开放映厅等要求；场务人员使用礼貌用语、服务态度要求；场务人员有事请假规范；场务人员违规处罚内容；场务部门遗失物品赔偿内容；
关于售票大厅等各种宣传物品的及时整理工作内容；
7、其他内容
场务部门和影院其他部门对接内容；
关于各个影院自身情况不同，场务部门需要做的事情流程内容。

三、机务流程
1、机务部门准备工作准备工作开始和截止时间；机房内消防器材检测内容；各种灯具电源检测内容；放映设备、3D设备的检测内容；根据排片表，检查各个放映影片内容；机房内各种放映设备、线路的卫生；清楚每日排片的具体信息；了解全天放映影片的各种基本信息内容；
2、机务部门放映工作机房内温度要求；放映工作前的开机流程；每部影片放映的具体流程；放映工作后的关机流程；
每部影片放映过程中的具体技术要求；
3、机务交班工作
每日放映情况记录内容要求；下班前的各种机器设备关闭内容；
4、其他内容
机务主管：每月跟财务或办公室核对各种物品的使用情况内容；机房内删拷影片记录内容和要求；
机房内删拷影片密钥、延期密钥等记录内容和要求；机房突发情。