ada/SecondBrain
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
SecondBrain/02 Projects/Наука/НИР/УИР_Сводный_вариант.md
T
Dmitry f67061a06a ada-pc: 2026-06-14 20:51:13 | 1 
Affected files:
02 Projects/Наука/НИР/УИР_Сводный_вариант.md
2026-06-14 20:51:14 +03:00

250 lines
50 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: "УИР: Обзор систем учёта посещаемости студентов НИЯУ МИФИ"
status: stable
type: document
tags:
- уир
- мифи
- разработка
created: 2026-06-08
updated: 2026-06-14
---
# УИР\_Сводный\_вариант
## Введение
Цифровизация управления учебным процессом требует от университета не только электронного хранения данных, но и прозрачной, проверяемой фиксации факта присутствия студентов на занятиях. Согласно исследованию [\[Электронный журнал как элемент цифровой трансформации вуза\]](https://ivdon.ru/back_media/uploads/article/pdf/IVD_47__4_glukhovsky_pirozhkov_tsvelik.pdf_048169e65f.pdf) средний балл студента обратно зависит от процента пропущенных им занятий. В крупном техническом вузе, традиционные бумажные журналы и разрозненные электронные таблицы создают существенные организационные ограничения: увеличивают нагрузку на преподавателей, повышают риск потери или несвоевременного внесения данных, затрудняют оперативное получение статистики деканатами и не позволяют автоматически синхронизировать сведения с внутренними информационными системами университета.
Проблема особенно актуальна для НИЯУ МИФИ, поскольку университет располагает развитой корпоративной IT-инфраструктурой: единой системой аутентификации, внутренними академическими реестрами, расписанием и ролевыми моделями доступа. Готовая система учёта посещаемости для такого окружения должна не просто фиксировать отметку, а работать как часть корпоративного контура: использовать существующие учётные записи, корректно разделять роли студентов, преподавателей, кураторов, деканата и администраторов, а также гарантированно передавать события посещаемости во внешние реестры.
Дополнительную актуальность задаче придаёт требование прозрачности:
1) студент должен иметь возможность видеть собственную историю посещений до окончания семестра;
2) преподаватель должен иметь быстрый механизм фиксации присутствия и возможность ручной корректировки спорных случаев;
3) куратор и деканат должны получать сводную аналитику без ручной консолидации журналов.
Проведённый анализ показывает, что массовые российские и зарубежные решения не сочетают одновременно ключевые свойства, необходимые корпоративному вузу: QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO на базе CAS, гарантированную синхронизацию с внутренними реестрами и полноценную вузовскую ролевую модель. Это обосновывает необходимость разработки собственной системы.
**Целью** настоящей работы является определение подхода к разработке веб-приложения для автоматизированного учёта посещаемости студентов НИЯУ МИФИ, обеспечивающего прозрачную фиксацию присутствия на занятиях, интеграцию с корпоративными системами университета и надёжную синхронизацию данных с внешними реестрами.
**Объект исследования** — процесс учёта посещаемости студентов в НИЯУ МИФИ, включающий взаимодействие студентов, преподавателей, кураторов, деканата и администраторов в рамках учебного процесса.
**Предмет исследования** — методы и инструменты автоматизации фиксации посещаемости студентов, архитектурные паттерны и технологии для реализации интегрированного корпоративного веб-приложения.
**Задачи работы:**
1. Провести обзор существующих аналогов систем учёта посещаемости и выявить их ограничения применительно к условиям НИЯУ МИФИ.
2. Проанализировать основные методы технической фиксации факта посещения студентом занятия.
3. Обосновать выбор QR-кодов как основного механизма самоотметки.
4. Изучить научные и отраслевые источники по автоматизированному учёту посещаемости, производительности СУБД и архитектурным паттернам надёжной синхронизации.
5. Определить технологический стек и архитектурные решения для разработки системы.
**Методологическую основу** исследования составляет системный анализ существующих программных решений и технологических подходов в области автоматизации учёта посещаемости. В работе используются сравнительный анализ коммерческих и открытых систем, анализ методов фиксации посещаемости, обзор научных публикаций и проверка технических решений по официальной документации.
**Практическая значимость** работы заключается в формировании обоснованной методической базы для последующей разработки собственной системы. Результаты анализа позволяют избежать типовых ошибок: зависимости от внешнего SaaS-провайдера, отсутствия гарантий доставки данных, невозможности интеграции с корпоративным SSO и смешения ролей пользователей.
## 1. Обзор существующих систем учёта посещаемости студентов
Перед проектированием новой системы необходимо оценить существующие решения: российские электронные журналы и ERP-платформы, зарубежные LMS и сервисы видеоконференций, специализированные QR/SaaS-сервисы и открытые прототипы.
Цель анализа — определить, можно ли закрыть требования НИЯУ МИФИ готовым продуктом либо разработка собственной системы является обоснованной.
### 1.1. Российские системы
**Система «Учёт посещаемости студентов» ВВГУ.** Это внутренняя разработка Департамента цифрового развития Владивостокского государственного университета. По описанию ВВГУ, преподаватель во время занятия предоставляет студентам QR-код, при сканировании которого фиксируется присутствие; также возможна ручная отметка преподавателем. Система близка к целевому сценарию по способу фиксации, но является закрытым внутренним решением одного вуза. Для НИЯУ МИФИ она не закрывает требования интеграции с CAS, внешними академическими реестрами и собственной ролевой моделью. [Источник](https://www.vvsu.ru/news/201301/)
**БАРС.Образование / ЭЖД Мос.ру** Платформы ориентированы на электронный журнал и дневник школьного сегмента: оценки, темы уроков, расписание, домашние задания, посещаемость и отчётность. Ключевое ограничение состоит в самой модели предметной области: «школа — класс — родитель» плохо переносится на вузовскую структуру «поток — группа — подгруппа — кафедра — деканат». Посещаемость в таких системах, как правило, фиксируется учителем вручную; студенческая QR-самоотметка на очном занятии и интеграция с CAS вуза не являются базовым сценарием. [Источник](https://барс-образование.рф/about/)
**1С:Университет.** Решение на платформе «1С:Предприятие 8.3» предназначено для комплексной автоматизации процессов вуза: приёмной кампании, учебных планов, контингента, нагрузки преподавателей, успеваемости и посещаемости. Его сильная сторона — широкий охват административных процессов. Ограничение для данной работы — избыточность ERP-подхода и зависимость от экосистемы 1С. Для задачи точечной разработки веб-системы QR-самоотметки с CAS и REST/Outbox-синхронизацией такое решение не является оптимальным.
**iSpring LMS (ранее iSpring Learn).** Платформа ориентирована на корпоративное обучение: онлайн-курсы, тесты, тренинги, отчёты, API, SSO и on-premise-развёртывание. Функции посещаемости привязаны к тренингам и корпоративным мероприятиям, а не к вузовскому расписанию очных занятий. Система не предоставляет целевую модель «поток — группа — занятие — преподаватель — студент» и не решает задачу гарантированной синхронизации посещаемости с академическими реестрами НИЯУ МИФИ.
**Дневник.ру, ЭлЖур, Сетевой город. Образование.** Эти решения также относятся преимущественно к школьному электронному журналу. Их базовые сценарии строятся вокруг класса, учителя, родителей и ручной отметки посещаемости. Для корпоративного технического университета они не закрывают требования по CAS, QR-самоотметке, вузовской ролевой модели и on-premise-контролю данных.
### 1.2. Зарубежные системы
**Microsoft Teams.** В Teams поддерживаются отчёты о посещаемости онлайн-встреч: время входа, выхода, длительность участия и, в отдельных тарифах, показатели вовлечённости. Это полезно для дистанционных занятий, но не эквивалентно фиксации присутствия в аудитории. Кроме того, отчёты зависят от организатора встречи и не являются корпоративным реестром очной посещаемости. Для задачи НИЯУ МИФИ Teams не предоставляет QR-механизм, CAS-интеграцию и синхронизацию с внутренними академическими системами.
**Google Classroom / Google Meet.** Google Meet поддерживает отчёты о посещаемости для определённых редакций Google Workspace, включая Education Plus и Teaching and Learning Upgrade. Однако речь идёт о посещаемости онлайн-встреч, а не очных занятий. Google Classroom сам по себе не решает задачу аудиторной QR-самоотметки и не интегрируется с внутренними реестрами НИЯУ МИФИ в требуемой архитектуре.
**Brightspace (D2L).** Brightspace содержит инструмент Attendance, позволяющий создавать реестры посещаемости и отмечать статусы студентов. По своей природе базовый инструмент является электронным журналом внутри LMS. QR-самоотметка возможна через сторонние интеграции, например Qwickly Attendance, но это требует внедрения внешнего модуля и всей LMS-среды. Для НИЯУ МИФИ такой путь избыточен и не решает нативную интеграцию с CAS и внутренними реестрами.
### 1.3. Сравнительный анализ аналогов
Сравнительная оценка систем по критериям, важным для НИЯУ МИФИ, представлена в Таблице 1.
| Система | QR-self-service | SSO/CAS | Ролевая модель вуза | On-premise / контроль данных | Итог |
| ------------------------ | :--------------: | :-------------------: | :-----------------: | :--------------------------: | ------------------------------------------------- |
| ВВГУ «Учёт посещаемости» | + | - | Частично | + | Не переносится в МИФИ |
| БАРС.Образование | - | - | Школьная | Зависит от внедрения | Не подходит в силу нацеленности на школьный фрмат |
| 1С:Университет | - | - | + | + | Избыточная ERP-платформа |
| iSpring LMS | - | SSO, не интегрируется | Корпоративная | + | Не подходит для вузовской QR-самоотметки |
| Microsoft Teams | - | Azure AD | - | - | Только онлайн-встречи |
| Google Meet/Classroom | - | Google | - | - | Только онлайн-встречи |
| Brightspace (D2L) | Через интеграции | Зависит от внедрения | LMS | Зависит от контракта | Избыточно |
| **Attendance MEPhI** | **+** | **(CAS МИФИ)** | **+** | **+** | **Целевое решение** |
*Таблица 1 — Сравнительная оценка систем учёта посещаемости*
Вывод по разделу: готового продукта, который одновременно обеспечивает QR-самоотметку очной посещаемости, интеграцию с CAS МИФИ, гарантированную синхронизацию с внутренними реестрами, полную вузовскую ролевую модель и контроль данных на стороне университета, не выявлено. Следовательно, разработка собственной системы является обоснованной.
## 2. Анализ методов фиксации посещаемости студентов
Для выбора основного механизма фиксации посещаемости необходимо сравнить возможные методы по инфраструктурным затратам, скорости, достоверности, правовым рискам и применимости в условиях многокорпусного университета.
**Ручная отметка преподавателем.** Традиционный метод не требует дополнительной инфраструктуры, но плохо масштабируется на крупные потоки. Он увеличивает нагрузку на преподавателя, создаёт задержку между фактом посещения и появлением данных в системе, а также оставляет риск ошибок при переносе данных.
**RFID/NFC-карты.** Метод позволяет быстро фиксировать предъявление студенческой карты или пропуска. Ограничения связаны с необходимостью оборудования аудиторий считывателями, стоимостью внедрения и риском передачи карты другому лицу. Кроме того, отметку нужно связать не просто с входом в корпус, а с конкретной дисциплиной, занятием и преподавателем.
**QR-коды.** Преподаватель генерирует QR-код для конкретного занятия, студент сканирует его смартфоном и проходит отметку через аутентифицированную сессию. Метод не требует установки считывателей в аудиториях, быстро внедряется и естественно связывается с расписанием, преподавателем и конкретной парой. Защита от злоупотреблений обеспечивается ограниченным временем жизни QR-кода, одноразовым токеном и проверкой личности через CAS.
**СКУД.** Системы контроля и управления доступов исторически являлись одним из самых надежных способов фиксации посещения, но использование их, как единственного метода — недостаточно, так как проход через турникет не гарантирует присутствие на лекции, но целесообразно использовать такие системы, как дополнительную проверку.
**Биометрическая идентификация.** Биометрия обеспечивает высокий уровень достоверности, но создаёт существенные правовые и организационные риски. Обработка биометрических персональных данных в РФ регулируется статьей 11 Федерального закона № 152-ФЗ «О персональных данных» и требует отдельного правового обоснования. Для учебного проекта и массового внедрения в аудиториях этот метод избыточен.
**Геолокация.** Геолокационная отметка не требует аудиторного оборудования, но точности GPS и Wi-Fi-позиционирования может быть недостаточно для различения смежных аудиторий. Кроме того, постоянная или регулярная обработка местоположения студентов повышает чувствительность решения с точки зрения приватности.
| Метод | Инфраструктура | Скорость | Защита от подмены | Правовые риски | Применимость в МИФИ |
| -------------- | ------------------------------- | ------------------------- | ----------------------------- | -------------- | -------------------------------------- |
| Ручная отметка | Минимальная | Низкая на больших потоках | Низкая | Минимальные | Резервный сценарий |
| RFID/NFC | Высокие затраты на считыватели | Высокая | Средняя | Низкие | Ограниченная |
| **QR-коды** | **Минимальная** | **Высокая** | **Средняя при токенах и CAS** | **Низкие** | **Оптимальная** |
| СКУД | Затраты на оборудование | Высокая | Высокая | Низкие | Уже используется (возможна интеграция) |
| Биометрия | Высокие затраты на оборудование | Высокая | Высокая | Высокие | Не рекомендуется |
| Геолокация | Минимальная | Высокая | Низкая/средняя | Средние | Усложненная |
*Таблица 2 — Сравнительная оценка методов фиксации посещаемости*
Основным методом для системы целесообразно выбрать QR-коды. Ручная отметка преподавателем должна сохраниться как резервный механизм для спорных ситуаций, технических сбоев и студентов без доступа к смартфону в момент занятия.
---
## 3. Обзор существующих исследований
**QR-системы посещаемости.** В работе A. Nuhi, A. Memeti, F. Imeri и B. Çiço "Smart Attendance System using QR Code" предложена система учёта посещаемости на основе QR-кодов для высшего образования. Авторы указывают на типовые проблемы ручной регистрации: трудоёмкость, затраты времени и сложность работы с большими группами. Исследование подтверждает применимость QR-подхода для лекций и практических занятий, но описанная система функционирует автономно и не рассматривает интеграцию с корпоративным SSO, академическими реестрами и механизмами гарантированной доставки событий.
**Электронный журнал в структуре НИЯУ МИФИ.** Работа К.С. Глуховского, Р.В. Пирожкова и Е.А. Цвелика посвящена электронному журналу как элементу цифровой трансформации вуза. Для настоящей работы она важна тем, что рассматривает близкий контекст: электронную информационно-образовательную среду, импорт академических данных, разграничение ролей и отчётность. Ограничение такого подхода — отсутствие студенческой QR-самоотметки и описанного механизма надёжной синхронизации событий посещаемости.
**Практический опыт автоматизации очной посещаемости.** В публикации о методике автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий рассматривается переход от бумажной фиксации к цифровому учёту с использованием QR-инструментов и таблиц. Материал подтверждает практическую проблему крупных потоков и положительный эффект делегирования отметки студентам. При этом использование внешних облачных таблиц не подходит для целевой системы НИЯУ МИФИ из-за требований к контролю персональных данных и интеграции с внутренними системами.
**Производительность СУБД.** В статье 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. Выбор технологического стека
Выбор технологического стека должен учитывать не только производительность отдельных компонентов, но и соответствие предметной области: быстрый CRUD, интеграция с SSO, работа с расписанием и группами, массовые отметки в начале занятий, генерация отчётов и надёжная доставка событий во внешние реестры.
### 4.1. Веб-фреймворк и архитектура приложения
Для реализации бэкенда выбран **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
В качестве основной СУБД выбрана **PostgreSQL**. Для проекта важны ACID-транзакции, конкурентные записи, развитые индексы, строгая типизация, JSONB для метаданных событий и зрелые механизмы работы с ролями и схемами.
PostgreSQL особенно важен для реализации Transactional Outbox: отметка посещаемости и запись события синхронизации должны выполняться атомарно. Если запись отметки прошла успешно, но событие не было создано, внешние реестры могут остаться несогласованными. Если событие было отправлено без успешной записи отметки, возникнет обратная ошибка. Транзакционная модель PostgreSQL позволяет избежать этих сценариев.
### 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".
Установлено, что готовые российские и зарубежные продукты не закрывают совокупность требований НИЯУ МИФИ. Школьные электронные журналы ориентированы на модель класса и ручную отметку. ERP-решения уровня 1С:Университет избыточны для задачи QR-самоотметки и завязаны на собственную экосистему. LMS и сервисы видеоконференций фиксируют либо активность внутри курса, либо участие в онлайн-встрече, но не очную посещаемость в аудитории. QR-SaaS-сервисы создают риски внешнего хранения персональных данных и vendor lock-in. Открытые прототипы не обладают промышленной надёжностью и корпоративной интеграцией.
Из рассмотренных методов фиксации посещаемости оптимальным признан QR-код с ограниченным временем жизни, одноразовым токеном и проверкой пользователя через CAS. Ручная отметка преподавателем должна оставаться резервным механизмом. RFID/NFC требует инфраструктурных затрат, биометрия создаёт высокие правовые риски, а геолокация недостаточно точна для аудиторного сценария и чувствительна с точки зрения приватности.
Выбранный стек — Ruby on Rails 7, Hotwire, PostgreSQL, Sidekiq, Redis, CAS, Tailwind CSS, Capistrano и Mise — соответствует задаче разработки корпоративного веб-приложения. Rails и Hotwire ускоряют создание интерфейсов без отдельного SPA, PostgreSQL обеспечивает транзакционную целостность, Sidekiq реализует фоновые процессы, а Transactional Outbox снижает риск потери событий при синхронизации с внешними реестрами.
Результаты работы формируют обоснованную теоретическую и техническую базу для реализации системы "Attendance MEPhI" в рамках последующей проектной или дипломной работы.
---
## Список использованной литературы
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. Глуховский К.С., Пирожков Р.В., Цвелик Е.А. Электронный журнал как элемент цифровой трансформации вуза // Инженерный вестник Дона. 2021. № 5. URL: https://ivdon.ru/ru/magazine/archive/n5y2021/6978 (дата обращения: 08.06.2026).
3. Дусалин А.К., Семенов Г.Н., Скичко Е.А. Методика автоматизации контроля посещаемости очных занятий по опыту кафедры информационных компьютерных технологий. URL: https://www.muctr.ru/upload/iblock/409/hd3gn9gkbrnezs3kuedj3lz18cb2oddx.pdf (дата обращения: 08.06.2026).
4. Richardson C. Microservices Patterns: With Examples in Java. Manning Publications, 2018. 520 p.
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. 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. Getting Started with Rails // Ruby on Rails Guides. URL: https://guides.rubyonrails.org/getting_started.html (дата обращения: 08.06.2026).
8. Hotwire: HTML Over The Wire // Hotwire. URL: https://hotwired.dev/ (дата обращения: 08.06.2026).
9. Sidekiq: Simple, Efficient Background Jobs for Ruby // GitHub. URL: https://github.com/sidekiq/sidekiq (дата обращения: 08.06.2026).
10. PostgreSQL Documentation // PostgreSQL. URL: https://www.postgresql.org/docs/ (дата обращения: 08.06.2026).
11. CAS Protocol // Apereo CAS. URL: https://apereo.github.io/cas/7.1.x/protocol/CAS-Protocol.html (дата обращения: 08.06.2026).
12. Tailwind CSS Documentation // Tailwind CSS. URL: https://tailwindcss.com/docs (дата обращения: 08.06.2026).
13. Bootstrap 5 Documentation // Bootstrap. URL: https://getbootstrap.com/docs/5.3/ (дата обращения: 08.06.2026).
14. Capistrano: Remote Server Automation and Deployment Tool // Capistrano. URL: https://capistranorb.com/ (дата обращения: 08.06.2026).
15. Mise: Polyglot Runtime Manager // Mise. URL: https://mise.jdx.dev/ (дата обращения: 08.06.2026).
16. Система "Учёт посещаемости студентов" // Электронный кампус ВВГУ. URL: https://www.vvsu.ru/e-campus/news/201301/ (дата обращения: 08.06.2026).
17. БАРС.Образование — Электронная Школа: описание программного обеспечения // БАРС Груп. URL: https://bars.group/wp-content/uploads/2024/05/opisanie-elektronnaya-shkola.pdf (дата обращения: 08.06.2026).
18. 1С:Университет — Возможности // 1С. URL: https://solutions.1c.ru/catalog/university/features (дата обращения: 08.06.2026).
19. iSpring LMS (iSpring Learn): платформа для онлайн-обучения // iSpring. URL: https://www.ispring.ru/ispring-learn (дата обращения: 08.06.2026).
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. 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. 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).
Reference in New Issue View Git Blame Copy Permalink