Evaluarea riscurilor prin prisma ciclului de viaţă al sistemului (model – extras din teza de doctorat).
Putem vorbi de asemenea şi de o reprezentare în timp, pe o axă a ciclului de viaţă a proiectului a momentului apariţiei / identificării riscului.
Amintim de Project Management Institute: în opinia acestora un proiect trece prin paşii: o procesele de iniţiere – procesele de planificare – procesele de execuţie – procesele de control – procesele de închidere.
Sau, dacă analizăm situaţia prin prisma sistemelor, am putea face de asemenea o reprezentare în timp pe o axă a ciclului de viaţă. Şi un model de referinţă ar putea fi cel cascadă , dar asta doar pentru a scoate în evidenţă etapele ciclului de viaţă (la implementarea unui sistem de pot folosi evident, orice alt model, modelul V, modelul evolutiv, incremental, spirală etc.):
– definirea cerinţelor (stabilirea cerinţelor, structurarea cerinţelor, generarea şi alegerea variantelor de proiectare a sistemelor etc.)
– analiza (stabilirea managerului de proiect şi a echipei necesare la fiecare etapă – cerinţe profesionale, cerinţe psihologice, planificarea proiectului, stabilire beneficiari / furnizori, stabilire politici de securitate informaţională şi informatică, planificarea managementului de risc şi a planului de recuperare în caz de dezastru, analize de fezabilitate etc.)
o Atenţie! „Mai mult nu înseamnă neapărat mai bun”
o Atenţie! „Folosiţi unealta potrivită pentru sarcina potrivită”. Paul Dorsey, fondator şi preşedinte al Dulcian Inc., propune o listă de motive ce duc la eşecuri ale proiectelor de sisteme informaţionale, pe locul 6 amintind situaţia: „construirea sistemului în Java, chiar dacă cea mai mare parte a echipei de dezvoltare crede că Java este cafea!”.
– proiectarea (proiectarea logică – a interfeţelor, a dialogurilor, a bazelor de date, proiectarea fizică – a bazelor de date, a programelor şi procedurilor, a reţelelor de calculatoare şi a sistemelor de securitate etc.)
– implementarea (implementarea programelor, instalarea sistemului, documentarea sistemului şi întreţinerea utilizatorilor etc.)
– testarea (lansarea proiectului pilot şi testarea acestuia )
– utilizarea (utilizarea efectivă a sistemului)
– întreţinerea (operaţiuni de întreţinere, reproiectare, actualizare etc.).
Este de la sine înţeles că identificarea şi analiza unui risc încă din momentul definirii cerinţelor şi analizei sistemului se realizează mult mai uşor, implicând mult mai puţin efort (fizic, intelectual, financiar), controlând mult mai bine planificarea calendaristică şi generând planuri de răspuns la risc (control şi monitorizare) de o calitate ridicată, decât atunci când riscurile sunt identificate ulterior, în timpul proiectării, implementării, testării sau mai rău, după ce sistemul a fost pus în funcţiune.
Combinând etapele ciclului de viaţă al sistemului cu reprezentarea grupelor de risc, am putea genera o matrice a riscului, amintind din nou de dictonul latin „Divide et Impera”. Mai mult, putem introduce aici şi sursele de risc, interne sau externe sistemului.
Această matrice va fi prezentată într-o viitoare lucrare (carte) la care lucrez. Până atunci, mai multe despre managementul riscului la adresa www.managementul-riscurilor.ro
