智慧校园之校务管理系统技术需求方案158页.docx

智慧校园之校务管理系统技术需求方案158页.docx

《智慧校园之校务管理系统技术需求方案158页.docx》由会员分享，可在线阅读，更多相关《智慧校园之校务管理系统技术需求方案158页.docx（164页珍藏版）》请在冰豆网上搜索。

智慧校园之校务管理系统技术需求方案158页

智慧校园之校务管理系统

技术需求方案

1、项目总体技术要求

1.1.项目系统性要求

1.1.1.系统设计

1、系统整体设计须体现“软件即服务（SOA）”，“碎片化服务”的理念。

除实验室管理系统外，其它系统每一项应用都是相对独立的单元，都是以独立APP的形式存在，都做到高内聚低耦合。

2、系统基础性服务功能应由智慧校园管理支撑平台2统一提供，如消息、任务、日志、评价反馈等，无论是服务应用，还是智慧校园的其他应用系统，通过“服务调用”即可获得相应的功能。

1.1.2.规范性和可用性

本项目各系统须提供统一的UI/UE界面风格。

系统可将需要用户办理的事务直接推送到用户界面，包含待办任务、流程跟踪、周期服务、消息通知等，用户直接点击即可阅读并实现办理，对尚未处理的事务，始终以醒目提示符提醒用户。

1.1.3.可用性和高性能

系统不限制用户注册数，能满足500人并发访问和10000人同时在线访问，且并发访问响应时间小于3S。

系统支持集群的应用部署方式，核心组件都必须提供“双机负载均衡”的运行方式。

1.1.4.统一性要求

1.1.1.1.统一架构要求

本项目中提供的智慧校园管理支撑平台2（至少包含：

数据集成服务平台2、统一身份认证平台、应用集成平台2、流程引擎平台）、智慧校园应用系统软件（至少包含：

学工事务管理、人力资源综合管理、教务管理（含研究生教务管理））须为服务商自有品牌或自主开发，不接受服务商采用非自有品牌或非自主开发产品。

1.1.1.2.统一数据要求

本项目各系统数据库必须与数据集成服务平台2进行对接集成，向数据集成服务平台2及其它业务系统提供数据交换接口，实现与校内其它业务系统间的数据共享交换要求，完成数据层的集成。

各系统所包含的数据表结构均必须免费向学校开放，数据必须全部都能集成到主数据平台。

各系统数据集成需支持ETL及API两种数据集成方式，须支持ODI数据中间件，能支持统一的可视化的集成查看工具、集成调度工具在内的数据集成管理工具，支持图形化的设计和定义数据抽取、转换、加载流程，并保证数据集成交换的稳定性和安全性。

1.1.1.3.统一认证要求

1.本项目所建所有系统必须采用相同认证方式，统一身份认证平台后台管理端须能同时对一站式服务中心的PC门户和移动门户认证进行统一管理。

2.须提供主流身份认证cas、反向代理、OAuth2.0等不少于3种类型集成方案，并提供从系统准入、集成示例代码、集成效果展示全过程的具体实现方案。

1.1.1.4.统一访问入口

1.一站式服务中心是本项目所有系统的PC端唯一访问入口，各系统访问入口必须全部整合集成在一站式服务中心，通过一站式服务中心进行访问。

2.一站式服务中心支持为多种访问对象（默认至少应包含：

学生、教师、访客，且支持新建、自建访问对象）自动匹配服务应用，登录后根据用户身份推荐应用。

1.1.1.5.统一管理要求

1.本项目建设的所有针对普通师生的信息化服务应用须支持通过应用集成平台2管理界面进行统一管理，管理包括应用的名称修改、上线/下线、启用/停用、启用时间、流程编辑、访问权限配置等。

各服务应用在上线使用时支持同时推送到PC端和移动端的功能。

1.1.1.6.统一访问行为分析

本项目建设的各项信息系统，可通过一站式服务中心展示各系统使用情况和状态分析，可精确显示各系统、服务应用的详细使用情况，包括但不仅限于用户访问频次（PV、UV）、用户访问终端（PC、移动）、用户所用操作系统、浏览器数据（浏览器品牌及版本）、访问IP地址等，并能按时间段分析使用状况。

1.1.1.7.统一的应用评价反馈

1.为应用集成平台2承载的各系统及服务应用提供统一的应用评价功能，用于服务应用过程中用户对系统或服务应用进行评价打分和留言，支持用户匿名评价，平台维护人员可查看评价标准及评价内容。

2.系统应提供应用评价在线统计和查询功能，可展示评分最高和最低的服务应用，可依据服务类型或服务名称查询应用评价情况。

1.1.1.8.统一运维服务

本项目建设的各系统、应用须提供运维接口，且能提供给统一运维管理使用，由统一运维管理系统报告各系统、应用当前运行状况数据（包括CPU占用、内存占用、数据库连接状态等）。

1.1.5.易用性和灵活性

系统须提供多维度、精准的应用查找功能和应用智能定位功能，支持用户自定义一站式服务中心个人服务桌面，允许用户将个人常用服务应用布置在个人桌面。

1.支持用户对服务应用进行收藏/取消、建立常用应用文件夹。

2.支持业务直通车功能，管理员可按业务类别构建不同业务直通车卡片,卡片包含两级业务目录，可对每一级目录进行详细编辑，在每一级目录下勾选包含的业务应用。

用户可在个人桌面选择不同的业务直通车卡片，在卡片内切换二级目录，点击包含的业务应用即可直接进入该业务应用办理。

3.针对校内重点业务，在其业务期，系统提供业务专题推荐功能，可对业务情况做出介绍和说明，支持以文字、图片方式对业务专题做出介绍和说明，并可把业务相关功能模块纳入专题推荐栏内。

1.1.6.系统接口开放性

系统须采用J2EE技术架构，支持SOA技术架构，提供业务应用程序接口（API）库，支持开发者根据系统提供的API和程序规范可独立开发应用，作为现有服务的补充。

对于数据，提供数据交换接口。

1.1.7.数据对比开放性

系统及服务应用的运行状态数据、访问频次等数据，与国内其他本科院校信息系统使用数据做横向对比分析，可判断各系统建设情况、使用情况、师生满意度等指标，通过对比结果来指明系统改进方向。

横向使用数据对比，至少应提包含学工、人事、教务三大系统，且提供不少于10家国内其它本科院校同类系统使用数据进行对比，并以图形化方式展示、汇总、分析对比（至少包含运行状态数据、访问频次等数据），判断本次项目的建设使用情况。

1.1.8.安全性

1.在系统设计中，既要充分考虑信息资源的共享，更要注意信息资源的保护和隔离，采取不同的措施，包括用户与权限管理、统一身份认证、访问控制、管理控制、版本控制、数据关联控制、数据加密、数据存储、数据备份与恢复、日志与安全审计，确保系统数据安全。

采取技术手段有效识别和拒绝爬虫类访问，避免信息被恶意采集。

2.本项目整体及各分项系统均必须达到国家信息系统安全等级二级保护要求，满足学校通过国家信息系统安全等级二级保护要求测评，对无法满足的部分，服务商须承诺无条件免费整改，直至通过为止。

1.2.项目基本技术要求

1.2.1.B/S结构要求

管理支撑平台和应用系统软件均要求采用B/S结构，必须采用主流开发语言，推荐JAVA编程语言和服务器端JAVA技术进行开发。

平台和系统服务端支持Unix、Linux、WindowsServer等操作系统；客户端支持IE9/10/11,Chrome50/51/52、Safari、360安全浏览器V8.1、360极速浏览器V8.5访问；本项目建设的智慧校园管理支撑平台2的数据库要求采用关系型数据库产品。

1.2.2.J2EE标准

开发技术应采用J2EE标准、组件技术及在数据交换上支持XML，同时将整体系统内部在技术上的耦合性减至最低。

1.2.3.组件技术

采用面向对象的组件技术，着重于开发构成应用程序的可重复使用的组件，再利用这些组件顺利地建立分布式应用程序。

1.2.4.三层架构

应用程序开发与运行结构要基于统一的三层架构（即Web服务器、应用服务器和数据库服务器）。

1.2.5.Ipv6支持

管理支撑平台和应用系统软件均要求支持Ipv6访问。

1.2.6.细粒度授权

能完成跨业务部门的业务流程和相对应的细颗粒度的分级授权体系。

1.2.7.细粒度封装

各应用系统软件要充分利用现有先进技术手段，采用相同的体系结构和运行平台，基于多层架构和组件技术进行构建，做到系统结构层次清晰。

所有应用逻辑、流程、数据等都应当能够根据建设方要求的颗粒度进行封装。

1.2.8.系统负载均衡

系统必须支持负载均衡，必须支持我校已有的负载均衡设备，且须提供关键节点的“多机部署”的软负载均衡功能，支持动态监测负载状况，自动对可用资源进行并发检测，调整和分配等功能。

1.2.9.系统备份

支持应用服务备份、数据库的备份，支持系统整机备份以及异地备份，利用数据库的备份功能将建设的平台和系统数据备份到专用的服务器或存储设备上。

1.2.10.信息标准

系统必须遵守《教育管理信息化标准》和《高等学校管理信息标准》等国家相关信息化标准要求。

1.2.11.系统接口要求

1、按我校的需求提供标准接口，接口信息包括服务URL、服务类型、功能类型，说明文档等。

系统内部各个子系统之间不允许直接访问各自的数据库，只能通过接口交换数据。

2、按我校的需求提供标准接口，供其他业务系统获取或推送相关数据。

1.2.12.系统数据迁移/导入要求

中标人除完成本项目各分子系统开发、部署完，还需负责完成本项目相关系统的历史数据的迁移、导入工作，包括系统数据与电子表格数据（EXCEL表格数据）的迁移导入，对电子表格数据还须提供数据导入模板。

1.2.13.项目部署要求

1.中标人负责完成本项目中所有系统对部署实施、开发测试、上线使用工作。

2.服务商须提供系统部署方案，要求所提供部署方案具有高可靠性、高稳定性和高可扩展性。

3.系统整体网络应采用B/A/S三层体系架构，中间层通过WebService实现异构系统之间的数据交换和集成。

4.充分满足用户业务系统运行环境需要，跨网络划分多个功能服务器，独立部署。

5.服务器架构上可实现快捷便利的性能和功能扩展需求。

6.系统关键节点采用高可用性的冗余设计，并充分采用负载均衡解决方案，可支持主流负载均衡产品。

7.各个子系统支持服务器虚拟化方案，能在市面上主流的云平台上运行，实现生产系统服务器的虚拟化整合，保证高可用性及业务连续性。

8.各个子系统支持无状态的服务器水平伸缩，即根据业务和使用量的需要而通过简单增加服务器就能提高并发业务/事务处理能力。

1.2.14.项目中英俄三语版要求

本项目所有包含师生服务的服务应用用户页面，必须支持中文、英文、俄文三语版（本项目内统称为“三语版”，下同），系统须支持中英俄三种语言包，支持用户自动切换。

要求把支持多语言的架构开发分散到各业务系统中来实现不同语言切换、展示框架须适应中英俄文语言兼容，不允许只对数据字典进行语言翻译。

系统仅须针对包含师生服务的服务应用用户页面提供中英俄三语，后端管理界面可仅支持中文。

要求：

1.智慧校园应用系统软件，在系统底层构建中英俄文三种语言包，系统在中英俄三种语言包调用不同语言码表方式，实现前端服务页面中英俄语言自动切换。

2.要求提供中文、英文、俄文版的系统包括：

1）一站式服务中心服务界面提供中文、英文、俄文版；

2）学工事务管理系统面向学生的服务界面提供中文、英文、俄文版；

3）人力资源综合管理服务的面向普通教工服务的界面提供中文、英文、俄文版。

4）教务管理系统服务的面向学生、授课教师的界面提供中文、英文、俄文版（含研究生教务管理）。

5）实验室管理系统面向师生使用的界面提供中文、英文、俄文版

6）智慧校园创新应用中向师生展示的内容提供中文、英文、俄文版

1.2.15.需求可变要求

1.鉴于我校为新建高校，组织架构及业务流程均在持续优化，本项目各系统功能模块技术要求、功能要求、设计流程后续均可能因我校实际需求变化而发生变化，服务商须承诺在本项目各系统功能模块不增加的前提下，在系统需求梳理、设计、确认过程中我校可根据实际业务需求变化进行各系统功能模块需求动态调整。

本项目技术需求仅为基本要求，最终交付要求以服务商签约进场后，根据实际需求梳理、设计、确认后的需求文档为准。

2.鉴于业务范围、业务内容后期存在变动可能性，本项目各系统功能模块，在未上线试运行前，我校可根据自身实际使用需求进行置换，置换为符合自身业务范围及内容的模块，置换的模块与被置换模块工作量符合本项目发改委概算文档批复范围内的单价或工作量，（如出现此类情况，我校需提供发改委概算批复文档作为参考）。

2、智慧校园管理支撑平台

2.

2.1.数据集成服务平台

2.1.1.信息标准管理工具

2.1.1.1.信息标准建设

信息标准的建设是学校信息化建设的基础核心内容。

建立一套《深圳北理莫斯科大学信息标准》，符合国家、教育部和行业标准，适合深圳北理莫斯科大学信息化可持续性建设发展要求，并与我校世界一流本科院校建设发展要求相适应，使学校在数据建模、信息采集、加工处理、数据交换的过程中有统一的规范，最大限度地实现信息优化管理和资源共享。

同时，标准必须符合我校的具体情况和实际需求，能够满足各业务系统向上级或相关部门报送数据报表的需求。

信息标准体系的建设内容主要包括数据标准、代码标准、信息标准管理工具。

1.数据标准:

数据标准按照学校的信息子集进行定义，每个信息子集应包括以下内容：

1）数据集、数据子集、数据项分类与分层结构；

2）数据集定义、属性描述；

3）数据子集定义、属性描述；

4）数据项定义、属性描述、权限描述。

5）实际确定的信息集要根据我校实际情况，伴随着各类应用的建设与更新同步进行修订、补充，未来信息集的制订范围应能涵盖我校所有业务，需包含人事管理数据集、学生管理数据集、财务管理数据集、科研管理数据集、资产管理数据集、教务管理数据集等。

2.代码标准:

数据要按照统一的标准产生、存放、使用，使数据真正实现共享。

代码标准的建设即是基于国家标准、教育部标准、行业标准和学校已有的校标，兼顾各个标准之间的兼容性、一致性以及标准的可扩展性，建设和完善的各类系统中数据的存储、使用规则，建设形成一套符合学校自身实际的代码标准。

信息标准管理工具建设：

信息标准管理工具，实现代码标准的新增、启用、拆分、合并、停用，记录代码变更日志，代码值映射关系的增删改查，代码标准的检索以及代码被引用情况查询。

信息标准管理工具须提供代码标准管理、代码标准查询、代码使用范围检索、代码映射关系、代码使用情况检查等功能，实现学校代码标准的制定、维护、理解、集成等功能。

同时，系统可监督标准的执行情况，不断优化学校的信息标准。

1.信息标准管理实现对代码标准的日常管理，当某个标准需要更新时，通过代码标准管理功能进行及时更新维护。

须支持代码标准的新增、启用、拆分、合并、停用、导入、导出等功能；须提供记录代码变更日志，供用户跟踪代码标准变更过程。

2.信息标准管理工具需要完全采用B/S架构，在不安装任何客户端软件的基础上通过浏览器即可对校内信息标准进行管理，便于用户维护使用。

3.代码标准查询实现对代码标准、代码标准模式、代码映射关系、使用范围的查询检索。

1）代码表模糊检索，比如：

给出表名或表中文名，可检索相关代码表；

2）代码内容模糊检索，例如：

只给出一个代码值，检索所有含此内容的代码表；

3）代码使用范围查询，查询代码的使用范围，以便于系统管理员了解代码的影响范围；

4）代码检查情况查询，检查业务系统和标准代码的匹配程度，为数据集成提供是否达到集成条件的判断依据，代码标准分级查询。

4.提供按角色授权查询功能，能够实现代码标准的分级授权管理，不同角色可以查询不同的代码标准。

5.提供代码云中心API申请和访问功能，能够实现其他应用基于webservice和json两种接口的直接调用，提供在线申请和代码反馈功能。

2.1.2.主数据集成管理

数据集成与共享是本次数据集成服务平台2建设的重点内容，需要采用统一的数据集成管理工具，将分散在各业务系统之中需共享的主数据抽取上来，并根据校内信息标准进行统一的存储和对外发布及共享，数据集成过程需采用成熟的商用中间件实现，以保证数据交换过程的稳定与安全，并能够为校方提供对应的管理与配置工具，提升数据集成过程的管理能力。

主要功能要求如下：

2.1.2.1.主数据模式及主数据库

主数据库的数据规范需基于教育部最新的教育信息化数据标准，并对其存储的数据对象按合理的数据模型进行划分。

2.1.2.2.数据集成开发包

1.需支持通过ETL的方式将各异构业务系统的主数据抽取上来，形成校内统一的、权威的主数据集；

2.提供包括拓扑管理工具、集成设计工具、集成查看工具、集成调度工具在内的数据集成管理工具，工具需要具备可视化、可拖拽、可配置的特性，并具备一定的二次开发功能，便于各个层面的管理人员进行使用；

3.提供数据集成知识库，知识库需要预置超过100个数据集成知识模块。

2.1.2.3.元数据管理工具

1.支持对数据源进行注册、启用、停用；

2.支持对数据对象按目录结构进行管理，能够实现对数据对象和其分类目录的增删改查；

3.支持对元数据的变更进行操作记录历史查询；

4.支持根据元数据对主数据库进行建模并且保证建模过程不会操作业务系统数据结构；

5.支持对主数据库数据对象和对应的数据库实体匹配情况进行自动检查，并逐项列出不一致项，方便用户后期处理，同时支持对已处理问题进行记录，便于后期查询跟踪。

2.1.2.4.主数据管理

1.考虑到学校部分业务部门尚未建立信息系统，其他业务系统又需要使用其业务数据的情况，需提供手工将本地数据（包括EXCEL、DBF）导入主数据平台之中，供其他业务系统使用的功能；

2.需支持通过主数据管理工具，查询主数据和主数据历史变化情况，并能够导出EXCEL，便于线下开展数据分析；

3.需实现主数据的分级授权管理，可根据数据流向控制其管理查询权限。

2.1.2.5.数据集成核心模块

1.拓扑管理工具

对数据源和调度代理进行管理，支持RDBMS、文本、消息、WebService等各种数据源接口。

2.集成设计工具

对数据集成项目提供图形化界面进行设计和开发。

3.集成查看工具

查看数据集成项目的运行情况，可以对集成过程进行调试。

4.集成调度工具

对各个数据集成同步任务进行调度控制，以此完成定制化的数据集成过程。

2.1.3.主数据备份管理

平台除了要考虑主数据本身的存储之外，还需要考虑到后期为数据分析、数据积累提供良好的支撑。

同时数据库存储的设计要具备良好的合理性和科学性。

具体功能要求如下：

1.需提供数据备份管理功能，支持对备份日志进行查询，支持对主数据变动情况进行查询，并能够将变动情况导出excel。

2.需支持在系统内随时查询某个历史时间点的主数据状况和代码标准情况，时间点的颗粒度支持细化到以天为单位。

3.数据的备份需要采取合理的备份模式，要既能完整保留历史数据的变动信息，同时不能过度浪费存储空间。

2.1.4.主数据质量检测

提供数据质量检测工具需围绕业务视角，提升用户可看性，直面性能瓶颈，对业务系统集成的主数据进行事后检测，暴露数据存在的问题，推动源头部门进行数据质量提升。

功能要求如下：

2.1.4.1.检测规则管理

系统需支持针对数据质量检测规则的增删改查操作，除预置的检测规则外，还应可以根据具体需要自定义检测规则，具体预置的检测规要求如下：

1.空检查规则：

检查字段是否为空，会对元数据标记为不能为空的字段默认进行检查；

2.代码检查规则：

检查字段取值是否在代码表（由系统中预先进行定义）中；会对源数据中有代码应用的字段默认进行检查；

3.唯一性检查规则：

提供字段的唯一性检查。

例如：

身份证号是唯一的，如有重复将是错误信息；

4.文本检查规则：

检查单个字段的文本取值是否满足指定的长度和格式，或预先定义的各种固定编码规则；文本长度支持单个长度、多个长度、范围组合等，文本格式支持包括：

数字、字母、大写字母、小写字母、字母数字、汉字等，预定义的编码如邮政编码、EMAIL地址、URL地址、身份证号码。

2.1.4.2.业务检测项管理

系统需提供业务检测项管理，可以设置数据检测范围，如：

数据期限、不合格记录显示字段等；也可以针对业务检测规则进行配置，如：

要检测的表、字段组合、检测规则等配置；针对所有设置好的检测项可以进行直接执行测试。

2.1.4.3.检测任务配置

系统应支持检测任务配置，可配置检测任务进程数、起始/终止日期、每天开始检测时刻，是否启用。

2.1.4.4.数据质量检测

系统支持根据检测任务的配置，按照业务检测项，采用增量检方式，逐项检测主数据库中的数据，并记录检测结果。

2.1.4.5.检查任务日志

系统提供检测任务日志可以查询每天任务的总体执行情况以及检测任务异常情况，具体功能要求如下：

1.任务日志

可以按照执行日期、执行状态进行检索；检索内容包含执行日期、进程ID、检测项总数、异常检测项总数、检测数据项总数、异常数据项总数、执行开始时间、执行结束时间；

2.异常日志

可以根据执行日期检索；检索内容包含执行日期、进程ID，检测表明、检测字段组合、检测规则、异常信息、执行开始时间、执行结束时间等。

2.1.4.6.检查结果查询

系统应可以通过检测结果查询了解总体检测情况，也可以了解具体表的检测情况，也可以进一步输出具体的单表检测报告，了解问题所在。

具体功能要求如下：

1.系统需支持参与检测的业务系统数、检测总表数、检测业务字段数、业务检测项数、数据样本数、今日数据正常数据项数、异常数据项数、合格率情况展示；支持30日正常数据项数、异常数据项数情况及问题处理情况进行直观展示；支持对各检测规则合格率排名、单表合格率前五名、后五名情况进行展示。

2.系统围绕业务视角针对每个业务系统展现单表数据的合格率、正常数据项数、项异常数据项数、项总数据项数、项业务检测项数、数据样本数、检测字段数信息。

3.系统内需支持生成直观的检测报告，方便反应问题所在及动态。

2.1.4.7.检测结果推送提醒

系统需支持根据检测结果，按照单表配置推送任务，通过邮件方式，把总的结果及明细情况推送源头业务人员。

2.1.5.运行监控管理

2.1.5.1.问题跟踪处理

系统需提供数据技术属性规范性检测、元数据与数据库一致性检测、集成接口运行情况、数据质量合规性检测、代码标准一致性检测、数据备份情况等多种维度健康监测，并应对可以通过技术解决的问题提供一键修正的能力。

2.1.5.2.数据拓扑呈现

1.系统需支持通过图形化的形式反映系统数据的拓扑关系，通过系统之间的拓扑图呈现系统集成的上下行接口数、系统集成与主数据库之间的关系、同步是否存在问题。

2.系统支持通过表-表，字段-字段的拓扑图进一步了解数据流向细节。

1.数据集成监控系统支持监控依托数据集成工具，对业务系统集成情况，接口运行情况进行展现，包含：

集成概况、接口信息、任务计划、接口运行日志等。

2.数据流向查询

1）按业务系统或部门视角，以IPO图的方式直观的展现数据的流向，可按照系统（数据源）表进行查看；

2）支持以图形化方式展现，并在图上显示出实际的数据集成情况，发生错误的数据流向箭头会以特定颜色、线条等强调标识。

2.1.5.3.数据库监控

系统需同时对影响数据库稳定运行的指标进行监控，便于及时发现数据库异常，及时优化调整数据库或应用程序，确保数据库、应用的稳定运行，包括：

数据库连接数、数据库表空间（主数据）、数据库表空间（主数据仓库）、数据库死锁、数据库归档情况、耗时最大的10条SQL、CPU消耗最大的10条SQL、磁盘读写消耗最大的10条SQL等。

2.1.6.创新数据主题和服务

2.1.6.1.数据建设服务

1.根据本项目创新数据主题和服务需要，针对学校实际系统建设和历史数据情况，组合使用ETL集成、API接口、数据导入、定制开发数据补采应用等方法，制定适宜的数据采集、集成方案和实施计划，并提供相应的数据采集、集成实施服务（包括特定的接口对接开发和特定的工具开发），支撑创新数据主题和服务建设。

2.完成需要的业务数据（教务数据、人事数据、学生数据、