V-модель – це модель SDLC, де виконання процесів відбувається послідовним чином у V-подібній формі. Вона також відома як модель верифікації та валідації.
V-модель є розширенням моделі водоспаду та базується на асоціації фази тестування для кожної відповідної стадії розробки. Це означає, що для кожної окремої фази циклу розробки існує безпосередньо пов’язана фаза тестування. Це високодисциплінована модель, і наступний етап починається лише після завершення попереднього.
У V-моделі паралельно планується відповідна фаза тестування до фази розробки. Отже, існує певний етап розробки і до цього етапу є фази веріфікації та валідації.
V-модель – етапи
У V-моделі є кілька етапів.
Аналіз бізнес-вимог
Це перша фаза циклу розробки, на якій вимоги до продукту розглядаються з точки зору клієнта. Цей етап передбачає детальне спілкування з клієнтом, щоб зрозуміти його очікування та точні вимоги. Це дуже важлива діяльність, і нею потрібно добре керувати, оскільки більшість клієнтів не впевнені, що саме їм потрібно. На цій стадії здійснюється планування проєкту приймального випробування, оскільки бізнес-вимоги можна використовувати як вхідні дані для приймального тестування (acceptance testing).
Проєктування системи
Коли у вас є чіткі та детальні вимоги до продукту, настав час розробити повну систему. Проєкт системи містить розуміння та деталізацію повного обладнання та налаштування зв’язку для продукту, що розробляється. План тестування системи розробляється на основі проєкту системи. Виконання цього на ранньому етапі залишає більше часу для фактичного виконання тесту пізніше.
Архітектурне проєктування
Архітектурні характеристики розуміються та проектуються на цьому етапі. Зазвичай пропонується більше ніж один технічний підхід, і на основі технічної та фінансової реалістичності виконання проєкту приймається остаточне рішення. Архітектура системи далі розбивається на модулі, які виконують різні функції. Це також називається дизайном високого рівня (High Level Design).
Передача даних і зв’язок між внутрішніми модулями та із зовнішніми системами чітко зрозумілі та визначені на цьому етапі. З цією інформацією можна розробити та задокументувати інтеграційні тести.
Проєктування модуля
На цьому етапі вказується детальна внутрішня конструкція для всіх системних модулів, що називається низькорівневим дизайном (Low Level Design) . Важливо, щоб дизайн був сумісний з іншими модулями архітектури системи та іншими зовнішніми системами. Модульні тести є важливою частиною будь-якого процесу розробки та допомагають усунути максимальну кількість недоліків і помилок на дуже ранній стадії. Ці модульні тести можуть бути розроблені на цьому етапі на основі дизайну внутрішнього модуля.
Фаза кодування
Фактичне кодування системних модулів, розроблених на етапі проєктування, виконується на етапі кодування. Найкраща підходяща мова програмування вибирається на основі системних і архітектурних вимог. Кодування здійснюється на основі інструкцій і стандартів кодування. Код проходить численні перевірки та оптимізується для найкращої продуктивності перед тим, як остаточна збірка буде перевірена в репозиторії.
Модульне тестування
Модульні тести, розробляються на етапі проєктування модуля. Модульне тестування – це тестування на рівні коду, яке допомагає усунути помилки на ранній стадії, хоча модульне тестування не може виявити всі дефекти.
Інтеграційне тестування
Інтеграційне тестування пов’язане з етапом архітектурного проєктування. Інтеграційні тести виконуються для перевірки співіснування та зв’язку внутрішніх модулів у системі.
Тестування системи
Тестування системи безпосередньо пов’язане з етапом проєктування системи. Системні тести перевіряють всю функціональність системи та зв’язок системи, що розробляється, із зовнішніми системами. Більшість проблем із сумісністю програмного та апаратного забезпечення можна виявити під час виконання цих тестів.
Приймальне тестування
Приймальне тестування пов’язане з фазою аналізу бізнес-вимог і включають тестування продукту в середовищі користувача. Приймальні тести виявляють проблеми сумісності з іншими системами, доступними в середовищі користувача. Вони також виявляють нефункціональні проблеми, такі як дефекти навантаження та продуктивності в реальному середовищі користувача.
V-Модель – Застосування
Застосування моделі V майже таке ж, як і моделі водоспаду, оскільки обидві моделі мають лінійний тип. Вимоги мають бути дуже чіткими перед початком проєкту, оскільки повертатися назад і вносити зміни зазвичай дорого. Ця модель використовується в галузі медичних розробок, оскільки це суворо дисциплінована область.
Наступні умови є одними з найбільш поширених сценаріїв для використання V-моделі:
- Вимоги чітко визначені, чітко задокументовані та фіксовані.
- Визначення продукту стабільне.
- Технологія не є динамічною і добре зрозуміла команді проєкту. Немає двозначних або невизначених вимог.
V-модель – переваги
Перевага методу V-моделі полягає в тому, що його дуже легко зрозуміти та застосувати. Простота цієї моделі також полегшує керування.
Переваги V-моделі:
- Це високодисциплінована модель, і фази завершуються по черзі.
- Добре працює для проєктів, де вимоги визначені та добре зрозумілі.
- Простий і легкий для розуміння та використання.
- Легко керувати завдяки жорсткості моделі. Кожен етап має конкретні результати та процес перевірки.
V-модель – недоліки
Недоліком є те, що модель не гнучка до змін. У випадку зміни вимоги, що дуже часто зустрічається в сучасному динамічному світі, внесення змін стає дуже дорогим.
Недоліки методу V-моделі наступні:
- Високий ризик і невизначеність.
- Не підходить для проєктів, де вимоги мають помірний або високий ризик зміни.
- Коли програма знаходиться на стадії тестування, важко повернутися назад і змінити функціональність.