ҐМІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ «ХАРКІВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ» Інститут Комп’ютерних наук та інформаційних технологій Кафедра Програмної інженерії та інтелектуальних технологій управління Спеціальність 121 Інженерія програмного забезпечення Освітня програма Інженерія програмного забезпечення До захисту допускаю Завідувач кафедри Андрій КОПП (ім’я та прізвище) (підпис, дата) ДИПЛОМНА РОБОТА __ першого(бакалаврського) рівня вищої освіти Тема роботи Проєктування та розробка вебзастосунку для складання та моніторингу раціону харчування Шифр роботи КН-222с.1.3 (група, номер теми за наказом) Виконавець Димитращук Любомир Іванович (прізвище, ім’я, по-батькові) Керівниця доцент Коваленко Світлана Миколаївна (посада, прізвище, ім’я, по-батькові) Харків 2025 Назва виробу, Назва Фор- Кільк. При- об’єкту або теми документу мат арк. мітка Документи загальні Завдання на ДР А4 1 Пояснювальна записка до ДР А4 60 Ілюстративні матеріали Проєктування та розробка Презентація вебзастосунку для складання та моніторингу раціону харчування А4 21 КН-222с.1.3 ВД Прізвище Підп Дата Розроб. ДИМИТРАЩУК Проєктування та розробка Літ. Аркуш Аркушів Перев. КОВАЛЕНКО вебзастосунку для Д Р Б 1 складання та моніторингу НТУ «ХПІ» Н.конт. ІВАЩЕНКО раціону харчування Кафедра «ПІІТУ» Затв. КОПП Відомість документів МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ «ХАРКІВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ» Інститут Комп’ютерних наук та інформаційних технологій Кафедра Програмної інженерії та інтелектуальних технологій управління Рівень вищої освіти перший (бакалаврський) рівень Спеціальність 121 Інженерія програмного забезпечення Освітня програма Інженерія програмного забезпечення ЗАТВЕРДЖУЮ Завідувач кафедри (підпис) Андрій КОПП (ім’я та прізвище) «____» ______________ 20__ року З А В Д А Н Н Я НА ДИПЛОМНУ РОБОТУ СТУДЕНТУ Димитращуку Любомиру Івановичу (прізвище, ім’я, по батькові) 1 Тема роботи Проєктування та розробка вебзастосунку для складання та моніторингу раціону харчування Керівниця роботи Коваленко Світлана Миколаївна, доцент, к.т.н. (прізвище, ім’я, по батькові, науковий ступінь, вчене звання) затверджена наказом закладу вищої освіти від «21» квітня 2025 р. № 583 2 Термін подання студентом роботи 14.06.2025 р. 3 Вихідні дані до роботи літературні джерела, джерела в мережі Інтернет, електронні книги в вільному доступі 4 Перелік питань, які потрібно розробити у пояснювальній записці Провести аналіз предметної області; зробити постановку задачі дослідження; розробити математичне та алгоритмічне забезпечення; розробити програмне забезпечення; навести приклади застосування програмного забезпечення, проаналізувати отримані результати 3 5 Перелік графічного матеріалу (з точним зазначенням обов’язкових креслеників) Презентація – 18 аркушів А4 6 Консультанти розділів роботи Підпис, дата Прізвище, ініціали та посада Розділ завдання завдання консультанта видав прийняв Економічне обґрунтування Москаленко В.В., професор 7 Дата видачі завдання 21.04.2025 КАЛЕНДАРНИЙ ПЛАН Строк Номер виконання Назва етапів дипломної роботи Примітка етапу етапів роботи 1 Розробка і затвердження календарного плану роботи 22.04.2025 2 Огляд методів щодо розробки інтернет-магазину з 23.04.2025 елементами персоналізованого онлайн-шопінгу на основі штучного інтелекту 3 Розробка алгоритмічного та програмного забезпечення 25.04.2025 4 Тестування розробленого програмного забезпечення 27.04.2025 5 Оформлення звіту 30.04.2025 6 Розробка демонстраційних плакатів 07.05.2025 7 Складання відомості документів (ВД) 15.05.2025 8 Оформлення та комплектування ДР 23.05.2025 9 Подання закінченої ДР на допуск до захисту 31.05.2025 10 Рецензування дипломної роботи 06.06.2025 11 Захист ДР 14.06.2025 Студент Любомир ДИМИТРАЩУК (підпис) (прізвище та ініціали) Керівниця роботи Світлана КОВАЛЕНКО (підпис) (прізвище та ініціали) МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ «ХАРКІВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ» Інститут Комп’ютерних наук та інформаційних технологій Кафедра Програмної інженерії та інтелектуальних технологій управління Спеціальність 121 Інженерія програмного забезпечення Освітня програма Інженерія програмного забезпечення ПОЯСНЮВАЛЬНА ЗАПИСКА до дипломної роботи першого (бакалаврського) рівня вищої освіти на тему Проєктування та розробка вебзастосунку для складання та моніторингу раціону харчування Виконав студент 3с курсу, групи КН-222с Любомир ДИМИТРАЩУК (підпис, прізвище та ініціали) К ерівниця _____ Світлана КОВАЛЕНКО (підпис, прізвище та ініціали) Р ецензентка _____ Каріна МЕЛЬНИК____ (підпис, прізвище та ініціали) Н ормоконтроль ______Оксана ІВАЩЕНКО___ (підпис, прізвище та ініціали) Харків 2025 РЕФЕРАТ Пояснювальна записка до ДР: 60 с., 10 рис., 20 табл., 25 джерел. Ключові слова: ВЕБЗАСТОСУНОК, РАЦІОН ХАРЧУВАННЯ МОНІТОРИНГ, КАЛОРІЙНІСТЬ, АЛГОРИТМ, ХАРЧОВА ЦІННІСТЬ, ПЕРСОНАЛІЗАЦІЯ, СКЛАДАННЯ РАЦІОНУ. Об’єкт дослідження – процес проєктування та реалізації веборієнтованого інструменту для формування та контролю раціону харчування. Мета та цілі роботи – створення ефективного та зручного у використанні вебзастосунку для автоматизованого складання і моніторингу щоденного раціону з урахуванням індивідуальних потреб користувача. Предмет дослідження – методи, алгоритми та технології, які забезпечують персоналізований підхід до формування раціону харчування на основі індивідуальних фізіологічних показників користувача та інформації про поживні характеристики продуктів. У результаті виконання роботи було розроблено вебзастосунок, який дозволяє користувачам формувати та аналізувати свій раціон харчування, отримувати рекомендації відповідно до особистих цілей і потреб. Особливу увагу приділено алгоритмам розрахунку калорійності, поживної цінності, а також механізмам адаптації під такі параметри, як вік, стать, рівень фізичної активності тощо. ABSTRACT Explanatory note to the DW: 60 p., 10 fig., 20 tables, 25 sources. Keywords: WEB APPLICATION, DIET MONITORING, CALORIE, ALGORITHM, NUTRITION, PERSONALIZATION, DIET COMPILATION. The object of the study is the process of designing and implementing a web-based tool for forming and controlling the diet. The purpose and objectives of the work are to create an effective and user-friendly web application for automated compilation and monitoring of the daily diet, taking into account the individual needs of the user. The subject of the study is methods, algorithms and technologies that provide a personalized approach to forming a diet based on the user's individual physiological indicators and information about the nutritional characteristics of products. As a result of the work, a web application was developed that allows users to form and analyze their diet, receive recommendations according to personal goals and needs. Special attention was paid to algorithms for calculating calorie content, nutritional value, as well as mechanisms for adapting to such parameters as age, gender, level of physical activity, etc. 2 ЗМІСТ Перелік познак та скорочень ............................................................................................. 5 Вступ .................................................................................................................................... 6 1 Опис програмної системи та постановка задачі ........................................................... 8 1.1 Опис програмного об’єкта та характеристика ...................................................... 8 1.2 Проблеми розробки сучасних програмних систем ............................................... 9 1.3 Огляд існуючих технологій для вирішення проблем ......................................... 10 1.4 Визначення основних понять: програмна інженерія, програмне забезпечення, функціональні вимоги, атрибути якості ............................................ 11 1.5 Огляд моделей життєвого циклу створення ПЗ та вибір методології .............. 13 1.6 Постановка задачі виконання дипломної роботи ............................................... 15 2 Аналіз існуючих рішень та моделювання бізнес процесів ....................................... 17 2.1 Огляд існуючих програмних систем та технологій ............................................ 17 2.2 Розробка моделей для формалізації бізнес-процесів .......................................... 21 2.3 Розрахунок математичних моделей ...................................................................... 24 3 проектування програмної системи .............................................................................. 26 3.1 Побудова системної архітектури цільової ПС .................................................... 26 3.1.1 Визначення типу системної архітектури ...................................................... 26 3.1.2 UML-діаграма варіантів використання ......................................................... 27 3.1.3 UML-діаграма варіантів використання ......................................................... 29 3.2 Побудова системної архітектури цільової ПС .................................................... 31 3.2.1 Схема алгоритмів ............................................................................................ 31 3.2.2 Концептуальна модель даних ........................................................................ 32 3.2.2 Логічна модель бази даних ............................................................................. 33 3.3 Вибір інструментальних програмних засобів ..................................................... 34 3.3.1 Програмне забезпечення для клієнтської частини ...................................... 35 3.3.2 Програмне забезпечення для бізнес-логіки .................................................. 35 3.3.3 Інструменти для розробки БД та сервісів ..................................................... 35 4 Реалізація програмної системи та тестування ............................................................ 36 3 4.1 Особливості програмної реалізації системи ........................................................ 36 4.1.1 Опис основних програмних компонентів ..................................................... 36 4.1.2 Візуальний інтерфейс користувача ............................................................... 37 4.1.3 Характеристики апаратно-програмної платформи ...................................... 37 4.2 Тестування програмного забезпечення ................................................................ 38 4.3 Оцінка досягнення мети дипломної роботи ........................................................ 40 4.3 Оцінка досягнення мети дипломної роботи ........................................................ 40 4.4 Шляхи вдосконалення та подальший розвиток системи ................................... 41 5 Економічне обґрунтування ........................................................................................... 42 5.1. Обґрунтування доцільності розробки програмного забезпечення .................. 42 5.1.1. Актуальність розробки .................................................................................. 42 5.1.2. Потенційні користувачі системи .................................................................. 42 5.2. Оцінка конкурентоспроможності програмного забезпечення ......................... 43 5.2.1. Аналіз існуючих аналогів .............................................................................. 43 5.2.2. Конкурентні переваги Nutrition .................................................................... 44 5.3. Розрахунок витрат на розробку програмного забезпечення ............................. 44 5.3.1. Трудомісткість розробки ............................................................................... 44 5.3.2. Витрати на оплату праці ................................................................................ 45 5.3.3. Амортизаційні відрахування ......................................................................... 45 5.3.4. Інші витрати .................................................................................................... 46 5.3.5. Загальні витрати на розробку ........................................................................ 46 5.4. Ціноутворення та економічний ефект ................................................................. 46 5.4.1. Методика ціноутворення ............................................................................... 46 5.4.2. Розрахунок економічного ефекту ................................................................. 47 5.4.3. Розрахунок терміну окупності ...................................................................... 48 5.5. Розрахунок витрат на впровадження програмного забезпечення .................... 49 5.5.1. Аналіз вимог до технічного забезпечення ................................................... 49 5.5.2. Витрати на технічне забезпечення ............................................................... 49 5.5.3. Витрати на програмне забезпечення ............................................................ 50 5.5.4. Витрати на навчання персоналу ................................................................... 50 4 5.5.5. Загальні витрати на впровадження ............................................................... 51 5.6. Розрахунок витрат на придбання та впровадження програмного продукту-аналога .......................................................................................................... 51 5.6.1. Вартість придбання ліцензій MyFitnessPal .................................................. 51 5.6.2. Витрати на впровадження MyFitnessPal ...................................................... 52 5.6.3. Загальні витрати на придбання та впровадження MyFitnessPal ................ 52 5.7. Розрахунок експлуатаційних витрат програмного забезпечення..................... 52 5.7.1. Визначення тривалості корисного використання ....................................... 52 5.7.2. Розрахунок експлуатаційних витрат Nutrition ............................................ 53 5.7.3. Розрахунок експлуатаційних витрат MyFitnessPal ..................................... 54 5.7.4. Порівняння експлуатаційних витрат ............................................................ 54 5.8. Оцінка ефекту та ефективності програмного забезпечення ............................. 54 5.8.1. Розрахунок економічного ефекту ................................................................. 54 5.8.2. Розрахунок економічної ефективності ......................................................... 55 5.8.3. Розрахунок терміну окупності ...................................................................... 55 Висновки ........................................................................................................................... 57 Список джерел інформації .............................................................................................. 58 5 ПЕРЕЛІК ПОЗНАК ТА СКОРОЧЕНЬ БД – база даних; БЖВ – білки, жири, вуглеводи; ВООЗ – Всесвітня організація охорони здоров'я; ГБ – Гігабайт; ГГц – Герц; МЖЦ – модель життєвого циклу; ООП – об'єктно-орієнтоване програмування; ПЗ – програмне забезпечення; API – application programming interface; DRY – Don't Repeat Yourself; HTTP – Hypertext Transfer Protocol; HTTPS – HyperText Transfer Protocol Secure; JWT – JSON Web Token; MERN – MongoDB, Express.js, React.js, Node.js; MVC – Model-View-Controller; ORM – Object-relational mapping; REST – Representational State Transfer; RUP – Rational Unified Process; SPA – Single Page Application; SRP – Single Responsibility Principle; SSL – Secure Sockets Layer; TCP – Transmission Control Protocol; TLS – Transport Layer Security; UML – Unified Modeling Language; XP – Extreme Programming. 6 ВСТУП Програмне забезпечення та програмні системи стали невіддільною складовою функціонування комерційних, промислових підприємств, а й закладів охорони здоров’я, освіти, транспорту, сфери обслуговування та навіть побуту. Інформаційні технології істотно підвищують ефективність бізнес-процесів, прискорюють обробку даних, забезпечують автоматизацію рутинних операцій, підтримують прийняття управлінських рішень і сприяють загальному підвищенню якості послуг. У зв’язку з високими темпами урбанізації, малорухливим способом життя, поширеністю шкідливих звичок, незбалансованого харчування та стресових факторів, питання збереження здоров’я та покращення якості життя набувають особливого значення. Здоров’я людини безпосередньо залежить від способу життя, зокрема – від системи харчування. Відсутність контролю за споживанням калорій, макро – та мікронутрієнтів призводить до численних проблем зі здоров’ям, зокрема ожиріння, цукрового діабету, серцево-судинних захворювань тощо. У зв’язку з цим актуальним є створення програмного забезпечення, яке дозволить кожній людині мати зручний, доступний і персоналізований інструмент для моніторингу власного харчування. У сучасних умовах стрімкого розвитку цифрових технологій стає можливим використання вебзастосунків як ефективного засобу для вирішення повсякденних задач. Web-технології забезпечують кросплатформеність, зручність у доступі з будь- якого пристрою, централізоване зберігання даних та інтеграцію з іншими сервісами. Тому саме формат вебзастосунку є оптимальним для реалізації системи, що дозволяє формувати раціон харчування, розраховувати калорійність страв, контролювати дотримання добових норм, вести щоденник харчування та отримувати рекомендації на основі особистих фізіологічних параметрів користувача. Предметною областю дослідження є інтелектуалізований підхід до формування щоденного раціону харчування з можливістю подальшого моніторингу споживаних калорій та поживних речовин. У межах предметної області 7 передбачається автоматизація наступних процесів: реєстрація та автентифікація користувача, введення фізіологічних параметрів (вік, стать, зріст, вага, рівень активності), розрахунок індивідуальних енергетичних потреб, добір страв на основі калорійності та складу, облік спожитих продуктів, аналіз динаміки харчування. З точки зору архітектури, система повинна мати розподілений характер, передбачаючи поділ на клієнтську частину (інтерфейс користувача), серверну частину (обробка логіки, доступ до бази даних), а також централізовану базу даних для зберігання профілів користувачів, довідників продуктів, історії споживання тощо. Метою дослідження є розробка вебзастосунку, який дозволить автоматизувати процес складання та моніторингу раціону харчування користувача, враховуючи індивідуальні фізіологічні показники та харчові потреби. Запропонована система має забезпечити зручний інтерфейс для взаємодії, точні алгоритми розрахунку калорійності, інформативну візуалізацію даних та персоналізовані рекомендації. У результаті реалізації такого ПЗ очікується досягнення соціального ефекту, який проявляється у формуванні здорових харчових звичок серед користувачів, підвищенні рівня обізнаності про власне харчування, а також у сприянні загальному покращенню фізичного стану та профілактиці хронічних захворювань. 8 1 ОПИС ПРОГРАМНОЇ СИСТЕМИ ТА ПОСТАНОВКА ЗАДАЧІ 1.1 Опис програмного об’єкта та характеристика Програмним об’єктом є вебзастосунок, призначений для складання та моніторингу індивідуального раціону харчування. У сучасному інформаційному середовищі, цифрові технології стають основою для вирішення все більшої кількості повсякденних задач, створення подібного програмного забезпечення набуває особливої актуальності. Харчування є однією з ключових складових здорового способу життя, однак підтримка збалансованого раціону вимагає від людини постійного обліку та аналізу інформації про продукти, калорійність, співвідношення білків, жирів і вуглеводів. Ці процеси складні при ручному виконанні, що знижує їх ефективність та призводить до втрати мотивації в користувачів. Розроблений програмний об’єкт дозволить автоматизувати ці процеси шляхом створення зручного онлайн-інструменту, який враховує фізіологічні параметри користувача (вік, стать, зріст, вага, рівень фізичної активності) та на основі цих даних генерує індивідуальні рекомендації щодо щоденного харчування. Основне функціональне призначення системи полягає у формуванні персоналізованого раціону, веденні обліку спожитої їжі, розрахунку калорійності та аналізі статистики у вигляді графіків, діаграм та зведень. Застосунок забезпечує реєстрацію та авторизацію користувачів, введення індивідуальних даних, автоматичний розрахунок добової потреби в калоріях, білках, жирах і вуглеводах, ведення щоденника харчування з можливістю додавання, редагування та видалення записів. У системі реалізована база даних харчових продуктів, яка може оновлюватись і доповнюватись. Для візуалізації даних використовуються інтерактивні діаграми, що дозволяють відслідковувати динаміку змін, наприклад, у споживанні калорій або співвідношенні макроелементів. Програмний об’єкт орієнтований на широку аудиторію:  осіб, що прагнуть підтримувати фізичну форму; 9  тих, хто дотримується спеціальних дієт (наприклад, веганство, діабетичне харчування);  фітнес-тренерів, що супроводжують клієнтів;  дієтологів та просто користувачів, які бажають змінити харчові звички. Головною перевагою вебзастосунку є його доступність з будь-якого пристрою, що має доступ до Інтернету, простота використання, можливість збереження історії та гнучке налаштування під конкретного користувача. 1.2 Проблеми розробки сучасних програмних систем Одна з основних проблем, що постає перед розробниками – це високий рівень складності функціональних вимог. Користувачі очікують, що програмні продукти будуть інформативними, точними та інтуїтивно зрозумілими, швидкими у роботі, привабливими візуально, адаптивними до різних платформ та пристроїв [1]. У випадку з системами для планування харчування ситуація ускладнюється необхідністю точної обробки фізіологічних та дієтологічних даних, що мають медичну природу і часто не є тривіальними для формалізації. Суттєва проблема – неоднорідність і динамічність вхідних даних. Вебзастосунок для моніторингу харчування оперує інформацією, яка постійно оновлюється: це дані про продукти, нові рецепти, зміни в харчових нормах, рекомендації ВООЗ та інших джерел. Необхідність підтримки актуальності таких даних вимагає розробки гнучкої моделі з можливістю оновлення баз знань, що, в свою чергу, потребує ретельного проєктування сховища даних та API-інтерфейсів [2]. Різні користувачі мають різні цілі (схуднення, набір маси, підтримка форми), харчові вподобання (вегетаріанство, безглютенова дієта, низьковуглеводна дієта тощо), а також медичні обмеження (діабет, алергії). Розробка алгоритмів, здатних враховувати всі ці параметри одночасно, є складною задачею з точки зору логіки та оптимізації, адже система має не просто збирати інформацію, а й адекватно обробляти її та пропонувати релевантні рішення. 10 Розроблена система повинна бути готова до зростання кількості користувачів, розширення функціоналу та оновлень без збоїв у роботі. Це потребує грамотної архітектури, впровадження шаблонів проєктування, розділення на модулі та використання масштабованих рішень як на фронтенді, так і на бекенді. 1.3 Огляд існуючих технологій для вирішення проблем На ринку ІТ існує низка технологій, фреймворків та інструментів, які можуть бути використані для розв’язання задач, пов’язаних із розробкою вебзастосунку для моніторингу харчування. Огляд таких рішень дозволяє визначити їхні переваги, обмеження та доцільність застосування у конкретній предметній області. У плані реалізації користувацького інтерфейсу (front-end) широке застосування мають фреймворки React.js, Vue.js та Angular. Вони забезпечують високу продуктивність, компонентний підхід, двобічну прив’язку даних, адаптивність до різних екранів, що є надзвичайно важливим для досягнення якісного користувацького досвіду [3]. У контексті застосунку що розробляється, ці технології дозволяють гнучко реалізувати інтерфейси для введення параметрів, відображення графіків, створення раціону тощо. Для реалізації бізнес-логіки (back-end) найбільш доцільним є використання Node.js у поєднанні з Express.js або NestJS, які забезпечують продуктивність, модульність та масштабованість [4]. Завдяки своїй асинхронності, Node.js здатен ефективно обробляти одночасні запити, що актуально при роботі з великою кількістю користувачів. Для зберігання даних найбільш поширеними є MongoDB (документно- орієнтована СУБД) та PostgreSQL (реляційна СУБД). MongoDB зручно використовувати для роботи з гнучкими структурами, такими як динамічні профілі користувачів або списки страв, у той час як PostgreSQL краще підходить для структурованих фінансових або адміністративних даних [5]. У питанні автентифікації користувачів ефективно застосовуються бібліотеки JWT (JSON Web Token) та OAuth2, що забезпечують надійний захист персональних даних. 11 Для візуалізації даних широко використовуються бібліотеки Chart.js, D3.js, Recharts, які дозволяють будувати інтерактивні графіки, кругові діаграми, гістограми тощо. У контексті проектування та моделювання ПС активно застосовуються нотації UML (Unified Modeling Language) та ER-моделі для проєктування баз даних [6]. UML дозволяє створити чітке технічне бачення архітектури системи, зв’язків між компонентами, сценаріїв використання, алгоритмічних процесів. Технології розгортання та CI/CD, які включають Docker, GitHub Actions, Heroku, Vercel, забезпечують швидке, стабільне та контрольоване розгортання системи. Водночас, попри розмаїття доступних технологій, існують певні обмеження. Наприклад, інтеграція багатьох бібліотек може ускладнити підтримку коду, збільшити розмір програми, знизити продуктивність на слабких пристроях. Деякі фреймворки вимагають високого рівня компетенцій для ефективного використання. 1.4 Визначення основних понять: програмна інженерія, програмне забезпечення, функціональні вимоги, атрибути якості Розуміння таких термінів, як програмна інженерія, програмне забезпечення, функціональні вимоги та атрибути якості, дозволяє правильно сформулювати цілі проєкту, обрати адекватні підходи до його реалізації, а також забезпечити високу якість кінцевого продукту. Програмна інженерія – це дисципліна, що займається розробкою, супроводом і управлінням програмними продуктами з урахуванням вимог замовника, ресурсних обмежень, стандартів якості та життєвого циклу системи [7]. Це не просто процес написання коду, а комплексна діяльність, яка включає аналіз вимог, проєктування архітектури, тестування, впровадження, документування, супровід та еволюцію програмного забезпечення. Програмна інженерія об’єднує як інженерні, так і наукові підходи до вирішення задач автоматизації в різних предметних галузях, орієнтуючись на створення масштабованих, надійних, ефективних і зручних у використанні програмних продуктів. 12 Програмне забезпечення (ПЗ) – це структурований набір інструкцій, даних та пов’язаної з ними документації, призначений для виконання на комп’ютерах або інших цифрових пристроях [8]. ПЗ включає в себе як прикладні, так і системні компоненти, модулі інтерфейсу, бази даних, алгоритмічну логіку, бібліотеки, допоміжні скрипти, а також технічну й користувацьку документацію. Функціональні вимоги – це сукупність описів того, що саме повинна робити система. Вони визначають функціональність програмного забезпечення з точки зору користувача, охоплюючи сценарії використання, реакцію системи на ті чи інші дії, можливості та сервіси, які має надавати продукт. Для вебзастосунку, що розробляється, функціональні вимоги можуть включати:  можливість реєстрації та авторизації користувача;  введення фізіологічних даних (вік, зріст, вага, стать, рівень фізичної активності);  автоматичний розрахунок добової норми калорій і макроелементів (білки, жири, вуглеводи); пошук і додавання продуктів до раціону;  створення меню на день або тиждень; перегляд статистики споживання;  редагування особистих параметрів; перегляд історії харчування;  формування рекомендацій на основі аналізу даних тощо. Функціональні вимоги слугують основою для технічного проєктування системи і прямо впливають на вибір архітектури, структури бази даних, способів взаємодії компонентів та підходів до тестування [9]. Атрибути якості, або нефункціональні вимоги, визначають як саме система повинна виконувати свої функції. Це властивості, які не стосуються конкретного функціоналу, але мають критичне значення для зручності, надійності, ефективності та безпеки роботи програмного продукту. Найбільш значущими атрибутами якості у контексті даної роботи є:  юзабіліті – інтерфейс має бути інтуїтивно зрозумілим, легким у навігації, естетично привабливим;  продуктивність – система має забезпечувати швидкий відгук на дії користувача, мінімізувати час завантаження сторінок і запитів до БД; 13  масштабованість – програмний продукт повинен легко адаптуватися до зростання кількості користувачів або обсягу даних без втрати продуктивності;  безпека – захист особистих даних користувача, унеможливлення несанкціонованого доступу, шифрування чутливої інформації;  сумісність – можливість коректної роботи на різних пристроях (десктоп, мобільний телефон, планшет) та в різних браузерах;  підтримуваність і розширюваність – зручність у внесенні змін, оновлення функціоналу, виправлення помилок. Формалізація функціональних вимог та атрибутів якості є однією з найважливіших фаз розробки, оскільки від неї залежить як рівень задоволеності користувача, так і технічна спроможність команди розробників досягнути бажаного результату. Чітке розмежування між тим, що робить система, і тим, як вона це робить, дозволяє уникнути помилок, що часто виникають при неправильному трактуванні завдань і цілей. 1.5 Огляд моделей життєвого циклу створення ПЗ та вибір методології Процес розробки програмного забезпечення – це складна послідовність взаємопов’язаних етапів, що охоплює аналіз потреб користувачів, формування вимог, проєктування, реалізацію, тестування, впровадження, супровід і модернізацію програмного продукту [10]. Цей процес прийнято описувати за допомогою моделей життєвого циклу програмного забезпечення (МЖЦ ПЗ), які слугують методичними основами для управління розробкою, ресурсами, термінами та якістю ПЗ. На сьогодні існує велика кількість моделей МЖЦ, кожна з яких має свої переваги, недоліки та сфери доцільного застосування. Найбільш відомими є такі моделі, як каскадна (waterfall), спіральна (spiral model), інкрементна (incremental model), ітеративна, V-подібна модель (V-model), а також гнучкі (agile) підходи – Scrum, Kanban, XP (Extreme Programming), RUP (Rational Unified Process) тощо [11]. Каскадна модель передбачає послідовне проходження всіх етапів розробки без можливості повернення до попередніх. Кожна фаза має чітко визначені вхідні та 14 вихідні артефакти, а перехід до наступної можливо лише після повного завершення попередньої. Основна перевага цієї моделі – простота управління проєктом, документованість кожного кроку [12]. Проте в умовах, коли вимоги можуть змінюватися в процесі реалізації або уточнюватися вже після початку розробки, каскадна модель виявляється негнучкою та застарілою. Спіральна модель поєднує переваги каскадної моделі з можливістю ітерацій та поступової деталізації продукту. Вона орієнтована на управління ризиками та дає змогу поступово формувати систему через цикл аналізу, проєктування, реалізації, оцінки [11]. Хоча ця модель дозволяє гнучко реагувати на зміни та має високу адаптивність, її застосування передбачає серйозне ресурсне та фінансове забезпечення, що не завжди можливо в умовах дипломного проєкту. Інкрементна модель передбачає розробку ПЗ поетапно: кожен інкремент – це завершена частина функціоналу, яку можна розгорнути та використовувати незалежно від інших. Перевага полягає в тому, що користувачі отримують доступ до основних можливостей системи ще до завершення повної реалізації [13]. Це підвищує зворотній зв'язок та дозволяє краще реагувати на очікування. Інкрементна модель особливо добре підходить для вебзастосунків, де можливо окремо реалізовувати функціональність авторизації, формування раціону, перегляду статистики тощо. Agile методології за останнє десятиліття стали стандартом у розробці web- застосунків. Основні цінності Agile – це взаємодія з користувачем, швидка поставка результатів, постійна адаптація до змін і мінімізація зайвої документації [14]. У межах Agile-підходів широко використовуються такі методології, як:  Scrum – дозволяє розбити розробку на спринти (зазвичай по 2 тижні), в межах яких реалізуються чітко визначені задачі. Scrum забезпечує регулярне зворотне інформування між учасниками команди, гнучке реагування на зміну пріоритетів і прозорість виконання робіт;  Extreme Programming (XP) – акцентує увагу на постійному тестуванні, рефакторингу коду, тісній взаємодії з користувачем і спрощенні програмного коду. Особливо ефективна в умовах нестабільних або неповних вимог; 15  Rational Unified Process (RUP) – комбінує об’єктно-орієнтоване проєктування (ООП) з ітераційним підходом і передбачає розробку через серії релізів з чітко визначеними фазами: ініціалізація, деталізація, побудова, впровадження. У процесі аналізу предметної області, вимог до майбутньої системи, специфіки користувачів, а також з урахуванням ресурсних та часових обмежень дипломної роботи, було прийнято рішення обрати ітераційно-інкрементну модель, реалізовану в межах Scrum-підходу. Такий вибір обґрунтований низкою факторів:  потреба в регулярному тестуванні проміжного функціоналу (реєстрація, введення параметрів, калькулятор калорійності, перегляд раціону);  можливість швидкого отримання зворотного зв’язку на кожному етапі;  гнучкість у внесенні змін до функціоналу без перебудови всієї архітектури;  високий ступінь повторного використання коду;  прозорість процесу розробки;  зручність у реалізації дипломного проєкту поетапно (розробка MVP, подальше розширення функціоналу). Вибір Scrum як методології дозволяє ефективно реалізувати продукт у стислі терміни з мінімальними ризиками та високою адаптивністю. 1.6 Постановка задачі виконання дипломної роботи Розробка програмного забезпечення для підтримки здорового харчування – це технічне завдання та міждисциплінарна проблема, що поєднує в собі елементи програмної інженерії, дієтології, аналітики даних, UX-дизайну та інформаційної безпеки. Враховуючи зростаючий попит на інструменти, які допомагають користувачам контролювати власний раціон, виникає необхідність створення адаптивного, інформативного та надійного вебзастосунку, здатного працювати з персоналізованими харчовими сценаріями. Передбачається реалізація повноцінного вебзастосунку, який надає користувачам засоби для складання персонального раціону харчування, враховуючи індивідуальні фізіологічні характеристики, цілі (схуднення, підтримка ваги, набір 16 маси) та особливості дієти. Застосунок повинен підтримувати моніторинг фактичного споживання калорій та макроелементів (білків, жирів, вуглеводів), відображати статистику у вигляді інтерактивних графіків, дозволяти аналіз динаміки та формувати рекомендації на основі зібраних даних. Для досягнення поставленої мети необхідно вирішити наступні ключові задачі:  проаналізувати предметну область і дослідити наявні програмні продукти, які частково або повністю реалізують подібний функціонал;  обґрунтувати доцільність розробки нового програмного забезпечення та визначити його переваги й відмінності;  сформулювати вимоги до системи, визначивши як функціональні, так і нефункціональні характеристики;  розробити концептуальну модель системи, включаючи моделі даних, структуру взаємодії компонентів, користувацькі сценарії;  побудувати системну архітектуру вебзастосунку з урахуванням кросплатформеності, масштабованості та захищеності;  реалізувати застосунок із використанням сучасних фреймворків, мов програмування, систем управління базами даних;  провести тестування реалізованого рішення на відповідність вимогам, оцінити якість функціонування. У результаті виконання дипломної роботи має бути створена програмна система, яка дозволить користувачам формувати індивідуальні раціони харчування, здійснювати моніторинг споживання поживних речовин, відслідковувати прогрес і приймати більш обґрунтовані рішення щодо власного харчування. 17 2 АНАЛІЗ ІСНУЮЧИХ РІШЕНЬ ТА МОДЕЛЮВАННЯ БІЗНЕС ПРОЦЕСІВ 2.1 Огляд існуючих програмних систем та технологій У контексті проєктування вебзастосунку для складання та моніторингу раціону харчування доцільним є вивчення найпопулярніших сучасних програмних систем, які вже реалізують подібний функціонал. Аналіз сильних і слабких сторін таких рішень дозволяє не лише краще зрозуміти очікування користувачів, а й уникнути повторення типових помилок, врахувати невирішені проблеми та вдосконалити нову систему. Серед найбільш розповсюджених вебзастосунків для моніторингу харчування є – Yazio, MyFitnessPal і FatSecret. Ними вони мають мільйони користувачів по всьому світу, активно розвиваються і використовуються як людьми, що прагнуть слідкувати за здоров’ям, так і професійними тренерами, дієтологами, спортсменами. Нижче наведено розгорнутий порівняльний огляд цих систем за основними критеріями: функціональність, зручність використання, інтерфейс (UI/UX), точність даних, технологічна гнучкість та можливість інтеграції. Yazio – це одна з найдинамічніших платформ останніх років, яка позиціонує себе як особистий помічник у харчуванні. Застосунок дозволяє створювати індивідуальні плани харчування, вести облік калорій та макроелементів, контролювати динаміку ваги, слідкувати за кількістю випитої води та навіть підтримувати періодичне голодування [15]. Інтерфейс Yazio є надзвичайно сучасним, мінімалістичним та інтуїтивно зрозумілим. Дизайн побудований на яскравих, але не агресивних кольорах, із логічно структурованими елементами керування (Див. рис. 2.1). Система надає детальні графіки споживання калорій, білків, жирів і вуглеводів, які легко читаються та розуміються навіть користувачами без технічної підготовки. Великим плюсом є адаптивність застосунку для мобільних платформ і веббраузерів. 18 Рисунок 2.1 – Інтерфейс веб-застосунку Yazio Yazio використовує широку базу продуктів харчування, що постійно оновлюється. Проте її головною перевагою є гнучкість у створенні власних страв і меню. Застосунок також підтримує інтеграцію з фітнес-браслетами, мобільними трекерами активності (Google Fit, Apple Health) та надає преміум-функціонал – включаючи готові плани харчування, інструкції для кетодієти, вегетаріанського раціону тощо. Попри велику кількість функцій, Yazio залишається простим у використанні. Початкове налаштування займає кілька хвилин, а щоденне користування вимагає мінімальних зусиль – додавання продуктів відбувається в кілька натискань. Це значно підвищує шанси, що користувачі не покинуть застосунок через складність чи перевантаженість інтерфейсу. MyFitnessPal – один із найбільш відомих і авторитетних застосунків у сфері здорового харчування, з понад 200 мільйонами завантажень по всьому світу. Він надає величезний обсяг функціональності – від класичного обліку калорій до трекінгу макро- і мікроелементів, відстеження фізичної активності, ваги, водного балансу, щоденників настрою, і навіть журналу прогресу [16]. 19 Рисунок 2.2 – Інтерфейс веб-застосунку MyFitnessPal MyFitnessPal також має мобільну та вебверсію, синхронізується з десятками фітнес-пристроїв (Garmin, Fitbit, Samsung Health), підтримує імпорт тренувань та навіть дозволяє відслідковувати рівень вітамінів і мінералів. Що стосується доступності – основні функції є безкоштовними, але розширена аналітика, більш точні цілі, підсумки та безрекламний інтерфейс – тільки у преміум- версії. FatSecret – менш медійно відомий, але не менш функціональний інструмент для відстеження харчування. Його головна перевага – простота у використанні та фокус на базовому користувачі, який хоче вести журнал харчування без перевантаження зайвими функціями [17]. FatSecret має привабливий, але простий інтерфейс. Інформація подається лаконічно, меню чітке, усі ключові функції (додавання їжі, перегляд денної норми, історія харчування) доступні буквально в кілька кліків (див. рис. 2.3). Це чудовий варіант для користувачів, які вперше знайомляться з подібними застосунками. 20 Рисунок 2.3 – Інтерфейс веб-застосунку FatSecret Великим плюсом є наявність соціальних елементів: у FatSecret є спільнота користувачів, які можуть ділитися досвідом, рецептами, досягненнями. Це додає мотивації та відчуття підтримки, що особливо важливо при досягненні довготривалих цілей – схуднення, контроль рівня глюкози тощо. FatSecret також пропонує візуалізацію статистики, зручний календар харчування, підтримку сканування штрихкодів і імпорт тренувань з інших сервісів. Проте функціональність у безкоштовній версії обмежена, а додавання нових страв чи редагування поживних елементів може бути дещо менш зручним, ніж у Yazio чи MyFitnessPal. У таблиці 2.1 міститься порівняльна характеристика розглянутих веб- застосунків. Таблиця 2.1 – Порівняльна характеристика розглянутих веб-застосунків Критерій Yazio MyFitnessPal FatSecret Дизайн та UX Сучасний, Функціональний, Простий, зручний адаптивний менш сучасний для новачків Повнота бази Велика Надзвичайно Середня продуктів велика Функціональність Висока Дуже висока Середня 21 Кінець таблиці 2.1 Критерій Yazio MyFitnessPal FatSecret Легкість Висока Середня Висока використання Інтеграція з Є Дуже широка Є іншими сервісами Соціальні функції Ні Частково (друзі) Так (спільнота, форуми) Платформа Мобільна, Web Мобільна, Web Мобільна, Web Платна версія Так (Premium) Так (Premium) Так (Premium) Проаналізовані програмні системи є потужними інструментами для складання та контролю раціону. Вони охоплюють широкий спектр функцій, мають різні підходи до візуалізації, взаємодії з користувачем та гнучкості налаштувань. Проте жодна з них не є універсальною, а деякі аспекти – як-от простота використання, локалізація, підтримка специфічних дієт чи облік медичних факторів – можуть бути реалізовані краще. Це відкриває можливість для розробки нового вебзастосунку, який поєднує переваги наявних систем, але уникає їх недоліків: надає простий, адаптивний інтерфейс, підтримує персоналізацію під користувача, дає змогу формувати гнучкі плани харчування й аналізувати прогрес без перевантаження системи зайвою функціональністю. 2.2 Розробка моделей для формалізації бізнес-процесів Проєктування сучасних програмних систем вимагає визначення функціональних вимог та формалізованого опису бізнес-процесів, які система повинна автоматизувати. Така формалізація дає змогу точно уявити структуру роботи майбутнього застосунку, визначити ролі, ресурси, вхідні та вихідні дані, а також відобразити взаємозв’язки між усіма складовими системи. Вона служить фундаментом для проєктування архітектури, вибору алгоритмів, побудови бази даних, а також є основою для подальшої валідації, верифікації й тестування програмного продукту. 22 Формалізація бізнес-процесів виконана з використанням нотації IDEF0, яка є однією з найбільш розповсюджених у практиці інженерії програмного забезпечення. Основна перевага цієї нотації полягає в наочності, строгій структурованості та можливості розширення моделі без втрати логічної цілісності [18]. У нотації IDEF0 кожна функція (тобто дія або процес) зображується у вигляді прямокутника, а її зв’язки з іншими об’єктами моделі (даними, ресурсами, обмеженнями) – у вигляді стрілок чотирьох типів:  вхідні дані (Input) – стрілки, що входять у блок зліва, описують інформацію або ресурси, необхідні для виконання процесу;  керування (Control) – стрілки, що входять згори, відображають нормативи, правила або обмеження, які визначають, як саме має бути реалізовано процес;  механізм (Mechanism) – стрілки знизу, які позначають засоби, ресурси або учасників, що забезпечують виконання процесу.  вихідні дані (Output) – стрілки, що виходять праворуч, позначають результат діяльності процесу. У межах цієї роботи сформовано базову модель, яка відображає бізнес-процес формування добового раціону харчування користувача, що є ключовим функціональним ядром майбутнього вебзастосунку. На рисунку 2.4 зображено узагальнений вигляд функціонального блоку A0 «Формування добового раціону». Рисунок 2.4 – Узагальнений вигляд функціонального блоку 23 Цей блок описує центральну дію, яку виконує система – генерація збалансованого раціону харчування на основі персональних даних користувача та списку обраних продуктів:  форма функції: прямокутник із написом Формування добового раціону.  керуюча стрілка (зверху): харчові норми користувача. Вони є регламентом, що визначає, скільки калорій, білків, жирів, вуглеводів має бути включено до щоденного раціону. Ці дані формуються на основі фізіологічних характеристик: вік, стать, вага, ріст, рівень фізичної активності, а також дієтична мета (схуднення, набір маси тощо).  вхідна стрілка (зліва): обрані продукти. Користувач із бази даних системи (або вручну) формує список продуктів, які є доступними або бажаними до вживання. Вони містять інформацію про калорійність, БЖВ, порцію тощо.  механізм (знизу): користувач, система обліку продуктів. Користувач є ініціатором процесу, вводить дані, змінює налаштування, оцінює результати. Система обліку продуктів включає алгоритми, бази даних, інтерфейс для взаємодії з цими даними.  вихідна стрілка (праворуч): добовий раціон у вигляді списку страв. Це готовий результат – перелік рекомендованих страв та продуктів із зазначенням кількості, енергетичної цінності, часу споживання та ін. Цей раціон буде збережений у профілі користувача та використаний у статистиці, візуалізаціях і подальших діях. Ця модель ілюструє логіку функціонування ядра застосунку та слугує основою для декомпозиції процесу на підфункції нижчого рівня, зокрема: підбір продуктів, перевірка відповідності до норм, обрахунок калорійності, формування порцій, перевірка залишків у базі тощо. Розроблена модель формалізації процесу дозволяє:  визначити ключові точки взаємодії користувача з системою;  уніфікувати логіку роботи програмного продукту відповідно до правил дієтології;  створити структурований підхід до реалізації алгоритмів; 24  спростити перехід до UML-діаграм, діаграм активності, послідовностей тощо;  пояснити технічній команді (чи рецензентам) логіку системи ще до написання коду. Завдяки IDEF0 модель стає засобом для опису ідеї та ефективним інструментом управління складністю, що дозволяє поетапно декомпонувати складні бізнес-процеси, залишаючись у межах логічної цілісності. 2.3 Розрахунок математичних моделей У процесі формування раціону використовуються такі основні математичні моделі: Розрахунок базової потреби в калоріях (BMR – Basal Metabolic Rate), наприклад, за формулою Маффіна-Джеора: де – маса тіла (кг), ℎ – зріст (см), – вік (років), – коефіцієнт статі: +5 для чоловіків, -161 для жінок. Розрахунок добової потреби в калоріях з урахуванням фізичної активності (TDEE – Total Daily Energy Expenditure): де PAL – коефіцієнт фізичної активності (наприклад, 1.2 – сидячий спосіб життя, 1.55 – середня активність, 1.9 – висока активність). Формування цільових значень для нутрієнтів (білків, жирів, вуглеводів) у грамах на день відповідно до встановленого співвідношення (наприклад, 30% білки, 30% жири, 40% вуглеводи): 25 , , де – цільова кількість білків (г), – цільова кількість жирів (г), – цільова кількість вуглеводів (г), 𝑝, 𝑓, 𝑐 – відповідні відсотки (у вигляді десяткових дробів). Сумарна енергетична цінність обраних продуктів (на основі їх харчової інформації): ∑ де – калорійність одиниці -го продукту (ккал/г), – кількість спожитого продукту (г), 𝑛 – загальна кількість продуктів у раціоні. Перевірка відповідності цільовим значенням може проводитися за допомогою обчислення відхилення: | | де – відповідна величина (калорії, білки, жири, вуглеводи), – відсоткове відхилення фактичного значення від цільового. Ці формули є невід’ємною частиною реалізації алгоритмів вебзастосунку, оскільки дозволяють автоматизувати обчислення та адаптацію добового раціону під індивідуальні потреби користувача. 26 3 ПРОЕКТУВАННЯ ПРОГРАМНОЇ СИСТЕМИ 3.1 Побудова системної архітектури цільової ПС Цільова програмна система, що розробляється в межах дипломного проєкту, покликана забезпечити користувачам зручний інструмент для створення, персоналізації та щоденного моніторингу раціону харчування. Основна функціональність охоплює ведення персонального профілю, облік споживаних страв і продуктів, формування рекомендованого меню, моніторинг фізичних навантажень, налаштування харчових вподобань, перегляд статистики та зворотний зв’язок. На етапі формування архітектури було прийнято рішення розробити систему як SPA-застосунок (Single Page Application) з використанням React.js на клієнтській стороні, Node.js з Express.js на сервері та MongoDB як системи управління базами даних [19]. Це дає змогу реалізувати гнучку трирівневу архітектуру з чітким розділенням відповідальності між фронтендом, бекендом і сховищем даних. Клієнтська частина (папка client) містить папки components, pages, utils, що демонструє модульну організацію, спрямовану на повторне використання коду та зручну підтримку. Компоненти інтерфейсу винесені в окрему структуру, а кожна логічна сторінка застосунку реалізована як окремий підрозділ. Серверна частина (server) структурована за класичним REST-підходом і включає моделі (models) для роботи з базою даних, маршрути (routes) для обробки HTTP-запитів, утиліти для автентифікації (utils/_auth) і конфігураційні файли. 3.1.1 Визначення типу системної архітектури Цільова архітектура вебзастосунку реалізована у вигляді трирівневої клієнт- серверної архітектури, яка також відповідає моделі SPA та логіці RESTful API [20]. Перший рівень – презентаційний (клієнтський інтерфейс), реалізований із використанням React.js. Він відповідає за візуалізацію інформації, взаємодію з користувачем, обробку подій та надсилання запитів до серверної частини. Користувач взаємодіє з єдиною HTML-сторінкою, яка динамічно оновлює контент за допомогою JavaScript, що значно покращує швидкість і плавність використання системи. У каталозі client/src/pages реалізовано такі підсистеми, як відображення 27 інформації про харчування (foodInfo), облік прийомів їжі (mealTracker), облік фізичної активності (exerciseTracker), управління вподобаннями (preferences), формування меню (menu, recommendedMenuItems, savedMenuItems), робота з особистим профілем (personalInfo) тощо. Другий рівень – серверний (логіка обробки запитів, бізнес-логіка), побудований на Node.js з Express.js. Він приймає HTTP-запити з клієнта, виконує перевірку прав доступу, взаємодіє з базою даних, проводить розрахунки (наприклад, оцінку раціону або формування рекомендацій) та повертає відповіді у форматі JSON. Сервер розділений на логічні блоки: routes для маршрутизації, models для роботи з MongoDB (ймовірно, через Mongoose), utils для службових функцій. Третій рівень – рівень даних (сховище), базується на NoSQL СУБД – MongoDB. Всі дані користувача – профілі, вподобання, прийоми їжі, оцінки, повідомлення – зберігаються у вигляді документів у колекціях. Моделі, що відповідають за структуру цих даних, розміщені в server/models. Обрана архітектура є логічно обґрунтованою та зручною з практичної точки зору. Вона дозволяє легко додавати нову функціональність без суттєвого переписування коду, забезпечує масштабованість, підтримує паралельну розробку фронтенду і бекенду, а також гарантує безпечну та швидку взаємодію з базою даних. Використання REST API відкриває можливості для майбутньої інтеграції з мобільними застосунками, сторонніми трекерами або хмарними сервісами. Застосування шаблонів проектування, таких як MVC (Model-View-Controller), DRY (Don't Repeat Yourself) і SRP (Single Responsibility Principle), посилює структурованість системи. 3.1.2 UML-діаграма варіантів використання UML-діаграма варіантів використання (use case діаграма), наведена на рисунку 3.1, відображає взаємодію між зовнішніми акторами – користувачами, адміністраторами та зовнішніми системами – і функціональністю, яку пропонує система. 28 Рисунок 3.1 – UML-діаграма варіантів використання Користувач є центральною фігурою взаємодії з програмним продуктом. Він має доступ до таких основних сценаріїв: реєстрація, вхід у систему, створення раціону, редагування раціону, перегляд раціону та перегляд історії споживання. Всі ці дії реалізуються у межах єдиного інтерфейсу і передбачають персоніфіковану логіку роботи з обліковим записом. Варіант використання «Логін в систему» тісно пов’язаний із процесом реєстрації, а також із доступом до усіх персональних даних, адже без автентифікації користувач не може виконувати жоден із функціональних сценаріїв. Функції створення та редагування раціону містять обов’язковий підпроцес перегляду раціону, тому між цими варіантами встановлено зв’язок включення (<>), що означає автоматичне виконання певної дії в межах іншої. У системі передбачено механізм розширення функціональності, зокрема через інтеграцію з зовнішніми сервісами. Цей процес пов’язаний із переглядом раціону як додатковий сценарій, що може активуватися лише в певних випадках. Цей підхід реалізується через зв’язок розширення (<>), який дозволяє підключити допоміжну функцію лише тоді, коли це необхідно. Відповідно, у моделі додано маркер extension points, який вказує, що дану дію можна буде масштабувати або інтегрувати з іншими сервісами, не порушуючи основної логіки взаємодії користувача із системою. 29 Адміністратор системи має окрему зону відповідальності – він виконує додавання нових продуктів у базу даних. Це дозволяє підтримувати актуальність і повноту інформації, необхідної для розрахунку калорійності та складання збалансованого раціону. На діаграмі адміністратор представлений як окремий актор, що взаємодіє з варіантом використання «Додаванням продукту», не маючи доступу до функцій, пов’язаних із персональними налаштуваннями користувачів. 3.1.3 UML-діаграма варіантів використання Діаграма програмних компонентів, представлена на рисунку 3.2, моделює архітектуру цільової програмної системи як розподіленої мікросервісної структури. Кожен прямокутник на діаграмі позначає окремий компонент (або сервіс), який реалізує автономну частину функціональності й взаємодіє з іншими сервісами через інтерфейси API. Усі компоненти інтегруються через центральний елемент – API Gateway, що виконує роль єдиного вхідного пункту у систему, централізуючи маршрутизацію запитів, обробку автентифікації, логування, керування кешем і безпекою. Саме API Gateway дозволяє реалізувати спрощену взаємодію фронтенд- застосунку з великою кількістю внутрішніх сервісів, які діють у розподіленому середовищі. Рисунок 3.2 – Діаграма програмних компонентів Authentication Service – окремий сервіс, відповідальний за автентифікацію та авторизацію користувачів. Його ізольованість дозволяє реалізувати безпечну 30 перевірку облікових даних, генерацію JWT-токенів, керування сесіями користувачів і контроль доступу до ресурсів на основі ролей. User Service виконує функції з управління обліковими записами, профілями користувачів, збереженими персональними параметрами, включаючи вік, стать, фізичну активність, алергії, харчові вподобання тощо. Він є критичним для побудови персоналізованого досвіду використання застосунку, оскільки надає основу для адаптації рекомендацій і розрахунку добових норм калорійності. Meal Plan Service реалізує одну з головних бізнес-функцій системи – створення, редагування та перегляд раціонів. Цей компонент оперує логікою формування меню на основі даних користувача, поживної цінності продуктів, історії споживання та інших факторів. Він також взаємодіє з сервісами моніторингу та базою продуктів для побудови збалансованих раціонів відповідно до медичних або дієтичних рекомендацій. Food Database Service відповідає за доступ до детальної інформації про продукти харчування – калорійність, вміст макро- та мікроелементів, тип продукту, порції тощо. Monitoring Service реалізує функціональність з відстеження харчової поведінки користувача, контролю за дотриманням раціону, аналізу динаміки прогресу, формування звітів і сповіщень. Кожен із зазначених сервісів пов’язаний із центральним шлюзом – API Gateway, через який здійснюється вся зовнішня взаємодія. Така архітектура забезпечує масштабованість: кожен сервіс може бути розгорнутий окремо, оновлений або замінений без зупинки роботи всієї системи. Така модульна структура значно підвищує надійність. Якщо один із компонентів тимчасово недоступний, решта системи може продовжувати свою роботу. З точки зору розгортання, кожен компонент може бути представлений окремим контейнером (наприклад, у Docker), що полегшує розподілену інфраструктуру. 31 3.2 Побудова системної архітектури цільової ПС 3.2.1 Схема алгоритмів Схема алгоритму відображає основну логіку роботи вебзастосунку (див. рис. 3.3). Користувач починає з реєстрації, після чого виконує вхід у систему. Далі відбувається перевірка наявності раціону. Якщо раціон вже створено, користувач може його переглядати або редагувати. Якщо ні – система пропонує створити новий раціон. Додатково доступні функції перегляду історії споживання та додавання продуктів (для адміністратора). Після виконання дій – кінець роботи з системою. Алгоритм охоплює всі базові сценарії та забезпечує просту послідовну навігацію користувача. Рисунок 3.3 – Схема алгоритмів 32 3.2.2 Концептуальна модель даних Концептуальна модель даних зображена на рисунку 3.4 відображає основні сутності, зв’язки між ними та структуру збереження інформації в системі. Центральною сутністю є таблиця users, яка зберігає облікові та персональні дані користувачів, а також їхні вподобання, фізіологічні показники, харчові звички та активність у форматі JSON. Рисунок 3.4 – Концептуальна модель даних 33 Таблиця menuitems містить інформацію про страви: назву, дату подачі, харчову цінність, складники, алергени та рейтинг. Зв’язок з diningcourts реалізовано через проміжну таблицю diningcourts_has_menuitems, що фіксує, які страви доступні у яких їдальнях. Таблиця saveditems зберігає дані про збережені користувачем страви. ratings – оцінки, які користувачі надають стравам. problems – звернення користувачів щодо помилок або проблем із застосунком. Модель чітко розділяє відповідальність між обліковими даними, харчовими елементами, збереженими вподобаннями та зворотним зв’язком. 3.2.2 Логічна модель бази даних Логічна модель бази даних складається з шести основних сутностей: User, MenuItem, DiningCourt, Saved, Rating, Problem. Модель побудована з урахуванням зв’язків між користувачами, стравами та об'єктами харчування (див. рис. 3.5). Рисунок 3.5 – Логічна модель даних Сутність User містить облікові та персональні дані користувача: ім’я, email, телефон, пароль, налаштування, обмеження та улюблені страви. Один користувач 34 може зберігати багато страв (Saved), залишати багато оцінок (Rating) і створювати багато скарг (Problem). Сутність MenuItem містить інформацію про страву: ID, назву, дату подачі, ознаку вегетаріанства, алергени, харчові факти, середній рейтинг. Одна страва може бути оцінена багатьма користувачами (Rating) і збережена в багатьох профілях (Saved). Сутність DiningCourt зберігає інформацію про їдальні: назву, офіційну назву, ідентифікатор Google та опис. Один об'єкт харчування має багато страв (MenuItem), одна страва належить лише одній їдальні. 3.3 Вибір інструментальних програмних засобів Для реалізації вебзастосунку використано стек технологій MERN, який включає:  MongoDB – документо-орієнтовану NoSQL базу даних, що зберігає інформацію у форматі JSON-подібних документів. Забезпечує гнучке зберігання користувацьких налаштувань, харчових записів, страв, оцінок та історії споживання [21].  Express.js – серверний фреймворк для Node.js, що відповідає за обробку HTTP-запитів, маршрутизацію, авторизацію, роботу з базою даних через Mongoose та реалізацію REST API [22].  React.js – бібліотека для побудови інтерфейсу користувача. Забезпечує динамічне оновлення контенту, роботу з формами, валідацію введених даних, побудову адаптивного SPA з поділом на компоненти [23].  Node.js – середовище виконання JavaScript на сервері, що забезпечує асинхронну обробку запитів, масштабованість і інтеграцію з базою даних MongoDB [24]. Для автентифікації використано JWT (JSON Web Tokens). Стилізацію реалізовано за допомогою SCSS. Система керування пакетами – npm. Бекенд та фронтенд розділені на окремі модулі з власною структурою, що дозволяє підтримувати чисту архітектуру проєкту. 35 3.3.1 Програмне забезпечення для клієнтської частини Клієнтська частина реалізована з використанням React.js, яка забезпечує створення односторінкового застосунку (SPA) із швидким оновленням даних без перезавантаження. Компонентний підхід дозволяє розділити інтерфейс на незалежні частини. Для маршрутизації застосовано React Router. Для стилізації інтерфейсу використано SCSS. Керування станом здійснюється за допомогою React Context API 3.3.2 Програмне забезпечення для бізнес-логіки Бізнес-логіка реалізована з використанням Node.js з фреймворком Express.js, який забезпечує обробку запитів, маршрутизацію, авторизацію, логіку взаємодії з базою даних та реалізацію API. Для автентифікації використано JWT. Логіка структурується через маршрути, контролери та моделі. Сервер підтримує REST- архітектуру для взаємодії з фронтендом. 3.3.3 Інструменти для розробки БД та сервісів Для зберігання даних використано MongoDB, яка дозволяє працювати з JSON- подібними структурами. Для зв’язку з базою даних використано Mongoose – ORM для Node.js. Моделі описують структуру колекцій, забезпечують валідацію та зв’язки між сутностями. Для тестування використовуються Jest і Postman. Розгортання локально виконується через npm. 36 4 РЕАЛІЗАЦІЯ ПРОГРАМНОЇ СИСТЕМИ ТА ТЕСТУВАННЯ 4.1 Особливості програмної реалізації системи 4.1.1 Опис основних програмних компонентів Основні програмні компоненти вебзастосунку реалізовано в межах архітектури MERN. Клієнтська частина побудована з використанням бібліотеки React.js, що дає змогу реалізувати сучасний односторінковий застосунок з динамічною маршрутизацією, реактивним оновленням інтерфейсу та гнучкою організацією компонування. Компоненти реалізовано окремими модулями для кожної логічної частини: реєстрація, логін, створення та перегляд раціону, налаштування профілю, моніторинг ваги, сну, води, харчових добавок. Для обміну даними між компонентами використано контекст React, який дозволяє централізовано зберігати сесію користувача, параметри профілю, статус авторизації та інші важливі дані. Уся бізнес-логіка реалізована на стороні сервера за допомогою Node.js у зв’язці з Express.js. Сервер виконує функції обробки HTTP- запитів, маршрутизації, перевірки автентичності, формування відповідей та доступу до бази даних. REST API, реалізований на основі Express, забезпечує повну взаємодію з фронтендом, а також дозволяє інтегрувати зовнішні сервіси за потреби. Для захисту даних і реалізації автентифікації застосовано JWT (JSON Web Token), що дає змогу ідентифікувати користувача при кожному запиті та підтримувати захищені сесії. У MongoDB зберігаються всі користувацькі та службові дані, включаючи інформацію про користувачів, страви, харчові обмеження, історію споживання, оцінки, звернення, збережені раціони та налаштування. Для роботи з MongoDB використано бібліотеку Mongoose, яка дозволяє описати схеми, створити індекси, забезпечити валідацію і встановити зв’язки між сутностями у форматі документів. 37 4.1.2 Візуальний інтерфейс користувача Візуальний інтерфейс користувача, реалізований у клієнтській частині застосунку, створено з урахуванням принципів сучасного UI/UX-дизайну. Стиль інтерфейсу користувача у вебзастосунку для складання та моніторингу раціону харчування витриманий у сучасній мінімалістичній естетиці з акцентом на зручність, візуальну чистоту та емоційне залучення. Візуальна композиція поєднує елементи soft UI (м’які контури, світлі напівпрозорі блоки, плавні тіні) з натуральним фоновим оформленням, що створює атмосферу затишку й турботи про здоров’я. Основним фоновим елементом є якісне фотореалістичне зображення страви та природи, яке стилістично відповідне тематиці харчування та фітнесу. Зображення затемнене, що дозволяє візуально виокремити інтерактивні блоки, не перевантажуючи користувача інформацією. Прозорі панелі поверх фону створюють ефект глибини та організованого простору. Кольорова палітра побудована на контрасті темного фону та яскравих акцентів – жовтого, зеленого або білого для кнопок, форм та заголовків. Шрифти інтерфейсу – без засічок, сучасні, з високою читабельністю, розміри тексту збалансовані: великі заголовки, середній розмір основного тексту, дрібні підписи. Весь інтерфейс повністю адаптивний – елементи автоматично перебудовуються під різні розміри екранів, зберігаючи логіку інтерфейсу на смартфонах, планшетах і десктопах. Вкладки, блоки перегляду, діаграми та форми з’являються з легкими анімаціями або переходами, що покращує UX і робить взаємодію приємною та «живою». 4.1.3 Характеристики апаратно-програмної платформи На стороні клієнта потрібен сучасний браузер з підтримкою ES6 (Google Chrome, Mozilla Firefox, Microsoft Edge), 2 ГБ оперативної пам’яті, процесор з тактовою частотою не менше ніж 1.5 ГГц. 38 Для серверної частини потрібна система з Node.js версії не нижче 18.x, оперативна пам’ять від 2 до 4 ГБ, підтримка TCP-портів (особливо 3000, 5000 або кастомні) та підключення до MongoDB через локальний або віддалений інтерфейс. У якості системи керування базами даних використовується MongoDB версії 6.0 або вище. Розробка здійснюється у середовищі Visual Studio Code, контроль версій реалізовано через Git, для керування залежностями використовується npm. Уся система взаємодіє через захищені HTTP-запити з використанням SSL/TLS (HTTPS). У разі розгортання в продуктивному середовищі застосунок може бути інтегровано з хмарною інфраструктурою (наприклад, Vercel для фронтенду, Render або Heroku для бекенду, MongoDB Atlas для бази даних), що дозволяє забезпечити високу доступність, автоматичне масштабування та надійність роботи вебзастосунку незалежно від навантаження. 4.2 Тестування програмного забезпечення Метою навантажувального тестування було визначення стабільності та ефективності роботи веб-застосунку, створеного в межах дипломного проекту, при обробці значної кількості запитів. Тестування проводилось з метою виявлення можливих вузьких місць у роботі серверної частини системи. Для навантажувального тестування було використано наступний інструмент: Artillery – open-source фреймворк для тестування продуктивності веб-застосунків, який дозволяє створювати сценарії з багатьма віртуальними користувачами та аналізувати результати тесту. На рисунку (див. рис. 4.1) наведено приклад конфігураційного YAML-файлу (test.yml), який описує сценарій тестування процесу авторизації користувача. Сценарій запускає 25 нових користувачів щосекунди протягом 60 секунд, що еквівалентно 1500 запитам авторизації. 39 Рисунок 4.1 – Сценарій тестування процесу На рисунку (див. рис. 4.2) видно що усі 1500 віртуальних користувачів успішно виконали авторизацію без жодної помилки. Середній час відповіді сервера склав 150.3 мс, що є дуже хорошим показником для REST API. Значення p95 = 159.2 мс свідчить про те, що 95% усіх відповідей були швидшими за цей час. Навіть під піковим навантаженням у 20 користувачів на секунду сервер залишався стабільним, обробляючи всі запити в межах прийнятного часу. Рисунок 4.2 – Результат тестування 40 Навантажувальне тестування показало, що серверна частина вебзастосунку є надійною, швидкою та готовою до використання в умовах реального середовища з помірним навантаженням. Відсутність помилок та відмов під час тестування свідчить про високу якість реалізації логіки автентифікації. 4.3 Оцінка досягнення мети дипломної роботи Основною метою було створення функціонального, доступного, персоналізованого інструменту для складання та щоденного моніторингу раціону харчування з урахуванням індивідуальних особливостей людини. Реалізоване програмне забезпечення повністю покриває ці потреби. Система дозволяє проходити реєстрацію, вносити індивідуальні фізіологічні параметри, створювати персональний раціон, редагувати його, контролювати споживання, слідкувати за історією харчування та ваги. Результати тестування засвідчили стабільну роботу системи в різних середовищах, правильне виконання логіки авторизації, збереження, отримання й обробки даних. Було досягнуто необхідного рівня гнучкості інтерфейсу, масштабованості архітектури та логічної цілісності всіх функцій. Ключовий ефект, досягнутий у процесі реалізації – це створення інструменту, який може реально впливати на формування здорових харчових звичок, підвищувати усвідомленість користувача щодо споживаних продуктів і сприяти корекції способу життя. 4.3 Оцінка досягнення мети дипломної роботи Основною метою було створення функціонального, доступного, персоналізованого інструменту для складання та щоденного моніторингу раціону харчування з урахуванням індивідуальних особливостей людини. Реалізоване програмне забезпечення повністю покриває ці потреби. Система дозволяє проходити реєстрацію, вносити індивідуальні фізіологічні параметри, створювати персональний раціон, редагувати його, контролювати споживання, слідкувати за історією харчування та ваги. 41 Результати тестування засвідчили стабільну роботу системи в різних середовищах, правильне виконання логіки авторизації, збереження, отримання й обробки даних. Було досягнуто необхідного рівня гнучкості інтерфейсу, масштабованості архітектури та логічної цілісності всіх функцій. Ключовий ефект, досягнутий у процесі реалізації – це створення інструменту, який може реально впливати на формування здорових харчових звичок, підвищувати усвідомленість користувача щодо споживаних продуктів і сприяти корекції способу життя. 4.4 Шляхи вдосконалення та подальший розвиток системи Одним з пріоритетних напрямів вдосконалення є впровадження мобільної версії застосунку на базі React Native або Flutter, що дозволить користувачам вести щоденник харчування у зручному форматі без необхідності доступу до браузера. Іншим напрямом може бути реалізація інтеграції з популярними фітнес- трекерами та сервісами здоров’я, що надасть змогу автоматично синхронізувати дані про фізичну активність, витрачені калорії, пульс і сон. Зі сторони штучного інтелекту перспективним є впровадження персоналізованої системи рекомендацій на базі машинного навчання, яка з часом буде краще адаптуватися до вподобань користувача. Також можливо реалізувати чат-бота для консультування користувачів у реальному часі. 42 5 ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ 5.1. Обґрунтування доцільності розробки програмного забезпечення Розробка вебзастосунку для моніторингу раціону харчування Nutrition є доцільною з огляду на зростаючу потребу суспільства у підтримці здорового способу життя та контролі за власним харчуванням. У сучасних умовах люди часто стикаються з дефіцитом часу та інформації щодо збалансованого раціону, що призводить до порушення харчової поведінки та супутніх захворювань. Запропонований вебзастосунок забезпечить зручний інструмент для ведення обліку спожитих продуктів, розрахунку БЖВ (білки, жири, вуглеводи) та отримання персоналізованих рекомендацій. Це сприятиме формуванню здорових звичок, підвищенню обізнаності користувачів та ефективному контролю над власним харчуванням. 5.1.1. Актуальність розробки На сьогоднішній день все більше людей прагнуть дотримуватись збалансованого харчування, однак стикаються з труднощами у щоденному контролі за споживанням калорій, білків, жирів і вуглеводів. Ведення обліку вручну є незручним, займає багато часу та часто супроводжується неточностями через людський фактор. Автоматизація цього процесу через спеціалізований вебзастосунок дозволяє: 1) швидко розраховувати індивідуальні добові норми поживних речовин; 2) систематично відстежувати фактичне споживання їжі; 3) виявляти відхилення від оптимального режиму харчування; 4) формувати раціональні рекомендації для покращення харчових звичок. 5.1.2. Потенційні користувачі системи Потенційними користувачами вебзастосунку Nutrition є широкі верстви населення, що прагнуть контролювати своє здоров’я та харчування. Насамперед це: 43 1) індивідуальні користувачі, які хочуть слідкувати за власним харчуванням, покращити фігуру, підвищити рівень енергії або дотримуватись рекомендацій лікаря; 2) люди з хронічними захворюваннями, для яких контроль за раціоном є критично важливим (наприклад, діабет, серцево-судинні захворювання тощо). 3) спортсмени та активні користувачі, що слідкують за БЖВ та калорійністю харчування для досягнення фітнес-цілей; 4) дієтологи та фахівці з харчування, які можуть використовувати систему як інструмент для супроводу своїх клієнтів; 5) батьки, які прагнуть організувати здорове харчування дітей; 6) адміністратори або розробники, що забезпечують наповнення бази даних продуктів, рецептів та технічну підтримку системи. 5.2. Оцінка конкурентоспроможності програмного забезпечення 5.2.1. Аналіз існуючих аналогів На ринку існує ряд програмних продуктів, що дозволяють вести облік харчування, контролювати калорійність і аналізувати раціон. Однак вони мають певні обмеження порівняно з розробленим вебзастосунком Nutrition: Таблиця 5.1 – Порівняння існуючих аналогів Назва Основні функції Обмеження Переваги Nutrition аналогу Підрахунок калорій, Безкоштовний Частина функціоналу планування доступ до повного доступна лише в платній Yazio харчування, функціоналу, версії, обмежена фіксація фізичної локалізована база локалізація продуктів активності продуктів Сучасний Велика база даних інтерфейс, Застарілий інтерфейс, MyFitness продуктів, інтуїтивна реклама у безкоштовній Pal синхронізація з навігація, версії, складний пошук фітнес-додатками розширені фільтри для пошуку страв 44 Кінець таблиці 5.1 Назва Основні функції Обмеження Переваги Nutrition аналогу Гнучка персоналізація Ведення харчового Обмежені можливості раціону, адаптація FatSecret щоденника, БЖУ- налаштування до потреб аналіз, звіти індивідуальних цілей користувача (вік, вага, цілі) 5.2.2. Конкурентні переваги Nutrition 1) безкоштовний повнофункціональний доступ - усі основні можливості (розрахунок БЖВ, ведення щоденника, доступ до бази рецептів тощо) доступні без підписки або додаткової оплати; 2) локалізована база продуктів і рецептів - ,аза продуктів адаптована під українського користувача, містить традиційні страви та інгредієнти, а також підтримує українську мову; 3) інтуїтивно зрозумілий інтерфейс - cучасний дизайн з фокусом на простоту використання: зручна навігація, логічна структура та адаптивність під мобільні пристрої; 4) гнучка персоналізація - можливість налаштування індивідуальних цілей (схуднення, набір ваги, підтримка форми), враховуючи вік, стать, рівень активності та медичні обмеження. 5.3. Розрахунок витрат на розробку програмного забезпечення 5.3.1. Трудомісткість розробки Розробка системи Nutrition включає наступні основні етапи Таблиця 5.2 – Основні етапи розробки Nutrition Тривалість Етап Опис робіт Виконавець (днів) 1 Аналіз вимог та проектування 3 Розробник, Керівник 2 Розробка серверної частини 5 Розробник 3 Розробка клієнтської частини 4 Розробник 45 Кінець таблиці 5.2 Тривалість Етап Опис робіт Виконавець (днів) Розробка алгоритмів аналізу та 4 3 Розробник, Керівник класифікації 5 Інтеграція компонентів 2 Розробник Тестування та виправлення 6 2 Розробник, Керівник помилок 7 Документування 2 Розробник Загальна тривалість 21 5.3.2. Витрати на оплату праці Для розрахунку витрат на оплату праці використовуємо наступні ставки:  розробник: 500 грн/год  керівник проекту: 700 грн/год Розрахунок витрат на оплату праці: Таблиця 5.3 – Розрахунок витрат на оплату праці Учасник Кількість годин Ставка (грн/год) Сума (грн) Розробник 168 (21 д × 8 год) 500 84 000 Керівник 48 (6 д × 8 год)* 700 33 600 Загальна сума 117 600 5.3.3. Амортизаційні відрахування Для розробки системи використовується наступне обладнання: Таблиця 5.4 – Розрахунок витрат на обладнання Термін Річна Амортизація Вартість Обладнання служби амортизація за час (грн) (років) (грн) проєкту (грн) Ноутбук MacBook Pro 85 000 5 17 000 4 887 Монітор Dell UltraSharp 15 000 5 3 000 863 Сервер для тестування 40 000 5 8 000 2 301 Загальна сума 8 051 амортизації 46 Амортизація за час проекту = (Річна амортизація / 365) × Тривалість проекту (105 днів). 5.3.4. Інші витрати Таблиця 5.5 – Інші витрати Стаття витрат Сума (грн) Оренда офісного приміщення 35 000 Електроенергія та комунальні послуги 7 500 Інтернет та зв'язок 3 500 Ліцензійне програмне забезпечення 25 000 Витратні матеріали 5 000 Непередбачені витрати 15 000 5.3.5. Загальні витрати на розробку Таблиця 5.6 – Загальні витрати Стаття витрат Сума (грн) Витрати на оплату праці 117 600 Амортизаційні відрахування 1 610 Інші витрати 18 200 Загальна сума 137 410 5.4. Ціноутворення та економічний ефект 5.4.1. Методика ціноутворення Для визначення ціни на програмне забезпечення Nutrition використовується метод "витрати плюс прибуток", а також враховується ціна конкурентних рішень на ринку додатків для моніторингу харчування. З урахуванням аналізу конкурентів та витрат на розробку, пропонується наступна цінова модель: 47 Таблиця 5.7 – Пропонована цінова модель Тип ліцензії Опис Ціна (грн) Обмежений доступ до функцій (до 50 записів Базова 20 000 раціону), базовий аналіз калорій та БЖУ Необмежена кількість записів, розширений аналіз Професійна 40 000 раціону, індивідуальні рекомендації Необмежена кількість записів, API для інтеграції з Корпоративна 80 000 іншими сервісами, підтримка та консультації Також пропонується модель підписки: Таблиця 5.8 – Пропонована модель підписок Тип підписки Опис Ціна на місяць (грн) Обмежена кількість записів (до 50), Базова 2 000 базова аналітика Необмежена кількість записів, Професійна 4 000 розширений аналіз, рекомендації Необмежена кількість записів, API, Корпоративна 8 000 підтримка 5.4.2. Розрахунок економічного ефекту Економічний ефект від впровадження системи Nutrition може бути розрахований на основі: Економії часу на ведення та аналіз раціону харчування  без системи: в середньому 10 годин на тиждень;  з системою: в середньому 5 години на тиждень;  економія: 8 годин на тиждень або 416 годин на рік;  при середній погодинній ставці дієтолога 200 грн/год, економія становить 83 200 грн на рік на одного користувача. Підвищення ефективності контролю за харчуванням:  Середня вартість неправильного харчування та пов’язаних проблем зі здоров’ям: 10 000 грн на рік;  Очікуване покращення завдяки моніторингу: 20%;  Економічний ефект: 2 000 грн на рік. 48 Зниження витрат на додаткове медичне лікування:  середні витрати на лікування через незбалансоване харчування: 15 000 грн на рік;  очікуване зниження ризику: 15%;  економічний ефект: 2 000 грн на рік. Загальний очікуваний економічний ефект від впровадження системи Nutrition: 83 200 + 2 000 + 2 250 = 87 000 грн на рік 5.4.3. Розрахунок терміну окупності Термін окупності розробки системи Nutrition можна розрахувати на основі прогнозованих продажів: Таблиця 5.9 – Окупність розробки системи Кількість проданих Середня ціна Сукупний дохід Дохід (грн) ліцензій ліцензії (грн) (грн) 200 2 000 400 000 400 000 300 2 000 600 000 1 000 000 400 2 000 800 000 1 800 000 Витрати на розробку: 631 051 грн Термін окупності = Витрати на розробку / (Сукупний дохід за перший рік) Термін окупності = 631 051 / 400 000 = 1,58 року. З урахуванням додаткових витрат на маркетинг та підтримку (приблизно 150 000 грн на рік), термін окупності становитиме близько 1,8 року, що є прийнятним показником для програмних продуктів такого типу. 49 5.5. Розрахунок витрат на впровадження програмного забезпечення 5.5.1. Аналіз вимог до технічного забезпечення Для ефективного функціонування системи MarketRule в організаціях та на підприємствах необхідно забезпечити відповідне технічне середовище. Система MarketRule має наступні технічні вимоги для впровадження: Серверна частина:  веб-сервер з підтримкою Node.js 14.0 або вище;  процесор: не менше 4 ядер, частота від 2.5 ГГц;  оперативна пам'ять: від 8 ГБ;  дисковий простір: від 100 ГБ SSD;  операційна система: Linux (Ubuntu 20.04 або новіше) або Windows Server 2019+;  пропускна здатність мережі: не менше 100 Мбіт/с. Клієнтська частина:  сучасний веб-браузер (Chrome 90+, Firefox 88+, Safari 14+, Edge 90+);  процесор: не менше 2 ядер, частота від 2.0 ГГц;  оперативна пам'ять: від 4 ГБ;  дисковий простір: від 10 ГБ вільного місця;  роздільна здатність екрану: не менше 1366x768. Програмне забезпечення:  MongoDB (версія 4.4 або вище);  Node.js (версія 14.0 або вище);  npm (версія 6.0 або вище);  PM2 для управління процесами (опціонально);  Nginx або Apache (опціонально). 5.5.2. Витрати на технічне забезпечення Розрахуємо витрати на технічне забезпечення для типової компанії середнього розміру з 5 робочими місцями: 50 Таблиця 5.10 – Витрати на технічне забеспечення Ціна за одиницю Найменування Кількість Сума (грн) (грн) Сервер (Dell PowerEdge R340) 1 85 000 85 000 ПК для робочих місць (HP ProDesk 400) 5 25 000 125 000 Монітори 24" 5 6 000 30 000 Мережеве обладнання (комутатор, 1 15 000 15 000 маршрутизатор) ДБЖ для сервера 1 12 000 12 000 ДБЖ для робочих станцій 5 3 000 15 000 Загальна сума 282 000 В умовах малого бізнесу або використання хмарної інфраструктури (наприклад, AWS/Azure) ці витрати можуть бути суттєво нижчими. 5.5.3. Витрати на програмне забезпечення Для функціонування системи Nutrition потрібне додаткове програмне забезпечення: Таблиця 5.11 – Витрати на ПЗ Кількість Ціна за ліцензію Найменування Сума (грн) ліцензій (грн) Windows Server 2019 1 35 000 35 000 Standard MongoDB Atlas 1 18 000 18 000 (підписка на рік) Антивірусне ПЗ 6 2 500 15 000 Інше системне ПЗ 6 3 000 18 000 Загальна сума 86 000 5.5.4. Витрати на навчання персоналу Важливою складовою впровадження є навчання персоналу роботі з системою: Таблиця 5.12 – Витрати на навчання персоналу Вид навчання Кількість осіб Навчання адміністраторів 1 51 Навчання користувачів 5 Технічна документація – Загальна сума 5.5.5. Загальні витрати на впровадження Таблиця 5.13 – Витрати на впровадження Стаття витрат Сума (грн) Витрати на технічне забезпечення 282 000 Витрати на програмне забезпечення 86 000 Витрати на навчання персоналу 40 000 Витрати на встановлення та налаштування системи 25 000 Витрати на міграцію даних 15 000 Загальна сума 448 000 Витрати на впровадження системи Nutrition можуть значно відрізнятися залежно від технічних ресурсів користувача та обраного способу доступу до системи. Для користувачів, які вже мають доступ до інтернету та пристроїв з веб- браузером, витрати на впровадження можуть обмежитися лише початковими витратами на розробку, розгортання системи на хостингу та організацію технічної підтримки. Додатковими витратами можуть стати заходи з популяризації та інструктажу кінцевих користувачів. 5.6. Розрахунок витрат на придбання та впровадження програмного продукту-аналога Як аналог системи Nutrition розглядається програмний продукт MyFitnessPal Premium, який є популярним сервісом для відстеження харчування, БЖУ та калорійності, доступним як для індивідуальних користувачів, так і для бізнесу 5.6.1. Вартість придбання ліцензій MyFitnessPal Сервіс MyFitnessPal (https://www.myfitnesspal.com) пропонує преміум- функціональність за моделлю підписки. Доступні наступні тарифи: Таблиця 5.14 – Вартість підписок MyFitnessPal Premiumв Місячна вартість Річна вартість Річна вартість Тарифний план (USD) (USD) (грн) при курсі 38 52 грн/USD Простий 9.99 79.99 3 040 Бізнес 14.99 749.9 28 495 Для умовного впровадження системи на 5 користувачів (наприклад, у фітнес- центрі або в компанії з фокусом на здоров’я персоналу) розглядається бізнес-тариф: 5 × 28 495 = 142 475 грн на рік 5.6.2. Витрати на впровадження MyFitnessPal Оскільки MyFitnessPal є вебзастосунком, витрати на впровадження будуть включати технічну реалізацію, базовий маркетинг, налаштування хостингу та підтримку. Таблиця 5.15 – Витрати на впровадження MyFitnessPal Стаття витрат Сума (грн) Технічне забезпечення (ПК для робочих місць) 125 000 Навчання персоналу 50 000 5.6.3. Загальні витрати на придбання та впровадження MyFitnessPal Таблиця 5.16 – Загальні витрати MyFitnessPal Стаття витрат Сума (грн) Вартість ліцензій на рік 142 475 Витрати на впровадження 205 000 Загальна сума 347 475 5.7. Розрахунок експлуатаційних витрат програмного забезпечення 5.7.1. Визначення тривалості корисного використання Для розрахунку експлуатаційних витрат необхідно визначити тривалість корисного використання програмного забезпечення Nutrition. 53 Припустимо, що система Nutrition буде використовуватися 5 співробітниками компанії, які супроводжують користувачів або працюють із аналітикою:  2 дієтологи (по 4 години на день);  2 аналітики (по 3 години на день);  1 адміністратор платформи (1 година на день). Розрахуємо річний фонд робочого часу:  кількість днів у році: 365;  вихідні дні (52 тижні × 2 дні): 104;  святкові дні: 12;  робочі дні: 365 - 104 - 12 = 249 днів. Річний фонд часу використання системи Nutrition:  дієтологи: 2 × 4 год × 249 днів = 1 992 години;  аналітики: 2 × 3 год × 249 днів = 1 494 години;  адміністратор: 1 × 1 год × 249 днів = 249 годин;  загальний річний фонд: 1 992 + 1 494 + 249 = 3 735 годин. При 8-годинному робочому дні це еквівалентно 3 735 / 8 = 466,9 повних робочих днів використання системи за рік. 5.7.2. Розрахунок експлуатаційних витрат Nutrition Таблиця 5.17 – Розрахунок експлуатаційних витрат Nutrition Стаття витрат Річні витрати (грн) Технічна підтримка та оновлення (20% від вартості 8 000 ліцензії) Витрати на електроенергію (сервер та робочі станції) 15 000 Витрати на обслуговування обладнання 12 000 Витрати на адміністрування системи (0.2 ставки 72 000 системного адміністратора) Витрати на резервне копіювання та відновлення даних 10 000 Витрати на інтернет-підключення 18 000 Загальна сума 135 000 54 5.7.3. Розрахунок експлуатаційних витрат MyFitnessPal Таблиця 5.18 – Розрахунок експлуатаційних витрат MyFitnessPal Стаття витрат Річні витрати (грн) Щорічне продовження підписки 378 100 Витрати на електроенергію (робочі станції) 12 000 Витрати на обслуговування обладнання 10 000 Витрати на інтернет-підключення 18 000 Загальна сума 418 100 5.7.4. Порівняння експлуатаційних витрат Таблиця 5.19 – Порівняння витрати Система Річні експлуатаційні витрати (грн) Nutrition 135 000 MyFitnessPal 418 100 Різниця 283 100 Аналіз показує, що річні експлуатаційні витрати при використанні системи Nutrition на 283 100 грн менші, ніж при використанні MyFitnessPal, що становить суттєву економію для підприємства. 5.8. Оцінка ефекту та ефективності програмного забезпечення 5.8.1. Розрахунок економічного ефекту Економічний ефект від впровадження системи Nutrition може бути розрахований на основі: Економія часу на розрахунок раціону та аналітику:  без системи: в середньому 20 годин на тиждень (ручні Excel/таблиці);  з системою: в середньому 5 годин на тиждень;  економія: 15 годин на тиждень або 780 годин на рік;  за середньої ставки дієтолога 250 грн/год, економія становить 195 000 грн на рік. Підвищення ефективності харчових рекомендацій: 55  середній бюджет програми харчування: 500 000 грн на рік  очікуване підвищення ефективності: 15%  економічний ефект: 75 000 грн на рік Зниження ризиків від неправильного харчування:  середні втрати від неефективних рішень: 200 000 грн на рік  очікуване зниження ризиків: 20%  економічний ефект: 40 000 грн на рік Економія на експлуатаційних витратах порівняно з аналогом:  різниця в експлуатаційних витратах: 283 100 грн на рік Загальний очікуваний економічний ефект від впровадження системи Nutrition: 195 000 + 75 000 + 40 000 + 283 100 = 593 100 грн на рік 5.8.2. Розрахунок економічної ефективності Коефіцієнт економічної ефективності розраховується як відношення річного економічного ефекту до загальних витрат на розробку та впровадження системи: E = Ерічний / (Врозробка + Ввпровадження) E = 593 100 / (631 051 + 448 000) = 593 100 / 1 079 051 = 0,55 Нормативний коефіцієнт ефективності для програмних продуктів становить 0,33. Оскільки розрахований коефіцієнт (0,55) перевищує нормативний, проект можна вважати економічно ефективним. 5.8.3. Розрахунок терміну окупності Термін окупності розраховується як відношення загальних витрат до річного економічного ефекту: Ток = (Врозробка + Ввпровадження) / Ерічний Ток = 1 079 051 / 593 100 = 1,82 року 56 Або приблизно 1 рік і 10 місяців. Термін окупності 1,82 року є прийнятним для інвестицій у програмне забезпечення такого типу. 57 ВИСНОВКИ У результаті виконання даної дипломної роботи було повністю реалізовано поставлену мету – створено функціональний вебзастосунок для складання та моніторингу раціону харчування, що враховує індивідуальні фізіологічні параметри користувача та дозволяє формувати персоналізоване меню, оцінювати калорійність страв. Система підтримує реєстрацію користувачів, збереження облікових даних, обробку щоденних записів про прийоми їжі, вагу, фізичну активність та використання добавок. Візуальний інтерфейс реалізовано з урахуванням сучасних вимог до UX/UI- дизайну – він є інтуїтивним, адаптивним, мінімалістичним, з акцентами на ключових функціях. Для зберігання й обробки даних використано MongoDB, серверну логіку реалізовано на Node.js з використанням Express, а клієнтську частину – за допомогою React. Розроблений застосунок відповідає актуальним запитам суспільства на здоровий спосіб життя та контроль власного харчування. Його впровадження дозволяє користувачам автоматизувати щоденні процеси планування харчування, підвищити інформованість щодо власних харчових звичок, сформувати стабільний раціон відповідно до добових норм. Розроблена система має соціальну цінність, що полягає у підвищенні рівня обізнаності населення щодо свого здоров’я, профілактиці метаболічних і серцево-судинних захворювань, а також формуванні культури відповідального ставлення до споживання їжі. Розроблений програмний продукт може бути використаний індивідуальними користувачами та адаптований для впровадження в закладах охорони здоров’я, фітнес-центрах, школах здорового харчування, компаніях, що займаються персоналізованим консалтингом. 58 СПИСОК ДЖЕРЕЛ ІНФОРМАЦІЇ 1 Прикладні комп’ютерні технології [Електронний ресурс] : зб. наук. ст. студентів / відп. ред. А. В. Селіванова. – Київ : Держ. торг.-екон. ун-т, 2023. – 141 с. 2 Прикладні інформаційні системи та технології в цифровому суспільстві: зб. тез доповідей і наук. повідомл. учасників VIII Міжнародної науково-практичної конференції (Київ, 01 жовтня 2025 р.) / за заг. ред. В. Плескач, О. Фендьо. К.: Київський нац. Ун ім. Тараса Шевченка, 2024. 3 Порівнюємо React, Angular і Vue – найпопулярніші бібліотеки й фреймворки у 2022 році. URL: https://dou.ua/forums/topic/39933/ (дата звернення: 28.03.2025). 4 Розробка Backend додатків на Node JS. URL: https://brander.ua/what-we- offer/application-development/rozrobka-backend-dodatkiv-na-node-js (дата звернення: 28.03.2025). 5 Що таке MongoDB Compass? URL: https://javascript.org.ua/posibnik-dlya- pochatkivcziv-po-zapitah-do-mongodb-za-dopomogoyu-compass-ovolodinnya-zapitami- mongodb-ta-rozuminnya-vidminnostej-iz-sql/ (дата звернення: 28.03.2025). 6 Уніфікована мова моделювання (Unified Modeling Language - UML). URL: https://www.maxzosim.com/unifikovana-mova-modeluvannia/ (дата звернення: 28.03.2024). 7 Лавріщева К.М. ПРОГРАМНА ІНЖЕНЕРІЯ.–К.– 2008.–319 с. ISBN 978– 966–02–5052–9. 8 Програмне забезпечення комп’ютера. URL: https://www.miyklas.com.ua/p/informatica/9-klas/programne-zabezpechennia-ta- informatciina-bezpeka-327110/programne-zabezpechennia-komp-iutera-327111/re- ea6711e4-d7e6-4f1e-9fe8-a1a4b20c4f44 (дата звернення: 30.03.2025). 9 Функціональні та нефункціональні вимоги. URL: https://visuresolutions.com/uk/посібник-з-відстеження-управління- вимогами/функціональні-та-нефункціональні-вимоги/ (дата звернення: 30.03.2025). 59 10 Модель життєвого циклу програмного проекту. URL: mmsa.kpi.ua/sites/default/files/disciplines/Розробка%20і%20тестування%20програм/di dkovska_m_v_testing_lecture_1.pdf (дата звернення: 02.04.2025). 11 Моделі життєвого циклу, принципи і методології розробки програмного забезпечення (ПЗ). URL: https://evergreens.com.ua/ua/articles/software-development- metodologies.html (дата звернення: 02.04.2025). 12 Каскадна модель (waterfall model). URL: https://qalight.ua/baza- znaniy/kaskadna-model-waterfall-model/ (дата звернення: 02.04.2025). 13 Інкрементальна модель життєвого циклу розробки програмного забезпечення. URL: https://newline.tech/inkrementalna-model-zhittyevogo-ciklu- rozrobki-programnogo-zabezpechennya-uk/ (дата звернення: 02.04.2025). 14 Agile як невід’ємна частина успішних проєктів. URL: https://foxminded.ua/shcho-take-agile/ (дата звернення: 02.04.2025). 15 Yazio. URL: https://www.yazio.com/en (дата звернення: 02.04.2025). 16 MyFitnessPal. URL: https://www.yazio.com/en (дата звернення: 02.04.2025). 17 FatSecret. URL: https://www.fatsecret.com/ (дата звернення: 02.04.2025). 18 Управління бізнес-процесами: Навчально-методичний комплекс дисципліни [Електронний ресурс]: навчальний посібник для студентів спеціальності 073 «Менеджмент» / КПІ ім. Ігоря Сікорського; уклад.: Т.А. Коцко. – Електронні текстові дані (1 файл: 13,1 мб). – Київ: КПІ ім. Ігоря Сікорського, 2021. – 79 с. 19 Що таке Single Page Application? URL: https://asabix.com.ua/what-is-a-single- page-application/ (дата звернення: 02.04.2025). 20 Трирівнева архітектура. URL: https://javarush.com/ua/quests/lectures/ua.questservlets.level14.lecture01 (дата звернення: 02.04.2025). 21 MongoDB Documentation. URL: https://www.mongodb.com/docs/ (дата звернення: 02.04.2025). 22 Express. URL: https://devdocs.io/express/ (дата звернення: 02.04.2025). 23 React.js. URL: https://uk.legacy.reactjs.org/docs/getting-started.html (дата звернення: 02.04.2025). 60 24 Node.js documentation. URL: https://nodejs.org/docs/latest/api/ (дата звернення: 02.04.2025). 25 Як використовувати JSON Web Tokens (JWT) для автентифікації. URL: https://devzone.org.ua/post/iak-vykorystovuvaty-json-web-tokens-jwt-dlia- avtentyfikatsiyi(дата звернення: 02.04.2025).