电子银行业务分析系统-项目总结

如有你有帮助，请购买下载，谢谢！

1. 项目概况

“XXX银行业务分析系统”是为建行XXXX分行电子银行部开发的综合性业务数据分析系统。其主要基于分行ODSB数据作为数据源（主要包括CCBS和ECTIP系统数据），再加上外围相关系统数据，如：电子对账、重客、证券、彩票、代发代扣、自助设备监控等系统。经过对采集到的数据进行清洗、整合、汇总后装入系统数据平台，借助报表工具定制报表展示统计数据。 2. 需求管理总结

需求作为每个软件项目前期的重要任务，可以说需求能做到多么成功项目就能做到多成功。我们的项目前期需求工作我们基本没有参与，从四月份接收项目已经是系统设计阶段，拿到的需求资料就是个比较粗略的需求分析文档和九十多张报表表样，报表指标详细的统计口径和计算公式没有、需要抽取的数据源表是否能满足报表统计基本没有说明（与客户更是没有见面确认报表需求中是否存在问题）。由于项目按照计划已经是设计阶段，所以没有时间安排对需求再次与客户讨论、确认等工作，直接开始根据现有的需求文档和报表表样分析后进行概要设计、数据字典设计，给项目的造成了一定的风险隐患。因为，作为数据分析型系统，用户最终主要看到的是报表结果数据，如果数据不是客户当初需要或数据差距不能接受，则主要原因还是需求范围没有准备划定或没有与客户进行真实的确认。那么在需求阶段需要花大量工作是非常有必要的。

首先，确定需求范围以及详细的统计口径，与一线的业务人员（最终用户）深入沟通，统计口径确定到报表具体指标，描述信息写入每个报表表样（excel）的格子里面，形成需求的初次确认；

之后，还有一个重要的工作就是由对数据源非常熟悉者，核查每个报表指标所需要

的数据源是否可以满足，如：数据源是否可以采集到、数据源质量是否满足、数据源取得频率是否符合报表统计需要、数据源数据粒度层次程度等。最终确定一份基于数据源分析后可以满足实现条件的业务报表需求，再提交给客户确认，对需求范围进行二次确认；如果还需要继续确认那就进行第三次确认，直至与客户达成一致的认识。

对客户在后期提出的需求变更和新增需求也需求用同样的方式进行多次确认处理。

3. 计划执行总结

项目计划执行情况，主要从下面三个方面说明： （1）项目内容：

1页

如有你有帮助，请购买下载，谢谢！

项目原需求要求完成报表数量有88张，开发过程中由于对复杂而且过宽的报表拆分后，总过完成了105张报表，再加上后期变更和新增需求追加了20张报表，截至现在为止共开发125张报表，17个维护模块。

（2）项目工期：

项目工期原计划是2009年9月份完成，实际是11月份完成，延期原因总结如下两个方面：

延期原因一：按照计划是7月份到现场实施，可是把在单位开发的后台ETL程序拿到现场环境后发现，后台跑数的ETL作业大都不能按照原来的数据源要求抽取数据，因为原来单位开发环境由于没有真实数据源环境，无法测试后台ETL跑数程序。所以在8月份到9月中旬在现场调整、完善、测试后台程序；于此同时项目组依照客户测试参照的总行“渠道报表分析系统”比对我们报表结果数据，发现部分报表数据与总行结果存在差距，其中电子渠道签约客户数差距客户接受；但电子渠道交易数据差距超出了客户可接受范围，当时已经是2009年9月份，为了早日找到原因，项目组每天加班加点，分别根据XXXX行原来的统计口径和总行提供的文档描述统计口径结合总行返回数据源，进行了多次的数据测试，数据结果都与总行报表数据相差较大，在种情况下，我们试着把数据范围缩小并改变原来的统计规则的方式验证数据，经过我们很多次的试验，终于摸索出了一种和总行报表数据结果相等或非常接近的统计规则，从而证明了原来XXXX行和总行文字描述的统计口径都不能套用，而对于由于数据源本身缺失造成的数据问题我们向客户作出了详细的说明，得到了客户的理解和认可。

延期原因二：到2009年10月中旬，项目进入了试运行阶段，此期间用户才真正进入了测试状态，在此期间客户的测试时间不能保证，而且用户在测试同时提出了一些的“需求误差”（需求确认没有做到位导致）、需求变更（业务实际需要引起的）和新增需求，截至12月底，改动的报表几乎涉及到了每一张，新增加的报表有20多张。

（3）项目人力

项目组在前期需求分析和设计阶段有时是一人或俩人，在开发阶段最多有5人，现场实施阶段基本保持是4人，但在开发和现场实施阶段频繁的换人，导致 项目开发人员之间工作衔接需要时间，项目的质量和工期造成了一定的影响。

XXXX的项目当初基本是从XXXX移植过来的，所以最需要的是有原班人员的参与，特别是有开发人员跟着到新的项目中，否则原来的系统移植到新的项目后，从开发阶段开始后台ETL、前台报表开发人员换了几拨，导致原来开发的程序越改越乱，一直在修补中完成。其

2页

如有你有帮助，请购买下载，谢谢！

实这次XXXX的电子银行项目这个情况比较严重（后台ETL在单位开发的时候是没有原来XXXX行开发人员参与，而后几个月现场实施的时候又没有原来在单位开发人的参与；前台报表中在现场实施的时候也没有原来XXXX行和在单位开发者的参与）。这也暴露出来一个问题：就是项目组人员安排没有根据项目的实际需要，造成项目开发效率低、质量下降，还有每次新参与的开发人员面对原开发结果（没有注释或程序不清楚）抱怨声不断，因为他们要看懂原开发程序才能继续动手工作。希望在以后的项目中人员能合理分配。 4. 产品质量总结

产品的质量是决定项目成败的重要标志，项目实施过程的每一个环节质量都是组成整个系统质量的因素，下面我主要从需求分析、系统设计、系统开发、系统测试四个方面阐述对项目质量影响： 4.1、需求分析

前面在“需求管理总结”中已经提到，我们在前期需求阶段需求花大量的时间，对业务是否合理以及通过数据源验证是否可以满足报表指标需求，经过多次的确认来确定需求范围。个人认为我们需要提前了解和处理那些可能遭遇问题的数据。我们必须决定这些数据是拒绝呢还是处理。假如数据质量得不到保证的话，在后续的处理过程中，这样的错误将逐渐被放大。 4.2、系统设计

一般我们的设计数据模型可以满足从数据源到目标数据表的实现，但是我们的设计是否合理，开发工作量是否可以减少、运行效率是否高，这些都是我们需要考虑到问题。下面就XXX银行项目设计总结如下：

首先对整个的业务需求进行分类分析，如：日常业务管理类报表需求、业务综合分析类报表需求、考核管理类报表需求、营销管理类报表需求，对这4类报表需求设计产生的数据模型是否能很好的为它们的支持，说具体就是：

（1）基础层：是否形成平台级的基础数据模型：“客户基本信息”、“账户基本信息”、“银行卡基本信息”、“电子渠道客户签约信息”、“电子渠道账户签约信息”等，可以提供多个业务部门数据集市需要的基础数据模型，也就是“企业级”基础数据模型；针对不同

3页