xx银行IT应用系统开发管理规定_第1页
xx银行IT应用系统开发管理规定_第2页
xx银行IT应用系统开发管理规定_第3页
xx银行IT应用系统开发管理规定_第4页
xx银行IT应用系统开发管理规定_第5页
已阅读5页,还剩39页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

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

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

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

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

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

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

7、件 5)及业务需求书 (见 附件 4)进行业务分析,确认项目是否可行。 (三)总行应用主管部门应指定业务代表,由业务代表与 项目承担部门沟通协调,提交可行性分析报告 (见附件 5) 及业务需求书 (见附件 4) ,配合项目承担部门进行需求分析。 第十九条 可行性研究 (一)项目需求分析阶段的首要工作是对业务需求进行技 术可行性分析,并编写业务需求分析说明书 ,同时估算工作 量。 (二)项目经理负责组织对业务需求进行技术可行性分析, 对于存在的技术风险、安全性设计问题和需求合理性等问题提 出分析意见。 第二十条 立项申请 (一)对于通过技术可行性分析的业务需求,应将分析意 见反馈给应用主管部门。

8、 (二)对于不可行的技术问题出具技术可行性分析报告 , 由审批经理审批后,同时反馈给应用主管部门。 (三)对于通过可行性分析的业务需求,应用主管部门应 填写项目立项审批表 (见附件 2)经相关条线和主管行长进 行项目立项审批,如果项目复杂度较高,影响范围较大,涉及 专业超过两个以上则需经行长审批。 第二十一条 审批 项目立项审批表 (见附件 2)经过相关领导审批通过后, 将项目立项审批表 (见附件 2) 、 业务需求书 (见附件 4) 及可行性分析报告 (附件 5)提交科技条线,科技条线可视 情况直接进入功能设计、系统设计或程序设计等阶段。其测试 验收及投产阶段需按本规定执行。 第二十二条 立

9、项 (一)对于已有产品进行升级改造的需求,规模大于 15 人 天的项目须进行科技立项。 (二)对于已有产品的需求变更工作量小于 15 人天的,可 以不进行科技立项,但必须由应用主管部门提交正式的业务 需求单 (见附件 3) 。 (三)科技条线根据实际情况确定自行开发还是项目外包, 自行开发按照本规定执行,项目外包参照计算机软件外包管 理规定 。 第 4 章 开 发 第二十三条 总体设计 (一)项目总体设计阶段的主要工作是编写项目的项目 方案 。 (二)项目经理负责组织项目方案编写工作,项目方 案应对系统的技术实现手段、系统与系统外部逻辑关系及系统 内部的关键逻辑结构进行描述,项目经理应该协调组

10、织对项目 方案的评审;对于对安全生产和客户服务有重大影响的项目, 项目方案必须进行正式评审。 第二十四条 功能设计 (一)项目功能设计阶段的主要工程活动是编写业务需 求分析说明书 ,对安全生产有重大影响的项目须编写非功能 性需求说明书 。 (二)项目经理负责组织业务代表以及相关人员对获取的 业务需求书进行分析,形成业务需求分析说明书 。 业 务需求分析说明书作为与应用主管部门进行确认和验收的文 档。 (三) 业务需求分析说明书在提交应用主管部门确认前, 需进行评审,确保需求的一致性和正确性。 (四) 业务需求分析说明书完成后,反馈给应用主管部 门进行确认。应用主管部门需要在十个工作日内将确认意

11、见返 回项目承担部门。 (五) 非功能性需求说明书的编制和评审: 1.项目经理应根据项目的实际情况,组织相关人员对非功 能性的需求进行分析,对安全生产有重大影响的项目和对项目 运行环境有特殊要求的,应该形成非功能性需求说明书 。 2.总行科技条线运行管理部应组织研究分析非功能性需 求说明书对生产系统的影响,结合总行生产运行维护要求提 出修改完善建议,并在七个工作日内将确认意见返回总行科技 条线开发管理部。 第二十五条 系统设计 (一)项目经理应组织项目组成员进行系统设计,根据实 际情况编写系统规格书或程序规格书 ;项目经理可以根 据实际情况组织编写数据库设计说明书、接口说明书等文档。 (二)项

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

13、地进行项目的集成测试和系统测试。 第二十九条 项目经理应该按照项目计划时间要求,确定 测试目标、测试范围、测试软硬件配置、测试规模分析等内容, 协助业务条线编写业务测试计划 (见附件 6)和业务测试 案例 (见附件 7) 。 第三十条 项目进入测试执行阶段后,项目经理负责组织 测试工作,并监控测试执行过程。 第三十一条 项目组在测试执行过程中,应详细、准确地 记录测试问题,跟踪问题处理情况,直到测试问题关闭。 第三十二条 在测试完成后,业务条线应完成测试报告、 用户手册、培训教材;科技条线应完成安装维护手册、版本说 明书、投产方案等项目文档的编制工作。 第三十三条 对于已有产品进行升级改造的项

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

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

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

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

18、求书 5.可行性分析报告 6.业务测试计划 7.业务测试案例 8.测试验收报告 附件 1: it应用系统开发流程图 立项 开发 测试验收推广 外包公司科技条线项目组主管领导招标委员会业务部门 提出需求 y 立项申请 审批 n n 立项y 自行开发 项目外包 项目招标 确定外包公司 签订协议 设计方案 项目设计 设计方案 项目设计 设计方案 项目设计 测试申请 测试申请 测试 测试 改进n 测试y n 验收验收验收 y y n n yn 推广 资料归档 y yy 可行性研究 n 附件 2: 项目立项审批表 项目编号: 年 月 日 附件 3: 项目名称 提出单位联系人 联系电话notes 邮箱 项

19、目概况: 联系人联系电话notes 邮箱 应用主管部门意见 部门负责人审批意见:(签字、盖章) 开发管理部意见: 负责人审批意见: 风险管理部意见: 负责人审批意见: 行长审批意见: 业务需求单 业务 需求 发起 部门 主管部门协办部门 联 系 人 联系电话notes 邮箱 详细需求描述:(具体到交易码、科目号及详细流程,涉及打印格式调整的需附打印格式样本) 部门负责人: 日期: 部门公章 应用主管部门意见: 部门负责人: 责任人: 日期: 协办部门意见: 部门负责人: 日期: 开发管理部意见: 计划完成时间: 部门负责人: 责任人: 日期: 投产验收情况: 责任人: 日期: 附件 4: 项目

20、编号:项目编号: xxxxxxx 项 目 业 务 需 求 书 年年 月月 日日 龙江银行龙江银行 文档属性 属性内容 立项部门:xxxxxx 部门 文档标题:xxxxxx 项目业务需求书 文档编号:建议为部门名称项目名称首字母缩写 文档版本号:如 v1.0 文档编写完成日期: 编写人: 审核者: 编写人联系电话: notes 联系邮箱: 编写说明: 本模板是业务需求书的公共模板,为适应我行业务快速稳 定发展,各专业部门在要求千差万别的情况下也有很强的创新 性,此模板虽具一定代表性,但可能存在不完全适应业务需要 的情况。因此,业务部门在编写过程中可参照此格式编写,也 可以实用性为原则在此基础上合

21、理裁减,只要完整详尽表明业 务需求本意即可。 目 录 第一章第一章 项目概述项目概述.21 1.1 项目背景.21 1.2 业务目标和意义.21 1.3 指导思想和基本原则.21 1.4 业务定位 .21 1.5 投产范围及用户 .21 第二章第二章 功能概述功能概述.22 2.1 术语定义.22 2.2 业务规则.22 2.3 总体结构.22 2.3.1 业务流程图.22 2.3.2 主要功能模块.23 2.3.3 账户体系.23 2.4 主要功能.23 2.5 参数设计.23 2.6 交易渠道和介质.23 2.7 服务时间和运行要求.24 第三章第三章 功能详述功能详述.24 3.1 功能

22、编号.24 3.2 功能名称.25 3.3 功能说明.25 3.3.1 本模块功能.25 3.3.2 用户权限要求.25 3.3.3 与其他模块的关系.25 3.3.4 交易渠道.25 3.3.5 介质.25 3.4 输入要素.25 3.4.1 输入要素.25 3.4.2 输入画面.25 3.4.3 输入要素说明.25 3.4.4 输入要素间的控制.26 3.5 处理要求.26 3.6 输出要素.26 3.7 记账处理.26 3.8 后督.26 第四章第四章 清算及对账处理清算及对账处理.26 4.1 清算处理.26 4.2 差错处理.27 4.3 对账处理.27 4.3 其他账务处理要求.2

23、7 第五章第五章 非业务功能类需求非业务功能类需求.27 5.1 数据移行 .27 5.2 业务应急处理要求 .27 5.3 数据存贮和清理.27 5.4 其他非业务功能的要求或建议 .28 附件:报表及凭证式样 .28 附录 1:打印输出凭证/凭条格式 .28 附录 2:打印输出清单格式 .28 附录 3:报表格式 .28 附录 4:参考资料(如:有关文件、纪要、其他资料) .28 第一章第一章项目概述项目概述 业务需求书的概述部分,主要描述项目背景、基本原则等。 1.11.1 项目背景项目背景 说明开发该项目或产品的背景资料,包括启动原因、业务背景及我 行相关系统现状等内容,可对市场上现有

24、同类产品进行简单介绍以作为 参考借鉴,定义产品或项目的名称(含中英文全称和缩写)。 1.21.2 业务目标和意义业务目标和意义 描述项目所要实现的基本目标和意义,如推出某一新业务品种,开 发一个内部管理系统等。 1.31.3 指导思想和基本原则指导思想和基本原则 描述项目开发的指导思想和基本原则,包括需求编写的依据、业务 原理及系统设计构想方面的基本要求等。 1.41.4 业务定位业务定位 描述该项目的业务定位,如该系统是推出一个新的金融产品或者是 一个内部管理系统。 1.51.5 投产范围及用户投产范围及用户 描述该项目的投产范围和面向用户(包含内部柜员及客户)。如投产范 围为各级分支行,客

25、户为理财投资者,内部柜员为前台运行管理人员。 第二章第二章 功能概述功能概述 描述需求的整体架构和完整流程,包含术语定义、业务规则、主要 功能模块、账户体系、参数设计、交易渠道、运行时间等内容,是整体 业务需求的主体框架。 2.12.1 术语定义术语定义 定义业务需求中涉及的业务术语及专有名词的具体含义。如有英文 简称应使用中英文对照完整描述,重要的名词要明确计算精度或字段长 度。 序号术语名称解 释备 注 1. 2. 3. 4. 5. 2.22.2 业务规则业务规则 描述项目相关的业务规则和基本规定,如客户协议、开销户控制、 交易授权等。 2.32.3 总体结构总体结构 描述需求的业务流程和

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

27、 2.42.4 主要功能主要功能 以列表形式描述需求的主要功能,细化到每个交易或最小模块,可 以按交易或模块的从属关系设多级标题,每个模块说明中应包含本模块 的功能说明及本模块的实现优先级。 功能功能 编号编号 功能名称功能名称说明说明实现优先级实现优先级 实现优先级分为:必须实现、重要的、次重要的 2.52.5 参数设计参数设计 以列表或文字形式描述该项目需要使用和定义的参数,并说明参数 的相关属性,如区域/地区属性、维护方式、维护权限等。 2.62.6 交易渠道和介质交易渠道和介质 描述该项目向客户提供服务的交易渠道和可以使用的交易介质,交 易渠道一般划分为柜面、atm、pos、自助终端、

28、网上银行、电话银行、 手机银行、直联渠道,交易介质包括存折、借记卡、贷记卡等。 2.72.7 服务时间和运行要求服务时间和运行要求 描述该项目对客户提供服务的时间和运行方面的具体要求。如对外 服务时间是否为法定工作日 8:3017:30、节假日的特殊处理要求、 是否需要设置系统运行开关、运行的平台等。如该系统涉及和第三方合 作单位,是否涉及对合作方的要求,如清算文件、对账文件截止传送时 间等。 第三章第三章 功能详述功能详述 用户需求书的核心内容,按第二章主要功能分设章节进行描述,一 个典型的业务系统可包含参数设置、用户管理、联机交易、清算及对账 处理、报表说明、非功能需求等若干章节,具体的取

29、舍按业务需求确定。 每一章中的具体业务功能(对应到交易)有需求编号、功能名称、功能说明、 输入要素、处理要求、输出要素、记账处理、后督等内容,具体模版见 以下说明。 另外,由于柜面、网银和电话银行等不同渠道发起的交易,在具体 输入输出及处理上有一定差异,建议将网银/电话银行方面的需求单独进 行描述。 3.13.1 功能编号功能编号 见第二章第四小节的功能编号,用多层级别定义每项具体业务需求, 如模块编号子模块编号。 3.23.2 功能名称功能名称 具体交易或子模块的名称。 3.33.3 功能说明功能说明 描述本模块的业务处理功能和用户的权限要求,如行级别的控制、 业务逻辑关系、与其他模块的关系

30、、交易渠道和介质等。 3.3.13.3.1 本模块功能本模块功能 3.3.23.3.2 用户权限要求用户权限要求 3.3.33.3.3 与其他模块的关系与其他模块的关系 3.3.43.3.4 交易渠道交易渠道 3.3.53.3.5 介质介质 注:此处的交易渠道和介质是对每个交易的具体说明,在 2.4 节描述 的交易渠道和介质是概述性质。 3.43.4 输入要素输入要素 3.4.13.4.1 输入要素输入要素 描述本模块涉及的输入要素定义及要素之间的控制要求。 3.4.23.4.2 输入画面输入画面 3.4.33.4.3 输入要素说明输入要素说明 对输入要素进行说明,描述输入要素的全称、类型(/

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

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

33、容。可提供清单和报表表样,在附录中表示。 4.34.3 其他账务处理要求其他账务处理要求 描述以上处理以外的其他账务要求,包括月终、年终、计息及特殊 时间点账务处理等要求。 第五章第五章 非业务功能类需求非业务功能类需求 业务部门对非业务功能提出需求或建议,以下是一些常要考虑的例 子。 5.15.1 数据移行数据移行 描述存量客户、存量数据的移行要求。 5.25.2 业务应急处理要求业务应急处理要求 描述业务连续性和应急处理的具体要求。包括故障的定义、出现故 障后采取的应急方式及各级行的处理要求等。 5.35.3 数据存贮和清理数据存贮和清理 描述数据存贮、传输及清理方面的具体要求。包括:数据

34、存贮时间、 数据存贮方式、数据下载的要求、历史数据的清理周期和清理条件等。 5.45.4 其他非业务功能的要求或建议其他非业务功能的要求或建议 描述以上章节未说明的其他事宜。例如:监控、灾备、网点撤并/账 务上收处理、24 小时支持、如涉及外联单位是否需要提供模拟器、维护 与管理、数据安全性要求(是否需加密、有无特殊要求或计算方法)等等。 附件:报表及凭证式样附件:报表及凭证式样 附录附录 1 1:打印输出凭证:打印输出凭证/ /凭条格式凭条格式 附录附录 2 2:打印输出清单格式:打印输出清单格式 附录附录 3 3:报表格式:报表格式 附录附录 4 4:参考资料(如:有关文件、纪要、其他资料

35、):参考资料(如:有关文件、纪要、其他资料) 可以是政策文件、会议纪要或其他有助于说明该材料的文 档。 附件 5: 项目编号:项目编号: xxxxxxxxxxxxxx 项项 目目 可可 行行 性性 分分 析析 报报 告告 年年 月月 日日 龙江银行龙江银行 目目录录 第一章项目概述 第二章投资匡算 第三章结论 第一章第一章 项目概述项目概述 1.项目简介 对项目整体情况进行介绍。 2.市场需求及风险分析 对项目市场情况及风险预估进行的说明。 3.投入产出分析 对项目所带来的效益进行分析。 4.项目实施范围 项目投产涉及的范围 5.项目用户 项目的最终使用用户。 6.项目功能 项目要实现的具体功

36、能。 7.与现有系统关系 和我行现有系统的联系。 第二章第二章 投资匡算投资匡算 项目需要投资的匡算(包含设备、软件开发、后期维护等费用。 ) 第三章第三章 结论结论 1.业务可行性结论 业务实现的可能性分析。 2.技术可行性结论 由技术部门提供该项目的技术可行性分析结论。 附件 6: 项目编号:项目编号: xxxxxxxxxxxxxx 项项 目目 业业 务务 测测 试试 计计 划划 年年 月月 日日 龙江银行龙江银行 目目 录录 一、一、测试项目简介测试项目简介.35 二、二、测试目标测试目标.35 三、三、测试所需的软硬件配置测试所需的软硬件配置.35 四、四、测试规模及工作量分析测试规模

37、及工作量分析.35 五、五、测试组组成及人力资源要求测试组组成及人力资源要求.36 六、六、测试内容测试内容.36 七、七、时间资源及测试进度时间资源及测试进度.36 八、八、测试风险测试风险.36 一、一、测试项目简介测试项目简介 简单描述测试的项目概况 二、测试目标二、测试目标 简述本次系统测试需要达到的目标,必须包括:测试案例功能覆盖 率、测试案例执行率、测试记录闭环率、遗留问题比例、遗留的严重问 题比例。例如: 测试案例的功能覆盖率达 100 测试案例的执行率 100 遗留问题中无严重问题 三、测试所需的软硬件配置三、测试所需的软硬件配置 描述本次测试所需的软硬件配置情况,须注明已经具备的和缺少的。 1硬件配置 按测

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论