Фазы инкрементной модели ЖЦ разработки ПО

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

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

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

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

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

• · не требуется заранее тратить средства, необходимые для разработки всего проекта (поскольку сначала выполняется разработка и реализация основной функции или функции из группы высокого риска);
• · в результате выполнения каждого инкремента получается функциональный продукт;
• · заказчик располагает возможностью высказаться по поводу каждой разработанной версии системы;
• · правило по принципу «разделяй и властвуй» позволяет разбить возникшую проблему на управляемые части, благодаря чему предотвращается формирование громоздких перечней требований, выдвигаемых перед командой разработчиков;
• · существует возможность поддерживать постоянный прогресс в ходе выполнения проекта;
• · снижаются затраты на первоначальную поставку программного продукта;
• · ускоряется начальный график поставки (что позволяет соответствовать возросшим требованиям рынка);
• · снижается риск неудачи и изменения требований;
• · заказчики могут распознавать самые важные и полезные функциональные возможности продукта на более ранних этапах разработки;
• · риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки);
• · требования стабилизируются (посредством включения в процесс пользователей) на момент создания определенного инкремента, поскольку не являющиеся особо важными изменения отодвигаются на момент создания последующих инкрементов;
• · инкременты функциональных возможностей несут больше пользы и проще при тестировании, чем продукты промежуточного уровня при поуровневой разработке по принципу «сверху-вниз»
• · улучшается понимание требований для более поздних инкрементов (что обеспечивается благодаря возможности пользователя получить представление о раннее полученных инкрементов на практическом уровне);
• · в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика;
• · использование последовательных инкрементов позволяет объединить полученный пользователями опыт в виде усовершенствованного продукта, затратив при этом намного меньше средств, чем требуется для выполнения повторной разработки;
• · в процессе разработки можно ограничить количество персонала таким образом, чтобы над поставкой каждого инкремента последовательно работала одна и та же команда и все задействованные в процессе разработки команды не прекращали работу над проектом (график распределения рабочей силы может выравниваться посредством распределения по времени объема работы над проектом);
• · возможность начать построение следующей версии проекта на переходном этапе предыдущей версии сглаживает изменения, вызванные сменой персонала;
• · в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика;
• · потребности клиента лучше поддаются управлению, поскольку время разработки каждого инкремента очень незначительно;
• · поскольку переход из настоящего в будущее не происходит моментально, заказчик может привыкать к новой технологии постепенно;
• · ощутимые признаки прогресса при выполнении проекта помогают поддерживать вызванное соблюдением графика «давление» на управляемом уровне.