某国有银行省行电子银行业务分析系统-ODS项目管理过程

某国有银行省行电子银行业务系统-ODS项目管理过程 电子银行业务分析系统 ——项目总结 1. 项目概况.............................................................................................................. 1 2. 需求管理总结 ...................................................................................................... 1 3. 计划执行总结 ...................................................................................................... 24. 产品质量总结 ...................................................................................................... 4 4.1、需求分析 .......................................................................................................... 4 4.2、系统 .......................................................................................................... 4 4.3、系统开发 .......................................................................................................... 5 4.4、系统测试 .......................................................................................................... 5 5. 项目风险总结 ...................................................................................................... 6 6. 沟通管理总结 ...................................................................................................... 7 7. 项目技术经验 ...................................................................................................... 7 8. 项目前景分析 ...................................................................................................... 9 1. 项目概况 “XXX银行业务分析系统”是为建行XXXX分行电子银行部开发的综 合性业务数据分析系统。其主要基于分行ODSB数据作为数据源(主要包括 CCBS和ECTIP系统数据)，再加上外围相关系统数据，如:电子对账、重 客、证券、彩票、代发代扣、自助设备监控等系统。经过对采集到的数据进 行清洗、整合、汇总后装入系统数据平台，借助报工具定制报表展示统计 数据。 2. 需求管理总结 需求作为每个软件项目前期的重要任务，可以说需求能做到多么成功项 目就能做到多成功。我们的项目前期需求工作我们基本没有参与，从四月份 接收项目已经是系统设计阶段，拿到的需求资料就是个比较粗略的需求分析 文档和九十多张报表表样，报表指标详细的统计口径和计算没有、需要 抽取的数据源表是否能满足报表统计基本没有说明(与客户更是没有见面确 1 认报表需求中是否存在问题)。由于项目按照计划已经是设计阶段，所以没 有时间安排对需求再次与客户讨论、确认等工作，直接开始根据现有的需求 文档和报表表样分析后进行概要设计、数据字典设计，给项目的造成了一定 的风险隐患。因为，作为数据分析型系统，用户最终主要看到的是报表结果 数据，如果数据不是客户当初需要或数据差距不能接受，则主要原因还是需 求范围没有准备划定或没有与客户进行真实的确认。那么在需求阶段需要花 大量工作是非常有必要的。 首先，确定需求范围以及详细的统计口径，与一线的业务人员(最终用 户)深入沟通，统计口径确定到报表具体指标，描述信息写入每个报表表样 (excel)的格子里面，形成需求的初次确认; 之后，还有一个重要的工作就是由对数据源非常熟悉者，核查每个报表 指标所需要的数据源是否可以满足，如:数据源是否可以采集到、数据源质 量是否满足、数据源取得频率是否符合报表统计需要、数据源数据粒度层次 程度等。最终确定一份基于数据源分析后可以满足实现条件的业务报表需 求，再提交给客户确认，对需求范围进行二次确认;如果还需要继续确认那 就进行第三次确认，直至与客户达成一致的认识。 对客户在后期提出的需求变更和新增需求也需求用同样的方式进行多 次确认处理。 3. 计划执行总结 项目计划执行情况，主要从下面三个方面说明: (1)项目内容: 项目原需求要求完成报表数量有88张，开发过程中由于对复杂而且过宽的报表拆分后，总过完成了105张报表，再加上后期变更和新增需求追加了20张报表，截至现在为止共开发125张报表，17个维护模块。 (2)项目工期: 项目工期原计划是2009年9月份完成，实际是11月份完成，延期原因总结如下两个方面: 延期原因一:按照计划是7月份到现场实施，可是把在单位开发的后台ETL程序拿到现场环境后发现，后台跑数的ETL作业大都不能按照原来的数据源要求抽取数据，因为原来单位开发环境由于没有真实数据源环境，无法测试后台 2 ETL跑数程序。所以在8月份到9月中旬在现场调整、完善、测试后台程序;于此同时项目组依照客户测试参照的总行“渠道报表分析系统”比对我们报表结果数据，发现部分报表数据与总行结果存在差距，其中电子渠道签约客户数差距客户接受;但电子渠道交易数据差距超出了客户可接受范围，当时已经是2009年9月份，为了早日找到原因，项目组每天加班加点，分别根据XXXX行原来的统计口径和总行提供的文档描述统计口径结合总行返回数据源，进行了多次的数据测试，数据结果都与总行报表数据相差较大，在种情况下，我们试着把数据范围缩小并改变原来的统计规则的方式验证数据，经过我们很多次的试验，终于摸索出了一种和总行报表数据结果相等或非常接近的统计规则，从而证明了原来XXXX行和总行文字描述的统计口径都不能套用，而对于由于数据源本身缺失造成的数据问题我们向客户作出了详细的说明，得到了客户的理解和认可。 延期原因二:到2009年10月中旬，项目进入了试运行阶段，此期间用户才真正进入了测试状态，在此期间客户的测试时间不能保证，而且用户在测试同时提出了一些的“需求误差”(需求确认没有做到位导致)、需求变更(业务实际需要引起的)和新增需求，截至12月底，改动的报表几乎涉及到了每一张，新增加的报表有20多张。 (3)项目人力 项目组在前期需求分析和设计阶段有时是一人或俩人，在开发阶段最多有5人，现场实施阶段基本保持是4人，但在开发和现场实施阶段频繁的换人，导致 项目开发人员之间工作衔接需要时间，项目的质量和工期造成了一定的影响。 XXXX的项目当初基本是从XXXX移植过来的，所以最需要的是有原班人员的参与，特别是有开发人员跟着到新的项目中，否则原来的系统移植到新的项目后，从开发阶段开始后台ETL、前台报表开发人员换了几拨，导致原来开发的程序越改越乱，一直在修补中完成。其实这次XXXX的电子银行项目这个情况比较严重(后台ETL在单位开发的时候是没有原来XXXX行开发人员参与，而后几个月现场实施的时候又没有原来在单位开发人的参与;前台报表中在现场实施的时候也没有原来XXXX行和在单位开发者的参与)。这也暴露出来一个问题:就是项目组人员安排没有根据项目的实际需要，造成项目开发效率低、质量下降，还有每次新参与的开发人员面对原开发结果(没有注释或程序不清楚)抱 3 怨声不断，因为他们要看懂原开发程序才能继续动手工作。希望在以后的项目中人员能合理分配。 4. 产品质量总结 产品的质量是决定项目成败的重要标志，项目实施过程的每一个环节质量都是组成整个系统质量的因素，下面我主要从需求分析、系统设计、系统开发、系统测试四个方面阐述对项目质量影响: 4.1、需求分析 前面在“需求管理总结”中已经提到，我们在前期需求阶段需求花大量的时间，对业务是否合理以及通过数据源验证是否可以满足报表指标需求，经过多次的确认来确定需求范围。个人认为我们需要提前了解和处理那些可能遭遇问题的数据。我们必须决定这些数据是拒绝呢还是处理。假如数据质量得不到保证的话，在后续的处理过程中，这样的错误将逐渐被放大。 4.2、系统设计 一般我们的设计数据模型可以满足从数据源到目标数据表的实现，但是我们的设计是否合理，开发工作量是否可以减少、运行效率是否高，这些都是我们需要考虑到问题。下面就XXX银行项目设计总结如下: 首先对整个的业务需求进行分类分析，如:日常业务管理类报表需求、业务综合分析类报表需求、考核管理类报表需求、营销管理类报表需求，对这4类报表需求设计产生的数据模型是否能很好的为它们的支持，说具体就是: (1)基础层:是否形成平台级的基础数据模型:“客户基本信息”、“账户基本信息”、“银行卡基本信息”、“电子渠道客户签约信息”、“电子渠道账户签约信息”等，可以提供多个业务部门数据集市需要的基础数据模型，也就是“企业级”基础数据模型;针对不同部门业务主题或数据集市中基础层是否彼此独立。因为不同部门数据集市基础层彼此独立，如果数据集市之间形成关联数据，会造成彼此影响。另外，基础层也需设计公用维度表信息(如:机构维度、日期维度、渠道维度等)，提供每个部门集市数据使用。 (2)汇总层:是否设计了平台级的汇总数据模型:“电子渠道客户交易日汇总”、“电子渠道账户交易日汇总”、“卡交易日汇总”、“电子渠道交易日汇总”、“柜面交易日汇总”等，可以提供多个业务部门数据集市需要的汇总数据模型， 4 也就是“企业级”汇总数据模型;如果业务部门需要汇总粒度可以再进行“月汇总、季汇总”等。建议不同部门数据集市汇总层也彼此独立。另外，在汇总层之上，根据不同业务部门需要，设计出针对主题分析的事实表(如:电子渠道客户签约分析事实表、电子渠道交易分析事实表、银行卡交易分析事实表等)，满足客户报表需要和多维数据分析。 4.3、系统开发 首先开发规范，如ETL、Shell、报表开发规范有没有进行严格的遵守;其次，项目开发人员在完成某个后台程序或报表后，自己测试不是很仔细，有的甚至没有遍历所有的程序逻辑，导致在系统测试时不能正常进行;所以这种情况需要有项目组有专门的代码检查人员，检查开发人员工作结果，不正确或不合规范的返回开发人员重新完成，这种方法虽然需要有人力条件，但是对保证项目的质量是必要的。 4.4、系统测试 由于ODSB项目一般都是从数据源抽取数据整合后以报表的形式展示给客户，和其他的应用系统有一定的区别，所以在测试方法也有不同。 (1)测试组测试: 需求根据项目后台ETL、前台报表两部分产物分别进行测试; 后台ETL测试需要从数据源——>目标表，验证ETL处理过程是否正确，测试人员根据设计文档，编写SQL语句进行测试，对测试人员SQL要求较高; 前台报表测试需要从目标表——>报表展示，验证报表开发是否准确，测试人员需要明白报表每个业务指标的统计口径和规则，对测试人员业务熟悉程度要求较高;而且同一个指标在多个报表展示时，应该是相等的，也就是报表之间平的。如果目标表与报表数据验证不一致，就需要对数据源编写SQL与报表结果比对，也就是主要采取白盒测试方式; 如果数据源——>目标表——>报表展示三者之间都是一致，那剩下的工作就是和业务部门的已有报表统计结果进行比对，数据如果有差异，需求分析人员或设计人员就需要进行与业务人员进行讨论确认问题所在，分析是原来需求是否理解有差异，或统计口径是否已发生变更。 (2)用户测试: 5 用户测试一般是黑盒测试，直接查看报表结果数据，如果与用户已有的业务报表报表结果不一致，客户就会提出疑议，需要项目组做出解释;当数据差距在可以可接受范围之内，还可以通过;否则，客户需要寻找另外的解决，给客户一个满意的答复。 5. 项目风险总结 对于风险，我主要总结几个方面: (1)对业务不了解或没有与客户真正确认需求，造成后期用户测试时进入了无休止的改动; (2)数据源结构不是很了解，增加了采集数据过程的时间; (3)数据源数据质量的较低，最终影响报表质量，从而导致客户对系统的认可度降低;如果排除我们自身开发质量原因，导致这种情况出现原因有以下两点: 1)客户原来要求的统计口径已经变更，客户测试参考的数据是新口径结果; 2)我们使用的数据源数据质量是否有问题，或者我们分析数据源的时候不 完整造成的。 用户测试问题分析: 对第1)点，这种情况往往是无法避免的，如果在口径变更时，客户提前通知项目组，就可以提前处理，否则做的都是无用功。 对第2)点，如果经过对数据源写SQL验证统计结果与客户要求结果相差比较大，需求分析数据源是否满足报表需求，而验证数据源的工作如果在需求分析期间已经完成，并且把数据源不能满足需求的报表与客户上来后剔除掉，那么在用户测试时候就不会出现这种情况;也就是说:需求阶段把不能实现的报表就排除掉，在开发阶段的工作就不会花无用功，提高工作的效率。 (4)项目组人员频繁变动，给代码衔接和质量带来隐患; (5)在单位开发ODSB项目，后台ETL取得数据源环境不具备，导致程序不能全面测试; (6)没有专门的客户配合项目实施，也是给项目的顺利进行带来不便。 这些现象都是非常常见的，而且都是很关键问题，试想如果我们能提前预知风险且采用了相应的措施来防止发生，那麻烦会大大降低;不过，即使发生了， 6 只要我们理清楚思路找到问题根源，然后按照步骤一步步执行下去，问题终究会解决的。 6. 沟通管理总结 沟通是人员、技术、信息之间的关键纽带，是项目成功所必须的。下面就客户沟通和项目组内部沟通情况做出总结: (1)客户沟通:与客户沟通让客户明白项目的进度以及需要配合的工作内容是非常必要的，同时把项目开发过程中遇到的不可避免的风险提前告知客户，取得客户的理解和支持，如数据源不满足或质量低等现象如果早在需求阶段就发现，并与客户达成一致意见就不会出现后期测试时才暴露。 在项目的开发过程中需要定期与客户进行开讨论会，汇报项目进展情况，彼此建立起良好的沟通机制。这一点，我们项目在单位开发的时候做的不够多，在现场实施的过程中，沟通比较充分，定期给客户汇报项目进度和数据质量情况。 (2)项目组内部沟通:项目组内部成员之间的沟通内容我认为主要包括:业务需求、设计结果、技术工具等，因为每个人对需求的理解都有自己的角度，通过沟通达成一致的认识;开发人员对设计结果是否可以理解或理解有偏离;技术工具需要熟练者带刚学者快速掌握，使其早日投入正常工作这也是加快项目进度的重要途径。 7. 项目技术经验 我们项目的定性分析: 首先，我们经常提到的操作数据存储(ODS)与数据仓库(DW)的区别: ODS是介于DB和DW 之间的一种数据存储技术，和原来面向应用的分散的DB相比，ODS中的数据组织方式和数据仓库(DW)一样也是面向主题的和集成的，所以对进入ODS的数据也象进入数据仓库的数据一样进行集成处理。另外ODS只是存放当前或接近当前的数据，如果需要的话还可以对ODS中的数据进行增、删和更新等操作，虽然DW中的数据也是面向主题和集成的，但这些数据一般不进行修改，所以ODS和DW的区别主要体现数据的可变性、当前性、稳定性、汇总度上。 简单说ODS只是业务数据库的一个备份或者映像，ODS中的数据也尽量不做转换，而是原封不动地与业务数据库保持一致，目的是为了使数据仓库的处理 7 和决策支持要求OLAP(联机分析处理)与OLTP(联机事务处理)系统相隔离，减少决策支持要求对OLTP系统的影响。 为什么需要有一个ODS系统呢,一般在带有ODS的系统体系结构中，ODS都具备如下几个作用: 1) 在业务系统和数据仓库之间形成一个隔离层; 2) 转移一部分业务系统细节查询的功能: ODS的数据从粒度、 组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而 降低业务系统的查询压力; 3) 完成数据仓库中不能完成的一些功能: 数据仓库从宏观角度满足企业的决策支持要求，而ODS层则从微观角度反映细节交易数据或者低粒度的数据查询要求。 经过上面对一些概念的描述，我一直在想，我们当前的电子银行项目或给其他行开发的基于ODSB开发的项目是DW吗,我们面对的是客户提出的几十甚至上百张的报表需求，项目完成的是以几个业务主题建设的数据仓库吗,如果是数据仓库，那提供用户灵活的多维立方体、OLAP(联机分析处理)分析中那里,这些问题经过思考过后，我总结得出:虽然提供给用户的是一大堆各种各样的报表，但是数据仓库的架构是存在的，首先在数据准备区(数据平台)中建立一致性维度、建立一致性事实的计算方法;其次在一致性维度、一致性事实的基础上逐步建立数据集市，这个为电子银行部提供的其实就是一个数据集市，我们在这个数据集市上产生了业务报表，如果客户需要，完全可以创建几个如“渠道签约分析”、“渠道交易分析”等业务主题，再通过Cognos工具产生对应的多维立方体，提供管理层用户上卷、下钻等数据分析。这样我们以后为其他部门每次增加数据集市，都会在数据准备区整合一致性维度，并将整合好的一致性维度同步更新到所有的数据集市。这样，建立的所有数据集市合在一起就是一个整合好的数据仓库。这种数据仓库架构(自下而上)具有逐步建设的特点，它的开发周期比其他架构(自上而下)方式的开发周期要短，风险和相应的成本也要低。 其实数据仓库的建设还有一种“企业信息工厂”(自上而下)的实现方式是， 8 首先进行全企业的数据整合，建立企业信息模型，即EDW。对于各种分析需求再建立相应的数据集市或者探索仓库，其数据来源于EDW，原子层给建立OLAP带来一定的复杂性，但是对于建立更复杂的应用，如挖掘仓库、探索仓库提供了更好的支持。这类架构的建设周期比较长，相应的成本也比较高。用户在短时间看不到想要的结果。 另外，基于ODSB的报表开发类项目，在项目管理中也与一般的应用系统有所不同，这里就不详细说明了。 8. 项目前景分析 8.1、数据源分析: 作为基于建行ODSB开发的项目，我们所使用的是建总行统一返给各一级分行最全面、最具核心业务数据，虽然现在数据模型一直在变化，但是目的就是为了各分行提供最有最有价值的数据，这为我们以后基于ODSB的项目做起来方便了很多，这方面在这次XXX银行项目得到了印证。而且值得一提的是ODSB数据模型在2009年11月14日下发的新版本中，竟然增加了一个针对证券系统(CCBSS)的分行应用集市——专门为证券主题报表准备好了大量汇总数据。如果说总行根据分行的需要在ODSB基础上不断的创建针对业务部门数据集市，那我们以后ODSB项目就会省去很多工作，即可以直接把总行返回的多个数据集市数据根据数据仓库架构抽取到我们的数据平台，形成分行企业级的数据仓库，在此平台上借助前台报表工具提供客户对历史数据查询和固定报表统计需要。 8.2、展示方式分析: 固定形式的报表是用来快速发现和定位问题或异常的，而动态OLAP是用来深入分析导致问题或异常的具体原因的。上面我为何不说成是我们在数据仓库基础之上提供客户灵活的联机分析(OLAP)、数据多维度钻取、挖掘出数据的内在价值，支持决策制定呢,也就是商业智能(BI)具备的功能呢,因为我们提供的这些固定报表足以满足业务部门的需要，根本原因在于我们面对的业务需求往往是客户提出上百张具有中国式的、格式复杂的固定报表，客户关心的就是减少每次手工产生和定期对关心指标数据的统计;而非提供多维数据联机分析、从历史数据形成趋势挖掘出数据规律提炼出价值，进而支持决策等商务智能系统应 9 该具备的需求高度。 8.3、产品未来发展分析: 首先我就简单说明一下“商业智能”和“数据仓库”的关系: 商业智能是用来实现数据向信息转变，信息向知识转变，知识向价值转变的这么一个过程，以及这个过程中所使用到的种种技术和工具。商业智能是围绕着数据来做文章的，数据仓库也可以说是商业智能的核心环节，很多情况下，习惯性地，由于两者有如此密切的关系，所以在很多项目命名时，往往是把数据仓库和商业智能相提并论，有时这会给人一种很混淆的感觉。一般来说，上面所描述的是一个广义上的商业智能概念，在这个概念层面上，数据仓库是其中非常重要的组成部分，数据仓库从概念上更多地侧重在对各类企业信息的整合工作，包括了数据的迁移，数据的组织和存储，数据的管理与维护这些我们平常称之为后台的基础性的数据准备工作，与之对应，侠义的商业智能概念则侧重在对数据的查询，报表、多维/联机数据分析、数据分析和数据可视化工具这些平常称之为所谓前台的数据应用方面。 ，要使我们ODSB方向的项目有个质上升，产生真正意义上的商业智那么 能系统，就需要把商业需求而不是技术作为数据仓库的驱动力量，在开始时就应该关注需要什么样的信息，而不是如果提供这些信息。更不要将注意力集中在工具上，支持用户需求的基本结构体系才是重要的。最终提供客户真正关心具有商业价值的数据。我忠心希望，我们公司在ODSB方向的项目越做越大，实现具有产品意义上的价值，在IT行业内推出权威软件产品，最终推向全国建行。 综上所述，我从八个方面围绕我们这次所完成的XXX银行系统做了分析和总结，希望对大家日后的项目实施过程中起到积极的作用。 总结人:mgjava@163.com 10