高校学分制教务教学管理系统建设方案Word文档格式.docx
《高校学分制教务教学管理系统建设方案Word文档格式.docx》由会员分享，可在线阅读，更多相关《高校学分制教务教学管理系统建设方案Word文档格式.docx（57页珍藏版）》请在冰豆网上搜索。
13）《大学信息标准与规范国家及教育部代码集》
14）《大学信息标准与规范校内自编代码集》
15）《大学信息标准与规范信息系统建设规范》
2.总体设计
2.1.总体目标
采用信息化手段，通过计算机应用软件、3G/4G无线网络技术建设高校学分制教务管理系统。
1.体现出先进的教学与教学管理理念
教务管理系统的宗旨在于使学校教学管理向高水平、规范化、标准化、便捷化迈进。
通过教务平台开发，平台体系设计应将先进的教学管理思想和方法体系纳入并具体体现，如注重教学管理中以人为本、全面发展、素质教育、创新能力培养、主体性、个性化、开放式、多样化、生态和谐、系统性等。
2.灵活多样的访问与管理权限体系
系统具有灵活多样的访问与管理权限体系。
总体来看，权限级别至少应该包括普通教师、二级学院管理人员、校区教学管理人员、教学督导、学校教学管理人员、学校领导层和学生等七个级别，各个级别之中，还要有不同的具体权限设置与分配机制。
3.统一的信息标准和规范、优化的业务流程
平台的定制开发过程中，达到整合各有关系统的教务基础数据、规范教务信息标准的目的,实现学校教务信息的高度统一和共享。
4.多元化的安全防范与预警功能
由于教务管理系统中存储有很多敏感数据，要求平台能够防范非法操作和入侵攻击，能记录所有操作轨迹。
一旦这些敏感数据发生了修改、更新操作，平台可以自主地提示与通知相关人员，并保存日志记录。
5.教学管理网络化和智能化
整个教学管理流程中的各环节、各角色的操作运用，能最大限度地在平台中完成，最大限度地减少纸质文本、减少人员实地办理的繁琐。
2.2.设计原则
根据系统特点和要求，在“先进性、实用性、标准化、开放性、整体性、共享性、安全性、保密性、可靠性、经济性、可扩展性、可维护性”等十二个方面提出原则性要求如下：
（1）先进性
系统采用国际先进的软件体系结构，先进的技术标准，保证系统的生命力。
系统的建设应以“高起点、高标准”严格要求，在系统设计上，首先应当具有前瞻性。
（2）实用性
系统结合实际的业务处理流程以及业务管理工作流程，设计结构合理、功能实用、符合实际业务需要的系统。
系统的设计在运行环境、使用操作等方面以实用为主，以方便使用和维护为出发点。
（3）标准化
系统建设采用的软件平台、数据标准、开发技术应符合公认的标准，符合国家、地方的有关标准与规范。
采用标准的数据描述语言以及标准的通信协议，适应以后的数据交换标准以及系统间互连的标准协议等。
（4）开放性
软件体系结构上，应充分考虑系统的开放性。
以模块化设计和基于组件的多层结构体系保证系统的开放性和灵活性。
（5）整体性
系统建设需进行整体的规划完善，通过科学的分布实施，建立全面覆盖业务，符合要求的系统。
系统建设具有整体性，即内容上全包括、数据上全部共享、流程上相互衔接、管理上协调统一。
（6）共享性
系统通过搭建共享平台接口进行数据共享，同时，系统提取和分析的信息库也能以标准的数据接口开放给其他部门使用，打破部门壁垒、信息孤岛，为业务管理提供有力的依据和手段。
（7）安全性
从身份验证到资源授权访问再到数据的安全性。
系统应能提供网络层和应用层的安全手段，防止系统外部成员的非法侵入以及操作人员的越级操作，从多个角度、环节考虑，确保系统和数据的安全。
（8）保密性
系统在权限功能规划上要考虑全责明晰，建立合理的可分配权限，使内容、功能管理有效、有序，减少人为的操作风险。
系统的访问和操作具备可回溯性，操作人员进行了哪些操作都有记录可查。
（9）可靠性
本系统为多部门使用的系统，系统需健壮、无故障运行周期长，应具有较高的性能可靠性。
（10）经济性
系统在规划和实施过程中，必须立足于现状，着眼于未来，遵循“统筹规划、分布实施、整合资源”的原则，避免系统的重复建设以及资源浪费。
（11）可扩展性
系统可以根据实际情况进行灵活的配置和组合，能方便地进行功能的调整以及系统的升级、扩展，以适应业务的不断发展和更新。
（12）可维护性
将应用与技术分离，建设方维护人员可自行维护本系统，如人员岗位的调整、工作流程的变化等，不需要对软件本身进行任何重新编码，通过维护模块的调整即可实现。
2.3.总体架构
系统主要由“1个规范、1个数据库、1个系统”构成。
“一个规范”即数据标准规范，根据教务管理要求，基于国家、省、市相关技术标准规范编制一套适应教务教学管理建设要求和实际情况的标准规范体系；
“一个数据库”即“基础信息资源库”，作为整个项目的基础数据支撑；
“一个系统”面向教务教学管理工作，实现高校学分制教务管理系统，主要包括：
系统维护管理、基础资源管理、学籍管理、成绩管理、人才培养计划管理、智能排课管理、考务管理、等级考试管理、选课管理、学分认证管理、教师调停课管理、实践实训管理、教材管理等。
总体架构主要包括感知层、网络层、数据层、服务层、平台层、应用层、政策法规、安全标准等层面。
项目建设基于信息标准，实现信息数据的集中部署，要做到以下五个方面的统一:
●统一数据标准（数据系统架构、数据库结构、数据表）；
●统一基础信息（文字、图片、音视频、虚拟素材等）；
●统一地理信息（位置信息、GPS数据、电子地图）；
●统一交换接口（内部数据交换接口规范、开放数据接口规范）；
●统一技术平台（硬件、软件、网络、安全）。
感知层：
通过各类数据采集和感知技术，如：
RFID、条形码、传感器、摄像头等，实现数据采集和存储，为整个系统治理应用体系提供基础数据的支撑；
网络层：
构建应用级物联、感知、互联、通信、卫星网络，为数据信息的传输流通起到支撑作用；
数据层：
系统业务处理的逻辑平台，它通过对数据核心层的调用访问业务数据，实现不同的功能模块，满足不同的业务需求；
所有业务功能在此统一平台上得到良好的封装和定义，以Web、手机终端服务的形式，运作在平台上，为用户提供各类信息服务；
应用层：
对于应用层，提供多样化的界面逻辑，实现对业务逻辑的应用。
2.4.应用架构
1.系统采用平台化开发，使用界面直观明了、简单方便，操作简便，用户使用体验好。
能灵活地定义参数和处理规则，使其符合工作要求。
具体包括：
1）用户界面基于Portal设计，可以通过管理员对师生的默认用户界面进行初始规划，包括界面风格、Portlet菜单及频道栏目面板布局、页面标签定义等。
用户可以自定义个人界面的布局，自定义功能组件。
软件界面可自适应PC、手机和平板电脑。
2）业务流程可定制，利用工作流引擎致力于打造工作流的可视化功能，使工作流的管理和建模简单、易用并且直观。
通过工作流管理模块，我院可以管理已经存在的工作流，包括对工作流的增删改查，以及对工作流进行统一部署。
还可以进行工作流运行实例的控制。
3）采用组件化开发，由低耦合的组件完成各项业务，通过组件管理器呈现给用户。
组件化开发有利于简化系统架构，并在系统升级、个性化服务等方面带来好处。
2.平台服务器端支持windows、linux、unix等主流操作系统，支持oracle数据库。
3.高并发性，要求在技术上引入缓存等机制，优化数据库设计，提高排课、选课、成绩查询、统计等性能瓶颈。
要求达到至少支持10000人同时在线，5000人并发登录和选课操作。
4.要求具有严格的安全机制，包括真正的三层结构（数据层、应用层、WEB层）、严格的身份授权机制（按角色、数据表、字段等授权）、敏感数据的监控预警（成绩异常修改监控）等。
5.本次项目建设要求满足学院现有的教学管理需求，并需要把我院原有教务管理系统中的数据迁移到新平台中，能顺利正常工作。
对系统内产生的废数据和临时数据，提供具体的清理管理方案，实现系统管理的方便清理。
6.软件可实现集中管理和分级管理相结合。
7.平台须支持集群部署，如应用服务器、数据库服务器。
8.提供可靠的服务器架构方案，可实现服务器系统、数据库的优化、安全冗余、备份，可实现双机热备。
9.可扩展性。
系统组成的各部分为独立运行的组件化子系统，相互之间通过标准的接口，充分体现系统的松散耦合性，极易扩展，方便二次开发或对接其他应用平台。
10.保证对各种浏览器（如：
IE9及以上版本，firefox，chrome等）的完美兼容。
解决电脑浏览器的兼容问题（例如由于浏览器兼容所导致的教师打印成绩单或者调停课申请单无法打印，教学日历无法保存的情况等），有相应的操作提示框。
11.提供移动端应用或服务，可接入微信公众号、企业微信号微应用，可定制教师、学生在微信公众号或企业微信号微应用中的业务流程、课表查询和教材申请、退还、查询等。
2.5.数据库设计
2.5.1.历史数据库设计
历史数据库用来存储实时数据库的历史数据。
实时数据库中只有各种设备的当前值（状态），而以前的实时数据要存储在历史数据库中，以备日后查询。
为了可以精确获取每个数据采集仪的任何时候状态，历史数据库中要保存所有节点的全部采样数据。
历史数据库系统采用大型商用关系型数据库。
历史数据库系统是整个应用程序的数据层。
它为各种客户提供所需要的历史数据。
历史数据库系统采用双机备用方式。
历史数据服务库系统的功能包括：
采样历史数据的存储；
计算各种分析所需的统计数据；
记录变位、SOE等随机性数据；
记录用户对应用程序的操作的日信息；
存储用户权限等安全信息；
提供Web发布所需的各种历史数据。
历史数据库系统的数据源由实时数据库系统提供，在实时数据库系统中，已经对数据质量、数据一致性、完整性作了处理，因此由实时数据库系统提供给历史数据库系统的数据均为有效数据。
实时数据库系统负责定时的将有效数据送给历史数据库系统的代理程序，随机数据在产生的时候送给代理程序，代理程序负责将数据写入历史库中。
同时代理程序负责定时对采样数据进行统计、计算并将结果存入数据库中。
历史数据系统示意图
2.5.2.历史数据
由实时数据库提供的采样数据存储在历史数据库中。
这些数据按类别、时间存储在数据库不同的历史表中。
I数据表命名规则
历史数据表名称按照一定的命名规则：
类型名称+时间。
如：
2001年7月10日的模拟量采样数据表应命名为SmpAna20010710，这张表将存储这一天的所有的模拟量采样数据。
以上设计主要基于对采样数据的查询方式，主要是要某一个量在某一段具体时间内的数据。
数据不存放在一个数据表中，可以大减少检索的次数。
当检索一个数据的时候，是先从系统数据表中检索出这张表的位置，然后定位这张表，再检索需要的数据。
而不必从一个大表中反复的检索、查找和定位。
这种检索方式也近似于字典查找的算法理论。
对于计算、统计数据也采用近似的处理方式。
II数据表索引（Index）
数据库的索引是一个B型树的数据结构。
当写入一记录时，数据库会对记录产生一个索引值，并在系统索引表（Sysindexes）中产生一条索引记录。
在检索一条记录时，从树的根节点到树叶的搜索方式进行，从而对有索引的记录加快检索速度。
但同时也降低了写入的速度。
对于采样数据，主要是记录值，因此可以考虑用没索引的表来表示。
III数据压缩存储
采样数据可能是一些不断重复的量。
重复记录会加大存储的空间和记录的行数。
因此可考虑数据变化时才存储，记录一个状态（值），并记录这个状态（值）重复的次数。
也就是：
数值—变化的压缩方式。
具体设计如下例：
如有一个模拟量，前一次的值如果和本次的值相同，则在记录中的次数计数器加1，否则添加一条记录。
2.5.3.统计数据
历史数据的存储方式同样是将数据按类分散在不同的表中，表要具有统一的命名规则。
数据统计是将各种采样数据计算生成所需要的一些统计数据。
数据统计与采样数据记录是同步进行的。
也就是说，当从实时数据库中取得采样数据并写入到采样记录表中的时候，就会触发一系列的统计和计算工作。
有一系列的中间结果产生出来，当在时间上满足要求的时候，就会将这个中间结果记录到相应的统计数据表中。
统计计算工作用ORACLE的触发器（Trigger）来完成，当采样数据更新时，会触发一系列的事件产生，事件驱动一系列的处理程序来处理是否写入数据库，更新统计数据的中间结果等。
这项工作在ORACLE后台为处理，使用大量的存储过程来加以实现。
2.5.4.临时表
临时表具有与普通表完全一样的属性，所不同的是它存储在Tempdb中而不放在当前数据库中，当用户连接并创建使用时它存在，当用户断开后临时表也会自动删除。
全局性临时表（以##开头作为标识）：
会各所有连接到数据库的用户开放，每一个用户均可以访问，只有当所有的用户都断开后，全局性临时表才会自动删除。
临时表的设计主要是为了考虑提高对报表、查询速度的要求。
通过组态的报表或定制的某个查询，是对固定的一些参数进行数据检索，这些量使用的频率最高。
考虑减少在无关的数据堆中检索的次数，因此想把这些用户最关心的数据量的记录放在一个专门的地方。
由于数据源的记录本来已在数据库中存在，而同样的数据在数据库中不应该重复，所以考虑将这样的数据放在临时表中，且为全局性临时表，为所有的数据连接用户开放。
临时表中的记录是最近一个时间段的数据和最近使用过的数据。
处理临时表中记录的算法应是先进先出的原则和最久不使用原则。
新数据将最老的数据并且最久没有使用过的数据覆盖。
临时表中的数据始终保持最新和最新使用过的数据。
这些数据也是用户使用频率最高的数据，这样可以提高报表、查询的检索数据速度。
2.5.5.数据冗余处理
数据冗余采用磁盘阵列的方式来实现。
数据冗余示意图
2.5.6.数据库安全
数据库安全性问题一直是系统安全的关键。
数据库安全性问题应包括两个部分：
（1）数据库数据的安全
它应能确保当数据库系统DownTime时，当数据库数据存储媒体被破坏时以及当数据库用户误操作时，数据库数据信息不至于丢失。
数据安全的解决，主要有系统双机热备份、数据库的备份和恢复等办法，本系统的数据安全，纳入信息中心的系统安全体系，共享一些硬件设施，实现数据的备份等。
（2）用户角色的管理：
这是保护数据库系统安全的重要手段之一。
它通过建立不同的用户组和用户口令验证，可以有效地防止非法的Oracle用户进入数据库系统，造成不必要的麻烦和损坏；
另外在Oracle数据库中，可以通过授权来对Oracle用户的操作进行限制，即允许一些用户可以对Oracle服务器进行访问，也就是说对整个数据库具有读写的权利，而大多数用户只能在同组内进行读写或对整个数据库只具有读的权利。
在此，特别强调对SYS和SYSTEM两个特殊账户的保密管理。
为了保护Oracle服务器的安全，应保证$ORACLE_HOME/bin目录下的所有内容的所有权为Oracle用户所有。
为了加强数据库在网络中的安全性，对于远程用户，应使用加密方式通过密码来访问数据库，加强网络上的DBA权限控制，如拒绝远程的DBA访问等。
3.系统设计
3.1.系统管理
3.1.1.基础数据设置
配置系统主要功能模块设置、服务器设置、学年学期设置等；
配置角色、权限等，自定义管理级别；
校区、机构、专业、年级、教研室等数据维护，可设置正、副职负责人（可多人），支持按照树状结构显示结构示意图。
3.1.2.业务流程管理
基于工作流引擎，实现管理流程的动态配置，提高系统的可扩展性。
通过工作流管理模块，用户可以管理已经存在的工作流，包括对工作流的增删改查，以及对工作流进行统一部署。
用户还可以进行工作流运行实例的控制，自定义工作流程、审批流程、文档资料提交流程等业务流程，允许二级学院自定本部门业务流程；
业务参与者包括学生、教师、教研室、二级学院（含其他开课部门）、教务处、学院领导等；
业务流程待办提醒功能；
业务流程业务汇总统计。
3.1.3.自定义报表
自定义报表格式、自定义报表数据项等。
3.1.4.角色权限管理
系统具有多级的灵活角色定义及授权功能。
实现依据学校各院部、各教学管理单位按照岗位职责进行角色定义及角色的级别（校级、院级），并依据岗位职责进行权限的分配，权限不仅控制功能组件，还控制到功能的操作按钮，保证用户在系统中的一切操作在授权范围内进行，当用户发生岗位调整或者岗位职责发生变化时系统可以灵活调整。
数据范围可控制到校区、院系、专业、班级、学生、供应商、校外专家等。
3.1.5.系统参数设置
通过设置各项控制参数，构建一个管理控制平台，保障系统正常运行。
3.1.6.系统日志管理
系统对用户的所有对数据库的读写操作都予以记录，系统管理员可查看到所有登录系统的用户的操作，包括登录时的IP地址、用户名、密码，操作内容描述，日期，时间等，以便对历史数据的修改痕迹查询提供线索，对恶意修改数据的用户进行跟踪，也为学校提供一些信息的分析统计。
3.1.7.历史数据管理
对历史数据按年级转入历史库，对转入历史库的重要数据具有查询和输出功能。
具体数据的转入转出灵活设置按年级专业、按年级等不同条件操作。
3.1.8.信息发布
可自定义通知公告的类别，可建立多个发送通过公告的群组，可指定每个通知公告的接收对象。
与企业微信平台对接，能用通告的形式推送各类信息，可指定接收人等。
3.2.学籍管理
学籍管理是教务教学管理系统中多个管理模块的输入端口，也是整个教务系统的基础信息模块，同时它又要求能接受来自教务管理系统以外的数据信息（如：
学工管理系统中的奖励信息，考试作弊信息，招生系统的新生基本信息，财务收费系统的学生缴费情况）。
学籍管理提供学生从入学到离校整个过程中各方面表现的详细记录，主要包括新生信息导入、学籍基本信息、报到注册、学籍预警、学籍异动、学生奖惩、交流生管理、转专业、大类分流、方向分流等。
3.2.1.新生管理
学校招生（统招、自主招生）数据导入系统，制定分班编学号规则，系统根据规则进行自动分班编学号。
3.2.2.学籍信息管理
学生学籍基本信息管理主要包括学生基本信息、学籍信息（一学期一条状态数据，满足各类教学管理的数据需要）、其他信息、联系方式、家庭成员，该模块支持根据不同角色看到的学生信息项不同，对于学生网上自主核对的信息可以做到部分（联系电话、家庭地址等）不需审核生效，部分必须通过管理岗位审核通过才生效。
3.2.2.1.修改信息设置
为维护权威数据源，学生具体信息字段存在是否在教务系统内可修改的问题。
关键字段可设定为只读，以数据源为信息变更的依据；
附加字段信息可以放开权限，由教务系统工作人员进行维护与管理。
3.2.2.2.学生校对
学生本人登录系统在本栏目中进行信息修改。
学生的信息一经确定不得由本人进行修改，如确实需要修改，在学校开放时间断内并智能对可允许修改的信息项进行调整，由学生在线上提出申请，按要求上传附件，调整后经授权老师审核通过后正式生效。
3.2.2.3.学生信息审核
按照预设审核流程对学生信息修改申请进行审核。
审核结果及时通知学生本人。
审核结果包括“通过”和“退回”。
3.2.2.4.学生照片
提供单个和批量上传功能，照片有两张，分别是入学前和毕业照片，照片操作提供按条件查询并导出功能，提供缺照片学生名单统计输出功能。
由系统管理员设置相关条件，实现缺照片学生网上上传指定规格照片，由学院用户审核后更新。
单个照片上传：
选择需要上传照片的记录，弹出上传页面，选择本地相片完成上传。
保存后对应学生照片状态将改为已上传。
批量照片上传：
将多个相片文件合并压缩为ZIP文件，系统获取该压缩包后自动解压将所获得的相片根据文件名分派到指定学生信息记录中。
照片必须由身份证号、考生号和准考证号命名。
照片导出：
维护年级、学院、专业、班级、按学院分目录、命名规则等字段信息，即可导出满足条件的学生的照片。
3.2.2.5.学生时盒数据
可通过维护源学年、源学期、目标学年、目标学期、生成类型等字段信息生成学生时盒数据，满足学生不同学期状态数据需要。
3.2.2.6.标签管理
为实现学生的个性化培养，可对某一类学生赋予特定标签，对赋予同类标签的学生实施有针对性的人才培养，标签分学生标签、生源标签、课堂标签、专业标签等，主要用于标注区分英语特长生、艺术特长生、免试生等不同学生类型，英语课堂、实验课堂、实训课堂等不同课堂以及不同类型专业等，为支持学校特殊管理需求的快速实现，支持各级管理员自定义增加、修改标签，设置标签对象。
要求通过标签的使用，用户可以在系统各模块中快速选定一类特殊的学生，进行规则化的批量操作。
3.2.2.7.订单班级管理
允许订单班（行政班）的学生可以来自不同二级学院、不同专业、不同年级、不同学制，不同专业方向，组成的订单班级与其他普通行政班级一致，可正常该班级的排课管理、选课管理、考务管理、教材管理、成绩管理等功能。
3.2.3.学生注册管理
系统设置不同年级的报到注册时间，根据系统限定时间内办理报到、注册手续，具体支持单个、批量方式。
对于有困难的学生提供绿色通道功能进行注册；
学生注册信息结果可以控制相关服务，如登录系统、选课、考试安排、查成绩、等级考试等功能；
提供报到、注册统计查询功能：
能按照全校、院系、年级或专业等不同维度，统计注册比例、报到比例、未注册原因等；
能提供未报到学生名册、报到学生名册、未注册学生名册、注册生名册、强制注册学生名册、学生注册情况统计表、学生报到情况统计表等报表等各维度的报到注册统计、报表输出。
3.2.3.1.新生注册
新生数据由教务处统一导入系统临时库中。
根据招生代码表作相应的处理并按专业分行政班、编学号。
新生注册是，由各二级学院通过迎新功能给新生注册，通过扫描学生录取通知书条形码或二维码调取报到学生信息，注册人员可以对报
升级会员 