Методологии разработки: Waterfall

Мы продолжаем знакомиться с различными методологиями разработки ПО. Сегодня речь пойдёт о самой популярной из них – Waterfall, или каскадной методологии.

Общая концепция подхода была представлена доктором Уинстоном Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должна быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап согласовывает компетентными сотрудниками, документируется и передаётся дальше.
Хотя популярность модели Водопада за последние годы ослабела, природа последовательного процесса, используемого в методе водопада, интуитивно ближе разработчикам, и потому доминирует в IT.

Как падает вода

Модель, предложенная Ройсом, предельно проста и понятна. Она состоит из 7 блоков, каждый из которых охватывает свою область ответственности.

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

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

Мы также сократим указанную модель до 6 блоков, объединив операции «Инсталляция» и «Поддержка» в одну – «Развертывание». Теперь взглянем на исполняемые функции:

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

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

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

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

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

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

Преимущества каскадной модели

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

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

• Устойчива к изменению кадрового состава. Разработчики могут приходить и уходить на протяжении всего жизненного цикла проекта, но благодаря подробному документированию это практически не влияет на сроки исполнения проекта.
• Дисциплина. Модель водопада заставляет разработчиков, вовлечённых в проект быть дисциплинированными, оставаться в рамках намеченного плана. При необходимости в общей модели добавляется орган управления, ответственный за принятие решений, исполнители же обязаны работать в рамках системы.
• Гибкость на ранних этапах. Изменения в первых трёх фазах могут быть сделаны немедленно и с минимальными усилиями, поскольку они не подкреплены кодом. Таким образом, заказчик и исполнитель имеют значительный временной запас для кардинального изменения концепции работы ПО.
• Ориентация на сроки и финансы. Благодаря тому, что каждый этап полностью очерчивает контур будущего ПО, все разработчики понимают свою роль, границы работы и сроки исполнения. Это позволяет оперировать реальными цифрами перед заказчиком, что делает модель проекта привлекательной.

Недостатки каскадной модели

В 1970-х годах идеи Ройса были актуальны. Но спустя почти 50 лет метод каскадной разработки всё меньше подходит для IT. Вот почему:

• Неадаптивная структура ПО. На первых этапах модель водопада может быть гибкой, но если на фазе тестирования выявляются проблемы в общей структуре – это влечёт за собой плачевные последствия в виде сорванных сроков и даже отказов заказчика. Таким образом, возрастает роль руководителей и ответственных разработчиков, с уровнем компетентности которых в любой компании часто бывают проблемы.
• Игнорирует конечного пользователя. Чем ниже продвигается процесс в водопаде, тем меньше в нём роль заказчика, не говоря уже о клиентах, которых он представляет. Внесение каких-либо изменений в функциональность ПО запускает всю цепочку этапов заново, поэтому продукты полученные по каскадной модели далеки от ориентации на массового пользователя.
• Позднее тестирование. Из описания выше легко выявить самый проблемный этап методологии – тестирование. Именно здесь чаще всего выявляются ошибки, допущенные на каждом из этапов. Более гибкие методологии используют тестирование в качестве фундаментальной операции, происходящей непрерывно. «Водопад» же допускает низкую квалификацию сотрудников на каждом этапе и плохое качество исполнения, ведь при запоздалом тестировании проблемы невозможно решить фундаментально, только при помощи «заплаток».

Получается, что каскадная методология – прекрасное решение точки зрения сроков и отчётности, но очень слабое в плане качества. Поэтому сегодня её рекомендуется использовать только  в трёх случаях:

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

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