Вебсервіс TimeBrix для управління проєктами та операційною  діяльністю підприємств

Атрощенко, Олександра Андріївна

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

Full metadata record

DC Field	Value	Language
dc.contributor.advisor	Катаєв, Дмитро Сергійович	-
dc.contributor.author	Атрощенко, Олександра Андріївна	-
dc.date.accessioned	2026-07-27T08:30:03Z	-
dc.date.available	2026-07-27T08:30:03Z	-
dc.date.issued	2026-06-09	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/9880	-
dc.description.abstract	Кваліфікаційна робота присвячена проєктуванню, розробці та тестуванню вебсервісу TimeBrix для управління проєктами та операційною діяльністю підприємств. Актуальність теми. Актуальність роботи зумовлена потребою підприємств у єдиному цифровому середовищі, яке дозволяє структурувати проєкти, контролювати виконання задач, розподіляти відповідальність між учасниками команди, аналізувати виконання робіт та підвищувати прозорість операційних процесів. Мета роботи і задачі дослідження. Метою роботи є розробка функціонального, зручного та масштабованого web-сервісу TimeBrix на базі сучасного стеку технологій. Об’єктом роботи є процес цифрового управління проєктами, задачами та операційною діяльністю організацій. Предметом роботи є архітектура, функціональні модулі, база даних, механізми безпеки та користувацький інтерфейс web-сервісу TimeBrix. Предмет дослідження: серверна та клієнтська частина веб-ресурсу для керування управління проєктами. Методи дослідження: в роботі застосовувалися аналізи існуючих рішень, методи проектування та створення програмних продуктів, патерни проєктування, аналіз предметної області, порівняльний аналіз аналогів, моделювання вимог, проєктування бази даних, модульне проєктування backend і frontend частин, функціональне тестування та аналіз результатів роботи системи.	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	web-сервіс	uk_UA
dc.subject	Prisma	uk_UA
dc.subject	управління проєктами	uk_UA
dc.subject	управління задачами	uk_UA
dc.subject	аналітика	uk_UA
dc.subject	React	uk_UA
dc.subject	NestJS	uk_UA
dc.subject	TypeScript	uk_UA
dc.subject	PostgreSQL	uk_UA
dc.subject	Docker	uk_UA
dc.title	Вебсервіс TimeBrix для управління проєктами та операційною діяльністю підприємств	uk_UA
dc.type	Bachelor Thesis	uk_UA
Appears in Collections:	126 Інформаційні системи та технології (Web-технології, web-дизайн)

Files in This Item:

File	Description	Size	Format
РЕП_БАК_Атрощенко _WEB-2211.pdf Restricted Access		2.81 MB	Adobe PDF	View/Open Request a copy

Show simple item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ

ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ

Кафедра інформаційних технологій проектування

Пояснювальна записка
до кваліфікаційної роботи

_______________________________бакалавра_____________________________
(освітньо-кваліфікаційний рівень)

на тему: «Вебсервіс TimeBrix для управління проєктами та операційною
діяльністю підприємств»

Виконав: студент 4 курсу, групи Web-2211
Спеціальність 126 “Інформаційні
системи та технології”
ОП “Web-технології, Web-дизайн”
Атрощенко О.А.
Керівник ______Катаєв Д.С._______
(прізвище та ініціали)
Рецензент Чичужко М.В._
(прізвище та ініціали)

Черкаси – 2026 року

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
(назва вузу)
Факультет ФІТІС Кафедра Інформаційних технологій проєктування
Освітній рівень бакалавр
Спеціальність 126 “Інформаційні системи та технології”
Освітня програма “Web-технології Web-дизайн”
ЗАТВЕРДЖУЮ:
зав.Кафедри Прокопенко Т.О.
“______” __________________2026р.
ЗАВДАННЯ
На кваліфікаційну роботу здобувачці
______________________________________________________________________________
(прізвище, ім’я, по батькові)
1. Тема проекту (роботи) Вебсервіс TimeBrix для управління проєктами та
операційною діяльністю підприємств.
Керівник проекту(роботи) КАТАЄВ Д., к.т.н., ст.в..
Затверджена наказом Черкаського державного технологічного університету № 60/04
від 24.02.26
2. Строк подання студентом роботи 5 червня 2026 р.
3. Вихідні дані до роботи: готовий web-сервіс TimeBrix; backend – NestJS (Node.js);
frontend – React (TypeScript); база даних – PostgreSQL; ORM – Prisma; стан
клієнтської частини – Redux Toolkit; маршрутизація – React Router; оформлення
інтерфейсу – Tailwind CSS і Material UI; інструменти – Swagger, ESLint, Prettier.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить
розробити)
ВСТУП; 1.1 Актуальність; 1.2 Мета та задачі; 1.3 Практичне значення; 1. АНАЛІЗ
ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ; 1.1 Аналіз предметної області
управління проєктами; 1.2 Огляд існуючих систем управління проєктами; 1.3 Аналіз
ринку програмних рішень для управління проєктами; 1.4 Визначення вимог до
вебсервісу TimeBrix; 1.5 Висновки до розділу 1; 2. АНАЛІЗ ВИМОГ,
ОБҐРУНТУВАННЯ ТЕХНІЧНОГО ЗАВДАННЯ ТА ПРОЄКТУВАННЯ
ФУНКЦІОНАЛУ СИСТЕМИ; 2.1 Призначення розроблюваного вебсервісу; 2.2
Функціональні вимоги до вебсервісу; 2.3 Нефункціональні вимоги; 2.4 Вимоги до
безпеки та захисту даних; 2.5 Архітектура та проєктування системи; 3. РОЗРОБКА ТА
ТЕСТУВАННЯ СИСТЕМИ; 3.1 Архітектура та загальна структура вебсервісу
TimeBrix; 3.2 Проєктування та реалізація бази даних; 3.3 Розробка серверної частини
Backend; 3.4 Розробка клієнтської частини вебзастосунку Frontend; 3.5 Реалізація
механізмів автентифікації та безпеки; 3.6 Тестування та перевірка працездатності
системи; ВИСНОВКИ; СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ; ДОДАТКИ.
6. Консультанти з проекту із зазначенням розділів проекту, що їх стосуються

Підпис, дата
Розділ Консультант
Завдання видав, завдання
прийняв

7. Дата видачі завдання 1 березня 2026 р.
Керівник Катаєв Д.С.
(підпис)
Завдання прийняв до виконання ________
(підпис)
Календарний план
Пор. № Назва етапів дипломного проекту Термін Примітка
виконання
етапів проекту
1 Підготовча стадія
1.1 Постановка задачі 14.02.2026 Виконано
1.2 Підготовка завдання 21.02.2026 Виконано
1.3 Погодження завдання 25.02.2026 Виконано
1.4 Затвердження завдання 10.03.2026 Виконано
2 Основна стадія
2.1 Підбір матеріалів 14.03.2026 Виконано
2.2 Аналіз шляхів рішення задачі 28.03.2026 Виконано
2.3 Розрахунок основних параметрів роботи 15.04.2026 Виконано
2.4 Вибір кінцевого варіанту проектного рішення 28.04.2026 Виконано
2.5 Оформлення первісної редакції роботи 09.05.2026 Виконано
3 Заключна стадія
3.1 Узгодження проектних рішень з керівником 16.05.2026 Виконано
3.2 Оформлення пояснювальної записки 18.05.2026 Виконано
3.3 Попередній захист роботи 1.06.2026 Виконано
3.4 Затвердження роботи 6.06.2026 Виконано
3.5 Рецензування роботи 8.06.2023 Виконано
3.6 Захист роботи 9.06.2026
Студент-дипломник ______________________________________________
(підпис) (ПІБ)
Керівник проекту ______________________________________________

АНОТАЦІЯ
До кваліфікаційної роботи бакалавра на тему «Вебсервіс TimeBrix для
управління проєктами та операційною діяльністю підприємств». Виконала
студентка групи Web-2211 Кваліфікаційна робота бакалавра П. І. Б. містить: 50
сторінок, 20 рисунків, 5 таблиц, 30 використаних джерел.
Кваліфікаційна робота присвячена проєктуванню, розробці та тестуванню
вебсервісу TimeBrix для управління проєктами та операційною діяльністю
підприємств.
Актуальність теми. Актуальність роботи зумовлена потребою
підприємств у єдиному цифровому середовищі, яке дозволяє структурувати
проєкти, контролювати виконання задач, розподіляти відповідальність між
учасниками команди, аналізувати виконання робіт та підвищувати прозорість
операційних процесів.
Мета роботи і задачі дослідження. Метою роботи є розробка
функціонального, зручного та масштабованого web-сервісу TimeBrix на базі
сучасного стеку технологій.
Об’єктом роботи є процес цифрового управління проєктами, задачами та
операційною діяльністю організацій. Предметом роботи є архітектура,
функціональні модулі, база даних, механізми безпеки та користувацький
інтерфейс web-сервісу TimeBrix.
Предмет дослідження: серверна та клієнтська частина веб-ресурсу для
керування управління проєктами.
Методи дослідження: в роботі застосовувалися аналізи існуючих
рішень, методи проектування та створення програмних продуктів, патерни
проєктування, аналіз предметної області, порівняльний аналіз аналогів,
моделювання вимог, проєктування бази даних, модульне проєктування backend

і frontend частин, функціональне тестування та аналіз результатів роботи
системи.
Ключові слова: web-сервіс, управління проєктами, управління задачами,
аналітика, NestJS, React, TypeScript, PostgreSQL, Prisma, Docker.

ANNOTATION
The bachelor qualification work is devoted to the design, development and
testing of the TimeBrix web service for project management, task management,
analytics and operational activity tracking for enterprises and organizations. This
bachelor’s thesis focuses on the design, development, and testing of the TimeBrix
web service for managing projects and business operations. The relevance of this
work stems from the need of modern companies for a unified digital environment that
enables project planning, task tracking, team collaboration, accountability, and
analytical monitoring of operational processes. The goal of this work is to develop a
functional, user-friendly, and scalable TimeBrix web service using NestJS, React,
TypeScript, PostgreSQL, Prisma, Docker, and Nginx. The subject of this work is the
process of digitally managing projects, tasks, and operational activities. The subject
of this work is the architecture, functional modules, database, security mechanisms,
and user interface of the TimeBrix web service. Keywords: web service, project
management, task management, NestJS, React, TypeScript, PostgreSQL, Prisma,
Docker, analytics.

ЗМІСТ
ВСТУП .......................................................................................................................................................... 4
РОЗДІЛ 1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ ........................... 7
1.1 Аналіз предметної області управління проєктами ................................................................................ 7
1.2 Огляд існуючих систем управління проєктами ..................................................................................... 9
1.3 Аналіз ринку програмних рішень для управління проєктами ....................................................... 11
1.4 Визначення вимог до вебсервісу TimeBrix ........................................................................................... 12
1.5 Висновки до розділу 1 ................................................................................................................................ 13
РОЗДІЛ 2 АНАЛІЗ ВИМОГ, ОБҐРУНТУВАННЯ ТЕХНІЧНОГО ЗАВДАННЯ ТА
ПРОЄКТУВАННЯ ФУНКЦІОНАЛУ СИСТЕМИ......................................................................... 15
2.1 Призначення розроблюваного вебсервісу ............................................................................................ 15
2.2 Функціональні вимоги до вебсервісу ..................................................................................................... 16
2.3 Нефункціональні вимоги .......................................................................................................................... 19
2.4 Вимоги до безпеки та захисту даних ...................................................................................................... 20
2.5 Архітектура та проєктування системи .................................................................................................. 22
2.6 Висновки до розділу 2 ................................................................................................................................ 23
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ СИСТЕМИ ............................................................... 25
3.1 Архітектура та загальна структура вебсервісу TimeBrix ................................................................. 25
3.2 Проєктування та реалізація бази даних ................................................................................................ 26
3.3 Розробка серверної частини Backend ..................................................................................................... 28
3.4 Розробка клієнтської частини вебзастосунку Frontend .................................................................... 31
3.5 Реалізація механізмів автентифікації та безпеки ............................................................................... 34
3.6 Тестування та перевірка працездатності системи.............................................................................. 36
3.7 Висновки до розділу 3 ................................................................................................................................ 38
ВИСНОВКИ ............................................................................................................................................. 39
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ........................................................................................... 41
ДОДАТОК Б ............................................................................................................................................. 46
ДОДАТОК В ............................................................................................................................................. 68

ЧДТУ 262202.001.ПЗ
Зм. Лист № докумемента Підпис Дата

Розроб. Літ. Лист Листів
Перев. Катаєв Д.С. «Вебсервіс TimeBrix для управління Н 2 56
Реценз.. Чичужко М. В проєктами та операційною діяльністю
озроб. підприємств»
Н.контр. Катаєв Д.С. ЧДТУ 232230.001 ПЗ ФІТІС,
Літ. Лист Листів
Пояснювальна записка
Перев. П ІБ кНа федра ІТП, WEB-2211
Затв. ПрокопенкоТ.О. 1
Перев.
62

Н.контр. Літ. Лист Листів

Затв. ПрокопенкоТ.О.. Н 1
ggg Серверна частина WEB
Реценз.. Ч-рДесТурУсу 2з 3пр2о2д3аж0у.0 01 П З

СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
API - Application Programming Interface, програмний інтерфейс застосунку.
БД - База даних.
CRUD - Create, Read, Update, Delete - базові операції роботи з даними.
DTO - Data Transfer Object, об’єкт передавання даних між шарами системи.
HTTP - HyperText Transfer Protocol, протокол передавання гіпертексту.
JWT JSON Web Token - токен для безпечного передавання ідентифікаційних
даних.
ORM - Object-Relational Mapping технологія відображення об’єктів
застосунку на структури бази даних.
RBAC - Role-Based Access Control керування доступом на основі ролей.
UI - User Interface, користувацький інтерфейс.
UX - User Experience, досвід користувача під час взаємодії з системою.
ПЗ - Програмне забезпечення.

Лист
ЧДТУ 262202.003 ПЗ
3
Зм Арк. № докум. Пiдпис. Дата
нт

ВСТУП
У сучасних умовах стрімкого розвитку інформаційних технологій
управління часом є невід’ємною складовою повсякденної діяльності людини та
організацій. Підприємства дедалі частіше виконують роботу у форматі проєктів,
спринтів, задач і короткострокових операційних доручень. Для ефективного
контролю та координації таких процесів недостатньо використовувати паперові
записи або неформальні домовленості між учасниками команди. Організаціям
необхідне єдине інформаційне середовище, яке дозволяє створювати проєкти,
розподіляти задачі між виконавцями, контролювати строки виконання та
отримувати аналітичну інформацію щодо стану реалізації робіт.
Управління проєктами є окремою професійною областю, що охоплює
планування, організацію, виконання, перевірку і завершення робіт для досягнення
визначених результатів. У стандартах Project Management Institute підкреслюється
необхідність системного підходу до управління результатами, зацікавленими
сторонами, командою, ризиками та цінністю проєкту [1]. Для інформаційних
систем це означає, що програмний продукт має не лише зберігати перелік задач, а
й підтримувати управлінський цикл: від формування цілі до оцінки
результативності виконання.
Розроблений web-сервіс TimeBrix призначений для управління проєктами,
задачами, ведення аналітики та відстеження операційної діяльності підприємств і
організацій. Система може використовуватися різними компаніями: від невеликих
команд до корпорацій, які потребують централізованого інструменту для
координації роботи. Практична цінність цього сервісу полягає у зручному Exele-
типовому інтерфейсі, наявності зручного функціоналу для командної роботи над
проєктами, доволі солідний вибір фільтрів для перевірки створених задач по
проєктам.
Для реалізації TimeBrix використано сучасний стек web-технологій: backend
побудовано на NestJS і Node.js, клієнтську частину реалізовано за допомогою
React та TypeScript, для зберігання даних використано PostgreSQL, а для взаємодії
Лист
ЧДТУ 262202.003 ПЗ
4
Зм Арк. № докум. Пiдпис. Дата
нт

з базою даних застосовано Prisma ORM. Такий набір інструментів відповідає
вимогам до масштабованості, підтримуваності та розділення відповідальності між
компонентами системи.
Актуальність теми також пов’язана з тим, що багато організацій одночасно
використовують кілька розрізнених інструментів: месенджери для обговорення
задач, таблиці для контролю термінів, окремі календарі для планування подій та
зовнішні сервіси для звітності. TimeBrix спрямований на вирішення цієї проблеми
шляхом об’єднання ключових функцій управління проєктами в одному web-
сервісі.
У контексті web-розробки важливою є не лише функціональність, а й якість
програмної архітектури. NestJS позиціонується як фреймворк для створення
ефективних і масштабованих серверних застосунків на Node.js з використанням
TypeScript [7]. React, зі свого боку, використовується для створення інтерактивних
клієнтських інтерфейсів, а офіційна документація React окремо описує підходи до
застосування TypeScript у компонентах [8]. У поєднанні ці технології дають змогу
створити систему, яка має чітко розділені backend і frontend, підтримує
подальший розвиток та спрощує командну роботу над кодовою базою.
Мета та задачі
Метою кваліфікаційної роботи є розробка web-сервісу TimeBrix для
управління проєктами, задачами, ведення аналітики та відстеження операційної
діяльності підприємств і організацій із використанням сучасного стеку web-
технологій.
Для досягнення поставленої мети необхідно виконати такі задачі:
 проаналізувати предметну область управління проєктами, задачами та
операційною діяльністю організацій;
 розглянути існуючі програмні рішення для управління проєктами та
визначити їхні сильні й слабкі сторони;
 спроєктувати структуру бази даних для зберігання інформації про
користувачів, проєкти, задачі, ролі та аналітичні показники;
Лист
ЧДТУ 262202.003 ПЗ
5
Зм Арк. № докум. Пiдпис. Дата
нт

 реалізувати серверну частину з використанням NestJS, Node.js,
PostgreSQL та Prisma;
 реалізувати клієнтську частину web-застосунку з використанням React,
TypeScript, Redux Toolkit, React Router, Tailwind CSS і Material UI;
 реалізувати механізми автентифікації, авторизації та захисту даних;
 провести тестування працездатності системи та оцінити відповідність
реалізованого функціоналу поставленим вимогам.
Обʼєкт.
Об’єктом роботи є процес розробки онлайн-сервісу управління проєктами,
задачами та операційною діяльністю підприємств і організацій, що надає
користувачам, точніше компаніям і організаціям, керувати проєктами та задачами,
командною роботою та створенням аналітики робочих процесів.
Лист
ЧДТУ 262202.003 ПЗ
6
Зм Арк. № докум. Пiдпис. Дата
нт

РОЗДІЛ 1
АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ПОСТАНОВКА ЗАДАЧІ
1.1 Аналіз предметної області управління проєктами
Предметна область управління проєктами охоплює сукупність процесів,
методів, інструментів і ролей, які забезпечують планування, організацію,
виконання, контроль та завершення робіт. Все це здійснюється в першу чергу для
досягнення великих цілей компаній та підприємств. У діяльності підприємств
проєкт зазвичай має визначену мету, обмеження за строками, ресурсами і
бюджетом. Управління задачами це одна з важливіших пунктів, оскільки саме
через задачі відбувається розбиття проєкту на конкретні дії, які ведуть компанії та
підприємства до поставленної мети.
Сучасне управління проєктами не обмежується класичним плануванням
строків. У багатьох організаціях важливими є зручність та швидкість, прозорість,
регулярне оновлення статусів, відображення залежностей між задачами, контроль
завантаженості виконавців та аналітика за результатами роботи. Такі вимоги
особливо актуальні для IT-компаній, маркетингових агентств, сервісних
організацій, проєктних офісів і корпоративних підрозділів, де робота часто
виконується декількома різними командами.
Згідно з підходами PMBOK, управління проєктами розглядається як
діяльність, спрямована на досягнення організаційних результатів і створення
цінності [1]. Це положення є важливим для TimeBrix, оскільки система не
повинна бути лише переліком задач. Вона має підтримувати управлінський
контекст: хто виконує роботу, у якому статусі перебуває задача, які пріоритети
мають роботи, які строки наближаються та які показники свідчать про
ефективність команди.
Гнучкі методології розробки програмного забезпечення, зокрема Agile та
Scrum, сформували додаткові вимоги до сьогоденних інструментів управління.
Agile Manifesto визначає робочий продукт, взаємодію людей і готовність до змін
як ключові цінності [2]. Scrum Guide наголошує на прозорості, перевірці та
адаптації як основних емпіричних принципах [3]. Для web-сервісу TimeBrix це
Лист
ЧДТУ 262202.003 ПЗ
7
Зм Арк. № докум. Пiдпис. Дата
нт

означає необхідність забезпечення актуального, доступного відображення стану
проєктів і задач, зручного інтерфейсу для оновлення даних, а також можливості
швидкої реакції менеджера або команди на зміни.
Управління операційною діяльністю відрізняється від управління окремими
проєктами тим, що воно часто є безперервним. Організація може щоденно
виконувати схожі операції: обробку заявок, підтримку клієнтів, внутрішні запити,
підготовку звітів, контроль SLA, планування ресурсів. Якщо такі процеси не
систематизовані у системі, вони втрачають прозорість. TimeBrix може виступати
інструментом, що поєднує проєктний та операційний підходи: проєкти мають
структуру, задачі мають визначених виконавців, а аналітичний блок дає змогу
оцінювати загальний стан роботи і успіхи компанії.
Типова інформаційна система управління проєктами повинна підтримувати
кілька груп користувачів. Адміністратор відповідає за налаштування системи та
керування користувачами. Менеджер або керівник проєкту створює проєкти,
визначає задачі, призначає виконавців, контролює строки та аналізує показники.
Виконавець працює зі своїми задачами, змінює статуси, залишає коментарі та
додає результати виконання. Керівник організації може використовувати
аналітичні дані для прийняття управлінських рішень.
Важливою проблемою існуючих систем є складність швидкого введення та
редагування даних. У багатьох сервісах створення задачі вимагає відкриття
окремих форм, заповнення великої кількості полів та переходів між екранами, що
уповільнює робочий процес і підвищує ймовірність помилок. Якщо система
управління проєктами є занадто складною, команда може частково або повністю
ігнорувати її, повертаючись до неформальних каналів комунікації. Для вирішення
цієї проблеми у системі TimeBrix реалізовано підхід, заснований на Excel-
подібній навігації. Інтерфейс головної сторінки представлено у вигляді таблиці,
де користувач може швидко створювати та редагувати задачі без переходу на
окремі сторінки. Це дозволяє вводити дані послідовно, структуровано та з
мінімальною кількістю дій.
Лист
ЧДТУ 262202.003 ПЗ
8
Зм Арк. № докум. Пiдпис. Дата
нт

Додатково в інтерфейсі передбачено систему фільтрів і сортування, яка дає
змогу оперативно знаходити задачі, перевіряти їх коректність, виявляти помилки
та аналізувати стан виконання. Такий підхід підвищує швидкість роботи
користувачів, зменшує когнітивне навантаження та забезпечує більш ефективне
управління задачами. Для досягнення цього у клієнтській частині застосовуються
React, TypeScript, Tailwind CSS і Material UI, що дозволяє створити
структурований, адаптивний та візуально узгоджений інтерфейс [8], [16], [17].
Рисунок 1.1 – скрін головної сторінки з web-сервісу TimeBrix

1.2 Огляд існуючих систем управління проєктами
Для визначення вимог до TimeBrix доцільно розглянути існуючі системи
управління проєктами, які використовуються на ринку. Аналіз аналогів дозволяє
зрозуміти, які функції є стандартними для користувачів, які підходи вважаються
зручними, а які недоліки можуть бути враховані при розробці власного сервісу.
Одним із найвідоміших рішень є Jira. В офіційних матеріалах Atlassian Jira
описується як інструмент для планування, відстеження та виконання проєктів
різними командами [18]. Сильними сторонами Jira є гнучке налаштування
Лист
ЧДТУ 262202.003 ПЗ
9
Зм Арк. № докум. Пiдпис. Дата
нт

workflow, підтримка Scrum і Kanban, велика кількість інтеграцій, потужні
можливості звітності та використання в корпоративному середовищі. Водночас
для невеликих команд Jira може бути складною у початковому налаштуванні, а
надлишкова кількість параметрів іноді ускладнює швидке впровадження. Також у
Jira доволі високі ціни ліцензії, що робить її достатньо витратною для бюджету
невеликих проєктів.
Іншим поширеним інструментом є Trello, який використовує дошки, списки
та картки для візуального управління задачами. Офіційний сайт Trello наголошує
на можливості організовувати задачі, процеси та командну роботу за допомогою
візуального підходу [19]. Перевагою Trello є простота, інтуїтивність і низький
поріг входу. Недоліком може бути обмеженість аналітики та складність
використання для великих структурованих проєктів без додаткових інтеграцій.
Asana позиціонується як інструмент для організації роботи команд, проєктів
і задач у розподіленому середовищі [20]. Система надає списки задач, календарі,
таймлайни, форми, цілі, автоматизацію та командну взаємодію. Її сильна сторона
полягає у поєднанні управління задачами й організаційної прозорості. Водночас
для окремих компаній певні функції можуть бути надлишковими або вимагати
платних тарифів.
ClickUp є багатофункціональною платформою, яка пропонує управління
задачами, документами, цілями, dashboards та автоматизацією [21]. Перевагою
ClickUp є широка функціональність і можливість налаштування робочих
просторів. Проте велика кількість можливостей може ускладнювати освоєння
системи для нових користувачів.
На основі огляду аналогів можна зробити висновок, що користувачі
очікують від системи управління проєктами таких базових можливостей:
створення проєктів, створення та призначення задач, статуси задач, пріоритети,
коментарі, ролі користувачів, фільтрація, пошук, аналітичні панелі, контроль
строків та адаптивний інтерфейс. TimeBrix повинен реалізувати ці ключові
можливості, але зберегти логічну структуру та зручність використання.
Лист
ЧДТУ 262202.003 ПЗ
10
Зм Арк. № докум. Пiдпис. Дата
нт

Таблиця 1.1 – Порівняння існуючих систем управління проєктами
Критерій Jira Trello Asana ClickUp TimeBrix
Основний Гнучкі Візуальні Командна Універсальна Проєкти,
підхід workflow, дошки робота і задачі платформа задачі,
Scrum/Kanban аналітика
Складність Висока Низька Середня Середня/висока Середня
впровадження
Аналітика Розвинена Обмежена Розвинена Розвинена Передбачена у
системі
Гнучкість Висока Середня Висока Висока Орієнтована на
налаштувань потреби
компаній
Цільова IT та Малі команди Бізнес- Різні типи Підприємства
аудиторія корпоративні команди команд та організації
команди

1.3 Аналіз ринку програмних рішень для управління проєктами
Ринок програмних рішень для управління проєктами характеризується
високою конкуренцією та постійним розширенням та покращенням
функціональності продуктів. Сучасні системи вже не обмежуються списками
задач: вони пропонують dashboards, автоматизацію, інтеграції з календарями,
репозиторіями, месенджерами, CRM-системами, аналітику продуктивності та
інструменти управління ресурсами.
Значна частина популярних рішень працює за SaaS-моделлю. Це зручно для
швидкого старту, однак не всі організації готові зберігати внутрішні дані у
зовнішніх сервісах. Для підприємств, які мають підвищені вимоги до контролю
даних, важливим є варіант розгортання у власній інфраструктурі або приватному
хмарному середовищі. Використання Docker у TimeBrix створює основу для
такого сценарію, оскільки контейнеризація спрощує перенесення та відтворення
середовища [12].
Іншою тенденцією є зростання ролі аналітики. Керівникам потрібні не лише
списки задач, а й агреговані показники, цифри: кількість завершених задач,
Лист
ЧДТУ 262202.003 ПЗ
11
Зм Арк. № докум. Пiдпис. Дата
нт

розподіл за статусами, навантаження виконавців в компанії, прострочені задачі,
активність у проєктах, динаміка виконання. Саме тому TimeBrix включає функції
ведення аналітики та відстеження операційної діяльності.
Для конкурентоспроможності системи управління проєктами необхідно
забезпечити баланс між функціональністю та простотою. Надмірно складні
системи можуть бути ефективними для великих корпорацій, але створюють
бар’єри для невеликих команд. Надто прості системи зручні на старті, але не
забезпечують достатньої аналітики та контролю для зростаючих організацій.
TimeBrix орієнтований на проміжну позицію: зрозумілий інтерфейс і водночас
наявність структурованих даних для управлінського аналізу.
1.4 Визначення вимог до вебсервісу TimeBrix
На основі аналізу предметної області та огляду аналогів можна сформувати
загальні вимоги до web-сервісу TimeBrix. Система повинна забезпечувати
реєстрацію та автентифікацію користувачів, розмежування доступу відповідно до
ролей, створення організаційних просторів або команд, створення проєктів,
формування задач, призначення відповідальних осіб, зміну статусів, фільтрацію,
пошук та перегляд аналітичних показників, і, перш за все, зручний та зрозумілий
інтерфейс для користувачів.
Функціональні вимоги повинні бути пов’язані з реальними сценаріями
використання. Наприклад, керівник проєкту повинен мати можливість створити
проєкт, додати учасників, сформувати перелік задач, визначити строки та
пріоритети. Виконавець повинен бачити власні задачі, оновлювати статуси,
залишати коментарі та переглядати деталі задачі. Адміністратор повинен
керувати користувачами, ролями та загальними налаштуваннями системи.
Нефункціональні вимоги мають забезпечувати якість роботи системи.
TimeBrix повинен бути продуктивним, підтримуваним, масштабованим,
безпечним та зручним для користувача. Для цього використовуються React і
Redux Toolkit для керованого стану клієнтської частини [14], React Router для
Лист
ЧДТУ 262202.003 ПЗ
12
Зм Арк. № докум. Пiдпис. Дата
нт

маршрутизації [15], NestJS для модульної серверної архітектури [7], PostgreSQL і
Prisma для надійної роботи з даними [10], [11].
Вимоги до безпеки мають враховувати типові ризики web-застосунків.
OWASP Top 10 визначає найбільш критичні категорії ризиків для web-
застосунків, серед яких порушення контролю доступу, криптографічні помилки,
ін’єкції та помилки ідентифікації й автентифікації [5]. У TimeBrix ці ризики
враховуються через застосування автентифікації, перевірки ролей, валідації
вхідних даних, безпечної роботи з паролями та обмеження доступу до ресурсів.
Окремою вимогою є можливість подальшого розвитку. Система повинна
мати архітектуру, яка дозволяє додавати нові модулі без повного переписування
наявного коду. Наприклад, у майбутньому до TimeBrix можуть бути додані
модулі календаря, інтеграції з месенджерами, імпорт/експорт даних, розширена
аналітика або інтеграція з корпоративними системами.
Таблиця 1.2 – Узагальнені вимоги до TimeBrix
Група вимог Зміст вимог Практичне призначення
Функціональні Проєкти, задачі, користувачі, Забезпечення основних
ролі, статуси, аналітика сценаріїв управління
Нефункціональні Продуктивність, Стабільна експлуатація системи
масштабованість, зручність,
підтримуваність
Безпекові Автентифікація, авторизація, Запобігання несанкціонованому
валідація, захист даних доступу
Інфраструктурні Docker, Nginx, змінні Спрощення розгортання та
середовища, API-документація супроводу

1.5 Висновки до розділу 1
У першому розділі було проаналізовано предметну область управління
проєктами, задачами та операційною діяльністю організацій. Встановлено, що
сучасні підприємства потребують інструментів, які забезпечують централізоване
планування, контроль виконання, командну взаємодію та аналітичну підтримку
управлінських рішень.
Лист
ЧДТУ 262202.003 ПЗ
13
Зм Арк. № докум. Пiдпис. Дата
нт

Розглянуто існуючі рішення Jira, Trello, Asana та ClickUp. Визначено, що
кожне з них має сильні сторони, однак також має обмеження, пов’язані зі
складністю впровадження, вартістю, надмірністю функцій або недостатньою
аналітикою. Це підтверджує доцільність розробки web-сервісу TimeBrix як
зручної системи, орієнтованої на управління проєктами, задачами та операційною
діяльністю підприємств.
На основі аналізу сформовано базові вимоги до TimeBrix: підтримка
користувачів і ролей, управління проєктами, управління задачами, статуси,
пріоритети, аналітика, безпека, масштабованість та зручний інтерфейс. Отримані
результати є підґрунтям для подальшого аналізу вимог, обґрунтування технічного
завдання та проєктування функціоналу системи у другому розділі.

Лист
ЧДТУ 262202.003 ПЗ
14
Зм Арк. № докум. Пiдпис. Дата
нт

РОЗДІЛ 2
АНАЛІЗ ВИМОГ, ОБҐРУНТУВАННЯ ТЕХНІЧНОГО ЗАВДАННЯ ТА
ПРОЄКТУВАННЯ ФУНКЦІОНАЛУ СИСТЕМИ
2.1 Призначення розроблюваного вебсервісу
Web-сервіс TimeBrix призначений для цифрового управління проєктами,
задачами, командною взаємодією та аналітикою операційної діяльності
підприємств і організацій. Його основна задача полягає у створенні єдиного
інформаційного середовища, у якому користувачі можуть планувати роботу,
контролювати виконання, фіксувати відповідальність, отримувати узагальнені
дані про стан діяльності, і все це повинно бути зручно, швидко і доступно.
Цільовими користувачами системи є керівники проєктів, менеджери
команд, виконавці задач, адміністратори системи та керівники організаційних
підрозділів. Кожна група користувачів має власні потреби. Менеджер потребує
інструментів планування і контролю, виконавець — зручного переліку актуальних
задач, адміністратор — механізмів керування доступом, а керівник —
аналітичних показників.
Система призначена для використання у web-браузері, тому не потребує
встановлення окремого клієнтського програмного забезпечення на робочі станції
користувачів. Такий підхід відповідає сучасній моделі web-сервісів, де основна
логіка розподілена між серверною частиною, клієнтським застосунком і базою
даних.
TimeBrix має забезпечувати не лише збереження інформації, а й підтримку
повного робочого циклу: створення проєкту, формування задач, призначення
виконавців, контроль статусів, перегляд аналітики, оцінку операційної активності
та подальше вдосконалення процесів. Для цього система повинна мати модульну
архітектуру, у якій окремі компоненти відповідають за автентифікацію,
користувачів, проєкти, задачі, аналітику та API.
Лист
ЧДТУ 262202.003 ПЗ
15
Зм Арк. № докум. Пiдпис. Дата
нт

2.2 Функціональні вимоги до вебсервісу
Функціональні вимоги визначають, які дії має виконувати система та які
можливості повинні бути доступні користувачам. Для TimeBrix функціональні
вимоги сформовано з урахуванням аналізу предметної області та існуючих
систем.
Першою групою функціональних вимог є робота з користувачами. Система
повинна підтримувати реєстрацію або створення користувачів адміністратором,
автентифікацію, вихід із системи, зберігання профілю користувача, а також
розмежування доступу за ролями. Для захисту облікових записів паролі не
повинні зберігатися у відкритому вигляді.
Друга група вимог стосується управління проєктами. Користувач із
відповідними правами повинен мати можливість створювати проєкти, редагувати
їх основні параметри, призначати учасників, переглядати список проєктів,
фільтрувати їх за статусом і відкривати детальну сторінку проєкту. Проєкт
повинен мати назву, опис, строки, статус, відповідального користувача та перелік
пов’язаних задач.
Третя група вимог пов’язана з управлінням задачами. Система повинна
дозволяти створювати задачі в межах проєкту, задавати назву, опис, пріоритет,
статус, дедлайн, відповідального виконавця та додаткові атрибути. Все це повино
робитися швидко і зручно, з спроміжними інструментами для редагування.
Користувачі повинні мати можливість змінювати статус задачі, переглядати
історію, додавати коментарі або уточнення, а також фільтрувати задачі за
проєктом або виконавцем.
Четверта група вимог стосується аналітики. TimeBrix повинен відображати
узагальнені показники: кількість активних проєктів, навантаження виконавців та
динаміку виконання. Аналітична інформація повинна подаватися у зрозумілому
вигляді через dashboard, таблиці або графічні елементи.
П’ята група вимог пов’язана з API та документацією. Оскільки backend
реалізовано на NestJS, доцільно документувати REST API за допомогою Swagger.
Лист
ЧДТУ 262202.003 ПЗ
16
Зм Арк. № докум. Пiдпис. Дата
нт

OpenAPI Specification дозволяє стандартизовано описувати HTTP API, що
спрощує тестування та взаємодію frontend із backend [6].
Шоста група вимог стосується інтерфейсу. Клієнтська частина повинна бути
адаптивною, зрозумілою, візуально узгодженою та зручною для щоденного
використання. React дозволяє реалізувати зручний інтерфейс користувача за
допомогою компонентного підходу. React Router забезпечує маршрутизацію між
сторінками [15], Redux Toolkit використовується для організації стану клієнтської
частини [14], а Material UI і Tailwind CSS дають змогу стилізувати сторінки та
компоненти інтерфейсу [16], [17].
Таблиця 2.1 – Функціональні вимоги до TimeBrix
№ Вимога Опис реалізації
1 Автентифікація користувачів Вхід у систему за обліковими
даними та отримання токена
доступу
2 Розмежування ролей Обмеження дій користувачів
залежно від ролі
3 Управління проєктами Створення, редагування,
перегляд і фільтрація проєктів
4 Управління задачами Створення задач, призначення
виконавців, зміна статусів
5 Аналітика Відображення статистики за
проєктами, задачами та
активністю
6 API-документація Опис backend-методів через
Swagger/OpenAPI

Лист
ЧДТУ 262202.003 ПЗ
17
Зм Арк. № докум. Пiдпис. Дата
нт

Рисунок 2.1 – Головна сторінка перегляду та редагування задач у TimeBrix

Рисунок 2.2 – Сторінка перегляду задач у особистому графіку TimeBrix

Лист
ЧДТУ 262202.003 ПЗ
18
Зм Арк. № докум. Пiдпис. Дата
нт

2.3 Нефункціональні вимоги
Нефункціональні вимоги визначають якісні характеристики системи. Вони
не описують конкретну дію користувача, але визначають, наскільки добре
система виконує свої функції. Для TimeBrix ключовими нефункціональними
вимогами є продуктивність, масштабованість, надійність, зручність використання,
підтримуваність та сумісність із сучасними web-браузерами.
Вимога продуктивності означає, що система повинна швидко обробляти
запити користувачів і забезпечувати прийнятний час завантаження сторінок.
Backend має ефективно працювати з базою даних, не виконувати зайвих запитів та
використовувати оптимізовані механізми вибірки даних. Prisma ORM забезпечує
типобезпечну взаємодію з PostgreSQL і дозволяє описувати структуру даних на
рівні схеми [11].
Масштабованість означає можливість системи працювати зі зростаючою
кількістю користувачів, проєктів і задач. Застосування Docker дозволяє ізолювати
компоненти системи та спростити розгортання в різних середовищах [12]. Nginx
може використовуватися як reverse proxy для маршрутизації запитів,
обслуговування статичних ресурсів і подальшого масштабування web-
інфраструктури.
Надійність системи полягає у стабільній роботі без втрати даних. Для цього
база даних повинна мати коректно визначені зв’язки, обмеження цілісності та
транзакційність. PostgreSQL надає широкі можливості для роботи з реляційними
даними, індексами, транзакціями та паралельним доступом [10].
Зручність використання є критичною для системи щоденного застосування.
Інтерфейс TimeBrix повинен дозволяти користувачам швидко створювати та
редагувати задачі, розуміти поточний стан роботи і виконувати основні дії без
зайвих переходів. Використання компонентного підходу React сприяє побудові
повторно використовуваних елементів інтерфейсу [8].
Підтримуваність програмного коду забезпечується структурованою
архітектурою, використанням TypeScript, ESLint і Prettier. TypeScript допомагає
Лист
ЧДТУ 262202.003 ПЗ
19
Зм Арк. № докум. Пiдпис. Дата
нт

явно описувати типи даних і зменшувати кількість помилок на етапі розробки [9].
ESLint використовується для виявлення проблем у JavaScript/TypeScript-коді [22],
а Prettier забезпечує єдиний стиль форматування [23].
Таблиця 2.2 – Нефункціональні вимоги
Критерій Вимога Засоби забезпечення
Продуктивність Швидка обробка запитів і Оптимізація API, Prisma,
завантаження сторінок індекси БД
Масштабованість Можливість збільшення Docker, Nginx, модульна
навантаження архітектура
Надійність Збереження цілісності даних PostgreSQL, транзакції,
обмеження
Підтримуваність Єдиний стиль коду та TypeScript, ESLint, Prettier
модульність
Зручність Простий та адаптивний React, Tailwind CSS, Material UI
інтерфейс

2.4 Вимоги до безпеки та захисту даних
Оскільки TimeBrix працює з даними організацій, користувачів, проєктів і
задач, безпека є однією з ключових вимог. Дані про внутрішні процеси компаній
можуть мати конфіденційний характер, тому система повинна запобігати
несанкціонованому доступу, неправильній зміні інформації та витоку облікових
даних.
Основною вимогою є автентифікація користувачів. Користувач повинен
отримувати доступ до системи лише після підтвердження особи за допомогою
логіна та пароля або іншого механізму, передбаченого реалізацією. У web-
сервісах поширеним рішенням є використання JWT-токенів, які дозволяють
передавати інформацію про автентифікованого користувача між клієнтом і
сервером.
Другою вимогою є авторизація. Навіть після входу в систему користувач не
повинен мати доступ до всіх ресурсів. Дії мають бути обмежені відповідно до
Лист
ЧДТУ 262202.003 ПЗ
20
Зм Арк. № докум. Пiдпис. Дата
нт

ролі: адміністратор керує користувачами, менеджер керує проєктами, виконавець
працює з призначеними задачами. Такий підхід відповідає моделі RBAC.
Третьою вимогою є захист паролів. Паролі не повинні зберігатися у
відкритому вигляді. Доцільно використовувати криптографічне хешування з
сіллю. Це зменшує ризики у випадку компрометації бази даних.
Четвертою вимогою є валідація вхідних даних. OWASP Top 10 відносить
ін’єкції та порушення контролю доступу до критичних ризиків web-застосунків
[5]. Тому backend повинен перевіряти структуру, типи та допустимість даних, що
надходять від клієнта. Використання DTO, pipes та validation-механізмів NestJS
дозволяє централізувати перевірку запитів.
П’ятою вимогою є захищена передача даних. У реальному середовищі
система повинна працювати через HTTPS, а конфігураційні значення, секретні
ключі та параметри підключення до бази даних мають зберігатися у змінних
середовища, а не у вихідному коді.
Окрему увагу необхідно приділити доступу до API. Swagger-документація
має бути корисною для розробників і тестувальників, але у продуктивному
середовищі доступ до неї може бути обмежений. OpenAPI дає змогу
формалізувати опис API, проте безпекова політика має визначати, хто може
переглядати таку документацію [6].
Таблиця 2.3 – Вимоги безпеки
Вимога Ризик, що зменшується Реалізація
Автентифікація Несанкціонований доступ JWT, перевірка облікових даних
Авторизація Доступ до чужих ресурсів RBAC, guards, ролі користувачів
Хешування паролів Компрометація паролів bcrypt або аналогічний алгоритм
Валідація даних Ін’єкції, некоректні запити DTO, validation pipes
HTTPS Перехоплення трафіку TLS-сертифікат у production-
середовищі

Лист
ЧДТУ 262202.003 ПЗ
21
Зм Арк. № докум. Пiдпис. Дата
нт

2.5 Архітектура та проєктування системи
Архітектура TimeBrix побудована як web-система з розділенням клієнтської
та серверної частин. Клієнтська частина відповідає за відображення інтерфейсу,
маршрутизацію, взаємодію з користувачем та надсилання HTTP-запитів до
backend. Серверна частина відповідає за бізнес-логіку, автентифікацію,
авторизацію, обробку запитів, взаємодію з базою даних і формування відповідей
API.
Backend реалізується на NestJS. Згідно з офіційною документацією, NestJS
використовує TypeScript і підтримує модульний підхід, який поєднує принципи
об’єктно-орієнтованого, функціонального та реактивного програмування [7]. У
TimeBrix це дозволяє виділяти окремі модулі, наприклад AuthModule,
UsersModule, ProjectsModule, TasksModule, AnalyticsModule.
Frontend реалізується на React із використанням TypeScript. React
забезпечує компонентний підхід до побудови інтерфейсу [8], а TypeScript додає
статичну типізацію, що підвищує передбачуваність коду [9]. Redux Toolkit
застосовується для роботи зі станом клієнтської частини [14], а React Router —
для організації сторінок і маршрутизації [15].
База даних PostgreSQL зберігає основні сутності системи: користувачів,
ролі, проєкти, задачі, статуси, коментарі, учасників проєктів та аналітичні дані.
Prisma ORM використовується як проміжний рівень між кодом backend і базою
даних, що спрощує виконання запитів та підтримує типобезпечність доступу до
даних [11].
Інфраструктура системи базується на Docker та Nginx. Docker
використовується для контейнеризації компонентів системи, що дозволяє
запускати backend, frontend і базу даних в узгодженому середовищі [12]. Nginx
може виконувати роль reverse proxy, який приймає зовнішні запити й
перенаправляє їх до відповідного сервісу.
Лист
ЧДТУ 262202.003 ПЗ
22
Зм Арк. № докум. Пiдпис. Дата
нт

Проєктування системи передбачає розділення на логічні шари: presentation
layer, application layer, business logic layer, data access layer та database layer. Таке
розділення спрощує тестування, підтримку й подальший розвиток системи.

Рисунок 2.3 – Архітектурна схема web-сервісу TimeBrix
2.6 Висновки до розділу 2
У другому розділі визначено призначення web-сервісу TimeBrix, його
основні групи користувачів та сценарії застосування. Сформовано функціональні
вимоги, які охоплюють автентифікацію, керування користувачами, проєктами,
задачами, ролями та аналітикою.
Визначено нефункціональні вимоги до продуктивності, масштабованості,
надійності, зручності використання та підтримуваності. Обґрунтовано
застосування NestJS, React, TypeScript, PostgreSQL, Prisma, Docker, Nginx, Redux
Toolkit, React Router, Tailwind CSS, Material UI, Swagger, ESLint і Prettier.
Лист
ЧДТУ 262202.003 ПЗ
23
Зм Арк. № докум. Пiдпис. Дата
нт

Окремо сформовано вимоги до безпеки та захисту даних, зокрема
автентифікацію, авторизацію, хешування паролів, валідацію даних та обмеження
доступу до ресурсів. Запропонована архітектура створює основу для реалізації
системи у третьому розділі.

Лист
ЧДТУ 262202.003 ПЗ
24
Зм Арк. № докум. Пiдпис. Дата
нт

РОЗДІЛ 3
РОЗРОБКА ТА ТЕСТУВАННЯ СИСТЕМИ
3.1 Архітектура та загальна структура вебсервісу TimeBrix
Розробка TimeBrix виконана відповідно до архітектури, визначеної у
другому розділі. Система складається з клієнтської частини, серверної частини,
бази даних та інфраструктурного шару. Такий підхід забезпечує розділення
відповідальності між компонентами та спрощує підтримку проєкту.
Серверна частина побудована на NestJS. Основна структура backend
включає модулі, контролери, сервіси, DTO, guards, decorators, PrismaService та
конфігураційні файли. Контролери приймають HTTP-запити, сервіси реалізують
бізнес-логіку, DTO визначають структуру даних, guards перевіряють доступ, а
PrismaService забезпечує взаємодію з базою даних.
Клієнтська частина побудована на React і TypeScript. Вона включає
сторінки, компоненти, маршрути, slices Redux Toolkit, API-клієнти, стилі та
допоміжні функції. Така структура дозволяє повторно використовувати
компоненти інтерфейсу, ізолювати логіку роботи зі станом та спростити навігацію
між сторінками.
Інфраструктурний рівень включає Docker-конфігурацію для запуску
компонентів системи та Nginx для маршрутизації запитів. У процесі розгортання
backend, frontend та PostgreSQL можуть запускатися як окремі контейнери. Це
дозволяє відтворювати однакове середовище на різних комп’ютерах і серверах.
Загальна структура TimeBrix відповідає принципам підтримуваності: кожен
модуль має власну відповідальність, а взаємодія між frontend і backend
відбувається через API. Для перевірки API використовується Swagger, що
відповідає практиці документування HTTP API через OpenAPI [6].

Лист
ЧДТУ 262202.003 ПЗ
25
Зм Арк. № докум. Пiдпис. Дата
нт

Рисунок 3.1 – Структура проєкту TimeBrix

3.2 Проєктування та реалізація бази даних
База даних TimeBrix реалізована на PostgreSQL. Вибір PostgreSQL
обґрунтований підтримкою реляційної моделі, транзакцій, індексів, зовнішніх
ключів і широких можливостей оптимізації запитів [10]. Для системи управління
проєктами реляційна модель є доцільною, оскільки основні сутності мають чіткі
зв’язки: користувачі беруть участь у проєктах, проєкти містять задачі, задачі
мають статуси, пріоритети та виконавців.
Основними сутностями бази даних є User, Role, Project, Task, TasksRaw,
Client, TimeInterval, Teg і Vacation. Сутність User зберігає інформацію про
користувачів системи. Сутність Role або рольове поле визначає рівень доступу.
Project описує проєкти, Task — задачі, TasksRaw — сирі, невідредаговані задачі за
день, Client – клієнти, TimeInterval - час по задачі, Teg - теги задач.
Зв’язок між користувачами та проєктами у вебсервісі TimeBrix реалізований
за принципом many-to-many через проміжну таблицю Prisma _ProjectToUser. Це
Лист
ЧДТУ 262202.003 ПЗ
26
Зм Арк. № докум. Пiдпис. Дата
нт

дозволяє одному користувачу брати участь у декількох проєктах одночасно, а
одному проєкту - мати багатьох учасників. Кожен проєкт має власника (ownerId),
який відповідає за його створення та адміністрування. Також проєкт може бути
пов’язаний із клієнтом через поле clientId, що дає змогу організовувати роботу з
різними замовниками. Для забезпечення унікальності даних реалізовано
обмеження, за яким один власник не може створити два проєкти з однаковою
назвою.
Сутність Task використовується для зберігання задач, що належать певному
проєкту. Кожна задача містить інформацію про автора (ownerId) та виконавця
(assignedTo). У разі видалення користувача, призначеного виконавцем задачі,
значення assignedTo автоматично встановлюється в NULL, що дозволяє зберегти
цілісність даних. Для інтеграції із зовнішніми системами використовується поле
externalId, яке є унікальним і застосовується для механізму upsert імпортованих
задач. Додатково задачі можуть містити теги через зв’язок many-to-many між
таблицями Task і Tag.
Для обліку витраченого часу використовується таблиця TimeInterval, яка
пов’язана із задачею через taskId. Поточна реалізація передбачає, що одна задача
може мати лише один часовий інтервал. Також система підтримує модуль
керування відпустками та лікарняними через таблицю Vacation, де зберігається
інформація про стан заявки (VacationState) та тип відпустки (VacationReason).
Prisma ORM використовується для опису структури бази даних та генерації
типобезпечного клієнта доступу до PostgreSQL у середовищі Node.js.
Використання Prisma ORM є важливим для вебсервісу TimeBrix, оскільки
дозволяє зменшити кількість помилок під час роботи з SQL-запитами, забезпечує
узгодженість між структурою бази даних і TypeScript-кодом backend, а також
спрощує підтримку та масштабування системи.

Лист
ЧДТУ 262202.003 ПЗ
27
Зм Арк. № докум. Пiдпис. Дата
нт

Рисунок 3.2 – ER-діаграма бази даних TimeBrix

3.3 Розробка серверної частини Backend
Серверна частина вебсервісу TimeBrix реалізована з використанням
фреймворку NestJS. Даний фреймворк було обрано завдяки його модульній
архітектурі, підтримці TypeScript, зручним засобам створення REST API та
можливості використання decorators, guards, pipes і interceptors. NestJS офіційно
позиціонується як фреймворк для створення ефективних, масштабованих і
підтримуваних серверних застосунків на платформі Node.js [7]. Використання
NestJS дозволяє структурувати код відповідно до сучасних принципів розробки
backend-систем та забезпечує високу розширюваність проєкту.
Архітектура серверної частини побудована за модульним принципом.
Кореневим модулем є AppModule, який об’єднує всі інші функціональні модулі
системи. Для реалізації основних функцій вебсервісу створено окремі модулі,
кожен з яких відповідає за певну бізнес-логіку.
Лист
ЧДТУ 262202.003 ПЗ
28
Зм Арк. № докум. Пiдпис. Дата
нт

Модуль AuthModule реалізує механізми автентифікації та авторизації
користувачів. Він забезпечує реєстрацію, вхід у систему, генерацію JWT-токенів,
підтримку Google OAuth, а також використання guards і стратегій перевірки
доступу. Завдяки цьому система підтримує безпечний механізм роботи з
обліковими записами користувачів. UsersModule відповідає за керування
користувачами системи, їх профілями та ролями. У межах цього модуля
реалізовано створення, редагування та пошук користувачів, а також управління
ролями admin і user.
ProjectsModule забезпечує роботу з проєктами. Модуль реалізує CRUD-
операції для створення, редагування, видалення та отримання проєктів, підтримує
зв’язок проєкту з клієнтом і механізм додавання учасників до проєкту. Також
передбачено перевірку прав доступу власника проєкту та його учасників.
TasksModule є одним із ключових модулів системи та відповідає за
управління задачами. У цьому модулі реалізовано створення та редагування задач,
призначення виконавців, роботу з тегами, часовими інтервалами та підтримку
імпорту задач через externalId. Додатково реалізовано механізм upsert, який
дозволяє оновлювати вже існуючі задачі або створювати нові на основі зовнішніх
даних.
Для підтримки категоризації задач використовується TagsModule, який
забезпечує створення та прив’язку тегів до задач. VacationsModule реалізує
систему заявок на відпустки та лікарняні, включаючи зміну статусів pending,
approved і rejected, а також збереження причин відсутності користувача.
Модуль ClientModule відповідає за роботу з клієнтами, до яких можуть бути
прив’язані проєкти. Для збереження сирих імпортованих даних використовується
RawTasksModule, який зберігає JSON-структури задач за користувачем і датою.
Це дозволяє реалізувати подальшу обробку або повторний імпорт інформації.
Для формування статистики та аналітики реалізовано ReportsModule, який
агрегує інформацію про задачі, часові інтервали, користувачів і проєкти.
Лист
ЧДТУ 262202.003 ПЗ
29
Зм Арк. № докум. Пiдпис. Дата
нт

Отримані дані використовуються для побудови dashboard та формування звітів за
визначений період часу.
Окремо у системі використовується MailModule, який забезпечує
надсилання електронних листів. Зокрема, реалізовано шаблони привітальних
повідомлень та повідомлень щодо прийняття або відхилення заявок на відпустку.
Для роботи з конфігурацією застосунку використовується ConfigModule,
який забезпечує централізоване зберігання змінних середовища, налаштування
CORS та інших параметрів системи. Доступ до бази даних реалізовано через
PrismaService, який використовується як provider у модулях NestJS для взаємодії з
PostgreSQL через Prisma ORM.
Контролери backend-програми приймають HTTP-запити від клієнтської
частини та передають їх у відповідні сервіси. Наприклад, ProjectsController
містить методи створення проєкту, отримання списку проєктів, оновлення
параметрів і видалення проєкту. TasksController реалізує створення задачі, зміну
статусу, отримання задач за проєктом або виконавцем.
Основна бізнес-логіка системи реалізована у сервісах. Наприклад, під час
створення задачі система перевіряє існування проєкту, права доступу
користувача, коректність призначеного виконавця та валідність вхідних даних.
Лише після успішного проходження перевірок інформація зберігається у базі
даних. Такий підхід дозволяє уникнути розміщення складної логіки
безпосередньо у контролерах і спрощує підтримку коду.
Для перевірки коректності вхідних даних використовуються DTO (Data
Transfer Object). DTO визначають структуру запитів, обов’язкові поля та
допустимі типи даних. Це забезпечує додатковий рівень безпеки та стабільності
системи, оскільки некоректні або неповні дані не потрапляють у бізнес-логіку чи
базу даних.
Документування API реалізовано за допомогою Swagger. OpenAPI
Specification визначає стандарт опису HTTP API, який дозволяє розробникам і
програмам взаємодіяти із сервісом через єдиний формат документації [6]. У
Лист
ЧДТУ 262202.003 ПЗ
30
Зм Арк. № докум. Пiдпис. Дата
нт

TimeBrix Swagger використовується для тестування backend-методів, формування
технічної документації та узгодження контрактів між frontend і backend частинами
системи.

Рисунок 3.3 – Swagger-документація API TimeBrix

3.4 Розробка клієнтської частини вебзастосунку Frontend
Клієнтська частина TimeBrix реалізована на React із використанням
TypeScript. Основна задача frontend полягає у наданні користувачу зручного
інтерфейсу для роботи з проєктами, задачами, dashboard та налаштуваннями.
React забезпечує компонентний підхід до розробки інтерфейсу [8], а TypeScript
підвищує надійність коду через типізацію [9].
Використання TypeScript підвищує надійність коду завдяки статичній
типізації, зменшує кількість помилок під час розробки та полегшує інтеграцію з
backend API [9]. Для збірки та запуску застосунку використовується Vite, який
забезпечує швидку компіляцію та оптимізацію frontend-застосунку.
Лист
ЧДТУ 262202.003 ПЗ
31
Зм Арк. № докум. Пiдпис. Дата
нт

Архітектура frontend-проєкту побудована за feature-based підходом, при
якому окремі модулі відповідають за конкретну функціональність системи. У
структурі застосунку виділено модулі авторизації, задач, проєктів, таблиці часу,
відпусток, користувачів, аналітики та адміністративної частини. Такий підхід
спрощує масштабування системи, підтримку коду та повторне використання
компонентів.
Структура frontend включає сторінки, компоненти, маршрути, сервіси для
API-запитів, сховище стану та стилі. Основними сторінками застосунку є сторінка
авторизації, список проєктів, детальна сторінка проєкту, сторінка задач, таблиця
для створення нових задач, календар відпусток, аналітична сторінка та сторінка
адміністративного керування.
Для керування глобальним станом застосунку використовується Redux
Toolkit. Офіційна документація визначає Redux Toolkit як рекомендований
інструментарій для ефективної розробки Redux-логіки [14]. У TimeBrix Redux
Toolkit використовується для збереження інформації про поточного користувача,
JWT-токен авторизації, списки проєктів і задач, фільтри, стан завантаження та
інші дані, необхідні для роботи інтерфейсу. Централізоване керування станом
дозволяє забезпечити узгодженість даних між компонентами застосунку.
Маршрутизація реалізована за допомогою React Router, що дозволяє
організувати навігацію між сторінками без повного перезавантаження
вебзастосунку [15]. Наприклад, користувач може перейти з dashboard до
конкретного проєкту, переглянути список задач або відкрити сторінку аналітики.
Для захисту приватних сторінок реалізовано механізм захищених маршрутів, який
обмежує доступ неавторизованим користувачам та підтримує розмежування прав
доступу за ролями.
Система підтримує авторизацію за допомогою JWT та Google OAuth. Після
успішного входу JWT-токен автоматично додається до API-запитів через
централізований API-шар. Також реалізовано обробку HTTP-помилок і
автоматичний logout у випадку втрати доступу або завершення терміну дії токена.
Лист
ЧДТУ 262202.003 ПЗ
32
Зм Арк. № докум. Пiдпис. Дата
нт

Для стилізації інтерфейсу використано Tailwind CSS та Material UI. Tailwind
CSS є utility-first CSS-фреймворком для швидкого створення сучасних адаптивних
інтерфейсів [16], а Material UI надає готові React-компоненти, реалізовані
відповідно до концепції Material Design [17]. Поєднання цих інструментів
дозволило реалізувати таблиці, форми, кнопки, модальні вікна, інформаційні
картки, системи повідомлень та інші елементи інтерфейсу. У застосунку також
реалізовано підтримку світлої та темної тем оформлення.
Однією з ключових функцій системи є інтерактивна таблиця обліку
робочого часу. Вона дозволяє користувачам вносити інформацію про витрачені
години за день або тиждень, автоматично зберігати дані та виконувати перевірку
коректності введених значень. Для зручності користувача реалізовано timeline-
перегляд задач за вибраний період часу.
Функціональність роботи з проєктами включає створення, редагування,
пошук і видалення проєктів, перегляд статистики, списку учасників та пов’язаних
задач. Користувачі можуть призначати учасників проєкту або видаляти їх зі
складу команди. Для адміністраторів реалізовано окрему панель керування
клієнтами та заявками на відпустку.
Аналітична частина системи містить dashboard із графіками та
статистичними показниками. Користувач може переглядати інформацію щодо
витраченого часу, оплачуваних годин, проєктів та динаміки роботи за певний
період. Для підвищення зручності роботи інтерфейс містить пагінацію, loader-
стани, повідомлення про помилки та модальні вікна.
Важливою вимогою до frontend є адаптивність інтерфейсу. TimeBrix
коректно відображається на різних типах пристроїв, зокрема на ноутбуках,
моніторах і планшетах. Для цього використовується гнучка сітка компонентів,
адаптивні стилі та продумана ієрархія елементів інтерфейсу.
Проєкт також підготовлений до production-розгортання. Для цього
реалізовано конфігурації Docker, Nginx і docker-compose, підтримку runtime-
конфігурації через config.json, а також CI/CD-конфігурацію для Bitbucket
Лист
ЧДТУ 262202.003 ПЗ
33
Зм Арк. № докум. Пiдпис. Дата
нт

Pipelines. Це дозволяє автоматизувати процес збірки, тестування та розгортання
вебзастосунку.

Рисунок 3.4 – Сторінка проєктів TimeBrix

3.5 Реалізація механізмів автентифікації та безпеки
Механізми автентифікації та безпеки TimeBrix реалізуються на рівні
backend і frontend. На backend перевіряються облікові дані користувача,
формується токен доступу, перевіряються ролі та права. На frontend
забезпечується збереження стану автентифікації, захист приватних маршрутів і
передавання токена в API-запитах.
Процес автентифікації може відбуватися за таким сценарієм: користувач
вводить email і пароль; frontend надсилає запит до endpoint login; backend
перевіряє користувача та пароль; у разі успіху формується JWT-токен; frontend
зберігає токен і використовує його для подальших запитів. Якщо токен відсутній
або недійсний, користувач не повинен отримувати доступ до приватних сторінок.
Авторизація реалізується через ролі. Наприклад, адміністратор може
керувати користувачами, бачити аналітику і статистику роботи користувачів,
створювати проєкти та задачі, а виконавець може доповнювати і виконувати
призначені задачі. Такий підхід дозволяє запобігти ситуації, коли користувач без
відповідних прав змінює критичні дані системи.
Лист
ЧДТУ 262202.003 ПЗ
34
Зм Арк. № докум. Пiдпис. Дата
нт

Вхідні дані повинні проходити валідацію. Це стосується форм входу,
створення проєкту, створення задачі, редагування профілю та інших операцій.
Валідація потрібна як на frontend для зручності користувача, так і на backend для
реального захисту системи. Backend-валідація є обов’язковою, оскільки
клієнтську перевірку можна обійти.
За рекомендаціями OWASP, web-застосунки повинні враховувати ризики
ін’єкцій, порушення контролю доступу, помилки автентифікації та
криптографічні помилки [5]. Для TimeBrix це означає необхідність хешування
паролів, обмеження доступу за ролями, перевірки прав на кожну критичну дію та
використання захищених конфігурацій у production-середовищі.

Рисунок 3.6 – Сторінка автентифікації користувача у TimeBrix

Лист
ЧДТУ 262202.003 ПЗ
35
Зм Арк. № докум. Пiдпис. Дата
нт

3.6 Тестування та перевірка працездатності системи
Тестування вебсервісу TimeBrix проводиться з метою перевірки
відповідності реалізованої системи функціональним і нефункціональним вимогам.
Основними завданнями тестування є підтвердження коректної роботи ключових
функцій системи, виявлення можливих помилок, перевірка стабільності роботи
застосунку, оцінка зручності користувацького інтерфейсу та перевірка базових
механізмів безпеки.
Функціональне тестування охоплює перевірку основних бізнес-сценаріїв
роботи користувача із системою. Зокрема, перевіряється коректність реєстрації та
авторизації користувачів, створення та редагування проєктів, створення задач,
зміна статусів задач, призначення виконавців, робота з тегами, перегляд
аналітики, створення заявок на відпустку та вихід із системи. Для кожного
тестового сценарію визначається очікуваний результат, який порівнюється з
фактичною поведінкою системи після виконання дій користувача.
Особлива увага приділяється тестуванню користувацького інтерфейсу
frontend-частини. Під час тестування перевіряється коректне відображення
сторінок, робота навігації, форм, кнопок, таблиць, модальних вікон, повідомлень
про помилки та loader-компонентів. Також оцінюється адаптивність інтерфейсу на
різних типах пристроїв і розмірах екранів. Найбільш важливими для перевірки є
сторінки dashboard, список проєктів, детальна сторінка проєкту, список задач,
таблиця обліку часу та сторінка аналітики.
Тестування серверної частини та API виконується за допомогою Swagger та
інших інструментів перевірки HTTP-запитів. Для кожного endpoint перевіряються
як позитивні сценарії роботи, так і обробка помилок. Зокрема, тестуються
випадки надсилання некоректних даних, відсутності JWT-токена, недостатніх
прав доступу, помилок валідації DTO та спроб доступу до неіснуючих ресурсів.
Такий підхід дозволяє оцінити не лише правильність роботи API, а й стійкість
системи до некоректних дій користувача.
Лист
ЧДТУ 262202.003 ПЗ
36
Зм Арк. № докум. Пiдпис. Дата
нт

Тестування безпеки спрямоване на перевірку механізмів автентифікації та
авторизації. Під час перевірки тестуються спроби доступу до захищених
маршрутів без токена, виконання адміністративних дій користувачем без
відповідної ролі, введення неправильних облікових даних, а також спроби
отримання доступу до чужих проєктів, задач або персональних даних. Такі
перевірки дозволяють підтвердити коректність реалізації механізмів контролю
доступу та захисту інформації [5].
Окремо виконується перевірка інтеграції frontend і backend частин системи.
Тестується коректність обміну даними між клієнтською та серверною частинами,
обробка HTTP-відповідей, оновлення стану застосунку після виконання запитів та
правильність відображення інформації в інтерфейсі користувача.
Результати тестування доцільно подати у вигляді таблиць із тестовими
сценаріями, очікуваними та фактичними результатами, а також статусом
проходження тесту. Такий формат дозволяє систематизувати результати
перевірки та наочно продемонструвати працездатність вебсервісу TimeBrix.
Таблиця 3.2 – Тестові сценарії TimeBrix
№ Сценарій Очікуваний Статус
результат
1 Вхід користувача з Користувач переходить Пройдено / уточнити
правильними даними до dashboard
2 Вхід з неправильним Система показує Пройдено / уточнити
паролем повідомлення про
помилку
3 Створення нового Проєкт з’являється у Пройдено / уточнити
проєкту списку
4 Створення задачі у Задача додається до Пройдено / уточнити
проєкті проєкту
5 Зміна статусу задачі Статус оновлюється у Пройдено / уточнити
системі
6 Доступ без токена Приватний ресурс Пройдено / уточнити
недоступний

Лист
ЧДТУ 262202.003 ПЗ
37
Зм Арк. № докум. Пiдпис. Дата
нт

3.7 Висновки до розділу 3
У третьому розділі описано реалізацію web-сервісу TimeBrix. Розглянуто
загальну структуру системи, серверну частину на NestJS, клієнтську частину на
React і TypeScript, базу даних PostgreSQL, використання Prisma ORM,
інфраструктуру Docker і Nginx, а також засоби документування API через
Swagger.
Описано проєктування бази даних, основні сутності та зв’язки між ними.
Визначено, що реляційна модель PostgreSQL є доцільною для системи управління
проєктами, оскільки вона дозволяє формалізувати зв’язки між користувачами,
проєктами, задачами, коментарями та аналітичними подіями.
Розглянуто реалізацію механізмів автентифікації, авторизації та захисту
даних. Запропоновано підхід до тестування системи, який охоплює функціональні
сценарії, перевірку API, тестування інтерфейсу та базові перевірки безпеки.

Лист
ЧДТУ 262202.003 ПЗ
38
Зм Арк. № докум. Пiдпис. Дата
нт

ВИСНОВКИ
У кваліфікаційній роботі розроблено вебсервіс TimeBrix для управління
проєктами та операційною діяльністю підприємств. Система орієнтована на
використання компаніями, проєктними командами та корпоративними
підрозділами, які потребують єдиного середовища для планування, виконання,
контролю та аналізу роботи.
Проаналізовано предметну область управління проєктами та задачами.
Визначено, що сучасні організації потребують цифрових інструментів, які
забезпечують прозорість роботи, розподіл відповідальності, контроль строків і
доступ до аналітичних показників. Розглянуто підходи PMBOK, Agile та Scrum,
які підтверджують важливість системного управління, адаптивності та
регулярного контролю результатів [1], [2], [3].
Розглянуто існуючі системи управління проєктами Jira, Trello, Asana та
ClickUp. Встановлено, що ці рішення мають розвинені можливості, але можуть
бути складними, надлишковими або обмеженими залежно від потреб конкретної
організації. На основі аналізу аналогів сформовано вимоги до TimeBrix як web-
сервісу, що поєднує управління проєктами, задачами та аналітику операційної
діяльності.
Сформовано функціональні вимоги до системи: автентифікація
користувачів, керування ролями, створення проєктів, створення та призначення
задач, зміна статусів, фільтрація, перегляд аналітики та документування API.
Сформовано нефункціональні вимоги до продуктивності, масштабованості,
надійності, зручності використання, підтримуваності та безпеки.
Обґрунтовано вибір технологій реалізації. Backend реалізовано на NestJS і
Node.js, frontend — на React і TypeScript, база даних — PostgreSQL, ORM —
Prisma. Для клієнтського стану використовується Redux Toolkit, для
маршрутизації — React Router, для стилізації — Tailwind CSS і Material UI.
Інфраструктурна частина базується на Docker та Nginx, а для документування API
застосовується Swagger.
Лист
ЧДТУ 262202.003 ПЗ
39
Зм Арк. № докум. Пiдпис. Дата
нт

Спроєктовано структуру бази даних TimeBrix, яка включає користувачів,
ролі, проєкти, учасників проєктів, задачі, коментарі та журнал активності. Така
модель дозволяє зберігати основні робочі дані, підтримувати зв’язки між
сутностями та формувати аналітичні показники.
Описано реалізацію серверної та клієнтської частин системи. Серверна
частина побудована за модульним принципом, де окремі модулі відповідають за
автентифікацію, користувачів, проєкти, задачі та аналітику. Клієнтська частина
забезпечує зручний інтерфейс для роботи з dashboard, проєктами, задачами та
налаштуваннями.
Розглянуто механізми безпеки TimeBrix: автентифікацію, авторизацію,
розмежування доступу за ролями, хешування паролів, валідацію вхідних даних і
захист приватних маршрутів. Вимоги безпеки сформовано з урахуванням
рекомендацій OWASP щодо критичних ризиків web-застосунків [5].
Проведено опис підходу до тестування системи. Запропоновано тестові
сценарії для перевірки входу користувача, створення проєктів і задач, зміни
статусів, доступу до приватних ресурсів та перевірки API. У роботі передбачено
місця для додавання фактичних результатів тестування, скриншотів інтерфейсу та
фрагментів програмного коду.
Практичне значення роботи полягає у можливості використання TimeBrix
підприємствами та організаціями для централізованого управління проєктами,
задачами, командною роботою та операційною аналітикою. Подальший розвиток
системи може включати інтеграцію з календарями та месенджерами, розширену
аналітику, сповіщення, імпорт і експорт даних, а також інтеграцію з
корпоративними сервісами.

Лист
ЧДТУ 262202.003 ПЗ
40
Зм Арк. № докум. Пiдпис. Дата
нт

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Project Management Institute. PMBOK Guide and Standards. URL:
https://www.pmi.org/standards/pmbok (дата звернення: 28.04.2026).
2. Beck K. et al. Manifesto for Agile Software Development. URL:
https://agilemanifesto.org/ (дата звернення: 28.04.2026).
3. Schwaber K., Sutherland J. The Scrum Guide. The Definitive Guide to Scrum: The
Rules of the Game. 2020. URL: https://scrumguides.org/docs/scrumguide/v2020/2020-
Scrum-Guide-US.pdf (дата звернення: 28.04.2026).
4. ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle
processes — Requirements engineering. Geneva: ISO, 2018.
5. OWASP Foundation. OWASP Top 10:2021. URL: https://owasp.org/Top10/2021/
(дата звернення: 28.04.2026).
6. OpenAPI Initiative. OpenAPI Specification. Version 3.1.0. URL:
https://swagger.io/specification/ (дата звернення: 28.04.2026).
7. NestJS. Documentation. A progressive Node.js framework. URL:
https://docs.nestjs.com/ (дата звернення: 28.04.2026).
8. React. Using TypeScript. URL: https://react.dev/learn/typescript (дата звернення:
28.04.2026).
9. Microsoft. TypeScript Documentation. URL: https://www.typescriptlang.org/docs/
(дата звернення: 28.04.2026).
10. PostgreSQL Global Development Group. PostgreSQL Documentation. URL:
https://www.postgresql.org/docs/ (дата звернення: 28.04.2026).
11. Prisma. Prisma ORM Documentation. URL: https://www.prisma.io/docs (дата
звернення: 28.04.2026).
12. Docker Inc. Docker Docs. URL: https://docs.docker.com/ (дата звернення:
28.04.2026).
13. Nginx. NGINX Documentation. URL: https://nginx.org/en/docs/ (дата звернення:
28.04.2026).
Лист
ЧДТУ 262202.003 ПЗ
41
Зм Арк. № докум. Пiдпис. Дата
нт

14. Redux Toolkit. Documentation. URL: https://redux-toolkit.js.org/ (дата звернення:
28.04.2026).
15. React Router. Official Documentation. URL: https://reactrouter.com/ (дата
звернення: 28.04.2026).
16. Tailwind Labs. Tailwind CSS Documentation. URL: https://tailwindcss.com/ (дата
звернення: 28.04.2026).
17. MUI. Material UI Documentation. URL: https://mui.com/material-ui/ (дата
звернення: 28.04.2026).
18. Atlassian. Jira Software. URL: https://www.atlassian.com/software/jira (дата
звернення: 28.04.2026).
19. Atlassian. Trello. URL: https://trello.com/ (дата звернення: 28.04.2026).
20. Asana. Manage your team’s work, projects, & tasks online. URL: https://asana.com/
(дата звернення: 28.04.2026).
21. ClickUp. Project Management Software. URL: https://clickup.com/ (дата
звернення: 28.04.2026).
22. ESLint. Documentation. URL: https://eslint.org/docs/latest/ (дата звернення:
28.04.2026).
23. Prettier. Opinionated Code Formatter. URL: https://prettier.io/ (дата звернення:
28.04.2026).
24. Fielding R. T. Architectural Styles and the Design of Network-based Software
Architectures: Doctoral dissertation. University of California, Irvine, 2000.
25. Sommerville I. Software Engineering. 10th ed. Boston: Pearson, 2015. 816 p.
26. Pressman R. S., Maxim B. R. Software Engineering: A Practitioner’s Approach. 9th
ed. New York: McGraw-Hill Education, 2020. 704 p.
27. World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2.
URL: https://www.w3.org/TR/WCAG22/ (дата звернення: 28.04.2026).
28. MDN Web Docs. HTTP. URL: https://developer.mozilla.org/en-
US/docs/Web/HTTP (дата звернення: 28.04.2026).
Лист
ЧДТУ 262202.003 ПЗ
42
Зм Арк. № докум. Пiдпис. Дата
нт

29. OWASP Foundation. Application Security Verification Standard. URL:
https://owasp.org/www-project-application-security-verification-standard/ (дата
звернення: 28.04.2026).
30. IEEE Computer Society. Guide to the Software Engineering Body of Knowledge
(SWEBOK Guide). URL: https://www.computer.org/education/bodies-of-
knowledge/software-engineering (дата звернення: 28.04).

Лист
ЧДТУ 262202.003 ПЗ
43
Зм Арк. № докум. Пiдпис. Дата
нт

ДОДАТОК А

ЗАТВЕРДЖЕНО
Зав.кафедри ІТП
____________Прокопенко Т.О.
“_____” _____________2026р.

Вебсервіс TimeBrix для управління проєктами та операційною діяльністю
підприємств

Специфікація
ЧДТУ 262202 – 01
Листів 2

Розробник Атрощенко О.А.
Керівник Катаєв Д.С.

Черкаси, 2026
ЧДТУ 262202 – 01
Лист
ЧДТУ 262202.003 ПЗ
44
Зм Арк. № докум. Пiдпис. Дата
нт

Позначення Найменування Примітка
ЧДТУ 262202 – 01 Фрагменти програмного
коду
ЧДТУ 262202 – 01 Скріншоти роботи web-
сервісу TimeBrix

Лист
ЧДТУ 262202.003 ПЗ
45
Зм Арк. № докум. Пiдпис. Дата
нт

ДОДАТОК Б

ЗАТВЕРДЖЕНО
Зав.кафедри ІТП
____________Прокопенко Т.О.
“_____” _____________2026р.

Вебсервіс TimeBrix для управління проєктами та операційною діяльністю
підприємств

Фрагменти програмного коду
ЧДТУ 262202 – 01
Листів 20

Розробник Атрощенко О.А.
Керівник Катаєв Д.С.

Черкаси, 2026
Лист
ЧДТУ 262202.003 ПЗ
46
Зм Арк. № докум. Пiдпис. Дата
нт

ДОДАТОК Б
ФРАГМЕНТИ ПРОГРАМНОГО КОДУ
Додаток Б.1 – Фрагмент Prisma-схеми бази даних
generator client {
provider = "prisma-client-js"
}

datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}

model User {
id Int @id @default(autoincrement())
username String @unique
email String @unique
passwordHash String
roleId Int
avatarUrl String?
createdAt DateTime @default(now()) @db.Timestamptz(6)
updatedAt DateTime @updatedAt @db.Timestamptz(6)

role Role @relation(fields: [roleId], references: [id], onDelete: Restrict,
onUpdate: Cascade)
ownedProjects Project[] @relation("ProjectOwner")
ownedTasks Task[] @relation("TaskOwner")
assignedTasks Task[] @relation("TaskAssignee")
vacations Vacation[]
projects Project[]

@@index([roleId])
}

model Role {
id Int @id @default(autoincrement())
role String @unique
users User[]
}

model Project {
id Int @id @default(autoincrement())
name String
Лист
ЧДТУ 262202.003 ПЗ
47
Зм Арк. № докум. Пiдпис. Дата
нт

description String?
ownerId Int
clientId Int?
createdAt DateTime @default(now()) @db.Timestamptz(6)
updatedAt DateTime @updatedAt @db.Timestamptz(6)

owner User @relation("ProjectOwner", fields: [ownerId], references: [id], onDelete:
Cascade, onUpdate: Cascade)
client Client? @relation(fields: [clientId], references: [id])
tasks Task[]
users User[]

@@unique([ownerId, name])
@@index([ownerId])
@@index([clientId])
}

model Client {
id Int @id @default(autoincrement())
name String @unique

projects Project[]
}

model Task {
id Int @id @default(autoincrement())
name String
description String?
projectId Int
ownerId Int
externalId String? @unique
assignedTo Int?
createdAt DateTime @default(now()) @db.Timestamptz(6)
updatedAt DateTime @updatedAt @db.Timestamptz(6)

project Project @relation(fields: [projectId], references: [id], onDelete: Cascade,
onUpdate: Cascade)
owner User @relation("TaskOwner", fields: [ownerId], references: [id], onDelete:
Cascade, onUpdate: Cascade)
assignee User? @relation("TaskAssignee", fields: [assignedTo], references: [id],
onDelete: SetNull, onUpdate: Cascade)

intervals TimeInterval[]
tags Tag[]
Лист
ЧДТУ 262202.003 ПЗ
48
Зм Арк. № докум. Пiдпис. Дата
нт

@@index([projectId])
@@index([ownerId])
@@index([assignedTo])
}

model Tag {
id Int @id @default(autoincrement())
name String @unique
createdAt DateTime @default(now()) @db.Timestamptz(6)
updatedAt DateTime @updatedAt @db.Timestamptz(6)

tasks Task[]
}

model TimeInterval {
id Int @id @default(autoincrement())
taskId Int @unique
startTime DateTime @db.Timestamptz(6)
endTime DateTime @db.Timestamptz(6)
isPaid Boolean @default(false)
createdAt DateTime @default(now()) @db.Timestamptz(6)
updatedAt DateTime @updatedAt @db.Timestamptz(6)

task Task @relation(fields: [taskId], references: [id], onDelete: Cascade, onUpdate:
Cascade)

@@index([taskId])
}

model Vacation {
id Int @id @default(autoincrement())
userId Int
state VacationState
reason VacationReason
description String?
startTime DateTime @db.Timestamptz(6)
endTime DateTime @db.Timestamptz(6)
createdAt DateTime @default(now()) @db.Timestamptz(6)
updatedAt DateTime @updatedAt @db.Timestamptz(6)

user User @relation(fields: [userId], references: [id], onDelete: Cascade, onUpdate:
Cascade)

Лист
ЧДТУ 262202.003 ПЗ
49
Зм Арк. № докум. Пiдпис. Дата
нт

@@index([userId])
}

model TasksRaw {
userId Int
day DateTime @db.Date
rawData Json
createdAt DateTime @default(now()) @db.Timestamptz(6)
updatedAt DateTime @updatedAt @db.Timestamptz(6)

@@id([userId, day])
@@index([userId])
}

enum VacationState {
pending
approved
rejected
}

enum VacationReason {
sickLeave
paid
unpaid
}

Додаток Б.2 – Модуль Users
Код файлу UserClass:
@UseGuards(JwtAuthGuard)
@ApiBearerAuth('access-token')
@Controller('users')
export class UsersController {
constructor(private readonly usersService: UsersService) {}

@Get()
public findAll(
@Query('page', new ParseIntPipe({ optional: true })) page: number = 1,
@Query('limit', new ParseIntPipe({ optional: true }))
limit: number = 20,
@Query('search') search?: string,
) {
return this.usersService.findAll(page, limit, search);
Лист
ЧДТУ 262202.003 ПЗ
50
Зм Арк. № докум. Пiдпис. Дата
нт

}

@Get(':username')
public findByUsername(@Param('username') username: string) {
return this.usersService.findByUsername(username);
}

@Get(':id')
public findOne(@Param('id') id: string) {
return this.usersService.findOne(+id);
}

@Patch()
public update(@CurrentUser() user: UserPayload, @Body() updateUserDto:
UpdateUserDto) {
return this.usersService.update(user.id, updateUserDto);
}

@Delete(':id')
@UseGuards(OwnerGuard)
@CheckOwner('user')
public remove(@Param('id') id: string) {
return this.usersService.remove(+id);
}
}

Код файлу UserService:
@Injectable()
export class UsersService {
constructor(
private readonly usersRepository: UsersRepository,
private readonly mailService: MailService,
) {}

public async findAll(
page: number = 1,
limit: number = 20,
search?: string,
): Promise<UserDto[]> {
const skip = (page - 1) * limit;
const users = await this.usersRepository.findAll(skip, limit, search);
return users.map((user) =>
plainToInstance(UserDto, user, { excludeExtraneousValues: true }),
Лист
ЧДТУ 262202.003 ПЗ
51
Зм Арк. № докум. Пiдпис. Дата
нт

);
}

public async findOne(id: number) {
const user = await this.usersRepository.findById(id);
if (!user) throw new NotFoundException();

return plainToInstance(UserDto, user, {
excludeExtraneousValues: true,
});
}

public async findByUsername(username: string) {
const user = await this.usersRepository.findByUsername(username);
if (!user) {
throw new NotFoundException(`User with username "${username}" not
found.`);
}
return plainToInstance(UserDto, user, {
excludeExtraneousValues: true,
});
}

public async create(createUserDto: CreateUserDto) {
try {
const passwordHash = await hashPassword(createUserDto.password);
const userEntity = plainToInstance(User, createUserDto, {
excludeExtraneousValues: true,
});
userEntity.passwordHash = passwordHash;
userEntity.roleId = Roles.USER;

);
}
}
throw error;
}
}

public async createOauthUser(email: string, username: string, avatarUrl?: string) {
const generatedUsername = await
this.usersRepository.generateUsername(username);

const user = new User();
user.email = email;
user.username = generatedUsername;
user.roleId = Roles.USER;
user.passwordHash = uuid();
if (avatarUrl) user.avatarUrl = avatarUrl;

const createdUser = await this.usersRepository.create(user);
return plainToInstance(UserDto, createdUser, {
excludeExtraneousValues: true,
});
}

public async update(id: number, updateUserDto: UpdateUserDto) {
if (updateUserDto.username) {
const existingUser = await
this.usersRepository.findByUsername(updateUserDto.username);

if (existingUser && existingUser.id !== id) {
throw new ConflictException('Username is already taken');
}
}

const passwordHash = updateUserDto.password
? await hashPassword(updateUserDto.password)
: undefined;

const userEntity = plainToInstance(User, updateUserDto, {
excludeExtraneousValues: true,
});

if (passwordHash) userEntity.passwordHash = passwordHash;

Лист
ЧДТУ 262202.003 ПЗ
53
Зм Арк. № докум. Пiдпис. Дата
нт

const updatedUser = await this.usersRepository.update(id, userEntity);

return plainToInstance(UserDto, updatedUser, {
excludeExtraneousValues: true,
});
}

public remove(id: number) {
return this.usersRepository.remove(id);
}

public async validateUser(email: string, password: string) {
const user = await this.usersRepository.findByEmail(email);
if (!user) throw new NotFoundException('User not found');

const isPasswordValid = await compare(password, user.passwordHash);
if (!isPasswordValid) throw new UnauthorizedException('Invalid credentials');

return plainToInstance(User, user, {
excludeExtraneousValues: true,
});
}

public async findByEmail(email: string) {
const user = await this.usersRepository.findByEmail(email);
return plainToInstance(User, user, {
excludeExtraneousValues: true,
});
}
}

Додаток Б.3 – Модуль Project
Код файлу ProjectController:
@UseGuards(JwtAuthGuard)
@ApiBearerAuth('access-token')
@Controller('projects')
export class ProjectsController {
constructor(private readonly projectsService: ProjectsService) {}

@Post()
Лист
ЧДТУ 262202.003 ПЗ
54
Зм Арк. № докум. Пiдпис. Дата
нт

public create(@Body() createProjectDto: CreateProjectDto, @CurrentUser()
user: UserPayload) {
return this.projectsService.create(createProjectDto, user.id);
}

@Get()
public findAll(
@CurrentUser() user: UserPayload,
@Query('page', new ParseIntPipe({ optional: true })) page: number = 1,
@Query('limit', new ParseIntPipe({ optional: true }))
limit: number = 20,
@Query('search') search?: string,
) {
return this.projectsService.findAll(user.id, page, limit, search);
}

@Get(':id')
@UseGuards(OwnerGuard)
@CheckOwner('project')
public findOne(@Param('id', ParseIntPipe) id: number) {
return this.projectsService.findOne(id);
}

@Patch(':id')
@UseGuards(OwnerGuard)
@CheckOwner('project')
public update(
@Param('id', ParseIntPipe) id: number,
@Body() updateProjectDto: UpdateProjectDto,
Лист
ЧДТУ 262202.003 ПЗ
55
Зм Арк. № докум. Пiдпис. Дата
нт

@CurrentUser() user: UserPayload,
) {
return this.projectsService.update(id, updateProjectDto, user.id);
}

@Delete(':id')
@UseGuards(OwnerGuard)
@CheckOwner('project')
public remove(@Param('id', ParseIntPipe) id: number, @CurrentUser() user:
UserPayload) {
return this.projectsService.remove(id, user.id);
}

@Get(':id/users')
public findUsersAssignedToProject(@Param('id', ParseIntPipe) id: number) {
return this.projectsService.findUsersAssignedToProject(id);
}

@Post(':id/users')
@UseGuards(OwnerGuard)
@CheckOwner('project')
public assignUsersToProject(
@Param('id', ParseIntPipe) id: number,
@Body('userIds') userIds: number[],
) {
return this.projectsService.assignUsersToProject(userIds, id);
}

@Delete(':id/users')
Лист
ЧДТУ 262202.003 ПЗ
56
Зм Арк. № докум. Пiдпис. Дата
нт

@UseGuards(OwnerGuard)
@CheckOwner('project')
public deleteUsersFromProject(
@Param('id', ParseIntPipe) id: number,
@Body('userIds') userIds: number[],
) {
return this.projectsService.deleteUsersFromProject(userIds, id);
}
}

Код файлу ProjectService:
@Injectable()
export class ProjectsService {
constructor(private readonly projectsRepository: ProjectsRepository) {}

public async create(createProjectDto: CreateProjectDto, ownerId: number) {
try {
const createdProject = await this.projectsRepository.create({
...createProjectDto,
ownerId,
});
return plainToInstance(ProjectDto, createdProject);
} catch (error: unknown) {
if (isPrismaError(error) && error.code === 'P2003') {
throw new NotFoundException(
`Client with ID ${createProjectDto.clientId} not found`,
);
} else if (isPrismaError(error) && error.code === 'P2002') {
throw new ConflictException('Project with such name already exists');
Лист
ЧДТУ 262202.003 ПЗ
57
Зм Арк. № докум. Пiдпис. Дата
нт

} else {
console.error(error);
throw error;
}
}
}

public async findAll(ownerId: number, page = 1, limit = 20, search?: string) {
const skip = (page - 1) * limit;
const [projects, count] = await Promise.all([
this.projectsRepository.findAllByUserId(skip, limit, ownerId, search),
this.projectsRepository.findQuantityByUserId(ownerId, search),
]);

return {
data: plainToInstance(ProjectDto, projects),
meta: {
totalItems: count,
itemCount: projects.length,
itemsPerPage: limit,
totalPages: Math.ceil(count / limit),
currentPage: page,
},
};
}

public async findOne(id: number) {
const project = await this.projectsRepository.findById(id);

Лист
ЧДТУ 262202.003 ПЗ
58
Зм Арк. № докум. Пiдпис. Дата
нт

if (!project) {
throw new NotFoundException(`Project with ID ${id} not found`);
}
return plainToInstance(ProjectDto, project, { excludeExtraneousValues: true });
}
public async update(id: number, updateProjectDto: UpdateProjectDto, ownerId:
number) {
const project = await this.projectsRepository.findById(id);

if (!project) {
throw new NotFoundException(`Project with ID ${id} not found or access
denied`);
}
if (project.owner.id !== ownerId) {
throw new ForbiddenException('Access denied');
}
try {
const updatedProject = await this.projectsRepository.update(id,
updateProjectDto);
return plainToInstance(ProjectDto, updatedProject);
} catch (error: unknown) {
if (isPrismaError(error) && error.code === 'P2025') {
throw new NotFoundException(`Project with ID ${id} not found`);
}
throw error;
}
}

public async remove(id: number, ownerId: number) {
Лист
ЧДТУ 262202.003 ПЗ
59
Зм Арк. № докум. Пiдпис. Дата
нт

const project = await this.projectsRepository.findById(id);

if (!project) {
throw new NotFoundException(`Project with ID ${id} not found or access
denied`);
}
if (project.owner.id !== ownerId) {
throw new ForbiddenException('Access denied');
}

try {
const removedProject = await this.projectsRepository.remove(id);
return plainToInstance(ProjectDto, removedProject);
} catch (error: unknown) {
if (isPrismaError(error) && error.code === 'P2025') {
throw new NotFoundException(`Project with ID ${id} not found`);
}
throw error;
}
}

public isUserAssignedToProject(userId: number, projectId: number):
Promise<boolean> {
return this.projectsRepository.isUserAssignedToProject(userId, projectId);
}

public async assignUsersToProject(usersIds: number[], projectId: number):
Promise<void> {
try {
Лист
ЧДТУ 262202.003 ПЗ
60
Зм Арк. № докум. Пiдпис. Дата
нт

await this.projectsRepository.assignUsersToProject(usersIds, projectId);
} catch (error: unknown) {
if (isPrismaError(error) && error.code === 'P2025') {
throw new NotFoundException(`Some users do not exist`);
}
throw error;
}
}

Додаток Б.4 – Модуль Tasks
Код файлу TasksController:
@UseGuards(JwtAuthGuard)
@ApiBearerAuth('access-token')
@Controller('tasks')
export class TasksController {
constructor(private readonly tasksService: TasksService) {}

@Post()
public create(@Body() createTaskDto: CreateTaskDto, @CurrentUser() user:
UserPayload) {
return this.tasksService.createOrUpdate(createTaskDto, user.id);
}

@Get()
public findAllByRange(
@Query('start') start: string,
@Query('end') end: string,
Лист
ЧДТУ 262202.003 ПЗ
61
Зм Арк. № докум. Пiдпис. Дата
нт

@CurrentUser() user: UserPayload,
@Query('includeNotAssigned') includeNotAssigned: boolean,
) {
return this.tasksService.findAllByRange(start, end, user.id,
includeNotAssigned);
}

@Get('project/:projectId')
public findAllByProject(@Param('projectId', ParseIntPipe) projectId: number)
{
return this.tasksService.findAllByProject(projectId);
}

@Get(':id')
@UseGuards(OwnerGuard)
@CheckOwner('task')
public findOne(@Param('id') id: string) {
return this.tasksService.findOne(+id);
}

@Delete(':id')
@UseGuards(OwnerGuard)
@CheckOwner('task')
public remove(@Param('id') id: string) {
return this.tasksService.remove(+id);
}
}

Код файлу TasksService:
Лист
ЧДТУ 262202.003 ПЗ
62
Зм Арк. № докум. Пiдпис. Дата
нт

@Injectable()
export class TasksService {
constructor(private readonly tasksRepository: TasksRepository) {}

public async createOrUpdate(createTaskDto: CreateTaskDto, ownerId:
number) {
const task = await this.tasksRepository.upsertTaskAndSingleInterval(
plainToInstance(
Task,
{ ...createTaskDto, ownerId },
{
excludeExtraneousValues: true,
},
),
createTaskDto.timeInterval,
);

return plainToInstance(TaskDto, task);
}

public async findAllByRange(
start: string,
end: string,
userId: number,
includeNotAssigned: boolean,
) {
const tasks = await this.tasksRepository.findAllByRange(
start,
end,
Лист
ЧДТУ 262202.003 ПЗ
63
Зм Арк. № докум. Пiдпис. Дата
нт

userId,
includeNotAssigned,
);

return plainToInstance(TaskDto, tasks);
}

public async findAllByRangeForUsersInProjects(
start: string,
end: string,
userIds: Set<number>,
projectIds: Set<number>,
) {
return this.tasksRepository.findAllByRangeForUsersInProjects(
start,
end,
userIds,
projectIds,
);
}

public async findAllByProject(projectId: number) {
const tasks = await this.tasksRepository.findAllByProject(projectId);
return plainToInstance(TaskDto, tasks);
}

public async findOne(id: number) {
const task = await this.tasksRepository.findById(id);
if (!task) {
Лист
ЧДТУ 262202.003 ПЗ
64
Зм Арк. № докум. Пiдпис. Дата
нт

throw new NotFoundException(`Task with ID ${id} not found`);
}

return plainToInstance(TaskDto, task);
}

public async remove(id: number) {
try {
await this.tasksRepository.remove(id);
return { message: `Task with ID ${id} successfully deleted` };
} catch (error: unknown) {
if (isPrismaError(error) && error.code === 'P2025') {
throw new NotFoundException(`Task with ID ${id} not found`);
}
throw error;
}
}
}
Додаток Б.5 – Фрагмент сервісу автентифікації користувача
@Injectable()
export class AuthService {
constructor(
private readonly jwtService: JwtService,
private readonly configService: ConfigService,
private readonly userService: UsersService,
private readonly googleClient: OAuth2Client,
) {}

public login(user: User): TokenPayload {
Лист
ЧДТУ 262202.003 ПЗ
65
Зм Арк. № докум. Пiдпис. Дата
нт

const payload: JwtPayload = { sub: user.id, username: user.username, roleId:
user.roleId };
return {
accessToken: this.jwtService.sign(payload),
};
}

publi async validateGoogleToken(credential: string): Promise<TokenPayload>
{
const ticket = await this.googleClient
.verifyIdToken({
idToken: credential,
audience: this.configService.get('GOOGLE_CLIENT_ID'),
})
.catch(() => {
throw new UnauthorizedException('Invalid Google token');
});

const payload = ticket.getPayload();
if (!payload) {
throw new UnauthorizedException('Invalid Google token');
}

if (!payload.email_verified) {
throw new UnauthorizedException('Google email is not verified');
}

const email = payload.email;
if (!email) {
Лист
ЧДТУ 262202.003 ПЗ
66
Зм Арк. № докум. Пiдпис. Дата
нт

throw new UnauthorizedException('Google account has no email');
}
const username = payload.name ?? email.split('@')[0];
let user = await this.userService.findByEmail(email);
if (!user) {
const oauthUser = await this.userService.createOauthUser(
email,
username,
payload.picture,
);
user = plainToInstance(User, oauthUser, {
excludeExtraneousValues: true,
}); }

return this.login(user);
}
}
Лист
ЧДТУ 262202.003 ПЗ
67
Зм Арк. № докум. Пiдпис. Дата
нт

ДОДАТОК В

ЗАТВЕРДЖЕНО
Зав.кафедри ІТП
____________Прокопенко Т.О.
“_____” _____________2026р.

Вебсервіс TimeBrix для управління проєктами та операційною діяльністю
підприємств

Скріншоти роботи web-сервісу TimeBrix
ЧДТУ 262202 – 01
Листів 4

Розробник Атрощенко О.А.
Керівник Катаєв Д.С.

Черкаси, 2026
Лист
ЧДТУ 262202.003 ПЗ
68
Зм Арк. № докум. Пiдпис. Дата
нт

ДОДАТОК В
СКРИНШОТИ РОБОТИ WEB-СЕРВІСУ TIMEBRIX

Рисунок В.1 – Сторінка входу web-сервісу TimeBrix

Рисунок В.2 – Dashboard web-сервісу TimeBrix
Лист
ЧДТУ 262202.003 ПЗ
69
Зм Арк. № докум. Пiдпис. Дата
нт

Рисунок В.3 – Сторінка для створення задач web-сервісу TimeBrix

Рисунок В.4 – Список проєктів web-сервісу TimeBrix

Лист
ЧДТУ 262202.003 ПЗ
70
Зм Арк. № докум. Пiдпис. Дата
нт

Рисунок В.5 – Сторінка проєкту web-сервісу TimeBrix

Рисунок В.6 – Сторінка відпусток web-сервісу TimeBrix

Лист
ЧДТУ 262202.003 ПЗ
71
Зм Арк. № докум. Пiдпис. Дата
нт

Рисунок В.7 – Аналітика web-сервісу TimeBrix

Рисунок В.8 – Сторінка користувача web-сервісу TimeBrix
Лист
ЧДТУ 262202.003 ПЗ
72
Зм Арк. № докум. Пiдпис. Дата
нт

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