Задача повышения качества образования, стремительное развитие информатики и, как следствие, развитие информационного общества обусловили необходимость модернизации учебного процесса на базе современных информационных технологий. Данная статья посвящена разработке модуля информационной системы управления учебным процессом вуза. Важнейшим условием обеспечения качества образовательного процесса является мониторинг учета успеваемости студентов в условиях перехода высшего профессионального образования на двухуровневую систему образования, что говорит об актуальности настоящего исследования.
Целевой средой для внедрения информационной системы управления вузом являются вузы, в которых внедрена Болонская система образования. В Рязанском государственном университете им. С.А. Есенина разработана информационная система «Электронный университет». Цель ее разработки – повышение качества образовательного процесса, оперативность в управлении вузом, организация обратной связи по цепи вуз–студент–общество–вуз на основе сопровождения и анализа качества подготовки специалиста в условиях перехода на двухуровневое образование на базе внедрения информационных технологий. На рисунке представлена структура информационной системы управления учебным процессом, которая может быть дополнена функциональными модулями или модифицирована под изменяющиеся объективные условия в сфере образования.
В первую очередь это модульная структу- ра дисциплин с делением на законченные бло- ки – модули; по ним проводятся контрольные мероприятия, а по сумме результатов выводится суммарный рейтинг студента по дисциплине, на основе которого и выставляется оценка. Рейтинговая система учета успеваемости требует от студента постоянной работы, порождает в некоторой степени здоровую конкуренцию, например, при назначении по рейтингу надбавки к стипендии.
Объектом рейтинговой подсистемы учета успеваемости студентов является рейтинг студентов, который они зарабатывают в процессе обучения за каждый законченный модуль.
Субъектом выступают персонал факультета и студенты. Этим обусловлено разделение пользователей на три группы, или роли – студент, преподаватель и деканат (администратор) с разным доступом к функционалу.
Эффективная подсистема учета рейтинга должна быть способной вести, создавать многоуровневые отчеты по статистике, быть удобной для использования, то есть иметь дружественный интерфейс.
Перечень основных групп функций включает: ввод и редактирование преподавателей, групп, дисциплин; установку связи преподаватель–группа–дисциплина; создание контрольных мероприятий; проведение контрольных мероприятий; вывод отчетов по контрольным мероприятиям и рейтингу; дополнительный функционал.
Функция ввода и редактирования преподавателей, групп, дисциплин доступна только администратору. При ее выполнении формируются и заносятся данные по каждой группе, дисциплине, преподавателю. Особенность данной функции в том, что необходимо учесть принадлежность каждого преподавателя к кафедре, создать группы дисциплин, предусмотреть хранение специальностей групп и курсов.
Установка связи преподаватель–группа–дисциплина – одна из важнейших функций подсистемы. Она также доступна только для администратора и является объединяющей для сущностей подсистемы. Именно здесь фактически создается уникальная дисциплина, характеризующая конкретную дисциплину, на основе которой организуются занесение данных и формирование отчетов.
Создание контрольных мероприятий доступно только преподавателю, при этом задаются его тип, дополнительная информация, дата проведения, минимальный и максимальный баллы за контрольное мероприятие. Существует возможность редактирования созданного мероприятия.
После создания мероприятия у преподавателя появляется возможность провести его. По результатам прохождения мероприятия формируются отчеты, в той или иной степени доступные лю- бому пользователю. Сама функция просмотра отчетов и контрольных мероприятий не влечет никаких изменений в структуре БД. Она использует языки программирования высокого уровня и SQL-запросы.
К дополнительным функциям, реализованным в рейтинговой подсистеме учета успеваемости студентов, относятся функции разграничения доступа, новостная лента и некоторые другие.
Для разработки информационной подсистемы была выбрана СУБД DB2 (Universal Database).
DB2 – это семейство программных продуктов в области управления информацией компании IBM. Помимо коммерческих продуктов семейства, IBM распространяет бесплатный дистрибутив DB2 Express-C для платформ Linux (x86, x86-64, POWER), Windows (x86, x86-64), Solaris (x86-64), Mac OS X (x86-64 beta). Бесплатная версия имеет ограничения на использование для работы СУБД не более одного двухъядерного процессора и 2 Гб оперативной памяти (общее количество процессоров и памяти в системе может быть любым, но ресурсы сверх указанных ограничений не будут использоваться СУБД). DB2 стала первой СУБД, использующей SQL.
К отличительным особенностям DB2 относятся диалект языка SQL, определяющий (за редчайшими исключениями) чисто декларативный смысл языковых конструкций, и мощный многофазовый оптимизатор, строящий по этим декларативным конструкциям эффективный план выполнения запроса. В отличие от других диалектов SQL в диалекте SQL DB2 практически отсутствуют подсказки оптимизатору, мало развит язык хранимых процедур, и, таким образом, все направлено на поддержание декларативного стиля написания запросов. Язык SQL DB2 при этом является вычислительно полным, то есть потенциально позволяет в декларативной форме определять любые вычислимые соответствия между исходными данными и результатом. Это достигается в том числе за счет использования табличных выражений, рекурсии и других развитых механизмов манипулирования данными.
Традиционно для написания хранимых процедур используются обычные языки программирования высокого уровня (Си, Java, PL/I и др.), что позволяет программисту легко оформлять один и тот же код либо как часть приложения, либо как хранимую процедуру в зависимости от целесообразности его выполнения на клиенте или на сервере. В настоящее время в DB2 реализовано процедурное расширение SQL для хранимых процедур в соответствии со стандартом ANSI SQL/PSM.
Оптимизатор DB2 широко использует статистику распределения данных в таблицах (если процесс ее сбора был выполнен администратором БД), поэтому один и тот же запрос на языке SQL может быть оттранслирован в различные планы выполнения в зависимости от статистических характеристик данных, которые он обрабатывает.
Поскольку исторически DB2 развивалась с многопользовательских систем на мейнфреймах, большое внимание в ее архитектуре уделяется безопасности и распределению ролей обслуживающих ее специалистов. В частности, в отличие от многих других СУБД в DB2 отводятся отдельные роли для администратора СУБД, ответственного за конфигурирование программных компонентов DB2 и их оптимальное выполнение в компьютерной системе, и администратора БД, ответственного за управление данными в конкретной базе.
Использование в программах статического SQL и концепции пакетов допускает, в отличие от большинства других СУБД, реализацию такой модели безопасности, когда права на выполнение определенных операций могут выдаваться прикладным программам при отсутствии таких прав у работающих с этими программами пользователей. Это гарантирует невозможность работы пользователя с БД в обход прикладной программы, если у него имеются права только на запуск программы, но не на самостоятельную манипуляцию данными.
В рамках концепции повышения уровня ин- теграции средств безопасности в компьютерной системе DB2 не имеет собственных средств аутентификации пользователей, интегрируясь со средствами операционной системы или специализированными серверами безопасности. В DB2 осуществляется только авторизация пользователей, аутентифицированных системой.
DB2 является единственной реляционной СУБД общего назначения, имеющей реализации на аппаратно-программном уровне (система IBM i; мейнфреймы IBM System z).
Современные версии DB2 обеспечивают расширенную поддержку использования данных в формате XML, в том числе операции с отдельными элементами документов XML.
Существенной особенностью DB2 является возможность обработки ошибок. Для этой цели используется структура SQLCA (Communications Area − область связи SQL), работающая только в программе DB2 и возвращающая информацию об ошибке прикладной программе после каждого выполнения SQL-выражения. Основная, но не всегда полезная диагностика ошибки содержится в поле SQLCODE (тип данных − целое число) внутри SQLCA-блока. Она может принимать следующие значения: 0 − успешное выполнение; положительное число – успешное выполнение с одним или более предупреждениями, например, +100 означает, что не найдены столбцы; отрицательное число – неудача с ошибкой. SQLERM (тип данных − строка из 71 символа) содержит текстовую строку с описанием ошибки в случае, если поле SQLCODE меньше нуля. SQLERRD (тип данных − массив, 6 целых чисел) описывает результат выполнения последнего оператора SQL: 1-й элемент − внутренняя информация; 2-й элемент − сгенерированное сервером значение поля типа SERIAL для оператора INSERT либо дополнительный код ошибки; 3-й элемент − количество обработанных записей; 4-й элемент − примерная стоимость выполнения данного оператора; 5-й элемент − смещение ошибки в текстовой записи оператора SQL; 6-й элемент − внутренняя информация.
Разработанная информационная подсистема рейтингового учета успеваемости студентов вуза позволяет осуществить мониторинг всех видов контроля знаний, умений и навыков студентов в рамках Болонской системы образования, обучающихся по модульно-рейтинговой системе. Подсистема работает с центральной БД и позволяет просматривать текущий рейтинг студента, группы по каждой дисциплине; формировать web-страницы на основе текущей и итоговой информации; автоматизировать создание технологических карт по дисциплинам; вести электронный журнал успеваемости студентов, обучающихся по модульно-рейтинговой системе; разграничивать права групп пользователей.
Литература
1. Андреев В.В. Информационная подсистема оценки рейтинга профессорско-преподавательского состава // Программные продукты и системы. 2009. № 4. С. 135–138.
2. Герова Н.В. Автоматизированная система рейтингового контроля знаний студентов вуза // Там же. С. 138–142.