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

Эволюционная стратегия разработки ПО

Инкрементная стратегия

Стратегии разработки ПО

Стратегии разработки ПО можно подразделить на три группы:

1. Линейная последовательность этапов разработки – однократный проход (водопадная стратегия)

2. Инкрементная стратегия, когда сначала определяются все требования (пользовательские и системные), а затем оставшаяся часть разработки выполняется в виде последовательности версий, первая из которых реализует часть запланированных возможностей, а все последующие версии реализуют дополнительные возможности до тех пор, пока не будет получена полная система.

3. Эволюционная стратегия.

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

Инкрементная модель является классическим примером инкрементной стратегии разработки ПО, объединяя элементы последовательной водопадной модели с итерационной философией макетирования. Она представляет собой несколько поставок (инкрементов) представляющих собой последовательность анализа, проектирования, кодирования и тестирования.

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

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

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

Спиральная модель (автор Боэм Б, 1988 г.) опирается на лучшие свойства классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих шагах разработки.

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

С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. В первом витке спирали определяются:

1. начальные цели, варианты и ограничения;

2. распознавание и анализ риска;

3. необходимость использования макетирования;

4. оценка заказчиком конструктивной работы и внесение предложения по модификации;

5. следующая фаза планирования и анализа риска, базируемая на предложениях заказчика.

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

К достоинствам спиральной модели относится:

1. наиболее реальное (в виде эволюции) отображение разработки программного обеспечения,

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

3. включение шага системного подхода в итерационную структуру разработки,

4. использование моделирования для уменьшения риска и совершенствования программного изделия.

Недостатками спиральной модели являются:

1. повышенные требования к заказчику,

2. трудности контроля и управления временем разработки.

Компонентно-ориентированная модель

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

К достоинствам компонентно-ориентированной модели относится:

1. уменьшение времени разработки ПО;

2. снижение стоимости программной разработки;

3. повышение производительности разработки.

Тяжеловесные и облегченные процессы

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

В последние годы появилась группа новых облегченных процессов разработки ПО. Их также называют подвижными процессами. Эти процессы привлекательны отсутствием бюрократизма, характерного для тяжеловесных (прогнозирующих) процессов.

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

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

Дата добавления: 2014-01-07