3.2. Контроль конфігурації
3.2.1. Запит на зміни
Як визначено в SPMP (глава 2), команда призначає інспектора для кожного учасника команди. Перш ніж зробити запит на зміну, розробник зобов'язаний отримати схвалення даної пропозиції по зміні від інспектує команди або, якщо останнє неможливе, від свого інспектора. Щоб зробити запит на зміну, необхідно надати форму http://www.ultracorp.division3. Encounter.submitCI ведучому конфігурацію і лідеру проекту разом з вихідним CI і зміненим CI.
3.2.2. Оцінка змін
Лідер проекту або його заступник оцінюють всі запити на зміни. Лідер проекту повинен також вказати стандарти якості, які необхідно врахувати при внесенні зміни.
3.2.3. Схвалення або несхвалення змін
Запит на зміну повинен бути схвалений лідером проекту. Якщо лідер проекту не має можливості це зробити протягом трьох робочих днів, то право схвалення запиту на зміну переходить до ведучого конфігурацію.
3.2.4. Реалізація змін
Як тільки CI включається в конфігурацію, на провідного конфігурацію відповідальність за тестування та інтеграцію змін. Це повинно виконуватися відповідно до правил регресійного тестування, описаного в документації з тестування програмного забезпечення (STD). Зокрема, провідний конфігурацію повинен координувати збірку версії для тестування.
Випуск версій повинен затверджуватися лідером проекту або керівником проекту, якщо лідер відсутня.
3.3. Визначення статусу конфігурації
Ведучий конфігурацію зобов'язаний оновлювати інформацію про конфігурацію на сайті http://www.ultracorp.division3/Encounter/Configuration не рідше разу на тиждень. Для цього достатньо опублікувати підсумковий звіт інструменту SuperCMTool.
3.4. Аудити та огляди конфігурації
Керівник проекту повинен запланувати виконання оглядів конфігурації провідним конфігурацію не рідше, ніж раз на два тижні, зазвичай в якості одного з пунктів порядку денного щотижневих зборів команди. Ведучий конфігурацію повинен зробити огляд стану конфігурації і запропонувати детальні процедури управління конфігураціями на фазах кодування та інтеграції.
Питання управління конфігураціями повинні бути предметом випадковим чином призначаються зовнішніх аудитів.
3.5. Управління інтерфейсом
Система управління конфігураціями повинна мати інтерфейс з веб-сайтом проекту. Цим інтерфейсом керує провідний конфігурацію.
3.6. Контроль постачальників та субпідрядників
Ведучий конфігурацію повинен відслідковувати оновлення і повідомлення про помилках в інструменті SuperСМТооl. У нього повинен бути план дій на випадок, якщо підтримка 5ірегСМТоо1 буде припинена. Цей план повинен бути представлю лідеру проекту протягом місяця після початку проекту.
Розклад
План-графік заходів по звітам, архівації та оновленню конфігурації показаний на рис. 1
|
Тиждень 1 |
Тиждень 2 |
Тиждень 3 |
|||||||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
Стабілізація управління конфігураціями |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
План резервного копіювання |
|
|
|
|
|
|
|
|
Огляд управління конфігураціями |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Наради щодо покращення процесу управління конфігураціями |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Випадкові зовнішні аудити |
|
|
|
|
|
|
|
|
|
|
Рис 1. Розклад управління конфігураціями