Каковы проблемы модели водопада?

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

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

1. Требования

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

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

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

3. Реализация

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

4. Проверка

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

Обратите внимание, что

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

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

В чем проблема водопада?

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

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

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

1.  Люди слепо следуют планам.

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

2.  Последовательный процесс и изменения становятся дорогостоящими

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

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

3.  Конечные пользователи не знают, чего хотят.

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

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

4.  Может пострадать проверка качества.

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

5.  Вы никогда не узнаете, на какой стадии вы находитесь на самом деле.

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

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

Связанные ресурсы

• Agile & Scrum — Статьи по разработке программного обеспечения ( английский ) ( китайский ) ( японский )