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

Веб-разработка 2020-06-21 18:33:27

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

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

Краткие сведения

  • Что такое каскадная модель?
  • Как работает каскадная модель?
    • Фазы каскадной модели
      • Анализировать
      • Дизайн
      • Реализация
      • Тест
      • Оценка модели incascade
        • Обзор преимуществ и недостатков каскадной модели
        • Проверка после каждого этапа проекта
        • По крайней мере две итерации
        • Тесты, интегрирующие конечного пользователя

        • Альтернативы каскадной модели
        • Что такое каскадная модель?

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

          Как работает модель? каскад?

          Нам нужна разработка классической каскадной модели для компьютерщика Уинстона Уокера Ройса. Однако Ройс не был изобретателем.

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

          Он рекомендовал модель в семь фаз, которая проходила в несколько этапов (итераций):

          • Системные требования
          • Требования к программному обеспечению
          • Анализ
          • Дизайн
          • Реализация
          • Тест
          • Эксплуатация
          • Модель управления, называемая каскадной моделью, основана на фазах, определенных Ройсом,

            но предусматривает одну итерацию .

            В своем эссе Ройс ни разу не упоминает термин

            Примечание

            Модель в Каскаде обязана своей большой известностью американскому стандарту DoD-STD-2167, который основан на чрезвычайно упрощенной форме модели управления. Разработанной Ройсом. Которая не была достаточно понята авторами. Такими как Дэвид Мейбор — один из авторов стандарта — уступил ей годы спустя. Эта ошибка была вызвана непониманием итерационных и инкрементных моделей.

            На практике используется несколько вариантов каскадной модели. Наиболее распространенные модели делят процесс разработки на пять фаз, причем фазы 1, 2 и 3, определенные Ройсом. Иногда группируются в одну фазу. Называемую анализом потребностей.

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

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

              Модель водопада, основанная на требованиях Уинстона Уолтера Ройса. Делит процесс разработки на пять этапов проекта: анализ. Проектирование, внедрение. Тестирование и эксплуатация.

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

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

              Фазы каскадной модели

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

              Анализ

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

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

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

              Концепция

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

              Реализация

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

              Тест

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

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

              Оценка каскадной модели

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

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

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

              Обзор преимуществ и преимуществ каскадной модели

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

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

              Проверка после каждого этапа проекта

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

              По крайней мере, две итерации

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

              Тесты, интегрирующие конечного пользователя

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

              Альтернативы каскадной модели

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

              В то время как такие модели , как спиральная модель или модель V-цикла. Считаются улучшениями классической каскадной модели, такие концепции. Как “экстремальное программирование