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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

1. Boehm, B (июль 2000 г.). "Спиральная разработка: опыт, принципы и усовершенствования" (PDF) . Специальный отчет . Институт программной инженерии. CMU/SEI-2000-SR-008.
2. Boehm, B (август 1986). «Спиральная модель разработки и улучшения программного обеспечения». ACM SIGSOFT Software Engineering Notes . 11 (4): 14–24. doi :10.1145/12944.12948. S2CID  207165409.
3. Boehm, B (май 1988). "Спиральная модель разработки и улучшения программного обеспечения" (PDF) . IEEE Computer . 21 (5): 61–72. doi :10.1109/2.59. S2CID  1781829.Архивировано 6 марта 2023 г. на Wayback Machine
4. Pew, RW; Mavor, AS, ред. (2007). Интеграция человека и системы в процессе разработки системы: новый взгляд. Вашингтон, округ Колумбия: National Academy Press. doi : 10.17226/11893. ISBN 978-0-309-10720-4.