Модель предполагает, что разработка будет состоять из определенных фаз, результат каждой из которой будет необходим для начала следующей.
Обрати внимание на то, что в этой модели довольно долгий подготовительный период. Менеджеры тщательно планируют работу по проекту и готовят всю необходимую документацию. По сути, сначала создается идеальный план выполнения работ с распределением всех ресурсов на выполнение конкретных задач для достижения целей фазы, а также просчитываются потенциальные риски и способы управления ими. После того как подготовительные этапы завершены, команда приступает к работе, а менеджер сравнивает реальный прогресс работы по проекту с тем идеальным планом, который был создан до этого, и принимает меры, если между ними возникают расхождения.
Использование этой модели предполагает знание ее плюсов и минусов.
Водопадная модель
Несомненный ее плюс – тщательное планирование и документирование работ до начала реализации. С самого начала понятно, какие работы нам следует выполнить для достижения результата и сколько они будут стоить. Кроме того, тщательно разработанная документация позволяет новым членам команды существенно быстрее присоединиться к работе. Вдобавок эта модель выглядит очень естественной и интуитивно понятной, что делает ее довольно легкой для менеджмента.
Однако это, как ни парадоксально, может оказаться одним из главных минусов. Очень сильная зависимость от опыта одного менеджера проекта, по плану которого команда будет работать, значительно повышает риск неудачи. Например, если компетенций и знаний «матчасти» менеджера не хватит, мы обязательно столкнемся с трудностями при реализации проекта. Отчасти эту проблему можно решить тщательной проверкой плана работы и проектной части командой специалистов продюсерской группы и оперативное внесение в них необходимых изменений.
Другой минус использования «водопадной» модели – высокая цена ранних ошибок. Другими словами, если на этапе тестирования ты обнаружишь дефект, связанный с проектированием, то все работы по разработке, вероятно, придется выполнять заново, поскольку функционал был разработан на ошибочных требованиях. Я говорил о таких ситуациях выше. Как же с ними можно бороться?
Например, использовать другую классическую модель – V-модель, усовершенствованнный «водопад». От предыдущей она отличается тем, что каждая фаза проекта совмещена с тщательным тестированием продукта этой фазы. Эта модель идеально иллюстрирует принцип раннего тестирования, который, помимо прочего, позволяет нам существенно экономить время и деньги. Возможно, авторы этой модели придали ей сходство с литерой V, которую часто изображают для обозначения победы (англ. Victory).
V-модель
Таким образом, тестирование с самых ранних этапов позволяет нам избежать концептуальных ошибок, которые сложно исправлять впоследствии, и контролировать проект и его бюджет на всех этапах реализации.
Казалось бы, невозможно придумать ничего лучше для реализации практически любого проекта; недаром эта модель – федеральный стандарт разработки ПО. Но и она не лишена недостатков. Например, мы не можем оперативно внести изменения, без которых проект рискует потерпеть неудачу (добавить или изменить функционал). Кроме того, модель не предполагает глубокого анализа рисков.
Зато углубленное изучение всевозможных рисков предполагается в следующей из рассматриваемых моделей – спиральной.
Спиральная модель (Spiral Model)
Спиральная модель
Спиральная модель – это концептуальный подход, в котором предполагается глубокий анализ разнообразных рисков.
Разработка продукта на каждой стадии (витке спирали) разработки программного обеспечения проходит всегда по четырем этапам.
1. Определение целей
2. Оценка рисков
3. Разработка и тестирование
4. Планирование
Так эта модель становится больше похожа на итеративную, хотя в ней нет четких временных ограничений этапов. И именно это обстоятельство – ее главный минус. Без введения временных ограничений для каждой стадии может быть довольно сложно определять время перехода от одного этапа к другому. Ну, и, как ты понимаешь, чтобы использовать эту модель, нужно быть экспертом в области управления рисками.