Спиральная модель разработки

Спиральная модель процесса создания программного обеспечения (рис. 2) в настоящее время получила широкую известность и популярность. В отличие от рассмотренных ранее моделей, где процесс создания ПО представлен в виде последовательности отдельных процессов с возможной обратной свя­зью между ними, здесь процесс разработки представлен в виде спирали. Каждый виток спирали соответствует одной стадии (итерации) процесса создания ПО. Так, самый внут­ренний виток спирали соответствует стадии принятия решения о создании ПО, на сле­дующем витке определяются системные требования, далее следует стадия (виток спирали) проектирования системы и т.д.

Каждый виток спирали разбит на четыре сектора.

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

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

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

4. Планирование. Здесь пересматривается проект и принимается решение о том, начи­нать ли следующий виток спирали. Если принимается решение о продолжении проекта, разрабатывается план на следующую стадию проекта.

Существенное отличие спиральной модели от других моделей процесса создания ПО за­ключается в точном определении и оценивании рисков. Если говорить неформально, то риск — это те неприятности, которые могут случиться в процессе разработки системы. Например, ес­ли при написании программного кода используется новый язык программирования, то риск может заключаться в том, что компилятор этого языка может быть ненадежным или что ре­зультирующий код может быть не достаточно эффективным. Риски могут также заключаться в превышении сроков или стоимости проекта. Таким образом, уменьшение (разрешение) рис­ков — важный элемент управления системным проектом.

Рис. 2. Спиральная модель создания ПО

Первая итерация создания ПО в спиральной модели начинается с тщательной проработки системных показателей (целей системы), таких как эксплуатационные показа­тели и функциональные возможности системы. Конечно, альтернативных путей дости­жения этих показателей или целей можно сформировать бесконечно много. Но каждая альтернатива должна оценивать стоимость достижения каждой сформулированной це­ли. Результаты анализа возможных альтернатив служат источником оценки проектного Риска. Это происходит на следующей стадии спиральной модели, где для оценки рисков используются более детальный анализ альтернатив, прототипирование, имитационное моделирование и т.п. С учетом полученных оценок рисков выбирается тот или иной подход к разработке системных компонентов, далее он реализуется, затем осуществля­ется планирование следующего этапа процесса создания ПО.

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