База знань

Каскадна модель (Waterfall model)

waterfall

Одного разу, на зорі епохи програмування, єдиними учасниками процесу розробки були програмісти. Вони писали програмні функції для полегшення математичних розрахунків або автоматизації інших рутинних дій. Сьогодні все інакше. Сучасні системи настільки великі і складні, що над їх створенням трудяться цілі команди фахівців різного профілю: програмісти, аналітики, системні адміністратори, тестувальники і кінцеві користувачі. Усі вони працюють разом для розробки програм, що містять мільйони рядків коду. Першою моделлю, що отримала широку популярність і справді структурує процес розробки, є каскадна або водоспадна. Вона була створена після минулої в 1968 р конференції NATO з питань науки і техніки, де розглядалися такі питання, і розділяє процес створення програмного продукту на послідовні етапи (слід зазначити, що вона вже застосовувалася тоді різними розробниками, однак ні кількість, ні зміст етапів не Уніфікований).

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

Життєвий цикл розробки ПЗ традиційно поділяють на такі основні етапи:

  1. Аналіз вимог
  2. Проектування
  3. Розробка
  4. Тестування та налагодження
  5. Експлуатація та супровід

Через деякий час після своєї появи на світ каскадна модель була доопрацьована Уінстом Ройсом з урахуванням взаємозалежності етапів і необхідності повернення на попередні ступені, що може бути викликано, наприклад, неповнотою вимог або помилками в формуванні завдання. У такому «оборотному» вигляді каскадна модель або «вир» проіснувала довгий час і стала основою для багатьох проектів.

Переваги моделі:

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

Каскадна модель добре зарекомендувала себе при побудові  простого ПЗ, коли на самому початку розробки можна досить точно і повно сформулювати всі вимоги до продукту.

Недоліки моделі:

  • складність чіткого формулювання вимог і неможливість їх динамічної зміни протягом  повного життєвого циклу розробки ПЗ;
  • низька гнучкість в управлінні проектом;
  • послідовність лінійної структури процесу розробки, де  повернення до попередніх кроків для вирішення виникаючих проблем призводить до збільшення витрат і порушення графіка робіт;
  • непридатність проміжного продукту для використання;
  • неможливість гнучкого моделювання унікальних систем;
  • пізнє виявлення проблем, пов’язаних зі складанням, в зв’язку з одночасною інтеграцією всіх результатів в кінці розробки;
  • недостатня участь користувача в створенні системи – на самому початку (при розробці вимог) і в кінці (під час приймальних випробувань);
  • користувачі не можуть переконатися в якості продукту, що розробляється до закінчення всього процесу розробки. Вони не мають можливості оцінити якість, оскільки не можна побачити готовий продукт розробки;
  • у користувача немає можливості поступово звикнути до системи;
  • процес навчання відбувається в кінці життєвого циклу, коли ПЗ вже запущено в експлуатацію;
  • кожна фаза є передумовою для виконання наступних дій, що перетворює такий метод в ризикований вибір для систем, які не мають аналогів, тому що він не піддається гнучкому моделюванню. 

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

Область застосування Каскадної моделі

Обмеження області застосування каскадної моделі визначається її недоліками. Її використання найбільш ефективно в наступних випадках:

  1. при розробці проектів з чіткими, незмінними протягом життєвого циклу вимогами, зрозумілими реалізацією і технічними методиками;
  2. при розробці проекту, орієнтованого на побудову системи або продукту такого ж типу, що вже розроблялися розробниками раніше;
  3. при розробці проекту, пов’язаного зі створенням і випуском нової версії вже існуючого продукту або системи;
  4. при розробці проекту, пов’язаного з перенесенням вже існуючого продукту або системи на нову платформу;
  5. при виконанні великих проектів, в яких задіяно кілька великих команд розробників.

Набагато більше інформації на курсі базовий модуль тестування