Технології розробки програмного забезпечення
Життєвий цикл програмного забезпечення (ПО) — період, який починається з прийняття рішення про необхідність створення програмного продукту і закінчується у його повного вилучення з эксплуатации[1]. Цей цикл - процес побудови та розвитку ПЗ.
Водоспадна (каскадна, послідовна) модель
Водоспадна модель життєвого циклу (англ. waterfall model) була запропонована в 1970 Уінстоном Ройсом. Вона передбачає послідовне виконання всіх етапів проекту у строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі. Вимоги, визначені на стадії формування вимог, суворо документуються як технічного завдання і фіксуються весь час розробки проекту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб технологія могла бути продовжена іншою командою розробників.
Етапи проекту відповідно до каскадної моделі:
формування вимог; Проектування; Реалізація; Тестування; Впровадження; Експлуатація та супровід.
Повна та узгоджена документація на кожному етапі; Легко визначити терміни та витрати на проект.
Ітераційна модель
Альтернативою послідовної моделі є так звана модель ітеративної та інкрементальної розробки (англ. iterative and incremental development, IID), що отримала також від Т. Гілба у 70-ті роки. назва еволюційної моделі Також цю модель називають ітеративною моделлю та інкрементальною моделлю [4].
За словами Т. Гілба, «еволюція — прийом, призначений до створення видимості стабільності. Шанси успішного створення складної системи будуть максимальними, якщо вона реалізується в серії невеликих кроків і якщо коженкрок містить чітко певний успіх, а також можливість «відкату» до попереднього успішного етапу у разі невдачі. Перед тим, як пустити в справу всі ресурси, призначені для створення системи, розробник має можливість отримувати з світу сигнали зворотний зв'язок і виправляти можливі помилки у проекте»[4].
Підхід IID має і свої негативні сторони, які, по суті, – зворотний бік переваг. По-перше, цілісне розуміння можливостей та обмежень проекту дуже довгий час відсутнє. По-друге, за ітерацій доводиться відкидати частину зробленої раніше роботи. По-третє, сумлінність фахівців під час виконання робіт все-таки знижується, що психологічно зрозуміло, адже над ними постійно тяжіє відчуття, що «все одно все можна буде переробити і поліпшити пізніше»[3].
Різні варіанти ітераційного підходу реалізовані у більшості сучасних методологій розробки (RUP, MSF, XP).
Спіральна модель
Спіральна модель (англ. spiral model) була розроблена в середині 1980-х Баррі Боемом. Вона ґрунтується на класичному циклі Демінга PDCA (plan-do-check-act). При використанні цієї моделі програмне забезпечення створюється в кілька ітерацій (витків спіралі) методом прототипування.
Кожна ітерація відповідає створенню фрагмента або версії ПЗ, на ній уточнюються цілі та характеристики проекту, оцінюється якість отриманих результатів та плануються роботи наступної ітерації.
На кожній ітерації оцінюються:
ризик перевищення термінів та вартості проекту; необхідність виконання ще однієї ітерації; ступінь повноти та точності розуміння вимог до системи; доцільність припинення проекту.
Важливо розуміти, що спіральна модель не є альтернативою еволюційної моделі.(моделі IID), а спеціально опрацьованим варіантом. На жаль, нерідко спіральну модель або хибно використовують як синонім еволюційної моделі взагалі, або (не менш хибно) згадують як цілком самостійну модель поряд з IID [3].
Відмінною особливістю спіральної моделі є спеціальна увага, що приділяється ризикам, що впливають на організацію життєвого циклу, та контрольним точкам. Боем формулює 10 найбільш поширених (за пріоритетами) ризиків:
Дефіцит спеціалістів. Нереалістичні терміни та бюджет. Реалізація невідповідної функціональності. Розробка неправильного інтерфейсу користувача. Перфекціонізм, непотрібна оптимізація та відточування деталей. Неперервний потік змін. Брак інформації про зовнішні компоненти, що визначають оточення системи або залучені в інтеграцію. Недоліки у роботах, що виконуються зовнішніми (стосовно проекту) ресурсами. Недостатня продуктивність одержуваної системи.
Розрив у кваліфікації спеціалістів різних областей.
У сьогоднішній спіральній моделі визначено наступний загальний набір контрольних точок [5]: