Переход от каскадной разработки к итеративной

Из журнала Rational Edge: Модель совершенной методологии итеративной разработки во многом радикально отличается от совершенной модели каскадной разработки. Но на практике ни одна группа разработчиков не применяет эти подходы строго в соответствии с их моделями. В этой статье объясняется, почему группам может потребоваться плавный переход от каскадного к итеративному подходу; также указаны некоторые полезные шаги в этом направлении.

Большинство групп разработчиков используют в своих проектах каскадный (waterfall – водопад, каскад) процесс. В чистом виде каскадный подход означат выполнение ряда фаз в строго определенном порядке: анализ требований, проектирование, выполнение/интеграция, тестирование. Тестирование откладывается до конца проекта, когда проблемы накапливаются настолько, что на их решение требуется много сил и времени; эти проблемы могут сорвать сроки выполнения проекта и надолго оставить ключевых членов группы без работы.

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