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

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

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

Инкрементальная модель [ править ]

В инкрементальной модели водопадная модель применяется постепенно. ^[1]

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

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

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

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

Преимущества ^{[3] [4]}

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

Недостатки ^[5]

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

Задания [ править ]

Эти задачи общие для всех моделей ^[1]

1. Коммуникация: помогает понять цель.
2. Планирование: требуется, чтобы над одним проектом, но разными функциями одновременно работало столько людей (команд разработчиков).
3. Моделирование: включает бизнес-моделирование, моделирование данных и моделирование процессов.
4. Строительство: это включает в себя повторное использование программных компонентов и автоматического кода.
5. Развертывание: интеграция всех инкрементов.

См. Также [ править ]

• Итеративная и инкрементальная разработка
• Быстрая разработка приложений
• Поэтапный подход

Ссылки [ править ]

Внешние ссылки [ править ]

• Методология :: Модели развития
• Инкрементальный жизненный цикл
• Что такое инкрементальная модель - преимущества, недостатки и когда ее использовать
• Инкрементальная модель в программной инженерии