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 шаги делаются крайне (экстремально – отсюда и наименование метода) недолгими по сравнению с традиционными моделями разработки – первый законченный этап шагов может быть длительностью в несколько дней или неделю, тогда, как в классических моделях он продолжается месяцы и годы. Перед кодированием пишутся автоматизированные тесты, которые должно пройти программное обеспечение, затем программируют парами (то есть, два программиста за одним компьютером кодируют один программный отрывок – так называемое «парное программирование»). Если готовый код проходит тесты (испытания), то шаг программирования в данной итерации закончен.