M-am confruntat de curînd cu acest subiect: evaluarea (se cerea de fapt un audit) riscurilor într-un proiect de dezvoltare software.

Pentru că sînt un adept al teorii sistemelor afirm de multe ori că se omite contextul. Sau banalul de acum, “suma părţilor este mai mare decît întregul”. Consider orice proiect ca fiind tot o schimbare/change pentru absolut toţi cei implicaţi. Şi în acest caz trebuie înţeles “contextul”/sistemul, relaţiile dintre componente (preluarea orbeşte, a celor scrise în frameworks, are ca efect decontextualizarea IT-ului şi ca efect bătăi de cap inutile). Dacă în analiza top down căutăm să “fărîmiţăm” lucrurile, vine un moment cînd acestea trebuie agregate. Controalele sînt proiectate şi funcţionează bottom-up…..În cascadă.

Nu voi discuta procesul şi componentele sale aşa după cum sînt prezentate ele de către PRINCE2 sau PMI (să nu uităm că multe poze sînt precedate de “Example”). Acolo este procesul, cu management, inputuri şi outputuri. Îl vizează pe PM.

În opinia mea, în cazul dezvoltării unei aplicaţii ar trebui avute în vedere 3 variabile: dimensiunea proiectului/complexitatea, structura şi experienţa membrilor.

Am luat în calcul dimensiunea pentru că în orice proiect sînt incluse alte variabile: costuri, timp, resursă umană, procese/funcţii afectate. Toate acestea prezintă riscuri. Aici intervine ceea ce se spune în metodologii.

Structurarea este relativ simplă: se lucrează după o metodologie sau nu? Dacă nu se lucrează este posibil să nu poată fi identificate multe controale documentare. Este direct legată de complexitate.

Experienţa este poate cel mai subiectiv aspect. Spun asta pentru că nici un proiect nu cred că seamnă cu altul. Au elemente comune, dar nu seamănă. Una este să faci o aplicaţie pentru banking şi alta pentru o şcoală. Chiar dacă se folosesc aceleaşi resurse umane şi tehnice. Cu cît mai multe proiecte cu atît mai bine. Aici aş aplica regula 80/20: 20% din membrii echipei să fi participat la 80% din proiectele din portofoliu…..Greu….Lumea academică din zona riscurilor este plină de lucrări care spun că înţelegerea comportamentului uman este cheia înţelegerii riscurilor…..

Prin prisma COBIT aş avea în vedere cîteva documente ce nu pot lipsi: studiul de fezabilitate,  specificaţiile  proiectului, analiza cost beneficiu, integrarea proiectului, cerinţele funcţionale/procedurale, controlul, arhitectura sistemului, testarea şi acceptarea, aprobarea finală.