Формування версій й контроль конфігурації

Версія системи містить у собі елементи конфігурації й варіант версії системи для передачі замовнику. Керування версіями полягає у виконанні дій:

• — інтеграція або композиція коректної й остаточної версії системи з елементів конфігурації, які реалізовані на процесах ЖЦ. Функціонування коду системи залежить від апаратних засобів й інструментів, за допомогою яких будувалася система;
• — вибору інструментарію побудови версії, оцінки можливостей середовища й засобів автоматизації процесу побудови окремих версій з коректною конфігурацією ПС і даних;
• — керування варіантами версій із сукупності готових ідентифікованих елементів системи, що задовольняють заданим вимогам замовника.

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

Яскравим прикладом формування 21 версії на ОС 360 (1965;1980 р.) є фірма ІВМ. В ОС постійно й поетапно додавалися нові функціональні можливості й вносилися зміни до попередньої версії при її експлуатації. Над розвитком додаткових можливостей даної ОС і внесення змін у попередню версію постійно працював колектив фірми. Трудомісткість розробки чергової версії ОС вважалася пропорційною інтервалу часу між реєстраціями чергових версій і приймалася за одиницю виміру складності створення нової версії.

Як міру трудомісткості супроводу й створення чергової версії було використано число модулів (обмежених розмірів зі стандартизованим описом), що піддаються змінам і доповненням. Крім того, оцінювалася інтенсивність робіт над створенням версії, що вимірялася числом змінених модулів в одиницю часу. Після 12 років постійних змін в ОС 21 версія працювала стабільніше, до неї майже не вносилося змін, оскільки претензій з боку користувачів в основному не надходило.

Метричний аналіз процесу розвитку ОС 360 дозволив встановити, що обсяг середнього приросту системи на кожну версію відповідав приблизно 200 модулям. При цьому загальний обсяг збільшився від 1 тис. модулів у перших версіях до 5 тис. модулів в останніх версіях. Коли рівень приросту складності був великим, для усунення помилок або додаткових коректувань іноді створювалися проміжні версії з меншим числом змін.

Як результат з’явилося поняття «критичної маси» або критичної складності системи, що модифікується. Якщо при модернізації й випуску чергової версії системи обсяг доробок перевищує «критичний», то зростає ймовірність погіршення характеристик або необхідність введення проміжної версії із внесенням деяких змін. «Критичний» обсяг доробок ОС-360 близько 200 модулів залишався постійним, незважаючи на підвищення кваліфікації колективу, удосконалення технічних і програмних засобів тощо. У перших версіях обсяг доробок становив 20% модулів, а в останніх версіях знизився до 5%.

Контроль конфігурації — це перевірка її правильності і випробування розгортки конфігурації в процесі експлуатації системи. Він містить у собі безперервні коректування, які стосуються вже погодженого й/або затвердженого конфігураційного базису. Це обумовлює такі об'єкти контролю:

• — зміни в затвердженому базисі і пов’язані з ними коректування елементів конфігурації;
• — дефекти й відхилення в конфігурації продукту з затвердженого базису.

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

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

• — Реєстрація пропозиції /запиту на зміну.
• — Аналіз впливу запропонованої зміни на наявний заділ, обсяг, трудомісткість, графік і вартість робіт з проекту.
• — Прийняття рішення з виконання цього запиту (наприклад, задовольнити, відмовити або відкласти).
• — Реалізація затвердженої зміни і її верифікація.

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

• — реєстрація інформації про отриманий дефект /відхилення;
• — аналіз та діагностика місця й причини дефекту /відхилення, оцінка обсягу, трудомісткості, строків і вартості переробок;
• — прийняття рішення з усунення дефекту/відхилення, реалізація й верифікація цих недоліків.

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

Найзручнішою формою реалізації такого рішення є рада керівників з контролю конфігурації CCB (Configuration Control Board), як родоначальника теорії й практики керування конфігурацією.