Введение

Модель процесса разработки программного обеспечения

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

История

Эта модель была впервые описана Барри Боемом в его статье 1986 года "Спиральная модель разработки и совершенствования программного обеспечения". В 1988 году Боем опубликовал аналогичную статью для более широкой аудитории. В этих статьях представлена диаграмма, которая впоследствии воспроизводилась во многих публикациях, посвященных спиральной модели. В этих ранних работах термин "модель процесса" использовался для обозначения спиральной модели, а также инкрементной, каскадной, прототипирования и других подходов. Однако характерное для спиральной модели сочетание элементов других моделей процессов, основанное на анализе рисков, уже присутствует: подмножество этапов спиральной модели, определяемое рисками, позволяет ей использовать любую подходящую комбинацию подходов, ориентированных на спецификации, прототипирование, моделирование, автоматическое преобразование или другие методы разработки программного обеспечения. Эта модель была расширена, чтобы учитывать риски, связанные с конечными пользователями. Чтобы лучше отличать подлинные применения спиральной модели от "опасных имитаций", Боем перечисляет шесть характеристик, общих для всех аутентичных реализаций спиральной модели.

Шесть инвариантов спиральной модели

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

Определять артефакты одновременно

Последовательное определение ключевых артефактов проекта часто повышает вероятность разработки системы, удовлетворяющей "условиям успеха" заинтересованных сторон (целям и ограничениям). Этот инвариант исключает процессы, имитирующие спираль, но представляющие собой последовательность инкрементных итераций "водопада" в ситуациях, когда базовые предположения модели "водопад" неприменимы. Боэм перечисляет эти предположения следующим образом:
Требования известны до начала реализации. Требования не содержат неразрешенных высокорисковых последствий, таких как риски, связанные со стоимостью, сроками, производительностью, безопасностью, пользовательскими интерфейсами, организационным воздействием и т.д. Характер требований не претерпит существенных изменений в процессе разработки или эволюции. Требования соответствуют ожиданиям всех ключевых заинтересованных сторон системы, включая пользователей, заказчика, разработчиков, специалистов по сопровождению и инвесторов. Подходящая архитектура для реализации требований хорошо продумана. Доступно достаточно времени для последовательного выполнения работ. В ситуациях, когда эти предположения выполняются, не уточнять требования и придерживаться последовательного подхода – это риск для проекта. Таким образом, модель "водопад" становится частным случаем спиральной модели, обусловленным управлением рисками.

Риск определяет уровень усилий

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

Риск определяет степень детализации

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

Используйте точки якоря

Первоначальное описание Боэмом спиральной модели не включало в себя никаких вех процесса. В более поздних уточнениях он вводит три ключевые вехи, которые служат индикаторами прогресса и точками фиксации обязательств. Эти ключевые вехи можно охарактеризовать ключевыми вопросами. Цели жизненного цикла. Достаточно ли определены технический и управленческий подходы для удовлетворения условий успеха всех заинтересованных сторон? Если заинтересованные стороны согласны с тем, что ответ "да", то проект преодолел веху ЦЖЦ. В противном случае проект может быть отменен, или заинтересованные стороны могут взять на себя обязательство по новому циклу, чтобы попытаться получить ответ "да". Архитектура жизненного цикла. Достаточно ли определен предпочтительный подход для удовлетворения условий успеха всех заинтересованных сторон, и устранены или смягчены ли все значительные риски? Если заинтересованные стороны согласны с ответом "да", то проект преодолел веху АЖЦ. В противном случае проект может быть отменен, или заинтересованные стороны могут взять на себя обязательство по новому циклу, чтобы попытаться получить ответ "да". Начальная операционная готовность. Достаточно ли подготовлены программное обеспечение, площадка, пользователи, операторы и обслуживающий персонал для удовлетворения условий успеха при запуске системы? Если заинтересованные стороны согласны с ответом "да", то проект преодолел веху НОГ и запущен. В противном случае проект может быть отменен, или заинтересованные стороны могут взять на себя обязательство по новому циклу, чтобы попытаться получить ответ "да". "Опасные имитации спирали", нарушающие это правило, включают эволюционные и инкрементальные процессы, выделяющие значительные ресурсы на реализацию решения со слабо определенной архитектурой. Три ключевые вехи легко вписываются в Рациональный унифицированный процесс (РУП), при этом ЦЖЦ обозначает границу между фазами инициализации и разработки RUP, АЖЦ – границу между фазами разработки и реализации, а НОГ – границу между фазами реализации и внедрения.

Сосредоточьтесь на системе и ее жизненном цикле

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