技术指标及要求

一、采购需求清单序号采购内容技术描述数量备注1校园大数据综合应用平台校园大数据综合应用平台1210产品技术规格一、项目背景经过前期十多年的发展,中国音乐学院信息化系统建设已初见成效,已建设了信息化业务系统,例如:人事系统、教务系统、资产系统、财务系统、学工系统及一卡通系统等业务系统,方便各自的业务管理需要的同时,也为智慧校园的建设奠定了一定的基础.
但同时也面临一些挑战,主要内容如下:1.
1顶层设计与协调不足在信息化对学院发展的引领作用方面,整体规划存在不足,缺乏基于学院整体的通盘规划和设计.
目前,业务部门信息化建设各自为政,在应用服务方面未能从顶层设计的视角规划设计.
各部门信息化管理能力良莠不齐.
已有软件系统缺乏明确的技术规范与要求,造成数据和服务集成的难度增大及系统维护成本不断增加等问题.
同时,部分教师和管理者信息化意识薄弱,对信息化在教学与管理变革中的重要性认识不足,管理人员技能单一,部门内部及部门间沟通成本高;无专人负责整个业务信息系统管理过程,缺乏全局统筹考察.
总之,缺乏顶层设计的数据标准和规划,导致学校已建的一些应用系统使用效果不好,用户感知度低,未能使从传统的电子化表格管理方式转变为通过信息服务系统来提升学校管理水平及师生服务水平.
1.
2数据资源分散,数据挖掘共享需提升目前学院数据资产未能得到有效梳理,大量的业务数据依旧处于分散、准确性差的状况,无法实现高效、实时的共享;数据沉淀不足,一些数据需重复录入填报,导致数据整理工作量大、效率低.
由于数据标准体系和数据中心未建立,难以基于学校数据开展深入分析挖掘,数据价值难以体现.
1.
3缺乏校务数据分析与展示技术及服务数据是学院的重要资产,但数据本身并不能直接发挥价值与作用,而是需要依靠业务分析模型方法经验和技术支撑,建立相应的数据分析模型,深度挖掘数据内部蕴含的价值及规律,通过可视化的方式将数据的价值进行展示、查询.
目前学院尚未具备该部分的能力,无法为各级领导及广大师生提供校务数据综合展示的服务.
1.
4项目需求针对以上挑战,学校急需搭建智慧校园平台,通过建设一套完善的数据标准体系,保证数据标准化管理,减少重复工作量,并建设统一数据中心,实现业务数据可共享、统一管理,提高各业务部门协作能力.
学校将按照新的数据标准体系,保证数据中心或其他业务系统与新建或升级业务系统进行交换对接:包括人事、教务、学工、图书馆等,实现各系统按数据标准互联互通.
通过建设统一身份认证系统和综合信息门户,集成学校已有的业务系统,保证学院各层人员都可以实现单点登录,无需重复登录提高用户访问效率;最后要建立一套数据可视化平台,实现对师生、职能部门、校领导提供基本数据查询服务,并通过数据可视化平台构建不同业务部门所需要的分析模型,辅助领导进行宏观决策,提供真实、可依据的数据.
二、项目建设要求和目标2.
1建设目标本期建设的目标为在现有信息化建设的基础上,打造中国音乐学院智慧校园的基础平台,为未来实现"三端一体化"提供根基性的保障和支撑.
包括全面梳理、建设中国音乐学院数据标准体系服务,为各业务部门数据的整合、交换乃至应用提供统一、权威的规范,并且以此指导未来学院的各类信息化建设.
以数据标准为指导建设公共数据中心,整合各业务部门的数据,形成统一的公共数据中心,将学院各业务部门的数据交换进行统一和规范,保证数据的规范性和唯一性.
在应用方面建设统一身份认证系统,统筹管理学校内各类用户的身份信息以及各业务系统的认证通道,使广大师生用户可以达到一次认证、全局使用.
建设统一信息门户,汇聚学院各类应用系统入口以及通知消息类的展示,为广大师生提供切实的获得感.
2.
1.
1数据标准建设目标数据标准是信息在采集、处理、交换、用户访问、传输过程中的统一规范,是实现学院信息资源共享和信息系统协同发展的基础.
本项目建设具体目标为:(1)推进学院信息化建设,提供科学、合理且符合学院实际情况的数据标准与规范,使各业务系统之间,有统一规范的标准可以参照,保证信息的交流与共享.
(2)通过科学合理的元数据管理,为数据库设计提供类似数据字典的作用.
元数据是各系统之间数据沟通的桥梁,分为技术元数据和业务元数据.
为信息交换、资源共享提供语义层基础性条件.
(3)保证信息在采集、处理、交换、传输过程中有统一、科学、规范的分类和描述,能够使信息有序流通、最大限度地实现信息资源共享,使学院信息系统得到协同发展,发挥信息资源的综合效益.
在学院智慧校园建设过程中能让共享数据资源和信息系统更健康的持续运作.
2.
1.
2公共数据中心建设目标基于解耦的设计思想,数据中心应分为数据标准与元数据管理中心和数据交换平台两部分.
其中数据标准与元数据管理中心负责数据标准管理、元数据管理、数据服务接口管理;数据交换平台负责数据的抽取、整合、采集、交换等工作.
2.
1.
2.
1数据标准与元数据管理中心建设目标数据标准与元数据管理中心的建设要求达到以下目标:(1)建立全局共享数据集,实现学院核心信息资源的共享;(2)结合数据交换平台的信息交换机制,快速构建公共数据库,反映学院全面的数据信息;(3)构建强大的公共数据平台管理工具,为平台运行维护和后期扩展提供支持;(4)对数据共享权限可灵活控制,即做到方便的将数据共享到各类需要应用系统,又能做到对安全性的高度保障,防止数据泄露及数据越权访问;(5)逐步建立完善公共数据平台的日常维护和运行保障机制,制定管理规范、技术规范、工作流程、服务章程等各项规章制度,保障公共数据平台和各个业务系统的持续运行.
2.
1.
2.
2数据整合交换平台建设目标建立灵活、高效、安全、稳定、高性能、跨平台、跨系统、高度可扩展的数据交换平台是校园信息化建设的关键.
通过构建数据交换平台,制定统一的信息交换标准,公开统一的数据交换接口,为将来的应用系统集成打下坚实的基础.
本平台的建设目标如下:(1)为学院智慧校园框架下的各应用系统之间提供一个统一的数据交换通道,使数据交换更加准确、便捷、高效、通畅;(2)为适应学院众多部门尚无业务系统或业务系统无法满足业务需要,不得不继续使用excel文件处理数据的实际情况,数据交换平台将提供一个稳定可靠的线下数据汇总导入通道,可以让业务部门工作人员在不改变自身工作习惯的同时,妥善的解决大量线下数据汇总收集问题,解决这一项目难点;(3)建立学院统一的数据交换技术规范和标准;(4)信息化解决方案需要以服务对象出发,以服务对象的实际情况作为系统的根本要求.
通过本次建设将提供一套操作非常直观便捷的可视化数据交换平台,通过可视化拖拽操作,实现数据交换功能操作,降低平台管理的技术门槛,便于学院自行管理数据交换工作,将项目难点中的学院技术能力较为薄弱的问题轻松化解.
2.
1.
2.
3综合信息门户建设目标综合信息门户的建设需达到以下目标:建设具有中国音乐学院特色的轻量级信息门户服务平台,通过最新的用户体验技术打造一个界面美观,用户体验友好的服务门户,减少用户学习使用成本.
集成学校已有的各应用系统、以及本期的GIS业务应用平台、数据分析展示平台,通过门户即可进入学院各类系统及数据可视化中心,广大师生无需记住众多不同的系统登录地址.
汇聚学院各类新闻、通知、会议提醒等信息,形成学院统一的信息汇总平台.
2.
1.
3统一身份认证建设目标统一身份认证系统建设的目标是按照学院实际组织架构与角色划分,提供学院统一的身份库以及身份认证体系,满足学院外众多用户的各类系统访问认证要求.
2.
1.
4数据可视化平台建设目标通过可视化技术,直观的掌握各业务域的数据概况,建设领导驾驶舱、教务分析模块、学生分析模块、人事分析模块、图书分析、资产分六大分析模块,进而全面了解业务情况,为学院主要业务部门和校领导决策提供有效、直观、准确的数据支持.

2.
2建设思路要求采用"顶层设计"的方法,构建一个学院层面的数据治理与服务中心.
实现以治理促管理,即通过信息环境和系统建设,进一步整合学院各部门的力量,明晰主体责权,形成系统合力,探索有效机制,促进一体化、全生命周期的管理业务与数据的建设与完善,实现"系统治理、综合施策".
要求构建学院综合治理体制机制,实现数据治理体系,实现各项管理与决策工作有数据、可量化、能预测;建设中国音乐学院数据管理服务体系,建设数据完备、共享服务化的数据中心,统筹统管校级主数据和业务数据,实现数据共享深度化、数据服务开放化、校务数据可视化.
三、项目建设内容清单(1)数据标准与规范(2)#数据标准与元数据管理系统(3)#数据交换平台(4)#数据可视化平台(5)#统一身份认证平台(6)#综合信息门户四、总体设计要求4.
1技术路线要求4.
1.
1技术指标要求(1)开发及运行平台基于J2EE,采用成熟的体系架构,具备良好的跨平台能力,所有服务器均要求采用主流的发行版本Linux操作系统(Redhat、Centos等),主要数据库采用Oracle,所有软件要求为满足建设要求的正版软件.
所有架构体系均在沿用学院已有经验的基础上,融合并继承现有平台、系统、数据库中的已有主要数据,并能与校内其它系统对接,保证顺利衔接.

(2)软件体系架构要求提供组件化、面向服务和接口、灵活可配置、可维护性强的系统设计和实现,可满足学院独立进行扩展应用服务构建和自主业务管理.
系统架构开放,采用MVC(模型、视图、控制)三层或多层分离的结构基础上的B/S模式.
预留标准、规范的接入接口和对外服务API,提供接入规范、应用开发规范及相关技术文档.
提供基于LDAP目录服务的身份组织管理技术.
4.
1.
2安全性系统应具有第三方有资质的安全检测机构出具的安全报告,并且相关的安全设计满足建设要求,通过主流安全漏洞扫瞄,不存在高危漏洞.
满足信息安全等保二级以上.
系统对敏感的数据存储和传输需要采用公开的加密算法进行加密处理.

系统提供严格的权限管理和安全审计功能,不出现任何非授权的业务访问和数据访问,并提供完善的审计日志,实现操作的追溯.
有完备的数据备份与恢复机制.
拥有完善的安全管理保障体系,具有有效的应急处理和灾难恢复机制,确保突发事件后能迅速恢复系统;严格遵守学院的数据保密相关规定,并提供软件全生命周期内的安全服务.
4.
1.
3视觉设计及交互体验要求要求支持IE9\10\11、Chrome(或其它基于Webkit内核)、Firefox、Safari、Edge等主流浏览器.
系统UI设计简洁大方,要求与学院的整体风格保持统一,建立包括色调主题、布局风格、操作体验等一整套完整的UI设计标准,可以提供连贯性、沉浸式的"WebApp"体验,减少学院用户在不同应用界面之间切换的学习成本和心理压力,更快更便捷地掌握系统功能,促进学院信息化建设的推广.
前端实现采用HTML5+CSS3的响应式设计,适应1024*768以上的各种主流屏幕分辨率.
遵守学院的UI设计规范和要求,不出现承建方的任何标识.
4.
2体系架构设计要求4.
2.
1数据标准体系数据标准是学院信息化工作的重要部分.
不仅对学院数据进行分类、按主题建立数据目录,更重要的是建立了统一的名词术语管理.
数据标准以信息资源规划的思想形成高校数据标准,对数据项的业务属性、技术属性、管理属性进行定义.
最后形成数据架构的一部分,学院可以在数据关系管理中下钻各类数属性.
4.
2.
2公共数据中心公共数据中心是围绕数据的交换、清洗与处理、管理与存储以及监控与治理的数据治理与开放数据服务平台.
其特点与核心就是数据存储分层化、数据共享服务化.
数据中心包含以下内容:(1)数据标准与元数据管理,其中数据中心需包含多层架构(原始层、主题层、分析层、应用层)设计.
(2)数据交换平台.
(3)综合信息门户.
4.
2.
2.
1数据标准与元数据管理数据标准本身是一套规范与制度,其表现形式在以往更多的是以一套电子文档的形式呈现,但这里面就存在几个问题.
首先,电子文档形式下难以进行更新和维护,标准建成之日往往就是停止更新之时,之后在实际工作中出现数据标准的改变时文档很难及时同步更新;其次,电子文档形式的数据标准难以真正规范数据的使用,因为电子文档并不能与真正存储数据的数据中心产生任何联系.
为了解决以上几方面问题,数据标准需要通过系统进行管理,并与元数据建立真正的关联.
数据标准的建立、修订、发布,全环节应通过系统进行管理,并可基于发布出来的"执行标准"构建中心库的结构,在日后执行标准升级后也可通过系统更新库结构,这样才能够保证数据标准落到实处,真正有效的指导信息化的建设,在全院数据交换中起到规范的作用.
数据中心体系包含多层不同的架构设计.
多层数据架构是一种在多所不同类型的高校数据中心建设中验证可行的数据治理数据层次结构,能够系统性的解决数据整合与治理工作量大、内容复杂的问题.
多层架构至少包括原始数据层、主题数据层、分析数据层与数据与应用数据层等,抽象层次由低到高.
在一般的数据中心建设中,最主要的工作就是将原始数据按照数据标准,并结合应用需求进行梳理、映射、清洗和转换,逐层向上分别形成各种层次的过程.

原始数据层原始数据就是需要被整合到数据中心的不同来源的数据.
典型的数据来源是现有业务信息系统,比如学工系统、教务系统,也包括机器设备产生的数据,比如一卡通终端日志、无线网络访问日志等.
这些源数据的数据质量由源系统的数据质量人员负责,在整合到平台前需要进行数据质量测量,然后根据测量结果进行数据清洗.
主题数据层通过顶层设计形成学院的数据标准还是一个抽象的框架,需要用学院的原始数据对照标准进行清洗、转换、映射等一系列处理,形成主题数据库.

主题数据需要被发布共享给其他系统、或者与数据分析模型进行面向各种应用的结果性数据.
原始数据与主题数据的映射关系,即某个主题数据是由哪些原始数据形成的,是数据治理中必须搞清楚的.
分析数据层数据分析模型是对输入数据的计算和处理产生新的结果性数据,比如平均值等.
同时分析模型输入数据可能来自不同的主题数据,这样的关系需要被表达与配置以满足不同的数据分析主题.
应用数据层数据的管理的目的是为应用服务,智慧校园的建设目标之一是实现数据与应用之间的解耦合的.
数据与应用之间的关系是灵活的,甚至是运行时的,需要提供师生用户与应用程序都能识别理解的数据API.
4.
2.
2.
2数据整合交换平台数据交换平台,构建起高校数据的传输管网,这是"百年大计"的数据基础建设.
该平台要对整个校级数据抽取作业的设计、管理、调度、监控,除了要支持上行集成、下行共享,还要支持向应用系统回写数据,在全局保持一致的数据.
可解决学院数据不一致问题.
数据交换平台要重点完成数据抽取作业,并且要管理包含数据来源去向等重要信息的ETL元数据,数据交换平台要集中管理ETL元数据,在界面上以图形化方式展现数据的流转,交互式地维护数据流转拓扑.
屏蔽ETL作业的细节时,要提供更容易理解的数据架构.
4.
2.
2.
3综合信息门户在信息门户建设方面的设计遵行轻量级设计,要求门户具备一定的扩展性、开放性、性能和安全性.
需要利用成熟的主流技术完成门户的搭建工作.

为了满足学院不同用户的操作习惯,门户必须能够对多浏览器支持,能够在主流的IE内核以及chrome内核浏览器上都能够为用户提供最便捷、最全面的访问渠道.
4.
2.
3统一身份认证认证中心设计需要基于4A标准规范,要提供统一认证、授权访问控制和管理工具,对所有数据进行立体的控制和管理,确保数据的安全性.
学院所有用户通过统一信息门户实现单点登录,全方位的解决了高校在统一身份(Account)、统一认证(Authentication)、统一授权(Authorization)、安全审计(Audit)四个方面的管理与安全问题.
4.
2.
4数据可视化平台数据可视化平台建设要符合学院当前信息化建设需求,要与学院各主要职能部门及教学单位沟通业务需求及数据情况,找出各业务部门中能够反映其业务特点的数据模型,并根据数据模型的特点,设计可视化的展示形式,以最适合的图形对数据模型进行展示,使其数据易于理解,并对观看者有所启发,展示出隐藏在数字背后的趋势以及特征.
五、分项建设内容和具体要求项目需包含数据标准与规范、数据标准与元数据管理系统、数据交换平台、综合信息门户平台、统一身份认证和数据可视化平台.
通过校内数据标准的建设,指导中国音乐学院的信息化建设,为学院信息化长期发展奠定基础;数据中心的建设也会加强不同管理应用之间的数据交换和共享的力度,避免数据的重复维护,提高学院整体工作效率.
数据中心建成后所涉及数据为学院各项核心业务数据,包括大量师生个人信息等敏感数据,本项目要求承建方按照信息安全等级保护二级的要求进行建设.
5.
1数据标准建设5.
1.
1功能要求(此功能要求需要现场演示)数据标准是信息在采集、处理、交换、用户访问、传输过程中的统一规范,是实现学院信息资源共享和信息系统得到协同发展的基础.
数据标准从类型上需要包含接口数据标准与主题数据标准两大类.
接口标准是指学院各部门系统在提供数据接口给数据中心作为数据源时候的标准,也是部门提供全校数据交换过程中能提供的数据标准.
这直接关系到数据中心将集成处理哪些数据.
主题数据标准是指根据国标和部标的主题分类方式,将接口标准按照主题一一对应而制作的标准.
主题数据标准的意义在于按主题划分后为数据挖掘、数据统计分析做准备.
按主题划分也是让全校数据标准向国标、部标靠拢,方便数据上报.
数据标准与规范建设从具体内容上应包含以下几方面:(1)数据标准.
数据标准需按照学院的信息子集进行定义,每个信息子集应包括以下内容:1)数据集、数据子集、数据项分类与分层结构;2)数据子集定义、属性描述;3)数据项定义、属性描述、权限描述.
最终确定的信息子集要根据中国音乐学院实际情况进行制定,未来要随着学院各类应用的新建或修改同步进行补充或修订.
信息子集的制订范围应涵盖中国音乐学院所有业务,需包含学院概况数据子集、教学管理数据子集、教职工管理数据子集、科研管理数据子集、学生管理数据子集、财务管理数据子集、资产与设备管理数据子集、办公管理数据子集、图书管理数据子集等.

(2)参考代码标准.
数据要按照统一的标准产生、存放、使用,使数据真正达到规范性、统一性和一致性.
编码标准的建设要求基于国家标准、教育部标准、行业标准和学院已有的校标,兼顾各个标准之间的兼容性、一致性以及标准的可扩展性,建设和完善学院各类系统中数据的存储、使用规则,并给出信息分类编码规格说明书,建设形成一套符合中国音乐学院自身实际情况的编码标准.
(3)交换接口标准:交换周期、文件交换、标准数据交换,采用XML、WebService,JSON等作为数据传输的标准,帮助用户建立统一的数据传输与数据交换规范,实现不同部门间、不同应用系统间的数据交换,具有良好的扩展性.

明确学院未来加入的应用系统如何对接,以及相应的对接标准.
5.
1.
2技术及原则要求数据标准建设是学院信息化建设的重点之一,对推进学院信息化建设,保证信息的交流与共享,有着重要的意义.
数据标准在全校范围内,为数据库设计提供类似数据字典的作用,为信息交换、资源共享提供了基础性条件.
数据标准需要保证信息在采集、处理、交换、传输的过程中有统一、科学、规范的分类和描述,能够使信息有序流通、最大限度地实现信息资源共享,使学院信息系统得到协同发展,发挥信息资源的综合效益.
数据标准建设需要考虑以下方面:1)标准的兼容性:该"标准"的实施对各职能部门信息系统建设、信息的交流与共享、数据的收集、分析、发布都有着十分重要的意义,因此所采用的数据标准必须和国家标准、教育部《教育管理信息化标准》等数据标准相兼容.
2)标准的可扩性:随着信息化进程的发展,数据标准也必须是一个及时更新、不断充实的动态系统.
必须提供能够灵活调整数据标准的管理和维护工具.
3)标准的规范性:即在一个信息编码标准中,代码的结构、类型以及编写格式必须统一.
4)标准的唯一性:即虽然一个编码对象可有很多不同名称,也可按各种不同方式对其进行描述,但是,在一个分类编码标准中,每一编码对象仅有一个代码,一个代码只唯一表示一个编码对象.
5)标准的适用性:即代码要尽可能的反映分类对象的特点,便于应用.
5.
2数据标准与元数据管理系统建设5.
2.
1功能要求(此功能要求需要现场演示)5.
2.
1.
1标准管理数据标准管理包含以下内容:标准管控中心、标准草案管理、执行标准管理、参照标准管理、标准对照管理和标准文档管理,为所有的标准文档目录和内容,包括草案和执行标准,要提供存放、显示、管理、维护、统计和监控的功能.
总的来说,数据标准管理系统包含以下部分:(1)标准管控中心标准管控中心主要是向用户图形方式展示学校执行标准的结构以及中心数据库的采标率.
执行标准的构成比是执行标准中的各数据子集所包含数据项数量占标准总数据项的百分比.
标准采标率是描述执行标准中来源于参照标准的数据项与执行标准总数据项的百分比.
(2)参照标准管理参照标准是指教育主管部门(特别是教育部)发布的有关学校信息化建设的规范标准,各学校(或教育机构)进行本单位信息化建设时参照并遵照执行.
管理主要为用户提供快捷地浏览数据标准内容的工具.
(3)标准草案管理要求标准草案建设要根据学院的教学、科研、管理的实际需要,参照教育主管部门制定的行业标准,制定适合学校自己需要的校级标准.
主要要提供有关草案标准的创建、更新、删除和发布等功能.
(要求提供功能截图并加盖原厂公章).
标准草案的主要功能如下:1)新建标准草案:为学校标准制定者提供自主创建适合学校需要的新的标准,主要包括标准数据集、数据子集、数据类、数据项等相关信息的创建.
使用者在创建新的标准草案时,可以引用参照标准或执行标准的相关数据集、数据子集、数据类或数据子类.
2)编辑标准草案:为学校标准制定者根据自己需要修改更新标准草案的数据集、数据子集、数据类、数据项等相关信息.
3)删除标准草案:为学校标准制定者根据实际删除标准草案的数据集、数据子集、数据类、数据项等内容.
4)还原标准草案:用户可对误删的标准草案信息进行恢复,使相关信息恢复到以前的内容.
5)发布标准草案:标准草案在发布之前,除标准草案制定者之外,其它用户是不能看见该标准的相关信息,只有标准发布为执行标准之后,其它用户才能查看或使用该标准,用户可以将标准草案发布为指定的版本.
(4)执行标准管理执行标准是指学校参照上级标准,根据本校实际情况,发布的适合本学校信息化建设的规范标准,学校相关部门遵照执行的数据标准.
执行标准管理主要为用户提供方便快捷地查看浏览执行标准内容的工具.
(5)标准文档管理标准文档是教育主管部门(或学校)制定信息化标准,以非结构化的WORD或PDF文档形式存储的数据标准,要提供非结构化标准文档的上传与下载浏览功能.
方便了用户对不同形式的标准信息的管理.
(6)标准对照管理标准对照管理,选择一个目标标准,再选择一个对照标准,可以检测出目标标准的数据更新、删除、新增的状况.
5.
2.
1.
2元数据字典管理根据学院提供的接口标准,主题标准建设的数据中心,需要生成多个相关的数据库结构的描述信息,还需要根据需求将同一类型的表批量分配到同一个主题.
用户可浏览数据库的结构、通过SQL语句查询表的详细数据.
(1)元数据管控中心元数据管控中心,同标准管控中心的用途一样,是为系统管理员提供性能监控以及系统统计,是系统管理员明白系统的运行情况等.
在元数据管控中心中,对4个中心库进行了统计,每个层以饼图和柱状图的形式展示.
要求可以展示多层数据中心的数据表、字段总个数,及多层架构每层的数据表、字段个数及占比.
要求可以展示数据的流转过程,各业务系统->到各层数据中心的流转,点击任一层展示的内容随之变化,显示每一层的元数据分布情况包括该层的数据表总数与字段总数,环形图表示该层各业务系统的数据占比,鼠标移上去可以显示数据量和百分比;柱状图表示该层各业务系统的字段数量,鼠标移上去显示详细数量.
(2)历史数据本着基于创新性的"多层架构"数据中心存储架构的设计,要求管理平台对数据实现历史数据管理,当需要回溯和查看某一历史时间的数据原貌,或需要对比任意两个时间节点之间的数据差异时,可以通过历史数据管理功能轻松便捷的进行管理,不但可以查看到不同历史时间的各类数据量,更能够直接查看到具体的历史数据记录.
(3)多层元数据管理系统对多层架构中的每个数据层次均要提供专门的功能进行管理,可以添加、编辑、删除元数据.
(4)数据查询分析工具系统要提供灵活强大的数据查询分析工具,可以查看数据中心中任意层次的数据,并提供条件配置功能,可以方便的进行关联、聚合、设置条件等查询方式,查询结果提供导出功能,便于进一步的数据操作.
5.
2.
1.
3数据支撑服务为了学校业务应用系统能访问数据中心平台的数据,数据中心平台的业务系统提供了标准WebService数据接口.
由于各应用业务系统需要访问数据中心平台的数据是不相同的,需要的访问服务接口也不一样,因此,数据中心平台管理员需要根据各应用系统的需求,灵活订制出符合业务系统需要的数据服务接口.

另外提供定义的数据服务接口的对外提供访问权限配置,其管理包括对各个数据服务添加和删除应用系统访问权限.
系统提供可视化的数据服务权限配置,用户只需选中某项数据服务并勾选为其授权相应应用系统,即可轻松完成数据服务权限的配置.
(1)应用系统资源管理管理数据中心的数据消费者、数据生产者信息.
将学校应用系统或平台的基本信息及IP认证信息录入到数据中心,数据服务应该授权给已有的应用系统.
列表显示应用系统名称、应用系统IP地址.
(2)数据服务资源管理管理员在此处发布需要共享出去的数据,管理员可以灵活的对已有的服务进行发布与停用操作.
(3)数据服务权限配置将数据服务的权限配置给数据中心上创建好的应用系统.
为了阻止非法用户访问数据中心平台的数据,数据中心平台需要提供基于角色的授权访问控制策略.
主要功能包括:创建用户及权限分配,系统功能资源的管理,角色创建以及权限分配,管理员可以将角色分配给用户,也可以直接将系统功能的使用权授予给用户,实现用户授权的简洁性和灵活性.
5.
2.
2.
2技术规格要求(1)采用开放、标准的数据库设计,支持跨平台部署.
对数据库中的表与数据项都提供中文注释.
(2)#支持对外提供开放的数据访问服务接口,并实现对服务接口的管理,支持对服务接口名称、接口方法的查询和编辑,以及对接口的授权管理.
提供统一数据访问接口及管理软件著作权登记证书.
(3)遵循"谁产生、谁维护"的原则,所有的数据都有特定的产生者和维护者.
在技术上,由授权体系控制数据维护的权限,没有该数据权限的人员不能对数据进行操作.
同时,在管理上,通过制定相应的应用规范迫使数据生产者/维护者及时更新自己负责的数据,从而保证任何业务数据的添加和修改不影响其它业务系统的正常使用.
(4)#数据中心体系的建设需要按照数据类型、用途等特点分层次进行设计.
从逻辑上,数据中心体系应包含四层不同的架构设计(包含原始层、主题层、统计层、应用层).
要求投标人在投标文件中给出具体的分层设计方案.
5.
2.
2数据交换平台建设5.
2.
2.
1功能要求(此功能要求需要现场演示)数据交换平台由三大部分组成,分别是:可视化的设计平台、任务调度管理平台、任务执行引擎.
三大部分的功能要求分别如下:5.
2.
2.
1.
1可视化的设计平台#提供数据交换的可视化设计软件著作权登记证书.
1)可视化的设计界面提供数据交换任务的可视化编辑与设计界面,通过图形化界面的拖、拉、拽操作,把业务组件组合成数据交换的任务流程,无须编码即可完成数据交换任务的设计.
2)数据整合组件为满足学校对数据清洗和整合业务的需要,要求数据交换平台内置150个以上数据整合组件,以保证学校可以通过快速选取组件完成作业设计.
要求提供功能截图并加盖原厂公章.
数据整合组件应包含以下内容:加密组件:包含对称加密/解密、生成密钥.
输入组件:包含Access输入、CSV输入、Excel输入、FTP输入、GAZIPCSV输入、Json输入、LDAP输入、LDIF输入、Mondrian输入、ORACLE日志分析、palo单元输入、palo维度输入、RSS输入、SAP输入、XBase、XML文件输入(StAX解析)、XML输入、XMLA输入、YamI输入、元数据表输入、固定宽度文件输入、序列化文件输入、数据库信息输入、文件内容输入、文件文本输入、生成记录、生成随机数、自定义常量数据、获取子目录名、获取文件名、获取文件行数、获取步骤结果文件、获取系统信息、表输入、资源库文件信息输入、邮件信息输入、配置文件输入.
输出组件:包含Access输出、Excel输出、FTP输出、Json输出、LDAP输出、palo单元输出、palo维度输出、RSS输出、SQL输出、XML输出、元数据表输出、删除、序列化文件输出、插入/更新、数据同步文本文件输出、更新、自动文档输出、表输出、配置文件输出.
转换组件:包含SQL解析、XSL转换、值映射、分组序列、列拆分为多行、列转行、剪切字符串、去除重复记录、唯一行(哈希值)、增加XML列、增加常量、增加序列、增加校验列、字段选择、字符串操作、字符串替换、将字段值设置为常量、拆分字段、排序记录、数值范围、行扁平化、行转列、计算器、设置字段值、闭合生成器.
应用组件:包含克隆行、写日志、发送信息至系统日志、发送邮件、启动一个进程、处理文件、延迟行、改变文件编码、替换NULL值、流的元数据、设置值为NULL、运行SSH命令.
流程组件:包含ETL元数据注入、单线程、数据流优先级排序、根据Java表达式过滤记录、检测空流、空操作、筛选(SweichCase)、终止、识别流的最后一行、过滤记录追加流、阻塞数据、阻塞数据直到步骤都完成.
脚本组件:包含Java代码、JavaScript代码、公式、执行SQL脚本、执行数据流中的SQL脚本、正则表达式、自定义Java表达式.
查询组件:包含HTTPPost、HTTP客户端、REST客户端、Web服务查询、代码表查询、执行动态SQL、数据库查询、数据库连接、检查web服务是否可用、检查文件是否存在、检查文件是否已被锁定、检查表是否存在、检查表里的列是否存在、模糊匹配、流查询、调用存储过程.
连接组件:包含XML连接、排序合并、记录关联(笛卡尔输出)、记录集连接.
数据仓库组件:包含维度查询/更新、联合查询/更新.
校验组件:包含使用XSD检验XML文件、数据检验、检验邮件地址.
统计组件:包含分组、前后行查询、在内存中分组、数据采样、样本行、转换步骤信息统计.
作业组件:包含从结果获取文件名、从结果获取记录、复制文件名到结果、复制记录到结果、获取变量、设置变量.
映射组件:包含映射(子转换)、映射输入接口、映射输出接口.
批量加载组件:包含ElastiSearch批量加载、Greenplum批量加载、Greenplum加载、Infobright批量加载、IngresVectorWise批量加载、LucidDB流加载、MonetDB批量加载、MySQL批量加载、Oracle批量加载、PostgreSQL批量加载、TeradataFastload批量加载.
内联组件:包含Socket写、Socket读、记录注射.
3)数据库操作控制台用于进行底层数据库访问的图形化操作界面,支持常用的数据库SQL语句操作,支持的底层数据库涵盖了主流的数据库类型,包括:Oracle、Mysql、MSAccess、MSSQLServer、IBMDB2、AS/400和Sybase.
数据库连接、数据交换任务可根据数据库连接访问不同的数据库,支持对数据库连接信息的创建、浏览、删除以及修改功能.
4)本地运行调试数据整合任务可以在本地运行,以便进行正确性的调试;具备数据交换运行日志查看功能.
5.
2.
2.
1.
2任务调度管理平台1)数据整合任务审核针对设计平台发布的新的数据整合任务,需经过部门用户或系统用户的审核才能在任务调度管理平台中进行调度、启动.
2)数据整合任务调度可根据具体的需要灵活地配置数据整合任务的启动方式,支持手动即时启动、定时自启动和周期自启动三种类型.
3)数据整合任务信息管理支持对数据整合任务基本信息的删除、修改、查询以及运行历史查看的操作.
4)#业务建模实现数据整合任务在任务调度管理平台的图形化拖拽式定义,无须编码即可完成学校各个业务部门的数据整合业务的配置,便于对数据整合任务运行时状态和数据吞吐流量的实时跟踪监控,支持对运行状态的数据整合任务进行暂停/恢复、中断操作.
(要求提供功能截图并加盖原厂公章).
5)数据整合任务回收站支持对已注销的数据整合任务的查看、彻底删除和还原功能.
6)#数据整合报表对数据整合任务的运行状态进行统计和分析,为管理人员提供直观的数据整合报表,方便实时监控.
包括:运行记录统计:查看指定的时间段内的数据整合任务运行次数,运行成功率比例和每次运行记录的详细日志信息.
部门数据整合任务统计:对所有部门的数据整合业务进行统计,以及产生的部门数据整合业务进行统计,支持查看最近一次数据整合业务运行的时间.
数据吞吐量的统计:提供数据交换平台所完成的每条数据整合任务的数据吞吐量的统计.
在线统计:查询在线用户以及在线数据整合客户端.
7)第三方应用整合服务面向第三方应用程序开放数据整合服务接口,实现与第三方应用系统的整合与集成.
对外安全授权:对第三方应用进行身份认证信息管理和数据整合授权管理.
第三方应用、数据调用、整合服务必须持有数据交换的身份授权信息,且只能操作被授权的数据交换任务,以保障用户的数据安全.
跨平台开放的数据整合服务接口:对外提供跨平台的数据整合服务接口,完成第三方应用对数据整合任务的管理、运行监控、消息订阅、输出文件、数据的回执等功能.
数据整合服务配置管理中心:提供对数据整合服务的相关配置参数信息的管理操作.
平台资源管理:实现清洗与整合平台的资源和资源权限的管理.
资源管理提供针对于系统资源的增加、删除、修改、查询等操作,支持采用通配符的方式进行系统资源的定义.
资源权限管理定义访问系统资源需要的相关身份信息,资源权限管理能为系统用户提供对资源权限的增加、删除、修改、查询等操作,并支持为账号授权、撤销授权操作.
8)#消息定制服务提供系统性能预警、业务数据源监控和数据整合任务运行监控的消息定制服务,支持短信、电子邮件以及网页即时消息三种发送方式,接收对象包含平台内用户、外部手机或邮箱,且支持用户自定义消息内容.
5.
2.
2.
1.
3任务执行引擎(1)任务执行引擎将数据集成任务的运行信息进行解析与执行,并在执行的过程当中通过远程传输协议将数据集成任务的运行状态和运行进度实时地反映在任务调度管理平台.
整个处理过程完全自动而无需人工干预.

(2)数据集成任务执行引擎可直接内置于任务调度管理平台当中,也可以单独的部署在其它服务器之上,用户可根据实际的硬件配置与业务需求情况进行自由的选择.
(3)任务执行引擎能够实现远程集群部署以及并行执行多个数据整合任务,提供自动分配、手动选择两种方式选择执行引擎.
(4)数据整合服务远程注册.
(5)执行引擎能在启动之后自动寻找任务调度管理平台进行服务的注册,通知任务调度管理平台已经准备好接受调度执行数据交换任务.
(6)任务运行状态监控服务.
#要求提供数据交换的监控软件(或相关名称)的著作权登记证书.
(1)执行引擎能在运行数据整合任务的过程中实时的将数据整合任务的运行状态反馈至任务调度管理平台,并向任务调度管理平台提供数据整合任务的暂停/恢复、中断服务.
(2)任务处理进度反馈执行引擎能在运行数据交换任务的过程中实时的将数据整合任务的处理进度信息反馈至任务调度管理平台,包括:数据整合任务总体数据吞吐量和数据交换任务步骤数据吞吐量.
(3)任务日志信息服务执行引擎能在运行数据整合任务的过程中完成对数据整合任务运行日志的记录,并将日志信息进行临时存储,向任务调度管理平台进行反馈.
(4)性能负载信息监控服务执行引擎能自启动开始便实时的对本地JVM使用率、物理内存使用率、CPU使用率等本地性能负载信息进行收集,产生其自身的性能快照反馈至任务调度管理平台.
5.
2.
2.
2技术规格要求(1)学校现在已有应用系统为各个应用厂商所建,采用不同的数据库,因此在数据交换平台必须支持国内外主流数据库.
(2)要求数据交换平台支持松耦合产品架构体系,能够灵活的适应业务流程的变化,保证更新一个模块不会引起其它模块的改变.
(3)#数字化校园是长期发展的过程,后期将会接入更多的应多系统,数据处理量将会大大增加,为保证系统的数据处理能力,要求系统支持"多引擎",并拥有智能的集群负载均衡能力.
(4)学校的数据整合与集成涉及到很多部门和人员,需要提供灵活而高细粒度的权限控制.
其安全认证体系必须基于URL拦截与ACL控制列表访问技术,对系统完成灵活而高细粒度的权限控制,能有效的针对系统级权限、功能级权限、资源级权限和数据级权限进行控制与保护,并且允许根据实际需要进行各种权限控制规则的自定义,自定义的权限规则即时生效无需重启服务器.
(5)为了防止建成即落后的局面出现,要求采用最新的、适应性最强的HTML5技术实现数据整合任务作业的图形化设计,并采用WebSocket技术实现前台页面与服务器后台的实时通信,提高系统性能.
(6)为了保证在数据整合与集成过程中的数据源的安全,要求支持"多用户"数据整合管理,为学校不同的部门提供独立的账号来管理各自的数据整合作业.
(7)为了保证数据整合与集成过程中的数据安全,要求数据传输支持加密传输技术.
(8)根据学校现状和未来数字化校园的发展,学校的各个应用系统不可能绑定一家厂商的数据库,因此要求数据交换平台采取独立于数据库厂家的ETL技术,完成数据交换工作.
(9)要求提供基于业务的数据整合影响分析功能,让用户能够清晰地了解到数据整合对业务的影响与效果,进而使得数据整合进程对用户更加透明化,帮助学校快速定位业务死角与信息孤岛.
(10)从产品易用性角度考虑,要求数据交换工具不需要任何编程即可实现复杂的数据交换操作,支持以拖、拉、拽的方式对业务流程进行绘制——只需通过简单的拖、拉、拽各种内置的数据整合组件与数据整合任务的简单配置,即可完成数据交换任务的定义与设计.
设计完成的数据整合任务由系统自动执行,正常状态下整个过程无需人工干预.
5.
2.
3综合信息门户平台5.
2.
3.
1GIS平台建设要求要求建设GIS系统,包括基础构件、基础信息呈现、人员分布和潮汐分析、行动轨迹和边界分析,并且要与门户系统进行对接,可以通过门户系统进行访问GIS系统.
5.
2.
3.
2门户平台框架要求采用主流的PORTAL框架,必须支持JSR168以及JSR286标准,以保证任何遵循此标准实现的portlet组件可平滑的迁移到信息门户平台.
平台框架须支持CAS统一认证协议,支持与身份认证系统的无缝集成.
平要求能够实现多种服务集成方式,包括(但不限于)带身份认证的超链接集成、页面集成、WebService服务集成等.
平台需要有灵活的可配置性,能够以模板技术的形式在线动态创建功能组件,并实现与标准WebService服务,数据库服务的数据交换.
平台的主要功能均以插件的形式体现,各个插件相互独立,可以单独选择、组合以及增减.
支持动态集群部署,可以弹性的部署多个低功耗节点,支持虚拟化技术,其并发性可达到学院全部师生访问的理论峰值.
任意节点宕机不影响系统整体运行.
5.
2.
3.
3个性化管理要求平台可内置2种以上不同色彩风格的主题供用户任意实时切换.
细粒度的权限控制.
信息门户权限可通过用户、部门、角色三方面来进行分配,并且提供具体到功能模块和栏目进行权限分配操作的细粒度的权限分配功能:1)用户的权限通过角色来进行控制,一个用户可以拥有多个角色.
2)用户拥有不同角色时,其权限应该是多个角色相互的并集.
3)每个角色可拥有任意一个应用的操作权限.
4)用户的前台菜单依据用户角色权限所拥有的模块来决定,不同的用户在前端显示的操作菜单不同.
5)可以针对单个用户进行特殊设置.
5.
2.
3.
4通用信息服务要求要求信息门户能实现各类不同来源的新闻信息展现,如院部新闻、学院新闻、班级通知、教务公告、学生处公告、新闻公告管理、新闻发布功能.
信息门户能实现访问统计功能及其它公共服务,如个人基本信息、单点登录、意见反馈、问卷调查和投票、通讯录、校历、友情链接、作息时间、天气预报、常用工具、校车时刻、信息查询、访问统计功能.
消息提醒,集成各个系统,将用户所关心的重要数据以推送的方式第一时间告知用户.
消息提醒包含OA待办事项、最新邮件信息、最新通知、一卡通费用明细、工资情况以及图书借阅情况多个应用系统的多个维度的数据统一到一处进行展现.
用户不仅可以自由订阅这些消息,还提供自动提示功能,方便用户第一时间了解最关心的情况.
5.
2.
3.
5门户轻应用功能要求在轻用建设方面,本期建设要求包含一周会议、重要提醒等4类轻应用服务,轻应用的建设将在实际工作中根据学校实际需求情况再利用门户配置工具配置.

5.
2.
3.
6技术规格要求技术规格要求1、平台必须具有统一的交互标准和界面标准,同时又能根据用户角色和权限进行相应的动态化、个性化页面配置.
2、保证门户平台能够低成本、快速地响应需求的变化,要求管理人员经过简单培训即可独立完成应用创建、更新应用的功能和内容.
3、门户的响应速度是非常重要的,为增强用户体验,平台应运用最新的开发平台技术,以达到动态交互的效果.
4、为保证数据安全,要求门户平台具有备份、容灾机制,可使用任意时间点备份进行相关应用的恢复工作.
5、平台可内置2种以上不同色彩风格的主题供用户任意实时切换.
6、系统提供7*24小时不间断运行服务保障,采用先进的技术手段,保证平台运行稳定性,并且建立有效机制防止系统错误或意外中止.
5.
3统一身份认证统一身份认证平台作为数字化校园的安全认证及授权中心,需要提供统一认证、授权访问控制和管理工具,对所有数据进行立体的控制和管理,确保数据的安全性.
学校所有用户要通过统一信息门户实现单点登录,在数字化校园的整体建设上避免重复投资.
统一身份认证平台要基于4A标准规范,全方位的解决了高校在统一身份(Account)、统一认证(Authentication)、统一授权(Authorization)、安全审计(Audit)四个方面的管理与安全问题.
5.
3.
1功能要求(此功能要求需要现场演示)一集功能二级功能功能描述1、我的应用支持系统应用并通过多种方式将业务系统接入到该模块,以图标的形式呈现,并可根据需要选用所需系统进行单点登录.
2、统一认证管理(1)支持学校学生、教师及其它用户角色通过平台统一认证服务,将众多校内和校外应用纳入信息门户平台之中,提供多样化应用认证方式,包括:CAS认证、LDAP认证、OAUTH、COAP认证等,提高信息安全更高层次身份认证需求.
(2)多种认证方式可有效支持PC端B/S系统认证等.
3、应用管理设置(1)系统应用管理支持对平台中系统应用的管理,包含功能有:添加应用、查看权限、修改应用、删除应用、禁用应用、指定管理员、管理成员等功能.
支持多种方式的应用系统接入,有效满足不同学校、不同用户的需求.
CAS接入、登录助手、超链接,OAUTH应用、COAP应用.
CAS接入:第三方应用系统提供接口,通过CAS接入方式,实现应用系统的单点登录.
登录助手接入:通过对登录表单的简单配置,所有用户均可轻松实现应用的添加和管理.
支持智能获取应用系统登录信息,不用编码、不用厂商协助.
超链接接入:通过配置应用访问地址,所有用户均可轻松实现应用的添加和管理.
OAuth接入:实现对通过OAuth协议接入的应用系统的添加和管理.
COAP接入:实现对通过COAP协议接入的应用系统的添加和管理.
(2)应用系统授权支持指定应用系统管理员,激活/禁用系统,为应用系统分配访问用户.
(3)自定义应用管理支持平台中用户自定义应用的管理,包含功能有:添加应用、修改应用、删除应用、添加到通用、查询应用5个功能.
(4)用户创建管理支持查看用户创建的所有应用,查看应用的创建次数,可禁用不符合规范的应用,支持将应用添加到通用.
4、组织机构(1)部门管理支持管理员、部门领导对学校部门进行管理,支持增、删、改、查等操作,以及导入外部数据,导出数据.
支持针对部门名称进行搜索.
(2)岗位管理支持管理员对学校岗位进行管理,操作:增、删、改、查,查看岗位所属关系,及岗位成员.
(3)角色管理支持采用基于角色的访问控制策略,对用户和用户组赋予相应的角色,针对学校不同职能部门定义不同的角色,同时根据用户的责任和资格来分配角色及角色中添加和撤销权限.
(4)用户组管理支持管理员、组管理员对学校用户组进行管理,操作:增、删、改、查,查看用户组所属关系,管理组成员,指定各组管理员.
5、身份管理(1)支持包含学生、教职工、师资、院系、性别等用户的统一身份库,实现各应用系统与统一身份库之间的用户信息交互;实现用户账号的统一管理、查询和统计功能;能指定用户身份数据的权威数据源,实现用户信息同步.
(2)支持从LDAP、EXCEL快捷导入用户身份数据.
(3)支持按条件进行查询,支持孤账号管理,支持高级检索和批量操作(包括批量重置密码、批量删除、批量身份信息激活和禁用).
6、统一权限采用分级授权以及多级授权模式,通过对部门、岗位、用户组、角色、用户的授权,实现用户权限的继承;系统管理员可将个别应用的管理权限下放到下级单位,实现应用权限控制的精细化、全面化、合理化.
(1)部门授权支持管理员、部门领导对整个部门进行授权,实现大批量用户授权,不同部门将会授予不同权限.
(2)岗位授权支持管理员对所有岗位进行授权,实现不同岗位的不同权限.
(3)用户组授权支持管理员、组管理员对用户组进行授权,实现不同用户组的不同权限.
(4)角色授权支持管理员对整个角色成员进行授权,实现不同角色的不同权限.
(5)用户授权支持管理员、组管理员对用户组进行授权,实现不同用户组的不同权限.
提供详细统计报表服务,统计用户的使用情况和异常情况,直观反映整个数字化校园的运行使用情况,通过多维统计分析为校园信息化的未来提供新的建设思路.
同时对异常情况有效监控,帮助管理员及时发现问题和异常.
7、安全审计(1)应用访问统计支持管理员、校领导、部门领导统计所有应用系统的访问情况,及访问日志.
应用访问统计以图形比例形式展现,用户可查看访问的前十个应用名称,了解应用类型、访问次数,所占百分比,可了解环比前日所访问系统应用是上升或下降趋势以及增加量情况.
(2)院系访问统计支持管理员、校领导、部门领导统计各个院系访问应用系统的情况,以及访问日志.
可选所有系统、或单独进行查看.
支持查看各个院系环比前日日访问量、访问趋势情况以及增加量.
(3)实时访问统计支持管理员、校领导、部门领导查看各应用系统,各院系的实时访问情况.
支持按应用查看及院系查看,可根据需要选择时间与系统进行查看.
(4)访问趋势统计支持管理员、校领导、部门领导查看学校不同时段,不同院系相应系统的访问量.
支持按小时及院系查看.
(5)应用助手使用统计支持管理员应用助手帐号使用统计.
包含系统应用及自定义应用,可观察到应用助手名称、应用类型、激活用户数量及排名.
(6)IP防火墙支持管理员指定IP白名单和IP黑名单.
添加IP地址、更新IP地址,IP类型且可进行相应描述.
(7)安全策略配置支持管理员配置统一身份认证平台的账号、密码、日志、权限、SSO等安全策略.
账号策略具备锁定规则,允许错误密码次数,设置锁定时间.
密码策略需对密码复杂性、最小长度进行设置.
日志策略对登录、登出、应用访问可进行选择,记录/不记录.
权限策略对创建自定义应用、应用管理员删除应用、组织机构管理员删除组织机构可进行选择,允许/不允许.
SSO策略包含IP是否绑定、防火墙设定是否开启、以及防火墙名单设定,只认黑名单/只认白名单.
(8)用户活跃度统计支持管理员按活跃类别统计,可分院系、全校、部门、角色查看,支持统计时间段自定义,可忽略假期,支持活跃间隔基数自定义,了解全校活跃概况.
(9)访问次数统计支持对全校学生、教职工最近7天、甚至最近30天学校访问概况进行统计.
可观察用户类别以及登录次数,并以用户访问量趋势统计进行呈现.
(10)登录登出日志支持查看用户登录操作时间、目的访问地址等.
收集身份管理平台各个服务组建所产生的日志,经过分析、筛选、归并、记录在管理控制台的数据库中,通过管理控制台可以查询这些日志,并对认证客户端的流量、类型、IP地址等信息作明细跟踪和后续分析,提供对所有审核信息的查询检索功能.
(11)平台分类统计支持管理员统计统一身份认证平台的访问量及登录情况.
可分为教职工、学生,支持按小时、天、周、月、年进行查看,支持查看登录比例情况,如:密码错误、被限制登录、登录被锁定、其它错误及登录成功.
(12)登录异常统计支持管理员按登录异常类型统计,可分院系、全校、部门、角色查看,支持统计时间段自定义(今天、昨天、最近7天、最近30天,自定义).
8、系统管理(1)系统显示配置支持管理员配置统一身份认证平台,系统管理员可以在web页面针对系统所需的各个参数进行轻松简单的配置,如:安全策略配置、LDAP接口配置、SSO用户信息配置等.
可进行系统显示配置:系统提供多套主题以供选择,能有效实现登录界面、页面信息、显示学校名称、Logo、页面文字描述、邮件信息、系统跳转异常提示描述等信息,支持自定义主题、登录页,同时支持登录页面源码编辑.
(2)LDAP接口配置支持管理员配置LDAP接口.
包含连接地址/端口号、LDAP连接账号、LDAP连接密码、用户信息存放路径、查询用户过滤条件及登录账号存储属性.
账号存储属性用于登录界面帐号密码LDAP同步验证,也是LDAP导入数据时导入用户帐号(loginId)LDAP中所对应属性.
(3)SSO用户信息配置支持管理员统一身份认证平台SSO用户信息配置.
唯一信息标识配置、拓展用户信息列表.
统一信息标识中唯一信息标识分为:学生:学号,教工:身份证号;学生:学号,教工:职工号两种.
拓展用户信息列表中拓展信息列表包含:角色信息、部门信息、院系信息、专业信息、用户基本信息、岗位信息、年级信息和班级信息.
(4)系统灾备支持管理员备份平台的用户信息及权限信息,重置系统.
系统管理员可通过浏览器一键式完成对整个应用系统数据库的备份、还原和重置,轻松、快速完成数据库的灾备处理.
(5)系统资源性能监控支持管理员了解CPU、内存的运行及占用情况.
对CPU、内存、网络使用情况进行实时监控,通过图形化展示方式直观反映系统运行情况.
对接入单点登录系统的服务状态进行监控,有效帮助系统管理员及时检测和发现系统异常.
(6)数据还原支持管理员对教职工、学生数据批量还原、删除,支持按姓名、职工号/学号查询.
建立的数据回收站机制,有效实现对误删教职工、学生数据的一键还原.
5.
3.
2技术规格要求(此要求需要现场演示)技术规格要求1、为平台的用户提供身份认证,建立通信信任关系,保证身份的真实性、信息的保密性、完整性.
2、统一身份管理(1)建立全校统一的身份库,该身份库包含用户资料信息、人员信息、人员的登录认证等.
(2)完全基于WEB界面,加密传输,无需专用客户端.
(3)用户信息采取实名制,管理员基于用户实际身份和基本信息建立独立且唯一用户账号.
(4)系统应具有良好的稳定性和集成性,提供多种成熟认证接口.
3、先进的技术和安全策略(1)整体部署安全机制、日志审核和访问策略等多种控制手段保证平台高度安全,遵从国家有关法律中关于用户账号安全的标准.
(2)对用户的操作行为进行日志记录,以追溯用户的行为过失,确保数据安全.
(3)对用户登录密码在传输过程和存储方面进行不同程度的加密处理,以保证敏感信息的安全性.
4、具有单点登录功能,用户只需要登录(认证)一次,就可以访问符合身份权限的应用系统,避免用户密码过多导致密码遗忘或遗失.
5、具有密码恢复功能,用户不慎遗失密码时,可通过该功能,输入设置密码时填写的验证信息恢复密码,以减轻系统管理员的负担.
6、采用灵活的基于角色的权限管理模型.
7、定制不同粗细粒度的访问控制策略.
8、用户身份数据采用数据交换平台来进行身份数据的同步,统一认证中心与业务应用系统身份数据库相对独立,但相关身份数据又保持同步,最大限度的保证原有系统的运行不受资源整合所影响,保障各系统的独立与数据安全.

5.
4数据可视化平台建设建设数据可视化系统将教育行业中现有的数据进行有效的整合,快速准确的提供报表并提出决策依据,帮助领导者实时的了解整体情况,并做出明智的决策和.
数据可视化要保证实时连接数据中心,同时支持文件上传、三方数据源等各种数据来源,探索式分析方式,保证业务人员无需拥有程序知识,也可以使用业务数据完成设计.
数据可视化系统拥有多种分析图表类型,给使用者带来全新的视觉感受.
其中包含多种常规图表和多种大数据可视化图表效果这些非传统交互式可视化效果.
并且,数据可视化系统拥有领先的仪表盘设计功能,能像绘图软件一样,直接快速的设计出漂亮的交互性展示页面.
5.
4.
1功能要求(此功能要求需要现场演示)5.
4.
1.
1数据源管理数据接入是进行数据分析的第一步,数据分析员(管理员)可以方便快捷的将所需要数据进行上传,数据分析员(管理员)可以使用文本数据上传(支持Excel)或接入数据源"数据库",接入数据可在工作表视图中查看.
5.
4.
1.
2仪表盘仪表盘相当于一个可编辑的页面,由多种组件组成.
数据分析员(管理员)可以创建一个空白仪表盘,相当于一个工作台,可以从组件库中选取一个组件,拖放到仪表盘中,可以对组件进行移动,或进行编辑,形成美观的数据分析仪表盘.
最后可以选择赋予权限给某些用户或用户组(比如教务用户组、人事用户组等).
组件是指仪表盘上基本的可交互图形部件.
组件包含,分析图,边框,装饰,iframe,单张图片,轮播图,时间器.
5.
4.
1.
3分析图[分析图]指一张单一的图表(如饼图,柱状图等).
分析图可以是可视化的核心功能,将数据库文本等表格转化为图形,并在仪表盘上对分析图进行外观属性的编辑,在分析图中进行数据的编辑.
5.
4.
1.
4站点管理用户可以对站点进行归档,归档后可在"我的归档站点"中查看.
用户可以对站点进行设置,包括:名称、状态(激活、禁用)成员(角色)的增删改查.
对该站点创建一个副本,名称为:XX站点的副本.
直接进入首页、数据源、管理、站点.
5.
4.
1.
5系统管理系统管理具备以下功能:(1)账号管理,账号的增删改查;(2)角色管理,角色的增删改查;(3)系统配置,配置用户权限,配置权限,可以配置主题样式,配置首页;(4)菜单配置,可以为系统配置菜单,菜单支持层级的增加、移动和删除;(5)主题配置,对主题样式颜色进行配置.
5.
4.
1.
6图片管理支持上传,删除图片.
上传的图片可以作为配置仪表盘的素材使用.
5.
4.
1.
7权限管理应提供权限管理功能,用来设置用户在系统中的权限,包括功能权限与数据权限.
要求支持动态渲染权限功能,各类可视化分析页面能在渲染后赋予数据权限,并对数据权限进行管理,达到"同一个分析页面不同角色不同内容",省去绘制多种分析页面的步骤.
5.
4.
2分析模型内容(此功能要求需要现场演示)1)人事主题在学校层面的人事数据分析,通过对学校的人事部门数据进行采集、整合、共享及利用,将教职工人事信息可视化.
在人事需求分析系统上,需要实现将学校人事处、教务处、科研处关于教职工的人事信息进行有效整合,实现不同层次的比较,使得整个学校发展情况实现可视化.
提供"人事"主题仪表盘,并有机整合,为人事业务提供决策分析数据支撑.
分析模型包括:在校教师学历分布、在校教师各院系学历分布、在校教师各单位人数分布.
实现"人事管理":该功能需要采集的数据分为两个层面,第一是教职工个体人事行为数据,例如教职工进修、退休;第二是采集校层面的数据,进行宏观的分析,包括但不局限于全校师资情况,校内人才引进情况、校内事业编制、非事业编制教职工情况.
数据经过清洗和完善,建立"人事管理"分析模型,用可视化图标显示校内人事管理具体情况,展示各学院人事情况,帮助学校评估各学院师资力量具体情况,为学校高层进行人事决策提供参考,从而提高档案价值,分析模型包括:在校教师来源分布、教师返聘率、在校教师编制类型分布、在校教师编制类型按学院分布、在校教师留学归国情况统计.
2)教务主题教务分析决策模块基于学校教务管理系统收集的大量的操作数据,并从这些数据中统计分析出教师教学评价、学生学习效果评价以及班级、专业、院系、学校的学习和管理评价;指导教师教学改革,提高学生学习效率,定位专业发展和人才培养方向,为教学管理制度的改进提供数据支持.
并根据教务系统数据情况,提供数据导入功能.
系统可根据导入数据及数据中心已有数据进行数据建模分析.
提供"教务"主题仪表盘内包含多个教务相关数据分析模型,并有机整合,为教务业务提供决策分析数据支撑.
实现"课程教学分析":通过采集教务模块及与教学计划相关的其他业务系统数据,将数据整合分析,提供包括多年教学趋势变化图,能反映出多年来各个院系在师资投入,学生数量及教学成果方面的情况和变化趋势.
需结合校历做重点数据呈现,根据重点信息分析出教学计划完成情况,通过简单明细的仪表数据呈现专业及课程建设情况,辅助分析教学制度实施成效,为教学计划制定提供支撑,供教务决策层进行教学制度改革.
实现"考务分析":通过采集考务相关数据源,包括但不局限于校内考试情况、校内英语水平考试相关信息、计算机水平考试相关信息,显示全校水平考试成绩发展趋势,显示各类考试占比,为学校为学生提供热门考试资源指导方向.

实现"教学评估与分析":通过简单关联分析学生评教情况与学生成绩及教师教研能力,为优秀教师衡量标准和开课方向提供支撑;其次,需要梳理教学任务与教学质量的关联关系,为学校发掘有潜力的优质教师.
3)学工主题根据学校的具体情况,需要对校内学生工作的相关数据进行分析,提升学校创新创业、学生服务工作的水平.
提供"学工"主题仪表盘内包含多个学工相关数据分析模型,并有机整合,为学工业务提供决策分析数据支撑.
模块功能需要分两部分建设,一是从整体出发,对全校整体创新、先进评选,学生管理宏观分析;二是从学生个体出发,针对重点问题学生可进行全面分析与监控,提升奖学金发放、优秀评选等学生工作的准确性,降低投诉率,对于优秀学生选取,提供具体支撑信息,帮助学校选择优秀样本进行示范性提升总体学生工作的满意度,并预防严重的学生问题事件发生.
分析模型包括:在校本科生来源分布、在校学生奖学金统计.
4)图书馆主题建设"图书情况决策模块",主要是基于学校的图书管理系统以及学校其它系统相关数据的基础上,针对不同读者个体某个时间段在图书馆的所有活动数据进行行为统计、分析、展示.
提供"图书馆"主题仪表盘,包含多个图书管理相关数据分析模型,并有机整合,为图书管理业务提供决策分析数据支撑.
实现"图书借阅分析":通过图书馆图书资源使用状况和借阅数据,分析图书资源的利用情况、图书借阅的变化趋势,从而整合全校的整体情况,得出学校图书借阅的合理性,便于学校有效引导学生的课外阅读,加强学生的专业学习;分析模型包括:图书每月流通量、最热图书借阅.
实现"图书馆管理":通过图书资源情况,综合分析图书馆财务状况,例如制定图书馆的图书采购和预算、人力投入和管理等工作提供决策分析和参考依据.
分析模型包括:图书分类、图书馆藏书量统计、馆藏图书量最多的top100.
5)领导驾驶舱需定制领导驾驶舱大屏,提供全校总体发展现状和实时运行情况数据分析支撑,提供学校在全国或目标群里的地位分析,提供学校在其在任期间的进步和成效分析,提供对总体工作开展的管理支持分析支撑,例如双一流建设情况、本科教学评估和学科评估数据分析支撑,提供教学安排、学生管理、资产投入情况分析.
6)资产主题资产的合理配置在高校发展中起着重要作用,通过信息化技术,借助大数据手段,对学校的固定资产及其他资产数据进行采集、转化和有效分析,为学校的资产有效管理提供支撑,从而提升学校资产管理质量,推进学校的可持续稳定发展.
提供资产主题仪表盘包含多个数据分析模型:(1)实现对固定资产大类的分析及变化跟踪,并对不同类型资产进行对比分析,辅助资产均衡管理,如教学类、科研类、行政类、生活后勤类资产对比分布;(2)对设备、房产、后勤、能源、医务数据进行独立建模和全面分析,例如对能源使用群体分析、各类型能源消耗分析及趋势跟踪、节能分析.
5.
4.
3技术规格要求(1)#支持oracel\mysql\sqlserver数据源管理(要求提供功能截图并加盖原厂公章)(2)#支持excel的上传和管理(要求提供功能截图并加盖原厂公章)(3)#控件种类包括文本控件、边框控件、图形控件、iframe、图片、轮播图、时间器、通用控件、筛选控件、提示控件、tab控件(要求提供功能截图并加盖原厂公章)(4)#数据筛选,用户可以选择对数据源表中某单个字段的数据记录(如果纪录超过n)进行精确筛选或条件筛选,对数据范围进行限制,这样在数据分析图中就只会出现经过筛选的数据(要求提供功能截图并加盖原厂公章)(5)#权限设置,将某些人能够看的权限进行设置,实现不同用户看同一张表显示不同数据(要求提供功能截图并加盖原厂公章)(6)#运算,根据不同的字段类型在数值轴时,进行运算(数字有求和、平均值、计数、去重计数)(文字有计数、去重计数)(日期有计数、去重计数)(要求提供功能截图并加盖原厂公章)(7)#显示属性,显示缩略轴、条目数、数值轴显示方式.
(8)#图表联动,两个不同的图表可以通过设置联动条件,做联动分析(要求提供功能截图并加盖原厂公章)5.
5数据整合要求本次项目建设要求实现学院不同系统(人事系统、教务系统、科研系统、财务系统、资产业务系统、OA办公系统、图书馆系统及一卡通系统)数据的整合管理.
5.
6软件著作权要求为保证承建方所投产品是成熟的,无版权纠纷问题,要求相关软件产品具有自主知识产权的软件著作权证书,且产品著作权均需取得三个月以上.
具体包括:(1)#要求提供数据交换平台的可视化设计(或相关名称)的软件著作权登记证书;(2)#数据交换平台建设是长期发展的过程,后期将会接入更多的应多系统,数据处理量将会大大增加.
为保证系统的数据处理能力,要求系统支持"多引擎",并提供数据交换的执行引擎系统(或相关名称)的软件著作权登记证书;(3)#要求提供数据访问接口软件(或相关名称)的软件著作权登记证书;(4)#要求提供元数据管理软件(或相关名称)的软件著作权证书;(5)#要求提供数据可视化平台(或相关名称)软件著作权证书.
5.
7其他说明所有建设内容和相关要求,以本方案中"五、建设内容和要求"为准,承建方在编制投标文件时,对该部分内容及要求请逐项予以确认应答.
六、实施要求6.
1时间进度要求本次项目规模较大,系统需求复杂,涉及部门、环节多,预计项目建设周期为175天.
在项目实施过程中将严格按照CMMI5相关标准规范流程,确保每一项过程和需求都有明确、规范的文档记录.
6.
2实施方案本次项目规模较大,系统需求复杂,涉及部门、环节多,要保证顺利有序实施,投标方必须对实施工作作出详尽慎密的组织实施方案,主要内容应包括以下几个层面:(1)组织架构与职责描述项目成员的组成,以及成员的职责.
(2)实施阶段划分描述各个实施阶段的工作范围、内容、人力投入、过程、责任、交付成果.

6.
3项目管理在项目实施过程中,必须严格按照相关标准规范流程,确保每一项过程和需求都有明确、规范的文档记录,同时承建方确保对实施人员经验、技能和数量的保障.
具体内容如下:(1)系统开发阶段要求1)方案设计承建方应充分调研系统现状及有关详细需求,明确细化具体的建设任务,建设技术路线,建设技术框架以及具体实现的技术方法,形成详细的设计文本.
参考项目确定的总体时间进度、质量等要求,制定项目施工时间进度计划.
同时根据项目的实际情况,进行必要的项目实施风险分析,提出详细的风险规避办法和措施.
明确项目实施需要的技术标准、设计规范以及项目实施的文档规范等,制定项目质量管理和控制、项目进度管理与控制以及软件开发定制文档规范、项目提交成果要求.
系统设计应与校方保持密切沟通并得到确认,遵循统一的标准规范,使用统一的设计模式和统一描述语言.
2)需求分析承建方按照项目实施计划所确定的目标完成需求调查与分析,深入各个业务部门开展需求调研工作,编制需求调研报告和需求规格说明书,在此基础上开发系统原型以确认需求.
3)系统设计承建方在需求规格说明书、系统原型基础上完成系统概要设计和系统详细设计文档.
4)系统开发承建方按照本项目招标要求完成软件编码及单元测试工作.
5)系统测试承建方按照项目实施计划所确定的目标,提出测试方法,制定测试规范,按照测试要求提供系统测试相关的各项报告,功能和性能测试报告文档,包括计划、用例和报告.
6)过程评审承建方完成方案设计、需求分析、系统设计、系统开发、系统测试阶段工作时,须通过校方组织的评审.
(2)部署实施阶段工作要求1)部署实施计划承建方须按照校方要求制定项目部署计划(含工作计划和技术方案),完成系统部署实施工作.
承建方须在投标文件中详细阐述项目部署计划,承诺按照校方要求,可多次派工程师到现场完成部署实施.
2)部署安装承建方根据项目部署实施工作需要对应用系统及配套基础软件进行安装和部署,并通过校方验收.
3)推广培训承建方需按照校方要求制定项目培训的工作计划和技术方案,编制系统的培训教材,并得到校方的确认.
(3)试运行阶段工作要求1)试运行工作任务承建方须参与应用系统的试运行工作,编制试运行工作方案,提供及时解决技术问题的解决方法.
2)试运行故障恢复要求系统试运行过程中如果发生故障,需在48小时内恢复.
七、项目培训要求培训应贯串于整个项目的实施过程中,包括在从项目准备、研发到项目运行的全过程中.
需要提供以下几方面关于培训的描述:(1)培训要求承建方派出的培训教员应具有丰富的同类课程的教学经验和应用经验;所有的培训教员必须用中文授课;承建方必须为所有被培训人员提供培训用文字资料和讲义等相关材料;承建方应按合同规定安排培训时间和培训名额.
(2)培训方式包括课堂讲解、上机操作和实际工作的参与.
(3)培训工作的内容和对象描述承建方进行的培训工作包括了培训方案的设计、培训制度的制定、培训开发、培训实施和培训效果评估,及时监控培训效果,保证培训课程符合我校实际的需要.
在系统运行(含试运行)的各个阶段相应的培训内容描述,培训阶段安排包括:项目管理培训、系统管理培训、系统运行维护培训、系统使用培训等.

八、售后服务保障要求承建方保证该项目按时正式稳定地运行,并承诺提供不少于三年7*24小时免费服务和技术升级.
承建方须免费提供不少于1名工程师在学校驻场服务两年,驻场工程师须具备本项目实施及维护相关的资质和技术能力.
根据对学院相关业务运做的规律来有计划地制定服务保障体系.
关于服务保障体系的描述应具体包括如下内容:应确保各类应用平台安全稳定的运行,需承建方提供不少于3年免费服务,售后服务期自验收合格之日开始计算.
方案中应对服务的范围和内容进行详细阐述,并至少包括以下内容:1)缺陷管理:针对本次建设各类应用支撑平台中存在的bug、缺陷,不论在保期内、外,投标方均应持续提供修正与消缺服务.
2)应急故障处理:系统运行环境出现故障或意外情况导致系统不能正常运行时,需针对不同故障级别的响应时间和响应内容.
3)系统升级:需提供应用平台的软件补丁版本的升级服务.
4)需求变更:对于学校自身业务规则的变化导致的非模块级功能需求变更、性能要求提升导致的部署结构变化,需承建方提供限定次数的服务支持.

5)文档服务:整个服务过程均需有完善的文档记录,便于跟踪、分析问题;每季度对各项服务提供详细的书面报告,包括故障处理报告、健康巡检报告、系统性能检测调优报告、维护总表报告.
6)运行支持:对系统运行过程中师生用户及业务部门的问题提供解答和问题解决跟踪,对于关键业务点的上线推广与运行提供现场保障.
7)服务请求流程需对用户支持或维护请求处理的流程进行详细描述.
8)服务请求方式需要项目承建方提供的服务请求方式至少应包括:服务热线电话和联系人、联系单位信息、信函/传真、电子邮件、服务网站.
九、成果移交要求在本期项目的建设过程中和交付使用后,承建方应该将各个阶段产生的全面、规范的成果和文档资料交付给采购人,而且要提供明确的交付清单.
交付的成果和文档资料必须符合软件工程的相关要求.
交付内容主要包括以下部分:(1)可运行的系统.
(2)技术文档:包括项目开发中的各种技术文档,如开发环境配置说明、软件工具清单、需求分析说明、变更说明、系统设计说明、用户手册、测试用例、测试结果、系统维护说明、系统培训资料以及有关系统接口的技术说明.