Модель жц водопад пРимееняется для

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

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

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

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

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

Этапы деятельности

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

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

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

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

Недостатки водопадного подхода

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

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

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

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

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

Когда применяется водопадный подход

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

Сравнение водопадного и итеративного подходов:

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

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

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

– Возможность нивелирования воздействия серьезных рисков на ранних стадиях проекта, пока это еще можно сделать с минимальными затратами. Разница стоимости ошибки определения требований в начале проекта и в конце равна 1:200.

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

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

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

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

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

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

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

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

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

Водопадная модель жизненного цикла (англ. 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) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

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

Лучшие изречения: Да какие ж вы математики, если запаролиться нормально не можете. 8397 – | 7317 – или читать все.

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

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

очень нужно

Методология разработки Waterfall: что это, как работает и чем отличается от Agile

Сейчас Waterfall не так часто используют, но без неё никто бы не придумал Agile. Рассказываем для менеджеров проектов и тех, кто хочет ими стать.

Бывает, что в теории методология ясна, а потом дело доходит до внедрения и начинаются вопросы. На курсе «Руководитель digital-проектов» преподаватели Skillbox разбирают инструменты управления на реальных кейсах, чтобы студенты легко и безошибочно применяли их в работе.

Что ещё за Waterfall?

Waterfall — модель «Водопад», водопадная или каскадная разработка продуктов. Она подобно потоку воды направляет команды решать задачи последовательно и строго по изначальному плану. Название появилось в 1970 году в статье Винстона Уолкера Ройса, директора Lockheed Software Technology Center, а структура позаимствована у диаграммы Ганта.

Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства
CRM-маркетинга Out of Cloud.

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

  1. Документы и инструкции — это важно, всё должно быть зафиксировано.
  2. Следующий этап работы не начинается, пока не закончится предыдущий.
  3. Пропускать этапы нельзя.
  4. Если требования к продукту изменились после согласования — переписываем ТЗ.
  5. Нельзя возвращаться на предыдущий этап, чтобы что-то изменить.
  6. Нет итераций, есть один общий процесс создания продукта.
  7. Выявлять и исправлять ошибки — только на этапе тестирования.
  8. Клиент не участвует в создании продукта после постановки ТЗ.

Как работает Waterfall

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

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

Команда создаёт прототип и готовит дизайн-макеты. Когда это готово, подключаются разработчики.

На этом этапе пишут код продукта согласно плану, макетам и требованиям. Ни шагу в сторону, всё четко по ТЗ.

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

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

Проект передают заказчику и следят заранее определённое время, чтобы всё работало.

Как отличить Waterfall от гибких методологий

Классическая методология Waterfall — это работа по заранее написанному и согласованному ТЗ. Гибкость здесь не приветствуется. В этом основное отличие водопадной модели от Agile.

Waterfall отличается от Agile и самими принципами работы, о которых мы говорили выше.

12 принципов Agile

  1. Главное — хороший продукт и довольный заказчик.
  2. Готовность к изменениям в любой момент.
  3. Показывать полностью рабочую часть продукта как можно чаще.
  4. Постоянные встречи команды и заказчика для обмена информацией.
  5. Заказчик и разработчики должны работать вместе, как одна команда.
  6. Важно доверять людям в том, что они делают.
  7. Есть рабочий продукт — есть прогресс.
  8. Гибкие процессы — это непрерывное развитие.
  9. Внимание к качеству способствует гибкости.
  10. Простота процесса разработки избавляет от лишней работы.
  11. Самоорганизующаяся команда работает лучше.
  12. Постоянное стремление к большей эффективности.

Эти принципы появились из agile-манифеста.

Манифест гибкой разработки ПО

  1. Люди важнее инструментов.
  2. Качество продукта важнее документации.
  3. Взаимодействие с заказчиком важнее контракта.
  4. Готовность к изменениям важнее установленного плана.

Если бы для Waterfall тоже написали манифест, он бы выглядел так:

Манифест водопадной модели разработки ПО

  1. Следуйте правилам.
  2. Нет ТЗ — нет продукта.
  3. Чем подробнее ТЗ, тем лучше продукт.
  4. Следите, чтобы не было изменений.

Чем Waterfall отличается от Scrum

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

Waterfall
каскадная модель
Scrum
итерационная модель
Все требования известны вначале и не меняютсяТребования могут меняться по ходу проекта
Объемное и подробное ТЗБэклог
Тестирование в концеТестирование после каждой итерации
НегибкаяГибкая
Готовый продукт в концеРаботающая часть продукта после первой итерации
Клиент не видит промежуточный результатКлиент видит и может влиять на промежуточный результат

Если хотите разобраться подробнее:

  • Посмотрите вебинар «Scrum & Waterfall: битва методологий».
  • Прочитайте статью «Будь гибким: как понять Scrum и создатьagile-команду».
  • Прочитайте руководство «Как создать план проекта в Scrum за5шагов».

Заключение

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

В Digital такое бывает редко, поэтому команды добавляют к каскадной модели гибкие практики: например, проверяют продукт на соответствие требованиям после каждого этапа работы, а не в самом конце.

Руководитель digital-проектов

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

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

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

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

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

Глобально существует 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 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «модель водопада», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.

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

  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… … Википедия

Водопадная модель разработки

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

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

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

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

Аль­тер­на­тива «водо­паду» — итеративная модель раз­ра­ботки (раз­лич­ные «гиб­кие» мето­до­ло­гии, напри­мер).

Бессмертная классика Waterfall

Среди вопросов, неизбежно возникающих в каждом проекте, выделяется один: как целесообразнее управлять процессом разработки продукта? Один из вариантов ответа проверенных годами — Waterfall (или каскадная, водопадная модель управления разработкой ПО).

Правда, сейчас эта методика нещадно критикуется, но так ли все плохо на самом деле или мы в очередной раз придем к тому, что все новое — хорошо забытое старое?

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

Практически каждая команда разработчиков может создавать свою модель жизненного цикла ПО или использовать что-то общепризнанное. Один из вариантов — Waterfall. «Родителем» такой модели считается американец В. У. Ройс, который, по слухам, многое позаимствовал у коллег, присвоив себе лавры. Случилось это в 1970 году. До сегодняшнего дня во многих проектах используется описанный им подход: в первоначальном варианте или с доработками.

Хотя некоторые участники IT говорят о том, что такой методологии «отродясь-то не бывало»:

Как IT-профессионал и преподаватель я в течение более чем 40 лет слышал много мифов об IT-индустрии. Но что продолжает удивлять меня, так это то, почему слово «Waterfall» до сих пор используется для описания методологии, которая не существует и почему создатели методов разработки систем используют его в качестве источника сравнения.
David Dischave,
профессор школы информационных технологий университета Сиракузы, США

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

Waterfall в сфере IT

Основной постулат Waterfall модели разработки ПО заключается в том, что следующий этап не может быть начат, пока не завершен предыдущий. При этом произвольные переходы вперед или назад не допускаются, а этапы не перекрывают друг друга. В этом и заключается основное отличие каскадной методологии от гибких собратьев (или конкурентов): Agile, DSDM, Scrum, FDD.

Чтобы понять мысли Ройса, заложенные в основу модели, можно изучить его труд в оригинале: Royce, Winston (1970), Managing the Development of Large Software Systems.

Процесс работы, основанный на каскаде

Возникновение идеи и ее обсуждение

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

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

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

По окончании анализа требований в наличии имеется ТЗ для программистов и бюджет.

Проектирование программного обеспечения

На этом этапе делаются конкретные шаги:

  1. выбирается платформа программирования (Python, PHP, JS и пр.)
  2. уточняются технические детали (например, как будут взаимодействовать сервис или продукт с серверами, станут ли использовать API, какой будет логика внешнего и внутреннего интерфейса и т.д.)
  3. решаются вопросы безопасности проекта (например, будет ли использоваться HTTPS, SSL-шифрование и пр.)
  4. описываются роли пользователей программного продукта (администратор, клиент, менеджер и пр.)
  5. финализируются вопросы надежности, производительности и дальнейшей техподдержки целевого продукта
  6. формируется конкретная команда.

Разработка программного обеспечения

Этап, на котором пишется код, соответствующий документации, разработанной ранее.

Тестирование программного обеспечения

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

Техническая поддержка программного обеспечения

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

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

Чтобы понять эволюцию классической водопадной методологии, описанной выше, можно изучить PMBOK. Между 3-ей и 4-й версиями есть ряд различий, которые помогут понять путь “каскада«.

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

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

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

Слабые стороны каскадной модели
разработки ПО

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

Как и когда использовать каскадную модель разработки?

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

  1. заказчик участвует в проекте только на первом этапе и принимает готовый продукт;
  2. изменять требования к продукту не планируется;
  3. проект отличается высокой сложностью, длительностью и дороговизной;
  4. основной приоритет — качество, даже в ущерб времени;
  5. отсутствие команды разработчиков экстра-класса;
  6. допускается возможность выполнения проекта на аутсорсе.

Для понимания же мотивации отказа от каскадной методологии можно прочесть книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда.

Примеры использования Waterfall

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

Понимание особенностей работы с такими проектами улучшает книга Сергея Зыкова «Основы проектирования корпоративных систем».

И это логично. Об этом говорит и Чак Кобб, автор книг, посвященных Аgile-методам в проектном менеджменте, наставник, инструктор:

Если бы вы строили мост через реку, было бы смешно сказать: «Мы построим первый пролет, посмотрим, как это выходит, а затем решим, как закончить оставшиеся пролеты!

Среди компаний, в которых использовали или используют Waterfall можно отметить:

Для чего использовалась модель Waterfall

Используется ли сейчас методология

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

Wüstenrot & Württembergische (W&W)

Разработка ERP-системы для финансового сектора

Модель жц водопад пРимееняется для

В 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… … Википедия

QA evolution

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

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

Waterfall

Для классической модели разработки программного обеспечения выделяют следующие этапы:

  1. Анализ требований проекта. Определяются программные требования для информационной предметной области системы.
  2. Проектирование. Разрабатывается и формулируется логически последовательная техническая характеристика программной системы. Детализация системы.
  3. Реализация ПО. Воплощение полноценного проекта.
  4. Тестирование продукта. Тестовая эксплуатация продукта
  5. Интеграция системы. Включает установку и официальную приёмку продукта.
  6. Поддержка. Предоставление технической помощи по продукту после запуска а коммерческую эксплуатацию.

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

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

ПРОЕКТ И ДОКУМЕНТАЦИЯ

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

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

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

Мета информация

  • Количество процессов — 6
  • Команда — десятки человек
  • Watrefall проект должен постоянно иметь актуальную документацию. Обязательная актуализация проектной документации. Избыточная документация
  • Очень не гибкая методологии
  • Может создать ошибочное впечатление о работе над проектом (например фраза «45% выполнено» не несёт за собой никакой полезной информации, а является всего лишь инструментов для менеджера проекта)
  • У Заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы
  • У Пользователя нет возможности привыкать к продукту постепенно
  • Все требования должны быть известны в начале жизненного цикла проекта
  • Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выйдет из графиков
  • Отсутствует возможность учесть переделку, весь проект делается за один раз
  • Высокая прозрачность разработки и фаз проекта
  • Чёткая последовательность
  • Стабильность требований
  • Строгий контроль менеджмента проекта
  • Облегчает работу по составлению плана проекта и сбора команды проекта
  • Хорошо определяет процедуру по контроля качества

Применение

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

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