招标
长沙卫生职业学院:“智慧校园”基础软件平台一期建设采购需求公开
金额
-
项目地址
湖南省
发布时间
2022/06/22
公告摘要
公告正文
一、功能及要求:
(一)项目背景
本项目围绕我校智慧校园基础平台进行建设,充分利用信息化先进手段,辅助我校实现高效管理,提升我校管理与服务水平。此次智慧校园基础平台建设以我校门户为依托,通过高效采集、有效整合、并基于开放的信息化模式下,转变信息化建设思路,构建基于PC与移动相结合的服务管理新模式。提供在一站式办事大厅中,满足业务办理、流程审批、信息查询等综合性服务平台,并借助此次智慧校园基础平台的信息化建设提升我校技术基础架构,并从业务开展和流程执行的层面实现全校部门间的数据融合,消除信息孤岛,做到让各业务部门多种业务、同一来源,让终端用户一次填报,重复利用。彻底解决学校各部门数据不统一、用户反复填报数据等的问题。本次项目的建设,一是需要对我校基础支撑进行完善、实现互联网的无感对接,提升校内数据质量。二是实现身份的统一管理,解决身份的单点登录及安全审计问题;三是丰富校内师生服务,梳理跨部门、跨流程,建立用户真正需要的服务,提升用户信息化体验,解决用户使用最后一公里的问题。
(二)项目需求
1、完善身份互联建设:通过本次项目建设,在我校建成一套符合高校使用需求的校园身份互联平台,完成我校各类业务系统的身份对接,解决单点登录、用户管理、认证授权、认证审计等一系列问题。
2、实现校务服务事项数据共享:打破信息孤岛,实现数据共享,组织数据来源部门编制校务服务数据目录,推动学校行政办公、财务管理、学生工作、教学管理、科研管理、后勤服务等各部门建立数据仓,不断充实校务服务大数据。
3、推进校务服务事项流程优化:优化办事流程,进一步减少前置条件、精简办事材料、缩短办理时间,有效避免师生在办事过程中重复填写表单和重复提交证明。
(三)技术路线
1、本项目软件运行平台和应用系统均可运行于Linux、Unix、Windows等高安全性操作系统。开发技术应采用J2EE标准、组件技术及在数据交换上对XML的支持,使系统功能最优化,同时将整体系统内部在技术上的相互依赖性减至最低。
2、本项目软件基础运行平台和应用系统均要求采用B/S结构,采用Java编程语言和服务器端Java技术进行开发,应用程序开发与运行结构要基于统一的技术开发平台的三层架构,即Web服务器、应用支撑服务器和数据库服务器。且必须基于Oracle 11g或以上版本。
3、采用面向对象的组件技术,着重于开发构成应用程序“业务对象”的可重复使用的组件,利用这些组件顺利地建立分布式应用程序。各应用系统要基于多层架构和组件技术进行构建,做到系统结构层次清晰。
4、所有应用逻辑、流程、数据等都应当能够根据建设方要求的颗粒度进行封装,能完全实现跨业务部门的业务流程和相对应的细颗粒度的分级授权体系,且保障优秀的易用性。本次项目建设过程中,要保证此项目后期的可持续服务能力及外部接入的开放能力。
5、本项目软件平台所有运行的组件支持容器化部署。系统平台实现从源代码到交付件过程全自动部署,从交付件到部署环境的过程是可重现的,升级过程可以一键完成。
6、本项目软件系统需支持分布式架构,处理节点支持水平多点扩展,系统必须支持负载均衡,支持动态监测负载状况,自动对可用资源进行并发检测,调整和分配等功能。
7、本项目软件系统平台的接口体系需支持 OAuth2.0 协议,实现基于用户个人授权的安全模式。为保证系统运行的稳定性与安全性,本项目如有涉及中间件产品,需采用主流的、成熟的商用中间件产品。所有组件符合微服务架构模式,并提供完善的 API,且可以由OAuth 等机制保障其开放性和安全性。
8、一站式流程服务平台所有组件兼容原生的Kubernetes及其生态,比如支持Prometheus监控、日志等各种第三方云原生工具栈。支持实时数据备份,支持云存储及非结构化数据存储,容量无限扩容。
(四)安全要求
1、认证授权:保证用户的合法性和用户使用信息资源的权力,避免内部敏感信息泄漏和服务所提供的信息资源被非法访问,造成严重的安全事件。
2、信息保密:充分利用密码技术,对于需要保密的信息,采用密码技术进行加解密处理,防止信息的非授权泄漏,确保涉密信息在产生、存储、传递和处理过程中的保密。
3、数据完整性:建立数据完整性检验机制,保证收发双方数据的一致性,防止信息被非授权修改。
4、审计:记录应用日志,对事件进行分析,并能提供预警信息。
5、数据备份:利用数据库的备份功能将建设的平台和系统数据备份到指定的服务器或存储系统上。
6、要求投标人从物理安全、网络安全、中间件安全、系统安全、应用软件安全、用户安全、数据安全等几个方面提出配套的安全体系完善方案,以便防范安全风险。
二、相关标准:
符合国家、行业相关标准及规范要求。
三、技术规格:
(一)建设清单
投标人可提供同等档次或更高档次产品和服务,并提供相应文件证明其符合或优于采购需求,各项建设内容要求见详细技术参数要求。
(二)详细技术参数及要求
1 一站式网上办事大厅
1.1 融合服务大厅建设要求
1.1.1 融合服务大厅l 校园门户
为师生用户提供查看学校各类信息资讯、新闻、通知公告和系统直通车的统一门户。
支持个性化界面, 投标方需提供多套不同主题风格的界面模板供学校选择,页面模板支持两列和三列布局,并不同尺寸、不同内容的卡片组成页面的内容,学校可根据自身的要求配置整体配色、校徽、Tab页标题、头图等内容。门户平台需提供开放能力支持根据学校的个性化需求设计界面。
丰富的内容卡片: 提供丰富的标准内容卡片库,供学校选择使用来支撑信息门户内容展示。
系统直通车:需支持灵活添加业务系统,并支持授权不同角色的用户,用户只能看到自己有权限的系统。
新闻资讯聚合:需支持接口、数据库、网页抓取方式将学校公文、部门通知、校内新闻等内容集成在新的校园门户中。
l 办事大厅
需为学生、教职工、单位办事不同角色的用户提供按照不同的办事主题和办事部门对外提供办事服务,既包括线上可办理的信息化服务,也包括在线下办理的事项清单,让师生及游客对校内办事清单有详细的了解,包括办理部门、办理地点(地图的形式体现)、办理时间、部门电话、所需材料、常见问题等。
首页:需包含对事项的搜索功能、整体导航,在线服务的最近使用以及办事大厅的简要统计。
分角色目录页:需针对学生、教师、游客分别提供分角色目录页,支持按照事项主题、事项部门、标签的查找,以及对具体事项是否有在线办理的筛选。
事项详情页:对某一事项的具体描述页面,描述内容需包含事项名称、责任部门、服务部门、前置条件、服务内容、业务周期、内容标签、办理须知、所需材料、办理时间和地点、咨询电话和常见问题等;
针对有在线办理的事项需提供“在线办理”按钮进行跳转。
搜索: 能基于AI智能引擎,支持根据用户输入的关键词匹配事项名称、事项内容、应用名称以及常见问题中的关键词进行综合搜索。
个人中心:包含用户个人在办事大厅中的办件以及意见反馈。
l 工作台:
需为全校涉及业务管理类、行政审批类用户提供快速、方便、高效的工作页面,只显示跟自己工作相关内容,预置已经分类完成的管理服务目录,我的收藏,任务中心统一处理待办任务入口,不需要登录到各个系统中办理,提高办事效率。
l 责权公示
需提供符合学校要求的职责清单、审批清单、责任清单管理后台,能够根据不同的部门填写职责、并对每个职责关联服务事项,在前台统一展示。
l 我的收藏
提供应用收藏功能,用户可将自己经常需要使用的应用添加到收藏夹。在个人中心页面有我的收藏模块,用户可以更直接方便的获取到自己收藏的应用。
l 意见反馈
提供用户问题反应渠道,用户可填写反馈意见或建议。为用户提供意见反应渠道,搭建用户与管理者之间的网络沟通桥梁,管理端根据获取的意见可及时做出调整并回复用户处理结果。
l 服务评价
提供用户对服务事项、办结的流程进行满意度评价,将自己最真实的使用感受分享给其他用户、反馈给应用管理员。用户使用应用前也可以通过查看其它用户对该应用的评价,作为应用选择的依据。应用管理员可以查看来自用户的应用评价,为进一步优化升级应用提供参考依据。
l 消息提醒
应用程序能调用消息中心接口,将提醒消息推送到服务大厅中分类展示,并显示消息的查看状态。
1.1.2 移动服务大厅支持一站式服务大厅前台使用移动端浏览器访问,内容与PC端一致,提供专门的移动端卡片和管理支撑能力,包括校内门户、办事大厅两部分内容。支持集成到企业微信、钉钉、微信公众号。
l 校内门户
包括个人数据、校内新闻、通知公告、校内发文、待办通知、最近使用服务、通知公告、业务直通车等;
l 办事大厅
用户可搜索服务事项,并可根据学生、老师、游客不同角色分类展示学校内部各个部门所提供的办事指南,办事指南包括事项名称、责任部门、服务部门、前置条件、服务内容、业务周期、内容标签、办理须知、所需材料、办理时间和地点、咨询电话和常见问题等,并可在办事指南中关联在线应用、提供咨询、评价等服务;展示个人办事详情,包括正在办件,已完成办件,待办任务,我管理的事项;提供办事大厅运行数据展示,包括当前进驻事项、可在线办理事项、当前正在办件、已完成办件、累计服务师生数。
支持企业微信、钉钉、微信公众号等移动终端对接方式。
1.2 平台服务能力需求
1.2.1 应用管理中心需支持对接入应用的多终端(PC、移动校园、微信端)发布、上架、下架管理、权限管理能力,实现一处发布多终端使用;支持对前台大厅统一管理与配置,大厅模板管理、卡片配置管理以及其他内容配置能力。
管理:包含分配业务域、分配应用管理员、编辑、网页端和移动端应用的上线和下线设置;
配置:配置项包括属性、授权、开放时间、维护时间。属性中包括服务场景、服务角色、服务类别、服务方式、应用属性配置、推荐周期设置、应用可见性设置、应用详情设置。
1.2.2 事项管理中心l 服务事项管理
需支持对事项清单进行全生命周期管理,建设学校统一事项清单库。
事项审核:需支持校级管理部门对业务部门申报的服务事项进行审核,审核通过后,可对事项进行配置。
事项配置:需支持管理员对审核通过的事项进行应用配置、标签配置、可能问法配置。进行应用配置时可直接查询线上服务大厅上的所有线上服务列表,直接点击关联,无需配置其他信息。
事项发布:事项审核完成并进行相关配置后,需支持管理员对外发布,师生可在办事大厅中查询该事项。
事项查询:需支持事项库的多维事项查询,包括事项类型、职能部门、服务类型、起止时间等,显示各类事项的查询结果,并可以导出事项清单。
需支持服务事项字段自定义,除了产品标准提供的填写字段以外,用户还能自定义符合本校的字段并能编辑字段名称、内容显示、是否必填等。
l 服务字典表管理
需能对服务主题和服务部门的增删配置操作,用于支撑线上服务大厅的模板前台的内容。
l 事项管理员维护
支持针对部门指定业务管理员,用于将服务事项维护的权限下放,某个部门下的业务管理员能够对此部门为责任部门的服务事项进行维护。
l 任务中心
各类应用服务通过任务中心对外开放接口对接任务中心,将服务内部产生的任务信息推送至任务中心,使用户能够在服务大厅统一处理待办任务、已办任务。
待办任务:师生能够在任务中心中查询当前自己所有的待办任务,并能根据接收时间、任务来源、紧急程度、任务类型进行筛选,并能够点击单条任务跳转至对应的应用。
已办任务:师生能够在任务中心中查询自己所有的已办任务,并能根据任务名称进行关键字搜索,以及根据处理时间、任务来源、流程状态进行筛选,可以查询到已办任务。
当前所属流程的状态以及流转记录。针对流转记录,用户可以查看到此流程经历的每个节点名称、处理人、处理意见、处理结果、接受&处理时间以及耗时。
我发起的:师生可以在任务中心中查看自身在所有的系统中发起的流程,能通过流程名称进行关键字搜索,并能根据发起时间范围、任务所属来源以及流程状态进行筛选;针对某个流程,师生可以点击跳转至应用内部、查看此流程的流转记录以及对当前办理人进行催办。
1.2.3 流程中心l 流程设计
投标方需提供一套遵循BPMN2.0规范的流程执行引擎和服务引擎来执行流程和流程所定义的服务。可以执行基于BPMN2标准的业务流程模型,包括执行人工任务以及各种事务型服务。提供流程定义与执行语言完全遵循国际标准的流程执行语言BPMN2.0。
需采用业内通用并符合BPMN2.0标准的Activiti流程引擎。
需支持可视化流程设计,支持在Web 页面采用拖拽方式设计流程;按照BPMN 流对象与类型进行设置。
需支持多种流程模式,至少包括顺序、分支、并发、子流程、条件路由、并行会签、串行会签等流程
需支持支持多种流程操作权限,至少包括提交、退回、追回、转办、终止、催办、加签、跳转、挂起。
需提供丰富的任务节点类型,至少包括单人活动、多人并行、多人顺序、多人单一几种类型。
需支持多种办理人设置方式,支持按照人员、部门、用户组、岗位方式设置流程节点办理人;
需支持多表单设置,在不同流程节点设置不同的表单,每个流程节点上面支持PC、移动表单,系统自动根据访问终端属性定位到PC或者移动表单。
需支持人工选择下一步分支环节,并可配置这项功能在哪个环节启用;
需支持人工选择下一步处理人,并可配置这项功能在哪个环节启用;
需支持配置判断分支条件,根据登录人的基本信息和业务字段信息,进行AND OR 布尔表达式进行逻辑判断。
需支持多版本管理,支持将修改后的流程保存为新的版本,旧的版本可恢复。
l 流程分析
提供流程分析功能,帮助管理人员分析工作流状态,定位工作瓶颈,改进工作流程,提高工作效率。
支持服务状态统计,如驳回数、挂起数、终止数、办结数;
支持统计展示服务次数、办理次数的Top10服务清单;
支持按时间统计流程发起数、办理次数;
支持统计所有已发布的流程服务的发起数、办结数、办理次数、办结率、平均耗时、最短耗时、最长耗时;
l 流程干预
需支持异常流程查询、干预功能,当异常流程或当前环节处理人无法处理时,服务管理员直接将流程转办、挂起或终止。
需支持对流程实例进行挂起、激活、终止、办件取回、删除和查看流程状态。
需支持对流程运行的任务进行人工干预,如提供处理、转办、跳转功能。
需支持对不同版本的流程进行再设计、激活、下载流程图、启动等操作。
1.3 管控中心
l 新闻资讯聚合
需提供URL网页抓取、接口、数据库方式集成新闻资讯,聚合到线上服务大厅、移动端中展示。
URL业务抓取方式,支持URL方式抓取某个网站中的信息,采用可视化的方式选择抓取区域,并将信息内容保存到校园门户中,可以设置抓取的内容是否保留原样式。
接口方式聚合,需提供开放接口,第三方应用程序将新闻、资讯、公告实时推送到校园信息门户中
数据库方式聚合,第三方应用程序提供新闻、资讯、公告的只读权限数据表或视图,新闻资讯聚合模块定时从数据库中同步差异的增量数据。
l 大厅内容管理
直通车管理
需提供可以在桌面呈现并授权的业务直通车卡片配置功能,将不同的碎片化服务组织放置在桌面卡片中并授权,业务直通车卡片支持一级分类和无分类两种场景。
本地卡片库, 平台内置常用的内容卡片库,支持将卡片添加到不同的模板中使用,卡片可设置用户使用权限,用户只能看到自己有权限的卡片。平台提供开放接口及卡片开发标准规范,可根据学校实际需求开发新卡片,可视化方式配置卡片尺寸单列、双列。
至少提供任务中心卡片、最近使用卡片、Banner卡片、通知公告卡片、业务直通车卡片、个人数据卡片、链接导航卡片。其中业务直通车卡片能够根据在系统配置好的业务直通车内容进行显示,支持最多一级分类。
模板库管理,平台需默认提供多套模板,管理员可以选择启用某个模板,平台需明确开发能力及模板制作规范,支持自定义模板。
责权公示管理,需支持按部门分别维护责任清单、审批清单、职责清单,需要支持对每个责任清单关联系统中已经梳理好的服务事项中。需支持按部门名称、清单类型、办理类型查询责权公示
个人提醒管理,需提供用于用户的个人提醒信息配置功能,包含邮箱、一卡通余额等基础信息,邮箱已经内置了主流邮件厂商,例如:腾讯、coremail、亿邮等的集成。
l 大厅展示配置
针对线上服务大厅移动端、线上服务大厅PC端以及可能产生的拓展模块内容进行展示方案的管理,不同的展示方案可以授权给不同的用户组使用。
1、校园门户展示配置
需支持创建多个校园门户展示方案,并可视化方式设置门户布局。
页面容器管理:需支持在页面中添加单列、双列的容器,可以拖动容器位置,并在容器中添加卡片内容。
展示方案授权:需支持将不同的展示方案授权给不同角色的用户,实现不同的用户看到不同的门户内容。
展示方案启停:需支持管理员可启用、停用多个展示方案
2、自定义页签
服务大厅具备融合开放能力,支持扩展TAB页签,支持将应用程序页面集成到服务大厅的导航菜单中或者嵌入到服务大厅中,使其成为一个整体。
l 应用版本管理
提供应用的升级、版本下载、部署地址设置功能。
支持批量下载同一类型的应用包,进行安装部署。
支持选择应用的各个版本进行下载,下载后的包用于应用的升级更新。
支持选择版本对应用进行升级,系统自动推送应用是否升级的信息。
支持配置应用部署前缀,提供测试连接。
l 缓存管理
基于Redis缓存管理机制,支持多服务器间的缓存共享。该模块提供界面化的缓存管理功能,管理员可随时查看平台自身的缓存情况,并可根据实际情况进行缓存的清理。
l 平台版本管理
提供平台的更新说明、当前版本以及依赖关系查看、历史更新记录功能,功能如下。
l 系统管理员维护
超级管理员可以维护系统管理员名单,拥有系统管理员权限的用户可操作管控台中的所有模块。
l 业务域管理
为系统管理员提供业务域配置功能,支持把应用分配到业务域可以更方便的进行应用的管理。业务域管理包括业务域的新增、编辑、删除,并可对域管理员进行设置。
l 意见反馈管理
收集并展示用户前台对线上服务大厅模板中的意见反馈,管理员能够回复或忽略用户的意见反馈内容。
l 用户组管理
根据用户的角色、职责进行分组,管理同一属性应用群体的应用使用权限。有效的用户组管理是做好应用主动推送的第一步。同时管理端可以清晰的了解到业务域下的用户组和具体应用的授权关系。用户组管理提供用户组的新增、编辑、删除功能。
每一个用户组可设置该用户组的用户组名称、所属业务域、用户组描述、组内用户、应用权限。
用户组内的成员管理可提供静态、动态两种形式的管理。解决了不同的业务场景下对用户授权的管理需求。静态组用于固定群组的管理,例如在校生、实习生、教职工等;动态组用于人员变动较快、及时性较高的群组的管理,例如临时人员等。
l 操作日志
管理员能够通过操作日志功能查询近期平台管理员对当前平台的配置的操作,针对不同的操作模块和时间都能进行查询。
2 统一身份认证平台
2.1 身份管理要求
1、用户数据模型
支持按照学校特点和应用现状设计用户、组、权限等模型,并按照模型设计完成数据存储。所有的用户信息应分别存放在LDAP目录服务和数据库中,通过可靠的机制完成两者的同步,用户身份信息在目录服务中以层次结构,面向对象的数据库的方式集中存储管理,从而保证身份数据的一致性和完整性,为校园各类应用提供一致的用户信息访问。
支持设置用户身份类型,方便平台和硬件平台、应用系统等通过LDAP接口的方式实现身份集成。
2、用户管理
系统至少内置教师、学生、校外人员、校友四种基础用户来源,在教师与学生分类下允许用户在基础来源类型下创建自定义类型。
提供具有高校特色的组织机构管理,支持针对不同用户类型生成不同的组织机构树。组织机构树由用户信息自动生成。
系统允许针对不同的用户来源创建至少三种生命周期,包括未入校、在校、离校三个状态。系统应能自动创建对应生命周期的用户组。同时应能对生命周期设置有效期,在有效期到期后,自动转换生命周期状态。投标方需在投标文件中提供真实系统截图。
需支持管理员对全校用户身份帐号数据的增加、删除、修改、过期设置、锁定、解锁等操作。在进行导入用户操作时,可实现拥有多账号的用户自动绑定,无需管理员手工干预,系统自动判定导入账号是否归属同一人,若为同一人不同阶段账号,则系统自动创建自然人,同时完成账号绑定。投标方需在投标文件中提供真实系统截图。
3、应用管理
提供校内身份类型组的管理功能,用于区分用户的身份类型,为校内应用提供资源级授权。
系统同时也应提供微信公众号的配置功能,支持配置多个公众号与平台集成。
4、外部通讯录同步工具
需支持将身份认证系统内的通讯录数据自动同步到企业微信/钉钉,同步内容需包括组织机构及人员信息。在组织机构发生人员异动后,需支持对企业微信/钉钉通讯录进行人员同步。系统需提供配置功能方便管理员新建多个同步任务,同步任务需支持配置同步名称、启用状态、同步类型、同步周期、同步用户分类。投标方需在投标文件中提供真实系统截图。
5、安全中心(登录统计、安全工具)
系统需提供系统安全运行看板,管理员可按照不同时间段,查询系统登录信息,包括尝试登录次数、成功登录次数、失败登录次数、拦截恶意登录,并提供相关的趋势变化图。
系统需提供安全配置功能,管理员可配置密码策略、验证码策略、激活策略、安全问题策略、找回密码策略、人脸识别方式、完善资料策略。
6、帐号元数据管理
系统需支持帐号元数据管理,支持扩展字段满足学校人员信息管理要求。新增自定义字段信息需包括属性名称、LDAP属性名称、显示名称、属性值类型,属性描述,支持设置是否必填、是否显示;需支持管理员配置系统预置元数据的展示/隐藏属性。投标方需在投标文件中提供真实系统截图。
7、登录主题配置
需支持配置多个登录主题,管理员可切换不同的的管理页面;支持上传\下载多个登录主题包。投标方需在投标文件中提供真实系统截图。
8、日志中心
日志中心需支持查看用户操作记录、用户认证记录、管理员操作记录,支持按照认证帐号、认证帐号、操作时间段查询用户认证记录;支持按照操作者、操作对象、操作IP、操作类型、操作时间段段查询用户操作记录;支持按照管理员帐号、登录IP、操作时间段查询管理员操作日志。
9、API接口管理
系统需预置API接口服务,接口应包含普通用户修改密码接口、查询用户属性接口、修改用户属性接口、管理员修改密码接口、根据用户信息创建TGT接口、获取用户详细信息接口、获取st接口;同时提供相关接口的接口发布地址、接口提供地址、提供者;支持对相关接口进行启停操作,管理员也可自助注册其他API接口,并授权第三方应用使用。
提供统一的API网关服务,将系统中的接口在统一的出口向用户提供,同时提供API鉴权等能力。
10、系统应支持配置一种或多种高校常用的消息通道,至少包括阿里云短信、微信企业号、邮件、消息总线,支持配置消息频次,包括消息发送间隔,单个用户每天发送上限。提供可视化的配置页面配置消息总线,配置内容需包括消息发送URI、消息标签、应用ID、应用的凭证密钥、网关域名。投标方需在投标文件中提供真实系统截图。
2.2 统一认证要求
系统需支持高校常用认证协议,可对接各类WEB应用、移动APP、企业微信、钉钉,满足师生访问校园各类系统的需求,提供认证凭证的不可逆安全存储机制,保证密码安全。提供认证过程的安全性保障,保证认证过程凭证安全。具体要求:
1、需提供身份认证基础服务,实现SSO单点登录功能。支持用户登录后在不同系统之间漫游而不需要再次输入密码。平台需能同时支持学校移动应用客户端的统一身份认证集成,需能支持短信动态验证码的验证方式。需提供密码变动短信通知功能。对安全级别要求较高的系统,需提供特殊系统二次登录设置功能。
2、为实现统一认证和单点登录提供接口和通道,可以支持跨平台和各种开发语言的应用系统接入平台,如目前学校各类应用系统所使用的ASP、.NET、JAVA、PHP、Python等多种开发语言;平台需使用CAS5.3或以上版本认证内核,支持的标准至少包括CAS 1.0、CAS2.0、CAS3.0、LDAP。同时还需提供一种为移动APP专用的对接协议。
3、系统需支持在发放帐号密码时支持无密码自助激活方式。要求提供帐号激活服务支撑无密码自助激活方式,激活流程需包括信息校验、绑定手机、绑定邮箱、设置密码、激活完成五部分。投标方需在投标文件中提供真实系统截图。
4、系统需支持基于Nginx的反向代理集成方式,集成接入方式简单,接入系统可以直接从标准的Header中获取登录人员的相关信息,适用不同的开发语言。
5、提供系统级缓存,允许平台调用,加快平台访问速度,同时提供DBLESS能力,在系统遭遇数据库停机时,依然可向用户提供基础认证及鉴权能力,避免因数据库停机造成身份认证不可用。
6、需提供对全校身份认证相关数据的管理功能,包括应用认证分析、使用用户分析、帐号变动该分析,具体要求如下:
应用认证分析支持一段时间,或者快捷查询今日、昨日、近7天、近30天、近90天的应用认证次数排名,以柱状图的方式由高到低排列展示排名前10的应用;提供应用认证次数列表,按照认证次数由高到低的顺序逐行展示认证应用。投标方需在投标文件中提供真实系统截图。
使用用户分析支持一段时间,或者快捷查询今日、昨日、近7天、近30天、近90天的使用用户排名,以柱状图的方式由高到低排列展示排名前10的用户;提供使用用户列表,按照认证次数由高到低的顺序逐行展示用户使用用户的帐号。投标方需在投标文件中提供真实系统截图。
帐号变动分析支持一段时间,或者快捷查询近7天、近30天、近90天的帐号变动情况,以柱状图的方式的方式展示查询期间帐号变动情况,对于每日新增次数、修改次数、删除次数采用不同颜色的柱状体进行展示。投标方需在投标文件中提供真实系统截图。
2.3 自助服务要求
要求系统需在PC端、移动端提供自助服务功能。自助服务需支持中英双语切换。
具体要求如下
1、系统需为校内的最终用户提供面向个人身份自助服务,用户可自行维护个人资料,设置个人帐号,保护登录密码、安全问题、登录别名、邮箱、手机号。
2、系统需支持用户查询各类认证记录,包括当前登录记录、帐号认证记录、密码维护记录、应用访问记录。
3、对于学校拥有多个身份账号的用户,系统需支持用户可以自行设置其中一个帐号为默认帐号。若用户使用手机号/邮箱进行登录时,系统应认定用户本次登录的帐号时是默认帐号。投标方需在投标文件中提供真实系统截图。
4、需支持用户进行个人偏好设置,可以设定本帐号只能在一个浏览器上登录,只保留最新登录页面,其余将退出登录,需支持配置帐号异动提醒。
2.4 帐号安全管理
为帐号安全管理需求,系统提供主动防御功能,对于常见的恶意登录或暴力破解,可自动冻结账号直至解冻。具体需提供异常会话管理、休眠账号管理、恶意登录管理、冻结帐号管理、异常应用管理相关功能。具体要求如下:
1、系统需支持按照用户会话数、IP数去判定某个会话是否为异常会话并触发帐号冻结机制,管理员可配置触发冻结的阈值以及冻结时长。
2、系统需支持根据同一天多次登录成功\登录失败判定某个帐号是否为恶意登录行为并触发帐号冻结机制,理员可配置触发冻结的阈值以及冻结时长。
3、系统需支持管理冻结白名单,添加为白名单的帐号/IP地址不会因为出发冻结机制而被冻结。
4、系统需支持异常应用的管理功能,可配置异常应用判定规则。
5、为满足用户安全访问系统的需求,需提供二次认证、多因子登录的功能。需支持管理与配置二次认证/多因子认证方式及使用顺序,需支持管理员手动拖拽方式维护不同认证的顺序,系统可按照可用性及顺序智能选择当前最适合的认证方式。投标方需在投标文件中提供真实系统截图。
6、恶意登录管理:系统应支持帐号恶意登录的锁定功能,并可通过短信提醒用户,确保帐号安全。
2.5 无缝兼容当前学校使用的认证系统
为了保障师生用户体验,要求新建身份互联平台能够基于我校现有认证系统进行平滑升级,投标方需提供承诺函,承诺本次项目建设的身份认证互联平台能够兼容我校现有身份平台的身份认证协议,已与校内现有身份认证协议的系统无需重新与新建平台重新对接。
3 数据管理平台
3.1 数据管理平台
投标方需要提供包含信息标准管理、数据集成管理、数据备份管理、运行监控管理相关的多种数据管理工具,能够围绕数据共享接口、数据仓库提供高可用的管理功能,同时面向校级数据情况能够向我校提供数据情况可视化展现的能力,以支撑我校核心数据情况的建设。具体功能需求如下:
l 信息标准管理工具
平台需围绕信息标准管理提供元数据、代码标准、标准与代码版本以及数据集市模型的管理功能。
(1)可提供数据源统一注册管理,可灵活调整不同接入数据源的启停;
(2)可提供按目录结构对主数据和业务系统的数据对象进行管理,可根据元数据进行数据建模;
(3)需提供针对元数据一致性检查,采用先对元数据和数据库实体一致性比对,在对差异项进行处理的方式;
(4)需提供代码标准基本管理系列工具,围绕我校实现标准的“制定、维护、理解、分享和集成”,可集中对代码标准进行拆合、启停等操作,能够记录代码变更过程;
(5)可提供标准代码和业务系统代码映射关系的管理功能,实现代码映射的自动感知匹配功能。在代码标准映射过程中,可提供有代码和无代码两种场景下的映射管理;
(6)能够提供针对标准和代码版本的管理,可自动记录数据模型标准和代码标准的变更记录,自动生成标准版本号,并能实现当前版本与上一版本的内容对比。
(7)能够提供按目录结构对数据集市模型的数据对象进行分类管理,在数据集市建模时,可实现根据元数据进行数据建模,并对元数据和数据库实体进行一致性比对。
l 数据集成管理工具
为了形成我校统一的校级主数据库,通过构建一系列数据集成管理工具完成面向分散数据的集成汇聚工作,解决我校数据孤岛的问题。数据集成管理工具主要涉及数据集成开发包、主数据管理与生命周期追溯、数据流向管理等功能。
(1)针对我校数据集成工作,需提供丰富的数据集成开发包。包括拓扑管理、集成设计、集成查看、集成调度等工具;
(2)能够提供丰富的集成接口支持,包括支持主流关系型数据库、支持非主流关系型数据库、支持ODBC数据源类型接入、支持主题或者队列、支持Web Service、支持Tabled-Txt文件、支持XML文件以及操作系统的网络协议的集成接口;
(3)为了提升数据集成的工作量,需要能够向我校提供基于各种场景通用的知识模块,数据集成需求开发包数量不得低于100项;
(4)除了能够提供我校常规主数据管理的功能外,还必须向我校提供基于主数据生命周期的追溯功能,使我校数据管理人员清楚指导每个数据对象随着时间变化,增、删、改的数据量;
(5)必须提供基于数据流向的可视化展示功能,能够实时监控数据源头及目标的数据量,接口运行状态等,能够很方便的在拓扑图和详细列表之间进行切换;
(6)为方便数据管理员实时监控与目标表相关的源头系统与主数据表之间的运行状态,必须提供数据字段血缘监控功能,实现可以通过目标表下钻至源头、主数据、目标三方的监控可视化环境,可在可视化环境下通过触发表间连接,下钻至接口运行状态监控环境;
(7)需支持查询数据对象的接口运行记录,从建表到当前时间的数据全生命周期变化过程;
(8)能够面向我校数据集成业务,提供符合高校行业特征的高校行业集成库,通过可视化集成工具,梳理各业务系统核心的数据模型与字段,形成预制同步接口;
(9)为方便我校信息中心对数据管理的效率,投标方需提供在线SQL查询器,可方便的进行在线SQL查询操作,并能够提供查询语句收藏功能,保留常用语句不低于10个。
l 数据展现
通过对数据情况可视化展现功能建设,使我校可以清晰看到现有校级资产状况,涉及数据模型建模完成情况、数据同步集成概况、数据同步质量等。其中,主要包括需实现的功能为:数据情况概况与详情、数据集成操作情况、数据质量评估、权威数据责任单位管理、全校/部门数据报告等功能。
(1)必须能够以可视化树形结构的方式集中方便的呈现我校数据的概况,其中需要覆盖校级数据中包括的主数据对象模型、自定义对象模型、业务对象模型、数据集市模型、代码标准模型五大类。投标方可以提供以打分的方式,对我校一定时间范围内数据进行评估;支持查看不同模型分类的状态占比、不同模型分类下的业务模型的完整度占比以及不同业务模型的表数量和数据量;
(2)需要能够为我校数据管理员提供在可视化环境下,对各模型逐级下探的功能,能够在一个页面上集中展现不同模型下未建表、无数据表和有数据表的个数;
(3)需要能够展现数据同步质量情况,围绕数据完整性检测项、唯一性检测项、代码有效性检测项、格式合规性检测项,自定义各种展示规则;实现以横向多维柱状图展示各种检测项的检测结果,以增强对正常项数和异常项数监控查询的能力;
(4)需要能够为我校提供数据集成接口运行状态的文本及图形方式展现,实现支持查看每个接口调用成功/失败数量上的反馈,以及支持查看不同业务系统接口数量、运行次数和成功运行次数的统计;
(5)需要能够支持查看历史数据质量的评分,以判断数据质量的优劣;可以实现查看每个模型分类同步的数据条数统计信息,同时可以根据不同系统查看预设表、添加表的情况,并能够给出实时评分;
(6)能够支持实现权威数据责任单位管理的功能,提供易用配置的方式,将责任单位与主数据对象模型之间建立关联,最终可以在数据血缘关系、部门数据报告、质量报告查询中,可自动根据责任单位进行主数据对象模型的筛选;
(7)需要提供面向全校或部门级别的数据报告功能。以图文方式展现各级别组织数据情况,核心包括组织的数据建设情况、数据集成运行情况、数据开放情况、数据质量检测情况四个方面,同时可导出报告。
3.2 数据集成服务
需要与我校集成已经建设业务系统有关数据,包括但不限于已有业务系统OA、短信平台、教务、图书馆数字资源、网站群、微信公众号、一卡通等数据,以及待建的学工、质量保障体系、财务内控、人才培养数据、科研、财务、资产、邮件等业务系统,进行数据集成。集成工作由中标商负责业务系统提供商共同完成。
4 微服务建设
根据我校对微服务需求内容,确定通过流程服务快速构建工具定制开发25个微服务,具体内容包含(但不限于)如下,(最终上线的微服务为建设时到校调研为准):
5 人事应用
5.1 教职工信息管理
人事处可以对教职工的基本信息和扩展信息进行维护和管理,也可以进行相应的设置,具体服务包括教职工基本信息管理、教职工扩展信息管理、教职工信息检测、教职工管理授权、教职工信息归档、教职工快照设置和教职工快照查询、教职工身份转换等。
教职工基本信息管理:人事处可对全校所有教职工信息维护管理、导入查询和批量维护,包括基本信息、在校信息、资质信息、岗位职务信息和通讯信息等。
教职工扩展信息管理:人事处可对教职工扩展信息进行统一和批量维护和管理,包括教职工过程信息子集如下:
1) 工作经历:可逐条维护教职工曾经的参加工作时间、工作单位、曾任职务等工作履历信息,可批量导入和导出;
2) 学习经历:可逐条维护教职工学历、所学专业、入学时间、毕业时间、毕业学校、取得学位、取得学位时间等学习经历,支持证书附件上传、在线预览和下载,可批量导入和导出;
3) 家庭成员:可逐条维护配偶、子女等家庭成员的单位、出生年月、职务等信息;
4) 岗位信息:可逐条维护教职工的曾任岗位信息,包括岗位类别、岗位等级、聘任起止时间等,可批量导入和导出;
5) 职称信息:可逐条维护教职工曾经获得过的职称信息,包括获得评定职称、评定职称等级、职称评定时间、聘任职称、聘任职称等级、聘任职称起止时间等,支持证书附件上传、在线预览和下载,可批量导入和导出;
6) 党政职务:可逐条维护教职工的曾任党政职务信息,包括职务名称、职务级别、任职年月、任职单位等,可批量导入和导出;
7) 政治面貌:可逐条维护教职工的政治面貌信息,包括政治面貌、参加党派日期、参加时所在单位等,可批量导入和导出;
8) 工人等级:可逐条维护教职工曾经获得过的工人等级信息,包括工人技术工种、工人技术等级、评定时间、聘任工人技术等级、聘任起止时间等,支持证书附件上传、在线预览和下载,可批量导入和导出;
9) 奖励情况:可逐条维护教职工曾经获得过的奖励情况,包括奖励名称、奖励级别、获奖日期等,支持证书附件上传、在线预览和下载,可批量导入和导出;
10)惩处情况:可逐条维护教职工曾经收到的惩处情况,包括惩处名称、惩处日期、惩处单位、惩处原因等,可批量导入和导出;
11)海外研修信息: 可逐条维护教职工曾经的海外研修信息,包括起止时间、研修(访学)机构名称、国家(地区)、项目名称等,可批量导入和导出;
12)语言能力:可逐条维护教职工所掌握的语种信息,包括语种、语种熟练程度等,支持证书附件上传、在线预览和下载,可批量导入和导出;
13)其他技能:可逐条维护教职工所掌握的其他技能信息,包括其他技能名称、其他技能熟练程度等,支持证书附件上传、在线预览和下载,可批量导入和导出;
14)证书信息:可逐条维护教职工所获得的证书信息,包括证书类型、证书名称、发证年月、发证单位等,支持证书附件上传、在线预览和下载,可批量导入和导出;
15)社会兼职:可逐条维护教职工曾经做过的社会兼职信息,包括社会兼职名称、起止时间等,可批量导入和导出;
16)学术团体兼职:可逐条维护教职工曾经做过的学术团体兼职信息,包括学术团体名称、起止时间、学术团体级别、兼职职务等,可批量导入和导出;
17)教师资格信息:可逐条维护教职工获得的教师资格信息,包括教师资格证号码、任教学科、证书颁发日期等,支持证书附件上传、在线预览和下载,可批量导入和导出;
教职工管理授权:对各角色的查看权限、维护权限、必填权限等进行设置,比如一个应用分别对人事处角色和普通教职工角色进行权限的设置和授权,可分别设置不同的维护权限、查询权限和是否必填,还可针对教职工修改哪些字段后需要审核进行设置。
教职工信息归档:可对教职工信息进行归档,可设置归档的时间和规则,人事处可对过去任一时间点的数据进行回溯归档,对相关的查询统计提供依据。
教职工快照设置:设置教职工快照信息的生成时间和规则等。
教职工快照查询:根据设置,系统会定期生成教职工快照信息以达到信息备份的目的,教职工快照信息同时为事业单位报表统计和高基报表统计提供数据依据。
教职工身份转换:教职工身份发生变化时,可以实现职工号和用人方式的身份转换,比如人才派遣人员转换为人事代理人员,可以使用新的职工号和用人方式,原教职工基本信息、工作经历、学习经历、家庭成员、岗位信息、职称信息、党政职务、政治面貌、工人等级、奖励情况、惩处情况、社会兼职信息和学术团体兼职等相关基础信息将同步关联到新的职工号。并且身份转换会留存转换历史记录。
5.2 教职工考勤
可对教职工考勤方案设置、考勤信息院系上报、考勤审核管理等,通过移动终端进行考勤查询服务。教职工可以的手机端进行考勤定位打卡,查询个人历史的缺勤记录,院系可以按月查询所管部门的缺勤明细情况,人事处可以按月查询全校各部门的缺勤明细情况。
6 业务集成
投标人须完成学校现有业务系统集成,具体包括对学校现有的应用系统进行界面、身份认证和数据的集成。通过把各应用系统集成到网上办事大厅,并由统一身份认证平台完成各应用系统的身份认证,既便于用户使用其权限下的应用系统,也便于系统管理员对用户权限、系统安全的统一管理。同时通过统一数据中心平台,对各个应用系统整合,对其数据进行抽取、清洗、转换、储存等措施,消除学院以往建设中存在的“信息孤岛”和“数据孤岛”,实现各应用系统数据信息的统一管理与共享。
本次一期建设内容的智慧校园支撑平台为学校对接所有现有第三方业务系统包括但不限于教务、OA、科研、财务、资产、图书馆、一卡通、企业微信、邮件、短信平台、网站群、平安校园、微信公众号提供数据接口服务,投标人须承诺在项目建设过程中及质保期内始终免费开放系统接口,并免费完成学校现有及质保期内待建业务系统与智慧校园平台的身份和数据的集成工作。质保期后,不得以任何不正当的理由拒绝与学校新建业务系统进行集成对接,双方可根据接口集成的工作量另行协商签署合同。
7 工程实施服务要求
7.1 时间进度要求
本次项目须严格按工期部署完成,并达到采购人的要求。本项目要求在合同签订后180 天内完成项目系统建设并交付使用。投标文件中须提供针对本项目的预实施工期进度表,否则视为无效投标。
7.2 实施方案
7.2.1组织架构与职责1、须提供项目经理一人,负责全程跟踪项目的开发与实施,直至该项目验收,该项目经理应具备高校数字化校园基础平台及应用系统(基础平台、门户平台、主数据管理平台、身份认证平台等)项目成功开发实施经验。
2、项目组其他实施人员应满足项目开发和实施的需要,项目组成人员应不少于2 人,具备数字化校园相关开发和实施经验。
7.2.2实施阶段划分投标人须描述各个实施阶段的工作范围、内容、人力投入、过程、责任、交付成果等。
7.2.3项目管理要求投标人须提出对项目的建设进行科学严格的管理方案与措施,保证项目全面顺利实施。
7.2.4项目配置管理在项目的建设过程中以及交付使用后,会产生大量文档和程序,且文档的版本在不断变迁和修改中。投标人须提供相应的项目配置管理系统,维护产品的历史、鉴别和定位产品版本、在产品开发和发布阶段控制变化,制定规范的配置管理工作计划和流程, 沟通交流配置管理工作情况,使管理制度化、减少重复性工作、保证产品的质量和效率和系统的后续升级和维护。同时需承诺会对项目实施过程中产生的各类数据(包含记录、报告等)进行保密,不能外泄。
7.2.5项目管理规范和手段根据项目的实施方案,在实施过程中,为了保证用户方、开发方等各方能够对项目建设实施进行监控,及时发现和解决的问题,投标人必须建立相应的项目管理规范,使管理和监控工作流程化、规范化,管理和监控工作责任明确。
7.2.6风险管理项目风险管理是对项目风险从识别到分析到应对措施的一个过程,包括风险识别、风险量化、风险对策、风险对策实施控制四个方面。项目在实施过程中会出项各种各样的风险,必须做到充分、有效识别风险,应对风险和控制风险,投标人须提供风险管理方案,制定风险预测和规避风险的对策。
四、交付时间和地点:
(一)服务完成时间:在合同签订后180天内完成系统建设并交付使用。
(二)服务地点:采购人指定地点。
五、服务标准:
(一)综合运维服务
高效全面的综合运维服务是确保平台安全稳定运行的根本。平台综合运维服务需包括相关软硬件部署、系统安装和调试、项目培训以及平台交付及后续技术支持和现场服务等。
(二)现有数据迁移与存储
本次一期建设平台要考虑我校原有数据情况,将有效的整理学校现有各业务系统数据,将各业务系统数据进行综合考虑,统一做好数据整理与迁移,统一在数据资产管理平台进行存储备份,保证我校数据的唯一性。
(三)质保期
本项目建设内容供应商至少提供原厂3年免费质保及服务。
质保期内,需提供7*24小时线上服务,提供定期产品使用质量回访服务外,须提供如下服务(但不限于):对系统巡检和BUG进行修复,系统环境调整的文档更新,微服务流程修改,使用过程中的问题接单,服务器临时启停服务,对运行过程中访问报错问题进行处理,对使用过程中数据错误问题进行处理,实施数据备份服务和数据容灾演练恢复。
质保期外本次采购供应商也需提供7*24小时线上服务,并提供定期产品使用质量回访服务,质保期外供应商需提供每1个季度不少于1次在现场进行的巡检服务,及时发现和排除潜在问题和故障隐患,保证系统的稳定运行。
(四)技术支持
根据系统运行的环境要求和安全考虑,制定适当的系统维护、网络安全、系统使用等相关的操作规范等,并指定对应负责人。
需设有售后技术服务部,并提供专人提供5×8小时(即每周5天工作日,每天8小时)的技术咨询服务,提供经验丰富的程序员解答用户的各种问题。
(五)定制化服务
一期项目所建内容供应商需满足我校在质保期内的定制化开发的需求,对一期建设内容的相关软件的系统功能(界面与应用层),根据学校各业务部门需求进行二次开发,不得另外收取费用。
(六)驻场服务
本项目需提供为期1年的专人驻场人员(不少于3人)服务,驻场人员对平台软件及硬件要有着充分的了解,具有丰富的运维实施经验。服务人员需相对固定,若有变动,需提前一周通知校方并征得校方同意。
对于任何运行中软件或硬件进行修改或维护,服务人员需严格填写维护记录单,并由校方签字确认后进行相应的修改完善。
(七)日常运维
为确保本项目的服务质量,需要严格遵守质量控制标准,并应用在项目服务的各个阶段。
六、验收标准:
(一)本项目按照《关于进一步规范政府采购项目履约验收工作管理的通知》(长财采购[2016]6号)文件要求进行验收。
(二)项目验收国家有强制性规定的,按国家规定执行。
七、其他要求:
(一)付款方式:
1、付款人:长沙卫生职业学院(通过国库集中支付)
2、付款方式:
(二)本项目采用费用包干方式,供应商应根据项目要求,详细列明项目所需的设备购置和材料费用(如有),以及人工、管理、财务等所有费用,如一旦成交,在项目实施中出现任何遗漏,均由中标人免费提供,采购人不再支付任何费用。
(三)知识产权
本项目开发过程中新产生的知识产权全部归长沙卫生职业学院所有。
中标人须保证系统的开发不侵犯任何人的权利。如系统开发过程中或系统包含的任何知识产权侵害任何人的权利,中标人应负责并使采购人免责,包括但不限于使采购人免于参与或处理相关纠纷,赔偿采购人产生的任何实际损失。
(四)人员培训
中标人应按采购人指定负责培训后台操作管理及维护人员,达到熟练掌握产品性能,能独立完成对系统的维护更新、能及时排除一般故障的程度。
(五)本项目中标人不得以任何方式转包或分包给第三方,如被采购人发现,采购人有权取消其中标资格。
(六)投标人须保证所提供的证明材料真实有效,如发现造假,取消其中标资格,所造成的后果均由中标人承担。
(七)投标人在投标前,如须踏勘现场,有关费用自理,踏勘期间发生的意外自负。
采购需求仅供参考,相关内容以采购文件为准。
(一)项目背景
本项目围绕我校智慧校园基础平台进行建设,充分利用信息化先进手段,辅助我校实现高效管理,提升我校管理与服务水平。此次智慧校园基础平台建设以我校门户为依托,通过高效采集、有效整合、并基于开放的信息化模式下,转变信息化建设思路,构建基于PC与移动相结合的服务管理新模式。提供在一站式办事大厅中,满足业务办理、流程审批、信息查询等综合性服务平台,并借助此次智慧校园基础平台的信息化建设提升我校技术基础架构,并从业务开展和流程执行的层面实现全校部门间的数据融合,消除信息孤岛,做到让各业务部门多种业务、同一来源,让终端用户一次填报,重复利用。彻底解决学校各部门数据不统一、用户反复填报数据等的问题。本次项目的建设,一是需要对我校基础支撑进行完善、实现互联网的无感对接,提升校内数据质量。二是实现身份的统一管理,解决身份的单点登录及安全审计问题;三是丰富校内师生服务,梳理跨部门、跨流程,建立用户真正需要的服务,提升用户信息化体验,解决用户使用最后一公里的问题。
(二)项目需求
1、完善身份互联建设:通过本次项目建设,在我校建成一套符合高校使用需求的校园身份互联平台,完成我校各类业务系统的身份对接,解决单点登录、用户管理、认证授权、认证审计等一系列问题。
2、实现校务服务事项数据共享:打破信息孤岛,实现数据共享,组织数据来源部门编制校务服务数据目录,推动学校行政办公、财务管理、学生工作、教学管理、科研管理、后勤服务等各部门建立数据仓,不断充实校务服务大数据。
3、推进校务服务事项流程优化:优化办事流程,进一步减少前置条件、精简办事材料、缩短办理时间,有效避免师生在办事过程中重复填写表单和重复提交证明。
(三)技术路线
1、本项目软件运行平台和应用系统均可运行于Linux、Unix、Windows等高安全性操作系统。开发技术应采用J2EE标准、组件技术及在数据交换上对XML的支持,使系统功能最优化,同时将整体系统内部在技术上的相互依赖性减至最低。
2、本项目软件基础运行平台和应用系统均要求采用B/S结构,采用Java编程语言和服务器端Java技术进行开发,应用程序开发与运行结构要基于统一的技术开发平台的三层架构,即Web服务器、应用支撑服务器和数据库服务器。且必须基于Oracle 11g或以上版本。
3、采用面向对象的组件技术,着重于开发构成应用程序“业务对象”的可重复使用的组件,利用这些组件顺利地建立分布式应用程序。各应用系统要基于多层架构和组件技术进行构建,做到系统结构层次清晰。
4、所有应用逻辑、流程、数据等都应当能够根据建设方要求的颗粒度进行封装,能完全实现跨业务部门的业务流程和相对应的细颗粒度的分级授权体系,且保障优秀的易用性。本次项目建设过程中,要保证此项目后期的可持续服务能力及外部接入的开放能力。
5、本项目软件平台所有运行的组件支持容器化部署。系统平台实现从源代码到交付件过程全自动部署,从交付件到部署环境的过程是可重现的,升级过程可以一键完成。
6、本项目软件系统需支持分布式架构,处理节点支持水平多点扩展,系统必须支持负载均衡,支持动态监测负载状况,自动对可用资源进行并发检测,调整和分配等功能。
7、本项目软件系统平台的接口体系需支持 OAuth2.0 协议,实现基于用户个人授权的安全模式。为保证系统运行的稳定性与安全性,本项目如有涉及中间件产品,需采用主流的、成熟的商用中间件产品。所有组件符合微服务架构模式,并提供完善的 API,且可以由OAuth 等机制保障其开放性和安全性。
8、一站式流程服务平台所有组件兼容原生的Kubernetes及其生态,比如支持Prometheus监控、日志等各种第三方云原生工具栈。支持实时数据备份,支持云存储及非结构化数据存储,容量无限扩容。
(四)安全要求
1、认证授权:保证用户的合法性和用户使用信息资源的权力,避免内部敏感信息泄漏和服务所提供的信息资源被非法访问,造成严重的安全事件。
2、信息保密:充分利用密码技术,对于需要保密的信息,采用密码技术进行加解密处理,防止信息的非授权泄漏,确保涉密信息在产生、存储、传递和处理过程中的保密。
3、数据完整性:建立数据完整性检验机制,保证收发双方数据的一致性,防止信息被非授权修改。
4、审计:记录应用日志,对事件进行分析,并能提供预警信息。
5、数据备份:利用数据库的备份功能将建设的平台和系统数据备份到指定的服务器或存储系统上。
6、要求投标人从物理安全、网络安全、中间件安全、系统安全、应用软件安全、用户安全、数据安全等几个方面提出配套的安全体系完善方案,以便防范安全风险。
二、相关标准:
符合国家、行业相关标准及规范要求。
三、技术规格:
(一)建设清单
投标人可提供同等档次或更高档次产品和服务,并提供相应文件证明其符合或优于采购需求,各项建设内容要求见详细技术参数要求。
序号 | 建设内容 | 数量 | 单位 | 质保期 | 是否需要技术支持资料 |
1 | 一站式网上办事大厅 | 1 | 套 | 3年 | 是 |
2 | 统一身份认证平台 | 1 | 套 | 3年 | 是 |
3 | 数据管理平台 | 1 | 套 | 3年 | 是 |
4 | 微服务建设 | 25 | 个 | 3年 | 是 |
5 | 人事应用 | 1 | 套 | 3年 | 是 |
6 | 业务系统集成服务 | 若干 | 个 | 5年 | 是 |
(二)详细技术参数及要求
1 一站式网上办事大厅
1.1 融合服务大厅建设要求
1.1.1 融合服务大厅l 校园门户
为师生用户提供查看学校各类信息资讯、新闻、通知公告和系统直通车的统一门户。
支持个性化界面, 投标方需提供多套不同主题风格的界面模板供学校选择,页面模板支持两列和三列布局,并不同尺寸、不同内容的卡片组成页面的内容,学校可根据自身的要求配置整体配色、校徽、Tab页标题、头图等内容。门户平台需提供开放能力支持根据学校的个性化需求设计界面。
丰富的内容卡片: 提供丰富的标准内容卡片库,供学校选择使用来支撑信息门户内容展示。
系统直通车:需支持灵活添加业务系统,并支持授权不同角色的用户,用户只能看到自己有权限的系统。
新闻资讯聚合:需支持接口、数据库、网页抓取方式将学校公文、部门通知、校内新闻等内容集成在新的校园门户中。
l 办事大厅
需为学生、教职工、单位办事不同角色的用户提供按照不同的办事主题和办事部门对外提供办事服务,既包括线上可办理的信息化服务,也包括在线下办理的事项清单,让师生及游客对校内办事清单有详细的了解,包括办理部门、办理地点(地图的形式体现)、办理时间、部门电话、所需材料、常见问题等。
首页:需包含对事项的搜索功能、整体导航,在线服务的最近使用以及办事大厅的简要统计。
分角色目录页:需针对学生、教师、游客分别提供分角色目录页,支持按照事项主题、事项部门、标签的查找,以及对具体事项是否有在线办理的筛选。
事项详情页:对某一事项的具体描述页面,描述内容需包含事项名称、责任部门、服务部门、前置条件、服务内容、业务周期、内容标签、办理须知、所需材料、办理时间和地点、咨询电话和常见问题等;
针对有在线办理的事项需提供“在线办理”按钮进行跳转。
搜索: 能基于AI智能引擎,支持根据用户输入的关键词匹配事项名称、事项内容、应用名称以及常见问题中的关键词进行综合搜索。
个人中心:包含用户个人在办事大厅中的办件以及意见反馈。
l 工作台:
需为全校涉及业务管理类、行政审批类用户提供快速、方便、高效的工作页面,只显示跟自己工作相关内容,预置已经分类完成的管理服务目录,我的收藏,任务中心统一处理待办任务入口,不需要登录到各个系统中办理,提高办事效率。
l 责权公示
需提供符合学校要求的职责清单、审批清单、责任清单管理后台,能够根据不同的部门填写职责、并对每个职责关联服务事项,在前台统一展示。
l 我的收藏
提供应用收藏功能,用户可将自己经常需要使用的应用添加到收藏夹。在个人中心页面有我的收藏模块,用户可以更直接方便的获取到自己收藏的应用。
l 意见反馈
提供用户问题反应渠道,用户可填写反馈意见或建议。为用户提供意见反应渠道,搭建用户与管理者之间的网络沟通桥梁,管理端根据获取的意见可及时做出调整并回复用户处理结果。
l 服务评价
提供用户对服务事项、办结的流程进行满意度评价,将自己最真实的使用感受分享给其他用户、反馈给应用管理员。用户使用应用前也可以通过查看其它用户对该应用的评价,作为应用选择的依据。应用管理员可以查看来自用户的应用评价,为进一步优化升级应用提供参考依据。
l 消息提醒
应用程序能调用消息中心接口,将提醒消息推送到服务大厅中分类展示,并显示消息的查看状态。
1.1.2 移动服务大厅支持一站式服务大厅前台使用移动端浏览器访问,内容与PC端一致,提供专门的移动端卡片和管理支撑能力,包括校内门户、办事大厅两部分内容。支持集成到企业微信、钉钉、微信公众号。
l 校内门户
包括个人数据、校内新闻、通知公告、校内发文、待办通知、最近使用服务、通知公告、业务直通车等;
l 办事大厅
用户可搜索服务事项,并可根据学生、老师、游客不同角色分类展示学校内部各个部门所提供的办事指南,办事指南包括事项名称、责任部门、服务部门、前置条件、服务内容、业务周期、内容标签、办理须知、所需材料、办理时间和地点、咨询电话和常见问题等,并可在办事指南中关联在线应用、提供咨询、评价等服务;展示个人办事详情,包括正在办件,已完成办件,待办任务,我管理的事项;提供办事大厅运行数据展示,包括当前进驻事项、可在线办理事项、当前正在办件、已完成办件、累计服务师生数。
支持企业微信、钉钉、微信公众号等移动终端对接方式。
1.2 平台服务能力需求
1.2.1 应用管理中心需支持对接入应用的多终端(PC、移动校园、微信端)发布、上架、下架管理、权限管理能力,实现一处发布多终端使用;支持对前台大厅统一管理与配置,大厅模板管理、卡片配置管理以及其他内容配置能力。
管理:包含分配业务域、分配应用管理员、编辑、网页端和移动端应用的上线和下线设置;
配置:配置项包括属性、授权、开放时间、维护时间。属性中包括服务场景、服务角色、服务类别、服务方式、应用属性配置、推荐周期设置、应用可见性设置、应用详情设置。
1.2.2 事项管理中心l 服务事项管理
需支持对事项清单进行全生命周期管理,建设学校统一事项清单库。
事项审核:需支持校级管理部门对业务部门申报的服务事项进行审核,审核通过后,可对事项进行配置。
事项配置:需支持管理员对审核通过的事项进行应用配置、标签配置、可能问法配置。进行应用配置时可直接查询线上服务大厅上的所有线上服务列表,直接点击关联,无需配置其他信息。
事项发布:事项审核完成并进行相关配置后,需支持管理员对外发布,师生可在办事大厅中查询该事项。
事项查询:需支持事项库的多维事项查询,包括事项类型、职能部门、服务类型、起止时间等,显示各类事项的查询结果,并可以导出事项清单。
需支持服务事项字段自定义,除了产品标准提供的填写字段以外,用户还能自定义符合本校的字段并能编辑字段名称、内容显示、是否必填等。
l 服务字典表管理
需能对服务主题和服务部门的增删配置操作,用于支撑线上服务大厅的模板前台的内容。
l 事项管理员维护
支持针对部门指定业务管理员,用于将服务事项维护的权限下放,某个部门下的业务管理员能够对此部门为责任部门的服务事项进行维护。
l 任务中心
各类应用服务通过任务中心对外开放接口对接任务中心,将服务内部产生的任务信息推送至任务中心,使用户能够在服务大厅统一处理待办任务、已办任务。
待办任务:师生能够在任务中心中查询当前自己所有的待办任务,并能根据接收时间、任务来源、紧急程度、任务类型进行筛选,并能够点击单条任务跳转至对应的应用。
已办任务:师生能够在任务中心中查询自己所有的已办任务,并能根据任务名称进行关键字搜索,以及根据处理时间、任务来源、流程状态进行筛选,可以查询到已办任务。
当前所属流程的状态以及流转记录。针对流转记录,用户可以查看到此流程经历的每个节点名称、处理人、处理意见、处理结果、接受&处理时间以及耗时。
我发起的:师生可以在任务中心中查看自身在所有的系统中发起的流程,能通过流程名称进行关键字搜索,并能根据发起时间范围、任务所属来源以及流程状态进行筛选;针对某个流程,师生可以点击跳转至应用内部、查看此流程的流转记录以及对当前办理人进行催办。
1.2.3 流程中心l 流程设计
投标方需提供一套遵循BPMN2.0规范的流程执行引擎和服务引擎来执行流程和流程所定义的服务。可以执行基于BPMN2标准的业务流程模型,包括执行人工任务以及各种事务型服务。提供流程定义与执行语言完全遵循国际标准的流程执行语言BPMN2.0。
需采用业内通用并符合BPMN2.0标准的Activiti流程引擎。
需支持可视化流程设计,支持在Web 页面采用拖拽方式设计流程;按照BPMN 流对象与类型进行设置。
需支持多种流程模式,至少包括顺序、分支、并发、子流程、条件路由、并行会签、串行会签等流程
需支持支持多种流程操作权限,至少包括提交、退回、追回、转办、终止、催办、加签、跳转、挂起。
需提供丰富的任务节点类型,至少包括单人活动、多人并行、多人顺序、多人单一几种类型。
需支持多种办理人设置方式,支持按照人员、部门、用户组、岗位方式设置流程节点办理人;
需支持多表单设置,在不同流程节点设置不同的表单,每个流程节点上面支持PC、移动表单,系统自动根据访问终端属性定位到PC或者移动表单。
需支持人工选择下一步分支环节,并可配置这项功能在哪个环节启用;
需支持人工选择下一步处理人,并可配置这项功能在哪个环节启用;
需支持配置判断分支条件,根据登录人的基本信息和业务字段信息,进行AND OR 布尔表达式进行逻辑判断。
需支持多版本管理,支持将修改后的流程保存为新的版本,旧的版本可恢复。
l 流程分析
提供流程分析功能,帮助管理人员分析工作流状态,定位工作瓶颈,改进工作流程,提高工作效率。
支持服务状态统计,如驳回数、挂起数、终止数、办结数;
支持统计展示服务次数、办理次数的Top10服务清单;
支持按时间统计流程发起数、办理次数;
支持统计所有已发布的流程服务的发起数、办结数、办理次数、办结率、平均耗时、最短耗时、最长耗时;
l 流程干预
需支持异常流程查询、干预功能,当异常流程或当前环节处理人无法处理时,服务管理员直接将流程转办、挂起或终止。
需支持对流程实例进行挂起、激活、终止、办件取回、删除和查看流程状态。
需支持对流程运行的任务进行人工干预,如提供处理、转办、跳转功能。
需支持对不同版本的流程进行再设计、激活、下载流程图、启动等操作。
1.3 管控中心
l 新闻资讯聚合
需提供URL网页抓取、接口、数据库方式集成新闻资讯,聚合到线上服务大厅、移动端中展示。
URL业务抓取方式,支持URL方式抓取某个网站中的信息,采用可视化的方式选择抓取区域,并将信息内容保存到校园门户中,可以设置抓取的内容是否保留原样式。
接口方式聚合,需提供开放接口,第三方应用程序将新闻、资讯、公告实时推送到校园信息门户中
数据库方式聚合,第三方应用程序提供新闻、资讯、公告的只读权限数据表或视图,新闻资讯聚合模块定时从数据库中同步差异的增量数据。
l 大厅内容管理
直通车管理
需提供可以在桌面呈现并授权的业务直通车卡片配置功能,将不同的碎片化服务组织放置在桌面卡片中并授权,业务直通车卡片支持一级分类和无分类两种场景。
本地卡片库, 平台内置常用的内容卡片库,支持将卡片添加到不同的模板中使用,卡片可设置用户使用权限,用户只能看到自己有权限的卡片。平台提供开放接口及卡片开发标准规范,可根据学校实际需求开发新卡片,可视化方式配置卡片尺寸单列、双列。
至少提供任务中心卡片、最近使用卡片、Banner卡片、通知公告卡片、业务直通车卡片、个人数据卡片、链接导航卡片。其中业务直通车卡片能够根据在系统配置好的业务直通车内容进行显示,支持最多一级分类。
模板库管理,平台需默认提供多套模板,管理员可以选择启用某个模板,平台需明确开发能力及模板制作规范,支持自定义模板。
责权公示管理,需支持按部门分别维护责任清单、审批清单、职责清单,需要支持对每个责任清单关联系统中已经梳理好的服务事项中。需支持按部门名称、清单类型、办理类型查询责权公示
个人提醒管理,需提供用于用户的个人提醒信息配置功能,包含邮箱、一卡通余额等基础信息,邮箱已经内置了主流邮件厂商,例如:腾讯、coremail、亿邮等的集成。
l 大厅展示配置
针对线上服务大厅移动端、线上服务大厅PC端以及可能产生的拓展模块内容进行展示方案的管理,不同的展示方案可以授权给不同的用户组使用。
1、校园门户展示配置
需支持创建多个校园门户展示方案,并可视化方式设置门户布局。
页面容器管理:需支持在页面中添加单列、双列的容器,可以拖动容器位置,并在容器中添加卡片内容。
展示方案授权:需支持将不同的展示方案授权给不同角色的用户,实现不同的用户看到不同的门户内容。
展示方案启停:需支持管理员可启用、停用多个展示方案
2、自定义页签
服务大厅具备融合开放能力,支持扩展TAB页签,支持将应用程序页面集成到服务大厅的导航菜单中或者嵌入到服务大厅中,使其成为一个整体。
l 应用版本管理
提供应用的升级、版本下载、部署地址设置功能。
支持批量下载同一类型的应用包,进行安装部署。
支持选择应用的各个版本进行下载,下载后的包用于应用的升级更新。
支持选择版本对应用进行升级,系统自动推送应用是否升级的信息。
支持配置应用部署前缀,提供测试连接。
l 缓存管理
基于Redis缓存管理机制,支持多服务器间的缓存共享。该模块提供界面化的缓存管理功能,管理员可随时查看平台自身的缓存情况,并可根据实际情况进行缓存的清理。
l 平台版本管理
提供平台的更新说明、当前版本以及依赖关系查看、历史更新记录功能,功能如下。
l 系统管理员维护
超级管理员可以维护系统管理员名单,拥有系统管理员权限的用户可操作管控台中的所有模块。
l 业务域管理
为系统管理员提供业务域配置功能,支持把应用分配到业务域可以更方便的进行应用的管理。业务域管理包括业务域的新增、编辑、删除,并可对域管理员进行设置。
l 意见反馈管理
收集并展示用户前台对线上服务大厅模板中的意见反馈,管理员能够回复或忽略用户的意见反馈内容。
l 用户组管理
根据用户的角色、职责进行分组,管理同一属性应用群体的应用使用权限。有效的用户组管理是做好应用主动推送的第一步。同时管理端可以清晰的了解到业务域下的用户组和具体应用的授权关系。用户组管理提供用户组的新增、编辑、删除功能。
每一个用户组可设置该用户组的用户组名称、所属业务域、用户组描述、组内用户、应用权限。
用户组内的成员管理可提供静态、动态两种形式的管理。解决了不同的业务场景下对用户授权的管理需求。静态组用于固定群组的管理,例如在校生、实习生、教职工等;动态组用于人员变动较快、及时性较高的群组的管理,例如临时人员等。
l 操作日志
管理员能够通过操作日志功能查询近期平台管理员对当前平台的配置的操作,针对不同的操作模块和时间都能进行查询。
2 统一身份认证平台
2.1 身份管理要求
1、用户数据模型
支持按照学校特点和应用现状设计用户、组、权限等模型,并按照模型设计完成数据存储。所有的用户信息应分别存放在LDAP目录服务和数据库中,通过可靠的机制完成两者的同步,用户身份信息在目录服务中以层次结构,面向对象的数据库的方式集中存储管理,从而保证身份数据的一致性和完整性,为校园各类应用提供一致的用户信息访问。
支持设置用户身份类型,方便平台和硬件平台、应用系统等通过LDAP接口的方式实现身份集成。
2、用户管理
系统至少内置教师、学生、校外人员、校友四种基础用户来源,在教师与学生分类下允许用户在基础来源类型下创建自定义类型。
提供具有高校特色的组织机构管理,支持针对不同用户类型生成不同的组织机构树。组织机构树由用户信息自动生成。
系统允许针对不同的用户来源创建至少三种生命周期,包括未入校、在校、离校三个状态。系统应能自动创建对应生命周期的用户组。同时应能对生命周期设置有效期,在有效期到期后,自动转换生命周期状态。投标方需在投标文件中提供真实系统截图。
需支持管理员对全校用户身份帐号数据的增加、删除、修改、过期设置、锁定、解锁等操作。在进行导入用户操作时,可实现拥有多账号的用户自动绑定,无需管理员手工干预,系统自动判定导入账号是否归属同一人,若为同一人不同阶段账号,则系统自动创建自然人,同时完成账号绑定。投标方需在投标文件中提供真实系统截图。
3、应用管理
提供校内身份类型组的管理功能,用于区分用户的身份类型,为校内应用提供资源级授权。
系统同时也应提供微信公众号的配置功能,支持配置多个公众号与平台集成。
4、外部通讯录同步工具
需支持将身份认证系统内的通讯录数据自动同步到企业微信/钉钉,同步内容需包括组织机构及人员信息。在组织机构发生人员异动后,需支持对企业微信/钉钉通讯录进行人员同步。系统需提供配置功能方便管理员新建多个同步任务,同步任务需支持配置同步名称、启用状态、同步类型、同步周期、同步用户分类。投标方需在投标文件中提供真实系统截图。
5、安全中心(登录统计、安全工具)
系统需提供系统安全运行看板,管理员可按照不同时间段,查询系统登录信息,包括尝试登录次数、成功登录次数、失败登录次数、拦截恶意登录,并提供相关的趋势变化图。
系统需提供安全配置功能,管理员可配置密码策略、验证码策略、激活策略、安全问题策略、找回密码策略、人脸识别方式、完善资料策略。
6、帐号元数据管理
系统需支持帐号元数据管理,支持扩展字段满足学校人员信息管理要求。新增自定义字段信息需包括属性名称、LDAP属性名称、显示名称、属性值类型,属性描述,支持设置是否必填、是否显示;需支持管理员配置系统预置元数据的展示/隐藏属性。投标方需在投标文件中提供真实系统截图。
7、登录主题配置
需支持配置多个登录主题,管理员可切换不同的的管理页面;支持上传\下载多个登录主题包。投标方需在投标文件中提供真实系统截图。
8、日志中心
日志中心需支持查看用户操作记录、用户认证记录、管理员操作记录,支持按照认证帐号、认证帐号、操作时间段查询用户认证记录;支持按照操作者、操作对象、操作IP、操作类型、操作时间段段查询用户操作记录;支持按照管理员帐号、登录IP、操作时间段查询管理员操作日志。
9、API接口管理
系统需预置API接口服务,接口应包含普通用户修改密码接口、查询用户属性接口、修改用户属性接口、管理员修改密码接口、根据用户信息创建TGT接口、获取用户详细信息接口、获取st接口;同时提供相关接口的接口发布地址、接口提供地址、提供者;支持对相关接口进行启停操作,管理员也可自助注册其他API接口,并授权第三方应用使用。
提供统一的API网关服务,将系统中的接口在统一的出口向用户提供,同时提供API鉴权等能力。
10、系统应支持配置一种或多种高校常用的消息通道,至少包括阿里云短信、微信企业号、邮件、消息总线,支持配置消息频次,包括消息发送间隔,单个用户每天发送上限。提供可视化的配置页面配置消息总线,配置内容需包括消息发送URI、消息标签、应用ID、应用的凭证密钥、网关域名。投标方需在投标文件中提供真实系统截图。
2.2 统一认证要求
系统需支持高校常用认证协议,可对接各类WEB应用、移动APP、企业微信、钉钉,满足师生访问校园各类系统的需求,提供认证凭证的不可逆安全存储机制,保证密码安全。提供认证过程的安全性保障,保证认证过程凭证安全。具体要求:
1、需提供身份认证基础服务,实现SSO单点登录功能。支持用户登录后在不同系统之间漫游而不需要再次输入密码。平台需能同时支持学校移动应用客户端的统一身份认证集成,需能支持短信动态验证码的验证方式。需提供密码变动短信通知功能。对安全级别要求较高的系统,需提供特殊系统二次登录设置功能。
2、为实现统一认证和单点登录提供接口和通道,可以支持跨平台和各种开发语言的应用系统接入平台,如目前学校各类应用系统所使用的ASP、.NET、JAVA、PHP、Python等多种开发语言;平台需使用CAS5.3或以上版本认证内核,支持的标准至少包括CAS 1.0、CAS2.0、CAS3.0、LDAP。同时还需提供一种为移动APP专用的对接协议。
3、系统需支持在发放帐号密码时支持无密码自助激活方式。要求提供帐号激活服务支撑无密码自助激活方式,激活流程需包括信息校验、绑定手机、绑定邮箱、设置密码、激活完成五部分。投标方需在投标文件中提供真实系统截图。
4、系统需支持基于Nginx的反向代理集成方式,集成接入方式简单,接入系统可以直接从标准的Header中获取登录人员的相关信息,适用不同的开发语言。
5、提供系统级缓存,允许平台调用,加快平台访问速度,同时提供DBLESS能力,在系统遭遇数据库停机时,依然可向用户提供基础认证及鉴权能力,避免因数据库停机造成身份认证不可用。
6、需提供对全校身份认证相关数据的管理功能,包括应用认证分析、使用用户分析、帐号变动该分析,具体要求如下:
应用认证分析支持一段时间,或者快捷查询今日、昨日、近7天、近30天、近90天的应用认证次数排名,以柱状图的方式由高到低排列展示排名前10的应用;提供应用认证次数列表,按照认证次数由高到低的顺序逐行展示认证应用。投标方需在投标文件中提供真实系统截图。
使用用户分析支持一段时间,或者快捷查询今日、昨日、近7天、近30天、近90天的使用用户排名,以柱状图的方式由高到低排列展示排名前10的用户;提供使用用户列表,按照认证次数由高到低的顺序逐行展示用户使用用户的帐号。投标方需在投标文件中提供真实系统截图。
帐号变动分析支持一段时间,或者快捷查询近7天、近30天、近90天的帐号变动情况,以柱状图的方式的方式展示查询期间帐号变动情况,对于每日新增次数、修改次数、删除次数采用不同颜色的柱状体进行展示。投标方需在投标文件中提供真实系统截图。
2.3 自助服务要求
要求系统需在PC端、移动端提供自助服务功能。自助服务需支持中英双语切换。
具体要求如下
1、系统需为校内的最终用户提供面向个人身份自助服务,用户可自行维护个人资料,设置个人帐号,保护登录密码、安全问题、登录别名、邮箱、手机号。
2、系统需支持用户查询各类认证记录,包括当前登录记录、帐号认证记录、密码维护记录、应用访问记录。
3、对于学校拥有多个身份账号的用户,系统需支持用户可以自行设置其中一个帐号为默认帐号。若用户使用手机号/邮箱进行登录时,系统应认定用户本次登录的帐号时是默认帐号。投标方需在投标文件中提供真实系统截图。
4、需支持用户进行个人偏好设置,可以设定本帐号只能在一个浏览器上登录,只保留最新登录页面,其余将退出登录,需支持配置帐号异动提醒。
2.4 帐号安全管理
为帐号安全管理需求,系统提供主动防御功能,对于常见的恶意登录或暴力破解,可自动冻结账号直至解冻。具体需提供异常会话管理、休眠账号管理、恶意登录管理、冻结帐号管理、异常应用管理相关功能。具体要求如下:
1、系统需支持按照用户会话数、IP数去判定某个会话是否为异常会话并触发帐号冻结机制,管理员可配置触发冻结的阈值以及冻结时长。
2、系统需支持根据同一天多次登录成功\登录失败判定某个帐号是否为恶意登录行为并触发帐号冻结机制,理员可配置触发冻结的阈值以及冻结时长。
3、系统需支持管理冻结白名单,添加为白名单的帐号/IP地址不会因为出发冻结机制而被冻结。
4、系统需支持异常应用的管理功能,可配置异常应用判定规则。
5、为满足用户安全访问系统的需求,需提供二次认证、多因子登录的功能。需支持管理与配置二次认证/多因子认证方式及使用顺序,需支持管理员手动拖拽方式维护不同认证的顺序,系统可按照可用性及顺序智能选择当前最适合的认证方式。投标方需在投标文件中提供真实系统截图。
6、恶意登录管理:系统应支持帐号恶意登录的锁定功能,并可通过短信提醒用户,确保帐号安全。
2.5 无缝兼容当前学校使用的认证系统
为了保障师生用户体验,要求新建身份互联平台能够基于我校现有认证系统进行平滑升级,投标方需提供承诺函,承诺本次项目建设的身份认证互联平台能够兼容我校现有身份平台的身份认证协议,已与校内现有身份认证协议的系统无需重新与新建平台重新对接。
3 数据管理平台
3.1 数据管理平台
投标方需要提供包含信息标准管理、数据集成管理、数据备份管理、运行监控管理相关的多种数据管理工具,能够围绕数据共享接口、数据仓库提供高可用的管理功能,同时面向校级数据情况能够向我校提供数据情况可视化展现的能力,以支撑我校核心数据情况的建设。具体功能需求如下:
l 信息标准管理工具
平台需围绕信息标准管理提供元数据、代码标准、标准与代码版本以及数据集市模型的管理功能。
(1)可提供数据源统一注册管理,可灵活调整不同接入数据源的启停;
(2)可提供按目录结构对主数据和业务系统的数据对象进行管理,可根据元数据进行数据建模;
(3)需提供针对元数据一致性检查,采用先对元数据和数据库实体一致性比对,在对差异项进行处理的方式;
(4)需提供代码标准基本管理系列工具,围绕我校实现标准的“制定、维护、理解、分享和集成”,可集中对代码标准进行拆合、启停等操作,能够记录代码变更过程;
(5)可提供标准代码和业务系统代码映射关系的管理功能,实现代码映射的自动感知匹配功能。在代码标准映射过程中,可提供有代码和无代码两种场景下的映射管理;
(6)能够提供针对标准和代码版本的管理,可自动记录数据模型标准和代码标准的变更记录,自动生成标准版本号,并能实现当前版本与上一版本的内容对比。
(7)能够提供按目录结构对数据集市模型的数据对象进行分类管理,在数据集市建模时,可实现根据元数据进行数据建模,并对元数据和数据库实体进行一致性比对。
l 数据集成管理工具
为了形成我校统一的校级主数据库,通过构建一系列数据集成管理工具完成面向分散数据的集成汇聚工作,解决我校数据孤岛的问题。数据集成管理工具主要涉及数据集成开发包、主数据管理与生命周期追溯、数据流向管理等功能。
(1)针对我校数据集成工作,需提供丰富的数据集成开发包。包括拓扑管理、集成设计、集成查看、集成调度等工具;
(2)能够提供丰富的集成接口支持,包括支持主流关系型数据库、支持非主流关系型数据库、支持ODBC数据源类型接入、支持主题或者队列、支持Web Service、支持Tabled-Txt文件、支持XML文件以及操作系统的网络协议的集成接口;
(3)为了提升数据集成的工作量,需要能够向我校提供基于各种场景通用的知识模块,数据集成需求开发包数量不得低于100项;
(4)除了能够提供我校常规主数据管理的功能外,还必须向我校提供基于主数据生命周期的追溯功能,使我校数据管理人员清楚指导每个数据对象随着时间变化,增、删、改的数据量;
(5)必须提供基于数据流向的可视化展示功能,能够实时监控数据源头及目标的数据量,接口运行状态等,能够很方便的在拓扑图和详细列表之间进行切换;
(6)为方便数据管理员实时监控与目标表相关的源头系统与主数据表之间的运行状态,必须提供数据字段血缘监控功能,实现可以通过目标表下钻至源头、主数据、目标三方的监控可视化环境,可在可视化环境下通过触发表间连接,下钻至接口运行状态监控环境;
(7)需支持查询数据对象的接口运行记录,从建表到当前时间的数据全生命周期变化过程;
(8)能够面向我校数据集成业务,提供符合高校行业特征的高校行业集成库,通过可视化集成工具,梳理各业务系统核心的数据模型与字段,形成预制同步接口;
(9)为方便我校信息中心对数据管理的效率,投标方需提供在线SQL查询器,可方便的进行在线SQL查询操作,并能够提供查询语句收藏功能,保留常用语句不低于10个。
l 数据展现
通过对数据情况可视化展现功能建设,使我校可以清晰看到现有校级资产状况,涉及数据模型建模完成情况、数据同步集成概况、数据同步质量等。其中,主要包括需实现的功能为:数据情况概况与详情、数据集成操作情况、数据质量评估、权威数据责任单位管理、全校/部门数据报告等功能。
(1)必须能够以可视化树形结构的方式集中方便的呈现我校数据的概况,其中需要覆盖校级数据中包括的主数据对象模型、自定义对象模型、业务对象模型、数据集市模型、代码标准模型五大类。投标方可以提供以打分的方式,对我校一定时间范围内数据进行评估;支持查看不同模型分类的状态占比、不同模型分类下的业务模型的完整度占比以及不同业务模型的表数量和数据量;
(2)需要能够为我校数据管理员提供在可视化环境下,对各模型逐级下探的功能,能够在一个页面上集中展现不同模型下未建表、无数据表和有数据表的个数;
(3)需要能够展现数据同步质量情况,围绕数据完整性检测项、唯一性检测项、代码有效性检测项、格式合规性检测项,自定义各种展示规则;实现以横向多维柱状图展示各种检测项的检测结果,以增强对正常项数和异常项数监控查询的能力;
(4)需要能够为我校提供数据集成接口运行状态的文本及图形方式展现,实现支持查看每个接口调用成功/失败数量上的反馈,以及支持查看不同业务系统接口数量、运行次数和成功运行次数的统计;
(5)需要能够支持查看历史数据质量的评分,以判断数据质量的优劣;可以实现查看每个模型分类同步的数据条数统计信息,同时可以根据不同系统查看预设表、添加表的情况,并能够给出实时评分;
(6)能够支持实现权威数据责任单位管理的功能,提供易用配置的方式,将责任单位与主数据对象模型之间建立关联,最终可以在数据血缘关系、部门数据报告、质量报告查询中,可自动根据责任单位进行主数据对象模型的筛选;
(7)需要提供面向全校或部门级别的数据报告功能。以图文方式展现各级别组织数据情况,核心包括组织的数据建设情况、数据集成运行情况、数据开放情况、数据质量检测情况四个方面,同时可导出报告。
3.2 数据集成服务
需要与我校集成已经建设业务系统有关数据,包括但不限于已有业务系统OA、短信平台、教务、图书馆数字资源、网站群、微信公众号、一卡通等数据,以及待建的学工、质量保障体系、财务内控、人才培养数据、科研、财务、资产、邮件等业务系统,进行数据集成。集成工作由中标商负责业务系统提供商共同完成。
4 微服务建设
根据我校对微服务需求内容,确定通过流程服务快速构建工具定制开发25个微服务,具体内容包含(但不限于)如下,(最终上线的微服务为建设时到校调研为准):
序号 | 应用名称 | 服务 对象 | 应用 分类 | 业务域 | 简单功能描述 |
1 | 图书查询 | 师生 | 网页+移动 | 信息中心 | 使用对象:所有人 简介:对接图书馆系统,教职工与学生可以方案查询图书馆所有藏书资料,并可通过电子图书证阅读现有电子图书。 |
2 | 教职工请销假 | 师生 | 网页 | 人事 | 使用对象:教职工 满足部门教职工请假功能,完成在线请假申请、审批、查询功能,满足销假功能,与学校人事考勤系统对接,实时查看教职工工作状态。 |
3 | 用餐申请 | 师生 | 网页+移动 | 党政办 | 使用对象:所有人 简介:教职工在值班、加班期间可根据用餐需求提交用餐申请;在地图上的标记清晰的识别食堂的分布图,点击标记可以查看食堂的简介和联系方式。对于新入校的学生、家长、办事人员能快速的找到食堂的位置,并能根据自己的要求选择合适的食堂就餐。 |
4 | 通知公告 | 教职工 | 网页+移动 | 宣统处 | 各学校部门通过统一的平台进行授权发布,向师生发布通知,师生则可以通过这个平台统一获得需要的通知公告内容。 师生可以查看所有的校内通知,支持PC和移动端同步查看,并且公告带有附件,支持在线预览和下载,极大地方便通知到达的方式和查看信息的效率。 |
5 | 工资查询 | 教职工 | 网页+移动 | 人事 | 使用对象:教职工 简介:满足教职工工资查询功能,与财务系统对接,查询教职工工资明细。 |
6 | 课表查询 | 学生 | 网页+移动 | 教务 | 使用对象:教职工、学生 简介:教师和学生通过PC端或移动均可查询本人的课表信息,信息按照分学期按教学周展示,数据与教务系统集成,数据自动同步,无需人为操作,为师生提供更安全、更准确的课表信息,展现界面更友好、统一。 |
7 | 临时校园卡 申请 | 师生 | 网页+移动 | 信息中心 | 当有非学校教职工和学生需要在校内长时间办公,需要申请校园卡进行消费和门禁功能时,需通过本服务申请。 |
8 | 成绩查询 | 教师 | 网页+移动 | 教务 | 学生可以随时查看自己不同学期的考试课程的成绩,包括分数、班级排名、获得学分,可以查看当前学业完成进度,包括已修学分和未完成学分,绩点详情可以展示总绩点、绩点排名,绩点计算方法。 |
9 | 校外人员进校管理 | 教师 | 网页+移动 | 学保处 | 使用对象:教职工、校外人员 简介:针对校外人员进校办事,减少门卫对其身份和目的核实所耽误的时间,为校外人员提供通行证。教职工为进校办事人员申请通行证,相关部门对其进行审批,通过后会将通行证以短信的形式发送给校外人员,校外人员通过短信内容中的链接打开通行证,门卫对通行证的有效性进行识别和验证,验证通过的即可放行。 |
10 | 报修 | 教职工 | 网页+移动 | 后勤、信息中心 | 当教职工需要公共设施、教学多媒体设备等进行修缮时可通过一站式服务大厅提交报修申请,并实时记录修缮进度及结果以及满意度。 |
5 人事应用
5.1 教职工信息管理
人事处可以对教职工的基本信息和扩展信息进行维护和管理,也可以进行相应的设置,具体服务包括教职工基本信息管理、教职工扩展信息管理、教职工信息检测、教职工管理授权、教职工信息归档、教职工快照设置和教职工快照查询、教职工身份转换等。
教职工基本信息管理:人事处可对全校所有教职工信息维护管理、导入查询和批量维护,包括基本信息、在校信息、资质信息、岗位职务信息和通讯信息等。
教职工扩展信息管理:人事处可对教职工扩展信息进行统一和批量维护和管理,包括教职工过程信息子集如下:
1) 工作经历:可逐条维护教职工曾经的参加工作时间、工作单位、曾任职务等工作履历信息,可批量导入和导出;
2) 学习经历:可逐条维护教职工学历、所学专业、入学时间、毕业时间、毕业学校、取得学位、取得学位时间等学习经历,支持证书附件上传、在线预览和下载,可批量导入和导出;
3) 家庭成员:可逐条维护配偶、子女等家庭成员的单位、出生年月、职务等信息;
4) 岗位信息:可逐条维护教职工的曾任岗位信息,包括岗位类别、岗位等级、聘任起止时间等,可批量导入和导出;
5) 职称信息:可逐条维护教职工曾经获得过的职称信息,包括获得评定职称、评定职称等级、职称评定时间、聘任职称、聘任职称等级、聘任职称起止时间等,支持证书附件上传、在线预览和下载,可批量导入和导出;
6) 党政职务:可逐条维护教职工的曾任党政职务信息,包括职务名称、职务级别、任职年月、任职单位等,可批量导入和导出;
7) 政治面貌:可逐条维护教职工的政治面貌信息,包括政治面貌、参加党派日期、参加时所在单位等,可批量导入和导出;
8) 工人等级:可逐条维护教职工曾经获得过的工人等级信息,包括工人技术工种、工人技术等级、评定时间、聘任工人技术等级、聘任起止时间等,支持证书附件上传、在线预览和下载,可批量导入和导出;
9) 奖励情况:可逐条维护教职工曾经获得过的奖励情况,包括奖励名称、奖励级别、获奖日期等,支持证书附件上传、在线预览和下载,可批量导入和导出;
10)惩处情况:可逐条维护教职工曾经收到的惩处情况,包括惩处名称、惩处日期、惩处单位、惩处原因等,可批量导入和导出;
11)海外研修信息: 可逐条维护教职工曾经的海外研修信息,包括起止时间、研修(访学)机构名称、国家(地区)、项目名称等,可批量导入和导出;
12)语言能力:可逐条维护教职工所掌握的语种信息,包括语种、语种熟练程度等,支持证书附件上传、在线预览和下载,可批量导入和导出;
13)其他技能:可逐条维护教职工所掌握的其他技能信息,包括其他技能名称、其他技能熟练程度等,支持证书附件上传、在线预览和下载,可批量导入和导出;
14)证书信息:可逐条维护教职工所获得的证书信息,包括证书类型、证书名称、发证年月、发证单位等,支持证书附件上传、在线预览和下载,可批量导入和导出;
15)社会兼职:可逐条维护教职工曾经做过的社会兼职信息,包括社会兼职名称、起止时间等,可批量导入和导出;
16)学术团体兼职:可逐条维护教职工曾经做过的学术团体兼职信息,包括学术团体名称、起止时间、学术团体级别、兼职职务等,可批量导入和导出;
17)教师资格信息:可逐条维护教职工获得的教师资格信息,包括教师资格证号码、任教学科、证书颁发日期等,支持证书附件上传、在线预览和下载,可批量导入和导出;
教职工管理授权:对各角色的查看权限、维护权限、必填权限等进行设置,比如一个应用分别对人事处角色和普通教职工角色进行权限的设置和授权,可分别设置不同的维护权限、查询权限和是否必填,还可针对教职工修改哪些字段后需要审核进行设置。
教职工信息归档:可对教职工信息进行归档,可设置归档的时间和规则,人事处可对过去任一时间点的数据进行回溯归档,对相关的查询统计提供依据。
教职工快照设置:设置教职工快照信息的生成时间和规则等。
教职工快照查询:根据设置,系统会定期生成教职工快照信息以达到信息备份的目的,教职工快照信息同时为事业单位报表统计和高基报表统计提供数据依据。
教职工身份转换:教职工身份发生变化时,可以实现职工号和用人方式的身份转换,比如人才派遣人员转换为人事代理人员,可以使用新的职工号和用人方式,原教职工基本信息、工作经历、学习经历、家庭成员、岗位信息、职称信息、党政职务、政治面貌、工人等级、奖励情况、惩处情况、社会兼职信息和学术团体兼职等相关基础信息将同步关联到新的职工号。并且身份转换会留存转换历史记录。
5.2 教职工考勤
可对教职工考勤方案设置、考勤信息院系上报、考勤审核管理等,通过移动终端进行考勤查询服务。教职工可以的手机端进行考勤定位打卡,查询个人历史的缺勤记录,院系可以按月查询所管部门的缺勤明细情况,人事处可以按月查询全校各部门的缺勤明细情况。
6 业务集成
投标人须完成学校现有业务系统集成,具体包括对学校现有的应用系统进行界面、身份认证和数据的集成。通过把各应用系统集成到网上办事大厅,并由统一身份认证平台完成各应用系统的身份认证,既便于用户使用其权限下的应用系统,也便于系统管理员对用户权限、系统安全的统一管理。同时通过统一数据中心平台,对各个应用系统整合,对其数据进行抽取、清洗、转换、储存等措施,消除学院以往建设中存在的“信息孤岛”和“数据孤岛”,实现各应用系统数据信息的统一管理与共享。
本次一期建设内容的智慧校园支撑平台为学校对接所有现有第三方业务系统包括但不限于教务、OA、科研、财务、资产、图书馆、一卡通、企业微信、邮件、短信平台、网站群、平安校园、微信公众号提供数据接口服务,投标人须承诺在项目建设过程中及质保期内始终免费开放系统接口,并免费完成学校现有及质保期内待建业务系统与智慧校园平台的身份和数据的集成工作。质保期后,不得以任何不正当的理由拒绝与学校新建业务系统进行集成对接,双方可根据接口集成的工作量另行协商签署合同。
7 工程实施服务要求
7.1 时间进度要求
本次项目须严格按工期部署完成,并达到采购人的要求。本项目要求在合同签订后180 天内完成项目系统建设并交付使用。投标文件中须提供针对本项目的预实施工期进度表,否则视为无效投标。
7.2 实施方案
7.2.1组织架构与职责1、须提供项目经理一人,负责全程跟踪项目的开发与实施,直至该项目验收,该项目经理应具备高校数字化校园基础平台及应用系统(基础平台、门户平台、主数据管理平台、身份认证平台等)项目成功开发实施经验。
2、项目组其他实施人员应满足项目开发和实施的需要,项目组成人员应不少于2 人,具备数字化校园相关开发和实施经验。
7.2.2实施阶段划分投标人须描述各个实施阶段的工作范围、内容、人力投入、过程、责任、交付成果等。
7.2.3项目管理要求投标人须提出对项目的建设进行科学严格的管理方案与措施,保证项目全面顺利实施。
7.2.4项目配置管理在项目的建设过程中以及交付使用后,会产生大量文档和程序,且文档的版本在不断变迁和修改中。投标人须提供相应的项目配置管理系统,维护产品的历史、鉴别和定位产品版本、在产品开发和发布阶段控制变化,制定规范的配置管理工作计划和流程, 沟通交流配置管理工作情况,使管理制度化、减少重复性工作、保证产品的质量和效率和系统的后续升级和维护。同时需承诺会对项目实施过程中产生的各类数据(包含记录、报告等)进行保密,不能外泄。
7.2.5项目管理规范和手段根据项目的实施方案,在实施过程中,为了保证用户方、开发方等各方能够对项目建设实施进行监控,及时发现和解决的问题,投标人必须建立相应的项目管理规范,使管理和监控工作流程化、规范化,管理和监控工作责任明确。
7.2.6风险管理项目风险管理是对项目风险从识别到分析到应对措施的一个过程,包括风险识别、风险量化、风险对策、风险对策实施控制四个方面。项目在实施过程中会出项各种各样的风险,必须做到充分、有效识别风险,应对风险和控制风险,投标人须提供风险管理方案,制定风险预测和规避风险的对策。
四、交付时间和地点:
(一)服务完成时间:在合同签订后180天内完成系统建设并交付使用。
(二)服务地点:采购人指定地点。
五、服务标准:
(一)综合运维服务
高效全面的综合运维服务是确保平台安全稳定运行的根本。平台综合运维服务需包括相关软硬件部署、系统安装和调试、项目培训以及平台交付及后续技术支持和现场服务等。
(二)现有数据迁移与存储
本次一期建设平台要考虑我校原有数据情况,将有效的整理学校现有各业务系统数据,将各业务系统数据进行综合考虑,统一做好数据整理与迁移,统一在数据资产管理平台进行存储备份,保证我校数据的唯一性。
(三)质保期
本项目建设内容供应商至少提供原厂3年免费质保及服务。
质保期内,需提供7*24小时线上服务,提供定期产品使用质量回访服务外,须提供如下服务(但不限于):对系统巡检和BUG进行修复,系统环境调整的文档更新,微服务流程修改,使用过程中的问题接单,服务器临时启停服务,对运行过程中访问报错问题进行处理,对使用过程中数据错误问题进行处理,实施数据备份服务和数据容灾演练恢复。
质保期外本次采购供应商也需提供7*24小时线上服务,并提供定期产品使用质量回访服务,质保期外供应商需提供每1个季度不少于1次在现场进行的巡检服务,及时发现和排除潜在问题和故障隐患,保证系统的稳定运行。
(四)技术支持
根据系统运行的环境要求和安全考虑,制定适当的系统维护、网络安全、系统使用等相关的操作规范等,并指定对应负责人。
需设有售后技术服务部,并提供专人提供5×8小时(即每周5天工作日,每天8小时)的技术咨询服务,提供经验丰富的程序员解答用户的各种问题。
(五)定制化服务
一期项目所建内容供应商需满足我校在质保期内的定制化开发的需求,对一期建设内容的相关软件的系统功能(界面与应用层),根据学校各业务部门需求进行二次开发,不得另外收取费用。
(六)驻场服务
本项目需提供为期1年的专人驻场人员(不少于3人)服务,驻场人员对平台软件及硬件要有着充分的了解,具有丰富的运维实施经验。服务人员需相对固定,若有变动,需提前一周通知校方并征得校方同意。
对于任何运行中软件或硬件进行修改或维护,服务人员需严格填写维护记录单,并由校方签字确认后进行相应的修改完善。
(七)日常运维
为确保本项目的服务质量,需要严格遵守质量控制标准,并应用在项目服务的各个阶段。
六、验收标准:
(一)本项目按照《关于进一步规范政府采购项目履约验收工作管理的通知》(长财采购[2016]6号)文件要求进行验收。
(二)项目验收国家有强制性规定的,按国家规定执行。
七、其他要求:
(一)付款方式:
1、付款人:长沙卫生职业学院(通过国库集中支付)
2、付款方式:
付费次序 | 占总费用 | 付费时间 |
第一次付费 | 30% | 签订合同后 |
第二次付费 | 50% | 系统上线运行后 |
第三次付费 | 15% | 项目通过验收后 |
第四次付费 | 5% | 质保期满后 |
(二)本项目采用费用包干方式,供应商应根据项目要求,详细列明项目所需的设备购置和材料费用(如有),以及人工、管理、财务等所有费用,如一旦成交,在项目实施中出现任何遗漏,均由中标人免费提供,采购人不再支付任何费用。
(三)知识产权
本项目开发过程中新产生的知识产权全部归长沙卫生职业学院所有。
中标人须保证系统的开发不侵犯任何人的权利。如系统开发过程中或系统包含的任何知识产权侵害任何人的权利,中标人应负责并使采购人免责,包括但不限于使采购人免于参与或处理相关纠纷,赔偿采购人产生的任何实际损失。
(四)人员培训
中标人应按采购人指定负责培训后台操作管理及维护人员,达到熟练掌握产品性能,能独立完成对系统的维护更新、能及时排除一般故障的程度。
(五)本项目中标人不得以任何方式转包或分包给第三方,如被采购人发现,采购人有权取消其中标资格。
(六)投标人须保证所提供的证明材料真实有效,如发现造假,取消其中标资格,所造成的后果均由中标人承担。
(七)投标人在投标前,如须踏勘现场,有关费用自理,踏勘期间发生的意外自负。
采购需求仅供参考,相关内容以采购文件为准。
返回顶部