В спиральной (спиралевидной) модели разработки все идет по спирали: жизненный цикл продукта закручен в нее и разделен на фазы. Прохождение каждого витка дает инкремент. То есть некий готовый функционал.

Петли спирали — это фазы разработки ПО. В модели выделяют четыре главные фазы: Планирование. Анализ и выявления рисков. Разработка и тестирование. Оценка результата и переход к новому витку.

Спиральная модель справляется с рисками через создание прототипов на каждом этапе разработки. Также на каждом этапе определяют характеристики продукта, все тщательно анализируют.

В спиральной (спиралевидной) модели разработки все идет по спирали: жизненный цикл продукта закручен в нее и разделен на фазы. Каждый виток спирали может быть моделью водопада (waterfall) или V–образной моделью (разработка через тестирование). Разработка идеи поэтапно. Пока не завершится предыдущий этап, следующий не начнется.

Прохождение каждого витка дает инкремент. То есть некий готовый функционал.

Кстати, использовать спиральную модель начали больше 30 лет назад. И она до сих пор актуальна.

Петли спирали — это фазы разработки ПО. В ходе всего процесса, продукт проходит эти фазы по несколько раз. Сколько именно — зависит от продукта и команды.

Всего же выделяют четыре главные фазы:

• Фаза планирования. С нее–то все и начинается. Здесь происходит определение целей проекта, формулируются основные требования к нему. Это может быть обсуждение возможного дизайна, System Requirement Specifications, Business Requirement Specifications.На следующих витках спирали требования к продукту уже будут формироваться по отзывам от заказчиков. Коммуникация с ними в спиральной модели очень важна.
• Фаза анализа и выявления рисков. Это самый значимый этап в спирали. Под рисками понимают все факторы, которые могут помешать достичь целей из пункта один. Команда должна обнаружить эти возможные риски и приоритизировать их. А затем выработать стратегии по их преодолению. На этом же этапе создается прототип продукта.
• Фаза разработки и тестирования. На первом витке спирали команда разрабатывает Proof Of Concept — концепцию продукта. Она нужна для первых отзывов от заказчиков. На следующих витках (итерациях) уже рабочие версии продукта надо будет отправлять заказчику. От него нужно получить отзыв с деталями и на его основе более четко сформировать требования к продукту.
• Фаза планирования. Здесь вся информация по продукту собирается воедино и на ее основе планируют дальнейшую разработку.

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

Она подходит крупным и сложным проектам с большим бюджетом. Например, разработка системы документооборота для банков, государственные проекты или создание системы «Умный дом».

Применение спиральной модели в разработке довольно затратная история. Небольшие проекты могут ее просто не потянуть. Главные расходы идут на управление рисками. Ведь в спирале как нигде важна именно фаза выявления и разрешения рисков. А такой контроль на практике требует проводить анализ на каждом витке или итерации. Для этого нужны дополнительные ресурсы, и дополнительные навыки.

Лучше всего подходит для проектов:

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

Спиральная модель справляется с рисками через создание прототипов на каждом этапе разработки. Также на каждом этапе определяют характеристики продукта, все тщательно анализируют.

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

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

• Сложно в ней разобраться. Точно сложнее, чем в других моделях. Каждая итерация — это отдельная экспертиза. Управлять таким проектом нелегко.
• Дорогостоящая. И из–за этого подходит далеко не всем проектам.
• Вся завязано на анализе рисков. От этого зависит успех всего проекта и его завершение в принципе. Соответственно без опытного специалиста в этой области не обойтись.
• Сложно рассчитать время реализации проекта и даже время завершения отдельных фаз. Потому что их количество в начале разработки неизвестно.
• Есть риск застрять на начальных стадиях разработки. Совершенствовать первую версию продукта и не двигаться дальше.
• Нужно готовить большое количество документации по проекту. Так как много стадий разработки.

На первом этапе заказчик поставил задачу: сделать возможность управления чайником с телефона: вскипятить, включить режим подогрева до определенной температуры, выключить.

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

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

Затем перешли к следующему этапу. Заказчик захотел создать функционал для управления холодильником с телефона. Команда начала анализировать риски и выяснила, что для этого нужно встраивать в холодильник модуль wi-fi. Но производители бытовой техники не были заинтересованы в сотрудничестве, и решение выходило слишком дорогим. То есть риски превысили потенциальную выгоду от реализации функционала. Информацию предоставили заказчику и он принял решение завершить разработку и сосредоточиться на совершенствовании, доведении до ума уже имеющихся функций по управлению чайником и телевизором.

GanttPro — это приложение для управления проектами и распределения задач. Команда разработчиков применяла спиральную модель и элементы Scrum. В частности, периоды релизов продукта сделали более короткими — двухнедельными, чтобы чаще получать отзывы. Продумали максимально детальный план задач для первого этапа разработки. А остальные требования к продукту закрепили в бэклоге и дорожной карте.

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

• Добиться четкого понимания требований к продукту на начальном этапе разработки. И подготовиться к тому, что будут появляться новые требования и их нужно будет выполнять.
• Осознать необходимость выявления, анализа и управления рисками. Быть готовыми к тому, что на протяжении разработки появятся новые риски.
• Готовиться к тому, что увеличиваются затраты на разработку из–за долгого планирования.

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

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