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

Разработка каждого интегрированного продукта ограничивается четко определенным периодом времени, который, как правило, составляет 60 дней и называется временным блоком.

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

Фазы модели RAD

Модель RAD проходит через следующие фазы:

· этап планирования требований - сбор требований выполняется при использовании рабочего метода, называемого совместным планированием требований (Joint requirements planning, JRP), который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач;

· пользовательское описание - совместное проектирование приложения (Joint application design, JAD) используется с целью привлечения пользователей; на этой фазе проектирования системы, не являющейся промышленной, работающая над проектом команда зачастую использует автоматические инструментальные средства, обеспечивающие сбор пользовательской информации;

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

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

·

Рис. 5. Модель быстрой разработки приложений

Преимущества модели RAD

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

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

· требуется меньшее количество специалистов (поскольку разработка системы выполняется усилиями команды, осведомленной в предметной области);

· существует возможность произвести быстрый изначальный просмотр продукта;

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

· благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика;

· обеспечивается эффективное использование имеющихся в наличии средств и структур;

· постоянное присутствие заказчика сводит до минимума риск неудовлетворения продуктом и гарантирует соответствие системы коммерческим потребностям и надёжность программного продукта в эксплуатации;

· в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);

· интеграции констант предотвращают возникновение проблем и способствуют созданию обратной связи с потребителем;

· основное внимание переносится с документации на код, причем при этом справедлив принцип "получаете то, что видите" (What you see is what you get, WYSIWYG);

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

· повторное использование компонент уже существующих программ.

Недостатки модели RAD

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

· Непостоянное участие пользователя может негативно сказаться на конечном продукте (т.е. если пользователи не могут постоянно принимать участие в процессе разработки на протяжении всего жизненного цикла, это может негативно сказаться на конечном продукте);

· при использовании этой модели необходимо достаточное количество высококвалифицированных разработчиков, (умеющих воспользоваться выбранными инструментальными средствами разработки для ускорения времени разработки);

· использование модели может оказаться неудачным в случае отсутствия пригодных для повторного использования компонент;

· могут возникать затруднения при использовании модели совместно с наследственными системами и несколькими интерфейсами;

· возникает потребность в системе, которая может быть смоделирована корректным образом;

· для реализации модели требуются разработчики и заказчики, которые готовы к быстрому выполнению действий ввиду жестких временных ограничений;

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

· при использовании модели "вслепую" на затраты и дату завершения работы над проектом ограничения не накладываются;

· команды, разрабатывающие коммерческие проекты с помощью модели RAD, могут "затянуть" разработку программного продукта до такой степени, что его поставка конечному пользователю будет под большим вопросом;

· существует риск, что работа над проектом никогда не будет завершена, - в связи с этим менеджер проекта должен сотрудничать как с командой разработчиков, так и с заказчиком, что позволит избежать появления замкнутого цикла;

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

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

· в системах, которые поддаются моделированию (тех которые основаны на использовании компонентных объектов), а также в масштабируемых системах;

· в системах, требования для которых в достаточной мере хорошо известны;

· в случаях, когда конечный пользователь может принимать участие в процессе разработки на протяжении всего жизненного цикла;

· когда пользователи хотят принимать активное участие в использовании автоматических инструментальных средств;

· при невысокой степени технических рисков;

· при выполнении проектов, разработка которых должна быть выполнена в сокращенные сроки (как правило, не более, чем за 60 дней);

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

· когда пригодные к повторному использованию части можно получить из автоматических хранилищ программных продуктов;

· в системах, которые предназначены для концептуальной проверки, являются некритическими или имеют небольшой размер;

· когда затраты и соблюдение графика не являются самым важным вопросом (например при разработке внутренних инструментальных средств);

· в информационных системах;

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

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

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

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

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

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

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

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

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

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

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

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

· не требуется заранее тратить средства, необходимые для разработки всего проекта (поскольку сначала выполняется разработка и реализация основной функции или функции из группы высокого риска);

· в результате выполнения каждого инкремента получается функциональный продукт;

· заказчик располагает возможностью высказаться по поводу каждой разработанной версии системы;

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

· существует возможность поддерживать постоянный прогресс в ходе выполнения проекта;

· снижаются затраты на первоначальную поставку программного продукта;

· ускоряется начальный график поставки (что позволяет соответствовать возросшим требованиям рынка);

· снижается риск неудачи и изменения требований;

· заказчики могут распознавать самые важные и полезные функциональные возможности продукта на более ранних этапах разработки;

· риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки);

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

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

· улучшается понимание требований для более поздних инкрементов (что обеспечивается благодаря возможности пользователя получить представление о раннее полученных инкрементов на практическом уровне);

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

· использование последовательных инкрементов позволяет объединить полученный пользователями опыт в виде усовершенствованного продукта, затратив при этом намного меньше средств, чем требуется для выполнения повторной разработки;

· в процессе разработки можно ограничить количество персонала таким образом, чтобы над поставкой каждого инкремента последовательно работала одна и та же команда и все задействованные в процессе разработки команды не прекращали работу над проектом (график распределения рабочей силы может выравниваться посредством распределения по времени объема работы над проектом);

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

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

· потребности клиента лучше поддаются управлению, поскольку время разработки каждого инкремента очень незначительно;

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

· ощутимые признаки прогресса при выполнении проекта помогают поддерживать вызванное соблюдением графика "давление" на управляемом уровне.

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

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

· в модели не предусмотрены итерации в рамках каждого инкремента;

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

· формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом;

· заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены;

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

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

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

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

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

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

· если большинство требований можно сформулировать заранее, но их появление ожидается через определенный период времени;

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

· для проектов, на выполнение которых предусмотрен большой период времени разработки, как правило, один год;

· при равномерном распределении свойств различной степени важности;

· когда при рассмотрении риска, финансирования, графика выполнения проекта, размера программы, ее сложности или необходимости в реализации на ранних фазах оказывается, что самым оптимальным вариантом является применение принципа пофазовой разработки;

· при разработке программ, связанных с низкой или средней степенью риска;

· при выполнении проекта с применением новой технологии, что позволяет пользователю адаптироваться к системе путем выполнения более мелких инкрементных шагов, без резкого перехода к применению основного нового продукта;

· когда однопроходная разработка системы связана с большой степенью риска;

· когда результативные данные получаются через регулярные интервалы времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· спиральная модель разрешает пользователям "увидеть" систему на ранних этапах, что обеспечивается посредством использования ускоренного прототипирования в жизненном цикле разработки ПО;

· обеспечивается определение непреодолимых рисков без особых дополнительных затрат;

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

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

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

· реализованы преимущества инкрементной модели, а именно выпуск инкрементов, сокращение графика посредством перекрывания инкрементов, рассортированных по версиям, и неизменяемость ресурсов при постепенном росте системы;

· здесь не ставится цель выполнить невозможное - довести конструкцию до совершенства;

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

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

· повышается продуктивность благодаря использованию пригодных для повторного использования свойств;

· повышается вероятность предсказуемого поведения системы с помощью уточнения поставленных целей;

· при использовании спиральной модели не нужно распределять заранее все необходимые для выполнения проекта финансовые ресурсы;

· можно выполнять частую оценку совокупных затрат, а уменьшение рисков связано с затратами.

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

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

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

· модель имеет усложненную структуру, поэтому может быть затруднено ее применение разработчиками, менеджерами и заказчиками;

· серьезная нужда в высокопрофессиональных знаниях для оценки рисков;

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

· большое количество промежуточных стадий может привести к необходимости в обработке внутренней дополнительной и внешней документации;

· использование модели может оказаться дорогостоящим и даже недопустимым по средствам, так как время, затраченное на планирование, повторное определение целей, выполнение анализа рисков и прототипирование, может быть чрезмерным;

· при выполнении действий на этапе вне процесса разработки возникает необходимость в переназначении разработчиков;

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

· отсутствие хорошего средства или метода прототипирования может сделать использование модели неудобным;

· в производстве использование спиральной модели еще не получило такого широкого масштаба, как применение других моделей.

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

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

· когда создание прототипа представляет собой подходящий тип разработки продукта;

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

· когда организация обладает навыками, требуемыми для адаптации модели;

· для проектов, выполнение которых сопряжено со средней и высокой степенью риска;

· когда нет смыла браться за выполнение долгосрочного проекта из-за потенциальных изменений, которые могут произойти в экономических приоритетах, и когда такая неопределенность может вызвать ограничение во времени;

· когда речь идет о применении новой технологии и когда необходимо протестировать базовые концепции;

· когда пользователи не уверены в своих потребностях;

· когда требования слишком сложные;

· при разработке новой функции или новой серии продуктов;

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

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

· в случае больших проектов;

· для организаций, которые не могут себе позволить выделить заранее все необходимые для выполнения проекта денежные средства, и когда в процессе разработки отсутствует финансовая поддержка;

· при выполнении затянувшихся проектов, которые могут вызывать раздражение у менеджеров и заказчиков;

· когда преимущества разработки невозможно точно определить, а достижение успеха не гарантировано;

· с целью демонстрации качества и достижения целей за короткий период времени;

· когда в процесс вовлекаются новые технологии, такие как впервые применяемые объектно-ориентированные принципы;

· при разработке систем, требующих большого объема вычислений, таких как систем, обеспечивающих принятие решений;

· при выполнении бизнес-проектов, а также проектов в области аэрокосмической промышленности, обороны и инжиниринга, где использование спиральной модели уже получило популярность.

Адаптированные модели жизненного цикла разработки ПО

Иногда менеджер проекта выбирает модель жизненного цикла из какой-нибудь книги и затем руководствуется ею в процессе разработки. В других случаях может оказаться, что отсутствует именно та модель, которая в достаточной мере соответствовала бы потребностям проекта. Предположим, что требуется жизненный цикл, в котором предусмотрены возможные риски, но применение спиральной модели неоправданно. В этом случае нужно начать со спиральной модели и адаптировать ее к определенным потребностям. А если необходимо обеспечить функциональные возможности на уровне инкрементов, но также необходимо принять во внимание вопросы, связанные с надежностью системы? Тогда потребуется объединить инкрементную модель с V-образной моделью. Далее приведено несколько примеров адаптированных моделей.

Быстрое отслеживание

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

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

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

Параллельный инжиниринг

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

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

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

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

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

Спиральная модель "Win-Win"

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

В этом методе, основанном на постоянном согласовании, циклы состоят из следующих фаз или стадий:

· определение участников следующего уровня;

· определение условий, необходимых для одержания участниками победы;

· согласование "победных" условий;

· формулирование целей, ограничений и альтернативных вариантов следующего уровня;

· оценка альтернативных вариантов на уровне продукта и процесса, разрешение рисков;

· определение следующего уровня продукта и процесса, включая сегментацию;

· обоснование определений продукта и процесса;

· обзор и комментарии.

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

Спиральная модель "win-win" имеет следующие преимущества:

· более быстрая разработка ПО благодаря содействию, оказываемому участниками проекта;

· уменьшение стоимости программ благодаря уменьшению объема переработок и текущего сопровождения;

· более высокий уровень удовлетворения со стороны участников проекта, достигаемого до разработки самого продукта;

· более высокое качество ПО благодаря использованию компромиссных качественно-атрибутивных моделей на уровне архитектуры;

· исследование большого количества вариантов построения архитектуры на ранних этапах разработки.

Эволюционный/инкрементный принцип

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

· является ли решение о разработке текущих функциональных свойств хорошей идеей с учетом текущего объема финансирования?

· наступило ли уже время рассматривать функциональные возможности системы (приоритеты пользователя, требования процесса эволюции)?

· стоят ли добавленные функциональные возможности потраченных на них средств (или "покрывается позолотой" лишь одна область функциональных возможностей прежде, чем будут разработаны все необходимые характеристики системы)?

· хватит ли у нас объема денежных средств на разработку требуемой системы в полном объеме?

Принцип V-образной инкрементной модели

Разработка хорошей модели жизненного цикла проекта означает заблаговременные капиталовложения, например, создание традиционной V-образной модели, смешанной с инкрементной, итеративной моделью разработки.

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

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

Выбор приемлемой модели жизненного цикла разработки ПО

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

1. Проанализируйте следующие отличительные категории проекта, помещенные в таблицах 1-4:

· Требования: таблица 1.

· Команда разработчиков: таблица 2.

· Коллектив пользователей: таблица 3.

· Тип проекта и риски: таблица 4.

2. Ответьте на вопросы, приведенные для каждой категории, обведя кружочком слова "да" или "нет".

3. Расположите по степени важности категории или вопросы, относящиеся к каждой категории, относительно проекта, для которого выбирается приемлемая модель.

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

Отличительные категории проекта

Ниже приводится краткое описание характеристик и требований к команде разработчиков, коллективу пользователей, типу проекта и рискам. В табл. 1-4 приведен набор матриц, предназначенных для использования на стадиях 1-5 процесса выбора модели жизненного цикла, описание которого было приведено в предыдущем разделе.

Требования. Категория требований (таблица 1) состоит из вопросов относительно требований, которые предъявляет пользователь к проекту. В терминологии их иногда называют свойствами системы, которая будет поддерживаться данным проектом.

Таблица 1. Выбор модели жизненного цикла на основе характеристик требований

Требования	Каскад- Ная	V-образ- ная	Прототи- пирование	Спираль- ная	RAD	Инкре- ментная
Являются ли требования легко определимыми и/или хорошо известными?	Да	Да	Нет	Нет	Да	Нет
Могут ли требования заранее определяться в цикле?	Да	Да	Нет	Нет	Да	Да
Часто ли будут изменяться требования в цикле?	Нет	Нет	Да	Да	Нет	Нет
Нужно ли демонстрировать требования с целью определения?	Нет	Нет	Да	Да	Да	Нет
Требуются ли для демонстрации возможностей проверка концепции?	Нет	Нет	Да	Да	Да	Нет
Будут ли требования отражать сложность системы?	Нет	Нет	Да	Да	Нет	Да
Обладает ли требование функциональными свойствами на раннем этапе?	Нет	Нет	Да	Да	Да	Да

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

Таблица 2. Выбор модели жизненного цикла на основе характеристик участников команды разработчиков

Команда разработчиков проекта	Каскад- ная	V-образ- ная	Прототи- пирование	Спираль- ная	RAD	Инкре- ментная
Являются ли проблемы предметной области проекта новыми для большинства разработчиков?	Нет	Нет	Да	Да	Нет	Нет
Является ли технология предметной области проекта новой для большинства разработчиков?	Да	Да	Нет	Да	Нет	Да
Являются ли инструменты, используемые проектом, новыми для большинства разработчиков?	Да	Да	Нет	Да	Нет	Нет
Изменяются ли роли участников проекта во время жизненного цикла?	Нет	Нет	Да	Да	Нет	Да
Могут ли разработчики проекта пройти обучение?	Нет	Да	Нет	Нет	Да	Да
Является ли структура более значимой для разработчиков, чем гибкость?	Да	Да	Нет	Нет	Нет	Да
Будет ли менеджер проекта строго отслеживать прогресс команды?	Да	Да	Нет	Да	Нет	Да
Важна ли легкость распределение ресурсов?	Да	Да	Нет	Нет	Да	Да
Приемлет ли команда равноправные обзоры и инспекции, менеджмент/обзоры заказчика, а также стадии?	Да	Да	Да	Да	Нет	Да

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

Таблица 3. Выбор модели жизненного цикла на основе характеристик коллектива пользователей

Коллектив пользователей	Каскад- ная	V-образ- ная	Прототи- пирование	Спираль- ная	RAD	Инкре- ментная
Будет ли присутствие пользователей ограничено в жизненном цикле?	Да	Да	Нет	Да	Нет	Да
Будут ли пользователи знакомы с определением системы?	Нет	Нет	Да	Да	Нет	Да
Буду ли пользователи ознакомлены с проблемами предметной области?	Нет	Нет	Да	Нет	Да	Да
Будут ли пользователи вовлечены во все фазы жизненного цикла?	Нет	Нет	Да	Нет	Да	Нет
Будет ли заказчик отслеживать ход выполнения проекта?	Нет	Нет	Да	Да	Нет	Нет

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

Таблица 4. Выбор модели жизненного цикла на основе характеристик типа проектов и рисков

Тип проекта и риски	Каскад- ная	V-образ- ная	Прототи- пирование	Спираль- ная	RAD	Инкре- ментная
Будет ли проект идентифицировать новое направление продукта для организации?	Нет	Нет	Да	Да	Нет	Да
Будет ли проект иметь тип системной интеграции?	Нет	Да	Да	Да	Да	Да
Будет ли проект являться расширением существующей системы?	Нет	Да	Нет	Нет	Да	Да
Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла?	Да	Да	Да	Нет	Да	Нет
Ожидается ли длительная эксплуатация продукта в организации?	Да	Да	Нет	Да	Нет	Да
Должна ли быть высокая степень надежности?	Нет	Да	Нет	Да	Нет	Да
Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения?	Нет	Нет	Да	Да	Нет	Да
Является ли график ограниченным?	Нет	Нет	Да	Да	Да	^ J
Являются ли "прозрачными" интерфейсные модули?	Да	Да	Нет	Нет	Нет	Да
Доступны ли повторное используемые компоненты?	Нет	Нет	Да	Да	Да	Нет
Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)?	Нет	Нет	Да	Да	Нет	Нет

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

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

Согласно модели SEI СММ, не существует каких-либо четких предписаний на сей счет: "Руководящие принципы и критерии для адаптации стандартного процесса разработки ПО данной организации к выбранным проектам получают путем разработки и последующего утверждения", а также "определенный процесс разработки ПО в рамах данного проекта является адаптированной версией стандартного процесса разработки ПО для данной организации".

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

А что будет в том случае, если при выполнении проекта происходят какие-либо изменения, которые заставляют команду прийти к мысли, что другая модель была бы более действенной? Можно ли изменить модель в процессе выполнения проекта? Ответ на этот вопрос почти всегда положительный, но это следует сделать с обязательным учетом возможных последствий таких изменений для проекта. В крайнем случае, лучше изменить модель, чем пытаться использовать ту, которая не подходит в достаточной степени для соответствия потребностям проекта.

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

1. Ознакомьтесь с различными моделями.

2. Просмотрите и проанализируйте возможные виды работ: разработка, модернизация, сопровождение и т.д.

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

4. Проанализируйте, насколько выбранный жизненный цикл соответствует стандартам вашей организации, ваших заказчиков или типа проекта - ISO, IEEE и т.д.

5. Сформулируйте набор фаз и действий, образующих каждую фазу.

6. Определите внутренние и внешние производимые продукты.

7. Определите шаблоны и внутреннее содержимое поставляемых продуктов.

8. Определите действия по обзору, инспектированию, верификации и аттестации, а также стадии проекта.

9. Выполните оценку эффективности схемы жизненного цикла и проведите ее модернизацию там, где это необходимо.

Часто применяемый метод подгонки жизненных циклов заключается в комбинировании моделей. Два примера подобной подгонки изображены на рис. 4.19 и 4.20.

Резюме

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

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

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

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

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

Размещено на Allbest.ru

...