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

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

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