《esb项目实施过程》由会员分享，可在线阅读，更多相关《esb项目实施过程（29页珍藏版）》请在金锄头文库上搜索。
1、客户logo或名称 ESB平台项目实施过程 ESB项目实施过程 提交人:王军丰 提交日期:Mar 30, 2013 版本号:v1.0文档控制变更记录 31日期作者版本号变更参考文件Mar 27, 2013王军丰V1.0创建文档审阅日期姓名职位Mar 1, 2013Manger Name审阅甲骨文公司声明 本文件是由甲骨文(中国)软件系统有限公司（以下简称：Oracle公司）向xx（以下简称：xx ）免费提供，其内容专供xx用于评估Oracle公司为其提供产品及服务的能力，仅供参考。本文件所包含的信息所有权属于Oracle公司。由于本文件包含Oracle公司保密资料，因此要求（xx）在收到本文件
2、后三年内应为Oracle公司保密；除非根据法律要求，不得出于除本项目评估之外的任何目的，以任何形式向任何第三方提供本文件内容；并同意采取所有合理的步骤，保证其接触本文件的人员不对外披露或散布本文件内容。本文件的内容将可能且应该根据(xx项目)的具体实施情况及阶段的变化而变化。 本文件对硬件规格、型号、性能的分析与估计并没有考虑操作系统、网络资源或任何其它在同一服务器上运转的应用软件对硬件的消耗。具体的硬件配备必须根据硬件厂商的推荐来决定。对本项目硬件最终选择的决定权应由客户掌握。本文件中对硬件规格的估计也不对客户形成任何具有约束性质的陈述或担保。请注意：如果您不同意上述声明，请不要阅读本文件，
3、并立即将其返还给Oracle公司；否则，Oracle公司将视为您接受并同意遵守上述声明。目 录1概述42ESB类项目实施过程52.1ESB项目特点简述52.2项目启动52.2.1项目范围和估算52.2.2项目角色82.2.3项目计划92.2.4组织结构102.3项目需求分析阶段112.3.1ESB项目与其他SOA项目的差异112.3.2服务分析步骤122.3.3接口分析132.3.4服务识别152.3.5更新服务分析文档192.3.6编写服务规范文档202.3.7编写服务映射文档212.3.8更新数据字典212.3.9编写接口映射文档222.3.10发布服务规范222.3.11其他232.4架
4、构设计阶段232.5设计与实现阶段232.6测试阶段242.6.1集成测试242.6.2FAT阶段和UAT阶段242.6.3性能测试阶段252.7上线阶段253新疆农信信息交换平台实施过程注意事项263.1重点掌握OSB产品263.2服务分析过程的掌握263.3系统情况的预先收集和准备261 概述目前，很多银行根据自己的实际情况，选择ESB项目作为基于SOA进行IT架构整合的落地项目。然而，在实施过程中，由于ESB类项目实施过程具有自身的特征，尤其是涉及到服务如何定义，行方或者项目组往往会有一些困惑和疑虑，在项目初期对项目整体缺乏把握和信心，感觉难以落地。本文的主要目的是为客户和实施方提供ES
5、B项目的参考实施过程。通过介绍ESB项目的实施过程和特征，为用户提供项目的参考实施路线图。本文的组织方式将按通用“瀑布”项目模型进行描述，从项目启动到项目上线，在各个过程中描述该阶段主要的工作、流程和特点，涉及到的角色和主要任务，也会包含部分模板，供用户参考。具体模板需要根据项目实际情况进行调整，以更符合实际项目的特征。对符合一般项目过程的知识点不在该文档描述。2 ESB类项目实施过程2.1 ESB项目特点简述ESB项目整体实施过程和其他项目在大的阶段划分上相似，然而，不同于一般业务系统的实施，ESB项目更多表现为一个技术类项目的实施，或者说是集成类项目的实施。ESB项目往往需要集成多个系统，
6、各个业务系统对应的开发商、业务部门甚至技术部门内部的小组和人员都不同，因此，ESB项目的协调沟通类工作远远大于普通的业务类项目，这对ESB项目的项目经理、需求分析人员和架构师提出了更多的要求。同时，由于涉及到到的系统多，而各个系统的开发计划、上线点并不完全相同，因此，ESB项目总体上表现为“瀑布” 模型，而具体实施过程往往表现为“迭代”模型，这在ESB项目实施二期表现尤为突出，因此，在制定项目计划时，一期可能是“瀑布”加“迭代”，二期往往就是“迭代”，若二期上线系统多时，由于每个系统上线都要执行完整的上线流程，项目组将面临很大的上线压力，当然，这是二期及以后才会面临的压力。另外，由于ESB项目
7、是一个架构类项目，而企业很难在短的周期内完成大量系统的调整，因此，ESB项目的项目周期也会较长，需要项目组和行方制定合理的总体规划和推进路线。在后续的章节，将按阶段描述ESB的实施过程。2.2 项目启动2.2.1 项目范围和估算项目范围的重要性和作用不在此赘述，在此需要说明的是，ESB的项目范围主要是接入的系统，集成的系统数量不同、复杂度不同，工作量会有较大的差异，因此，接入系统是项目首先需要确认的问题。当接入的系统确认之后，我们可以初步了解系统的情况、包含通讯协议、报文类型等，作为工作量估算的依据，主要是估算接入的连接器是否需要定制、接入的特殊要求、接入的难度等，以估算接入系统需要的工作量。
8、以下是一个估算文件，供参考，具体的基数需根据实际情况而定。另外，该工作量主要是服务定义、开发的工作量，未包含系统自身功能的开发工作量，项目总体工作量需要综合考虑质量管理、性能测试、上线等。另外，接入系统的多少也涉及到接口的数量，接口数量将是需求分析主要的参考依据，因此，在项目开始阶段会要求收集这类信息。以上都是比较容易确认的信息，或者说是客户能够明确给出的信息，但有一点需要注意的是，在制定项目范围时，涉及到平台功能如监控功能、管理功能、流水功能、冲正功能等，各行往往会有不同的要求，而这些要求在项目启动时难以确认会有哪些，因为客户对产品功能还没有深入的了解，因此，该部分范围将难以确认，工作量也较
9、难估算出来。一个办法是：由于ESB项目的周期将分为多个阶段，因此，这部分可以做的粗一点，在工作说明书中说明未完善部分在二期完成，与客户达成一致意见；同时，在项目启动后，尽快向客户演示这些功能，与客户就这些内容进行沟通与确认，再制定具体的资源计划和开发计划。项目启动前，尽早完成接入系统的调查，以便进行开发工作量和需求分析工作量的估算。接入系统调查表可以参考以下内容，根据项目和行方实际情况调整：该表的目的是确认存量系统的技术、接口现状，能否修改，是否在本次修改，后续是否有改造计划等，这些信息将影响项目的计划安排，也会影响到对存量系统实施策略。系统的接入方式，是否修改等策略，需要在架构文档中进行描述
10、和说明，当然，之前也跟客户达成一致意见。一般而言，新系统的开发，或者改造较大的系统，一般要求按照标准Webservice方式实现和接入，实在有困难的，可考虑作为服务提供方和服务请求方采用不同的方式；对存量系统，需要考虑改造难度、是否有开发团队、能提供什么样的支持等，决定具体的通讯方式和报文是按照标准格式还是按照原有格式，这需要跟行方一起，与原有的开发商进行沟通协调，因为这可能会带来预算的增加。工作量的估算，业务系统往往会按照功能点估算，ESB项目除了系统本身功能是按照功能点外，需求分析是按照接口的数量进行估算，开发是按照新增connector的数量、报文格式的数量等估算，另外需要考虑集成的工作
11、量。系统集成的工作量将是ESB项目特别注意的一点，往往会消耗较多的资源投入。在估算工作量时，需要根据项目组人员技能情况，给出合适的估算单位值，如每个服务从接口分析、服务定义、服务开发实现、服务测试、完成集成测试、功能测试等给出单位人日数，以此为基准给出具体的数值。在该数值估算过程中，可以参看以下章节中具体的服务定义过程，结合对ESB产品的掌握、报文的类别（是否标准SOAP报文，是否需要报文格式转换、是否需要字段映射）、开发人员技术集成等综合评定。同理，系统集成的连接器开发等也需要根据类别进行估算。完成以上工作后，考虑项目管理工作量、质量管理工作量、性能测试工作量、知识转移工作量等等，加上项目风
12、险的预留Buffer，可以得到项目工作量估算。2.2.2 项目角色ESB的项目角色和其他项目角色相同，然而，由于ESB项目项目特性，需要的技能有所不同，以下给出主要项目角色的技能要求。项目经理：如前所示，由于涉及到多个同时实施（开发或改造）的项目，ESB项目的项目经理需要具有项目群经理的技能，虽然不是直接管理各个项目，而只是负责管理ESB项目，但应该从项目群管理角度，发现可能存在的风险和问题，从项目群角度综合考虑项目进度、项目风险，协调对应的项目计划，并积极寻求行方的理解和支持，推动整体项目群的上线。ESB项目的管理者需要谨记：只有所有相关系统上线，ESB项目才算成功上线，否则，只是部分完成了
13、任务；虽然责任可能并不在ESB项目组自身，然而从客户角度来看，项目并没有达到预期的目标。因此，ESB项目经理需要极强的推动力和执行力。架构师：ESB项目的架构师更关注整体集成架构，而不仅仅是单个项目的架构，因此，需要架构师具有较强的集成架构设计经验。能够把SOA的理念和具体执行传达到其他相关项目组，制定技术规范并指导其他项目组按照ESB的技术规范完成系统开发和集成。需求分析人员：ESB项目的需求分析人员和常见业务系统的分析人员不同，分析的对象是原有的系统和接口，对原有接口进行梳理和抽象，结合自己的行业经验和专业经验，整理和发布为服务。因此，要求ESB的项目分析人员对要接入ESB的业务系统的业务
14、比较熟悉，必要时，能够与该系统的业务人员直接交流，收集该业务的发展方向，以保证提供的服务具有较长的生命力，能够支持未来业务的发展，具有较好的扩展性。同时，还具有一定的技术背景，能够对原有接口的合理性进行分析，给出修改建议，以便更符合服务定义的要求（主要是存量系统；但实际开发过程中，往往实施商已经有对应的产品或者产品原型，外部接口已经定义好，此时，对新系统的接口同样要进行分析和调整）。开发人员：开发人员主要工作分为两类，一是完成对应的系统连接器开发；完成产品功能与客户期望差异的实现；二是完成具体服务的配置和实现。其中，第一类技能要求较高，要求对产品比较熟悉，且具有一定的设计能力；第二类要求较低一
15、些，主要使用工具完成服务配置，完成字段映射及部分服务组合逻辑，相对要求较低一些。在ESB项目第一期，对第一类技术人员需求稍多一些，而在一期之后的二期，只需要极少的第一类员工即可，甚至架构师可以直接兼任该部分工作，只配置第二类人员即可。其他项目角色没有特殊的要求，此处不再赘述。需要特别指明的是，ESB项目组不需要专门的功能测试人员，因为没有具体的业务功能（产品自身的管理功能、监控功能、客户特色功能除外），因此，可以由开发人员完成功能测试，但需要做好测试案例的设计和管理。2.2.3 项目计划在项目范围确定后，需要明确各个项目的上线时间点，在很多情况下，各个 项目的上线时间点不完全相同，需要采用分批上线的策略。部分项目群实施过程中，也可
