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

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

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

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

Я также предлагаю вам прочитать о жизненном цикле тестирования программного обеспечения

Давайте посмотрим, что такое модель водопада, и ее преимущества и Подробнее о недостатках.

Водопад Модель в жизненном цикле разработки программного обеспечения »/> </p>
</p>
<h2> <strong> Модель водопада: </strong> </h2>
<p>Модель водопада — традиционная модель. Это так называемый последовательный процесс проектирования, часто используемый в SDLC, в котором прогресс рассматривается как нисходящий, как водопад, через различные фазы, такие как сбор требований, технико-экономическое обоснование/анализ, проектирование, кодирование, тестирование, установка и обслуживание. Каждый следующий этап начинается только после того, как цель предыдущего этапа достигнута. Эта методология предпочтительнее в проектах, где качество важнее графика или стоимости. Эта методология лучше всего подходит для краткосрочных проектов, где требования не изменятся. (Например, калькулятор, управление посещаемостью) </p>
<h3> <strong>Преимущества: </strong> </h3>
<ul style =

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

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

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

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

    TAG: qa