V-модель є різновидом Модель SDLC де процес виконується послідовно у V-подібній формі. Вона також відома як модель верифікації та перевірки. Він заснований на асоціації фази тестування для кожної відповідної стадії розробки. Розробка кожного кроку безпосередньо пов'язана з фазою тестування. Наступна фаза починається лише після завершення попередньої фази, тобто для кожної дії розробки існує відповідна їй діяльність тестування.

Зміст

• Дизайн V-моделі
• Важливість V-моделі
• Принципи V-моделі
• Коли використовувати V-модель?
• Переваги моделі V
• Недоліки V-Model
• Висновок

V-модель — це модель життєвого циклу розробки програмного забезпечення (SDLC), яка забезпечує систематичне та візуальне представлення процесу розробки програмного забезпечення. Він заснований на ідеї V-подібної форми, причому два кінці V представляють прогресію процес розробки програмного забезпечення від збір вимог і аналіз для проектування, впровадження, тестування та обслуговування.

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

1. Збір і аналіз вимог : Перший етап V-Model — це етап збору та аналізу вимог, на якому збираються та аналізуються вимоги замовника до програмного забезпечення для визначення обсягу проекту.
2. Дизайн: На етапі проектування розробляються архітектура та дизайн програмного забезпечення, включаючи проект високого рівня та детальний проект.
3. Реалізація: На етапі впровадження програмне забезпечення будується на основі дизайну.
4. Тестування: На етапі тестування програмне забезпечення перевіряється на відповідність вимогам клієнта та високу якість.
5. Розгортання: На етапі розгортання програмне забезпечення розгортається та вводиться в експлуатацію.
6. Технічне обслуговування: На етапі обслуговування програмне забезпечення підтримується, щоб гарантувати, що воно продовжує відповідати потребам і очікуванням клієнта.
7. V-модель часто використовується в безпеці: критично важливих систем, таких як аерокосмічні та оборонні системи, через його наголос на ретельному тестуванні та здатність чітко визначати етапи процесу розробки програмного забезпечення.

SDLC V-Model

На наступній ілюстрації зображені різні фази V-моделі SDLC.

Перевірка Фази :

Він включає в себе техніку статичного аналізу (перегляду), виконану без виконання коду. Це процес оцінки фази розробки продукту, щоб визначити, чи задовольняються визначені вимоги.

У V-моделі є кілька етапів перевірки:

Аналіз бізнес-вимог:

Це перший крок позначення циклу розробки, де вимоги до продукту потрібно виправити з точки зору замовника. на цих етапах належне спілкування з клієнтом, щоб зрозуміти вимоги клієнтів. це дуже важливі дії, якими потрібно займатися належним чином, оскільки більшість часу клієнти не знають точно, чого вони хочуть, і вони не впевнені в цьому, тоді ми використовуємо проект приймального випробування планування, яке виконується під час бізнес-вимоги, воно використовуватиметься як введення для приймальних випробувань.

Дизайн системи:

Розробка системи почнеться, коли ми в цілому зрозуміємо вимоги до продукту, а потім буде потрібно повністю спроектувати систему. Це розуміння буде на початку повного процесу розробки продукту. це буде корисно для майбутнього виконання тестів.

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

На цьому етапі осмислюються та проектуються архітектурні характеристики. Зазвичай пропонується кілька технічних підходів, і остаточний вибір робиться після розгляду як технічної, так і фінансової життєздатності. Архітектура системи далі розділена на модулі, кожен з яких виконує окрему функцію. Інша назва цього - дизайн високого рівня (HLD).

рядок для int у java

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

Дизайн модуля:

Цей етап, відомий як низькорівневе проектування (LLD), визначає комплексний внутрішній дизайн для кожного системного модуля. Сумісність між дизайном та іншими зовнішніми системами, а також іншими модулями в системній архітектурі має вирішальне значення. Модульні тести є ключовим компонентом будь-якого процесу розробки, оскільки вони допомагають виявити та викорінити більшість помилок і недоліків на ранній стадії. На основі дизайну внутрішнього модуля тепер можна створювати ці модульні тести.

Фаза кодування:

Етап кодування включає написання коду для системних модулів, які були створені на етапі проектування. Вимоги до системи та архітектури використовуються для визначення того, яка мова програмування є найбільш прийнятною.

При виконанні кодування дотримуються стандартів і принципів кодування. Перед тим, як остаточну збірку буде перевірено в сховищі, код проходить багато перевірок і оптимізується для оптимальної продуктивності.

Перевірка Фази :

Він включає в себе методи динамічного аналізу (функціонального та нефункціонального) і тестування, виконане шляхом виконання коду. Перевірка — це процес оцінювання програмного забезпечення після завершення етапу розробки, щоб визначити, чи відповідає програмне забезпечення очікуванням і вимогам клієнта.

Отже, V-модель містить фази перевірки з одного боку та етапи перевірки з іншого боку. Фази верифікації та валідації об’єднані фазою кодування у V-подібній формі. Тому вона називається V-модель.
Є декілька Перевірка фази в V-моделі:

Модульне тестування:

Плани модульного тестування розробляються на етапі проектування модуля. Ці плани модульного тестування виконуються для усунення помилок у коді або на рівні модуля.

Інтеграційне тестування:

Після завершення модульного тестування виконується інтеграційне тестування. Під час інтеграційного тестування модулі інтегруються, а система тестується. Тестування інтеграції виконується на етапі проектування архітектури. Цей тест перевіряє взаємодію модулів між собою.

Тестування системи:

Системне тестування перевіряє повну програму з її функціональністю, взаємозалежністю та зв’язком. Він перевіряє функціональні та нефункціональні вимоги розробленої програми.

Прийнятне тестування користувача (UAT):

UAT виконується в середовищі користувача, яке нагадує виробниче середовище. UAT перевіряє, чи поставлена ​​система відповідає вимогам користувача та чи система готова до використання в реальному світі.

Фаза проектування:

• Аналіз вимог: Ця фаза містить детальне спілкування з клієнтом, щоб зрозуміти його вимоги та очікування. Цей етап відомий як збір вимог.
• Дизайн системи: Цей етап містить проектування системи та повне налаштування апаратного забезпечення та зв’язку для розробки продукту.
• Архітектурний дизайн: Дизайн системи розбивається на модулі, які виконують різні функції. Передача даних і зв’язок між внутрішніми модулями та із зовнішнім світом (іншими системами) чітко зрозумілі.
• Дизайн модуля: На цьому етапі система розбивається на невеликі модулі. Уточнюється детальний проект модулів, також відомий як низькорівневий дизайн (LLD).

Етапи тестування:

• Модульне тестування: Плани модульного тестування розробляються на етапі проектування модуля. Ці плани модульного тестування виконуються для усунення помилок на рівні коду або модуля.
• Інтеграційне тестування: Після завершення модульного тестування виконується інтеграційне тестування. Під час інтеграційного тестування модулі інтегруються, а система тестується. Тестування інтеграції виконується на етапі проектування архітектури. Цей тест перевіряє взаємодію модулів між собою.
• Тестування системи: Системне тестування перевіряє повну програму з її функціональністю, взаємозалежністю та зв’язком. Він перевіряє функціональні та нефункціональні вимоги розробленої програми.
• Прийнятне тестування користувача (UAT): UAT виконується в середовищі користувача, яке нагадує виробниче середовище. UAT перевіряє, чи поставлена ​​система відповідає вимогам користувача та чи система готова до використання в реальному світі.

Індустріальний виклик:

Оскільки галузь розвивалася, технології ставали складнішими, швидшими та постійно змінювалися, однак залишається набір основних принципів і концепцій, які так само застосовні сьогодні, як і тоді, коли ІТ були в зародковому стані.

• Точне визначення та уточнення вимог користувача.
• Розробка та створення програми відповідно до вимог авторизованого користувача.
• Підтвердити, що програма, яку вони створили, відповідає дозволеним бізнес-вимогам.

Важливість V-моделі

1. Рання ідентифікація дефекту

Включаючи завдання верифікації та підтвердження на кожному етапі процесу розробки, V-модель заохочує раннє тестування. Це знижує витрати та зусилля, необхідні для усунення проблем на пізніх етапах життєвого циклу розробки, допомагаючи ранньому виявленню та вирішенню несправностей.

2. визначення етапів розробки та тестування

V-модель містить фазу тестування, яка відповідає кожному етапу процесу розробки. Забезпечуючи чітке відображення процесів тестування та розробки, це чітке відображення сприяє методичному та впорядкованому підходу до розробки програмного забезпечення.

3. Запобігає тесту Big Bang

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

4. Покращує співпрацю

На кожному рівні V-модель сприяє співпраці між командами тестування та розробки. Завдяки цій співпраці краще розуміються вимоги до проекту, вибір дизайну та методології тестування, що покращує результативність і ефективність процесу розробки.

5. Покращене забезпечення якості

Загальну гарантію якості посилює V-модель, яка включає операції тестування на кожному рівні. Перш ніж програма досягне фінального етапу розгортання, вона перевіряє, чи відповідає вимогам, і проходить суворий процес перевірки та перевірки.

Принципи V-моделі

• Від великого до малого: У V-моделі тестування виконується в ієрархічній перспективі, наприклад, вимоги, визначені командою проекту, створюючи етапи проектування високого рівня та детального проектування проекту. По мірі завершення кожної з цих фаз вимоги, які вони визначають, стають все більш уточненими та деталізованими.
• Цілісність даних/процесу: Цей принцип стверджує, що успішна розробка будь-якого проекту вимагає об’єднання та узгодженості як даних, так і процесів. Елементи процесу повинні бути визначені для кожної вимоги.
• Масштабованість: Цей принцип стверджує, що концепція V-Model має гнучкість для будь-якого ІТ-проекту, незалежно від його розміру, складності чи тривалості.
• Перехресні посилання: Пряма кореляція між вимогами та відповідною діяльністю тестування відома як перехресне посилання.

Реальна документація:

Цей принцип стверджує, що кожен проект потребує створення документа. Ця документація є обов’язковою та застосовується як командою розробки проекту, так і командою підтримки. Документація використовується для підтримки програми, коли вона стає доступною у робочому середовищі.

Чому перевага?

скільки мб в гб

• Легко керувати завдяки жорсткості моделі. Кожен етап V-Model має конкретні результати та процес перевірки.
• Проактивне відстеження дефектів – тобто дефекти виявляються на ранній стадії.

Коли використовувати з V-Model ?

• Відстеження вимог: V-модель виявляється корисною в ситуаціях, коли необхідно створити точну відстежуваність між вимогами та відповідними тестовими випадками.
• Комплексні проекти: V-модель пропонує методичний спосіб керування діяльністю з тестування та зниження ризиків, пов’язаних із проблемами інтеграції та інтерфейсу для проектів із високим рівнем складності та взаємозалежністю між компонентами системи.
• Водоспадні проекти : Оскільки V-модель пропонує доступну структуру для організації, проведення та моніторингу тестування на кожному рівні розробки, вона підходить для проектів, які використовують послідовний підхід до розробки, подібно до моделі водоспаду.
• Критичні для безпеки системи: Ці системи використовуються в аерокосмічній, автомобільній та медичній промисловості. Вони приділяють особливу увагу жорстким процедурам верифікації та підтвердження, які допомагають гарантувати виконання основних системних вимог і виявлення й усунення можливих ризиків на ранніх стадіях процесу розробки.

Переваги моделі V

• Це високодисциплінована модель, і фази завершуються по черзі.
• V-Model використовується для невеликих проектів, де чіткі вимоги до проекту.
• Простий і легкий для розуміння та використання.
• Ця модель зосереджена на верифікації та валідації на ранніх стадіях життєвого циклу, тим самим підвищуючи ймовірність створення якісного продукту без помилок.
• Це дає змогу керівництву проекту точно відстежувати прогрес.
• Чіткий і структурований процес: V-модель забезпечує чіткий і структурований процес для розробка програмного забезпечення , що полегшує розуміння та дотримання.
• Акцент на тестуванні: V-модель робить сильний акцент на тестуванні, яке допомагає забезпечити якість і надійність програмного забезпечення.
• Покращена відстежуваність: V-модель забезпечує чіткий зв’язок між вимогами та кінцевим продуктом, полегшуючи відстеження та керування змінами програмного забезпечення.
• Краща комунікація: чітка структура V-моделі допомагає покращити комунікацію між клієнтом і командою розробників.

Недоліки V-Model

• Високий ризик і невизначеність.
• Це не підходить для складних і об'єктно-орієнтованих проектів.
• Він не підходить для проектів, де вимоги незрозумілі та містять високий ризик зміни.
• Ця модель не підтримує повторення фаз.
• Він нелегко обробляє одночасні події.
• Негнучкість: V-модель — це лінійна та послідовна модель, що може ускладнити адаптацію до мінливих вимог або несподіваних подій.
• Забирає багато часу: V-модель може забрати багато часу, оскільки вимагає багато документації та тестування.
• Надмірна залежність від документації: V-модель робить сильний акцент на документації, що може призвести до надмірної залежності від документації за рахунок фактичної роботи з розробки.

Висновок

Науковий та організований підхід до життєвого циклу розробки програмного забезпечення (SDLC) забезпечує V-модель розробки програмного забезпечення. Під час вибору будь-яких моделей SDLC, включаючи V-модель, слід враховувати досвід команди щодо обраної методології, унікальні особливості проекту та характер вимог.

Довідник:

Розробка програмного забезпечення: Підхід практикуючого Роджера С. Прессмана, опубліковано McGraw-Hill Education, 2017.