竞争性谈判项目需求
一、项目概况
(一)学校基本情况
南京高等职业学校学校位于南京河西新城区,毗邻奥体中心,学校占地12.5万平方 米,建筑面积10.3万平方米,在校学生5140余人。现有的一卡通系统于2014年建设,由 南京理达软件有限公司开发,使用市民卡钱包交易。使用市民卡Desfire卡为载体,用于食堂、超市、开水、浴室、图书借阅消费、现金充值、门禁管理等多种业务场景。校园 一卡通系统现有服务器位于总机房,卡中心位于食堂一楼负责相关卡务业务办理。硬件 终端为各类消费POS机55台,集中浴室及宿舍内淋浴水控300余台,市民卡自助终端3台。
南京高等职业技术学校的校园卡系统须继续以南京市市民卡公司当前在学校发行的智汇卡为介质,通过市民卡公司开放卡信息接口对接后自动在新校园卡系统建立绑定关系,无需更换师生在用的卡片或二次回收写卡。原市民卡电子钱包可继续在校外城市公共服务消费,新校园卡系统则新建校内电子钱包用于校内消费,系统建成后将形成以实体卡、二维码虚拟卡等多介质融合的新消费模式。即所有的消费场景都能够使用智汇卡、 虚拟卡等进行身份认证和金融支付,且所有交易须均为金融级全在线的统一资金账户模式管理,不得使用小钱包转账的方式进行资金划转消费。对接学校服务银行交通银行, 须实现银行账户自己向校园卡账户圈存充值,自动对账,实现线下支付宝、微信、交行掌银等第三方金融渠道的聚合扫码付。须实现资金流、信息流在系统之间实时传输、交换。依托南京高等职业技术学校的微信门户,为全校师生提供虚拟校园卡领取、消费支付、身份识别、注册、认证、审核、支付、查询、充值等移动端应用等多元化、全方位的智能服务。
校园卡系统的建设要按照学校信息化建设顶层设计总体要求,建设开放、共享、先 进、安全、实用的新一代校园卡系统,实现业务管理、数据管理、介质管理、应用管理 的统一,实现与校园信息化应用的深度融合。
(1)多元支付,走遍校园
本次校园卡系统建设在满足校内支付、认证功能的基础上,融合虚拟卡的移动认证 和移动支付功能以及冗余下一步扩展人脸识别的软硬件条件。通过在线支付技术,提高 结算效率和账户安全。
(2)面向服务,管理便捷
本项目需要从师生用户、运维人员、财务人员、各级领导、业务部门等不同群体的 需求出发,通过开放接口实现与各类系统的数据整合、业务融合,为人、财、物、信息 系统提供开放、友好、便捷的认证服务、金融服务、信息服务。
(3)开放友好,学校自主
校园卡系统应采用开放架构、开放平台、开放产品,为学校提供规范、通用的信息 标准。
(4)安全稳定,技术先进
系统在数据存储、传输方面采用多种技术和策略,确保数据的安全与可靠,满足大 规模并发交易情况下的实时性要求,确保系统在复杂环境下平稳运行。中标人与学校签 订保密协议,确保学校数据不泄露。
(三)建设的原则
1.整体规划
须按照一体化建设理念,建立统一的校园卡金融支付结算平台、统一的身份认证平 台、统一数据共享交换平台及统一的管理应用中心,应采用平台式、模块化的建设方法, 适应与银行系统、学校原有的各类应用系统衔接和系统本身应用规模、应用层次不断扩 大的衔接,将校园卡系统建设成一个一体化、开放式、标准化和用户自我建设扩展的系 统。
2.分步实施
首先建设校园卡核心平台及数据中心,建设新校园卡支付和认证场景,建设新校园 卡食堂、超市、公共浴室消费等系统,并与数据中心实现人员照片数据、身份数据、部 门等基础数据的集成对接。其次,要求软件架构可支撑人脸平台扩展建设,硬件支持人 脸扫码刷卡三合一,待人脸应用建设完毕后可立即开通人脸识别应用。最后要去系统建成TSM平台实现校内图书馆借还书这样的自有应用系统对接,以及后续其他业务系统接入, 实现数据共享互通。
(四)建设总体要求
序号 |
名称 |
项目要求 |
1 |
总体架构 要求 |
校园卡核心平台系统——采用“集中式+分布式”有机统一的融合式技术架构。涉及服务量大、并发需求高的平台,采用微服务体系的分布式实现。 主要管理平台:校园卡管理平台、综合前置平台、聚合支付平台、移动服务平台等,同时移动端业务的后台系统须采用分布式实现。 涉及服务量小、并发需求低的平台,采用集中式实现——主要有:综合业务平台、身份前置平台等。 |
2 |
在线支付要求 |
考虑到当前技术发展趋势及学校实际使用情况,要求校园卡系统采 用在线交易模式,支持汇聚多种支付方式的统一的聚合支付通道, 第三方支付渠道管理能力、第三方支付对接管理能力。针对交易的 每个环节提供高可靠的措施,确保系统及交易数据的安全和可靠。 系统支持海量的20万用户数,支持所有电子账户交易并发处理。支 持在线高并发:TPS:账户交易 >10000 ,查询 & 认证 > 10000。 TCP时间:系统响应时间<=300毫秒。 扫码响应时间<=1s,刷脸认证支付时间<=2s。 |
3 |
系统先进性要求 |
需采用业内先进成熟的技术,包括 BI、Nosql 等设计模式,另外在应用系统架构方面采用前后端分离设计模式、数据中心设计要满足极端故障的设计,系统支持 IPV6。 |
4 |
开放性建设要求 |
系统必须采用开放的架构、开放的平台、开放的产品,提供完备的 文档资料和标准的接口程序,要求学校掌握密钥和算法。向第三方 系统提供标准的 API 接口,校方可方便、快捷的进行应用接入管理和接口授权,实现多部门、多场景接入不同业务的需求。 |
5 |
统一账户要求 |
系统采用“统一账户”设计模式,智汇卡、虚拟卡、人脸识别、其他介质等,使用统一账户金额进行支付,统一管理财务结算、资金对账、多介质权限管控等内容。 |
6 |
密钥管理要求 |
支持国密算法,学校提供规范、通用的信息标准,规范接入开放型终端设备;利用完善的平台接口,为学校构建属于自己的校园卡系统,确保学校对系统的自主权。 |
7 |
系统安全要求 |
系统设计要有完整的安全性设计考虑,从系统密钥管理、数据交换、数据传输、数据存储、都要有完整的安全性考虑。 |
8 |
高可靠性要求 |
系统应针对交易的每个环节提供可靠性的措施,包括虚拟卡、人 脸、终端、网络通讯、应用和数据库的可靠性设计。须确保系统在 脱机状态下的安全交易和在联机状态下的实时性强的要求,以及大 规模并发交易情况下系统的稳定和高效,各个环节应充分考虑系统的可靠性和稳定性,采用冗余、多路、脱机、备件等手段做好可靠性保障,避免业务中断,避免单点故障。要求系统采用金融行业相关标准+信息安全三级等保,支持等保2.0三级的新技术扩展安全 要求。 |
9 |
高可用性要求 |
数据双活设计,脱机交易风控策略,自动恢复机制。 |
10 |
系统扩展性要求 |
系统具有灵活的扩展性,以满足未来用户增加的需求和保护原有投资。 |
11 |
系统功能性要求 |
支持分级管理;管理员可指派二级操作员。 在线支付平台系统采用安全、稳定的Linux、Unix系统搭建平台; 要求提供标准的单点登录接口和虚拟卡数据接口程序。 支持Http、Http(S)、Webservice、等服务协议。 支持系统运行状况扫描,管理员可用WEB登录方式对系统运行状况 进行监控。 |
二、项目需求清单
序号 |
标的名称 |
数量 |
单位 |
采购标的所属行业 |
属性 |
1 |
金融数据中心软件 |
1 |
套 |
软件和信息技术服务业 |
服务 |
2 |
身份数据中心软件 |
1 |
套 |
||
3 |
综合前置机 |
1 |
套 |
货物 |
|
4 |
身份前置服务系统 |
1 |
套 |
服务 |
|
5 |
电子证书管理系统 |
1 |
套 |
||
6 |
移动平台 |
1 |
套 |
||
7 |
运维监控 |
1 |
套 |
||
8 |
TSM平台 |
1 |
套 |
||
9 |
加密读卡器 |
1 |
台 |
服务 |
|
10 |
USB加密卡 |
4 |
套 |
货物 |
|
11 |
交通银行对接开发服务 |
1 |
项 |
服务 |
|
12 |
大数据平台对接开发服务 |
1 |
项 |
||
13 |
图书馆管理系统接口开发 服务 |
1 |
项 |
序号 |
标的名称 |
数量 |
单位 |
采购标的所属行业 |
属性 |
14 |
软网关系统 |
1 |
套 |
|
|
15 |
综合业务系统 |
1 |
套 |
服务 |
|
16 |
读卡器 |
4 |
只 |
货物 |
|
17 |
壁挂式收款机 |
49 |
台 |
||
18 |
不锈钢支架 |
49 |
套 |
||
19 |
卧式收款机 |
6 |
台 |
||
20 |
施工服务 |
1 |
项 |
服务 |
详见采购文件