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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
Водоспадний метод розробки. Процес проходить всі стадії послідовно, як вода в водоспаді
ТРПЗ
Цикл розробки програмного забезпечення
Coding Shots Annual Plan high res-5.jpg
Програміст за роботою
Діяльність та кроки
Вимоги • Специфікація • Архітектура • Дизайн • Реалізація • Тестування • Розгортання (Реліз) • Супровід
Методології • Процес
Гнучка • Чистого приміщення • DSDM • Ітеративна • RAD • RUP • Спіраль • Водоспад • XP • Scrum • Lean • V-Model • FDD • TDD • BDD
Допоміжні дисципліни
Керування конфігурацією • Документування • Якість ПЗ • Управління проектами • Досвід користування
Інструменти
Компілятор • Зневаджувач • Профілювальник • GUI designer • IDE

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

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

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

Плюси методу[ред.ред. код]

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

Мінуси[ред.ред. код]

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

Модифікації[ред.ред. код]

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

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

Примітки[ред.ред. код]

  1. Лаврищева, Катерина Михаліївна. 2.3.1 каскадна модель. Програмна інженерія (укр). Київ: ВПЦ «Київський унiверситет». Процитовано 4 жовтня 2015. 
  2. а б Benington, Herbert D. (1 October 1983). Production of Large Computer Programs. IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Процитовано 2011-03-21. 
  3. What are names of successful projects using the waterfall model? Quora
  4. Royce, Winston (1970), «Managing the Development of Large Software Systems»
  5. http://blog.3back.com/development/sashimi-method-building-software/

Джерела[ред.ред. код]