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

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

Плюси і мінуси каскадної моделі:

+ Повне документування кожного етапу;

+ Чітке планування термінів і витрат;

+ Прозорість процесів для замовника;

– Необхідність затвердження повного обсягу вимог до системи ще на першому етапі;

– У разі необхідності внесення змін до вимог пізніше – повернення до першої стадії та переробка заново всієї виконаної роботи;

– Збільшення витрат коштів та часу в разі потреби змінити вимоги.

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

Коли варто використовувати каскадну модель:

– У проектах з чітко визначеними вимогами, для яких не передбачається зміна цих вимог в процесі розробки;

– Для проектів, які мігрують з однієї платформи на іншу. Тобто, вимоги залишаються ті ж, міняється лише системне оточення та/або мова програмування;

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