Подход Инкрементальный использует определенное количество шагов , и развитие идет от начала до конца в линейной траектории прогрессии.
Инкрементная разработка выполняется в несколько этапов: от проектирования, внедрения, тестирования / проверки, обслуживания. Они могут быть разбиты далее на подэтапы, но большинство инкрементальных моделей следует той же схеме. Модель « Водопад» - это традиционный метод постепенного развития.
Итерационный подход не имеет определенное количество шагов, а развитие осуществляется в циклах.
Итеративная разработка меньше связана с отслеживанием прогресса отдельных функций. Вместо этого основное внимание уделяется созданию рабочего прототипа и добавлению функций в циклы разработки, где этапы инкрементной разработки выполняются для каждого цикла. Agile Modeling - это типичный итеративный подход.
Инкрементная модель изначально была разработана в соответствии с традиционной моделью сборочной линии, используемой на фабриках. К сожалению, проектирование и разработка программного обеспечения имеет мало общего с производством физических товаров. Код - это план, а не готовый продукт разработки. Хороший выбор дизайна часто «обнаруживается» в процессе разработки. Заключение разработчиков в набор предположений без надлежащего контекста может привести к плохим проектам в лучшем случае или к полному срыву разработки в худшем.
В настоящее время итеративный подход становится обычной практикой, поскольку он лучше соответствует естественному пути развития в разработке программного обеспечения. Вместо того, чтобы тратить много времени / усилий в погоне за «идеальным дизайном», основанным на допущениях, итеративный подход заключается в создании чего-то «достаточно хорошего», чтобы его запускать и развивать в соответствии с потребностями пользователя.
tl; dr - Если бы вы писали эссе по инкрементальной модели, вы бы попытались написать его идеально от начала до конца по одному предложению за раз. Если бы вы написали его в рамках Итеративной модели, вы бы быстро набросали черновой вариант и работали над его улучшением через ряд этапов пересмотра.
Обновить:
Я изменил свое определение «Инкрементальный подход», чтобы соответствовать более практическому примеру.
Если вам когда-либо приходилось иметь дело с заключением контрактов, постепенный подход заключается в том, как выполняется большинство контрактов (особенно для военных). Несмотря на множество тонких изменений типичной «модели водопада», большинство / все из них применяются на практике одинаково.
Шаги идут следующим образом:
- Заключение контракта
- Предварительная проверка дизайна
- Критический обзор дизайна
- Спецификация заморозить
- развитие
- Филдинг / Интеграция
- верификация
- Проверка надежности
PDR и CDR - это то, где спецификация создается и пересматривается. Как только спецификация завершена, она должна быть заморожена, чтобы предотвратить смещение области видимости. Интеграция происходит, если программное обеспечение используется для расширения уже существующей системы. Проверка предназначена для проверки того, что приложение соответствует спецификации. Надежность - это тест, доказывающий, что приложение будет надежным в течение длительного периода времени, это можно определить во многом как SLA (Соглашение об уровне обслуживания), где система должна поддерживать определенный процент времени безотказной работы (например, 99% безотказной работы в течение 3 месяцев ).
Эта модель отлично подходит для систем, которые просто указать на бумаге, но которые сложно изготовить. Программное обеспечение очень сложно указать на бумаге с какой-либо заметной степенью детализации (например, UML). Большинство «типов бизнеса», отвечающих за управление / заключение контрактов, не понимают, что - когда дело доходит до разработки программного обеспечения - сам код является спецификацией. Бумажные спецификации часто занимают столько же или больше времени / усилий, сколько и сам код, и на практике они оказываются неполными / неполноценными.
Инкрементные подходы пытаются потратить впустую время / ресурсы, рассматривая сам код как спецификацию. Вместо прохождения бумажной спецификации через несколько этапов ревизии, сам код проходит несколько циклов ревизии.