Интерактивная информационная система сопровождения учебного процесса Военного учебного центра при РТУ МИРЭА
Данный проект посвящен внедрению интерактивного мобильного ассистента, способного упорядочить и упростить организацию учебного процесса в Военном учебном центре при РТУ МИРЭА. Одной из основных проблем, с которой сталкиваются студенты – это продолжительная адаптация к порядку организации учебного процесса в ВУЦ, связанная с невозможностью получения оперативной информации по изменениям в расписании учебных занятий (месту и порядку проведения занятий, информации по преподавателям и т.п.).
Warning
Данный проект имеет лицензию MIT
Прежде, чем начать собирать требования, необходимо выявить всех заинтересованных лиц (стейкхолдеров), которые будут пользоваться данной системой. Чем точнее будет этот список, тем полнее будут требования. В нашем проекте стейкхолдерами будут только студенты и руководящий преподавательский состав. Заинтересованные лица могут разделяться на внешних и на внутренних.
Существует множество различных техник сбора требований, которые помогут лучше понять, что хочет видеть пользователь в конечном итоге. Мы использовали такие техники сбора требований, как интервьюирование и мозговой штурм.
Интервью
Сбор требований с помощью интервью осуществлялся в несколько этапов:
- Подготовительный этап. На данном этапе осуществлялась подготовка полного списка вопросов и тем обсуждения для лучшего понимания целей создания мобильного приложения;
- Выбор участников. На данном этапе определялся список участников на интервью;
- Ход проведения интервью. На данном этапе задавались открытые вопросы для получения максимально подробного ответа, при необходимости нужно задавать уточняющие вопросы;
- Фиксация требований. На данном этапе все полученные требования фиксировались в письменном виде для дальнейшего анализа и создания спецификации;
- Анализ. После интервью проводился анализ полученных данных и выделялись основные требования;
- Обратная связь. При необходимости стейкхолдеры давали обратную связь по возможным коррективам требований.
Мозговой штурм
Благодаря данному подходу собиралось множество идей от небольшой группы студентов и преподавателей в кратчайшие сроки, стейкхолдеры на презентации разработки накидывали множество идей, связанных со способом решения существующей технологии сопровождения учебного процесса в ВУЦ. В ходе мозгового штурма каждая идея фиксировалась в особый список, из которого затем отбирались лучшие варианты. Затем лучшие варианты попадают в схему мозгового штурма для визуализации будущего проекта.
Выбор методики сбора требований помогает определить и уточнить пожелания заказчика и будущих пользователей системы. Методики помогают конкретизировать требования к системе, позволяя сконцентрироваться на отдельных аспектах проекта, что положительно может повлиять на его своевременное завершение.
В нашем проекте мы будем руководствоваться принципам каскадного метода сбора требований, которая предполагает последовательный сбор информации, ее анализ, проектирование проекта, разработку, тестирование и внедрение.
Пока не каждое учебное заведение обладает мобильной информационной системой, которая поможет повысить эффективность обучения студентов. Студентам ВУЦ приходится тратить время на поиск расписания на сайте учебного заведения, загружать сторонний файл, ориентироваться по дате в огромной таблице, осуществляя поиск своего учебного взвода. Все перечисленные действия требуют высоких затрат по времени на их выполнение, а сложная структура может ввести в заблуждение поступившего. Такое представление информации кажется проблемным для отдельных студентов. При этом в существующем расписании отсутствует информация о предстоящем предмете, а также о преподавателе и его должности.
Образец существующего расписания ВУЦ
Модель сопровождения учебного процесса ВУЦ AS IS в нотации BPMN 2.0
После того, как требования были зафиксированы во время их сбора у стейкхолдеров, необходимо провести тщательный анализ и структуризировать их.
На этапе структуризации проводится проверка требований на их полноту, согласованность, однозначность и реалистичность. Это включает в себя проверку на противоречия, недостатки и недостающие элементы.
После этого требования структурируются в специальной схеме, чтоб лучше разделить требования на функциональный и нефункциональный характер, а также разделить на три уровня:
- Уровень бизнес-требований
- Уровень пользовательских требований
- Уровень функциональных требований
Данный уровень включает в себя Бизнес-требования (функциональный характер) и бизнес-правила (нефункциональный характер). Бизнес-правила - ценный источник требований.
Они влияют на следующие типы требований к системе:
- Бизнес-требования
- Пользовательские и функциональные требования
- Атрибуты качества
| Бизнес-правило | Требование к системе |
|---|---|
| Пользователи должны иметь возможность просматривать расписание занятий на определенный день (неделю) | На главном экране (где показывается расписание занятий) пользователь должен иметь возможность переключать расписание занятий на главном экране с помощью специальных кнопок (стрелочек) или свайпом влево/вправо |
| Информация о занятиях должна быть актуальной и своевременно обновляться | Пользователь тоже проходить авторизацию в системе путем ввода только номера учебного взвода, после этого система автоматически через специальный сервер подгружает расписание занятий. Так же должно происходить обновление расписание при нажатии на специальную кнопку (зацикленная стрелочка) или свайпом вниз |
| Должна быть предусмотрена возможность оставлять отзывы после использования приложения для улучшения качества сервиса | Должна быть отдельная вкладка настроек, где должна будет быть кнопка для быстрого перехода в Telegram, где автоматически откроется чат технической поддержки |
Но при этом бизнес-требования не относятся напрямую к реализации проекта, а в первую очередь они отражают цели учебного процесса, абстрагированные от реализации системы.
Главная бизнес-цель проекта сформирована по методике SMART:
Повысить эффективность адаптации поступивших студентов с помощью новой технологии упорядочивания и упрощения организации учебного процесса в Военном учебном центре при РТУ МИРЭА, чтобы разработанная технология пользовалась постоянным спросом как минимум у 300 студентов в течение двух лет.
В конечном итоге бизнес-цель определяет какие будут бизнес-требования, а уже бизнес-требования формируют Документ бизнес-требований (BRD).
Данный уровень включает в себя пользовательские требования (функциональный характер) и атрибуты качества (нефункциональный характер). Пользовательские требования содержат:
- Цели и задачи пользователей
- Сценарии использования — способ решения задачи пользователей
- Как следствие, описание самих пользователей системы:
- пользовательские роли
- уровни доступа
Пользовательские требования описывались по следующему шаблону: Пользователь должен иметь возможность + {тезис}
1) User Story
| Роль | Цель/Действие | Ожидаемый результат |
|---|---|---|
| Студент | Пройти авторизацию в системе | Актуальная информация о том учебного взводе, номер которого был введен в поле ввода |
1) Use Case
Цель пользователя в том, что он вводит свой номер учебного взвода и свое имя (необязательно), после этого получает актуальную информацию о своем взводе и расписании занятий.
Задачи пользователя
- Ввод номера учебного взвода в поле ввода на экране авторизации.
- Ввод имени пользователя в поле ввода на экране авторизации (необязательная функция).
| Название Use Case | Авторизация |
|---|---|
| Описание Use Case | Пользователь авторизуется в системе, чтоб получить актуальную информацию по своему взводу и расписанию занятий |
| Акторы | Пользователи |
| Предусловия | Система должна быть подсоединена к сети Интернет для получения актуальной информации; Для ввода номера учебного взвода используется только числовой тип данных; Для ввода имени пользователя используется только текстовый тип данных, также имя может принимать NULL; При некорректном вводе выводится ошибка. |
1) Wireframe
1) Пользовательское требование
Пользователь должен иметь возможность авторизовываться в системе по номеру учебного взвода.
2) User Story
| Роль | Цель/Действие | Ожидаемый результат |
|---|---|---|
| Студент | Получить актуальное расписание | Актуальная расписание занятий на текущий или выбранный период времени |
2) Use Case
Цель пользователя в том, что ему необходимо как можно быстро получить актуальное расписание.
Задачи пользователя
- Задач у пользователя нет, так как после успешного прохождения авторизации пользователю автоматически на главном экране должно подгружаться расписание занятий.
Note
Если пользовательских задач нет, то диаграмма вариантов использования не требуется.
2) Wireframe
2) Пользовательское требование
Пользователь должен иметь возможность всегда получать актуальную информацию о расписании занятий.
3) User Story
| Роль | Цель/Действие | Ожидаемый результат |
|---|---|---|
| Студент | Оперативно получать нужную информацию | Удобная панель навигации |
3) Use Case
Цель пользователя в том, что он должен достигать своих целей в приложении как можно быстро с помощью специального меню.
Задачи пользователя
- Переключаться между вкладками с помощью меню быстрого доступа.
| Название Use Case | Навигация |
|---|---|
| Описание Use Case | Пользователь оперативно получает нужную ему информацию с помощью меню быстрого доступа |
| Акторы | Пользователи |
| Предусловия | - |
3) Wireframe
3) Пользовательское требование
Пользователь должен иметь возможность быстро и удобно достигать своих целей в системе.
4) User Story
| Роль | Цель/Действие | Ожидаемый результат |
|---|---|---|
| Студент | Получить связь с технической поддержкой | Переход в “два клика” в Telegram чат технической поддержкой |
4) Use Case
Цель пользователя в том, что он в случае возникновения различных багов и ошибок мог быстро решить эту проблему путем обращения напрямую к разработчикам через данную систему.
Задачи пользователя
- Перейти на вкладку настроек.
- Из настроек перейти в Telegram-канал с помощью специальной ссылки.
| Название Use Case | Техподдержка |
|---|---|
| Описание Use Case | Пользователь переходит в Telegram чат, при возникновение каких-либо ошибок или багов |
| Акторы | Пользователи |
| Предусловия | Система должна быть подсоединена к сети Интернет для обращения в техническую поддержку |
4) Wireframe
4) Пользовательское требование
Пользователь должен иметь возможность через систему связаться с технической поддержкой.
После внедрение новой технологии сопровождения учебного процесса ВУЦ, бизнес процесс изменит свой вид на более оптимизированную модель.
Модель сопровождения учебного процесса ВУЦ TO BE в нотации BPMN 2.0
Следовательно, пользовательские требования должны формировать Документ требований к продукту (PRD).
Атрибуты качества (нефункциональные требования):
Удобство использования
Главная цель разработанной системы будет являться оперативное получение информации по расписанию занятий, соответственно, к удобству использования будет относится:
- После ввода номера учебного взвода и при нажатии кнопки «Войти», пользователь должен будет сразу же попасть на «Главный» экран системы, в котором будет уже загружено расписание занятий
- Навигация по приложению (то есть переключение между вкладками) должна обеспечиваться меню быстрого доступа в нижней части экрана мобильного устройства
Производительность
- Разрабатываемая система не предрасполагает большое количество запросов в секунду, так как для загрузки актуального расписания требуется совершить один запрос в семестр (4 месяца), при условии, что оно не будет изменять в течение этого времени
- Допустимое время ответа сервера: от 500мс. до 1000 мс. (1с.)
- Ожидаемое кол-во пользователей зависит от среднего кол-ва обучающихся в Военном учебном центре – это порядка 500 студентов
- Никаких ограничений по техническим характеристикам серверов нет, минимальных мощностей серверов будет достаточно для примитивного запроса для получения расписания занятий
Защищенность
- Ни на какие роли система не разделяется, она имеет только один общий доступ для всех видов пользователей
- Работа с персональными данными не предусматривается, соответственно, создавать резервную копию или наличие правил создания точек сохранения базы данных - будет нецелесообразным. Расписание занятий будет браться из сайта военного учебного центра
Совместимость
Проектируемая система должна быть доступной практически для всех студентов на мобильном устройстве на ОС Android и IOS. Из этого выходит, что основными пользователями системы будут являться студенты. Поэтому на основе этого для комфортной работы в данной информационной системе были выдвинуты минимальные системные требования устройств:
- На ОС Android:
- Версия ОС - Android 9.0-10.0;
- Архитектура - 32-разрядная;
- Частота процессора - 1,1 ГГц;
- ОЗУ - 2 ГБ;
- Кол-во свободного места - До 50 МБ;
- Доступ к сети Интернет.
- На ОС IOS:
Функциональные требования являются результатом декомпозиции верхнеуровневых требований и описывают атомарные функции, которые должны быть реализованы в системе. Например:
- “Пользователь должен иметь возможность авторизовываться в системе по номеру учебного взвода”:
- Функция 1 - ввод в специальную область только числовое значение (для номера учебного взвода)
- Функция 2 - ввод в специальную область только строковое значение (для имени пользователя)
- Функция 3 - вывод на главный экран приложения актуальное расписание (расписание является актуальным, если у нас расписание относится именно тому учебному взводу)
- “Пользователь должен иметь возможность всегда получать актуальную информацию о расписании занятий”:
- Функция 1 – парсинг расписания из Excel-файла;
- Функция 2 – вывод на экран расписания отсортированного по номеру взвода и текущего числа (недели);
- Функция 3 – вывод ключевой информации (номер пары, время занятий, название предмета, преподаватель и номер аудитории) по каждому предмету
- Функция 4 - кнопка “Обновить” должна обновлять текущее расписание занятий без необходимости выходить из приложения и получать актуальное расписание за счет повторной авторизации в системе.
- “Пользователь должен иметь возможность быстро и удобно достигать своих целей в системе”:
- Функция 1 - система должна иметь навигационное меню в нижней части экрана
- Функция 2 - переключение должно быть только по вкладкам - “О ВУЦ”, “Расписание” и “Преподаватели”
- “Пользователь должен иметь возможность через систему связаться с технической поддержкой”:
- Функция 1 - во вкладке “Настройки” должна быть кнопка для быстрого перехода в чат с разработчиками (Telegram платформа)
Note
Расписание является актуальным, если у нас расписание:
- Относится именно к тому учебному взводу, которое было введено в момент авторизации
- Вывод на главный экран системы учебных занятий, которые относятся к текущей учебной недели (за исключением зимних и летних каникул, а также дней пересдач)
- Содержит информацию о: название текущего занятия, ФИО преподавателя по данному занятию и номер аудитории, где будет проводится это занятие
Следовательно, функциональные требования должны формировать Документ функциональной спецификации (FSD).
Целевая аудитория
Для определения целевой аудитории за основу был взят метод 5W Марка Шеррингтона и составлена удобная таблица для определения будущего пользователя.
| Вопрос из метода 5W Марка Шеррингтона | Ответ на вопрос (определения целевой аудитории) |
|---|---|
| Что предлагает исполнитель? | В данном проекте предлагается мобильное приложение для демонстрации актуального расписания |
| Кто будет пользоваться данным приложением? | В данном проекте пользователями системы предполагаются студенты, которые хотят: Всегда знать актуальное расписание занятий; Знать самую важную информацию о Военном учебном центре; Оперативно знать весь преподавательских состав; Более качественно готовиться к предстоящим занятиям. |
| Почему должны начать пользоваться приложением? Какую потребность у пользователей закрывает приложение? Какую проблему решает приложение? | Данный проект по разработки мобильного приложения способен ряд трудностей, с которыми достаточно часто сталкиваются студенты, а особенно недавно поступившие студенты. К таким трудностям относится: Долгий поиск нужно расписания занятий; Чтоб посмотреть расписание, необходимо долго ориентироваться в сложной, на первый взгляд, структуре; Вся информация есть только на сайте Военного учебного центра, для этого всего требуется доступ к сети Интернет; Сайт Военного учебного центра несовсем адаптирован под мобильную версию, что, в свою очередь, вызывает дополнительные сложности. |
| Когда пользователи решат начать пользоваться данным приложением? | В целом данная система актуальна всегда в период учебного года |
| Где можно будет начать пользоваться данной данным приложением? | Данная система адаптирована под пользователей с операционной системой |
Общий взгляд на новую систему
Причиной разработки данного мобильного приложения является решение одной из основных проблем, с которой сталкиваются студенты – это продолжительная адаптация к порядку организации учебного процесса в ВУЦ, связанная с невозможностью получения оперативной информации по изменениям в расписании учебных занятий (месту и порядку проведения занятий, информации по преподавателям и т.п.).
Исходя из этого новая технология должна решить существующие трудности у студентов и улучшить их качество подготовки к занятиям.
В качестве пример будет приведена контекстная диаграмма в нотации IDEF0, которая будет показывать систему как набор иерархических действий.
Модель просмотра расписания занятий в нотации IDEF0
Модель просмотра расписания занятий в нотации IDEF0
Модель авторизации в нотации IDEF0
Классы и характеристики пользователей
| Класс пользователей | Описание |
|---|---|
| Студент | Это студенты ВУЦ, желающие лучше готовиться к предстоящим занятиям путем просмотра расписания занятий и изучением важной информации о распорядке в ВУЦ. Всего студентов в ВУЦ около 800, из которых 300, как ожидается, будут использовать МИС ВУЦ в среднем 5 раз в неделю |
Операционная среда
Мобильное приложение с расписанием занятий Военного учебного центра должно работать на ОС Android и IOS. Минимальная версия ОС Android должна быть 9.0, а у IOS минимальная версия должна быть ХХХ.
Архитектура системы