Что характерно для жц водопад

Модель жизненного цикла водопад

Данную модель можно назвать попыткой перенести положительный опыт другой природы на программную сферу

· Последовательное выполнение этапов проекта в строгом фиксированном порядке

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

· Отсутствие обратных связей между этапами

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

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

1. Оценка реалистичности программного продукта

2. Оценка возможности создания программного продукта

3. Требования к программному продукту

4. Проверка правильности

5. Проектирование высокого уровня

6. Контроль проектных решений

7. Детальное проектирование

8. Контроль правильности специальных программных компонентов

10. Помодульное тестирование (цель тестирования – подтверждение НЕработоспособности программы)

11. Интеграция модулей

12. Контроль качества сборки

13. Опытная эксплуатация (программу нельзя испытать полностью)

14. Системное тестирвоание

15. Промышленная эксплуатация

16. Переоценка желаний пользователя

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

2) использование прототипов как инструментального средства анализа и согласование треб к программному продукту;

3)относится к классу документно-ориентированных, т.е. каждый этап заканчивается составлением документации.

Итерационный характер развития (возврат)

На каждом шаге контроль результата

Заказчик вовлечен в процесс

Ограниченность: работает, когда нет глобальной неопределенности

Водопадная (каскадная, последовательная) модель

Основная статья: Модель водопада

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

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований;

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

· Полная и согласованная документация на каждом этапе;

· Легко определить сроки и затраты на проект.

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы [2] . Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем [3] .

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

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью [4] .

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения [3] .

По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте» [4] .

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже» [3] .

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

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

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

· риск превышения сроков и стоимости проекта;

· необходимость выполнения ещё одной итерации;

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

· целесообразность прекращения проекта.

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

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

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

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

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

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

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

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

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

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

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

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

В сегодняшней спиральной модели определён следующий общий набор контрольных точек [5] :

1. Concept of Operations (COO) — концепция (использования) системы;

2. Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;

3. Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

4. Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;

5. Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Учись учиться, не учась! 10313 – | 7849 – или читать все.

193.151.241.65 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

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

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

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

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

  1. Инженерный подход
  2. С учетом специфики задачи
  3. Современные технологии быстрой разработки

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

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

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

  1. Постановка задачи
  2. Выполнение
  3. Проверка результата
  4. При необходимости переход к первому пункту

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

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

  1. Прояснить не ясные требования (прототип UI)
  2. Выбрать одно из ряда концептуальных решений (реализация сцинариев)
  3. Проанализировать осуществимость проекта

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

  1. Горизонтальные и вертикальные
  2. Одноразовые и эволюционные
  3. бумажные и раскадровки

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

Модель принадлежит второй группе.

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

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

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

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

Недостатки:

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

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

Что характерно для жц водопад

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

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

  1. Определение требований
  2. Проектирование
  3. Конструирование (также «реализация» либо «кодирование»)
  4. Интеграция
  5. Тестирование и отладка (также «верификация»)
  6. Инсталляция
  7. Поддержка

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

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

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

Критика модели Водопада и гибридные методологические решения

Методику «Водопада» довольно часто критикуют за недостаточную гибкость и объявлении самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. [1] Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным. Поэтому даже в PMBOK 3-ей версии формально была закреплена только методика «Водопада» и не были предложены альтернативные варианты, известные как итеративное ведение проектов.

Начиная с PMBOK 4-ой версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. [2] Таким образом, начиная с 2009 года, формально Институтом Проектного Менеджмента (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.

Примечания

Другие модели: CMM • CMMI • Модель данных • Function model • IDEF • Information model • Metamodeling • Object model • View model • UML

Разработка программного обеспечения
Шаги процессаАнализ требований • Проектирование программного обеспечения • Программирование • Формальные методы • Тестирование программного обеспечения • Внедрение программного обеспечения • Сопровождение программного обеспечения
КонцепцииМоделирование данных • Архитектура программного обеспечения • Functional specification • Язык моделирования • Парадигма программирования • Программное обеспечение • Архитектура программного обеспечения • Методология разработки программного обеспечения • Цикл разработки программного обеспечения • Качество программного обеспечения • Обеспечение качества программного обеспечения • Структурный анализ программного обеспечения
НаправленияГибкая методология разработки • Аспектно-ориентированное программирование • Объектно-ориентированное программирование • Проблемно-ориентированное программирование • Онтология • Сервисно-ориентированная архитектура • Цикл разработки программного обеспечения • Оценка затрат на разработку программного обеспечения
Модели
Выдающиеся
деятели
Kent Beck • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Tom DeMarco • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Michael A. Jackson • Ivar Jacobson • Craig Larman • James Martin • Bertrand Meyer • David Parnas • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл
Связанные
статьи
Информатика • Компьютерная инженерия • Организационная инженерия • История разработки ПО • Конфигурационное управление • Менеджмент • Документирование • Математика • Управление проектами • Управление программами • Всеобщее управление качеством • Эргономика • Системотехника • Обратная разработка

Wikimedia Foundation . 2010 .

Смотреть что такое “Модель водопада” в других словарях:

Итеративная модель разработки — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ | Проектирование | Реализация | Тестирование | Внедрение | Сопровождение Модели / методы Agile | Cleanroom | Итеративная | Scrum | RUP | MSF | Спиральная | Во … Википедия

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

Каскадная модель — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия

Dual Vee Model — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия

Жизненный цикл программного обеспечения — (ПО) период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл процесс построения и развития ПО. Содержание 1 Стандарты… … Википедия

V-Model — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Документирование • … Википедия

Жизненный цикл информационной системы — это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из… … Википедия

Жизненный цикл информационных систем — Жизненный цикл информационной системы это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в… … Википедия

Процесс разработки программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • … Википедия

CMM — Capability Maturity Model модель зрелости процессов создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение. CMM(ед.изм.) кубические метры/минута. Антон Ка 85.21.47.34 05:30, 18 августа 2009… … Википедия

Жизненный цикл программных систем

5.7. Виды моделей ЖЦ ПО

Каскадная модель (классический жизненный цикл)

Эта модель обязана своим появлением У. Ройсу ([1], 1970 г.). Модель имеет и другое название – водопад (waterfall). Особенность модели – переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии; возвратов на пройденные стадии не предусматривается (рис.5.4).

Требования к разрабатываемой ПС, определенные на стадиях формирования и анализа, строго документируются в виде ТЗ и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации (ТЗ, ЭП, ТП, РП), достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций ТЗ. Основное внимание разработчиков сосредоточивается на достижении оптимальных значений технических характеристик разрабатываемой ПС – производительности, объема занимаемой памяти и др.

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

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

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

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

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

Итерационная модель ЖЦ ПС

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

В итерационной модели (рис.5.5) недостатки проектирования и программирования могут быть устранены позже путем частичного возврата на предыдущую стадию. Чем ниже уровень обнаружения ошибки, тем дороже ее исправление. Если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше (рис.5.6).

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

Макетирование

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

Модель может принимать следующие формы.

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

Как показано на рис.5.7, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.

Последовательность действий при макетировании представлена на рис.5.8. Макетирование начинается со сбора и уточнения требований к создаваемой программной системе. Разработчик и заказчик совместно определяют цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить. Затем выполняется быстрое проектирование. В нем сосредотачиваются на характеристиках, которые должны быть видимыми пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО. Итерации продолжаются до тех пор, пока макет не выявит все требования заказчика и даст возможность разработчику понять, что должно быть сделано.

Достоинства макетирования – возможность обеспечения определения полных требований к системе. Недостатки макетирования:

  • заказчик может принять макет за продукт;
  • разработчик может принять макет за продукт.

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

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

Прежде чем рассматривать другие модели ЖЦ ПО, которые пришли на смену каскадной модели , следует остановиться на стратегиях конструирования программных систем. Именно стратегия конструирования ПО во многом определяет модель ЖЦ ПО.

Стратегии конструирования ПО

Существует три стратегии конструирования программных систем:

Выбор жизненного цикла для проекта

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

На мой взгляд, жизненный цикл проекта (ЖЦ) служит следующим целям:

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

Глобально существует 2 ключевых подхода к формированию ЖЦ проекта:

  • Водопадная модель
  • Итерационная модель

Описание водопадной модели проекта появилось раньше итерационной модели. Первое официальное описание модели водопада приписывается статье автора Winston W. Royce, вышедшей в 1970 году, хотя автор и не использовал в статье термин «водопад». Впервые термин “водопад”, как считается, был введен в 1976 году.

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

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

Ключевые плюсы водопадного ЖЦ проекта, на мой взгляд:

  1. Команда проекта и заказчик последовательно получают ответы на вопросы: «Что нужно получить? Как мы это сделаем?», и только после этого приступают к реализации задуманного.
  2. Спланировать объемы работ, сроки и бюджет после второго этапа становится намного проще, т.к. мы имеем ответы на самые сложные в проекте вопросы.

Минусы водопадного подхода:

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

Устранить указанные минусы водопадной модели должен был итерационный ЖЦ проекта. Суть этого подхода – деление проекта на серию мини-проектов (итерации), в каждом из которых получаем ответы на вопросы «Что?» и «Как?», реализуем задуманное и проверяем. По окончании каждой итерации заказчик проекта принимает решение, можно ли показать то, что уже получилось, представителям будущих пользователей, чтобы быстрее понять, сделали мы то, что ими будет востребовано, или в чем-то ошиблись.

Плюсы итерационного подхода к ЖЦ проекта:

  1. Пользователи результатов проекта и другие заинтересованные стороны проекта могут увидеть прототип продукта на одной из ранних итераций (когда уже есть что показать).
  2. Требования к результату (продукту) проекта могут уточняться по итогу каждой итерации, что дает возможность быстро вносить изменения в создаваемый результат проекта.
  3. Управление изменениями требований к результатам проекта достаточно простое, т.к. сводится к расстановке приоритетов для каждого требования.
  4. Планирование каждой итерации проходит достаточно легко, т.к. несложно оценить объемы работ на итерацию и отобрать столько задач, сколько команда способна реализовать с учетом ее производительности.
  5. Знакомясь с приращением функционала продукта проекта по окончанию каждой итерации, у заказчика проекта формируется понимание о продукте по мере продвижения по проекту. Это облегчает приемо-сдаточные испытания продукта в конце проекта.

Минусы итерационного ЖЦ проекта:

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

Какую модель ЖЦ проекта выбрать?

Ответ на этот вопрос зависит от:

  1. Готовности заказчика потратить время и деньги на проработку требований к результатам проекта до того, как начать разрабатывать продукт(ы) проекта.
  2. Степени вовлеченности заказчика проекта. Его готовности тратить свое время на проект.
  3. Типа контракта на проект.
  4. Масштаба и трудоемкости проекта.
  5. Степени инновационности результатов проекта.
  6. Требований к безопасности продуктов проекта.

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

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

Например, V-образная модель ЖЦ проекта была разработана на базе водопадной модели и является ее разновидностью.

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

  1. Руководитель проекта может не использовать ни одну из существующих моделей ЖЦ проекта, но в этом случае он изобретает велосипед для своего проекта.
  2. Нет единственной подходящей для любого проекта модели ЖЦ проекта.
  3. Чем больше опыта у руководителя проекта и команды проекта по работе с разными моделями ЖЦ проекта, тем больше вероятность того, что под конкретный проект они смогут выбрать наиболее подходящую для него модель ЖЦ проекта, а под эту модель – наиболее адекватные методы и инструменты планирования, контроля и внесения изменений в проект.

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

Виды моделей ЖЦ ПС и технологии создания программных систем

Каскадная модель (классический жизненный цикл)

Эта модель обязана своим появлением У. Ройсу (1970) [16]. Модель имеет и другое название – «Водопад» (Waterfall). Особенность модели -переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии, возвратов на пройденные стадии не предусматривается (рис. 3.4). Требования к разрабатываемой ПС, определенные на стадиях формирования и анализа, строго документируются в виде ТЗ и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации (ТЗ, ЭП, ТП, РП), достаточного для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Рис. 3.3. Вариант взаимосвязи и стадий работ с процессами ЖЦ ПО

Критерием качества разработки при таком подходе является точность выполнения спецификаций ТЗ. Основное внимание разработчиков сосредотачивается на достижении оптимальных значений технических характеристик разрабатываемой ПС – производительности, объема занимаемой памяти и др.

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

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

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

Рис. 3.4. Каскадная модель ЖЦ ПС

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

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

Каскадная модель жизненного цикла разработки ПО (стр. 1 из 2)

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

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

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

Модель «кодирование–устранение ошибок». Она описывается следующим образом: 1) поставить задачу; 2) выполнять ее до успешного завершения либо отмены; 3) проверить результат; 4) повторить при необходимости с 1-го шага.

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

Рис. 1. Модель процесса “делать, пока, не будет сделано”

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

Рис. 2. Классическая каскадная модель

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

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

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

Отличительным свойством каскадной модели можно назвать то, что она представ­ляет собой формальный метод, разновидность разработки “сверху вниз”, она состоит из независимых фаз, выполняемых последовательно, и подвержена частому обзору.

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

Рис. 3. Модифицированная каскадная модель с обратной связью

Краткое описание фаз модифицированной каскадной модели

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· она отличается стабильностью требований;

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

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

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

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

· она облегчает работу менеджеру проекта по составлению плана

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

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

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

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

Проект с умом. Выбираем между Waterfall и Agile

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

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

Одни из самых распространенных категорий моделей разработки ПО – Agile и Waterfall, гибкая и каскадная соответственно. Мы дадим краткое описание каждой, рассмотрим их плюсы, минусы и определимся с корректной системой под проект.

Agile

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

При оплате труда разработчиков в рамках Agile обычно выбирают между выделенной командой под проект (Dedicated Team) и системой Time&Materials (T&M). Мы уже сравнили между собой некоторые механизмы построения финансовых отношений с подрядчиком. Наши выводы с позиций клиентов и разработчиков можно найти здесь.

Гибкая модель разработки основана на 12 принципах, из которых определяющими мы считаем следующие:

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

К классу Agile относятся такие методики, как экстремальное программирование (XP), FDD, DSDM, Scrum и другие.

Waterfall

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

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

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

А теперь сравним сильные и слабые стороны Agile и Waterfall.

Гибкая модель

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

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

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

Гибкая модель

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

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

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

Изучив матчасть, мы легко научимся жонглировать Agile и Waterfall в своих проектах!

Гибкая модель разработки действует, если:

1. В проекте задействована опытная команда.

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

3. Конечный пользователь «варится» в проекте с самого начала.

4. Необходимо быстро разработать рабочее ПО.

Выбирайте каскадную модель в случаях, если:

1. Требования к проекту стабильны и практически неизменны;

2. Качество продукта намного важнее затраченного времени и ресурсов;

3. Проект разрабатывается на аутсорсе;

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

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

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

А теперь просто идите и сделайте свой проект!

Какие бывают жизненные циклы проекта и почему важно об этом знать

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

Фото с сайта sptk-status.ru

На мой взгляд, жизненный цикл проекта (ЖЦ) служит следующим целям:

1. Хорошо проработанная модель ЖЦ позволяет определить иерархическую структуру работ.

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

Глобально существует 2 ключевых подхода к формированию ЖЦ проекта, о которых я расскажу.

Водопадная модель

Первое ее официальное описание встречается в статье Winston W. Royce (хотя автор и не использовал термин «водопад»), вышедшей в 1970 году. Сам термин, как считается, впервые был введен в 1976 году.

Модель построена на предположении – сначала в проекте должно появиться понимание, что именно команда проекта должна получить в итоге работы. Потом нужно ответить на вопрос «Как мы это сделаем?». После происходит реализация запланированных результатов проекта и затем – приемо-сдаточные испытания.

Поэтому водопадный ЖЦ часто изображают в виде 4-х этапов, не пересекающихся во времени:

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

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

1. Команда проекта и заказчик последовательно получают ответы на вопросы: «Что нужно получить?», «Как мы это сделаем?», и только после этого приступают к реализации задуманного.

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

Минусы водопадного подхода:

1. Оценка сроков и стоимости всего проекта на этапе «Концепции» затруднена – не проработаны требования к результатам проекта.

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

3. Часто на этапе «Реализация» требования к результатам проекта все же начинают изменяться. Вносить изменения в разрабатываемый продукт проекта зачастую становится сложно.

4. Пользователи впервые увидят результаты только на четвертом этапе – «Завершение», а то и после него. Обратная связь от пользователей поступает слишком поздно, когда цена внесения изменений в результаты проекта уже слишком велика.

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

Для устранения упомянутых выше минусов можно использовать итерационный ЖЦ проекта. Его суть заключается в делении всего проекта на серию мини-проектов (итераций). В каждом из них происходит получение ответов на вопросы «Что?» и «Как?», реализация задуманного и его проверка. По окончании каждой итерации заказчик принимает решение, можно ли показать то, что уже получилось, будущим пользователям. Это помогает побыстрее понять, сделан ли востребованный продукт, или его разработчики в чем-то ошибаются.

Плюсы итерационного ЖЦ проекта:

1. Пользователи результатов проекта и другие заинтересованные стороны могут увидеть прототип продукта на одной из ранних итераций (когда уже есть что показать).

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

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

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

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

Минусы итерационного ЖЦ проекта:

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

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

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

Какую модель ЖЦ проекта выбрать?

Ответ на этот вопрос зависит от нескольких факторов:

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

2. Степени вовлеченности заказчика проекта. Его готовности тратить свое время на проект.

3. Типа контракта на проект.

4. Масштаба и трудоемкости проекта.

5. Степени инновационности результатов проекта.

6. Требований к безопасности продуктов проекта.

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

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

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

Фото с сайта road-movie.livejournal.com

Подведем итоги:

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

2. Нет единственной подходящей для любого проекта модели ЖЦ.

3. Чем больше опыта у руководителя и команды проекта по работе с разными моделями ЖЦ, тем больше вероятности, что под конкретный проект они выберут наиболее подходящую модель. И уже под нее – разработают наиболее адекватные методы и инструменты планирования, контроля и внесения изменений в проект.

Мой совет будет таким: анализируйте опыт выполненных проектов, чтобы лучше понимать, какая модель ЖЦ и в каком случае лучше подойдет. И продолжайте изучать эту тему. Возможно, кто-то в данный момент описывает новую модель ЖЦ проекта для вашей отрасли и в скором времени собирается опубликовать ее для нас.

Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».

Опыт работы в сфере управления проектами – более 10 лет.

20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.
Опыт преподавания – 10 лет. Около 2200 студентов, прошедших обучение на его семинарах.

Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий блога по управлению проектами.