Web-платформа для відстеження проєктної діяльності програміста

Жалдак, Олександр Віталійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9568
Full metadata record
DC Field	Value	Language
dc.contributor.advisor	Немов, Руслан Григорович	-
dc.contributor.author	Жалдак, Олександр Віталійович	-
dc.date.accessioned	2026-06-16T08:56:02Z	-
dc.date.available	2026-06-16T08:56:02Z	-
dc.date.issued	2026-06-17	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/9568	-
dc.description.abstract	АНОТАЦІЇ Виконавець: Жалдак Олександр Віталійович Назва роботи: «Web-платформа для відстеження проєктної діяльності програміста» Спеціальність: 121 Інженерія програмного забезпечення. Навчальний заклад: «Черкаський державний технологічний університет» м. Черкаси, 2026р. Кваліфікаційна робота бакалавра на тему «Web-платформа для відстеження проєктної діяльності програміста» містить 109 сторінок, 5 таблиць, 48 рисунків, список використаних джерел з 34 найменувань, 4 додатків. Актуальність теми – з інженерії програмного забезпечення є розробка програмного забезпечення для відстеження проєктної діяльності є актуальним завданням, тому що з розвитком IT-індустрії та зростанням популярності віддаленої роботи виникає потреба у ефективних інструментах контролю, планування та аналізу робочого процесу програмістів Основна мета – web-платформа, що орієнтована на автоматизованому процесі збору даних про робочу активність розробників як для індивідуальних користувачів так і для IT-команд. Об’єкт розробки – є процес розробки програмного забезпечення web-платформи для відстеження проєктної діяльності Предметом розробки – є архітектура та програмне забезпечення web-платформи (Node.js, React, Electron, PostgreSQL) для відстеження проєктної діяльності програміста. У роботі проведено аналіз предметної області та існуючих аналогів (Jira, Toggl, RescueTime), обґрунтовано вибір технологічного стека (Node.js, React, Electron, PostgreSQL) та спроєктовано архітектуру системи за допомогою UML-моделювання. Результатом роботи є програмний комплекс, що дозволяє переглядати статистику та забезпечує контроль для розробників.	uk_UA
dc.description.abstract	ANNOTATIONS Performer: Zhaldak Oleksandr Vitaliiovych The title of the work: "Web platform for tracking programmer's project activity" Specialty: 121 Software Engineering Cherkasy State Technological University Cherkasy, 2026 The qualification thesis titled "Web Platform for Tracking Programmer's Project Activity" contains 109 pages, 5 tables, 48 figures, a list of references with 34 sources, and 4 appendices. The project provides automated user activity data collection, including screenshot capturing and real-time activity tracking. Topicality of the theme. In the field of software engineering, developing software for project activity tracking is a highly relevant task. With the continuous growth of the IT industry and the rising popularity of remote work, there is an increasing demand for effective tools to monitor, plan, and analyze the workflow of software developers. Main objective. The main objective is to develop a web platform focused on the automated collection of work activity data for both individual users and IT teams. Object of research. The object of research is the processes of time tracking and productivity analysis for individual developers and remote IT teams. Subject of development. The subject of development is the architecture and software of a web platform (Node.js, React, Electron, PostgreSQL) designed for tracking a programmer's project activities. Summary. The work provides an analysis of the domain area and existing analogs (Jira, Toggl, RescueTime), justifies the choice of the technological stack (Node.js, React, Electron, PostgreSQL), and designs the system architecture using UML modeling. The final result of the work is a software suite that enables data visualization (statistics viewing) and ensures control for developers.	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	WEB-платформа	uk_UA
dc.subject	моніторінг	uk_UA
dc.subject	таймер	uk_UA
dc.subject	розробник	uk_UA
dc.subject	NODE.JS	uk_UA
dc.subject	TYPESCRIPT	uk_UA
dc.subject	POSTGRESQL	uk_UA
dc.subject	REACT	uk_UA
dc.subject	візуалізація	uk_UA
dc.subject	ELECTRON	uk_UA
dc.subject	керівник	uk_UA
dc.subject	WEB PLATFORM	uk_UA
dc.subject	MONITORING	uk_UA
dc.subject	TIMER	uk_UA
dc.subject	DEVELOPER	uk_UA
dc.subject	NODE.JS	uk_UA
dc.subject	TYPESCRIPT	uk_UA
dc.subject	POSTGRESQL	uk_UA
dc.subject	REACT	uk_UA
dc.subject	VISUALIZATION	uk_UA
dc.subject	ELECTRON	uk_UA
dc.subject	MANAGER	uk_UA
dc.subject	SYSTEM	uk_UA
dc.title	Web-платформа для відстеження проєктної діяльності програміста	uk_UA
dc.type	Bachelor Thesis	uk_UA
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Кваліфікаційна_робота бакалавра Жалдак Олександр Віталійович.pdf Restricted Access		5.76 MB	Adobe PDF	View/Open Request a copy
Show simple item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
бакалавра 
на тему: «WEB-платформа для відстеження проєктної діяльності 
програміста» 
Виконав: студент 4 курсу, групи ПЗ-2204 
спеціальності  
121 «Інженерія програмного забезпечення» 
(шифр і назва напряму підготовки) 
Студент Жалдак О.В.
(прізвище та ініціали) 
Керівник Немов Р.Г.
(прізвище та ініціали) 
Рецензент   Русалівський Б.В.
(прізвище та ініціали) 
Черкаси 2026 
 
 Черкаський державний технологічний університет 
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем  
Кафедра  програмного забезпечення автоматизованих систем  
Освітній рівень  бакалавр  
Спеціальність 121 «Інженерія програмного забезпечення»  
Освітня програма Інженерія програмного забезпечення  
 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
____________________ С. Голуб  
«___» _______________ 2026 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
  Жалдаку Олександру Віталійовичу  
(прізвище, ім’я, по батькові) 
1. Тему проекту (роботи) Web-платформа для відстеження проєктної діяльності програміста  
Керівник проекту (роботи) Немов Руслан Григорович   
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від «  12  » березня 2026 року 
№56/03-03 
2. Строк подання студентом проекту (роботи) 3 червня 2026 року  
3. Вхідні дані до проекту (роботи): Технічне завдання на розробку інтерактивної web-платформи; 
автоматизовані системи; терміни та визначення; методичні рекомендації до виконання бакалаврської 
кваліфікаційної роботи;  
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ; 
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань (аналіз предметної області, огляд 
аналогів та обґрунтування технологічного стеку);  
Розділ 2. Проектування архітектури та логічної структури системи діагностики;  
Розділ 3. Реалізація та тестування програмного комплексу;  
Висновки;  
Список використаних джерел;  
Додатки.  
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту Слайд 1; Слайд 2; Слайд 
3; Слайд 4; Слайд 5; Слайд 6; Слайд 7; Слайд 8; Слайд 9; Слайд 10; Слайд 11; Слайд 12; Слайд 13; Слайд 14; Слайд 
15; Слайд 16; Слайд 17; Слайд 18; Слайд 19; Слайд 20; Слайд 21; Слайд 22;  
 
 
6. Консультанти розділів роботи 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
7. Дата видачі завдання грудень 2025 р.  
 
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання 
№ 
Назва етапів випускної роботи етапів кваліфікаційної Примітки 
п/п 
роботи 
1 Постановка задачі 05.12.2025 виконано 
2 Підготовка завдання 13.12.2025 виконано 
3 Погодження завдання 16.12.2025 виконано 
4 Затвердження завдання 19.02.2026 виконано 
 Основна стадія   
1 Підбір матеріалів 27.02.2026 виконано 
2 Аналіз шляхів вирішення поставленої задачі 04.02.2026 виконано 
3 Розрахунок основних параметрів роботи 10.03.2026 виконано 
4 Вибір кінцевого варіанту проектного рішення 17.03.2026 виконано 
5 Оформлення первісної редакції роботи 25.03.2026 виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з 31.04.2026 виконано 
керівником 
2 Оформлення пояснювальної записки роботи в 13.05.2026 виконано 
кінцевій редакції 
3 Попередній захист роботи 19.05.2026 виконано 
4 Затвердження роботи 19.05.2026 виконано 
5 Рецензування роботи 26.05.2026 виконано 
6 Захист роботи 03.06.2026  
 
Студент _____________________  Жалдак О.В. 
  (підпис)   (прізвище та ініціали) 
 
Керівник роботи _____________________  Немов Р. Г. 
  (підпис)   (прізвище та ініціали) 
 
 
АНОТАЦІЇ 
Виконавець: Жалдак Олександр Віталійович 
Назва роботи: «Web-платформа для відстеження проєктної діяльності 
програміста» 
Спеціальність: 121 Інженерія програмного забезпечення. 
Навчальний заклад: «Черкаський державний технологічний університет»      
м. Черкаси, 2026р. 
Кваліфікаційна робота бакалавра на тему «Web-платформа для відстеження 
проєктної діяльності програміста» містить 109 сторінок, 5 таблиць, 48 рисунків, 
список використаних джерел з 34 найменувань, 4 додатків.  
Актуальність теми – з інженерії програмного забезпечення є розробка 
програмного забезпечення для відстеження проєктної діяльності є актуальним 
завданням, тому що з розвитком IT-індустрії та зростанням популярності віддаленої 
роботи виникає потреба у ефективних інструментах контролю, планування та 
аналізу робочого процесу програмістів  
Основна мета – web-платформа, що орієнтована на автоматизованому 
процесі збору даних  про робочу активність розробників як для індивідуальних 
користувачів так і для IT-команд.  
Об’єкт розробки – є процес розробки програмного забезпечення web-
платформи для відстеження проєктної діяльності  
Предметом розробки – є архітектура та програмне забезпечення web-
платформи (Node.js, React, Electron, PostgreSQL) для відстеження проєктної 
діяльності програміста. 
У роботі проведено аналіз предметної області та існуючих аналогів (Jira, 
Toggl, RescueTime), обґрунтовано вибір технологічного стека (Node.js, React, 
Electron, PostgreSQL) та спроєктовано архітектуру системи за допомогою UML-
моделювання. Результатом роботи є програмний комплекс, що дозволяє 
переглядати статистику та забезпечує контроль для розробників. 
 
Ключові слова: WEB-платформа, моніторінг, таймер, розробник, NODE.JS, 
TYPESCRIPT, POSTGRESQL, REACT,  візуалізація, ELECTRON, керівник. 
 
 
ANNOTATIONS 
Performer: Zhaldak Oleksandr Vitaliiovych  
The title of the work: "Web platform for tracking programmer's project activity"  
Specialty: 121 Software Engineering  
Cherkasy State Technological University 
Cherkasy, 2026 
The qualification thesis titled "Web Platform for Tracking Programmer's Project 
Activity" contains 109 pages, 5 tables, 48 figures, a list of references with 34 sources, and 
4 appendices. The project provides automated user activity data collection, including 
screenshot capturing and real-time activity tracking. 
Topicality of the theme. In the field of software engineering, developing software 
for project activity tracking is a highly relevant task. With the continuous growth of the 
IT industry and the rising popularity of remote work, there is an increasing demand for 
effective tools to monitor, plan, and analyze the workflow of software developers. 
Main objective. The main objective is to develop a web platform focused on the 
automated collection of work activity data for both individual users and IT teams. 
Object of research. The object of research is the processes of time tracking and 
productivity analysis for individual developers and remote IT teams. 
Subject of development. The subject of development is the architecture and 
software of a web platform (Node.js, React, Electron, PostgreSQL) designed for tracking 
a programmer's project activities. 
Summary. The work provides an analysis of the domain area and existing analogs 
(Jira, Toggl, RescueTime), justifies the choice of the technological stack (Node.js, React, 
Electron, PostgreSQL), and designs the system architecture using UML modeling. The 
final result of the work is a software suite that enables data visualization (statistics 
viewing) and ensures control for developers. 
 
Keywords: WEB PLATFORM, MONITORING, TIMER, DEVELOPER, 
NODE.JS, TYPESCRIPT, POSTGRESQL, REACT, VISUALIZATION, ELECTRON, 
MANAGER, SYSTEM. 
 
 
ЗМІСТ 
  
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ТА СКОРОЧЕНЬ .......................................... 6 
ВСТУП .......................................................................................................................... 7 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ ..................................................................................................................... 9 
1.1. Порівняння та аналіз існуючих аналогів ................................................ 9 
1.2. Постановка задачі ................................................................................... 12 
1.3. Вибір технологій для розробки додатку ............................................... 13 
1.3.1. Технологічний стек front-end частини ........................................ 13 
1.3.2. Технологічний стек back-end частини ........................................ 14 
1.3.3. Технології розгортання клієнтського додатку ............................ 15 
1.3.4. Вибір середовища розробки ......................................................... 15 
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ ........................................................ 16 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ .................................................................................................................... 17 
2.1. Моделювання предметної області .......................................................... 17 
2.1.1. Предметна область моделювання. Модель предметної області. 
Словник предметної області. ................................................................. 17 
2.1.2. Елементи моделювання предметної області .............................. 19 
2.1.3. Робоча область моделювання ....................................................... 20 
2.2. Формування та аналіз вимог ................................................................... 21 
2.2.1. Формування вимог до програмного забезпечення. Первинні і 
детальні вимоги. Вимоги замовника і розробника. Функціональні та 
нефункціональні вимоги ........................................................................ 21 
2.2.2. Формування вимог за допомогою діаграм прецедентів ............ 24 
2.3. Проектування логічної структури програмного комплексу ................. 26 
2.3.1. Діаграма класів .............................................................................. 26 
2.3.2. Діаграма пакетів ............................................................................ 30 
2.4. Архітектурне проектування .................................................................... 31 
  
ЧДТУ.262242.004 ПЗ 
Зм Арк. № докум. Підпис Дата 
 Розроб. Жалдак О.В. «WEB-платформа для Літ. Арк. Акрушів 
 Перевір. Немов Р. Г 4  
відстеження проєктної 
  
 Н. Контр. Немов Р. Г. діяльності програміста» ФІТІС, кафедра ПЗАС,  ПЗ-2204 
 Затверд. Голуб С.В. Пояснювальна записка.  
 
2.4.1. Діаграма компонентів ................................................................... 31 
2.4.2. Розгортання програмної системи на апаратних засобах. 
Діаграма розгортання.............................................................................. 33 
2.5. Моделювання поведінки системи ........................................................... 34 
2.5.1. Діаграма діяльності. ...................................................................... 34 
2.5.2. Діаграма послідовності ................................................................ 36 
2.5.3. Діаграма коммунікацій ................................................................. 37 
2.5.4. Діаграма скінченного автомата .................................................... 38 
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ ......................................................... 41 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 42 
3.1 Розробка программного комплексу ....................................................... 42 
3.1.1. Обгрунтування вибору засобів реалізації ................................... 43 
3.1.2. Опис структурної (функціональної) схеми ................................ 45 
3.1.3. Опис логічної схеми системи....................................................... 48 
3.1.4. Розробка бази даних...................................................................... 50 
3.1.5. Розробка інтерфейсу користувача ............................................... 50 
3.1.6. Опис розробки програмних компонентів ................................... 56 
3.2. Тестування програмного забезпечення .................................................. 58 
3.2.1. Модульне тестування .................................................................... 59 
3.2.2. Інтеграційне тестування ............................................................... 61 
3.2.3. Системне тестування .................................................................... 63 
3.2.4. Приймальне тестування ............................................................... 65 
3.3 Приклади впровадження програмного комплексу ................................. 67 
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ ....................................................... 69 
ВИСНОВКИ ............................................................................................................... 42 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 72 
ДОДАТОК А .............................................................................................................. 75 
ДОДАТОК Б ............................................................................................................... 77 
ДОДАТОК В ............................................................................................................... 95 
ДОДАТОК Г ............................................................................................................... 98 
ЧДТУ 262242.004 ПЗ
Змн. Арк. № докум. Підпис Дата 
ЧДТУ 262242.004 ПЗ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ТА СКОРОЧЕНЬ 
IT Сфера технологій збору, обробки, зберігання та передачі 
 даних. 
WEB Розподілена система взаємопов'язаних гіпертекстових 
 документів у мережі. 
URL Стандартизований уніфікований покажчик адреси 
 ресурсу в комп'ютерній мережі. 
HTTP Прикладний протокол передачі гіпертекстових даних у 
 клієнт-серверній архітектурі. 
HTTPS Розширення протоколу HTTP з підтримкою шифрування 
 (TLS/SSL) для захисту даних. 
UI Сукупність графічних та функціональних засобів для 
 взаємодії користувача з системою. 
PiP Режим інтерфейсу, що відображає таймер в 
 автономному вікні поверх інших програм. 
DOM Об'єктна деревоподібна модель структури документа 
 (HTML/XML) для програмного керування ним. 
CSS Формальна мова опису візуального представлення та 
 стилізації документів розмітки. 
БД База даних. Упорядкована сукупність взаємопов'язаних 
 даних, організована за певною концептуальною 
 моделлю. 
SQL Мова для керування даними в реляційних СУБД. 
JSON Текстовий формат обміну структурованими даними на 
 основі пар «ключ — значення». 
API Специфікований інтерфейс взаємодії та обміну даними 
 між програмними компонентами. 
UML Мова графічного моделювання для візуалізації та 
проєктування.
6 
ЧДТУ 262242.004 ПЗ 
ВСТУП 
Актуальність теми – з інженерії програмного забезпечення є розробка 
програмного забезпечення для відстеження проєктної діяльності є актуальним 
завданням, тому що в з розвитком IT-індустрії та зростанням популярності 
віддаленої роботи виникає потреба у ефективних інструментах контролю, 
планування та аналізу робочого процесу програмістів. Такі системи дозволяють не 
лише фіксувати витрачений час, але й отримувати детальну інформацію про 
продуктивність, завантаженість та ефективність виконання завдань. 
Сучасні платформи дозволяють відстежувати активність розробника, 
аналізувати використання програм і web-сторінок, переглядати статистику та 
створювати аналітичні звіти. Використання таких додатків є корисним як для 
керівників проєктів, так і для самих розробників. Керівники отримують можливість 
контролювати процес виконання завдань, оцінювати ефективність роботи команди 
та приймати обґрунтовані рішення по управлінню проектами, а програмісти 
можуть аналізувати власну продуктивність, виявляти неефективні витрати часу та 
оптимізувати робочий процес.  
Мета і завдання розробки – метою кваліфікаційної роботи є теоретичне 
обґрунтування, проєктування та практична реалізація web-платформи для 
відстеження проєктної діяльності програміста. Web-платформа, що орієнтована на 
автоматизованому процесі збору даних  про робочу активність розробників як для 
індивідуальних користувачів так і для IT-команд. Платформа повинна допомогти 
користувачам виявити проблеми використання часу на розробку проєктів, як 
індивідуальних розробників так і команд та візуалізувати продуктивность  у вигляді 
діаграм. 
Завдання розробки: 
1 Аналіз предметної області та існуючих аналогів систем 
2 Визначення вимог до системи 
3 Вибір технологічного стеку 
4 Розробка інтерфейсу користувача 
5 Розробка серверної частини системи 
7 
ЧДТУ 262242.004 ПЗ 
6 Розробка desktop-компонента 
7 Реалізація функціоналу статистики та звітності 
8 Тестування та впровадження системи 
Об’єкт розробки – є процес розробки програмного забезпечення web-
платформи для відстеження проєктної діяльності. 
Предметом розробки – є архітектура та програмне забезпечення web-
платформи (Node.js, React, Electron, PostgreSQL) для відстеження проєктної 
діяльності програміста. 
Практичне значення одержаних результатів – розробка web-платформи 
для відстеження проєктної діяльності програміста виступає інструментом для 
оптимізації робочих процесів в IT-сфері. Завдяки автоматизації збору даних про 
активність програміста, система забезпечує точність обліку робочих годин, що є 
критично важливим для ефективного планування та дотримання термінів реалізації 
програмних проектів.  
Особистий внесок автора – під час виконання кваліфікаційної роботи 
автором було реалізовано повний цикл розробки web-платформи для відстеження 
проектної діяльності програміста. 
Було самостійно розроблено архітектуру системи, що забезпечує стабільну 
взаємодію між web-інтерфейсом на React, серверною частиною та desktop-додатком 
на базі Electron. При проектуванні web-платформи основою була ідея зручній та 
ефективній взаємодії користувача з платформою, тому було реалізовано навігацію 
сторінки у вигляді бокової панелі(sidebar), інтуїтивно зрозумілий графічний 
інтерфейс та було візуалізовано звіти робочого часу та активності розробника у 
вигляді діаграм та графіків, які можна експортувати у вигляді СSV-формату. 
Програмний код серверної логіки на Node.js було систематизовано та інтегровано з 
базою даних PostgreSQL.  
Процес виконання роботи охопив технічну реалізацію платформи  
проєктування логіки взаємодії, візуалізацію аналітичних даних.  Перевірка логіки 
взаємодії та системний підхід до реалізації функціоналу забезпечують 
відповідність проекту функціональним та нефункціональним вимогам.  
8 
ЧДТУ 262242.004 ПЗ 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
У цьому розділі буде зроблено аналіз функціоналу існуючих аналогів, 
визначено їх переваги та недоліки, обґрунтовано вибір інструментів і технологій 
для розробки власної web-платформи.  
1.1. Порівняння та аналіз існуючих аналогів 
При розробці власного програмного забезпечення необхідно провести аналіз 
вже існуючих сайтів, що мають схожий функціонал. Це потрібно для того, щоб 
визначити їх сильні сторони, перейняти найкращі рішення та уникнути можливих 
помилок під час розробки власного продукту. 
Крім цього, аналіз існуючих платформ дозволяє краще зрозуміти потреби 
користувачів, а також визначити, які функції є найбільш важливими у системах для 
управління проектами та відстеження діяльності. Це допомагає сформувати більш 
чіткі вимоги до майбутньої web-платформи та зробити її більш зручною та 
ефективною у використанні. 
В цьому підрозділі буде зроблено аналіз вже існуючих аналогів для 
управління проєктами, визначені переваги та недоліки, зроблені висновки, які 
будуть враховані при розробці власного додатку: 
1 Jira – це професійна web-платформа управління проектами та задачами від 
компанії Atlassian, яка використовується IT-командами для планування, 
відстеження часу, витраченого на проєкти, розробки ПЗ [15]. 
Переваги: 
− гнучкість налаштування – можливість налаштування унікальних 
налаштувань для кожного завдання (workflow) та автоматизація переходів між 
етапами розробки; 
− інтеграція – наявність розвиненого API та плагінів, які дозволяють 
синхронізувати дані з репозиторіями(GitHub, Bitbucket та ін); 
− аналітика та візуалізація – модуль побудови звітів (Burndown charts, 
Cumulative Flow Diagrams), який дозволяє оцінювати ефективність роботи команд. 
9 
ЧДТУ 262242.004 ПЗ 
Недоліки: 
− обмеження web-платформи – Jira функціонує як web-платформа, тому 
вона обмежена в своєму функціоналі. Без desktop-додатку неможливо відслідкувати 
активність розробника; 
− відсутність перевірки – в Jira відсутнє відстеження активних вікон 
програм або створення знімків робочого столу розробника без використання 
сторонніх модулів; 
− cкладність інтерфейсу – складність структури сайту та безліч 
налаштувань,  на які розробник витрачає час на адаптацію та налаштування завдань 
замість виконання роботи. 
2 Toggl Track – один із найбільш розповсюджених інструментів для 
індивідуального та командного обліку часу, який орієнтований на простоту та 
швидкість взаємодії [14]. 
Переваги: 
− кросплатформеність – наявність web-інтерфейсу, мобільних та desktop-
додатків, а також розширень для браузерів забезпечує доступ до системи з будь-
якого пристрою; 
− зрозумілий UX – дизайн дозволяє почати роботу з таймером без 
попереднього досвіду, що мінімізує поріг входження для нових користувачів; 
− автоматичні нагадування – система має вбудовану функцію нагадувань 
про необхідність запуску таймера, якщо виявлено активність користувача, але запис 
часу не ведеться; 
− детектор бездіяльності – якщо користувач відійшов від робочого місця і 
не вимкнув таймер, то додаток дозволяє видалити цей час.  
Недоліки: 
− відсутність функціоналу верифікації активності – платформа повністю 
базується на довірі до користувача. У додатку відсутні інструменти підтвердження 
активності (наприклад; знімки екрана та відстеження активності за допомогою 
перевірки посилань на які заходив розробник та натискань клавіш миші чи 
клавіатури); 
10 
ЧДТУ 262242.004 ПЗ 
− cлабкий функціонал управління задачами – платформа є виключно 
«таймером» і не містить вбудованих інструментів для повноцінного планування; 
− обмеженість безкоштовної версії – більшість функцій аналітики та 
автоматизації доступні лише у платних тарифах. 
3 RescueTime представляє платформу відстеження активності, що працює у 
фоновому режимі та автоматично класифікує активність користувача на основі 
запущених додатків та відвіданих web-ресурсів [16]. 
Переваги:  
− повна автоматизація – додаток автоматично фіксує активність розробника 
та вкладки та програми що він використовує;  
− глибока аналітика – сервіс вираховує саме продуктивність та автоматично 
визначає активність на категорії(VS Code – «продуктивно», YouTube – 
«відволікає»); 
− режим концентрації – RescueTime може заблокувати доступ до соцмереж 
та розважальних сайтів на вашому комп'ютері для покращення продуктивності; 
− облік офлайн-активності – якщо користувач відійшов від робочого місця, 
після повернення програма може запитати: «Чим ви займалися?» і додати цей час у 
звіт; 
− кросплатформеність – додаток може працювати з різними пристроями та 
збирати дані з ПК та мобільних пристроїв. 
Недоліки: 
− відсутність функцій для командної роботи – RescueTime розроблений в 
основному як індивідуальний інструмент. У ньому відсутні функції для менеджерів 
(наприклад; розподіл задач між розробниками або порівняльна аналітика в межах 
одного проекту); 
− відсутність засобів візуального підтвердження – система фіксує лише 
метадані (назви вікон, URL-адреси), але не підтримує створення знімків екрана, що 
обмежує можливості верифікації роботи для керівників проекту; 
− проблема точності даних – алгоритм фіксує лише ту програму, яка 
знаходиться у фокусі. Це створює похибки, якщо розробник використовує кілька 
11 
ЧДТУ 262242.004 ПЗ 
моніторів (наприклад, дивиться документацію на одному, а пише код на іншому) 
або якщо медіафайли відтворюються у фоні – система може не зарахувати це як 
активність або, навпаки, приписати час не тій програмі. 
1.2. Постановка задачі 
Основним завданням є проєктування та розробка web-платформи для 
відстеження проєктної діяльності програміста, яка може використовуватися як для 
індивідуальної роботи, так і для командної взаємодії. Система має забезпечувати 
автоматизоване відстеження активності користувача, створення команд, зберігання 
отриманих даних у базі даних та їх подальшу візуалізацію через інтерактивні звіти 
у вигляді діаграм. Функціонал платформи розрахований на дворівневу модель 
використання, де розробник отримує засіб для самоконтролю та планування та 
звітів, а керівник проєкту – інструментарій для аналізу загальної статистики 
команди та перевірки виконання робіт. При цьому додаток повинен бути зручним у 
інтерфейсі, швидким, адаптивним і для вирішення проблем з функціоналом – 
кросплатформенним. 
Для цього у рамках завдання необхідно вирішити такі задачі: 
1 Аналіз предметної області та існуючих аналогів систем – дослідження 
сучасних систем відстеження активності користувачів, визначення їхніх 
переваг, недоліків та можливостей застосування у власному проєкті. 
2 Визначення вимог до системи – формування функціональних та 
нефункціональних вимог до web-платформи відстеження проєктної 
діяльності, визначення основних функцій і вимог до стабільності та 
безпеки системи. 
3 Вибір технологічного стеку – обґрунтування вибору сучасних технологій 
для реалізації клієнтської, серверної та desktop-частини системи. 
4 Розробка інтерфейсу користувача – створення зручного та інтуїтивно 
зрозумілого інтерфейсу web-платформи для роботи з проєктами, 
задачами та статистикою активності. 
12 
ЧДТУ 262242.004 ПЗ 
5 Розробка серверної частини системи – реалізація back-end архітектури з 
підтримкою REST API, авторизації, розмежування прав доступу та 
взаємодії з базою даних. 
6 Розробка desktop-компонента – створення компонента для розширення 
функціоналу створення скріншотів та активності користувача. 
7 Реалізація функціоналу статистики та звітності – створення засобів 
візуалізації персональної та командної статистики у вигляді 
інтерактивних діаграм та графіків. 
8 Тестування та впровадження системи – проведення комплексного 
тестування ресурсу для перевірки коректності роботи та відповідності 
вимогам технічного завдання. 
1.3. Вибір технологій для розробки додатку 
Після проведення аналізу та визначення основних вимог необхідно підійти до 
вибору технологій для реалізації власного програмного забезпечення. Виявлені 
недоліки існуючих аналогів, а також поставлені задачі дозволяють сформувати 
чітке уявлення про необхідний технологічний стек для вирішення задач. 
В цьому розділі буде проведено вибір технологій, фреймворків для розробки 
клієнтської front-end та серверної back-end частин, а також систем управління 
базами даних (СУБД). Вибрані технології дозволять реалізувати архітектуру, яка 
здатна ефективно обробляти обсяги інформації та підтримувати цілісність даних 
при їх складній аналітичній обробці. 
1.3.1. Технологічний стек front-end частини  
Технології front-end частини: 
− React – бібліотека для побудови інтерфейсів, вона базується на 
компонентному підході [6]. Компоненти можна повторно використати, що значно 
спрощує файлову структуру проекту та процес розробки. Окрім цього, за 
допомогою Virtual DOM, інтерфейс миттєво реагує на зміни на сторінці, тому такі 
елементи, як таймер або будь-яка зміна стану інтерфейсу, будуть оновлюватися без 
перезавантаження сторінки.  
13 
ЧДТУ 262242.004 ПЗ 
− TypeScript – мова програмування із суворою типізацією. Її використання 
дозволить впровадити чіткі структури даних, що допоможе уникнути помилок при 
передачі об’єктів між клієнтською та серверною частинами [5]. На відміну від 
JavaScript, який є динамічно типізованою мовою, TypeScript дозволяє виявляти 
значну частину помилок ще на етапі розробки, а не під час виконання програми. Це 
підвищує надійність коду, спрощує його підтримку та особливо важливо при 
розробці проектів, де використовується складна взаємодія між різними частинами 
системи. 
− Recharts – бібліотека React для побудови графіків. Вона буде використана 
для візуалізації звітів у вигляді зрозумілих інтерактивних діаграм для аналізу 
ефективності роботи [6]. 
− React Router Dom – бібліотека React для реалізації маршрутизації між 
сторінками у web-додатках [3].  
− React Hook Form – бібліотека React для керування станом форм. Вона 
дозволить реалізувати складні форми реєстрації, створення проектів та редагування 
профілю користувача. 
1.3.2. Технологічний стек back-end частини 
Технології back-end частини: 
− Node.js – як середовище виконання для back-end частини додатка, 
забезпечуючи високу швидкість обробки мережевих запитів [2]. Node.js може 
працювати з великою кількістю одночасних запитів. Також використання Node.js 
дозволяє використовувати одну мову програмування, як на front-end, так і на back-
end частині, що спрощує розробку і зменшує кількість помилок; 
− Express  – фреймворк для середовища Node.js, призначений для створення 
серверних додатків[10]. Він буде основою для back-end частини web-платформи для 
ефективної маршрутизації запитів та обробки логіки управління проектами; 
− Socket.io – бібліотека для забезпечення зв'язку між клієнтом і 
сервером[33]. За допомоги нього можливо реалізувати миттєву передачу даних про 
14 
ЧДТУ 262242.004 ПЗ 
активність і система зможе оновлювати стан таймерів та статусів на інформаційній 
сторінці користувача без необхідності перезавантаження сторінки; 
− PostgreSQL – вибір цієї СУБД дозволить побудувати надійну структуру 
збереження інформації, забезпечуючи цілісність даних при роботі зі складними 
зв’язками між користувачами, задачами та записами робочого часу. Він має більші 
можливості для роботи зі складними запитами та краще підтримує зв’язки між 
таблицями та забезпечує більший контроль цілісності даних ніж MySQL [11]; 
− JSON Web Token (JWT) –  технологія для побудови системи авторизації, 
що дозволить ідентифікувати користувачів та надавати захищений доступ до 
функцій API за допомогою зашифрованих токенів[9]; 
− bcrypt – функція, яка призначена для безпечного хешування паролів [12]. 
1.3.3. Технології розгортання клієнтського додатку 
Electron – фреймворк для створення кросплатформних desktop-додатків за 
допомоги web-технологій. Він дозволить вирішити проблеми з функціоналом web-
платформи та запустити front-end частину додатка у вигляді окремої програми, 
використовуючи можливості Node.js для доступу до ресурсів системи [8]. 
1.3.4. Вибір середовища розробки  
Visual Studio Code – редактор вихідного коду, розроблений корпорацією 
Microsoft на базі фреймворку Electron. Він запускається миттєво і споживає менше 
ресурсів ніж інші IDE(Intellij idea, Visual Studio) при цьому майже не програє їм у 
можливостях за допомоги власного модулю розширень, що дозволяє розробнику 
самостійно налаштовувати та встановити необхідні технології відповідно до вимог 
проекту та індивідуальних потреб розробника [34].  
 
  
15 
ЧДТУ 262242.004 ПЗ 
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ 
У першому розділі проведено комплексний аналіз сучасних методів та засобів 
відстеження проєктної діяльності, що дозволило визначити основні напрями для 
розробки власної web-платформи. Розглянуто функціональні можливості 
популярних аналогів, що дало змогу виявити їхні переваги та недоліки. На основі 
проведеного порівняльного аналізу сформовано детальний перелік завдань 
кваліфікаційної роботи, основний акцент на створенні системи, що поєднує гнучке 
управління задачами з автоматизованим відстеженням робочого процесу 
(скріншоти, активні вікна). Обґрунтовано вибір технологічного стеку: React та 
TypeScript для побудови front-end частини, Node.js та Express для back-end частини, 
PostgreSQL для забезпечення цілісності даних. Electron як рішення для реалізації 
кросплатформенного desktop-додатка, що вирішить технічні обмеження браузерів. 
У результаті було закладено теоретичний та технічний фундамент для подальшого 
проєктування архітектури системи. Визначено, що майбутня платформа має 
забезпечувати баланс між інструментами індивідуального контролю розробника та 
аналітичними засобами для керівника проєкту, що створює чітку основу для 
переходу до етапу проектування  та розробки структури бази даних. 
  
16 
ЧДТУ 262242.004 ПЗ 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ 
У цьому розділі розглянуто проектування web-платформи. Основна увага 
виділена архітектурним рішенням, функціональним та нефункціональним вимогам, 
організації клієнт-серверної взаємодії та моделюванню предметної області. 
2.1. Моделювання предметної області 
Моделювання предметної області є основою у розробці web-платформи перед 
проєктуванням та написанням коду. У контексті платформи для відстеження 
проєктної діяльності, моделювання забезпечує врахування потреб двох основних 
груп користувачів: керівників  та розробників. Це включає створення дворівневої 
моделі. Основна мета – створити представлення про основні об’єкти системи, 
властивості та їх взаємозв’язки.  У представленні платформи моделювання 
предметної області забезпечує врахування потреб користувачів, такі як доступність 
інтерфейсу, сповіщення, адаптивність. Це також включає створення 
моделей(концепептуальної, логічної і фізичної). Це зменшує ризик помилок та 
забезпечення зручності використання для керівників та розробників. Окрім 
статичних структур, моделювання предметної області платформи охоплює бізнес-
правила обробки активності. Зокрема, це автоматизовані алгоритми розрахунку 
інтенсивності роботи на основі вводу користувача та механізми переходу системи 
в стан простою. Це дозволяє передати актуальні дані аналітики керівнику команди. 
2.1.1. Предметна область моделювання. Модель предметної області. Словник 
предметної області. 
Предметна область моделювання – предметна область моделювання 
платформи для відстеження проєктної діяльності програміста охоплює процеси, 
пов’язані з автоматизованим відслідковуванням часу, обліком та аналізом 
продуктивності розробника в процесі виконання проєктів. Вона включає збір 
технічної інформації активності (взаємодія з пристроями вводу), реєстрацію 
17 
ЧДТУ 262242.004 ПЗ 
часових інтервалів роботи, візуальну фіксацію робочого процесу 
(скріншоти), а також механізми обробки та візуалізації цих даних для керівників та 
розробників. 
Модель предметної області – відображає логічну структуру платформи. 
Основним об’єктом системи є користувач, що взаємодіє з платформою через web-
інтерфейс та desktop-додаток. Система забезпечує підрахунок робочого часу, 
управління проєктами та задачами, автоматичне відстеження активності 
користувача та створює скріншоти робочого процесу. Модель враховує командну 
взаємодію, керівник команди може контролювати виконання задач, переглядати 
статистику команди та завантажувати звіти. 
Словник предметної області – на основі аналізу діяльності програміста було 
виділено ключові сутності, які відображають процес відслідковування та 
управління проєктами. Сформуємо словник предметної області (табл. 2.1), що 
описує доменні об’єкти, які будуть використані при створенні логічної моделі 
системи. 
Таблиця 2.1 
Словник предметної області 
№ Назва Назва Опис 
1 Користувач User Сутність, що містить автентифікаційні дані та 
визначає роль у системі (Admin/Member). 
2 Команда Team Логічне об'єднання користувачів. Користувач 
може бути власником команди або її учасником. 
3 Проєкт Project Об’єкт, що належить або надається керівником 
користувачу. 
4 Завдання Task Конкретна одиниця роботи, що має назву, тип та 
поточний статус виконання. 
5 Сесія Session Динамічний об'єкт, що фіксує проміжок часу, 
витрачений користувачем на конкретне 
завдання. 
 
18 
ЧДТУ 262242.004 ПЗ 
Продовження таблиці 2.1 
6 Скріншот Screenshot Елемент відслідковування, що містить 
посилання на файл, заголовок вікна та 
розрахований рівень активності. 
 
2.1.2. Елементи моделювання предметної області 
Проєктування архітектури системи базується на використанні уніфікованої 
мови моделювання UML. Згідно з методичними вимогами, цей підхід дозволяє 
наочно відобразити складні взаємодії між web-частиною та desktop-додатком 
(рисунок 2.1, рисунок 2.2).  
UML виступає фундаментальним інструментом візуалізації, що дозволяє за 
допомогою діаграм описати шаблони об'єктів (класи) та функціональні сценарії 
(прецеденти). Поєднання цих символів дає змогу спроєктувати як статичну будову 
бази даних, так і динаміку поведінки системи. Такий підхід забезпечує створення 
детального плану, необхідного для якісної реалізації та подальшого тестування 
програмного продукту при розробці платформи. 
 
 
Рисунок 2.1 – Основні графічні символи UML [4] 
19 
ЧДТУ 262242.004 ПЗ 
Використання мови UML дозволяє створити чітку та зрозумілу модель 
системи, що суттєво полегшує процеси розробки, тестування та подальшої 
модернізації платформи. Завдяки візуалізації архітектурних рішень забезпечується 
прозорість взаємодії між модулями, що є критично важливим для стабільної роботи 
механізмів автоматизованого моніторингу та коректної обробки масивів даних про 
активність користувача.  
2.1.3. Робоча область моделювання 
Робоча область моделювання інформаційної системи визначає межі 
середовища, у якому відбувається взаємодія між користувачем, клієнтськими 
застосунками та серверною частиною. У межах даного проєкту робоча область 
охоплює дворівневу структуру, де перший рівень включає клієнтську взаємодію 
через web-інтерфейс для візуалізації аналітики та desktop-додаток для 
низькорівневого збору активності. Другий рівень відповідає за обробку та 
синхронізацію даних на стороні сервера, що забезпечує стабільність інформаційних 
потоків та надійне збереження даних моніторингу. 
 
 
Рисунок 2.3 – Модель предметної області 
 
Основні компоненти робочої області: 
20 
ЧДТУ 262242.004 ПЗ 
1 Керівник (Admin) – користувач, що здійснює стратегічне управління 
проєктами та контроль за діяльністю команди; 
2 Розробник (Member) – користувач, який виконує та створює завдання і 
ініціює робочі сесії; 
3 Проєкт (Project) – елемент системи, призначений для групування завдань 
за певними критеріями(назва, команда, виконавець і тд). 
4 Завдання (Task) – об’єкт, є елементом проєкту, що належить або надається 
користувачу керівником команди; 
5 Клієнт (Client) – програмний інтерфейс, що забезпечує взаємодію 
користувача з платформою та автоматизує збір даних; 
6 Сервер (Server) – елемент, що відповідає за авторизацію, обробку вхідних 
даних та структуроване зберігання в базі даних; 
7 Робоча сесія (Session) – інтервал безперервної роботи над завданням, що 
є основою для формування звітів; 
8 Активність (Activity) – показник інтенсивності роботи користувача, що 
вираховується на основі взаємодії з ПК; 
9 Скріншот (Screenshot) – графічний елемент, що автоматично створюється 
під час сесії для верифікації робочого процесу. 
2.2. Формування та аналіз вимог 
Задача формування та аналізу вимог є ключовим етапом проєктування  і 
полягає у розумінні того, чим повинна бути система, які завдання вона вирішує, та 
її подальшому документуванні. Основною метою є знаходження, обґрунтування і 
опис функціональних та особливостей використання системи у вигляді, яка є 
зрозумілою як замовнику, так і команді розробників. 
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги  
Формування вимог до програмного забезпечення. Для побудови якісної 
системи автоматизованого обліку часу необхідно сформувати первинні вимоги, що 
дозволить деталізувати технічні аспекти реалізації. Платформа призначена для 
21 
ЧДТУ 262242.004 ПЗ 
відстеження проєктної діяльності програміста під час роботи за комп'ютером. Після 
того яко користувач зайшов на web-платформу або інсталяції клієнтського додатка, 
авторизації, та після запуску таймера система отримує доступ до подій вводу 
(миша/клавіатура) та робочого столу. Система забезпечує вибір завдання, запуск 
таймера, автоматичний збір метрик активності та створення скріншотів у випадкові 
моменти часу. 
Вимоги замовника (первинні вимоги) 
Розглянемо більш детальніше вимоги замовника: 
− забезпечення об'єктивного контролю робочого часу учасників команди 
без необхідності постійної ручної звітності; 
− автоматична класифікація рівня продуктивності користувачів; 
− надання керівнику візуальних доказів виконання роботи у вигляді 
скріншотів через web-інтерфейс. Скріншоти повинні створюватись кожні 15 хвилин 
активності користувача; 
− сучасний та зрозумілий розробнику інтерфейс desktop-додатка та web-
платформи; 
− мінімальна кількість дій для розробника, щоб ініціаціювати та створити 
запис робочого часу. 
Вимоги розробника (детальні вимоги) 
Розглянемо більш детальніше вимоги розробника: 
− реалізація безпечної авторизації користувачів за допомогою JWT-токенів; 
− створення інструмента для вибору та створення проєкту та керування 
станом таймера сесії; 
− автоматична перевірка прав доступу до системних ресурсів (екран, події 
вводу) перед початком збору даних; 
− забезпечення механізму локального накопичення даних 
(Localstorage/SQLite) при відсутності зв'язку з сервером; 
− автоматична синхронізація локальних звітів та скріншотів із сервером при 
відновленні інтернет-з'єднання; 
22 
ЧДТУ 262242.004 ПЗ 
− формування аналітичних звітів для керівника на основі обробки 
зафіксованого часового інтервалу; 
− можливість подальшого розширення функціоналу системи. 
Функціональні вимоги 
Розглянемо більш детальніше функціональні вимоги: 
1 Інтерфейс користувача – інтерфейс має бути мінімалістичним. На 
головному екрані повинно відображено назву обраного завдання та таймер. Після 
натискання кнопки «Start» вона змінює стан на «Stop», а таймер починає відлік; 
2 Модуль збору даних – система повинна кожну хвилину підраховувати 
кількість кліків та натискань клавіш. На основі цих даних кожні 10 хвилин 
вираховується середній відсоток активності; 
3 Модуль скріншотів – додаток має захоплювати зображення екрана. Файли 
повинні стискатися (JPEG) перед відправкою для економії трафіку; 
4 Екран результатів (Dashboard) – має відображати прогрес протягом 
робочого дня, де кожен 15-хвилинний відрізок відображений кольором залежно від 
активності (зелений, жовтий, червоний); 
5 Інтерактивний таймер – додаток повинен містити таймер у 
інтерактивному вікні. Користувач повинен мати можливість переміщати, закрити, 
згорнути та повинен містити кнопки «Start», яка мусить після натискання 
змінюватись на «Stop» 
Нефункціональні вимоги 
Розглянемо більш детальніше нефункціональні вимоги: 
1 Швидкодія – обробка даних сесії на сервері та оновлення графіків не 
повинно тривати більше 1 секунд;  
2 Безпека – скріншоти та персональні дані не повинні бути доступні 
стороннім особам; передача здійснюється виключно через SSL/TLS; 
3 Сумісність – desktop-додаток має бути сумісним з Windows 11, web-
інтерфейс – з сучасними браузерами (Chrome, Firefox, Microsoft Edge); 
4 Конфіденційність – система не повинна зчитувати безпосередньо текст, 
що вводиться (keylogging), лише факт натискання клавіш. 
23 
ЧДТУ 262242.004 ПЗ 
Розділення вимог дозволяє чітко забезпечити реальні потреби користувачів і 
закласти правильну основу для подальшого проєктування архітектури платформи 
для відстеження проєктної діяльності. 
2.2.2. Формування вимог за допомогою діаграм прецедентів 
Для візуалізації функціональних вимог та визначення взаємодії між акторами 
(користувачами) і системою використовується діаграма прецедентів (Use Case 
Diagram) [17][18]. Вона дозволяє описати сервіси, які система надає користувачеві, 
не вдаючись у деталі програмної реалізації. 
Основними акторами у системі виступають (рисунок 2.4): 
– розробник (Користувач) – базовий актор, який використовує клієнтський 
додаток для фіксації робочого часу та перегляду особистої статистики; 
– керівник (Менеджер) – спеціалізація користувача з розширеними правами, 
що дозволяють керувати проєктами та переглядати активність команди; 
– сервер – технічний актор, що забезпечує зберігання даних активності та 
скріншотів. 
Основні прецеденти (Use Cases): 
− управління обліковим записом – включає прецеденти «Зареєструватися», 
«Увійти в систему», «Налаштувати профіль»; 
− управління робочою сесією – основний прецедент, що ініціюється 
Розробником. Включає ($<<include>>$) прецеденти «Вибрати проєкт», «Вибрати 
завдання», «Запустити таймер»; 
− фіксація активності – прецедент, що виконується системою автоматично 
під час активної сесії. Розширюється ($<<extend>>$) прецедентами «Зробити 
скріншот» та «Вирахувати рівень активності»; 
− перегляд аналітики – прецедент для розробника (бачить свою статистику) 
та Керівника (бачить звіти по всій команді); 
− керування проєктами – прецедент, доступний лише керівнику, що включає 
створення нових проєктів та призначення завдань розробникам; 
− перегляд скріншотів – прецедент, доступний розробнику для перегляду 
своєї активності і керівнику для верифікації робочого процесу підлеглих. 
24 
ЧДТУ 262242.004 ПЗ 
Діаграма прецедентів чітко розмежовує функціональні можливості для 
кожної ролі та слугує відправною точкою для проєктування поведінки системи. 
Також використання моделі прецедентів є фундаментом для створення діаграм 
послідовності (Sequence Diagrams) та діаграм класів (Class Diagrams), що 
забезпечує цілісність та логічну послідовність усього процесу розробки платформи. 
 
 
Рисунок 2.4 – UML  діаграма прецедентів(Use Case Diagram) 
25 
ЧДТУ 262242.004 ПЗ 
2.3. Проектування логічної структури програмного комплексу 
У цьому підрозділі буде детально розглянуто проєктування логічної 
структури системи. На відміну від аналізу вимог, який визначає зовнішню 
поведінку, проєктування логічної структури зосереджено на внутрішній логікі 
системи – її модульності, типізації даних та механізмах взаємодії компонентів. 
Такий архітектурний підхід не лише спрощує поточну розробку, а й закладає 
фундамент для майбутнього масштабування системи, наприклад, інтеграції з 
зовнішніми додатками або додавання нових видів звітності. 
2.3.1. Діаграма класів 
  Для візуалізації статичної структури коду розроблено діаграму класів, яка 
відображає ієрархію об’єктів, їх атрибути, методи і відносини між даними [19][20]. 
Окрім цього було проведено декомпозицію системи на логічні пакети(Packages), що 
дозволяє відділити інтерфейс користувача від бізнес-логіки та взаємодії з базою 
даних (рисунок 2.5). 
 
 
Рисунок 2.5 – Діаграма класів  без  атрибyтів 
26 
ЧДТУ 262242.004 ПЗ 
Розглянемо більш детальніше логіку створення діаграми класів яка показана 
на рисунку 2.6. Отже починаємо розгляд опису основних класів.   
Опис основних класів: 
1 Клас User (Користувач) 
Eлемент системи, що представляє зареєстрованого користувача. Він містить 
персональні дані, необхідні для автентифікації, управління профілем та зв’язку з 
іншими об’єктами системи (проєктами, завданнями, скріншотами). 
Поля: 
‒ id: Number – унікальний ідентифікатор користувача; 
‒ username: String – ім’я користувача для відображення; 
‒ email: String – адреса електронної пошти; 
‒ avatar_url: String – посилання на завантажене фото профілю; 
‒ status: String – поточний мережевий статус ("online"/"offline"). 
2 Клас Team (Команда) 
Клас, призначений для організації групової роботи. Дозволяє об’єднувати 
користувачів у спільний робочий простір для спільного ведення проєктів. 
Поля: 
− id: Number – ідентифікатор команди; 
− name: String – назва команди; 
− invite_code: String – унікальний код для приєднання нових учасників; 
− owner_id: Number – ідентифікатор власника команди. 
3 Клас Project (проєкт) 
Представляє основну одиницю організації роботи. Може належати окремому 
користувачу або назначеному учаснику команди, є контейнером для завдань. 
Поля: 
‒ id: Number – ідентифікатор проєкту; 
‒ name: String – назва проєкту; 
‒ color: String – колірний маркер для візуалізації в інтерфейсі; 
‒ is_team: Boolean – прапорець, що визначає тип проєкту (особистий чи 
командний); 
27 
ЧДТУ 262242.004 ПЗ 
‒ team_id: Number – ідентифікатор команди (якщо проєкт командний). 
4 Клас Task (Завдання) 
Робоча одиниця в межах проєкту. Використовується для призначення 
відповідальних осіб та відстеження витраченого часу. 
Поля: 
‒ id: Number – ідентифікатор завдання; 
‒ name: String – назва завдання; 
‒ type: String – категорія завдання; 
‒ description: String – текстовий опис робіт; 
‒ total_seconds: Number – весь час, витрачений на завдання; 
‒ assigned_to: Number – ID користувача, якому призначено завдання. 
5 Клас TimeEntry (Часовий запис) 
Записує окрему сесію роботи користувача над завданням. Є базовим 
елементом для розрахунку загальної продуктивності та побудови звітів. 
Поля: 
– id: Number – ідентифікатор запису; 
– start_time: DateTime – час початку сесії; 
– end_time: DateTime – час закінчення сесії; 
– duration_seconds: Number – тривалість сесії в секундах. 
6 Клас Screenshot (Скріншот) 
Використовується для зберігання даних про автоматично зняті зображення 
екрана під час робочого процесу для контролю активності. 
Поля: 
‒ id: Number – ідентифікатор знімка; 
‒ file_path: String – шлях до файлу зображення на сервері; 
‒ activity_score: Int – рівень активності користувача в момент знімка (0-100); 
‒ app_name: String – назва активного додатку; 
‒ window_title: String – заголовок вікна програми. 
28 
ЧДТУ 262242.004 ПЗ 
 
Рисунок 2.6 – Діаграма класів 
29 
ЧДТУ 262242.004 ПЗ 
2.3.2. Діаграма пакетів 
Діаграма пакетів показує логічну організацію класів у модулі, що дозволяє 
структурувати архітектуру платформи для відстеження проєктної діяльності 
програміста та чітко розподілити зони відповідальності між частинами системи 
(Рисунок 2.7) [21][22]. 
 
 
Рисунок 2.7 – Діаграма пакетів 
 
Опис основних пакетів: 
1 Presentation Layer (Frontend) – відповідає за клієнтську частину додатка, 
включаючи React-компоненти інтерфейсу, логіку управління станом та сервіси для 
взаємодії з API; 
2 Application Layer (Controllers) – реалізує серверну логіку обробки запитів, 
де зосереджені контролери для управління проєктами, завданнями, командами та 
автентифікацією користувачів; 
3 Infrastructure Layer (Middleware) – забезпечує допоміжні сервіси системи, 
такі як перевірка JWT-токенів, обробка WebSocket-з’єднань та збереження 
завантажених скріншотів на сервері; 
30 
ЧДТУ 262242.004 ПЗ 
4 Persistence Layer (Data Access) – відповідає за низькорівневу взаємодію з 
базою даних PostgreSQL, включаючи виконання SQL-запитів та управління пулом 
з’єднань. 
2.4. Архітектурне проектування 
У цьому підрозділі розглядається архітектурне проєктування платформи. 
Метою є показати, як система розділена на окремі автономні компоненти та як вони 
взаємодіють між собою для забезпечення відстеження активності та аналізу 
продуктивності. Для цього була побудована діаграма компонентів, яка відображає 
логічний розподіл функціональності між web-інтерфейсом, desktop-додатком та 
серверною частиною [23][24]. 
2.4.1. Діаграма компонентів 
Основні компоненти (Рисунок 2.8): 
 
 
Рисунок 2.8 – Діаграма компонентів 
31 
ЧДТУ 262242.004 ПЗ 
1 Web-застосунок (Web Client / React) – компонент взаємодії з користувачем, 
реалізований як SPA (Single Page Application). Він забезпечує візуалізацію зібраних 
даних, управління структурою проєктів та командну взаємодію.  
Підкомпоненти: 
– UI Engine (React компоненти); 
– DashboardView (Analytics, Weekly Productivity); 
– ProjectManager (склад проєктів та завдань); 
– TeamModule (управління учасниками). 
2 Desktop елемент – спеціалізований компонент для збору первинної 
інформації про активність користувача, який працює на рівні операційної системи 
для обходу обмежень браузера.  
Підкомпоненти: 
– ActivityTracker (фіксація натискань клавіш та рухів миші); 
– ScreenshotModule (автоматичне створення та стиснення знімків екрана); 
– ProcessMonitor (визначення активних вікон та назв програм). 
3 Cерверна частина (Backend API / Node.js) – вузол обробки даних, що 
реалізує RESTful API для всіх клієнтів. Він відповідає за бізнес-логіку, безпеку та 
координацію потоків даних між базою даних та інтерфейсами. 
Підкомпоненти: 
– AuthService (JWT автентифікація та сесії); 
– ProjectController (CRUD операції над проєктами та задачами); 
– TimeManager (логіка розрахунку тривалості та лімітів); 
– SocketServer (оновлення статусів користувачів у реальному часі). 
4  Система збереження даних (Data & Storage) – компонент, що відповідає за 
цілісність інформації.  
Підкомпоненти: 
– PostgreSQL Pool (збереження метаданих та часових записів); 
– FileStorage (збереження файлів скріншотів та аватарів користувачів). 
Зв’язки між компонентами: 
32 
ЧДТУ 262242.004 ПЗ 
− web-застосунок та desktop-додаток взаємодіють із сервером через 
HTTP/HTTPS запити за протоколом REST; 
− desktop-додаток надсилає дані (скріншоти) через спеціалізований 
Middleware (Multer) для збереження у FileStorage; 
− серверна частина виконує SQL-запити до PostgreSQL для агрегації 
аналітики (getAnalyticsStats) на запит web-застосунку; 
− Socket.io забезпечує миттєву синхронізацію статусів між web-
платформою та desktop-додатком. 
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання. 
Розгортання програмної системи передбачає стратегічне розміщення 
компонентів платформи на відповідних фізичних або віртуальних пристроях для 
забезпечення стабільної роботи [25][26]. Для системи архітектура розгортання 
включає взаємодію клієнта, сервера обробки даних та бази даних. 
Діаграма розгортання зображена на рисунку 2.9. 
 
 
Рисунок 2.9 – Діаграма розгортання web-додатку 
 
Клієнтський пристрій: 
− компоненти: Web Browser (React UI), Desktop; 
− опис: клієнтська частина розгортається безпосередньо на робочих 
станціях користувачів. Web-інтерфейс доступний через сучасні браузери, тоді як 
33 
ЧДТУ 262242.004 ПЗ 
desktop-додаток працює як фоновий процес для моніторингу активності та 
створення скріншотів; 
− апаратні вимоги: персональний комп’ютер з ОС Windows, стабільне 
підключення до мережі Інтернет. 
Сервер платформи: 
− компоненти: Node.js, Socket.io, Multer Storage; 
− опис: сервер обробляє запити від обох типів клієнтських додатків, 
забезпечуючи автентифікацію, управління проєктами та збереження медіафайлів 
(скріншотів). Для зв’язку в реальному часі використовується протокол WebSocket. 
− апаратні вимоги: виділена серверна машина з достатніми 
обчислювальними ресурсами для обробки множинних з’єднань та файлових 
потоків. 
База даних: 
− компоненти: PostgreSQL Database Service. 
− опис: зберігає структуровані дані про користувачів, команди, часові записи 
та метадані активності. Використовується реляційна модель для забезпечення 
цілісності зв’язків між сутностями. 
− апаратні вимоги: серверна машина із достатнім обсягом пам’яті для 
швидкого доступу до часових записів та логів. 
2.5. Моделювання поведінки системи 
2.5.1. Діаграма діяльності. 
Діаграма діяльності візуалізує динаміку роботи системи: від моменту запуску 
таймера користувачем до формування звітності на сервері(рисунок 2.10)[27][28]. 
1 Авторизація та вибір задачі – користувач запускає один із додатків. 
Система перевіряє активні сесії. Після вибору проєкту та конкретної задачі стає 
доступною кнопка запуску таймера. 
2 Цикл відстеження – після старту система паралельно запускає три 
процеси: інкрементальний підрахунок часу, рандомний запуск модуля скріншотів і 
збір даних про активність. 
34 
ЧДТУ 262242.004 ПЗ 
3 Аналіз активності (Idle Detection) – система постійно відслідковує 
системні переривання (миша/клавіатура). Якщо активність відсутня понад 
встановлений ліміт(15 хв), таймер автоматично ставиться на паузу, а сесія 
позначається як «Idle». 
4 Синхронізація даних – дані про відпрацьовані секунди та зашифровані 
зображення екрана передаються на сервер через REST API. 
 
Рисунок 2.10 – Діаграма діяльності 
35 
ЧДТУ 262242.004 ПЗ 
5 Формування звітності – на основі отриманих даних сервер розраховує 
Activity Score (відсоток активності) та оновлює графіки на сторінці звітів. 
2.5.2. Діаграма послідовності 
Діаграма послідовності детально відображає взаємодію між front-end на 
React, back-end на Node.js та базою даних (Рисунок 2.11) [29][30]. 
 
 
Рисунок 2.11 – Діаграма послідовності 
 
Основні етапи взаємодії: 
1 Запуск таймера – користувач вибирає конкретне завдання (Task) зі списку 
в інтерфейсі та натискає кнопку запуску. 
2 Ініціалізація сесії – компонент timerContext переводить систему в 
активний стан (isActive = true), запускає внутрішній лічильник секунд та ініціює 
useActivityTracker для відстеження дій миші та клавіатури. 
3 Оновлення статусу користувача – клієнт надсилає сигнал на сервер через 
Socket.io, щоб повідомити команду про зміну статусу користувача на "Online". 
4 Автоматичне створення скріншотів – система через заданий інтервал часу 
ініціює запит до Capture Service. Сервіс робить знімок екрана та збирає дані про 
активне вікно програми, у якій працює користувач. 
5 Перевірка авторизації – перед кожним відправленням даних на сервер 
перевіряє JWT-токен та валідність поточної сесії в таблиці user_sessions. 
36 
ЧДТУ 262242.004 ПЗ 
6 Збереження даних – web-сайт відправляє скріншот та відсоток активності 
на API-сервер (POST /api/screenshots/upload). Сервер зберігає файл у файловій 
системі, а шлях у базі даних PostgreSQL. 
7 Зупинка таймера – користувач завершує роботу над завданням, 
натискаючи кнопку паузи. Клієнт зупиняє локальний відлік і формує фінальний 
пакет даних про тривалість сесії. 
8 Фіксація часового запису в базі даних – web-сайт надсилає запит на 
збереження (POST /api/timer/save). Сервер оновлює загальний час виконання 
завдання в таблиці tasks та створює новий запис у таблиці time_entries для 
створення звітів. 
9 Оновлення інтерфейсу користувача – після підтвердження від сервера, 
дані в таблиці SessionsTable автоматично оновлюються, відображаючи останню 
завершену сесію користувача. 
2.5.3. Діаграма коммунікацій  
Діаграма, яка фокусується на структурній організації об'єктів, що 
обмінюються повідомленнями (Рисунок 2.12) [31]. 
 
 
Рисунок 2.12 – Діаграма комунікацій 
 
− користувач – починає взаємодію через графічний інтерфейс (gui), 
ініціюючи процеси входу або запуску таймера. 
37 
ЧДТУ 262242.004 ПЗ 
− timerСontext – виступає центральним вузлом управління. Він координує 
роботу всіх інших модулів. 
− модуль Electron API – використовується для низькорівневої взаємодії з 
операційною системою (керування вікнами, доступ до системного часу). 
− модуль activityTracker – відповідає за логіку перевірки 15-хвилинного 
інтервалу бездіяльності. Ініціює ланцюжок повідомлень про бездіяльність. 
− модуль Axios (HTTP) – забезпечує серіалізацію даних у формат json та їх 
відправку на сервер (збереження часу, скріншотів). 
− модуль Socket.io – підтримує постійне з'єднання з сервером для миттєвої 
передачі сповіщень керівнику, якщо активність дорівнює нулю. 
− модуль Notifications – відповідає за виведення модальних вікон та 
системних сповіщень для користувача. 
− cервер – отримує запити та підтверджує збереження даних у базу даних. 
2.5.4. Діаграма скінченного автомата 
Діаграма станів моделює динамічну поведінку об'єкта «Таймер», який є 
керованим вузлом системи. Діаграма показує, як додаток переходить між різними 
режимами роботи у відповідь на дії користувача та автоматичні системні події 
(Рисунок 2.13) [32]. 
 
 
Рисунок 2.13 – Діаграма скінченного автомата 
38 
ЧДТУ 262242.004 ПЗ 
Опис основних станів та внутрішніх дій: 
Очікування (Idle): 
Стан, у якому об'єкт перебуває після запуску додатка. 
− entry(відобразити список завдань): при переході у цей стан система 
автоматично оновлює перелік доступних задач із бази даних. 
− do(чекати вибору завдання): внутрішня діяльність, що полягає у 
моніторингу вибору користувача. 
Відслідковування (Running):  
Стан, що відповідає за основний функціонал системи. 
− entry(ініціалізувати лічильник): скидання та підготовка таймера до 
роботи. 
− do(інтервальне створення скріншотів): тривала діяльність, яка виконує 
захоплення екрана та фіксацію активності кожні 15 хвилин. 
− exit(зупинити CaptureService): дія виходу, що гарантує припинення 
використання системних ресурсів (пам'яті та процесора) при зміні стану. 
Пауза (Paused): 
Тимчасовий стан призупинення обліку часу. 
− entry(призупинити лічильник): фіксація поточного значення часу. 
− do(збереження локальної чернетки): система утримує дані сесії в 
оперативній пам'яті для миттєвого відновлення без звернення до сервера. 
Бездіяльність (IdleAlert): 
Спеціалізований стан, що активується автоматично.  
− entry(відправити сигнал idle через socket): миттєве сповіщення сервера та 
керівника про відсутність активності. 
− do(відобразити попередження): візуальна сповіщення для користувача 
про перехід у режим простою. 
Зміна станів відбувається на основі подій, ініційованих користувачем 
(натискання кнопок інтерфейсу), або за умовами системи. Перехід із стану 
відслідковування до бездіяльності відбувається автоматично за умови бездіяльності 
15 хв. Повернення у робочий стан здійснюється за подією активності (будь-який 
39 
ЧДТУ 262242.004 ПЗ 
ввід з миші чи клавіатури). Завершення процесу відслідковування супроводжується 
важливою дією синхронізації з БД, що забезпечує запис накопиченого часу та 
метаданих на сервер через API.  
40 
ЧДТУ 262242.004 ПЗ 
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ 
У другому розділі було проведено комплексне проєктування архітектури та 
функціональної моделі web-платформи для відстеження проєктної діяльності 
програміста. На основі проведеного аналізу предметної області було визначено 
основні сутності системи та розроблено словник термінів, що дозволило 
сформувати єдине інформаційне середовище для взаємодії керівників та 
розробників. У процесі формування вимог до програмного забезпечення було 
систематизовано функціональні та нефункціональні вимоги, також вимоги щодо 
автоматизації збору даних активності, безпеки передачі даних та кросплатформеної 
сумісності платформ. 
При розробці логічної структури за допомогою діаграм пакетів та класів 
обґрунтовано використання багатошарової архітектури, що забезпечує чіткий 
розподіл зон відповідальності між компонентами на базі React, Node.js та 
PostgreSQL. Побудовані діаграми розгортання та компонентів дозволили 
спроєктувати взаємодію елементів системи через REST API та протокол WebSocket 
для синхронізації даних у реальному часі. 
Також приділена моделюванню динамічної поведінки системи. За допомогою 
діаграм діяльності, послідовності та станів було детально описано життєвий цикл 
робочої сесії, включаючи ініціалізацію таймера, автоматичну фіксацію екрана та 
механізми переходу в стан бездіяльності. Запропоновані рішення створюють 
необхідну основу для подальшої реалізації інформаційної платформи для 
відстеження проєктної діяльності. 
  
41 
ЧДТУ 262242.004 ПЗ 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
3.1  Розробка программного комплексу 
Процес розробки платформи є ключовим етапом роботи, що охоплює заходи 
зі створення цілісної системи для моніторингу проєктної діяльності. Основною 
метою на цьому етапі була реалізація ключових модулів, побудова масштабованої 
архітектури, налаштування стабільного зв’язку між клієнтськими додатками та 
сервером, а також розробка мінімально життєздатного продукту (MVP) платформи. 
У процесі розробки особлива увага приділялася модульності архітектури. Це 
дозволило забезпечити незалежну роботу web-панелі аналітики та desktop-додатку. 
Було реалізовано механізм фонового збору даних активності: desktop-додаток 
фіксує події вводу та стан робочого столу, передаючи ці дані на сервер у реальному 
часі. Ці дані накопичуються в базі даних PostgreSQL, що дозволяє формувати 
детальні звіти про продуктивність, розраховувати показник активності розробника 
та візуалізувати часові інтервали роботи для керівників і розробників. 
Розробка велася з дотриманням сучасних практик інженерії програмного 
забезпечення: 
– чітке розділення відповідальності між клієнтською частиною на React, 
desktop оболонкою Electron та серверною логікою на Node.js; 
– оптимізація продуктивності, що забезпечує мінімальний desktop-додатку 
на ресурси комп’ютера користувача під час виконання фонових задач (скріншотів 
та підрахунку кліків); 
– забезпечення безпеки даних шляхом впровадження авторизації на основі 
JWT-токенів та використання захищених протоколів передачі медіафайлів; 
– модульність інтерфейсу, реалізована за допомогою компонентного 
підходу React, що дозволяє легко додавати нові аналітичні віджети або змінювати 
логіку таймера без переробки всієї системи; 
– використання Document Picture-in-Picture API для забезпечення 
безперервного доступу до таймера у відокремленому вікні, що підвищує зручність 
використання платформи. 
42 
ЧДТУ 262242.004 ПЗ 
В основі реалізації використовувався об’єктно-орієнтований підхід та сучасні 
архітектурні патерни, що забезпечило масштабовану структуру коду та спростило 
процес тестування окремих модулів. Сучасний стек технологій (TypeScript, 
Socket.io) дозволив створити чисту та підтримувану кодову базу. 
В результаті цього етапу було розроблено повнофункціональну 
кросплатформену систему, яка успішно реалізує всі задачі автоматизованого 
відстеження часу та готова до подальшого впровадження в робочі процеси ІТ-
команд. 
3.1.1. Обгрунтування вибору засобів реалізації 
Вибір програмних засобів для реалізації проєкту здійснювався з урахуванням 
вимог до кросплатформеності, синхронізації даних у реальному часі та 
необхідності глибокої інтеграції з операційною системою для збору даних 
активності. 
Основою для розробки клієнтської частини обрано бібліотеку React. 
Використання підходу Single Page Application (SPA) дозволяє створити динамічний 
інтерфейс із високою швидкістю відгуку, що є критично важливим для аналітичних 
панелей. Для забезпечення навігації всередині додатка без перезавантаження 
сторінок використано бібліотеку React Router, яка дозволяє реалізувати чітку 
структуру маршрутизації між головною сторінкою, аналітичними звітами, 
сторінкою команди та сторінками налаштувань. Для desktop-додатка використано 
технологію Electron, що дозволяє обгорнути web-додаток у web-оболонку, надаючи 
доступ до операційної системи для створення скріншотів та відстеження подій 
вводу, що технічно неможливо реалізувати засобами стандартного браузера без 
підтвердження дозволу користувача. 
Головною мовою програмування обрано TypeScript. На відміну від 
класичного JavaScript, він забезпечує сувору типізацію даних, що дозволяє 
виявляти помилки на етапі розробки та полегшує підтримку складних інтерфейсів 
взаємодії між web-платформою та desktop-додатком. 
Для стилізації компонентів обрано технологію CSS Modules. Це рішення 
забезпечує локальну область видимості стилів, запобігаючи конфліктам іменування 
43 
ЧДТУ 262242.004 ПЗ 
класів у великих проєктах та полегшуючи підтримку коду. Візуальна частина 
доповнена бібліотекою Lucide React, що надає набір сучасних мінімалістичних 
іконок, які відповідають обраній концепції дизайну (зокрема, для ідентифікації 
статусів та елементів управління таймером). 
Серверна частина реалізована на базі середовища Node.js із використанням 
фреймворку Express. Такий вибір зумовлений асинхронною моделлю обробки 
запитів, що є оптимальним для систем із великою кількістю дрібних операцій 
запису (логівання часу, передача координат активності). Для збереження 
структурованих даних обрано реляційну СУБД PostgreSQL, яка забезпечує високу 
цілісність даних та дозволяє виконувати складні агрегуючі запити для формування 
аналітичної звітності. Важливою архітектурною перевагою обраного стеку є 
технологічна однорідність системи, оскільки desktop-додаток на базі Electron 
безпосередньо використовує середовище Node.js для взаємодії з операційною 
системою. Це стало вирішальним фактором при виборі Node.js як основної 
платформи для реалізації серверної частини, що дозволяє використовувати єдину 
мову програмування та спільні модулі обробки даних на всіх рівнях архітектури. 
Такий підхід значно спрощує розробку, дозволяючи перевикористовувати логіку 
типізації TypeScript між клієнтськими додатками та REST API, а також забезпечує 
високу швидкість обміну даними через вбудовані механізми серіалізації. 
Використання Node.js у зв'язці з фреймворком Express гарантує високу 
продуктивність завдяки неблокуючій моделі вводу-виводу, що є критичним для 
обробки інтенсивних потоків даних активності, які надходять від desktop-модуля. 
Реалізовано інтерактивний таймер за допомогою технології Document Picture-
in-Picture API. На відміну від стандартного Video PiP, даний інтерфейс дозволяє 
відкривати окреме вікно з довільним HTML-наповненням, що залишається поверх 
усіх інших вікон операційної системи. Вибір цієї технології був необхідний 
потребою забезпечити користувачу безперервний доступ до керування часовою 
сесією без необхідності перемикання між вкладками браузера або розгортання 
основного вікна платформи. Це дозволяє досягти рівня зручності нативних desktop 
застосунків, зберігаючи при цьому архітектурну легкість web-рішення. 
44 
ЧДТУ 262242.004 ПЗ 
Для забезпечення двостороннього зв'язку в реальному часі інтегровано 
бібліотеку Socket.io. Це дозволяє миттєво синхронізувати статус учасників команди 
("Online", "Idle", "Active") між desktop-клієнтом та web-платформою керівника без 
необхідності постійного оновлення сторінки. 
Як основне середовище розробки (IDE) використовувався Visual Studio Code, 
який є легким та потужним середовищем завдяки інтегрованому широкому набору 
розширень середовище розробки дозволяє налаштувати середовище під 
індивідуальні потреби та налаштувати середовище на роботу з багатьма 
технологіями.  
Платформа орієнтована на роботу в сучасних браузерах (Chrome, Firefox, 
Edge) та операційних системах Windows (10/11). 
Альтернативи та їх недоліки: 
Python (Django/Flask) – Python зручний для аналітики, але він поступається 
Node.js у швидкості обробки великої кількості запитів (скріншоти, логування) у 
реальному часі. 
C# (.NET/WPF) – забезпечує високу продуктивність на Windows, але значно 
ускладнює розробку кросплатформного web-інтерфейсу та вимагає окремої кодової 
бази для фронтенду. 
MongoDB – гнучка база даних, проте відсутність жорстких зв’язків між 
таблицями ускладнює побудову складної аналітичної звітності, де потрібна висока 
точність реляцій. 
3.1.2. Опис структурної (функціональної) схеми  
Функціональна схема системи показує, з яких основних блоків складається 
система і як вони взаємодіють між собою для забезпечення автоматизованого обліку 
робочого часу. 
Система побудована за гібридною архітектурою, що поєднує можливості 
віддаленого сервера та локального моніторингу, і складається з таких головних 
частин: 
1 Web-інтерфейс керування та аналітики: 
− забезпечує візуальну взаємодію користувача (менеджера або 
45 
ЧДТУ 262242.004 ПЗ 
розробника) із системою; 
− реалізовано за допомогою стеку React, TypeScript та CSS Modules; 
− містить панель керування проєктами, звіти про продуктивність, сторінку 
команди з відображенням статусів у реальному часі та налаштування профілю. 
2 Desktop компонент моніторингу 
− виступає як функціональне розширення платформи, побудоване на базі 
Electron; 
− відповідає за низькорівневий збір даних, які недоступні браузеру: зняття 
скріншотів робочого столу та аналіз активності периферійних пристроїв (миші та 
клавіатури); 
− забезпечує автоматичну фіксацію часу в автономному режимі з 
подальшою синхронізацією з сервером. 
3 Модуль інтерактивного таймера (PiP Module) 
− реалізований за допомогою Document Picture-in-Picture API; 
− дозволяє виносити таймер у плаваюче вікно, що залишається поверх усіх 
активних програм; 
− забезпечує швидке керування сесією (Start/Stop) без необхідності 
перемикання на головну вкладку браузера. 
4 Модуль аналізу активності: 
− здійснює розрахунок показника активності розробника на основі 
інтенсивності взаємодії з пристроями вводу; 
− визначає стани користувача («Active», «Idle») та автоматично 
призупиняє таймер у разі тривалої відсутності активності; 
− проводить стиснення знімків екрана (JPEG) перед відправкою для 
економії мережевого трафіку. 
5 Серверний модуль (Backend API) 
− базується на Node.js та фреймворку Express; 
− обробляє REST-запити від клієнтів, відповідає за автентифікацію (JWT) 
та валідацію даних; 
− забезпечує збереження часових інтервалів та метаданих у базі даних 
46 
ЧДТУ 262242.004 ПЗ 
PostgreSQL. 
6 Модуль синхронізації в реальному часі (Real-time Sync) 
− реалізований на базі Socket.io; 
− забезпечує миттєву передачу змін статусу розробника на web-панель 
адміністратора; 
− дозволяє підтримувати актуальність даних у всіх відкритих сесіях 
користувачів без перезавантаження сторінок. 
Загальна логіка роботи: 
Коли користувач запускає таймер у desktop-додатку або через PiP-вікно, 
система ініціює сесію запису. Desktop компонент починає фіксувати активність та 
робити знімки екрана, які через API передаються на сервер. Сервер обробляє ці дані 
та зберігає їх у БД. Одночасно через Socket.io статус користувача оновлюється на 
web-платформі сторінки команди, де керівник може бачити поточний прогрес у 
реальному часі. Після завершення роботи система формує аналітичний звіт (див. 
схему на рисунку 3.1). 
 
 
Рисунок 3.1 – Структурна (функціональна) схема 
47 
ЧДТУ 262242.004 ПЗ 
Така структура забезпечує чітке розділення обов’язків: 
– Web App – візуалізацією та аналітикою; 
– Desktop – займається розширеним системним моніторингом;  
– Node.js back-end – надійним збереженням та комунікацією між усіма 
частинами екосистеми. 
3.1.3. Опис логічної схеми системи 
Процес функціонування платформи побудований на основі циклічного збору 
даних активності, їх обробки на клієнтському рівні та синхронізації з віддаленим 
сервером. Логічна структура включає основні операції: автентифікацію, 
ініціалізацію сесії, вирахування показників активності, передачу даних та 
формування аналітичної звітності. Послідовність дій у системі організована 
наступним чином: 
1 Авторизація та ініціалізація – при запуску desktop-додатку або web-
платформи користувач проходить процес автентифікації. Система ініціалізує 
захищене з'єднання з сервером, перевіряє права доступу та встановлює активну 
Socket-сесію для обміну даними в реальному часі. 
2 Запуск сесії відстеження – користувач обирає проєкт та активує таймер. 
Система генерує унікальний ідентифікатор робочої сесії та за бажанням 
користувача ініціалізує PiP-модуль для відображення інтерактивного таймера 
поверх інших вікон. 
3 Збір даних активності – Electron у фоновому режимі починає циклічне 
опитування пристроїв вводу (миші та клавіатури). Одночасно спрацьовує алгоритм 
фіксації екрана з заданим інтервалом. Отримані дані тимчасово кешуються 
локально. 
4 Обробка та аналіз даних (Activity Score) – система аналізує отримані 
дані про події вводу за певний проміжок часу. Розраховується показник 
інтенсивності роботи розробника. У разі відсутності активності понад 
встановлений ліміт, система автоматично змінює статус користувача на «Idle» та 
призупиняє фіксацію часу. 
48 
ЧДТУ 262242.004 ПЗ 
5 Синхронізація з сервером – сформовані пакети даних (метадані часу, 
показники активності та стислі скріншоти) надсилаються до REST API. Сервер 
валідує JWT-токен, обробляє вхідну інформацію та вносить відповідні записи до 
бази даних PostgreSQL. 
6 Візуалізація та аналітика – web-платформа отримує оновлені дані через 
Socket-з'єднання або за запитом. Компонент аналітики на базі React обробляє часові 
інтервали, будує графіки продуктивності та відображає поточний статус команди 
для менеджера. 
7 Завершення сесії – при зупинці таймера система фіксує фінальний час, 
завершує поточний запис у базі даних, закриває PiP-вікно та очищує тимчасові 
буфери пам’яті, щоб уникнути витоку ресурсів desktop-додатку. 
 
 
Рисунок 3.2 – Схема логічної роботи системи 
49 
ЧДТУ 262242.004 ПЗ 
3.1.4. Розробка бази даних 
Для забезпечення надійного зберігання результатів відстеження, історії 
робочих сесій та метаданих користувачів, у системі реалізовано повноцінну 
реляційну базу даних. Система обліку часу потребує довготривалого зберігання 
(persistence) для подальшого формування аналітичної звітності та доступу до 
історичних даних. 
Для взаємодії серверної частини на Node.js із базою даних використано підхід 
ORM (Object-Relational Mapping). Це дозволяє оперувати даними як об'єктами мови 
TypeScript, автоматизуючи перетворення записів бази даних у структури додатка та 
забезпечуючи захист від SQL-ін’єкцій. У процесі розробки бази даних платформи 
було проведено три етапи моделювання: 
1 Концептуальна модель даних – аналіз предметної області час-трекінгу, 
визначення ключових сутностей (користувач, команда, робоче завдання) та їхніх 
взаємозв’язків. На цьому етапі було встановлено, що одна робоча сесія може 
містити безліч дискретних записів активності та скріншотів. 
2 Логічна модель даних – визначення структури таблиць та типів даних. 
Зокрема, для зберігання часових інтервалів використано типи TIMESTAMP, а для 
гнучкого опису логів активності – тип JSON, що дозволяє масштабувати систему 
без зміни схеми БД. 
3 Фізична модель даних – проєктування таблиць, індексів для 
пришвидшення пошуку за датами та зовнішніх ключів (Foreign Keys) для 
забезпечення посилальної цілісності. Наприклад, при видаленні проєкту система 
автоматично обробляє пов'язані з ним записи робочого часу. 
Тобто, база даних є важливим компонентом, який забезпечує не лише 
збереження прогресу, та є основним елементом для передачі даних до всіх модулів 
аналітики та візуалізації продуктивності. 
3.1.5. Розробка інтерфейсу користувача 
Інтерфейс користувача (UI) є важливою складовою додатку оскільки саме він 
забезпечує взаємодію між розробником або керівником та системою відстеження 
50 
ЧДТУ 262242.004 ПЗ 
проєктної діяльності. Інтерфейс розроблено за допомогою бібліотеки React.js з 
використанням TypeScript та стилізації через CSS Modules, що забезпечує високу 
швидкість відгуку, модульність компонентів та сучасний вигляд аналітичних 
панелей. 
Основні елементи інтерфейсу: 
− панель керування (Dashboard) – головний екран web-платформи, що 
містить віджети з поточною статистикою, графіками продуктивності, останні задачі 
та списком активних проєктів (рисунок 3.3). 
 
 
Рисунок 3.3 – Інтерфейс головної сторінки 
 
− сторінка «Проєкти» – це сторінка для створення проєктів та завдань, на 
цій сторінці керівник може передати завдання учаснику команди (рисунок 3.4). 
51 
ЧДТУ 262242.004 ПЗ 
 
Рисунок 3.4 – Інтерфейс сторінки «Проєкти» 
 
− сторінка «Команда» – це сторінка на якій у реальному часі 
відображаються статуси учасників команди (Online, Idle, Active), годин за тиждень 
учасників та загальний та середній час команди (рисунок 3.5). 
 
 
Рисунок 3.5 – Інтерфейс сторінки «Команда» 
52 
ЧДТУ 262242.004 ПЗ 
− компонент таймера (PiP Timer) – компактне вікно, реалізоване через 
Document PiP API, що містить кнопки керування сесією (Start/Stop), лічильник часу 
та назву поточного завдання (рисунок 3.6). 
 
 
Рисунок 3.6 – Інтерактивний таймер 
 
− сторінка «Скріншоти» – візуалізація часової шкали робочого дня, де 
різними кольорами позначено рівень активності та зафіксовані інтервали роботи та 
скріншоти (рисунок 3.7). 
 
 
Рисунок 3.7 – Інтерфейс сторінки «Скріншоти» 
53 
ЧДТУ 262242.004 ПЗ 
− сторінка «Звіти» – сторінка для перегляду детальної аналітики як для 
індивідуальних користувачів так і для керівників. Керівники можуть переглядати 
аналітику учасників команди за обраний час (рисунок 3.8). 
 
 
Рисунок 3.8 – Інтерфейс сторінки «Звіти» 
 
− сторінка «Налаштування» – розділ для керування персональними 
даними, сповіщень та   параметрами безпеки (рисунок 3.9, 3.10). 
 
 
Рисунок 3.9 – Інтерфейс сторінки «Налаштування» 
54 
ЧДТУ 262242.004 ПЗ 
 
Рисунок 3.10 – Інтерфейс сторінки «Налаштування» №2 
 
− Сторінка «Авторизація» – сторінка входу користувача в систему (рисунок 
3.11). 
 
 
Рисунок 3.11 – Інтерфейс сторінки «Авторизація» 
55 
ЧДТУ 262242.004 ПЗ 
− Бічна панель навігації – компонент інтерфейсу який забезпечує 
користувачу навігацію між сторінками (рисунок 3.12). 
 
 
Рисунок 3.12 – Компонент навігації «Sidebar» 
 
3.1.6. Опис розробки програмних компонентів 
Інтерфейс реалізовано у вигляді набору незалежних React-компонентів, що 
дозволяє легко масштабувати систему. В структурі проєкту виділено спеціалізовані 
модулі та класи: 
1 Компонент відстеження активності (useActivityTracker): 
Логіка відстеження активності розробника винесена у кастомний хук 
useActivityTracker. Компонент використовує глобальні слухачі подій (mousemove, 
keydown, click) для фіксації взаємодії користувача з операційною системою. 
− механізм роботи – для оптимізації продуктивності застосовано перевірку 
часового інтервалу (1 секунда) між діями, що дозволяє уникнути зайвих оновлень 
стану; 
− обробка даних – метод getandresetactivity дозволяє отримати накопичену 
кількість активних секунд для формування звіту та автоматично скидає лічильник 
для наступного циклу відстеження. 
56 
ЧДТУ 262242.004 ПЗ 
2 Компонент управління часовими сесіями (TimerContext): 
Одним із основних елементів архітектури клієнта є контекст TimerContext, 
який реалізує складний життєвий цикл робочої сесії: 
− cинхронізація сесії – використання MediaStream дозволяє системі 
отримувати доступ до візуального потоку робочого столу для подальшої фіксації 
прогресу; 
− автоматизація скріншотів – реалізовано алгоритм інтервальної фіксації 
екрана. Перший знімок виконується через 5 секунд після старту для підтвердження 
початку роботи, а наступні – автоматично кожні 15 хвилин; 
− обробка стану – перед кожним відправленням даних система розраховує 
відсоток активності, що дозволяє менеджеру оцінити реальну інтенсивність роботи 
розробника. 
3 Інтерактивний PiP-модуль (pipService): 
 Для забезпечення безперервного контролю над часом розроблено сервіс на 
базі Document Picture-in-Picture API. Він динамічно створює окреме вікно та 
забезпечує двосторонній зв'язок між вікном PiP та основним станом додатка, 
дозволяючи керувати таймером (Start/Stop) безпосередньо з плаваючого вікна. 
4 Компонент навігації та доступу (App Routing):  
Для організації переходів між сторінками без перезавантаження браузера 
використано бібліотеку react-router-dom: 
− механізм захисту маршрутів – реалізовано компонент-обгортку 
ProtectedRoute, який перевіряє наявність валідного токена перед наданням доступу 
до аналітичних сторінок; 
− динамічна маршрутизація – система підтримує вкладені маршрути для 
детального перегляду звітів по кожному окремому проєкту. 
5 Компонент управління проєктами та завданнями (project.controller.ts). 
Даний серверний модуль є ядром бізнес-логіки системи. Він реалізує 
наступні функції: 
− CRUD-операції – створення, редагування та видалення проєктів і завдань. 
− логіка приєднання учасників – генерація унікальних 6-значних кодів 
57 
ЧДТУ 262242.004 ПЗ 
доступу (generateInviteCode) та обробка запитів на приєднання до команд. 
− розрахунок часу – обчислення загальної тривалості робочих сесій для 
формування персональної та командної статистики. 
6 Компонент автентифікації та безпеки (auth.controller.ts, 
auth.middleware.ts).  
Цей компонент забезпечує захист даних користувачів та розмежування прав 
доступу в системі: 
− JWT-автентифікація – реалізація механізму входу та реєстрації з 
використанням токенів доступу. 
− управління сесіями – можливість перегляду активних пристроїв 
(getUserSessions) та віддаленого завершення сеансів (revokeSession). 
− валідація доступу – проміжне ПЗ (middleware) перевіряє валідність токена 
при кожному запиті до захищених API-ендпоінтів, забезпечуючи цілісність 
системи. 
3.2. Тестування програмного забезпечення 
Тестування є критично важливим етапом розробки системи, тому що  
гарантує точність обліку робочого часу розробників та надійність механізмів 
командної взаємодії. В межах роботи було реалізовано такі види тестування: 
модульне, ітеграційне, системне і приймальне. 
Етапи тестування розробленої системи включають: 
1 Визначення об’єкту тестування – серверна частина (Node.js), клієнтська 
частина (React). 
2 Визначення мети тестування – перевірка точності таймера, стабільності 
WebSocket-з'єднань та захищеності даних користувачів. 
3 Вибір технології тестування – Jest, React Testing Library, Postman (для 
API). 
4 Розробка програми тестування – створення тестових сценаріїв для 
трекінгу часу та генерації звітів. 
5 Проведення тестування – запуск автоматизованих тестів та ручна 
58 
ЧДТУ 262242.004 ПЗ 
верифікація інтерфейсу. 
6 Підведення висновків – аналіз логів, виправлення знайдених помилок у 
розрахунках 
3.2.1. Модульне тестування 
Модульне тестування системи – це процес перевірки кожного 
функціонального блоку окремо на предмет його коректності перед інтеграцією в 
загальну систему. Модульне тестування в проєкті було організовано як перший етап 
верифікації коду, що дозволяє перевірити алгоритми обробки часу та управління 
проєктами без запуску всіх компонентыв сервера. Оскільки проєкт базується на 
архітектурі Full-stack TypeScript, основна мета тестів полягала у підтвердженні 
ідентичності розрахунків як на стороні клієнта (React), так і на стороні сервера 
(Node.js). 
Для автоматизації цього процесу обрано середовище Jest. Вибір 
обґрунтований його високою швидкістю роботи.  
Протестовано наступні компоненти: 
Модуль автентифікації: 
− тестування входу – перевірка валідації email та пароля. 
− тестування захисту – перевірка Middleware на відхилення запитів без 
JWT-токена. 
Модуль управління проєктами: 
− тестування кодів запрошення – перевірка генерації унікальних 6-значних 
кодів. 
− тестування створення проєкту – перевірка коректності збереження назви 
та налаштувань. 
Система обліку часу (Timer): 
− тестування точності – перевірка інкременту секунд при активному стані; 
− тестування форматування – перевірка перетворення секунд у формат 
HH:MM:SS; 
− тестування активності – система підраховує кількість активних учасників 
команди та відображає рівень активності у відсотках. 
59 
ЧДТУ 262242.004 ПЗ 
 
Рисунок 3.13 – Результати модульного тестування 
 
Таблиця 3.1 
Проходження модульних тестів 
№ Функція Опис тесту Очікуваний Результат 
результат виконання 
1 generateInviteCode Перевірка довжини length = 6, Успішно 
та формату коду відсутність 
проєкту спецсимволів 
2 generateInviteCode Перевірка Відсутність Успішно 
унікальності при дублікатів (unique) 
масовій генерації 
3 formatSeconds Тестування Результат 01:01:01 Успішно 
конвертації секунд у для 3661 с 
формат HH:MM:SS 
4 calculateProgress Перевірка При 5 учасниках Успішно 
розрахунку відсотка команди прогрес 
активності команди становить 50%. 
 
60 
ЧДТУ 262242.004 ПЗ 
Продовження таблиці 3.1 
5 authMiddleware Перевірка HTTP- Статус помилки 401 Успішно 
запитів без JWT- (Unauthorized) 
токена 
6 validateEmail Перевірка Відхилення адрес Успішно 
синтаксису без доменної 
електронної пошти частини 
7 projectValidator Перевірка обмежень Помилка валідації Успішно 
на довжину назви при назві менше 
проєкту трьох символів та 
більше 40 
 
Застосування модульного тестування дозволило виявити та усунути логічні 
неточності в алгоритмах підрахунку прогресу та налаштувати коректну обробку 
часових поясів.  
3.2.2. Інтеграційне тестування 
Інтеграційне тестування системи полягає в перевірці взаємодії окремих 
компонентів: клієнтської частини (React), серверного API (Node.js) та бази даних 
(PostgreSQL). Основна мета – переконатися, що всі модулі коректно обмінюються 
даними в реальному часі, а також виявити конфлікти, які можуть виникнути при 
взаємодії між web-платформою та desktop-додатком . 
Процес інтеграційного тестування включав наступні кроки: 
− тестування зв'язку Web UI з API – перевірка, що при створенні проєкту 
на фронтенді відправляється коректний POST-запит, а сервер повертає відповідний 
об'єкт із присвоєним ID; 
− тестування зв'язку Electron з API – перевірка, що desktop-додаток формує 
правильну структуру даних про активність користувача та надсилає її на сервер; 
− тестування зв'язку API з базою даних – перевірка, що після отримання 
запиту сервер коректно зберігає дані в PostgreSQL та повертає актуальну 
інформацію; 
− тестування інтеграції модуля звітів – перевірка, що система формує звіт 
61 
ЧДТУ 262242.004 ПЗ 
на основі агрегованих даних з БД та коректно віддає його клієнту; 
− тестування маршрутизації з автентифікацією – перевірка, що захищені 
маршрути API доступні лише за наявності валідного JWT-токена, а Route Guard на 
фронтенді блокує переходи без авторизації. 
 
Таблиця 3.2 
Результати інтеграційного тестування 
Об’єкт Опис перевірки Результат 
тестування виконання 
Web UI Коректність створення, оновлення та видалення Успішно 
проєктів через API 
Electron/Server Передача пакетів даних про активність та Успішно 
API скріншотів робочого столу 
PostgreSQL Збереження та читання часових логів з БД без Успішно 
втрат 
Reporting Формування звіту на основі даних з БД та Успішно 
Module передача на клієнт 
System Event Спрацювання функції зупинки таймера при Успішно 
Loop відсутності активності 
Auth Module/ Перевірка цілісності сесії при переході між Успішно 
Route Guard розділами системи 
 
62 
ЧДТУ 262242.004 ПЗ 
 
Рисунок 3.14 – Результат виконання інтеграційного тестування 
 
Після успішного завершення етапу інтеграційного тестування було 
підтверджено, що всі ключові компоненти системи (web-dashboard, Electron-
компонент моніторингу, серверне API та база даних) коректно взаємодіють між 
собою. При перевірці було встановлено, що дані про активність користувача 
безперешкодно передаються від локального сховища до сервера, обробляються 
згідно з бізнес-логікою та в повному обсязі відображаються у статистичних звітах 
інтерфейсу. 
3.2.3. Системне тестування 
Системне тестування платформи для відстеження проєктної діяльності 
програміста є завершальним етапом верифікації, під час якого система 
перевіряється як єдине ціле. Основна мета цього етапу – підтвердження повної 
функціональності додатка, його стабільності під навантаженням та відповідності 
сформованим технічним вимогам у реальних умовах експлуатації. 
Після успішного завершення інтеграційного тестування, яке підтвердило 
63 
ЧДТУ 262242.004 ПЗ 
зв'язки між модулями, було проведено комплексне системне тестування всієї 
інфраструктури (Web, Desktop та Database). 
Основні етапи системного тестування: 
− тестування стабільності та витривалості – проведення тривалих сесій 
відстеження діяльності (понад 8 годин) для виявлення витоків пам'яті в Electron-
модулі. також перевірялася робота системи при максимальній кількості одночасних 
запитів до api для імітації активної роботи команди. 
− тестування відновлення після збоїв – важливий аспект для таймера – 
збереження прогресу. перевірялася здатність системи відновлювати активну сесію 
таймера після раптового завершення процесу додатка або перезавантаження 
операційної системи. 
− тестування продуктивності – аналіз швидкості відгуку інтерфейсу при 
великій кількості записів у базі даних. Перевірявся час завантаження головної 
сторінки та швидкість генерації аналітичних графіків. 
− тестування поведінки в умовах нестабільної мережі – перевірка 
механізмів черги запитів (request queueing), локального збереження даних при 
втраті зв'язку з мережею та автоматичної синхронізації після відновлення мережі; 
− тестування сумісності – перевірка роботи desktop-додатка на різних 
версіях ос (windows 10, windows 11) та коректність відображення web-інтерфейсу в 
основних браузерах (Chrome, Firefox,  Microsoft Edge). 
 
Таблиця 3.3 
Таблиця результатів системного тестування 
№ Функціональність Опис перевірки Очікуваний Результат 
перевірки результат 
1 Тестування Безперервна робота Відсутність crash, Успішно 
стабільності таймера протягом стабільне 
8+ годин споживання пам'яті 
 
64 
ЧДТУ 262242.004 ПЗ 
Продовження таблиці 3.3 
2 Тестування Імітація раптового Автоматичне Успішно 
відновлення після завершення відновлення сесії 
збоїв процесу додатка під після перезапуску 
час активної сесії 
3 Тестування Завантаження Час формування та Успішно 
продуктивності головної сторінки відображення 
при обсязі даних > інтерфейсу 
5000 записів у БД приблизно 2 секунди 
4 Тестування Робота в браузерах Коректне Успішно 
сумісності  Chrome, Firefox, відображення та 
Edge та ОС стабільна робота 
Windows 10/11 
5 Тестування Відключення Локальні дані Успішно 
нестабільної мережі на 5 хвилин синхронізовані з 
мережі з подальшим сервером без 
відновленням дублювання 
 
3.2.4. Приймальне тестування 
Приймальне тестування (UAT – User Acceptance Testing) платформи для 
відстеження проєктної діяльності було проведене з метою підтвердження 
готовності продукту до випуску та його відповідності очікуванням кінцевих 
користувачів. Основна увага приділялася перевірці того, як система вирішує 
реальні задачі обліку часу та наскільки зручним є інтерфейс управління проєктами. 
Під час приймального тестування були перевірені основні аспекти роботи 
системи, включаючи точність фіксації робочих сесій, ефективність алгоритму 
детекції бездіяльності (Idle Detection) та коректність генерації аналітичної 
звітності. Усі ключові функції продемонстрували стабільну роботу, що відповідає 
технічному завданню. 
Процес приймального тестування включав наступні кроки: 
− перевірка виконання вимог замовника – підтвердження наявності всіх 
65 
ЧДТУ 262242.004 ПЗ 
запланованих компонентів (авторизація, таймер, генерація звітів, управління 
командою) та їх відповідність технічному завданню; 
− тестування ключових сценаріїв використання – відтворення повного 
шляху користувача: від реєстрації та створення проєкту до запуску таймера, 
отримання звіту та експорту даних; 
− тестування зручності інтерфейсу (UI/UX) – перевірка адаптивності web-
інтерфейсу,  навігації, коректності відображення графіків, компонентів активності 
та сповіщень; 
− тестування обробки помилок користувача – перевірка валідації форм 
(порожні поля, некоректний email); 
 
Таблиця 3.4 
Таблиця результатів приймального тестування 
№ Сценарій Очікувана поведінка Фактичний Статус 
тестування результат 
1 Запуск таймера та Відображення Результат коректно Успішно 
зупинка через підсумкового часу відображено в 
інтерфейс відпрацьованої сесії інтерфейсі 
2 Відправка Виведення Повідомлення Успішно 
порожніх полів повідомлення про відображено, 
при створенні обов’язкове проєкт не створено 
проєкту заповнення полів 
3 Введення Показ помилок Дані відхилено, Успішно 
некоректних даних валідації та відхилення помилки 
у форму (email) даних відображені 
 
66 
ЧДТУ 262242.004 ПЗ 
Продовження таблиці 3.4 
4 Авторизація з Успішний вхід у систему та Вхід виконано, Успішно 
коректними доступ до робочої області доступ надано 
даними 
5 Авторизація з Повідомлення про помилку Відображено Успішно 
неправильним автентифікації повідомлення 
паролем «Невірний 
логін або 
пароль» 
6 Перезавантаження Збереження активної сесії Таймер Успішно 
сторінки під час без втрати даних продовжує 
активного роботу, дані 
таймера збережено 
3.3. Приклади впровадження програмного комплексу 
Впровадження платформи для відстеження проєктної діяльності програміста 
дозволяє автоматизувати облік робочого часу та підвищити прозорість процесів 
розробки. Нижче наведено опис процесу розгортання та приклади взаємодії 
користувача з основними компонентами. 
Для того щоб розгорнути систему та почати її використання, необхідно 
виконати наступні кроки: 
1 Завантажити актуальну версію коду з репозиторію на GitHub. 
2 Налаштувати локальне середовище – встановити Node.js та розгорнути 
базу даних PostgreSQL. 
3 Підключити необхідні бібліотеки та залежності за допомогою менеджера 
пакетів npm. 
4 Налаштувати конфігураційні файли (.env) для встановлення зв'язку між 
фронтендом, бекендом та базою даних. 
67 
ЧДТУ 262242.004 ПЗ 
Приклади роботи з системою 
Для перевірки функціоналу та підтвердження правильної роботи системи 
передбачено два основних сценарії взаємодії користувача з інструментами 
відстеження:  перший – через web-платформу, другий – допомогою desktop-додатка. 
Сценарій 1: використання web-платформи – web-інтерфейс дозволяє 
користувачу керувати робочим часом без необхідності встановлення додаткового 
ПЗ. 
1. Авторизація – увійти до особистого кабінету через будь-який сучасний 
браузер. 
2. Вибір завдання – обрати поточний проєкт або конкретне завдання зі 
списку доступних. 
3. Відслідковування часу – запустити таймер безпосередньо у вікні браузера. 
Дані про початок роботи миттєво фіксуються на сервері. Цей метод є оптимальним 
для швидкої фіксації часу без глибокого моніторингу активності. 
Сценарій 2: використання desktop-додатка – Electron забезпечує розширений 
контроль та автоматизацію процесів. 
1. Запуск додатка – авторизуватися у встановленому клієнті. 
2. Активація моніторингу – після натискання кнопки старту програма не 
лише відраховує час, а й активує компоненти створення скріншотів та аналізу 
активності пристроїв введення. 
3. Обробка бездіяльності (Idle Detection) – у разі відсутності дій з боку 
користувача за робочим місцем, додаток ідентифікує стан спокою та в разі, якщо 
користувач виконує командний проєкт – надсилає сповіщення керівнику. 
Процес взаємодії з системою в обох сценаріях завершується синхронізацією 
даних із сервером. Після завершення роботи керівник команди може переглянути 
візуальну статистику та завантажити детальний звіт. Такий підхід робить систему 
зручним інструментом для індивідуальних розробників так і для команд. 
68 
ЧДТУ 262242.004 ПЗ 
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ 
У даному розділі було здійснено комплексну розробку та тестування 
програмного забезпечення системи для відстеження проєктної діяльності 
програміста. На основі попередньо спроєктованої архітектури було реалізовано 
web-платформу, desktop-додаток та серверну частину, об’єднані єдиною логікою 
обміну даними та синхронізації в реальному часі. 
На етапі розробки було впроваджено модульну архітектуру системи, що 
забезпечує розділення відповідальності між клієнтськими та серверними 
компонентами, а також дозволяє незалежний розвиток кожного з них. Особливо 
було приділено увагу реалізації механізмів збору та обробки даних активності 
користувача, інтеграції системи таймера, а також забезпеченню стабільного обміну 
даними через API та WebSocket-з’єднання. Використання сучасного стеку 
технологій, зокрема TypeScript, React, Electron, Node.js та Socket.io, дозволило 
створити продуктивну та масштабовану архітектуру програмного комплексу. При 
розробці інтерфейсу користувача було створено набір React-компонентів, що 
забезпечують зручну взаємодію з системою. Інтерфейс включає компоненти 
керування проєктами, перегляду статистики, управління командою, відображення 
скріншотів та роботи таймера, що реалізований із використанням Document Picture-
in-Picture API. 
У процесі тестування програмного забезпечення було проведено модульне, 
інтеграційне, системне та приймальне тестування, що дозволило перевірити 
коректність роботи всіх компонентів системи. Результати тестування підтвердили 
стабільність роботи алгоритмів, очікувану взаємодію між компонентами та 
відповідність системи заданим вимогам. 
У кінцевому підсумку результати тестування підтверджують, що розроблена 
система є стабільною, функціонально завершеною та готовою до впровадження у 
реальні умови експлуатації для відстеження проєктної діяльності програміста.  
69 
ЧДТУ 262242.004 ПЗ 
ВИСНОВКИ 
У процесі виконання кваліфікаційної роботи бакалавра було успішно 
досягнуто поставлену мету – спроєктовано та реалізовано web-платформу для 
відстеження проєктної діяльності програміста. 
Розроблений програмний комплекс надає можливість здійснювати точний 
підрахунок витрат часу на виконання завдань, оцінювати динаміку продуктивності 
та оптимізувати процеси контролю як в ІТ-командах, так і під час індивідуальної 
роботи. 
У результаті виконання роботи були повністю виконані всі поставлені 
завдання, а саме: 
1 Проведено аналіз предметної області та існуючих аналогів, у межах якого 
досліджено сучасні системи керування часом та аналізу продуктивності 
користувачів – визначено їхні переваги, недоліки та обґрунтовано 
доцільність розробки власного оптимізованого рішення. 
2 Сформовано та деталізовано вимоги до системи, що дозволило чітко 
визначити функціональні та нефункціональні вимоги програмного 
забезпечення – увагу приділено критеріям стабільності системи, 
кросплатформеності, безпеки та захисту даних користувачів. 
3 Обґрунтовано та обрано сучасний технологічний стек для реалізації всіх 
компонентів архітектури – для розробки клієнтського web-інтерфейсу 
обрано мову TypeScript та бібліотеку ReactJS, для створення desktop-
компонента – фреймворк Electron, а для серверної частини – платформу 
Node.js у поєднанні з реляційною базою даних PostgreSQL. 
4 Розроблено інтерактивний інтерфейс користувача – що забезпечує зручну 
та інтуїтивно зрозумілу роботу з проєктами, завданнями й загальною 
статистикою робочого часу через браузери. 
5 Реалізовано серверну частину (back-end) системи, побудовану на базі 
архітектурного стилю REST API – забезпечено надійну систему 
автентифікації користувачів, гнучке розмежування прав доступу, безпечну 
взаємодію з базою даних та оптимізоване збереження логів. 
70 
ЧДТУ 262242.004 ПЗ 
6 Створено desktop-компонент додатка, який розширює базовий функціонал 
платформи – модуль успішно реалізує фоновий підрахунок активності 
користувача та розширює функціонал інтерактивного таймера та 
механізму скріншотів. 
7 Реалізовано функціонал статистики та звітності, що дозволяє здійснювати 
аналіз персональних та командних метрик – інформація виводиться у 
вигляді інтерактивних діаграм та графіків для візуалізації розподілу часу 
між завданнями, які можуть бути завантаженні у форматі CSV. 
8 Проведено комплексне тестування та підготовку платформи до 
впровадження. Програмний продукт успішно пройшов модульний, 
інтеграційний, системний та приймальний рівні тестування за допомогою 
інструментарію Jest та системних випробувань. Результати перевірки 
підтвердили стабільність обміну даними між компонентами системи, 
точність роботи модуля визначення інтервалів бездіяльності та здатність 
desktop-додатка стабільно функціонувати у фоновому режимі. 
За результатами тестування, розроблена платформа працює стабільно, 
коректно та повністю відповідає визначеним вимогам до структури, дизайну і 
функціональності, що підтверджує її готовність до практичної експлуатації в 
реальних умовах. 
  
71 
ЧДТУ 262242.004 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 GitHub Docs. GitHub REST API documentation [Електронний ресурс]. – Режим 
доступу: https://docs.github.com/rest 
2 Node.js Documentation. [Електронний ресурс]. – Режим доступу: 
https://nodejs.org/en/docs 
3 React Documentation. – Meta  [Електронний ресурс]. – Режим доступу:  
https://react.dev/ 
4 Методичні рекомендації до підготовки кваліфікаційної роботи бакалавра для 
здобувачів вищої освіти зі спеціальності 121 «Інженерія програмного 
забезпечення» усіх форм навчання [Текст] / Укл.: Голуб С.В., Заспа Г.О., 
Куницька С.Ю., Півень О.Б. Катаєва Є.Ю., Салапатов В.І., Метелап В.В., 
Олексюк В.В.; М-во освіти і науки України, Черкаський державний 
технологічний університет. - Черкаси : ЧДТУ, 2023. - 96 с. 
5 TypeScript Documentation. The TypeScript Handbook  [Електронний ресурс]. – 
Режим доступу:: https://www.typescriptlang.org/docs/handbook/intro.html 
6 React Tutorial for Beginners [Електронний ресурс]. – Режим доступу: 
https://www.youtube.com/watch?v=QFaFIcGhPoM... 
7 PlantText UML Editor. Professional UML diagrams with PlantUML 
[Електронний ресурс]. – Режим доступу: https://www.planttext.com/ 
8 Electron Documentation. Build cross-platform desktop apps with JavaScript, 
HTML, and CSS. [Електронний ресурс]. – Режим доступу: 
https://www.electronjs.org/docs 
9 JSON Web Token (JWT) Documentation. Introduction to JSON Web Tokens 
[Електронний ресурс]. – Режим доступу: https://jwt.io/introduction/  
10 Express.js Guide. Fast, unopinionated, minimalist web framework for Node.js 
[Електронний ресурс]. – Режим доступу: https://expressjs.com/  
11 PostgreSQL Documentation. The world's most advanced open source relational 
database [Електронний ресурс]. – Режим доступу: 
https://www.postgresql.org/docs/ 
72 
ЧДТУ 262242.004 ПЗ 
12 Bcrypt.js Library. Optimized bcrypt in JavaScript with zero dependencies. 
[Електронний ресурс]. – Режим доступу: 
https://www.npmjs.com/package/bcrypt  
13 Unified Modeling Language (UML) Resource Page. Object Management Group 
[Електронний ресурс]. – Режим доступу: https://www.uml.org/  
14  Toggl Track Documentation. Time tracking software for teams [Електронний 
ресурс]. – Режим доступу: https://toggl.com/track/  
15 Jira Software Support. Product documentation for project management 
[Електронний ресурс]. – Режим доступу: 
https://confluence.atlassian.com/jirasoftware  
16 RescueTime Help Center. Automatic time tracking and distraction management 
[Електронний ресурс]. – Режим доступу: https://www.rescuetime.com/  
17 Lucidchart. UML Use Case Diagram Tutorial [Електронний ресурс]. – Режим 
доступу: https://www.lucidchart.com/pages/uml-use-case-diagram. 
18 Visual Paradigm. Use Case Diagram Tutorial [Електронний ресурс]. – Режим 
доступу:https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-
tutorial/. 
19 Visual Paradigm. UML Class Diagram Tutorial [Електронний ресурс]. – Режим 
доступу:https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/uml-class-diagram-tutorial/. 
20 Lucidchart. UML Class Diagram Tutorial [Електронний ресурс]. – Режим 
доступу: https://www.lucidchart.com/l-class-diagram. 
21 Visual Paradigm. What is a Package Diagram in UML? [Електронний ресурс]. – 
Режим доступу: https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-package-diagram/. 
22 Lucidchart. Package Diagram Tutorial [Електронний ресурс]. – Режим доступу: 
https://www.lucidchart.com/pages/uml-package-diagram. 
23 Visual Paradigm. Component Diagram Tutorial [Електронний ресурс]. – Режим 
доступу:https://online.visual-paradigm.com/diagrams/tutorials/component-
diagram-tutorial/. 
73 
ЧДТУ 262242.004 ПЗ 
24 Lucidchart. UML Component Diagram Tutorial [Електронний ресурс]. – Режим 
доступу: https://www.lucidchart.com/pages/uml-component-diagram. 
25 Visual Paradigm. Deployment Diagram Tutorial [Електронний ресурс]. – Режим 
доступу:https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-deployment-diagram/. 
26 Lucidchart. UML Deployment Diagram Tutorial [Електронний ресурс]. – Режим 
доступу: https://www.lucidchart.com/pages/uml-deployment-diagram. 
27 Visual Paradigm. Activity Diagram Tutorial [Електронний ресурс]. – Режим 
доступу:https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-activity-diagram/. 
28 Lucidchart. UML Activity Diagram Tutorial [Електронний ресурс]. – Режим 
доступу: https://www.lucidchart.com/pages/uml-activity-diagram. 
29 Visual Paradigm. Sequence Diagram Tutorial [Електронний ресурс]. – Режим 
доступу:https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-sequence-diagram/. 
30 Lucidchart. UML Sequence Diagram Tutorial [Електронний ресурс]. – Режим 
доступу: https://www.lucidchart.com/pages/uml-sequence-diagram. 
31 Visual Paradigm. What is Communication Diagram? [Електронний ресурс]. – 
Режим доступу: https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-communication-diagram/. 
32 Visual Paradigm. All You Need to Know about State Diagrams [Електронний 
ресурс]. – Режим доступу: https://www.visual-paradigm.com/guide/uml-unified-
modeling-language/about-state-diagrams/. 
33 Socket.io. Introduction [Електронний ресурс]. – Режим доступу: 
https://socket.io/docs/v4/ 
34 Visual studio Code. Visual Studio Code documentation [Електронний ресурс]. – 
Режим доступу: https://code.visualstudio.com/docs 
 
   
74 
ДОДАТОК А 
ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2026 р. 
Web-платформа для відстеження проєктної діяльності програміста 
Специфікація 
482 ЧДТУ. 262242 004 
Листів 2 
Розробник _______________ Жалдак О.В. 
Керівник _______________ Немов Р.Г. 
Черкаси 2026
482 ЧДТУ 262242 004 2 
Позначення Найменування Примітки 
482 ЧДТУ. 262242 12 01 Текст програми 
482 ЧДТУ. 262242 34 01 Інструкція користувачеві 
482 ЧДТУ. 262242 90 01 Графічні матеріали 
76 
ДОДАТОК Б 
Web-платформа для відстеження проєктної діяльності програміста 
Текст програми 
482 ЧДТУ. 262242 12 01 
Листів 18 
Розробник _______________ Жалдак О.В. 
Черкаси 2026
 482 ЧДТУ 262242 12 01 2 
Лістинг коду Home.tsx 
import { useState, useEffect } from 'react'; 
import { useNavigate } from 'react-router-dom'; 
import Header from '@/components/Header'; 
import { DashboardCard } from 
'@/components/DashboardCard/DashboardCard'; 
import { AnalyticsCard } from '@/components/Cards/AnalyticsCard'; 
import { SessionsTable } from '@/components/Cards/SessionsTable'; 
import { DistributionCard } from 
'@/components/Cards/DistributionCard'; 
import styles from '@/styles/main.module.css'; 
import { useTimer } from '@/components/TimerDisplay/timerContext';  
import type { Project } from '../types/types';  
 
import '@/styles/reset.css'; 
import '@fontsource/montserrat/800.css'; 
import '@fontsource/montserrat/400.css'; 
 
export default function Home() { 
  const navigate = useNavigate(); 
 
  const { seconds, isActive, toggleTimer, handleOpenPiP } = 
useTimer(); 
 
  const [projectsData, setProjectsData] = useState<Project[]>([]); 
 
  useEffect(() => { 
    const token = localStorage.getItem('token'); 
    if (!token) { 
      navigate('/RegisterPage'); 
    } 
  }, [navigate]); 
 
  useEffect(() => { 
    const fetchProjects = async () => { 
      try { 
        const token = localStorage.getItem('token'); 
        if (!token) return; 
 
        const res = await 
fetch('http://localhost:5000/api/projects', { 
          headers: { 'Authorization': `Bearer ${token}` } 
        }); 
        const data = await res.json(); 
         
        if (Array.isArray(data)) { 
          setProjectsData(data); 
        } 
      } catch (e) { 
        console.error("Fetch projects error:", e); 
      } 
    }; 
 
    fetchProjects(); 
  }, [isActive]);  
 
  const totalSecondsFromDB = projectsData.reduce((acc, proj) => acc 
+ (Number(proj.totalSeconds) || 0), 0); 
78 
 482 ЧДТУ 262242 12 01 3 
    const todaySecondsFromDB = projectsData.reduce((acc, proj) => 
acc + (Number(proj.todaySeconds) || 0), 0); 
 
  return (  
    <div className={styles.pageWrapper}> 
      <Header /> 
      <main className={styles.mainContent}> 
        <div className={styles.dashboardLayout}> 
          <DashboardCard  
            seconds={seconds}  
            todaySeconds={todaySecondsFromDB + seconds}  
            totalSeconds={totalSecondsFromDB + seconds}  
            isActive={isActive}  
            onToggle={toggleTimer}  
            onOpenPiP={handleOpenPiP} 
          /> 
          <AnalyticsCard projectsData={projectsData} /> 
          <div className={styles.sessionsSection}> 
            <SessionsTable key={isActive ? 'running' : 'stopped'} /> 
          </div> 
          <DistributionCard projects={projectsData} /> 
        </div> 
      </main> 
    </div> 
  ); 
} 
 
 
Лістинг коду ProjectPage.tsx 
import React, { useState, useEffect } from 'react'; 
import Header from '@/components/Header'; 
import styles from '@/styles/project.module.css'; 
import { Search, Check, X, Plus } from 'lucide-react';  
import { ProjectRow } from '../components/rowLogic/ProjectRow'; 
import { TaskRow } from '../components/rowLogic/TaskRow'; 
import { TaskForm } from '../components/TaskForm/TaskForm'; 
import type { Project, Task, TeamMember } from '../types/types'; 
 
interface FullProject extends Project { 
  is_team?: boolean; 
  team_id?: number | null; 
  team_name?: string;  
  tasksToDisplay?: Task[]; 
} 
 
type FilterType = 'all' | 'personal' | 'i_assigned' | 
'assigned_to_me'; 
 
export default function ProjectsPage() { 
  const [projects, setProjects] = useState<FullProject[]>([]); 
  const [teamMembers, setTeamMembers] = useState<TeamMember[]>([]); 
  const [myTeams, setMyTeams] = useState<{id: number, name: 
string}[]>([]); 
  const [loading, setLoading] = useState(true); 
 
  const [searchTerm, setSearchTerm] = useState(''); 
79 
 482 ЧДТУ 262242 12 01 4 
  const [activeFilter, setActiveFilter] = 
useState<FilterType>('all'); 
  const [expandedProjectId, setExpandedProjectId] = useState<number 
| null>(null); 
  const [addingTaskToProjectId, setAddingTaskToProjectId] = 
useState<number | null>(null); 
   
  const [isAddingProject, setIsAddingProject] = useState(false); 
  const [newProjectName, setNewProjectName] = useState(''); 
  const [newProjectType, setNewProjectType] = useState<'personal' | 
'team'>('personal'); 
  const [selectedTeamId, setSelectedTeamId] = useState<number | 
null>(null); 
  const [selectedColor, setSelectedColor] = useState('#3b82f6'); 
 
  const [editProjId, setEditProjId] = useState<number | null>(null); 
  const [editTaskId, setEditTaskId] = useState<number | null>(null); 
 
  const currentUserId = typeof window !== 'undefined' ? 
Number(localStorage.getItem('userId')) : null; 
 
  const apiFetch = async (url: string, options: any = {}) => { 
    const token = localStorage.getItem('token'); 
    const res = await fetch(`http://localhost:5000/api${url}`, { 
      ...options, 
      headers: {  
        'Content-Type': 'application/json', 
        ...(token ? { 'Authorization': `Bearer ${token}` } : {}), 
        ...options.headers, 
      } 
    }); 
    if (!res.ok) throw new Error("API Error"); 
    return await res.json(); 
  }; 
 
  const loadData = async () => { 
    setLoading(true); 
    try { 
      const [projectsData, userTeamsData, membersData] = await 
Promise.all([ 
        apiFetch('/projects'), 
        apiFetch('/teams/my').catch(() => []), 
        apiFetch('/teams/current/members').catch(() => []) 
      ]); 
 
      const enrichedProjects = projectsData.map((p: any) => { 
        const team = userTeamsData.find((t: any) => t.id === 
p.team_id); 
        return {  
          ...p,  
          tasks: p.tasks || [],  
          team_name: team ? team.name : (p.is_team ? "Команда" : null)  
        }; 
      }); 
 
      setProjects(enrichedProjects); 
      setMyTeams(userTeamsData); 
      setTeamMembers(membersData); 
    } catch (err) { 
80 
 482 ЧДТУ 262242 12 01 5 
      console.error("Load failed", err); 
    } finally { 
      setLoading(false); 
    } 
  }; 
 
  useEffect(() => { loadData(); }, []); 
 
  const handleAddProject = async () => { 
    if (!newProjectName.trim()) return; 
    try { 
      const payload = {  
        name: newProjectName,  
        is_team: newProjectType === 'team', 
        team_id: newProjectType === 'team' ? selectedTeamId : null, 
        color: selectedColor  
      }; 
 
      const data = await apiFetch('/projects', { 
        method: 'POST', 
        body: JSON.stringify(payload) 
      }); 
 
      const team = myTeams.find(t => t.id === selectedTeamId); 
      const newProjFull = {  
        ...data,  
        tasks: [],  
        tasksCount: 0,  
        totalSeconds: 0, 
        team_name: team ? team.name : (data.is_team ? "Команда" : 
null) 
      }; 
 
      setProjects(prev => [newProjFull, ...prev]); 
      setNewProjectName(''); 
      setIsAddingProject(false); 
      setSelectedTeamId(null); 
    } catch (e) { alert("Помилка додавання"); } 
  }; 
 
  const handleUpdateProject = async (id: number, updates: 
Partial<FullProject>) => { 
    try { 
      const updated = await apiFetch(`/projects/${id}`, { 
        method: 'PATCH', 
        body: JSON.stringify(updates) 
      }); 
      setProjects(projects.map(p => p.id === id ? { ...p, ...updated 
} : p)); 
      setEditProjId(null); 
    } catch (e) { alert("Помилка оновлення"); } 
  }; 
 
  const handleDeleteProject = async (id: number) => { 
    if (!confirm('Видалити проект?')) return; 
    try { 
      await apiFetch(`/projects/${id}`, { method: 'DELETE' }); 
      setProjects(projects.filter(p => p.id !== id)); 
    } catch (e) { alert("Помилка видалення"); } 
81 
 482 ЧДТУ 262242 12 01 6 
  }; 
 
  const handleAddTask = async (projectId: number, taskData: any) => 
{ 
    try { 
      const data = await apiFetch(`/projects/${projectId}/tasks`, { 
        method: 'POST', 
        body: JSON.stringify(taskData) 
      }); 
      setProjects(projects.map(p => p.id === projectId ? { 
        ...p, 
        tasks: [...(p.tasks || []), data], 
        tasksCount: (p.tasksCount || 0) + 1 
      } : p)); 
      setAddingTaskToProjectId(null); 
    } catch (e: any) { alert(e.message); } 
  }; 
 
  const handleUpdateTask = async (projId: number, taskId: number, 
updates: Partial<Task>) => { 
    try { 
      const updatedTask = await apiFetch(`/tasks/${taskId}`, { 
        method: 'PATCH', 
        body: JSON.stringify(updates) 
      }); 
      setProjects(projects.map(p => p.id === projId ? { 
        ...p,  
        tasks: p.tasks.map(t => t.id === taskId ? updatedTask : t) 
      } : p)); 
      setEditTaskId(null); 
    } catch (e) { alert("Помилка оновлення завдання"); } 
  }; 
 
  const handleDeleteTask = async (projectId: number, taskId: number) 
=> { 
    try { 
      await apiFetch(`/tasks/${taskId}`, { method: 'DELETE' }); 
      setProjects(projects.map(p => p.id === projectId ? { 
        ...p, 
        tasks: p.tasks.filter(t => t.id !== taskId), 
        tasksCount: Math.max(0, (p.tasksCount || 0) - 1) 
      } : p)); 
    } catch (e) { alert("Помилка видалення завдання"); } 
  }; 
 
  const filteredProjects = projects.map(project => { 
    const tasks = project.tasks || []; 
    let tasksToDisplay = tasks; 
    if (activeFilter === 'assigned_to_me') tasksToDisplay = 
tasks.filter(t => Number(t.assigned_to) === currentUserId); 
    if (activeFilter === 'i_assigned') tasksToDisplay = tasks.filter(t 
=> Number(project.user_id) === currentUserId && t.assigned_to && 
Number(t.assigned_to) !== currentUserId); 
 
    return { ...project, tasksToDisplay }; 
  }).filter(project => { 
    const matchesSearch = 
project.name.toLowerCase().includes(searchTerm.toLowerCase()); 
    if (!matchesSearch) return false; 
82 
 482 ЧДТУ 262242 12 01 7 
    if (activeFilter === 'personal') return !project.is_team; 
    if (activeFilter === 'assigned_to_me' || activeFilter === 
'i_assigned') return project.tasksToDisplay.length > 0; 
    return true;  
  }); 
 
  const formatSeconds = (s: number = 0) => { 
    const h = Math.floor(s / 3600); 
    const m = Math.floor((s % 3600) / 60); 
    return `${h.toString().padStart(2, 
'0')}:${m.toString().padStart(2, '0')}`; 
  }; 
 
  return ( 
    <div className={styles.wrapperContainer}> 
      <Header /> 
      <div className={styles.mainContainer}> 
         
        <div className={styles.filterBarWrapper}> 
          <div className={styles.searchBox}> 
            <Search size={18} className={styles.searchIcon} /> 
            <input  
              className={styles.searchInput}  
              placeholder="Пошук проектів..."  
              value={searchTerm}  
              onChange={(e) => setSearchTerm(e.target.value)}  
            /> 
          </div> 
 
          <div className={styles.rightActions}> 
            <div className={styles.filterTabs}> 
              {['all', 'personal', 'i_assigned', 
'assigned_to_me'].map((f) => ( 
                <button  
                  key={f} 
                  className={activeFilter === f ? styles.activeTab : 
styles.tab}  
                  onClick={() => setActiveFilter(f as FilterType)} 
                > 
                  {f === 'all' && 'Всі'} 
                  {f === 'personal' && 'Особисті'} 
                  {f === 'i_assigned' && 'Я призначив'} 
                  {f === 'assigned_to_me' && 'Мені призначено'} 
                </button> 
              ))} 
            </div> 
            <button className={styles.newProjectBtn} onClick={() => 
setIsAddingProject(true)}> 
              <Plus size={18} /> Новий проект 
            </button> 
          </div> 
        </div> 
 
        <div className={styles.tableContainer}> 
          <div className={styles.tableHeader}> 
            <div className={styles.colCentering}>#</div> 
            <div>ПРОЕКТ</div> 
            <div>ТИП / КОМАНДА</div> 
            <div className={styles.colCentering}>ЗАВДАННЯ</div> 
83 
 482 ЧДТУ 262242 12 01 8 
            <div className={styles.colCentering}>ЧАС</div> 
            <div style={{textAlign:'right'}}>ДІЇ</div> 
          </div> 
 
          {isAddingProject && ( 
            <div className={styles.inlineAddingRow}> 
              <div className={styles.colCentering}>*</div> 
              <div style={{ display: 'flex', alignItems: 'center', 
gap: '10px' }}> 
                <input  
                  type="color"  
                  className={styles.miniColorPicker} 
                  value={selectedColor}  
                  onChange={(e) => setSelectedColor(e.target.value)}  
                /> 
                <input  
                  autoFocus  
                  className={styles.tableInput}  
                  placeholder="Назва проекту..."  
                  value={newProjectName}  
                  onChange={(e) => setNewProjectName(e.target.value)} 
                /> 
              </div> 
              <div style={{ display: 'flex', flexDirection: 'column', 
gap: '4px' }}> 
                <select  
                  className={styles.projectTypeSelect} 
                  value={newProjectType} 
                  onChange={(e) => setNewProjectType(e.target.value 
as 'personal' | 'team')} 
                > 
                  <option value="personal">Особистий</option> 
                  <option value="team">Командний</option> 
                </select> 
                {newProjectType === 'team' && ( 
                  <select  
                    className={styles.tableSelect} 
                    value={selectedTeamId || ''}  
                    onChange={(e) => setSelectedTeamId(e.target.value 
? Number(e.target.value) : null)} 
                  > 
                    <option value="">Оберіть команду...</option> 
                    {myTeams.map(t => <option key={t.id} 
value={t.id}>{t.name}</option>)} 
                  </select> 
                )} 
              </div> 
              <div className={styles.colCentering}>0</div> 
              <div className={styles.colCentering}>00:00</div> 
              <div className={styles.projectActions}> 
                <Check size={22} className={styles.confirmIcon} 
onClick={handleAddProject} /> 
                <X size={22} className={styles.cancelIcon} onClick={() 
=> setIsAddingProject(false)} /> 
              </div> 
            </div> 
          )} 
 
          {loading ? ( 
84 
 482 ЧДТУ 262242 12 01 9 
            <div 
className={styles.loadingState}>Завантаження...</div> 
          ) : filteredProjects.map((project, index) => ( 
            <React.Fragment key={project.id}> 
              <ProjectRow  
                project={{...project, totalTime: 
formatSeconds(project.totalSeconds)}}  
                index={index} 
                isExpanded={expandedProjectId === project.id} 
                isEditing={editProjId === project.id} 
                onToggle={() => setExpandedProjectId(expandedProjectId 
=== project.id ? null : project.id)} 
                onEdit={() => setEditProjId(project.id)} 
                onUpdate={(upd: any) => 
handleUpdateProject(project.id, upd)} 
                onDelete={(e: any) => { e.stopPropagation(); 
handleDeleteProject(project.id); }} 
              /> 
 
              {expandedProjectId === project.id && ( 
                <div className={styles.expandedTasks}> 
                  <div className={`${styles.taskTableHeader} 
${project.is_team ? styles.gridWithAssignee : styles.gridNoAssignee}`}> 
                    <div /> 
                    <div>НАЗВА</div> 
                    <div>ОПИС</div> 
                    <div>ТИП</div> 
                    {project.is_team && <div>ВИКОНАВЕЦЬ</div>} 
                    <div style={{textAlign:'center'}}>ЧАС</div> 
                    <div style={{textAlign:'right'}}>ДІЇ</div> 
                  </div> 
 
                  {project.tasksToDisplay?.map(task => ( 
                    <TaskRow  
                      key={task.id}  
                      task={task}  
                      isTeamProject={!!project.is_team} 
                      members={teamMembers} 
                      isEditing={editTaskId === task.id} 
                      onEdit={() => setEditTaskId(task.id)} 
                      onCancelEdit={() => setEditTaskId(null)} 
                      onDelete={() => handleDeleteTask(project.id, 
task.id)} 
                      onUpdate={(upd: any) => 
handleUpdateTask(project.id, task.id, upd)}  
                    /> 
                  ))} 
 
                  <div className={styles.addTaskFooter}> 
                    {addingTaskToProjectId === project.id ? ( 
                      <TaskForm  
                        isTeamProject={!!project.is_team} 
                        members={teamMembers} 
                        projectColor={project.color} 
                        onSave={(data) => handleAddTask(project.id, 
data)}  
                        onCancel={() => setAddingTaskToProjectId(null)}  
                      /> 
                    ) : ( 
85 
 482 ЧДТУ 262242 12 01 10 
                      <button className={styles.addInlineBtn} 
onClick={() => setAddingTaskToProjectId(project.id)}> 
                        <Plus size={16} /> Додати завдання 
                      </button> 
                    )} 
                  </div> 
                </div> 
              )} 
            </React.Fragment> 
          ))} 
        </div> 
      </div> 
    </div> 
  ); 
} 
 
 
Лістинг коду ReportPage.tsx 
export interface TeamMember { 
  id: number; 
  username: string; 
  email: string; 
  role: string; 
  weekly_hours: string; 
  daily_avg: string; 
  trend: number; 
  current_project?: string; 
  avatar_url?: string; 
} 
 
export interface Team { 
  id: number; 
  name: string; 
  color: string; 
  members_count: number; 
  total_hours?: string; 
  avg_hours?: string; 
} 
 
const getAvatarUrl = (avatar?: string, username?: string) => { 
  if (!avatar) { 
    return 
`https://api.dicebear.com/7.x/initials/svg?seed=${username}`; 
  } 
 
  if (avatar.startsWith('http')) return avatar; 
 
  return `http://localhost:5000${avatar}`; 
}; 
 
const getAvatarColor = (username: string) => { 
  const colors = ['#8b5cf6', '#3b82f6', '#ec4899', '#f59e0b', 
'#10b981', '#ef4444']; 
  const charCodeSum = (username || 'User').split('').reduce((acc, 
char) => acc + char.charCodeAt(0), 0); 
  return colors[charCodeSum % colors.length]; 
}; 
86 
 482 ЧДТУ 262242 12 01 11 
 
export default function ReportPage() { 
  const [loading, setLoading] = useState(true); 
  const [reportType, setReportType] = useState<'my' | 'team'>('my'); 
  const [displayStats, setDisplayStats] = useState<any>(null); 
   
  const [teams, setTeams] = useState<Team[]>([]); 
  const [selectedTeam, setSelectedTeam] = useState<Team | 
null>(null); 
  const [isTeamSelectorOpen, setIsTeamSelectorOpen] = 
useState(false); 
   
  const [teamMembers, setTeamMembers] = useState<TeamMember[]>([]); 
  const [activeUserInTeam, setActiveUserInTeam] = 
useState<TeamMember | null>(null); 
 
  const token = typeof window !== 'undefined' ? 
localStorage.getItem('token') : null; 
  const headers = { 'Authorization': `Bearer ${token}` }; 
 
   useEffect(() => { 
    const initPage = async () => { 
      try { 
        const [myStatsRes, teamsRes] = await Promise.allSettled([ 
          axios.get('http://localhost:5000/api/reports/stats', { 
headers }), 
          axios.get('http://localhost:5000/api/teams/my', { headers 
}) 
        ]); 
         
        if (myStatsRes.status === 'fulfilled') { 
          setDisplayStats(processTrendData(myStatsRes.value.data)); 
        } 
         
        if (teamsRes.status === 'fulfilled') { 
          setTeams(teamsRes.value.data); 
          if (teamsRes.value.data.length > 0) { 
            setSelectedTeam(teamsRes.value.data[0]); 
          } 
        } 
      } catch (error) { 
        console.error("Initialization error:", error); 
      } finally { 
        setLoading(false); 
      } 
    }; 
    initPage(); 
  }, []); 
 
  useEffect(() => { 
    if (reportType === 'team' && selectedTeam) { 
      loadTeamData(selectedTeam.id); 
    } else if (reportType === 'my') { 
      loadMyData(); 
    } 
  }, [reportType, selectedTeam]); 
 
  const loadMyData = async () => { 
    try { 
87 
 482 ЧДТУ 262242 12 01 12 
      const res = await 
axios.get('http://localhost:5000/api/reports/stats', { headers }); 
      setDisplayStats(processTrendData(res.data)); 
      setActiveUserInTeam(null); 
    } catch (error) { 
      console.error("Error loading personal reports:", error); 
    } 
  }; 
 
  const loadTeamData = async (teamId: number) => { 
    try { 
      const results = await Promise.allSettled([ 
        axios.get(`http://localhost:5000/api/reports/team/${teamId}`
, { headers }), 
        axios.get(`http://localhost:5000/api/reports/team/${teamId}/
stats`, { headers }) 
      ]); 
       
      if (results[0].status === 'fulfilled') { 
        const data = results[0].value.data; 
        setTeamMembers(Array.isArray(data) ? data : (data.members || 
[])); 
      } else { 
        setTeamMembers([]);  
      } 
 
      if (results[1].status === 'fulfilled') { 
        setDisplayStats(processTrendData(results[1].value.data)); 
      } 
       
      setActiveUserInTeam(null);  
    } catch (error) { 
      console.error("Critical error loadTeamData:", error); 
    } 
  }; 
 
  const handleUserClick = async (member: TeamMember) => { 
    if (!selectedTeam) return; 
    try { 
      setActiveUserInTeam(member); 
      const url = 
`http://localhost:5000/api/reports/team/${selectedTeam.id}/member/${membe
r.id}`; 
      const res = await axios.get(url, { headers }); 
       
      if (res.data) { 
        setDisplayStats(processTrendData(res.data)); 
      } 
    } catch (error) { 
      console.error("Error loading member stats:", error); 
    } 
  }; 
 
  const processTrendData = (data: any) => { 
    if (!data) return null; 
    const template = [ 
      { date: 'W1', hours: 0 }, { date: 'W2', hours: 0 }, 
      { date: 'W3', hours: 0 }, { date: 'W4', hours: 0 } 
    ]; 
88 
 482 ЧДТУ 262242 12 01 13 
     
    // Перевіряємо наявність тренду 
    if (data.monthlyTrend && Array.isArray(data.monthlyTrend)) { 
      data.monthlyTrend.forEach((item: any) => { 
        const index = template.findIndex(t => t.date === item.date); 
        if (index !== -1) template[index].hours = 
parseFloat(item.hours) || 0; 
      }); 
    } 
     
    return {  
      ...data,  
      monthlyTrend: template, 
      weeklyData: data.weeklyData || [], 
      projectData: data.projectData || [] 
    }; 
  }; 
 
  if (loading) return <div className={styles.loading}>Завантаження 
аналітики...</div>; 
 
  return ( 
    <div className={styles.container}> 
      <Header /> 
       
      <div className={styles.subHeader}> 
        <div className={styles.tabGroup}> 
          <button  
            className={reportType === 'my' ? styles.tabActiveNav : 
styles.tabNav}  
            onClick={() => setReportType('my')} 
          > 
            <User size={16} /> Мої звіти 
          </button> 
          <button  
            className={reportType === 'team' ? styles.tabActiveNav : 
styles.tabNav}  
            onClick={() => setReportType('team')} 
          > 
            <Users size={16} /> Моя команда 
          </button> 
        </div> 
 
        {reportType === 'team' && ( 
          <div className={styles.teamSelectorWrapper}> 
            <button className={styles.selectorBtn} onClick={() => 
setIsTeamSelectorOpen(!isTeamSelectorOpen)}> 
              <Shield size={16} /> 
              <span>{selectedTeam?.name || "Оберіть команду"}</span> 
              <ChevronDown size={14} className={isTeamSelectorOpen ? 
styles.rotateIcon : ''} /> 
            </button> 
            {isTeamSelectorOpen && ( 
              <div className={styles.dropdown}> 
                {teams.map((team) => ( 
                  <div  
                    key={team.id}  
                    className={styles.dropdownItem}  
89 
 482 ЧДТУ 262242 12 01 14 
                    onClick={() => { setSelectedTeam(team); 
setIsTeamSelectorOpen(false); }} 
                  > 
                    <div className={styles.teamDot} style={{ 
backgroundColor: team.color }} /> 
                    <div className={styles.dropdownText}> 
                      <p>{team.name}</p> 
                      <span>{team.members_count} учасників</span> 
                    </div> 
                  </div> 
                ))} 
              </div> 
            )} 
          </div> 
        )} 
      </div> 
 
      <main className={styles.content}> 
        <div className={styles.statsContextBar}> 
          <h2> 
            {reportType === 'my'  
              ? "Персональна продуктивність"  
              : activeUserInTeam  
                ? `Аналітика: ${activeUserInTeam.username}`  
                : `Командний звіт: ${selectedTeam?.name}`} 
          </h2> 
          {reportType === 'team' && activeUserInTeam && ( 
            <button className={styles.resetBtn} onClick={() => 
loadTeamData(selectedTeam!.id)}> 
              <RefreshCw size={14} /> Повернутись до команди 
            </button> 
          )} 
        </div> 
 
        <div className={styles.metricsGrid}> 
          <MetricCard  
            title="Total Hours"  
            value={displayStats?.totalHours || "0h"}  
            trend={displayStats?.trends?.hours}  
            icon={<Clock size={16} />}  
          /> 
          <MetricCard  
            title="Avg. Daily"  
            value={displayStats?.avgDaily || "0h"}  
            trend={displayStats?.trends?.daily}  
            icon={<TrendingUp size={16} />}  
          /> 
          <MetricCard  
            title={reportType === 'my' ? "Projects" : "Members"}  
            value={reportType === 'my' ? displayStats?.projectCount 
|| 0 : teamMembers.length}  
            icon={reportType === 'my' ? <Folder size={16} /> : 
<Users size={16} />}  
          /> 
        </div> 
 
        <div className={styles.chartSection}> 
          <div className={styles.chartHeader}><h3>Weekly 
Productivity</h3></div> 
90 
 482 ЧДТУ 262242 12 01 15 
          <div style={{ width: '100%', height: 300 }}> 
            <ResponsiveContainer width="100%" height="100%"> 
              <BarChart data={displayStats?.weeklyData || []}> 
                <CartesianGrid strokeDasharray="3 3" 
vertical={false} stroke="#2d3748" /> 
                <XAxis dataKey="day" axisLine={false} 
tickLine={false} tick={{fill: '#718096', fontSize: 12}} /> 
                <YAxis axisLine={false} tickLine={false} 
tick={{fill: '#718096', fontSize: 12}} /> 
                <Tooltip  
                  cursor={{ fill: 'rgba(255, 255, 255, 0.05)' }}  
                  contentStyle={{ backgroundColor: '#1a202c', 
border: '1px solid #2d3748', borderRadius: '8px' }}  
                /> 
                <Bar dataKey="hours" fill="#3b82f6" radius={[4, 4, 
0, 0]} barSize={45} /> 
              </BarChart> 
            </ResponsiveContainer> 
          </div> 
        </div> 
 
        <div className={styles.bottomGrid}> 
          <div className={styles.chartSection}> 
            <h3>Monthly Trend</h3> 
            <div style={{ width: '100%', height: 250 }}> 
              <ResponsiveContainer width="100%" height="100%"> 
                <AreaChart data={displayStats?.monthlyTrend || []}> 
                  <defs> 
                    <linearGradient id="colorHours" x1="0" y1="0" 
x2="0" y2="1"> 
                      <stop offset="5%" stopColor="#3b82f6" 
stopOpacity={0.3}/> 
                      <stop offset="95%" stopColor="#3b82f6" 
stopOpacity={0}/> 
                    </linearGradient> 
                  </defs> 
                  <CartesianGrid strokeDasharray="3 3" 
vertical={false} stroke="#2d3748" /> 
                  <XAxis dataKey="date" axisLine={false} 
tickLine={false} tick={{fill: '#718096', fontSize: 12}} /> 
                  <YAxis hide />  
                  <Tooltip contentStyle={{ backgroundColor: 
'#1a202c', border: '1px solid #2d3748' }} /> 
                  <Area type="monotone" dataKey="hours" 
stroke="#3b82f6" fill="url(#colorHours)" strokeWidth={3} /> 
                </AreaChart> 
              </ResponsiveContainer> 
            </div> 
          </div> 
 
          <div className={styles.chartSection}> 
            <h3>Time by Project</h3> 
            <div className={styles.pieWrapper}> 
              <div style={{ width: '55%', height: 220 }}> 
                <ResponsiveContainer width="100%" height="100%"> 
                  <PieChart> 
                    <Pie  
                      data={displayStats?.projectData || []}  
                      innerRadius={65}  
91 
 482 ЧДТУ 262242 12 01 16 
                      outerRadius={85}  
                      dataKey="value"  
                      stroke="none"  
                      paddingAngle={5} 
                    > 
                      {(displayStats?.projectData || []).map((entry: 
any, index: number) => ( 
                        <Cell key={`cell-${index}`} 
fill={entry.color || '#3b82f6'} /> 
                      ))} 
                    </Pie> 
                  </PieChart> 
                </ResponsiveContainer> 
              </div> 
              <div className={styles.legend}> 
                {(displayStats?.projectData || []).map((item: any) 
=> ( 
                  <div key={item.name} 
className={styles.legendItem}> 
                    <div className={styles.legendLabel}> 
                      <span className={styles.dot} style={{ 
backgroundColor: item.color }}></span> 
                      <span 
className={styles.itemName}>{item.name}</span> 
                    </div> 
                    <span 
className={styles.itemValue}>{item.value}%</span> 
                  </div> 
                ))} 
              </div> 
            </div> 
          </div> 
        </div> 
 
        {reportType === 'team' && ( 
          <div className={styles.teamTableSection}> 
            <div className={styles.tableHeader}> 
              <div className={styles.titleWithIcon}> 
                <Users size={20} className={styles.blueIcon} /> 
                <div> 
                  <h3>Звіти учасників</h3> 
                  <p>Оберіть рядок, щоб деталізувати графіки</p> 
                </div> 
              </div> 
              <div className={styles.headerStats}> 
                <div className={styles.miniMetric}><Clock 
size={14}/> Всього: <b>{selectedTeam?.total_hours || '0h'}</b></div> 
                <div className={styles.miniMetric}><Target 
size={14}/> Сер./день: <b>{selectedTeam?.avg_hours || '0h'}</b></div> 
              </div> 
            </div> 
 
            <table className={styles.table}> 
              <thead> 
                <tr> 
                  <th>Співробітник</th> 
                  <th>Проект</th> 
                  <th>Годин / Тиждень</th> 
                  <th>Сер. / День</th> 
92 
 482 ЧДТУ 262242 12 01 17 
                  <th>Тренд</th> 
                </tr> 
              </thead> 
              <tbody> 
                {teamMembers.length > 0 ? ( 
                  teamMembers.map((member) => ( 
                    <tr  
                      key={member.id}  
                      className={`${styles.clickableRow} 
${activeUserInTeam?.id === member.id ? styles.activeRow : ''}`}  
                      onClick={() => handleUserClick(member)} 
                    > 
                      <td> 
                        <div className={styles.userCell}> 
                         <div className={styles.avatar} style={{ 
backgroundColor: getAvatarColor(member.username) }}> 
  {member.avatar_url ? ( 
    <img  
      src={getAvatarUrl(member.avatar_url, member.username)}  
      alt={member.username}  
      className={styles.avatarImg} 
      onError={(e) => { 
        (e.target as HTMLImageElement).style.display = 'none';  
      }} 
    /> 
  ) : null} 
  <span className={styles.avatarInitials}> 
    {member.username.substring(0, 2).toUpperCase()} 
  </span> 
</div> 
                          <span 
className={styles.userName}>{member.username}</span> 
                        </div> 
                      </td> 
                      <td><span 
className={styles.projectBadge}>{member.current_project || 
'Project'}</span></td> 
                      <td 
className={styles.hoursCell}>{member.weekly_hours}</td> 
                      <td>{member.daily_avg}</td> 
                      <td> 
                        <div className={member.trend >= 0 ? 
styles.trendUp : styles.trendDown}> 
                          {member.trend >= 0 ? <ArrowUpRight 
size={14}/> : <ArrowDownRight size={14}/>} 
                          {Math.abs(member.trend)}% 
                        </div> 
                      </td> 
                    </tr> 
                  )) 
                ) : ( 
                  <tr> 
                    <td colSpan={5} className={styles.emptyRow}>Дані 
про учасників відсутні</td> 
                  </tr> 
                )} 
              </tbody> 
            </table> 
          </div> 
93 
 482 ЧДТУ 262242 12 01 18 
        )} 
      </main> 
    </div> 
  ); 
} 
 
function MetricCard({ title, value, trend, icon }: any) { 
  const isPositive = trend?.includes('↑') || 
trend?.includes('Зріст') || (typeof trend === 'number' && trend > 0); 
  return ( 
    <div className={styles.metricCard}> 
      <div className={styles.metricHeader}> 
        <span className={styles.metricTitle}>{title}</span> 
        <span className={styles.metricIcon}>{icon}</span> 
      </div> 
      <div className={styles.metricValue}>{value || "0"}</div> 
      {trend && ( 
        <div className={`${styles.trend} ${isPositive ? 
styles.trendPositive : styles.trendNegative}`}> 
          {trend} <span className={styles.trendLabel}>vs last 
month</span> 
        </div> 
      )} 
    </div> 
  ); 
} 
 
 
94 
 
ДОДАТОК В 
 
 
 
 
Web-платформа для відстеження проєктної діяльності програміста 
 
Інструкція користувачеві 
482 ЧДТУ. 262242 34 01 
Листів 3 
 
 
 
 
 
Розробник _______________ Жалдак О.В. 
 
 
 
 
 
 
 
 
 
 
 
Черкаси 2026
 
 
 482 ЧДТУ 262242 34 01 2 
Дана інструкція користувача призначена для ознайомлення з 
функціональними можливостями та правилами навігації багатокомпонентної 
платформи для відстеження проектної діяльності програміста. Платформу було 
розроблено з урахуванням потреб індивідуальних розробників та керівників IT-
команд. 
Інтерфейс системи є інтуїтивно зрозумілим, інформація структурована за 
логічними модулями, що забезпечує швидкий доступ до таймера, аналітики та 
налаштувань. Інструкція допоможе користувачам ефективно взаємодіяти з 
основними розділами платформи, керувати завданнями, переглядати звіти про 
продуктивність та використовувати desktop-додаток для автоматичної фіксації 
активності. 
1. Реєстрація та вхід: 
− Реєстрація – перейдіть на головну сторінку, натисніть «Зареєструватися», 
заповніть необхідні поля та підтвердіть створення акаунту. 
− Вхід – для входу у web-платформу або desktop-додаток використовуйте 
свій логін та пароль. Після успішної аутентифікації ви потрапите на головну панель 
(Dashboard). 
2. Робота із завданнями та проектами: 
– Вибір проекту – у боковому навігаційному меню оберіть розділ 
«Проекти», де відображається перелік активних проектів. 
– Фільтрація завдань – для швидкої навігації використовуйте фільтр 
«Призначено мені» (щоб побачити власні задачі) або «Я призначив» (якщо ви 
призначили завдання іншим). 
3. Таймер та моніторинг активності: 
– Запуск відстеження – на головній сторінці оберіть завдання та натисніть 
«Start». Таймер почне відлік часу в реальному часі. 
– Автоматична фіксація – під час роботи таймера платформа автоматично 
створює скріншоти робочого столу, якщо ви в desktop-додатку система також 
фіксує активність здійснюючи логування дій. 
– Зупинка – для завершення фіксації часу натисніть кнопку «Stop». 
96 
 482 ЧДТУ 262242 34 01 3 
4. Аналітика та контроль: 
– Перегляд звітів – у розділі «Статистика» доступні візуалізовані звіти у 
вигляді діаграм та графіків, що відображають продуктивність за обраний період. 
– Перегляд скріншотів – у розділі «Screenshots» можна переглянути 
зафіксовані кадри екрана, натиснувши на відповідний часовий проміжок. 
5. Налаштування та вихід: 
– Персоналізація – на сторінці «Налаштування» користувач може змінити 
персональні дані, пароль або встановити частоту створення скріншотів для desktop-
клієнта. 
– Завершення сесії – для виходу з акаунту натисніть «Logout» у меню 
налаштувань.
97 
 
ДОДАТОК Г 
 
 
. 
 
 
 
Web-платформа для відстеження проєктної діяльності програміста 
 
Графічні матеріали 
482 ЧДТУ. 262242 90 01 
Листів 12 
 
 
Розробник _______________ Жалдак О.В. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Черкаси 2026 
 
 
 482 ЧДТУ 262242 90 01 2 
 
Рисунок Г.1 – Слайд 1 
 
 
Рисунок Г.2 – Слайд 2 
 
 
99 
 482 ЧДТУ 262242 90 01 3 
 
Рисунок Г.3 – Слайд 3 
 
 
Рисунок Г.4 – Слайд 4 
 
100 
 482 ЧДТУ 262242 90 01 4 
 
Рисунок Г.5 – Слайд 5 
 
 
Рисунок Г.6 – Слайд 6 
 
101 
 482 ЧДТУ 262242 90 01 5 
 
Рисунок Г.7 – Слайд 7 
 
Рисунок Г.8 – Слайд 8 
102 
 482 ЧДТУ 262242 90 01 6 
 
Рисунок Г.9 – Слайд 9 
 
 
Рисунок Г.10 – Слайд 10 
 
103 
 482 ЧДТУ 262242 90 01 7 
 
Рисунок Г.11 – Слайд 11 
 
 
Рисунок Г.12 – Слайд 12 
104 
 482 ЧДТУ 262242 90 01 8 
 
Рисунок Г.13 – Слайд 13 
 
 
Рисунок Г.14 – Слайд 14 
105 
 482 ЧДТУ 262242 90 01 9 
 
Рисунок Г.15 – Слайд 15 
 
 
 
Рисунок Г.16 – Слайд 16 
 
106 
 482 ЧДТУ 262242 90 01 10 
 
Рисунок Г.17 – Слайд 17 
 
 
Рисунок Г.18 – Слайд 18 
107 
 482 ЧДТУ 262242 90 01 11 
 
Рисунок Г.19 – Слайд 19 
 
 
 
Рисунок Г.20 – Слайд 20 
 
108 
 482 ЧДТУ 262242 90 01 12 
 
Рисунок Г.21 – Слайд 21 
 
 
Рисунок Г.22 – Слайд 22 
109
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
