Спиральная модель - Spiral model

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

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

История

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

В этих ранних статьях термин «модель процесса» используется для обозначения спиральной модели, а также инкрементального, водопадного, прототипного и других подходов. Однако характерное для спиральной модели сочетание характеристик других моделей процессов с учетом рисков уже присутствует:

Управляемое [R] isk подмножество шагов спиральной модели позволяет модели приспособить любую подходящую смесь ориентированного на спецификации, ориентированного на прототип, ориентированного на моделирование, ориентированного на автоматическое преобразование или другого подхода к разработке программного обеспечения.

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

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

• что спираль - это просто последовательность приращений водопада;
• что все мероприятия проекта следуют единой спиральной последовательности;
• что каждое действие на диаграмме должно выполняться в указанном порядке.

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

В отчете Национального исследовательского совета эта модель была расширена, чтобы включить риски, связанные с людьми-пользователями.

Чтобы лучше отличить их от «опасных спиральных двойников», Бем перечисляет шесть характеристик, общих для всех аутентичных применений спиральной модели.

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

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

Одновременное определение артефактов

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

Этот инвариант исключает «опасные спиральные похожие» процессы, которые используют последовательность последовательных переходов водопада в условиях, где не применяются базовые допущения модели водопада. Бем перечисляет эти предположения следующим образом:

1. Требования известны до реализации.
2. Требования не имеют нерешенных последствий высокого риска, таких как риски, связанные с затратами, графиком, производительностью, безопасностью, пользовательскими интерфейсами, организационными воздействиями и т. Д.
3. Природа требований не сильно изменится в процессе разработки или эволюции.
4. Требования совместимы с ожиданиями всех ключевых заинтересованных сторон системы, включая пользователей, заказчиков, разработчиков, специалистов по обслуживанию и инвесторов.
5. Правильная архитектура для реализации требований хорошо изучена.
6. Достаточно календарного времени, чтобы продолжить последовательно.

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

Выполняйте четыре основных действия в каждом цикле

Этот инвариант определяет четыре действия, которые должны происходить в каждом цикле спиральной модели:

1. Учитывайте условия победы всех заинтересованных сторон, критически важных для успеха.
2. Определите и оцените альтернативные подходы для удовлетворения условий победы.
3. Выявление и устранение рисков, связанных с выбранным подходом (ами).
4. Получите одобрение всех заинтересованных сторон, имеющих решающее значение для успеха, а также обязательство продолжить следующий цикл.

Циклы проекта, в которых не учитываются или не учитываются какие-либо из этих действий, рискуют потратить впустую усилия из-за вариантов, которые неприемлемы для основных заинтересованных сторон или являются слишком рискованными.

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

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

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

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

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

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

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

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

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

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

1. Цели жизненного цикла. Есть ли достаточное определение технического и управленческого подхода к удовлетворению условий победы каждого? Если заинтересованные стороны согласны с ответом «Да», значит, проект прошел эту веху LCO. В противном случае проект может быть прекращен, или заинтересованные стороны могут перейти к другому циклу, чтобы попытаться получить ответ «Да».
2. Архитектура жизненного цикла. Есть ли достаточное определение предпочтительного подхода к удовлетворению условий победы каждого, и все ли существенные риски устранены или уменьшены? Если заинтересованные стороны согласны с ответом «Да», значит, проект прошел эту веху ОЖЦ. В противном случае проект может быть прекращен, или заинтересованные стороны могут перейти к другому циклу, чтобы попытаться получить ответ «Да».
3. Первоначальные эксплуатационные возможности. Достаточно ли подготовлено программное обеспечение, сайт, пользователи, операторы и сопровождающие, чтобы удовлетворить все условия победы, запустив систему? Если заинтересованные стороны согласны с ответом «Да», значит, проект прошел контрольную точку МОК и запускается. В противном случае проект может быть прекращен, или заинтересованные стороны могут перейти к другому циклу, чтобы попытаться получить ответ «Да».

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

Три точки привязки легко вписываются в Rational Unified Process (RUP): LCO обозначает границу между этапами RUP Inception и Elaboration, LCA обозначает границу между этапами Elaboration и Construction, а IOC обозначает границу между этапами Construction и Transition.

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

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

Рекомендации