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

Содержание
  1. Pros & Cons of Waterfall Methodology
  2. Понятие о каскадной методологии управления проектами
  3. Benefits of waterfall project management
  4. Advantages of the Waterfall Methodology
  5. Жизненный цикл разработки программного обеспечения
  6. Каскадное управление — «водопад»
  7. Преимущества и недостатки Waterfall
  8. Agile methodology
  9. История возникновения водопадной модели
  10. Приложения и программы для управления разработкой по каскадной модели
  11. Using ProjectManager.com for Waterfall Project Management
  12. What’s the best way?
  13. Сравнительная таблица
  14. Процесс работы, основанный на каскаде
  15. Примеры использования Waterfall
  16. Критика каскадной модели и гибридные методологические решения

Pros & Cons of Waterfall Methodology

There are several reasons why managers choose to use the waterfall project management methodology. Here are some benefits:

  • Because project requirements are agreed upon in the first phase, planning and scheduling is simple and clear.
  • With a fully laid out project schedule, you can give an accurate estimate for your project cost, resources and deadlines.
  • It’s easy to measure progress as you move through the phases and hit milestones.
  • Customers aren’t perpetually adding new requirements to the project, delaying production.

Of course, there are drawbacks to using the waterfall method as well. Here are some disadvantages to this approach:

  • It can be difficult for customers to articulate all of their needs at the beginning of the project.
  • If the customer is dissatisfied with the product in the verification phase, it can be very costly to go back and design the code again.
  • A linear project plan is rigid and lacks flexibility for adapting to unexpected events.

Although it has its drawbacks, a waterfall project management plan is very effective in situations where you are encountering a familiar scenario with several knowns, or in situations where your customer knows exactly what they want at the onset.

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

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

Каскадное управление проектом начинается с этапа определения требований или составления списка предполагаемых функций и характеристик системы.

Разработчики создают архитектуру программного обеспечения на этапе проектирования.

Далее идет этап реализации, в ходе которого осуществляется разработка и интеграция ПО.

На этапе тестирования и отладки команда находит и исправляет ошибки.

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

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

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

Benefits of waterfall project management

Although most companies use some combination of project management styles, a 2017 report from LiquidPlanner showed that 25.5% of manufacturing companies currently use waterfall. What makes this methodology successful for so many teams?

Keeps training simple

This methodology could ensure your project’s success even if there are unanticipated changes in bandwidth. Because waterfall project management emphasizes thorough documentation, you can easily and seamlessly add new team members to any project. There’s no need to intuit what an absent programmer was trying to do, as everything—from the project’s conception to its completion—is recorded. New team members can simply refer to documentation to get quickly up to speed.

Shows progress

Waterfall project management also shows progress simply. The clear milestones delineated in the first phase make it easy to determine if a project is moving forward on schedule. Likewise, the discrete phases indicate how close a project is to overall completion at any given time, as the waterfall system does not allow for revisiting a prior phase. This eliminates much of the guesswork related to a project’s timeline.

Makes the project easy to manage

These benefits, combined with the linear nature of the system, make waterfall projects easy to manage. Because of the sequential system, you’ll know where the project is at any given time and if that’s where it should be. Rather than scrambling to manage a large team, a manager can focus exclusively on team members participating in a given phase. And should there be unexpected outside delays or personnel changes, waterfall documentation allow you to quickly get your team back on track.

Saves time and money

Whether you decide to fully commit to waterfall project management, there’s no question that certain aspects of this methodology—namely, thorough conceptualization and detailed documentation—better prepare you to execute a project the right way the first time. Taking the time early on to discover and plan for requirements can save you time and money down the line.

Advantages of the Waterfall Methodology

The waterfall primarily recommends to invest the bulk of the time, capital and energy up front: 20-40% in the first two stages, 30-40% on the development/coding, and the remaining spend on the implementation and maintenance.

  • It is useful for projects which give more priority to quality than to the cost or the time duration.
  • Suitable for projects which are easy to implement and doesn’t need a lot of resources and efforts.
  • The stability of the model makes project management easier.
  • Both the customers and project manager can actively monitor the progress at any stage of the development.
  • Since all phases occur without any overlap, hence it reduces the project complexity.
  • Flexibility in communicating with the clients, especially when any critical requirements needs a design discussion.
Рекомендуем:  Секреты мира виноделия: в поисках истинных экспертов вина

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

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

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

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

Waterfall в сфере IT

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

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

Каскадное управление — «водопад»

Каскадная модель лучше всего подходит для проектов с чётко определёнными границами, то есть когда содержание является ключевым элементом проекта. Примеры: строительство дома, планирование конференции, внедрение Easy Project.

Методика: Задаём границы проекта, то есть определяем содержание — оно будет неизменным. Это означает, что нельзя изменить число окон в доме, место проведения или тему конференции. Далее, время проекта является ограничивающим фактором — мы ограничены полностью (конференция) или почти полностью (внедрение EP). Когда содержание проекта неизменно, главная задача проектного или портфельного менеджера заключается в том, чтобы спланировать, как будут использоваться и расходоваться ресурсы с учётом времени и последовательности реализации проекта.

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

Преимущества и недостатки Waterfall

В число наибольших преимуществ методики Waterfall вошли:

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

Среди недостатков водопадного метода можно выделить:

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

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

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

Agile methodology

Agile is an approach that prioritizes development through evolution. Cross-functional teams collaborate to continually improve and iterate. This methodology really stems from the Agile Manifesto, a set of values and principles that prioritize flexibility, customer needs, quality software, and collaboration. As the name implies, it allows for teams to adjust the project mid-course to address customer needs or to solve issues that arise during iterations.

Agile gives people a common foundation to refer to when developing software, but it’s nowhere near as strict as the Waterfall methodology.

Agile works best for:

  • Projects without known deadlines or the full scope of requirements
  • Teams with direct access to customers 
  • Software that can evolve through iterations
  • Teams without bureaucracy
  • Projects without a fixed budget
  • Projects without competition
  • Customers that are happy to regularly update their software
Рекомендуем:  Как оформить кредит безработному

The Agile methodology is great for fast deployments, smaller budgets, faster feedback, and experimentation. It’s really the methodology that best demonstrates the “fail fast” mindset.

Learn about different agile methods, and start applying agile principles to your team today.

It works best in small-to-medium teams that can think quickly, be flexible, and work independently from major corporate oversight. This is probably why it’s the methodology of choice for most start-ups and app developers.

But it isn’t for everyone. 

What if you’ve read the two descriptions above and your project requirements don’t seem to align with either methodology? There’s a third option.

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

Вам будет интересно:Корректирующее действие — это… Определение, особенности и принципы

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

Вам будет интересно:Ситуационное руководство: описание модели, стили, уровни развития сотрудников

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

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

Для работы с «водопадом» можно использовать ряд сервисов для постановки задач. Ключевые критерии — наличие тайм-трекера, канбан-досок и диаграммы Ганта.

Привлекательный украинский saas-сервис с удобной мобильной версией.

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

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

Using ProjectManager.com for Waterfall Project Management

With Gantt charts, templates, task lists, reporting tools and more, ProjectManager.com has the best features for planning and executing a waterfall project.

Plan the Steps

The Gantt chart is easily the most important tool for waterfall project management. Use our interactive online Gantt chart software to create a timeline of all the tasks and phases in your waterfall project. You can assign tasks to team members and create dependencies between tasks. Dependencies are great in a waterfall setting because they ensure that phases and tasks are completed in sequential order.

Collect Requirements & Other Documentation

ProjectManager.com offers unlimited online file storage, so you can upload all of your requirements documents in one central location where the entire team can gain access. Plus, attach documents like specifications and requirements to tasks on our Gantt chart, so the documentation produced always stays with the relevant phase.

Track Progress Through Each Phase

See how close you are to your next milestone with automatic task bar shading on our Gantt chart. For even more detail, use our real-time dashboards that track more than just tasks. Monitor your team workload, your project expenses and planned vs. actual progress with easy-to-read graphs.

Duplicate Plans with Templates & Imported Files

With Projectmanager.com, you can create templates to quickly plan any recurring waterfall projects. If you know exactly what it takes to get the project done, then make it into a template! Plus, you can import proven project plans from MSP, and task lists from Excel and Word.

What’s the best way?

It’s tempting to become champion of one methodology, especially if you’re accustomed to it, but it’s important to remember that the successful completion of the project takes top priority. A successful methodology is only one that helps teams remain on task, produce a workable product, and stay within budget. That may involve taking the hybrid approach and may also include a bit of trial and error. 

Use the suggestions above to determine what could be the best methodology for each part of your development cycle, and consider adjusting methodologies not just per team or per development section, but per project. If the project is short and easy, it may benefit from the Waterfall methodology, even though your teams are accustomed to an Agile approach. 

Рекомендуем:  Как грамотно составить резюме?

Сравнительная таблица

Agile

Waterfall

Суть

Гибкая модель разработки, основанная наитеративных принципах

Каскадная система разработки, основанная на жёсткой последовательности процесса разработки

Дата создания

2001 г.

1956 г., 1961 г., 1970 г.

Разработчики

Группа IT-специалистов (США)

Г. Беннингтон, Хозьер, В. Уолкер Ройс

Принципы применения

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

Плюсы

  1. высокий уровень взаимодействия между членами команды проекта
  2. быстрый результат (рабочий код) в итоге «спринтов»
  3. стимулирование изменения и улучшений продукта во время его разработки
  4. непосредственное вовлечение заказчика к рабочему процессу.
  1. понятная и чёткая схема рабочего процесса
  2. возможность просчёта точного количества затраченных на проект ресурсов
  3. не требует затрат по налаживанию коммуникаций между всеми членами команды.

Минусы

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

Компании-практики

Unilever, ряд банков (Альфа Банк, Home Credit, Райффайзен Банк и т.д.)

Cisco Ericsson AB, Toyota (до 2010)

Подойдёт вам, если…

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

Не подойдёт, если…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рейтинг статьи
Оцените статью: 1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд
Загрузка...
Комментариев нет, будьте первым кто его оставит

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

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