В чем разница между инкрементным и итеративным подходом к разработке программного обеспечения?


16

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

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

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

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

Как можно объединить эти два метода для формирования итеративного и инкрементального подхода к проектированию?

Ответы:


13

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

Инкрементная разработка выполняется в несколько этапов: от проектирования, внедрения, тестирования / проверки, обслуживания. Они могут быть разбиты далее на подэтапы, но большинство инкрементальных моделей следует той же схеме. Модель « Водопад» - это традиционный метод постепенного развития.

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

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


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

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

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


Обновить:

Я изменил свое определение «Инкрементальный подход», чтобы соответствовать более практическому примеру.

Если вам когда-либо приходилось иметь дело с заключением контрактов, постепенный подход заключается в том, как выполняется большинство контрактов (особенно для военных). Несмотря на множество тонких изменений типичной «модели водопада», большинство / все из них применяются на практике одинаково.

Шаги идут следующим образом:

  • Заключение контракта
  • Предварительная проверка дизайна
  • Критический обзор дизайна
  • Спецификация заморозить
  • развитие
  • Филдинг / Интеграция
  • верификация
  • Проверка надежности

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

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

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


+1 для хорошего примера, хотя инкрементное описание мне кажется неправильным
Basilevs

@Basilevs Это лучше?
Эван Плейс

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

0

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

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

Так что отвечая конкретно как подход к разработке программного обеспечения ..

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

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

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

Итерация - это цикл работы.

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

В заключение...

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

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

И, наконец, конечно, это зависит от того, как подразумевается термин при использовании, который часто значительно варьируется в зависимости от говорящего, времени месяца и т. Д.!

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

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

Эта статья описывает это хорошо, с примерами.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.