Процес розробки програмного забезпечення

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

Етапи проєкту у відповідності з каскадною моделлю:

1. Формування вимог;
2. Проєктування;
3. Реалізація;
4. Тестування;
5. Впровадження;
6. Експлуатація та супровід.

Переваги

• Повна і погоджена документація на кожному етапі;
• Легко визначити терміни і витрати на проєкт.

Недоліки

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

Альтернативою послідовної моделі є так звана модель ітеративної та інкрементальної розробки (англ. iterative and incremental development, IID), отримала також від Т. Ґілба в 1970-ті назву еволюційної моделі. Також цю модель називають ітеративною та інкрементальною моделлю[3].

Модель IID передбачає розбиття життєвого циклу проєкту на послідовність ітерацій, кожна з яких нагадує «міні-проєкт», включаючи всі процеси розробки в застосуванні до створення менших фрагментів функціональності, порівняно з проєктом в цілому. Мета кожної ітерації — отримання версії програмної системи, що працює та включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерації. Результат фінальної ітерації містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт отримує приріст — інкремент — до його можливостей, які, отже, розвиваються еволюційно. Ітеративність, інкрементальність і еволюційність в даному випадку є вислів одного і того ж сенсу різними словами зі злегка різних точок зору[2].

За висловом Ґілба, «еволюція — прийом, призначений для створення видимості стабільності. Шанси успішного створення складної системи будуть максимальними, якщо вона реалізується у серії невеликих кроків і якщо кожен крок містить у собі чітко визначений успіх, а також можливість „відкату“ до попереднього успішного етапу в разі невдачі. Перед тим, як пустити в справу всі ресурси, призначені для створення системи, розробник має можливість одержувати з реального світу сигнали зворотного зв'язку і виправляти можливі помилки в проєкті»[3].

Підхід IID має і свої негативні сторони, які, по суті, — зворотній бік чеснот. По-перше, цілісне розуміння можливостей і обмежень проєкту дуже довгий час відсутнє. По-друге, при ітераціях доводиться відкидати частину раніше зробленої роботи. По-третє, сумлінність фахівців при виконанні робіт все ж знижується, що психологічно зрозуміло, адже над ними постійно тяжіє відчуття, що «все одно все можна буде переробити і поліпшити пізніше»[2].

Різні варіанти ітераційного підходу реалізовані в більшості сучасних методологій розробки (RUP, MSF, XP).

Спіральна модель (англ. spiral model) була розроблена в середині 1980-х років Баррі Боэмом. Вона заснована на класичному циклі Демінга PDCA (plan-do-check-act). При використанні цієї моделі ЗА створюється в кілька ітерацій (витків спіралі) методом прототипування.

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

На кожній ітерації оцінюються:

• ризик перевищення строків і вартості проєкту;
• необхідність виконання ще однієї ітерації;
• ступінь повноти і точності розуміння вимог до системи;
• доцільність припинення проєкту.

Важливо розуміти, що спіральна модель є не альтернативою еволюційної моделі (моделі IID), а спеціально опрацьованим варіантом. На жаль, нерідко спіральну модель або помилково використовують як синонім еволюційної моделі взагалі, або (не менш помилково) згадують як абсолютно самостійну модель поряд з IID[2].

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

1. Дефіцит фахівців.
2. Нереалістичні терміни і бюджет.
3. Реалізація не відповідає функціональності.
4. Розробка неправильного користувальницького інтерфейсу.
5. Перфекціонізм, непотрібна оптимізація та покращення деталей.
6. Безперервний потік змін.
7. Брак інформації про зовнішні компоненти, що визначають оточення системи або залучених в інтеграцію.
8. Недоліки в роботах, що виконуються зовнішніми (стосовно проєкту) ресурсами.
9. Недостатня продуктивність одержуваної системи.
10. Розрив у кваліфікації фахівців різних областей.

У сьогоднішній спіральної моделі визначено наступний загальний набір контрольних точок[4]:

1. Concept of Operations (COO) — концепція (використання) системи;
2. Life Cycle Objectives (LCO) — цілі і зміст життєвого циклу;
3. Life Cycle Architecture (LCA) — архітектура життєвого циклу; тут можливо говорити про готовність концептуальної архітектури цільової програмної системи;
4. Initial Operational Capability (IOC) — перша версія створюваного продукту, придатна для дослідної експлуатації;
5. Final Operational Capability (FOC) — готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації.