11.3. Питання для самоконтролю

1. Які методи перевірки вимог ви вважаєте найбільш ефективними?

2. Наскільки важливі, на вашу думку, неофіційні перегляди вимог, чому?

3. Як ви розумієте поняття «критерії прийнятності»? Яке значення вони мають?

Тема №12. Вимоги в управлінні проектом

12.1. Методичні вказівки до вивчення теми

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

Така постановка питання цілком логічна і обґрунтована, що підтвердить будь-який розробник. Проте, вона викликає багато питань, наприклад:

• Де знайти замовника, який погодиться чекати 2-3 місяці, поки розробник складе для нього комерційну пропозицію?

• Хто сплатить за роботи з аналізу вимог?

• Як бути, якщо ціна питання виявиться завеликою і від проекту доведеться відмовитися, хто відшкодує замовникові витрати на проведення досліджень?

Розумний замовник зможе знайти вихід з цієї непростої ситуації, наприклад:

• підшукавши розробника, що має великий досвід виконання подібних проектів, який зможе дати необхідну оцінку значно швидше (але ризик помилки при цьому залишається);

• узявши на себе ризики можливого припинення проекту на ранніх стадіях, у разі, якщо виявиться його невідповідність бюджетним обмеженням (у складних ризикованих проектах краще втратити 5% або 10% від бюджету, що закладається, ніж усі 100%, як це було у «каскадних» схемах розробки) – шлях прогнозуючих методологій;

• розділивши з розробникам відповідальність за кінцевий продукт, зважившись день за днем працювати з ним поряд аж до появи результату – шлях гнучких (agile) методологій.

Від меж проекту до експрес-планування

Початкову, приблизну оцінку проекту можна зробити на підставі документу «Бачення». Так, шаблон Vision/Scope MSF містить перелік ключових характеристик/функцій, критерії прийнятності і (що дуже важливе) перелік характеристик/функцій, які лежать «поза рамками» проекту. Паралельно з опрацюванням концепції, перша фаза MSF містить роботи з аналізу ризиків: виявляються і оцінюються головні ризики проекту.

Щоб зробити перше наближення плану і кошторису проекту на ранніх етапах аналізу, у [1] пропонується наступний підхід:

• Виділити 25 - 99 функцій, що характеризують систему (замовник і розробник спільно);

• Встановити пріоритети для кожної з функцій (замовник);

• Оцінити трудовитрати (розробник);

• Оцінити ризики (розробник, можливе залучення замовника).

Усі оцінки роблять за 3-бальною шкалою (високий, низький, середній; критичний, важливий, корисний і т.п.) і зводять у таблицю:

№ з/п	Функція	Пріоритет	Трудомісткість	Ризик

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

Результати планування на концептуальному рівні, виконані на основі вищезгаданого шаблону, дозволяють дати першу оцінку розмірам проекту. Така оцінка не відрізняється особливою точністю, але за певних умов (досвід розв’язання розробником аналогічних завдань; довірчі стосунки між замовником і розробником) може бути відправною точкою для укладання контракту на цілу систему.