V-Model

Концепція V-подібної моделі була розроблена Німеччиною та США в кінці 1980-х років незалежно один від одного:

• Німецька V-модель була розроблена аерокосмічної компанією IABG в Оттобрунні поряд з Мюнхеном у сприянні з Федеральним департаментом з закупівлі озброєнь в Кобленці, для Міністерства оборони Німеччини. Модель була прийнята німецькою федеральною адміністрацією для цивільних потреб влітку 1992.[1]
• Американська V-Model (VEE) була розроблена національною радою з системної інженерії (міжнародна — з 1995 року) для супутникових систем, включаючи обладнання, програмне забезпечення та взаємодію з користувачами.[2]

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

V-Model процесу розробки ІС.[3]

Основний принцип 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]