Водоспадна модель
Водоспадна (каскадна[1]) модель життєвого циклу ПЗ (англ. waterfall model) — послідовний метод розробки програмного забезпечення, названий так через діаграму, схожу на водоспад (як на ілюстрації справа).
Ця модель розробки запозичена з системної інженерії у виробництві та будівництві — областях, в яких зміни на пізніх етапах дуже дорогі або неможливі.[2] Наприклад, для створення складних інженерних конструкцій (споруд, літаків, мостів тощо). Зміни в проекті фундаменту будинку після того, як покладений дах, коштують дуже дорого, тому перфекціонізм на початкових етапах проектування просто необхідний. Інженери, які починали займатись розробкою програмного забезпечення, перейшовши з інших галузей, просто адаптували звичну модель, тому що на ранніх етапах розвитку комп'ютерної техніки не було методологій, створених саме для програмування.[2] Проте схожі методології застосовуються для програмного забезпечення й далі у випадках, коли вимоги фіксовані і вимагається висока якість та надійність, наприклад, у системах для військових чи медичних потреб[3].
Перший формальний опис водоспадної моделі, після якої вона стала популярною, був здійснений В. В. Ройсом у 1970[4]. Попри те, що стаття містить переважно критику методу, на неї часто посилаються.
Принципова особливість водоспадної (каскадної) моделі — перехід на наступну стадію здійснюється тільки після повного завершення роботи на поточній стадії, повернення на пройдені стадії не передбачається. Кожна стадія закінчується одержанням результатів, що є вхідними даними для наступної стадії, та випуском повного комплекту документації. Вимоги до програмного забезпечення, визначені на стадії формування вимог, документуються у вигляді технічного завдання і фіксуються на весь час розроблення. Критерієм якості розробки за такої моделі є точність виконання специфікацій технічного завдання[джерело?].
Плюси методу ред.
- Ніяких, або майже ніяких переробок;
- гарна специфікація здебільшого перетікає в гарну документацію;
- зрозуміла модель;
- програмісти можуть мати низьку кваліфікацію.
Мінуси ред.
- Необхідно досягати досконалості на кожному етапі;
- може бути складно вносити зміни (якщо взагалі можливо);
- надлишкове проєктування;
- Поділ розробників на «perfect» та «code monkeys».
Модифікації ред.
Через те, що цей метод погано підходить для розробки саме ПЗ, частіше використовують його модифікації.
Найвідоміша модифікація — Sashimi. Названа так через японську страву сашимі (суші нарізане і сервіроване так, що складені рядочком шматочки накладаються один на одного). В моделі розробки Сашимі фази життєвого циклу йдуть одна за одною, але при цьому перекривають одна одну в часі.[5]
Примітки ред.
- ↑ Лаврищева, Катерина Михаліївна. 2.3.1 каскадна модель. Програмна інженерія (укр) . Київ: ВПЦ «Київський університет». Архів оригіналу за 26 лютого 2012. Процитовано 4 жовтня 2015.
- ↑ а б Benington, Herbert D. (1 жовтня 1983). Production of Large Computer Programs (PDF). IEEE Annals of the History of Computing. IEEE Educational Activities Department. 5 (4): 350—361. doi:10.1109/MAHC.1983.10102. Архів оригіналу (PDF) за 18 липня 2011. Процитовано 21 березня 2011.
- ↑ What are names of successful projects using the waterfall model? Quora
- ↑ Royce, Winston (1970), «Managing the Development of Large Software Systems» [Архівовано 15 березня 2016 у Wayback Machine.]
- ↑ Архівована копія. Архів оригіналу за 29 липня 2016. Процитовано 15 червня 2016.
{{cite web}}: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання)
Джерела ред.
- Дацко М., Семенів Г. Аналіз моделей життєвого циклу проектів галузі інформаційних технологій // Формування ринкової економіки в Україні. — № 18-2008. — С. 63-69.
| Ця стаття потребує додаткових посилань на джерела для поліпшення її перевірності. (січень 2018) |
