СПИРАЛЬНАЯ МОДЕЛЬ: ИСТОРИЯ, ХАРАКТЕРИСТИКИ, ЭТАПЫ, ПРИМЕР - ТЕХНОЛОГИЯ - 2025

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

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

Анализ, оценка, планирование и развитие. Спираль разработки программного обеспечения Источник: Beao commons.wikimedia.org

история

Создание

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

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

Бем известен своими многочисленными вкладами в разработку программного обеспечения, такими как конструктивная модель затрат (COCOMO), спиральная модель процесса разработки программного обеспечения, подход G-Theory (беспроигрышный) к определению требований и управлению ими. программного обеспечения.

Альтернатива модели водопада

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

Спиральная модель была не первой, в которой обсуждалась циклическая разработка, но это была первая модель, объясняющая, почему итерация важна. Как первоначально планировалось, он был нацелен на крупные сложные проекты, итерации которых обычно составляют от 6 месяцев до 2 лет.

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

Эта циклическая модель повлияла на архитектуру разработки программного обеспечения на основе моделей (MBASE) и экстремальное программирование.

Особенности спиральной модели

Контроль рисков

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

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

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

Описание спирали

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

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

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

общий

Четыре этапа реализуют только основные цели цикла, но они не должны проявляться в каждом цикле.

Порядок каждого цикла также строго не определен. Поэтому модель в любой момент можно комбинировать с другими моделями.

гибкий

Он достаточно гибкий, так как выполняет процессы определения целей, анализа рисков, разработки и планирования отдельно для каждой фазы проекта.

Metamodel

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

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

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

Этапы

Определите цели, альтернативы и ограничения

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

Кроме того, рассматриваются различные альтернативы его реализации, такие как build vs. покупать, повторно использовать существующие компоненты или использовать аутсорсинг и т. д.

Таким же образом определяются такие ограничения, как стоимость, расписание и интерфейсы, потребление времени и т. Д.

Оценка рисков

Оцениваются все предлагаемые альтернативы. Цели и ограничения служат определяющими ориентирами для выбора наилучшего решения.

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

Наконец, используются такие методы, как прототипирование, моделирование, аналитические модели и опросы пользователей.

Разработка и тестирование

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

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

Планирование следующего цикла

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

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

пример

Военные США приняли спиральную модель для разработки и модернизации программы модернизации Future Fighting Systems (SCF).

Официально запущенные в 2003 году, SCF должны были оснащать войска транспортными средствами, подключенными в режиме реального времени к чрезвычайно быстрой и гибкой сети полей сражений.

Проект был разделен на четыре цикла развития продолжительностью около двух лет каждая. Спираль 1 должна была начаться в 2008 году и доставить прототипы для использования и оценки.

После завершения спирали 1, спираль 2 должна была начаться в 2010 году. Окончательная разработка продукта должна была завершиться в 2015 году.

В августе 2005 года компания Boeing объявила о завершении первой важной вехи проекта, а именно функциональной перестройки систем. Boeing и Science Applications International Corporation были соруководителями проекта.

Однако на октябрь 2005 года Пентагон рекомендовал отложить реализацию проекта из-за сильного воздействия на расходы войны в Ираке и помощи от урагана Катрина.

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

преимущество

Циклическая структура

Благодаря такой структуре проблемы между дизайном и техническими требованиями к программному обеспечению неявно устраняются благодаря периодическим проверкам.

Управление рисками

Риски анализируются на каждом этапе продукта, прежде чем двигаться дальше. Это помогает преодолеть или снизить потенциальные риски.

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

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

Участие клиентов и обратная связь

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

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

Идеально подходит для больших проектов

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

Недостатки

Дорого

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

Довольно сложно

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

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

Знания в области анализа и управления рисками, которые часто недоступны, имеют важное значение.

Тайм-менеджмент

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

Много шагов

Многие шаги в разработке программного обеспечения не всегда благоприятны, потому что, несмотря на универсальность тестирования, незавершенные части программы могут попасть в готовую систему.

Как следствие, всегда существует опасность, что любая концептуальная ошибка или несоответствие повлияет на конечный продукт.

Ссылки

1. Виктор Фонт-младший (2019). Спиральная модель. Полное руководство по SDLC. Взято с: ultimatesdlc.com.
2. Ионос (2019). Спиральная модель: модель процесса разработки программного обеспечения с учетом рисков. Взято с: ionos.com.
3. Techuz (2018). Что такое спиральная модель? Простое объяснение жизненного цикла спиральной разработки программного обеспечения (SDLC). Взято с: techuz.com.
4. Единое тестирование (2020). Спиральная модель. Взято с сайта onestoptesting.com.
5. Гики для гиков (2020). Программная инженерия - спиральная модель. Взято с: geeksforgeeks.org.
6. Чанду (2019). Спиральная модель в программной инженерии. Взято с: medium.com.