Таким образом, по каждому студенту накапливается история приказов, которые когда-либо его касались - как минимум, это приказ о зачислении, переводные приказы (с семестра на семестр) и приказ об окончании обучения, но существуют также приказы об академическом отпуске, задолженностях, сроках их сдачи, поселение и выселении из общежития и т.п.
На данный момент активно ведется разработка других систем, которые использует данные, предоставляемые "Контингентом".
2.4.4. Автоматизированная информационная система «Электронный Деканат «ЭД++» РЭА им. Г. В. Плеханова
Автоматизированная информационная система «Электронный Деканат «ЭД++» [[13]] для высшего учебного заведения предназначена для автоматизации работы деканата. "ЭД++" также построена по технологии клиент-сервер.
В системы реализованы следующие функции (режимы):
· Справочники (справочник специальностей, справочник групп, справочник образовательных блоков, справочник дисциплин)
· Учебный план (создание учебного плана, редактирование учебного плана, дисциплины по выбору)
· Сессии (объявление приказа о сессии, проект приказа о сессии, продление сессии)
· Успеваемость (выписывание ведомостей, заполнение ведомости, возврат ведомости)
· Перевод студентов (начать новый учебный год, перевести непереведенных студентов)
· Студенты (матрикул студента, добавление и удаление студента, изменение информации о студенте, распределение по группам, учет студентов, обучающихся на платной основе)
· Дипломы (общие положения, создание шаблона диплома, редактирование шаблона, выписка дипломов, редактирование дипломов)
· Отчеты (контингент студентов, сводная ведомость, итоговая ведомость)
· Новости (пользовательские новости, системные новости)
2.4.5. Система «Студент», Санкт-Петербургский государственный университет
Система "Студент" [[14]] позволяет проводить сбор и хранение практически любой информации о студентах. В составе программного комплекса функционируют следующие подсистемы:
· Картотека. Учет информации о студентах.
· Приказы. Создание приказов в автоматическом режиме, на основе имеющихся шаблонов.
· Сессия и учебные планы. Включает работу с учебными планами, поддерживает механизм контроля сроков сдачи сессии и хранение истории оценок, автоматическое определение академической задолженности, а также ввод, корректировку и хранение всей информации, необходимой работникам деканата в период проведения экзаменационной сессии. Осуществляет печать всех необходимых выпускных документов, в том числе массовую.
· Выпуск. Хранение информации о выпускнике, автоматическое составление списка выпускников текущего года, включая вычисление таких данных, как итоговые оценки, средние баллы диплома, определение дипломов с отличием. Также ведется подготовка и печать всех выходных форм в соответствии с существующей нормативной базой СПбГУ.
· Статистика. Служит для создания статистических отчетов и их анализа. Содержит полный набор типовых форм, требуемых для отчетности, например: распределение студентов по специальностям и курсам на некий момент времени, изменение состояния контингента (с учетом причин) за указанный период времени, распределение студентов по льготным категориям, и многие другие. Для анализа статистических данных осуществляется переход в список студентов с различными параметрами, уточняющий полученные данные.
Все рассмотренные системы решают сходные задачи с РИВСУУП, однако интеграция некоторых их подсистем в РИВСУУП невозможна вследствие несовместимости платформ и схем данных. Кроме того, во многом РИВСУУП превосходит любую из этих систем. Также, надо сказать, системы, предоставляемые сторонними разработчиками, уже не являются такими гибкими и адаптируемыми. Например, при изменении структуры учебных планов, при переходе на другие формы контроля, либо при каких-нибудь других изменениях в учебном процессе система никак не сможет на это отреагировать, потому что разработчиком является третья сторона. РИВСУУП же разрабатывается коллективом разработчиком непосредственно в МГУ, и все изменения учебного процесса своевременно отражаются.
Также в таких системах практически невозможно учитывать некоторые особенности морского ВУЗа. Поэтому было решено разрабатывать собственную подсистему работы с сессиями.
3.1. Требования к аппаратному обеспечению
Требуется наличие сервера баз данных, на котором размещалась бы БД, а также должна обеспечиваться связь компьютера клиента с этим сервером.
3.2. Требования к программному обеспечению
На машине пользователя должен быть установлено ADO (драйвер MS SQL Server 2000). На сервере должна существовать БД, соответствующая схеме РИВСУУП.
3.3. Требования к пользователям
Пользователь АРМа должен обладать элементарными навыками работы с компьютером. Необязательно, но желательно знакомство пользователя с другими АРМами РИВСУУП, т.к. это поможет ему быстрее освоить программу.
Также пользователь должен быть сотрудником МГУ, быть зарегистрированным пользователем БД и иметь право редактировать данные в этом АРМе. Полномочия пользователей для АРМа «Сессия», как и для всех остальных АРМов РИВСУУП, определяются с помощью АРМа «Редактор прав пользователей».
Пользователи АРМа «Сессия» делятся на две группы:
Обычные пользователи – сотрудники деканатов. Они имеют право просматривать и редактировать данные только своих деканатов. Полномочия пользователей назначаются в специальном АРМе «Редактирование прав пользователей».
Администраторы – имеют право доступа ко всей информации со всех деканатов. Данная роль введена для упрощения процесса разработки и тестирования программы, конечным пользователям эта роль недоступна.
На рис. 2 показана схема подсистем и компонентов РИВСУУП и указано, какое место в этой иерархии занимает подсистема «Сессия» в ней:
Рис. 2. Компоненты РИВСУУП
На рис. 3 выделены принципиальные компоненты системы и их связи.
Рис. 3. Компоненты системы
Назначение компонентов описано в следующей таблице:
Компонент | Описание |
Core | Ядро РИВСУУП [[3]], а также глобальные переменные, используемые в разных модулях |
Forms | Формы АРМа |
Export | Модули, отвечающие за работу экспорта документов в Word и Excel, а также XML-шаблоны |
ClassesTrees | Модули, реализующие бизнес-логику приложения, отвечающие за загрузку, изменение и удаление данных с использованием MObject |
UI | Модули, отвечающие за отображение данных на форме с помощью MGrid |
Tests | Модули, используемые для тестирования клиента |
Следует отметить, что все функциональные части системы завязаны на ядре РИВСУУП. Бизнес-логика приложения вынесена в самостоятельные модули, отдельно от пользовательского интерфейса, что позволяет разрабатывать разнообразные тесты на загрузку, сохранение и удаление данных. Тесты на пользовательский интерфейс не пишутся, т.к. критичной надобности в них нет.
5.1. Сущности системы
5.1.1. Семестр рабочего плана (WorkTerm)
В сущности «Семестр рабочего плана» имеет смысл рассматривать следующие атрибуты
Название поля | Тип | Ограничения на допустимые значения |
Семестр | ЧИСЛО | [0,11] |
Рабочий план | ЧИСЛО | NOT NULL |
5.1.2. Рабочий план (WorkPlan)
Сущность «Рабочий план», по аналогии с реальной жизнью, имеет следующие атрибуты:
Название поля | Тип | Ограничения на допустимые значения |
Год | ЧИСЛО | NOT NULL |
Факультет | ЧИСЛО | NOT NULL |
Данная сущность реализована в БД в виде таблицы
Сущность «Сессия» характеризуется следующими атрибутами:
Название поля | Тип | Ограничения на допустимые значения |
Семестр рабочего плана | ЧИСЛО | NOT NULL |
Дата начала | DATETIME | NOT NULL |
Продолжительность | ЧИСЛО | NOT NULL |
Факультет | ЧИСЛО | NOT NULL |
Специальность | ЧИСЛО | NOT NULL |
Данная сущность реализована в виде представления из уже имеющихся сущностей БД.
5.1.4. Учебное поручение (TeacherPart)
Сущность «Учебное поручение» характеризуется следующими атрибутами:
Название поля | Тип | Ограничения на допустимые значения |
Группа для занятий | ЧИСЛО | NULL |
Дисциплина | ЧИСЛО | NULL |
Преподаватель | СТРОКА | NULL |
Год | ЧИСЛО | NOT NULL |
Семестр | ЧИСЛО | 1 – осенний 2 - весенний |
Данная сущность реализована в виде представления из уже имеющихся сущностей БД.
Сущность «Группа» характеризуется следующими атрибутами: