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

модель водопада представляет процесс разработки в виде строго упорядоченной последовательности этапов. К ним относятся:

• сбор требований к системе и программному обеспечению;• анализ;• проектирование;

• кодирование и тестирование модулей;• интеграция системы;• тестирование приложения в целом;• передача в эксплуатацию.

Для перехода к следующему этапу необходимо полностью закончить работу над текущим и тщательно описать его результаты.

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

Ряд недостатков:

• Излишние затраты времени — как правило, интеграция всех подсистем в работающее приложение занимает гораздо больше времени, чем запланировано.

• Выявление причин, по которым необходимо изменять проект на поздних стадиях — при использовании модели водопада это обычное дело. Проверка работоспособности и реализуемости проекта приложения на ранних стадиях, как правило, не выполняется.

• Неадекватное управление рисками — риски, связанные с проектом, выявляются на поздних стадиях выполнения проекта.

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

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

• Отсутствие рецензирования — первые четыре этапа модели водопада, по сути, — бумажная работа, и чтобы демонстрировать прогресс проекта, по окончании каждой стадии необходимо готовить массу документов. Лавинообразное нарастание объема проектной документации ведет к тому, что понятыми оказываются лишь вопросы, обсуждавшиеся последними; наиболее сложные стороны проекта не проверяются, а правильность их решения принимается за аксиому.

Спиральная модель

Применение более современных методов привело к появлению итерационного подхода к управлению процессом разработки — так называемой спиральной модели. Эта модель подразделяется на следующие стадии:

• исследование — анализ требований и предварительное планирование;

• проработка — проектирование приложений;

• переходный период— оценка и стабилизация приложения;

• создание— реализация приложения.

Каждая из этих стадий обычно подразделяется на пять фаз: сбор требований, проектирование, реализация, развертывание и управление.

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

Как и модель водопада, спиральная модель порождает множество проблем - недостатки:

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

• Никогда не заканчивающиеся проекты — проекты, реализуемые по спиральной модели, часто начинают жить собственной жизнью, когда работа над проектом фактически превращается в работу для проекта; такие проекты или никогда не кончаются, или кончаются ничем. При изменении целей проекта итерационный подход вынуждает группу продолжать работу над реализацией прежних целей, игнорируя новые задачи.

Это ведет к утрате ориентации и

резкому снижению полезности проекта.

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

• Отсутствие стабильности — постоянное изменение системы формирует у заказчиков и пользователей мнение о нестабильности продукта. Постоянное обновление всех составляющих проекта на каждой итерации резко увеличивает затраты и значительно повышает стоимость развертывания продукта.

• Отсутствие автоматизации — необходимость инвестиций в автоматизацию процесса разработки программного обеспечения часто упускается из вида. Значительные первоначальные расходы на

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

новых версий продукта на компьютеры пользователей.

2.Модель процесса разработки MSF

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

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

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

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

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

проекты, разрабатывавшиеся по спиральной модели, так и не заканчивались— итерационный цикл продолжался без конца.Как показано на рис. 2,1, модель процесса разработки MSF сочетает сильные стороны обоих методов, позволяя воспользоваться преимуществами поэтапного подхода модели водопада и достоинствами итерационной разработки, присущей спиральной модели.

Модель процесса разработки MSF имеет три отличительные осо­бенности:

• разбиение на фазы (рис. 2.1);

• контроль выполнения работ на каждой фазе;

• итеративность (стрелка на рис. 2.1 возвращает процесс к первой фазе).

Хотя на рис. 2.1 все четыре фазы занимают по четверти времени, от­веденного на проект, в действительности дело не всегда обстоит именно так. Распределение времени и ресурсов между фазами диктуется осо­бенностями бизнес-проблемы и технологической инфраструктуры.