1) определить цели – продукт, деловые цели, понять ограничения, предложить альтернативы;
2) оценить альтернативы – анализ риска, прототипирование;
3) разработать продукт – детальный проект, код, unit test, интеграция;
4) спланировать следующий цикл – оценка клиентом, планирование проектирования, поставка клиенту, внедрение.
Эта модель предназначена для проектов с существенными рисками. Пожалуй, эту особенность следует выделить и подчеркнуть. Во многом модель в связи с необходимостью оценки рисков может быть интересна и в кризисный период, когда проекты становятся более рискованными, чем раньше, получают дополнительные риски, связанные, например, с задержкой финансирования, сложностями взаимодействия в проектной команде, если она является распределенной. По сути, в этой модели речь идет о задачах, которые выполняются на каждом этапе и на каждом витке жизненного цикла меняются – наблюдаются итерации.
Рис. 3.8. Спиральная модель жизненного цикла ПО
Каждая фаза каскадной модели зацикливается – как правило, это три-четыре итерации, но это сильно зависит от «сходимости» проекта, в ряде случаев количество итераций сложно предсказать, более того, часто бывает так, что после оценки рисков проект продолжать невозможно. Это может повлечь дополнительные расходы, но в ряде случаев необходимо признать, что проектная команда не в состоянии в заявленные сроки и с требуемым уровнем качества реализовать проект должной функциональности. При этом, как уже отмечалось, каждый цикл модели включает при спиральном подходе четыре основных этапа: определение, оценка, реализация и планирование. На первой стадии определяются цели, возможные альтернативы достижения этих целей и ограничения, существующие для каждой из альтернатив. Далее ведется оценка альтернатив, главным образом оценка рисков. Это достаточно сложная дисциплина, которая требует фундаментальных знаний, и поэтому специалисты, часто вынужденные принимать решения в условиях неполной информации и существенной неопределенности, ценятся очень дорого. В этой связи модель требует дополнительных расходов, но хороша для тех проектов, которые могут требовать таких постоянных оценок рисков и являются достаточно рискованными сами по себе. Если удается идентифицировать риски, указать пути их снижения или найти возможность продолжать проект с теми рисками, которые существуют, начинается стадия реализации, верификации и тестирования текущего витка спирали. И после этого, с учетом того, каким образом, в какой мере и с какими затратами людских ресурсов, по срокам, качеству достигается поставленная цель, осуществляется планирование следующего цикла, следующего витка спирали.
Нужно заметить, что поскольку анализ рисков включает ряд существенных неопределенностей, которые заказчик для исполнителя обычно раскрывает далеко не в полной мере, спиральная модель достаточно хороша для внутренних проектов, когда разработчик и заказчик либо являются одним юридическим лицом, либо работают в рамках одной корпоративной структуры. Очень часто в больших корпорациях выделяется отдельная компания, занимающаяся ведением ИТ-проектов, например компания «Сибинтек» в составе ЮКОСа, компания «Итеранет» в группе компаний «Итера». Спиральная модель при такой организации взаимодействия, когда разработчик и заказчик находятся в рамках одной структуры корпоративного типа, – достаточно хорошее решение. В этом случае может осуществляться достаточно полная передача всей необходимой информации для оценки рисков, они могут оцениваться достаточно достоверно и поэтому грамотно и с минимальными затратами разрешаться.
Следующая модель, о которой хочется более подробно сказать, получила название «синхронизация и стабилизация», или модель синхростабилизации. Это связано с особенностью организации фаз жизненного цикла программного продукта. Другое название – модель Microsoft. Сегодня по информации из ряда источников она постепенно заменяется на Microsoft Solution Framework (MSF). По сути, эта модель была во многом похожа на MSF, но сегодня ею вытесняется. MSF – достаточно сложная и достаточно открытая модель. Она имеет интересные преимущества, которые основаны на определенном равноправии членов проектной команды. С другой стороны, эта модель достаточно сложна. Крайне ограниченно количество экспертов, владеющих тонкостями этой модели настолько, чтобы донести ее до широкой аудитории руководителей проектов, менеджеров продуктов, системных архитекторов. Поэтому, к сожалению, несмотря на свою привлекательность, модель не получила широкого распространения вне компании Microsoft. Сторонние компании, даже если они работают с инструментарием Microsoft и имеют хорошие знания о технологиях и стандартах Microsoft, редко пользуются ею из-за сложности ее реализации.