Идеи
This commit is contained in:
dipatrik10
586
docs/FEATURE_IDEAS.md
Normal file
586
docs/FEATURE_IDEAS.md
Normal file
@@ -0,0 +1,586 @@
|
|||||||
|
# Идеи развития проекта 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. Отсутствия преподавателей и мастер замены
|
||||||
|
|
||||||
|
### Проблема и пользователи
|
||||||
|
|
||||||
|
Болезнь, командировка или другое временное отсутствие преподавателя затрагивает сразу
|
||||||
|
несколько занятий. Сейчас учебному отделу нужно самостоятельно найти эти занятия, проверить
|
||||||
|
доступность ресурсов и создать каждое точечное изменение. Функция нужна учебному отделу,
|
||||||
|
кафедрам и преподавателям.
|
||||||
|
|
||||||
|
Регистрация отсутствий и мастер разрешения инцидентов уже обозначены как планируемые
|
||||||
|
бизнес-правила в [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. **Демонстрационный эффект:**
|
||||||
|
максимальный.
|
||||||
|
|
||||||
|
## Рекомендуемые варианты развития
|
||||||
|
|
||||||
|
### Быстрые продуктовые улучшения
|
||||||
|
|
||||||
|
1. Привязать студента к группе и подгруппе.
|
||||||
|
2. Добавить ICS-подписку для преподавателей и групп.
|
||||||
|
3. Реализовать импорт календарного графика из одного утверждённого Excel-шаблона.
|
||||||
|
|
||||||
|
Эти задачи относительно изолированы, сразу заметны пользователям и подготавливают данные
|
||||||
|
для уведомлений и персональных сервисов.
|
||||||
|
|
||||||
|
### Следующий крупный релиз
|
||||||
|
|
||||||
|
Объединить отсутствия преподавателей, мастер замены и внутренний центр уведомлений в один
|
||||||
|
сквозной сценарий:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Регистрация отсутствия
|
||||||
|
↓
|
||||||
|
Поиск затронутых занятий
|
||||||
|
↓
|
||||||
|
Подбор допустимых решений
|
||||||
|
↓
|
||||||
|
Подтверждение overrides
|
||||||
|
↓
|
||||||
|
Уведомление пользователей
|
||||||
|
```
|
||||||
|
|
||||||
|
Это направление максимально использует уже готовые механизмы и показывает практическую
|
||||||
|
ценность системы в ежедневной работе университета.
|
||||||
|
|
||||||
|
### Архитектурное развитие
|
||||||
|
|
||||||
|
Перед массовой автоматизацией изменений целесообразно внедрить версии, черновики и
|
||||||
|
публикацию. Такой жизненный цикл защищает конечных пользователей от промежуточного состояния
|
||||||
|
и создаёт безопасную основу для мастера инцидентов и оптимизатора.
|
||||||
|
|
||||||
|
### Исследовательское направление
|
||||||
|
|
||||||
|
Для магистерской работы наиболее сильны два варианта:
|
||||||
|
|
||||||
|
- анализ качества и оптимизация расписания с объяснимыми строгими и мягкими ограничениями;
|
||||||
|
- отдельный модуль экзаменационной сессии с задачей размещения экзаменов и минимизации
|
||||||
|
конфликтов.
|
||||||
|
|
||||||
|
Оптимизатор лучше начинать с оценки качества и локальных рекомендаций. Экзаменационный
|
||||||
|
модуль — с ручного конструктора и строгой проверки ресурсов. Это позволит получить полезный
|
||||||
|
MVP до разработки полного solver.
|
||||||
|
|
||||||
|
## Предлагаемый порядок реализации
|
||||||
|
|
||||||
|
1. Персональный контекст студента.
|
||||||
|
2. ICS-подписки и Excel-импорт как независимые быстрые функции.
|
||||||
|
3. Версии, черновики, аудит и публикация расписания.
|
||||||
|
4. Отсутствия преподавателей и мастер замены.
|
||||||
|
5. Внутренний центр уведомлений, затем внешние каналы.
|
||||||
|
6. Пожелания преподавателей и заявки на перенос.
|
||||||
|
7. Анализатор качества и локальные рекомендации.
|
||||||
|
8. Полный оптимизатор либо экзаменационный модуль как отдельный крупный этап.
|
||||||
|
|
||||||
|
Порядок не является обязательным roadmap. Он показывает зависимости между идеями и должен
|
||||||
|
быть пересмотрен после выбора ближайших продуктовых целей.
|
||||||
|
|
||||||
|
## Внешние ориентиры
|
||||||
|
|
||||||
|
- [RFC 5545: Internet Calendaring and Scheduling Core Object Specification](https://www.rfc-editor.org/info/rfc5545/)
|
||||||
|
— стандарт формата iCalendar.
|
||||||
|
- [UniTime: Course Timetabling Solver Manual](https://help.unitime.org/manuals/courses-solver)
|
||||||
|
— ограничения, варианты расписаний и публикация результата.
|
||||||
|
- [UniTime: Instructor Survey](https://help.unitime.org/instructor-survey)
|
||||||
|
— сбор предпочтений и требований преподавателей.
|
||||||
|
- [UniTime: Examination Timetabling Manual](https://help.unitime.org/manuals/examination-timetabling)
|
||||||
|
— отдельная предметная область экзаменационного расписания.
|
||||||
|
|
||||||
|
Эти материалы используются только как ориентиры для продуктовой проработки. Конкретные
|
||||||
|
контракты, модели данных и пользовательские сценарии должны соответствовать архитектуре и
|
||||||
|
ролевой модели Magistr.
|
||||||
@@ -121,6 +121,7 @@ magistr/
|
|||||||
|----------|-----------|
|
|----------|-----------|
|
||||||
| [Архитектура](ARCHITECTURE.md) | Общая архитектура, мультитенантность, взаимодействие компонентов |
|
| [Архитектура](ARCHITECTURE.md) | Общая архитектура, мультитенантность, взаимодействие компонентов |
|
||||||
| [Бизнес-логика](BUSINESS_LOGIC.md) | Ролевая модель, правила расписания, управление ресурсами |
|
| [Бизнес-логика](BUSINESS_LOGIC.md) | Ролевая модель, правила расписания, управление ресурсами |
|
||||||
|
| [Идеи развития](FEATURE_IDEAS.md) | Продуктовые предложения, приоритеты и возможный roadmap проекта |
|
||||||
| [Календарный учебный график](ACADEMIC_CALENDAR.md) | Модель графиков по специальностям, профилям и группам |
|
| [Календарный учебный график](ACADEMIC_CALENDAR.md) | Модель графиков по специальностям, профилям и группам |
|
||||||
| [База данных](DATABASE.md) | Схема БД, описание таблиц, Flyway миграции |
|
| [База данных](DATABASE.md) | Схема БД, описание таблиц, Flyway миграции |
|
||||||
| [REST API](API.md) | Все эндпоинты с примерами запросов и ответов |
|
| [REST API](API.md) | Все эндпоинты с примерами запросов и ответов |
|
||||||
|
|||||||
Reference in New Issue
Block a user