Водоспадна (каскадна) модель життєвого циклу ПЗ () — послідовний метод розробки програмного забезпечення, названий так через діаграму, схожу на водоспад (як на ілюстрації справа).
Ця модель розробки запозичена з системної інженерії у виробництві та будівництві — областях, в яких зміни на пізніх етапах дуже дорогі або неможливі. Наприклад, для створення складних інженерних конструкцій (споруд, літаків, мостів тощо). Зміни в проекті фундаменту будинку після того, як покладений дах, коштують дуже дорого, тому перфекціонізм на початкових етапах проектування просто необхідний. Інженери, які починали займатись розробкою програмного забезпечення, перейшовши з інших галузей, просто адаптували звичну модель, тому що на ранніх етапах розвитку комп'ютерної техніки не було методологій, створених саме для програмування. Проте схожі методології застосовуються для програмного забезпечення й далі у випадках, коли вимоги фіксовані і вимагається висока якість та надійність, наприклад, у системах для військових чи медичних потребWhat are names of successful projects using the waterfall model? Quora.
Перший формальний опис водоспадної моделі, після якої вона стала популярною, був здійснений В. В. Ройсом у 1970Royce, Winston (1970), «Managing the Development of Large Software Systems» . Попри те, що стаття містить переважно критику методу, на неї часто посилаються.
Принципова особливість водоспадної (каскадної) моделі — перехід на наступну стадію здійснюється тільки після повного завершення роботи на поточній стадії, повернення на пройдені стадії не передбачається. Кожна стадія закінчується одержанням результатів, що є вхідними даними для наступної стадії, та випуском повного комплекту документації. Вимоги до програмного забезпечення, визначені на стадії формування вимог, документуються у вигляді технічного завдання і фіксуються на весь час розроблення. Критерієм якості розробки за такої моделі є точність виконання специфікацій технічного завдання.
Плюси методу Ніяких, або майже ніяких переробок; гарна специфікація здебільшого перетікає в гарну документацію; зрозуміла модель; програмісти можуть мати низьку кваліфікацію.
Мінуси Необхідно досягати досконалості на кожному етапі; може бути складно вносити зміни (якщо взагалі можливо); надлишкове проєктування; Поділ розробників на «perfect» та «code monkeys».
Модифікації Через те, що цей метод погано підходить для розробки саме ПЗ, частіше використовують його модифікації.
Найвідоміша модифікація — Sashimi. Названа так через японську страву сашимі (суші нарізане і сервіроване так, що складені рядочком шматочки накладаються один на одного). В моделі розробки Сашимі фази життєвого циклу йдуть одна за одною, але при цьому перекривають одна одну в часі.
Примітки
Джерела