招标
第十七届“挑战杯”赛事服务管理平台技术开发服务(ZBZXFB2021013)采购公告
金额
67.5万元
项目地址
四川省
发布时间
2021/07/20
公告摘要
项目编号zbzxfb2021013
预算金额67.5万元
招标公司-
招标联系人-
标书截止时间-
投标截止时间-
公告正文
项目名称:第十七届“挑战杯”赛事服务管理平台技术开发服务
项目编号:ZBZXFB2021013
采购单位:四川大学
联系人: 中标后在我参与的项目中查看
联系电话:中标后在我参与的项目中查看
签约时间要求:成交后5个工作日内
到货时间要求:
预算总价:675000
收货地址:
供应商资质要求:符合《政府采购法》第二十二条规定的供应商基本条件
采购商品:第十七届“挑战杯”赛事服务管理平台技术开发服务
采购数量:1
计量单位:项
预算单价:675000
技术参数及配置要求:1. 系统说明
1.1定制开发第十七届“挑战杯”赛事服务管理平台,实现赛前及赛事期间各种信息收集、展示、查询和服务功能。确保系统具有高度灵活性、敏捷性和扩展性,可随时根据实际需求做出调整,并具有良好的稳定性和用户使用体验。
★1.2“挑战杯”赛事服务管理平台须建立统一的管理平台,提供统一的管理界面,对赛事所涵盖的各环节进行统一管理及监测预警;建立赛事相关人员数据库,实现人员的统一管理、分组管理。实现用户管理、角色管理、权限管理、组织机构管理、消息管理、住宿管理、参赛人员报到管理、预约管理、赛事在线、在线评分等功能;同时实现与其他系统及硬件平台的对接,实现数据的统一管理与交互,为大赛提供一流的信息化服务。
★1.3“挑战杯”赛事服务管理平台须保障7×24小时不间断工作,确保数据的一致性、完整性、准确性。系统参数可配置;各项服务间为松耦合架构,独立运行,互不影响;预留拓展接口。“挑战杯”赛事服务管理平台须防范注入漏洞攻击,参数使用严格的过滤函数进行过滤,关键服务请求内容加密,能够确保系统的数据安全性。
2. 开发与功能需求
2.1 移动信息服务平台
★2.1.1开发移动端信息服务展示平台,并与微信公众号对接。
★2.1.2实现与市面上主流手机品牌型号进行完美适配,避免因适配问题造成的用户体验缺失。
★2.1.3用户须采用验证方式登录,如:手机短信验证、人脸识别验证等。
★2.1.4平台所有信息均需登录后可见,如部分信息可公开展示,管理员拥有权限对展示材料进行权限管理。
★2.1.5平台中各应用可根据权限或需求定向投送。如某个应用仅对某种身份人员开放,则其余人员不可见。
★2.1.6平台需实现动态电子二维码确定身份功能,便于校内通行。
2.2 消息平台
★2.2.1平台开发消息功能模块,其组织架构可以自定义分组,一个ID可在多个分组中存在,消息发送可按分组、按个人等精准发送。
★2.2.2平台消息推送、短信推送、邮件信息等消息,管理员同步可选。
★2.2.3ID号支持自编号(如学工号)、身份证号、手机号、邮箱号等多种模式。
★2.2.4消息中心拥有多种管理权限、多级管理权限、多重管理权限,实现对参赛人员进行精准消息管理。所有管理员都可以拥有消息发送权限,消息可由管理员按下属成员分组、按个人精准发送给下属成员。如:志愿者管理员可通过消息中心,向所有志愿者发送消息,可精准到向某一人或多人发送消息。如省队管理员可以向下属省份所有人员发送消息,可以向下属各高校管理员发送消息,可精准到向下属某一人或多人发送消息。
★2.2.5平台系统有独立的消息中心,平台消息集中显示(如赛事消息模块),有已读和未读标记,未读消息有显著提醒等,方便查询消息。
2.3 数据中心
★2.3.1用户到校前,需激活个人账号。
★2.3.2用户激活帐号时,须完成:账号激活、个人信息完善、会务费缴纳、住宿登记、交通信息填报等整个流程,则系统默认该账号已成功完成激活,可实现系统内部信息的查看,否则,系统默认该帐号未完成激活,系统内所有信息均无查看权限。该部分信息由管理员设置的开放信息为准,除管理员开放查看信息外,其余信息均无法查看。
★2.3.3平台账号激活须支持三种模式,赛事组根据实际情况任选。
1)与第三方报名系统进行技术对接,获取基础数据,用户通过手机号作为账号进行激活;
2)开放注册,支持多种验证模式,设定截止日期,截止后数据上报组委会审核,审核通过的为有效账号,可激活,未通过的为无效账号,无法激活;
3)设置各单位管理员,由各单位管理员负责本单位内所有参会人员的信息预置,设置截止日期,到期后不可修改,预置成功用户可进行账号激活。须向各单位管理员提供在线查阅的操作手册和可下载的数据模板,便于其学习使用和批量导入数据。
★2.3.4用户激活账号时,须完善个人信息。个人信息内容包含但不限于:姓名、性别、学校(单位)、手机号、身份证号(护照号)、人员类别、身份等约20项左右信息。
★2.3.5系统须具有信息填写智能纠错功能,如:手机号码、身份证号码等的基本规则检测,文字与数字的检测,信息查重检测等。
★2.3.6以上个人信息可由授权管理员代填。
★2.3.7对各单位授权管理员开放独立的管理权限,权限设置可由系统管理员批量配置,各单位授权管理员可通过平台对下属参赛人员进行跟进管理等,如通过平台查看下属参赛人员住宿信息、交通信息等。
★2.3.8系统须具有多级管理权限,超级管理员可设置任一级管理员并授权其相应管理权限等。管理权限设置可精准至字节。可实现单个或多个二级权限批量下发,可实现多重分组,各个分组独立管理,人员分组可交叉重叠且不受分组影响。上级管理员可下发下一级权限,并可批量设置下一级管理权限。
★2.3.9参赛人员可通过系统查看自己的参赛时间、参赛场地、出入口、注意事项等相关参赛信息。
2.4 参会报到模块
★2.4.1住宿预定:用户选择是否需要安排住宿。选择需要安排住宿的用户在线自助选择宾馆及房型,系统自动核算住宿费用,用户通过学校移动支付平台自助缴费。缴费通道有会务费(交财务处)和住宿费(会务公司)。住宿信息在缴费完成前默认预定未完成,可随时修改;住宿费缴纳成功后,则已完成住宿预定,不能修改。
★2.4.2会务费和住宿费可由授权管理员代缴,并由平台统一出具电子发票或纸质发票。
★2.4.3系统对各宾馆开放后台管理权限,宾馆可随时查看自己宾馆的预订情况,随时可以调整房间数量,但房间数量不可低于限定数量,可向上增加,各宾馆管理员不可修改房间价格。宾馆管理员能从后台看到自己宾馆最终的预订明细,用户入住宾馆时,宾馆管理员可以从系统自动核销。
★2.4.4支持将报名成功参会人员数据在宾馆间转移,便于参会人员入住宾馆的调整。
★2.4.5接站服务:该功能模块点击进入后,出现温馨提示,用户选择是否需要接站服务。需要接站的用户填写:抵蓉时间、航班/车次/车牌号、抵达站点等交通信息。以上交通信息可由授权管理员批量代填。该部分信息可随时进行修改。交通信息填报和修改可设置截至时间,到期后不可修改交通休息和接站信息。
★2.4.6系统管理员可从后台导出需接站人员明细信息,为接站工作组提供数据支持。
★2.4.7参会人员到达后,须扫码签到,后台可随时查看、统计抵达人员数据及明细。
★2.4.8系统部分信息须扫码签到后才打开访问权限。管理员可进行单个设置或批量设置。
2.5 预约中心
★2.5.1车辆进校预约:定制开发前端扫码或在赛事平台点击对应图标进入车辆临时进出校园预约系统,可灵活设置审核权限,并将数据传输给学校车辆管理系统,预约成功后返回消息提醒;
★2.5.2用车预约:授权人员扫二维码或在赛事平台点击图标进入用车预约系统,填入相应信息,实现在线用车预约。后台管理员可实时查看约车统计信息,并具有灵活的排序功能,设置一键智能排序,如:同时段同目的地用车需求;同时段同出发地用车需求等多种排序模式,便于交通组进行调度安排车辆,调度安排成功后可将车辆信息和驾驶员信息发送给约车人;该约车权限仅对部分人员开放,其余人员在平台中不可见该功能。
★2.5.3工作餐预订:
1)按需求在相应单位或工作组设置订餐管理员,由订餐管理员线上自助订餐,后台生成订餐确认单,餐饮保障单位送餐时该确认单需由订餐管理员或订餐管理员指定的收货人签字确认。一个订单内允许填写多个送餐地址及相应数量;
2)一次性超过50份的订餐需求,系统需要在餐饮保障单位设置节点,由节点人工安排给多个食堂制作并根据用户填写的多个地址进行配送。
3)管理员及饮食中心均可查询权限内的历史订单。订餐确认单一键打印,可重复打印。
4)订单完成后,餐饮保障单位可从后台查询、统计、打印各用餐单位的用餐统计数据和明细清单,对账完成后,用餐单位通过对公转账方式支付餐费。
2.6 赛事新闻通告中心
★2.6.1实现会务通知公告、赛事新闻、食宿交通信息、日程信息、路线信息等的发布、呈现。该权限可由管理员下发给多个人进行管理。
2.7 会务资料
★2.7.1制作电子版会务资料,该资料仅对账号激活用户开放。且会务资料仅能在线查看,不能下载。
2.8 赛事留影
★2.8.1实现赛事留影功能。赛事期间由专业的摄影师现场拍照并实时传输到留影墙,用户可通过信息验证或人脸识别自动匹配查找与自己相关的照片,进行下载。
2.9 作品展示
★2.9.1参赛作品(800-1000)件线上展示,包括作品介绍、图片展示、队伍信息等。
2.10 评分系统
★2.10.1定制开发在线评分系统:实现队伍信息、作品信息、复赛成绩、评委信息等前期数据初始化;通过参数配置实现参赛队伍、评审专家在大分类中自动随机分组,后台设置评分机制,系统根据评分规则自动计算各参赛队成绩。计算完成的成绩进入待发布队列,由工作人员审核后,再行确认发布或驳回,成绩一经发布不可更改,并同步在展示大屏显示。(注:在线评分系统具体流程需求以最终组委会确定方案为准,若与本需求不一致,则以组委会意见为准。)
★2.10.2评审专家账号预置:由管理员批量导入专家组数据信息,包含:专家姓名、联系电话、单位、专业方向、身份等重要信息。
★2.10.3专家库管理模块:管理员可通过系统后台批量导入专家数据,也可批量删除专家数据,可逐一添加,也可逐一删除。可批量增加、修改专家属性、可逐一增加、修改专家属性。如批量导入专家邮箱地址等。管理员可按条件查询专家数据、批量导出专家数据。所有操作均须保留在日志报表中。
★2.10.4组别管理模块:管理员可通过系统后台批量导入组别的分类信息,包括该分组的名称、属性,所需专家专业方向、职称等专家组成员数量和结构。
★2.10.5考场管理模块:管理员可通过系统批量导入考场信息,如:校区、楼栋、房间号等。
★2.10.6签到/报到管理模块:专家按时到场后扫码签到,系统后台可随时查看签到专家统计数量信息及名单信息。
★2.10.7专家分组管理模块:管理员可根据各个组别的分组属性,从已按时到场签到的专家中按照各分组专家专业方向要求,系统自动分配专家,管理员拥有手动调整专家的权限。管理员可设置备用专家数量及专业信息,系统自动选择,管理员也可手动选择。管理员可手动导入此次评审的专家分配表,设置数据开放时间,在数据开放时间前,扫码提示:请于****年**月**日**点前扫码查看您所参加的评审相关信息。直至数据开始时间到点后,系统自动给专家推送消息,专家点击察看自己对应评审信息,包括:专家姓名、单位、专业方向、联系方式等基础信息和专家自己参与评审的组别名称、地址、专家身份等信息。专家只可见自己的信息。专家根据时间和地址进入相应会场领取评审设备。
★2.10.8评委在线打分:评审专家所用评分设备根据安排排序,显示参赛队伍列表,并根据当前比赛进度自动显示当前参赛队伍的评分界面。评审专家通过评审设备上面的九宫格数字键为各参赛队伍评分。同时在统一的监控室设置后台管理账号,其仅拥有获取评审进度显示功能。如:正在评审作品名称、评委5名,评审进度4/5等。待进度显示为5/5时,该管理员可依次点击计算成绩和发布成绩按钮。点击计算成绩,则成绩自动保存在系统中,在未点击发布成绩前,均可发还评审专家进行再次核对调整。点击发布成绩,则该参赛队成绩锁定不可修改,并同步上传至对接好的专用展示大屏进行公开发布。
★2.10.9成绩计算:每个作品成绩按照比赛规定算法自动计算,同时可按组汇总、按大类汇总,并可按照组委会要求实现全过程在线调整。直至确认并发布后不可修改,并同步公开展示。
★2.10.10系统需支持多种分数计算方法,如:去掉一个最高分和一个最低分,再计算平均分;不同身份评委打分权重不同,可根据评分系统后台设置权重系数,再进行计算得分等多种计算方法计算各参赛队最终得分。最终计算规则以组委会决议为准。
★2.10.11每个评分环节可回溯,以便回应质疑。
★2.10.12评审专家授权须具备白名单机制包括但不局限于IP、MAC、专家ID等,确保赛事评分公平、公正、安全。
2.11 大屏成绩展示系统
★2.11.1部署相应展示系统或平台,将赛事信息、比赛动态、评分结果实时在大屏幕上进行展示,需定制开发展示页面。
★2.11.2需能同时展示多个赛场的成绩。按照新出成绩先后顺序轮番展示。
2.12 系统设计、美工、UI
★2.12.1移动信息平台、消息平台、赛事新闻通告中心的页面UI设计及制作。界面设计简洁清爽,贴合大赛主题,凸显川大元素。
★2.12.2要求前期页面设计不少于5个版本提供给赛事组选择,如不符合要求,无条件修改,直至赛事组评定通过为止。
2.13 安全设计
★2.13.1通过安全设计防止截屏、录屏等。如用户登录后页面具有全页面水印功能,水印内容为当前登录人员姓名和当前日期。
2.14 驻场服务
★2.14.1合同签订到赛事结束期间,至少派一名技术工程师到学校驻场服务。该人员须一直与赛事组老师一起,随时了解赛事最新情况,对赛事服务平台做深度调研,并提出合理化建议。将最新设计要求及时反馈给开发团队,能做到及时响应需求的修改。
2.15 系统使用培训
★2.15.1现场根据功能模块具体场景,组织相应志愿者进行系统使用培训,预计10场左右。
3. 技术要求
3.1 架构要求
★系统所有服务需满足微服务架构的特点,需支持消息队列机制,服务端需支持windows和linux多平台布署,需要支持分布式服务部署。
3.2 系统对接要求
1)▲系统对外提供的程序调用接口符合RESTful及OAuth2.0规范。
2)▲报价须包含匹配第三方系统接口的对接费,这里的第三方系统包括但不限于以下内容:
3)▲该系统必须与学校移动支付系统对接,并能按学校规定实现在线缴费。
4)▲该系统必须与学校车辆管理系统对接,确保人员能够正常进出校园及会场。
5)▲该系统必须与留影墙功能打通或对接,实现认证访问,非认证用户无法查看照片。
6)▲该系统必须与直播平台对接,实现认证后访问直播,非认证用户无法访问直播。
7)▲该系统必须与预约/订餐功能打通或对接,实现认证后使用应用,非认证用户无法使用。
8)▲该系统必须与学校短信平台对接,基于短消息的消息提醒通知均通过该短信平台发送。
3.3 UI设计要求
用户操作界面必须完全按照赛事组要求进行个性化设计。用户界面美观大方,直观高效,能够凸显大赛主题,要求提供不少于5个版本的界面设计给大赛组委会选择,如不符合要求,无条件修改,直至大赛组委会认可。操作流程清晰简洁,易用度、灵活度高,给用户提供良好的操作体验。基于模块化、组件化的思想实现流程化界面、向导式操作和个性化风格,方便使用人员轻松掌握相应系统功能、快速完成相应操作。
3.4 安全性要求
1)★需要提供详细的用户及管理员使用平台的登录日志与操作日志。
2)★应使用加密算法对程序源代码进行加密,防止文件篡改。
3)★全系统页面必须使用HTTPS,系统支持SSL/TLS证书。
4)★需要提供全面的系统安全策略实施,包括系统完善的用户及权限管理、用户身份认证策略以防非法用户入侵。
5)★需采用PHP、JAVA、Python或Ruby语言中的一种或多种,需要对系统的保密数据进行Zend加密或类似加密防范系统防止SQL注入等的攻击机制。(需提供书面承诺函并加盖公章)
6) ★所有在通信过程中使用的密钥、算法均需要支持升级,从而持续保持系统的安全性。
7)★对系统数据传输,进行加密处理和脱敏显示。
8)▲要求系统上线前须通过网络安全等级保护三级,投标人报价须包含三级等保测评所需费用,未能通过指定级别的等级保护测评,不予上线、不予验收。
3.5 扩展性要求
1)在充分满足当前业务需求的基础上,能够为第三方软件提供相关接口,以确保系统可满足后续业务发展需要。
2)▲必须提供标准的API接口,需要符合RESTful及OAuth2.0规范,接口方式需要涵盖(HTTP、SOAP等)。
3.6 高并发要求
▲系统须支持不低于20000人注册及使用,不设置用户上限。在最小集群下支持5000人在线,在此数据量的情况下,系统应具有高并发处理支持能力,并发量不低于5000人,满足在某一时段集中进行数据采集、业务管理、数据传输、查询、统计分析的需要。
4. 商务要求
4.1开发周期:
▲挑战杯为全国性重要赛事,关系着四川大学的整体形象。因赛事临近,系统建设时间紧迫,要求中标企业必须在中标公告截止日后三天内签定合同,必须在签订合同后的30个自然天内完成系统建设并上线试运行,期间接受学校信息化工作管理单位的上线测试,测试通过后将于2021年8月30日上午10点正式上线。如中标企业无法按时签订合同,或无法按照工期交付使用,甲方有权终止合同,并要求中标企业除返还已支付的款项外,还需按照合同金额的50%赔偿违约金。
4.2实施进度要求:
▲投标人必须制定详细的项目实施进度表,并保障不低于项目实施进度表进度进行系统建设。
▲中标企业自合同签订之日起,必须每日上报系统开发进度,并接受甲方检查,如两次出现未按进度要求完成,甲方有权终止合同,并有权要求中标企业赔偿违约金。
4.3售后服务要求:
▲合同签订后,提供至少一名工程师驻场服务,提供工程师团队7X24小时远程技术支持服务,直至赛事结束。若因不可抗力因素导致大赛时间推迟超过一个月,驻场服务模式另议。
详情请访问原网页!
项目编号:ZBZXFB2021013
采购单位:四川大学
联系人: 中标后在我参与的项目中查看
联系电话:中标后在我参与的项目中查看
签约时间要求:成交后5个工作日内
到货时间要求:
预算总价:675000
收货地址:
供应商资质要求:符合《政府采购法》第二十二条规定的供应商基本条件
采购商品:第十七届“挑战杯”赛事服务管理平台技术开发服务
采购数量:1
计量单位:项
预算单价:675000
技术参数及配置要求:1. 系统说明
1.1定制开发第十七届“挑战杯”赛事服务管理平台,实现赛前及赛事期间各种信息收集、展示、查询和服务功能。确保系统具有高度灵活性、敏捷性和扩展性,可随时根据实际需求做出调整,并具有良好的稳定性和用户使用体验。
★1.2“挑战杯”赛事服务管理平台须建立统一的管理平台,提供统一的管理界面,对赛事所涵盖的各环节进行统一管理及监测预警;建立赛事相关人员数据库,实现人员的统一管理、分组管理。实现用户管理、角色管理、权限管理、组织机构管理、消息管理、住宿管理、参赛人员报到管理、预约管理、赛事在线、在线评分等功能;同时实现与其他系统及硬件平台的对接,实现数据的统一管理与交互,为大赛提供一流的信息化服务。
★1.3“挑战杯”赛事服务管理平台须保障7×24小时不间断工作,确保数据的一致性、完整性、准确性。系统参数可配置;各项服务间为松耦合架构,独立运行,互不影响;预留拓展接口。“挑战杯”赛事服务管理平台须防范注入漏洞攻击,参数使用严格的过滤函数进行过滤,关键服务请求内容加密,能够确保系统的数据安全性。
2. 开发与功能需求
2.1 移动信息服务平台
★2.1.1开发移动端信息服务展示平台,并与微信公众号对接。
★2.1.2实现与市面上主流手机品牌型号进行完美适配,避免因适配问题造成的用户体验缺失。
★2.1.3用户须采用验证方式登录,如:手机短信验证、人脸识别验证等。
★2.1.4平台所有信息均需登录后可见,如部分信息可公开展示,管理员拥有权限对展示材料进行权限管理。
★2.1.5平台中各应用可根据权限或需求定向投送。如某个应用仅对某种身份人员开放,则其余人员不可见。
★2.1.6平台需实现动态电子二维码确定身份功能,便于校内通行。
2.2 消息平台
★2.2.1平台开发消息功能模块,其组织架构可以自定义分组,一个ID可在多个分组中存在,消息发送可按分组、按个人等精准发送。
★2.2.2平台消息推送、短信推送、邮件信息等消息,管理员同步可选。
★2.2.3ID号支持自编号(如学工号)、身份证号、手机号、邮箱号等多种模式。
★2.2.4消息中心拥有多种管理权限、多级管理权限、多重管理权限,实现对参赛人员进行精准消息管理。所有管理员都可以拥有消息发送权限,消息可由管理员按下属成员分组、按个人精准发送给下属成员。如:志愿者管理员可通过消息中心,向所有志愿者发送消息,可精准到向某一人或多人发送消息。如省队管理员可以向下属省份所有人员发送消息,可以向下属各高校管理员发送消息,可精准到向下属某一人或多人发送消息。
★2.2.5平台系统有独立的消息中心,平台消息集中显示(如赛事消息模块),有已读和未读标记,未读消息有显著提醒等,方便查询消息。
2.3 数据中心
★2.3.1用户到校前,需激活个人账号。
★2.3.2用户激活帐号时,须完成:账号激活、个人信息完善、会务费缴纳、住宿登记、交通信息填报等整个流程,则系统默认该账号已成功完成激活,可实现系统内部信息的查看,否则,系统默认该帐号未完成激活,系统内所有信息均无查看权限。该部分信息由管理员设置的开放信息为准,除管理员开放查看信息外,其余信息均无法查看。
★2.3.3平台账号激活须支持三种模式,赛事组根据实际情况任选。
1)与第三方报名系统进行技术对接,获取基础数据,用户通过手机号作为账号进行激活;
2)开放注册,支持多种验证模式,设定截止日期,截止后数据上报组委会审核,审核通过的为有效账号,可激活,未通过的为无效账号,无法激活;
3)设置各单位管理员,由各单位管理员负责本单位内所有参会人员的信息预置,设置截止日期,到期后不可修改,预置成功用户可进行账号激活。须向各单位管理员提供在线查阅的操作手册和可下载的数据模板,便于其学习使用和批量导入数据。
★2.3.4用户激活账号时,须完善个人信息。个人信息内容包含但不限于:姓名、性别、学校(单位)、手机号、身份证号(护照号)、人员类别、身份等约20项左右信息。
★2.3.5系统须具有信息填写智能纠错功能,如:手机号码、身份证号码等的基本规则检测,文字与数字的检测,信息查重检测等。
★2.3.6以上个人信息可由授权管理员代填。
★2.3.7对各单位授权管理员开放独立的管理权限,权限设置可由系统管理员批量配置,各单位授权管理员可通过平台对下属参赛人员进行跟进管理等,如通过平台查看下属参赛人员住宿信息、交通信息等。
★2.3.8系统须具有多级管理权限,超级管理员可设置任一级管理员并授权其相应管理权限等。管理权限设置可精准至字节。可实现单个或多个二级权限批量下发,可实现多重分组,各个分组独立管理,人员分组可交叉重叠且不受分组影响。上级管理员可下发下一级权限,并可批量设置下一级管理权限。
★2.3.9参赛人员可通过系统查看自己的参赛时间、参赛场地、出入口、注意事项等相关参赛信息。
2.4 参会报到模块
★2.4.1住宿预定:用户选择是否需要安排住宿。选择需要安排住宿的用户在线自助选择宾馆及房型,系统自动核算住宿费用,用户通过学校移动支付平台自助缴费。缴费通道有会务费(交财务处)和住宿费(会务公司)。住宿信息在缴费完成前默认预定未完成,可随时修改;住宿费缴纳成功后,则已完成住宿预定,不能修改。
★2.4.2会务费和住宿费可由授权管理员代缴,并由平台统一出具电子发票或纸质发票。
★2.4.3系统对各宾馆开放后台管理权限,宾馆可随时查看自己宾馆的预订情况,随时可以调整房间数量,但房间数量不可低于限定数量,可向上增加,各宾馆管理员不可修改房间价格。宾馆管理员能从后台看到自己宾馆最终的预订明细,用户入住宾馆时,宾馆管理员可以从系统自动核销。
★2.4.4支持将报名成功参会人员数据在宾馆间转移,便于参会人员入住宾馆的调整。
★2.4.5接站服务:该功能模块点击进入后,出现温馨提示,用户选择是否需要接站服务。需要接站的用户填写:抵蓉时间、航班/车次/车牌号、抵达站点等交通信息。以上交通信息可由授权管理员批量代填。该部分信息可随时进行修改。交通信息填报和修改可设置截至时间,到期后不可修改交通休息和接站信息。
★2.4.6系统管理员可从后台导出需接站人员明细信息,为接站工作组提供数据支持。
★2.4.7参会人员到达后,须扫码签到,后台可随时查看、统计抵达人员数据及明细。
★2.4.8系统部分信息须扫码签到后才打开访问权限。管理员可进行单个设置或批量设置。
2.5 预约中心
★2.5.1车辆进校预约:定制开发前端扫码或在赛事平台点击对应图标进入车辆临时进出校园预约系统,可灵活设置审核权限,并将数据传输给学校车辆管理系统,预约成功后返回消息提醒;
★2.5.2用车预约:授权人员扫二维码或在赛事平台点击图标进入用车预约系统,填入相应信息,实现在线用车预约。后台管理员可实时查看约车统计信息,并具有灵活的排序功能,设置一键智能排序,如:同时段同目的地用车需求;同时段同出发地用车需求等多种排序模式,便于交通组进行调度安排车辆,调度安排成功后可将车辆信息和驾驶员信息发送给约车人;该约车权限仅对部分人员开放,其余人员在平台中不可见该功能。
★2.5.3工作餐预订:
1)按需求在相应单位或工作组设置订餐管理员,由订餐管理员线上自助订餐,后台生成订餐确认单,餐饮保障单位送餐时该确认单需由订餐管理员或订餐管理员指定的收货人签字确认。一个订单内允许填写多个送餐地址及相应数量;
2)一次性超过50份的订餐需求,系统需要在餐饮保障单位设置节点,由节点人工安排给多个食堂制作并根据用户填写的多个地址进行配送。
3)管理员及饮食中心均可查询权限内的历史订单。订餐确认单一键打印,可重复打印。
4)订单完成后,餐饮保障单位可从后台查询、统计、打印各用餐单位的用餐统计数据和明细清单,对账完成后,用餐单位通过对公转账方式支付餐费。
2.6 赛事新闻通告中心
★2.6.1实现会务通知公告、赛事新闻、食宿交通信息、日程信息、路线信息等的发布、呈现。该权限可由管理员下发给多个人进行管理。
2.7 会务资料
★2.7.1制作电子版会务资料,该资料仅对账号激活用户开放。且会务资料仅能在线查看,不能下载。
2.8 赛事留影
★2.8.1实现赛事留影功能。赛事期间由专业的摄影师现场拍照并实时传输到留影墙,用户可通过信息验证或人脸识别自动匹配查找与自己相关的照片,进行下载。
2.9 作品展示
★2.9.1参赛作品(800-1000)件线上展示,包括作品介绍、图片展示、队伍信息等。
2.10 评分系统
★2.10.1定制开发在线评分系统:实现队伍信息、作品信息、复赛成绩、评委信息等前期数据初始化;通过参数配置实现参赛队伍、评审专家在大分类中自动随机分组,后台设置评分机制,系统根据评分规则自动计算各参赛队成绩。计算完成的成绩进入待发布队列,由工作人员审核后,再行确认发布或驳回,成绩一经发布不可更改,并同步在展示大屏显示。(注:在线评分系统具体流程需求以最终组委会确定方案为准,若与本需求不一致,则以组委会意见为准。)
★2.10.2评审专家账号预置:由管理员批量导入专家组数据信息,包含:专家姓名、联系电话、单位、专业方向、身份等重要信息。
★2.10.3专家库管理模块:管理员可通过系统后台批量导入专家数据,也可批量删除专家数据,可逐一添加,也可逐一删除。可批量增加、修改专家属性、可逐一增加、修改专家属性。如批量导入专家邮箱地址等。管理员可按条件查询专家数据、批量导出专家数据。所有操作均须保留在日志报表中。
★2.10.4组别管理模块:管理员可通过系统后台批量导入组别的分类信息,包括该分组的名称、属性,所需专家专业方向、职称等专家组成员数量和结构。
★2.10.5考场管理模块:管理员可通过系统批量导入考场信息,如:校区、楼栋、房间号等。
★2.10.6签到/报到管理模块:专家按时到场后扫码签到,系统后台可随时查看签到专家统计数量信息及名单信息。
★2.10.7专家分组管理模块:管理员可根据各个组别的分组属性,从已按时到场签到的专家中按照各分组专家专业方向要求,系统自动分配专家,管理员拥有手动调整专家的权限。管理员可设置备用专家数量及专业信息,系统自动选择,管理员也可手动选择。管理员可手动导入此次评审的专家分配表,设置数据开放时间,在数据开放时间前,扫码提示:请于****年**月**日**点前扫码查看您所参加的评审相关信息。直至数据开始时间到点后,系统自动给专家推送消息,专家点击察看自己对应评审信息,包括:专家姓名、单位、专业方向、联系方式等基础信息和专家自己参与评审的组别名称、地址、专家身份等信息。专家只可见自己的信息。专家根据时间和地址进入相应会场领取评审设备。
★2.10.8评委在线打分:评审专家所用评分设备根据安排排序,显示参赛队伍列表,并根据当前比赛进度自动显示当前参赛队伍的评分界面。评审专家通过评审设备上面的九宫格数字键为各参赛队伍评分。同时在统一的监控室设置后台管理账号,其仅拥有获取评审进度显示功能。如:正在评审作品名称、评委5名,评审进度4/5等。待进度显示为5/5时,该管理员可依次点击计算成绩和发布成绩按钮。点击计算成绩,则成绩自动保存在系统中,在未点击发布成绩前,均可发还评审专家进行再次核对调整。点击发布成绩,则该参赛队成绩锁定不可修改,并同步上传至对接好的专用展示大屏进行公开发布。
★2.10.9成绩计算:每个作品成绩按照比赛规定算法自动计算,同时可按组汇总、按大类汇总,并可按照组委会要求实现全过程在线调整。直至确认并发布后不可修改,并同步公开展示。
★2.10.10系统需支持多种分数计算方法,如:去掉一个最高分和一个最低分,再计算平均分;不同身份评委打分权重不同,可根据评分系统后台设置权重系数,再进行计算得分等多种计算方法计算各参赛队最终得分。最终计算规则以组委会决议为准。
★2.10.11每个评分环节可回溯,以便回应质疑。
★2.10.12评审专家授权须具备白名单机制包括但不局限于IP、MAC、专家ID等,确保赛事评分公平、公正、安全。
2.11 大屏成绩展示系统
★2.11.1部署相应展示系统或平台,将赛事信息、比赛动态、评分结果实时在大屏幕上进行展示,需定制开发展示页面。
★2.11.2需能同时展示多个赛场的成绩。按照新出成绩先后顺序轮番展示。
2.12 系统设计、美工、UI
★2.12.1移动信息平台、消息平台、赛事新闻通告中心的页面UI设计及制作。界面设计简洁清爽,贴合大赛主题,凸显川大元素。
★2.12.2要求前期页面设计不少于5个版本提供给赛事组选择,如不符合要求,无条件修改,直至赛事组评定通过为止。
2.13 安全设计
★2.13.1通过安全设计防止截屏、录屏等。如用户登录后页面具有全页面水印功能,水印内容为当前登录人员姓名和当前日期。
2.14 驻场服务
★2.14.1合同签订到赛事结束期间,至少派一名技术工程师到学校驻场服务。该人员须一直与赛事组老师一起,随时了解赛事最新情况,对赛事服务平台做深度调研,并提出合理化建议。将最新设计要求及时反馈给开发团队,能做到及时响应需求的修改。
2.15 系统使用培训
★2.15.1现场根据功能模块具体场景,组织相应志愿者进行系统使用培训,预计10场左右。
3. 技术要求
3.1 架构要求
★系统所有服务需满足微服务架构的特点,需支持消息队列机制,服务端需支持windows和linux多平台布署,需要支持分布式服务部署。
3.2 系统对接要求
1)▲系统对外提供的程序调用接口符合RESTful及OAuth2.0规范。
2)▲报价须包含匹配第三方系统接口的对接费,这里的第三方系统包括但不限于以下内容:
3)▲该系统必须与学校移动支付系统对接,并能按学校规定实现在线缴费。
4)▲该系统必须与学校车辆管理系统对接,确保人员能够正常进出校园及会场。
5)▲该系统必须与留影墙功能打通或对接,实现认证访问,非认证用户无法查看照片。
6)▲该系统必须与直播平台对接,实现认证后访问直播,非认证用户无法访问直播。
7)▲该系统必须与预约/订餐功能打通或对接,实现认证后使用应用,非认证用户无法使用。
8)▲该系统必须与学校短信平台对接,基于短消息的消息提醒通知均通过该短信平台发送。
3.3 UI设计要求
用户操作界面必须完全按照赛事组要求进行个性化设计。用户界面美观大方,直观高效,能够凸显大赛主题,要求提供不少于5个版本的界面设计给大赛组委会选择,如不符合要求,无条件修改,直至大赛组委会认可。操作流程清晰简洁,易用度、灵活度高,给用户提供良好的操作体验。基于模块化、组件化的思想实现流程化界面、向导式操作和个性化风格,方便使用人员轻松掌握相应系统功能、快速完成相应操作。
3.4 安全性要求
1)★需要提供详细的用户及管理员使用平台的登录日志与操作日志。
2)★应使用加密算法对程序源代码进行加密,防止文件篡改。
3)★全系统页面必须使用HTTPS,系统支持SSL/TLS证书。
4)★需要提供全面的系统安全策略实施,包括系统完善的用户及权限管理、用户身份认证策略以防非法用户入侵。
5)★需采用PHP、JAVA、Python或Ruby语言中的一种或多种,需要对系统的保密数据进行Zend加密或类似加密防范系统防止SQL注入等的攻击机制。(需提供书面承诺函并加盖公章)
6) ★所有在通信过程中使用的密钥、算法均需要支持升级,从而持续保持系统的安全性。
7)★对系统数据传输,进行加密处理和脱敏显示。
8)▲要求系统上线前须通过网络安全等级保护三级,投标人报价须包含三级等保测评所需费用,未能通过指定级别的等级保护测评,不予上线、不予验收。
3.5 扩展性要求
1)在充分满足当前业务需求的基础上,能够为第三方软件提供相关接口,以确保系统可满足后续业务发展需要。
2)▲必须提供标准的API接口,需要符合RESTful及OAuth2.0规范,接口方式需要涵盖(HTTP、SOAP等)。
3.6 高并发要求
▲系统须支持不低于20000人注册及使用,不设置用户上限。在最小集群下支持5000人在线,在此数据量的情况下,系统应具有高并发处理支持能力,并发量不低于5000人,满足在某一时段集中进行数据采集、业务管理、数据传输、查询、统计分析的需要。
4. 商务要求
4.1开发周期:
▲挑战杯为全国性重要赛事,关系着四川大学的整体形象。因赛事临近,系统建设时间紧迫,要求中标企业必须在中标公告截止日后三天内签定合同,必须在签订合同后的30个自然天内完成系统建设并上线试运行,期间接受学校信息化工作管理单位的上线测试,测试通过后将于2021年8月30日上午10点正式上线。如中标企业无法按时签订合同,或无法按照工期交付使用,甲方有权终止合同,并要求中标企业除返还已支付的款项外,还需按照合同金额的50%赔偿违约金。
4.2实施进度要求:
▲投标人必须制定详细的项目实施进度表,并保障不低于项目实施进度表进度进行系统建设。
▲中标企业自合同签订之日起,必须每日上报系统开发进度,并接受甲方检查,如两次出现未按进度要求完成,甲方有权终止合同,并有权要求中标企业赔偿违约金。
4.3售后服务要求:
▲合同签订后,提供至少一名工程师驻场服务,提供工程师团队7X24小时远程技术支持服务,直至赛事结束。若因不可抗力因素导致大赛时间推迟超过一个月,驻场服务模式另议。
详情请访问原网页!
返回顶部