Дипломная работа: Разработка информационно-аналитической системы приемной кампании. Модуль учета профориентационных мероприятий

Таким образом, были проанализированы четыре системы учета профориентационных мероприятий, рассмотрены их возможности. Ни одна система не позволяет составлять отчеты о мероприятиях за определенный период, хотя бы поэтому они уже не подходят для НИУ ВШЭ - Пермь в качестве информационно-аналитической системы приемной кампании, следовательно необходима разработка такой системы.

1.3 Анализ предыдущей работы

В рамках курсовой работы третьего курса была разработана система учета профориентационных мероприятий. Она не предоставляет возможность анализировать эффективность мероприятий и составлять отчеты о мероприятиях за определенный период. Также она имеет ряд недостатков: не был реализован пользовательский интерфейс для участников мероприятий; интерфейс для работников ВУЗа слишком сложен, неудобен, ограничена функциональность при добавлении мероприятий и участников.

Описанные выше недостатки подтверждают необходимость разработки новой системы для учета профориентационных мероприятий НИУ ВШЭ - Пермь

1.4 Требования к модулю учета профориентационных мероприятий информационно-аналитической системы приемной кампании

На данном этапе необходимо формализовать требования к системе.

В системе должны быть реализованы следующие возможности (рис. А.3-А.5):

1. Создание мероприятий.

2. Автоматизация анализа эффективности мероприятий.

3. Упрощенный процесс регистрации на мероприятие с помощью единой учетной записи. Вводить контактные данные и другую информацию необходимо будет только при регистрации в системе. При каждой записи на мероприятие будут использоваться данные аккаунта.

Интерфейс сотрудника ВУЗа должен позволять добавлять, изменять и удалять данные, создавать отчеты и выгружать их в формате «.xlsx».

Интерфейс участника мероприятий должен позволять просматривать информацию о мероприятиях и регистрироваться на них.

Система должна предоставлять возможность хранить следующие данные об абитуриенте:

1. ФИО.

2. Школа (или СПО/НПО) и класс (высчитывается через год предполагаемого окончания).

3. Контактные данные (телефон и email).

Основная информация о школе:

1. Адрес.

2. Тип, номер и полное наименование.

3. Вхождение в Университетский округ (да/нет).

4. Приоритетность школы для НИУ ВШЭ - Пермь (да/нет).

Информация о мероприятии должна содержать:

1. Тип мероприятия (олимпиада, курсы, работа со школами).

2. Даты проведения.

3. Адреса.

4. Организаторов (в том числе подразделения, ответственные за проведение мероприятия), преподавателей, волонтеров.

5. Расходы с указанием закупаемых товаров, предоставляемых услуг.

6. Участников (абитуриентов, учителей, родителей).

Система должна позволять выполнять анализ данных. Для этого необходимо реализовать генерацию следующих отчетов:

1. Зависимость процента зачисленных студентов, которые участвовали в мероприятии, от стоимости мероприятия.

2. Зависимость посещаемости мероприятий от времени года.

3. Зависимость поступления абитуриента от числа мероприятий, в которых он участвовал.

4. Зависимость поступления абитуриента от баллов, которые он набрал по олимпиаде.

5. Число выпускников курсов ЕГЭ и их средние баллы ЕГЭ.

Поскольку регистрация на мероприятие должна быть доступна в любое время, система должна быть реализована с использований web_технологий.

1.5 Технологии и методы

При разработке использованы следующие методы:

1. Извлечение данных - получение структурированных данных из неструктурированных документов.

2. Преобразование данных - подготовка информации к хранению в оптимальной форме для реализации запросов, необходимых для принятия решений.

3. Загрузка данных - помещение данных в хранилище, производится атомарно, путём добавления новых фактов или корректировкой существующих.

4. Анализ данных - сводные отчеты.

5. Представление результатов анализа.

Серверная часть приложения будет реализована на языке C# с использованием ASP.Net Web API, так как он достаточно прост не только для реализации, но и для развертывания на Windows-сервере.

Для реализации клиентской части был выбор между ASP.Net MVC, Angular и React. Сравнение проводилось по следующим критериям:

1. Наличие паттерна MVC.

2. Эффективная работа с памятью.

3. Наличие компонентного подхода - возможности разделения страниц на отдельные компоненты. Это значительно упрощает чтение кода, а также позволяет избежать дублирования.

4. Цельное решение - то есть технология, в которую включены основные функциональные возможности. Такие решения не требуют дополнительного анализа библиотек и их подключения.

ASP.Net MVC - фреймворк для создания веб-приложений, который реализует паттерн MVC. Для изменений состояния на клиентской стороне можно использовать JavaScript, но при любых изменениях DOM будет обновляться все дерево HTML-тегов. Фреймворк включает в себя все возможности для настройки маршрутизации, внедрения зависимостей и пр.

Angular - это JavaScript-фреймворк, основанный на TypeScript. Он поддерживает паттерн MVC, и, так же, как и ASP.Net MVC, является цельным решением. В Angular используется обычный DOM и постоянно обновляется состояние, поэтому работу с памятью нельзя назвать эффективной. Кроме прочего, фрейморк позволяет использовать компонентный подход.

React - это JavaScript-библиотека для создания пользовательских интерфейсов. Она не является цельным решением, поскольку требует настройки необходимых библиотек, принятия решений относительно архитектуры. В React используется виртуальный DOM, который позволяет обновлять требуемую часть страницы, сравнивая различия между предыдущей и текущей версией HTML, это позволяет эффективно использовать память. Так же, как и Angular, React позволяет использовать компонентный подход.

В таблице 1.2 представлен результат сравнения технологий для реализации клиентской части.

Таблица 1.2 Результат сравнения технологий для реализации клиентской части

В итоге для клиентской части был выбран Angular и TypeScript. Стоит отметить, что TypeScript в отличие от JavaScript позволяет использовать объектно-ориентированный подход и более строгую типизацию.

1.6 Диаграмма прецедентов модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании

Требования к системе были формализованы с помощью диаграмм вариантов использования системы с расширенным описанием всех прецедентов. С системой могут взаимодействовать следующие акторы: абитуриент, сотрудник ВУЗа и администратор (рис. А.6). Стоит отметить, что администратор также является сотрудником ВУЗа.

Ниже представлено расширенное описание прецедентов.

Название: «Работа с мероприятиями».

Акторы: сотрудник ВУЗа.

Краткое описание: актор выбирает в меню пункт «Мероприятия». Выполняет работу (добавление или редактирование) над мероприятиями. Список мероприятий обновляется.

Триггер: актор вошел в систему.

Основной поток (табл. 1.3):

Таблица 1.3 Основной поток прецедента «Работа с мероприятиями»

Название: «Добавление мероприятий».

Акторы: сотрудник ВУЗа.

Краткое описание: актор нажимает на кнопку «Добавить», заполняет необходимую информацию, нажимает на кнопку «Сохранить».

Триггер: актор выбрал в меню пункт «Мероприятия».

Основной поток (табл. 1.4):

Таблица 1.4 Основной поток прецедента «Добавление мероприятий»

Альтернативные потоки:

E1: Появление предупреждений у незаполненных или неверно заполненных полей при проверке данных перед сохранением, если какие-либо данные введены некорректно или отсутствуют.

Подпотоки:

S1: Актор нажимает на кнопку «Отменить». Переход к пункту 7. Прецедент продолжается.

Название: «Импорт мероприятий из MS Excel».

Акторы: сотрудник ВУЗа.

Краткое описание: актор нажимает на кнопку «Импорт», выбирает файл MS Excel, проверяет полученные данные, нажимает на кнопку «Сохранить».

Триггер: актор выбрал в меню пункт «Мероприятия».

Основной поток (табл. 1.5):

Таблица 1.5 Основной поток прецедента «Импорт мероприятий из MS Excel»

Альтернативные потоки:

E1: Появление предупреждения о неверном формате данных при загрузке документа, если какие-либо данные некорректны или отсутствуют.

Подпотоки:

S1: Актор нажимает на кнопку «Отменить». Переход к пункту 8. Прецедент продолжается.

Название: «Редактирование мероприятий».

Акторы: сотрудник ВУЗа.

Краткое описание: актор открывает мероприятие, изменяет необходимую информацию и сохраняет мероприятие.

Триггер: актор выбрал в меню пункт «Мероприятия».

Основной поток (табл. 1.6):

Таблица 1.6 Основной поток прецедента «Редактирование мероприятий»

Альтернативные потоки:

E1: Появление предупреждений у незаполненных или неверно заполненных полей при проверке данных перед сохранением, если какие-либо данные введены некорректно или отсутствуют.

Подпотоки:

S1: Актор нажимает на кнопку «Отменить». Переход к пункту 7. Прецедент продолжается.

Название: «Удаление мероприятий».

Акторы: сотрудник ВУЗа.

Краткое описание: актор выбирает мероприятие и удаляет его.

Триггер: актор выбрал в меню пункт «Мероприятия».

Основной поток (табл. 1.7):

Таблица 1.7 Основной поток прецедента «Удаление мероприятий»

Название: «Генерация отчетов».

Акторы: сотрудник ВУЗа.

Краткое описание: актор выбирает в меню пункт «Отчеты» и выбирает вид отчета.

Триггер: актор вошел в систему.