.jpg)
Academia Română a fost creată în 1866 pentru a cristaliza cele mai înalte valori intelectuale din provinciile românești într-o societate erudită menită să consolideze identitatea națională pe baza a patru componente esențiale: limbă și literatură, istorie, etnografie și cultură. La...
Costul dezvoltării unui produs software – „ghiceală“ sau estimare?
Cătălin Tiseac,
Director Executiv PMSolutions
Răsfoind revistele de specialitate, găsesc aproape peste tot numai poveşti de succes despre firme care au finalizat cu succes proiecte de dezvoltare software de anvergură. Discutând la evenimente ale industriei cu colegi cu care încercăm să formăm o comunitate matură de project management, aflu de multe ori însă şi partea nevăzută şi de obicei nespusă a acestor proiecte “de succes” şi descopăr că aceste proiecte s-au confruntat în realitate cu depăşirea termenelor de finalizare planificate şi că valoarea costurilor de implementare a acestor proiecte a fost scăpată de sub control, fără ca aceste situaţii să se datoreze neapărat unei lipse de experienţă a persoanelor care le-au condus.
În condiţiile în care profitabilitatea şi competitivitatea proiectelor (şi, implicit, a companiilor care le derulează) sunt direct legată de costul aferent procesului de implementare, devine evident faptul că problema estimării proiectelor de dezvoltare software ar trebui să fie una de reală actualitate şi că, în condiţiile unei reduceri sau chiar lipse generale de finanţare a proiectelor, rezolvarea rapidă de către management a acestei probleme poate determina rămânerea sau dispariţia de pe piaţă a unor firme de software.
Făcând o analiză a experienţei personale de colaborare cu firme importante de dezvoltare software locale, precum şi a unor proiecte semnificative derulate în ultimii ani şi care au avut ca obiectiv principal dezvoltarea unor soluţii software dedicate, pot face următoarea estimare (aplicabilă pieţei locale de dezvoltare software):
- Mai mult de o treime dintre organizaţiile analizate nu derulează un proces formal de estimare a efortului şi a costului de dezvoltare utilizând o tehnică de estimare. În multe situaţii, costul (şi, implicit, preţul) sunt stabilite de către directorul firmei pe baza unor criterii care ţin mai mult de oportunitate şi mai puţin de justificarea economică (aşa se explică, de exemplu, situaţii bizare de reducere a preţului cu 50% pe durata unor licitaţii electronice la proiecte cu bugete de ordinul milioanelor de euro);
- Mai mult de jumătate dintre organizaţiile analizate nu colectează datele referitoare la efortul real consumat pe parcursul dezvoltării, sau nu utilizează instrumente de gestiune a costurilor reale ale activităţilor de dezvoltare şi ale resurselor implicate;
- Mai mult de două treimi dintre proiectele de dezvoltare software sunt întârziate şi/sau îşi depăşesc bugetul alocat (nu iau în considerare aici rezerva de timp sau bugetul de rezervă - riscuri - de care aceste proiecte, în majoritatea cazurilor, dispun).
De ce este dificil de estimat costul dezvoltării software?
Observând problemele cu care o firmă de software se confruntă atunci când aceasta trebuie să stabilească un buget pentru dezvoltarea unui produs software, devine inevitabilă întrebarea: care sunt motivele pentru care estimarea costului de dezvoltare software este aşa dificilă? Fără a intra în detalii, voi încerca să prezint în continuare câteva motive care determină dificultatea acestui proces:
- Multe firme producătoare de software nu colectează în mod organizat informaţii cu privire la performanţa estimărilor din proiecte anterioare, comparativ cu realitatea existentă la finalul implementării, ceea ce duce la o lipsă de informaţii referitoare la proiectele software finalizate. Lipsa acestor informaţii este un handicap important pentru managerul de proiect şi echipa sa în realizarea unor estimări de efort şi cost pentru proiectele noi.
- Estimările sunt realizate, de cele mai multe ori, sub presiunea timpului, fără a permite o evaluare realistă a efortului necesar dezvoltării unui produs software – de cele mai multe ori estimarea de efort şi de cost se realizează înainte ca o specificaţie clară şi completă să fie disponibilă şi fără a înţelege exact care sunt cerinţele pentru produsul care trebuie dezvoltat.
- Modificările, adaptările sau funcţionalităţile adiţionale apărute pe parcursul dezvoltării reprezintă mai degrabă o regulă decât nişte excepţii – ca o consecintă, graficul de implementare şi bugetul proiectului trebuie şi ele schimbate.
- Un număr important de factori determinanţi pot influenţa efortul şi timpul necesar unei dezvoltări – dimensiunea şi complexitatea produsului software, gradul de participare şi implicare a utilizatorilor pe parcursul etapelor de analiză şi testare, utilizarea unei metodologii consacrate sau nivelul de experienţă al echipei de dezvoltatori (în general, aceşti factori sunt dificil de luat în considerare în etapa de estimare).
- Persoana care face estimarea (de cele mai multe ori, managerul de proiect) nu are suficientă experienţă în derularea acestui proces, în special pentru proiecte mari sau foarte mari – câte proiecte de acest tip poate coordona un project manager sau un team leader pe parcursul a zece ani, perioadă care reprezintă să zicem experienţa medie a persoanelor de pe piaţa locală de muncă care deţin un astfel de rol?
- De cele mai multe ori, estimatorul ia în considerare efortul sau timpul necesar dezvoltării unei componente software în condiţiile în care activităţile ar fi desfăşurate de el sau de persoane situate la nivelul său de experienţă, neluând în considerare faptul că, în realitate, foarte multe dintre activităţi sunt derulate de colegi cu mai puţină experienţă, care au un nivel de performanţă şi productivitate semnificativ mai reduse.
- Managerul de proiect este deseori pus în situaţia de a accepta reduceri faţă de estimările iniţiale, pentru a face oferta comercială mai atractivă şi astfel se ajunge la un plan de implementare total nerealist, care, pe lângă depăşirile inevitabile de termene şi buget pe care le va genera, va duce şi la demotivarea echipei de proiect. Aceasta are implicaţii directe asupra performanţei echipei, devenind astfel un factor care contribuie la înregistrarea unor depăşiri suplimentare celor care se întrevedeau încă de la începutul proiectului.
- Nu de puţine ori, în estimarea de efort şi de timp nu se iau în considerare activităţile de management care trebuie să însoţească procesul de dezvoltare a unui produs software – am avut ocazia pe parcursul activităţii mele să văd grafice de implementare (Gantt) ale unor proiecte de dezvoltare software în care activităţile de planificare, urmărire şi control lipseau cu desăvârşire, în detrimentul activităţilor de analiză, design, dezvoltare sau testare. Aceste activităţi reprezintă, pe bună dreptate, scopul unui proiect de dezvoltare software, însă activităţi precum şedinţele de proiect şi producerea de rapoarte sunt, de asemenea, absolut necesare şi se vor desfăşura chiar dacă ele nu se regăsesc în planul de proiect, fiind prea puţin (sau chiar deloc) luate în consideraee în estimarea iniţială de efort şi de cost. Aţi avut vreodată curiozitatea să vedeţi cât costă în mod real astfel de activităţi?
Sunt foarte mulţi factori care influenţează durata sau efortul necesar pentru un proiect de dezvoltare software şi există şi modalităţi prin care unele organizaţii încearcă să răspundă acestor provocări (alocarea clară a responsabilităţilor, proceduri de luare a deciziilor, monitorizarea şi auditarea activităţilor etc.). Etapa iniţială care trebuie parcursă înainte ca procesul de estimare să fie demarat propriu-zis trebuie să vizeze obţinerea unor răspunsuri cât mai clare şi mai complete la următoarele întrebări:
- CE – specificaţia produsului software care trebuie dezvoltat (anvergură, cerinţe de calitate, complexitate, nivelul de reutilizare, gradul de documentare, arhitectura, cerinţele de securitate etc.);
- CU CE – descrierea instrumentelor şi a tehnicilor utilizate în procesul de dezvoltare software;
- CINE – caracteristicile resurselor care vor face dezvoltarea (calitatea, experienţa, disponibilitatea etc.);
- CUM – descrierea modului de organizare (roluri şi responsabilităţi) şi a planificării procesului de dezvoltare (planul de proiect);
- PENTRU CINE – caracteristicile utilizatorilor sau ale organizaţiei beneficiare (disponibilitatea şi nivelul de participare, numărul de persoane implicate, poziţia şi stabilitatea acestora în cadrul organizaţiei, nivelul de educare în utilizarea unor produse software sau experienţa în cadrul organizaţiei).
Tehnici şi instrumente utilizate în estimarea costurilor de dezvoltare
În ultimii 15 ani, au fost dezvoltate numeroase modele de estimate a costurilor de dezvoltare software. Fără a avea posibilitatea unei prezentări a acestora în cadrul acestui articol, voi menţiona câteva pentru a furniza o referinţă celor interesaţi să obţină detalii despre aceste modele: COnstructive COst Model (COCOMO), Functional Point Analisis (FPA), Programming Review of Information Costing and Evaluation – Software (PRINCE-S), Estimacs sau BIS-Estimator.
Indiferent de metoda pe care o alegeţi pentru estimarea efortului de dezvoltare, vă încurajăm să aveţi o abordare metodologică asupra procesului de dezvoltare, iar dacă nu aveţi încă o metodă proprie şi un proces documentat pentru realizarea estimărilor, există consultanţi cu experienţă care vă pot ajuta în acest demers.
Parerea ta conteaza: 
Cum definim misiunea unui proiect
