项目验收流程说明书.docx
《项目验收流程说明书.docx》由会员分享，可在线阅读，更多相关《项目验收流程说明书.docx（17页珍藏版）》请在冰豆网上搜索。
项目验收流程说明书
项目
验收要求
目录
1验收流程4
2开发方申请阶段5
2.1开发方QA审批5
2.2开发方项目经理申请5
3用户确认阶段6
3.1提交资料：
6
4委托方验收审核阶段7
4.1委托方项目经理审核7
4.2委托方软件设计师审核7
4.2.11.提交资料7
4.2.2门户集成整改：
8
4.2.3编译测试11
4.2.4上线部署11
4.3委托方质量保证员审核11
4.3.1需要提供的纸质材料：
11
4.3.2电子文档11
4.4委托方开发经理审批11
5附录一13
5.1验收审批表13
5.2系统上线申请表14
5.3软件上线部署报告14
5.3.1软件清单检查表15
5.3.2编译测试报告16
5.3.3上线部署报告17
6附录二输出物命名规范18
7附录三文档命名规则19
8附录四版本历史19
1验收流程
验收流程图:
2开发方申请阶段
2.1开发方QA审批
开发方QA审查人员，需严格通过QA审核，并在验收审批表上写明审核结果，签字确认。
发方QA通过审核，则进入局方验收审批环节；
开发方QA未通过审核，则验收流程终止；
2.2开发方项目经理申请
开发方项目经理在通过开发方QA审核后，根据项目情况，对项目是否符合验收条件进行审核；审核后，需在验收审批表上写明审核结果，并签字确认；
3用户确认阶段
3.1提交资料：
纸质需求用例。
用户根据需求用例，对各项需求进行逐个测试验证，并在打印的纸制需求用例上进行签字确认是否通过。
所有需求用例测试验证完毕，用户在审批表中填写用户意见，并签字。
用户审批通过，提交委托方审核。
4委托方验收审核阶段
4.1委托方项目经理审核
委托方项目经理根据项目当前现状，综合评审，并确认审批意见。
4.2委托方软件设计师审核
开发方提供《系统上线申请表》全部通过的纸质证明。
开发方提供《软件上线部署报告》全部通过的纸质证明。
《系统上线申请表》参考附录一,5.2系统上线申请表；
《软件上线部署报告》参考附录二5.3软件上线部署报告；
4.2.11.提交资料
根据《软件上线部署报告》提交相应的资料，资料包括以下两类:
4.2.1.1文档类：
文档名称
要求
安装文档
根据该文档审核人员能够独立安装并运行项目程序
源代码说明文件
包含源代码说明层级，代码功能说明
上线申请表
检查局方审核签字的《上线申请表》
上线计划表
检查局方审核签字的《上线计划表》
数据库设计文档
包括该项目所涉及的表，视图，表空间，触发器，序列，存储过程等对象，审核人员根据文档到生产环境检查是否遗漏
文档中需要包含中文描述
数据初始化/配置说明文档
数据初始化/配置相关安装文件
概要设计文档
根据需要文档检查概要设计文档相关功能是否提及
详细设计文档
根据需要文档检查详细设计文档相关功能是否提及
4.2.1.2介质：
源代码
项目的源代码
安装包
项目的安装包，安装后能够运行
各种支撑软件
项目运行所需要的各种支撑软件
组件列表
支撑软件的列表
数据初始化/配置相关安装文件
包含创建表，视图，表空间，触发器，序列，存储过程等对象的sql脚本
4.2.2门户集成整改：
4.2.2.1集中权限整改评审
概述
根据移动运营支撑系统整合要求，需要对各子系统的权限进行整合。
集中用户权限管理系统是基于角色的访问控制的，在访问控制中引入了角色的概念，把对资源的访问权限分配给相应的角色，根据用户在组织内所承担的角色进行访问授权与控制。
根据应用系统的特点，我们把系统角色划分了通用角色和系统角色。
Ø通用角色：
可以跨系统进行定义，对注册到集中也就是说一个通用角色，可以定义访问不同子系统的菜单权限，主要考虑门户系统的菜单权限
Ø系统角色：
包括了“流程角色”和“操作角色”，不能跨系统进行定义。
系统工作流程
流程操作权限整合
流程和操作权限，是通过角色和用户信息关联来定位用户所具备的权限。
在集中权限管理系统定义角色，以及角色和用户的对应关系，子系统从集中用户权限管理系统中进行同步，根据子系统中定义的权限模型，验证用户所拥有的权限。
下面具体说明整合步骤。
Ø第一步定义子系统所用户的系统角色，具体模版请使用附录“系统角色申请表”，举例说明如下：
系统名称
角色
角色属性（流程角色/操作角色）
角色职责
板件资源管理
系统管理员
操作角色
负责备品备件资源系统的维护工作，如权限添加、用户配置等；
板件资源管理
板件审批员
操作角色
负责部门内各专业的板件在报废等流程进一步审批
板件资源管理
板件管理员
操作角色
负责本专业备品备件资源的日常管理及“板件送修、更换”等流程的审批工作，负责定期进行本地备品备件资源情况统计清查；
板件资源管理
仓库管理员
操作角色
负责仓库备品备件的出入库管理、清点及核对、发起板件送修及报废申请操作
板件资源管理
资产管理员
操作角色
负责板件报废等资产相关工作的审核
板件资源管理
维护人员
操作角色
负责在故障抢修需要备品备件时，发起板件更换流程；
Ø第二步定义系统角色申请样列。
申请样列，定义了子系统流程或者操作角色的权限模型，具体模版请使用附录“系统角色申请表”，举例说明如下，其中：
归属单位、归属部门、管理专业、管理跨度（管理部门，可以多选）是用户的维度信息，子系统根据角色和维度信息组合，确定该用户所拥有的权限。
归属单位：
包括省公司、分公司和县公司，格式参考如下，『移动.省公司』、『移动.福州分公司』、『移动.福州分公司.平潭县公司』
归属部门：
根据不同的单位，具有不同的部门
管理专业：
按照系统来分，不同的系统，管理的专业不同
管理跨度：
和归属部门一下，可以进行多选
角色属性：
包括流程角色和操作角色
系统名称.角色名称
姓名
归属单位
归属部门
管理专业
管理跨度（部门，可以多选）
角色属性
板件资源管理.仓库管理员
张三
移动.福州分公司
网络部
操作角色
Ø第三步系统角色和角色申请样列提交给局方相关人员进行评审，审核通过后，通过“系统角色申请”流程，完成子系统流程或操作角色的申请。
Ø第四步子系统权限改造。
子系统必须严格按照评审通过后的权限模型进行权限改造，通过角色和用户的维度信息，包括归属单位、归属部门、管理专业、管理跨度，来验证用户所拥有的流程和操作权限。
注：
子系统中所包含的角色必须和集中权限的系统角色是一致的，不允许子系统中通过集中给出的角色再进行组合，定义新的角色。
4.2.2.2权限，错误页面整改
整改注意点:
1.权限和错误页面不能使用绝对地址，因为门户可以由网和OA网访问
4.2.3编译测试
编译要求：
不允许出现编译错误（Error）。
当出现编译错误时，需要记录错误原因并修改错误。
4.2.4上线部署
上线要求：
能够和正式环境中部署的程序版本相对应，没有出现功能增加和减少。
4.3委托方质量保证员审核
质量保证员如发现需求用例与实际不符即可退回至用户，重新验收确认。
4.3.1需要提供的纸质材料：
验收证书（盖章）、委托书（复印版）、验收手册、软件上线申请书、软件上线部署报告、
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.
权限，错误页面整改
□是□否
问题列表
问题编号
问题描述
解决情况
1.
2.
3.
4.
5.
6.
7.
结论：
□通过□不通过
双方代表签字：
5.3.2编译测试报告
开始时间
结束时间
地点
编译机IP
操作系统
编译环境
审查人员
开发方人员
编译过程
问题列表
问题编号
问题描述
问题原因
解决情况
1.
2.
3.
结论：
□通过□不通过
双方代表签字：
5.3.3上线部署报告
开始时间
结束时间
地点
部署目标机IP
操作系统
部署目录
审查人员
开发方人员
部署过程
问题列表
问题编号
问题描述
问题原因
解决情况
1.
2.
结论：
□通过□不通过
双方代表签字：
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
杨婕
黄海辉
正式发布
V1.0
2010-11-24
马骏
倪志刚
修订稿
升级会员 