Спиральная модель — это модель процесса разработки программного обеспечения, основанная на рисках . Спиральная модель, основанная на уникальных моделях рисков данного проекта, помогает команде применять элементы одной или нескольких моделей процессов, таких как инкрементальное , каскадное или эволюционное прототипирование .
Эта модель была впервые описана Барри Бёмом в его статье 1986 года «Спиральная модель разработки и улучшения программного обеспечения». [2] В 1988 году Бём опубликовал аналогичную статью [3] для более широкой аудитории. В этих статьях представлена диаграмма, которая воспроизводилась во многих последующих публикациях, посвященных спиральной модели.
В этих ранних статьях термин «модель процесса» используется для обозначения спиральной модели, а также поэтапного, каскадного, прототипирования и других подходов. Однако характерное для спиральной модели сочетание особенностей других моделей процессов, основанное на риске, уже присутствует:
Подмножество шагов спиральной модели, управляемое рисками, позволяет модели адаптировать любое подходящее сочетание ориентированного на спецификации, прототипно-ориентированного, симуляционно-ориентированного, ориентированного на автоматическое преобразование или другого подхода к разработке программного обеспечения. [3]
В более поздних публикациях [1] Бём описывает спиральную модель как «генератор модели процесса», где выбор, основанный на рисках проекта, создает соответствующую модель процесса для проекта. Таким образом, инкрементная, каскадная, прототипная и другие модели процессов являются частными случаями спиральной модели, которые соответствуют моделям рисков определенных проектов.
Бём также указывает на ряд заблуждений, возникающих из-за чрезмерного упрощения исходной диаграммы спиральной модели. Он говорит, что наиболее опасными из этих заблуждений являются:
Хотя эти заблуждения могут соответствовать моделям рисков некоторых проектов, они неверны для большинства проектов.
В отчете Национального исследовательского совета [4] эта модель была расширена и теперь включает риски, связанные с пользователями-людьми.
Чтобы лучше отличить их от «опасных спиральных двойников», Бём перечисляет шесть характеристик, общих для всех подлинных применений спиральной модели. [ нужна цитата ]
Подлинное применение спиральной модели обусловлено циклами, которые всегда демонстрируют шесть характеристик. Бём иллюстрирует каждую из них примером «опасного двойника спирали», нарушающего инвариант. [1]
Последовательное определение ключевых артефактов проекта часто увеличивает возможность разработки системы, отвечающей «условиям победы» заинтересованных сторон (целям и ограничениям).
Этот инвариант исключает «опасные спиральные процессы», в которых используется последовательность поэтапных каскадных проходов в условиях, когда основные предположения каскадной модели не применяются. Бём перечисляет эти предположения следующим образом:
В ситуациях, когда эти предположения действительно применимы, существует риск проекта не указать требования и не действовать последовательно. Таким образом, водопадная модель становится частным случаем спиральной модели, основанным на риске.
Этот инвариант определяет четыре действия, которые должны происходить в каждом цикле спиральной модели:
Проектные циклы, в которых игнорируются или не учитываются какие-либо из этих действий, рискуют напрасно потратить усилия из-за выбора вариантов, которые неприемлемы для ключевых заинтересованных сторон или являются слишком рискованными.
Некоторые «опасные спиральные процессы» нарушают этот инвариант, исключая ключевых заинтересованных сторон из определенных последовательных фаз или циклов. Например, специалисты по сопровождению системы и администраторы могут не быть приглашены для участия в определении и разработке системы. В результате система рискует не выполнить свои условия выигрыша.
Для любой деятельности проекта (например, анализа требований, проектирования, прототипирования, тестирования) команда проекта должна решить, каких усилий достаточно. В аутентичных спиральных циклах процессов эти решения принимаются путем минимизации общего риска.
Например, инвестирование дополнительного времени в тестирование программного продукта часто снижает риск, связанный с тем, что рынок отклонит некачественный продукт. Однако дополнительное время тестирования может увеличить риск из-за раннего выхода конкурента на рынок. С точки зрения спиральной модели тестирование следует проводить до тех пор, пока общий риск не будет минимизирован, и не более того. [ нужна цитата ]
«Опасные спиральные двойники», нарушающие этот инвариант, включают эволюционные процессы, которые игнорируют риск из-за проблем с масштабируемостью, и инкрементные процессы, которые вкладывают значительные средства в техническую архитектуру, которая должна быть перепроектирована или заменена, чтобы приспособиться к будущим приращениям продукта.
Для любого артефакта проекта (например, спецификации требований, проектной документации, плана тестирования) команда проекта должна решить, насколько детализации достаточно. В аутентичных спиральных циклах процессов эти решения принимаются путем минимизации общего риска.
Если рассматривать в качестве примера спецификацию требований, то в проекте следует точно указать те функции, где риск снижается за счет точной спецификации (например, интерфейсы между аппаратным и программным обеспечением, интерфейсы между генеральным подрядчиком и субподрядчиками). И наоборот, в проекте не следует точно определять те функции, точная спецификация которых увеличивает риск (например, графические макеты экрана, поведение готовых компонентов).
Первоначальное описание спиральной модели, данное Бёмом, не включало никаких этапов процесса. В более поздних уточнениях он вводит три контрольных точки, которые служат индикаторами прогресса и точками обязательств. Эти опорные точки можно охарактеризовать ключевыми вопросами.
«Опасные спиральные двойники», нарушающие этот инвариант, включают эволюционные и инкрементные процессы, требующие значительных ресурсов для реализации решения с плохо определенной архитектурой. [ нужны разъяснения ]
Три контрольных точки легко вписываются в Rational Unified Process (RUP): LCO отмечает границу между фазами начальной и разработки RUP, LCA отмечает границу между фазами разработки и строительства, а IOC отмечает границу между фазами строительства и перехода.
Этот инвариант подчеркивает важность всей системы и долгосрочные проблемы, охватывающие весь ее жизненный цикл. Он исключает «опасные спиральные двойники», которые слишком много внимания уделяют первоначальной разработке программного кода. Эти процессы могут возникнуть в результате следования опубликованным подходам к объектно-ориентированному или структурированному анализу и проектированию программного обеспечения при игнорировании других аспектов потребностей процесса проекта.