商业信用卡集成开发技术方案Word文档格式.docx

商业信用卡集成开发技术方案Word文档格式.docx

《商业信用卡集成开发技术方案Word文档格式.docx》由会员分享，可在线阅读，更多相关《商业信用卡集成开发技术方案Word文档格式.docx（100页珍藏版）》请在冰豆网上搜索。

1.SAISON信用卡公司

降低品牌运营费用，开发出更有竞争力的系统；

通过基于数据的营销系统，开展一系列的ONETOONE营销活动，包括针对新加入会员的入会介绍、积分活动等促进信用卡利用的活动，针对重要顾客的再利用专门优待、特定商品到货通知等强化关系活动，针对目标顾客及一样顾客的有关新商品、优待及纪念庆典的信息告知活动以及有关顾客反应调查、成效调查和特定调查等内容的问卷调查活动。

这一系列活动关于维系顾客与信用卡公司的关系起到了专门大的作用。

降低品牌运营费用，开发出更有竞争力的系统；

2.Orico信用卡公司

开发出分期付款、贷款、汽车消费贷款等功能合并的信用卡系统；

3.QB银行

作为以开发为主的公司，受托与SAISON信用卡公司、Orico信用卡公司以及其他公司，开发出银行与信用卡共用的信用卡系统。

1.1.3项目目标

项目要紧目标是在保持各自原有系统功能不变的情形下，把相同或者相似功能进行整合及完善，同时增加一些新的有用功能，兼容现有三家银行的业务。

1.2Introduction简介

1.2.1Purpose目的

本需求规格说明书的编写目的，是为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。

它说明了本系统的各项功能和性能需求，明确标识各个功能的实现过程，阐述使用范畴及背景，提供客户解决问题或达到目标所需的条件或权能，提供一个度量和遵循的基准。

本文档供项目经理、设计人员、开发人员、测试人员、爱护人员及软件的治理人员参考

1.2.2Scope范畴

1.Name软件名称

信用卡治理系统

2.Functions软件功能

本系统的要紧功能为：

1客户治理：

要紧分为账户治理和信用卡治理两大模块，其中账户治理包括开户、客户信息爱护、柜台存款、柜台取款和账户信息爱护；

账单查询和结算；

信用卡治理包括开卡和卡信息爱护。

2报表治理：

包括开户情形和消费情形报表的统计。

3系统治理：

包括用户添加和用户信息爱护。

3.Applications软件应用

ICC系统是符合国际标准信用卡〔贷记卡〕发卡系统，既能发行金融机构自己的信用卡，也能发行符合国际信用卡组织〔如VISA、MasterCard等〕标准的信用卡。

本系统具有客户信用评估治理、循环信用治理、卡治理、账务治理、客户信息治理、在线交易授权治理、安全治理、催收治理、批量/清算以及市场营销等功能，是真正意义上的可多币种结算的综合贷记卡软件系统；

同时，本系统具有灵活的应用架构、费用结构和产品定义，在系统、机构、产品、客户、账户、交易等各个层面均实现参数化，是一个以客户为中心的多产品、多账户、多卡综合应用系统。

1.3Level0DesignDescription第0层设计描述

1.3.1SoftwareSystemContextDefinition软件系统上下文定义

信用卡治理系统是银行卡业务体系中的一部分，提供各种接入服务整合了银联系统、ATM系统。

1.3.2DesignConsiderations设计思路

1.DesignAlternatives设计可选方案

本系统的实现采纳java语言，应用SSH框架。

2.DesignConstraints设计约束

Standardscompliance遵循标准

本软件产品应严格遵循如下规范，不能和规范相违抗，能够扩充规范中不存在的需求：

«

传输网综合网络治理系统技术规范»

客户服务系统技术规范»

银行卡联网联合技术规范V2.0»

HardwareLimitations硬件限制

最终的产品能够在分布式运行环境中运行，软件产品具有良好的可移植性，能够在不同的操作系统中运行。

会员服务应用服务器、后台应用治理服务器、银联接口网关服务器：

CPU应在P4以上，内存一样1GB～2GB，硬盘采纳单SCSI或SATA硬盘。

数据库服务器：

至强MP四路处理器、8G或以上内存、SCSI硬盘或更高配置。

最终软件产品在最低配置的pose端和服务器端能顺畅地跑起来，客户通过用户交互界面提交一项要求，要求必须在几秒之内做出响应，不能给用户有迟滞的感受。

TechnologyLimitations技术限制

数据库：

软件产品设计应与数据库无关，本系统使用MySQL数据库为主，今后能够方便的移植到其它类型的数据库比如Oracle、Informix等。

接口：

符合银联的接口标准，支持中国银联新系统〔通用规范2.0版〕的接入，能够使用银联新系统〔通用规范2.0版〕的所有新的功能。

符合营帐系统〔服务器〕的接口标准。

符合短信平台接口标准。

符合俱乐部会员治理系统接口。

并行操作：

同时承诺500个以上客户端同时运行，保证数据的正确和完备性。

编程规范：

用java和jsp实现，由开发方提供一套编程规范，甲方审查认定。

1.4Level1DesignDescription第一层设计描述

1.4.1SystemArchitecture系统结构

1.DescriptionoftheArchitecture系统结构描述

本系统结构是按照系统用户的治理权限来划分子系统。

银行一般职员只具备客户治理功能，银行经理只需要系统提供报表服务，系统治理员那么负责对系统用户的治理。

1〕客户治理子系统：

该子系统向银行的一般职员提供客户治理功能。

2〕报表治理子系统：

该子系统向银行经理提供报表服务。

3〕系统治理子系统：

该子系统向系统治理员提供用户治理功能。

4〕RepresentationoftheBusinessFlow业务流程说明

4.1客户治理子系统，银行职员对信用卡客户的治理：

4.2报表治理子系统，银行经理猎取业务报表：

4.3系统治理子系统，系统治理员对系统用户进行治理：

4.2DecompositionDescription分解描述

2.客户治理子系统

1.Overview简介

银行一般职员对信用卡用户的治理，要紧分为账户治理和信用卡治理两大模块，其中账户治理包括开户、客户信息爱护、柜台存款、柜台取款和账户信息爱护；

2.Functions功能列表

模块

子模块

功能

功能描述

客户治理

账户治理

开户

依照客户提交的资料添加账户

客户信息爱护

查询、修改客户信息

柜台存款

为信用卡客户提供还款服务

柜台取款

为信用卡客户提供取现服务

账户信息爱护

查询修改账户信息、销户

账单查询

包括未出账单和已出账单

结算

客户账单结算

信用卡治理

开卡

为差不多拥有账户的客户办理信用卡

卡信息爱护

信用卡信息查询、修改、挂失和销卡

3.报表治理子系统

银行经理能够查询信用卡开户情形以及消费情形。

报表治理

开户情形报表

某一时刻段内每月新开户的客户数量统计

开卡情形报表

某一时刻段内每月新开卡数量统计

消费情形报表

某一时刻段内各透支额区段的客户数量统计

4.系统治理子系统

系统治理员对系统用户的治理。

系统治理

用户添加

添加系统用户

用户信息爱护

爱护用户信息，包括查询，修改和删除

1.5Level2DesignDescription第二层设计描述

1.5.1账户治理模块

1.DesignDescription模块设计描述

柜台职员治理客户账户信息，提供办理账户、客户信息爱护、柜台存取款、账户信息爱护、账单查询和结算功能。

CustomerAction类

1〕CIIdentification标识

CCMS_AccountManagement_CustomerAction

2〕Overview简介

CustomerAction提供对客户信息进行查询和修改的方法，具体如下：

CustomerAction具有的方法有：

客户信息查询:

customerQuery（）、

客户信息更新:

customerUpdate（）

3〕Definition类定义〔Optional〕

AccountAction类

CCMS_AccountManagement_AccountAction

2〕Overview简介

AccountAction提供对账户信息进行处理的方法，包括，办理新账户，添加新客户，账户信息爱护，柜台存取款等。

具体如下：

添加新客户：

addCustomer（）

添加新账户：

addAccount（）

存款：

deposit（）

取款：

withdrawal

账户信息查询：

accountQuery（）

账户信息更新：

accountUpdate（）

所有的属性差不多上私有的和所有的方法差不多上public方法。

BillAction类

CCMS_AccountManagement_BillAction

BillActin要紧提供对账单的治理功能，包括账单的查询以及每月账单的结算。

具体方法如下：

查询已出账单：

queryHandledBill（）

查询账单详细信息：

queryDetailBill（）

查询未出账单：

queryUnhandledBill（）

账单结算：

calculate（）

2.FunctionIllustration功能实现说明

添加客户信息

添加账户信息

客户信息查询

客户信息修改

账单结算

1.5.2信用卡治理模块

银行柜台职员对信用卡的治理，包括办理信用卡和信用卡信息的爱护。

2.CardAction类

CCMS_CardManagement_CardAction。

该类实现信用卡信息的添加、查询、挂失和销卡。

办理信用卡：

addCard（）

查询卡信息：

queryCard（），cardDetail（）

挂失信用卡：

lossreportCard（）

销卡：

deleteCard（）

其中类图中所有的属性都为私有的，所有的方法都为公有的。

5.2.2FunctionIllustration功能实现说明

添加信用卡信息

查询卡信息

1.5.3报表治理模块

银行经理使用该模块查看业务报表。

ReportAction类

CCMS_ReportManagement_ReportAction

银行经理使用该模块信用卡账户开户情形和信用额度情形报表，还能够得到透支情形报表。

查询开户情形报表：

accountReport（）

查询信用额度情形报表：

deficitReport（）

查询消费情形报表：

consumption（）

。

客户报表：

消费报表：

1.5.4系统治理模块

UserAction类

CCMS_UserManagement_UserAction

系统治理员使用该模块能够对用户进行添加，查询，更新以及修改用户权限。

添加用户：

saveUser（）

查询用户：

queryUser（）

更新用户：

updateUser（）

修改用户权限：

updateUserStatus（）

5.4.2FunctionIllustration功能实现说明

添加用户

用户权限治理

1.6InterfaceDesign界面设计

1.6.1登录界面

1.6.2账户治理

1.开户

2.账户查询

3.信用卡开卡

1.6.3报表治理

6.3.1客户分布统计

6.3.2交易类型统计

6.4系统治理

1.添加用户

2.用户信息爱护

1.7DatabaseDesign数据库设计

1.7.1EntitiesDefinition实体定义

1.DecompositionDescription分解描述

本系统数据库设计概念模型中的实体包括银行、客户、账单记录、用户、账户、信用卡、交易记录、挂失记录、账单记录、省份和都市。

他们在数据库中分别对应银行信息表、客户信息表、账单记录表、用户表、账户信息表、信用卡信息表、交易记录表、挂失记录表、账单记录表、省份表和都市表。

2.InternalDependencyDescription内部依靠性描述

系统总E-R图：

各实体具体属性：

1.8DetailedDesignoftheDatabase数据库详细设计

1.8.1数据库表设计

1、用户表

2、账户信息表

3、银行信息表

4、账单记录表

5、都市表

6、信用卡信息表

7.客户信息表

8.挂失记录表

9.省份表

10.交易记录表

1.8.2各表联系图

1.9开发设计

1.9.1详细设计时期

在项目开发过程中，日本方面提供概要设计，和一些固定的功能模块，设计人员按照概要设计式样书写出详细设计式样书。

在写详细式样书的过程中，设计人员要看明白概要设计的整体思路并依照实际需要来发觉概要设计中的一些错误。

如此为以后项目开发省去了大量重复修改代码的苦恼。

在写详细式样书的时候，设计人员要把业务语言翻译成程序员能够快速明白得的逻辑语言。

这需要设计人员关于业务和开发语言都要有充分的明白得。

详细设计是整个项目开发的重要环节，只有那个环节做好了，后面的coding，UT，IT。

才能顺利的进行。

1.9.2CD/UT时期

程序编写人员按照详细设计式样书在HLL/WB上编写出正确的代码；

然后测试人员依照程序的测试点进行测试，并完成UT式样书。

UT测试一样由这本程序的coding人员担当。

不管如何样强调软件测试的重要性和它对软件可靠性的阻碍都只是分。

在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程紧密相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个时期都不可幸免地会产生差错。

我们力求在每个时期终止之前通过严格的技术审查，尽可能早地发觉并纠正差错；

然而，体会说明审查并不能发觉所有差错，此外在编码过程中还不可幸免地会引入新的错误。

假如在软件投入生产性运行之前，没有发觉并纠正软件中的大部分差错，那么这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成专门恶劣的后果。

测试的目的确实是在软件投入生产性运行之前，尽可能多地发觉软件中的错误。

目前软件测试仍旧是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。

大量统计资料说明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情形，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的3倍到5倍。

因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。

仅就测试而言，它的目标是发觉软件中的错误，然而，发觉错误并不是最终目的。

软件工程的全然目标是开发出高质量的完全符合用户需要的软件，因此，通过测试发觉错误之后还必须诊断并改正错误，这确实是调试的目的。

调试是测试时期最困难的工作。

在对测试结果进行收集和评判的时候，软件所达到的可靠性也开始明朗了。

软件可靠性模型使用故障率数据，估量软件今后显现故障的情形并推测软件的可靠性。

1.9.3IT时期

IT分为IT0、IT〔PC〕、IT〔HOST〕和ITY。

IT0要紧测试程序中调用的子程序；

IT〔PC〕是以概要设计为单位对程序进行测试；

IT〔HOST〕那么是以IT〔PC〕使用的数据为基础，在大型机上运行程序；

ITY那么是由日本提供雏形数据，以业务为差不多点进行测试。

系统测试是为了发觉错误而执行程序的过程，成功的测试是发觉了至今尚未发觉的错误的测试。

　测试的目的确实是期望能以最少的人力和时刻发觉潜在的各种错误和缺陷。

应依照开发各时期的需求、设计等文档或程序的内部结构精心设计测试用例，并利用这些实例来运行程序，以便发觉错误。

信息系统测试应包括软件测试、硬件测试和网络测试。

硬件测试、网络测试能够依照具体的性能指标来进行，此处所说的测试更多的是指软件测试。

系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析系统设计和实施的最后复查。

依照测试的概念和目的，在进行信息系统测试时应遵循以差不多原那么。

·

应尽早并不断地进行测试。

测试不是在应用系统开发完之后才进行的。

由于原始问题的复杂性、开发各时期的多样性以及参加人员之间的和谐等因素，使得毛开发各个时期都有可能显现错误。

因此，，测试应贯穿在开发的各个时期，尽早纠正错误，排除隐患。

测试工作应该幸免由原开发软件的人或小组承担，一方面，开发人员往往不愿召认自己的工作，总认为自己开发的软件没有错误;

另一方面，开发人员的错误专门对由本人测试出来，专门容易依照自己编程的思路来制定测试思路，具有局限性。

测试工作应由专门人员来进行，如此会更客观，更有效。

设计测试方案的时候，不仅要确定输入数据，而且要依照系统功能确定预期的输出结果。

将实际输出结果与预期结果相比较就能发觉测试对象是否正确。

在设计测试用例时，不仅要设计有效合理的输入条件，也要包含不合理、失效的输入条件。

测试的时候，人们往往适应按照合理的、正常的情形进行测试，而忽略了对专门、不合理、意想不到的情形进行测试，而这些可能确实是隐患。

在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。

余外的工作会带来副作用，阻碍程序的效率，有时会带来潜在的危害或错误。

严格按照测试打算来进行，幸免测试的随意性。

测试打算应包括测试内容、进度安排、人员安排、测试环境、测试工具和测试资料等。

严格的按照测试打算能够;

认证进度，使各方面都得以和谐进行。

妥善储存测试打算、测试用例，作为软件文档的组成部分，为爱护提供方便。

测试用例差不多上精心设计出来的，能够为重新测试或追加测试提供方便。

当纠正锱前的测试用例，或在其基础上修改，然后进行测试。

测试是开发过程中一个独立且专门重要的时期，测试过程差不多上与开发过程平行。

一个规范化的测试过程通常包括以下差不多的测试活动。

（1）拟定测试打算。

在制定测试打算时，要充分考虑整个项目的开发时刻和开发进童以及一些人为因素和客观条件等，使得测试打确实是可行的。

测试打算的内容要紧有测试的内容、进度安排、测试所需的环境和条件、测试培训安排等。

（2）编制测试大纲。

测试大纲是测试的依据。

它明确详尽地规定了在测试中针对系统的每一项功能或特性所必须完成的差不多测试项目和测试完成的标准。

（3）依照测试大纲设计和生成测试用例。

在设计测试用例的时候，可综合利用前面介绍的测试用例和设计技术，产生测试设计说明文档，其内容要紧有被测项目、输人数据、测试过程、预期输出结果等。

（4）实施测试。

测试的实施时期是由一系列的测试周期组成的。

在每个测试周期中，测试人员和开发人员将依据预先编制好的测试大纲和预备好的测试用例，对被测软件或设备进行完整的测试。

（5）生成测试报告。

测试完