智慧银行金融信息云平台实施方案.docx

智慧银行金融信息云平台实施方案.docx

《智慧银行金融信息云平台实施方案.docx》由会员分享，可在线阅读，更多相关《智慧银行金融信息云平台实施方案.docx（34页珍藏版）》请在冰豆网上搜索。

智慧银行金融信息云平台实施方案

智慧银行金融信息云平台实施方案

第3章平台总体方案

第1章

第2章

第3章

3.1平台业务方案

3.1.1业务全景图

智慧银行_金融信息云平台围绕中小微企业，以企业采购，销售，结算，授信，分销商管理，催收款等流程为主线，提供覆盖企业生产全流程的面向不同部门人员使用的一系列轻量应用群，在解决企业痛点需求基础上，快速扩大兰州银行存贷量，打造同业最强的对公互联网金融信息服务生态圈。

智慧银行_金融信息云平台面向中小微企业服务，有可复制性，填补了传统银行面向中小微企业服务空白。

采用最新的移动互联网和云平台技术，充分利用银行服务优势和个人存款业务优势，面向企业不同关键人，提供一系列轻量应用，切入企业痛点，扩大存贷量。

通过以小微企业为目标，贯穿起包括企业刚需进销存、企业投融资、企业记账理财、企业协同办公、企业业务支持、信息查询等全套服务，构建面向中小微企业的金融服务平台，实现将金融产品对企业在各环节上的支持提升到新的水平，在企业转型互联网潮流中占据先机，取得行业领先优势。

3.1.2关键特性设计

智慧银行金融信息云平台整体服务基于SaaS和PaaS模式设计，用户使用租用的方式享受云服务，用户不必自己搭建应用、配置硬件与软件环境。

小微企业云平台提供企业常用轻应用和各种平台级基础服务，第三方平台也可以快速接入平台，快速形成服务能力。

根据小微企业设计各种基础角色，方便企业不同人群按需使用服务。

拥有完善的权限管理系统，可以控制到页面菜单级别，让企业数据更加安全。

1.1.1

3.1.3业务设计图

3.1.3.1金融信息云平台_产品常用使用角色和权限

3.2

第4章平台实施方案

4.1项目实施方案

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

11.1.

1.1

1.2

1.2.1项目实施进度计划

项目实施阶段主要完成银行统一信息发布及金融产品移动展示平台的搭建，实现PC、客户经理Pad端的基础平台的搭建，实现各自渠道内容及信息的统一推送。

各阶段初步工作任务分解请见下图：

1.2.2项目人员构成

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

11.1.

11.1.1.

11.1.2.

1.2.2.1核心人员列表

姓名

职务/等级

在本项目中角色

学历

参与阶段/主要工作

预计现场实施人月

何船

开发一部主管

项目经理

本科

常驻

6

林良谋

产品经理

产品经理

本科

常驻

6

李汶良

JAVA工程师

JAVA工程师

本科

常驻

6

蒋勇

JAVA工程师

JAVA工程师

本科

常驻

6

徐哲

JAVA工程师

JAVA工程师

本科

常驻

6

周志强

安卓工程师

安卓工程师

本科

常驻

5

王玉琴

测试工程师

测试工程师

本科

常驻

5

注：

1、在填写时，如本表格不适合投标单位的实际情况，可根据本表格式自行制表填写。

2、必须实施人员提供简历、毕业证复印件、软件工程师或其它专业技术证书、工作项目经历证明及担任职务等资料，作为评议和合作公司人员项目进场审核依据。

报价人（公章）：

法定代表人或授权委托代理人签名：

日期：

1.2.2.2人力资源投入计划

编号

职位

级别

项目投入时间

总人月

4月

5月

6月

7月

8月

9月

1

项目经理1

1

1

1

1

1

1

6

2

产品经理1

高级

1

1

1

1

1

1

6

3

UI设计师1

高级

0.5

1

1

1

1

1

5.5

4

重构工程师1

高级

1

1

1

1

1

5

5

JAVA1

高级

1

1

1

1

1

1

6

6

JAVA2

高级

1

1

1

1

1

1

6

7

JAVA3

高级

1

1

1

1

1

1

6

8

JAVA4

中级

1

1

1

1

1

1

6

9

JAVA5

中级

1

1

1

1

1

5

10

JAVA6

中级

1

1

1

1

1

5

11

安卓工程师1

高级

1

1

1

1

1

5

12

安卓工程师2

中级

1

1

1

1

1

5

13

测试工程师1

高级

1

1

1

1

1

5

14

测试工程师2

中级

1

1

1

1

1

5

人月合计

76.5

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

11.1.

11.1.1.

11.1.2.

11.1.2.1.

11.1.2.2.

1.2.2.3组织架构

1.2.2.3.1项目管理办公室

项目领导小组成员由xx银行相关领导、项目负责人和我公司的领导和本项目的项目控制主管、项目经理共同组成，负责对项目的整体管理和重大事项的决策，在整个项目过程中对项目进行监督管理。

职责：

总体协调项目实施过程中各个单位和各个部门之间的配合和合作；对项目开发提供必要的支持；对项目范围与业务需求给与最终的确认；对项目过程中产生的问题和变更给与最终的确认；对整个项目建设过程的进度、计划、质量等进行宏观监督；对项目中的风险进行宏观分析和监控。

1.2.2.3.2项目控制主管

在工程实施期间，我公司派出一名资深项目控制主管，同时与xx银行的项目组进行沟通、协调我公司公司人员、指导我公司的项目经理的管理工作、并定时参加周会，保证项目的顺利实施。

职责：

负责指导、控制系统各阶段的业务、技术工作、公司内部人员调配、相关业务与技术问题、业务架构与技术架构的探讨及方案；并辅助项目经理将整个项目顺利实施。

项目控制主管向双方项目领导汇报工作。

1.2.2.3.3项目经理

在工程实施期间，我公司派出一名资深专职项目经理，同时为了保证更顺畅的沟通合作，建议xx银行也选派一名资深人员作为本项目的项目经理组成员协助项目的顺利实施。

职责：

项目经理负责向项目领导组定期报告项目进展情况，就项目中存在的问题提出解决建议，对项目进行有计划地组织管理。

项目经理直接对项目管理办公室负责，向双方项目管理办公室汇报工作。

项目管理办公室下辖以下各功能组，各种完成各自的职责，同时在项目各个阶段，还将演化出阶段性的临时工作组，由项目管理办公室主要人员按工作要求进行调配。

1.2.2.3.4需求分析组

由xx银行业务专家和我公司资深产品经理组成，是整个项目的业务把关团队。

职责：

完成具体需求分析工作，需求功能说明书的编写、业务管理办法的编写、静态DEMO的制作等。

同时需求分析组负责整个项目过程中对相关人员进行必要的知识培训工作，包括：

操作人员培训、运行维护人员培训、需求分析人员培训等培训工作的具体组织、工作落实。

作为培训组织团队，在项目启动到结束的整个过程中，对参与人员可能缺失的各项技能进行分析，提前安排各项培训工作、协调业务技术专家参与项目培训工作。

1.2.2.3.5系统环境组

系统环境组将由xx银行信息技术骨干和我公司高级系统架构师组成，是整个项目的系统架构把关团队。

职责：

负责整个项目的概要设计、详细设计、数据库设计、接口设计的制定及评审，并将设计文档做为产出物指导下游开发团队进行开发工作。

1.2.2.3.6开发组

项目开发小组将由我公司派出的多名中高级研发工程师组成，同时也希望有xx银行的技术人员加入，以保证项目可以更顺畅地得到实现。

职责：

负责整个应用软件的开发、实施工作，测试问题的修正，数据移植，系统运行过程中BUG的修改等工作，是本项目的技术主体组。

1.2.2.3.7测试组

由我公司测试部派出的中高级测试人员和xx银行业务、技术测试人员共同组成。

职责：

负责整个平台的测试工作，包括软件系统的集成测试、客户验收测试、安全测试、性能测试等，负责具体的测试环境准备、测试工作组织、测试过程管理、测试结果评估。

1.2.2.3.8质量管理组

由我公司和xx银行双方的项目管理部成员构成。

职责：

负责项目质量控制，监督项目实施质量；同时负责监督业务和技术培训的效果。

1.2.3项目文档管理

1.2.3.1文档管理说明

项目中所有文档的产生、维护可由版本控制工具（例如SVN）进行统一维护，以保证文档的一致性和有效性。

1.2.3.2文档确认机制

文档就其性质分为需回复和不需回复。

不需回复的文档，如进度报告、非正式的会议纪要、备忘录等，提交给对象后不需要确认或回回答。

另外一些文档需要有关方面的领导层作出决策，例如需求规格说明书、系统设计文档等，这类文档提交后，都需要一个确认过程，一般确认时限为三个工作日，确认方式一般通过邮件回复确认或纸质确认。

此类文档在发出时会注明需要某方面领导或部门确认，以及紧急程度。

对文档的回回答可以是同意、待定（注明时间）、会签（注明参加部门）、转签（注明部门）等。

无法作明确回答复时应回回答“待定”或其他和大致所需时间。

一般情况下文档提交方若在3天内得不到任何回答复，可发出催问并作记录。

在可能影响项目进度的情况下，项目组发出催问同时以缺省默认方式继续项目工作，若有反复的情况将被记录在案。

严重影响项目进度的情况下可提交项目领导协调小组处理。

1.2.3.3阶段性工作及对应产出文档

本项目的实施过程分为两个大的阶段，第一阶段实现系统整体基础功能，第二阶段进行优化完善以及对接外部系统，为确认项目实施过程的总体可控，我们会将每个阶段又划分为需求分析、系统设计、系统编码、系统测试等子过程，对各个子过程的计划及产出物进行细化管理。

需要说明的是，项目实施是一个复杂的过程，随着项目的开展会发生许多预期之外的事情，因此，这些规划在项目过程中会逐渐的修改以适应要求。

项目阶段

工作内容

产出

第一阶段

项目启动

确定项目组主要成员，最终界定项目范围，研究并制定项目实施方案，补充完善项目主计划。

《项目总体计划》

需求分析

进行需求分析，分析项目详细业务功能需求，界定项目功能范围并定义确认最终用户对未来系统使用界面的需求及操作界面流程。

《项目范围说明书》

《用户需求说明书》

《软件需求规格说明书》

《场景验证方案和用例》

《需求确认文档》

系统原型

系统设计

依据在需求分析中所得到的业务需求和系统原型，进行系统概要设计、详细设计和数据库设计，为后继的程序编写打下良好基础。

《概要设计》

《详细设计》

《数据库设计》

《系统设计确认文档》

系统编码

为我公司相关产品为基础，根据已确认的系统设计文档进行开发工作。

系统源代码

系统测试

搭建测试环境；

制定测试计划；

编制测试用例；

执行SIT测试；

修改测试中发现的问题；

编写测试报告。

《测试计划》

《测试用例》

《测试报告》

第二阶段

系统优化

对xx银行项目组业务及技术测试人员进行相关培训；

xx银行项目组进行UAT测试；

修改测试中发现的问题。

需求分析

对需求规格说明书中的外部系统对接需求进行细化

《需求规格说明书》

《需求确认文档》

系统设计

编写接口设计文档并确认

《概要设计》

《详细设计》

《数据库设计》

《系统设计确认文档》

系统编码

完成与手机银行、网上银行、支付平台、ECIF及其它第三方系统账号的对接工作

系统源代码

系统测试

搭建测试环境；

制定测试计划；

编制测试用例；

执行SIT测试；

执行UAT测试；

执行压力测试、安全容错、兼容性等测试；

修改测试中发现的问题；

编写测试报告。

《测试计划》

《测试用例》

《测试报告》

系统上线

准备生产环境、上线方案及回滚计划准备；

完成试点运行数据加载；

提供试点行的现场业务和技术支持，运行监控维护，故障排查解决。

《用户手册》

《部署手册》

《管理员手册》

《系统上线试运行报告》

《系统验收报告》

1.2.4项目实施管理

1.2.4.1项目沟通管理方案

1.2.4.1.1项目会议

项目会议是服务于项目工作的，是为了更好的加强项目沟通、解决项目实施过程中存在的各种问题。

主要采用周例会和不定专题会议等形式。

每次会议都要有专人做会议记录，会后由记录人员将会议纪要分发给相关人员，并上传配置管理系统中。

会议可由xx银行项目组项目经理或我公司项目组项目经理根据项目实际情况发起，会议发起人必须有具体的议题，并至少提前1小时通过邮件或书面等文字形式向参会人提供会议议题及议程。

如会议因其他原因更改或取消，会议发起人需要通过电话、邮件、即时通讯、口头等至少一种形成通知参会人。

1.2.4.1.2周报制度

根据我公司项目管理统一要求，建立周报制度，周报提交时间初定为每周五中午12点，周报将发送项目组所有干系人员。

1.2.4.1.3沟通方式

日常工作中如涉需要确认事项统一通过邮件或书面方式进行，其他沟通方式包括但不仅限于邮件、电话、会议等。

1.2.4.2项目人员管理方案

1.2.4.2.1项目人员管理规定

为确保本项目计划的正常执行，我司承诺按项目要求，协调相应资源保质保量地投入到本项目，并及时正确地完成所分配的任务。

在我司入场前，应向xx银行提供项目参与人员详细资料，xx银行项目组有权根据项目实际情况要求调换，或在项目实施过程中发现资料与实际人员不符时，有权要求进行调换，我司会尽快予以调整。

如果根据项目需要、或甲方/乙方请求、或不可抗拒的原因，需要对于我司参与本项目的相关人员进行调整（包括人员的增减和更换）时，双方将本着对项目负责的原则，在进行充分协商并取得xx银行同意后尽快完成人员的调整。

另外xx银行对于我司不能胜任项目工作的人员，有权提出调整要求。

我司项目组成员须遵守xx银行项目作息制度，我司项目组成员离开项目组（包括：

请假等）须提早通知xx银行项目组相关负责人，并在xx银行项目组相关负责人确认不影响项目进度时方可离开。

1.2.4.2.2项目人员考核方案

为规范项目管理行为，鉴定项目管理水平，确认项目管理成果，对项目管理进行全面考核和评价，并以此为依据进行相应奖惩，特制定本方案。

项目考核评价的依据是项目经审核立项后所签订的《项目任务书》，考核按项目进度计划划分阶段进行。

项目完成后，必须对项目管理进行全面的终结性考核。

在《项目任务书》中应由项目负责人小组、项目管理办公室、市场部和项目经理一起，按项目的具体情况明确项目进程中对项目组和项目经理的奖惩原则和具体奖惩措施，并报项目管理办公室负责人核准。

项目终结性考核的内容应包括确认阶段性考核的结果，确认项目管理的最终结果，确认该项目部是否具备"解体"的条件。

经考核评价后，兑现《项目任务书》确定的奖励和处罚。

1.2.4.3软件版本控制

为确保软件开发过程、测试过程、实施交付过程中软件版本始终可控，需要根据项目实际情况对于版本的更新制订规则，对于版本进行严格的控制。

项目过程中具体的版本控制应达到下列标准：

1）版本更新要与系统测试及修改情况相适应；

2）为了便于测试组明确下一个版本的测试范围和目的，开发人员更新提交新程序时，须提交本次《版本更新修改程序的配置说明》，否则不予接收新版本的测试；

3）对每个版本进行冒烟测试，不能通过测试的不能打版本上测试环境；

4）开发人员能够保证提供稳定的版本测试；

5）对于每个版本发现的问题、解决的问题进行记录，并做版本更新记录；

6）打版本时，应当建立新的文件夹，避免对于老版本的覆盖；

版本控制根据项目的要求，可以选择适合的版本控制工具，如SVN、CVS等等，具体的版本控制操作实施细则如下：

1）开发人员修改的程序，应统一提交至服务器，由专人做打包并发布版本；

2）提交《版本更新修改程序的配置说明》，说明修改了哪些问题，对哪些功能可能会有影响，并对版本更新做记录；

3）新版本发布之后，由测试人员在开发环境上对于新版本进行冒烟测试，测试用例可以选取用例级别较高的进行；

4）冒烟测试通过后，方可以打新版本，否则不能打新版本；

5）记录每个版本发现的问题，即版本测试情况；

6）关于版本发布的频率，可以根据实际情况确定，如每天发布一次版本，或每轮测试发布一次版本；

7）新的版本新建立新的文件夹，避免覆盖老版本，以做版本恢复和对比使用；

1.2.4.4项目风险分析及应对

1.2.4.4.1高并发和瞬时蜂拥数据

⏹风险描述

统一信息发布及金融产品移动展示平台应用环境中，常可见以“秒杀”、“节假日促销”等为典型代表的高并发或瞬时蜂拥类业务场景，如何应对这类业务场景，成为平台设计之初就必须要考虑的问题。

⏹应对策略

基于互联网系统“完全松耦合式”的体系结构，遵循简洁到极致，以最大限度释放平台的互联网张力。

分布式运算与存储，支持海量用户访问和峰涌到来时的在线扩容，详见“高并发业务应对技术”、“海量数据处理技术”两个章节的描述。

在核心系统与平台之间设立“红线”，严格界定账户数据、资金数据与电子商务客户信息、其他信息之间的界限。

在“红线”之上，则要保证系统修改的灵活性，适应互联网业态快速迭代开发模式。

1.2.4.4.2平台运营风险

⏹风险描述

互联网业务的特点是“三分建设，七分运营”，平台建设完成投产上线只是一个起点，好的平台还需要好的运营去让它持续活跃，如何充分利用xx银行本地化优势资源，用较短的时间、花较少的钱，达到传统互联网电子商务企业近10年、投资数亿所达到的运营效果和市场影响力，是项目实施过程中就需要考虑进去的问题。

⏹应对策略

平台建设好之前就要做好相应的运营准备工作，包括制度建设，人员准备，运营准备工作等；

我公司拥有由互联网专家、电子商务专家、业务专家三大领域的人员构成的一支专业的统一信息发布及金融产品移动展示平台运营团队，可以直接实现平台建设到运营的完美过渡。

1.2.4.4.3信用风险

⏹风险描述

统一信息发布及金融产品移动展示平台交易双方的信用评价是互联网金融的基础支撑功能，在系统设计时，需考虑对消费者和商家的信用进行管理。

⏹应对策略

我公司iEC-CECFS社区电商金融整合服务平台中，对消费者和平台入驻商家的信用有完善的评价、管理和展现，平台在运营过程中不断积累用户行为数据、交易数据、信用数据，以数据为支撑建立完善的金融电商信用管理体系。

1.2.4.4.4操作风险

⏹风险描述

根据业务需要，用户在统一信息发布及金融产品移动展示平台操作中会使用到身份证号、银行账号、支付平台账号、密码等关键敏感数据，系统安全风险是首要考虑并必须完善解决的风险。

⏹应对策略

我方将从应用安全、数据安全、客户端安全、服务端安全、通信链路安全这几个方面来构建全方位的系统安全体系，详见系统安全方案章节的描述。

1.2.4.4.5需求控制风险

⏹风险描述

项目需求控制主要是指对需求变更的控制，需求变更控制的好坏会对项目成本、项目进度产生直接影响。

⏹应对策略

对于项目需求的重大变更，由甲方发起项目变更流程：

1）甲方人员提出变更请求，填写变更申请表；

2）将变更申请表交甲方项目经理；

3）甲方项目经理审批通过后，双方项目经理（或项目经理授权人，必须以书面形式确认，下同）共同审阅，评估该变更的技术有效性和对本项目的影响；

4）如果审阅批准该请求，则双方项目经理签字确认，变更申请表将被甲方文档管理员登记后，转发给乙方。

如果未获批准，其原因将反馈给该变更发起人；

5）乙方在收到经审阅批准的变更申请后的三个工作日内，发给甲方一份书面确认书，确认其收到，并给出分析与执行变更所需时间和工作量的估算；

6）根据请求的变更程度和复杂度，乙方进一步进行成本评估，若不需成本，则直接执行变更工作；若需要增加成本，则以书面形式通知甲方文档管理员，甲方管理员登记后，按照xx银行项目管理办法中的项目变更相关管理流程处理。

7）合同在履行过程中，如一方需对本合同条款或内容进行修改、补充，应提前五个工作日书面通知另一方，经双方协商达成一致后，双方签署《合同变更书》,《合同变更书》在双方授权代表签字盖章后生效。

8）合同中所附《需求说明书》中业务需求范围属纲领性文件，包括但不仅限于所提供内容，最终需以双方需求确认为准。

乙方允许甲方以合同所附《需求说明书》中业务需求范围为依据进行需求变更，超出《需求说明书》范围的需求变更则双方协商人工成本解决。

9）业务需求经双方确认后，任一方变更《需求确认书》的工作内容，应向另一方的项目经理提交书面的《需求变更申请书》。

甲乙双方项目经理审核需求变更申请，并做进一步的分析，确定需求变更的实施对日程表和其他合同条款所产生的影响。

甲乙双方项目经理审核、分析后，以书面形式决定批准或拒绝该变更申请。

双方授权代表将据此签署相应的《变更备忘录》。

经双方授权代表签字盖章后的《变更备忘录》将作为本合同的有效附件和执行变更的依据。

10）变更协议构成对合同的修改，多个变更协议之间发生矛盾时，原则上以签署时间最后的变更协议为准。

1.2.4.4.6人力资源风险

⏹风险描述

本项目是属于驻场集中开发型项目，需要在一定时间内集中较多的人力资源，包括我方的管理人员、技术人员、UI人员、测试人员、运维人员（培训及技术支持）以及xx银行的相关技术人员和业务人员，双方的人力资源的质量和到位情况对项目能否如期交付至关重要。

⏹应对策略

1）xx银行和我方的公司高层组成项目高层管理委员会，确保配合项目实施资源；

2）在项目开始前明确所有岗位的人员，清晰定义分工、责任和进度要求，严格监控执行；

3）xx银行及我公司双方项目经理均不能随意中途变更，如确需变更，需明确变更日期，并由双方共同对变更带来的风险进行评估，评估报告作为申请附件；

4）建立全本地化的技术实施队伍，集中资源在现场办公，确保沟通效率和响应效率；

5）组成专门的测试、现场服务团队，确保现场质量控制工作的专业性；

6）项目组核心技术人员负责项目售后服务支持工作，确保后续维护工作的能力和开发阶段保持一致；

7）加强对xx银行技术人员的培训，确保顺利完成产品转移和技能转移。

1.2.4.5对项目实施的承诺

1.2.4.5.1对项目的承诺

我公司科技股份有限公司针对统一信息发布及金融产品移动展示平台项目成立项目组，对项目中的业务、技术、管理以及运维等方面进行了充分讨论和测试，论证了该项目在技术上的可行性，可以保证该项目成功上线。

我公司科技股份有限公司将严格按照xx银行项目管理规范进行实施，项目经理每周定期向项目领导小组汇报项目的实施进度；同时，协调行内、公司各方人员，保证按时完成项目。

1.2.4.5.2对人员的承诺

提供足够的技术人员以确保该项目的顺利实施。

同时，项目组主要技术人员除非经客户方同意，不得随意撤换。

1.2.4.5.3项目管理承诺

本项目的项目经理由我公司科技股份有限公司担任，并定期向项目领导小组汇报项目的进展情况。