Управління проєктом створення веб-орієнтованої інформаційної системи групової експертизи

Єфімов, Віктор Вадимович

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

Full metadata record

DC Field	Value	Language
dc.contributor.advisor	Триус, Юрій Васильович	-
dc.contributor.author	Єфімов, Віктор Вадимович	-
dc.date.accessioned	2026-01-11T11:25:26Z	-
dc.date.available	2026-01-11T11:25:26Z	-
dc.date.issued	2023-12-21	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/6741	-
dc.description.abstract	Використання інформаційних експертних систем дозволяє автоматизувати процес експертного оцінювання за допомогою інтерфейсу анкетування для експертів і також інтерфейсу опису задачі прийняття рішень для організатора експертизи. Система повідомляє як організатора про стан проведення експертизи, так й експертів для підключення до процесу експертизи. Розробка експертної системи є актуальною темою, тому що її використання підвищує ефективність підприємств та має потенціал для подальшого її розвитку. Метою кваліфікаційної роботи магістра є управління проєктом створення веб-орієнтованої інформаційної системи групової експертизи. Об’єкт дослідження: процес управління проєктом зі створення інформаційної системи. Предмет дослідження: проєкт розробки веб-орієнтованої інформаційної системи групової експертизи. Методи дослідження. Системний аналіз, сітьове планування, метод декомпозиції, методи управління ризиками, метод бюджетування «знизу-нагору», SWOT-аналіз, PEST-аналіз, прийоми програмування на мовах програмування. Апробація результатів роботи. Основні положення і результати кваліфікаційної роботи магістра доповідалися і були обговорені на студентській науково-практичній конференції ЧДТУ (18 квітня 2023р.). Публікації. Результати кваліфікаційної роботи магістра опубліковані у збірнику тез доповідей студентської науково-практичної конференції ЧДТУ за 2023 р.: Єфімов В.В, Триус Ю.В. Розробка ІТ-проєкту веб-орієнтованої інформаційної системи групової експертизи // Збірник тез доповідей студентської науково-практичної конференції ЧДТУ: 18–20 квіт. 2023 р. [Електронний ресурс] / [упоряд. : Єгорова О. В., Захарова О. В., Кисельов В. Б. та ін.] ; М-во освіти і науки України, Черкас. держ. технол. ун-т. Черкаси : ЧДТУ, 2023. С. 28.	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	ІНФОРМАЦІЙНА СИСТЕМА	uk_UA
dc.subject	ГРУПОВА ЕКСПЕРТИЗА	uk_UA
dc.subject	МАІ	uk_UA
dc.subject	NODE.JS	uk_UA
dc.subject	REACT	uk_UA
dc.subject	MONGODB	uk_UA
dc.subject	EXPRESS	uk_UA
dc.subject	MS PROJECT	uk_UA
dc.subject	УПРАВЛІННЯ ПРОЄКТОМ.	uk_UA
dc.title	Управління проєктом створення веб-орієнтованої інформаційної системи групової експертизи	uk_UA
dc.type	Master Thesis	uk_UA
Appears in Collections:	122 Комп’ютерні науки (Управління стартапами і проектами в галузі інформаційних технологій)

Files in This Item:

File	Description	Size	Format
Пояснювальна записка_ Єфімов Віктор_МСТП-2202_2023-2024.pdf Restricted Access		2.33 MB	Adobe PDF	View/Open Request a copy

Show simple item record

Extracted text

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

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

Кафедра комп’ютерних наук та системного аналізу

Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)

на тему: «Управління проєктом створення веб-орієнтованої інформаційної
системи групової експертизи»

Виконав: студент 2 курсу, групи МСТП-2202

спеціальності 122  «Комп’ютерні науки»
(шифр і назва спеціальності)

освітня програма «Управління стартапами і
проєктами в галузі інформаційних
технологій»
(назва освітньої програми)

Єфімов Віктор Вадимович

Керівник __________ Триус Ю.В.
(прізвище та ініціали)

Рецензент _________ Богатирьов О.О.
(прізвище та ініціали)

Черкаси 2023 рік
2
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітній рівень Магістр
Спеціальність 122 – комп’ютерні науки
Освітня програма Управління стартапами і проєктами в галузі інформаційних технологій

«ЗАТВЕРДЖУЮ»
Завідувач кафедри КНСА
____________ Юрій ТРИУС
«06» жовтня 2023 року

ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Єфімову Віктору Вадимовичу
(прізвище, ім’я, по батькові)
1. Тема роботи: «Управління проєктом створення веб-орієнтованої інформаційної системи
групової експертизи»

Керівник роботи Триус Ю.В., д.п.н., к.ф.-м.н., професор
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «06» жовтня 2023 р. № 267/04.

2. Строк подання студентом роботи 19.12.2023
3. Вихідні дані до роботи:
Практичні навички роботи з інформаційними ресурсами.
Звіт з переддипломної практики.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ.
4.1. Аналіз оточення проєкту.
4.2. Розробка концепції проєкту.
4.3. Розробка проєкту.
4.4. Практична реалізація проєкту.
Висновки.
Список використаних джерел.
5. Перелік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. Специфікація 482.ЧДТУ. 21802-01.

3
5.2. Додаток Б. Текст програми.
5.3. Додаток В. Інструкція користувача.
5.5. Додаток Д. Публікація по темі кваліфікаційної роботи магістра.
6 . Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
завдання видав завдання прийняв
консультанта

7. Дата видачі
завдання 06 жовтня 2023 року

КАЛЕНДАРНИЙ ПЛАН
№ Строк виконання
Назва етапів кваліфікаційної роботи магістра Примітка
з/п етапів роботи
1 Видача завдання на кваліфікаційну роботу 1.09.2023 - виконано
магістра. 2.10.2023
2 Аналіз літературних джерел, об’єкту та 3.10.2023 - виконано
предмету дослідження. 20.10.2023
3 Написання теоретичного розділу 21.10.2023 - виконано
кваліфікаційної роботи магістра. 5.11.2023
4 Написання аналітичного розділу (аналіз 6.11.2023 - виконано
об’єкту й предмету дослідження). 20.11.2023
5 Написання практичних розділів й висновків 21.11.2023 - виконано
кваліфікаційної роботи магістра. 5.12.2023
6 Передзахист кваліфікаційної роботи магістра виконано
13.12.2023
на засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри КНСА. 19.12.2023 виконано
8 Захист кваліфікаційної роботи магістра. 21.12.2023 виконано

Студент _____________________________ Єфімов В. В.
(підпис)
Керівник роботи ____________________________ Триус Ю.В.
(підпис)

4
РЕФЕРАТ
Кваліфікаційна робота магістра містить: 75 с., 37 рис., 9 таблиць, 13
використаних джерел, 4 додатки.
Актуальність теми. Використання інформаційних експертних систем
дозволяє автоматизувати процес експертного оцінювання за допомогою
інтерфейсу анкетування для експертів і також інтерфейсу опису задачі прийняття
рішень для організатора експертизи. Система повідомляє як організатора про стан
проведення експертизи, так й експертів для підключення до процесу експертизи.
Час та гроші, які були потрібні на організацію експертизи тепер,
використовуючи інформаційну систему групової експертизи, можна витратити на
сам процес анкетування (оцінювання) експертів.
Розробка власної інформаційної системи для проведення групових експертиз
дозволяє налаштувати усі потрібні функції під ключ. Від інтерфейсу до додаткових
модулів для системи. Наприклад, додавання нових експертних методів. Можна
зробити систему модульною для полегшення її майбутнього розвитку.
Розробка експертної системи є актуальною темою, тому що її використання
підвищує ефективність підприємств та має потенціал для подальшого її розвитку.
Мета роботи і задачі дослідження. Метою кваліфікаційної роботи магістра
є управління проєктом створення веб-орієнтованої інформаційної системи групової
експертизи.
Для досягнення поставленої мети в роботі розв’язуються наступні завдання:
– проаналізувати оточення проєкту;
– розробити концепцію проєкту;
– спланувати проєкт згідно стандарту PMBoK;
– створити моделі баз даних;
– розробити серверну частину системи;
– розробити клієнтську частину системи.
Розроблений модуль повинен бути доступним в мережі Internet користувачам
для експертного аналізу реальних задач і проблем, а також студентам закладів
5
вищої освіти (ЗВО), які вивчають експертні технології прийняття рішень та їх
використання.
Об’єкт дослідження: процес управління проєктом зі створення
інформаційної системи.
Предмет дослідження: проєкт розробки веб-орієнтованої інформаційної
системи групової експертизи.
Методи дослідження. Системний аналіз, сітьове планування, метод
декомпозиції, методи управління ризиками, метод бюджетування «знизу-нагору»,
SWOT-аналіз, PEST-аналіз, прийоми програмування на мовах програмування.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи магістра доповідалися і були обговорені на студентській
науково-практичній конференції ЧДТУ (18 квітня 2023р.).
Публікації. Результати кваліфікаційної роботи магістра опубліковані у
збірнику тез доповідей студентської науково-практичної конференції ЧДТУ за
2023 р.: Єфімов В.В, Триус Ю.В. Розробка ІТ-проєкту веб-орієнтованої
інформаційної системи групової експертизи // Збірник тез доповідей студентської
науково-практичної конференції ЧДТУ: 18–20 квіт. 2023 р. [Електронний ресурс] /
[упоряд. : Єгорова О. В., Захарова О. В., Кисельов В. Б. та ін.] ; М-во освіти і науки
України, Черкас. держ. технол. ун-т. Черкаси : ЧДТУ, 2023. С. 28.
Перелік ключових слів: ІНФОРМАЦІЙНА СИСТЕМА, ГРУПОВА
ЕКСПЕРТИЗА, МАІ, NODE.JS, REACT, MONGODB, EXPRESS, MS PROJECT,
УПРАВЛІННЯ ПРОЄКТОМ.

6
ABSTRACT
Master’s work contains. 75 pages, 37 figures, 9 tables, 13 sources used, 4
attachments.
Actuality of theme. The use of information expert systems allows you to automate
the expert examination process using the questionnaire interface for experts and also the
decision-making task description interface for the expert examination organizer. The
system notifies both the organizer about the status of the examination and the experts to
connect to the examination process.
The development of your own information system for conducting group
examinations allows you to set up all the necessary functions on a turnkey basis. From
the interface to additional modules for the system. For example, adding new expert
methods. It is possible to make the system modular to facilitate its future development.
The development of an expert system is a relevant topic, because its use increases
the efficiency of enterprises and has the potential for its further development.
Purpose and tasks of the research.
The purpose of the work and research tasks: The purpose of the master's
qualification work is to manage the project of developing a web-oriented information
system of group expertise.
To achieve the set goal, the following tasks are solved in the work:
- analyze the project environment;
- develop the project concept;
- plan the project according to the PMBoK standard;
- create database models;
- develop the server part of the system;
- develop the client part of the system.
The developed module should be available on the Internet to users for expert
analysis of real tasks and problems, as well as to students of higher education institutions
(HEIs) who study expert decision-making technologies and their use.
The object of research: the process of managing a project to develop an
information system.
7
The subject of research: the project of developing a web-oriented information
system of group expertise.
Research methods. System analysis, network planning, decomposition method,
risk management methods, bottom-up budgeting method, SWOT analysis, PEST
analysis, programming techniques in programming languages.
Approbation of work results. The main provisions and results of the master's
qualification work were reported and discussed at the student scientific and practical
conference of ChSTU (April 18, 2023).
Publications. The results of the master's qualification work were published in the
collection of abstracts of reports of the student scientific and practical conference of
ChSTU for 2023: Yefimov V.V., Tryus Yu.V. Development of an IT project of a web-
oriented information system of group expertise
The list of keywords: INFORMATION SYSTEM, GROUP EXPERTISE, AHP,
NODE.JS, REACT, MONGODB, EXPRESS, MS PROJECT, PROJECT
MANAGEMENT.

8
ЗМІСТ
ВСТУП ............................................................................................................................ 10
1 АНАЛІЗ ОТОЧЕННЯ ПРОЄКТУ ............................................................................. 12
1.1 Постановка та обгрунтування проблеми ........................................................... 12
1.2 Опис ідеї майбутнього проєкту .......................................................................... 15
1.3 Варіанти вирішення щодо реалізації ідеї .......................................................... 17
1.4 Огляд інсуючих систем для експертного оцінювання ..................................... 19
1.4.1 Веб-ресурс «EasyAHP». ................................................................................ 19
1.4.2 Веб-ресурс «Decisioner». ............................................................................... 22
1.4.3 Веб-ресурс «123ahp». .................................................................................... 24
Висновки до розділу 1 ............................................................................................... 26
2 КОНЦЕПЦІЯ ПРОЄКТУ ........................................................................................... 27
2.1 Загальна концепція проєкту ................................................................................ 27
2.2 Структура продукту проєкту .............................................................................. 30
2.3 SWOT аналіз проєкту .......................................................................................... 33
2.4 Стратегія реалізації проєкту ............................................................................... 36
Висновки до розділу 2 ............................................................................................... 40
3 РОЗРОБКА ПРОЄКТУ .............................................................................................. 42
3.1 Планування змісту ............................................................................................... 42
3.2 Планування часу проєкту .................................................................................... 45
3.3 Планування трудових ресурсів ........................................................................... 49
3.4 Планування якості ................................................................................................ 53
3.5 Планування ризиків ............................................................................................. 54
Висновки до розділу 3 ............................................................................................... 56
4 ПРАКТИЧНА РЕАЛІЗАЦІЯ ..................................................................................... 57
4.1 Технології для розробки продукту проєкту ...................................................... 57
4.1.1 База даних MongoDB. ................................................................................... 57
4.1.2 Express. ............................................................................................................ 58
4.1.3 React. ............................................................................................................... 58
4.1.4 Node.js. ............................................................................................................ 59
9
4.2 Проєктування моделей бази даних..................................................................... 60
4.3 Розробка продукту проєкту................................................................................. 66
4.4 Розробка інтерфейсу системи ............................................................................. 70
Висновки до розділу 4 ............................................................................................... 73
ВИСНОВКИ ................................................................................................................... 74
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ..................................................................... 75

10
ВСТУП
У наш час будь-який бізнес все більше й більше стикається з ситуаціями, коли
потрібно прийняти важливе рішення. Зазвичай для цього залучаються експерти з
потрібної галузі та проводиться групова експертиза. Але у наш час проводити
експертизи традиційним (оффлайн) способом становиться складніше й складніше
у зв’язку з тим, що ситуація в Україні (та й у інших країнах теж) становиться все
більш небезпечною через пандемії та агресію інших країн.
Для того, щоб зробити процес групового експертного оцінювання більш
гнучким та безпечним потрібно надати можливість проводити їх дистанційно.
Це надає експертам можливість надати свою експертну оцінку у безпечному
середовищі, де експерт може виконати свою роботу у стані спокою. Також це
дозволяє значно зменшити витрати на експертизу, оскільки потрібно лише описати
суть задачі прийняття рішень та встановити терміни виконання, не витрачаючи час
та гроші на її організацію традиційним способом.
Для створення веб-орієнтованого програмного забезпечення, що реалізує
індивідуальну та групову експертизу, використано сучасні інформаційні
технології, а саме: базу даних MongoDB, фреймворк Express, фреймворк React та
Node.js. Обрані технології задовольняють всім потребам та вимогам проєкту, що
розробляється.
Після впровадження системи організатори експертиз зможуть залучати до
них потрібних експертів для проведення всього процесу експертування онлайн.
Експерти зможуть вносити у систему свої експертні оцінки для подальшого їх
опрацювання системою відповідно до обраного організатором експертного методу.
До кожного методу буде написана інструкція, тому експерт зможе не вивчаючи
теорію обраного методу виконати свою роботу.
Мета роботи і задачі дослідження. Мета кваліфікаційної роботи
магістра – управління проєктом створення веб-орієнтованої інформаційної
системи групової експертизи.
Для досягнення поставленої мети в роботі розв’язуються наступні завдання:
11
– проаналізувати оточення проєкту;
– розробити концепцію проєкту;
– спланувати проєкт згідно стандарту PMBoK;
– створити моделі баз даних;
– розробити серверну частину системи;
– розробити клієнтську частину системи.
Розроблена система повинна бути доступною в мережі Internet для
користувачів для проведення групових експертиз щодо вирішення реальних задач
прийняття рішень, а також студентам закладів вищої освіти (ЗВО), які будуть
вивчати експертні технології прийняття рішень.
Об’єкт дослідження: процес управління проєктом зі створення
інформаційної системи.
Предмет дослідження: проєкт розробки веб-орієнтованої інформаційної
системи групової експертизи.
Методи дослідження. Системний аналіз, сітьове планування, метод
декомпозиції, методи управління ризиками, метод бюджетування «знизу-нагору»,
SWOT-аналіз, PEST-аналіз, прийоми програмування на мовах програмування.
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи магістра доповідалися і були обговорені на студентській
науково-практичній конференції ЧДТУ (18 квітня 2023р.).
Публікації. Результати кваліфікаційної роботи магістра опубліковані у
збірнику тез доповідей студентської науково-практичної конференції ЧДТУ за
2023 р.: Єфімов В.В, Триус Ю.В. Розробка ІТ-проєкту веб-орієнтованої
інформаційної системи групової експертизи // Збірник тез доповідей студентської
науково-практичної конференції ЧДТУ: 18–20 квіт. 2023 р. [Електронний ресурс] /
[упоряд. : Єгорова О. В., Захарова О. В., Кисельов В. Б. та ін.] ; М-во освіти і науки
України, Черкас. держ. технол. ун-т. Черкаси : ЧДТУ, 2023. С. 28.
12
1 АНАЛІЗ ОТОЧЕННЯ ПРОЄКТУ
1.1 Постановка та обгрунтування проблеми
У наш час прийняття рішень є одним з найважливіших процесів у керуванні
бізнесом та будь-якими процесами у всіх галузях, де потрібно приймати рішення.
У випадку, коли рішення не є очевидним та воно буде мати довгострокові наслідки,
потрібно залучити експертів для пошуку ефективного рішення. Для цього потрібно
організувати індивідуальну або групову експертизу з залученням відповідних
фахівців. Цей процес займає багато часу, оскільки організація експертизи
складається з кількох затратних по часу етапів:
- пошук і залучення експертів;
- організація роботи експертів;
- проведення опитування (анкетування) експертів;
- опрацювання результатів опитування (анкетування) експертів;
- агрегація результатів групи експертів;
- інтерпретація результатів експертизи.
Якщо проводити експертизу традиційним способом, то потрібно спочатку
знайти експертів з потрібної галузі, потім зібрати їх у одному місці (організувати
зустріч), провести опитування на паперових носіях і потім проводити опрацювання
результатів експертизи вручну, тобто проводити усі обчислення вручну, і
наприкінці інтерпретувати результат.
Як бачимо, ці процеси є не лише витратними за часом, але й складними у
реалізації. Знайти зручний час для всіх експертів для проведення експертизи
оффлайн – задача прийняття рішень сама по собі й займає багато часу та зусиль. Не
факт, що знайдеться зручний час, щоб усі експерти змогли оперативно зібратися в
одному місці. Навіть, якщо такий час знайдеться, то експертам доведеться
добиратися до місця проведення експертизи. Це втрата часу самого експерта, а
також може бути ситуація, коли експерт мешкає дуже далеко від місця збору (у
іншому місті або навіть країні).
13
При проведенні опитування (анкетування) експертів також є певні
складності. На роботу експертів можуть вплинути багато факторів, зокрема:
- некомфортні умови середовища, де відбувається експертне оцінювання;
- негативний емоційний і психологічний стан експертів (наприклад: втома
після довгої подорожі до місця проведення експертизи; сторонні думки, що
турбують і відволікають експерта);
- присутність на експертизі, осіб, з якими є певні проблеми при спілкуванні.
Опрацювання анкет експертів також є складним процесом й потребує від
організатора експертизи певних навичок в галузі прийняття рішень та знань
відповідних методів прийняття рішень. Наприклад, при використанні методу
аналізу ієрархій для прийняття рішень організатор експертизи повинен знайти
особливості цього методу, зокрема формули для знаходження векторів пріоритетів
для відповідних матриць та для перевірки узгодженості думок експертів тощо.
Тому проведення обчислень за цим методом потребує, як правило, залучення
аналітиків, які беруть участь в опрацюванні результатів роботи експертів, що
вимагає додаткових часових і фінансових витрат.
Проблема, що виникає, при проведенні групової експертизи – занадто велика
витратність як часу, так й трудовитрат організатора експертизи, експертів й
аналітиків, складність процесу опрацювання результатів експертизи і пошуку
найкращого рішення.
Для вирішування цієї проблеми розробляється веб-орієнтована система
підтримки прийняття рішень з можливістю проведення індивідуальних і групових
експертиз. Система надасть можливість проводити експертизи онлайн і вирішити
багато проблем, що виникають при організації експертизи.
Організатор за допомогою цієї системи зможе створити завдання на
проведення експертизи, знайти експертів з потрібної галузі у базі даних системи,
запросити їх до проведення експертизи й отримати згоду на участь у ній. Запрошені
експерти зможуть внести до відповідної форми свої експертні думки у зручний для
них час протягом певного терміну. Це економить час як організатора, так й
експертів. При цьому можна залучати експертів навіть з інших країн.
14
Експерт зможе швидко внести свою експертну думку в систему за допомогою
зручного інтерфейсу. На відміну від оффлайн експертизи, перевірка на
узгодженість його думки (де це потрібно) буде проведена автоматично, що значно
економить час і забезпечить якість експертного оцінювання. Усі процеси прийняття
рішень будуть автоматизовані системою.
Опрацювання заповнених анкет буде проводитися в автоматичному режимі,
що звільняє організатора від проведення складних математичних операцій. Тобто
організатор може обрати навіть найскладніші експертні методи (наприклад метод
аналітичних мереж) без страху витрачати час на обрахунки у майбутньому та
унеможливлює будь-які помилки у проміжних та фінальних результатах.
Агрегування думок групи експертів також проводиться в автоматизованому
режимі.
Для вирішування зазначеної проблеми система повинна задовольняти
наступним умовам:
- дані про експертів, які в ній зареєстровані, повинні бути актуальними і
доступними для організаторів експертизи;
- повинен бути модуль для налаштування ролей;
- підтримка організації групових експертиз;
- повинна бути забезпечена процедура запрошення експертів до експертизи;
- повинно бути гарантована безпечність зберігання конфіденційних даних;
- повинні бути реалізовані кілька найбільш поширених експертних методів
прийняття рішень, зокрема: метод нормування, метод ранжування, метод
аналізу ієрархій;
- забезпечення автоматизації процесів пошуку ефективного рішення
(знаходження розв’язку) за обраним методом.
Система може бути використана при розв’язанні задач з будь-якої галузі з
використанням експертних методів прийняття рішень. Наприклад, один з
реалізованих у системі методів, «метод аналізу ієрархій» має широке застосування
для розв’язання задач прийняття рішень.
15
Очікуваним ефектом від розробки системи є значне зменшення
навантаження на учасників експертизи та значне зменшення часових і фінансових
витрат на організацію і проведення експертизи.
1.2 Опис ідеї майбутнього проєкту
Ідея проєкту – розробити веб-орієнтовану систему підтримки прийняття
рішень з можливістю проведення індивідуальних і групових експертиз, яка буде
реалізовувати декілька експертних методів та буде інтуїтивно зрозумілою у
використанні.
Користувачі цієї системи зможуть використати реалізовані експертні методи
для прийняття рішень у різних галузях діяльності людини від побутових проблем
до керування малим і середнім бізнесом. Система зробить найскладніші методи
прийняття рішень доступними для кожного бажаючого. Система дозволить
проводити як індивідуальні експертизи, які використовуються зазвичай для
особистого використання, так й групові експертизи, які вже використовують при
прийнятті важливих бізнес-рішень.
Система повинна мати наступні підсистеми:
- підсистема реєстрації, авторизації та аутентифікації;
- підсистема ролей;
- підсистема особистого кабінету;
- підсистема керування експертизами;
- підсистема адміністрування;
- підсистема запрошень до групових експертиз;
- підсистема створення шаблонів анкет / форм опитування;
- підсистеми реалізації експертних методів:
- підсистема інтерпретації результатів.
Система буде орієнтована на мінімізацію витрат на супроводження. Для її
роботи буде достатньо одного домену та одного кластеру бази даних. Тобто
система буде монолітною (уся система є цілою, не розподіленою).
16
Процес проведення експертизи буде наступним: організатор (модератор)
створює завдання на групову експертизу, розсилає запрошення експертам та очікує
їх згоди, експерти, які погодилися брати участь в експертизі, вносять свої експертні
оцінки до відповідних шаблонів анкет чи форм опитування, система опрацьовує
результати анкетування за обраним методом, потім організатор експертизи
ознайомлюється з результатами експертного оцінювання.
Процес експертного оцінювання подано на рисунку 1.1.

Рисунок 1.1 – Процес експертного оцінювання
17
Концептуальна модель системи наведена у рисунку 1.2.

Рисунок 1.2 – Концептуальна модель системи
1.3 Варіанти вирішення щодо реалізації ідеї
Реалізація системи підтримки прийняття рішень можлива не лише у вигляді
веб-додатку. Систему можна реалізувати у вигляді мобільного додатку або
18
програмного забезпечення для ПК (desktop). Проаналізуємо усі переваги та
недоліки кожної реалізації.
Веб-додаток.
Ця реалізація має багато переваг. По-перше, весь проєкт можна реалізувати
на javascript, використовуючи певні фреймворки. Це полегшує процес розробки у
рази. Javascript є легкою мовою для створення такого роду систем. Перевагою є те,
що розроблений продукт буде доступний на усіх можливих платформах, які
підтримують роботу веб-браузерів. Одна версія проєкту може бути запущеною як
на ПК на різних операційних система, так й на мобільних пристроях. Універсальна
кросплатформеність гарантована цим методом. Інтерфейс системи може бути
адаптованим для мобільних пристроїв та буде доступний будь-де, якщо є доступ до
мережі Інтернет.
Також система може супроводжуватись іншими людьми у майбутньому,
оскільки фахівців з розробки веб-додатків зараз багато і вони вміють працювати з
потрібними фреймворками. Тобто у подальшому можливий перехід на outsource
для супроводження та подальшого розвитку системи, зокрема реалізації інших
методів прийняття рішень.
Мобільний додаток.
Операційні системи мобільних телефонів постійно оновлюються й, навіть,
якщо у певного пристрою немає можливості для оновлення, то старі версії
підтримуються протягом років. Це стосується як ОС Android, так й IOS. Якщо
розробити систему як мобільний додаток, то можна бути впевненими, що додаток
буде працювати стабільно роками.
Мобільні додатки також мають можливість працювати у оффлайн режимі,
тобто експерт може працювати з системою у дорозі або якщо не буде доступу до
мережі Інтернет. Це певна перевага над веб-додатком. Разом з тим, експерт
повинен вносити свої експертні оцінки у стані спокою та повинен бути повністю
зосередженим на експертизі. Експерт не повинен працювати з системою будь-де (в
дорозі, у міському транспорті), він повинен працювати у своєму офісі чи кімнаті,
де не буде відволікаючих факторів.
19
Desktop-додаток.
Реалізація системи як програмне забезпечення для ПК має суттєві недоліки.
Додаток повинен бути реалізованим для багатьох платформ. Хоча б для OC
Windows, MacOS та Linux. Кожна версія повинна супроводжуватись та
оновлюватись, що вимагає багато часу розробника. Можна розробити додаток на
мові програмування Java, що звільняє розробника від такого навантаження,
оскільки Java-додатки підтримуються будь-якою системою, що надає можливість
експертам працювати на будь якій операційній системі. Це перевага, яка дійсно є
важливою, але не тільки ця реалізація має цю перевагу.
Java є складною мовою програмування для розробки систем. Для реалізації
системи таким методом буде потрібно багато часу.
Зручний інтерфейс, який є необхідним для швидкого внесення експертних
оцінок, може бути реалізований в усіх можливих реалізаціях. Але простота
розробки системи та її супроводження відрізняється. Порівняння варіантів
реалізації подано у таблиці 1.1.
Таблиця 1.1 – Порівняння варіантів реалізації.
Реалізація Зручний Кросплатформеність Простота Простота
інтерфейс розробки супроводження
Мобільний + - - +
додаток
Desktop + - - -
додаток
Веб-додаток + + + +
Можна зробити висновок, що веб-додаток є найкращим варіантом реалізації
системи.
1.4 Огляд існуючих систем для експертного оцінювання
1.4.1 Веб-ресурс «EasyAHP». «EasyAHP» – це комерційний веб-ресурс для
прийняття рішень, який використовує метод аналізу ієрархій (МАІ). Безкоштовний
тариф обмежений функціоналом з можливістю визначення лише до 3 критеріїв та
3 альтернатив. Перехід на платні тарифи розширює функціонал. Веб-ресурс працює
20
в режимі демоверсії. Доступ до цього рішення можна отримати за посиланням:
http://www.easyahp.com/ [1].
Веб-ресурс дозволяє оцінювати критерії та альтернативи за допомогою
графічного інтерфейсу, який значно спрощує внесення експертних оцінок.
Використовуючи інтуїтивний графічний інтерфейс, користувачі можуть легко
вносити експертні оцінки, отримуючи при цьому зручність та швидкість взаємодії.
Інтерфейс доступний лише англійською мовою, але надає зручність у
збереженні експертних оцінок, дозволяючи користувачам повертатись до них у
будь-який зручний для них момент.
Після визначення критеріїв та альтернатив і створення їх ієрархії, веб-ресурс
блокує можливість внесення змін. Це рішення дозволяє користувачам зосередитися
на аналізі та оцінці, не переймаючись можливими випадковими змінами в ієрархії
завдань.
Щодо архітектури веб-ресурсу, важливо відзначити, що він складається з
двох ключових частин. Перша частина - це веб-сайт, де надається огляд сервісу,
блог проєкту та контактна інформація розробника. Веб-сайт, реалізований з
використанням CMS WordPress та бібліотеки стилів bootstrap, забезпечує
привабливий та легко орієнтований інтерфейс для користувачів.
Друга частина веб-ресурсу, а саме система прийняття рішень, відзначається
власноручним створенням без використання CMS. Розрахунки та взаємодія з базою
даних реалізовані за допомогою php, з використанням bootstrap для покращення
ефективності та естетики. Система використовує СУБД MySQL для забезпечення
надійності та швидкості обробки даних. Усі фінансові транзакції здійснюються
через платіжну систему PayPal, забезпечуючи високий ступінь безпеки та
надійності.
Обидві частини веб-ресурсу використовують захищене HTTPS з'єднання,
забезпечуючи конфіденційність та безпеку взаємодії користувачів із системою. Усе
це взяте разом робить наш веб-ресурс ідеальним інструментом для ефективного
управління прийняттям рішень та аналізу альтернатив.
21
З інтерфейсом головної сторінки веб-ресурсу можна ознайомитися на
рисунку 1.3.

Рисунок 1.3 – Інтерфейс головної сторінки веб-ресурсу «easyAHP»
З інтерфейсом самої системи можна ознайомитись на рисунку 1.4.

Рисунок 1.4 – Інтерфейс системи «easyAHP»
22
1.4.2 Веб-ресурс «Decisioner». Decisioner – закрита веб-орієнтована система
підтримки прийняття рішень, яка супроводжується компанією «Трумф-ІТ».
Система доступна безкоштовно для студентів ЗВО за спеціальним студентським
обліковим записом за посиланням: http://decision.tg.ck.ua [2].
Система підтримує декілька методів прийняття рішень:
- метод аналізу ієрархій;
- метод аналітичних мереж;
- метод аналізу співвідношень.
Також підтримує розв’язок задач прийняття рішень в умовах ризику та
невизначеності. Процес експертного оцінювання у цій системі проводиться одразу
після визначення ієрархії, на відміну від «easyAHP», де спочатку треба було
сформувати ієрархію задачі прийняття рішень і тільки після остаточного
підтвердження (яке блокує будь-які зміни ієрархії у подальшому) можна
приступати до експертизи, «Decisioner» пропонує здійснити експертизу «за один
прохід», тобто користувач відразу формує задачу і одразу починає заповнювати
матриці порівнянь або інші таблиці.
Інтерфейс системи є інтуїтивно зрозумілим та простим. Головна сторінка
відразу пропонує обрати експертний метод, після чого користувач потрапляє на
сторінку, де він може почати розв’язувати задачу. Розв’язок задачі поділяється на
етапи (кроки). Кожний крок – це порівняння одного рівня ієрархії. Є певний
недолік, а саме неможливість повертатись змінювати значення матриці порівнянь
на попередньому кроці, хоча її значення впливає лише на кінцевий результат та не
впливає на матриці нижнього рівня.
Слід зазначити, що у процесі внесення оцінок у поля матриці порівнянь
обернене поле з іншої сторони діагоналі матриці заповнюється автоматично.
Наприклад, якщо ввести у клітину A1,3 значення «6» – то клітина A 3,1 автоматично
заповниться значенням «1/6» відповідно до шкали Томаса Сааті. Це економить час
експерта при оцінюванні ієрархічних рівней, звільняє його від введення заздалегідь
визначених значень.
23
Система була розроблена за допомогою CMS та мови програмування PHP.
Веб-сервер – Nginx. СУБД – MySQL. Ознайомитись з головною сторінкою веб-
ресурсу можна на рисунку 1.5.

Рисунок 1.5 – Головна сторінка системи «Decisioner»
З інтерфейсом внесення експертних думок можна ознайомитись на
рисунку 1.6.

Рисунок 1.6 – Інтерфейс внесення експертної думки у системі «Decisioner»

24
1.4.3 Веб-ресурс «123ahp». «123ahp» – це безкоштовне веб-рішення на
базі МАІ з можливістю проведення групової експертизи. Веб-ресурс не є
комплексним або інноваційним, тому що розроблений для безкоштовного
використання. Адреса веб-рішення «123ahp»: http://123ahp.com [3].
Інтерфейс веб-ресурсу доступний на багатьох мовах, а саме: англійській,
німецькій, чеській, польській, португальській, хорватській та іспанській мовах.
Інтерфейс веб-ресурсу є зрозумілим та не вимагає від користувача знань з теорії
прийняття рішень. Сайт надає короткий опис МАІ та інструкцію по роботі з
системою. Інтерфейс був розроблений спеціально для звичайного користувача,
який хоче прийняти рішення за допомогою онлайн сервісу.
Не зважаючи на те, що система спроєктована для звичайних користувачів, які
не мають навичок розв’язування задач прийняття рішень, ця система також
повністю задовольняє потреби професіоналів та реальних експертів. Система
підтримує проведення групових експертиз. Доступ до групової експертизи
надається через надсилання листа з запрошенням на електронну пошту. Можна
зробити групову експертизу приватною, тобто результати експертизи можуть бути
переглянутими лише організатором експертизи.
Робота з веб-ресурсом зроблена через керування задачами (мети, критеріїв та
альтернатив). Введення даних у матрицю порівнянь здійснюється за допомогою
графічного інтерфейсу, який не вимагає ручного введення даних до матриці. Також
це зменшує час, що витрачається на порівняння варіантів.
Веб-ресурс був розроблений вручну без використання CMS за допомогою
фреймворку Microsoft ASP.NET. Інтерфейс написаний на мові C# через фреймворк.
Скріпти написані на JavaScript з використанням jQuery. Веб-ресурс використовує
захищене HTTPS з’єднання. З інтерфейсом головної сторінки веб-ресурсу можна
ознайомитися на рисунку 1.7.
25

Рисунок 1.7 – Інтерфейс головної сторінки веб-ресурсу «123ahp»
Інтерфейс системи представлено на рисунку 1.8.

Рисунок 1.8 – Інтерфейс системи для внесення експертної думки
26
Висновки до розділу 1
У розділі розглянуто постановку та обгрунтування проблеми організації і
проведення експертного оцінювання для прийняття рішень при вирішенні задач,
що виникають у різних сферах діяльності людини.
Сформульована ідея проєкту, яка полягає у розробці веб-орієнтованої
системи підтримки прийняття рішень з можливістю проведення індивідуальних і
групових експертиз, яка буде реалізовувати декілька експертних методів та буде
інтуїтивно зрозумілою у використанні.
Проаналізовано різні варіанти реалізації проєкту, зокрема: веб-додаток,
мобільний додаток, desktop-додаток. У результаті порівняльного аналізу
зазначених варіантів було зроблено висновок про доцільність створення системи
підтримки прийняття рішень як веб-додатку. Розглянувши вже існуючі веб-
орієнтовані системи та виявивши їх переваги та недоліки, було визначено основні
вимоги до майбутньої системи.
У майбутній системі буде реалізовано більшість переваг систем, що були
розглянуті у розділі. Зокрема, буде забезпечена можливість працювати над кожним
завданням окремо та зберігати їх, буде можливість повертатись на попередні етапи
розв’язання задач, що зробить систему більш гнучкою. Буде реалізований
інтуїтивно зрозумілий інтерфейс та написана інструкція до кожного реалізованого
експертного методу.
Система буде орієнтована на звичайного користувача, який не має
спеціальних знань та навичок з прийняття рішень, але буде повністю задовольняти
усі потреби професіоналів даної галузі.

27
2 КОНЦЕПЦІЯ ПРОЄКТУ
2.1 Загальна концепція проєкту
Мета даного проєкту полягає у створенні веб-орієнтованої системи
підтримки прийняття рішень (СППР), в основі якої лежить розробка та випуск
продукту.
Місія проєкту спрямована на організацію та проведення групових експертиз,
роблячи їх більш простими та доступними. Ця загальна ціль вирішує основну
проблему організації та проведення групових експертиз.
Візія проєкту передбачає створення засобу, де прийняття рішень не потребує
ніяких зусиль на математичні обрахунки.
Мрія проєкту полягає у тому, щоб технології прийняття рішень були
доступними та зрозумілими для користувача та швидкими у використанні.
Цілі проєкту:
- наповнити базу даних користувачів (експертів) системи не менш ніж 25
експертів за 3 місяці;
- реалізувати 3 методи прийняття рішень (МАІ, метод нормування, метод
ранжування) протягом розробки системи та реалізувати не менш ніж 3
додаткових методів прийняття рішень не пізніше ніж 3 місяці після запуску
проєкту;
- мати не менш ніж 80% позитивних відгуків про систему.
Для подальшого планування системи потрібно створити історії користувачів
(user stories). Вони допоможуть визначити потреби майбутніх користувачів та
згідно них визначити функціональні вимоги системи.
Історії користувачів:
- Я як аналітик, хочу мати доступ до списку експертів.
- Я як експерт, хочу мати зручний інтерфейс для введення моєї експертної
думки.
- Я як користувач, хочу швидко отримати ефективне рішення.
- Я як аналітик, хочу швидко отримувати результати групової експертизи.
28
- Я як особа, що приймає рішення, хочу бачити результат у зрозумілому
форматі.
- Я як експерт, хочу знати, що мої експертні оцінки є анонімними.
- Я як аналітик, хочу щоб групова експертиза проводилась за обраним мною
методом прийняття рішень.
- Я як експерт, хочу мати інструкцію з використання методів прийняття
рішень, з якими я ще не знайомий.
- Я як аналітик, хочу бачити фінальні результати усіх залучених до групової
експертизи експертів.
- Я як користувач, хочу мати зрозумілий інтерфейс для роботи з цією
системою.
Також треба визначити зацікавлених сторін проєкту (стейкхолдерів). Це
потрібно для налагодження відносин, які необхідні для успішної розробки проєкту.
Список стейкхолдерів:
- Єфімов В.В – автор проєкту / розробник. Автор ідеї та майбутньої
кваліфікаційної роботи магістра. Розробляє продукт та пише кваліфікаційну
роботу. Зацікавлений та напряму впливає на проєкт.
- Триус Ю.В. – замовник. Керівник кваліфікаційної роботи. Вносить корективи
до проєкту, описує яким повинен бути кінцевий результат. Зацікавлений та
напряму впливає на проєкт.
- Члени атестаціонної комісії – перевіряючі. Перевіряють результат роботи
проєкту та оцінюють кваліфікаційну роботу. Впливають на проєкт, але не є
зацікавленими.
- Користувачі – вони не впливають ні на що, але зацікавлені у використанні
додатку.
З реєстром зацікавлених сторін можна ознайомитись у таблиці 2.1.
Згідно реєстру побудуємо матрицю зацікавлених сторін та визначимо як
треба взаємодіяти з стейкхолдерами проєкту. Відповідно до параметрів «Вплив» та
«Зацікавленість» до кожного стейклодеру треба визначити особисту тактику
відносин. Якщо в учасника параметри впливу та зацікавленості великі, то тоді треба
29
активно співпрацювати та активно залучати. Якщо впливу немає, але є інтерес -
інформувати. Якщо є вплив, але немає зацікавленості – задовольняти.
Таблиця 2.1 – Реєстр зацікавлених сторін.
ПІП Посада Вплив Зацікавленість
Єфімов В.В Автор проєкту 80 100
Керівник
Триус Ю.В. кваліфікаційної роботи. 70 70
Замовник
Члени атестаційної
- 80 0
комісії
- Клієнти 0 70

Матриця зацікавлених сторін наведена на рисунку 2.1.

Рисунок 2.1 – Матриця зацікавлених сторін
Бачимо, що потрібно здійснювати наступні дії:
- Єфімов В.В – автор проєкту / розробник. Активно залучати (зацікавленість
та вплив вище 50%).
- Триус Ю.В. – замовник. Активно залучати (зацікавленість та вплив вище
50%).
30
- Члени атестаційної комісії – перевіряючі. Задовольняти (вплив вище 50%
та зацікавленість нижче 50%).
- Користувач - інформувати (вплив нижче 50% та зацікавленість вище 50%).
2.2 Структура продукту проєкту
Система буде складатись з двох частин: frontend та backend. Кожна частина
буде мати свій набор функціоналу та задач. Оскільки система повинна бути легкою
та невитратною у плані підтримки, було прийнято рішення більшість функціоналу
реалізувати у frontend, а у backend реалізувати лише опрацювання результатів
групової експертизи та взаємодії з базою даних. Загальна архітектура систему
подана на рисунку 2.2.

Рисунок 2.2 – Загальна архітектура проєкту
Подивившись на цю архітектуру, можна побачити, що база даних буде
розташована на окремому кластері, які надають безкоштовно компанії-розробники
СКБД. Основна частина проєкту буде встановлена на одному домені. Це дозволяє
зменшити витрати на підтримку системи та полегшити її запуск.
31
Frontend – це клієнтська частина проєкту, яка працює на стороні клієнта
(користувача). Це веб-сторінка, яку він відкриває. Вона повинна відображати
інформацію та надавати інструменти (інтерфейс) для взаємодії користувача з
системою. У даному проєкті всі взаємодії користувача під час проведення
експертизи, окрім зберігання фінальних результатів його взаємодії, наприклад
оновлення даних експертизи у базі даних, проводяться на frontend частині
продукту.
Це дозволяє зменшити навантаження на майбутній сервер додатку, що, в
свою чергу, дозволить обирати менш вартісні тарифи доменів або взагалі
використовувати його безкоштовно. Також це дозволить встановити додаток на
серверах університету без значного впливу на загальне навантаження його систем.
Але в цьому є й певний недолік, а саме: при помилках інтернет-з’єднання
зміни в даних можуть бути втрачені, оскільки оновлення не проводиться у момент
змін – тільки після остаточного підтвердження зі сторони користувача. Але це
дозволяє значно зменшити кількість запитів на сервер.
Враховуючи вище сказане, frontend частина проєкту буде реалізовувати
наступний функціонал:
- інтерфейс для роботи з системою;
- робота з експертизами;
- надсилання запрошень до групових експертиз;
- прийняття згоди на участь у груповій експертизі;
- внесення експертних оцінок;
- реалізація експертних методів;
- графічне відображення результатів;
- модуль адміністрування;
- керування обліковими записами.
Структура frontend частини додатку наведена на рисунку 2.3.
32

Рисунок 2.3 – Структура frontend
Backend частина проєкту буде мати набагато менше функцій. На цій частині
буде розроблений функціонал, який неможливо реалізувати ніяк інакше – агрегація
результатів групової експертизи, оскільки для цього потрібно оперувати даними
інших користувачів. Також серверна частина проводить опрацювання результатів
оцінювання експертів за відповідними методами. Ця частина додатку реалізує усі
операції над даними у базі даних, а також забезпечує реєстрацію, авторизацію та
аутентифікацію користувачів додатку.
Для кожного експертного методу сервер буде опрацьовувати індивідуальний
алгоритм обрахунку узгодженості та компетентності. Також сервер буде мати
доступ до поштового аккаунту Outlook. Поштовий аккаунт необхідний для
надсилання повідомлень про запрошення до групових експертиз та для
підтвердження реєстрації користувачів. Також через е-пошту можна буде змінити
пароль користувача.
Отже, backend частина додатку буде реалізовувати наступний функціонал:
- агрегація результатів групової експертизи;
33
- розрахунок узгодженості експертів та компетентності експертів;
- робота з поштовим сервісом;
- виконання CRUD операцій з базою даних.
Струткура backend частини проєкту наведена на рисунку 2.4.

Рисунок 2.4 – Структура backend
2.3 SWOT аналіз проєкту
Для успішної імплементації будь-якого проєкту необхідно детально вивчити
та визначити обсяг можливих ризиків з метою об'єктивного вирішення питання про
доцільність розпочати його реалізацію. Цей аналіз повинен охоплювати як
внутрішні, так і зовнішні аспекти, які можуть вплинути на успіх проєкту.
У процесі розробки СППР виникає ряд специфічних ризиків, і для їх
ідентифікації доцільно використовувати SWOT-аналіз. SWOT-аналіз дозволяє не
лише визначити потенційні небезпеки та перешкоди, а й відокремити сильні та
слабкі сторони продукту проєкту. Це структурований підхід, який забезпечує
глибоке вивчення внутрішніх проблем та конкурентних переваг, дозволяючи
приймати обґрунтовані рішення.
Результат SWOT аналізу проєкту наведений у таблиці 2.2.

34
Таблиця 2.2 – результат SWOT аналізу проєкту.
Позитивний вплив Негативний вплив
Сильні сторони Слабкі сторони
1. Наявність методів прийняття 1. Можливі збої у роботі СППР,
рішень, які не були реалізовані у оскільки у розробників мало досвіду
інших СППР. роботи.
2. Зручний та простий 2. Нереалізовано багато
інтерфейс СППР. популярних методів прийняття
3. Підтримка групових рішень.
експертиз. 3. Не оптимізований код.
4. Монолітна структура
проєкту.
5. Можливість додавання нових
методів прийняття рішення.
Можливості Загрози
1. Безкоштовний інструмента- 1. Терміни реалізації і
рій для розробки. завершення проєкту.
2. Безкоштовні хостінги. 2. Обмеженість функціоналу
3. Можливість монетизувати безкоштовних хостінгів.
проєкт через додавання реклами у 3. Наявність інших СППР.
додаток. 4. Можливий перехід
безкоштовних хостінгів на платний
план або зменшення доступного
безкоштовного функціоналу.
5. Проблеми зі світлом узимку
через енергетичну кризу.

Враховуючі сказане, можна визначити шляхи протидії загрозам, або
перекрити ризики сильними сторонами проєкту. Опишемо протидію до кожної
загрози:
Зовнішнє оточення Внутрішнє оточення
35
- можливі збої у роботі системи – написати обробку для кожної помилки, яка
може трапитись у процесі роботи системи;
- мало реалізованих методів – зробити архітектуру системи таким чином, щоб
у майбутньому можна було легко інтегрувати інші експертні методи;
- не оптимізований код – перевірити усі функції системи на безпомилкове
виконання їх призначень (тестування);
- терміни реалізації і завершення проєкту – проводити розробку продукту
згідно встановлених термінів;
- обмеженість функціоналу безкоштовних хостінгів – розробити систему
таким чином, щоб основне навантаження було на стороні клієнті, а не на
стороні сервері;
- проблеми зі світлом узимку – мати резервне живлення, адаптувати графік
роботи над проєктом згідно графіків вимкнення світла або збільшити терміни
завершення проєкту.
Оцінимо також конкурентоспроможність проєкту, навіть якщо у цілях
проєкту відсутня потреба в отриманні доходу, оскільки проєкт є безкоштовним,
система все одно повинна мати певні переваги над іншими СППР. Для цього
проаналізуємо визначені сильні сторони проєкту:
- наявність методів прийняття рішень, які не були реалізовані у інших СППР
– жодна з проаналізованих СППР не підтримує такі експертні методи, як метод
нормування та метод ранжування, хоча ці методи математично обґрунтовані,
досить ефективні та прості в реалізації, а також надають аналітику можливість
одержати інформацію про узгодженість та компетентність експертів;
- зручний та простий інтерфейс –платні СППР мають складний інтерфейс,
оскільки містять багато функціоналу, а дуже прості СППР можуть мати незручний
дизайн інтерфейсу користувача;
- підтримка групових експертиз – багато систем надають цей функціонал за
платним таріфом, але ця система буде надавати цю можливість безкоштовно;
- монолітність проєкту – дозволяє значно зменшити витрати на її
супроводження;
36
- можливість додавання нових методів прийняття рішень – оскільки система
буде модульною, інтеграція нових методів буде простою;
- безкоштовний інструментарій розробки – дозволяє розробити проєкт не
витрачаючи ніяких фінансових ресурсів;
- безкоштовні хостінги – виходячі з того, що проєкт не буде мати великого
розміру та частих запитів зі сторони клієнтської частини, можна використати
безкоштовні рішення для інсталювання системи;
- можливість додавання реклами – якщо буде прийнято рішення
монетизувати проєкт.
Можна побачити, що кожний ризик має свою протидію. З урахуванням
сильних сторін проєкту можна зробити висновок про доцільність початку роботи
над проєктом.
2.4 Стратегія реалізації проєкту
Після визначення та докладного опису структури проєкту, а також
проведення аналізу можливих ризиків, наступним етапом є планування стратегії
реалізації проєкту. У сфері розробки веб-додатків існує кілька стратегій, які можна
використовувати:
1. Розробка backend, а потім frontend: цей підхід передбачає початок розробки
серверної частини перед клієнтською.
2. Розробка frontend, а потім backend: у цьому випадку спочатку створюється
клієнтська частина, а потім серверна.
3. Паралельна розробка backend та frontend: обидві частини розробляються
одночасно.
У нашому випадку обрано перший варіант, оскільки кожна функція frontend
пов'язана із backend, і витрати на створення імітації серверних відповідей
вважаються зайвими. Немає потреби у тому, щоб спеціально розробляти імітацію
роботи серверної частини, якщо вона може бути розроблена раніше. Це визначає
ключові етапи проєкту:
1. Розробка моделей бази даних;
37
2. Розробка backend частини з базовим функціоналом взаємодії з базою даних
та авторизацією;
3. Розробка інтерфейсу frontend частини додатку;
4. Інтеграція експертних методів;
5. Написання алгоритмів агрегації групових результатів;
6. Інтеграція поштового сервісу;
7. Тестування;
8. Реліз продукту.
Такий вибір стратегії дозволяє систематично та ефективно рухатися вперед,
забезпечуючи високу взаємодію між різними компонентами проєкту та
відповідаючи вимогам функціональності та якості.
Щоб забезпечити ефективний процес розробки системи (СППР),
використовуємо ітераційний підхід. На етапі початкової роботи над проєктом були
вирішені архітектурні питання додатку. Після цього додаток розробляється
ітераційно, ставлячи завдання на кожний тиждень.
Кожна ітерація включає в себе задачі з розробки певної частини системи,
тестування, уточнення та реліз цієї частини. Задачі формулюються для тижневих
періодів, і кожного тижня проводяться огляди роботи з формулюванням нових
завдань.
Важливим етапом є взаємодія та вирішення завдань, що узгоджуються з
замовником. Він перевіряє реалізовану частину проєкту, після чого вносяться зміни
відповідно до його рекомендацій. Цей цикл може повторюватися для кожної
частини проєкту до досягнення повної задоволеності замовника або до завершення
всього проєкту. Також протягом цього циклу можуть ставитись нові завдання, які
не були передбачені спочатку роботи над продуктом, оскільки саме у процесі
роботи стають відомими нові нюанси потреб користувачів або роботи самої
системи.
Кожна фаза життєвого циклу взаємодії представляє собою етап розгляду,
виконання, тестування та внесення необхідних змін. Під час огляду роботи
замовник має можливість детально оцінити прогрес та надати свої коментарі та
38
вимоги до подальшої розробки. Такий поділ на фази сприяє покроковому підходу
до досягнення мети та забезпеченню високої якості кінцевого продукту.
Життєвий цикл розробки підсистем проєкту наведений на рисунку 2.5.

Рисунок 2.5 – Життєвий цикл розробки підсистем проєкту
Розглянемо більш детально процес однієї ітерації зв’язку з замовником.
Кожний сеанс зв’язку проводиться для отримання зворотного зв’язку щодо
розробки продукту проєкту. У процесі розробки виконавець також вносить свої
правки у запити замовника. Задаються питання «Чи це дійсно потрібно у межах
теперішніх термінів здачі?», або «Чи потрібно додати до списку завдань створення
39
функції «Х» для того, щоб доповнити функцію «Y»?», або «Чи потрібно приділяти
цьому завданню більше уваги, ніж іншим?».
Схема ітераційного процесу наведена на рисунку 2.6.

Рисунок 2.6 – Одна ітерація розробки проєкту
Взаємодія виконавця та замовника проводиться за допомогою додатку
«Microsoft Teams». Жива бесіда з замовником дозволяє швидше та більш коректно
зрозуміти що саме він хоче бачити у готовому продукті. Також можливість
демонстрації екрану дозволяє показати замовнику як були реалізовані завдання, які
він поставив.
Для організації та відслідковування прогресу роботи використовується
методологія «Kanban» за допомогою веб-ресурсу «Trello». Це веб-рішення
дозволяє розробнику бачити які завдання є більш пріоритетними, а які займають
більше часу ніж на них планувалось. Замовнику ресурс дозволяє вносити нові
завдання та надавати зворотній зв’язок щодо завдань, які вже були виконані.
Вище описані інструменти дозволяють легко проводити потрібний
ітераційний процес розробки та підтримують процес життєвого циклу проєкту.
Дошку завдань можна подивитись на рисунку 2.7.
40

Рисунок 2.7 – Дошка завдань «Trello»
Висновки до розділу 2
У цьому розділі розроблена концепція проєкту, описані мета, візія та цілі
проєкту. Були поставлені конкретні задачі, розроблені історії користувачів та
визначені стейкхолдери проєкту. Для кожного стейкхолдеру була визначена
стратегія поведінки.
Були визначені ключові етапи реалізації проєкту – це глобальні завдання, які
потрібно виконати для успішного завершення проєкту. Визначена стратегія як для
безпосередньо розробки проєкту, так і взаємодії із замовником. Були визначені та
проаналізовані сильні та слабкі сторони проєкту за допомогою SWOT аналізу.
Також були ідентифіковані ризики та визначені протидії цим ризикам. Була
41
визначена конкурентноспроможність проєкту, а також можливості монетизувати
майбутній продукт.
Як підсумок розробки концепції проєкту – маємо загальне бачення продукту
проєкту і вимоги до нього. Це дозволяє розпочати планувати проєкт за допомогою
Microsoft Project згідно міжнародного стандарту PMBoK.

42
3 РОЗРОБКА ПРОЄКТУ
3.1 Планування змісту
Зміст проєкту – роботи, які необхідно виконати, щоб отримати продукт,
послугу чи результат із запланованими характеристиками і функціями [4].
Простими словами – це план, виконання якого призводить до успішного
завершення проєкту.
Робоча структура проєкту (WBS) представляє собою детальний опис завдань,
які необхідно виконати в рамках проєкту. Це ієрархічна система завдань, яка
відображає сприйняття учасників проєктної групи щодо складу роботи, а також
розміру, вартості та тривалості кожного етапу чи завдання [5]. Головні цілі WBS
включають:
1. Розгляд деталей та структури роботи у вигляді конкретних завдань;
2. Планування виконання робіт у межах проєкту;
3. Визначення вартості кожного окремого завдання.
Рівень деталізації WBS визначається необхідністю точних оцінок та рівнем
відстеження, який необхідний для цих оцінок. Проєкти з високими вимогами до
вчасності та бюджету часто вимагають докладного розгляду WBS та
систематичного контролю над прогресом та витратами. Це особливо актуально для
будівельних та інженерних проєктів [5].
Розробка WBS – це важливий та витратний процес, який, зазвичай, вимагає
співпраці та обміну інформацією між різними учасниками [5]. У цій статті
висвітлено, як можна використовувати розширені можливості WBS відповідно до
ваших потреб у забезпеченні оцінки та контролю прогресу проєкту.
Перейдемо безпосередньо до розробки WBS структури проєкту, що
реалізується у роботі. Для цього скористаємось ключовими етапами роботи, які
були визначені у підрозділі 2.4, але опишемо їх більш детально.
1. Розробка моделей бази даних.
1.1. Опис концептуальної моделі даних;
1.2. Опис логічної моделі даних;
43
1.3. Створення фізичної моделі даних.
2. Розробка backend частини з базовим функціоналом взаємодії з базою
даних та авторизацією.
2.1. Встановлення ПЗ для розробки;
2.2. Підключення серверу до кластеру бази даних;
2.3. Написання алгоритмів реєстрації, авторизації та аутентифікації;
2.4. Налагодження системи ролей;
2.5. Написання CRUD операції з усіма сутностями бази даних.
3. Розробка інтерфейсу frontend частини додатку.
3.1. Встановлення ПЗ для розробки;
3.2. Створення базової архітектури Redux додатку;
3.3. Розробка головного меню додатку;
3.4. Реалізація реєстрації, авторизації та аутентифікації;
3.5. Інтеграція локалізації;
3.6. Реалізація CRUD операцій з експертизами;
3.7. Реалізація інтерфейсу адміністрування (CRUD операції над усіма
сутностями).
4. Інтеграція експертних методів.
4.1. Написання алгоритмів реалізації експертних методів;
4.2. Розробка інтерфейсу анкетування для експертних методів;
4.3. Виведення результатів експертиз.
5. Реалізація групових експертиз.
5.1. Розробка системи запрошень до групових експертиз;
5.2. Написання алгоритмів агрегації групових результатів;
5.3. Виведення результатів групових експертиз.
6. Інтеграція поштового сервісу.
6.1. Підключення серверу до поштового аккаунту Outlook;
6.2. Реалізація алгоритму підтвердження реєстрації на експертизу.
7. Тестування.
7.1. Тестування усіх CRUD операції;
44
7.2. Тестування усіх експертних методів;
7.3. Тестування системи запрошень до групових експертиз;
7.4. Тестування поштового сервісу.
8. Реліз продукту.
Реалізація WBS структури у MS Project наведений на рисунках 3.1-3.2.

Рисунок 3.1 – Реалізація WBS структури у MS Project
45

Рисунок 3.2 – Реалізація WBS структури у MS Project (продовження)
Після того, як WBS структура була описана, можна перейти до планування
часу.
3.2 Планування часу проєкту
До процесу планування часу входить аналіз тривалості виконання кожного
пункту WBS. Оцінивши терміни виконання кожної задачі, можна підрахувати
тривалість виконання проєкту в цілому. А це, у свою чергу, дозволяє, звіряючись з
календарем та графіком роботи (який можна налаштувати окремо), дізнатися
реальні терміни виконання проєкту. Тобто буде відома дата завершення проєкту.
На цьому етапі також встановлюється послідовність виконання задач проєкту. У
нашому випадку, оскільки виконавець всього один, усі завдання будуть
виконуватися послідовно.
Графік роботи над проєктом складається з 5 днів на тиждень з понеділка по
п’ятницю. Субота та неділя є вихідними днями. Робочий графік з 8:00 до 17:00
враховуючи обід. Тобто маємо стандартний 8-годиний робочий день. Свята не
враховуються за вихідні дні. День початку роботи над проєктом – 1 листопада 2023
року.
46
До кожної задачі у WBS напишемо термін виконання. Та проаналізуємо
отриманий план виконання. WBS з доданими термінами виконання наведена на
рисунках 3.3-3.4.

Рисунок 3.3 – WBS с заданими термінами виконання
47

Рисунок 3.4 – WBS с заданими термінами виконання (продовження)
Знаючи послідовність виконання робіт та їх терміни, можемо побудувати
мережевий графік.
Мережевий графік представляє собою живу модель виробничого процесу,
яка відтворює технологічну залежність і послідовність виконання різноманітних
завдань, узгоджуючи їх завершення у визначений час із врахуванням ресурсних
витрат і вартості робіт, виділяючи при цьому ключові (критичні) етапи [6].
Мережевий графік проєкту представлено на рисунку 3.5.

Рисунок 3.5 – Мережевий графік проєкту у MS Project
48
Також MS Project будує діаграму Ганта відповідно до створеної WBS.
Діаграма Ганта – це один з найбільш визнаних інструментів управління
проєктами. Це набір графічних гістограм, що відображають терміни, взаємозв'язок
та віхи реалізації різних етапів проєкту. Інженер Генрі Гант, починаючи з початку
20-го століття, розробив цей інструмент, який протягом понад 100 років
залишається основним стандартом для планування проєктів [7].
Діаграма Ганта проєкту наведена на рисунку 3.6.

Рисунок 3.6 – Діаграма Ганта
Згідно планування терміну робота над проєктом починається з 1.11.2023 та
закінчується 21.12.2023. Робота буде тривати 51 календарний день. Знаючи чіткі
терміни та план роботи, можемо перейти до планування трудових ресурсів.
49
3.3 Планування трудових ресурсів
Незважаючи на те, що в планувальнику від Microsoft, термін "ресурси" може
включати в себе широкий спектр елементів, таких як машини, механізми, рядові
працівники і таке інше, для зручності використовується наступна класифікація:
Трудові Ресурси
Цей тип ресурсів визначається як працівники або обладнання, які взято в
оренду для використання в проєкті. У Microsoft Project, трудові ресурси можуть
бути використані на різних проєктах, оскільки їх обмеженість та відновлюваність
роблять їх універсальними.
Матеріальні Ресурси
Цей вид даних вказує на матеріальні цінності, необхідні для проєкту. У
практиці використання MS Project, матеріальні ресурси використовуються рідко
через те, що їх планування та закупівля покладаються на спеціалізованих фахівців.
Тим не менше, у випадку дефіциту певних позицій, вони можуть бути включені до
плану.
Витрати
Цей аспект визначає підрядні організації, які беруть участь у виконанні
проєкту, а також інші затрати, такі як оренда приміщень, витрати на зв'язок та інші.
Ці витрати можуть бути деталізовані та враховані для забезпечення повноцінного
планування та управління бюджетом проєкту.
Отже, хоча поняття "ресурси" може охоплювати різноманітні складові,
використання такої детальної класифікації в MS Project сприяє ефективному
управлінню різними аспектами проєкту та забезпечує належне планування ресурсів
для досягнення успіху. [8].
Оскільки проєкт використовує безкоштовні рішення, то ні матеріальних, ні
витратних ресурсів немає. Але є трудові ресурси, а саме:
1. Єфімов В.В – розробник системи, виконує усі задачі проєкту;
2. Триус Ю.В. – замовник системи, виставляє вимоги та допомогає у
тестуванні системи.
50
Усі ці ресурси є безкоштовними. Введемо ці ресурси у MS Project. Аркуш
ресурсів наведений на рисунку 3.7.

Рисунок 3.7 – Аркуш трудових ресурсів проєкту
Після цього етапу важливо провести призначення ресурсів на конкретні
завдання та визначити, хто відповідає за виконання кожного завдання. Для
ефективності цього процесу ми вирішили створити матрицю відповідальності
проєкту. Оскільки обсяг задач є значущим, розподілимо відповідальність на цілі
етапи, які в MS Project позначаються як підсумкові задачі. Кожна конкретна задача
ідентифікується кодом WBS, який детально представлений на рисунках 3.3-3.4.
Матриця відповідальності, яка допоможе організувати цей процес, наведена
у таблиці 3.1. Ця таблиця визначає, який член команди відповідає за кожний
підсумковий етап проєкту. Цей підхід дозволяє кожному учаснику команди чітко
розуміти свої обов'язки та відповідальності, сприяючи впорядкуванню робочих
процесів та успішному виконанню завдань проєкту.
Таблиця 3.1 – Матриця відповідальності
Задачі
Відповідальний
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8
Єфімов В.В. ОВ ОВ ОВ ОВ ОВ ОВ ОВ ОВ
Триус Ю.В. В
де О – відповідальний, В – виконавець.
Оскільки наша проєктна команда складається лише з двох учасників, виникає
логічне обґрунтування того, що створення організаційної структури проєкту (OBS)
стає зайвим етапом. Замість того, щоб розробляти складну OBS, де функціональні
ролі між двома учасниками можуть бути очевидні та легко визначені, зосередимось
на більш детальному аспекті планування ресурсів.
У процесі призначення завдань членам команди проєкту під час планування
ресурсів важливо діяти ретельно та уважно. Коли ресурси призначаються
конкретним завданням, MS Project автоматично створює графік робочих годин для
51
учасників команди, враховуючи робочий календар. Це спрощує контроль за тим, як
ресурси використовуються, і забезпечує оптимальне використання робочого часу.
Результати цього процесу відображаються в зручному графіку
«Використання ресурсів», представленому на рисунку 3.8. Цей графік дозволяє
чітко спостерігати, як розподілений час кожного учаснику проєкту, що сприяє
ефективному розподілу ресурсів та вчасному виконанню проєкту.

Рисунок 3.8 – Використання ресурсів у MS Project
У процесі управління ресурсами важливо уникати перенавантаження будь-
якого ресурсу, оскільки це безпосередньо впливає на його ефективність. У випадку,
якщо виникає ситуація, коли неможливо зняти навантаження з певного ресурсу,
розглядається можливість призначення додаткових фінансових ресурсів для
забезпечення його ефективності. Важливо враховувати, що у випадку виконання
робіт послідовно немає потреби в перенавантаженні ресурсів.
Використання MS Project надає можливість моніторити навантаження
ресурсів за допомогою графіка ресурсів, який відображається в поданні «Графік
ресурсів». Аналізуючи рисунки 3.9-3.10, можна визначити, що жоден з ресурсів не
перенавантажений, що свідчить про успішне планування трудових ресурсів. Це
гарантує ефективне використання команди проєкту та виключає можливість
надмірного навантаження, забезпечуючи успішне виконання завдань проєкту.
52

Рисунок 3.9 – Навантаження ресурсу «Єфімов В.В.»

Рисунок 3.9 – Навантаження ресурсу «Триус Ю.В.»
53
3.4 Планування якості
Планування якості в ІТ-проєкті є ключовим етапом, спрямованим на
забезпечення високого рівня функціональності, ефективності та задоволення вимог
замовника. Цей процес передбачає ретельне визначення стандартів якості,
визначення критеріїв успішності та впровадження стратегій для досягнення цих
цілей.
Початковий етап планування включає в себе аналіз вимог та очікувань
замовника. Необхідно чітко визначити, які аспекти функціональності,
продуктивності та безпеки є критичними для успішного виконання завдань
проєкту. Також важливо визначити ключові показники ефективності, за якими буде
вимірюватися якість продукту.
Виділимо критерії якості:
1. Швидкість обрахунків;
2. Безпека даних у базі даних;
3. Відсутність багів;
4. Якість локалізації;
5. Надійність роботи поштового модулю.
Далі необхідно розробити стратегію тестування, яка включає в себе
тестування функціональності, продуктивності, безпеки та інших аспектів. Важливо
створити чіткий план тестування, визначити тести, які будуть проведені на різних
етапах розробки, та встановити критерії прийняття.
Тестування буде проводитись розробником та замовником. Встановлений
наступний план тестування:
1. Тестування усіх CRUD операцій. Тестування модулів для роботи над
експертизами, змінами даних облікових записів та модулю адміністрування.
2. Тестування експертних методів. На цьому етапі буде вимірюватись
точність обрахунків результатів експертних методів.
3. Тестування системи запрошень до групових експертиз. На цьому етапі
буде перевірено роботу запрошень, а саме їх надсилання та прийняття або відмова.
54
4. Тестування поштового сервісу. Перевірка якості реагування поштового
сервісу на запити системи.
Крім того, слід враховувати процес контролю якості під час розробки. Це
може включати в себе регулярні код-рев’ю, аудит якості коду, впровадження
стандартів програмування та інші практики, спрямовані на покращення якості
продукту вже на етапі розробки. Для цього й був налаштований ітераційний процес,
описаний у підрозділі 2.4.
3.5 Планування ризиків
Ризик проєкту– це будь-яка можлива подія, що може призвести до затримки
проєкту, збільшення його вартості або навіть до припинення проєкту [9].
Управління ризиками у проєкту є важливою складовою успішного його
виконання. Під час SWOT аналізу у підрозділі 2.3 були визначені загрози та слабкі
сторони проєкту, які частково є ризиками. Проаналізуємо їх з точки зору
планування ризиків. З початку ідентифікуємо ризики даного проєкту.
Ризики наведені у таблиці 3.2.
Таблиця 3.2 – Ризики проєкту.
№ Найменування ризику імовірність Вплив на проєкт
виникнення
1 Розроблена система може мати 0,6 0,8
погану якість.
2 Безкоштовні хостінги можуть не 0,7 0,8
мати підтримку технологій,
потрібних для роботи проєкту.
3 Збої роботи енергетичної 0,6 0,8
системи країни.
4 Посилення мобілізаційної 0,4 0,8
політики.
55
5 Втрата розробленої системи 0,2 0,8
через поломку машини, на якій
проводиться розробка.
6 Проблеми зі сумісністю 0,1 0,4
браузерів.
7 Втрата конфіденційних даних 0,4 0,8
через хакерськи атаки.
8 Проблеми з встановленням 0,3 0,7
системи.
Маючи ймовірність та рівень впливу кожного ризику, можемо встановити
рівень загрози ризиків для проєкту.
Визначення рівня загрози ризиків наведено у таблиці 3.3
Таблиця 3.3 – Рівень загрози ризиків.
Імовірність
0.8 – 1.0
0.6 – 0.8 1,2
0.4 – 0.6 3,4,7
0.2 – 0.4 8
0 – 0.2 6 5
0.05 0.1 0.2 0.4 0.8
Вплив
Область високих ризиків
Область помірних ризиків
Область низьких ризиків
Можна побачити, що більшість ідентифікованих ризиків мають високий
рівень загрози. Визначимо протидію цим ризикам для зменшення їх ймовірностей
та впливу.
1. Проведення тестування розроблених модулів дозволить вирішити
проблему якості проєкту;
56
2. У випадку якщо безкоштовні хостінги не зможуть підтримувати роботу
системи, встановити систему на серверах ЧДТУ;
3. Зберігання копій системи у хмарі унеможливлює ризик втрати
розробленої системи;
4. Використовувати сучасні рішення для розробки проєкту дозволить
гарантувати сумісність з більшістю популярних браузерів та спростить
його встановлення;
5. Встановлення захисту від хакерських атак у проєкті зменшить ризик
втрати конфіденційних даних.
Висновки до розділу 3
У цьому розділі був описаний процес розробки проєкту згідно міжнародного
стандарту PMBoK. Був створений зміст плану розробки проєкту за допомогою
програмного засобу MS Project, був розподілений час на його виконання, були
розплановані трудові ресурси проєкту, визначені критерії якості та ризики проєкту.
Були розглянуті основні пунки управління проєктом. Планування витрат та
бюджету були опущені, оскільки у даному проєкті немає витрат та бюджету. Весь
проєкт розробляється на безкоштовній основі та на безкоштовних технологіях.
Як підсумок маємо повний план реалізації проєкту з урахуванням ризиків та
контролю якості. У наступному розділі буде описана практична реалізація проєкту.

57
4 ПРАКТИЧНА РЕАЛІЗАЦІЯ ПРОЄКТУ
4.1 Технології для розробки продукту проєкту
Для розробки був використаний стек MERN, який складається з MongoDB,
Express, React та Node.js.
4.1.1 База даних MongoDB. MongoDB представляє собою базу даних, яка
ґрунтується на нереляційній моделі документів [10]. У порівнянні з традиційними
реляційними базами даних, такими як Oracle, MySQL або Microsoft SQL Server,
MongoDB відрізняється як база даних нового покоління.
Основною особливістю MongoDB є його модель документів та здатність
координувати роботу кількох серверів для зберігання даних. Це дозволяє системі
забезпечувати відмовостійкість, оскільки резервні копії одних і тих самих даних
знаходяться на різних серверах, запобігаючи, таким чином, впливу помилок одного
сервера на загальну продуктивність.
Однією з ключових переваг MongoDB є його масштабованість, яка легко
реалізується на декількох серверах для зберігання та обробки даних. Такий підхід
сприяє зростанню обсягу даних і вимог до продуктивності, дозволяючи
користувачам легко додавати нові сервери без необхідності оновлення складних
мейнфреймів. Крім того, це робить MongoDB ідеальним варіантом для хмарних
середовищ, де ресурси розподіляються на різних комп'ютерах.
MongoDB також відзначається швидкістю виконання запитів, особливо в
умовах, коли всі дані знаходяться в одному місці та можуть бути легко отримані за
одним пошуком. Проте, важливо враховувати, що це стосується випадків, коли дані
представлені у формі документів. При намаганні емулювати реляційну модель,
продуктивність може страждати через необхідність виконання багатьох окремих
запитів для отримання одного документа.
Додатково, використання Node.js, яке використовує JavaScript, спрощує
роботу з даними JSON, оскільки JavaScript є надмножиною JSON. Це вирішує
проблему об'єктно-реляційної несумісності природно, а робота з JSON стає більш
зручною та легкою, особливо при відображенні даних на клієнтському рівні.
58
4.1.2 Express. Express – це мінімалістичний і гнучкий веб-фреймворк для
додатків Node.js, що надає широкий набір функцій для мобільних і веб-застосунків
[11].
Express.js є гнучким веб-фреймворком для створення веб-додатків на основі
Node.js. Розроблений для швидкої розробки та простоти використання, Express
дозволяє швидко створювати серверні додатки та API.
Основні характеристики Express.js включають в себе:
1. Маршрутизація. Express надає простий та потужний спосіб визначення
URL-шляхів та обробки HTTP-запитів для визначених ресурсів;
2. Middleware. Велика перевага Express – система middleware, яка дозволяє
виконувати функції посеред дороги обробки запиту. Це може бути використано для
обробки аутентифікації, логування, перевірки даних та інших завдань.
3. Управління шаблонами. Express полегшує використання шаблонів для
створення HTML-сторінок. Він підтримує різні шаблонізатори, такі як EJS, Pug
(раніше відомий як Jade), Handlebars та інші.
4. Статичні файли. Express надає можливість легко обробляти статичні
файли, такі як зображення або CSS, що робить розгортання клієнтського контенту
простим.
5. Розширені можливості маршрутизації. Включає в себе параметри шляху,
обробники запитів для різних методів HTTP, а також можливості використання
регулярних виразів для більш гнучкої маршрутизації.
6. Спрощений сервер. Express дозволяє легко створювати та запускати веб-
сервер з мінімальним кодом.
Express.js є дуже популярним вибором серед розробників для швидкого
створення серверних додатків у світі JavaScript та Node.js. Активна спільнота та
простий інтерфейс роблять його ідеальним вибором для будь-якого розміру
проєкту від простих API до складних веб-додатків.
4.1.3 React. Фреймворк React.js – це фреймворк і бібліотека JavaScript з
відкритим вихідним кодом, розроблені та підтримувані Facebook і Instagram. Він
використовується для швидкого та ефективного створення інтерактивних
59
користувацьких інтерфейсів і веб-додатків із застосуванням значно меншої
кількості коду, ніж під час використання звичайного JavaScript [12].
Створювати інтерактивні інтерфейси користувача на React досить просто.
Достатньо описати, як частини інтерфейсу програми виглядають у різних станах.
React буде своєчасно оновлювати їх, коли дані змінюються.
Декларативні уявлення роблять код більш передбачуваним і спрощують
налагодження.
Оскільки логіка компонента написана на JavaScript, а не міститься в
шаблонах, можна з легкістю передавати різні дані по всьому додатку і тримати стан
поза DOM.
React також може працювати на сервері, використовуючи Node.js та на
мобільних платформах, використовуючи React Native.
4.1.4 Node.js. Node.js представляє собою серверну платформу JavaScript, що
працює на використаному движку Google Chrome - V8, і здатна компілювати код
JavaScript у машинний код [13]. З'явившись у 2009 році, Node.js визначено як
перехід від виконання JS у браузері до його використання як самостійної програми.
Node.js став популярною платформою для створення різноманітних додатків,
включаючи веб-додатки, гібридні програми, REST API та рішення для Інтернету
речей (IoT).
Використання Node.js для розробки серверної частини має свої переваги та
недоліки. Один з головних плюсів полягає в тому, що JavaScript є широко
використовуваною мовою програмування, а Node.js дозволяє використовувати цю
мову і на серверному боці. Такий підхід дозволяє забезпечити швидку
синхронізацію між frontend та backend.
Node.js базується на моделі подій та підтримує оновлення даних в режимі
реального часу, що робить його ефективним для додатків обміну повідомленнями,
онлайн-ігор та відеочатів. Також варто відзначити його неблокуючу систему
введення-виведення, яка дозволяє обробляти запити одночасно, що сприяє
ефективності та відсутності затримок в обробці.
60
Проте Node.js має обмеження у важких обчислювальних завданнях через
свою однопоточну природу та ускладнення взаємодії з важкими обчислювальними
завданнями, пов'язаними із процесором. Також, невдоволення якістю деяких
бібліотек та відсутність належної документації можуть впливати на якість
розробки.
Основні переваги Node.js включають широке використання JavaScript,
потужну бібліотеку та інструменти, ефективність завдяки використанню однієї
мови та високошвидкісну модель подій. Серед недоліків варто відзначити
зниження продуктивності при складних обчислювальних завданнях та відсутність
модерації деяких бібліотек.
4.2 Проєктування моделей бази даних
Проєктування моделей бази даних потрібно для оптимізації використання
ресурсів бази даних. Інформація не повинна повторюватись. Кожна сутність бази
даних повинна бути чітко визначеною.
Основні етапи проєктування бази даних:
 концептуальне проєктування;
 логічне проєктування;
 фізичне проєктування.
Концептуальне проєктування.
Концептуальне проєктування бази даних визначається як процес формування
моделі даних, що використовується у проєкті, залежно від різних аспектів їхнього
представлення. Це етап ініціації проєктування бази даних, під час якого
створюється концептуальна модель даних для аналізованої частини проєкту [21].
Ця модель повністю незалежна від конкретних інструментів розробки, мов
програмування чи інших аспектів реалізації.
Концептуальна модель розробляється відповідно до вимог користувачів. Ця
модель діє основою для наступного етапу проєктування, а саме – логічного
проєктування бази даних.
Концептуальна модель складається з трьох основних компонентів:
61
сутностей, атрибутів (властивостей) та зв’язків. Сутності представляють об'єкти,
що зберігаються в системі, такі як "Експерт", "Групова експертиза" та "Анкета".
Атрибути визначають властивості сутностей, наприклад, атрибути сутності
"Експерт" включають "ПІП", "Логін", "Пароль" та "E-mail". Зв’язки представляють
залежності між сутностями і описуються дієсловами, наприклад, сутність
"Експерт" створює сутність "Групова експертиза" зв’язком "Створює".

Рисунок 4.1 – Концептуальна модель даних
62
Логічне проєктування.
Логічне проєктування є другим етапом у розробці бази даних, де на основі
концептуальної моделі визначається логіка взаємодії з додатком. У додатку
присутня система ролей, тому потрібно створити логічну модель для кожної ролі.
[23].
Наприклад, якщо модератор бажає запросити експерта до групової
експертизи, необхідно відправити запрошення на його електронну пошту. Це
означає, що в базі даних повинні бути збережені запрошення, які не були враховані
на етапі концептуального проєктування.
Під час логічного проєктування враховується специфіка кожної сутності
моделі, проте поки що не розглядаються аспекти фізичної реалізації.
Роль «Експерт» надається кожному зареєстрованому користувачу. Він може
створювати індивідуальні експертизи та відповідно проводити їх. Це мінімальний
доступний функціонал ІС.
Логічна модель для експерта зображена на рисунку 4.2.

Рисунок 4.2 – Логічна модель для експерта
Роль «Модератор» надається адміністратором ІС. Ця роль має усі можливості
ролі «Експерт» та має розширений функціонал. Він може створювати групові
експертизи та проводити їх. Для цього він запрошує експертів до створеної
експертизи та потім може отримати агрегований груповий результат.
63
Логічна модель модератора зображена на рисунку 4.3.

Рисунок 4.3 – Логічна модель для модератора
Роль «Адміністратор» надається через базу даних напряму. Він має усі
можливості ролі «Модератор» та має найвищий рівень прав у системі. Він може
переглядати усіх користувачів та експертизи. Може надавати роль модератора
експертам та відповідно її відміняти.
Логічна модель для адміністратора зображена на рисунку 4.4.

Рисунок 4.4 – Логічна модель для адміністратора
Фізичне проєктування – останній етап проєктування бази даних, яке
проводиться вже під обрану СКБД [24]. СКБД за своїми основами можуть не
підтримувати певні типи даних або підтримувати специфічні, які можуть бути
64
більш зручними для виконання певних специфічних завдань. Це вже створення
моделей на програмному рівні.
MongoDB є документно-орієнтованою базою даних. Вона не використовує
реляційні таблиці. Замість них використовуються колекції – масиви даних, які не
обмежуються кількістю елементів. Це також допомагає у роботі з даними у Node.js,
бо необмежені масиви підтримуються JavaScript за своєю основою.
Згідно концептуального та логічного проєктування можна визначити
наступні сутності:
1. Users – користувачі системи;
2. Blanks – банк анкет експертів, до якого входять анкети індивідуальних
експертиз та анкети експертів для групових експертиз;
3. Group-expertises – створені користувачами групові експертизи;
4. Invitations – створені модераторами запрошення до групових експертиз.
Для кожної визначеної сутності потрібно описати модель.
Сутність «Blank» описана у таблиці 4.1.
Таблиця 4.1 – Фізична модель сутності «Blank».
Ім'я атрибуту Тип Опис атрибуту Обов’язкове
атрибуту поле
creator ObjectId Містить id експерта, який створив +
експертизу.
name String Назва експертизи. +
groupExpertise ObjectId ID групової експертизи, частиною -
якої є анкета.
method String Експертний метод, який +
enum використовується у анкеті.
blank Object Дані анкети. У цій властивості +
описані мета, критерії, альтернативи,
постановка задачі, а також експертні
оцінки у вигляді масивів.
65
result Object Обрахований результат експертизи. -
creationDate Date Час створення експертизи у форматі. +
isClosed Boolean Флаг підтвердження анкети. Якщо +
«True», то змінювати дані неможливо
Сутність «Group-expertise» описана у таблиці 4.2.
Таблиця 4.2 – Фізична модель сутності «Group-expertise».
Ім'я атрибуту Тип Опис атрибуту Обов’язкове
атрибуту поле
creator ObjectId Містить id експерта, який створив +
експертизу.
name String Назва експертизи. +
expertsWeight Array Масив коефіцієнтів ваги експертів. -
experts Array Масив залучених до експертизи -
експертів.
invitedExperts Array Масив експертів, яких запросили до -
експертизи, але експерти ще не
відповіли на запрошення.
method String Експертний метод, який +
enum використовується у анкеті.
blanks Array Масив анкет з експертними оцінками. -
template Object Аналог атрибуту «Blank» +
попередньої сутності. Містить
шаблон для створення анкет.
result Object Обрахований результат експертизи. -
creationDate Date Час створення експертизи у форматі. +
isClosed Boolean Флаг підтвердження експертизи. +
Якщо «True», то змінювати дані
неможливо.
66

Сутність «User» описана у таблиці 4.3
Таблиця 4.3 – Фізична модель сутності «User».
Ім'я атрибуту Тип Опис атрибуту Обов’язкове
атрибуту поле
login String Логін для авторизації. +
password String Пароль для авторизації. Хешується. +
salt String Строка, яка генерується випадково та +
додається до паролю користувача для
подальшого його хешування.
email String Електронна пошта. +
phone String Номер телефону. +
degree String Освіта. -
academicStatus String Академічний рівень. -
direction String Напрямок експертувань. +
activitySphere String Сфера, де працює експерт. +
emailKey String Допоміжне поле, у якому зберігається -
ключ для зміни паролю. Не
поширюється.
role String Роль користувача. +
enum

4.3 Розробка продукту проєкту
З початку потрібно розробити серверну частину системи. Сервер генерується
за допомогою Express самостійно та вже готовий для запуску. Все, що
залишається, – написати маршрути, контролери та сервіси системи. Маршрути –
розпізнають запити та запускають потрібні контролери. Контролери – алгоритми,
67
які надсилають відповідь. Сервіси – допоміжні алгоритми, які використовують
контролери (наприклад, запит до бази даних).
Сервер був розроблений за допомогою Node.js та Express. Структура проєкту
backend частини системи наведена на рисунку 4.5

Рисунок 4.5 – Структура серверної частини системи
У папці «app» знаходиться усі розроблені процеси та алгоритми проєкту.
68
Папка «administration» містить сервіси та контролери для адміністрування. В
неї знаходяться усі операції, які може проводити адміністратор.
Папка «aggregation» містить алгоритми для агрегування результатів групових
експертиз. Саме вона надає груповий результат експертизи.
Папка «auth» виконує реєстрацію, авторизацію та аутентифікацію та містить
алгоритм підтвердження реєстрації.
Папка «CRUD» містить усі CRUD операції для усіх сутностей бази даних.
Папка «mailer» виконує надсилання листів на е-пошту, вона
використовується для підтвердження реєстрації та зміни паролю.
Папка «bin» – це стандартна папка Express.
Папка «config» містить секретний ключ для шифрування jwt токенів.
Папка «models» містить моделі бази даних, які використовуються у системі.
Папка «public» містить файли, побудовані фреймворком React. Містить
скомпільовану frontend частину системи.
Папка «routes» містить маршрути проєкту.
Файл «app.js» – це основний файл сервера, що відповідає за підключення до
бази даних. У ньому, як правило, записують основні налаштування такі як CORS-
налаштування, захист від ін’єкцій і т.д. Усі запити проходять обробку саме цим
файлом, який вже потім розподіляє їх на маршрути.
Після того, як основний функціонал серверу був розроблений, можна перейти
до розробки клієнту.
Клієнтська частина розроблена за допомогою фреймворку React Redux. Весь
проєкт розподілений на сервіси та компоненти. Сервіси – файли, які містять
алгоритми, які виконуються поза інтерфейсом. Наприклад, експертні методи, а
саме їх обрахунки. Компоненти – частини інтерфейсу системи. Вони можуть як
мати якусь логіку, яку вони створені виконувати (наприклад, компонент для
анкетування), так й просто відображати певну інформацію.
Redux дозволяє створити сховище даних у додатку. Усі дані зберігаються там
та є єдиним. Воно є єдиним джерелом істини. Усі операції з даними беруть їх зі
сховища. Для взаємодії з ним написані так названі «actions». Це фрагменти коду,
69
які виконують зміни у середовищі та передають дані з нього у компоненти системи
для їх відображення або інших операцій. Також середовище треба типізувати. Для
цього використовують «slices». Вони розділяють сховище на директорії та
описують кожну змінну, яка в ньому зберігається.
Структура клієнтської частини системи подана на рисунку 4.6.

Рисунок 4.6 – Структура клієнтської частини системи
У директорії «public» розташовані файли локалізації.
70
У директорії «calculation-service» знаходяться алгоритми для математичних
операцій. Наприклад для знаходження максимального значення з вибірки.
У папці «components» розташовані усі компоненти системи.
У папці «calculation» знаходяться компоненти для обрахунків анкет.
У папці «hierarchy» знаходяться файли, які відповідають за графічне
відображення ієрархії.
У директорії «methods» розташовані інтегровані експертні методи.
Папка «models» містить усі інтерфейси та типи змін. Тут описані усі сутності,
які використовуються у клієнтській частині.
Усі інші файли та директорії є стандартними для React.
4.4 Розробка інтерфейсу системи
Зручний інтерфейс та привабливий дизайн є візиткою будь-якої веб-
орієнтованої ІС. З початку була розроблена форма авторизації. Форма відображена
на рисунку 4.7.

Рисунок 4.7 – Форма авторизації
Після цього був розроблений інтерфейс для роботи з експертизами. Це
сторінка, яка відображає список експертиз, до яких користувач має доступ та через
цю сторінку можна перейти до створення нової експертизи. Також було розроблене
головне меню системи. Воно буде постійно відображатись зліва від основного
71
контенту сторінки. Загальний вигляд сторінки для взаємодії з експертизами подано
на рисунку 4.8.

Рисунок 4.8 – Сторінка для роботи з експертизами
Після цього був розроблений інтерфейс для створення та редагування
експертиз. Саме тут користувач описує задачу, яку хоче вирішити. Мета, критерії
та альтернативи прописуються тут.

Рисунок 4.9 – Інтерфейс створення / редагування експертизи
Оскільки експертизи вже можуть бути створені у frontend, потрібно
розробити інтерфейс для анкетування. Для кожного експертного методу був
розроблений свій інтерфейс.
72
Інтерфейс для методу аналізу ієрархій (МАІ) подано на рисунку 4.10.

Рисунок 4.10 – Інтерфейс анкетування для МАІ
Інтерфейс анкетування для методу нормування наведений на рисунку 4.11.

Рисунок 4.11 – Інтерфейс анкетування для методу нормування
73
Для методу ранжування також розроблений інтерфейс анкетування.
Ознайомитись з ним можна на рисунку 4.12.

Рисунок 4.12 – Інтерфейс анкетування для методу ранжування
Висновки до розділу 4
У даному розділі був визначений набір програмного забезпечення для
розробки ІС групової експертизи. Стек «MERN» повністю задовольняє усі вимоги
продукту проєкту. Для зберігання даних використовується документно-
орієнтована СКБД MongoDB. Для забезпечення асинхронної обробки запитів
використовується Node.js з фреймворком «Express». Для розробки frontend частини
системі на основі технології single page application використовується фреймворк
«React».
Розроблена веб-орієнтована ІС групової експертизи повністю виконує свою
функцію, а саме:
- дозволяє створювати експертизи;
- дозволяє проводити індивідуальні експертизи;
- дозволяє проводити групові експертизи з участю інших експертів.
74
ВИСНОВКИ
Мета кваліфікаційної роботи магістра досягнута, тобто в ході її виконання
був спланований проєкт розробки інформаційної системи групової експертизи, був
проведений аналіз оточення проєкту, розроблена концепція проєкту, розроблений
проєкт згідно міжнародного стандарту PMBoK та розроблений продукт проєкту.
Для досягнення поставленої мети в роботі були розв’язані такі завдання:
– визначено набір технологій для розробки;
– спроєктовано базу даних;
– розроблено серверну (backend) частину системи;
– розроблено клієнтську (frontend) частину системи.
У результаті роботи була розроблена ІС групової експертизи, яка в
подальшому буде розгорнута на безкоштовному хостінгу в мережі Інтернет для
користування.
ІС групової експертизи може бути використана менеджерами малого і
середнього бізнесу для проведення професійного експертного оцінювання різних
альтернатив за відповідними критеріями для прийняття ефективних рішень, а
також як інструмент для навчання студентів експертним методам при вивченні
дисциплін, пов’язаних з прийняттям рішень.

75
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Сайт веб-додатку «easyAHP». URL: http://www.easyahp.com/ (дата
звернення: 07.11.23).
2. Сайт веб-додатку «Decisioner». URL: http://decision.tg.ck.ua (дата звернення
07.11.23).
3. Сайт веб-додатку «123ahp». URL: http://123ahp.com (дата звернення
07.11.23).
4. Алгоритм управління змістом проєкту. URL: https://dspace.nuph.edu.ua/
bitstream/123456789/16232/1/Алгоритм%20управління%20змістом%20проєкту.pdf
(дата звернення: 17.11.23).
5. Огляд робочих структур проєкту | Microsoft Learn URL:
https://learn.microsoft.com/uk-ua/dynamics365/project-operations/prod-pma/work-
breakdown-structures (дата звернення: 17.11.23).
6. Мережевий графік URL: https://www.wikiwand.com/uk/Мережевий_
графік(дата звернення: 19.11.23).
7. Що таке діаграма Ганта та як нею правильно користуватися? URL:
https://nachasi.com/creative/2020/09/03/gantt-chart/ (дата звернення: 19.11.23).
8. Ресурсы в MS Project: Добавление, Назначение и Выравнивание URL:
https://blog.ganttpro.com/ru/resursy-ms-microsoft-project (дата звернення: 25.11.23).
9. Управління ризиками URL: https://s2bc950b395389d80.
jimcontent.com/download/version/1553421782/module/14204527623/name/Управлінн
я%20ризиками.pdf (дата звернення: 25.11.23).
10. Сайт MongoDB. URL: http://mongodb.org/ (дата звернення: 07.12.23).
11. Сайт Express. URL: https://expressjs.com/ru/ (дата звернення: 07.12.23).
12. React – JavaScript-библиотека для создания пользовательских
интерфейсов. URL: https://ru.legacy.reactjs.org/ (дата звернення: 07.12.23).
13. Сайт NodeJs. URL: http://nodejs.org/ (дата звернення: 07.12.23).

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