Какие есть альтернативы модели водопада

Проблема с Waterfall в том, что он состоит из монолитных этапов, каждая из которых построена на предыдущем этапе. Таким образом, код разрабатывается в виде одного фрагмента после того, как была спроектирована вся система, что, в свою очередь, произошло после того, как все требования были собраны и подписаны.

Это проблема, потому что любое изменение должно быть одобрено сложной процедурой и проходить через все этапы. Но урок истории таков: перемены случаются. К тому времени, как мы приступаем к кодированию, требования всегда являются неполными, неверно указанными или просто устаревшими. Слишком часто проектирование и построение основываются на предположениях, которые сводятся на нет, когда система попадает в UAT. Это приводит к безумным переделкам и сбоям.

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

Единственная честная спецификация требований - «Я узнаю, когда увижу». Поэтому крайне важно как можно скорее представить работающее программное обеспечение реальным пользователям. Любая методология, которая фокусируется на постепенной доставке рабочего программного обеспечения за короткие итерации, «устранит недостатки водопадной модели».

Первоначально это был RAD или DSDM. Затем XP активирует баннер. Теперь есть Agile и подобные вещи, такие как Scrum и Канбан.

Так почему же люди настаивают на методе водопада?

Существует распространенное мнение, что Agile - это просто прикрытие для ковбойских хакеров, чтобы они бросили все скучные процессы и занялись тем, что им нравится больше всего: написанием кода. Бренд «Экстремальное программирование», безусловно, подталкивает к этой мысли, и, честно говоря, это не безосновательное обвинение. То есть некоторые программисты притворяются гибкими, чтобы не планировать, не проектировать или не документировать. Это не отражает реальную практику Agile, которая требует такой же строгости, как и любая другая методология.

Кроме того, Agile требует гораздо большего количества времени от персонала заказчика, что многие организации не хотят принимать. Кроме того, люди, оплачивающие счет, могут не захотеть уполномочить своих младших сотрудников принимать решения. Между Customer и User есть важное различие.

Когда дело доходит до аутсорсинга, каскадная модель обеспечивает простую основу для сопоставления результатов и поэтапных платежей. На самом деле договорный аспект может быть сильнее этого: в ЕС «Водопад» требуется для всех проектов стоимостью 100 миллионов евро и более.

Наконец, есть проекты, в которых хорошо работает Waterfall. У этих проектов есть области знаний, которые стабильны и хорошо понятны как заказчикам, так и разработчикам.

последнее слово

Несмотря на свои недостатки, Waterfall успешно реализовала множество проектов. Это потому, что упорный труд, способности и порядочность важнее методологии.

Модель водопада была описана в 1970 году доктором Уинстоном Ройсом в статье под названием «Управление разработкой больших программных систем». В основном излагает свои идеи о последовательном развитии. Его идея заключалась в том, что программное обеспечение могло бы быть произведено аналогично автомобилю, где транспортное средство собирается вместе в последовательных / линейных фазах.

Этот линейный подход на самом деле не позволяет вносить изменения в часть программного обеспечения после его запуска. Нет тесных отношений с конечным пользователем / клиентом, поэтому сложнее обозначить возможные проблемные области.

Стоит отметить, что некоторые фазы модели водопада допускают «всплеск», когда в период разработки есть достаточно времени, чтобы вернуться и внести небольшие изменения. Ограничения по времени, объем работы и бюджеты на самом деле не позволяют внести в эту модель много изменений, если они вообще возможны.

Модель водопада устарела, со временем меняются и сами программные парадигмы. Объектно-ориентированное программирование популярно, тогда оно было едва живым. Благодаря использованию модели водопада становится очевидным, что недостатки были обнаружены, и это привело к альтернативным методологиям разработки.

Хорошо, теперь об альтернативах. Инкрементная модель описывается Алистером Кокбурном (2008) как стратегия подготовки и планирования, в которой различные части разрабатываются в разное время или с разной скоростью и интегрируются по завершении этой конкретной части.

В основном инкрементальный режим выглядит примерно так:

Analysis->Design->Code->Test
  Analysis->Design->Code->Test
  Analysis->Design->Code->Test

К числу преимуществ относится гибкость жизненного цикла и возможность внесения изменений с самого начала. Работающее программное обеспечение, а точнее его части, создаются быстро и на ранней стадии. Созданный код раньше тестировать и управлять из-за небольших итераций прогресса. Не все требования к системе собраны заранее, только наброски. Это позволяет быстро начать работу, однако в некоторых системах это может быть недостатком, так как могут быть упущены такие вещи, как поддерживаемая архитектура системы.

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

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

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

Одноразовое прототипирование. Одноразовое прототипирование не сохраняет созданный прототип. В одноразовом прототипировании никогда не бывает намерения превратить прототип в работающую систему. Вместо этого быстро разрабатывается прототип, чтобы продемонстрировать некоторые неясные аспекты конструкции системы. Его также можно разработать, чтобы помочь пользователям или клиентам выбрать между различными функциями или характеристиками интерфейса. Как только будут решены какие-либо проблемы или неопределенности, прототип можно «выбросить», а изученные принципы использовать при проектировании и документации реального продукта.

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

Другие области, на которые стоит обратить внимание, будут включать Agile-> SCRUM, экстремальное программирование, парное программирование и т. Д.

Пытался быть кратким, но люди пишут книги об этом, и есть что обсудить.

Возможно, стоит взглянуть на: Добавочный и итеративный

Альтернатива водопадному методу - «делать правильно».

Кажется, что водопад имеет смысл, если вы находитесь на конвейере заводского цеха. Но я никогда не видел, чтобы это работало как часть процесса проектирования ... а разработка программного обеспечения - это ВСЕ процесс проектирования. Таким образом, метод водопада никогда не работает в том смысле, что он не помогает облегчить создание высококачественного продукта, а скорее фокусируется на процессе. Процесс может быть отличным, но какой смысл, если продукт, который он производит, второсортный?

Я мысленно могу придумать способы исправить недостатки модели водопада:

• Попросите программиста сконцентрироваться на автоматизации самого процесса. Автоматизируйте переходы от одного шага к другому, чтобы изменения происходили более или менее автоматически.
• Сделайте процесс более двунаправленным. Одной из основных характеристик модели водопада является изменение потока сверху вниз. Это однонаправленный процесс, и это часть проблемы.

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

Канбан и Скрам - две наиболее часто используемые альтернативы Waterfall. Я попытался дать хороший обзор и сравнение различных подходы к SDLC.

Как упоминалось APC, водопад в значительной степени опирается на массивные монолитные фазы. Это огромное слабое место, потому что попытка определить конечный продукт с самого начала - бесплодная попытка.

Канбан немного ковбойский, но я считаю, что если вы соедините его со стендапами, он определенно найдет свое место.

Скрам отлично подходит для оказания давления на команду и получения права собственности на билеты. Я обнаружил, что большинство мест используют это, но его недостаток в том, что некоторые люди заходят за борт, собирая встречи для всего. Собрания по планированию спринта, стартовые встречи спринта, ежедневные встречи, которые длятся 1 час с участием более 20 человек, демонстрационные встречи и, наконец, вскрытие.

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

Вот несколько ссылок о модели водопада:

http://www.cs.odu.edu/~zeil/cs451/Lectures/01overview/process2/process2_htsu2.html

http://www.buzzle.com/editorials/3-13-2005-67039.asp