База знань

V- модель (V-Model)

v-model

Концепція V-подібної моделі була розроблена Німеччиною і США в кінці 1980-х років. Була запропонована саме для того, щоб усунути недоліки каскадної моделі, а назва – V-подібна або шарнірна – з’явилася через її специфічне графічне подання.

Основний принцип

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

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

Однак в цілому V-подібна модель є всього лише модифікацією каскадної і володіє багатьма її недоліками. Зокрема, і та, і інша слабо пристосовані до можливих змін вимог замовника. Якщо процес розробки займає тривалий час (іноді до декількох років), то отриманий в результаті продукт може виявитися фактично непотрібним замовникові, оскільки його потреби істотно змінилися. У тій же мірі актуальне і питання впливу науково-технічного прогресу: вимоги до ПЗ висуваються з урахуванням поточного стану наукових і практичних досягнень в області апаратно-програмного забезпечення, однак IТ-сфера розвивається дуже швидко, і тривалий процес розробки здатний привести до створення продукту, який базується на застарілих технологіях і виявляється неконкурентоспроможним ще до своєї появи.

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

В результаті замовник буде змушений або миритися з обмеженнями створеного на основі розглянутих моделей рішення, або додатково інвестувати кошти, щоб отримати дійсно те, що необхідно.

Фази тестування:

  • Компонентне тестування (Component testing) 
  • Тестування окремих компонентів (Unit testing) – перевіряє роботу компонентів системи (модулі, програми, об’єкти, класи, які тестуються незалежно один від одного).
  • Інтеграційне тестування (Integration testing) – тестує інтерфейс між компонентами, взаємодію з різними частинами системи такими як операційна система, файлова система, «залізо»
  • Системне тестування (System testing) – тестування всієї системи / продукту, як зазначено в проекті розробки ПЗ. Головне завдання системного тестування – перевірка по відношенню до вимог.
  • Приймальне тестування (Acceptance testing ) – тестування готового продукту кінцевими користувачами в реальному оточенні

Переваги:

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

Недоліки:

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

Коли використовувати V-модель:

  • в проектах, в яких існують часові та фінансові обмеження;
  • для завдань, які передбачають більш широке, в порівнянні з каскадної моделлю, тестове покриття.

Набагато більше інформації на курсі базовий модуль тестування