V-модель является продолжением модели Waterfall, поэтому не ожидайте, что она будет сильно отличаться.
По сути, вы следуете V-модели слева направо , как в модели Waterfall. В «Водопаде» вы выполняете требования, проектируете, внедряете, проверяете и, наконец, обслуживаете. Таким же образом, в V-модели вы выполняете требования, проектирование, реализацию, проверку и обслуживание: одинаковые шаги в обоих случаях.
Основными отличиями от Waterfall являются способ его представления и акцент на тестировании.
Представление потока в виде V-образной формы помогает определить разницу между всем, что предшествует кодированию (требования, архитектура и дизайн), и всем, что следует за кодированием (в основном, тестированием). Хотя тесты в Waterfall - это лишь один из пяти этапов, в V-модели это выглядит практически как половина процесса.
Диаграмма в вашем вопросе немного сложнее. То, что он пытается показать, это то, что, например, этап проектирования системы приводит не только к документу по проектированию системы, как предполагает модель Waterfall, но также и к проектированию системных тестов, которые позже помогут в написании системных тестов. Диаграмма просто делает еще больший акцент на тестировании . Наконец, разработка системного теста помогает в проектировании архитектуры (было бы неудобно заниматься проектированием архитектуры независимо от проектирования системного теста).
Ища другие объяснения в Интернете, я не могу не процитировать следующую статью Бхакти Саталкар :
Основное различие между моделью водопада и моделью V состоит в том, что в модели водопада испытания выполняются после завершения работ по разработке. С другой стороны, в модели V тестирование начинается с самого первого этапа. Другими словами, модель водопада - это непрерывный процесс, а модель V - одновременный процесс. По сравнению с программным обеспечением, созданным с использованием модели водопада, количество дефектов в программном обеспечении, выполненном с использованием модели V, меньше. Это связано с тем, что существуют тестовые действия, которые выполняются одновременно в V модели. Поэтому модель водопада используется, когда требования пользователя зафиксированы. Если требования пользователя являются неопределенными и продолжают изменяться, то V-модель является лучшей альтернативой.
Это объяснение вводит в заблуждение . Это будет верно только в том случае, если вы замените «V-модель» в цитате любым методом Agile.
В отличие от статей, в V-модели тестирование выполняется после кодирования; например, см. википедию :
Обычная практическая критика V-модели заключается в том, что она приводит к тому, что тестирование оказывается в тесных окнах в конце разработки, когда более ранние этапы превышают допустимые сроки, но дата внедрения остается фиксированной.
В то время как в V-модели дизайн системного теста следует дизайну системы, не дожидаясь завершения реализации продукта, это не означает, что сами тесты выполняются до кодирования. Автор путает V-модель с Agile-подходами, такими как Test Driven Development (TDD) в Extreme Programming (XP).
V
Representing the flow as V-shape helps making the difference between everything which comes prior to coding (requirements, architecture and design) and everything which follows coding (essentially testing). While tests are just one of five steps in Waterfall, it looks like practically half of the process in V-model.
= прибил это! Спасибо