服务器开发中的项目管理流程评审版

项目管理流程

（合用于server开发）

版本号：1.0

目录:

1.概述........................................................

2.合用范围...................................................

3.术语和缩略语...............................................

3.1术语.................................................

3.2缩略语...............................................

4.项目管理总流程图...........................................

5.项目管理规范和流程........................................

5.1产品需求文档（PRD）生成............................

5.2技术调研............................................

5.3软件需求文档（SRD）编写............................

软件需求文档（SRD）编写........................

SRD文档评审....................................

5.4项目预立项..........................................

5.5项目整体方案设计....................................

技术方案设计...................................

概要设计文档编写及评审....................

详细设计文档编写与评审....................

测试方案及用例设计.............................

测试方案设计及评审.......................

测试用例设计及评审.......................

UI/UE设计（针对有界面展现的I产品）............

配置管理方案及计划设计.........................

5.6项目正式启动准备....................................

项目计划制定...................................

项目组组员列表.................................

风险评估及管理.................................

项目质量目的的设计和制定.......................

配置管理........................................

5.7项目启动会议........................................

5.8编码实现及调试......................................

编码............................................

单元测试........................................

联调............................................

集成测试........................................

提交系统测试申请...............................

系统测试版本输出...............................

5.9系统测试............................................

系统测试........................................

测试汇报评审...................................

开发debug..........................................

5.10性能测试............................................

5.11封板及代码冻结......................................

封板测试及封板.................................

代码冻结.......................................

5.12生产环境布署、验证测试.............................

上线布署申请...................................

布署上线.......................................

验证测试.......................................

6.文档模板列表...............................................

7.编制历史...................................................

1.概述

本文档意在通过建立规范化原则化的项Fl管理流程并且不停地改善、优化，到达提高工

作效率，原则化项目管理，提高软件质量，优化资源配置，减小风险事件等不良影响，

减少沟通成本的目的，进而，为企业拓展业务、扩大规模、持续发展，扫除阻碍、铺平

道路。

2.合用范围

本流程合用于北京无限立通基础平台服务器开发日勺项目管理使用

3.术语和缩略语

下列术语和缩略语只合用于本规范:

3.1术语

术语阐明

输入每项任务开始时的前提条件

活动每项任务的详细工作内容分解

输出每项任务通过活动后得出H勺成果，原则上规定所有的输出内容需要保

留、备份。

负责人指目前仃务项的重要负责人

参与方指目前任务项的配合、辅助人员

3.2缩略语

缩略语英文全称中文含义

MRDMarketRequirementDocument市场需求文档

PRDProductKequirementDocument产品需求文档

SRDSoftwareRequirementDocument软件需求文档

4.项目管理总流程图

如下是无限立通项目管理总流程图（本流程合用于服务端的开发）

5.项目管理规范和流程

5.1产品需求文档(PRD)生成

输入：移动规范、业务部提出需求、开发自行新需求

活动：

☆产品经理结合移动规范、业务部提出的新需求或开发自行提出的新需求，对产

品进行整体规划；

☆产品经理根据产品规划，编写和制定《产品需求文档》；

☆产品需求文档输出后，产品经理须召集项目经理、开发人员、测试人员对产品

的详细需求进行分析、同步及讨论；

☆针对产品需求中日勺实现功能点，假如评估有波及到技术难点或风险点日勺，需要

做前期R勺技术调研工作。

输出：《产品需求文档》

负责人：产品经理

参与方：项目经理、开发人员、测试人员

5.2技术调研

输入：产品文档

活动：

☆针对产品设计讨论过程中所提出的技术性风险、难题进行前期技术调研，技术

调研都要有一定口勺深度，评测成果要真实可信，其他来源H勺数据仅能作为参照,

要以自己口勺测试成果为重要根据；

☆调研工作结束后，必须编写《技术调研汇报》，汇报中要有对■被调研技术的分析

和提议结论；

☆《技术调研汇报》完毕后，需要与有关人员共同评估被调研技术，评估完毕后，

针对该技术H勺调研工作完毕；

☆假如在调研过程中有波及到有关U勺代码和demo,需要在《技术调研汇报》中体

现，并阐明详细放置的途径。

输出:《技术调研汇报》、代码、Demo

负责人：开发人员

参与方：产品经理、项目经理

5.3软件需求文档（SRD）编写

5.3.1软件需求文档（SKD）编写

输入：产品需求文档

活动：

☆项目经理根据产品经理提供日勺PRD文档，将PRD文档转化为软件需求文档；

☆SRD文档重要内容包括：

★项目名称

★术语解释

★功能需求描述

★性能需求描述

★安全及可扩张性需求

★所参照H勺协议和规范（包括内部协议和外部协议）

★接口规定

★软硬件需求

★产品质量规定

★项目大体计划等

☆详细格式可参见《软件需求文档》模板

输出：《软件需求文档》

负责人：项目经理

参与方：产品经理、开发人员、测试人员

5.3.2SRD文档评审

输入：SRD文档

活动：

☆项目经理编写好SRD文档后，召集产品经理、开发人员、测试人员进行讨论、

评审，并输出评审汇报及修正后日勺SRD文档。

输出：评审汇报，修正后的JSRD文档

负责人：项目经理

参与方：产品经理、开发人员、测试人员

5.4项目预立项

输入：SRD文档

活动：

☆项目经理根据最终确定的SRD文档对项目进行预立项,对背面附匚作进行安排

和规划；

☆预立项工作重要是针对接下来的“项H整体方案设计”阶段进行规划和计划安

排；

☆项目整体方案设计重要涵盖如下四大部分：

★技术方案的设计（包括概要设计及详细设计）

★UI/UE时设计

★测试方案及测试用例口勺设计

★配置方案及计划的设计

输出：项目计划

负责人：项目经理

参与方：产品经理、开发人员、测试人员、配置管理员

5.5项目整体方案设计

5.5.1技术方案设计

5.5.1.1概要设计文档编写及评审

输入：PRD文档、SRD文档、项目计划

活动：

☆在SRD完毕后，需要开发人员对SRD、PRD进行系统分析工作；

☆必要时需要进行额外的技术调研，技术调研的流程仍参照5.2环节进行;

☆初步系统分析完毕后，需要编写《概要设计文档》；

☆概要设计文档至少包括内容：

★系统架构

★系统各模块的分解及功能阐明

☆针对《概要设计文档》进行评审，评审通过后初步系统分析完毕

☆详细格式可参见《概要设计文档》模板

输出：《概要设计文档》、评审汇报

负责人：技术负责人

参与方：开发人员、项目经理、技术总监、测试人员

5.5.1.2详细设计文档编写与评审

输入：SRD文档、《概要设计文档》、项目计划

活动:

☆开发人员根据SRD和《概要设计文档》，进行系统模块的划分和分解；

☆分模块进行系统分析，各个模块H勺系统分析完毕后，需要编写《详细设计文档》；

☆各子系统间的交互需要编写《系统内部接口文档》；

☆如本系统与其他系统有交互，需要编写《系统接口文档》；

☆针对《详细设计文档》、《系统内部接口文档》和《系统接口文档》须召集项目

经理、产品经理、开发人员、测试人员进行评审；

☆详细格式可参见《详细设计文档》、《系统内部接口文档》和《系统接口文档》

模板。

输出：《详细设计文档》、《系统内部接口文档》、《系统接口文档》、评审汇报

负责人：开发人员

参与方：项目经理、技术总监、测试人员

5.5.2测试方案及用例设计

5.5.2.1测试方案设计及评审

输入：PRD文档、SRD文档、《概要设计文档》、《详细设计文档》、《系统内部接口文档》

和《系统接口文档》

活动：

☆测试人员根据产品文档、需求文档及技术文档进行测试方案的编写；

☆测试方案包括：功能测试、性能测试、白盒测试;

☆测试方案编写完毕后，需要组织有关人员进行评审，并输出评审汇报;

☆测试方案评审后，测试、开发需双方到达确认。

输出：《测试方案》、测试方案评审汇报

负责人：测试人员

参与方：开发人员、项目经理、产品经理

5.5.2.2测试用例设计及评审

输入：测试方案、PRD文档、SRD文档

活动：

☆测试人员根据测试方案、产品文档及SRD文档进行测试用例的编写和分解:

☆测试用例包括：功能测试、性能测试、白盒测试；

☆测试用例编写完毕后，需要组织有关人员进行评审，并输出评审汇报；

☆测试用例评审后，测试、开发需双方到达确认。

输出：《测试用例》

负责人：测试人员

参与方：开发人员、项目经理、产品经理

5.5.3UI/UE设计（针对有界面展现的产品）

输入：PRD文档、SRD文档、项目计划

活动:

☆产品经理根据SRD文档、PRD文档对产品的UI/UE进行设计;

☆设计结束后，须召集项目经理、开发人员、测试人员进行评审。

输出：UI/UE设计文档

负责人：产品经理

参与方：开发人员、项目经理、测试人员

5.5.4配置管理方案及计划设计

输入：SRD文档、PRD文档、项目计划

活动：

☆项目经理根据SRD文档对项目H勺配置管理方案及计划进行设计；

☆配置管理方案重要涵盖如下内容：

★项目名：（供内部使用）

★公布版本命名及版本号：（每次版本公布时的版本命名及版本号控制，包括

从输出给测试部系统测试起一直到止式版本H勺公布。）

★Sharepoint：（项目文献目录”勺规划和设计）

★SVN：（目录的规划和设计）

★QC系统：（目录的规划和设计）

★资源配置

①人力资源

②设备资源

③其他无形资源（如开发环境软件、工具类等）

☆配置管理方案和计划设计结束后，须召集开发人员，测试人员，配置管理员进

行讨论及信息同步:

☆最终输出《配置管理方案和计划》，并同步给配置管理员作为后续项目配置管理

的根据。

输出：《配置管理方案和计划》

负责人：项目经理

参与方：开发人员、测试人员、配置管理员、运维人员

5.6项目正式启动准备

5.6.1项目计划制定

输入：PRD文档、SRD文档、整体方案设计

活动：

☆项目经理召集技术负责人进行计划预估及制定；

☆技术负责人须配合项目经理进行任务U勺分解和评估，同步对开发时间进行评估

（技术负责人在预估时间时可找对应要参与的直接工程师进行共同预估时间点,

以保证给出日勺时间尽量精确）；

☆评估日勺时间粒度原则上能让项目经理可有效的进行跟踪任务进展，详细的粒度

由项目经理根据项目实际状况进行把握（按照国内的项目管理通例，一般状况

下，最小粒度但愿能细到1天。）

☆项目计划所包括口勺维度须涵盖：

★服务器端开发

★客户端开发

★单元测试

★联调

★集成测试

★系统测试

★性能测试

★封板公布等

☆项目经理根据开发、测试评估的I计划，整顿出整个项目计划；

输出：项目计划

负成人：项目经理

参与方：开发人员、测试人员、运维人员、配置管理员

5.6.2项目组组员列表

输入：项目计划

活动：

☆项目经理根据项目计划中的人力资源，对所有项目组人员建立一份组员列袤；

☆需明确每位项目组组员的职责：

☆假如有波及到客户或第三方，也需要将其项目H勺负责人进行建立，以便保持后

续联络；

☆项目组员列表至少包括姓名、职责、、邮件等联络方式。

输出：项目组员列表

负责人：项目经理

参与方：开发人员、测试人员、运维人员、合作伙伴、配置管理员

5.6.3风险评估及管理

输入：项目计划、PRD文档、SRD文档、项目整体方案设计

活动：

☆项目经理需组织项目组组员对项目的风险进行识别和评估；

☆项目风险重要包括技术风险、资源风险等；

☆根据识别出口勺风险，项目组需要对其严重程度及影响面进行评估，以综合评估

风险的影响程度；

☆针对识别出来的风险，需要项目组共同讨论防止措施及应对措施，以防问题发

生，将风险降到最低点；

☆项目经理根据识别出的风险点及讨论后H勺防止措施，进行管理.，并跟进防止措

施的贯彻状况，并定期更新和维护风险管理表。

输出：风险评估和管理表

负责人：项目经理

参与方：开发人员、测试人员、运维人员

5.6.4项目质量目的的设计和制定

输入：SRD文档、项目计划

活动:

☆项目经理根据SRD文档和项目计划对项目在实行过程中日勺每个milestone,产品

所要完毕日勺功能及到达的质量目日勺进行设计和制定；

☆项目质量目口勺需要分解到每个大H勺里程碑；

☆质量目的和测试用例需要同开发人员进行讨论、同步；

☆项目质量目的重要涵盖内容如下：

★功能完毕度

★性能到达内规定

★本阶段日勺输入及输出

★本阶段质量所要到达日勺最终目的

★评判原则

★评判人员

输出：项目质量目的

负责人：项目经理

参与方：开发人员、测试人员、产品经理

5.6.5配置管理

输入：配置管理方案及「划

活动：

☆配置管理员收到项目经理H勺配置管理方案和计划书后。对项目实行过程中所使

用到的工具、系统、环境进行有关日勺配置；

☆目前波及到有关H勺工具，系统，环境是:

★Sharepoint：根据配置方案进行项目建立、目录的建立.及有关人员权限开通、

设置；

★QC系统：根据配置方案进行项目建立、目录的建立及有关人员权限开通、

设置；

★SVN：根据配置方案进行项目建立、目录的建立及有关人员权限开通、设置；

★版本管理：根据配置方案对版本公布地址、版本命名、版本号进行建立和管

理。

☆配置管理员对以.卜•的配置进行管理和维护，并输出项目配置表。

输出：项目配置表

负责人：配置管理员

参与方：项目经理、开发人员、测试人员、运维人员

5.7项目启动会议

输入：项目计划、团体组员列表、风险评估和管理表、项目质量目的、项目配置表

活动：

☆在项目启动准备工作就绪后，项目经剪发起会议并召集项目组所有人员进行kick

off会议；

☆会议重要讨论和明确内容如下：

①项目计划同步和确定

②项目组组员及职责的明确和确定

③对目前存在风险点进行同步和明确，并明确各风险点的负责人；

④对项目质量目的的明确和同步

⑤对项目配胃.方案/、J明确和同步

☆会议结束后，项目经理将以上5项讨论后的结论做最终整顿，并将其有关文档

提交到sharepoint上对应的文献目录下进行管理，以便项目组查询。

输出：项目计戈k团体组员列表、风险评估和管理表、项目质量目的、项目配置表

负责人：项目经理

参与方：开发人员、测试人员、运维人员

5.8编码实现及调试

5.8.1编码

输入：项目计划、PRD文档、SRD文档、技术方案设计文档

活动：

☆在项目启动会议结束后，开发在开始编码前，须建立并确定代码目录构造、文

献命名规则：

☆代码格式须遵照《Java代码编写规范》书写；

☆每隔2-3天，应将代码入库一次；

☆代码入库前必须完毕CodeReview

★准备进行CodeReview前，应当更新当地代码到最新版本；

★检查更新后口勺代码与否会导致BuildBreak；

★如没有问题，生成patch,将patch发送给Reviewer；

★Reviewer检查完代码，确认没有问题后，方可入库；

★入库代码假如导致BuildBreak,须在当日处理，并且入库更新的代码

☆开发过程中H勺多种讨论（技术讨论、需求讨论、测试讨论等）原则上都需要有

文档记录，可以通过SharePoint或者邮件来记录

☆对于BuildBreak、较严重或有代表性H勺Bug、重大设计错误等问题，需要进行Case

Study,每一次CaseStudy都需要有独立的文档，并且保留在SharePoint中

☆开发过程中如有并行开发的情形（例如同步修改多种Bug,或者Bug修改和代码

开发同步进行•，或者多种分支同步开发等），应当在自己日勺开发机器上建立多种

开发镜像，不应将代码混杂在一种工程中管理

☆在代码编写阶段，需要严格按照项目计划执行，并保证代码质量。

输出：代码

负责人：开发人员

参与方：项目经理

5.8.2单元测试

输入：项目计划、PRD文档、SRD文档、系统设计文档、产品代码

活动：

☆在代码实现过程中，须保证在在一种迭代周期内完毕单元测试（迭代周期视项

目详细状况而定）；

☆在一种迭代周期结束前，入库日勺代码须包括对应的单元测试代码；

☆单元测试代码入库前原则上也必须进行CodeReviewer；

☆单元测试的最终止果是保证迭代周期内的代码测试通过，以保证入库代码的质

量；

☆单元测试结束后，须输出对应H勺测试汇报，测试汇报原则上规定每项都是pass。

输出：单元测试代码、单元测试汇报

负责人：开发人员

参与方：项目经理

5.8.3联调

输入：编码完毕、单元测试完毕

活动：

☆在编码及单元测试完毕后，软件系统进入联调工作；

☆联调工作重要包括：

★子系统间接口、功能联调

★本系统与其他系统间的接口、功能联调

☆联调须保证各子系统间或互相调用的系统之间接口调通，正常流程的功能实现

正常，以作为进入下阶段集成测试奠定良好的基础；

☆联调结束后，须输出联调汇报（汇报模板和格式可根据项目实际状况进行设订）。

输出：联调汇报

负责人：开发人员

参与方：项目经理

5.8.4集成测试

输入：联调结束

活动：

☆联调结束后，开发需进行集成测试：

☆集成测试的测试方案和测试原则由测试部门提供；

☆通过集成测试，须保证各系统及系统间互相调用的功能、正常流程是正常内；

☆集成测试后，须输出集成测试汇报（汇报模板和格式可根据项目实际状况进行

设计，重点是保证功能已实现且正常流程跑通）；

☆集成测试的结论将作为与否准入系统测试的鉴定原则之一，假如集成测试不通

过，测试团体有权拒收提交口勺系统测试版本：

☆集成测试结束后，开发需将最新代码进行提交、入库。

输出：集成测试汇报

负责人：开发人员

参与方：项目经理.、测试人员、配置管理员

5.8.5提交系统测试申请

输入：集成测试汇报

活动：

☆集成测试通过后，开发人员将程序打包并提交到指定口勺服务器地址；

☆开发人员需填写《系统测试申请单》，申请单需通过有关人员签字后提交给测试

部和配置管理员；

☆系统测试申请单须包括如下内容：

★集成测试的成果

★安装包的寄存位置和地址

★代码的详细地址（包括SVN地址及SVN版本号）

输出:《系统测试申请单》

负责人：开发人员

参与方：项目经理、测试人员、配置管理员

5.8.6系统测试版本输出

输入：系统测试申请单

活动：

☆配置管理人员从开发手上拿到系统测试申请单后，按照开发申请单上所描述的

版本寄存位置卜载安装包，将版本备份到指定日勺服务器，并对版本进行统一管

理；

☆同步配置管理员需要审核开发所提交口勺安装包的版本命名和版本号与否对内；

☆保证没问题后，将告知测试人员到指定的位置取安装包；

输出：系统测试版本

负责人：配置管理人员

参与方：开发人员、项目经理、测试人员

5.9系统测试

5.9.1系统测试

输入：系统测试版本、测试用例、测试方案

活动：

☆测试负责人按照测试计划对测试用例对任务进行分解到每位测试人员，并保证

每条用例到详细负责人；

☆测试人员收到测试版本及测试任务后，进行测试工作；

☆测试人员口勺工作须按照测试计划进行，如出现与测试计划不符H勺，需及时提出，

并跟项目经理进行沟通；

☆测试过程中发现日勺bug提交及详细操作，请参照QC文档执行；

☆测试过程中，假如碰到严重问题而导致正常测试无法进行的，须第一时间

highlight出来给开发和项目经埋，开发接到问题后需第一时间安排分析处埋。问

题得到修正后，开发需要重新走到版本提交申请、输出的流程；

☆测试负责人需要每天反馈测试进展，并输出《每日测试汇报》；

☆一轮系统测试结束后，测试负责人需要公布一轮《系统测试总结汇报》；

输出：《每口测试汇报》、《系统测试总结汇报》

负货人：测试负责人

参与方：开发人员、项目经理、测试人员

5.9.2测试汇报评审

输入:测试汇报、buglist

活动：

☆项目经理收到测试部发出H勺系统测试总结汇报后,结合实际状况.发起测试汇

报评审的会议；

☆会议评审内容重要包括测试汇报的内容及QC中的buglist；

☆测试汇报评审日勺原则：

★测试汇报中与否已完毕该涵盖的用例：

★针对N/A内部分需要阐明详细原因，并确认目前与否确实无法测试：

★Fail项与否都已提交到QC系统中进行管理

☆BugList评审原则：

★需要对每个bug的J最新状态作确认；

★逐一讨论bug,对每个bug需要分析其严重程度、处理的优先级；

★每个bug需要明确详细的负责人和处理时间点；

★对某些bug临时不需要处理的（如需求不明确或严重程度低”勺），可做“挂

起”处理。但事后需要尤其对“挂起”问题，重新进行分析•、讨论，作为后

期完善、优化II勺一部分内容；

★针对“争议”类日勺bug需要项目组做尤其讨论，并给出处理的结论：

★其他有关bug的处理原则，详细详见QC文档执行。

☆根据评审完日勺汇报和buglist,需要深入明确下阶段版本更新、系统测试的时间

点以及测试范围；

☆根据评审日勺成果，项目组确定版本与否可到达封板目日勺。

输出：评审结论、会议记录

负责人：项目经理

参与方：开发人员、项目经理、测试人员

5.9.3开发debug

输入：buglist

活动：

☆开发人员需要积极查看分派给自己日勺Bug,并及时更新Bug状态；

☆当Bug修改完毕提交修改代码时，需要阐明如下事项：

★在提交到SVN时，，必须附带comment,并且在comment中阐明有关Bug号;

★同步修改Bug状态，在Bug中增长comment阐明有关代码提交时H勺Revisiono

☆针对Bug修改的代码提交时，原则上不容许如下状况：

★一次提交代码中包括多种Bug修改；

★一次提交代码中即包括Bug修改，又包括其他功能的开发代码

☆有关bug日勺处理原则，详细详见QC文档执行。

输出：评审结论、会议记录

负责人：项目经理

参与方：开发人员、项目经理、测试人员

5.10性能测试

输入：测试版本、测试式境

活动：

☆测试负责人按照测试计划对性能测试进行安排：

☆性能测试重要包括如下几方面：

★客户端方面：对功耗、流量、内存拥有率进行测试（详细测试内容视详细项

目和测试方案而定）；

★服务器方面：根据设定日勺对应使用指标进行测试（详细指标视不•样项目实

际状况和测试方案而定）：

☆测试结束后，须输出性能测试汇报，并把汇报发给项目经理、开发人员及有关

负责人；

☆测试汇报中，测试人员需要给出每项测试的结论；

输出：性能测试汇报

负责人：性能测试负责人

参与方：开发人员、项目经理、测试人员

5.11封板及代码冻结

5.11.1封板测试及封板

输入：系统测试完毕、性能测试完毕

活动:

☆测试负责人按照测试计划，完毕系统测试及性能测试的成果对产品进行最终一

轮封板测试；

☆封板测试结束后，须输出封板测试汇报；

☆根据封板测试汇报，召集项目组进行讨论、评估，以确定版本与否可到达封板

条件；

☆假如到达，测试负责人启动版本封板流程，并填写《版本封板申请单》，并提交

申请单给开发人员、项FI经理、配置管理员进行签字确认；

☆版本封板申请单所包括内容项，至少涵盖：

★各有关负责人确认成果

★封板测试的版本及版本号

★对应代码的SVN地址和版本号

★封板的结论和详细时间

☆最终将封板申请单提交给配置管理员，由配置管理员进行版本封存，对代码、

版本进行冻结、封存管理。

输出：封板测试汇报

负责人：测试负责人

参与方：开发人员、项目经理、配置管理员

5.11.2代码冻结

输入：版本封板申请单

活动，

☆配置管理员收到版本封板申请单后，根据申清单上对应日勺SVN地址和版本号对

代码、版本进行冻结和封存，并对SVN上的代码打Tag,同步对Tag进行尤其注

释；

☆冻结完毕后，配置人员需在《版本封板申请单》上填写代码冻结、版本封存的

结论、时间、地址及对应的SVN版本号，并告知给项目口勺有关人员；

☆在代码冻结之后，原则上严禁任何代码的提交，假如确实需要提交，需要部门

经理及配置管理员确认，以确定与否在原有基础上拉分支，方案确定后方可入

库。

输出：版本封板申请单

负责人：配置管理员

参与方：开发人员、项目经理、测试人员、开发经理

5.12生产环境布署、验证测试

5.12.1上线布署申请

输入：版本封板及代码冻结

活动：

☆上线前开发人员需要编写和准备《系统布署文档》和《上线手册》两份文档；

☆此两份文档需要提交给测试人员进行验证测试，验证通过后将文档提交给运维

部门；

☆开发人员收到配置管理员最终的版本封板和代码冻结成功后，根据项目计划提

交《上线布署申请单》；

☆上线布署申请单由测试负责人、项目经理、开发人员、运维人员共同讨论，确

定产品公布原则，并由各有关负责人签字确认；

☆最终将签字确认完H勺《上线布署申请单》提交给运维部门，由运维部门负责详

细时布署上线工作。

输出：上线布署申请单

负责人：开发人员

参与方：项目经理、测试人员、配置人员、运维人员

5.12.2布署上线

输入：上线布署申请单、系统布署文档、上线手册

活动：

☆运维部门收到上线布署申请单、布署文档及上线手册后，须安排人员进彳丁布署

工作；

☆布署结束后，假如发现布署文档或手册有问题，须及时反馈给开发负责人；

☆布署结束后，运维人员需要验证系统与否能正常运行，保证布署成功：

☆布署结束后，布署人员需耍提交一份《系统布署汇报》将最终止果告知给有关

的有关人员。

☆系统布署汇报须至少涵盖如下内容：

★参照有关布署文档口勺名称和版本号

★布署程序的版木名称和版木号

★完毕布署时间

★布署的结论（需要总结本次布署日勺感想和问题点）

输出：《系统布署汇报》

负责人：运维人员

参与方：项目经理、测试人员、配置人员、开发人员

5.12.3验证测试

输入：系统布署汇报

活动：

☆测试部门需要提前准备验证测试H勺测试方案和测试用例，测试方案和测试用例

需要召集项目组有关人员进行讨论、确定；

☆测试部门收到运维人员的系统布署汇报后，需启动验证测试；

☆测试部门按照测试方案和测试用例进行验证测试；

☆测试过程中假如发现问题，需要及时将问题告知给项目经理、开发人员及运维

人员等，项目经理得到告知后须第一时间召集项目组有关人员进行讨论，以确

定背面工作日勺安排；

☆验证测试通过后，测试部门须输出《验证测试汇报》，并告知项目组的有关人员。