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

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

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

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

18
sdlc

3 ответов

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

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

Поэтапное Развитие

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

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

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

условия эволюция и эволюционная были введен компанией Tom Gilb в своей книге Показатели Программного Обеспечения опубликовано в 1976 году, где он писал об Эво, его практике IID (возможно, старейшей). Эволюционное развитие сосредоточено на скорейшем обеспечении высокой ценности для заинтересованных сторон и на получении и использовании обратной связи от заинтересованных сторон.

на Разработка Программного Обеспечения: Итеративный И Эволюционный в Craig Larman выразился примерно так:

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

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

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

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

цитирую итеративная и инкрементная разработка: краткое описание История:

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

что теперь?

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

ссылки

16

эти понятия обычно плохо объясняются.

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

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

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

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

для понятий "рабочий продукт", "задача", "жизненный цикл" и др. пожалуйста, смотрите ISO / IEC 24744.

надеюсь, что это помогает.

7

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

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

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

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

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

надеюсь, что это помогает. Тати!--3-->

0