如需完整的数据中台解决方案、建设方案、各行业解决方案，请联系客服免费索取。
1 项目概述
1.1 总体描述
随着信息化的发展，很多学校已经基于ODI工具实现了简单的数据交换，满足了基本的跨部门数据共享需求。但是在实际数据相关工作中ODI工具的局限性明显、数据质量问题较为突出，主要原因是学校业务发展迅速导致数据类型多样化、数据规模剧增，数据治理能力欠缺。现状总结为以下几点：
1.1.1数据交换方式局限性高
随着学校业务的发展，数据呈现出多样化、大量化的特点，终端用户对数据的使用要求也在提升，现有的数据交换方式不能完全满足这样的变化。从实际使用的情况来看，现有的数据交换平台存在一些局限，比如：
(1)数据库以外的数据源（文件或服务接口）的集成，基本是通过编写Java代码实现的；
(2)数据对外共享只是通过视图或数据推送，暂不支持服务化的共享方式。
因此，需要增强数据交换能力，扩展适配度更广、兼容度更高的数据集成方式和共享方式。
1.1.2数据资源目录尚不清晰
学校现在的数据中心建立了一个数据库，通过ODI工具同步业务系统的数据。但是，数据仅仅反应在数据库层面，未能系统性的梳理学校的数据资源目录，导致问题：
(1)管理人员不能全面掌握学校到底有哪些数据；
(2)不清楚数据都来自哪个部门；
(3)不清楚数据的含义是什么；
(4)对外提供数据时没有依据等问题。
1.1.3 数据处理自动化程度低
现有数据交换平台只实现了端到端的数据简单同步，并未实现数据自动化清洗加工。遇到实际数据清洗加工需求时，基本都是通过手工写SQL语句的方式进行转换，工作量大、重复性高、效率低、维护成本大。
1.1.4 可视化监控能力待提升
数据处理工程涉及的环节较多，过程复杂，可视化的运维监控能力就显得尤为重要。现阶段只是细粒度的监控查询，缺乏宏观层面的监控体系，包含数据集成监控、服务监控、服务器资源监控、异常预警、数据进度实时监控等。
1.1.5 数据治理和开发能力亟需加强
数据质量问题一直是数据跨部门共享过程中的一个典型问题，部门常反应数据不准确、不一致、不及时等问题。主要原因在于，学校现阶段还未完善统一的信息标准规范，在数据质量方面缺乏相应的工具来辅助进行质量提升。
数据安全问题也是数据管理的核心关注点，数据在同步、存储、查询、共享等方面的安全需要重点关注，防止数据泄露。通过相应的数据安全管理工具或模块加强数据安全防范。
在数据治理的基础上，提供完备的数据开发工具，便于用户进行数据的开发后形成数据集，供全校用户查询和使用，也为上层应用提供数据支撑，逐步形成校级数据中台，以提高数据服务能力，减小应用开发难度。
在数据管理项目建设过程中，建议将学校原有的信息化项目建设模式从传统的以功能为主的项目模式往新型的以协同运营数据为主的项目模式转变。模式转型的过程中主要围绕以下三点推进：第一，面向解决问题。传统项目主要聚焦于满足业务部门工作流程的功能开发，数据管理项目需要着重于不断提供校级领导、职能部门、教学单位、直属单位和教职工以及学生的数据支持。第二，能够持续演进。传统项目建设是周期闭环式建设，适应变化能力弱、周期长。数据管理项目采用开环迭代式建设，与螺旋递进数据的积累和治理保持一致。第三，横向共建协同。新项目需要从面向问题入手，涉及的服务对象会越来越多，因此对跨部门的协同共建有更高的要求。
1.1.6 重复填报数据，降低工作效率
人才培养状态数据采集的工作是持续的，需要投入大量人力重复填报数据，且人才培养状态数据应该被涵盖在全量数据中心内，希望通过本项目的建设优化人才培养状态数据采集的工作，降低数据采集负担。
1.2 项目内容
数据治理项目建设主要内容包括：数据治理服务、数据交换服务、数据总线服务、数据治理规范标准设计、数据应用建设、数据展示(人员画像)应用建设、数据安全管理。
1.3 建设目标
平台架构的设计需要充分考虑其先进性并且可以落地实施，能为学院下阶段的发展提供有力支撑，本项目主要围绕以下五点建设：
（一）规划先行，巩固成果
根据校情现状做好平台框架的规划设计，体现顶层设计上的大格局。需要建立数据生产、数据治理、数据开发（包含业务模型探索）以及数据应用的闭环数据生态，符合未来五年的政策发展要求，适应变化频繁的业务发展要求，更好地满足广大教职工和学生在校工作、学习的发展要求。
（二）积累数据，滴水成河
完善现有的数据采集机制，为把“小数据”做成“大数据”提供良好的基础环境。主要包括以下三点：（1）丰富数据采集类型，利用更多的技术手段和工具从结构化数据往半结构化、非结构化数据的方向发展；（2）丰富数据采集的源头，建设更多的小应用下沉收集数据，并提出小应用的管理办法；（3）丰富采集数据的形式，为散落在电子表格中的、临时需要填报的数据提供新渠道，利用长短结合的方式不断突破、推进大数据的建设。
（三）拓展对象，面向问题
在数据安全得到保障的前提下，扩大数据应用的对象和范围。不断强化信息安全意识，健全网络安全管理制度，创建可靠、可控、可查的网络信息安全技术防护体系，树立正确的网络安全观，将服务对象拓展到校级领导、职能部门、教学单位、直属单位和教职工以及学生，科学地分析、收集服务对象的数据应用需求，并提出对应的解决办法，切实帮助服务对象解决目前在工作、学习中使用数据的困难，使他们在安全的闭环数据生态中持续获益。
（四）深化应用，融合创新
治理数据的目的是为了让数据用起来，让数据“说话”，发挥其应有的价值。本期项目的建设需要立足于解决学校发展面临的实际问题，坚持“以应用为导向，以好用为导向，以用好为导向”，促进管理水平和服务能力的提高。在服务对象覆盖面越来越广的基础上建设以师生需求为导向的数据服务与大数据分析，配合目标管理系统的建设，实质性推动诊改工作，体现产学融合的新实践，探索准确评价的新模型。
（五）横向共建，促进协同
加强“数据”与“业务”的关联性，引入“数据中台”的关键设计理念，并通过数据中台的架构完善数据平台，降低重复建设，减少烟囱式协作的成本，将学校的发展需求和师生的发展需求纳入数据应用协同的体系，提高将数据（信息）作为基础设施的认知程度，不断通过数据应用来满足使用数据的需求，通过使用数据的需求又不断促进数据应用的提升，这个过程就是跨部门横向共建。本期项目要在理念设计和软件实现上围绕这一本质内容开展，建立学校的数据应用协作机制，推动信息系统建设和应用从服务教育部门和学校管理、监管为主的现状往服务全校师生教育教学的过程发展。
2 建设方案
2.1 实施思路
2.1.1 国际化
2.1.1.1字符集要求
字符集采用UTF-8标准，满足国际化要求。
2.1.1.2多语言要求
多语言要求方面，要求i18n国际化支持。
2.1.2 标准化
针对数据治理平台建设要求，标准化主要体现在
1 国家教育系统标准
2 平台建设国家标准
3 数据接口对接标准
4 数据交换与加密标准
2.1.3 开放
数据治理平台作为运营中心的重要基础，必须全方位的开放其相关数据或者采用业界成熟的中间件产品集成，开放性将直接决定后面平台建设的成败。投标单位必须对开放性作出重要的承诺。
2.1.4 安全
在系统设计与建设中，充分考虑系统安全性，其包括了数据安全、网络安全，传输安全，管理安全等。
2.1.5 数据所有权与处置权
数据治理平台在实现开放性基础上、数据的所有权及处置权归甲方所有，投标方在中标后必须提供详细的数据表结构信息、其数据接口标准、加密方式和密钥（如有）及其相关必要的信息资料。
2.2 建设内容
2.2.1 数据治理服务
主数据平台以教育部《教育部2012版教育信息化数据标准》为基础。按照面向对象设计理念，主数据库模式是按照对象和高校核心活动进行划分的，从总体上对高校上层应用及数据进行梳理，由应用来推导模式的设计，由模式反向衍生、扩展上层应用。
将数据信息按照不同角度不同侧重点，分散在各个业务系统中进行管理，而主数据模式则将这些数据信息抽离出来，进行对象和业务类的拆分，将其分为对象类和活动类。
对象类是指数据对象，主要包括实体对象和逻辑对象。实体对象是指传统的数据对象，如人、活动等；而逻辑对象则是指一些非传统的数据对象，如院系信息等。
活动类包括对象管理活动和综合管理活动，可以按照对象的生命周期进行管理活动的设定。其中对象管理活动指基于对象的管理部分活动可以进行清晰的划分和归纳的数据，比如一些对实体对象的管理；综合管理活动是指包含的内容和相关联系会随着应用、定位以及数据使用的角度不同而变化的活动。
主数据模式围绕业务系统建设，围绕数据的集成与利用，会逐步迭代完善。展示主数据平台的一些主要模块的概要统计信息，主要包括涉及的系统数据库连接数、对接的业务系统、接入的数据源、数据资产项、数据集成运行情况。主数据平台围绕数据健康度指标呈现，反映数据当前健康度及历史趋势；同时进一步反映业务系统集成情况、代码标准建设情况、数据现状情况、历史数据存储情况等建设成效；也暴露元数据检测、代码标准一致性检测、数据集成运行情况、数据质量检测、数据仓库切片备份情况等存在问题；同时，也采用图形化方式分层反映系统数据的拓扑关系，通过系统之间、表之间、字段之间等三层体现数据的“从哪来、到哪去”。
2.2.1.1 元数据管理
数据对象管理：实现对元数据的定义，包括新增数据对象、删除数据对象、修改数据对象和变更数据分类；
元数据监测: 元数据保存的是定义数据表结构的数据。
2.2.1.2 代码标准管理
信息标准管理工具提供了代码标准管理、代码标准查询、代码使用范围检索、代码映射关系、代码使用情况检查等多种功能，以帮助高校轻松实现对标准的“制定（Draw）、维护（Edit）、理解（Understand）、分享（Share）、集成（Integration）”等功能，同时，监督代码标准的执行情况，逐步优化趋向统一。
2.2.1.3 主数据管理
提供主数据管理工具，自动识别和读取数据源，在线对主数据进行查询和归档，并可以通过自助化的脚本实现实时查询数据。
2.2.1.4 数据质量管理
数据质量检测工具围绕业务视角，提升用户可看性，直面性能瓶颈，对业务系统集成的主数据进行事后检测，暴露数据存在的问题，包括数据集成问题、实施规范问题、源头业务系统本身数据质量问题，所见即所得反映问题所在及动态，推送直接触达源头业务人员，推动源头部门进行数据质量提升。
2.2.1.5 数据共享接口
数据共享接口主要完成API配置通过可视化操作界面，完成读写API接口的制作，满足实时读写场景需求；同时，通过工具化，零代码，降低对工程人员的要求，同时，能快速响应用户需求，减少响应时间，增加满意度。同时实现与数据总线服务产品的无缝对接。
数据共享接口包含(1) 数据共享服务概述 (2)数据服务管理 (3)数据服务运行 (4) 服务运行监控 (5) 服务调用统计
实现与数据总线服务的无缝对接。
2.2.1.6数据运行监控
数据运行监控依托数据集成工具，对业务系统集成情况，接口运行情况进行展现，主要包括数据集成监控、数据库监控、问题跟踪处理、数据拓扑呈现。实现与DI数据交换服务平台的无缝对接。
数据运行监控包括(1)数据集成监控 (2)数据库监控 (3)接口跟踪处理 (4)数据拓扑呈现。
2.2.1.7系统管理模块
系统管理模块不具备任何业务功能，它主要通过对用户与系统的维护和管理为整个数据质量系统的运行和用户的正常使用提供必要的保障。
用户管理
用户管理单元用于对用户的管理和维护，包括对用户的增加、修改、删除，并对用户的角色进行分配管理。
角色管理
角色管理单元用于对角色的管理和维护，包括对角色的增加、修改、删除，并对角色所属的用户和菜单进行分配管理。通过角色对菜单的分配来实现系统权限的控制，此处权限控制级别可以做到菜单的权限控制以及页面功能按钮的权限控制。
菜单管理
菜单管理单元用于定义系统中各页面菜单的属性，包括菜单名称、图标、上级菜单、顺序以及链接地址等。
在线用户
在线用户单元用于记录用户最近一次登录的信息，密码管理单元用于用户密码的修改，刷新内存单元用于刷新在内存中所存储的变量值，包括检核类别、参数配置与数据源配置中对数据的修改操作。
2.2.2 数据交换服务
构建数据交换平台，保障数据层的互联互通。通过商用的数据交换平台完成学校基础数据库、业务数据库、主题数据库和文件数据之间的数据交换作业设计、调度、管理和监控的软件系统，为建立学校数据仓库的铺垫基础。
2.2.2.1交换平台技术要求
1) 数据交换必须基于成熟的 ETL 工具，提供统一的可视化的开发工具，能图形化的设计和定义抽取、转换、加载流程，并保证数据交换的稳定性、高效性和安全性。
2) 支持异构平台、异构系统、异构数据库的数据交换，操作系统包含 Windows，Unix，Linux 等，数据库包含 Oracle、Sybase、DB2、MySQL、MS SQL Server、Informix 等，支持文件型数据，如 Excel、Access、XML、TXT 等类型，支持Hadoop、HBase、CouchDb，能够以组件形式不断扩展对新的数据格式支持。
3) 数据交换引擎可以满足大规模数据的并发处理，完成企业级的数据交换场景。
4) 支持批量/单次，同步/异步，增量/全表，定时/实时等多种交换方式。
5) 支持灵活的、多角度的作业调度管理，包括事件、文件到达和计划调度以及手工触发。
6) 支持作业优先级分配，支持执行多种类型的作业任务。
7) 一般性的作业/任务无需编码和复杂配置就能实现，对于复杂作业/任务有脚本或程序语言作为扩展支撑。
具备二次开发能力，提供详尽的开发文档。
2.2.2.1交换平台功能要求
功能 | 概述 |
传输交换 | 支持异构数据库间的数据集成与协同，并保证多数据库(异构或同构)之间的全局事务一致，可以通过加载脚本或程序满足复杂输入输出，如 sql、javascript、java等；支持主流的数据库，如 Oracle、MySQL、SQL Server等，支持与部分非主流关系型数据库进行对接，包括Microsoft Access、Microsoft Excel、Dbase、VisualFoxpro 等。数据集成接口必须支持包括 JMS Topic、JMS 、Queue、Web Service、Txt 文件、excel 文件、XML 文件，支持操作系统的网络协议，包括 FTP、FTPS、SFTP、SSH等文件传输方式； 支持多种数据交换策略，实时同步、事件触发、定时任务、按需触发等以满足不同的交换需求。支持多种数据同步模式，批量数据全同步、增量数据同步，在数据整合过程中支持数据的合并与拆分。 提供数据订阅和通知功能。把数据变化的信息实时推送到订阅者，提供页面上的下载或数据接口。 采用主流的 Web Service 技术，支持 XML、Json 数据格式。具备日志功能，能够查询到接口的调用情况，并能以图表、日志形式展现。数据共享接口工具需要完全采用 B/S 架构，在不安装任何客户端软件的基础上通过浏览器即可对校内信息接口进行管理，便于用户维护使用。 |
作业/任务 | 提供可视化界面进行数据交换作业管理和设计工具，实现数据采集、交换、转换等工作的配置工作。 提供作业任务调度等管理界面。具备完善的监控管理机制。监控数据交换任务的全过程并记入日志，为管理人员进行性能分析和故障判断提供直观详实的数据。 支持任务执行完后的消息提醒，错误警报，支持邮件发送ᨀ醒。 要求交换过程先对源数据按照数据标准进行转换、清洗，然后加载到基础数据库；保证未转换过的源数据不在基础数据库存储，以减少基础数据库中数据的冗余、降低管理难度。 |
管理监控 | 用户管理功能。包括角色和用户和添加、删除、修改授权等功能，支持统一身份认证。 集中管理。控制各交换节点(基础数据库、主题数据库、业务数据库)间数据交换规则、映射关系，提供数据交换全过程的可视化配置，支持节点作业流量监控和统计分析 提供统一的监控中心，能监控和管理交换流程和系统性能，并能快速捕获和统计异常信息 应支持可视化服务器状态监控，及时了解服务器的运行状况（启动/异常等），支持资源预警，ᨀ供图形化方式实时跟踪服务器CPU、内存、磁盘空间等状态变化，设置服务器资源阀值，实时告警通知。 |
可移植性与安全 | 支持包括 Unix、Linux、Windows 等不同的操作系统，支持跨平台的部署，不同平台间平滑移植；支持集群部署和负载均衡，确保无单点故障，提供可靠、高效服务。 支持 https 传输协议或数字加密等安全保障方式，确保数据在交换过程中不能被非法篡改、非法访问，实现数据防篡改、数据加密的功能。 |
2.2.2.3规范和技术文档
中标方提供以最终实际运行状态下的平台操作手册、开发规范和开发文档。
2.2.2.4性能指标
1) 支持 7 * 24 小时运行，并支持热部署；
2) 每秒不低于 15000 条以上数据处理能力（需提供权威部门检测报告）；
3) 支持虚拟机部署。
2.2.3 数据总线服务
构建校园服务总线平台，保障应用系统间互联互通。通过专业的商用服务总线产品来保障学校应用系统之间在消息、事件和服务的级别上动态的互连互通软件系统，通过校园服务总线消除异构系统间技差异，实现不同服务之间的通信与整合，推动学校业务部门之间业务协作。
2.2.3.1数据总线技术要求
1) 支持当前主流通讯协议和方式，比如 HTTP、 HTTPS、 SOAP、JMS、TCP、UDP、FTP、Email、EJB、Tuxedo 等；
2) 支持常用的系统平台，能运行在包括 Windows、Linux、AIX、Solaris 和 HPUX等系统之上；
3) 支持常用 Web server，如 IBM WebSphere，Oracle WebLogic Server，IIS，Nginx，Apache，Tomcat 等
4) 支持常用数据库平台，兼容数据库包含 Oracle、Sybase、DB2、MySQL、MS SQL Server、Informix 等
5) 兼容多种编程语言与开发平台，使用标准协议方式实现总线服务的接入与访问，为学校异构系统的接入提供最大兼容。支持常用 WEB 开发语言，JAVA，JSP，C#、ASP、ASPX、PHP 等
6) 多种基于标准协议的接入功能，如 SOAP、HTTP、HTTPS，JMS、MQ、Socket 等，可实现不同协议间的自由转换，满足不同业务应用的需要。
7) 多报文格式支持： 定长、分隔符、XML、SOAP、JSON 等；
8) 确保消息传递：一旦信息被创建，将保证信息到达并且只到达一次，当系统出现问题时可自动执行恢复；
9) 具有良好的扩展性，可以以组件形式支持自定义协议适配器的开发；
10) 提供扩展 API 接口，开发文档等。
2.2.3.2数据总线功能要求
功能 | 描述 |
服务功能 | 实现统一的客户化应用服务接口，实现对各种数据源、信息源以及各种应用系统的无缝衔接，支持大多数主流的数据库、消息中间件产品和通信协议。 实现对不同技术、语言、应用ᨀ供的功能接口进行标准服务化封装，并提供图形化、模版化开发工具，实现快速、准确的服务开发。 同一服务多协议功能，服务可多种协议接入方式，便于不同的服务使用者进行灵活选择。 必须提供服务组件的服务注册和服务发布功能，实现服务接口、服务运行与服务参数等各种服务信息的注册和发布； 服务的编排组合功能，组合成新功能的服务，以便满足业务需求的新增和变更。 多种辅助开发工具、如生成、打包、部署等功能，可以快速的对业务服务进行建模，可在代理仿真环境中进行便捷的集成测试。 |
消息功能 | 实现服务之间的路由、协议转换和格式转换，提供多种消息传递形式(请求/响应、单路请求、发布/订阅等)； 提供基于内容消息动态路由方式，在使用动态路由时，总线不仅提供可配置的路由规则库，同时还可引入第三方系统作为路由规则库。 消息可被多个消息订阅者同时接收，可以广播；可实现消息多种不同格式的转换、映射，支持使用 XSLT 进行转换；可实现消息格式的二次丰富，包括数据内容丰富、数据样式丰富等。 必须有消息可靠传递机制：一旦信息被创建，将保证信息到达并且只到达一次，当系统出现问题时可自动执行恢复； |
管理功能 | 总线提供对服务的整个生命周期内管理和控制功能，包括服务的版本管理、发布/订阅管理，服务开发的配置文件更改，服务的启动、停止等操作。配置文件包括数据源、服务断点的配置信息、服务的日志目录等。通过编目功能使得用户可以对服务以及资源实例进行灵活的分类。用户可进行查询、新增、修改编目等操作。提供用于服务端点描述功能，如支持 WSDL 形式描述的 Web 服务和XML Schema 定义的数据形式，以便为业务部门应用系统开发提供支持。 ESB 产品应提供可视化服务监控平台，可以方便地对部署在分布式服务总线上的各服务执行情况进行实时监控，通过数据统计可进行更为具体、细致的业务分析。 总线支持多级管理机制，通过统一的管理工具对分布式总线上的不同服务节点进行管理工作，提供多级管理权限控制机制：包括域授权、主机授权、服务授权。支持对总线中的服务支持节点认证、用户认证、 服务认证、IP 认证多种方式，确保应用安全地访问企业服务总线提供的服务。 基于权限认证功能，通过安全审计可以查看到总线服务的访问情况。提供黑名单审计功能，有效判断服务的安全性；支持多种消息加密解密机制和规范，实现数据一致性和完整性。 应记录服务的执行过程，如记录服务内容、服务调用是否成功、服务执行时间等。 |
2.2.3.3规范和技术文档
中标方提供以最终实际运行状态下的平台操作手册、开发规范和开发文档。
2.2.3.4性能指标
1) 支持 7 * 24 小时运行，并支持热部署；
2) 每秒不低于 4000 个以上业务处理能力（需提供权威部门出具的检测报告）；
3) 支持集群部署，必须保证不会出现单点故障；
4) 提供负载均衡能力；
5) 支持虚拟机部署。
2.2.4 数据治理规范标准设计
学校信息标准是学校范围内的数据字典，为信息交换、资源共享提供基础性条件。是学校信息化建设的重中之重，对推进学校信息化建设，保证各类信息的交流与共享，有着重要意义。信息标准需要保证采集、处理、交换、传输过程中有统一、科学、规范分类和描述，能够使信息有序流通、最大限度地实现信息资源共享，使学校信息系统得到协同发展，发挥信息资源综合效益。
校本数据标准建立在国家教育行业权威标准基础上的、适合我校信息化建设的规范体系，具体的标准细节如下表所示。
表 数据治理规范标准依据的国家教育系统标准集一览表
序号 | 标准代码 | 标准名称 |
1 | JY/T 1006-2012 | 高等学校管理信息 |
2 | JY/T 1001-2012 | 教育管理基础代码 |
3 | JY/T 1002-2012 | 教育管理基础信息 |
4 | JY/T 1003-2012 | 教育行政管理信息 |
5 | JY/T 1007-2012 | 教育统计信息 |
6 | GB/T 29263-2012 | 信息技术：面向服务的体系结构（SOA）应用的总体技术要求 |
7 | GB/T 32430-2015 | 信息技术 SOA 应用的服务分析与设计 |
8 | CELTS-34 | 高等学校管理信息标准 |
2.2.4.1 学校信息标准规范
信息标准是学校范围内的数据字典，为信息交换、资源共享提供基础性条件，为学校信息化建设的重中之重，对推进学校信息化建设，保证各类信息的交流与共享，有着重要意义。信息标准需要保证采集、处理、交换、传输过程中有统一、科学、规范分类和描述，能够使信息有序流通、最大限度地实现信息资源共享，使学校信息系统得到协同发展，发挥信息资源综合效益。
校标数据标准必须建立在国家教育行业权威标准基础上的、适合我校信息化建设的规范体系。具体的标准细节如下表所示。具体包括但不限于以下内容：信息子集建设、数据代码标准建设、交换标准、交换接口标准和数据模型等。
序号 | 标准代码 | 标准名称 |
1 | JY/T 1006-2012 | 高等学校管理信息 |
2 | JY/T 1001-2012 | 教育管理基础代码 |
3 | JY/T 1002-2012 | 教育管理基础信息 |
4 | JY/T 1003-2012 | 教育行政管理信息 |
5 | JY/T 1007-2012 | 教育统计信息 |
6 | GB/T 29263-2012 | 信息技术：面向服务的体系结构（SOA）应用的总体技术要求 |
7 | GB/T 32430-2015 | 信息技术 SOA 应用的服务分析与设计 |
8 | CELTS-34 | 高等学校管理信息标准 |
9 | XB-XXXXXX | 校标 |
必须支持NoSQL数据库的需求。
建设内容包括：1信息子集建设 2数据代码标准建设 3交换标准 4交换接口标准 5数据模型 4 非结构化文档数据对接标准。
2.2.4.2数据接入标准规范
数据库管理的科学数据类型各异，各有特色。为便于阐述，本规范将专业库归纳为以下两个类型：
(1)关系型数据库：建立在关系模型基础上的数据库。
(2)非关系型数据库：不可关系化的数据，如文件型数据，文档等。
本规范列举之条款，无特别注明的，可同时适用于关系型数据库和非关系型数据库两种类型，专门针对关系型数据库（或非关系型数据库）的内容均在章节前加以注明，非关系型数据库（或关系型数据库）可不必遵守，读者在阅读过程中请加以区别。
数据库的数据形式应有正确合理的选择，一般而言应符合学科领域常用的主流数据格式，在满足这一原则的前提下，因关系型数据库的整合深入程度高于非关系型数据库，在能使用关系型数据库管理的场合应尽可能使用关系型数据库进行管理。
2.2.4.3 数据抽取标准规范
数据的抽取是从各个不同的专题子库中抽取数据到应用层数据库的过程，在抽取的过程中需要挑选不同的抽取方法，尽可能的提高数据处理的运行效率。数据的抽取需要在调研阶段做大量工作，分析科研应用所需数据来自几个专题子库，各个专题子库采用的数据组织方式等问题，并根据组织层数据及科研应用数据需求的具体情况进行数据抽取的详细设计。
2.2.4.4 数据清洗标准规范
原始数据中有可能存在着大量的脏数据，需要利用有关技术如数理统计、数据挖掘或预定义的数据清洗规则将脏数据转化成满足数据质量要求的数据。不符合要求的数据主要是有不完整的数据、错误的数据和重复的数据三大类。
(1)不完整的数据，其特征是一些应该有的信息缺失。需要将这一类数据过滤出来，列出其缺失的内容，要求在规定的时间内补全。补全后再写入数据库。
(2)错误的数据，产生原因可能是在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车、日期格式不正确、日期越界等。这一类错误需要用SQL 的方式挑出来，要求限期修正。
(3)重复的数据，将重复数据记录的所有字段筛选出来，然后进行确认并清除。
经过清洗的数据满足以下要求：
(1)单一字段中不存在多种信息；
(2)相同对象的名称表达一致；
(3)缩写词、惯用语的表达一致；
(3)值与字段名含义匹配；
(4)同类数据的计量单位统一；
(5)同一字段内的数据格式统一。
2.2.4.5 数据整合标准规范
数据集成用于将来自不同数据源的数据整合成一致的数据存储。元数据、相关分析、数据冲突检测和语义异种性的解析都有助于数据集成。 主要方法包括：
➤模式匹配
利用数据库的元数据对异构数据进行映射转换，形成模式匹配。
➤消除冗余
利用相关行分析的方法检测冗余，消除重复数据。
2.2.4.6 数据管理标准规范
➤数据库管理规范
目前支持的数据库类型有Oracle、MS SQL 、MySQL、DB2、Sybase 等数据库。在数据同步之前需要准备数据库相关的用户名、密码以及数据库名和数据库地址等信息，并确保数据库连接畅通。
在进行数据同步前需要准备好需要同步的表的信息，如需要同步数据源的那张表中的那些数据等，并建立好目标表的表结构。
➤表命名规范
序号 | 命名对象 | 命名规则 | 举例 |
1 | 实体表 | 系统编号+_+表名 | 发卡系统客户资料表(CUSTR)：CUP_CUSTR |
2 | 临时表 | TMP_+系统编号+_+表名 | 客户资料表的临时表： TMP_CUP_CUSTR |
➤索引命名规范
序号 | 命名对象 | 命名规则 | 举例 |
1 | 索引 | idx_+表名+_+列名（或列名缩写） | 客户资料表的客户证件号码CUST_NBR上的索引为：IDX_CUSTR_CUST_NBR |
➤表空间命名规范
序号 | 命名对象 | 命名规则 | 举例 |
1 | 数据表空间 | TS_+用户名+_data | ODS层的数据存储表空间：TS_ODS_data |
2 | 索引表空间 | TS_+用户名+_idx | ODS层的索引存储表空间：TS_ODS_ idx |
2 | 临时表空间 | TS_+用户名+_TMP | ODS临时表存储表空间：TS_ODS_TMP |
➤过程名规范
过程名称包括procedure、function、package。按照不同类型的实现逻辑，命名方式也不一致：
序号 | 实现逻辑 | 命名规则 | 举例 |
1 | 实现项目中通用的逻辑 | p_+功能 F_+功能 PKG_+功能 | p_trunc |
2 | 实现某个特定目标表内部的逻辑处理 | p_+目标表 F_+目标表 PKG_+目标表 | 如处理dds 的客户资料表: p_dds_ CUP_CUSTR |
➤视图名规范
序号 | 命名对象 | 命名规则 | 举例 |
1 | 普通视图 | V_+表名（当为多个表时按数据逻辑，取实现逻辑的英文简称） | 如V_ CUP_CUSTR |
2 | 物化视图 | MV_+表名（当为多个表时按数据逻辑，取实现逻辑的英文简称） | 如MV_ CUP_CUSTR |
2.2.4.7 数据库数据同步规范
对于数据库中的表的数据同步这里有三种方式实现。三种方式对表中的数据都有一定的数据规范。
（1）全文比对同步
前提条件：
源数据表中需要有可唯一标识某一行的列
实现方式：
全文比对方式同时将业务系统中USERINFO表的数据和前置交换区USERINFO表的数据抽取到“对比记录”步骤进行数据的分批比对，对比完成后“对比记录”会添加一个对比结果字段，将数据交给“Swinch/Case”步骤根据对比结果字段信息分别将三种不同的操作交给后面的流程处理。
1new操作会将数据传送给“选择插入的数据”进行数据过滤交给“插入”把数据插入到前置交换区的USERINFO表中。
2changed操作会将数据传送给“选择更新的数据”进行数据过滤交给“更新”把前置交换区的USERINFO表中对应的数据更新。
3deleted操作会将数据传送给“选择删除的数据”进行数据过滤交给“删除”把前置交换区的USERINFO表中对应的数据删除。
前提条件：
1创建临时表存放增量数据，临时表中要增加操作顺序以及操作类型两个字段。
2 为源数据表创建操作类型的触发器。
源数据表需要有可唯一标识某一行的列。
实现方式：
以Oracle数据库为例，建立一张表结构和USERINFO表相同的USERINFO_TRI表并添加操作字段OPERATION和排序字段T_ID。增加一个Sequences(userinfo_seq)用于对操作排序。在USERINFO表上建立增删改对应的三个触发器。
USERINFO_INSERT触发器
create or replace trigger userinfo_insert before insert on userinfo for each row declare -- local variables here begin insert into userinfo_tri (id,name,......,operation,t_id) values(:new.id,:new.name,......,'insert',userinfo.nextval); end userinfo_insert; |
USERINFO_UPDATE触发器
create or replace trigger userinfo_update before update on userinfo for each row declare -- local variables here begin insert into userinfo_tri (id,name,......,operation,t_id) values(:new.id,:new.name,......,'update',userinfo.nextval); end userinfo_update; |
USERINFO_DELETE触发器
create or replace trigger userinfo_delete before delete on userinfo for each row declare -- local variables here begin insert into userinfo_tri (id,name,......,operation,t_id) values(:old.id,:old.name,......,'delete',userinfo.nextval); end userinfo_delete; |
业务系统对USERINFO表操作的时候会自动向USERINFO_TRI表中添加操作数据信息，DI模型获取USERINFO_TRI表中的数据，将数据交给“Swinch/Case”步骤根据USERINFO_TRI表的OPERATION字段信息分别将三种不同的操作交给后面的流程处理。
1 insert操作会将数据传送给“选择插入的数据”进行数据过滤交给“前置数据插入”把数据插入到前置交换区的USERINFO表中。
2 update操作会将数据传送给“选择更新的数据”进行数据过滤交给“前置数据更新”把前置交换区的USERINFO表中对应的数据更新。
3 delete操作会将数据传送给“选择删除的数据”进行数据过滤交给“前置数据删除”把前置交换区的USERINFO表中对应的数据删除。
最后做完以上操作后将同步完成的数据从USERINFO_TRI表中删除。完成整个同步过程。
(3) 时间戳同步
前提条件：
1 业务系统表中要有一个默认值为Sysdate的时间戳字段
2 业务系统表中需要有可唯一标识某一行的列，
实现方式：
1基于时间戳的增量数据抽取只能针对Insert/Update操作，Delete操作需要结合其它模式。
2先从“前置交换区”的USERINFO表中获取最大时间，接下来根据需要将日期的格式到“时间格式转换”步骤做日期格式的转换，然后将转换后的日期作为参数传递给“业务系统1”步骤查出业务系统中USERINFO表大于这个时间的所有数据交给“前置交换/插入更新”步骤来进行数据的插入或更新。
2.2.4.8 文件管理规范
对于文件型数据，对其组织管理有如下要求：
a) 须建立有元数据库来对文件型数据集进行管理，保证用户能够通过元数据查
找到相应的数据集。
b) 可用相同的元数据元素集描述的文件型数据集，使用同一个元数据库管理。
c) 所有的文件型数据集，必须有揭示其内容特征的元数据元素，同时必须包含：
唯一标识符
访问地址
在同步文件前需要准备好同步文件的文件系统信息，如要同步那些文件，同步到那个文件系统。
文件命名规范 ETL过程中使用的输入和输出文件都采用小写。
文件编码规范 标志文件和数据文件均统一采用文本文件、UTF-8编码格式；如果数据文件是压缩文件，则要求解压后的文件是UTF-8编码格式。
空文件处理规范 如果对应的源系统某张表当天没有产生业务数据，其也需要生成相应的数据文件，内容为空；并在标志文件中记录数据条数是0；
文件记录格式规范 每条记录一行，记录最后一个字段值后面不包含分隔符，每行行尾以回车换行符结尾；文件最后一行为空行，标识文件结束；如果是以定界方式提供文件的，各字段以’|’+0X1B(十六进制数1B)组合字符作为分隔符；
结构化文件类型 数据同步文件支持文本文件、Excel文件和xml文件。文件中的内容必须是规格化的需要包含字段名称。结构文件主要包含：文本文件、Excel文件和XML文件。
2.2.4.8数据交换共享标准规范
根据接口业务特征，在服务接入总线时，需要定义服务调用的同步或者异步调用。由于同步、异步通信在各自技术上特性不同，同步指发送方发出数据后，等接收方发回响应以后才发下一个数据包的通讯方式，这种通信方式，在集成接口中更适合实时信息的传输，如调用编码系统，对材料实例进行编码等；异步调用指发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式，这种通信方式，在集成接口中更适合非实时信息的传输，如对表单填写时服务端数据校验，当填完表单第一个属性值，接着填写第二个属性值，不需要等待第一个值的服务端数据校验响应，界面不会停卡在第一个表单，不会影响用户继续下一个表单填写，增强用户体验，用户在客户端与服务端数据通信，操作上更加人性化。
2.2.5 数据应用建设
2.2.5.1 数据应用中心建设价值
数据应用中心建设价值主要包括：快、准、省
➤快：
现状 (1) 定制化需求造成重复开发 (2) 实施团队需排期 (3) T+1延时满足不了精细化运营 提升价值目标 (1) 平台化，透明封装复用技术组件 (2) 自助化，简单配置，月=>天 (3) 实时化，驱动业务增长，天=>分
➤准：
现状(1) 取数方式各异，清洗逻辑各异 (2) 数据孤岛未打通整合 (3) 需求驱动实施，无法沉淀数据资产
提升价值目标：(1)统一化，统一数据归集和出口 (2) 管理化，元数据、数据地图、血缘 (3) 资产化，模型管理让数据可信赖
➤省
现状(1) 时间成本，需求排期和重复开发 (2) 人力成本，重复开发和缺少复用 (3) 硬件成本，集群资源滥用造成浪费
提升价值目标：(1) 自助化，节省时间就是节省成本 (2) 平台化，成熟技术组件高复用度 (3) 精细化，集群资源可估可查可量化
2.2.5. 2 数据应用建设特点和需求
业务条线众多：办事大厅系统、学生管理模块、财务管理系统、图书管理系统，几十个系统
技术选型众多：MySQL、Oracle、Hbase、Elasticsearch、MongoDB、Hive、Spark、Impala等
数据需求多样：报表、可视化、服务、推送、迁移、同步、数据应用等
数据需求多变：经常有周级产出数据需求和数据应用
数据管理考虑：数据元信息可查，数据定义和流程标准化，数据管理可控等
数据安全考虑：多级数据安全策略，数据链路可追溯，敏感数据不可泄露等
数据权限考虑：表级、列级、行级数据权限，组织架构、角色、权限策略自动化
数据成本考虑：集群成本、运维成本、人力成本、时间成本、风险成本等
数据应用建设要求是
从数据技术和计算能力复用，到数据资产和数据服务复用
数据应用建设会以更大价值带宽，快准精让数据直接赋能业务
2.2.5.3 数据应用中心技术要求
ESB 数据总线平台：ESB面向大数据项目开发和管理运维人员，致力于提供数据实时采集和分发解决方案。平台采用高可用流式计算框架，提供海量数据实时传输，可靠多路消息订阅分发，通过简单灵活的配置，无侵入接入源端数据，对各个IT系统在业务流程中产生的数据进行汇集，并统一处理转换成通过JSON描述的UMS格式，提供给不同下游客户订阅和消费。ESB可充当数仓平台、大数据分析平台、实时报表和实时营销等业务的数据源。
流处理平台：面向大数据项目开发和管理运维人员，致力于提供数据流式化处理解决方案。平台专注于简化和统一开发管理流程，提供可视化的操作界面，基于配置和SQL的业务开发方式，屏蔽底层技术实现细节，极大的降低了开发门槛，使得大数据流式处理项目的开发和管理变得更加轻量敏捷、可控可靠。
Spark计算服务平台：面向数据仓库工程师/数据分析师/数据科学家等，致力于提供数据虚拟化解决方案。既可作为数据应用底层数据查询计算统一入口，也可作为逻辑数据仓库与现有数据仓库互补。用户只需通过统一SQL服务调用和Spark交互，即可透明屏蔽异构数据系统异构交互方式，轻松实现跨异构数据系统透明混算。
Davinci可视应用平台：Davinci面向业务人员/数据工程师/数据分析师/数据科学家，致力于提供一站式数据可视化解决方案。既可作为公有云/私有云独立部署使用，也可作为可视化插件集成到三方系统。用户只需在可视化UI上简单配置即可服务多种数据可视化应用，并支持高级交互/行业分析/模式探索/社交智能等可视化功能。
2.2.5.4 数据应用中心场景描述
提供多种基本的大数据分析算法，包括数据统计分析类算法、大数据挖掘类算法、人工智能/机器学习类算法。预留新增10个大数据分析算法的开发工作。
【场景】
• 业务领域组数据团队需要紧急制作一批报表，不希望排期，希望可以自助完成，并且部分报表需要T+0时效性
【挑战】
• 业务组数据团队工程能力有限，只会简单SQL，之前要么排期，要么通过工具直连业务备库制作报表，要么通过Excel制作
• 数据来源可能来自异构数据库，没有很好的平台支持自助导数
• 对数据时效性要求很高，需要流上做数据处理逻辑
【总结】
• 平台全自助能力，大大提高了业务数字化驱动进程，无需排期等待，经过短暂培训，人均2-3日可以自助完成一张实时报表，实时报表不再求人
• 平台支持人员也无需过多参与，不再成为进度瓶颈
【能力】即席查询能力、批量处理能力、实时处理能力、报表看板能力、数据权限能力、数据安全能力、数据管理能力、租户管理能力、项目管理能力、作业管理能力、资源管理能力
2.2.6 数据展示(人员画像)应用建设
2.2.6.1 应用概述
通过图形化手段清晰地传达数据，促进信息的传递与沟通，是数据可视化的基础要素，也是设计美学和功能相结合的具体表现形式。可视应用平台理论的背景下，围绕“数据视图”和“可视组件”两个核心概念设计，支持多种可视化功能。支持各种不同的数据源对接。
应用支持以下功能：
(1) 回顾大量数据 决策者通过查看以图形形式呈现的数据，能够在短时间内有效地理解大量数据的意义，相比分析数据表格要快得多。
(2)发现趋势 时间序列数据通常蕴含趋势，但是当数据源种类繁多、数据量巨大时，发掘出隐藏在数据中的趋势便很难实现了。使用恰当的大数据可视化技术可以很容易地发现这些趋势，从而支持学校业务中更加快速和精准的决策。
(3) 识别相关性和意外的关系
大数据可视化的一个巨大优势是它可以让用户自由探索数据集，这并非为了寻找某个问题的特定答案，而是去挖掘数据所能带来的出人意料的结论。在数据中识别出以往未被重视的模式和关系可以为学校提供巨大的竞争优势。
(4)友好的数据呈现
大数据可视化提供了一种非常有效的方式来传达他人对数据的的发掘成果，因为使用图形化的方式传达信息更容易被理解。
2.2.6.2 应用技术要求
数据展示平台解决方案，面向学校用户，致力于提供一站式数据可视化解决方案。既可作为公有云/私有云独立使用，也可作为可视化插件集成到三方系统。用户只需在可视化UI上简单配置即可服务多种数据可视化应用，并支持高级交互/行业分析/模式探索/社交智能等可视化功能。
➤围绕View（数据视图）和Widget（可视组件）两个核心概念设计
View是数据的结构化形态，一切逻辑/权限/服务等相关都是从View展开
Widget是数据的可视化形态，一切展示/交互/引导等都是从Widget展开
作为数据的两种不同形态，二者相辅相成，让用户拥有一致的体验和认识。
➤强化集成定制能力和智能能力
集成定制能力指无缝集成到三方系统，并提供强大的定制化能力，使其和三方系统融为一体。
智能能力指共享优秀的数据可视化思想，激发用户对数据可视化表达能力和艺术美感的追求，同时也使数据展示平台更加智能的引导和提高用户的数据可视化能力。
智能能力指共享优秀的数据可视化思想，激发用户对数据可视化表达能力和艺术美感的追求，同时也使数据展示平台更加智能的引导和提高用户的数据可视化能力。
2.2.6.3 应用功能要求
➤数据源
支持多种 JDBC 数据源
支持 CSV 数据文件上传
➤数据模型
支持友好 SQL 编辑器进行数据处理和转换
支持自动和自定义数据模型设计和共享
➤可视化组件
支持基于数据模型拖拽智能生成可视化组件
支持各种可视化组件样式配置
支持自由分析能力
➤数据门户
支持基于可视化组件创建可视化仪表板
支持可视化组件自动布局
支持可视化组件全屏显示、本地控制器、高级过滤器、组件间联动、群控控制器可视组件
支持可视化组件大数据量展示分页和滑块
支持可视化组件 CSV 数据下载、公共分享授权分享以及可视化仪表板的公共分享和授权分享
支持基于可视化仪表板创建数据门户
➤数据大屏
支持可视化组件自由布局
支持图层、透明度设置、边框、背景色、对齐、标签等更丰富大屏美化功能
支持多种屏幕自适应方式
➤用户体系
支持多租户用户体系
支持每个用户自建一整套组织架构层级结构
支持浅社交能力
➤安全权限
支持 LDAP 登录认证
支持动态 Token 鉴权
支持细粒度操作权限矩阵配置
支持数据列权限、行权限
➤集成能力
支持安全 URL 嵌入式集成
支持 JS 融入式集成
➤多屏适应
支持大屏、PC、Pad、手机移动端等多屏自适应
2.2.6.4 应用支持场景
➤安全多样自助交互式报表
一次配置即可实现可视组件高级过滤、高级控制、联动、钻取、下载、分享等，帮助业务人员快速完成对比、地理分析、分布、趋势以及聚类等分析和决策。
自动布局的 Dashboard（仪表板），适用于大多数通过快速配置即可查看和分享的可视化报表。
自由布局的 Display（大屏），适用于一些特定的、需要添加额外修饰元素的、长时间查看的场景，通常配置这类场景需要花一定的时间和精力，如“人才评估平台”大屏。
➤实时运营监控
实时观察运营状态，衔接各个环节流程，对比检测异常情况，处理关键环节问题。
透视驱动与图表驱动两种图表配置模式，满足不同的应用场景需求。
➤快速集成
分享链接、IFRAME 或调用开发接口，方便快捷地集成到三方系统，并能够支撑二次开发与功能拓展，充分适应不同业务人员的个性化需求，快速打造属于自己的数据可视化平台。
2.2.6.5 AI赋能设计
AI赋能是一套智能模型全生命周期管理平台和服务配置系统，基于数据中心平台服务，通过对智能服务的共享复用、对智能服务研发相关角色进行管理，以及研发流程的标准化、自动化，对前台业务提供个性化智能服务的迅速构建能力的支持。
(1)AI 赋能的业务路线
用户画像构建方法主要包括：
师生画像的主要任务是给师生贴“标签”，准确精炼地描述师生的特征标识，标签内容从标签体系中选择，将师生的所有标签综合在一起，就可以构成师生的“画像”。
具体实施业务路线包括：
➤ 业务理解：根据业务需求设计实施方案、服务编排、通用方案模板管理
定义目标、定义场景范围、方案设计
➤ 数据处理：数据接入，数据的准备与分析、采样、标注。
获取数据、数据分析、预处理，样本采集与标注
➤模型学习：模型特征提取，训练，评估、调优管理,可复用模型库、算法库管理。
特征过程、模型迭代、学习与评估
➤运行监控：模型自动部署，发布，更新管理，性能监控，对外服务接口管理。
模型上线、线上性能评估、持续演进
(2)AI赋能场景分析举例
场景描述：贫困生决策树模型建设流程
具体实现过程：开始->数据中心平台中选取消费数据->统计学生各类消费信息->将数据拆分成训练集和测试集->利用训练集构建决策树模型->运用测试集对决策树进行剪枝->结束
2.2.7 数据安全管理
2.2.7.1 建设目标
建设可靠的数据安全保障体系，实现应用服务及数据调用的安全认证和安全审计，主动的异常数据操作行为的监控分析、预警机制，并提供异常问题的倒查追溯能力。
2.2.7.2 方案概述
从技术角度看，数据中心的安全防护可以从物理层、系统层、网络层、应用层、数据层来看，形成五个层次的纵深防御体系。从非技术角度来看，还需要管理运维安全。
物理层主要包括：各类设备和介质的访问授权控制与保护、传输介质访问控制与保护、电磁防护、环境安全保障等。
系统层主要包括：补丁管理、操作系统加固（含安全操作系统）、主机病毒/木马查杀软件、漏洞扫描、一机两用监控和终端安全助手等。
网络层主要包括：防火墙（UTM）、入侵防御、防病毒网关、VPN（加密机）、DDoS、网闸、异常流量分析、病毒监测预警以及入侵检测等。
应用层主要包括：基于应用系统的身份认证与授权、WEB防火墙、网站防篡改、应用日志审计以及安全渗透检测等。
数据层主要包括数据加解密、数据备份/恢复、数据存取控制等。
管理安全主要包括安全组织架构，安全制度，人员安全，系统建设安全，系统运维安全等方面。
2.2.7.3 数据治理项目安全管理方案需求
2.2.7.3.1 系统安全
序号 | 类别 | 内容 |
1 | 身份鉴别 | a) 应对登录操作系统和数据库系统的用户进行身份标识和鉴别； |
2 | b) 操作系统和数据库系统管理用户身份鉴别信息应不易被冒用，口令复杂度应满足要求并定期更换。口令长度不得小于8位，且为字母、数字或特殊字符的混合组合，用户名和口令禁止相同； | |
3 | c) 启用登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施。限制同一用户连续失败登录次数； | |
4 | d) 当对服务器进行远程管理时，应采取必要措施，防止鉴别信息在网络传输过程中被窃听； | |
5 | e) 应为操作系统和数据库系统的不同用户分配不同的用户名，确保用户名具有唯一性； | |
6 | 访问控制 | a) 应启用访问控制功能，依据安全策略控制用户对资源的访问； |
7 | b) 应实现操作系统和数据库系统特权用户的权限分离； | |
8 | c) 应严格限制默认帐户的访问权限，重命名系统默认帐户，修改这些帐户的默认口令； | |
9 | d) 应及时删除多余的、过期的帐户，避免共享帐户的存在。 | |
10 | 安全审计 | a) 审计范围应覆盖到服务器和重要客户端上的每个操作系统用户和数据库用户；系统不支持该要求的，应以系统运行安全和效率为前提，采用第三方安全审计产品实现审计要求； |
11 | b) 审计内容应包括重要用户行为、系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件，审计内容至少包括：用户的添加和删除、审计功能的启动和关闭、审计策略的调整、权限变更、系统资源的异常使用、重要的系统操作（如用户登录、退出）等； | |
12 | c) 审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等； | |
13 | d) 应保护审计记录，避免受到未预期的删除、修改或覆盖等； | |
14 | 入侵防范 | a) 操作系统应遵循最小安装的原则，仅安装必要的组件和应用程序，并通过设置升级服务器等方式保持系统补丁及时得到更新，补丁安装前应进行安全性和兼容性测试； |
15 | 恶意代码防范 | a) 应在本机安装防恶意代码软件或独立部署恶意代码防护设备，并及时更新防恶意代码软件版本和恶意代码库； |
16 | b) 应支持防恶意代码的统一管理。 | |
17 | 资源控制 | a) 应通过设定终端接入方式、网络地址范围等条件限制终端登录； |
18 | b) 应根据安全策略设置登录终端的操作超时锁定； | |
19 | c) 应根据需要限制单个用户对系统资源的最大或最小使用限度 |
2.2.7.3.2 网络安全
(1)网络拓扑
序号 | 类别 | 内容 |
1 | 结构安全 | a) 核心网络与管理网络应物理隔离； |
2 | b) 内部网络和外部网络有信息通信交换时防护强度应强于逻辑隔离； | |
3 | c) 具有层次网络结构的单位可统一提供互联网出口； | |
4 | d) 应保证关键网络设备的业务处理能力具备冗余空间，满足业务高峰期需要； | |
5 | e) 应保证网络各个部分的带宽满足业务高峰期需要； | |
6 | f) 应绘制完整的网络拓扑结构图，有相应的网络配置表，包含设备IP地址等主要信息，与当前运行情况相符； | |
7 | g) 应根据各部门的工作职能、重要性和所涉及信息的重要程度等因素，划分不同的子网或网段，并按照方便管理和控制的原则为各子网、网段分配地址段。 | |
8 | 边界完整性检查 | a) 应能够对内部网络中出现的内部用户未通过准许私自联到外部网络的行为进行检查。 |
9 | 入侵防范 | a) 应在网络边界处监视以下攻击行为：端口扫描、强力攻击、木马后门攻击、拒绝服务攻击、缓冲区溢出攻击、IP碎片攻击和网络蠕虫攻击等。 |
(2)网络设备
序号 | 类别 | 内容 |
1 | 访问控制 | a) 应在网络边界部署访问控制设备，启用访问控制功能； |
2 | b) 应能根据会话状态信息为数据流提供明确的允许/拒绝访问的能力，控制粒度为端口级； | |
3 | c) 应按用户和系统之间的允许访问规则，决定允许或拒绝用户对受控系统进行资源访问，控制粒度为单个用户。以拨号或VPN等方式接入网络的，应采用强认证方式，并对用户访问权限进行严格限制； | |
4 | d) 应限制具有拨号、VPN等访问权限的用户数量。 | |
5 | 安全审计 | a) 应对网络系统中的网络设备运行状况、网络流量、用户行为等进行日志记录； |
6 | b) 审计记录应包括：事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息。 | |
7 | 网络设备防护 | a) 应对登录网络设备的用户进行身份鉴别； |
8 | b) 应对网络设备的管理员登录地址进行限制； | |
9 | c) 网络设备标识应唯一；同一网络设备的用户标识应唯一；禁止多个人员共用一个账号； | |
10 | d) 身份鉴别信息应具有不易被冒用的特点，口令应有复杂度要求并定期更换。应修改默认用户和口令，不得使用缺省口令，口令长度不得小于8位，要求是字母和数字或特殊字符的混合并不得与用户名相同，口令应定期更换，并加密存储； | |
11 | e) 应具有登录失败处理功能，可采取结束会话、限制非法登录次数和当网络登录连接超时自动退出等措施； | |
12 | f) 当对网络设备进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听； | |
13 | g) 应封闭不需要的网络端口，关闭不需要的网络服务。如需使用SNMP服务，应采用安全性增强版本；并应设定复杂的Community控制字段，不使用Public、Private等默认字段。 |
(3)安全设备
序号 | 类别 | 内容 |
1 | 访问控制 | e) 应在网络边界部署访问控制设备，启用访问控制功能； |
2 | f) 应能根据会话状态信息为数据流提供明确的允许/拒绝访问的能力，控制粒度为端口级； | |
3 | g) 应按用户和系统之间的允许访问规则，决定允许或拒绝用户对受控系统进行资源访问，控制粒度为单个用户。以拨号或VPN等方式接入网络的，应采用强认证方式，并对用户访问权限进行严格限制； | |
4 | h) 应限制具有拨号、VPN等访问权限的用户数量； | |
5 | 安全审计 | c) 应对网络系统中的网络设备运行状况、网络流量、用户行为等进行日志记录； |
6 | d) 审计记录应包括：事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息； | |
7 | 网络设备防护 | h) 应对登录网络设备的用户进行身份鉴别； |
8 | i) 应对网络设备的管理员登录地址进行限制； | |
9 | j) 网络设备标识应唯一；同一网络设备的用户标识应唯一；禁止多个人员共用一个账号； | |
10 | k) 身份鉴别信息应具有不易被冒用的特点，口令应有复杂度要求并定期更换。应修改默认用户和口令，不得使用缺省口令，口令长度不得小于8位，要求是字母和数字或特殊字符的混合并不得与用户名相同，口令应定期更换，并加密存储； | |
11 | l) 应具有登录失败处理功能，可采取结束会话、限制非法登录次数和当网络登录连接超时自动退出等措施； | |
12 | m) 当对网络设备进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听； | |
13 | n) 应封闭不需要的网络端口，关闭不需要的网络服务。如需使用SNMP服务，应采用安全性增强版本；并应设定复杂的Community控制字段，不使用Public、Private等默认字段。 |
2.2.7.2.3 应用安全
序号 | 类别 | 内容 |
1 | 身份鉴别 | a) 应提供专用的登录控制模块对登录用户进行身份标识和鉴别； |
2 | b) 应用系统用户身份鉴别信息应不易被冒用，口令复杂度应满足要求并定期更换。应提供用户身份标识唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识；用户在第一次登录系统时修改分发的初始口令，口令长度不得小于8位，且为字母、数字或特殊字符的混合组合，用户名和口令禁止相同；应用软件不得明文存储口令数据； | |
3 | c) 应提供登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施； | |
4 | d) 应启用身份鉴别、用户身份标识唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理功能，并根据安全策略配置相关参数。 | |
5 | 访问控制 | a) 应提供访问控制功能，依据安全策略控制用户对文件、数据库表等客体的访问； |
6 | b) 访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作； | |
7 | c) 应由授权主体配置访问控制策略，并严格限制默认帐户的访问权限； | |
8 | d) 应授予不同帐户为完成各自承担任务所需的最小权限，并在它们之间形成相互制约的关系。 | |
9 | 安全审计 | a) 应提供覆盖到每个用户的安全审计功能，对应用系统的用户登录、用户退出、增加用户、修改用户权限等重要安全事件进行审计； |
10 | b) 应保证审计活动的完整性，保证无法删除、修改或覆盖审计记录； | |
11 | c) 审计记录的内容至少应包括事件的日期、时间、发起者信息、类型、描述和结果等； | |
12 | 通信完整性 | 应采用校验码技术保证通信过程中数据的完整性。 |
13 | 通信保密性 | a) 在通信双方建立连接之前，应用系统应利用密码技术进行会话初始化验证； |
14 | b) 应对通信过程中用户口令、会话密钥等敏感信息字段进行加密 | |
15 | 软件容错 | a) 应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的数据格式或长度符合系统设定要求； |
16 | b) 在故障发生时，应用系统应能够继续提供部分功能，确保系统能够实施恢复措施。 | |
17 | 资源控制 | a) 当应用系统的通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话； |
18 | b) 应能够对应用系统的最大并发会话连接数进行限制； | |
19 | c) 应能够对单个帐户的多重并发会话进行限制； |
2.2.7.2.4 数据安全
序号 | 类别 | 内容 |
1 | 数据完整性 | a) 应能够检测到鉴别信息和重要业务数据在传输过程中完整性受到破坏。 |
2 | 数据保密性 | a) 应采用加密或其他保护措施实现鉴别信息的存储保密性。 |
3 | 备份和恢复 | a) 应对重要信息进行备份，并对备份介质定期进行可用性测试；（增强） |
4 | b) 应提供关键网络设备、通信线路和数据处理系统的硬件冗余，保证系统的可用性。 |
2.2.7.2.5 管理安全
(1)组织架构
序号 | 类别 | 内容 |
1 | 岗位设置 | a) 应设立安全主管、安全管理各个方面的负责人岗位，并定义各负责人的职责； |
2 | b) 应设立系统管理员、网络管理员、安全管理员等岗位，并定义各个工作岗位的职责。 | |
3 | 人员配备 | a) 应配备一定数量的系统管理员、网络管理员、安全管理员等； |
4 | b) 安全管理员不能兼任网络管理员、系统管理员、数据库管理员等。 | |
5 | 资金保障 | a) 应保障落实信息系统安全建设、运维及等级保护测评资金等； |
6 | b) 系统建设资金筹措方案和年度系统维护经费应包括信息安全保障资金项目。 | |
7 | 授权和审批 | a) 应根据各个部门和岗位的职责明确授权审批部门及批准人，对系统投入运行、网络系统接入和重要资源的访问等关键活动进行审批； |
8 | b) 应针对关键活动建立审批流程，并由批准人签字确认，并存档备查。 | |
9 | 沟通和合作 | a) 应加强各类管理人员之间、组织内部机构之间以及信息安全职能部门内部的合作与沟通； |
10 | b) 应加强与行业信息安全监管部门、公安机关、通信运营商、银行及相关单位和部门的合作与沟通。 | |
11 | 审核和检查 | a) 安全管理员应负责定期进行安全检查，检查内容包括系统日常运行、系统漏洞和数据备份等情况。 |
(2)安全管理制度
序号 | 类别 | 内容 |
1 | 管理制度 | a) 应制定信息安全工作的总体方针和安全策略，说明机构安全工作的总体目标、范围、原则和安全框架等； |
2 | b) 应对安全管理活动中重要的管理内容建立安全管理制度； | |
3 | c) 应对安全管理人员或操作人员执行的重要管理操作建立操作规程。 | |
4 | 制定和发布 | a) 应指定或授权专门的部门或人员负责安全管理制度的制定； |
5 | b) 应组织相关人员对制定的安全管理制度进行论证和审定； | |
6 | c) 应将安全管理制度以某种方式发布到相关人员手中。 | |
7 | 评审和修订 | a) 定期或在发生重大变更时对安全管理制度进行检查和审定，对存在不足或需要改进的安全管理制度进行修订。 |
(3) 人员安全
序号 | 类别 | 内容 |
1 | 人员录用 | a) 应指定或授权专门的部门或人员负责人员录用； |
2 | b) 应规范人员录用过程，对被录用人员的身份、背景和专业资格等进行审查，对其所具有的技术技能进行考核； | |
3 | c) 应与安全管理员、系统管理员、网络管理员等关键岗位的人员签署保密协议。 | |
4 | 人员离岗 | a) 应规范人员离岗过程，及时收回离岗员工的所有访问权限； |
5 | b) 应取回各种身份证件、钥匙、徽章等以及机构提供的软硬件设备； | |
6 | c) 只有在收回访问权限和各种证件、设备之后方可办理调离手续。 | |
7 | 人员考核 | a) 应定期对各个岗位的人员进行安全技能及安全认知的培训级考核。 |
8 | 安全意识教育和培训 | a) 应对各类人员进行安全意识教育、岗位技能培训和相关安全技术培训； |
9 | b) 应对安全责任和惩戒措施进行书面规定并告知相关人员，对违反违背安全策略和规定的人员进行惩戒； | |
10 | c) 应按照行业信息安全要求，制定安全教育和培训计划，对信息安全基础知识、岗位操作规程等进行的培训应至少每年举办一次。 | |
11 | 外部人员访问管理 | a) 应确保在外部人员访问受控区域前得到授权或审批，批准后由专人全程陪同或监督，并登记备案。 |
(4)系统建设安全
序号 | 类别 | 内容 |
1 | 系统定级 | a) 应明确信息系统的边界和安全保护等级； |
2 | b) 应以书面的形式说明信息系统确定为某个安全保护等级的方法和理由； | |
3 | c) 对信息系统要统一确定安全保护等级。 | |
4 | d) 应确保信息系统的定级结果经过行业信息安全主管部门批准，方可到公安机关备案。 | |
5 | 安全方案设计 | a) 应根据系统的安全保护等级选择基本安全措施，并依据风险分析的结果补充和调整安全措施； |
6 | b) 应以书面形式描述对系统的安全保护要求、策略和措施等内容，形成系统的安全方案； | |
7 | c) 应对安全方案进行细化，形成能指导安全系统建设、安全产品采购和使用的详细设计方案； | |
8 | d) 应组织相关部门和有关安全技术专家对安全设计方案的合理性和正确性进行论证和审定，重大项目应报行业信息安全主管部门进行信息安全专项审查批准。 | |
9 | 产品采购和使用 | a) 应确保安全产品采购和使用符合国家的有关规定； |
10 | b) 应确保密码产品采购和使用符合国家密码主管部门的要求； | |
11 | c) 应指定或授权专门的部门负责产品的采购； | |
12 | d) 专用信息安全产品应经行业主管部门指定的安全机构测评方可采购使用。 | |
13 | 自行软件开发 | a) 应确保开发环境与实际运行环境物理分开； |
14 | b) 应制定软件开发管理制度，明确说明开发过程的控制方法和人员行为准则； | |
15 | c) 应确保提供软件设计的相关文档和使用指南，并由专人负责保管； | |
16 | 外包软件开发 | a) 应根据开发需求检测软件质量； |
17 | b) 应确保提供软件设计的相关文档和使用指南； | |
18 | c) 应在软件安装之前检测软件包中可能存在的恶意代码； | |
19 | d) 外包开发的软件应在本单位存有源代码备份，并已通过软件后门等安全性检测。 | |
20 | 工程实施 | a) 应指定或授权专门的部门或人员负责工程实施过程的管理； |
21 | b) 应制定详细的工程实施方案控制实施过程； | |
22 | 测试验收 | a) 应对系统进行安全性测试，并出具安全性测试报告； |
23 | b) 在测试验收前应根据设计方案或合同要求等制订测试验收方案，在测试验收过程中应详细记录测试验收结果，并形成测试验收报告； | |
24 | c) 应组织相关部门和相关人员对系统测试验收报告进行审定，并签字确认。 | |
25 | 系统交付 | a) 应制定系统交付清单，并根据交付清单对所交接的设备、软件和文档等进行清点； |
26 | b) 应对负责系统运行维护的技术人员进行相应的技能培训，对安全教育和培训的情况和结果进行记录并归档保存； | |
27 | c) 应确保提供系统建设过程中的文档和指导用户进行系统运行维护的文档。 | |
28 | 系统备案 | 应将系统等级及相关材料报系统主管部门备案； |
29 | 等级测评 | 应选择具有国家相关技术资质和安全资质的测评单位进行等级测评。 |
30 | 安全服务商选择 | a) 应选择符合国家及行业有关规定的服务商开展安全服务； |
31 | b) 应与选定的安全服务商签订安全协议，明确安全责任； | |
32 | c) 应与服务商签订安全服务合同，确保提供技术培训，并明确服务承诺。 |
(5) 系统运维安全
序号 | 类别 | 内容 |
1 | 环境管理 | a) 应指定专门的部门或人员定期对机房供配电、空调、温湿度控制等设施进行维护管理； |
2 | b) 应配备机房安全管理人员，对机房的出入、服务器的开机或关机等工作进行管理； | |
3 | c) 应建立机房安全管理制度，对有关机房物理访问，物品带进、带出机房和机房环境安全等方面的管理作出规定； | |
4 | d) 应加强对办公环境的保密性管理，规范办公环境人员行为，包括工作人员调离办公室应立即交还该办公室钥匙和不在办公区接待来访人员等。 | |
5 | 资产管理 | a) 应编制并保存与信息系统相关的资产清单，包括资产责任部门、重要程度和所处位置等内容； |
6 | b) 应建立资产安全管理制度，规定信息系统资产管理的责任人员或责任部门，并规范资产管理和使用的行为； | |
7 | 介质管理 | a) 应确保介质存放在安全的环境中，对各类介质进行控制和保护，并实行存储环境专人管理； |
8 | b) 应建立移动存储介质安全管理制度，对移动存储介质的使用进行管控；（增加） | |
9 | c) 应对介质归档和查询等进行登记记录，并根据存档介质的目录清单定期盘点； | |
10 | d) 应对需要送出维修或销毁的介质，首先清除其中的敏感数据，防止信息的非法泄漏； | |
11 | e) 应根据所承载数据和软件的重要程度对介质进行分类和标识管理。 | |
12 | 设备管理 | a) 应对信息系统相关的各种设备（包括备份和冗余设备）、线路等指定专门的部门或人员定期进行维护管理； |
13 | b) 应建立基于申报、审批和专人负责的设备安全管理制度，对信息系统的各种软硬件设备的选型、采购、发放和领用等过程进行规范化管理； | |
14 | c) 应对终端计算机、工作站、便携机、系统和网络等设备的操作和使用进行规范化管理，按操作规程实现主要设备（包括备份和冗余设备）的启动/停止、加电/断电等操作； | |
15 | d) 应确保信息处理设备必须经过审批才能带离机房或办公地点。 | |
16 | 网络安全管理 | a) 应指定专人对网络进行管理，负责运行日志、网络监控记录的日常维护和报警信息分析和处理工作； |
17 | b) 应建立网络安全管理制度，对网络安全配置、日志保存时间、安全策略、升级与打补丁、口令更新周期等方面作出规定； | |
18 | c) 应根据厂家提供的软件升级版本对网络设备进行更新，并在更新前对现有的重要文件进行备份； | |
19 | d) 应定期对网络系统进行漏洞扫描，对发现的网络系统安全漏洞进行及时的修补； | |
20 | e) 应对网络设备的配置文件进行定期备份 | |
21 | f) 应保证所有与外部系统的连接均得到授权和批准； | |
22 | 系统安全管理 | a) 应根据业务需求和系统安全分析确定系统的访问控制策略； |
23 | b) 应定期进行漏洞扫描，对发现的系统安全漏洞及时进行修补； | |
24 | c) 应安装系统的最新补丁程序，在安装系统补丁前，首先在测试环境中测试通过，并对重要文件进行备份后，方可实施系统补丁程序的安装； | |
25 | d) 应建立系统安全管理制度，对系统安全策略、安全配置、日志管理和日常操作流程等方面作出具体规定； | |
26 | e) 应依据操作手册对系统进行维护，详细记录操作日志，包括重要的日常操作、运行维护记录、参数的设置和修改等内容，严禁进行未经授权的操作； | |
27 | f) 应定期对运行日志和审计数据进行分析，以便及时发现异常行为。 | |
28 | 恶意代码防范管理 | a) 应提高所有用户的防病毒意识，及时告知防病毒软件版本，在读取移动存储设备上的数据以及网络上接收文件或邮件之前，先进行病毒检查，对外来计算机或存储设备接入网络系统之前也应进行病毒检查； |
29 | b) 应指定专人对网络和主机进行恶意代码检测并保存检测记录； | |
30 | c) 应对防恶意代码软件的授权使用、恶意代码库升级、定期汇报等作出明确规定； | |
31 | 密码管理 | 应使用符合国家密码管理规定的密码技术和产品。 |
32 | 变更管理 | a) 应确认系统中要发生的变更，并制定变更方案； |
33 | b) 系统发生重要变更前，应向主管领导申请，审批后方可实施变更，并在实施后向相关人员通告； | |
34 | 备份与恢复管理 | a) 应识别需要定期备份的重要业务信息、系统数据及软件系统等； |
35 | b) 应规定备份信息的备份方式、备份频度、存储介质和保存期等； | |
36 | c) 应根据数据的重要性和数据对系统运行的影响，制定数据的备份策略和恢复策略，备份策略须指明备份数据的放置场所、文件命名规则、介质替换频率和将数据离站运输的方法； | |
37 | 安全事件处置 | a) 应报告所发现的安全弱点和可疑事件，但任何情况下用户均不应尝试验证弱点； |
38 | b) 应制定安全事件报告和处置管理制度，明确安全事件的类型，规定安全事件的现场处理、事件报告和后期恢复的管理职责； | |
39 | c) 应根据国家相关管理部门对计算机安全事件等级划分方法和安全事件对本系统产生的影响，对本系统计算机安全事件进行等级划分； | |
40 | d) 应记录并保存所有报告的安全弱点和可疑事件，分析事件原因，监督事态发展，采取措施避免安全事件发生。 | |
41 | 应急预案管理 | a) 应在统一的应急预案框架下制定不同事件的应急预案，应急预案框架应包括启动应急预案的条件、应急处理流程、系统恢复流程、事后教育和培训等内容； |
42 | b) 应对安全管理员、系统管理员、网络管理员等相关的人员进行应急预案培训，应急预案的培训应至少每年举办一次。 |
2.2.8 对接现有管理系统接口及处置要求（报价时须包含在内）
与原业务系统对接，投标单位中标后需提供相应的法律文书。
序号 | 名称 | 数据集成 | 拟处置方式 | 开发公司 | 时间 | 原合同/投标书条款摘录 |
1 | 教务系统 | √ | 对接 | |||
2 | 办事大厅 | √ | 对接 |
对接内容包含不限于：1 标准化（校标）数据对接 3 原系统非结构化文档对接。
3 建设规范
3.1 技术路线
3.1.1 部署方式
数据治理平台生产环境部署需要考虑
1系统高可用、可扩展
系统具有高可用：保证服务不间断；可扩展性：随着访问的增加或减少，系统具备良好的伸缩能力。
2服务负载均衡、可监控
负载均衡：将用户请求分散，保证服务应答的及时性。
监控（可视化）：服务器、系统的状态处于一个实时的监控之下。建议运营中心可监控方案可以采用。
3数据库高可靠
数据备份：数据库的备份及图片视频等多媒体文件的备份。
数据库服务器采用主从备份机制，Oracle数据库可以采用(Oracle RAC)，Mysql数据库可以采用Mysql主从配置，实现读写分离。
非结构化数据包括文本、图像、音频、视频、PDF、电子表格等。备份可以采用文件服务器完成，文件服务器同时需要master-slave完成主从备份。
生产与测试分离部署要求，测试开发环境可以根据需要进行精简部署，但中标方需要为自动化测试到持续部署系统技术保障。
3.1.2 知识产权
3.2 项目化实施管理
项目团队管理方式：
项目团队采用目标管理与过程管理相结合的动态管理方式。团队以客户需求为导向，通过计划、评估、执行、内审、复核等手段确保节点控制、质量达标和目标实现。
项目团队组织职能：
项目经理对项目负总责任，对内协调和管理项目，对外负责与客户沟通。
项目组开发人员对项目总负责人负责，对内协助项目总负责人开展项目管理工作。外协组依据项目组计划任务开展对外接待、沟通、协调与组织工作。
需求分析人员依据项目组计划编制客户需求调研计划，并依据调研计划进行相关调研工作、需求分析与评审工作。
系统分析与设计人员依据项目组计划展开系统分析、论证、规划、设计等工作。
3.3 技术服务要求
具体包括但不限于以下内容：
1 技术平台采用J2EE体系架构；
2各应用平台：采用业界主流应用集成平台；
3服务器操作系统：最新稳定的Linux64位操作系统；
4数据库管理系统：支持Oracle 11g或者Mysql5.5及以上版本；
5客户端操作系统或浏览器：支持主流浏览器（注意今后兼容性要求）
3.4 文档服务要求
3.4.1 技术文档
中标实施单位在实施项目过程中提供完备的技术文档。
包括提供完整的软件安装、操作、使用、测试、控制和维护手册，以及软件所有源代码（UML图），能够满足甲方对知识转移的要求。包括以下内容但不仅限于以下内容：
《用户调查报告》
《需求分析说明说》
《系统概要设计说明书》
《数据ER模型设计》
《数据库结构说明书》
《功能规格说明书》
《系统详细设计说明书》
《系统安装维护手册》
《系统部署手册》
《用户操作手册》
《测试用例和测试报告》
另外必须提供以光盘形式相关存档材料。
3.4.2 安装与使用说明书
安装与使用说明要求详见3.4.1技术文档。
3.5 技术服务要求
3.5.1 驻场人员
投标人应为采购人提供维护和升级服务，需保证在2小时内对采购人所提出的维护要求做出响应，并在作出响应24小时内派出工作人员进行故障排除。
服务方式和内容包括软件升级、提供技术指导、功能优化与支持服务、相关培训等内容，服务方式应采用现场服务，系统经过验收完成1年后，可以采用网络支持（不允许远程操作）与现场服务等。
3.5.2 服务时限
服务时限参照3.5.1驻场人员。在数据治理项目建设期间需要2名及以上开发人员常驻学校，配合校方完成平台建设。
3.5.3 培训人员
中标公司需承诺在系统建设和服务过程中为系统管理员、学校老师等各类用户现场培训，确保管理人员能熟练掌握日常维护及内容更新的能力。
3.6 测试、验收、交付要求
中标单位需要根据平台建设需求和系统设计方案，提供详细的系统验收手册和验收流程、验收通过标准，经甲方认可后，由双方共同组织人员进行系统验收；验收参与部门：系统使用单位、专家小组或第三方验收人员；开发单位。
验收后会提交本项目技术文档及其他相关全部资料等。