|
Водопадная модель жизненного цикла
Что такое водопадная модель
Жизненным циклом ПО называется период существования ПО,
связанный с подготовкой к его разработке, разработкой, использованием и
переработками, начиная с того момента, когда принимается решение
разработать новую систему до того момента, когда полностью прекращается
всякое ее использование. Модель жизненного цикла ПО выделяет конкретные
наборы видов деятельности, артефактов, ролей и их взаимосвязи. Она
определяет, какие артефакты являются входными данными у каких видов
деятельности, и какие артефакты появляются в качестве результатов,
какие роли вовлечены в различные работы, как работы соотносятся друг с
другом по времени, каковы критерии качества полученных результатов, как
оценить степень соответствия различных артефактов общим задачам проекта
и когда можно переходить от одной деятельности к другой.
Водопадная модель жизненного цикла ПО предполагает
последовательное выполнение различных этапов деятельности, включая
анализ требований, проектирование, кодирование и тестирование отдельных
модулей (компонентов), тестирование сборок и интегрированное
тестирование всего конечного продукта. При этом предполагается четкое
разграничение этапов, на которых набор документов, выработанный на
предыдущей этапе, передается в качестве входных данных для следующего.
Таким образом, каждый вид деятельности выполняется на какой-то одной
фазе жизненного цикла ПО, движение в обратную сторону по этой цепочке
невозможно.
Этапы деятельности
Анализ. На этапе анализа изучается и определяется задача,
которую должна выполнять программа. Результатом выполнения этой фазы
является совокупность требований, предъявляемых к ПО.
Проектирование. На этом этапе требования, выявленные при
анализе, преобразуются в описание принципов решения – документ, в
соответствии с которым принимаются конкретные решения при реализации
программы. Основным итогом второй фазы является получение проекта,
который может включать текст на естественном языке, модель ПО,
алгоритмы, таблицы, математические формулы и т. п. Детальное
проектирование предполагает выделение компонент ПО, определение их
структуры и методов взаимодействия.
Реализация. По завершении исходного проектирования
следует этап реализации, на котором создаются и тестируются программные
модули, определенные при проектировании. Главными результатами этого
этапа являются модули исходного кода и автономные тесты модулей. После
реализации переходят к тестированию системы, а затем к сдаче ее в
эксплуатацию.
Внедрение и эксплуатация. Готовый программный продукт
передается заказчику, производятся приемо-сдаточные испытания,
осуществляется обучение пользователей и опытная эксплуатация, после
чего ПО ставится на сопровождение и начинается производственная
эксплуатация программной системы.
Недостатки водопадного подхода
-
Накопление различных ошибок, допущенных на ранних стадиях проекта.
Если только к концу проекта, становится очевидно, что были допущены
ошибки, то любой возврат к предыдущим стадиям с целью исправления
ошибок становится крайне дорогостоящим. Метод "водопада" не позволяет
эффективно выявлять и нивелировать последствия подобных рисков.
-
Неоправданное увеличение времени реализации, превышение бюджета и риск полного срыва проекта из-за накопления ошибок от этапа к этапу.
-
Все ключевые решения принимаются тогда, когда у аналитиков и разработчиков нет полного понимания системы.
Очень сложно уложить реальный процесс создания программного обеспечения
в такую жесткую схему, поэтому постоянно возникает необходимость
возврата к предыдущим этапам с целью уточнения и пересмотра ранее
принятых решений. В начале проекта перед разработчиками стоит
обескураживающая задача: полностью определить все требования к системе.
Для этого необходимо тщательно и всесторонне обсудить с пользователями
и исследовать бизнес-процессы. Пользователи должны согласиться со всем
тем, что выясняется в ходе такого обследования, хотя они могут и не
ознакомиться до конца с его результатами. При некотором везении таким
способом на стадии анализа удается собрать около 80% требований к
системе. При проектировании могут возникнуть новые проблемы, их
необходимо опять обсуждать с пользователями, что выразится в появлении
новых требований к системе. В процессе реализации и тестирования
зачастую обнаруживается, что некоторые из принятых ранее решений
невозможно осуществить или выясняется, что требования не были
достаточно детализированы и их реализация некорректна. Нужно
возвращаться назад на этап анализа и пересматривать эти требования.
- Метод водопада не дает возможности быстрой адаптации к изменениям, особенно на поздних стадиях жизненного цикла ПО.
- Конечный продукт может оказаться невостребованным из-за неточного изложения требований или их изменения за длительное время создания ПО.
Когда применяется водопадный подход
Водопадный подход хорошо работает в проектах, где
требования к программному продукту четко определены и не должны
меняться, вовлечение заказчика в процесс разработки не требуется. То же
касается проектов ПО, сложность которых определяется необходимостью
реализации сложных алгоритмов, а роль и объем пользовательского
интерфейса невелик.
Сравнение водопадного и итеративного подходов
На приведенном рисунке хорошо видны различия
водопадного и итеративного подходов. Водопадный подход предполагает
фиксацию функциональности ПО и возможность варьирования времени и
ресурсов (обычно в сторону увеличения по причинам, приведенным выше).
При водопадном подходе заказчик привлекается к участию в проекте только
на раннем этапе (для определения требований к ПО) или в случае
необходимости внесения изменений, обнаруженной разработчиками. Он может
оценить только конечный результат, который может не соответствовать его
представлениям.
В итеративном подходе предполагается участие представителя заказчика в
проекте на всех этапах. Итеративный подход позволяет существенно
облегчить и упростить процесс изменения функциональности ПО.
Основные преимущества итеративного подхода можно сформулировать так:
- Возможность нивелирования воздействия серьезных рисков на ранних
стадиях проекта, пока это еще можно сделать с минимальными затратами.
Разница стоимости ошибки определения требований в начале проекта и в
конце равна 1:200.
- возможность организовать плодотворную обратную связь с будущими
конечными пользователями с целью создания системы, реально отвечающей
их потребностям;
- акцент усилий на наиболее важные и критичные направления проекта;
- непрерывное итеративное тестирование конечного продукта, позволяющее оценить успешность всего проекта в целом;
- раннее обнаружение несоответствий между требованиями, моделями и программным кодом;
- более равномерная загрузка участников проекта;
- эффективное использование накопленного опыта;
- реальная оценка текущего состояния проекта и, как следствие,
большая уверенность заказчиков и непосредственных участников в его
успешном завершении.
|
