软件产品登记流程

软件产品登记流程

一、申请软件产品登记的税收优惠政策：

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、证书提示

软件企业年审：直接查看公示网公示结果即可，无需在证书上盖章。软件企业认定、软件企业名称变更、软件产品登记、续延、变更：根据公示网公示提示领取证书

软件产品开发运作管理作业程序

1 / 5 1. 目的 制定软件产品开发运作管理程序，对软件开发过程的各个工作阶段予以识别和控制，实施过程管理程序和质量控制，使软件开发过程各阶段得以有序进行，不符 受 控 分发号

合项得到及时发现并纠正，确保软件开发项目的工程质量符合客户的要求。 2. 范围 适用于公司各种类型的软件产品开发活动：内部立项开发项目、客户委托开发项目、招投标项目等等包含软件产品开发的运作过程。 3. 职责 3．1中心副总经理：负责组织内部项目的立项申请、软件开发项目的项目任务定义、组织和软件开发技术评审，负责技术开发的外部联合有关事宜，指导开发部经理确定项目经理。 3．2软件开发部经理：协助中心副总经理进行项目任务定义和软件开发技术评审，确定软件开发项目经理，合理配置开发项目各种资源，监督项目经理执行软件开发运作程序及项目过程质量控制，并协同质量管理部人员对开发项目进行检查验收。与项目经理共同负责软件产品开发完成后的归档工作。 3．3项目经理：负责软件产品开发的执行过程：从项目任务书下达开始，对开发计划、需求开发、概要设计、测试设计与计划、数据库设计、详细设计、编码、测试、编写用户手册（或操作手册）、模块开发卷宗、试运行、验收等产品开发活动的全过程实施负责，对产品概要设计、数据库设计、详细设计的实施负责。并负责项目开发完成后的归档。 3．4开发人员（软件工程师）：配合项目经理，对指定任务的需求调研、详细设计、编码及单元测试、手册内容编写、测试任务、模块卷宗开发负责。配合项目经理进行开发文件、卷宗的编篡归档工作。 4. 程序内容 4. 1软件产品开发流程图 (左侧为工作阶段名称，右侧为工作相关产品，括号中的编号是文档的编号)

一个完整的软件开发流程

一个完整的软件开发流程 一、开发流程图 二、过程产物及要求 本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。 三、过程说明 (一)项目启动 1、产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。

2、公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。 3、明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》;从项目启动起，研发项目经理每周提供《项目研发周报》;测试阶段，测试工程师每周提供《项目测试周报》。 4、产品经理进行需求调研，输出《需求调研》文档。需求调研的方式主要有背景资料调查和访谈。 5、产品经理完成《业务梳理》。首先，明确每个项目的目标;其次，梳理项目涉及的角色;再来，每个角色要进行的事项;最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。 (二)需求阶段 1、进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。在这个过程中还可能产生的包括业务流程图和页面跳转流程图。业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。项目管理者联盟 2、产品经理面向整个团队，进行需求的讲解。 3、研发项目经理根据需求及项目要求，明确《项目里程碑》。根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。 4、研发工程师按照各自的分工，进入概要需求阶段。《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。 (三)设计阶段 1、UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。UI设计常涵盖交互的内容。 2、研发工程师在界面效果图，输出《需求规格》，需求规格应包含最终要实现的内容的一切要素。 3、研发工程师完成《概要设计》、《通讯协议》及《表结构设计》，及完成正式编码前的一系列研发设计工作。 (四)开发阶段项目经理博客 1、研发工程师正式进入编码阶段，这个过程虽然大部分时间用来写代码，但是可能还需要进行技术预研、进行需求确认。

软件发布流程

软件发布流程1目的 为了规范软件产品的版本发布过程，提高软件发布的可控性。2范围 适用于公司所有软件产品的发布。 3角色与职责 4软件发布流程 公司软件产品发布的流程如下： 1.1发布准备 软件开发完成，开发人员完成自测，并确定发布日期。 自测应当完成对以下内容的确认： 1)原有BUG是否彻底解决； 2)增加的功能，修改的功能； 3)新增功能是否达到需求及设计要求； 4)所做的改变带来的影响； 1.2提交测试 软件负责人提出测试申请，并明确以下内容： 1)软件版本号； 2)新增或修改了哪些功能；

3)修复了哪些BUG； 4)更改后的影响分析及测试建议； 1.3执行测试 测试负责人接收测试申请后，启动软件测试，完成后反馈测试结果。 测试结果应包含以下内容： 1)原有BUG的解决情况； 2)BUG的新增情况； 3)测试用例执行情况； 1.4发布评审 软件经过全面测试后，由质量部SQA负责审核并判断软件是否达到发布要求。 发布评审中对软件缺陷的要求是：致命、严重级别缺陷为0，一般级别缺陷解决率为95%，轻微级别缺陷解决率为90%。 说明： 缺陷级别划分为四级：致命、严重、一般、轻微。 1.5源码、文档入库 软件负责人安排将软件源代码及文档入库。 源码包括软件所有源代码；文档包括需求、设计、测试文档，安装手册、使用手册等。 1.6程序打包 软件负责人安排将程序打包，标记源码、文档版本tag等。 1.7编写发布说明 软件负责人安排编写产品发布说明（或者release note）。 Readme的内容应该包括 1)产品版本说明； 2)产品概要介绍； 3)本次发布包含的文件包、文档说明； 4)本次发布包含或者新增的功能特性说明； 5)遗留问题及影响说明； 6)版权声明以及其他需要说明的事项。

软件开发流程图_软件产品发布流程_规范

一、软件产品开发流程图：

二、软件产品发布流程 1、发布准备。发布之前，所有程序由测试人员进行确认测试；检查系统内登记的所有bug 都已经被解决，或者遗留的bug不影响系统的使用，如果有严重bug未解决，则不能发布；程序打包前做冒烟测试（冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。）。（测试） 2、测试负责人编写发布产品质量报告进行质量分析和总结。 3、源码、文档入库。源码包括数据库创建脚本（含静态数据）、编译构建脚本和所有源代码； 文档包括需求、设计、测试文档，安装手册、使用手册、二次开发手册、产品介绍（ppt）、使用demo等等。（按合同规定，或只提供部分文档）（产品、项目经理、研发、测试） 4、进行程序打包；标记源码、文档版本。（研发、运维） 5、填写发布基线通知，并通知相关人员；经理对发布基线进行审计检查。（项目经理） 6、在禅道系统上新建产品发布计划，填写配置项，发布产品。（项目经理） 7、传程序包、使用文档至Download站点。（运维） 8、编写发布说明。内容应该包括产品版本说明；产品概要介绍；本次发布包含的文件包、 文档说明；本次发布包含或者新增的功能特性说明；遗留问题、影响说明；版权声明以及其他需要说明的事项。（项目经理、测试） 9、正式发布通知。通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介 绍。（项目经理邮件通知） 10、后续工作。产品发布后，在使用过程中可能还会发现一些bug。在不影响正常使用 的情况下，这些bug将在下一版本发布时解决；如果bug严重影响使用，必须打patch 或者按照流程重新发布。（研发） 11、临时发布。软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应 急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员；研发人员需要为源码、文档打tag标记。 （研发） 12、附《常见问题排除手册》，内容简介：推荐硬件配置。（售后） 13、文件命名规则：惠朗_项目名_文件名称_版本号.xxx。如，惠朗_无锡银行_POC文档 _V1.0.doc。（ALL）。 14、写Readme，后有DEMO。（项目经理） 注意事项： 尽量使用Jekenis，如果没有，可将测试程序上传禅道。程序如果过大可以上传到文件服务器。 发版的程序一定要上传禅道或文件服务器。 Readme:（打到war包里，记录版本号，改进内容，项目名称，甲方，400电话等） 以下为DEMO =========================== ###########环境依赖 Mysql5.7+ redis ~

一个完整的软件开发流程精品范本

一个完整的软件开发流程一、开发流程图

二、过程产物及要求 本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。 三、过程说明 (一)项目启动 1、产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。 2、公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。

3、明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》;从项目启动起，研发项目经理每周提供《项目研发周报》;测试阶段，测试工程师每周提供《项目测试周报》。 4、产品经理进行需求调研，输出《需求调研》文档。需求调研的方式主要有背景资料调查和访谈。 5、产品经理完成《业务梳理》。首先，明确每个项目的目标;其次，梳理项目涉及的角色;再来，每个角色要进行的事项;最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。 (二)需求阶段 1、进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。在这个过程中还可能产生的包括业务流程图和页面跳转流程图。业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。项目管理者联盟 2、产品经理面向整个团队，进行需求的讲解。 3、研发项目经理根据需求及项目要求，明确《项目里程碑》。根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。 4、研发工程师按照各自的分工，进入概要需求阶段。《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。 (三)设计阶段 1、UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。UI设计常涵盖交互的内容。 2、研发工程师在界面效果图，输出《需求规格》，需求规格应包含最终要实现的内容的一切要素。 3、研发工程师完成《概要设计》、《通讯协议》及《表结构设计》，及完成正式编码前的一系列研发设计工作。 (四)开发阶段项目经理博客 1、研发工程师正式进入编码阶段，这个过程虽然大部分时间用来写代码，但是可能还需要进行技术预研、进行需求确认。 2、编码过程一般还需进行服务端和移动端的联调等。

软件产品发布流程

严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制,保证软件产品质量的关键过程 之一。 参与软件产品发布的人员主要是测试负责人和BM(Build Master)。 公司软件产品发布的规程如下: 1、发布准备。发布之前,所有程序freezed由测试人员进行确认测试;检查qcs系统内登记的所有bug都已经被fixed,或者遗留的bug不影响系统的使用,如果有严重bug未解决(级别为must fixed)不能发布;程序打包前做冒烟测试。 2、测试负责人编写release产品质量报告进行质量分析和总结。 3、源码、文档入库。源码包括数据库创建脚本(含静态数据)、编译构建脚本和所有源代码;文档包括需求、设计、测试文档,安装手册、使用手册、二次开发手册、产品介绍(ppt)、使用demo等。 4、BM进行程序打包;标记源码、文档版本tag。 5、BM填写发布基线通知并通知相关人员;BM经理对发布基线进行审计。 6、在qcs系统上新建产品发布计划,填写配置项,执行发布计划(发布产品)。 7、上传程序包、使用文档至download站点。 8、编写发布说明readme.txt(或者release note)。Readme的内容应该包括产品版本说明;产品概要介绍;本次发布包含的文件包、文档说明;本次发布包含或者新增的功能特性说明;遗留问题及影响说明;版权声明以及其他需要说明的事项。 9、正式发布通知。通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介绍。

10、后续工作。产品发布后,在使用过程中可能还会发现一些bug。在不影响正常使用的情况下,这些bug将在下一版本发布时解决;如果bug严重影响使用,必须打patch或者按照流程重新发布。 11、临时发布。软件产品未正式发布前,可能需要一个临时版本供开发人员或者用户应急使用,这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员;BM需要为源码、文档打tag标记。 软件产品发布后,即建立了一条发布基线。所有用户安装及二次开发必须在此基线上进行,开发人员不能直接从cvs或vss上check 代码编译交付用户使用或者进行二次开发。

软件版本发布流程

软件版本发布流程 目录 1、目的 ........................................ 2、范围 ........................................ 3、涉及的干系人................................. 3.1 项目经理（PM，Project Manager）......... 3.2配置管理员（CMO，Configuration Management Officer） ............................................ 3.3测试人员（TP） .......................... 4、版本发布流程................................. 4.1版本发布流程图 .......................... 4.2版本发布流程描述 ........................ 5、涉及的表单和模板............................... 1、目的 为了确保测试人员的版本和开发人员发布的版本一致，不会出现版本混乱，保证测试代码版本的稳定性，以及开发代码版本的可控性，使基线库完全的受控起来。通过版本发布、基线发布报告等规程来保证软件生命过程中所有产品的完整性、一致性、可追溯性，同时也保证测试人员的工作效率。若是要变更必须走变更流程。 2、范围 适用于整个高铁事业部纳入配置管理中的所有项目。

3、涉及的干系人 3.1 项目经理（PM，Project Manager） 项目经理是整个信息系统开发和维护活动的负责人，他批准配置管理的各项活动并控制他们的进程。具体职责如下： 1）在项目将要进行编码阶段，就要使用SVN库，根据代码包含的模块在src和release下建立相应的文件夹，已明确区分，并每天要督促项目开发人员从SVN上上传和下载代码，并对每个重要的代码上传进行标注。 2）项目要开始测试时，需填写《版本发布报告》，交给配置管理人员； 3）将代码的可执行程序或代码上传到SVN目录结构下的code下相关的文件夹下； 4）Web类的测试程序需搭建服务器，并将访问的网址、用户名、密码等以书面的形式发给测试人员。 3.2配置管理员（CMO，Configuration Management Officer） 根据配置管理计划执行各项管理任务，其具体的工作职责如下： 1）根据项目经理提交的《版本发布报告》，将相关的内容打基线，确定测试版本； 2）发送《基线发布报告》给部门经理、开发人员、测试人员等，确定可以开始测试； 3）为测试人员增加SVN的库中该项目基线库的访问权限。 3.3测试人员（TP） 根据测试计划，执行测试任务，其具体工作职责如下： 1）根据《基线发布报告》在SVN基线库中获取代码或可执行程序； 2）Web类型的根据项目经理的发的访问网址、用户名、密码等登录系统，进行测试； 3）将每一轮测试的bug提交到mantis上。 4、版本发布流程 4.1版本发布流程图 4.2版本发布流程描述 1）项目从将要开始编码起就要求要使用SVN,每天进行上传和下载代码，进行标记，对应的VS? 和eclipse都有对应的SVN插件； 2）项目代码编写阶段结束后，要进入测试阶段进行测试，项目经理需向配置管理

软件开发之版本发布流程

软件开发之版本发布流程1目的 为了规范公司软件产品的版本发布过程，提高软件发布的可控性。 2范围 适用于公司所有软件产品的发布。 3角色与职责 4软件发布流程 公司软件产品发布的流程如下： 4.1发布准备 软件开发完成，开发人员完成自测，并确定发布日期。 自测应当完成对以下内容的确认： 1) 满足式样要求； 1)原有BUG是否彻底解决； 2)增加的功能，修改的功能； 3)新增功能是否达到需求及设计要求； 4)所做的改变带来的影响； 4.2提交测试 软件负责人提出测试申请，并明确以下内容： 1)软件版本号；

2)新增或修改了哪些功能； 3)修复了哪些BUG； 4)更改后的影响分析及测试建议； 4.3执行测试 测试负责人接收测试申请后，启动软件测试，完成后反馈测试结果。 测试结果应包含以下内容： 1)原有BUG的解决情况； 2)BUG的新增情况； 3)测试用例执行情况； 4.4发布评审 软件经过全面测试后，由质量部SQA负责审核并判断软件是否达到发布要求。 发布评审中对软件缺陷的要求是：致命、严重级别缺陷为0，一般级别缺陷解决率为95%，轻微级别缺陷解决率为90%。 说明： 缺陷级别划分为四级：致命、严重、一般、轻微。 4.5源码、文档入库 软件负责人安排将软件源代码及文档入库。 源码包括软件所有源代码；文档包括需求、设计、测试文档，安装手册、使用手册等。 4.6程序打包 软件负责人安排将程序打包，标记源码、文档版本tag等。 4.7编写发布说明 软件负责人安排编写产品发布说明readme.txt（或者release note）。 Readme的内容应该包括 1)产品版本说明； 2)产品概要介绍； 3)本次发布包含的文件包、文档说明； 4)本次发布包含或者新增的功能特性说明； 5)遗留问题及影响说明；

软件产品发布管理流程

软件产品发布管理流程 IMB standardization office【IMB 5AB- IMBK 08- IMB 2C】

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

（4）编写《用户手册》、《安装手册》 4）测试人员：负责产品测试 3.定义 1）软件版本正式发布：通过软件测试人员测试验证并符合发布标准的软件版本发布过程。 2）软件版本异常发布通过软件测试人员测试； 4.发布前期 、发布准备开发人员先要确定发布的准备工作和发布的日期。准备工作应包含以下内容： 1）原有BUG的是否彻底解决； 2）新增模块在功能上是否达到设计要求； 3）修改了什么，增加了什么； 4）所做的改变带来的影响； 、撰写文档开发人员确定所发布内容中是否有新增功能。若有，则需撰写一份需求文档（即功能列表文档），交给测试人员。否则发送测试通知单，告知测试人员。需求文档的内容如下： 1）所做的改动有哪些； 2）修改原有BUG或新增模块的设计目标 、全面测试

测试人员在收到测试通知单或需求文档后，应进行全面、完善的测试，如果通过测试，发送测试报告给产品经理，并修改BUG状态。否则，将测试结果反馈给开发人员，测试结果中应包含以下内容： 1）原有BUG的解决情况或新增模块的BUG情况 2）发现BUG的测试用例 、发布确认 通过系统测试后，测试人员将通过测试后的最新版本提交给产品经理： 1）产品经理编写《产品发布说明书》 2）产品经理通知项目开发组人员编写《用户手册》、《安装手册》，并组织评审，评审通过后，由产品经理提交给运营人员。

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

软件产品发布管理流程规范 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的测试用例

软件项目上线发布流程

布比项目上线部署发布流程 V1.0 2017/9/14

1、目的 规范公司项目和产品的上线流程，建立和完善产品的版本控制，保证软件产品质量。 2、范围 适用于公司所有项目和产品 3、发布人员 开发环境由开发人员内部负责（包括维护和管理开发分支和git代码库）测试环境由测试人员负责 预热环境由运维人员负责 正式环境由运维人员负责 *数据库操作均由DBA统一负责(或运维人员) 4、发布流程 在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。 一、提交测试 a)开发人员在功能开发完毕后首先配置开发环境，并将系统部署至 开发环境。在开发环境经过自测通过后提交测试代码，并开始撰 写上线方案。(上线方案须包括新增的外部应用程序安装，应用程 序部署顺序及应用关联性、是否关闭其他应用服务，数据库脚本， 制定合理的上线时间，涉及的服务影响范围以及上线失败的回滚 步骤。)并提交相关技术负责人审核，在审核过后邮件给相关测试 人员。 b)测试人员根据模块功能文档并制定测试方案，测试用例，特别注

意临界点测试方案。 c)测试人员通过自动化部署平台根据提供的分支号依照上线方案 进行自动化部署，涉及数据库操作可提请DBA操作。 d)记录各种数据测试结果及测试问题，并交由相关开发人员进行二 次迭代处理，该点须交付测试结果报告。 e)内测完毕后交由相关业务及需求人员进行集成测试，并请测试人 员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。 二、预热发布 a)测试人员在测试环境测试并跟踪修改bug达到上线标准（没有 A、B级bug，C 级bug达到要求）时。开始部署预热环境， 测试人员对现有功能在预热环境上进行验收测试（重新执行 case）。紧急Bug修改走补丁/hotfix流程。不影响功能的bug 留到下次版本解决，确认达到上线标准。 b)如达到上线标准，测试人员发起邮件通知相关开发人员、产品人 员，准备正式上线发布流程。 三、正式上线 a)在测试人员确认项目具备上线条件下，正式上线前，开发负责人 须发起部署大会，召集相关开发人员、测试人员、产品人员、运维人员讨论此次部署事项(介绍项目的相应负责人员，数据库脚本执行，部署顺序，应用程序关联，部署时间点，部署回滚方案，包括数据库回滚和应用程序回滚)，最后生成会议纪要并发送邮 件。

软件发布管理流程规范方案

软件发布管理流程规范 编制： 审核： 日期： 版本： 编号： 密级：

修改历史

目录 1. 目标 (5) 2. 发布流程 (6) 2.1.补丁发布流程 (6) 2.2.主版本发布流程 (8) 2.3.产品实施流程 (11) 2.4.VSS管理流程 (12) 3. 相关资料 (13)

1.目标 软件的发布过程，需要形成有序的良性循环。否则，各环节流转中容易发生相互等待、被动接应的局面。无形中，不断增加了沟通成本，扩大了软件的风险。且对后期造成的影响并不能够完全预知、完全估量。 因此，根据公司内部前期已有的习惯，总结过去产品的发布经验，分析统计结果后，特制定本发布过程规范。预期达到如下目的： 1、减少交叉沟通。通过将发布过程流程化，使每一个环节的执行者都非常清楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻找到关键人物沟通解决。避免当需要获取一件事情的进展情况时，需要广泛征询才能掌握的现象。减少交叉沟通成本。 2、提高工作预见性。流程一旦启动，流程中的所有人员便被触动。各环节执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”，主动提前做出安排、准备，避开人力、时间等资源上的冲突。且一旦发现冲突，便能立刻“报警”，报得越早，越能提前应对，减少损失。 3、提高可控性。软件发布就像道路交通。交通电台有了可靠的消息渠道（取决于上述“1、减少交叉沟通”），便能随时掌握路面交通状况，配合可预见的行车计划（取决于上述“2、提高工作预见性”），当然更能向车队提供有价值的消息。因此，车队领导能做出更有控制力的指令，各车队协调行驶，整个交通自然更受控。 一条早已设计好的行车路线，加上提前准备就绪的车队人马，再加上行进途中密切配合的交通电台。与没有固定线路，需要时才去调配车马，电台信息又不

发布管理流程规范

产品发布管理流程规范编制： 审核： 日期： 版本： 编号： 密级： 目录 1. 目标 2. 发布流程 2.1. 补丁发布流程 .................................................................................................................................... 2.2. 主版本发布流程 ................................................................................................................................ 2.3. 产品实施流程 .................................................................................................................................... 2.4. VSS管理流程..................................................................................................................................... 3. 相关资料

目标 软件产品的发布过程，需要形成有序的良性循环。否则，各环节流转中容易发生相互等待、被动接应的局面。无形中，不断增加了沟通成本，扩大了软件的风险。且对后期造成的影响并不能够完全预知、完全估量。 因此，根据公司内部前期已有的习惯，总结过去产品的发布经验，分析统计结果后，特制定本发布过程规范。预期达到如下目的： 1、减少交叉沟通。通过将发布过程流程化，使每一个环节的执行者都非常清楚自己的产入产出，受谁的影响，将影响谁。当遇到困难时，能明确的定位寻找到关键人物沟通解决。避免当需要获取一件事情的进展情况时，需要广泛征询才能掌握的现象。减少交叉沟通成本。 2、提高工作预见性。流程一旦启动，流程中的所有人员便被触动。各环节执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”，主动提前做出安排、准备，避开人力、时间等资源上的冲突。且一旦发现冲突，便能立刻“报警”，报得越早，越能提前应对，减少损失。 3、提高可控性。产品发布就像道路交通。交通电台有了可靠的消息渠道（取决于上述“1、减少交叉沟通”），便能随时掌握路面交通状况，配合可预见的行车计划（取决于上述“2、提高工作预见性”），当然更能向车队提供有价值的消息。因此，车队领导能做出更有控制力的 指令，各车队协调行驶，整个交通自然更受控。 一条早已设计好的行车路线，加上提前准备就绪的车队人马，再加上行进途中密切配合的交通电台。与没有固定线路，需要时才去调配车马，电台信息又不畅的队伍相比，哪一个更能成功到达目的地？ 发布流程 本章节的流程图中，将使用下列简称。 1、需求组(人)：包括需求总负责人(或PM)、各模块需求负责人。 2、开发部(人)：包括技术开发部全体成员。 3、配置管理员：或简称SCM，包括技术研发部的配置管理组成员。 4、测试组(人)：包括测试组所有固定资源、临时调配资源。 5、安装组(人)：包括负责公司内部、客户现场的安装、调试的人员。 6、客户：所有使用我司产品的用户。 补丁发布流程 软件产品的某个主版本向外发布给客户使用后，发现了错误。若这个错误给客户造成了很大的影响，等不及下一主版本，需要立刻修正，我们就需要发布补丁（对应VSS上的存放目录：Patch[X.Y]）（注：所有补丁要求合并入下一主版本）。流程图如下所示。 主版本发布流程 主版本的发布流程，与补丁的发布流程相比，参与的职能部门个数、次数明显增多，且设置的检查点也随之增多。 重要的一点，引入客户监督。改变目前的“直到整个版本完全下流水线后，才提交客户试用” 的方法。采取“我们主动争取客户全程参与”的方法，每完成一个变更，不一定要待版本中的 所有变更完成，立刻放上客户使用的测试环境，请客户在线试用并提意见。（此举依赖公司实 现远程测试环境）。目的：让客户不仅知道我们在干什么，还知道我们干成什么样，是否满意。尽量让客户的意见在开发早期提出，越早提出，变更成本越小，且能直接减少后续的补丁发布 频率。 流程图如下： 产品实施流程 为方便大家更加理解软件的整个发布循环过程，在此简单介绍软件通过Release阶段后的实施流程，它包括安装、培训等内容。具体的规范制度，以实施部门制定的为准。

软件发布流程规范说明

软件发布流程规范说明文稿归稿存档编号：[KKUY-KKIO69-OTM243-OLUI129-G00I-FDQS58-

软件发布流程规范说明 1.目的 1)规定产品中软件版本的各类发布流程. 2.适用范围 1)适用于产品生命周期内,产品中所有自行开发软件的发布过程. 3.职责 1)软件开发负责人 ①拟制软件版本各类发布说明 ②编制和维护《软件测试版本计划》 ③审核软件自测和外测测试报告 2)项目负责人 ①审核软件版本各类发布说明 ②批准软件版本正式发布说明 3)技术部总监 ①批准软件版本非正式发布说明及异常发布说明 4)产品支持人员 ①跟踪软件版本异常和非正式发布后的版本替代 5)项目助理 ①相关文档整理及软件发布,备份 4.定义 1)软件版本正式发布:通过软件测试人员测试验证并符合发布标准的软 件版本发布过程

2)软件版本异常发布:通过软件测试人员测试验证,但测试结果不符合发 布标准的软件版本发布过程,可采取软件版本异常发布流程的情形仅限于生产和客户使用现场缺陷修复或现场测试等紧急情况 3)软件版本非正式发布:仅通过设计人员自测而未提交测试人员测试或 只经过测试人员的设计验证测试的软件版本发布过程. 5.工作流程 软件版本发布是依据产品《软件开发计划书》,《软件版本计划》及最新版本的《软件需求规格说明书》,确认某一软件从开发阶段过渡到投入使用阶段的工作过程.分为正式发布,异常发布及非正式发布三种情形; 1)软件版本正式发布流程 ①软件开发负责人根据《软件开发计划书》和《软件版本计划》,申请启动软件版本正式发布. ②软件项目组提交可安装执行的程序软件包,《软件版本正式发布说明》,《设计更改说明》等. ③软件测试人员提供测试报告,软件开发负责人核对测试结果,确认符合软件版本发布标准. ④项目负责人审核及批准发布 ⑤产品助理按照要求进行发放和登记. 2)软件版本异常发布流程 ①软件开发负责人启动软件发布后,如发现软件测试人员提供的测试结果不符合软件发布标准时,可选择重新提交测试,或者申请启动软件版本异常发布流程.

软件发布流程64375

软件发布流程

1、目的 规范公司项目和产品的上线流程，建立和完善产品的版本控制，保证软件产品质量。 2、范围 适用于公司所有电商项目和产品 3、发布人员 Dev环境由开发人员内部负责（开发分支） Alpha环境由测试负责人负责 Beta环境由运维负责 正式环境由运维负责 *数据库操作均由dba统一负责 4、发布流程 1、提交测试 开发人员经过自测（单元测试），在handoff通过后提交测试代码 测试人员通过自动发布工具部署测试环境（alpha） 2、预发布（beta） 测试人员在alpha环境测试并跟踪修改bug达到上线标准（没有A、B级bug，C 级bug少于20%）时。开始部署beta环境，有测试发起走邮件发布流程。 3、验收测试 测试人员对现有功能在beta上进行验收测试（重新执行case）。紧急Bug修改走补丁/merge流程。不影响功能的bug留到下次版本解决。确认达到上线标准。 4、正式上线 测试人员发起，通知相关部门人员配合发起上线操作（具体走发布流程邮件）。 测试人员在线上进行冒烟测试，（紧急Bug修改走补丁 /merge流程。不影响功能的bug留到下次版本解决。）。通过后回复邮件，发布结束。 5、总结报告 测试负责人编写测试总结报告。

5、邮件格式 1、稳定版： a)提前一天通知邮件： QA部门将于*月*日*时（周几）锁定代码，进行稳定版制作，需要某某，某某某。。。提供支持。 稳定版制作完成后再提交代码需要走merge流程。 本次修改内容： 1、登陆样式调整 2、第三方登陆 3、登陆按钮位置调整 b)正式开始时，请直接回复此邮件 稳定版制作开始，代码权限开放，请某某开始操作 c)运维，DBA在进行操作时均需要回复次邮件，并说明操作步骤。 发布完成后运维回复邮件通知QA进行测试 *上线流程同上，均需要通过邮件进行步骤流转。最后测试人员在线上冒烟测试结束，回复邮件，发布结束。 2、merge/补丁： a）邮件内容： Bug号+简单描述 修改文件名 Review人 Review人员帮助审核并回复邮件 b）运维人员发布 回复补丁邮件提醒QA进行验证，QA验证通过并结束此邮件。（如不通过继续流转此邮件）

软件版本发布流程

软件版本发布流程

目录 1、目的 (3) 2、范围 (3) 3、涉及的干系人 (3) 3.1 项目经理（PM，Project Manager） (3) 3.2配置管理员（CMO，Configuration Management Officer） (3) 3.3测试人员（TP） (3) 4、版本发布流程 (4) 4.1版本发布流程图 (4) 4.2版本发布流程描述 (4) 5、涉及的表单和模板 (4)

1、目的 为了确保测试人员的版本和开发人员发布的版本一致，不会出现版本混乱，保证测试代码版本的稳定性，以及开发代码版本的可控性，使基线库完全的受控起来。通过版本发布、基线发布报告等规程来保证软件生命过程中所有产品的完整性、一致性、可追溯性，同时也保证测试人员的工作效率。若是要变更必须走变更流程。 2、范围 适用于整个高铁事业部纳入配置管理中的所有项目。 3、涉及的干系人 3.1 项目经理（PM，Project Manager） 项目经理是整个信息系统开发和维护活动的负责人，他批准配置管理的各项活动并控制他们的进程。具体职责如下： 1）在项目将要进行编码阶段，就要使用SVN库，根据代码包含的模块在src和release 下建立相应的文件夹，已明确区分，并每天要督促项目开发人员从SVN上上传和下载代码，并对每个重要的代码上传进行标注。 2）项目要开始测试时，需填写《版本发布报告》，交给配置管理人员； 3）将代码的可执行程序或代码上传到SVN目录结构下的code下相关的文件夹下； 4）Web类的测试程序需搭建服务器，并将访问的网址、用户名、密码等以书面的形式发给测试人员。 3.2配置管理员（CMO，Configuration Management Officer） 根据配置管理计划执行各项管理任务，其具体的工作职责如下： 1）根据项目经理提交的《版本发布报告》，将相关的内容打基线，确定测试版本； 2）发送《基线发布报告》给部门经理、开发人员、测试人员等，确定可以开始测试； 3）为测试人员增加SVN的库中该项目基线库的访问权限。 3.3测试人员（TP） 根据测试计划，执行测试任务，其具体工作职责如下： 1）根据《基线发布报告》在SVN基线库中获取代码或可执行程序； 2）W eb类型的根据项目经理的发的访问网址、用户名、密码等登录系统，进行测试； 3）将每一轮测试的bug提交到mantis上。

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

软件产品发布管理流程规范 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软件版本正式发布流程

产品版本发布流程规范

软件发布管理流程规范 V3.2 内部文档 XXX股份有限公司 修改历史

目录

目的 根据公司已有内部习惯、总结过去产品发布经验，特制订本发布流程管理规范，达到明确岗位职责、减少交叉沟通、提高产品质量的目的。 范围 适用于公司全部产品软件发布版本发布。 涉及的人员 产品经理 产品经理是公司所有软件的管理人员，负责软件的设计和对外发布。 研发人员 研发人员是软件的研发者，负责软件的研发和完善。 测试人员 测试人员是软件的质量管理人员，负责软件的质量管理和缺陷管理。 项目人员 项目人员是具体项目的项目经理，负责当前项目的整体实施协调工作。 产品版本发布流程 产品版本发布主要分为正常发布、临时发布、紧急发布三种情况。 ●正常发布：指产品发布有一定的计划安排，产品研发和测试具有充足的时间。 ●临时发布：指产品发布是临时安排的，产品研发和测试具有1天至5天的时间，需 要按照项目节点定时间计划，快速迭代。 ●紧急发布：指产品发布是紧急安排的，需要快速开展开发工作。 产品版本发布主要涉及产品部、研发部、测试部和项目部，各部门的责任人为： ●产品部：产品部具体的产品经理 ●研发部：研发部具体的研发人员 ●测试部：测试部具体的测试人员 ●项目部：具体项目的项目经理

下面分别对三种发布流程进行说明。 产品版本正常发布 发布流程 发布流程描述 产品部 ?制定计划 产品经理首先与开发经理、测试经理沟通，根据开发工作量、时间评估制定《版本发布计划》，计划内容包括了迭代周期、缺陷报告提交时间、发布时间等关键节点的计划（详见发布时间计划模版）。 ?节点跟踪 产品经理在迭代过程中，主要根据《版本发布计划》，跟踪在计划的时间节点上的完成情况，如未按计划提交，产品经理需要推进开发、测试负责人员按计划提交任务产出。 ?版本最终发布 研发部 ?产品开发及提交测试(临时版本、最终版本) ?缺陷修复（下一版本提交之前完成修复）； 测试部 ?产品测试（遍历测试、完整测试） ?报告提交（缺陷报告、完整测试报告） ?最终版本提交 产品版本临时发布 发布流程 发布流程描述 临时版本的发布流程与正常发布版本的流程相同，在版本发布最终期限前，按天进行迭代安排计划，各部门快速完成相关工作。 产品部：跟踪整个进度节点，跟踪、推进各部门按计划完成任务 研发部：需要快速的修复已知缺陷，按计划发出版本 测试部：根据项目具体要求进行重点测试包括基本功能、特殊功能等