Чем инкрементная модель отличается от итеративной
Перейти к содержимому

Чем инкрементная модель отличается от итеративной

  • автор:

Чем инкрементная модель отличается от итеративной

1.2.2.2. Инкрементальная (инкрементная, поступательная) модель разработки

1.2.2.2. Инкрементальная (инкрементная, поступательная) модель разработки

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

Смысловую путаницу вызывают понятия итеративной и инкрементальной разработки. Согласно Алистеру Кокбернц (Alistair Cockburn) здесь имеем дело с двумя разными моделями разработки:

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

Согласно Яну Соммервиллю (Ian Sommerville) «итеративная модель разработки» скорее общее название для ряда так называемых гибридных моделей (в том числе, и инкрементальная и спиральная модели). Слово «итеративный» подчеркивает то, что действия в этой модели повторяются.

Независимо от того смысла, который стоит за итеративной разработкой, инкрементальная (поэтапная) разработка довольно однозначно описана в различных источниках.

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

Рисунок 1-2. Инкрементальная разработка

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

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

Преимущества инкрементальной (поэтапной) разработки:

1. Затраты, которые получаются в связи с изменением требований пользователей, уменьшаются, повторный анализ и совокупность документации значительно сокращаются по сравнению с водопадной (каскадной) моделью.

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

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

Проблемы инкрементальной (поэтапной) разработки:

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

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

Гибкие (ускоренные, agile) методы разработки

Для гибких методов разработки пригодно использование инкрементальной модели. Начало распространения гибкого метода разработки программного обеспечения уходит в 2001 год, когда те, кто отвечали за тогдашнее перепланирование методов разработки, подписали «Манифест гибкой разработки» (или просто «Гибкий манифест», «The Agile Manifesto»), в котором в наиболее важные пунктах внимание акцентируется на человеке и на взаимодействии между людьми:

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

Больше считаются с информацией, полученной в процессе обратной связи (нагрузочное тестирование, мнение пользователей и т.д.), чем полагаются на предварительное тщательное планирование технологии. Основное внимание уделяется людям, в том числе пользователям и постоянному тестированию. Говорят, что с гибким методом достигается лучший результат за те же деньги, однако при использовании гибкого метода труднее заранее запланировать, когда какая-то функция программного обеспечения будет готова — «Agile process will provide the most bang for the buck, but won’t say exactly when that bang will be». («Agile-процесс обеспечит максимальную отдачу, но не скажет точно, когда это произойдет».)

Наиболее известными и наиболее распространенными гибкими методами являются экстремальное программирование (XP), Scrum, Feature Driven Development (FDD), Open Unified Process (OpenUP) и др.

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

SDLC – итерационная инкрементальная модель

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

Итерации

Итеративная инкрементная модель – Сильные стороны

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

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

Сначала вы можете разработать приоритетные требования.

Начальная доставка товара происходит быстрее.

Клиенты получают важные функциональные возможности рано.

Снижает первоначальную стоимость доставки.

Каждый выпуск представляет собой инкремент продукта, поэтому у клиента всегда будет под рукой рабочий продукт.

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

Изменения требований могут быть легко учтены.

Итерационная Инкрементальная Модель – Слабые стороны

Недостатками Итеративной инкрементальной модели являются –

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

Требуется эффективное планирование итераций.

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

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

Необходимы четко определенные интерфейсы модулей, поскольку некоторые из них разработаны задолго до разработки других.

Общая стоимость всей системы не ниже.

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

Итеративная инкрементная модель может использоваться, когда:

Большинство требований известны заранее, но, как ожидается, со временем будут развиваться.

Требования являются приоритетными.

Существует необходимость в быстрой доставке базовой функциональности.

Проект имеет длительные графики развития.

Проект имеет новые технологии.

Домен является новым для команды.

iterative

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

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

В несколько упрощенном виде, итеративная модель состоит из четырех основных стадий, которые повторяются в каждой из итераций (plan-do-check-act):

– определение и анализ требований;

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

– разработка и тестирование – кодирование, интеграция и тестирование нового компонента;

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

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

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

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

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

Плюсы и минусы итеративной модели:

+ раннее создание работающего ПО;

+ гибкость – готовность к изменению требований на любом этапе разработки;

+ каждая итерация – маленький этап, для которого тестирование и анализ рисков обеспечить проще, чем для всего жизненного цикла продукта.

— каждая фаза – самостоятельна, отдельные итерации не накладываются;

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

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

– для крупных проектов;

– когда известны, по крайней мере, ключевые требования;

– когда требования к проекту могут меняться в процессе разработки.

Итеративная модель ­является ключевым элементом так называемых «гибких» (Agile) подходов к разработке программного обеспечения, основные из которых мы рассмотрим в следующих разделах.

  • Выбери курс для обучения
    • Тестирование
      • Базовый модуль тестирования
      • Тестирование ПО
      • Тестирование WEB-сервисов
      • Тестирование мобильных приложений
      • Тестирование нагрузки с JMeter
      • Расширенный модуль автоматизации тестирования
      • Автоматизация тестирования с Selenium WebDriver (Python)
      • Автоматизация тестирования с Selenium WebDriver (Java)
      • Автоматизация тестирования с Selenium WebDriver (C#)
      • Автоматизация тестирования на JavaScript
      • Java для автоматизаторов
      • Fullstack Web Developer
      • Java
      • Python
      • JavaScript
      • HTML5 И CSS3
      • Полный стек разработки на фреймворке Laravel
      • Разработка CMS на основе PHP
      • Git для автоматизаторов
      • Практический SQL
      • Основы Unix и сети
      • WEB-серверы и WEB-сервисы
      • Создание проекта автоматизации и написания UI тестов
      • Составление комбинированных тестов UI и API. Написание BDD тестов
      • IT Project Manager
      • HR-менеджер в ИТ-компании
      • Как правильно составить резюме и пройти собеседование
      • Подготовка к сертификации ISTQB Foundation Level на основе Syllabus Version 2018
      • Тестирование
        • Базовый модуль тестирования

        Чем итеративная модель отличается от инкрементной

        Иногда можно увидеть термин «итеративно-инкрементная модель разработки». Можно подумать, что авторы считают, что итеративная и инкрементная модели – одно и то же. Так ли это?

        Тестировщик » QA-блог » База » Чем итеративная модель отличается от инкрементной
        10 месяцев назад 4 1669

        Итеративная и инкрементная модели: в чем разница

        Хотя обе модели были разработаны, чтобы повысить гибкость «Водопада», они различаются. Итеративная подразумевает постепенное приближение циклами к финальному результату, а инкрементная – приращение по частям.

        На изображение чем итеративная модель отличается от инкрементной.

        В свете аналогий с другими повседневными предметами: можно создавать их все более и более совершенные версии, а можно сформировать отдельные части и затем объединить в целое.

        Что такое модель разработки ПО

        Модель разработки — это концепция создания программного обеспечения, определяющая ключевые подходы к проектированию, программированию, тестированию и т.д. Современные IT-команды используют модели разработки, чтобы:

        • Организовать свою деятельность;
        • Определиться в необходимых ресурсах для проекта;
        • Сориентироваться в сроках разработки;
        • Адаптировать тестирование под специфику проекта;
        • Обеспечить экономическую эффективность IT-продукта;
        • Регламентировать взаимодействие (как внутреннее, так и внешнее, со стейкхолдерами и клиентом).

        Иногда в отношении модели разработки ПО применяется термин жизненный цикл программного обеспечения (Software Development Life Cycle, SDLC).

        В чем особенность итеративной модели

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

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

        • Нет необходимости в четко определенном техническом задании на старте проекта;
        • Быстрый выпуск продукта, хотя и с минимальными функциями;
        • Раннее обнаружение дефектов – снижение затрат на их исправление;
        • Экономия ресурсов – не нужно разрабатывать невостребованные функции;
        • Возможность использовать накопленный опыт из предыдущих итераций.

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

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

        В чем особенность инкрементной модели

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

        Плюсы инкрементной модели разработки:

        • Быстрая разработка базовой модификации как работоспособного продукта;
        • Клиент видит созданные инкременты и сразу дает обратную связь;
        • Можно вносить изменения в продукт поэтапно;
        • Можно снизить вложения в продукт, отказавшись от реализации некоторых инкрементов;
        • Раннее обнаружение дефектов – снижение затрат на их исправление.

        Минусы инкрементной модели разработки:

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

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

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

        Итеративно-инкрементная модель разработки

        Все чаще в практике IT-компаний используется итеративно-инкрементная модель. Это гибрид, он объединяет в себе оба подхода. Например, разработка инкрементов может происходить параллельно и циклами (итеративно).

        Итеративно-инкрементная усиливает в себе плюсы и нивелирует минусы обеих моделей разработки.

        Резюме

        В истории развития программного обеспечения есть две модели, которые более гибкие, чем классический «Водопад»: итеративная и инкрементная. Итеративная предполагает разработку ПО циклам и целиком, инкрементная – по частям. Существует также созданная на основе их объединения гибридная модель – итеративно-инкрементная.

        на изображение автор Михаил Кулешов

        Автор Михаил Кулешов

        Михаил, профессиональный партнерский маркетолог, является основателем компании South Media OÜ, которая была создана в 2018 году и базируется в Таллинне. С 2016 года Михаил уехал из Финляндии и жил как настоящий «цифровой кочевник» в IT-индустрии, путешествуя по миру только с ноутбуком. Михаил работает и пишет статьи, связанные с IT-индустрией.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *