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

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

История [ править ]

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

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

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

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

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

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

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

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

Чтобы лучше отличить их от «опасных спиральных двойников», Бём перечисляет шесть характеристик, общих для всех подлинных применений спиральной модели. ^{[ нужна цитата ]}

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

Подлинное применение спиральной модели обусловлено циклами, которые всегда демонстрируют шесть характеристик. Бём иллюстрирует каждую из них примером «опасного двойника спирали», нарушающего инвариант. ^[1]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте вехи опорных точек [ править ]

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

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

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

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

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

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

Ссылки [ править ]

^ Перейти обратно: ^а ^б ^с Бём, Б. (июль 2000 г.). «Спиральное развитие: опыт, принципы и уточнения» (PDF) . Специальный репортаж . Институт программной инженерии. CMU/SEI-2000-SR-008.
^ Бём, Б. (август 1986 г.). «Спиральная модель разработки и улучшения программного обеспечения». Заметки по разработке программного обеспечения ACM SIGSOFT . 11 (4): 14–24. дои : 10.1145/12944.12948 . S2CID 207165409 .
^ Перейти обратно: ^а ^б Бём, Б. (май 1988 г.). «Спиральная модель разработки и улучшения программного обеспечения» (PDF) . IEEE-компьютер . 21 (5): 61–72. дои : 10.1109/2.59 . S2CID 1781829 . Архивировано 6 марта 2023 года в Wayback Machine .
^ Пью, RW; Мавор, А.С., ред. (2007). Интеграция человека и системы в процессе разработки систем: новый взгляд . Вашингтон, округ Колумбия: Издательство Национальной академии. ISBN 978-0-309-10720-4 .

[:0-1] Перейти обратно: ^а ^б ^с Бём, Б. (июль 2000 г.). «Спиральное развитие: опыт, принципы и уточнения» (PDF) . Специальный репортаж . Институт программной инженерии. CMU/SEI-2000-SR-008.

[2] Бём, Б. (август 1986 г.). «Спиральная модель разработки и улучшения программного обеспечения». Заметки по разработке программного обеспечения ACM SIGSOFT . 11 (4): 14–24. дои : 10.1145/12944.12948 . S2CID 207165409 .

[:1-3] Перейти обратно: ^а ^б Бём, Б. (май 1988 г.). «Спиральная модель разработки и улучшения программного обеспечения» (PDF) . IEEE-компьютер . 21 (5): 61–72. дои : 10.1109/2.59 . S2CID 1781829 . Архивировано 6 марта 2023 года в Wayback Machine .

[4] Пью, RW; Мавор, А.С., ред. (2007). Интеграция человека и системы в процессе разработки систем: новый взгляд . Вашингтон, округ Колумбия: Издательство Национальной академии. ISBN 978-0-309-10720-4 .

[1]

[2]

[3]

[4]