Мал. 1. Життєвий цикл програмного забезпечення

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

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

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

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