Iterative Waterfall Model итеративная каскадная модель и архитектура разработки программного обеспечения

История создания итеративная каскадной модели

В оригинальной модели водопада Ройса следующие фазы выполняются по порядку:

1. Системные и программные требования — отражены в документе с требований к продукту;
2. Анализ: создание моделей, схем и бизнес-правил;
3. Дизайн: в результате появилась программная архитектура;
4. Кодирование: разработка, тестирование и интеграция программного обеспечения;
5. Тестирование: систематическое обнаружение и устранение дефектов;
6. Операции: установка, миграция, поддержка и обслуживание полных систем.

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

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

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

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

Когда использовать итеративную модель?

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

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

Фазовое сдерживание ошибок — это принцип обнаружения ошибок как можно ближе к их точкам привязки.

Преимущества итеративной модели водопада

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

Недостатки итеративной модели водопада

• Трудно включить запросы на изменение: главный недостаток итеративной каскадной модели заключается в том, что все требования должны быть четко сформулированы до начала фазы разработки. Заказчик может изменить требования через некоторое время, но итеративная каскадная модель не оставляет возможности для включения запросов на изменение, сделанных после начала фазы разработки.
• Инкрементная доставка не поддерживается: в итеративной каскадной модели программное обеспечение полностью разрабатывается и тестируется перед доставкой заказчику. Никаких промежуточных поставок нет. Таким образом, покупателям приходится долго ждать получения программного обеспечения, что в свою очередь не верно с точки зрения успеха проектов, так как увеличивает риск поставки «устаревшего» проекта, а также более жестко привязывает проект по срокам, нет возможности сдавать проект частями, о таких ситуациях рассказывается в книге Тома ДеМарко, Тимоти Листера “Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения”.
• Перекрытие фаз не поддерживается: модель итеративного водопада предполагает, что одна фаза может начаться после завершения предыдущей фазы, но в реальных проектах фазы могут перекрываться, чтобы сократить усилия и время, необходимые для завершения проекта.
• Обработка рисков не поддерживается: проекты могут подвергаться различным типам рисков. Но в модели итеративного водопада нет механизма обработки рисков, более подробно о рисках при разработке программного обеспечения в книге Тома ДеМарко, Тимоти Листера “Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения.
• Ограниченное взаимодействие с клиентами: взаимодействие с клиентами происходит в начале проекта во время сбора требований и по завершении проекта во время поставки программного обеспечения. Такое меньшее количество взаимодействий с клиентами может привести к множеству проблем, поскольку окончательно разработанное программное обеспечение может отличаться от реальных требований клиентов, о чем так же говорится в книге Тома ДеМарко, Тимоти Листера “Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения.

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