Управління проектом розробки web-орієнтованої системи

Устименко, Богдан Денисович

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

Title:	Управління проектом розробки web-орієнтованої системи
Authors:	Тесля, Юрій Миколайович Устименко, Богдан Денисович
Keywords:	управління проєктом;інформаційна система;WBS проекту;концепція програми;SWOT, PEST аналіз проект
Issue Date:	4-Dec-2021
Abstract:	Прогрес сучасної економічної теорії й практики нерозривно пов’язаний з необхідністю аналізу та обґрунтування тих чи інших управлінських рішень, зокрема проектних. Методологія управління проектами дає можливість чітко визначити мету і результати проекту, дати їм кількісні характеристики, тимчасові, вартісні і якісні параметри проекту, створити чіткий план проекту, виділити, оцінити ризики і запобігти можливим негативним наслідкам під час реалізації проекту. На сьогоднішній день методологія управління проектами довела своє право вважатися одним з найефективніших способів успішної реалізації проектів та є важливою науковою задачею. Метою роботи є розкриття методології управління проектом розробки програмного забезпечення на прикладі типової конкретної ситуації, пов’язаної з розробкою конкретного ІТ проекту, оволодіння навичками вирішення комплексу задач передінвестиційної фази проектів, оволодіння методологією багатоваріантного обґрунтування проектних рішень. У роботі розглянуто сучасні форми організації інвестиційних процесів ІТ компанії. Проведено аналіз беззбитковості операційної діяльності проекту. Обраховано оцінку показників ефективності проекту, прогноз витрат операційної діяльності, прогноз грошових потоків проекту, прогноз витрат, прогноз динаміки показників операційної діяльності. Було проведено розробку кошторису. Висвітлено необхідні навички з фінансово-економічними та звітно-аналітичними аспектами роботи проектного менеджера.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/7296
Appears in Collections:	126 Інформаційні системи та технології (IT Project Management)

Files in This Item:

File	Description	Size	Format
РЕП_МАГ_Устименко_МІТ-2010.pdf Restricted Access		3.11 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
Кафедра інформаційних технологій проектування
Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)
на тему: «Управління проектом розробки web-орієнтованої системи»
Виконав: студент 2 курсу, групи МІТ-2010
Спеціальності
122 «Комп’ютерні науки»
»
(шифр і назва спеціальності)
Освітньої програми
Управління ІТ-проектами
я
Устименко Б.Д
(прізвище та ініціали)
Керівник
(прізвище та ініціали)
Рецензент
(прізвище та ініціали)
Черкаси 2021 року
АНОТАЦІЯ
Прогрес сучасної економічної теорії й практики нерозривно
пов’язаний з необхідністю аналізу та обґрунтування тих чи інших
управлінських рішень, зокрема проектних. Методологія управління
проектами дає можливість чітко визначити мету і результати проекту, дати
їм кількісні характеристики, тимчасові, вартісні і якісні параметри проекту,
створити чіткий план проекту, виділити, оцінити ризики і запобігти
можливим негативним наслідкам під час реалізації проекту. На
сьогоднішній день методологія управління проектами довела своє право
вважатися одним з найефективніших способів успішної реалізації проектів
та є важливою науковою задачею.
Метою роботи є розкриття методології управління проектом
розробки програмного забезпечення на прикладі типової конкретної
ситуації, пов’язаної з розробкою конкретного ІТ проекту, оволодіння
навичками вирішення комплексу задач передінвестиційної фази проектів,
оволодіння методологією багатоваріантного обґрунтування проектних
рішень.
У роботі розглянуто сучасні форми організації інвестиційних
процесів ІТ компанії. Проведено аналіз беззбитковості операційної
діяльності проекту. Обраховано оцінку показників ефективності проекту,
прогноз витрат операційної діяльності, прогноз грошових потоків проекту,
прогноз витрат, прогноз динаміки показників операційної діяльності. Було
проведено розробку кошторису. Висвітлено необхідні навички з
фінансово-економічними та звітно-аналітичними аспектами роботи
проектного менеджера.
4
ЗМІСТ
ВСТУП 7
РОЗДІЛ І 10
КОНЦЕПЦІЯ ПРОЕКТУ ‘Your next’ 10
1.1 Формування ідеї та цілей проекту 10
Ініціація бізнес-ідеї та розробка концепції інвестиційного проекту. На
стадії розробки (передінвестиційній фазі) виконуються такі види робіт:
10
1.2 SWOT, PEST аналіз проект 13
1.2.1 PEST аналіз проекту: 13
1.2.2 SWOT аналіз проекту: 15
1.3 Резюме проекту 16
1.4 Висновки до розділу 1: 18
РОЗДІЛ ІІ 19
ГАЛУЗІ ЗНАНЬ УПРАВЛІННЯ ПРОЕКТУ 19
2.1 Управління змістом проекту 19
2.1.1 WBS проекту: 20
2.2 Управління ресурсами проекту 22
2.3 Управління часом проекту 24
2.3.1 Діаграма Ганта: 24
2.4 Управління вартістю проекту 26
2.5 Управління якістю проекту. 28
2.5.1 Дослідження чинників що впливають на якість. 31
2.5.2 Розроблена діаграма Ісікави та коментарі до неї. 35
2.7 Управління ризиками проекту. 36
2.7.1 План управління ризиками. 40
2.8 Управління інформаційним зв’язком та інтеграцією в проекті 46
2.8.1 Схема інформаційного обміну в IT проекті 47
2.8.2 Опис застосованої гнучкої технології (Agile, Scrum, Kanban) 49
2.9 Контроль та мотивація проекту 52
2.9.1 Канбан дошка в Асані проекту ‘Your next’: 53
2.10 Висновки до розділу 2: 53
5
РОЗДІЛ 3 54
ОЦІНКА ЕФЕКТИВНОСТІ ПРОЕКТУ 54
3.1 Планування фінансових ресурсів інвестиційної фази проекту 54
3.2 Розробка зведеного кошторису витрат інвестиційної фази проекту 56
3.3 Планування амортизаційних витрат операційної діяльності 57
3.4 Планування кредитних процесів операційної діяльності 60
3.5 Прогноз доходів операційної діяльності 62
3.6 Прогноз витрат операційної діяльності 62
3.7 Оцінка показників ефективності проекту 64
3.8 Висновки до розділу 3: 66
ВИСНОВОК 68
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 70
6
ВСТУП
Актуальність теми. В наш час розробка вебсайтів використовується
практично з усіх причин про які ви можете подумати, включаючи продаж
товарів та надання послуг. Станом на січень 2021 року в усьому світі
налічувалося 4,66 мільярда активних користувачів Інтернету, що становить
59,5% населення планети. З цієї загальної кількості 92,6% (4,32 мільярда)
мали доступ до Інтернету за допомогою мобільних пристроїв. Прогрес
економічної теорії й практики міцно пов’язаний з потребою аналізу та
обґрунтування тих чи інших управлінських рішень, які повинен приймати
проектний менеджер. Проектний аналіз був виділений в окремий напрям
науки насамперед через необхідність системного підходу до оцінки та
підготування проектів як цілісної системи. Досвід по проектуванню, що
був накопичений під час адміністративної економіки, засновувався на
методах адміністративно-командної системи і був відірваний від сучасної
методології й великого набору інструментів, що застосовується у світовій
економічній науці.
Вебсайт є важливим для кожного власнику бізнесу, нижче наведенні
причини його важливості:
Діловий вплив. Користувачі смартфонів проводять більше часу в
Інтернеті. Дослідження показує, що користувачі смартфонів щодня
витрачають щонайменше 162 хвилини на кілька додатків на своїх
смартфонах. Тож наявність додатка може допомогти збільшити видимість
бізнесу та сприяти зростанню бізнесу. Це пов’язано з тим, що люди, як
правило, спілкуються із зображеннями, які бачать частіше.
Лояльність клієнтів. Вебсайт можна використовувати для
підвищення лояльності клієнтів, оскільки це дозволяє компаніям
7
спілкуватися безпосередньо зі своїми клієнтами за допомогою покупок у
програмі, оголошень, рекламних акцій та сповіщень.
Дієвий інструмент маркетингу. Вебсайт можна використовувати як
маркетинговий інструмент для охоплення цільових споживачів. Власникам
підприємств не потрібно друкувати об’ємні брошури, щоб залучити нових
клієнтів, оскільки вебсайти можуть надавати інформацію, форми
реєстрації / бронювання, рахунки, стрічку новин та інші цінні
маркетингові інструменти. Клієнти можуть бути в курсі рекламних
пропозицій, просто використовуючи push-повідомлення.
Мета дослідження є розкриття методології управління проектом
розробки програмного забезпечення на прикладі типової конкретної
ситуації, пов’язаної з розробкою конкретного ІТ проекту, оволодіння
навичками вирішення комплексу задач передінвестиційної фази проектів,
оволодіння методологією багатоваріантного обґрунтування проектних
рішень.
Предметом дослідження є методологічні аспекти вирішення задач на
усіх фазах розробки проекту.
Об’єктом дослідження є типова проектна ситуація, яка характерна
для великого різноманіття ІТ проектів в різних галузях діяльності.
Галузь дослідження - галузь інформаційних технологій.
Методи дослідження. В роботі застосовані методи веб-розробки
згідно з набутих під час навчання знань.
Класичний проектний менеджмент.
● Agile.
● Scrum.
● Lean.
● Kanban.
8
Наукова новизна одержаних результатів. У роботі використовується
поєднання різноманітних методів управління проектом розробки ПО.
Практичне значення одержаних результатів. Практична значимість
даної роботи полягає в тому, що висновки та прогнози зроблені під час
роботи можуть бути практично застосовані при розробці реального
вебсайту.
9
РОЗДІЛ І
КОНЦЕПЦІЯ ПРОЕКТУ ‘Your next’
1.1 Формування ідеї та цілей проекту
Ініціація бізнес-ідеї та розробка концепції інвестиційного проекту.
На стадії розробки (передінвестиційній фазі) виконуються такі види робіт:
● визначення інвестиційних можливостей і висунення бізнес-ідеї;
● аналіз альтернативних варіантів проекту і попередній вибір проекту;
● підготовка проекту - розробка попереднього техніко-економічного (ПТЕО)
і техніко-економічного обґрунтування (ТЕО);
● функціональні дослідження проекту;
● висновок на проект і рішення про інвестування (оцінний висновок).
Таке постадійне виконання передінвестиційної фази дозволяє провести
поетапну перевірку бізнес-ідеї та оцінити альтернативні варіанти рішень.
Можна виділити наступні причини появи інвестиційного задуму (ідеї
проекту):
● незадоволений попит;
● надлишкові ресурси;
● ініціатива підприємців;
● інтереси кредиторів;
● реакція на політичну ситуацію.
Бізнес-ідея в загальному вигляді відображає основні цілі проекту. Таким
чином, процес розробки проекту починається з формування його
концепції.
Процес формування концепції проекту прийнято поділяти на наступні
етапи:
1. Формулювання цілей, досягнення яких забезпечується реалізацією
проекту.
2. Формулювання попередніх альтернативних варіантів (сценаріїв
розвитку проекту), що задовольняють цілі інвестора.
3. Відбір варіантів проекту, прийнятних з точки зору термінів
реалізації та інших умов.
Розробка концепції проекту передбачає виконання наступних дій:
- Обґрунтування цілей проекту на основі вивчення ринку і аналізу
виробничих резервів;
- Попередня оцінка вартості проекту і прогноз збільшення
оборотного капіталу;
- Оцінка тривалості інвестиційного процесу та власне реалізації
проекту, терміну початку експлуатації проекту;
- Прогноз збільшення капіталу від реалізації проекту;
- Визначення джерел (інвесторів) і розмірів фінансування;
- Визначення основних характеристик проекту. До числа останніх
можна віднести:
● наявність альтернативних технічних рішень;
11
● попит на продукцію проекту;
● тривалість проекту, і в тому числі, його інвестиційної фази;
● оцінку рівня базових, поточних і прогнозних цін на
● продукцію або послуги проекту;
● перспективи експорту продукції проекту;
● складність проекту;
● обсяг і склад нормативної і проектно-кошторисної
● документації;
● інвестиційний клімат в районі реалізації проекту;
● співвідношення витрат і результатів проекту.
На основі цих характеристик проводиться попередній аналіз здійсненності
проекту. Для цієї мети можна використовувати різного роду експертні
системи. Експертна оцінка варіантів інвестиційних рішень.
1. Визначення факторів, які можуть значною мірою вплинути на
успішність виконання проекту (характеристики, представлені вище).
2. Розташування факторів в порядку убування пріоритетності. Для цього
визначається, який з факторів найбільшою мірою вплине на хід реалізації
проекту. Далі визначається найбільш істотний фактор із тих, що
залишилися і т.д.
3. Оцінка вагомості (рангу кожного з факторів). Сума рангів повинна
дорівнювати 1.
4. Оцінка варіантів проекту або проектів по кожному з факторів (критеріїв
оцінки). Максимальний бал по будь-якому з факторів дорівнює 100,
мінімальний - 0.
12
5. Експертна оцінка впливу кожного фактора (перемножевання рангу
кожного фактора на оцінку цього фактора для кожного варіанта проекту) та
визначення інтегральної оцінки пріоритетності варіантів. Дана методика
може застосовуватися як для попереднього відбору найбільш
перспективних варіантів здійснення проекту, так і для попереднього
визначення здійсненності проекту. У першому випадку для подальшого
розгляду залишаються альтернативи, що одержали найвищі результати, у
другому - отримана інтегральна експертна оцінка проекту порівнюється із
заздалегідь визначеним «обмеженням знизу». Якщо отримане експертним
шляхом значення вище встановленого мінімального рівня, проект
визнається здійсненним.
1.2 SWOT, PEST аналіз проект
1.2.1 PEST аналіз проекту:
PEST-аналіз (іноді позначають як STEP) – це здебільшого
маркетинговий інструмент, призначений для виявлення політичних (Р –
political), економічних (Е – economic), соціальних (S – social) і
технологічних (Т – technological) аспектів зовнішнього середовища, що
впливають на досліджувану проблему.
Таблиця 1.1 PEST аналіз
Політичні фактори Важливість
фактору
Проблеми офіційного оформлення вебсайту 2
Нестабільна ситуація в Україні 3
Корупція 4
13
Економічні фактори Важливість фактору
Податки на вебсайти не планують збільшувати у 3
найближчий час
Рівень доходів жителів України росте 2
Соціокультурні Важливість
фактору
Все більше людей здійснюють покупки через вебсайти 3
Фізичні магазини тимчасово втратили актуальність у 5
зв’язку з ковід-19
Підростаюче покоління звикло до використання 3
веб-сервісів
Технологічні Важливість
фактору
IT- технології розвиваються надзвичайно стрімко 5
Технології з закордону переймаються нашими 3
робітниками
Комп’ютери та телефони стають дешевше через 2
стрімкий розвиток технологій
14
Базуючись на результатах PEST аналізу, можна бачити, що наразі в Україні
сприятливі умови для створення вебсайтів, проект є потенційно успішним.
1.2.2 SWOT аналіз проекту:
Одним із основних інструментів стратегічного управління, що
оцінюють в комплексі внутрішні й зовнішні чинники, які впливають на
розвиток проекту, є SWOT-аналіз.
SWOT – початкові літери слів Strengths (Сильні сторони),
Weaknesses (Слабкі сторони), Opportunities (Можливості), Threats
(Загрози). У 1963 році в Гарварді на конференції з проблем бізнес-політики
професор К. Ендрюс уперше публічно озвучив акронім SWOT. Цей
акронім базувався візуально у вигляді матриці SWOT. Тобто, з появою
SWOT-моделі аналітики отримали інструмент для своєї інтелектуальної
праці. SWOT-аналіз – це процес установлення зв'язків між
найхарактернішими для підприємства можливостями, загрозами, сильними
сторонами (перевагами), слабкостями, наслідки якого в подальшому
можуть бути використані для формулювання і вибору стратегій
підприємства. Він проводиться з метою дослідження підприємства як
системи господарювання у певному середовищі.
Таблиця 1.2 SWOT аналіз
Загрози Можливості Сильні сторони Слабкі сторони
Сайти Доставку можна Малі затрати Плата за
монополісти здійснювати використання
самому сторонніх сервісів
15
Активність Реклама вебсайту Свобода Витрати на
розвитку пересування рекламу
конкурентів
Доповнення Немає великої Доставка товарів
товарів необхідності в
оренді площ
Базуючись на результатах SWOT аналізу, можна бачити, що проект є
потенційно успішним.
1.3 Резюме проекту
Вебсайт з продажу товарів “Your next”
Мета проекту: розробка вебсайту по продажу товарів під назвою “Your
next”
Тип проекту: вебсайт по продажу товарів
Учасники проекту та їх цілі:
Устименко Богдан Денисович - розробник, тестувальник, та керівник
проекту розробки вебсайту.
● Ціллю розробки є вебсайт по продажу товарів, з можливістю зручної
підтримки та розвитку в майбутньому, а також з мінімальною кількістю
дефектів.
● Ціллю тестування є знаходження всіх критичних дефектів у програмі під
16
час розробки та по її завершенню.
● Ціллю проекту є вебсайт з продажу товарів, що готовий до використання
та відповідає усім вимогам.
Обмеження на проект: проект повинен бути виконаний до літа 2020 року.
Вимоги до результату: кінцевим результатом повинен бути готовий до
роботи, протестований та зручний у використання вебсайт з продажу
товарів, що задовольняє вимоги кінцевого користувача.
Особливості: Вебсайт з продажу.
Альтернативи реалізації:
1. Розробка ігрового додатку. Вартість та довготривалість такої альтернативи
буде більше так як потрібен додатковий час на освоєння нового
інструментів.
2. Розробка вебсайту із залученням додаткових розробників. Така
альтернатива зменшить тривалість виконання, але збільшить вартість
проекту, що не є доцільним, так як виконання проекту вкладається в
терміни.
Дерево цілей:
"Дерево цілей" - це графічне зображення взаємозв'язку і
підпорядкованості цілей, що відображає розподіл місії і мети на цілі, під
цілі, завдання та окремі дії. Дерево цілей з кількісними показниками, що
використовуються в якості одного із засобів при прийнятті рішень, і носить
назву "дерева рішень". Головна перевага "дерева рішень" перед іншими
методами - можливість пов'язати ставлення цілі з діями, що підлягають
17
реалізації в сьогоденні. Основна ідея щодо побудови "дерева цілей" -
декомпозиція.
Рис 1.1 Дерево проекту
1.4 Висновки до розділу 1:
В даному розділі було сформовано ідеї та цілі. Також було проведено
SWOT та PEST аналізи проекту, побудовано резюме проекту.
18
РОЗДІЛ ІІ
ГАЛУЗІ ЗНАНЬ УПРАВЛІННЯ ПРОЕКТУ
2.1 Управління змістом проекту
Ефективність ІТ проекту необхідно оцінити та спрогнозувати вже на фазі
доінвестиційних досліджень, так як саме на цій фазі закладаються основи
оптимізації вартісних та кількісних показників та досягається оптимальне
співвідношення між витратами та ризиками при прийнятті рішень в ході
реалізації ІТ проекту. В термінах проектного менеджменту коло задач подібної
проробки ідеї проекту має назву “передінвестиційної фази життєвого циклу
проекту”.
Метою доінвестиційної фази є отримання обґрунтувань можливості та
доцільності реалізації ідей проектів, на підставі яких приймається доленосне
управлінське рішення – варто здійснювати ідеї, чи ні. Багатоваріантна проробка
як ідей проектів в цілому, так і окремих її аспектів з метою пошуку найбільш
раціональних варіантів проектних та управлінських рішень є тим
методологічним підходом, що гарантує розробку ефективного ІТ проекту.
Передінвестиційна фаза передбачає вирішення широкого кола задач, що
потребують координації зусиль навколо ідей проекту спеціалістів різного
профілю діяльності. Зокрема, стандарти проектного менеджменту
відокремлюють в складі передінвестиційної фази такі основні задачі (етапи):
- розробка концепції ІТ проекту ;
- аналіз інвестиційних можливостей ІТ проекту;
- техніко-економічне обґрунтування ІТ проекту;
- прийняття рішень відносно інвестиційного забезпечення ІТ проекту.
Вже сам перелік цих задач об’єктивно свідчить про ступінь важливості
передінвестиційної фази для ефективної реалізації ідей проекту та важливість
професійних знань і навичок за означеним напрямком в діяльності фахівця за
спеціалізацією “Управління ІТ проектами”.
Невід'ємним елементом передінвестиційної фази , з точки зору класичних
засад проектного менеджменту, є багатоваріантна проробка як ідеї проекту в
цілому, так і окремих її аспектів, з метою пошуку найбільш раціональних
варіантів проектних та управлінських рішень. Лише такий методологічний
підхід є гарантом появи ефективних проектів.
Класифікація проекту:
• за класом – монопроект;
• за типом – економічний;
• за видом – інвестиційний;
• за тривалістю – короткостроковим;
• за масштабом – середній;
• за ступенем складності – простий.
2.1.1 WBS проекту:
Структура декомпозиції робіт, тж. ієрархічна структура робіт (англ. work
breakdown structure, WBS) у проектному менеджменті та системотехніці є
орієнтованою на доконане виконання проекту декомпозицією проекту на менші
частки. Структура декомпозиції робіт є ключовою часткою робіт по проекту, яка
організовує командну роботу по проекту у керовані частини. PMBOK визначає
структуру декомпозиції робіт як «ієрархічну декомпозицію робіт, що має бути
виконаною командою проекту та орієнтована на успішне завершення проекту».
20
Рис 2.1 WBS проекту
21
Рис 2.2 Сітьовий графік
2.2 Управління ресурсами проекту
Управління ресурсами - одна з головних підсистем управління проектом,
яка включає процеси планування, закупівлі, постачання, розподілу, обліку і
контролю ресурсів.
Поняття "ресурс" в методології управління проектами трактується як все,
що має в своєму розпорядженні проект, у тому числі трудові, фінансові і
матеріально-технічні ресурси, команда проекту, час (тривалість, терміни
обмеження), інформація, знання і технології.
Основна мета управління ресурсами - забезпечити їх оптимальне
використання для досягнення кінцевої мети управління проектом.
У кожний поточний момент часу ресурси проекту обмежені і тому
основними завданнями управління ресурсами є:
- оптимальне планування ресурсів;
- управління матеріально-технічним забезпеченням, у тому числі:
- управління закупівлею ресурсів;
- управління постачанням ресурсів;
- управління запасами;
22
- управління розподілом ресурсів за видами робіт. Закупівля ресурсів є
центральним елементом системи управління ресурсами.
Під закупівлями розуміють заходи, направлені на забезпечення проектів
ресурсами, тобто, майном (товарами), виконанням робіт (послуг). Закупівлі і
постачання взаємозв'язані та є, по суті, двома сторонами процесів
матеріально-технічного забезпечення проекту.
Управління закупівлями або матеріально-технічним забезпеченням
проекту - це підсистема управління проектом, що включає процеси придбання
товарів, продукції і послуг для проекту від зовнішніх
організацій-постачальників.
Дана підсистема складається з планування матеріально-технічного
забезпечення, вибору постачальників, укладання договорів і їх ведення,
забезпечення постачання, закриття договорів.
Управління постачаннями виділяється як самостійна підсистема поряд з
управлінням закупівлями, яка включає:
- планування постачань;
- організацію бухгалтерського обліку;
- доставку, приймання і зберігання товару;
- облік і контроль постачань.
Основні принципи планування ресурсів проекту:
На стадії планування проводиться збалансований аналіз комплексу робіт і
ресурсів з врахуванням обмежень та їх прогнозний розподіл на основі графіків
потреби в ресурсах. Планування ресурсів за проектом є основою їх формування
в часі та визначення можливості забезпечення ресурсами для підписання
договорів закупівлі ресурсів, планування постачання ресурсів, а також
розподілу вже куплених ресурсів за проектними роботами.
Як основна складова управління проектами ресурсне планування включає:
23
● розробку і збалансований аналіз комплексів робіт і ресурсів, направлених на
досягнення цілей проекту;
● розробку системи розподілу ресурсів і призначення відповідальних виконавців;
● контроль за ходом робіт - порівняння планових параметрів робіт з фактичними і
розробка коректуючих дій.
Є два основні методи планування ресурсів проекту:
● планування при обмеженні за часом;
● планування при обмежених ресурсах.
Перший підхід - ресурсне планування при обмеженому часі, передбачає
фіксовану дату закінчення проекту і призначення на проект додаткових ресурсів
на періоди перевантажень.
Другий підхід - планування при обмежених ресурсах, передбачає, спочатку
задану кількість доступних ресурсів, яка не може бути змінена.
В результаті ресурсного планування менеджер проекту має можливість
перейти до наступної фази управління ресурсами -організації закупівель і
постачань.
Рис 2.3 Використання трудових ресурсів
2.3 Управління часом проекту
2.3.1 Діаграма Ганта:
Діаграма Ґанта являє собою відрізки (графічні плашки), розміщені на
горизонтальній шкалі часу. Кожен відрізок відповідає окремому завданню або
підзадачі. Завдання і підзадачі, складові плану, розміщуються по вертикалі.
Початок, кінець і довжина відрізка на шкалі часу відповідають початку, кінцю і
24
тривалості завдання. На деяких діаграмах Ґанта також показується залежність
між завданнями.
Діаграма може використовуватися для представлення поточного стану
виконання робіт: частина прямокутника, що відповідає завданню,
заштриховується, відзначаючи відсоток виконання завдання; показується
вертикальна лінія, що відповідає моменту «сьогодні».
Рис 2.3 Діаграма Ґанта
25
2.4 Управління вартістю проекту
Управління вартістю проекту пов'язане з одним із трьох основних
обмежень у проектах – по вартості, термінам і вимогам до предметної області.
Дотримання всіх цих обмежень дозволяє завершити проект у рамках
запланованих термінів і бюджету при повному задоволенні визначених раніше
чекань замовника, (тобто при повному досягненні всіх заздалегідь визначених
результатів) Основна мета управління вартістю проекту полягає в тому, щоб
завершити його в рамках затвердженого бюджету. Тому основною задачею РМ
при управлінні вартістю є визначення та затвердження бюджету проекту. РМ в
першу чергу приділяє значну увагу управлінню прямими витратами проекту,
але сучасна тенденція в керуванні проектами веде до того, що його роль у
керуванні вартістю проекту буде зростати за рахунок усе більшого включення
нетрадиційних областей управління вартістю. Можна припустити, що в
майбутньому усе більше керівників проектів будуть мати справу з управлінням
непрямими витратами і витратами по проектах. Для обліку витрат також досить
важливо установити відповідний часовий порядок збору фактичних даних по
витратах. Бюджет проекту повинний бути синхронізований із процедурою
їхнього збору. Наприклад, якщо РМ відповідає за вартість матеріалів, то
необхідно визначити, коли в бюджеті повинний бути показана витрата. Чи
повинно це відбуватися при прийнятті керівником проекту рішення про
покупку, або при постачанні купленого? А може бути, варто фіксувати витрата
після завершення приймання купленого, або в момент, коли покупка
оплачується? Подібні проблеми можуть перетворити управління вартістю
проекту в кошмар. Таким чином, якщо в проекті не здійснюється відповідне
керування вартістю, то він обов'язково вийде з-під контролю, і для його
завершення буде витрачено більше грошей, чим передбачалося. Управління
вартістю проекту націлене саме на запобігання такої ситуації. Отже для
26
визначення вартості проекту потрібно знати вартість складових ресурсів
проекту, час виконання робіт і вартість цих робіт. Таким чином, оцінка вартості
проекту починається після визначення робіт проекту і структури необхідних
ресурсів. Контроль вартості проекту здійснюється в процесі реалізації проекту
такими методами як аналіз освоєного обсягу, прогнозування витрат і іншими.
Отже, що обрахувати вартість проекту необхідно просумувати:
1. Зарплата проектної команди і керівника проекту;
2. Вартість матеріальних ресурсів;
3. Вартість енергетичних та інших ресурсів;
4. Вартість рекламних послуг – 20 тис. грн;
5. Інші витрати;
6. Резервні витрати.
Для того, щоб спростити розрахунок вартості ресурсів доцільно використати
автоматичний підрахунок в MS Project та представити у вигляді відповідних
діаграм
Рис 2.4 Локальний кошторис матеріальних затрат
Рис 2.5 Локальний кошторис трудових затрат
27
Рис 2.6 Зведений кошторис
2.5 Управління якістю проекту.
Якість – одна з фундаментальних категорій, що визначають спосіб життя,
соціальну й економічну основу для розвитку людини і суспільства. Якість є
важливим інструментом у боротьбі за ринки збуту.
Якість визначається дією багатьох випадкових, місцевих і суб'єктивних
факторів. Для попередження впливу цих факторів на рівень якості необхідна
система керуванняякістю. У ринковій економіці величезна увага приділяється
проблемам якості. Це обумовлено наявністю конкурентного середовища. По
методах здійснення конкуренція поділяється на цінову (витиснення конкурентів
шляхом зниження, збивання ціни) і нецінову, при якій ту ж ціну пропонується
товар з більш високими якісними параметрами і комплексом послуг, що означає
в термінах маркетингу "товар із супроводом".
Тільки якість може залучити споживача. Серйозна конкурентна боротьба
обумовила в країнах з розвиненою ринковою економікою розробку програм
підвищення якості. У наукових дослідженнях і у практиці виникла необхідність
вироблення об’єктивних показників для оцінки здібностей фірм робити
продукцію з необхідними якісними характеристиками. Ці характеристики
28
підтверджуються сертифікатом відповідності на продукцію. Багато
фірм-виробників
мають системи якості, що відповідають міжнародним стандартам.
У сучасних умовах саме сертифікат на систему якості служить
вирішальним фактором для укладання контракту на постачання продукції.
Успішна реалізація якісного продукту споживачу є головним джерелом
існування будь-якого підприємства. У ринковій економіці виробник і споживач
самі знаходять себе на ринку, їхні мотивації базуються на фінансовому виграші
і максимізації споживчого ефекту. При цьому споживач має вибір між
найкращими товарами різних виробників. Споживач, будучи головною фігурою,
визначає напрямок розвитку виробництва, здобуваючи товари і послуги по
своєму власному бажанню. Тим самим споживач указує, що варто робити.
Говорячи про проблему якості, слід зазначити, що за цим поняттям завжди
стоїть споживач. Саме він вибирає найбільш кращі властивості. Якість є
задачею номер один в умовах ринкової економіки, де відбулися справжні
революції в цій області. Саме за допомогою сучасних методів менеджменту
якості передові закордонні фірми домоглися лідируючих позицій на різних
ринках.
Між якістю й ефективністю виробництва існує прямий зв'язок.
Підвищення якості сприяє підвищенню ефективності виробництва, приводячи
до зниження витрат і підвищенню частки ринку. Кінцева якість залежить від
якості роботи на кожнім етапі.
Отже, якість є комплексним поняттям, що відбиває ефективність усіх сторін
діяльності фірми. В ході розвитку економіки в Україні все більша увага
приділяється якості. В даний час однією із серйозних проблем для вітчизняних
підприємств є створення системи якості, що дозволяє забезпечити виробництво
конкурентноздатної продукції. Система якості важлива при проведенні
переговорів із закордонними замовниками, що вважають обов'язковою умовою
29
наявність у виробника системи якості і сертифіката на цю систему, виданого
авторитетним органом, що сертифікує. Система якості повинна враховувати
особливості підприємства, забезпечувати мінімізацію витрат на розробку
продукції і її впровадження. Споживач бажає мати впевненість, що якість
продукції, що поставляється, буде стабільною і стійкою.
У теорії і практиці керування якістю виділені дві проблеми: якість
продукції і менеджмент якості. Забезпечення якості вимагає чималих витрат.
Донедавна основна частка у витратах на якість приходилася на фізичну працю.
Але сьогодні висока частка інтелектуальної праці. Повинна бути гармонія всіх
складових професійного впливу на якість. Якість є важливим інструментом у
боротьбі за ринки збуту. Саме якість забезпечує конкурентоздатність товару.
Вона складається з технічного рівня продукції і корисності товару для
споживача через функціональні, соціальні, естетичні, ергономічні, екологічні
властивості. При цьому конкурентоздатність визначається сукупністю якісних і
вартісних особливостей товару, що можуть задовольняти потреби споживача, а
також витратами на придбання і споживання відповідного товару. Варто
враховувати, що серед продукції аналогічного призначення більшою
конкурентоздатністю володіє та, котра забезпечує найвищий корисний ефект
стосовно сумарних витрат споживача. Безумовно, підвищення якості сполучене
з витратами. Однак вони окупляться завдяки отриманому прибутку. Заняття
лідируючого положення на ринку неможливо без розробки й освоєння нових
товарів (модифікованих, поліпшених). Якість представляє, з погляду споживача,
придатність продукту для досягнення його цілей. Виробник може виходити з
того, що імовірність покупки продукту прямо залежить від його сприйнятої
якості. Дослідження, проведені в ряді країн, показали, що в компаніях, що мало
приділяють уваги якості, до 60% відсотків часу може іти на виправлення браку.
Фірми, що функціонують у ринковій економіці, формулюють політику в області
якості таким чином, щоб вона стосувалася діяльності кожного працівника, а не
30
тільки якості пропонованих виробів чи послуг. У політиці чітко визначаються
рівні стандартів якості роботи для конкретної фірми й аспекти системи
забезпечення якості.
При цьому продукція заданої якості повинна бути поставлена споживачу в
заданий термін, у заданих обсягах і за прийнятну ціну.
Необхідні умови для впровадження управління якістю:
– зацікавленість керівництва;
– забезпечення колективної участі;
– забезпечення індивідуальної участі;
– більш повне залучення поставників;
– забезпечення якості функціонування систем керування;
– розробка і реалізація короткострокових планів і довгострокової стратегії
поліпшення роботи;
– створення системи визнання заслуг.
2.5.1 Дослідження чинників що впливають на якість.
Процеси управління якістю проектів включають в себе наступне:
1. Планування якості - визначення того, які з стандартів якості ставляться до
даногопроекту і як їх задовольнити.
2. Процес забезпечення якості - виконання планових систематичних операцій за
якістю, які забезпечують виконання всіх передбачених процесів, необхідних для
того, щоб проект відповідав обумовленим вимогам.
3. Процес контролю якості - моніторинг певних результатів з метою визначення
їх відповідності прийнятим стандартами якості та визначення шляхів усунення
причин, що викликають незадовільне виконання.
31
Ці процеси взаємодіють як один з одним, так і з процесами з інших областей
знань. Залежно від потреб проекту в кожному процесі можуть брати участь
один або кілька осіб або груп.
Кожен процес має місце принаймні один раз в ході кожного проекту, а
якщо проект розділений на фази - то в одній або декількох фазах проекту.
Модель управління якістю, в основі своїй відповідає вимогам Міжнародної
організації зі стандартизації (ISO). Ця узагальнена модель враховує також
авторські моделі управління якістю, розроблені Демінгом (Deming), (Juran),
Кросбі(Crosby) та ін, і загальні моделі, такі як Тотальне управління якістю
(TQM), Сигма 6 (Six Sigma), Аналіз характеру та наслідків відмов, Контрольні
оцінки на етапі проектування, Думка замовника, Вартість якості (COQ) і
Постійне вдосконалення. Управління якістю проекту має бути спрямована як на
керування проектом, так і на продукт проекту.
Хоча управління якістю проекту поширюється на всі проекти, незалежно
від продукту проекту, але конкретні заходи і методи забезпечення якості
продукту залежать від конкретного типу продукту, одержуваного в рамках
проекту. Наприклад, для управління якістю програмних продуктів потрібні інші
підходи і заходи, ніж для атомних електростанцій, хоча підходи до управління
якістю проекту однакові в обох випадках. Але в кожному разі невиконання
вимог до якості по якомусь критерію може привести до серйозних негативних
наслідків для учасників проекту. Наприклад:
- Задоволення вимог замовника за рахунок понаднормової роботи команди
проектуможе викликати негативні наслідки у вигляді перевтоми співробітників,
появи необґрунтованих помилок або доопрацювань.
- Досягнення цілей, позначених в розкладі проекту, за рахунок поспішного
проведення перевірок якості може призвести до негативних наслідків, якщо
помилки залишаться непоміченими.
Якість - це ступінь, в якій сукупність внутрішніх характеристик чогось або
32
відповідає вимогам "(Американське товариство з якості, 2000 р.). Входами для
розробки вимог проекту є заявлені й передбачувані потреби. Найважливішим
елементом в управлінні якістю проекту є можливість перетворити потреби,
побажання та очікування учасників проекту у вимоги в ході аналізу учасників
проекту, що проводиться в рамках управління змістом проекту. Необхідно чітко
розуміти різницю між якістю і сортом.
Сорт - це категорія (клас), що присвоюється продуктам або послугам, які
мають одне і те ж функціональне призначення, але різні технічні
характеристики.
Низька якість - це завжди проблема, чого не можна сказати про низький
сорт.
Наприклад, програмний продукт може бути високої якості (без явних помилок,
хороша супровідна документація) і низького сорту (обмежене число
можливостей), або низької якості (часті збої, недостатньо повний опис), але
високого ґатунку (безліч різних функцій).
Менеджер проекту і команда управління проектом відповідають за визначення і
забезпечення необхідних рівнів, як якості, так і сортів.
Сучасне управління якістю служить доповненням до управління
проектом.
Наприклад, обидві дисципліни визнають важливість наступних положень:
- Задоволення потреб замовника. Розуміння, оцінка, визначення і керування
очікуваннями замовника таким чином, щоб його вимоги виявилися виконаними.
Для цього необхідно забезпечити поєднання відповідності вимогам (проект
повинен зробити те, що було заявлено) та придатності до використання
(Продукт або послуга повинні задовольнятиреальним потребам). Керівництво
Американського товариство з якості, 1999,с. 13-14) є основою підвищення
якості. На додаток до цього ініціативи щодо підвищення якості, вживаються
виконуючою організацією (як передбачено в моделях Тотального управління
33
якістю і Сігма 6), можуть підвищити як якість управління проектом, так і якість
продукту проекту.
Серед моделей, які передбачають покращення процесу, можна назвати
Malcolm Baldrige, CMM ® і CMMISM.
Якість завжди приносить прибуток ІТ компанії, оскільки сприяє кращому
задоволенню клієнтів і збільшення їх кількості. Існує безліч визначень якості.
Наприклад, у старій редакції міжнародних стандартів
серії ISO 9000 якість визначається як сукупністю властивостей і характеристик
продукту, які наділяють її спроможністю задовольняти виражені і невиражені
потреби споживачів. Сенс цього поняття отримав подальший розвиток у
стандарті ISO 9000-2000 (ДСТУ ISO 9000-2001), відповідно до якого якість - це
ступінь, до якої сукупність власних характеристик задовольняє вимогам.
При побудові системи управління якістю переслідується мета
організаційного об'єднання всіх управлінських функцій, від реалізації яких
залежать забезпечення та підвищення якості. У рамках структур такого типу
координуються всі роботи, пов'язані з дослідженнями, і освоєнням видів послуг,
підвищенням продуктивності праці та якості.
Такі структурні схеми дозволяють створювати організаційні умови для
об'єднання зусиль всього персоналу, спрямованих на підвищення економічних і
виробничих показників діяльності всієї компанії.
Якість, в кінцевому рахунку, залежить від контактів працівників з
клієнтами, оскільки це їх поведінка формує у клієнтів певну думку про
обслуговування. Це одна із самих складних завдань. Проектним менеджером
був розроблений необхідний стан середовища сервісу, включаючи такі речі, як
частота прибирань, максимальний і середній час очікування клієнта на надання
послуги з консультації, регулярність контактів з постійними клієнтами.
Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний
стандарт ISO/IEC 12207 [555] (ISO - International Organization of Standardization
34
- Міжнародна організація по стандартизації, IEC - International Electrotechnical
Commission - Міжнародна комісія з електротехніки). Він визначає структуру
ЖЦ, що містить процеси, дії і задачі, що повинні бути виконані під час
створення ПЗ.
Структура ЖЦ ПЗ по стандарті ISO/IEC 12207 базується на трьох групах
процесів:
- основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація,
супровід);
- допоміжні процеси, що забезпечують виконання основних процесів
(документування, управління конфігурацією, забезпечення якості, верифікація,
атестація, оцінка, аудит, рішення проблем);
- організаційні процеси (управління проектами, створення інфраструктури
проекту, визначення, оцінка і поліпшення самого ЖЦ, навчання)
2.5.2 Розроблена діаграма Ісікави та коментарі до неї.
Рис 2.7 Діаграма Ісікави
35
Як можна бачити з діаграми, якість проекту залежить від багатьох
чинників, які більше чи менше впливають на якість розроблюваного продукту.
Очевидно що покращення кожного з факторів представленого на діаграмі, веде
до збільшення якості продукту в цілому, але в умовах реального проекту,
неможливо довести всі фактори до ідеального стану, що веде за собою
погіршення якості продукту. А тому раціональним буде зосередження ресурсів
на тих факторах та моментах, які мають найбільший вплив на якість
конкретного проекту, тобто працюючи з кожним проектом потрібно провести
аналіз ринку та галузі і зосередити сили на ключових аспектах.
2.7 Управління ризиками проекту.
Управління ризиками включає планування менеджменту ризиків,
визначення стану і моніторинг ризиків. Поряд з оцінюванням ризиків ці
компоненти повинні підтримуватися наборами інструментів і методик. Під час
планування менеджменту ризиків використовуються інструменти по
одержанню інформації і методики, що дозволяють уникнути прояву ризиків.
Також застосовується передача, редукція елементів і інтеграція планування.
Виробляється підписання контрактів з консультантами-експертами по основних
питаннях, одержання інформації з баз даних, що містять цікавлячі питання, а
також надання дослідницьких послуг
Розглянемо модель управління ризиками з використанням 12 категорій
потенційного ризику для визначеного проекту. Для кожної категорії детально
представлені фактори, що впливають на ризики, і рекомендується проводити
їхньої оцінки по трьох рівнях можливого прояву (низька, середня, висока
очевидність погрози ризику), опису змісту й атрибутів яких представлено у
великій таблиці. План управління проектними ризиками для конкретного ІС
рекомендується моделювати категоріями: 1) Задачі і цілі. Кожен схвалений
проект ІС повинний займати відповідне місце серед цілей і задач підприємства.
36
Ті проекти, що не відповідають реальної цілям організації, створюють напруга,
що впливає на всі проекти. Наприклад, зажадаємо, щоб існувала організація, у
задачі якої входила би розробка ІС для внутрішнього корпоративного
виробництва, а ціль складається в створенні найбільш ефективного,
замовленого програмного забезпечення для підприємств організації. Якщо
підприємство приступить до виконання проекту по створенню пакета ІС
загальної спрямованості і на комерційній основі, то це може бути ризикованим
заходом, що суперечать поточним задачам, кваліфікації і цілям організації. 2)
Організаційний менеджмент. Кожний з обраних проектів повинний вписуватися
в поточну або плановану організаційну структуру. Якщо організація не має
подібну структуру або ж вона ще не створена, важко розраховувати на успішну
реалізацію програмного проекту. Прикладом подібних ризикованих формувань
є торговельні організації, що припиняють розробку проектів без дотацій з боку
виконуючих організацій. Проект перекидається на інше підприємство по
розробці, оскільки немає підходящої команди і відсутній процес формування
необхідного типу системи. 3) Замовник. Усі проекти повинні мати постійний
зворотний зв'язок із замовником. Проект розробки ІС вимагає великих вихідних
даних, що можуть представити замовники і кінцеві користувачі. Без подібних
даних самий удалий процес розробки приведе до формування тільки відмінно
функціонуючої системи, що не відповідає реальним запитам кінцевих
користувачів. Схований тут ризик складається в залученні в команду
недосвідчених співробітників, що не володіють адекватним досвідом з дозволу
проблем, зв'язаних з конкретною предметною областю. Такі співробітники не
зможуть задовольняти необхідні технічні запити замовника і розроблювачів ІС.
4) Бюджет/вартість. Саме дана категорія звичайно залучає найбільш пильну
увагу і впливає на всі інші категорії ризиків. Менеджери проектів зосереджують
увагу на бюджеті й обсягах витрат, оскільки саме ці важелі дозволяють задіяти
широкий спектр можливостей, що приводять проект до успішного завершення.
37
Для зменшення ризику, що відноситься до цієї категорії, варто чітко
представляти розміри проекту, мати у своєму розпорядженні достовірну
передісторію про роботу над подібними проектами, а також мати досить повне
представлення про зовнішні впливи, наприклад, про технології. 5) Графік.
Великий ризик полягає в тому, що команді розроблювачів нав'язуються занадто
тісні тимчасові рамки графіка робіт. Якщо розроблювачі не можуть робити
впливу на формування графіка і дати ключових етапів проекту, велика
імовірність того, що графік виконуватися не буде. Команди розроблювачів ІС
повинні брати участь у розробці проектних графіків і мати можливість вносити
туди зміни. 6) Зміст проекту. Усі проекти генерують ті або інші особливості, що
доповнюють проект і утворять проміжні продукти. Одним з основних
компонентів є документація, що містить вимоги, відомості про проектування,
про цільову систему і зовнішнє середовище. Якщо ця інформація відсутня,
можуть з'явитися помилки, або різко і непередбачено зросте ризик утрати
зведень, що утримуються в проекті. Також може порушитися графік або істотно
постраждає вміст продукту. 7) Виконання. Ці фактори ризику відносяться до
особливого періоду, коли настає момент практичних іспитів розробленої
системи і ІС. Однак саме ці фактори ризику є ключовими для критерію по
розробці програмного продукту. Деякі з основних областей ризику відносяться
до функціонування системи під час тестування. Критичне значення має
доступна можливість повного тестування всіх модулів і їхніх інтерфейсів.
Неадекватне тестування веде до відмовлень при виконанні проекту і
відповідних ризиків. 8) Управління проектом. Ця категорія відноситься як до
процесу управління проектом, так і до компетенції менеджера проекту. Ризик
існує не тільки через недоліки, неадекватного трактування, процесів
менеджменту, але може бути також наслідком попереднього досвіду роботи
менеджера проекту. Менеджери проектів повинні мати досвід роботи з
визначеною предметною областю і мати представлення про процеси проектного
38
менеджменту в життєвому циклі ІС. 9) Процеси розробки. Ця категорія
фокусується на тих процесах, що зменшують загальний ризик і поліпшують
якість виробленого продукту. До процесів розробки не відносяться специфічні
інструменти, такі як мови програмування, генератори коду. Розглянуті процеси
фокусуються на процесах конфігураційного менеджменту, практиках і методах
забезпечення якості і на аналізі альтернатив. 10) Середовище розробки. Дана
категорія зосереджена на фізичному середовищі можливостей, апаратних
платформах і інструментах по розробці програмного продукту. Ризик виникає
не тільки через недолік адекватних інструментів, але і унаслідок відсутності
адекватних можливостей їхнього використання. Якщо команда не підібрана
спеціально для рішення конкретної задачі, відсутнє адекватний простір для
вироблення угод, простір для підтримки інтерв'ю з замовником і робітники
кімнати, ризик істотно зростає. 11) Персонал. Ця категорія є єдиної, де істотне
зменшення ризику досягається за рахунок набору досвідченої і
високопродуктивної команди розроблювачів ІС. Розроблювачі, що володіють
високою робочою ефективністю, можуть у 10 і навіть у 25 разів продуктивніше
працювати, чим звичайна команда. Непевність у можливостях команди або в
досвідченості її членів у сполученні з деякими особливостями предметних
областей, сприяє фіксації консервативного підходу до факторів ризику з цієї
категорії. 12) Підтримка. Ця заключна категорія дозволяє кількісно оцінювати
ризик, зв'язаний із ІС, після постачання програмного продукту. Команда
розроблювачів проекту часто несе відповідальність за підтримку програмного
продукту протягом визначеного періоду після його постачання. Якщо ж це не
так, а недосвідчені користувачі намагаються фіксувати і виправляти помилки в
ІС, проектний ризик істотно зростає. Інструменти, застосовувані для розробки,
повинні бути доступні і на етапі підтримки. Підтримка постачальника після
випуску продукту характеризується наявністю ризику випуску, якщо відсутній
план або бюджет для реалізації інструментарію безперервної підтримки.
39
2.7.1 План управління ризиками.
Таблиця 2.1 Визначення ризиків проекту:
Категорія ризику Ризик Опис ризиків
1. Задачі і цілі проекту – зміна цілей Ризик зміни цілей під
час виконання проекту
що веде до додаткових
часових витрат
2. Організаційний - немає підходящої Існує ризик того, що в
менеджмент проектної команди фірми немає підходящої
команди для виконання
даного проекту.
3. Замовник - функціонування Не відповідає реальним
системи запитам кінцевого
користувача.
4. Бюджет - вартість проекту Важко представити
розмір проекту.
- зміна кількості робіт
Зміна кількості робіт під
час виконання проекту.
5. Графік робіт - тісний графік робіт Проектній команді
нав’язують тісний
графік робіт, який не в
змозі виконати дана
команда.
40
6. Зміст проекту - відсутність Відсутня документація,
документації яка містить вимоги та
відомості по
проектуванню
7. Виконання - випробування Існує ризик, що
новоствореної системи новостворена система
некоректно виконує свої
- неадекватне
функції під час
тестування
тестування.
Не вірно вибрані
способи тестування
інформаційної системи
проектною командою.
8. Управління проектом - компетентність Немає досвіду роботи
керівника проекту керівника проекту в
даній предметній
області, що може
повести до
неправильного
трактування процесів
управління
9. Процеси розробки - якість управління Неправильний вибір
методів, які
забезпечують якість
проекту.
41
10. Середовище - вибір інструмента Ризик виникає від
розробки розробки недостатньої
адекватності вибраного
- відсутність
інструмента розробки.
адекватного простору
для вироблення угод між Ризик виникає, якщо не
учасниками проекту - підібрана команда
захищення даних ІС в спеціально для рішення
даному середовищі поставленої задачі.
Ризик, щодо безпеки
даних ІС, так як в
вибраному середовищі
мало створених
подібних систем.
11. Персонал - вибір персоналу Вибір мало досвідченої
проектної команди
- погана домовленість з
проектною командою Є ризик, що працівник
не хоче виконувати
поставлену перед ним
роботу.
12. Підтримка - підтримка після Ризик, що підтримку
впровадження продукту буде проводити
недосвідчений
користувач через
відсутність плану або
42
бюджету неперервної
підтримки ІС.
Таблиця 2.2 Оцінка ризиків по категоріям:
Категорія ризику Ризик Тип ризику Оцінка
ризику
1. Задачі і цілі – зміна цілей Середній 7
проекту
2. Організаційний - немає підходящої Малий 3
менеджмент проектної команди
3. Замовник - функціонування Середній 6
системи
4. Бюджет - вартість проекту Високий 9
- зміна кількості
робіт
5. Графік робіт - тісний графік Середній 6
робіт
6. Зміст проекту - відсутність Середній 6
документації
7. Виконання - випробування Високий 8
новоствореної
системи
- неадекватне
тестування
43
8. Управління - компетентність Середній 5
проектом керівника проекту
9. Процеси - якість управління Середній 6
розробки
10. Середовище - вибір інструмента Середній 4
розробки розробки
- відсутність
адекватного
простору для
вироблення угод
між учасниками
проекту
- захищення даних
ІС в даному
середовищі
11. Персонал - вибір персоналу Середній 5
- погана
домовленість з
проектною
командою
12. Підтримка - підтримка після Малий 3
впровадження
продукту
Таблиця 2.3 Оцінка ризиків і методи боротьби з ними:
44
Ризик Оцінка Методи боротьби
ризику
1) Вартість проекту 9 Постійне детальне планування
протягом ЖЦ проекту
2) Зміна кількості робіт 9 Постійне детальне планування
протягом ЖЦ проекту
3) Випробування новоствореної 8 Розробка детального тестування
системи проекту і постійний зв’язок з
замовником
4) Зміна цілей 7 Отримання повної інформації від
замовника в фазі аналізу
5) Якість управління 6 Вибір керівника з досвідом
роботи в даній ПО
6) Функціонування системи 6 Постійна перевірка на
відповідність функціонування ІС
7) Тісний графік робіт 6 Розробка графіку з проектною
командою
8) Відсутність документації 6 Постійне ведення проектувальної
документації
9) Застосовність 6 Постійний зв’язок з замовником
10) Неадекватне тестування 6 Розробка плану тестування
11) Компетентність керівника 5 Вибір керівника з досвідом
проекту роботи
12) Погана домовленість з 5 Назначати працівників на роботи,
проектною командою які працівник може і хоче
виконувати, чітка початкова
домовленість по заробітній платі
на весь проект
45
13) Вибір персоналу 5 Ретельний підбір команди
14) Відсутність адекватного 5 Створення сайту для постійного
простору для вироблення угод зв’язку з замовником
між учасниками проекту
15) Захищення даних ІС в 4 Необхідний вибір достатнього
даному середовищі рівня захищеності (можливо
необхідно найняти спеціаліста
(експерта) для цього)
16) Вибір інструмента розробки 4 Детальне вивчення існуючих
інструментів розробки
17) Немає підходящої проектної 3 Відведення часу для навчання
команди проектної команди
18) Підтримка після 3 Розробка плану і бюджету для
впровадження продукту підтримки ІС
2.8 Управління інформаційним зв’язком та інтеграцією в проекті
Управління інформаційним зв'язком, або комунікаціями, в проектах
включає дії, необхідні для забезпечення своєчасного отримання, збору,
поширення, зберігання і кінцевого розміщення проектної інформації. Воно
забезпечує дуже важливі зв'язки між людьми для обміну ідеями та різного роду
інформацією, що в кінцевому підсумку необхідно для успішного завершення
проекту. Будь-яка особа, залучена до роботи в рамках проекту, повинна бути
готовою до пересилання та прийому інформації на «мові» проекту по
встановлених каналах, повинна розуміти, як ці комунікації впливають на проект
в цілому. Управління комунікаціями проекту повинно бути націлене на групову
взаємодію в рамках управління проектом і включає:
46
1. Інформацію проекту, тобто зібрані, оброблені і розподілені дані, що
включають як вихідні дані, так і ті, які одержані в результаті прямих
розрахунків, аналітичної обробки, експертних оцінок і ін.;
2. Засоби обробки інформації, тобто інформаційні технології, що базуються на
сучасних програмних продуктах;
3. Засоби комунікації, що базуються на сучасних засобах зв'язку, орієнтовані на
забезпечення своєчасного збору, генерації, розподілу і збереження і передачі
необхідної проектної інформації;
4. Документування робіт – збір, обробка та збереження документації по проекту
2.8.1 Схема інформаційного обміну в IT проекті
Рис 2.8 Схема інформаційного обміну в IT проекті
Схема вище показує як інформація переходить від одного рівня проекту
до іншого, насправді, чим шарів передачі інформації буде менше, тим швидше
та легше будуть прийматися рішення на проекті. Завдання всі членів команди
47
виявляти проблеми в комунікації та ситуації, коли через комунікацію та
неможливість прийняття рішення їхня робота заблокована.
Менеджери проектів значну частину свого робочого часу приділяють
комунікацій - з членами команди, стейкхолдерами проекту (внутрішніми і
зовнішніми). Крім того, менеджеру постійно доводиться погоджувати вимоги
різних груп, які не приймають безпосередню участь в проекті, проте зацікавлені
в результатах проекту. Комунікації проекту складаються з процесів своєчасного
збору, поширення, зберігання, отримання та використання інформації.
Менеджер проекту повинен формувати певний простір для спільного
обговорення зацікавленими сторонами проекту загальних завдань, цілей і сфер
інтересів (в японському менеджменті - «ментальне середовище), що утворює
додаткову цінність проекту. Такий простір для зацікавлених сторін проекту
повинен відповідати певним критеріям, зокрема, креативності, відкритості,
синергії [11].
Інформаційна платформа передбачає організацію комунікацій в мережі
Інтернет для формування інтегрованих звітів, обробки інформації в
корпоративних програмних продуктах, забезпечення вільного доступу до
загальнодоступних нормативних, інформаційних або технологічних баз даних.
Слід зазначити, що під часу процесу управління очікуваннями зацікавлених
сторін план управління комунікаціями може бути оновленим (якщо будуть
виявлені неефективні методи проведення комунікації, або ж новітніші методи
будуть запропоновані).
Культурна платформа розглядається як своєрідний віртуальний простір, в
якому зацікавлені сторони проекту охоче проявляють ініціативу, і також активно
співпрацюють з іншими сторонами проекту. Забезпечивши розуміння
стейкхолдерами ризиків і переваг, що пов'язані з проектом, менеджер отримує
48
підтримку з їхнього боку в наданні допомоги при оцінці можливих ризиків,
викликаних рішеннями проекту [11].
Більшість робочої комунікації між командою проекту і клієнтом буде
відбуватися за допомогою програми Slack, що є розробленою для
бізнес-комунікацій і є зручною при роботі з it-проектами. Slack - корпоративний
месенджер. Запущено в тестовому режимі в серпні 2013 року, публічний випуск
відбувся 12 лютого 2014 року. У перший день тестування зареєструвалися 8
тисяч компаній. За даними компанії на червень 2015 року, Slack щодня
використовують 1,1 мільйона користувачів [2]. Slack став самим швидко
зростаючим бізнес-додатком в історії [3].
2.8.2 Опис застосованої гнучкої технології (Agile, Scrum, Kanban)
Agile — це методологія гнучкої розробки, яка першочергово сьогодні
популярна в ІТ і дозволяє клієнтам швидше отримувати якісне програмне
забезпечення.
Іншими словами Agile — це сукупність підходів і моделей поведінки,
орієнтованих на використання ітеративної розробки, time boxes (часових
рамок), динамічне формулювання вимог і забезпечення реалізації ПЗ в
результаті взаємодії всередині високо самоорганізованої робочої групи із
фахівців різних профілів.
Scrum — це одна з методик гнучкої розробки. У Scrum -і робиться акцент на
планомірному контролі процесу розробки. Головна особливість скраму — це
розбивка процесу розробки на ітерації з чіткими відрізками часу (зазвичай 2-6
тижнів; їх називають “спринтами”).
На початку спринта проводится “планування спринту” — нарада на 3-4
години, де обговорюються головні завдання, які будуть виконуватися протягом
49
спринта. В кінці спринта проводиться “демо” — демонстрація результатів
роботи команд за цей спринт.
Перед самим першим спринтом замовник, або його представник формує
список вимог до майбутнього продукту котрий розроблятиметься. Такі вимоги
називають User Story, а самого замовника Product Owner. У User Story Product
Owner вказує пріоритет по кожній задачі. Спочатку будуть реалізовуватися
задачі з більш високим пріоритетом. Увесь список називається Product backlog
або “резерв продукту”.
Окрім Product Owner, серед учасників ще особливо виділяють scrum-мастера.
Скрам мастер — слідкує щоб слідували усім принципам скраму. У якості
скрам-мастера виступає хтось із команди.
На першій зустрічі, на початку спринта, окрім того, що задачі
встановлюється пріоритет, надається ще приблизна оцінка в “абстрактних
людських днях”, яку ще називають “story point”. Потім команда вирішує,
скільки вона успішно виконає завдань за час спринта. Наприклад, замовник
відображає 7 задач, а команда зможе зробити тільки 5. Значить 2 зайві задачі
підуть у наступний спринт. Якщо замовнику така обставина не подобається, він
може підвищити їх пріоритет, тоді інші завдання будуть вилучені зі спринту, а
ці 2 завдання посядуть їх місце. Крім того, скрам-мастер може розбити деякі
завдання на більш дрібніші, надати їм пріоритети на свій розсуд, щоб замовник
залишився задоволеним.
Список відібраних задач на спринт називається “sprint backlog”, або
“резерв спринта”. Для кращої наглядності звичайно складається таблиця, в якій
перелічуються завдання, які необхідно реалізувати, які перебувають у процесі
реалізації, і ті, що вже виконані (схоже на Канбан дошку, але не зовсім). Також
будується діаграма “згоряння задач”. Вона графічно показує, скільки ще задач
залишилося виконати. В ідеалі графік “згоряння задач” до кінця спринта
повинен опуститися до нуля.
50
Також кожного дня або через день проводяться невеликі заходи в
командах на 5-15 хвилин, де кожен з учасників перераховує, що зробив за цей
день, що ще потрібно зробити, а також вказує на те, що йому щось заважає
зробити.
Коли спринт завершився, scrum-master проводить демо, на якому
демонструється список всього, що повністю зроблено. Потім обговорення, яке
звичайно намагається виявити, що було зроблено добре, а що можна було
зробити краще.
Зазвичай за 2-3 спринта можна виявити головні проблеми, які заважають
працювати ефективніше, звісно ці проблеми слід усунути. Такі умови сприяють
більшій продуктивності команди, не збільшує навантаження на команду. До ери
гнучких методологій, це було неможливе.
Також в середині спринта, іноді ще проводять проміжні зустрічі,
присвячені плануванню наступного спринта. На ній звичайно уточняють
пріоритети задач, а також можуть бути якісь задачі поділені, нові задачі додані в
product backlog.
У Скрамі учасників поділяють на “свиней” і “кур”. “Свині” повністю
задіяні у процесах, “кури” – тільки-но частково. До категорії “свиней”
відносить наступні ролі:
Product Owner (власник продукту) Scrum майстер і Scrum Team (команда
розробників). В ідеалі ці ролі повинні бути крос-функціональними і не
використовуватися спільно з іншими проектами.
Product Owner (власник продукту) — володіє всією розробкою продукту,
призначає завдання команді (the list of Product Backlogs) і виступає у ролі
звязуючої ланки між scrum командою (команда розробників) та зацікавленими
сторонами.
Scrum Майстер виступає в якості фасилітатора Scrum команди. Роз’яснює
питання. Стежить за тим, щоб в команді діяли правила scrum і проводили
51
зустрічі за scrum -ом, Відповідальний за управління спринтом. А також
концентрується на рентабельності інвестицій (ROI).
Scrum команда бере участь у зустрічах за scrum -ом та виконує поставлені перед
нею завдання. До Scrum команди належать Developers, QA, Group of Product
Owner, Business Analyst.
Рекомендований розмір команди в Scrum – 7 плюс або мінус 2 (тобто від 5 до 9
членів команди).
До “курей” відносяться ролі:
Користувачі (Users)
Клієнти, продавці (особи, які ініціюють проект і для кого проект повинен
приносити вигоду. Вони задіяні у Скрам тільки під час оглядових зустрічей по
спринту (Sprint Review));
Управлінці (Managers) (люди, які управляют персоналом);
Експерти-консультанти (Consulting Experts).
Багато Scrum мастерів не мають можливості працювати з крос-функціональною
або спеціалізованою командою по ряду причин. Це питання може спонукати
інтерв’юера запитати, як ви плануєте працювати з командою, у якій не було
дизайнера або тестувальника, або як будете навчати команду, яка ще не
посвячена в нюанси роботи.
2.9 Контроль та мотивація проекту
Для контролю над проектом була обрана ‘Asana’. Asana — це інструмент
для розподілу навантаження та трекінгу прогресу в роботі команди. Його
переваги: колеги можуть бачити розподіл задач один в одного, завдання можна
структурувати за допомогою канбан-дошок, календаря, таймлайну. Є навіть
можливість сформувати схему з переходами завдань між працівниками
(наприклад, коли у рамках створення email-розсилки завдання переходить від
52
копірайтера до верстальника). Але попереджаємо: інтерфейс програми та її
функціонал складніші, ніж в інших сервісах, хоча цікаві можливості варті того.
Вартість: безкоштовно (акаунт для команди із базовими можливостями).
Є й платні тарифи з більшими можливостями — від 9.99$ щомісяця* з людини.
2.9.1 Канбан дошка в Асані проекту ‘Your next’:
Рис 2.9 Канбан дошка
2.10 Висновки до розділу 2:
Було розроблено зміст проекту, його графік, WBS структуру,
Розглянуто застосування гнучких методологій до проекту, побудовано
діаграму Ганта та діаграму Ісікави. Розглянуто галузі знань з управління
проектами, які використовуються в проекті.
53
РОЗДІЛ 3
ОЦІНКА ЕФЕКТИВНОСТІ ПРОЕКТУ
3.1 Планування фінансових ресурсів інвестиційної фази проекту
Фаза впровадження проекту, передбачає великий спектр
консультаційних і проектних робіт, головним чином у напрямку
управління проектом.
Планувати витрати потрібно таким чином, щоб вони змогли
задовольнити необхідності у фінансових ресурсах на протязі всього
періоду реалізації та розробки проекту. Усі витрати проекту
класифікуються за переліком ознак. Так, зокрема, усі витрати на проекті
поділяються на інвестиційні витрати та поточні витрати. До інвестиційних
відносяться витрати на інвестиції до основного капіталу (придбання землі,
будівництво приміщень і споруд, купівля та оренда технології та
обладнання), передвиробничі трати на необхідності в обіговому капіталі.
Поточні витрати – це трати на випуск продукції, що містять витрати
необхідні для придбання сировини, основних і допоміжних матеріалів,
оплату праці, загальні витрати по проекту, які попадають на звітний
період. За способами включення у собівартість проектних робіт і за
характером участі під час реалізації проекту витрати розподіляються на
прямі та непрямі витрати.
Прямі – це витрати, які безпосередньо пов'язані з виконанням робіт і
включаються у виробничу собівартість проектних робіт відповідних
об’єктів обліку за прямою ознакою, наприклад: прямі витрати на оплату
праці; прямі матеріальні трати, відрахування на соціальні заходи, інші
витрати.
54
Непрямі – це витрати, пов’язані з управлінням та обслуговуванням
процесів, організацією виконання проектних робіт а також інші витрати,
які не можуть бути зараховані економічно доцільним шляхом
безпосередньо до конкретного об’єкта витрат. Залежно від зміни обсягів
виконаних проектних робіт виробничі витрати діляттся на постійні та
змінні. Змінні витрати – це витрати, величина яких збільшується при
зростанні обсягів виконаних проектних робіт і спадає при їх зменшенні.
До цих витрат належать: витрати на матеріали, на оплату праці
розробників проекту, відрахування на соціальні заходи тощо.
Постійні витрати – це витрати, розмір яких залишається незмінним
при зміні обсягу виконаних проектних робіт. До цих витрат належать:
витрати, що пов’язані з управлінням, організацією та обслуговуванням
виробництва і процесів що його стосуються[8].
Сьогодні великого розповсюдження отримали наступні джерела
фінансування:
• різні форми позикових коштів (кредити, позики тощо);
• власні фінансові кошти (внески власного капіталу, нерозподілений
прибуток, амортизаційні відрахування, статутний капітал,
зокрема, поширеною формою фінансування проектів є одержання
фінансових ресурсів через випуск акцій та облігацій);
• іноземні та міжнародні інвестиції, лізингове фінансування;
• асигнування з державного, регіонального або місцевого бюджету.
На даному проекті був вибраний спосіб фінансування власними
коштами компанії, тобто компанія з оборотних коштів розробляє власний
продукт в результаті чого буде єдиним власником та матиме дохід
виключно для себе[8].
55
В більшості на інвестиційній фазі будуть витрати на підготовку
проекту до стану в якому розробники та проектна команда можуть почати
роботу над ним, сюди входить розробка вимог та дизайну, інструменти
потрібні розробник як системні, так і технічні, в тому числі спеціалізоване
ПО та комп’ютери.
3.2 Розробка зведеного кошторису витрат інвестиційної фази проекту
Кошторис - це набір розрахунків для визначення розміру витрат на
проект. З іншого боку, це інструмент для управління, який
використовується менеджером чи керівником проекту у процесі реалізації
та розробки проекту. Тож він є документом, що визначає вартість проекту,
а також інструментом аналізу та контролю витрат коштів на проект і
супутні процеси[8].
Дуже важливо правильно та всеціло визначити кошторисну вартість
проекту. Від того, наскільки точно кошторис показує рівень необхідних
витрат, залежить точність оцінки економічності проекту, а звідси і чіткість
планування капітальних вкладень і фінансування. Кошторис буде
настільки точним, наскільки будуть чітко визначені слушність висунутих
припущень і комплекс робіт.
Таблиця 3.1 Зведений кошторис
планових витрат інвестиційної фази проекту
Процеси, роботи Шифр процесу Всього
1. Планування процесів проекту, придбання документації на продукт 1 – 2 20
2. Технологічне проектування 2 – 3 30
3. Аналіз ринку, маркетингові дослідження 2 – 4 60
4. Оренда і утримання офісних приміщень (щомісячно) 2 – 5 30
56
5. Утримання дирекції та адміністративні витрати (щомісячно) 2 – 10 70
6. Проектування ІС 3 – 4 40
7. Придбання обладнання 3 – 5 1600
8. Розробка ІС 4 – 5 799,8
9. Придбання меблів, комп’ютерів 4 – 7 110
10. Утримання групи спеціалістів (щомісячно) 4 – 10 60
11. Створення матеріальних запасів 5 – 6 80
12. Тестування 5 – 7 220
13. Утримання виробничих площ (щомісячно) 5 – 9 40
14. Рекламні заходи та створення реалізаційної мережі 5 – 10 60
15. Набір і навчання персоналу 7 – 8 100
16. Впровадження 7 – 10 50
17. Логічний зв’язок (фіктивний процес) 6 – 7
18. Логічний зв’язок (фіктивний процес) 8 – 10
19. Логічний зв’язок (фіктивний процес) 9 – 10
Втирати з процентом 3263,204
У кошторисі фігурують всі процеси, що потребують фінансових
затрат (крім фіктивних процесів), останнім пунктом визначаються потреби
на оплату процентів за кредити.
Зведений кошторис є одним з найважливіших
планово-координуючих документів, що забезпечує процеси управління
ходом реалізації проекту.
3.3 Планування амортизаційних витрат операційної діяльності
Метою розробки цього комплексу розрахунків є обґрунтування
амортизаційних витрат за роками операційної діяльності. Стандарти
бухгалтерського обліку передбачають право суб`єкта господарської
діяльності самостійно вирішувати питання про строк і метод погашення
57
амортизаційних витрат. В розпорядженні суб`єкта господарської діяльності
є шість можливих методів амортизації:
- прямолінійного списання;
- зменшення залишкової вартості;
- прискореного зменшення залишкової вартості;
- кумулятивний;
- виробничий.
Спираючись на свої знання, стосовно амортизаційних процесів і
амортизаційної політики, студент може самостійно вибрати доцільний, на
його погляд, метод амортизації та розрахувати величини амортизаційних
відрахувань за роками операційної діяльності.
Амортизація основних засобів у податковому обліку нараховується з
використанням тих самих методів, які застосовуються до об'єктів основних
засобів у бухгалтерському обліку та які при цьому застережені в наказі про
облікову політику підприємства з метою складання фінансової звітності
(пп. 145.1.5, 145.1.9 ПКУ). Причому податкова амортизація, як і бух
облікова, нараховується щомісячно (починаючи з місяця, наступного за
місяцем введення об'єкта в експлуатацію), а квартальна сума податкової
амортизації (за кожним об'єктом) — визначається як сума нарахованих
амортизаційних відрахувань за об'єктом за 3 місяці розрахункового
кварталу.
Діюче податкове законодавство відокремлює у складі основних
фондів суб‘єктів господарської діяльності 16 груп фондів, для кожної з
яких встановлено свій метод нарахування амортизації. Для групи 4, до
якої відносяться електронно-обчислювальні машини та програмне
забезпечення застосовується метод прискореного зменшення залишкової
вартості. Мінімальний строк корисного використання становить 2 роки.
58
Річна сума амортизації згідно даного методу визначається як добуток
залишкової вартості об’єкта на початок звітного періоду або первісної
вартості на дату початку нарахування амортизації та річної норми
амортизації, яка обчислюється відповідно до строку корисного
використання об’єкта і подвоюється.
Розмір річної амортизації групи основних фондів для t-го року
операційної діяльності складає
, грн.,
де – залишкова вартість об’єкта на початок звітного періоду, грн.;
–норма річної амортизації (не більше граничних норм),
%.
Амортизаційна вартість розраховується як різниця первісної вартості
та ліквідаційної вартості.
Розрахунок амортизаційних витрат виконується на протязі 10 років
операційної діяльності за формою таблиці 5.
Таблиця 3.2
Розрахунок амортизаційних витрат за роками операційної діяльності
Первісн
Групи а Річна
основних вартість норма Роки операційної діяльності
фондів , аморти
тис.грн. зації, %
1 2 3 4 5 6 7 8 9 10
4 група 256,0 102,4
1600,00 960,00 640,0 0 0 40,9616,38 6,55 2,62 1,05 0,4 0,17
6 110,00 33,00 77,00 53,90 37,73 26,41 18,49 12,9 9,06 6,34 4,4 3,11
59
група
309,9 140,1
Разом 717,0 0 3 67,37 34,87 19,5 11,6 7,39 4,8 3,27
3.4 Планування кредитних процесів операційної діяльності
В процесі операційної діяльності треба забезпечити повернення сум
кредитів, які використовуються на інвестиційній фазі проекту, і
забезпечити оплату процентів за використання сум кредитів. Перші
платежі забезпечуються за рахунок прибутку, другі – відносяться до складу
операційних витрат.
В роботі пропонується дослідити два можливих варіанта побудови
кредитного процесу. Перший варіант – більш “жорсткий”, з коротким
терміном повернення кредитів, другий – більш “м’який”, з більшим
терміном повернення кредитів і можливими часовими відстрочками.
Наприклад, для першого варіанту пропонується така схема повернення
кредиту – за перші 3 роки операційної діяльності у розмірі по 33,3 %
щорічно; для другого – відстрочка повернення кредиту на 1-й рік
операційної діяльності і наступним його поверненням за 4 роки по 25 %
щорічно.
Схема використання та повернення кредиту за формою наступної
таблиці:
Таблиця 3.3
Схема використання та повернення кредиту за роками операційної
діяльності
Роки операційної діяльності
Показники
1 2 3 4 5
1 варіант
60
1.Повернення
суми кредиту, тис. 2211,00 1474,00 982,67
грн. (%)
2. Використана за
рік сума кредиту, 6633,00 4422,00 2948,00 - -
тис. грн. (%)
3.Оплата
процентів,тис. 1591,92 1061,28 707,52
грн.
2 варіант
1.Повернення
суми кредиту, тис. 1658,251 1658,251 1658,251 1658,251
грн. (%)
2. Використана за
рік сума кредиту, 6633,004 6633,004 4974,753 3316,502 1658,251
тис. грн. (%)
3.Оплата
процентів,тис. 1591,92096 1591,92096 1193,94072 795,96048 397,98024
грн.
Величина річної процентної ставки за кредит повинна відповідати
нормативу, застосованому при плануванні кредитних процесів для
інвестиційної фази проекту.
Розраховані річні суми повернення кредиту будуть використані при
визначенні грошових потоків фінансової діяльності, а річні суми оплати
процентів – при розрахунку операційних витрат.
61
3.5 Прогноз доходів операційної діяльності
Операційні доходи за роками операційної діяльності визначаються
запланованими обсягами виробництва і реалізації продукції і рівнем цін на
продукції, що були спрогнозовані і визначені у таблиці 4. Розрахунок
річних сум доходів виконується за 10 років операційної фази проекту за
формою наступної таблиці:
Таблиця 3.4
Прогноз доходів операційної діяльності
Показники Роки операційної діяльності
1 2 3 4 5 6 7 8 9 10
1. Річні обсяги 280 280 280 280 280 280 280 280 280 280
реалізації
продукції
2. Ціна одиниці 100 97 94,09 91,26 88,52 85,87 83,29 80,79 78,37 76,02
3. Річний дохід 28000 27160 26345 25554,84 24788,20 24044,55 23323,22 22623,52 21944,81 21286,47
,20
3.6 Прогноз витрат операційної діяльності
Річні суми операційних витрат для t-го року операційної фази
проекту складають
,(тис. грн.)
де – витрати змінного характеру (тис. грн.)
- витрати постійного характеру (тис. грн.) (із табл. 4)
62
– амортизаційні погашення(тис. грн.) (із табл. 5)
– оплата процентів за кредити(тис. грн.) (із табл. 6)
Річні суми витрат змінного характеру для t-го року операційної фази
проекту складуть
, тис.грн.
де – обсяг реалізації продукції, одиниць;
– витрати на прямі матеріали на одиницю продукції, грн./од. (із
табл.4);
– витрати на пряму оплату праці (з нарахуваннями) на
одиницю продукції, грн./од. (із табл. 4).
Операційні витрати розраховуються для перших 10 років операційної
діяльності. Розрахунки оформлення за допомогою таблиці.
Таблиця 3.5
Прогноз витрат операційної діяльності, тис. грн. (j – варіант)
Роки операційної діяльності
Показники
1 2 3 4 5 6 7 8 9 10
5,88 5,96 6,05 6,14 6,23 6,32 6,42 6,52 6,62 6,72
1. Витрати змінні
443,8 452,6
2. Витрати постійні 410,00 418,20 426,56 435,10 461,73 470,96 480,38 489,99
0 7
3. Амортизація 717,00 309,90 140,13 67,37 34,87 19,49 11,68 7,39 4,86 3,27
4. Процент за
кредит 1591,92 1061,28 707,52
63
Разом операційні 2724,80 1795,34 1280,26 508,61 484,9 478,4
0 9 479,83 484,87 491,86 499,99
витрати
Роки операційної діяльності
Показники
1 2 3
5,88 5,96 6,05 6,14 6,23 6,32 6,42 6,52 6,62 6,72
1. Витрати змінні
2. Витрати постійні 410,00 418,20 426,56 435,10 443,80 452,67 461,73 470,96 480,38 489,99
3. Амортизація 717,00 309,90 140,13 67,37 34,87 19,49 11,68 7,39 4,86 3,27
4. Процент за 1591,92 1591,92 1193,94 795,96 397,98
кредит
Разом операційні 2725,80 2327,98 1769,69 1308,57 887,88 478,49 479,83 484,87 491,86 499,99
витрати
3.7 Оцінка показників ефективності проекту
Розрахунок показників ефективності проекту робиться на підставі
прогнозу і по реалізації за 12 років. За формалізованим підходом показник
абсолютного ефекту проекту визначається як різниця між накопиченими
грошовими притоками і відтоками проекту. Якщо мова йде про
дисконтовані грошові потоки, то цей показник має назву чистого
дисконтованого прибутку (доходу) проекту – ЧДП (ЧДД).
Для прикладу з таблиці 10:
= 2357 - 2343 = +14 тис. грн.,
де - поточні грошові притоки, тис. грн.;
64
- поточні грошові відтоки, тис. грн.
Але це з точки зору використання капіталу. Так як передбачається,
що інвестиційна фаза буде повністю профінансована за рахунок
запозиченого кредитного капіталу, тобто для власника проекту сума
інвестиційних відтоків складає нуль, то з його точки зору
0 = 2357 – 0 = +2357 тис. грн.
Таке значення ЧДП свідчить про високу комерційну ефективність проекту.
Показник відносної ефективності використання кредитного капіталу –
індекс прибутковості (доходності) капітала проекту
В даному випадку з точки зору власника проекту це лише формальний
показник.
Для розрахунку строку окупності капіталу, що передбачається
вкласти у проект, визначається величина середньорічних грошових
притоків
тис. грн.,
де - тривалість операційного періоду генерування грошових
притоків, років.
Очікуваний строк окупності капіталу, що буде вкладений у проект
років.
Показник внутрішньої норми доходності проекту (ВНД) визначається на
підставі рішення рівняння
65
Якщо підставити вираз , отримуємо наступне
вирішення цього рівняння
Вирішення цього рівняння відносно , дає значення ,
яке являє собою показник ВНД. Цей показник повинен бути більшим ніж
норми доходу на капітал, яка покладена в основу розрахунків показників
ефективності проекту.
Таблиця 3.6 Показники ефективності проекту
Чистий дисконтований
прибутк 68000,46642
Індекс прибутковості 23,92737834
Величина середньорічних
грошових притоків 6800,046642
Очікуваний строк окупності
капіталу 0,417931286
Внутрішня норма доходності 35%
3.8 Висновки до розділу 3:
В даному розділі було проведено планування фінансових ресурсів на
всіх етапах проекту, починаючи з інвестиційної фази, а також були
спрогнозовані витрати під час розробки проекту та доходи проекту,
66
прогнози показали що доходи перевищують витрати і проект є економічно
доцільним.
67
ВИСНОВОК
У ході виконання роботи було засвоєно навички проектного аналізу.
Також було розглянуто сучасні форми організації інвестиційних процесів
ІТ компанії. Проведено аналіз беззбитковості операційної діяльності
проекту. Обраховано оцінку показників ефективності проекту, прогноз
витрат операційної діяльності, прогноз грошових потоків проекту, прогноз
витрат, прогноз динаміки показників операційної діяльності. Було
проведено розробку кошторису та побудовано схему використання та
повернення кредиту за роками операційної діяльністю. Засвоєно навички
роботи з фінансово-економічним та звітно-аналітичним аспектами роботи
проектного менеджера.
Завданням проектного управління є виконання завдань проекту та
досягнення всіх цілей, що були поставлені на його початку, а також
реалізуючи зобов'язання щодо обмежень проекту що були визначені.
Прикладами обмежень є бюджет, час, межі та зміст проекту, не виконуючи
які, проект втратить свою цінність. Другорядним завданням, але більш
амбітним, є інтеграція та розподілення завдань, потрібних для досягнення
наперед визначених цілей, а також їх оптимізація. Результатом виконання
роботи є проектування повного циклу розробки вебсайту, що включає в
себе планування, реалізацію та отримання прибутку від вебсайту.
При виконанні роботи було розглянуто управління проектом.
Питання пов’язані з успішним управлінням проектів на сьогодні є досить
актуальні, оскільки в галузі інформаційних технологій часто виникає
визначений набір невирішених проблем, таких як збільшення обсягу
операцій і зменшення швидкості роботи системи, використання могутньої
68
системи не на повну потужність, перетворення впровадження в
нескінченний процес, постійну зміну вимог.
Було застосовано різні методи аналізу організаційних
проектно-орієнтованих структур, застосовано програмні засоби управління
проектами, а також побудови різних типів блок-схем, графіків та таблиць
для доступного представлення інформації.
Проектний менеджер – це людина яка бере на себе відповідальність
за всі критичні рішення на проекті, та сам підхід до його реалізації, під час
роботи було набуто корисних навичок що допоможуть зробити правильний
вибір при проектуванні майбутніх проектів.
Також було проведено планування фінансових ресурсів проекту,
розробку кошторису витрат проекту, планування амортизаційних та
кредитних процесів проекту, а також прогноз доходів та витрат проекту.
Базуючись на всіх прогнозах було визначено потенційну ефективність
проекту яка є економічно вигідною. З огляду на економічну вигідність,
було прийнято рішення розробляти проект. Мету дослідження досягнуто.
69
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Прокопенко Т. О. Методологія управління ІТ проектами / Т. О.
Прокопенко. – Черкаси: ЧДТУ, 2017. – 109 с.
2. Лавріщева К. М. Програмна інженерія – Підручник. – К.:
Академперіодика, 2008. – 320 с.
3. Навчальний посібник / Методи оцінювання Usability інтерфейсу
користувача / О.Кіріленко, Ю. Кузнєцова, Є. Соколова, Г. Фролова., 2013.,
243−246 с.
4. Денікін А. А. Чи можуть відеоігри бути мистецтвом?
[Електронний ресурс] / Денікін Антон
5. Липков А. В. Коробка Пандори: Феномен комп’ютерних ігор в
світі / Липков А. В. 2008, 81-91 с.
6. Калбертсон Роберт, Браун Крис, Кобб Гэри. Швидке тестування
/ М: «Вильямс», 2002. 374 с.
7. Акулов М.Г., Драбаніч А.В., Євась Т.В. Економіка праці та
соціально-трудові відносини. Навч. посіб. - К.:Центр учбової літератури,
2012. - 328 с.
8. Фінансовий аналіз : навч. посіб. / Г. Я. Аніловська, О. О.
Столяренко ; Львів. держ. ун-т внутр. справ. —ЛьвДУВС, 2012. — 403 с.
9. Оформлення конструкторської документації [Текст] : навч.
посіб. / В. В. Ванін, А. В. Бліок, Г. О. Гнітецька. — 2-ге вид., випр. — К. :
Каравела, 2003. — 160 с
10. Анна Радченко. Аналіз проекту "Наукова книга" НАН України.
2011. 120-140 с.
70
11. В. Бакуменко. Управління проектами // Політична енциклопедія.
Редкол.: Ю. Левенець (голова),та ін. — К.:Парламентське видавництво,
2011. — с.738
12. Т. Г. ФЕСЕНКО. Управління проектами: теорія та практика
виконання проектних дій / Харків – ХНАМГ – 2012. 45-80 с.
13. Шлапак В.С. «Аналіз проекту по розробці ігрового додатку під
назвою “Jump till the end”» / публікація в науковій конференції «Проблеми
інформатизації» 26-27 листопада 2020 року (Черкаси – Баку –
Бельсько-Бяла – Харків).
14. Проектное финансирование: монографія / Пересада А.А. та ін.
К.: КНЕУ, 2007. – 767 с.
15. Клячкин В.Н. Статистические методы в управлении качеством:
компьютерные технологии: уч. пособие. М.: Финансы и статистика, 2009.
– 304 с.
16. Бабенко С.В., Бабенко Г.В. Экономико-математическая модель
управления рисками при комплексном освоении территории //
Экономическая наука сегодня:сборник научных статей / пред. редкол. С.Ю.
Солодовников. – Минск: БНТУ, 2013. – Вып. 1. – С. 260-270.
17. Lisboa, P.J.G., El-Deredy W., Vellido A., Etchells T., Pountney D.C.
Automatic Variable Selection and Rule Extraction Using Neural Networks xt] //
Prog. of the 15 IMACS World Congress on Scientific Computation, Modelling
and Applied Mathematics, Berlin, 1998. – P.461-466.
18. Бурков В. Н., Новиков Д. А. Как управлять проектами. —
М-СИНТЕГ-ГЕО, 1997.
19. Прокопенко Т.О. Інформаційні технології управління
організаційно-технологічними системами: [монографія] / Т.О. Прокопенко,
А.П. Ладанюк. – Черкаси: Вертикаль, видавець Кандич С.Г., 2015. – 224 с
71
20. Демкин И.В., Перцев Д.В. Метод оценки интегрированного
портфеля риска инновационных проектов // Проблемы управления. – 2009.
– №4. – С.39-45.
21. Nikolay S. Gonchar Dynamical Risk Model with Investment in
Assets // Journal of Automation and Information Sciences. – 2014. –Vol. 5. –
Pp. 15-34.
22. Joseph W. Mayo Risk Management for IT Projects // All rights
reserved, 2009. – Pр.1 – 11.
23. C. Lambrinoudakisa, S. Gritzalisa, P. Hatzopoulosb, A. N.
Yannacopoulosb, S. Katsikasa A formal model for pricing information systems
insurance contracts // Computer Standards & Interfaces. – 2005. – Vol. 27, Issue
5. – Pр. 521-532.
24. Онищенко І.І. Когнітивне моделювання як метод якісного
аналізу ризиків ІТ-проектів// Харків : НТУ "ХПІ". – 2016. – № 2 (1174). –
С. 77-81.
25. Ladaniuk A., Prokopenko T., Reshetiuk V. The model of strategic
management of organizational and technical systems, taking into account
risk-based cognitive approach // Annals of Warsaw University of Life Sciences
– SGGW Agriculture (Agricultural and Forest Enginweering). – 2014. – № 63.
– P.97-104.
26. Прокопенко Т.A., Лега Ю.Г., Молотилин Ю.И. Управление
рисками технологического комплекса сахарного завода // Известия вузов.
Пищевая технология. – 2014. – № 2-3. – С.110-112.
27. Кирюшкин, В. Е., Ларионов В. Основы риск менеджмента
монографія/ Москва.: «Анкил», 2009. – 130 с.
28. Дамодаран А. Стратегический риск-менеджмент. Принципы и
методики монографія/ Вильямс, 2010. – 496 с.
72
29. Кунцевич В.М. Управление в условиях неопределенности:
гарантированные результаты в задачах управления и идентификации
монографія/ К.: Наук. думка, 2006. – 264 с.
30. Управление проектами / Мазура И. И., . Шапиро В. Д. М.:
Издательство «Омега Л», 2010. – 960 с.
31. Руководство по управлению инновационными проектами и
программами: т.1, версия 1.2 / пер.на рус.язык под ред. С.Д.Бушуева. – К.:
Наук.світ, 2009. – 173 с.
32. Москві С.О., Бевз С.М., Верба В.А., Дідик В.Г., Новиков В.А.,
Унковська Т.Є. Проектний аналіз. – Київ: ТОВ «Видавництво Лібра», 1998.
– 368 с.
33. Матвеев А.А., Новиков Д.А., Цветков А.В. Модели и методы
управления портфелями проектов. – М.:ПМСОФТ, 2005. – 206 с.
34. Караваев А. П. Модели и методы управления составом
активных систем / А. П. Караваев. – М.: ИПУ РАН, 2003. – 151 c.
35. Бурков В.Н. Модели и методы управления организационными
системами / В.Н. Бурков, В.А. Ириков. – М.: Наука, 1994. – 270 с.
36. Novikov D. MOcroeconomic AnOlysis Ond POrOmetric Control of
ONOtionOl Economy / D. Novikov, A. Ashimov, B. SultOnov, Z. Adilov, Y.
Borovskiy, R. AlshOnov, A. Ashimov. – New York: Springer, 2013. – 288 p.
37. Каплан Р.С.Организация,ориентированная на стратегию /
Р.С.Каплан,Д.П. Нортон. – М.: Олимп-Бизнес, 2004. – 416 с.38. Gre Osley
A. En Obling Osimul Otion cOpObility in the orgonization / A. GreOsley. -L.:
Springer. - 2008.- 152 р.
38. Бурков В.Н. Механизмы управления эколого- Экономическими
системами. / В.Н. Бурков,Д.А. Новиков, А.В.Щепкин. - М.: Физматлит,
2008. — 244 с.
73
39. Новиков Д. А. Модели и методы организационного управления
инновационным развитием фирмы / Д. А. Новиков, А.А.Иващенко. – М.:
КомКнига, 2006. – 332 с.
40. Оптимизация структур больших систем / В.И. Борщ, В.А.
Донец, В.В. Коваль, А.Я. Лейбзон, И.П. Лесовой. – К.: Науковадумка, 2000.
– 188 с.
41. Юдицкий С.А. Моделирование динамики развития
конфигураций организационных систем на основе сетей Петри и графов
приращений / С.А. Юдицкий, И.А. Мурадян, Л.В. Желтова. // Проблемы
управления. 2007, №6, С. 26-34.
42. Luis, J. Requirements Engineering for SociotechnicOl Systems/ J. L.
MOte, A. SilvO. – ІnformOtion Science Publishing. – 2005. – 313 р.
43. Спицнадель В.Н. Основы системного анализа / В.Н.
Спицнадель. – СПб.: Изд.дом «Бизнес- пресса», 2000. – 200 с.
44. Заико А.И. Теория систем. Стохастические модели / А. И. Заико.
- М.: МАИ, 2005. – 195 с.
45. Кини Р.Л. Принятие решений при многих критериях:
предпочтения и замещения / Р.Л. Кини, Х. Райфа. – М.: Радио и связь,
1981. – 560 с.
46. Юдицкий С.А. Модель и принципы реализации стратегического
управления сложными организационными системами / С.А. Юдицкий,
Ю.С. Затуливетер, И.И. Ижов // Приборы и системы управления. – 1999. -
№ 7. – с.59 – 66.
47. Юдицкий С.А. Моделирование циклов в процессах развития
организационных систем / С.А. Юдицкий // Приборы и Системы.
Управление, контроль, диагностика, 2011, №2, С.17-20.
74
48. Юдицкий, С.А. Моделирование динамики многоагентных
триадных сетей / С.А. Юдицкий. – М.: СИНТЕГ, 2012. – 112 с.
49. InnovOtive energys Oving technologies in biotechnologicOl objects
control / A. Chochowski, I.Chernyshenko, V. Kozyrskyi, V. Kyshenko, A.
LOdOniuk, V. Lysenko, V.Reshetiuk, I. Smitiukh, V. ShtepO, V. V.
ShcherbOtiuk – K.: Tsentr Uchbovoii LiterOtury, 2014. – 240 p.
50. Kosko B. Fuzzy CognitiveMOps / B. Kosko // InternOtionOl
JournOl MOn- MOchine Studies. 1986. - Vol.11. - P.65-67.
51. Chen S. M. Cognitivem Op-bOsed decision OnOlysis bOsed on
NPN logics / S. M. Chen // Fuzzy Sets Ond Systems 71.-1995.- P. 155–163.
52. Юдицкий С.А. Анализ Слабоструктурированных проблемных
ситуаций в организационных системах с применением нечетких
когнитивных карт/ С.А. Юдицкий, И.А. Мурадян, Л.В. Желтова //
Приборы и системы. Управление, контроль, диагностика. 2008, № 3, С.
54-62.
53. Поспелов, Д.А. Ситуационное управление: Теория и практика
[Текст] / Д.А. Поспелов – М.: Наука.- Гл. ред. физ.-мат. лит., 1986. – 288 с.
54. Максимов В.И. Структурно-целевой анализ развития
социально-экономических ситуаций / В.И. Максимов // Проблемы
управления, 2005, №3, С. 30-38.
55. Кунцевич, В.М. Управление в условиях неопределенности:
гарантированные результаты в задачах управления и идентификации
[Текст] / В.М. Кунцевич . – К.: Наук. думка, 2006. – 264 с.
56. UncertOinty Ond intelligent informOtion systems / World Scientific
Publishing. 2008. – 536 p.
57. KOcprzyk J. UncertOinty OpproOches for spOtiOl dOtO modeling
Ond processing/ J. KOcprzyk, F.E. Petry, A. YOzid/ Springer, 2010. – 225 р.
75
58. Ладанюк А.П. Основи системного аналізу / А.П. Ладанюк
Навчальний посібник. Вінниця. Нова книга, 2004. – 176 с.
59. DorfmOn, MOrk S. Introduction to Risk MOnOgement Ond
InsurOnce (9 ed.) / MOrk S. DorfmOn. Englewood Cliffs, N.J: Prentice HOll. -
2007.
60. DOvid Cooper LeOdership Risk: A Guide for PrivOte Equity Ond
StrOtegic Investors / Cooper DOvid. 2010. ISBN: 978-0-470-03264-0 – 250 p
61. MoorOd Choudhry, Ketul TOnnO (Foreword by) An Introduction to
VOlue-Ot- Risk/ MoorOd Choudhry,Ketul TOnnO// 4th Edition.- 2007.
ISBN:978-0-470-03377-7 192 p
62. Geoff Trickey Risk Types/ Geoff Trickey //OP MOtters No 14
FebruOry 2012 The British PsychologicOl Society
63. Fischer, M. D. Resisting hybridisOtion between modes of clinicOl
risk mOnOgement: ContrOdiction, contest, Ond the production of intrOctOble
conflict / MichOel DOniel Fischer, EwOn Ferlie // Accounting, OrgOnizOtions
Ond Society. - 2013. - 38 (1) р. 30–49.
64. Botti V. ANEMONA: A multi-Ogent methodology for Holonic
MOnufOcturing / V. Botti Ond A. Giret. – London: Springer, 2008, 214 p.
65. Wooldridge M. An Introduction to MultiAgent Systems / M.
Wooldridge. - 2nd ed., GlOsgow: John Wiley & Sons. - 2009 – 484 p.
66. Трахтенгерц Э.А. Взаимодействие агентов в многоагентных
системах (обзор) / Э.А. Трахтенгерц // Автоматика и телемеханика. – 1998,
№8, С. 3 – 52.
67. ShohOm, Y. MultiOgent Systems: Algorithmic, GOme-Theoretic,
Ond LogicOl FoundOtions / Y.ShohOm, K. Leyton-Brown.– COmbridge
University Press. - 2008. - 532 p.
76
68. Joe TOik Kirn. MOnOgement contingency / Пер. Соколова М.
Ситуационный подход к управлению //Государственное управление.
Словарь- справочник (по материалам "InternOtionOl EncyclopediO of Public
Politic Ond AdministrOtion"). ООО "Изд-во "Петрополис", 2000.
69. BrOdfield, R. M. Cognitive BOrriers in the Sce nOrio
DevelopmentProcess / R. M. BrOdfield // In: AdvOnces in Developing HumOn
Resources. - 2008. - 10. – р.198-215.
70. Schwenker B., Wulf T. (Eds.) ScenOrio-bOsed StrOtegic PlOnning:
Developing StrOtegies in On UncertOin World /Schwenker B., Wulf T. //
Springer, 2013. — 240 p. — ISBN: 3658028742
71. Месарович М. Теория Иерархических многоуровневых систем
/М. Месарович, Д. Мако, И. Ткахара. — М., Мир, 1973. —344 с.
72. ZOdeh L. A. Fuzzy Sets. / L. A. ZOdeh // InformOtion Ond Control,
1965, Vol. 8, № 3, pp. 338–353.
73. Тесля, Ю. Н. Несиловое взаимодействие / Ю. Н. Тесля . – Київ :
Кондор, 2005 . – 193 с.: ил. - Библиогр.: с.188-193 (84 назв.) . – На рус. яз. –
ISBN 966-351-009-9.
74. Томашевський В.М. Моделювання систем / В.М. Томашевський.
– К.: Видавнича група BHV, 2007. – 352 с.
75. Alter, S. Work System Theory: Overview of Core Concepts,
Extensions, Ond ChOllenges for the Future / S. Alter // JournOl of the
AssociOtion for InformOtion Systems. 2013. - 14(2). - pp. 72-121.
76. Юдицкий С. А. Основы предпроектного анализа
организационных систем / С. А. Юдицкий, П. Н. Владиславлев. - М.:
Финансы и статистика, 2005. - 144 с.
77
77. Novikov D., Ashimov A., SultOnov B., Adilov Z., Borovskiy Y.,
Nizhegorodtsev R., Ashimov A. MOcroeconomic AnOlysis Ond Economic
Policy Bosed on POrOmetric Control. – New York: Springer, 2012. – 256 p.
78. Kvint, V. The GlobOl Emerging MOrket: StrOtegic MOnOgement
Ond Economics / VlOdimir Kvint. – Routeledge. - 2009. – 488 р. ISBN:
0415988403
79. MulcOster, W.R. Three StrOtegic FrOmeworks/ W.R. MulcOster //
Business StrOtegy Series. -2009. - Vol 10, No1, pp. 68 – 75.
80. Мескон М.Х. Основы менеджмента: Пер. С англ. / М.Х. Мескон,
М. Альберт, Ф. Хедоури. – М.: Дело, 1998. – 800 с.
81. Зуб, А. Т. Стратегический менеджмент. Системный подход / А.
Т. Зуб, М. В. Локтионов. – Генезис - 2011, 848 с.
82. TolmOn E. C. Cognitive mOps in rOts Ond men/ E. C. TolmOn //
PsychologicOl Review. - 1948. - V. 55. P. 189–208.
83. TOber W. R. Fuzzy Cognitive MOps ModelSociOl Systems/ W. R.
TOber // ArtificiOl Intelligence Expert. 1994. - 9. - 18-23.
84. Кузнецов А.П. Анализ влияний при управлении
слабоструктурированными ситуациями на основе когнитивных карт / А.П.
Кузнецов, А.А. Кулинич, А.В. Марковский // Человеческий фактор
вуправлении / Под ред. Н.А. Абрамовой, К.С.Гинсберга, Д.А. Новикова —
М. : КомКнига, 2006. — С. 313– 344.
85. ZhOng W.R. A Cognitive-MOp-Bosed OpproOch to the
coordinOtion oI distributed cooperOtive Ogents / W.R. ZhOng, S. S. Chen, W.
Wong Ond R. S. King. " IEEE TrOnsOctions on Systems, MOn, Ond
Cybernetics. 1992. - 22-1, 103-114.
86. Руководство по Управлению инновационными проектами и
программами: т 1, версия
78
87. 1.2 / пер.на рус. Язык под ред. С.Д. Бушуева. – К. : Наук. світ,
2009. – 173 с.
88. Клыков Ю.И. Семиотические основы Ситуационного
управления / Ю.И. Клыков. – М. Энергия, 1974. - 171 с.
89. McCOrthy J. HOyes P. Some philosophicOl problems from the
stOndpoint of OrtificiOl intelligence. In B. Meltzer Ond D. Michie, editors.
MOchine Intelligence, Edinburgh University Press. 1969.- Vol 4, pp. 463–502.
90. SOwOrOgi T. An integrOtion of quOlitOtive cOusOl knowledge for
useroriented decision support / T. SOwOrOgi, S. IwOi, O.KOtOi // Control
Theory Ond AdvOnced Technology. 1986. - V. 2, P. 451–482.
91. Малиницкий Г. Г. Сценарии, стратегические риски,
информационные технологии / Г. Г. Малиницкий // Информационные
технологии и вычислительные системы. 2002. № 4. С. 83–108.
92. Кирюшкин, В. Е.Основы риск менеджмента. [Текст] / В. Е.
Кирюшкин, И. В. Ларионов. — Москва.: «Анкил», 2009. — 130 с.
93. Бурков В.Н. Управление риском: механизмы взаимного и
смешанного страхования / В.Н. Бурков, А.Ю. Заложнев, Д.А. Новиков //
Автоматика и Телемеханика. 2001. № 10. С. 125 – 131.
94. Трахтенгерц, Э. А. Субъективность в стратегическом
управлении. / Э. А. Трахтенгерц // Человеческий фактор в управлении /
Под ред. Н.А. Абрамовой,К.С.Гинсберга, Д.А. Новикова — М. : КомКнига,
2006. – С. 408 – 438.
95. Юдицкий С.А. Технология выбора целей при проектировании
бизнес - систем / С.А. Юдицкий, П.Н. Владиславлев // Приборы и системы.
Управление. Контроль. Диагностика. – 2002. - №12. – с.60 –64.
96. Саати Т. Принятие решений. Метод анализа иерархий / Т. Саати.
– М.: Радио и связь, 1993. – 150 с.
79
97. Кини Р.Л. Принятие решений при многих критериях:
предпочтения и замещения / Р.Л. Кини, Х. Райфа. – М.: Радио и связь,
1981. – 560 с.
98. Ларичев О.И. Качественные методы принятия решений.
Вербальный анализ решений / О.И. Ларичев, Е.М. Мошкович. – К.: Наука,
1996. - 106 с.
99. COrvOlho J. P. Rule BOsed Fuzzy Cognitive MOps, A CompOrison
with fuzzy Cognitive MOps / J. P. COrvOlho Ond J. A. B.Tome. Proceedings of
the NAFIPS99, NY, USA. 1999.
100. Кульба В.В. Сценарный анализ динамики поведения
социально-экономических систем / В.В. Кульба, Д.А. Кононов, С.С.
Ковалевский, С.А. Косяченко, Р.М. Нижегородцев, И.В. Чернов /
Институтуправления им. В.А. Трапезникова РАН. – М.,2002. – 220 с.
80
Додаток А
Комунікація на проекті - Slack
81
Додаток Б
Використання асани для ведення проекту
Додаток В
Діаграма Ганта
82
Додаток Г
Матриця відповідальності
83
Додаток Д
Оцінка ризиків
84
Додаток Е
Приклади сторінок сайту
85
86
Додаток Є
Приклади коду
87
88

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets