V-модел, наричан още модел за проверка и валидиране. При това всяка фаза на SDLC трябва да завърши, преди да започне следващата фаза. Той следва последователен процес на проектиране, същият като модела на водопада. Тестването на устройството е планирано паралелно със съответния етап на разработка.
Проверка: Той включва метод за статичен анализ (преглед), извършен без изпълнение на код. Това е процес на оценка на процеса на разработване на продукта, за да се установи дали определените изисквания отговарят.
Валидиране: Включва метод на динамичен анализ (функционален, нефункционален), тестването се извършва чрез изпълнение на код. Валидирането е процесът за класифициране на софтуера след завършване на процеса на разработка, за да се определи дали софтуерът отговаря на очакванията и изискванията на клиента.
Така че V-моделът съдържа фази на проверка от едната страна на фазите на валидиране от другата страна. Процесът на проверка и валидиране е съчетан от фаза на кодиране във V-образна форма. Затова е известен като V-модел.
Има различни фази на фазата на проверка на V-модела:
| Анализ на бизнес изискванията: | Това е първата стъпка, при която продуктовите изисквания са разбрани от страна на клиента. Тази фаза съдържа подробна комуникация за разбиране на очакванията и точните изисквания на клиента.
| Дизайн на системата: | На този етап системните инженери анализират и интерпретират дейността на предложената система чрез изучаване на документа с потребителски изисквания.
| Архитектурен дизайн: | Основното при избора на архитектура е, че тя трябва да разбира всичко, което обикновено се състои от списък с модули, кратка функционалност на всеки модул, техните интерфейсни връзки, зависимости, таблици на базата данни, архитектурни диаграми, подробности за технологията и т.н. Моделът за интеграционно тестване се извършва в определена фаза.
| Дизайн на модула: | Във фазата на проектиране на модула системата се разпада на малки модули. Уточнява се детайлният дизайн на модулите, който е известен като Low-Level Design
| Фаза на кодиране: | След проектирането започва фазата на кодиране. Въз основа на изискванията се избира подходящ език за програмиране. Има някои насоки и стандарти за кодиране. Преди проверка в хранилището, финалната компилация е оптимизирана за по-добра производителност и кодът преминава през много прегледи на кода, за да се провери производителността.
Има различни фази на фазата на валидиране на V-модела:
| Единично тестване: | Във V-модела плановете за изпитване на единици (UTP) се разработват по време на фазата на проектиране на модула. Тези UTP се изпълняват, за да се елиминират грешки на ниво код или ниво единица. Единицата е най-малката единица, която може да съществува независимо, например програмен модул. Тестването на модула проверява дали най-малкият обект може да функционира правилно, когато е изолиран от останалите кодове/единици.
| Интеграционно тестване: | Плановете за тестване на интеграцията се разработват по време на фазата на архитектурния дизайн. Тези тестове потвърждават, че групите, създадени и тествани независимо, могат да съществуват съвместно и да комуникират помежду си.
| Тестване на системата: | Плановете за системни тестове се разработват по време на фазата на проектиране на системата. За разлика от модулните и интеграционните тестови планове, плановете за системни тестове се съставят от бизнес екипа на клиента. Системният тест гарантира, че очакванията на разработчика на приложение са изпълнени.
| Тестване за приемане: | Тестването за приемане е свързано с частта за анализ на бизнес изискванията. Включва тестване на софтуерния продукт в потребителска атмосфера. Тестовете за приемане разкриват проблемите със съвместимостта с различните системи, които са налични в потребителската атмосфера. Той съвместно открива нефункционалните проблеми като натоварване и дефекти в производителността в реалната потребителска атмосфера.
Кога да използвате V-модел?
- Когато изискването е добре дефинирано и не е двусмислено.
- V-образният модел трябва да се използва за малки до средни проекти, където изискванията са ясно определени и фиксирани.
- V-образният модел трябва да бъде избран, когато са налични примерни технически ресурси с съществен технически опит.
Предимство (плюсове) на V-модела:
- Лесно за разбиране.
- Методи за тестване като планиране, проектиране на тестове се случват много преди кодирането.
- Това спестява много време. Оттук и по-висок шанс за успех пред модела водопад.
- Избягва низходящия поток на дефектите.
- Работи добре за малки планове, където изискванията са лесни за разбиране.
Недостатък (против) на V-модела:
- Много твърд и най-малко гъвкав.
- Не е добър за сложен проект.
- Софтуерът се разработва по време на етапа на внедряване, така че не се произвеждат ранни прототипи на софтуера.
- Ако се случат някакви промени по средата, тогава тестовите документи заедно с необходимите документи трябва да бъдат актуализирани.
