Выбор модели жц программного проекта

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

При выборе модели ЖЦ программного проекта следует найти ответ на ряд следующих вопросов.

Насколько стабильны требования?

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

Кто же является конечным пользователем системы?

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

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

В последнее время методология разработки программного обеспечения от Microsoft (MSF - Microsoft Solution Framework) стала включать в себя гибкий подход. Что касается гибкой модели, то, согласно данной методологии, «маленькие итерации позволяют снизить уровень ошибок в предположениях и представить быстрый отчет о точности ваших планов. Каждая итерация должна в результате предоставлять стабильную часть всей системы». Microsoft и Google выбрали гибкость в разработке, потому что их клиенты представлены в виде очень распределенной группы пользователей.

Временные рамки проекта агрессивны или консервативны?

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

Каков размер проекта?

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