xx银行IT应用系统开发管理规定.doc

上传人:文库蛋蛋多 文档编号:3792968 上传时间:2023-03-22 格式:DOC 页数:43 大小:646.50KB
返回 下载 相关 举报
xx银行IT应用系统开发管理规定.doc_第1页
第1页 / 共43页
xx银行IT应用系统开发管理规定.doc_第2页
第2页 / 共43页
xx银行IT应用系统开发管理规定.doc_第3页
第3页 / 共43页
xx银行IT应用系统开发管理规定.doc_第4页
第4页 / 共43页
xx银行IT应用系统开发管理规定.doc_第5页
第5页 / 共43页
点击查看更多>>
资源描述

《xx银行IT应用系统开发管理规定.doc》由会员分享,可在线阅读,更多相关《xx银行IT应用系统开发管理规定.doc(43页珍藏版)》请在三一办公上搜索。

1、龙江银行IT应用系统开发管理规定第一章 总 则第一条 为了明确总行及各分行在应用开发类项目活动中的职责,规范系统开发流程,特制定本规定。第二条 本规定适用于总行及各分行科技条线以及相关业务条线IT应用系统开发的管理。第三条 本规定所称管理对象是指对总行及各分支行在应用开发类项目管理活动及工程活动的管理过程。第四条 本规定所称项目生命周期是指从科技条线完成项目方案开始直至项目关闭。应用类软件开发项目关闭条件须同时满足项目投产后五周且提交项目验收材料。第五条 本规定所称项目承担部门和项目运行部门分别是指总行科技条线的开发管理部和运行管理部。第六条 本规定所称应用主管部门是指总行科技条线及各相关业务

2、条线。第七条 本规定所称需求变更是指应用主管部门在项目关闭前对业务需求分析说明书中的需求内容进行调整。第八条 工程活动是指在项目生命周期内除管理活动之外的,与技术相关的各项活动,主要包括软件需求分析、总体设计、软件需求设计、系统设计、程序设计、编码、代码检查、单元测试、集成测试、系统测试、验收及投产等。工程活动可以根据项目的规模、性质等特性进行相应的裁剪。第九条 IT应用系统的开发管理应遵循统一规划、统一需求、统一设计、统一开发平台的原则。第二章 岗位与职责第十条 核心系统或涉及核心业务管理及流程方面的需求,由总行运营管理条线结算业务管理部负责提出;涉及信贷系统方面的需求,由总行信贷管理条线信

3、贷资产管理部负责提出;中间业务类需求,由总行机构业务条线中间业务部负责提出;技术优化改造类需求,由总行科技条线开发管理部负责提出;其它应用系统需求根据具体情况确定负责部门。第十一条 应用主管部门下设业务代表,该业务代表属于项目组成员;项目承担部门下设审批经理、项目经理、项目组成员;项目运行部门下设非功能性需求研究岗。第十二条 业务代表的主要职责:(一)作为应用主管部门指定的授权人。(二)负责与第三方之间的沟通协调,取得第三方需求文档、技术接口文档,明确联调时间和投产时间等要求。(三)负责与第三方协调开发及测试环境,要求第三方保证项目开发期间内的环境支持和技术支持。(四)负责处理业务需求的有关事

4、项,协助项目组进行需求分析。(五)负责项目组与业务条线之间的沟通协调,参加业务需求分析说明书的评审。(六)负责编制业务测试计划(见附件6)和业务测试案例(见附件7)。(七)负责提交正式的测试验收报告。第十三条 审批经理的主要职责:(一)负责项目的项目方案、外部技术资源申请、需求变更申请等要求的审批工作。(二)负责协调解决项目组内部无法解决的问题和风险。(三)负责组织技术风险较大项目的项目方案评审工作。(四)负责跟踪监督项目实施情况。(五)负责协调处理项目相关问题。第十四条 项目经理的主要职责:(一)负责项目的管理工作,组织制定上报项目的项目方案和项目计划、变更方案、需求变更申请、外部技术资源申

5、请等。(二)负责项目的各类工程活动的组织、实施。(三)负责接收任务和内部任务的下达工作,对项目状况进行跟踪和监控,收集报告实施过程中的问题和风险,确保项目按时、保质完成。第十五条 项目组成员的主要职责:负责项目中开发、测试等各类工程活动的实施。第十六条 非功能性需求研究岗的主要职责:(一)参与项目承担部门组织的非功能性需求说明书评审。(二)分析非功能性需求说明书对生产运行的影响并确认其内容。第十七条 项目组各岗位对照关系(一)业务代表由总、分行各条线业务人员构成。(二)审批经理由总行科技条线管理人员担任。(三)项目经理由总行科技条线开发人员担任。(四)项目组成员由总行科技条线开发人员、总分行各

6、条线业务人员构成。(五)非功能性需求研究岗由总行科技条线运行管理部人员担任。第三章 立 项 第十八条 提出需求(一)总行或分行业务需求部门提出新产品项目需求时,应首先编写可行性分析报告(见附件5)及业务需求书(见附件4),经过条线领导审批后,提交给总行相关业务条线,由总行相关业务条线作为应用主管部门提交总行科技条线。(二)总行应用主管部门,首先对总行或分行业务需求部门提出的可行性分析报告(见附件5)及业务需求书(见附件4)进行业务分析,确认项目是否可行。(三)总行应用主管部门应指定业务代表,由业务代表与项目承担部门沟通协调,提交可行性分析报告(见附件5)及业务需求书(见附件4),配合项目承担部

7、门进行需求分析。第十九条 可行性研究(一)项目需求分析阶段的首要工作是对业务需求进行技术可行性分析,并编写业务需求分析说明书,同时估算工作量。(二)项目经理负责组织对业务需求进行技术可行性分析,对于存在的技术风险、安全性设计问题和需求合理性等问题提出分析意见。第二十条 立项申请(一)对于通过技术可行性分析的业务需求,应将分析意见反馈给应用主管部门。(二)对于不可行的技术问题出具技术可行性分析报告,由审批经理审批后,同时反馈给应用主管部门。(三)对于通过可行性分析的业务需求,应用主管部门应填写项目立项审批表(见附件2)经相关条线和主管行长进行项目立项审批,如果项目复杂度较高,影响范围较大,涉及专

8、业超过两个以上则需经行长审批。第二十一条 审批项目立项审批表(见附件2)经过相关领导审批通过后,将项目立项审批表(见附件2)、业务需求书(见附件4)及可行性分析报告(附件5)提交科技条线,科技条线可视情况直接进入功能设计、系统设计或程序设计等阶段。其测试验收及投产阶段需按本规定执行。第二十二条 立项(一)对于已有产品进行升级改造的需求,规模大于15人天的项目须进行科技立项。(二)对于已有产品的需求变更工作量小于15人天的,可以不进行科技立项,但必须由应用主管部门提交正式的业务需求单(见附件3)。(三)科技条线根据实际情况确定自行开发还是项目外包,自行开发按照本规定执行,项目外包参照计算机软件外

9、包管理规定。第四章 开 发第二十三条 总体设计(一)项目总体设计阶段的主要工作是编写项目的项目方案。(二)项目经理负责组织项目方案编写工作,项目方案应对系统的技术实现手段、系统与系统外部逻辑关系及系统内部的关键逻辑结构进行描述,项目经理应该协调组织对项目方案的评审;对于对安全生产和客户服务有重大影响的项目,项目方案必须进行正式评审。第二十四条 功能设计(一)项目功能设计阶段的主要工程活动是编写业务需求分析说明书,对安全生产有重大影响的项目须编写非功能性需求说明书。(二)项目经理负责组织业务代表以及相关人员对获取的业务需求书进行分析,形成业务需求分析说明书。业务需求分析说明书作为与应用主管部门进

10、行确认和验收的文档。(三)业务需求分析说明书在提交应用主管部门确认前,需进行评审,确保需求的一致性和正确性。(四)业务需求分析说明书完成后,反馈给应用主管部门进行确认。应用主管部门需要在十个工作日内将确认意见返回项目承担部门。(五)非功能性需求说明书的编制和评审:1.项目经理应根据项目的实际情况,组织相关人员对非功能性的需求进行分析,对安全生产有重大影响的项目和对项目运行环境有特殊要求的,应该形成非功能性需求说明书。2.总行科技条线运行管理部应组织研究分析非功能性需求说明书对生产系统的影响,结合总行生产运行维护要求提出修改完善建议,并在七个工作日内将确认意见返回总行科技条线开发管理部。第二十五

11、条 系统设计(一)项目经理应组织项目组成员进行系统设计,根据实际情况编写系统规格书或程序规格书;项目经理可以根据实际情况组织编写数据库设计说明书、接口说明书等文档。(二)项目经理应组织项目组成员依据系统规格书编写程序规格书。(三)在项目实施过程中因设计变更或需求变更引起的系统设计和程序设计的调整,须组织对系统规格书和程序规格书进行修订。(四)对已有产品进行升级改造的项目和小型项目,只需编写程序规格书。对已有产品进行升级改造的项目需编写与原系统差异对照详细的说明文档。第五章 测 试第二十六条 项目编码及测试阶段的工程活动通常包括:编码、代码检查、单元测试、集成测试、系统测试等活动。第二十七条 项

12、目经理应组织项目组成员根据程序规格书进行编码,并组织进行代码检查或评审。第二十八条 单元测试由项目组完成,项目承担部门可根据实际情况,有选择地进行项目的集成测试和系统测试。第二十九条 项目经理应该按照项目计划时间要求,确定测试目标、测试范围、测试软硬件配置、测试规模分析等内容,协助业务条线编写业务测试计划(见附件6)和业务测试案例(见附件7)。第三十条 项目进入测试执行阶段后,项目经理负责组织测试工作,并监控测试执行过程。第三十一条 项目组在测试执行过程中,应详细、准确地记录测试问题,跟踪问题处理情况,直到测试问题关闭。第三十二条 在测试完成后,业务条线应完成测试报告、用户手册、培训教材;科技

13、条线应完成安装维护手册、版本说明书、投产方案等项目文档的编制工作。第三十三条 对于已有产品进行升级改造的项目,业务代表应根据项目组提供的新老系统差异对照说明重新修订用户手册反馈应用主管部门。第六章 验 收第三十四条 验收成员验收人员由总行相关领导、总行科技条线相应人员和总行业务条线相应人员构成。第三十五条 验收(一)验收测试应具体包括用户功能、业务流程、安装测试、备份恢复测试等方面的测试:1.项目经理协助组织实施验收测试工作。2.业务代表根据业务测试计划(见附件6)和业务测试案例(见附件7)完成验收测试,并记录测试结果。3.业务代表、项目经理和项目组成员应该协调测试过程中发现的各种问题,并对项

14、目测试风险和软件产品缺陷进行跟踪和管理。(二)项目组应该保证验收测试环境正常运行,并使环境尽量接近投产目标环境;项目经理应跟踪项目验收测试的情况,收集项目在验收测试中发现的问题并组织协调解决。(三)验收测试通过后,由应用主管部门在五个工作日内出具书面测试验收报告(见附件8),加盖部门公章,经相关部门审批后,提交科技条线安排进行项目投产。第三十六条 验收不合格的处理如果项目没有通过验收,需重新进行相应模块的开发、测试。第七章 推 广第三十七条 投产(一)项目运行部门根据项目投产方案,组织在生产环境进行投产。项目投产后,项目经理跟踪项目投产后的运行情况,收集项目在投产运行中发现的生产问题。项目投产

15、后,应对项目软件产品版本进行归档管理。(二)在投产过程中因不确定因素导致投产失败,项目组应查明原因,若是纯技术问题,待问题解决后可再次直接投产;否则应该重新进行测试,待测试通过后,方可再次发起投产。对于投产后发现的生产问题,项目承担部门应及时组织研发生产补丁,解决生产问题。(三)根据项目投产部门要求,项目组成员可在项目投产阶段进行技术支持。第三十八条 后期管理(一)项目的工程活动须根据本规定执行,及时完成项目文档的交付件,其内容可根据实际情况裁剪执行。(二)对于因政策性要求且时间紧迫的项目,项目的相关活动可以并行进行。(三)总行科技条线根据自身实际情况,按照本规定对本单位的项目工程活动进行评价

16、和分析。(四)总行科技条线根据自身实际情况,组织对项目工程实施过程进行监控,监督检查项目工程实施过程是否有效。(五)总行科技条线根据项目的进度和定期的评估报告,制定项目工程活动的改进计划。(六)根据改进计划,对项目工程活动进行持续改进,对影响项目工程活动的各方面因素进行调整和优化。第三十九条 资料归档科技条线及相关业务部门进行资料的归档。第八章 附 则第四十条 本规定由龙江银行科技条线统一解释和修改。第四十一条 本规定自印发之日起施行。参考文件1.科技档案管理规定2.软件开发外包管理规定附件:1.IT应用系统开发流程图 2.项目立项审批表 3.业务需求单 4.业务需求书 5.可行性分析报告 6

17、.业务测试计划 7.业务测试案例 8.测试验收报告附件1:附件2:项目立项审批表项目名称提出单位联系人联系电话NOTES邮箱项目概况:应用主管部门意见联系人联系电话Notes邮箱部门负责人审批意见:(签字、盖章)开发管理部意见:负责人审批意见:风险管理部意见:负责人审批意见:行长审批意见: 项目编号: 年 月 日附件3:业务需求单业务需求发起部门主管部门协办部门联系人联系电话NOTES邮箱详细需求描述:(具体到交易码、科目号及详细流程,涉及打印格式调整的需附打印格式样本)部门负责人: 日期: 部门公章应用主管部门意见: 部门负责人: 责任人: 日期: 协办部门意见: 部门负责人: 日期: 开发

18、管理部意见: 计划完成时间:部门负责人: 责任人: 日期: 投产验收情况:责任人: 日期:附件4:项目编号: XXXXXXX 项 目业务需求书年 月 日龙江银行文档属性属性内容立项部门:XXXXXX部门文档标题:XXXXXX项目业务需求书文档编号:建议为部门名称项目名称首字母缩写文档版本号:如V1.0文档编写完成日期:编写人:审核者:编写人联系电话:NOTES联系邮箱:编写说明:本模板是业务需求书的公共模板,为适应我行业务快速稳定发展,各专业部门在要求千差万别的情况下也有很强的创新性,此模板虽具一定代表性,但可能存在不完全适应业务需要的情况。因此,业务部门在编写过程中可参照此格式编写,也可以实

19、用性为原则在此基础上合理裁减,只要完整详尽表明业务需求本意即可。目 录第一章 项目概述211.1 项目背景211.2 业务目标和意义211.3 指导思想和基本原则211.4业务定位211.5投产范围及用户21第二章 功能概述222.1 术语定义222.2 业务规则222.3 总体结构222.3.1 业务流程图222.3.2主要功能模块232.3.3 账户体系232.4 主要功能232.5 参数设计232.6 交易渠道和介质232.7 服务时间和运行要求24第三章 功能详述243.1 功能编号243.2 功能名称253.3 功能说明253.3.1 本模块功能253.3.2 用户权限要求253.3

20、.3 与其他模块的关系253.3.4 交易渠道253.3.5 介质253.4 输入要素253.4.1 输入要素253.4.2 输入画面253.4.3 输入要素说明253.4.4 输入要素间的控制263.5 处理要求263.6 输出要素263.7 记账处理263.8 后督26第四章 清算及对账处理264.1 清算处理264.2 差错处理274.3 对账处理274.3 其他账务处理要求27第五章 非业务功能类需求275.1数据移行275.2业务应急处理要求275.3 数据存贮和清理275.4其他非业务功能的要求或建议28附件:报表及凭证式样28附录1:打印输出凭证/凭条格式28附录2:打印输出清单

21、格式28附录3:报表格式28附录4:参考资料(如:有关文件、纪要、其他资料)28第一章 项目概述业务需求书的概述部分,主要描述项目背景、基本原则等。1.1 项目背景说明开发该项目或产品的背景资料,包括启动原因、业务背景及我行相关系统现状等内容,可对市场上现有同类产品进行简单介绍以作为参考借鉴,定义产品或项目的名称(含中英文全称和缩写)。1.2 业务目标和意义描述项目所要实现的基本目标和意义,如推出某一新业务品种,开发一个内部管理系统等。1.3 指导思想和基本原则描述项目开发的指导思想和基本原则,包括需求编写的依据、业务原理及系统设计构想方面的基本要求等。1.4业务定位描述该项目的业务定位,如该

22、系统是推出一个新的金融产品或者是一个内部管理系统。1.5投产范围及用户描述该项目的投产范围和面向用户(包含内部柜员及客户)。如投产范围为各级分支行,客户为理财投资者,内部柜员为前台运行管理人员。第二章 功能概述描述需求的整体架构和完整流程,包含术语定义、业务规则、主要功能模块、账户体系、参数设计、交易渠道、运行时间等内容,是整体业务需求的主体框架。2.1 术语定义定义业务需求中涉及的业务术语及专有名词的具体含义。如有英文简称应使用中英文对照完整描述,重要的名词要明确计算精度或字段长度。序号术语名称解 释备 注1.2.3.4.5.2.2 业务规则描述项目相关的业务规则和基本规定,如客户协议、开销

23、户控制、交易授权等。2.3 总体结构描述需求的业务流程和整体架构,包含业务流程图、主要功能模块和账户体系,可以是文字及图表说明。2.3.1 业务流程图从客户或银行角度描述业务发起至结束的完整的业务处理流程,并绘制流程图。业务流程图应详细说明客户、银行柜员等各角色在各步骤中的主要操作内容。如果流程、角色较复杂,可绘制多张图表描述。2.3.2主要功能模块以图表形式将需求划分为主要功能模块,并说明各功能模块间的关系。功能模块包含账户管理、柜面联机交易、参数设置、清算、后督、报表等。2.3.3 账户体系描述该项目的账户体系设置,如总/分账户结构、登记簿、第三方关联账户等。2.4 主要功能以列表形式描述

24、需求的主要功能,细化到每个交易或最小模块,可以按交易或模块的从属关系设多级标题,每个模块说明中应包含本模块的功能说明及本模块的实现优先级。功能编号功能名称说明实现优先级实现优先级分为:必须实现、重要的、次重要的2.5 参数设计以列表或文字形式描述该项目需要使用和定义的参数,并说明参数的相关属性,如区域/地区属性、维护方式、维护权限等。2.6 交易渠道和介质描述该项目向客户提供服务的交易渠道和可以使用的交易介质,交易渠道一般划分为柜面、ATM、POS、自助终端、网上银行、电话银行、手机银行、直联渠道,交易介质包括存折、借记卡、贷记卡等。2.7 服务时间和运行要求描述该项目对客户提供服务的时间和运

25、行方面的具体要求。如对外服务时间是否为法定工作日8:3017:30、节假日的特殊处理要求、是否需要设置系统运行开关、运行的平台等。如该系统涉及和第三方合作单位,是否涉及对合作方的要求,如清算文件、对账文件截止传送时间等。第三章 功能详述用户需求书的核心内容,按第二章主要功能分设章节进行描述,一个典型的业务系统可包含参数设置、用户管理、联机交易、清算及对账处理、报表说明、非功能需求等若干章节,具体的取舍按业务需求确定。每一章中的具体业务功能(对应到交易)有需求编号、功能名称、功能说明、输入要素、处理要求、输出要素、记账处理、后督等内容,具体模版见以下说明。另外,由于柜面、网银和电话银行等不同渠道

26、发起的交易,在具体输入输出及处理上有一定差异,建议将网银/电话银行方面的需求单独进行描述。3.1 功能编号见第二章第四小节的功能编号,用多层级别定义每项具体业务需求,如模块编号子模块编号。3.2 功能名称 具体交易或子模块的名称。3.3 功能说明 描述本模块的业务处理功能和用户的权限要求,如行级别的控制、业务逻辑关系、与其他模块的关系、交易渠道和介质等。3.3.1 本模块功能3.3.2 用户权限要求3.3.3 与其他模块的关系3.3.4 交易渠道3.3.5 介质 注:此处的交易渠道和介质是对每个交易的具体说明,在2.4节描述的交易渠道和介质是概述性质。3.4 输入要素3.4.1 输入要素描述本

27、模块涉及的输入要素定义及要素之间的控制要求。3.4.2 输入画面 3.4.3 输入要素说明 对输入要素进行说明,描述输入要素的全称、类型(/输入项/选择项/自动显示等)、种类(数字/字母/字符/汉字等)、长度、范围、是否必输项等内容进行定义。3.4.4 输入要素间的控制描述各要素间的控制要求,包括先后顺序、从属关系、逻辑检查以及其他控制要求等等。3.5 处理要求描述本模块对输入的业务要素进行校验和系统处理的全过程,如输入要素的检查、账户合法性检查、余额控制、系统处理过程、异常处理要求、提示信息等等。3.6 输出要素描述系统处理完成后输出信息的具体要求。包括:输出内容或画面、打印凭证/凭条/清单

28、内容等等,表样在附录中列明。3.7 记账处理 对于结算类交易涉及账务处理的,需要提供具体的会计分录,并明确相关记账时间、方式、轧账处理等要求。3.8 后督在此节应明确后督的具体内容。第四章 清算及对账处理对该项业务的清算模式及对账处理流程进行描述。4.1 清算处理描述清算的基本模式和流程,包括清算涉及的行级别、各级行的基本职责及权限控制、处理模式、清算时间或周期、特殊情况的处理等。4.2 差错处理描述差错的具体处理方式,含差错定义,紧急和非紧急情况下的差错处理方法等。4.3 对账处理 描述对账方面的具体要求,如对账涉及的行级别、具体数据项等内容。可提供清单和报表表样,在附录中表示。4.3 其他

29、账务处理要求描述以上处理以外的其他账务要求,包括月终、年终、计息及特殊时间点账务处理等要求。第五章 非业务功能类需求 业务部门对非业务功能提出需求或建议,以下是一些常要考虑的例子。5.1数据移行描述存量客户、存量数据的移行要求。5.2业务应急处理要求描述业务连续性和应急处理的具体要求。包括故障的定义、出现故障后采取的应急方式及各级行的处理要求等。5.3 数据存贮和清理描述数据存贮、传输及清理方面的具体要求。包括:数据存贮时间、数据存贮方式、数据下载的要求、历史数据的清理周期和清理条件等。5.4其他非业务功能的要求或建议 描述以上章节未说明的其他事宜。例如:监控、灾备、网点撤并/账务上收处理、2

30、4小时支持、如涉及外联单位是否需要提供模拟器、维护与管理、数据安全性要求(是否需加密、有无特殊要求或计算方法)等等。附件:报表及凭证式样附录1:打印输出凭证/凭条格式附录2:打印输出清单格式附录3:报表格式附录4:参考资料(如:有关文件、纪要、其他资料)可以是政策文件、会议纪要或其他有助于说明该材料的文档。附件5:项目编号: XXXXXXX 项 目可行性分析报告年 月 日 龙江银行目录第一章 项目概述 第二章 投资匡算第三章 结论第一章 项目概述1.项目简介对项目整体情况进行介绍。2.市场需求及风险分析对项目市场情况及风险预估进行的说明。3.投入产出分析 对项目所带来的效益进行分析。4.项目实

31、施范围 项目投产涉及的范围5.项目用户项目的最终使用用户。6.项目功能项目要实现的具体功能。7.与现有系统关系和我行现有系统的联系。第二章 投资匡算项目需要投资的匡算(包含设备、软件开发、后期维护等费用。)第三章 结论1.业务可行性结论业务实现的可能性分析。2.技术可行性结论由技术部门提供该项目的技术可行性分析结论。附件6:项目编号:XXXXXXX 项 目业务测试计划年 月 日龙江银行目 录一、测试项目简介35二、测试目标35三、测试所需的软硬件配置35四、测试规模及工作量分析35五、测试组组成及人力资源要求36六、测试内容36七、时间资源及测试进度36八、测试风险36一、测试项目简介简单描述

32、测试的项目概况二、测试目标简述本次系统测试需要达到的目标,必须包括:测试案例功能覆盖率、测试案例执行率、测试记录闭环率、遗留问题比例、遗留的严重问题比例。例如:l 测试案例的功能覆盖率达100l 测试案例的执行率100l 遗留问题中无严重问题三、测试所需的软硬件配置描述本次测试所需的软硬件配置情况,须注明已经具备的和缺少的。1硬件配置按测试人员及测试项目需配备的设备。2软件系统配置各种操作系统、通讯系统、测试版本、外围系统等。四、测试规模及工作量分析根据本项目的测试规模及难易程度进行评估,并按“人日”折算成工作量。五、测试组组成及人力资源要求1本项目的系统测试人员姓名及分工,指定测试负责人。2

33、需要配合的相关部门和人员。3写明人员联系电话,NOTES邮箱。六、测试内容在此处描述测试内容。七、时间资源及测试进度1测试方案、测试案例的完成时间2环境准备(包括环境搭建、数据准备:各类账户、卡、客户信息等等)时间3预估测试的进度,预计的测试时间及轮次安排4批量处理的计划要求5测试要点、用户手册、测试验收报告完成时间八、测试风险 通过分析已具备的测试资源、本项目的测试规模及难度、可预计的变动因素,提出完成本项目存在的风险程度。1人力、时间资源方面2测试环境方面3部门配合方面附件:项目编号:XXXXXXX 项 目业务测试案例年 月 日龙江银行文档属性文档属性内容项目名称项目编号编制案例数量编写人

34、编写人电话编写人NOTES邮箱业务测试案例(第X件) 案例名称渠道编写人编写日期案例描述测试账户信息账号: 类型:其它:测试过程测试要点预期结果结果检查遗留问题测试人测试时间附件8:项目编号: XXXXXXX 项 目测试验收报告年 月 日龙江银行文档属性文档属性内容项目名称项目编号编写人编写人联系电话编写人NOTES邮箱编写完成日期目 录一、项目简述44二、测试情况分析与结论44三、测试人员44四、投产意见45一、项目简述介绍项目概况。二、测试情况分析与结论1测试开始和截止时间测试开始时间:XXXX年XX月XX日测试截止时间:XXXX年XX月XX日2测试情况统计分析(1) 情况统计共提交测试案例件。测试了XX轮,每轮重点测试的内容以及测试的案例数。存在的待以后版本解决的遗留问题。 (2) 测试结论 明确项目是否达到业务需求的效果,是否满足投产要求。三、测试人员1测试负责人写明业务及技术负责人员及联系方式。2参加测试的成员写明参加测试的具体业务人员及技术支持人员及联系方式。四、投产意见各部门需明确投产意见,业务主管部门需加盖公章。应用主管部门投产意见:负责人: 公章开发管理部投产意见:负责人:风险管理部意见:负责人:

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 办公文档 > 其他范文


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号