Architectural design of the systemfor university innovation management and educational process supporting..pdf В настоящее время российская система высшего образования переживает ко-ренные изменения в организационной структуре, методах оценки знаний и мето-дологиях обучения [1]. Данные изменения обусловлены глобализацией образова-ния и требованиями современного бизнеса и производства. В последние годыгармонизация национальной образовательной системы, по крайней мере, с обра-зовательными стандартами европейского сообщества очень актуальна [1, 2]. Заме-тим, что процесс модернизации образовательных систем в рамках Болонского иКопенгагенского процессов стал выходить за рамки европейского сообщества, ох-ватывая все большее количество стран различных регионов мира [3].Таким образом, гармонизация образовательных стандартов выдвигает передвсеми ведущими мировыми державами такие цели [1] в области реформациивысшего профессионального образования, как создание четких и единых квали-фикаций, переход на двухуровневую систему подготовки, введение системы кре-дитов, обеспечение академической мобильности студентов и преподавателей, ме-ждународное сотрудничество в обеспечении качества высшего образования, обра-зование в течение всей жизни (LLL - Lifelong learning) и др. Немаловажным, го-воря языком бизнеса, является ориентация на потребителя, т.е. в нашем случае ус-тановка студента в центр образовательного процесса.На сегодняшний день множество российских высших учебных заведений на-ходятся в процессе перехода к вышеназванным принципам построения процессаобучения и организации работы вуза, но они сталкиваются с множеством про-блем. В том числе, c одной из самых трудоемких - полностью управляемый сту-дентом план обучения, который требует тесного взаимодействия студентов, пре-подавателей курсов, составителей расписания, деканата, учебного управления идругих структур учебного заведения. Очевидно, что необходимо внедрение ин-формационной системы, позволяющей управлять процессом обучения и контро-лировать его на всех этапах.При проектировании данной информационной системы был сделан упор навведении принципиально нового системного подхода в организации образова-тельного процесса и сопутствующих ему управляющих процессов. Особенностьюданного подхода является акцентирование внимания на индивидуализацию обра-зовательных траекторий студентов, поддержку современных образовательныхконцепций (таких, как CDIO и PBL) [4] и обеспечение предельно дружественныхв использовании компьютерных технологий для выполнения всех видов органи-зационной деятельности. Кроме того, отдельное внимание при планировании бы-ло уделено социальным элементам системы.1. Возможности системыПрежде всего, проектируемая система является хранилищем данных обо всехаспектах учебной и организационной деятельности в вузе. После проведения ана-лиза работы типового университета были выделены следующие основные сущно-сти: учетные записи студентов, преподавателей и других сотрудников, аудитор-ный фонд, набор дисциплин и привязанных к ним материалов, учебные планы(как базовые, так и индивидуальные), структура подразделений, условия состав-ления расписания, индивидуальные расписания и некоторые другие вплоть доданных мониторинга текущей успеваемости.Очевидно, система должна предоставлять отдельный набор операций в зави-симости от роли вошедшего пользователя. Поэтому была имплементированаслужба ролей с разграничением доступа к функциям системы. Данная служба по-зволяет пользователю иметь несколько ролей, что необходимо для внедрения вреальном учебном заведении, так как зачастую один и тот же сотрудник исполня-ет несколько обязанностей из различных ролей.Каждая роль имеет свой фронт-энд для удобного доступа ко всем разрешен-ным функциям через веб-интерфейс. На первом этапе развития системы былопринято решение сделать четыре типа фронт-энда: для студента, для преподава-теля, для администратора учебного заведения или его подразделения и для сво-бодного просмотра (гостя). В дальнейшем планируется добавить различныефронт-энды для других подразделений и сотрудников, например для ректора, ра-ботника деканата, заведующего корпусом и т.д.Фронт-энд студента привязан к аккаунту студента, который создается и запол-няется на этапе его поступления в учебное заведение (или при внедрении систе-мы, в случае, если студент уже находится на обучении), после чего студенту вы-даются данные для доступа. Студенту доступны следующие основные функции:редактирование и просмотр личных данных, запись на курсы, отслеживание соот-ветствия индивидуального учебного плана обязательной образовательной про-грамме и подсчет кредитов, просмотр индивидуального расписания, просмотр ма-териалов по выбранным курсам, оценка курсов и преподавателей, просмотр теку-щей успеваемости и заданий, связь с преподавателем.Фронт-энд преподавателя также привязан к аккаунту преподавателя, которыйсоздается или при вступлении в должность, или при внедрении системы для ужеработающих преподавателей. Было принято решение включить в систему воз-можность преподавателю заявлять пожелания и требования к составлению распи-сания и записи на его курсы.Получив доступ к аккаунту, преподаватель может добавить в систему своикурсы (или отметить себя преподавателем уже существующего в системе курса),добавить описание, рабочую программу, список занятий, учебно-методическиематериалы и др. Затем он должен определить ограничения для записи на курс. Та-кими ограничениями могут быть: максимальное количество слушателей, необхо-димый набор уже пройденных студентом предметов, институт, к которому дол-жен относиться слушатель, и т.п. Кроме того, преподаватель может предъявитьтребования к аудиториям, в которых будут проходить занятия: наличие экрана спроектором, аудиосистемы, компьютеров для каждого студента, специального ла-бораторного оборудования, размещение аудитории в конкретном корпусе (корпу-сах) и т.п. Преподавателю доступны следующие основные функции: редактирова-ние и просмотр личных данных, создание курсов и открытие их для записи сту-дентов, просмотр личного расписания, просмотр списка студентов на курсах, пуб-ликация материалов по своим курсам, публикация заданий для самостоятельноговыполнения студентами, ведение текущего контроля успеваемости и посещениязанятий, связь со студентами (как массовая рассылка, так и индивидуальная).Администраторы подразделений авторизуются в системе под одноименнымфронт-эндом. Основная цель этих пользователей - ввод данных об аудиториях,преподавателях, студентах и т.д. На более поздних этапах разработки данной сис-темы будут добавлены специальные роли для данных задач, такие, как отдел кад-ров или приемная комиссия. Они примут на себя обязанности по управлениювсеми статическими данными (корпуса, аудитории, персонала и т.д.), возлагаемыена этапе внедрения системы на администраторов подразделений.Также можно выделить отдельно роль и соответствующий фронт-энд техниче-ского администратора системы. В нем реализуется различный функционал поконтролю работоспособности всех уровней системы, её обслуживанию: проверкабазы данных на ошибки, редактирование прав доступа, контроль различных тех-нических характеристик (нагрузка системы, сообщения об ошибках) и т.д. Крометого, технический администратор осуществляет запуск различных ресурсоемкихпроцедур, таких, как составление общего расписания или подсчета статистики.Общий фронт-энд предназначен только для просмотра общедоступной инфор-мации. Одним из сценариев его применения является предоставление информа-ции о студенте работодателю. Данный функционал присутствует во многих сис-темах профессиональной сертификации, например в сертификационном центреMicrosoft. Работодатель может по коду, предоставленному выпускником этогоучебного заведения, получить информацию о пройденных курсах, их содержаниии успеваемости студента.Помимо доступа к функциям разрабатываемой информационной системы по-средством веб-браузера планируется имплементировать Web API (англ. WebApplication Programming Interface - сетевой интерфейс программирования прило-жений) для решения проблемы доступа к данным и функциям системы с исполь-зованием других программ [5]. Данный Web API впоследствии будет использо-ваться при реализации приложений для мобильных устройств и нативных прило-жений для различных операционных систем. Такой дополнительный метод взаи-модействия с системой, при наличии документации для API в свободном доступе,позволит разработчикам сторонних приложений расширять систему, создаватьразличные виджеты и т.д.Важной функцией рассматриваемой информационной системы является непо-средственно генерация учебного расписания, удовлетворяющего всему множествузаданных ранее условий. Эта задача является наиболее нетривиальной и ресурсо-емкой в рамках разрабатываемой системы [6, 7], так как является NP-полной и всравнении с распространенными системами генерации расписаний, работающимис небольшим набором групп (классов) и, в большинстве случаев, не берущими врасчет никаких дополнительных условий - данная информационная система ра-ботает с большѝм количеством индивидуальных планов студентов и учитываетразличные условия, предъявленные преподавателями при объявлении курсов.По причине высокой ресурсоемкости было принято решение выделить в сете-вой архитектуре системы отдельный вычислительный кластер для задач генера-ции расписания. Данное решение принято для разгрузки центрального серверасистемы, так как он отвечает за взаимодействие с пользователями и может суще-ственно снизить время ответа при генерации расписания на том же сервере. Гене-рация расписания является полностью автономной задачей и не требует вмеша-тельств в процессе выполнения. Таким образом, эта задача является идеальнойдля выполнения одним из сервисов облачных вычислений [8]. В настоящий мо-мент выбор в пользу сервисов облачных вычислений оправдан как экономически,так и удобством внедрения и обслуживания [9]. Отсутствие необходимости за-купки серверного оборудования, аренды помещения, обеспечения сохранностиданных и т.д. делает облачные сервисы наилучшим инструментом для выполне-ния удаленных вычислений.В общем случае генерация расписания происходит несколько раз в учебныйгод. Генерация инициируется администратором системы после проверки наличиявсех необходимых компонентов: индивидуальных учебных планов, дисциплин,различных условий генерации и описания аудиторного фонда. В случае, если сту-дент не предоставил индивидуальный учебный план, применяется базовый пландля его специальности.Хранилище данных накапливает данные по дисциплинам, индивидуальнымучебным планам и расписаниям. После окончания учебного года, а порой и семе-стра, данная информация становится неактуальной, но не может быть удалена, таккак может понадобиться для статистических или других целей. В данный моментв большинстве высших учебных заведениях такая информация наполняет бумаж-ные архивы в худшем случае и неструктурированные электронные хранилища - влучшем. Оставлять устаревшие данные в основной базе данных системы тоже яв-ляется не лучшим решением, так как при малой полезности эти данные замедляютскорость запросов с каждым годом все больше и больше. По этой причине былопринято решение выделить в сетевой архитектуре системы отдельное хранилищеданных, которое не должно обеспечивать оперативный доступ к данным. Такимобразом, будет снижена нагрузка на основную БД и произведена кластеризацияданных по признаку их текущей полезности [10].2. Сетевая архитектура системыБазируясь на заявленном ранее функционале системы, была разработана сле-дующая сетевая архитектура информационной системы (рис. 1).Рис. 1. Схема сетевой архитектуры системы информационной поддержкивысшего учебного заведенияОсновой архитектуры являются облачные веб-приложения и хранилище дан-ных. Основное веб-приложение выполняет важнейшую функцию распределенияправ, предоставления и обработки данных. Хранилище данных не имеет средствразграничения доступа, поэтому вся работа с ним происходит только через веб-приложение. На схеме база данных обозначена как сетевая единица, но при необ-ходимости может быть масштабирована путем внедрения системы репликациибез модификации других частей системы.На левой половине схемы изображены возможные варианты клиентского дос-тупа к системе: мобильные и обычные веб-клиенты (доступ посредством браузерак соответствующей версии веб-сайта), нативные программы для мобильных уст-ройств и различных операционных систем (доступ посредством Web API). Все ва-рианты доступа реализуются через единые механизмы основногосистемы в учебном заведении). Дальнейшая работа по сопровождению делегиру-ется службе информатизации вуза. Следующим этапом является внесение в хра-нилище данных - аудиторий, студентов, преподавателей, и т.д. На этом, благода-ря использованию системы как облачного сервиса внедрение непосредственнопрограммного комплекса заканчивается.Затем происходит публикация дисциплин, их описаний, материалов, требова-ний преподавателями. После этого студенты выбирают дисциплины для изученияиз списков доступных и составляют индивидуальный учебный план на ближай-ший семестр. Каждый учебный план проверяется на соответствие всем нормам итребованиям как учебного заведения, так и Федеральным государственным обра-зовательным стандартам.С использованием собранных данных составляется индивидуальное расписа-ние для каждого студента и преподавателя, удовлетворяющее всем поставленнымстрогим требованиям и максимально подходящее под все нестрогие. Алгоритми-чески модуль генерации расписания основан на комплексном использовании эво-люционных вычислений и метода штрафов. Данная комбинация позволяет вклю-чать дополнительные условия в процесс генерации и уменьшить время генерациирасписания по сравнению с использованием этих методов отдельно или примене-ния некоторых других методик [13]. Процедура составления расписания можетпроводиться несколько раз с параллельным изменением настроек или требованийк расписанию, пока не будет получен оптимальный результат. В качестве объек-тивного критерия оптимальности принимается минимальное отклонение от функ-ции штрафов, задаваемой массивом требований к расписанию с различными зна-чениями приоритета. Кроме того, возможна (субъективная) ручная оценка от-дельных срезов расписания и последующая корректировка.ЗаключениеСледует отметить, что подобные системы существуют, но в основном внедре-ны за рубежом, например TechAct University Management System или AccelUMS.Использование этих систем в российских учебных учреждениях невозможно, таккак они не учитывают особенностей переходного состояния нашей системы обра-зования и имеют жесткую привязку к зарубежным стандартам делопроизводства иорганизации образовательного процесса.Представленная в данной статье информационная система позиционируетсядля последующего внедрения в крупные высшие учебные заведения России, в ча-стности в национальные исследовательские университеты.

Скачать электронную версию публикации