软件版本发布流程

软件版本发布流程
软件版本发布流程

软件版本发布流程规范文件编号:

版本号:

文件状态:

编制:

审核:

批准:

发布日期:2012年4月30日实施日期:2012年5月2日

WAP(北京)信息技术有限公司

修改历史

目录

1、目的 (4)

2、范围 (4)

3、涉及的干系人 (4)

3.1 项目经理(PM,Project Manager) (4)

3.2配置管理员(CMO,Configuration Management

Officer) (4)

3.3测试人员(TP) (4)

4、版本发布流程 (5)

4.1版本发布流程图 (5)

4.2版本发布流程描述 (5)

5、涉及的表单和模板 (6)

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上。

4、版本发布流程

4.1版本发布流程图

4.2版本发布流程描述

1)项目从将要开始编码起就要求要使用SVN,每天进行上传和下载代码,进行标记;

2)项目代码编写阶段结束后,要进入测试阶段进行测试,项目经理需向配置管理员提交《版本发布报告》并将代码上传到SVN;

3)配置管理员根据《版本发布报告》将代码打基线,并产生《基线发布报告》发送给项目组的开发、测试人员、以及与项目相关的领导;

4)测试人员可以从SVN中基线库取代码,进行第一轮测试,测试过程中产生Bug,开发人员修改Bug。

5)Bug修改结束后,进入第二轮测试阶段;

接下来的过程和上面从2)到5)描述的一样,直到测试人员通过测试为止。

1,该流程参与人员:

模块开发人员,模块测试人员,版本发布人员,移植人员,运营人员。

2,版本号规范,版本号分为3位,即X.X.X,第一位为大版本号,即一个大的框架,第二位为功能添加或严重BUG修复是版本号位,第三位为小BUG,及版本区分位。

3,正常情况下,开发人员将版本号、模块运作流程或设计文档(邮件形式),条件限制(邮件形式),及样机提交给测试人员。

4,由测试人员制作测试样例(版本号前连两位做修改的,要进行测试样例评审,参与人员为流程设计人员,开发人员,测试人员)并进行测试,之中出现问题反馈给开发人员(走bugfree反馈)。

5,测试完全通过后,由测试人员发邮件给版本发布人员告知测试通过(以此为准,其它均无效),并详细描述版本差异及特性。

6,由版本发布人员发布新版本周知,正式发布上线,开始出包移植。

7,对于项目发现问题,要对问题进行评定(运营协调评定),需要进行整体测试的,要将项目暂停,然后整体测试完成后再进行调试,若不需要则现场调试,然后再由移植人员将BUG提交到BugFree中,由解决问题的开发人员来进行详细填写解决办法(由版本发布人员来审查),以备忘。

8,若项目需求变更需要改库,没有外出的,由开发人员告知测试人员,添加至BugFree,并只给开发人员(版本发布人员来审)。

9,若时间问题要发布新版本的(做局部BUG修复,理论上不影响稳定性),也要告知版本发布人员,由版本发布人员周知版本特性,并由测试人员确定其稳定性(在发布后)。

5、涉及的表单和模板

版本发布流程涉及《版本发布报告》和《基线发布报告》。

软件开发过程管理规范

软件开发过程管理规范文件管理序列号:[K8UY-K9IO69-O6M243-OL889-F88688]

0 引言 如果要提高软件开发人员的开发质量,必须有相应的考核制度,有了制度后才能推动开发人员想方设法改善自已的开发质量。目前研发对软件开发的过程缺乏细粒度的度量,所以不能依据有效的度量数据来考核开发人员的工作绩效,大部份只是凭考核人主观意志来考核,不能形成对被考核人有效的说服力。此绩效考核办法旨在结合实际情况合理客观地评价开发效率和质量。 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价,用评价的结果指导软件的开发过程,不断地提高软件开发质量水平,并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1)技术文档:主要包括:可行性分析报告、需求分析报告、软件功能规格说明、开发计划、系统设计报告、测试文档、用户手册、总结报告等; 2)计算机程序。 3 度量数据的来源 1)项目计划; 2)评审报告; 3)测试报告; 4)问题报告; 5)软件维护记录; 4 质量度量

4.1 度量指标 主要根据各类软件项检查表的检查指标来确定,例如,软件需求规格说明书检查表(见附录1),有10个检查指标,则根据具体项目检查侧重点不同,可从中选择相应的检查指标作为度量指标。 4.2 质量等级 1)软件项的质量等级的确定根据度量综合指标进行。 2)度量综合指标计算公式为:Total = ∑QiMi。 3)其中i=1,2,...n代表指标数量; 4)Q代表度量的指标; 5)M代表度量的指标Q在整个指标体系中所占的权重系数,对不同的开发项目可能不同,此系数根据开发的不同着重点给出。 度量指标权重系数表: 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分 1.0 6)质量评价:一般地,根据度量综合指标值,有以下评分标准。 质量评价计分标准表 序号得分质量评价

软件开发流程管理制度

软件开发流程管理制度 (讨论稿) 为加强对定制软件开发工作管理,缩短开发周期,提高软件开发质量,降低开发成本,提高定开发效率和效益,特制定软件开发流程管理制度。 第一章、总则 为保证日常工作正常有序的进行,让开发中各个环境更紧凑,更可控,需要尽可能实现项目管理的正规化,工作过程的流程化,以便提高软件质量,按期交付。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程,制定以下工作流程,并规定了各个重要环节需要提交的交付物。各阶段需提交的文档: 1、立项:项目申请表,软件需求报告或设计方案。 2、需求分析:项目研发主计划、需求规格说明书 3、总体设计:概要设计说明书或功能模块描述 4、详细设计:详细设计说明书,包括软件接口说明、单元测试计

划。 5、软件实现:软件功能说明、源代码说明或者注释 6、产品测试:测试报告 7、产品发布:产品说明书、使用手册 8、产品维护:问题反馈记录 9、项目总结:提交客户方的项目总结和公司项目汇报的PPT。软件过程成果表:

第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写,系统总体设计的编写;开发阶段完成设计文档的编写,代码的编写、代码的维护。测试阶段完成系统的测试,测试文档及其他材料。通过逐渐的调整岗位,明确工作职责,逐步实现项目经理,软件设计师,程序员,测试工程师的岗位设置。

软件过程规范

1.总则 最大限度提高Q&P (质量与生产率),提高Q&P的可预见性,是每一个软件开发机构的最大目标。而Q&P依赖于三个因素:过程、人和技术,因此要实现Q&P的提高, 除了加强技术能力,引进、培育更多优质技术人才之外,规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准,并在软件开发实践中不断地完善、修订,提高Q&P和Q&P的可预见性。 本规范采用CMM (软件过程成熟度模型)的指导,吸收RUP、XP、MSF、PSP、TSP 等过程规范指南的思想、方法及实践,充分结合xxx技术开发部的实际情况,引入先 进的技术、方法、工具,为公司的软件开发工作提供一部详细、可操作的过程指南。 在本规范的第一版本中,主要包括管理过程和开发过程两个部分,管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。 2.项目管理过程规范项目管理过程主要包括三个阶段:项目立项与计划、项目实施、项目关闭 2.1项目立项与计划参与人员:技术开发部指定的项目负责人(包括前期负责人、正式的项目经理)、立项申请人、[相关最终客户]以及实施该项目的开发组队成员; 入口准则:接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》; 出口准则:立项申请人签字确认了经修订正后的正式《软件项目计划》,并通过《工作任务卡》下达了开发任务,开发工作正式开始; 输入:经审批的《软件开发立项申请表》、与需求相关的业务资料;输出:《软件项目计划》、《软件需求规格说明书》、《开发任务卡》; 活动: 1.接到《软件开发立项申请表》后,技术开发部经理指定前期负责人,并告知立项申请人; 2.前期负责人阅读《软件开发立项申请表》后,通过与立项申请人的沟通、阅读立项申请人提交的材料、通过立项申请人与客户直接交流等方式,了解项目目标、范围与基本需求;并形成最初的《软件需求规格说明书》; 3.前期负责人会同技术开发部经理以及其它相关人员,制定最初的《软件项目计划》,并组织评审; 4.向立项申请人提交最初的《软件项目计划》; 5.最初的《软件项目计划》通过立项申请人的确认后,项目经理计划安排需求分析; 6.需求分析完成后,形成正式的《软件需求说明书》,提交立项申请人确认;(需求分析过程参见开发过程规范部分)

软件发布管理系统流程要求规范

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

修改历史

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

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

版本控制流程规范V完整版

版本控制流程规范V HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

版本控制流程规范文档 目录 一、编写目的 本文档主要目的是规范配置管理活动的过程,阐述了在项目开发、测试、实施的过程中SVN库的组成和使用规约,指导使用者正确地操作SVN 库,以保证项目中所产生的代码、文档各版本之间完整性、可追踪性和一致性。 二、适用范围 该规范适用于公司内部所有项目的配置管理过程。 三、环境资源 在整个项目过程或产品生命周期中,选择SVN作为配置管理工具。

四、职责 五、规范 1,用户命名及权限配置 1)SVN用户命名 项目组成员在各自的PC上安装SVN客户端,根据配置管 理员所分配的用户和权限登录配置库进行各项配置管理活 动。 初始用户命名规则: 用户名:公司邮箱@前的部分

密码:手机号后6位 2)访问约定 为了保证各个项目组开发成果的安全性,以项目为单位, 进行了精确权限划分,使得成员只能操作该项目组内的配 置项。 内网访问svn资源库地址: svn: ... /svn/项目名称 3)权限管理 各个项目组成员只能访问、操作各自的项目库,并具有特 定文件区域的读、写权限,配置管理员统一分配和管理权 限。 2,SVN库的划分 根据公司的项目,采用项目名—分区名—版本名—的主结构进行管理。 1)版本库名 根据项目名称由项目经理与配置管理员共同设定。各项目 统一建立2层目录,子目录根据实际情况建立。 2)文件结构 a)工作区:按版本存放提交测试阶段的相关程序、文档等 开发:开发相关 测试:测试相关

经营计划管理流程

流程负责人王建所 / 企管部经理 I.流程概述 本流程阐述编制年度、季度公司经营计划的管理程序,旨在规范公司经营计划的编制、执行、调整等各环节的工作。II.适用范围 英利绿色能源控股有限公司 III.流程参与人 ·主管副总 ?经理或副经理/专项计划责任部门 ?经理或副经理/经营计划管理部门 ?计划员/各专项计划责任部门、经营计划管理部门 IV.名词解释 V.相关文档及数据 ?年度、季度、月度经营计划 ?年度、季度、月度各专项计划

流程负责人 王建所 / 企管部经理 经经经经经经经经经 经经经经经经经经 经经经经经经经经经经经经经经经经经经经 经经 经经 经经 经经 经经经经 经经 经经经经经经经经经经经经经经经经经经经经经经经经经经经经经 经经经 经经经经经/经经经经经经经 经经经经经经经经经/经经经经经经经经经经经经经经经经 经经经经经经经经经经经经 经 经经经经经经经经经经经经经/经经经经 经经经经 经经经经经经经经经经经经 经经经经经经经 经经 经经经经经经经经经经经经经经经经经经经经经经经 经经经经经经经经经经经经经经经经经经经经经经经经经经经经 经经 经经 经经经 经经经经经 经 经经经 经经经 经经经 经经

流程负责人王建所 / 企管部经理流程描述 步骤 流程及控制说明 参与者 相关文档、数据及系统发现与建议部门岗位 01 企管部组织召开计划编制会 企管部组织召开经营计划编制会或发布通知,启动年 度、季度、月度经营计划的编制工作。下达公司经营 指标,明确计划编制的时间、内容、格式等具体要求企管部 专项计划责任 部门 主管副总 企管部经理 专项计划责任部门经理 各部门计划员 年度、季度、月度经营 指标表 计划编制时间表 计划格式样表 02 专项计划组织编制 各专项计划责任部门根据企管部下达的经营指标以及 计划编制的要求组织编制专项计划,签字后报主管副 总审核专项计划责任 部门 专项计划责任部门经理经营指标 专项计划(草案) 03 专项计划主管副总审核专项计划 主管副总审核专项计划,有问题交编制部门修改,审 核通过后签字专项计划责任 部门 主管副总 责任部门经理 专项计划 04 专项计划上报企管部 各专项计划责任部门将经主管副总审核的专项计划上 报企管部企管部 专项计划责任 部门 计划员专项计划 05 企管部审核专项计划,综合平衡后编制经营计划 企管部计划员审核各专项计划,有问题要求编制部门 修改,审核通过后进行综合平衡,编制公司经营计划 草案,企管部经理签字后交主管副总审批企管部 专项计划责任 部门 主管副总 企管部经理 专项计划责任部门经理 各部门计划员 专项计划 经营计划草案 06 主管副总审批经营计划 主管副总审批经营计划草案,有问题由企管部进行修 改,审批通过签字主管副总 企管部经理 企管部计划员 经营计划

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

软件产品发布管理流程规范 1.目的 产品的发布主要用于指导从项目到产品,从产品到市场的发布过程,本过程目的是为了有效指导项目组开展产品发布,实现下列目的: 1)指导发布活动,有效控制产品发布过程 2)有效控制和追踪产品版本 2.角色与职责 1)运营人员: (1)负责产品发布 (2)组织评审 (3)跟踪需要现场调测的异常产品包验证状态 2)产品经理: (1)提出发布申请 (2)跟踪异常发布的产品 (3)负责产品移交给市场、销售部门 (4)审核产品发布 3)项目组开发成员: (1)修改完善产品 (2)负责对市场、销售人员进行培训 (3)协助测试人员进行验收测试 (4)编写《用户手册》、《安装手册》 4)测试人员:负责产品测试 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、发布确认

软件开发流程规范-详细流程

软件开发流程规范 目录 目录 0 一、概述 (2) 二、开发流程规范 (3) 2.1系统软硬件开发环境 (3) 2.2系统架构(系统组成) (5) 2.3系统功能模块设计 (6) 2.4系统功能开发流程图 (7) 2.5开发修改记录 (8) 三、开发代码规范 (9) 3.1文件结构 (9) 3.1.1 文件信息声明 (10) 3.1.2头文件的结构 (12) 3.1.3定义文件的结构 (15) 3.1.4 头文件的作用 (17) 3.1.5 目录结构 (18) 3.2命名规则 (18) 3.2.1 共性原则 (19) 3.2.2 Windows变量命名规则 (21) 3.3程序风格 (24) 3.3.1 空行 (25) 3.3.2代码行 (26) 3.3.3代码行内的空格 (29) 3.3.4 对齐 (31) 3.3.5 长行拆分 (33) 3.3.6修饰符的位置 (35) 3.3.7 注释 (35) 3.4函数设计 (40) 3.4.1 参数的规则 (40) 3.4.2返回值的规则 (42) 3.4.3函数内部实现的规则 (47) 3.4.4其它建议 (50) 3.4.5使用断言 (50) 3.4.6 引用与指针的比较 (52) 3.5变量类型定义 (56)

四、软件测试规范 (56) 4.1单元测试 (57) 4.2 系统测试 (57) 4.6 业务测试 (59) 4.7 验收测试 (59) 4.8 用户现场测试 (59) 五、软件版本管理 (60) 4.1 版本管理的必要性 (60)

、概述 本文制定烟台开发区德联软件有限责任公司计算机软件开发规范文档。本规范的目的是使公司软件开发项目阶段清晰、要求明确、任务具体、编写的代码规范,使之规范化、系统化和工程化,向公司内从事软件开发的工程师和管理人员提出一系列规范和要求,从而有利于开发过程的控制和管理,提高所开发软件系统的质量,缩短开发时间,减少开发和维护费用,以保证项目高质量、顺利进行。 本规范包含:开发流程规范和开发代码规范等,开发流程规范需要技术开发人员编写相关内容,希望每个技术人员形成习惯,如有新的内容更新会及时通知大家,如有好的规范要求也可通知编制人员及时更新。 本规范为烟台开发区德联软件有限责任公司内部材料,严禁其他商业应用。

软件发布管理流程规范模板

软件发布管理流程 规范 1

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

资料内容仅供参考,如有不当或者侵权,请联系本人改正或者删除。 修改历史 II

目录 1. 目标........................................................................错误!未定义书签。 2. 发布流程................................................................错误!未定义书签。 2.1.补丁发布流程 .................................................错误!未定义书签。 2.2.主版本发布流程 .............................................错误!未定义书签。 2.3.产品实施流程 .................................................错误!未定义书签。 2.4.VSS管理流程 .................................................错误!未定义书签。 3. 相关资料................................................................错误!未定义书签。 III

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

项目开发计划管理流程

日照安泰集团编号:ATJT-OP-YY02 版本: 管理体系文件 生效日期:2013-XX-XX 项目开发计划管理流程 密级: 发放编号: 编制: 审核: 批准: 版本修订记录 序号修订日期修订内容修订人版本备注

范围 适用于公司项目开发计划(含节点计划与项目开发运营计划)管理 控制目标 规范公司项目开发计划的编制、审核、发布及变更的流程,协调、监控计划实施,促使公司项目产品的顺利实现 职责 工程管理部工程计划主管 组织项目关键节点计划的编制、调整、评估 组织项目开发运营计划的编制、调整、评估 组织工程计划分析会 协助工程管理部各专业工程师检查监督项目计划的履行情况,形成计划执行情况分析报告,向工程副总经理反馈 工程管理部 组织项目工程计划(主要指施工计划)编制、协调、汇总、发布工作 项目工程计划执行过程的监控、协调,组织计划调整 项目工程计划总结报告的汇总和核实上报 各部门 组织项目专项计划的编制、实施、调整 编制本部门各类计划完成情况总结报告 公司领导 按权限规定审核或审批各类计划的编制、调整 全面监控公司项目计划完成情况 术语和定义 节点(关键控制点):指项目开发运营计划中关键线路上主要工序的完成时间,如:概念设计、方案设计、扩初设计、施工图设计、开工、地下室完成(正负平)、主体封顶、外装饰完工、开始预售、竣工备案、完成90%销售额、交付入住等。 专业计划责任人:各部门负责人为各类专业计划的第一责任人;计划的执行人为直接责任人。 说明:日常重复的工作无须纳入计划,直接执行对应职责即可。 项目开发计划管理流程

项目计划体系管理

项目关键节点计划 开发报建部获取土地项目后5日内,将土地信息、项目资料、项目可行性研究报告、项目建议书等相关资料移交工程管理部工程计划主管。 工程计划主管依据上述资料,根据公司三年经营计划目标并结合公司其他要求,制定【项目关键节点计划(初稿)】,按权限经公司领导审核后组织各部门进行评审,评审的标准为计划的科学性、合理性及其与公司经营目标的统一性。 工程计划主管将评审后修订完成的【项目关键节点计划】报工程副总审核,按权限经公司领导审批。 审批通过的【项目关键节点计划】由工程管理部下发相关部门,监督其执行落实。人力资源部备案 项目开发运营计划及专项计划 依据发布的【项目关键节点计划】,工程管理部组织相关部门、项目经理在20天内签订【项目运营目标书】。根据项目关键节点计划和项目策划报告、项目运营目标书,工程副总组织专业部门讨论细化为具体的【项目开发运营计划】。【项目开发运营计划】的编制应当具有可交付、可考核的成果,交付成果所涉及到的工期应当在30天内。 工程管理部【项目开发运营计划】编制完成后3天内,组织各部门进行计划评审,着重计划的进度、协调及其与公司经营目标的统一。 经评审的【项目开发运营计划】按权限经公司领导审批后,工程管理部在公司范围发布。 公司职能部门依据审批通过的【项目开发运营计划】,组织本部门人员编制各专项细项工作计划(各类专项计划编制之初是控制性、指导性计划,过程之中应当进行细化调整。编制之初具有不同的编制依据、时机及责任部门,具体参见6.2.5表格),各阶段专项计划提交人力资源部审核,按权限经公司领导审批后发布,工程管理部备案。 经审批通过的各专项工作计划,人力资源部负责下发到各部门,由各业务部门分解成季度工作计划予以执行落实,人力资源部对各部门季度计划进行审核并备案。 工程副总负责各部门工作计划的协调和推动,督促各部门按计划执行落实,每季度组织计划协调会,编制【项目计划执行情况分析报告】,工程计划主管负责项目计划的全面监控。

软件发布流程

软件发布流程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 ~

软件版本发布流程

软件版本发布流程规范文件编号: 版本号: 文件状态: 编制: 审核: 批准: 发布日期:2012年4月30日实施日期:2012年5月2日 WAP(北京)信息技术有限公司

修改历史

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

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上。

软件产品发布流程

严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制,保证软件产品质量的关键过程 之一。 参与软件产品发布的人员主要是测试负责人和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 代码编译交付用户使用或者进行二次开发。

软件项目上线发布流程

布比项目上线部署发布流程 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 引言......................................................错误!未定义书签。 编写目的..........................................错误!未定义书签。 适用范围..........................................错误!未定义书签。 定义..............................................错误!未定义书签。 流程图............................................错误!未定义书签。 2 需求调研..................................................错误!未定义书签。 概述..............................................错误!未定义书签。 需求调研..........................................错误!未定义书签。 注意事项..........................................错误!未定义书签。 3 可行性分析................................................错误!未定义书签。 4 需求分析..................................................错误!未定义书签。 概述..............................................错误!未定义书签。 产物/成果.........................................错误!未定义书签。 需求分析任务......................................错误!未定义书签。 需求分析方法......................................错误!未定义书签。 原型化........................................错误!未定义书签。 需求报告..........................................错误!未定义书签。 划分需求的优先级..................................错误!未定义书签。 评审需求文档和原型................................错误!未定义书签。 5 系统设计..................................................错误!未定义书签。 概述..............................................错误!未定义书签。 产物/成果.........................................错误!未定义书签。 产品设计..........................................错误!未定义书签。 概述..........................................错误!未定义书签。 流程图........................................错误!未定义书签。

软件项目上线标准流程

项目上线部署发布流程

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留到下次版本解决。测试通

经营计划和目标管理控制程序

XXXXXX有限公司 经营计划和目标管理控制程序 IATF16949:2016 文件编号:XXX 制订日期:XXX 制订单位:XX 修订日期:XXXX 版次:B0 版 受控状态:受控文件/参考文件 生效日期:2017/9/30 副本编号: 保管部门:行政部 文件编号 QP-YX-01

1.目的 通过外部环境(市场、竞争对手、产业环境等)及内部环境(产品成本、组织机构、财务等)的分析,根据公司的长远发展需求,规划公司未来发展前景,并明确公司阶段性业务计划和经营目标及发展战略,不断增强企业的竞争力,使企业在稳定中求发展,在发展中求提升,以促进公司持续发展和

永续经营。 2.范围 本程序适用于本公司短期(1-2年)和中长期(3年或3年以上)的业务计划。 3.职责及依据标准 3.1总经理负责制定公司中长期业务计划,负责环境安全、基础设施、人力资源开发规划,财务策划,制 定目标成本、资金预决算及经营计划的批准等; 3.2营销部制定短期业务计划并跟踪本部门业务计划执行情况及效果验证评价; 3.3生产部负责本厂生产计划、生产设备、安全生产计划并跟踪本部门业务计划执行情况及效果验证评价; 3.4技术部负责新品开发计划并跟踪本部门业务计划执行情况及效果验证评价; 3.5品质部负责质量目标规划的制定、实施与持续改进计划并跟踪本部门业务计划执行情况及效果验证评 价; 3.6依据标准: 依据IATF16949:2016质量管理体系中标准条款5.1;5.1.1;5.1.1.1;5.1.1.2;5.1.1.3;5.1.2编制。 4.程序 4.1 确定公司经营方针: 总经理根据公司长远的发展需求和未来的发展前景制定并颁布公司的基本经营方针,以表明公司经营理念。 4.2 制定中长期业务计划 总经理根据企业的发展目标,行业的发展趋势,市场风险评估,产品结构以及顾客当前和未来的需求与期望组织各相关部门主管制定正式的,形成文件的全面的长期业务计划,经总经理批准后,作为受控文件下达执行,具体可考虑以下因素: a)与市场有关的问题; b)质量目标; c)增长预测; d)工厂/设施计划; e)质量目标成本; f)人力资源开发; g)预期销售额(月度预期销售额、季度预期销售额、年度预期销售额); h)顾客满意计划。 4.3 制定年度业务计划 各部门根据中长期规划和部门实际,制定本部门年度业务计划,营销部还要制定短期业务计划,报总经理批准后,作为受控文件下达执行,具体包括以下计划: a)年度销售计划; b)年度顾客满意度计划; c)年度质量成本目标计划; d)年度固定资产投资计划; e)年度员工培训计划; f)年度质量目标计划; g)年度劳动安全计划。 4.4 业务计划实施检查和修订

相关文档
最新文档