Введение в модель водопада

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

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

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

Фазы Водопада Модель

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

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

  1. Требования
  2. Анализ
  3. дизайн
  4. Кодирование / реализация
  5. тестирование
  6. Эксплуатация / развертывание
  7. техническое обслуживание

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

  1. Требования: если говорить конкретно, нам нужно знать и понимать, что мы должны проектировать, что мы должны разрабатывать, каковы его процессы, каковы будут его функциональные возможности и т. Д. Он предоставляет исходные материалы для производимого продукта и, следовательно, для будущего продукта. изучен, доработан и отмечен. Это также дает нам возможность расширять требования к аппаратному или программному обеспечению продукта, который будет спроектирован, разработан и реализован на всех этапах.
  2. Анализ: это приводит к разработке моделей, схем и бизнес-правил. Не только это требование делится на две части:
  • Сбор и анализ требований: сначала вся информация и требования для разработки продукта собираются у клиента, а затем обрабатываются для анализа. Основная роль этой части заключается в искоренении незавершенности и несоответствий, связанных с разработкой программного продукта.
  • Спецификация требований: Затем проанализированные выше требования документируются в документе SRS (спецификация требований к программному обеспечению). Он служит связующим звеном между заказчиком и командой разработчиков SRS. Любые споры в будущем разрешаются и разрешаются только с помощью этой документации SRS.
  1. Проектирование: после того, как первый этап завершен и проверен, это следующий наиболее важный этап, который необходимо изучить, поскольку он используется для проектирования системы. Это помогает в определении требований к программному и аппаратному обеспечению для дизайна продукта. Это также помогает в общей архитектуре для системного дизайна. Таким образом, спецификация требований в основном изучается и проверяется на этом этапе. Это также полезно для преобразования документа SRS в функциональное проектирование и разработку программного продукта. Таким образом, мы можем сказать, что на этапе проектирования создается общая архитектура для проекта разработки программного обеспечения.
  2. Внедрение: После полной проверки проекта системы начинается этап внедрения. На этом этапе принимаются входные данные от проектирования системы, и она сначала разрабатывается в небольших программах, известных как устройства, которые тестируются и реализуются на следующем этапе. Каждый модуль на этапе реализации подвергается разработке, и его полная функциональность тестируется, что также называется модульным тестированием. Таким образом, на этом этапе проект системы преобразуется в исходный код с полнофункциональными программными модулями. Включает разработку, проверку и интеграцию программного обеспечения.
  3. Интеграция и тестирование: каждый блок, разработанный и разработанный на более ранних этапах, включается в фазу реализации, которая интегрируется в модуль или систему для различных испытаний, таких как нагрузочное тестирование, тестирование на отвод и т. Д., После тестирования каждого блока. Среда тестирования подвергается постоянной проверке программного обеспечения, чтобы выяснить, есть ли какие-либо потоки или ошибки в дизайне или коде. Тестирование проводится для поддержания стабильности и выполнимости программного обеспечения, чтобы клиент не сталкивался с какими-либо помехами или ошибками во время его производства. Таким образом, на этом этапе после внедрения вся система тщательно тестируется на наличие ошибок и сбоев. Системное тестирование состоит из трех различных типов действий, которые можно объяснить, как показано ниже:
  • Альфа (α) тестирование: это тестирование, выполненное командой разработчиков.
  • Бета-тестирование: это тестирование, выполненное дружной командой клиентов и пользователей.
  • Приемочное тестирование: оно проводится после альфа-тестирования и бета-тестирования. В основном, это тестирование проводится после доставки заказчиками. После тестирования, выполненного заказчиком, принимается решение, является ли это программное обеспечение приемлемым или отклонить его. Так что на этом этапе в основном отладка ошибок делается.
  1. Развертывание системы / Операции: после завершения нефункционального, функционального, альфа- и бета-тестирования продукт программного обеспечения развертывается в системе пользователя или клиента или выпускается на рынок. Этап развертывания включает в себя установку, миграцию и поддержку всей системы в среде пользователя или клиента.
  2. Техническое обслуживание: это последний, но самый важный этап в модели рабочего процесса водопада. Этот шаг выполняется сразу после установки и включает в себя внесение соответствующих изменений в продукт или систему, либо для улучшения, изменения или изменения атрибутов, связанных с проблемой производительности, связанной с системой. его основная роль заключается в повышении производительности системы с максимальной точностью результата программного обеспечения. Эти изменения, возникающие на этапе обслуживания, в основном связаны с изменениями, инициированными заказчиком или пользователями после фазы установки и тестирования, которые включают ошибки, такие как дефект, обнаруженный во время использования системы в реальном времени, или запрос, выдвинутый клиентами. Таким образом, клиенту предоставляется своевременное и плановое обслуживание и поддержка разработанного продукта. Вы действительно будете удивлены, узнав, что усилия, предпринятые на этапе проектирования и разработки программного продукта, составляют всего лишь 60% усилий по сравнению с усилиями, предпринятыми на этапе обслуживания. Есть три основных вида обслуживания, которые описаны ниже:
  • Корректирующее обслуживание: на этапе проектирования и разработки некоторые ошибки не обнаруживаются, они учитываются только при использовании клиентом. Это только корректирующее обслуживание, которое означает исправление проблем или ошибок, которые не были обнаружены на этапе разработки.
  • Безупречное обслуживание. Этот тип обслуживания выполняется по запросу клиента для расширения и улучшения функциональных возможностей системы или программного обеспечения.
  • Адаптивное обслуживание: это обслуживание, которое требуется для переключения системной среды. Обычно требуется для переноса существующей системы в новую среду или на новый компьютер или систему или, возможно, с новой операционной системой. Этот этап слишком важен, так как это ведет к повышению производительности системы.

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

преимущества

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

  • Это позволяет отделить и контролировать.
  • График может быть установлен со сроками для каждого этапа разработки, и продукт может проходить этапы модели процесса разработки один за другим.
  • Поскольку он проходит легко понятные и объяснимые фазы, он преодолевает многие проблемы, поэтому его очень легко использовать.
  • Из-за жесткости модели рабочего процесса им очень легко управлять, поскольку каждая фаза в модели водопада имеет особые процессы анализа и получения результатов.
  • Модель водопада хорошо работает для небольших проектов, где требования очень хорошо поняты.
  • График может быть установлен с крайними сроками для каждого этапа разработки, и продукт может проходить этапы модели процесса разработки один за другим.
  • Четко определенные этапы.
  • Хорошо понятные вехи.
  • Легко организовать задачи.
  • Процесс и результаты хорошо документированы.
  • Укрепляет хорошие привычки: определите, прежде чем дизайн,
  • Дизайн-Before-кода.
  • Модель хорошо работает для небольших проектов и проектов, где требования хорошо понятны.

Недостаток

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

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

Где использовать модель водопада

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

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

Вывод

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

Рекомендуемые статьи

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

  1. Что такое AWS?
  2. Что такое Bootstrap?
  3. Что такое улей?
  4. Что такое Unix?
  5. Скрам против водопада | сравнение

Категория:

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