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

Понятие Инкремент (от англ. increment «увеличение») – постепенно увеличивающий, чаще всего под инкрементом подразумевается увеличение переменной на 1 единицу.

Модель инкрементального процесса также известна как модель последовательной версии.

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

Incremental process model Инкрементальная модель разработки программного обеспечения
Incremental process model Инкрементальная модель разработки программного обеспечения

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

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

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

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

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

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

Начиная с версии 1, в каждом последовательном приращении создается следующая версия, которая затем развертывается на платформе заказчика. После последней версии (версии n) происходит окончательная поставка продукта клиенту.

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

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

Модель поэтапной реализации – разработка только одной части проекта за раз.

Модель параллельной разработки – одновременно разрабатываются разные подсистемы. Это может уменьшить календарное время, необходимое для разработки, то есть время выхода на рынок, если доступно достаточное количество ресурсов.

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

  • Требования к системе понятны и известны заранее.
  • Когда имеется потребность на досрочный выпуск продукта.
  • Когда команда разработчиков программного обеспечения недостаточно квалифицирована или обучена.
  • Когда задействованы функции и цели высокого риска.
  • Проекты с новыми технологиями.

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

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

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

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

 

 

 

от Janberg