Managementul riscului

1. Introducere

În această prezentare, atenţia se concentrează pe riscul datorat

întârzierii proiectului sau depăşirii bugetului alocat

Identificăm trei tipuri de riscuri:

• cele cauzate de dificultăţile inerente ale estimării;
• cele datorate presupunerilor făcute în timpul procesului de
planificare;
• cele datorate unor evenimente apărute neaşteptat.
Estimarea erorilor
Anumite sarcini sunt greu de estimat din cauza lipsei experienţei cu
sarcini similare, de aceea e indicat să existe manuale de utilizare. Pe de
altă parte, timpul petrecut cu testarea şi depanarea poate fi greu de
prognozat cu un grad de acurateţe mărit.
Estimarea poate fi îmbunătăţită dacă se analizează datele istorice pentru
activităţi similare şi sisteme similare. Păstrarea înregistrărilor comparând
estimările originale şi rezultatele finale vor pune în evidenţă tipurile de
sarcini pentru care se fac cu greu estimări corecte.

Presupunerile făcute la planificarea activităţilor

La fiecare etapă a procsului de planificare, e important să listăm explicit
toate presupunerile care au fost făcute şi să identificăm ce efecte pot
avea asupra planului dacă sunt nepotrivite.

Posibilităţi
Anumite posibilităţi nu pot fi prevăzute. Totuşi, majoritatea evenimentelor
neaşteptate pot fi, în realitate, prevăzute. Asemenea evenimente se pot
întâmpla din timp în timp şi, chiar dacă probabilitatea de apariţie a lor să
fie mică, trebuie luate în calcul şi planificate.
 2. Managementul riscurilor

Există un număr de modele pentru managementul riscului, dar majoritatea

sunt similare, pentru că identifică două componente majore – identificarea
riscului (risk identification) şi managementul riscului (risk management). În
figura de mai jos e dată o structură divizată în sarcini, pe care Barry
Boehm o numeşte ingineria riscului (risk engineering). Toate elementele
din figură se vor discuta în detaliu în slide-urile următoare.
 3. Identificarea riscurilor (risk identification)

Trebuie făcută distincţia dintre cauza întâmplătoare (hazard) şi efectul

produs de acesta.
Anumite cauze întâmplătoare sunt generice – adică sunt relevante pentru
toate proiectele software. Asemenea riscuri sunt înţelegerea greşită a
cerinţelor şi starea de boală a persoanelor cheie implicate în proiect.
Alte riscuri sunt specifice – care vor fi identificate mai greu şi numai cu
suportul întregii echipe a proiectului.

Categoriile care trebuie luate în considerare sunt:

Factorii legaţi de aplicaţie (application factors) – natura aplicaţiei (fie că
e vorba de o aplicaţie de porcesare simplă a datelor, de un sistem critic din
punct de vedere al securităţii sau de sisteme distribuite) poate fi un factor
critic. De asemenea, mărimea aşteptată a aplicaţiei e importantă (cu cât e
mai mare aplicaţia, cu atât probabilitatea de apariţie a erorilor e mai mare).
Factorii legaţi de personal (staff factors) – un programator experimentat
face, de regulă, mai puţine erori decât unul cu mai puţină experienţă. Pe
de altă parte, e importantă aria în care unii au experienţă (experienţa unui
programator în Cobol nu prea contează dacă dezvoltă un sistem în C++).

Factorii legaţi de proiect (project factors) – e important ca proiectul şi

obiectivele sale să fie bine definite şi să fie clare pentru toţi membrii
proiectului şi pentru stakeholders.

Metode legate de proiect – folosind anumite metode pentru

managementul proiectelor şi dezvoltarea de sistem se scade probabilitatea
ca sistemul să fie livrat târziu sau cu probleme. Pe de altă parte, folosirea
acestor metode pentru prima oară poate duce la întârzieri.

Factorii hardware/software – un proiect care necesită hardware nou

poate pune probleme mai mari decât dacă se dezvoltă sistemul pe un
hardware existent. Realizarea proiectului pe un tip de hardware şi o
platformă software şi utilizarea sistemului pe un alt hardware şi/sau
software poate ridica anumite probleme la instalare şi nu numai.
Factorii legaţi de schimbări (changeover factors) – o schimbare
radicală pentru noul sistem facilitează apariţia riscurilor. Schimbările
graduale minimizează riscurile dar nu sunt întotdeauna practice.

Factorii legaţi de furnizori (supplier factors) – un proiect se bazează

uneori pe organizaţii exterioare. Riscurile legate de întârzierile cu care
livrează anumite produse sau de calitatea acestora nu pot fi controlate.

Factorii de mediu (conjuncturali) – de exemplu, schimbări legate de

regulile de plata a salariilor (modificarea CAS, a sporurilor etc) pot afecta
succesul unui proiect ce gestionează salarizarea într-o organizaţie.

Factorii de sănătate şi siguranţă – deşi impactul asupra sănătăţii şi

siguranţei celor care interacţionează cu un proiect software e diminuat faţă
de alte proiecte (de exemplu, construcţii), totuşi, conform BS 6079, “orice
proiect trebuie să includă un audit al acestor posibile riscuri înainte de a
începe”, iar acest audit trebuie să facă parte din planul de ansamblu al
proiectului.
 4. Analiza riscurilor (risk analysis)

Identificând riscurile, e utilă o cale de a le evalua importanţa. Anumite

riscuri au probabilitate mai mare de apariţie (cum ar fi îmbolnăvirea unuia
dintre membrii echipei, chiar şi pentru o perioadă scurtă de timp), iar altele
au probabilitate mică de apariţie (un eşec hardware să ducă, de exemplu,
la pierderea întregului cod scris).

Probabilitatea apariţiei unei cauze întâmplătoare de risc e cunoscută ca

probabilitatea riscului (risk likehood). Efectul rezultat, dacă apare, se
numeşte impactul riscului (risk impact) şi importanţa riscului e cunoscută
ca valoarea riscului (risk value sau risk exposure). Risk value e calculat:
risk value = risk likehood x risk impact
Obs. Termenii de mai sus pot fi întâniţi şi sub alte denumiri, nu sunt
denumiri universal acceptate.

Ideal, impactul riscului e exprimat în termeni monetari şi probabilitatea

riscului ca probabilitate (număr subunitar). În acest caz, valoarea riscului
va reprezenta costul aşteptat (expected cost). Se pot compara aşadar
valorile riscului pentru a evalua iportanţa relativă a riscurilor.
Mulţi manageri folosesc o metodă prin care se dau scoruri riscurilor,
pentru a oferi o măsură cantitativă pentru evaluarea fiecărui risc. Un scor
ar putea fi împărţirea în trei categorii (High, Medium, Low), dar se
recomandă (şi e mai populară) metoda în care se dau note de la 1 la 10
(unde 10 este pentru probablitatea cea mai mare de apariţie e unei erori).

Măsurile de impact, notate pe o scară similară, trebuie să ia în

consideraţie riscul total al proiectului. Acesta trebuie să includă
următoarele costuri potenţiale:
• costul întârzierilor faţă de datele planificate pentru deliverables;
• supracostul datorat de folosirea adiţională a unor resurse;

În tabelul următor se dă un exemplu de calcul a valorii riscului pentru un

anumit proiect.
Acordarea de priorităţi riscurilor
Managerii folosesc două strategii:
• reducerea valorii riscului prin reducerea probabilităţii riscului sau a
impactului riscului;
• realizarea unor planuri de rezervă (care să ia în calcul întâmplări
neprevăzute), astfel încât, dacă riscurile apar, să fie gestionate.

Oricare dintre aceste strategii vor avea un cost asociat. De aceea e

importantă acordarea de prorităţi riscurilor, pentru ca cele mai importante
să primească atenţia cea mai mare.

În practică, sunt în general alţi factori care trebuie luaţi în calcul atunci
când vrem să aranjăm în funcţie de prioritate:
• Riscuri acumulate. Când se întâmplă acest lucru, riscurile trebuie
tratate ca şi cum ar fi un singur risc.
• Numărul riscurilor. Există un număr maxim de riscuri ce trebuie
considerate efectiv de un manager
• Costul acţiunii. Anumite riscuri, o dată identificate, pot fi reduse sau
evitate imediat cu un cost redus. Pentru alte riscuri trebuie să comparăm
costurile cu efectuarea acţiunii cu beneficiile reducerii riscului. O metodă
e să se calculeze risk reduction leverage (RRL):

REina int e − REdupa

RRL =
cos t reducere risc

unde REinainte e valoarea riscului originală, REdupa este valoarea riscului

aşteptată după trecerea la acţiune, iar cost reducere risc este costul
implementării acţiunii de reducere a riscului.
 5. Reducerea riscurilor

În linii mari, există 5 strategii de reducere a riscului:

• Prevenirea hazardului.

• Reducerea probabilităţii de apariţie.

• Evitarea riscului.

• Transferul riscului. Anumite riscuri pot fi transferate, de exemplu

printr-o asigurare.

• Planificarea de rezervă (contingency planning)

În tabelul de mai jos sunt arătate riscuri şi măsuri de reducere a acestor

riscuri, aşa cum sunt prezentate în Tutorial on Software Risk
Management, IEEE Computer Society, 1989 de Barry Boehm.
 6. Metode de reducere a riscurilor

Utilizarea PERT pentru evaluarea efectelor incertitudinii

PERT (Program Evaluation and Review Techniques) utilizează 3
estimatori:
• Most likely time – timpul pe care-l aşteptăm pentru ca sarcina să se
desfăşoare în circumstanţe normale. Îl notăm cu m.
• Optimistic time – cel mai scurt timp în care ne aşteptăm că completăm
activitatea. Îl notăm cu a.
• Pessimistic time – cel mai prost timp pentru completarea activităţii. Îl
notăm cu b.

Timpul aşteptat (te) obţine cu relaţia:

a + 4m + b
te =
6
Exemplu. Se consideră tabelul de mai jos, cu estimările timpului
activităţilor folosind estimatorii PERT:

Reţeaua PERT prezentată pe pagina următoare ne arată că se aşteaptă

ca proiectul să dureze 13,5 săptămâni.
 Convenţia de notare în reţeaua PERT

Reţeaua PERT pentru activităţile prezentate în tabelul

precedent
O măsură cantitativă a gradul de incertitudine a unui estimator de timp
pentru o activitate se obţine calculând deviaţia standard s:
b−a
s=
6
Tabelul cu estimatorii PERT se completează cu deviaţia standard şi va
arăta astfel:
Avantajul tehnicii PERT este că oferă o metodă pentru estimarea
probabilităţii de a respecta sau rata datele planificate ale diverselor
sarcini.
Să presupunem că vrem să completăm proiectul în 15 săptămâni, dar ne
aşteptăm să ne ia 13,5 săptămâni. Poate lua mai mult sau mai puţin. În
plus, să presupunem că activitatea C trebuie completată până în
săptămâna a 10-a. În plus, evenimentul 5 reprezintă livrarea produsului
intermediar către client.
Tehnica PERT foloseşte o metodă în 3 paşi pentru a calcula
probabilitatea de a respecta sau nu data ţintă:
• se calculează deviaţia standard pentru fiecare eveniment al proiectului;
• se calculează valoarea z pentru fiecare eveniment care are o dată ţintă;
• se converteşte valoarea z la probabilitate.

Deviaţia standard pentru evenimentul 3 depinde doar de activitatea B. De

aceea deviaţia standard va fi 0,33.
Pentru evenimentul 5 există două căi posibile, B+E sau F. Deviaţia
standard totală pentru calea B+E este

0,332 + 0,50 2 = 0,6

iar pentru F este1,17. Prin urmare, deviaţia standard pentru evenimentul
5 este 1,17 (cea mai mare dintre ele).
Calcularea valorii z
Valoarea z se calculează pentru fiecare nod care are o dată ţintă, cu
formula de mai jos, în care T este data ţintă, iar te este data aşteptată:

T − te
z=
s
Valoarea z pentru evenimentul 4 este (10-9)/0,53=1,8867.

Convertirea valorii z la probabilităţi

Se poate face folosind tabelele cu valorile lui z, care se găsesc în

majoritatea cărţilor de statistică sau cu un grafic ce reprezintă
echivalentul tabelelor.
Simularea Monte Carlo
Baza acestei tehnici este calcularea timpilor evenimentelor de un număr
mare de ori, fiecare timp selectând timpii activităţii aleator dintr-o mulţime
de estimări pentru fiecare activitate. Rezultatele sunt apoi tabulate,
sumarizate sau afişate ca grafic, aşa cum se arată în figura de mai jos.