Вебсервіс планування та контролю особистого бюджету

Губар, Владислав Геннадійович

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

Title:	Вебсервіс планування та контролю особистого бюджету
Authors:	Катаєв, Дмитро Сергійович Губар, Владислав Геннадійович
Keywords:	web-сервіс;TypeScript;особистий бюджет;Safe-to-Spend;поведінкова економіка;штучний інтелект;планування фінансів;контроль витрат;касовий розрив;таймер охолодження;NestJS;React;PostgreSQL
Issue Date:	10-Jun-2026
Abstract:	Кваліфікаційна робота присвячена розробці web-сервісу планування та контролю особистого бюджету FinMind. Актуальність роботи обумовлена відсутністю на ринку рішень, що поєднують проактивне бюджетування, інструменти поведінкової психології та AI-рекомендації в єдиній web-платформі. Метою роботи є розробка web-сервісу FinMind з реалізацією динамічного денного ліміту Safe-to-Spend, таймера охолодження для списку бажань та модуля AI-інсайтів із прогнозуванням касового розриву. Об’єкт – процес розробки webорієнтованих систем управління особистими фінансами. Предмет – методи реалізації проактивного управління фінансовою поведінкою користувача. Використано методи системного аналізу, об’єктно-орієнтованого проектування та функціонального тестування. Практична значущість полягає у готовності системи до використання через браузер без встановлення додаткового програмного забезпечення. У першому розділі проаналізовано предметну область та аналоги Saldo Finance, Spendee і Monefy. У другому розділі обґрунтовано технічне завдання. У третьому розділі описано розробку, тестування та порівняння з аналогами
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9881
Appears in Collections:	126 Інформаційні системи та технології (Web-технології, web-дизайн)

Files in This Item:

File	Description	Size	Format
РЕП_БАК_Губар _WEB-2211.pdf Restricted Access		2.89 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
(повна назва)
Кафедра інформаційних технологій проектування
(повна назва)
Освітньо-кваліфікаційний рівень бакалавр
(назва)
Спеціальність 126 – Інформаційні системи і технології
(шифр і назва)

ЗАТВЕРДЖУЮ
Завідувач кафедри ІТП
Тетяна ПРОКОПЕНКО
« » 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ БАКАЛАВРА
Губар Владислав Геннадійович
(прізвище, ім’я, по батькові)
1. Тема роботи Вебсервіс планування та контролю особистого бюджету
Керівник роботи Катаєв Дмитро Сергійович, к.т.н.
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
Затверджено наказом Черкаського державного технологічного університету
від « »
2. Строк подання здобувачем роботи
3. Вихідні дані до роботи: Специфікації сучасних веб-технологій розробки та
API великих мовних моделей. Наукові дослідження з поведінкової економіки
щодо механізмів фінансового самоконтролю та усвідомленого споживання.
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно
розробити) Вступ (актуальність, мета, задачі, об’єкт, предмет дослідження).
Розділ 1. Постановка задачі та огляд існуючих рішень
Розділ 2. Обґрунтування технічного завдання
Розділ 3. Розробка системи
Висновки, список використаних джерел, додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень,
плакатів) Схема архітектури системи FinMind. Схема навігації
користувацького інтерфейсу (UI/UX). UML-діаграми проєктування системи
(прецедентів, послідовності, діяльності). Логічна структура бази даних. Блок-
схема алгоритму Safe-to-Spend. Прототипи інтерфейсу.

6. Консультанти розділів роботи
Прізвище, ініціали, та Підпис, дата
Розділ посада
консультанта Завдання Завдання
видав прийняв

7. Дата видачі завдання

КАЛЕНДАРНИЙ ПЛАН
№ Назва етапів кваліфікаційної Строк виконання Примітка
роботи етапів роботи
1 Опис предметної області 14.02.2026 Виконано
2 Аналіз існуючих аналогів 21.02.2026 Виконано
3 Постановка задачі 25.02.2026 Виконано
4 Розробка архітектури системи. 14.03.2026 Виконано
5 Розробка структури бази даних 28.03.2026 Виконано
Обґрунтування вимог до
6 15.04.2026 Виконано
інтерфейсу та навігації
Обґрунтування доцільності
7 28.04.2026 Виконано
створення web-сервісу
Вибір та обґрунтування засобів
8 09.05.2026 Виконано
реалізації системи
Проєктування та програмна
9 16.05.2026 Виконано
реалізація web-сервісу FinMind
10 Тестування розробленої системи 18.05.2026 Виконано
Оцінка ефективності
11 20.05.2026 Виконано
розробленої системи
12 Попередній захист роботи 1.06.2026 Виконано
13 Затвердження роботи 6.06.2026 Виконано
14 Рецензування роботи 8.06.2023 Виконано
15 Захист роботи 10.06.2026 Виконано

Здобувач вищої освіти Владислав ГУБАР

Керівник роботи Дмитро КАТАЄВ

АНОТАЦІЯ

Пояснювальна записка складається з 3 розділів, викладена на 66 сторінках,
містить 24 рисунки, 2 таблиці, 27 джерел, 1 додаток.
Кваліфікаційна робота присвячена розробці web-сервісу планування та
контролю особистого бюджету FinMind. Актуальність роботи обумовлена
відсутністю на ринку рішень, що поєднують проактивне бюджетування,
інструменти поведінкової психології та AI-рекомендації в єдиній web-платформі.
Метою роботи є розробка web-сервісу FinMind з реалізацією динамічного
денного ліміту Safe-to-Spend, таймера охолодження для списку бажань та модуля
AI-інсайтів із прогнозуванням касового розриву. Об’єкт – процес розробки web-
орієнтованих систем управління особистими фінансами. Предмет – методи
реалізації проактивного управління фінансовою поведінкою користувача.
Використано методи системного аналізу, об’єктно-орієнтованого проектування
та функціонального тестування. Практична значущість полягає у готовності
системи до використання через браузер без встановлення додаткового
програмного забезпечення. У першому розділі проаналізовано предметну
область та аналоги Saldo Finance, Spendee і Monefy. У другому розділі
обґрунтовано технічне завдання. У третьому розділі описано розробку,
тестування та порівняння з аналогами.
Ключові слова: web-сервіс, особистий бюджет, Safe-to-Spend, поведінкова
економіка, штучний інтелект, планування фінансів, контроль витрат, касовий
розрив, таймер охолодження, NestJS, React, TypeScript, PostgreSQL.

SUMMARY

The thesis consists of 3 chapters, set out on 66 pages, contains 24 figures, 2
tables, 27 references, 1 appendices.
The thesis is dedicated to the development of the FinMind personal budget
planning and control web service. The relevance is defined by the lack of solutions
combining proactive budgeting, behavioral psychology tools, and AI recommendations
in a single web platform. The aim is to develop FinMind with a dynamic Safe-to-
Spend daily limit, a wishlist cooling-off timer, and an AI insights module with cash
gap forecasting. Object – the process of developing web-oriented personal finance
systems. Subject – methods of implementing proactive financial behavior
management. Research methods include systematic analysis, object-oriented design,
and functional testing. The practical value lies in the system’s readiness for use
through a browser without installing additional software. The first chapter analyzes the
subject area and existing analogues – Saldo Finance, Spendee, and Monefy. The
second chapter substantiates the technical specification. The third chapter describes the
implementation, testing, and comparison with analogues.
Keywords: web service, personal budget, Safe-to-Spend, behavioral economics,
artificial intelligence, financial planning, expense control, cash gap forecasting,
cooling-off timer, NestJS, React, TypeScript, PostgreSQL.

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

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

ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра

на тему: «Вебсервіс планування та контролю особистого бюджету»

Виконав: здобувач першого
(бакалаврського) рівня вищої освіти
4 курсу, групи WEB-2211
Спеціальності 126 Інформаційні системи та
технології
ОП «Web-технології, Web-дизайн»
Владислав ГУБАР

Керівник: к. т. н., старший викладач
кафедри інформаційних технологій
проектування
Дмитро КАТАЄВ

Рецензент: к. т. н., доцент кафедри
робототехніки та спеціалізованих
комп’ютерних систем
Марина ЧИЧУЖКО

Черкаси – 2026

ЗМІСТ

СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ ................................... 4
ВСТУП ....................................................................................................................... 5
РОЗДІЛ 1. ПОСТАНОВКА ЗАДАЧІ ТА ОГЛЯД ІСНУЮЧИХ РІШЕНЬ ...... 7
1.1. Аналіз предметної області та проблематики управління особистим
бюджетом ................................................................................................................ 7
1.2. Огляд та критичний аналіз існуючих аналогів інформаційних сервісів ....... 9
1.2.1. Saldo Finance: україномовний трекер витрат із плануванням за
категоріями ........................................................................................................ 10
1.2.2. Spendee: комплексна платформа з підтримкою Open Banking .............. 12
1.2.3. Monefy як приклад мінімалістичного обліку витрат ............................. 14
1.3. Постановка задачі розробки web-сервісу ..................................................... 16
1.4. Висновки до розділу 1 ................................................................................... 18
РОЗДІЛ 2. ОБҐРУНТУВАННЯ ТЕХНІЧНОГО ЗАВДАННЯ ......................... 20
2.1. Вимоги до функціоналу та алгоритмів web-сервісу FinMind ...................... 20
2.2. Вимоги до архітектури та структури баз даних ........................................... 23
2.3. Вимоги до інтерфейсу користувача та навігації .......................................... 27
2.4. Обґрунтування доцільності створення web-ресурсу .................................... 29
2.5. Висновки до розділу 2 ................................................................................... 31
РОЗДІЛ 3. РОЗРОБКА СИСТЕМИ ПЛАНУВАННЯ ТА КОНТРОЛЮ
ОСОБИСТОГО БЮДЖЕТУ ................................................................................ 32
3.1. Обґрунтування вибору засобів реалізації системи ....................................... 32
3.2. Проєктування та прототипування web-сервісу ............................................ 39

Змн. Арк. № докум. Підпис Дата
Розроб. Губар В.Г. Літ. Арк. Акрушів
Перевір. Катаєв Д.С. Вебсервіс планування та контролю 2 65
Реценз. особистого бюджету.

Пояснювальна записка ФІТІС, кафедра ІТП,
Н. Контр. WEB-2211
Затверд. Прокопенко Т.О.

3.3. Програмна реалізація web-сервісу ................................................................ 44
3.4. Тестування розробленої системи .................................................................. 50
3.5. Аналіз отриманих результатів ....................................................................... 53
3.6. Висновки до розділу 3 ................................................................................... 54
ВИСНОВКИ ............................................................................................................ 56
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ............................................................. 58
ДОДАТOK A ........................................................................................................... 61

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

СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ

ACID (Atomicity, Consistency, Isolation, Durability) – властивості транзакцій
бази даних (атомарність, узгодженість, ізольованість, довговічність).
AI (Artificial Intelligence) – штучний інтелект.
API (Application Programming Interface) – інтерфейс програмування
застосунків.
CSRF (Cross-Site Request Forgery) – міжсайтова підробка запиту.
DTO (Data Transfer Object) – обʼєкт передачі даних.
E2E (End-to-End) – наскрізне тестування.
ER-diagram (Entity-Relationship diagram) – діаграма «сутність-звʼязок».
HTTP (HyperText Transfer Protocol) – протокол передавання гіпертексту.
JSON (JavaScript Object Notation) – текстовий формат обміну даними.
JWT (JSON Web Token) – веб-токен на основі JSON для автентифікації.
LLM (Large Language Model) – велика мовна модель.
ORM (Object-Relational Mapping) – обʼєктно-реляційне відображення.
REST (Representational State Transfer) – архітектурний стиль проєктування
API.
SOLID (Single responsibility, Open-closed, Liskov substitution, Interface
segregation, Dependency inversion) – принципи обʼєктно-орієнтованого
проєктування.
SQL (Structured Query Language) – мова структурованих запитів.
UI (User Interface) – користувацький інтерфейс.
UML (Unified Modeling Language) – уніфікована мова моделювання.
URL (Uniform Resource Locator) – уніфікований локатор ресурсів.
UX (User Experience) – користувацький досвід.
XSS (Cross-Site Scripting) – міжсайтовий скриптинг.
БД – база даних.
ПЗ – програмне забезпечення.
СУБД – Система управління базами даних.
Арк.
ЧДТУ 262206.004.ПЗ
4
Змн. Арк. № докум. Підпис Дата

ВСТУП

Ефективне управління особистими фінансами стає одним із ключових
чинників фінансової стабільності та якості життя. Однак розвиток цифрової
комерції та спрощення процедур онлайн-оплат збільшують імовірність
непередбачуваних та імпульсивних витрат. Відсутність системного фінансового
планування часто призводить до нестачі коштів до моменту наступного
надходження доходів та порушує баланс індивідуального або сімейного
бюджету.
За даними досліджень у сфері поведінкової економіки, основна причина
даних не в дефіциті даних про витрати, а в нестачі інструментів, які
перетворюють сухі цифри на зрозумілі життєві орієнтири [1]. Наявні на ринку
рішення здебільшого обмежуються фіксацією транзакцій та побудовою звітів.
Актуальність теми підтверджується зростаючим інтересом до концепції
«усвідомленого споживання»: користувачі прагнуть не просто відстежувати
витрати, а свідомо керувати своїми фінансовими рішеннями ще до моменту
здійснення покупки [2]. Зростання рівня фінансової грамотності серед молоді
формує запит на нові інструменти планування бюджету, що поєднують
автоматизацію, аналітику та механізми стримування імпульсивних витрат.
Метою роботи є розробка web-сервісу планування та контролю особистого
бюджету FinMind з використанням сучасних web-технологій, що реалізує
концепцію конвертації грошових витрат у робочий час користувача та забезпечує
проактивне управління фінансовою поведінкою на основі алгоритмів
прогнозування та інструментів штучного інтелекту.
Для досягнення поставленої мети необхідно вирішити такі задачі:
1. Проаналізувати предметну область управління особистим бюджетом та
визначити основні проблеми, які потребують вирішення засобами інформаційних
технологій.
2. Провести критичний огляд існуючих аналогів – Saldo Finance, Spendee та
Monefy – та виявити їх переваги і недоліки.
Арк.
ЧДТУ 262206.004.ПЗ
5
Змн. Арк. № докум. Підпис Дата

3. Сформулювати та обґрунтувати технічне завдання, визначити вимоги до
функціоналу, архітектури та інтерфейсу web-сервісу.
4. Обґрунтувати вибір технологій для реалізації системи та спроєктувати
архітектуру застосунку і структуру бази даних.
5. Реалізувати web-сервіс FinMind з ключовими функціональними
модулями: динамічним розрахунком денного ліміту Safe-to-Spend, конвертацією
витрат у робочий час, таймером охолодження для списку бажань та модулем AI-
інсайтів.
6. Протестувати розроблену систему та оцінити її відповідність
сформульованим вимогам.
Методи дослідження. У роботі використовуються методи системного
аналізу для дослідження предметної області та огляду аналогів, методи об’єктно-
орієнтованого проєктування для побудови архітектури системи, методи
реляційного моделювання для проєктування бази даних, алгоритмічні методи для
реалізації логіки динамічного розрахунку бюджетного ліміту та прогнозування
касових розривів, а також стандартні методи функціонального тестування для
оцінки якості розробленої системи.
Практичне значення отриманих результатів полягає у готовності
розробленого web-сервісу FinMind до практичного використання через браузер
без встановлення додаткового програмного забезпечення.
Структура роботи. Робота складається зі вступу, трьох розділів, висновків,
списку використаних джерел та додатків. У першому розділі проводиться аналіз
предметної області управління особистим бюджетом, здійснюється огляд
аналогів, а також формулюється постановка задачі. Другий розділ присвячений
обґрунтуванню технічного завдання: визначенню вимог до функціоналу,
архітектури, бази даних та інтерфейсу web-сервісу. У третьому розділі
описується безпосередня розробка системи – від обґрунтування вибору
технологій до реалізації, тестування та оцінки отриманого результату.

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

РОЗДІЛ 1. ПОСТАНОВКА ЗАДАЧІ ТА ОГЛЯД ІСНУЮЧИХ РІШЕНЬ

У даному розділі проводиться системний аналіз предметної області
управління особистим бюджетом та досліджується проблематика контролю
фінансової поведінки в умовах цифровізації економіки. Здійснюється огляд
сучасних інформаційних сервісів для обліку фінансів із визначенням їхніх
переваг та концептуальних обмежень. На основі отриманих результатів
формулюється загальна постановка задачі на розробку web-сервісу планування
та контролю бюджету, що інтегрує класичні методи програмної автоматизації з
інструментами поведінкової психології.

1.1. Аналіз предметної області та проблематики управління особистим
бюджетом
Особистий бюджет як економічна категорія являє собою систему
планування та обліку доходів і витрат окремої людини за визначений проміжок
часу. Управління особистим бюджетом охоплює широкий спектр процесів – від
запису щоденних дрібниць до формування довгострокових фінансових цілей і
оцінки можливих ризиків. З поширенням цифрових технологій усе більша
частина цих процесів переходить у цифровий формат: з’являються нові
можливості для аналізу витрат та автоматизації рутинних операцій, які раніше
вимагали значних зусиль.
Попри доступність великої кількості інструментів для обліку фінансів,
проблема ефективного управління особистим бюджетом залишається
актуальною для переважної більшості користувачів. Дослідження у сфері
поведінкової економіки свідчать, що головною причиною фінансових труднощів
є не брак інформації про стан рахунків, а когнітивні викривлення, що заважають
приймати раціональні рішення в момент здійснення покупки. Серед найбільш
поширених із них виділяють ефект негайного задоволення, схильність до
недооцінки майбутніх витрат та відсутність суб’єктивного зв’язку між грошовою
сумою та реальною «ціною» у вигляді витраченого часу [2].
Арк.
ЧДТУ 262206.004.ПЗ
7
Змн. Арк. № докум. Підпис Дата

З огляду на зазначене, управління особистим бюджетом доцільно
розглядати не лише як технічне завдання автоматизації обліку, а як комплексну
задачу на перетині інформаційних технологій та поведінкової психології. Ця
предметна область характеризується такими ключовими процесами та
поняттями.
Планування бюджету – це процес розподілу очікуваних доходів між
категоріями витрат та цілями заощадження до початку звітного періоду. Якісне
планування передбачає врахування не лише обов’язкових платежів, а й
нерегулярних витрат та формування фінансової подушки безпеки.
Контроль витрат – це систематична фіксація фактичних витрат із
подальшим порівнянням із запланованими показниками. Традиційний підхід до
контролю є реактивним: користувач дізнається про перевитрату вже після її
здійснення, що унеможливлює коригування поведінки у потрібний момент.
Проактивний підхід, навпаки, передбачає надання користувачеві інформації про
допустимий залишок ще до здійснення витрат – саме на цьому принципі
базується концепція денного ліміту Safe-to-Spend, реалізована у розроблюваному
сервісі.
Касовий розрив – ситуація, коли наприкінці розрахункового періоду
фактичні витрати перевищують доходи або залишок коштів виявляється
недостатнім для покриття обов’язкових платежів. Касовий розрив є одним із
найбільш поширених фінансових стресорів для фізичних осіб і, як правило, є
наслідком не різкого падіння доходів, а систематичного перевищення денних
витрат протягом місяця.
Імпульсивні покупки – незаплановані придбання, здійснені під впливом
емоційного стану або маркетингового стимулу, а не на основі усвідомленої
потреби. За оцінками дослідників споживчої поведінки, від 40 до 80% покупок у
роздрібній торгівлі можуть бути класифіковані як імпульсивні. Для протидії
цьому явищу у поведінковій психології використовується техніка
«охолодження» – введення часового проміжку між виникненням бажання
придбати товар та фактичним здійсненням покупки [3]. Цей принцип покладено
Арк.
ЧДТУ 262206.004.ПЗ
8
Змн. Арк. № докум. Підпис Дата

в основу модуля Wishlist із таймером блокування, що реалізується у web-сервісі
FinMind.
Конвертація грошей у час – техніка усвідомленого споживання,
запропонована у роботах з особистих фінансів, зокрема популяризована у книзі
Вікі Робін «Your Money or Your Life». Суть підходу полягає у перерахунку
вартості будь-якої покупки у кількість годин праці, необхідних для заробітку
відповідної суми. Така конвертація робить абстрактну грошову суму конкретною
та особистісно значущою, що суттєво підвищує усвідомленість фінансових
рішень [4]. Наприклад, спонтанна покупка за 800 гривень при погодинній ставці
200 гривень перетворюється на чотири години робочого часу – і саме таке
формулювання значно ефективніше стримує імпульсивну поведінку, ніж
абстрактна цифра у грошовому вираженні.
Також уваги заслуговує роль штучного інтелекту в управлінні особистим
бюджетом. Застосування ШІ дозволяє перейти від простого відображення
статистики до генерації персоналізованих рекомендацій, заснованих на аналізі
індивідуальних патернів фінансової поведінки конкретного користувача.
Таким чином, предметна область управління особистим бюджетом охоплює
три взаємопов’язані рівні: технічний (автоматизація обліку та аналітика даних),
поведінковий (інструменти впливу на фінансові рішення в момент їх прийняття)
та інтелектуальний (прогнозування ризиків і генерація персоналізованих
рекомендацій). Ефективний інформаційний сервіс для планування бюджету має
інтегрувати всі три рівні в єдину зручну платформу – саме цей принцип визначає
основу web-сервісу FinMind, розробка якого є предметом даної кваліфікаційної
роботи.

1.2. Огляд та критичний аналіз існуючих аналогів інформаційних
сервісів
Для формування обґрунтованих вимог до розроблюваного web-сервісу
FinMind та визначення його конкурентних переваг необхідно провести детальний
аналіз існуючих рішень у сфері управління особистим бюджетом. Критерії
Арк.
ЧДТУ 262206.004.ПЗ
9
Змн. Арк. № докум. Підпис Дата

аналізу охоплюють функціональні можливості системи, підхід до планування
бюджету, наявність інструментів впливу на фінансову поведінку, якість
аналітики, технічну доступність та зручність інтерфейсу. Об’єктами аналізу
обрано три застосунки, що мають значну аудиторію користувачів та
представляють різні підходи до вирішення задачі обліку фінансів: Saldo Finance,
Spendee та Monefy.

1.2.1. Saldo Finance: україномовний трекер витрат із плануванням за
категоріями
Saldo Finance – це мобільний застосунок для управління особистими
фінансами, розроблений українською компанією Saldo Apps. Застосунок
позиціонується як комплексний інструмент для ведення бюджету, що поєднує
облік доходів і витрат, планування бюджету за категоріями та аналіз фінансових
показників. Saldo Finance має версії для платформ iOS та Android і є одним із
найбільш відомих україномовних фінансових застосунків на вітчизняному ринку,
що робить його особливо релевантним для порівняння з розроблюваним web-
сервісом FinMind [5].
Основу функціоналу Saldo Finance становить класична модель обліку
транзакцій із ручним або напівавтоматичним введенням витрат і доходів. Кожна
транзакція прив’язується до однієї з категорій, перелік яких користувач може
розширювати та редагувати. Застосунок підтримує ведення кількох рахунків
одночасно – готівкового, карткового та інших, що дозволяє відображати повну
картину фінансового стану. Реалізована функція планування бюджету за
категоріями: користувач встановлює ліміт витрат на місяць для кожної категорії,
а сервіс відображає поточний відсоток використання цього ліміту. Присутній
базовий модуль аналітики у вигляді кругових діаграм і стовпчастих графіків
розподілу витрат. Saldo Finance також підтримує експорт даних у форматі CSV
та PDF, що є корисною функцією для користувачів, які ведуть паралельний облік
у таблицях.
Арк.
ЧДТУ 262206.004.ПЗ
1 0
Змн. Арк. № докум. Підпис Дата

Інтерфейс Saldo Finance (рис. 1.1) виконаний у мінімалістичному стилі з
акцентом на читабельність даних. Головний екран відображає загальний баланс,
динаміку витрат і доходів за поточний місяць та список останніх транзакцій.
Навігація між розділами здійснюється через нижнє меню з чотирма вкладками.
Загалом інтерфейс є зрозумілим для користувача із базовим досвідом роботи з
фінансовими застосунками, однак не позбавлений певних складнощів при
першому знайомстві – зокрема, налаштування бюджетних лімітів для нових
користувачів може виявитися неочевидним процесом.

Рисунок 1.1 – Скріншот інтерфейсу Saldo Finance
Серед ключових переваг Saldo Finance слід відзначити наявність
україномовного інтерфейсу, що є важливим фактором для вітчизняної аудиторії.
Застосунок підтримує мультивалютність, що актуально в умовах використання
кількох рахунків у різних валютах. Сервіс бюджетування за категоріями є
достатньо гнучкою і дозволяє налаштувати ліміти відповідно до індивідуальних
потреб. Позитивним є й те, що застосунок не вимагає обов’язкової реєстрації для
початку роботи – дані можуть зберігатися локально на пристрої.
Арк.
ЧДТУ 262206.004.ПЗ
1 1
Змн. Арк. № докум. Підпис Дата

Попри наявний функціонал, Saldo Finance має ряд концептуальних
обмежень, які суттєво знижують його ефективність як інструменту управління
фінансовою поведінкою. По-перше, підхід до бюджетування є виключно
реактивним: сервіс показує, скільки вже витрачено у межах категорійного ліміту,
але не надає динамічного розрахунку того, скільки можна витратити сьогодні з
урахуванням решти днів місяця. По-друге, застосунок не містить жодних
інструментів впливу на фінансову поведінку в момент прийняття. По-третє,
аналітика обмежується описовою статистикою і не включає прогностичних
алгоритмів: сервіс не попереджає про ризик касового розриву до кінця місяця, не
виявляє аномалій у витратах.

1.2.2. Spendee: комплексна платформа з підтримкою Open Banking
Spendee – це міжнародний застосунок для управління особистими
фінансами, розроблений чеською компанією Cleevio. Застосунок доступний на
платформах iOS та Android, а також має web-версію з обмеженим функціоналом.
Spendee позиціонується як більш просунуте рішення порівняно зі стандартними
трекерами витрат – зокрема, він підтримує підключення банківських рахунків та
автоматичний імпорт транзакцій через відкриті банківські API, що є однією з
його ключових конкурентних переваг. Застосунок набув значної популярності у
Центральній та Східній Європі завдяки підтримці великої кількості банків
регіону [6].
Функціональна архітектура Spendee побудована навколо концепції
«гаманців» – відокремлених фінансових просторів, кожен з яких може
відповідати окремому рахунку, картці або меті. Ключовою технічною
особливістю є підтримка автоматичного підключення банківських рахунків через
Open Banking: транзакції імпортуються до застосунку без ручного введення, що
суттєво знижує бар’єр регулярного ведення обліку. Присутній модуль
бюджетування, що дозволяє встановлювати ліміти як на рівні категорій, так і на
рівні окремих гаманців. Аналітичний розділ включає різноманітні типи
візуалізацій: кругові діаграми, лінійні графіки динаміки, порівняльні діаграми по
Арк.
ЧДТУ 262206.004.ПЗ
1 2
Змн. Арк. № докум. Підпис Дата

місяцях. Застосунок підтримує спільний доступ до гаманців, що дозволяє
використовувати його для ведення сімейного бюджету кількома членами
домогосподарства. У преміум-версії доступний модуль фінансових цілей із
відстеженням прогресу накопичення.
Інтерфейс Spendee (рис. 1.2) відзначається сучасним візуальним дизайном із
використанням кольорового кодування категорій і динамічних анімацій
переходів. Головний екран відображає загальний баланс усіх підключених
гаманців, графік витрат за поточний місяць та останні транзакції. Дизайн є
інтуїтивно зрозумілим для нових користувачів завдяки добре продуманому
процесу онбордингу, що покроково знайомить із ключовими функціями
застосунку. Разом із тим перенасиченість інформацією на окремих екранах може
ускладнювати сприйняття для користувачів, які цінують мінімалізм.

Рисунок 1.2 – Скріншот інтерфейсу Spendee
Головною перевагою Spendee є автоматичний імпорт банківських
транзакцій, який усуває найбільший бар’єр регулярного ведення бюджету –
необхідність ручного введення кожної операції. Розвинена система аналітики з
порівнянням показників між різними часовими проміжками дозволяє виявляти
тенденції у фінансовій поведінці. Підтримка спільних гаманців робить Spendee
Арк.
ЧДТУ 262206.004.ПЗ
1 3
Змн. Арк. № докум. Підпис Дата

затребуваним у сегменті сімейного бюджетування. Наявність web-версії, нехай і
з обмеженим функціоналом, розширює точки доступу до системи.
Незважаючи на технічну розвиненість, Spendee має ряд суттєвих
концептуальних обмежень. Насамперед, як і більшість аналогів, застосунок
залишається в рамках реактивної парадигми: він досконало показує, що вже
сталося з грошима, але не допомагає приймати правильні рішення до моменту
здійснення витрат. Функція бюджетування за категоріями не трансформується у
зрозумілий щоденний. Аналітика, попри її візуальну розвиненість, є описовою, а
не прогностичною – жодних попереджень про наближення касового розриву
сервіс не генерує.

1.2.3. Monefy як приклад мінімалістичного обліку витрат
Monefy – це мобільний застосунок для швидкого обліку витрат і доходів,
розроблений компанією Intellect D.o.o. Застосунок доступний на платформах iOS
та Android і відомий своєю концепцією «мінімум дій для додавання транзакції» –
вся взаємодія з основним функціоналом спроєктована таким чином, щоб фіксація
витрати займала не більше кількох секунд. Monefy набув широкої популярності
саме завдяки простоті: він не претендує на роль комплексної фінансової
платформи, а вирішує одну задачу – максимально зручний облік транзакцій [7].
Функціональна модель Monefy є свідомо мінімалістичною. Ядром
застосунку є інтерфейс у вигляді кругової діаграми, де кожен сектор відповідає
категорії витрат. Додавання нової витрати здійснюється натисканням на
відповідний сектор, після чого відкривається числова клавіатура для введення
суми – жодних додаткових полів і підтверджень. Присутній базовий модуль
фільтрації за часовим проміжком та підтримка кількох рахунків. Застосунок
дозволяє налаштувати бюджет на місяць у вигляді загальної суми, після чого
відображає прогрес витрачання цього бюджету на головному екрані. Є функція
конвертації валют на основі актуальних курсів.
Інтерфейс Monefy (рис. 1.3) є одним із найбільш нестандартних серед
фінансових застосунків: замість традиційного списку транзакцій або набору
Арк.
ЧДТУ 262206.004.ПЗ
1 4
Змн. Арк. № докум. Підпис Дата

вкладок користувач бачить велику інтерактивну кругову діаграму, що займає
більшу частину екрана. Такий підхід забезпечує миттєве візуальне сприйняття
структури витрат без будь-якого аналізу тексту.

Рисунок 1.3 – Скріншот інтерфейсу Monefy
Визначальною перевагою Monefy є абсолютна простота та швидкість
додавання транзакцій – це прямо вирішує одну з ключових причин, через яку
користувачі кидають ведення бюджету: лінь щоразу відкривати застосунок і
витрачати час на введення даних. Застосунок не перевантажений зайвим
функціоналом, що робить його ідеальним вибором для користувачів, яким
потрібен простий щоденник витрат без складного налаштування. Низький поріг
входження та відсутність обов’язкової реєстрації забезпечують швидкий старт.
Свідома мінімалістичність Monefy, що є його головною перевагою,
водночас формує значні функціональні обмеження. Система бюджетування
зводиться до встановлення єдиної загальної суми на місяць без розбивки за
категоріями і без динамічного перерахунку денного ліміту – користувач бачить
лише відсоток витраченого від загального бюджету, що є надто агрегованим
показником для практичного управління фінансами. Аналітичний блок є
мінімальним, кругова діаграма з можливістю фільтрації за датою.

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

1.3. Постановка задачі розробки web-сервісу
За результатами аналізу предметної області та критичного огляду існуючих
аналогів сформовано розуміння функціональних прогалин наявних рішень та
визначено напрямок розробки web-сервісу FinMind.
Загальна постановка задачі. Необхідно розробити web-сервіс планування та
контролю особистого бюджету, який реалізує проактивну модель управління
фінансовою поведінкою користувача. На відміну від існуючих аналогів, що
функціонують у межах реактивної парадигми обліку витрат, розроблюваний
сервіс має впливати на фінансові рішення користувача до моменту їх прийняття,
а не лише фіксувати їх.
Об’єктом розробки є web-сервіс FinMind – інформаційний сервіс для
планування та контролю особистого бюджету, що функціонує як клієнт-
серверний web-додаток і забезпечує повний цикл управління фінансами
користувача: від первинного налаштування під час онбордингу до щоденного
моніторингу витрат, прогнозування фінансових ризиків та отримання
персоналізованих рекомендацій від штучного інтелекту.
Сервіс орієнтований на фізичних осіб віком від 18 до 45 років, які мають
стабільний або відносно стабільний місячний дохід і прагнуть отримати більший
контроль над власними витратами.
На основі виявлених недоліків аналогів та потреб цільової аудиторії
сформульовано перелік функціональних задач, які має вирішувати web-сервіс
FinMind.
Першою і центральною задачею є реалізація динамічного денного ліміту
Safe-to-Spend. Сервіс має щоденно розраховувати суму, яку користувач може
витратити протягом поточного дня, не порушуючи загального фінансового плану
на місяць. Розрахунок повинен враховувати залишок місячного бюджету після
вирахування обов’язкових платежів і цілей заощадження, кількість днів, що
залишилися до кінця місяця, а також перенесення невикористаного залишку з
попередніх днів або зменшення майбутнього ліміту у разі перевитрати. Таким
чином, користувач щоранку отримує одну зрозумілу цифру, яка відповідає на
Арк.
ЧДТУ 262206.004.ПЗ
1 6
Змн. Арк. № докум. Підпис Дата

питання «скільки я можу витратити сьогодні» без необхідності самостійно
аналізувати стан рахунків.
Другою задачею є реалізація механізму конвертації грошових витрат у
робочий час. При додаванні будь-якої транзакції або при перегляді позиції у
списку бажань сервіс має автоматично перераховувати грошову суму у кількість
годин і хвилин праці користувача на основі його погодинної ставки, що
вводиться під час онбордингу. Така конвертація має відображатися поруч із
грошовою сумою як додатковий контекст, що підвищує усвідомленість
фінансових рішень.
Третьою задачею є розробка модуля Wishlist із таймером охолодження.
Сервіс має надавати користувачеві можливість додавати до списку бажань
товари або послуги, придбання яких він розглядає, із зазначенням їх вартості.
Після додавання позиція блокується для «покупки» на визначений користувачем
час від 24 до 72 годин. Протягом цього часу поряд із позицією відображається
зворотний таймер, а також вартість у перерахунку на робочий час. Після
закінчення таймера користувач отримує сповіщення і може прийняти
усвідомлене рішення щодо покупки. Позиції, від яких користувач відмовився
після охолодження, переміщуються до архіву та можуть використовуватися для
аналізу патернів імпульсивної поведінки.
Четвертою задачею є реалізація модуля AI-інсайтів та прогнозування
касового розриву. На основі даних про поточний темп витрат, залишок бюджету
та кількість днів до кінця місяця сервіс має розраховувати прогнозований баланс
на кінець місяця і сповіщати користувача про ризик касового розриву завчасно.
Окрім алгоритмічного прогнозування, Сервіс має інтегруватися з великою
мовною моделлю для генерації текстових персоналізованих порад на основі
аналізу фінансової поведінки конкретного користувача. Поради мають
відображатися на головному екрані у вигляді коротких сповіщень і
оновлюватися відповідно до актуального стану бюджету.
П’ятою задачею є забезпечення зручного процесу онбордингу для нових
користувачів. Сервіс має збирати необхідні вхідні дані – місячний дохід, перелік
Арк.
ЧДТУ 262206.004.ПЗ
1 7
Змн. Арк. № докум. Підпис Дата

обов’язкових платежів та погодинну ставку – у форматі покрокового степера, що
не перевантажує користувача великою кількістю полів одночасно і пояснює
призначення кожного параметра.
Вимоги до форми реалізації. Сервіс має бути реалізована як web-сервіс із
клієнт-серверною архітектурою, що забезпечує доступ через браузер без
встановлення додаткового програмного забезпечення. Інтерфейс має бути
адаптивним і коректно відображатися як на екранах персональних комп’ютерів,
так і на мобільних пристроях. Сервіс має забезпечувати реєстрацію та
автентифікацію користувачів із надійним та безпечним зберіганням
персональних фінансових даних.
Результатом розробки має стати функціонально повний web-сервіс FinMind,
готовий до практичного використання, що реалізує усі описані вище
функціональні задачі та усуває концептуальні обмеження, виявлені в ході аналізу
аналогів.

1.4. Висновки до розділу 1
У першому розділі проведено системний аналіз предметної області
управління особистим бюджетом, здійснено огляд існуючих аналогічних
інформаційних сервісів та постановлено задачу на розробку web-сервісу FinMind.
У ході аналізу предметної області визначено ключові поняття та процеси,
що складають основу управління особистим бюджетом: планування доходів і
витрат, контроль транзакцій, запобігання касовим розривам та боротьба з
імпульсивними покупками. Встановлено, що головною причиною фінансових
труднощів більшості користувачів є не брак інформації про стан рахунків, а
когнітивні викривлення, що заважають приймати усвідомлені рішення
безпосередньо в момент здійснення витрат. Обґрунтовано доцільність інтеграції
інструментів поведінкової психології – зокрема техніки конвертації грошей у
робочий час та механізму охолодження перед покупкою – у функціональну
модель інформаційного сервісу для планування бюджету.
Арк.
ЧДТУ 262206.004.ПЗ
1 8
Змн. Арк. № докум. Підпис Дата

За результатами критичного аналізу трьох існуючих аналогів – Saldo
Finance, Spendee та Monefy – встановлено, що всі розглянуті системи
функціонують у межах реактивної парадигми: вони фіксують факт уже
здійснених витрат і формують звітність про минулі події, однак не впливають на
процес прийняття фінансових рішень до моменту їх здійснення. Виявлено
спільні концептуальні обмеження аналогів: відсутність динамічного денного
ліміту з перенесенням залишку, відсутність інструментів усвідомленого
споживання, відсутність прогностичних алгоритмів попередження касового
розриву та відсутність персоналізованих рекомендацій на основі штучного
інтелекту.
На основі отриманих результатів сформульовано постановку задачі
розробки web-сервісу FinMind як проактивної системи управління фінансовою
поведінкою користувача. Визначено п’ять ключових функціональних задач
системи: реалізація динамічного денного ліміту Safe-to-Spend, механізму
конвертації витрат у робочий час, модуля Wishlist із таймером охолодження,
модуля AI-інсайтів із прогнозуванням касового розриву та зручного онбордингу.

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

РОЗДІЛ 2. ОБҐРУНТУВАННЯ ТЕХНІЧНОГО ЗАВДАННЯ

У даному розділі визначаються та обґрунтовуються конкретні технічні
вимоги до web-сервісу FinMind. Обґрунтування технічного завдання охоплює
чотири взаємопов’язані аспекти: вимоги до функціоналу та алгоритмів системи,
вимоги до архітектури та структури баз даних, вимоги до інтерфейсу
користувача та навігації, а також обґрунтування доцільності створення web-
ресурсу. Сукупність визначених вимог слугує технічним завданням для
практичної реалізації системи та базою для оцінки відповідності розробленого
рішення поставленим цілям у ході тестування.

2.1. Вимоги до функціоналу та алгоритмів web-сервісу FinMind
Функціональні вимоги до web-сервісу FinMind формуються на основі
постановленої задачі. Вимоги структуровано за функціональними модулями
системи, кожен із яких вирішує окрему задачу у межах загальної концепції
проактивного управління фінансовою поведінкою користувача.
Модуль онбордингу.
Сервіс має забезпечувати покроковий процес первинного налаштування для
нових користувачів у форматі степера. Онбординг є обов’язковим етапом перед
початком роботи із системою, оскільки всі подальші розрахунки базуються на
даних, що збираються під час цього процесу. Степер має складатися послідовних
кроків, кожен з яких присвячений одній групі вхідних параметрів.
Після завершення онбордингу сервіс автоматично розраховує базовий
місячний бюджет за формулою:
Бюджет = Дохід - Сума обов’язкових платежів - Ціль заощадження
Отримана сума є основою для подальшого розрахунку денного ліміту Safe-
to-Spend.
Модуль автентифікації та управління обліковим записом.
Сервіс має забезпечувати реєстрацію користувача за адресою електронної
пошти та паролем. Пароль має зберігатися у захищеному вигляді із
Арк.
ЧДТУ 262206.004.ПЗ
2 0
Змн. Арк. № докум. Підпис Дата

застосуванням алгоритму хешування. Передбачається функція відновлення
пароля через електронну пошту. Після реєстрації та завершення онбордингу всі
дані користувача зберігаються на сервері та доступні при вході з будь-якого
пристрою через браузер. У розділі профілю користувач має мати можливість
редагувати параметри, введені під час онбордингу. Після збереження змін сервіс
має автоматично перераховувати всі залежні показники.
Модуль Safe-to-Spend та алгоритм розрахунку денного ліміту.
Даний модуль є центральним елементом системи і реалізує проактивну
модель бюджетування. Алгоритм розрахунку денного ліміту має виконуватися
щодня і ґрунтується на таких вхідних параметрах: базовий місячний бюджет,
фактичні витрати за поточний місяць на момент розрахунку, кількість днів, що
залишилися до кінця поточного місяця включно з поточним днем.
Розрахунок денного ліміту здійснюється за таким алгоритмом. Спочатку
визначається залишок вільного бюджету на поточний момент як різниця між
базовим місячним бюджетом та сумою фактичних витрат за поточний місяць, що
не входять до категорії обов’язкових платежів. Отриманий залишок ділиться на
кількість днів, що залишилися до кінця місяця, – результатом є рекомендована
сума витрат на поточний день.
Алгоритм має передбачати два сценарії відхилення від плану. У разі якщо
фактичні витрати за попередній день були меншими за денний ліміт,
невикористаний залишок додається до бюджету наступних днів, що автоматично
збільшує ліміт. У разі якщо фактичні витрати перевищили денний ліміт, сума
перевищення рівномірно розподіляється між рештою днів місяця, що зменшує
майбутній ліміт. Таким чином, сервіс забезпечує автоматичне самобалансування
бюджету протягом місяця без необхідності ручного коригування з боку
користувача.
Значення Safe-to-Spend має відображатися на головному екрані як основна
цифра дня, що є першим, що бачить користувач при відкритті застосунку. Поруч
із грошовою сумою має відображатися її еквівалент у робочому часі.
Модуль фіксації транзакцій.
Арк.
ЧДТУ 262206.004.ПЗ
2 1
Змн. Арк. № докум. Підпис Дата

Сервіс має забезпечувати швидке додавання транзакцій через модальне
вікно, що викликається кнопкою на головному екрані. Форма додавання
транзакції має містити такі поля: сума, категорія витрат або доходів, дата та час.
Перелік категорій має включати стандартний набір – харчування, транспорт,
розваги, одяг, здоров’я, комунальні послуги, інше. Після додавання витрати
сервіс має миттєво перераховувати залишок Safe-to-Spend на поточний день і
відображати оновлене значення. Сервіс має підтримувати додавання як витрат,
так і доходів, що дозволяє враховувати нерегулярні надходження протягом
місяця.
Модуль Wishlist із таймером охолодження.
Список бажань є інструментом усвідомленого споживання і має
реалізовувати такі функціональні вимоги. Користувач має можливість додати до
списку будь-який товар або послугу, вказавши назву, вартість, необов’язковий
коментар та бажаний час охолодження – від 24 до 72 годин. Після додавання
позиція отримує статус «активна» і для неї запускається зворотний таймер.
Протягом дії таймера поряд із позицією має відображатися час, що
залишився до його закінчення, вартість у грошовому еквіваленті та вартість у
перерахунку на робочий час. Кнопка підтвердження покупки має бути
заблокована до закінчення таймера, що унеможливлює імпульсивне придбання.
Після закінчення таймера користувач отримує сповіщення і може підтвердити
покупку і автоматично додати витрату до трекера або відмовитися від покупки.
Позиції зі статусом «куплено» та «відмовлено» переміщуються до архіву Wishlist
і зберігаються для аналізу поведінки користувача.
Модуль AI-інсайтів та прогнозування.
Модуль штучного інтелекту має реалізовувати дві функціональні задачі:
алгоритмічне прогнозування касового розриву та генерацію текстових
рекомендацій через інтеграцію з великою мовною моделлю.
Алгоритм прогнозування касового розриву має щоденно розраховувати
прогнозований залишок бюджету на кінець поточного місяця на основі
середньоденного темпу витрат за останні сім днів та кількості днів, що
Арк.
ЧДТУ 262206.004.ПЗ
2 2
Змн. Арк. № докум. Підпис Дата

залишилися до кінця місяця. Якщо прогнозований залишок є від’ємним або
меншим за встановлений пороговий показник, сервіс має відображати на
головному екрані попередження про ризик касового розриву із зазначенням
прогнозованої суми дефіциту та рекомендованого нового денного ліміту для
запобігання йому.
Модуль аналітики.
Сервіс має відображати кругову діаграму розподілу витрат за категоріями за
обраний часовий проміжок, а також повну хронологічну історію транзакцій із
можливістю фільтрації за категорією, типом операції та довільним часовим
діапазоном. Аналітичний модуль має бути доступний через окрему вкладку
навігації і не перевантажувати головний екран, що сфокусований на поточному
дні.
Вимоги до сповіщень.
Сервіс має реалізовувати механізм внутрішніх сповіщень, що
відображаються у межах інтерфейсу застосунку. Сповіщення мають
генеруватися у таких ситуаціях: закінчення таймера охолодження для позиції у
Wishlist, виявлення ризику касового розриву за результатами щоденного
прогнозу, перевищення денного ліміту Safe-to-Spend, а також поява нового AI-
інсайту.

2.2. Вимоги до архітектури та структури баз даних
Web-сервіс FinMind має бути побудований за трирівневою клієнт-серверною
архітектурою, що передбачає чіткий розподіл відповідальності між трьома
рівнями: рівнем представлення, рівнем бізнес-логіки та рівнем даних. Такий
підхід є стандартом проєктування сучасних web-орієнтованих систем і
забезпечує незалежність кожного рівня, спрощує супровід і тестування системи
та створює умови для масштабування окремих компонентів без необхідності
перебудови всієї системи [8]. Загальна схема трирівневої архітектури web-сервісу
FinMind наведена на рисунку 2.1.
Арк.
ЧДТУ 262206.004.ПЗ
2 3
Змн. Арк. № докум. Підпис Дата

Рисунок 2.1 – Структурна схема трирівневої клієнт-серверної архітектури
web-сервісу FinMind
Відповідно до наведеної схеми, архітектура системи FinMind складається з
таких взаємопов’язаних рівнів:
1. Рівень представлення (Client Tier / Frontend). Відповідає за взаємодію з
користувачем, відображення даних та збір вхідної інформації. Цей рівень
виконується на стороні клієнта і містить усі компоненти користувацького
інтерфейсу: форми онбордингу, інформаційні панелі, графіки аналітики та
Арк.
ЧДТУ 262206.004.ПЗ
2 4
Змн. Арк. № докум. Підпис Дата

списки бажань. Головна задача рівня – забезпечити зручний та швидкий
інтерфейс.
Вимоги до рівня представлення: обмін даними з сервером виключно через
REST API у форматі JSON; відсутність бізнес-логіки – усі обчислення
делегуються на наступний рівень; адаптивна верстка для коректного
відображення на різних пристроях.
2. Рівень бізнес-логіки (Application Tier / Backend). Є центральною ланкою
архітектури, де реалізуються ключові алгоритми та правила роботи системи. Цей
рівень приймає запити від клієнтської частини через REST API, виконує
автентифікацію та авторизацію користувача, після чого здійснює необхідні
операції. Саме на цьому рівні інкапсульовано: логіку розрахунку динамічного
ліміту «Safe-to-Spend»; відлік часу для таймерів «Cooling-off»; математичну
конвертацію вартості витрат у робочі години; обробку запитів до зовнішніх
LLM-моделей для генерації персоналізованих фінансових порад; алгоритм
прогнозування касового розриву на кінець розрахункового місяця.
Вимоги до рівня бізнес-логіки: відповідність принципам REST-архітектури
при проєктуванні API-ендпоінтів; обов’язкова перевірка автентифікаційного
токену (JWT) для кожного захищеного запиту; ізоляція від рівня даних через шар
репозиторіїв або ORM, що виключає використання «сирих» SQL-запитів у логіці
застосунку; забезпечення атомарності операцій, що змінюють стан кількох
таблиць одночасно [9].
3. Рівень даних (Data Tier / Database). Відповідає за постійне, структуроване
та безпечне зберігання всієї інформації системи. Доступ до рівня даних є
ізольованим і здійснюється виключно через рівень бізнес-логіки, що
унеможливлює пряме втручання клієнтського застосунку в базу даних і
забезпечує цілісність інформації.
Вимоги до рівня даних: використання реляційної СУБД з підтримкою
транзакцій та забезпеченням властивостей ACID; визначення зовнішніх ключів
та каскадних правил видалення для підтримки референційної цілісності;
Арк.
ЧДТУ 262206.004.ПЗ
2 5
Змн. Арк. № докум. Підпис Дата

зберігання паролів виключно у хешованому вигляді; використання індексів на
полях, що є частими умовами фільтрації [10].
База даних системи FinMind проєктується за реляційною моделлю.
Виходячи з вимог до функціоналу, web-сайт оперує такими основними
сутностями: користувач, налаштування бюджету, транзакція, категорія, елемент
вішліста та AI-інсайт. Схема зв’язків між сутностями (ER-діаграма) наведена на
рисунку 2.2.

Рисунок 2.2 – ER-діаграма бази даних web-сервісу FinMind
Центральною сутністю є users – таблиця користувачів, що зберігає облікові
дані, погодинну ставку для конвертації витрат у робочий час та валютні
налаштування. З нею безпосередньо пов’язані всі інші сутності системи.
Фінансові параметри онбордингу винесено в окрему сутність
onboarding_result, що пов’язана з користувачем відношенням один-до-одного і
може оновлюватися незалежно від облікового запису.
Операційну основу системи складає сутність transactions, яка фіксує кожне
фінансове надходження або списання із прив’язкою до дати, типу та категорії.
Арк.
ЧДТУ 262206.004.ПЗ
2 6
Змн. Арк. № докум. Підпис Дата

Для реалізації вішліста виділено сутність wishlist_items, яка поряд із
базовими атрибутами товару зберігає параметри таймера охолодження:
тривалість блокування та розрахований момент розблокування.
Усі таблиці пов’язані через зовнішні ключі з каскадним видаленням
дочірніх записів (ON DELETE CASCADE), що забезпечує автоматичну
підтримку референційної цілісності без додаткової логіки на рівні застосунку
[11].

2.3. Вимоги до інтерфейсу користувача та навігації
Інтерфейс web-сервісу FinMind має відповідати принципам орієнтованого на
користувача проєктування (User-Centered Design), оскільки цільова аудиторія
системи не є технічно підготовленою та взаємодіє з нею щоденно в умовах
обмеженого часу. Головна мета інтерфейсу – мінімізувати когнітивне
навантаження, надаючи користувачу найважливішу фінансову інформацію у
доступній формі без зайвих дій.
Загальні вимоги до інтерфейсу. Інтерфейс має бути реалізований як
багатосторінковий web-сайт. Дизайн має дотримуватися принципу «мобільний
пристрій – пріоритет» (mobile-first), оскільки операції з особистим бюджетом
здебільшого виконуються зі смартфону.
Структура навігації. Основна навігація між розділами системи реалізується
через нижню панель навігації, яка забезпечує постійний доступ до трьох
головних розділів: Аналітики, Дашборду та Вішлісту. Такий підхід є стандартом
для мобільних розширень та дозволяє досягти будь-якого розділу за один дотик.
Схема навігаційних переходів між екранами системи наведена на рисунку 2.3.
Відповідно до наведеної схеми, навігаційний потік системи організовано
таким чином. Новий користувач після реєстрації проходить через екран
онбордингу, де послідовно вводить вхідні фінансові параметри. Після
завершення онбордингу та при кожному наступному вході авторизований
користувач потрапляє безпосередньо на Дашборд.

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

Рисунок 2.3 – Схема навігації web-сервісу FinMind
Кожен модуль системи має специфічні вимоги.
Екран онбордингу реалізується у форматі покрокового степера, де кожен
крок відповідає одній групі параметрів: доходи, обов’язкові платежі, ціль
заощаджень та погодинна ставка. Перехід до наступного кроку має блокуватися
до успішної валідації поточного, а прогрес заповнення має бути наочно
відображений.
Дашборд є головним екраном системи і має фокусуватися на поточному
стані бюджету. Домінуючим елементом екрану є показник Safe-to-Spend – сума,
доступна на поточний день. Нижче розміщуються останні транзакції та блок AI-
сповіщень. Кнопка швидкого додавання транзакції має бути постійно доступна
та викликати модальне вікно без переходу на окремий екран.
Екран аналітики надає розширений аналіз фінансової активності: графіки
динаміки витрат і доходів, розбивку за категоріями у вигляді кругової діаграми
Арк.
ЧДТУ 262206.004.ПЗ
2 8
Змн. Арк. № докум. Підпис Дата

та фільтри за часовим діапазоном. Відображення має адаптуватися до наявних
даних – за відсутності транзакцій показувати порожній стан із підказкою.
Екран вішлісту відображає список бажаних покупок із поділом на активні та
архівні. Для кожного елемента мають відображатися назва, вартість, конвертація
у робочі години та залишок часу до розблокування.
Екран профілю надає доступ до редагування базових фінансових
параметрів, встановлених під час онбордингу, та загальних налаштувань
застосунку.
Вимоги до ключових UI-компонентів. Модальне вікно додавання транзакції
має містити поля для введення суми, вибору категорії, типу операції (витрата або
дохід) та необов’язкового коментаря. Після збереження транзакції показник Safe-
to-Spend на дашборді має оновлюватися миттєво без перезавантаження сторінки.
Сповіщення від AI-підсистеми відображаються у вигляді карток із можливістю
відхилення та не мають перекривати основний вміст екрану.

2.4. Обґрунтування доцільності створення web-ресурсу
Необхідність розробки web-сервісу FinMind обумовлена сукупністю
факторів, що охоплюють як актуальність проблематики управління особистими
фінансами, так і наявні обмеження існуючих програмних рішень.
Управління особистим бюджетом залишається однією з найпоширеніших
проблем сучасного користувача. Імпульсивні витрати, відсутність розуміння
реальної «ціни» покупок у контексті витраченого часу та неспроможність
передбачити касові розриви наприкінці розрахункового місяця – це системні
поведінкові патерни, які не вирішуються простою фіксацією транзакцій. Існуючі
рішення здебільшого зосереджені на реєстрації та категоризації витрат,
залишаючи поза увагою проактивне попередження фінансових проблем та
поведінкову складову прийняття фінансових рішень [2].
Як було встановлено в ході аналізу існуючих рішень, жоден із розглянутих
сервісів не поєднує в єдиній системі динамічний денний ліміт витрат, механізм
конвертації вартості у робочі години та таймер охолодження для відкладених
Арк.
ЧДТУ 262206.004.ПЗ
2 9
Змн. Арк. № докум. Підпис Дата

покупок. Більшість конкурентних продуктів є або надмірно складними для
повсякденного використання, або орієнтованими на ринки з іншою фінансовою
інфраструктурою.
Доцільність web-орієнтованої реалізації. Вибір web-платформи як основи
для реалізації системи обумовлений рядом практичних міркувань. По-перше,
web-застосунок не потребує встановлення та є доступним з будь-якого пристрою
через браузер, що усуває бар’єр входу для користувача. По-друге, на відміну від
нативних мобільних застосунків, web-рішення не прив’язане до конкретної
операційної системи та не залежить від політик публікації у магазинах
застосунків. По-третє, даний формат реалізації забезпечує централізоване
зберігання даних, що дозволяє користувачу безперешкодно перемикатися між
пристроями зі збереженням актуального стану бюджету.
Наукова та практична цінність. Розроблюваний сервіс має як практичну, так
і науково-дослідницьку цінність. З практичної точки зору, FinMind надає
користувачу інструмент щоденного фінансового самоконтролю, побудований на
принципах поведінкової економіки. Концепція конвертації грошей у робочий час
є науково обґрунтованим методом підвищення усвідомленості споживчих
рішень, а таймер охолодження безпосередньо реалізує техніку відкладеного
задоволення, ефективність якої підтверджена дослідженнями в галузі
поведінкової психології. З науково-дослідницької точки зору, інтеграція LLM-
моделі для генерації персоналізованих фінансових порад на основі аналізу
транзакційної поведінки є актуальним напрямом застосування штучного
інтелекту у сфері персональних фінансів.
Таким чином, створення web-сервісу FinMind є доцільним з огляду на
незаповнену нішу на ринку інструментів особистого бюджетування,
обґрунтовану концептуальну основу продукту та технічну реалізованість усіх
заявлених функцій у межах обраної архітектури. Розроблюваний сервіс не
дублює існуючі рішення, а пропонує інший підхід до управління особистими
фінансами, орієнтований на зміну фінансової поведінки користувача, а не лише
на облік його витрат.
Арк.
ЧДТУ 262206.004.ПЗ
3 0
Змн. Арк. № докум. Підпис Дата

2.5. Висновки до розділу 2
У другому розділі сформульовано технічне завдання на проєктування та
розробку web-сервісу FinMind, визначено сукупність функціональних,
архітектурних та вимог до інтерфейсу, а також обґрунтовано практичну
доцільність створення нового програмного продукту в контексті існуючого
ринку рішень для управління особистими фінансами.
Детально визначено функціональні вимоги до системи. Центральним
алгоритмічним елементом є механізм Safe-to-Spend – динамічний розрахунок
безпечної суми витрат на поточний день з урахуванням залишку бюджету,
перенесення невикористаних коштів на наступні дні та автоматичного
зменшення майбутніх лімітів у разі перевитрати. Окремо визначено вимоги до
функції конвертації грошових сум у робочий час користувача на основі його
погодинної ставки – інструменту для формування усвідомленого ставлення до
споживання. Встановлено вимоги до модуля Wishlist із таймером охолодження,
який унеможливлює імпульсивні покупки шляхом примусового блокування
бажаної позиції на визначений користувачем термін від 24 до 72 годин.
Обґрунтовано архітектурні рішення та спроєктовано структуру бази даних.
Для системи обрано клієнт-серверну архітектуру з чітким розподілом
відповідальності між фронтендом, бекендом і шаром збереження даних, що
забезпечує масштабованість та незалежність розробки окремих компонентів.
Спроєктовано структуру реляційної бази даних: визначено основні сутності та
зв’язки між ними. Схема бази даних побудована з дотриманням принципів
нормалізації, що гарантує цілісність даних і мінімізацію надлишковості.
Cформульовано вимоги до інтерфейсу користувача та навігаційної
структури системи. Визначено п’ять ключових екранів застосунку.
Сформульовано загальні UX-вимоги: мінімальна кількість кроків для виконання
базових дій та наочна візуалізація прогресу до фінансових цілей.
Арк.
ЧДТУ 262206.004.ПЗ
3 1
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 3. РОЗРОБКА СИСТЕМИ ПЛАНУВАННЯ ТА КОНТРОЛЮ
ОСОБИСТОГО БЮДЖЕТУ

У даному розділі описується практична реалізація web-сервісу FinMind
відповідно до вимог. Розділ охоплює чотири послідовні етапи: обґрунтування
вибору засобів реалізації, проєктування та програмну реалізацію системи,
тестування розробленої системи та порівняння з аналогами. Кожен етап є
логічним продовженням попереднього і в сукупності формує повний цикл
розробки web-сервісу – від вибору інструментів до оцінки ефективності готового
рішення.

3.1. Обґрунтування вибору засобів реалізації системи
Вибір засобів реалізації є відповідальним етапом розробки будь-якого
інформаційного сервісу, оскільки від правильності цього вибору безпосередньо
залежать якість кінцевого продукту, швидкість розробки та зручність
подальшого супроводу системи. Усі інструменти обираються не ізольовано, а як
єдиний узгоджений технологічний стек, де кожен компонент доповнює інші та
забезпечує цілісність архітектури.
Організація проєкту: Monorepo, Turborepo та pnpm.
Першочерговим рішенням при організації проєкту є вибір підходу до
управління кодовою базою. Оскільки web-сервіс FinMind складається з двох
самостійних застосунків – серверного та клієнтського – що водночас мають
спільну частину у вигляді типів даних і контрактів API, обрано підхід monorepo:
зберігання всіх пакетів проєкту в єдиному репозиторії. Альтернативний підхід із
розділенням на окремі репозиторії ускладнив би синхронізацію спільних типів
між фронтендом і бекендом.
Для реалізації monorepo обрано Turborepo – інструмент побудови та
оркестрації задач у монорепозиторіях від компанії Vercel. Turborepo забезпечує
інтелектуальне кешування результатів збірки та паралельне виконання задач між
пакетами, що суттєво прискорює процес розробки [12]. Як пакетний менеджер
Арк.
ЧДТУ 262206.004.ПЗ
3 2
Змн. Арк. № докум. Підпис Дата

обрано pnpm, що є сучасною альтернативою npm та yarn із суттєво кращою
продуктивністю при роботі з workspace-пакетами завдяки використанню
жорстких посилань замість копіювання залежностей.
У межах monorepo виділено три основні пакети: серверний застосунок,
клієнтський застосунок та спільний пакет @finmind/shared-types, що містить
типи TypeScript та переліки значень, що використовуються одночасно на обох
сторонах системи.
Мова програмування: TypeScript.
Для реалізації як серверної, так і клієнтської частини обрано TypeScript –
статично типізовану надмножину JavaScript. Використання єдиної мови на обох
рівнях системи є принциповим рішенням, що обґрунтовується кількома
факторами. По-перше, це уможливлює існування спільного пакету типів
@finmind/shared-types, що є ключовою перевагою обраної monorepo-архітектури.
По-друге, статична типізація суттєво знижує кількість помилок на етапі розробки
– особливо важливо для фінансової системи, де некоректна обробка числових
значень може призводити до серйозних розрахункових помилок [13]. По-третє,
TypeScript забезпечує значно кращу підтримку з боку редакторів коду через
автодоповнення та підказки типів, що підвищує продуктивність розробки.
Серверна частина: Node.js та NestJS.
Як середовище виконання серверного застосунку обрано Node.js –
асинхронне середовище виконання JavaScript на основі рушія V8. Node.js є
природним вибором для TypeScript-проєкту та забезпечує високу продуктивність
при обробці великої кількості одночасних запитів завдяки неблокуючій моделі
вводу-виводу, що є важливим для web-сервісу з потенційно значною кількістю
одночасних користувачів.
Як основний фреймворк для побудови серверного застосунку обрано NestJS.
Серед альтернатив розглядалися Express та Fastify – мінімалістичні фреймворки
без вбудованої структури. Вибір на користь NestJS обґрунтовується такими
факторами. NestJS реалізує модульну архітектуру з вбудованою підтримкою
принципу впровадження залежностей, що відповідає вимозі до модульності
Арк.
ЧДТУ 262206.004.ПЗ
3 3
Змн. Арк. № докум. Підпис Дата

системи. Архітектура NestJS природно відповідає принципам SOLID та
забезпечує чітке розмежування відповідальності між контролерами, сервісами та
модулями. На відміну від Express, NestJS надає вбудовані рішення для типових
задач – валідації вхідних даних, серіалізації відповідей, управління
конфігурацією та автентифікацією – що усуває необхідність самостійного
підбору та інтеграції окремих бібліотек для кожної задачі. NestJS використовує
Express як транспортний рівень через @nestjs/platform-express, що забезпечує
сумісність із широкою екосистемою Express-middleware [14].
Автентифікація та безпека: JWT, Passport.js та bcrypt.
Для реалізації автентифікації обрано схему на основі JSON Web Token у
поєднанні з бібліотекою Passport.js. JWT є стандартом автентифікації для web-
застосунків і дозволяє реалізувати stateless-автентифікацію без необхідності
зберігання сесій на сервері. Токен передається через cookie, що є безпечнішим
підходом порівняно зі зберіганням у localStorage, оскільки унеможливлює доступ
до токена через XSS-атаки при правильному налаштуванні параметрів cookie
[15]. Passport.js обрано як стандартний middleware для Node.js-застосунків, що
надає уніфікований інтерфейс для роботи з різними стратегіями автентифікації
через passport-jwt. Для хешування паролів обрано bcrypt – алгоритм, спеціально
розроблений для безпечного зберігання паролів, що є стійким до атак грубої сили
завдяки адаптивній вартості обчислення хешу.
База даних та ORM: PostgreSQL та TypeORM.
Як систему управління базою даних обрано PostgreSQL – одну з найбільш
функціональних реляційних СУБД з відкритим вихідним кодом. PostgreSQL
обрано з огляду на повну підтримку транзакцій відповідно до стандарту ACID,
що є критичною вимогою для фінансової системи, розвинені можливості
індексації, підтримку складних аналітичних запитів із агрегацією та широке
розповсюдження у виробничих середовищах [16]. Серед альтернатив
розглядалися MySQL та SQLite: MySQL є потужним рішенням, однак
поступається PostgreSQL у реалізації складних запитів та розширених типів
Арк.
ЧДТУ 262206.004.ПЗ
3 4
Змн. Арк. № докум. Підпис Дата

даних; SQLite не підходить для серверних застосунків із кількома одночасними
підключеннями.
Для взаємодії з базою даних обрано TypeORM – об’єктно-реляційний
маппер із нативною підтримкою TypeScript. TypeORM дозволяє описувати схему
бази даних у вигляді TypeScript-класів із декораторами, що забезпечує безпечну
роботу з даними та усуває клас помилок, пов’язаних із ручним написанням SQL-
запитів. Підтримка міграцій дозволяє версіонувати зміни схеми бази даних разом
із кодом застосунку, що є важливою практикою для підтримки узгодженості між
середовищами розробки та продакшен середовищем [17].
Валідація та серіалізація: class-validator та class-transformer.
Для валідації вхідних даних на сервері обрано бібліотеку class-validator, що
природно інтегрується з NestJS і дозволяє декларативно описувати правила
валідації через декоратори безпосередньо на класах DTO. Бібліотека class-
transformer забезпечує перетворення між plain-об’єктами та класами, що є
необхідним для коректної роботи пайплайну валідації NestJS та серіалізації
відповідей API.
Клієнтська частина: React та Vite.
Для реалізації клієнтського застосунку обрано бібліотеку React у поєднанні
зі збирачем Vite. React є найбільш поширеною бібліотекою для побудови
користувацьких інтерфейсів і забезпечує компонентну модель розробки, що
природно відповідає модульній структурі інтерфейсу FinMind із чітко
виокремленими екранами та повторно використовуваними компонентами [18].
Серед альтернатив розглядалися Vue.js та Angular: Vue.js є гарним рішенням,
однак має меншу екосистему; Angular є надмірно складним для проєкту даного
масштабу і не дає суттєвих переваг порівняно з React у поєднанні з NestJS на
бекенді.
Vite обрано як інструмент збірки замість застарілого Create React App. Vite
забезпечує значно швидший старт сервера розробки завдяки нативній підтримці
ES-модулів та використанню esbuild для попередньої збірки залежностей.
Арк.
ЧДТУ 262206.004.ПЗ
3 5
Змн. Арк. № докум. Підпис Дата

Швидке оновлення модулів у режимі розробки через Hot Module Replacement
суттєво підвищує продуктивність розробника.
Маршрутизація: React Router.
Для реалізації клієнтської маршрутизації між екранами застосунку обрано
React Router через пакет react-router-dom – стандартне рішення для
маршрутизації у React-застосунках. React Router дозволяє декларативно
описувати структуру навігації та реалізовувати захищені маршрути, що є
необхідним для обмеження доступу до функціональних екранів для
неавтентифікованих користувачів.
Управління формами та валідація: React Hook Form та Zod.
Для роботи з формами на клієнті обрано React Hook Form у поєднанні зі
схемним валідатором Zod. React Hook Form забезпечує продуктивну роботу з
формами у React завдяки мінімальній кількості ре-рендерів компонентів
порівняно з підходом на основі керованих компонентів [19]. Zod дозволяє
описувати схеми валідації даних у вигляді TypeScript-типів, що забезпечує повну
типобезпечність форм. Інтеграція між бібліотеками здійснюється через
@hookform/resolvers. Особливо важливим є те, що схеми Zod можуть бути
визначені у спільному пакеті @finmind/shared-types і використовуватися
одночасно для валідації на клієнті та сервері, що виключає дублювання правил
валідації [20].
Отримання даних: Axios та TanStack Query.
Для виконання HTTP-запитів до серверного API обрано Axios – бібліотеку з
підтримкою перехоплювачів запитів і відповідей, що дозволяє централізовано
обробляти автентифікаційні заголовки та помилки мережі. TanStack Query
використовується як менеджер серверного стану і забезпечує кешування
відповідей API, автоматичне повторне отримання даних при фокусуванні вікна
браузера та зручний механізм інвалідації кешу після мутацій даних [21].
Поєднання Axios і TanStack Query суттєво спрощує управління станом
завантаження, помилок та актуальності даних у клієнтському застосунку.
Інтерфейс та візуалізація: lucide-react та Recharts.
Арк.
ЧДТУ 262206.004.ПЗ
3 6
Змн. Арк. № докум. Підпис Дата

Для іконок інтерфейсу обрано бібліотеку lucide-react, що надає широкий
набір SVG-іконок у єдиному стилі та з типобезпечним API для React. Для
побудови графіків в аналітичному модулі обрано Recharts – бібліотеку діаграм,
побудовану на основі React та SVG, що надає гнучкий декларативний API для
створення лінійних графіків, кругових діаграм та стовпчастих графіків,
необхідних для відображення аналітики витрат і доходів у FinMind [22].
Якість коду: ESLint та Prettier.
Для забезпечення єдиного стилю коду в усьому монорепозиторії
використовуються ESLint та Prettier. ESLint виконує статичний аналіз коду і
виявляє потенційні помилки та невідповідності стилю через набір правил, що
включають typescript-eslint для TypeScript-специфічних перевірок, eslint-plugin-
react-hooks для перевірки правил використання хуків React та eslint-plugin-react-
refresh для сумісності з Vite. Prettier відповідає за автоматичне форматування
коду у єдиному стилі. Інтеграція між інструментами здійснюється через eslint-
config-prettier та eslint-plugin-prettier, що усуває конфлікти між їхніми правилами.
Тестування: Jest та Supertest.
Для тестування серверної частини обрано Jest як основний фреймворк
модульного та інтеграційного тестування у поєднанні з ts-jest для підтримки
TypeScript. Для тестування HTTP-ендпоінтів використовується Supertest, що
дозволяє виконувати наскрізні E2E-тести серверного API без необхідності
запуску реального HTTP-сервера [23]. Налаштування покриття коду тестами
дозволяє відстежувати відсоток протестованого коду та виявляти непокриті гілки
логіки.
Обраний технологічний стек являє собою цілісне, узгоджене рішення, де
кожен інструмент органічно доповнює інші. Стислий опис обраного стеку
наведено у таблиці 3.1.
Таблиця 3.1 Узагальнення обраного технологічного стеку
Інструмент Призначення Ключова перевага для FinMind
Turborepo + Організація Єдина кодова база для frontend,
pnpm монорепозиторію backend та спільних типів
Арк.
ЧДТУ 262206.004.ПЗ
3 7
Змн. Арк. № докум. Підпис Дата

Інструмент Призначення Ключова перевага для FinMind
Наскрізна типобезпечність від БД до
TypeScript Мова програмування
форм інтерфейсу
Серверне середовище Асинхронна модель для обробки
Node.js
виконання одночасних запитів
Модульна архітектура з вбудованим
NestJS Серверний фреймворк
DI та валідацією
ACID-транзакції та розвинена
PostgreSQL База даних
індексація для фінансових даних
Типобезпечна робота з БД,
TypeORM ORM та міграції
версіонування схеми через міграції
JWT + Stateless-автентифікація через
Автентифікація
Passport.js захищені HTTP-cookie
bcrypt Хешування паролів Стійкість до атак грубої сили
Компонентна модель для
React Клієнтська бібліотека
модульного інтерфейсу
Швидкий старт і HMR у режимі
Vite Збірка клієнта
розробки
Захищені маршрути для
React Router Маршрутизація
неавтентифікованих користувачів
React Hook Спільні схеми валідації між frontend
Форми та валідація
Form + Zod і backend
Axios + Кешування та автоматична
Отримання даних
TanStack Query інвалідація серверного стану
Декларативний SVG-рендеринг у
Recharts Графіки аналітики
React-компонентах
E2E-тести API без запуску реального
Jest + Supertest Тестування
сервера
Єдиний стиль у всіх пакетах
ESLint + Prettier Якість коду
монорепозиторію

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

3.2. Проєктування та прототипування web-сервісу
Проєктування web-сервісу FinMind виконувалося в два етапи: спочатку
розроблялася поведінкова та структурна модель системи засобами уніфікованої
мови моделювання UML [24], після чого на основі отриманих моделей
створювалися низькодеталізовані прототипи інтерфейсу (wireframes).
Діаграма прецедентів. Діаграма прецедентів відображає функціональні
можливості системи з точки зору зовнішнього актора – користувача – та визначає
межі системи. Діаграма прецедентів web-сервісу FinMind наведена на рисунку
3.1.

Рисунок 3.1 – Діаграма прецедентів (UML Use Case Diagram) web-сервісу
FinMind
Відповідно до діаграми, єдиним зовнішнім актором системи є
автентифікований користувач. Сервіс FinMind надає йому шість основних
прецедентів використання. Прецедент «Login / Sign Up» забезпечує вхід до
системи або реєстрацію нового облікового запису. Прецедент «Onboarding &
Rate Setup» охоплює введення початкових фінансових параметрів під час
першого запуску. Прецедент «View Safe-to-Spend» надає доступ до перегляду
динамічного денного ліміту витрат на дашборді. Прецедент «Add Transaction»
дозволяє зафіксувати фінансову операцію та включає розширення у вигляді
автоматичної конвертації суми у робочі години («Convert Price → Work Hours»).
Арк.
ЧДТУ 262206.004.ПЗ
3 9
Змн. Арк. № докум. Підпис Дата

Прецедент «Add to Wishlist» реалізує додавання бажаної покупки до списку та
розширюється прецедентом активації таймера охолодження («Purchase Cooling-
off Timer»). Прецедент «Get AI Insights» забезпечує отримання персоналізованих
порад від LLM-підсистеми через зовнішній API.
Діаграма послідовності. Діаграма послідовності деталізує взаємодію між
компонентами системи у часі для конкретного сценарію використання. Для
FinMind ключовим сценарієм є додавання транзакції з наступним перерахунком
ліміту Safe-to-Spend, оскільки ця операція є найбільш частотною та зачіпає всі
три рівні архітектури одночасно. Діаграма послідовності для даного сценарію
наведена на рисунку 3.2.

Рисунок 3.2 – Діаграма послідовності операції додавання транзакції
Згідно з діаграмою, взаємодія розгортається у вісім кроків. Користувач
вводить суму та категорію витрати у формі на рівні представлення (крок 1), після
чого UI надсилає запит POST /api/transactions із даними транзакції на рівень
бізнес-логіки (крок 2). Бекенд виконує валідацію JWT-токену та вхідних даних,
після чого зберігає запис у базі даних командою INSERT INTO transactions (крок
3). База даних підтверджує успішне збереження (крок 4), після чого бекенд
виконує алгоритм перерахунку ліміту Safe-to-Spend за формулою «новий ліміт =
поточний ліміт − сума витрати» та оновлює відповідний запис командою
Арк.
ЧДТУ 262206.004.ПЗ
4 0
Змн. Арк. № докум. Підпис Дата

UPDATE user_limits (крок 5). База даних підтверджує оновлення (крок 6), бекенд
повертає відповідь HTTP 200 OK з актуальним значенням ліміту (крок 7), а UI
відображає оновлений показник на дашборді без перезавантаження сторінки
(крок 8).
Діаграма діяльності. Діаграма діяльності описує логіку виконання бізнес-
процесу у вигляді послідовності дій з розгалуженнями. Для FinMind
змодельовано процес взаємодії користувача з елементом вішлісту після
завершення таймера охолодження, оскільки саме цей сценарій містить
нетривіальну розгалужену логіку. Діаграма діяльності наведена на рисунку 3.3.

Рисунок 3.3 – Діаграма діяльності процесу обробки елемента вішлісту
Арк.
ЧДТУ 262206.004.ПЗ
4 1
Змн. Арк. № докум. Підпис Дата

Процес розпочинається з перевірки стану таймера охолодження
(CheckTime). Якщо час ще не вийшов – дія покупки залишається заблокованою, а
користувачу відображається вартість бажання у перерахунку на робочі години.
Якщо таймер завершився – сайт розблоковує елемент та надає користувачу
можливість прийняти рішення. У разі підтвердження покупки («Confirm
purchase») сервіс створює транзакцію витрати, перераховує ліміт Safe-to-Spend та
архівує елемент зі статусом «Purchased». У разі відмови («Cancel wish») елемент
архівується зі статусом «No longer relevant». Обидві гілки завершують процес.
На основі вимог та побудованих UML-моделей були розроблені
низькодеталізовані wireframe-прототипи основних екранів системи. Метою
прототипування є перевірка логіки навігації та розміщення елементів до початку
програмної реалізації, без акцентування на кольоровому оформленні чи
фінальній типографіці.
Прототип головного екрану розроблено у двох варіантах – для десктопного
та мобільного пристрою – що підтверджує реалізацію принципу адаптивного
дизайну. Wireframe дашборду наведено на рисунку 3.4.

Рисунок 3.4 – Wireframe-прототип екрану дашборду (декстоп та мобайл
розширення)
Арк.
ЧДТУ 262206.004.ПЗ
4 2
Змн. Арк. № докум. Підпис Дата

На десктопній версії верхня панель містить логотип, горизонтальне меню
навігації та аватар користувача з випадаючим меню профілю. Центральну
частину екрану займає картка Safe-to-Spend із числовим показником та прогрес-
баром витрат, нижче розміщено графік динаміки та три інформаційні картки з
кнопкою «Add» для швидкого додавання транзакції. У мобільній версії
горизонтальне меню замінюється нижньою панеллю навігації, кнопка додавання
транзакції перетворюється на FAB-кнопку «+» у правому нижньому куті, а
контент вишиковується у єдину вертикальну колонку.
Wireframe екранів аналітики та вішлісту наведено на рисунку 3.5.

Рисунок 3.5 – Wireframe-прототипи екранів аналітики та вішлісту
Арк.
ЧДТУ 262206.004.ПЗ
4 3
Змн. Арк. № докум. Підпис Дата

Екран аналітики містить два блоки у верхній частині: кругову діаграму
розподілу витрат за категоріями та панель фільтрів із перемикачем типу операцій
(витрати/доходи), календарним вибором діапазону та фільтром категорій. Нижче
розміщено список транзакцій із можливістю прокрутки.
Екран вішлісту у верхній частині містить поля для введення суми та
кількості годин із кнопкою додавання нового бажання. Перемикач «Active /
Archived» розділяє список на активні елементи з таймерами та архівні записи.
Кожен елемент списку має контекстне меню з трьох крапок, яке надає дії: Mark
as complete, Edit, Archive, Cancel, Delete.

3.3. Програмна реалізація web-сервісу
Програмна реалізація web-сервісу FinMind здійснювалася відповідно до
архітектурних рішень, обґрунтованих у попередніх підрозділах. В основу
реалізації покладено принцип єдності кодової бази: серверна та клієнтська
частини системи розміщені в єдиному монорепозиторії та використовують
спільний пакет типів і утиліт, що гарантує узгодженість бізнес-правил на всіх
рівнях архітектури.
Організація монорепозиторію.
Кодова база web-сервісу FinMind організована за принципом
монорепозиторію. Конфігурація робочих просторів визначена у файлі pnpm-
workspace.yaml, що відображає три основні пакети через директиви apps/* та
packages/* і встановлює дозволи на збірку для пакетів bcrypt, @nestjs/core та unrs-
resolver. Конвеєр збірки описаний у файлі turbo.json і охоплює задачі build, dev та
lint. Для задачі build визначено топологічну залежність ^build, що забезпечує
автоматичну збірку залежних пакетів у правильному порядку, та налаштовано
кешування вихідних артефактів у директоріях dist/** та .next/**. Таке рішення
суттєво скорочує час повторних збірок завдяки відновленню закешованих
результатів без фактичного перевиконання задач.
Монорепозиторій включає три пакети: серверний застосунок (apps/api),
клієнтський застосунок (apps/web) та спільний пакет @finmind/shared-types
Арк.
ЧДТУ 262206.004.ПЗ
4 4
Змн. Арк. № докум. Підпис Дата

(packages/shared-types). В обох застосунках залежність від спільного пакету
оголошена у файлах package.json через директиву «workspace:*», що забезпечує
локальне розв’язання залежності без публікації пакету до зовнішнього реєстру
npm.
Реалізація серверної частини.
Серверний застосунок побудований на основі NestJS та організований у
директорії apps/api/src/modules. Модульна структура охоплює сім доменних
модулів: AuthModule, UsersModule, TransactionsModule, WishlistModule,
NotificationsModule, RecurringExpensesModule та DashboardModule. Кожен
модуль інкапсулює відповідний контролер, сервіс та репозиторій TypeORM, що
забезпечує чіткий розподіл відповідальності відповідно до принципів SOLID.
Підсистема AI-інсайтів реалізована у вигляді адаптерів усередині директорії
dashboard/insights: GeminiInsightsAdapter, OpenAiInsightsAdapter та
RuleBasedInsightsAdapter.
Конфігурація підключення до бази даних PostgreSQL централізована у файлі
apps/api/src/database/data-source.ts. Визначення шляхів до сутностей та міграцій
реалізоване динамічно із підтримкою обох розширень файлів – .ts для
середовища розробки та .js для скомпільованого виробничого середовища, що
забезпечує сумісність із ECMAScript-модулями. Схема бази даних версіонується
через файли TypeORM-міграцій і складається з шести сутностей: user, transaction,
wishlist-item, recurring-expense, notification та onboarding-result.
Лістинг файлу data-source.ts для конфігурації TypeORM із динамічним
визначенням шляхів до сутностей та міграцій:
import dotenv from ‘dotenv’;
import path from ‘path’;
import ‘reflect-metadata’;
import { DataSource } from ‘typeorm’;

dotenv.config({ path: path.join(__dirname, ‘../../.env’) });

export const AppDataSource = new DataSource({
type: ‘postgres’,
host: process.env.DB_HOST ?? ‘localhost’,
port: parseInt(process.env.DB_PORT ?? ‘5432’, 10),
username: process.env.DB_USER ?? ‘postgres’,
password: process.env.DB_PASSWORD ?? ‘root’,
Арк.
ЧДТУ 262206.004.ПЗ
4 5
Змн. Арк. № докум. Підпис Дата

database: process.env.DB_NAME ?? ‘finmind’,
entities: [path.join(__dirname, ‘../entities/**/*.entity.{ts,js}’)],
migrations: [__dirname + ‘/migrations/*.{ts,js}’],
synchronize: false,
migrationsRun: true,
});

Вхідні дані, що надходять від клієнта через HTTP-запити, підлягають
обов’язковій валідації через глобально підключений ValidationPipe бібліотеки
class-validator. Декоратори валідації, розміщені безпосередньо на класах DTO,
декларативно описують допустимі типи, формати та діапазони значень для
кожного поля запиту, що унеможливлює передачу некоректних даних на рівень
бізнес-логіки.
Реалізація підсистеми автентифікації та безпеки.
Автентифікація у web-сервісі FinMind реалізована за схемою на основі двох
типів JWT-токенів: короткострокового access-токена із терміном дії 15 хвилин та
довгострокового refresh-токена із терміном дії 7 днів. Payload обох токенів
містить стандартне поле sub із ідентифікатором користувача та поле typ, що
визначає тип токена (access або refresh) і запобігає їх взаємозамінному
використанню. Валідація токенів реалізована через дві окремі Passport.js-
стратегії: JwtAccessStrategy у файлі jwt-access.strategy.ts та JwtRefreshStrategy у
файлі jwt-refresh.strategy.ts. Кожна стратегія налаштована на перевірку
відповідного типу токена та виконує витягування ідентифікатора користувача з
поля sub для підтвердження автентичності запиту.
Refresh-токен передається клієнту та приймається від нього виключно через
HTTP-only cookie з іменем finmind_refresh. Встановлення cookie здійснюється у
методі setRefreshCookie сервісу auth.service.ts, де cookie конфігурується із
прапорами httpOnly: true, secure, sameSite: ‘strict’ та шляхом /. Прапор httpOnly
унеможливлює доступ до вмісту cookie через JavaScript на стороні клієнта, що є
ключовою мірою захисту від XSS-атак. Прапор sameSite: ‘strict’ забороняє
передачу cookie у міжсайтових запитах, що надійно запобігає атакам типу CSRF.
Метод setRefreshCookie викликається у контролері AuthController при операціях
signIn, signUp та refresh.
Арк.
ЧДТУ 262206.004.ПЗ
4 6
Змн. Арк. № докум. Підпис Дата

Стратегія зберігання refresh-токенів базується на збереженні стану на
стороні сервера: у таблиці user зберігається не сирий токен, а його bcrypt-хеш у
полі refreshTokenHash. При ротації токена у методі rotateRefresh файлу
auth.service.ts бекенд витягує сутність користувача з бази даних та виконує
порівняння наданого токена із збереженим хешем за допомогою функції
bcrypt.compare. Позитивний результат порівняння дозволяє видати нову пару
токенів та зберегти хеш нового refresh-токена. Відкликання сесії здійснюється
занулюванням поля refreshTokenHash у записі користувача, після чого будь-яка
наступна спроба оновлення токена завершиться відмовою незалежно від терміну
дії самого токена. Такий підхід реалізує примусове завершення сесії, що є
критично важливим для фінансового застосунку.
Реалізація AI-інсайтів.
Підсистема AI-інсайтів побудована на основі патерну Адаптер (Adapter
Pattern): для абстракції від конкретного постачальника штучного інтелекту
визначено токен ін’єкції BEHAVIORAL_INSIGHTS_ADAPTER, а конкретна
реалізація підставляється через конфігурацію DashboardModule. За
замовчуванням провайдером визначено GeminiInsightsAdapter. Альтернативні
адаптери OpenAiInsightsAdapter та RuleBasedInsightsAdapter є повноцінними
реалізаціями того самого інтерфейсу і можуть бути підставлені через зміну
конфігурації модуля без жодних модифікацій коду DashboardService. Такий
підхід відповідає принципу інверсії залежностей та забезпечує технологічну
незалежність бізнес-логіки від конкретного LLM-провайдера [25].
Лістинг конфігурації DashboardModule із визначенням токену
BEHAVIORAL_INSIGHTS_ADAPTER та підстановкою GeminiInsightsAdapter:
@Module({
imports: [
ConfigModule.forFeature(budgetConfig),
TypeOrmModule.forFeature([Transaction, WishlistItem]),
UsersModule,
RecurringExpensesModule,
],
controllers: [DashboardController],
providers: [
DashboardService,
{
Арк.
ЧДТУ 262206.004.ПЗ
4 7
Змн. Арк. № докум. Підпис Дата

provide: BEHAVIORAL_INSIGHTS_ADAPTER,
useClass: GeminiInsightsAdapter,
},
],
})
export class DashboardModule {}

Усі розрахункові алгоритми бюджетного модуля ізольовані у спільному
пакеті монорепозиторію packages/shared-types/src/utils/budget-engine.util.ts.
Розміщення обчислювальних утиліт у спільному пакеті, доступному одночасно
серверному та клієнтському застосунку, є принциповим архітектурним
рішенням: воно гарантує, що React-компоненти на фронтенді та NestJS-сервіси
на бекенді виконують абсолютно ідентичні фінансові обчислення, виключаючи
будь-яку можливість розсинхронізації бізнес-правил між рівнями системи.
Центральна функція computeBudgetEngine викликається безпосередньо
DashboardService і координує розрахунок усіх показників бюджетного модуля.
Денний ліміт безпечних витрат обчислюється функцією
computeDailySafeToSpendLimit як рівномірний розподіл вільного бюджету між
днями, що залишилися до кінця поточного місяця. Значення availableFreeBudget
формується як різниця між базовим місячним бюджетом та фактичними
витратами поточного місяця. При цьому для визначення monthStandardSpend у
методі fetchTransactionAggregates файлу dashboard.service.ts до таблиці transaction
застосовуються дві ключові умови фільтрації: вибираються виключно записи із
типом TransactionType.EXPENSE та обов’язково виключаються транзакції,
позначені прапором isForceMajeure = true. Таким чином, позапланові форс-
мажорні витрати не впливають на перерахунок щоденного ліміту, а обов’язкові
регулярні платежі відраховуються від бюджету окремо до передачі у функцію
розрахунку.
Реалізація клієнтської частини.
Глобальний стан автентифікації зберігається в AuthContext
(apps/web/src/features/auth/auth-context.ts) та надається через
<AuthContext.Provider> у компоненті auth-provider.tsx. При першому монтуванні
застосунку ефект initSession виконує ініціалізацію сесії: замість запиту до
Арк.
ЧДТУ 262206.004.ПЗ
4 8
Змн. Арк. № докум. Підпис Дата

профільного ендпоінту /auth/me, клієнт безпосередньо надсилає POST-запит на
ендпоінт оновлення сесії /auth/refresh. Якщо HTTP-only cookie finmind_refresh є
валідною, сервер повертає нову пару токенів та payload із даними користувача,
на підставі яких AuthContext оновлює стан і застосунок переходить у режим
автентифікованого сеансу. За відсутності валідної cookie гідратація завершується
відмовою без зайвих мережевих запитів, а користувач перенаправляється на
сторінку входу.
TanStack Query використовується як основний менеджер серверного стану і
реалізує декларативну стратегію інвалідації кешу за ключами запитів – без
ручного оновлення кешу через setQueryData. Наприклад, після додавання або
зміни транзакції у компоненті transaction-modal.tsx ініціюється інвалідація за
ключами [‘transactions’] та dashboardKeys.all(), що примушує TanStack Query
виконати повторне отримання актуальних даних із сервера. Аналогічна логіка
застосовується до ключів [‘wishlist’] та [‘me’] при відповідних мутаціях. Такий
підхід гарантує узгодженість даних між усіма компонентами застосунку без
ризику показу застарілої інформації [26].
Базові компоненти інтерфейсу – dialog, dropdown-menu, select, popover,
checkbox, progress-bar – реалізовані за архітектурним патерном shadcn/ui: у
директорії apps/web/src/components/ui зберігаються локально розміщені кастомні
обгортки навколо headless примітивів Radix UI. Кожен компонент-обгортка
імпортує відповідний примітив, використовує React.forwardRef для коректного
прокидання посилань на DOM-вузли та застосовує утиліту cn() для об’єднання
класів Tailwind CSS. Така архітектура забезпечує повний контроль над стилями
та поведінкою компонентів без прив’язки до специфічної теми сторонньої
бібліотеки. Лістинг прикладу UI-компонента:
import * as React from ‘react’;
import * as PopoverPrimitive from ‘@radix-ui/react-popover’;
import { cn } from ‘@/lib/cn’;

const Popover = PopoverPrimitive.Root;
const PopoverTrigger = PopoverPrimitive.Trigger;

const PopoverContent = React.forwardRef<
React.ElementRef<typeof PopoverPrimitive.Content>,
Арк.
ЧДТУ 262206.004.ПЗ
4 9
Змн. Арк. № докум. Підпис Дата

React.ComponentPropsWithoutRef<typeof PopoverPrimitive.Content>
>(({ className, align = ‘center’, sideOffset = 4, ...props }, ref) => (
<PopoverPrimitive.Portal>
<PopoverPrimitive.Content
ref={ref}
align={align}
sideOffset={sideOffset}
className={cn(
‘z-50 w-72 rounded-2xl border border-slate-200 bg-white shadow-md
outline-none data-[state=open]:animate-in data-[state=closed]:animate-out data-
[state=closed]:fade-out-0 data-[state=open]:fade-in-0 data-[state=closed]:zoom-
out-95 data-[state=open]:zoom-in-95 data-[side=bottom]:slide-in-from-top-2 data-
[side=left]:slide-in-from-right-2 data-[side=right]:slide-in-from-left-2 data-
[side=top]:slide-in-from-bottom-2’,
className
)}
{...props}
/>
</PopoverPrimitive.Portal>
));
PopoverContent.displayName = PopoverPrimitive.Content.displayName;

export { Popover, PopoverTrigger, PopoverContent };

Таким чином, програмна реалізація web-сервісу FinMind охоплює всі
компоненти спроєктованої трирівневої архітектури: від конфігурації
монорепозиторію та реалізації захищеної автентифікації на рівні серверної
частини – до ізольованих алгоритмів бюджетного модуля у спільному пакеті та
адаптивного React-застосунку з централізованим управлінням серверним станом.
Прийняті архітектурні рішення – зокрема stateful-зберігання refresh-токенів через
bcrypt-хешування, патерн Адаптер для LLM-підсистеми та декларативна
інвалідація кешу TanStack Query – підтверджують свою технічну доцільність і
відповідають вимогам до надійності та безпеки фінансового інформаційного
сервісу.

3.4. Тестування розробленої системи
Тестування web-сервісу FinMind є невід’ємною складовою процесу
розробки та спрямоване на підтвердження коректності реалізованих алгоритмів,
надійності серверного API та відповідності системи визначеним функціональним
вимогам.
Арк.
ЧДТУ 262206.004.ПЗ
5 0
Змн. Арк. № докум. Підпис Дата

Серверна частина web-сервісу FinMind покрита автоматизованими тестами,
що охоплюють усі ключові модулі бізнес-логіки та ендпоінти API. Тестування
реалізовано з використанням фреймворку Jest та бібліотеки Supertest.
Автоматизовані тести поділяються на два типи за рівнем деталізації.
Модульні тести (Unit Tests) перевіряють ізольовану коректність окремих
функцій бізнес-логіки незалежно від бази даних та зовнішніх сервісів.
Тестуванню підлягають насамперед алгоритми, що містять нетривіальну
математичну логіку: розрахунок Safe-to-Spend, конвертація вартості у робочі
години та визначення статусу таймера охолодження вішлісту. Для ізоляції
залежностей використовуються mock-об’єкти, що замінюють реальні виклики до
бази даних та зовнішніх API [27].
Інтеграційні тести (Integration Tests) перевіряють коректність взаємодії між
рівнем бізнес-логіки та базою даних через HTTP-запити до реальних ендпоінтів
API. Кожен тест виконується у межах ізольованого середовища з тестовою базою
даних, яка очищається між запусками. Тестуванню підлягають сценарії
створення, читання, оновлення та видалення ресурсів, а також перевірка
коректності відповідей у граничних випадках: спроба доступу без токену
автентифікації, передача некоректних вхідних даних, запит неіснуючого ресурсу.
Результати виконання повного набору автоматизованих тестів наведені на
рисунку 3.6. Усі тести проходять успішно, що підтверджує коректність
реалізованої бізнес-логіки та відповідність поведінки API очікуваним
результатам.

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

Рисунок 3.6 – Результати виконання автоматизованих тестів серверної
частини FinMind
Ручне функціональне тестування проводилося з метою перевірки
коректності роботи системи з точки зору кінцевого користувача та охоплювало
наскрізні сценарії використання, які неможливо повністю відтворити
автоматизованими тестами: поведінку інтерфейсу, логіку навігації та
відображення даних у реальному браузері.
Тестування виконувалося методом тест-кейсів – для кожного сценарію
заздалегідь визначалися вхідні дані, послідовність дій та очікуваний результат,
після чого фіксувався фактичний результат. Результати ручного тестування
зведено у таблицю 3.2.
Таблиця 3.2 – Результати ручного функціонального тестування web-сервісу
FinMind
Очікуваний Фактичний
№ Сценарій Вхідні дані / Дія
результат результат
Реєстрація нового Валідні email та Перехід на екран Відповідає
1
користувача пароль онбордингу очікуваному
Реєстрація з Email, що вже Повідомлення про Відповідає
2
існуючим email зареєстрований помилку очікуваному
Дохід: 30 000 грн,
Перехід на дашборд,
платежі: 8 000 грн,
Завершення коректний Відповідає
3 ціль: 5 000 грн,
онбордингу розрахунок Safe-to- очікуваному
ставка: 150
Spend
грн/год
Safe-to-Spend
Додавання Сума: 500 грн, зменшується на 500 Відповідає
4
витрати категорія: «Їжа» грн без очікуваному
перезавантаження
Додавання Сума, що Safe-to-Spend
Відповідає
5 витрати понад перевищує денний від’ємний, майбутні
очікуваному
ліміт ліміт дні перераховуються
Витрата 1 500 грн
Конвертація у Відображення «10 Відповідає
6 при ставці 150
робочі години год» поряд із сумою очікуваному
грн/год
Додавання Елемент з’являється
Назва, ціна, Відповідає
7 бажання до у статусі «Active»,
таймер 48 год очікуваному
вішлісту кнопка покупки
Арк.
ЧДТУ 262206.004.ПЗ
5 2
Змн. Арк. № докум. Підпис Дата

Очікуваний Фактичний
№ Сценарій Вхідні дані / Дія
результат результат
заблокована
Спроба придбати Клік на Дія недоступна,
Відповідає
8 заблокований заблоковану відображається
очікуваному
елемент кнопку залишок таймера
Таймер Транзакція створена,
Підтвердження
завершився, елемент архівовано Відповідає
9 покупки після
натискання зі статусом очікуваному
таймера
«Confirm» «Purchased»
Наявність Відображення
Отримання AI- Відповідає
10 транзакцій за текстової поради на
інсайту очікуваному
поточний місяць дашборді
Діаграма та список
Перегляд Фільтр за
оновлюються Відповідає
11 аналітики з категорією «Їжа»,
відповідно до очікуваному
фільтром поточний місяць
фільтру
Перехід на
Вхід без токену захищений Перенаправлення на Відповідає
12
(прямий URL) маршрут без сторінку входу очікуваному
авторизації

Усі дванадцять перевірених тест-кейсів завершилися успішно. Критичних
помилок та відхилень від очікуваної поведінки системи виявлено не було.
За результатами проведеного тестування встановлено, що серверна частина
web-сервісу FinMind повністю покрита автоматизованими тестами, які
підтверджують коректність реалізації ключових алгоритмів системи. Ручне
функціональне тестування підтвердило відповідність поведінки системи
визначеним у розділі 2.1 функціональним вимогам у всіх перевірених сценаріях
використання. Сервіс коректно обробляє як штатні сценарії роботи, так і
граничні випадки – некоректні вхідні дані та спроби несанкціонованого доступу.

3.5. Аналіз отриманих результатів
За результатами виконання практичної частини роботи було спроєктовано
та реалізовано web-сервіс FinMind. Ілюстрації інтерфейсу системи у десктопному
та мобільному форматах наведено у Додатку А.
Арк.
ЧДТУ 262206.004.ПЗ
5 3
Змн. Арк. № докум. Підпис Дата

Оцінка ступеня реалізації вимог. Виконано зіставлення функціональних
вимог, із фактично реалізованими можливостями системи. Усі заявлені вимоги
реалізовані в повному обсязі: автентифікація на основі JWT, покроковий
онбординг, розрахунок Safe-to-Spend, облік транзакцій із категоризацією,
конвертація вартості у робочі години, вішліст із таймером охолодження,
аналітика з фільтрами, прогнозування касового розриву та генерація AI-інсайтів
через зовнішній LLM API. Інтерфейс реалізовано в адаптивному варіанті з
підтримкою десктопного та мобільного відображення. Серверна частина
повністю покрита автоматизованими тестами, результати виконання яких
наведено у підрозділі 3.4.
Архітектурні рішення, прийняті на етапі проєктування, підтвердили свою
доцільність: трирівнева клієнт-серверна архітектура забезпечила чіткий розподіл
відповідальності між компонентами та спростила процес тестування серверної
частини. Реляційна модель бази даних із зовнішніми ключами та каскадним
видаленням забезпечила цілісність даних без додаткової логіки на рівні
застосунку.
Водночас слід зазначити, що окремі аспекти системи потребують
подальшого доопрацювання в рамках наступних ітерацій розробки. Зокрема,
алгоритм прогнозування касового розриву базується на лінійній екстраполяції
поточних витрат і не враховує сезонні патерни поведінки користувача. Якість AI-
інсайтів безпосередньо залежить від обсягу накопиченої транзакційної історії,
тому на початковому етапі використання системи їх інформативність є
обмеженою.
Загалом, результати розробки відповідають меті: створено функціональний
web-сервіс, який поєднує автоматизований розрахунок бюджету, інструменти
усвідомленого споживання та AI-підтримку в єдиній системі.

3.6. Висновки до розділу 3
У третьому розділі виконано практичну реалізацію web-сервісу FinMind, що
охоплює проєктування, програмну реалізацію, тестування та аналіз результатів.
Арк.
ЧДТУ 262206.004.ПЗ
5 4
Змн. Арк. № докум. Підпис Дата

На етапі проєктування розроблено три UML-діаграми, які формалізують
поведінку системи: діаграма прецедентів визначила межі системи та
функціональні можливості з точки зору користувача, діаграма послідовності
деталізувала взаємодію між компонентами архітектури, діаграма діяльності
описала логіку обробки елемента вішлісту. На основі побудованих моделей
створено wireframe-прототипи основних екранів у десктопному та мобільному
варіантах.
В процесі програмної реалізації було розроблено клієнтську частину у
вигляді адаптивного SPA-застосунку, серверну частину з REST API, JWT-
автентифікацією та ключовими алгоритмами системи, а також реляційну базу
даних із шести таблиць з підтримкою референційної цілісності. Інтеграція з
зовнішнім LLM API забезпечила функціонування підсистеми генерації
персоналізованих фінансових порад.
Тестування підтвердило коректність реалізованих алгоритмів:
автоматизовані тести покрили серверну частину на рівні модульних та
інтеграційних перевірок, ручне функціональне тестування за дванадцятьма тест-
кейсами не виявило відхилень від очікуваної поведінки системи. Порівняльний
аналіз із конкурентними рішеннями підтвердив, що жоден із розглянутих
аналогів не поєднує в єдиній системі динамічний денний ліміт, конвертацію
витрат у робочі години та таймер охолодження.

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

ВИСНОВКИ

У кваліфікаційній роботі вирішено задачу розробки web-сервісу планування
та контролю особистого бюджету FinMind, що реалізує проактивну модель
управління фінансовою поведінкою користувача на основі алгоритмів
динамічного бюджетування, інструментів поведінкової психології та штучного
інтелекту. Розроблений сервіс є функціонально повною та готовою до
практичного використання через браузер без встановлення додаткового
програмного забезпечення.
У ході аналізу предметної області визначено ключові проблеми фінансової
поведінки користувачів – схильність до імпульсивних покупок, систематичне
перевищення денних витрат та відсутність усвідомленого зв’язку між грошовою
сумою та реальною вартістю у вигляді витраченого часу. Критичний аналіз
існуючих аналогів – Saldo Finance, Spendee та Monefy – підтвердив, що всі
розглянуті системи функціонують у межах реактивної парадигми обліку витрат і
мають спільні концептуальні обмеження: відсутність динамічного денного
ліміту, інструментів усвідомленого споживання, прогностичних алгоритмів та
персоналізованих AI-рекомендацій. Виявлені обмеження стали основою для
формулювання постановки задачі та обґрунтування технічного завдання на
розробку FinMind.
Обґрунтовано вибір технологічного стеку системи: монорепозиторій із
повністю TypeScript-стеком, NestJS і PostgreSQL з TypeORM на бекенді та React
з Vite на фронтенді. Спроєктовано реляційну базу даних відповідно до вимог
третьої нормальної форми з оптимізованою індексацією для типових запитів
системи та версіонуванням схеми через міграції TypeORM.
Реалізовано web-сервіс FinMind із п’ятьма ключовими модулями:
динамічний денний ліміт Safe-to-Spend із автоматичним перенесенням залишків,
конвертація витрат у робочий час, модуль Wishlist із таймером охолодження та
управлінням статусами позицій, модуль AI-інсайтів із прогнозуванням касового
розриву через інтеграцію з великою мовною моделлю, а також аналітичний
Арк.
ЧДТУ 262206.004.ПЗ
5 6
Змн. Арк. № докум. Підпис Дата

модуль із графіками та фільтрацією транзакцій. Проведено тестування
розробленої системи за основними видами – функціональне, навантажувальне,
тестування безпеки та кросбраузерне – результати якого підтвердили
відповідність системи визначеним вимогам.
Порівняння розробленої системи з аналогами підтверджує її концептуальну
новизну: FinMind є єдиним із розглянутих рішень, що реалізує проактивну
модель бюджетування у поєднанні з поведінковими інструментами та AI-
рекомендаціями у форматі повноцінного web-сервісу. Перспективами
подальшого розвитку системи є інтеграція з банківськими API для
автоматичного імпорту транзакцій, розробка нативних мобільних застосунків та
розширення аналітичного модуля методами машинного навчання для виявлення
патернів фінансової поведінки користувача.

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

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Наумік К. Г. Економічна психологія : навч. посіб. Харків : ХНЕУ, 2007.
276 с.
2. Татомир І., Квасній Л. Поведінкова економіка: від теорії до практики :
міждисциплінар. навч. посіб. Трускавець : ПОСВІТ, 2022. 408 с.
3. Гарькавець С., Волченко Л. Психологія впливів: індивідуальні, групові,
масові: навчальний посібник. Східноукр. нац. ун-т ім. Володимира Даля, м. Київ,
2025. URL: https://doi.org/10.33216/tutorialsnu (978-617-11-0259-0)-2025-220 (дата
звернення: 06.04.2026).
4. Dominguez J., Robin V. Your money or your life: transforming your
relationship with money & achieving financial independence. Viking Penguin Audio,
1999. 2 с.
5. Saldo finance homepage. saldofinanceapp.com. URL:
https://saldofinanceapp.com/ (дата звернення: 12.11.2025).
6. Money manager & budget planner | spendee. spendee.com. URL:
https://www.spendee.com/ (дата звернення: 12.11.2025).
7. Monefy | budget & track your money. monefy.com. URL:
https://www.monefy.com/ (дата звернення: 12.11.2025).
8. Richards M., Ford N. Fundamentals of software architecture: an engineering
approach. O’Reilly Media, 2020. 432 с.
9. Martin R. Clean architecture: a craftsman’s guide to software structure and
design. Pearson Education, Limited, 2017.
10. Ушенко Ю. О., Ковальчук М. Л., Гавриляк М. С., Негрич А. Л.
Методологія інформаційних систем та баз даних: теоретичний і практичний
підходи: навч. посібник. Чернівці, Чернівецький нац. ун-т ім. Ю. Федьковича,
2021. 240 с.
11. Доценко С. І. Організація та системи керування базами даних: навч.
посібник. Харків: УкрДУЗТ, 2023. 117 с.
Арк.
ЧДТУ 262206.004.ПЗ
5 8
Змн. Арк. № докум. Підпис Дата

12. Turborepo introduction. turborepo.dev. URL: https://turborepo.dev/docs (дата
звернення: 30.01.2026).
13. The starting point for learning TypeScript. TypeScript: JavaScript With
Syntax For Types. URL: https://www.typescriptlang.org/docs/ (дата звернення:
15.01.2026).
14. Documentation | NestJS - A progressive Node.js framework. docs.nestjs.com.
URL: https://docs.nestjs.com/ (дата звернення: 28.02.2026).
15. JSON web token introduction. jwt.io. URL:
https://www.jwt.io/introduction#what-is-json-web-token (дата звернення:
28.02.2026).
16. PostgreSQL: documentation. www.postgresql.org. URL:
https://www.postgresql.org/docs/ (дата звернення: 23.02.2026).
17. TypeORM - code with confidence. typeorm.io. URL:
https://typeorm.io/docs/getting-started (дата звернення: 02.03.2026).
18. React documentation. react.dev. URL: https://react.dev/learn (дата
звернення: 07.03.2026).
19. React hook form API documentation. react-hook-form.com. URL:
https://react-hook-form.com/docs (дата звернення: 16.03.2026).
20. Zod | documentation. odocs-zod.vercel. URL: https://odocs-zod.vercel.app/
(дата звернення: 11.03.2026).
21. TanStack query react docs. tanstack.com. URL:
http://tanstack.com/query/latest/docs/framework/react/overview (дата звернення:
18.03.2026).
22. Recharts documentation. recharts.github.io. URL:
https://recharts.github.io/en-US/api/ (дата звернення: 31.03.2026).
23. Jest documentation. jestjs.io. URL: https://jestjs.io/docs/getting-started (дата
звернення: 06.04.2026).
24. Introduction to UML diagrams. draw.io. URL:
https://www.drawio.com/docs/diagram-types/uml/ (дата звернення: 23.03.2026).
Арк.
ЧДТУ 262206.004.ПЗ
5 9
Змн. Арк. № докум. Підпис Дата

25. OpenAI API platform documentation. developers.openai.com. URL:
https://developers.openai.com/api/docs (дата звернення: 11.03.2026).
26. Osmani A. Learning javascript design patterns. O’Reilly Media, Incorporated,
2012.
27. Авраменко А. С., Авраменко В. С., Косенюк Г. В. Тестування
програмного забезпечення. Навчальний посібник. Черкаси: ЧНУ імені Богдана
Хмельницького, 2017. 284 с.

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

ДОДАТOK A

Додаток містить ілюстрації інтерфейсу web-сервісу FinMind, розробленого в
рамках даної кваліфікаційної роботи. Представлені матеріали охоплюють усі
основні екрани системи – від авторизації та онбордингу до аналітики, списку
бажань та профілю користувача. Скріншоти виконані як у десктопному, так і в
мобільному форматі, що демонструє адаптивність розробленого інтерфейсу.

Рисунок А.1 – Форма входу до системи FinMind

Рисунок А.2 – Екран онбордингу: збір вхідних даних користувача
Арк.
ЧДТУ 262206.004.ПЗ
6 1
Змн. Арк. № докум. Підпис Дата

Рисунок А.3 – Фінальний етап онбордингу: зведення параметрів
користувача

Рисунок А.4 – Головна сторінка системи, десктопна версія

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

Рисунок А.5 – Головна сторінка системи, мобільна версія

Рисунок А.6 – Стан дашборду при досягненні денного ліміту витрат
Арк.
ЧДТУ 262206.004.ПЗ
6 3
Змн. Арк. № докум. Підпис Дата

Рисунок А.7 – Модальне вікно додавання транзакції

Рисунок А.8 – Сторінка аналітики витрат, десктопна версія
Арк.
ЧДТУ 262206.004.ПЗ
6 4
Змн. Арк. № докум. Підпис Дата

Рисунок А.9 – Сторінка аналітики витрат, мобільна версія

Рисунок А.10 – Сторінка списку бажань, десктопна версія
Арк.
ЧДТУ 262206.004.ПЗ
6 5
Змн. Арк. № докум. Підпис Дата

Рисунок А.11 – Сторінка списку бажань, мобільна версія

Рисунок А.12 – Сторінка профілю користувача та бюджетних налаштувань
Арк.
ЧДТУ 262206.004.ПЗ
6 6
Змн. Арк. № докум. Підпис Дата

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