可行性研究报告分析

中国农业银行XX分行中间业务系统金融平台改造项目可行性研究报告文档编号：CG-C03-DLNH-01-PBL01编写人：XXX审核人：YYY丹东市启东信息工程研究所-引言1.1编写目的阐明中国农业银行XX分行中间业务系统金融平台改造项目的实现在技术上、经济上和社会条件方面的可行性；评述为了合理地达成开发目的而可能选择的多个实施方案；阐明并论证所选定的方案的理由，从而为公司领导决策提供参考。1.2背景阐明项目名称中国农业银行XX分行中间业务系统金融平台改造项目。任务提出者中国农业银行XX分行。软件运行的网络中国农业银行内部网。同其它系统往来本项目涉及到与第三方系统报文交换的地方较多。1.4参考资料序号文档标题1中国农业银行XX分行竞争性谈判邀请对现有系统的分析现在面对交易的农行应用系统根据解决逻辑的不同分为三个层次：渠道层、金融产品层、核算层中，核算层及传统金融产品重要布署在ABIS系统中，为银行客户提供传统的金融产品服务，并为其他金融产品提供帐务逻辑解决的服务，而多个新型金融产品的应用逻辑（帐务逻辑除外）则根据业务的不同分别分布于AIPS、中间业务平台、投资业务平台、第三方后台服务等应用系统中。这样，根据应用布署的不同又能够按照渠道层、前置层、后台服务层等三个层次划分，以下随着全国数据集中项目的稳步进行及ABIS系统的日趋稳定和完善，各分行的工作重点正逐步向渠道层和前置层转移，渠道整合、ACBS两个项目的实施为渠道层的应用逻辑统一解决打下了坚实的基础，而前置层上的应用解决则处在相对混乱的状态，重要有下列某些问题：首先，不同的业务在不同的应用系统中实现，就规定渠道层必须根据业务的不同判断其对应的后台并组装该应用系统所定义的报文，从而加重了渠道层应用解决的复杂度；另首先，各级分行科技人员面临着总行开发推广的多个金融产品和各个不同的应用系统，还要应对多个本地化的新型金融产品，而总行开发推广的产品，大都由不同的产品组开发，有着不同的设计思想、不同的开发习惯、多个不同的工作流程、多个自定义的数据库表、不同的报表生成方式，大量的程序维护、大量的系统维护、多个不同的管理规则……，从总行到分行都在疲于奔命应付多个项目的开发、测试、推广以及技术支持。最后的成果是对业务需求的反映速度慢；技术人员进行着大量重复性的开发工作，多个低档的应用错误重复出现；同一种应用层上不同的业务归属于不同的技术人员负责，诸多人做着相似的工作，从而造成人力、财力资源的严重浪费……金融服务平台的技术可行性分析3.1简要描述随着商业银行发展的需要，银行电子化建设也正向着更深的层次发展，银行的应用系统明显地呈现下列三个发展趋势：数据趋于集中、解决趋于统一、系统趋于开放。我行的全国数据大集中正在稳步实施，在前置层上建设一种开放的、解决逻辑统一的金融服务平台已是大势所趋。随着银行间的竞争加剧，各级业务部门设计的新型金融产品越来越多，而这些新型金融产品的大部分业务逻辑都是在前置层上实现的，在此层次上的应用从业务角度上分析是千差万别、难于归纳的。但是如果将各产品的逻辑拆分成具体的功效单元，则能够发现千差万别的金融产品其实是由可归纳总结的一种个功效单元拼装而成的。我们能够对现有金融产品所涉及到的功效单元进行系统地分析、归纳和总结，统一其解决办法，而具体逻辑则通过可配备的参数体现出来。这样，产品逻辑的实现过程就是平台对产品所涉及到的各功效模块的调度过程，产品的开发则由原来的编写程序变化为对各功效单元以及功效单元的调度流程的参数化设立，产品的维护则由原来的程序维护变化为对配备参数的维护。这样，解决办法统一了，产品开发办法统一了，产品管理办法统一了，产品的维护办法统一了，产品规范统一了，前面所提出的多个问题自然迎刃而解。事实上，在中间业务平台中已经对大部分的功效单元进行了总结和实现，并在实践中得到了承认，因此我们认为金融服务平台的实施和实现是完全可行的。金融服务平台的应用布局在农行面对交易的应用系统架构中，金融服务平台应当是前置层上的唯一应用解决系统，以下图所示：在省域数据集中和全国数据集中两种模式并存的状况下，金融服务平台的应用布局以下所示：如上，金融服务平台负责渠道的接入、后台服务的调用、本地应用解决等三部分功效的实现，在级连模式下，两个金融服务平台之间互为后台服务。金融服务平台只在各一级分行的数据中心布署，采用集中式管理和应用、分布式开发和维护的架构，全国数据中心布署的金融服务平台还能够有全国业务统计、分析、管理等功效。金融服务平台的系统架构金融服务平台是一种集管理、开发、运行、维护、统计分析等功效于一体的应用系统，它由金融服务平台运行环境（TulipFramework）和金融服务平台开发管理环境（TulipStudio）两大部分构成，其系统架构以下图所示：下面分别对各模块进行阐明：运行环境（TulipFramework）：在UNIX环境下实现，基于CICS、SYBASE、C＋SQL编程实现；开发管理环境（TulipStudio）：重要基于.NET架构开发实现；产品信息：一种金融产品的实现涉及产品逻辑的定义、产品运行数据、产品管理信息、产品统计分析数据等等，这些数据以多个方式保存在数据库中；交易引擎（TransactionEngine）：是金融服务平台运行环境的核心模块，它负责对交易逻辑及交易有关要素进行解释分析并确保交易的实现；组件（Component）：完毕某种特定功效的一段执行代码，是由交易引擎调度的金融服务平台运行环境中的最小功效单元；运行数据总线（DataChannel）：每个交易被调起时系统在内存中动态分派出来的一块数据区，交易过程中产生和使用到的全部数据都在此数据区内，供交易引擎和各组件使用，交易调用结束后该数据区被系统释放；流程配备总线（TaskChannel）：保存于数据库中，由交易引擎访问并获得的交易流程配备信息，是一种虚拟的数据总线；应用服务器（ApplicationServer）：基于WINDOWSIIS（InternetInformationServices）架构开发的WEB服务器，负责客户端应用调度的实现，逻辑上总行数据中心以及各一级分行数据中心各布署一台；开发客户端、管理客户端：金融服务平台的全部开发、管理、运行、维护、统计分析等功效都通过开发和管理两个客户端外在体现出来，其中管理客户端为瘦客户端，能够通过浏览器（例如IE）连接到应用服务器上完毕金融服务平台的运行、维护、管理、统计分析等操作；开发客户端为胖客户端，负责金融产品的可视化开发，并通过应用服务器将产品逻辑保存到数据库中。3.5技术条件方面的可行性评价在成熟的Tulip平台上进行二次开发，开发过程以配备为主，个别地方需要运用开发语言C语言编写程序，按照农行项目的数量，预计投入开发人员应在12人左右，开发周期为2个月，完全能够完毕全部项目，符合规定。所建议系统的经济可行性分析4.1支出开发支出重要为：◆员工工资和奖金；◆加班费；◆交通费◆餐费4.1.1无。4.1.2其它一次性支出无。4.1.3非一次性支出◆系统一年免费维护费用4.2收益4.2.1一次性收益按照合同规定。4.2.2非一次性收益第一年