Дослідження процесів створення інформаційних систем турагенств

Липний, Василь Віталійович

Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/6439

Назва:	Дослідження процесів створення інформаційних систем турагенств
Автори:	Зубко, Ігор Анатолійович Липний, Василь Віталійович
Дата публікації:	січ-2024
Короткий огляд (реферат):	Дослідження процесу розробки програмного забезпечення для контролю відвідування занять студентами та учнями є актуальним науковим завданням, що дасть можливість підвищення ефективність використання необхідних ресурсів та дотриматись заданих часових рамок. Дослідження проєктів дає можливість чітко визначити мету і результати проєкту, дати їм кількісні характеристики, тимчасові, вартісні і якісні параметри проєкту, створити чіткий план проєкту, виділити, оцінити ризики і запобігти можливі негативні наслідки під час реалізації проєкту. На сьогоднішній день методологія управління проєктами довела своє право вважатися одним з найефективніших способів успішної реалізації проєктів.
URI (Уніфікований ідентифікатор ресурсу):	https://er.chdtu.edu.ua/handle/ChSTU/6439
Розташовується у зібраннях:	123 Комп’ютерна інженерія (Спеціалізовані комп’ютерні системи)

Файли цього матеріалу:

Файл	Опис	Розмір	Формат
М_123_2023_Липний+.pdf Restricted Access		1.2 MB	Adobe PDF	Переглянути/Відкрити Запит копії

Показати повний опис матеріалу Перегляд статистики

Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.

Extracted text

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ
СИСТЕМ

Пояснювальна записка
до кваліфікаційної роботи
освітнього ступеню «магістр»
на тему: «Дослідження процесів створення інформаційних систем турагенств»

Виконав: студент 2 курсу, групи МСКС-2207
спеціальності 123 Комп’ютерна інженерія,
освітня програма «Спеціалізовані
комп’ютерні системи»
Василь Липний
(ім’я, ПРІЗВИЩЕ)

Керівник Ігор Зубко
( ім’я, ПРІЗВИЩЕ)

Рецензент
( ім’я, ПРІЗВИЩЕ)

Черкаси 2023 року
СПИСОК УМОВНИХ СКОРОЧЕНЬ

- ІТ – Інформаційні технології;
- ПК – Персональний комп’ютер;
- OC – Операційна система;
- SMM – Social media marketing;
- PR – Public relations;
- UI – User interface;
- UX – User experience;
- SEO – Search engine optimization;
- WBS - Work breakdown structure;
- ТЕО – Техніко-економічне обгрунтування;
- ТЗ – Технічне завдання;
- PSD – Photoshop document;
- БД – Бази даних;
- TQM – Total Quality Management;
- PDCA – Plan do check act;
- QA – quality assurance;
- ІСР – інтегроване середовище розробки;
- ПМ – Проєктний менеджер;
- ІБ – Інформаційна безпека;
- СУІІБ – Система управління інцидентами інформаційної безпеки;
- ІД – Інвестиційна діяльність;
- ОД – Операційна діяльність.

Зміст
СПИСОК УМОВНИХ СКОРОЧЕНЬ ...................................................................... 2
Вступ ................................................................................................................................. 6
РОЗДІЛ 1. СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУВАННЯ ЗАВДАНЬ
........................................................................................................................................... 9
1.1 Опис предметної області розробки інформаційних систем для
туристичних компаній .............................................................................................. 9
1.2 SWOТ та PEST аналізи проєкту .................................................................... 13
1.3. Концепція проєкту ........................................................................................... 17
РОЗДІЛ 2. ГАЛУЗІ ЗНАНЬ З УПРАВЛІННЯ ПРОЄКТАМИ .................................. 24
2.1 Управління інтеграцією та інформаційним зв’язком в проєкті ................... 24
2.2 Управління змістом проєкту (WBS - структура) .......................................... 27
2.3 Управління трудовими ресурсами в проєкті ................................................. 29
2.4 Управління вартістю проєкту ......................................................................... 33
2.5 Управління якістю проєкту ............................................................................ 34
2.6 Управління закупівлями в проєкті ................................................................ 37
2.7 Управління ризиками проєкту ........................................................................ 41
2.8 Управління змінами проєкту .......................................................................... 56
2.9 Контроль проєкту ............................................................................................ 58
РОЗДІЛ 3. РОЗРОБКА СИСТЕМИ ОЦІНКИ ЕФЕКТИВНОСТІ ПРОЄКТУ ......... 61
3.1 Система оцінки ефективності проєкту ........................................................... 61
3.2 Управління часом в проєкті ............................................................................ 64
3.3 Оцінка економічної ефективності проєкту ................................................... 67
3.4 Розробка зведеного кошторису витрат інвестиційної фази проекту ......... 69
3.5 Планування амортизаційних витрат операційної діяльності ...................... 71
3.6 Прогноз доходів та витрат операційної діяльності ..................................... 72
3.7 Прогноз грошових потоків проекту .............................................................. 75
3.8 Оцінка показників ефективності проекту ..................................................... 77
3.9 Оцінка соціальної ефективності проєкту ...................................................... 79
ВИСНОВКИ ................................................................................................................... 81
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ .............................................................. 84

5
Вступ
Інвестиційна діяльність в сучасних умовах тісно пов'язана з умінням
розроби- ти ефективний інвестиційний план або проєкт, а потім забезпечити
визначені ними обмеження по ресурсах і реалізувати заданий рівень якості
продукції проєкту. Тому гостро постає питання про необхідність
забезпечення ефективного управління проєктом. Успіх кожної організації
залежить від її здатності адаптуватися на зміни зовнішнього оточення. Саме
поняття «зміни» є сутністю будь-якого проєкту, а управління проєктами
розглядається як універсальна методологія управління такими змінами.
Управління проєктами не є чимось незвичайним – це найбільш ефективний
засіб досягнення результату. Краще або гірше, у залежності від умінь, інтуїції
й удачі менеджерів, проєкти завжди повинні бути керовані.
Практично завжди під час реалізації проєктів в галузі інформаційних
технологій виникає визначений набір невирішених проблем, таких як
збільшення обсягу опе- рацій і зменшення швидкості роботи системи,
використання могутньої системи не на повну потужність, перетворення
впровадження в нескінченний процес, постійну зміну вимог і т.д. Управління
ризиками в проєкті, може повністю або частково запобігти цим ситуаціям.
Знаючи методи і аналізи боротьби з ризиками і використовуючи їх в
управлінні проєктами в галузі створення інформаційної системи, можна
уникнути зриву проєкту, оскільки сама галузь створення інформаційних
систем є досить не прогнозованою.
Управління проєктами [15] у широкому розумінні – це професійна
діяльність, заснована на використанні сучасних наукових знань, навичок,
методів, засобів і технологій і орієнтована на одержання ефективних
результатів.
Застосування методології управління проєктами дає можливість чітко
визначити мету і результати проєкту, дати їм кількісні характеристики,
тимчасові, вартісні і якісні параметри проєкту, створити чіткий план проєкту,
виділити, оцінити ризики і запобігти можливі негативні наслідки під час
реалізації проєкту.
6
Актуальність теми. Застосування проєктного підходу в процесі створення
інформаційної системи турагенстває актуальним науковим завданням, що
дасть можливість підвищення ефективності використання необхідних
ресурсів та дотриматись заданих часових рамок.
Мета дослідження. Метою даної кваліфікаційної роботи є розкрити
методологію управління проєктом створення інформаційної системи
турагенства за допомогою теоретичних знань та практичних навичок, що були
здобуті за час навчання.
Для досягнення поставленої мети були сформульовані та вирішені такі
завдання дослідження:
- структурувати проєкт (підцілі, підпроєкти, фази і т.д.);
- визначити фінансові потреби і джерела фінансування;
- забезпечити контроль за ходом виконання проєкту і внесення
коректив у план реалізації;
- управління ризиками в проєкті.
Об’єктом дослідження є проєкт створення інформаційної системи
турагенства.
Предмет дослідження – методи та засоби управління проєктом
створення інформаційної системи турагенства.
Галузь дослідження - галузь інформаційних технологій.
Методи дослідження. В роботі застосовані методи проєктного
менеджменту згідно PMBok.
Наукова новизна одержаних результатів. Вперше застосовано метод
дерева цілей при формулюванні цілей проєкту створення інформаційної
системи турагенства.
Практичне значення одержаних результатів. Практична значимість
даної роботи полягає в тому, що теоретичні положення та висновки знайшли
своє безпосереднє застосування в ході управління проєктом створення
7
інформаційної системи турагенства.
Апробація результатів роботи і публікації. Результати кваліфікаційної
роботи представлені в Матеріалах VІIІ Міжнародної науково-технічної
Internet-конференції
«Сучасні методи, інформаційне, програмне та технічне забезпечення систем
керування організаційно-технічними та технологічними комплексами», 26
листопада 2021. [Електронний ресурс] – К: НУХТ, 2021 – C.179. — Режим
доступу: https://nuft.edu.ua/naukova-diyalnist/naukovi-konferencii/
8
РОЗДІЛ 1. СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУВАННЯ ЗАВДАНЬ
1.1 Опис предметної області розробки інформаційних систем для
туристичних компаній
Проєкт – це тимчасова діяльність, призначена для створення унікальних
програмних продуктів для IT сфери або послуг.
Найчастіше проєкти є засобом організації роботи по створенню нових
продуктів, до того ж ступені новизни продукту можуть мінятися від світового
рівня до локальної новизни(новизни для даної організації). Прибуток проєкту
суттево залежить від рівня новизни, до того ж: чим вищий рівень новизни, тим
вищий рівень прибутку.
Характеристики проєкту:
● тимчасовість;
● унікальність(від світового рівня до локального);
● наукова ємність проєктних рішень;
● терміни виконання;
● затрати на проєкт;
● рентабельність проєкту(прибуток);
● рентабельність створеного продукту
Управління проєктами — це система організації робіт по створенню
нового IT продукту, яка забезпечує задоволення вимог, що пред'являються до
проєкту. Управління проєкту передбачає застосування нових наукових знань,
навичок, інструментів і методів операцій по проєкту.
Проєктний менеджмент — процес управління командою, ресурсами
проєкту за допомогою спеціальних методів та прийомів з метою успішного
досягнення поставленої мети. Класично найважливішими параметрами у
процесі управління проєктом вважають виконання роботи у заданих обсягах,
вчасно і в межах виділених коштів [9].
Американський Інститут управління проєктами розробив сертифікаційну
9
програму, в якій, окрім етичного кодексу і професійного досвіду, було
визначено професійні знання, відомі як Project Management Body of
Knowledge (PMBOK). PMBOK
[10] складається з дев’яти функцій: менеджменту обсягів, затрат, часу, якості,
людських ресурсів, комунікацій, контрактів/постачання, ризиків, проєктної
інтеграції.
Перші чотири функції (спрямовані на управління цілями) заведено
називати основними. Це такі функції [12]:
Управління обсягом проєкту — контролює проєкт за допомогою
встановлення його мети, завдань і цілей.
Управління затратами — передбачає фінансовий контроль проєкту
завдяки накопиченню, аналізу та складанню звітів по затратах.
Управління часом — передбачає планування, складання календарних
графіків та їх контроль для забезпечення вчасного виконання проєкту.
Управління якістю — забезпечує виконання стандартів якості,
встановлених для проєкту.
П’ять функцій, перелічених нижче (спрямовані на управління певними
об’єктами), називають додатковими [14]:
Управління людськими ресурсами — включає спрямування і
координацію діяльності людей, залучених до проєкту.
Управління комунікаціями — накопичує інформацію, якою
обмінюються члени проєктної команди, керівництво, і сприяє успішному
завершенню проєкту.
Управління контрактами/постачанням — передбачає відбір, переговори
і підписання замовлень, контроль за постачанням матеріалів, устаткування і
послуг (обслуговування).
Управління ризиком — залежить від ступеня невизначеності проєкту і
базується на знаннях та досвіді із зазначенням умов реалізації конкретного
проєкту.
Управління проєктною інтеграцією — має забезпечити належну
координацію всіх функцій проєкту.
10
Згідно [15], основні функції PMBOK визначено за цілями, за досягнення
яких
відповідає проєктний менеджер, а додаткові — за об’єктами, на які
спрямовується
діяльність керівника. Проте в назві всіх цих функцій наявне спільне слово
управління, що, в свою чергу, передбачає виконання в їх межах таких функцій
управління, як організація, планування, контроль, мотивація. Інакше кажучи,
проєктний менеджер повинен здійснювати основні функції управління щодо
специфічних цілей та об’єктів очолюваних ним проєктів.
IT сфера є одним з найбільш прогресивних напрямків бізнесу, що
розвивається дуже швидкими темпами як в Україні, так і в цілому світі.
Основним видом діяльності є розробка продуктів та сервісів Інтернет
Технологій. Як свідчать дані НБУ за 2014-2015 рік, IT індустрія має дуже
великий внесок у ВВП країни. Дохід на 2014 рік складає 18.1 млрд. гривень
(за даними Horizon Capital), при цьому є стабільна сплата податків. На 2014-
2015 рік налічується 74 000 - 100 000 IT спеціалістів, що працюють у даній
сфері.
Прогнози говорять про те, що до 2020 року очікується зростання обсягу
галузі до 182 млрд грн. в рік, також збільшиться кількість робочих місць до
180 000, тобто 20 000 нових місць щорічно (Рис.1). Варто також відмітити, що
на сьогодні середня заробітна плата ІТ спеціаліста становить 2 000 $.
Існує щонайменше 3000 ІТ компаній в Україні. В Черкасах їх налічується
близько 40ка.

Рис. 1.1. Розвиток структури ринку IT галузі в Україні
Інформаційні та комунікаційні технології в Україні знаходиться на
11
третьому місці в експорті, після аграрного сектору та металургії. Варто
зазначити, що довго третє місце займала хімічна промисловість, та IT
посунула її на четверте місце.
Головним критерієм функціонування туристичних компаній є
задоволення по бажань клієнтів, намагаючись повністю задовольнити їхні
потреби в якісному відпочинку. Щорічно туристичні компанії відправляють
за кордон понад 12000 туристів. Значна увага в роботі компанії приділяється
інновація та новітнім технологіям. В даний момент існує потреба в розробці
інформаційних систем, що забезпечувала б можливості онлайн роботи з
клієнтом, де можна було б здійснити пошук турів по всіх туроператорах
України. Також необхідна зручна система пошуку, де кожен мав би змогу
підібрати собі потрібну пропозицію за найвигіднішою ціною. Основними
принципами роботи компанії є відповідальність, професіоналізм та
індивідуальний підхід до кожного клієнта, збереження репутації. Туристичні
компанії тісно співпрацюють з туроператорами, для яких основним
критерієм є надійність.
Головною метою туристичних компаній є розвиток внутрішнього
туризму в Україні, розробка нових оригінальних маршрутів. Більшість
туристичних компаній є туроператорами по Україні і працюють за двома
напрямками - внутрішній та виїзний туризм.
Кожний туристичний маршрут розробляється безпосередньо
менеджерами компанії. Працівники компанії плідно відшукують цікаві факти
з української історії та культури, особисто виїжджають в місця, з ними
пов’язані, готують марш- рути і доповнюємо їх якісним сервісом. В Україні є
досить багато історичних маловідомих місць, які варто відвідати. Туристична
компанія повинна забезпечувати виконання наступних послуг:
• Виїзд менеджера в офіс або додому з каталогами
• Бронювання готелів по всьому світу
• Допомога в підготовці документів в консульство і їх переклад на іноземні
мови
12
• Доставка документів додому або в офіс
• Готівковий і безготівковий способи оплати турів
• Медичне страхування
• Продаж і поповнення карток Тревел СІМ.
Тому для туристичної компанії необхідна така інформаційна система
управління, що надавала б такі можливості:
- це колектив відповідальних фахівців, які можуть надати грамотну
консультацію кожному туристу, завдяки знанням, отриманим під час ста-
жування за кордоном. Компанія практикує індивідуальний підхід до
кожного клієнта та гарантує досконалий сервіс. Працівники завжди го-
тові допомогти вибрати відпочинок на морі в будь-якій частині світу;
гарячу путівку, в якій привабливе співвідношення ціна – якість поєдна-
не з відмінним сервісом; екскурсійні тури, які надають можливість
ознайомитись з декількома країнами; тур вихідного дня чи круїз; за-
бронювати авіаквитки; організувати індивідуальну мандрівку найбільш
вимогливому клієнту. Однак необхідно надання можливостей клієнту
здійснити онлайн пошук туру відповідно на сайті компанії, а також
можливості замовлення туру та його безпосередньої оплати.
1.2 SWOТ та PEST аналізи проєкту
Управління проєктом пов'язано з питаннями планування й організації
робіт, створення колективів розроблювачів і контролю за термінами і якістю
виконуваних робіт. Технічне й організаційне забезпечення проєкту включає
вибір методів і інструментальних засобів для реалізації проєкту, визначення
методів опису проміжних станів розробки, розробку методів і засобів
випробувань ПЗ, навчання персоналу і т.п. Забезпечення якості проєкту
зв'язано з проблемами верифікації, перевірки і тестуван ня ПЗ. Верифікація -
це процес визначення того, чи відповідає поточний стан розробки, досягнутий
на даному етапі [17], вимогам цього етапу. Перевірка дозволяє оціни- ти
відповідність параметрів розробки з вихідними вимогами. Перевірка частково
збі- гається з тестуванням, що зв'язано з ідентифікацією розходжень між
13
дійсними й очікуваними результатами й оцінкою відповідності харак-
теристик ПЗ початковим вимогам. У процесі реалізації проєкту важливе місце
займають питання ідентифікації, опису і контролю конфігурації окремих
компонентів і всієї системи в цілому.
Методологія проєктного менеджменту є одним з тих небагатьох засобів
управління, за допомогою яких досягається більш високий рівень якості уп-
равління, оптимізації та інновації.
Реалізація проєкту вимагає виконання певної кількості різноманітних
заходів і робіт, які для зручності розгляду можна поділити на дві групи:
основна діяльність і діяльність із забезпечення проєкту. Такий поділ є поділом
процесу реалізації проєкту на фази і стадії, оскільки ці види діяльності часто
не співпадають у часі.
При формулюванні стратегії впровадження програмного продукту
(інформаційної системи) необхідно чітко уявляти, можливості та загрози
ринку. Процес всебічного пристосування підприємства до зовнішніх і
внутрішніх умов характерний для ринкових умов господарювання
обумовлюється загальною макроекономічною ситуацією, зміною
кон’юнктури ринку чи впливом внутрішніх факторів підприємства. Для
ефективного розвитку в конкурентному середовищі підприємство повинне
мати певний рівень прибутку, постійно збільшувати свою ринкову вартість,
зберігати та збільшувати частку ринку. А це, в свою чергу, передбачає
постійні зміни на підприємстві в організаційній структурі, технології,
управлінні.
SWOТ-аналіз - це аналіз зовнішнього та внутрішнього середовища
організації. Аналізу підлягають сильні сторони (Strength), слабкі сторони
(Weakness) внутрішнього середовища, а також можливості (Opportunities) і
загрози (Threats) зовнішнього середовища організації [14].
Згідно методології SWOT-аналізу необхідно виявити сильні та слабкі
сторони, можливості і загрози проєкту впровадження програмного продукту
(ІС для туристичних компаній). Після цього встановлюються зв'язки між
ними, які в подальшому можуть бути використані для формулювання
14
подальшої стратегії проєкту впровадження програмного продукту (ІС для
туристичних компаній). SWOT-аналіз проєкту впровадження програмного
продукту (ІС для туристичних компаній) наведений в таблиці 1.1
Таблиця 1.1. Результати SWOТ-аналізу проєкту впровадження програмного
продукту (ІС для туристичних компаній).

Strengths (конкурентні Opportunities (сприятливі обста-
вини, використанняя ких ство- рює
переваги) переваги)
1. Високий рівень контролю якості; 1. Необхідність в розробці ІС;
2. Зростання оборотних коштів; 2. Ритмічна робота проєктної
3. Досвід роботи з клієнтами; команди;
4. Концентрація на певних продуктах 3. Погіршення позицій
конкурентів;
та послугах;
4. Співпраця з зарубіжними
5. Передові інформаційні
партне- рами;
технології та висока якість
5. Удосконалення менеджменту;
обслуговування;
6. Надання послуг он-лайн;
6. Висококваліфікований персонал
7. Участь в міжнародних проєктах
та досконала система управління;
7. Ефективна взаємодія з місцевими
органами влади.
Weaknesses (слабкі сторони) Threats
(фактори, які потенційно можуть
погір шити становище на ринку)
1. Некомпетентність персоналу у 1. Нестабільність політичного
питаннях прийняття правлінських середовища;
рішень; 2. Економічна депресія;
2. Погане управління активами; 3. Можливі великі коливання курсу
3. Не виділяються та не обміну валюти;
вдосконлю-ються основні бізнес- 4. Вихід на ринок нових
конкурентів;
процеси;
4. Надмірний ріст персоналу.
15
PEST - аналіз дає можливість виявлення політичних (P - political), еко-
номічних (E - economic), соціальних (S - social) і технологічних (T -
technological) аспектів зовнішнього середовища, які впливають на реалізацію
інвестиційної фази проєкту будівництва торгівельного центру.
Таблиця 1.2. PEST аналіз проєкту впровадження програмного продукту (ІС
для туристичних компаній).

Група
Фактор Опис
факторів
В 2021 році керівництвом планується
Політичне стабілізувати ситуацію. Планується ряд реформ,
Законодавст
середовище нових законів, які можуть суттєво вплинути на
во
розвиток ІТ галузі

Регулюва
ння Ризиком є зростання валютного курсу
міжнарод
ної
торгівлі
Економічні Економіч За оцінками експертів в 2021 році очікується
фактори не повільне стабілізування ринку нерухомості
зростан
ня
Радикальні зміни, які відбулися в політиці
оподаткування на 2020 рік, дозволяє вважати, що
Оподаткуван протягом 2020 року податкове законодавство буде
ня піддане ряду доопрацювань та змін у рамках моделі,
запропонованої
в Податковому Кодексі.

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

Політика досліджується, тому що вона регулює владу, яка в свою чергу
визначає середовище проєкту і отримання ключових ресурсів для його
16
реалізації. Основна причина вивчення економіки - це створення картини
розподілу ресурсів на рівні держави, що впливає на реалізацію проєкту. Не
менш важливі споживчі переваги
визначаються за допомогою соціального компонента PEST-аналізу. Останнім
чинником є технологічний компонент. Метою його дослідження прийнято
вважати виявлення тенденцій у технологічному розвитку, які часто є
причинами змін і втрат ринку, а також появи нових продуктів [3].
Таким чином, стратегічне управління проєктом створення інформаційної
системи управління турагенством дасть можливість забезпечити подання
процесів управління із необхідним ступенем деталізації, що дозволить
врахувати ряд додаткових (якісних) характеристик та формувати раціональні
рішення.
1.3 Концепція проєкту
Проєкт розробки ІС турагенства, що представляється нам, як прин-
ципово нова система, що автоматизує повний спектр обліку інформації, що
увібрала в себе багаторічний досвід групи програмістів і аналітиків СК
«Глобус».
Метою проєкту розробки ІС турагенства є підвищення ступеню
автоматизації роботи фірми в рамках єдиної архітектури на рівні, що не
уступає ведучим вітчизняним розробкам. Дерево цілей представлене на
рисунку (Рис. 1.4). Другорядною метою проєкту є створити ІС управління
туристичним агенством, щоб мати можливість продати її іншим фірмам чи
організаціям даної галузі, при чому, щоб дана ціль не зашкоджувала головній
меті проєкту для даної організації.
Впроваджена інформаційна система забезпечить такі можливості:
- підтримка організаційних процесів управління туристичним агентством
шляхом обміну, обробки інформації та прийняття рішень,створення
інфраструктури, що сприяє підняттю ефективності інформаційного
обміну;
- редагування лінії, аналізу інформації про туристичні тури, редагування
17
клієнтів, створення таблиць для автоматичного розрахунку вартості
турів;
- введення результатів, статистики, розрахунку вартості турів, отримання
детальної інформації по кожній касі (адреса, валюта, поштова
скринька, телефон),
для реєстрування програм і користувачів даної ІС і перегляду
фінансової статистики по кожній касі і фірми в цілому;
- контрольний центр для окремого регіону;
- перегляду лінії, результатів та статистики на Web-сайті, мати сервіси
для реєстрації на сайті, поповнення інтернет-рахунків, виплати,
прийому коштів через інтернет;
- блокування лінії, отримання інформація про клієнтів, отримати
інформацію про фінансові операції фірми.

Рисунок 1.2 Дерево цілей
Дерево цілей має чотири рівні завдань. Опис та шляхи досягнення цілей
18
пред ставлені в таблиці (Табл. 1.3)
Таблиця 1.3 Опис та шляхи досягнення цілей
Вага
Код цілі
Ціль Шляхи досягнення
Створення конкурентно
здатного програмного Розробити програмний продукт для
С 1
продукту

Розробити технічний комплекс разом з ор-
С11 Розробка АРМів працівників 0,15
ганізаційно-технічними регламентами
С12 Створення WEB сайту Розробити WEB сайт 0,20

Розробка продукту у відповідності до
С21 Розробка якісного продукту 0,05
стандартів
Мінімізація витрат на підт- Просування через пошукові системи та
С22 0,45
римку соціальні мережі
Розробка програмного за- Розробка фунціоналу із застосуванням
безпечення сучасних мов програмування
С111 0,15
Впровадження програмного Підтримки та навчання персоналу
продукту
С112 0,08
Розробка Front end Розробтити інтерфейс для взаємодії між
користувачем і back end
С121 0,15
Розробка back end Розробити бази даних та функціонал
С122 0,07
Забезпечення належного рі-
вня якості за допомогою те- Проведення тестування, розробка тестової
С211 0,12
стування та тестової доку- документації
ментації
Забезпечення коректності та Перевірка функціоналу, пошук багів
надійності розробки
С212 0,08

Забезпечення стабільного
С221 Розробка точних проєктних рішень 0,35
функціонування продукту
Впровадження покращень та необхідних змін
С222 Розвиток продукту 0,10
19
За класом проєкту (складом і структурою самого проєкту та його
предметної галузі) проєкт розробки ІС турагенства є:
1) за класом – монопроєкт;
2) за типом – економічний;
3) за видом – інвестиційний;
4) за тривалістю – короткостроковим;
5) за масштабом – середній;
6) за ступенем складності – простий.
Вимоги до результату проєкту:
− Результатом проєкту повинна бути веб-орієнтована інформаційна
система, що базується на рішенні для персональних комп’ютерів;
− Продукт повинен надавати можливість простого і швидкого
керування проєктом, його документацією та власним часом проєктного
менеджера;
− Система повинна мати інтуїтивно зрозумілий інтерфейс;
− Система має бути готовою до змін та покращень;
− Продукт має містити мінімальну кількість багів та помилок.
Учасники проекту:
В даному проекті до команди проекту відносимо: головний розробник, 3
розро бника,QA- інженер, QS –інженер, системний адміністратор, дизайнер
сайту (OBS проекту в Додатку А) .
Особливості проєкту:
− Продукт проєкту є простим у використанні;
− Проєкт є досить короткочасним для проєктів подібного типу.
Альтернативні реалізації проєкту:
− Головною альтернативою такого проєкту є розробка продукту як
десктоп- ну версію, що могло би надати користувачам більше надійності та
безпеки системи, але робить систему менш гнучкою та дорожчою в розробці.
20
Окрім вище названих характеристик проєкту можна також виділити
характеристику споживачів результату проєкту.
Як свідчать дослідження в галузі комунікацій, проведені зарубіжними та
вітчизняними науковцями, на різні групи споживачів реклама впливає по-
різному. Тому в економічно розвинутих країнах більше не орієнтуються на
якогось середньостатистичного індивіда. Зараз увесь рекламний процес
спрямовано на конкретну людину, яка входить до певної групи людей,
подібних до неї.
Реклама більше не обіцяє людині задоволення якихось глобальних
бажань, не породжує в неї солодких мрій про суспільство «білих кадилаків».
Сучасна реклама пропонує саме той спосіб (стиль) життя, який цінує в даний
момент конкретна група споживачів або навіть країна в цілому. Реклама
послідовно домагається свідомого сприйняття покупцем рекламного
звернення і свідомого здійснення покупки.
Споживач — основна особа в маркетингу. Уся політика маркетингу
полягає, врешті-решт, у спрямуванні дій безпосередньо на кінцевого
споживача. Широкий спектр засобів рекламування створюється з однією
метою — найефективнішим способом залучити кінцевого споживача та
максимально задовольнити його запити. Усі інші об’єкти рекламного впливу
(наприклад, торгівля) є лише допоміжними, і вплив на них здійснюється
тільки для посилення тиску на споживача [18].
Радники — це особи, які завдяки своєму авторитетові, соціальному
стану, професії можуть справляти вирішальний вплив на придбання товару
(послуг) іншими особами. За характером споживання покупці підроз-
діляються на дві категорії: покупці товарів широкого вжитку та покупці
(споживачі) товарів проми- слового призначення. Оскільки попит на товари
промислового призначення майже на 90 % визначається попитом на товари
широкого вжитку, головним об’єктом ре- кламного бізнесу є покупець товарів
широкого вжитку. В економічно розвинутих країнах процес наукового
обґрунтування споживчого попиту пройшов три етапи. На першому етапі
бралися до уваги в основному соціально-демографічні, географічні критерії
22
та критерії матеріального забезпечення й рівня споживання. Споживачів
групували за такими ознаками: стать, вік, соціально-професійна належність,
місце проживання, район, кількість членів сім’ї, кількість дітей,
забезпеченість окремими видами товарів, рівень споживання товарів особис-
того попиту, рівень використання засобів масової інформації [19].
Висновки до розділу 1
В першому розділі досліджено предметна сфера, ідея та можливості
реалізації проекту створення інформаційної системи управління тураген-
ством, розроблено концепцію проекту, здійснено PEST та SWOT аналізи
проекту. Сформовано резюме проекту створення інформаційної системи
турагенства, де описано мету проекту, оточення та учасники проекту, інвес-
тиційні можливості та продукт проекту. Ро зроблено цільове дерево проекту,
сценарій його реалізації на основі сценарно- цільового методу
23
РОЗДІЛ 2. ГАЛУЗІ ЗНАНЬ З УПРАВЛІННЯ ПРОЄКТАМИ
2.1 Управління інтеграцією та інформаційним зв’язком в проєкті
Управління інтеграцією проєкту (Project Іntegratіon Management) –
розділ проєктного менеджменту, що включає процеси, необхідні для забез-
печення координації різних процесів управління проєктами. Інтеграція
включає в себе такі процеси як визначення, уточнення, комбінування, об’єд-
нання та координацію різних дій щодо управляння проєктом.
Управління інтеграцією проєкту складається з таких компонентів [23]:
− розробка плану проєкту – створення підсумкового структурованого
документу на підставі даних, отриманих на попередніх етапах планування;
− визначення критеріїв успіху – розробка критеріїв оцінки виконання
проєкту;
− виконання плану проєкту – реалізація плану проєкту шляхом
виконання робіт, які ввійшли до нього;
− загальне управління змінами – координація змін за всіма
параметрами проєкту.
Для визначення процесу інтеграції проєкту необхідно також виділити
групи усіх процесів управління проєктом. Їх можна поділити на 5 груп [36]:
1) група процесів ініціації (initiating process group) – процеси, які
виконуються визначення нового проєкту або нової фази існуючого проєкту
шляхом отримання дозволу щодо початку проєкту або фази;
2) група процесів планування (planning process group) – процеси,
необхідні для визначення загального змісту проєкту, уточнення цілей
та визначення послідовності дій задля досягнення цілей проєкту;
3) група процесів виконання (executing process group) – процеси, які
застосо- вуються для виконання робіт, визначених в плані управління
проєктом задля задоволення специфікації проєкту;
4) група процесів моніторингу та контролю (monitoring and controlling
rocess group) – процеси, необхідні для відстеження, аналізу та регулювання
ходу та ефек- тивності виконання проєкту, виявлення тих областей, щодо яких
24
необхідно внести зміни в план, а також ініціація відповідних змін;
5) група процесів завершення (closing process group) – процеси, які
виконуються для завершення всіх дій в межах всіх груп
процесів та формального завершення проєкту або фази.
Управління інтеграцією проєкту Project Management Assistant можна
зобразити за допомогою таблиці 2.1.
Таблиця 2.1Управління інтеграцією

Група процесів Заходи
Процеси ініціації Визначення залученого до проєкту
персоналу, попередній опис проєк-
ту
Процеси планування Проведення вартісної оцінки,
визначення обсягу проєкту, пла-
нування бюджету проєкту
Процеси виконання Набір команди для реалізації проєк-
ту згідно визначеного плану та
бюджету
Процеси моніторингу Моніторинг ринку та процесу ро-
зробки
Процеси завершення Закриття проєкту чи віхи
В свою чергу, управління інформаційними зв’язками (управління ко-
мунікаціями) проєкту забезпечує підтримку системи зв'язку (взаємодій) між
учасниками проєкту, передачу управлінської і звітної інформації,
направленої на забезпечення досягнення цілей проєкту. Кожен учасник
проєкту має бути підготовлений до взаємодії в рамках проєкту відповідно до
його функціональних обов'язків.
Функція управління інформаційними зв'язками включає наступні процеси
[38]:
− планування системи комунікацій – визначення інформаційних
25
потреб учасників проєкту (склад інформації, терміни і способи доставки);
− збір і розподіл інформації – процеси регулярного збору і
своєчасної доста вки необхідній інформації учасникам проєкту;
− оцінка і відображення прогресу – обробка фактичних результатів
стану робіт проєкту, співвідношення з плановими і аналіз тенденцій,
прогнозування;
− документування ходу робіт – збір, обробка і організація зберігання
формальної документації по проєкту.
Технології або методи розподілу інформації між учасниками проєкту
можуть значно розрізнятися залежно від параметрів проєкту і вимог системи
контролю. Вибір технологій взаємодій визначається: мірою залежності успіху
проєкту від актуальності даних або детальності опису; доступністю
технологій; кваліфікацією і підготовленістю кадрів.
План управління комунікаціями включає [21]:
− план збору інформації, в якому визначаються джерела інформації і
методи її здобуття. План розподілу інформації, в якому визначаються
споживачі інформаціїі методи доставки;
− детальний опис кожного документа, який має бути отриманий або
переданий, включаючи формат, вміст, рівень детальності визначення, які
використовувалися;
− розклад і частота взаємодій;
− метод внесення змін в план комунікацій.
Залежно від потреб проєкту, план комунікацій може бути більш менш
формалізований, деталізований або описаний лише в загальному вигляді.
План ко- мунікацій є складовою частиною плану проєкту. Процеси збору і
обробки даних про досягнуті результати, фактичні витрати та відображення
інформації про стан робіт у звітах забезпечують основу для координації робіт,
оперативного планування та управління.

26
2.2 Управління змістом проєкту (WBS - структура)
Структура робіт проєкту – ієрархічна структура, що розділяє роботи
проєкту на групи, підгрупи, фази і т.д.(називається WBS – структура проєкту).
По своїй природі структура робіт є ієрархічної, і призначена для повноти
опису проєкту і відстеження змін складу і змісту робіт, що відбуваються в
ньому.
WBS– структура – це перелік робіт, які необхідно виконати по проєкті
[39]. Для її побудови необхідно провести декомпозицію робіт. Її можна
здійснювати різними способами: або по життєвому циклі проєкту, або по
змісту продукту (те, що ми хоче мо в результаті одержати). У будь-якому
випадку, спочатку виділяються блоки робіт, що у міру розробки WBS –
структури необхідно деталізувати.
Переміщення від верхніх рівнів до нижнього означає перехід до більш
детального опису робіт проєкту. Деталізація робіт проводиться доти, поки по
кожній роботі стане можливим здійснення безпосереднього контролю, тобто
призначення відповідального за її виконання.
Часто використовують ітераційний похід для створення WBS –
структури, що полягає в тім, що на початковому етапі не завжди можна
детально описати всі роботи з проєкту. Однак вартість проєкту визначається
через вартість його робіт. Тому при визначенні вартості проєкту на первісному
етапі відбувається груба оцінка блоків ро- біт з обов'язковим обліком
погрішності (за згодою Замовника).
Після того, як декомпозиція робіт проведена, можна говорити про
наявність ієрархічної структури робіт. Після цього приступають до
календарного планування проєкту, тобто встановлюють зв'язку між роботами,
оцінюють тривалість кожної роботи, а також визначають обмеження на
терміни початку і закінчення проєкту, фаз, окремих робіт при необхідності. У
результаті можна одержати графік Ганта – горизонтальну лінійну діаграму, на
якій роботи проєкту представлені протяжними в часі відрізками з датами
початку і закінчення.
27
Для виконання цих дій існують спеціальні програмні продукти,
наприкладM icrosoft Project.
В даному проєкті створення WBS-структури використовувалася програма
Microsoft Project 2010 (див. додаток Б). Також WBS – структуру можна
представити в вигляді таблиці 2.1
Таблиця 2.2 WBS – структура проєкту

Роботи проєкту
1. Старт проєкту
2. Підготовчі роботи
2.1 Закупівля комп'ютерів та меблів
2.2 Розміщення меблів і комп'ютерів
2.3 Закупівля сервера та WEB-сервера
2.4 Купівля ліцензійного ПЗ
2.5 Установка ПЗ
3. Аналіз
3.1 Визначення цілей ІС
3.2 Визначення основних вимог
3.3 Визначення основних ризиків
3.4 Складання початкового плану робіт
3.5 Документація
Роботи проєкту
4. Проєктування
4.1 Формування плану розробки ІС
4.2 Розробка структури бази даних
4.3 Розробка архітектури ІС
4.4 Розробка методів боротьби з ризиками
5. Реалізація
5.1 Створення бази даних
5.2 Створення програми «офісу для туристичних компаній»
5.2.1 Реалізація редактора турів
5.2.2 Реалізація аналізу турів
28
5.3 Створення сайту
5.3.1 Створення дизайну сайту
5.3.2 Реєстрація на сайті
5.3.3 Реалізація поповнення рахунку
5.3.4 Реалізація грошових операцій
5.3.5 Реалізація перегляду турів
5.4 Створення контрольного центру
5.4.1 Реалізація введення результатів
5.4.2 Реалізація розрахунку вартості туру
5.4.3 Реалізація управління і реєстрацію клієнтів
5.4.4 Реалізація перегляду фінансової статистики
5.5 Створення програми прийому коштів
5.6 Створення програми регіонального офісу
5.7 Створення програм для інтернет-диспетчера
5.7.1 Реалізація отримання інформації про клієнтів
5.7.2 Реалізація прийому коштів
6. Тестування
6.1 Альфа - тестування
6.1.1 Визначення основних недоліків
6.1.2 Усунення помилок
6.1.3 Внесення змін
6.2 Бета - тестування
6.2.1 Визначення основних недоліків
6.2.2 Усунення помилок
Роботи проєкту
6.3 Підготовка документації для користувачів
7. Впровадження
7.1 Установлення нової інформаційної системи
7.2 Навчання користувачів

2.3 Управління трудовими ресурсами в проєкті
При управлінні ресурсами в проєкті ІС повинне бути зроблено дві
перевірки зв'язані з дослідженням його забезпечення ресурсами. У
найпростішому виді це означ ає, що планування персоналу в проєкті враховує
деякі основні реалії [6].
29
Перша реалія в тім, що розподіл людей по задачах враховує той факт,
що люди можуть працювати тільки п'ять днів у тиждень, і що є визначені
періоди (вихідні, свята, відпустки), коли вони не працюють. Таким чином, ви
повинні перевірити, що вра ховано вплив:
- щорічних відпусток (особливо для проєктів, що йдуть улітку);
- свят;
- довгих вихідних;
- сезонних відпусток.
Також варто дивитися з деякою підозрою на проєкти або етапи проєктів,
що закінчуються в суботи і неділі. Вони можуть мати на увазі, що деякі
основні речі не бу ли продумані.
Отже в проєкті планується розподіл людей на задачі, так щоб людина
виконувала поставлену задачу, тоді коли в неї немає відпустки чи вихідного.
Тому при пла-нуванні часу виконання задач проєкту необхідно враховувати
розподіл ресурсів.
Друга перевірка складається в контролі, що проти кожної задачі в плані
проєкту коштує ресурс. Якщо справа обстоїть не так, це не обов'язково
проблема за умови, що десь у плані закладені такі роботи, як, наприклад,
найму персоналу, внутрішні переходи, узгодження субпідрядних договорів, і
так далі – імена цих людей, що надає.
Отже в проєкті план розподілу ресурсів складається так, що напроти
кожної задачі стояв відповідний ресурс (по можливості не повинно стояти
містерів Х чи ресурс У в плані). Якщо на початку планування не вдається
розподілити всі ресурси, то необхідно розподілити по можливості точніше
ресурси на початкові задачі проєкту, а потім розподіляти ресурси протягом
проєкту, коли є більш точна інформація на задачі проєкту.
Дуже ефективний шлях з'ясування того, що проєкт був запланований і
продуманий належним образом, складається в перевірці розподілу
працезатрат і робітника графіка за часом життя проєкту. Порівнюючи цей
30
розподіл з аналогічними параметрами попередніх закінчених проєктів, ви
можете відчути точність, або її відсутність, в оцінках у розглянутому плані.
Очевидно, проєкти сильно розрізняються в різних організаціях і навіть у
межах однієї організації. У силу цього розподіл працезатрат і робітника
графіка по життю проєкту також будуть розрізнятися.
На жаль, в області інформаційних систем усе ще вкрай рідко можна
знайти такід ані, не говорячи вже про їхню точність.
Третя перевірка заключається в тому, що коли ми маємо графік робіт,
ми повинні зробити розподіл людей по задачам, де деякі зразково підходять до
даної задачі, а інші в меншому ступені. Тепер треба розподілити задачі по
людям так, щоб проєкт був виконаний.
Який найкращий шлях для цього? Для будь-якої задачі із списку і для
будь- якого члена проєктної команди в команді є варіанти [4]:
1) дана людина може виконати дану роботу и хоче її робити (дана
категорія людей ідеал для проєкту, чим більше таких людей в
проєкті, тим більша ймовірність, що проєкт буде виконано вчасно);
2) може виконувати дану роботу и підготовлений, щоб робити її (від
даної категорії людей рідко коли з’являються проблеми в виконанні
задач проєкту);
3) може виконати дану роботу, але не підготовлений, щоб робити її (для
даної категорії людей необхідно в плануванні часу відвести час на
підготовку до виконання поставленої задачі);
4) може виконати дану роботу, але не хоче виконувати її (в даній
категорії людина, або виконувала багато разів дану роботу і їй зовсім
не цікаво виконувати, ще один раз дану роботу, або їй мало платять
за виконання поставленої задачі);
5) може бути навчений проінструктований, як виконувати дану роботу
(Наприклад, коли людина знає мову програмування, але даній
область вона не створювала програм і вона може легко бути
проінструктована по даній задачі і в результаті буде виконана
поставлена задача перед даною людиною);
31
6) не може виконувати дану роботу (Наприклад в проєкті є декілька
програмістів, один із них добре орієнтується в галузі інтернет, а
інший в офісній час- тині. Тому слід назначати на задачу по
створенню сайту ту людину, яка добре в цьому розуміється, якщо
назначити другу людину, то вона може або не виконати цю задачу,
або не вкластися в час виконання цієї задачі).
Отже в результаті розподілу ресурсів, необхідно розподілити по
можливості їх так, щоб люди, які виконували поставлену задачу відносилися до
категорії 1 або 2.
Також в проєкті для виконання поставленої задачі необхідно ресурси
такі, як WEB-сервер, інтернет (відноситься до задач пов’язаних с
написанням інтернет- сайту).
Отже в проєкті даний розподіл ресурсів зображено на сітьовому графіку,
листі ресурсів і працезатрат (див. додатки).
Кількість людей, які необхідно для проєкту вибираються за такими
ознаками:
1) від рівня знання програмістів і експертів;
2) від оцінки об’єму в проєкті;
3) від рішення прийнятих по головним ризикам;
Отже в проєкті ми маємо такі фази в проєкті, по яким необхідно
розділити ресурси:
1) Підготовчі роботи – в даній фазі створюється закупка всього
необхідного для проєкту, установка ПЗ, розміщення меблів та
комп’ютерів, всім цим займається системний адміністратор СК
«Глобус».
2) Аналіз – для даної фази два експерти в галузі створення ІС, головний
аналі тик СК «Глобус» і головний програміст, 4 комп’ютери, меблі (4
комплекти) та інтернет необхідний для роботи проєктної команди;
3) Проєктування – в даній галузі необхідно головний програміст,
програміст та 2 комп’ютери, меблі (2 комплекти) та інтернет.
32
4) Реалізація – для даної галузі необхідно такі ресурси: головний
програміст, 3 програмісти, дизайнер сайту, інтернет і ще 5
комп’ютерів, меблі (5 компле ктів), сервер та WEB-сервер ліцензійне
програмне забезпечення.
5) Тестування – для даної галузі такі необхідні ресурси 3 програмісти,
головний програміст, 4 комп’ютери, меблі (4 комплекти) та інтернет.
6) Впровадження – для даної галузі необхідно ресурсів: системний
адміністратор та головний програміст, 2 комп’ютери, меблі (2
комплекти) та інтернет.
В кожній фазі також необхідно комплект меблів і комп’ютерної техніки
керівнику проєкту.
2.4 Управління вартістю проєкту
Управління вартістю проєкту зв'язане з одним із трьох основних
обмежень у проєктах - по вартості, термінам і вимогам до предметної області.
Дотримання всіх цих обмежень дозволяє завершити проєкт у рамках
запланованих термінів і бюджету при повному задоволенні визначених раніше
чекань замовника, (тобто при повному досягненні всіх заздалегідь визначених
результатів)
Основна мета управління вартістю проєкту полягає в тому, щоб завершити
його в рамках затвердженого бюджету.
Затверджений бюджет проєкту 580 тис. грн.
Керівник проєкту в першу чергу заклопотаний управлінням прямими
витратами проєкту, але сучасна тенденція в керуванні проєктами веде до того,
що його роль у керуванні вартістю проєкту буде зростати за рахунок усе
більшого включення нетра диційних областей управління вартістю. Можна
припустити, що в майбутньому усе більше керівників проєктів будуть мати
справа з управлінням непрямими витратами і витратами по проєктах.
При цьому незалежно від того, за що конкретно відповідає керівник
проєкту, критично важливо, щоб його робота оцінювалася по тим і тільки тим
показникам, за які він несе відповідальність. Наприклад, якщо керівник
33
проєкту не відповідає за вар тість матеріалів у проєкті, то немає ніякого сенсу
оцінювати його роботу з цього по- казника.
Для обліку витрат також досить важливо установити відповідний
часовий порядок збору фактичних даних по витратах. Бюджет проєкту
повинний бути синхронізований із процедурою їхнього збору. Наприклад,
якщо керівник проєкту відповідає за вартість матеріалів, то необхідно
визначити, коли в бюджеті повинний бути показана витрата. Чи повинно це
відбуватися при прийнятті керівником проєкту рішення про покупку, або при
постачанні купленого? А може бути, варто фіксувати витрата після
завершення приймання купленого, або в момент, коли покупка оплачується?
Подібні проблеми можуть перетворити управління вартістю проєкту в
кошмар.
Таким чином, якщо в проєкті не здійснюється відповідне керування
вартістю, то він обов'язково вийде з-під контролю, і для його завершення буде
витрачено більше грошей, чим передбачалося. Управління вартістю проєкту
націлене саме на зап бігання такої ситуації.
Отже для визначення вартості проєкту потрібно знати вартість
складових ресурсів проєкту, час виконання робіт і вартість цих робіт. Таким
чином, оцінка вартос- ті проєкту починається після визначення робіт проєкту і
структури необхідних ресур- сів. Контроль вартості проєкту здійснюється в
процесі реалізації проєкту такими методами як аналіз освоєного обсягу,
прогнозування витрат і іншими. Отже, що обрахувати вартість проєкту
необхідно просумувати:
1) Зарплата проєктної команди і керівника проєкту – 384 тис. грн.;
2) Вартість матеріальних ресурсів (WEB-сервер, сервера, офісні
меблі, комп’ютери) – 166 тис. грн.
3) Вартість за оренду та інтернет-послуги – 10 тис. грн..
2.5 Управління якістю проєкту
Проєкт по створенню інформаційної системи (ІС) підприємства завжди
включає безліч задач, зв'язаних із загальним управлінням проєктом,
розробкою ПО, проєктуванням ІС, упровадженням ERP-системи, кожна з яких
34
сама по собі є проєктом із властивими йому особливостями.
Як правило, вести такі проєкти без реально діючої системи управління
якістю практично неможливо. Навіть якщо на початковому етапі компанії, що
взялися за реалізацію проєктів, не задумуються про це, усвідомлення
необхідності системи управ- ління якістю проєкту приходить досить швидко.
Особливо, коли проблеми управління починають рости з кожним днем у
геометричній прогресії [24].
Загальні методичні вказівки по управління якістю проєктів дані в ISO
10006:1996 "Адміністративне управління якістю. Провідні вказівки по
забезпеченню якості при управлінні проєктом" [20], ISO 10007:1995
"Адміністративне управління якістю. Провідні вказівки по управлінню
конфігурацією" [21]. По управління якістю проєктів в області інформаційних
технологій (ІТ-проєкти) існують спеціалізовані стандарти, наприклад,
стандарти COBIT або корпоративний стандарт Microsoft MSF. Але великі
проєкти мають три основні особливості.
Перша – зміна задач у ході проєкту [25]. Цим "страждають" ІТ-проєкти,
але великі наслідки бувають особливо важкими. Часто первісна постановка
задачі істотно міняється в ході проєкту. Крім того, при впровадженні
проєктних рішень необхідна реорганізація діяльності замовника, при цьому
постійно повинні уточнюватися і коректуватися функціональність
розроблювальної системи і відслідковуватися потреби замовника при зміні
його бізнесів-процесів. Як правило, будь-яка некерована зміна у
функціональності створюваної ІС або роботах, здійснюваних у рамках
проєкту, істотно позначається на якості проєктних рішень і може взагалі
привести до краху проєкту. І це необхідно враховувати при керуванні
проєктом.
У проєкті для того, щоб не виникали різкі зміни у головній цілі, було
проведено детально збір інформації від кожного замовника проєкту і опис
необхідних вимог до ІС, оскільки в даному проєкті по створенню ІС для
туристичних компаній, замовниками виступають працівники фірми СК
«Глобус».
35
Друга – рівнобіжне ведення робіт різними проєктними групами [25].
Наприклад, одночасно можуть виконуватися роботи з ескізного проєктування
всієї ІС, розроблятися ПО, що забезпечує інтеграцію існуючих ІС
підприємства з розроблювальною системою, вестися впровадження окремих
модулів ERP-системи. У сполученні з першою особливістю це може викликати
лавиноподібний ріст працезатрат в проєкті.
Тим самим паралельність і багатоплановість робіт, виконуваних у
проєкті по розробці і впровадженню ІС, багаторазово збільшує імовірність
виникнення ризиків невдалого завершення проєкту. Одна з важливих задач
управління якістю проєкту – домогтися, щоб до моменту його завершення
"зрослися" усі компоненти системи і були виконані вимоги замовника по
функціональності, термінам і вартості системи.
Як видно с WBS – структури проєкту ми маємо декілька робіт, які
ведуться паралельно, щоб в результаті не було того, що один модуль не
працює разом з іншим, була проведене детальне планування архітектури
системи експертами і програміста ми проєкту.
Оскільки в новостворюваній ІС для туристичних компаній до десятка
програм і кожна повинна відповідати вимогам замовника, необхідно було
ведення уточнень вимог замовника до початку проєкту.
Третя – дуже великі ризики як для замовника, так і для виконавця
проєкту [25]. У даній роботі ризик – це добуток величини збитку (зміна
термінів проєкту, працезатрат і т.д.) на імовірність його виникнення. Ризики
замовника зв'язані з неповним досягненням цілей проєкту і не ефективно
витраченими засобами, а ризики виконавця – з можливістю різкого
перевищення фактичної собівартості робіт з порівняння з планової.
Причинами перевищення є саме перша і друга особливості. Необхідність ве-
дення рівнобіжних і часом що принципово відрізняються за своїм характером
робіт приводить до того, що багаторазово зростає рівень ризику проєкту.
Зрозуміло, що реакція замовника на 20% зміни працезатрат виконавця в
проєкті вартістю 20 тис. грн. і у проєкті буде різною. При цьому сучасний
замовник не дозволяє виконавцеві страхувати ризики за рахунок великого
36
"зазору" між ціною конт ракту і собівартістю робіт.
Дана особливість буде розглянута більш детально в іншому розділі.
Також при управлінні якості проєкту по створенню ІС, необхідно
приділити увагу якості самої ІС. Основні показники якості ІС для
туристичних компаній: надійність, коректність, зручність застосування,
ефективність, універсальність і супро воджуваність. Для аналізування даних
показників і виправлення помилок відведено в проєкті такі етапи проєкту, як
тестування, як користувачем так і самою проєктною групою.
2.6 Управління закупівлями в проєкті
Управління закупівлями в проєкті включає процеси, необхідні для
придбання товарів та послуг за межами виконавчої організації.
Основними процесами управління закупівлями в проєкті є [28]:
– планування закупівель – визначення того, що і коли треба придбати;
– планування клопотань – документальне оформлення вимог до
продукту та визначення потенціальних джерел його отримання;
– клопотання – отримання тендерної документації, тендерних
пропозицій або інших слушних пропозицій;
– вибір джерела – вибір серед потенціальних продавців;
– адміністрування контракту – управління зв’язком з продавцем;
– закриття контракту – завершення і врегулювання виконання завдань
контракту, включаючи вирішення відкритих питань.
Планування закупівель – це процес визначення проєктних потреб, які
можуть задовольнятися найкращим чином з допомогою закупівлі товарів і
послуг за межами виконавчої організації. Він включає обговорення того, чи
варто закуповувати, як, що, скільки і коли [17].
Описання змісту проєкту включає описання поточних проєктних меж,
надає важливу інформацію про потреби та стратегії проєкту, які мають бути
розглянуті в процесі планування закупівель.
Описання продукту містить важливу інформацію про будь-які технічні
37
рішення або проблеми ,які необхідно розглянути в процесі планування
закупівель.
Ресурси закупівлі. Якщо виконавча організація не має офіційної групи
по роботі з контрактами, то члени команди проєкту повинні набути знань і
досвіду для підтримки конкретних робіт по закупівлі.
Умови ринку. При плануванні закупівель повинні бути враховані
асортимент товарів та послуг на ринку товаровиробника.
Обмеження. Обмеження – це чинники, що обмежують права покупця. В
нашому випадку обмеженням являються наявність грошових коштів.
Управління закупівлями в проєкті обговорюється з позиції покупця у
відношенні “покупець – продавець“. Таке відношення існує майже на всіх
рівнях проєкту [9, 53]. Продавець в даному проєкті називається
постачальником.
Основним методом планування закупівель є вибір типу контракту. В
проєкті використовується контракт з твердою ціною або з фіксованою
вартістю. Така категорія контракту включає загальну тверду ціну для
конкретного товару.
Планування клопотань включає підготовку документів, необхідних для
підтримки клопотань при управлінні закупівлями в проєкту. Основним
методом для планування клопотань є стандартні форми, які включають
стандартні контракти, стандартні описання елементів закупівлі,
стандартизовані версії всіх або частини необхідних документів по торгах.
Документи по закупівлі використовують для пропозиції – клопотань від
передбачуваних продавців. Вони структуровані, для того щоб сприяти
точним і повним відповідям від продавців (постачальників).
Для отримання повної оцінки при закупках визначаємо наступні критерії:
– розуміння потреби;
– загальна вартість, або вартість життєвого циклу, - чи буде
вибраний продавець надавати найнижчу вартість;
– технічні можливості;
– підхід до управління;
38
– фінансові можливості.
Процес клопотання включає отримання комерційних пропозицій від
потенцій них продавців про те, як можуть бути задоволені проєктні потреби.
Закупівлі, які необхідно зробити в проєкті для створення ІС для
туристичних компаній (які виконуються в фазі „Підготовчі роботи”, крім
інтернет-послуг):
- закупки матеріалів (меблі, ліцензійне програмне забезпечення);
- закупки обладнання (комп’ютери, сервер та Web-сервер);
- закупки послуг (інтернет-послуги).
Ресурсами нашого проєкту є:
- покупка CMS;
- покупка доменного імені;
- покупка хостингу;
- витрати на SEO просування;
- витрати на контекстну рекламу.
Всі клопотання щодо закупівель лежать на виконавцеві, який за свою
практику добре знайомий з цим ринком і може робити покупки по зниженим
цінам, як для постійного клієнта. А це, в свою чергу дозволяє знизити загальні
витрати для підприємства-замовника веб-послуг. І бере на себе всю
відповідальність за якість та доцільність куплених продуктів.
Для створення ІС дизайн-студія обрала Систему управління вмістом
(Content Management System – CMS). CMS - ефективна і надійна система
управління сайтами,
що дозволяє створювати, підтримувати і управляти інтернетом-сайтами
практично будь-якої міри складності.
Придбання доменного імені http://brandmania.com.ua та хостингу
дизайн-студія здійснює на першому в Україні, повністю автоматизованому
сервісі за наданням хостингу і реєстрації доменних імен. Особливістю
хостингу (http://www.ukraine.com.ua) є повна автоматизації всіх процесів,
пов'язаних не лише з реєстрацією доменів і хостингу, але і повною
автоматизацією роботи серверів і персоналу хостингу. За рахунок закладеної
39
в програмне забезпечення логіки ми досягається найбільша швидкість і якість
в наданні послуг. Напрям хостингу був відкритий в 2004 році, в більшості для
власних проєктів компанії і своїх клієнтів. З часом, кількість сайтів
розміщених на серверах виросло на стільки, що для управ- ління хостингом
потрібно було створити програмне забезпечення, що автоматизує роботу.
У основу хостингу "Україна" закладено унікальне програмне
забезпечення, якого немає ні в однієї української хостинг - компанії.
Користувачі можуть виконавати тонке налаштування хостингу, налаштувати
кожен сайт. Користувачі не обмежені єдиними налаштуваннями PHP, для
кожного сайту є можливість налаштувати ті параметри PHP, які потрібні для
більшості систем управління.
SEO просування забезпечує виведення сайту на перших позиціях
результатів пошуку в Google.
Контекстна реклама направлена на швидке (в порівнянні з пошуковим
просуванням сайту) збільшення цільової відвідуваності сайту або залучення
уваги користувачів.
Методи та засоби вибору джерела:
– переговори по контракту передбачають пояснення положень
контракту і взаємну угоду відносно структури та вимог контракту перед його
підписанням. Текст контракту має відображати всі досягнуті домовленості;
– система ранжування – спосіб кількісного подання якості даних,
спрямований на те, щоб мінімізувати вплив персональних переваг при виборі
джерела;
– система необхідних умов передбачає складання мінімальних вимог до
показників виконання за одним або більше критеріями оцінки.
Результатами вибору джерел є підписання контракту – угода, яка зв’язує
покупця сплачувати по ньому [8].
Адміністрування контракту – це процес забезпечення того, що
постачальник задовольняє показники контрактних вимог [17]. Юридична
сторона контрактних відносин вимагає, щоб всі учасники проєкту
усвідомлювали всі юридичні наслідки рішень, що приймаються при
40
адмініструванні контракту. Адміністрування контракту містить компонент
фінансового менеджменту. Строки оплати визначені в кон- тракті і
відображають певний зв’язок між виконанням його та виплатами по ньому.
Основні методи адміністрування:
– система контролю за змінами в контракті;
– звіти про виконання;
– система оплати.
Закриття контракту включає перевірку того, чи вся робота виконана
правильно та задовільно та коригування записів для відображення
підсумкових результатів і архівація цієї інформації з метою подальшого
використання.
Основним методом закриття контракту є аудит закупівлі –
структурований перегляд процесу закупівлі від стадії планування закупівлі до
адміністрування по контракту.
Для отримання інтернет-послуг вкладено контракт на поставку
інтернету протягом всього проєкту.
2.7 Управління ризиками проєкту
Управління ризиками включає планування менеджменту ризиків,
визначення стану і моніторинг ризиків. Поряд з оцінюванням ризиків ці
компоненти повинні підтримуватися наборами інструментів і методик. Під
час планування менеджменту ризиків використовуються інструменти по
одержанню інформації і методики, що дозволяють уникнути прояву ризиків.
Також застосовується передача, редукція елементів і інтеграція планування.
Виробляється підписання контрактів з консультантами - експертами по
основних питаннях, одержання інформації з баз даних.
У ряді публікацій [21-29] рекомендується модель управління
ризиками,в якій структура містить шість етапів, зміст яких охоплює ті ж
процеси, докладно відбиті на малюнку моделі. В описі виділені дві основні
проблеми управління ризиками складних програмних проєктів: проблема
менеджменту проєктів і проблема теорії управління проєктом. У цій моделі
виділені десять компонентів — найбільш важливих причин при керуванні
41
ризиками проєктів складних комплексів програм, для яких рекомендуються
процедури їхнього скорочення:
− недостатня кількість і кваліфікація колективу фахівців;
− нереальна оцінка необхідного часу реалізації проєкту і виділюваного
бюджету;
− дефекти і невизначеності при розробці вимог і основних функцій
комплексу програм;
− дефекти і помилки при розробці інтерфейсу для користувача і зв'язків
компоне нтів ІС;
− порушення базових (золотих) основ процесів розробки і твердих
вимог, відсутність прототипів, аналізу і проєктування витрат;
− безперервна зміна вимог, інформаційних зв'язків, розширення функцій
проєкту ІС;
− недоліки компонентів зовнішнього обслуговування і контролю,
аналізу суміс ності компонентів, рекомендацій і застосування зв'язків;
− недоліки засобів зовнішніх перетворень і взаємодії компонентів,
компетентного проєктування або прототипування;
− дефекти при забезпеченні процесів реального часу, моделюванні
прототипів, настроювання інструментів розробки і контролю;
− дефекти контролю обчислювальної техніки і відмовлення
функціонування комп'ютерів і системи.
Також існує модель управління ризиками з використанням 12 категорій
потен ційного ризику для визначеного проєкту. Для кожної категорії детально
представлені фактори, що впливають на ризики, і рекомендується
проводити їхньої оцінки по трьох рівнях можливого прояву (низька, середня,
висока очевидність погрози ризику), опису змісту й атрибутів яких представлено
у великій таблиці. План управління проєк тними ризиками для конкретного ІС
рекомендується моделювати категоріями [34]:
1) Задачі і цілі. Кожен схвалений проєкт ІС повинний займати відповідне
місце серед цілей і задач підприємства. Ті проєкти, що не відповідають
реальної цілям організації, створюють напруга, що впливає на всі проєкти.
42
Наприклад, зажадаємо, щоб існувала організація, у задачі якої входила би
розробка ІС для внутрішнього корпоративного виробництва, а ціль
складається в створенні найбільш ефективного, замовле- ного програмного
забезпечення для підприємств організації. Якщо підприємство при- ступить до
виконання проєкту по створенню пакета ІС загальної спрямованості і на
комерційній основі, то це може бути ризикованим заходом, що суперечать
поточним задачам, кваліфікації і цілям організації.
2) Організаційний менеджмент. Кожний з обраних проєктів повинний
вписуватися в поточну або плановану організаційну структуру. Якщо
організація не має подібну структуру або ж вона ще не створена, важко
розраховувати на успішну реалізацію програмного проєкту. Прикладом
подібних ризикованих формувань є торговельні організації, що припиняють
розробку проєктів без дотацій з боку виконуючих організацій. Проєкт
перекидається на інше підприємство по розробці, оскільки немає підхо- дящої
команди і відсутній процес формування необхідного типу системи.
3) Замовник. Усі проєкти повинні мати постійний зворотний зв'язок із
замовником. Проєкт розробки ІС вимагає великих вихідних даних, що можуть
представити замовники і кінцеві користувачі. Без подібних даних самий
удалий процес розробки приведе до формування тільки відмінно
функціонуючої системи, що не відповідає реальним запитам кінцевих
користувачів. Схований тут ризик складається в залученні в команду
недосвідчених співробітників, що не володіють адекватним досвідом з до-
зволу проблем, зв'язаних з конкретною предметною областю. Такі
співробітники не зможуть задовольняти необхідні технічні запити замовника і
розроблювачів ІС.
4) Бюджет/вартість. Саме дана категорія звичайно залучає найбільш
пильну увагу і впливає на всі інші категорії ризиків. Менеджери проєктів
зосереджують увагу на
бюджеті й обсягах витрат, оскільки саме ці важелі дозволяють задіяти
широкий
спектр можливостей, що приводять проєкт до успішного завершення. Для
43
зменшення ризику, що відноситься до цієї категорії, варто чітко представляти
розміри проєкту, мати у своєму розпорядженні достовірну передісторію про
роботу над подібними проєктами, а також мати досить повне представлення
про зовнішні впливи, наприклад, про технології.
5) Графік. Великий ризик полягає в тому, що команді розроблювачів
нав'язуються занадто тісні тимчасові рамки графіка робіт. Якщо розроблювачі
не можуть робити впливу на формування графіка і дати ключових етапів
проєкту, велика імовірність то го, що графік виконуватися не буде. Команди
розроблювачів ІС повинні брати участьу розробці проєктних графіків і мати
можливість вносити туди зміни.
6) Зміст проєкту. Усі проєкти генерують ті або інші особливості, що
доповнюють проєкт і утворять проміжні продукти. Одним з основних
компонентів є документація, що містить вимоги, відомості про проєктування,
про цільову систему і зовнішнє середовище. Якщо ця інформація відсутня,
можуть з'явитися помилки, або різко і непередбачено зросте ризик утрати
зведень, що утримуються в проєкті. Також може порушитися графік або
істотно постраждає вміст продукту.
7) Виконання. Ці фактори ризику відносяться до особливого періоду, коли
настає момент практичних іспитів розробленої системи і ІС. Однак саме ці
фактори ризику є ключовими для критерію по розробці програмного продукту.
Деякі з основних облас тей ризику відносяться до функціонування системи під
час тестування. Критичне значення має доступна можливість повного
тестування всіх модулів і їхніх інтерфейсів. Неадекватне тестування веде до
відмовлень при виконанні проєкту і відповідних ризиків.
8) Управління проєктом. Ця категорія відноситься як до процесу уп-
равління про ктом, так і до компетенції менеджера проєкту. Ризик існує не
тільки через недоліки, неадекватного трактування, процесів менеджменту, але
може бути також наслідком попереднього досвіду роботи менеджера проєкту.
Менеджери проєктів повинні мати досвід роботи з визначеною предметною
областю і мати представлення про процеси проєктного менеджменту в
життєвому циклі ІС.
44
9) Процеси розробки. Ця категорія фокусується на тих процесах, що
зменшують загальний ризик і поліпшують якість виробленого продукту. До
процесів розробки не відносяться специфічні інструменти, такі як мови
програмування, генератори коду. Розглянуті процеси фокусуються на
процесах конфігураційного менеджменту, практиках і методах забезпечення
якості і на аналізі альтернатив.
10) Середовище розробки. Дана категорія зосереджена на фізичному сере-
довищі можливостей, апаратних платформах і інструментах по розробці прог-
рамного продукту. Ризик виникає не тільки через недолік адекватних
інструментів, але і унаслідок відсутності адекватних можливостей їхнього
використання. Якщо команда не підібрана спеціально для рішення конкретної
задачі, відсутнє адекватний простір для вироблення угод, простір для під-
тримки інтерв'ю з замовником і робітники кімнати, ри- зик істотно зростає.
11) Персонал. Ця категорія є єдиної, де істотне зменшення ризику дося-
гається за рахунок набору досвідченої і високопродуктивної команди розроб-
лювачів ІС. Розроблювачі, що володіють високою робочою ефективністю, мо-
жуть у 10 і навіть у 25 ра- зів продуктивніше працювати, чим звичайна коман-
да. Непевність у можливостях ко- манди або в досвідченості її членів у сполу-
ченні з деякими особливостями предмет- них областей, сприяє фіксації
консеративного підходу до факторів ризику з цієї ка- тегорії.
12) Підтримка. Ця заключна категорія дозволяє кількісно оцінювати ризик,
зв'яза- ний із ІС, після постачання програмного продукту. Команда
розроблювачів проєкту часто несе відповідальність за підтримку програмного
продукту протягом визначено- го періоду після його постачання. Якщо ж це не
так, а недосвідчені користувачі нама- гаються фіксувати і виправляти помилки
в ІС, проєктний ризик істотно зростає. Інструменти, застосовувані для розроб-
ки, повинні бути доступні і на етапі підтримки. Підтримка постачальника піс-
ля випуску продукту характеризується наявністю ризику випуску, якщо відсут-
ній план або бюджет для реалізації інструментарію безперервної підтримки.
Рекомендується розробка плану управління ризиками, що складається з
п'яти етапів. Використовуючи попередній розподіл на 12 категорій ризиків,
45
пропонується виконати ранжирування і відсортувати ризики таким чином, щоб
ними можна було керувати в конкретному проєкті. Потім розглянутий план
скомпонувати в процесі ідентифікації потенційних погроз і ризиків, уведення
їхніх категорій і встановлення пріоритетів.
Етап 1. Використовуючи описані категорії ризиків, рекомендується
створити таблицю категорій. Команда розроблювачів може скористатися цією
таблицею для огляду категорій ризиків даного проєкту. Також команда
повинна сформувати інформацію про набір факторів і погроз для вивчення.
Таблиця категорій ризиків повинна містити зведення про те, які фактори
ризиків більш реальні і наскільки вони очевидні. Якщо підприємство має у
своєму розпорядженні методи роботи з цими факторами, можна порівняти
їхні рейтинги в даному проєкті з рейтингами в проєктах, що розроблялися
раніше. Можна використовувати підхід, заснований на всеосяжному рейтингу,
або фіксувати увага на визначеній кількості найбільших ризиків або ж
комбінувати кількість ризиків і ступінь їхнього впливу, прогнозуючи успіх
або невдачу проєкту. Дана таблиця є відправною крапкою при ідентифікації
визначених ризиків у кожнім проєкті.
Етап 2. Ранжуються ризики, зв'язані з виконанням проєкту, по категоріях:
− фактори ризику й області — для кожної категорії в стовпці
перелічуються фактори і погрози категорії ризику;
− виділяється низька очевидність ризиків — цей стовпець характеризує
фактори щодо невисокої імовірності і малих наслідків ризику для
проєкту;
− середня очевидність ризиків — стовпець характеризує фактори, що
мають се редню імовірність, і наслідку ризиків для проєкту;
− висока очевидність ризиків — виділяються фактори, коли імовірність і
негати вні наслідки ризику для проєкту досить великі;
− визначення рейтингу — виділення рівня інтегрального ризику,
припустимогод ля даного проєкту;
− коментарі — підтримується інформація про особливості проєкту, що
дозволяє дотримувати обраний рейтинг.
46
У деяких випадках очевидний прояв ризику однієї категорії може
характеризуватися як високе, а іншої — як низьке. У приведена таблиця
факторів ризику і категорій, для яких очевидність ризику характеризується
відповідно як низька, середня або висока. Дана таблиця може служити
шаблоном, використовуваним як відправну крапку для розробки проєкту
програмного продукту. Категорії, фактори й очевид- ність ризиків можна
обновляти для будьякого проєкту в межах розглянутої схеми.
Етап 3. Виконується сортування таблиці ризиків, розташовуючи них у
порядку убування очевидності і погрози. Спочатку перелічуються ризики з
найвищою очевидністю. Обчислюється інтегральний ризик для найбільших
десяти ризиків, а також для всіх ризиків, відзначених як високі, якщо їх більше
десяти. Саме вони і будуть ключовими. Ідентифікуються засоби для контролю
кожного ключового ризику, установлюється відповідальність за його
скорочення і дата виконання. Інтегруються ключовір изики в план проєкту, і
уточнюється їхній вплив на графік і розмір витрат.
Етап 4. Установлюється формат звіту для кожного регулярного ризику.
Цей звіт рекомендується заслуховувати на щотижневих зустрічах колективу
фахівців, де розглядається стан проєкту. Показується стан найбільших десяти
ризиків, зміни в ранжируванні для кожного ризику за останній тиждень.
Відображається звіт відгуків- контрзаходів про ризики і про їхні зміни.
Етап 5. На заключному етапі варто упевнитися, що управління і
скорочення ризиків є безперервним процесом у рамках життєвого циклу
проєкту ІС. Відстеження і контроль ризиків, включених у список, повинні
виконуватися на регулярній основі. Менеджер проєкту і всі члени команди
повинні звертати увагу на поводження ідентифікованих ризиків, а також
контролювати процеси їхнього визначення. Нові ризики повинні
ідентифікуватися, насамперед, для них визначаються пріоритети, що потім
додаються в план управління ризиками. Ризики з високим пріоритетом варто
обробляти відповідно до загального плану проєкту ІС.
Технічні ризики визначаються вимогами й особливостями об'єкта —
програмного за собу і включають [37]:
47
− функціональні характеристики;
− характеристики якості;
− надійність;
− застосовність;
− тимчасову продуктивність;
− повторне використання
компонентів. Вартісні ризики
складають:
− обмеження сумарного бюджету;
− недоступна, фіксована вартість проєкту ІС;
− ступінь реалізму при оцінюванні витрат на
проєкт ІС. Планові ризики включають [38]:
− властивості і можливості гнучкості зміни планів;
− можливості порушення установлених віх — термінів етапів;
− реалізм планів і етапів життєвого циклу.
Крім того, виділені ризики процесів і процедур управління проєктом, які
можна віднести до основних перерахованих елементів ризиків:
− ризики ідентифікації;
− ризики стратегії і планування проєкту;
− ризики оцінок;
− припустимі результуючі ризики при скороченні або усуненні погроз;
− ризики документування;
− ризики прогнозування розвитку й удосконалювання проєкту.
Загальні методи аналізу ризиків у складних системах регламентовані
стандартом ДСТ Р 51901 — Управління надійністю. Аналіз ризику
технологічних систем [17]. Основною задачею стандарту є обґрунтування
рішень, що стосуються аналізу ризику реалізації проєктів і технологій
складних систем. Викладені в стандарті рекомендації можуть бути, зокрема,
застосовані при техніко-економічному обґрунтуванні і розробці проєктів
комплексів програм. Нижче представлені основні концепції і скорочений
зміст цього стандарту, адаптовані для можливості застосування його поло-
48
жень при аналізі ризиків проєктів програмних засобів. Для підвищення
ефективності управління проєктами рекомендується проводити аналіз ризику,
що включає:
− ідентифікацію ризику і визначення методів рішення зв'язаних з ним
проблем;
− використання об'єктивної інформації при прийнятті рішень для
скорочення ризиків;
− задоволення регламентованих вимог замовника до припустимого ризику.
− Застосовуваний метод аналізу ризику повинний бути:
− науково обґрунтованим і відповідати функціям, характеристикам і
складності досліджуваної системи;
− давати результати у формі, що забезпечує розуміння природи погроз,
властиво стей ризику і способів його контролю;
− типовим і мати властивості, що забезпечують прослідковуваність,
повторюва ність і контрольованість результатів аналізу.
Елементи процесу оцінки величини ризику є загальними для усіх видів
небезпеки. Насамперед, аналізуються можливі причини небезпеки з метою
визначення час тоти її виникнення, тривалості, а також характеру. У процесі
аналізу може виникнути необхідність визначення оцінки імовірності
небезпеки, що викликає негативні наслідки, і проведення аналізів
послідовності подій, що обумовлюють.
Аналіз частот використовується для оцінки імовірності кожної негативної
події, що проявились на стадії ідентифікації небезпек, погроз. Для оцінки
частот подій, що від буваються, звичайно застосовуються наступні три методи:
− використання наявних статистичних даних (передісторії);
− одержання частот негативних подій на основі аналітичних або
імітаційних ме тодів;
− використання думок експертів.
Дані експлуатації використовуються з метою визначення частоти, з
яким негативні події відбувалися в минулому, і, виходячи з цього,
прогнозування частоти, з яким вони можуть відбутися в майбутньому. У тому
49
випадку, коли статистичні дані недоступні або не відповідають вимогам до
системи, можна одержувати частоти подій за допомогою аналізу структури і
змісту системи і її аварійних станів. При проведенні аналізу частот можуть
використовуватися методи імітаційного моделювання відмовлень. Існує ряд
методів для зіставлення експертної думки, що виключають дво-
значність оцінок, допомагають при постановці відповідних питань.
Існує безліч невизначеностей, зв'язаних з оцінкою ризику. Розуміння
невизначеностей і зухвалих їхніх причин необхідно для ефективної
інтерпретації значень ризику. Аналіз невизначеностей повинний передбачати
визначення змін і неточностей у результатах моделювання, що є наслідком від-
хилення параметрів і припущень, застосовуваних при побудові моделі.
Областю, тісно зв'язаної з аналізом невизначеностей, є аналіз чутливості.
Аналіз має на увазі визначення змін у реакції моделі на відхилення окремих
параметрів моделі. Оцінка невизначеності складається з перетворення не-
визначеності критичних параметрів моделі в невизначеність результатів
відповідно до моделі ризику. Це відноситься як до невизначеностей даних, так
і до невизначеностей моделі. Повинні бути визначені ті параметри, до яких
чуттєвий аналіз.
Вибрана розробка плану управління ризиками, що складається з п'яти
етапів, використовуючи 12 категорій ризиків. Потім необхідно виконати
ранжирування і відсортувати ризики таким чином, щоб ними можна було
керувати в проєкті. Потім розглянутий план скомпонувати в процесі
ідентифікації потенційних погроз і ризиків, уведення їхніх категорій і
встановлення пріоритетів.

50
Етап 1. Використовуючи описані категорії ризиків, створюємо таблицю 2.3
Таблиця 2.3Визначення ризиків проєкту

Категорія ризику Ризик Опис ризиків
1. Задачі і цілі - створенню ІС Існує ризик, що дані заходи
проєкту загальної суперечать поточним задачам,
спрямованості кваліфікації і цілям фірми.
- зміна цілей Ризик зміни цілей під час
виконання проєкту

2. - немає підходящої Існує ризик того, що в даній фірми
Організаційний проєктної команди немає підходящої команди для
менеджмент - постійний зв’язок з виконання даного проєкту.
замо вником Так, як в проєкті замовником
виступають працівники фірми
існує ймовірність того, що не з
усіма - можливий зв’язок.

4. Замовник - функціонування Не відповідає реальним запитам
системи кінцевого користувача.
Залучення замовником в команду
працівників, які не володіють
- підбір не даною предметною областю.
підходящої Ризик, щодо застосування ІС.
проєктної команди
51
4. Бюджет - вартість проєкту Важко представити розмір
(вартість)
- зміна кількості робіт проєкту.
Зміна кількості робіт під час
виконання проєкту.

- тісний графік робіт
5. Графік робіт
Проєктній команді нав’язують
тісний графік робіт, який не в

- відсутність змозі виконати дана команда.
6. Зміст проєкту документації
Відсутня документація по
проміжним модулям ІС, яка
містить вимоги, відомості по
проєктуванню.
Категорія ризику Ризик Опис ризиків

7. Виконання - випробування Існує ризик, що новостворена
новоство реної система не коректно виконує свої
системи функції під час тестування.
- неадекватне Не вірно вибране тестування
тестування інформаційної сис- теми
проєктною командою.
Ризик пов’язаний з надійністю
- надійність ІС нової ІС

8. Управління - компетентність Немає досвіду роботи керівника
проєктом керівника проєкту проєкту в даній предметній
області, що може повести до
неправильного трактування
процесів управління.
52

9. Процеси - якість управління Неправильний вибір методів, які
розробки забезпечують якість проєкту.

10. Середовище - вибір інструмента Ризик виникає від недостатньої
розроб- ки розробки адекватності вибраного
- відсутність інструмента розробки.
адекватного простору Ризик виникає, якщо не
для вироблення угод підібрана команда спеціально
між учасниками для рішення поставленої задачі.
проєкту
- захищення даних ІС
в даному середовищі
Ризик, щодо безпеки даних ІС,
так як в вибраному середовищі
мало створених подібних систем.

11. Персонал - вибір персоналу Вибір мало досвідченої проєктної
погана команди
-
домовленість з Є ризик, що працівник не хоче
проєктною командою виконувати постав- лену перед
ним роботу.

12. Підтримка - підтримка після Ризик, що підтримку буде
впрова дження проводити недосвідче-
продукту ний користувач через
відсутності плану або бюджету
неперервної підтримки ІС.
53
Етап 2. Оцінюємо ризики, зв'язаних з виконанням проєкту, по категоріях:
Таблиця 2.4 Оцінка ризиків по категоріям

Оцінка
Категорія ризику Ризик Малий Середній Високий
ризику
1. Задачі і цілі проєк- - створенню ІС загальної спрямова- + 5
ту ності
2. Організаційний - зміна цілей + 7
менеджмент - немає підходящої проєктної коман- + 3
ди
3. Замовник - постійний зв’язок з замовником + 4
- функціонування системи + 6
- підбір не підходящої проєктної ко- + 4
манди
- застосовність + 7
4. Бюджет (вартість) - вартість проєкту + 8
- зміна кількості робіт + 7
5. Графік робіт - тісний графік робіт + 5
6. Зміст проєкту - відсутність документації + 2
7. Виконання - випробування новоствореної сис- + 8
теми
- неадекватне тестування + 4
- надійність + 7
8. Управління проєк- - компетентність керівника проєкту + 5
том
9. Процеси розробки - якість управління + 4
10. Середовище роз- - вибір інструмента розробки + 8
робки - відсутність адекватного простору + 7
для вироблення угод між учасниками
проєкту
- захищення даних ІС в даному сере- + 9
довищі
- піратське ПЗ + 5
11. Персонал - вибір персоналу + 3
- погана домовленість з проєктною + 5
командою
12. Підтримка - підтримка після впровадження про- + 6
дукту
54
Етап 3. Виконуємо сортування таблиці ризиків, розташовуючи них у
порядку убування очевидності і погрози, та розписуємо методи боротьби з ними.
Таблиця 2.5 Оцінка ризиків і методи боротьби з ними

Оцінка
Ризик Методи боротьби
ризику
1) захищення даних ІС в даному се- 10 Необхідний вибір достатнього рівня захищеності (можливо
редовищі необхідно найняти спеціаліста (експерта) для цього)
2) вибір інструмента розробки 9 Детальне вивчення існуючих інструментів розробки
3) вартість проєкту 8 Постійне детальне планування протягом ЖЦ проєкту
4) випробування новоствореної сис- 8 Розробка детального тестування проєкту і постійний зв’язок з
теми замовником
5) зміна кількості робіт 7 Постійне детальне планування протягом ЖЦ проєкту
6) зміна цілей 7 Отримання повної інформації від замовника в фазі аналізу
7) надійність ІС 7 Детальне тестування
8) застосовність ІС 7 Постійний зв’язок з замовником
9) відсутність адекватного простору 7 Створення сайту для постійного зв’язку з замовником
для вироблення угод між учасниками
проєкту
10) функціонування системи 6 Постійна перевірка на відповідність функціонування ІС
11) підтримка після впровадження 6 Розробка плану і бюджету для підтримки ІС
продукту
12) піратське ПЗ 5 Купівля ліцензійне програмне забезпечення
13) компетентність керівника проєкту 5 Вибір керівника з досвідом роботи в даній ПО
14) створенню ІС загальної спрямо- 5 Перш за все розробка ІС, яка відповідає головним цілям, а
ваності якщо буде вистачати часу, то і для комерційних цілей
15) тісний графік робіт 5 Розробка графіку з проєктною командою
16) погана домовленість з проєктною 5 Назначати працівників на роботи, які працівник може і хоче
командою виконувати, чітка початкова домовленість по заробітній платі
на весь проєкт
17) постійний зв’язок з замовником 4 Створення сайту
18) підбір не підходящої проєктної 4 Ретельний підбір команди
команди (вибір персоналу)
19) неадекватне тестування 4 Розробка плану тестування
20) якість управління 4 Вибір керівника з досвідом роботи в даній ПО
21) немає підходящої проєктної ко- 3 Відведення часу для навчання проєктної команди
манди
22) відсутність документації 2 Постійне ведення проєктувальної документації
23) економічна криза в країні 1 Страхування від таких ситуацій
55
Етап 4. Установлюється формат звіту для кожного ризику. Цей звіт
заслуховується на щотижневих зустрічах проєктної команди, де роз-
глядається стан проєкту. Показується стан найбільших десяти ризиків, зміни
в ранжируванні для кожного ри- зику за останній тиждень. Відображається звіт
відгуків-контрзаходів про ризики і про їхні зміни.
Етап 5. На заключному етапі необхідно постійно перевіряти управління
і скорочення ризиків є безперервним процесом у рамках життєвого циклу про-
єкту ІС. Відстеження і контроль ризиків, включених у список, виконуються на
регулярній основі. Менеджер проєкту і всі члени команди повинні звертають
увагу на поводження ідентифікованих ризиків, а також постійно контролюють
процеси їхнього визначення. Нові ризики, які виникають під час проєкту іден-
тифікуються, насамперед, для них визначаються пріоритети, що потім дода-
ються в план управління ризиками. Ризики з високим пріоритетом варто
обробляються відповідно до загального плану проєкту ІС.
2.8 Управління змінами проєкту
Під управлінням змінами розуміється процес прогнозування і
планування май бутніх змін, реєстрація всіх потенційних змін для оцінки їхніх
наслідків, схвалення або відхилень, а також організація моніторингу і коор-
динації виконавців, що реалізу ють зміни в проєкті. Передумовою для ефек-
тивного керування змінами є наявність опису базисного стану, що відбиває ви-
хідний стан системи для наступних змін і називається описом конфігурації
поточного стану проєкту. Це комплекс технічної доку- ментації, що
характеризує загальний стан відповідної системи у визначений момент часу.
Джерела змін можуть походити з внутрішнього або зовнішнього
оточення проєкту. До зовнішніх джерел змін відносяться політичні, еконо-
мічні соціальні, законодавчі, технологічні, екологічні, міжнародні, геогра-
фічні й ін. аспекти. Внутрішні джерела змін формуються в процесі відносин
між учасниками проєкту. Зміни впливають на:
− цінність і ефективність проєкту;
− тривалість і терміни завершення проєкту;
− вартість і бюджет проєкту;
56
− якість виконання робіт і специфікації вимог до
результатів; Внесення змін у проєкт припускає:
− виникнення додаткових витрат;
− порушення планових термінів здійснення проєкту;
− неможливість досягнення необхідної якості або результату проєкту.
У міру просування проєкту вартість внесених змін зростає, а практична
цінність часто убуває. У практиці використовуються наступні документи, що
регламентують і протоколюють проходження змін:
1) Звіт про проблему (Problem report) - опис проблеми, що виникає в ході
реаліза ції проєкту. Формується на початковій стадії.
2) Запит на здійснення зміни (Change request) - формується на початковій
стадії.
3) Опис передбачуваної зміни (Change proposal form) - інформація про
зміну, його поточному статусі, ініціаторах і відповідальних за виконання
і контроль. Формується на початковій і коректується на наступних
стадіях.
4) Заявка на зміну (Change order) - оформляється у виді письмового наказу
і підписується посадовою особою підрядчика; дозволяє і вказує, які
робити зміни поп роєкті. Формується на стадії ухвалення рішення.
Отже потенційними змінами в даному проєкті пов’язаного зі
створенням інфо рмаційної системи можуть бути:
- можливі зовнішні зміни пов’язані з політичними, економічними
соціальними, законодавчими, технологічними, екологічними,
міжнародними, географічними аспектами;
- зміна структури інформаційної системи;
- зміна структури бази даних інформаційної системи;
- зміна кількості програм (модулів) інформаційної системи;
- зміна вартості і бюджету проєкту;
- зміна якості виконання робіт і специфікації вимог до результатів.

57
2.9 Контроль проєкту
Система контролю за виконанням проєкту — це логічна структура
формальних та неформальних процедур для аналізу та оцінки ходу виконання
проєкту та оцінки ефективності управління ресурсами, витратами, зобов'яза-
ннями протягом усього терміну його реалізації (періодичний моніторинг
поточної діяльності, порівняння обсягів та витрат із плановими стандартами
проєкту, виявлення відхилень із метою усунення додаткових витрат). Це
також процес, в якому керівник проєкту встановлює, чи досягаються
поставлені цілі, виявляє причини, які дестабілізують хід роботи, й обгрунтовує
прийняття управлінських рішень, що коригують виконання робіт по проєкту,
перш ніж будуть завдані збитки проєкту. Основними задачами контролю є:
перевірка фактичних даних, зіставлення їх із плановими і виявлення
відхилень.
Предметом контролю є: факти і події, перевірка виконання конкретних
рішень, з'ясування причин відхилення, оцінка ситуації, прогнозування
наслідків. Контроль передбачає постійне спостереження за ходом реалізації
проєкту.
Усередненими елементам даного проєкту, що є об'єктами контролю, —
це час, вартість, якість, зміни, які виникають у ході реалізації проєкту;
підготовка, отримання, найм персоналу та оренда приміщення, стан справ із
фінансуванням, закупівельні характеристики проєкту, відповідність поло-
женням договорів тощо.
Роль контролю як функції управління полягає в тому, що він є засобом
здійснення зворотного зв'язку в системі управління. Його сенс полягає у ство-
ренні гарантій виконання планових рішень. До процесів контролю
включають:
- визначення результатів діяльності на основі зіставлення результатів
здійснення рішень із запланованими; порівняння показників очікуваного й
фактичного виконання планів; аналіз ймовірних відхилень від
запланованих показників; перевірка припущень; перевірка методичної та
змістової узгодженості планового процесу, проведення необхідних робіт
58
для виправлення ситуації. Організацію і послідовність здійснення
контролю показано на рисунку 2.1

Рисунок. 2.1 – Послідовність здійснення контролю
Як бачимо, контролюючи проєкт, ми звертаємо увагу, в першу чергу, на
відхилення, а саме: на їх розміри, чи достатньо вони малі, щоб із ними можна
було миритися, або, чи настільки великі, що потрібно змінювати хід реалізації
проєкту загалом. Отже, контролем можна назвати процес перевірки
виконання плану і вживання заходів для усунення відхилень. Обов'язковими
вимогами до системи контролю є: точність; своєчасність; повнота інформації;
забезпечення єдності інформації для всіх учасників проєкту. Існує три основні
види контролю:
— попередній;
— поточний;
— заключний.
Попередній контроль здійснюється до фактичного початку виконання
робіт і направлений на дотримання правил і процедур, він торкається
ресурсного забезпечення робіт.
Поточний контроль здійснюється при реалізації проєкту, він включає:
59
контроль часу, досягнення проміжних цілей проєкту, виконання заданих
обсягів робіт,
контроль бюджету, контроль ресурсів, контроль якості. Основна мета —
оперативне регулювання ходу реалізації проєкту. Такий підхід базується на
порівнянні досягнутих результатів із встановленими в проєкті вартісними,
часовими, ресурсними характеристиками. При впровадженні енерго-
зберігаючих технологій буде застосовуватись регулярний оперативний
контроль.
Заключний контроль проводиться на стадії завершення проєкту з метою
повної фактичної оцінки реалізації проєкту. Основним призначенням його є
узагальнення отриманого досвіду для подальшої розробки й реалізації
проєктів-аналогів і з метою вдосконалення процедур управління як для
менеджера з управління проєктами впроваджуваного проєкту так і для
звітування перед замовником.
Також для моніторингу прогресу в даному проєкті використовуються
віхи, а саме:
- Закінчення передінвестиційної фази
- Закінчення інвестиційної фази
- Закінчення експлуатаційної фази
- Закінчення проєкту
Висновки до розділу 2.
В другому розділі здійснено управління проектом згідно методології
PMBOK на основі застосування програмного засобу “Microsoft Project”.
Досліджені ризики та їх ймовірність, визначені основні методи боротьби з
ймовірними ризиками. Розроблено план проекту, бюджет проекту, здійснено
управління ресурсами, закупівлями та якістю.
60
РОЗДІЛ 3. РОЗРОБКА СИСТЕМИ ОЦІНКИ ЕФЕКТИВНОСТІ ПРОЄКТУ
3.1 Система оцінки ефективності проєкту
Визначення мети проекту: це бажаний та доведений результат, досягнутий
у межах певного строку при заданих умовах реалізації проекту. Метою проекту
створення інформаційної системи турагенства є підвищення ступеню автоматизації
роботи фірми в рамках єдиної архітектури на рівні, що не уступає ведучим
вітчизняним розробкам. Другорядною метою проекту є створити ІС для загального
використання для туристичних компаній, щоб мати можливість продати її іншим
фірмам чи організаціям даної галузі, при чому, щоб дана ціль не зашкоджувала
головній меті проекту для даної організації.
Інструмент управління проекту, який використовується для ідентифікації
та відображення структури відповідальностей учасників проекту було використано
OBS (Organizational Breakdown Structure). OBS дозволяє розкласти організацію на
різні рівні, показуючи, як кожна частина організації пов'язана з конкретними
елементами проекту.
Організаційний розклад проекту може включати в себе такі елементи:
• Функціональні групи: Відділи та підрозділи організації, що
забезпечують ресурси та експертизу для проекту.
• Ролі та відповідальності: Визначення ролей, обов'язків та
відповідальностей для кожного учасника проекту.
• Матриця управління: Визначення, як керівництво та виконавчий
персонал взаємодіють на різних рівнях проекту.
• Ключові зацікавлені сторони: Врахування ролей зовнішніх
стейкхолдерів, таких як клієнти, партнери чи регулятори.
• Робочі групи та команди: Сформовані групи, спрямовані на
виконання конкретних завдань у рамках проекту.
61

Проектний менеджер
Дизайнер Системний
Головний розробник QA-інженер QS-інженер адміністра-
тор

Ро зробник 1 Розробник 2 Розробник 3

Рисунок 3.1 – OBS проекту створення ІС управління турагенством

Також для проектного управління було використано інструмент WBS (Work
Breakdown Structure), який допомагає розглядати проект як сукупність менших,
легше керованих елементів. Для проекту створення інформаційної системи (ІС)
управління турагенством, WBS включає наступні етапи та компоненти:
1. Ініціація проекту:
• Визначення бізнеспотреб та мети проекту.
• Підготовка проектної документації.
2. Аналіз та планування:
• Збір вимог для ІС від турагенства.
• Розробка технічного завдання та специфікацій.
• Планування ресурсів, графік робіт та бюджету.
3. Розробка ІС:
• Розробка архітектури системи.
• Розробка бази даних та інтеграції з нею.
• Розробка користувацького інтерфейсу.
• Програмування та тестування функціоналу.
• Розробка систем звітності та аналітики.
4. Впровадження та тестування:
• Тестування інтеграції та відповідності вимогам.
• Підготовка до впровадження та планування пілотного запуску. 62

• Технічна підтримка під час впровадження.
5. Оптимізація та розвиток:
• Оцінка продуктивності та збір фідбеку від користувачів.
• Впровадження покращень та оптимізація роботи ІС.
• Підготовка до можливого розширення функціоналу.
6. Навчання та підтримка:
• Розробка програми навчання для користувачів.
• Надання технічної підтримки та вирішення проблем користувачів.
7. Завершення проекту:
• Оцінка та аналіз результатів.
• Підготовка звітів та закриття проекту.

Проект створення ІС
управління турагенст-
вом

До інвестиційна фаза Інвестиційна фаза Операційна фаза

Визначення цілей Проектування Впровадження

проекту

Встановлення за- Реалізація
Супровід
вдань проекту

Ан аліз Тестування

Підготовчі роботи Документування

Рисунок 3.2 - WBS проекту створення ІС управління турагенством

63

3.2 Управління часом в проєкті
Перше, що треба зробити при управлінні часом у проєкті, це визначити
календар, по якому працюють люди в проєкті. Отже при плануванні часу
слід звернути увагу на те, що люди виконують роботу тільки п’ять днів (в
залежності від календаря) на тиждень. Також треба враховувати вихідні, свята,
відпустки (особливо для проєктів, які виконуються в літній період). В проєкті
вибраний календар з п’ятьма робочими днями на тиждень з врахуванням свят.
На наступному етапі планування необхідно визначити, скільки часу буде
потрібно для виконанні проєкту впровадження ІС для туристичних компаній.
Від даного планування залежить на скільки вчасно буде виконуватися проєкт.
Чим детальніше зроблене планування по кожній роботі, тим менша
ймовірність відхилення від плану проєкту. Можна сказати, що точність оцінок
відбиває знання проєктного менеджера даної галузі. Точність оцінок також
жорстко зв'язана зі стадією виконання проєкту. На початку проєкту оцінки
будуть менш точні, чим ближче до його фінішу.
Точність оцінок залежить від рівня невизначеності проєкту.
Невизначеність змушує користуватися кривої імовірності. Чим вище ризик,
тим ширше розподіл. Оцінки бувають оптимістичними, найбільш ймовірними
і песимістичними.
Зв'язок робіт проєкту між собою визначається логікою проєкту. Деякі
дії повинні виконуватися у визначеному порядку. Наприклад, при впровад-
женні ІС для туристичних компаній спочатку створюється архітектура
програм і база даних проєкту, потім створюються самі програми. Ці роботи
мають залежне або серійне взаємовідношення. Інші роботи не зв'язані одна з
одною. Наприклад в даній АІС створення WEB-сайту і створення програми
для менеджера. Ці дві роботи мають незалежні або рівнобіжні відносини.
Деякі роботи мають запас часу (вони називаються роботами з резервом
часу або роботами, що плавають). Послідовність робіт, що не має запасу часу,
не може “плавати” по тимчасовій шкалі і тому називається критичним шляхом
проєкту. Якщо будь-яка робота цієї послідовності протриває довше
запланованого часу, то зрушиться весь термін виконання проєкту. Отже при
64
проєктуванні необхідно звертати увагу на роботи, які входять до критичного

шляху і більш детально планувати роботи, які входять до критичного шляху,
так як від них залежить на скільки можливе відхилення по терміну виконання
проєкту.
В даному проєкті для планування часу використовувалась програма
Microsoft Project 2010. Діаграма Ганта показував план робіт проєкту (див. рисунок
3.3).
Рисунок 3.3 – Діаграма Ганта
Як ми бачимо з WBS-структури проєкт складається з таких фаз:
1) Підготовчі роботи – час виконання 18 днів;
2) Аналіз – час виконання 14 днів;
65

3) Проєктування – час виконання 14 днів;
4) Реалізація – час виконання 59,98 день;
5) Тестування – час виконання 12 днів;
6) Документація - час виконання 22 днів;
7) Впровадження – час виконання 10,67 днів.
Отже час виконання проєкту впровадження ІС для туристичних
компаній – 150,64 днів.
На Основі запропонованих схем і діаграм реалізовано базу даних структуру якої
зображено на рисунку 3.4
66

Рисунок 3.4 Структура Бази Даних проєкту
3.3 Оцінка економічної ефективності проєкту
На підставі прогнозу витрат робіт реалізації інвестиційної фази проекту
та на їх реалізацію розробляється первісний варіант календарного графіка
фінансування інвестиційної фази (табл. 3.1).
Графік відображає щомісячну потребу (Kt) у фінансових ресурсах
(капіталовкладеннях) і розробляється в передумові рівномірного за місяцями
фінансування робіт, використання яких розтягується на декілька місяців.
На графіку вказуються суми щомісячних потреб у фінансових ресурсах.
Загальна сума капіталовкладень складе:
К =
t  К t , тис. грн.
Таблиця 3.1 Календарний графік фінансування інвестиційної фази

Дисконтовані виттра-
Потреба в капіта- Коефіцієнт дис- Дисконтовані ти з наростаючим під-
Місяць ловкладенні, грн. контування витрати, грн сумком, грн
1 73470 0,952380952 69971,43 69971,43
2 75487 0,907029478 68468,93 138440,4
3 89289 0,863837599 77131,2 215571,6
4 99963 0,822702475 82239,81 297811,4
5 101157 0,783526166 79259,16 377070,5
6 94499 0,746215397 70516,61 447587,1
7 89379 0,71068133 63519,99 511107,1
8 73079 0,676839362 49462,74 560569,9
Всього 696323 560569,9

Прогнозування вартісних показників операційної діяльності мають
67

тенденцію до змін за роками проекту і обумовлюють річні операційні доходи
та витрати. Про- гнозування повинно дати відповіді на слідуючи питання: як
буде змінюватися ціна реалізації одиниці продукції, як будуть мінятися
витрати на матеріали внаслідок зміни цін на матеріальні ресурси, як будуть
змінюватися витрати на оплату праці
внаслідок зміни цін на трудові ресурси, як будуть вести себе за роками
проекту витрати постійного характеру. Основою прогнозних розрахунків є
прогнози динаміки показників операційної діяльності.
Таблиця 3.2 Прогноз показників операційної діяльності

Назва Показники
1. Середньорічний обсяг реалізації продукції (ОР), 2-3
2.Середня ціна реалізації замовлення (Ц), т. грн./одиницю 25,5
3. Прямі витрати для 1 замовлення (П), т.грн./одиницю 8,8
4. Прямі витрати на оплату праці (ОП), т.грн./одиницю, (з нарахуваннями) 7,5
5. Постійні витрати операційної діяльності (ПВ), тис.грн./рік 46,04

Отримані значення вартісних показників будуть використані при
розрахунку операційних доходів і витрат за роками проекту.
Таблиця 3.3 Прогноз динаміки показників операційної діяльності

Назва Показники

1. Коефіцієнт щорічного зростання (зниження) ціни продукції ( Ц )
1,02
2. Коефіцієнт щорічного зростання (зниження) ціни на продукти(сировину)
( Ц П ) 1,02
3. Коефіцієнт щорічного зростання (зниження) рівня оплати праці ( ОП ) 1,02
4. Коефіцієнт щорічного зростання рівня постійних витрат ( ПВ ) 1,02
Операційні доходи за роками операційної діяльності визначаються
запланова- ними обсягами надання кожного із видів послуг і рівнем цін на
послуги.
68

Рисунок 3.1 - Графік поточних потреб у капіталовкладеннях
3.4 Розробка зведеного кошторису витрат інвестиційної фази
проекту
Основою для розробки планового зведеного кошторису (бюджету)
витрат інвестиційної фази проекту служать дані прогнозу витрат окремих
робіт. Для процесів, витрати на які визначені як щоквартальні,
розраховуються загальні суми витрат, що враховують кількість кварталів. У
кошторисі фігурують роботи, що потребують фінансових затрат (крім
фіктивних робіт).
Зведений кошторис, що наведено у табл. 3.5 є одним з найважливіших
планово-координуючих документів, що забезпечує процеси управління ходом
реалізації проекту.
Таблиця 3.5 Зведений кошторис планових витрат інвестиційної фази проекту
№ п/п Процеси, роботи Витрати, грн.
1 Старт проекту 43470
2 Підготовчі роботи 65487
3 Аналіз 109289

4 Проектування 109 963
5 Реалізація 154157
6 Тестування 124499
7 Впровадження 89367
8 Всього витрат 696323

Прогнозування значення показників за роками операційної діяльності
(для t-го року) складуть [45]: 69

- прогноз середньої ціни одного замовлення:
Ц t = Ц t-1 * ∆Ц, грн./одиницю;
- прогноз прямих продуктових витрат:
П t = П t-1 * ∆Ц п, грн./одиницю;
- прогноз прямих витрат на оплату праці:
ОП t = ОП t-1 * ∆ОП, грн./одиницю;
- прогноз рівня постійних витрат операційної
діяльності: ПВ t = ПВ t-1 * ∆ПВ,
грн./рік,
де Ц t-1,П t-1, ОП t-1, ПВ t-1 - відповідні показники попереднього року
операційної діяльності (табл. 3.2);
∆Ц, ∆Цп, ∆ОП, ∆ПВ – коефіцієнти темпу зміни(зростання чи зниження)
значення показників для кожного наступного року операційної
діяльності(табл. 3.3).
Таблиця 3.6 Прогноз динаміки вартісних показників операційної
діяльності
Роки операційної діяльності
Показники 1 2 3 4 5 6 7 8 9 10
1. Середня ціна
одного замов-
лення (Цt),т.
грн./од. 25,5 26,01 26,53 27,06 27,60 28,15 28,71 29,29 29,87 30,47
2. Прямі про-
дуктові витра-
ти (Пt), грн./од. 8,8 8,976 9,155 9,338 9,525 9,715 9,910 10,10 10,31 10,51
3. Прямі ви-
трати на оп-
лату праці
(ОПt),
т.грн./од. 7,5 7,65 7,803 7,959 8,118 8,280 8,446 8,615 8,787 8,963
4. Постійні
витрати
(ПВt),
тис.грн. 46,04 46,96 47,90 48,85 49,83 50,83 51,84 52,88 53,94 55,02

Отримані значення вартісних показників будуть використані при
розрахунку операційних доходів і витрат за роками проекту.
70

3.5 Планування амортизаційних витрат операційної діяльності
Метою розробки цього комплексу розрахунків є обґрунтування
амортизаційних витрат за роками операційної діяльності, що наведено у
таблиці 3.7. Стандарти бухгалтерського обліку передбачають право суб`єкта
самостійно вирішувати питання про строк і метод погашення амортизаційних
витрат.
Самостійно обираємо найбільш доцільний метод амортизації та
розраховуємо величини амортизаційних відрахувань за роками операційної
діяльності. В рамках даних методів обираємо один, який передбачає
застосування до амортизації, як процесу погашення витрат, правил і норм, що
застосовуються податковим законодавством для амортизації, як процесу
накопичення коштів.
Діюче податкове законодавство відокремлює у складі основних фондів
суб‘єктів господарської діяльності 16 груп фондів, для кожної з яких
встановлені відповідні граничні норми амортизації від балансової вартості
груп на початок року. Виходячи з цих граничних норм визначаємо суму
прибутку, яку підприємство може вивести з оподаткування і направити на цілі
оновлення основних фондів.
Таблиця 3.7 Розрахунок амортизаційних витрат за роками
операційної діяльності
Пер-
Мініма- Роки
вісна
льно до-
вар- пустимі
тість, строки
корисног
Груп тис.г 1 2 3 4 5 6 7 8 9 10
о викорис-
а р тання
ОФ н
.
3 26,32 15 2,10 1,937 1,78 1,63 1,58 1,38 1,76 1,14 1,08 0,9
6 2 9 4
6 4,265 4 1,76 1,23 0,61 0,36 0,22 0,13 0,07 0,047 0,02 0,0
4 8 1 2 9 8 1
4 13,04 5 0312 2,37 1,80 1,37 1,04 0,79 0,60 0,458 0,34 0,2
3 3 8 6
4 0,690 2 0,41 0,165 0,06 0,02 0,01 0,00 0,00 0,006 0,00 0,0
4 6 6 0 4 1 2 1
Разом 443,2 7,45 5,70 4,5 3,88 3,24 2,98 2,61 2,416 2,35 2,2
7 5 4 3 8 7 71

3.6 Прогноз доходів та витрат операційної діяльності
Операційні доходи за роками операційної діяльності визначаються
запланованими обсягами виробництва, реалізації продукції і рівнем цін на
продукцію. Розрахунок річних сум доходів за 10 років операційної фази
проекту представлений у формі наступної таблиці:
Таблиця 3.8 Прогноз доходів операційної діяльності

Роки операційної
Показники діяльності
1 2 3 4 5 6 7 8 9 1
0
1.Середньорічні 2 2 3 3 3 3 2 2 2 2
обсяги
реалізації
продукції (ОР),
одиниць
2. Середня ціна
реалізації
замов- лення
(Ц), т. 25,5 26,01 26,53 27,06 27,60 28,15 28,71 29,29 29,87 30,4
грн./одиницю 7
3. Річний дохід
(Д) тис.грн 51 52,02 79,59 81,18 82,8 84,45 57,42 58,58 59,74 60,9
4

Річні суми витрат змінного характеру для t-го року операційної фази проекту
складуть:

де ОР t – обсяг реалізації продукції, одиниць;
П – витрати на продукти (сировину) для одного замовлення, грн./од;
t
ОП t – витрати на пряму оплату праці (з нарахуваннями) на одиницю
продукції, грн./од.
Розробляємо і оформлюємо прогноз операційних витрат.
Розрахунок представлений у табл. 3.9.

72

Таблиця 3.9 Прогноз витрат операційної діяльності, тис. грн
Роки операційної
Показник діяльності
1 2 3 4 5 6 7 8 9 10
1. 2,019 2,0599 2,1011 2,1431 2,1860 2,2297 2,2743 2,3198 2,3662 2,4135
Змінні 5
витрат 7
и
(ВЗ)
2. Постійні
витра
ти 46,04 46,96 47,9 48,85 49,835 50,831 51,848 52,885 53,943 55,022
(ВП)
3.Амортиз 7,45 5,70 4,5 3,887 3,245 2,984 2,613 2,416 2,358 2,276
а
ція (А)
Разом опе-
раційні
ви- трати 55,509 54,719 54,501 54,880 55,266 56,044 56,735 57,620 58,667 59,711
(ОВ)
73

Прогноз грошових потоків операційної діяльності

Прогнозний аналіз грошових потоків операційної діяльності на основі
співставлень доходів і витрат за роками цієї фази дає картину формування
прибутку (табл.. 3.10).
Таблиця 3.10 Прогноз грошових потоків операційної діяльності
Показни- Роки операційної
ки діяльності
1 2 = 3 4 5 6 7 8 9 1
0
1. Дохід
від реалі-
зації (Д),
тис грн 51 52,02 79,59 81,18 82,8 84,45 57,42 58,58 59,74 60,94
2. Опера-
ційні ви-
трати,
грн (ОВ) 55,50 54,71 54,501 54,8 55,26 56,044 56,735 57,620 58,667 59,711
80 6
3. Прибу-
ток (ПБ) -4,5 -2,69 -1,441 -0,76 - 0,256 0,685 0,96 1,073 1,229
0,066
4. Амор- 7,45 5,70 4,5 3,88 3,24 2,984 2,613 2,416 2,358 2,276
тизація 7 5
(А)
5
Оподатко
ваний
прибуток - -8,39 20,589 22,4 24,28 25,422 -1,928 -1,456 -1,285 -1,047
(ОП) 11,95 13 9
6. Пода-
ток на
прибуток 4,48 4,857
(П) -2,39 -1,67 4,1178 26 8 5,0844 -0,385 -0,291 -0,257 -0,209
7. Чистий
прибуток
(ПЧ) -9,56 -6,71 16,471 17,9 19,43 20,337 -1,542 -1,164 -1,028 -0,837
30 1

74

3.7 Прогноз грошових потоків проекту
Метою виконання даних прогнозних розрахунків є співставлення
грошових потоків інвестиційної, операційної, і фінансової діяльності в межах
даного проекту з тим, щоб переконатися в його ефективності. При виконанні
даної роботи розрахунки виконуються за перші 2 роки інвестиційної фази (з
розбивкою за кварталами) та послідуючі 10 років операційної фази проекту.
Саме такий підхід застосовується у практиці проектного аналізу.
В цілому картина грошових потоків проекту, в ситуації що моделюється
в роботі, має вигляд за формою таблиці 3.11. При виконанні розрахунків
коефіцієнти дисконтування для квартальних періодів інвестиційної фази
визначаються за квартальною нормою доходу, а для річних періодів
операційної фази – за річними нормами доходу на капітал.

75

Таблиця
3.11
Прогноз грошових потоків проекту

Фази, роки, квартали проекту
Інвестиційна фаза, тис грн Роки операційної фази, тис грн
Показники Місяці
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8
1. Грошові потоки ін-
вестиційної діяльності 73,47 75,48 89,289 99,96 101,15 94,499 89,37 73,08
2. Чистий прибуток
операційної діяльності -9,56 -6,71 16,47 17,93 19,43 20,33 -1,54 -1,16 -1,02 -0,87
3. Амортизація 7,45 5,70 4,5 3,887 3,245 2,984 2,613 2,416 2,358 2,276
4. Сальдо реальних - - - - - - -
грошей 73,47 75,48 89,289 -99,96 101,15 94,499 89,37 73,08 -9,56 -6,71 16,47 17,93 19,43 20,33 -1,54 -1,16 -1,02 -0,87
5. Коефіцієнт дискон-
тування 0,95 0,90 0,863 0,822 0,783 0,746 0,71 0,67 0,51 0,40 0,32 0,26 0,20 0,16 0,13 0,10 0,08 0,06
6. Дисконтований по-
тік грошей за періода-
- - - - - - - - - -
ми 69,79 67,93 77,056 -82,16 79,200 70,496 63,45 48,96 4,875 2,684 5,270 4,661 3,886 3,252 -0,20 0,116 -0,38 -0,16
7. Дисконтований по-
тік грошей наростаю-
чим підсумком -69,7 -137, -214,7 -296,9 -376,1 -446,6 -510 -559, -4,9 -7,58 -2,31 2,348 6,234 9,487 9,286 9,170 8,781 8,620

68

За результатами розрахунку грошових потоків розробляється графічний
варіант схеми номінальних (реальних) грошових потоків проекту (сальдо
реальних грошей), що зображений на рис 3.2. Для інвестиційної фази вказуються
річні сумарні грошові потоки, що складуть 696298 грн

Рисунок 3.2 - Схема номінальних грошових потоків проекту
3.8 Оцінка показників ефективності проекту
Розрахунок показників ефективності проекту робиться на підставі
прогнозу і по реалізації за 12 років. За формалізованим підходом показник
абсолютного ефекту проекту визначається як різниця між накопиченими
грошовими притоками і відтоками проекту. Якщо мова йде про дисконтовані
грошові потоки, то цей показник має назву чистого дисконтованого прибутку
(доходу) проекту – ЧДП (ЧДД).
Ч Д П =  П * К Д −  В * К Д = 8 , 6 2 0
t t t t тис.грн,
де П t - поточні грошові притоки, тис. грн.;
В t - поточні грошові відтоки, тис. грн.
Таке значення ЧДП свідчить про ефективність проекту.
Показник відносної ефективності використання капіталу – індекс
прибутковості (дохідності) капіталу проекту[47]:

77
Індекс дохідності більше 1, що також свідчить про ефективність
проекту.
Для розрахунку строку окупності капіталу, що передбачається вкласти у
про ект, визначається величина середньорічних грошових притоків:

де Т оп - тривалість операційного періоду генерування грошових притоків, ро-

Очікуваний строк окупності капіталу, що буде вкладений у проект:

Показник внутрішньої норми доходності проекту (ВНД) визначається на
підставі рішення рівняння:

Якщо підставити вираз:

вирішення цього рівняння:

Вирішення цього рівняння відносно X= Н д дає значення Н д собою показник
ВНД.
Цей показник повинен бути більшим ніж норми доходу на капітал, яка
покла дена в основу розрахунків показників ефективності проекту
В даній задачі ВНД = 25%, що є відповідає значенню від норми доходу на
капітал (25%). Отже, за всіма розрахованими показниками ефективності, даний
78
проект є ефективним для впровадження для власних потреб турагенства.
3.9 Оцінка соціальної ефективності проєкту
Слід відзначити, що зростання соціальної ефективності є кінцевою метою
загальної виробничо-господарської і комерційної діяльності підприємств. З
огляду на це, економічну ефективність відносно соціальної треба вважати
проміжною. Саме рівень економічної рентабельності функціонування
підприємств є матеріальною і фінансовою базою розв'язання будь-яких
соціальних проблем. З урахуванням цієї важливої обставини треба оцінювати
соціальну ефективність.
Завдання соціального аналізу проєкту полягає у визначенні його
узгодженості з інтересами груп населення, які так чи інакше відчуватимуть вплив
проєкту: працюють на підприємстві, де реалізується проєкт; споживатимуть його
продукцію; живуть у зоні проєкту. Соціально прийнятною вважається така
стратегія проєкту, що не суперечить інтересам зазначених груп населення і
сприяє додатковому якісному задоволенню соціально-культурних потреб
населення регіону і країни (при відповідному масштабі проєкту).
Проєкт не лише не погіршує соціальне середовище свого розміщення, а й
сприяє його поліпшенню (благоустрій території, поліпшення торгівельної інфра-
структури, додаткові робочі місця, соціальна значущість продукції проєкту).
Загальну послідовність дослідження соціального впливу проєкту наведено
на рис. 3.2.
Особливо актуальним є аналіз опрацювання соціальних питань всередині
проєкту з огляду на:
– персонал – додаткове робоче місце;
– рівень оплати праці;
– заплановану систему стимулювання й мотивації праці;
– організацію взаємодії дирекції і персоналу – підвищення рівня їхнього
співробітництва;
– ділові якості менеджерів проєкту і базового підприємства.
79

Рис. 3.2. Соціальний аналіз проєкту
Окремо в аналізі варто розглянути технічні аспекти місця людини у
проєкті: заплановані умови праці, режим роботи, дотримання правил техніки
безпеки. Робота працівника буде відповідати всім нормам і стандартам безпечної
роботи. Буде про- ведено вступний, а через певний час і повторний інструктаж
по техніці безпеки.
Здійснюючи соціальний аналіз проєкту, необхідно враховувати, що для
більшості проєктів основним є аналіз впливу проєкту на рівень життя залученого
персоналу і оцінка його екологічної безпеки. Аналізуючи даний проєкт, можна
зазначити, що рівень життя залученого персоналу зростатиме, адже планується
надбавки за ефективну і активну роботу. Індексація заробітної плати відповідно
до динаміки роздрібних цін на товари і регулювання продажних цін на певні види
товарів для населення. Що до оцінки екологічної безпеки, то проєкт є повністю
безпечним.
Висновки до розділу 3.
В третьому розділі здійснено розрахунок ефективності проекту. Зроблено
розподіл коштів на інвестиційній фазі проекту, розроблено кошторис витрат
інвестиційної фази проекту. Здійснено прогноз показників операційної фази
проекту та розрахо вані показники ефективності проекту.
80
ВИСНОВКИ

В даній кваліфікаційній роботі досліджено процеси створення інформа-
ційної системи турагенства. Питання пов’язані з успішним управлінням проєктів
на сьогодні є досить актуальні, оскільки в галузі інформаційних технологій,
оскільки часто виникає визначений набір невирішених проблем, таких як
збільшення обсягу операцій і зменшення швидкості роботи системи,
використання могутньої системи не на повну потужність, перетворення
впровадження в нескінченний процес, постійну зміну вимог. Саме цими
питаннями і займається управління ризиків та управління змінами в проєкті.
Знаючи методи і аналізи боротьби з ризиками та змінами і використовуючи їх в
управлінні проєктами в галузі створення інформаційної системи, можна
уникнути зриву проєкту.
При цьому були вирішені наступні задачі:
- проведено управління проєктом впровадження програмного продукту
(ІС) для туристичних компаній;
- розглянуто моделі, методи і аналізи боротьби з ризиками при управлінні
проєктами в галузі створення інформаційних систем;
- розглянуто міжнародні стандарти якості з управління ризиками проєкту
ство рення інформаційних систем;
- проведено досить детальне дослідження ризиків вибраним методом, що
скла дається з п'яти етапів, використовуючи 12 категорій ризиків;
- проаналізовано особливості управління змінами в проєктах створення
інформа- ційних систем;
- розраховано економічну ефективність проєкту впровадження програмного
продукту (ІС) для туристичних компаній.
В результаті проведення аналізу управління ризиками та змінами в
проєктах в галузі створення інформаційних систем, було зроблено такі висновки:
- для вирішення задачі управління ризиками існує багато, методів, кожний із
них має свої особливості, обумовлені властивостями і характеристиками
об'єктів розробки — комплексів програм, а також систем і зовнішнього
81
середовища, у яких вони застосовуються. Моделі відрізняються
специфікою інтересів і квалі фікації їхніх авторів і охоплюють широкий
спектр реальних ситуацій проєкту- вання інформаційних систем, у яких
необхідне скорочення або виключення ризиків проєктів;
- в моделях, що приводяться, увага акцентується на процесах аналізу і
зменшення ризиків, однак практично відсутні оцінки реальних значень
ризиків, що можуть бути досягнуті при пропонованих методах і стратегіях.
Рішення цієї задачі сильно залежить від параметрів і характеристик
реальних проєктів ІС і навряд чи може конструктивно вирішуватися в
загальному виді. Приведений набір мо делей і стандартів і їхні фрагменти
доцільно узагальнювати і використовувати розроблювачам і замовникам
складних ІС високої якості для формування влас- них керівних документів
підприємства при необхідності забезпечення мінімальних ризиків у
життєвому циклі конкретних програмних продуктів;
- при дослідженні ризиками в кваліфікаційній роботі, зроблено висновок, що
в проєктах в галузі створення інформаційних систем, досить часто
виникають ризики, які охоплюють широкий спектр різноманітних ситуацій,
для яких необхідно знайти метод боротьби з ними. Є ризики, з якими досить
легко боротися, а є ри зики, які відомі розробникам, але невідомо їх реальні
перспективи для того чи іншого проєкту, з якими досить важко боротися і
які можуть принести досить великі втрати для проєкту. Тому необхідно
досить ретельно аналізувати можливі ризики, які виникають в проєктах в
галузі створення інформаційних систем;
- при управлінні змінами в проєкті зроблено висновок, що у міру просування
проєкту вартість внесених змін зростає, а практична цінність часто убуває.
В результаті дослідження проєкту впровадження програмного продукту
(ІС) для туристичних компаній отримали такі результати.
Проєкт розбитий на 6 фаз: підготовчі роботи, аналіз, проєктування,
реалізація, тестування та впровадження.
Час виконання проєкту рівний: Т = 150, 64
днів Бюджет проєкт: С = 580 тис. грн.
82
При визначенні оцінки економічного ефекту проєкту створення
інформаційної системи для туристичних компаній, отримали результати, що
даний проєкт є досить перспективним.
ЧДП = 53200 грн. - свідчить про високу комерційну ефективність
проєкту. ІД = 1,66 – індекс прибутковості капіталу, досить високий.
Ток = 0,6 років
Проєкт дуже швидко може окупитися 7-8 місяців. Якщо б даний проєкт
окуплювався в межах 2-3 років, даний проєкт був зовсім не перспективний,
оскільки галузь інформаційних технологій швидко змінюється і через 2-3 роки,
створену інформаційну систему необхідно було б міняти, а це означає, що фірма
не отримала ніяких прибутків, а могла і понести збитків.
При виконанні кваліфікаційної кваліфікаційної роботи було досліджено
процеси створення проєкту за допомогою сучасних програмних засобів
проєктного менеджменту.
83
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

1. Sutherland, Jeff; Sutherland, J.J. Scrum: The Art of Doing Twice the Work in Half
the Time (1st ed.). Currency, 2014. – p. 256. ISBN 9780385346450.
2. Bichler, Shimshon; Nitzan, Jonathan Systemic Fear, Modern Finance and the Fu-
ture of Capitalism, Jerusalem and Montreal, 2010, pp. 8–11.
3. Pekoz, Erol The Manager's Guide to Statistics. ProbabilityBookstore.com, 2009.
– 26 р. ISBN 9780979570438.
4. Belov, Mikhail V., Novikov, Dmitry A. Methodology of Complex Activity: Foun-
dations of Understanding and Modelling. Heidelberg: Springer, 2020. –
290 с.
5. Antonio Nesticò, Gianluigi De Mare A Multi-Criteria Analysis Model for Invest-
ment Projects in Smart Cities. Environments, 2018, 5(4), 50.
6. Novikov D. Control Methodology. – New York: Nova Science Publishers, 2013. –
76 p. ISBN 978-1624179624.
7. Charles G. Cobb The Project Manager's Guide to Mastering Agile: Principles and
Practices for an Adaptive Approach. John Wiley & Sons. 2015, p. 378. ISBN 978-
1-118-99104-6.
8. Collyer, S., & Warren, C. M. (2009). Project management approaches for dynamic
environments. International Journal of Project Management, 27(4), 355– 364.
9. Serrador, P. & Turner, R. (2015). The relationship between project success and pro-
ject efficiency. Project Management Journal, 46(1), 30–39.
10. Prokopenko, T.A., Zyelyk, Ya.L. Complex method of strategic decision-making in
management of technological complexes of continuous type. - Journal of Automa-
tion and Information Sciences. - 2017.- Volume 49. - P.71 -79
11. Prokopenko, T.A., Ladanyuk A.P. Information model of control of the continuous
type technological complexes in the class of organizational and technological
systems // Journal of Automation and Information Sciences, 2014, Volume 46,
Issue84 9, Pages 78-85
84

12. Липний В. В. Особливості управління якістю проєктів в сфері інформаційних
технологій// Матеріали VІIІ Міжнародної науково-технічної Internet-
конференції «Сучасні методи, інформаційне, програмне та технічне
забезпечення систем керування організаційно-технічними та технологічними
ком- плексами», 26 листопада 2021. [Електронний ресурс]
– К: НУХТ, 2021 – C.179. Режим доступу:
https://nuft.edu.ua/naukovadiyalnist/naukovi-konferencii/
13. Прокопенко Т. О., Ободовский Б. П. Дослідження впливу компетентностей
членів проєктної команди на ефективність проєкту в галузі інформаційних
технологій// Вісник Національного технічного університету «ХПІ». Серія:
Стратегічне управління, управління портфелями, програмами та проектами.
2020. No 2, ст. 50-55
14. Tetiana Prokopenko, Yaroslav Povolotskyi CONCEPTUAL PROCEDURE FOR
ESTIMATING THE PERFORMANCE PROJECT BASED ON FLEXIBLE
SCRUM METHODOLOGIES IN THE FIELD OF INFORMATION
TECHNOLOGIES. Bulletin of NTU "KhPI". Series: Strategic Management,
Portfo-lio, Program and Project Management No. 2(4) (2021). – Р.60-66
15. Hamed Taherdoost, Decision Making Using the Analytic Hierarchy Process
(AHP); A Step by Step Approach. International Journal of Economics and
Management System, 2017. ffhal-02557320f
16. Прокопенко Т.О., Лавданська О.В. Інформаційна модель керування проектами
галузі інформаційних технологій в умовах гнучкої методології Scrum.
Міжнародний науково-технічний журнал Проблеми управління та
інформатики. 2021 №2. С. 129 – 138.
17. ISO 12207 — Процеси життєвого циклу програмних засобів
18. ISO 15504 — Оцінка й атестація зрілості процесів створення і супроводи
програмних засобів і інформаційних систем, що доцільно використовувати
при розробці комплексів програм.
85
19. ISO 10006:1996 "Адміністративне управління якістю. Провідні вказівки по
забезпеченню якості при управлінні проєктом"/
20. ISO 10007:1995 "Адміністративне управління якістю. Провідні вказівки по
управлінню конфігурацією"
21. М.Г. Круглов, П.М. Козлов Управління якістю проєктів корпоративних
інформаційних систем
22. Бакаєв Л. О. Кількісні методи в управлінні інвестиціями. – К., 2000.
26. Бланк И. А. Інвестиційний менеджмент. – К., 2001. 25. Власова А.М.,
Краснокутська Н.В. Інноваційний менеджмент: Навч. посібник. К.: КНЕУ,
2002. – 92с.
27. Гончарова Н., Перерва П. Маркетинг інноваційного процесса – К., 2002. – с.
8- 256;
28. Губський Б.В. Інвестиційні процеси в глобальному середовищі. – К., 2002.
35.Економіка виробничого підприємства / Під ред. Петровича. - К., 2001;
36.Загородній А. В., Стадницький Ю. С. Менеджмент реальних
інвестицій. – К., 2000.
29. Золотогоров В.С. Інвестиційне проєктування. – Мн., 2002.
30. Інформаційні системи і технології в економіці: Посібник для студентів вищих
навчальних закладів / За ред. В.С. Пономаренка. – К. :
Видавничий центр „Академія”, 2002. – 544с.
31. Керівництво з питань проєктного менеджменту / Під ред. С.Д. Бушуєва, 2-е
вид., перероб. – К.: Видавничій дім “Деловая Украина”, 2000. – 198 с.
32. Кобиляцький Л.С. Управління проєктами: Навч. посіб. – К.: МАУП, 2002. –
2005 с.: іл. – Бібліогр.: с. 193 – 196.
33. Куденко Н.В. Стратегічний маркетинг: Навч. Посібник.- К.: КНЕУ, 2001.- 152с.
34. Орлов О.О. Планування діяльності промислового підприємства.
Підручник. – К.: Скарби, 2002. – 336 с.
35. Плоткін Я.Д., Янушкевия О.К. Організація і планування виробництва: Навч.
видання. Львів: Світ, 2001 – с. 28-36;
86
36. Покровний С.Ф. Підприємництво: стратегія, організація, ефективність: Навч.
посібник . - К.: КНЕУ, 2002 – 350с.;
37. Проєктний аналіз. – Київ: ТОВ “Видавництво Лібра”, 1999. –
368 с.
38. Сизоненко В. Підприємництво. – К., 2002р.
39. Ситник В. Ф., Писаревська Т.А., Єрьоміна Н.В., Краєва О. Основи інформа-
ційних систем : Навч. посібник . – К. : КНЕУ, 1997. – 252 с.
40. Тян Р.Б., Холод Б.І., Ткаченко В.А.Управління проєктами.//Київ. 2003. с.221;
41. Управління дослідженнями, розробками та інноваційними проєктами / Под.
ред. С.В. Валдайцева. – СПб., 2003. – с. 6-205;
42. Швиданенко Г.О. Обґрунтування інвестиційних проєктів у процесі трансфор-
мації форм власності. – К., 2002.
43. Куденко Н.В. Стратегічний маркетинг: Навч. Посібник.- К.: КНЕУ, 2001.- 152с.
62.Покровний С.Ф. Підприємництво: стратегія, організація, ефективність:
Навч. посібник . - К.: КНЕУ, 2002 – 350с.;
44. .Інформаційні системи і технології в економіці: Посібник для студентів вищих
навчальних закладів / За ред. В.С. Пономаренка. – К. :
Видавничий центр „Академія”, 2002. – 544с.
45. Управління ризиками //http://wiki.tntu.edu.ua/Управління_ризиками 46. Р.Б.
Тян, Б.І. Холод, В.А. Ткаченко. Управління проєктами. Підручник. – К. 2004.,
- 224 с.
47. Методичні рекомендації і завдання до контрольної роботи з курсу: "Інвести-
ційні інструменти проєктного менеджменту " для слухачів всіх форм навчання
спеціальності 8.000003 "Управління проєктами"
48. Мізюк Б.М. Особливості стратегічного управління підприємствами / Б.М.
Мі- зюк // Фінанси України. – 2002. – №12. – С. 31 – 36.
49. Морозов О.В., Такчук Л.М. Організаційно-економічні фактори управління
якістю на підприємствах: Монографія / О.В. Морозов, Л.М. Ткачук. – Вінниця:
УНІВЕРСУМ-Вінниця, 2005. – 138 с.
87
50. Немчин М.С., Хобта В.М. Методика управління ризиками інвестиційних
проєктів / М.С. Немнич, В.М. Хобта // Матеріали всеукраїнської міжвузівської
наукової студентської конференції. – Київ, Київський національний
економічний університет імені Вадима Гетьмана. – 2009, С. 85 – 86.
51. Овчаренко Л. Інноваційне підприємство: світовий досвід реалії України //
Економіка. Фінанси. Право. – 2001. - №2. – с. 3-5;
52. Одрехівський М.В. Методологічні аспекти організаційного проєктування ін-
новаційних підприємств. // Регіональна економіка. – 2000. - №3. – с. 8894;
53. Пересада А.А., Майорова Т.В. Інвестиційне кредитування: Навч. посібник /
А.А. Пересада, Т.В. Майборода. – К.: КНЕУ, 2002. – 271 с.
54. Пересада А.А. Управління інвестиційним процесом / А.А. Пересада. – К.:
Лібра, 2002. – 472 с.
55. Про інвестиційну діяльність: Закон України // Відомості Верховної Ради
України. - 1992. - № 10. - Ст. 138; 1998. - №33. - Ст. 226; 1999. - №31. - Ст. 248.
56. Ситніченко В. та ін. Удосконалення системи менеджменту підприємства на
принципах якості / В. Ситніченко та ін. // Стандартизація, Сертифікація,
якість. – 2004. – №5. – С. 55 – 58.
57. Словник-довідник з питань управління проєктами./ Бушуєв С.Д. Українська
асоціація управління проєктами. – К.: Видавничий дім „Деловая Украина”,
2001. – 640 с.
58. Словник-довідник з питань управління проєктами. – К:ВІПОЛ,2001.
89.Стратегічне управління: Метод. вказ. для студентів спеціальності
«Економіка підприємством», «Фінанси» / Упоряд. В.І. Хомяков та ін. –
Черкаси: ЧДТУ, 2003. – 20 с.
59. Тарасюк Г.М. Управління проєктами: Навч. посібн. для вузів / Г.М.
Тарасюк. – 2-е вид. – К.: Каравела, 2006. – 320 с.
60. Тесля Ю.М. Системна організація управлінських взаємодій як інструмент
підвищення ефективності реалізації складних проєктів / Ю.М. Тесля,
І.І. Оберемок, О.Г. Тімінський // Вісник ЧДТУ. – 2008. – №2. – С. 100 – 105.
88
61. Тупчієнко О. Управління затратами / О. Тупчієнко. – Кіровоград:
Центральне українське видавництво, 2004. – 220 с.
62. Тян Р.Б. та ін. Управління проєктами: Підручник для вузів / Р.Б. Тян та ін.
– К.: ЦНЛ, 2004. – 224 с.
63. Управління ресурсами підприємства: Навч. посібн. для вузів / В.
Крамаренко, Б. Холод, Ю. Воробйов та ін. – К.: ЦНЛ, 2004. – 288 с.
64. Фінансова діяльність підприємства: Підручник / О.М. Бандурка та ін. – К.:
Либідь, 2002. – 383 с.
65. Чирков В. Эффектометрия / В. Чирков. - К.: Феникс, 2005. – 240 с.
66. Чумаченько М. Амортизаційні відрахування - суттєве джерело фінансу- вання
інвестицій підприємства / М. Чумаченько // Бухгалтерський облік і аудит. –
2004. – №8. – с. 6 – 8.
67. Шаповал М.І. Основи стандартизації, управління якістю і сертифікації:
Навч. посібник / М.І. Шаповал. – К.: Вид-во ЄУ, 2001. – 173 с.
68. Шелудько В.М. Фінансовий менеджмент: Підручник для вузів / В.М.
Шелудько. – К.: Знання, 2006. – 440 с.
69. Щукін Б.М. Аналіз інвестиційних проєктів: Конспект лекцій / Б.М. Щукін.
– К.: МАУП, 2002. – 128 с.
70. Вдовічен А.А., Черешньовська Г.М. Методи оцінки ефективності інве-
стиційних проєктів // http://intkonf.org/kenvdovichen-aa-chereshnovska-gm-
metodi-otsinki-efektivnosti-investitsiynih-proektiv/
71. Верба В.А. «Проєктний аналіз (2000)» / В.А.
Верба // http://library.if.ua/books/134.html
72. Грещак М. Г., Коцюба О. С. Управління витратами: Навч.-метод. посіб- ник
для самост. вивч. дисц. / М.Г. Грещак, О.С. Коцюба. – К.: КНЕУ, 2002. – 131 с.
// http://fingal.com.ua/content/view/204/39/
73. Дворнікова О.О. Управління якістю на підприємствах торгівельного бізнесу /
О.О. Дворнікова // http://intkonf.org/dvornikova-oo-upravlinnya-
yakistyunapidpriemstvah-torgivelnogo-biznesu/

89

Репозиторій ЧДТУ