Итеративный подход

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

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

Почему это важно

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

Состав команды

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

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

Повторные работы

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