Управління змінами

Вимірювання трудовитрат, необхідних для управління вимогами

Контроль статусу вимог

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

Стан	Визначення
Proposed (запропоновано)	Вимога, що запитана авторизованим джерелом
Approved (схвалено)	Вимога проаналізована, її вплив на проект прораховано, і вона була розміщена в базовій версії визначеної версії. Ключові зацікавлені в проекті особи погодились з цією вимогою, а розробники ПЗ зобов’язались реалізувати її
Implemented (реалізовано)	Код, що реалізує вимогу, розроблений, написаний і протестований. Вимогу відслідковано до відповідних елементів дизайну і коду
Verified (перевірено)	Коректне функціонування реалізованої вимоги підтверджено у відповідному продукті. Вимогу відслідковано до відповідних варіантів тестування. Тепер вимога вважається закінченою.
Deleted (видалено)	Затверджену вимогу видалено із базової версії. Необхідно зазначити причини видалення і назвати того, хто прийняв таке рішення.
Rejected (відхилено)	Вимога запропонована, але не запланована для реалізації ні в одній із майбутніх версій. Необхідно описати причини відхилення вимог і назвати того, хто прийняв таке рішення.

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

Управління вимогами, як і всякий інший процес, вимагає ресурсів. Контроль зусиль також дозволяє з’ясувати, чи виконують розробники пропонуємі задачі для управління вимогами. Основні трудовитрати по управлінню вимогами:

- Пропозиція зміни вимог та нових вимог;

- Оцінка запропонованих змін, включаючи оцінку впливу змін;

- Зміна роботи;

- Оновлення документації вимог або бази даних;

- Повідомлення про зміни вимог зацікавленим групам і окремим особам;

- Контроль і звіт про стан вимог;

- Збір інформації про трасуємість вимог.

Більшість розробників стикалися з простими на перший погляд змінами, які виявлялися більш складними, ніж вони очікували. Розробники іноді не виконують - або не можуть виконати - реалістичні розрахунки витрат та інших наслідків запропонованого зміни ПЗ. І коли розробник, який хоче бути люб'язним, погоджується додати поліпшення, запитуване користувачем, вимоги змінюються через «чорний хід», а не затверджуються зацікавленими особами, які мають на це право. Tакі неконтрольовані зміни - повсюдний джерело хаосу в проекті, порушення графіка і проблем з якістю, особливо якщо робота ведеться на декількох ділянках або проект виконує стороння організація. Організація, серйозно відноситься до управління
своїми проектами з розробки ПЗ, повинна переконатися, що:

· запропоновані зміни вимог ретельно оцінені до їх у введення у справу;

· відповідні особи приймають (беруть) бізнес-рішення, будучи добре інформованими про запитані зміни;

· схвалені зміни доведені до відома всім учасникам проекту;

· зміни вимог, внесені в проект, узгоджені один з іншим.

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

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