511 lines
40 KiB
Markdown
511 lines
40 KiB
Markdown
# Идеи развития проекта Magistr
|
||
|
||
Документ содержит продуктовые предложения для дальнейшего развития системы управления
|
||
университетским расписанием. Это не утверждённые требования и не техническая спецификация:
|
||
каждое направление перед реализацией требует отдельного согласования границ, ролей,
|
||
контрактов API и модели данных.
|
||
|
||
## Текущее состояние проекта
|
||
|
||
Основное ядро системы уже реализовано и не требует повторного создания в новых модулях:
|
||
|
||
- динамическое расписание строится из правил, календарных учебных графиков и временных
|
||
слотов, а не хранится как набор отдельных занятий на каждую дату;
|
||
- правила поддерживают лекции, практики, лабораторные работы, потоки, подгруппы,
|
||
чётность недель и лимиты академических часов;
|
||
- при сохранении правил проверяются конфликты преподавателей, аудиторий, групп и подгрупп;
|
||
- учебный отдел может отменять, переносить и заменять отдельные занятия через точечные
|
||
изменения расписания;
|
||
- доступны поиск расписаний, проверка конфликтов, отчёты по нагрузке и поиск свободных
|
||
аудиторий;
|
||
- существуют отдельные кабинеты администратора, учебного отдела, кафедры, преподавателя
|
||
и студента;
|
||
- данные университетов изолированы мультитенантной архитектурой.
|
||
|
||
Подробное описание текущих возможностей приведено в
|
||
[бизнес-логике](BUSINESS_LOGIC.md), [REST API](API.md),
|
||
[документации frontend](FRONTEND.md) и
|
||
[концепции динамического расписания](SCHEDULE_PROPOSAL.md).
|
||
|
||
Новые функции ниже должны расширять это ядро и по возможности повторно использовать
|
||
`ScheduleGeneratorService`, `ScheduleQueryService`, проверки конфликтов, механизм
|
||
`schedule_overrides` и существующую ролевую модель.
|
||
|
||
## Сравнение направлений
|
||
|
||
Оценки являются относительными:
|
||
|
||
- **S** — локальное улучшение без нового крупного бизнес-процесса;
|
||
- **M** — новая модель, API и пользовательский экран;
|
||
- **L** — сквозной модуль, сложный алгоритм или изменение жизненного цикла расписания.
|
||
|
||
| Направление | Польза | Сложность | Демонстрационный эффект | Повторное использование текущего ядра |
|
||
|-------------|:------:|:---------:|:-----------------------:|:-------------------------------------:|
|
||
| Отсутствия и мастер замены | 5/5 | M–L | 5/5 | Высокое |
|
||
| Версии и публикация расписания | 5/5 | M–L | 5/5 | Высокое |
|
||
| Пожелания и заявки преподавателей | 4/5 | M | 4/5 | Высокое |
|
||
| Центр уведомлений | 5/5 | M | 4/5 | Среднее |
|
||
| Привязка студента к группе | 4/5 | M | 3/5 | Высокое |
|
||
| Подписка через ICS | 4/5 | S–M | 4/5 | Высокое |
|
||
| Импорт графика из Excel | 4/5 | M | 4/5 | Высокое |
|
||
| Анализ качества и автооптимизатор | 5/5 | L | 5/5 | Высокое |
|
||
| Расписание экзаменационной сессии | 5/5 | L | 5/5 | Среднее |
|
||
|
||
## 1. Отсутствия преподавателей и мастер замены
|
||
|
||
**Статус: реализовано в MVP.** Реестр, согласование преподавательских заявок, поиск
|
||
затронутых занятий, проверенные варианты, групповое применение `schedule_overrides` и журнал
|
||
решений доступны в системе.
|
||
|
||
### Проблема и пользователи
|
||
|
||
Болезнь, командировка или другое временное отсутствие преподавателя затрагивает сразу
|
||
несколько занятий. Сейчас учебному отделу нужно самостоятельно найти эти занятия, проверить
|
||
доступность ресурсов и создать каждое точечное изменение. Функция нужна учебному отделу,
|
||
кафедрам и преподавателям.
|
||
|
||
Регистрация отсутствий и мастер разрешения инцидентов реализуют правила из
|
||
[BUSINESS_LOGIC.md](BUSINESS_LOGIC.md). Существующая Red Zone уже выявляет конфликты сформированного расписания;
|
||
новизна этого направления заключается в реестре причин, массовом поиске затронутых занятий
|
||
и управляемом подборе решений.
|
||
|
||
### Пользовательский сценарий
|
||
|
||
1. Ответственный сотрудник указывает преподавателя, период отсутствия и причину.
|
||
2. Система строит список всех затронутых занятий в этом периоде.
|
||
3. Для каждого занятия показываются возможные решения:
|
||
- назначить свободного преподавателя, который может вести дисциплину и тип занятия;
|
||
- перенести занятие на ближайшее допустимое время;
|
||
- подобрать другую свободную аудиторию;
|
||
- отменить занятие, если перенос или замена невозможны.
|
||
4. Пользователь проверяет предложения и подтверждает только выбранные действия.
|
||
5. Система создаёт обычные `schedule_overrides`, поэтому итоговое расписание продолжает
|
||
формироваться единым существующим механизмом.
|
||
|
||
### Минимальная версия
|
||
|
||
- реестр отсутствий с преподавателем, периодом, причиной и статусом;
|
||
- поиск затронутых занятий через текущий генератор расписания;
|
||
- подбор свободных квалифицированных преподавателей;
|
||
- проверка времени, аудитории, групп и подгрупп существующим механизмом конфликтов;
|
||
- групповое подтверждение предложений с созданием переносов, замен или отмен;
|
||
- журнал принятых и отклонённых решений.
|
||
- делегирование регистрации отсутствия самому преподавателю с подтверждением кафедры;
|
||
|
||
### Связь с текущей системой
|
||
|
||
Модуль может использовать привязки «преподаватель ↔ дисциплина», поддерживаемые типы
|
||
занятий, `ScheduleQueryService`, отчёты нагрузки, поиск свободных аудиторий и
|
||
`ScheduleOverrideService`. Временное отсутствие не должно переписывать базовые правила
|
||
семестра: изменения остаются точечными и обратимыми.
|
||
|
||
### Дальнейшее развитие
|
||
|
||
- автоматическая рассылка уведомлений затронутым группам и преподавателям;
|
||
- пакетная обработка нескольких одновременных отсутствий;
|
||
- ранжирование вариантов по числу переносов, окнам и дополнительной нагрузке;
|
||
- статистика причин и среднего времени разрешения инцидентов.
|
||
|
||
**Ожидаемый результат:** сокращение ручной работы и времени реакции на изменения.
|
||
**Сложность:** M–L. **Демонстрационный эффект:** очень высокий, поскольку сценарий
|
||
показывает работу генератора, проверок и точечных изменений как единой системы.
|
||
|
||
## 2. Черновики, версии, публикация и аудит расписания
|
||
|
||
### Проблема и пользователи
|
||
|
||
Изменение активного правила сейчас сразу влияет на следующий запрос расписания. При большой
|
||
переработке семестра это создаёт риск показать студентам и преподавателям промежуточное
|
||
состояние. Учебному отделу нужен безопасный цикл «подготовить — проверить — опубликовать».
|
||
|
||
В таблице `schedule_rules` уже предусмотрены поля `version_group_id`, `change_reason`,
|
||
`created_by` и `created_at`, которые можно использовать как основу, но полноценный жизненный
|
||
цикл версий пока не реализован.
|
||
|
||
### Пользовательский сценарий
|
||
|
||
1. Пользователь создаёт черновик расписания для выбранного семестра.
|
||
2. Все изменения правил применяются только к черновику и не видны обычным пользователям.
|
||
3. Перед публикацией система проверяет конфликты и показывает сравнение с текущей версией:
|
||
добавленные, удалённые и изменённые занятия.
|
||
4. Ответственный сотрудник указывает причину и публикует версию одной операцией.
|
||
5. Студенты и преподаватели начинают видеть только полностью опубликованный вариант.
|
||
6. При необходимости администратор может восстановить предыдущую опубликованную версию.
|
||
|
||
### Минимальная версия
|
||
|
||
- статусы версии: черновик, опубликована, архивирована;
|
||
- одна активная опубликованная версия на семестр;
|
||
- автор, время создания, причина изменения и история публикаций;
|
||
- проверка всего черновика перед публикацией;
|
||
- понятный diff на уровне правил и сформированных занятий;
|
||
- атомарная публикация без промежуточного состояния;
|
||
- возврат к предыдущей опубликованной версии.
|
||
|
||
### Связь с текущей системой
|
||
|
||
Текущая динамическая генерация сохраняется, но получает явный контекст версии. Конструктор
|
||
правил работает как с черновиком, так и с опубликованной версией, а кабинеты просмотра — только с опубликованной версией. Точечные изменения можно вести отдельным аудитом либо включать в пакет публикации в зависимости от
|
||
будущих продуктовых требований.
|
||
|
||
### Дальнейшее развитие
|
||
|
||
- согласование черновика несколькими ролями;
|
||
- комментарии и замечания к версии;
|
||
- публикация по кафедрам или учебным потокам;
|
||
- запланированная публикация в указанное время;
|
||
- цифровое подтверждение и неизменяемый журнал действий.
|
||
|
||
**Ожидаемый результат:** предсказуемое расписание для конечных пользователей и безопасная
|
||
работа учебного отдела. **Сложность:** M–L. **Демонстрационный эффект:** высокий за счёт
|
||
наглядного сравнения и управляемой публикации.
|
||
|
||
## 3. Пожелания преподавателей и заявки на перенос
|
||
|
||
### Проблема и пользователи
|
||
|
||
Кабинет преподавателя сейчас предназначен только для просмотра недельного расписания.
|
||
Пожелания о времени и запросы на изменение обычно передаются вне системы, после чего
|
||
учебному отделу приходится вручную переносить данные и проверять их актуальность.
|
||
|
||
### Пользовательский сценарий
|
||
|
||
1. Преподаватель отмечает предпочтительные и нежелательные временные интервалы, а также
|
||
даты полной недоступности.
|
||
2. Кафедра или учебный отдел проверяет и утверждает ограничения на семестр.
|
||
3. Утверждённые данные подсвечиваются в конструкторе правил и учитываются мастером замены.
|
||
4. Для уже опубликованного занятия преподаватель может отправить отдельную заявку на
|
||
перенос, замену аудитории или отмену.
|
||
5. Учебный отдел получает заявку вместе с результатом предварительной проверки конфликтов
|
||
и принимает либо отклоняет её с комментарием.
|
||
|
||
### Минимальная версия
|
||
|
||
- календарь доступности преподавателя на семестр;
|
||
- разделение строгой недоступности и мягких пожеланий;
|
||
- заявка, статус, комментарий и история решения;
|
||
- предварительный поиск допустимых слотов для выбранного занятия;
|
||
- применение одобренной заявки через существующий механизм overrides;
|
||
- пожелания «пары подряд» или «без окон»;
|
||
|
||
### Связь с текущей системой
|
||
|
||
Используются кабинет преподавателя, данные семестров и сеток времени, привязки
|
||
преподавателей к дисциплинам, проверка конфликтов и `ScheduleOverrideService`. Пожелания
|
||
могут стать входными данными для будущего оптимизатора, но не должны автоматически менять
|
||
опубликованное расписание.
|
||
|
||
### Дальнейшее развитие
|
||
|
||
- уведомление преподавателя о результате.
|
||
- ограничения на максимальное число пар в день;
|
||
- предпочтения по корпусам и аудиториям;
|
||
- массовое копирование предпочтений из прошлого семестра;
|
||
- автоматическое ранжирование заявок по срочности и влиянию.
|
||
|
||
**Ожидаемый результат:** формализованная коммуникация между преподавателем, кафедрой и
|
||
учебным отделом. **Сложность:** M. **Демонстрационный эффект:** высокий.
|
||
|
||
## 4. (не делаем) Центр уведомлений
|
||
|
||
### Проблема и пользователи
|
||
|
||
Даже корректно внесённое изменение бесполезно, если преподаватель или студенты узнают о нём
|
||
слишком поздно. Системе нужен единый способ сообщать об отменах, переносах, заменах и
|
||
публикации нового расписания.
|
||
|
||
### Пользовательский сценарий
|
||
|
||
1. После подтверждённого изменения система определяет затронутых пользователей.
|
||
2. В центре уведомлений появляется сообщение с понятным сравнением «было / стало».
|
||
3. Пользователь открывает сообщение, переходит к нужной неделе и отмечает его прочитанным.
|
||
4. В настройках можно включить или отключить дополнительные каналы для разных типов
|
||
событий.
|
||
|
||
### Минимальная версия
|
||
|
||
- внутренний центр уведомлений;
|
||
- события: публикация версии, перенос, отмена, замена преподавателя или аудитории;
|
||
- адресация преподавателю и связанным с группой студентам;
|
||
- статусы «новое / прочитано»;
|
||
- ссылка на изменённое занятие и данные до/после;
|
||
- надёжная очередь формирования уведомлений после успешной транзакции изменения.
|
||
|
||
Внутренний центр следует реализовать первым. Почта, Web Push и Telegram требуют внешней
|
||
конфигурации, управления согласиями и отдельной политики повторных отправок.
|
||
|
||
### Связь с текущей системой
|
||
|
||
Источниками событий становятся `schedule_overrides` и публикация версии расписания.
|
||
Персональные студенческие уведомления зависят от реализации связи пользователя с группой и
|
||
подгруппой. Для технических метрик доставки можно использовать существующую систему
|
||
логирования и OpenTelemetry.
|
||
|
||
### Дальнейшее развитие
|
||
|
||
- Web Push для браузеров и мобильных устройств;
|
||
- почтовые и Telegram-уведомления;
|
||
- ежедневная сводка вместо отдельных сообщений;
|
||
- повторное напоминание о срочной отмене;
|
||
- журнал доставки и пользовательские настройки каналов.
|
||
|
||
**Ожидаемый результат:** снижение числа пропущенных изменений. **Сложность:** M.
|
||
**Демонстрационный эффект:** высокий, особенно вместе с мастером замены.
|
||
|
||
## 5. (не делаем) Привязка студента к группе и подгруппе
|
||
|
||
### Проблема и пользователи
|
||
|
||
Студент сейчас выбирает любую группу вручную, а выбранный идентификатор сохраняется только
|
||
в `localStorage.studentGroupId`. У системы нет персонального контекста студента, поэтому
|
||
нельзя надёжно показать его подгруппу или адресовать ему уведомления.
|
||
|
||
### Пользовательский сценарий
|
||
|
||
1. Администратор создаёт студента и назначает ему группу и при необходимости лабораторную
|
||
подгруппу.
|
||
2. После входа студент сразу попадает в раздел «Моё расписание».
|
||
3. Расписание автоматически фильтруется по его группе и подгруппе.
|
||
4. При переводе сохраняется история принадлежности, чтобы прошлое расписание оставалось
|
||
корректным.
|
||
|
||
### Минимальная версия
|
||
|
||
- связь пользователя с учебной группой и опциональной подгруппой;
|
||
- редактирование связи в административном интерфейсе;
|
||
- выдача группы и подгруппы в профиле текущего пользователя;
|
||
- автоматическая загрузка личного расписания без `localStorage` как источника истины;
|
||
- проверка соответствия подгруппы выбранной группе;
|
||
- безопасное поведение для студента, которому группа ещё не назначена.
|
||
|
||
### Связь с текущей системой
|
||
|
||
Используются существующие `User`, `StudentGroup`, `Subgroup`, авторизация и студенческий
|
||
кабинет. Динамический генератор уже умеет фильтровать лабораторные занятия по подгруппам,
|
||
поэтому новая связь завершает пользовательский сценарий без создания второго механизма
|
||
расписания.
|
||
|
||
### Дальнейшее развитие
|
||
|
||
- история переводов между группами;
|
||
- индивидуальные элективные дисциплины;
|
||
- староста и дополнительные роли внутри группы;
|
||
- персональные экзамены и уведомления;
|
||
- импорт состава групп из внешней информационной системы.
|
||
|
||
**Ожидаемый результат:** настоящий персональный кабинет студента и основа для адресных
|
||
сервисов. **Сложность:** M. **Демонстрационный эффект:** средний, продуктовая ценность —
|
||
высокая.
|
||
|
||
## 6. (не делаем) Персональная подписка на расписание через ICS
|
||
|
||
### Проблема и пользователи
|
||
|
||
Преподаватели и студенты вынуждены открывать отдельный сайт, чтобы проверить расписание.
|
||
Подписка на календарь позволит видеть актуальные занятия в Google Calendar, Apple Calendar,
|
||
Outlook, Яндекс Календаре и других совместимых приложениях.
|
||
|
||
Формат следует строить на открытом стандарте
|
||
[iCalendar RFC 5545](https://www.rfc-editor.org/info/rfc5545/).
|
||
|
||
### Пользовательский сценарий
|
||
|
||
1. Пользователь открывает раздел интеграций и создаёт персональную ссылку.
|
||
2. Ссылка добавляется в календарное приложение напрямую или через QR-код.
|
||
3. Приложение периодически обновляет календарь, получая актуальные занятия с учётом
|
||
переносов, замен и отмен.
|
||
4. Пользователь может отозвать ссылку и создать новую.
|
||
|
||
### Минимальная версия
|
||
|
||
- read-only ICS-feed для преподавателя и учебной группы;
|
||
- персональный непрогнозируемый токен вместо JWT в URL;
|
||
- стабильный `UID` события, корректные дата, время, часовой пояс и место;
|
||
- отражение актуальных overrides;
|
||
- отзыв и ротация токена;
|
||
- кнопка копирования ссылки и краткая инструкция подключения.
|
||
|
||
### Связь с текущей системой
|
||
|
||
Feed формируется через `ScheduleQueryService` и не хранит отдельную копию расписания.
|
||
Преподавательский календарь можно реализовать сразу, а персональный студенческий вариант
|
||
становится полноценным после привязки студента к группе и подгруппе. При внедрении версий
|
||
feed должен отдавать только опубликованное расписание. Текущий API ограничивает один запрос
|
||
расписания диапазоном в 120 дней, поэтому подписке понадобится ограниченное скользящее окно
|
||
либо внутренняя генерация последовательных диапазонов вместо безграничного запроса на весь
|
||
период обучения.
|
||
|
||
### Дальнейшее развитие
|
||
|
||
- отдельные календари экзаменов и консультаций;
|
||
- подписки для аудиторий и кафедр;
|
||
- экспорт выбранного диапазона отдельным `.ics`-файлом;
|
||
- дополнительные напоминания через `VALARM`;
|
||
- интеграция через CalDAV при появлении соответствующей потребности.
|
||
|
||
**Ожидаемый результат:** расписание становится частью привычного календаря пользователя.
|
||
**Сложность:** S–M. **Демонстрационный эффект:** высокий при относительно небольшом объёме
|
||
работ.
|
||
|
||
## 7. (не делаем) Импорт календарного учебного графика из Excel
|
||
|
||
### Проблема и пользователи
|
||
|
||
Календарные графики обычно существуют в виде Excel-таблиц с кодами `Т`, `Э`, `К`, `У`,
|
||
`П` и другими активностями. Сейчас администратор переносит эти данные в дневную сетку
|
||
вручную. В [ACADEMIC_CALENDAR.md](ACADEMIC_CALENDAR.md) прямо указано, что Excel-импорт в
|
||
первой реализации не предусмотрен.
|
||
|
||
### Пользовательский сценарий
|
||
|
||
1. Администратор скачивает утверждённый шаблон или выбирает существующий XLSX-файл.
|
||
2. Система распознаёт лист, курсы, недели, дни и коды активностей.
|
||
3. Перед сохранением показывается предварительная сетка и список ошибок с адресами ячеек.
|
||
4. Пользователь исправляет файл либо подтверждает корректный результат.
|
||
5. Данные применяются атомарно через текущий сервис полной замены сетки.
|
||
|
||
### Минимальная версия
|
||
|
||
- один документированный XLSX-шаблон;
|
||
- импорт одного календарного графика;
|
||
- распознавание курсов, дат и известных кодов активностей;
|
||
- режим предварительной проверки без записи;
|
||
- понятные ошибки с номером листа и ячейки;
|
||
- запрет частичного сохранения при любой ошибке;
|
||
- итоговое применение через `AcademicCalendarGridService`.
|
||
|
||
### Связь с текущей системой
|
||
|
||
Импорт должен преобразовывать Excel в существующий дневной REST-контракт, а не создавать
|
||
параллельную модель хранения. Все проверки дат, учебного года, ISO-недель, уникальности и
|
||
кодов активностей остаются в `AcademicCalendarGridService`.
|
||
|
||
### Дальнейшее развитие
|
||
|
||
- сопоставление колонок для нескольких распространённых шаблонов;
|
||
- экспорт текущего графика обратно в XLSX;
|
||
- импорт дисциплин и учебных планов;
|
||
- сравнение файла с сохранённым графиком до применения;
|
||
- пакетная загрузка нескольких профилей и форм обучения.
|
||
|
||
**Ожидаемый результат:** заметное сокращение ручного заполнения и ошибок ввода.
|
||
**Сложность:** M. **Демонстрационный эффект:** высокий благодаря наглядному предпросмотру.
|
||
|
||
## 8. (отдельным запросом) Анализ качества и автоматическая оптимизация расписания
|
||
|
||
### Проблема и пользователи
|
||
|
||
Текущее расписание может быть формально корректным, но неудобным: большие окна, перегруженные
|
||
дни, неравномерная нагрузка, слишком крупная аудитория для небольшой группы или игнорирование
|
||
пожеланий преподавателя. Существующая проверка конфликтов отвечает на вопрос «можно ли
|
||
сохранить», но не оценивает качество допустимого варианта.
|
||
|
||
### Рекомендуемое разделение на этапы
|
||
|
||
#### Этап 1. Анализатор качества
|
||
|
||
- рассчитывает окна групп и преподавателей;
|
||
- показывает равномерность занятий по дням;
|
||
- сравнивает вместимость аудитории с численностью групп;
|
||
- учитывает пожелания и недоступность преподавателей;
|
||
- выявляет чрезмерную дневную нагрузку;
|
||
- формирует объяснимую итоговую оценку и список проблем.
|
||
|
||
#### Этап 2. Помощник перестановок
|
||
|
||
- предлагает несколько свободных слотов или аудиторий для выбранной проблемы;
|
||
- показывает, какие показатели улучшатся или ухудшатся;
|
||
- применяет вариант только после подтверждения пользователя;
|
||
- сохраняет ручные закрепления, которые оптимизатор не имеет права менять.
|
||
|
||
#### Этап 3. Полный оптимизатор
|
||
|
||
- строит один или несколько вариантов расписания для выбранного семестра;
|
||
- соблюдает все строгие ограничения;
|
||
- минимизирует штрафы мягких ограничений;
|
||
- сохраняет результат как черновик, а не публикует автоматически.
|
||
|
||
### Минимальная версия
|
||
|
||
Практичнее начать не с полного solver, а с анализатора и локальных рекомендаций для одного
|
||
конфликтного или неудобного занятия. Такой MVP позволяет проверить метрики качества,
|
||
интерфейс объяснений и производительность на реальных данных.
|
||
|
||
Red Zone уже выявляет накладки и превышение вместимости, а вкладка загруженности показывает
|
||
занятые и свободные слоты. Новый анализатор не должен дублировать эти экраны: его ценность —
|
||
единая объяснимая оценка, мягкие критерии качества и рекомендации по улучшению.
|
||
|
||
### Связь с текущей системой
|
||
|
||
Исходными данными становятся правила, сформированные занятия, размеры групп, вместимость
|
||
аудиторий, квалификации и пожелания преподавателей. Для проверки кандидатов повторно
|
||
используются существующие валидаторы конфликтов. Версии и черновики дают безопасное место
|
||
для результатов оптимизации.
|
||
|
||
В качестве внешнего ориентира можно использовать подходы из официального
|
||
[руководства по solver UniTime](https://help.unitime.org/manuals/courses-solver), не копируя
|
||
его внутреннюю реализацию.
|
||
|
||
### Дальнейшее развитие
|
||
|
||
- настройка весов критериев для каждого тенанта;
|
||
- сравнение нескольких найденных вариантов;
|
||
- фоновый расчёт с прогрессом и возможностью остановки;
|
||
- автоматическое локальное исправление после инцидента;
|
||
- сохранение обезличенных метрик качества по семестрам.
|
||
|
||
**Ожидаемый результат:** переход от проверки корректности к измеримому повышению качества
|
||
расписания. **Сложность:** L. **Демонстрационный эффект:** максимальный и подходящий для
|
||
исследовательской части магистерской работы.
|
||
|
||
## 9. (не делаем) Расписание экзаменационной сессии
|
||
|
||
### Проблема и пользователи
|
||
|
||
Календарный учебный график уже поддерживает код экзаменационной сессии `Э`, но обычные
|
||
занятия на таких датах намеренно не генерируются. Отдельной модели экзаменов, консультаций,
|
||
экзаменаторов и экзаменационных аудиторий пока нет.
|
||
|
||
### Пользовательский сценарий
|
||
|
||
1. Учебный отдел задаёт экзаменационные периоды семестра.
|
||
2. Кафедры указывают дисциплины, группы, экзаменаторов, длительность и особые требования.
|
||
3. Система проверяет допустимые даты, вместимость и занятость ресурсов.
|
||
4. Пользователь вручную размещает экзамены или запускает подбор вариантов.
|
||
5. После проверки экзаменационное расписание публикуется студентам и преподавателям.
|
||
|
||
### Минимальная версия
|
||
|
||
- экзамен и консультация как отдельные сущности, не маскируемые под обычную пару;
|
||
- связь с дисциплиной, семестром, группами и экзаменаторами;
|
||
- дата, период, длительность и одна или несколько аудиторий;
|
||
- проверка пересечений групп, преподавателей и помещений;
|
||
- проверка суммарной вместимости аудиторий;
|
||
- ручной конструктор и отдельный режим просмотра;
|
||
- публикация в личных кабинетах и календарных feeds.
|
||
|
||
На первом этапе конфликты можно считать на уровне групп. Для индивидуальных конфликтов
|
||
студентов понадобится модель зачислений на дисциплины или экзамены.
|
||
|
||
### Связь с текущей системой
|
||
|
||
Модуль использует семестры, коды календарной активности, группы, дисциплины, преподавателей,
|
||
аудитории и общий подход к проверке ресурсов. При этом экзаменационное расписание должно
|
||
оставаться отдельным доменом: у экзаменов другие длительности, правила вместимости и
|
||
критерии качества.
|
||
|
||
Полезным внешним ориентиром является официальное
|
||
[руководство UniTime по экзаменационному расписанию](https://help.unitime.org/manuals/examination-timetabling).
|
||
|
||
### Дальнейшее развитие
|
||
|
||
- автоматическое распределение экзаменов по периодам и аудиториям;
|
||
- минимизация двух экзаменов подряд и перегруженных экзаменационных дней;
|
||
- индивидуальные конфликты студентов;
|
||
- печатные ведомости, рассадка и распределение по нескольким аудиториям;
|
||
- отчёты по использованию экзаменационных помещений.
|
||
|
||
**Ожидаемый результат:** новый самостоятельный контур учебного процесса на основе уже
|
||
существующих справочников и календаря. **Сложность:** L. **Демонстрационный эффект:**
|
||
максимальный.
|