Визначення ризиків

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

Визначення ризиків може виконуватися в режимі командної роботи з використанням підходу "мозковий штурм" або грунтуватися на досвіді менеджера. При визначенні ризиків може допомогти приведений нижче список можливих категорій ризиків.

1. Технологічні ризики. Виникають з програмних і апаратних технологій, на основі яких розробляється система.

2. Ризики, пов'язані з персоналом. Пов'язані з членами команди розробників.

3. Організаційні ризики. Виникають з організаційного оточення, в якому виконується проект.

4. Інструментальні ризики. Пов'язані з використовуваними CASE-средствами і іншими засобами підтримки процесу створення ПО.

5. Ризики, пов'язані з системними вимогами. Виявляються при зміні вимог, що пред'являються до системи, що розробляється.

6. Ризики оцінювання. Пов'язані з оцінюванням характеристик програмної системи і ресурсів, необхідних для реалізації проекту.

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

Таблиця 9.5 - Категорії ризиків

Категорія ризиків	Приклади ризиків
Технологічні ризики	База даних, яка використовується в програмній системі, не забезпечує обробку очікуваного об'єму транзакцій. Програмні компоненти, які використовуються повторно, мають дефекти, що обмежують їх функціональні можливості
Ризики, пов'язані з персоналом	Неможливо підібрати працівників з необхідним професійним рівнем. Провідний розробник захворів в найкритичніший час. Неможливо організувати необхідне навчання персоналу
Організаційні ризики	У організації, що виконує розробку ПО, відбулася реорганізація, внаслідок чого змінилися пріоритети в управлінні проектом. Фінансові утруднення в організації привели до зменшення бюджету проекту
Інструментальні ризики	Програмний код, що генерується CASE-средствами, не ефективний. CASE-средства неможливо інтегрувати з іншими засобами підтримки проекту
Ризики, пов'язані з системними вимогами	Зміни вимог приводять до значних повторних темними вимогами роботам по проектуванню системи. Первинне нечітке формулювання призначених для користувача вимог привело до значних змін системних вимог, що виявилися на пізніх стадіях розробки проекту
Ризики оцінювання	Недооцінки часу виконання проекту. Швидкість виявлення дефектів в системі нижче раніше запланованою. Розмір системи значно перевищує спочатку розрахований