Итеративная разработка программного обеспечения

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

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

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

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

Итеративная, итерационная, инкрементная и эволюционная разработка — фактически, это синонимы. 

Итеративность (iteration, «повторение») в данном случае означает подход, основаный на выполнении задач в рамках «мини-проектов», инкрементность (increment «увеличение») означает последовательное добавление функционала к разрабатываемому продукту, а эволюционность (evolutio, «развёртывание») — процесс развития продукта, напоминающий естественное развитие биологических видов.

Водопадная и итеративная модели разработки

Метафорически сравнение водопадной и итеративной моделей разработки часто описывают на примере разработки транспортного средства. 

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

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

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

Основные преимущества итеративной модели разработки

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

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

Быстрый выпуск минимально ценного продукта (MVP) и возможность вывести продукт на рынок и начать эксплуатацию гораздо раньше.

Основные недостатки итеративной модели разработки

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

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

Резюме

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

Итеративная разработка — это оптимальный выбор:

  • для больших проектов
  • для проектов с размытыми требованиями
  • для инновационных продуктов и стартапов
  • для проверки бизнес-гипотез
  • для запуска в сжатые сроки

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

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

Узнать больше →

Разработка ПО на основе водопадной модели эффективна при полном и детальном понимании целей и задач проекта. Благодаря работе по строгой спецификации, эта модель позволяет строго зафиксировать бюджет и сроки проекта.

Cтатьи по теме:

Ошибки при разработке сайтов: старт проекта без целей, задач и проектирования
Часто, когда встает вопрос о создании сайта, цели и задачи не формулируются или формулируются нечётко. В этом случае вы никогда не получите то, что хотели, так как разработчикам просто непонятно что именно вы хотите.
Ошибки при разработке сайтов: субъективный подход к дизайну и стремление к самовыражению
Как часто можно услышать это: «Сайт должен быть стильным», «Сайт должен внушать доверие», «Мой дизайн должен быть эксклюзивным и непохожим на другие» и другие варианты необъективных критериев. «Стильное, лаконичное, внушающее доверие» — это все субъективные оценочные критерии, которые зависят от восприятия каждого конкретного человека.
Ошибки при разработке сайтов: отсутствие аналитики и развития после запуска
То, что сайт разработан и запущен, еще не означает, что можно больше ничего не делать и продажи резко пойдут вверх. Впереди еще много работы.
Как написать функциональное техническое задание?
Описывайте нужные функции в формате сценария использования. Такой формат позволяет сделать пункты ТЗ объективными, просто изложенными и элементарным способом проверяемыми требованиями.
Создание дизайна сайта или веб-приложения
Создание дизайна для сайта или веб-приложения — это самый субъективно оцениваемый этап разработки, часто вызывающий сложности как на этапе постановки задачи, так и на этапе сдачи-приёмки выполненных работ.
Использование экономических критериев в веб-разработке для оценки целесообразности реализации
В этой статье будут затронуты некоторые особенности разработки и поддержки ПО, которые основываются на экономических критериях оценки целесообразности.
​Создание сайта быстро, дешево, индивидуально и качественно
Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку».

Тематические технологии:

Язык программирования Ruby
Фреймворк Ruby on Rails
PostgreSQL — объектно-реляционная СУБД
Поисковая система ElasticSearch
СУБД Redis
Язык программирования Go
Язык программирования Python
Язык разметки HTML
CSS — каскадные таблицы стилей
Язык программирования JavaScript
Библиотека React
Библиотека MobX
Библиотека MobX State Tree
Система сборки WebPack
Платформа NodeJS
Red Hat Enterprise Linux