4. Зберігання елементів конфігурації

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

Система повинна реєструвати і зберігати всі адміністраторські документи, що мають відношення до проекту, наприклад, проміжні і фінальні звіти, запити, звіти тестування і т.д.

Адміністраторські документи повинні бути інтегровані з елементами конфігурації так, щоб можна було легко простежити за зв'язком причини-наслідку в системі.

Існують наступні види конфігураційних бібліотек:

• бібліотека поточного процесу розробки,

• бібліотека базових продуктів,

• архіви.

• бібліотеки/репозиторії конфігураційних елементів

Добре організована бібліотека є базою для УКПЗ. Вона повинна значно полегшувати пошук, читання, вставку, заміну і видалення.

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

Всі інтерфейси компонентів повинні бути помічені в наступній чурзі:

• назва проекту,

• ідентифікатор конфігураційного елементу,

• дата і час запису даних в репозиторій,

• короткий опис або характеристика.

Контроль зміни конфігурації

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

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

Зміни повинні бути перевірені перед внесенням інших змін. Зміни повинні документуватися, наприклад, в бланк змін.

Опис статусу конфігурації

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

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

Таблиця - документ статусу конфігурації. Туди можна ввести і інші бланки запису статусів, якщо вони легкі для розуміння і внесення змін.

Статус конфігурації повинен оновлюватися і бути завжди доступним для команди проекту. Якщо програма не працює, але працювала зв день до цього, буде висунутим питанням: "Що змінилося?"

SPMP - план управління проекту розробки ПЗ Software Project Management Plan SCMP - план управління конфігурації ПЗ, Software Configuration Management Plan SVVP – план перевірки і затвердження ПЗ, Software Verification and Validation Plan SQAP - план перевірки гарантії якості ПЗ, Software Quality Assurance Plan URD - документ користувацьких вимог, User Requirements Document SRD - документ вимог ПЗ, Software Requirement Document ADD - документ аналізу-розробки, Analysis-Design Document DPD - докладний документ проекту, Детальний документ проекту SID - документ установки ПЗ, Software Installation Document