Спиральная модель разработки программного обеспечения не так широко известна, как, например, Scrum или Kanban. Причина в том, что данный подход может оказаться довольно затратным в применении. Именно поэтому он не очень хорошо подходит для небольших проектов. В спиральной модели особое внимание уделяется управлению рисками. На практике это означает, что фаза оценки и разрешения рисков является критичной для успеха проекта. Контроль рисков, в свою очередь, требует проведения специфического анализа на каждой итерации. Для регулярного обзора и анализа текущего состояния проекта необходимы дополнительные навыки и ресурсы.
На первый взгляд может показаться, что данная модель является сложной, неповоротливой и дорогостоящей и нет никаких веских причин для того, чтобы рассматривать ее как один из возможных вариантов. Но, как и любой другой подход к разработке программного обеспечения, спиральная модель имеет, помимо недостатков, также и свои сильные стороны. Например, она позволяет добавлять дополнительный функционал к программному обеспечению на самых поздних стадиях разработки. Поскольку постоянный контроль за рисками и, как следствие, регулярные экспертизы текущего состояния проекта, являются неотъемлемой частью данного подхода, общее видение проекта становится более ясным.
Обзор главных особенностей
Коротко спиральную модель можно описать как повторяющуюся последовательность циклов разработки с непрерывным контролем рисков.
Для лучшего понимая механизма разработки рассмотрим такую схему:
Как вы видите, спиральная модель состоит из четырех главных повторяющихся стадий. В ходе процесса разработки проект несколько раз проходит через все эти фазы. Каждая такая итерация называется спиралью.
Четыре главные фазы это:
1. Определение целей, альтернатив, ограничений, или фаза планирования. С этой стадии начинается работа над проектом. Команда разработчиков формулирует цели проекта, основные требования (такие как, например, Business Requirement Specifications, или BRS, System Requirement Specifications, или SRS), возможный дизайн и т.д. На последующих спиралях требования формируются согласно отзывам, полученным от заказчика. Именно поэтому постоянная коммуникация между заказчиком и командой крайне важна.
2. Анализ, определение и разрешение рисков является одной из самых значимых стадий разработки. В данном контексте, риски — это возможные события и состояния проекта, препятствующие достижению командой разработчиков поставленных целей. Существует довольно обширный диапазон возможных рисков, от тривиальных и легко преодолимых, до крайне серьезных. Главной задачей для команды разработчиков является выявление всех возможных рисков и присвоение им определенного уровня приоритета на основе их значимости. Следующим шагом является разработка возможных стратегий преодоления этих рисков. В итоге этих действий возможны изменения в последующих стадиях разработки. В качестве результата работы на этом этапе создается прототип.
3. Фаза разработки. На этом этапе происходит разработка и последующее тестирование продукта. Во время первой итерации, когда общие требования еще не так четко сформулированы, разрабатывается так называемый концепция будущего продукта (Proof Of Concept), которая необходима для получения отзыва заказчика. На последующих витках спирали рабочие версии продукта, или билды (builds), отправляются заказчику. Это позволяет получить более детальный отзыв и четче сформулировать требования.
4. Планирование следующей фазы. На этом этапе вся полученная информация используется для планирования дальнейших этапов разработки.
Спиральную модель часто называют мета-моделью, поскольку в ней используются два подхода: каскадная модель и модель прототипирования. Но крайне важно понимать, что спиральная модель не является простой последовательностью этапов разработки, следующих каскадной модели. На самом деле, спиральная модель является довольно гибкой. Стоит помнить, что схема, приведенная выше содержит определенные упрощения. Может показаться, что все стадии следуют одной спиральной последовательности. Но реальный жизненный цикл ПО более гибкий, чем это изображено на схеме. Существует даже возможность вернуться к предыдущим фазам в случае необходимости пересмотра принятых решений.
Давайте рассмотрим, как проходила разработка реальных проектов, чтобы понять, как эта модель может быть применена.
Сильные и слабые стороны спиральной модели
У любой модели разработки ПО есть свои сильные и слабые стороны. В этом отношении спиральная модель не является исключением. Давайте рассмотрим ее основные достоинства и недостатки.
Достоинства:
- Мониторинг рисков является одной из главных особенностей, делающих данную модель особенно привлекательной в том случае, если вам предстоит управление большим, сложным и дорогостоящим проектом. Более того, проект будет более прозрачным, поскольку спиральная модель изначально была спроектирована таким образом, чтобы каждая итерация тщательно анализировалась;
- Заказчик может увидеть работающую версию продукта уже на ранних стадиях жизненного цикла ПО;
- Изменения могут быть внесены на поздних стадиях разработки;
- Проект может быть разделен на несколько частей и те из них, которые, согласно анализу, окажутся более рискованными, могут быть реализованы на ранних стадиях. Такой подход может снизить трудности, связанные с управлением проектом;
Строгий контроль над документацией, как результат постоянного анализа рисков.
Недостатки:
- Мониторинг рисков требует дополнительных ресурсов, а значит, эта модель может оказаться весьма затратной. Каждая итерация требует отдельной экспертизы, что делает управление проектом сложнее. Именно поэтому спиральная модель плохо подходит для небольших проектов;
- Большое количество промежуточных стадий разработки. Как следствие — большой объем документации;
- На самых ранних стадиях дата завершения работы над проектом может быть неизвестна, что также усложняет контроль над процессом разработки
Заключение
Стоит понимать, что спиральную модель стоит применять в проектах такого типа, для которого она изначально была предназначена. Она может оказаться полезной, если вам предстоит работа над проектом со средним или высоким уровнем возможных рисков, заказчик не может предоставить достаточно четкий список требований к конечному продукту или эти требования достаточно сложные, а также в том случае, когда ожидаются значительные изменения в процессе разработки.
