SDLC — V-модель

V-модель — это модель SDLC, в которой выполнение процессов происходит последовательно в форме буквы V. Он также известен как модель верификации и валидации .

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

V-модель — Дизайн

В рамках V-модели соответствующая фаза тестирования фазы разработки планируется параллельно. Итак, есть фазы проверки на одной стороне «V» и фазы проверки на другой стороне. Фаза кодирования объединяет две стороны V-модели.

На следующем рисунке показаны различные фазы V-модели SDLC.

V-модель — Этапы верификации

В V-модели есть несколько этапов верификации, каждый из которых подробно описан ниже.

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

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

Системный дизайн

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

Архитектурный дизайн

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

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

Модуль Дизайн

На этом этапе указывается подробный внутренний дизайн для всех системных модулей, называемый Низкоуровневым проектированием (LLD) . Важно, чтобы проект был совместим с другими модулями в архитектуре системы и другими внешними системами. Модульные тесты являются неотъемлемой частью любого процесса разработки и помогают устранить максимальные ошибки и ошибки на самой ранней стадии. Эти модульные тесты могут быть разработаны на этом этапе на основе внутренних конструкций модулей.

Фаза кодирования

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

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

Этапы валидации

Различные этапы валидации в V-модели подробно описаны ниже.

Модульное тестирование

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

Интеграционное тестирование

Интеграционное тестирование связано с этапом архитектурного проектирования. Интеграционные тесты выполняются для проверки сосуществования и связи внутренних модулей в системе.

Тестирование системы

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

Приемочное тестирование

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

V- Модель ─ Применение

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

Следующие указатели являются одними из наиболее подходящих сценариев для использования приложения V-Model.

• Требования четко определены, четко задокументированы и зафиксированы.

• Определение продукта является стабильным.

• Технология не динамична и хорошо понимается командой проекта.

• Здесь нет двусмысленных или неопределенных требований.

• Проект короткий.

Требования четко определены, четко задокументированы и зафиксированы.

Определение продукта является стабильным.

Технология не динамична и хорошо понимается командой проекта.

Здесь нет двусмысленных или неопределенных требований.

Проект короткий.

V-модель — плюсы и минусы

Преимущество метода V-Model заключается в том, что его очень легко понять и применить. Простота этой модели также облегчает управление. Недостатком является то, что модель не является гибкой к изменениям, и на случай изменения требований, которое очень распространено в современном динамичном мире, внесение изменений становится очень дорогим.

Преимущества метода V-модели заключаются в следующем —

• Это очень дисциплинированная модель, и Фазы завершаются по одному.

• Хорошо работает для небольших проектов, где требования очень хорошо поняты.

• Просто и легко понять и использовать.

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

Это очень дисциплинированная модель, и Фазы завершаются по одному.

Хорошо работает для небольших проектов, где требования очень хорошо поняты.

Просто и легко понять и использовать.

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

Недостатки метода V-модели заключаются в следующем —

Высокий риск и неопределенность.

Не очень хорошая модель для сложных и объектно-ориентированных проектов.

Плохая модель для длительных и текущих проектов.

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

Как только приложение находится в стадии тестирования, трудно вернуться назад и изменить функциональность.

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