Спиральная модель жизненного цикла разработки ПО

Основатели теории управления разработкой программного обеспечения, в том числе Уинстон Ройс (Winston Royce) и Барри Боэм (Barry Boehm), изначально понимали, какая проблема кроется в классическом каскадном процессе. Для преодоления этих проблем в середине 80-х годов была предложена спиральная модель жизненного цикла, обеспечивающая большую степень взаимосвязи с потребителем. Спиральная модель базируется на лучших свойствах водопадного процесса и метода прототипирования (макетирования), к которым добавляется новый элемент – анализ рисков.

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

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

Как показано на рис. 1.8, в каждый квадрант модели входят целевые и вспомогательные действия. Ниже перечислены эти квадранты.

· Определение целей, альтернативных вариантов и ограничений.

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

· Оценка альтернативных вариантов, идентификация и разрешение рисков.

Выполняется оценка альтернативных вариантов, относящихся к выделенным на предыдущем этапе целям и ограничениям. Выполняется определение и разрешение рисков (менеджмент рисков), принимается решение относительно прекращения и/или продолжения работ над проектом.

Рис. 1.8. Спиральная модель жизненного цикла

· Разработка продукта следующего уровня.

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

· Планирование следующей фазы.

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

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

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

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

Следует отметить тот факт, что кодирование выполняется значительно позже,чем в других моделях. Смысл заключается в том, чтобы минимизировать риск посредством последовательных уточнений требований, выдвигаемых пользователем. В каждом «мини-проекте» (движении по спирали) рассматривается один или несколько факторов риска, начиная с фактора с наивысшим приоритетом. Типичные риски включают в себя неправильно истолкованные требования, архитектуру, потенциальные проблемы, связанные с эксплуатацией продукта, проблемы в базовой технологии и т.д.

Эта модель более полно отражает реальный процесс создания ПО, чем «водопад». Неполное завершение работ на каждой стадии позволяет переходить на следующую стадию, не дожидаясь полного завершения работы на текущей. Недостающую работу можно будет выполнить на следующей итерации. Главная задача как можно скорей предъявить пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Такой процесс непрекращающихся потребительских обзоров и обновления спецификаций позволял регулировать степень риска проекта. Этот подход стал основой для развития современных схем управления проектами по разработке программного обеспечения.

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

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

В случае использования спиральной модели при выполнении проекта, для которого она в достаточной мере подходит, проявляются ее следующие преимущества:

• спиральная модель позволяет пользователям «увидеть» систему на ранних этапах разработки, что обеспечивается посредством использования ускоренного прототипирования в жизненном цикле разработки ПО;
• модель обеспечивает возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования. Это позволяет в случае необходимости, прекратить работу над проектом, и уменьшить непроизводительные расходы;
• в модели предусмотрена возможность гибкого проектирования, поскольку в ней воплощены преимущества каскадной модели, и в тоже время, разрешены итерации по всем фазам этой же модели;
• модель позволяет идентифицировать непреодолимые риски без особых дополнительных затрат;
• модель предусматривает активное участие пользователей в работах по планированию, анализу рисков, разработке и оценке полученных результатов. Обратная связь по направлению от пользователей к разработчикам выполняется с высокой частотой и на ранних этапах жизненного цикла, что обеспечивает создание нужного продукта высокого качества;
• при использовании модели происходит усовершенствование процессов управления проектом, включая процесс обеспечения качества, соблюдение графика выполнения работ и использования ресурсов, что достигается путем выполнения обзора в конце каждой итерации;
• модель обеспечивает повышение эффективности разработки благодаря использованию пригодных для повторного использования свойств;
• при использовании спиральной модели повышается вероятность предсказуемого поведения системы за счет неоднократного уточнения поставленных целей;
• модель позволяет выполнять частую оценку совокупных затрат, и, как следствие, контролировать степень риска.

В то же время спиральная модель не лишена недостатков, которые особенно ярко проявляются при ее использовании в проектах, для которых она не слишком подходит:

· модель имеет усложненную структуру, поэтому может быть затруднено ее применение разработчиками, менеджерами и заказчиками;

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

· сложность поддержания версий продукта (хранение версий, возврат к ранним версиям, комбинация версий);

· сложность оценки точки перехода на следующий цикл;

· спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл, что отдаляет окончание работы над проектом;

Спиральная модель жизненного цикла применяется в тех случаях, когда:

· пользователи не уверены в своих потребностях или когда требования к системе слишком сложны и могут меняться в процессе выполнения проекта и необходимо прототипирование для анализа и оценки требований;

· достижение успеха не гарантировано и необходима оценка рисков продолжения проекта;

· проект является сложным, дорогостоящим и обосновать объемы финансирования возможно только в процессе его выполнения;

· речь идет о применении новых технологий, что связано с риском их освоения и достижения ожидаемого результата;

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

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