重庆三峡银行平安输入控件基础软件采购项目招标书.docx
《重庆三峡银行平安输入控件基础软件采购项目招标书.docx》由会员分享，可在线阅读，更多相关《重庆三峡银行平安输入控件基础软件采购项目招标书.docx（32页珍藏版）》请在冰点文库上搜索。
重庆三峡银行平安输入控件基础软件采购项目招标书
重庆三峡银行
二维码效劳平台项目
招标书
重庆三峡银行股分
2017年7月
目录
第一章项目介绍及需求
一、项目背景
随着移动互联网的进展，快捷支付成为大伙儿争相把握的关键技术。
其中二维码支付是一种基于账户体系搭起来的新一代无线支付方案，以其技术成熟、利用简单、支付便利、本钱较低的优势成为互联网支付的主力军。
专门在于2021年开始，互联网公司的支付大战掀起金融支付的革命浪潮。
而金融支付的传统银行却沦为看客，这成为银行业的为难。
在人民银行大力推动下，陆续解决了二维码支付的平安问题，各家银行也开始踊跃投入，分享那个互联网金融大蛋糕。
作为中国银行业支付领域的领军者中国银联也在踊跃推动二维码支付，拾起曾经丢失的支付市场。
近日中国银联《关于加速推动二维码支付收单业务的函》（业管委秘[2017]7号）更是要求银行尽快完成二维码支付系统改造并投产上线。
我行在二维码支付上已经有了长足的熟悉和预备，并取得必然的成绩。
借助这次银联的二维码支付业务，我行必然能更进一步的扩大支付市场，享受互联网金融功效。
二、项目建设目标
这次建设二维码效劳平台是基于全行级考虑，是我行转型时期，全面实现大零售的关键步骤。
通过建设二维码效劳平台，提升我行在移动支付市场话语权，专门是结合我行在互联网上投入建设更全面市场营销，巩固传统优势，拓展新兴用户市场。
通过支付能力的输出配合各类优质产品和效劳，将更多的商户纳入整体的支付体系。
不仅保留老的客户，还能够快速的占据部份缺失市场，将以前咱们未覆盖到的支付市场从头捡回来，实现真正大零售的战略目标。
为此我行将“二维码效劳平台”定位关键工程，其项目建设目标如下：
1、通过建设支付平台实现多种支付模式（聚合支付），达到一个平台多种方式的成效。
2、通过建设支付平台实现业务扩展能力，吸收更多的商户成为咱们的客户，在业务上实现多重获利点。
3、通过平台建设，打破移动支付的技术壁垒，提升行里科技含量，为尔后互联网相关技术沉淀技术储蓄。
三、项目进度及要求
从投标方进场开始，包括需求分析、系统设计、开发及系统考试、验收测试、上线前演示、接入设备试运行、正式投产等时期
这次中标的厂商须配合项目组完成项目相关调试，并提供指定品牌的设备安装、调试等系统集成工作且提供设备运行中因为系统故障的维保效劳。
四、项目治理要求
（一）项目整体治理要求
投标方应认真阅读招标文件的所有内容，结合招标方对项目建设的目标和进度实施要求，制定并提出有效可行的项目实施打算和完整可落地实施的解决方案。
投标方须按招标方认可的实施打算和方案推动项目建设，依照项目质量、进度、风险等几个重要维度完成项目治理工作，具有完善的项目治理方法和较强的项目操纵能力，较好地和谐与本项目相关的各关联系统开发进度，在保证项目质量的前提下严格操纵项目进度，与招标方一起监督、指导与本项目相关的各系统建设进度，保证运营流程再造项目实施成效符合招标方要求。
（二）治理方案要求
招标方要求项目采纳驻场开发模式，由招标方提供开发场地，投标方应依如实际情形自备必要的设备。
在项目实施及驻场维保进程中，投标方应遵守招标方关于合作公司人员治理的各项规定。
投标方在本项目实施进程中须对项目治理涉及的以下几个方面提出治理方案：
1.项目的治理组织方案和工作机制。
针对本项目的特点，提出适合本项目的治理组织方案和工作机制。
2.进度治理方案。
针对本项目特点说明进度操纵的要点及风险，如何确保工期。
3.风险治理方案。
针对本项目特点说明项目风险及难点，包括技术方面及其他方面，对项目可能产生的风险进行有效识别，并制定有效地风险操纵方法。
4.质量治理方案。
针对本项目特点提出合理的质量治理方案，须对设计质量、开发质量、文档质量及培训质量等一系列的问题提出治理方案。
5.配置、变更治理方案，要求针对代码版本治理、文档治理、变更治理提出治理方案。
（三）人员要求
投标人应许诺未征得我行书面同意的情形下不得改换项目成员。
所有成员必需为投标人单位员工，不得外包其他单位员工，如有发觉，招标方有权要求改换项目成员或解除合同。
如有本地化研发实施团队，那么需提供相关证明材料。
项目组须设置项目领导、应用开发、系统集成、质量操纵及测试等相关责任人，并提供关于本项目治理操纵体系、需求分析建模需求治理体系、测试及质量治理体系、源代码及配置治理体系、文档质量操纵体系、进度操纵及风险操纵体系的体系文档和例如。
项目经理
五年以上项目管理、系统分析经验及软件架构设计经验，有独当一面的技术能力；负责实施过两个以上二维码服务平台项目，直接对项目的实施负责，通过对工期、成本、质量的控制（包括总体制定、执行、跟踪、调整相关计划，协调项目可用资源），确保项目按要求完成
测试经理
五年以上相关项目测试和管理经验
需求分析师
5年以上银行业务系统分析、设计经验
熟悉银行业务流程和相关法律法规。
负责完成过两个以上二维码服务平台项目的需求分析工作；
能够辅助行方完成业务流程梳理、整合以及创新
善于表达、具有良好的沟通技巧和能力
架构师
要求担任过至少一个类似二维码服务平台项目的主架构师和7年以上相关工作经历，并且熟悉SOA、分布式架构以及主流开发框架
项目组开发人员
至少2年开发经验，开发组长须有至少3年开发经验，且均有银行相关系统的项目实施经历
项目组测试人员
具有2年以上银行相关系统测试经验
评标前我行需对项目领导、测试领导、架构师、需求分析师进行面试，需提供人员简历信息，要求若是中标以上核心人员必需到场，不得改换。
同时，我行将对所提供的人员进行考核，达不到我行要求的将要求替换。
（四）项目实施要求
在本项目实施周期内，如碰到原系统功能与需求不符，需要及时调整实施方案，知足我行的要求，并征得我行同意方可变更。
投标人在项目实施进程中，需依照我行项目治理标准提供相应文档（所有提交文档必需为中文），并提供定制开发部份及相关应用系统的源代码。
禁止应用软件部署利用的安装码或授权码与其运行的基础环境（如：
硬盘序列号、CPU序列号或网卡序列号等）进行绑定。
（五）知识产权要求
如无特殊说明，定制开发部份知识产权归我行所有。
投标人应许诺在项目顶用到的各类工具、产品、组件、文档无任何知识产权问题，若是产生纠纷或其他问题投标人要负责承担给我行带来的一切损失。
五、业务需求
该项目的要紧目标是构建我行统一的二维码支付平台，实现各渠道二维码标准的整合，对商户、定单、用户、渠道的二维码进行治理。
通过与银联、微信、支付宝等二维码处置系统进行交互，实现本行、微信、支付宝和银联二维码支付，为电话银行、三峡付、传统POS、智能POS、自助终端等渠道提供相关的的二维码应用接口，实现二维支付的消费、人到人转账、ATM取款等二维码相关业务，可供行内多渠道集成。
该平台应分为三大模块：
1、二维码网关：
该模块要紧作为二维码互联网跳转页面的入口和二维码的路由；
2、二维码处置模块：
该模块要紧功能是二维码的生成、校验、治理。
3、二维码业务模块：
该模块作为业务治理系统和第三方二维码支付的前置。
在系统层面该平台要实现的功能有：
1、统一行内标准：
基于银联二维码标准制定本行二维码的标准；
2、生成、治理、校验二维码：
涉及的码种有：
固态码、静态码、收款码、付款码、取款码；
3、银联二维码支付：
通过与银联二维码处置系统交互，实现银联二维码相关业务，包括消费、转账、ATM取款；
4、信息平安：
依照银联提出的《中国银联二维码支付平安标准》及相关行业标准，在系统建设进程中确保二维码支付的业务的平安开通、二维码中信息不被泄露和窜改、平安的信息传输、平安的支付进程等多方面的平安目标来保证个人、商户/机构信息及支付交易的平安，确保二维码支付业务的平安、稳固和高效运行。
5、与电话银行和三峡付APP交互：
配合电话银行实现二维码功能的开通、账户绑定、token治理、申请、展现、扫码、支付、收款、取款；
6、聚合收单：
通过与微信、支付宝等第三方支付公司之间的系统交互，以二维码聚合的方式，实现“聚合收单”；
7、与综合收单平台交互：
配合综合收单平台实现商户二维码的申请、保护治理、查询校验定单信息，和清算文件的获取、处置、转发；
8、与行内营销系统交互：
配合营销系统实现二维码支付的营销宣传功能。
本次实施功能模块
模块
功能点
主扫消费
订单查询
营销查询
主扫付款
交易结果查询
交易明细查询
交易结果通知
交易撤销
交易部分退货
交易全部退货
交易冲正
被扫消费
生成付款码
附加处理请求查询
附加处理请求完成通知
交易结果查询
交易明细查询
附加处理请求
交易结果通知
交易撤销
交易部分退货
交易全部退货
交易冲正
人到人转账
收款方-收款码申请
收款方-收款结果查询
收款方-交易结果通知
付款方-订单查询
付款方-付款
付款方-付款结果查询
付款方-付款确认
付款结果通知
收款结果通知
付款方-交易结果通知
本行二维码
本行二维码生成
本行二维码被扫支付
本行面对面转账解密
获取二维码信息
本行账务处理
二维码管理
二维码产品参数管理
渠道二维码管理
证书管理
二维码验证次数管理
二维码白名单管理
二维码流水查询
二维码对账结果查询
二维码交易限额管理
日终批量处理
对账文件申请
对账文件解析
数据准备
数据核对
差错录入
对账文件下发
日间批量处理
主扫交易结果轮询查询
被扫交易结果轮询查询
六、技术要求
一、整体原那么
1.有效性原那么
充分利用成熟的先进技术，应用系统设计必需符合实际，适用于邀标人二维码效劳平台建设要求。
2.开放性、兼容性原那么
所设计的系统在结构上真正实现开放，各类设计标准、技术指标及产品均符合国际和工业标准，包括各类广域网、局域网、运算机及数据库协议，并可提供多厂家产品的支持能力，从而为以后的业务进展奠定基础。
系统中所采纳的所有产品都要知足相关的国际标准和国家标准，并符合邀标人的实际需求，而且是开放的可兼容的系统，能与不同厂商的产品兼容，能够有效爱惜投资。
系统具有与各类协议运算机通过网络互连互通的特性，确保综合网公用基础设施功能充分发挥。
应从如下方面考虑对当前市场主流终端维持良好的兼容性：
应用系统所部署的操作系统、数据库、中间件等系统环境应该利用重庆三峡银行购买过的软件产品，不利用盗版的系统环境软件，假设利用了开源、免费的环境软件等应在交付文档中做出详细的说明。
软件的版本应在原厂的支持范围，幸免利用已经或即将停止保护的软件及补丁版本；幸免利用存在高风险、高危漏洞、漏洞多发的软件与技术框架（如struts2等漏洞多发框架）。
系统应该能够支持所有行方利用的硬件产品，做到系统功能与硬件设备无关。
系统设计应该充分考虑开放性的要求，不依托于某一种特定的操作系统、中间件、数据库等产品。
3.先进性和前瞻性
系统技术水平要保证先进性，符合今世信息技术进展形势，提供良好的技术支持和技术效劳，以知足当前的业务需求，使业务或生产系统具有较强的运作能力。
系统体系架构和软件体系结构要有前瞻性，要充分考虑以后业务的进展和治理的转变，方便对新业务和新需求的扩展和支持，知足银行持续进展的要求。
4.灵活性和可扩充性
所设计的系统应具有良好的扩充性，包括软件、硬件系统在性能上的可扩展性能够依照治理要求，软件系统达到组件化开发要求，在源系统改造或前端应用的需求发生转变时，整个系统的架构和设计方式能够适应这种转变，在功能变更、二次开发时对原有系统阻碍要小，能快速依照应用需求对系统进行接入，可不能对已有的平台造成阻碍。
在性能指标达到预警值时，能够通过横向扩展集群模式达到性能的线性增加。
投标人设计的系统应具有线性或近似线性的性能扩展能力，并能在不断止效劳的的情形下完成容量伸缩。
5.靠得住性与稳固性
需知足我行和监管机构的业务持续性要求，可实现7X24小时的持续稳固运行，系统整体可用性要求在%以上，每次发生预期或非预期停机事件后能够在2小时内恢复运营。
6.容错性
系统应具有足够的错误抗容和恢复能力，包括在犯错乃至意外崩溃时，能保证处置事务的完整性、交易的完整性，和通过重启系统等简单手腕恢复正常的运行状态等。
7.易保护性
在系统整体设计上注意系统的可保护性。
尽可能采纳大伙儿熟悉的易于保护的系统平台。
系统软件安装简单、易于操作。
系统上必需提供充沛的保护工具，包括但不限于：
运行日记、异样日记、发布工具、运行监控工具、数据（包括文件）备份工具、垃圾清理工具等，确保关键业务行为和异样能够被追踪，日常保护工作大体自动化。
二、系统架构要求
1、网络拓扑架构方面
本次项目需要知足我行三层隔离的网络平安结构。
2、应用系统架构方面
本项目需要依照我行应用架构计划和业务各项需求的关联性，维持系统架构以高内聚、低耦合为系统建设标准，最终使应用系统具有清楚的和相对独立的软件层次，系统内各个模块之间耦合度小为大体架构，兼具高弹性、高性能、高靠得住性并具有较高业务敏捷性的业务支撑平台。
支持多种开放技术标准，应该提供标准的接口接入能力，便于扩展应用功能与其它系统的互联。
3、应用数据架构方面
应依照本系统有关数据的要求，设计合理的数据库体系，使之在后台数据处置及前台业务操作性上有一个合理的平稳和可扩充性；数据库的设计应兼顾我行现有相关系统的接口要求；在设计数据库时，应依照系统情形别离对历史数据、衍生数据、治理数据和其他数据的量进行估量，合理设计数据库结构，投标人必需提供：
详细的数据容量估算；相应的数据字典设计方案；相应的表结构和说明。
应以提高数据库的运行效率为原那么优化设计系统数据结构，数据库原那么上只限于数据存储方式利用，不用做数据运算方式利用，即对存储进程、触发器等对象原那么上禁止利用，假设必需利用那么需给出详细说明。
应基于数据存储需求，并在对各类数据的数据量大小、业务应用特点进行充分分析的基础上，设计合理的数据存储方案，方案中应充分考虑每一类数据的存储位置、存储方式、数据访问方式等。
数据访问层设计应知足可移植的持久层、适应数据结构转变的设计、完整是事务支持（尤其在分库分表时）的设计；严禁在应用中硬编码SQL语句。
4、应用部署架构方面
应用系统和及其关联各子系统需采纳集群或散布式的部署方式，知足目前相关的性能指标，由于业务进展致使系统性能不能知足业务要求时，可通过横向增加效劳节点，知足新的性能需求。
应用系统之间逻辑独立、启停效劳时系统间不彼此阻碍的部署方案。
应用系统应支持双活跨数据中心的部署方案。
三、应当遵循的标准和标准
应用软件开发符合软件开发标准的要求，方便保护和扩展。
业务处置符合国家法律、法规和有关政策规定。
数据标准要知足银监会及人民银行相关治理方法及标准化的要求。
应用系统应严格遵循行内系统的接口标准；支持多种主流通信协议（包括TCP、HTTP、FTP等）、中间件（包括MQ、Weblogic、WAS等）和通信模式（包括短连接、同步、异步等）,支持多种标准报文格式（包括XML、ISO8583、定长等）和自概念报文格式的解析、组装和转换功能；支持主流的数据库（Oracle11G、DB2，如假设不支持，请说明）；
系统架构必需遵循招标方应用架构统一架构标准；对外交互界面（含接口、交互流程）均需遵循招标方确信统一标准进行设计和开发；同时开发进程的产出物（如：
设计文档、代码、测试案例、测试报告等）也需完全遵循招标方确信的统一标准标准完成。
四、非功能性要求
（一）、运维要求
1、提供日常运行监控和完整的系统保护治理的方案：
提供日记、实时交易监控等系统问题定位方案；提供日记和历史数据备份、清理机制；
2、提供给用系统之间逻辑独立、启停效劳时系统间不彼此阻碍的部署方案（十分重要），保障系统的7*24小时运行；
3、数据库建表语句需包括字段的详细注释
4、提供系统资源运行情形实时监控报告；提供系统显现异样预警报告；提供系统运行情形报表等。
5、涉及重大生产故障，需15分钟内响应，30分钟内提供临时解决方案并能恢复活产效劳，并安排响应的技术专家进行技术支持。
（二）、日记要求
1、应完整记录所有通信日记，若是通信日记为字节码的，不能直接查看的，应提供查看工具。
2、应完整记录交易日记，方便交易统计分析，不同类型的交易可分不同的交易日记表。
3、可在线动态调整日记级别，在生产环境下定位问题时不需要中断效劳。
4、系统相关日记应输出在应用目录之外。
（三）、自动监控指标
1、磁盘占用率（关键目录）、CPU利用率、内存占用率等；
2、数据库连接池利用情形：
总连接数、空闲连接数、利用中连接数；c、线程池利用情形：
总线程、空闲线程、利用中线程；
3、虚拟机堆内存情形（适用Java）：
空闲内存、利用中内存；
4、交易级的错误，应用系统重大错误；
（四）、平安性&稳固性要求
通太高靠得住的产品（硬件、软件、效劳），带有系统容错性的方案（冗余、备份），较强的治理机制和操纵手腕，保证系统的平安靠得住和高可用性。
系统建设需要用到的软件产品利用主流产品，以保证系统的高质量和稳固性。
系统建设需要结合重庆三峡银行提供的软件平台和数据库平台等基础环境要素，提出完善的平安机制和靠得住性保障。
系统开发应付各类数据的治理和操作，具有完善的分级权限机制，保证数据的平安和合理利用。
系统必需能够提供有效的平安机制，抵御可能产生的歹意和病毒解决，而且在运行平安、网络平安和应用系统平安等方面有合理的靠得住的策略，平安机制与应用系统要相对独立，能够替换不同的平安产品。
系统应提供完整的数据平安方案。
1）、数据通信及灵敏信息平安性：
提供通信级的数据加密，保障数据传输平安；关于灵敏信息（如密码、密钥等），应保障更高的平安品级，在应用级加密处置，不能以明文的方式保留相关密码;
2）、数据一致性，在任何异样和故障情形下，一个交易对数据库的所有更新或是全数完成，或是没有执行，不能有中间结果，保证交易的完整性。
3）、数据备份：
应提供各类业务和系统数据的备份、恢复和快速检索方案;d,灾难备份：
提供可操作性的系统灾难备份方案。
应用程序不得与操作系统的用户名/密码相关，应采纳参数的模式记录所链接的数据库IP地址、数据库实例名、用户名/密码等信息，以支持按期修改相关密码。
密码不能以明文形式存储在文件或配置中。
应用应具有接口访问平安设计，如Token授权机制、时刻戳超机会制、签名机制等；应用应具有稳固性设计，如效劳限流机制、效劳降级机制等效劳管控机制的应用。
依照二维码效劳平台高可用要求，系统构建时应采纳先进的物理、逻辑架构（如：
散布式、去中心化SOA、微效劳等），从全然上提高系统的整体可用性。
系统应最大限度集成业界最稳固且优秀的技术及组件，采纳先进技术以降低系统的不稳固性，同时，应考虑对功能和数据进行合明白得耦（例如采纳数据纵切分库等），幸免故障时的阻碍扩散。
另外，对系统如硬件、操作系统、网络、数据库应设计尽可能详尽的故障处置方案，以保证系统的快速恢复。
（五）、性能指标
具有高效的运行效率，能通过负载均衡、流量操纵、消息缓存等机制，提供大规模、高并发量的交易处置能力，并达到我行要求性能指标。
在不受带宽条件制约的前提下，在下述业务场景中，单个业务的响应时刻（在网络通畅的情形下，从请求发出时刻到结果完成）应在~1秒之内，并非低于对标类似应用系统的响应速度
（六）其它
除上述技术要求外，二维码效劳平台系统建设需要知足行方研发治理、技术标准等相关标准要求；包括但不限于以下技术如报表生成和治理、流程引擎、规那么引擎、文件处置、批处置等技术实现和解决方案，需提供完整的技术实现解决方案说明书。
第二章商务条款
一、交货时刻、地址、效劳水平协议
（一）交货及完工时刻：
具体以项目合同为准。
（二）交货及实施地址：
招标人指定地址。
（三）效劳水平协议：
邀标人提供效劳水平协议最低标准（参见附件效劳水平协议），投标人以此为基础依照邀标人需求和自身能力提出实际许诺的效劳水平协议，最终版本以项目合同为准。
二、测试和验收
（一）测实验收的范围
测实验收的范围为项目实施完毕,终验前最终确认的所有需求。
（二）测实验收的组织
一、测实验收小组由招标人、中标人等有关人员组成，负责对项目建设进行验收。
二、中标人拟定验收方案，编制测试手册，体会收小组确认后，由验收小组负责验收。
验收方案包括测试目的、环境、进程、结果及分析等方面内容。
3、在测实验收进程中，显现严峻缺点或质量问题时，验收小组能够决定暂停所有测试，直至缺点和问题取得纠正。
（三）测试和验收的程序
一、对各子系统进行测实验收。
二、在各子系统验收合格的前提下，对系统进行全面初验。
系统初验合格后进入试运行时期。
3、系统在全行上线运行三个月后，进行验收。
（四）验收测试的评定
测试结果按以下级别评定，并体会收小组签字认可：
·优良：
功能和质量达到预期目的。
·合格：
部份功能和质量不能知足招标人的要求，但中标人（集成商）采取了更正方法，使测试结果达到预期目的。
·不合格：
功能和质量不能知足招标人的要求。
三、售后效劳和支持
效劳和支持的范围：
·系统的安装、部署和调试；
·项目的验收测试；
·项目的数据转换、模拟运行和试运行；
·与系统运行有关的技术问题（含操作系统、数据库、应用系统的整体性能调优等）
·相关技术及业务培训（其中在项目实施前必需组织技术人员进行平台二次开发培训，并提供平台的所有技术文档等）
·相应的售后效劳（含很多于二年免费保护期、免费保护期满后的每一年保护费用等），售后效劳起始时刻为验收后第二天起，终止时刻需为12月31日
·投标人在竞标文件中（报价表下方）详细说明在系统质保期的具体免费效劳内容，系统质保期事后有偿保护的内容、价钱及收取方式，按开发量评估收取，说明每人/月价；
投标人在投标文件中需对以上相关内容中进行论述并作出相应许诺。
四、文档和培训
（一）文档
一、文档范围
包括中标人搜集整理的系统建设中所形成的全数文字记载、录音和照片等，项目验收后由中标人向招标人提供。
二、文档内容
招、投标文件；产品出厂文件；系统整体计划书；系统需求说明书；系统概要、详细设计说明书；系统源码（第三方产品除外）；系统数据库设计说明书；系统利用和操作说明书；系统（含子系统）测试案例、验收方案；系统（含子系统）测试、验收报告；系统建设的详细工程日记；系统运行质量评估报告；系统变更和补充的相关文件、协议、录音、照片等
3、要求
投标人提供的文档要维持完整性和准确性。
所有文档都采纳简体中文（第三方产品出厂文件除外）。
（二）培训
一、培训人员
中标人应付以下人员进行相应的技术培训：
包括但不限于涉及本项目的相关开发人员、运维人员和业务人员等。
二、要求
例如：
对所有的培训，投标人除提供完备的书面教材外，还应提交培训方案和打算。
招标人要求所有的培训在招标人指定地址进行。
五、付款方式
本项目采纳分期付款：
（一）合同生效且乙方人员进场开始实施之日起7个工作日内，甲方向乙方支付合同总额的10%；。
（二）项目安装、调试并投入试运行后7个工作日内,甲方向乙方支付合同总额的50％；
（三）项目验收合格后7个工作日内,甲方向乙方支付合同总额的30％；
（四）免费保护期到期后7个工作日内，甲方对乙方效劳质量作出评判，评判合格后，甲方向乙方支付合同总额的全数10%余款。
六、系统维保费用
免费保护期满后，每一年保护费用不高于合同价10%，且每一年系统升级改造工作量1个人月内不收费。
第三章投标人须
升级会员 