财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx

上传人:b****6 文档编号:21007875 上传时间:2023-01-26 格式:DOCX 页数:83 大小:147.59KB
下载 相关 举报
财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx_第1页
第1页 / 共83页
财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx_第2页
第2页 / 共83页
财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx_第3页
第3页 / 共83页
财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx_第4页
第4页 / 共83页
财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx_第5页
第5页 / 共83页
点击查看更多>>
下载资源
资源描述

财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx

《财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx》由会员分享,可在线阅读,更多相关《财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx(83页珍藏版)》请在冰豆网上搜索。

财务管理信用管理 星展银行信用卡系统技术方案Word文档格式.docx

3.3.系统安全需求18

4.相关技术19

4.1.IBM公司的SNA网络技术19

4.2.IBMWebSphereMQSeries中间件19

4.3.CICS中间件21

5.系统的详细设计与实现21

5.1.企业端与银行端的通讯实现21

6.运行环境25

6.1.软件平台25

6.2.开发工具说明25

第二部分项目实施及服务方案26

6.项目组织与管理27

6.1.项目干系人分析27

6.2.项目组织结构27

6.3.主要人员投入28

6.4.佰钧成的项目服务管理体系结构29

6.4.1.公司级管理服务体系29

6.4.2.项目级服务管理体系结构29

7.项目实施计划30

7.1.项目阶段划分31

7.2.项目总体计划31

7.2.1.准备阶段32

7.2.2.需求阶段32

7.2.3.设计阶段33

7.2.4.开发阶段33

7.2.5.集成测试阶段34

7.2.6.试运行、上线及终验阶段34

7.2.7.运营维护阶段34

7.2.8.贯穿各阶段的其它任务35

8.项目成果和交付物35

9.项目风险计划36

9.1.项目风险分析36

9.1.1.宏观风险分析37

9.1.2.微观风险分析38

9.2.主要风险识别及缓解措施40

9.3.其他风险控制措施43

10.项目测试与验收方案45

10.1.项目测试方案45

10.1.1.测试概述45

10.1.2.测试目标和原则45

10.1.2.1.测试目标45

10.1.2.2.测试原则45

10.1.3.测试组织46

10.1.4.测试内容46

10.1.5.测试步骤49

10.1.6.测试过程进度及质量控制50

10.2.验收方案51

10.2.1.概述51

10.2.2.验收标准51

10.2.2.1.验收方案的原则51

10.2.2.2.系统验收标准52

10.2.2.3.问题级别定义53

10.2.2.4.测试通过标准定义53

10.2.2.5.测试异常的定义54

10.2.3.验收流程54

10.2.4.验收方式55

10.2.5.验收内容55

10.2.5.1.软件系统55

10.2.5.2.过程文档56

11.项目实施制度和规范56

11.1.实施制度56

11.1.1.决策制度56

11.1.2.沟通汇报制度57

11.1.3.需求管理制度57

11.1.4.变更管理制度58

11.1.5.配置管理制度58

11.1.6.问题管理制度58

11.1.7.文档管理制度59

11.2.实施规范60

11.2.1.质量管理规范60

11.2.2.分析设计规范61

11.2.2.1.系统分析规范61

11.2.2.2.概要设计规范62

11.2.2.3.详细设计规范63

11.2.3.系统测试规范64

11.2.4.系统开发规范66

12.项目质量保证体系68

12.1.质量保证目标69

12.2.质量保证角色与职责69

12.3.质量保证流程71

12.4.质量保证活动71

12.4.1.协助项目过程定义71

12.4.2.协助项目计划的编写71

12.4.3.质量保证计划编写与确认72

12.4.4.项目过程和产品检查72

12.4.5.问题上报76

12.4.6.质量保证工作总结77

13.项目进度控制方案78

13.1.项目进度跟踪78

13.2.项目进度分析79

13.3.项目进度控制79

14.售后服务承诺80

14.1.服务承诺80

14.1.1.质量保证承诺80

14.1.2.免费技术咨询80

14.2.服务响应承诺81

14.2.1.1.故障等级划分81

14.2.1.2.服务响应承诺81

14.3.服务目标82

14.4.服务策略82

14.5.服务方式83

15.培训保障方案85

15.1.培训承诺85

15.2.培训目标和内容86

15.2.1.培训需求86

15.2.2.培训目标86

15.3.培训类别87

15.4.培训课程88

15.5.培训方式88

第一部分技术方案

1.总体设计

1.1.总体设计原则

1、实用性原则

系统建设中,兼顾实用性、可靠性、安全性、先进性、可扩充性,在满足功能要求的前提下,尽可能降低建设成本和运行成本。

在系统建设特别是应用系统建设中,采用平台化、组件化的思想,充分利用成熟的应用支撑平台及中间件技术,分层实现,减少系统建设和维护工作量,提高系统的整体质量和效率,节省投资,应对变革。

2、有效性与扩展性原则

在多个层次的建设任务和建设阶段划分过程中,应充分体现阶段建设的有效性,尽量先满足具备条件的建设需求,将条件不成熟的建设任务后置,以免返工;

建设过程应

遵循一个时期内的有效性,够用、好用即可,避免在有限的时间内无限地扩张建设范围;

同时在有效的基础上应考虑未来一定时期内的扩展性,减少后期投入。

3、采用灵活的平台样式,页面中栏目可以灵活摆放,栏目可以灵活定义,风格样式可以灵活选择。

4、平台能够适应一定的需求变化,能快速响应信息需求和功能需求的变化。

5、操作简便,后台管理功能设计合理;

具备良好的导航能力。

1.2.总体设计思路

1.2.1.采用统一顶层设计方法

1.2.2.顶层设计方法的含义

顶层设计方法主要是用系统论的方法,对考试院信息系统建设的各个方面、各个层次、各种参与力量、各种正面的促进因素和负面的限制因素进行统筹考虑,理解和分析影响系统建设的各种关系,从全局的视角出发,进行整体技术结构的设计,并做出各种管理和技术决策,提出体制和业务的改进建议。

不管是业务处理还是内部管理,顶层设计对信息化建设的成效都起着至关重要的作

用:

在系统建设过程中,如果说没有统一的顶层设计、规划的话,那么各系统各自为政,软件、接口、体系标准都不一样,会导致互联互通实现不了,业务无法协同,内部办公效率低下。

顶层设计中的“顶层”包含三个层次:

第一层、从整体和全局出发。

顶层设计的首要视角是要跳出局部环境的束缚和影响,站在全系统互联和全网通用

的整体高度和全局视野,去分析决定应用系统建设过程中的基础、通用、平台型模块。

比如说交易、服务资源目录体系,在应用互联互通的时代,交易、服务资源目录不

但要供自己本系统、本单位使用,可能还要供相关联系统、外部单位使用,系统之间的接口必须统一兼容。

如果交易、服务资源目录这个交易调用、服务共享的关键部件,在内容、格式、接口、协议上是彼此不同的,则违背了建设资源目录的初衷,必将导致形成新的孤立割裂、群雄并存的结局。

第二层、从整体业务框架、顶层流程入手。

顶层设计的重点是业务、是流程。

应用系统开发失败的教训一再揭示正确全面描述用户需求,尽力满足用户需求的重要性,这里的用户需求,多半重点不在用户的操作需求,而是用户业务需求。

顶层设计就是用信息工程的方法,从宏观上对业务需求进行收集、梳理和描述,把业务需求按层次、体系化呈现出来。

顶层设计中的业务,不是进行业务决策,但是顶层设计的输出结果,将以丰富清晰的业务框架,帮助和推动业务决策,业务设计,业务改进和改革。

第三层、从应用系统类型划分、整体架构规划入手。

结合业务框架、顶层流程,规划合理的应用系统类型划分、整体架构规划,是顶层设计在应用系统设计过程中技术层面关心的主要问题。

规划合理的应用系统类型划分,可确保基于业务框架的系统功能切分的合理性。

可避免后续重复的系统建设,业务功能建设;

整体架构规划可确保各类应用系统的建设在技术统一、平台统一、流程一致、方法一致的基础上实现系统之间功能接口、数据接口的一致性。

1.2.3.顶层设计对象

业务和技术,正是顶层设计的两大范畴。

1、顶层设计中所指的业务,不但包括业务职能、业务结构、业务流程,还要包括业务体制、业务法律法规、业务模式、业务布局等事情。

2、顶层设计中所指的技术,主要是从全局和整体出发,对技术战略、技术框架和技术标准的分析和定义,还包括为了减少重复建设,增加资源(业务需求分析、数据模型、软件模块、系统组件设计素材等等)重用性,以模块化服务的形式,来定义所有的应用系统。

进行顶层设计,就是围绕着系统建设中上述业务和技术的种种问题,用系统规范的

科学理论方法,描述业务和技术的状态,理清业务和技术中的各种关系,确定建设目标,选择和制定实现目标的路径和战略战术,从信息化的“今天”走向信息化的“明天”。

1.2.4.采用成熟快速开发平台

在本方案中,我们将采用IBM强大、成熟的开发应用平台,利用平台提供的应用支撑框架,如页面布局管理、工作流引擎、数据交换、页面流转、事务管理等,以及大量成熟业务、技术构件,如组织机构、用户权限、系统监控等,能够快速搭建各类业务应用,有效降低应用系统开发的进度风险和质量风险。

1.3.界面设计原则

1、用户原则

访问界面设计首先要确立涉众用户类型,通过划分不同层次的用户类型,分析其不同需求,从多方面加以设计实现,提供用户自定义界面服务功能。

2、简洁性原则

界面反映的信息量要求最小,界面设计要尽量减少用户记忆负担,采用有助于记忆的设计方案,使用户操作更容易短期上手。

3、易用原则

软件界面设计要直观、对用户透明,最终用户接触软件后对界面上对应的功能一目了然,便于用户的理解、学习、掌握,不需要专业培训就可以方便使用系统。

4、友好性原则

人机界面友好,具有很强的在线帮助功能,方便操作和维护。

要对用户的操作命令做出反应,帮助用户处理问题,提供智能业务提醒功能,辅助业务流程工作。

系统要设计有恢复出错现场的能力,在系统内部处理工作要有提示,尽量把主动权让给用户。

5、一致性原则

界面风格统一设计、统一实现。

使操作界面清晰,美观,干净,直观,前后操作连贯。

在界面设计中应该保持界面的一致性,确立界面设计标准。

包括显示信息、错误提示、快捷方式、页面布局、交互方式等标准,使系统风格始终保持一致。

1.4.技术架构

基于本文前面章节所述设计原则,按层次化思路,系统技术架构的层次结构如下图所示:

系统技术架构由界面访问层、业务应用层、应用支撑层、数据资源层、系统设施层、网络通信层和支撑体系七个层次构成。

其中,支撑体系又分为标准规范体系、安全保障体系和运维管理体系。

2.OS/390系统

2.1.OS/390技术特点

OS/390操作系统是IBM公司最引以为豪的系统软件,它秉承和扩展了MVS的传统强势,是一个具有整合性功能的集成企业服务器操作系统。

它将开放的通讯服务器、分布式数据和文件服务、并行复合系统支持、面向对象程序设计、DCE以及开放应用程序接口集成为一个产品,为用户提供了一个集成化的、具有可扩充性的系统。

在体系结构上基于之前的System/370做了一系列改进,向量处理、新的通道结构ESCON、保密硬件措施以及SCE系统控制单元技术使得OS/390具有更

强大的处理能力。

OS/390通过逻辑分区和虚拟技术可以把多个服务器上的应用集中到一台大型主机上实现集中管理,消除分散系统开销难以预见的困难,管理成本清楚可见。

同时,大型机区别于UNIX服务器系统的最关键因素在于大型机在支持大型工作负荷和大规模用户数方面的能力显著。

在开放的运行环境下,OS/390系统具有自动工作负载管理功能,根据工作量自动调整资源分配,结合OS/390最佳系统恢复能力及资料一致性机制,在出现故障时能保持最大限度的系统继续可用,确保客户至上的服务品质。

OS/390拥有可进行并行数据严谨分析的安全网络及时髦的网络计算功能,可并行快速地分析和处理企业级数据,保证对动态商业环境灵活反应,完成商业重要度管理。

一直以来,OS/390始终保持向上兼容与开放性。

目前,IBM的z系列可以支持

Java、J2EE等新标准;

WebSphere等电子商务应用程序服务器软件以基于JAVA的

Servlet引擎为基础,可以使用IBMConnector系列访问大型机的资源(如CICS和IMS);

OS/390结合MQ、CICS等中间件软件,可完成强大的多人、多工在线联机交易功能、

批处理、数据挖掘、Web服务等功能。

2.2.信用卡系统结构

银行的信用卡系统业务负载较高,峰值交易量巨大,且对数据的存储、安全性与处理速度有较高的要求。

基于OS/390的上述技术特点和优势,提出了一种基于OS/390大型机平台的银行信用卡系统模型,这里介绍其总体结构和技术特征。

1.2.1总体业务结构模型。

(1)总体业务结构模型。

持卡人、收单银行、发卡银行和卡片组织之间的关系如下:

申请人先向发卡银行申请信用卡,发卡银行按一定策略对申请者的信用状况进行评

估,对符合条件的申请人核发信用卡。

持卡人取得信用卡后即可到特约商店进行消费,每笔消费交易之前,特约商店会发起授权请求,通过信用卡国际组织授权清算网络向发卡银行请求授权,发卡银行根据卡片的信用状况决定是否给与授权,并将结果反馈给特约商店。

特约商店取得授权后,即可为持卡人提供相应服务,持卡人要对消费行为及金额进行确认。

之后,特约商店会依照消费金额向收单银行请款,收单银行会将钱先付给特约商店,再通过信用卡国际组织的清算网络向发卡银行请求清算,发卡银行确认后,将钱付给收单银行,并将消费金额计人持卡人帐户。

当持卡人账单日到时,通过计算机系统将持卡人本月全部交易金额进行汇总,打印账单给持卡人,要求缴款。

持卡人收到账单后,经确认无误,通过发卡银行的缴款通路缴纳消费款项。

当有争议发生时,会依照授权码、消费签单,进行调单扣款作业处理。

若持卡人在规定时间内未按要求交清所欠款项,发卡银行要对持卡人进行催收作业及一系列后续处理。

在信用卡使用的整个循环中,发卡银行的计算机系统要完成征信发卡、授权、帐务帐单、催收调扣等主要模块的功能。

具体业务流程如图1所示。

图1总体业务结构模型图

(2)总体系统架构。

信用卡业务整体需求的特殊性决定了其计算机系统架构的复杂性。

授权请求交易过程必须在线及时处理,同时持卡人会在全球各地、任何时刻进行刷卡消费活动,能否及时快速对如此大量、密集、不间断的授权交易请求作出准确、高效的响应,是衡量发卡银行计算机系统响应处理能力的重要指标同时,在计算机系统出现故障

和异常时继续保证授权交易的正常进行是必须解决的关键问题。

在后续请款、清算、帐务账单、催收和调扣处理过程中,系统中要存储大量关键数据,以供应用系统结合业务处理逻辑对数据进行加工处理,为银行提供各种需要的结果。

如何管理好这些海量数据的存储和加工,在时空效率上满足业务要求,一直是计算机系统处理能力的瓶颈。

针对上述问题,结合最新ES9000系列大型机技术发展的成果,在OS/390操作平台下设计新的计算机应用系统的整体体系架构如图2所示

图2总体系统架构图

在图2中,数据处理服务器采用IBMES/9000大型机,应用系统中大量业务数据的存储和加工处理、数据完整性与安全性由OS/390下的VSAM文件系统管理,各交易通路的数据获取及维护请求通过OS/390下的在线交易处理中间件CICS技术实现。

联机前置处理服务器采用HP公司的TANDEM机,完成OLTP前置处理和备援功能,当ES/

9000主机进行批量作业处理和有故障时完成代行功能,处理授权交易请求。

各交易通路有自己的管理中心,通过各自的前置系统连接各种终端设备,再将业务进行处理、转发和传送。

NETBANKSERVER、CALLCENIER和D0WNL0ADSERVER完成网络银行、

电话银行及其他各种交易通路数据格式的转换及可靠连接传输功能。

与VISA和

MASTER国际组织之间的信息交互由VAPSERVER和MIPSERVER承担,AS/400的交换网络承担连外通路的收单功能,系统中对各业务关键节点进行双备份,比如信用卡

中心的局域网等。

但是,为了简明起见,没有画出。

在上述架构中,整个系统既能集中管理信用卡业务的海量数据,同时又能对各交易通路的在线服务请求作出快速、准确的响应,最大程度地满足了信用卡业务整体需求。

3.需求分析

3.1.总体目标

在信用卡系统中,针对信用卡业务的特点,企业提出可以通过网上单笔或批量两种方式对本企业账户下属的所有职员的信用卡进行报销款项转账业务并可以完成本企业账户下属的所有职员的信用卡快速申请和授信额度的灵活变更等信用卡辅助使用功能。

通过对以上企业提出的需求进行分析,设计信用系统是应主要实现以下几方面的功能:

>

系统的主旨是面向重点企业客户,用户通过Intemet接入。

支持企业付款的单笔录入、批量导入,使系统更灵活,可用性更强

实现合笔从企业对公账户扣款,并逐笔往相应的信用卡中入账,即合笔扣账,逐笔入账。

实现根据不同企业的性质要求灵活定制企业端的复核和授权方式。

为实现及时完成企业报账划款的要求,必提高系统的安全性,实效性,信用卡系统要实现联机会计业务,即联机的会计扣账和冲账业务。

通过第三方CA产品安全保障对企业身份验证及付款指令的加密传输。

将原来分行与支行间资金的手工清算变为分行与支行间逐笔实施清算,将所有企业的对公账户扣款直接划归在分行卡部信用卡专户中,以完成逐笔入个人信用卡账户的

功能。

实现当批量报账中存在异常卡的反馈和后续处理。

实现在网信用卡业务的5×

8小时的联机服务。

实现信用卡账务系统批量接口,批量完成逐笔入账,提高处理效率。

银行处理端规范业务操作,相关传票、分录、特种转账传票由系统自动生成借口文件传到OnDemand报表系统中,减少手工操作风险。

提供系统的银行管理端,完成客户资料维护以及企业证书的管理。

提供多种方式的查询,以方便企业的管理和银行的管理。

3.2.信用卡系统业务需求分析

2.2.1信用卡快速申请1.业务描述

是指客户通过网上信用系统向银行端发送申请办理信用卡的电子信息,银行对电子

信息进行下载处理后,经过申请处理、审批、录入和开户等流程完成制卡手续,待领卡时补齐申请原件的业务处理。

2.处理方式

(1)由公司指定人员在信用卡系统填制信用卡电子申请表,要素包括:

姓名、性别、

身份证号码、家庭地址、部门名称、联系电话、账单地址等字段。

(2)填妥后,附上申请人身份证扫描件发送至主管进行审批,审批后,回传至经办。

由经办将审批后的申请表和身份证扫描件发送至银行端。

(3)银行接收申请件后办理审批和制卡手续。

(4)领卡时补齐申请原件。

2.2.2卡资料及授权额度等信息变更1.业务描述

是指客户通过信用卡系统提交授信额度的增加与修改、公司基本资料的修改、账单地址的变更等信息,银行接收客户提交的申请信息进行下载打印,并视作为有效申请,按正常流程进行处理的业务操作。

(1)由公司指定人员在信用卡系统填写授信额度、持卡人基本资料和账单地址变更申请单。

(2)填妥后,将《额度申请表》发送至主管进行核批,核批后,回传至经办。

由经办将核批后的申请单发送至银行端(其他变更信息不需复核)。

(3)银行接收申请信息后,将下载打印件直接作为申请原件,同时办理相关变更手续。

2.2.3多元化的查询1.回单查询

输入日期及当日的报账批号即可查询当天此批号报账业务的银行处理情况,如果当

天银行回单中有错误记录,则缺省显示出来,方便企业及时掌握报账处理情况广采取相应的措施。

也可以根据日期和卡号查询某一张公务卡报销处理的情况。

2.综合查询

提供一个全面的查询功能。

可能多选择的组合模糊查询,更方便企业的使用。

强化了网上公务卡的企业财务的管理功能。

3.3.系统安全需求

对处理不同业务的企业端操作人员应根据不同的级别和操作权限对身份进行验证

(登录财务中心系统必须持有CA认证证书,该证书应达到相应技术安全认证标准),保证交易安全和身份认证的有效性和合法性。

一、系统登录控制与管理

1.安全证书验证

用户登录网上公务卡系统,必须通过安全和身份验证。

2.签入系统

通过用户名和密码登录系统。

二、企业端用户证书级别和权限限定

1.经办权限

(1)创建、修改报账文件和相关信息更改申请文件

(2)可以发送经复核后的报账文件、客户基本资料修改申请和账单地址变更申请

(3)不可对报账文件进行复核。

(4)不可对复核批准后的文件进行修改。

(5)不可发送未经复核的报账文件和授信额度修改申请文件。

2.主管权限

(1)只可对相关申请文件进行复核,不可对文件进行修改。

(2)不能发送所有文件。

3.出纳权限:

只能发送报账文件。

三、所有的交易数据需要加密传输

4.相关技术

4.1.IBM公司的SNA网络技术

SNA(SystemsNetworkArchitecture)系统网络结构,是IBM公司开发的网络体系结构,是一组大型网络标准和协议,包含着IBM大型机网络环境中配置和管理系统资源的服务,

SNA定义了大型机主机控制终端的集中体系结构,是IBM大型机和中型机的主要联网协议,在IBM主机环境中得到广泛的应用。

SNA这个体系结构中,包括大型计算机系统(ES

/9000、S/390等)、中型机计算机系统(AS/400)、3270终端和台式计算机,并有一个使这些系统与主机系统通信或系统间相互对等通信的策略。

SNA定义了数据通信网络的逻辑架构,网络资源之间进行同步通信的协议,网络上传输的信息格式;

描述了

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 小学教育 > 数学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1