XIII. Управління конфігурацією ПЗ і версіями

Управління конфігурацією ПЗ

Метою управління конфігурацією ПЗ (SCM, Software Configuration Management) є планування, організація, контроль і координування всіх дій в розробці ПЗ. Ці дії означають знаходження проблем, зберігання ПЗ і його зміна на всіх етапах розвитку.

Конфігурація важлива для ефективної розробки і подальшого обслуговування ПЗ.

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

Недолік відповідного управління конфігурацією може "підвісити" програму.

Огляд управління конфігурацією ПЗ

Кожен компонент програми повинен унікально ідентифікуватися. Повна її версія повинна бути компактно складена з елементів, які відповідають один одному в логічній формі. Фактична версія компонентів повинна бути розпізнаною, повинна використовуватися відповідна версія документації. Програмні компоненти повинні бути доступні і ніколи не втрачатися (наприклад, через несправність диска або помилки оператора).

Кожна зміна ПЗ повинна бути схвалена і задокументована. Зміни не повинні втрачатися, наприклад, через багато одночасних оновлень. Повинна існувати можливість повернення до попередньої версії.

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

Завдання супервізора в управління конфігурацією ПЗ.

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

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

Виконання управління конфігурації ПЗ

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

Одна з важливих процедур - інтеграція елементів. Будучи об'єднаними із привласненими ним статусами, елементи можуть бути випущені.

 

Малюнок 13.2.1. Управління конфігурацією ПЗ.

 

Найголовніші дії зображені на малюнку 13.2.1.

Елементи конфігурації ПЗ

Елементи конфігурації

Всі елементи проекту і ПЗ повинні розглядатися управлінням конфігурації ПЗ. УКПЗ містить:

· документації вимог, аналізу, проектування, тестування, призначену для користувача документацію і т.д.,

· модулі з початковим кодом, об'єднаним кодом, двійковим кодом,

· інтерфейс користувача,

· файли з текстовими даними (наприклад, повідомлення), словниками і т.п.,

· компілятори, інтерпретації, бібліотеки, протоколи, інструменти CASE, апаратура і т.п.,

· тестування ПЗ і даних,

· www-сервери з відповідними html-сторінками і ПЗ.

Ієрархія конфігурації ПЗ

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

Малюнок 13.3.1. Ієрархія конфігурації елементів.

Базис

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

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

Базиси не змінюються і служать основою для подальших розробок.

Ключові базові елементи - віхи управління проектом. Нові елементи визначаються (додаються) в процесі інтеграції нових компонентів.

Версії, варіанти

Термін "версія" (або варіант) використовується, щоб знайти схожі або майже однакові елементи, які відрізняються тільки в таких аспектах, як:

· кінцева платформа/конфігурація,

· протокол зв'язку, який взаємодіє із зовнішнім ПЗ,

· реалізація діагностування і тестування під час розробки ПЗ.

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

Угода позначень

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

Наприклад, рядок SME/ANA/RD 3.2 означає: проект визначається як SME, пакет (завдання) - як ANA, RD означає документ вимог, 3-а версія, і 2-й перегляд.

Угода повинна:

· визначити назви елементів конфігурації,

· визначити людину, відповідальну за термінологію,

· визначити (якщо можливо) історію елементу.