Представляем Вашему вниманию модель Водопад. Этот подход для разработки программного обеспечения считается классикой в IT. В этой статье мы рассмотрим, как она работает, ее плюсы и минусы, когда она эффективна, и где в ней применяется тестирование.
Тестирование по модели водопада
Модель «Водопад»
Модель «Водопад» (Waterfall model), она же каскадная модель, – это такая модель процесса разработки ПО, в которой проект реализуется поэтапно шаг за шагом. Среди таких шагов обычно выделяют анализ системных и программных требований, проектирование (бизнес-аналитика), конструирование (дизайн), собственно разработка (кодинг), тестирование и функционирование.
Первоисточником считается статья У. У. Ройса, опубликованная в 1970 году.
При этом в модели водопада следующий шаг делается только тогда, когда полностью и успешно выполнен предыдущий. Если предыдущий не сделан, то последующий не начинают выполнять.
Как работает модель водопада
В стандартной модели шаги (фазы, стадии) указывались в следующем порядке:
| № | Шаг (каскад) | Содержание шага | Результат шага |
| Определение системных и программных требований (System and software requirements) |
| Документ, фиксирующий требования к продукту (как правило, ТЗ – Техническое задание) | |
| Проектирование (Analysis) |
| Модели, схема и бизнес-правила работы продукта | |
| Конструирование (Design) |
| Архитектура ПО | |
| Разработка (Coding) |
| Программирование, отладка и интеграция модулей продукта | |
| Тестирование (Testing) |
| Устранение найденных дефектов в ПО | |
| Функционирование (Operations) |
| Стабильно функционирующий продукт |
При этом стоит отметить, что здесь приведены примерные шаги. Существуют модифицированные каскадные модели, имеющие отклонения от стандартного процесса.
Главные правила «Водопада»
Суть модели водопада можно отражают ее главные правила:
- Следуйте инструкциям и правилам
- Нет ТЗ — нет продукта
- Чем подробнее ТЗ, тем лучше продукт
- Минимум непредвиденных изменений
Каковы плюсы и минусы каскадной модели
К плюсам модели водопада относят:
- Подробный план работ и инструкции по всему процессу. Уже на первой стадии становится понятен объем работ. В дальнейшем каждое действие в проекте описывается, риски оцениваются и устраняются, ответственные назначаются. В итоге исполнителям остается лишь следовать плану.
- Определенность по срокам и бюджету проекта. Если известны все действия, то, естественно, можно рассчитать сроки всех мероприятий и бюджет проекта. Это удобно и разработчикам, и клиентам. Сроки исполнения могут поменяться только из-за форс-мажора.
- Возможность снизить длительность проекта за счет параллельной разработки. Т.к. дизайн продукта будет определен полностью заранее, то разработчики могут работать над модулями ПО параллельно.
- Экономия рабочего времени на коммуникациях между стадиями. Исполнителям на последующей стадии нет необходимости контактировать с исполнителями из предыдущей стадии— надо просто выполнять предписанные инструкции. Это экономит время исполнителей.
- Прозрачность проекта. Поскольку все стадии хорошо спланированы, то все заинтересованные лица знают сроки, объемы и другие аспекты исполнения каждой стадии. В таком случае проще контролировать выполнение работ.
К минусам модели водопада относят:
- Каждая непредвиденная ситуация – это маленькая катастрофа. Как бы то ни было, невозможно предусмотреть все проблемы и риски заранее. И если недочеты выявлены на поздних стадиях, то придется переделывать все предыдущие. Это лишние затраты.
- Дефекты выявляются только на стадии тестировании. Как мы знаем, чем позже обнаружен дефект, тем дороже обойдется его устранение. В модели «Водопад» дефекты обнаруживаются сильно позднее, чем могли бы.
Как клиент видит результат?
При использовании модели «Водопад» клиент принимает участие в создании продукта главным образом только при постановке ТЗ, он не участвует в разработке и тестировании.
Если финальный продукт не будет соответствовать его ожиданиям, возникнет много проблем – и у клиента, и у исполнителя. И если в ходе проекта бизнес-требования к ПО серьезно изменились (из-за внешних условий, например), то продукт уже заранее становится «хромой уткой».
В этой связи критически важно максимально точно снять ожидания с клиента и правильно сформулировать ТЗ на первой стадии водопада.
Когда модель водопада эффективна?
Казалось бы, каскадная модель слишком жесткая и не подразумевает гибкости в переходах назад или вперед между стадиями. Однако, есть сферы, где такая модель получается эффективной. Это отрасли, где последствия рисков некорректной работы ПО намного превышают стоимость разработки.
Например, ее используют в авиастроении: ущерб от аварии самолета из-за недокументированных, но случившихся рисков ПО будет намного серьезнее, чем неудобства малорискового «Водопада». Также данную модель довольно часто применяют в медицине, космической сфере, безопасности авто- и железнодорожных перевозок.
Резюме
Особенностью модели водопада является то, что тестирование производится на предпоследней стадии проекта. Это означает, что все конструкционные и программные недоработки будут выявлены поздно, и поэтому их исправление обойдется дороже. Но зато эта модель подразумевает меньше неучтенных рисков и более прозрачна по срокам и бюджету разработки ПО.
