V-модель також називається моделлю верифікації та перевірки. У цьому випадку кожна фаза SDLC має завершитися перед початком наступної фази. Він дотримується послідовного процесу проектування, такого ж, як і модель водоспаду. Тестування пристрою планується паралельно з відповідним етапом розробки.
Перевірка: Він передбачає метод статичного аналізу (перегляду), який виконується без виконання коду. Це процес оцінки процесу розробки продукту, щоб визначити, чи відповідають задані вимоги.
Перевірка: Він включає в себе динамічний метод аналізу (функціональний, нефункціональний), тестування виконується шляхом виконання коду. Перевірка — це процес класифікації програмного забезпечення після завершення процесу розробки, щоб визначити, чи відповідає програмне забезпечення очікуванням і вимогам клієнта.
Отже, V-модель містить фази перевірки з одного боку та етапи перевірки з іншого боку. Процес верифікації та валідації поєднується з фазою кодування у V-подібній формі. Тому вона відома як V-модель.
Існують різні фази фази перевірки V-моделі:
| Аналіз бізнес-вимог: | Це перший крок, на якому вимоги до продукту розуміються з боку клієнта. Ця фаза містить детальне спілкування для розуміння очікувань клієнта та точних вимог.
| Дизайн системи: | На цьому етапі системні інженери аналізують та інтерпретують бізнес запропонованої системи шляхом вивчення документа вимог користувача.
| Архітектурний дизайн: | Основним у виборі архітектури є те, що вона повинна розуміти все, що зазвичай складається зі списку модулів, короткої функціональності кожного модуля, їхніх інтерфейсних зв’язків, залежностей, таблиць бази даних, діаграм архітектури, деталей технології тощо. Модель інтеграційного тестування здійснюється на певній фазі.
| Дизайн модуля: | На етапі проектування модуля система розбивається на невеликі модулі. Уточнюється детальний проект модулів, який відомий як низькорівневий дизайн
| Фаза кодування: | Після проектування починається етап кодування. Виходячи з вимог, вибирається відповідна мова програмування. Існують деякі вказівки та стандарти кодування. Перед реєстрацією в репозиторії остаточна збірка оптимізується для кращої продуктивності, а код проходить багато перевірок коду, щоб перевірити продуктивність.
Існують різні фази фази перевірки V-моделі:
| Модульне тестування: | У V-моделі плани модульного тестування (UTP) розробляються на етапі проектування модуля. Ці UTP виконуються для усунення помилок на рівні коду або на рівні модуля. Блок — це найменша сутність, яка може існувати незалежно, наприклад, програмний модуль. Модульне тестування перевіряє, чи може найменша сутність правильно функціонувати, ізольована від решти кодів/одиниць.
| Тестування інтеграції: | Плани тестування інтеграції розробляються на етапі архітектурного проектування. Ці тести підтверджують, що групи, створені та протестовані незалежно, можуть співіснувати та спілкуватися між собою.
| Тестування системи: | Плани тестування системи розробляються на етапі проектування системи. На відміну від планів тестування модулів і інтеграції, плани тестування системи складаються бізнес-командою клієнта. Тестування системи гарантує, що очікування від розробника програми виправдані.
| Приймальні випробування: | Приймальні випробування пов’язані з частиною аналізу бізнес-вимог. Він включає тестування програмного продукту в атмосфері користувача. Приймальні випробування виявляють проблеми сумісності з різними системами, доступні в атмосфері користувача. Він спільно виявляє нефункціональні проблеми, такі як навантаження та дефекти продуктивності в атмосфері реального користувача.
Коли використовувати V-модель?
- Коли вимога чітко визначена і не є двозначною.
- V-подібну модель слід використовувати для малих і середніх проектів, де вимоги чітко визначені та фіксовані.
- V-подібну модель слід обирати, коли доступні зразки технічних ресурсів із необхідною технічною експертизою.
Переваги (плюси) моделі V:
- Легко зрозуміти.
- Методи тестування, такі як планування, розробка тестів, відбуваються задовго до кодування.
- Це економить багато часу. Отже, вищі шанси на успіх порівняно з моделлю водоспаду.
- Уникає низхідного потоку дефектів.
- Добре працює для невеликих планів, де вимоги легко зрозуміти.
Недоліки (мінуси) V-Model:
- Дуже жорсткий і найменш гнучкий.
- Не підходить для складного проекту.
- Програмне забезпечення розробляється на етапі впровадження, тому ранні прототипи програмного забезпечення не створюються.
- Якщо посередині відбудуться будь-які зміни, необхідно оновити тестові документи разом із необхідними документами.
