产品上线流程
产品上线流程标准化工作室编码[XX968T-XX89628-XJ668-XT689N]
1、需求阶段a、需求产生。需求产生有三种渠道：一，U I （UserInterface用户界面）设计师或PD（ProductDesiger产品策划）研究市场需要，提出需求，应获得市场策划或市场调研员的认可；二，业务部门提出需求，包含总经理、研究部、内容编辑部、客服部、展
1、需求阶段?
a、需求产生。需求产生有三种渠道：
一，UI（UserInterface用户界面）设计师或PD（ProductDesiger产品策划）研究市场需要，提出需求，应获得市场策划或市场调研员的认可；
二，业务部门提出需求，包含总经理、研究部、内容编辑部、客服部、展业部、市场部等部门。
三，UI或PD研究用户，提出需求。此步骤需提供用户习惯报告，体验目标，用户访谈、调研，流量数据统计等作为依据，不得凭空想象。所有需求需经过PD。不经PD的需求，技术部门有权拒绝开发，也没有人为需求负责。即使不需进行策划和设计，也应提交给PD备案。
b、MRD（MarketRequirementsDocument市场需求文档）。
MRD需明确传达产品需求的目的和目标，指出什么样的新产品、方案和服务为什么可以在市场上或者内部取得成功，以及希望取得怎样的成
功。MRD说明“是什么”和“为什么”，但不要写“如何”（即不要包含流程图和原型图）。
当产品需求为高优先级（即项目立项）时，需求方必须提供MRD文档。产品需求的优先级、权重和是否立项由项目实施委员会确定，日常需求由委员会负责人确定，非常规需求开会确定。个别小修改甚至不需PRD，可由PD与技术部门直接沟通完成。
c、需求评审。PD接到显性需求后，应仔细透彻地分析需求方的真正意图。有时候需求方的想法不一定正确，也有些是突然的想法并不可行，PD需进行判断；当这种情况出现时，PD有权提出自己的解决方法，包括否定需求。因判断失误造成需求冲突、重复开发等情况，责任由PD承担。当发生争执，由PM（ProductManager产品经理）协调解决。PD完成需求评审后，需告知需求方完成PRD的时间、产品开发的预估难度及完成工期。此步骤必须。
2、策划阶段?
a、PRD（ProductRequirementDocument产品需求文档）。PRD侧重对产品产品功能和性能的说明，相对于MRD中的同样内容，要更加详细，并进行量化。PRD一般包含流程图、原型图等，使用用例等手段，以准确说明。若无MRD，则PRD需对目标进行说明。PRD为必须经过的步骤，由PD或UI完成。PRD需进行编号，编号规则详见“需求编码”表格。
b、专家评审。需求方、相关领域的顾问（即有丰富经验者）、PD或UI参与的评审PRD的会议，一般项目经理、PM需参与会议。若项目较大，需邀请总经理参与。会议必须有主持，并在会后出MEMO（备忘）或PRD更新说明。专家评审结束后，PD出设计结果方案，需求方签字确认。程序员接到PRD方案后，需评估完成开发的大致时间，以及任务分解安排。当需要GUI方案作为辅助判断时，需明确提出。
c、交互DEMO。ID（InteractionDesigner交互设计师）根据PRD定稿做出交互设计方案，真实再现用户交互过程，并与PD、UI进行内部评审。视情况，PM参与。（因公司没有ID，此步骤由PD与美工，视觉设计师，口头沟通完成）
d、视觉界面。由美工（视觉设计师）设计页面风格、布局、关键界面等，交由PD、UI、ID进行内部GUI（GraphicalUserInterface图形使用者接口）评审。GUI方案通过后，页面制作师开始切割页面，编写HTML。
3、开发阶段?
a、后台编码。在编码之前，程序员应视其系统需要，进行概要设计、数据库设计，并进行内部讨论和评审，邀请顾问参与。程序员对文档有疑问或不理解，需与PD进行沟通，了解其真实涵义，不得以任何理由私自更改已确定的PRD、GUI方案。确有功能需做调整，程序员需与PD、需求方共同协商完成。改动应出具文档，由需求方、技术经理、PM签字后生效。
b、α（alpha最初）测试。在开发小组内部进行，测试的方法也较多，黑盒、白盒、??压力、应力等。此阶段应完成80%以上的需求开发，测试以PRD为准。测试完成后，收集反馈，修复BUG，优化流程。开发者在场。
c、β（beta第二次）测试。有选择地请一些最终用户实际使用，将发现的问题反馈，开发者对系统进行最后的修改，之后准备发布最终产品。β测试开发者不在场。产品估算开发时间，以完成β测试为准。
d、产品发布。β测试后，PD校验产品。如产品与策划方案相差较大，有权不接受产品，责任由开发部门负责。将产品发布日设为里程碑，以此考核整个项目的运作效率。
4、校验阶段?
a、发布跟踪。产品上线后，PD或市场调研员负责收集用户操作数据，检测各个反馈渠道，筛选数据，出具用户检测报告，检验产品改进是否达到预期目标。立项产品应专门出具报告，非立项改动需在数据分析报告中体现。
source:互联网产品时代
软件产品开发运作管理作业程序
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)版权声明以及其他需要说明的事项。
软件项目上线发布流程
布比项目上线部署发布流程 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) 在测试人员确认项目具备上线条件下，正式上线前，开发负责人须发起部 署大会，召集相关开发人员、测试人员、产品人员、运维人员讨论此次部 署事项(介绍项目的相应负责人员，数据库脚本执行，部署顺序，应用程序关联，部署时间点，部署回滚方案，包括数据库回滚和应用程序回 滚) ，最后生成会议纪要并发送邮件。 b) 确认上线之后，测试人员邮件上线方案，数据库脚本，应用分支 号给运维人员及DBA DBA应提前执行数据库脚本，应用部署须 通过自动化部署平台进行部署，部署系统应在应用系统中记录当
软件开发流程图_软件产品发布流程_规范
一、软件产品开发流程图：
二、软件产品发布流程 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.验收测试简介 1.1简介 验收测试即由产品开发方按照新浪提供的需求文档中所有内容(或按合同及其它有效约定，对方承诺 实现的需求)进行开发、内测完毕，提交版本符合验收测试标准，通过新浪质量保证部进行的测试。 通过验收测试判断产品质量是否符合产品需求，功能实现是否正确并可以最终上线。 1.2角色定义 验收提交方：产品研发方 验收接收方：质量保证部 2.验收测试目的 通过验收测试判断产品质量是否符合产品需求、功能实现是否正确，性能和安全性方面是否符合发布标准，并且产 品可以最终上线。 3.验收测试版本 3.1测试版本命名 提交验收测试的产品版本统一按如下格式命名：产品名称―版本_ATx各部分释义如下：产品名称：提交测试的产品名称，例如“易享收藏夹”(EasyShareFolder) 版本： ATx :其中“ AT ”表示Acceptanee testing ;“ x”表示提交验收测试的次数后，如1、2、3等 3.2测试版本保存 每次提交验收测试的版本统一保存至新浪主体产品的版本库中，上线版本以验收测试通过版本为准。 4.验收测试范围 4.1界面测试 所有页面浏览，连接的正确、所有功能按钮及界面显示正确 4.2功能测试 所有需求文档描述的功能实现正确
4.3性能测试 重点业务功能、性能能满足上线运营需求 4.4安全性测试 接口和数据调用等方面符合安全性规范；没有安全性漏洞 5.验收测试流程 验收测试基本工作流程如下： 5.1.准入条件检测 进入验收测试的文档准备齐全： a）验收版本的需求文档（提交方提供）：要求需求文档与最终提交验收测试的程序完全匹配 b）验收版本的测试用例（提交方提供）：要求测试案例覆盖最终版本的需求文档； c）验收版本的测试告（提交方提供）：在测试报告书中说明测试总体情况，缺陷列表及修复情况； 要求开发方在Win dowsXP IE6 /IE7/Firefox3.x 兼容环境中（该兼容性需求会根据项目情况有变动，以新浪要求的为准），对需要文档上提及的所有功能进行全面测试，且提交验收测试时，开发方发现的所有缺陷都已解决。 验收测试环境准备完成，与线上真实环境一致 我方项目负责人负责测试环境控制，保证测试期间环境一致、稳定 1.提交验收测试 的开发方负责人联系方式及测试工程师联系方式齐全； 2.提交验收测试 缺陷的沟通渠道建立完毕，要求快捷、准确、反馈及时； 5.2验收测试
一个完整的软件开发流程精品范本
一个完整的软件开发流程一、开发流程图
二、过程产物及要求 本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。 三、过程说明 (一)项目启动 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 代码编译交付用户使用或者进行二次开发。
系统上线管理办法
《系统上线管理办法》 内部讨论版 上海捷羿软件系统有限公司 二〇一六年十月 版本历史 变更说明： C 初始创建；A添加；M 修改；D删除 目录 1 总则 2 范围 3 职责 4 管理办法 上线流程 ............................................................... 一般问题或需求................................................... 紧急问题......................................................... 管理办法细则 ........................................................... 系统上线操作注意事项 ................................................... 关于数据库备份机制 ..................................................... 5 附录 附录A：《01系统故障(缺陷)报告》模板.................................... 附录B：《02系统故障(缺陷)修复方案》模板................................ 附录C：《03系统变更测试报告》模板...................................... 附录D：《04系统变更申请单》模板........................................ 附录E：《05系统变更操作复核表》模板.................................... 附录F：《06系统升级上线方案》模板......................................
软件版本发布流程
软件版本发布流程 目录 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)遗留问题及影响说明；
软件项目上线标准流程
项目上线部署发布流程 V1.0 2017/9/14
一. 目的 规范公司项目和产品的上线流程，建立和完善产品的版本控制，保证软件产品质量。二. 适用范围 适用于公司所有项目和产品 三. 职责分工 开发环境由开发人员内部负责（包括维护和管理开发分支和git代码库） 测试环境由测试人员负责 预热环境由运维人员负责 正式环境由运维人员负责 *数据库操作均由DBA统一负责(或运维人员) 四. 发布流程 在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。 4.1.提交测试 ①开发人员在功能开发完毕后首先配置开发环境，并将系统部署至开发环境。在开发环境经过自测通过后提交测试代码，并开始撰写上线方案。(上线方案须包括新增的外部应用程序安装，应用程序部署顺序及应用关联性、是否关闭其他应用服务，数据库脚本，制定合理的上线时间，涉及的服务影响范围以及上线失败的回滚步骤。)并提交相关技术负责人审核，在审核过后邮件给相关测试人员。 ②测试人员根据模块功能文档并制定测试方案，测试用例，特别注意临界点测试方案。
③测试人员通过自动化部署平台根据提供的分支号依照上线方案进行自动化部署，涉及数据库操作可提请DBA操作。 ④记录各种数据测试结果及测试问题，并交由相关开发人员进行二次迭代处理，该点须交付测试结果报告。 ⑤内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。 4.2.预热发布 ①测试人员在测试环境测试并跟踪修改bug达到上线标准（没有A、B级bug，C 级bug达到要求）时。开始部署预热环境，测试人员对现有功能在预热环境上进行验收测试（重新执行case）。紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决，确认达到上线标准。 ②如达到上线标准，测试人员发起邮件通知相关开发人员、产品人员，准备正式上线发布流程。 4.3.正式上线 ①在测试人员确认项目具备上线条件下，正式上线前，开发负责人须发起部署大会，召集相关开发人员、测试人员、产品人员、运维人员讨论此次部署事项(介绍项目的相应负责人员，数据库脚本执行，部署顺序，应用程序关联，部署时间点，部署回滚方案，包括数据库回滚和应用程序回滚)，最后生成会议纪要并发送邮件。 ②确认上线之后，测试人员邮件上线方案，数据库脚本，应用分支号给运维人员及DBA，DBA应提前执行数据库脚本，应用部署须通过自动化部署平台进行部署，部署系统应在应用系统中记录当前分支号，以便后续应用回滚使用。在部署中出现错误，及时通知相关开发人员。如若问题不能在计划内时间解决，执行回滚方案。 ③运维，DBA在操作完成时均需要回复邮件，并说明操作步骤结果。 ④发布完成后运维人员回复邮件通知测试人员、业务及需求人员进行线上测试。测试结果及问题, 提交至开发人员。如若出现问题不能在计划内时间解决，执行回滚方案，并进行迭代改进。
软件产品发布管理流程
软件产品发布管理流程 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）产品经理通知项目开发组人员编写《用户手册》、《安装手册》，并组织评审，评审通过后，由产品经理提交给运营人员。
供应商介绍及引进流程
入驻好实再厂家店商城说明和流程 第一步、申请入驻： 了解资质信息：商家首先关注厂家店入驻标准，确认符合要求； 提交入驻申请：商家按合作意向书或VIP引进表要求填写，然后提交给招商经理或发送到招商部负责人邮箱； 确认合作意向：厂家店商城招商负责人约见商家，确认合作意向。 第二步、签订合同： 发送合同：招商负责人发送PDF格式合同或邮寄合同到商家处； 资质合同审核：商家按照要求签订合同、提交资质材料到厂家店商城审核。 第三步、产品上传准备： 准备产品资料：商家准备需要合作的产品图片及说明填写好供应商信息表； 免费注册供应商：商家登录好实再集团厂家店商城注册，供应商上传资料； 第四步、上架销售： 商品管理部经理将与您取得联系安排后续商品推广运营销售事宜。 说明 第一步、申请入驻及条件： 1、生产厂家或品牌供应商（经销商）应具有一定的规模； 2、证照齐全。应提供： ①企业营业执照 ②组织机构代码证 ③税务登记证 ④商标注册证、 ⑤质量检测报告、 ⑥供应商对商城的授权书、 ⑦特殊产品需要知识产权、专利证、及相应的认证； 3、品牌经销商必须提供品牌供应商，给与的正式销售授权书。
第二步、签订合同相关工作 1、如有必要将公司证照发邮件给供应商； 2、签订合同还需提供：产品结算时的《开户许可证》或指定的银行账号 3、将合同填写检查无误后发邮件给供应商签名、盖章，并连同以上所有证照盖章后快递给我 司相关人员； 4、采购招商人员接到快递的相关文件后，将《好实再厂家店供应商引进审批表》按照流程报 公司审批； 5、相关人员将《品牌申请表》、《XX品牌报价表》报领导审批。 第三步、产品上传准备及注意事项 1、准备产品资料：商家准备需要合作的产品图片及说明填写好《供应商提供产品信息详细 表》并重点注意以下6点： ①、产品主图(800*800)必须是800x800像素，数量个数是1-6张，不能有重复的图 片，第1张是：显示在首页上的，必须是白底，高清精美的图片。第2张通常为：核心部件图/官方亮丽宣传图。第3-5张：不同角度图、细节图、包装、全家福、多色图方法：参考淘宝/京东搜产品型号，主图中找； ②、产品名称（参照京东，天猫，其他大型的网站标志，产品的标题需要有引流和产品 的卖点及关键词，字数不能只是几个字） ③、产品详情图片（宽度是固定一样的：790是标准的宽度，不能大于790，不能小于 750。长度是不固定的一般长度是在600-700之间是最好的，这样的话打开产品显示出来比较快。） ④、商品的属性详细说明（对于产品功能、用途、使用方法等特性的详细描述介绍） ⑤、供货价和售价一定要合理，保障一定的商品毛利空间； ⑥、保证商品上架有正常库存，能直接订货销售。 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的测试用例
软件项目上线标准流程
项目上线部署发布流程
2017/9/14
一.目的 规范公司项目和产品的上线流程，建立和完善产品的版本控制，保证软件产品质量。二.适用范围 适用于公司所有项目和产品 三.职责分工 开发环境由开发人员内部负责（包括维护和管理开发分支和git代码库） 测试环境由测试人员负责 预热环境由运维人员负责 正式环境由运维人员负责 *数据库操作均由DBA统一负责(或运维人员) 四.发布流程 在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。 4.1.提交测试 ①开发人员在功能开发完毕后首先配置开发环境，并将系统部署至开发环境。在开发环境经过自测通过后提交测试代码，并开始撰写上线方案。(上线方案须包括新增的外部应用程序安装，应用程序部署顺序及应用关联性、是否关闭其他应用服务，数据库脚本，制定合理的上线时间，涉及的服务影响范围以及上线失败的回滚步骤。)并提交相关技术负责人审核，在审核过后邮件给相关测试人员。 ②测试人员根据模块功能文档并制定测试方案，测试用例，特别注意临界点测试方案。 ③测试人员通过自动化部署平台根据提供的分支号依照上线方案进行自动化部署，涉
及数据库操作可提请DBA操作。 ④记录各种数据测试结果及测试问题，并交由相关开发人员进行二次迭代处理，该点须交付测试结果报告。 ⑤内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。 4.2.预热发布 ①测试人员在测试环境测试并跟踪修改bug达到上线标准（没有A、B级bug，C 级bug达到要求）时。开始部署预热环境，测试人员对现有功能在预热环境上进行验收测试（重新执行case）。紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决，确认达到上线标准。 ②如达到上线标准，测试人员发起邮件通知相关开发人员、产品人员，准备正式上线发布流程。 4.3.正式上线 ①在测试人员确认项目具备上线条件下，正式上线前，开发负责人须发起部署大会，召集相关开发人员、测试人员、产品人员、运维人员讨论此次部署事项(介绍项目的相应负责人员，数据库脚本执行，部署顺序，应用程序关联，部署时间点，部署回滚方案，包括数据库回滚和应用程序回滚)，最后生成会议纪要并发送邮件。 ②确认上线之后，测试人员邮件上线方案，数据库脚本，应用分支号给运维人员及DBA，DBA应提前执行数据库脚本，应用部署须通过自动化部署平台进行部署，部署系统应在应用系统中记录当前分支号，以便后续应用回滚使用。在部署中出现错误，及时通知相关开发人员。如若问题不能在计划内时间解决，执行回滚方案。 ③运维，DBA在操作完成时均需要回复邮件，并说明操作步骤结果。 ④发布完成后运维人员回复邮件通知测试人员、业务及需求人员进行线上测试。测试结果及问题, 提交至开发人员。如若出现问题不能在计划内时间解决，执行回滚方案，并进行迭代改进。 ⑤紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决。测试通
软件项目上线发布流程
布比项目上线部署发布流程 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、提高工作预见性”），当然更能向车队提供有价值的消息。因此，车队领导能做出更有控制力的指令，各车队协调行驶，整个交通自然更受控。 一条早已设计好的行车路线，加上提前准备就绪的车队人马，再加上行进途中密切配合的交通电台。与没有固定线路，需要时才去调配车马，电台信息又不