Модель водоспаду була першою представленою моделлю процесу розробки програмного забезпечення. Її також називають моделлю лінійно-послідовного життєвого циклу . Його дуже просто зрозуміти та використовувати. У моделі водоспаду кожна фаза має бути завершена до початку наступної фази.
Модель водоспаду ілюструє процес розробки програмного забезпечення в лінійному послідовному потоці. Це означає, що будь-яка фаза процесу розробки починається лише тоді, коли попередня фаза завершена. У моделі водоспаду фази не накладаються одна на одну.
Модель водоспаду – стадії
У моделі водоспаду весь процес розробки програмного забезпечення ділиться на окремі етапи. У цій моделі, як правило, результат однієї фази виступає в якості входу для наступної послідовної фази.
Виділяють наступні стадії: збір і аналіз вимог, проєктування системи, розробка, інтерграція та тестування, рогортання системи, технічне обслуговування.
Збір і аналіз вимог – Усі можливі вимоги до системи, яка буде розроблена, фіксуються на цьому етапі та документуються в документі специфікації вимог.
Проєктування системи – специфікації вимог з першого етапу вивчаються на цьому етапі та готується проєкт системи. Цей проєкт допомагає визначити апаратні та системні вимоги, а також допомагає визначити загальну архітектуру системи.
Розробка. За допомогою вхідних даних проєктування системи система спочатку розробляється в невеликих програмах, які називаються модулями, які інтегруються на наступному етапі. Кожен блок розробляється та перевіряється на його функціональність, що називається модульним тестуванням.
Інтеграція та тестування – усі блоки, розроблені на етапі розробки, інтегруються в систему після тестування кожного блоку. Після інтеграції вся система перевіряється на наявність помилок та збоїв.
Розгортання системи − після завершення функціонального та нефункціонального тестування; продукт розгортається в середовищі клієнта або випускається на ринок.
Технічне обслуговування – у клієнтському середовищі можуть виникати певні проблеми. Для вирішення цих проблем випускаються патчі. Крім того, для вдосконалення продукту може бути випущено кілька кращих версій. Технічне обслуговування виконується для внесення цих змін у клієнтське середовище.
Усі ці фази розташовуються каскадом одна до одної, у якій прогрес розглядається як постійний рух вниз (як водоспад) через фази. Наступна фаза починається лише після того, як визначений набір цілей досягнуто для попередньої фази, і вона підписана, звідси і назва “Модель водоспаду”.
Модель водоспаду – застосування
Кожне розроблене програмне забезпечення має свої особливості і вимагає відповідного підходу SDLC, який слід застосовувати на основі внутрішніх і зовнішніх факторів.
Деякі ситуації, коли використання моделі Waterfall є найбільш прийнятним:
- Вимоги дуже добре задокументовані, чіткі та фіксовані.
- Визначення продукту стабільне.
- Технологія зрозуміла і не є динамічною.
- Немає неоднозначних вимог.
- Доступні достатні ресурси з необхідним досвідом для підтримки продукту.
Модель водоспаду – переваги
Можна встановити графік із кінцевими термінами для кожного етапу розробки, і продукт може проходити через етапи моделі процесу розробки одну за одною.
Розробка проходить від концепції до проєктування, впровадження, тестування, інсталяції, усунення несправностей і закінчується експлуатацією та обслуговуванням. Кожна фаза розвитку протікає в чітко визначеному порядку.
Деякі з основних переваг моделі водоспаду такі:
- Проста і легка для розуміння та використання
- Легко керувати завдяки жорсткості моделі. Кожен етап має конкретні результати та процес перевірки.
- Фази обробляються та завершуються одна за одною.
- Чітко визначені етапи.
- Легко призначати завдання. Процес і результати добре задокументовані.
Модель водоспаду – недоліки
Недоліком моделі водоспаду є те, що вона не допускає можливості переглядів та внесення змін. Коли програма перебуває на стадії тестування, дуже важко повернутися назад і змінити щось, що не було добре задокументовано або продумано на стадії концепції.
Основні недоліки моделі водоспаду такі:
- Не дуже хороша модель для сучасних проєктів, які потребують гнучкості
- Не підходить для проектів, де вимоги мають помірний або високий ризик зміни. Таким чином, ризик і невизначеність є високими з цією моделлю процесу.
- Неможливо задовольнити мінливі вимоги.
- Інтеграція зазвичай виконується як “великий вибух” наприкінці проєкту, що ускладнює виявлення можливих проблем (збоїв, дефектів).