Модель инкрементальной сборки

редактировать

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

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

Содержание
  • 1 Инкрементная модель
  • 2 Задачи
  • 3 См. Также
  • 4 Ссылки
  • 5 Внешние ссылки
Инкрементальная модель

В инкрементальной модели применяется каскадная модель постепенно.

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

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

Характеристики инкрементальной модели

  1. Система разбита на множество мини-проектов разработки.
  2. Частичные системы создаются для создания окончательной системы.
  3. Сначала были рассмотрены требования наивысшего приоритета.
  4. Требование части замораживается после разработки увеличенной части.

Преимущества

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

Недостатки

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

Эти задачи являются общими для всех моделей

  1. Коммуникация: помогает понять цель.
  2. Планирование: требуется столько людей (программных команд), которые работают над одним проектом но разные функции одновременно.
  3. Моделирование: включает бизнес-моделирование, моделирование данных и моделирование процессов.
  4. Конструирование: включает повторное использование программных компонентов и автоматического кода.
  5. Развертывание: интеграция всех инкрементов.
См. Также
Ссылки
Внешние ссылки
Последняя правка сделана 2021-05-23 13:08:25
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте