Водопадная модель жизненного цикла

Что такое водопадная модель

Жизненным циклом ПО называется период существования ПО, связанный с подготовкой к его разработке, разработкой, использованием и переработками, начиная с того момента, когда принимается решение разработать новую систему до того момента, когда полностью прекращается всякое ее использование. Модель жизненного цикла ПО выделяет конкретные наборы видов деятельности, артефактов, ролей и их взаимосвязи. Она определяет, какие артефакты являются входными данными у каких видов деятельности, и какие артефакты появляются в качестве результатов, какие роли вовлечены в различные работы, как работы соотносятся друг с другом по времени, каковы критерии качества полученных результатов, как оценить степень соответствия различных артефактов общим задачам проекта и когда можно переходить от одной деятельности к другой.

Водопадная модель жизненного цикла ПО предполагает последовательное выполнение различных этапов деятельности, включая анализ требований, проектирование, кодирование и тестирование отдельных модулей (компонентов), тестирование сборок и интегрированное тестирование всего конечного продукта. При этом предполагается четкое разграничение этапов, на которых набор документов, выработанный на предыдущей этапе, передается в качестве входных данных для следующего. Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла ПО, движение в обратную сторону по этой цепочке невозможно.

Этапы деятельности

Анализ. На этапе анализа изучается и определяется задача, которую должна выполнять программа. Результатом выполнения этой фазы является совокупность требований, предъявляемых к ПО.

Проектирование. На этом этапе требования, выявленные при анализе, преобразуются в описание принципов решения – документ, в соответствии с которым принимаются конкретные решения при реализации программы. Основным итогом второй фазы является получение проекта, который может включать текст на естественном языке, модель ПО, алгоритмы, таблицы, математические формулы и т. п. Детальное проектирование предполагает выделение компонент ПО, определение их структуры и методов взаимодействия.

Реализация. По завершении исходного проектирования следует этап реализации, на котором создаются и тестируются программные модули, определенные при проектировании. Главными результатами этого этапа являются модули исходного кода и автономные тесты модулей. После реализации переходят к тестированию системы, а затем к сдаче ее в эксплуатацию.

Внедрение и эксплуатация. Готовый программный продукт передается заказчику, производятся приемо-сдаточные испытания, осуществляется обучение пользователей и опытная эксплуатация, после чего ПО ставится на сопровождение и начинается производственная эксплуатация программной системы.

Недостатки водопадного подхода
  • Накопление различных ошибок, допущенных на ранних стадиях проекта. Если только к концу проекта, становится очевидно, что были допущены ошибки, то любой возврат к предыдущим стадиям с целью исправления ошибок становится крайне дорогостоящим. Метод "водопада" не позволяет эффективно выявлять и нивелировать последствия подобных рисков.
  • Неоправданное увеличение времени реализации, превышение бюджета и риск полного срыва проекта из-за накопления ошибок от этапа к этапу.
  • Все ключевые решения принимаются тогда, когда у аналитиков и разработчиков нет полного понимания системы. Очень сложно уложить реальный процесс создания программного обеспечения в такую жесткую схему, поэтому постоянно возникает необходимость возврата к предыдущим этапам с целью уточнения и пересмотра ранее принятых решений. В начале проекта перед разработчиками стоит обескураживающая задача: полностью определить все требования к системе. Для этого необходимо тщательно и всесторонне обсудить с пользователями и исследовать бизнес-процессы. Пользователи должны согласиться со всем тем, что выясняется в ходе такого обследования, хотя они могут и не ознакомиться до конца с его результатами. При некотором везении таким способом на стадии анализа удается собрать около 80% требований к системе. При проектировании могут возникнуть новые проблемы, их необходимо опять обсуждать с пользователями, что выразится в появлении новых требований к системе. В процессе реализации и тестирования зачастую обнаруживается, что некоторые из принятых ранее решений невозможно осуществить или выясняется, что требования не были достаточно детализированы и их реализация некорректна. Нужно возвращаться назад на этап анализа и пересматривать эти требования.
  • Метод водопада не дает возможности быстрой адаптации к изменениям, особенно на поздних стадиях жизненного цикла ПО.
  • Конечный продукт может оказаться невостребованным из-за неточного изложения требований или их изменения за длительное время создания ПО.
Когда применяется водопадный подход

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

Сравнение водопадного и итеративного подходов

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

При водопадном подходе заказчик привлекается к участию в проекте только на раннем этапе (для определения требований к ПО) или в случае необходимости внесения изменений, обнаруженной разработчиками. Он может оценить только конечный результат, который может не соответствовать его представлениям.

В итеративном подходе предполагается участие представителя заказчика в проекте на всех этапах. Итеративный подход позволяет существенно облегчить и упростить процесс изменения функциональности ПО.

    Основные преимущества итеративного подхода можно сформулировать так:
  • Возможность нивелирования воздействия серьезных рисков на ранних стадиях проекта, пока это еще можно сделать с минимальными затратами. Разница стоимости ошибки определения требований в начале проекта и в конце равна 1:200.
  • возможность организовать плодотворную обратную связь с будущими конечными пользователями с целью создания системы, реально отвечающей их потребностям;
  • акцент усилий на наиболее важные и критичные направления проекта;
  • непрерывное итеративное тестирование конечного продукта, позволяющее оценить успешность всего проекта в целом;
  • раннее обнаружение несоответствий между требованиями, моделями и программным кодом;
  • более равномерная загрузка участников проекта;
  • эффективное использование накопленного опыта;
  • реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.