МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ ХАРЧОВИХ ТЕХНОЛОГІЙ

Інститут (факультет ) АКС

Кафедра Інформаційних систем

«До захисту в ЕК» «До захисту допущено»

Директор інституту(декан факультету) Завідувач кафедри

______ Форсюк А. В. ______ Чумаченко С. М.
(підпис) (прізвище та ініціали) (підпис) (прізвище та
ініціали)
«___» _______________ 20__ р. «___» _______________ 20__ р.

Дипломна робота
на здобуття освітнього ступеня магістра
з спеціальності: 122 “Комп’ютерні науки та інформаційні технології” ___
(шифр та назва спеціальності)

на тему: “Дослідження та порівняння методологій проектування на

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

Виконав: студент 6 курсу, групи ІС 2-4М Мізін Р.Е.

(прізвище та ініціали)

Керівник доц. М’якшило О.М. ___________

(прізвище та ініціали) (підпис)

Рецензент Антонюженко А.К. ___________

(прізвище та ініціали) (підпис)

Засвідчую, що в цій
дипломній
роботі немає запозичень із
праць
інших авторів без відповідних
посилань.
Студент_____________
(підпис)
 Київ – 2019 р.
Факультет Автоматизації і комп’ютерних систем
(назва факультету)

Кафедра Інформацій них систем

(назва кафедри)

Спеціальність 122 Комп’ютерні науки та інформацій ні технології (спеціалізація

Інформацій ні управляючі системи та технології):
(шифр та назва спеціальності)

ЗАТВЕРДЖУЮ
Завідувач кафедри (Чумаченко С.М.)
« 10 » листопада 2018 р.
ЗАВДАННЯ
на магістерську роботу
Mізін Роман Едуардович
(прізвище, ім’я, по батькові)

Тема роботи Дослідження та порівняння методологій проектування на прикладі

створення мобільного додатку для поліграфічного підприємства
затверджено наказом по університету від «07» листопада 2018 р. №1150-кс
Термін здачі магістрантом закінченої роботи:
Вихідні дані до роботи: 1) Загальна інформація про метолології розробки які
присутні на ринку та детальний розбір waterfall та scrum
2) Результати дослідницької роботи
Зміст магістерської роботи: 1) Вступ
2) Огляд та дослідження особливостей методологій розробки ПО
3) Детальне досліження методологій розробки Waterfall та Scrum
4) Процес розробки проекту “Мобільний додаток для формування замовлень
поліграфічної продукції” організації ПП “Авалон-прінт”
5) Висновки

2
 КАЛЕНДАРНИЙ ПЛАН
виконання магістерської роботи
№ Термін
Етап
п\п виконання

Дослідження методологій розробки програмного 21 жовтня – 15

1
забезпечення які є на ринку. листопада

Проведення порівняльної характеристики обраних 16 листопада –

2
методологій розробки. 15 грудня

Розробка критеріїв вибору для методологій розробки для

3 16 – 29 грудня
конкретного проекту та компанії.

Реалізація способу вибору оптимальної методології 30 грудня –

4
розробки програмного забезпечення. 9 січня

Дослідження результативності розробленого способу вибору

10 січня –
5 оптимальнох методології розробки програмного
07 лютого
забезпечення.

08 лютого – 10
6 Оформлення роботи
лютого
8 лютого – 10
7 Розробка презентації
лютого

Завдання прийняв до виконання Мізін Р.Е.

(підпис) (прізвище, ініціали)
Науковий керівник роботи М'якшило О. М.
(підпис) (прізвище, ініціали)

« 10 » листопада 2018 р.

3
 ЗМІСТ
ВСТУП.................................................................................................................6
РОЗДІЛ 1. Огляд та дослідження методологій розробки програмного
забезпечення........................................................................................................9
1.1 Особливості методологій розробки програмного забезпечення..............9
1.2. Каскадна методологія розробки ПЗ..........................................................10
1.3. Інкрементна методологія розробки ПЗ....................................................12
1.4. Ітеративна методологія розробки ПЗ.......................................................13
1.5. Спіральна методологія розробки ПЗ........................................................14
1.6. Гнучкі методології розробки ПЗ...............................................................16
1.7. Scrum як один з різновидів Agile методологій........................................17
1.8. ПОСТАНОВА ЗАДАЧІ.............................................................................20
1.9. ВИСНОВКИ ДО РОЗДІЛУ 1....................................................................21
РОЗДІЛ 2. Детальне дослідження методологій розробки Waterfall та Scrum
.............................................................................................................................23
2.1. Обгрунтування вибору Waterfall та Scrum...............................................23
2.2. Гнучкі методології розробки та їх види...................................................24
2.3. SCRUM........................................................................................................29
2.3.1. Розстановка пріоритетів.........................................................................32
2.3.2. Елементи SCRUM...................................................................................32
2.3.2.1. Складання backlog проекту.................................................................32
2.3.2.2. Робочі спринти.....................................................................................33
2.3.2.3. Щоденні наради....................................................................................33
2.3.2.4. Власник продукту.................................................................................34
2.3.2.5. Контроль замовником всіх етапів роботи..........................................34
2.3.2.6. Надання звітів в кінці кожного спринту............................................35
2.3.3. Мінімізація ризиків в скрам...................................................................35
2.3.4. Переваги SCRUM для замовника..........................................................36
2.3.4.1. «Нульовий» спринт..............................................................................36
2.3.4.2. Оплата фактично витраченого часу фахівця.....................................36
2.3.4.3. «Безболісні» зміни проекту.................................................................36
2.3.4.4. Повний контроль команди...................................................................37
4
2.4. WATERFALL..............................................................................................37
2.4.1. Переваги Waterfall...................................................................................39
2.4.2. Недоліки каскадної моделі.....................................................................40
2.4.3. Етапи каскадної моделі...........................................................................43
2.4.4. Область застосування каскадної моделі................................................44
2.4.5. Застосування каскадної моделі в роботі...............................................45
2.5. Формування критеріїв оптимальності вибору методології розробки...46
2.6. Порівняння..................................................................................................47
2.6.1. Порівняльна таблиця...............................................................................48
2.7. Характеристика проектів для вибору методології розробки
програмного забезпечення підприємства Avalon - Print................................51
2.7.1. Методологія Scrum..................................................................................56
2.7.2. Каскадна модель розробки ПЗ...............................................................57
2.7.3. Вибір правильної методології розбобки для проекту «Мобільний
додаток для формування замовлень поліграфічної продукції» організації
ПП «Авалон-прінт”...........................................................................................59
2.8. ВИСНОВКИ ДО РОЗДІЛУ 2....................................................................60
РОЗДІЛ 3. Процес розробки проекту «Мобільний додаток для формування
замовлень поліграфічної продукції» організації ПП «Авалон-прінт” в
рамках методології розробки ПЗ Scrum..........................................................62
3.1. Створення Беклогу продукту....................................................................62
3.2. Створення першого спрінту......................................................................62
3.3. Виконання першого спринту.....................................................................63
3.4. Створення другого спринту......................................................................64
3.5. Виконання другого спринту......................................................................65
3.6. Результат 4-х тижнів спринту (Готова перша версія додатку)..............66
3.7. Подальші дії................................................................................................71
3.8. Розрахунок техніко-економічного ефекту для проекту виконаного з
використанням методології SCRUM..............................................................71
ВИСНОВКИ ДО РОЗДІЛУ 3...........................................................................79
ВИСНОВКИ ДО РОБОТИ...............................................................................81
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ.........................................................83

5
 ВСТУП

Актуальність теми У багатьох компаніях, які займаються

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

6
 Предметом дослідження є порівняльний аналіз методологій
розробки та визначення оптимальної для конкретного проекту.
Об'єктом дослідження Методології розробки програмного
забезпечення Scrum та Waterfall.
Зв’язок роботи з науковими програмами, планами, темами.
Робота виконана у відповідності з тематикою кафедри інформаційних
систем: Дослідження та впровадження інформаційних технологій у галузях
харчової промисловості та освіті, № держреєстрації 0117U003475
Метою роботи є здійснення дослідження та розроблення наглядного
методу вибору методології розробки на прикладі конкретного проекту.
Виходячи з мети, були визначені наступні завдання дослідження:
1. Дослідити теоретичні засади методологій розробки Scrum та
Waterfall.
2. Дослідити основні аспекти використання Scrum і Waterfall,
визначити критерії їх порівняння та методи оцінювання ефективності
використання досліджуваних методологій розробки.
3. Ознайомитися з особливостями використання гнучкої
методології Scrum.
4. Ознайомитися з особливостями використання ієрархічної
методології Waterfall.
5. Визначити критерії для порівняння та визначення придатності
конкретної методології для виконання конкретного проекту з урахуванням
компанії замовника.
6. Визначити оптимальну методологію для конкретного проекту
«Мобільний додаток для формування замовлень поліграфічної продукції»
організації ПП «Авалон-прінт”.
7. На основі проведених досліджень сформулювати пропозиції,
щодо використання тієї, чи іншої методологій розробки.

7
 Методи дослідження та розробки: метод радіальних діаграм,
методологія SCRUM, методологія waterfall, елементи економічної теорії
оцінки проектів, мова програмування Swift, система контролю версій GIT,
система управління задачами JIRA.
Наукова новизна одержаних результатів.
 Досліджено популярні методології розробки ІТ-проектів на ринку,
визначено їх переваги та недоліки, сформовано критерії оцінки для їх
порівняння і проведено порівняння методологій за визначеними
критеріями
 Розроблено наглядний та чіткий графічний метод визначення
оптимальної методології розробки програмного забезпечення для IT-
проекту.
 Ефективність розробленого методу показано на реальних замовленнях,
з урахуванням вимог замовника.
Наукове значення роботи: Зроблено внесок у теорію управління ІТ-
проектами.
Практичне значення отриманих результатів.
Розроблений метод має значне практичне значення, так як дозволяє
чітко та наглядно визначити оптимальну методолгію розробки
програмного забезпечення для проекту, а також завдяки її наглядності,
дозволяє більш легко переконувати клієнтів в необхідності
використовувати ту чи іншу методологію.
Апробація результатів магістерської роботи. Основні положення та
результати наукової роботи доповідались на Міжнародній науково-
практичній конференції «Сучасні тенденції розвитку інформаційних
систем і телекомунікаційних технологій».
Структура та обсяг роботи. Магістерська робота складається зі
вступу, трьох розділів, висновків, списку використаних джерел із 33
найменувань. Загальний обсяг магістерської роботи складає 85 сторінок,
робота містить 33 рисунка, 7 таблиць.

8
 РОЗДІЛ 1. Огляд та дослідження методологій розробки програмного
забезпечення

1.1 Особливості методологій розробки програмного забезпечення

Щоб зрозуміти, що таке методологія розробки програмного

забезпечення (далі ПЗ), потрібно сформулювати цілі, без яких неможливе
створення IT продукту. [1] Головним завданням будь-якого успішного
проекту є умова того, щоб на момент запуску системи і протягом усього
терміну життєвого циклу можна було забезпечити:
● необхідну функціональність системи і адаптацію до зміни вимог щодо її
функціональності;
● прийнятний час відгуку і реакції системи на запит;
● необхідну пропускну здатність ПЗ;
● простоту і зручність експлуатації системи;
● можливість підтримки системи;
● відмовостійкість системи в режимі експлуатації;
● необхідну безпеку.
Продуктивність системи - головний фактор, який визначає
ефективність ПЗ [2]. Добре й продумане проектне рішення є основою
високонавантаженої і високопродуктивної системи.
Проектування інформаційних систем включає в себе три основні області:
● проектування структур даних і баз даних;
● проектування безпосередньо програм, різних елементів графічного
інтерфейсу, звітів, які будуть забезпечувати доступ до даних;
● облік технологій і середовища: топології мережі, використання різних
архітектур, конфігурації апаратних засобів, паралельної обробки даних або
розподіленої обробки даних.
В реальних умовах комерційної розробки ПЗ проектування
інформаційних систем є пошуком кращого способу забезпечення
9
необхідних функціональних вимог до системи з урахуванням обмежень,
які були задані замовником.
Методологія розробки ПЗ - це набір методів і правил, які
використовуються для постановки завдання, планування, реалізації IT
продукту [3]. Сам процес розробки описується моделлю, яка визначає
послідовність етапів розробки і одержуваних результатів.
Протягом довгого часу процес розробки ПЗ здійснювався відповідно
до методик, розроблених в інженерній галузі, тобто, це стандартизована
практика поетапного створення IT продукту. Процес починався з
складання формальних специфікацій і закінчувався поставкою товару
замовнику. Існують стандарти, що описують даний процес: ГОСТ в Росії і
ISO в Європі, CMM (Capability Maturity Model - поширений в США), які
регламентують цей процес. ДСТУ в Україні.
При розробці програмного продукту використовується велика
кількість методологій розробки ПЗ, інакше кажучи, усталених підходів і
наборів правил. Вибір залежить від специфіки конкретного проекту,
бюджету, часових рамок, суб'єктивних переваг і навіть темпераменту і
настрою керівника. Далі буде дано опис найбільш використовуваних
методологій розробки в даний час.

1.2. Каскадна методологія розробки ПЗ

Однією з найпопулярніших методологій розробки ПЗ є каскадна

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

10
 Рис.1. стадії розробки ПЗ

Якщо слідувати каскадній моделі, то розробник повинен переходити

від однієї стадії до іншої в строго певному порядку. Спочатку повністю
завершується етап «проектування», в результаті чого виходить список
вимог до продукту, планування бюджету, часу, технічних деталей. Після
того як вимоги визначені, відбувається перехід до дизайну, в ході якого
створюються документи з описом архітектури додатку, описуються
елементи графічного інтерфейсу[4]. Після цього програмісти приступають
до реалізації проекту. На наступній стадії процесу проводиться тестування
і налагодження створеного продукту; на цій стадії усуваються всі помилки
і недоліки, що з'явилися на попередній стадії розробки. Після цього ПО
впроваджується і здійснюється його підтримка. Це може бути, як внесення
нової функціональності, так і усунення помилок.
При використанні моделі Waterfall легко керувати проектом. Завдяки
її жорсткості і неможливості відхилень від заздалегідь визначених рамок,
розробка ПО проходить швидко, а вартість і терміни заздалегідь визначені.

11
 Але це є, як і перевагою, так одночасно і недоліком. Каскадна модель дає
відмінний результат тільки в проектах із заздалегідь визначеними
вимогами і способами їх реалізації [5]. Немає можливості повернутися і
щось поміняти в вимогах, навіть, якщо дуже потрібно. Тестування
продукції починається тільки після того, як розробка повністю завершена
або майже завершена. Ті продукти, які були розроблені за цією моделлю
без обґрунтованого її вибору, можуть мати недоліки, так як список вимог
не можна скорегувати після розробки, про які стає відомо лише в кінці, або
на стадії розробки або тестування через сувору послідовності дій. Так як
вимоги визначаються на початку, то на етапі розробки або ще пізніше їх
змінити дуже проблематично. Вартість внесення змін дуже висока, так як
для цього потрібно чекати завершення проекту і починати все заново. Але
тим не менш, фіксована заздалегідь певна вартість часто переважає мінуси
підходу. Звичайно, виправлення недоліків, які були виявлені пізніше,
можливо, тільки це вимагає підписання додаткових угод до контракту, що
може бути вельми проблематично.
Каскадну методологію краще використовувати:
● тільки тоді, коли всі вимоги до системи відомі, зрозумілі і зафіксовані, а
суперечливих вимог немає;
● Немає проблем з доступністю програмістів потрібної кваліфікації.

1.3. Інкрементна методологія розробки ПЗ

Інкрементна методологія розробки - це методологія розробки

програмного забезпечення, де продукт розробляється, впроваджується і
тестується поступово (кожен раз додається деяка частина функціоналу),
поки продукт не буде повністю закінчено. Інкрементна методологія
включає в себе як розробку, так і обслуговування. Продукт визначається як
готовий, коли він задовольняє всім вимогам. Ця методологія поєднує в собі
елементи моделі водоспаду в циклі [6].
У інкрементній методології управління повні вимоги до системи діляться
на різні збірки, системні пакети. Є кілька циклів розробки, а цикл, в свою
12
 чергу, розділений на більш дрібні і легко створювані частини функціоналу.
Кожна частина проходить через фази визначення системних вимог,
проектування, написання коду, тестування і впровадження. Про
цес розробки за інкрементною методологією передбачає випуск на
найпершому великому етапі продукту в базовій обмеженій
функціональності, а потім вже поступове додавання нових функцій.
Процес триває до тих пір, поки не буде створена повна система. На рис. 2 -
використання инкрементной методології розробки ПО.

Рис. 2. Схема розробки ПЗ системи за інкрементною методологією

● Коли основні вимоги до системи визначені і зрозумілі, але деякі деталі

можуть розроблятися пізніше;
● Є кілька ризикових функціональних вимог.

1.4. Ітеративна методологія розробки ПЗ

Ітеративна методологія подібна до раніше розглянутої інкрементної

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

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

Рис. 3. Порівняння інкриментної та ітеративної методологій

розробки ПЗ

Найкраще використовувати інкрементну методологію:

● якщо проект великий або дуже великий;
● вимоги до кінцевої фінальної системи заздалегідь визначені, погоджені і
зрозумілі;
● основне завдання продукту визначене, проте конкретні деталі реалізації
можуть змінюватися протягом часу.

1.5. Спіральна методологія розробки ПЗ

Спіральна методологія схожа на попередню інкрементну, але з

великим акцентом на аналіз ризиків. Вона добре підходить для вирішення
дуже важливих задач, наприклад, якщо невдача несумісна з подальшою

14
діяльністю компанії.
Кожен виток спіралі [7] (Рис. 4. - Спіральна методологія) відповідає
створенню якогось обмеженого фрагмента або версії ПЗ, на ньому
уточнюються цілі і різні характеристики проекту, плануються роботи
наступного за ним витка спіралі і визначається якість продукту. Таким
чином деталізується проект і в кінцевому рахунку вибирається
обгрунтоване рішення, яке і доводиться до реалізації.

Рис. 4. Спіральна методологія

Головне завдання, яке ставиться в спіральної методології - це

якомога швидше показати користувачам і замовникам системи
працездатний продукт, нехай навіть першу «сиру» версію, тим самим
починаючи процес уточнення і доповнення всіх вимог. [8] Основною
проблемою спірального циклу є визначення моменту переходу на
наступний етап спіралі. Для цього необхідно ввести часові обмеження на
кожен з етапів спіралі або життєвого циклу. Перехід здійснюється
відповідно до плану, навіть якщо ще не вся намічена робота закінчена [9].
План складається на основі статистичних даних, які були отримані в
попередніх проектах, і особистого досвіду розробників.
Ця модель не підійде для малих проектів, має сенс її
15
використовувати, якщо проект дорогий і великий, припустимо, таких, як
розробка ПЗ документообігу для великого банку, коли кожен наступний
крок вимагає ще більшого аналізу для оцінки наслідків, ніж
програмування.

1.6. Гнучкі методології розробки ПЗ

Гнучка методологія розробки [10] - це серія підходів і технік до

розробки ПЗ, які орієнтовані на використання динамічного формування
вимог, ітеративну розробку і забезпечення їх реалізації в результаті тісного
спілкування і взаємодії членів однієї команди, які є професіоналами різних
напрямків. Існує багато різних методологій, які є гнучкими, зокрема Scrum,
Kanban FDD, XP, DSDM і інші.
При використанні гнучкої методології розробки ПЗ після кожної ітерації
(Рис. 5.), замовник (власник товару) може бачити результат роботи і
розуміти, приймає він його чи ні. Це найважливіша перевага гнучкої
методології. А до її недоліків можна віднести те, що через відсутність
чітко описаних формулювань результатів складно оцінити спочатку
людські ресурси, трудовитрати і вартість, необхідні на розробку ПЗ.
Kanban і Scrum є одними з найбільш відомих застосувань гнучкої
методології розробки ПО на практиці.
Дана методологія розробки ПЗ підходить для тривалих і великих
проектів, постійно адаптуються до потреб ринку. Відповідно, в процесі
реалізації продукту ПЗ вимоги постійно змінюються. Також методологія
підходить для класу творчих людей, які генерують, видають і пробують
нові ідеї і думки щодня або навіть щогодини. Внутрішні стартапи краще
розробляти, використовуючи гнучкі методології розробки ПЗ.

16
 Рис. 5. Спринт
Основною метрикою і результатом гнучких методологій є робочий
продукт. При використанні даної методології зменшують обсяг письмової
документації в порівнянні з іншими методологіями. Це призводить до
критики цих методологій як недисциплінованих.
Використовуються гнучкі методології в наступних випадках:
● Коли потреби користувачів і замовників змінюються;
● На відміну від Водоспадної моделі в гнучкій методології для початку
проекту досить лише невеликого планування

1.7. Scrum як один з різновидів Agile методологій

Scrum є найпопулярнішою і широко використовуваною Agile

методологією розробки ПЗ [11]. Важливо розуміти, що Agile - це
специфікація методологій, а Scrum - конкретна реалізація даної
специфікації, тобто набір конкретних правил і підходів

17
 Рис. 6. Робота по Scrum

Робота по Scrum організована за такими основними правилами (Рис.

6.):
● існує «власник продукту» - це замовник продукту або особа, що
представляє його, власник продукту стежить за постановкою завдань і їх
виконанням, тісно спілкується з командою;
● робота виконується в невеликих кроссфункціональних командах, що
складаються з розробників, тестувальників і інших фахівців, виділяється
одна людина - скрам-майстер, який відповідає за дотримання процесів в
команді, комунікацію між членами команди і іншими відповідальними
людьми, а також за конструктивну атмосферу;
● вся робота ведеться короткими (від 1 до 4 тижнів) фіксованими ітераціями
- спринт, в результаті яких поставляється деякий кінцевий функціонал,
який можна навіть вивести на ринок при необхідності;
● всі завдання, які є в проекті, записуються в порядку пріоритету в беклог
продукту;
● команда, оцінюючи свою швидкість, набирає завдання на спринт, який не

18
 змінюється в часі, і складається беклог спринту;
● в процесі роботи члени команди беруть в роботу елементи беклога спринту
відповідно до пріоритету завдання;
● в кінці кожного спринту проводиться огляд спринту, щоб отримати
зворотній зв'язок від власника продукту, і ретроспективу спринту, щоб
оптимізувати процеси роботи в команді, кожен член команди визначає, що
було добре, а що не сподобалося;
● після цього власник продукту може поміняти вимоги або їх пріоритети і
запустити новий спринт, виконуючи всі кроки заново.

19
 1.8. ПОСТАНОВА ЗАДАЧІ

Як вибрати методологію? Найчастіше, коли необхідно прийняти

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

20
 1.9. ВИСНОВКИ ДО РОЗДІЛУ 1

1. Популярність методологій розробки зростає, і пов'язано це в першу

чергу з мобільними технологіями, та збільшенню вимогливості
замовників до швидкості та результативності команд розробників та
новими вимогами щодо доступності та масштабованості.
Незважаючи на те що такі методології як Waterfall і досі
користуються популярністю, але вони не є «срібною кулею»,
особливо на швидкозмінному ринку мобільних технологій. При
розробці програмного продукту використовується велика кількість
методологій розробки ПЗ, інакше кажучи, усталених підходів і
наборів правил. Вибір залежить від специфіки конкретного проекту,
бюджету, часових рамок, суб'єктивних переваг і навіть темпераменту
і настрою керівника.
2. При використанні моделі Waterfall легко керувати проектом. Завдяки
її жорсткості і неможливості відхилень від заздалегідь визначених
рамок, розробка ПО проходить швидко, а вартість і терміни
заздалегідь визначені. Але це є, як і перевагою, так одночасно і
недоліком. Каскадна модель дає відмінний результат тільки в
проектах із заздалегідь визначеними вимогами і способами їх
реалізації. Немає можливості повернутися і щось поміняти в
вимогах, навіть, якщо дуже потрібно. Тестування продукції
починається тільки після того, як розробка повністю завершена або
майже завершена. Ті продукти, які були розроблені за цією моделлю
без обґрунтованого її вибору, можуть мати недоліки, так як список
вимог не можна скорегувати після розробки, про які стає відомо
лише в кінці, або на стадії розробки або тестування через сувору
послідовності дій.
3. У інкрементній методології управління повні вимоги до системи
діляться на різні збірки, системні пакети. Є кілька циклів розробки, а
цикл, в свою чергу, розділений на більш дрібні і легко створювані

21
 частини функціоналу. Кожна частина проходить через фази
визначення системних вимог, проектування, написання коду,
тестування і впровадження. Процес розробки за інкрементною
методологією передбачає випуск на найпершому великому етапі
продукту в базовій обмеженій функціональності, а потім вже
поступове додавання нових функцій. Процес триває до тих пір, поки
не буде створена повна система.
4. Основна відмінність від інкрементної методології полягає в тому, що
інкрементна модель розробки спрямована на створення окремих
фінальних і завершених модулів системи з вже працюючим
функціоналом, в свою чергу, ітеративна модель спрямована на
створення версій ПЗ з подальшим поліпшенням.
5. Спіральна модель не підійде для малих проектів, має сенс її
використовувати, якщо проект дорогий і великий, припустимо,
таких, як розробка ПЗ документообігу для великого банку, коли
кожен наступний крок вимагає ще більшого аналізу для оцінки
наслідків, ніж програмування.
6. Дана методологія розробки ПЗ підходить для тривалих і великих
проектів, постійно адаптуються до потреб ринку. Відповідно, в
процесі реалізації продукту ПЗ вимоги постійно змінюються. Також
методологія підходить для класу творчих людей, які генерують,
видають і пробують нові ідеї і думки щодня або навіть щогодини.
Внутрішні стартапи краще розробляти, використовуючи гнучкі
методології розробки ПЗ.

22
 РОЗДІЛ 2. Детальне дослідження методологій розробки Waterfall та
Scrum

2.1. Обгрунтування вибору Waterfall та Scrum

Як можемо бачити зі статистики Гнучкі методології (Рис. 7.) є

найпопулярнішими (58%), а водоспадна методологія залишається єдиною
методологією, котра із усіх методологій, окрім гнучкої, використовується
масово і в наші дні (18%).
Серед гнучких методологій на основі дослідження компанії Agile
Survey (співтовариство Agile), про популярність гнучких методологій,
результати його представлені на Рис. 8. Можемо бачити що серед усіх
гнучких методологій розробки зі значним відривом перемагає Scrum
(75%).

Рис.7. Статистика по використанню методологій розробки на ринку

23
 Рис. 8 - Використання гнучких методологій

Тож на основі приведених вище статистик, було вирішено

продовжувати дослідження методології SCRUM та WATERFALL, оскільки
вони, із дуже значною перевагою, використовуються в проектах компаній.

2.2. Гнучкі методології розробки та їх види

Перш, ніж впровадити оптимальну для замовника методологію

розробки, необхідно проаналізувати їх, адже впровадження безпосередньо
залежить від особливостей методології. Для цього потрібно ясно розуміти
відмінності гнучких методологій і жорстких ієрархічних, одна з яких з
великою ймовірністю буде використовуватися під впроваджуваної
компанії.
Як правило, розробка програмного забезпечення являє собою досить
хаотичну діяльність, яку нерідко можна охарактеризувати фразою "code
and fix" ("пишемо і правимо") [12]. Єдиного алгоритму не існує, а
загальний проект являє собою просто суміш короткострокових рішень.
Такий підхід може згодитися для невеликої системи, однак якщо система
починає рости, додавати в неї нові властивості стає все важче. Не варто
забувати і про те, що чим більше система, тим більше в ній з'являється
24
помилок, які все складніше і складніше виправляти. А це означає, що
більшість великих створюваних систем мають довгий тестовий період,
хоча розробка всієї функціональності давно закінчена. Рідко які компанії
закладають у план проекту цей відрізок часу, а тому дуже часто
відбувається зрив термінів здачі проекту. А точніше сказати, закладатися-
то він закладається, але не настільки тривалий, який він виходить в
реальності, так як при подібному тестуванні і виправленні помилок
адекватне планування просто неможливо.
Однак у команд завжди була альтернатива - використовувати методологію
розробки, яка перетворює створення програмного продукту в
упорядкований процес, за допомогою якого можна зробити роботу
програміста більш прогнозованою і ефективною [13]. Для досягнення цієї
мети створюється детальний опис процесу, важливе місце в якому посідає
планування. Здавалося б - ось рішення проблеми непередбачуваності
розробки і виходу за рамки встановлених термінів. Однак в подібних
методиках є один істотний недолік, через який більшість команд
програмістів від них відмовляються. Щоб зробити процес розробки
передбачуваним, необхідно налагодити дисципліну всередині колективу, а
для цього потрібно точно виконувати розпорядження методології і
виконувати безліч різних допоміжних дій, що часто уповільнює весь темп
робіт. І в підсумку використання такого підходу часто стає безглуздим.
Саме тому такі методології розробки програмного забезпечення називають
важкими, або, відповідно до терміна Джима Хайсміта, - монументальними.
Кілька років тому такий стан справ наштовхнуло методологів на думку, що
потрібно якось змінювати процес створення програмних продуктів, і на
світ з'явилася група нових, полегшених методологій, які докорінно
відрізняються від монументальних. В даний час найбільш поширений для
них термін гнучкі (agile). Вони являють собою щось середнє між занадто
перевантаженим процесом розробки і повним його відсутністю. Інакше
кажучи, обсягу процесу в них якраз достатньо, щоб отримати розумну
віддачу.
25
 Одним з очевидних відмінностей гнучких методологій від
великовагових є набагато менший обсяг артефактів і більша орієнтація на
вихідний код як ключову частину документації. Зовсім не обов'язково
створювати пачку нікому не потрібних документів тільки заради процесу.
Але це не головне їх відмінність, це скоріше наслідок. Найбільш істотними
відмінностями є наступні:
● "Гнучкі методології адаптивні [14], а не передбачувані. Для великовагових
методологій необхідно детальне планування великого обсягу розробок, і
такий підхід працює - але до тих пір, поки не почнуться зміни. Отже, для
цих методологій опиратися всяким змінам цілком природно. Гнучкі ж
методології, навпаки, зміни вітають. на відміну від великовагових, вони
були задумані як процеси, які адаптують зміни і тільки виграють від них,
навіть у тому випадку, коли зміни відбуваються в них самих.
● Гнучкі методології орієнтовані на людину, а не на процес. У них ясно
заявлено про необхідність враховувати в роботі природні якості людської
натури, а не діяти їм наперекір. Крім цього в гнучких методологіях
особливо підкреслюється, що робота зі створення програмних продуктів
повинна приносити задоволення. ".
● Одними з головних критеріїв для порівняння методологій розробки
програмних продуктів є ітеративність і формальзованість. Відповідно до
цих критеріїв методології бувають каскадні / ітеративні і низько
формалізовані / високо формалізовані.
● Велика частина команд, що розробляють програмне забезпечення, до сих
пір використовують в своїх проектах каскадну розробку, при якій фази
виконуються в чіткій послідовності: [15] спочатку вимоги, потім аналіз і
проектування, потім реалізація / інтеграція і потім тестування. Такий
підхід змушує ключових членів групи простоювати досить тривалий час, а
тестування відкладається на самий кінець життєвого циклу проекту [16],
коли стає дорого виправляти якісь серйозні помилки, і це ставить під
загрозу терміни виходу кінцевого продукту.

26
 Ітеративний підхід це послідовність наростаючих кроків або
ітерацій. Кожна ітерація [17] включає в себе деякі або більшу частину
дисциплін розробки. У кожній ітерації [17] є чітко визначений набір цілей,
і вона створює частково працюючу реалізацію кінцевої системи. кожна
наступна ітерація будується на результатах попередніх, розвиває і
вдосконалює систему до тих пір, поки не буде створено кінцевий продукт.
В процесі итеративной розробки робочі версії системи, що мають якийсь
обмежений набір необхідних властивостей, виробляються досить часто.
Таким проміжним версіями бракує функціональності, проте, в усьому
іншому вони повністю відповідають кінцевої системі. Проміжні варіанти
системи повинні бути повністю інтегровані і так само добре відтестували,
як і кінцева версія продукту. Всі гнучкі методології використовують саме
ітеративний підхід, і це не випадково. Ітеративний підхід виявляється
ефективніше за кількома показниками.
● Він пристосований до мінливих вимог. Зміна вимог і додавання нових
властивостей, що визначається замовником або потребами технології
завжди було найголовнішим джерелом бід проектів. Воно приводило до
запізнення з випуском, порушення графіків, незадоволення замовників і
подразнення розробників. Однак, це нормальна практика в розробці
програмного забезпечення, і було б нерозумно цьому дивуватися.
Звичайно, можна вважати, що часто змінюються вимоги - результат
поганий опрацювання вимог, однак справи йдуть далеко не завжди таким
чином. Адже відразу визначити всі можливі варіанти вимог непросто.
Тільки отримавши якусь версію системи, можна оцінити, які її властивості
важливі, а які абсолютно непотрібні і незручні. Виконати проект без змін
можна, але це загрожує випуском продукту, який не буде мати ніякої
комерційної цінності. До того ж, не варто забувати про такий важливий
чинник, як час. У світі бізнесу та інформаційних технологій не стоїть на
місці, а рухається вперед стрімкими темпами, тому те, що актуально
сьогодні, через півроку виявиться застарілим. А якщо проект розрахований
не на один рік, то з самого початку проекту слід готуватися до мінливих
27
 вимог з боку замовника.
● Інтеграція [18] - це не один «великий вибух» в кінці проекту. Залишити
інтеграцію на самий кінець означає отримати переробки з великими
витратами часу - іноді до 40% всього обсягу проекту. Щоб цього не
допустити, ітеративний підхід пропонує розбити весь процес розробки на
невеликі ітерації, в кінці кожної з яких повинна бути готова повноцінна
робоча версія системи, повністю відтестувати і інтегрована. А значить,
переробка мінімізується.
● Ризики зазвичай виявляються і усуваються на ранніх ітераціях [19].
Ітеративний підхід мінімізує ризики на ранніх стадіях, коли тестуються всі
компоненти. Він дозволяє вчасно зрозуміти, чи є передбачуваний ризик
реальним, і виявити нові. На початку проекту це зробити набагато легше і
не так дорого.
● Менеджери мають можливість внесення тактичних змін в продукт.
Ітеративна розробка швидко створює виконувану архітектуру (хоча і з
обмеженою функціональністю), яку можна використовувати для швидкого
випуску продукту з деякими обмеженнями [19].
● Полегшується повторне використання [19]. Набагато легше визначити
загальні частини тоді, коли вони вже частково спроектовані або реалізовані
в ітераціях, ніж розпізнати їх при плануванні. Рецензування проектних
рішень на ранніх ітераціях дозволяє архітекторам вказати на потенційні
можливості для повторного використання і потім розробити в наступних
ітераціях зрілий загальний код для реалізації таких можливостей.
● Дефекти можна знайти і виправити за кілька ітерацій [19], що забезпечує
створення чіткої архітектури та високоякісного додатки. Вузькі місця
виявляються ще на ранніх ітераціях, а не в кінці проекту при глобальному
тестуванні.
● Краще використання персоналу в проекті. [19] Багато організацій
поєднують використання каскадного підходу з організацією на кшталт
конвеєра: аналітики посилають готові вимоги проектувальникам, які
відсилають свій продукт програмістам, які посилають компоненти
28
 фахівцям з інтеграції, які відсилають систему тестувальникам. Такі
численні переходи є джерелами помилок і непорозумінь і змушують людей
менше відчувати відповідальність за кінцевий продукт. Ітеративний процес
розширює області компетенції членів групи, дозволяючи їм виконувати
багато ролей, дозволяючи менеджеру проекту краще використовувати
наявний персонал, і одночасно прибирає шкідливі передачі.
● Члени команди вчаться на ходу. Учасники проекту протягом циклу
розробки отримують можливість навчатися на своїх помилках від ітерації
до ітерації.
● Поліпшується процес розробки сам по собі і стає по ходу роботи
досконалішим. В кінці кожної ітерації учасники проекту можуть оцінити
організацію процесу і внести в нього необхідні корективи, якщо щось не
буде підходити їхній команді.

2.3. SCRUM

«Порвіть свої візитки. Позбавтеся від звань і титулів, від керівників та

ієрархічних структур. Дайте людям свободу робити те, що вони вважають
правильним, і можливість нести за це відповідальність. Результати вас
вразять».
Ті, хто займається управлінням проектами, та й просто управлінням, добре
знають, наскільки складно організувати злагоджену командну роботу.
Через відсутність злагодженості постійно порушуються плани,
відбувається відставання від графіка, бюджет проекту роздувається, гроші
і час витікають крізь пальці, завдання різних підрозділів дублюються,
люди сперечаються і не допомагають один одному, хоча, здавалося б, їх
зусилля спрямовані на досягнення однієї мети. Крім того, замовники часто
бувають не задоволені остаточним варіантом створеного продукту.
Методика Scrum, яку розробили Джефф Сазерленд і Кен Швабер [20],
покликана вирішити всі ці проблеми.
Scrum - це противагу класичному поетапного підходу [21], що
застосовується до реалізації проектів. Методику Scrum взяли на озброєння
29
 багато компаній як з технологічних галузей, звідки вона сама родом, так і з
традиційних і навіть некомерційних. Підхід, що лежить в основі методики
Scrum, можна застосовувати в різних видах діяльності, в яких потрібно
колективна робота.
Важливими характеристиками Scrum є її гнучкість і орієнтованість на
клієнта, так як вона передбачає його (клієнта) безпосередню участь в
процесі роботи.

Scrum не вимагає впровадження будь-яких дорогих інструментів

[21]. Схему методики Scrum можна описати таким чином:

1. Для початку необхідно вибрати «Власника продукту» [21] - людини, що

володіє баченням того, що ви збираєтеся створити або досягти.
2. Потім потрібно зібрати «Команду», до якої увійдуть люди, які
безпосередньо виконують роботу. Вони повинні володіти навичками і
знаннями, які допоможуть втілити ідею власника продукту в життя [21].
3. Потрібно вибрати «Скрам-майстра» - того, хто буде стежити за ходом
реалізації проекту, забезпечувати проведення коротких зборів і допомагати
команді усувати перешкоди на шляху досягнення мети [21].
4. Приступаючи до роботи, потрібно створити максимально повний список
всіх вимог, що пред'являються до продукту або цілі. Пункти цього списку
повинні бути розставлені по пріоритету. Список носить назву «Беклог
продукту». Він може розвиватися і змінюватися протягом усього терміну
реалізації проекту [21].
5. Учасники команди повинні оцінити по своїй системі оцінок кожен пункт
на предмет складності і витрат, які будуть потрібні для його виконання
[21].
6. Потім учасники, скрам-майстер [21] і власник продукту повинні провести
перше скрам-збори, на якому вони запланують спринт - певний час для
виконання частини завдань. Тривалість спринту не повинна перевищувати
один місяць. За кожен спринт команда напрацьовує певну кількість балів.
30
 Команда повинна постійно прагнути до того, щоб перевершити в новому
спринті кількість напрацьованих балів за попередній спринт, тобто її мета -
постійно перевершувати свої власні результати - «нарощувати динаміку
продуктивності».
7. Щоб всі учасники були в курсі стану справ потрібно завести скрам-дошку з
трьома колонками [21]: «Потрібно зробити, або беклог»; "В роботі";
«Зроблено». На дошку учасники клеять стікери із завданнями, які в процесі
роботи по черзі переміщаються з колонки «Беклог» в колонку «в роботі», а
потім в «зроблено».
8. Щодня проводиться скрам-збори. За висловом Джеффа Сазерленда «це
пульс всього процесу Scrum». Суть його проста - щодня, на ходу,
п'ятнадцять хвилин на те, щоб все дали відповіді на три питання: «Що ти
робив вчора, щоб допомогти команді завершити спринт?», «Що ти будеш
робити сьогодні, щоб допомогти команді завершити спринт?» , «Які
перешкоди стають на шляху команди?».
9. По завершенні спринту команда робить його огляд - проводить зустріч, на
якій учасники розповідають, що зроблено за спринт.
10.Після показу результатів роботи за спринт учасники проводять
ретроспективне збори [21], на якому обговорюють, що команда робила
добре, що можна зробити краще, що можна поліпшити прямо зараз.

31
 2.3.1. Розстановка пріоритетів

Рис. 9. Розстановка приорітетів

Суть роботи полягає в пошуку золотої середини - збалансованої

концепції між трьома крайнощами (Рис. 9.):

● Ви висуваєте на перший план то, що ви можете запропонувати. Тоді

виникає ризик зробити нікому непотрібний продукт;
● Ви орієнтуєтеся на ринок. Тоді вас можуть випередити або знищити
конкуренти;
● Ваше головне прагнення - великі продажі. Тоді ви ризикуєте випустити на
ринок посередній продукт.

2.3.2. Елементи SCRUM

2.3.2.1. Складання backlog проекту

Backlog проекту [22] - аналог стандартного ТЗ по розробці

мобільного додатку. Правда, на відміну від технічного завдання, яке часом
затягує на 70 - 90 сторінок А4, backlog проекту створюється у вигляді
набору вимог до проекту, а їх повна деталізація буде поступовою, етап за
етапом. Це допоможе вам уважно звертати уваги на всі вимоги до проекту,
32
що розробляється.
Кожному пункту в backlog проекту присвоюється пріоритет (від 10
до 100), вказуються попередні витрати часу на етап (в людино-годинах).
Головна особливість backlog в тому, що ви можете внести правки в
пріоритет, список функцій (розширити його або звузити) до того, як
фахівці візьмуть його в роботу. Всі зміни вносяться «безболісно» і
дозволяють в точності реалізувати всі ваші задуми щодо дизайну і
функціоналу корпоративного мобільного додатку, інтернет-магазину або
каталогу.

2.3.2.2. Робочі спринти

Весь робочий процес над проектом розбитий на короткі етапи

(спринти) [23]. Тривалість одного спринту від 1 до 2 тижнів в залежності
від комплексу цілей, які необхідно виконати в рамках даного етапу.
Функції, які потрібно реалізувати на кожному спринті - зафіксовані (їх не
можна змінювати по ходу спринту). Цей підхід ідеально підходить для
бізнесу, адже ви можете запустити продажу (почати отримувати прибуток)
ще до того, як всі задумані функції і «фічі» будуть реалізовані.

2.3.2.3. Щоденні наради

Робота за методологією SCRUM передбачає щоденні наради, під час

яких кожен виконавець в команді відповідає на три питання:
- що було зроблено вчора?
- що я збираюся зробити сьогодні?
- які проблеми виникли під час роботи?
Тривалість наради 10-15 хвилин, під час яких менеджер проекту
дізнається, на якому етапі перебуває розробка програми, які труднощі
виникли з реалізацією, як їх усунути і скільки часу знадобитися для цього
[23]. Завдяки щоденній звіту менеджер проекту завжди тримає руку на
пульсі і вчасно реагує на проблеми, а не спохвачується в самий останній

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

2.3.2.4. Власник продукту

У скрам передбачається три ролі:

1. скрам-команда - виконавці конкретних проектів;
2. скрам-майстер - це той, хто стежить за ходом проекту і допомагає команді
вирішувати проблеми;
3. власник продукту - той, хто вирішує питання концепції продукту і
становить беклог.

Скрам-майстер і команда відповідають за те, яким буде темп їх праці

і як швидко вони закінчать проект [23].
Власник продукту відповідальний за те, щоб результативна
командна робота перетворилася в результат, що приносить прибуток.
Власнику продукту необхідно добре знати ринок і у нього повинні бути
повноваження для прийняття рішень.

Це може бути дуже великою зоною відповідальності для однієї

людини, тому на великих проектах може працювати бригада власників
продукту.

2.3.2.5. Контроль замовником всіх етапів роботи

Багато хто впевнений, що методологія SCRUM побудована на тих же

принципах, що і всесвітньо відома техніка організації роботи - «Водоспад»
(Waterfall), коли комунікація між компанією, що розробляє мобільний
додаток, розрахована всього на 2-3 зустрічі, під час яких озвучуються
основні вимога і бачення мобільного додатку, обговорюється ТЗ і
демонструється кінцевий результат.
SCRUM передбачає більш тісне спілкування клієнта і IT-компанії:
34
фахівці демонструють вам результати кожного спринту, обговорюють їх,
складають список правок, які вносяться в стислі терміни.

2.3.2.6. Надання звітів в кінці кожного спринту

В кінці кожного етапу робіт (спринту) ви отримаєте детальний звіт

про виконану роботу і завжди будете знати, чим зайнята команда, якій ви
довірили розробку мобільного додатку (Рис. 10.).

Рис. 10. Scrum

2.3.3. Мінімізація ризиків в скрам

Так як в скрам передбачена покрокова здача проекту, то це сприяє

мінімізації ризиків. Це допомагає швидше показувати клієнту продукт і
отримувати від нього зворотний зв'язок.

«Методологія Scrum корисна бізнесу тим, що швидко відповідає на

питання: чи зможемо ми заробити гроші, якщо зробимо те чи інше?»

Вам не потрібно витрачати величезні кошти перед тим, як зрозуміти, що

щось не працює.
35
 2.3.4. Переваги SCRUM для замовника

2.3.4.1. «Нульовий» спринт

«Нульовий» спринт [24] - передпроектна підготовка проекту до реалізації.

Маркетолог компанії вивчає цільову аудиторію замовника, аналізує
прямих конкурентів, вивчає сферу бізнесу. Результатом етапу є список
вимог для подальшого проектування мобільного додатку.
Також, на цьому етапі розробляють backlog проекту.
Якщо бізнес-рішення, розроблене в ході «нульового» спринту,
клієнта влаштовує, можна приступати до подальшої роботи.
Перевага такого підходу - в легкому старті: в короткий термін і за
прийнятну ціну клієнт отримує базове бізнес-рішення, «основу» для
подальшого проектування і розробки.
Отримання робочої версії продукту в короткий термін - одне з
головних переваг системи SCRUM. В кінці кожного спринту замовник
отримує готовий результат. Запустивши продукт вже після перших
спринтів з програмування, замовник зможе отримувати прибуток і
взаємодіяти з клієнтом, і одночасно впроваджувати нові функції.

2.3.4.2. Оплата фактично витраченого часу фахівця.

Робота за методологією SCRUM - це істотне зниження ризиків,

пов'язаних з оплатою праці програмістів, дизайнерів, верстальників.
Замовник оплачує фактично витрачені години на роботу фахівця.

2.3.4.3. «Безболісні» зміни проекту

Scrum - єдина система, в якій внесення правок в дизайн і функціонал

мобільного додатку можливо в процесі розробки проекту. Так замовник
економить час - у фахівця на виправлення піде 30-40 хвилин, а на внесення
правок вже після розробки проекту - не менше 3-4 годин.
Ще одна перевага в тому, що робота ведеться окремими блоками

36
[25]. Їх тривалість - 2 тижні. В кінці кожного етапу ви оцінюєте результат,
і, якщо у вас з'являються нові ідеї, ми відразу їх впроваджуємо і на їх
основі змінюємо наступний функціонал мобільного додатку.

2.3.4.4. Повний контроль команди.

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

роботу, детальний список впроваджених функцій, згідно backlog. Замовник
завжди буде знати, на якому етапі перебуває підготовка продукту і чим
зайнята команда.

2.4. WATERFALL

Методика Waterfall (водоспадна система розробки) (Рис. 11.) -

дітище Вінстона Уолкера Ройса, директора Lockheed Software Technology
Center в Остіні (штат Техас, США), піонера в області розробки
програмного забезпечення [26].
З методикою Waterfall вийшло також, як і з багатьма винаходами:
свій внесок у створення методології зробили Герберт Беннінгтон в 1956 р і
Хозьер в 1961 р, а Уолкер використовував їх напрацювання, забезпечивши
собі славу «творця Waterfall».
Водоспадна модель розробки передбачає послідовне проходження
процесу, розбитого на стадії. Перехід до нового етапу можливий тільки
після завершення попереднього.

37
 Рис. 11. Модель Waterfall
В оригінальній роботі Уолкера «Managing the development of large
software systems» [28] описані 6 стадій розробки продукту, які в 1985 році
Департамент захисту США закріпив в стандартах роботи з розробниками
програмного забезпечення:
● Системні і програмні вимоги: закріплюються в PRD (документі вимог до
продукту).
● Аналіз: втілюється в моделях, схемах і бізнес-правилах.
● Дизайн: розробляється внутрішня архітектура програмного забезпечення,
способи реалізації вимог. Це не тільки про інтерфейс і зовнішній вигляд
ПО, а й про його внутрішньої структурної логіці.
● Кодінг: безпосередньо пишеться код програми, йде інтеграція програмного
забезпечення.
● Тестування: баг-тестери (тестувальники) перевіряють фінальний продукт,
заносячи в трекери відомості про дефекти коду програми або функціоналу.
У разі помилок і наявності часу / фінансів відбувається виправлення багів.
● Операції: продукт адаптується під різні операційні системи, регулярно

38
 оновлюється для виправлення виявлених користувачами багів і додавання
функціоналу. В рамках стадії також здійснюється технічна підтримка
клієнтів.
Компанія Toyota, популяризувати методології Lean і Kanban, до
кінця 2000-х користувалася каскадної моделлю розробки ПО для потреб
виробництва.

2.4.1. Переваги Waterfall

Не важко помітити, що каскадна модель має безліч переваг, якщо її

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

2.4.2. Недоліки каскадної моделі

Але при використанні каскадної моделі для проекту, який важко

назвати відповідним для неї, виявляються такими недоліки [29]:
● в основі моделі лежить послідовна лінійна структура, в результаті чого
кожна спроба повернутися на одну або дві фази назад, щоб виправити
будь-яку проблему або недолік, призведе до значного збільшення витрат і
збою в графіку [29];
● вона не може запобігти виникненню ітерацій між фазами, які так часто
зустрічаються при розробці ПЗ, оскільки сама модель створюється
відповідно до стандартного циклу апаратного інжинірингу;
● вона не відображає основну властивість розробки ПО, спрямоване на
рішення завдань. Окремі фази строго пов'язані з певними діями, що
відрізняється від реальної роботи персоналу або колективів [29];
● вона може створити помилкове враження про роботу над проектом. Вираз
типу "35 відсотків виконано" - не несе ніякого сенсу і не є показником для
менеджера проекту [29];
● інтеграція всіх отриманих результатів відбувається раптово в завершальній
стадії роботи моделі. В результаті такого одиничного проходу через весь
40
 процес, пов'язані з інтеграцією проблеми, як правило, дають про себе знати
занадто пізно. Отже, з’являються не виявлені раніше помилки або
конструктивні недоліки, підвищується ступінь ризику при невеликому
завданні та зменшується час на відновлення продукту [29];
● у клієнта майже немає можливості ознайомитися з системою заздалегідь,
це трапляється лише в самому кінці життєвого циклу. Клієнт не має
можливості користуватися доступними проміжними результатами, і
відгуки користувачів не можна передати назад розробникам. Оскільки
готовий продукт не доступний до закінчення процесу, користувач приймає
участь в процесі розробки тільки на самому початку - при зборі вимог, і в
кінці - під час приймальних випробувань [29];
● користувачі не можуть переконатися в якості розробленого продукту до
завершення усього процесу розробки. Вони не мають можливості оцінити
якість, якщо не можна побачити готовий продукт розробки [29];
● у користувача немає можливості поступово звикнути до системи. Процес
навчання відбувається в кінці життєвого циклу, коли ПО вже запущено в
експлуатацію [29];
● проект можна виконати, застосувавши впорядковану каскадну модель, і
привести його у відповідність з письмовими вимогами, що, однак, не
гарантує його запуску в експлуатацію [29];
● кожна фаза є передумовою для виконання наступних дій, що перетворює
такий метод в ризикований вибір для систем, які не мають аналогів, так як
він не піддається гнучкому моделюванню [29];
● для кожної фази створюються результативні дані, які по його завершенню
вважаються замороженими. Це означає, що вони не повинні змінюватися
на наступних етапах життєвого циклу продукту. Якщо елемент
результативних даних будь-якого етапу змінюється (що зустрічається
досить часто), на проект зробить негативний вплив зміна графіка, оскільки
ні модель, ні план не були розраховані на внесення та дозвіл зміни на
більш пізніх етапах життєвого циклу [29];

41
● всі вимоги повинні бути відомі на початку життєвого циклу, але клієнти
рідко можуть сформулювати всі чітко задані вимоги на цей момент.
Модель не розрахована на динамічні зміни у вимогах на про протязі всього
життєвого циклу, так як ці дані "заморожуються". Використання моделі
може спричинити за собою значні витрати, якщо вимоги в недостатній мірі
відомі або схильні до динамічних змін під час протікання життєвого циклу
[29];
● виникає необхідність в жорсткому управлінні і контролі, оскільки в моделі
не передбачена можливість модифікації вимог;
● модель заснована на документації, а значить, кількість документів може
бути надмірною [29];
● весь програмний продукт розробляється за один раз. Немає можливості
розбити систему на частини. В результаті взятих розробниками зобов'язань
розробити конструкцію та цілу систему за один раз, можуть виникнути
проблеми з фінансуванням проекту. Відбувається розподіл великих
грошових коштів, а сама модель не дозволяє повторно розподілити кошти,
не зруйнувавши при цьому проект в процесі його виконання [29];
● відсутня можливість врахувати переробку і ітерації за рамками проекту.
Частково недоліки Водоспадної моделі розробки виправлені в
модифікаціях Waterfall: Waterfall з фазовим нашаровуванням, Waterfall з
субпроектів і водоспадна модель розробки з зниженням ризику.
Водоспадна модель з фазовим нашаровуванням - cамая відома серед
них. У ній етапи як і в оригінальній методиці йдуть один за одним, але при
цьому перекриваються одна інший в часі.
Waterfall з субпроектів - модель, в якій ви працюєте з трьома
великими блоками: концептуалізацію, проектування вимог і архітектурна
структура продукту. Потім для кожного з них ви проходите стадії
(субпроекти) детального проектування, кодування і тестування. В кінці
проводиться інтеграція всіх компонентів на етапі тестування системи.
Водоспадна модель розробки з зниженням ризику - модифікація
класичного Waterfall, в який додані спіралі зниження ризику, які поділяють
42
 проект на міні-проекти і кореспондують їх одному або декільком
ключовим ризикам.

2.4.3. Етапи каскадної моделі

Наведена нижче характеристика являє собою опис кожної фази

каскадної моделі (включаючи фази інтеграції):
● дослідження концепції – відбувається дослідження вимог на системному
рівні [30] з метою визначення можливості реалізації концепції;
● процес системного розподілу - може бути пропущений для систем по
розробці виключно ПО. Для систем, в яких необхідна розробка як
апаратного, так і програмного забезпечення, необхідні функції
застосовуються до ПЗ та обладнання відповідно до загальної архітектурної
системи [30];
● [30] процес визначення вимог - визначаються програмні вимоги для
інформаційної предметної області системи, призначення, лінії поведінки,
продуктивність і інтерфейси (В разі необхідності в процес також включено
функціональний розподіл системних вимог до апаратного і програмного
забезпечення.)
● процес розробки проекту - розробляється і формулюється логічно
послідовна технічна характеристика програмної системи, включаючи
структури даних, архітектуру ПО, інтерфейсні уявлення і алгоритмічну
деталізацію [30];
● процес реалізації - в результаті його виконання ескізний опис ПО
перетворюється в повноцінний програмний продукт. При цьому
створюється вихідний код, база даних і документація, які лежать в основі
фізичного перетворення проекту. Якщо програмний продукт являє собою
набутий пакет прикладних програм, основними діями по його реалізації
будуть установка і тестування пакету програм. Якщо програмний продукт
розробляється на замовлення, основними діями є програмування і код-
тестування [30];
● процес встановлення - включає установку ПО, його перевірку і офіційне
43
 прийняття замовником для операційного середовища [30];
● процес експлуатації та підтримки - має на увазі запуск користувачем
системи і поточне забезпечення, включаючи надання технічної допомоги,
обговорення питань, що виникли з користувачем, реєстрацію запитів
користувача на модернізацію і внесення змін, а також коригування або
усунення помилок[30];
● процес супроводу - з вирішенням програмних помилок, занходження
причин збоїв, модернізацією та внесенням змін, що генеруються в процесі
підтримки. Складається з ітерацій розробки і передбачає зворотний зв'язок
з надання інформації про аномалії[30];
● процес виведення з експлуатації - виведення існуючої системи з її
активного використання, або шляхом припинення її роботи, або завдяки її
заміні новою системою або модернізованою версією існуючої системи[30];
● інтегральні завдання - включають початок роботи над проектом,
моніторинг проекта і його управління, управління якістю, верифікацію і
атестацію, межмент конфігурації, розробку документації і професійну
підготовку протягом усього життєвого циклу [30].

2.4.4. Область застосування каскадної моделі

Через недоліки каскадної моделі її застосування необхідно обмежити

ситуаціями, в яких вимоги та їх реалізація максимально чітко визначені і
зрозумілі.
Каскадна модель добре дає собі раду при її застосуванні в циклах
розробки програмного продукту, в яких використовується незмінне
визначення про продукт і цілком зрозумілі технічні методики.
Якщо компанія має досвід побудови певного роду системи -
автомати автоматизованого бухгалтерського обліку, нарахування зарплати,
ревізії, компіляції, виробництва, тоді в проекті, орієнтованому на побудову
ще одного продукту такого ж типу, можливо, навіть заснованого на
існуючих розробках, можна ефективно використовувати каскадну модель
[31]. Іншим прикладом належного застосування моделі може служити
44
створення і випуск нової версії вже існуючого продукту, якщо вносяться
зміни цілком визначені і керовані. Перенесення вже існуючого продукту на
нову платформу часто наводять як ідеального прикладу використання
каскадної моделі в проекті.
При всій справедливості критики цієї моделі все ж слід визнати [32],
що модифікована версія каскадної моделі є в значній мірі менш жорсткою,
ніж її початкова форма. Тут включаються ітерації між фазами, паралельні
фази і менеджмент змін. Зворотні стрілки припускають можливість
існування ітерацій між діями в рамках фаз. Щоб відобразити узгодженість
між етапами, їх об'єднують прямокутниками або під прямокутниками
перераховують які на даних етапах виконуються дії, щоб
продемонструвати узгодженість між ними. Незважаючи на те, що
модифікована каскадна модель є значно більш гнучкою, ніж класична
модель, вона все ж не є найкращим вибором для виконання проектів з
прискореною розробкою.
Каскадні моделі протягом усього часу їх існування
використовуються при виконанні великих проектів, в яких задіяно кілька
великих команд розробників.

2.4.5. Застосування каскадної моделі в роботі

Перший етап включає в себе спілкування з замовником, роботу з

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

2.5. Формування критеріїв оптимальності вибору методології розробки

На основі проведеного детального дослідження методологій

розробки Waterfall та Scrum, було визначено такі критерії визначення
оптимальності методологій як:

1. Досвідчена команда або аутсорс

Agile: над проектом працює досвідчена, висококваліфікована команда
Waterfall: більша частина або вся робота над проектом проводиться в
аутсорсі

2. Стартап або зрілий продукт

Agile: ви працюєте над стартапом
Waterfall: у вас є чітка концепція продукту який ви хочете отримати

3. Терміни
Agile: потрібно швидко отримати працюючу версію продукту
Waterfall: ви не обмежені в часі та ресурсах створення продукту

4. Роль замовника
46
 Agile: замовник виступає в якості партнера, а не інвестора
Waterfall: замовник ніяк не взаємодіє з продуктом під час розробки

5. Динаміка
Agile: сфера підвержена постійним змінам
Waterfall: створення продукту або бізнесу побудовано на дотриманні
суворої послідовності виконання завдань

2.6. Порівняння

Рис. 12. Порівняння

47
 2.6.1. Порівняльна таблиця

Таблиця 1: порівняння методологій agile та waterfall

Agile Waterfall

Суть Гнучка модель розробки, Каскадна система

заснована на розробки, заснована на
ітеративних принципах жорсткій послідовності
процесу розробки

Дата створення 2001 р 1956 р

Принципи ● Найвищий приорітет ●

в Жорстка послідовність
застосування задоволенні потреб етапів розробки
замовника ● Перехід до нового
● Протягом усього етапу - тільки після
проекту команда і успішного завершення
замовник щодня попереднього
взаємодіють між собою ●і Фіксована вартість
один з одним продукту
● Працюючий продукт ●- Замовник не
головний показник залучається до
прогресу безпосереднього
● Роботу можна довірити процесу розробки
тільки ● Зміни можуть бути
самоорганізованої, внесені тільки після
мотивованій команді завершення всього
● Оптимальні терміни процесу розробки.
випуску робочого
продукту - від 2 тижнів
до 2 місяців

Плюси ● Високий рівень взаємодії

● Зрозуміла і чітка схема
48
 між членами команди робочого процесу
проекту ● Можливість
● Швидкий результат прорахунку точної
(робочий код) в кількості витрачених
результаті «спринтів» на проект ресурсів
● Стимулювання зміни ●і Не вимагає витрат по
поліпшень продукту під налагодженню
час його розробки комунікацій між усіма
● Безпосереднє залучення членами команди
замовника до робочого
процесу

Мінуси ● Ризик нескінченних змін

● Приорітет
продукту формального підходу
● Велика залежність від до послідовності
рівня кваліфікації та процесу роботи
досвіду команди ● Неможливість
● Практично неможливо внесення змін
точно підрахувати замовником до
підсумкову вартість закінчення розробки
проекту продукту
● В разі нестачі ресурсів
страждає якість
проекту через
скорочення етапу
тестування.

Компанії практики Unilever, ряд банків Cisco Ericsson AB,

(Альфа Банк, Home Toyota (до 2010)
Credit, Райффайзен Банк
і т.д.)

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

Не підійде якщо ● Ви не готові витрачати

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

50
 2.7. Характеристика проектів для вибору методології розробки
програмного забезпечення підприємства Avalon - Print

Таблиця 2: Характеристика проектів підприємства Avalon - Print

Параметр Риз Характерист Коментар

ик ика
параметра

Технічні 1 Рутина Розробка такого ПЗ є для компанії

ризики звичайною діяльністю, рутиною

2 Ми вже таке Аналогічне рішення вже колись

робили розроблялося

3 Робили, але Доводилося зустрічатися з подібним

не ми рішенням або воно вже існує у замовника

4 Невідоме Вперше стикаємося з розробкою

рішення подібного ПЗ

Продовження таблиці 2

Сроки 1 Не терміново Замовнику не є принциповим термін

поставки постачання першого прототипу

2 Фіксована дата Термін поставки прототипу фіксований

поставки

3 Регулярна Замовнику необхідно регулярно

поставка отримувати оновлені прототипи

4 Терміново, Замовнику потрібно прототип в

потрібно вже найкоротші терміни
зараз

Вимоги 1 Відомі та Замовник точно знає, що він хоче, і

фіксовані вимоги не можуть змінюватися

51
 2 Відомі, але Замовник знає, що він хоче, але не
можуть виключає деякі зміни у вимогах в процесі
змінюватися розробки

3 Не відомі, Замовник має уявлення про кінцевий

будуть результат, але поки що не може точно
сформовані в сформулювати вимоги
процесі

Бюджет 1 Time & Оплата за фактом виконання робіт:

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

2 Рамковий Укладається договір на певну суму, в

договір рамках якої може реалізовуватися проект

3 Може бути Сума договору фіксована, але може бути

розширений укладений додатковий договір або
розширений поточний

4 Фіксований Сума договору на розробку фіксована і не

може бути змінена

Продовження таблиці 2

Параметр Риз Характеристи Коментар

ик ка параметра

Участь 1 Повна Замовник повністю залучений в

замовника проектний процес, можлива
зайнятість фахівців замовника в
проектну роботу на повний робочий
день

2 По мірі Замовник має обмежену можливість

52
 можливостей брати участь в проектній роботі,
тільки при відсутності зайнятості за
своїми основними посадовими
обов'язками

3 Мінімальна Замовник не зацікавлений в участі в

проектній роботі, повністю зайнятий
основними посадовими обов'язками

Проектні 1 Переважають Переважають контрольовані проектні

ризики контрольовані ризики, їх ймовірність не висока
ризики

2 Переважають Переважають частково контрольовані

частково проектні ризики
контрольовані

3 Переважають Переважають неконтрольовані

неконтрольова ризики, ймовірність досить висока
ні ризики

Нехай F (t, d, r, b, c, p) є функцією вибору методології для створення ІТ-

проекту, де:
t - технічні ризики
d - час доставки
r - вимоги
b - бюджет
c - залучення клієнтів
p - ризики проекту
Як видно з опису змінних, не всі вони мають кількісні значення.
Тому для знаходження значень функції F (t, d, r, b, c, p), що задовільняють

53
розглядуваному проекту, використаємо графічний метод побудови
простору допустимих рішень.
У системі координат, заданій змінними t, d, r, b, c, p, побудуємо
простір, що відображає множину допустимих рішень для обраної
методології ( Ms ).
Задаючі значення змінних t, d, r, b, c, p, побудуємо множину Mp – рішень,
що задовольняють заданим критеріям вибору методології створення
проекту.
Тоді функцію вибору найбільш прийнятної методології можна представити
як:
Mp ∩ Ms →max , (1)

Де,

t € {"Рутина"; "Ми вже таке робили"; "Робили, але не ми"; "Невідоме

рішення"}

d € {“Не терміново”; “Фіксована дата поставки”; “Регулярна поставка”;

“Терміново, потрібно вже зараз”}

r € {“Відомі та фіксовані”; “Відомі, але можуть змінюватися”; “Не відомі,

будуть сформовані в процесі”}

b € {“Time & Materials”; “Рамковий договір”; “Може бути розширений”;

“Фіксований”}

c € {“Повна”; “По мірі можливостей”; “Мінімальна”}

p € {“Переважають контрольовані ризики”; “Переважають частково

контрольовані”; “Переважають неконтрольовані ризики”}

54
 Базуючись на цьому, створюємо діаграму (Рис.13.) в котрій кожна
вершина – це один за параметрів нашої функції:
Для того щоб визначити котра методології є оптимальною для вашого
проекту, потрібно:
1. Визначити найбільш відповідний параметр для вашого проекту для
кожної гілки діаграми;
2. Накреслити профіль методологій серед котрих проводиться вибір.
3. Накреслити профіль вашого проекту на основі параметрів
визначених раніше.
4. Порівняти профіль вашого проекту з профілями методологій.

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

методологія розробки програмного забезпечення
Вона має такий вигляд (Рис. 13):

55
 Рис. 13. Діаграма параметрів вибору
Обираємо для проекту “Мобільний додаток для формування
замовлень поліграфічної продукції”, найбільш відповідні критерії.
1. Технічні ризики
4 - Невідоме рішення - оскільки компанія та її розробники ще не мали
досвіду в розробці додатків даного типу.

2. Термін поставки
4 - Терміново, потрібно вже зараз - оскільки компанія хоче якомога
швидше вийти на ринок та почати отримувати прибутки.

3. Вимоги
3 - Невідомі, будуть сформовані в процесі розробки - оскільки замовник
має представлення про кінцевий результат, але не може сформулювати

56
 чіткі вимоги.

4. Бюджет
1 - Time & Materials - замовник буде платити по факту виконання робіт.

5. Участь замовника
1 - Повна - оскільки вимоги не сформовані, команді розробників необхідно
постійно контактувати із замовником.

6. Проектні ризики
3 - Можуть бути неконтрольовані ризики - оскільки сроки проекту
невеликі, бюджет сталий, а вимоги не сформовані до кінця.

2.7.1. Методологія Scrum

Для використання при роботі принципів гнучкої розробки, а тим

більше всіх практик, об'єднаних під методологією Scrum, необхідно кілька
умов:
● Замовник повинен розуміти і погоджуватися з тим, що він не може
впливати на склад беклога спринту і процес розробки. Він може тільки
формувати і пріоритезувати беклог, але розробники самі вибирають
завдання, які будуть включені в спринт;
● Замовник повинен розуміти, що у проекту можуть бути змінені тимчасові і
бюджетні кордони;
● Існує постійна, самоорганізована скрам-команда, що складається з скрам -
майстрів, аналітиків і розробників. Команда несе колективну
відповідальність за процес розробки.
При виконанні цих умов використання Scrum стає можливо. Профіль
методології Scrum, представлений на Рис. 14.

57
 Рис. 14. Профіль методології скрам на діаграмі параметрів

2.7.2. Каскадна модель розробки ПЗ

За сформованою корпоративною практикою каскадна модель

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

58
Рис. 15. Профіль методології warterfall на діаграмі параметрів

59
2.7.3. Вибір правильної методології розбобки для проекту «Мобільний
додаток для формування замовлень поліграфічної продукції»
організації ПП «Авалон-прінт”.

Як можемо бачити параметри нашого проекту майже повністю

співпадають з профілем методології розробки Scrum. Тож на основі
дослідження робимо висновок, що найдоцільніше використовувати гнучку
методологію розробки. (Рис. 16., Рис. 17.)

Рис. 16. Профіль Scrum

Рис. 17. Профіль проекту

60
 2.8. ВИСНОВКИ ДО РОЗДІЛУ 2

1. Agile і Waterfall - дві абсолютно різні методики розробки та

управління проектами. Кожна з них породила десятки модифікацій і
методів, «заточених» під конкретний формат проектів. Гнучка
модель буде ідеальною для IT-компаній, стартапів, проектах в
інноваційних сферах.
Каскадна модель не здає позиції в будівельних проектах або
проектах, де ключовим обмежувачем є термін реалізації проекту, а
не фінанси.
З урахуванням особливостей кожної з методик і вашого
бізнесу, а також на основі критеріїв ризику, часу і залучення
зацікавлених осіб ви зможете самостійно визначити ефективну
методологію.

2. Як можемо бачити зі статистики Гнучкі методології (Рис. 7.) є

найпопулярнішими (58%), а водоспадна методологія залишається
єдиною методологією, котра із усіх методологій, окрім гнучкої,
використовується масово і в наші дні (18%). Cеред усіх гнучких
методологій розробки зі значним відривом перемагає Scrum (75%).

3. Гнучкі методології являють собою щось середнє між занадто

перевантаженим процесом розробки і повним його відсутністю.
Інакше кажучи, обсягу процесу в них якраз достатньо, щоб отримати
розумну віддачу. Одним з очевидних відмінностей гнучких
методологій від великовагових [33] є набагато менший обсяг
артефактів і більша орієнтація на вихідний код як ключову частину
документації. Зовсім не обов'язково створювати пачку нікому не
потрібних документів тільки заради процесу.

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

5. Водоспадна модель розробки передбачає послідовне проходження

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

6. Agile: сфера підвержена постійним змінам

Waterfall: створення продукту або бізнесу побудовано на дотриманні
суворої послідовності виконання завдань

7. Параметри пректу “Мобільний додаток для формування замовлень

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

62
 РОЗДІЛ 3. Процес розробки проекту «Мобільний додаток для
формування замовлень поліграфічної продукції» організації ПП
«Авалон-прінт” в рамках методології розробки ПЗ Scrum

3.1. Створення Беклогу продукту

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

момент часу. Створюється командою, на основі вимог та побажань
замовника до створюваного додатку.
Зовнішній вигляд частини беклогу додатку зображено на Рис. 18.

Рис. 18. Беклог проекту

3.2. Створення першого спринту

Після визначення приорітетних задач, з цих задач створюється

перший спринт.
Тривалість спринту: 2 тижні. По закінченню яких повинні бути
виконані всі поставлені задачі.
Вигляд вікна створення спринту зображено на Рис. 19.
63
 Рис. 19. Створення першого спринту

3.3. Виконання першого спринту

В першому спринті було визначено такі задачі:

● Створення ядра додатку
● Створення сторінки замовлення холстів
● Створення сторінки контактів
● Створення інформаційної сторінки
● Створення головної сторінки додатку
● Створення сторінки замовлення банерів
● Створення сторінки замовлення плакатів
● Створення сторінки замовлення наліпок
64
 Вигляд вікна з активним першим спринтом зображено на Рис. 20.

Рис. 20. Вікно активного першого спринта

Після завершення першого спринту:

● 10-15 хв нарада з командою про виконану роботу, та вкладання в сроки;
● зустріч з замовником, звіт про результати;
● складання другого спринту з включенням невиконаних завдань першого
спринту (якщо такі є).

3.4. Створення другого спринту

Після визначення приорітетних задач, з цих задач створюється

другий спринт.
Тривалість спринту: 2 тижні. По закінченню яких повинні бути
виконані всі поставлені задачі.
Вигляд вікна створення спринту зображено на Рис. 21.

65
 Рис. 21. Створення другого спринту

3.5. Виконання другого спринту

В другому спринті було визначено такі задачі:

● Створення кошику для замовлень
● Створення сторінки формування замовлень
● Створення месенджеру онлайн підтримки
● Створення сторінки історії замовлень
● Створення сторінки редагування профілю користувача
● Створення сторінки реєстрації
● Створення сторінки входу до профілю користувача
● Створення сторінки відновлення паролю
● Створення головної сторінки профілю користувача
66
 Вигляд вікна з активним другим спринтом зображено на Рис. 22.

Рис. 22. Вікно активного другого спринта

Після завершення другого спринту:

● Нарада з командою про виконану роботу, та вкладання в сроки;
● Зустріч з замовником, звіт про результати;
● Якщо всі задачі виконані - здача першої версії проекту;
● Якщо команда не встигла виконати всі задачі - перенесення сроків до
завершення наступного спринту.

3.6. Результат 4-х тижнів спринту (Готова перша версія додатку)

Після запуску програми з’являється головне меню (див. рис. 23.), на

ньому відображені його пункти, перші чотири пункти це типи продукції
які доступні для замовлення на даний момент, два останні пункти, це
довідники, в яких є вся необхідна інформація щодо компанії, та послуг що
вона надає.
Ліва іконка на панелі навігації, це кнопка доступу до аутентифікації
користувача.
Права іконка на панелі навігації, це кнопка доступу до кошика, в
який користувач додає продукцію для подальшого замовлення.
67
 При переході на один з пунктів меню з вибору продукції, бачимо
форму (див. рис. 24.), в якій користувач обирає деталі продукції яку він
хоче замовити (тираж, розмір, маетріал, постдрукарські роботи). Та може
бачити згенеровану ціну на продукцію. Також на формі присутня кнопка
“Добавить в корзину” яка переносить обрану продукцію до кошика для
подальшого її замовлення.
Також в інтерфейсі поряд з полем вибору матеріалу присутня кнопка
, яка переносить користувача до розширених відомостей про кожен
матеріал який наразі доступний для вибору.

Рис.23. Головне меню Рис.24. Меню вибору продукції

При натисканні кнопки “i”, відображається форма з переліком доступних
матеріалів (див. Рис. 25.), з фото. При натисканні на будь-якого з
матеріалів відкривається вся інформація про нього (див. Рис. 26.).

68
Рис.25. Перелік матеріалів Рис.26. Інформація про матеріали

При переході до кошика (див. Рис 27.), користувач баче всі замовлення які
він переніс до корзини при роботі з додатком, ці замовлення не зникають з
кошику навіть при виходу та входу до додатку.
Для видалення будь-якого замовлення потрібно зробити свайп в ліво, після
цього з’явиться червока кнопка “Delete”, при натисканні на яку,
замовлення буде видалено з кошика.

При натисканні на кнопку “Оформить заказ” відкривається форма

введення(“Оформление заказа”(див. Рис. 28.)), в яку користувач повинен
внести всі необхідні дані.
Якщо користувач вже зареєстрований у додатку, то всі його персональні
дані будуть автоматично відображатися у полях при оформленні
замовлення, що значно пришвидшує цей процес, користувачеві лишиться
тільки додати свої коментарі до замовлення, та посилання на макети для
друку).
При натисканні кнопки “Заказать” замовлення з кошику, та всі введені

69
користувачем дані, відправляютья на підприємство, користувачеві
лишаеться чекати, або доставки, або дзвінка менеджера якщо йому буде
потрібно уточнення деталей.

Рис.27. Кошик Рис.28. Оформлення замовлення

При переході до форми Аутентифікації, користувач баче поля Входу (див.
Рис. 29.), якщо користувач ще не маж профілю в додатку, при переході по
кнопці “Регистрация”, користувачеві відкривається форма введення даних
для реєстраці (див. Рис. 30.).
Після заповнення форми реєстрації на натискання кнопки
“Зарегестрироватся”, користувачеві потрібно підтвердити свою електронну
адресу, після чого користувач може виконати вхід та користуватися своїм
профілем.

70
 Рис.29. Вхід Рис.30. Реєстрація
Після входу до свого профілю користувач баче форму яка відображена на
рис. 31. Наявність профіля користувача надає такі привілеї:
• Перегляд історії замовлень та відстежування статусу замовлень
(пункт меню “Мои заказы”);
• Редагування персональних даних введених при реєстрації (пункт
меню “Редактировать профиль”);
• Онлайн підтримка у вигляді месенджеру (пункт меню “Онлайн
поддержка”);
При переході до пункту меню “Онлайн поддержка”, користувач баче
Форму “Сообщения” (див. Рис. 32.), де відображені вже активні чати з
менеджерами компації.
Для написання повідомлення менеджеру якого немає в скписку у формі
“Сообщения”, потрібно натиснути кнопку у парвому верхньому кутку та
обрати одного з менеджерів до якого користувачу потрібно звернутися.
Після вибору одного з менеджерів відкриється типова форма Чату (див.
Рис. 33.) з усією перепискою, текстовим полем для введення нового

71
повідомлення, та кнопкою для його відправлення.

Рис.31. Профіль Рис.32. “Сообщения” Рис.33. Переписка

3.7. Подальші дії

Далі процес розроблення наступних версій додатку виглядає таким

самим чином: спринти, наради та звіти замовнику, але з урахуванням
зворотного з’вязку від користувачів першої версії продукту яка вже
вийшла на ринок.

3.8. Розрахунок техніко-економічного ефекту для проекту виконаного

з використанням методології SCRUM

Після повного завершення проекту було проведено аналіз

ефективності розробки.
Економічний ефект – результативність економічної діяльності,
реалізації економічних програм та заходів, що характеризується
відношенням отриманого економічного ефекту (результату) до витрат
ресурсів, які зумовили отримання цього результату.
Техніко-економічний ефект від впровадження інформаційної
системи «Крос платформний мобільний додаток для замовлення
поліграфічної продукції підприємства ПП Авалон-прінт» визначається за

72
співвідношенням витрат та розробку системи, її завантаження до play
market та app store і прибутку від її впровадження, віднесеному на рік
експлуатації.
Тому перш ніж виконати розробку, потрібно прорахувати, який
економічний ефект від її впровадження.
Вихідні дані для розрахунку.
Система “Мобільний додаток для формування замовлень
поліграфічної продукції”
Узагальнені дані вхідної та вихідної інформації для системи
“Мобільний додаток для формування замовлень поліграфічної продукції”
за видами вхідної та вихідної інформації табл.3.
Таблиця 3. Узагальнені дані для вхідної та вихідної ІС.

Вид інформації Позна К-сть

-чення наборів
даних

Змінна інформація ЗІ m=4

Нормативно-довідкова інформація НДІ n=3

База даних БД p=1

Обробка в режимі реального часу РЧ Так

Забезпечення комунікації між ТОУ ні

клієнтом та сервером за допомогою
техногогії WEB SOCKET в реальному
часі

Витрати часу на систему призначену “Мобільний додаток для

формування замовлень поліграфічної продукції”, а саме на розробку
ескізного проекту T1 і технічного завдання T2, будуть наступні (табл. 4).

73
Таблиця 4. Визначення витрат часу

Вид системи Стадія розробки системи

Передпроектне Беклог
дослідження (SCRUM)

В В

Мобільний додаток для T1= 53 T2=42

формування замовлень
поліграфічної продукції

Визначається базове значення витрат часу для стадій "Технічний

проект", "Робочий проект" і "Впровадження". Для цього використовуються
дані для системи “Мобільний додаток для формування замовлень
поліграфічної продукції”.
Вхідними даними для визначення є:
- кількість форм вхідної інформації В1 = 2,
- кількість форм вихідної інформації В2 = 2,
- базове значення витрат часу для стадій "Планування спринту": 50;
- базове значення витрат часу для стадій "Спринти": 81;
- базове значення витрат часу для стадій "Впровадження": 31.
Базове значення витрат часу ТБ коригується за допомогою
поправочних коефіцієнтів для всіх стадій розробки автоматизованої
системи.
Розрахунок витрат часу для стадії “ Планування спринту ” (T3).
Коефіцієнт трудомісткості робіт kп визначається

0,824
і з врахуванням коефіцієнтів табл. 3:

74
Таблиця 5. Коефіцієнти k1, k2, k3 для стадії " Планування спринту ".

Вид використаної інформації Ступінь новизни

k1 (ЗІ) 1.0

k2 (НДІ) 0.72

k3 (БД) 2.08

Коефіцієнт ступеню новизни проекту, kО, що враховує вид обробки

інформації для трьох стадій розробки системи наведено в табл. 5.
Таблиця 6. Коефіцієнт ступеню новизни проекту, kO.

Стадія розробки Вид Ступінь новизни

системи обробки
В

Планування спринту РЧ 1.26

Спринти РЧ 1.32

Впровадження РЧ 1.21

Витрати часу для стадії “ Планування спринту ” T3 розраховуються

за формулою:

50*0,98*1,26 = 61.74
- Розрахунок витрат часу для стадії "Спринти" (T4) і "Впровадження"
(T5).
Для визначення витрат часу на стадії " Спринти "використовують
формулу

де kП – коефіцієнт, що враховує вид використаної інформації і

75
визначається за формулою:

0,827
Таблиця 7. Коефіцієнти k1, k2, k3 для стадії "Спринти".

Вид використаної Група Ступінь

інформації складності новизни
алгоритму
В

k1 (ЗІ) 2 1.1

k2 (НДІ) 2 0.58

k3 (БД) 2 0.48

Коефіцієнт, що враховує вид обробки інформації на стадії "Спринти"

1.16
Витрати часу Т4 вимірюються в людино-днях, розраховується:

81*0,827*1,21*1,16 = 94.02
Для стадії визначення загальних витрат часу на "Впровадження" Т5
(люд-днів) використовують формулу:

31*0,827*1,21*1,16 = 35.9
Таким чином, загальні витрати людської праці на проектування
системи складають:

53+42+123,5+94.02+35.9 = 348 (люд-дн).

Для дипломного проекту (випускової роботи) кількість робочих
годин складає 348 із 7-годинним робочим днем, тому на розробку проекту
виділено Ф, днів:

Для дипломного проекту Ф = 50 днів. Тоді визначаємо кількість

місяців із розрахунку 25 робочих днів.
76
 Кількість місяців на розробку, М:

Отже, для виконання такого проекту потрібно таку чисельність

виконавців Ч, виконавців, обраховується за формулою: 17.4

Якщо прийняти, що оплата програміста здійснюється в розмірі
15000грн, то оплата праці всіх виконавців складе:
7*2*15000 = 21000 грн.

Витрати, пов’язані з розробкою програми на ПК

Розрахунок річного фонду часу роботи ПК.
Дійсний річний фонд часу ПК у годинах дорівнює числу робочих
годин у році для оператора, за вийнятком часу на технічне обслуговування
і ремонт ПК (в середньому 5год/міс + 6 роб.днів/рік).

год.
Оскільки під час виконання дипломного проекту (роботи) студент в
середньому витрачає 450 год. машинного часу, то величина фонду часу ПК
дорівнює

год
Поточні витрати на експлуатацію V1" .
Балансова вартість ПК вираховується
грн
де ЦР – ринкова вартість ПК, орієнтовно складає 8000грн.,
kУН – коефіцієнт, що враховує витрати на установку і налагодження
ПК і дорівнює 0.12.
Амортизаційні відрахування використання ПК, ЗАМ, обчислюються

грн.
норма амортизаційних відрахувань, яка для ПК дорівнює НА = 5:

77
 Витрати на електроенергію, споживану ПК, визначаються

грн
де потужність ПК, РПК = 1.4 кВт,
фонд корисного часу роботи ПК, ТПК = 425.7 год,
вартість 1 кВт електроенергії для підприємств, ЦЕЛ = 1.74 грн/кВт,
коефіцієнт інтенсивного використання ПК, А = 0.9.
ЗР – витрати на поточний ремонт і технічне обслуговування ПК
визначаються як 6% від балансової вартості ПК, ЦПК.

грн.
ЗМАТ – непрямі витрати, пов’язані з експлуатацією ПК,
визначаються як 5% від балансової вартості ПК ЦПК.

грн.
Таким чином, маємо:
заробітна плата обслуговуючого персоналу (якщо роботи
виконуються не на власному ПК); ЗОП = 1680 грн, ЗАМ = 896 грн, ЗЕЛ =
113.41 грн,
Поточні витрати на експлуатацію V1", грн, визначаються

Отже, загальні витрати на розробку програмного забезпечення

комп’ютерної системи розраховуються за формулою і складуть:
грн.
Витрати на придбання і установку ПК V2.
На підприємстві є ПК, на якому буде працювати система, тому V2=0.
Витрати на підготовку приміщення V3.
Ці витрати залежать від стану приміщення, де буде встановлюватися
ПК. Так як пристосоване приміщення є, тому:

грн.
Витрати на навчання персоналу V4.
В середньому навчання персоналу триватиме 1 місяць, тому можна

78
вважати, що:

грн.
Загальна вартість розробки і впровадження системи.
Загальна вартість розробки і впровадження системи V∑,
вираховується за формулою:
грн.
Оскільки норма амортизаційних втрат для комп’ютерних систем НА
= 5, то для обрахування річного економічного ефекту слід брати до
розгляду величину формулою

грн.
Річний прибуток ПР від впровадження системи буде досягнуто за
рахунок впровадження додаткової інформаційноії системи на прикладі
різниці as-is і to-be і складає 20000 та 12500 грн за тиждень. Коефіцієнт
економічної ефективності розробки вираховується:
Прибуток від впровадження ІС за рік:
54* 7500 = 405.000грн

Термін окупності розробки визначається за формулою.

Таким чином, термін окупності інформаційної системи буде півтора роки.

ВИСНОВКИ ДО РОЗДІЛУ 3

1. Було розроблено мобільний додаток з використанням оптимальної

методології розробки визначеною розробленим графічним методом.

79
 2. Було створено беклог продукту, в який занесені усі задачі по
виконанню котрих, проект “Мобільний додаток для формування замовлень
поліграфічної продукції” має бути завершено.

3. Було створено перший спринт, тривалість якого становить два

тижні. По закінченню яких повинні бути виконані всі поставлені задачі.

4. Після завершення першого спринту пректу “Мобільний додаток

для формування замовлень поліграфічної продукції” було виконано всі
поставлені на цей спринт задачі, та реалізовано частину функціоналу
додатку які повинні бути в першій версії проекту.

5. Було створено другий спринт, тривалість якого становить два

тижні. По закінченню яких повинні бути виконані всі поставлені задачі.

6. Після завершення другого спринту пректу “Мобільний додаток

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

7. В результаті чотирох тижнів розробки (розділених на два

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

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

9. Після проведення розрахунку техніко-економічного ефекту, було

визначено, що термін окупності пректу “Мобільний додаток для
формування замовлень поліграфічної продукції” буде становитт півтора
року.

ВИСНОВКИ ДО РОБОТИ

1. В результаті проведеного дослідження було визначено, що:

Waterfall (Водоспадна модель) )передбачає послідовне проходження
процесу розробки, розбитого на етапи. Перехід до нового етапу можливий
81
тільки після завершення попереднього. Водоспадна модель дає відмінний
результат в проектах із заздалегідь визначеними вимогами і способами їх
реалізації, список вимог не можна скорегувати в процесі розробки.
Scrum - це противага класичному поетапного підходу, що
застосовується до реалізації проектів. .Важливими характеристиками
Scrum є її гнучкість і орієнтованість на клієнта, так як вона передбачає
його (клієнта) безпосередню участь в процесі роботи.
2. Було визначено критерії для порівняння та визначення придатності
конкретної методології для виконання конкретного проекту з урахуванням
вимог компанії замовника. А саме: Технічні ризики; Термін поставки;
Вимоги; Бюджет; Участь замовника; Проектні ризики.
3. Зроблено висновок, що каскадна методика розробки дозволяє краще
документувати, але до закінчення розробки мобільний додаток не працює,
що не дає змогу відразу отримувати зворотній зв’язок від користувачів, а
також не дає можливості почати замовнику раніше за конкурентів займати
ринок у своїй сфері діяльності.
4. Гнучка ж методологія дозволяє запустити мобільний додаток на
ринок в найкоротші терміни, і продовжувати розробляти додаток з
урахуванням зворотного зв'язку користувачів, що в кінцевому результаті
покращує якість додатку, робить його більш клієнтоорієнтованим, а також
дозволяє почати отримувати з нього прибуток, набагато раніше ніж це
можливо у Waterfall.
5. Було визначено оптимальну методологію для проекту «Мобільний
додаток для формування замовлень поліграфічної продукції» організації
ПП «Авалон-прінт”. А саме: SCRUM.
6. Після проведення розрахунку техніко-економічного ефекту, було
визначено, що термін окупності пректу “Мобільний додаток для
формування замовлень поліграфічної продукції” буде становити півтора
роки.

82
 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Каскадна модель життєвого циклу розробки ПО - Вершиніна Е.В.,

Гонченко М.С. http://ukrdoc.com.ua/text/7830/index-1.html?page=2.
2. ДОДАТОК А - Галузева система управління якістю
http://ua.convdocs.org/docs/index-131570.html?page=7.
3. Автоматизована система управління відділом експлуатації
автобусного парку http://revolution.allbest.ru/programming/00554173_0.html.
4. Короткий опис фаз каскадної моделі - реферати та учбові матеріали
на um.co.ua http://um.co.ua/8/8-11/8-118522.html.
5. IBM Rational Unified Process (RUP) | ЕasyСode http://easy-
code.com.ua/2010/11/ibm-rational-unified-process-rup/.
6. Технологии разработки программного обеспечения - "Студенточка"
http://tema.studentochka.ru/25933.html.
7. Учебно-методический комплекс по дисциплине проектирование
информационных систем - страница 7 http://urf.podelise.ru/docs/2653/index-
13478.html?page=7.
8. Scrum http://moyaosvita.com.ua/menedzhment/scrum/.
9. информационные технологии http://eprints.kname.edu.ua/45507/4/Ч. 4
- туризм, информационные технологии.pdf.
10. David Mark, James Bucanek. Learn C on the Mac 2nd Edition
11. Jack Nutting, Jeff LaMarche, Fredrik Olsson. Beginning iOS 6
Development
12. David Mark, Alex Horovitz, Kevin Kim, Jeff LaMarche. More iOS 9
Development
13. http://swiftbook.ru/doc - не офіційна документація по мові
прорграмування Swift, та середовищі розробки Xcode.
14. https://firebase.google.com/docs/ - офіційна документація по Firebase
та БД Realtime Database.
9.https://developer.apple.com/library/content/documentation/Swift/Conceptual/S
83
wift_Programming_Language/ - офіційна документація від компанії Apple по
мові програмування Swift.
15. Інформаційно-обчислювальні комплекси та АСУ: Методичні
рекомендації до виконання лабораторних робіт для студентів напряму
підготовки 6.050101 „Комп'ютерні науки” усіх форм навч./Уклад.: О.А.
Хлобистова, М.В. Гладка, К.Є. Бобрівник. – К.: НУХТ, 2012. – 83 с.
16. Кодекс законів про працю України [Електронний ресурс] // Режим
доступу: http://zakon.rada.gov.ua/cgi-bin/laws/main.cgi?nreg=322-08.
17. Основні напрямки розвитку науково-технічного прогресу
[Електронний ресурс]: Офіц. Стаття від 21. 12. 2009 р., - Режим доступу :
http://www.refine.org.ua/pageid-1402-1.html.
18. Стаття з поліграфічного виробництва [Текст]: Із історії
поліграфічного виробництва //Полиграфист и издатель. - 2000. - No 11. - C.
87- 94.
19. Ушакова І.О. Системний аналіз та проектування систем обробки
інформації. – Харків: Вид. ХДЕУ, 2004. – 164 с.
20. Гибкая методология разработки. М.: Изд. «Русская Редакция». 2008г.
127с.
21. Павлов В.Л., Жереб К. А., Дорошенко А. Е., Сергиенко В. И. Метод
обратной семантической трассировки для контроля качества в гибкой
разработке программных проектов в . Электронный ресурс. [Режим
доступа]: http://dspace.nbuv.gov.ua/xmlui/bitstream/handle/123456789/145
5/27%20-%20Pavlov.pdf?sequence=1.
22. Тестирование. Фундаментальная теория. Часть 2— Методологии
23. Вольфсон Б. М.Гибкие методологии разработки.: Изд. «Русская
Редакция». 2014 г. 112с.
24. Пушкарев А. Гибкая методология разработки “Scrum”. Электронный
ресурс. [Режим доступа]:https://habrahabr.ru/post/247319/
25. Гибкая методология разработки (Agile). Электронный ресурс.
[Режим доступа]: http://mahamba.com/ru/gibkaya-metodologiya-razrabotki-
agile
84
26. Ясенитская А. AGILE.Электронный ресурс. [Режим
доступа]:https://vc.ru/p/agile-victims.
27. AGILE. Гибкая технология разработки.Электронный ресурс. [Режим
доступа]:Источник: http://hbr-russia.ru/management/operatsionnoe-
upravlenie/p17368/#ixzz4f5EzdY1l.
28. Arbi Ghazarian. Reliability in Agile Software Engineering: A
Dilemma.Электронный ресурс. [Режим
доступа]:http://paris.utdallas.edu/IEEE-RS- ATR/document/2010/10-Reliability
%20in%20Agile%20Software%20Engineering_Ghazarian.pdf.
29. Алгазинов, Э.К. Анализ и компьютерное моделирование
информационных процессов и систем: учебное пособие / Э.К.
30. Алгазинов, А.А. Сирота. – М.: ДИАЛОГ-МИФИ, 2009 – 416c.
31. Арский Ю.М.Инфосфера: Информационные структуры, системы и
процессы в науке и обществе / Ю.М.Арский, Р.С.Гиляревский,
32. И.С.Туров, А.И.Чёрный– М.: ВИНИТИ, 1996 – 489 с.
33. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство
пользователя. -М.: ДМК Пресс, 2001.

85