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

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

Водоспадний метод розробки. Процес проходить всі стадії послідовно, як вода в водоспаді
Технологія розробки програмного забезпечення
Цикл розробки програмного забезпечення
Програміст за роботою
Діяльність і кроки
Допоміжні дисципліни
Практики
Інструменти
Стандарти та галузі знань

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

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

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

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

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

Модифікації

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

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

Примітки
  1. Лаврищева, Катерина Михаліївна. 2.3.1 каскадна модель. Програмна інженерія (укр). Київ: ВПЦ «Київський унiверситет». Архів оригіналу за 26 лютого 2012. Процитовано 4 жовтня 2015.
  2. Benington, Herbert D. (1 жовтня 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. Архів оригіналу за 18 липня 2011. Процитовано 21 березня 2011.
  3. What are names of successful projects using the waterfall model? Quora
  4. Royce, Winston (1970), «Managing the Development of Large Software Systems» Архівовано 15 березня 2016 у Wayback Machine.
  5. http://blog.3back.com/development/sashimi-method-building-software/

Джерела
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.