Инкрементная модель в SDLC: использование, преимущества и недостатки
Лукас Беннетт
Что такое инкрементальная модель?
Инкрементальная модель - это процесс разработки программного обеспечения, в котором требования разбиваются на несколько отдельных модулей цикла разработки программного обеспечения. Инкрементальная разработка выполняется поэтапно: от проектирования анализа, внедрения, тестирования / проверки, сопровождения.
Каждая итерация проходит через требования, этапы проектирования, кодирования и тестирования. И каждый последующий выпуск системы добавляет функции к предыдущему выпуску до тех пор, пока весь задуманный функционал не будет реализован.
Система запускается в производство после поставки первого приращения. Первый шаг часто является основным продуктом, в котором удовлетворяются основные требования, а в следующих шагах добавляются дополнительные функции. После того, как клиент проанализирует основной продукт, разрабатывается план следующего шага.
Характеристики инкрементного модуля включают в себя
- Разработка системы разбита на множество мини-проектов разработки.
- Частичные системы последовательно строятся для создания окончательной полной системы.
- Требование с наивысшим приоритетом выполняется в первую очередь
- После того как требование разработано, требования к этому приращению замораживаются.
| Дополнительные фазы | Действия, выполняемые поэтапно |
|---|---|
| Анализ требований |
|
| Дизайн |
|
| Code |
|
| Тест |
|
Когда использовать инкрементные модели?
- Требования системы четко понятны
- Когда возникает спрос на досрочный выпуск продукта
- После появления разработка программного обеспечения команда не очень хорошо квалифицирована или обучена
- Когда задействованы функции и цели высокого риска
- Такая методология больше используется для компаний, занимающихся веб-приложениями и продуктами.
Преимущества и недостатки инкрементной модели
| Наши преимущества | Недостатки бонуса без депозита |
|---|---|
| Программное обеспечение будет создаваться быстро в течение жизненного цикла программного обеспечения. | Это требует хорошего планирования проектирования |
| Изменение требований и масштаба является гибким и менее затратным. | Проблемы могут возникнуть из-за архитектуры системы как таковой, не все требования собраны заранее на протяжении всего жизненного цикла программного обеспечения. |
| На всех этапах разработки могут быть внесены изменения. | Каждая фаза итерации является жесткой и не перекрывает друг друга. |
| Эта модель дешевле других. | Устранение проблемы в одном блоке требует исправления во всех блоках и отнимает много времени. |
| Клиент может ответить на каждое здание | |
| Ошибки легко обнаружить |
