Управление проектами

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

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

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

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

—        облегчает процедуру контроля.

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

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

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

Планирование — определение сроков реализации замысла, разделение данных процессов на конкретные этапы, а также назначение исполнителей и ответственных лиц.

Исполнение — начинается сразу же после того, как были утверждены планы. Подразумевает реализацию в полном объеме всех намеченных действий.

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

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

Фазы цикла

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

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

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

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

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

Особенности жизненного цикла проекта

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

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

—        На первом этапе наблюдается наибольший уровень риска, а также неуверенности и сомнений по поводу успешного исхода деятельности.

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

С течением времени это становится сделать все сложнее.

Каскадная модель жизненного цикла проекта

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

составление четкого плана действий по достижению поставленных целей;

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

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

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

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

—        недостаток квалифицированных и опытных кадров;

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

—        потеря актуальности разработки за время ее реализации;

—        необходимость вносить изменения в процессе производства;

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

—        несоответствие производственной мощности необходимому уровню;

—        противоречия в работе различных подразделений.

Инкрементная модель

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

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

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

И одним из самых важных моментов является минимизация рисков, которые равномерно распределяются между фазами (инкрементами).

Принципы жизненного цикла проекта

Жизненные циклы проекта характеризуются рядом принципов, а именно:

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

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

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

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

Жизненный цикл проектной задачи

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

Финансовая структура проекта является отдельной темой для осмысления. В настоящей статье мы рассмотрим вопрос о временной структуре проекта.

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

Ключевые моменты для принятия решений

Понятие цикла жизнедеятельности широко распространено в современности. Любое органическое явление, будь то продукт, компания, рынок или планета, подчиняется закономерностям жизненного цикла (ЖЦ).

Эти постулаты свидетельствуют нам о протяженных во времени «зачатии», «рождении», «развитии», «угасании» и «смерти».

Вполне философско-логическая последовательность, повернуть вспять которую никто не в силах.

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

Жизненный цикл проекта (ЖЦП) состоит из полного набора последовательных фаз.

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

Жизненный цикл проекта достаточно часто применяется для того, чтобы своевременно принимать взвешенные управленческие решения: идем дальше или нет. Для этого проект делится на этапы.

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

Они дают авторизацию разрешения перехода на каждую следующую фазу.

Обобщенная последовательность фаз ЖЦП

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

Формирование концепции.

Разработка.

Реализация.

Завершение.

Данные стадии жизненного цикла проекта предваряет процедура его запуска, а окончательной точкой является событие закрытия. Такое содержание ЖЦП применимо к большинству проектов. В отдельных областях жизненные циклы обладают отраслевой спецификой. Например, у фармацевтов свои основные этапы ЖЦ, у строителей – свои особенности, у IT-компаний этапы также уникальны.

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

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

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

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

Этому сложному вопросу обязательно будет посвящена отдельная статья.

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

Двухфазная модель жизненного цикла

Основные этапы ЖЦП формируются в логико-временной структуре деятельности.

Ранее отмечено, что состав фаз различается по отраслям и по позициям соответствующих авторов-методистов, разрабатывающих модели управления. Интерес представляет пример двухфазного состава структуры ЖЦ.

Его содержание включает фазу разработки и фазу реализации. Характеристики фазы разработки отражают деятельность по:

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

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

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

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

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

Таким образом, три базовых критерия (содержание, ограничения и риски) находят свое выражение на временной ленте проекта. Динамический анализ указанных параметров в диаграммной форме представлен далее.

Зависимость основных параметров проекта от фаз ЖЦП

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

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

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

Трактовка ЖЦП в стандарте PMI

Представленная в прошлом разделе двухфазная модель ЖЦ хороша тем, что на ее основе достаточно просто перейти к более развернутым конфигурациям жизненного цикла. Универсальный пример развертки фаз проекта предоставляет нам институт PMI. В англоязычной версии жизненный цикл проекта именуется Project Live Cycle (PLC). В руководстве PMBOK понятие ЖЦП раскрывается следующим определением.

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

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

Работы в составе процессов могут повторяться на каждом этапе ЖЦ. Жизненный цикл продукта, сгенерированного проектом, не совпадает с жизненным циклом проекта.

Типовые уровни стоимости и обеспечения персоналом в структуре ЖЦП

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

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

Данные особенности визуально представлены на примере трехфазного проекта «Ликвидация хранилища опасных отходов».

Пример трехфазного проекта

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

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

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

Пример проекта с перекрывающимися фазами

Жцп в инвестиционном режиме

Инвестиционный и инновационный проекты отличаются друг от друга. В чем именно заключается отличие между ними? Понятие инвестиционного проекта связано с субъектом, именуемым инвестором.

Инвестор – лицо, вкладывающее средства с целью получения в будущем дохода и прибыли.

Заказчик (если он не является инвестором) и PM обосновывают для инвестора вложение им финансовых средств, несут перед ним ответственность и предоставляют отчетность. Обоснование включает ответы на три главных вопроса.

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

Какова доходность (рентабельность) проекта?

Каков срок окупаемости вложений?

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

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

ЖЦ инвестиционного проекта

Жц инновационного проекта

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

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

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

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

Например, успешные инновации в области ВПК дают очевидные преимущества государству, но не приносят прямой прибыли.

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

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

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

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

ЖЦ проекта создания нового образца военной техники

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

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

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

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

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

В этом и будет заключаться моя небольшая тема.

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

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

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

Эти модели можно разделить на 3 основных группы:

Инженерный подход

С учетом специфики задачи

Современные технологии быстрой разработки

Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.

Модель кодирования и устранения ошибок

Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.

Данная модель имеет следующий алгоритм:

Постановка задачи

Выполнение

Проверка результата

При необходимости переход к первому пункту

Модель также ужасно устаревшая. Характерна для 1960-1970 гг.

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

Каскадная модель жизненного цикла программного обеспечения (водопад)

Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.

Преимущества:

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

Недостатки:

• Отсутствие обратных связей между этапами
• Не соответствует реальным условиям разработки программного продукта

Относится к первой группе моделей.

Каскадная модель с промежуточным контролем (водоворот)

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

V модель (разработка через тестирование)

Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.

Модель на основе разработки прототипа

Данная модель основывается на разработки прототипов и прототипирования продукта.

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

Прояснить не ясные требования (прототип UI)

Выбрать одно из ряда концептуальных решений (реализация сцинариев)

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

Классификация протопипов:

Горизонтальные и вертикальные

Одноразовые и эволюционные

бумажные и раскадровки

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

Спиральная модель жизненного цикла программного обеспечения

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

Преимущества:

• Быстрое получение результата
• Повышение конкурентоспособности
• Изменяющиеся требования — не проблема

Недостатки:

• Отсутствие регламентации стадий

Третьей группе принадлежат такие модели как экстремальное программирование (XP), SCRUM, инкриментальная модель (RUP), но о них я бы хотел рассказать в отдельном топике.

Большое спасибо за внимание!

Фазы и жизненный цикл проекта

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

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

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

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

При определœении фаз жизненного цикла проекта крайне важно учитывать следующее:

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

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

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

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

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

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

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

Фаза реализации — ϶ᴛᴏ выполнение ранее утвержденных планов, реализация принятых проектных решений, достижение базовых целœей проекта с учетом динамического воздействия окружающей среды.

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

Большинство жизненных циклов проектов имеют набор общих характеристик:

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

· неопределœенность в отношении времени и стоимости осуществления проекта уменьшается по мере его развития;

· вероятности успешного выполнения проекта имеет минимальное значение вначале проекта͵ при этом высока неопределœенность. По мере исполнения проекта вероятность успешного его завершения возрастает;

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

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

Жизненный цикл программного обеспечения

Следует начать с определения, Жизненный цикл программного обеспечения (Software Life Cycle Model) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

Модели Жизненного цикла программного обеспечения

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

Каскадная модель

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

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

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

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

Жизненный цикл традиционно разделяют на следующие основные этапы:

Анализ требований,

Проектирование,

Кодирование (программирование),

Тестирование и отладка,

Эксплуатация и сопровождение.

Каскадная модель Жизненного цикла

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

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

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

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

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

Ограничение области применения каскадной модели определяется её недостатками. Её использование наиболее эффективно в следующих случаях:

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

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

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

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

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

 Инкрементная модель

Инкрементная модель (англ. increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.

Поэтапная модель с промежуточным контролем

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

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

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

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

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

Жизненный цикл данной модели характерен при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат. Разработка версиями ведется в силу разного рода причин:

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

Достоинства и недостатки этой модели (стратегии) такие же, как и у каскадной (классической модели жизненного цикла). Но в отличие от классической стратегии заказчик может раньше увидеть результаты.

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

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

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

Схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

Основная проблема спирального цикла — определение момента перехода на следующий этап.

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

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

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

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

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

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

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

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

• разработка,
• сопровождение.

Фазы разбиваются на ряд этапов (см. рис. 7.1).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Считается, что это один из видов работ этапа реализации.

В общепринятой модели фаза разработки заканчивается этапом тестирования (автономного и комплексного) и передачей системы в эксплуатацию — следующие два этапа.

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

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

Но соответствующее уточнение делается в других моделях жизненного цикла.

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

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

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

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

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