Этапы проекта в соответствии с каскадной моделью:
Формирование требований;
Проектирование;
Реализация;
Тестирование;
Внедрение;
Эксплуатация и сопровождение.
Преимущества каскадной модели:
полная и согласованная документация на каждом этапе;
легко определить сроки и затраты на проект.
В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится возвращаться к ранней фазе проекта. В результате требуемая переработка приводит не только к нарушению графика, но и к существенному росту затрат.
По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем.
Итерационная модель
Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также название эволюционной модели.
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение инкремент к его возможностям, которые, следовательно, развиваются эволюционно.
По выражению Т. Гилба, «эволюция прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность отката к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».
Недостатки подхода IID:
отсутствие целостного понимания возможностей и ограничений проекта на ранних итерациях;
необходимость переделывать часть сделанной ранее работы;
снижение добросовестности специалистов при выполнении работ (всё равно всё можно будет переделать и улучшить позже).
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).
Спиральная модель
Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
риск превышения сроков и стоимости проекта;
необходимость выполнения ещё одной итерации;
степень полноты и точности понимания требований к системе;
целесообразность прекращения проекта.
Спиральная модель является усовершенствованным вариантом эволюционной модели (модели IID). Ее отличительной особенностью является специальное внимание, уделяемое рискам, влияющим на организацию разработки. Наиболее распространёнными являются следующие группы рисков.
Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
Перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
Разрыв в квалификации специалистов разных областей.
Для преодоления рисков при реализации проектов предлагается использовать так называемые контрольные точки, характеризующие разные стадии готовности проекта.
Concept of Operations (COO) концепция (использования) системы;
Life Cycle Objectives (LCO) цели и содержание жизненного цикла;
Life Cycle Architecture (LCA) архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;