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

В этом году я изучаю программную инженерию, и меня немного смущает вопрос в названии.

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

Кто-нибудь может объяснить различные модели лучше?

Источник

3 ответа

Решение

Крейг Ларман много писал на эту тему, и я предлагаю его знаменитую статью " Итеративное и поэтапное развитие: краткая история" (PDF) и его книгу " Гибкая и итеративная разработка: руководство менеджера".

Вот как я бы суммировал вещи:

Инкрементальное развитие

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

Инкрементная разработка (добавление) часто используется вместе с Iterative Development (redo) в разработке программного обеспечения. Это называется итеративным и инкрементным развитием (IID).

Эволюционный метод

Термины эволюция и эволюция были введены Томом Гилбом в его книге Software Metrics, опубликованной в 1976 году, где он писал о EVO, его практике IID (возможно, самой старой). Эволюционное развитие фокусируется на своевременной доставке ценных активов заинтересованным сторонам, а также на получении и использовании отзывов заинтересованных сторон.

В разработке программного обеспечения: итеративный и эволюционный, Крейг Ларман говорит об этом так:

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

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

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

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

Цитирование итеративного и поэтапного развития: краткая история:

Вехой в публикациях IID в 1985 году была "Спиральная модель разработки и совершенствования программного обеспечения" Барри Бома (хотя более частая ссылка на цитирование - 1986 год). Спиральная модель, возможно, была не первым случаем, в котором команда расставила приоритеты в циклах разработки по степени риска: например, Гилб и IBM FSD ранее применяли или защищали варианты этой идеи. Однако спиральная модель формализовала и выдвинула на первый план концепцию итераций, управляемых риском, и необходимость использовать дискретный шаг оценки риска в каждой итерации.

Что теперь?

Гибкие методы являются подмножеством IID и эволюционных методов и являются предпочтительными в настоящее время.

Рекомендации

Источник

Эти понятия обычно плохо объяснены.

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

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

[ Итеративный жизненный цикл, но путь, относится к задачам, которые вы выполняете (в отличие от "инкрементного", который относится к продуктам; это представление, принятое SEMAT), и это означает, что вы выполняете задачи одного и того же печатать снова и снова. Например, в итеративном жизненном цикле вы будете заниматься дизайном, программированием, модульным тестированием, выпуском и повторением одних и тех же вещей снова и снова. Обратите внимание, что итеративный и инкрементный не подразумевают друг друга; возможна любая комбинация обоих.]

Спиральная модель для жизненных циклов - это модель, предложенная Барри Бёмом, которая сочетает в себе аспекты водопада с инновационными достижениями, такими как итеративный подход и встроенный контроль качества.

Понятия "рабочий продукт", "задача", "жизненный цикл" и т. Д. См. В ИСО / МЭК 24744.

Надеюсь это поможет.

Источник

Это определение ipsis litteris из ISO 24748-1:2016 (Управление жизненным циклом системной и программной инженерии):

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

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

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

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

Надеюсь это поможет. Tati

Источник
Другие вопросы по тегам