Инкрементная модель жизненного цикла информационной системы

Для организации инкрементной разработки выбирается определенный временной интервал, например, неделя. В течение этого периода происходит обновление исходного проекта. Теоретически шаги разработки могут выполняться и параллельно, но такую работу очень сложно скоординировать. Лучше всего инкрементная разработка проходит тогда, когда следующая стадия n+1 начинается после того, как обновление всех модулей на стадии n завершено.

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

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

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

Преимущества инкрементной модели:

• -Получение функционального продукта после реализации каждого инкремента;
• -Предотвращение формирования громоздких перечней требований;
• -Стабилизация требований во время создания каждого инкремента за счет короткой продолжительности его создания, включения в процесс пользователей и возможности отодвигания не важных изменений на последующие инкременты;
• -Улучшение понимания требований для более поздних инкрементов за счет практической работы с наиболее разработанными инкрементами;
• -Улучшение тестирования инкрементов по сравнению с продуктами промежуточных уровней при разработке систем по методу нисходящего проектирования;
• -Возможность пересмотра рисков, связанных с затратами и соблюдением установленного графика в конце каждой инкрементной поставки;
• -Снижение риска неудачи и пересмотра требований;
• -Распределение риска между несколькими небольшими инкрементами, что сокращает его общую величину;
• -Снижение затрат на первоначальную поставку программного продукта;
• -Возможность управляемого распределения средств с учетом важности реализуемых в инкременте функций;
• -Ускорение начального графика поставки и графика всего проекта в целом;
• -Возможность выравнивания графика распределения рабочей силы посредством распределения по времени объема работы над проектом, что в итоге приводит к сокращению общего числа участников проекта;
• -Упрощение работы над проектом при смене состава разработчиков;
• -Возможности поддержания постоянного прогресса продукта, разработчиков и технологий в ходе прогресса проекта;
• -Постепенное привыкание заказчика к системе;
• -Возможность оценки заказчиком наиболее важных функциональных особенностей продукта на более ранних этапах разработки;
• -Незначительное время разработки каждого инкремента, что упрощает работу с потребностями заказчика.

ГОСТ Р ИСО/МЭК ТО 15 271−2002 выделяет следующие достоинства инкрементной модели:

• -Необходимость изначального использования характеристик системы;
• -Пригодность для использования промежуточного продукта;
• -Естественное разделение системы на наращиваемые компоненты;
• -Возможности наращивания привлекаемого персонала и средств.

Этим же документом отмечен ряд недостатков инкрементного подхода к созданию ИС в случае его использования для создания не подходящего к данной модели проекта:

• -Непредусмотренность итераций в рамках каждого инкремента модели;
• -Необходимость полного функционального определения системы в самом начале жизненного цикла в целях обеспечения определения инкрементов и управления проектом;
• -Недостаточно четкое определение требований;
• -Необходимость создания интерфейсов между модулями, связанная с различными сроками их создания;
• -Сложность формального анализа и проверки отдельных инкрементов;
• -Наличие тенденции к оттягиванию решения трудных проблем на более поздние инкременты и связанные с этим задержки работ;
• -Возможность изменения в технологиях работ, что дает возможность нарушения их графика;
• -Нежелательность для руководства использования на этапе анализа общих целей вместо полностью сформулированных требований;
• -Возможность изменения требований к системе, уже реализованных в предыдущих инкрементах;
• -Необходимость хорошего планирования и проектирования, грамотного распределения работы;
• -Ограниченность привлечения ресурсов на длительный срок.

Область применения инкрементной модели:

Менеджер проекта может быть уверен в целесообразности применения инкрементной модели если:

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

Недостатки инкрементной модели разработки:

• -В модели не предусмотрены итерации в рамках каждого инкремента;
• -Определение полной функциональности системы должно осуществляться в начале жизненного цикла, чтобы обеспечить определение инкрементов;
• -Формальный критический анализ намного сложнее выполнить для инкрементов, чем для системы в целом;
• -Невозможность снижения затрат проекта;
• -Необходимость в четко определенных интерфейсах;
• -Использование на этапе анализа общих целей вместо полностью сформулированных требований может оказаться неудобным для руководства;
• -Для модели необходимы четкое проектирование и моделирование: руководство должно заботиться о распределении работы, а технический персонал должен соблюдать субординацию в отношениях между сотрудниками;
• -Может возникнуть тенденция к решению трудных проблем на будущее с целью продемонстрировать руководству успех, достигнутый на ранних этапах разработки.