ada/SecondBrain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

arch-x1: 2026-06-08 15:48:31 | 1

Browse Source
This commit is contained in:
Dmitry
2026-06-08 15:48:31 +03:00
parent 3f3ef3327b
commit 651ed73d41
1 changed files with 196 additions and 97 deletions
Download Patch File Download Diff File Expand all files Collapse all files
00 Inbox/УИР_Сводный_вариант.md
+196 -97
View File
@@ -10,6 +10,40 @@ created: 2026-06-08
updated: 2026-06-08 updated: 2026-06-08
--- ---
# МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение высшего образования
## НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ЯДЕРНЫЙ УНИВЕРСИТЕТ «МИФИ»
*ИНСТИТУТ ИНТЕЛЛЕКТУАЛЬНЫХ КИБЕРНЕТИЧЕСКИХ СИСТЕМ*
КАФЕДРА КИБЕРНЕТИКИ
---
**Учебно-исследовательская работа на тему**
**«Обзор существующих решений и выбор инструментария для разработки системы учёта посещаемости студентов НИЯУ МИФИ»**
---
Выполнил студент: __________________________________
Группа: _______
Проверил: __________________________________
Оценка: ___________________
Дата: _____________________
Подпись: __________________
**Москва, 2026**
---
## Оглавление ## Оглавление
- [Введение](#введение) - [Введение](#введение)
@@ -20,6 +54,13 @@ updated: 2026-06-08
- [2. Анализ методов фиксации посещаемости студентов](#2-анализ-методов-фиксации-посещаемости-студентов) - [2. Анализ методов фиксации посещаемости студентов](#2-анализ-методов-фиксации-посещаемости-студентов)
- [3. Обзор существующих исследований](#3-обзор-существующих-исследований) - [3. Обзор существующих исследований](#3-обзор-существующих-исследований)
- [4. Выбор технологического стека](#4-выбор-технологического-стека) - [4. Выбор технологического стека](#4-выбор-технологического-стека)
- [4.1. Веб-фреймворк и архитектура приложения](#41-веб-фреймворк-и-архитектура-приложения)
- [4.2. Фронтенд-архитектура: Hotwire](#42-фронтенд-архитектура-hotwire)
- [4.3. СУБД: PostgreSQL](#43-субд-postgresql)
- [4.4. Фоновые задачи: Sidekiq и Redis](#44-фоновые-задачи-sidekiq-и-redis)
- [4.5. Аутентификация: CAS](#45-аутентификация-cas)
- [4.6. Архитектурные паттерны](#46-архитектурные-паттерны)
- [4.7. Стилизация и деплой](#47-стилизация-и-деплой)
- [Заключение](#заключение) - [Заключение](#заключение)
- [Список использованной литературы](#список-использованной-литературы) - [Список использованной литературы](#список-использованной-литературы)
@@ -27,183 +68,241 @@ updated: 2026-06-08
## Введение ## Введение
Цифровая трансформация высшего образования является одним из ключевых направлений государственной политики Российской Федерации. В современных условиях крупного вуза, такого как НИЯУ МИФИ, традиционные бумажные журналы или разрозненные электронные таблицы становятся неэффективными инструментами для учета посещаемости. Ручное ведение журналов существенно увеличивает нагрузку на преподавателей, повышает риск потери данных, снижает оперативность получения статистики деканатами и не позволяет автоматически синхронизировать данные с внешними информационными системами университета. Цифровизация управления учебным процессом требует от университета не только электронного хранения данных, но и прозрачной, проверяемой фиксации факта присутствия студентов на занятиях. В крупном техническом вузе, таком как НИЯУ МИФИ, традиционные бумажные журналы и разрозненные электронные таблицы создают существенные организационные ограничения: увеличивают нагрузку на преподавателей, повышают риск потери или несвоевременного внесения данных, затрудняют оперативное получение статистики деканатами и не позволяют автоматически синхронизировать сведения с внутренними информационными системами университета.
Проблема усугубляется тем, что НИЯУ МИФИ располагает развитой корпоративной IT-инфраструктурой, включающей Единую систему аутентификации (CAS) и внутренние реестры академических данных. Существующие на рынке решения, как правило, не обеспечивают нативной интеграции с подобными инфраструктурными компонентами. Проблема особенно актуальна для НИЯУ МИФИ, поскольку университет располагает развитой корпоративной IT-инфраструктурой: единой системой аутентификации, внутренними академическими реестрами, расписанием и ролевыми моделями доступа. Готовая система учёта посещаемости для такого окружения должна не просто фиксировать отметку, а работать как часть корпоративного контура: использовать существующие учётные записи, корректно разделять роли студентов, преподавателей, кураторов, деканата и администраторов, а также гарантированно передавать события посещаемости во внешние реестры.
Дополнительную актуальность проблеме придаёт требование прозрачности: студент должен иметь возможность самостоятельно видеть свою историю посещений, преподаватель должен иметь возможность как автоматически фиксировать посещение (через QR-код), так и вручную корректировать данные, а деканат — получать сводную аналитику. Дополнительную актуальность задаче придаёт требование прозрачности. Студент должен иметь возможность видеть собственную историю посещений до окончания семестра; преподаватель должен иметь быстрый механизм фиксации присутствия и возможность ручной корректировки спорных случаев; куратор и деканат должны получать сводную аналитику без ручной консолидации журналов.
Анализ показывает, что ни один массовый продукт на рынке не сочетает одновременно ключевые свойства, необходимые корпоративному вузу: QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO (CAS МИФИ), гарантированную Outbox-синхронизацию с внутренними реестрами и полную ролевую модель (студент / преподаватель / куратор / деканат / администратор). Это прямо обосновывает необходимость разработки собственного решения для НИЯУ МИФИ (система «Attendance MEPhI»). Проведённый анализ показывает, что массовые российские и зарубежные решения не сочетают одновременно ключевые свойства, необходимые корпоративному вузу: QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO на базе CAS, гарантированную синхронизацию с внутренними реестрами и полноценную вузовскую ролевую модель. Это обосновывает необходимость разработки собственной системы «Attendance MEPhI».
**Целью** настоящей работы является определение подхода к разработке веб-приложения для автоматизированного учёта посещаемости студентов НИЯУ МИФИ, обеспечивающего прозрачную фиксацию присутствия на занятиях, интеграцию с корпоративными системами университета и надёжную синхронизацию данных. **Целью** настоящей работы является определение подхода к разработке веб-приложения для автоматизированного учёта посещаемости студентов НИЯУ МИФИ, обеспечивающего прозрачную фиксацию присутствия на занятиях, интеграцию с корпоративными системами университета и надёжную синхронизацию данных с внешними реестрами.
**Объект исследования** — процесс учёта посещаемости студентов в НИЯУ МИФИ, включающий взаимодействие студентов, преподавателей, кураторов и администраторов в рамках учебного процесса. **Объект исследования** — процесс учёта посещаемости студентов в НИЯУ МИФИ, включающий взаимодействие студентов, преподавателей, кураторов, деканата и администраторов в рамках учебного процесса.
**Предмет исследования** — методы и инструменты автоматизации фиксации посещаемости студентов, архитектурные паттерны и технологии для реализации интегрированного корпоративного веб-приложения. **Предмет исследования** — методы и инструменты автоматизации фиксации посещаемости студентов, архитектурные паттерны и технологии для реализации интегрированного корпоративного веб-приложения.
**Задачи работы:** **Задачи работы:**
1. Провести обзор существующих аналогов систем учёта посещаемости (российских и зарубежных) и выявить их принципиальные ограничения применительно к условиям НИЯУ МИФИ.
2. Проанализировать основные методы технической фиксации факта посещения студентом занятия и обосновать выбор QR-кодов как основного механизма самоотметки. 1. Провести обзор существующих аналогов систем учёта посещаемости и выявить их ограничения применительно к условиям НИЯУ МИФИ.
3. Изучить актуальные научные исследования в области автоматизированного учёта посещаемости и смежных задач для формирования теоретической базы разработки. 2. Проанализировать основные методы технической фиксации факта посещения студентом занятия.
4. Определить оптимальный технологический стек и архитектурные решения, обосновав выбор каждого компонента. 3. Обосновать выбор QR-кодов как основного механизма самоотметки.
4. Изучить научные и отраслевые источники по автоматизированному учёту посещаемости, производительности СУБД и архитектурным паттернам надёжной синхронизации.
5. Определить технологический стек и архитектурные решения для разработки системы.
**Методологическую основу** исследования составляет системный анализ существующих программных решений и технологических подходов в области автоматизации учёта посещаемости. В работе используются сравнительный анализ коммерческих и открытых систем, анализ методов фиксации посещаемости, обзор научных публикаций и проверка технических решений по официальной документации.
**Практическая значимость** работы заключается в формировании обоснованной методической базы для последующей разработки системы «Attendance MEPhI». Результаты анализа позволяют избежать типовых ошибок: зависимости от внешнего SaaS-провайдера, отсутствия гарантий доставки данных, невозможности интеграции с корпоративным SSO и смешения ролей пользователей.
--- ---
## 1. Обзор существующих систем учёта посещаемости студентов ## 1. Обзор существующих систем учёта посещаемости студентов
Прежде чем приступить к проектированию новой системы, необходимо провести детальный анализ уже существующих решений для выявления незаполненной ниши и формулирования требований к разрабатываемому приложению. Перед проектированием новой системы необходимо оценить существующие решения: российские электронные журналы и ERP-платформы, зарубежные LMS и сервисы видеоконференций, специализированные QR/SaaS-сервисы и открытые прототипы. Цель анализа — определить, можно ли закрыть требования НИЯУ МИФИ готовым продуктом либо разработка собственной системы является обоснованной.
### 1.1. Российские системы ### 1.1. Российские системы
**Система «Учёт посещаемости студентов» ВВГУ (ВГУЭС).** Собственная разработка Департамента цифрового развития ВВГУ. Преподаватель показывает QR-код, студенты сканируют его для записи о присутствии; также возможна ручная отметка. **Система «Учёт посещаемости студентов» ВВГУ.** Это внутренняя разработка Департамента цифрового развития Владивостокского государственного университета. По описанию ВВГУ, преподаватель во время занятия предоставляет студентам QR-код, при сканировании которого фиксируется присутствие; также возможна ручная отметка преподавателем. Система близка к целевому сценарию по способу фиксации, но является закрытым внутренним решением одного вуза. Для НИЯУ МИФИ она не закрывает требования интеграции с CAS, внешними академическими реестрами и собственной ролевой моделью.
*Ограничения:* Это закрытая внутренняя система одного вуза без публичного API и Outbox-синхронизации, права куратора выдаются по бумажному заявлению. Не интегрируется с внешними CAS МИФИ и обладает ограниченной ролевой моделью.
**БАРС.Образование — Электронная школа (БАРС Груп).** Одна из наиболее распространённых платформ электронного журнала в РФ, рекомендованная к тиражированию в рамках программы «Электронный регион» [10]. **БАРС.Образование — Электронная школа.** Платформа ориентирована на электронный журнал и дневник школьного сегмента: оценки, темы уроков, расписание, домашние задания, посещаемость и отчётность. Ключевое ограничение состоит в самой модели предметной области: «школа — класс — родитель» плохо переносится на вузовскую структуру «поток — группа — подгруппа — кафедра — деканат». Посещаемость в таких системах, как правило, фиксируется учителем вручную; студенческая QR-самоотметка на очном занятии и интеграция с CAS вуза не являются базовым сценарием.
*Ограничения:* Архитектура построена на модели «школа — класс — родитель», не масштабируемой на структуру «поток — группа — подгруппа». Посещаемость фиксируется исключительно вручную учителем; QR-self-service не предусмотрен. Интеграция реализуется через Госуслуги, минуя корпоративный CAS вуза, и отсутствует механизм гарантированной Outbox-синхронизации.
**1С:Университет.** Отраслевое ERP-решение на платформе «1С:Предприятие 8.3» для управления учебным процессом вуза [11]. **1С:Университет.** Решение на платформе «1С:Предприятие 8.3» предназначено для комплексной автоматизации процессов вуза: приёмной кампании, учебных планов, контингента, нагрузки преподавателей, успеваемости и посещаемости. Его сильная сторона — широкий охват административных процессов. Ограничение для данной работы — избыточность ERP-подхода и зависимость от экосистемы 1С. Для задачи точечной разработки веб-системы QR-самоотметки с CAS и REST/Outbox-синхронизацией такое решение не является оптимальным.
*Ограничения:* Ввод данных о посещаемости осуществляется вручную через АРМ преподавателя. Отсутствует студенческий QR-self-service. Интеграция с внешними системами реализуется через специализированные механизмы обмена 1С, а не через REST API и корпоративный SSO.
**iSpring Learn (iSpring Solutions).** Российская корпоративная LMS, доступная в облаке и on-premise [12]. **iSpring LMS (ранее iSpring Learn).** Платформа ориентирована на корпоративное обучение: онлайн-курсы, тесты, тренинги, отчёты, API, SSO и on-premise-развёртывание. Функции посещаемости привязаны к тренингам и корпоративным мероприятиям, а не к вузовскому расписанию очных занятий. Система не предоставляет целевую модель «поток — группа — занятие — преподаватель — студент» и не решает задачу гарантированной синхронизации посещаемости с академическими реестрами НИЯУ МИФИ.
*Ограничения:* Система предназначена для корпоративного обучения. Посещаемость является побочной функцией модуля мероприятий (преподаватель отмечает вручную после завершения). Нет QR-самоотметки на занятии, отсутствует модель «учебный поток вуза» и Outbox-синхронизация. SSO реализован без поддержки используемого в МИФИ протокола CAS.
**Дневник.ру, ЭлЖур, Сетевой город. Образование.** Данные системы ориентированы на школьный сегмент (ручная отметка, модель «класс»). Они не поддерживают QR-самоотметку, CAS вуза и вузовскую ролевую модель. **Дневник.ру, ЭлЖур, Сетевой город. Образование.** Эти решения также относятся преимущественно к школьному электронному журналу. Их базовые сценарии строятся вокруг класса, учителя, родителей и ручной отметки посещаемости. Для корпоративного технического университета они не закрывают требования по CAS, QR-самоотметке, вузовской ролевой модели и on-premise-контролю данных.
### 1.2. Зарубежные системы ### 1.2. Зарубежные системы
**Microsoft Teams.** Платформа поддерживает автоматическую генерацию отчёта о посещаемости онлайн-встречи (время входа/выхода) [13]. **Microsoft Teams.** В Teams поддерживаются отчёты о посещаемости онлайн-встреч: время входа, выхода, длительность участия и, в отдельных тарифах, показатели вовлечённости. Это полезно для дистанционных занятий, но не эквивалентно фиксации присутствия в аудитории. Кроме того, отчёты зависят от организатора встречи и не являются корпоративным реестром очной посещаемости. Для задачи НИЯУ МИФИ Teams не предоставляет QR-механизм, CAS-интеграцию и синхронизацию с внутренними академическими системами.
*Ограничения:* Фиксирует присутствие на видеовстрече, а не на очном занятии. Отчёты привязаны к организатору и безвозвратно удаляются при его увольнении. Нет QR-механизма, нет интеграции с реестрами МИФИ.
**Google Classroom / Google Meet.** В Google Classroom нативная функция отметки посещаемости отсутствует. В Google Meet отслеживание посещаемости доступно только на платных тарифах (Education Plus) для онлайн-встреч [14]. **Google Classroom / Google Meet.** Google Meet поддерживает отчёты о посещаемости для определённых редакций Google Workspace, включая Education Plus и Teaching and Learning Upgrade. Однако речь идёт о посещаемости онлайн-встреч, а не очных занятий. Google Classroom сам по себе не решает задачу аудиторной QR-самоотметки и не интегрируется с внутренними реестрами НИЯУ МИФИ в требуемой архитектуре.
*Ограничения:* Ключевая функция для очных занятий отсутствует; нет интеграции с внутренними системами вуза.
**Brightspace (D2L) — Attendance tool.** Базовый инструмент представляет собой электронный реестр, где отметку ставит преподаватель вручную [15]. **Brightspace (D2L).** Brightspace содержит инструмент Attendance, позволяющий создавать реестры посещаемости и отмечать статусы студентов. По своей природе базовый инструмент является электронным журналом внутри LMS. QR-самоотметка возможна через сторонние интеграции, например Qwickly Attendance, но это требует внедрения внешнего модуля и всей LMS-среды. Для НИЯУ МИФИ такой путь избыточен и не решает нативную интеграцию с CAS и внутренними реестрами.
*Ограничения:* QR-самоотметка реализуется только через сторонние платные плагины. Требует внедрения всей LMS Brightspace, что избыточно для задачи учёта посещаемости.
**Специализированные QR/чек-ин SaaS-решения (OneTap, AccuClass и др.).** Обеспечивают QR-чек-ин и импорт из Excel. **Специализированные QR/чек-ин SaaS-сервисы.** Сервисы наподобие OneTap, AccuClass и аналогичных решений предоставляют QR-чек-ин, импорт списков и отчёты. Их ограничение — ориентация на мероприятия, учебные центры или облачный сценарий. Для государственного вуза это создаёт риски размещения персональных данных у внешнего поставщика, vendor lock-in и зависимость от модели данных провайдера.
*Ограничения:* Данные хранятся в облаке стороннего провайдера (риски ФЗ-152). Нет Outbox-синхронизации, интеграции с CAS МИФИ и полноценной вузовской ролевой модели.
**Открытые проекты на GitHub (QR-Attendance-System и др.).** Студенческие прототипы на разнородных стеках. **Открытые прототипы на GitHub.** В открытом доступе есть студенческие и демонстрационные QR Attendance-проекты на Django, PHP, Java, .NET и других стеках. Они полезны как технические примеры, но не обладают промышленной надёжностью, полноценной ролевой моделью вуза, CAS-интеграцией и механизмом гарантированной доставки событий во внешние системы.
*Ограничения:* Отсутствует промышленная надёжность, нет Outbox-синхронизации, интеграции с CAS и ролевой модели вуза.
### 1.3. Сравнительный анализ аналогов ### 1.3. Сравнительный анализ аналогов
Сравнительная оценка систем по ключевым критериям, определённым спецификой задачи НИЯУ МИФИ, представлена в Таблице 1. Сравнительная оценка систем по критериям, важным для НИЯУ МИФИ, представлена в Таблице 1.
| Система | QR-self-service | SSO/CAS | Outbox-синхр. | Ролевая модель вуза | On-premise | Open-source | Итог | | Система | QR-self-service | SSO/CAS | Outbox-синхронизация | Ролевая модель вуза | On-premise / контроль данных | Контроль исходного кода | Итог |
|---|:---:|:---:|:---:|:---:|:---:|:---:|---| |---|:---:|:---:|:---:|:---:|:---:|:---:|---|
| ВВГУ «Учёт посещаемости» | ✔ | ✘ | ✘ | Частично | ✔ | ✘ | Не подходит | | ВВГУ «Учёт посещаемости» | ✔ | ✘ | ✘ | Частично | ✔ | ✘ | Не переносится в МИФИ |
| БАРС.Образование | ✘ | ✘ (Госуслуги) | ✘ | Школьная | Зависит | ✘ | Не подходит | | БАРС.Образование | ✘ | ✘ | ✘ | Школьная | Зависит от внедрения | ✘ | Не подходит |
| iSpring Learn | ✘ | ✔ (SAML) | ✘ | Корпоративная | ✔ | ✘ | Не подходит | | 1С:Университет | ✘ | ✘ | ✘ | ✔ | ✔ | ✘ | Избыточная ERP-платформа |
| 1С:Университет | ✘ | ✘ | ✘ (Обмен 1С) | ✔ | ✔ | ✘ | Не подходит | | iSpring LMS | ✘ | SSO, не CAS МИФИ | ✘ | Корпоративная | ✔ | ✘ | Не подходит для вузовской QR-самоотметки |
| MS Teams | ✘ | ✔ (Azure AD) | ✘ | ✘ | ✘ | ✘ | Не подходит | | Microsoft Teams | ✘ | Azure AD | ✘ | ✘ | ✘ | ✘ | Только онлайн-встречи |
| Google Meet | ✘ | ✔ (Google) | ✘ | ✘ | ✘ | ✘ | Не подходит | | Google Meet/Classroom | ✘ | Google | ✘ | ✘ | ✘ | ✘ | Только онлайн-встречи |
| Brightspace | Плагин | ✔ | ✘ | LMS | ✔ | ✘ | Не подходит | | Brightspace (D2L) | Через интеграции | Зависит от внедрения | ✘ | LMS | Зависит от контракта | ✘ | Избыточно |
| QR-SaaS (OneTap и др.) | ✔ | Частично | ✘ | ✘ | ✘ | ✘ | Не подходит | | QR-SaaS-сервисы | ✔ | Частично | ✘ | ✘ | ✘ | ✘ | Риски ПДн и vendor lock-in |
| **Проектируемая система (МИФИ)** | **✔** | **✔ (CAS МИФИ)** | **✔** | **Полная** | **✔** | **✔** | **Целевая** | | Открытые прототипы | ✔ | ✘ | ✘ | ✘ | ✔ | ✔ | Не production-grade |
| **Attendance MEPhI** | **✔** | **✔ (CAS МИФИ)** | **✔** | **✔** | **✔** | **✔** | **Целевое решение** |
*Таблица 1 — Сравнительная оценка систем учёта посещаемости* *Таблица 1 — Сравнительная оценка систем учёта посещаемости*
Ни один из рассмотренных продуктов не закрывает нишу «QR-самоотметка + CAS-SSO вуза + Outbox-синхронизация + полная ролевая модель + on-premise», что полностью обосновывает разработку собственного решения. Вывод по разделу: готового продукта, который одновременно обеспечивает QR-самоотметку очной посещаемости, интеграцию с CAS МИФИ, гарантированную синхронизацию с внутренними реестрами, полную вузовскую ролевую модель и контроль данных на стороне университета, не выявлено. Следовательно, разработка собственной системы является обоснованной.
--- ---
## 2. Анализ методов фиксации посещаемости студентов ## 2. Анализ методов фиксации посещаемости студентов
**Ручная отметка преподавателем.** Традиционный метод, не требующий технических средств. Недостатки: трудоёмкость на больших потоках (до 10–15 минут на поток в 150 человек), субъективность, задержка актуализации данных, отсутствие цифрового следа. Для выбора основного механизма фиксации посещаемости необходимо сравнить возможные методы по инфраструктурным затратам, скорости, достоверности, правовым рискам и применимости в условиях многокорпусного университета.
**RFID/NFC-карты.** Метод обеспечивает высокую скорость фиксации. Ограничения: необходимость установки считывателей в каждой аудитории (высокие инфраструктурные затраты), риск передачи карты другому лицу, сложность привязки отметки к конкретной дисциплине без сложных расписаний на турникетах. **Ручная отметка преподавателем.** Традиционный метод не требует дополнительной инфраструктуры, но плохо масштабируется на крупные потоки. Он увеличивает нагрузку на преподавателя, создаёт задержку между фактом посещения и появлением данных в системе, а также оставляет риск ошибок при переносе данных.
**QR-коды.** Преподаватель генерирует QR-код для конкретного занятия, студент сканирует его смартфоном. Метод сочетает высокую скорость (5-10 сек на человека) и минимальные инфраструктурные требования (считыватели не нужны). Защита от злоупотреблений обеспечивается временем жизни кода и однократным использованием токена в связке с CAS-аутентификацией. **RFID/NFC-карты.** Метод позволяет быстро фиксировать предъявление студенческой карты или пропуска. Ограничения связаны с необходимостью оборудования аудиторий считывателями, стоимостью внедрения и риском передачи карты другому лицу. Кроме того, отметку нужно связать не просто с входом в корпус, а с конкретной дисциплиной, занятием и преподавателем.
**Биометрическая идентификация.** Обеспечивает высокую достоверность, но обработка биометрии требует строгого соответствия требованиям ФЗ-152 о персональных данных специальной категории. Сопряжено с крайне высокими затратами на оборудование (камеры) и юридическими сложностями внедрения. **QR-коды.** Преподаватель генерирует QR-код для конкретного занятия, студент сканирует его смартфоном и проходит отметку через аутентифицированную сессию. Метод не требует установки считывателей в аудиториях, быстро внедряется и естественно связывается с расписанием, преподавателем и конкретной парой. Защита от злоупотреблений обеспечивается ограниченным временем жизни QR-кода, одноразовым токеном и проверкой личности через CAS.
**Геолокация.** Фиксирует местоположение студента. В многокорпусном кампусе МИФИ погрешность GPS (5–15 м) недостаточна для различения смежных аудиторий; также метод вызывает опасения пользователей касательно приватности. **Биометрическая идентификация.** Биометрия обеспечивает высокий уровень достоверности, но создаёт существенные правовые и организационные риски. Обработка биометрических персональных данных в РФ регулируется статьёй 11 Федерального закона № 152-ФЗ «О персональных данных» и требует отдельного правового обоснования. Для учебного проекта и массового внедрения в аудиториях этот метод избыточен.
**Геолокация.** Геолокационная отметка не требует аудиторного оборудования, но точности GPS и Wi-Fi-позиционирования может быть недостаточно для различения смежных аудиторий. Кроме того, постоянная или регулярная обработка местоположения студентов повышает чувствительность решения с точки зрения приватности.
| Метод | Инфраструктура | Скорость | Защита от подмены | Правовые риски | Применимость в МИФИ | | Метод | Инфраструктура | Скорость | Защита от подмены | Правовые риски | Применимость в МИФИ |
|---|---|---|---|---|---| |---|---|---|---|---|---|
| Ручная отметка | Минимальная | Низкая | Низкая | Минимальные | Базовая (резерв) | | Ручная отметка | Минимальная | Низкая на больших потоках | Низкая | Минимальные | Резервный сценарий |
| RFID/NFC | Высокая | Высокая | Средняя | Низкие | Ограниченная | | RFID/NFC | Высокие затраты на считыватели | Высокая | Средняя | Низкие | Ограниченная |
| **QR-коды** | **Минимальная** | **Высокая** | **Средняя** | **Низкие** | **Оптимальная** | | **QR-коды** | **Минимальная** | **Высокая** | **Средняя при токенах и CAS** | **Низкие** | **Оптимальная** |
| Биометрия | Высокая | Высокая | Высокая | Высокие (ФЗ-152) | Не применима | | Биометрия | Высокие затраты на оборудование | Высокая | Высокая | Высокие | Не рекомендуется |
| Геолокация | Минимальная | Высокая | Низкая | Средние | Вспомогательная | | Геолокация | Минимальная | Высокая | Низкая/средняя | Средние | Вспомогательная |
*Таблица 2 — Сравнительная оценка методов фиксации посещаемости* *Таблица 2 — Сравнительная оценка методов фиксации посещаемости*
Следовательно, метод **QR-кодов** является оптимальным: не требует оборудования, быстр и легко интегрируется с CAS. Основным методом для «Attendance MEPhI» целесообразно выбрать QR-коды. Ручная отметка преподавателем должна сохраниться как резервный механизм для спорных ситуаций, технических сбоев и студентов без доступа к смартфону в момент занятия.
--- ---
## 3. Обзор существующих исследований ## 3. Обзор существующих исследований
**QR-системы.** В исследовании A. Nuhi и др. (2020) [2] подтверждается принципиальная эффективность QR-метода в вузах. Система авторов продемонстрировала высокую скорость отметки и сниженные требования к инфраструктуре. Однако она была лишена CAS-интеграции и механизмов синхронизации, которые включены в проектируемую систему. **QR-системы посещаемости.** В работе A. Nuhi, A. Memeti, F. Imeri и B. Çiço «Smart Attendance System using QR Code» предложена система учёта посещаемости на основе QR-кодов для высшего образования. Авторы указывают на типовые проблемы ручной регистрации: трудоёмкость, затраты времени и сложность работы с большими группами. Исследование подтверждает применимость QR-подхода для лекций и практических занятий, но описанная система функционирует автономно и не рассматривает интеграцию с корпоративным SSO, академическими реестрами и механизмами гарантированной доставки событий.
**Отраслевой опыт МИФИ.** К.С. Глуховский и соавторы (2021) [3] описывают внедрение электронного журнала в ВИТИ НИЯУ МИФИ. Они выделяют задачи импорта расписания и разграничения ролей (студент, преподаватель, деканат). Недостатком их решения было отсутствие QR-самоотметки и гарантий Outbox-синхронизации, что решается в разрабатываемой системе. В статье с КиберЛенинки (опыт кафедры ИКТ) [22] также отмечается позитивный отклик преподавателей на делегирование процедуры отметки самим студентам на крупных потоках. **Электронный журнал в структуре НИЯУ МИФИ.** Работа К.С. Глуховского, Р.В. Пирожкова и Е.А. Цвелика посвящена электронному журналу как элементу цифровой трансформации вуза. Для настоящей работы она важна тем, что рассматривает близкий контекст: электронную информационно-образовательную среду, импорт академических данных, разграничение ролей и отчётность. Ограничение такого подхода — отсутствие студенческой QR-самоотметки и описанного механизма надёжной синхронизации событий посещаемости.
**Производительность СУБД.** Сравнительный анализ PostgreSQL и MySQL от Salunke и Ouda (2024) [5] продемонстрировал превосходство PostgreSQL в транзакционных операциях (INSERT быстрее в 13–15 раз на миллионе записей). Это критически важно для Outbox-паттерна и одновременных массовых отметок сотен студентов в начале лекции. **Практический опыт автоматизации очной посещаемости.** В публикации о методике автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий рассматривается переход от бумажной фиксации к цифровому учёту с использованием QR-инструментов и таблиц. Материал подтверждает практическую проблему крупных потоков и положительный эффект делегирования отметки студентам. При этом использование внешних облачных таблиц не подходит для целевой системы НИЯУ МИФИ из-за требований к контролю персональных данных и интеграции с внутренними системами.
**Архитектурные паттерны.** Монография К. Ричардсона (2018) [4] и документация AWS [16] фундаментально описывают паттерн **Transactional Outbox**, решающий проблему несогласованности данных («dual write»). Бизнес-событие пишется в outbox-таблицу в той же транзакции БД, а фоновый релей публикует его во внешние системы с гарантией at-least-once. Этот паттерн лежит в основе модуля синхронизации `Attendance MEPhI`. **Производительность СУБД.** В статье S.V. Salunke и A. Ouda «A Performance Benchmark for the PostgreSQL and MySQL Databases» сравниваются PostgreSQL и MySQL на операциях INSERT, SELECT и UPDATE. В условиях эксперимента PostgreSQL показал преимущество на ряде транзакционных операций. Для «Attendance MEPhI» это важно, поскольку фиксация посещаемости создаёт пиковую нагрузку в начале занятия и требует атомарной записи основной отметки вместе с Outbox-событием. При этом вывод не следует трактовать как абсолютное превосходство PostgreSQL во всех сценариях: результаты бенчмарков зависят от профиля нагрузки, объёма данных, индексов и конфигурации.
**Архитектурный паттерн Transactional Outbox.** К. Ричардсон и AWS Prescriptive Guidance описывают паттерн Transactional Outbox, решающий проблему «dual write»: несогласованности между записью в базу данных и отправкой события во внешнюю систему. Суть паттерна состоит в том, что событие записывается в outbox-таблицу в той же транзакции, что и бизнес-данные, а отдельный процесс-релей асинхронно публикует событие получателям. Паттерн обеспечивает доставку at-least-once, поэтому принимающая сторона должна быть идемпотентной.
Вывод по разделу: научные и отраслевые источники подтверждают применимость QR-кодов для учёта посещаемости, важность интеграции с вузовскими справочниками и необходимость архитектурного механизма надёжной синхронизации. Недостатки существующих подходов учитываются в проектируемой системе через CAS-аутентификацию, ролевую модель, PostgreSQL и Transactional Outbox.
--- ---
## 4. Выбор технологического стека ## 4. Выбор технологического стека
### 4.1. Веб-фреймворк и архитектура приложения Выбор технологического стека должен учитывать не только производительность отдельных компонентов, но и соответствие предметной области: быстрый CRUD, интеграция с SSO, работа с расписанием и группами, массовые отметки в начале занятий, генерация отчётов и надёжная доставка событий во внешние реестры.
Для реализации бэкенда выбран **Ruby on Rails 7**. Фреймворк реализует строгий паттерн MVC, принципы Convention over Configuration и DRY. Это обеспечивает высокую скорость разработки CRUD-компонентов. Данный выбор согласуется с выводами исследований веб-фреймворков (Даньшин К.А., 2019 [6]), подчеркивающих эффективность Rails для быстрой разработки. Недостаток "сырой" производительности Ruby компенсируется фоновой многопоточной обработкой и кэшированием.
### 4.2. Фронтенд-архитектура: Hotwire (Turbo + Stimulus) ### 4.1. Веб-фреймворк и архитектура приложения
Вместо разработки отдельного SPA (на React или Vue) используется подход **Hotwire** (HTML Over The Wire) [7], интегрированный в Rails 7. Сервер возвращает готовые HTML-фрагменты. Компоненты Turbo Drive, Turbo Frames и Turbo Streams позволяют выполнять точечные обновления DOM (отметка студента, обновление статуса) без полной перезагрузки страницы, обеспечивая SPA-ощущение с минимальным использованием клиентского JavaScript.
Для реализации бэкенда выбран **Ruby on Rails 7**. Rails реализует архитектурный паттерн MVC, следует принципам Convention over Configuration и DRY, предоставляет зрелую ORM Active Record и ускоряет разработку типовых CRUD-компонентов: занятий, групп, студентов, преподавателей, ролей и отчётов.
Альтернативами могли быть Django, Laravel и Spring Boot. Django обладает зрелой экосистемой Python, но для server-side realtime-обновлений обычно требует дополнительных компонентов либо отдельного SPA-фронтенда. Laravel удобен для CRUD и имеет Livewire, но не соответствует текущему Ruby-стеку проекта. Spring Boot силён в корпоративной Java-разработке, но увеличивает объём шаблонного кода и замедляет итерации для относительно компактного веб-приложения.
Ограничение Rails — более низкая «сырая» вычислительная производительность Ruby по сравнению с Java и некоторыми другими рантаймами. В данной задаче это не является определяющим фактором: основная нагрузка связана с I/O, транзакциями БД, фоновыми задачами и отчётами, а не с тяжёлыми вычислениями в веб-процессе.
### 4.2. Фронтенд-архитектура: Hotwire
Для фронтенда выбран **Hotwire**: Turbo Drive, Turbo Frames, Turbo Streams и Stimulus. Hotwire использует подход HTML over the wire: сервер возвращает HTML-фрагменты, а не JSON для последующей сборки интерфейса на клиенте. Это позволяет получить отзывчивый интерфейс без отдельного React/Vue SPA.
Для системы учёта посещаемости такой подход подходит естественно. Основные действия пользователя — открыть список занятий, сгенерировать QR-код, отметить присутствие, обновить статус студента, посмотреть отчёт. Эти сценарии хорошо ложатся на Turbo Frames и Turbo Streams: можно точечно обновлять строки таблиц, счётчики и статусы без полной перезагрузки страницы.
Ограничение Hotwire проявилось бы в приложении со сложным клиентским состоянием, например в графическом редакторе или интерфейсе с большим количеством drag-and-drop логики. Для «Attendance MEPhI» таких требований нет, поэтому отказ от отдельного SPA снижает сложность разработки и поддержки.
### 4.3. СУБД: PostgreSQL ### 4.3. СУБД: PostgreSQL
В качестве хранилища используется **PostgreSQL** [9]. Выбор обусловлен превосходством в сложных транзакционных операциях (подтверждено исследованием Salunke & Ouda [5]), полной ACID-совместимостью, наличием развитой ролевой модели и встроенной поддержкой типа JSONB (необходимого для метаданных Outbox-событий).
### 4.4. Фоновые задачи: Sidekiq + Redis В качестве основной СУБД выбрана **PostgreSQL**. Для проекта важны ACID-транзакции, конкурентные записи, развитые индексы, строгая типизация, JSONB для метаданных событий и зрелые механизмы работы с ролями и схемами.
Для асинхронной обработки применяется **Sidekiq** [8] (многопоточный обработчик) с **Redis** в качестве in-memory хранилища очередей. Sidekiq решает три задачи: реализацию Outbox-релея (`LessonVisitSyncWorker`), импорт справочников из внешних API без блокировки веб-процесса и генерацию тяжёлых отчётов для деканата.
### 4.5. Архитектурные паттерны и бизнес-логика PostgreSQL особенно важен для реализации Transactional Outbox: отметка посещаемости и запись события синхронизации должны выполняться атомарно. Если запись отметки прошла успешно, но событие не было создано, внешние реестры могут остаться несогласованными. Если событие было отправлено без успешной записи отметки, возникнет обратная ошибка. Транзакционная модель PostgreSQL позволяет избежать этих сценариев.
- **Service Objects:** Сложная логика (генерация QR, фиксация посещения) вынесена в специализированные классы (PORO) в папке `app/services` с единственным методом `call`. Это упрощает тестирование в изоляции.
- **Namespaced Controllers:** Контроллеры разделены по пространствам имён (`Admin::`, `Student::`, `Teacher::`), что технически обеспечивает строгую вузовскую ролевую модель.
- **Outbox Pattern:** Реализует надёжную синхронизацию с реестрами.
### 4.6. Интеграция с CAS и стилизация Сравнение с MySQL не должно строиться только на тезисе «PostgreSQL быстрее». Корректнее указать, что в цитируемом бенчмарке Salunke и Ouda PostgreSQL показал сильные результаты на ряде операций, а выбор для данного проекта дополнительно обоснован транзакционной целостностью и возможностями типов данных.
Аутентификация реализуется через протокол **CAS (Central Authentication Service)** [17] МИФИ. Приложение не видит пароль пользователя, снижая риски безопасности, и позволяет использовать существующие учётные записи.
Для стилизации выбран **Tailwind CSS** [18] в связке с локальными компонентами Bootstrap 5 [19]. Утилитарный подход Tailwind позволяет формировать минимальный production-бандл за счёт JIT-purge неиспользуемых классов. Деплой автоматизируется через Capistrano. ### 4.4. Фоновые задачи: Sidekiq и Redis
Для фоновой обработки выбран **Sidekiq** с **Redis** в качестве хранилища очередей. Sidekiq использует многопоточную модель и хорошо интегрируется с Rails-приложениями.
В проектируемой системе Sidekiq решает три задачи:
1. Выполнение Outbox-релея: периодическая обработка необработанных событий посещаемости и отправка их во внешние реестры.
2. Импорт справочников: загрузка расписания, групп, студентов и преподавателей из внутренних API без блокировки веб-интерфейса.
3. Генерация отчётов: подготовка сводок для деканата и кураторов в фоне.
Redis используется как очередь фоновых задач и может дополнительно применяться для кэширования часто запрашиваемых справочников. При этом Redis не является источником истины для посещаемости: все критичные данные должны храниться в PostgreSQL.
### 4.5. Аутентификация: CAS
Для аутентификации используется **CAS (Central Authentication Service)**. CAS — билетный протокол единого входа: пользователь вводит логин и пароль на доверенном CAS-сервере, после чего приложение получает service ticket и валидирует его. Веб-приложение не хранит и не обрабатывает пароль пользователя.
Для НИЯУ МИФИ это принципиально важно. Система посещаемости должна использовать существующие учётные записи студентов и преподавателей, не создавая отдельную базу паролей. CAS отвечает за аутентификацию, а авторизация остаётся задачей приложения: после входа система должна определить роль пользователя и доступные интерфейсы.
### 4.6. Архитектурные паттерны
**Service Objects.** Сложная бизнес-логика выносится из контроллеров и моделей в отдельные сервисные объекты. Примеры операций: импорт студентов, импорт расписания, генерация QR-кода, фиксация посещения, создание Outbox-события. Такой подход упрощает тестирование и снижает связанность кода.
**Namespaced Controllers.** Контроллеры разделяются по пространствам имён: `Admin::`, `Teacher::`, `Student::`, `Moderator::` или аналогичным. Это отражает ролевую модель в структуре приложения, упрощает маршрутизацию и снижает риск случайного смешения интерфейсов.
**Transactional Outbox.** При фиксации посещения приложение записывает основную отметку и событие синхронизации в одной транзакции. Затем фоновый воркер отправляет событие во внешний реестр. Если отправка не удалась, событие остаётся в outbox-таблице и будет обработано повторно. Получатель должен обеспечивать идемпотентность, например по уникальному идентификатору события.
### 4.7. Стилизация и деплой
Для стилизации выбран **Tailwind CSS**. Utility-first подход удобен для быстрого создания интерфейсов с небольшим production-бандлом и без жёсткой зависимости от визуального стиля готового UI-фреймворка. **Bootstrap 5** может использоваться точечно для готовых компонентов, если это не усложняет сборку и не создаёт конфликтов стилей.
Деплой целесообразно автоматизировать через **Capistrano**, так как это стандартный инструмент для Ruby/Rails-приложений с поддержкой релизов, rollback и разделения окружений. **Mise** может использоваться для фиксации версий Ruby, Node.js и сопутствующих рантаймов между локальной разработкой, CI и сервером.
Итоговый технологический стек:
| Компонент | Выбор | Обоснование |
|---|---|---|
| Backend | Ruby on Rails 7 | Быстрая разработка CRUD, MVC, зрелая экосистема |
| Frontend | Hotwire (Turbo + Stimulus) | Интерактивность без отдельного SPA |
| Database | PostgreSQL | ACID, JSONB, транзакции для Outbox |
| Background jobs | Sidekiq + Redis | Фоновые импорты, отчёты, Outbox-релей |
| Auth | CAS | SSO, приложение не хранит пароли |
| UI | Tailwind CSS, точечно Bootstrap | Быстрая стилизация и готовые компоненты |
| Deploy | Capistrano + Mise | Повторяемый деплой и контроль версий рантаймов |
--- ---
## Заключение ## Заключение
В ходе настоящей учебно-исследовательской работы проведён комплексный анализ существующих систем и методов учёта посещаемости студентов, а также обоснован технологический стек для разработки корпоративного веб-приложения для НИЯУ МИФИ (система «Attendance MEPhI»). В ходе учебно-исследовательской работы проведён анализ существующих систем учёта посещаемости, методов фиксации присутствия студентов и технологического стека для разработки системы «Attendance MEPhI».
Установлено, что ни одна из массовых российских (БАРС, 1С, iSpring) или зарубежных систем (MS Teams, Brightspace) не обеспечивает одновременно QR-самоотметку на очном занятии, интеграцию с корпоративным SSO (CAS), гарантированную Outbox-репликацию данных в реестры и поддержку сложной ролевой модели вуза. Это обосновывает необходимость разработки собственного решения. Установлено, что готовые российские и зарубежные продукты не закрывают совокупность требований НИЯУ МИФИ. Школьные электронные журналы ориентированы на модель класса и ручную отметку. ERP-решения уровня 1С:Университет избыточны для задачи QR-самоотметки и завязаны на собственную экосистему. LMS и сервисы видеоконференций фиксируют либо активность внутри курса, либо участие в онлайн-встрече, но не очную посещаемость в аудитории. QR-SaaS-сервисы создают риски внешнего хранения персональных данных и vendor lock-in. Открытые прототипы не обладают промышленной надёжностью и корпоративной интеграцией.
Метод QR-кодов признан оптимальным, так как он минимизирует требования к аудиторной инфраструктуре, обладает высокой скоростью и не создаёт правовых рисков в отличие от биометрической идентификации. Из рассмотренных методов фиксации посещаемости оптимальным признан QR-код с ограниченным временем жизни, одноразовым токеном и проверкой пользователя через CAS. Ручная отметка преподавателем должна оставаться резервным механизмом. RFID/NFC требует инфраструктурных затрат, биометрия создаёт высокие правовые риски, а геолокация недостаточно точна для аудиторного сценария и чувствительна с точки зрения приватности.
Выбранный технологический стек (Ruby on Rails 7, PostgreSQL, Hotwire, Sidekiq, Tailwind CSS) обеспечивает высокую скорость разработки, отзывчивый интерфейс без перегрузки клиентской части JavaScript-кодом и промышленную надёжность (через паттерн Transactional Outbox). Результаты исследования формируют обоснованную теоретическую и техническую базу для реализации системы в рамках последующей дипломной работы. Выбранный стек — Ruby on Rails 7, Hotwire, PostgreSQL, Sidekiq, Redis, CAS, Tailwind CSS, Capistrano и Mise — соответствует задаче разработки корпоративного веб-приложения. Rails и Hotwire ускоряют создание интерфейсов без отдельного SPA, PostgreSQL обеспечивает транзакционную целостность, Sidekiq реализует фоновые процессы, а Transactional Outbox снижает риск потери событий при синхронизации с внешними реестрами.
Результаты работы формируют обоснованную теоретическую и техническую базу для реализации системы «Attendance MEPhI» в рамках последующей проектной или дипломной работы.
--- ---
## Список использованной литературы ## Список использованной литературы
1. Ruby on Rails Guides: Getting Started with Rails // Ruby on Rails Documentation, 2024. URL: https://guides.rubyonrails.org/ (дата обращения: 20.05.2025). 1. Nuhi A., Memeti A., Imeri F., Çiço B. Smart Attendance System using QR Code // 2020 9th Mediterranean Conference on Embedded Computing (MECO), Budva, Montenegro, 2020. P. 1-4. DOI: 10.1109/MECO49872.2020.9134225.
2. Nuhi A., Memeti A., Imeri F., Çiço B. Smart Attendance System using QR Code // 2020 9th Mediterranean Conference on Embedded Computing (MECO), Budva, Montenegro, 2020, pp. 1–4. DOI: 10.1109/MECO49872.2020.9134225. 2. Глуховский К.С., Пирожков Р.В., Цвелик Е.А. Электронный журнал как элемент цифровой трансформации вуза // Инженерный вестник Дона. 2021. № 5. URL: https://ivdon.ru (дата обращения: 08.06.2026).
3. Глуховский К.С., Пирожков Р.В., Цвелик Е.А. Электронный журнал как элемент цифровой трансформации вуза // Инженерный вестник Дона. 2021. № 5. URL: https://ivdon.ru (дата обращения: 22.05.2025). 3. Методика автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий // КиберЛенинка. URL: https://cyberleninka.ru/article/n/metodika-avtomatizatsii-kontrolya-poseschaemosti-ochnyh-zanyatiy-po-opytu-kafedry-informatsionnyh-kompyuternyh-tehnologiy (дата обращения: 08.06.2026).
4. Richardson C. Microservices Patterns: With Examples in Java. Manning Publications, 2018. 520 с. 4. Richardson C. Microservices Patterns: With Examples in Java. Manning Publications, 2018. 520 p.
5. Salunke S.V., Ouda A. A Performance Benchmark for the PostgreSQL and MySQL Databases // Future Internet. 2024. Vol. 16, No. 10. Art. 382. DOI: 10.3390/fi16100382. 5. Transactional Outbox Pattern // AWS Prescriptive Guidance. URL: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html (дата обращения: 08.06.2026).
6. Даньшин К.А. Сравнительный анализ современных веб-фреймворков для разработки приложений // CyberLeninka, 2019. 6. Salunke S.V., Ouda A. A Performance Benchmark for the PostgreSQL and MySQL Databases // Future Internet. 2024. Vol. 16, No. 10. Article 382. DOI: 10.3390/fi16100382.
7. Hotwire: HTML Over The Wire // Hotwire Documentation. URL: https://hotwired.dev/ (дата обращения: 20.05.2025). 7. Getting Started with Rails // Ruby on Rails Guides. URL: https://guides.rubyonrails.org/getting_started.html (дата обращения: 08.06.2026).
8. Sidekiq: Simple, Efficient Background Processing for Ruby // Sidekiq Documentation. URL: https://sidekiq.org/ (дата обращения: 20.05.2025). 8. Hotwire: HTML Over The Wire // Hotwire. URL: https://hotwired.dev/ (дата обращения: 08.06.2026).
9. PostgreSQL 16 Documentation // PostgreSQL. URL: https://www.postgresql.org/docs/16/ (дата обращения: 20.05.2025). 9. Sidekiq: Simple, Efficient Background Jobs for Ruby // GitHub. URL: https://github.com/sidekiq/sidekiq (дата обращения: 08.06.2026).
10. БАРС.Образование — Электронная школа // БАРС Груп. URL: https://bars.group/products/education/ (дата обращения: 15.05.2025). 10. PostgreSQL Documentation // PostgreSQL. URL: https://www.postgresql.org/docs/ (дата обращения: 08.06.2026).
11. 1С:Университет — Возможности // 1С Образование. URL: https://solutions.1c.ru/catalog/university/features (дата обращения: 15.05.2025). 11. CAS Protocol // Apereo CAS. URL: https://apereo.github.io/cas/7.1.x/protocol/CAS-Protocol.html (дата обращения: 08.06.2026).
12. iSpring Learn: корпоративная платформа для обучения // iSpring Solutions. URL: https://www.ispring.ru/ispring-learn (дата обращения: 15.05.2025). 12. Tailwind CSS Documentation // Tailwind CSS. URL: https://tailwindcss.com/docs (дата обращения: 08.06.2026).
13. Manage the Attendance and Engagement Report for Meetings and Events in Microsoft Teams // Microsoft Learn. URL: https://learn.microsoft.com/en-us/microsoftteams/teams-analytics-and-reports/meeting-attendance-report (дата обращения: 16.05.2025). 13. Bootstrap 5 Documentation // Bootstrap. URL: https://getbootstrap.com/docs/5.3/ (дата обращения: 08.06.2026).
14. Track Attendance & View Live Stream Report // Google Classroom Help. URL: https://support.google.com/edu/classroom/answer/10090454 (дата обращения: 16.05.2025). 14. Capistrano: Remote Server Automation and Deployment Tool // Capistrano. URL: https://capistranorb.com/ (дата обращения: 08.06.2026).
15. Brightspace by D2L: Attendance Tool // D2L Documentation. URL: https://documentation.brightspace.com/ (дата обращения: 16.05.2025). 15. Mise: Polyglot Runtime Manager // Mise. URL: https://mise.jdx.dev/ (дата обращения: 08.06.2026).
16. Transactional Outbox Pattern // AWS Prescriptive Guidance. URL: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html (дата обращения: 18.05.2025). 16. Система «Учёт посещаемости студентов» // Электронный кампус ВВГУ. URL: https://www.vvsu.ru/e-campus/news/201301/ (дата обращения: 08.06.2026).
17. CAS Protocol Specification // Apereo Foundation. URL: https://apereo.github.io/cas/ (дата обращения: 18.05.2025). 17. БАРС.Образование — Электронная Школа: описание программного обеспечения // БАРС Груп. URL: https://bars.group/wp-content/uploads/2024/05/opisanie-elektronnaya-shkola.pdf (дата обращения: 08.06.2026).
18. Tailwind CSS Documentation // Official Site. URL: https://tailwindcss.com/docs/ (дата обращения: 20.05.2025). 18. 1С:Университет — Возможности // 1С. URL: https://solutions.1c.ru/catalog/university/features (дата обращения: 08.06.2026).
19. Bootstrap 5 Documentation // Official Site. URL: https://getbootstrap.com/docs/5.3/ (дата обращения: 20.05.2025). 19. iSpring LMS (iSpring Learn): платформа для онлайн-обучения // iSpring. URL: https://www.ispring.ru/ispring-learn (дата обращения: 08.06.2026).
20. Capistrano: Remote Server Automation and Deployment Tool // Official Documentation. URL: https://capistranorb.com/ (дата обращения: 20.05.2025). 20. On-Premise LMS for Effective & Secure Employee Training // iSpring Solutions. URL: https://www.ispringsolutions.com/ispring-learn/on-premise-lms (дата обращения: 08.06.2026).
21. Mise: Polyglot Runtime Manager // Official Documentation. URL: https://mise.jdx.dev/ (дата обращения: 20.05.2025). 21. Manage meeting attendance reports in Microsoft Teams // Microsoft Support. URL: https://support.microsoft.com/en-US/teams/meetings/manage-meeting-attendance-reports-in-microsoft-teams (дата обращения: 08.06.2026).
22. Методика автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий // КиберЛенинка. URL: https://cyberleninka.ru/article/n/metodika-avtomatizatsii-kontrolya-poseschaemosti-ochnyh-zanyatiy-po-opytu-kafedry-informatsionnyh-kompyuternyh-tehnologiy (дата обращения: 22.05.2025). 22. Track attendance & view Live stream report // Google Meet Help. URL: https://support.google.com/meet/answer/10090454?hl=en (дата обращения: 08.06.2026).
23. About Attendance // Brightspace Community. URL: https://community.d2l.com/brightspace/kb/articles/3609-about-attendance (дата обращения: 08.06.2026).
24. Qwickly Attendance Pro // D2L Brightspace IntegrationHub. URL: https://integrationhub.brightspace.com/details/qwickly-attendance-pro (дата обращения: 08.06.2026).
25. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», статья 11 «Биометрические персональные данные» // КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_61801/7336c78762a98b5f4f698b8c3800dca1111acc16/ (дата обращения: 08.06.2026).