webdonsk.ruКак сделать каскадную модель
Добавил пользователь Евгений Кузнецов Обновлено: 01.09.2024
Классическая каскадная модель, несмотря на полученную в последнее время негативную оценку, исправно служила специалистам многие годы. Понимание ее сильных сторон и недостатков улучшает оценочный анализ других, зачастую более эффективных моделей жизненного цикла, основанных на данной модели.
В первые годы практики программирования сначала записывался программный код, а затем происходила его отладка. Общепринятым считалось правило начинать работу не с разработки плана, а с общего ознакомления с продуктом. Без лишних формальностей можно было спроектировать, закодировать, отладить и протестировать ПО еще до того, как оно будет готово к выпуску. Это напоминало процесс, изображенный на рис. 1.
В структуре такого процесса есть несколько "неправильностей" (или недостатков). Во-первых, поскольку изначально не существовало официального проекта или анализа, невозможно было узнать о моменте завершения процесса. Также отсутствовал способ определения соответствия требованиям относительно достижения качества.
Рис. 1. Модель процесса "делать, пока, не будет сделано”
В 1970 году каскадная модель была впервые определена как альтернативный вариант метода разработки ПО по принципу кодирование-устранение ошибок, который был широко распространен в то время. Это была первая модель, которая формализовала структуру этапов разработки ПО, придавая особое значение исходным требованиям и проектированию, а также созданию документации на ранних этапах процесса разработки.
Рис. 2. Классическая каскадная модель
Начальный этап выполнения каскадной модели показан в левой верхней части рис. 2. Продолжение процесса выполнения реализуется с помощью упорядоченной последовательности шагов. В модели предусмотрено, что каждая последующая фаза начинается лишь тогда, когда полностью завершено выполнение предыдущей фазы Каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные.
В результате выполнения генерируются внутренние или внешние данные проекта, включай документацию и ПО. Документы по анализу требований впоследствии передаются системным специалистам, которые в свою очередь передают их разработчикам программных систем более высокого уровня. Программисты передают детальные технические характеристики программистам, которые уже представляют готовый код тестерам.
Переход от одной фазы к другой осуществляется посредством формального обзора . Таким образом, клиент получает общее представление о процессе разработки, кроме того происходит проверка качества программного продукта. Как правило, прохождение стадии обзора указывает на договоренность между командой разработчиков и клиентом о том, что текущая фаза завершена и можно перейти к выполнению следующей фазы. Окончание фазы удобно принимать за стадию в процессе выполнения проекта.
Отличительным свойством каскадной модели можно назвать то, что она представляет собой формальный метод, разновидность разработки "сверху вниз", она состоит из независимых фаз, выполняемых последовательно, и подвержена частому обзору.
Рис. 3. Модифицированная каскадная модель с обратной связью
Краткое описание фаз модифицированной каскадной модели
Приведенная ниже характеристика представляет собой краткое описание каждой фазы каскадной модели (включая фазы интеграции):
· исследование концепции — происходит исследование требований на системном уровне с целью определения возможности реализации концепции;
· процесс системного распределения — может быть пропущен для систем по разработке исключительно ПО. Для систем, в которых необходима разработка как аппаратного, так и программного обеспечения, требуемые функции применяются к ПО и оборудованию в соответствии с общей архитектурой системы;
· процесс определения требований — определяются программные требования для информационной предметной области системы, предназначение, линии поведения, производительность и интерфейсы. (В случае необходимости в процесс также включено функциональное распределение системных требований к аппаратному и программному обеспечению.);
· процесс разработки проекта — разрабатывается и формулируется логически последовательная техническая характеристика программной системы, включая структуры данных, архитектуру ПО, интерфейсные представления и процессуальную (алгоритмическую) детализацию;
· процесс реализации — в результате его выполнения эскизное описание ПО превращается в полноценный программный продукт. При этом создается исходный код, база данных и документация, которые лежат в основе физического преобразования проекта. Если программный продукт представляет собой приобретенный пакет прикладных программ, основными действиями по его реализации будут являться установка и тестирование пакета программ. Если программный продукт разрабатывается на заказ, основными действиями являются программирование и код-тестирование;
· процесс установки — включает установку ПО, его проверку и официальную приемку заказчиком для операционной среды;
· процесс эксплуатации и поддержки - подразумевает запуск пользователем системы и текущее обеспечение, включая предоставление технической помощи, обсуждение возникших вопросов с пользователем, регистрацию запросов пользователя на модернизацию и внесение изменений, а также корректирование или устранение ошибок;
· процесс сопровождения— связан с разрешением программных ошибок, неисправностей, сбоев, модернизацией и внесением изменений, генерируемых процессом поддержки. Состоит из итераций разработки и предполагает обратную связь по предоставлению информации об аномалиях;
· процесс вывода из эксплуатации — вывод существующей системы из ее активного использования либо путем прекращения ее работы, либо благодаря ее замене новой системой или модернизированной версией существующей системы;
· интегральные задачи — включают начало работы над проектом, мониторинг проекта и его управление, управление качеством, верификацию и аттестацию, менеджмент конфигурации, разработку документации и профессиональную подготовку на протяжении всего жизненного цикла.
Нетрудно заметить, что каскадная модель имеет множество преимуществ, если ее использовать в проекте, для которого она достаточно приемлема. Ниже перечислены эти преимущества:
· модель хорошо известна потребителям, не имеющим отношения к разработке и эксплуатации программ, и конечным пользователям (она часто используется другими организациями для отслеживания проектов, не связанных с разработкой ПО);
· она весьма доступна для понимания, так как преследуется простая цель — выполнить необходимые действия;
· она проста и удобна в применении, так как процесс разработки выполняется поэтапно;
· ее структурой может руководствоваться даже слабо подготовленный в техническом плане или неопытный персонал;
· она отличается стабильностью требований;
· она представляет собой шаблон, в который можно поместить методы для выполнения анализа, проектирования, кодирования, тестирования и обеспечения;
· она хорошо срабатывает тогда, когда требования к качеству доминируют над требованиями к затратам и графику выполнения проекта;
· она способствует осуществлению строгого контроля менеджмента проекта;
· при правильном использовании модели дефекты можно обнаружить на более ранних этапах, когда их устранение еще не требует относительно больших затрат;
· она облегчает работу менеджеру проекта по составлению плана
· она позволяет участникам проекта, завершившим действия на выполняемой ими фазе, принять участие в реализации других проектов;
· она определяет процедуры по контролю за качеством. Каждые полученные данные подвергаются обзору. Такая процедура используется командой разработчиков для определения качества системы;
· стадии модели довольно хорошо определены и понятны;
· ход выполнения проекта легко проследить с помощью использования временной шкалы (или диаграммы Гантта), поскольку момент завершения каждой фазы используется в качестве стадии.
Но при использовании каскадной модели для проекта, который трудно назвать подходящим для нее, проявляются следующими недостатки:
· она может создать ошибочное впечатление о работе над проектом. Выражение типа "35 процентов выполнено" — не несет никакого смысла и не является показателем для менеджера проекта;
· интеграция всех полученных результатов происходит внезапно в завершающей стадии работы модели. В результате такого единичного прохода через весь процесс, связанные с интегрированием проблемы, как правило, дают о себе знать слишком поздно. Следовательно, проявятся не обнаруженные ранее ошибки или конструктивные недостатки, повысить степень риска при небольшом задаче времени на восстановление продукта;
· у клиента едва ли есть возможность ознакомиться с системой заранее, это происходит лишь в самом конце жизненного цикла. Поскольку готовый продукт не доступен вплоть до окончания процесса, пользователь принимает участие в процессе разработки только в самом начале — при сборе требований, и в конце — во время приемочных испытаний;
· пользователи не могут убедиться в качестве разработанного продукта до окончания всего процесса разработки. Они не имеют возможности оценить качество, если нельзя увидеть готовый продукт разработки;
· у пользователя нет возможности постепенно привыкнуть к системе. Процесс обучения происходит в конце жизненного цикла, когда ПО уже запущено в эксплуатацию;
· для каждой фазы создаются результативные данные, которые по его завершению считаются замороженными. Это означает, что они не должны изменяться на следующих этапах жизненного цикла продукта. Если элемент результативных данных какого-либо этапа изменяется (что встречается весьма часто), на проект окажет негативное влияние изменение графика, поскольку ни модель, ни план не были рассчитаны на внесение и разрешение изменения на более поздних этапах жизненного цикла;
· все требования должны быть известны в начале жизненного цикла, но клиенты редко могут сформулировать все четко заданные требования на этот момент разработки. Модель не рассчитана на динамические изменения в требованиях на протяжении всего жизненного цикла, так как получаемые данные "замораживаются". Использование модели может повлечь за собой значительные затраты, если требования в недостаточной мере известны или подвержены динамическим изменениям во время протекания жизненного цикла;
· возникает необходимость в жестком управлении и контроле, поскольку в модели не предусмотрена возможность модификации требований;
· модель основана на документации, а значит, количество документов может быть избыточным;
· весь программный продукт разрабатывается за один раз. Нет возможности разбить систему на части. В результате взятых разработчиками обязательств разработать целую систему за один раз могут возникнуть проблемы с финансированием проекта. Происходит распределение больших денежных средств, а сама модель едва ли позволяет повторно распределить средства, не разрушив при этом проект в процессе его выполнения;
Из-за недостатков каскадной модели ее применение необходимо ограничить ситуациями, в которых требования и их реализация максимально четко определены и понятны.
Каскадная модель хорошо функционирует при ее применении в циклах разработки программного продукта, в которых используется неизменяемое определение продукта и вполне понятные технические методики.
Если компания имеет опыт построения определенного рода системы — автоматизированного бухгалтерского учета, начисления зарплаты, ревизии, компиляции, производства, — тогда в проекте, ориентированном на построение еще одного продукта такого же типа, возможно, даже основанного на существующих разработках, можно эффективно использовать каскадную модель. Другим примером надлежащего применения модели может служить создание и выпуск новой версии уже существующего продукта, если вносимые изменения вполне определены и управляемы. Перенос уже существующего продукта на новую платформу часто приводят в качестве идеального примера использования каскадной модели в проекте.
При всей справедливости критики этой модели все же следует признать, что модифицированная версия каскадной модели является в значительной степени менее жесткой, чем ее первоначальная форма. Здесь включаются итерации между фазами, параллельные фазы и менеджмент изменений. Обратные стрелки предполагают возможность существования итераций между действиями в рамках фаз. Чтобы отобразить согласованность между этапами, их объединяют прямоугольниками или под прямоугольниками перечисляют выполняемые на данных этапах действия, чтобы продемонстрировать согласованность между ними. Несмотря на то, что модифицированная каскадная модель является значительно более гибкой, чем классическая модель, она все же не является наилучшим выбором для выполнения проектов по ускоренной разработке.
В этой статье Вадим Кулага, проектный менеджер EPAM Anywhere, расскажет об основных моделях разработки программного обеспечения (SDLC), их плюсах и минусах, а также о реальных примерах их использования.
Более половины ИТ-проектов заканчиваются провалом. Одни из самых распространенных причин неудач ИТ-проектов – неправильная интерпретация бизнес-целей, игнорирование клиентов, неправильная расстановка приоритетов. Но у всех у них общий корень проблемы: неправильный подход к разработке программного обеспечения.
Основные методологии разработки ПО
Методология разработки программного обеспечения (SDLC) представляет собой последовательность действий, которые необходимо выполнить, чтобы получить готовое решение. Проще говоря, это способ создания программного продукта. Проблема в том, что существует множество моделей SDLC, которые используются для разных типов проектов. Как узнать, какой из них подходит для вашего проекта? В статье я перечислил наиболее популярные модели SDLC, их варианты использования, преимущества и недостатки.
Каскадная модель (waterfall)
Это линейная и последовательная модель разработки программного обеспечения, в которой фазы проекта следуют одна за другой и включают:
Плюсы и минусы подхода
| Плюсы | Минусы |
| Простая в использовании модель. | С этой моделью слишком сложно и дорого адаптироваться к изменениям требований. |
| Каждый этап хорошо задокументирован. | Документирование каждой фазы проекта занимает много времени. |
| Результат проекта абсолютно предсказуем. | Вы не можете ничего предоставить заказчику, пока не завершите весь проект. |
| Этапы и роли четко определены с самого начала. | Различные команды (дизайн, разработка, контроль качества и т. д.) изолированы, а взаимодействие между ними ограничено. |
| Минимальное вмешательство клиента. | Без обратной связи клиента результат рискует не оправдать ожидания. |
Каким проектам подходит
Каскадная модель – хороший вариант, если выполняются эти условия:
- Проект короткий и с нулевым риском.
- Требования фиксированные.
- Технологии стабильны.
- Доступны все необходимые ресурсы.
Всего десять лет назад многие компании использовали каскадную модель для разработки корпоративного программного обеспечения, включая CRM, системы управления цепочками поставок и системы точек продаж. Но сегодня эта модель не может удовлетворить быстро меняющиеся технические потребности. Вот почему компании все чаще обращаются к более современным подходам.
V-образная модель SDLC
| Плюсы | Минусы |
| Легко реализовывать. | В V-образной модели внести изменения в середине проекта крайне сложно. |
| Тест-кейсы создаются заранее. | При таком большом количестве процедур тестирования остается меньше времени на код. |
| Бюджет и продолжительность проекта предсказуемы. | По сравнению с каскадной эта модель требует больше специалистов. |
| У каждого этапа есть свои результаты, и все хорошо задокументировано. | Модель не подходит для проектов с быстро меняющимися требованиями. |
| Это структурированный подход с четко определенными ролями и функциями. | Не подходит для больших и сложных проектов. |
Каким проектам подходит
V-образная модель может быть чрезвычайно полезна в случаях, когда ошибки могут быть фатальными, и в проектах, где точность имеет решающее значение. Например, это решение, основанное на нормативных требованиях, таких как подача налоговых деклараций. Кроме того, эта модель подходит для проектов в сфере здравоохранения. Например, компания Roche Diagnostics однажды использовала его для разработки системы диагностики рака.
Модель эволюционного прототипирования
Это ещё одна вариация каскада. Пока проект проходит через традиционные фазы, прототип продукта пошагово дорабатывается на основе отзывов клиентов. Как правило, первый прототип не проходит приемочный тест, поэтому модель прототипирования включает в себя несколько прототипов. Только после того, как предложенный дизайн продукта будет полностью принят, команда разработчиков сможет перейти к следующим этапам.
| Плюсы | Минусы |
| Получение отзывов пользователей на ранних этапах. | Поскольку прототипы могут развиваться бесконечно, планирование проекта невозможно. |
| Высокие шансы на успех проекта. | Разрабатывать несколько прототипов – дорого. |
| Легко адаптироваться к быстро меняющимся требованиям. |
Каким проектам подходит
Модель эволюционного прототипирования может быть полезна для проектов, которые предполагают взаимодействие с пользователем, используют новые технологии, имеют сложную функциональность или должны учитывать быстро меняющиеся требования, которые трудно или невозможно предсказать.
Итеративная и инкрементальная модель
В инкрементальной и итеративной модели решение разрабатывается небольшими частями через серию циклов. Рабочий процесс выглядит следующим образом:
Каким проектам подходит
Модель будет эффективна в следующих случаях:
- Если система состоит из нескольких сегментов с чёткими требованиями.
- Ограниченные ресурсы на проекте или есть ограничения по времени выхода решения на рынок.
- Для стартапов, проходящих инвестиционные раунды.
- Масштабные проекты.
- Проекты, в основе которых новые технологии.
- Проекты, которые потребуется развивать после выпуска.
По словам Алистера Скотта , каждый программный продукт, который хочет оставаться конкурентным на рынке, требует наращивания мощностей. Даже если вы будете использовать каскадную модель для разработки своего решения, к моменту завершения цикла решение уже устареет. Поэтому необходимы дополнительные итерации.
Спиральная модель
Этот подход основан на оценке риска, он сочетает в себе функции каскадной, прототипной, итеративной и инкрементной моделей. Модель похожа на спираль с несколькими кругами. Каждый круг – это фаза, состоящая из четырёх элементов:
- Сбор требований. Он включает выявление и анализ потребностей заинтересованных сторон и бизнес-целей.
- Анализ рисков и прототипирование. Команда оценивает все возможные способы удовлетворения потребностей клиентов и выбирает лучшее решение. Затем они выявляют и устраняют риски, связанные с решением, и создают прототип, который развивается с каждым последующим циклом.
- Инжиниринг. Команда инженеров продолжает разработку и тестирование того, что было запланировано на двух предыдущих этапах.
- Планирование следующего этапа. Готовый продукт отправляется заказчику для получения обратной связи. Кроме того, команда разработчиков анализирует весь цикл с точки зрения расписания, бюджета и других критериев.
Затем, на основе отзывов пользователей и заинтересованных сторон, планируется следующая итерация.
Как видите, продукт неоднократно проходит через эти этапы, и в конце каждого цикла создаётся и выпускается лучшая версия продукта. И, как и в итеративном подходе, продукт состоит из серии релизов.
Каким проектам подходит
Спиральная модель подходит для:
- Больших, сложных продуктов, состоящих из нескольких компонентов.
- Проектов с частыми релизами.
- Проектов средней и высокой степени риска.
- Проектов с неясными требованиями.
Microsoft, IBM и Tata Consultancy используют спиральную модель.
Модели гибкой разработки программного обеспечения
Вопреки распространённому мнению Agile не является ни структурой, ни методологией. Это философия с набором принципов, ориентированных на ускорение процесса разработки программного обеспечения, обеспечение 100% удовлетворённости клиентов и предоставление высококачественных решений в быстро меняющейся среде. Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:
- Люди и взаимодействие важнее процессов и инструментов.
- Рабочее программное обеспечение над обширной документацией.
- Сотрудничество с клиентами вместо переговоров по контракту.
- Реагирование на изменения вместо следования плану.
Ценности Agile породили более 50 методологий , из которых Scrum является самой популярной .
Scrum
Скрам-проекты разбиты на спринты. Спринт – это небольшой объём работы, который необходимо выполнить в течение определённого периода времени. Обычно заказчику доставляется часть проекта, которая была завершена во время спринта (инкремент продукта, от англ. increment). Скрам подразумевает активное общение и сотрудничество между всеми участниками проекта. Наряду с ежедневными 15-минутными встречами разработчиков, есть также:
- Планирование спринта , когда заинтересованные стороны проекта и команда разработчиков встречаются, чтобы обсудить, что нужно сделать во время следующего спринта.
- Обзор спринта , когда команда разработчиков демонстрирует заинтересованным сторонам, что было сделано во время спринта, и анализируется прогресс в достижении цели проекта.
- Ретроспектива спринта , когда команда разработчиков анализирует спринт и обсуждает, как можно улучшить процессы во время следующих спринтов.
Сердце процессов Scrum – это backlog, своего рода список задач, которые необходимо сделать для завершения проекта. По мере того, как проект продвигается, и команда узнаёт о нём больше, они редактируют бэклог продукта, добавляя, удаляя и переупорядочивая его элементы. Тем не менее, нельзя сделать что-то, если этого нет в очереди продукта.
Но на самом ли деле всё так гладко и красиво в Agile? Посмотрим на его основные варианты использования, а также на плюсы и минусы.
| Плюсы | Минусы |
| Не нужно ждать завершения проекта, чтобы внедрить основные функции продукта. | Гибкие методологии разработки ПО сложно внедрить. |
| Кросс-функциональные команды регулярно общаются и обмениваются знаниями между собой и владельцами проектов. | В Agile проектная документация очень быстро устаревает, поэтому понадобятся дополнительные навыки оперативной работы с ней. |
| Возможность адаптироваться к изменениям на любой стадии проекта. | В Agile проектах практически невозможно делать прогнозы и достаточно тяжело с высокой долей точности планировать бюджет. |
| Регулярная обратная связь от пользователей, что позволяет удовлетворить все потребности. | Сбор отзывов пользователей может быть сложной задачей. |
Примеры использования
- Требования к проекту недостаточно ясны.
- Требования к проекту постоянно меняются.
- Проект включает в себя множество взаимодействий с пользователем.
- У проекта много заинтересованных сторон.
В общем, Agile кажется именно тем, что нужно большинству проектов во времена неопределённости. Неудивительно, что более 70% компаний применяют Agile , включая Microsoft, IBM, Procter & Gamble и другие. И EPAM не исключение.
Резюме
Вот несколько советов как подходить к разработке на примере реального проекта EPAM Anywhere :
Каскадная модель маркетинга
Артём Седов
Усилю марткетинг онлайн-школы
Думаю, ближайшие 4 года будут определяющими в жизни многих перфоманс-агентств. Многие отделы лидогенерации в инфобизнесе, екоммерсе, строительстве и медицине тоже будут трансформироваться.
Старые стандарты будут вымирать
Старые стандарты естественным образом будут вымирать. На смену придут те игроки, кто знает как работать с базой. Ценности в простой закупке трафика будет все меньше, а взрывной рост на холодном трафике уже сейчас не возможен. Это мнение справедливо для всех ниш.
Инфобизнес будет в целом жёстче. Конкуренция будет больше. Маржинальность будет ниже. Цена ошибки будет выше. Порог входа будет выше. Учить будут всех, всему и хорошо. У пользователей будет большой выбор. Поэтому начинайте копить базу уже сейчас и работайте над доверием и технологиями удержания внимания пользователей.
Каскадная модель монетизации — это тот термин, который максимально ёмко описывает работу с базой. Один каскад — одна попытка продать. Самый верхний каскад — входная воронка для холодного трафика. Далее — активности, процессы, форматы, контент, запуски.
Представьте себе путь одного из своих пользователей:
- прошёл регистрацию и попал в автомарафон
- через неделю пришёл на день открытых дверей
- ещё через неделю пришёл на вебинар
- потом изучил видеоархив с кейсами бывших учеников
- распродажами Новый год
- первая покупка
Все это сопровождается регулярными постами в соцсетях, рассылками, публикациями в каналах и сторисами эксперта. Иногда звонят менеджеры отдела продаж и приходят СМС.
Пробежался по нескольким проектам. Если бы они не занимались продажами базе, то заработали бы на 70% меньше, а маржа (с учетом объемов, команды и расхода на трафик) была бы на 90% ниже.
Каскадная модель (англ. waterfall model ) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; забавно, что сам Ройс использовал итеративную модель разработки.
Содержание
Содержание модели
В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:
Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.
Тем не менее, существуют модифицированные каскадные модели (включая модель самого Ройса), имеющие небольшие или даже значительные вариации описанного процесса.
Критика каскадной модели и гибридные методологические решения
См. также
Примечания
Ссылки
| Разработка программного обеспечения | |
|---|---|
| Известные деятели |
|
