Обзор моделей жизненного цикла разработки программного обеспечения

Инкрементная  модель жизненного цикла  разработки ПО

 

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

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

     Подобное  усовершенствование каскадной модели одинаково эффективно при использовании как в случае чрезвычайно больших, так и небольших проектов.  

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

 

     Менеджер  проекта может быть уверен в целесообразности применения модели, если для этого  имеются следующие причины:

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

Спиральная  модель жизненного цикла  разработки ПО

 

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

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

     

 

     Рис. 6.  Спиральная модель 
 

    Стадии  разработки спиральной модели

 

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

• определение целей, альтернативных вариантов и ограничений.

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

• оценка альтернативных вариантов, идентификация и разрешение рисков.

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

• разработка продукта следующего уровня.

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

• планирование следующей фазы.

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

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

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

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

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

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