Web-орієнтована інформаційна система контролю відвідування занять студентами

Перевозний, Олександр Олександрович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9887

Title:	Web-орієнтована інформаційна система контролю відвідування занять студентами
Authors:	Катаєв, Дмитро Сергійович Перевозний, Олександр Олександрович
Keywords:	web-орієнтована;UI/UX-дизайн;інформаційна система;контроль відвідування занять студентами;фреймворк;Node.js;Figma;React;сервер
Issue Date:	11-Jun-2026
Abstract:	У кваліфікаційній роботі бакалавра розроблено Web-орієнтована інформаційна система контролю відвідування занять студентами. Розробку реалізовано на основі використання комплексу сучасних програмних інструментів та засобів, таких як React, Node.js, Figma. Обсяг пояснювальної записки кваліфікаційної роботи бакалавра складає 80 сторінок, в тому числі вступ, 3 розділи, висновки, додаток та список використаних джерел. Робота містить 10 рисунків та 50 інформаційних джерел. Перший розділ кваліфікаційної роботи присвячений опису сучасного стану досліджуваної теми, визначення ключових процесів, термінів та актуальності розробки. Здійснено аналітичний огляд існуючих програмних рішень або систем, оцінку їхніх переваг і недоліків. Обґрунтувано актуальність та доцільність створення нового продукту. Сформульовано мету роботи, описано функціональні вимоги та перелік завдань для реалізації проєкту. Другий розділ присвячений проектуванню архітектури web-орієнтованої інформаційної системи, проєктуванню бази даних. Досліджено питання вибору засобів розробки web-орієнтованої ІС. У третьому розділі спроєктовано та реалізовано клієнтську і серверну частини системи, а також створено сучасний інтуїтивно зрозумілий UI/UXдизайн, який забезпечує зручну взаємодію користувача з інтерфейсом. Проведене комплексне тестування розробленого програмного забезпечення підтвердило повну відповідність системи висунутим функціональним вимогам, високу стабільність її роботи та готовність до практичного розгортання.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9887
Appears in Collections:	126 Інформаційні системи та технології (Web-технології, web-дизайн)

Files in This Item:

File	Description	Size	Format
РЕП_БАК_Перевозний _WEB-2211.pdf Restricted Access		1.19 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет Інформаційних Технологій і Систем_____________________________________
(повна назва)
Кафедра Інформаційних Технологій Проектування__________________________________
(повна назва)
Освітньо-кваліфікаційний рівень Бакалавр_________________________________________
(назва)
Спеціальність 126 – Інформаційні системи і технології_______________________________
(шифр і назва)
ЗАТВЕРДЖУЮ
Завідувач кафедри ІТП
___________ Тетяна ПРОКОПЕНКО
«_____» ______________20___ року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ БАКАЛАВРА
_____________________ Перевозний Олександр Олександрович ____________________
(прізвище, ім’я, по батькові)
1. Тема роботи Web-орієнтована інформаційна система контролю відвідування занять
студентами ____________
Керівник роботи Катаєв Дмитро Сергійович, _к.т.н., доцент____________________
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
Затверджено наказом Черкаського державного технологічного університету від «_12_»
__березня_______ 2026 року N56/03-03________
2. Строк подання здобувачем роботи _____26.05.2026___________________________
3. Вихідні дані до роботи: Загальна інформація про об’єкт дослідження, інформація про
меоди та засоби розробки, структура БД, аналіз аналогів, базові технічні характеристики
розроблюваної системи.
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ________________________________________________________________________
1. Опис предметної області. ___ ___________________________________________________
2. Аналіз існуючих аналогів._____________________________________________________
3.Постановка задачі _________________________________________________
4.Розробка архітектури системи.__________________________________________
5. Розробка структури бази даних________________________________________________
6. Обґрунтування технології та засобів реалізації.___________________________________
7.Вибір засобів розробки.__________________________________________
8.Рзробка дизайну web- системи.________
Висновки._____________________________________________________________________
Перелік джерел та посилань._____________________________________________________
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів)
Презентація кваліфікаційної роботи____________________________________
6. Консультанти розділів роботи
Прізвище, ініціали, та посада
Розділ Підпис, дата
консультанта
Завдання
Завдання прийняв
видав
7. Дата видачі завдання ______________________________________________
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ Назва етапів кваліфікаційної роботи Примітка
етапів роботи
1 Опис предметної області.
2 Аналіз існуючих аналогів
3 Постановка задачі
4 Розробка архітектури системи.
5 Розробка структури бази даних
Обґрунтування технології та засобів
6 реалізації.
7 Вибір засобів розробки.
8 Застосування стеку технологій
9 Розробка дизайну web-системи
10 Висновки
Здобувач вищої освіти _______________ Олександр ПЕРЕВОЗНИЙ
Керівник роботи _______________________ Дмитро КАТАЄВ
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ ПРОЕКТУВАННЯ
Пояснювальна записка
до кваліфікаційної роботи бакалавра
на тему: ««WEB-ОРІЄНТОВАНА ІНФОРМАЦІЙНА
СИСТЕМА КОНТРОЛЮ ВІДВІДУВАННЯ ЗАНЯТЬ
СТУДЕНТАМИ»»
Виконав студент 4 курсу,
групи Web-2211,
спеціальності 126 –
Інформаційні системи та
технології,
освітня програма – Web-
технології, Web-дизайн,
Перевозний О.О.
Керівник к.т.н., доц. Катаєв Д.С.
Рецензент Директор ТОВ АндерсенЛаб
Алєсін О.
Черкаси – 2026 року
АНОТАЦІЯ
У кваліфікаційній роботі бакалавра розроблено Web-орієнтована
інформаційна система контролю відвідування занять студентами. Розробку
реалізовано на основі використання комплексу сучасних програмних
інструментів та засобів, таких як React, Node.js, Figma.
Обсяг пояснювальної записки кваліфікаційної роботи бакалавра складає
80 сторінок, в тому числі вступ, 3 розділи, висновки, додаток та список
використаних джерел. Робота містить 10 рисунків та 50 інформаційних джерел.
Перший розділ кваліфікаційної роботи присвячений опису сучасного
стану досліджуваної теми, визначення ключових процесів, термінів та
актуальності розробки. Здійснено аналітичний огляд існуючих програмних
рішень або систем, оцінку їхніх переваг і недоліків. Обґрунтувано актуальність
та доцільність створення нового продукту. Сформульовано мету роботи,
описано функціональні вимоги та перелік завдань для реалізації проєкту.
Другий розділ присвячений проектуванню архітектури web-орієнтованої
інформаційної системи, проєктуванню бази даних. Досліджено питання вибору
засобів розробки web-орієнтованої ІС.
У третьому розділі спроєктовано та реалізовано клієнтську і серверну
частини системи, а також створено сучасний інтуїтивно зрозумілий UI/UX-
дизайн, який забезпечує зручну взаємодію користувача з інтерфейсом.
Проведене комплексне тестування розробленого програмного забезпечення
підтвердило повну відповідність системи висунутим функціональним вимогам,
високу стабільність її роботи та готовність до практичного розгортання.
Ключові слова: web-орієнтована, інформаційна система, контроль
відвідування занять студентами, фреймворк, Node.js, Figma, React, сервер,
UI/UX-дизайн.
ABSTRACT
A Web-based information system for monitoring student attendance.has
been developed in the bachelor's thesis. React, Node.js, Figma were chosen as the
development tools.
The volume of the explanatory note of the bachelor's qualification work is
80 pages, including the introduction, 3 sections, conclusions, appendix and the list
of used sources. The work contains 10 drawings and 50 references.
The first section of the qualification work is devoted to describing the
current state of the research topic, defining key processes, terms and relevance of
the development. An analytical review of existing software solutions or systems
was carried out, their advantages and disadvantages were assessed. The relevance
and feasibility of creating a new product was substantiated. The purpose of the work
was formulated, functional requirements and a list of tasks for the implementation
of the project were described.
The second section is devoted to designing the architecture of a web-
oriented information system, database design. The issue of choosing web-oriented
IS development tools was studied.
In the third section, the client and server parts of the system were designed
and implemented, and a modern intuitive UI/UX design was created, which ensures
convenient user interaction with the interface. Comprehensive testing of the
developed software confirmed the full compliance of the system with the functional
requirements, high stability of its operation and readiness for practical deployment.
Keywords: web-oriented, information system, student attendance control,
framework, Node.js, Figma, React, server, UI/UX design.
ЗМІСТ
ВСТУП.......................................................................................................... 3
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ.........................................................6
1.1 Опис предметної області.......................................................................6
1.2 Аналіз існуючих аналогів на ринку...................................................12
1.3 Постановку задачі................................................................................18
1.4 Висновки до розділу 1.........................................................................24
2 ПРОЄКТУВАННЯ WEB-ОРІЄНТОВАНОЇ ІНФОРМАЦІЙНОЇ
СИСТЕМИ КОНТРОЛЮ ВІДВІДУВАННЯ ЗАНЯТЬ СТУДЕНТАМИ......26
2.1 Архітектура web-орієнтованої інформаційної системи...................26
2.2 Проєктування бази данх......................................................................29
2.3 Вибір засобів розробки web-орієнтованої ІС....................................33
2.4 Висновки до розділу 2.........................................................................35
3 РОЗРОБКА ТА ТЕСТУВАННЯ WEB-ОРІЄНТОВАНОЇ ІС..............37
3.1 Розробка Backend-частини.................................................................37
3.2 Розробка Frontend-частини................................................................40
3.3 Розробка макету дизайну web-орієнтованої ІС.................................44
3.4 І Тестування web-орієнтованої ІС......................................................49
3.5 Висновки до розділу 3.........................................................................53
ВИСНОВКИ...............................................................................................54
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ..................................................56
ДОДАТОК A 482 ЧДТУ 22144-01 Web-орієнтована інформаційна
система контролю відвідування занять студентами. Специфікація.............61
ЧДТУ 262214.001 ПЗ
Зм. Лист № докумемента Підпис Дата
Розроб. Перевозний О Літ. Лист Листів
Перев. Катаєв Д.С.. Web-орієнтована інформаційна Н 2 80
Реценз система контролю відвідування ФІТІС,
Н. .контр. занять студентами.
кафедра ІТП, Web-2211
Затв. Прокопенко Т.О. Пояснювальна записка
ВСТУП
Сучасний етап розвитку вищої освіти в Україні та світі характеризується
масштабною цифровою трансформацією. Впровадження інформаційних
технологій у діяльність закладів вищої освіти (ЗВО) є стратегічною
необхідністю, оскільки автоматизація ключових процесів дозволяє суттєво
підвищити якість менеджменту, оптимізувати використання ресурсів та
мінімізувати вплив людського фактору.
Одним із критично важливих, але досі слабко автоматизованих процесів
у багатьох ЗВО залишається контроль відвідування занять студентами.
Традиційні паперові журнали та ручне перенесення даних до відомостей мають
низку суттєвих недоліків:
- високі часові витрати, коли викладачі витрачають до 5–10% часу
кожної лекції чи практичного заняття на перекличку;
- низька оперативність, тобто керівництво деканату та куратори
отримують інформацію про прогули із запізненням (зазвичай під
час атестації чи сесії), що унеможливлює вчасне педагогічне
реагування;
- суб'єктивізм та помилки, адже паперовий облік вразливий до
втрати даних, механічних помилок або фальсифікацій.
Створення та впровадження web-орієнтованої інформаційної системи
(ІС) контролю відвідування занять дозволяє розв'язати ці проблеми. Web-формат
забезпечує транскордонний, кросплатформний та цілодобовий доступ до
системи з будь-якого пристрою (ПК, планшет, смартфон) без необхідності
встановлення додаткового програмного забезпечення.
Актуальність. Актуальність розробки полягає в оптимізації
адміністративного моніторингу навчального процесу через створення єдиного
інформаційного простору ЗВО. Система дозволяє автоматизувати збір
статистики, миттєво виявляти студентів із «групи ризику» на ранніх етапах
семестру та оперативно приймати управлінські рішення для підвищення
Арк.
ЧДТУ 262214.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата
загального рівня виконавчої дисципліни. Автоматичний аналіз динаміки
відвідуваності дає змогу виявляти «групи ризику» серед студентів на ранніх
етапах, прогнозувати рівень успішності та автоматизувати генерацію звітів для
адміністрації.
Розробка web-орієнтованої інформаційної системи контролю
відвідування занять є актуальним науково-практичним завданням, спрямованим
на побудову єдиного цифрового освітнього простору ЗВО, підвищення
виконавчої дисципліни студентів та оптимізацію робочого часу науково-
педагогічних працівників..
Об’єктом дослідження є процес обліку та контролю відвідуваності
навчальних занять студентами у закладах вищої освіти.
Предметом дослідження є методи, алгоритми та програмні засоби
автоматизації збору, збереження, обробки та візуалізації даних про
відвідуваність у web-орієнтованому середовищі.
Метою кваліфікаційної роботи бакалавра є проектування, розробка та
впровадження web-ориієнтованої інформаційної системи контролю відвідування
занять студентами для забезпечення підвищення ефективності моніторингу
навчального процесу в ЗВО. Для досягнення поставленої мети кваліфікаційної
роботи бакалавра необхідно розв’язати наступні задачі:
 проаналізувати предметну область розробки;
 здійснити порівняльний аналіз програмних аналогів контролю
відвідуваності у ЗВО, виявити їхні недоліки;
 обґрунтувати вибір технологічного стеку (мови програмування,
фреймворків, СКБД) для реалізації клієнтської та серверної частин;
 сформувати вимоги до web-ориієнтованої інформаційної системи
контролю відвідування занять студентами;
 провести тестування розробленого програмного продукту.
Арк.
ЧДТУ 262214.001 ПЗ 4
Змн. Арк. № докум. Підпис Дата
Обсяг пояснювальної записки кваліфікаційної роботи бакалавра складає
77 сторінок, в тому числі вступ, 3 розділи, висновки, додаток та список
використаних джерел. Робота містить 22 рисунка та 50 інформаційних джерел.
Арк.
ЧДТУ 262214.001 ПЗ 5
Змн. Арк. № докум. Підпис Дата
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ
1.1 Опис предметної області
Сучасний заклад вищої освіти (ЗВО) є складною, динамічною та
багаторівневою соціально-економічною системою. Його функціонування
пов'язане з обробкою величезних масивів інформації, що стосуються
навчального планування, кадрового забезпечення, наукової діяльності та
моніторингу успішності студентів. Головною метою діяльності будь-якого ЗВО
є надання якісних освітніх послуг, що безпосередньо залежить від рівня
організації освітнього процесу та виконавчої дисципліни його учасників.
Одним із базових чинників, що впливають на якість засвоєння знань та
кінцеві результати навчання, є регулярне відвідування студентами аудиторних
(або онлайн) занять. Відвідуваність є інтегральним показником, який
відображає:
- рівень мотивації та залученості студентів до навчального процесу;
- ефективність викладацької майстерності та актуальність
навчального матеріалу;
- потенційні ризики низької успішності чи відрахування здобувачів
освіти.
Впровадження web-орієнтованої інформаційної системи контролю
відвідуваності занать студентами в структуру сучасного університету має
велике значення та полягає у трансформації хаотичного паперового обліку в
системний цифровий інструмент управління. Практична доцільність такої
впровадження системи реалізуються через три основні рівні вигоди:
1. Педагогічний та психологічний аспект полягає в наступному [1]:
- підвищення дисципліни, тобто сам факт існування прозорої цифрової
системи, де кожен пропуск фіксується миттєво, стимулює студентів до
відповідальнішого ставлення до навчання;
- раннє виявлення проблем забезпечується за рахунок можливості
система, що дозволяє кураторам та викладачам помітити систематичні
Арк.
ЧДТУ 262214.001 ПЗ 6
Змн. Арк. № докум. Підпис Дата
пропуски студента не наприкінці семестру під час сесії, а вже на 2–3
тижні навчання. Це дає змогу вчасно з'ясувати причини (хвороба,
психологічні труднощі, фінансові проблеми) та надати студенту
необхідну підтримку.
2. Організаційно-управлінський аспект (для Деканату та Адміністрації)
забезпечується за рахунок [2]:
- об'єктивна аналітика в реальному часі, що забезпечує можливості
керівництву університету отримати доступ до зведених звітів у розрізі
факультетів, курсів, груп чи окремих дисциплін за будь-який проміжок
часу в один клік;
- автоматизація рутини, тобто деканат звільняється від необхідності
збирати паперові рапортучки від старост чи відомості від викладачів,
вручну підраховувати години пропусків та складати звіти для
ректорату;
- прозорість та виключення корупційних ризиків, коли дані в електронній
системі мають чіткі логи (хто, коли і яку відмітку поставив або змінив),
що виключає можливість «заднім числом» сфальсифікувати
присутність студента.
3. Економічний сенс та оптимізація часу викладача, що сприяє:
- економія аудиторного часу, тобто традиційна перекличка на початку
кожної пари забирає від 5 до 10 хвилин. У масштабах семестру для
одного викладача це десятки втрачених академічних годин, які можна
було використати на виклад матеріалу чи дискусію. Автоматизована
фіксація (наприклад, через швидкі кліки у вебі або QR-коди) зводить ці
витрати до 1 хвилини.
- екологічність та зменшення витрат, де повна відмова від паперових
журналів, рапортучок та бланків відомостей знижує витрати ЗВО на
канцелярію та відповідає концепції "Green Campus".
Арк.
ЧДТУ 262214.001 ПЗ 7
Змн. Арк. № докум. Підпис Дата
Таким чином, впровадження пропонованого рішення є не просто
автоматизацією окремої рутинної дії, а стратегічним кроком до створення
цифрового двійника університету, де дані про відвідуваність стають основою
для аналізу якості освіти.
Мета web-орієнтованої інформаційної системи контролю відвідування
занять полягає в створенні єдиного, прозорого та оперативного цифрового
середовища для автоматизованого збору, централізованого зберігання,
інтелектуальної обробки та візуалізації даних про присутність студентів на
навчальних заняттях у режимі реального часу.
Досягнення цієї мети дозволяє трансформувати пасивний облік «по
факту» в активний інструмент управління якістю освіти, що забезпечує
реалізацію наступних підцілей для різних категорій користувачів ЗВО. Для
керівництва закладу освіти (Ректорат, Деканат, Куратори) це забезпечить
оперативність контролю. Отримання миттєвого доступу до аналітики
відвідуваності без необхідності очікування кінця тижня, місяця чи семестру.
Прогнозування успішності через можливість виявлення кореляції між
пропусками занять та фінальними оцінками студентів забезпечить превентивне
запобігання академічній заборгованості. Автоматизація звітності через
зведення до мінімуму людського фактора при формуванні статистичних звітів,
відомостей та аналітичних довідок для контролюючих органів чи
акредитаційних комісій.
Для науково-педагогічних працівників (Викладачів) дана система є
інструментом оптимізації робочого часу. Звільнення викладача від рутинної
процедури переклички на початку заняття, що дозволяє раціонально
використовувати кожну хвилину аудиторного часу для викладання дисципліни.
Спрощення обліку шляхом надання зручного, адаптивного веб-інтерфейсу
(електронного журналу) сприятиме фіксації присутніх/відсутніх у кілька кліків з
будь-якого пристрою. Накопичення історії через автоматичне збереження історії
Арк.
ЧДТУ 262214.001 ПЗ 8
Змн. Арк. № докум. Підпис Дата
відвідувань полегшує виставлення балів за поточну активність або
автоматичний допуск до заліку/іспиту.
Для здобувачів вищої освіти (Студентів) дана система забезпечить
можливості прозорості та самоконтролю. Забезпечення доступу до
персонального кабінету, де студент чітко бачить свою статистику відвідувань,
поточний рейтинг та наявність пропусків, які потребують відпрацювання.
Дисциплінарна мотивація сприятиме формуванню у студентів розуміння
неминучості фіксації пропусків, що стимулює їх до систематичного
відвідування занять та підвищує рівень виконавчої дисципліни. Зручність
комунікації є можливістю оперативного завантаження електронних копій
виправдовувальних документів (довідок про хворобу, заяв тощо) через веб-
інтерфейс.
Отже, перевага запропонованої системи полягає у синергетичному
ефекті: оптимізація менеджменту ЗВО та економії часу викладача, а також
підвищення відповідальності студента забезпечить можливості суттєвого
покращення загальної якості та результативності освітнього процесу в
університеті.
Успішна інтеграція web-орієнтованої системи контролю відвідуваності в
освітній простір ЗВО та її довгострокова ефективність залежать від виконання
низки ключових технологічних, організаційних та користувацьких критеріїв.
Основними ключами до успіху розробки та впровадження системи є:
1. Кросплатформність та адаптивність дизайну (Mobile-First). Більшість
викладачів та студентів взаємодіють із веб-ресурсами через смартфони та
планшети безпосередньо в аудиторіях. Ключем до успіху є створення
адаптивного інтерфейсу, який однаково коректно та швидко працює на будь-
якому типі пристроїв та за будь-якої роздільної здатності екрана без
необхідності встановлення важких мобільних додатків.
2. Простота та швидкість взаємодії (UX/UI). Якщо процес фіксації
відвідуваності у системі вимагатиме від викладача багато кліків, довгих пошуків
Арк.
ЧДТУ 262214.001 ПЗ 9
Змн. Арк. № докум. Підпис Дата
груп чи постійного перезавантаження сторінок, система викличе спротив і не
приживеться. Інтерфейс електронного журналу має бути максимально
інтуїтивним: виставлення відміток для всієї групи має здійснюватися в 1–2
кліки, мінімізуючи витрати часу до кількох секунд.
3. Інтеграційний потенціал. Система не повинна існувати ізольовано.
Ключовим фактором успіху є її здатність легко інтегруватися з наявною
інфраструктурою ЗВО: базами даних деканату, електронним розкладом,
корпоративною поштою та системами авторизації (наприклад, Active Directory,
Google Workspace або Office 365). Це виключає потребу ручного дублювання
списків студентів та груп.
4. Безпека даних та надійність логування. Дані про відвідуваність
впливають на допуск до сесії, виплату стипендій та відрахування, що робить їх
потенційним об'єктом для маніпуляцій. Успішна система повинна мати жорстке
розмежування прав доступу (рольова модель), захист від несанкціонованого
доступу та обов'язкове логування (аудит) дій користувачів — фіксацію того,
який саме викладач, з якої IP-адреси та в який час виставив або змінив відмітку.
5. Гнучкість аналітики та автоматизація звітності.
Просте збереження «Н-ок» у базі даних не має високої управлінської
цінності. Система досягає успіху тоді, коли вона самостійно перетворює сирі
дані на корисну аналітику: будує графіки відвідуваності, автоматично
підраховує відсоток пропусків та миттєво генерує готові звіти для деканату за
тиждень, місяць чи семестр у форматах PDF або Excel.
6. Психологічна готовність та адміністративна підтримка. Будь-яка
автоматизація стикається із людським фактором (небажанням персоналу
змінювати звичні методи роботи). Ключем до успіху є наявність чіткого
регламенту від адміністрації ЗВО, проведення коротких навчальних тренінгів
для викладачів та забезпечення технічної підтримки на перших етапах
впровадження.
Основними інструментами управління виконанням проєкту є [3]:
Арк.
ЧДТУ 262214.001 ПЗ 10
Змн. Арк. № докум. Підпис Дата
- автоматизація процесів освітньої діяльності;
- документарне, нормативно-правове, кадрове, технологічне та
фінансове забезпечення усіх етапів робіт та процесів за проєктом;
- контроль за усіма видами діяльності, ходом робіт, діяльністю
відповідальних осіб, виконавців, підрядників;
- встановлення послідовності виконання робіт за проєктом та
дотримання неї;
- розподіл завдань між виконавцями різного типу та контроль за
своєчасністю їх виконання;
- використання фінансових та організаційних важелів впливу на
виконавців окремих видів робіт за проєктом, постачальників, інших пов’язаних
сторін [4];
- контроль за якістю отриманого продукту;
- постійне вдосконалення продукту на етапі експлуатації.
Проєкт полягає у створенні мобільних додатків, які дозволяють
автоматизувати перевірку наявності учнів чи студентів освітніх закладів на
заняттях. Робиться це для того, щоб викладачеві надати допомогу при веденні
обліку присутності студентів чи учнів на заняттях для спрощення контролю.
Продукт проєкту складатиметься з:
• сайту;
• мобільного додатку для Android
• мобільного додатку для iOS;
• мобільного додатку для Windows Phone;
• системи моніторингу;
• системи технічного обслуговування;
• системи захисту від шахраїв.
До продукту проєкту висуваються наступні вимоги:
1. Висока швидкодія.
2. Оперативне оновлення інформації.
Арк.
ЧДТУ 262214.001 ПЗ 11
Змн. Арк. № докум. Підпис Дата
3. Висока кваліфікація працівників.
4. Достовірність інформації, що публікується на сайті.
5. Цілодобова доступність для користувача.
6. Постійне удосконалення та розвиток технічної бази.
7. Простота та зручність для кінцевого користувача.
8. Комфортні умови праці для обслуговуючого персоналу.
9. Бездефектність транзакцій системи оплати.
1.2 Аналіз існуючих аналогів на ринку
Для обґрунтування архітектури та функціоналу розроблюваної web-
орієнтованої системи необхідно провести критичний аналіз існуючих рішень,
які сьогодні використовуються у закладах вищої освіти для обліку
відвідуваності. На практиці застосовуються три основні групи рішень:
традиційні (паперові), універсальні хмарні інструменти та інтегровані модулі
великих LMS-систем.
1. Традиційні паперові журнали.
Цей підхід досі залишається базовим у багатьох консервативних ЗВО.
Староста групи або викладач вручну фіксує відсутніх у паперовому журналі,
дані з якого наприкінці тижня чи місяця передаються до деканату у вигляді
зведених паперових документів.
Перевагами такого підходу є можливості уникнення потреби
комп'ютерної техніки, нульова залежність від наявності електроенергії чи
інтернету.
Недоліком є колосальні витрати аудиторного часу; затримка передачі
даних до деканату (від 1 тижня до місяця); висока ймовірність механічних
помилок, втрати паперів або фальсифікації («закриття» прогулів знайомими);
повна відсутність оперативної аналітики.
2. Модуль «Attendance» (Відвідуваність) у LMS Moodle .
Арк.
ЧДТУ 262214.001 ПЗ 12
Змн. Арк. № докум. Підпис Дата
Moodle є найпопулярнішою платформою дистанційного навчання в
українських ЗВО. Вона має стандартний плагін для фіксації присутності
студентів на заняттях.
Перевагою є інтеграція з навчальними курсами ЗВО; можливість для
студента самостійно відмітити себе за допомогою спеціального пароля чи
тимчасового коду, наданого викладачем.
Недоліками є те, що інтерфейс Moodle є перевантаженим та морально
застарілим, він не адаптований під концепцію Mobile-First (незручно
використовувати зі смартфона на парі). Система орієнтована на оцінювання, а
не на глобальну адміністративну аналітику для деканату. Генерація зведених
звітів по всьому факультету чи університету є складною і вимагає глибоких
прав доступу адміністратора платформи.
3. Універсальні хмарні сервіси (Google Таблиці / Google Форми).
Багато прогресивних викладачів під час пандемії та впровадження
воєнного стану перейшли на використання Google-інструментів. Викладач
створює онлайн-таблицю для кожної групи або пропонує студентам заповнити
Google-форму на початку лекції.
Перевагою є безкоштовність, швидкість розгортання, доступ з будь-
якого пристрою, можливість спільного редагування.
Серед недоліків варто виділити повну відсутність централізації (у
кожного викладача свій файл); неможливо автоматично звести дані сотень
викладачів в один звіт для деканату. Високий ризик шахрайства: студенти
можуть пересилати посилання на Google-форму своїм одногрупникам, які
перебувають поза межами аудиторії чи взагалі не підключені до заняття.
4. Комерційні ERP-системи для ЗВО (наприклад, "Політек-Софт",
"Деканат" тощо).
Великі комплексні інформаційні системи, які автоматизують роботу
всього університету, часто містять підсистему електронного журналу.
Арк.
ЧДТУ 262214.001 ПЗ 13
Змн. Арк. № докум. Підпис Дата
Перевагою таких систем є глибока інтеграція з базою даних студентів
та розкладом.
Серед недоліків виділяють надзвичайно високу вартість ліцензій та
впровадження; громіздка десктопна архітектура або складний веб-інтерфейс,
який вимагає тривалого навчання персоналу; низька швидкість роботи на
слабких пристроях.
Для наочності результати аналізу існуючих рішень зведені у порівняльну
таблицю (табл.1.1). Оцінювання проведено за 5-бальною шкалою (де 5 —
найвищий рівень відповідності критерію, 1 — найнижчий).
Таблиця 1.1. Порівняльна таблиця аналогів.
Критерій Паперовий Модуль Google Комерційні Проектована
порівняння облік Moodle Інструменти ERP система
Швидкість 2 3 4 2 5
фіксації на парі
Зручність для 1 2 4 2 5
смартфонів
Оперативна 1 3 1 5 5
аналітика для
деканату
Захист від 2 4 2 4 5
фальсифікацій
Простота 5 2 4 1 5
інтерфейсу
(UX/UI)
Централізація 1 4 1 5 5
даних
Жодне з існуючих на ринку рішень повною мірою не задовольняє вимог
сучасного ЗВО щодо швидкості, мобільності та захищеності процесу фіксації
відвідуваності. Це підтверджує доцільність розробки спеціалізованої,
полегшеної web-орієнтованої інформаційної системи, яка поєднає простоту
Арк.
ЧДТУ 262214.001 ПЗ 14
Змн. Арк. № докум. Підпис Дата
використання зі смартфона (UX/UI) та потужний аналітичний інструментарій
для адміністрації.
Також можна виділити наступні міжнародні спеціалізовані сервіси:
MyAttendanceTracker [5] є популярним англомовним веб-сервісом, що
орієнтований суто на облік відвідуваності у класах та студентських групах
(рис.1.1).
Рисунок 1.1. Головна сторінка сервісу MyAttendanceTracker.
o Плюси: повністю хмарний інтерфейс, можливість відмічати
присутніх у клік або через сканування штрих-кодів/QR-кодів,
генерація звітів у формати PDF та Excel.
o Мінуси: відсутня глибока аналітика для деканатів (сервіс заточений
під окремих викладачів), немає української локалізації, складно
інтегрувати з українськими університетськими реєстрами (ЄДЕБО).
Edusign [6] є потужною європейською SaaS-платформою для автоматизації
відвідуваності в університетах та школах.
Арк.
ЧДТУ 262214.001 ПЗ 15
Змн. Арк. № докум. Підпис Дата
Рисунок 1.2. Головна сторінка платформи Edusign.
o Плюси: студенти чекіняться на парах через динамічні QR-коди, є
окремий модуль для завантаження студентами офіційних довідок
про хворобу або пропуски.
o Мінуси: платний комерційний продукт, висока вартість підписки,
складна інтеграція із локальними базами даних ЗВО [6].
Серед українські систем та платформ варто виділити НUMAN Школа /
Освіта [7]. Це відома українська освітня екосистема, що включає модулі
аналітики, електронних журналів та розкладу. Головна сторінка представлена на
рис. 1.3.
Рисунок 1.3. Головна сторінка платформи НUMAN.
Арк.
ЧДТУ 262214.001 ПЗ 16
Змн. Арк. № докум. Підпис Дата
o Плюси: повністю адаптована під законодавство України, гарний та
зрозумілий інтерфейс (UX/UI), автоматично будує статистику для
адміністрації (рис.1.4).
o Мінуси: платформа розроблялася переважно для закладів загальної
середньої освіти (шкіл) та коледжів. Вона погано враховує
специфіку великих університетів (наприклад, поділ на
лекції/практики, чисельник/знаменник у розкладі, потокові лекції на
кілька груп одночасно).
Рисунок 1.4. Функціонал платформи НUMAN.
Електронні журнали внутрішніх КІС (на прикладі НАУ, ХНУРЕ, НУБіП)
характеризують більшість провідних українських ЗВО, що розробляють власні
локальні веб-сайти «Електронний кампус» або «Особистий кабінет викладача»
(на базі систем "Деканат" або внутрішніх розробок).
o Плюси: повна інтеграція з базою даних студентів закладу та
офіційним розкладом.
o Мінуси: морально застарілий інтерфейс, який зазвичай розроблявся
багато років тому. Сайти часто не адаптовані для смартфонів
Арк.
ЧДТУ 262214.001 ПЗ 17
Змн. Арк. № докум. Підпис Дата
(викладачу важко відкрити велику таблицю на парі з телефона),
відсутні сучасні методи автоматизації (студент не може сам
відмітити себе через QR-код) [7].
Під час дослідження ринку програмного забезпечення було
проаналізовано спеціалізовані закордонні веб-платформи, такі як
MyAttendanceTracker та Edusign, які демонструють високу ефективність
використання QR-кодів для чекіну студентів. Проте їх впровадження в
українських ЗВО обмежене через відсутність інтеграції з вітчизняними
реєстрами та мовними бар'єрами. З іншого боку, вітчизняні рішення, такі як
HUMAN Освіта або внутрішні електронні журнали університетів, часто
орієнтовані на шкільну модель навчання або мають застарілий веб-інтерфейс,
який не забезпечує концепцію мобільності викладача безпосередньо в аудиторії.
Це обумовлює необхідність створення власної гнучкої web-орієнтованої
системи.
1.3 Постановка задачі
На основі проведеного аналізу діяльності закладів вищої освіти,
визначення критеріїв успішності та дослідження існуючих ринкових аналогів,
формулюється завдання на проектування та розробку web-орієнтованої
інформаційної системи контролю відвідування занять студентами.
Головне інженерне завдання полягає у створенні трирівневого веб-
додатка (клієнтська частина, серверна частина, база даних), який забезпечить
автоматизацію обліку присутності студентів, матиме адаптивний дизайн для
зручної роботи з мобільних пристроїв та надаватиме інструменти аналітики для
адміністрації ЗВО.
Функціональні вимоги до системи за ролями користувачів базуються на
наступних засадах. Система повинна реалізовувати рольову модель доступу із
розмежуванням прав для трьох основних категорій користувачів:
1. Модуль «Адміністратор / Деканат»:
Арк.
ЧДТУ 262214.001 ПЗ 18
Змн. Арк. № докум. Підпис Дата
- управління структурою ЗВО: можливість створення, редагування та
видалення записів про факультети, кафедри, академічні групи, навчальні
дисципліни та аудиторії;
- керування користувачами: імпорт та реєстрація списків студентів і
викладачів, призначення та зміна прав доступу;
- глобальний моніторинг: перегляд зведеної статистики відвідуваності
в розрізі всього ЗВО, окремого курсу, групи чи студента за обраний період
(тиждень, місяць, семестр);
- експорт звітів: автоматичне формування та завантаження
аналітичних відомостей у форматах PDF та Excel для подальшого
використання у документообігу ЗВО.
2. Модуль «Викладач»:
- управління журналами: доступ до списку закріплених за викладачем
груп та дисциплін відповідно до розкладу;
- фіксація відвідуваності: зручний інтерфейс електронного журналу,
що дозволяє виставляти відмітки про присутність («Присутній», «Н» —
відсутній, «З» — запізнився) в один-два кліки;
- генерація індивідуальних кодів: можливість створення тимчасового
QR-коду або пароля для пари, щоб студенти могли самостійно зафіксувати
свою присутність;
- корекція даних: можливість редагування відміток (наприклад, у разі
надання студентом довідки) із обов'язковим зазначенням причини зміни.
3. Модуль «Студент»:
- персональний кабінет: відображення індивідуального профілю,
поточної групи та списку дисциплін;
- самоконтроль: перегляд власної детальної статистики відвідуваності
з графічним відображенням відсотка пропущених занять;
- модуль «Чек-ін»: можливість сканування QR-коду викладача через
веб-інтерфейс для швидкої автоматичної відмітки на занятті;
Арк.
ЧДТУ 262214.001 ПЗ 19
Змн. Арк. № докум. Підпис Дата
- зворотний зв'язок: інтерфейс для завантаження скан-копій або
фотографій документів (наприклад, медичних довідок), що
підтверджують поважну причину відсутності.
Система характеризується наступними еефункціональними (системно-
технічні) вимогами:
1. кросплатформність, тобто система повинна стабільно функціонувати у
всіх сучасних веб-браузерах (Google Chrome, Mozilla Firefox, Safari,
Microsoft Edge);
2. адаптивність (Mobile-First), де графічний інтерфейс має динамічно
підлаштовуватися під екрани смартфонів та планшетів без втрати
читабельності та зручності натискання елементів журналу;
3. безпека та аудит, коли паролі користувачів повинні зберігатися в базі
даних у зашифрованому вигляді за допомогою сучасних хеш-алгоритмів
(наприклад, bcrypt). Будь-яка зміна відмітки в журналі має
супроводжуватися логуванням дій (хто змінив, коли і яка відмітка була
раніше);
4. швидкодія, тобто час відклику системи (завантаження сторінки журналу
групи) не повинен перевищувати 1.5–2 секунд за умов стандартного 3G/4G
або Wi-Fi з'єднання.
Функціонування web-орієнтованої системи контролю відвідуваності
базується на взаємодії трьох основних потоків даних: адміністративного,
операційного (процес фіксації) та аналітичного. Складові архітектури бізнес-
процесів системи розподіляються на чотири ключові цикли:
1. Бізнес-процес «Ініціалізація та налаштування освітнього простору» є
базовим, де виконується на початку кожного навчального семестру та керується
виключно Адміністратором (Деканатом):
- внесення структури передбачає створення та іпортування
адміністратором з зовнішніх реєстрів актуальних списків
факультетів, кафедр та академічних груп;
Арк.
ЧДТУ 262214.001 ПЗ 20
Змн. Арк. № докум. Підпис Дата
- формування контингенту реалізується у систему завантажуються
облікові записи викладачів та студентів із прив'язкою останніх до
конкретних груп;
- завантаження розкладу, тобто створюється цифровий розклад занять
(Дисципліна — Викладач — Група — Дата/Час — Тип пари).
2. Бізнес-процес «Фіксація відвідуваності занять» (Операційний цикл) є
основним щоденним процесом, який має два альтернативні сценарії реалізації:
 Сценарій А (Класичний — ручний ввід викладачем):
1. Викладач авторизується в системі через смартфон або ПК
безпосередньо в аудиторії.
2. Система автоматично підтягує поточну пару згідно з розкладом.
3. Викладач відкриває інтерактивний список групи та проставляє
відмітки («Н» або «З») навпроти прізвищ студентів.
4. Викладач натискає кнопку «Зберегти», після чого дані миттєво
записуються в базу даних.
 Сценарій Б (Автоматизований — через QR-код/Чек-ін):
1. Викладач на початку пари натискає кнопку «Згенерувати QR-код».
Система створює унікальний токен пари з обмеженим часом дії
(наприклад, 5 хвилин).
2. Студенти в аудиторії відкривають систему на своїх смартфонах,
активують камеру та сканують QR-код.
3. Система перевіряє валідність коду (і, за наявності модуля,
геолокацію студента) та автоматично змінює статус студента на
«Присутній».
4. Після закінчення дії коду всім, хто не пройшов чек-ін, система
автоматично виставляє статус «Н».
3. Бізнес-процес «Обробка виправдовувальних документів та корекція»
регулює взаємодію між Студентом, Викладачем та Деканатом у разі пропуску
занять з поважних причин:
Арк.
ЧДТУ 262214.001 ПЗ 21
Змн. Арк. № докум. Підпис Дата
1. Студент через персональний кабінет завантажує фото/скан-копію
медичної довідки або заяви та вказує період відсутності.
2. Співробітник Деканату отримує сповіщення, перевіряє документ та
змінює його статус на «Затверджено».
3. Система автоматично маркує відповідні «Н-ки» студента в журналах
усіх викладачів за цей період як пропуски «З поважної причини»
(наприклад, змінює статус на «Н/П»).
4. Бізнес-процес «Моніторинг та генерація аналітичної звітності»
забезпечує закриття інформаційних потреб Адміністрації та Кураторів:
1. Система у фоновому режимі постійно калькулює відсотки
відвідуваності по кожному студенту, групі та факультету.
2. При досягненні студентом критичного порогу пропусків (наприклад,
більше 20% годин без поважної причини), система автоматично маркує
його профіль червоним кольором («Група ризику») та надсилає
сповіщення куратору.
3. За запитом користувача (Деканату) система агрегує дані за обраний
період та формує зведений звіт (наприклад, «Відомість пропусків за
жовтень») для експорту в Excel/PDF.
Продукт проєкту буде актуальним для наступних видів споживачів:
1. Учні та студенти – складатимуть основний потік користувачів,
отримуватимуть інформацію про свої прогули та час, коли їх можна
відпрацювати.
2. Вчителі – також складатимуть чималу кількість користувачів,
матимуть всю інформацію про своїх учнів та їх відвідування.
3. Навчальні заклади – матимуть базу даних всіх учнів і вчителів.
Продукт призначений для навчальних закладів, відсутня залежність від
статі та стилю життя. Користувачами даного продукту будуть самі студенти та
вчителі, що будуть контролювати відвідуваність.
Арк.
ЧДТУ 262214.001 ПЗ 22
Змн. Арк. № докум. Підпис Дата
Для досягнення даної мети, основну ціль розбито на підцілі та створено
ієрархічну структуру - дерево цілей (графічне зображення взаємозв'язку і
підпорядкованості цілей, що відображає розподіл місії і мети на цілі, під цілі,
завдання та окремі дії), що зображено на рис. 1.5.
Рисунок 1.5. Графічне зображення взаємозв'язку і підпорядкованості цілей.
Основні вимоги та завдання:
а) Front-end частина
• Розробити домашню сторінку, яка матиме привабливий інтерфейс.
• Реалізувати просту форму для створення списку груп/класів,
студентів/учнів.
• Розробка та реалізація адаптивного інтерфейсу панелі керування
користувача.
Арк.
ЧДТУ 262214.001 ПЗ 23
Змн. Арк. № докум. Підпис Дата
• Створити ергономічні регулярні нагадування про час відробіток
прогулів.
б) Back-end частина
• Забезпечення підтримки багатьох функцій шляхом створення
відповідного модуля
• Розробка модуля для повідомлення про прогули.
• Створити алгоритми збору статистики та аналізу відвідуваності.
в) Маркетинг та SEO-оптимізація
• На основі маркетингового досідження, написати SEO-текст для
збільшення кількості користувачів
• Проводити опитування користувачів та працювати над
вдосконаленням продукту на основі проведених опитувань
• Підготувати та провести маркетингову кампанію
1.4 Висновки до розділу 1
Впровадження веб-орієнтованої системи контролю відвідуваності є
критично важливою умовою для цифрової трансформації сучасного закладу
вищої освіти. Традиційні паперові журнали та ручний збір статистики вже не
відповідають темпам розвитку академічного середовища, оскільки вони
призводять до значних втрат робочого часу викладачів і створюють ризик
помилок через людський чинник. Перехід на автоматизований цифровий облік
дозволяє миттєво отримувати точні дані, що кардинально спрощує роботу
деканатів, кураторів та адміністрації.
Значення такої системи для університету полягає у створенні прозорого
та оперативного інформаційного простору. Керівництво закладу отримує
потужний інструмент аналітики для моніторингу якості освітнього процесу,
виявлення проблемних тенденцій на ранніх етапах та швидкого реагування на
хронічні прогули студентів. Це безпосередньо впливає на підвищення
навчальної дисципліни, зменшує відсоток відрахувань та оптимізує розподіл
бюджетних коштів, наприклад, при нарахуванні стипендій. У підсумку,
Арк.
ЧДТУ 262214.001 ПЗ 24
Змн. Арк. № докум. Підпис Дата
цифровізація цього процесу не лише полегшує бюрократичне навантаження, але
й суттєво зміцнює загальний рейтинг та престиж закладу вищої освіти на ринку
освітніх послуг.
В першому розділі кваліфікаційної роботи здійснено опис предметної
області, аналітичний огляд існуючих систем та засобів вітчизняних та
іноземних, виконано поставку задачі розробки.
Арк.
ЧДТУ 262214.001 ПЗ 25
Змн. Арк. № докум. Підпис Дата
2 ПРОЄКТУВАННЯ WEB-ОРІЄНТОВАНОЇ ІНФОРМАЦІЙНОЇ
СИСТЕМИ КОНТРОЛЮ ВІДВІДУВАННЯ ЗАНЯТЬ СТУДЕНТАМИ
2.1 Архітектура web-орієнтованої інформаційної системи
Для проектування ефективної web-орієнтованої інформаційної системи
контролю відвідуваності найкраще підходить сучасна багаторівнева архітектура
(Multi-tier Architecture) [8]. Вона розділяє систему на незалежні шари, що
забезпечує гнучкість розробки, безпеку даних та легке масштабування.
Загальна схема архітектури є Клієнт-Сервер. Система будується за
принципом розподілу обов'язків і складається з трьох основних рівнів (рис.2.1):
Клієнтський рівень (Frontend)
HTTPS / REST API або WebSockets
Серверний рівень (Backend / API Gateway) Модуль бізнес-
SQL / ORM запити логіки
Рівень даних (Database / Storage)
Рисунок 2.1. Загальна схема архітектури web-орієнтованої ІС.
В даній архітектурі клієнтський рівень (Presentation Tier / Frontend)
відповідає за взаємодію з користувачем (інтерфейс) та відображення даних.
Оскільки система веб-орієнтована, доступ до неї здійснюється через брузери на
ПК, планшетах або смартфонах.
Арк.
ЧДТУ 262214.001 ПЗ 26
Змн. Арк. № докум. Підпис Дата
Технологічна концепція передбачає SPA (Single Page Application) —
односторінковий додаток, який завантажується один раз і динамічно оновлює
дані без перезавантаження сторінок.
Компоненти інтерфейсу наступні:
o Кабінет викладача: інтерактивні сітки розкладу, електронні
журнали з можливістю швидкого кліку/тапу для виставлення "н-ок".
o Кабінет студента: персональний дашборд зі статистикою
відвідуваності у вигляді графіків, форма завантаження медичних
довідок.
o Панель адміністратора/деканату: генератори зведених звітів,
графіки відвідуваності по кафедрах і потоках.
Серверний рівень (Application Tier / Backend) приймає запити від
клієнтської частини, обробляє їх, перевіряє права доступу та виконує основні
обчислення (бізнес-логіку).
API Gateway (Шлюз API) є єдиною точкою входу для клієнтських
запитів. Він відповідає за маршрутизацію запитів, автентифікацію користувачів
та захист від DDOS-атак.
Ядро бізнес-логіки (Application Logic) містить програмні алгоритми
системи, такі як:
o Модуль авторизації (перевірка ролей: студент, викладач, декан).
o Модуль обробки відвідуваності (валідація геопозиції при скануванні
QR-коду, фіксація часу запізнення).
o Модуль генерації звітів (формування PDF/Excel відомостей для
стипендіальної комісії).
o Модуль нотифікацій (автоматичне надсилання повідомлень про
критичну кількість пропусків).
На рівені даних (Data Tier) забезпечується надійне, безпечне та
структуроване зберігання всієї інформації системи. Реляційна база даних (РБД)
зберігає пов'язані дані (студенти, викладачі, групи, предмети, розклад, журнал
Арк.
ЧДТУ 262214.001 ПЗ 27
Змн. Арк. № докум. Підпис Дата
відвідуваності). Використання транзакцій гарантує, що дані не втратяться під
час одночасного внесення відміток кількома викладачами. Файлове сховище
(Object Storage) є окремою захищеною директорією або хмарне сховище для
збереження завантажених студентами сканованих копій документів (довідок,
пояснювальних записок). Кеш-пам'ять (In-Memory Database) використовується
для збереження сесій користувачів та кешування розкладу на поточний день,
щоб знизити навантаження на основну базу даних під час пікових годин
(наприклад, на початку кожної пари).
Аспекти безпеки та інтеграції передбачають протокол зв'язку, де весь
обмін даними між клієнтом та сервером шифрується за допомогою протоколу
HTTPS (SSL/TLS). Авторизація реалізується за допомогою токенів (наприклад,
JWT — JSON Web Tokens), що дозволяє користувачу залишатися в системі без
необхідності постійно вводити пароль. Інтеграційний шар (API) архітектури
передбачає підключення до зовнішніх систем ЗВО (наприклад, до існуючої бази
даних студентів "деканат" або системи електронного розкладу) для уникнення
дублювання інформації [9].
Забезпечення простоти налаштування (конфігурованості) на задане
системне програмне забезпечення є критично важливим критерієм
якостіархітектури ІС. Оскільки університети можуть використовувати різні
сервери, операційні системи чи версії баз даних, бекенд повинен розроблятися за
принципом незалежності від середовища (Environment Independence).
Для реалізації цього принципу в архітектуру закладаються такі технічні
рішення [10]:
1. Екстракція конфігурації (Принцип «12-Factor App»). Усі
налаштування системи виносяться за межі програмного коду. Жодні паролі,
IP-адреси, порти чи ключі доступу не прописуються "жорстко" в коді
(Hardcoding). Для локального розгортання використовуються файли змінних
середовища. Змінні оточення (Environment Variables) при запуску на сервері
ЗВО бекенд автоматично зчитує глобальні змінні ОС (наприклад,
Арк.
ЧДТУ 262214.001 ПЗ 28
Змн. Арк. № докум. Підпис Дата
DATABASE_URL, SERVER_PORT, JWT_SECRET). Це дозволяє змінювати
параметри системи без перекомпіляції чи зміни коду.
2. Контейнеризація за допомогою Docker, тобто для усунення
проблеми «на моєму комп'ютері все працювало, а на сервері університету не
запускається» застосовується контейнеризація. Бекенд, разом із усіма
залежностями, системними бібліотеками та потрібною версією мови
програмування (наприклад, Node.js або Python), упаковується в ізольований
контейнер. Docker Compose дозволяє однією командою (docker-compose up)
розгорнути готову інфраструктуру: сам бекенд, базу даних PostgreSQL та кеш-
сервер Redis. Це зводить налаштування системи системним адміністратором
ЗВО до кількох хвилин.
3. Система не повинна залежати від конкретної системи управління
базами даних (MySQL, PostgreSQL, MS SQL Server). Використання ORM
(Object-Relational Mapping) для роботи з даними йде через об'єктні моделі.
Якщо університет вирішить перейти з безкоштовної PostgreSQL на
корпоративну Oracle, у коді бекенду не доведеться переписувати жодного
SQL-запиту — достатньо змінити один рядок у налаштуваннях драйвера
підключення. Бекенд сам керує структурою бази даних. При першому запуску
на новому сервері система автоматично створить усі необхідні таблиці,
індекси та зв'язки.
4. Кросплатформеність runtime-середовища передбачає вибір
технологічної платформи для бекенду (наприклад, Node.js, .NET Core або
Python). Це гарантує, що серверна частина буде однаково стабільно
працювати як на серверах під управлінням Linux (Ubuntu, Debian, CentOS), так
і на Windows Server, які часто розгорнуті в українських ЗВО.
2.2 Проєктування бази даних
Проєктування бази даних (БД) є фундаментом всієї системи, оскільки від
правильності побудови її структури залежить швидкість виконання запитів,
Арк.
ЧДТУ 262214.001 ПЗ 29
Змн. Арк. № докум. Підпис Дата
цілісність інформації та відсутність дублювання даних [11]. Для web-
орієнтованої ІС контролю відвідуваності занять студентами найкраще підходить
реляційна модель даних (наприклад, на базі PostgreSQL або MySQL), оскільки
сутності навчального процесу мають чіткі та жорсткі зв'язки (рис.2.2).
Рисунок 2.2. Модель бази даних web-орієнтованої ІС
Логічна модель бази даних складається з наступних таблиць:
Арк.
ЧДТУ 262214.001 ПЗ 30
Змн. Арк. № докум. Підпис Дата
1. Таблиця USERS (Користувачі). Зберігає облікові дані всіх учасників
системи. Рольова модель (role) розмежовує права доступу. Для студентів
обов'язково заповнюється зовнішній ключ group_id. Містить наступні
поля:
id (INT, Primary Key, Auto Increment) — унікальний ідентифікатор.
email (VARCHAR, Unique) — корпоративна пошта (логін).
password_hash (VARCHAR) — зашифрований пароль.
role (ENUM: 'student', 'teacher', 'dean', 'admin') — роль у системі.
created_at (TIMESTAMP) — дата створення акаунту.
2. Таблиця GROUPS (Академічні групи). Містить перелік груп університету
із прив'язкою до конкретної кафедри/факультету (department_id).
Складається з наступних полів:
id (INT, Primary Key) — унікальний ідентифікатор.
group_name (VARCHAR, Unique) — шифр групи (наприклад,
"КН-401")
curator_id (INT, Foreign Key -> teachers.id) — посилання на куратора
групи.
3. Таблиця DEPARTMENTS (Кафедри/Факультети). Організаційна
структура ЗВО для групування аналітики деканатом. Містить поля:
id (INT, Primary Key) — унікальний ідентифікатор.
user_id (INT, Foreign Key -> users.id, Unique) — зв'язок з обліковим
записом.
group_id (INT, Foreign Key -> groups.id) — зв'язок з групою студента.
first_name (VARCHAR) — ім'я.
last_name (VARCHAR) — прізвище.student_ticket (VARCHAR, Unique)
— номер студентського квитка.
4. Таблиця DISCOURSES (Дисципліни). Перелік навчальних предметів, що
викладаються в університеті (наприклад, "Архітектура ПЗ", "Бази даних").
Поля даної таблиці наступні:
Арк.
ЧДТУ 262214.001 ПЗ 31
Змн. Арк. № докум. Підпис Дата
id (INT, Primary Key) — унікальний ідентифікатор.
subject_name (VARCHAR) — назва дисципліни (наприклад, "Веб-
технології").
5. Таблиця SCHEDULES (Розклад/Заняття). Ключова таблиця розкладу.
Поєднує в собі інформацію про те, який викладач, для якої групи, яку
дисципліну, коли і в якій аудиторії викладає. Містить поля:
id (INT, Primary Key) — унікальний ідентифікатор.
subject_id (INT, Foreign Key -> subjects.id) — який предмет
викладається.
teacher_id (INT, Foreign Key -> teachers.id) — хто веде пару.
group_id (INT, Foreign Key -> groups.id) — яка група навчається.
lesson_date (DATE) — дата проведення.
lesson_number (INT) — номер пари (1, 2, 3, 4 тощо).room (VARCHAR)
— номер аудиторії або посилання на онлайн-лекцію (Zoom/Teams).
6. Таблиця ATTENDANCE (Журнал відвідуваності). Зберігає фінальні
відмітки про присутність. Вона пов'язує конкретне заняття з розкладу
(schedule_id) та конкретного студента (student_id). Поля modified_by та
updated_at відповідають за нефункціональну вимогу безпеки (аудит та
логування змін):
id (INT, Primary Key) — унікальний ідентифікатор
lesson_id (INT, Foreign Key -> lessons.id) — на якій саме парі.
student_id (INT, Foreign Key -> students.id) — який студент.
status (ENUM: 'present', 'absent', 'late', 'excused') — статус (присутній,
відсутній, запізнився, поважна причина).
marked_at (TIMESTAMP) — точний час виставлення відмітки.
marked_by (INT, Foreign Key -> users.id) — ID того, хто виставив
(викладач або автоматично через QR).
document_url (VARCHAR, Nullable) — посилання на скан довідки,
якщо причина пропуску поважна.
Арк.
ЧДТУ 262214.001 ПЗ 32
Змн. Арк. № докум. Підпис Дата
7. Таблиця DOCUMENTS (Документи, що пояснюють відсутність
здобувача). Зберігає інформацію про завантажені студентами медичні
довідки. Якщо статус змінюється на Approved, система автоматично
оновить відповідні записи у таблиці ATTENDANCE на статус Excused
(Поважна причина):
id (INT, Primary Key) — унікальний ідентифікатор документа.
student_id (INT, Foreign Key -> USERS.id) — посилання на студента,
який надав документ.file_url (VARCHAR) — шлях до завантаженого
файлу в об'єктному сховищі.
document_type (ENUM: 'medical', 'statement', 'other') — тип документа.
start_date (DATE) — дата початку дії документа (з якого числа діє
звільнення).
end_date (DATE) — дата завершення дії документа.status (ENUM:
'pending', 'approved', 'rejected') — статус верифікації документа
деканатом чи куратором.
verified_by (INT, Foreign Key -> USERS.id, Nullable) — ID
співробітника, який перевірив і затвердив документ.
2.3 Вибір засобів розробки web-орієнтованої ІС
Обґрунтований вибір технологічного стеку безпосередньо впливає на
швидкість розробки, масштабованість, безпеку та простоту розгортання системи
на серверах ЗВО. Враховуючи вимоги щодо простоти налаштування,
кросплатформеності та високих навантажень під час початку пар, нижче
наведено оптимальний вибір засобів розробки.
Серверна частина (Backend) базується на застосуванні технології Node.js
із використанням фреймворку NestJS та мови TypeScript. Це забезпечить
можливості на основі подійно-орієнтованій архітектури (Event-driven
Architecture) платформі легко витримує тисячі одночасних запитів, коли
студенти масово сканують QR-коди або відмічаються на початку пари. NestJS є
Арк.
ЧДТУ 262214.001 ПЗ 33
Змн. Арк. № докум. Підпис Дата
прогресивним фреймворком, який змушує розробника будувати чітку
архітектуру за замовчуванням (розділення на контролери, сервіси та модулі). Це
спрощує підтримку коду іншими програмістами. Строга типізація TypeScript
мінімізує кількість помилок на етапі написання коду, що критично для систем,
які працюють із персональними даними.
Для розробки клієнтської частини (Frontend) обрана технологія React.js
(мова TypeScript) + Tailwind CSS. React.js дозволяє створити Single Page
Application (SPA), де користувач взаємодіє із системою без постійного
перезавантаження сторінок. Компонентний підхід дозволяє
перевикористовувати елементи інтерфейсу (наприклад, таблицю журналу чи
картку студента). Tailwind CSS забезпечує швидку утилітарну стилізацію.
Інтерфейс системи буде адаптивним "з коробки" ( однаково зручно
відображатиметься на великих моніторах у деканаті та на екранах смартфонів
викладачів чи студентів).
База даних та інструменти роботи з нею реалізовано на основі технології
PostgreSQL + Prisma ORM. PostgreSQL є безкоштовна реляційна СУБД із
відкритою ліцензією, яка підтримує складні зв'язки, транзакційність (ACID) та
кастомні типи даних (ENUM), що були закладені в нашому проектуванні. Вона
надійно захищає дані від часткового збереження у разі обриву зв'язку.Prisma
ORM абстрагує код від прямого написання SQL-запитів. Це реалізує вимогу про
легкість налаштування системи під іншу СУБД (наприклад, якщо університет
використовує MySQL). Також Prisma має вбудовану систему міграцій.
Для інфраструктури, розгортання та контейнеризації обрані технології
Docker + Docker Compose + Nginx. Docker є програмою, що упаковується разом
із усім середовищем (Node.js, залежності) в ізольований контейнер. Це гарантує
стабільний запуск ІС на будь-якому сервері університету, незалежно від
встановленої операційної системи (Linux чи Windows Server). Nginx
використовується як зворотний проксі-сервер (Reverse Proxy). Він приймає
Арк.
ЧДТУ 262214.001 ПЗ 34
Змн. Арк. № докум. Підпис Дата
запити від користувачів через інтернет, шифрує трафік за допомогою
SSL/HTTPS та розподіляє навантаження на бекенд.
Інструменти розробки та тестування IDE (Середовище розробки) Visual
Studio Code — безкоштовне, легке середовище з великою екосистемою плагінів
під TypeScript та React. Тестування API реалізовано за допомогою Postman або
Bruno — для перевірки працездатності серверних ендпоінтів без участі
фронтенду. Для контролю версій застосовано Git (хостинг на GitHub або GitLab)
— для спільної розробки та фіксації історії змін коду.
2.4 Висновки до розділу 2
Створення веб-орієнтованої інформаційної системи контролю
відвідування занять є комплексним інженерним завданням, успішна реалізація
якого залежить від синергії продуманої архітектури, строго структурованої бази
даних та сучасного технологічного стеку. Використання трирівневої
архітектури дозволяє чітко розмежувати обов'язки між клієнтським
інтерфейсом, ядром бізнес-логіки та рівнем зберігання даних. Завдяки цьому
система набуває гнучкості, стає захищеною від зовнішніх загроз та готовою до
масштабування в межах великого закладу вищої освіти.
В другому розділі описано проєктування бази даних на основі реляційної
моделі, що забезпечує цілісність інформації, відображаючи реальну структуру
університету — від кафедр і академічних груп до журналів відвідуваності та
верифікації документів. Вибір сучасних інструментів розробки, таких як
Node.js, React та PostgreSQL, гарантує високу швидкість обробки масових
запитів у пікові години та адаптивність інтерфейсу для мобільних пристроїв.
Кінцева цінність розробленого технічного рішення полягає у дотриманні
принципу незалежності від середовища. Контейнеризація за допомогою Docker
та винесення конфігурацій у змінні оточення повністю вирішують проблему
складної інсталяції. Це дозволяє системним адміністраторам ЗВО розгортати
інформаційну систему на будь-якому наявному серверному обладнанні за
Арк.
ЧДТУ 262214.001 ПЗ 35
Змн. Арк. № докум. Підпис Дата
лічені хвилини. У підсумку, спроєктована система є повністю готовим до
впровадження інструментом цифрової трансформації, який ліквідує паперову
рутину, підвищує академічну дисципліну та надає керівництву університету
прозору аналітику для прийняття управлінських рішень
Арк.
ЧДТУ 262214.001 ПЗ 36
Змн. Арк. № докум. Підпис Дата
3 РОЗРОБКА ТА ТЕСТУВАННЯ WEB-ОРІЄНТОВАНОЇ ІС
3.1 Розробка Backend-частини.
Серверна частина web-орієнтованої інформаційної системи контролю
відвідування занять студентами реалізована на платформі Node.js із
використанням фреймворку NestJS та мови програмування TypeScript.
Архітектура Backend-частини побудована за принципом розподілу обов'язків та
складається з чотирьох основних компонентів: шару опису моделей (Prisma
Schema), шару бізнес-логіки (Services), шару маршрутизації запитів
(Controllers) та механізмів автоматизації процесів [12].
Об'єктно-реляційне відображення даних (ORM) для взаємодії з базою
даних PostgreSQL реалізовано через сучасний інструмент Prisma ORM. У файлі
конфігурації schema.prisma декларативно описано структуру всіх таблиць, типів
даних та зв’язків, що відповідають спроєктованій ER-моделі, а саме:
- рольова модель користувачів та статуси відвідуваності реалізовані
через системні переліки (enum), що гарантує валідність даних на рівні
СУБД;
- таблиця users об'єднує в собі всі типи користувачів, де за допомогою
необов'язкових (nullable) полів groupId та studentTicket забезпечується
зберігання специфічних даних студентів без створення додаткових
надлишкових таблиць;
- зв'язки між сутностями розкладу (schedules), відвідуваності
(attendance) та користувачів (users) налаштовані за допомогою каскадних
правил видалення (ON DELETE CASCADE / RESTRICT). Це запобігає
появі "сирітських" записів у журналі у разі зміни чи видалення занять;
- для таблиці attendance встановлено унікальний складений індекс
unique_student_lesson, який на рівні архітектури БД унеможливлює
створення дублікатів відміток для одного студента на тому самому занятті.
Реалізація шару бізнес-логіки (AttendanceService) здйснено на основі
компоненту AttendanceService, що відповідає за виконання основних
Арк.
ЧДТУ 262214.001 ПЗ 37
Змн. Арк. № докум. Підпис Дата
аналітичних та обчислювальних операцій системи. У ньому запрограмовано два
ключові алгоритми:
алгоритм 1 - масове виставлення відміток. Метод markAttendance
приймає масив ідентифікаторів студентів та їхніх статусів від викладача.
Перед внесенням змін система виконує валідацію: перевіряє існування заняття
за розкладом та відповідність ідентифікатора викладача, який здійснює запит,
з ID викладача, закріпленого за цим заняттям. Для забезпечення надійності
операція завантаження даних обгорнута в базу даних транзакцію ($transaction).
Якщо під час оновлення запису хоча б одного студента виникне помилка, вся
операція буде скасована, що гарантує цілісність даних. Використання методу
upsert дозволяє автоматично створювати новий запис (якщо відмітка ставиться
вперше) або оновлювати існуючий (якщо викладач виправляє помилку);
алгоритм 2 – формування електронного журналу. Метод
getLessonJournal забезпечує агрегацію даних для виведення на клієнтську
частину. Система робить вибірку всієї структури академічної групи, що
закріплена за парою, та зіставляє список студентів із наявними відмітками про
присутність у таблиці attendance. Результатом є готовий об'єкт, де для кожного
студента відображається його поточний статус або мітка "не виставлено", що
дозволяє викладачу бачити повну картину заняття.
Організація інтерфейсу REST API (AttendanceController) має вагоме
значення в процесі розробки Backend-частини. Шар контролерів у NestJS
виконує роль маршрутизатора вхідних HTTP-запитів від клієнтської частини
додатка. Компонент AttendanceController реалізує кінцеві точки (endpoints) для
доступу до функцій журналу. Для захисту персональних даних та запобігання
несанкціонованому доступу до контролера підключено модулі захисту Guard
(JwtAuthGuard та RolesGuard). Вони перевіряють наявність і валідність
цифрового токена безпеки (JWT) у заголовку запиту. Розмежування прав
доступу реалізовано через кастомний декоратор @Roles. Ендпоінт збереження
відміток (/mark) захищений метаданими, які дозволяють виконувати операцію
Арк.
ЧДТУ 262214.001 ПЗ 38
Змн. Арк. № докум. Підпис Дата
виключно користувачам із ролями teacher (викладач) або admin (адміністратор).
Студенти при спробі надіслати такий запит автоматично отримають помилку
доступу з кодом 403 Forbidden. Ідентифікація автора змін відбувається
безпечним шляхом: ID викладача витягується безпосередньо з розшифрованого
на сервері JWT-токена (req.user.id), що виключає можливість підміни даних з
боку клієнта.
Автоматизація процесів обробки документів (DocumentsService) є
необхідною складовою web-орієнтованої ІС. Важливою інноваційною
частиною бекенду є автоматизація верифікації виправдальних документів у
DocumentsService. Коли співробітник деканату змінює статус завантаженої
студентом медичної довідки на "Затверджено" (approved), сервіс запускає
фоновий алгоритм:
- на основі полів startDate та endDate довідки визначається точний
часовий проміжок, коли студент був відсутній з поважної причини;
- система виконує запит до таблиці розкладу (schedules), щоб знайти
всі пари, які мала відвідати група цього студента у вказаний період;
- далі викликається масове оновлення (updateMany) в таблиці
attendance. Усі записи цього студента за знайдені заняття, які мали статус
"Відсутній" (absent), автоматично змінюються на статус "Поважна
причина" (excused). Пари, де студент все ж був присутній (наприклад,
підключився онлайн), залишаються без змін;
- кожне таке автоматичне виправлення маркується ідентифікатором
працівника деканату в полі modifiedBy, що повністю задовольняє
нефункціональну вимогу безпеки щодо повного аудиту та логування дій
користувачів.
Арк.
ЧДТУ 262214.001 ПЗ 39
Змн. Арк. № докум. Підпис Дата
3.2 Розробка Frontend-частини
Для розробки клієнтської частини (Frontend) web-орієнтованої
інформаційної системи контролю відвідування занять студентами обрана
технологія React.js (мова TypeScript) + Tailwind CSS. Комбінація React
(TypeScript) та Tailwind CSS є сучасним стандартом індустрії, який ідеально
підходить для розробки внутрішніх систем, таких як контроль відвідуваності.
Компонентний підхід React дозволяє створити перевикористовувані
елементи інтерфейсу (картки студентів, таблиці відвідуваності, випадаючі
списки груп). Типізація TypeScript мінімізує помилки при роботі з даними
(наприклад, чітка структура об'єкта Student, Lesson або Attendance).Швидкість
Tailwind CSS дозволяє миттєво верстати адаптивні таблиці, календарі та
графіки без написання окремих CSS-файлів [13].
Архітектуру web-орієнтованої інформаційної системи контролю
відвідування занять студентами організовано за модульним або стандартним
компонентним принципом:
Ключовими TypeScript інтерфейсів містять наступні базові моделі
даних, які застосовано для контролю відвідування:
// types/index.ts
export interface Student {
id: string;
name: string;
ticketNumber: string;
Арк.
ЧДТУ 262214.001 ПЗ 40
Змн. Арк. № докум. Підпис Дата
groupId: string;
}
export type AttendanceStatus = 'PRESENT' | 'ABSENT' | 'LATE' | 'EXCUSED';
export interface AttendanceRecord {
studentId: string;
status: AttendanceStatus;
comment?: string; // наприклад, причина запізнення
}
export interface Lesson {
id: string;
subjectName: string;
date: string; // ISO формат
teacherId: string;
groupId: string;
attendance: AttendanceRecord[];
}
Обраний стек технологій (React + TypeScript + Tailwind CSS) разом із
запропонованою архітектурою забезпечує системі високу швидкість роботи,
надійність та зручність підтримки.
Перевагами такого технологічного стеку є наступні [14]:
- React.js забезпечує високу швидкість (Virtual DOM). Сторінка
відвідуваності оновлюється миттєво без перезавантаження всього
браузера. Це критично, коли викладач швидко проставляє галочки
для 30+ студентів;
- компонентна архітектура сприяє розбиттю інтерфейсу на дрібні
блоки. Наприклад, один раз створений рядок таблиці студента
використовується на всіх сторінках журналів;
- TypeScript забезпечує безпеку коду (Статична типізація): виключає
помилки на етапі написання коду. Не можливо випадково передати
текст замість масиву студентів або переплутати studentId з lessonId;
Арк.
ЧДТУ 262214.001 ПЗ 41
Змн. Арк. № докум. Підпис Дата
- Автодоповнення (IntelliSense) через IDE (наприклад, VS Code)
одразу підказує доступні поля об'єкта
(наприклад, .name, .ticketNumber), що прискорює розробку в рази;
- Tailwind CSS забезпечує швидку верстку (Utility-First). Стилі
пишуться прямо в HTML/JSX. Не потрібно вигадувати назви класів
чи стрибати між файлами;
- Мала вага (Швидке завантаження) Tailwind видаляє невикористані
стилі при збірці (Purge CSS). Система буде швидко відкриватися
навіть через мобільний інтернет у стінах університету;
- Легка адаптивність забезпечує можливості інтерфейсу легко
підлаштуватись під мобільні телефони (для старост чи викладачів,
які відмічають відвідуваність з інституту) за допомогою префіксів
типу md:, lg:.
Архітектура web-орієнтованої ІС характеризується масштабованістю,
коли чіткий розподіл на папки (components, pages, hooks) дозволяє системі
розростатися. Новий розробник зможе за 5 хвилин зрозуміти, де лежить
потрібний файл. Чистота коду (DRY - Don't Repeat Yourself) за рахунок
винесення логіки запитів у services, а типів в interfaces уникає дублювання коду.
Гнучкість тестування через ізольовані компоненти та кастомні хуки значно
легше покривається юніт-тестами (Unit Tests) [15].
Для створення журналу відвідуваності інтерфейс має бути максимально
простим, оскільки викладачі або старости заповнюють його в умовах обмеже
Екран створення журналу (або створення заняття, для якого ведеться облік)
логічно ділиться на два кроки.
Крок 1. Налаштування заняття та Таблиця відміток.
Блок А: Керування та метадані (Верхня панель) реалізується наступними
елементами:
- селектори здійснюють вибір Навчального курсу (дисципліни),
Факультету, Курсу та Групи;
Арк.
ЧДТУ 262214.001 ПЗ 42
Змн. Арк. № докум. Підпис Дата
- поля дати та часу забезпечують автоматичне підставлення поточної
дати та номер пари (за розкладом), з можливістю ручної зміни;
- тип заняття: Лекція, Практична, Лабораторна, Семінар (впливає на
статистику).
Блок Б: Робоча область (Журнал відвідуваності) містить наступні
елементи:
- пошуковий рядок для швидкого пошуку студента за прізвищем;
- кнопки швидкої дії через кнопку «Відмітити всіх як "Присутні"»
(економить до 90% часу);
- списки студентів (Таблиця):
o Стовпчик 1: Прізвище, ім'я студента + фото (за наявності).
o Стовпчик 2: Статус відвідування (швидкі кнопки або перемикачі).
o Стовпчик 3: Поле для короткої примітки (наприклад, «Запізнився
на 20 хв», «Провідна причина»).
Крок. 2. UX/UI Фішки для Tailwind CSS (Зручність використання)
реалізується наступним чином:
- колірне кодування статусів:
o присутній (Н) — спокійний сірий або зелений контур;
o відсутній (НБ) — яскравий червоний колір (привертає увагу);
o запізнився (ЗП) — жовтий колір;
o поважна причина (ПП) — синій колір.
- великі зони для кліків (Fat Fingers) на мобільних пристроях радіо-кнопки
замінюються на великі тач-плашки, по яких легко влучити пальцем.
- Sticky-заголовок при прокручуванні великого списку (наприклад, потік із
60 студентів) шапка таблиці та ПІБ студента мають фіксуватися, щоб
викладач бачив, кого саме відмічає.
Арк.
ЧДТУ 262214.001 ПЗ 43
Змн. Арк. № докум. Підпис Дата
3.3. Розробка макету дизайну web-орієнтованої ІС
Процес розробки макету дизайну (UI/UX) web-орієнтованої інформаційної
системи контролю відвідування занять студентами включає три класичні етапи:
створення карти екранів, UX-проєктування (вайрфрейми) та фінальний UI-
дизайн із використанням дизайн-системи Tailwind CSS.
Перший етап передбачає створення карти екранів системи (User Flow).
Розробка макету інтерфейсу передбачає чітке розуміння, які сторінки
бачитимуть користувачі. Основна структура макету включає наступні елементи.
Екран авторизації (Login Page) є вхід за корпоративною поштою або
номером студентського/викладацького квитка (рис.3.1)
Рисунок 3.1 – Форма авторизації користувача
Панель керування (Dashboard) передбачає для викладача: розклад на
сьогодні, швидкий доступ до останніх журналів, відсоток відвідуваності на його
курсах; для студента: його особиста статистика, сповіщення про пропуски,
можливість завантажити довідку про хворобу; для деканату: глобальні графіки
відвідуваності по факультету, антирейтинг студентів-прогульників.
Журнал відвідуваності (Attendance Sheet) є сторінкою, що деталізує (з
вибором предмету, групи та інтерактивною таблицею студентів). Звіти та
Арк.
ЧДТУ 262214.001 ПЗ 44
Змн. Арк. № докум. Підпис Дата
аналітика (Reports) представляє зведені таблиці за місяць/семестр з можливістю
фільтрації та експорту даних.
У React-компоненті з використанням класів Tailwind CSS приклад для лівого
верхнього кута меню прописано на основі наступного коду:
Для розробки макету застосовано інструмент Figma (Для візуального
прототипу). Це забезпечило можливості малювати дизайн з елементів, які потім
на 100% збігатимуться з класами Tailwind у коді.Shadcn/ui або Tailwind UI.
Для реалізації балансу легкого та зрозумілого інтерфейсу (між
інформаційною насиченістю та простотою сприйняття) у Figma застосовується
концепція прогресивного розкриття даних (Progressive Disclosure) та чітка
візуальна ієрархія.
UX-стратегія передбачає розподіл інформації на шари. Складні функції
(перегляд детальної статистики студента за весь семестр, історія редагування
оцінок) виноситься у висувну бічну панель (Slide-over panel) справа. Меню
реєстрації користувача передбачає невеликий віджет-стрічку, який робить
систему інтерактивною та автоматизує комунікацію (рис.3.2).
Арк.
ЧДТУ 262214.001 ПЗ 45
Змн. Арк. № докум. Підпис Дата
Рисунок 3.2 – Форма реєстрації користувача
На головній сторінці (Dashboard / Панелі керування) системи контролю
відвідуваності мають бути розміщені елементи, які дають користувачу миттєву
картину дня та забезпечують доступ до головних дій в 1–2 кліки. Оскільки
інформаційна система орієнтована на різні ролі, наповнення головної сторінки
буде дещо відрізнятися для викладача та для студента. Розглянемо структуру
головної сторінки для Викладача / Старости (як головних користувачів системи).
Верхній блок містить віджети швидкої статистики (Key Metrics). Це 3–4
компактні картки, які показують агреговані дані за допомогою великих цифр і
мікрографіків. Вони не обтяжують інтерфейс, але дають розуміння поточної
ситуації. Так, Картка 1 «Заняття» показує кількість пар, які потрібно
провести/відмітити. Картка 2 «% відвідування» показує загальний % присутності
студентів на курсах викладача за поточний тиждень (наприклад, 84.5%) (рис.3.3).
Арк.
ЧДТУ 262214.001 ПЗ 46
Змн. Арк. № докум. Підпис Дата
Рисунок 3.3 – Головна сторінка ІС.
Центральний блок ліворуч є інтерактивним розкладом на сьогодні (Today's
Agenda). Це головний операційний елемент сторінки. Замість паперових
журналів викладач бачить список своїх пар на поточний день. Картки занять
впорядковані за часом: 1-ша пара, 2-га пара тощо. Вміст кожної картки містить:
Назва дисципліни, тип заняття (лекція/практика), час, аудиторія та шифр групи
(наприклад, ІП-21). Індикатор статусу :«Проведено / Журнал заповнено»
(зелений маркер).«Очікує заповнення» (жовтий маркер).Кнопка швидкої дії:
Велика кнопка «Відмітити відвідуваність», яка веде прямо на сторінку журналу,
що ми проєктували раніше.
Невеликий віджет-стрічка, який робить систему інтерактивною та
автоматизує комунікацію. Заяви від студентів: Списки надісланих студентами
довідок про хворобу або пояснювальних записок, які викладач/деканат може
затвердити або відхилити в один клік. Системні нагадування: Наприклад: «Ви не
заповнили журнал для групи ІП-21 за 19 травня».
Простий лінійний або стовпчиковий графік (реалізований через бібліотеку
recharts), який показує динаміку відвідуваності за останні 7–14 днів. Він
Арк.
ЧДТУ 262214.001 ПЗ 47
Змн. Арк. № докум. Підпис Дата
допомагає візуально оцінити, чи падає відвідуваність (наприклад, перед святами
або під час похолодання).
Головна сторінка інформаційної системи контролю відвідуваності занять
проектується як єдиний аналітично-операційний центр, що забезпечує миттєве
занурення користувача в робочий контекст поточного дня. В основі
композиційного рішення лежить модульна сітка, яка адаптується під екранні
розрішення та розподіляє інформаційне навантаження за ступенем
пріоритетності.
Верхній ярус інтерфейсу займає панель ключових метрик, представлена
компактними інформаційними картками. Цей блок виконує роль експрес-
аналітики, де за допомогою великих числових індикаторів та мікрографіків
відображається кількість запланованих на сьогодні занять, усереднений відсоток
присутності студентів за поточний тиждень та динамічний маркер виконання
плану заповнення журналів. Поруч виводиться критично важливий показник
кількості студентів, які потрапили до зони ризику через систематичні прогули,
що дозволяє викладачу або представнику деканату миттєво зорієнтуватися в
наявності проблемних ланок без глибокого пошуку в системі.
Центральна робоча область екрана розділена на два асиметричні блоки.
Більшу частину простору займає інтерактивний розклад занять на поточний
день. Кожна пара представлена у вигляді окремого візуального контейнера, який
містить точний час, назву дисципліни, тип заняття, аудиторію та шифр
академічної групи. Особливе місце в структурі цієї картки посідає колірний
індикатор статусу, що чітко диференціює проведені занять від тих, які лише
очікують на фіксацію відвідуваності. Прямо з картки розкладу реалізовано
швидкий перехід до електронного журналу за допомогою акцентної кнопки дії,
що мінімізує кількість кліків для виконання основної операції.
Праву сторону центрального блоку займає стрічка оперативних сповіщень
та контекстних запитів. Цей елемент відповідає за інтерактивну взаємодію між
учасниками навчального процесу в реальному часі. Тут відображаються
Арк.
ЧДТУ 262214.001 ПЗ 48
Змн. Арк. № докум. Підпис Дата
надіслані студентами електронні заяви, пояснювальні записки та цифрові копії
довідок про хворобу, які викладач або куратор може оперативно розглянути та
верифікувати безпосередньо з головної сторінки. Також цей блок виконує
функцію системного нагадувальника про не заповнені вчасно електронні
відомості.
Нижній сегмент головної сторінки відведено під інтерактивний графік
часових трендів. Реалізований у вигляді лаконічної діаграми, він візуалізує
коливання рівня відвідуваності за останні кілька тижнів. Таке рішення дозволяє
керівництву та викладачам наочно відстежувати загальні тенденції навчальної
дисципліни та вчасно реагувати на спади активності студентських колективів.
3.4 Тестування web-орієнтованої ІС
Для забезпечення надійності, безпеки та високої якості web-орієнтованої
інформаційної системи контролю відвідування занять студентами розробляється
комплексна стратегія тестування. Враховуючи обраний технологічний стек
(React, TypeScript, Tailwind CSS), процес верифікації системи охоплює кілька
рівнів, кожен з яких спрямований на виявлення специфічних дефектів та
перевірку працездатності програмного забезпечення в цілому [16].
Модульне тестування (Unit Testing) реалізується на на найнижчому рівні,
коли виконується ізольована перевірка окремих компонентів інтерфейсу,
кастомних хуків та допоміжних функцій. Завдяки статичній типізації TypeScript
значна частина помилок виявляється ще на етапі компіляції. Модульні тести
фокусуються на логіці поведінки елементів: перевіряється коректність роботи
функцій фільтрації списків студентів, правильність обчислення фінального
відсотка відвідуваності у віджетах статистики, а також валідація полів введення
коментарів та дат. Для написання таких тестів зазвичай використовуються
інструменти Jest або Vitest у поєднанні з React Testing Library.
Інтеграційне тестування (Integration Testing) передбачає етап, що реалізує
перевірку взаємодії між кількома логічними модулями клієнтської частини, а
Арк.
ЧДТУ 262214.001 ПЗ 49
Змн. Арк. № докум. Підпис Дата
також коректність їхньої комунікації з сервером (Backend API). У контексті
системи відвідуваності інтеграційні тести перевіряють, як зміна статусу студента
в таблиці відображається на загальному лічильнику присутніх у шапці журналу,
та чи правильно надсилається сформований JSON-пакет даних через сервісні
функції axios на сервер. Також тестується механізм авторизації та розмежування
прав доступу, щоб переконатися, що студент не має технічної можливості
отримати доступ до функцій створення журналу, які призначені виключно для
викладача чи старости.
Наскрізне тестування (End-to-End / E2E Testing) повністю імітує реальну
поведінку користувача в браузері від моменту входу в систему до виконання
цільових дій. За допомогою інструментів Playwright або Cypress
автоматизуються критичні сценарії використання системи. Типовий тест-кейс
відтворює повний цикл роботи викладача: авторизація в системі, перехід на
головну сторінку, вибір потрібної пари з розкладу на сьогодні, проставляння
відміток відсутності для кількох студентів, додавання примітки та успішне
збереження журналу з подальшою перевіркою появи оновлених даних на
графіках аналітики.
Тестування користувацького інтерфейсу та адаптивності (UI/UX &
Responsiveness Testing), оскільки стилізація системи реалізована за допомогою
Tailwind CSS, окрема увага приділяється перевірці коректності відображення
інтерфейсу на пристроях з різною роздільною здатністю екрана. Тестування
адаптивності гарантує, що велика таблиця журналу залишається читабельною на
моніторах комп'ютерів у деканаті, а великі елементи керування статусами
відвідуваності є зручними для кліків пальцями на смартфонах старост чи
викладачів безпосередньо під час занять. Також перевіряється кросбраузерність
для стабільної роботи системи у всіх популярних веб-переглядачах.
Критерії успішності тестування є фінальним етапом, де реалізується аналіз
покриття коду тестами (Code Coverage) та формування звітів. Система
вважається готовою до впровадження в освітній процес за умови успішного
Арк.
ЧДТУ 262214.001 ПЗ 50
Змн. Арк. № докум. Підпис Дата
проходження всіх автоматизованих сценаріїв, відсутності критичних
вразливостей у передачі персональних даних студентів та відповідності
швидкості завантаження інтерфейсу встановленим вимогам технічного завдання.
Тест-кейси (Test Cases) реалізовано у вигляді чітких сценаріїв із
зазначенням початкових умов, кроків відтворення та очікуваного результату. Це
демонструє інженерний підхід до верифікації розробленого модуля.
Тест-кейс №1: Перевірка зміни статусу відвідуваності студента та
автоматичного перерахунку лічильників
Опис та початкові умови. Цей сценарій спрямований на верифікацію
інтерактивності інтерфейсу. Перед початком тесту користувач із роллю
викладача успішно авторизований у системі, знаходиться на сторінці створення
журналу конкретної академічної групи, а для всіх студентів у списку за
замовчуванням встановлено статус «Присутній». Головний лічильник у верхній
панелі відображає стовідсоткову присутність.
Кроки виконання. Тестувальник здійснює пошук конкретного студента у
таблиці та натискає на кнопку-іконку статусу «Відсутній» (червоний маркер з
позначкою «НБ»). Після цього додає текстовий коментар у відповідне поле
введення в цьому ж рядку та натискає кнопку збереження змін.
Очікуваний результат. Інтерфейс миттєво реагує на дію розробника без
перезавантаження сторінки. Кнопка статусу змінює свій візуальний стан на
активний червоний колір, а загальний лічильник присутніх студентів у верхній
панелі автоматично зменшується на одну одиницю, коректно перераховуючи
фінальний відсоток відвідуваності пари. Введена примітка успішно фіксується у
внутрішньому стані компонента.
Тест-кейс №2: Валідація функції «Відмітити всіх як присутніх» при
масовому редагуванні даних
Опис та початкові умови. Метою тесту є перевірка працездатності
інструменту швидкого заповнення відомості. Викладач відкрив новий журнал
заняття, де у кількох студентів випадковим чином виставлені різні статуси:
Арк.
ЧДТУ 262214.001 ПЗ 51
Змн. Арк. № докум. Підпис Дата
«Відсутній», «Запізнився» та «Поважна причина». Лічильник відображає
реальне поточне співвідношення студентів.
Кроки виконання. Користувач натискає на функціональну кнопку «Усі
присутні», розташовану на верхній панелі керування над основною таблицею
журналу.
Очікуваний результат. Система миттєво оновлює стан усіх рядків у таблиці.
Кожен студент отримує статус «Присутній», відповідні кнопки підсвічуються
зеленим кольором, а всі інші маркери переходять у неактивний стан. Текстові
коментарі, які були введені раніше, залишаються без змін, якщо вони не
суперечать новому статусу. Головний лічильник оновлюється до максимального
значення кількості студентів у групі.
Тест-кейс №3: Перевірка збереження журналу та коректності відправки
JSON-пакета на сервер
Опис та початкові умови. Тест верифікує інтеграційну взаємодію
клієнтської частини (Frontend) із серверною (Backend). Журнал заняття
заповнений викладачем, виставлені актуальні статуси та примітки для
академічної групи. Мережеве з'єднання стабільне.
Кроки виконання. Тестувальник натискає на акцентну кнопку «Зберегти
журнал». Інструменти розробника в браузері (вкладка Network) відкриті для
фіксації вихідного трафіку.
Очікуваний результат. Після натискання кнопки інтерфейс блокує повторні
кліки (вмикається стан завантаження), а клієнтська частина через сервіс axios
відправляє на сервер HTTP-запит типу POST або PUT. У тілі запиту міститься
коректно сформований масив об'єктів TypeScript, де для кожного студента чітко
вказано його унікальний ідентифікатор, ідентифікатор заняття, обраний статус та
текст коментаря. Після отримання успішної відповіді від сервера (код 200 OK),
система виводить спливаюче сповіщення про успішне збереження та
перенаправляє викладача на головну сторінку розкладу.
Арк.
ЧДТУ 262214.001 ПЗ 52
Змн. Арк. № докум. Підпис Дата
3.5 Висновки до розділу 3
В третьому розділі детально описано процес розробки web-орієнтованої
інформаційної системи контролю відвідування занять студентами, представлено
дизайн системи та інтерфейс. На етапі UX/UI-дизайну в середовищі Figma
створено адаптивний, ергономічний та візуально легкий інтерфейс, який
базується на концепції прогресивного розкриття даних і забезпечує комфортну
роботу користувачів як на десктопних моніторах, так і на мобільних пристроях.
Обґрунтування вибір та побудова Frontend-частини системи на основі сучасного
фреймворку React із застосуванням мови TypeScript та стилістичного
інструментарію Tailwind CSS. Серверна частина (Backend) забезпечує надійне
збереження, обробку та структуризацію даних, організовуючи безпечну
взаємодію з базою даних і надаючи клієнтській частині чітко типізований REST
API для виконання операцій над журналами занять, списками студентів та
аналітичними звітами. Також описано процес тестування розробленого
програмного продукту.
Арк.
ЧДТУ 262214.001 ПЗ 53
Змн. Арк. № докум. Підпис Дата
ВИСНОВКИ
Актуальність розробки web-орієнтованої інформаційної системи
контролю відвідування занять студентами зумовлена об'єктивною необхідністю
модернізації та цифровізації менеджменту вищої освіти в Україні. Перехід від
застарілих паперових журналів до автоматизованого обліку дозволяє
кардинально зменшити бюрократичне навантаження на професорсько-
викладацький склад, забезпечити деканати прозорими аналітичними даними в
режимі реального часу та підвищити загальну виконавську дисципліну
здобувачів освіти завдяки операційному моніторингу пропусків.
У кваліфікаційній роботі розроблено web-орієнтовану інформаційну
систему контролю відвідування занять студентами із використанням комплексу
сучасних програмних інструментів та засобів. Впровадження сучасного
методологічного та технологічного підходу забезпечило високу ефективність
реалізації всіх складових частин проекту. Розроблений у Figma дизайн-макет
став основою для створення ергономічного, інтуїтивно зрозумілого
користувацького інтерфейсу, позбавленого зайвого візуального шуму та
адаптованого під мобільні пристрої. Реалізація клієнтської частини за
допомогою зв'язки React, TypeScript та Tailwind CSS дозволила досягти
максимальної швидкодії системи, миттєвого відгуку інтерактивних елементів
журналу та надійної архітектури коду.
Серверна частина (Backend) системи, реалізована на платформі Node.js із
використанням фреймворку NestJS та мови TypeScript, забезпечила створення
модульної, архітектурно збалансованої та легко масштабованої серверної
інфраструктури. Застосування підходів об'єктно-орієнтованого програмування,
ін'єкції залежностей (Dependency Injection) та суворої типізації на обох кінцях
розробки (End-to-End TypeScript) дозволило побудувати безпечний і
високопродуктивний REST API. Це забезпечило надійну обробку та валідацію
вхідних даних, швидке формування підсумкової аналітики та стабільну
Арк.
ЧДТУ 262214.001 ПЗ 54
Змн. Арк. № докум. Підпис Дата
взаємодію з базою даних при високих навантаженнях під час масового
заповнення журналів викладачами наприкінці навчальних пар.
Фінальний етап комплексного тестування програмного забезпечення,
який охопив верифікацію на модульному, інтеграційному та наскрізному рівнях,
підтвердив повну працездатність системи, стабільність бізнес-логіки та
відсутність критичних дефектів у передачі даних. Таким чином, розроблена
інформаційна система є повністю завершеним, масштабованим та захищеним
інструментом, який готовий до інтеграції в діюче цифрове середовище вищого
навчального закладу для підвищення якості управління освітнім процесом.
Отже, можна стверджувати, що мета роботи досягнута, всі вимоги
технічного завдання виконані у повному обсязі.
Арк.
ЧДТУ 262214.001 ПЗ 55
Змн. Арк. № докум. Підпис Дата
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Менеджмент освіти : навчальний посібник / автори-укладачі: А.
Рибчук, В. Бодак, О. Блистів, І. Ворончак, Н. Гук, В. Зінкевич, Т. Конопельнюк,
Г. Мельник, Н. Мінчак, І. Нищак, Г. Ожубко, Л. Оршанський, М. Оршанська, М.
Паласевич, О. Процишин, Г. Пурій, О. Сивик, П. Скотний ; за ред. проф. А.
Рибчука. Дрогобич : Ред.-вид. відділ Дрогобицького державного педагогічного
університету ім. І. Франка, 2022. 326 с.
2. Менеджмент в освіті: Підручник / За ред. проф. В. Крижка (Василь
Крижко, Валерій Радул, Григорій Луценко, Ольга Старокожко, Сергій
Немченко, Юлія Кондратенко). – К. : Освіта України, 2020. – 465 с.
3. Недашківський О. М. Планування та проєктування інформаційних
систем. Київ : КНЕУ, 2014. 215 с.
4. Денісова О. О. Автоматизоване проектування інформаційних
систем : навч. посіб. Київ : КНЕУ, 2011. 412 с
5. Myattendancetracker [Електронний ресурс]. – Режим доступу:
https://myattendancetracker.com/#. Дата звернення – 02.04.2026.
6. Edusign [Електронний ресурс]. – Режим доступу: https://edusign.com/.
Дата звернення – 02.04.2026.
7. Human [Електронний ресурс]. – Режим доступу:
https://www.human.ua/. Дата звернення – 02.04.2026.
8. Пасічник В. В., Литвин В. В., Шаховська Н. Б. Проєктування
інформаційних систем : навч. посіб. Львів : Новий Світ-2000, 2013. 380 с.
9. Dong, Jing; Paul, Raymond & Zhang, Liang Jie (2009). "Chapter 12 :
Specifying Enterprise Web-Oriented Architecture". High Assurance Services
Computing. Springer. ISBN 978-0387876573.
10. Su, Chuan-Jun. Web-Oriented Architecture (WOA) Enabled Customer-
Centric Collaborative Commerce Platform (WCCP). Vol. 7. pp. 402–406.
Арк.
ЧДТУ 262214.001 ПЗ 56
Змн. Арк. № докум. Підпис Дата
11. Жученко А. І. Основи проєктування баз даних : навч. посіб. 2-ге вид.,
допов. Київ : КПІ ім. Ігоря Сікорського, 2021.
12. Felke-Morris, Terry. Basics of web design: HTML5 & CSS3. 5-th ed.
Pearson, 2019. 496 p.
13. Що таке CSS [Електронний ресурс]. – Режим доступу:
https://css.in.ua/article/shcho-take-html_10.
14. Прокопенко Т. О., Підкуйко О.І. DevOps: навч. посіб. [Електронний
ресурс] / Т. О. Прокопенко, О.І.Підкуйко ; М-во освіти і науки України, Черкас.
держ. технол. ун-т.– Черкаси:ЧДТУ, 2025. – 160 с.
15. Посібник: знайомство з React [Електронний ресурс]. – Режим
доступу: https://uk.reactjs.org/tutorial/tutorial.html.Dynamic Routes [Електронний
ресурс]. – Режим доступу: https://nextjs.org/docs/routing/dynamic-routes. Дата
звернення – 12.04.2026.
16. Gizas A., Christodoulou S., Papatheodorou T. Comparative Evaluation
of Javascript Frameworks [Текст] // Proceedings of the 21st Annual Conference on
World Wide Web Companion. – 2018. – P. 513-514.
17. Graziotin D., Abrahamsson P. Making Sense out of a Jungle of
Javascript Frameworks, Towards a Practitioner-friendly Comparative Analysis
[Текст] // Lecture Notes in Computer Science. – 2017. – P. 334- 337.
18. Павлиш В.А. Основи інформаційних технологій і систем.
Підручник [Текст] / В.А. Павлиш, Л.К. Гліненко, Н.Б. Шаховська. Львів:
Видавництво Львівської політехніки, – 2018. – 620 с.
19. Буйницька О.П. Інформаційні технології та технічні засоби
навчання. Навчальний посібник рекомендовано МОН України [Текст] / В-во:
ЦНЛ. – 2018. – 240 с.
20. Трофименко О. Г. Веб-технології та веб-дизайн : навч. посібник / О.
Г. Трофименко, О. Б. Козін, О. В. Задерейко, О. Є. Плачінда. – Одеса : Фенікс,
2019. – 284 с.
Арк.
ЧДТУ 262214.001 ПЗ 57
Змн. Арк. № докум. Підпис Дата
21. De Lamadrid J.C. Computer Organization. Basic Processor Structure /
J.C. De Lamadrid. – Boca Raton: CRC, 2018. – 384 p.
22. Peterson J.L. Computer Organization and Assembly Language
Programming / J.L. Peterson. – Independently published, 2019. – 434 p.
23. Warford J.S. Computer Systems / J.S. Warford // New York: Jones &
Bartlett Learning, 2016. — 892 p.
24. Wu Junjie. Advanced Computer Architecture / J. Wu, L. Li // Springer,
2016. – 224 p.
25. Fox C. Go Data Structures and Algorithms / C. Fox // Bookboon.com,
2018. – 265 p.
26. Kelvin L. Data Structures & Algorithms in Swift / L. Kelvin, N. Vincent.
– Razeware, 2018. – 328 p.
27. Karumanchi N. Data Structures and Algorithms Made Easy: Data
Structure and Algorithmic Puzzles / N. Karumanchi // 5th Edition. – CareerMonk
Publications, 2017. – 828 p.
28. Smith William. Everyday Data Structures / W. Smith. – Packt
Publishing, 2017. – 385 p.
29. Campbell, Jennifer (2017). Web Design: Introductory. Cengage
Learning. p.
30. Keil, Mark; Cule, Paul E.; Lyytinen, Kalle; Schmidt, Roy C. (November
1998). "A framework for identifying software project risks". Communications of the
ACM. 41 (11): 76–83. doi:10.1145/287831.287843. ISSN 0001-0782.
31. Salas-Zárate, María del Pilar; Alor-Hernández, Giner; Valencia-García,
Rafael; Rodríguez-Mazahua, Lisbeth; Rodríguez-González, Alejandro; López
Cuadrado, José Luis (May 2015). "Analyzing best practices on Web development
frameworks: The lift approach". Science of Computer Programming. 102: 1–19.
doi:10.1016/j.scico.2014.12.004
32. Du, Xiaofeng; Song, William; Munro, Malcolm (2009), Barry, Chris;
Lang, Michael; Wojtkowski, Wita; Conboy, Kieran (eds.), "Semantic Service
Арк.
ЧДТУ 262214.001 ПЗ 58
Змн. Арк. № докум. Підпис Дата
Description Framework for Address", Information Systems Development, Boston,
MA: Springer US, pp. 1033–1045, doi:10.1007/978-0-387-78578-3_35, ISBN 978-
0-387-78577-6, retrieved 2023-11-30
33. Hall, Heather (2022-05-01). "Web 2.0 Explained: Everything You Need
To Know". History-Computer. Retrieved 2023-12-10.
34. Козловський А.В. Комп’ютерна техніка та інформаційні технології:
Навч. посіб. Рекомендовано МОН [Текст] / Козловський А.В., Паночишин
Ю.М., Погріщук Б.В. – В-во: Знання. – 2017. – 463 с.
35. Soni, Anuj; Gupta, Sachin; Talwandi, Navjot Singh (September 2023).
"Evolution Of Web Technologies in Recent Years" (PDF). Journal of Emerging
Technologies and Innovative Research. 10 (9). ISSN 2349-5162.
36. Mullenweg, Matt (May 27, 2003). "WordPress Now Available".
wordpress.org. WordPress. Archived from the original on July 19, 2010. Retrieved
July 22, 2010.
37. CMS Usage Statistics". builtwith.com. BuiltWith. Archived from the
original on August 6, 2013. Retrieved August 1, 2013.
38. Прокопенко Т. О. Теорія систем і системний аналіз : навч. посіб.
[Електронний ресурс] / Т. О. Прокопенко ; М-во освіти і науки
України,Черкас. держ. технол. ун-т. – 2-ге вид., змінене та доп. –Черкаси :
ЧДТУ, 2025. – 147 с.
39. ECM Enterprise Content Management, Ulrich Kampffmeyer. Hamburg
2006, ISBN 978-3-936534-09-8. Definition, history, architecture, components and
ECM suites
40. Managing Enterprise Content: A Unified Content Strategy. Ann
Rockley, Pamela Kostur, Steve Manning. New Riders, 2003.
41. Aichner, T., Jacob, F. Measuring the Degree of Corporate Social Media
Use // International Journal of Market Research. – 2017. – 57 (2). – Рр. 257–275.
Арк.
ЧДТУ 262214.001 ПЗ 59
Змн. Арк. № докум. Підпис Дата
42. Thakkar, Mohit. Building React Apps with Server-Side Rendering: Use
React, Redux, and Next to Build Full Server-Side Rendering Applications. –
Berkeley, CA: Apress. – 2020. – Pp. 93–137.
43. Flanagan, David. JavaScript: The Definitive Guide. 7th edition. –
Sebastopol, California: O'Reilly, 2020. – Pp. 289-193.
44. Haverbeke, Marijn. Eloquent JavaScript. 3rd edition. – No Starch Press. –
2018. – 472 p.
45. Smith, Craig S. Have You Noticed The New Web? It's Faster, More
Secure. [Електронний ресурс]. – Режим доступу:
https://www.forbes.com/sites/craigsmith/2020/04/21/have-you-noticed-the-new-
web-its-faster-more-secure/. Дата звернення – 17.04.2026.
46. Krill P. Next.js 2.0 plays better with React and JavaScript [Електронний
ресурс]. – Режим доступу: https://www.infoworld.com/article/3185385/nextjs-20-
plays-better-with-react-and-javascript.html. Дата звернення – 17.04.2026.
47. Режим доступу: https://www.infoworld.com/article/3185385/nextjs-20-
plays-better-with-react-and-javascript.html. Дата звернення – 17.04.2026.
48. Managing Enterprise Content: A Unified Content Strategy. Ann Rockley,
Pamela Kostur, Steve Manning. New Riders, 2003.
49. Методичні рекомендації до підготовки кваліфікаційної роботи для
здобувачів освітнього ступеня «бакалавр» зі спеціальності 126 Інформаційні
системи та технології освітньої програми «Web-технології, Web-дизайн» усіх
форм навчання [Електронний ресурс] / [Упоряд.: Т.О. Прокопенко, Я.В.
Тарасенко]; М-во освіти і науки України, Черкас. держ. технол. ун-т. Черкаси:
ЧДТУ, 2021. – 48 c.
ПРОГРАМНІ ЗАСОБИ
1. Microsoft 365 © Microsoft Inc., 2026.
2. Node.js : open-source, cross-platform JavaScript runtime environment. URL:
https://nodejs.org (date of access: 07.05.2026).
Арк.
ЧДТУ 262214.001 ПЗ 60
Змн. Арк. № докум. Підпис Дата
ДОДАТОК A
ЗАТВЕРДЖЕНО
Зав. кафедри ІТП, проф.
_________________ Прокопенко Т.О.
«____» ________________ 2026 р.
WEB-ОРІЄНТОВАНА ІНФОРМАЦІЙНА СИСТЕМА КОНТРОЛЮ
ВІДВІДУВАННЯ ЗАНЯТЬ СТУДЕНТАМИ
Специфікація
482 ЧДТУ 22144-01
Листів 2
Розробник _______________ Перевозний О.О.
Керівник _______________ Катаєв Д.С.
Н. Контроль _______________
Черкаси, 2026
2
482 ЧДТУ 22144-01
Позначення Найменування Примітка
Документація
482 ЧДТУ 22144-0112 01 Текст програми
WEB-ОРІЄНТОВАНА ІНФОРМАЦІЙНА СИСТЕМА КОНТРОЛЮ
ВІДВІДУВАННЯ ЗАНЯТЬ СТУДЕНТАМИ
482 ЧДТУ 22144-0112 01
Текст програми
Листів 14
Розробник _____________ Перевозний О.О.
Н
2026
6
482 ЧДТУ 22144-01 12 01
Лістинг програмного коду файлу, що описує сутності для ORM, які
автоматично транслюються у створені раніше SQL-таблиці та генерують типи для
TypeScript:
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
generator client {
provider = "prisma-client-js"
}
enum Role {
student
teacher
dean
admin
}
enum AttendanceStatus {
present
absent
late
excused
}
enum DocStatus {
pending
approved
rejected
}
7
482 ЧДТУ 22144-01 12 01
model Department {
id Int @id @default(autoincrement())
name String @unique @db.VarChar(150)
code String? @unique @db.VarChar(10)
groups Group[]
@@map("departments")
}
model Group {
id Int @id @default(autoincrement())
groupName String @unique @map("group_name") @db.VarChar(20)
departmentId Int @map("department_id")
courseNumber Int @map("course_number")
department Department @relation(fields: [departmentId], references: [id])
users User[]
schedules Schedule[]
@@map("groups")
}
model User {
id Int @id @default(autoincrement())
email String @unique @db.VarChar(100)
passwordHash String @map("password_hash") @db.VarChar(255)
firstName String @map("first_name") @db.VarChar(50)
lastName String @map("last_name") @db.VarChar(50)
role Role
groupId Int? @map("group_id")
studentTicket String? @unique @map("student_ticket") @db.VarChar(20)
createdAt DateTime @default(now()) @map("created_at")

group Group? @relation(fields: [groupId], references: [id])
teacherSchedules Schedule[] @relation("TeacherSchedules")
8
482 ЧДТУ 22144-01 12 01
studentAttendance Attendance[] @relation("StudentAttendance")
modifiedAttendance Attendance[] @relation("ModifierAttendance")
documents Document[] @relation("StudentDocuments")
verifiedDocuments Document[] @relation("VerifierDocuments")
@@map("users")
}
model Discourse {
id Int @id @default(autoincrement())
title String @unique @db.VarChar(150)
description String? @db.Text
credits Decimal? @db.Decimal(3, 1)
schedules Schedule[]
@@map("discourses")
}
model Schedule {
id Int @id @default(autoincrement())
discourseId Int @map("discourse_id")
teacherId Int @map("teacher_id")
groupId Int @map("group_id")
lessonDate DateTime @map("lesson_date") @db.Date
lessonNumber Int @map("lesson_number")
classroom String? @db.VarChar(20)
isOnline Boolean @default(false) @map("is_online")
discourse Discourse @relation(fields: [discourseId], references: [id])
teacher User @relation("TeacherSchedules", fields: [teacherId], references: [id])
group Group @relation(fields: [groupId], references: [id])
attendance Attendance[]
@@map("schedules")
9
482 ЧДТУ 22144-01 12 01
}
model Attendance {
id Int @id @default(autoincrement())
scheduleId Int @map("schedule_id")
studentId Int @map("student_id")
status AttendanceStatus @default(absent)
markedAt DateTime @default(now()) @map("marked_at")
updatedAt DateTime @default(now()) @map("updated_at")
modifiedBy Int @map("modified_by")
schedule Schedule @relation(fields: [scheduleId], references: [id])
student User @relation("StudentAttendance", fields: [studentId], references: [id])
modifier User @relation("ModifierAttendance", fields: [modifiedBy], references: [id])
@@unique([scheduleId, studentId], name: "unique_student_lesson")
@@map("attendance")
}
model Document {
id Int @id @default(autoincrement())
studentId Int @map("student_id")
fileUrl String @map("file_url") @db.VarChar(512)
documentType String @map("document_type") @db.VarChar(50)
startDate DateTime @map("start_date") @db.Date
endDate DateTime @map("end_date") @db.Date
status DocStatus @default(pending)
verifiedBy Int? @map("verified_by")
uploadedAt DateTime @default(now()) @map("uploaded_at")
student User @relation("StudentDocuments", fields: [studentId], references: [id])
verifier User? @relation("VerifierDocuments", fields: [verifiedBy], references: [id])
@@map("documents")
10
482 ЧДТУ 22144-01 12 01
Лістинг програмного коду файлу attendance.service.ts:
import { Injectable, BadRequestException, NotFoundException } from '@nestjs/common';
import { PrismaService } from './prisma.service'; // Сервіс підключення до БД
import { AttendanceStatus } from '@prisma/client';
@Injectable()
export class AttendanceService {
constructor(private prisma: PrismaService) {}
// 1. Масове виставлення або оновлення відміток викладачем
async markAttendance(
scheduleId: number,
teacherId: number,
records: { studentId: number; status: AttendanceStatus }[]
) {
// Перевірка, чи існує заняття і чи веде його саме цей викладач
const schedule = await this.prisma.schedule.findUnique({
where: { id: scheduleId },
});
if (!schedule) throw new NotFoundException('Заняття за розкладом не знайдено');
if (schedule.teacherId !== teacherId) {
throw new BadRequestException('Ви не є викладачем цього заняття');
}
// Використання транзакції для забезпечення цілісності даних
return this.prisma.$transaction(
records.map((record) =>
this.prisma.attendance.upsert({
where: {
unique_student_lesson: {
scheduleId: scheduleId,
11
482 ЧДТУ 22144-01 12 01
studentId: record.studentId,
},
},
update: {
status: record.status,
modifiedBy: teacherId,
updatedAt: new Date(),
},
create: {
scheduleId: scheduleId,
studentId: record.studentId,
status: record.status,
modifiedBy: teacherId,
},
})
)
);
}
// 2. Отримання електронного журналу заняття для викладача
async getLessonJournal(scheduleId: number) {
const schedule = await this.prisma.schedule.findUnique({
where: { id: scheduleId },
include: {
group: {
include: {
users: {
where: { role: 'student' },
select: { id: true, firstName: true, lastName: true, studentTicket: true }
}
}
},
attendance: true
}
12
482 ЧДТУ 22144-01 12 01
});
if (!schedule) throw new NotFoundException('Заняття не знайдено');
// Мапінг студентів групи із наявними відмітками в журналі
return schedule.group.users.map(student => {
const attendanceRecord = schedule.attendance.find(a => a.studentId === student.id);
return {
...student,
status: attendanceRecord ? attendanceRecord.status : 'not_marked',
markedAt: attendanceRecord ? attendanceRecord.markedAt : null
};
});
}
}
Лістинг програмного коду файлу attendance.controller.ts:
import { Controller, Post, Get, Body, Param, ParseIntPipe, UseGuards, Req } from
'@nestjs/common';
import { AttendanceService } from './attendance.service';
import { JwtAuthGuard } from '../auth/jwt-auth.guard'; // Guard для перевірки авторизації
import { RolesGuard } from '../auth/roles.guard'; // Guard для перевірки ролей
import { Roles } from '../auth/roles.decorator';
import { AttendanceStatus, Role } from '@prisma/client';
// Клас опису вхідних даних для валідації (DTO)
class MarkAttendanceDto {
records: { studentId: number; status: AttendanceStatus }[];
}
@Controller('api/attendance')
@UseGuards(JwtAuthGuard, RolesGuard) // Захист ендпоінтів
export class AttendanceController {
13
482 ЧДТУ 22144-01 12 01
constructor(private readonly attendanceService: AttendanceService) {}
// Ендпоінт для виставлення відміток (доступно тільки викладачам та адмінам)
@Post('schedule/:id/mark')
@Roles(Role.teacher, Role.admin)
async mark(
@Param('id', ParseIntPipe) scheduleId: number,
@Body() dto: MarkAttendanceDto,
@Req() req: any // Отримання даних авторизованого викладача з JWT
) {
const teacherId = req.user.id;
return this.attendanceService.markAttendance(scheduleId, teacherId, dto.records);
}
// Ендпоінт для отримання повної відомості по конкретному заняттю
@Get('schedule/:id/journal')
@Roles(Role.teacher, Role.dean, Role.admin)
async getJournal(@Param('id', ParseIntPipe) scheduleId: number) {
return this.attendanceService.getLessonJournal(scheduleId);
}
}
Лістинг програмного коду файлу documents.service.ts:
import { Injectable, NotFoundException } from '@nestjs/common';
import { PrismaService } from './prisma.service';
import { DocStatus, AttendanceStatus } from '@prisma/client';
@Injectable()
export class DocumentsService {
constructor(private prisma: PrismaService) {}
// Затвердження довідки деканатом із автоматичним оновленням журналу відвідуваності
async verifyDocument(documentId: number, verifierId: number, status: DocStatus) {
const document = await this.prisma.document.findUnique({
where: { id: documentId },
});
if (!document) throw new NotFoundException('Документ не знайдено');
14
482 ЧДТУ 22144-01 12 01
// 1. Оновлюємо статус документа в таблиці DOCUMENTS
const updatedDoc = await this.prisma.document.update({
where: { id: documentId },
data: { status, verifiedBy: verifierId },
});
// 2. Якщо документ затверджено, автоматично змінюємо 'absent' на 'excused' у журналі
за цей період
if (status === DocStatus.approved) {
// Шукаємо всі заняття студента, які потрапляють у часовий проміжок дії довідки
const schedulesInPeriod = await this.prisma.schedule.findMany({
where: {
group: { users: { some: { id: document.studentId } } },
lessonDate: {
gte: document.startDate,
lte: document.endDate,
},
},
});
const scheduleIds = schedulesInPeriod.map((s) => s.id);
// Масово оновлюємо пропуски на статус "поважна причина"
await this.prisma.attendance.updateMany({
where: {
studentId: document.studentId,
scheduleId: { in: scheduleIds },
status: AttendanceStatus.absent, // Тільки ті пари, де він дійсно був відсутній
},
data: {
status: AttendanceStatus.excused,
modifiedBy: verifierId,
updatedAt: new Date(),
},
});
}
return updatedDoc;
}
}
робочий код для сторінки створення та заповнення журналу:
import React, { useState } from 'react';
import { Student, AttendanceStatus, AttendanceRecord } from '../interfaces/types';
import { Check, X, Clock, FileText, Save } from 'lucide-react'; // Іконки
// Фейкові дані студентів для прикладу
15
482 ЧДТУ 22144-01 12 01
const mockStudents: Student[] = [
{ id: '1', name: 'Іваненко Іван Ігорович', ticketNumber: 'КВ-1023', groupId: 'IP-21' },
{ id: '2', name: 'Петренко Петро Петрович', ticketNumber: 'КВ-1024', groupId: 'IP-21' },
{ id: '3', name: 'Сидоренко Анна Олегівна', ticketNumber: 'КВ-1025', groupId: 'IP-21' },
];
export const CreateAttendanceSheet: React.FC = () => {
const [records, setRecords] = useState<AttendanceRecord[]>(
mockStudents.map(s => ({ studentId: s.id, status: 'PRESENT' }))
);
// Зміна статусу для конкретного студента
const handleStatusChange = (studentId: string, status: AttendanceStatus) => {
setRecords(prev =>
prev.map(r => r.studentId === studentId ? { ...r, status } : r)
);
};
// Зміна примітки
const handleCommentChange = (studentId: string, comment: string) => {
setRecords(prev =>
prev.map(r => r.studentId === studentId ? { ...r, comment } : r)
);
};
// Швидке відмічання всіх присутніми
const markAllPresent = () => {
setRecords(prev => prev.map(r => ({ ...r, status: 'PRESENT' })));
};
const handleSave = () => {
console.log('Дані журналу для відправки на Backend:', records);
// Тут буде виклик функції з services/attendance.ts через React Query Mutation
};
16
482 ЧДТУ 22144-01 12 01
return (
<div className="p-6 max-w-5xl mx-auto bg-gray-50 min-h-screen">
{/* Шапка налаштувань */}
<div className="bg-white p-4 rounded-xl shadow-sm mb-6 flex flex-wrap gap-4 justify-between
items-center">
<div>
<h1 className="text-xl font-bold text-gray-800">Створення журналу занять</h1>
<p className="text-sm text-gray-500">Група: <span className="font-semibold text-
gray-700">ІП-21</span> | Дисципліна: <span className="font-semibold text-gray-700">Веб-
технології</span></p>
</div>
<div className="flex gap-2">
<button
onClick={markAllPresent}
className="px-4 py-2 border border-gray-300 text-sm font-medium rounded-lg text-gray-700 bg-
white hover:bg-gray-50 transition"
>
Усі присутні
</button>
<button
onClick={handleSave}
className="flex items-center gap-2 px-4 py-2 bg-indigo-600 text-sm font-medium rounded-lg text-
white hover:bg-indigo-700 shadow-sm transition"
>
<Save size={16} /> Зберегти журнал
</button>
</div>
</div>
{/* Таблиця студентів */}
<div className="bg-white rounded-xl shadow-sm overflow-hidden">
<div className="overflow-x-auto">
<table className="min-w-full divide-y divide-gray-200">
17
482 ЧДТУ 22144-01 12 01
<thead className="bg-gray-50">
<tr>
<th className="px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase">Студент</th>
<th className="px-6 py-3 text-center text-xs font-medium text-gray-500 uppercase">Статус
відвідування</th>
<th className="px-6 py-3 text-left text-xs font-medium text-gray-500 uppercase">Примітка</th>
</tr>
</thead>
<tbody className="divide-y divide-gray-200 bg-white">
{mockStudents.map((student) => {
const record = records.find(r => r.studentId === student.id);
const currentStatus = record?.status || 'PRESENT';
return (
<tr key={student.id} className="hover:bg-gray-50 transition">
<td className="px-6 py-4 whitespace-nowrap">
<div className="font-medium text-gray-900">{student.name}</div>
<div className="text-xs text-gray-500">Квиток: {student.ticketNumber}</div>
</td>
<td className="px-6 py-4 whitespace-nowrap justify-center flex">
{/* Селектор статусів у стилі кнопок-перемикачів (Segmented Control) */}
<div className="inline-flex rounded-lg p-1 bg-gray-100 gap-1">
<button
type="button"
onClick={() => handleStatusChange(student.id, 'PRESENT')}
className={`p-2 rounded-md transition ${currentStatus === 'PRESENT' ? 'bg-green-500
text-white shadow-sm' : 'text-gray-600 hover:bg-gray-200'}`}
title="Присутній"
>
<Check size={18} />
</button>
<button
type="button"
onClick={() => handleStatusChange(student.id, 'ABSENT')}
18
482 ЧДТУ 22144-01 12 01
className={`p-2 rounded-md transition ${currentStatus === 'ABSENT' ? 'bg-red-500 text-
white shadow-sm' : 'text-gray-600 hover:bg-gray-200'}`}
title="Відсутній"
>
<X size={18} />
</button>
<button
type="button"
onClick={() => handleStatusChange(student.id, 'LATE')}
className={`p-2 rounded-md transition ${currentStatus === 'LATE' ? 'bg-amber-500 text-
white shadow-sm' : 'text-gray-600 hover:bg-gray-200'}`}
title="Запізнився"
>
<Clock size={18} />
</button>
<button
type="button"
onClick={() => handleStatusChange(student.id, 'EXCUSED')}
className={`p-2 rounded-md transition ${currentStatus === 'EXCUSED' ? 'bg-blue-500 text-
white shadow-sm' : 'text-gray-600 hover:bg-gray-200'}`}
title="Поважна причина"
>
<FileText size={18} />
</button>
</div>
</td>
<td className="px-6 py-4 whitespace-nowrap">
<input
type="text"
value={record?.comment || ''}
onChange={(e) => handleCommentChange(student.id, e.target.value)}
placeholder="Додати коментар..."
className="w-full text-sm px-3 py-1.5 border border-gray-200 rounded-md focus:outline-
none focus:border-indigo-500 text-gray-700"
19
482 ЧДТУ 22144-01 12 01
/>
</td>
</tr>
);
})}
</tbody>
</table>
</div>
</div>
</div>
);
};

Арк.
ЧДТУ 22000.004 ПЗ 73
Змн. Арк. № докум. Підпис Дата

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets