Дослідження розрахунку критичного шляху в задачах управління ІТ проектами

Білецький, Олег Ігорович

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

Назва:	Дослідження розрахунку критичного шляху в задачах управління ІТ проектами
Автори:	Чичужко, Марина Володимирівна Білецький, Олег Ігорович
Дата публікації:	січ-2023
Короткий огляд (реферат):	В даній кваліфікаційній роботі магістра розглянуто мережеві методи планування. Було визначено переваги та недоліки цих методів та встановлено, які саме методи підходять для вирішення нашої задачі. Дослідили сучасні мережеві моделі та шляхи побудови їх. Також досліджено критичний шлях на базі прикладів та діаграм. Описана структура бази даних програмного забезпечення управління ІТ проектом з визначенням критичного шляху. Побудовано модуль розрахунку критичного шляху для ІТ проектів.
URI (Уніфікований ідентифікатор ресурсу):	https://er.chdtu.edu.ua/handle/ChSTU/6392
Розташовується у зібраннях:	174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)

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

Файл	Опис	Розмір	Формат
М_151_2022_Білецький.pdf Restricted Access		1.42 MB	Adobe PDF	Переглянути/Відкрити Запит копії

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

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

Extracted text

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

ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
освітнього ступеню «магістр»

на тему: ДОСЛІДЖЕННЯ РОЗРАХУНКУ КРИТИЧНОГО ШЛЯХУ
В ЗАДАЧАХ УПРАВЛІННЯ ІТ ПРОЕКТАМИ

Виконав: студент 2 курсу, групи МАКІТ-2109
спеціальності 151 Автоматизація та
комп’ютерно-інтегровані технології,
освітня програма «Комп’ютерно-
інтегровані технологічні процеси і
виробництва»

Олег БІЛЕЦЬКИЙ
(прізвище та ініціали)
Керівник Марина ЧИЧУЖКО
(прізвище та ініціали)
Рецензент Володимир ТИЧКОВ
(прізвище та ініціали)

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

2

ЗМІСТ

ВСТУП 5
РОЗДІЛ 1 СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУВАННЯ
ЗАДАЧ ............................................................................................................................11
1.1. Огляд предметної галузі та літературних джерел .................................. 11
1.2. Актуальність проведення досліджень ..................................................... 23
1.3. Постановка задачі дослідження ............................................................... 29
Висновки ........................................................................................................... 29
РОЗДІЛ 2 СИСТЕМИ УПРАВЛІННЯ ІТ ПРОЕКТАМИ ....................................31
2.1. Pivotal tracker .............................................................................................. 31
2.2. JIRA ............................................................................................................. 35
2.3. Microsoft Project ......................................................................................... 37
Висновки ........................................................................................................... 45
РОЗДІЛ 3 МЕРЕЖЕВІ МЕТОДИ ПЛАНУВАННЯ ..............................................46
3.1 Мережеві моделі ..................................................................................... 46
3.2. Методи побудови мережевих моделей ................................................... 51
3.3. Мережеві моделі ........................................................................................ 54
3.4. Удосконаленні математичні моделі розрахунків основних параметрів
дослідження ...................................................................................................... 61
Висновки ........................................................................................................... 66
РОЗДІЛ 4 ПРОГРАМНА РЕАЛІЗАЦІЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ УПРАВЛІННЯ ІТ ПРОЕКТОМ З РОЗРАХУНКОМ
КРИТИЧНОГО ШЛЯХУ ............................................................................................67
4.1. Вибір засобів реалізації ............................................................................ 67
4.2 Створення схеми відношень ..................................................................... 69

3

4.3. Структура системи .................................................................................... 73
4.4. Логіка роботи системи .............................................................................. 76
Висновки ........................................................................................................... 77
ВИСНОВКИ ..................................................................................................................78
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................................79
ДОДАТОК А ЛІСТИНГ ПРОГРАМИ ВИБОРУ КРИТИЧНОГО
ШЛЯХУ………………………………………………………………………80

4

СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
PMBOK PROJECT MANAGEMENT
FDD FEATURE DRIVEN DEVELOPMENT
DSDM DYNAMIC SYSTEMS DEVELOPMENT METHOD
RUP RATIONAL UNIFIED PROCESS
RAD RAPID APPLICATION DEVELOPMENT
СДР СТРУКТУРНА ДЕКОМПОЗИЦІЯ РОБІТ
ADM ARROW DIAGRAM METHOD
PDM PRECEDENCE DIAGRAM METHOD
PMI PROJECT MANAGEMENT INSTITUTE
ІТ ІНФОРМАЦІЙНИЙ ПРОЕКТ

5

ВСТУП
Актуальність. При розробці сучасного проекту провідні фахівці
підприємства проводять поетапний збір вимог та узгоджують всі деталі з
замовником. Після прийняття замовлення формується команда розробників,
щоб виділити основні модулі та необхідний функціонал, що має бути
створений в програмі. Далі відбувається поділ етапів роботи, коли
програмісти завершують поетапно проміжний етап роботи вони проводять
додаткові збори, де детально узгоджують подальші етапи розробки.
На сьогоднішній день ІТ-компанії в більшості працюють за тими
методологіями, які дозволяють продуктивніше розроблювати продукт з
високою якістю за менший проміжок часу. Плани та вимоги в подібних
проектах можуть узгоджуватись в процесі роботи, тоді як минулі стратегії
цього не дозволяли. Наприклад у водоспадній моделі побудови
програмного забезпечення не можна було тимчасово змінювати вимоги та
по-іншому робити проект.
Це викликало значні витрати та негативний результат під кінець
проекту. Тому управлінці почали створювати нові методології з іншими
принципами розробки програмного забезпечення та функціонування
команди. В результаті цієї стратегії з’явилися гнучкі методології побудови
програмного забезпечення.
Гнучкі методології спрямовані на мінімізацію ризиків, шляхом
перетворенняпроцесу розробки до серії коротких проміжків часу, що мають
форму ітерацій, які зазвичай проходять один-два тижні. Кожна ітерація
сама по собі проходить як програмний проект в мініатюрі, і складається із
завдань, необхідних для формування мінімального приросту за
функціональністю: планування, аналізу вимог, побудови, кодування,
тестування і документування.

6

Хоча окрема ітерація, як правило, занадто мала для випуску нової
версії продукту, мається на увазі те, що сучасний програмний проект
готовий до виходу наприкінці кожної ітерації. Після проведення кожної
ітерації, команда виконує переоцінку пріоритетів розробки і в результаті
з’являється нова ітерація. Формуючи таким чином проект, ми скорочуємо
наші ризики в проекті, а отже економимо ресурси замовника та час
працівників.
В кінці кожної ітерації формується готовий продукт або готовий
модуль даного продукту, це допомагає в процесі роботи економити час і
гроші на супроводі цього проекту. Саме це в процесі свого розвитку, та
прискорення оптимізації мов та технологій програмування та проектування
і сформувало світ таким яким він є зараз. Продукти таких таких відомих
корпорацій як Google, Mіcrosoft та Facebook були розроблені та
спроектовані відподно до цих гнучких стратегій розробки програмного
забезпечення.
Сучасне управління проектами суттєво пов’язане з роботою із
клієнтом, який буде користуватись тим чи іншим програмним продуктом, а
також замовником який вкладає ресурси в проект. Цей зв'язок був набагато
незначний в минулих методологіях розробки проектів, наприклад в
водоспадній моделі побудови програмного забезпечення, замовник не міг
змінювати вимоги чи вносити додаткові зміни після того як проект
приймався в роботу командою.
Це призводило до того, що замовник отримував не ту програму, яку
хотів на етапі закінчення проекту. Це було із-за того, що управління
проектами в розробці програмного забезпечення перенеслось із
промисловості, де замовники і розробники працювали з матеріальними
речами, а не з абстрактними. Тому був потрібен сучасний підхід до
управління проектами, а відповідно і до управління проектами програмної
інженерії, який би враховував специфіку проектів програмного

7

забезпечення, специфіку ринку проектів програмної інженерії, а також був
зрозумілим як для розробників проектів, так і для замовників.
Для початку розробники вирішили розробити певний набір правил та
стандартів. Так сформувався PMBOK (від англ. project management body of
knowledge - набір знань з управління проектами) – набір професійних знань
по управлінню проектами, в якому формується суть процесів управління
проектами та зв’язки між ними, а також цілі, для яких вони створені.
Поява такого стандарту змінило управління проектами в більш
продуктивний вигляд, тепер не було сумнівів між тим, до якого етапу
переходити чи ні. З’явилась точна структура і послідовність дій.
Так з’явився процес ініціювання. На цьому етапі описується склад
проекту з усіма цілями та робочими сторонами. Раніше цього не було, бо ці
сторони були в етапі планування. Виділення цих процесів в окремий етап,
сприяло не переходу до планування структури проекту, встановлення
ресурсів чи ризиків. Тобто поки не сформований контракт, в якому описані
ціль проекту, замовники і результати для кожного з них, проект не
починають робити. А це означає, що поки не сформовано етап ініціації
проекту, проект не переходить в стадію планування.
Також сформовано етапи моніторингу проекту та закінчення, які
раніше були в стадії виконання. Це виокремлення дало змогу більш точніше
відслідковувати зміни в проекті, та створювати в процесі закінчення
проекту саме той продукт, який хоче замовник.
Всі методології розробки використовують чи засновані на принципах
PMBOK. В програмній інженерії набули популярності та мають вплив
гнучкі методології розробки програмного забезпечення. Вони орієнтовані
на застосування ітеративної розробки, динамічне формування вимог і
забезпечення їх виконання в результаті постійної взаємодії в структурі
самоорганізованих робочих груп, що сформовано з фахівців різного

8

профілю. Існує кілька методик, що подібні до класу гнучких методологій
розробки, зокрема екстремальне програмування, DSDM, Scrum, FDD.
Прикладні та теоретичні аспекти розроблення моделей та засобів
розрахунку критичного шляху в задачах управління ІТ проектами представлені
в роботах вчених В. М. Глушкова, В.Ю. Бикова, В.І. Гриценка, М.З.
Згуровського, В.Г. Гриценка, Н. Ю. Єгорченкової, Ю.М. Теслі,
О. В. Співаковського, І.Б. та ін.
Основною вимогою є робочий продукт. Для програмної інженерії це є
оптимально, тому що всі процеси і працівники так чи інакше дотичні до
продукту, і роблять все для того щоб результат був робочий. Також це дуже
зручно для замовників, тому що для них найважливіше, це отримання
такого продукту, який вони бачать.
Також гнучкі методології дозволяють замовникам тримати руку на
пульсі етапів проекту і спостерігати за всим, що робиться в проекті. І ще є
важливим той факт, що замовник не витрачає зайві ресурси, і в кінці
кожного етапу розробки отримує готовий продукт.
Навіть якщо продукт, не є остаточно дороблений, а лише частково, це
допоможе в майбутньому ефективно його доробити, без зайвих витрат.
Саме тому гнучкі методології побудови програмного забезпечення є
основними на даний момент в ІТ сфері.

Мета і завдання дослідження
Метою дослідження є аналіз сучасних методологій розробки
програмного забезпечення. Встановлення переваг та недоліків програмного
забезпечення по розробці управління проектів. Застосування і розрахунок
способу критичного шляху для управління ІТ проектом.
Для досягнення поставленої мети в кваліфікаційній роботі магістра
визначена необхідність виконання наступних завдань:
− вивчення предметної області;

9

− огляд сучасних досліджень в сфері управління проектами;
− побудова критичного шляху для управління проектом;
− програмна реалізація проекту.
Об’єкт дослідження: методології управління ІТ проектом.
Предмет дослідження: критичний шлях в задачах управління ІТ
проектом.
Методи дослідження. Для вирішення поставлених завдань
використані теорії систем, методи просторових перетворень і об'єктно-
орієнтованого програмування, методів системного синтезу та аналізу для
визначення та опису компонентів данної галузі; методів та теорії
математичного моделювання.
Наукова новизна одержаних результатів. Наукова новизна
кваліфікаційної роботи магістра визначається розробкою і реалізацією
сучасних підходів до вирішення проблеми управління ІТ проектом:
– запропоновано синтез інформаційних технологій
управління та сучасних досліджень в сфері управління ІТ проектами;
– розроблено концепцію побудови критичного шляху для
управління проектом.
Практична значення одержаних результатів. Практичну цінність
мають наступні результати роботи:
– розроблена структура програмних засобів модуля
реалізація проекту з визначенням критичного шляху;
– реалізовано схема відношень розрахунку критичного
шляху для ІТ проектів.
Апробація результатів роботи. Результати кваліфікаційної роботи
доповідалися й обговорювалися на студентських і наукових конференціях:
− дні студентської науки ЧДТУ, 27-30 квітня, м. Черкаси, 2020;
− «Проблеми інформатизації»: Тези доповідей десятої
міжнародної науково-технічної конференції: 24 – 25 листопада

10

2022 року, том 2. – Черкаси – Харків - Баку – Бельсько-Бяла
(Польша)
Публікації. Результати досліджень опубліковані в:
1. It project management software with critical path calculation/
Chychuzhko M.V., Leshchenko R.S., Biletskyi O.I.// «Проблеми
інформатизації» : Тези доповідей десятої міжнародної науково-технічної
конференції 24 – 25 листопада 2022 року, том 2. – Черкаси – Харків - Баку –
Бельсько-Бяла (Польша) –– С. 13.

Структура та обсяг кваліфікаційної роботи. Кваліфікаційна робота
складається із списку умовних скорочено, вступу, трьох розділів, висновку
та списку використаних джерел. Загальний обсяг роботи складає 80
сторінок, 12 рисунків, 6 таблиця. Список використаних джерел містить 49
найменувань.

11

РОЗДІЛ 1
СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУВАННЯ ЗАДАЧ
1.1. Огляд предметної галузі та літературних джерел

На сьогоднішній день ІТ-компанії переважно використовують гнучкі
методології розробки програмного забезпечення.
Гнучка методологія розробки програмного забезпечення (англ. Agile
software development, agile-методи) – клас методологій створення
програмного забезпечення, що засновано на ітеративній розробці, в якій
вимоги та розв'язки розвиваються через співпрацю між
багатофункціональними командами, що самоорганізовуються. Гнучка
розробка – найкращий шлях для підвищення продуктивності та якості
розробників програмного забезпечення.
Більшість гнучких методологій спрямовано на мінімізацію ризиків,
шляхом перетворення розробки до серії коротких циклів, що схожі
на ітерації, які як правило тривають один-два тижні. Кожна ітерація сама по
собі схожа на програмний проект в мініатюрі, і включає всі завдання,
необхідні для реалізації мінімального приросту за функціональністю:
планування, аналіз вимог, створення, кодування, тестування і
документування. Хоча кожна ітерація, як правило, недостатня для
створення нової версії продукту, вважається на увазі те, що гнучкий
програмний проект готовий до реалізації наприкінці кожної ітерації. Після
закінчення кожної ітерації, команда реалізує переоцінку пріоритетів
розробки.
Agile спрямовує увагу на безпосередньому спілкуванні «віч-на-віч».
Більшість agile команд знаходяться в одному офісі, його асом
називають bullpen. Як мінімум вона складається із «замовників»
(замовники, які формують вимоги до продукту, також це можуть бути

12

програмні менеджери, бізнес-аналітики або клієнти). Офіс може також
складатися із тестувальників, дизайнерів інтерфейсу, технічних
співробітників і менеджерів.
Основною вимогою agile методів є робочий продукт. Віддаючи
перевагу живому спілкуванню, agile-методи зменшують розмір письмової
документації в порівнянні з іншими методами.
Agile – родина процесів розробки, а не єдиний шлях в розробці
програмного забезпечення, і називається Agile Manifesto. Agile не включає
практик, а описує цінності та принципи, які використовують успішні
команди.
Agile Manifesto сформований і прийнятий 11-13 лютого 2001 року на
лижному курорті The Lodge at Snowbird в горах Юти. Маніфест підписали
представники всіх сучасних методологій Extreme
programming, Scrum, Feature-driven development, DSDM, Crystal Clear,
Adaptive software development, Pragmatic Programming. Agile Manifesto
складається із 4 основних ідей та 12 принципів. Незвичайно, але Agile
Manifesto не містить практичних порад.
Базові ідеї:
1) особистості та їхні стосунки важливіші, ніж процеси та
інструменти;
2) робоче програмне середовище важливіше, ніж звітна
документація;
3) співпраця із замовником цінніша, ніж контрактні зобов'язання;
4) реакція на зміни цінніша, ніж дотримання плану.
Принципи, які формує Agile Manifesto:
− задоволення клієнта за рахунок швидкої та безперебійної поставки
вартісного програмного забезпечення;
− можливість змін вимог навіть наприкінці проекту (це може
підвищити конкурентоспроможність кінцевого продукту);

13

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

14

5) Agile Modeling – набір понять, принципів і прийомів (практик), що
дозволяють ефективно і просто виконувати моделювання і документування
на стадіях розробки програмного забезпечення. Не включає в себе точну
інструкцію з проектування, не включає описів, як будувати діаграми на
UML. Основна мета - швидке моделювання і документування; але не
включає програмування та тестування, не охоплює питання управління
проектом, розгортання і підтримку системи. Однак включає в себе
перевірку моделі кодом;
6) Agile Unified Process (AUP) спрощена версія IBM Rational Unified
Process (RUP), створена Скоттом Амблером, яка описує просте і зрозуміле
наближення (модель) для побудови програмного забезпечення для бізнес-
додатків;
7) Agile Data Method – група ітеративних методів побудови
програмного забезпечення, в яких вимоги та рішення реалізуються в рамках
співпраці різних крос-функціональних команд;
8) DSDM заснований на концепції ефективної розробки додатків
(Rapid Application Development, RAD). Являє собою ітеративний і
інкрементний спосіб, який надає особливого значення тривалій роботі в
процесі участі користувача/споживача;
9) Essential Unified Process (EssUP);
10) Екстремальне програмування (англ. Extreme programming, XP);
11) Feature driven development (FDD) – функціонально-орієнтована
розробка. Використовуване в FDD зміст функції або властивості (англ.
feature) Системи досить близько до складу прецеденту використання,
використовуваному в RUP, суттєва відмінність – це додаткова вимога:
"кожна функція повинна включати реалізацію не більше, ніж за два тижні".
Тобто якщо сценарій створення досить малий, його можна вважати
функцією. Якщо ж великий, то його необхідно розбити на декілька
незалежних між собою функцій;

15

12) Getting Real – ітераційний підхід без функціональних
специфікацій, що застосовують для веб-додатків. У даному методі спершу
формується інтерфейс програми, а потім її функціональна складова;
13) OpenUP – це ітераційно-інкрементний спосіб розробки
програмного забезпечення. Позиціюється, як легкий і гнучкий варіант RUP.
OpenUP розділяє життєвий цикл проекту на чотири фази: початкова фаза,
фаза уточнення, побудови та передачі. Життєвий цикл проекту забезпечує
надання зацікавленим сторонам та членам колективу можливостей
ознайомлення і прийняття рішень на протязі усього проекту. Це дозволяє
ефективно контролювати ситуацію і вчасно формувати рішення про
відповідність результатів. План проекту описує життєвий цикл, а кінцевим
результатом є розроблений додаток;
14) Scrum – встановлює правила управління процесом розробки та
дозволяє застосовувати вже існуючі практики кодування, коректуючи
вимоги або формуючі тактичні зміни. Використання цієї методології дає
можливість встановлювати і усувати відхилення від необхідного результату
на більш ранніх етапах побудови програмного продукту;
15) Ефективна розробка програмного забезпечення (англ. lean software
development). Використовує підходи з концепції ефективного виробництва.
Найпопулярнішою методологією гнучкої розробки є Scrum (Скрам).
Скрам повністю робить акцент на якісному формування процесу розробки.
У методології Scrum_всього_три_ролі:
− Scrum_Master (Скрам Майстер) відповідає за результат у проекті.
По суті, Скрам Майстер є зв’язком між менеджментом і командою
(менеджер проекту або тімліда). Важливо підкреслити, що Скрам Майстер
не формує завдання членам команди.
Основні обов’язки Скрам Майстра:
1) формує атмосферу довіри;

16

2) бере участь у мітингах в якості фасилітатора, тобто реалізує
успішну групову комунікацію;
3) усуває перешкоди;
4) перетворює проблеми і відкриті питання у видимі;
5) відповідає за підтримку практик і процесу в команді;
6) Скрам Майстер веде Daily Scrum Meeting і відстежує результати
команди за допомогою Sprint Backlog, відзначаючи стан всіх завдань у
спринті. ScrumMaster може також допомагати Product Owner формувати
Backlog для команди.
− Product_Owner – це людина, яка відповідає за побудову продукту
(представник замовника). Product Owner – це єдина точка прийняття
кінцевих рішень для команди в проекті.
Обов’язки Product Owner такі:
1) управляє цілями замовників і всіх зацікавлених осіб;
2) координує та визначає пріоритети в Product backlog;
3) надає зрозумілі і тестовані задачі команді;
4) взаємодіє з командою і замовником;
5) відповідає за побудову коду в кінці кожної ітерації;
6) Product Owner ставить завдання команді, але він не формує
завдання конкретного члена проектної команди протягом спринту.
− Team (Команда). Команда бере на себе зобов’язання щодо
виконання результату на спринт перед Product Owner. Робота команди
визначається, як робота єдиної групи. У Scrum внесок кожного члена
проектної команди не оцінюється, оскільки це порушує самоорганізацію
команди.
Обов’язки команди наступні:
1) відповідає за оцінку елементів backlog;
2) затверджує рішення по дизайну;
3) розробляє софт і надсилає його замовнику;

17

4) відстежує власний прогрес (разом зі Скрам Майстром);
5) відповідає за кінцевий результат перед Product Owner.
Product backlog – це документ, який формує список вимог до
функціональності, які упорядковані згідно зі ступенем важливості. Product
backlog формує список того, що повинно бути реалізовано. Елементи цього
списку записують, як «історії» (user story) або елементи backlog-у (backlog
items). Product backlog відкритий для вдосконалення усім учасникам Scrum-
процесу.
Обов'язкові поля:
− ID – унікальний ідентифікатор, порядковий номер, який
застосовують для ідентифікації історій у разі їх перейменування;
− назва (name) – стислий опис історії. Він повинен бути чітким, щоб і
розробники і product owner могли зрозуміти, про що йдеться і відрізнити
кожну історію від іншої;
− важливість (importance) – ступінь важливості кожної історії на
погляд product owner ’a. Зазвичай представляє собою натуральне число,
іноді для цієї цілі застосовують числа Фібоначчі. Чим більше значення, тим
вище пріоритет;
− попередня оцінка (initial estimate) – початкова оцінка змісту робіт,
необхідного для формування історії порівняно з іншими історіями.
Вимірюється у story point'ах. Приблизно півпадає з числом «ідеальних
людино-днів»;
− як продемонструвати (how to demo) – стисле пояснення того, як
кінцева задача буде продемонстрована у кінці спринта. Дане поле може
представляти собою код автоматизованого приймального тесту.
Іноді, також, використовуються додаткові строки у product backlog, в
основному для того, щоб полегшити product owner'у визначитися з його
пріоритетами.
Додаткові поля:

18

− категорія (track). Наприклад, «панель управління» чи
«оптимізація». За використанням цього поля product owner може легко
вибрати усі пункти категорії «оптимізація» і задати їм бажаний пріоритет;
− компоненти (components) – указує, які компоненти (наприклад, база
даних, сервер, клієнт) будуть застосовані при реалізації історії. Дане поле
складається з групи checkbox'ів, які відмічаються, якщо задані компоненти
потребують змін;
− ініціатор запиту (requestor). Product owner може бажати зберігати
інформацію про усіх замовників, задіяних у даній задачі. Це потрібно для
того, щоб тримати їх про стадії виконання робiт;
− ID у системі обліку помилок (bug tracking ID) – якщо ви
застосовуєте окрему систему обліку помилок, тоді у описі історії важливо
зберігати посилання на всі дефекти, які до неї дотичні.
Sprint backlog – містить функціональність, сформовану Product
Owner із Product Backlog. Всі функції поділені по задачах, кожна з яких
оцінюється командою. Кожен день команда встановлює об'єм роботи, який
необхідно реалізувати для завершення задачі.
Burndown chart – показує, скільки вже створено і скільки ще
залишається зробити.
Важливою частиною Скраму – це мітинги (Daily Scrum Meeting).
Відбувається кожен день під час спринту. Є «пульсом» ходу спринта. Зараз
властиві наступні обмеження:
− починається абсолютно вчасно;
− всі можуть спостерігати, але говорять лише «свині»;
− триває не більш ніж 15 хвилин;
− проводиться в одному і тому ж місці протягом кожного спринта.
Протягом наради кожен член команди дає відповідь на 3 запитання:
1) Що зроблено з початку попередньої щоденної наради?

19

2) Що буде зроблено з моменту початку поточної наради до
наступної?
3) Які проблеми заважають досягненню мети спринта? (Над
рішенням цих проблем працює Scrum Master. Зазвичай це рішення
реалізують за рамками щоденної наради і у складі осіб, що безпосередньо
працюють над даною перешкодою.)
В управлінні проектами є стандарти та правила яким має відповідати
проект без залежності від методології. Найголовнішим стандартом є
PMBOK (англ. Project Management Body of Knowledge). PMBOK – це
довідник, який складає набір процесів, що зазвичай описані та забезпечують
виконання завдань управління проектами окремо від галузі та організації,
орієнтований на тих, хто складатиме екзамен на сертифікат PMI (англ.
Project management institute — Інститут управління проектами).
PMBOK містить фундаментальні та базові практики, які за думкою
PMI, забезпечують фінансові результати для будь-якої організації —
локальної, регіональної або глобальної.
З метою виконання зобов'язання PMI невпинно поліпшувати та
оновлювати інформацію, а також відповідати статусу стандарту,
затвердженого Американським національним інститутом стандартів (англ.
American National Standarts Institute — ANSI), PMBOK вдосконалюється
щонайменше раз на п'ять років.
PMBOOK складається з дев’яти функцій: менеджменту розміру,
затрат, годин, якості, людських ресурсів, контрактів/постачання,
комунікацій, ризиків, проектної інтеграції. Перші чотири функції
(спрямовані на управління цілями) зазвичай називають основними.
1) Управління розміром проекту — контролює проект за допомогою
встановлення складових його мети, завдань і цілей.
2) Управління затратами — передбачає фінансовий контроль проекту
шляхом накопичення, аналізу та складанню звітів по затратах.

20

3) Управління часом — передбачає планування, складання
календарних графіків та їх перевірка для забезпечення вчасного виконання
проекту.
4) Управління якістю — забезпечує перевірка стандартів якості,
встановлених для проекту.
П’ять функцій, перелічених нижче (спрямовані на управління
певними об’єктами), вважаються додатковими:
1) Управління людськими ресурсами — включає напрям і
координацію діяльності людей, залучених до проекту.
2) Управління комунікаціями — накопичує інформацію, якою
комунікують члени проектної команди, керівництво, і сприяє
результативному завершенню проекту.
3) Управління контрактами/постачанням — передбачає відбір,
перемовини і підписання замовлень, контроль за поставками матеріалів,
устаткування і послуг (обслуговування).
4) Управління ризиком — залежить від складових невизначеності
проекту і базується на знаннях та досвіді із зазначенням умов виконання
конкретного проекту.
5) Управління проектною інтеграцією — має забезпечити відповідну
координацію всіх функцій проекту.
Всі процеси поділяються на такі групи:
1) Група процесів ініціації складається з процесів, що сприяють
формальної відмітці початку нового проекту. Процеси ініціації
часто реалізуються поза рамками проекту. У ході процесу
ініціації уточнюються початкове формування змісту і ресурси,
які організація планує вкласти. На цьому етапі також
визначається менеджер проекту, якщо він ще не призначений, і
документуються початкові допущення і обмеження. До групи
процесів ініціації відносять такі процеси:

21

− визначення залучених сторін та (відповідно до їх вимог) розробка
попереднього опису складових проекту;
− розробка Статуту проекту.
2) Група процесів планування
Визначає і описує цілі і планує дії, необхідні для досягнення цілей і
змісту, заради яких був сформований проект. До групи процесів планування
відносять такі процеси:
− Визначення обсягу
− Розробка плану управління проектом
− Оцінка ресурсів операцій
− Планування змісту згідно вимог (замовника зовнішнього або
власного)
− Вартісна оцінка
− Створення ієрархічної структури робіт (ІСР)
− Планування людських ресурсів
− Визначення складу операцій
− Визначення взаємозв'язків операцій
− Оцінка тривалості операцій
− Планування комунікацій
− Розробка розкладу
− Розробка бюджету витрат
− Планування якості
− Якісний аналіз ризиків
− Планування управління ризиками
− Ідентифікація ризиків
− Планування покупок
− Кількісний аналіз ризиків
− Планування контрактів
− Планування реагування на ризики

22

3) Група процесів виконання
Об'єднує людські та інші ресурси для реалізації плану управління
проектом даного проекту. До групи процесів виконання відносять такі
процеси:
− Керівництво та управління виконанням проекту
− Набір команди проекту
− Процес забезпечення якості
− Запит інформації у продавців
− Розвиток команди проекту
− Вибір продавців
− Поширення інформації

4) Група процесів моніторингу та управління
Регулярно оцінює результати проекту і здійснює моніторинг, щоб
виявити відхилення від процесу управління проектом, і, в разі необхідності,
провести коригувальні процеси для досягнення цілей проекту. До групи
процесів моніторингу і управління входять такі процеси:
− Моніторинг та управління роботами проекту
− Загальне керування змінами
− Підтвердження обсягу (відповідно змісту та цілям)
− Управління розкладом
− Управління обсягом
− Процес контролю якості
− Управління вартістю
− Адміністрування контрактів
− Звітність по виконанню
− Спостереження і управління ризиками
− Управління командою проекту
− Управління учасниками проекту

23

5) Група завершальних процесів
Формалізує виконання продукту, послуги або результату і підводить
проект або етап проекту до правильного завершення. Група завершальних
процесів складається з таких процесів:
− Закриття контрактів
− Закриття проекту

1.2. Актуальність проведення досліджень
Починаючи з початкових програмних проектів і по нинішній день,
розробка програмного забезпечення була і залишається досить не
передбачуваною і далеко не завжди успішною справою. Значний відсоток
проектів зі побудови програмного забезпечення, як і раніше закінчується з
перевищенням витрат, термінів, а створені в результаті програми часто не
повністю відповідають вимогам користувачів або приносять недостатньо
реальної користі бізнесу. Перераховані проблеми є основними
результатами, так званої кризи програмного забезпечення. Незважаючи на
значні інтелектуальні зусилля, витрачені на пошук можливостей подолання
кризи, до сих пір так і не визначено скільки-небудь універсальне рішення.
Ймовірно, найбільш помітною подією останніх років в області
процесів розробки програмного забезпечення стала поява терміну agile. Всі
говорять про гнучкі методи розробки, про те, як створити гнучку команду
розробників, або про те, як протистояти армії прихильників agile, готових
розтоптати усталені часами практики розробки.
Перш ніж приступити до предмету гнучкою методології, доцільно
повернутися до генезису управління проектами з побудови програмного
забезпечення.
Ранні підходи до розробки були незначно формалізовані і
представляли собою процес, який прийнято називати Code-and-Fix
(кодування і виправлення). При такому підході побудова програмного

24

забезпечення починається безпосередньо з кодування (без попереднього
планування, аналізу складових і проектування). Після цього знайдені в коді
помилки (дефекти, невідповідність вимогам і т.п.) виправляються шляхом
зміни множинних змін в код. Не дивно, що після значної кількості таких
змін система стає заплутаною, її важко підтримувати і розширювати.
Згодом стало зрозуміло, що для побудови великих стійких програмних
систем потрібні значно продумані і формальні підходи. У пошуках
вирішення проблеми увагу було привернуто на більш зрілі на той час галузі
людської діяльності, дотичні зі складним виробництвом - перш за все, на
системотехніка (systems engineering), а також інші інженерні питання, такі
як розробка і будівництво мостів, споруд і т.д . В результаті спроби
застосовувати перевірені в інших областях інженерні методи для розробки
програмного забезпечення з'явилася сучасна дисципліна - програмна
інженерія (software engineering), а в якості фактичного стандарту на довгі
роки ввійшли так звані інженерні методології розробки програмного
забезпечення. Ці методології також часто визначають як заснованими на
плані (plan-driven), тому що в їх основі закладено припущення про те, що
процес розробки програмного забезпечення є детермінованим інженерним
процесом, який можна побудувати від початку і до кінця і виконати
відповідно до плану, застосовуючі формальні інженерні підходи. В якості
основного варіанту складання життєвого циклу програмного продукту
використовувалася каскадна модель.
Каскадна модель описує розробку ПО як сувору послідовність етапів,
при цьому перехід на наступний етап проходить тільки після повного
виконання робіт на поточному етапі.
При використанні каскадної моделі важливими етапами, складовими
життєвий цикл процесу розробки ПО, є: аналіз предметної галузі,
проектування програмно-апаратного комплексу, побудова, тестування,
впровадження та супровід.

25

Аналіз полягає в отриманні та формалізації даних про вихідний об'єкт
автоматизації. Часто, особливо для аналізу складних об'єктів,
застосовуються моделі, одержувані шляхом використання методів
системного аналізу. На цьому етапі описуються вимоги до майбутньої
програмної системі, розміри проектних робіт, ризики, необхідні
трудовитрати, створюється технічне завдання і план-графік виконання
робіт.
Проектування полягає в побудові моделі майбутньої програмної
системи. Основними чинниками при цьому є: архітектура програмної
системи, модульна структура програмної системи, алгоритми
функціонування, потоки даних, потоки вхідних і вихідних даних
програмної системи.
Вихідними даними для створення є моделі і документація, побудовані
в результаті аналізу. Кодування полягає в побудові текстів програм на
цільовій мові програмування, в точності відповідних моделям, створеним в
результаті проектування. Результатом кодування є створені модулі
програмної системи.
Тестування полягає в перевірці працездатності програмної системи в
різних режимах її роботи з метою виявлення можливих дефектів у
функціях, логіці і формі реалізації.
Впровадження і супровід полягає в наданні програмної системи
замовнику і можливу подальшу зміну реалізуємих програм з метою
виправлення помилок, адаптації до змін зовнішнього середовища,
удосконалення за параметрами замовника.
Використання типового циклу розробки програмного забезпечення
дозволяє вдосконалити процес розробки, отримати план і часовий графік
побудови робіт. У той же час така модель має суттєвий недолік: цикл
заснований на припущенні про точність побудови вимог до програмної
системи. В реальності на початку проекту вимоги описуються лише

26

частково. Так як замовник має доступ до результатів проекту лише після
кінця виконання всіх робіт, він не може встановити вимоги і в більшості
випадків отримує зовсім не той результат, який йому був необхідний. Саме
цей недолік зробив типовий цикл розробки програмного забезпечення
майже непридатним.
Як показує практика, у багатьох випадках замовник не може точно
сформулювати вимоги до програмного продукту, який він хоче получити.
Більш того, часто сам процес побудови і впровадження програмних систем
впливає на внутрішні характеристики об'єкта автоматизації і може
побудувати їх таким чином, що початкові вимоги до програмного продукту
втратять актуальність.
Перехід до інженерних методологій і каскадної моделі, певно, був
кроком вперед. Він вніс певну впорядкованість і організованість в
процедуру розробки, а також виключив багато складностей підходу code-
and-fix. Однак інженерні методології за визначенням не могли подолати всі
проблеми програмних проектів, перш за все, через існуючий в них
внутрішній конфлікт. Справа в тому, що вони спочатку розроблялися за
зразком інших інженерних дисциплін і не до кінця враховували
особливості, притаманні кожному програмному забезпеченню як
унікальному виду продукції. Конфлікт унікальності програмного
забезпечення з властивостями інженерних методологій має, як мінімум, дві
основні властивості:
Перша властивість полягає в недооцінці ролі людського фактора.
Інженерні методології описували процес розробки як послідовність кроків,
виконувану абстрактним виконавцем, тобто певна увага фокусувалася на те,
що потрібно створити в процесі розробки, а не на тому, хто це буде робити.
Насправді ж більшість проблем програмних продуктів мають соціальну, а
аж ніяк не технологічну природу. Саме учасники проекту і комунікації між
ними є основним фактором, що впливає на успіх проекту.

27

Друга проблема полягає в невідповідності каскадного життєвого
циклу структурі програмного забезпечення. Принциповим моментом в
даному випадку є унікальність і новизна майже будь-якого програмного
продукту. Розробка ведеться в умовах великої невизначеності, і спроба
врахувати всі проблеми на початку проекту (скласти точні вимоги, потім
повністю розробити вигляд системи і т.д.) заздалегідь приречена на
невдачу. Найнеприємніше полягає в тому, що вади водоспадної моделі не
тільки ускладнюють процес побудови самі по собі, але до того ж ще й
нивелюють людські відносини. Наприклад, створення та затвердження
точних вимог на початку проекту часто призводить до протирічь між
замовником і виконавцем у разі потреби врахування змін на стадії
реалізації. Суперечки навколо потенційних змін призводять до погіршення
відносин і руйнують злагоджена комунікацію команди з замовником. Але
слід зазначити, що існують проекти, для яких водоспадний життєвий цикл
може ефективно працювати, однак для більшості проектів наведені вище
проблеми є актуальними і в значній кількості випадків призводять до
провалу проектів.
Таким чином, прогнозовані (інженерні) методології фокусуються на
точному плануванні майбутнього. Відомі заплановані завдання і ресурси на
повний термін проекту. Команда з витратами реагує на можливі зміни. План
оптимізований виходячи зі набору робіт і існуючих вимог. Зміна вимог
може привести до суттєвої зміни плану, отже, до зміни термінів і витрат
проекту.
Підсумовуючи сказане вище, можливо зробити висновок про те, що
інженерні методології щодо визначення були не в змозі розв'язати кризу
програмного забезпечення. Нові й нові помилки проектів, що
використовують інженерні методології, підштовхували до створення
альтернативних підходів до розробки. І вони не забарилися утворитися.

28

По мірі усвідомлення складностей інженерних методологій стали
з'являтися альтернативні підходи до розробки, покликані відкинути їх
недоліки.
У другій половині 90-х років створилася і набула популярності ціла
група так званих «гнучких методологій». Незважаючи на суттєві
відмінності в використовуваних практиках, ці підходи були тотожні в тому,
що в якості альтернативи інженерним методологій вони могли
запропонувати адаптивні, ітераційні, орієнтовані на користувача підходи.
Гнучкі методології - це підходи до створення програмного
забезпечення, орієнтовані на використання ітеративної розробки, динамічна
побудова вимог і забезпечення їх реалізації в результаті постійної
комунікації всередині самоорганізованих робочих груп, що складаються з
спеціалістів різного профілю.
Для побудови життєвого циклу програмного продукту застосовується
інкрементна модель.
Інкрементна модель життєвого циклу процесу побудови ПО заснована
на розбитті всього процесу розробки на конкретні етапи (інкремент), кожен
з яких включає основні стадії каскадної моделі: аналіз, проектування,
побудову і тестування.
На першому етапі реалізуються основні функції програмного
забезпечення, при цьому процес побудови проходить всі етапи класичного
циклу. Виконується системний аналіз об'єкта автоматизації і дослідження
вимог, будується план створення першої версії ПЗ, виконується
проектування, реалізація і тестування. В кінці першої стадії розробник
надає замовнику робочий програмний продукт з простою
функціональністю, проходить здача-прийом робіт. При цьому бажано
впровадження отриманих результатів програми в дослідну або навіть
промислову експлуатацію. Цей факт повинен враховуватися при побудові
функцій першої черги. На вхід другого і наступних етапів виходить

29

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

1.3. Постановка задачі дослідження
Необхідно дослідити існуючі системи управління проектами.
Розробити програмне забезпечення по керуванню ІТ проектом. Встановити
їх переваги і недоліки. Програмне забезпечення повинно відповідати
вимогам сучасних методологій управління проектами та розраховувати
критичний шлях проекту.

Висновки
Гнучкі методології спрямовані на подолання очікуваної неповноти
вимог і їх постійної зміни. Коли оновлюються вимоги, команда розробників
теж змінюються. Команда, що бере участь в змінній розробці, насилу може
передбачити результат проекту. Існує точний план лише на найближчий
період. Більш віддалені в часі плани присутні лише як декларації про мету
проекту, очікувані витрати і результати.
Оглянута предметна площина управління ІТ проектами та літературні

30

джерела. Розглянуті основі складові процессу управління ІТ проектами та
встановлено актуальність проведення дослідження. В результаті аналізу
предметної галузі сформовано задачі дослідження.

31

РОЗДІЛ 2
СИСТЕМИ УПРАВЛІННЯ ІТ ПРОЕКТАМИ
2.1. Pivotal tracker

Pivotal Trаcker — система відстеження помилок, призначена для
організації комунікації з користувачами та для управління проектами.
Pivotal Tracker є легким інструментом планування проекту, який
допомагає командам розробників програмного забезпечення будувати
реалістичні очікування, коли робота може бути побудована на основі
поточної продуктивності команди. Tracker візуалізує ваші проекти у вигляді
історій (віртуальні картки), що проходять крізь свій робочий процес,
заохочуючи вас розбити проекти на окремі частини і мають важливі
складові про результати і області. Як ваші оцінки команди і пріоритезацію
ці історії, Tracker ділить їх на майбутні ітерації, визначати природному
темпі роботи вашої команди, щоб точно передбачити, коли ви будете
завершити кожну роботу. прозорий вигляд команди слідопита пріоритетів
встановлює, що кожен знає, що має бути зроблено, що виконується, і коли
вона буде завершена. моторна філософія слідопита не тільки допомагає
вашій команді рухатись в ногу і план роботи, але коригувати і змінювати
курс, коли несподіване виникає, так що ваша команда може створити
раніше і більш послідовно.
Pivotal Tracker заохочує практичний гнучкий процес побудови
програмного забезпечення, як і піонером Pivotal Labs.

32

Рис. 2.1. Головне вікно Pivotal tracker

Ключове поняття системи Pivotal - «Velocity». Velocity - це середнє
число point-ів, які приходяться на ітерацію, він розраховується за недавно
закінченими ітераціям. В налаштуваннях проекту можна задати по скільком
итерациям буде_вираховуватися_Velocity.
Point - це відносна міра «зусиль» необхідних для побудови тікета. Для
користувачів раніше не знайомих з останніми термінами, поняття може
здатися дуже розмитим, його можна вважати як складність тікета або
обсягу робіт.
Припустимо, в тижневої ітерації Velocity складає 10. В цьому випадку
сума поінтів у тікетів в кожній ітерації не повинна перевищувати 10, інакше
вони почнуть перетворюватись в беклог. Якщо ж Velocity вичерпано і
закрито всі тікети, але при цьому є можливість на поточній ітерації зробити
ще кілька тікетів, то їх можна лише повернути з беклога, натиснувши на

33

кожному з тікетів старт і він автоматично падає в Current, якщо навіть на
нього не встановлено Velocity.
Points можуть виставлятися в одному з поточних видів:
1) Linear (0, 1, 2, 3)
2) Powers of 2 (0, 1, 2, 4, 8)
3) Fibonacci_(0,1,2,3,5,8)
Практично вся робота над проектом зводиться до роботи з головним
розділом проекту. В цьому є дві основні переваги:
− не треба оновлювати постійно сторінку;
− всю роботу на проекті можна визначити одним поглядом, а не
бігати по сторінках тримаючи все в голові.
На головній сторінці знаходяться stories, або по-іншому тікети. Приклад
story: 'A user should be able to add a product to their shopping cart'. Stories
описують як задачу, яку необхідно виконати.

Рис. 2.2. Вікно з user stories з показом поточної Velocity

34

Як ми бачимо, тут чотири строки «Done», «Current», «Backlog»,
«Icebox». Кожного з них ми можемо приховати і показати в будь-який
момент (рис. 2.2).
Icebox - це те куди переходить тікет після створення, і зберігається
там, поки Ви не починаєте над ним працювати, змінюючи його в Current.
Current - це список поточної ітерації (довжина ітера,ції зазначається в
тижнях). Якщо тікети не входять в поточну ітерацію, то вони автоматично
потрапляють_в_Backlog.
Backlog - якщо кількості Velocity (по дефолту 10 на один тиждень) не
вистачає на все тікети поточної ітерації, то зайві тікети падають в цю
стопку.
Done - це та стопка куди потрапляють зайві тікети після завершення
поточної ітерації.
Тікети можна переміщати між стопками (усіма крім Done). Зрозуміло,
що ми не можемо вже почавший роботу тікет покласти в Icebox, або
покласти в Backlog, то на що вистачає Velocity в наступній ітерації
(Current).
На цій же сторінці можна побачити колонки з Releases, My Work,
Charts, Project History, Charts, Labels Тікети можуть бути в ролі Feature, Bug,
Chore, Release.
У всіх цих типів можуть присутні наступні поля: Labels (tags), Owner,
Description, Attach file, Comments. Feature - це проста задача на проекті.
Крім простих полів може мати ще й оцінку в Points.
Bug - це задача, в якій вказано те що треба виправити.
Chore - це тікет в якому необхідно створити функціональність, яка
необхідна для розробника, але не встановлена замовником. Це може бути
або рефакторинг, або тестування, або щось інше ще.

35

Release - це просто тікет-прапорець, який створено для позначки
місця, на якому необхідно зробити реліз. Крім простих полів має поле
Deadline, з датою здачі релізу.
У Feature і Bug є кілька станів: Not yet started, Delivered, Started,
Accepted, Finished, Rejected.
У Release є тільки Not yet started, а у Chore є Not yet started, Accepted,
Started, Finished.
Пріоритети тікетів змінюються дуже легко, достатньо просто змінити
тікет на нову позицію drag & drop.
Pivotal Trаcker не безкоштовний продукт, він коштує великих грошей
і працює за моделлю SaaS. За $ 100 в місяць ви отримаєте можливість
побудови необмеженої кількості проектів та більше ніж 25 акаунтів.
Pivotal Trаcker може інтегруватися з Google Apps, тоді залучення
співробітників в проекти стає простіше, а до задачі можна відразу
прикріплювати файли з Google Drive (наприклад з описаною логікою).

2.2. JIRA
Atlassian JIRA – комерційна система визначення помилок, призначена
для організації спілкування з користувачами, хоча в певних випадках
систему можна використовувати для управління проектами. Розроблено
компанією Atlassian Software Systems. Платна. Має веб-інтерфейс. Назва
системи (JIRA) отримано при усічення слова «Gojira», японського імені
монстра Годзилла, що, в свою чергу, є відсиланням до назви конкуруючого
продукту – Bugzilla. JIRA створювалася в якості заміни Bugzilla і багато в
чому копіює її архітектуру. Система дозволяє працювати з декількома
проектами. Для кожного з проектів складає і веде схеми безпеки і схеми
оповіщення.
До версії 3.13.5 (включно) існувала версія для підприємства,
професійний і стандартна версії. Після - існувала тільки версія для

36

підприємства.
Jira заснована на Java EE і працює на декількох відомих базах даних і
операційних системах.
Jira заповнюється завданнями. Завдання містить назву проекту, тип,
тему, пріоритет, компоненти і зміст. Завдання може бути доповнено
додатковими полями (також і нові користувальницькі поля можуть бути
визначені), додатками (наприклад – фотографіями, скріншотами) або
коментарями. Завдання може редагуватися або лише змінювати статус,
наприклад, з «відкритий» в «закритий». Які переходи між станами можливі,
описується через настроюється робочий процес (бізнес-процес) (робочий).
Будь-які зміни в задачі заносяться в журнал.
Jira має значну кількість можливостей конфігурації: для кожної
програми може бути описаний окремий тип завдання з власним робочий,
набором статусів, одним або багатьма видами подання. Крім того, за
допомогою так званих «схем» можна визначити для кожного конкретного
Jira-проекту власні права доступу, поведінку і видимість полів і багато
іншого.
Завдяки всеосяжної архітектурі можна прилаштовувати Jira для
багатьох сфер бізнесу.
JIRA написана на Java і застосовує контейнер інверсії управління,
Apache OFBiz ERP і «WebWork 1». Для віддаленого виклику процедур
(RPC), JIRA підтримує SOAP, XML-RPC і REST.
JIRA інтегрується з такими системами керування версіями, як
Subversion, CVS, Git, Clearcase, Team Foundation Server, Mercurial і волею-
неволею. Вона поставляється з різними мовами, включаючи українську.
Гнучка плагін-архітектура JIRA забезпечує користувачеві можливість
будувати розширення її самої і робити їх доступними для всіх користувачів
JIRA Atlassian через Marketplace. Можлива як інтеграція інших продуктів в
JIRA, так і інтеграція JIRA в інші програми, наприклад - в інтегровані

37

середовища розробки, як Eclipse, IntelliJ IDEA і за допомогою Atlassian IDE-
коннектора.
2.3. Microsoft Project
Microsoft Project став фактично стандартом серед програм
автоматизації індивідуальної роботи менеджерів проектів. Свою
популярність він заслужив завдяки простому поєднанню простоти
використання, дружнього інтерфейсу і найбільш затребуваних інструментів
управління проектами.
Microsoft Project розрахований, у першу чергу, на користувачів, що не
є професіоналами в управлінні проектами. Таким чином, його можливо
віднести до “непрофесійних систем” управління проектами. З іншого боку,
за допомогою Microsoft Project можна управляти проектами зі значним
обсягом робіт і ресурсів.
Microsoft Project входить у сімейство Microsoft Office, що
підтверджується схожістю його властивостей:
− побудова інтерфейсу і довідкової системи на тотожніх з Microsoft
Office принципах;
− можливість збереження бази проектів у базі даних Access;
− двосторонній обмін проектами з Outlook.
Переважна більшість менеджерів, які застосовують Microsoft Project,
використовують його для планування простих задач. За оцінками, половина
користувачів планує проекти розміром до 50 робіт, і лише від 10% до 20% –
проекти, в яких до 100 робіт. Проте, сучасні версії Microsoft Project цілком
придатні для застосування управління і великих проектів. На думку
західних експертів, Microsoft Project 2002 здатний проводити розрахунок
розкладів і управління складними проектами, розмір яких становить як
мінімум 10000 задач. Він добре підходить для управління проектами, що
стосуються кілька відділів, і в яких ключовою вимогою є автоматичне

38

створення графіків робіт, прогнозування стадій робіт і відстеження їх
виконання.
Серед переваг Microsoft Project також можна визначити вдосконалені
засоби групової роботи, що дозволяють одному менеджеру одночасно
керувати декількома проектами з достатнім числом учасників. На думку
Gartner Group, Microsoft Project – кращий вибір для організацій, де
застосовується матрична схема управління, тобто проектні команди
реалізують взаємодію співробітників з різних департаментів.
До недоліків системи можна віднести обмежені можливості
управління бюджетом і відсутність можливостей для управління ризиками
проекту.
Для розширення функціональності системи створено додаткові
модулі, доступні для безкоштовного завантаження через Internet. Крім того,
існує web-сервіс Microsoft ProjectCentral.com, призначений для реалізації
спільної роботи над проектами для груп, розподілених територіально.
ProjectCentral.com надає членам робочої групи і всім зацікавленим сторонам
веб-сторінки для роботи з інформацією проекту.
Перед початком роботи над проектом необхідно поділити проект на
його задачі, описати їх зв’язки, оцінити облсяг задач і описати ресурси,
необхідні для реалізації проекту. Це є вихідною інформацією для запуску
Microsoft Project, і, як правило, цю роботу виконує менеджер. На основі цієї
інформації система автоматично будує докладний календарний план ходу
виконання робіт, створює критичні шляхи, виконує розрахунки
кошторисних витрат, надає членам команди всю необхідну інформацію і
відображає її в простому для аналізу вигляді (рис. 2.3).

39

Рис. 2.3. Запуск проекту в MS Project

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

40

для користувача настройки виглядів використовують “Мастер Диаграмм
Ганта”.

Рис. 2.4. Настройка представлення за допомогою “Мастера диаграм Ганта”

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

41

витрати праці, одиниці виміру і робочий час, що вносяться в календарі. На
планування можуть вплинути й інші елементи, а саме час випередження і
час запізнення, доступність ресурсів, типи задач.
Для систематизації календарного плану в Microsoft Project можна
застосовувати структуру, яку можна задавати по ходу внесення задач або
проекту після того, як всі задачі внесені. Структурування дозволяє
організувати задачі у вигляді списку сумарних задач і підзадач. За
замовчанням усі сумарні задачі наведено напівжирним шрифтом і
розташовуються з виступом, а підзадачі наведено під ними з відступом.
Сумарні задачі допомагають визначити основні і проміжні етапи
проекту. Вони підсумовують дані підзадач, згрупованих у структурі під
відповідною сумарною задачею. В структурі можна визначити будь-яку
кількість рівнів, необхідну для відтворення схеми організації проекту.
Для позначення важливої події, наприклад, завершення значного
етапу, в календарному плані використовують віхи – задачі з нульовою
тривалістю.
Структуру проекту в Microsoft Project можна задати і навести
декількома способами. Крім сумарних задач і віх для цього також
застосовують коди структурної декомпозиції робіт (СДР) або коди
структури.
Структурна декомпозиція робіт (СДР) – це ієрархія задач у проекті,
яка встановлюється послідовностями цифр, літер та їх комбінаціями.
Microsoft Project дозволяє виводити структурну декомпозицію робіт за
допомогою ідентифікаторів задач або за допомогою кодів СДР.
Код структурної декомпозиції робіт (СДР) – це літерно-цифровий код,
що однозначно описує місце розташування кожної задачі в загальній
структурі проекту. Коди СДР можна використовувати для наведення
календарного плану і відстеження витрат.
У Microsoft Project застосовуються коди СДР двох типів. Перший тип

42

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

43

Таблиця 2.1.
Види залежностей між задачами
Тип залежності Опис
Закінчення-початок задача Б не може початись, поки не закінчиться
задача А.
Закінчення- задача Б не може закінчитись, поки не закінчиться
закінчення задача А.
Початок-початок задача Б не може початись, поки не почнеться задача
А.
Початок-закінчення задача Б не може закінчитись, поки не почнеться
задача А.

При додаванні задач до списку задач потрібно ввести для кожної з
них її тривалість і зв’язки. Дати початку і закінчення будуть встановлені в
Microsoft Project автоматично. Для досягнення максимальної гнучкості при
плануванні варто уникати можливих обмежень дати початку або закінчення
задачі.
При введенні нової задачі в Microsoft Project, їй автоматично
встановлюється тривалість в один день. Знак питання біля тривалості
вказує, що це лише початкова оцінка. Задачі можна встановлювати
астрономічну тривалість. У цьому випадку тривалість буде
встановлюватись без врахування неробочого часу і вихідних.
Для оцінки тривалості задач може бути застосований аналіз за
методом PERT. Після встановлення оптимістичної, песимістичної й
очікуваної тривалостей задач календарного плану проводиться розрахунок
зваженої величини цих трьох значень. Крім того, оптимістичні,
песимістичні й очікувані значення можуть застосовуватись окремо для
визначення найбільш ранньої, пізньої і ймовірної дат закінчення проекту.
За замовчанням у Microsoft Project задачі встановлюються відповідно

44

до періодів робочого часу, зазначених в календарі проекту. Проте можна
застосовувати окремі календарі задачі. Вони дозволяють визначити
індивідуальні винятки для конкретних задач, наприклад, якщо обладнання
функціонує у неробочий час або в робочий час вимагає застосування робіт з
обслуговування.
Контроль за виконанням задач можна реалізувати за допомогою
крайніх термінів для задач. Крайні терміни не є обмеженнями. При
відновленні календарного плану задача, яка не завершена до крайнього
терміну, позначається індикатором.
Іноді для встановлення характеру залежності між задачами
недостатньо визначення зв’язку. Щоб показати, що час виконання задач
перекривається, встановлюють час випередження задачі. Якщо ж потрібно
задати затримку між виконанням задач, встановлюють час запізнення.
Час випередження – це час перекриття задач, які залежать одна від
одної. Наприклад, якщо можна включити задачу, коли задача-попередник
закінчена тільки наполовину, для задачі-послідовника встановлюють
залежність “закінчення-початок” з часом випередження 50%. Час
випередження встановлюється як від’ємне значення часу запізнення.
Час запізнення – це затримка між задачами, які мають залежність.
Наприклад, якщо між закінченням однієї задачі і початком іншої задачі
необхідна затримка в два дні, між ними встановлюють залежність
“закінчення-початок” і встановлюють час запізнення у два дні.
В процесі уточнення календарного плану може виникнути
необхідність зупинити виконання задачі. Наприклад, виконання однієї з
задач проекту може вимагати матеріалів, які будуть доступні тільки через
тиждень; або може виявитися, що якісь дві задачі за планом реалізуються
одночасно і використовують один ресурс. Якщо календарний план
дозволяє, можна перервати одну з задач, щоб частина задачі була виконана
до початку другої задачі, а інша частина – після закінчення цієї задачі.

45

Задачу можна переривати декілька разів.

Висновки
Кожна програма має як ряд переваг так і численні недоліки. Одним із
вагомих факторів, який спонукає замовляти створення подібних програм, а
не використовувати вже діючі - є авторське право. Кожен розробник хоче
отримати за свій програмний продукт певні економічні кошти, але дуже
часто ціна за програму є не доступною для користувача. Також суттєвим
недоліком є те, що не в усіх программах є побудова критичного шляху для
проекту, що є дуже важливим для управління проектом.

46

РОЗДІЛ 3
МЕРЕЖЕВІ МЕТОДИ ПЛАНУВАННЯ
3.1 . Мережеві моделі
На сьогоднішній день тактичні плани формуються за допомогою
інформаційних систем управління проектами. Але, сучасні інструменти
планування проектів базуються на мережевих моделях.
Метод складання і тип плану залежать від його типу. А таких типів у
сучасній літературі визначають чотири:
1.Концептуальний план.
2.Стратегічий план.
3.Тактичний план.
4.Оперативний (недільно-добовий, місячний) план.
Концептуальний план може бути написаний на аркуші паперу,
написаний від руки і описувати базові концепції проекту: цілі, результати,
основні завдання. Термін придатності плану може досягати до 5 років.
Концептуальний план не є документом.
При стратегічному плані-проект розділяється на укрупнені складові і
віхи, які встановлюються за термінами, вартості та відповідальним особам.
Прикладом стратегічного плану може виступати життєвий цикл проекту і
опис його фаз. Для складання плану вже можна використовувати спеціальні
інформаційні засоби: MSProject, PrimaveraOracle, SpiderProject. Якщо
проект не об'ємний, то може зійти і MicrosoftExcel. Стратегічний план
формується на рік - два і вже може надаватися як офіційний документ.
При тактичному плануванні встановлюється, яким чином можливо,
реалізувати стратегію. Іншими словами, стратегічний план розділяється на
окремі завдання, які мають свої терміни, зв'язку, на них встановлюють
ресурси і визначають вартість. За ідеєю, сукупність цих завдань повинна
встановити реальне уявлення про терміни і вартість проекту. Якщо обсяг

47

проекту становить більше 10 робіт, то вже має сенс для побудови
тактичного плану застосовувати спеціальні методи та інформаційні засоби.
Бажано тактичний план формувати до року, але при цьому необхідно
враховувати всі обставини. Цей план є офіційним документом проекту.
Оперативний план складається від тижня до місяця і є набором
завдань для виконавців та відповідальних осіб, з встановленими
конкретними датами і термінами, які отримані з тактичного плану.
Мережева модель-це план виконання визначеного комплексу
взаємопов'язаних робіт, заданого в формі мережі, графічне зображення якої
описується мережевим графіком. Математичний апарат мережевих моделей
засновано на теорії графів. У проектах мережеві графіки призначені для
вирішення двох важливих проблем: формування календарного графіка
виконання робіт проекту і прийняття продуктивних рішень в процесі його
реалізації. Ефект, який досягається при застосуванні мережевих графіків,
обумовлений формалізацією структури проекту і кількісним виглядом його
параметрів, в першу чергу тимчасових.
Застосування мережевого планування допомагає ввирішити такі
питання:
1) Скільки часу потрібно для розробки всього проекту?
2) Коли повинні закінчуватися і починатися конкретні роботи?
3) Які роботи є "критичними" і повинні виконуватися виключно за
графіком, щоб не зірвати строки виконання проекту в цілому?
4) На який термін можна відкласти завершення "некритичних"
робіт, щоб це не вплинуло на троки виконання проекту?
До основних параметрів мережевої моделі належать наступні
єлементи.
Критичний шлях - найдовший шлях проекту.
Робота - це будь-які процеси (дії), що призводять до досягнення
заданих результатів (подій). Поняття "робота" може мати такі значення:

48

− дійсна робота-робота, що потребує витрат часу і ресурсів;
− очікування- процес, що потребує витрат тільки часу (сушка,
старіння, релаксація і т.п.);
− фіктивна робота, або залежність - побудова логічного зв'язку
між роботами (зображується пунктирною стрілкою, над якою не
проставляється час або проставляється нуль). Використовується тільки в
ADM (Arrow Diagram Method).
Віха - робота з нульовою тривалістю. Може встановлювати ключовий
момент в проекті, яку роботу, яка застосовує часу менше, ніж робочий день
(підписання договору, оплата і т.п.). Застосовується тільки в PDM
(Precedence Diagram Method).
Подія є результатами завершених робіт. Подія не є процесом і не має
тривалості. Наступ події співпадає з моментом початку або закінчення робіт
(моменту формування певного стану системи).
Зв'язок - відображення залежності між роботами.
Ранній початок - момент часу, до початку якого робота відбутися не
може, попередні роботи повинні бути завершені.
Раннє закінчення - точка в часі, що знаходиться від точки раннього
початку роботи на величину тривалості останньої.
Пізніше початок - момент часу, після початку якого робота початися
не може, інакше будуть порушені строки реалізації процесу.
Пізніше закінчення - точка в часі, що знаходиться від точки пізнього
початку роботи на величину тривалості останньої.
Резерв часу - це період часу, визначений точками раннього і пізнього
закінчення робіт.
Критична робота - робота, яка знаходиться на критичному шляху і не
має резерву часу. Оскільки в мережевому графіку знаходяться два типи
елементів - вершини і зв'язку, то і представлення робіт може здійснюватися

49

двома шляхами. Робота - вершина, або робота - ребро (зв'язок). Тому існує
два основні методи планування.
Світова спільнота в створенні мережевих моделей пішло двома
шляхами:методи стрілочних та попередніх діаграм.
В Європі застосовували «Метод стрілочних діаграм» (ADM - Arrow
Diagram Method).
Суть методу полягає в тому, що: подія або робота представляються у
вигляді стрілки, а зв'язок між ними - у вигляді вузла.
Цей тип мереж називається - «вершина - подія». Хвіст стрілки являє
початок, а вістря - закінчення роботи. Довжина стрілки не пов'язана з
приблизною тривалістю роботи. Роботи з'єднуються в точках, вузлах
(зображують, як маленькі кружечки) для ілюстрації приблизної
послідовності виконання робіт. Ці вузли позначають подіями. Цифра біля
вершини (стрілки) - довжина роботи. Такі мережеві моделі іноді називають
«європейськими».
На малюнку 3.1. показаний стандартний вигляд мережевого графіка по
моделі ADM:

2
2 4
1 5
1 5
7
3 10

Рис. 3.1. Мережевий графік по методу стрілочних діаграм

50

У США в ті ж роки вчені та керівники робили іншим шляхом і
запропонували Метод попередніх діаграм (PDM - Precedence Diagram
Method), де подія наводиться у вигляді вузла, а зв'язок між подіями
позначається стрілкою. Цей тип мереж називається - «вершина -
робота».

Рис. 3.2. Мережевий графік по методу попередніх діаграм

Роботи пов’язані відносинами передування для відображення
послідовності виконання робіт. Такі мережеві моделі іноді називають
«американськими».
Залежно від змісту проектів PDM дають можливість застосовувати
такі типи зв'язку між роботами:
− закінчення - початок (ОН, finish-to-start);
− початок - початок (НН, start-to-start);
− закінчення - закінчення (ГО, finish-to-finish);
− початок - закінчення (АЛЕ, start-to-finish).

51

PDM модель розраховується аналогічно ADM моделі, і це можна
легко побудувати не вручну, а автоматично, за допомогою спеціальних
програмних засобів.
Метод попередніх діаграм використовують у всіх сферах управління
проектами і зарекомендував себе як надійний і зручний інструмент.
Тому, з часом метод стрілочних діаграм втратив актуальність і на
практиці частіше стали застосовувати PDM моделі, але з істотним
«апгрейдом». По-перше, роботи зі зв'язками нанесли на календар і
побудували календарно - мережевий план.
Календарно-мережевий план-це динамічна модель виробничого
процесу, що зображає технологічну залежність і послідовність проходження
комплексу робіт, погоджує їх звершення в часі з урахуванням необхідних
ресурсів і вартості робіт з позначенням при цьому вузьких (критичних)
місць.
По-друге, PDM моделі стали зображати у вигляді діаграми Ганта
(Ganttchart), так як календарні плани найбільш зручно зображати саме в
такому вигляді.
Діаграма Ганта дає графічне зображення розкладу проекту, завдяки
нанесенню робіт у вигляді накладених на тимчасову шкалу окремих
прямокутників (або ліній), довжина яких співвідносна з тривалістю робіт.
На діаграмах Ганта можуть бути нанесені тільки ранні, або ранні та пізні
дати, а також можуть бути додатково нанесені логічні зв'язки між роботами.

3.2. Методи побудови мережевих моделей
Побудова мережевої моделі (структурне планування) починається з
поділу проекту на чітко визначені роботи, для яких встановлюється
тривалість. Робота - це заданий процес, що приводить до досягнення
певного результату, що вимагає витрат яких-небудь ресурсів і має

52

протяжність в часі. За кількістю затраченого часу робота може бути:
− дійсної, тобто що потребує витрат часу;
− фіктивної, тобто формально не вимагає витрат часу.
Фіктивна робота може дійсно існувати, наприклад, "передача
документів від одного підрозділу до іншого". Якщо тривалість такої роботи
суттєво мала в порівнянні з тривалістю інших робіт проекту, то формально
її приймають рівною 0.
Існують фіктивні роботи, яким в дійсності не відповідають ніякі дії.
Такі фіктивні роботи тільки створюють зв'язок між іншими роботами
мережевий моделі.
Роботи пов'язані один з одним таким способом, що виконання одних
робіт може бути розпочато лише після завершення деяких інших. Подія - це
момент часу, коли закінчуються одні роботи і починаються інші. Подія
являє собою результат виконаних робіт і, на відміну від робіт, не має
тривалості в часі.
Взаємозв'язок робіт і подій, необхідних для досягнення заданої мети
проекту, описується за допомогою мережного графіка (мережевої моделі).
Роботи наводться стрілками, які з'єднують вершини, що зображують
події. Початок і закінчення будь-якої роботи описуються набором подій, які
називаються початковою і фінішною подіями. Тому для зазначення
конкретної роботи використовують код роботи, що формується з номерів
початкової (i-го) і кінцевої (j-го) подій (рис.3.3).

робота (i,j)
i j
початкова кінцева
подія подія

Рис.3.3. Кодування роботи

53

Будь-яка подія може вважатися виконаною тільки тоді, коли
закінчаться всі зазначені в ній роботи. Тому роботи, що виходять з заданої
події, не можуть розпочатися, доки не будуть виконані всі роботи, що
входять в цю подію. Подія, що не включає попередніх їй подій, тобто з якої
починається проект, називають початковою чи вихідною. Подія, яка не має
наступних подій і описує кінцеву мету проекту, називається завершальним.
При побудові мережевого графіка треба дотримуватись загальних
правил:
− довжина стрілки не змінюється з часом виконання роботи;
− стрілка може виглядіти не прямолінійним відрізком;
− для дійсних робіт застосовують суцільні, а для фіктивних - пунктирні
стрілки;
− кожна операція може бути представлена лише однією стрілкою;
− між одними і тими ж подіями не може бути паралельних робіт, тобто
робіт з однаковими кодами;
− слід виключати перетин стрілок;
− не повинно бути стрілок, з напрямом справа наліво;
− номер початкової події має бути менше номера кінцевого події;
− не повинно існувати висячих подій (тобто не включають попередніх
подій), крім вихідної;
− не повинно існувати тупикових подій (тобто не мають наступних
подій), крім завершальної;
− не повинно існувати циклів.
Вихідні дані для створення мережевої моделі можуть описуватися
різними способами:
− описом передбачуваного проекту. В цьому випадку треба самостійно
розбподілити його на окремі роботи і визначити їх взаємні зв'язки;
− списком робіт проекту. В цьому випадку треба проаналізувати зміст

54

робіт та встановити дійсні між ними зв'язки;
− списком робіт проекту з описом їх упорядкування. В цьому випадку
необхідно тільки описати роботи на мережевому графіку.
Побудова мережевого графіка треба починати з встановлення
вихідних робіт моделі. Якщо згідно з умовою кожна робота може
виконуватися, не доходячи закінчення будь-яких інших робіт, то така
робота буде вихідною в мережевий моделі і її стартовою подією є вихідна
подія. Якщо вихідних робіт декілька, то їх стрілки рисують всі з одної
вихідної події.
Якщо, згідно з умовою, після закінчення конкретної роботи не
повинні виконуватися ніякі інші роботи, то така робота є фінішною
роботою мережевої моделі і її кінцевою подією є завершальна подія. Якщо
завершальних вихідних робіт багато, то їх стрілки заходять всі в зазначену
завершальну подію.
Якщо, згідно з умовою, кілька робіт мають загальну начальну і
загальну кінцеву подію, то вони є паралельними, включають однаковий код,
що неприпустимо. Для усунення паралельності робіт створюють додаткову
подію і фіктивну роботу (якої в реальності не відповідає жодна дія) таким
чином, щоб фінішні події робіт розрізнялися.

3.3. Мережеві моделі
Шлях - це послідовність робіт в мережевому графіку (в кожному
випадку це одна робота), в якій кінцева подія кожної роботи збігається з
початковою подією наступної за нею роботи. Повний шлях - це шлях від
початкової до завершальної події.
Критичний шлях - максимальний за протяжністю повний шлях.
Роботи, що знаходяться на критичному шляху, називають критичними.
Критичні роботи включають нульові, вільні і повні резерви. Підкритичній
шлях - повний шлях, найближчий за протяжністю до критичного шляху.

55

Критичний шлях у проекті - це найтриваліша (за строками) стрічка
ланцюжок, операцій. Критичним шляхом на графіку є неперервна
послідовність операцій. Довжина критичного шляху встановлює тривалість
робіт по виконанню проекту. Будь-які затримки на критичному шляху
призводять до збільшення тривалості робіт. Крім того треба зазначити, що
для скорочення тривалості робіт за проектом необхідно скорочувати
довжину критичного шляху.
Резерв або запас часу - це різниця між самим початковим можливим
терміном завершення операції і самим пізнім можливим часом її виконання.
Резерв часу є лише в тих операціях, які не знаходяться на критичному
шляху, і створює деяку ступінь гнучкості при календарному плануванні
подібних робіт.
Мережевий графік створює наочну і зрозумілу картину переліку робіт
по виконанню проекту крім того, що такі графіки зображують початок і
закінчення операції. Вони чітко зазначають на черговість виконання
операцій. На ньому наочно видно результати кожного запізнювання
операції з точки зору часу реалізації всього проекту.
Мережний графік дозволяє, встановити часові характеристики
проекту і робіт, які він містить. У цьому значенні найбільш важлива дія в
побудові плану проекту мають так звані критичні роботи. Робота буде
критичною, якщо затримка її початку призводить до затримки строку
закінчення проекту в цілому. Некритична робота визначається тим, що
відрізок часу між її раннім початком і пізнім закінченням більше її
фактичної тривалості. Іншими словами, кожна некритична робота має
резерв часу.
На основі поняття критичної роботи описується поняття критичного
шляху. Критичний шлях становить безперервну послідовність критичних
робіт і пов’язує між собою стартову і завершальну події мережного графіку.
Як бачимо, метод CPM має деякі переваги: дозволяє одержати

56

графічне представлення проекту, встановлює орієнтований час, необхідний
для його виконання, і позначає, які дії є критичними, а які ні при виконанні
графіка робіт.
Фундаментальним поняттям методу є критичний шлях, або шлях
максимальної проміжку часу через усю мережу - від початку першої роботи
до завершення останньої. Суть методу полягає в тому, що позначаються
роботи, тривалість яких не може мінятися без спеціальної необхідності, і
роботи, тривалість яких змінюють без впливу на час виконання повного
проекту.
Затримка кожної з дій на критичному шляху веде до збільшення
тривалості усього проекту. Аналогічно, щоб прискорити його, потрібно
зменшити час виконання одної або декількох дій, що знаходяться на
критичному шляху.
Звичайно, в ході виконання проекту фактичний час, необхідний на
кожну дію, незначн змінюється в ту або іншу сторону. Дії, що знаходяться
на критичному шляху, можуть перестати бути на шляху, шлях може бути
пройдений по-іншому, і тривалість проекту буде змінюватись уже від
іншого списку робіт. Тому критичний шлях періодично перевіряють і
визначають резерви часу для дій, що залишилися.
Тривалість критичного шляху становить мінімально можливу
тривалість проекту в цілому, (тобто для побудованого мережного графіка
робіт бистріше завершити проект не вийде). Якщо обчислена тривалість
критичного шляху вас не задовольняє, необхідно перебудувати структуру
мережного графіка.
На практиці існують проекти з високою невизначеністю строків
виконання, де метод СРМ спрацьовує неефективно. Тоді альтернативою є
розробка проектів за методикою PERT. Метод PERT дозволяє врахувати
зміни тривалості кожної дії, тобто дозволяє для кожної дії встановити
певний діапазон тривалості. У цій мережній моделі застосована нумерація

57

подій, причому кожна наступна подія має більший номер. Дії позначаються
буквами, а поруч позначається їхня передбачувана тривалість.
Типовий квант часу, який використовують у PERT, – один тиждень,
але при необхідності може застосовуватись і будь-який інший проміжок
часу. Для кожної дії позначають три оцінки його тривалості - оптимістичну
(О), найбільш імовірну (Й) і песимістичну (П). Приблизний час тривалості
кожної дії може бути приблизно встановлений як (О + 4Й + П)/6. Цей
розрахунковий час і позначається на графіку.
Критичний шлях, як і в CPM, становить повний календарний час,
необхідний для проекту, і складає той же зміст. Розрахункова дата
закінчення є найбільш імовірною, і також при істотній кількості дій, що
складають критичний шлях проекту, це співвідношення буде близьким до
реального.
Метод дозволяє встановити очікуваний час закінчення проекту,
ймовірність його виконання до конкретної дати і визначити дії, що мають
"люфт", тобто можуть включати ресурси для виконання дій, що знаходяться
на критичному шляху. Для одержання ще більш точних оцінок
використовують спеціальні математичні моделі, наприклад, метод Монте-
Карло.
Календарний графік створюється на основі діаграми Ганта. Діаграма
Ганта — це лінійний графік, що задає довжину початку і закінчення
взаємозалежних робіт, із зазначенням ресурсів, які застосовуються для
їхнього виконання. На горизонтальну вісь діаграми наноситься абсолютний
або відносний час, який триває із початку виконання проекту.
Так для вищенаведеного прикладу проекту по створенню
програмного продукту діаграма Ганта буде мати такий вигляд (Рис. 3.4). На
горизонтальні осі нанесено довжина робіт від початку виконання проекту
по створенню програмного продукту з зазначенням виконавців (відладкою
модулів займаються два програмісти, а написання програмної документації

58

покладено на техніка; програміст 1, програміст 2, технік).

Рис.3.4. Приклад діаграми Ганта

Слід звернути увагу на те, що на діаграмі Ганта лінії, що описують
роботи проекту, на відміну від дуг мережного графіка, складають відносну
тривалість робіт. Діаграма Ганта — надає точне представлення робіт, які
виконуються одночасно. Крім того, вона дозволяє досить легко (правда, не
дуже точно) встановити завантаженість ресурсів. Разом із тим, діаграма
Ганта не пристосована до реалізації кількісного аналізу процесів. Тому
популярність, ця форма графіків набула лише після того, як була
використана в модифікованому стилі як календарний графік у мережному
плануванні.
Таким чином, календарний графік становитьмодифікований варіант
діаграми Ганта. В якості вихідних даних для його створення
використовуються:
− структура робіт проекту, яка встановлена на основі мережного
графіка;
− ресурси, які використовуються для виконання проекту і їхній

59

розподіл між роботами;
− реальні (календарні) дати, до яких відносяться моменти початку
й завершення робіт і проекту в цілому.
Варіант календарного графіка, який створено для прикладу, зв'язаного
із побудовою програмного продукту (Рис. 3.5).

Рис.3.5. Приклад календарного графіка

Критичні роботи на рисунку підкреслено подвійними штрихами. Лінії
з подвійними стрілками позначають резерви часу некритичних робіт.
Пунктирними лініями позначені зв'язки між роботами.
При дослідженні отриманого календарного графіка, як і при аналізі
мережного графіка, основна увага надається критичному шляхові. Саме
тому ресурсне планування (тобто поділ ресурсів між роботами проекту)
починають із робіт критичного шляху.
Після стартового розподілу ресурсів за допомогою календарного

60

графіка можуть вирішуватися такі види задач:
− аналіз завантаженості ресурсів;
− зміна строків початку і/або закінчення некритичних робіт із
метою більш ефективного використання ресурсів;
− планування робочого графіку виконавців;
− кошторисного аналізу проекту.

Якщо отримані результати будуть незадовільними за яким-небудь
показником, необхідно змінити календарний графік, скорегувавши терміни
виконання робіт і/або розподіл ресурсів, або просто повернутися до
мережного графіка і внести виправлення в нього.
Метод мережного планування, на відміну від сучасних математичних
методів дослідження операцій (наприклад, лінійного та динамічного
програмування) не реалізує "автоматичного" обчислення оптимальних
параметрів проекту. Він лише дає можливість одержати об'єктивну оцінку
цих параметрів при визначеному варіанті структури робіт і розподілу
ресурсів. Відповідно, отримані з його допомогою результати можливо
розглядати як рекомендації.
У методі мережного планування існує два основних типи ресурсів:
поновлювані і не поновлювані (які витрачаються). До першого типу
відносяться так звані виконавці — люди або механізми, що, виконали одну
роботу, можуть бути "встановлені" на іншу. Зрозуміло, виконавці також
мають знос, однак передбачається, що в рамках одного проекту їхня
працездатність буде незмінною. Не поновлювані ресурси - це сировина й
матеріали, а також енергоносії. Внаслідок цього облік застосованих не
поновлюваних ресурсів при реалізації проекту буде йти по наростаючій.

61

3.4. Удосконаленні математичні моделі розрахунків основних
параметрів дослідження
Розрахунок параметрів мережевої моделі
Розрахунок параметрів мережевої моделі ведеться для повних шляхів,
подій і робіт. При розрахунках визначають наступні параметри:
- А) для повних шляхів мережного графіка:
- t (Li) - тривалість будь-якого повного шляху;
- t (Lкр) - тривалість критичного шляху;
- R-(Li) - повний резерв часу шляху.
- Б) для подій:
- Ti(p), Ti(n) - ранній і пізній терміни здійснення події;
- Ri, - резерв часу події.
- В) для робіт:
- tij(рз), tij(рз) - ранній термін початку та закінчення робіт;
- tij(пп), tij(пз) - пізній термін початку та закінчення робіт;
- rij(п) , rij(B) - повний і вільний резерв часу роботи.
При розрахунку цих параметрів використовують графічний і
табличний методи.
Розрахунок тривалості повного шляху
1) Розрахунок тривалості будь-якого повного шляху здійснюється за
формулою

2) – протяжність критичного шляху (в нашому
прикладі це шлях 1).
3) Повний резерв часу шляху

Підвищення сумарної тривалості всіх робіт, що лежать на шляху , на

62

величину не збільшує час настання завершальної операції.
Розрахунок часу настання подій
Розрахунок проведемо на мережевому графіку рис. 3.6.
При графічному методі запису розрахункових параметрів здійснюється
безпосередньо на мережевому графіку.
Для чого кожен вузол мережевого графіка ділимо на чотири частини
(сектори), в цих секторах записуються такі дані:
верхній - призначений для запису номера події - i;
правий - для запису раннього терміну звершення події - Tpi;
лівий – для запису пізнього строку здійснення події - Tпi;
нижній – для запису резерву часу події - Ri.

Рис. 3.6. Мережевий графік із зазначенням часу настання подій

63

1. Найбільш ранній термін надходження i-ої події в мережі Tpi,де i =
1, 2, .. n; i - одна з подій мережі.
Tpi- мінімально необхідний час між настанням початкової і даної
події.
Для початкового події Tpi = 0 - найбільш ранній термін дорівнює 0.
При розрахунку Tpi послідовно переходять від початкового події до події,
все більш від нього віддаленого. Тоді для будь-якого іншої події у цей
показник визначається за формулою:

де T(p)i - найбільш ранній термін надходження події i, що передує
події j;
Tij- Тривалість роботи (i-j).
Для кінцевого події мережного графіка найбільш ранній термін
надходження його дорівнює тривалості критичного шляху і називається
критичним часом мережевого графіка.
2. Найбільш пізній термін настання події в мережі Tni.
Цей показник розраховується від кінця мережевого графіка до
початку, тобто в напрямку, зворотному визначенню найбільш раннього
терміну настання подій. Для кінцевого події (k) робиться припущення, що
найбільш ранній термін його настання дорівнює найбільш пізнього терміну,
тобто:

Для критичного шляху також вірно рівність:

Тоді для початкового – Tn1=0.
Для інших подій мережевого графіка Tni визначається за формулою:

64

де Tn
1 - найбільш пізній термін настання подальшого події j;
tij- тривалість роботи (i-j).
Цей показник визначає найбільш допустимий час наступлення події,
яке не потребує збільшення часу на здійснення всього комплексу робіт.
Допустимий термін настання події – Tд
i:

Дана нерівність показує, що допустимий термін настання події
повинні знаходитися в діапазоні змін від найбільш раннього терміну
настання до найбільш пізнього строку настання даної події.
Для критичних подій:

3. Резерв часу подій - .
Розрахувавши ранні та пізні терміни настання кожної події, можна
визначити резерви часу подій за формулою: .
Резерви часу всього критичних подій рівні 0: Rікр = 0.
Розрахунок часу виконання робіт
Розрахунок часу виконання робіт проводять після того, як
визначені і для всіх подій:
а) Ранній термін початку робіт ( ) дорівнює раннього терміну
наступлення події, з якої виходить дана робота, тобто:

Якщо цю оцінку виразити через характеристики робіт, то можемо
записати:

де - попередня робота;
- подальша робота.

65

Частина мережевого графіка
б) Ранній термін закінчення роботи визначається шляхом додавання
до ран-нього терміну початку роботи тривалості самої роботи:
Або .
в) Пізній термін закінчення роботи дорівнює пізнього терміну
наступлення подальшої події:
або .
г) Пізній термін початку роботи перебуває шляхом вирахування з
пізнього терміну настання подальшого події тривалості роботи, тобто:
або .
д) Повний резерв часу роботи показує час, на який можна перенести
початок даної роботи (або збільшити її протяжність), не змінюючи при
цьому довжини критичного шляху і визначається за формулами
або
Для всіх робіт, що лежать на критичному шляху
.
або .
е) Вільний резерв часу роботи - частина повного резерву часу роботи,
яка зберігається у неї за умови, що початкова подія роботи сповниться в
найпізніший термін, а кінцева - в самий ранній термін і визначається за
формулами:

66

Висновки
В даному розділі розглянуто мережеві методи планування. Визначили
переваги та недоліки цих методів та встановили, які саме є методи.
Дослідили сучасні мережеві моделі та шляхи побудови їх. Також вивчили
таку річ як критичний шлях на базі прикладів та діаграм.

67

РОЗДІЛ 4
ПРОГРАМНА РЕАЛІЗАЦІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
УПРАВЛІННЯ ІТ ПРОЕКТОМ З РОЗРАХУНКОМ КРИТИЧНОГО
ШЛЯХУ
4.1. Вибір засобів реалізації
В якості мови програмування застосовано Ruby, у цієї мови є багато
переваг над іншими мовами програмування, що дозволяє реалізувати з її
допомогою практично будь-які завдання.
Одна з основних переваг мови Ruby – незалежність від платформи, на
якій реалізуються програми: один і той же код можна компілювати під
управлінням операційних систем Windows, Linux, Machintosh та інші. Це
дійсно важливо, коли програми завантажуються через Інтернет для
подальшої роботи під управлінням різних операційних систем.
Наша система створюється в середовищі програмування RubyMine
яка є комерційним інтегрованим середовищем програмування для Ruby від
компанії JetBrains.
RubyMine – розумне і зручне інтегроване робоче середовище
розробки для мови Ruby і веб-фреймворку Rails, яка налічує в себе всі
необхідні розробнику інструменти та підтримує найбільш популярні
технології зі світу Ruby.
Як і всі IDE, створені на основі платформи IntelliJ, RubyMine володіє
унікальним механізмом аналізу коду, який покладено в основі таких
функцій, як інтелектуальне авто оновлення коду, рефакторинг, виправлення
коду на льоту і навігація по коду. Особливістю RubyMine є те, що для всіх
наведених вище функцій враховується специфіка кожного конкретного
проекту.
Ruby on Rails – це вільно поширюваний фреймворк, створений
Девідом Гайнемаєр Генссоном (англ. David Heinemeier Hansson). Він був

68

створений з метою уникнути складності розробки веб-додатків.
Ruby on Rails – об'єктно-орієнтований фреймворк для побудови веб-
застосунків, написаний на мові програмування Ruby. Ruby on Rails надає
каркас модель-вид-контролер (Model-View-Controller) для веб-застосунків, а
також реалізує їхню інтеграцію з веб-сервером і сервером бази даних.
Ruby on Rails встановлює принципи розробки застосунків:
− застосунки не повинні визначати власну архітектуру, так як вони
використовують готовий каркас модель-вид-контролер;
− мова Ruby дозволяє застосовувати нотацію, що легко читається, для
встановлення семантики веб-застосунків (таких як відносини між
таблицями в базі даних);
− Ruby on Rails має механізми повторного використання, що
реалізують мінімізацію дублювання коду у веб-застосунку (принцип Don't
Repeat Yourself – не повторюй себе).
За замовчуванням застосовуються угоди по конфігурації, типові для
більшості веб-застосунків (принцип Convention over configuration - угоди
над конфігурацією). Явна специфікація конфігурації необхідна тільки в
нестандартних випадках.
Основними компонентами додатків Ruby on Rails є модель,
представлення і контролер. Ruby on Rails використовує REST-стиль
побудови веб-додатків.
В якості системи управління базами даних ми обрали MySQL. При
роботі нашого web-додатку для роботи з базою даних MySQL ми
застосовуємо ORM Active Record.
Active Record - засіб відображення між об'єктами та реляційними
структурами (object-relational mapping, ORM) для платформи Ruby on Rails.
Active Record є частиною фреймворку Ruby on Rails [ 1 ]. Active Record
надає простий для використання каркаc для відображення між об'єктно-
орієнтованою моделлю даних і традиційною реляційною базою даних.

69

Метою Active Record є звільнення розробника від об’ємних типових
завдань із програмування взаємодії з базою даних. Active Record може
застосовуватись як при розробці з нуля, так і для вже створеної бази даних.

4.2 Створення схеми відношень
Спроектована база даних, що складається з 6 пов’язаних між собою
таблиць, які розроблено для збереження даних системи, представлена на
рисунку 4.1.

Рис. 4.1. Модель бази даних
Детально опишемо структуру таблиць і структуру таблиць дані яких
часто модифікуються під час роботи системи.
Таблиця Users (користувачі) містить в собі адресу поштової скриньки
користувача та пароль, а також дані відвідування користувачем сайту.
Структура таблиці бази даних наведена в таблиці 4.1.

70

Таблиця 4.1
Структура таблиці Users (користувачі)
№ Опис
Назва поля Тип поля Ключ
п/п
1 Id Int PK Ідентифікатор
2 role_id Int FK Роль
3 Email Varchar - Адреса поштової скриньки
4 encrypted_password Varchar - Зашифрований пароль
5 reset_password_token Varchar - Ключ скидання паролю
Відправлений ключ
6 reset_password_sent_at Datetime -
скидання паролю
7 remember_created_at Datetime - Дата створення
8 sign_in_count Int - Кількість входів
9 current_sign_in_ip Varchar - Поточний IP входу
10 last_sign_in_at Datetime - Час останнього входу
11 confirmation_token Varchar - Ключ підтвердження
12 confirmed_at Datetime - Час підтвердження
13 confirmation_sent_at Datetime - Відправлення підтвердження
Непідтверджено по
14 unconfirmed_email Varchar -
електронній пошті
15 created_at Datetime - Час створення
16 updated_at Datetime - Час оновлення
Таблиця Profiles (профайли) призначена для зберігання інформації
про користувача.

71

Таблиця 4.2
Структура таблиці Profiles (профайли)
№ п/п Назва поля Тип поля Ключ Опис
1 Id Int PK Ідентифікатор
2 user_id Int FK id користувача
3 first_name Varchar - Ім´я користувача
4 last_name Varchar - Прізвище користувача
5 Gender Varchar - Стать
6 created_at Datetime - Час створення
7 updated_at Datetime - Час оновлення

Таблиця Roles (ролі) містить в собі інформацію про ролі користувача.
Таблиця 4.3
Структура таблиці Roles (ролі)
№ п/п Назва поля Тип поля Ключ Опис
1 id Int PK Ідентифікатор
2 name Varchar - Назва ролі
3 created_at Datetime - Час створення
4 updated_at Datetime - Час оновлення
Таблиця Comments (коментарі) зберігає в собі коментарі до задач.
Також зберігає дані про користувача який створив коментар.

72

Таблиця 4.4
Структура таблиці Comments (коментарі)
№ п/п Назва поля Тип поля Ключ Опис
1 id Int PK Ідентифікатор
2 text Varchar - Текст коментаря
3 user_id Int FK Id користувача
4 task_id Int FK Id задачі
5 created_at Datetime - Час створення
6 updated_at Datetime - Час оновлення
Таблиця Projects (проекти), містить в собі інформацію про проекти.
Таблиця 4.5
Структура таблиці Projects (проекти)
№ п/п Назва поля Тип поля Ключ Опис
1 id Int PK Ідентифікатор
2 user_id Int FK Id користувача
3 name Varchar - Назва проекту
4 description Varchar - Опис проекту
5 created_at Datetime - Час створення
6 updated_at Datetime - Час оновлення
Таблиця Tasks (задачі), містить в собі інформацію про задачі.

73

Таблиця 4.6
Структура таблиці Tasks (задачі)
№ п/п Назва поля Тип поля Ключ Опис
1 Id Int PK Ідентифікатор
2 user_id Int FK Id користувача
3 Name Varchar - Назва проекту
4 Description Varchar - Опис проекту
5 created_at Datetime - Час створення
6 updated_at Datetime - Час оновлення
7 project_id Int FK Id проекту
8 Status Varchar - Статус
9 Hours Int - Години
10 started_at Datetime - Час початку

4.3. Структура системи
Веб-додаток розроблений на основі фреймворку Ruby on Rails, який
в своїй основі лежить архітектурний стиль MVC (Model View Control).
Вибраний фреймворк задає стиль побудови додатку у вигляді
багатошарової архітектури , від шару відповідального за доступ до бази
даних до шару представлення (інтерфейсу користувача). Структура проекту
(рисунок 4.2) в середовищі розробки Jetbrains Rubymine поділено на три
основні частини, перша - сама наша програма розташована в директорії
app, друга - конфігураційні файли розмішені в config, і третя - файли що

74

відповідають за зв'язок з базою даних розміщені в директорії db.

Рис. 4.2. Структура проекту
Програма розташована в 6 директоріях:
− assets – файли стилів, картинки та джава-скрипти;
− controllers – класи контролерів програми;
− helpers – модулі хелперів;
− mailers – файли електронної пошти;
− models – класи що містять сутності таблиць бази даних;
− views – файли сторінок програми.
Всі конфігураційні ресурси та файли розміщено в директорії config:
1) файли конфігурацій середовища в директорії enviroments;
2) файли ініціації в директорії initializers;
3) файли локалізації в директорії locales;
4) файл конфігурації application.rb;
5) файл запуску гемів boot.rb;
6) файл конфігурації бази даних database.yml;
7) файл ініціалізації environment.rb;

75

8) файл генерації маршрутів routes.rb;
9) ключі до бази даних secrets.yml.
Файли що відповідають за зв'язок з базою даних розміщені в
директорії_db:
1) файли міграцій в директорії migrate;
2) файл схеми бази даних schema.rb;
3) файл з початковими даними seeds.rb.
Як було сказано розроблений додаток побудовано на архітектурному
стилі Model-View-Control (рисунок 4.3). Модулі нашого додатку можна
поділити на 3 головні частини [ 1 ]:
− представлення, для взаємодії користувача з нашим додатком;
− контролер, служить для обробки подій які виникають від взаємодії
користувача з представленням;
− модель, призначена за збереження, вибірки, зберігання даних
додатку.

Рис. 4.3. Архітектура системи

76

Розглянемо роботу системи на даній архітектурі. Користувачу
додатку надається web-сторінка (view), на якій розташовані елементи
керування, з якими взаємодіє користувач. При взаємодії з представлення
формуютьсяч запити на головний контролер.
Контролер ідентифікує тип запиту, виконує задану обробку даних
звертаючись до відповідних сутностей (entity). Сутності (entity) звертаються
до бази даних і реалізують об’єктно-реляційні перетворення (перетворює
записи таблиць БД в об’єкти програми і навпаки). Після виконання заданих
перетворень, результати повертаються назад контролеру. Контролер
отримавши результати обробки будує представлення і повертає її
користувачу. Такий цикл обробки даних існує при кожному запиті від
користувача на сервер.

4.4. Логіка роботи системи
Для початку роботи з системою користувачу необхідно пройти
авторизацію. Після успішної авторизації користувачу, в залежності від його
ролі, представляються функції по організації робочого процесу такі як,
робота з проектами та задачами. У кожного користувача є особистий про
файл з інформацією про нього.
В системі користувач може володіти однією з трьох ролей: простий
користувач, модератор та адміністратор.
Простий користувач – це права для рядового співробітника. Його
основна місія – це робити завдання, які йому представить модератор. Він
може робити як на одному проекту, так і на декількох.
Модератор – це роль для керівника команди співробітників. Його
основна задача це побудова завдань для співробітників. Він може робити як
на одному проекту, так і на декількох.
Адміністратор – це роль для менеджера. Його основна задача це
моніторинг роботи на проектах. Він створює модераторів.

77

Висновки
Описана структура бази даних програмного забезпечення управління
ІТ проектом з визначенням критичного шляху. Побудовано модуль
розрахунку критичного шляху для ІТ проектів.

78

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

79

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Advatages of Java at ibm.com. [Електронний ресурс].– Режим
доступу:
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/performance/adv
antages_java.html
2. CSS Flexible Box LАyout Module [Electronic resource] //
Офіцйний сайт W3C. – Mode of Аccess: https://www.w3.org/TR/css-flexbox-1/
(viewed on 05.12.2019).
3. Dixit S. Аn introduction to the Web Bluetooth АPI [Electronic
resource] // Dev.operА: OperА SoftwАre АSА. – Mode of Аccess:
https://dev.operА.com/Аrticles/web-bluetooth-intro/ (viewed on 15.10. 2019).
4. Djiraj. JWT Role Based Authorization with Spring Security.
[Електронний ресурс].– Режим доступу: https://www.devglan.com/spring-
security/jwt-role-based-authorization
5. It project management software with critical path
calculation/ Chychuzhko M.V., Leshchenko R.S., Biletskyi O.I.// «Проблеми
інформатизації» : Тези доповідей десятої міжнародної науково-технічної
конференції 24 – 25 листопада 2022 року, том 2. – Черкаси – Харків - Баку –
Бельсько-Бяла (Польша) –– С. 13.
6. Golovko O. V. FormulАtion of the Problem of MАximum Clique
DeterminАtion in Non-Oriented GrАphs. InternАtionАl JournАl of Engineering
& Technology. Vol. 7, no. 4.3 (2018): SpeciАl Issue 3. P. 293–297.
7. Introduction to Web Technologies for FrontPАge Users [Electronic
resource] // Офіційний ресурс MSDN. – Mode of Аccess: https
https://msdn.microsoft.com/en-us/librАry/office/АА218647(v=office.11).Аspx
(viewed on 10.11. 2019).
8. JАckson B. 100+ Аwesome Development Tools Аnd Resources /
BriАn JАckson // Офіційний сайт keycdn [Electronic resource]. – Mode of

80

Аccess: https://www.keycdn.com/blog/web-development-tools/ (viewed on
07.11.2019).
9. JАvАScript-тренды, на которые стоит обратить внимание в
2019-м // Блог компании RUVDS.com / Офіційний сайт hАbrАhАbr
[Електронний ресурс]. — Режим доступу:
https://hАbrАhАbr.ru/compАny/ruvds/blog/319162/ (дата звернення
15.10.2019).
10. Listrovoy S. V. Development of method of definition mАximum
clique in А nonoriented grАph. EАsternEuropeАn JournАl of Enterprise
Technologies. 2018. Vol. 5, № 4 (89). – P. 12–17. EID: 2-s2.0-85032585697.
11. Michael Hartl. Ruby on Rails Tutorial (Addison-Wesley
Professional Ruby Series) 6th Edition. - Amazon.com Services LLC, 2018. – 208
с.
12. MVC Design Pattern – JournalDev. [Електронний ресурс].–
Режим доступу: https://www.journaldev.com/16974/mvc-design-pattern
13. MVC Pattern -Anshul vyas - Medium. [Електронний ресурс].–
Режим доступу: https://medium.com/@anshul.vyas380/mvc-pattern-
3b5366e60ce4
14. MVC для початківців та інтернету [Електронний ресурс]. -
Режим доступа: http://chtivo.webhost.ru/articles/mvc.php.
15. MАnifesto for Аgile SoftwАre Development [Электронный
ресурс] // Веб-портал АgilemАnifesto.org. – Режим доступу:
http://www.АgilemАnifesto.org/
16. PostgreSQL : About. [Електронний ресурс].– Режим доступу:
https://www.postgresql.org/about/
17. Programming Ruby 1.9 (3rd edition): The Pragmatic Programmers'
Guide, Dave Thomas, Chad Fowler, Andy Hunt, 2019

81

18. Scrum | Digital Humanities LAB at CVCE powered by uni.lu.
[Електронний ресурс].– Режим доступу:
https://cvcedhlab.hypotheses.org/tag/scrum
19. Spring | Home. [Електронний ресурс].– Режим доступу:
https://spring.io/
20. Timothy M. O'Brien "Jakarta Commons Cookbook". O'Reilly; ISBN
0-596-00706-X
21. Topical Guide | Spring Security Architecture. [Електронний
ресурс].– Режим доступу: https://spring.io/guides/topicals/spring-security-
architecture
22. Website security – Learn web development | MDN. [Електронний
ресурс].– Режим доступу: https://developer.mozilla.org/en-
US/docs/Learn/Server-side/First_steps/Website_security
23. What is REST – Learn to create timeless REST APIs. [Електронний
ресурс].– Режим доступу: https://restfulapi.net/
24. Бегг К. Бази даних. Проектування, реалізація і супровід. Теорія
та практика / К. Бегг, Т. Конноллі. – 2003. – 1238 с.
25. Берюх И. С. Вибір технології розробки програмного забезпечення
інформаційних систем. ScienceRise. Харкsв, 2018. № 5/2. С. 40–43
26. Брюс У. Javaсервлети і JSP. Збірник рецептів. [Текст] / У. Брюс.
— Львів, Захід-Прес, 2009 — 768 с.
27. Васильєв Н. Об'єктно-орієнтоване програмування. [Текст] / Н.
Васильєв. — К. Львів: «Афіша», 2011 — 400 с.
28. Вендров А. М. Сучасні технології створення програмного
забезпечення [Електронний ресурс] / А. М. Вендров // Портал
“CITFORUM”. – Режим доступа: http://citforum.ru/progrАmming/
АpplicАtion/progrАm/index.shtml#v

82

29. Вольфсон Б. Гнучкі методології розробки [Електронний ресурс] / Б.
Вольфсон // Електронна бібліотека Аdm-lib.ru. – Режим доступа:
http://Аdm-lib.ru/books/10/Gibkie-metodologii.pdf
30. Інтернет-бізнес в Україні [Електронний ресурс] // Український
інтернет-журнал АIN.UА – Режим доступу: http://Аin.uА/5-trendov-
progrАmmirovАniyА-kotorye-izmenyАt-industriyu (дата звернення
13.11.2019).
31. Інженерія якості програмного забезпечення: навч. посібник /
Г.В Табунщик, Р.К. Кудерметов, Т.І. Брагіна. - Запоріжжя: ЗНТУ, 2013. -
180 с.
32. Кеннеді Б. Вивчаємо HTML / Б. Кеннеді, Ч. Маскиано. – 2018. –
272 с.
33. Концепція розвитку цифрової економіки та суспільства України
на 2018-2020 роки: Розпорядженням Кабінету Міністрів України від 17
січня 2018 р. № 67-р. URL : https://zakon.rada.gov.ua/laws/show/67-2018-
%D1%80. (дата звернення: 17.10.20).
34. Лоусон Б. HTML і XHTML. Детальне керівництво / Б. Лоусон,
Р. Шарп. – 2000. – 752 с.
35. МатовО.Я., ХрамоваІ.О. Сучасні технології інтеграції
інформаційних ресурсів. Реєстрація, зберігання і обробка даних. 2009, Т.
11, № 1. С.33-42.
36. Офіційний сайт MySQL [Електронний ресурс]. - Режим
доступа: http://dev.mysql.com/
37. Панченко С. В. Математичне моделювання в розподілених
інформаційних системах: Монографія. Харків: ФОП Бровін О. В., 2017. –
220с.
38. Політек-софт – Пакет програм "ПС-Адміністратор".
[Електронний ресурс].– Режим доступу: http://www.politek-
soft.kiev.ua/index.php?do=products&product=ps-administrator

83

39. Пурьев М. Тренди програмування в 2019 році // Офіційний сайт
GeekBrАins [Електронний ресурс] – Режим доступу:
https://geekbrАins.ru/posts/2018_techcrunch_trends (дата звернення
05.11.2019).
40. Сайт СКБД http://postgresql.ru.net/
41. СОУ-Н ДКА 0061:2012. Настанова Державного космічного
агентства України. Галузева система управління якістю. Процеси
життєвого циклу програмного забезпечення програмно-технічних
комплексів критичного призначення. – К.: ДКА України, 2012. – 111 с.
42. Тенденции развития веб-технологий в 2020 году [Електронний
ресурс] // Офіційний сайт компанії SITE ELITE. – Режим доступу: http://st-
lt.ru/blog/useful/tendenczii-rАzvitiyА-veb-texnologij-v-2020-godu.html (дата
звернення 13.10.2019).
43. Технології створення програмних продуктів та інформаційних
систем : навч. посібник / М. Ю. Карпенко, Н. О. Манакова, І. О. Гавриленко
; Харків. нац. ун-т міськ. госп-ва ім. О. М. Бекетова. - Харків : ХНУМГ ім.
О. М.Бекетова, 2017. - 93 с.
44. Томсон Л. Разробка web додатків на РНР и MySQL. – 2 е вид., –
Львів.: Полюс, 2003. – 672 с
45. Тренди та події у світі веб-технологій у 2019 році [Електронний
ресурс] // Блог компании HTML АcАdemy / Офіційний сайт hАbrАhАbr. –
Режим доступу: https://hАbrАhАbr.ru/compАny/htmlАcАdemy/blog/317558/
(дата звернення 14.09.2019).
46. Фернандес О. Шлях Rails. Докладне керівництво по створенню
додатків в середовищі Ruby on Rails. — К.: Символ-Плюс, 2008. — 224 с.
47. Хаф Л. Методологии разработки ПО. Часть 5. Microsoft
Solutions FrАmework [Электронный ресурс] / Л. Хаф. // Компьютер Пресс. –
№ 7. – 2004. – Режим доступа: www.compress.ru/Аrchive/CP/2004/7/29/

84

48. Шевчук І. Б. Інформаційні технології в регіональній економіці:
теорія і практика впровадження та використання : монографія. Львів :
Видавництво ННВК "АТБ", 2018. 448 с.
49. Шпион А. Web технології развиваются клиєнтами [Електронний
ресурс] // Офіційний сайт АRT Lemon. – Режим доступу: https://Аrt-
lemon.com/web-tech (дата звернення 05.10.2019).

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