项目验收流程说明书Word文件下载.docx

项目验收流程说明书Word文件下载.docx

《项目验收流程说明书Word文件下载.docx》由会员分享，可在线阅读，更多相关《项目验收流程说明书Word文件下载.docx（17页珍藏版）》请在冰豆网上搜索。

发方QA通过审核，则进入局方验收审批环节；

开发方QA未通过审核，则验收流程终止；

2.2开发方项目经理申请

开发方项目经理在通过开发方QA审核后，根据项目情况，对项目是否符合验收条件进行审核；

审核后，需在验收审批表上写明审核结果，并签字确认；

3用户确认阶段

纸质需求用例。

用户根据需求用例，对各项需求进行逐个测试验证，并在打印的纸制需求用例上进行签字确认是否通过。

所有需求用例测试验证完毕，用户在审批表中填写用户意见，并签字。

用户审批通过，提交委托方审核。

4委托方验收审核阶段

4.1委托方项目经理审核

委托方项目经理根据项目当前现状，综合评审，并确认审批意见。

4.2委托方软件设计师审核

开发方提供《系统上线申请表》全部通过的纸质证明。

开发方提供《软件上线部署报告》全部通过的纸质证明。

《系统上线申请表》参考附录一,5.2系统上线申请表；

《软件上线部署报告》参考附录二5.3软件上线部署报告；

4.2.11.提交资料

根据《软件上线部署报告》提交相应的资料，资料包括以下两类:

4.2.1.1文档类：

文档名称

要求

安装文档

根据该文档审核人员能够独立安装并运行项目程序

源代码说明文件

包含源代码说明层级，代码功能说明

上线申请表

检查局方审核签字的《上线申请表》

上线计划表

检查局方审核签字的《上线计划表》

数据库设计文档

包括该项目所涉及的表，视图，表空间，触发器，序列，存储过程等对象，审核人员根据文档到生产环境检查是否遗漏

文档中需要包含中文描述

数据初始化/配置说明文档

数据初始化/配置相关安装文件

概要设计文档

根据需要文档检查概要设计文档相关功能是否提及

详细设计文档

根据需要文档检查详细设计文档相关功能是否提及

4.2.1.2介质：

源代码

项目的源代码

安装包

项目的安装包，安装后能够运行

各种支撑软件

项目运行所需要的各种支撑软件

组件列表

支撑软件的列表

包含创建表，视图，表空间，触发器，序列，存储过程等对象的sql脚本

4.2.2.1集中权限整改评审

概述

根据移动运营支撑系统整合要求，需要对各子系统的权限进行整合。

集中用户权限管理系统是基于角色的访问控制的，在访问控制中引入了角色的概念，把对资源的访问权限分配给相应的角色，根据用户在组织内所承担的角色进行访问授权与控制。

根据应用系统的特点，我们把系统角色划分了通用角色和系统角色。

Ø

通用角色：

可以跨系统进行定义，对注册到集中也就是说一个通用角色，可以定义访问不同子系统的菜单权限，主要考虑门户系统的菜单权限

系统角色：

包括了“流程角色”和“操作角色”，不能跨系统进行定义。

系统工作流程

流程操作权限整合

流程和操作权限，是通过角色和用户信息关联来定位用户所具备的权限。

在集中权限管理系统定义角色，以及角色和用户的对应关系，子系统从集中用户权限管理系统中进行同步，根据子系统中定义的权限模型，验证用户所拥有的权限。

下面具体说明整合步骤。

第一步定义子系统所用户的系统角色，具体模版请使用附录“系统角色申请表”，举例说明如下：

系统名称

角色

角色属性（流程角色/操作角色）

角色职责

板件资源管理

系统管理员

操作角色

负责备品备件资源系统的维护工作，如权限添加、用户配置等；

板件审批员

负责部门内各专业的板件在报废等流程进一步审批

板件管理员

负责本专业备品备件资源的日常管理及“板件送修、更换”等流程的审批工作，负责定期进行本地备品备件资源情况统计清查；

仓库管理员

负责仓库备品备件的出入库管理、清点及核对、发起板件送修及报废申请操作

资产管理员

负责板件报废等资产相关工作的审核

维护人员

负责在故障抢修需要备品备件时，发起板件更换流程；

第二步定义系统角色申请样列。

申请样列，定义了子系统流程或者操作角色的权限模型，具体模版请使用附录“系统角色申请表”，举例说明如下，其中：

归属单位、归属部门、管理专业、管理跨度（管理部门，可以多选）是用户的维度信息，子系统根据角色和维度信息组合，确定该用户所拥有的权限。

归属单位：

包括省公司、分公司和县公司，格式参考如下，『移动.省公司』、『移动.福州分公司』、『移动.福州分公司.平潭县公司』

归属部门：

根据不同的单位，具有不同的部门

管理专业：

按照系统来分，不同的系统，管理的专业不同

管理跨度：

和归属部门一下，可以进行多选

角色属性：

包括流程角色和操作角色

系统名称.角色名称

姓名

归属单位

归属部门

管理专业

管理跨度（部门，可以多选）

角色属性

板件资源管理.仓库管理员

张三

移动.福州分公司

网络部

第三步系统角色和角色申请样列提交给局方相关人员进行评审，审核通过后，通过“系统角色申请”流程，完成子系统流程或操作角色的申请。

第四步子系统权限改造。

子系统必须严格按照评审通过后的权限模型进行权限改造，通过角色和用户的维度信息，包括归属单位、归属部门、管理专业、管理跨度，来验证用户所拥有的流程和操作权限。

注：

子系统中所包含的角色必须和集中权限的系统角色是一致的，不允许子系统中通过集中给出的角色再进行组合，定义新的角色。

4.2.2.2权限，错误页面整改

整改注意点:

1.权限和错误页面不能使用绝对地址，因为门户可以由网和OA网访问

4.2.3编译测试

编译要求：

不允许出现编译错误（Error）。

当出现编译错误时，需要记录错误原因并修改错误。

4.2.4上线部署

上线要求：

能够和正式环境中部署的程序版本相对应，没有出现功能增加和减少。

4.3委托方质量保证员审核

质量保证员如发现需求用例与实际不符即可退回至用户，重新验收确认。

验收证书（盖章）、委托书（复印版）、验收手册、软件上线申请书、软件上线部署报告、

4.3.2电子文档

按照以下目录树提供电子文档，并按照文档的命名规范提供。

项目名称

|_需求开发（需求规格说明书）

|_项目策划（项目计划、关键WBS检查单、风险列表）

|_系统设计（概要设计、详细设计、数据库详细设计说明文档）

|_实现与测试

|_测试（测试用例、测试报告）

|_源代码（源代码说明文档）

|_系统上线（上线申请表、上线计划表、上线部署报告）

|_系统验收

|_相关文档（验收手册、遗留问题、培训手册（课件）、用户手册、维护手册、安装手册）

|_补丁包（补丁包、补丁加载记录表）

图1：

宋体，小五，对中

电子文档命名规范见3命名规范

4.4委托方开发经理审批

委托方开发经理根据所有验收过程的结果，综合评审，并确认审批意见。

5附录一

5.1验收审批表

验收审批表

委托书编号：

填写委托书的公文编号

项目名称：

填写合同中约定的项目名称

项目类型：

软件开发类

工程建设类

申请人：

填写厂家项目经理姓名

遗留问题及解决方案

开发方QA：

签字：

日期：

开发方项目经理：

用户意见:

签字：

日期：

委托方项目经理审批

验收手册

意见：

日期:

委托方软件设计师审批

委托方质量保证员审批

代码审查报告

结论：

提交软件上线申请，并按照软件上线部署报告进行部署。

签字：

日期：

配置文档审核

电子文档入库

纸质文档入库

通过门户上线检查

委托方开发经理审批

1、该文档为纸质打印版文档，如需加页，请双面打印。

2、“”中填写、或N/A。

“”表示不通过,“”表示通过,“N/A”表示不适用。

3、开发经理的签字通过日期作为该项目的验收通过日期。

5.2系统上线申请表

5.3软件上线部署报告

软件上线部署报告

5.3.1软件清单检查表

所影响的系统

计划上线时间

最迟上线时间

部署材料清单

编号

检查内容

清单列表

是否完整

1.

□是□否

2.

3.

4.

5.

6.

《上线申请表》

7.

《上线计划表》

8.

9.

10.

数据库初始化/配置说明文档

11.

数据库初始化/配置相关安装文件。

12.

13.

14.

集中权限整改，测试

15.

权限，错误页面整改

问题列表

问题编号

问题描述

解决情况

□通过□不通过

双方代表签字：

5.3.2编译测试报告

开始时间

结束时间

地点

编译机IP

操作系统

编译环境

审查人员

开发方人员

编译过程

问题原因

5.3.3上线部署报告

地点

部署目标机IP

部署目录

部署过程

6附录二输出物命名规范

类型

配置项

命名规则

文档标识

管理

项目建议书

项目名称_M_项目建议书_版本号

Project_M_PRP_yyyymmdd

项目计划

项目名称_M_项目计划_版本号

Project_M_PP_yyyymmdd

项目周报

项目名称_M_项目周报_日期

Project_M_PWR_yyyymmdd

配置管理

项目名称_M_配置管理计划_版本号

Project_M_SCMP_yyyymmdd

质量保证

项目名称_M_质量保证计划_版本号

Project_M_SQAP_yyyymmdd

项目名称_M_质量保证报告_日期

Project_M_SQAR_yyyymmdd

评审计划及报告

项目名称_M_评审计划及报告_项目计划_日期

Project_M_TRR_PP_yyyymmdd

项目名称_M_评审计划及报告_需求评审报告_日期

Project_M_TRR_SRS_yyyymmdd

项目名称_M_评审计划及报告_概要设计_日期

Project_M_TRR_HLD_yyyymmdd

变更控制

项目名称_M_需求变更控制报告_日期　

ProjName_M_CCR_SRS_yyyymmdd

项目名称_M_项目计划变更控制报告_日期　

ProjName_M_CCR_PP_yyyymmdd

项目名称_M_配置项变更控制报告_日期　

ProjName_M_CCR_CC_yyyymmdd

需求开发

用户需求说明书

项目名称_P_用户需求说明书_版本号

Project_P_CRS_Version

需求规格说明书

项目名称_P_需求规格说明书_版本号

Project_P_SRS_Version

系统开发

概要设计说明书

项目名称_P_概要设计说明书_版本号

Project__P_HLD_Version

详细设计说明书

项目名称_P_详细设计说明书_版本号

Project_P_DDS_Version

数据库设计说明书

项目名称_P_数据库设计说明书_版本号

Project_P_DBD_Version

开发计划

项目名称_开发计划_[模块]

Project_P_SDP_[module]_Version

开发测试文档

项目名称_P_测试用例_[模块]_版本号

Project_P_ETC_[module]_Version

项目名称_P_测试报告_[模块]_版本号

Project_P_ETR_[module]_Version

项目名称_P_源代码_版本号

系统验收

用户测试文档

项目名称_P_用户接受测试BUG列表及问题跟踪报告_版本号

项目名称_P_验收报告_[模块]_版本号

Project_P_LAP_[module]_Version

安装手册

项目名称_P_安装手册_版本号

Project_P_SIM_[module]

用户手册

项目名称_P_用户手册_版本号

Project_P_SUM_[module]

维护手册

项目名称_P_维护手册_版本号

Project_P_SMM_[module]

培训手册

项目名称_P_培训手册_版本号

项目质量评估报告

项目名称_项目质量评估报告_yyyymmdd

Project_P_PER_[module]

项目名称_P_安装包_版本号

其他文档

项目名称_M/P_XXX_XXX

7附录三文档命名规则

项目名称_类型_文档名称_版本标识

举例：

板件资源管理_M_项目周报_20051123

板件资源管理；

类型：

M/P，M表示管理类，P表示产品类

版本标识：

M类文档，采用日期格式：

YYYYMMDD

P类文档，采用版本标识：

以大写V+版本号，配置项的版本号与配置项的状态紧密相关。

1.版本号的命名规则

✧处于草稿状态的配置项版本号格式为：

0.YZ。

YZ的数字范围为01～99。

随着草稿的不断完善，“YZ”的取值递增。

“YZ”的初值和增幅由用户自己把握。

✧处于“正式发布”状态的配置项的版本格式为X.Y。

X为主版本号，取值范围为1～9。

Y为次版本号，取值范围1～9。

配置项第一次正式发布时，版本号为1.0。

如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。

只有当配置项的版本升级幅度比较大时，才允许增大X值。

✧处于“正在修改”状态的配置项的版本号格式为：

X.YZ。

配置项正在修改时，一般只增大Z值，X、Y保持不变。

当配置项修改完毕，状态重新写成“正式发布”时，将Z值设置为0，增加X.Y值。

8附录四版本历史

版本号

日期

作者

参与者

说明

备注

V1.0

2009-7-09

杨婕

黄海辉

正式发布

2010-11-24

马骏

倪志刚

修订稿