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

1 龙江银行 IT 应用系统开发管理规定 第一章 总 则 第一条 为了明确总行及各分行在应用开发类项目活动中 的职责，规范系统开发流程，特制定本规定。 一一一 本规定适用于总行及各分行科技条线以及相关业务 条线 IT 应用系统开发的管理。 一一一 本规定所称管理对象是指对总行及各分支行在应用 开发类项目管理活动及工程活动的管理过程。 一一一 本规定所称项目生命周期是指从科技条线完成项 目方案开始直至项目关闭。应用类软件开发项目关闭条件须同 时满足项目投产后五周且提交项目验收材料。 第五条 本规定所称项目承担部门和项目运行部门分别是 指总行科技条线的开发管理部和运行管理部。 第六条 本规定所称应用主管部门是指总行科技条线及各 相关业务条线。 第七条 本规定所称需求变更是指应用主管部门在项目关 闭前对业务需求分析说明书中的需求内容进行调整。 第八条 工程活动是指在项目生命周期内除管理活动之外 的，与技术相关的各项活动，主要包括软件需求分析、总体设计、 软件需求设计、系统设计、程序设计、编码、代码检查、单元测试、 2 集成测试、系统测试、验收及投产等。工程活动可以根据项目的 规模、性质等特性进行相应的裁剪。 第九条 IT 应用系统的开发管理应遵循统一规划、统一需求、 统一设计、统一开发平台的原则。 第 2 章 岗位与职责 第十条 核心系统或涉及核心业务管理及流程方面的需求， 由总行运营管理条线结算业务管理部负责提出；涉及信贷系统方 面的需求，由总行信贷管理条线信贷资产管理部负责提出；中间 业务类需求，由总行机构业务条线中间业务部负责提出；技术优 化改造类需求，由总行科技条线开发管理部负责提出；其它应用 系统需求根据具体情况确定负责部门。 第十一条 应用主管部门下设业务代表，该业务代表属于项 目组成员；项目承担部门下设审批经理、项目经理、项目组成员； 项目运行部门下设非功能性需求研究岗。 第十二条 业务代表的主要职责： （一）作为应用主管部门指定的授权人。 （二）负责与第三方之间的沟通协调，取得第三方需求文档、 技术接口文档，明确联调时间和投产时间等要求。 （三）负责与第三方协调开发及测试环境，要求第三方保证项 目开发期间内的环境支持和技术支持。 3 （四）负责处理业务需求的有关事项，协助项目组进行需求分 析。 （五）负责项目组与业务条线之间的沟通协调，参加业务需 求分析说明书的评审。 （六）负责编制业务测试计划（见附件 6）和业务测试案例 （见附件 7）。 （七）负责提交正式的测试验收报告。 第十三条 审批经理的主要职责： （一）负责项目的项目方案、外部技术资源申请、需求变更 申请等要求的审批工作。 （二）负责协调解决项目组内部无法解决的问题和风险。 （三）负责组织技术风险较大项目的项目方案评审工作。 （四）负责跟踪监督项目实施情况。 （五）负责协调处理项目相关问题。 第十四条 项目经理的主要职责： （一）负责项目的管理工作，组织制定上报项目的项目方案 和项目计划、变更方案、需求变更申请、外部技术资源申请等。 （二）负责项目的各类工程活动的组织、实施。 （三）负责接收任务和内部任务的下达工作，对项目状况进行 跟踪和监控，收集报告实施过程中的问题和风险，确保项目按时、 保质完成。 第十五条 项目组成员的主要职责：负责项目中开发、测试 4 等各类工程活动的实施。 第十六条 非功能性需求研究岗的主要职责： （一）参与项目承担部门组织的非功能性需求说明书评审。 （二）分析非功能性需求说明书对生产运行的影响并确认 其内容。 第十七条 项目组各岗位对照关系 （一）业务代表由总、分行各条线业务人员构成。 （二）审批经理由总行科技条线管理人员担任。 （三）项目经理由总行科技条线开发人员担任。 （四）项目组成员由总行科技条线开发人员、总分行各条线业 务人员构成。 （五）非功能性需求研究岗由总行科技条线运行管理部人员 担任。 第三章 立 项 第十八条 提出需求 （一）总行或分行业务需求部门提出新产品项目需求时，应首 先编写可行性分析报告（见附件 5）及业务需求书（见附件 4）， 经过条线领导审批后，提交给总行相关业务条线，由总行相关业 务条线作为应用主管部门提交总行科技条线。 （二）总行应用主管部门，首先对总行或分行业务需求部门提 5 出的可行性分析报告（见附件 5）及业务需求书（见附件 4）进 行业务分析，确认项目是否可行。 （三）总行应用主管部门应指定业务代表，由业务代表与项目 承担部门沟通协调，提交可行性分析报告（见附件 5）及业务需 求书（见附件 4），配合项目承担部门进行需求分析。 第十九条 可行性研究 （一）项目需求分析阶段的首要工作是对业务需求进行技术 可行性分析，并编写业务需求分析说明书，同时估算工作量。 （二）项目经理负责组织对业务需求进行技术可行性分析，对 于存在的技术风险、安全性设计问题和需求合理性等问题提出分 析意见。 第二十条 立项申请 （一）对于通过技术可行性分析的业务需求，应将分析意见反 馈给应用主管部门。 （二）对于不可行的技术问题出具技术可行性分析报告，由 审批经理审批后，同时反馈给应用主管部门。 （三）对于通过可行性分析的业务需求，应用主管部门应填写 项目立项审批表（见附件 2）经相关条线和主管行长进行项目立 项审批，如果项目复杂度较高，影响范围较大，涉及专业超过两 个以上则需经行长审批。 第二十一条 审批 项目立项审批表（见附件 2）经过相关领导审批通过后，将 6 项目立项审批表（见附件 2）、 业务需求书（见附件 4）及可行 性分析报告（附件 5）提交科技条线，科技条线可视情况直接进入 功能设计、系统设计或程序设计等阶段。其测试验收及投产阶段 需按本规定执行。 第二十二条 立项 （一）对于已有产品进行升级改造的需求，规模大于 15 人天 的项目须进行科技立项。 （二）对于已有产品的需求变更工作量小于 15 人天的，可以 不进行科技立项，但必须由应用主管部门提交正式的业务需求 单（见附件 3）。 （三）科技条线根据实际情况确定自行开发还是项目外包，自 行开发按照本规定执行，项目外包参照计算机软件外包管理规 定。 第 4 章 开 发 第二十三条 总体设计 （一）项目总体设计阶段的主要工作是编写项目的项目方案 。 （二）项目经理负责组织项目方案编写工作，项目方案应对 系统的技术实现手段、系统与系统外部逻辑关系及系统内部的关 键逻辑结构进行描述，项目经理应该协调组织对项目方案的评审； 7 对于对安全生产和客户服务有重大影响的项目， 项目方案必须 进行正式评审。 第二十四条 功能设计 （一）项目功能设计阶段的主要工程活动是编写业务需求分 析说明书，对安全生产有重大影响的项目须编写非功能性需求 说明书。 （二）项目经理负责组织业务代表以及相关人员对获取的业 务需求书进行分析，形成业务需求分析说明书。 业务需求分析 说明书作为与应用主管部门进行确认和验收的文档。 （三）业务需求分析说明书在提交应用主管部门确认前，需 进行评审，确保需求的一致性和正确性。 （四）业务需求分析说明书完成后，反馈给应用主管部门进 行确认。应用主管部门需要在十个工作日内将确认意见返回项目 承担部门。 （五）非功能性需求说明书的编制和评审： 1.项目经理应根据项目的实际情况，组织相关人员对非功能 性的需求进行分析，对安全生产有重大影响的项目和对项目运行 环境有特殊要求的，应该形成非功能性需求说明书。 2.总行科技条线运行管理部应组织研究分析非功能性需求 说明书对生产系统的影响，结合总行生产运行维护要求提出修 改完善建议，并在七个工作日内将确认意见返回总行科技条线开 发管理部。 8 第二十五条 系统设计 （一）项目经理应组织项目组成员进行系统设计，根据实际情 况编写系统规格书或程序规格书；项目经理可以根据实际情 况组织编写数据库设计说明书、接口说明书等文档。 （二）项目经理应组织项目组成员依据系统规格书编写程 序规格书。 （三）在项目实施过程中因设计变更或需求变更引起的系统 设计和程序设计的调整，须组织对系统规格书和程序规格书 进行修订。 （四）对已有产品进行升级改造的项目和小型项目，只需编写 程序规格书。对已有产品进行升级改造的项目需编写与原系统 差异对照详细的说明文档。 第五章 测 试 第二十六条 项目编码及测试阶段的工程活动通常包括：编 码、代码检查、单元测试、集成测试、系统测试等活动。 第二十七条 项目经理应组织项目组成员根据程序规格书 进行编码，并组织进行代码检查或评审。 第二十八条 单元测试由项目组完成，项目承担部门可根据 实际情况，有选择地进行项目的集成测试和系统测试。 第二十九条 项目经理应该按照项目计划时间要求，确定测 9 试目标、测试范围、测试软硬件配置、测试规模分析等内容，协助 业务条线编写业务测试计划（见附件 6）和业务测试案例（见 附件 7）。 第三十条 项目进入测试执行阶段后，项目经理负责组织测 试工作，并监控测试执行过程。 第三十一条 项目组在测试执行过程中，应详细、准确地记 录测试问题，跟踪问题处理情况，直到测试问题关闭。 第三十二条 在测试完成后，业务条线应完成测试报告、用 户手册、培训教材；科技条线应完成安装维护手册、版本说明书、 投产方案等项目文档的编制工作。 第三十三条 对于已有产品进行升级改造的项目，业务代表 应根据项目组提供的新老系统差异对照说明重新修订用户手册 反馈应用主管部门。 第六章 验 收 第三十四条 验收成员 验收人员由总行相关领导、总行科技条线相应人员和总行业 务条线相应人员构成。 第三十五条 验收 （一）验收测试应具体包括用户功能、业务流程、安装测试、 备份恢复测试等方面的测试： 10 1.项目经理协助组织实施验收测试工作。 2.业务代表根据业务测试计划（见附件 6）和业务测试案 例（见附件 7）完成验收测试，并记录测试结果。 3.业务代表、项目经理和项目组成员应该协调测试过程中发 现的各种问题，并对项目测试风险和软件产品缺陷进行跟踪和管 理。 （二）项目组应该保证验收测试环境正常运行，并使环境尽量 接近投产目标环境；项目经理应跟踪项目验收测试的情况，收集 项目在验收测试中发现的问题并组织协调解决。 （三）验收测试通过后，由应用主管部门在五个工作日内出具 书面测试验收报告（见附件 8），加盖部门公章，经相关部门审 批后，提交科技条线安排进行项目投产。 第三十六条 验收不合格的处理 如果项目没有通过验收，需重新进行相应模块的开发、测试。 第 7 章 推 广 第三十七条 投产 （一）项目运行部门根据项目投产方案，组织在生产环境进行 投产。项目投产后，项目经理跟踪项目投产后的运行情况，收集 项目在投产运行中发现的生产问题。项目投产后，应对项目软件 11 产品版本进行归档管理。 （二）在投产过程中因不确定因素导致投产失败，项目组应查 明原因，若是纯技术问题，待问题解决后可再次直接投产；否则应 该重新进行测试，待测试通过后，方可再次发起投产。对于投产 后发现的生产问题，项目承担部门应及时组织研发生产补丁，解 决生产问题。 （三）根据项目投产部门要求，项目组成员可在项目投产阶段 进行技术支持。 第三十八条 后期管理 （一）项目的工程活动须根据本规定执行，及时完成项目文档 的交付件，其内容可根据实际情况裁剪执行。 （二）对于因政策性要求且时间紧迫的项目，项目的相关活动 可以并行进行。 （三）总行科技条线根据自身实际情况，按照本规定对本单位 的项目工程活动进行评价和分析。 （四）总行科技条线根据自身实际情况，组织对项目工程实施 过程进行监控，监督检查项目工程实施过程是否有效。 （五）总行科技条线根据项目的进度和定期的评估报告，制定 项目工程活动的改进计划。 （六）根据改进计划，对项目工程活动进行持续改进，对影响 项目工程活动的各方面因素进行调整和优化。 第三十九条 资料归档 12 科技条线及相关业务部门进行资料的归档。 第八章 附 则 第四十条 本规定由龙江银行科技条线统一解释和修改。 第四十一条 本规定自印发之日起施行。 参考文件 1.科技档案管理规定 2.软件开发外包管理规定 附件：1.IT 应用系统开发流程图 2.项目立项审批表 3.业务需求单 4.业务需求书 5.可行性分析报告 6.业务测试计划 7.业务测试案例 8.测试验收报告 附件 1： 13 IT应用系统开发流程图 立项 开发 测试验收推广 外包公司科技条线项目组主管领导招标委员会业务部门 提出需求 Y 立项申请 审批 N N 立项Y 自行开发 项目外包 项目招标 确定外包公司 签订协议 设计方案 项目设计 设计方案 项目设计 设计方案 项目设计 测试申请 测试申请 测试 测试 改进N 测试Y N 验收验收验收 Y Y N N YN 推广 资料归档 Y YY 可行性研究 N 附件 2： 14 项目立项审批表 项目编号： 年 月 日 附件 3： 项目名称 提出单位联系人 联系电话NOTES 邮箱 项目概况： 联系人联系电话Notes 邮箱 应用主管部门意见 部门负责人审批意见：(签字、盖章) 开发管理部意见： 负责人审批意见： 风险管理部意见： 负责人审批意见： 行长审批意见： 15 业务需求单 业务 需求 发起 部门 主管部门协办部门 联 系 人 联系电话NOTES 邮箱 详细需求描述：(具体到交易码、科目号及详细流程，涉及打印格式调整的需附打印格式样本) 部门负责人： 日期： 部门公章 应用主管部门意见： 部门负责人： 责任人： 日期： 协办部门意见： 部门负责人： 日期： 开发管理部意见： 计划完成时间： 部门负责人： 责任人： 日期： 投产验收情况： 责任人： 日期： 附件 4： 项项目目编编号：号： 16 XXXXXXX 项 目 业 务 需 求 书 年年 月月 日日 龙龙江江银银行行 文档属性 属性内容 立项部门：XXXXXX 部门 文档标题：XXXXXX 项目业务需求书 文档编号：建议为部门名称项目名称首字母缩写 文档版本号：如 V1.0 文档编写完成日期： 编写人： 审核者： 编写人联系电话： 17 NOTES 联系邮箱： 编写说明： 本模板是业务需求书的公共模板，为适应我行业务快速稳定 发展，各专业部门在要求千差万别的情况下也有很强的创新性， 此模板虽具一定代表性，但可能存在不完全适应业务需要的情况。 因此，业务部门在编写过程中可参照此格式编写，也可以实用性 为原则在此基础上合理裁减，只要完整详尽表明业务需求本意即 可。 目 录 第一章第一章 项项目概述目概述21 1.1 项目背景21 1.2 业务目标和意义21 18 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 功能编号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 19 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 其他账务处理要求27 第五章第五章 非非业务业务功能功能类类需求需求27 5.1 数据移行 27 5.2 业务应急处理要求 27 5.3 数据存贮和清理27 5.4 其他非业务功能的要求或建议 28 附件：报表及凭证式样 28 附录 1：打印输出凭证/凭条格式 28 附录 2：打印输出清单格式 .28 20 附录 3：报表格式 .28 附录 4：参考资料（如：有关文件、纪要、其他资料）28 项项目概述目概述 业务需求书的概述部分，主要描述项目背景、基本原则等。 1.1 项项目背景目背景 说明开发该项目或产品的背景资料，包括启动原因、业务背景及我行 21 相关系统现状等内容，可对市场上现有同类产品进行简单介绍以作为参考 借鉴，定义产品或项目的名称(含中英文全称和缩写)。 1.2 业务业务目目标标和意和意义义 描述项目所要实现的基本目标和意义，如推出某一新业务品种，开发 一个内部管理系统等。 1.3 指指导导思想和基本原思想和基本原则则 描述项目开发的指导思想和基本原则，包括需求编写的依据、业务原 理及系统设计构想方面的基本要求等。 1.4 业务业务定位定位 描述该项目的业务定位，如该系统是推出一个新的金融产品或者是一 个内部管理系统。 1.5 投投产产范范围围及用及用户户 描述该项目的投产范围和面向用户(包含内部柜员及客户)。如投产范 围为各级分支行，客户为理财投资者，内部柜员为前台运行管理人员。 第二章第二章 功能概述功能概述 描述需求的整体架构和完整流程，包含术语定义、业务规则、主要功 能模块、账户体系、参数设计、交易渠道、运行时间等内容，是整体业务需 求的主体框架。 2.1 术语术语定定义义 定义业务需求中涉及的业务术语及专有名词的具体含义。如有英文简 称应使用中英文对照完整描述，重要的名词要明确计算精度或字段长度。 22 序号术语名称解 释备 注 1. 2. 3. 4. 5. 2.2 业务规则业务规则 描述项目相关的业务规则和基本规定，如客户协议、开销户控制、交易 授权等。 2.3 总总体体结结构构 描述需求的业务流程和整体架构，包含业务流程图、主要功能模块和 账户体系，可以是文字及图表说明。 2.3.1 业务业务流程流程图图 从客户或银行角度描述业务发起至结束的完整的业务处理流程，并绘 制流程图。业务流程图应详细说明客户、银行柜员等各角色在各步骤中的 主要操作内容。如果流程、角色较复杂，可绘制多张图表描述。 2.3.2 主要功能模主要功能模块块 以图表形式将需求划分为主要功能模块，并说明各功能模块间的关系。 功能模块包含账户管理、柜面联机交易、参数设置、清算、后督、报表等。 2.3.3 账户账户体系体系 描述该项目的账户体系设置，如总/分账户结构、登记簿、第三方关联 账户等。 23 2.4 主要功能主要功能 以列表形式描述需求的主要功能，细化到每个交易或最小模块，可以 按交易或模块的从属关系设多级标题，每个模块说明中应包含本模块的功 能说明及本模块的实现优先级。 功能功能 编编号号 功能名称功能名称说说明明实现优实现优先先级级 实现优先级分为：必须实现、重要的、次重要的 2.5 参数参数设计设计 以列表或文字形式描述该项目需要使用和定义的参数，并说明参数 的相关属性，如区域/地区属性、维护方式、维护权限等。 2.6 交易渠道和介交易渠道和介质质 描述该项目向客户提供服务的交易渠道和可以使用的交易介质，交 易渠道一般划分为柜面、ATM、POS、自助终端、网上银行、电话银行、手 机银行、直联渠道，交易介质包括存折、借记卡、贷记卡等。 2.7 服服务时间务时间和运行要求和运行要求 描述该项目对客户提供服务的时间和运行方面的具体要求。如对外 服务时间是否为法定工作日 8：3017：30、节假日的特殊处理要求、是否 需要设置系统运行开关、运行的平台等。如该系统涉及和第三方合作单位， 是否涉及对合作方的要求，如清算文件、对账文件截止传送时间等。 24 第三章第三章 功能功能详详述述 用户需求书的核心内容，按第二章主要功能分设章节进行描述，一个 典型的业务系统可包含参数设置、用户管理、联机交易、清算及对账处理、 报表说明、非功能需求等若干章节，具体的取舍按业务需求确定。每一章中 的具体业务功能(对应到交易)有需求编号、功能名称、功能说明、输入要素、 处理要求、输出要素、记账处理、后督等内容，具体模版见以下说明。 另外，由于柜面、网银和电话银行等不同渠道发起的交易，在具体输入 输出及处理上有一定差异，建议将网银/电话银行方面的需求单独进行描述。 3.1 功能功能编编号号 见第二章第四小节的功能编号，用多层级别定义每项具体业务需求， 如模块编号子模块编号。 3.2 功能名称功能名称 具体交易或子模块的名称。 3.3 功能功能说说明明 描述本模块的业务处理功能和用户的权限要求，如行级别的控制、业 务逻辑关系、与其他模块的关系、交易渠道和介质等。 25 3.3.1 本模本模块块功能功能 3.3.2 用用户权户权限要求限要求 3.3.3 与其他模与其他模块块的关系的关系 3.3.4 交易渠道交易渠道 3.3.5 介介质质 注：此处的交易渠道和介质是对每个交易的具体说明，在 2.4 节描述的 交易渠道和介质是概述性质。 3.4 输输入要素入要素 3.4.1 输输入要素入要素 描述本模块涉及的输入要素定义及要素之间的控制要求。 3.4.2 输输入画面入画面 3.4.3 输输入要素入要素说说明明 对输入要素进行说明，描述输入要素的全称、类型(/输入项/选择项/自 动显示等)、种类(数字/字母/字符/汉字等)、长度、范围、是否必输项等内容 进行定义。 3.4.4 输输入要素入要素间间的控制的控制 描述各要素间的控制要求，包括先后顺序、从属关系、逻辑检查以及其 他控制要求等等。 3.5 处处理要求理要求 描述本模块对输入的业务要素进行校验和系统处理的全过程，如输入 要素的检查、账户合法性检查、余额控制、系统处理过程、异常处理要求、 26 提示信息等等。 3.6 输输出要素出要素 描述系统处理完成后输出信息的具体要求。包括：输出内容或画面、打 印凭证/凭条/清单内容等等，表样在附录中列明。 3.7 记账处记账处理理 对于结算类交易涉及账务处理的，需要提供具体的会计分录，并明 确相关记账时间、方式、轧账处理等要求。 3.8 后督后督 在此节应明确后督的具体内容。 第四章第四章 清算及清算及对账处对账处理理 对该项业务的清算模式及对账处理流程进行描述。 4.1 清算清算处处理理 描述清算的基本模式和流程，包括清算涉及的行级别、各级行的基本 职责及权限控制、处理模式、清算时间或周期、特殊情况的处理等。 4.2 差差错处错处理理 描述差错的具体处理方式，含差错定义，紧急和非紧急情况下的差错 处理方法等。 4.3 对账处对账处理理 描述对账方面的具体要求，如对账涉及的行级别、具体数据项等内容。 可提供清单和报表表样，在附录中表示。 27 4.3 其他其他账务处账务处理要求理要求 描述以上处理以外的其他账务要求，包括月终、年终、计息及特殊时 间点账务处理等要求。 第五章第五章 非非业务业务功能功能类类需求需求 业务部门对非业务功能提出需求或建议，以下是一些常要考虑的例 子。 5.1 数据移行数据移行 描述存量客户、存量数据的移行要求。 5.2 业务应业务应急急处处理要求理要求 描述业务连续性和应急处理的具体要求。包括故障的定义、出现故障 后采取的应急方式及各级行的处理要求等。 5.3 数据存数据存贮贮和清理和清理 描述数据存贮、传输及清理方面的具体要求。包括：数据存贮时间、数 据存贮方式、数据下载的要求、历史数据的清理周期和清理条件等。 5.4 其他非其他非业务业务功能的要求或建功能的要求或建议议 描述以上章节未说明的其他事宜。例如：监控、灾备、网点撤并/账务上 收处理、24 小时支持、如涉及外联单位是否需要提供模拟器、维护与管理、 数据安全性要求(是否需加密、有无特殊要求或计算方法)等等。 28 附件：附件：报报表及凭表及凭证证式式样样 附附录录 1：打印：打印输输出凭出凭证证/凭条格式凭条格式 附附录录 2：打印：打印输输出清出清单单格式格式 附附录录 3： ：报报表格式表格式 附附录录 4：参考：参考资资料（如：有关文件、料（如：有关文件、纪纪要、其他要、其他资资料）料） 可以是政策文件、会议纪要或其他有助于说明该材料的文档。 29 附件 5： 项项目目编编号：号： XXXXXXX 项项 目目 可可 行行 性性 分分 析析 报报 告告 年年 月月 日日 龙龙江江银银行行 30 目目 录录 一一一项目概述 一一一投资匡算 一一一结论 31 项项目概述目概述 1.项目简介 对项目整体情况进行介绍。 2.市场需求及风险分析 对项目市场情况及风险预估进行的说明。 3.投入产出分析 对项目所带来的效益进行分析。 4.项目实施范围 项目投产涉及的范围 5.项目用户 项目的最终使用用户。 6.项目功能 项目要实现的具体功能。 7.与现有系统关系 和我行现有系统的联系。 投投资资匡算匡算 项目需要投资的匡算（包含设备、软件开发、后期维护等费用。 ） 结论结论 1.业务可行性结论 业务实现的可能性分析。 32 2.技术可行性结论 由技术部门提供该项目的技术可行性分析结论。 33 附件 6： 项项目目编编号：号： XXXXXXX 项项 目目 业业 务务 测测 试试 计计 划划 年年 月月 日日 龙龙江江银银行行 34 目目 录录 一、一、测试项测试项目目简简介介35 二、二、测试测试目目标标35 三、三、测试测试所需的所需的软软硬件配置硬件配置35 四、四、测试规测试规模及工作量分析模及工作量分析35 五、五、测试组组测试组组成及人力成及人力资资源要求源要求36 六、六、测试测试内容内容36 七、七、时间资时间资源及源及测试进测试进度度36 八、八、测试风险测试风险36 35 一、一、测试项测试项目目简简介介 简单描述测试的项目概况 二、二、测试测试目目标标 简述本次系统测试需要达到的目标，必须包括：测试案例功能覆盖率、 测试案例执行率、测试记录闭环率、遗留问题比例、遗留的严重问题比例。 例如： 测试案例的功能覆盖率达 100 测试案例的执行率 100 遗留问题中无严重问题 三、三、测试测试所需的所需的软软硬件配置硬件配置 描述本次测试所需的软硬件配置情况，须注明已经具备的和缺少的。 1硬件配置 按测试人员及测试项目需配备的设备。 2软件系统配置 各种操作系统、通讯系