Водоспадна модель

Водоспадна (каскадна^[1]) модель життєвого циклу ПЗ (англ. waterfall model) — послідовний метод розробки програмного забезпечення, названий так через діаграму, схожу на водоспад (як на ілюстрації справа).

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

Ця модель розробки запозичена з системної інженерії у виробництві та будівництві — областях, в яких зміни на пізніх етапах дуже дорогі або неможливі.^[2] Наприклад, для створення складних інженерних конструкцій (споруд, літаків, мостів тощо). Зміни в проекті фундаменту будинку після того, як покладений дах, коштують дуже дорого, тому перфекціонізм на початкових етапах проектування просто необхідний. Інженери, які починали займатись розробкою програмного забезпечення, перейшовши з інших галузей, просто адаптували звичну модель, тому що на ранніх етапах розвитку комп'ютерної техніки не було методологій, створених саме для програмування.^[2] Проте схожі методології застосовуються для програмного забезпечення й далі у випадках, коли вимоги фіксовані і вимагається висока якість та надійність, наприклад, у системах для військових чи медичних потреб^[3].

Перший формальний опис водоспадної моделі, після якої вона стала популярною, був здійснений В. В. Ройсом у 1970^[4]. Попри те, що стаття містить переважно критику методу, на неї часто посилаються.

Принципова особливість водоспадної (каскадної) моделі — перехід на наступну стадію здійснюється тільки після повного завершення роботи на поточній стадії, повернення на пройдені стадії не передбачається. Кожна стадія закінчується одержанням результатів, що є вхідними даними для наступної стадії, та випуском повного комплекту документації. Вимоги до програмного забезпечення, визначені на стадії формування вимог, документуються у вигляді технічного завдання і фіксуються на весь час розроблення. Критерієм якості розробки за такої моделі є точність виконання специфікацій технічного завдання^{[джерело?]}.

Плюси методу

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

Мінуси

• Необхідно досягати досконалості на кожному етапі;
• може бути складно вносити зміни (якщо взагалі можливо);
• надлишкове проєктування;
• Поділ розробників на «perfect» та «code monkeys».

Модифікації

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

Найвідоміша модифікація — Sashimi. Названа так через японську страву сашимі (суші нарізане і сервіроване так, що складені рядочком шматочки накладаються один на одного). В моделі розробки Сашимі фази життєвого циклу йдуть одна за одною, але при цьому перекривають одна одну в часі.^[5]