Спиральная модель: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
[отпатрулированная версия][непроверенная версия]
← Предыдущая правка
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
 
(не показано 8 промежуточных версий 8 участников)
Строка 1: Строка 1:


{{нет источников|дата=2011-10-06}}
{{нет источников|дата=2011-10-06}}
⚫
[[Image:Spiral model (Boehm, 1988).svg|thumb|400px|Спиральная модель (Боэм, 1988).]]
{{Разработка программного обеспечения}}
{{Разработка программного обеспечения}}
⚫
[[Файл:Спиральная модель Барри Боэма.svg|thumb|520px|Спиральная модель (Боэм, 1988)]]
'''Спира́льная модель''', предложенная Барри Боэмом в [[1986 год]]у, стала существенным прорывом в понимании природы разработки ПО. Она представляет собой [[процесс разработки программного обеспечения]], сочетающий в себе как проектирование, так и постадийное [[прототипирование]] с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:
'''Спира́льная модель''', предложенная [[Барри Боэм|Барри Боэмом]] в [[1986 год]]у, стала существенным прорывом в понимании природы разработки ПО. Она представляет собой [[процесс разработки программного обеспечения]], сочетающий в себе как итеративность, так и этапность.

Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:
# Дефицит специалистов.
# Дефицит специалистов.
# Нереалистичные сроки и бюджет.
# Нереалистичные сроки и бюджет.
Строка 14: Строка 14:
# Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
# Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
# Недостаточная производительность получаемой системы.
# Недостаточная производительность получаемой системы.
# Разрыв между квалификацией специалистов и требованиями проекта<ref>{{Книга|автор = Richard W. Selby|год = 2007-06-04|isbn = 9780470148730|страниц = 834|издательство = John Wiley & Sons|заглавие = Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research|ссылка = https://books.google.com/books?id=ttaMIFv8bv8C}}</ref>
# «Разрыв» в квалификации специалистов разных областей знаний.
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.


Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нём уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:
⚫
* определение целей,
* оценка и разрешение рисков,
* оценка и разрешение рисков,
⚫
* определение целей,
* разработка и тестирование,
* разработка и тестирование,
* планирование.
* планирование следующей итерации.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт.
⚫
Модель сочетает в себе возможности модели прототипирования и [[Модель водопада|водопадной модели]]. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации.
⚫
Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений [[RAD (программирование)|RAD]] (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:
# небольшую команду программистов (от 2 до 10 человек);
# короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);
# повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.


⚫
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз:
# фаза определения требований и анализа;
# фаза проектирования;
# фаза реализации;
# фаза внедрения.


⚫
Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для её решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков
Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В условиях, когда бизнес цели таких проектов могут измениться, но требуется разработка стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости, имеет смысл применение [http://sadd4ru.codeplex.com Spiral Architecture Driven Development]. Данная методология, включающая в себя лучшие идеи спиральной модели и некоторых других, позволяет существенно снизить архитектурные риски, что является немаловажным фактором успеха при разработке крупных систем.

== Примечания ==
{{примечания}}


== Ссылки ==
== Ссылки ==
Строка 44: Строка 38:


{{Software Engineering}}
{{Software Engineering}}




[[Категория:Формальные методы]]
[[Категория:Формальные методы]]

Текущая версия от 19:35, 27 июня 2020

Разработка программного обеспечения
Ключевые процессы
Парадигмы и модели
Методологии
Инструменты
Спиральная модель (Боэм, 1988)

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

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

  1. Дефицит специалистов.
  2. Нереалистичные сроки и бюджет.
  3. Реализация несоответствующей функциональности.
  4. Разработка неправильного пользовательского интерфейса.
  5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
  6. Непрекращающийся поток изменений.
  7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
  8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
  9. Недостаточная производительность получаемой системы.
  10. Разрыв между квалификацией специалистов и требованиями проекта[1]

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

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

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

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

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

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

Примечания

[править | править код]
  1. ↑ Richard W. Selby. Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research. — John Wiley & Sons, 2007-06-04. — 834 с. — ISBN 9780470148730.

Ссылки

[править | править код]
Источник — https://ru.wikipedia.org/w/index.php?title=Спиральная_модель&oldid=107894327