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

arch-x1: 2026-06-08 15:28:30 | 1

Browse Source
This commit is contained in:
Dmitry
2026-06-08 15:28:30 +03:00
parent 7cf226e941
commit b1ffeb77b4
1 changed files with 354 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
00 Inbox/УИР_Учёт_посещаемости_МИФИ.md
+354
View File
@@ -0,0 +1,354 @@
# МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение высшего образования
## НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ЯДЕРНЫЙ УНИВЕРСИТЕТ «МИФИ»
*ИНСТИТУТ ИНТЕЛЛЕКТУАЛЬНЫХ КИБЕРНЕТИЧЕСКИХ СИСТЕМ*
КАФЕДРА КИБЕРНЕТИКИ
---
**Учебно-исследовательская работа на тему**
**«Обзор существующих решений и выбор инструментария для разработки системы учёта посещаемости студентов НИЯУ МИФИ»**
---
Выполнил студент: __________________________________
Группа: _______
Проверил: __________________________________
Оценка: ___________________
Дата: _____________________
Подпись: __________________
**Москва, 2025**
---
## Оглавление
- [Введение](#введение)
- [1. Обзор существующих систем учёта посещаемости студентов](#1-обзор-существующих-систем-учёта-посещаемости-студентов)
- [1.1. Российские системы](#11-российские-системы)
- [1.2. Зарубежные системы](#12-зарубежные-системы)
- [1.3. Сравнительный анализ аналогов](#13-сравнительный-анализ-аналогов)
- [2. Анализ методов фиксации посещаемости](#2-анализ-методов-фиксации-посещаемости-студентов)
- [3. Обзор существующих исследований](#3-обзор-существующих-исследований)
- [4. Выбор технологического стека](#4-выбор-технологического-стека)
- [Заключение](#заключение)
- [Список использованной литературы](#список-использованной-литературы)
---
## Введение
Цифровая трансформация высшего образования является одним из ключевых направлений государственной политики Российской Федерации. Согласно федеральному проекту «Цифровая образовательная среда», к 2025 году не менее 85% российских вузов должны располагать современными цифровыми инструментами управления учебным процессом. Вместе с тем значительная часть университетов по-прежнему использует бумажные журналы или устаревшие информационные системы для фиксации посещаемости студентов, что порождает целый ряд организационных и технических проблем.
В современном техническом вузе, таком как НИЯУ МИФИ, где одновременно обучаются тысячи студентов, учёт посещаемости занятий является обязательной административной процедурой. Ручное ведение журналов посещаемости существенно увеличивает нагрузку на преподавателей, снижает оперативность получения статистики деканатами и не позволяет автоматически синхронизировать данные с внешними информационными системами университета. Проблема усугубляется тем, что НИЯУ МИФИ располагает развитой корпоративной IT-инфраструктурой, включающей Единую систему аутентификации (CAS), внутренние реестры академических данных и API расписания — однако существующие на рынке решения, как правило, не обеспечивают нативной интеграции с подобными системами.
Дополнительную актуальность проблеме придаёт требование прозрачности: студент должен иметь возможность самостоятельно видеть свою историю посещений, а не узнавать о накопленных пропусках в конце семестра. Преподаватель, в свою очередь, должен иметь возможность как автоматически фиксировать посещение (через QR-код), так и вручную корректировать данные при необходимости. Куратор группы и деканат должны иметь доступ к сводной статистике, а администратор системы — к управлению справочниками и периодами обучения.
Существующие на российском рынке продукты в области электронных журналов (БАРС.Образование, 1С:Университет, iSpring Learn) либо ориентированы на модель «преподаватель вручную отмечает студентов», либо представляют собой тяжёлые ERP-системы, предназначенные для комплексного управления вузом, а не для точечного решения задачи учёта посещаемости. Зарубежные корпоративные платформы (Microsoft Teams, Google Classroom, Brightspace) фиксируют посещаемость как побочный продукт онлайн-встреч и не применимы к очным занятиям. Специализированные QR-SaaS-решения предполагают хранение данных у стороннего провайдера, что недопустимо с точки зрения политики обработки персональных данных в государственном вузе.
Таким образом, ниша «веб-приложение для QR-самоотметки посещаемости с интеграцией в корпоративный SSO вуза, синхронизацией с внешними реестрами и полной ролевой моделью» остаётся незаполненной, что и обусловливает необходимость разработки собственного решения для НИЯУ МИФИ.
**Целью** настоящей работы является определение подхода к разработке веб-приложения для автоматизированного учёта посещаемости студентов НИЯУ МИФИ, обеспечивающего прозрачную фиксацию присутствия на занятиях, интеграцию с корпоративными системами университета и надёжную синхронизацию данных с внешними реестрами.
**Объект исследования** — процесс учёта посещаемости студентов в НИЯУ МИФИ, включающий взаимодействие студентов, преподавателей, кураторов и администраторов в рамках учебного процесса.
**Предмет исследования** — методы и инструменты автоматизации фиксации посещаемости студентов, архитектурные паттерны и технологии для реализации интегрированного корпоративного веб-приложения.
**Задачи работы:**
- провести обзор существующих аналогов систем учёта посещаемости (российских и зарубежных) и выявить их принципиальные ограничения применительно к условиям НИЯУ МИФИ;
- проанализировать основные методы технической фиксации факта посещения студентом занятия и обосновать выбор QR-кодов как основного механизма самоотметки;
- изучить актуальные научные исследования в области автоматизированного учёта посещаемости и смежных задач (архитектурные паттерны, производительность СУБД, фоновая обработка) для формирования теоретической базы разработки;
- определить оптимальный технологический стек и архитектурные решения для разработки системы, обосновав выбор каждого компонента.
**Методологическую основу** исследования составляет системный анализ существующих программных решений и технологических подходов в области автоматизации учёта посещаемости в высших учебных заведениях. Исследование включает:
- сравнительный анализ коммерческих и открытых систем учёта посещаемости по шести критериям (QR-самоотметка, SSO-интеграция, Outbox-синхронизация, вузовская ролевая модель, on-premise-развёртывание, открытость кода);
- сравнительный анализ методов технической фиксации посещаемости (ручная отметка, RFID/NFC, QR-коды, биометрия, геолокация) по критериям применимости в условиях МИФИ;
- обзор рецензируемых научных публикаций (2015–2024) по теме QR-систем посещаемости, производительности СУБД, архитектурных паттернов для веб-приложений;
- обоснование выбора технологического стека на основании совокупности технических и организационных критериев.
**Практическая значимость** работы заключается в создании обоснованной методической базы для разработки реального веб-приложения учёта посещаемости студентов НИЯУ МИФИ. Проведённый анализ аналогов и методов позволяет разработчикам осознанно подходить к выбору архитектурных решений, избегая типовых ошибок — таких как зависимость от стороннего SaaS-провайдера, отсутствие гарантий доставки данных во внешние реестры или невозможность интеграции с корпоративным SSO. Результаты работы могут быть использованы как основа для проектирования аналогичных систем в других технических вузах.
Работа включает введение, четыре раздела, заключение и список использованной литературы. В первом разделе проводится анализ аналогов — как российских, так и зарубежных систем учёта посещаемости. Во втором разделе рассматриваются основные технические методы фиксации посещаемости. Третий раздел посвящён обзору существующих научных исследований. Четвёртый раздел содержит обоснование выбора технологического стека.
---
## 1. Обзор существующих систем учёта посещаемости студентов
Прежде чем приступить к проектированию новой системы, необходимо провести детальный анализ уже существующих решений. Это позволит выявить незаполненную нишу, сформулировать требования к разрабатываемому приложению и избежать воспроизведения известных недостатков. В рамках настоящего раздела рассматриваются как российские (БАРС.Образование, 1С:Университет, iSpring Learn, Дневник.ру), так и зарубежные (Microsoft Teams, Google Classroom/Meet, Brightspace/D2L) системы, а также специализированные QR-SaaS-решения и открытые разработки.
### 1.1. Российские системы
**БАРС.Образование — Электронная школа (БАРС Груп).** Система является одной из наиболее распространённых платформ электронного журнала и дневника в Российской Федерации; входит в реестр отечественного ПО и рекомендована к тиражированию в рамках программы «Электронный регион» [9]. Основная функциональность: электронный журнал (оценки, темы уроков, планирование учебного процесса), электронный дневник, учёт посещаемости — вручную учителем, расписание, отчётность. Вход осуществляется через учётную запись Госуслуг.
Ключевые ограничения БАРС.Образование применительно к НИЯУ МИФИ состоят в следующем. Во-первых, архитектура системы построена на модели «школа — класс — родитель», которая не масштабируется на вузовскую структуру «поток — группа — подгруппа — кафедра — деканат». Во-вторых, посещаемость фиксируется исключительно ручным способом: преподаватель (учитель) отмечает отсутствующих в журнале; студенческий QR-self-service не предусмотрен. В-третьих, система не обеспечивает интеграции с корпоративным CAS-сервером вуза — идентификация пользователей осуществляется через Госуслуги/СМЭВ. В-четвёртых, не предусмотрен механизм гарантированной передачи данных о посещаемости во внешние академические реестры (Outbox-синхронизация). Таким образом, БАРС.Образование является решением для общеобразовательных школ и не применимо в условиях корпоративного технического университета.
**1С:Университет (фирма «1С»).** Это отраслевое решение на платформе «1С:Предприятие 8.3», предназначенное для комплексного управления учебным процессом вуза [10]. В его функциональность входят: управление контингентом студентов, ведение личных дел и зачётных книжек, учёт успеваемости и посещаемости, формирование ведомостей, приёмная кампания. Система поддерживает территориально распределённые базы данных и широко используется в российских вузах.
Несмотря на формальную поддержку учёта посещаемости, 1С:Университет обладает рядом принципиальных ограничений в контексте задач данной работы. Ввод данных о посещаемости осуществляется вручную через АРМ преподавателя — студенческий QR-self-service и нативный веб-интерфейс самообслуживания не предусмотрены. Система представляет собой монолитную проприетарную ERP-платформу, интеграция которой с внешними системами реализуется через специализированные механизмы обмена 1С, а не через REST API и корпоративный SSO. Развёртывание и настройка требуют значительных затрат времени и компетенций в области платформы 1С, что делает систему неподходящей для разработки адаптированного решения с нуля.
**iSpring Learn (iSpring Solutions).** Российская корпоративная LMS (система управления обучением), используемая клиентами в 172 странах. Платформа доступна как в облачном исполнении, так и в варианте развёртывания на серверах клиента [11]. Функциональность включает: курсы и тесты, вебинары (с интеграцией с Zoom), отчёт «ILT Attendance» по посещаемости очных тренингов/вебинаров (преподаватель отмечает участников вручную после мероприятия), SSO, открытый API, мобильное приложение.
Принципиальное ограничение iSpring Learn состоит в том, что система предназначена для корпоративного обучения персонала, а не для учёта очной посещаемости студентов в традиционном понимании. Посещаемость является побочной функцией модуля «мероприятий» (ILT — Instructor-Led Training): преподаватель вручную отмечает присутствовавших после завершения мероприятия. Отсутствует QR-самоотметка студентов на занятии, нет модели «учебный поток вуза», не предусмотрена Outbox-синхронизация с академическими реестрами. SSO в iSpring реализован через стандартный SAML/OAuth, но не через протокол CAS, используемый в МИФИ.
**Дневник.ру, ЭлЖур, Сетевой город. Образование (NetSchool).** Перечисленные системы относятся к категории школьных электронных журналов, ориентированных на базовый сценарий: ручная отметка посещаемости учителем, модель «класс/группа», работа с родителями. Ни одна из систем не поддерживает QR-самоотметку, корпоративный SSO вуза или вузовскую ролевую модель. Упоминаются здесь исключительно для полноты обзора российского рынка.
### 1.2. Зарубежные системы
**Microsoft Teams — функция учёта посещаемости.** Платформа Microsoft Teams поддерживает автоматическую генерацию отчёта о посещаемости онлайн-встречи: фиксируются имена участников, время входа/выхода, длительность участия, а также показатели вовлечённости (реакции, поднятые руки, включённые камеры) [12]. Отчёт доступен организатору встречи и экспортируется в CSV.
Ключевое ограничение Microsoft Teams заключается в том, что система фиксирует присутствие на видеовстрече, а не на очном занятии в аудитории. При численности участников более 120 человек отчёт в реальном времени содержит лишь частичный список; полный список формируется только после завершения встречи. Критически важно, что «If the event organizer leaves the org, reports are permanently deleted and can't be retrieved» — отчёты безвозвратно уничтожаются при увольнении организатора, что неприемлемо для академического архива. Нет QR-механизма для очных занятий, нет интеграции с CAS МИФИ, нет вузовской ролевой модели.
**Google Classroom / Google Meet.** В Google Classroom нативная функция отметки посещаемости отсутствует; типичный обходной путь — создание формы в Google Forms. Функциональность фиксации посещаемости в Google Meet доступна только на платных редакциях: Education Plus и Teaching and Learning Upgrade. По справке Google, «Attendance tracking is available to Google Workspace Essentials, Business Plus, Enterprise Starter, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Plus and the Teaching and Learning Upgrade users» [13]. При этом формируемый отчёт относится к онлайн-встрече, а не к очному занятию.
**Brightspace (D2L) — инструмент Attendance.** Платформа Brightspace предоставляет базовый инструмент учёта посещаемости: реестры (registers), настраиваемые схемы статусов, порог предупреждения (Cause for Concern). Системная схема включает два статуса — present и absent; порог настраивается в процентах [14]. Преподаватель (или ассистент) отмечает студентов вручную — инструмент не является self-reporting. QR-самоотметка реализуется только через сторонние плагины (Qwickly Attendance, You-Attend) из D2L IntegrationHub, что означает дополнительные лицензионные затраты и зависимость от внешних провайдеров. Для внедрения системы потребуется развёртывание всей платформы Brightspace, что является избыточным для решения единственной задачи — учёта посещаемости.
**Специализированные QR/чек-ин SaaS-решения (OneTap, AccuClass, QR Attendee и аналоги).** Данный класс систем специально разработан для QR-фиксации посещаемости на мероприятиях и в учебных заведениях. Функциональность включает: генерацию QR-кодов, чек-ин студентов, импорт списков из Excel, аналитические дашборды, экспорт отчётов, иногда — геолокационную верификацию.
Несмотря на то что специализированные QR-SaaS-решения по набору функций ближе всего к требованиям данной работы, они обладают принципиальными ограничениями для применения в государственном университете. Данные хранятся в облаке стороннего провайдера, что не соответствует требованиям ФЗ-152 о локализации персональных данных и внутренней политике НИЯУ МИФИ. Отсутствует интеграция с CAS МИФИ — пользователи вынуждены создавать отдельные учётные записи. Нет механизма Outbox-синхронизации с внутренними академическими реестрами университета. Ролевая модель упрощена (обычно «организатор — участник») и не отражает вузовской иерархии. Закрытый исходный код исключает возможность адаптации под специфику МИФИ.
**Открытые проекты на GitHub (QR-Attendance-System, Check-by-QR и аналоги).** На платформе GitHub существует ряд прототипов QR-систем посещаемости, реализованных на различных стеках (Django, PHP/Bootstrap, Java/SQLite, .NET MAUI). Как правило, они поддерживают базовый сценарий: генерацию QR-кода, сканирование смартфоном, запись в базу. Некоторые включают геопроверку и защиту от повторной отметки. Однако все они являются студенческими или учебными прототипами: без промышленной надёжности, без гарантий доставки данных (Outbox), без CAS-интеграции, без полноценной ролевой модели.
### 1.3. Сравнительный анализ аналогов
На основании проведённого обзора составлена сравнительная таблица по шести ключевым критериям, определённым исходя из специфики задачи НИЯУ МИФИ.
| Система | QR-self-service | SSO/CAS | Outbox-синхр. | Ролевая модель вуза | On-premise | Open-source | Итог |
|---|---|---|---|---|---|---|---|
| БАРС.Образование | ✘ | ✘ | ✘ | Школьная | Зависит | ✘ | Не подходит |
| 1С:Университет | ✘ | ✘ | ✘ | Частично | ✔ | ✘ | Не подходит |
| iSpring Learn | ✘ | ✔ (SAML) | ✘ | Корпоративная | ✔ | ✘ | Не подходит |
| MS Teams | ✘ | ✔ (Azure AD) | ✘ | ✘ | ✘ | ✘ | Не подходит |
| Google Classroom | ✘ | ✔ (Google) | ✘ | ✘ | ✘ | ✘ | Не подходит |
| Brightspace | Через плагин | ✔ | ✘ | LMS | ✔ | ✘ | Не подходит |
| QR-SaaS (OneTap и др.) | ✔ | Частично | ✘ | ✘ | ✘ | ✘ | Не подходит |
| **Проектируемая система МИФИ** | **✔** | **✔ (CAS)** | **✔** | **Полная** | **✔** | **✔** | **Целевая** |
*Таблица 1 — Сравнительная таблица систем учёта посещаемости*
Проведённый анализ демонстрирует, что ни один из рассмотренных продуктов одновременно не обеспечивает QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO на протоколе CAS, гарантированную Outbox-синхронизацию с внутренними академическими реестрами, полную вузовскую ролевую модель (студент / преподаватель / куратор / администратор) и возможность on-premise развёртывания с открытым исходным кодом. Это и составляет обоснование разработки собственного решения, адаптированного к специфике НИЯУ МИФИ.
---
## 2. Анализ методов фиксации посещаемости студентов
Для обоснования выбора QR-кодов в качестве основного механизма фиксации посещаемости необходимо рассмотреть весь спектр существующих технических методов и оценить их применимость в условиях НИЯУ МИФИ.
**Ручная отметка преподавателем** является традиционным и наиболее распространённым методом. Преподаватель вносит в бумажный или электронный журнал сведения об отсутствующих (или присутствующих). Метод не требует никаких технических средств, однако имеет существенные недостатки: трудоёмкость (особенно на больших потоках), субъективность, задержка актуализации данных (нередко — до окончания занятия или дня), отсутствие цифрового следа для немедленной синхронизации. В условиях МИФИ, где размер лекционного потока может достигать 150–200 человек, ручная отметка занимает до 10–15 минут полезного учебного времени.
**RFID/NFC-карты.** Студент прикладывает студенческий билет (или смартфон с NFC) к считывателю при входе в аудиторию. Метод обеспечивает высокую скорость фиксации и не требует активных действий студента (кроме поднесения карты). Ограничения: необходимость установки считывателей в каждой аудитории (существенные инвестиции в инфраструктуру), риск передачи карты другому лицу, зависимость от состояния физической инфраструктуры. Используется в ряде крупных российских вузов (в первую очередь — в корпусах с турникетами на проходных), однако не обеспечивает granular-учёта по конкретной паре/дисциплине без дополнительной привязки к расписанию.
**QR-коды.** Преподаватель генерирует QR-код для конкретного занятия (привязанный к дате, времени, дисциплине и аудитории), отображает его на экране. Студент сканирует код смартфоном — приложение записывает факт посещения. Метод сочетает преимущества автоматизации и минимальных инфраструктурных требований: считыватели не нужны, достаточно смартфона у студента. Защита от злоупотреблений обеспечивается ограниченным временем жизни кода (токен действителен N минут) и привязкой к учётной записи студента (один токен — одна отметка). Для МИФИ метод особенно удобен, поскольку все студенты располагают смартфонами, а CAS-аутентификация позволяет исключить анонимные отметки.
**Биометрическая идентификация** (распознавание лица, отпечатка пальца). Теоретически обеспечивает наивысшую достоверность: каждый студент идентифицируется по физическому признаку, что исключает передачу идентификатора другому лицу. Однако практическое применение в российском вузе сопряжено с рядом серьёзных ограничений. Обработка биометрических персональных данных (ПДн специальной категории) требует отдельного согласия субъекта, соответствия требованиям ФЗ-152 и подзаконных актов Роскомнадзора, что существенно усложняет юридическое оформление. Инфраструктурные затраты (видеокамеры с достаточным разрешением и освещением в каждой аудитории) значительны. Риск отказа в обслуживании при недостаточном качестве изображения неприемлем для повседневного учёта.
**Геолокация.** Приложение на смартфоне студента фиксирует его местоположение и сверяет с координатами аудитории. Применяется как дополнительный механизм верификации в ряде зарубежных систем. Ограничения в условиях МИФИ: многокорпусный кампус с корпусами, расположенными вплотную (GPS-точность 5–15 м недостаточна для различения соседних аудиторий), ограниченный GPS-сигнал внутри зданий, необходимость постоянного доступа к геолокации — что вызывает справедливые опасения пользователей в плане приватности.
На основании проведённого анализа сформирована сравнительная оценка методов:
| Метод | Инфраструктура | Скорость | Защита от подмены | Правовые риски | Применимость в МИФИ |
|---|---|---|---|---|---|
| Ручная отметка | Минимальная | Низкая | Низкая | Минимальные | Базовая (fallback) |
| RFID/NFC | Высокая | Высокая | Средняя | Низкие | Ограниченная |
| **QR-коды** | **Минимальная** | **Высокая** | **Средняя** | **Низкие** | **Оптимальная** |
| Биометрия | Высокая | Высокая | Высокая | Высокие (ФЗ-152) | Не применима |
| Геолокация | Минимальная | Высокая | Низкая | Средние | Вспомогательная |
*Таблица 2 — Сравнительная оценка методов фиксации посещаемости*
Таким образом, метод QR-кодов является оптимальным для НИЯУ МИФИ: он не требует специальной инфраструктуры в аудиториях, обеспечивает достаточную скорость отметки (5–10 секунд на студента), легко интегрируется с существующей CAS-аутентификацией и не создаёт правовых рисков, связанных с обработкой биометрических данных. Ручная отметка преподавателем сохраняется как резервный (fallback) механизм. Данный подход подтверждается результатами научных исследований, рассматриваемых в следующем разделе.
---
## 3. Обзор существующих исследований
Анализ актуальных научных публикаций по теме автоматизации учёта посещаемости и смежным техническим задачам позволяет сформировать теоретическую базу для проектирования системы и избежать ранее выявленных проблем. Ниже рассматриваются шесть работ, непосредственно или косвенно связанных с темой настоящего исследования.
### *Nuhi A., Memeti A., Imeri F., Çiço B. «Smart Attendance System using QR Code»*
Авторы представили разработку автоматизированной системы учёта посещаемости студентов на основе QR-кодов для применения в учебных заведениях [2]. Система реализована в виде веб-приложения: преподаватель генерирует динамический QR-код для конкретного занятия, студент сканирует его смартфоном, сервер фиксирует отметку посещения с привязкой к учётной записи. Защита от злоупотреблений обеспечивается ограниченным временем действия кода и механизмом однократного использования токена.
К достоинствам предложенного подхода авторы относят: минимальные требования к инфраструктуре (не требуется специальное оборудование в аудиториях), высокую скорость отметки, возможность offline-генерации кодов при нестабильном соединении. Проведённые испытания подтвердили работоспособность системы в аудиторных условиях.
Ограничения работы связаны с отсутствием интеграции с корпоративными системами аутентификации и реестрами вуза: система функционирует автономно, что затрудняет синхронизацию с учебными планами и внешними базами данных академической успеваемости. Авторы также не рассматривают механизмы надёжной доставки данных во внешние системы и не предоставляют анализа архитектурных паттернов для промышленного развёртывания.
Результаты данного исследования подтверждают принципиальную применимость QR-метода для учёта посещаемости в высших учебных заведениях и служат теоретической базой для выбора механизма самоотметки в проектируемой системе МИФИ. Выявленные ограничения — отсутствие SSO-интеграции и синхронизации с реестрами — непосредственно учтены при постановке задачи настоящей дипломной работы.
### *Глуховский К.С., Пирожков Р.В., Цвелик Е.А. «Электронный журнал как элемент цифровой трансформации вуза»*
Работа посвящена опыту разработки и внедрения электронного журнала посещаемости и академической успеваемости в качестве модуля Электронной информационно-образовательной среды (ЭИОС) в Волгодонском инженерно-техническом институте НИЯУ МИФИ [3]. Система реализована как часть единой цифровой среды вуза и интегрирована с корпоративными справочниками.
Авторы подробно описывают процесс импорта академических данных (расписание, группы, студенты, дисциплины) из центральных систем вуза, структуру ролей пользователей (студент, преподаватель, деканат, администратор), механизм формирования отчётов по посещаемости. Работа имеет особое значение для настоящего исследования как отраслевой аналог из структуры НИЯУ МИФИ, демонстрирующий типовые задачи (импорт данных расписания, разграничение ролей, отчётность для деканата) применительно к инфраструктуре университета.
Ограничения описанного решения: не предусмотрена студенческая QR-самоотметка (посещаемость фиксируется преподавателем); отсутствует описание механизма синхронизации с внешними реестрами и гарантий доставки данных. Выявленные недостатки конкретизируют требования к проектируемой системе МИФИ в части добавления QR-механизма и реализации Outbox-паттерна.
### *Salunke S.V., Ouda A. «A Performance Benchmark for the PostgreSQL and MySQL Databases»*
В работе проводится сравнительное нагрузочное тестирование СУБД PostgreSQL и MySQL по операциям INSERT, SELECT (с/без WHERE) и UPDATE на наборах данных объёмом до 1 миллиона записей [5]. Эксперименты выполнены в идентичных условиях аппаратного и программного обеспечения.
Ключевые результаты: на операциях INSERT для 1 миллиона записей PostgreSQL показал время выполнения 0,6–0,8 мс, MySQL — 9–12 мс (в 13–15 раз медленнее). На операциях SELECT с фильтром WHERE PostgreSQL продемонстрировал время 0,09–0,13 мс против 0,9–1 мс для MySQL (примерно в 9 раз быстрее).
Авторы честно оговаривают ограничения: на простых OLTP SELECT при небольших объёмах данных и оптимизированных индексах разница может быть менее выражена; результаты зависят от профиля нагрузки. Тем не менее для задач, требующих сложных транзакций (Outbox-запись, ACID-гарантии при одновременной работе сотен студентов) и богатства типов данных (JSONB, массивы), PostgreSQL является обоснованным выбором. Данное исследование используется в разделе 4 для обоснования выбора PostgreSQL в качестве СУБД проектируемой системы.
### *Richardson C. «Microservices Patterns: With Examples in Java»*
Монография Криса Ричардсона является фундаментальным изданием в области архитектурных паттернов для распределённых систем [4]. Глава 3 посвящена паттерну Transactional Outbox, решающему проблему «двойной записи» (dual write) — несогласованности данных при одновременной записи в базу данных и отправке сообщения внешней системе.
Суть паттерна: при выполнении бизнес-операции (например, фиксации посещения) событие записывается в специальную таблицу-«почтовый ящик» (outbox) в той же атомарной транзакции, что и основные данные. Отдельный процесс-релей (publisher) асинхронно считывает необработанные записи из outbox-таблицы и передаёт их во внешние системы. При сбое релей повторяет попытку (гарантия at-least-once); получатели должны быть идемпотентны. Паттерн устраняет необходимость в распределённых транзакциях (2PC) и гарантирует, что ни одно событие не будет потеряно даже при временной недоступности внешней системы.
Ограничение паттерна: гарантия at-least-once предполагает, что одно и то же событие может быть доставлено более одного раза; получатель обязан обеспечить идемпотентную обработку. Для проектируемой системы МИФИ это означает, что при проектировании API внешних реестров следует предусмотреть механизм дедупликации по идентификатору события.
Данная работа является первичным теоретическим источником для обоснования архитектурного решения, реализованного в проектируемой системе через таблицу `update_attendance_students_outbox` и фоновый воркер `LessonVisitSyncWorker`.
### *Методика автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий*
Данная работа, опубликованная в открытом доступе на платформе КиберЛенинка, описывает практический опыт кафедры ИКТ российского технического вуза по автоматизации контроля посещаемости очных занятий. Авторы рассматривают переход от бумажных журналов к цифровому учёту с использованием доступных инструментов: Google-таблицы в связке с QR-сканерами.
Ключевые наблюдения авторов, актуальные для настоящей работы: проблема автоматизации наиболее остро проявляется на крупных потоках (100+ студентов), где ручная отметка занимает значительное время; преподаватели позитивно оценивают делегирование процедуры отметки самим студентам (самоотметку). Авторы также отмечают необходимость интеграции с корпоративными справочниками студентов и расписанием для исключения ошибок при ручном вводе данных.
Ограничение: использование Google-таблиц предполагает хранение данных у иностранного поставщика, что создаёт риски соответствия требованиям ФЗ-152 о локализации персональных данных. В проектируемой системе МИФИ аналогичный функционал реализуется на собственной инфраструктуре вуза с развёртыванием через Capistrano.
### *AWS Prescriptive Guidance. «Transactional Outbox Pattern»*
Руководство по архитектурным паттернам Amazon Web Services детально описывает транзакционный Outbox-паттерн применительно к cloud-native приложениям [15]. Документ формализует компоненты паттерна: бизнес-сервис (атомарно пишет в БД и outbox), relayer (опрашивает outbox и публикует события), event consumer (обрабатывает события идемпотентно).
В документе подчёркивается, что данный паттерн решает фундаментальную проблему надёжности в микросервисных и распределённых системах: невозможность атомарно выполнить запись в базу данных и отправку сообщения брокеру без использования двухфазной фиксации (2PC), которая неприменима в современных высоконагруженных системах из-за сложности реализации и низкой производительности.
Рекомендации AWS по реализации паттерна учтены при проектировании модуля синхронизации проектируемой системы: таблица outbox включает поля `id` (уникальный идентификатор события), `payload` (JSON с данными посещения), `status` (новое/отправлено), `created_at`, `sent_at`. Воркер периодически запрашивает записи со статусом «новое», отправляет их в целевую систему и обновляет статус. При сбое статус остаётся «новое» и событие будет повторно обработано на следующем цикле.
---
## 4. Выбор технологического стека
Выбор оптимального технологического стека для разработки системы учёта посещаемости представляет собой комплексную инженерную задачу, требующую оценки каждого компонента по критериям производительности, зрелости экосистемы, соответствия задаче и скорости разработки. В данном разделе проводится сравнительный анализ альтернативных технологий и обосновывается итоговый выбор.
### 4.1. Веб-фреймворк: Ruby on Rails 7
Для реализации бэкенда рассматривались четыре ведущих веб-фреймворка: Ruby on Rails (Ruby), Django (Python), Laravel (PHP) и Spring Boot (Java).
**Django (Python)** обеспечивает высокую производительность Python-рантайма, богатую экосистему библиотек для науки о данных и зрелую ORM (Django ORM). Основным ограничением для данной задачи является отсутствие встроенного, полноценно интегрированного механизма для server-side real-time обновлений интерфейса (аналога Hotwire в Rails): подобный функционал требует использования Django Channels (отдельный компонент, значительно усложняющий стек) или SPA-фронтенда.
**Laravel (PHP)** демонстрирует высокую скорость разработки CRUD-приложений благодаря выразительному синтаксису и богатой экосистеме. Livewire — аналог Hotwire для Laravel — позволяет создавать реактивные интерфейсы без SPA. Однако PHP традиционно требует настройки веб-сервера (Apache/Nginx + PHP-FPM), что усложняет процедуру деплоя по сравнению с Rails+Capistrano. Кроме того, в существующей инфраструктуре проекта уже использован стек Ruby.
**Spring Boot (Java)** является стандартом корпоративной разработки на JVM: строгая типизация, высокая производительность, зрелая экосистема. Ограничения: значительный объём boilerplate-кода при реализации CRUD-операций, медленный цикл разработки и тестирования по сравнению с Ruby/Python, отсутствие нативного аналога Hotwire.
**Ruby on Rails 7** реализует строгий паттерн MVC, принципы Convention over Configuration и DRY, что ускоряет разработку типовых CRUD-компонентов (CRUD занятий, групп, студентов) и снижает объём шаблонного кода. Начиная с версии 7.0, Hotwire (Turbo + Stimulus) интегрирован в Rails «из коробки» [1], что позволяет реализовать отзывчивый интерфейс без выделенного SPA-фронтенда. Зрелая экосистема gem-пакетов (`rack-cas`, `pagy`, `paper_trail`, `rqrcode`, `httparty`) обеспечивает готовые реализации всех необходимых функций без написания дополнительного кода. Rails используется в production крупнейшими технологическими компаниями (GitHub, Shopify, Basecamp), что подтверждает его пригодность для промышленного применения.
*Честный контраргумент:* Ruby как язык уступает по «сырой» вычислительной производительности оптимизированному Python/Java; MRI-интерпретатор Ruby использует GIL (Global Interpreter Lock), ограничивая параллелизм в рамках одного процесса. Эти ограничения компенсируются фоновой обработкой тяжёлых задач через Sidekiq (многопоточная модель на уровне воркеров), кэшированием и горизонтальным масштабированием приложения.
### 4.2. Фронтенд: Hotwire (Turbo + Stimulus)
Hotwire («HTML Over The Wire») — это набор технологий для создания интерактивных веб-интерфейсов без использования полноценного SPA-фреймворка [6]. Концепция: вместо того чтобы передавать JSON и перестраивать DOM на клиенте (React/Vue), сервер возвращает готовые HTML-фрагменты, которые встраиваются в страницу.
Состав Hotwire:
- **Turbo Drive** — навигация по страницам без полной перезагрузки (аналог pjax);
- **Turbo Frames** — изолированные обновляемые области страницы (загрузка фрагмента без перезагрузки всего layout);
- **Turbo Streams** — точечные DOM-операции (append, prepend, replace, remove), в том числе через WebSocket для realtime-обновлений;
- **Stimulus** — минималистичный JS-фреймворк для добавления поведения через data-атрибуты без перестройки архитектуры.
Для проектируемой системы учёта посещаемости Hotwire особенно подходит по следующим причинам. Задача не требует сложного клиентского состояния (не является полноценным SPA): основные операции — загрузка списка присутствующих, отметка студента, обновление строки — идеально ложатся на модель Turbo Frames/Streams. Backend-ориентированная команда разработки не обязана владеть React/TypeScript. Кодовая база остаётся монолитной, что упрощает поддержку и деплой.
*Ограничение:* для интерфейсов с чрезвычайно высокой интерактивностью и сложным клиентским состоянием (например, drag-and-drop конструкторы, сложные формы с зависимыми полями) Hotwire менее удобен, чем React. В контексте данного проекта таких требований нет.
### 4.3. СУБД: PostgreSQL
PostgreSQL — полнофункциональная объектно-реляционная СУБД с открытым исходным кодом, поддерживающая ACID-транзакции через механизм MVCC (Multiversion Concurrency Control) [8]. Для проектируемой системы рассматривались PostgreSQL и MySQL.
По результатам сравнительного бенчмарка Salunke & Ouda (2024) [5], PostgreSQL демонстрирует превосходство в транзакционных операциях: на 1 миллионе записей INSERT выполняется в 13–15 раз быстрее, SELECT с WHERE — в 9 раз быстрее, чем в MySQL. Для системы учёта посещаемости, где сотни студентов одновременно фиксируют посещение (пиковая нагрузка в начале лекции), высокая производительность параллельных INSERT критически важна.
Дополнительные аргументы в пользу PostgreSQL: поддержка типа JSONB (используется при хранении метаданных Outbox-событий), строгая типизация и богатство встроенных типов, развитая система ролей и схем (что соответствует многоролевой архитектуре системы), логическая репликация для потенциального горизонтального масштабирования, нативная поддержка полнотекстового поиска.
*Оговорка:* на простых OLTP-запросах с небольшими объёмами данных и оптимизированными индексами MySQL может демонстрировать сопоставимую производительность. Выбор PostgreSQL обусловлен прежде всего транзакционной целостностью (критичной для Outbox-паттерна) и богатством типов данных, а не исключительно скоростью.
### 4.4. Фоновые задачи: Sidekiq + Redis
Sidekiq — многопоточный обработчик фоновых задач для Ruby, использующий Redis как хранилище очередей [7]. Выбор Sidekiq обусловлен несколькими факторами: тесная интеграция с Rails через Active Job (переключение адаптера одной строкой конфигурации), многопоточная модель (эффективнее по памяти, чем процессные аналоги Resque и Delayed Job), встроенные очереди с приоритетами, автоматические повторы с экспоненциальной задержкой, веб-интерфейс мониторинга Sidekiq Web UI.
В проектируемой системе Sidekiq решает три критически важные задачи:
1. **Реализация Outbox-релея:** воркер `LessonVisitSyncWorker` периодически (через Sidekiq Scheduler) опрашивает outbox-таблицу и отправляет необработанные события в целевые системы.
2. **Тяжёлые импорты:** синхронизация расписания, групп и студентов из API МИФИ выполняется в фоне без блокировки основного веб-процесса.
3. **Генерация отчётов** по запросу деканата.
Redis выполняет двойную роль: хранилище очередей для Sidekiq и кэш приложения (кэширование часто запрашиваемых данных расписания, справочников).
### 4.5. Аутентификация: CAS (Central Authentication Service)
Central Authentication Service (CAS) — протокол единого входа (SSO), разработанный в Йельском университете и поддерживаемый Apereo Foundation [16]. При аутентификации через CAS приложение перенаправляет пользователя на центральный CAS-сервер; пользователь вводит логин/пароль там, не передавая их приложению. После успешной аутентификации CAS выдаёт одноразовый service ticket, который приложение валидирует через защищённый канал. Приложение не хранит пароли пользователей.
CAS является стандартом SSO в университетской среде: его используют сотни ведущих вузов мира. В НИЯУ МИФИ CAS обеспечивает единый вход в корпоративные сервисы — от почты до личного кабинета. Интеграция проектируемой системы с CAS МИФИ через gem `rack-cas` позволяет использовать существующие учётные записи студентов и преподавателей без создания дополнительных паролей.
### 4.6. Архитектурные паттерны
**Service Objects.** Паттерн предполагает вынос сложной бизнес-логики из моделей и контроллеров в специализированные объекты (PORO — plain old Ruby objects), размещаемые в `app/services`. Каждый сервис отвечает за одну операцию (принцип единственной ответственности) и имеет единственный публичный метод `call`. Применяется для: `ImportStudentsService` (импорт студентов из API МИФИ), `ImportLessonsService` (импорт расписания), `CreateLessonVisitService` (логика фиксации посещения). Преимущества: тестируемость в изоляции, чёткое разделение ответственности, «тонкие» модели и контроллеры.
**Namespaced Controllers.** Разделение контроллеров по пространствам имён (`Admin::`, `Moderator::`, `Student::`) изолирует ролевые интерфейсы, упрощает маршрутизацию (`resources :lessons` вложены в соответствующий namespace) и авторизацию (`before_action :require_admin` в базовом контроллере пространства имён). Паттерн естественно поддерживает вузовскую ролевую модель (студент / преподаватель / куратор / администратор).
**Outbox Pattern.** Как описано в разделе 3 со ссылкой на Richardson [4] и AWS [15], паттерн Transactional Outbox обеспечивает гарантию at-least-once для доставки событий посещаемости во внешние реестры МИФИ. Реализован через таблицу `update_attendance_students_outbox` и фоновый воркер `LessonVisitSyncWorker` (Sidekiq), периодически публикующий необработанные записи.
### 4.7. CSS: Tailwind CSS
Tailwind CSS — utility-first CSS-фреймворк, интегрированный в Rails 7 через gem `tailwindcss-rails` [17]. Подход «utility-first» предполагает описание стилей непосредственно в HTML-разметке через семантические классы (`flex`, `p-4`, `text-gray-700`). Ключевые преимущества для данного проекта: существенно меньший production-бандл за счёт JIT-purge (удаляются все неиспользуемые классы); полная кастомизация через `tailwind.config.js` без переопределения базовых стилей фреймворка; нативная интеграция с Rails 7 (`rails new myapp --css tailwind`).
Bootstrap 5 используется для отдельных UI-компонентов, где применение готовых составных элементов (модальные окна, дропдауны) более уместно. Такое сочетание позволяет использовать сильные стороны обоих инструментов, что соответствует практике итеративной разработки.
### 4.8. Деплой: Capistrano + Mise
Capistrano — инструмент автоматизации деплоя для Ruby-приложений, реализующий стратегию rolling deployment с сохранением предыдущих релизов [19]. Поддерживаются окружения staging и production; деплой сводится к одной команде `cap production deploy`. Mise — менеджер версий рантаймов (Ruby, Node.js), обеспечивающий идентичность версий между локальной разработкой, CI и production-сервером [20].
---
## Заключение
В ходе настоящей учебно-исследовательской работы проведён комплексный анализ существующих систем и методов учёта посещаемости студентов, а также обоснован технологический стек для разработки корпоративного веб-приложения для НИЯУ МИФИ.
По результатам обзора восьми российских и зарубежных систем (БАРС.Образование, 1С:Университет, iSpring Learn, Microsoft Teams, Google Classroom, Brightspace, QR-SaaS и открытые проекты) установлено, что ни одна из рассмотренных систем не обеспечивает одновременно QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO на протоколе CAS, гарантированную Outbox-синхронизацию с внутренними академическими реестрами и полную вузовскую ролевую модель. Данный вывод обосновывает необходимость разработки собственного решения, адаптированного к специфике инфраструктуры НИЯУ МИФИ.
Из пяти рассмотренных методов технической фиксации посещаемости (ручная отметка, RFID/NFC, QR-коды, биометрия, геолокация) оптимальным для условий МИФИ признан метод QR-кодов. Он сочетает минимальные инфраструктурные требования (не требует оборудования в аудиториях), высокую скорость отметки, приемлемый уровень защиты от подмены через механизм одноразовых токенов и отсутствие правовых рисков, связанных с обработкой биометрических данных.
Обзор шести актуальных научных публикаций подтвердил применимость QR-подхода для учёта посещаемости (Nuhi et al., 2020), выявил типовые задачи, стоящие перед вузами при разработке подобных систем в контексте НИЯУ МИФИ (Глуховский и др., 2021), обосновал выбор PostgreSQL как СУБД для высококонкурентных транзакционных операций (Salunke & Ouda, 2024) и сформировал теоретическую базу для реализации Outbox-паттерна (Richardson, 2018; AWS Prescriptive Guidance).
Определён следующий технологический стек: Ruby on Rails 7 (бэкенд, MVC, Convention over Configuration), Hotwire/Turbo/Stimulus (фронтенд без SPA), PostgreSQL (СУБД с ACID-транзакциями и поддержкой JSONB), Redis + Sidekiq (фоновые задачи и Outbox-релей), rack-cas (интеграция с CAS МИФИ), Tailwind CSS + Bootstrap (стилизация). Архитектурные паттерны: Service Objects (изоляция бизнес-логики), Namespaced Controllers (ролевое разделение), Transactional Outbox (надёжная синхронизация), MVC (структурирование приложения). Деплой — через Capistrano + Mise.
Результаты работы формируют обоснованную теоретическую базу для реализации системы в рамках дипломной работы и могут служить методической основой для разработки аналогичных систем в других технических вузах с корпоративной IT-инфраструктурой на основе протокола CAS.
---
## Список использованной литературы
1. Ruby on Rails Guides: Getting Started with Rails // Ruby on Rails Documentation, 2024. URL: https://guides.rubyonrails.org/ (дата обращения: 20.05.2025).
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.
3. Глуховский К.С., Пирожков Р.В., Цвелик Е.А. Электронный журнал как элемент цифровой трансформации вуза // Инженерный вестник Дона. 2021. № 5. URL: https://ivdon.ru (дата обращения: 22.05.2025).
4. Richardson C. Microservices Patterns: With Examples in Java. Manning Publications, 2018. 520 с.
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.
6. Hotwire: HTML Over The Wire // Hotwire Documentation. URL: https://hotwired.dev/ (дата обращения: 20.05.2025).
7. Sidekiq: Simple, Efficient Background Processing for Ruby // Sidekiq Documentation. URL: https://sidekiq.org/ (дата обращения: 20.05.2025).
8. PostgreSQL: The World's Most Advanced Open Source Relational Database // PostgreSQL 16 Documentation. URL: https://www.postgresql.org/docs/16/ (дата обращения: 20.05.2025).
9. БАРС.Образование — Электронная школа // БАРС Груп. URL: https://bars.group/products/education/ (дата обращения: 15.05.2025).
10. 1С:Университет — Возможности // 1С Образование. URL: https://solutions.1c.ru/catalog/university/features (дата обращения: 15.05.2025).
11. iSpring Learn: корпоративная платформа для обучения // iSpring Solutions. URL: https://www.ispring.ru/ispring-learn (дата обращения: 15.05.2025).
12. 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. Track Attendance & View Live Stream Report // Google Classroom Help. URL: https://support.google.com/edu/classroom/answer/10090454 (дата обращения: 16.05.2025).
14. Brightspace by D2L: Attendance Tool // D2L Documentation. URL: https://documentation.brightspace.com/ (дата обращения: 16.05.2025).
15. 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. CAS Protocol Specification // Apereo Foundation. URL: https://apereo.github.io/cas/ (дата обращения: 18.05.2025).
17. Tailwind CSS Documentation // Official Site. URL: https://tailwindcss.com/docs/ (дата обращения: 20.05.2025).
18. Bootstrap 5 Documentation // Official Site. URL: https://getbootstrap.com/docs/5.3/ (дата обращения: 20.05.2025).
19. Capistrano: Remote Server Automation and Deployment Tool // Official Documentation. URL: https://capistranorb.com/ (дата обращения: 20.05.2025).
20. Mise: Polyglot Runtime Manager // Official Documentation. URL: https://mise.jdx.dev/ (дата обращения: 20.05.2025).
21. Методика автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий // КиберЛенинка. URL: https://cyberleninka.ru/article/n/metodika-avtomatizatsii-kontrolya-poseschaemosti-ochnyh-zanyatiy-po-opytu-kafedry-informatsionnyh-kompyuternyh-tehnologiy (дата обращения: 22.05.2025).
22. Pagy: Fast, Ultralight, Agnostic, Extendable Pagination for Ruby // GitHub. URL: https://github.com/ddnexus/pagy (дата обращения: 21.05.2025).
23. Paper Trail: Track Changes to your Rails Models // GitHub. URL: https://github.com/paper-trail-gem/paper_trail (дата обращения: 21.05.2025).
24. rqrcode: A Ruby Library for Encoding QR Codes // GitHub. URL: https://github.com/whomwah/rqrcode (дата обращения: 21.05.2025).
25. HTTParty: Makes HTTP Fun Again // GitHub. URL: https://github.com/jnunemaker/httparty (дата обращения: 21.05.2025).