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

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

Любой проект влечет за собой определенные риски. Чем раньше в жизненном цикле можно проверить отсутствие рисков, тем
более точно можно выполнять планирование. Многие риски не удается обнаружить до тех пор, пока не будет предпринята
попытка интеграции системы. Невозможно предугадать все риски, независимо от опыта коллектива разработчиков.

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

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

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

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

Однажды заказчик сказал: «При водопадном подходе все выглядит прекрасно практически до конца проекта, иногда вплоть до
середины интеграции. А затем все распадается. При итеративном подходе очень трудно долго скрывать правду.»

Руководители проектов часто оказывают сопротивление итерационному подходу, считая его бесконечным. В Rational Unified
Process итерационный подход полностью управляем; планируется число, продолжительность и цели итераций. Определяются
задачи и ответственности участников. Собираются объективные показатели выполнения. От одной итерации к следующей
существует некоторый объем повторяющихся действий, однако это также тщательно контролируется.

Снижение рисков

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

Интеграция не является одним «большим шоком» в конце — элементы объединяются постепенно. В действительности,
итерационный подход представляет собой практически непрерывную интеграцию. То, что является длительным, неопределенным
и сложным — что отнимает до 40% общих усилий в конце проекта — и что сложно точно спланировать, делится на от шести до
девяти меньших интеграций, которые выполняются с гораздо меньшим числом элементов.

Внесение изменений

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

Изменения в требованиях и «смещение» требований всегда являются первичными источниками нарушений для проекта, ведущими
к задержке поставок, сбоям в расписании, неудовлетворенности заказчиков и разочарованию разработчиков. Двадцать пять
лет назад Фред Брукс написал: «Заранее планируйте выкинуть первую версию — все равно придется.» Мнение пользователей
будет изменяться по мере продвижения работы над проектом. Такова человеческая натура. Неверным было бы принуждать
пользователей принять систему такой, какой они представляли себе первоначально. Мнение пользователей меняется,
поскольку меняется контекст — они больше узнают о среде и технологии и видят промежуточную демонстрацию
разрабатываемого продукта.

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

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

Достижение более высокого качества

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

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

Обучение и улучшение

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

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

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

Увеличение возможностей повторного применения

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

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

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

Обсуждение  

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

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

Третье необходимое условие — принимать изменения и работать с ними. Сегодняшние приложения слишком сложны
чтобы за один раз выполнить проектирование, реализацию и тестирование. Более эффективно для разработки приложений —
принять неизбежность последующих изменений. Улучшение приложения происходит с помощью постоянного учета замечаний и
предложений и постепенной доработки при итерациях. Для управления изменениями нужны соответствующие инструменты, чтобы
не мешать креативности.

Четвертое необходимое условие — уменьшение ключевых рисков на ранних этапах жизненного цикла, как показано на
схеме ниже. Необходимо заниматься основными техническими, бизнес и программными рисками как можно раньше, а не
откалывать до конца проекта. Для этого надо непрерывно оценивать риски, с которыми мы имеем дело, а также заниматься
самыми рискованными задачами в ближайшей итерации. В успешных проектах ранние итерации включали вовлечение
заинтересованных лиц в создание требований высокого уровня, включая проектирование архитектуры, реализацию и
тестирование для смягчения технических рисков. Также при обсуждениях важно решить, какие из коробочных программных
продуктов и многократно используемых ресурсов необходимо использовать.

Профайлы уменьшения рисков для водопадного и итерационного типов разработки.

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

повторяющийся вид

вид — начало или продолжительность или завершение или повторение действия глагола

повторяющийся

повторяющийся, повторяющийся — характеризуется повторяемостью; «повторяющееся движение»