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

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

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

Title:	Розробка веб-орієнтованого модуля організації групової експертизи для системи підтримки прийняття рішень
Authors:	Оксамитна, Любов Павлівна Єфімов, Віктор Вадимович
Keywords:	СИСТЕМА ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ;ГРУПОВА ЕКСПЕРТИЗА;МАІ;NODE.JS;ANGULAR;MONGODB.
Issue Date:	16-Jun-2022
Abstract:	Використання експертних систем дозволяє автоматизувати процес експертизи за допомогою інтерфейсу для оцінювання для експертів і також інтерфейсу визначення мети, критеріїв та альтернатив для керівника. Система може повідомляти як керівника про стан проведення експертизи, так й експертів для своєчасного підключення до процесу експертизи. Розробка власної експертної системи для прийняття рішень дозволяє налаштувати будь які функції під ключ. Від інтерфейсу до додаткових модулів для системи. Розробка експертної системи є актуальною темою, тому що її використання підвищує ефективність підприємств та має потенціал для подальшого її розвитку. Також користування системою можна зробити платним, що є додатковим доходом для компанії-власника. Мета кваліфікаційної роботи бакалавра – створення веб-орієнтованого модуля для експертного оцінювання за допомогою методів прийняття рішень. Об’єкт дослідження: системи прийняття рішень. Предмет дослідження: модуль групової експертизи для системи прийняття рішень. У роботі застосовувалися: теоретичний метод (аналіз літератури з проблеми дослідження). Основні положення і результати кваліфікаційної роботи бакалавра доповідалися і були обговорені на науково-практичній конференції ЧДТУ (Черкаси, 2022). Результати кваліфікаційної роботи бакалавра опубліковані у збірнику тез доповідей студентської науково-практичної конференції ЧДТУ: Єфімов В. В., Оксамитна Л. П., Триус Ю. В. Розробка веб-орієнтованого модуля організації групової експертизи для системи підтримки прийняття рішень. Тези доповідей студентської науково-практичної конференції ЧДТУ, 19-22 квітня 2022 р. Черкаси : ЧДТУ, 2022. С. 62-63.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/8851
Appears in Collections:	124 Системний аналіз (Штучний інтелект)

Files in This Item:

File	Description	Size	Format
Пояснювальна записка_Єфімов Віктор_СА-182_2021-2022.pdf Restricted Access		2.23 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

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

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

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

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

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

Виконав: студент 4 курсу, групи СА-182

спеціальності 124  «Системний аналіз»
(шифр і назва спеціальності)

освітня програма «Системи і методи
(назва освітньої програми)
прийняття рішень»

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

Керівник __________ Оксамитна Л.П.
(прізвище та ініціали)

Рецензент _________ Землянський О.М.
(прізвище та ініціали)

Черкаси 2022 року

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

ЗАТВЕРДЖУЮ
Завідувач кафедри КН та СА
_______________ Триус Ю.В.
«____» _____________ 2022 р.

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

Керівник роботи Оксамитна Л.П., к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «7» лютого 2022 р. №45/04.

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

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

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

КАЛЕНДАРНИЙ ПЛАН

Строк виконання
№ з/п Назва етапів кваліфікаційної роботи магістра Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу
11.012022 Виконано
бакалавра.
2 Аналіз джерел, об’єкту та предмету дослідження.
до 13.02.2022 Виконано
3 Написання теоретичного розділу кваліфікаційної
до 04.03.2022 Виконано
роботи бакалавра.
4 Написання аналітичного розділу кваліфікаційної
до 01.04.2022 Виконано
роботи бакалавра.
5 Написання практичних розділів й висновків до
до 01.05.2022 Виконано
кваліфікаційної роботи бакалавра.
6 Передзахист кваліфікаційної роботи бакалавра
01.06.2022 Виконано
на засіданні кафедри КН та СА.
7 Подання роботи завідувачу кафедри КН та СА. до 16.06.2022 Виконано
8 Захист кваліфікаційної роботи бакалавра. 16.06.2022 Виконано

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

4
РЕФЕРАТ
Кваліфікаційна робота бакалавра містить: 71 с., 25 рис., 1 таблицю, 23
використаних джерел, 2 додатки.
Актуальність теми. Використання експертних систем дозволяє
автоматизувати процес експертизи за допомогою інтерфейсу для оцінювання для
експертів і також інтерфейсу визначення мети, критеріїв та альтернатив для
керівника. Система може повідомляти як керівника про стан проведення
експертизи, так й експертів для своєчасного підключення до процесу експертизи.
Час, який був потрібен на збір експертів, їх доручення до експертизи, їх
введення у мету експертизи та на отримання результатів, тепер, використовуючи
експертну систему, можна витратити на сам процес анкетування (оцінювання)
експертів.
Розробка власної експертної системи для прийняття рішень дозволяє
налаштувати будь які функції під ключ. Від інтерфейсу до додаткових модулів для
системи. Наприклад, додавання нових експертних методів. Можна зробити
систему модульною для полегшення її майбутнього розвитку.
Розробка експертної системи є актуальною темою, тому що її використання
підвищує ефективність підприємств та має потенціал для подальшого її розвитку.
Також користування системою можна зробити платним, що є додатковим доходом
для компанії-власника.
Мета роботи і задачі дослідження. Мета кваліфікаційної роботи
бакалавра – створення веб-орієнтованого модуля для експертного оцінювання за
допомогою методів прийняття рішень.
Для досягнення поставленої мети в роботі розв’язуються наступні завдання:
– провести дослідження існуючих методів експертного оцінювання;
– проаналізувати існуючі системи експертного оцінювання;
– розробити структуру майбутньої системи;
– налаштувати систему ролей майбутньої системи;
– створити моделі баз даних;

5
– розробити backend частину системи;
– розробити front-end частину системи.
Розроблений модуль повинен бути доступним в мережі Internet
користувачам для експертного аналізу реальних задач і проблем, а також
студентам закладів вищої освіти (ЗВО), які вивчають експертні технології
прийняття рішень та їх використання.
Об’єкт дослідження: системи прийняття рішень.
Предмет дослідження: модуль групової експертизи для системи прийняття
рішень.
Методи дослідження. У роботі застосовувалися: теоретичний метод (аналіз
літератури з проблеми дослідження).
Апробація результатів роботи. Основні положення і результати
кваліфікаційної роботи бакалавра доповідалися і були обговорені на науково-
практичній конференції ЧДТУ (Черкаси, 2022).
Публікації. Результати кваліфікаційної роботи бакалавра опубліковані у
збірнику тез доповідей студентської науково-практичної конференції ЧДТУ:
Єфімов В. В., Оксамитна Л. П., Триус Ю. В. Розробка веб-орієнтованого модуля
організації групової експертизи для системи підтримки прийняття рішень. Тези
доповідей студентської науково-практичної конференції ЧДТУ, 19-22 квітня 2022
р. Черкаси : ЧДТУ, 2022. С. 62-63.
Перелік ключових слів: СИСТЕМА ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ,
ГРУПОВА ЕКСПЕРТИЗА, МАІ, NODE.JS, ANGULAR, MONGODB.

ABSTRACT
Master’s work contains. 71 pages, 25 figures, 1 table, 23 sources used, 2
attachments.
Actuality of theme. The use of expert systems allows you to automate the
expertization process using an interface for evaluation for experts and an interface for
determining the goal, criteria and alternatives for the manager. The system can notify
both the manager about the status of the expertization, and experts for timely connection
to the expertization process.

6
The time that was needed to collect experts, assign them to the expertization,
introduce them to the expertization goal and obtain results, can now, using the expert
system, be spent on the process of questioning (evaluating) experts.
Developing your own expert system for decision-making allows you to configure
any turnkey functions. From the interface to additional modules for the system. For
example, adding new expert methods. You can 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.
Also, using the system can be made paid, which is additional income for the owner
company.
Purpose and tasks of the research. The goal of the bachelor's qualification work
is to create a web-based module for expert evaluation using decision-making methods.
To achieve the goal, the following tasks are solved in the work:
– to conduct a study of existing expert evaluation methods;
– to analyze existing expert evaluation systems;
– to develop the structure of the future system;
– to configure the role system of the future system;
– to create database models;
– to develop the backend part of the system;
– to develop the front-end 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: decision-making systems.
The subject of research: group expertise module for the decision-making system.
Research methods: The work used: theoretical method (analysis of literature on
the research problem).

7
Approval of the results of work. The main provisions and results of the
bachelor’s qualification work were reported and discussed at the student scientific and
practical conference of the ChSTU (ChDTU, 2022).
Publications. The results of the bachelor’s thesis are published in the collection
of abstracts of the student scientific and practical conference of the ChSTU:
Efimov V. V., Oksamytna L. P., Trius Yu. V. Development of a web-based module
for organizing group expertise for a decision-making support system. Abstracts of the
reports of the student scientific and practical conference of ChSTU, April 19-22, 2022.
Cherkasy: ChSTU, 2022. Pp. 62-63.
The list of keywords: DECISION SUPPORT SYSTEM, GROUP EXPERTISE,
МАІ, NODE.JS, ANGULAR, MONGODB.

8
ЗМІСТ

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ . 10
ВСТУП........................................................................................................................... 11
1 ОГЛЯД ІСНУЮЧИХ СИСТЕМ ДЛЯ ЕКСПЕРТНОГО ОЦІНЮВАННЯ .......... 13
1.1 Веб-сервіс «Business Performance Management» ............................................. 13
1.2 Веб-ресурс «easyAHP» ....................................................................................... 15
1.3 Веб-ресурс «Online Output» ............................................................................... 17
1.4 Веб-ресурс «123ahp»........................................................................................... 19
Висновки до розділу 1 .............................................................................................. 21
2 ОГЛЯД ІСНУЮЧИХ МЕТОДІВ ЕКСПЕРТНОГО ОЦІНЮВАННЯ ................. 22
2.1 Фактори, що впливають на роботу експертів .................................................. 22
2.2 Роль людського фактору у процесі прийняття рішень ................................... 23
2.3 Узгодженість та компетентність експертів ...................................................... 25
2.4 Анкетні експертні методи .................................................................................. 28
2.5 Метод нормування .............................................................................................. 30
2.5.1 Порівняння альтернатив при однокритеріальному експертному
оцінюванні .............................................................................................................. 30
2.5.2 Порівняння альтернатив при багатокритеріальному експертному
оцінюванні .............................................................................................................. 31
2.5.3 Порівняння альтернатив при багатокритеріальному неоднорідному
експертному оцінюванні ....................................................................................... 32
2.6 Метод ранжування .............................................................................................. 33
2.7 Метод аналізу ієрархій ....................................................................................... 33
Висновки до розділу 2 .............................................................................................. 38
3 РОЗРОБКА ВЕБ-ОРІЄНТОВАНОГО МОДУЛЯ ОРГАНІЗАЦІЇ ГРУПОВОЇ
ЕКСПЕРТИЗИ ДЛЯ СИСТЕМИ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ .............. 39
3.1 Цілі та завдання проекту .................................................................................... 39

9
3.2 Огляд програмних засобів для розробки веб-орієнтованого програмного
забезпечення .............................................................................................................. 42
3.2.1 Серверна мова програмування NodeJS ...................................................... 42
3.2.2 Документно-орієнтована база даних MongoDB ........................................ 44
3.2.3 Фреймворк Angular ...................................................................................... 45
3.2.4 Git – система керування версіями .............................................................. 46
3.3 Проектування бази даних ................................................................................... 46
3.4 Структура проекту .............................................................................................. 54
3.4.1 Структура backend ........................................................................................ 55
3.4.2 Структура frontend........................................................................................ 46
3.5 Розробка інтерфейсу системи………………………………………………….59
Висновки до розділу 3 .............................................................................................. 63
ВИСНОВКИ .................................................................................................................. 64
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................................... 65
ДОДАТКИ ……………………………………………………………………………67

10
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І
ТЕРМІНІВ
БД – база даних;
ПЗ – програмне забезпечення;
МАІ – метод аналізу ієрархій;
ЗВО – заклад вищої освіти;
СКБД – система керування базами даних;
HTML – HyperText Markup Language;
CSS – Cascading Style Sheets.

11
ВСТУП
При роботі зі складними системами виникають проблеми, що виходять за
межі формальних математичних постановок задач.
У випадку, коли строгу математику не доцільно застосовувати, часто
звертаються до послуг т.н. «експертів», тобто людей, чий досвід, розум та інтуїція
можуть зменшити складність проблеми.
Основна мета експертних методів полягає у тому, щоб використати
особистий досвід та інтелект людини, її здібності шукати і знаходити рішення
слабо формалізованих задач. Однак на інтелектуальну діяльність людини багато
впливають зовнішні і внутрішні умови.
Мета роботи і задачі дослідження. Мета кваліфікаційної роботи
бакалавра – створення веб-орієнтованого модуля для експертного оцінювання.
Для досягнення поставленої мети в роботі розв’язуються наступні завдання:
– провести дослідження існуючих методів експертного оцінювання;
– проаналізувати існуючі системи експертного оцінювання;
– розробити структуру майбутньої системи;
– налаштувати систему ролей майбутньої системи;
– створити моделі баз даних;
– розробити backend частину системи;
– розробити front-end частину системи.
Розроблений модуль повинен бути доступним в мережі Internet
користувачам для експертного аналізу реальних задач і проблем, а також
студентам закладів вищої освіти (ЗВО), які вивчають експертні технології
прийняття рішень та їх використання.
Об’єктом дослідження є системи прийняття рішень.
Предметом дослідження є модуль групової експертизи для системи
прийняття рішень.
Методи дослідження.
Для вирішення поставлених завдань були застосовані наступні методи
дослідження:

12
– теоретичний (аналіз літератури з проблеми дослідження);
– емпіричний – полягав у спостереженні роботи систем підтримки
прийняття рішень та їх модулів для групової експертизи;
– порівняльний – для здійснення порівнянь систем підтримки прийняття
рішень та їх модулів для групової експертизи.
Для створення програмного забезпечення використано новітні технології, а
саме: фреймворк Angular, NodeJs сервер і базу даних MongoDB. Обрані технології
задовольняють всім функціональним і не функціональним вимогам до такого типу
програмного забезпечення (ПЗ).

13
1 ОГЛЯД ІСНУЮЧИХ СИСТЕМ ДЛЯ ЕКСПЕРТНОГО ОЦІНЮВАННЯ
1.1 Веб-сервіс «Business Performance Management»
«Business Performance Management» – це безкоштовне веб-рішення на базі
методу аналізу ієрархій (МАІ), як допоміжний інструмент для процесу прийняття
рішень. Дане рішення можна знайти за посиланням: http://bpmsg.com/.
МАІ використовується також для групової експертизи. Можна зберігати
повні вирішення ієрархій та використовувати їх, щоб оцінити вагу критеріїв і
підкритеріїв, можна оцінити до семи альтернатив.
На міжнародному ринку МАІ використовується в широкому діапазоні,
наприклад, для оцінки постачальників, в галузі управління проектами, в процесі
прийому на роботу або оцінки діяльності компанії. Результати парного порівняння
розташовані в матриці. МАІ використовується також для групового прийняття
рішень. Можна зберігати повні вирішення ієрархій та використовувати їх, щоб
оцінити вагу критеріїв та підкритеріїв можна оцінити до семи альтернативних
рішень. Інтерфейс доступний англійською, німецькою, іспанською та
португальською мовою, але він інтуїтивно зрозумілий.
На сайті є коротке знайомлення з основними поняттями, методами та
інструментами для прийняття рішень. Управління ефективністю бізнесу
складається з набору управлінських та аналітичних процесів, які підтримуються
технологіями, які дозволяють підприємству визначати стратегічні цілі, і потім
вимірювати та керувати продуктивністю. Основні процеси керування
ефективністю бізнесу включають: фінансове планування, оперативне планування,
бізнес-моделювання, консолідації та звітності. Для того, щоб скористатись
ресурсом, потрібно зареєструватись та авторизуватись.
Веб-сервіс був розроблений на базі CMS WordPress, скріпти написані на php.
Сервіс використовує протокол HTTPS, що забезпечує безпечне з’єднання з сайтом.
У сервісі є можливість перевести гроші розробнику для його підтримки, сервіс

14
оплати – PayPal. Оскільки розробка була проведена на WordPress,
використовується база даних MySQL.
З інтерфейсом головної сторінки можна ознайомитися на рис 1.1.

Рисунок 1.1 – Інтерфейс головної сторінки «Business Performance Management»
На рис. 1.2 показано заповнення матриці порівнянь альтернатив за
критеріями:

Рисунок 1.2 – Інтерфейс «Business Performance Management» для внесення
експертної думки за допомогою МАІ

15
На рис. 1.3 показано форму входу у групову експертизу.

Рисунок 1.3 – Форма входу в групову сесію в «Business Performance Management»
1.2 Веб-ресурс «easyAHP»
«easyAHP» – це комерційний веб-сервіс для прийняття рішень за допомогою
МАІ. Обмежений функціонал з можливістю визначення до 3 критеріїв та 3
альтернатив доступний безкоштовно. Для розширення функціоналу потрібно
перейти на відповідний тарифний план. Сервіс працює в режимі демо-версії,
доступ до якої можна отримати за посиланням: http://www.easyahp.com/.
Сервіс дозволяє робити оцінки критеріїв та альтернатив за допомогою
графічного інтерфейсу, що значно спрощує роботу з ним. Інтерфейс доступний
лише англійською мовою, але він дуже простий і зрозумілий. Можна зберігати
проекти та відповідно повертатись до них у будь який час. У сервісі можна легко
оперувати критеріями та альтернативами через зручний інтерфейс.
Після визначення критеріїв та альтернатив для початку розрахунків проект
блокується, після чого неможливо вносити зміни у структуру проекту. Інтерфейс
сервісу дозволяє легко вибирати потрібні порівняння та вносити в них зміни.
Відповідно одразу ж перевіряється транзитивність порівнянь.

16
Сервіс складається з двох частин: з опису сервісу на сайті та з системи
прийняття рішень на іншому домені. У першої частині надано опис системи, блог
проекту та контакти розробника.
З інтерфейсом головної сторінки сайту можна ознайомитися на рис 1.4.

Рисунок 1.4 – Інтерфейс головної сторінки «easyAHP»
Перша частина розроблена за допомогою CMS WordPress та використовує
бібліотеку стилей bootstrap. Сайт збирає статистику за допомогою Google
Analytics. Друга частина (саме веб-рішення) розроблена вручну без CMS з
використанням bootstrap, усі розрахунки та взаємодія з базою даних виконується
за допомогою php. База даних – MySQL. Сервіс оплати платного тарифу – PayPal.
Обидві частини використовують HTTPS з’єднання.
З інтерфейсом самої системи можна ознайомитись на рис. 1.5.

17

Рисунок 1.5 – Інтерфейс системи «easyAHP»
1.3 Веб-ресурс «Online Output»
«Online Output» – це комерційне рішення для прийняття рішень, яке реалізує
МАІ у онлайн режимі. Демо версія є доступною безкоштовно з обмеженим
функціоналом, для розширення функціоналу, а саме доступу до групової
експертизи онлайн, потрібно оплатити відповідний тариф. Дане рішення можна
переглянути за посиланням: https://onlineoutput.com.
Сервіс вимагає внесення даних через матрицю порівнянь напряму, тобто
немає графічного інтерфейсу внесення даних у систему. Принцип внесення даних
не є інтуїтивно зрозумілим. Наприклад внесення оберненої оцінки у матрицю
зроблено через дробові числа, тобто щоб показати що альтернати «А1» значно
програє альтернативі «А2» потрібно ввести вручну число «0.2». Також
приходиться вводити нескінчені дроби, наприклад «0.3333», що не зручно.
Сам сервіс доступний лише англійською мовою. Усі проекти, що створені
користувачем зберігаються та їх можна редагувати навіть після проведення
обрахунків, але це стосується демо версії, де групова експертиза проводиться на
одному пристрої офлайн.
Сервіс розподілений на дві частини. Перша частина є візиткою сервісу, де
знаходяться посилання на другу частину сервісу, де проводиться робота з
проектами та обрахунки матриць порівнянь критеріїв та альтернатив. На сайті є

18
короткий опис МАІ та інструкція по використанню сервісу, де описано як вносити
дані у матрицю порівнянь, а також про роботу з сервісом в цілому.
Перша частина веб-ресурсу розроблено за допомогою CMS WordPress.
Функціоналу у цій частині немає. Використовується база даних MySQL. У неї не
зберігаються ніякі дані про користувача, вона потрібна лише для роботи
WordPress. Сайт захищений SSL-сертифікатом.
Дізнатись про засоби розробки другої (функціональної) частини неможливо,
оскільки цей домен є закритим для доступу адміністратором. Єдине в чому можна
бути впевненим це те, що система прийняття рішень використовує небезпечне
HTTP з’єднання.
З інтерфейсом головної сторінки сайту можна ознайомитися на рис 1.6.

Рисунок 1.6 – Інтерфейс головної сторінки «Online Output»
Інтерфейс самої системи представлено на рис. 1.7.

19

Рисунок 1.7 – Інтерфейс системи «Online Output»
1.4 Веб-ресурс «123ahp»
«123ahp» – це безкоштовне веб-рішення для прийняття рішень на базі МАІ з
можливістю групової експертизи. Сервіс не є комплексним та складним, тому що
розроблений для безкоштовного використання. Адреса веб-рішення:
http://123ahp.com.
Інтерфейс сервісу доступний на англійській, німецькій, чеській, польській,
португальській, хорватській, та іспанській мові. Він не є респонсивним, але тим не
менш він є зрозумілим та не вимагає від користувача ніякої теорії. Також на сайті
є короткий опис МАІ та інструкція по роботі з сервісом. Інтерфейс був
розроблений спеціально для звичайного користувача, який хоче прийняти рішення
за допомогою онлайн сервісу.
Ця система також цілком задовольняє потреби й професіоналів та реальних
експертів. Також можливе проведення групової експертизи через цей сервіс.
Доступ до експертизи надається через електронну пошту. Є можливість зробити
групову експертизу приватною, тобто результати експертизи можуть бути
переглянутими тільки тим, хто створив експертизу.

20
Робота з системою зроблена через керування проектами, їх мети, критеріїв
та альтернатив. Введення даних у матрицю порівнянь ведеться через графічний
інтерфейс, який є інтуїтивно зрозумілим та не вимагає ручного введення даних до
матриці. Також це зменшує час, що витрачається на порівняння варіантів.
Сервісі має єдиний, але суттєвий недолік: його інтерфейс дуже дрібний,
розробник не робив його респонсівним, тому багато простору у вікні браузера є
вільним, що робить сайт не зручним; зовнішній вигляд сервісу є дуже бляклим та
непоказливим.
Сервіс написаний без використання будь яких CMS через фреймворк
Microsoft ASP.NET. Інтерфейс написаний на C# за допомогою фреймворку.
Скріпти написані на чистому JavaScript з використанням jQuery. Сервіс
використовує HTTPS з’єднання.
З інтерфейсом головної сторінки сайту можна ознайомитися на рис 1.8.

Рисунок 1.8 – Інтерфейс головної сторінки «123ahp»

21
Інтерфейс системи представлено на рис. 1.9.

Рисунок 1.9 – Інтерфейс системи для внесення експертної думки
Висновки до розділу 1
Розглянуті в даному розділі веб-сервіси не вичерпують все різноманіття
програмних засобів для розв’язування зазначених задач, але вони можуть бути
використані у навчальних цілях при вивченні дисциплін, де розглядаються методи
і системи підтримки прийняття рішень.
Також веб-сервіси будуть корисними представникам малого і середнього
бізнесу для розв’язування реальних економічних задач.
Вони є зрозумілими, більшість з них є комерційними. Деякі мають демо-
версію, в якій можна ознайомитися з функціоналом сервісу. На деяких є відео для
ознайомлення.

22
2 ОГЛЯД ІСНУЮЧИХ МЕТОДІВ ЕКСПЕРТНОГО ОЦІНЮВАННЯ
2.1 Фактори, що впливають на роботу експертів
Найважливішими серед факторів, що впливають на роботу експертів є:
− Ступінь ризику – мається на увазі, що завжди існує імовірність прийняття
помилкового рішення, що може привести до поганих наслідків, таких як втрата
прибутку, погіршення стану людини або отримання незадовільних результатів.
Експерти та аналітики повинні тримати ризики у голові та розуміти свою
відповідальність [5].
− Обмеження часу на прийняття рішення – не завжди вдається
проаналізувати усі варіанти рішення проблеми у наслідку нестачі часу. Як правило
цей фактор завжди присутній у будь-якої задачі на прийняття рішення [5].
− Особисті якості менеджера – менеджер повинен мати відповідні знання
для прийняття рішень [5].
− Політика організації – це суб'єктивний фактор при прийнятті рішення:
статус, влада, авторитет – усе це може вплинути на прийняття того чи іншого
рішення [5].
− Особисті цінності керівника – кожна людина має різні цінності, що
впливає на прийняття рішення [6].
− Середовище прийняття рішення – у процесі оцінювання критеріїв та
альтернатив керівник має проаналізувати усі можливі наслідки з урахуванням
обставин; рішення ухвалюються за різних обставин щодо ризику. Ризик — міра
визначеності, з допомогою якої прогнозується результат [6].
− Зміна середовища – як правило середовище змінюється у часі, Воно може
змінитися настільки, що попередній рейтинг критеріїв може виявитися недійсним
[6].
− Обмеження вхідних даних – іноді для прийняття оптимального рішення
потрібні певні статистичні дані, які можуть бути недоступними або коштувати

23
певних ресурсів (часу або грошей), тому потрібно вирішувати кількість
інформації, оптимальної для прийняття рішень [6].
− Поведінкові обмеження – комплексний фактор, що включає в себе
міжособистісні відносини між працівниками, також серйозно впливає на
прийняття рішення. Кожна людина по-різному сприймає проблеми та їх
серйозність. Може приводити до конфліктів у професійному середовищі, що ніяк
не сприяє пошуку найкращої альтернативи [7].
2.2 Роль людського фактору у процесі прийняття рішень
Процес прийняття управлінських рішень порівняно з іншими видами
психічних процесів людини дуже складний. Особистість людини – унікальний
набір психологічних конструктів, що впливають на сприймання навколишнього
світу в цілому та визначають спосіб мислення, що в свою чергу впливає на
прийняття рішення.
Психічні процеси поділяють на три основних види: пізнавальні, вольові та
емоційні [8]. Інтуїція, пам'ять, сприйняття, мислення, уява й увага – основні
процеси, що беруть участь у прийнятті рішень.
Психічні властивості класифікуються на загальні та індивідуальні. До
перших належать фундаментальні особливості психіки, притаманні усім людям.
До них відноситься обмежена швидкість переробки інформації. Основна причина
– обмеженість обсягу короткочасної пам'яті, що має прямий вплив у прийнятті
рішень. Якщо короткочасна пам’ять заповнена, то нова інформація не зможе
засвоїтись та не буде ефективно використовуватися.
Індивідуальні властивості – це особливості конкретної людини. До них
належать тип мислення, темперамент, психічні реакції на різні подразники,
психічна стійкість, менталітет, емоційність, особливості сприйняття, характер [9].
Індивідуальні якості людей сильніше впливають на процес розробки, ніж на
результат прийняття рішення. Тобто треба розуміти, що на рішення впливають не

24
тільки психічні процеси, а й інші фактори. Вважають, що інтелект лише на 15 %
визначає якість управлінських рішень [10].
Кожний керівник – це звичайна людина, тому скільки б вона не намагалися
«об’єктивно висвітлювати» свої думки – в її діяльності можуть виявитися такі
риси, як «відрив від реальності», домінування власного сприйняття ситуації. Як
наслідок, усі рішення по природі своїй є суб’єктивними, що вже допускає їх
неправильність.
Менеджери повинні вміти контролювати не стільки підлеглих йому, скільки
себе, вміти себе організовувати, мати на увазі психологічний стан як свій так й
навколишніх людей. Його зобов’язання як керівника над підлеглими – бути
психологом, уміти аналізувати і формувати психологічні портрети підлеглих для
ефективного керування людьми й досягнення поставлених цілей.
Приймання рішення людиною не завжди керується логікою. Почуття й
емоції, за винятком наявності психопатії, «конкурують» з розумом і логікою. Тому
немає гарантій чи приймитиметься рішення раціонально чи ні. Процес прийняття
рішень – сукупність взаємодій мислення, інтуїції, почуттів на певний момент часу.
Інтуїція – це так зване «почуття» правильного вибору як правило джерелом
якого є підсвідомість [11]. Використовується так зване «шосте чуття». Але
важливо інтуїцію лише як додатковий незначний фактор, так як це «почуття» як
правило у багатьох випадках є помилковим. Не потрібно зловживати його
використанням у практиці прийняття важливих рішень.
Метод суджень багато в чому схожий з інтуїтивними методами. Але в основі
цього методу лежать знання й достатньо осмислений досвід минулого. Але не
можна «системно» й «автоматично» відокремити раціональне мислення від
інтуїтивного, тому даний метод теж не дає гарантій. Однією з задач менеджера є
виявлення в управлінській роботі «інтуїтивного», «емоційного» та інших підходів.
Розглядаючи вплив особистісних рис менеджера на процес приймання
управлінського рішення, слід мати на увазі склад та різний ступінь прояву окремих
особистісних рис.

25
Темперамент керівника також має серйозний вплив на стратегію та процес
прийняття рішення. Немає такого типу темпераменту, який гірше підходить для
керування – кожний має свою специфіку, переваги та недоліки.
Холеричний тип. Характеризується швидкістю, схильність до
експериментів, та оперативністю під час прийняття рішення. Але рішення часом
спонтанні, ризиковані, рішучі та безкомпромісністю.
Сангвінічний тип. Характеризується швидкістю, оперативністю і
схильністю до колективного обговорення ключових проблем. Але приймання
рішення самотньо для них може бути складним.
Флегматичний тип. Характеризується бажанням отримати великий обсяг
даних для та думок для мінімізації ризиків перед прийняттям рішень. Рішення
характеризуються високим рівнем безпеки й обдуманості. Але для них потрібен
деякий час у запасі. Поки вони не відчують «захищеність» вони не зможуть
раціонально прийняти рішення.
Меланхолійний тип. Характеризується високою точністю. Рішення,
прийняте меланхоліком, є детальним і реальним у виконанні. Меланхоліки – гарні
стратегі, але напружені ситуації можуть вибити їх з колії.
2.3 Узгодженість та компетентність експертів
Після отримання результату експертизи, який як правило є агрегованою
думкою експертів, слід розуміти, що цей результат може бути неточним. Звісно,
експерти – звичайні люди, які хоча й мають відповідні знання та досвід, можуть
помилятися та їх думка може бути непостійною або змінюватися у часі.
Для визначення точності результатів експертизи розраховують два
коефіцієнти:
– коефіцієнт узгодження;
– коефіцієнт компетентності.
Узгодженість – єдність та близькість точці зору на проблему. Вона визначає
наскільки думки експертів схожі між собою. Це потрібно для визначення точності

26
результатів експертного оцінювання. Якщо рівень узгодженості думок експертів
високий, то це означає, що більшість експертів вважають що отриманий
агрегований результат є точним та оптимальним. Якщо узгодженість низька, то
думки експертів дуже відрізняються або поділяються на коаліції. Наприклад,
експерти розділилися на дві групи, думка кожної з яких суттєво відрізняються. У
даному випадку результат експертизи є неточним та приймати рішення на основі
нього дуже ризиковано.
Технологія визначення ступеню узгодження полягає у використанні
коефіцієнта конкордації Кендалла (2.1):

S
W  (2.1)
Smax
2
nr  1 nr mr mr 
де S  S (i, j) S (i, j) – сума квадратів відхилень (різниць)
 r r 
j1 nr j1 i1 i1 
сумарного рангу фактору від середнього сумарного рангу всіх факторів, Smax –
величина S для матриці порівнянь [12].
Компетентність – показник того, наскільки думка експерта є правильно та
вказує на оптимальний результат. Він потрібний для визначення того, чи потрібно
агрегувати думку конкретного експерта. Наприклад, якщо думка експерта суттєво
відрізняється від інших думок, при цьому рівень компетентності експерта низький,
то потрібно виключити цю думку при розрахунку кінцевого результату для
підвищення його надійності.
Технологія визначення ступеню компетентності полягає у використання
коефіцієнта кореляції Спірмена (2.2):

 (i)   min
Dr (i)  r r
max min , i 1,m , r 1,r
   k , (2.2)
r r
де r – індекс критерія оцінювання;
i – індекс експерта;

27
min  min (i) – мінімальне значення з величин  , що характеризують кожного
1im
експерта;
max max (i) – максимальне значення з величин  , що характеризують кожного
1im
експерта [12].
Ступінь надійності результату експертизи визначається частотою випадків,
коли експерти, маючи кілька можливих рішень, надають більшу перевагу тій, яка
в кінцевому результаті виявиться правильною.
Іншими словами розуміють величину, що визначає відхилення прогнозу
експерта від «правильного рішення» (наскільки прогноз відхиляється від істини).
Основні фактори, що впливають на надійність результатів експертизи:
Неточність експертних оцінок.
Основні причини, що приводять до неточності експертних оцінок:
– низка компетентність експертів (у галузі проблеми);
– недостатня підготовленість експертизи;
– слабкості використовуваних методів обробки експертної інформації;
– використання недоречних методик оцінювання альтернативних
варіантів;
– слабкості використовуваних методів обробки експертної інформації;
– слабкості використаних технологій проведення експертиз.
Суперечливість експертних оцінок.
Як правило, думки експертів не завжди є послідовними у своїх оціночних
судженнях. Суперечливості суджень можна усунути через перевірку на
порушення однорідності (узгодженості).
Неузгодженість при колективній експертизі.
Порушення узгодженості суджень показує на надійність отриманого
результату, але треба розуміти, що сам це є показником лише результатів, а не
експертизи в цілому. Наприклад, експерти можуть бути достатньо сильно
узгоджені лише тому, що до експертизи група експертів ставилась чисто
формально без якого-небудь глибокого аналізу. Тоді навпаки, неузгодженість є

28
показником того, що експерти дійсно аналізували складну ситуацію та просто
мають різні думки. У цих випадках потрібно здійснювати більш глибоке
дослідження проблеми.
2.4 Анкетні експертні методи
Анкетні методи є найбільш розповсюдженими та популярними серед
методів експертного оцінювання.
До анкетних методів відносяться:
– метод нормування;
– метод ранжування;
– метод парних порівнянь.
Перевагами анкетних методів є наступні:
– простота;
– відносно мала вартість;
– дозволяють охоплювати велику кількість експертів;
– анонімність експертів;
– результати отримуються на основі статистичного аналізу експертних
даних.
Недоліками анкетних методів є:
– невизначеність стану, у якому прибуває експерт (серйозне або ні,
зацікавленість у результатах і т. п.);
– неоднозначність розмовної мови (відсутність впевненості, що експерт
правильно зрозуміє те, що написано у анкеті);
– суб’єктивність в інтерпретації питань (тиск ззовні, психологічний стан,
ін.);
– можливість відсутність відповідей на частину питань.
Методи анкетування простими словами – заповнення анкет експертами, у
яких надані питання щодо критеріїв та альтернатив, на які потрібно надати
відповідь згідно поставлених цілей. Але при фізичному проведенні експертизи

29
(заповнення анкет у письмовій формі на робочому місці) на експерта впливають
такі психологічні фактори, як небажання критикувати думку інших експертів,
бажання мати спільну думку з більшістю і та ін.
Індивідуальні експертні методи полягають у використанні здібностей і знань
окремого експерта. Вони є дуже простими у організації та проведенні цільового
аналізу. Вони мають суттєвий недолік – обмеженість знань кожного з опитуваних
експертів про стан і розвиток суміжних сфер діяльності.
Цей недолік змушує аналітиків використовувати колективні експертні
методи, які надають можливість задіяти групу експертів, яка добре обізнана у
багатьох суміжних сферах діяльності. Перевага колективних методів полягає в
взаємодії між залученими експертами, що дає змогу проаналізувати проблему з
різних точок зору.
Анкетування – це один з основних методів організації експертиз.
Основні типи анкет:
 фактографічні анкети – це анкети, в які потребують внесення об'єктивної
інформації про проблему експертизи. Такого типу анкети використовують, коли
потрібно одержати статистичні дані, чіткі дані про об’єкт експертизи. Наприклад,
при систематизації даних, розробці банків і баз даних;
 тематичні анкети – це анкети, в яких вноситься думка експертів у
конкретній галузі з визначеного кола цілей;
 цільові анкети – це анкети, призначені для аналізу аспектів управлінських
технологій або їх елементів;
 анкети рішень – це анкети, в яких потрібно обрати варіант рішення тих чи
інших проблем.
Тематичні, цільові та анкети рішень класифікуються як оціночні, якщо в них
присутні пункти, за допомогою яких надається оцінка критеріїв та альтернатив за
обумовленою в анкеті шкалою.
Оцінки проводяться через порівняння важливостей критеріїв та альтернатив
по кожному критерію. Оцінки можуть вноситься явно, тобто оцінка є кількісною
(чіткою), або неявно, де оцінка надана у якісному вигляді діапазону значень в яких

30
знаходиться оцінка. У другому випадку, через якісну оцінку відновлюється
кількісна.
Є два типи анкет: відкритий та закритий типи. Анкети закритого типу мають
строго визначені варіанти відповідей (наприклад, так звані «чекбокси») на кожне
питання, а в анкетах відкритого типу відповіді можуть вноситися у довільній
формі.
2.5 Метод нормування
У методі нормування експертні оцінки критеріїв-альтернатив проводиться
по шкалі від 0 до 1 або у аналогічних значення у відсотках. Експерту надається
анкета з критеріями-альтернативами для надання експертних оцінок. Після
оцінювання заповнена анкета опрацьовується, після чого готовий результат
надається аналітику чи особі, що приймає рішення для подальшого аналізу.
2.5.1 Порівняння альтернатив при однокритеріальному експертному
оцінюванні. Нехай g j (xi ) – це оцінка i-ої альтернативи j-им експертом. Оцінки
g1(xi ) , g2 (xi ) , …, gm (xi ) можна розглядати як статистичні дані оцінок групи
експертів для пошуку «об’єктивної оцінки» g(xi ) (індекс експерта відсутній,
оскільки це оцінка групи в цілому), вважаючи g j (xi )  g(xi ) випадковими
величинами.
В якості наближення g(xi ) можна розглядати деяку статистику (2.3):

g(xi )  g(g1(xi ),g2(xi ),..., gm(xi)) (2.3)

Зазвичай агрегація думок експертів йде через вибіркове середнє (2.4):

1 m
g(xi )   g j (xi ) , i 1,n , (2.4)
m j1

31
де m – число експертів, n – число альтернатив [14].
2.5.2 Порівняння альтернатив при багатокритеріальному експертному
оцінюванні. Зазвичай проблеми, які потребують прийняття рішення, не
характеризуються одним критерієм. Як правило розглядають деяку сукупність
критеріїв. Чим більше критеріїв розглядаються тим більш точною буде кінцеве
рішення.
У випадку, коли альтернативи оцінюються по кільком критеріям (ознакам)
k 1,r : g j,1,g j,2 ,...,g j,r , а також відома думка експертів на ступінь важливості
кожного критерію  j,k , при 0   j,k 1, то в якості наближення до «об’єктивної
оцінки» g(xi ) можна розглядати таку статистику:

1 m r
g(xi )  (H )
j ,k g j ,k (xi ) , 0  
(H )
j,k 1. (2.5)
m j1 k1

У цьому випадку схема ситуації прийняття рішень є наступною (рис. 2.1):

Рисунок 2.1 – Багатокритеріальна оцінка альтернатив j-м експертом
Змінні (H )
j ,k розглядаються як унормовані, тобто (2.6):

32

(H ) j ,k
 j ,k  , 0 
r j ,k 1 , (2.6)
 j ,k
k1
де  j ,k – вихідні експертні оцінки ступеню важливості критеріїв у рамках задачі
прийняття рішення.
2.5.3 Порівняння альтернатив при багатокритеріальному
неоднорідному експертному оцінюванні. Якщо розглядати випадок, коли рівень
компетентності експертів є різним (тобто розглядаємо найбільш реалістичний
випадок), то й вага  j думок експертів є різною, бо оцінкам більш компетентного
експерту потрібно надавити більшу вагу. Тому оцінки альтернатив будуть мати
наступний вигляд:
1 m r
g(x )   (H )
i j  j ,k g j ,k (xi ) ,0   j,k 1, (2.7)
m j1 k1
де рівень компетентності експерта  j визначається або керівником, або
визначаються самими ж експертами:
m
i, j
(H ) i1  i, j
 j 
m m ,i, j  , (2.8)
m
(i, j )  i, j
j1 i1 j1
 1,1 1,2 ... 1,m 
 

   2,1  2,2 ...  2,m 
 i, j    , 0 i, j 1, (2.9)
... ... ... ...
 
 
 m,1  m,2 ...  m,m 
де  i, j – вихідні оцінки j-ого експерту i-им експертом самих себе [14].
Демонстраційні приклади застосування методу нормування подано в
додатку Г.

33
2.6 Метод ранжування
Метод розміщення даних на основі спадання чи зростання показників з
відповідного діапазону оцінок, що дає можливість визначити ранг будь якої
складової в ряду ознак, є методом ранжування [12].
Ранжування доцільно застосувати у наступних випадках:
– коли не має потреби у порівняннях факторів між собою, тобто коли
просто доцільно виставити ранг факторів;
– коли достатньо упорядкувати фактори упорядкувати фактори до певної
властивості, тобто коли не потрібно оперувати точними оцінками;
– коли не можна вимірити певні властивості у даний час, хоча в принципи
вимірювання можливе.
Метод ранжування полягає у тому, що експертна оцінка надається через
числові ранги кожного з наведених у анкеті факторів.
Чим менший ранг, тим важливішим є фактор: тобто ранг рівний 1
присвоюється найбільш важливому фактору, ранг рівний 2 – наступному за
важливістю і т. д.
Бувають ситуації, коли не вдається розподілити ранги чітко між факторами.
В цьому випадку вводять зв’язані ранги (rзв). Вони визначаються наступним
чином: складуються ранги, які складно розподілити між факторами, потім ця сума
ділиться на кількість цих рангів. Наприклад, якщо деяка пара факторів належать
2  3 4
до 2-3-4 місця (ранг), то rзв   3 , якщо четвірка факторів належать до 4,
3
4 5 6 7
5, 6,7 місця, то rзв   5,5 .
4
2.7 Метод аналізу ієрархій
Метод аналізу ієрархій (МАІ) – математичний інструмент системного
підходу до вирішення складних проблем прийняття рішень [15]. Метод дозволяє

34
прийняти рішення за допомогою ієрархічної композиції завдання та
рейтингування критеріїв та альтернатив.
Метод застосовується у різних галузях людської діяльності. МАІ є найбільш
відомим та надійним методом прийняття рішень. За допомогою нього
приймаються рішення навіть у медичної галузі. Наприклад, він використовується
для визначення більш точного діагнозу або для вибору найкращих ліків для
лікування пацієнта.
Тому майже усі системи підтримки прийняття рішень підтримують метод
аналізу ієрархій (МАІ) (Analityc hierarchy process) (AHP).
МАІ не дає «готове правильне рішення», але надає можливість знайти такий
варіант, проводячи поступовий аналіз проблеми. Таким чином, експерт приходить
до альтернативи, яка найкращим чином узгоджується з його розумінням проблеми.
Метод МАІ надає можливість:
1. Провести аналіз проблеми.
Проблема представляється як ієрархія, яка складається з:
а) головної мети прийняття рішення;
б) декількох груп однотипних критеріїв, що впливають на рейтинг;
в) групи можливих альтернатив;
г) системи зв'язків, що вказують на взаємний зв’язок критеріїв і
альтернатив.
Ознайомитись з ієрархією проблеми можна на рис. 2.1.

Рисунок 2.1 – Ієрархія проблеми у МАІ

35
2. Провести збирання даних з проблеми.
Ієрархію проблеми можна розбити на більш менші проблеми, тобто провести
декомпозицію ієрархії та отримати так названу кластерну структуру. Тобто, одну
глобальну задачу «отримання найкращої альтернативи згідно мети за критеріями»
можна розбити сукупність більш простих задач «отримання найкращої
альтернативи згідно критерію». Для цього використовують процедуру попарних
порівнянь, яка надає пріоритети альтернатив до кожного кластеру. Для визначення
ж пріоритетів використовують метод власного вектору.
3. Оцінити і мінімізувати суперечливість даних.
МАІ може допомогти виявити найбільш суперечливі дані, які потрібні для
вирішення найбільш проблемних ділянок задачі.
4. Провести синтез проблеми прийняття рішення.
Після знаходження пріоритетів альтернатив у кожному кластері за
спеціальним алгоритмом розраховується підсумковий рейтинг – вектор
пріоритетів альтернатив. За допомогою нього вже приймаються рішення.
Наприклад, вирішується використати альтернативу з найвищим пріоритетом.
Метод аналізу ієрархій дозволяє оцінити ступінь важливості кожного критерію та
альтернативи. Це означає що фінальне рішення може прийматися не просто
обравши варіант з найвищим пріоритетом, а, наприклад, оцінюючи загальний
вплив на рейтинг усіх факторів.
5. Організувати обговорення проблеми, сприяє досягненню консенсусу.
МАІ можна задіяти у груповій експертизі, у цьому випадку думка кожного
експерту розраховується окремо та може бути відповідно проаналізована на базі
особистого рейтингу пріоритетів. А заключний вектор пріоритетів є агрегованим
вектором думок усіх експертів.
6. Оцінити важливість урахування кожної альтернативи і важливість
урахування кожного критерію, що впливає на пріоритети рішень.
Оптимальність рішення прямо пов’язана з величиною пріоритету у
рейтингу. Це означає, що альтернативи, які мають дуже низький пріоритет не

36
розглядаються у прийнятті рішення, тому що є несуттєвими. Те саме стосується й
критеріїв.
7. Оцінити стійкість прийнятого рішення.
Рішення є обґрунтованим лише тоді й тільки тоді, коли неточність даних та
неточність структури моделі задачі прийняття рішення не впливають суттєво на
заключний вектор пріоритетів альтернатив та критеріїв.
У МАІ структура моделі прийняття рішення є орієнтованим графом, який
включає:
1. Мета (ціль) прийняття рішень.
2. Набір альтернатив.
3. Набір груп однотипних критеріїв, за якими приймається рішення.
4. Зв'язки, що вказують на впливи рішень альтернатив і критеріїв один на
одного.
В МАІ виділяють чотири групи понять:
1. Перша група пов'язана з описом можливих структур моделей прийняття
рішення.
Для визначення пріоритетів альтернатив до надається інформація про
інтенсивність впливів критеріїв і альтернатив один на одного.
2. Друга група пов'язана з описом даних для моделей прийняття рішення.
Після того, як була отримана структура і закінчений збір усіх даних, модель
прийняття рішення є сформованою, тобто в ній можливо отримання рейтингів
пріоритетів критеріїв і альтернатив.
3. Третя група пов'язана з описом результатів, отриманих у моделях
прийняття рішення.
4. Четверта група пов'язана з поясненням організованості обчислення.
Ієрархічного представлення елементів – це основна риса МАІ. Існує кілька
видів ієрархій:
– домінантні – схожі на перевернуте дерево;
– холархії – з оберненим зв'язком;
– модулярні – від простого до складного.

37
Зазвичай для побудови моделі задачі прийняття рішень необхідні
статистичні дані. Основним джерелом статистичних даних є люди, які задіяні у
прийнятті рішень, тобто експерти, клієнти, користувачі і т.д. Як правило, ці дані
подаються у неформалізованому (нечіткому) вигляді, бо людині простіше мислити
образами ніж статистикою.
Метод аналізу ієрархій (МАІ), розроблений Т. Сааті, оперує нечіткими
вхідними даними, так званими попарними оцінками. Ці оцінки надаються
відповідно до «шкали Сааті». Наприклад, оцінки «Очевидно переважає»,
«абсолютно переважає», «незначно програє» за шкалою перетворюються у «7»,
«9» та «1/3» відповідно. МАІ був призначений для підтримки прийняття
багатокритеріальних рішень через вибір одного з множини критеріїв та
альтернатив.
Існують наступні аксіоми МАІ:
– однорідності;
– оберненості (взаємності);
– незалежності вищих рівнів ієрархії від нижчих рівнів.
Застосування МАІ базується на формуванні та використанні ієрархічних
мереж під час побудови моделі. Модель призначена для розрахунку ймовірностей
виникнення кожної можливої ситуації.
Існує ряд модифікацій МАІ:
– з однаковою кількістю альтернатив під критерієм;
– з різною кількістю альтернатив під критерієм.
Крім того, у МАІ є три методи порівняння (рейтингування):
1) попарне порівняння;
2) порівняння альтернатив за стандартами;
3) порівняння альтернатив копіюванням.
У рамках оптимізаційної моделі визначається цільова функція, яка
складається з пріоритетів галузей як коефіцієнтів та обсягів ресурсів (наприклад
фінансових), які необхідно розподілити між галузями, як змінних. Наступним

38
кроком є максимізація даної цільової функції при обмеженнях типу «витрата-
випуск», що враховують мультиплікативні ефекти в економіці.
При цьому існує двоїста задача, яка включає мінімізацію цільової функції,
коефіцієнтами якої є Yi (обсяги кінцевої продукції галузей). Отже, зміни в
пріоритетах галузей надають можливість досліджувати вплив на продукцію Yi.
Метод аналізу ієрархії (Analytic Hierarchy Process) є систематизованою
математичною процедурою для ієрархічного подання елементів, які визначають
сутність певної економічної проблеми [16]. Основна риса МАІ полягає у
декомпозиції проблеми на більш прості складові частини (кластери) та
подальшій обробці оцінок експертів, що подаються у вигляді попарних
порівнянь.
МАІ дозволяє проводити синтез множинних суджень, отримання векторів
пріоритетів критеріїв і знаходження оптимальних рішень (альтернатив). МАІ має
багато практичних застосувань, зокрема реалізований у веб-орієнтованих систем
підтримки прийняття рішень [16] (див. у розділі 1).
Висновки до розділу 2
У другому розділі було розглянуто: анкетні експертні методи, шляхи
визначення компетентності експертів та визначення узгодженості, а також
фактори які впливають на експертну оцінку й метод аналізу ієрархій.
Метод аналізу ієрархій є гарною надбудовою для інших методів для
вирішення погано формалізованих задач, де більш підходять людські досвід і
інтуїція, за допомогою яких надається експертна думка, ніж математичні
розрахунки.
Метод не тільки дає спосіб виявлення найбільш кращого рішення, але й
надає можливість отримати рейтинг альтернативних рішень. Це дозволяє повно і
адекватно виявляти переваги особі, що приймає рішення. Також оцінка міри
суперечливості використаних при аналізі даних дає можливість встановити
ступінь довіри до кінцевого результату.

39
3 РОЗРОБКА ВЕБ-ОРІЄНТОВАНОГО МОДУЛЯ ОРГАНІЗАЦІЇ
ГРУПОВОЇ ЕКСПЕРТИЗИ ДЛЯ СИСТЕМИ ПІДТРИМКИ ПРИЙНЯТТЯ
РІШЕНЬ
Цей розділ призначений для опису засобів розробки системи, цілей та
завдань проекту, моделей даних, виявленню функціональних та нефункціональних
вимог.
Він представляє проектування та саму розробку веб-орієнтованої системи
підтримки прийняття рішень.
3.1 Цілі та завдання проекту
Призначення проекту: підтримка групового та одиночного експертного
оцінювання при вирішенні задач прийняття рішень в режимі онлайн.
Мета створення проекту: простота, зручність та доступність проведення
групового та одиночного експертного оцінювання з метою розв’язування задач
прийняття рішень в режимі онлайн.
Вид програмного забезпечення: веб-орієнтоване програмне забезпечення у
вигляді single page application.
Етапи розробки:
1) постановка завдання;
2) структурування системи;
3) побудова концептуальної і логічної моделі баз даних системи;
4) створення прототипу системи;
5) розробка тестів і тестування прототипу;
6) розробка документації.
В проекті мають бути реалізовані такі функції:
– управління користувачами (реєстрація користувачів, керування ролями);
– ознайомлення з методами експертного оцінювання;
– забезпечення проведення одиночного експертного оцінювання;
– забезпечення проведення групового експертного оцінювання;

40
– керування базою даних;
– розрахунок та видача результатів.
– Мають бути створені такі підсистеми продукту:
– адміністративна частина;
– підсистема для введення вхідних даних для проведення експертиз;
– підсистема реалізації методів експертного оцінювання;
– підсистема для виведення результатів експертного оцінювання;
– підсистема управління базою даних;
– підсистема діалогу з користувачами.
Також мають бути підключені бази даних:
– бази даних по користувачах;
– база даних по групових експертизах;
– база даних по анкетах.
База даних по експертах містить такі поля:
– прізвище;
– ім’я;
– по батькові;
– логін;
– пароль;
– науковий ступінь;
– сфера діяльності;
– галузі, у яких проводить експертизи;
– вчене звання;
– e-mail.
База даних по анкетах містить такі поля:
– назва;
– ID експерта, який створив анкету;
– дата створення;
– ID групової експертизи;
– альтернативи;

41
– критерії;
– експертна думка;
– мета;
– метод, за яким ведеться розрахунок.
База даних по груповим експертизам:
– назва / мета експертизи;
– ID експерта, який створив експертизу;
– дата створення;
– ID експертів, що приймають участь;
– ID анкет, що пов’язані з експертизою;
– альтернативи;
– критерії;
– мета;
– метод, за яким ведеться розрахунок.
Система повинна підтримувати такі методи:
– метод нормування;
– метод ранжування;
– метод аналізу ієрархій.
Вхідні дані:
– назва експертизи;
– назви критеріїв;
– експерти (якщо експертиза групова);
– назви альтернатив;
– дані експертизи кожного експерта по кожному критерію.
Результати:
– таблиця з ознаками і відповідним рейтингом за кожним критерієм;
– коефіцієнт компетентності експертів (якщо експертиза групова);
– коефіцієнт узгодженості всієї експертної групи (якщо експертиза
групова).

42
3.2 Огляд програмних засобів для розробки веб-орієнтованого
програмного забезпечення
Усі засоби розробки повинні задовольняти усім функціональним та
нефункціональним вимогам.
Функціональні вимоги:
– керування базою даних;
– асинхронна обробка запитів;
– модульність (легкість подальшого доповнення системи функціоналом);
– захист від ін’єкцій;
– робота з поштовими сервісами;
– розподілення ролей.
Нефункціональні вимоги:
– зручність використання – повинен бути інтуїтивно зрозумілий інтерфейс
для роботи з системою;
– надійність – система не повинна завершувати свою роботу у будь яких
ситуаціях;
– безпечність – система ролей не повинна дозволяти доступ до ресурсів
нестворених користувачем, за випадком адміністратора.
Цим вимогам повністю задовольняє стек MEAN: «MongoDB + Express.js +
Angular + Node.js».
3.2.1 Серверна мова програмування NodeJS. Node.js – це серверна
платформа JavaScript, яка працює на движку Google Chrome – V8 і може
компілювати код JavaScript у машинний код [17].
NodeJS побачив світ у 2009 році. Платформа була представлена як крок від
JS, що запускається у браузері, до JS, що працює на машині як самостійна
програма.
Це популярна платформа для створення повноцінних веб-додатків Node.js,
гібридних програм, REST API, настільних програм і навіть рішень IoT.

43
Використання Node.js для програмування на стороні сервера має як
переваги, так і недоліки. Щоб зрозуміти, чи підходить ця технологія власному
проекту, варто розглянути обидві сторони.
JavaScript є надзвичайно популярною мовою програмування. У той же час
Node.js розглядається як незалежна технологія. Вона охоплює всі переваги
JavaScript, але на серверній частині.
Node.js спирається на модель на основі подій. Він передбачає оновлення
даних в режимі реального часу, що важливо для програм обміну повідомленнями,
онлайн-ігор і відеочатів. Використання однієї і тієї ж мови на frontend та backend
– найкращий спосіб швидкої синхронізації.
Нарешті, Node.js пропонує неблокуючу систему вводу-виводу, яка дозволяє
обробляти запити одночасно. Коли запити надходять, вони обробляються
ефективно та без затримок. На відміну від асинхронної обробки запитів (що є
основною перевагою Node.js), синхронна обробка обробляє запити один за іншим.
Це означає, що запит не може бути оброблений, якщо в процесі є інший.
Асинхронна обробка Nodejs дозволяє обробляти запити без блокування потоку.
Node.js є однопоточним і керується подіями, і тому він не підходить для
важких обчислювальних завдань. Отримуючи велике обчислювальне завдання, він
максимально використовує потужність ЦП для вирішення цього завдання,
залишаючи інші завдання виконуватися в черзі. Це означає уповільнення всього
потоку подій, що заважає інтерфейсу. «Робочі потоки» були введені для вирішення
цієї проблеми, але це рішення не є абсолютно ефективним для обробки
обчислювальних завдань, пов’язаних із процесором.
Хоча бібліотек npm здається багато, якість багатьох бібліотек залишає
бажати кращого. Багато з них не мають належної документації. Оскільки це
система з відкритим вихідним кодом, професійний моніторинг тут дуже малий,
тому багато пакетів не відповідають стандартам кодування.
Виходячи з вище написаного можна виділити наступні переваги та недоліки.
Переваги:
– це широко поширена мова;

44
– велика бібліотека та інструменти;
– ефективність завдяки використанню однієї мови;
– висока швидкість і продуктивність;
– високошвидкісна модель на основі подій.
Недоліки:
– зниження продуктивності під час виконання складних обчислювальних
завдань;
– відсутність модерування бібліотек.
3.2.2 Документно-орієнтована база даних MongoDB. MongoDB – це база
даних, заснована на нереляційній моделі документа [18]. Таким чином, як так
звана база даних, вона принципово відрізняється від звичайних реляційних баз
даних, таких як Oracle, MySQL або Microsoft SQL Server.
Крім моделі документів, MongoDB принципово відрізняється від
традиційних баз даних. Завдяки своїй функціональності він здатний координувати
кілька серверів для зберігання даних.
Основні переваги:
Відмовостійкість – щоб забезпечити відмовостійкість на роботі, резервні
копії одних і тих же даних зберігаються на різних серверах. Помилка одного
сервера не впливає на застосунок.
Масштабованість – MongoDB легко масштабується на декількох серверах
для зберігання та обробки даних. Таким чином, обсяг даних і вимоги до
продуктивності зростають. Користувач може легко додати більше серверів замість
оновлення дорогих мейнфреймів. Це також ідеально підходить для хмарних
середовищ, де навантаження розподіляється на багатьох комп'ютерах;
Запити MongoDB можуть бути дуже швидкими, оскільки зазвичай всі дані
знаходяться в одному місці, і їх можна легко отримати за один пошук. Але це вірно
лише тоді, коли дані є справді документом. Коли база даних намагається
емулювати реляційну модель, вона починає працювати дуже повільно, тому що
можливо доведеться виконувати багато незалежних запитів, щоб отримати один
документ. Це така особливість, яку не можна однозначно перевести у розряд

45
переваг чи недоліків. Все залежить від проекту, у якому ця база даних
використовується
Оскільки Node.js використовує JavaScript, немає необхідності відображати
дані JSON, що повертаються з MongoDB, оскільки JavaScript є наднабором JSON.
По суті, вирішення об’єктно-реляційної невідповідності за самою своєю
природою. Працювати з JSON також легше в цілому, оскільки він легше
вписується в те, як представляються дані на клієнті.
3.2.3 Фреймворк Angular. Angular – це платформа JavaScript з відкритим
вихідним кодом, написана на TypeScript. Його основна мета – розробка
односторінкових додатків [19].
Angular дозволяє працювати з частина інтерфейсу як з окремими
компонентами зі своєю чіткою структурою. Кожний компонент описується
шаблоном HTML, стилями CSS та TypeScript файлом, де описані залежності,
модулі, бібліотеки та функціонал компонента.
Сам по собі TypeScript, на відміну від JavaScript, спонукає розробника
писати код чистим з правильною структурою та стилем написання. Він є об’єктно-
орієнтованою мовою програмування, а не мовою скріптів. Також сам TypeScript –
це вдосконалений JavaScript, тому людині, що працювала з JavaScript, дуже
швидко опанує цією мовою.
Недоліком цього фреймворку є складність навчання. Він дуже строгий та
комплексний. Наприклад, якщо був створений сервіс який надає дані, то потрібно
його прописати у секції «providers» у «app-modules», файлі який об’являє усі
компоненти, модулі та бібліотеки.
Строгість фреймворку полягає у використанні TypeScript для написання
функціональної частини компонентів та сервісів, що може збити з толку
розробника, який працював з іншими фреймворками, що працюють на JavaScript,
або не працював з ніякими фреймворками зовсім.

46
3.2.4 Git – система керування версіями. Git – система керування версіями,
яка була створена під час розробки ядра Linux. Система пов’язана з хмарою, на
якої зберігаються проекти, підключені до системи [20].
Основна мета Git – полегшення доступу до проектів розробникам, а також
роботи команди з проектом. Система дозволяє робити окремі копії проектів
(гілки), з яким член команди розробки може працювати як завгодно, не заважаючи
іншим розробникам – внесення змін буде проводитись лише у рамках гілки, зміст
якої був відредагований.
Система гілок дозволяє кожному члену команди працювати над власними
задачами окремо від інших, у той же час не підставляючи роботу інших у
небезпеку власними змінами.
Система керування версіями також дозволяє переглядати зміни в рамках
кожної задачі через коміти. Коміти – група змін у рамках гілки з власним описом,
яка дозволяє через інтерфейс системи преглянути що саме було змінено і для чого,
якщо був доданий детальний опис.
Гілка може бути об’єднана у іншу. Тобто усі зміни з однієї гілки можуть бути
перенесені у іншу (функція «Merge»). При цьому гілка яка «мерджилась» буде
злита з другою. При цьому модератору потрібно вирішити конфлікти – зміни з
двох гілок, які конфліктують між собою.
Також Git, а саме його хмарний модуль, може використовуватися як
звичайна хмара для зберігання проекту та його розповсюдження. Доступ до
проектів може контролюватися власником репозіторію. Зараз багато середовищ
розробки IDE підтримують інтеграцію з Git, що значно полегшує використання
системи розробниками.
3.3 Проектування бази даних
Задача проектування баз даних – визначення моделей колекцій таким чином,
щоб поля колекцій зберігали усі необхідні дані та й не було допущено їх
повторень. Тобто, основна мета проектування – оптимізація пам’яті бази даних.

47
Основні етапи проектування бази даних:
– концептуальне проектування;
– логічне проектування;
– фізичне проектування.
Концептуальне проектування.
Концептуальне проектування бази даних – процес створення моделі
використовуваних у проекті даних, які залежать від будь-яких аспектів їх
представлення.
Концептуальне проектування – перший етап проектування бази даних, у
процесі чого створюється концептуальна модель даних для частини проекту, що
аналізується [21]. Модель абсолютно не залежить від набору використаних для
розробки прикладних програм, мови програмування чи будь-яких інших аспектів
її реалізації. Ця модель даних розробляється відповідно до вимог користувачів. У
процесі розробки модель даних постійно редагується, покращується та
перевіряється на відповідність вимогам користувачів. Створена модель даних
проекту на даному етапі є основою для наступного етапу проектування – логічного
проектування бази даних.
Концептуальна модель складається з наступних трьох основних
компонентів:
– сутності;
– атрибути (властивості);
– зв’язки.
Сутності – це об’єкти, які зберігаються у системі, щось конкретне, що
можна уявити або побачити [22]. Наприклад, у нашому проекті, це «Експерт»,
«Групова експертиза» та «Анкета» (яка працює також як одиночна експертиза).
Атрибути – це властивості сутностей, простою мовою це властивості
об’єктів у документно-орієнтованої бази даних або поле таблиці у реляційної бази
даних [22]. Наприклад у сутності «Експерт» атрибути: «ПІП», «Логін», «Пароль»
та «E-mail».

48
Зв’язки – це представлення залежності між сутностями. Звичайно
описуються дієсловом [22]. Наприклад, сутність «Експерт» створює сутність
«Групова експертиза», у даному випадку зв’язок – «Створює».
Концептуальна модель представлена на рис. 3.1.

Рисунок 3.1 – Концептуальна модель даних
Логічне проектування.
Логічне проектування – другий етап проектування бази даних, у процесі
якого, на основі концептуальної моделі, визначається логіка роботи з додатком.
Якщо є система ролей у додатку, зазвичай робляться логічні моделі для кожної
роли. Це потрібно для визначення структури даних з точки зору звичайного
користувача [23].

49
Наприклад, експерт хоче запросити іншого експерта у свою групову
експертизу. Для цього потрібно надіслати запрошення на його електронну пошту.
Тобто у базі даних повинні зберігатися запрошення, які не були передбачувані
концептуальною моделлю.
На цьому етапі починає враховуватися специфіка кожної сутності моделі,
але поки що не враховуються аспекти фізичної реалізації. Логічна модель для
адміністратора зображена на рис. 3.2, модель для експерта – на рис. 3.3.

Рисунок 3.2 – Логічна модель для адміністратора

Рисунок 3.3 – Логічна модель для експерта
Фізичне проектування.
Фізичне проектування – останній етап проектування бази даних, яке
проводиться вже під конкретну СКБД. СКБД за своїми основами можуть не

50
підтримувати деякі типи даних або підтримувати специфічні, які можуть більш
підходити під конкретне завдання. Це вже створення моделей на програмному
рівні.
У MongoDB замість таблиць використовуються колекції – масиви даних, які
не обмежуються кількістю елементів, тобто можуть «розтягуватися». Це також
допомагає у роботі з даними у Node.js, бо необмежені масиви підтримуються
JavaScript за своєю основою.
При аналізі логічних моделей було вирішено створити наступні колекції:
– Experts (експертів);
– Admins (адміністраторів);
– Group-expertise (групових експертиз);
– Blanks (анкет, які є одночасно й бланками для групових експертиз та
одиночними експертизами);
– Invitations (запрошень на групову експертизу).
Оскільки MongoDB є документно – орієнтованою, то й схема колекцій буде
у вигляді об’єктів з властивостями, які можуть визначатися певними опціями чи
може властивість бути невизначеною, повторюватися або є посиланням на об’єкт
іншої колекції.
Список основних опцій:
– type – тип змінної властивості;
– required – булева опція, яка вказує на обов’язкове визначення змінної
значенням;
– unique – булева опція, яка вказує на обов’язкову унікальність значення
змінної;
– ref – опція яка вказує на посилання на об'єкт іншої колекції (через id);
– default – опція яка задає конкретне значення, якщо змінна не була
визначена при створені об’єкту.
Колекція «Experts» складається з:
– name – ім’я (обов’язкове поле);
– surname – прізвище (обов’язкове поле);

51
– lastname – по батькові;
– email – електронна пошта (обов’язкове поле);
– login – логін (обов’язкове унікальне поле);
– password – пароль (обов’язкове унікальне поле).
Фізична модель колекції «Experts» зображена на рис. 3.4:

Рисунок 3.4 – Модель колекції «Experts»
Колекція «Admins» має таку ж саму структуру як і колекція «Experts».
Колекція «Blanks» складається з:
– name – ім’я / мета експертизи (обов’язкове поле);
– creator – експерт, що створив анкету (обов’язкове поле, посилання на
колекцію експертів);
– groupExpertise – групова експертизу, частиною складової якої є бланк
(посилання наколекцію групових експертиз);
– method – експертний метод (обов’язкове поле);
– blank – дані анкети;

52
– result – результат експертизи;
– creationDate – час створення;
– isClosed – флаг підтвердження анкети.

Рисунок 3.5 – Модель колекції «Blanks»
Колекція «Group-expertise» складається з:
– name – ім’я / мета експертизи (обов’язкове поле);

53
– creator – експерт, що створив анкету (обов’язкове поле, посилання на
колекцію експертів);
– blanks – список анкет, що використовуються у експертизі (посилання на
колекцію анкет);
– experts – список експертів, які приймають участь у експертизі (посилання
на колекцію експертів);
– template – шаблон для анкет, що створюються у рамках експертизи;
– result – результат експертизи;
– creationDate – час створення;
– isClosed – флаг підтвердження експертизи.

Рисунок 3.6 – Модель колекції «Group-expertise»
Фактично структура групової експертизи повторює структуру
індивідуальної експертизи, але є певні відмінності. Замість властивості «blank»

54
використовується «template», яка містить необхідну інформацію для створення
експертних анкет для експертів, де вони надають свою експертну думку у рамках
групової експертизи. Також були додані такі поля, як: «experts», «expertsWeight»
та «blanks», необхідні вже для проведення групової експертизи.

Рисунок 3.7 – Модель колекції «Group-expertise»
Таким чином, в результаті концептуального, логічного та фізичного
проектування була повністю спроектована база даних системи на MongoDB.
3.4 Структура проекту
Структура проекту – деталізована схема розподілу елементів проекту, їх
відокремлення та каталогізація. Грамотна структура проекту дозволяє легше

55
зрозуміти принцип роботи проекту людині, яка з ним ще не знайома, та спрощує
роботу над ним, тому що код є більш організованим та читабельним.
Добре організована структура також дозволяє зробити систему модульною,
тобто спрощує її подальше вдосконалення та розширення функціоналу. У рамках
даного проекту повинні бути організовані дві структури: структура backend
частини та структура frontend частини.
3.4.1 Структура backend. Перш за все опишемо структуру backend частини
проекту, яка наведена на рис. 3.8.

Рисунок 3.8 – Структура backend частини проекту
У папці «app» знаходиться уся логіка проекту, яка розподілена на сервіси та
контролери.

56
Директорія «administration» містить логіку для адміністрування. Усі
операції, які може проводити адміністратор з іншими користувачами та їх
ресурсами заходяться тут.
Директорія «aggregation» містить логіку агрегування результатів групових
експертиз. Саме вона надає груповий результат експертизи за експертними
думками.
Папка «auth» виконує авторизацію та аутентифікацію, а також реєстрацію та
її підтвердження.
Директорія «CRUD» містить усі операції з базою даних (операції для
адміністратора знаходяться у папці «administration»).
Директорія «mailer» виконує надсилання листів на е-пошту, а також
відповідальна за підтвердження операцій, для яких використовується е-пошта.
Папка «bin» потрібна для запуску проекту, це стандартна папка express.js.
Директорія «config» містить ключі для шифрування jwt токенів, які
використовуються для аутентифікації.
Папка «methods» містить реалізації експертних методів при агрегуванні.
Папка «models» містить усі моделі даних, які використовуються у проекті.
Директорія «entities» потрібна для зберігання моделей сутностей проекту
(індивідуальна експертиза / анкета та групова експертиза, також у подальшому
буде містить інші сутності).
Директорія «keys» відповідає за моделі ключів, які потрібні для зміни е-
пошти та паролей користувачів. Папка «users» містить модулі даних користувачів.
Папка «public» містить файли, побудовані фреймворком «Angular».
Потрібна для відображення frontend частини проекту.
Папка «routes» містить рути проекту, саме ця папка відповідальна за
розпізнання запитів та надсилання відповідей на них.
Файл «app.js» – це основний файл сервера та відповідає за підключення до
бази даних, за певні налаштування серверу, за реагування на запити згідно «CORS»
та за захист від no-sql ін’єкцій.

57
3.4.2 Структура frontend. Тепер розглянемо структуру frontend частини
проекту, яка наведена на рис. 3.9.

Рисунок 3.9 – Структура frontend частини проекту
Усі спроектовані файли створені у папці «app», усі інші директорі є
стандартними для фреймворку «Angular» та середовищ розробки.
Директорія «components» містить усі компоненти проекту, які розподілені
по директоріям:
– account – профіль користувача;
– administration – компонент адміністрування (для адміністратора);
– blank-components – директорія з усіма компонентами для роботи з
індивідуальними експертизами / анкетами;

58
– group-expertise-components – директорія з усіма компонентами для
роботи з груповими експертизами;
– loader – компонент кола завантаження;
– req-components – директорія для майбутньої функції додатку
«замовлення на проведення експертизи»;
– signin – компонент для логіну;
– signup – компонент для реєстрації.
Директорія «interfaces» містить інтерфейси для роботи проекту. Директорія
«services» містить усі сервіси проекту, а саме:
– loader – директорія сервісів для роботи кола завантаження;
– methods – директорія реалізації експертних методів;
– access-guard-service.ts – сервіс для контролю доступу користувача до
компонентів веб-додатку;
– check-entity.service.ts – сервіс для отримання поточного ресурсу, з яким
працює користувач;
– data-sharing.service.ts – сервіс для передачі інформації між
компонентами;
– hierarchy.service.ts – сервіс для роботи ієрархічний графів (для методу
аналізу ієрархій);
– http.service.ts – сервіс для http-запитів;
– popup.service.ts – сервіс для модальних вікон;
– position.service.ts – сервіс для отримання поточного місця користувача у
– системі.
Також треба звернути увагу ще на файли:
– app.component.* – головний компонент;
– app.module.ts – кореневий модуль;
– app-routing.module.ts – роутер «Angular».

59
3.5 Розробка інтерфейсу системи
Грамотний інтерфейс дозволяє полегшити використання веб-додатку
користувачем, а також виділяє цей додаток від інших. Основними кольорами
інтерфейсу визначено синій та білий.
Інтерфейс для авторизації наведений на рис. 3.10. Це звичайна форма
авторизації за логіном та паролем.

Рисунок 3.10 – Інтерфейс для авторизації
З інтерфейсом для реєстрації можна ознайомитись на рис. 3.11. Ця форма
передбачає введення основних даних користувача.

Рисунок 3.11 – Інтерфейс для реєстрації

60
Загальний вигляд системи разом з інтерфейсом для перегляду експертиз
користувача наведений на рис. 3.12.

Рисунок 3.12 – Загальний інтерфейс системи з переглядом експертиз
Інтерфейс створення експертизи наведений на рис. 3.13. Для методу аналізу
ієрархій показується ієрархічний граф.

Рисунок 3.13 – Інтерфейс створення експертизи

61
Інтерфейс запрошення експертів до групової експертизи (рис. 3.14) містить
головну інформацію про експертів та надсилає на їх е-пошту запрошення.

Рисунок 3.14 – Інтерфейс запрошення експертів
Інтерфейс для внесення експертної думки представлений на рис. 3.15. При
вводі даних у матриці порівнянь система виводить розраховані показники у
зручному для аналізу вигляді через таблиці та діаграми.

Рисунок 3.15 – Інтерфейс внесення експертної думки
Інтерфейс для виводу агрегованих думок експертів для групової експертизи
наведений на рис. 3.16.

62

Рисунок 3.16 – Інтерфейс виводу результатів групової експертизи

Висновки до розділу 3
У даному розділі розглянуто мету, цілі та завдання проекту, а також вимоги
до нього. Був визначений стек (набір) програмного забезпечення для розробки та
підтримки проекту. Стек «MEAN» повністю задовольняє усі потреби та вимоги
проекту. Для зберігання цілісності даних використовується MongoDB. Для
підвищення оптимізації роботи серверної частини проекту з базою даних та для
забезпечення асинхронної обробки запитів використовується Node.js з
фреймворком «Express.js». Для розробки оптимізованої frontend частини на основі
технології single page application використовується фреймворк «Angular».
Розроблений веб-орієнтований модуль для організації групової експертизи
для системи підтримки прийняття рішень дозволяє виконувати усі необхідні
операції з експертизами для її проведення. Від її створення до отримання
результатів.

64
ВИСНОВКИ
Мета кваліфікаційної роботи бакалавра досягнута, тобто в ході її виконання
досліджено певні експертні методи, які потребують реалізації у модулі організації
групової експертизи, а саме: метод аналізу ієрархій, метод нормування та метод
ранжування.
Для досягнення поставленої мети в роботі розв’язувалися наступні завдання:
– визначення набору програмних засобів для розробки;
– проектування бази даних;
– розробка серверної частини модулю;
– розробка клієнтської частини модулю.
В результаті роботи були порівняні деякі існуючі системи підтримки
прийняття рішень з можливістю проведення групових експертиз, досліджені певні
експертні методи та розроблений сам модуль безпосередньо.

65
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Бідюк П. І., Коршевнюк Л. О. Проектування комп’ютерних інформаційних
систем підтримки прийняття рішень. Навчальний посібник. Київ: ННК
«ІПСА» НТУУ «КРІ», 2010. 340 с.
2. Вітлінський В. В. Економічний ризик: ігрові моделі: Навч. посібник / В. В.
Вітлінський, П. І. Верченко, А. В. Сігал, Я. С. Нако нечний // За ред. д-ра
екон. наук, проф. В. В. Вітлінського. К.: КНЕУ, 2002. 446 с.
3. Вольский В. И., Лезина З. М. Голосование в малых группах: процедуры и
методы сравнительного анализа. М.: Hаука, 1991. 192 с.
4. Гнатієнко Г.М., Снитюк В.Є. Експертні технології прийняття рішень.
Монографія. К.: «Маклаут», 2008. 444 с.
5. Калініна І. О. Стаття Врахування компетентності експертів у методах
багатокритеріального аналізу в задачах раціонального вибору. /Калініна І.
О., Гожий О. П., Мусенко Г. О., 20.04.2012 р.
6. Катренко А.В., Пасічник В.А., Пасько В.П. Теорія прийняття рішень. К.,
2009.
7. Литвак Б. Г. Экспертные оценки и принятие решений. М.: Патент, 1996. 271
с.
8. Методологія експертного оцінювання: Конспект лекцій для використання в
навчальному процесі в системі підвищення кваліфікації кадрів / Уклад.
Новосад В. П., Селіверстов Р. Г.// К.: Вид-во НАДУ, 2007. 56 с.
9. Петруня Ю. Є., Говоруха В. Б., Літовченко Б. В. та ін. Прийняття
управлінських рішень. Навч. посіб./ за ред. Ю. Є. Петруні. 2-ге вид. К.:
Центр учбової літератури, 2011. 216 с.
10. Черноруцкий, И. Г. Методы принятия решений. СПб.: БХВ-Петербург,
2005. 416 с.
11. Волошин О.Ф., Мащенко С.О. Моделі та методи прийняття рішень.
Навчальний посібник для студентів вищих навчальних закладів. К.:
Видавничо-поліграфічний центр "Київський университет", 2009. 340 с.

66
12. Шишов К. Методы организации и оценки качества экспертиз”. URL:
http://shishov-gip103.narod.ru/a_exp.doc (дата доступу: 18.11.2021 р.).
13. Collaboration Software for Organizational Decision-Making. URL:
http://expertchoice.com/products-services/comparion-s (дата доступу:
18.11.2021 р.).
14. Топчій О.О., Зайцєва М.Л. Стаття “Методи парних порівнянь в економічних
дослідженнях”. URL:
http://www.rusnauka.com/SND/Economics/13_topchiy.doc (дата доступу:
18.11.2021 р.).
15. Сайт AngularJs. URL: https://angularjs.org/ (дата доступу: 18.01.2022 р.).
16. Сайт MakeItRational. URL: http://makeitrational.com/ (дата доступу:
15.01.2022 р.).
17. Сайт Business Performance Management. URL: http://bpmsg.com/ (дата
доступу: 15.01.2022 р.).
18. Сайт «Decision Lens». URL: http://www.decisionlens.com/ (дата доступу:
15.01.2022 р.).
19. Сайт «Expert Choice». URL: http://expertchoice.com/ (дата доступу:
15.01.2022 р.).
20. Сайт NodeJs. URL: http://nodejs.org/ (дата доступу: 15.01.2022 р.).
21. Сайт MongoDb. URL: http://mongodb.org/ (дата доступу: 15.01.2022 р.).
22. Сайт фреймворк Express. URL: http://expressjs.com/ (дата доступу:
15.01.2022 р.).
23. Концептуальне та логічне проектування комп’ютерних систем реального
часу. Дніпро: ДНУЗТ, 2018. 274 с.

67
ДОДАТОК А

Затверджую
Зав. кафедри КНтаСА,
______________ Триус Ю.В.
«____»____________2022 р.

РОЗРОБКА ВЕБ-ОРІЄНТОВАНОГО МОДУЛЯ ОРГАНІЗАЦІЇ ГРУПОВОЇ
ЕКСПЕРТИЗИ ДЛЯ СИСТЕМИ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ

Специфікація
482.ЧДТУ. 21802-01 12 01

Листів 2

Розробник ____________________ Єфімов В.В.

Керівник ____________________ Оксамитна Л.П.

Черкаси – 2022

68
482.ЧДТУ. 21802-01
Позначення Найменування Примітка

Документація

482.ЧДТУ. 21802-01 90 01 Публікація по темі
кваліфікаційної роботи
бакалавра

69
ДОДАТОК Б

ТЕЗИ ДОПОВІДЕЙ СТУДЕНТСЬКОЇ НАУКОВО-ПРАКТИЧНОЇ
КОНФЕРЕНЦІЇ ЧДТУ

Публікація по темі кваліфікаційної роботи бакалавра
482.ЧДТУ. 21802-01 90 01

Листів 3

Розробник: _________________ Єфімов В.В.

Черкаси – 2022

70

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ЧЕРКАСЬКИЙ
ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ЗБІРНИК ТЕЗ ДОПОВІДЕЙ
СТУДЕНТСЬКОЇ НАУКОВО
ПРАКТИЧНОЇ
КОНФЕРЕНЦІЇ ЧДТУ
19-22 квітня 2022 р.

Черкаси 2022

71
РОЗРОБКА ВЕБ-ОРІЄНТОВАНОГО МОДУЛЯ ОРГАНІЗАЦІЇ
ГРУПОВОЇ ЕКСПЕРТИЗИ ДЛЯ СИСТЕМИ ПІДТРИМКИ
ПРИЙНЯТТЯ РІШЕНЬ
Єфімов В.В. (студент ФІТІС), Оксамитна Л.П., к.т.н., доцент,
Триус Ю.В., д.п.н., проф.
Черкаський державний технологічний університет

Методи експертного оцінювання застосовують при прийнятті рішень
у різних галузях діяльності людини. Вони незамінні під час
вирішення складних управлінських та соціально-економічних проблем,
аналізу й прогнозування ситуацій в умовах ризику та невизначеності.
Було спроектовано і розроблено модуль організації і проведення
групової експертизи для системи підтримки прийняття рішень (СППР), що
надає можливість за методом аналізу ієрархій та анкетними методами
нормування і ранжування здійснювати групове експертне оцінювання у
задачах вибору найкращої альтернативи з багатьох можливих за певними
критеріями. Модуль дозволяє задіяти групу експертів, визначену експертом-
модератором, який створив експертизу. Експертиза характеризується:
назвою, метою, постановкою задачі, критеріями та альтернативами. Після
роботи кожного окремого експерта у межах експертизи розрахунок групової
оцінки проводиться з використанням механізмів агрегування експертних
оцінок всіх експертів. Модуль розроблявся за допомогою стеку MEAN
(MongoDB, Express.js, Angular, Node.js) з використанням IntelIJ Idea.
Інтерфейс системи дозволяє легко здійснювати створення, редагування,
зберігання та видалення експертиз й експертних оцінок, а також текстове і
графічне відображення результатів експертного оцінювання. Інтерфейс для
введення думки експертів у модулі дозволяє вносити оцінки як у табличному
вигляді, так і ранжируваному вигляді «input-range». Експерт-модератор
запрошує інших експертів через інтерфейс запрошення, який підключений до
поштового модуля серверної частини проекту, що надсилає лист-запрошення
через поштовий сервіс «Gmail». У модулі використовується система ролей,
яка розділяє права доступу до бази даних сервісу. Адміністратори системи
мають повний доступ до усіх колекцій бази даних, у той час як звичайні
експерти можуть отримати лише дані, що самі й створили. Розроблений
модуль надасть можливість користувачам здійснювати експертизу для
прийняття рішення в складних задачах бізнесу з використанням веб-
орієнтованих і хмарних технологій.

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