Модели жизненного цикла проекта

1.2 Модели жизненного цикла проекта

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

Несмотря на уникальность всех проектов, подобно тому, как существуют общие процессы управления, применимые к большинству проектов, существуют также и общие модели, которые могут служить руководством по определению жизненного цикла большинства проектов. Эти общие модели ценны тем, что экономят время проектным командам при разработке графика проекта. [4; 34-35]

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

Что может быть проще? Даже если у Вас очень маленький проект, Вы все равно проходите эти базовые шаги, хотя бы даже проделывая некоторые из них в голове. К примеру, если у Вас 40-часовой (на одну рабочую неделю) проект разработки или улучшения документа, может показаться что Вы сразу же бросаетесь в фазу "Реализация". Но так ли это? Наиболее вероятно, что Вы получили какого-либо рода поручение с требованиями или пожеланиями, которые придется осмыслить (Анализ) и трансформировать в замысел будущего содержания (Проектирование). Затем вы воплощаете замысел (Реализация), проверяете результат (Тестирование) и передаете для использования (Внедрение). [5; 67-71]

Водопадная (каскадная) схема включает несколько важных операций, применимых ко всем проектам:

• составление плана действий по разработке системы;

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

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

Графическая иллюстрация “водопадной модели” проектного цикла

Рисунок.3 Водопадная модель жизненного цикла проекта

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

Каскадная модель имеет преимущества, если ее использовать в проекте, для которого она достаточно приемлема.

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

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

c.  Она доступна для понимания, так как преследуется простая цель – выполнить необходимые действия.

d.  Она проста и удобна в применении, так как процесс разработки выполняется поэтапно.

e.  Она отличается стабильностью требований.

f.  Она представляет собой шаблон, в который можно поместить методы для выполнения анализа, проектирования, кодирования, тестирования и обеспечения.

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

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

i.  Ход выполнения проекта легко проследить с помощью использования временной шкалы (диаграммы Ганта), поскольку момент завершения каждой фазы используется в качестве стадии.

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

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

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

b.  У клиента не всегда есть возможность ознакомиться с системой заранее, это происходит лишь в самом конце жизненного цикла.

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

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

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

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

В то время, как "водопад" универсален и может применяться в любом проекте, другие модели жизненного цикла могут оказаться более результативными и эффективными в зависимости от характеристик проекта. Например, если Вы устанавливаете пакет программного обеспечения, Вы пропускаете фазы проектирования и реализации. Подобным же образом, если Вы занимаетесь опытно-конструкторскими разработками, Вы можете использовать специфическую модель жизненного цикла R&D проекта, учитывающую, что проделанная работа или часть ее может пойти в мусорную корзину. Другие важные модели жизненного цикла могут использоваться для ускорения проектов определенного вида. Проекты в области информационных технологий, к примеру, часто используют итеративную либо быструю (Agile development) разработку. [6; 23-25]

Ниже приведены некоторые другие модели жизненного цикла проекта:

Итеративный подход (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).

Преимущества итеративного подхода:

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

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

3.акцент усилий на наиболее важные и критичные направления проекта;

4.непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

5.раннее обнаружение конфликтов между требованиями, моделями и 6.реализацией проекта;

7.более равномерная загрузка участников проекта;

8.эффективное использование накопленного опыта;

9.реальная оценка текущего состояния проекта и, как следствие, большая 10.уверенность заказчиков и непосредственных участников в его успешном завершении. [7; 240-243]

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

Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

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

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. “Разрыв” в квалификации специалистов разных областей знаний.

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

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

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

оценка и разрешение рисков,

определение целей,

разработка и тестирование,

планирование.

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

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

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

a  Спиральная модель разрешает пользователям «увидеть» систему на ранних этапах, что обеспечивается посредством использования ускоренного прототипирования в жизненном цикле разработки проекта.

b  Обеспечивается определение непреодолимых рисков без особых затрат.

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

d  Она обеспечивает разбиение большого потенциального объема работы по разработке продукта на небольшие части.

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

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

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

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

a  Спираль может продолжаться до бесконечности.

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

c  Использование модели может стать дорогостоящим, так как время, затраченное на планирование, повторное определение целей, анализа рисков и прототипирование, может быть чрезмерным. [8; 312-316]

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

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

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

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

a  Не требуется заранее тратить средства на разработку всего проекта.

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

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

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

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

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

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

h  Риск распределяется на несколько меньших по размеру инкрементов, и не сосредоточен в одном большом проекте разработки.

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

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

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

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

c  Заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены. [9; 90-94]