На практике, при решении достаточно большого количества задач, разработка ПО имеет циклический характер, когда после выполнения некоторых стадий приходится возвращаться на предыдущие. Можно указать две основные причины таких возвратов:
· Ошибки разработчиков, допущенные на ранних стадиях и выявленные на поздних стадиях – ошибки анализа, проектирования, кодирования, выявляемые, как правило, на стадии тестирования.
· Изменение требований в процессе разработки («ошибки» заказчиков). Это или неготовность заказчиков сформулировать требования («Сказать, что должна делать программа я смогу только после того, как увижу как она работает»), или изменения требований, вызванные изменениями ситуации в процессе разработки (изменения рынка, новые технологии, …).
Циклический характер разработки программного обеспечения отражен в спиральной модели ЖЦ, описанной Б. Боэмом в 1988 году. Спиральная модель была предложена как альтернатива каскадной модели, учитывающая повторяющийся характер разработки программного обеспечения. Основные принципы спиральной модели можно сформулировать следующим образом:
· Разработка вариантов продукта, соответствующих различным вариантам требований с возможностью вернуться к более ранним вариантам
· Создание прототипов программного обеспечения как средства общения с заказчиком для уточнения и выявления требований
· Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту
· Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок.
|
· Использование каскадной модели как схемы разработки очередного варианта
· Активное привлечение заказчика к работе над проектом. Заказчик участвует в оценке очередного прототипа программного обеспечения, уточнении требований при переходе к следующему, оценке предложенных альтернатив очередного варианта и оценке рисков.
Схема работы спиральной модели выглядит следующим образом. Разработка вариантов продукта представляется как набор циклов раскручивающейся спирали. Каждому циклу спирали соответствует такое же количество стадий, как и в модели каскадного процесса. При этом, начальные стадии, связанные с анализом и планированием представлены более подробно с добавлением новых элементов.
В каждом цикле спиральной модели выделяются четыре базовые фазы:
· определение целей, альтернативных вариантов и ограничений.
· оценка альтернативных вариантов, идентификация и разрешение рисков.
· разработка продукта следующего уровня.
· планирование следующей фазы.
Рис. 4. Циклы спиральной модели.
Определение целей, альтернатив, ограничений |
Планирование следующих фаз |
Разработка следущего уровня |
Оценка альтернатив выявить и устранить риски |
Треб, ЖЦ |
Концеп. |
Сборка и |
тестирование |
АР |
АР |
Анализ |
рисков |
Анализ рисков |
П1 |
П2 |
Прототип |
Рабочий |
прототип |
Суммарная |
стоимость |
Треб. к ПО |
Проверка треб. |
Проект ПО |
Проверка проекта |
Коди- ров. |
Мод. тестир. |
Сборка |
Внедр. |
проект |
Детальн. |
План |
разработ. |
|
«Раскручивание» проекта начинается с анализа общей постановки задачи на разработку программного обеспечения. Здесь на первой фазе определяются общие цели, устанавливаются предварительные ограничения, определяются возможные альтернативы подходов к решению задачи. Далее проводится оценка подходов, устанавливаются их риски. На шаге разработки создается концепция (видение) продукта и путей его создания.
Следующий цикл начинается с планирования требований и деталей жизненного цикла продукта для оценки затрат:
На фазе определения целей устанавливаются альтернативные варианты требований, связанные с аранжировкой требований по важности и стоимости их выполнения.
На фазе оценки устанавливаются риски вариантов требований.
На фазе разработки – спецификация требований (с указанием рисков и стоимости), готовится демо-версия программного обеспечения для анализа требований заказчиком.
Следующий цикл – разработка проекта – начинается с планирования разработки:
На фазе определения целей устанавливаются ограничения проекта (по срокам, объему финансирования, ресурсам,…), определяются альтернативы проектирования, связанные с альтернативами требований, применяемыми технологиями проектирования, привлечением субподрядчиков, …
На фазе оценки альтернатив устанавливаются риски вариантов и делается выбор варианта для дальнейшей реализации.
На фазе разработки выполняется проектирование и создается демо-версия, отражающая основные проектные решения.
Следующий цикл – реализация программного обеспечения – также начинается с планирования. Альтернативными вариантами реализации могут быть применяемые технологии реализации, привлекаемые ресурсы. Оценка альтернатив и связанных с ними рисков на этом цикле определяется степенью «отработанности» технологий и «качеством» имеющихся ресурсов. Фаза разработки выполняется по каскадной модели с выходом – действующим вариантном (прототипом) продукта.
|
Отметим некоторые особенности спиральной модели:
· До начала разработки программного обеспечения есть несколько полных циклов анализа требований и проектирования.
· Количество циклов модели (как в части анализа и проектирования, так и в части реализации) не ограничено и определяется сложностью и объемом задачи
· В модели предполагаются возвраты на оставленные варианты при изменении стоимости рисков.
Спиральная модель (по отношению к каскадной) имеет следующие очевидные преимущества:
· Более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях.
· Поэтапное уточнение требований в процессе выполнения итераций, что позволяет более точно удовлетворить требованиям заказчика
· Участие заказчика в выполнении проекта с использованием прототипов программы. Заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования.
· Планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ.
· Возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования.
Основные недостатки спиральной модели связаны с ее сложностью:
· Сложность анализа и оценки рисков при выборе вариантов.
· Сложность поддержания версий продукта (хранение версий, возврат к ранним версиям, комбинация версий)
· Сложность оценки точки перехода на следующий цикл
· Бесконечность модели – на каждом витке заказчик может выдвигать новые требования, которые приводят к необходимости следующего цикла разработки.
Спиральную модель целесообразно применять при следующих условиях:
· Когда пользователи не уверены в своих потребностях или когда требования слишком сложны и могут меняться в процессе выполнения проекта и необходимо прототипирование для анализа и оценки требований.
· Когда достижение успеха не гарантировано и необходима оценка рисков продолжения проекта.
· Когда проект является сложным, дорогостоящим и обоснование его финансирования возможно только в процессе его выполнения
· Когда речь идет о применении новых технологий, что связано с риском их освоения и достижения ожидаемого результата
· При выполнении очень больших проектов, которые в силу ограниченности ресурсов можно делать только по частям.