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

Обновлено: 02.07.2024

Инженерный подход
С учетом специфики задачи
Современные технологии быстрой разработки

Модель кодирования и устранения ошибок

Постановка задачи
Выполнение
Проверка результата
При необходимости переход к первому пункту

Каскадная модель жизненного цикла программного обеспечения (водопад)

Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.

Последовательное выполнение этапов проекта в строгом фиксированном порядке
Позволяет оценивать качество продукта на каждом этапе

Отсутствие обратных связей между этапами
Не соответствует реальным условиям разработки программного продукта

Каскадная модель с промежуточным контролем (водоворот)

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

V модель (разработка через тестирование)

Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.

Модель на основе разработки прототипа

Прояснить не ясные требования (прототип UI)
Выбрать одно из ряда концептуальных решений (реализация сцинариев)
Проанализировать осуществимость проекта

Горизонтальные и вертикальные
Одноразовые и эволюционные
бумажные и раскадровки

Модель принадлежит второй группе.

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

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

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ИС создается в несколько итераций (витков спирали) методом прототипирования (рис.11).

Рис.11. Спиральная модель жизненного цикла системы.

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

На каждой итерации оцениваются:

Риск превышения сроков и стоимости проекта

Необходимость выполнения еще одной итерации

Степень полноты и точности понимания требований к системе

Целесообразность прекращения проекта.

Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод быстрой разработки приложений).

Принципиальные особенности спиральной модели:

отказ от фиксации требований и назначение приоритетов пользовательским требованиям;

разработка последовательности прототипов, начиная с требований наивысшего приоритета;

идентификация и анализ риска на каждой итерации;

использование каскадной модели для реализации окончательного прототипа;

оценка результатов по завершении каждой итерации и планирование следующей итерации.

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

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

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

Достоинствами спиральной модели являются:

· ускорение разработки (раннее получение результата за счет прототипирования);

· постоянное участие заказчика в процессе разработки;

· разбиение большого объема работы на небольшие части;

· снижение риска (повышение вероятности предсказуемого поведения системы).

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

К недостаткам спиральной модели можно отнести:

· сложность планирования (определения количества и длительности итераций, оценки затрат и рисков);

· сложность применения модели с точки зрения менеджеров и заказчиков (из-за привычки к строгому и детальному планированию);

· напряженный режим работы для разработчиков (при краткосрочных итерациях).

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

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

Рис.11. Спиральная модель жизненного цикла системы.

На каждой итерации оцениваются:

Риск превышения сроков и стоимости проекта

Необходимость выполнения еще одной итерации

Степень полноты и точности понимания требований к системе

Целесообразность прекращения проекта.

Принципиальные особенности спиральной модели:

отказ от фиксации требований и назначение приоритетов пользовательским требованиям;

разработка последовательности прототипов, начиная с требований наивысшего приоритета;

идентификация и анализ риска на каждой итерации;

использование каскадной модели для реализации окончательного прототипа;

оценка результатов по завершении каждой итерации и планирование следующей итерации.

Достоинствами спиральной модели являются:

· ускорение разработки (раннее получение результата за счет прототипирования);

· постоянное участие заказчика в процессе разработки;

· разбиение большого объема работы на небольшие части;

· снижение риска (повышение вероятности предсказуемого поведения системы).

К недостаткам спиральной модели можно отнести:

· сложность планирования (определения количества и длительности итераций, оценки затрат и рисков);

· напряженный режим работы для разработчиков (при краткосрочных итерациях).

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

основные процессы жизненного цикла, то есть приобретение, поставка, разработка, эксплуатация и сопровождение;

вспомогательные процессы, обеспечивающие выполнение основных процессов, то есть документирование, верификация, аттестация, оценка качества и другие;

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

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

Основные этапы процесса разработки:

анализ требований заказчика;

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

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

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

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

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

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

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

Рисунок 1– Основные этапы разработки каскадной модели

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

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

2. Проектирование состоит в создании:

архитектуры программного обеспечения;

модульной структуры программного обеспечения;

алгоритмической структуры программного обеспечения;

входного/выходного интерфейса (входных/выходных форм данных).

При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.

3. Кодирование или разработка состоит в переводе результатов проектирования в код программы.

4. Тестирование – это выполнение программы на выявление дефектов в функциях, логике и форме реализации программного продукта.

5. Сопровождение – это внесение изменений в эксплуатируемое программное обеспечение с целью:

адаптации к изменениям внешней для программного обеспечения среды;

усовершенствование программного обеспечения в соответствии с требованиями заказчика.

Достоинства применения каскадной модели:

дает план и временной график по всем этапам проекта, упорядочивая, таким образом, ход разработки;

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

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

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

Недостатки каскадной модели:

реальные проекты часто требуют отклонений от стандартной последовательности шагов;

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

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

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

Рисунок 2 – Процесс разработки программного обеспечения на основе каскадной модели

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

при разработке проектов с четкими, неизменяемыми в течение ЖЦ требованиями, понятными реализацией и техническими методиками;

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

при разработке проекта, связанного с созданием и выпуском новой версии уже существующего продукта или системы;

при разработке проекта, связанного с переносом уже существующего продукта на новую платформу;

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

Спиральная модель жизненного цикла

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

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

Спиральная модель включает четыре основных этапа, которые периодически повторяются:

планирование – это определение целей, вариантов и ограничений;

анализ риска – это анализ вариантов и распознавание риска;

конструирование – это разработка программного продукта следующего уровня;

оценивание – это оценка заказчика текущих результатов конструирования.

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

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

Рисунок 4 – Этапы спиральной модели

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

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

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

использует моделирование для уменьшения риска и совершенствования программного продукта.

Недостатки спиральной модели:

повышенное требование к заказчику;

трудности контроля и управления временем разработки.

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

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

∙ когда создание прототипа представляет собой подходящий тип разработки продукта;

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

∙ когда организация обладает навыками, требуемыми для адаптации модели;

∙ для проектов, выполнение которых сопряжено со средней и высокой степенью риска;

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

∙ когда речь идет о применении новой технологии и когда необходимо протестировать базовые концепции;

∙ когда пользователи не уверены в своих потребностях;

∙ когда требования слишком сложные;

∙ при разработке новой функции или новой серии продуктов;

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

Следует начать с определения, Жизненный цикл программного обеспечения (Software Life Cycle Model) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

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

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

Каскадная модель

Каскадная модель ( англ . waterfall model ) — модель процесса разработки программного обеспечения, жизненный цикл которой выглядит как поток, последовательно проходящий фазы анализа требований, проектирования. реализации, тестирования, интеграции и поддержки.

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

Жизненный цикл традиционно разделяют на следующие основные этапы :

Анализ требований,
Проектирование,
Кодирование (программирование),
Тестирование и отладка,
Эксплуатация и сопровождение.

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

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

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

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

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

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

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

Инкрементная модель

(поэтапная модель с промежуточным контролем)

Инкрементная модель ( англ . increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.

Поэтапная модель с промежуточным контролем

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

В начале работы над проектом определяются все основные требования к системе, подразделяются на более и менее важные. После чего выполняется разработка системы по принципу приращений, так, чтобы разработчик мог использовать данные, полученные в ходе разработки ПО. Каждый инкремент должен добавлять системе определенную функциональность. При этом выпуск начинают с компонентов с наивысшим приоритетом. Когда части системы определены, берут первую часть и начинают её детализировать, используя для этого наиболее подходящий процесс. В то же время можно уточнять требования и для других частей, которые в текущей совокупности требований данной работы были заморожены. Если есть необходимость, можно вернуться позже к этой части. Если часть готова, она поставляется клиенту, который может использовать её в работе. Это позволит клиенту уточнить требования для следующих компонентов. Затем занимаются разработкой следующей части системы. Ключевые этапы этого процесса — простая реализация подмножества требований к программе и совершенствование модели в серии последовательных релизов до тех пор, пока не будет реализовано ПО во всей полноте.

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

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

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

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

менеджеры должны постоянно измерять прогресс процесса. в случае быстрой разработки не стоит создавать документы для каждого минимального изменения версии;
структура системы имеет тенденцию к ухудшению при добавлении новых компонентов — постоянные изменения нарушают структуру системы. Чтобы избежать этого требуется дополнительное время и деньги на рефакторинг. Плохая структура делает программное обеспечение сложным и дорогостоящим для последующих изменений. А прерванный Жизненный цикл ПО приводит еще к большим потерям.

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

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

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

Спиральная модель жизненного цикла

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

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

Жизненный цикл на каждом витке спирали — могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели . Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.

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

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

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

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

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

История создания спиральная модель и архитектура разработки программного обеспечения

Барри Боэм родился в 1935 году. Боэм получил степень бакалавра по математике в Гарвардском университете, степень магистра в и степень доктора философии.

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

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

Барри Боэм в его статье Spiral Development:Experience, Principles,and Refinements, так пишет о спиральной модели

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

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

Когда использовать спиральную модель?

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

Например, подобная модель используется Агентстве перспективных оборонных исследовательских проектов (DARPA) США.

И так, что такое спиральная модель

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

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

Spiral Model Спиральная модель и архитектура разработки программного обеспечения

Фазы спиральной модели

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

Spiral Model Спиральная модель и архитектура разработки программного обеспечения от Барри Боэма

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

Читайте также: