Процес контролю змін

Рис. Шаблон опису процесу контролю змін

1. Введення

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

2. Ролі та відповідальності

Необхідно перелічити членів команди - за ролями, не по іменах, які беруть участь у процесі контролю змін, і описати їх обов'язки. На рис. наведені деякі типові ролі; їх можна адаптувати відповідно до конкретної ситуації. Кожна людина може виконувати кілька ролей. Наприклад, голова ради з управління змінами також може отримувати запити, що подаються на зміни. У невеликих проектах декілька, а можливо, і всі ролі виконуються однією людиною.

Рис. Можливі ролі учасників проекту при управлінні змінами

3. Стан запиту на зміну

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

4. Вхідний критерій

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

5. Завдання

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

6. Перевірка

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

7. Вихідний критерій

Всі перераховані далі вихідні критерії повинні бути задоволені, щоб належним чином завершити процес управлінь змінами:

- стан запиту: Rejected (Відхилено), Closed (Закрито) або Canceled (Скасовано);

- всі зміни записані у відповідних розділах;

- ініціатор запиту, голова ради з управління змінами, менеджер проекту та інші значущі учасники проекту оповіщені про деталі зміни і поточний стан запиту на зміну;
- матриця зв'язків вимог оновлена.

8. Звіт про стан управління зміни

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

Дата добавления: 2014-01-11