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