Достоинства:

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

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

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

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

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

Спиральная модель по( ieee).

//график..

Каждый виток спирали соответствует стадии процесса создания ПО. Самый внутренний виток соответствует стадии принятия решения о создании ПО. На следующем витке определяются системные требования. Затем идет проектирование и т.д. каждый виток спирали разбит на 4 сектора. Первый сектор определение целей:

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

Второй сектор:

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

Третий сектор:

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

Четвертый сектор:

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

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

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