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

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

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

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

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

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

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

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

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

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

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

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

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

Базис

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Визначення конфігурації елементу

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

Конфігураційні елементи можуть містити інші елементи конфігурації системи. Ідентифікатори не міняються.

Внизу малі елементи ідентифікуються, наприклад: документи аналізу і проектування, початковий код і кінцеві кодові модулі (файли, заголовки і т.д.). Вони розглядаються як одне ціле, наприклад, компілятором.

Конфігураційні елементи представляють проектну декомпозицію в завданнях.

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

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

Ідентифікатор повинен враховувати вид елементу. Трьома основними типами інтерфейсу компонентів є:

• початковий інтерфейс компонентів (наприклад, текст програми),

• вихідний інтерфейс компонентів (наприклад, двійковий код),

• інструмент для генерування вихідного елементу.

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

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

Відповідальність за конфігураційне число

Кожне конфігураційне число повинне мати не менше трьох рівнів відповідальності:

• відповідальність програміста,

• відповідальність менеджера по проектах,

• відповідальність органу контролю-перевірки.

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

Менеджер по проектах несе відповідальність за об'єднання елементів нижчого рівня в елементи більш вищого рівня. Елементи нижчго рівня зберігаються в репозиторії. За документування інтерфейсу компонентів вищого рівня відповідальність несе менеджер по проектах. Архів теж повинен містити інформацію щодо вищого рівня інтерфейсу компонентів.

Для більших проектів використовується бібліотекар.

Орган контролю-перевірки затверджує базиси і внесені до них зміни. У нього повинні входити: менеджер по проектах, представники клієнта, представник правління компанії, бібліотекар і представник оцінки якості.