Аналіз ризиків

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

1. Вірогідність ризику вважається дуже низькою, якщо вона має значення менше 10%; низькою, якщо її значення від 10 до 25 %; середньою при значеннях від 25 до 50%; високою, якщо значення коливається від 50 до 75%; дуже високою при значеннях більше 75%.

2. Можливий збиток від ризикових ситуацій можна підрозділити на катастрофічний, серйозний, терпимий і незначний.

Результати аналізу ризиків повинні бути представлені у вигляді таблиці ризиків, впорядкованих по ступеню можливого збитку. У табл. 9.6 приведений впорядкований список ризиків, описаних в табл.4. 6; там же вказана вірогідність цих ризиків. Тут вірогідність ризиків і ступінь збитку від них вказані довільно. На практиці для їх визначення необхідна докладна інформація про проект, технології створення ПО, команді розробників і про саму організацію.

Таблиця 9.6 - Список ризиків після проведення їх аналізу (приклад не копіювати)

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

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

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

У деяких статтях рекомендується визначити і відстежувати "10 верхніх" ризиків, але це не завжди обгрунтована рекомендація. Кількість ризиків, які необхідно відстежувати, залежить від конкретного проекту. Це може бути п'ять ризиків, а може - п'ятнадцять. Але, звичайно, кількість ризиків, по яких проводиться моніторинг, повинна бути осяжною. Велика кількість відстежуваних ризиків зажадає величезної кількості збираної інформації. Із списку ризиків, представлених в табл. 6, для моніторингу слід відібрати ті ризики, які можуть привести до катастрофічних і серйозних наслідків для вашого проекту.