1.1平台采用当前主流的微服务及J2EE技术架构体系。
1.2平台在交易机制方面,遵照金融行业交易标准,采用“金融在线、联机交易”模式,以数据库中账户金额作为唯一交易基准,卡上无钱包信息,只作为身份验证,保证账务平衡,彻底解决卡库不平问题。
2.操作界面要求
2.1面向普通持卡用户的非硬件依赖功能及服务应当能通过Web方式提供,并支持移动端等,良好兼容当前主流浏览器。
2.2面向普通持卡用户的操作界面应当支持中英文双语,并支持根据用户的具体习惯自主切换。
2.3面向校园卡管理相关业务人员的非硬件依赖功能及服务应当能通过Web方式提供,良好兼容当前主流浏览器。
3.安全性要求
3.1系统总体上应当符合《信息安全技术个人信息安全规范》(GB/T 35273-2020)要求,并根据《教育部等七部门关于加强教育系统数据安全工作的通知》(教科信函〔2021〕20号)要求加强个人信息保护。
3.2系统具有完整的安全性设计方案,安全性设计中至少包含密钥安全、介质安全(卡、码、脸)、终端安全、交易安全、账目安全、传输安全、平台安全等,以确保我校未来在整体系统建设过程中的安全。
4.系统性能要求
4.1高峰状态下,5000用户并发进行校园码消费交易时,交易平均响应时间应≤1秒,TPS≥3000笔/秒。
5.信创可拓展要求
5.1***平台支持未来的信创建设,可兼容国产化运行环境(包括但不限于达梦、人大金仓等)。
6.脱机交易的可持续性要求
6.1***网等极端情况下的业务不中断能力。***网络异常情况下,校园卡消费终端设备可自动切换显示聚合支付二维码,支持师生用微信、支付宝扫码完成消费。
7.系统功能要求
7.1档案管理
(1)具有组织机构、用户管理能力,****中心、“一网通办”自动同步。
(2)全校师生每人一个账户,一个账户对应唯一钱包,可对应多类介质,包含实体卡介质(CPU卡)、二维码、人脸特征。无需回收师生当前持有的校园卡或对卡片进行二次操作,可直接在新系统下正常使用,且使用方式不发生任何变化。
(3)支持档案信息修改,包含但不限于有卡修改、无卡修改功能。
(4)支持档案信息查询,如全部用户档案信息,档案信息包含但不限于姓名、学号、所在单位、性别、证件号、身份证号、国籍、银行卡等主要核心信息。
(5)支持未开户档案信息修改功能,能够对未开户用户的当前信息进行修改。
(6)支持配置管理中可对人员信息进行脱敏设置,至少包括人员编号、姓名、证件号码、银行卡号、手机号码、账户地址、邮箱等字段的脱敏设置。
7.2商户日常管理
支持商户综合管理,为学校财务部门和商户提供商户账户开立与撤销、支付终端配置、账户管理、口令重置、交易查询、结算对账、生成导出静态收款二维码等功能。
7.3设备管理
(1)支持对设备的基础信息及隶属关系进行管理,支持设备绑定身份、商户、产品规则等功能。支持按模板导入,以及批量添加、修改设备参数功能。
(2)支持终端标签管理,系统消息推送时,可根据不同的终端标签分批推送消息。
7.4虚拟卡管理
(1)***平台认证过程中的动态码生成、纸质二维码生成、解析识别。
(2)虚拟卡信息管理核心功能至少包含付款码开通、付款码信息查询、人脸应用注册、人脸应用信息查询等主要功能。
(3)付款码开通:操作员可按照部门、证件号等批量为用户开通虚拟卡功能。具备主副账户、消费限额、是否允许消费、身份识别能力、默认密码等功能。系统支持按照查询条件进行批量开通,以保障开学迎新阶段大批量开通需求。
(4)付款码信息查询:支持通过身份类型、证件号、学工号等查询已经开通付款码信息。支持修改限额、开通/关闭身份识别能力、重置付款码密码、销户、冻结、解冻等功能。
(5)付款码交易:***网工作的消费终端设备完成交易,实时扣除校园卡账户余额;***网工作的消费终端设备完成交易,以加密可信方式本地存储交易流水,待终端恢复联机后上传至系统,须保证交易数据的完整性。
(6)人脸应用注册:支持操作员可按照部门、证件号等批量为用户开通人脸识别功能。
(7)人脸应用信息查询:支持通过身份类型、证件号、学工号等查询已经开通人脸应用信息功能。
(8)人脸识别交易:用户可使用人脸识别方式在联机工作的消费终端设备完成交易,实时扣除校园卡账户余额;在校方授权开通的前提下,也可在脱机工作的消费终端设备完成交易,以加密可信方式本地存储交易流水,待终端恢复联机后上传至系统,须保证交易数据的完整性。
(9)多介质信息查询:支持展示全校师生的基本信息及其所有使用中的介质,可以打开用户详情展示用户的详细信息及每个介质的详细信息(包括介质有效期、介质消费限额等),介质类型包括用户实体卡、虚拟卡、人脸信息等。
7.5卡务管理
(1)支持实现对校园卡账户和各种介质(包括实体卡和虚拟卡)的全生命周期管理,****中心和相关单位管理人员的校园卡管理业务,并支持通过各类用户服务终端向持卡用户提供本人校园卡管理功能。
(2)须提供卡务日常业务管理服务,至少包含开户、现金存款、挂失解挂、有卡换卡、无卡换卡、有卡销户、无卡销户、有卡重置密码,辅助卡务日常管理服务。校园卡账户的开户、冻结、解冻、销户等操作。
(3)支持校园卡二维码和其他介质的启用、停用、支付功能开通和禁用等功能。
(4)与校园人员身份和权限管理功能配合,根据不同类型人员的校园身份状态同步批量进行相应的卡务管理操作。支持根据学生注册情况对注册有效期的管理,支持根据注册有效期相关规则对学生校园卡账户的管理。
(5)支持卡务管理操作根据对校园卡账户的多种条件组合查询结果批量执行。
(6)支持对校园卡用户身份、人员类型、账户信息和不同介质状态等卡务管理数据的综合查询。
(7)集成证卡打印机等制卡设备和服务,支持零散卡片开户打印和补卡打印、批量卡片开户打印和补卡打印,支持人工操作和自助设备操作。支持表格导入形式批量开户打印、批量补卡打印、批量打印、单独开户打印等。
(8)支持通过智能读卡器支持通过读取卡片获取人员信息,无须手动输入相关信息自动完成人员发卡。
(9)支持通过BS/CS方式进行访问系统进行用户卡片的制作等,保障系统管理及维护的便捷性和访问的时效性。
(10)用户补卡、换卡时,支持管理员一键完成用户卡挂失、补卡、卡片打印等业务流程,无需用户自行挂失。
7.6财务清算
具备生成满足系统交易结算需求的财务清算报表的能力,根据清算业务模式的需要,支持卡务报表、商户报表、操作报表、自助存款报表、系统报表、会计科目报表、补助报表、科目汇总表、卡费报表、商户管理费报表等报表功能。具备数据防篡改功能。
7.7支付结算
(1)通过集成人脸识别、扫码、刷卡功能的三合一校园卡消费终端设备,支持刷卡、扫码、人脸核验消费支付功能。
(2)消***网工作模式,交易数据实时上传至系统;***网工作模式,***网后交易数据及时上传至系统。***网工作模式须有保障数据完整性和一致性的有效机制。
(3)***网、***网(Wifi)***网方式,***网自动进行模式切换,***网,***网***网连接。
(4)支持持卡人被扫(消费终端设备扫用户码),支持密码(口令)验证等额外的身份验证,允许用户自行设置一定额度范围的免密支付。
(5)支持对单个支付终端的可消费人员身份类型限制,实现对单个校园卡账户的单次、单日支付额度限制,支持按额度进行小额免密支付、验证交易密码支付和禁止支付的设置。
(6)校园卡账户正常情况下支持在线(联机)交易模式,账户唯一且余额和交易信息均须以信息系统数据库记录为准(不得采用卡、库多钱包余额同步机制的过渡模式),支持采取支付终端或实体卡内等其他辅助记录措施用于对账。
7.8后台管理
支持包含但不限于权限管理、部门管理、操作员身份绑定、系统定时任务管理、数据字典设置、信息查询、参数设置等功能。
7.9信用管理
系统支持对校园卡系统脱机交易时使用信用服务管理的能力,包含但不限于信用额度设置、信用额度调整、风险预警的具体功能。支持根据不同的身份类别为用户设置不同的信用额度。支持给终端设备分组设置不同的信用额度。
7.10产品管理
(1)满足我校特殊餐饮或支付服务环境需求,支持配置对应产品规则功能,如打折优惠、管理费、补贴、消费规则、专款专用等特殊支付服务。支持学校操作管理人员灵活设定优惠时间段(不限次、限次),人员类别,优惠的餐厅,以及优惠政策。
(2)系统支持对校园卡系统产品提供管理服务的能力,包含但不限于产品管理、用户绑定产品、绑定商户、添加明细等服务。
(3)支持为不同类型的用户批量开通专款专用钱包,支持专款专用钱包的消费规则配置(包括专款清零日期、最低/最高消费额、允许的消费介质、每日/月最大消费次数等消费规则)。
(4)支持专款专用钱包绑定用户。支持根据用户的属性进行绑定,包括用户所属校区、用户身份类别、用户学工号、用户所在部门、用户所属民族、用户标签等属性批量绑定。支持专款专用钱包绑定校园商户。支持设置指定用户在指定商户、指定终端上使用该钱包消费。
7.11多身份管理
(1)系统须支持“一用户多身份”的管理模式。须提供如下两种方式:
一用户多身份,使用同一个校园码,共用一套资金结算账户;
一用户多身份,不同身份有不同校园码,用户可自主切换,各身份结算账户独立、门禁权限独立、身份权限独立。
(2)系统须限制多身份用户仅允许办理一张实体卡,多身份用户在使用不同身份申领多张实体卡时,系统须进行提示或限制,该功能须同时适用于人工办卡、自助补卡两种场景。
7.12定制开发
针对曾经定制开发的功能,***平台进行重新定制开发,包括但不限于毕业生余额退款/捐赠、补助发放包括但不限于补助审核,补助下发,补助撤销,补助统计以及补助的生效日期等功能。
(二)优化移动服务子系统
1.移动用户端
1.1移动应用服务须支持校园卡绑定/解绑、电子校园卡(虚拟卡)信息展示、扫一扫/校园码展示、充值、捡卡登记/丢卡查询(招领服务)、校园卡挂失、交易记录查询、补助查询、限额/密码修改、手机用水、门禁应用、证件照采集等。
1.2首页个人信息区支持脱敏显示,包括用户照片、学工号、姓名、余额等信息。
1.3首页须展示高频应用(扫一扫和校园码)快捷图标和常用应用图标矩阵。
1.4首页常用应用:支持个人自定义首页展示的日常应用。
1.5校园码支持离线码模式,可在后台启用/停用,***网时正常使用。
1.6交易记录:以订单视角展示消费过程数据,支持按照月份查询交易记录,按照产生的时间倒序排列,记录类型包括充值、消费、补助和转账等。支持查看交易订单明细。
1.7余额明细查询:以余额视角展示消费过程数据,支持查看每笔交易后的余额。
1.8余额明细中可展示脱机情况下的交易记录。***网后上传,记录中须展示“交易发生时间”和“记录创建时间”。
1.9消息提醒:支持欠费提醒、充值提醒和余额提醒等消息通知。
1.10支持用户查阅“常见问题”,进行“问题反馈”。增设办事指南,支持移动端嵌入学****广场中校园卡相关的智能体。
1.11支持师生设置电子校园卡的皮肤样式,提供不少于10种可选版样式,整体风格与电子校园默认样式保持基本一致。
2.移动商户端
2.1支持通过后台管理软件内设置的商户账户完成身份认证。由商户自助输入商户号和商户密码完成移动应用内的身份绑定。
2.2移动应用服务须包括商户账户绑定/解绑、首页概览、****中心、修改密码、终端交易记录、商户报表、子商户报表等。
2.3首页概览支持展示当日营收、昨日营收、近七日营收、可选起止时间营收的总额和交易笔数,可以按照交易总额和交易笔数两个维度通过可视化的方式展示不同时间范围的营收趋势。
2.4支持商户通过移动端查询详细的餐次日/周/月报和餐次自定义汇总报表查询。
2.5支持系统显示当天商户下属终端的所有交易记录。支持按自然日或自定义时间段进行筛选;支持按全部终端或指定终端进行筛选。
2.6支持商户报表展示近6个月的每月交易笔数与交易金额汇总数据,支持展开显示每个月的每日汇总数据,支持按自然月或自定义时间段查询每日汇总数据。
2.7支持查询展示子商户的月汇总统计、日汇总统计和自定义时间段的日汇总统计。
3.后台管理端
3.1包含支撑前端功能实现的基础配置和参数管理功能,包括应用菜单管理、页面提示管理、宿主管理、充值设置、皮肤设置、校园卡绑定设置、用户协议管理、虚拟卡卡样式设置、***网缴费设置、用户认证管理、消息发布等,支持以上功能由校内管理人员自行设定。
3.2应用菜单管理,支持后台配置前台可见的应用功能。
3.3支持页面信息提示功能。支持在不同宿主中,对不同应用功能添加页面信息提示,提示内容可由管理人员自定义进行编辑。
3.4管理员支持在后台设置宿主接入地址等配置参数。
3.5充值设置:支持设置三方充值方式和预设充值金额。
3.6在校园卡绑定功能中,支持针对在校师生、商户、商户管理员不同身份人群提供认证方式的设置管理。
3.7支持根据实际需求设计虚拟校园卡版面样式,为不同身份的用户,绑定不同样式的虚拟卡版面。卡样中可设置卡面背景、学校logo、学校名称、照片、身份信息等内容。
3.8支持管理人员在后台对《用户协议》内容进行管理。支持针对不同角色展示不同的用户协议内容。
4.家属卡应用
4.1支持教职工自助申请“家属卡”并与之绑定,校园卡后台可设置家属卡使用权限、使用介质、是否共享教职工账户余额或独立账户等。
4.2支持教职工支持自主办理所申请家属卡的挂失、延期、解挂失、充值等业务。
4.3家属卡解绑:系统应支持解绑操作,解绑前家属需将其账户余额清零。支持已解绑家属卡批量销户。
5.学生画像
5.1支持提供学生日常画像展示包括本月消费总金额、充值总金额、充值高峰期、消费趋势、消费场所分布、单笔消费排行、交易概览等,支持消费对比分析餐别分布图,单笔最高消费窗口及食物,美食打卡排行榜,早餐、午餐、夜宵的消费频率,个人用餐喜好、校园卡充值和支付习惯等。
5.2支持结合校园卡消费等数据,制定学生生日祝福画报,生日当天给学生推送图形化的生日祝福。
5.3支持自动实现在学生生日当天发放生日券,可使用生日券就餐,生日当天可通过消息提醒机制提供生日祝福语和一年消费画报。
6.优化移动端毕业生余额退款/捐赠等功能。
(三)优化支付服务子系统
1.***平台支持须为系统提供收单机构管理、支付方式管理、支付渠道管理、支付参数设置、支付路由设置、订单管理、自动对账、报表管理等服务,支持承载线上线下支付业务。务系统
2.支持为各类角色管理的登录菜单及按钮菜单管理服务,支持自定义各角色的权限。
3.支持开通三方支付后定义不同的收单机构。线上支付,可定义不同的支付项目设置不同的收单机构;线下支付,可定义不同的终端归属不同的收单机构,从而实现支付业务自动清算。
4.支持设置支付方式,可注册并管理各类三方支付接口信息,至少包括微信、支付宝等。
5.支持支付渠道管理,支付渠道是支付方式的组合。可将若干支付方式组合为一种支付渠道,以便灵活配置给不同的支付业务。
6.支持订单管理,可通过订单号、支付方式、开始时间、结束时间等组合条件查询支付的交易明细情况。
7.支持自动对账,可查询对账结果,可分别查看对账成功和对账异常的明细数据,并支持导出为文件。
(四)优化运维监控子系统
1.监控设置:支持对“校园卡”各类(消费类、身份识别类、自助服务)终端机、各类服务器(数据库服务器、业务服务器)、网络信息点、部署的软件服务进行有效的状态监控及预警。包括但不限于支持消费终端设备的软件版本、黑名单版本、在线时长等,以及自助服务终端的卡片异常、钱箱异常预警、卡片数量等监测提醒(***平台)。将这些运行状态集中投放在大屏设备上,管理人员可以直观获悉“校园卡”业务运行状况。
2.系统设置:支持为运维服务提供系统设置服务功能,包含但不限于操作员管理、角色管理、告警类别管理服务、发送类型管理、参数管理等服务,满足运维管理日常参数需要。
3.大屏展示:支持自定义大屏显示内容,支持按照时间段查询和统计设备运行情况,数据回溯,支持历史对比、图表化,支持单独拉出一个屏幕,协助管理员快速定位故障。
4.系统须为运维服务提供运维监控大屏,大屏展示服务,展示内容可学校运维需要自行调整内容,支持以表盘模式展示如曲线图、图表、饼状图、柱状图等。
5.支持设定推送管理员或管理员组,支持短信、邮件或根据要求与第三方消息系统对接,及时发送消息提醒来保障运维工作的时效性;支持对维修事项进行登记,系统中所产生的各类运维记录将作为对维护人员的考核依据。
6.支持对容器应用的管理,包括监控应用版本、运行状态、更新时间、CPU内存使用情况、运行的副本数等,并可以对应用进行一键操作,包括启动、停用、升级、回滚、查看日志等功能。
7.支持界面的操作来新建和执行各类操作指令,如网络测速、重启工作节点等。
(五)优化综合消费子系统
1.支持金额、定额、快捷菜单等扣费模式。
2.支持指定卡类别和终端定向消费。
3.支持自定义设置餐次及时间段。
4.支持根据身份类别进行优惠打折;支持根据商户或终端进行优惠打折。
5.支持根据商户类型进行管理费用收取。
6.支持设置终端机最大脱机时间,超时禁止消费,联网后自动恢复。
7.支持设置餐次消费限额和日消费限额,超额须密码验证。
8.商户通过消费终端设备支持查询营业收入等账目信息。
(六)优化密钥管理子系统
1.支持采用硬件加/解密技术,适配硬件加密机。
2.支持发行PSAM卡、发行CPU用户卡。
3.支持各类卡片回收管理。
4.支持运行日志和操作日志。
5.要求投标人拥有完全自主知识产权,提供计算机软件著作权登记证书。
6.加/解密所用商密产品须符合国家标准。
(七)优化自助补卡子系统
1.支持用户通过自助服务终端实现7×24小时自助服务。包括但不限于自助挂失、补卡(缴补卡费)、账户查询、流水查询、遗失卡查询、自助挂失解挂、修改密码等功能。支持一次性完成新卡发卡和卡面打印。
2.支持使用校园卡账户余额等渠道缴纳补卡费。
3.招领查询:支持查询用户丢失的卡片是否已被捡到。
4.后台首页管理:首页支持展示各设备运行状态统计预览、业务产生次数、设备实况监控、预警信息等数据概览。
5.显示管理:支持自定义首页显示内容,包括首页轮播图、学校Logo、服务热线等。支持自定义多套首页模板,不同模板可绑定不同设备。
6.预警管理:终端运行异常支持预警,预警信息包括但不限于卡片数量异常、打印机状态异常、色带不足、读卡器异常等。
7.运维管理:当设备出现故障等情况时,后台支持设置补卡机进入运维模式,防止用户误操作。
8.监控管理:支持后台实时监控各终端的运行状态。
9.****中心:支持后台自定义前屏所显示的提示内容。
10.支持设置不同菜单操作权限的身份认证方式。
(八)实现第三方对接
1.第三方读卡及扣款接口:升级后的校园卡系统支持为第三方系统提供读卡、扣款接口。
2.银行圈存接口:支持按学校要求接入准入的银行充值渠道。
3.支付渠道对接:支持按学校要求接入准入的支付渠道。
4.水控系统对接:支持对接学校现有水控设备,要求系统升级后:手机消费时支持直接扣微信钱包或支付宝的费用,用户可预充值,也可以不预充值。
5.***平台对接:升级***平台,完成用户各类数据的共享和同步业务。
6.须与图书馆借还书系统对接。
7.须与超市收银系统对接。
8.支持餐厅消费对接:包括但不限于自主称量等。
9.支持与校内各个门禁系统对接。
10.****广场平台开发校园卡业务智能体,提供大模型接口服务,实现校园卡相关业务自动问答办理(包括但不限于充值、挂失、修改密码、查询消费画像等),以及基础的消费数据问答查询。
11.与第三方对接,支持师生在校内餐厅通过手机NFC进行消费,以及在校园周界及学生社区门禁、图书馆等场所,使用手机NFC进行身份核验。
12.支持与第三方系统接口的正常对接与运行,涵盖因第三方系统升级或增加所产生的接口对接工作(教务处、迎新离校系统、公寓管理系统等)。
(九)新增能力开放子系统
1.接入系统管理:具有对接入系统的管理功能的能力,支持实时查看接入系统各类信息,包含但不限于:接入者账号、接入者名称、接入者邮箱等信息,便于接入系统管理,基于安全考虑,支持设置token有效期、选择签名方式和加密方式(须支持国密算法)、IP白名单等信息。
2.接口管理:***平台内封装的接口服务,包含但不限于查询接口列表、添加接口、接口编辑等,为了便于系统管理员接口管理维护,支持列表至少显示接口名称、接口简介、接口URL、接口入参示例等信息。管理者支持使用原有服务接口快速创建同类接口,支持控制同样业务接口入参与出参的字段不同。
3.接口授权:支持为三方接入系统授权接口的能力,包含但不限于查询接口、接口授权,为接入系统授权接口,让接入系统具有调用接口的能力。
4.开发者门户:第三方接入系统支持自行登录系统,申请所需接口,学校管理人员完成接口使用权限的审批授权。支持查询调用数据(今日使用最多接口、今日最活跃接口、接口耗时等)。
5.日志查询:第三方接入系统所有的操作及接口调用,均产生系统日志,支持管理人员查询、追溯。
(十)智能水控管理子系统
1.具备设备统一管理功能,支持将水控器统一管理,实现对淋浴、热水、直饮水的计量、管控、统计等功能。可查看设备运行的状态,如联机脱机状态、使用状态、开关阀状态、报警状态、信号强度等,***平台对任意设备和批量设备进行远程开关阀控制。
2.消费方式:支持刷卡、手机扫码、输设备号、预约消费、用水码等多种消费方式,并在系统软件中统一进行管理。移动支付支持微信/支付宝钱包直扣,用户可预充值,也可以不预充值。
3.***平台为用户发放补助,支持按岗位为各类账户快速下发补助,也可创建补助计划下发补助。补助计划可设置是否清零账户余额,补助计划支持单次和多次发放,支持设置指定日期自动发放补助。
4.远程升级:***平台对任意或批量水控设备程序进行升级,升级任务支持设置有效期和执行时间段,支持静默升级和终端提示升级方式,支持设置同时升级设备个数、是否强制升级。升级过程中,平台实时更新显示设备升级进度条。
5.提供报表和查询功能:支持按部门、区域、时间等维度统计用户消费、充值及商户收入日报、月报、区间报表以及支付记录、充值记录等,支持报表导出和打印功能。
注:以上支持均表示项目交付时必须实现的相关功能。
二、信息系统集成要求1.系统升级要求(1)本项***平台进行升级优化,***平台的密钥体系,查询密码、消费密码不作变动。***平台、水控系统、NFC校园卡、终端消费机等软硬件设备需符合现有密钥交易体系。
(2)***平台中的历史操作和交易数据。包括但不限于科目汇总表、科目汇总报表、卡费汇总表、补助信息统计、商户汇总表等财务报表。
(3)***平台下发行的实体校园卡,需***平台下仍可作为正常的身份认证和消费介质,***网的情况下,也可正常使用。
(4)本项目是交钥匙项目,***平台可以正常使用的相关PSAM卡,加密机等辅材由中标人统一提供。
2.系统集成要求
(1)统一身份认证集成。对面向师生服务的信息系统(包括但不限于校园卡移动端应用、Web端服务大厅等)实现与学校统一身份系统集成。对统一身份认证的用户的功能授权、业务操作权限授权工作仍然在业务系统中内部完成。
(2)“一网通办”服务门户集成。对面向师生服务的信息系统实现与“一网通办”服务门户集成,移动端与学校企业号、小程序进行融合,通过统一身份认证,实现单点登录,一站式统一办理。在质量保证期内免费按学校要求进行修改。
(3)校务数据集成。信息系统产生的业务数据(数据资源目录为准)应通过API接口或数据库方式(开放数据库权限)****中心,提供数据字典,包括数据逻辑关系图,字段说明等。系统所需的人员、组织机构、教学科研等数据,****中心提供共享数据,***平台申请,各系统不再单独收集和维护。在质量保证期/服务期内免费按学校要求进行修改。
3.数据标准要求
(1)信息系统涉及的字典表数据公共部分应以《陕西师范大学校务数据代码标准》为准,未在该标准中界定的字典,应符合相应国标和行标,个性化部分应符合学校业务发展需要。
(2)生物特征对接要求。本项目中的人脸生物特征信息须***平台(下称“校级生物特征库”),不得单独采集师生的人脸信息(可保留采集入口)。校级生物特征库为本项目中的应用提供人脸数据源服务,保障人脸数据安全。
4.网络安全要求
(1)***平台的源代码审计、渗透测试报告,平台各子系统需配置SSL证书,使用SSL加密传输。上线前,***平台的漏洞扫描报告,并配合学校进行安全检查(主要包括服务器主机扫描、web应用扫描等)。运行后供应商须持续完善系统安全防护措施,定期运维,学校将进行不定期监督检查,供应商需配合学校检查并根据要求及时进行整改。
(2)用户安全管控,信息系统管理如有独立用户登录入口,需使用复杂密码,具有防暴力破解方案,并对访问源地址进行限制。
(3)信息系统采集、使用、产生的各类数据,属于学校资产,未经学校同意,不得公开、转让、向第三方提供。信息系统可能包含的敏感、涉密数据,需有技术方案及措施,确保数据安全。
(4)信息系统因程序代码、框架技术以及使用的中间件而产生的漏洞或bug等程序错误,厂商应终身负责维护升级。
5.设备接口开放。项目中的设备需对外提供标准接口调用。***平台的接入纳管能力,通过API、SDK等主流对接方式,***平台的控制纳管,包括但不限于数据下发、进出权限的下发、进出数据的采集及查询、设备运维等功能。
三、其他要求
1.驻场运维要求。项目验收完成后,需提供2人、6年的驻场运维服务。驻场人员须保证工作日在岗,每天8小时,可轮换但必须保证1人在岗。驻场运维工作不允许合同转包,运维***平台的系统及配置,具有软件系统维护、硬件设备维护的工作技能,熟悉本项目系统代码及相关硬件的管理维护。运维工作期间,应完全服从学校考勤及工作任务安排,如工作服务质量达不到学校要求,学校可要求中标人重新安排人员驻场服务,对于造成损失巨大的情况学校保留法律追偿权利。
2.质量保证与售后要求。软件系统提供大版本内终身免费升级服务,质保期后,运维服务费用不超过原合同的。
3.双方确认,本项目实施过程中所产生的全部工作成果(包括但不限于技术方案、设计图纸、文档资料及由此衍生的任何发明创造等)的知识产权,自创作完成之日起即归属于陕西师范大学单独所有。
微信公众号(订阅通知)
本公告地址:https://www.anfangzb.com/view/16144/QCcuz5cBtavodC9fw7OS.html
微信在线客服