银行信用卡系统技术方案DOC 88页.docx
- 文档编号:6522892
- 上传时间:2023-01-07
- 格式:DOCX
- 页数:62
- 大小:194.15KB
银行信用卡系统技术方案DOC 88页.docx
《银行信用卡系统技术方案DOC 88页.docx》由会员分享,可在线阅读,更多相关《银行信用卡系统技术方案DOC 88页.docx(62页珍藏版)》请在冰豆网上搜索。
银行信用卡系统技术方案DOC88页
银行信用卡系统技术方案(DOC88页)
摩根大通银行信用卡系统
技
术
方
案
投标人名称:
武汉佰钧成技术有限责任公司
日期:
二○一二年二月一日
前言
最后,预祝本次项目工作取得圆满成功!
武汉佰钧成技术有限责任公司
2012年2月
第一部分技术方案
1.总体设计
1.1.总体设计原则
1、实用性原则
2、有效性与扩展性原则
3、采用灵活的平台样式,页面中栏目可以灵活摆放,栏目可以灵活定义,风格样式可以灵活选择。
4、平台能够适应一定的需求变化,能快速响应信息需求和功能需求的变化。
5、操作简便,后台管理功能设计合理;具备良好的导航能力。
1.2.总体设计思路
1.2.1.采用统一顶层设计方法
1.2.2.顶层设计方法的含义
顶层设计中的“顶层”包含三个层次:
第一层、从整体和全局出发。
第二层、从整体业务框架、顶层流程入手。
第三层、从应用系统类型划分、整体架构规划入手。
1.2.3.顶层设计对象
业务和技术,正是顶层设计的两大范畴。
1.2.4.采用成熟快速开发平台
1.3.界面设计原则
1、用户原则
2、简洁性原则
3、易用原则
4、友好性原则
5、一致性原则
1.4.技术架构
基于本文前面章节所述设计原则,按层次化思路,系统技术架构的层次结构如下图所示:
2.OS/390系统
2.1.OS/390技术特点
2.2. 信用卡系统结构
1.2.1总体业务结构模型。
(1)总体业务结构模型。
持卡人、收单银行、发卡银行和卡片组织之间的关系如下:
具体业务流程如图1所示。
图1总体业务结构模型图
图2总体系统架构图
3.需求分析
3.1.总体目标
>系统的主旨是面向重点企业客户,用户通过Intemet接入。
>支持企业付款的单笔录入、批量导入,使系统更灵活,可用性更强
>实现合笔从企业对公账户扣款,并逐笔往相应的信用卡中入账,即合笔扣账,逐笔入账。
>实现根据不同企业的性质要求灵活定制企业端的复核和授权方式。
>通过第三方CA产品安全保障对企业身份验证及付款指令的加密传输。
>实现当批量报账中存在异常卡的反馈和后续处理。
>实现在网信用卡业务的5×8小时的联机服务。
>实现信用卡账务系统批量接口,批量完成逐笔入账,提高处理效率。
>提供系统的银行管理端,完成客户资料维护以及企业证书的管理。
>提供多种方式的查询,以方便企业的管理和银行的管理。
3.2.信用卡系统业务需求分析
2.2.1信用卡快速申请
1.业务描述
2.处理方式
(3)银行接收申请件后办理审批和制卡手续。
(4)领卡时补齐申请原件。
2.2.2卡资料及授权额度等信息变更
1.业务描述
2.处理方式
(1)由公司指定人员在信用卡系统填写授信额度、持卡人基本资料和账单地址变更申请单。
(3)银行接收申请信息后,将下载打印件直接作为申请原件,同时办理相关变更手续。
2.2.3多元化的查询
1.回单查询
2.综合查询
3.3.系统安全需求
一、系统登录控制与管理
1.安全证书验证
用户登录网上公务卡系统,必须通过安全和身份验证。
2.签入系统
通过用户名和密码登录系统。
二、企业端用户证书级别和权限限定
1.经办权限
(1)创建、修改报账文件和相关信息更改申请文件
(2)可以发送经复核后的报账文件、客户基本资料修改申请和账单地址变更申请
(3)不可对报账文件进行复核。
(4)不可对复核批准后的文件进行修改。
(5)不可发送未经复核的报账文件和授信额度修改申请文件。
2.主管权限
(1)只可对相关申请文件进行复核,不可对文件进行修改。
(2)不能发送所有文件。
3.出纳权限:
只能发送报账文件。
三、所有的交易数据需要加密传输
4.相关技术
4.1.IBM公司的SNA网络技术
4.2.IBMWebSphereMQSeries中间件
IBMWebSphereMQSeries中间件有着以下四方面的优点:
4.3.CICS中间件
5.系统的详细设计与实现
5.1.企业端与银行端的通讯实现
一、IBMWebSphereMQSeries中间件的基本组成描述有以下几方面:
1.队列管理器
队列管理器是MQ系统中最上层的一个概念,由它为我们提供基于队列的消息服务。
2.消息
消息有两部分组成:
二、在MQ中,还有逻辑消息和物理消息的概念。
利用逻辑消息和物理消
息,我们可以将大消息进行分段处理,也可以将若干个本身完整的消息在应用逻辑上归为一组进行处理。
队列
队列是消息的安全存放地,队列存储消息直到它被应用程序处理。
MQ消息队列的工作方式如下所述:
(1)程序A形成对消息队列系统的调用,此调用告知消息队列系统,消息准备好了投向程序B;
(2)消息队列系统发送此消息到程序B驻留处的系统,并将它放到程序B的队列中;
(3)适当时间后,程序B从它的队列中读此消息,并处理此信息。
由于采用了先进的程序设计思想以及内部工作机制,MQ能够在各
种网络条件下保证消息的可靠传递,可以克服网络线路质量差或
不稳定的现状,在传输过程中,如果通信线路出现故障或远端的主
机发生故障,本地的应用程序都不会受到影响,可以继续发送数据,
而无需等待网络故障恢复或远端主机正常后再重新运行。
2.通道
在MQ中,主要有三大类通道类型,即消息通道,MQI通道和Cluster
通道。
消息通道是用于在MQ的服务器和服务器之间传输消息的,需
要强调指出的是,该通道是单向的,它又有发送(sender),接收
(receive),请求者(requestor),服务者(server)等不同类型,供
用户在不同情况下使用。
MQI通道是MQClient和MQServer之间通
讯和传输消息用的,与消息通道不同,它的传输是双向的。
群集
(Cluster)通道是位于同一个MQ群集内部的队列管理器之间通讯使
用的。
三、IBMWebSphereMQSeries的工作原理
IBMWebSphereMQSeries的工作原理如图4.1所示:
图4-1IBMWebSphereMQSeries的工作原理
四、MQ的架构
图4-2MQ具体结构图
6.运行环境
6.1.软件平台
●操作系统:
OS/390
●应用框架:
RPG
●数据库:
DB2
●浏览器:
MicrosoftInternetExplorer6.0及以上
6.2.开发工具说明
整个平台的开发将采用IBM核心的OS/400RPG银行系统开发工具,并使用最新的版本,使整个平台具备先进的应用环境。
第二部分项目实施及服务方案
1.项目组织与管理
1.1.项目干系人分析
从这个基础出发,我们把本项目涉及到干系人分成几类,如下表所示:
干系人名称
主要职责
项目建设方(用户方):
IBM
提出并确认项目需求;
监督工程项目进展情况;
审查和验收项目工作成果;
项目承建商:
武汉佰钧成技术有限责任公司
承建IBM银行信用卡系统项目;
对建设方案中的系统进行设计、开发、实施;
按照总体技术方案和详细技术方案的要求完成系统的开发测试工作;
协助招标人、项目监理的验收评审工作;
提供系统运行维护服务;
提供培训工作;
1.2.项目组织结构
为此,建议建立如下图所示的项目组织结构:
武汉佰钧成技术有限责任公司
项目领导
小组
项目经理
项目
开发
实施
小组
IBMGDC
注:
箭头表示汇报路径。
角色
职责
人员要求
项目领导小组
项目的最高决策机构。
对项目的战略方向、IT规划、重大事件进行决策。
负责有效的将决策信息传达给项目管理小组,监督、管理决策意见的执行结果。
批准项目实施规范,协调内部资源。
项目领导小组将进行不定期会晤。
由IBM银行信用卡系统项目管理领导团队、武汉佰钧成技术有限责任公司项目管理领导人员联合组成。
项目领导小组人员,在所属机构内,必须具有项目总体规划、决策的相应权力。
项目经理
在整个项目实施期间的担任项目管理和行政管理的工作;
根据项目需要,协调各方关系;贯彻、落实项目领导小组的决策意见,并有效的监督、管理其执行状态;
定期向项目领导小组汇报项目执行情况和总体执行状态。
由武汉佰钧成技术有限责任公司相关人员担任。
项目开发实施小组
依据有效的责任范围工作定义进行具体的项目任务实施,接受管理层的直接管理,定期向管理层汇报工作。
根据项目需要,由IBM银行信用卡系统、武汉佰钧成技术有限责任公司的相关人员联合组成。
1.3.主要人员投入
角色
姓名
工龄
职务
项目领导小组
李磊
15
高管
江龙
13
研发经理
项目经理
许卫国
15
项目经理
系统架构师
张岩
13
高级工程师
数据库设计师
王辉
10
高级工程师
代码设计师
於艳
5
高级工程师
代码设计师
朱婧
5
产品技术经理
代码设计师
郝建军
2
软件工程师
代码设计师
李兴彬
2
软件工程师
质量保证员
陈新
3
QA
配置管理员
洪子娟
3
CM
美工
朱亚
5
专职美工
测试经理
刘博
5
测试经理
测试工程师
邓育飞
2
测试工程师
测试工程师
罗莲
2
测试工程师
测试工程师
杨丽
2
测试工程师
支持组-客户经理
余海霞
6
客户经理
培训工程师
邵宁
7
高级工程师
维护组
刘流
9
软件工程师
1.4.佰钧成的项目服务管理体系结构
1.4.1.公司级管理服务体系
佰钧成的决策体系保证了授权、决策渠道的畅通,使得服务管理的内部决策过程快捷、高效。
1.4.2.项目级服务管理体系结构
佰钧成建立了完善并有效的项目组组织结构和服务体系。
项目组内部岗位职责依据项目情况确定。
一般包括:
✓项目经理:
由部门级或公司级管理者担任项目经理。
✓架构师:
根据项目规模需要设立。
由项目经理提名,软件开发中心负责人批准。
✓开发经理:
由项目经理提名,软件中心负责人批准。
一般由公司高级工程师担任,主导项目编码工作。
✓需求经理:
由项目经理提名,软件中心负责人批准。
一般由公司咨询顾问和业务经理担任,对项目业务需求负责。
✓项目工程师(含开发、测试、维护):
由项目经理提名,软件中心批准。
一般由工程师担任。
✓咨询顾问:
由项目经理提名,项目管理办公室批准。
一般由工程师担任。
注:
上述为项目组的标准配置,根据项目规模的大小,上述岗位可以部分或全部合并。
对于本项目,虽然规模不大,但鉴于项目的战略地位,我公司将设立较为全面的组织结构,并配备专职人员。
2.项目实施计划
2.1.项目阶段划分
基于佰钧成软件服务最佳实践模型,依据我们对本项目的理解,定义主要项目阶段划分如下表所示:
编号
阶段名称
阶段主要工作描述
1
准备阶段
完成项目启动准备工作,主要包括成立项目组织、项目人员的确定、确定项目计划、对项目实施任务的确认、合同的签订、项目实施环境、工具等的准备。
2
需求阶段
完成需求调研、需求分析工作,为便于与客户方的交流,需求开发系统原型,最终形成需求调研报告和需求规格说明书,由公司方和客户方相关专家完成需求评审。
3
设计阶段
完成系统的总体设计、详细设计、数据库设计工作、单元测试等测试计划、用例的编制,在系统原型基础上进行进一步的设计、开发,完成最终的设计成果的评审。
4
开发阶段
以系统设计为基础完成应用软件的编码开发和单元测试工作,此外还有集成测试计划及用例的编制等其他工作。
5
集成测试阶段
完成应用软件的集成测试工作并进行评审。
6
试运行、上线及终验阶段
完成系统的试运行工作,对试运行期间发现的问题进行进一步的修改、完善和测试;同时完成系统上线过渡的准备工作,包括数据、软、硬件环境、人员培训等。
在试运行结果符合项目要求后对项目进行最终验收。
同时再上线试运行阶段,将会沿用原来系统中的数据,所做工作包括数据迁移。
7
运营维护阶段
在系统验收后进入运营维护阶段,由技术支持及服务人员对系统运行提供技术支持服务,对系统业务变化进行修改完善,保证系统正常使用。
8
贯穿各阶段的其它任务
包括项目建设中的其他一些任务,这些任务不是在哪个特定阶段完成,而是伴随整个项目实施的过程进行,主要包括数据资源的清理和规划设计、系统集成、培训、项目管理等。
2.2.项目总体计划
第1月
第2-4月
第5月
第6月
准备阶段
需求阶段
设计阶段
开发阶段
集成测试阶段
2.2.1.准备阶段
✓建立项目管理体制:
与用户就本项目的项目管理体制进行讨论,最终形成项目管理体制。
✓优化项目计划:
针对实际情况对项目计划进行优化,编写项目进度计划和预算。
✓招标书需求分析确认:
再次确认用户在招标文件中提出的需求。
本阶段要实现的里程碑是:
签订商务合同和工作说明书。
本阶段承建方的主要参与人员有售前人员、需求分析人员、架构师、项目管理人员(含质量、配置人员)。
客户方主要参与人员为项目组织人员。
2.2.2.需求阶段
本阶段主要内容为需求调研和需求分析,用户培训、初步用户手册的编制等工作内容。
✓初步用户手册的编制:
根据需求内容,编制初步用户手册。
✓需求评审:
针对需求规格说明书进行用户的需求评审。
本阶段要实现的里程碑是:
签署需求规格说明书。
本阶段承建方的主要参与人员有项目管理人员、需求分析人员、架构师、开发人员。
本期客户方主要参与人员为项目组织成员、相关业务部门的部门主管及业务骨干、科技部门相关人员。
2.2.3.设计阶段
本阶段主要内容为系统的总体设计和详细设计、数据库设计、测试方案的设计、用户培训等工作内容。
✓详细设计:
完成应用系统软件功能模块的详细设计。
✓数据库设计:
完成数据库系统的详细设计,包括数据库结构、表结构、数据字典等的编制。
✓完成系统设计的评审;
本阶段要实现的里程碑是:
评审通过项目设计方案(包括数据库设计方案)。
本阶段承建方的主要参与人员有项目管理人员、需求分析人员、架构师、开发人员、测试人员。
本期客户方主要参与人员为项目组织成员、科技部门相关人员、相关业务部门的业务骨干。
2.2.4.开发阶段
本阶段要实现的里程碑是:
完成软件的开发评审。
本期客户方主要参与人员为项目组织成员、技术人员及相关业务部门的业务骨干。
2.2.5.集成测试阶段
本阶段要实现的里程碑是:
通过系统集成测试评审。
本期客户方主要参与人员为项目组织成员、技术人员及相关业务部门的业务骨干。
2.2.6.试运行、上线及终验阶段
✓用户培训:
完成此阶段对用户的培训工作。
✓数据迁移:
完成应用系统的数据迁移工作。
✓系统过渡:
完成系统过渡工作。
✓试运行:
完成系统试运行工作。
在完成系统上线稳定运行,进行项目终验。
本阶段要实现的里程碑是:
完成系统试运行,签署系统终验报告。
2.2.7.运营维护阶段
本阶段是从项目终验合格后开始进行为期3年的质保时间。
2.2.8.贯穿各阶段的其它任务
3.项目成果和交付物
阶段名称
成果和交付物
备注
准备阶段
需求分析
需求规格说明书;
系统设计
概要设计说明书
详细设计说明书
数据库设计说明书
系统开发
编程规范
模块开发卷宗
系统源代码及执行码
单元测试计划;
单元测试报告;
培训资料(教材);
软件功能技术手册;
集成测试
集成测试计划;
集成测试用例;
集成测试报告(含压力测试报告);
试运行、上线和终验
程序清单
安装维护手册
用户操作手册
程序源代码
运营维护
技术维护手册
故障应急处理手册;
4.项目风险计划
4.1.项目风险分析
1、首先,按项目系统要素进行分析。
这主要有四个方面的系统要素风险:
⏹项目环境要素风险:
最常见的有政治风险、法律风险、经济风险、自然条件、社会风险等;
⏹其他方面的风险:
如外围主体(政府部门、相关单位)等产生的风险。
⏹工期风险,如造成局部的(工程活动、分项工程)或整个工程的工期延长,不能及时投产;
⏹费用风险,这包括财务风险、成本超支、投资追加、报价风险、收入减少等;
⏹质量风险,这包括工程等不能通过验收,工程试生产不合格、经过评价工程质量未达到标准或要求;
⏹生产能力风险,项目建成后达不到设计生产能力;
⏹市场风险,工程建成后达不到预期的经济目标,没有竞争力;
⏹法律责任风险,可能因此被起诉或承担相关法律的或合同的责任。
⏹高层战略风险,如指导方针战略思想可能有错误而造成项目总体目标设计的错误等;
⏹环境调查和预测的风险;
⏹决策风险,如错误的选择,错误的投标决策、报价等;
⏹项目策划风险;
⏹技术设计风险;
⏹计划风险,如目标的错误理解,方案错误等;
⏹实施控制中的风险,如合同、供应、新技术新工艺、分包层、工程管理失误等方面的风险;
⏹运营管理的风险,如准备不足,无法正常运营,销售不畅等的影响。
4.1.1.宏观风险分析
从项目的整体规划上看,本项目作为一项IBM银行信用卡系统的一个信息化工程建设项目,其具有以下特点:
⏹应用系统建设涉及的业务内容多;
⏹项目工程进度时间要求短;
⏹涉及业务学科领域广,且部分信息化建设任务缺乏案例和成功经验可循;
由于项目的这些特点,使项目的建设存在以下风险性:
1、项目建设的统筹规划、协调实施方面的风险性
2、项目周期相对短造成的组织、实施方面的风险性
3、项目建设经验欠缺造成的实施风险性
4、项目受不可控因素影响产生的风险性
该项目受不可控因素的影响主要表现在以下几个方面:
5、项目由于外部因素影响可能存在的风险性
4.1.2.微观风险分析
项目过程的每个阶段都存在着不同的风险,这些风险与该阶段的工作内容紧密相关。
1、合同签约立项阶段可能存在的风险:
⏹项目宏观目标不清;
⏹项目范围不明确(范围太大太小都不可以);
⏹用户参与少或和用户沟通少;
⏹对业务了解不够;
⏹对需求了解不够;
⏹没有进行可行性研究。
2、项目启动阶段可能存在的风险:
⏹项目具体目标不清;
⏹项目范围不够精确;
⏹用户参与不够;
⏹本项目的规划不够准确;
3、项目计划阶段可能存在的风险:
⏹项目队伍缺乏经验,如缺乏有经验的项目经理;
⏹仓促计划,可能带来进度方面的风险;
⏹漏项,由于设计人员的疏忽某个功能没有考虑进去;
4、项目执行与控制阶段可能存在的风险
⏹设备环境没有具备好;
⏹计划错误带来的实施困难;
⏹项目团队实施能力差;
⏹项目范围改变(突然要增加或修改一些功能,需要重新考虑设计);
⏹项目进度改变(要求提前完成任务等);
⏹人员离开,在一个项目内软件开发工作有一定的连续性,需要移交和交接,有时人员离开对项目的影响会很大;
⏹开发团队内部沟通不够,导致程序员对系统设计的理解上有偏差;
⏹没有有效的备份方案;
⏹没有切实可行的验收计划;
⏹验收人员经验不足;
5、收尾阶段可能存在的风险:
⏹质量差;
⏹客户不满意;
⏹设备没有按时到货,软件无法应用等;
6、维护阶段可能存在风险:
⏹系统运行不稳定;
⏹客户人事变化;
⏹客户业务变化导致付款出现问题;
4.2.主要风险识别及缓解措施
技术风险级别描述表
技术风险
风险级别
本项目风险
缓解措施
成熟性
现有的或局部重新设计
低
中等
配备公司核心骨干参与项目
主要部分重新设计,但技术可行
中等
技术可行的复杂设计或最新技术,某些研究已完成
高
复杂性
简单设计或局部增加复杂性
低
中等
通过设计原型解决
复杂性有中等程度增加
中等
复杂性显著增加或极其复杂
高
相关性
与现有系统、设施或相关的研制单位无关或进度取决于现有的系统设施或相关的研制单位
低
低
不需要
性能取决于现有系统性能、设施或相关的研制单位
中等
进度取决于新系统的进度、设施或相关的研制单位或性能取决于新系统的性能、设施或相关的研制单位
高
费用风险级别描述表
费用风险
风险级别
本项目风险
缓解措施
任务要求明确性
任务要求明确,使用方和承制方对任务有共同的理解
低
低
不需要
任务要求基本明确,某些细节上尚需进一步确定
中等
任务要求不明确,使用方可能不断提出新的要求或双方对任务要求有不同的理解
高
技术风险影响
无高风险项目,中等风险项目不超过2个
低
低
无高风险项目,中等风险项目超过3个
中等
有1个以上的高风险项目
高
进度风险影响
无高风险项目,中等风险的进度指标不超过2个
低
低
无高风险项目,但中等风险项目在3个以上
中等
有1个以上的高风险项目
高
成本预算准确性
有充分的类似项目的历史数据可供参考,成本估算部门有足够可用的合格人员
低
低
有足够可用的合格人员但仅有部分历史数据可供参考
中等
缺乏可用的合格人员且无类似项目的历史数据供参考
高
合同类型影响
固定价格合同
低
低
成本加奖励费用合同
中等
拨款性合同
高
合同报价影响
与其它竞标单位的报价和预测成本基本相符
低
待定
略低于其它竞标单位报价和预测成本
中等
报价显著低于其它竞标单位的报价和预测成本
高
进度风险级别描述
进度风险
风险级别
本项目风险
缓解措施
技术风险影响
无高风险,中等风险项目不超过2个
低
低
不需要
无高风险,中等风险项目超过3个
中等
有1个以上的高风险项目
高
计划安排合理性
计划切实可行且留有一定时间余度以防意外情况发生
低
中等
通过集中封闭开发和对进度加强控制,根据情况增加资源等来缓解
计划可靠,但对意外发生的问题未留有余度
中等
计划不可靠,不是根据每项研制工作的实际需要来安排时间,而是根据竞争的需要或上级命令来分配时间
高
资源充分性
资源充足且可供使用
低
低
不需要
现有资源充足,但与其它项目之间有潜在的矛盾冲突,可能因某些预想不到的问题而影响进度
中等
现有资源不足或与其它项目之间存在严重的潜在冲突
高
项目人员经验
参与该项目的人员在类似的项目中已积累了经验,有足够的知识储备可用于该项目
低
低
不需要
参与人员在类似的项目中已有一般性的经验,但在某些关键部门还缺乏有经验的人员
中等
参与人员普遍
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 银行信用卡系统技术方案DOC 88页 银行 信用卡 系统 技术 方案 DOC 88