Управління проєктом розробки мобільного додатку моніторингу технічного стану легкових автомобілів

Лиходід, Микола Володимирович
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/6767
Повний запис метаданих
Поле DC	Значення	Мова
dc.contributor.advisor	Дяченко, Петро Васильович	-
dc.contributor.author	Лиходід, Микола Володимирович	-
dc.date.accessioned	2026-01-11T17:22:48Z	-
dc.date.available	2026-01-11T17:22:48Z	-
dc.date.issued	2022-12-26	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/6767	-
dc.description.abstract	Сьогодні важко уявити життя сучасної людини без смартфона. Смартфон є невід’ємним атрибутом працездатної людини, не тільки як засіб комунікації, а також як засіб, за допомогою якого можна підвищити продуктивність виконання певних простих задач. Так як і смартфони, невід’ємною частиною робочого процесу багатьох професій є наявність автомобіля. Мета дослідження полягає у розробці мобільного додатку для моніторингу та діагностики автомобіля з використанням технологій управління проєктами в галузі інформаційних технологій. Об’єктом дослідження є процеси управління проєктом розробки мобільного додатку для моніторингу та діагностики автомобіля. Предмет дослідження – проєкт розробки мобільного додатку мобільного додатку для моніторингу та діагностики автомобіля. Основні положення і результати кваліфікаційної роботи магістра доповідалися і були обговорені на студентській науково-практичній конференції ЧДТУ (Черкаси, 2022).	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	МОБІЛЬНИЙ ЗАСТОСУНОК	uk_UA
dc.subject	РОЗРОБКА ПРОЄКТУ	uk_UA
dc.subject	ПЛАНУВАННЯ ПРОЄКТУ	uk_UA
dc.subject	ДІАГНОСТИКА ЛЕГКОВОГО АВТОМОБІЛЯ.	uk_UA
dc.title	Управління проєктом розробки мобільного додатку моніторингу технічного стану легкових автомобілів	uk_UA
dc.type	Master Thesis	uk_UA
Розташовується у зібраннях:	122 Комп’ютерні науки (Управління стартапами і проектами в галузі інформаційних технологій)
Файли цього матеріалу:
Файл	Опис	Розмір	Формат
Пояснювальна записка_Лиходід Микола_МСТП-2102_2022-2023.pdf Restricted Access		1.82 MB	Adobe PDF	Переглянути/Відкрити Запит копії
Показати базовий опис матеріалу Перегляд статистики
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра комп’ютерних наук та системного аналізу 
 
 
 
 
 
Пояснювальна записка 
до кваліфікаційної роботи 
                                          магістра       
 (освітній рівень) 
 
на тему: «Управління проєктом розробки мобільного додатку моніторингу 
технічного стану легкових автомобілів» 
 
 
 
Виконав: студент 2 курсу, групи МСТП-2102  
 
 спеціальності 122 – «Комп’ютерні науки» 
                                                             (шифр і назва спеціальності) 
освітня програма «Управління стартапами  
(назва освітньої програми) 
і проєктами в галузі інформаційних технологій» 
 
      Лиходід Микола Володимирович 
 
Керівник                              Дяченко П.В 
                                              (прізвище та ініціали) 
 
Рецензент                            . 
                                              (прізвище та ініціали) 
 
 
 
 
 
Черкаси 2022 року 
 
2 
  
Бланк завдання на кваліфікаційну роботу магістра студенту 
 
Черкаський державний технологічний університет 
Факультет Інформаційних технологій і систем 
Кафедра Комп’ютерних наук та системного аналізу 
Освітній рівень Магістр 
Спеціальність 122 – комп’ютерні науки  
 
 
ЗАТВЕРДЖУЮ 
Завідувач кафедри КН та СА  
_______________ Триус Ю.В. 
«____» _____________ 20__ р. 
 
 
ЗАВДАННЯ 
на кваліфікаційну роботу бакалавра студенту 
Лиходіду Миколі Володимировичу 
(прізвище, ім‘я, по батькові) 
1. Тема роботи «Управління проєктом розробки мобільного додатку моніторингу технічного 
стану легкових автомобілів» 
 
Керівник роботи Дяченко Петро Васильович, ктн, доцент  
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання) 
 
затверджені наказом університету від «14» жовтня 2022 р. № 275/04. 
 
2. Строк подання студентом роботи  «8» грудня 2022 року  
3. Вихідні дані до роботи:  
Звіт з переддипломної практики 
Звіт з наукової практики 
 
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити): 
Вступ 
4.1. Аналіз передумов створення ІТ-проєкту 
4.2. Розробка концепції проєкту 
4.3. Планування та управління проєкту 
3 
  
4.4 Моделювання виконання проєкту 
Висновки.  
5. Перелік додатків (з точним зазначенням назв додатків): 
 
5.1. Додаток А. Специфікація 
 
5.3. Додаток Б. Текст програм повний перелік робіт з діаграмою Ганта та повна мережева схема 
1в .M ІнSс тPрrуoкjeцcіtя  користувача 
 
 6. Консультанти розділів роботи 
Прізвище, ініціали та Підпис, дата 
Розділ посада 
консультанта завдання видав завдання прийняв 
    
    
7. Дата видачі завдання 14.10.2022 р. 
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання 
№ з/п Назва етапів кваліфікаційної роботи магістра Примітка 
етапів роботи 
1 Видача завдання на кваліфікаційну роботу до 14.10.2022 Виконано 
магістра. 
2 Аналіз літературних джерел, об’єкту та до 29.10.2022 Виконано 
предмету дослідження. 
3 Написання теоретичного розділу до 07.11.2022 Виконано 
кваліфікаційної роботи магістра. 
4 Написання аналітичного розділу (аналіз об’єкту до 15.11.2022 Виконано 
й предмету дослідження). 
5 Написання практичних розділів й висновків по до 29.11.2022 Виконано 
роботі. 
6 Передзахист кваліфікаційної магістра на до 08.12.2022 Виконано 
засіданні випускової кафедри. 
7 Подання роботи завідувачу кафедри. до 08.12.2022 Виконано 
8 Захист кваліфікаційної роботи магістра. 26.12.2022 Виконано 
 
Студент                                   _____________________________    Лиходід М.В. 
(підпис)                                                                
Керівник роботи                     ____________________________      Дяченко П.В. 
                                           (підпис)                                                                   
4 
  
РЕФЕРАТ 
Кваліфікаційна робота магістра містить: 73 с., 38 рис., 11 табл., 5 
використаних джерел, 2 додатки.   
Актуальність теми. Сьогодні важко уявити життя сучасної людини без  
смартфона. Смартфон є невід’ємним атрибутом працездатної людини, не тільки як 
засіб комунікації, а також як засіб, за допомогою якого можна підвищити 
продуктивність виконання певних простих задач.    
 Так як і смартфони, невід’ємною частиною робочого процесу багатьох 
професій є наявність автомобіля.  
Мета та задачі дослідження. Мета дослідження полягає у розробці 
мобільного додатку для моніторингу та діагностики автомобіля з використанням 
технологій управління проєктами в галузі інформаційних технологій.  
Задачі, що вирішуються в роботі: 
– проведення дослідження ринку мобільних застосунків у анспортній сфері; 
– дослідження особливостей методологій управління проєктами в ІТ галузі; 
– розробка компонентів управління проєктом розробки мобільного додатку 
для діагностики і моніторингу систем легкового автомобіля; 
– виявлення та оцінка можливостей подальшого удосконалення мобільного 
додатку з метою розширення його функціональності. 
Об’єктом дослідження є процеси управління проєктом розробки мобільного 
додатку для моніторингу та діагностики автомобіля. 
Предмет дослідження – проєкт розробки мобільного додатку мобільного 
додатку для моніторингу та діагностики автомобіля. 
У процесі дослідження використовувалися наступні методи: 
– експертне оцінювання альтернатив; 
– методи прийняття рішень в умовах невизначеності; 
– календарне планування; 
– метод критичного шляху. 
5 
  
Користувачі зможуть швидко та легко відслідковувати динамічні 
характеристики автомобіля та мати вчасний моніторинг системи. 
Апробація результатів роботи. Основні положення і результати 
кваліфікаційної роботи магістра доповідалися і були обговорені на студентській 
науково-практичній конференції ЧДТУ (Черкаси, 2022).  
Перелік ключових слів: МОБІЛЬНИЙ ЗАСТОСУНОК, РОЗРОБКА 
ПРОЄКТУ, ПЛАНУВАННЯ ПРОЄКТУ, ДІАГНОСТИКА ЛЕГКОВОГО 
АВТОМОБІЛЯ. 
6 
  
ABSTRACT 
The master's thesis contains: 73 pages, 38 figures, 11 tables, 5 used sources, 2 
appendices. 
Actuality of theme. Today it is difficult to imagine the life of a modern person 
without a smartphone. A smartphone is an indispensable attribute of an able-bodied 
person, not only as a means of communication, but also as a means with which you can 
improve the performance of certain simple tasks. 
 Like smartphones, having a car is an integral part of the workflow of many 
professions. 
The purpose and objectives of the research. The purpose of the research is to 
develop a mobile application for vehicle monitoring and diagnostics using project 
management technologies in the field of information technology. 
Tasks solved in the work: 
– conducting a market research of mobile applications in the field of sports; 
– research on the peculiarities of project management methodologies in the IT 
industry; 
– development of project management components for the development of a mobile 
application for creating personal training programs; 
- identification and assessment of opportunities for further improvement of the 
mobile application in order to expand its functionality. 
The object of the study is the project management processes for the development 
of a mobile application for car monitoring and diagnostics. 
The subject of the research is the project of developing a mobile application for 
monitoring and diagnosing a car. 
The following methods were used in the research process: 
– expert evaluation of alternatives; 
– methods of decision-making in conditions of uncertainty; 
- calendar planning; 
- the critical path method. 
7 
  
Users will be able to quickly and easily monitor the dynamic characteristics of the 
car and have timely monitoring of the system. 
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 ChDTU (Cherkasy, 2022). 
List of keywords: MOBILE APPLICATION, PROJECT DEVELOPMENT, 
PROJECT PLANNING, CAR DIAGNOSTICS. 
8 
  
 ЗМІСТ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
 ............................................................................................................................................. 10 
ВСТУП ..................................................................................................................... 11 
1 АНАЛІЗ ПЕРЕДУМОВ СТВОРЕННЯ ІТ-ПРОЄКТУ ...................................... 13 
1.1 Постановка та обґрунтування проблеми ............................................... 13 
1.2 Опис задуму створеного проєкту ........................................................... 13 
1.3 Аналіз аналогів проєкту, що реалізується у роботі .............................. 14 
1.4 Аналіз альтернативних ідей та вибір найбільш привабливої 
альтернативи для реалізації проєкту ........................................................................... 14 
Висновки до розділу 1 ........................................................................................ 15 
2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ .............................................................. 17 
2.1 Аналіз первинних та вторинних зацікавлених сторін .......................... 17 
2.2 Концепція проєкту ................................................................................... 19 
2.3 Учасники проєкту .................................................................................... 20 
2.4 Життєвий цикл проєкту, перелік ключових фаз проєкту .................... 21 
Висновки до розділу 2 ........................................................................................ 24 
3 ПЛАНУВАННЯ ТА УПРАВЛІІННЯ ПРОЄКТУ .......................................... 26 
3.1 Планування змісту проєкту ..................................................................... 26 
3.2 Планування часу проєкту ........................................................................ 32 
3.3 Планування трудових ресурсів проєкту ................................................ 38 
3.4 Планування якості проєкту ..................................................................... 45 
3.5 Планування ризиків проєкту ................................................................... 46 
3.6 Планування бюджету проєкту ................................................................ 47 
3.7 Управління комунікаціями в проєкті ..................................................... 55 
9 
  
Висновки до розділу 3 ........................................................................................ 57 
4 ДЕТАЛЬНА РОЗРОБКА ПРОЄКТУ ............................................................... 57 
4.1 Механізм контролю робіт проєкту .............................................................. 57 
4.2 Опис засобів програмної реалізації додатку .............................................. 59 
4.3 Макет додатку................................................................................................ 64 
4.4 Опис функцій та можливостей додатку ...................................................... 65 
Висновки до розділу 4 ........................................................................................ 66 
ВИСНОВКИ ............................................................................................................. 68 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................... 69 
 
10 
  
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ 
СППР – система підтримки прийняття рішень; 
СКМ – система комп’ютерної математики; 
ІСР – ієрархічна структура робіт 
11 
  
ВСТУП 
Актуальність теми.   В умовах швидкого темпу життя важко уявити собі наш 
світ без використання транспортних засобів. Автомобілі стали не показником рівня 
заможності, а звичайним атрибутом майже кожної сім’ї чи окремої людини. Вони 
доступні для більшості, їх навіть просто дають працівникам для виконання роботи, 
або для того, що б швидко дістатись робочого місця. Складна структура автомобіля 
обумовлює необхідність мати певні знання про процеси його функціонування, але 
це далеко не для кожного, тому постає питання полегшити розуміння можливих 
несправностей у автомобіля. Саме через це є актуальність у розробці додатку для 
спрощення процесів аналізу функціонування систем автомобіля з їх детальним 
описом, для того, щоб кожна людина мала чітке уявлення про технічгий стан свого 
транспортного засобу. 
Мета та задачі дослідження. Мета дослідження полягає у поліпшенні 
процесу діагностики і моніторингу систем легкового автомобіля на основі розробки 
відповідного мобільного додатку з використанням технологій управління проектами 
в галузі інформаційних технологій. 
Задачі, що вирішуються в роботі: 
– проведення дослідження ринку мобільних застосунків у транспортній 
сфері; 
– дослідження особливостей методологій управління проєктами в ІТ 
галузі; 
– розробка компонентів управління проєктом розробки мобільного 
додатку для діагностики і моніторингу систем автомобіля; 
– виявлення та оцінка можливостей подальшого удосконалення 
мобільного додатку з метою розширення його функціональності. 
Об’єктом дослідження є процеси управління проєктом розробки мобільного 
додатку для діагностики і моніторингу систем автомобіля. 
Предмет дослідження – проєкт розробки мобільного додатку для діагностики 
і моніторингу систем автомобіля. 
12 
  
У процесі дослідження використовувалися наступні методи: 
– методи прийняття рішень в умовах невизначеності; 
– календарне планування; 
– метод критичного шляху. 
Власники додатку зможуть без перешкод користуватись усіма можливостями 
за стосунку, як для перегляду характеристик автомобіля, так і інформування про всі 
можливі проблеми з авто. 
Апробація результатів роботи. Основні положення і результати 
кваліфікаційної роботи магістра доповідалися і були обговорені на студентській 
науково-практичній конференції ЧДТУ (Черкаси, 2022).  
Перелік ключових слів: МОБІЛЬНИЙ ЗАСТОСУНОК, РОЗРОБКА 
ПРОЄКТУ, ПЛАНУВАННЯ ПРОЄКТУ, ДІАГНОСТИКА АВТОМОБІЛЯ. 
 
 
 
 
 
 
 
 
 
 
 
 
 
13 
  
1 АНАЛІЗ ПЕРЕДУМОВ СТВОРЕННЯ ІТ-ПРОЄКТУ  
1.1 Постановка та обґрунтування проблеми 
Активний ритм життя призводить до того що люди стають залежними від 
багатьох технічних засобів сьогодення. Зараз вже важко уявити рутинні справи без 
транспортних засобів. А, отже, і питання зручного та швидкого діагностування 
автомобіля набуває великого значення. Найбільш простим і зручним способом 
мобільного діагностування автомобільних транспортних засобів є сканери з 
використанням інтерфейсу OBDII. Такі сканери бувають як з провідним 
інтерфейсом (USB) так і з безпровідним (Bluetooth, WiFi).  
Автомобілі з OBDII інтерфейсом почали виготовляти починаючи з 1996 року. 
OBD-II - дозволяє отримувати повний контроль над двигуном автомобіля. Дозволяє 
здійснювати діагностування частин кузова і додаткових пристроїв, а також 
проводити моніторинг мережі управління транспортним засобом. В даному 
інтерфейсі виробники використовують такі протоколи для з'єднання з транспортним 
засобом:  
 
– ISO 9141-2; 
– ISO 14230 Keyword Protocol 2000; 
– SAE J1850 VPW; o SAE J1850 PWM; 
– ISO 15765-4 CAN (Controller Area Network).  
 
На даний момент цей інтерфейс є обов’язковим для всіх виробників США та 
Євросоюзу. На даний момент вже існує багато методів діагностування автомобілів 
за допомогою інтерфейсу OBDII. Більшість з них вміють робити діагностування 
автомобіля, зчитувати та скидати помилки і навіть робити логування показників 
системи. Проте, всі вони потребують глибоких знань структури автомобіля, що 
спричиняє складнощі а іноді і неможливість користуватися такими додатками 
людям без досвіду технічного обслуговування автомобільних транспортних засобів.  
14 
  
1.2 Опис задуму створеного проєкту  
Ідеєю проєкту є розробка мобільного додатку для спрощеного моніторингу та 
діагностики структури автомобіля. У додатку будуть використовуватись 
інструменти для професійної діагностики та графіки характеристик. Додаток також 
матиме вихід на офіційні дилерські ринки запчастин, та їх аналоги інших компаній. 
Це дозволить середньостатистичному користувачеві автомобіля мати уявлення про 
вартість тої чи іншої запчастини, що в свою чергу зможе захистити від переплат та 
заощадить час на закупівлю потрібних елементів. 
1.3 Аналіз аналогів проєкту, що реалізується у роботі 
Велика  залежність багатьох професій від власне наявності автомобіля та його 
ефективній діагностиці створили попит на програми та додатки такого роду. Для 
аналізу і порівняння аналогів до проєкту, що розробляється, було обрано найбільш 
конкурентоздатні: 
– Додаток «Obd Mary – car scanner for ELM» від TechnoDrive. [4]; 
– Додаток «inCarDoc ELM327 OBD2» від inCarDoc. [5];  
– Додаток «EOBD Facile» від Outils OBD Facile. [6]. 
 
На мій погляд, найкращим серед цих додатків є «Obd Mary». У цього додатку 
проста та  функціональна подача інформації. Додаток постійно оновлюється та має 
доступ до більшості автомобілів на ринку. І найважливіше те, що додаток підтримує 
українську мову. 
 «inCarDoc» хоч і отримує меншу кількість інформації але має великий рівень 
захисту даних, що теж грає велику роль для власника автомобіля. 
  «EOBD Facile» має «Pro» версію, в якій дуже широко і точно подається 
інформація а також присутній більший функціонал. 
Підсумком цього пунку є порівняльний аналіз переваг та недоліків обраних 
проєктів, представлений у табл. 1.1. 
15 
  
Таблиця 1.1 – Порівняльний аналіз додатків-конкурентів 
Критерії «Obd «inCarDoc «EOBD» 
Mary» » 
Підтримка української мови + - - 
Безпека даних - + + 
Різноплановість систем діагностики + + + 
Багатофункціональність додатку + - - 
Дизайн та інтерфейс + - + 
Можливість користуватися без платної підписки + + + 
Простота використання + + - 
Результати 6 4 4 
Як видно з таблиці, за всіма критеріями, додаток «Obd Mary» від TechnoDrive. 
є найбільш конкурентним до створюваного в роботі додатку, у нього багато переваг, 
простота і функціональність. Отож саме на цей додаток слід звернути увагу, при 
подальшій роботі над проєктом. 
1.4 Аналіз альтернативних ідей та вибір найбільш привабливої 
альтернативи для реалізації проєкту 
Для більшого розуміння ринку та на випадок непередбачуваних ризиків, 
проаналізуємо альтернативні ідеї для реалізації проєкту та визначимо, яка з них буде 
кращою альтернативою основному проєкту. 
Найкращою можливою альтернативою можна обрати вихід додатку на 
інтернет магазини з запчастинами, які будуть рекомендовані в залежності від 
автомобіля потенційного користувача. 
 
Висновки до розділу 1 
У даному розділі описано проблему розв’язання якої можна вирішити шляхом 
створення додатку на основі сучасних інформаційних. Наведена актуальність 
16 
  
створення додатку, виділено унікальність, сформульована загальна ідея, а також 
його переваги та недоліки порівняно з існуючими аналогами. Виходячи з цього було 
визначено цілі та мету проекту.  
Також був проведений попередній аналіз його існуючих аналогів з метою 
з’ясування, які в подібних додатків можуть бути недоліки та як з ними боротися. 
Також було обрано альтернативну ідею для розробки, на випадок 
непередбачуваних обставин, для цього було проведено аналіз з використанням 
відповідних математичних критеріїв прийняття рішень в умовах невизначеності, та 
використано відповідні програмні засоби.  
Як підсумок даного аналізу - можна обрати оптимальну альтернативу – 
мобільний додаток «CarSys M», який буде розроблятися у межах кваліфікаційної 
роботи. Проведений аналіз даного розділу дав можливість з’ясувати, як ті чи інші 
зовнішні умови можуть впливати на подібні додатки. 
 
17 
  
2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ 
2.1 Аналіз первинних та вторинних зацікавлених сторін 
Для прoрахунку якості всіх складoвих проєкту слід прoвести аналіз його 
оточення, тобто зацікавлених сторін проєкту, які так, чи інакше впливають на 
проєкт. 
Зацікавлені сторони проєкту діляться на дві категорії: первинні та вторинні. 
Первинними зацікавленими сторонами є ініціатор, замовник, керівник проєкту 
та команда проєкту.  
До вторинних належать інвестор, споживачі (клієнти) та органи влади. 
Тепер детальніше пройдемося по кожному з них. 
Керівник проєкту 
Оскільки проєкт студентський, то керівник проєкту поєднує в собі декілька 
ролей. 
Роль: ініціатор, замовник. 
Вигода: Отримання прибутку, реалізація проєкту, отримання досвіду 
управлінням ІТ-проєктами та ІТ-стартапами. 
Форма підтримки проєкту: ведення проєкту, сприяння його успішному 
завершенню. 
Механізм участі: створення та ведення обігу документальної частини, 
управління командою проєкта, управління самим проєктом, прийняття рішень з 
реалізації проєкту. 
Команда проєкту 
Ролі: маркетолог, дизайнер, 2 програмісти, тестувальник, команда тренерів.. 
Вигода: Отримання прибутку, отримання досвіду роботи в команді, 
покращення своїх професійних навичок. 
Форма підтримки проєкту: чітке виконання вимог керівника проєкту. 
Механізм участі: розробка проєкту на всіх етапах його існування. 
 
18 
  
Інвестор 
Роль: інвестор. 
Вигода: отримання прибутку від проєкту, реклама власної продукції у 
створеному додатку. 
Форма підтримки проєкту: фінансування проєкту. 
Механізм участі: фінансування проєкту. 
Клієнти 
Роль: кінцеві споживачі готового продукту. 
Вигода: можливість користуватися зручним, корисним додатком для спорту і 
тренувань. 
Форма підтримки проєкту: придбання підписки, оцінка додатку в Play Store. 
Механізм участі: користування додатком та надання відгуків для покращення 
роботи додатку. 
Органи влади 
Роль: Державні структури. 
Вигода: отримання податків від проєкту. 
Форма підтримки проєкту: надання оподаткування. 
Механізм участі: стягнення податків. 
Як бачимо всі сторони мають вигоду від  реалізації проєкту, проте мають і 
позитивний вплив на проєкт.  
Для успішної реалізації проєкту розробимо стратегію взаємодії з кожною 
стороною проєкту, зосередивши увагу на важливих факторах, що здатні вплинути на 
проєкт. 
Стратегія взаємодії з керівником проєкту 
Продукт повинен відповідати всім стандартам та вимогам. Користувачі мають 
бути задоволені тими функціями, які пропонує додаток. Команда проєкту повинна 
мати чіткі і зрозумілі задачі. 
Стратегія взаємодії з командою проєкту 
Всі задачі проєкту повинні бути виконані чітко з графіком. Кінцевий результат 
задач повинен відповідати плану проєкту. 
19 
  
Стратегія взаємодії з інвестором 
Керівник проєкту повинен надати всі фінансові звіти та інформацію про хід 
реалізації проєкту. 
Стратегія взаємодії з клієнтами 
Клієнти повинні бути задоволені продуктом. Отримувати користь від 
користування додатком. 
Стратегія взаємодії з органами влади 
Оскільки на органи влади впливу немає, їх варто зазначити в план реагування 
на ризики, та при плануванні проєкту, застосувавши стратегію реагування та 
адаптації. 
Отже, результатом аналізу зацікавлених сторін є розуміння, що оточення 
проєкту в більшій мірі позитивно впливає на проєкт. Є деякі ризики, та їх можна 
уникнути розробивши стратегію реагування та адаптації. 
2.2 Концепція проєкту 
Концепція проекту – це попередній план впровадження бізнес-ідеї проекту, який 
надається Замовнику для оцінки перспективності цієї бізнес-пропозиції. Метою 
оцінки є відбір з декількох альтернативних ідей найбільш перспективних. 
Щоб розробити концепцію для мобільного додатку моніторингу технічного 
стану легкових автомобілів сформуємо опис проєкту. 
Причини ініціалізації проєкту 
 У зв’язку із збільшенням кількості водіїв та транспорту в цілому, постала 
необхідність у швидкому і якісному діагностуванні авто з подальшим ефективним 
ремонтом. Це зумовлює необхідність у створенні системи, що буде допомогати 
людям далеким від принципів роботи автомобіля мати можливість швидко і зручно 
проаналізувати його стан. 
Сутність запропонованої інноваційної ідеї та спосіб її використання 
Продуктом проєкту є мобільний додаток, розроблений для операційної 
системи Android. Додаток матиме безліч функцій та можливостей,  серед яких: 
20 
  
діагностика автомобіля конкретної заданої марки; показ графіку ефективності 
роботи кожної з систем всередині авто; вихід на інтернет магазини з необхідними 
запчастинами з відгуками. 
Мета проєкту 
Розробка мобільного додатку «CarSys M» з використанням проєктного 
підходу до управління. Доступно надати інформацію про стан автомобіля через 
зрозумілі графіки. Дати можливість на покупку якісних запчастин за найнижчими 
цінами по ринку. Зробити додаток простим та зручним для користування. 
Цілі проєкту 
Щоб краще зрозуміти проєкт визначимо його цілі та критерії досягнення цих 
цілей. 
Таблиця 2.1 – Цілі та критерії досягнення цілей 
№ Ціль Критерій 
1 Отримати прибуток 75 тисяч гривень через 6 
місяців після завершення 
проєкту 
2 Залучити клієнтів 2000 осіб через 3 місяці після 
завершення проєкту 
3 Отримати кількість завантажень додатку 5000 завантажень через 6 
місяців після завершення 
проєкту 
Продукт проєкту 
Прoдуктом проєкту повинен бути впроваджений та виведений на ринок 
додаток, що матиме такі можливості: 
– Діагностика автомобіля конкретної марки. 
– Вивід графіків з технічного стану автомобіля. 
– Система сповіщень про можливі несправності та їх рішення. 
– Інтернет магазин з необхідними деталями. 
– Збереження інформації про автомобіль та його характеристик 
Критерії успішності проєкту 
21 
  
Для розуміння успішності проєкту визначено такі критерії, за допомогою яких 
буде видно наскільки успішним є додаток: 
– Впізнаваність на ринку через рік після завершення проєкту; 
– Багато хороших відгуків та рекомендацій встановити додаток; 
– Половина користувачів додатку з платною підпискою. 
Обмеження проєкту 
Для зручного планування проєкт має такі обмеження: 
– Проєкт повинен тривати, не довше 10 місяців; 
– Проєкт повинен не перевищувати загальні втрати, більше ніж на 300 тисяч 
гривен. 
Допущення проєкту 
Вище вказані обмеження проєкту, але враховуючи ризики та непередбачувані 
обставини, закладемо в проєкт такі допущення: 
– По часу, додатково 3 місяці до 8, зазначених раніше; 
– По загальних втратах, додатково 30 тисяч гривень. 
Згідно з створеною концепцією, побудуємо дерево цілей проєкту. 
Розробка 
мобільного додатку 
«CarSys M» 
Отримати Отримати к-ть 
прибуток Залучити завантажень 
клієнтів 
 
Рисунок 2.1 – Дерево цілей проєкту 
2.3 Учасники проєкту 
У розділі 2.1 проведено аналіз всього оточення проєкту, тепер більш детально 
зупинимося на людях, які сильно впливають на проєкт. Для початку створимо схему 
з всіма учасниками проєкту (рис. 2.2). 
22 
  
Замовник проєкту 
Лиходід Микола 
Ініціатор проєкту  
Лиходід Микола Власник проєкту 
 Лиходід Микола 
 
Споживачі кінцевої Менеджер проєкта 
продукції Лихо дід Микола 
Автомеханіки; Інвесто
Инвестори 
користувачі-власники  ри: 
Ком
авто  Команда проєкта ITпа-нії 
Виробники 
 4 програміста, компанія Epam, 
укразїнапчастин 
маркетолог,  дизайнер, ський 
тестувальник. фонд під тримки 
стартапів 
Інші зацікавлені сторони  Конкуренти 
Мережі автозапчастин мобільний додаток «Obd Mary»; 
 мобільний додаток «inCarDoc»; 
мобільний додаток «EOBD». 
 
Постачальники/Підрядники 
Відсутні 
Ліцензіари Органи влади 
Відсутні Податкова служба 
  
 
Рисунок 2.2 – Схема учасників проєкта 
Для успішної реалізації проєкту потрібно знати цілі кожного учасника, хоч у 
кожного  з учасників можуть бути свої цілі, проте одна ціль повинна бути спільною 
– успішно завершити проєкт. В табл. 2.2 представлені цілі кожного учасника. 
Таблиця 2.2 – Цілі учасників проєкту 
№ Учасник Ціль 
1 Ініціатор/Замовник/Власник Реалізувати проєкт, oтримати прибуток 
проєкту 
2 Менеджер проєкту Успіх проєкту, отримати досвід в управлінні 
проєктами 
3 Команда проєкту Oтримання прибутку, отримання досвіду командної 
роботи 
4 Інвестор Oтримати прибуток, більший ніж рівень вкладу 
5 Клієнт Отримати зручний та корисний додаток  
Як зазначалося раніше, кожен учасник має свої інтереси та цілі у проєкті, 
проте як бачимо з табл. 2.3, для досягнення їх цілей проєкт повинен бути успішно 
23 
  
завершений. Тож команда пoвинна успішно завершити проєкт та домогтися своїх 
цілей.  
2.4 Життєвий цикл проєкту, перелік ключових фаз проєкту 
Проміжок часу між моментом появи проєкту та моментом його ліквідації 
називають проєктним циклом, або життєвим циклом проєкту. Життєвий цикл 
проєкту є вихідним поняттям для дослідження проблем фінансування за проєктом та 
прийняття відповідних рішень. Кожен проєкт незалежно від його складності та 
обсягу робіт, необхідних для його виконання, проходить у своєму розвитку певні 
стадії: від стадії, коли «проєкту ще нема», до стадії, коли «проєкту вже нема». 
Спеціалісти з проєктного аналізу розглядають цикл проєкту  як базовий 
елемент концепції проєктного аналізу. 
У практиці проєктного аналізу використовуються різні підходи до розподілу 
реалізації проєкту на фази: 
– підхід, що пропонує розглядати три фази проєкту — концептуальну, 
контрактну і фазу реалізації проєкту. З огляду на запропоноване розрізнення 
концептуальна фаза має такі стадії: розробка концепції проєкту, оцінка 
життєздатності проєкту, планування проєкту, розробка вимог до проєкту, 
вибір і придбання земельної ділянки. Контрактна фаза включає вироблення 
кваліфікаційних вимог, підготовку попереднього завдання на проектування, 
заяву про наміри, добір потенційних виконавців, оформлення контракту з 
обраними виконавцями, вибір і затвердження остаточного варіанта проєкту, 
початок реалізації проєкту. Фаза реалізації проєкту має дві стадії — детальне 
проєктування та поставки; будівництво або інсталяція. 
– підхід, що ґрунтується на основній діяльності – аналізі проблеми, розробці 
концепції та детальному поданні проєкту, використанні результатів його 
реалізації, ліквідації об'єктів проєкту; 
24 
  
– програмою промислового розвитку ООН (UNIDO) запропоноване своє 
бачення проєкту як циклу, що складається з трьох окремих фаз – 
передінвестиційної, інвестиційної та експлуатаційної. 
Для даного проєкту найкраще підійде перший підхід, який розбитий на такі 
фази: 
– ініціювання; 
– планування; 
– реалізація; 
– завершення. 
Кожна фаза містить свої етапи 
Фаза ініціації складається з таких етапів: 
– обґрунтування проблеми 
– аналіз ринку; 
– розробка концепції проєкту; 
– оцінка життєздатності проєкту; 
– розробка вимог до проєкту; 
– підготовка попереднього завдання на проектування; 
– добір потенційних виконавців; 
– оформлення контракту з обраними виконавцями. 
 
Фаза планування складається з наступних етапів: 
– планування змісту та структури проєкту; 
– планування трудових ресурсів  та бюджету; 
– планування часу та ризиків; 
– планування комунікацій та закупівель. 
Фаза реалізації складається з наступних етапів: 
– реєстрація ФОП; 
– розробка концепту та ТЗ; 
– вибір технології та проектування архітектури додатку; 
– створення структури додатку; 
25 
  
– розробка дизайну та створення прототипу; 
– створення бази даних; 
– тестування; 
– реалізація додатку, створення рекламних сторінок та запуск реклами. 
Фаза завершення складається з наступних етапів: 
– розміщення додатку в Google Play Store; 
– розпуск команди та архівація проєкту; 
– аналіз проєкту та його закриття. 
Після визначення необхідних етапів та робіт кожної фази було визначено 
орієнтовну тривалість проєкту за фазами (табл. 2.3). 
Таблиця 2.3 – Тривалість проєкту за фазами 
№ Название 
Критерії перехода на іншу Оцінка Оцінка 
фази 
фазу тривалості(дні) вартості 
1 Прийняття рішення 30 36 800 грн. 
Ініціалізація замовником щодо реалізації 
проекту 
2 Затвердження плану 65 37 200 грн. 
Планування 
замовником 
3 Готовність продукту проекту 158 175 000 грн. 
Реалізація до установки кінцевим 
споживачем 
4 Розпoрадження щодо 20 30 800 грн. 
Завершення 
завершення проекту 
Всього на проекті 245 днів 280 000 грн 
На оснoві тривалості фаз та етапів проєкту будуємо мережеву схему, завдяки 
якій розуміємо, які роботи можуть виконуватися паралельно, а які лише послідовно. 
На стадії завершальної оцінки визначається ступінь досягнення цілей проєкту, 
із набутого досвіду робляться висновки для його використання в подальших 
проєктах. У перебігу цієї стадії треба порівняти фактичні результати проєкту із 
запланованими. Проєкти, особливо успішні, мають довге життя. В певному 
розумінні проєкти ніколи не завершуються, а дають позитивні результати протягом 
невизначеного строку. Втім, після фази завершення корисно оцінити уроки проєкту і 
переглянути можливий вклад проєкту в зміни життя людей. Ця оцінка, що 
провадиться після фази завершення проєкту, являє собою своєрідний урок для тих, 
26 
  
хто планує подальші проєкти, оскільки слугує дисциплінуючим заходом щодо тих, 
хто планував підданий оцінці завершений прoєкт. 
Висновки до розділу 2 
У даному розділі був проведений аналіз оточення проєкту, завдяки якому 
стало зрозуміло, як ті чи інші учасники можуть і впливають на проєкт, а також 
розроблена стратегія взаємодії з кожним з цих учасників. 
Розроблена концепція проєкту, в яку вкладено багато важливих етапів, без 
розуміння яких неможливе подальше продовження проєкту, зокрема: мета, цілі 
проєкту, його обмеження та допущення.  
Наступним кроком став агаліз учасників проєкту, визначення їх особистих 
цілей. Була сформована схема учасників проєкту, яка наочно демонструє всіх 
учасників, що якимось чином залучені у проєкт. 
Також в даному розділі здійснено опис життєвого циклу проекту, розглянуті 
різні методи для поділу проєкту на фази та обрано кращий підхід для даного 
проєкту. Після цього кожна фаза була розписана по етапах, що дало змогу 
сформувати попередню тривалість проєкту та його вартість.  
 
 
 
 
 
 
 
 
 
27 
  
3 ПЛАНУВАННЯ ТА УПРАВЛІІННЯ ПРОЄКТУ 
3.1 Планування змісту проєкту 
При реалізації проектів передбачається застосування знань і процесів 
управління проєктами у різних галузях. Управління змістом проєкту є однією з 
таких галузей. Неможливо управляти проєктом без його змісту. 
Отже, під управлінням змістом проєкту розуміють виконання процесів, які 
потрібні для того, аби проєкт містив в собі саме ті роботи, що необхідні для 
успішного його завершення. 
Структура декомпозиції робіт (СДР/WBS) – це спосіб описати мету та 
завдання проєкту шляхом його декомпозиції в термінах ієрархічно взаємозв'язаних 
результатів пакетів робіт, виконання яких необхідно для реалізації проєкту . 
Декомпозиція передбачає поділ основних робіт у проєкті на дрібніші, із 
більшим ступенем керованості. Даний поділ відбувається доти, допоки роботи не 
будуть визначені достатньо детально для підтримки майбутніх робіт проєкту. 
Перш ніж створювати СДР необхідно сформувати структуру продукту та 
основні вимоги до нього. 
Кінцевим продуктом проєкту є додаток для створення персональних програм 
тренувань з урахуванням індивідуальних особливостей користувача. 
На табл. 3.1 представлені високорівневі вимоги до кінцевого результату 
проєкту. 
Таблиця 3.1 – Високорівневі вимоги до кінцевого результату проєкту 
№ Назва вимоги 
1 Система простого первинного моніторингу систем автомобіля 
2 Зберігання даних роботи автомобіля 
3 Можливість віддаленої діагностики, або діагностики на ходу 
4 Доступ до баз даних інтернет магазинів з відповідними запчастинами 
5 Система різнорівневої авторизації 
28 
  
Під час побудoви WBS виконується послідoвна декомпозиція проєкту на 
підпроєкти, пакети робіт різного рівня, пакети детальних робіт. Перелік завдань 
проєкту по суті є ієрархічною структурою робіт. 
Для того щоб створити WBS потрібно оцінити вартість роботи та створити її 
розклад. Кожен елемент WBS повинен забезпечувати помітний результат та має 
бути агрегатом усіх підпорядкованих елементів, що перераховані безпосередньо під 
ним. Декомпозиція кожного з результатів починаючи з першого рівня до останнього 
повинна бути пов’язана логічно. Результативність пакетів робіт повинна бути 
унікальною та бути відмінним результатом пакетів робіт того ж самого рівня. Сам 
процес розробки WBS повинен являти собою гнучкий механізм, який дозволяє 
коригувати систему.  
WBS розробляється за допомогою ітераційного розглядання цілей та 
результатів проєкту, досягнення функціональності, критеріїв планування і, об’єму 
робіт, реалізації технічних вимог. Верхні рівні WBS мають змогу розробляти на 
ранній, концептуальній стадії проєкту. Подальша деталізація WBS можлива після 
визначення проєкту та підготовчих особливостей. 
Структура декомпозиції робіт (WBS) може розроблятися з самого початку або 
на основі раніше створених WBS реалізованих проектів подібного типу. При 
розробці схеми декомпозиції можна використовувати поділ «за продуктами» (рис. 
3.1) або поділ «за процесами» (рис. 3.2). 
29 
  
Розробка додатку для 
моніторингу та 
діагностики легкового 
Програмний автомобіля Проєктна 
комплекс  документація 
Просування 
Розробка продукту Статут проєкта OBS проєкта 
додатку 
Календарний план WBS проєкта 
Розробка 
Тестування компанії по План 
додатку просуванню План закупівель 
моніторингу 
продукту 
Початок компанії План управління 
Проведення 
по просуванню ризиками 
корегуючих дій 
продукту 
 
Рисунок 3.1 – Схема декомпозиції (поділ «тільки за продуктами») 
30 
  
Управління Ініціація Розробка додатку для Просування 
проєктом моніторингу та продукту 
Формальний 
діагностики легкового 
Управління початок Розробка 
автомобіля 
людськими проєкту компанії по 
ресурсами Розробка просуванню 
Призначення 
Тестування продукту 
Управління менеджера Створення 
системи 
змістом проєкту концептуальної Початок 
схеми продукту компанії по 
Управління Формування Запуск 
просуванню 
строками стратегії Розробка продукту у 
продукту 
проєкту дизайну тестову 
Управління 
додатку єкспулатацію 
ризиками Розробка 
Розробка Технічне 
Управління статуту 
основного обслуговування 
якістю проєкту 
функціоналу 
Usability-
Управління продукту 
тестування 
вартістю 
Аналіз 
Контроль та 
отриманих 
монітринг 
результатів 
проєкту 
тестування 
Управління 
Корегування 
комунікація
виявлених 
ми 
недоліків та 
Закриття помилок 
Проведення 
контрольного 
тестування 
 
Рисунок 3.2 – Схема декомпозиції (поділ  «тільки за процесами») 
Під час створення WBS проєкту першим кроком стало визначення кінцевого 
результату проєкту – створений та впроваджений мобільний додаток. 
Другим кроком стало визначення основних пакетів робіт та підпорядкованих 
їм завдань, що необхідні для отримання кінцевих результатів (продуктів) проєкту. 
Кінцеву та детальну структуру робіт наведено на табл. 3.2. 
 
 
31 
  
Таблиця 3.2 – Структура декомпозиції робіт проєкта 
Тривалість Оцінка 
СДР Назва задачі Ресурси 
(дні) вартості 
1 Название задачи Длительность Затраты 
 
Створення додатку 278 976,00 
1.1 245 дней 
"CarSys M"  грн. 
74 000,00 
1.1.1    Ініціалізація 90 дней Проектний менеджер[50%] 
грн. 
      Формування 16 000,00 
1.1.2 20 дней Проектний менеджер[50%] 
команди грн. 
1.1.3       Формалізація ідеї 10 дней Маркетолог 8 000,00 грн. 
1.1.4       Аналіз ринку 4 дней Проектний менеджер 4 800,00 грн. 
      Розробка бізнес-
1.1.5 5 дней 8 000,00 грн. 
плану  
37 200,00 
1.2       Планування 65 дней 
 грн. 
1.2.1          Планування якості 11 дней Проектний менеджер[34%] 6 000,00 грн. 
         Планування 
1.2.2 14 дней Проектний менеджер[33%] 8 000,00 грн. 
трудових ресурсів 
1.2.3          Планування змісту 10 дней Проектний менеджер[34%] 4 500,00 грн. 
         Планування 
1.2.4 7 дней Проектний менеджер[33%] 4 500,00 грн. 
бюджету 
1.2.5          Планування часу 7 дней Проектний менеджер[33%] 4 000,00 грн. 
         Планування 
1.2.6 7 дней Проектний менеджер[33%] 4 000,00 грн. 
ризиків 
         Планування 
1.2.7 7 дней Проектний менеджер[33%] 2 000,00 грн. 
комунікацій 
         Планування 
1.2.8 3 дней Проектний менеджер[33%] 4 200,00 грн. 
закупівель 
         Всі плани проекту 
1.2.9 затверджені 0 дней 0,00 грн. 
 
Замовником 
174 176,00 
1.3    Реалізація 150 дней 
 грн. 
1.3.1       Розробка концепу 7 дней Проектний менеджер[33%] 3 808,00 грн. 
32 
  
1.3.2       Реєстрація ФОП 12 дней Проектний менеджер[34%] 6 336,00 грн. 
Програміст;Проектний 13 152,00 
1.3.3       Розробка ТЗ 14 дней 
менеджер[33%] грн. 
1.3.4       Вибір технології 2 дней Програміст 2 880,00 грн. 
      Проектування 10 080,00 
1.3.5 7 дней Програміст 
архітектури додатку грн. 
      Створення 17 280,00 
1.3.6 12 дней Програміст 
структури додатку грн. 
1.3.7       Розробка дизайну 7 дней Дизайнер 8 400,00 грн. 
      Створення 36 960,00 
1.3.8 14 дней Дизайнер;Програміст 
прототипу грн. 
      Внесення інформації Команда механіків 21 280,00 
1.3.9 7 дней 
в базу данних програми ;Програміст грн. 
27 600,00 
1.3.10       Тестування 23 дней Тестувальник 
грн. 
14 400,00 
1.3.11       Реалізація додатку 10 дней Програміст 
грн. 
      Створення 
1.3.12 10 дней Маркетолог[50%] 6 000,00 грн. 
рекламних сторінок 
1.3.13       Запуск реклами 10 дней Маркетолог[50%] 6 000,00 грн. 
      Готовий мобільний 
1.3.14 0 дней 0,00 грн. 
додаток  
30 800,00 
1.4    Завершення 20 дней 
 грн. 
      Розміщення додатку 13 200,00 
1.4.1 5 дней Маркетолог;Програміст 
в магазинах грн. 
1.4.2       Розпуск команди 10 дней Проектний менеджер[50%] 8 000,00 грн. 
1.4.3       Архівація проекту 6 дней Проектний менеджер[50%] 4 800,00 грн. 
1.4.4       Аналіз проекту 3 дней Проектний менеджер 4 800,00 грн. 
1.4.5       Проект закритий 1 день 0,00 грн. 
 
 
Отже, ієрархічна структура рoбіт є основою планування проєкту та одним з 
найважливіших методів, що використовуються в управлінні проєктами. Правильно 
33 
  
створена ІСР є важливою для якісного планування проєкту та успішного управління 
проєктами. 
3.2 Планування часу проєкту 
Наступним важливим етапом є планування часу, або календарне планування. 
На цьому етапі складається та коригується  розклад робіт, що взаємопов’язані між 
собою. При календарному плануванні необхідно дотримуватися заданих в проєкті 
обмежень, таких як: тривалість робіт, ліміти ресурсів та оптимальний розподіл 
ресурсів. 
Основними цілями при плануванні календарного плану є: 
 Контроль робіт виконання проєкту; 
 Забезпечення своєчасного надходження фінансування; 
 Своєчасне забезпечення ресурсами, визначення ступеню завантаження 
ресурсів, корегування; 
 Забезпечення своєчасного виконання проєкту. 
Розробка календарного плану проєкту завжди ітеративна, тому, що в процесі 
виконання необхідно постійно повертатися до попередніх етапів для уточнення і 
наближення їх до реальності, чи поступово наближаючи попередні варіанти до 
найкращих досяжних значень. 
Даний календарний план проєкту є першим наближенням прогнозу до 
реалізації проєкту. Під час реалізації проєкту даний прогноз уточнюється з 
врахуванням як фактичного, так і планового виконання показників ефективності 
проєкту. У ідеальному варіанті фактичний стан проєкту повинен відповідати його 
прогнозу наприкінці проєкту. 
Саме при календарному плануванні найкраще проявляють себе комп’ютерні 
системи управління проєктами. 
Починаючи розробку календарного плану проєкту, потрібно визначити 
повний перелік робіт та пакетів робіт. Результати пакетів робіт мають бути 
унікальними і відрізнятися від результатів пакетів робіт того ж рівня. Їх необхідно 
34 
  
розбити до рівня деталізації , який забезпечить успішне планування, координацію, а 
також контроль робіт. 
Календарне планування даного проєкту виконувалося в системі управління 
проєктами Microsoft Project. 
Microsoft Project – одна з найбільш поширених систем управління проектами, 
що поєднує в собі простоту використання, дружній інтерфейс і необхідні 
інструменти для управління проєктами. 
Під час розробки календарного планування проєкту була використана 
розроблена СДР проєкту. 
Для початку потрібно внести повний перелік робіт та пакетів робіт проєкту 
(рис. 3.3). 
35 
  
 
Рисунок 3.3 – Вікно проєкту з введеним переліком робіт 
Далі потрібно визначити тривалість рoбіт. Поле часової діаграми містить лінії 
діаграми, які починаються та закінчуються одночасно. 
Наступним кроком визначаємо тривалість виконання підлеглих робіт. 
36 
  
Найпростіше зробити це за допомогою календаря, який відкривається в 
комірці стовпця Start напроти назви роботи. Перелік робіт після визначення їх 
тривалості матиме такий вигляд (рис. 3.4). 
 
Рисунок 3.4 – Вікно проєкту з визначеною тривалістю робіт 
Останнім кроком у планування робіт проєкту є встановлення зв'язків між 
роботами, оскільки лише з врахуванням послідовності виконання робіт система в 
змозі обрахувати  часовий графік проєкту і представити його на діаграмі. 
37 
  
Для зв'язування робіт використовують два основних інструменти: вказування 
попередника (роботу зв'язують роботою-попередником проставляючи у стовпці 
Predecessor номер строки роботи попередника, або встановлення такого зв'язку 
безпосередньо на часовій діаграмі з використанням піктограми зв'язування.  
При складанні  календарного плану даного проєкту використовувався кожен з 
цих інструментів. 
Існують такі типи зв’язків між роботами: старт до старту, фініш до фінішу, 
фініш до старту та старт до фінішу (Start to Start (SS), Finish to Finish (FF), Finish to 
Start (FS), Start to Finish (SF)). За замовчуванням роботи проекту зв'язуються між 
собою зв'язком фініш до старту, тобто, послідовно. 
При встановленні зв’язків між роботами потрібно враховувати часові межі 
роботи, які можуть бути таких типів: 
1. As Late As Possible (ALAP) - так пізно, як це можливо. 
2. As Soon As Possible (ASAP) - так швидко, як це можливо. 
3. Finish No Earlier Than (FNET) - фініш не раніше, ніж. 
4. Finish No Later Than (FNLT) - фініш не пізніше, ніж. 
5. Must Finish On (MFO) - фініш на визначену дату. 
6. Must Start On (MSO) - старт визначеної дати. 
7. Start No Earlier Than (SNET) - старт не раніше, ніж. 
8. Start No Later Than (SNLT) - старт не пізніше, ніж. 
Також важливо враховувати конкретні дати часових обмежень. Для кожного 
типу обмеження, суть і призначення яких стає ясним після уведення послідовності 
виконання робіт, логічним є уведення лише пари часових параметрів. Так, 
наприклад, для роботи з обмеженням типу MFO логічно визначати дату завершення 
і тривалість. Дата старту в цьому випадку обраховується в автоматичному режимі.  
На початку визначення зв'язків між роботами проекту було встановлено для 
всіх робіт обмеження типу ASAP, які відкоригували для окремих робіт згодом. 
Після виконання зв’язків робіт календарний план проекту набув наступного 
вигляду (рис. 3.5). 
38 
  
 
Рисунок 3.5 – Вікно проєкту з вказаними зв’язками між роботами 
Також важливою є мережева схема проєкту. В МS Project вона будується 
автоматично, на основі робіт та х зв’язків (рис. 3.6). 
 
 
 
Рисунок 3.6 – Мережева схема проєкту 
 
39 
  
3.3  Планування трудових ресурсів проєкту 
Наступним не менш важливим етапом є планування трудових ресурсів. 
Трудовими ресурсами даного проєкту є його учасники, тобто команда проєкту. 
Основними організаційними завданнями побудови команди проєкту є: здійснення 
грамотного керівництва; створення професійно-стимулюючого оточення; 
забезпечення підтримки керівництва і стабільно сприятливого навколишнього 
середовища; забезпечення кваліфікованим технічним персоналом. 
Учасники команди мають бачити себе частиною команди проекту та виробити 
спільні цінності та норми, тільки тоді вони будуть в змозі працювати, як команда. 
Команда проєкту сформована з спеціалістів, які володіють необхідними для 
виконання проєкту навичками. На рис. 3.7 зображена схема організаційної 
структури команди. 
Проєктний менеджер 
Головний програміст 
Маркетолог Команда Дизайнер 
Програміст механіків 
Тестувальник 
 
Рисунок 3.7 – Організаційна структура проєкту 
 
Команда проєкту складається з 7 осіб. Проєктний менеджер є керівником 
проєкту і йому підпорядковуються всі інші члени команди. 
На основі розробленої організаційної структури та СДР виконуємо розподіл 
відповідальності команди проєкту по основним проєктним роботам. Для цього 
створюємо так звану матрицю відповідальності (табл. 3.3). 
Таблиця 3.3 – Матриця відповідальності 
 ПМ М Д П Т КТ 
1.1.1 RP      
1.1.2 RP      
1.1.3  RP     
Задач
і 
40 
  
1.1.4 RP      
1.2.1 RP      
1.2.2 RP      
1.2.3 RP      
1.2.4 RP      
1.2.5 RP      
1.2.6 RP      
1.2.7 RP      
1.2.8 RP      
1.3.1 RP      
1.3.2 RP  P P   
1.3.3 RP   RP   
1.3.4    RP   
1.3.5    RP   
1.3.6    RP   
1.3.7   RP    
1.3.8   P RP   
1.3.9    P  RP 
1.3.10     RP  
1.3.11   P RP   
1.3.12  RP     
1.3.13  RP     
1.3.14       
1.4.1 RP P  И   
1.4.2 RP      
1.4.3 RP      
1.4.4 RP      
R – Відповідальний, P – Виконавець 
Продовжуючи планування проєкту необхідно вказати, які ресурси 
використовуються для виконання кожної роботи, тобто призначити ресурси до робіт 
проєкту. 
Під ресурсами у проєкті розуміють робочу силу, обладнання, мтеріали та 
гроші, що потрібні для виконання робіт, і є передумовами для реалізації будь-якого 
проєкту. 
Важливим питанням є складання та оцінка потреб у ресурсах, умов їх 
надходження та забезпечення та забезпечення їх повного та ефективного 
використання. 
Планування ресурсів починається з складання переліку людей і обладнання, 
необхідних для виконання проєктних робіт. 
Зробити це можна за двома способами: 
41 
  
 призначати ресурси для кожної роботи, таким чином формуючи їх перелік; 
 скласти перелік ресурсів, а потім за допомогою нього призначати ресурси 
до робіт. 
Всі ресурси даного проєкту відомі, тож легше використовувати другий спосіб. 
Скориставшись меню View | Resource Sheet, на екрані з'явиться таблиця 
ресурсів з усіма доступними характеристиками, а саме: 
– Resource Name - назва ресурсу; 
– Type - тип (працівник, матеріал); 
– Material Label - позначення матеріалу; 
– Initials - абревіатура працівника; 
– Group - група; 
– Max. Units - максимальна "задіяність"; 
– Std. Rate - звичайний тариф оплати (протягом робочого часу); 
– Ovt. Rate - тариф оплати за роботу в неробочий час; 
– Cost/Use - одноразові витрати; 
– Accrue At - форма оплати (аванс, погодинно, по факту); 
– Base Calendar - базовий календар ресурсу; 
– Code - код ресурсу. 
Якщо ресурс повністю використовується для виконання робіт у проєкті, у 
комірці Units потрібно поставити значення (100%), якщо ресурс використовується 
частково  необхідно вказати відсоток його використанняу цьому проєкті. 
На рис. 3.8 зображена заповнена таблиця ресурсів. 
 
Рисунок 3.8 – Заповнена таблиця ресурсів проєкту 
Призначення ресурсів до робіт проєкту 
Після того, як ресурси визначені, можна призначати їх до робіт. Для цього 
необхідно двічі клацнути лівою кнопкою миші, навівши курсор на комірку з назвою 
42 
  
роботи. Після чого з’явиться діалогове вікно Task Information. У ньому знаходимо 
вкладку Recource. 
У цьому вікні можна вибрати з переліку доступні ресурси та призначити їх на 
виконання цієї роботи (рис. 3.9). 
 
Рисунок 3.9 – Перелік доступних ресурсів проєкту для призначення 
Альтернативно можна призначити ресурс до роботи натиснувши лівою 
кнопкою миші на комірку поруч з датою закінчення роботи в стовбці Resource 
Names (рис. 3.10). 
 
Рисунок 3.10 – Присвоєння ресурсу до роботи 
43 
  
Після присвоєння всіх ресурсів до необхідних робіт можна побачити, що їх 
назви відображаються на діаграмі Ганта, поруч з лініями робіт (рис. 3.11). 
 
Рисунок 3.11 – Відображення призначених роботам ресурсів на часовій 
діаграмі 
Виявлення та вирішення конфліктів ресурсів 
Після того, як ресурси призначені до робіт можуть з’явитися 
перенавантаження тих чи інших ресурсів. 
Наявність перенавантажень можна перевірити в листі ресурсів (Resource 
Sheet), перенавантажені ресурси будуть позначені червоним (рис. 3.12). 
 
Рисунок 3.12 – Маркування перевантажених ресурсів 
Далі необхідно використати меню View, Resource Graph. У вікні, що 
відкриється, зображено графік перенавантаження ресурсів. На рис. 3.13 зображено 
графік перенавантаження проєктного менеджера. 
44 
  
 
Рисунок 3.13 – Графік перевантажень ресурсу «Проєктний менеджер» 
 
У даному проєкті виявився перенавантажений ресурс, а саме: проєктний 
менеджер (рис. 3.12). Це означає, що на виконання роботи на яку призначений 
ресурс, йому знадобиться більше часу ніж він має. 
Ця проблема може виникнути за кількох причин: 
– самою розповсюдженою причиною є призначення ресурсу до паралельних 
завдань, тобто тих, що виконуються одночасно; 
–  іншою причиною може бути збільшення обсягу робіт завдання, через яке 
відбувається перевищення допустимого часу виконання та як наслідок, 
перенавантаження ресурсу. 
Якщо такі конфлікти наявні у проєкті їх потрібно виправляти за допомогою 
методів «зглажування» або «калібрування». 
Метод «калібрування» полягає в тому, що явне навантаження розподіляється 
рівномірно протягом усього терміну виконання, що дає зниження пікового 
навантаження та дотримання термінів виконання робіт, проте використовуючи цей 
метод ресурси працюють понаднормово, що в свою чергу збільшує витрати на 
проєкт. 
Застосовуючи ж метод «зглажування» рівень задіяних ресурсів зводиться до 
номінальних 100%%, однак збільшуються терміни виконання проєкту. 
45 
  
Для того, щоб збалансувати дане перенавантаження, можна використати один 
чи декілька методів: 
– зменшити навантаження на перенавантажені ресурси шляхом скорочення 
частини робіт або доручення їх іншим учасникам; 
– позбавитися перетинів у роботах, додавши перерви в розкладі завдань або 
призначень, чи змінити дати початку та закінчення; 
– позначити роботу, яка виконується ресурсом, як понаднормову. 
Дані вирівнювання ресурсів можна виконувати, як автоматичними засобами, 
так і вручну. Проте, як правило використовують обидва варіанти, тому, що 
автоматичне вирівнювання використовує лише другий з наведених вище способів. 
Перед тим як починати, варто запам’ятати тривалість проєкту до змін, аби 
розуміти, як коригування змінить тривалість проєкту. 
 
Рисунок 3.14 – Тривалість виконання проєкту до зглажування ресурсів 
Більшою мірою у проєкті було використано метод «згалажування». Тобто 
навантаження на ресурс зводилося до номінальних 100% шляхом рівномірного 
розподілу відсотків навантаження ресурсу між паралельними роботами. Що в свою 
чергу призвело до збільшення тривалості проекту. 
 
Рисунок 3.15 – Лист ресурсів із вирішеними конфліктами ресурсів 
Як бачимо після зглажування тривалість проєкту складає 240 дня, замість 105 
днів до зглажування. Тобто тривалість проєкту збільшилася на 33 дні. В той же час 
витрати на проєкт знизилися з 235 600 грн. до 234 480 грн. Тобто змншилась на 1120 
грн. це відбулося за рахунок невеликої зміни зв’язків робіт та збільшення кількості 
паралельних робіт. 
46 
  
3.4  Планування якості проєкту 
Проєкт можна вважати успішним, якщо він завершений у запланований 
термін, відповідає встановленим вимогам щодо обсягів та якості, а вартість проєкту 
знаходиться в запланованих межах. Якість один з найважливіших параметрів 
проєкту поряд з часом, вартістю і ресурсами. Для того щоб дізнатися тривалість чи 
бюджет проєкту, потрібно задати необхідну кількість днів та вказати суму коштів. А 
що робити, що дізнатися якість проєкту? Слово «якість» часто використовують для 
позначення високої вартості, елітарності, відповідності найвимогливішим 
побажанням споживачів. Міжнародний стандарт ISO визначає якість як сукупність 
властивостей та характеристик об’єкта, які гарантують його можливість 
задовольняти явні та неявні потреби споживачів. 
Крім того, ініціативи організації, що виконує проєкт, з удосконалення якості 
можуть поліпшити якість управління проєктом і якість продукту проєкту. 
До цього проєкта застосовано таку концепцію формування якості: 
– формування корпоративних рекомендацій з якості (на основі стандартів серії 
ISO 9001), що визначають основні методи забезпечення якості та структуру 
документів системи забезпечення якості; 
– виконання усіх робіт в проєкті з урахуванням попередньо узгоджених і 
затверджених рекомендацій з якості; 
– впровадження технології управління проєктами як складової частини системи 
управління якістю; 
– кожен виконавець несе відповідальність за якість своєї праці; 
– контроль якості на всіх етапах проєкту. 
Після визначення концепції формування якості, варто визначитися з заходами 
щодо досягнення якості на кожній з фаз проєкту. 
Фаза ініціації 
На фазі ініціації важливим елементом є всебічний аналіз ринку та точне 
визначення очікувань та необхідностей клієнтів. 
Фаза планування 
47 
  
Важливим етапом на фазі планування є повнота та якість головних 
нормативних документів проєкту, оцінки ризиків, проєктних структур. 
Фаза реалізації 
На фазі реалізації результати робіт повинні відповідати всім вимогам 
корпоративної настанови з якості (ISO 9001), загальновизнаним стандартам якості. 
Фаза завершення 
Важливим етапом  фази завершення є оцінка якості продукту проєкту, 
термінів виконання робіт та бюджету. 
3.4 Планування якості проєкту 
Проєкт можна вважати успішним, якщо він буде завершений у запланований 
термін, буде відповідати встановленим вимогам щодо обсягів та якості, а вартість 
проєкту знаходиться в запланованих межах. Якість - один з найважливіших 
параметрів проєкту поряд з часом, вартістю і ресурсами. Для того щоб дізнатися 
тривалість чи бюджет проєкту, потрібно задати необхідну кількість днів та вказати 
суму коштів. А що робити, що дізнатися якість проєкту? Слово «якість» часто 
використовують для позначення високої вартості, елітарності, відповідності 
найвимогливішим побажанням споживачів. Міжнародний стандарт ISO визначає 
якість як сукупність властивостей та характеристик об’єкта, які гарантують його 
можливість задовольняти явні та неявні потреби споживачів. 
Крім того, ініціативи організації, що виконує проєкт, з удосконалення якості 
можуть поліпшити якість управління проєктом і якість продукту проєкту. 
До цього проєкта застосовано таку концепцію формування якості: 
– формування корпоративних рекомендацій з якості (на основі стандартів 
серії ISO 9001), що визначають основні методи забезпечення якості та 
структуру документів системи забезпечення якості; 
– виконання усіх робіт в проєкті з урахуванням попередньо узгоджених і 
затверджених рекомендацій з якості; 
48 
  
– впровадження технології управління проєктами як складової частини 
системи управління якістю; 
– кожен виконавець несе відповідальність за якість своєї праці; 
– контроль якості на всіх етапах проєкту. 
 
Після визначення концепції формування якості, варто визначитися з заходами 
щодо досягнення якості на кожній з фаз проєкту. 
Фаза ініціації 
На фазі ініціації важливим елементом є всебічний аналіз ринку та точне 
визначення очікувань та необхідностей клієнтів. 
Фаза планування 
Важливим етапом на фазі планування є повнота та якість головних 
нормативних документів проєкту, оцінки ризиків, проєктних структур. 
Фаза реалізації 
На фазі реалізації результати робіт повинні відповідати всім вимогам 
корпоративної настанови з якості (ISO 9001), загальновизнаним стандартам якості. 
Фаза завершення 
Важливим етапом  фази завершення є оцінка якості продукту проєкту, 
термінів виконання робіт та бюджету. 
 
3.5 Управління ризиками проєкту 
Оскільки планування та реалізація проєкту відбувається в умовах 
невизначеності, це породжує зміну внутрішнього та зовнішнього середовища. У 
форматі проєкту невизначеність – це відсутність достовірної та повної інформації 
щодо умов реалізації проєкту. Будь-який проєкт містить в собі виконання якої-
небудь нової діяльності в нових умовах, з використанням нових ресурсів і для 
створення нового результату. Більшість складних проєктів усе більш невизначені 
вже з перших стадій своєї розробки. Новизна або інноваційність проєкту приводить 
49 
  
до появи ризиків у широкому розумінні. Ризики можна визначити як 
невизначеності, пов'язані з виникненням у ході проєкту ситуацій, наслідком яких є 
вплив на тривалість, витрати та якість проєкту. 
Під управлінням ризиками розуміють процес реагування на події та зміни 
ризиків у процесі виконання проєкту . 
Основна стратегія управління ризиками – це мінімізація. Управління ризиками 
поєднує у собі планування ризиків, реалізацію дій по реагуванню, контроль, роботу 
з новими ризиками, або ризиками, що залишилися. 
Планування управління ризиками – процес в якому робиться вибір підходу до 
планування і управління ризиками для конкретного проєкту. Даний процес 
складається з таких рішень: рішення по обмеженнях реагування на ризики, рішення 
по організації і кадровому забезпеченню процедур управління ризиками проєкту, 
вибору джерел даних і часових інтервалів для ідентифікації ризиків, їх фінансовому 
забезпеченню. Фактично на даному етапі обговорюється і будується система 
управління ризиками в цьому проєкті. Управління ризиками має бути сплановане 
адекватно як р типу і рівню ризиків, так і важливості проєкту для організації. 
На рисунку 3.20 зображено загальний проєкт управління ризиками. 
Планування 
управління 
ризиками Ідентифікація 
ризиків 
Якісний аналіз 
ризиків 
Кількісний 
аналіз ризиків 
Планування 
реагування 
Моніторинг 
та контроль 
 
Рисунок 3.20 – Схема процесу управління ризиками 
Для проєкту застосовуються такі процеси управління ризиками: 
50 
  
– планування управління ризиками – процес вибору підходів до планування і 
управління ризиками для конкретного проєкту; 
– ідентифікація ризиків проекту – визначення ризиків, здатних впливати на 
проект, і документування їхніх характеристик: опис і природа ризику, 
категорія, умови виникнення, методи реагування; 
– якісна і кількісна оцінка ризиків і умов їх виникнення з метою оцінки 
імовірності їх виникнення і впливу на розвиток проекту. На цьому етапі 
якісно і кількісно визначається ступінь важливості ризику, розставляються 
пріоритети для різних категорій ризиків. 
– планування реагування на виявлені значимі ризики – визначення процедур 
і методів щодо ослаблення негативного впливу ризикових подій; 
– моніторинг і контроль ризиків – відстеження поточних, визначення вже 
існуючих і нових ризиків, виконання плану управління ризиками проекту й 
оцінка ефективності дій щодо управління ними. 
Для того, щоб оцінити вплив ризикових подій на процес реалізації проєкту, 
було використано наступну шкалу: 
 
– «0» - ризик не має ніякого впливу; 
– «0.05» - ризик має мінімальний вплив; 
– «0.1» - ризик має невеликий вплив; 
– «0.2» - ризик має помірний вплив; 
– «0.4» - ризик має великий вплив; 
– «0.8» - ризик має надмірно великий вплив. 
Тепер розподілимо ймовірності настання ризикової події  на такі діапазони 
(від 0 до 1, де 0 – подія неможлива, 1 – подія, що точно відбудеться): 
– 0,0-0,2 – дуже низька; 
– 0,2-0,4 – низька; 
– 0,4-0,6 – середня; 
– 0,6-0,8 – велика; 
– 0,8-1 – дуже велика. 
51 
  
Після цього визначаємо ймовірність настання того чи іншого ризику та його 
вплив на проєкт (табл. 3.4). 
Таблиця 3.4 – Ймовірність настання та вплив на проєкт ризиків 
№ Вид ризику Вірогідність Вплив на хід 
появи проєкта 
1 Технічний ризик 0,1 0,5 
2 Фінансовий ризик 0,2 0,8 
3 Ризик персоналу 0,3 0,4 
4 Маркетинговий ризик 0,1 0,2 
5 Юридичний ризик 0,1 0,2 
6 Управлінський ризик 0,3 0,6 
7 Форс-мажорний ризик 0,3 0,7 
8 Ринковий ризик 0,1 0,4 
Далі, для комплексної оцінки можливих наслдків впливу ризикової події на 
проєкт формується матриця аналізу ризиків (табл. 3.5) 
Таблиця 3.5 – Аналіз ризиків 
Вірогідність  
0.8 – 1.0      
 
 
 
 
0.6 – 0.8      
 
 
 
 
0.4 – 0.6      
 
 
 
 
0.2 – 0.4    3, 6, 7 2 
 
 
 
 
0.0 – 0.2   4, 5 1, 8  
 
 
 
 
 0.05 0.1 0.2 0.4 0.8 
Вплив 
 
52 
  
З табл. 3.5 видно, що найвпливовішим для проєкту є фінансовий ризик. 
Середній вплив мають: ризик персоналу, управлінський ризик, форс-мажорний 
ризик. 
Останнім кроком в управлінні ризиками є створення варіантів реагувань на 
ризики, що мають значний вплив на проєкт (табл. 3.6). 
Таблиця 3.6 – Заходи щодо запобігання ризикам проекту 
№ Вид ризику Застереження ризику Усунення ризику 
Кроки вирішення Відповіда Дата Кроки вирішення Відповіда
льний льний 
2 Фінансовий ризик - резервування ПМ  - перепланування ПМ 
бюджету бюджету 
- дослідити - кредитування 
можливості проєкту 
кредитування - пошук 
додаткових 
джерел 
фінансування 
3 Ризик персоналу - проведення ПМ  - пошук нових ПМ 
досконалого та учасників 
детального - підвищення 
відбору команди кваліфікації  
проєкту - навчання 
- стимулювання та персоналу 
заохочення 
учасників проєкту 
6 Управлінський - підвищення ПМ  -  перепланування ПМ 
ризик кваліфікації проєкту 
- консультації зі - прийняття 
спеціалістами в інших, більш 
управлінні професійних, 
- прийняття рішень 
правильних - пошук більш 
рішень кваліфікованого 
менеджера 
7 Форс-мажорний - резервування ПМ  - перепланування ПМ 
ризик бюджету проєкту 
- резервування 
часу 
3.6  Планування бюджету проєкту 
Планування бюджету проекту - це визначення вартості робіт, виконуваних у 
рамках проекту та процес формування на цій основі бюджету проекту, 
53 
  
встановленим розподілом витрат за видами робіт, за часом виконання робіт, 
статтями витрат, за центрами витрат або з інших позиціях. 
Бюджетування є плануванням вартості або планом витрат. Це означає, що 
бюджет повинен давати уявлення, коли, скільки і за що буде виплачено грошей. 
Тому тут можливе застосування будь-яких методів представлення витрат, головне - 
щоб вони задовольняли практичним вимогам зацікавлених у них стейкхолдерів, 
сформованим стандартам і відповідали на цікаві стейкхолдерів проекту питання. 
В якості форми представлення бюджету можуть виступати: 
– календарні плани-графіки витрат; 
– матриці розподілу витрат; 
– стовпчасті діаграми витрат; 
– стовпчасті діаграми кумулятивних (наростаючим підсумком) витрат; 
– лінійні діаграми розподілених у часі кумулятивних витрат; 
– кругові діаграми структури витрат. 
У команди буде фіксована ставка та, у разі їх наднормової роботи, додаткова 
ставка. Для її розрахунку необхідно використання ресурсів за годину множити на 
тривалість робіт (рис. 3.21). 
 
Рисунок 3.21 – Ставка кожного виконавця проєкту 
В MS Project витрати обраховуються автоматично, як тільки до робіт будуть 
присвоєні доступні ресурси. Для зручності на діаграму Ганта можна вивести 
витрати проєкту, для цього необхідно додати відповідний стовпчик (рис. 3.22). 
54 
  
 
Рисунок 3.22 – Діаграма Ганта з витратами проєкту 
Ще в MS Project існує безліч шаблонних звітів, в тому числі і фінансових, за 
допомогою яких можна зробити різні звіти, що будуть корисні проєктному 
менеджеру на етапі моніторингу та контролю. 
Наприклад, можна зробити огляд вартості ресурсів (рис. 3.23). 
55 
  
 
Рисунок 3.23 – Звіт з оглядом вартості ресурсів 
Також MS Project можна переглянути всі витрати за проєктом. 
Зробити це можна виконавши кілька кроків: 
– обираємо комірку «Подання» в стрічці; 
– шукаємо комірку «Таблиці»; 
– у випадному списку обираємо «Витрати». 
56 
  
 
Рисунок 3.24 – Таблиця витрат по проєкту 
 
3.7 Управління комунікаціями в проєкті 
Кoмунікації в проєкті варто розглядати як один з ключових етапів управління 
проєктами. При відсутнoсті комунікацій всі процеси проєкту зупиняються: 
керівники не мають інформації про виконані роботи, виконавці не знають, чи в 
достатній мірі результати їх роботи відповідають проєктам і планам, менеджер 
проєкту не може координувати виконання робіт. Через це припиняється будь-яка 
діяльність по здійсненню проєкту до тих пір, поки не будуть відновлені комунікації. 
Комунікації часто порівнюють з соціальним клеєм, що дозволяє склеїти все 
розмаїття процесів, які забезпечують розвиток проєктів, в єдине ціле. В середньому 
57 
  
менеджер проєкту витрачає 80% свого часу на комунікації. Тому процеси 
комунікації, засоби їх діагностики, виявлення проблем та їх усунення надзвичайно 
важливі для ефективного управління проєктами. 
Комунікація проєкту – це процес, в ході якого одні учасники проєкту 
передають іншим яку-небудь інформацію, пов'язану з досягненням цілей проєкту. 
Учасники комунікації обмінюються інформацією, при цьому мета комунікації – 
домогтися від приймаючої сторони точного розуміння відправленого повідомлення. 
У комунікації завжди беруть участь, принаймні, дві людини – сторони комунікацій. 
Сторонами тут можуть бути групи людей (наприклад, команда проєкту) і навіть 
організації. 
Аби проєкт нормально функціонував, учасникам проєкту необхідно ретельно 
координувати свої дії та зусилля. 
Для проєкту було розроблено наступний план комунікацій (табл. 3.7). 
Таблиця 3.7 – План комунікацій проєкту 
№ Вид комунікації Регулярність Хто відправляє Хто отримує 
комунікації інформацію інформацію 
1 Тижневий звіт по 1 раз на тиждень Виконавець Той, хто контролює 
задачах (кожну п’ятницю) 
2 Місячний звіт по 1 раз на місяць Виконавець Той, хто контролює 
задачах (останній день місяця) 
3 Звіт за місяць по 1 раз на місяць (перший Менеджер проекту Замовник 
проекту день місяця) 
4 Щотижнева 1 раз на тиждень Виконавець Менеджер проекту 
нарада (кожна п’ятниця) 
5 Усна комунікація Кожний  день Будь-хто з команди Будь-хто з команди 
6 Підсумковий звіт При завершенні Менеджер проекту Замовник 
по всьому проекту проекту 
Висновки до розділу 3 
Планування проєкту є найголовнішою його частиною. 
У фазі планування для даного проєкту розроблено зміст проєкту з повним 
переліком робіт, що необхідно виконати для успішного завершення проєкту. 
Подальшим  етапом є розроблення календарного плану проєкту. Для якого, до 
повного переліку робіт була визначена тривалість кожної роботи, як наслідок 
58 
  
тривалість всього проєкту, також на цьому етапі були встановлені зв’язки між всіма 
роботами проєкту. 
Після створеного календарного планування відбувається планування ресурсів. 
На цьому етапі для проєкту були внесені необхідні для виконання робіт трудові 
ресурси, що згодом були призначені для виконання робіт. 
Потім відбувається планування якості проєкту. В цьому етапі були сформовані 
та прописані стандарти якості, яким повинен відповідати проєкт. 
На етапі управління ризиками визначено, які види ризиків для проєкту більш 
небезпечні та розроблено відповідні кроки, щоб запобігти появі даних ризиків та 
варіанти вирішення ризикової ситуації, в разі її виникнення.  
На етапі планування бюджету була закладена вартість проєкту, його 
обмеження та допущення.  
Останнім етапом фази планування є управління комунікаціями проєкту. В 
даному етапі розроблено план комунікацій для проєкту, за допомогою якого 
учасники зможуть комфортно обмінюватися необхідною інформацією. 
Отож, планування проєкту є важливим, оскільки охоплює всі фундаментальні 
етапи створення проєкту. Розробивши даний розділ, стало зрозуміло, що для 
успішного завершення проєкту менеджер повинен вкласти в планування всі свої 
можливості та знання. 
 
 
 
 
 
 
 
 
 
 
 
59 
  
4 ДЕТАЛЬНА РОЗРОБКА ПРОЄКТУ  
4.1 Механізм контролю робіт проєкту 
Найважливішим елементом системи контролю є моніторинг проекту. За 
допомогою даного механізму відбувається постійне спостереження за 
найважливішими поточними результатами реалізації проекту з метою своєчасного 
виявлення відхилень від календарного плану та бюджету. 
Моніторинг дозволяє здійснювати порівняння заданих і фактичних даних, які 
стосуються планування проєкту та його реалізації. Шляхом оцінки проводиться 
порівняння між заданими плановими показниками та їх фактичними показниками 
проєкту. Моніторинг використовують для вирішення наступних завдань: 
– Своєчасне виявлення проблем; 
– Відображення здійснених операцій, витрат і використаних ресурсів; 
– Поліпшення робіт в рамках проєкту; 
– Розпізнавання можливостей подальшого поліпшення технологій; 
– Оцінка якості управління проєктом; 
– Економія витрат; 
– Прискорення появи необхідних результатів проекту; 
– Визначення помилок і аналіз їх причин; 
– Забезпечення стейкхолдерів інформацією. 
В даному проєкті моніторинг відбувається наступним чином: 
– Виконавець має надсилати звіт особі, що його контролює кожної 
п’ятниці; 
– Виконавець має надсилати місячний звіт по задачам особі, що 
контролює його роботу першого числа кожного місяця; 
– Кожної п’ятниці проводиться нарада, де виконавці надають звіт 
проєктному менеджеру; 
– Усна комунікація між командою проєкту може відбуватися у будь-який 
час; 
60 
  
– Менеджер проєкту надає замовнику підсумковий звіт по всьому проєкту 
після завершення проєкту. 
Звіти потрібні для ведення контролю за ходом виконання робіт, аналізу виконаної 
роботи та постановки завдання на наступний тиждень.  
4.2 Опис засобів програмної реалізації додатку 
Мова програмування.  
Для програмної реалізації даного додатку була обрана мова програмування C++, 
одна із найстаріших мов, застосовується до створення нативних додатків із 
потужним навантаженим функціоналом. Це можуть бути ігри або технічно складні 
програми. Найчастіше використовується як С/С++. На ньому пишуться лише певні 
частини чи модулі, які виконують складні операції та завдання. 
Якщо ставити питання, якою мовою пишуть додатки для андроїд, то складно 
сказати, що С/С++ сюди безпосередньо відноситься. Але без його знань буде 
складно реалізувати потужні функції. Головна його перевага полягає в запуску коду, 
який виробляється не через Java Virtual Machine, а через девайс. Це дозволяє 
отримати більший контроль над елементами системи пристрою. 
С/С++ є універсальною мовою, здатною підтримувати різні стилі 
програмування. Він дає більшу свободу розробнику, у своїй не накладає 
навантаження програму. Підходить для роботи на будь-якому програмному 
середовищі. Це одна з базових мов, за допомогою якої здійснюється не тільки 
програмування на андроїді, але й на будь-яких інших системах. 
 
Система управління базами даних (СУБД) 
Для зберігання програм тренувань, вправ та інших активностей додатку 
необхідна база даних. Для даного проєкту була обрана SQLite [18], яка є відкритою 
базою даних SQL, що зберігає дані у форматі тексту на пристроях.  
61 
  
SQLite являє собою самодостатній, високонадійний, вбудований, 
загальнодоступний механізм бази даних SQL. Це найбільш використовувана 
система баз даних у світі. ЇЇ бібліотека постійно в процесі роботи, а її код є 
загальнодоступним. ЇЇ можна використовувати безкоштовно як для комерційних, так 
і  приватних цілей. Формат файлу бази даних SQLite є кросплатформним, тому 
кожен може легко скопіювати базу даних між 32-розрядними та 64-розрядними 
системами. Завдяки всім цим функціям, це адекватний вибір.  
Опис функцій та можливостей додатку 
Для більшого розуміння результату проєкту наведемо концептуальний опис 
створюваного продукту та опис його основних функцій. 
Після встановлення застосунку з Play Store, користувач матиме змогу 
зареєструватися згідно його статусу з авто (власник, довірена особа, гість). Після 
реєстрації користувачу пропонується вказати марку автомобіля, або обрати зі спику 
наявних у швидкому пошуку; інформацію про проходження останнього технічного 
огляду, з якого буде взятий стан автомобіля в цілому, та зношеність основних 
розхідних і важливих частин. 
Коли реєстрація буде завершеною, користувач без проблем може 
використовувати усі функції додатку. Сам додаток запам’ятовує інформацію про 
авто на пам’яті пристрою та, у разі необхідності, може надати її уже кваліфікованим 
спеціалістам з ремонту транспортних засобів. 
4.3 Макет додатку 
62 
  
 
Рисунок 4.1  Головне меню додатку 
Головне меню (Рис.4.4.1) матиме приблизно такий вигляд, на ньому будуть 
знаходитись лише найголовніші функції додатку, та через нього відбуватиметься 
основний вхід в додаток. 
 
 
Рисунок 4.2  Меню читання та скидання помилок  
 
Необхідна функція в кожному додатку - це читання помилок  та їх скидання. 
Далеко не завжди звичайна заміна необхідного елементу обумовлене само 
скиданням помилки, дуже часто це необхідно робити на сервісі, чи власноруч але 
прибігати до методик дивного комбінування клавіш на панелі приборів авто. 
63 
  
 
Рисунок 4.3 Інформація про автомобіль 
  
Функція «Інформація про автомобіль» надаватиме актуальні відомості про 
кількість і складність помилок, та іншу інформацію пов’язану з автомобілем. 
Планується додати можливість закріплення інформації за бажанням користувача. 
 
Рисунок 4.4 Графіки характеристик авто 
Деякі параметри неможливо назвати точно на момент експлуатації авто, так як 
на це впливає безліч факторів. Графік характеристик займатиметься моніторингом 
динамічних систем автомобіля, з подальшим порівнянням їх з попередніми 
64 
  
замірами, так користувач матиме уявлення про причини чи обставини, через які авто 
покращило чи погіршило свої динамічні якості. 
 
Рисунок 4.5  Контрольні тести системи 
 Система може потребувати перевірки до моменту, коли водій потрапить на 
дорогу. Для цього існуватиме можливість перевірки основних систем авто, та 
окремих за бажанням користувача. 
Ще одним примітним фактором є наявність виходу додатка на інтернет 
магазини, магазин отримуватиме інформацію про автомобіль користувача, та за 
необхідності буде представляти запчастини необхідні саме для даного автомобіля. 
 
 
 
Рисунок 4.6 Меню вибору марки та моделі автомобіля 
Після збереження авто користувача в системі сайту, усі товари автоматично 
підбираються саме під задану марку автомобіля. 
65 
  
  
 
Рисунок 4.7 Групи запчастин 
 
66 
  
Сайт має прекрасний каталог запчастин, який візуально виглядає дуже 
компактно.  
 
Рисунок 4.8 Меню налаштувань та інформації про додаток буде знаходитись 
за «шторою» у верхньому лівому куті. 
 
4.4  Особливості використання додатку 
Для максимальної результативності додатку, та отримання інформації точно 
та швидко, буде необхідно встановлювати власну систему контрольних датчиків, це 
необхідно буде для можливості використання додатку з дому, коли автомобіль не 
працює. Система матиме живлення від сигналізації авто, яка якраз працює в момент 
не працюючого транспортного засобу. 
Висновки до розділу 4 
У даному розділі детально описані можливості та функції додатку, що 
розробляється в кваліфікаційній роботі магістра. Показаний перелік функцій, які має 
додаток, а також, який вигляд має інтернет-магазин та його особливості. 
Створено попередній макет застосунку, для наочного прикладу. 
67 
  
Також в даному розділі обрано та зроблено короткий опис програмних засобів, 
які знадобляться для практичної реалізації додатку. Виконано планування, яким 
чином відбуватиметься моніторинг та контроль проєкту. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
68 
  
ВИСНОВКИ 
У цій кваліфікаційній роботі показано управління проєктом з розробки 
мобільного додатку в сфері автотранспорту.  Керування автомобілем чи то власним, 
чи тим, який надає компанія, фірма тощо., майже неможливе без знань систем 
автомобіля. Тому для виключення даної проблеми ,та зосередження на своєму житті 
додатки такого плану дуже актуальні. 
Кожен розділ кваліфікаційної роботи є важливою частиною розробки проєкту. 
Так у першому розділі описується проблема, яку вирішуватиме застосунок.  
На основі розуміння проблеми, що вирішує додаток, який буде 
реалізовуватись, розробляється концепція проєкту, якій присвячений другий розділ, 
де формується важлива частина проекту, розуміння того, як виглядатиме процес 
реалізації додатку. 
У третьому розділі відбувається планування розробки за допомогою MS 
Project. Даний розділ є безперечно важливим, оскільки містить в собі точне 
визначення тривалості, вартості проєкту. В ньому відбувається планування таких 
важливих чинників, як ризики, комунікації та бюджет проєкту. 
В останньому розділі розглянуто яким чином в проєкті відбувається 
моніторинг та контроль, що неменше важливо для успішного виконання проєкту. 
Вибрані програмні засоби для його реалізації. Такoж у четвертому розділі виконано 
опис можливостей та функцій кінцевого продукту проєкту та створено макет 
додатку. 
В майбутньому планується виконати програмну реалізацію застосунку, що 
розроблений в кваліфікаційній роботі, використовуючи створений в цій роботі 
проєкт. Після програмної реалізації вивести додаток на ринок, додавши його в 
Google Play.  
Отже, кожен етап реалізації проєкту має важливе значення для проєкту. 
Успішним проєктом буде той, де всі фази, від ініціації до завершення, методично та 
чітко розроблені, а всі учасники проєкту мають достатньо кваліфікації для 
виконання поставлених цілей
Репозиторій ЧДТУ
