ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/6033| Title: | Веб-орієнтована інформаційна система для управління завданнями при розробці IT-продуктів |
| Authors: | Дяченко, Петро Васильович Волошина, Вікторія Олександрівна |
| Keywords: | УПРАВЛІННЯ ЗАВДАННЯМИ,;ІНФОРМАЦІЙНА СИСТЕМА,;ВЕБ-ОРІЄНТОВАНА СИСТЕМА,;ВЕБ-РОЗРОБКА,;IT-ПРОДУКТ,;ПЛАНУВАННЯ ПРОЄКТІВ,;ІНТЕРФЕЙС КОРИСТУВАЧА,;BACKEND. |
| Issue Date: | 11-Jun-2025 |
| Abstract: | Сучасний світ характеризується стрімким розвитком інформаційних технологій та постійним зростанням конкуренції на ринку. Це, у свою чергу, зумовлює високі вимоги до ефективності управління процесами розробки програмних продуктів. Розробка IT-продуктів є складним, багатоетапним процесом, що включає діяльність фахівців різних профілів: UX/UI дизайнерів, frontend- та backend- розробників, DevOps-інженерів, тестувальників та інших. Успішне завершення таких проєктів значною мірою залежить від злагодженої роботи команди, чіткого розподілу завдань та ефективного контролю за їх виконанням. Метою роботи є проєктування та розробка веб-орієнтованої інформаційної системи для управління завданнями, яка допоможе покращити ефективність роботи у команді при розробці IT-продуктів, надаючи зручну та налаштовувану платформу для організації завдань. Система має бути зручною у використанні, допомагати розподіляти завдання та налагоджувати взаємодію між учасниками. Вона має вирішувати ті проблеми, які притаманні іншим подібним платформам. Роботу було апробовано на Днях студентської науки ЧДТУ-2025, м. Черкаси, за результатами якої було отримано диплом за І місце по секції «Комп’ютерні науки та системний аналіз». |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6033 |
| Appears in Collections: | 122 Комп’ютерні науки (Комп’ютерні науки та прикладне програмування) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Волошина Вікторія_КН-2101_2024-2025.pdf Restricted Access | 6.22 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
бакалавра
на тему: «Веб-орієнтована інформаційна система для управління завданнями
при розробці IT-продуктів»
Виконала: студентка 4 курсу, групи КН-2101
спеціальності 122 «Комп’ютерні науки»
(шифр і назва спеціальності)
Освітня програма «Комп’ютерні науки та
(назва освітньої програми)
прикладне програмування»
Волошина Вікторія Олександрівна
Керівник Дяченко П.В.
(прізвище та ініціали)
Рецензент _____________ ____________
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Бакалавр
Спеціальність 122 – комп’ютерні науки
Освітня програма Комп’ютерні науки та прикладне програмування
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 20__ р.
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Волошиній Вікторії Олександрівні
(прізвище, ім‘я, по батькові)
1. Тема роботи
«Веб-орієнтована інформаційна система для управління завданнями при розробці IT-продуктів»
Керівник роботи Дяченко П.В., к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «25» лютого 2025 р. №53/03-03.
2. Строк подання студентом роботи «___» ________ 20___ року
3. Вихідні дані до роботи:
Технічне завдання на розробку веб-орієнтованої інформаційної системи для управління
завданнями при розробці IT-продуктів; методичні рекомендації з виконання кваліфікаційної
роботи бакалавра; технологічна документація щодо використання технологій HTML, CSS
JavaScript, Node.js, MySQL; аналітичні матеріали щодо функціональності існуючих систем
управління завданнями (Trello, Asana, ClickUp, Monday.com, Todoist).
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Аналіз предметної області та обгрунтування вибору напряму дослідження
4.2. Проєктування веб-орієнтованої інформаційної системи
4.3. Розробка веб-орієнтованої інформаційної системи
Висновки.
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація
1. Інструкція користувача
5.2. Додаток Б. Текст програми
5.3. Додаток В. Інструкція користувачеві
5.4 Додаток Г. Графічні матеріали
5.5 Додаток Д. Тези доповідей студентської науково-практичної конференції ЧДТУ
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
завдання видав завдання прийняв
консультанта
7. Дата видачі завдання 25.02.2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ з/п Назва етапів кваліфікаційної роботи бакалавра Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу
до 28.02.2025 виконано
бакалавра.
2 Аналіз літературних джерел, об’єкту та предмету
до 17.03.2025 виконано
дослідження.
3 Написання теоретичного розділу кваліфікаційної
до 01.04.2025 виконано
роботи бакалавра.
4 Написання аналітичного розділу (аналіз об’єкту
до 15.04. 2025 виконано
й предмету дослідження).
5 Написання практичних розділів й висновків по
до 12.05.2025 виконано
роботі.
6 Передзахист кваліфікаційної роботи бакалавра
до 26.05.2025 виконано
на засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри. до 02.06. 2025 виконано
8 Захист кваліфікаційної роботи бакалавра. 11.06.2025 виконано
Студент _____________________________ Вікторія ВОЛОШИНА
(підпис)
Керівник роботи ____________________________ Петро ДЯЧЕНКО
(підпис)
РЕФЕРАТ
Кваліфікаційна робота бакалавра містить: 170 с., 72 рис., 18 таблиць, 18
використаних джерел, 5 додатків.
Актуальність теми. Сучасний світ характеризується стрімким розвитком
інформаційних технологій та постійним зростанням конкуренції на ринку. Це, у свою
чергу, зумовлює високі вимоги до ефективності управління процесами розробки
програмних продуктів. Розробка IT-продуктів є складним, багатоетапним процесом, що
включає діяльність фахівців різних профілів: UX/UI дизайнерів, frontend- та backend-
розробників, DevOps-інженерів, тестувальників та інших. Успішне завершення таких
проєктів значною мірою залежить від злагодженої роботи команди, чіткого розподілу
завдань та ефективного контролю за їх виконанням.
Традиційні методи управління завданнями, що базуються на використанні
електронних таблиць, електронної пошти або навіть усних домовленостей, виявляються
неефективними в умовах зростаючої складності проєктів та збільшення кількості
учасників команди. Такі підходи призводять до:
втрати важливих деталей завдань, обговорень та рішень, які можуть бути
загублені;
складнощів у відстеженні поточного статусу завдань та загального прогресу
проєкту;
неузгодженості дій у команді через відсутність єдиної платформи для
роботи та обміну інформацією;
витрат часу на ручне відстеження та координацію замість безпосереднього
виконання завдань.
У цьому контексті веб-орієнтовані інформаційні системи для управління
завданнями стають важливим інструментом для організації роботи. Такі системи
охоплюють весь процес управління завданнями та проєктами – від формування ідеї та
постановки завдань до їх виконання й контролю результатів. Вони підтримують
постійну комунікацію між учасниками команди, допомагають ефективно розподіляти
ресурси, відстежувати прогрес у реальному часі та швидко реагувати на зміни у
планах або проблеми, що виникають під час розробки.
Проте багато існуючих платформ не повністю відповідають потребам
користувачів. Вони часто є дороговартісними, надмірно складними для невеликих та
середніх команд; не забезпечують адаптивності до конкретних робочих процесів,
зручності інтерфейсу та гнучкості в налаштуванні. Це дослідження спрямоване на
подолання зазначених обмежень шляхом розробки веб-орієнтованої інформаційної
системи для управління завданнями, яка поєднує простий та зручний інтерфейс із
необхідними функціональними можливостями для організації командної роботи.
Метою роботи є проєктування та розробка веб-орієнтованої інформаційної
системи для управління завданнями, яка допоможе покращити ефективність роботи у
команді при розробці IT-продуктів, надаючи зручну та налаштовувану платформу для
організації завдань. Система має бути зручною у використанні, допомагати
розподіляти завдання та налагоджувати взаємодію між учасниками. Вона має
вирішувати ті проблеми, які притаманні іншим подібним платформам.
Завдання кваліфікаційної роботи бакалавра:
провести аналіз сучасних інструментів управління завданнями для виявлення
основних обмежень та потреб користувачів;
визначити функціональні та нефункціональні вимоги до веб-орієнтованої
інформаційної системи для управління завданнями, ґрунтуючись на досвіді
користувачів та найкращих практиках галузі;
розробити та реалізувати прототип веб-орієнтованої інформаційної системи
для управління завданнями з акцентом на зручність використання, продуктивність і
адаптивність;
оцінити ефективність та зручність розробленої веб-орієнтованої
інформаційної системи шляхом функціонального тестування, тестування зручності
використання та продуктивності.
Об’єкт дослідження: процес управління завданнями у командах розробки IT-
продуктів.
Предмет дослідження: веб-орієнтована інформаційна система для управління
завданнями при розробці IT-продуктів.
Методи дослідження: огляд науково-технічної літератури для аналізу поточного
стану інструментів для управління завданнями; порівняльний аналіз існуючих систем
управління завданнями для виявлення їх особливостей та недоліків; збір вимог шляхом
аналізу наявних систем та аналогічних рішень, а також спостереження за тим, як
користувачі взаємодіють з існуючими системами; розробка прототипу веб-орієнтованої
інформаційної системи для управління завданнями з використанням сучасних
технологій веб-розробки; тестування зручності використання прототипу для оцінки його
функціональності та продуктивності.
Апробація результатів роботи. Роботу було апробовано на Днях студентської
науки ЧДТУ-2025, м. Черкаси, за результатами якої було отримано диплом за І місце
по секції «Комп’ютерні науки та системний аналіз».
Публікації. Результати кваліфікаційної роботи бакалавра опубліковано у:
1) збірнику тез доповідей ІІІ Міжнародної науково-практичної інтернет-
конференції: Дяченко П. В., Волошина В. О. Розробка веб-сайту для
управління завданнями [Електронний ресурс] // Збірник тез доповідей ІІІ
Міжнар. наук.-практ. інтернет-конф. «Інновації та перспективні шляхи
розвитку інформаційних технологій» (ІПШРІТ-2024), 22 листопада 2024 р.,
м. Черкаси / упоряд. : Т. О. Прокопенко, О. І. Підкуйко ; М-во освіти і науки
України, Черкас. держ. технол. ун-т. – Черкаси : ЧДТУ, 2024. – С. 82–85.
2) збірнику тез доповідей студентської науково-практичної конференції
ЧДТУ:
Волошина В.О., Дяченко П.В. WEB-орієнтована інформаційна система для
управління завданнями при розробці IT-продуктів [Електронний ресурс]:
Збірник тез доповідей студентської науково-практичної конференції ЧДТУ:
22–24 квітня 2025 р., м. Черкаси / [упоряд. : Єгорова О.В., Захарова О.В.,
7
Тичков В.В. та ін.] ; Міністерство освіти і науки України, Черкаський
державний технологічний університет. – Черкаси : ЧДТУ, 2025. – С. 18.
Ключові слова: УПРАВЛІННЯ ЗАВДАННЯМИ, ІНФОРМАЦІЙНА СИСТЕМА,
ВЕБ-ОРІЄНТОВАНА СИСТЕМА, ВЕБ-РОЗРОБКА, КОМАНДНА РОБОТА, IT-
ПРОДУКТ, ПЛАНУВАННЯ ПРОЄКТІВ, ІНТЕРФЕЙС КОРИСТУВАЧА, HTML, CSS,
JAVASCRIPT, NODE.JS, MYSQL, FRONTEND, BACKEND.
ABSTRACT
The qualification work of bachelor contains: 170 pages, 72 figures, 18 tables, 18
sources used, 5 attachments.
Actuality of theme. The modern world is characterised by the rapid development of
information technology and the constant growth of competition in the market. This, in turn,
places high demands on the efficiency of managing software development processes. The
development of IT products is a complex, multi-stage process that involves the work of
specialists in various fields: UX/UI designers, frontend and backend developers, DevOps
engineers, testers, and others. The successful completion of such projects largely depends on
the well-coordinated work of the team, clear distribution of tasks, and effective control over
their implementation.
Traditional methods of task management based on spreadsheets, emails, or even verbal
agreements are proving ineffective as projects grow in complexity and the number of team
members increases. Such approaches lead to:
loss of important details of tasks, discussions, and decisions that may be lost;
difficulties in tracking the current status of tasks and overall project progress;
inconsistency in team activities due to the lack of a single platform for working
and sharing information;
time spent on manual tracking and coordination instead of actually performing
tasks.
In this context, web-based task management information systems are becoming an
important tool for organizing work. Such systems cover the entire process of task and project
management - from idea generation and task setting to their implementation and monitoring of
results. They support constant communication between team members, help to effectively
allocate resources, track progress in real time, and respond quickly to changes in plans or
problems that arise during development.
However, many existing platforms do not fully meet the needs of users. They are often
expensive, overly complex for small and medium-sized teams; they do not provide adaptability
to specific workflows, user-friendly interface, and flexibility in configuration. This study
aims to overcome these limitations by developing a web-based information system for task
management that combines a simple and user-friendly interface with the necessary
functionalities for organizing teamwork.
The purpose of the work is to design and develop a web-based information system
for task management, which will help improve the efficiency of teamwork in the
development of IT products, providing a convenient and customizable platform for
organizing tasks. The system should be easy to use, help distribute tasks and establish
interaction between participants. It should solve the problems inherent in other similar
platforms.
Objectives of bachelor’s qualifying work:
conduct an analysis of modern task management tools to identify key limitations
and user needs;
define the functional and non-functional requirements for a web-based task management
information system based on user experience and industry best practices;
develop and implement a prototype of a web-based task management information
system with a focus on usability, performance and adaptability;
evaluate the effectiveness and usability of the developed web-based information
system through functional testing, usability testing, and performance testing.
The object of research: the process of task management in IT product development
teams.
The subject of research: a web-oriented information system for task management in
IT product development.
Research methods: review of scientific and technical literature to analyze the current
state of task management tools; comparative analysis of existing task management systems
to identify their features and shortcomings; requirements gathering by analyzing existing
systems and similar solutions, as well as observing how users interact with existing systems;
development of a prototype of a web-based information system for task management using
modern web development technologies; usability testing of the prototype to assess its
functionality and performance.
Approval of the results of work. The work was approved on the Days of student
Science ChSTU-2025, Cherkasy, the results of which received a diploma for the first place
in the section "Computer Science and Systems Analysis".
Publications. The results of the qualification work of the bachelor are published in:
1) Dyachenko P.V., Voloshyna V.O. Development of a website for task management
[Electronic resource] // Collection of abstracts of reports of the III International
Scientific and Practical Internet Conference "Innovations and Prospective
Directions of Information Technologies" (IPSHRIT-2024), November 22, 2024,
Cherkasy / compiled by T.O. Prokopenko, O.I. Pidkuiko; Ministry of Education
and Science of Ukraine, Cherkasy State Technological University. – Cherkasy:
ChSTU, 2024. – P. 82–85.
2) Voloshyna V.O., Dyachenko P.V. Web-oriented information system for task
management in IT product development [Electronic resource]: Collection of
abstracts of reports of the student scientific-practical conference of ChSTU: April
22–24, 2025, Cherkasy / [compiled by O.V. Yehorova, O.V. Zakharova, V.V.
Tychkov et al.]; Ministry of Education and Science of Ukraine, Cherkasy State
Technological University. – Cherkasy: ChSTU, 2025. – P. 18.
Keywords: TASK MANAGEMENT, INFORMATION SYSTEM, WEB-BASED
SYSTEM, WEB DEVELOPMENT, TEAM COLLABORATION, IT PRODUCT,
PROJECT PLANNING, USER INTERFACE, HTML, CSS, JAVASCRIPT, NODE.JS,
MYSQL, FRONTEND, BACKEND.
ЗМІСТ
ВСТУП ............................................................................................................................ 14
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ОБҐРУНТУВАННЯ ВИБОРУ НАПРЯМУ
ДОСЛІДЖЕННЯ ............................................................................................................ 17
1.1 Характеристика обраного напряму дослідження ................................................... 17
1.1.1 Визначення поняття управління завданнями.................................................... 17
1.1.2 Характеристики та функції веб-орієнтованих інформаційних систем для
управління завданнями у процесі розробки IT-продуктів ........................................ 18
1.1.3 Сучасні тенденції управління завданнями в IT-проєктах ................................ 19
1.2 Порівняльний аналіз існуючих веб-орієнтованих інформаційних систем для
управління завданнями .................................................................................................. 22
1.2.1 Платформа для візуального управління завданнями та проєктами Trello ...... 22
1.2.2 Система для командної координації та управління проєктами Asana ............ 24
1.2.3 Вебсервіс для комплексного управління завданнями та проєктами ClickUp . 27
1.2.4 Платформа для управління командними робочими процесами Monday.com . 30
1.2.5 Вебсервіс для організації особистих завдань та проєктів Todoist ................... 33
1.3 Аналіз переваг та недоліків існуючих веб-орієнтованих систем для управління
завданнями...................................................................................................................... 38
1.4 Постановка задачі дослідження ............................................................................... 40
Висновки до розділу 1 ................................................................................................... 41
2 ПРОЄКТУВАННЯ ВЕБ-ОРІЄНТОВАНОЇ ІНФОРМАЦІЙНОЇ СИСТЕМИ .......... 42
2.1 Аналіз вимог до інформаційної системи ................................................................ 42
2.1.1 Визначення користувачів інформаційної системи та їхніх ролей ................... 42
2.1.2 Функціональні вимоги до інформаційної системи ........................................... 43
2.1.3 Нефункціональні вимоги до інформаційної системи ....................................... 45
2.2 Моделювання предметної області інформаційної системи ................................... 50
2.2.1 Опис основних об’єктів предметної області інформаційної системи ................ 50
2.2.2 Визначення зв’язків між об’єктами ...................................................................... 53
2.2.3 Діаграма «сутність-зв’язок» інформаційної системи .......................................... 54
2.3 Проєктування логічної структури інформаційної системи. Побудова діаграми
класів ............................................................................................................................... 56
2.4 Архітектурне проєктування інформаційної системи ............................................. 63
2.4.1 Загальна архітектура інформаційної системи ................................................... 63
2.4.2 Склад компонентів інформаційної системи та їх функцій .............................. 65
2.4.3 Діаграма компонентів інформаційної системи ................................................ 66
2.4.4 Діаграма розгортання інформаційної системи ................................................. 69
2.5 Моделювання поведінки інформаційної системи. Діаграма діяльності ............... 71
Висновки до розділу 2 ................................................................................................... 84
3 РОЗРОБКА ВЕБ-ОРІЄНТОВАНОЇ ІНФОРМАЦІЙНОЇ СИСТЕМИ....................... 85
3.1 Вибір та обґрунтування технологій розробки інформаційної системи ................. 85
3.2 Розробка клієнтської частини інформаційної системи .......................................... 86
3.3 Розробка серверної частини інформаційної системи ............................................. 97
3.3.1 Розробка структури бази даних інформаційної системи .................................... 97
3.3.2 Реалізація API та логіки обробки запитів інформаційної системи ................... 108
3.4 Тестування розробленої інформаційної системи ................................................. 114
3.4.1 Функціональне тестування інформаційної системи .......................................... 115
3.4.2 Тестування зручності використання інформаційної системи ........................... 120
3.4.3 Тестування продуктивності інформаційної системи ......................................... 123
Висновки до розділу 3 ................................................................................................. 124
ВИСНОВКИ ................................................................................................................. 125
ДОДАТОК А ................................................................................................................ 129
ДОДАТОК Б ................................................................................................................. 131
ДОДАТОК В................................................................................................................. 142
ДОДАТОК Г ................................................................................................................. 148
ДОДАТОК Д ................................................................................................................ 161
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
API – Application Programming Interface, прикладний програмний інтерфейс;
CRM – Customer Relationship Management, управління взаєминами з клієнтами;
ERD – Entity-Relationship Diagram, діаграма «сутність-зв’язок»;
ERP – Enterprise Resource Planning, планування ресурсів підприємства;
ШІ – штучний інтелект;
14
ВСТУП
Сьогодні ІТ-галузь швидко змінюється: цифрові технології розвиваються,
конкуренція зростає, а проєкти стають складнішими. В таких умовах важливо
налагодити ефективне управління завданнями та злагоджену роботу команди. Тому
створення інструментів, які допомагають упорядкувати робочі процеси, стежити за
виконанням завдань й підвищити продуктивність команди, залишається актуальним
як у теоретичному, так і в практичному аспектах.
Управління завданнями пов’язане з різними процесами – від розподілу ролей у
команді до контролю за виконанням задач у межах проєкту. Існуючі сервіси, як-от
Trello, Asana, ClickUp, Monday.com та інші, пропонують багато функцій, але не
завжди враховують особливості невеликих команд або стартапів. Такі команди часто
працюють з обмеженими ресурсами й потребують простих, зручних у використанні
рішень, які легко адаптувати під власні потреби. Крім того, більшість подібних
систем орієнтовані на комерційне використання, що може ускладнювати їх
застосування в студентських ініціативах, навчальних проєктах або внутрішніх
командах невеликих ІТ-компаній.
Проблема управління завданнями в ІТ-проєктах є актуальною темою
досліджень, оскільки ефективне планування та реалізація проєктів вимагають знань
як у технічній, так і в управлінській сферах. Серед фахівців, які зробили суттєвий
внесок у розвиток цієї теми, можна відзначити Джеффа Сазерленда – одного з авторів
методології Scrum, який написав низку праць про гнучке управління проєктами. Його
підхід до організації командної роботи став основою для багатьох методик у сфері
Agile. Кен Швабер – співзасновник Scrum Alliance, активно працює над
стандартизацією Agile та є співавтором оригінального Scrum Guide. Майк Коун, автор
книг «User Stories Applied» [1] та «Agile Estimating and Planning» [2], зробив значний
внесок у розвиток Agile-менеджменту, а його роботи стали основними посібниками
для менеджерів проєктів. У сфері DevOps важливу роль відіграє Джин Кім –
дослідник і співавтор книги «The Phoenix Project» [3], що описує трансформацію ІТ-
відділів через ефективне управління. Гарольд Керцнер, авторитет у класичному
15
управлінні проєктами, чия книга «Project Management: A Systems Approach to
Planning, Scheduling, and Controlling» [4] стала основою для багатьох навчальних
програм у цій галузі.
У світі активно розвиваються підходи до автоматизації управління завданнями
завдяки впровадженню сучасних вебтехнологій, хмарних обчислень, штучного
інтелекту та інтеграції з іншими корпоративними платформами. Серед провідних
компаній у цьому напрямі – Atlassian, Microsoft, Asana, Inc., Monday.com, ClickUp та
Smartsheet Inc.. Вони не лише розробляють сучасні платформи для управління
завданнями, а й впливають на розвиток методологій організації командної роботи у
сфері розробки IT-продуктів.
Світові тенденції демонструють зростаючу популярність гнучких методологій
управління (Agile, Scrum, Kanban), а також посилення ролі автоматизації у виконанні
повторюваних завдань. Все частіше у проєктному середовищі використовуються
візуальні засоби планування, аналітичні панелі для моніторингу прогресу, а також
інтелектуальні модулі, здатні прогнозувати строки завершення робіт або виявляти
потенційні ризики. У цьому контексті веб-орієнтовані системи виступають
універсальним інструментом для забезпечення доступу до платформи з будь-якого
пристрою, незалежно від місцезнаходження користувача.
З огляду на вказане, розробка власної інформаційної системи для управління
завданнями в командах розробників ІТ-продуктів має не лише дослідницьку, а й
практичну цінність. Така система повинна поєднувати зручний інтерфейс, підтримку
різних ролей та взаємодії між учасниками, можливості для налаштування та простоту
в організації робочого простору.
Метою даної кваліфікаційної роботи є створення веб-орієнтованої
інформаційної системи, що забезпечує ефективне управління завданнями в команді
розробників IT-продуктів.
Для досягнення поставленої мети потрібно вирішити наступні завдання:
проаналізувати існуючі системи управління завданнями та їх функціональні
можливості;
16
виконати дослідження основних процесів, які виникають під час управління
проєктами та командною взаємодією в IT-розробці;
провести огляд існуючих рішень для управління проєктами та завданнями в
IT-командах;
сформулювати вимоги до інформаційної системи для управління завданнями
при розробці IT-продуктів;
визначити функції користувачів, які будуть працювати з системою;
спроєктувати структуру інтерфейсу користувача та бази даних системи
управління завданнями;
спроєктувати архітектуру вебзастосунку, зокрема взаємодію між основними
модулями для управління командами, проєктами та завданнями;
реалізувати вебзастосунок із основними модулями для управління
командами, проєктами та завданнями;
провести тестування системи та оцінити її функціональність, зручність
використання та можливості для подальшого розвитку;
представити опис роботи розробленої системи та її основних компонентів.
Результатом роботи є розробка веб-орієнтованої інформаційної системи для
управління завданнями при розробці IT-продуктів. Система має забезпечити зручний
інтерфейс для управління командами, проєктами та завданнями, підтримувати різні
ролі користувачів та підвищувати продуктивність в організації спільної роботи.
17
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ОБҐРУНТУВАННЯ ВИБОРУ
НАПРЯМУ ДОСЛІДЖЕННЯ
1.1 Характеристика обраного напряму дослідження
1.1.1 Визначення поняття управління завданнями
Управління завданнями – це процес планування, організації, контролю та
моніторингу виконання завдань з метою досягнення встановлених цілей у визначені
терміни та в межах наявних ресурсів [5]. Завдання можуть бути різного масштабу: від
розробки функціональних елементів продукту до організації командної роботи та
узгодження діяльності між різними підрозділами.
У сфері розробки IT-продуктів управління завданнями включає такі етапи:
постановка завдань, визначення їх обсягів, вимог та очікуваних результатів;
розподіл завдань серед учасників проєкту з урахуванням їхніх навичок та
наявних ресурсів;
категоризація завдань за критерієм важливості та терміновості;
установлення термінів виконання завдань та контроль за їх дотриманням;
оцінка результатів виконання завдань та коригування планів в разі
необхідності.
Управління завданнями при розробці IT-продуктів вимагає системного підходу,
який охоплює не лише ефективний розподіл завдань та контроль за їх виконанням, а
й забезпечення прозорості та організації спільної роботи між учасниками проєкту.
Для досягнення цих цілей використовуються веб-орієнтовані системи для управління
завданнями. Вони забезпечують зручні платформи для організації та моніторингу
робочих процесів, дозволяючи команді підтримувати взаємодію в реальному часі.
18
1.1.2 Характеристики та функції веб-орієнтованих інформаційних систем
для управління завданнями у процесі розробки IT-продуктів
Веб-орієнтована інформаційна система – це програмне забезпечення, що
функціонує у веб-середовищі та забезпечує доступ до інформації через браузер. Такі
системи інтегровані з різними інструментами для роботи з даними: базами даних,
системами контролю версій та засобами аналітики.
Основними характеристиками таких систем є:
доступність – користувачі мають можливість взаємодіяти з системою з будь-
якого пристрою, що має доступ до Інтернету;
централізоване управління – всі дані зберігаються та обробляються на
єдиному сервері або кластері серверів, а клієнти отримують доступ до
інформації через веб-інтерфейс або API;
масштабованість – можливість розширення функціоналу відповідно до
потреб бізнесу;
інтеграція з іншими сервісами – підтримка API для зв’язку з інструментами
розробки, інтеграція з CRM, ERP та іншими системами.
Розробка IT-продуктів є складним процесом, який потребує чіткої організації
виконання завдань, координації командної роботи та ефективного управління
ресурсами. Оскільки кожен проєкт включає в себе завдання та строки їх виконання,
успіх проєкту залежить від ефективного управління ними. Це передбачає не лише
правильну пріоритизацію завдань, а й ефективний розподіл часу, який витрачається
на їх виконання. Неправильне управління завданнями може призвести до
накопичення незавершених завдань, що в кінцевому підсумку негативно вплине на
результати виконання проєкту.
Веб-орієнтовані системи для управління завданнями призначені для вирішення
проблеми організації та контролю за виконанням завдань у проєкті. Вони надають
командам зручні інструменти для планування, відстежування прогресу виконання
завдань та взаємодії між членами команди. Ці системи об’єднують різні функції:
автоматизацію нагадувань, спільне редагування документів та візуалізацію прогресу,
19
сприяючи покращенню продуктивності команди.
Основні функції веб-орієнтованих інформаційних систем для управління
завданнями при розробці IT-продуктів представлені на рис. 1.1:
Рисунок 1.1 – Функції веб-орієнтованих інформаційних систем для управління
завданнями при розробці IT-продуктів
Впровадження веб-орієнтованих інформаційних систем у розробку IT-
продуктів не тільки підвищує продуктивність команд, а й допомагає мінімізувати
ризики, пов’язані з управлінням проєктами. Це сприяє більш раціональному
використанню ресурсів та забезпечує високі результати в реалізації проєктів. У
сучасних умовах розвитку технологій такі системи стають незамінним інструментом
для організації робочих процесів.
1.1.3 Сучасні тенденції управління завданнями в IT-проєктах
Розвиток інформаційних технологій та зміна підходів до організації роботи
сприяють появі нових методів управління завданнями в IT-сфері. Успішне виконання
проєктів залежить від чіткого планування, злагодженої роботи команди та
оперативної адаптації до змін. Тому для цього існують різні методології, які
допомагають структурувати процеси, контролювати виконання завдань і
підвищувати продуктивність.
20
Методології управління завданнями:
Waterfall, або каскадна модель, є одним із найстаріших підходів до управління
завданнями. Цей метод передбачає послідовне виконання етапів розробки, де всі
завдання розділені на окремі фази: аналіз вимог, проєктування, розробка, тестування
та впровадження. Кожен етап виконується послідовно, і повернутися до попереднього
без суттєвих змін у плануванні неможливо [6].
Основною перевагою цього методу є структурованість та передбачуваність:
замовник та команда мають чітке уявлення про строки, бюджет та кінцевий результат
ще на початкових етапах проєкту. Проте такий підхід має свої недоліки: якщо під час
розробки з’являються нові вимоги, впровадити їх буде складно, оскільки доведеться
переглядати вже виконані етапи. Тому каскадна модель найкраще працює для
стабільних проєктів, де всі параметри визначені ще на початку.
На противагу класичній каскадній моделі, Agile-методологія пропонує більш
адаптивний підхід до управління завданнями та проєктами. При цьому підході робота
організовується короткими циклами – ітераціями, під час яких команда
зосереджується на виконанні певного набору завдань та створенні невеликих
функціональних частин продукту. По завершенні циклу роботи учасники команди
аналізують виконану роботу, отримують відгуки від замовника і вносять корективи.
Якщо під час виконання завдань виникає потреба внести зміни, команда може
повернутися до попередніх етапів та адаптувати продукт відповідно до нових вимог
без зайвих витрат часу або ресурсів [7].
Серед Agile-підходів найбільш популярним є Scrum. Ця методологія передбачає
роботу в рамках спринтів, які зазвичай тривають від одного до чотирьох тижнів.
Scrum чітко визначає ролі у команді: власник продукту, Scrum-майстер та команда
розробників. Власник продукту визначає, що потрібно розробити, формулює
пріоритети та збирає зворотний зв'язок, щоб команда знала, над чим працювати в
першу чергу. Scrum-майстер слідкує за дотриманням процесів Scrum, організовує
комунікацію в команді та допомагає вирішувати проблеми, що виникають. Команда
розробників складається з спеціалістів, які безпосередньо працюють над створенням
21
продукту. Scrum підходить для складних проєктів, де вимоги змінюються протягом
розробки [8].
Інтеграція штучного інтелекту:
В останні кілька років штучний інтелект також став важливою складовою веб-
орієнтованих інформаційних систем для управління завданнями. Одним зі способів
використання ШІ в управлінні завданнями є прогнозування строків їх виконання. На
основі попередніх даних про виконані завдання, час їх реалізації, а також
продуктивність окремих виконавців і команди загалом, інтелектуальні алгоритми
дозволяють розраховувати оптимальні дедлайни, враховуючи можливі затримки або
ризики.
Штучний інтелект також допомагає аналізувати як працює команда. Він збирає
дані про те, скільки часу потрібно на виконання завдань і як активно учасники
працюють. Завдяки цьому алгоритми виявляють певні закономірності та знаходять
проблеми в роботі команди. Менеджери, використовуючи цю інформацію, можуть
краще розподіляти робоче навантаження серед членів команди.
Візуалізація робочого процесу:
Щоб команда чітко розуміла, на якому етапі знаходиться робота і що потрібно
зробити далі, у сучасних веб-орієнтованих інформаційних системах для управління
завданнями використовуються візуальні елементи для наочного відображення
робочого процесу. Візуалізація завдань дозволяє бачити загальну картину прогресу
виконання проєкту та контролювати строки виконання завдань.
Найпоширенішим інструментом для візуалізації завдань є канбан-дошки.
Канбан-дошка представляє собою панель, де кожне завдання представляється
карткою, яка переміщується між різними стовпцями. Стовпці відповідають етапам
робочого процесу: «Заплановано», «У процесі», «Завершено». Кількість етапів
залежить від використовуваної платформи для управління завданнями.
Ще одним інструментом для візуалізації завдань у проєктах є діаграми Ганта.
Вони дозволяють відображати графік виконання завдань у вигляді горизонтальних
смуг, що показують терміни виконання та взаємозв'язки між різними завданнями.
22
Діаграми Ганта допомагають виявляти, як виконання одних завдань впливає на інші,
які завдання виконуються паралельно, а які є залежними від інших, що, у свою чергу,
дозволяє краще планувати терміни.
Перехід до хмарних платформ, підтримка віддаленої роботи та асинхронної
комунікації:
З розвитком технологій все більше компаній надають перевагу віддаленій
роботі, і саме хмара дозволяє зберігати всі дані та інструменти в одному місці,
доступному з будь-якого пристрою. Учасники команди можуть працювати з дому, з
кав'ярні або з іншого місця, де є інтернет.
Хмарні платформи підтримують асинхронну комунікацію, що важливо для
команд, учасники яких працюють в різних часових зонах. Замість того щоб чекати на
відповідь колеги, члени команди можуть залишати коментарі, оновлення та запитання
у системі, а інші отримають доступ до цієї інформації, коли їм буде зручно.
1.2 Порівняльний аналіз існуючих веб-орієнтованих інформаційних систем
для управління завданнями
1.2.1 Платформа для візуального управління завданнями та проєктами
Trello
Trello – це інструмент для управління завданнями, побудований на основі
канбан-методології, що дозволяє організовувати робочі процеси через представлення
завдань у вигляді карток.
Завдяки своєму мінімалістичному дизайну, Trello є доступним для користувачів
без технічного досвіду. Зручний інтерфейс без зайвих деталей дозволяє швидко
звикнути до платформи. Картки, списки та дошки організовані інтуїтивно, тож
працювати з платформою легко й зручно.
Trello підходить для невеликих команд або особистого використання, де
необхідна проста організація робочого процесу без складних налаштувань.
Головна сторінка веб-сайту Trello (https://trello.com/uk) представлена на рис.
23
1.2.
Рисунок 1.2 – Головна сторінка веб-сайту Trello
Trello пропонує багато функціональних можливостей для ефективного
управління проєктами та завданнями. Дошки відображають проєкти, списки
використовуються для позначення етапів виконання завдань: «Заплановано», «У
процесі», «Виконано», а картки відповідають окремим завданням. Для візуалізації
прогресу виконання завдань картки можна переміщувати між списками.
Кожна картка дозволяє додавати опис, вкладення, дедлайни, теги, чек-листи та
коментарі. Завдання можуть закріплюватися за окремими користувачами для
ефективного розподілу обов’язків. Користувачі можуть залишати коментарі до
завдань, позначати колег за допомогою тегів та додавати реакції для швидкого
зворотного зв’язку. Платформа підтримує інтеграцію зі сторонніми сервісами, такими
як Google Drive, Slack і Dropbox, для розширення функціональних можливостей.
Вбудований інструмент автоматизації Butler дозволяє автоматизувати рутинні
процеси, наприклад, переміщення карток завдань між списками або надсилання
сповіщень. Butler доступний як у безкоштовному, так і в платному планах, однак у
безкоштовній версії існують обмеження на кількість автоматизованих дій та
командних процесів на місяць.
24
Переваги платформи:
інтерфейс, побудований на основі канбан-дошки, забезпечує зручну
візуалізацію завдань та інтуїтивно зрозумілий процес роботи;
підтримка командної роботи з можливістю додавання учасників, коментарів
та прикріплення файлів;
можливість створення автоматизацій для спрощення виконання
повторюваних завдань;
основні функції безкоштовного тарифного плану підходять для базового
управління невеликими проєктами, забезпечуючи основні потреби команди.
Недоліки платформи:
у безкоштовній версії відсутні розширені можливості, такі як детальна
аналітика та автоматизація, які можуть бути критичними для складних або
великих проєктів;
обмежені можливості для управління великими проєктами, що мають
складну ієрархічну структуру;
відсутні розвинені можливості для управління ресурсами, які б дозволяли
краще планувати навантаження та час команди;
платформа є залежною від зовнішніх інтеграцій для розширення
функціоналу.
1.2.2 Система для командної координації та управління проєктами Asana
Asana – це платформа для управління завданнями та координації командної
роботи, що надає інструменти для планування, відстеження та контролю виконання
проєктів. Система дозволяє створювати завдання та підзавдання, встановлювати
дедлайни, визначати відповідальних осіб і пріоритети.
Asana підтримує різні варіанти візуалізації робочих процесів, включаючи
списки, канбан-дошки, календарі та таймлайни, що дозволяє командам обирати
найбільш зручний формат для управління завданнями та контролю залежностями між
ними.
25
Платформа орієнтована на середні та великі команди, які потребують
детального контролю та організації робочих процесів, що включають декілька етапів
виконання завдань.
Головна сторінка веб-сайту Asana (https://asana.com) наведена на рис. 1.3.
Рисунок 1.3 – Головна сторінка веб-сайту Asana
Asana забезпечує комплексні інструменти для планування, координації та
контролю виконання завдань. Платформа дозволяє створювати команди, розподіляти
їх на робочі групи, а також встановлювати ролі та права доступу до завдань і проєктів.
Завдання можуть містити підзадачі з дедлайнами, тегами, пріоритетами та
відповідальними особами.
Asana пропонує кілька форматів для візуалізації завдань: списки, календарі,
канбан-дошки та таймлайни. Це забезпечує зручний спосіб відстеження виконання
завдань та управління їхніми залежностями. Завдяки таймлайнам можна легко
контролювати взаємозв'язки між завданнями та слідкувати за їх виконанням.
Функції звітності дають змогу аналізувати продуктивність команди,
створювати звіти за проєктами, а також відстежувати виконання завдань і дотримання
дедлайнів. Для оптимізації робочих процесів передбачено можливість створення
повторюваних завдань, використання шаблонів робочих процесів, а також
налаштування автоматичних нагадувань про терміни виконання і тригерів для
26
сповіщень.
Для сприяння злагодженій командній роботі Asana підтримує обмін
коментарями, прикріплення файлів та ведення журналу змін у завданнях. Інтеграція
з популярними платформами, такими як Google Drive, Slack і Microsoft Teams,
дозволяє зберігати всі дані в одному робочому просторі та покращує співпрацю в
команді.
Переваги платформи:
доступність різних форматів, таких як списки, календарі, канбан-дошки та
таймлайни, дозволяє адаптувати систему до різних стилів управління
проєктами;
інструмент підтримує автоматизацію повторюваних завдань, створення
шаблонів та налаштування робочих процесів, дозволяючи знизити обсяг
рутинної роботи;
дає змогу аналізувати продуктивність команди, слідкувати за виконанням
завдань і відстежувати прогрес у реальному часі;
підтримує обмін коментарями, прикріплення файлів і ведення журналу змін
для ефективної комунікації в команді;
однаково добре підходить як для невеликих груп, так і для великих команд,
що одночасно керують значною кількістю проєктів.
Недоліки платформи:
деякі можливості, такі як таймлайни, розширена автоматизація, звіти та
інтеграція з деякими зовнішніми інструментами, доступні лише в платних
тарифах;
при роботі з великою кількістю завдань інтерфейс може здаватися
перевантаженим, а пошук потрібної інформації – менш інтуїтивним;
інструмент не дозволяє повноцінно планувати й відстежувати
завантаженість працівників у межах проєктів;
налаштування канбан-дошок чи робочих просторів мають фіксовану
структуру.
27
1.2.3 Вебсервіс для комплексного управління завданнями та проєктами
ClickUp
ClickUp – це багатофункціональна хмарна платформа для управління
завданнями, яка поєднує функції менеджера завдань, інструментів для спільної
роботи, автоматизації процесів та аналітики. Вона позиціонується як універсальне
рішення, яке може замінити кілька окремих програм для управління проєктами,
наприклад, Trello, Asana, Notion та Jira. Завдяки гнучкості налаштувань, ClickUp
підходить для різних сфер застосування, включаючи розробку програмного
забезпечення, наукові дослідження, управління бізнес-процесами та персональне
планування.
ClickUp підтримує різні візуальні формати: списки завдань, канбан-дошки,
таймлайни для управління залежностями між завданнями та календарі для детального
планування. Таймлайни дозволяють відстежувати залежності між завданнями, однак
для більш складних зв’язків використовуються діаграми Ганта, які роблять
управління залежностями між завданнями більш гнучким та деталізованим.
Платформа ClickUp підходить для команд будь-якого розміру та орієнтована на
організації, яким необхідна централізована система для управління проєктами та
завданнями з можливістю детального моніторингу та налаштування автоматизацій
для підвищення продуктивності.
Платформа ClickUp переважно орієнтована на команди та організації, оскільки
надає інструменти для колективної роботи, управління проєктами та координації
завдань. Однак вона також може бути корисною для індивідуальних користувачів,
зокрема для тих, хто шукає ефективний інструмент для організації особистих завдань
і планування. У цілому, ClickUp є ефективним рішенням у разі потреби
централізованої системи для управління проєктами та завданнями з можливістю
детального моніторингу прогресу та налаштування автоматизацій для підвищення
продуктивності.
Головна сторінка веб-сайту ClickUp (https://clickup.com) наведена на рис. 1.4.
28
Рисунок 1.4 – Головна сторінка веб-сайту ClickUp
Однією з особливостей платформи ClickUp є її багаторівнева ієрархічна
структура, яка дозволяє ефективно організовувати завдання. Вона включає робочий
простір, що об’єднує всі проєкти, окремі простори для команд, теки для групування
завдань, списки завдань, а також самі завдання і підзавдання. Додатково передбачено
інструменти для ведення контрольних переліків та використання кастомних полів для
деталізації завдань.
Гнучкість налаштувань ClickUp забезпечується можливістю зміни стандартних
статусів завдань та вибору способу їх візуального представлення. Платформа
підтримує понад 15 режимів перегляду, серед яких класичний список, канбан-дошка,
діаграма Ганта, календарний перегляд та таймлайн. Також передбачені інструменти
для створення ментальних карт та роботи з табличними даними.
Для підвищення ефективності робочих процесів ClickUp пропонує вбудовану
систему автоматизації. Користувачі можуть налаштовувати автоматичні тригери, що
виконують певні дії за заданими умовами. Наприклад, зміна статусу завдання може
запускати повідомлення для команди або ініціювати створення нового підзавдання.
Також платформа підтримує повторювані завдання та інтеграцію із Zapier для зв’язку
з іншими сервісами.
ClickUp містить розвинені інструменти для командної роботи та комунікації.
29
Завдання можуть містити коментарі, де учасники можуть згадувати один одного або
обговорювати робочі питання. Крім того, вбудовані документи та інтерактивні дошки
дозволяють спільно працювати над текстами та візуальними схемами без
необхідності використовувати зовнішні редактори.
Аналітика та звітність у ClickUp представлені через налаштовувані
інформаційні панелі та інструменти для відстеження продуктивності. Платформа
підтримує контроль витраченого часу, аналіз навантаження команди та генерацію
детальних звітів про виконання завдань. Завдяки цьому користувачі можуть
оцінювати ефективність роботи команди та оптимізувати розподіл ресурсів.
ClickUp також пропонує багато інтеграцій з популярними сервісами, зокрема
Google Drive, Dropbox, Slack, Microsoft Teams, GitHub, GitLab та Bitbucket. Крім того,
платформа підтримує API, що дає можливість розробникам створювати індивідуальні
інструменти та автоматизувати процеси для ефективної роботи з даними платформи.
Переваги платформи:
веб-застосунок пропонує великий набір інструментів для управління
проєктами, що охоплюють різні аспекти робочих процесів;
є можливість налаштування автоматизацій для підвищення продуктивності;
інтуїтивно зрозумілий інтерфейс з високим рівнем кастомізації;
можливість створення індивідуальних рішень за допомогою API;
підтримка багатьох форматів для відображення завдань, таких як канбан-
дошки, таймлайни та діаграми Ганта;
платформа надає можливість детального моніторингу прогресу завдань і
проєктів.
Недоліки платформи:
безкоштовна версія пропонує обмежені можливості в порівнянні з платними
тарифами, що може бути проблемою для команд, які потребують більше
функціональних можливостей;
платформа може бути надто складною для малих команд або індивідуальних
користувачів, які не потребують багатьох функцій;
30
велика кількість налаштувань та опцій може вимагати додаткового часу на
освоєння для нових користувачів;
продуктивність платформи при роботі з великими обсягами даних або
численними завданнями знижується, впливаючи на загальну ефективність
роботи;
платформа не підтримує офлайн-режим і потребує стабільного підключення
до Інтернету для коректної роботи, що може створювати труднощі за умов
обмеженого доступу до мережі.
1.2.4 Платформа для управління командними робочими процесами
Monday.com
Monday.com – це ще одна хмарна платформа для управління завданнями та
проєктами, розроблена з метою оптимізації командної роботи, контролю за прогресом
виконання задач та ефективної організації робочих процесів. Платформа має зручний
інтерфейс, який можна налаштувати відповідно до потреб команди або конкретного
проєкту.
Система базується на візуальній моделі, що дозволяє створювати,
налаштовувати та управляти завданнями у форматах таблиць, дошок або календарів.
Зрозумілий інтерфейс допомагає ефективно керувати всіма етапами роботи та
забезпечує чітку комунікацію між учасниками проєкту.
Головною особливістю Monday.com є можливість вибору напряму
використання платформи відповідно до потреб користувачів. Вона підтримує різні
сфери: управління проєктами, задачами, маркетингом, дизайном, CRM, програмним
забезпеченням, IT, операціями та продуктами. Така універсальність забезпечує
гнучкість у використанні та робить платформу ефективним інструментом для
організації роботи в різних галузях.
Головна сторінка веб-сайту Monday.com (https://monday.com) представлена на
рис. 1.5.
31
Рисунок 1.5 – Головна сторінка веб-сайту Monday.com
Платформа Monday.com надає розширені можливості для управління
завданнями та проєктами, забезпечуючи ефективну координацію роботи команд та
автоматизацію процесів. Система дозволяє створювати завдання з можливістю
встановлення дедлайнів, пріоритетів, тегів, а також призначати виконавців. Для
візуалізації процесів передбачено використання канбан-дошок, які допомагають
структурувати завдання за етапами виконання та наочно відображати поточний
статус проєкту.
Крім канбан-дошок, Monday.com також пропонує можливість відображення
завдань у вигляді таблиць. Це дозволяє зручно працювати з великими обсягами даних,
проводити аналіз та відстежувати статуси виконання завдань. Такий підхід є
оптимальним для компаній, що керують масштабними проєктами з великою
кількістю взаємопов’язаних завдань.
Для спрощення управління проєктами на Monday.com передбачено можливість
створення та налаштування робочих процесів за допомогою готових шаблонів.
Шаблони містять попередньо налаштовані етапи виконання завдань, які можна
змінювати, додаючи нові статуси, коригуючи структуру процесів і визначаючи
основні параметри проєкту.
Monday.com також підтримує автоматизацію для виконання повторюваних дій:
32
зміну статусів завдань, надсилання сповіщень, призначення відповідальних осіб при
створенні нового завдання або автоматичне генерування завдань за заданими
умовами, дозволяючи мінімізувати ручне втручання та зменшити кількість рутинних
операцій.
Система дозволяє налаштовувати сповіщення та нагадування, щоб учасники
команди вчасно отримували інформацію про зміни статусів завдань або наближення
термінів їх виконання. Завдання можна категоризувати за допомогою міток,
встановлювати пріоритети для визначення їх важливості, а також коментувати,
обмінюватися файлами та повідомленнями прямо в межах завдання або проєкту.
Платформа має інтеграцію з популярними сервісами, такими як Google Drive,
Slack і Zoom, дозволяючи зручно обмінюватися інформацією та працювати разом на
різних платформах. Завдяки автоматичному оновленню статусів та історії змін
учасники можуть спільно працювати над завданнями в реальному часі.
Переваги платформи:
простий та зручний інтерфейс плафторми дозволяє користувачам швидко
освоїти її основні функції та організовувати робочі процеси без потреби у
додатковому навчанні;
можливість налаштовувати робочі процеси, створювати індивідуальні
шаблони завдань, додавати кастомізовані поля та теги;
функція автоматизації дозволяє налаштовувати автоматичне оновлення
статусів, надсилання сповіщень або створення нових завдань без втручання
користувача;
можливість спільної роботи над завданнями з коментуванням, додаванням
файлів та редагуванням завдань у реальному часі;
налаштування прав доступу для контролю над рівнем доступу учасників до
завдань і проєктів;
можливість категоризації завдань за пріоритетами, тегами та іншими
критеріями для покращення організації роботи.
Недоліки платформи:
33
вартість підписки може бути високою для малих команд або окремих
користувачів, оскільки деякі функції, зокрема розширені можливості
автоматизації та інтеграцій, доступні лише на преміум-планах;
високе навантаження на систему може призводити до уповільнення роботи,
особливо при обробці великих обсягів даних;
платформа повністю залежить від наявності інтернет-з'єднання;
інструменти звітності на базових тарифах мають обмежену
функціональність та не забезпечують детального аналізу ефективності
виконання завдань і проєктів.
1.2.5 Вебсервіс для організації особистих завдань та проєктів Todoist
Todoist – це зручний інструмент для управління завданнями, який підходить для
індивідуальних користувачів та маленьких команд. Платформа надає простий
інтерфейс для організації особистих та професійних завдань. Вона дозволяє
створювати списки завдань, призначати дедлайни, ставити пріоритети та
відстежувати виконання завдань через інтуїтивно зрозумілий інтерфейс.
Todoist надає можливість вибору типу робочого середовища, що дозволяє
адаптувати досвід користувача відповідно до конкретних потреб – будь то особисті
завдання, робочі проєкти чи навчальні цілі. Крім того, платформа пропонує різні
шаблони для організації дошок, завдань, списків та календарів, включаючи шаблони
для ведення обліку, відстеження цілей та планування навчання. Це дозволяє швидко
налаштувати робочий процес та ефективно організовувати час для виконання завдань
у різних сферах життя.
Завдяки своїй простоті та високій функціональності, Todoist дозволяє
ефективно організовувати завдання без складних налаштувань або зайвих функцій.
Однак платформа більше підходить для простих завдань, тому може не підійти
великим командам, які працюють над складними проєктами і потребують більш
детального управління та моніторингу взаємозв'язків між завданнями.
34
Головна сторінка веб-сайту Todoist (https://todoist.com) наведена на рис. 1.6.
Рисунок 1.6 – Головна сторінка веб-сайту Todoist
Todoist пропонує систему відстеження продуктивності Karma, яка дозволяє
користувачам оцінювати свій прогрес у виконанні завдань. Ця система працює на
основі механіки накопичення балів: за кожне виконане завдання користувач отримує
певну кількість балів, тоді як за пропущені дедлайни бали знімаються.
Бали нараховуються за різні активності. Виконання завдань є основним
джерелом балів, і складніші завдання приносять більше очок. Також Todoist мотивує
користувачів підтримувати безперервні серії продуктивних днів, так звані стріки,
коли завдання виконуються регулярно без пропусків. Додаткові бали можна отримати
за досягнення встановлених щоденних або щотижневих цілей.
Окрім накопичення балів, Karma також надає детальну статистику. У розділі
аналітики можна переглядати графіки виконання завдань, аналізувати періоди
зростання продуктивності або спаду та визначати власні робочі тенденції. Це
дозволяє користувачам не лише стежити за своєю ефективністю, а й поступово
вдосконалювати власні звички управління завданнями.
Переваги:
зручний та простий у використанні дизайн, що забезпечує легке освоєння
платформи;
35
передбачена можливість вибору типу профілю – особистий, робочий,
освітній тощо;
доступні шаблони для різних типів завдань, таких як ведення обліку завдань,
відстеження цілей або планування навчання;
вбудована система Karma для мотивації користувачів та відстеження
продуктивності на основі виконаних завдань;
підтримка інтеграцій з Google Calendar, Slack, Dropbox, Zapier, Microsoft
Outlook та іншими популярними робочими інструментами;
можливість відстеження продуктивності за заданими періодами часу та
аналіз виконаних завдань;
наявність безкоштовного плану з базовими функціями, а також розширених
тарифів для професійного використання.
Недоліки:
для отримання додаткових можливостей, таких як розширена звітність або
створення нагадувань, необхідно перейти на преміум-план;
відсутність вбудованих функцій для управління складними проєктами з
великою кількістю учасників і складних залежностей між завданнями;
обмежена інтеграція з деякими сторонніми сервісами без використання
Zapier або інших посередницьких платформ;
функціональність командної роботи обмежена порівняно з конкурентами.
На основі проведеного аналізу веб-орієнтованих інформаційних систем для
управління завданнями можна зробити висновок, що ці платформи мають різний
функціонал, орієнтований на різні категорії користувачів та типи проєктів. Вибір
конкретного інструменту залежить від масштабів роботи, особливостей робочих
процесів і бюджету команди.
Trello є зручним інструментом для індивідуальних користувачів та невеликих
команд, які використовують прості робочі процеси, наприклад, методологію канбан
для візуалізації потоку даних. Його функціонал дозволяє ефективно візуалізувати
завдання, однак він має обмеження для масштабних проєктів або завдань із високим
36
рівнем залежностей.
Asana орієнтована на середні та великі команди, які потребують детального
планування, управління залежностями між завданнями та систематичного
моніторингу прогресу. Інструменти для створення діаграм Ганта, відстеження часу
виконання завдань та аналізу продуктивності команди підходять для проєктів
середньої та високої складності, хоча платформа може вимагати часу для освоєння
через свою багатофункціональність.
ClickUp надає універсальні можливості для команд різного розміру. Платформа
дозволяє налаштовувати робочий простір відповідно до потреб команди: включати до
функціоналу робочого простору організацію завдань, написання документів,
створення дашбордів, додавати можливості штучного інтелекту та інше. ClickUp
пропонує найбільше можливостей для управління проєктами у порівнянні з ішими
платформами.
Monday.com більше підходить для великих команд або організацій, які
працюють над складними проєктами. Основною перевагою платформи є можливість
вибору сфери її використання: для дизайну, маркетингу, інформаційних технологій
тощо. Однак через високу вартість на одного учасника команди її доцільно
використовувати переважно у великих корпоративних проєктах.
Todoist є оптимальною платформою для індивідуального використання та
невеликих команд із простою організацією робочих процесів. Її функціональність
задовольняє потреби в базовому плануванні завдань, однак платформа не забезпечує
необхідних інструментів для великих і складних проєктів.
У таблиці 1.1 наведені результати порівняльного аналізу існуючих платформ
для управління завданнями.
37
Таблиця 1.1 – Результати порівняльного аналізу існуючих платформ для
управління завданнями
Критерій Trello Asana ClickUp Monday Todoist
Структурова
Налаштовува
ний,
Простий та ний, Простий,
орієнтований Інтуїтивний,
інтуїтивний, багатофункці орієнтований
на списки; кольоровий,
Інтерфейс заснований на ональний; на швидке
зрозумілий орієнтований
канбан- може здатися додавання
для на таблиці
дошках складним для завдань
проєктного
новачків
управління
Список, Канбан,
Типи Список, канбан, таблиця,
Список,
подання Канбан-дошка канбан, діаграма діаграма
календар
завдань календар Ганта, Ганта,
календар календар
Призначення
Призначення Призначення Спільні
Призначення виконавців,
Можливості виконавців, виконавців, проєкти,
виконавців, коментарі,
спільної коментарі, коментарі, призначення
коментарі, спільні
роботи обговорення, файли, завдань,
вкладення документи,
вкладення обговорення коментарі
чат
Базові
Немає
правила та
Можливість автоматизації
автоматизації Налаштовуєть
створювати у класичному
з Використанн ся за
Автоматиза власні розумінні, є
використання я правил та допомогою
ція сценарії, лише
м Butler; без тригерів умовних дій
використанн повторювані
додатків та тригерів
я шаблонів задачі та
можливості
фільтри
обмежені
Наявність
безкоштовн Так Так Так Так Так
ого плану
38
Можливість
Середній Високий Середній
налаштуван Обмежена Мінімальна
рівень рівень рівень
ня
Панель Кастомні Віджети з Продуктивніс
Активність
прогресу, дашборди, показниками ть (Karma),
дошки, історія
звіти за графіки, ефективності, кількість
Звіти та змін, базова
статусами, звіти по часу візуальні виконаних
аналітика статистика
фільтри, й дашборди, завдань,
через Power-
базова продуктивно звіти по базова
Ups
візуалізація сті статусах статистика
Web, iOS,
Web, iOS, Web, iOS, Android, Web, iOS, Web, iOS,
Платформи
Android Android Windows, Android Android
Mac
Невеликі та Індивідуальні
Невеликі Команди Бізнес-
Цільова команди користувачі,
команди, різного команди,
аудиторія середнього невеликі
фрілансери масштабу відділи
розміру команди
Мова Англійська, Англійська, Англійська, Англійська, Англійська,
інтерфейсу інші інші інші інші інші
1.3 Аналіз переваг та недоліків існуючих веб-орієнтованих систем для
управління завданнями
Сучасні веб-орієнтовані системи для управління завданнями пропонують
багато можливостей для організації робочого процесу. Вони дозволяють планувати
завдання, розподіляти відповідальність між членами команди, відстежувати
виконання та отримувати аналітичні дані щодо продуктивності команди. Однак,
попри їхню популярність та функціональність, користувачі часто стикаються з
низкою обмежень, які ускладнюють роботу.
Хоча існуючих на сьогодні веб-орієнтованих інформаційних систем для
управління завданнями достатньо для того, щоб підібрати платформу під особливості
проєктів та потреби команди, найпоширенішою проблемою є те, що їхній інтерфейс
39
часто не дуже зручний. Багато систем мають занадто багато функцій, і знайти потрібні
інструменти буває важко. Тоді як інші системи, розраховані на невеликі команди або
індивідуальне використання, бувають занадто простими і не мають всіх необхідних
функцій для комфортної роботи над завданнями та проєктами при розробці IT-
продуктів. Веб-орієнтовані інформаційні системи для управління завданнями
зазвичай мають фіксовану структуру управління завданнями, яка не завжди
підходить для різних команд і проєктів. Одні системи працюють за канбан-
методологією, інші підходять для ієрархічного управління завданнями або гнучких
методологій. Якщо платформа не дає можливості змінювати спосіб планування, це
обмежує команду у виборі оптимальної структури робочого процесу.
Обираючи хмарну веб-орієнтовану інформаційну систему для управління
завданями, компанія повинна сплачувати кошти за ліцензію – це може бути як
одноразовий платіж, так і щомісячна або річна підписка. Крім того, багато сучасних
платформ мають модульну структуру, де базовий функціонал надається за
замовчуванням, а розширені можливості – аналітика, автоматизація чи інтеграції –
доступні лише за додаткову плату. Тарифні плани залежать від кількості активних
користувачів.
Веб-орієнтовані системи залежать від інтернет-з'єднання, тому без доступу до
мережі вони або не працюють, або функціонують з обмеженнями. До того ж, ці
системи використовують сторонні сервіси для зберігання даних, і це створює ризик
втрати інформації при проблемах з серверами. При великій кількості користувачів або
великому обсязі даних відбувається зниження швидкості роботи.
Ще однією складністю є відсутність точного прогнозування термінів виконання
завдань. У більшості випадків терміни встановлюються вручну, без урахування
попередньої статистики, навантаження команди або інших факторів. Функції
прогнозування за допомогою штучного інтелекту, який аналізує попередні дані щодо
продуктивності команди та на основі цього виставляє точні дедлайни, доступні
здебільшого лише у платних планах. І у випадку, коли у команди недостатньо коштів
на придбання повного функціоналу платформи на кожного учасника команди,
менеджерам доводиться самостійно визначати строки виконання завдань.
40
1.4 Постановка задачі дослідження
На сьогоднішній день немає рішення, яке б повністю відповідало вимогам
управління завданнями при розробці IT-продуктів та одночасно залишалося зручним
у використанні. Для створення такої веб-орієнтованої інформаційної системи для
управління завданнями необхідно визначити основні завдання для виконання.
Основні завдання розробки веб-орієнтованої інформаційної системи:
Розробка архітектури системи з модульним підходом.
Створення структури бази даних для зберігання інформації про проєкти,
завдання, користувачів та їхні ролі.
Визначення та налаштування прав доступу для менеджерів та виконавців.
Розробка модуля автентифікації та авторизації.
Забезпечення можливості вибору користувачами одного або кількох відділів
під час реєстрації.
Створення функціоналу для додавання, редагування та видалення проєктів.
Реалізація логіки відображення завдань користувачам на основі їхньої
приналежності до відділів.
Реалізація функціоналу додавання, редагування та видалення завдань.
Забезпечення можливості призначення відповідального виконавця та
встановлення дедлайнів для кожного завдання; прикріплення вкладень.
Реалізація системи статусів для визначення етапу виконання завдання.
Розробка дашборду з відображенням загальної статистики щодо виконання
завдань.
Додавання можливості фільтрації проєктів за статусом.
Додавання можливості фільтрації завдань за статусом та відділом.
Забезпечення фіксації змін у завданнях для відстеження активності.
Забезпечення можливості доступу до системи з різних пристроїв.
Розроблювана інформаційна система повинна забезпечувати базові можливості
для контролю виконання завдань у середовищі розробки IT-продуктів.
41
Висновки до розділу 1
У першому розділі було розглянуто поняття управління завданнями та роль веб-
орієнтованих інформаційних систем у цьому процесі. Описано популярні методології
управління завданнями – Waterfall, Agile та Scrum. Проведено порівняльний аналіз
існуючих платформ для планування та управління завданнями, їхнього функціоналу,
переваг і недоліків. Виявлено основні недоліки сучасних веб-орієнтованих систем для
управління завданнями, основна частина яких зводиться до незручного інтерфейсу та
неоптимізованого функціоналу, що вказує на перевантаженість платформ зайвими
можливостями та водночас нестачу інструментів, дійсно ефективних для організації
роботи в середовищі розробки IT-продуктів.
На основі виявлених недоліків обґрунтовано необхідність створення власної
веб-орієнтованої інформаційної системи для управління завданнями, орієнтованої на
потреби команд, що займаються розробкою IT-продуктів. Визначено основні
завдання її розробки: спроєктувати модульну архітектуру системи, розробити
структуру бази даних для збереження інформації про систему, налаштувати права
доступу в системі для ролей менеджера та виконавця, реалізувати функціонал для
роботи з проєктами та завданнями, забезпечити фіксацію змін у завданнях для
відстеження активності, а також забезпечити доступ до системи незалежно від
використовуваного пристрою.
42
2 ПРОЄКТУВАННЯ ВЕБ-ОРІЄНТОВАНОЇ ІНФОРМАЦІЙНОЇ СИСТЕМИ
2.1 Аналіз вимог до інформаційної системи
2.1.1 Визначення користувачів інформаційної системи та їхніх ролей
У веб-орієнтованій інформаційній системі для управління завданнями
передбачено дві основні ролі користувачів: учасник (виконавець) та менеджер
(організатор команди). Кожна з цих ролей має свої обов’язки та рівні доступу у
системі.
1. Учасник (виконавець)
Роль виконавця передбачає основну взаємодію із завданнями в системі: їх
виконання та оновлення статусу. Це користувач, який бере участь у виконанні завдань
у межах однієї чи кількох команд. Під час першого входу до системи виконавець
обирає відділ (або декілька відділів), що визначає його участь у відповідних відділах
команд при виконанні завдань.
Користувач, що виконує роль учасника, має можливість:
входити до системи;
обирати відділи (наприклад, Frontend, Backend, QA);
переглядати завдання, що були йому призначені;
переглядати завдання у відділах, до яких він належить;
фільтрувати завдання за відділами та за критерієм «Тільки мої завдання»;
здавати призначені йому завдання на перевірку;
додавати коментарі до призначених завдань;
додавати вкладення до призначених завдань;
створювати нові команди та автоматично отримувати роль менеджера у
створеній команді;
2. Менеджер (організатор команди)
Менеджер є користувачем з найвищим рівнем доступу в системі та здійснює
керування командою. Ця роль автоматично надається користувачу, який створює
43
команду в системі. Менеджер має доступ до всіх відділів та завдань у межах своєї
команди, незалежно від того, до яких відділів належить він сам.
Користувач, що виконує роль менеджера, має можливість:
входити до системи;
редагувати інформацію про команду;
запрошувати нових учасників до команди;
створювати нові проєкти у межах своєї команди;
створювати завдання та призначати їх виконавцям;
редагувати, видаляти, приймати або відхиляти завдання;
налаштовувати права доступу для інших учасників команди;
переглядати завдання у всіх відділах команди.
2.1.2 Функціональні вимоги до інформаційної системи
Функціональні вимоги визначають можливості та основний набір функцій, які
має реалізовувати веб-орієнтована інформаційна система для управління завданнями
при розробці IT-продуктів. Ці вимоги базуються на аналізі предметної області,
проведеному в першому розділі, а також на виявлених проблемах існуючих платформ
для управління завданнями.
Основні функціональні вимоги до системи:
1. Реєстрація та автентифікація користувачів
створення облікового запису;
вибір одного або декількох відділів після першого входу;
вхід у систему з обліковими даними;
2. Управління командами та користувачами у командах
створення команди;
автоматичне надання ролі менеджера користувачу, що створив
команду;
додавання та видалення учасників з команди;
створення нових проєктів у межах команди;
44
призначення ролі менеджера іншим учасникам команди;
3. Робота із проєктами
додавання нового проєкту;
редагування параметрів проєкту;
зміна статусу виконання проєкту;
видалення проєкту;
фільтрація проєктів за історією;
4. Робота із завданнями
додавання нового завдання;
редагування параметрів завдання (назва, опис, вкладення, дедлайн,
виконавець);
зміна статусу виконання завдання;
видалення завдання;
5. Перегляд списку завдань
фільтрація завдань за вкладками відділів;
критерій «тільки мої завдання» для відображення завдань користувача
у межах відділу;
відображення деталей завдання;
6. Взаємодія учасників
додавання коментарів до завдань;
додавання вкладень до завдань;
7. Історія змін команди
ведення журналу змін для кожної команди;
можливість перегляду історії змін у команді;
8. Історія змін проєктів
ведення журналу змін для кожного проєкту;
можливість перегляду історії змін у проєктах;
9. Історія змін завдань
ведення журналу змін для кожного завдання;
45
можливість перегляду історії змін у завданнях.
Ці функціональні вимоги є основою для розробки веб-орієнтованої
інформаційної системи для управління завданнями. На основі цих вимог буде
здійснюватися подальше проєктування архітектури системи, бази даних та
інтерфейсу користувача.
2.1.3 Нефункціональні вимоги до інформаційної системи
Нефункціональні вимоги описують обмеження, характеристики та якісні
аспекти веб-орієнтованої інформаційної системи для управління завданнями при
розробці IT-продуктів. Вони впливають на продуктивність, безпеку, зручність
використання та масштабованість системи.
1. Безпека
захист доступу до системи через автентифікацію (логін і пароль);
обмеження повторних спроб входу для запобігання перебору паролів;
автоматичний вихід користувача після тривалої бездіяльності;
2. Доступність
доступність через веб-браузер без необхідності встановлення
додаткового програмного забезпечення;
мінімальний рівень безвідмовної роботи – не менше 90%;
3. Масштабованість
забезпечення можливості додавання нових функцій без порушення
роботи основного функціоналу;
підтримка збільшення кількості користувачів без значного зниження
продуктивності системи;
4. Сумісність
підтримка коректної роботи в основних веб-браузерах (Google Chrome,
Mozilla Firefox, Microsoft Edge, Safari);
5. Продуктивність
46
час відгуку системи на основні операції (створення, редагування,
перегляд, видалення завдань) не повинен перевищувати 2-4 секунд при
стандартному навантаженні;
6. Зручність використання
інтуїтивно зрозумілий інтерфейс із простими засобами навігації;
адаптивний дизайн для коректного відображення на різних пристроях;
мінімальна кількість дій для виконання базових операцій (створення,
редагування, перегляд, видалення завдань);
Наведені нефункціональні вимоги описують базову версію веб-орієнтованої
інформаційної системи для управління завданнями при розробці IT-продуктів та
мають забезпечити стабільність, безпеку та зручність у використанні системи.
2.1.4 Діаграма прецедентів
Діаграма прецедентів – це засіб моделювання функціональних вимог до
системи. Вона відображає, які дії (прецеденти) система повинна виконувати у
відповідь на взаємодію з користувачами або іншими зовнішніми об’єктами
(акторами). На цій діаграмі показано, хто саме користується певною
функціональністю, без уточнення деталей реалізації – таких як алгоритми чи
структура даних. Діаграма дозволяє окреслити межі системи, виявити очікування
замовника та задати основу для подальшого аналізу і проєктування. Вона допомагає
відповісти на ключові питання: що виконує система, хто з нею взаємодіє і які
можливості при цьому використовуються [9].
Актори на діаграмі поділяються на первинних (активних) та вторинних
(пасивних). Первинні актори ініціюють виконання варіантів використання, оскільки
вони самостійно запускають певні дії в системі. Вторинні актори не розпочинають
сценарії, але беруть участь у процесах, коли система звертається до них для
виконання своїх функцій [10].
На основі функціональних вимог до системи та ролей користувачів, визначених
на попередніх етапах проєктування системи, було побудовано діаграму прецедентів
47
для веб-орієнтованої інформаційної системи для управління завданнями (рис. 2.1).
Рисунок 2.1 – Діаграма прецедентів веб-орієнтованої інформаційної системи для
управління завданнями
Діаграма прецедентів моделює основні сценарії взаємодії користувачів із веб-
орієнтованою системою для управління завданнями при розробці IT-продуктів. У
системі визначено дві основні ролі:
учасник (виконавець) – користувач, що виконує призначені завдання;
менеджер (організатор команди) – користувач, який керує завданнями та
учасниками команди.
48
Основні прецеденти:
1. Вхід до системи – користувач має можливість авторизуватися для доступу
до функціоналу системи.
2. Реєстрація – якщо користувач ще не має облікового запису, він має пройти
реєстрацію.
3. Вибір відділу(-ів) – вибір одного або кількох відділів, до яких належатиме
користувач.
4. Створення команди – функція, що дозволяє формувати команди для спільної
роботи.
5. Призначення ролей користувачам – можливість призначати ролі
користувачам.
6. Створення проєктів – необхідна дія для подальшого створення завдань у
системі.
7. Створення завдання – передбачає внесення нових завдань у систему.
8. Редагування завдання – дозволяє вносити зміни до вже існуючих завдань.
9. Додавання вкладення до завдання – дозволяє додавати вкладення до
завдання.
10. Призначення завдання – можливість призначити відповідального за
виконання завдання.
11. Перегляд завдань за відділами – можливість сортування завдань за
відділами.
12. Фільтрація «Тільки мої завдання» – відображення індивідуальних завдань.
13. Перегляд завдання – забезпечує доступ до інформації про конкретне
завдання.
14. Додавання коментарів до завдання – можливість додавати коментарі до
завдання.
15. Здача завдання – можливість подання завдання на перевірку.
16. Прийняття завдання – підтвердження виконання завдання.
17. Відхилення завдання – повернення завдання на допрацювання.
18. Видалення завдання – можливість видалити завдання з системи.
49
Усі користувачі можуть зареєструватися в системі, увійти до свого акаунту й
отримати доступ до її можливостей. Вони можуть створювати команди, залишати
коментарі до завдань, переглядати їх та змінювати статус виконання.
Після реєстрації користувач повинен вибрати відділи, що визначатимуть,
завдання яких відділів відображатимуться на сторінці завдань. Відділи на сторінці
завдань відображаються динамічно – користувач бачить лише ті, в яких є учасником.
Це правило також визначає можливості взаємодії з завданнями. Виконавець не може
змінювати завдання інших користувачів, навіть якщо вони відображаються на його
сторінці завдань, і має лише можливість переглядати їх. Менеджери ж мають повний
доступ до всіх відділів. Для перегляду лише власних завдань використовується фільтр
«Тільки мої завдання», який вмикається за замовчуванням.
Менеджер має більше повноважень. Окрім базових функцій, він може
створювати проєкти, додавати нові завдання, редагувати їх, призначати виконавців та
видаляти непотрібні завдання. Також у нього є право призначати роль менеджера
іншим користувачам.
Відносини «include» підкреслюють, що певні дії є необхідними складовими
інших процесів. Користувач не може увійти в систему, поки не авторизується.
Авторизуватися можуть тільки ті, хто вже зареєстрований. Якщо користувач ще не
має облікового запису, він має пройти процес реєстрації для отримання доступу. Без
реєстрації доступ до системи неможливий. Створення нового завдання можливе лише
в рамках існуючого проєкту. Тому перед додаванням завдання потрібно спочатку
створити проєкт. Створене завдання обов’язково має бути призначене виконавцю чи
групі виконавців.
Окрім обов’язкових зв’язків, діаграма містить також відносини «extend». Вони
вказують на додаткові можливості, які не є обов’язковими, але можуть бути
використані в рамках основного процесу. При створенні команди користувач може
призначити ролі учасникам команди, однак ця дія не є обов’язковою. При редагуванні
завдань користувач має можливість оновити статус завдання, однак він може і не
зробити цього, якщо в цьому немає потреби. Також в процесі редагування завдання є
можливість призначити його іншому виконавцю. Фільтр «Тільки мої завдання» також
50
є extend-функціоналом, що активується за бажанням користувача в межах перегляду
завдань.
2.2 Моделювання предметної області інформаційної системи
Моделювання предметної області є першим етапом у розробці програмної
системи, який визначає та описує сутності, з якими працюватиме система. Це етап
абстракції, де розглядаються основні концепти, зв'язки між ними та їхні
характеристики ще до початку технічної реалізації. Моделювання предметної області
дає змогу чітко зрозуміти, які об'єкти буде обробляти система, як ці об'єкти
взаємодіють між собою та які дії над ними можуть бути виконані.
2.2.1 Опис основних об’єктів предметної області інформаційної системи
У процесі моделювання предметної області системи для управління завданнями
потрібно визначити основні сутності, які є важливими для роботи системи:
1. Користувач – особа, яка взаємодіє із системою. Користувач має такі
властивості:
ім’я – ім’я користувача, яке може бути неунікальним, але
використовується для відображення в інтерфейсі системи;
електронна пошта – адреса електронної пошти, яка використовується
для реєстрації та комунікації з користувачем;
пароль – пароль користувача для входу у систему;
дата реєстрації – дата, коли користувач зареєструвався в системі;
статус – «Активний», «Неактивний»;
остання активність – дата та час останньої активності користувача в
системі.
2. Менеджер – користувач, який керує процесом виконання завдань. Менеджер
має всі властивості Користувача та додаткові функції:
створює проєкти;
51
керує завданнями (створює, редагує, змінює статус, приймає та
відхиляє завдання);
призначає виконавців на завдання.
3. Виконавець – користувач, який отримує завдання та виконує їх. Виконавець
має всі властивості Користувача.
4. Профіль – додаткова інформація про користувача, що розширює його
основні дані в системі. Профіль має такі атрибути:
код аватара – двійкові дані зображення профілю користувача,
закодовані у форматі Base64 (додається за бажанням).
номер телефону – контактний номер телефону користувача (додається
за бажанням).
місто – назва міста проживання або знаходження користувача
(додається за бажанням).
країна – назва країни проживання або знаходження користувача
(додається за бажанням).
5. Команда – група користувачів, що працюють над проєктами.
6. Відділ – структурна одиниця, що об'єднує користувачів за спеціалізацією або
функціональною роллю в процесі розробки. Відділ використовується для
призначення завдань відповідним фахівцям та фільтрації завдань за
напрямками роботи.
Відділ має такі властивості:
назва – назва відділу (наприклад, «Frontend», «Backend», «QA»);
опис – коротка характеристика функціональної області, яку охоплює
відділ.
7. Завдання – одиниця роботи. Завдання має атрибути:
назва – коротко сформульована суть завдання;
опис – детальна інформація про завдання;
статус – «Призначено», «В процесі», «Завершено»;
52
відповідальний виконавець або виконавці – користувачі, яким
призначено завдання;
вкладення – файли, пов’язані із завданням;
дата створення – коли завдання було додано в систему;
дедлайн – крайній термін виконання завдання.
8. Проєкт – набір завдань, об’єднаних спільною метою. Проєкт має такі
атрибути:
назва – коротко сформульована суть проєкту;
опис – детальна інформація про проєкт;
статус – «В роботі», «Завершений» або «Протермінований»;
дата створення – коли проєкт було додано в систему;
дата закінчення – дата завершення проєкту.
9. Вкладення – файли, пов'язані із завданням. Вкладення мають такі
властивості:
назва файлу – оригінальна назва файлу;
шлях до файлу – місцезнаходження файлу в системі;
дата завантаження – коли файл було завантажено;
розмір файлу – розмір файлу у байтах;
тип файлу – MIME-тип файлу.
10. Коментар – текстове повідомлення, яке додається до завдання для
уточнення деталей. Коментар має такі атрибути:
дата створення – коли коментар було додано до завдання;
текст – зміст коментаря;
автор – ім’я користувача, що залишив коментар.
53
2.2.2 Визначення зв’язків між об’єктами
У моделюванні предметної області існує кілька основних типів зв'язків, які
допомагають описувати відношення між різними сутностями [11]:
1. Один до одного (1:1) – один об'єкт має зв'язок з лише одним іншим об'єктом.
2. Один до багатьох (1:M) – один об'єкт може бути пов'язаний з кількома
іншими об'єктами.
3. Багато до одного (M:1) – кілька об'єктів можуть бути пов'язані з одним іншим
об'єктом.
4. Багато до багатьох (M:N) – кілька об'єктів можуть бути пов'язані з кількома
іншими об'єктами. Для реалізації таких зв'язків часто використовують проміжні
сутності.
Зв'язки між об'єктами системи:
1. Користувач Відділ
Користувач може бути частиною кількох відділів, і кожен відділ може мати
кілька користувачів. Тип зв’язку «багато до багатьох» (M:N).
2. Користувач Команда
Користувач може бути частиною кількох команд, і кожна команда може
мати кілька користувачів. Тип зв’язку «багато до багатьох» (M:N).
3. Користувач Профіль
Кожен користувач може мати один профіль, що містить додаткову
інформацію про нього. Кожен профіль належить одному конкретному
користувачу. Тип зв'язку «один до одного» (1:1).
4. Команда Проєкт
Одна команда може виконувати кілька проєктів, але кожен проєкт
прив’язаний до однієї конкретної команди. Тип зв’язку «один до багатьох»
(1:M).
5. Проєкт Завдання
Один проєкт може містити декілька завдань, але кожне завдання належить
лише одному проєкту. Тип зв’язку «один до багатьох» (1:M).
54
6. Менеджер Завдання
Один менеджер може керувати кількома завданнями, а кожне завдання може
мати кількох менеджерів. Тип зв’язку – «багато до багатьох» (M:N).
7. Виконавець Завдання
Один виконавець може мати декілька завдань, і одне завдання може
виконуватись кількома виконавцями. Тип зв’язку «багато до багатьох»
(M:N).
8. Відділ Завдання
Відділ може мати кілька завдань, а завдання прив'язується до одного відділу
для забезпечення відповідності спеціалізації. Тип зв’язку «один до багатьох»
(1:M).
9. Завдання Коментар
Завдання може мати кілька коментарів, і кожен коментар належить певному
завданню. Тип зв’язку «один до багатьох» (1:M).
10. Завдання Вкладення
Одне завдання може мати нуль або більше вкладень, але кожне вкладення
належить лише одному завданню. Тип зв’язку «один до багатьох» (1:M).
11. Користувач Коментар
Користувач може створювати кілька коментарів, і кожен коментар належить
певному користувачу. Тип зв’язку «один до багатьох» (1:M).
2.2.3 Діаграма «сутність-зв’язок» інформаційної системи
Діаграма «сутність-зв’язок» (ER-діаграма) – це засіб концептуального
моделювання, що описує структуру даних через сутності, атрибути та зв’язки між
ними. Вона є універсальним інструментом для візуалізації інформаційних структур і
може бути основою для створення реляційних, ієрархічних чи об’єктно-орієнтованих
моделей даних [12]. Основна мета ER-діаграми полягає в тому, щоб чітко визначити
сутності, їхні атрибути та зв’язки між ними. Це допомагає зрозуміти, як працює
система, та забезпечити її правильне проєктування.
55
Для системи управління завданнями ER-діаграма відображає основні сутності
та їхні зв’язки, що були визначені у попередніх підпунктах (рис. 2.2).
Рисунок 2.2 – Діаграма «сутність-зв’язок» веб-орієнтованої інформаційної
системи для управління завданнями
56
2.3 Проєктування логічної структури інформаційної системи. Побудова
діаграми класів
Проєктування логічної структури є наступним після визначення вимог та
моделювання предметної області етапом у розробці програмного забезпечення. На
цьому етапі формується модель, що визначає організацію та взаємодію основних
сутностей, які використовуються в системі.
Логічна структура системи визначає принципи організації даних, методи їх
зберігання, обробки та передачі між компонентами. Її проєктування забезпечує
створення масштабованої та гнучкої системи, яку зручно підтримувати та
розширювати. Логічна модель виступає основою для подальшого фізичного
проєктування та реалізації системи. Вона забезпечує узгодженість даних, мінімізує їх
дублювання та спрощує процес супроводу системи.
Процес проєктування логічної структури системи передбачає:
визначення класів, що реалізують сутності системи;
опис атрибутів та методів для кожного класу;
встановлення зв’язків між класами (асоціація, композиція, наслідування
тощо);
визначення механізмів взаємодії між класами для виконання основних
функцій системи.
На основі логічної структури розробляється архітектура компонентів системи,
що визначає методи взаємодії програмних модулів та реалізацію бізнес-логіки. Для
візуалізації логічної структури системи застосовується діаграма класів.
Діаграма класів в UML є інструментом об'єктно-орієнтованого моделювання,
який використовується для планування структури програмної системи. Вона
відображає класи, їхні атрибути, методи (функції) та взаємозв’язки між ними [13].
Діаграма класів дозволяє впорядкувати інформацію про те, як має виглядати система,
та є основою для подальшої її реалізації.
Діаграма класів розроблюваної системи представлена на рис. 2.3.
57
Рисунок 2.3 – Діаграма класів веб-орієнтованої інформаційної системи для
управління завданнями
58
Діаграма відображає основні сутності та їх взаємозв'язки в системі управління
завданнями. Вона складається з одинадцяти класів: User, Profile, Team, TeamMember,
Project, Task, TaskAssignment, Comment, Department, UserDepartment та Attachment.
Клас User
Атрибути:
1. id: int – унікальний ідентифікатор користувача в системі;
2. firstName: String – ім'я користувача;
3. lastName: String – прізвище користувача;
4. email: String – електронна адреса користувача;
5. password: String – пароль користувача, що використовується для входу у
систему;
6. registrationDate: Date – дата реєстрації користувача в системі;
7. lastActivity: DateTime – дата та час останньої активності користувача.
Методи:
1. getProfile() – метод для отримання профілю користувача (об'єкта класу
Profile), що містить додаткову інформацію про нього;
2. assignToDepartment(department: Department) – метод для призначення
користувача до відділу.
Клас Profile
Атрибути:
1. id: int – унікальний ідентифікатор профілю;
2. userId: int – унікальний ідентифікатор користувача, пов'язаний з цим
профілем;
3. avatarCode: String – двійкові дані зображення профілю користувача у
форматі Base64;
4. phoneNumber: String – контактний номер телефону користувача;
5. city: String – назва міста проживання або знаходження користувача;
6. country: String – назва країни проживання або знаходження користувача.
59
Методи:
1. viewProfile() – метод для перегляду детальної інформації профілю;
2. editProfile() – метод для редагування інформації профілю.
Клас Team
Атрибути:
1. id: int – унікальний ідентифікатор команди;
2. name: String – назва команди;
3. description: String – опис команди;
4. creationDate: Date – дата створення команди.
Методи:
1. addUser(user: User) – метод для додавання користувача до команди;
2. removeUser(user: User) – метод для видалення користувача з команди;
3. assignManager(user: User) – метод для призначення менеджера команди;
4. viewTeam() – метод для перегляду інформації про команду.
Клас TeamMember
Атрибути:
1. id: int – унікальний ідентифікатор запису про участь користувача в команді;
2. userId: int – ідентифікатор користувача, який є учасником команди;
3. teamId: int – ідентифікатор команди, учасником якої є користувач;
4. isManager: Boolean – прапор, що вказує, чи є користувач менеджером
команди.
Клас Project
Атрибути:
1. id: int – унікальний ідентифікатор проєкту;
2. name: String – назва проєкту;
3. description: String – опис проєкту;
4. creationDate: Date – дата створення проєкту;
60
5. endDate: Date – дата завершення проєкту;
6. status: String – статус проєкту;
7. teamId: int – ідентифікатор команди, яка працює над проєктом.
Методи:
1. createTask(task: Task) – метод для створення завдання в проєкті;
2. viewProject() – метод для перегляду інформації про проєкт;
3. editProject() – метод для редагування інформації про проєкт;
4. deleteProject() – метод для видалення проєкту.
Клас Task
Атрибути:
1. id: int – унікальний ідентифікатор завдання;
2. name: String – назва завдання;
3. description: String – опис завдання;
4. status: String – статус завдання;
5. creationDate: Date – дата створення завдання;
6. deadline: Date – дата завершення завдання;
7. projectId: int – ідентифікатор проєкту, до якого належить завдання;
8. departmentId: int – ідентифікатор відділу, до якого належить завдання.
Методи:
1. addComment(comment: Comment) – метод для додавання коментаря до
завдання;
2. viewTask() – метод для перегляду інформації про завдання;
3. editTask() – метод для редагування інформації про завдання;
4. deleteTask() – метод для видалення завдання;
5. changeDeadline(deadline: Date) – метод для зміни дати завершення завдання;
6. assignToDepartment(department: Department) – метод для призначення
завдання до відділу.
7. addAttachment(attachment: Attachment) – метод, який би відповідав за логіку
прикріплення файлу до завдання.
61
8. removeAttachment(attachment: Attachment) – метод для видалення
прикріпленого файлу.
9. getAttachments() – метод для отримання списку всіх об'єктів Attachment,
пов'язаних з даним завданням.
Клас TaskAssignment
Атрибути:
1. id: int – унікальний ідентифікатор призначення завдання;
2. taskId: int – ідентифікатор завдання, на яке призначено користувача;
3. userId: int – ідентифікатор користувача, призначеного на завдання.
Клас Comment
Атрибути:
1. id: int – унікальний ідентифікатор коментаря;
2. text: String – текст коментаря;
3. creationDate: Date – дата створення коментаря;
4. authorId: int – ідентифікатор користувача, який залишив коментар;
5. taskId: int – ідентифікатор завдання, до якого належить коментар.
Методи:
1. editComment() – метод для редагування коментаря;
2. deleteComment() – метод для видалення коментаря.
Клас Attachment
Атрибути:
1. id: int – унікальний ідентифікатор вкладення;
2. taskId: int – ідентифікатор завдання, до якого належить вкладення;
3. fileName: String – оригінальна назва файлу;
4. filePath: String – шлях до файлу на сервері;
5. uploadDate: DateTime – дата та час завантаження файлу;
6. fileSize: Long – розмір файлу в байтах;
7. fileType: String – MIME-тип файлу.
62
Клас Department
Атрибути:
1. id: int – унікальний ідентифікатор відділу;
2. name: String – назва відділу;
3. description: String – опис відділу.
Методи:
viewDepartment() – метод для перегляду інформації про відділ.
Клас UserDepartment
Атрибути:
1. id: int – унікальний ідентифікатор запису про призначення користувача до
відділу;
2. userId: int – ідентифікатор користувача;
3. departmentId: int – ідентифікатор відділу.
Існує сутність Користувач (User), яка представляє людину, що працює з
системою. Один користувач може бути пов'язаний з одним або кількома відділами
(Department). Зв'язок типу «багато до багатьох» реалізований через проміжний клас
UserDepartment, де кожен запис фіксує належність конкретного користувача до
певного відділу. Таким чином, користувач може мати кілька таких записів, а відділ –
містити багато пов'язаних користувачів.
Користувач також може бути членом однієї або кількох команд (Team). Цей
зв'язок також є «багато до багатьох» і реалізується через клас TeamMember. Запис у
TeamMember вказує на членство користувача в конкретній команді. У складі команди
має бути щонайменше один учасник, та одна особа може входити до кількох команд.
Кожна команда може працювати над одним або кількома проєктами (Project), і
кожен з них належить лише одній команді.
Проєкт може містити нуль або більше завдань (Task). Завдання завжди
прив'язане до одного проєкту.
Крім того, кожне завдання обов’язково належить до певного відділу. Відділ
63
може включати будь-яку кількість пов'язаних завдань. Також для кожного завдання
обов’язковою є наявність одного або кількох виконавців (User). Це відображається
через проміжний клас TaskAssignment, де фіксується призначення конкретної особи
на конкретне завдання. Кожне завдання може мати нуль або більше вкладень
(Attachment).
До завдання може бути додано нуль або більше коментарів (Comment). Кожен
з них належить одному завданню і створений певним користувачем. Один користувач
може залишати коментарі до різних завдань.
2.4 Архітектурне проєктування інформаційної системи
Архітектурне проєктування системи є важливим етапом у розробці
програмного забезпечення. На цьому етапі визначаються основні структурні
елементи системи та способи їх взаємодії для досягнення поставлених цілей. Метою
архітектурного проєктування є створення надійної, масштабованої, ефективної та
безпечної системи, яка відповідатиме вимогам замовника і користувачів.
Основні принципи архітектурного проєктування:
1. Архітектура повинна забезпечувати можливість масштабування системи в
разі збільшення кількості користувачів або обсягу даних.
2. Система повинна включати механізми для захисту даних, такі як
шифрування, аутентифікація та авторизація користувачів.
3. Компоненти системи мають бути незалежними один від одного, щоб можна
було легко змінювати окремі частини системи без впливу на інші.
2.4.1 Загальна архітектура інформаційної системи
Загальна архітектура системи є основою для її проєктування. Вона визначає
основні компоненти, їхні функції та як вони взаємодіють. Веб-орієнтована
інформаційна система для управління завданнями має бути побудована таким чином,
щоб забезпечити ефективне управління завданнями та проєктами, зручний доступ для
користувачів та можливість масштабування для підтримки розширення функціоналу
64
в майбутньому.
Архітектура веб-орієнтованої системи базується на клієнт-серверній моделі з
трирівневою структурою, у межах якої клієнтська частина взаємодіє із серверною
через API.
Основні рівні архітектури:
1. Клієнтський рівень (фронтенд)
надає інтерфейс користувача для взаємодії із системою;
отримує дані з серверної частини та відображає їх у зручному форматі;
передає запити на обробку операцій (створення, редагування,
видалення завдань) до серверної частини через API;
2. Серверний рівень (бекенд)
виконує бізнес-логіку системи, обробляє запити від користувачів;
реалізує механізми автентифікації та авторизації користувачів;
взаємодіє з базою даних для збереження та отримання інформації;
3. Рівень зберігання даних (база даних)
містить інформацію про користувачів, проєкти, завдання, коментарі та
інші елементи;
організовує безпечне збереження даних та забезпечує їхню цілісність.
Взаємодія між рівнями системи відбувається наступним чином:
1. Користувач вводить дані у веб-інтерфейсі та відправляє запит.
2. Клієнтська частина (фронтенд) передає запит на сервер через API.
3. Серверна частина (бекенд) обробляє запит, виконує бізнес-логіку та
звертається до бази даних.
4. База даних отримує та зберігає необхідні дані.
5. Серверна частина формує відповідь та передає її на клієнтську частину.
6. Користувач отримує оновлену інформацію в інтерфейсі.
65
2.4.2 Склад компонентів інформаційної системи та їх функцій
Веб-орієнтована інформаційна система для управління завданнями є складною
системою, яка складається з кількох взаємопов'язаних компонентів. Кожен
компонент виконує свою роль у забезпеченні функціональності системи. Основні
компоненти включають інтерфейс користувача, сервер, сервіси управління
завданнями та проєктами, сервіс автентифікації, а також сховище даних.
Інтерфейс користувача є основним засобом взаємодії користувачів із системою.
Він реалізується у вигляді веб-додатка, що надає доступ до функціоналу системи
через браузер, та призначений для відображення даних, отриманих від серверної
частини, а також для обробки дій користувача, пов'язаних з управлінням завданнями
та проєктами. Інтерфейс користувача відповідає за візуалізацію списку завдань та
проєктів, відображення деталей та інформації про них, а також за надання форм для
введення та редагування даних. Крім того, він надає необхідний інтерфейс для
процедури автентифікації користувачів.
Сервер забезпечує обробку запитів від інтерфейсу користувача та координує
взаємодію між іншими компонентами. Він здійснює маршрутизацію HTTP-запитів,
передаючи їх відповідним компонентам, та забезпечує обмін даними у форматі JSON.
Сервер відповідає за реалізацію бізнес-логіки, контроль авторизації користувачів,
управління доступом до ресурсів та взаємодію з базою даних для збереження й
отримання інформації.
Сервіс управління завданнями відповідає за управління завданнями в системі.
Він реалізує бізнес-логіку, пов'язану з завданнями, та забезпечує виконання таких
операцій, як створення, редагування, оновлення та видалення завдань. Сервіс зберігає
інформацію про кожне завдання, включаючи його назву, опис, статус, пріоритет,
дедлайн, виконавців та коментарі, а також відповідає за перевірку прав доступу до
завдань та забезпечення цілісності даних.
Сервіс управління проєктами забезпечує можливість створення,
адміністрування та організації проєктів, до яких прив'язуються завдання. Він
забезпечує функціональність для організації завдань в рамках проєктів, планування
66
етапів проєкту, встановлення термінів виконання завдань та відстеження прогресу
виконання проєкту.
Сервіс автентифікації забезпечує реєстрацію, вхід у систему та розподіл ролей
користувачів, контролюючи їхні права доступу. Він перевіряє облікові дані, видає
токени для авторизації та визначає, які можливості доступні кожному користувачеві,
обмежуючи доступ до функцій системи для неавторизованих осіб.
Сховище даних відповідає за збереження та отримання даних. Цей компонент
реалізує базу даних, яка зберігає дані про завдання, проєкти, користувачів та інші
сутності системи. Сховище даних забезпечує постійне зберігання даних та надає
інтерфейс для доступу до даних з інших компонентів системи.
Сховище даних забезпечує зберігання всієї інформації про користувачів,
проєкти, завдання та інші об’єкти системи. Воно реалізоване у вигляді реляційної
бази даних, що забезпечує структуроване зберігання та ефективний доступ до даних.
Сховище забезпечує постійне зберігання інформації та надає інтерфейс для доступу
до неї з інших компонентів системи, дозволяючи виконувати базові операції
(створення, читання, оновлення, видалення) над даними.
2.4.3 Діаграма компонентів інформаційної системи
Діаграма компонентів – це діаграма, яка відображає архітектуру системи на
рівні компонентів та їх взаємозв’язків. Вона зображає компоненти, як вони
взаємодіють між собою, які інтерфейси вони надають та використовують [14].
Діаграма компонентів веб-орієнтованої інформаційної системи для управління
завданнями представлена на рисунку 2.4.
67
Рисунок 2.4 – Діаграма компонентів веб-орієнтованої інформаційної системи для
управління завданнями
Компоненти:
1. User Interface – клієнтський веб-інтерфейс, який надає користувачам
можливість взаємодіяти з системою через веб-браузер. Він реалізує
графічний інтерфейс, відображаючи дані та обробляючи дії користувача.
2. Application Server – серверний компонент, який обробляє запити від
інтерфейсу користувача та взаємодіє з іншими серверними сервісами.
3. Task Management Service – серверний компонент, який відповідає за
управління завданнями: створення, редагування, видалення тощо.
68
4. Project Management Service – серверний компонент, який відповідає за
управління проєктами: створення, редагування, видалення тощо.
5. Data Storage – компонент, який відповідає за збереження та отримання
даних.
6. Authentication Service – серверний компонент, який відповідає за
автентифікацію та авторизацію користувачів.
Інтерфейси:
1. Інтерфейс HTTP API надається компонентом Application Server та
використовується компонентом User Interface. Через цей інтерфейс
обробляються HTTP-запити, що надходять від клієнтського інтерфейсу. Він
забезпечує виконання таких дій, як отримання списку завдань, їх створення,
оновлення та видалення. Application Server приймає запити у форматі JSON
та повертає відповіді в такому ж форматі, щоб забезпечити узгоджений
обмін даними між клієнтом і сервером.
2. Надається компонентом Task Management Service та використовується
компонентами User Interface, Application Server та Project Management
Service. Цей інтерфейс відповідає за управління завданнями в системі. Через
нього виконуються операції з управління завданнями. Клієнтський
інтерфейс звертається до цього API, щоб відображати список завдань,
створювати, редагувати й видаляти їх. Application Server використовує цей
API для обробки запитів від клієнтського інтерфейсу та взаємодії із сервісом
управління завданнями. Project Management Service використовує цей API
для отримання завдань, що входять до складу проєкту. Дані передаються у
форматі JSON.
3. Надається компонентом Project Management Service та використовується
компонентами User Interface та Application Server. Цей інтерфейс відповідає
за управління проєктами в системі. Через нього виконуються операції з
управління проєктами. Клієнтський інтерфейс звертається до цього API, щоб
відображати список проєктів, створювати, редагувати й видаляти їх.
Application Server використовує цей API для обробки запитів від
69
клієнтського інтерфейсу та взаємодії із сервісом управління проєктами. Дані
передаються у форматі JSON.
4. Надається компонентом Data Storage і використовується компонентами
Application Server, Task Management Service та Project Management Service.
Цей інтерфейс забезпечує доступ до даних, що зберігаються в базі даних.
Application Server використовує цей API для отримання та збереження даних,
необхідних для обробки запитів з користувацького інтерфейсу. Task
Management Service застосовує цей API для збереження та отримання даних,
пов'язаних із завданнями. Project Management Service застосовує цей API для
збереження та отримання даних, пов'язаних з проєктами.
5. Надається компонентом Authentication Service і використовується
компонентами User Interface, Application Server, Task Management Service та
Project Management Service для автентифікації та авторизації користувачів.
User Interface використовує цей API для входу користувача в систему.
Application Server використовує цей API для перевірки авторизації
користувачів, які надсилають запити. Task Management Service використовує
цей API для перевірки прав доступу користувачів до завдань. Project
Management Service використовує цей API для перевірки прав доступу
користувачів до проєктів.
2.4.4 Діаграма розгортання інформаційної системи
Діаграма розгортання в UML використовується для візуалізації фізичної
архітектури програмної системи на етапі її розгортання. Вона відображає розміщення
програмних компонентів – серверів, процесорів, пристроїв зберігання даних – на
фізичних вузлах, та як вони взаємодіють між собою через мережеве з’єднання [15].
На рисунку 2.5 представлено загальну діаграму розгортання веб-орієнтованої
інформаційної системи.
70
Рисунок 2.5 – Діаграма розгортання веб-орієнтованої інформаційної системи
для управління завданнями
1. Web Server – сервер, на якому розміщено веб-застосунок. Він відповідає за
обробку користувацьких запитів та передачу необхідних даних між клієнтом
та сервером бази даних. На цьому сервері розгорнуто компонент Website,
який містить логіку веб-інтерфейсу та надає користувачам доступ до
функціоналу системи. Взаємодія з клієнтами відбувається через протокол
HTTP на порту 80.
2. UserClient – клієнтський пристрій, який використовується для взаємодії з
веб-застосунком. На ньому працює компонент Browser, що забезпечує
візуалізацію веб-інтерфейсу та відображення веб-сторінок. У браузері
виконується артефакт HTML5, який містить основні компоненти
користувацького інтерфейсу. Через браузер користувач підключається до
Web Server для отримання веб-сторінок та передачі своїх запитів.
3. DB Server – сервер бази даних, який забезпечує збереження та управління
даними. На ньому розгорнуто компонент MySQL DB, який
71
використовується для організації бази даних та обробки запитів від веб-
сервера. У базі даних зберігається вся інформація, включаючи дані
користувачів, записи транзакцій та інші важливі елементи веб-застосунку.
2.5 Моделювання поведінки інформаційної системи. Діаграма діяльності
Моделювання поведінки системи – це процес опису та аналізу динаміки роботи
системи. Він включає створення моделей проєктованої системи, які дозволяють
зрозуміти, як система виконує свої функції, як взаємодіє з іншими елементами та
зовнішнім середовищем, а також як її компоненти реагують на різні вхідні дані та
змінювані умови. Завдяки моделюванню поведінки системи можна передбачити
відхилення від очікуваної поведінки при введенні даних, виявити неефективні
процеси та усунути можливі логічні помилки, щоб підвищити ефективність роботи
системи.
Для моделювання поведінки системи зазвичай використовуються діаграми
станів, діаграми активності та діаграми послідовностей, оскільки вони дозволяють
візуалізувати зміну станів системи, послідовність виконання процесів, взаємодію між
компонентами та передбачати її поведінку в різних умовах. У цьому пункті
розглянуто діаграму діяльності як метод моделювання поведінки системи.
Діаграма діяльності в UML є поведінковим типом діаграми, що
використовується для візуалізації потоку діяльності в системі. Вона ілюструє
послідовність операцій або активностей, які необхідно виконати для досягнення
певної мети, і описує процеси, робочі потоки та взаємодії елементів системи. Діаграма
діяльності допомагає зрозуміти порядок виконання дій та взаємозв'язки між ними.
[16].
Діаграми діяльності, що демонструють поведінку системи, представлено на
рисунках 2.6-2.14.
72
Рисунок 2.6 – Діаграма діяльності для процесу реєстрації користувача у системі
73
Діаграма діяльності для реєстрації користувача, зображена на рисунку 2.6,
описує процес реєстрації нового користувача в системі управління завданнями з
точки зору користувача та системи. Процес розпочинається з того, що користувач
відкриває реєстраційну форму та заповнює необхідні поля. Після введення даних
користувач натискає кнопку «Зареєструватися», ініціюючи передачу інформації
системі.
Система отримує введені дані та перевіряє їх на коректність. Якщо дані
некоректні, користувач отримує повідомлення про помилку та повертається до етапу
заповнення реєстраційної форми для виправлення помилок. Якщо введені дані є
коректними, система реєструє нового користувача в системі.
Після реєстрації система спрямовує користувача на сторінку вибору відділів.
Користувач обирає від одного до трьох відділів, до яких він хоче належати, та
підтверджує свій вибір. Система перевіряє кількість обраних відділів. Якщо
користувач не обрав жодного або обрав більше трьох відділів, система відображає
повідомлення про помилку, і користувач повертається до етапу вибору відділів. Якщо
кількість обраних відділів знаходиться в межах від одного до трьох, система здійснює
прив’язку новоствореного користувача до цих відділів. Після збереження вибраних
відділів система спрямовує користувача на головну сторінку системи – дашборд.
Процес реєстрації завершується.
Діаграма діяльності для створення команди, зображена на рисунку 2.7, описує
процес створення нової команди в системі з точки зору користувача та системи.
Процес починається з того, що користувач натискає кнопку «Створити команду». У
формі для додавання нової команди користувач вводить назву та опис команди (за
бажанням), а також обирає учасників, яких хоче додати до нової команди. Після
введення назви, опису та вибору учасників користувач подає введені дані системі на
перевірку. Система перевіряє коректність поданих даних: наявність назви команди та
вибір хоча б одного учасника. Якщо дані некоректні, користувач отримує
повідомлення про помилку та повертається до введення даних. Якщо дані коректні,
система створює команду, зберігаючи введену назву, опис та обраних учасників у базі
даних, та автоматично призначає менеджера команди. Система відображає
74
повідомлення про успішне створення команди, а користувач отримує підтвердження.
Процес створення команди завершується.
Рисунок 2.7 – Діаграма діяльності для процесу створення команди
75
Рисунок 2.8 – Діаграма діяльності для процесу створення нового проєкту
Діаграма діяльності для створення проєкту, зображена на рисунку 2.8, описує
процес створення нового проєкту менеджером у системі. Процес починається з того,
що менеджер обирає команду та натискає кнопку «Створити проєкт». У формі для
76
додавання нового проєкту менеджер вводить дані, такі як назва, опис та дати
виконання проєкту. Введені дані проєкту подаються на перевірку системі. Система
перевіряє коректність поданих даних, і якщо дані некоректні, то менеджер отримує
повідомлення про помилку та має виправити їх. Якщо дані коректні, система створює
проєкт, зберігаючи запис про проєкт та його терміни виконання у базі даних, та
відображає повідомлення про створення проєкту. Менеджер отримує підтвердження,
що проєкт створений, і процес завершується.
Діаграма діяльності для створення завдання, зображена на рисунку 2.9, описує
процес створення нового завдання менеджером у рамках конкретного проєкту.
Процес розпочинається з того, що менеджер обирає проєкт та натискає кнопку
«Створити завдання». У формі для додавання нового завдання менеджер вводить
дані, такі як назва завдання, опис та термін виконання. Далі менеджер обирає відділ,
до якого буде належати це завдання, а потім призначає одного або кількох виконавців,
які належать до обраного відділу, відповідальних за виконання цього завдання. Після
цього менеджер має можливість додати вкладення до завдання. Після додавання
вкладення (або пропускаючи цей крок) менеджер подає введені дані системі.
Система отримує введені дані та послідовно перевіряє їх коректність. Спочатку
перевіряються основні дані завдання (назва, опис, термін виконання). Якщо виявлено
некоректні дані, менеджер отримує повідомлення про помилку та повертається до
введення даних. Якщо основні дані коректні, система перевіряє, чи було обрано
відділ. Якщо відділ не обрано, менеджер отримує повідомлення про необхідність
обрання відділу та повертається до введення даних. Далі система перевіряє, чи було
призначено хоча б одного виконавця. Якщо виконавця не призначено, менеджер
отримує повідомлення про необхідність призначення виконавця та повертається до
введення даних.
Якщо всі дані заповнено коректно, обрано відділ і призначено хоча б одного
виконавця, система зберігає параметри завдання. Після збереження параметрів
система створює запис завдання та відображає повідомлення про створення завдання.
Менеджер отримує підтвердження створення завдання, і процес завершується.
77
Рисунок 2.9 – Діаграма діяльності для процесу створення завдання у проєкті
78
Рисунок 2.10 – Діаграма діяльності для процесу редагування проєкту
Діаграма діяльності для редагування проєкту, зображена на рисунку 2.10,
описує процес редагування проєкту менеджером. Процес починається з того, що
менеджер обирає проєкт для редагування та відкриває форму редагування проєкту.
Далі менеджер редагує дані проєкту. Після редагування даних менеджер подає їх
системі. Система перевіряє коректність поданих даних, і якщо дані некоректні,
менеджер отримує повідомлення про помилку та повинен виправити їх. Якщо дані
79
коректні, система зберігає зміни проєкту та відображає повідомлення про оновлення
даних проєкту. Менеджер отримує підтвердження, що проєкт відредаговано. Процес
завершується.
Рисунок 2.11 – Діаграма діяльності для процесу редагування завдання
80
Діаграма діяльності для редагування завдання, зображена на рисунку 2.11,
описує процес редагування завдання менеджером у рамках конкретного проєкту.
Процес розпочинається з того, що менеджер обирає проєкт та завдання для
редагування. Менеджер відкриває форму редагування завдання та вносить необхідні
зміни до основних даних завдання (назва, опис, термін виконання). Далі менеджер
має можливість змінити відділ, до якого належить завдання, а також призначити,
додати або видалити виконавців, відповідальних за виконання цього завдання.
Менеджер також може додати або видалити вкладення до завдання. Після
редагування даних менеджер подає їх на перевірку системі.
Система отримує відредаговані дані та послідовно перевіряє їх коректність.
Спочатку перевіряються основні дані завдання. Якщо виявлено некоректні дані,
менеджер отримує повідомлення про помилку та повертається до редагування даних
завдання. Якщо основні дані коректні, система перевіряє, чи обрано відділ. Якщо
відділ не обрано, менеджер отримує повідомлення про необхідність обрання відділу
та повертається до вибору відділу. Далі система перевіряє, чи призначено хоча б
одного виконавця. Якщо виконавця не призначено, менеджер отримує повідомлення
про необхідність призначення виконавця та повертається до призначення виконавців.
Якщо всі дані пройшли перевірку (основні дані коректні, обрано відділ та
призначено хоча б одного виконавця), система зберігає внесені зміни до завдання.
Після збереження змін система відображає повідомлення про оновлення даних
завдання. Менеджер отримує підтвердження, що завдання відредаговано, і процес
завершується.
Діаграма діяльності для видалення проєкту, зображена на рисунку 2.12, описує
процес видалення проєкту менеджером. Менеджер обирає проєкт, який потрібно
видалити, та відкриває форму видалення проєкту. Далі менеджер підтверджує своє
рішення видалити проєкт. Система запитує підтвердження видалення. Якщо
менеджер підтверджує видалення, система видаляє проєкт та відображає
повідомлення про успішне видалення проєкту. Якщо менеджер скасовує видалення,
процес завершується без видалення проєкту. Після видалення проєкту менеджер
отримує підтвердження, що проєкт було видалено. Процес завершується.
81
Рисунок 2.12 – Діаграма діяльності для процесу видалення проєкту
82
Рисунок 2.13 – Діаграма діяльності для процесу видалення завдання
83
Діаграма діяльності для видалення завдання, зображена на рисунку 2.13, описує
процес видалення завдання менеджером. Процес починається з того, що менеджер
обирає проєкт, а в межах проєкту – завдання для видалення. Після цього менеджер
відкриває форму видалення завдання та підтверджує своє рішення видалити завдання.
Система запитує підтвердження видалення. Якщо менеджер підтверджує видалення,
система видаляє завдання та відображає повідомлення про успішне видалення
завдання. Якщо менеджер скасовує видалення, процес завершується без видалення
завдання. Після успішного видалення завдання менеджер отримує підтвердження, що
завдання було видалено, і процес завершується.
Рисунок 2.14 – Діаграма діяльності для процесу додавання коментаря до завдання
84
Висновки до розділу 2
У другому розділі було проведено комплексне проєктування веб-орієнтованої
інформаційної системи. Розділ охоплює аналіз вимог, моделювання предметної
області, проєктування логічної структури, архітектурне проєктування та
моделювання поведінки системи.
На першому етапі здійснено аналіз вимог до системи. Було визначено основні
категорії користувачів та їхні ролі в системі. Далі було сформульовано функціональні
та нефункціональні вимоги, які описують основні можливості системи, її
продуктивність, безпеку, масштабованість та зручність використання. Для наочного
представлення взаємодії користувачів із системою було розроблено діаграму
прецедентів.
На етапі моделювання предметної області визначено основні об’єкти системи,
їхні характеристики та зв’язки між ними. Для графічного представлення структури
даних створено діаграму «сутність-зв’язок», яка відображає логічні взаємозв’язки між
елементами.
Розглянуто логічну структуру системи, де визначено основні класи, їхні
атрибути, методи та зв’язки між ними. Побудовано діаграму класів, яка описує
статичну структуру об’єктів у системі та їхню взаємодію.
На етапі архітектурного проєктування розроблено загальну архітектуру
системи, визначено її основні компоненти та їхні функції. Для візуалізації
архітектурних рішень створено діаграму компонентів, що відображає модулі системи
та їхні взаємозв’язки, та діаграму розгортання, яка визначає фізичне розташування
компонентів у середовищі виконання.
Останнім етапом стало моделювання поведінки системи, у межах якого було
побудовано діаграми діяльності для процесів створення команди, створення проєкту,
створення завдання, редагування проєкту, редагування завдання, додавання
коментаря до завдання, видалення проєкту та видалення завдання. Створені діаграми
діяльності відображають послідовність дій користувачів і системи, основні
розгалуження процесів та умови їх виконання.
85
3 РОЗРОБКА ВЕБ-ОРІЄНТОВАНОЇ ІНФОРМАЦІЙНОЇ СИСТЕМИ
3.1 Вибір та обґрунтування технологій розробки інформаційної системи
Перед початком розробки веб-орієнтованої інформаційної системи для
управління завданнями при розробці IT-продуктів було проаналізовано сучасні
інструменти та технології, які дозволяють забезпечити ефективну реалізацію
функціональних вимог, стабільність роботи, масштабованість та зручність у
підтримці. Вибір технологій базувався на їх відповідності сучасним стандартам веб-
розробки, рівні підтримки спільнотою, продуктивності, а також можливості легко
поєднувати їх між собою.
Для створення клієнтської частини системи було обрано HTML, CSS та
JavaScript – основні веб-технології, які дозволяють розробити адаптивний та
інтерактивний інтерфейс користувача.
HTML відповідає за структуру вмісту сторінки. У поєднанні з CSS він дає змогу
оформити інтерфейс згідно з вимогами сучасного дизайну, зробити його зручним для
сприйняття й візуально привабливим. JavaScript використовується для реалізації
інтерактивних елементів, обробки подій на стороні клієнта, перевірки введених даних
та динамічної взаємодії з серверною частиною. Завдяки цьому інтерфейс працює
швидше та зручніше для користувача, оскільки оновлення вмісту сторінки
відбувається без її повного перезавантаження.
Для реалізації серверної частини системи було обрано Node.js. Це популярне
середовище виконання JavaScript з відкритим вихідним кодом, яке забезпечує високу
продуктивність завдяки асинхронній обробці запитів. Основною перевагою Node.js є
використання JavaScript як на клієнтській, так і на серверній частинах, що спрощує
розробку й покращує взаємодію між компонентами системи. Крім того, у Node.js є
багато готових бібліотек, які можна легко підключити через менеджер пакетів npm.
Для організації маршрутизації запитів та обробки HTTP-звернень використовується
фреймворк Express.js. Це гнучкий та добре документований інструмент, який
пришвидшує процес розробки та дозволяє чітко структурувати логіку застосунку.
86
Для зберігання та обробки даних у межах розроблюваної системи обрано
систему управління базами даних MySQL. Це реляційна СУБД з відкритим вихідним
кодом, яка характеризується стабільністю та високою продуктивністю. Вона є досить
поширеною у веб-розробці. Для візуального проєктування бази даних,
адміністрування сервера та виконання SQL-запитів використовуватиметься
інструмент MySQL Workbench. Інструмент MySQL Workbench є графічним
середовищем розробки, яке спрощує проєктування, створення, адміністрування та
візуалізацію баз даних MySQL.
У якості середовища розробки було обрано редактор коду Visual Studio Code.
Це зручне, безкоштовне і кросплатформне середовище, яке підтримує всі технології,
що використовуються в проєкті. Visual Studio Code має функції автодоповнення,
підсвічування синтаксису та перевірки помилок у реальному часі, що допомагає
швидше писати код та зменшує кількість помилок. Вбудований термінал та інтеграція
з Git дозволяють працювати без перемикання між різними програмами. Редактор
стабільно працює навіть з великими проєктами, тому підходить для створення
сучасних вебзастосунків.
Обрані інструменти є надійними, зручними у використанні та підтримуються
всіма сучасними браузерами. Це робить їх оптимальними для використання у
розробці веб-орієнтованої інформаційної системи для управління завданнями.
3.2 Розробка клієнтської частини інформаційної системи
Інтерфейс клієнтської частини створено з акцентом на простоту та зручність.
Основна мета – зробити навігацію зрозумілою для нових користувачів і не
перевантажувати екран зайвими елементами. Було обрано світлу кольорову гаму з
м’якими градієнтами та шрифт Poppins для створення сучасного та простого вигляду
(рис. 3.1).
87
Рисунок 3.1 – Головна сторінка веб-орієнтованої інформаційної системи для
управління завданнями
Усі елементи інтерфейсу поділено на окремі блоки – вкладки, кожна з яких
відповідає за свою функцію: перегляд завдань, керування командою, створення
проєктів тощо. Така структура полегшує масштабування системи та дає змогу
адаптувати її під різні ролі користувачів.
Однією з важливих особливостей є динамічна адаптація інтерфейсу залежно від
статусу користувача. Компоненти інтерфейсу змінюються залежно від того, чи є
користувач новим, поки не належить до жодної з команд, чи вже є учасником якоїсь
команди. За замовчуванням користувач вважається новим, тому при реєстрації (рис.
3.2) чи першій авторизації (рис. 3.3) або у випадку, якщо раніше не було обрано
відділи, на сторінці дашборду з’являється модальне вікно з пропозицією вибрати від
одного до трьох відділів (рис. 3.4).
88
Рисунок 3.2 – Сторінка реєстрації
Рисунок 3.3 – Сторінка входу до системи
89
Рисунок 3.4 – Модальне вікно вибору відділів на сторінці дашборду
Після вибору система повідомляє про успішне збереження даних та пропонує
перейти до наступного етапу – приєднатися до команди або створити власну (додаток
Г, рис. Г.1).
У разі натискання кнопки «Приєднатися» користувача перенаправляє на
сторінку команд у режимі стану «користувач без команди» (рис. 3.5), де він може
ввести унікальний код команди для приєднання. Якщо користувач обирає варіант
створення нової команди, його також перенаправляє на сторінку команд, але одразу
відкриється форма створення команди (додаток Г, рис. Г.2). У ній потрібно вказати
назву команди та (опціонально) її опис. Після створення команди з’являється
можливість запрошення інших користувачів у вікні керування командою.
90
Рисунок 3.5 – Сторінка команд для користувача без команди
Після приєднання до команди чи створення власної, сторінка «Команди»
оновлюється відповідно до нового стану користувача. На ній з’являються картки
команд, що містять основну інформацію: назву, опис, кількість учасників, кількість
проєктів у команді та спеціальну позначку, якщо користувач є менеджером команди
(рис. 3.6). Якщо користувач був виключений з усіх команд, картки будуть відсутні,
але інші елементи сторінки залишаються доступними.
Рисунок 3.6 – Сторінка команд: стан користувача у команді
91
У верхній частині екрана, по центру, розташовано поле пошуку для зручного
пошуку команд за назвою. Внизу сторінки є кнопки «Назад» та «Вперед», які
з’являються при наявності великої кількості карток. У правому нижньому куті
розміщено дві кнопки: «Створити нову команду» та «Приєднатися за кодом»,
натискання на які відкриває відповідні модальні вікна.
Картка команди, яку бачить користувач, відображає його роль. Якщо
користувач є творцем або призначеним менеджером команди, на картці вказано
позначку «Менеджер», з’являється кнопка «Керувати», а також кнопка «Редагувати»
у правому верхньому куті. Натискання на останню відкриває вікно редагування назви
та опису команди, аналогічне до того, що доступне у вікні керування.
Вікно керування командою складається з кількох вкладок. Перша – «Учасники»
– відображає список усіх учасників команди з відповідними іменами, аватаром,
електронною поштою та роллю (додаток Г, рис. Г.3). Тут менеджер команди може
змінювати ролі учасників або виключати їх. Система передбачає два рівні
менеджерів: творець команди та менеджери, призначені творцем. Призначені
менеджери можуть видаляти звичайних учасників, але не мають права призначати
нових менеджерів або видаляти чинних. Також менеджери не можуть виключити
творця. Друга вкладка – «Інформація» – містить основні відомості про команду: її
назву та опис (додаток Г, рис. Г.4). Ці поля можна редагувати, якщо користувач є
творцем команди або призначеним менеджером. Вкладка «Запрошення» надає доступ
до двох основних функцій: «Отримати код запрошення» та «Запросити за email».
Перша функція відкриває вікно з унікальним кодом запрошення, який користувач
може скопіювати за допомогою відповідної кнопки (додаток Г, рис. Г.5). Друга –
відображає форму для введення одного або кількох email-адрес (через кому), а також,
за потреби, тексту запрошення (додаток Г, рис. Г.6). Вкладка «Додатково» (додаток
Г, рис. Г.7) містить функцію видалення команди. Після натискання кнопки «Видалити
команду» відкривається модальне вікно з попередженням про незворотність дії
(додаток Г, рис. Г.8). Після підтвердження команда остаточно вилучається із системи.
Ця функція доступна виключно творцеві команди.
92
Сторінка проєктів (рис. 3.7) призначена для відображення всіх проєктів, що
належать до конкретної команди. Якщо у команді ще не створено жодного проєкту,
на сторінці відображається повідомлення «Немає проєктів у цій команді» (додаток Г,
рис. Г.9). У верхній частині інтерфейсу розташована кнопка «Додати проєкт»,
натискання на яку відкриває модальне вікно створення нового проєкту (додаток Г,
рис. Г.10). У цьому вікні користувач може вказати назву, опис та кінцеву дату
реалізації проєкту. Поле з описом є необов’язковим для заповнення. Після
підтвердження введених даних новий проєкт додається до загального списку на
сторінці й автоматично отримує статус «Новий», що відображається за допомогою
жовтої позначки. Кнопка «Назад до команд», що знаходиться поряд зі шляхом, веде
назад на сторінку команд користувача.
Рисунок 3.7 – Сторінка проєктів команди
На кожній картці проєкту розміщено кнопки редагування та видалення у
вигляді іконок (додаток Г, рис. Г.11). Після натискання кнопки редагування
відкривається модальне вікно, де можна змінити дані проєкту (додаток Г, рис. Г.12).
Зміни зберігаються після натискання кнопки «Зберегти зміни», і оновлена інформація
одразу відображається на сторінці. Кнопка видалення відкриває модальне вікно з
підтвердженням (додаток Г, рис. Г.13). Якщо користувач підтверджує дію, проєкт
видаляється, а список карток оновлюється. Редагування доступне лише
користувачам, які мають роль менеджера в команді, а видаляти проєкти може тільки
93
творець команди. Якщо проєкт не було вручну переведено у відповідний статус до
завершення терміну, система автоматично позначає його як «Протерміновано».
Проєкти зі статусом «Протерміновано» або «Виконано» редагувати неможливо.
Для зручності користувачів на сторінці реалізовано фільтрацію проєктів. У
верхній частині розміщені кнопки для вибору статусу: «Усі», «Нові», «В процесі»,
«Виконано» та «Протерміновано» (додаток Г, рис. Г.14). Також доступний фільтр за
періодом активності: уся історія, за тиждень, за місяць або за три місяці (додаток Г,
рис. Г.15). Обидва фільтри можна використовувати одночасно, що дозволяє швидко
знаходити потрібні проєкти. Статуси мають кольорові позначки, які допомагають
візуально оцінити стан виконання проєкту: жовтий колір позначає нові проєкти, синім
кольором позначаються проєкти у процесі виконання, зеленим – виконані проєкти, а
червоним – протерміновані.
Сторінка завдань (рис. 3.8) призначена для управління процесом виконання
завдань у межах конкретного проєкту. У верхньому лівому куті розташована кнопка
«Назад до проєктів» та шлях до поточного розділу. У правому верхньому куті
знаходиться кнопка «Додати завдання», яка відкриває модальне вікно створення
нового завдання. Під заголовком розміщено поле пошуку для швидкого знаходження
завдань за назвою.
Рисунок 3.8 – Сторінка завдань системи
94
Основний простір сторінки поділено на чотири колонки відповідно до статусів
завдань: «В роботі», «На перевірці», «Виконано» та «Протерміновано». Перелік
завдань формується на основі відділів, обраних користувачем під час реєстрації.
Завдання на сторінці відображаються відповідно до відділів, обраних користувачем
при реєстрації. У звичайних учасників є вкладка «Усі відділи» та одна або кілька
вкладок із назвами відділів, до яких вони належать. Менеджери та творець команди
мають ширший доступ: окрім вкладки «Усі відділи», їм відображаються окремі
вкладки для кожного з відділів, до яких належать учасники команди. Наприклад,
якщо в команді є користувачі з відділів QA, Backend і Frontend, то менеджер і творець
команди бачитимуть три відповідні вкладки завдань. Учасники команди можуть
скористатися кнопкою «Тільки мої завдання» для перегляду лише призначених їм
завдань. Така функція недоступна для творця команди, оскільки йому не можуть бути
призначені завдання. Завдання також можна відфільтрувати за історією. У
випадаючому списку є варіанти: «Усі», «За тиждень», «За місяць», «За три місяці».
Кожне завдання представлено окремою карткою з інформацією про назву, опис,
відповідальних виконавців, відділ, кінцеву дату виконання. Пріоритет
встановлюється автоматично залежно від кількості днів до дедлайну: високий – за 1–
3 дні, середній – за 4–7, низький – якщо строк перевищує тиждень.
Редагування завдань доступне лише менеджерам. При натисканні на іконку
редагування відкривається вікно внесення змін до завдання (рис. 3.9). Видалення
можливе лише для творця команди. Завдання зі статусами «Виконано» та
«Протерміновано» не підлягають редагуванню, проте можуть бути видалені.
95
Рисунок 3.9 – Модальне вікно редагування завдання
Після натискання на картку завдання відкривається вікно перегляду (рис. 3.10),
де відображено детальну інформацію. Окрім основного статусу, завдання має статус
перевірки, який змінюється лише після прийняття або відхилення. Вікно перегляду
містить дві вкладки – «Коментарі» та «Вкладення». У вкладці коментарів менеджери,
виконавці та творець команди можуть залишати коментарі (додаток Г, рис. Г.16).
Кожен користувач має можливість видалити лише власні повідомлення. Коментарі
творця команди мають спеціальну позначку. На вкладці «Вкладення» (додаток Г, рис.
Г.17) розміщуються файли, необхідні для виконання завдання. Вкладення, додані
менеджером, не можуть бути змінені або видалені виконавцем, проте доступні для
96
завантаження. Виконавець, у свою чергу, може додавати власні файли перед здачею
завдання (додаток Г, рис. Г.18). Видалити ці вкладення може лише сам виконавець.
Рисунок 3.10 – Модальне вікно перегляду завдання
Коли завдання готове, виконавець може натиснути кнопку «Здати на
перевірку», яка з’являється у вікні перегляду для завдань зі статусом «В роботі».
Після цього статус змінюється на «На перевірці», і необхідно дочекатися рішення
менеджера або творця команди. Менеджер не може перевіряти завдання, призначене
самому собі – це може зробити інший менеджер або творець команди.
Для завдань зі статусом «На перевірці» менеджери та творець бачать кнопки
«Прийняти завдання» та «Відхилити завдання» (додаток Г, рис. Г.19). У разі
прийняття статус змінюється на «Виконано» (додаток Г, рис. Г.20). Якщо завдання
відхилено, воно повертається до статусу «В роботі» і залишається там до повторної
здачі або до закінчення терміну виконання. При відхиленні завдання менеджер може
вказати причину відхилення (додаток Г, рис. Г.26).
Сторінка профілю (рис. 3.11) відображає основну інформацію про користувача:
ім’я, аватар (за замовчуванням відсутній), локацію (за замовчуванням не вказана, але
може бути змінена), контактні дані – електронну пошту (визначається під час
реєстрації) та номер телефону (за замовчуванням також відсутній), а також перелік
відділів, до яких належить користувач.
97
Під час перегляду профілю іншого учасника команди відображається позначка
«онлайн» або час останньої активності, якщо користувач не в мережі (додаток Г, рис.
Г.21). У такому випадку доступний лише режим перегляду. При перегляді власного
профілю користувачеві надається можливість редагувати дані (додаток Г, рис. Г.22-
Г.25). На відміну від інших основних сторінок (дашборд, команди, проєкти,
завдання), сторінка профілю наразі не має повної адаптації під стан користувача.
Рисунок 3.11 – Сторінка профілю користувача
3.3 Розробка серверної частини інформаційної системи
3.3.1 Розробка структури бази даних інформаційної системи
Для забезпечення зберігання, цілісності та узгодженості даних у межах
розроблюваної інформаційної системи було спроєктовано реляційну базу даних. Вона
виконує роль централізованого сховища інформації, необхідної для повноцінного
функціонування системи управління завданнями при розробці IT-продуктів. База
даних зберігає відомості про користувачів, їхні облікові записи та ролі, організаційну
структуру (відділи, команди), проєкти, завдання, коментарі, файли, історію дій
користувачів тощо. Така структурованість забезпечує зручну організацію даних та їх
подальшу обробку, пошук, фільтрацію й аналіз.
98
Для забезпечення логічної цілісності та уникнення надмірностей у структурі
даних під час проєктування бази даних було застосовано принципи нормалізації.
Нормалізація – це підхід до аналізу структури таблиць бази даних на основі їх ключів
та функціональних залежностей. Вона передбачає застосування набору правил, які
дозволяють організувати таблиці так, щоб уникнути помилок і надлишковості даних.
Якщо таблиця не відповідає вимогам нормалізації, її розбивають на менші таблиці,
які задовольняють ці вимоги. [17].
Процес нормалізації є послідовним і складається з переходів між нормальними
формами, кожна з яких усуває певний тип залежності. Основними нормальними
формами є:
Перша нормальна форма (1НФ) означає, що всі поля містять лише прості,
неподільні значення, а таблиця не має повторюваних груп даних.
Друга нормальна форма (2НФ) вимагає, щоб кожен неключовий атрибут
залежав від усього первинного ключа, а не лише від його частини. Це
важливо, якщо ключ складається з кількох полів.
Третя нормальна форма (3НФ) передбачає, що неключові атрибути
залежать лише від первинного ключа, а не один від одного, тобто відсутні
транзитивні залежності [18].
Вищі нормальні форми, такі як нормальна форма Бойса-Кодда (BCNF), четверта
і п’ята нормальні форми, застосовуються для подальшого вдосконалення структури
бази даних. Вони допомагають усунути складні залежності та краще розподілити
таблиці. Дотримання принципів нормалізації підвищує надійність та ефективність
бази даних, зменшує ризик помилок і покращує загальну продуктивність системи.
Нижче наведено опис основних таблиць бази даних, що реалізують структуру
інформаційної системи (табл. 3.1 – 3.15).
99
Таблиця 3.1 – Сутність «Users»
Users
№ Назва Тип даних Обмеження Опис
Унікальний ідентифікатор
1 id int Первинний ключ
користувача
2 firstName varchar(100) NOT NULL Ім'я користувача
3 lastName varchar(100) NOT NULL Прізвище користувача
Унікальний, Адреса електронної
4 email varchar(255)
NOT NULL пошти користувача
5 password varchar(255) NOT NULL Пароль користувача
Дата реєстрації
6 registrationDate date NOT NULL
користувача
Дата та час останньої
7 lastActivity datetime
активності користувача
Статус користувача у
8 status varchar(50) NOT NULL системі (новий, без
команди, у команді тощо)
Таблиця 3.2 – Сутність «UserProfiles»
UserProfiles
№ Назва Тип даних Обмеження Опис
Первинний ключ, Ідентифікатор
1 UserId int
Зовнішній ключ користувача
Аватар користувача в
2 avatarPath text
форматі base64
Номер телефону
3 phoneNumber varchar(20)
користувача
Місто проживання
4 city varchar(100)
користувача
100
Країна проживання
5 country varchar(100)
користувача
Таблиця 3.3 – Сутність «Departments»
Departments
№ Назва Тип даних Обмеження Опис
Унікальний
1 id int Первинний ключ
ідентифікатор відділу
Унікальний, NOT
2 name varchar(100) Назва відділу
NULL
3 description text Опис відділу
Таблиця 3.4 – Сутність «UserDepartments»
UserDepartments
№ Назва Тип даних Обмеження Опис
Унікальний ідентифікатор
1 id int Первинний ключ
зв'язку
Зовнішній ключ, Ідентифікатор
2 userId int
NOT NULL користувача
Зовнішній ключ,
3 departmentId int Ідентифікатор відділу
NOT NULL
Таблиця 3.5 – Сутність «Teams»
Teams
№ Назва Тип даних Обмеження Опис
Унікальний
1 id int Первинний ключ
ідентифікатор команди
2 name varchar(100) NOT NULL Назва команди
3 description text Опис команди
101
4 creationDate date NOT NULL Дата створення команди
Унікальний, Код запрошення до
5 invitationCode varchar(255)
NOT NULL команди
Ідентифікатор
6 createdBy int Зовнішній ключ користувача, який
створив команду
Таблиця 3.6 – Сутність «TeamMembers»
TeamMembers
№ Назва Тип даних Обмеження Опис
Унікальний
1 id int Первинний ключ ідентифікатор учасника
команди
Зовнішній ключ, Ідентифікатор
2 userId int
NOT NULL користувача
Зовнішній ключ,
3 teamId int Ідентифікатор команди
NOT NULL
DEFAULT Позначка, чи є учасник
4 isManager boolean
FALSE менеджером
Таблиця 3.7 – Сутність «Projects»
Projects
№ Назва Тип даних Обмеження Опис
Унікальний ідентифікатор
1 id int Первинний ключ
проєкту
2 name varchar(100) NOT NULL Назва проєкту
3 description text Опис проєкту
4 creationDate date NOT NULL Дата створення проєкту
5 endDate date Дата завершення проєкту
102
6 status varchar(50) Статус проєкту
Зовнішній ключ, Ідентифікатор команди,
7 teamId int
NOT NULL до якої належить проєкт
Таблиця 3.8 – Сутність «Tasks»
Tasks
№ Назва Тип даних Обмеження Опис
Первинний Унікальний ідентифікатор
1 id int
ключ завдання
2 name varchar(100) NOT NULL Назва завдання
3 description text Опис завдання
4 status varchar(50) Статус завдання
5 creationDate date NOT NULL Дата створення завдання
6 deadline date Дата завершення завдання
Зовнішній
7 projectId int ключ, NOT Ідентифікатор проєкту
NULL
Зовнішній
8 departmentId int ключ, NOT Ідентифікатор відділу
NULL
Зовнішній Ідентифікатор
9 assignedBy int ключ, NOT користувача, який
NULL призначив завдання
10 reviewRequestedDate datetime Дата запиту на рецензію
Зовнішній
11 reviewerId int ключ, NOT Ідентифікатор рецензента
NULL
12 reviewStatus varchar(50) Статус рецензії
13 reviewDate datetime Дата рецензії
103
Причина відхилення
14 rejectionReason text
завдання
Таблиця 3.9 – Сутність «TaskAssignments»
TaskAssignments
№ Назва Тип даних Обмеження Опис
Унікальний ідентифікатор
1 id int Первинний ключ
призначення завдання
Зовнішній ключ,
2 taskId int Ідентифікатор завдання
NOT NULL
Ідентифікатор
Зовнішній ключ,
3 userId int користувача, якому
NOT NULL
призначено завдання
Таблиця 3.10 – Сутність «Comments»
Comments
№ Назва Тип даних Обмеження Опис
Унікальний ідентифікатор
1 id int Первинний ключ
коментаря
2 text text NOT NULL Текст коментаря
3 creationDate date NOT NULL Дата створення коментаря
Зовнішній ключ, Ідентифікатор автора
4 authorId int
NOT NULL коментаря
Ідентифікатор завдання,
Зовнішній ключ,
5 taskId int до якого належить
NOT NULL
коментар
Таблиця 3.11 – Сутність «Attachments»
104
Attachments
№ Назва Тип даних Обмеження Опис
Унікальний
1 id int Первинний ключ ідентифікатор
вкладення
Зовнішній ключ, NOT Ідентифікатор
2 taskId int
NULL завдання
3 fileName varchar(255) NOT NULL Назва файлу
4 filePath varchar(255) NOT NULL Шлях до файлу
Дата та час
5 uploadDate datetime DEFAULT NOW() завантаження
файлу
Розмір файлу в
6 fileSize bigint
байтах
7 fileType varchar(100) Тип файлу
Ідентифікатор
Зовнішній ключ, NOT користувача, що
8 uploadedByUserId int
NULL виклав
зображення
Призначення
вкладення
9 attachmentType varchar(50)
(загальне чи для
здачі завдання)
Таблиця 3.12 – Сутність «TeamInvitations»
TeamInvitations
№ Назва Тип даних Обмеження Опис
105
Унікальний
1 id int Первинний ключ ідентифікатор
запрошення
Зовнішній ключ, NOT Ідентифікатор
2 teamId int
NULL команди
Адреса
електронної
3 invitedEmail varchar(255) NOT NULL
пошти
запрошеного
4 invitationText text Текст запрошення
Ідентифікатор
Зовнішній ключ, NOT користувача, який
5 invitedByUserId int
NULL надіслав
запрошення
Дата та час
DEFAULT
6 invitationDate timestamp надсилання
CURRENT_TIMESTAMP
запрошення
Статус
запрошення
7 status varchar(50) DEFAULT ‘pending’
(очікує, прийнято,
відхилено)
Таблиця 3.13 – Сутність «TeamActivityLog»
TeamActivityLog
№ Назва Тип даних Обмеження Опис
Унікальний
ідентифікатор
1 id int Первинний ключ
запису активності
команди
106
Зовнішній ключ, NOT Ідентифікатор
2 teamId int
NULL команди
Ідентифікатор
3 userId int Зовнішній ключ користувача, який
виконав дію
4 actionType varchar(50) NOT NULL Тип дії
DEFAULT Час, коли
5 timestamp timestamp
CURRENT_TIMESTAMP відбулася дія
Деталі дії у
6 details json
форматі JSON
Таблиця 3.14 – Сутність «ProjectActivityLog»
ProjectActivityLog
№ Назва Тип даних Обмеження Опис
Унікальний
ідентифікатор
1 id int Первинний ключ
запису активності
проєкту
Зовнішній ключ, NOT Ідентифікатор
2 projectId int
NULL проєкту
Ідентифікатор
3 userId int Зовнішній ключ користувача, який
виконав дію
4 actionType varchar(50) NOT NULL Тип дії
DEFAULT Час, коли
5 timestamp timestamp
CURRENT_TIMESTAMP відбулася дія
Деталі дії у
6 details json
форматі JSON
107
Таблиця 3.15 – Сутність «TaskActivityLog»
TaskActivityLog
№ Назва Тип даних Обмеження Опис
Унікальний
ідентифікатор
1 id int Первинний ключ
запису активності
задачі
Зовнішній ключ, NOT Ідентифікатор
2 taskId int
NULL задачі
Ідентифікатор
Зовнішній ключ, NOT
3 userId int користувача, який
NULL
виконав дію
4 actionType varchar(100) NOT NULL Тип дії
Деталі дії у
5 details json
форматі JSON
DEFAULT Час, коли
6 timestamp datetime
CURRENT_TIMESTAMP відбулася дія
Схематичне зображення структури бази даних наведено на рисунку 3.12.
Модель побудовано засобами MySQL Workbench.
108
Рисунок 3.12 – Структура бази даних інформаційної системи
3.3.2 Реалізація API та логіки обробки запитів інформаційної системи
Серверна частина інформаційної системи реалізована з використанням
фреймворку Express.js для Node.js. В якості бази даних використовується MySQL,
взаємодія з якою здійснюється за допомогою бібліотеки mysql2/promise. Для обробки
паролів користувачів застосовується бібліотека bcrypt для хешування.
На початку роботи застосунок ініціалізує Express-сервер та налаштовує
статичне обслуговування клієнтських ресурсів. Обробка вхідних запитів відбувається
у форматі JSON, із зазначеним обмеженням розміру, а також передбачено підтримку
кодування форм з клієнтської частини. З базою даних сервер з’єднується за
допомогою пулу підключень.
109
Обмін даними між клієнтською та серверною частинами реалізовано через
HTTP-запити до API-ендпоінтів. У системі використовуються стандартні методи:
GET – для отримання інформації, POST – для створення нових записів, PUT – для
оновлення даних, DELETE – для їх видалення. Сервер надсилає відповіді у форматі
JSON, які потім обробляються на стороні клієнта й відображаються в інтерфейсі
користувача.
Сервер забезпечує доступ до HTML-сторінок інтерфейсу: головної сторінки,
форм реєстрації та входу, дашборду, сторінки профілю, проєктів та завдань. Для
захищеного доступу до функціоналу інформаційної системи передбачено проміжну
функцію автентифікації, яка перевіряє наявність ID користувача у заголовку запиту
та підтверджує його присутність у базі даних.
Завантаження та відображення веб-сторінок у системі реалізовано за
принципом серверного рендерингу базового HTM з подальшим динамічним
дозавантаженням даних на клієнті. Це означає, що початкова структура та статичний
контент кожної сторінки надсилаються сервером у вигляді HTML-файлу, а вже після
завантаження сторінки клієнтський JavaScript виконує додаткові запити до API для
отримання динамічних даних та їх відображення в інтерфейсі користувача.
Деталізація процесу отримання основних сторінок:
1. Коли користувач відкриває головну сторінку вебсайту, сервер відправляє
йому готовий HTML-файл, що містить основний контент та структуру
головної сторінки.
2. При переході на сторінку реєстрації сервер надсилає користувачеві HTML-
файл з формою для введення реєстраційних даних.
3. Аналогічно до реєстрації, при відкритті сторінки входу сервер надсилає
HTML-файл з формою для введення облікових даних.
4. Коли авторизований користувач переходить на дашборд, сервер спочатку
перевіряє його автентифікацію. Якщо користувач успішно пройшов
перевірку, сервер завантажує HTML-файл дашборду та додатково може
надсилати JSON-дані з персональною інформацією користувача (ім'я,
прізвище, статус) для відображення на цій сторінці.
110
5. При відкритті сторінки профілю, сервер відправляє користувачеві HTML-
файл профілю. Цей ендпоінт також може приймати параметр userId у запиті
для відображення профілю конкретного користувача.
6. Коли користувач переходить на сторінку проєктів, сервер відправляє йому
відповідний HTML-файл, що відображає інтерфейс для роботи з проєктами.
Функціональність API-ендпоінтів:
Реєстрація користувача. Коли новий користувач реєструється в системі, він
повинен ввести свої основні дані, такі як ім'я, прізвище та електронну пошту. Пароль
є обов'язковим елементом реєстрації. Перш ніж пароль буде збережено, він
перетворюється на унікальний, зашифрований код (хеш) за допомогою спеціального
алгоритму. Це забезпечує, що навіть у разі несанкціонованого доступу до бази даних,
справжні паролі користувачів залишаться захищеними. Крім того, система перевіряє,
чи не використовується введена електронна пошта вже іншим обліковим записом,
щоб уникнути дублювання. Також здійснюється перевірка правильності введення
пароля, і користувач отримує повідомлення про співпадіння або неспівпадіння
паролів безпосередньо під час реєстрації. Ці заходи забезпечують базовий рівень
безпеки та запобігають помилкам при створенні нового облікового запису.
Вхід користувача: Процес входу користувача починається з отримання його
електронної пошти та пароля. Для захисту від спроб підбору пароля застосовується
обмеження кількості невдалих спроб, яке відстежується за IP-адресою запиту.
Система спочатку перевіряє, чи не перевищено цей ліміт для поточної IP-адреси.
Якщо ліміт перевищено і час блокування ще не минув, користувач отримує
повідомлення про велику кількість невдалих спроб та інструкцію спробувати знову
через вказаний проміжок часу.
Далі система здійснює пошук облікового запису користувача в базі даних за
наданою електронною поштою. У випадку, якщо користувача з такою поштою не
знайдено, лічильник невдалих спроб для цієї IP-адреси збільшується, і користувачеві
надсилається повідомлення про невірні облікові дані та кількість залишених спроб.
Якщо обліковий запис знайдено, введений користувачем пароль порівнюється із
зашифрованим паролем, що зберігається в базі даних, за допомогою спеціальної
111
функції. У разі успішного порівняння паролів, лічильник невдалих спроб для цієї IP-
адреси скидається, і користувачеві повертається відповідь, що містить його
унікальний ідентифікатор, поточний статус та повідомлення про успішний вхід. Якщо
ж введені паролі не співпадають, лічильник невдалих спроб для поточної IP-адреси
знову збільшується, і користувачеві повертається повідомлення про невірні облікові
дані та кількість залишених спроб. У випадку виникнення будь-яких внутрішніх
помилок під час процесу входу, користувачеві повідомляється про помилку на
сервері.
Призначення відділів користувачам. При взаємодії користувача з інтерфейсом
для вибору відділів, система отримує його ідентифікатор та перелік ідентифікаторів
обраних відділів. Перед збереженням цих зв'язків, система виконує ряд перевірок:
вона встановлює, чи було обрано від одного до трьох відділів, перевіряє наявність
самого користувача, а також існування всіх зазначених відділів у базі даних. Лише
після успішного проходження всіх цих перевірок, система встановлює зв'язок між
користувачем та обраними відділами, додаючи відповідні записи. У випадку
виникнення будь-яких помилок на будь-якому етапі цього процесу, користувачеві
повертається повідомлення про невдачу.
Створення профілю користувача. Кожен користувач має профіль для зберігання
додаткової інформації. При реєстрації нового користувача система надсилає запит,
що містить ідентифікатор користувача. Сервер перевіряє наявність цього
ідентифікатора та його відповідність існуючому користувачу в базі даних. Якщо
користувача знайдено, сервер створює новий запис профілю, який спочатку містить
лише ідентифікатор користувача, але може бути доповнений іншими даними в
подальшому. У разі успішного створення профілю, сервер підтверджує виконання
операції. Якщо користувача не знайдено або виникає помилка при збереженні даних,
сервер повідомляє про це користувача.
Створення нової команди. Система приймає назву та опис нової команди від
користувача, який ініціює створення. Вона автоматично генерує унікальний код
запрошення для цієї команди, фіксує дату її створення та зберігає всю інформацію
про команду. Користувач, який створив команду, автоматично призначається її
112
менеджером, і його статус оновлюється на «в команді». Після успішного створення,
користувачу повертається унікальний ідентифікатор створеної команди, її назва,
згенерований код запрошення та підтвердження успішного виконання операції. У
випадку виникнення помилки, користувач отримує відповідне повідомлення.
Приєднання до команди за кодом запрошення. Система отримує наданий
користувачем код запрошення. Вона здійснює пошук команди, що відповідає цьому
коду, у базі даних. Якщо команду знайдено, і поточний користувач ще не є її
учасником, система додає його до складу цієї команди як звичайного учасника,
оновлює його статус, позначаючи, що він тепер перебуває в команді, та фіксує цю дію
в журналі активності команди. Користувачеві повертається повідомлення про
успішне приєднання та назву команди. У випадку виникнення будь-яких помилок,
таких як невірний код запрошення, спроба приєднатися до команди, в якій користувач
вже перебуває, або внутрішня помилка системи, користувач отримує відповідне
повідомлення.
Запрошення користувачів до команди. Після успішної автентифікації
користувача, система отримує ідентифікатор команди та перелік електронних адрес
користувачів, яких необхідно запросити. Також може бути надано необов'язкове
повідомлення запрошення. Лише особа, яка створила команду, має право надсилати
запрошення. Для кожної зазначеної електронної адреси система перевіряє, чи не є
користувач вже учасником цієї команди або чи не має він вже активного запрошення
до неї. Якщо жодна з цих умов не виконується, створюється новий запис про
запрошення, і фіксується інформація про те, хто саме надіслав це запрошення. У
відповідь користувачу повертається звіт, що містить інформацію про успішно та
неуспішно надіслані запрошення.
Прийняття запрошення до команди. Система отримує ідентифікатор
запрошення. Вона перевіряє, чи існує таке запрошення, чи призначене воно
поточному користувачеві та чи перебуває воно у статусі «очікування». Якщо всі ці
умови виконані, користувач додається до вказаної команди як звичайний учасник. За
потреби, його статус оновлюється, вказуючи, що він тепер перебуває в команді, а
статус самого запрошення змінюється на «прийнято». Дія приєднання фіксується в
113
журналі активності команди. Користувачеві повертається повідомлення про успішне
приєднання до команди.
Відхилення запрошення до команди. Система отримує ідентифікатор
запрошення. Вона також очікує, що в запиті буде вказано статус «відхилено».
Система перевіряє, чи існує таке запрошення та чи призначене воно поточному
користувачеві. Якщо ці умови дотримані, статус запрошення оновлюється на
«відхилено». Користувачеві повертається повідомлення про відхилення запрошення.
Створення нового проєкту. Система приймає ідентифікатор команди, назву,
опис, заплановану дату завершення та поточний статус нового проєкту. Перед
збереженням даних виконується перевірка наявності ідентифікатора команди та
назви проєкту. Після успішних перевірок система створює новий запис про проєкт у
базі даних, автоматично фіксуючи дату його створення. Дія створення проєкту також
реєструється в історії проєктів. У відповідь система повертає інформацію про щойно
створений проєкт. У випадку виникнення будь-яких помилок під час цього процесу
користувач отримує відповідне повідомлення.
Оновлення існуючого проєкту. Система отримує ідентифікатор команди,
ідентифікатор проєкту та оновлені дані для проєкту, такі як назва, опис, дата
завершення та поточний статус. Вона перевіряє коректність наданих ідентифікаторів
та наявність назви проєкту. Після успішних перевірок система знаходить відповідний
проєкт і оновлює всю його інформацію у базі даних. Дія оновлення проєкту також
фіксується в історії проєктів. У відповідь система повертає оновлені дані проєкту.
Якщо проєкт не знайдено або операція оновлення завершилася невдачею, користувач
отримує відповідне повідомлення про помилку.
Створення нового завдання у проєкті. Перед обробкою запиту система
перевіряє автентифікацію користувача. Потім вона ініціює транзакцію в базі даних,
щоб забезпечити цілісність даних. Система додає нове завдання до бази даних,
автоматично встановлюючи дату створення. Після цього вона призначає завдання
вказаним користувачам, створюючи записи про ці призначення. Якщо були надані
файли, система зберігає інформацію про них у базі даних, асоціюючи їх із
новоствореним завданням та фіксуючи, хто саме їх завантажив. Усі ці дії, пов'язані зі
114
створенням завдання, фіксуються в журналі активності завдань. Після успішного
завершення всіх операцій, зміни зберігаються в базі даних. У відповідь система
повертає повні дані про щойно створене завдання. При виникненні помилок система
автоматично скасовує внесені зміни, і користувач отримує відповідне повідомлення
про помилку.
Додавання коментаря до завдання. На початку процесу система здійснює
перевірку наданих даних: чи коректний ідентифікатор завдання та чи не є порожнім
текст коментаря. Також перевіряється, чи існує завдання з таким ідентифікатором у
базі даних. Після успішних перевірок, система створює новий запис коментаря,
асоціюючи його з вказаним завданням та автором, автоматично фіксуючи дату
створення. Після збереження коментаря, система отримує його повні дані, включаючи
інформацію про автора (ім'я, прізвище, аватар) та чи є він менеджером або творцем
команди, до якої належить завдання. У відповідь користувачу повертається об'єкт
новоствореного коментаря з усіма необхідними деталями. У випадку, якщо завдання
не знайдено, дані некоректні або виникла внутрішня помилка сервера, користувач
отримує відповідне повідомлення про помилку.
З метою автоматичного оновлення статусів проєктів і завдань у випадках, коли
термін їх виконання спливає, а зміни не було внесено вручну, у базі даних було
створено відповідні події. Вони забезпечують автоматичне встановлення статусу
«Протерміновано» для тих проєктів і завдань, які не були завершені вчасно (додаток
Г, рис. Г.28).
3.4 Тестування розробленої інформаційної системи
Після завершення етапу розробки інформаційної системи було проведено
комплексне тестування для перевірки її якості, стабільності та відповідності
функціональним вимогам. Основною метою тестування є виявлення помилок, оцінка
надійності роботи системи в різних умовах, а також перевірка зручності користування
з погляду кінцевого користувача.
У межах тестування було здійснено:
115
функціональне тестування – для перевірки коректності виконання основних
сценаріїв взаємодії користувачів із системою;
тестування зручності використання – для оцінки зрозумілості інтерфейсу,
логічності навігації та загального користувацького досвіду;
тестування продуктивності – для визначення швидкості обробки запитів,
стабільності роботи під навантаженням та оптимізації ресурсів.
Кожен із видів тестування дозволив перевірити різні аспекти роботи системи та
отримати повну оцінку її готовності до реального використання.
3.4.1 Функціональне тестування інформаційної системи
Функціональне тестування було проведено з метою перевірки відповідності
роботи інформаційної системи визначеним вимогам. Тестування передбачало
перевірку основних сценаріїв взаємодії користувача з системою, які є важливими для
її повноцінного функціонування. До основних сценаріїв належали:
реєстрація нового користувача;
вхід до системи;
вибір відділів після першого входу;
створення команд;
приєднання до команди за унікальним кодом;
надсилання запрошень іншим користувачам системи;
прийняття або відхилення запрошень;
створення проєктів менеджером;
створення завдань менеджером;
призначення виконавців до завдань;
додавання вкладень до завдань;
відображення завдань на сторінці користувача;
відправка завдань на перевірку учасником команди;
прийняття або відхилення завдань менеджером;
116
ручне та автоматичне оновлення статусу проєктів;
ручне та автоматичне оновлення статусу завдань;
фільтрація проєктів за статусами;
фільтрація проєктів за історією («Усі», «За тиждень, «За місяць», «За три
місяці);
фільтрація завдань за відділами;
фільтрація завдань за історією («Усі», «За тиждень, «За місяць», «За три
місяці);
ручний вихід із системи;
автоматичний вихід із системи після тривалого часу бездіяльності.
Усі перелічені функції були протестовані шляхом ручного проходження
сценаріїв для різних ролей користувачів. Під час тестування фіксувалися всі виявлені
помилки, а також аналізувалась коректність обробки запитів. Для додаткового
контролю під час розробки інформаційної системи використовувалося логування, що
дозволяло виявляти неочевидні помилки у роботі системи, зокрема при взаємодії з
базою даних, обробці некоректних вхідних даних, або непередбачуваних сценаріях
взаємодії користувачів.
Тестування функцій:
Тестовий випадок 1: Реєстрація нового користувача
Мета: Перевірити реєстрацію користувача з валідними даними.
Умови: ім’я, прізвище, електронна пошта, пароль.
Очікуваний результат: запис інформації про користувача до таблиці Users,
створення облікового запису, перехід до вибору відділів.
Фактичний результат: користувача успішно зареєстровано у системі та
перенаправлено на сторінку дашборду для нових користувачів.
Тестовий випадок 2: Вхід користувача до системи
Мета: Перевірити можливість входу з правильними обліковими даними.
Умови: електронна пошта та пароль раніше зареєстрованого користувача.
117
Очікуваний результат: перехід на дашборд залежно від стану користувача у
системі.
Фактичний результат: вхід успішний, користувача перенаправлено на сторінку
дашборду.
Тестовий випадок 3: Надсилання запрошень
Мета: Перевірити, як система обробляє список email-адрес, серед яких є вже
запрошені.
Умови: електронні адреси тестових користувачів – [email protected],
[email protected], [email protected].
Очікуваний результат:
для унікальних email – запрошення надіслано;
для дублікатів – пропуск, адже запрошення вже є у системі.
Фактичний результат: запрошення не надсилалися через наявність дубліката у
списку email-адрес. Виправлено.
Тестовий випадок 4: Додавання вкладення до завдання
Мета: Перевірити прикріплення файлу до завдання.
Умови: створення завдання «Тестування вкладень» та додавання до нього
файлу References.pdf.
Очікуваний результат: файл завантажено, збережено шлях у базі даних.
Фактичний результат: Вкладення прикріплено, шлях збереження правильний
після виправлення функції запису шляху на сервері.
Тестовий випадок 5: Автоматичне завершення сесії
Мета: Перевірити автоматичний log-out після 45 хвилин неактивності.
Умови: Користувач увійшов до системи і залишив вкладку неактивною.
Очікуваний результат: Через 30 хвилин – автоматичне відкриття модального
вікна з попередженням про неактивність та відліком до завершення сесії.
118
Фактичний результат: Сесія завершилася, але з’явилося модальне вікно ручного
виходу замість автоматичного. Модальні вікна було розділено.
Жодних критичних помилок під час функціонального тестування не виявлено.
Невеликі недоліки, пов’язані з візуальним відображенням повідомлень про помилки
або валідацією введених даних, були усунені в процесі розробки. За результатами
тестування встановлено, що основні функції інформаційної системи працюють
стабільно та відповідають очікуваній поведінці.
Результати функціонального тестування подано у таблиці 3.16.
Таблиця 3.16 – Результати функціонального тестування
Виявлено Уточнення / Дії після
№ Функціональність Протестовано
помилки тестування
Реєстрація нового
1 Так Ні –
користувача
2 Вхід до системи Так Ні –
Вибір відділів
3 після першого Так Ні –
входу
Створення
4 Так Ні –
команди
Приєднання до
5 Так Ні –
команди за кодом
Виправлено обробку
списку адрес: усунено
помилки при надсиланні
Надсилання
6 Так Так кільком адресатам та при
запрошень
повторному запрошенні
вже запрошених
користувачів
119
Прийняття /
7 відхилення Так Ні –
запрошень
Створення
8 Так Ні –
проєктів
9 Створення завдань Так Ні –
Призначення
10 Так Ні –
виконавців
Виправлено обробку
шляху збереження файлів
Додавання
11 Так Так на сервері для коректної
вкладень
роботи завантаження
вкладень
Відображення
12 Так Ні –
завдань на сторінці
Виникали труднощі з
витягуванням інформації
з кількох таблиць БД.
13 Перегляд завдань Так Так
Оптимізовано запити та
налагоджено
відображення даних
Відправка завдань
14 Так Ні –
на перевірку
Прийняття /
15 Так Ні –
відхилення завдань
Оновлення статусу
16 Так Ні –
проєктів
Оновлення статусу
17 Так Ні –
завдань
120
Фільтрація
18 Так Ні –
проєктів
19 Фільтрація завдань Так Ні –
Ручний вихід із
20 Так Ні –
системи
Виявлено конфлікт із
модальними вікнами.
Автоматичний
Було реалізовано окремі
21 вихід після Так Так
модальні вікна для
неактивності
ручного та автоматичного
виходу з системи
3.4.2 Тестування зручності використання інформаційної системи
Тестування зручності використання проводилося з метою перевірки, наскільки
інтерфейс системи є інтуїтивно зрозумілим, логічно структурованим та зручним для
користувачів. Основна увага приділялася простоті виконання базових дій, швидкості
освоєння функціоналу та візуальному сприйняттю інтерфейсу. Для збору зворотного
зв’язку було обрано метод спостереження за діями користувачів під час виконання
типових сценаріїв роботи з системою.
Учасники тестування оцінювали інформаційну систему за такими критеріями:
загальне враження від роботи з інтерфейсом;
зручність виконання основних дій;
помітність і зрозумілість елементів керування;
наявність та якість функції пошуку або фільтрації інформації;
кількість та характер складнощів у використанні інтерфейсу;
адаптивність інтерфейсу до різних пристроїв (ПК, планшети, смартфони).
У результаті тестування було встановлено, що більшість користувачів змогли
без додаткових інструкцій успішно зареєструватися, обрати відділи, до яких вони
хочуть приєднатися, а також працювати з проєктами та завданнями у системі.
121
Користувачі відзначили, що інтерфейс системи зрозумілий та зручно структурований.
Навігація між сторінками не викликала труднощів, основні дії виконуються у
зрозумілій послідовності. Візуальне оформлення системи також отримало позитивну
оцінку: застосовано мінімалістичний дизайн, елементи управління чітко підписані,
передбачено спливаючі підказки, які допомагають у роботі з системою.
Результати оцінки зручності використання веб-орієнтвоаної інформаційної
системи для управління завданнями представлено у таблиці 3.17.
Таблиця 3.17 – Результати оцінки зручності використання інформаційної
системи за основними критеріями
Коментарі
№ Критерій оцінювання Опис критерію Оцінка (1-5)
користувачів
Інтерфейс
Суб’єктивна
викликає
оцінка комфорту
Загальне враження від позитивні
1 та зручності 5
роботи з інтерфейсом враження,
роботи з
інтуїтивно
інтерфейсом
зрозумілий
Оцінка простоти Основні функції
Зручність виконання та швидкості виконуються без
2 5
основних дій виконання затримок і
типових операцій складнощів
Чи легко Елементи
користувачі керування мають
Помітність та
знаходять і чіткий вигляд,
3 зрозумілість елементів 5
розуміють потрібна
керування
кнопки, меню, мінімальна
поля інструкція
122
Оцінка зручності Функції працюють
Наявність і якість
та ефективності коректно, пошук та
4 функції пошуку або 4
пошуку і фільтрація швидкі
фільтрації інформації
фільтрації і точні
Кількість та характер Аналіз помилок і Складнощі у
складнощів у труднощів, які використанні
5 4
використанні виникають у відсутні або
інтерфейсу процесі роботи мінімальні
Інтерфейс
Оцінка зручності
Адаптивність коректно
роботи на ПК,
6 інтерфейсу до різних 4 відображається і
планшетах і
пристроїв працює на всіх
смартфонах
пристроях
Середня оцінка 4,5
Усі зауваження були проаналізовані, частину з них було враховано та внесено
відповідні зміни до інтерфейсу. Було реалізовано повідомлення успіху та
повідомлення про помилки, щоб користувачі могли отримувати відгук від системи,
та виділено кнопки, які відповідають за виконання основних дій в інформаційній
системі. Тестування підтвердило загальну зручність системи, однак під час перевірки
були виявлені окремі недоліки, усунення яких сприятиме покращенню
користувацького досвіду. Серед напрямів розвитку – додавання статистики на
сторінки команд, проєктів та завдань, щоб користувачі могли аналізувати
продуктивність команди та ефективність виконання завдань, додавання можливості
менеджеру залишати відгук при відхиленні завдання.
123
3.4.3 Тестування продуктивності інформаційної системи
З метою оцінки швидкодії інформаційної системи управління завданнями було
проведено базове тестування продуктивності. Для цього використовувалися
вбудовані інструменти розробника Chrome DevTools. У процесі тестування було
проаналізовано час відповіді серверної частини на клієнтські запити, швидкість
завантаження сторінок, а також ефективність обробки основних ресурсів системи.
Для оцінки продуктивності інтерфейсу прийнятним вважається час
завантаження у діапазоні від 300 до 500 мілісекунд. Якщо завантаження сторінки
триває більше ніж 500 мілісекунд, користувачі можуть відчути затримку.
Під час завантаження дашборду час становив 317 мс, структура сторінки була
готова за 231 мс. Для модуля команд – 322 мс і 233 мс відповідно. Більшість запитів
виконувались швидко – від 4 до 40 мс. Модуль проєктів завантажувався 283 мс,
сторінка ставала готовою через 206 мс. Найдовше тривало завантаження скриптів –
81 мс, решта запитів – 5–45 мс. Модуль завдань завантажувався 379 мс.
Аналіз продуктивності роботи системи для управління завданнями показав, що
її клієнтська та серверна частини добре оптимізовані у тестовому середовищі.
Більшість запитів виконувалися за час до 50 мілісекунд, що говорить про ефективну
роботу системи. Деякі ресурси, як-от шрифти та сторонні бібліотеки,
завантажувалися трохи довше – до 96 мілісекунд.
На підставі отриманих результатів тестування продуктивності можна
стверджувати, що система демонструє стабільну роботу з мінімальними затримками,
забезпечуючи комфортну взаємодію користувача з інтерфейсом. Проведене
тестування підтверджує готовність застосунку до подальшого розширення
функціональності та масштабування.
124
Висновки до розділу 3
У третьому розділі було проведено практичну реалізацію веб-орієнтованої
інформаційної системи для управління завданнями. На першому етапі було
обґрунтовано вибір технологій, які використовувались для розробки системи. Для
фронтенду застосовувалися HTML, CSS та JavaScript. Серверна частина розроблялася
з використанням Node.js та фреймворку Express, для ефективної обробки запитів та
взаємодії з базою даних. В якості системи управління базами даних була обрана
MySQL, яка забезпечила надійне зберігання та управління даними. Для розробки
використовувалось інтегроване середовище Visual Studio Code. Вибір цих технологій
базувався на функціональних вимогах, продуктивності та сучасних стандартах
розробки.
Розроблено інтерфейс користувача, який включає сторінки реєстрації, входу,
дашборду, проєктів, завдань, профілю та інші елементи. Інтерфейс було реалізовано
з урахуванням принципів простоти, логічної структури та зручності взаємодії з
системою. Спроєктовано базу даних, структуру якої було описано за допомогою
діаграм у другому розділі. У процесі реалізації до моделі було внесено деякі зміни для
кращої відповідності функціональним вимогам. Описано реалізацію основних API-
запитів, які забезпечують обробку даних між клієнтською та серверною частинами.
Реалізовано обробку HTTP-запитів різних типів: GET, POST, PUT і DELETE.
Інформаційну систему було протестовано з використанням трьох типів
тестування: функціонального, яке охоплює перевірку основних сценаріїв взаємодії
користувача з системою, а також двох нефункціональних видів тестування –
тестування зручності використання, що передбачає оцінку інтерфейсу та логіки
навігації, та тестування продуктивності, яке визначає швидкість завантаження
сторінок та обробки запитів. Отримані результати показали, що система є зручною у
використанні, простою, зрозумілою та достатньо продуктивною для невеликих
навантажень. Для можливості витримувати більші навантаження у майбутньому
систему потрібно буде масштабувати та оптимізувати.
125
ВИСНОВКИ
У результаті виконання кваліфікаційної роботи досягнуто поставлену мету –
розроблено веб-орієнтовану інформаційну систему для управління завданнями при
розробці IT-продуктів. Система орієнтована на підвищення ефективності командної
взаємодії, забезпечує зручну організацію процесів планування, розподілу та
контролю виконання завдань.
У першому розділі було проаналізовано актуальний стан у сфері управління
завданнями. Вивчено існуючі інструменти та методології, що застосовуються в IT-
проєктах. Виявлено основні обмеження популярних систем для управління
завданнями: перевантаженість функціоналом, недостатню гнучкість в управлінні
завданнями та складність у використанні. Це обґрунтувало необхідність створення
нової системи, адаптованої до реальних потреб користувачів.
У другому розділі виконано проєктування інформаційної системи.
Сформульовано вимоги, визначено ролі користувачів, розроблено моделі предметної
області, логічну та архітектурну структуру. Було створено діаграму класів для опису
структури системи на рівні об'єктно-орієнтованого моделювання та діаграми
діяльності для відображення порядку виконання дій та процесів у системі.
У третьому розділі реалізовано веб-орієнтовану інформаційну систему
відповідно до визначених вимог. Розроблено користувацький інтерфейс, який
відповідає принципам зручності та доступності. Реалізовано основні модулі для
управління командами, проєктами та завданнями. Проведено функціональне
тестування, а також нефункціональні перевірки зручності використання та
продуктивності для підтвердження відповідності розробленої системи
сформульованим вимогам. Результати тестування підтвердили, що система вирішує
основні проблеми, виявлені під час аналізу існуючих подібних платформ, та
забезпечує базовий функціонал для управління завданнями в межах розробки IT-
продуктів.
126
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Cohn M. User stories applied: For agile software development. 13th ed. Addison-
Wesley, 2009. URL: https://athena.ecs.csus.edu/~buckley/CSc191/User-Stories-
Applied-Mike-Cohn.pdf (дата звернення: 17.04.2025).
2. Cohn M. Agile estimating and planning. Pearson Education, 2006. URL:
https://www.academia.edu/41614300/Agile_Estimating_and_Planning_by_Mike
_Cohn (дата звернення: 18.04.2025).
3. Kim G., Behr K., Spafford G. The Phoenix Project: A novel about IT, DevOps,
and helping your business win. IT Revolution Press, 2013. URL:
https://github.com/RavinRau/Ebooks/blob/main/Devops/The%20Phoenix%20Pr
oject%20A%20Novel%20About%20IT,%20DevOps,%20and%20Helping%20Y
our%20Business%20Win%20%28Gene%20Kim,%20Kevin%20%20Behr,%20G
eorge%20Spafford%29.pdf (дата звернення: 18.04.2025).
4. Kerzner H. Project management: A systems approach to planning, scheduling, and
controlling. 10th ed. John Wiley & Sons, 2009. URL: https://ftp.idu.ac.id/wp-
content/uploads/ebook/ip/BUKU%20MANAJEMEN%20PROYEK/project-
management-harold-kerzner1.pdf (дата звернення: 17.04.2025).
5. Kortas T. Task management: Definition, examples, methods, software
[Електронний ресурс] // OTRS. 18.12.2024. URL:
https://otrs.com/blog/customer-service/task-management/ (дата звернення:
13.04.2025).
6. QALight. Каскадна модель [Електронний ресурс]. URL:
https://qalight.ua/baza-znaniy/kaskadna-model-waterfall-model/ (дата
звернення: 11.03.2025).
7. QALight. Agile [Електронний ресурс]. URL: https://qalight.ua/baza-
znaniy/agile-dev/ (дата звернення: 11.03.2025).
8. QATestLab. Scrum термінологія [Електронний ресурс] // QATestLab.
02.06.2022. URL: https://training.qatestlab.com/blog/technical-articles/scrum-
terminology/ (дата звернення: 13.03.2025).
127
9. Seidl M., Scholz M., Huemer C., Kappel G. The use case diagram //
UML@Classroom: An Introduction to Object-Oriented Modeling. Springer, 2015.
С. 23–47. URL: https://link.springer.com/chapter/10.1007/978-3-319-12742-2_3
(дата звернення: 13.03.2025).
10. Вікіпедія. Діаграма прецедентів [Електронний ресурс]. URL:
https://uk.wikipedia.org/wiki/Діаграма_прецедентів (дата звернення:
13.03.2025).
11. Song I. Y., Froehlich K. A Practical Guide to Entity-Relationship Modeling //
IEEE Potentials. 1994. Vol. 13, №5. С. 29–34. URL:
https://cci.drexel.edu/faculty/song/courses/info%20605/appendix/AppendixA.PD
F (дата звернення: 13.03.2025).
12. Буй Д. Б., Сільвейструк Л. М. Формалізація моделі „сутність-зв’язок” //
Dynamical System Modeling and Stability Investigation: international conference.
2007. С. 364. URL: http://csc.univ.kiev.ua/uk/library/books/bui-silveistruk-
33.pdf (дата звернення: 13.03.2025).
13. Вікіпедія. Діаграма класів [Електронний ресурс]. URL:
https://uk.wikipedia.org/wiki/Діаграма_класів (дата звернення: 13.03.2025).
14. Вікіпедія. Діаграма компонентів [Електронний ресурс]. URL:
https://uk.wikipedia.org/wiki/Діаграма_компонентів (дата звернення:
13.03.2025).
15. Deployment diagram in Unified Modeling Language (UML) [Електронний
ресурс] // GeeksforGeeks. 16.10.2024. URL:
https://www.geeksforgeeks.org/deployment-diagram-unified-modeling-
languageuml/ (дата звернення: 13.03.2025).
16. Carter M. UML activity diagram [Електронний ресурс] // Boardmix. 24.09.2024.
URL: https://boardmix.com/tips/uml-activity-diagram/ (дата звернення:
13.03.2025).
17. Мулеса О. Ю., Варга Я. В. Інформаційні системи та реляційні бази даних
[Електронний ресурс]. 2023. URL:
128
https://dspace.uzhnu.edu.ua/jspui/handle/lib/49919 (дата звернення:
26.04.2025).
18. Сидоренко В. В., Константинова Л. В., Смірнов С. А. Організація баз даних:
навч. посіб. Кропивницький: ЦНТУ, 2018. 274 с. URL:
https://dspace.kntu.kr.ua/server/api/core/bitstreams/a050035e-e868-4140-b2ba-
e449d7394255/content (дата звернення: 26.04.2025).
ДОДАТОК А
Затверджую
Завідувач кафедри КНСА
проф. Триус Ю.В.
_________________________
«____»______________2025 р.
«ВЕБ-ОРІЄНТОВАНА ІНФОРМАЦІЙНА СИСТЕМА ДЛЯ УПРАВЛІННЯ
ЗАВДАННЯМИ ПРИ РОЗРОБЦІ IT-ПРОДУКТІВ»
Специфікація
482.ЧДТУ.52107-01 12 01
Листів 1
Розробник ________________ Волошина В. О.
Керівник ________________ Дяченко П. В.
Черкаси – 2025
130
482.ЧДТУ. 52107-01
Позначення Найменування Примітка
Документація
482.ЧДТУ. 52107-01 12 01 Текст програми
482.ЧДТУ. 52107-01 34 01 Інструкція користувача
482.ЧДТУ. 52107-01 90 01 Графічні матеріали
482.ЧДТУ. 52107-01 90 01 Публікація по темі
кваліфікаційної роботи
бакалавра
ДОДАТОК Б
Затверджую
Завідувач кафедри КНСА
проф. Триус Ю.В.
_________________________
«____»______________2025 р.
ВЕБ-ОРІЄНТОВАНА ІНФОРМАЦІЙНА СИСТЕМА ДЛЯ УПРАВЛІННЯ
ЗАВДАННЯМИ ПРИ РОЗРОБЦІ IT-ПРОДУКТІВ
Текст програми
482.ЧДТУ.52107-01 12 01
Листів 10
Розробник ________________ Волошина В. О.
Черкаси – 2025
132
Ініціалізація вебсервера та підключення до бази даних:
const express = require("express");
const path = require("path");
const mysql = require('mysql2/promise');
const bcrypt = require('bcrypt');
const app = express();
const PORT = process.env.PORT || 3000;
app.use(express.static(path.join(__dirname, "public")));
app.use(express.urlencoded({ extended: false }));
app.use(express.json({ limit: '10mb' }));
const pool = mysql.createPool({
host: '127.0.0.1',
user: '…t',
password: '…',
database: 'task_management_system',
waitForConnections: true,
connectionLimit: 10,
queueLimit: 0
});
Визначення маршрутів для отримання сторінок:
app.get("/", (req, res) => {
res.sendFile(path.join(__dirname, "public", "html", "index.html"));
});
app.get("/html/sign-up.html", (req, res) => {
res.sendFile(path.join(__dirname, "public", "html", "sign-up.html"));
});
app.get("/html/login.html", (req, res) => {
res.sendFile(path.join(__dirname, "public", "html", "login.html"));
});
133
app.get("/html/dashboard.html", (req, res) => {
res.sendFile(path.join(__dirname, "public", "html", "dashboard.html"));
});
app.get("/html/profile", (req, res) => {
res.sendFile(path.join(__dirname, "public", "html", "profile.html"));
});
Middleware для перевірки, чи є користувач авторизованим:
const authenticateUser = async (req, res, next) => {
const userId = req.headers['user-id'];
if (!userId) {
return res.status(401).send('Будь ласка, авторизуйтесь.');
}
try {
const [users] = await pool.execute('SELECT id, status FROM users WHERE id
= ?', [userId]);
if (users.length === 1) {
req.userId = userId;
req.user = users[0];
next();
} else {
return res.status(401).send('Невірний ID користувача.');
}
} catch (error) {
console.error('Помилка аутентифікації:', error);
return res.status(500).send('Помилка сервера під час аутентифікації.');
}
};
Обробка POST-запиту для реєстрації:
134
app.post("/auth", async (req, res) => {
const { firstName, lastName, email, password, confirmPassword } = req.body;
if (!firstName || !lastName || !email || !password || !confirmPassword) {
return res.status(400).send("Будь ласка, заповніть усі поля.");
}
if (password !== confirmPassword) {
return res.status(400).send("Паролі не співпадають.");
}
try {
const [existingUsers] = await pool.execute('SELECT * FROM users WHERE
email = ?', [email]);
if (existingUsers.length > 0) {
return res.status(409).send("Користувач з таким email вже існує.");
}
const hashedPassword = await bcrypt.hash(password, 10);
const [result] = await pool.execute(
'INSERT INTO users (firstName, lastName, email, password,
registrationDate, lastActivity) VALUES (?, ?, ?, ?, NOW(), NOW())',
[firstName, lastName, email, hashedPassword]
);
if (result.insertId) {
const userId = result.insertId;
return res.status(201).json({ message: "Реєстрація успішна!", userId: userId
});
} else {
return res.status(500).send("Не вдалося додати користувача до бази
даних.");
}
} catch (error) {
console.error("Помилка реєстрації:", error);
135
res.status(500).send("Сталася помилка на сервері під час реєстрації.");
}
});
Обробка POST-запиту для входу:
app.post("/login", async (req, res) => {
const { email, password } = req.body;
console.log("Отримано email для входу:", email);
try {
const [users] = await pool.execute('SELECT id, password, status FROM users
WHERE email = ?', [email]);
if (users.length === 0) {
console.log("Користувача з email", email, "не знайдено.");
return res.status(401).json({ message: "Невірні облікові дані." });
}
const user = users[0];
const passwordMatch = await bcrypt.compare(password, user.password);
if (passwordMatch) {
console.log("Вхід успішний для користувача:", email, "ID:", user.id,
"Статус:", user.status);
return res.status(200).json({ userId: user.id, status: user.status, message:
"Вхід успішний!" });
} else {
console.log("Неправильний пароль для користувача:", email);
return res.status(401).json({ message: "Невірні облікові дані." });
}
} catch (error) {
console.error("Помилка входу:", error);
res.status(500).json({ message: "Сталася помилка на сервері під час входу."
});
136
}
});
Обробка POST-запиту для створення профілю користувача:
app.post("/api/user-profiles", async (req, res) => {
const { userId } = req.body;
if (!userId) {
return res.status(400).json({ error: "Необхідно вказати ID користувача." });
}
try {
const [users] = await pool.execute('SELECT id FROM users WHERE id = ?',
[userId]);
if (users.length === 0) {
return res.status(404).json({ error: "Користувача з таким ID не знайдено."
});
}
const [result] = await pool.execute(
'INSERT INTO UserProfiles (userId) VALUES (?)',
[userId]
);
if (result.affectedRows > 0) {
return res.status(201).json({ message: "Профіль користувача створено.",
userId: userId });
} else {
return res.status(500).json({ error: "Не вдалося створити профіль
користувача." });
}
} catch (error) {
console.error("Помилка створення профілю користувача:", error);
137
res.status(500).json({ error: "Сталася помилка на сервері під час створення
профілю." });
}
});
Обробка GET-запиту для відображення команд користувача:
app.get('/api/user/teams', authenticateUser, async (req, res) => {
const userId = req.userId;
try {
const [teamsResult] = await pool.execute(`
SELECT
t.id,
t.name,
t.description,
tm.isManager,
(SELECT COUNT(*) FROM TeamMembers WHERE teamId = t.id) AS
memberCount
FROM Teams t
JOIN TeamMembers tm ON t.id = tm.teamId
WHERE tm.userId = ?
`, [userId]);
res.json({ teams: teamsResult });
} catch (error) {
console.error('Помилка отримання команд користувача:', error);
res.status(500).json({ message: 'Не вдалося отримати список команд
користувача.' });
}
});
Обробка POST-запиту для створення нової команди:
138
app.post('/api/teams/create', authenticateUser, async (req, res) => {
const { teamName, teamDescription } = req.body;
const creatorUserId = req.userId;
if (!teamName) {
return res.status(400).json({ message: 'Назва команди є обов\'язковою' });
}
try {
const invitationCode = generateUniqueCode();
const creationDate = new Date();
const [teamResult] = await pool.execute(
'INSERT INTO Teams (name, description, creationDate, invitationCode,
createdBy) VALUES (?, ?, ?, ?, ?)',
[teamName, teamDescription, creationDate, invitationCode, creatorUserId]
);
const teamId = teamResult.insertId;
if (teamId) {
await pool.execute(
'INSERT INTO TeamMembers (userId, teamId, isManager) VALUES (?,
?, TRUE)',
[creatorUserId, teamId]
);
await pool.execute(
'UPDATE Users SET status = ? WHERE id = ?',
['in_team', creatorUserId]
);
res.status(201).json({ teamId, teamName, invitationCode, message:
'Команду успішно створено' });
} else {
res.status(500).json({ message: 'Не вдалося зберегти команду' });
139
}
} catch (error) {
console.error("Помилка при створенні команди:", error);
if (error.code === 'ER_DUP_ENTRY') {
return res.status(409).json({ message: `Команда з назвою "${teamName}"
вже існує. Будь ласка, оберіть іншу назву.` });
}
res.status(500).json({ message: 'Сталася помилка на сервері при створенні
команди', error: error.message });
}
});
Функція для генерації унікального коду запрошення:
function generateUniqueCode() {
const length = 8;
const characters =
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
let code = '';
for (let i = 0; i < length; i++) {
code += characters.charAt(Math.floor(Math.random() * characters.length));
}
return code;
}
Обробка POST-запиту для приєднання до команди за кодом запрошення:
app.post('/api/teams/join', authenticateUser, async (req, res) => {
const { invitationCode } = req.body;
const userId = req.userId;
if (!invitationCode) {
140
return res.status(400).json({ message: 'Будь ласка, надайте код запрошення.'
});
}
try {
const [teamsResult] = await pool.execute(
'SELECT id, name FROM Teams WHERE invitationCode = ?',
[invitationCode]
);
if (teamsResult.length === 0) {
return res.status(404).json({ message: 'Команду з таким кодом не
знайдено.' });
}
const team = teamsResult[0];
const teamId = team.id;
const teamName = team.name;
const [existingMember] = await pool.execute(
'SELECT * FROM TeamMembers WHERE userId = ? AND teamId = ?',
[userId, teamId]
);
if (existingMember.length > 0) {
return res.status(409).json({ message: 'Ви вже є учасником цієї команди.'
});
}
await pool.execute(
'INSERT INTO TeamMembers (userId, teamId, isManager) VALUES (?, ?,
FALSE)',
[userId, teamId]
);
await pool.execute(
'UPDATE Users SET status = "in_team" WHERE id = ?',
141
[userId]
);
await pool.execute(
'INSERT INTO TeamActivityLog (teamId, userId, actionType, details)
VALUES (?, ?, ?, ?)',
[teamId, userId, 'joinTeam', JSON.stringify({ joinMethod: 'invitationCode'
})]
);
res.json({ message: `Ви успішно приєдналися до команди
"${teamName}"!`, teamName });
} catch (error) {
console.error('Помилка при приєднанні до команди:', error);
res.status(500).json({ message: 'Не вдалося приєднатися до команди через
помилку сервера.' });
}
});
ДОДАТОК В
Затверджую
Завідувач кафедри КНСА
проф. Триус Ю.В.
_________________________
«____»______________2025 р.
ВЕБ-ОРІЄНТОВАНА ІНФОРМАЦІЙНА СИСТЕМА ДЛЯ УПРАВЛІННЯ
ЗАВДАННЯМИ ПРИ РОЗРОБЦІ IT-ПРОДУКТІВ
ІНСТРУКЦІЯ КОРИСТУВАЧА
482.ЧДТУ.52107-01 34 01
Листів 5
Розробник ________________ Волошина В. О.
Черкаси – 2025
143
Цей додаток містить інструкцію з використання веб-орієнтованої
інформаційної системи для управління завданнями. Інструкція охоплює основні
етапи взаємодії з системою, починаючи від доступу до неї та завершуючи базовими
операціями.
1. Взаємодія з системою розпочинається з головної сторінки (рис. Б.1). Ця
сторінка слугує візитівкою системи та надає користувачам дві основні опції
для подальшої роботи: вхід та реєстрацію. Кнопка «Увійти» призначена для
користувачів, які вже мають обліковий запис у системі. Натиснувши її,
користувач буде перенаправлений на сторінку авторизації.
Рисунок Б.1 – Головна сторінка веб-орієнтованої інформаційної системи для
управління завданнями
2. Для реєстрації в системі користувачу необхідно перейти на відповідну
сторінку, натиснувши кнопку «Зареєструватися» на головній сторінці. На
сторінці реєстрації (рис. Б.2) представлена форма, яка вимагає введення
імені, прізвища, електронної пошти та паролю. Введений пароль необхідно
підтвердити.
144
Рисунок Б.2 – Приклад заповнення форми реєстрації даними користувача
3. Після натискання кнопки «Зареєструватися» користувача буде
перенаправлено на дашборд. Оскільки користувач новий у системі, йому
висвітиться модальне вікно вибору відділів (рис. Б.3). У цьому вікні можна
обрати від одного до трьох відділів.
Рисунок б.3 – Приклад вибору відділів у модальному вікні для вибору відділів
4. Після натискання кнопки «Підтвердити» користувачу буде відображено
повідомлення про те, що відділи було обрано, і що для початку роботи із
завданнями необхідно приєднатися до існуючої команди або створити свою.
145
Вікно має дві кнопки – «Приєднатися» та «Створити».
5. При натисканні кнопки «Створити» користувача буде перенаправлено на
сторінку команд. Відкриється модальне вікно створення команди (рис. Б.4).
Для створення команди необхідно ввести назву та опис майбутньої команди.
Опис не є обов’язковим полем до заповнення.
Рисунок Б.4 – Приклад заповнення форми у модальному вікні створення команди
6. Після підтвердження створення команди на сторінці команд з'явиться картка
нової команди. При настиканні на кнопку «Керувати» відкриється модальне
вікно керування командою (рис. Б.5). У цьому вікні можна редагувати
команду, запрошувати нових учасників за електронною поштою, якщо вони
вже зареєстровані у системі та призначати менеджерів.
146
Рисунок Б.5 – Модальне вікно керування командою
7. При натисканні на картку команди користувача буде перенаправлена на
сторінку проєктів цієї команди. Створити новий проєкт можна натиснувши
кнопку «Додати проєкт» (рис. Б.6). У модальному вікні створення проєкту
необхідно ввести назву проєкту, опис за бажанням та вказати термін
виконання проєкту. По натисканню кнопки «Зберегти» буде створено новий
проєкт у межах команди (рис. Б.7).
Рисунок Б.6 – Модальне вікно створення проєкту
147
Рисунок Б.7 – Створений проєкт у межах команди
8. Якщо натиснути на картку проєкту, користувача буде перенаправлено на
сторінку завдань цього проєкту. Додати нове завдання до проєкту можна
натиснувши кнопку «Додати завдання» (рис. Б.8). У модальному вікні
додавання завдання необхідно ввести назву завдання, опис за бажанням,
додати вкладення – також опціонально, встановити дедлайн та обрати відділ.
Лише після вибору відділу можна обрати виконавця зі списку виконавців
цього відділу. До завдання можна призначити декілька виконавців. По
натисканню кнопки «Зберегти» нове завдання з'явиться у проєкті.
Рисунок Б.8 – Модальне вікно створення завдання
ДОДАТОК Г
Затверджую
Завідувач кафедри КНСА
проф. Триус Ю.В.
_________________________
«____»______________2025 р.
ВЕБ-ОРІЄНТОВАНА ІНФОРМАЦІЙНА СИСТЕМА ДЛЯ УПРАВЛІННЯ
ЗАВДАННЯМИ ПРИ РОЗРОБЦІ IT-ПРОДУКТІВ
Графічні матеріали
482.ЧДТУ.52107 90 01
Листів 12
Розробник ________________ Волошина В. О.
Черкаси – 2025
149
Рисунок Г.1 – Модальне вікно підтвердження вибору відділів
Рисунок Г.2 – Сторінка команд: створення нової команди
150
Рисунок Г.3 – Вікно керування командою: Учасники
Рисунок Г.4 – Вікно керування командою: Інформація
151
Рисунок Г.5 – Вікно копіювання коду запрошення у вкладці Запрошення модального
вікна керування командою
Рисунок Г.6 – Вікно запрошення учасників за електронною поштою у вкладці
Запрошення модального вікна керування командою
152
Рисунок Г.7 – Вікно керування командою: Додатково
Рисунок Г.8 – Модальне вікно підтвердження видалення команди
Рисунок Г.9 – Порожня сторінка проєктів команди
153
Рисунок Г.10 – Модальне вікно додавання нового проєкту
Рисунок Г.11 – Кнопки для редагування та видалення проєкту
Рисунок Г.12 – Модальне вікно редагування проєкту
Рисунок Г.13 – Модальне вікно підтвердження видалення проєкту
154
Рисунок Г.14 – Приклад фільтрації проєктів за статусом «В процесі»
Рисунок Г.15 – Приклад фільтрації проєктів за статусом виконання «В процесі» та за
часовим інтервалом «За місяць»
155
Рисунок Г.16 – Залишення коментаря на вкладці «Коментарі» модального вікна
перегляду завдання
Рисунок Г.17 – Вкладка «Вкладення» модального вікна перегляду завдання
156
Рисунок Г.18 – Форма додавання вкладень до завдання для виконавця
Рисунок Г.19 – Кнопки прийняття та відхилення завдання у вікні перегляду завдання
для менеджера
157
Рисунок Г.20 – Прийняте завдання зі статусом «Виконано»
Рисунок Г.21 – Сторінка профілю учасника команди
158
Рисунок Г.22 – Модальне вікно редагування аватара
Рисунок Г.23 – Модальне вікно редагування локації
159
Рисунок Г.24 – Модальне вікно редагування контактних даних
Рисунок Г.25 – Сторінка профілю користувача (відредагована)
Рисунок Г.26 – Введення причини відхилення завдання
160
Рисунок Г.27 – Відображення причини відхилення завдання у модальному вікні
перегляду завдання
Рисунок Г.28 – Створені події для автоматичної зміни статусів проєктів та завдань
ДОДАТОК Д
Затверджую
Завідувач кафедри КНСА
проф. Триус Ю.В.
_________________________
«____»______________2025 р.
ТЕЗИ ДОПОВІДЕЙ СТУДЕНТСЬКОЇ НАУКОВО-ПРАКТИЧНОЇ
КОНФЕРЕНЦІЇ ЧДТУ
Публікація по темі кваліфікаційної роботи бакалавра
482.ЧДТУ.52107 90 01
Листів 9
Розробник ________________ Волошина В. О.
Черкаси – 2025
162
163
WEB-ОРІЄНТОВАНА ІНФОРМАЦІЙНА СИСТЕМА
ДЛЯ УПРАВЛІННЯ ЗАВДАННЯМИ ПРИ РОЗРОБЦІ IT-ПРОДУКТІВ
Волошина В.О. (студентка ФІТІС), Дяченко П.В., к.т.н., доц.
Черкаський державний технологічний університет
У доповіді висвітлено питання створення web-орієнтованої
інформаційної системи для управління завданнями при розробці IT-продуктів.
Оскільки зростає кількість завдань та проєктів, виникає потреба у впровадженні
сучасних web- орієнтованих інформаційних систем для оптимізації робочих
процесів. Такі системи дозволяють забезпечити контроль над виконанням
завдань, що є важливим для успіху проєктів у галузі інформаційних технологій.
В роботі досліджено підходи до організації процесу управління
проєктами в IT-командах, проведено порівняльний аналіз існуючих
інструментів управління завданнями та визначено їх основні переваги і
недоліки. На основі аналізу аналогічних систем було сформовано вимоги до
web-орієнтованої інформаційної системи для управління завданнями. web-
орієнтований підхід забезпечує доступність системи з будь-якого пристрою, що
має підключення до мережі Інтернет. Архітектура передбачає використання
клієнт-серверної моделі, де серверна частина відповідає за обробку даних та
бізнес-логіку, а клієнтська – за інтерфейс користувача. Основними
функціональними можливостями розробленої системи є створення,
редагування та видалення проєктів і завдань, призначення відповідальних осіб,
а також контроль статусу виконання. web-орієнтована інформаційна система
для управління завданнями створена з використанням сучасних web-
технологій, що забезпечують її масштабованість та зручність у використанні.
Запропоноване рішення допомагає підвищити ефективність управління
завданнями в IT-командах, оптимізувати робочі процеси, знизити кількість
помилок при плануванні та виконанні завдань, а також покращити взаємодію
між членами команди.
164
165
Дяченко Петро Васильович
к. т. н., доц., доцент кафедри компʼютерних наук та системного аналізу,
Черкаський державний технологічний університет, м. Черкаси, Україна
Волошина Вікторія Олександрівна
здобувач вищої освіти 1-го (бакалаврського) рівня
РОЗРОБКА ВЕБ-САЙТУ ДЛЯ УПРАВЛІННЯ ЗАВДАННЯМИ
Управління завданнями в управлінні проєктами – це процес планування,
організації та виконання завдань в рамках проєкту для досягнення конкретних
цілей і завдань. Він включає в себе визначення завдань, розподіл обов’язків,
встановлення дедлайнів і моніторинг прогресу, щоб гарантувати, що проєкти
будуть завершені вчасно і в рамках бюджету. Ефективне управління завданнями
має вирішальне значення для успіху проєкту, оскільки допомагає командам
залишатися організованими, визначати пріоритети в роботі та ефективно
досягати бажаних результатів [1].
Управління завданнями є важливою складовою ефективної роботи як для
окремих користувачів, так і для команд у різних сферах діяльності. Завдяки
розвитку веб-технологій, з’являється все більше онлайн-платформ для
організації та контролю за виконанням завдань. Такі веб-сайти дають змогу
користувачам створювати, відстежувати та виконувати завдання в режимі
реального часу. Вони є особливо корисними для команд, що працюють над
спільними проєктами, оскільки забезпечують прозорість виконання завдань,
ефективну комунікацію та можливість спільної роботи. Крім того, такі системи
дозволяють централізовано зберігати інформацію про всі завдання, надаючи
користувачам можливість швидко звертатися до історії завдань та переглядати
їхній прогрес.
Сьогодні існує безліч платформ для спільного планування та управління
завданнями, які пропонують різноманітні функції для оптимізації робочого
процесу. Проте, через широкий вибір інструментів та налаштувань,
користувачам може бути важко розібратися, особливо якщо у них немає
попереднього досвіду роботи з такими системами. Тим не менше, основні
166
переваги цих платформ полягають у можливості отримувати повний контроль
над завданнями та працювати спільно в реальному часі, що сприяє ефективній
організації робочих процесів.
Розробка веб-сайту для управління завданнями вимагає створення
інтуїтивно зрозумілого інтерфейсу, який забезпечить простоту використання та
ефективне управління завданнями. Одним із важливих аспектів є наявність
можливостей для детального опису завдань, визначення їх пріоритетів та
термінів виконання, що допомагає учасникам проєкту чітко усвідомлювати обсяг
роботи, відповідальність та строки виконання кожного завдання.
Система повинна містити інструменти для моніторингу процесу виконання
завдань, що дозволятимуть учасникам бачити, на якому етапі знаходиться кожне
завдання, а також своєчасно виявляти затримки чи проблеми. Сповіщення про
зміни статусу завдання або наближення дедлайнів повинні допомагати командам
швидко адаптуватися до ситуації.
Іншою важливою функцією має бути можливість призначення завдань
конкретним членам команди, що дасть змогу чітко визначити відповідальність
та запобігти дублюванню зусиль, сприяючи ефективному розподілу ресурсів і
забезпеченню рівномірного навантаження на команду.
Крім того, система повинна підтримувати функції для спільної роботи над
завданнями, включаючи можливість коментування та прикріплення файлів до
завдань. Такий підхід забезпечить зручну і швидку комунікацію між членами
команди, підвищуючи прозорість процесу виконання завдань і зменшуючи
ймовірність виникнення помилок або непорозумінь [2].
Метою цього проєкту є створення веб-сайту для ефективного управління
завданнями в IT-компаніях, що дозволяє користувачам зручно відстежувати,
планувати і контролювати процеси виконання завдань в реальному часі.
Результатом реалізації проєкту є веб-сайт, що має такі характеристики:
підтримка популярних браузерів та адаптивний дизайн для різних
пристроїв;
167
можливість ефективного управління завданнями та моніторингу
їх виконання в реальному часі;
інтеграція з поштовими системами для отримання сповіщень про зміни
в завданнях та наближення термінів їх виконання.
Завдання, які необхідно вирішити в рамках реалізації проєкту:
провести аналіз сучасних платформ для управління завданнями, таких
як Trello, Asana, Jira, з метою вивчення функціональних можливостей,
архітектурних рішень та інтерфейсу користувача. Результати аналізу стануть
основою для формування вимог до розроблюваного веб-сайту;
сформувати функціональні вимоги до веб-сайту, зокрема забезпечити
можливість створення, редагування, видалення завдань, встановлення
пріоритетів, контролю дедлайнів, фільтрації та сортування завдань;
розробити дизайн інтерфейсу користувача, орієнтованого на простоту
використання, інтуїтивну навігацію та ефективне управління завданнями;
реалізувати функціонал веб-сайту за допомогою HTML, CSS, Node.js та
MySQL;
забезпечити інтеграцію бази даних MySQL для зберігання даних про
завдання, статуси та користувачів, а також для забезпечення їх надійної
взаємодії з іншими компонентами системи;
провести тестування розробленого веб-сайту для виявлення та
усунення можливих недоліків, перевірки продуктивності, сумісності з
браузерами та зручності використання.
Використовувані засоби:
HTML/CSS;
Node.js;
MySQL.
Розробка веб-сайту для управління завданнями в IT-компаніях дозволить
забезпечити користувачам ефективний інструмент для планування, організації та
моніторингу виконання завдань в реальному часі. Веб-сайт буде включати всі
168
необхідні функції для створення, редагування, видалення завдань, визначення
пріоритетів, встановлення дедлайнів та контролю за їх виконанням. Система
забезпечить централізоване зберігання даних про завдання та статуси, завдяки
чому користувачі зможуть швидко отримувати інформацію про виконання
Результатом реалізації проєкту стане стабільний та зручний веб-ресурс,
який дозволить підвищити продуктивність роботи команд, забезпечити
ефективну комунікацію та управління завданнями. Користувачі зможуть
відстежувати прогрес виконання завдань через інтуїтивно зрозумілий інтерфейс,
а також своєчасно отримувати сповіщення про зміни статусу завдань та
наближення дедлайнів. Веб-сайт також надасть можливість аналізувати хід
виконання завдань та визначати області для оптимізації робочих процесів.
Список літератури
1. What is Task Management? [Електронний ресурс]. – Режим доступу:
https://www.geeksforgeeks.org/what-is-task-management/. (дата звернення
02.11.2024).
2. Task Management Software Key Elements to Check Out. [Електронний
ресурс]. – Режим доступу: https://projectsly.com/task-management-software-key-
elements. (дата звернення 02.11.2024).
3. Live Business UA. Рейтинги приложений [Електронний ресурс]. – Режим
доступу: http:/ /www.livebusiness.com.ua/tools/shop. (дата звернення 02.11.2024).
169
СТВОРЕННЯ ВЕБ-СЕРВІСУ ДЛЯ УПРАВЛІННЯ ЗАВДАННЯМИ
Волошина В. О. (студентка ФІТІС), Дяченко П. В., к.т.н, доц.
Черкаський державний технологічний університет
У доповіді розглядається питання створення веб-орієнтованої інформаційної
системи для управління завданнями при розробці IT-продуктів. Оскільки зростає
кількість завдань та проєктів, виникає потреба у впровадженні сучасних веб-
орієнтованих інформаційних систем для оптимізації робочих процесів. Такі системи
дозволяють забезпечити контроль над виконанням завдань, що є важливим для успіху
проєктів у галузі інформаційних технологій.
Досліджено підходи до організації процесу управління проєктами в IT-
командах, проведено порівняльний аналіз існуючих інструментів управління
завданнями та визначено їх основні переваги і недоліки. На основі аналізу
аналогічних систем було сформовано вимоги до веб-орієнтованої інформаційної
системи для управління завданнями.
Веб-орієнтований підхід забезпечує доступність системи з будь-якого
пристрою, що має підключення до мережі Інтернет. Архітектура передбачає
використання клієнт-серверної моделі, де серверна частина відповідає за обробку
даних та бізнес-логіку, а клієнтська – за інтерфейс користувача. Основними
170
функціональними можливостями розробленої системи є створення, редагування та
видалення проєктів і завдань, призначення відповідальних осіб, а також контроль
статусу виконання.
Веб-орієнтована інформаційна система для управління завданнями створена з
використанням сучасних веб-технологій, що забезпечують її масштабованість та
зручність у використанні. Запропоноване рішення допомагає підвищити ефективність
управління завданнями в IT-командах, оптимізувати робочі процеси, знизити
кількість помилок при плануванні та виконанні завдань, а також покращити
взаємодію між членами команди.