XXXX大学数据预警平台技术要求

XXXX大学数据预警平台技术要求
（一）建设目的
预警平台建设之前，一切的操作行为都是以人工为主，经验型：拍脑袋，模糊型：凭感觉，条块分割，人工为主，建设预警平台之后，一切都变的科学化，精准化，一体化，数字化，一切都围绕一个模式内里以预警，周围环绕着，日常监测，精准预测，科学把脉，外围预警业务运行现状，洞察业务运行趋势，多维评估业务风险，已建立数据共享为基础的跨部门，跨高校的合作机制，大数据的采集和存储，为数据的挖掘和分析打好基础，构建基于指标体系与预警体系一体化的安全智能模式，以数字化推动日常工作各方面变革。

一切的操作都是围绕着精简化，简单化，方便的处理工作预警，为人员提供极大的便利。

（二）项目采购需求
1.日常业务管理
采购人预警平台管理，负责一切与预警平台相关的工作，预警平台工作内容（系统管理，系统监控，系统工具，指标评价，预警作业，数据源管理，数据模型，数据指标，指标体系，预警对象维护，预警对象角色，预警主题），学工主题预警体系，教学主题预警体系，科研主题预警体系，人事主题预警体系，财务主题预警体系，图书主题预警体系。

预警体系直观展现指标体系的完成情况，帮助部门聚焦核心工作目标，推进业务部门工作质量的提升。

指标体系根据模型和场景，对业务指标分析所需数据进行有效的采集、汇聚、分析和管理。

元数据收集推动跨层级、跨部门、跨区域数据归集，完善数据资源体系建设。

预警体系为框架最后一环，由预警监测、预警推送、预警处理等工作内容：预警监测提供体系化、数值化的标定和参考，可按需求定义预警展现形式，如雷达图、柱状图等。

预警推送可按照设定预警阈值将告警、预警记录推送相关
人员。

预警处理是预警体系开展识别、诊断、预控等活动的前提，根据预警等级制定应对方案，处理结果会有相应监测和统计。

2.应用迭代及开发
除了对现有校园预警平台已经上架应用进行应用维护和迭代，还需按照采购人要求完成校园预警平台新增开发应用和版本应用。

所有开发的应用须进行统一身份认证改造平台必须遵循采购人整体信息化制定的相关数据标准和相关其它信息标准要求。

基础指标是带有业务属性、经过加工的数据，能够指导业务改进的关键数据项。

单纯的数据展示对于业务管理者和决策者参考价值不高，需要结合业务，提炼成指标才有意义。

一般预警指标，没有系统化的管理，大多是单一实现，并且很难互相关联；对决策者来说，零散指标无法充分说明问题，预警平台能将具有相互联系的指标系统化的组织起来，形成指标体系并统计分析。

3.技术维护
技术维护负责与校园预警平台相关的所有软件维护工作，工作方式包含现场技术维护（技术人员学校驻场）与常规技术维护，采用两种方式相结合，能够提供7*24小时故障响应的全天候技术维护服务，保障校园预警平台的稳定运行。

技术维护的工作范围包括校园预警平台所有相关软件的免费升级，各相关系统定期或不定期安全抽查和检测，已交付应用bug修复，已交付应用需求变更修改，校园预警平台各系统软件版本管理与最新版本上线发布，记录各类日志，编制和修订各类文档等。

除此以外，需要建立完善的技术维护服务规章制度和故障响应流程。

在实际的技术维护中，实行严格的故障分级制度，各类各级故障必须要有明确的响应措施。

从故障提交到响应、级别升降、挂起、分配、故障排除到故障修复总结的所
有环节，对每个具体的服务，要责任到人，需要有有一套严格的管理流程和制度。

所有技术维护工作必须记录完整的技术维护日志，校园预警平台各软件系统维护需保存档案。

针对技术维护，要有定期或不定期的巡访、调查，监督，保障技术维护的效率和质量。

建立客户满意度调查制度，建设客户投诉体系，技术维护团队需积极妥善解决校园预警平台实际运行过程中出现的所有技术问题，提高客户满意度。

4.驻场服务要求
采购人数据预警平台项目工作主要分项目的开发工作和日常运营管理及维护两部分，由于需要同时承担开发和运维工作，要求组建一个综合开发团队，团队需要常驻XXXX大学东湖校区，并按照采购人上班要求（工作时间根据采购人上班时间制定）进行项目开发和日常运维实施及技术支持服务。

整个团队需保证至少安排1名项目负责人、4名有经验的技术开发人员，驻场服务时间自合同签订之日起至2024年12月31日。

驻场人员经采购人面试通过认方可入场，入场后不得随意替换，特殊原因需替换（如：离职、大病）需经采购人同意并书面批准。

驻场人员需要计算机相关专业，负责校园平台日常开发、运营管理和维护工作，必须具备Java专业知识、熟练掌握版本控制Git，SSM，SpringBoot快速开发框架，以及预警平台的相关开发技术和各类开发工具。

（三）项目技术需求
1.开发平台要求
1.1 开发工具
投标人应提供一个独立于硬件接口之上的应用软件开发平台，提供完善的开发工具，软件平台的IDE（Integration Development Environment）及插件的使用难度应该不高于目前各开发语言IDE。

其中JAVA开发的参照对象是：Eclipse；
1.2 开发平台
具有自主的开发平台，采用Spring，Bootstrap， MVC等主流技术架构，基于HTML5+CSS3实现多终端多浏览器访问（如：IE、Chrome、Firefox、Safari、Opera等），实现电脑端、移动端各种分辨率自适应访问，可以与校园门户（PC 端）、移动APP（Android和IOS）、微信公众号完美结合；
1.3 重用组件
对于复杂的业务，开发平台应通过提供各种组件和接口尽量减少开发工作量，对于各种业务流程中共有的内容，可以定制模板，并在以后的开发中直接使用；
1.4 接口支持
应该具备独立的接口管理模块。

利用此开发平台开发的IT应用，在接口开发上能支持常见的技术标准（至少支持Web Service，Restful API），保证与周边系统的无缝连接；
1.5 数据库支持
采用目前主流的数据库产品如ORACLE（11g或以上版本）、Mysql（6.5以上版本），数据库的建模要求必须使用专业工具完成，如：Power Designer、Erwin、Rational Data Architect；
1.6 中间件支持
如果需要使用中间件产品，那么要求开发平台和中间件是松耦合的方式，即开发平台对中间件是1：N的关系。

支持目前主流的中间件产品及其版本，Java 中间件小型应用系统采用Tomcat，中大型应用在WebLogic(10g以上)、WebSphere(6以上)中进行选择，SAP中间件采用Net Weaver(6.0以上)；
1.7 开发语言
开发语言为JAVA；
1.8 报表工具
开发平台中的报表工具应该是开源的产品；
1.9 原型验证
系统需求分析时，要求采用专业工具进行可视化原型说明，如：Axure RP；
1.10 开发框架
开发框架在架构层次、应用部署支持、资源管理、安全机制、平台管理（权限、接口、日志等）、应用扩展这些方面的设计思想符合SOA理念；
1.11 代码管理
主流、通用、完善的代码管理工具和良好的代码备份方案；
1.12 安全机制
基于三层结构（数据层、应用层、WEB层）设计、严格的身份授权机制（绑定MAC地址、按角色、数据表、字段等授权）、敏感数据的监控预警等，采用采购人统一身份认证系统。

2. 应用平台要求
2.1 客户端操作系统支持：Windows、Mac、Android、IOS等；
2.2 服务器操作系统要求：Linux系统；
2.3 浏览器：支持IE、Chrome、Firefox、Safari、Opera等主流浏览器；
2.4 架构：采用B/S架构；
2.5 系统对客户端网络带宽要求应符合现有各服务站、内部用户的网络接入现状，并明确系统对于网络质量（如丢包率等）要求或建议；
2.6 服务器端网络架构及带宽要求应符合现有网络现状，投标人可提出相关要求或建议；
2.7 应用软件与硬件平台相对分离，应用软件可以自由运行在主流操作系统及主流硬件平台上；
2.8 投标人应明确给出选用的应用软件平台的具体特性和使用限制，包括系
统的配置文件，并说明产品功能的使用范围；
2.9 系统具有较强的可配置性，在权限、流程、业务规则、页面内容等方面具有灵活性；
2.10 应采用简洁、直观、友好的图形化界面；
2.11 应具有完整的权限管理功能和完善的系统安全机制，能够对系统核心操作进行控制；
2.12 支持分布式数据管理，支持多数据源间的访问连接；
2.13 应用软件采用分层的模块化结构设计，应具有灵活性、可操作性、可移植性和可扩展性。

模块的增加和对模块的修改不应对其他模块产生影响，并能在不影响系统运转的情况下做到模块更新、模块加载；
2.14 应用平台升级方便，能在不影响应用平台主体应用模块功能的情况下升级，并保证以前的数据完整。

3. 性能要求
3.1 数据库可采用ORACLE (11g或以上版本)但必须实现数据库集成解决方案，提供符合采购人标准的容错性和高性能，并给出由于可预期的业务增长而必须进行的集成认证改进和扩展的解决方案说明书。

实现数据库高可用解决方案。

3.2 实现多台WEB负载均衡，保障平台10000+的在线人数的流畅访问，1000以上用户并发访问。

提供可预期访问量增长的改进和扩展方案。

实现多台WEB 动态负载均衡方案，可提供自动故障节点转移能力，保障平台7*24小时稳定高效运行。

3.3 应用服务器采用Tomcat/Resin/Web Logic等。

3.4 API接口支持响应时间为<1秒，并发用户数要能达到1000人/次。

1000个用户并发请求同一个API时，除网络延迟因素外，响应时间不超过3秒。

3.5 为了确保接口服务吞吐量最大，接口应自动地在系统中完成动态负载均衡调度。

3.6 与采购人数字化校园无缝集成，用户登录采用采购人门户统一身份验证，新生数据通过数据中心流转。

3.7 采用SOA技术架构实现模式，实现REST、Web Service服务等接口。

（四）其它要求。