Модель водопада

Модели процесса разработки программного обеспечения

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

Модель водопада

Модель водопада (waterfall model или последовательная разработка) – наверное, самый известный, исторически появившийся одним из первых процесс разработки. Он был описан в статье Ройса (W.W.Royce) в 1970 году (на самом деле, Ройс критиковал этот процесс, предлагая в качестве альтернативы итеративную разработку). Основная идея заключается в том, что процесс разработки делится на четко определенные фазы, выполняемые строго последовательно. Название «водопад» появилось из-за внешнего вида диаграммы, изображающей процесс:

Рисунок 1.

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

• Разработка требований (requirements): сбор бизнес-требований заказчика и их преобразование в функциональные требования к программному продукту.
• Анализ и дизайн (analysis and design): разработка модели предметной области (domain model), проектирование схемы базы данных, объектной модели, пользовательского интерфейса и т.п.
• Реализация (implementation): создание продукта по спецификациям, разработанным на предыдущем этапе.
• Тестирование (testing): включает проверку соответствия функциональности программного продукта потребностям пользователей (validation), а также поиск дефектов в реализации.
• Развертывание (deployment): обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию.

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

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

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

Однако практика показала следующие недостатки этого процесса:

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

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