Адаптированные модели жизненного цикла разработки ПО
Иногда менеджер проекта выбирает модель жизненного цикла из какой-нибудь книги и затем руководствуется ею в процессе разработки. В других случаях может оказаться, что отсутствует именно та модель, которая в достаточной мере соответствовала бы потребностям проекта. Предположим, что требуется жизненный цикл, в котором предусмотрены возможные риски, но применение спиральной модели неоправданно. В этом случае нужно начать со спиральной модели и адаптировать ее к определенным потребностям. А если необходимо обеспечить функциональные возможности на уровне инкрементов, но также необходимо принять во внимание вопросы, связанные с надежностью системы? Тогда потребуется объединить инкрементную модель с V-образной моделью. Далее приведено несколько примеров адаптированных моделей.
Быстрое отслеживание
Методология построения жизненного цикла по принципу быстрого отслеживания заключается в ускоренном прохождении или пропуске одного или нескольких фаз жизненного цикла или процессов разработки. Многие или большинство из стандартных стадий разработки выполняются в обычном режиме, в то время как выполнение других стадий и их область действия могут быть сокращены.
Адаптация жизненного цикла необходима для реализации принципа быстрого отслеживания, который эффективнее всего используется при выполнении второстепенных проектов по разработке и приобретению ПО. Необходимость в применении быстрого отслеживания может возникнуть в случае критической нехватки времени, например, при необходимости первым поставить серийно выпускаемый продукт на рынок или в случае возникновения угрозы национального характера для государственной организации. Помимо сокращения жизненный цикл, адаптированный в целях быстрого отслеживания, обычно является менее формальным. Полный срок службы поставленного продукта может быть коротким, что указывает на короткую фазу эксплуатации.
К проектам, при выполнении которых используется принцип быстрого отслеживания, должны прибегать лишь организации с повышенными дисциплинарными требованиями. Официально установленная и определенная среда разработки сводит до минимума возможные риски. При наличии четко выраженного постоянного набора требований и метода, предусмотренного для внесения изменений, вероятность достижения успеха при выполнении проектов за принципом быстрого отслеживания увеличивается.
Параллельный инжиниринг
Процесс параллельного инжиниринга (Concurrent engineering, СЕ) заключается в создании продуктов более высокого качества за меньший период времени.
Основной принцип использования этого метода заключается в том, что все аспекты жизненного цикла проекта должны учитываться в процессе от проектирования до производства как можно раньше. Благодаря раннему анализу более поздних этапов жизненного цикла выявляются проблемы, которые возникают далее в процессе разработки, а значит, это будет способствовать принятию продуманных и обоснованных решений на протяжении всего процесса разработки.
Метод параллельного инжиниринга успешно используется для проектирования ПО. При выполнении больших проектов отслеживание состояния на главных фазах жизненного цикла может обеспечить создание в высшей степени упрощенной модели.
В общих чертах можно отметить, что, как правило, параллельный инжиниринг состоит из нескольких действий (сбор требований, разработка проекта, кодирование, тестирование и т.д.), которые осуществляются одновременно. Кроме того, внутренние или внешние продукты проекта могут находиться в одном из нескольких состояний (в состоянии разработки, анализа, проверки, ожидания следующей стадии и др.)
При использовании этого метода следует оценить возможные технические риски, чтобы определить, совместима ли разрабатываемая технология с методикой ускоренной разработки, оставить свободное место в графике разработки, периодически производить оценку технологического процесса для определения того, является ли он по-прежнему совместимым с построенным планом, и чтобы, как и при использовании более традиционных жизненных циклов, обеспечить основу для проведения оценки и тестирования, поскольку игнорирование этих действия связано с крайним риском.
Спиральная модель "Win-Win"
Спиральная модель "Win-Win" содержит в себе больше фаз, в которых внимание сконцентрировано на участии заказчика в процессе разработки. Это достигается путем добавления к начальной фазе каждого цикла так называемых действий Теории W (Theory W activities). Теория W— это принцип менеджмента, при реализации которого особое значение придается ключевым организаторам совместного дела, выполняющим разработку системы (пользователь, заказчик, разработчик, наладчик, создатель интерфейсов и т.д.), которые станут "победителями", если проект окажется успешным.
В этом методе, основанном на постоянном согласовании, циклы состоят из следующих фаз или стадий:
определение участников следующего уровня;
определение условий, необходимых для одержания участниками победы;
согласование "победных" условий;
формулирование целей, ограничений и альтернативных вариантов следующего уровня;
оценка альтернативных вариантов на уровне продукта и процесса, разрешение рисков;
определение следующего уровня продукта и процесса, включая сегментацию;
обоснование определений продукта и процесса;
обзор и комментарии.
Важной стадией является последующее планирование следующего цикла и обновление плана жизненного цикла, включая разделение системы на подсистемы, разработка которых осуществляется в ходе выполнения параллельных циклов. Эта стадия может включать в себя план прекращения проекта, если продолжение работы является слишком рискованным или невозможным. Также необходимо обеспечить, чтобы продолжение работы над проектом со стороны руководства осуществлялось согласно составленному плану.
Спиральная модель "win-win" имеет следующие преимущества:
более быстрая разработка ПО благодаря содействию, оказываемому участниками проекта;
уменьшение стоимости программ благодаря уменьшению объема переработок и текущего сопровождения;
более высокий уровень удовлетворения со стороны участников проекта, достигаемого до разработки самого продукта;
более высокое качество ПО благодаря использованию компромиссных качественно-атрибутивных моделей на уровне архитектуры;
исследование большого количества вариантов построения архитектуры на ранних этапах разработки.
Эволюционный/инкрементный принцип
По своей природе разработка программного продукта при использовании эволюционного/инкрементного принципа часто затруднена. Вопросы возникают потому, что каждая инкрементная конструкция реализует лишь небольшую часть возможностей разрабатываемой системы. Помимо обычных критериев для принятия решений по разработки, может возникнуть необходимость ответа на дополнительные вопросы:
является ли решение о разработке текущих функциональных свойств хорошей идеей с учетом текущего объема финансирования?
наступило ли уже время рассматривать функциональные возможности системы (приоритеты пользователя, требования процесса эволюции)?
стоят ли добавленные функциональные возможности потраченных на них средств (или "покрывается позолотой" лишь одна область функциональных возможностей прежде, чем будут разработаны все необходимые характеристики системы)?
хватит ли у нас объема денежных средств на разработку требуемой системы в полном объеме?
Принцип V-образной инкрементной модели
Разработка хорошей модели жизненного цикла проекта означает заблаговременные капиталовложения, например, создание традиционной V-образной модели, смешанной с инкрементной, итеративной моделью разработки.
В этой модели предпринята попытка сбалансировать потребность в административном контроле с нуждами в технической инновации и ситуативной динамике.
Успешное использование V-образной тесно связано с тем, что происходит в контрольных точках. Эти точки представляют собой формальные механизмы, определяющие совместное принятие определенных решений по переходу к следующей фазе со стороны менеджеров и разработчиков. Вместе с периодическим проведением руководством обзоров и предварительных просмотров, контрольные точки побуждают к обсуждению вопросов, рисков и альтернатив. Значение каждой контрольной точки необходимо четко определить в рамках всего процесса. За такой высокоуровневой моделью кроются конкретные планы, основанные на точных предварительных оценках и четко определенных контрольных точках проектирования, способствующих достижению успеха.
|
