| Цикл розробки програмного забезпечення |
|---|
 Програміст за роботою |
| Діяльність і кроки |
| Допоміжні дисципліни |
| Практики |
| Інструменти |
| Стандарти та галузі знань |
V-Model (або VEE модель) є моделлю розробки інформаційних систем (ІС), спрямованої на спрощення розуміння складнощів, пов'язаних з розробкою систем. Вона використовується для визначення єдиної процедури розробки програмного забезпечення, апаратного забезпечення та людино-машинного інтерфейсу.
Концепція V-подібної моделі була розроблена Німеччиною та США в кінці 1980-х років незалежно один від одного:
- Німецька V-модель була розроблена аерокосмічної компанією IABG в Оттобрунні поряд з Мюнхеном у сприянні з Федеральним департаментом з закупівлі озброєнь в Кобленці, для Міністерства оборони Німеччини. Модель була прийнята німецькою федеральною адміністрацією для цивільних потреб влітку 1992.[1]
- Американська V-Model (VEE) була розроблена національною радою з системної інженерії (міжнародна — з 1995 року) для супутникових систем, включаючи обладнання, програмне забезпечення та взаємодію з користувачами.[2]
Сучасною версією V-Model є V-Model XT, яка була затверджена в лютому 2005 року. V-модель використовується для управління процесом розробки програмного забезпечення для німецької федеральної адміністрації. Зараз вона є стандартом для німецьких урядових і оборонних проєктів, а також для виробників ПЗ в Німеччині. V-Model являє собою скоріше набір стандартів у галузі проєктів, що стосуються розробки нових продуктів. Ця модель багато в чому схожа з Prince2 і описує методи як для проєктного управління, так і для системного розвитку.
Основний принцип V-подібної моделі полягає в тому, що деталізація проєкту зростає при русі зліва направо, одночасно з плином часу, і ні те, ні інше не може повернути назад. Ітерації в проєкті виробляються по горизонталі, між лівою і правою сторонами літери.
Стосовно до розробки інформаційних систем V-Model — варіація каскадної моделі, в якій завдання розробки йдуть зверху вниз по лівій стороні букви V, а завдання тестування — вгору по правій стороні букви V. Усередині V проводяться горизонтальні лінії, що показують, як результати кожної з фаз розробки впливають на розвиток системи тестування на кожній із фаз тестування. Модель базується на тому, що приймально-здавальні випробування ґрунтуються, насамперед, на вимогах, системне тестування — на вимогах та архітектури, комплексне тестування — на вимогах, архітектурі та інтерфейсах, а компонентне тестування — на вимогах, архітектурі, інтерфейсах та алгоритмах.[4]
V-модель забезпечує підтримку у плануванні та реалізації проєкту. В ході проєкту ставляться такі завдання:
- Мінімізація ризиків: V-подібна модель робить проєкт більш прозорим і підвищує якість контролю проєкту шляхом стандартизації проміжних цілей і опису відповідних їм результатів та відповідальних осіб. Це дозволяє виявляти відхилення в проєкті і ризики на ранніх стадіях і покращує якість управління проєктом.
- Підвищення та гарантії якості: V-Model — стандартизована модель розробки, що дозволяє домогтися від проєкту результатів бажаної якості. Проміжні результати можуть бути перевірені на ранніх стадіях. Універсальне документування полегшує читаність, зрозумілість та контрольованість.
- Зменшення загальної вартості проєкту: Ресурси на розробку, виробництво, управління і підтримку можуть бути заздалегідь прораховані та проконтрольовані. Отримувані результати також універсальні і легко прогнозуються. Це зменшує витрати на подальші стадії та проєкти.
- Підвищення якості комунікації між учасниками проєкту: Універсальний опис усіх елементів та умов полегшує взаєморозуміння всіх учасників проєкту. Таким чином, зменшуються неточності у розумінні між користувачем, покупцем, постачальником і розробником.[5]
- Користувачі V-Model беруть участь у розробці та підтримці V-моделі. Комітет з контролю за змінами підтримує проєкт і збирається раз на рік для обробки всіх отриманих запитів на внесення змін до V-Model.[6]
- На старті будь-якого проєкту V-подібна модель може бути адаптована під цей проєкт, так як ця модель не залежить від типів організацій та проєктів.[7]
- V-model дозволяє розбити діяльність на окремі кроки, кожен з яких буде включати в себе необхідні для нього дії, інструкції до них, рекомендації та докладне пояснення діяльності.[8]
Наступні моменти не враховуються в V-моделі, але можуть бути розглянуті окремо, або можливо адаптувати модель під них:
- Не регулюється розміщення контрактів на обслуговування.
- Організація і виконання управління, обслуговування, ремонту та утилізації системи не враховуються в V-моделі. Однак, планування і підготовка до цих операцій моделлю розглядаються.
- V-подібна модель більше стосується розробки програмного забезпечення в проєкті, ніж всієї організації процесу.[9]
- У моделі особливе значення надається плануванню, спрямованому на верифікацію та атестацію розроблювального продукту на ранніх стадіях його розробки. Фаза модульного тестування підтверджує правильність деталізованого проєктування. Фази інтеграції та тестування реалізують архітектурне проєктування або проєктування на вищому рівні. Фаза тестування системи підтверджує правильність виконання етапу вимог до продукту і його специфікації.[10]
- У моделі передбачені атестація та верифікація всіх зовнішніх і внутрішніх отриманих даних, а не тільки самого програмного продукту.[10][11][12]
- У V-подібної моделі визначення вимог виконується перед розробкою проєкту системи, а проєктування ПО — перед розробкою компонентів.[10]
- Модель визначає продукти, які повинні бути отримані в результаті процесу розробки, причому кожні отримані дані повинні піддаватися тестуванню.[10][12]
- Завдяки моделі менеджери проєкту можуть відслідковувати хід процесу розробки, так як в даному випадку цілком можливо скористатися тимчасовою шкалою, а завершення кожної фази є контрольною точкою.[10][12]
- Модель не передбачає роботу з паралельними подіями.[10]
- У моделі не передбачено внесення вимоги динамічних змін на різних етапах життєвого циклу.[10][11][13]
- Тестування вимог в життєвому циклі відбувається занадто пізно, внаслідок чого неможливо внести змін, не вплинувши при цьому на графік виконання проєкту.[10][11]
- У модель не входять дії, спрямовані на аналіз ризиків.[10]
- Деякий результат можна отримати тільки при досягненні низу букви V.[14]
- Водоспадна модель
- Dual Vee Model[ru]
- Модель хаосу[en]
- ↑ V-Model — lyfecycle process model [Архівовано 3 березня 2016 у Wayback Machine.](англ.)
- ↑ Forsberg, K. and Mooz, H., «The Relationship of Systems Engineering to the Project Cycle», Перший щорічний симпозіум національної ради з системної інженерії, жовтень 1991 (англ.)
- ↑ Clarus Concept of Operations. [Архівовано 12 вересня 2014 у Wayback Machine.] Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005 (англ.)
- ↑ Economicus: серія словників з економіки, фінансів та менеджменту[недоступне посилання з лютого 2019](рос.)
- ↑ Objectives of the V-Model [Архівовано 20 квітня 2011 у Wayback Machine.](англ.)
- ↑ Further Development of the V-Model [Архівовано 23 квітня 2011 у Wayback Machine.](англ.)
- ↑ Management Mechanisms of the V-Model — Tailoring [Архівовано 19 липня 2011 у Wayback Machine.](англ.)
- ↑ Overview of the Activity Model of the V-Model [Архівовано 19 липня 2011 у Wayback Machine.](англ.)
- ↑ Limits of the V-model [Архівовано 21 травня 2011 у Wayback Machine.](англ.)
- ↑ а б в г д е ж и к Огляд моделей життєвого циклу розробки програмного забезпечення [Архівовано 15 червня 2016 у Wayback Machine.](рос.)
- ↑ а б в Testing Excellence — V-Model [Архівовано 25 червня 2011 у Wayback Machine.](англ.)
- ↑ а б в Sameeradilhan — Advantages and disadvantages of Waterfall Model and V-Model [Архівовано 29 серпня 2012 у Wayback Machine.](англ.)
- ↑ TestManagement — Advantages and Disadvantages of V-Model [Архівовано 20 червня 2015 у Wayback Machine.](англ.)
- ↑ V-Model [Архівовано 20 червня 2015 у Wayback Machine.]: Expert Program Management(англ.)
| |||||||||||||||||||||||