Waterfall – Каскадна модель

1. Влаштування каскадної моделі

Каскадна модель, відома також як Waterfall (водоспад) – один із найбільш відомих підходів до розробки ПЗ. Автором моделі є Вінстон Ройс. У 1970 році він описав суть своєї інновації у статті з докладним викладом її переваг та недоліків. Там він пояснив, як цю модель можна доопрацювати до ітеративної моделі. Спочатку в каскадній моделі стадії розробки йдуть у такому порядку:

• Визначення та узгодження вимог;
• Затвердження проєкту;
• Кодування;
• Створення робочої версії програмного продукту;
• Тестування та налагодження;
• Установлення ПЗ;
• Підтримка.

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

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

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

На наступному етапі відбувається тестування та налагодження продукту. Тут усуваються раніше виявлені помилки.

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

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

2. Плюси і мінуси

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

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

Незважаючи на недоліки, у PMBOK третьої версії формально вказана лише методика "каскадної моделі". Інші варіанти, зокрема, ітеративне ведення проєктів, у ній не пропонуються.

Переваги каскадної моделі:

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

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

• Оскільки тестування стартує на етапі завершення розробки, при виявленні бага його виправлення обійдеться дорожче, ніж на початковому етапі. Адже тестувальники знайдуть помилку лише тоді, коли розробник уже закінчив написання коду, а копірайтери — документацію.
• Замовник знайомиться із готовим продуктом після завершення розробки. Відповідно, він може оцінити продукт лише тоді, коли він майже повністю готовий. Якщо результат йому не сподобається, вартість бюджету проєкту помітно збільшиться через потребу у виправленні.
• Чим більше технічної документації – тим довше до завершення роботи. Така документація потребує більше змін та погоджень.

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

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