arch-x1: 2026-06-08 15:33:30 | 1
This commit is contained in:
Dmitry
@@ -0,0 +1,145 @@
|
||||
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
|
||||
|
||||
Федеральное государственное автономное образовательное учреждение высшего образования
|
||||
|
||||
НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ЯДЕРНЫЙ УНИВЕРСИТЕТ «МИФИ»
|
||||
|
||||
<br>
|
||||
|
||||
**Учебно-исследовательская работа на тему:**
|
||||
«Аналитический обзор решений на рынке по системам контроля посещаемости в ВУЗе, сравнение с собственной разработкой и обоснование выбора технологического стека»
|
||||
|
||||
**Выполнил студент:** [ФИО студента]
|
||||
**Группа:** [Номер группы]
|
||||
|
||||
**Проверил:**
|
||||
[ФИО преподавателя]
|
||||
**Оценка:** ___________________
|
||||
**Дата:** _____________________
|
||||
**Подпись:** __________________
|
||||
|
||||
Москва, 2026
|
||||
|
||||
---
|
||||
|
||||
## Оглавление
|
||||
1. Введение
|
||||
2. Глава 1. Анализ существующих решений и систем контроля посещаемости
|
||||
1.1. Обзор российских систем
|
||||
1.2. Обзор зарубежных систем
|
||||
1.3. Сравнительный анализ аналогов
|
||||
3. Глава 2. Обоснование собственной разработки и выбора технологического стека
|
||||
2.1. Концепция системы Attendance MEPhI
|
||||
2.2. Выбор веб-фреймворка и архитектуры приложения
|
||||
2.3. Фронтенд-архитектура: отказ от SPA в пользу Hotwire
|
||||
2.4. Выбор СУБД и организация бизнес-логики
|
||||
2.5. Асинхронная обработка и надежная синхронизация (Outbox Pattern)
|
||||
2.6. Интеграция с корпоративной системой аутентификации (CAS)
|
||||
4. Заключение
|
||||
5. Список использованной литературы
|
||||
|
||||
---
|
||||
|
||||
## Введение
|
||||
|
||||
Цифровая трансформация образовательного процесса в современных университетах требует внедрения надежных и прозрачных инструментов контроля успеваемости и присутствия обучающихся. В условиях крупного вуза, такого как НИЯУ МИФИ, традиционные бумажные журналы или несистематизированные электронные таблицы становятся неэффективными, повышая риск потери данных и усложняя сбор аналитики для деканатов и администрации.
|
||||
|
||||
В связи с этим возникает потребность в автоматизированной системе учета посещаемости, способной интегрироваться с внутренними реестрами вуза и обеспечивать удобный интерфейс как для преподавателей, так и для студентов. Готового аналога, закрывающего все требования МИФИ, на рынке нет: зарубежные универсальные инструменты фиксируют посещаемость лишь как побочный продукт онлайн-встреч и не интегрируются с CAS МИФИ, а российские решения ориентированы на школу или корпоративное обучение, не давая студенческой QR-самоотметки и Outbox-синхронизации[cite: 1]. Это прямо обосновывает разработку собственной системы[cite: 1].
|
||||
|
||||
**Актуальность работы** обусловлена отсутствием на рынке универсального on-premise решения, которое сочетало бы механизм быстрой самостоятельной отметки студентов на очных занятиях, интеграцию с корпоративной системой авторизации и гарантированную асинхронную доставку данных в академические реестры университета[cite: 1].
|
||||
|
||||
**Целью работы** является проведение аналитического обзора существующих рыночных решений в сфере контроля посещаемости, их сравнение с разрабатываемой системой «Attendance MEPhI» и обоснование выбранного технологического стека[cite: 3].
|
||||
|
||||
**Задачи исследования:**
|
||||
1. Провести обзор российских и зарубежных аналогов систем контроля посещаемости.
|
||||
2. Сформировать сравнительную матрицу функциональных возможностей.
|
||||
3. Обосновать необходимость разработки собственного программного решения.
|
||||
4. Выполнить обоснование выбранной архитектуры, фреймворка, СУБД и сопутствующих технологий[cite: 1, 3].
|
||||
|
||||
---
|
||||
|
||||
## Глава 1. Анализ существующих решений и систем контроля посещаемости
|
||||
|
||||
Ни один массовый продукт не сочетает одновременно четыре ключевых свойства, необходимых корпоративному вузу: QR-самоотметку студента на очном занятии, интеграцию с корпоративным SSO (CAS МИФИ), гарантированную синхронизацию с внутренними реестрами и полную ролевую модель[cite: 1].
|
||||
|
||||
### 1.1. Обзор российских систем
|
||||
|
||||
**1. БАРС.Образование — Электронная школа**
|
||||
Одна из самых распространенных в РФ платформ электронного дневника[cite: 1]. Модуль ориентирован на фиксацию посещаемости исключительно путем ручной отметки учителем[cite: 1]. Основным архитектурным ограничением является использование школьной модели данных («школа — класс — родитель»), которая не масштабируется на сложную вузовскую структуру («учебный поток — группа — подгруппа»)[cite: 1]. Кроме того, интеграция реализуется через СМЭВ/Госуслуги, что затрудняет использование корпоративного CAS вуза[cite: 1].
|
||||
|
||||
**2. iSpring Learn (iSpring LMS)**
|
||||
Известная российская корпоративная LMS, доступная в облаке вендора и on-premise[cite: 1]. Включает отчет по посещаемости очных тренингов, где преподаватель отмечает участников вручную[cite: 1]. Система предназначена для корпоративного обучения персонала, не поддерживает ролевую модель учебного потока вуза и QR-самоотметку на занятии, а также не имеет Outbox-синхронизации с академическими реестрами[cite: 1].
|
||||
|
||||
**3. 1С:Университет**
|
||||
Отраслевое решение на платформе «1С:Предприятие 8.3» для комплексного управления вузом[cite: 1]. Посещаемость вводится вручную через АРМ[cite: 1]. В решении отсутствует студенческий QR-self-service и нативное веб-самообслуживание[cite: 1]. Интеграция требует механизмов обмена 1С, а не современных REST/CAS[cite: 1].
|
||||
|
||||
**4. Система «Учет посещаемости студентов» ВВГУ**
|
||||
Собственная разработка Департамента цифрового развития ВВГУ[cite: 1]. Поддерживает QR-отметку и имеет частичную ролевую модель (роль куратора)[cite: 1]. Главный недостаток — это закрытая внутренняя система одного вуза без публичного API и Outbox-синхронизации, не интегрируемая с внешними CAS МИФИ[cite: 1].
|
||||
|
||||
### 1.2. Обзор зарубежных систем
|
||||
|
||||
**1. Microsoft Teams и Google Classroom/Meet**
|
||||
Обе платформы фиксируют присутствие на видеовстрече (время входа/выхода), а не на очном занятии[cite: 1]. Нативной отметки очных занятий по QR нет, интеграция с внутренними реестрами и вузовская ролевая модель отсутствуют[cite: 1].
|
||||
|
||||
**2. Brightspace (D2L) — Attendance tool**
|
||||
Базовый инструмент представляет собой электронный реестр, где отметку ставит преподаватель или ассистент вручную[cite: 1]. Мобильная самоотметка и QR реализуются только через сторонние интеграции и платные плагины (Qwickly Attendance), что требует внедрения всей LMS Brightspace[cite: 1].
|
||||
|
||||
**3. Специализированные QR/чек-ин SaaS решения (OneTap, AccuClass)**
|
||||
Эти сервисы предоставляют функционал сканирования QR-кодов, однако ориентированы на мероприятия или школы[cite: 1]. Данные хранятся в облаке вендора (vendor lock-in), нет вузовской ролевой модели и Outbox-синхронизации[cite: 1].
|
||||
|
||||
### 1.3. Сравнительный анализ аналогов
|
||||
|
||||
**Таблица 1 — Сравнительный анализ систем учета посещаемости[cite: 1]**
|
||||
|
||||
| Система | QR-self-service | SSO/CAS-интеграция | Outbox-синхронизация | Вузовская ролевая модель | On-premise |
|
||||
| :--- | :---: | :---: | :---: | :---: | :---: |
|
||||
| ВВГУ "Учет посещаемости" | ✔ | ✘ | ✘ | Частично | ✔ |
|
||||
| БАРС.Образование | ✘ | ✘ (Госуслуги) | ✘ | Школьная | Зависит |
|
||||
| iSpring Learn | ✘ | ✔ (SSO) | ✘ | Корпоративная | ✔ |
|
||||
| 1С:Университет | ✘ | ✘ | ✘ (обмен 1С) | ✔ | ✔ |
|
||||
| MS Teams | ✘ | ✔ (Azure AD) | ✘ | ✘ | ✘ |
|
||||
| Google Classroom/Meet | ✘ | ✔ (Google) | ✘ | ✘ | ✘ |
|
||||
| Brightspace | Через плагины | ✔ | ✘ | LMS | ✔ |
|
||||
| QR-SaaS (OneTap и др.) | ✔ | Частично | ✘ | ✘ | ✘ |
|
||||
| **Attendance MEPhI (Проект)** | **✔** | **✔ (CAS МИФИ)**| **✔** | **✔ (полная)**| **✔** |
|
||||
|
||||
**Вывод по Главе 1:** Ниша систем для QR-самоотметки очной посещаемости с интеграцией CAS-SSO вуза, Outbox-синхронизацией с реестрами и полной ролевой моделью не закрыта существующими продуктами, что служит обоснованием разработки[cite: 1].
|
||||
|
||||
---
|
||||
|
||||
## Глава 2. Обоснование собственной разработки и выбора технологического стека
|
||||
|
||||
### 2.1. Концепция системы Attendance MEPhI
|
||||
**Attendance MEPhI** — это веб-приложение для отслеживания посещаемости занятий студентами НИЯУ МИФИ[cite: 3]. Система автоматизирует процесс фиксации присутствия студентов на лекциях и семинарах, предоставляя интерфейсы для студентов, преподавателей (тьюторов), модераторов и администраторов[cite: 3]. Проект построен на классическом паттерне MVC с использованием современных расширений Rails[cite: 3].
|
||||
|
||||
### 2.2. Выбор веб-фреймворка и архитектуры приложения
|
||||
Стек Rails 7 обоснован архитектурно[cite: 1]. Rails реализует строгий паттерн MVC, принципы «Convention over Configuration» и DRY, что ускоряет разработку CRUD-приложений[cite: 1]. Хотя Ruby исторически уступает по "сырой" производительности оптимизированным PHP/Python, это компенсируется фоновой обработкой, кэшированием и горизонтальным масштабированием[cite: 1].
|
||||
|
||||
### 2.3. Фронтенд-архитектура: отказ от SPA в пользу Hotwire
|
||||
Server-rendered HTML через Hotwire (Turbo + Stimulus) снимает необходимость в отдельном SPA[cite: 1]. Он отправляет фрагменты HTML вместо JSON, обеспечивая отзывчивый интерфейс без тяжелого клиентского JS[cite: 1, 3]. Для стилизации используется Tailwind CSS, utility-first подход которого дает существенно меньший production-бандл за счет JIT-purge и не тянет лишние JS-компоненты[cite: 1, 3].
|
||||
|
||||
### 2.4. Выбор СУБД и организация бизнес-логики
|
||||
В качестве хранилища данных выбрана PostgreSQL[cite: 1, 3]. Это ACID-совместимая СУБД с MVCC, расширенным набором типов и ролевой моделью доступа, предпочтительная для транзакционных приложений с большими объемами данных[cite: 1].
|
||||
Бизнес-логика (импорт данных, обработка посещений) изолируется в Service Objects (`app/services`), что соответствует принципу единой ответственности и упрощает тестирование[cite: 1, 3]. Ролевая модель поддерживается через пространства имен контроллеров (Namespaced Controllers: `Admin`, `Student` и т.д.), что изолирует ролевые интерфейсы и упрощает авторизацию[cite: 1, 3].
|
||||
|
||||
### 2.5. Асинхронная обработка и надежная синхронизация (Outbox Pattern)
|
||||
Для гарантированной доставки данных во внешние реестры МИФИ используется Outbox Pattern (таблица `update_attendance_students_outbox`)[cite: 1, 3]. Событие записывается в outbox-таблицу в той же транзакции, что и бизнес-данные, решая проблему "dual write"[cite: 1]. Отдельный процесс (Sidekiq) асинхронно публикует его наружу, обеспечивая доставку at-least-once[cite: 1]. Sidekiq использует Redis как in-memory хранилище очередей и эффективен по памяти благодаря многопоточной модели[cite: 1, 3].
|
||||
|
||||
### 2.6. Интеграция с корпоративной системой аутентификации (CAS)
|
||||
Система интегрируется с CAS (Central Authentication Service) МИФИ для Single Sign-On[cite: 3]. CAS — это протокол, при котором приложение никогда не видит пароль пользователя: аутентификация выполняется на доверенном сервере, выдающем service ticket[cite: 1]. Это снижает риск фишинга и избавляет от необходимости вести локальную базу паролей[cite: 1].
|
||||
|
||||
---
|
||||
|
||||
## Заключение
|
||||
|
||||
Анализ показал, что ни одна из массовых российских или зарубежных систем не удовлетворяет одновременно требованиям QR-самоотметки, интеграции с CAS МИФИ, наличию механизмов надежной Outbox-репликации данных и поддержке специфической ролевой модели вуза. Выбранный технологический стек (Ruby on Rails 7, PostgreSQL, Hotwire, Sidekiq) обеспечивает высокую скорость разработки, SPA-ощущение без перегрузки клиентской части JavaScript-кодом и промышленную надежность доставки данных во внешние реестры. Разработка системы «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, pp. 1–4. DOI: 10.1109/MECO49872.2020.9134225.
|
||||
2. Глуховский К.С., Пирожков Р.В., Цвелик Е.А. Электронный журнал как элемент цифровой трансформации вуза // Инженерный вестник Дона. 2021. №5.
|
||||
3. Salunke S.V., Ouda A. A Performance Benchmark for the PostgreSQL and MySQL Databases // Future Internet (MDPI). 2024. Vol. 16(10). Art. 382. DOI: 10.3390/fi16100382.
|
||||
4. Даньшин К.А. Сравнительный анализ современных веб-фреймворков для разработки приложений // CyberLeninka, 2019.
|
||||
5. Chris Richardson. Microservices Patterns: With examples in Java. Manning Publications. (Pattern: Transactional outbox).
|
||||
Reference in New Issue
Block a user