+7 (495) 982-50-33  

Компания «Октис» - универсальный системный интегратор. Разработка ПО, поставка оборудования и интеграция.

Главная » Статьи » Водопадная модель жизненного цикла
Вторник, 11 Дек 2018

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

E-mail Печать

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

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

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

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

Анализ

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

Проектирование

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

Реализация

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

Внедрение и эксплуатация

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

Недостатки водопадного подхода 

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

Неоправданное увеличение времени реализации, превышение бюджета и риск полного срыва проекта из-за накопления ошибок от этапа к этапу.

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

Метод водопада не дает возможности быстрой адаптации к изменениям, особенно на поздних стадиях жизненного цикла ПО.

Конечный продукт может оказаться невостребованным из-за неточного изложения требований или их изменения за длительное время создания ПО.

Когда применяется водопадный подход

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

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

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

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

Основные преимущества итеративного подхода:

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

- возможность организовать плодотворную обратную связь с будущими конечными пользователями с целью создания системы, реально отвечающей их потребностям;

- акцент усилий на наиболее важные и критичные направления проекта;

- непрерывное итеративное тестирование конечного продукта, позволяющее оценить успешность всего проекта в целом;

- раннее обнаружение несоответствий между требованиями, моделями и программным кодом;

- более равномерная загрузка участников проекта;

- эффективное использование накопленного опыта;

- реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.

За дополнительной информацией, пожалуйста, обращайтесь к руководителю отдела маркетинга Сергею Ларионову: E-mail: sergey_l(0)octys.ru