ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 141
Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 8
Abonament PDF

Particularităţi ale proiectelor informatice

Dan Suciu
Lector, PhD @ Facultatea de matematică și informatică, UBB



MANAGEMENT


Unul dintre primele lucruri pe care le afli atunci când citeşti un articol sau o carte despre gestiunea proiectelor din IT este acela că proiectele informatice se deosebesc foarte mult de toate celelalte proiecte. Chiar și atunci când subiectul principal este legat de gestiunea proiectelor în general, se fac referiri directe cu privire la ineficienţa anumitor metode atunci când avem de-a face cu proiecte software. Din păcate nu este întotdeauna explicat în ce costau acele deosebiri şi se insistă mai degrabă pe a descrie soluţii, mai mult sau mai puţin eficiente. Articolul de faţă îsi propune să evidenţieze şi analizeze principalele aspecte caracteristice proiectelor informatice.

Unul dintre cele mai intens citate rapoarte statistice cu privire la succesul proiectelor informatice este Standish Group Chaos Report, care an de an publică rezultate procentuale ce evidenţiază ponderea proiectelor finalizate cu succes, a celor eşuate precum şi a celor care au întâmpinat dificultăţi majore până la finalizare. Criteriile care stau la baza acestui raport sunt foarte simple şi se referă ca scop, timp şi bani, sau mai precis la:

  • respectarea şi implementarea cerinţelor specificate,
  • încadrarea în bugetul estimat iniţial şi
  • respectarea termenelor de livrare agreate.

Proiectele de succes erau considerate acelea care respectau cu brio toate aceste criterii, cele eşuate erau cele care se stopau fără a mai fi finalizate din cauza nerespectării unuia sau mai multor criterii, iar cele finalizate reprezentau proiectele care au fost până la urmă terminate, rezultatul proiectelor fiind implementat cu condiția reevaluări și ajustării în mode semnificativ a unora dintre criterii.

Tabelul următor prezintă câteva dintre rezultatele raportului de-a lungul timpului, începând cu rezultatul "şocant" din 1994, ce relevă o rată de succes extrem de scăzută, şi până aproape de zilele noastre. Şi această statistică vine să confirme existenţa unei diferenţe evidente între proiectele informatice şi celelalte proiecte, un procent de eşec de 20-30% fiind de neconceput în vreunul dintre celelalte domenii, de la cel al construcţiilor de clădiri sau maşini până la servicii medicale.

An Succes Finalizat Eşec
1994 16% 53% 31%
1996 27% 33% 40%
1998 26% 46% 28%
2000 28% 49% 23%
2002 34% 51% 15%
2004 29% 53% 18%
2007 35% 46% 19%
2009 32% 44% 24%

Desigur că se poate discuta mult pe marginea acestor statistici şi a relevanţei lor. Pentru că "proiect informatic" este un termen care acoperă un spectru destul de larg şi eterogen de proiecte, e neclar ce fel de proiecte au fost luate în considerare. Între anii 1994 şi 2000 de exemplu, s-au studiat în jur de 30000 de proiecte informatice doar din Statele Unite ale Americii. Pentru 2004 raportul precizează că au fost luate în considerare peste 50000 de proiecte din întreaga lume (58% SUA, 27% Europa, 15% rest), cei de la Standish Group International asigurându-ne că s-a respectat un echilibru între numărul proiectelor mici, medii şi mari.

În altă ordine de idei, este destul de restrictiv să măsurăm succesul unui proiect luând în considerare doar criteriile scop, timp şi ban. Calitatea produsului sau a serviciului rezultat reprezintă la rândul său un criteriu important. De asemenea, există proiecte care nu au respectat cele trei criterii, dar care au fost considerate de către organizaţiile în care s-au desfăşurat ca fiind de mare success pentru că au atras ulterior noi proiecte importante, după cum există şi proiecte ce au excelat în toate cele trei direcţii însă presiunea exercitată a făcut ca echipa de proiect să se destrame rapid după terminarea proiectului pierzându-se experienţa şi expertiza câştigată în domeniul proiectului respectiv.

După cum se poate observa şi din graficul următor, în 2012 raportul vine cu informaţii agregate pe diferite tipuri de metodologii utilizate în gestionarea proiectelor. Aşa cum era de aşteptat, metodologiile Agile ameliorează simţitor numărul de proiecte eşuate, însă ele nu pot fi aplicate cu success pentru toate tipurile de proiecte informatice.

Dar ne-am îndepărtat destul de mult de scopul declarat al articolului. Ce am dorit să subliniem până la acest punct este doar că există diferenţe notabile între proiectele informatice şi celelalte tipuri de proiecte şi că aceste diferenţe par a influenţa negativ succesul acestora. În cele ce urmează le vom descrie pe cele mai importante.

1. Softul este nemăsurabil

Din fericire sau din păcate (în funcţie de perspectiva din care privim lucrurile), activitatea de dezvoltare a softului este una creativă. Nu există, aşa cum se întâmplă în cazul altor activităţi, un nomenclator care să precizeze care este timpul uzual necesar pentru implementarea unei ferestre ce conţine, să zicem, două liste derulante, un grid şi două butoane. În ciuda dezvoltării de instrumente sofisticate de generare automată a codului sau de implementarea diverselor biblioteci de clase sau framework-uri, fiecare proiect nou vine cu provocările proprii în ceea ce priveşte creativitatea.

Un exemplu edificator în acest sens este dat în cartea "The Healthy Software Project: a guide to successful development", (1993, autori M. Norris, P. Rigby, M. Payne) care face un experiment chestionând un număr de 44 de experţi în legătură cu numărul de instrucţiuni care apar în codul de mai jos:

#define 	LOWER	0
#define 	UPPER	300
#define 	STEP	20
main()
{
  int fahr;
  for (fahr=LOWER; fahr<=UPPER; fahr=fahr+STEP)
    printf("%4d %6.1 f\n", fahr, (5.0/9.0*(fahr-32)))
}

Răspunsurile acestora cuprind toate numerele între 1 şi 9 inclusiv (11 experţi au răspuns 6, alţii 11 au răspuns 9, restul alegând ca răspuns un alt număr din interval)! Concluzia este imediată: dacă nişte experţi în domeniul software nu reuşesc să cadă de acord asupra unei întrebări simple pe baza unui program de 9(!) linii, înseamnă că este de aşteptat ca estimările într-un proiect software să difere foarte mult de la o persoană la alta, aceste estimări având o relativ restrânsă legătură cu experienţa acumulată.

O practică uzuală este aceea ca estimările date (atunci când este vorba de estimări de timp şi nu în puncte de complexitate) să fie mărite cu 20% de către project manager înainte ca ele să fie transmise către client, pentru a se asigura o oarecare "linişte" (deşi sunt situaţii în care acest 20% este departe de a fi suficient).

O altă consecinţă directă a acestui aspect o reprezintă dificultatea gestionării schimbărilor într-o echipă de proiect, persoanele care vor înlocui anumiţi membri ai echipei rareori respectând estimările date de aceştia.

Şi pentru ca lucrurile să fie "complete", pentru multe dintre activităţile estimate este foarte dificil de controlat progresul. Cele mai reprezentative exemple aici sunt activităţile de analiză şi proiectare unde putem ştii când s-au terminat aceste activităţi, dar nu vom putea specifica dacă la un moment dat ne aflăm la 50% la 75% din activitatea respectivă.

2. Softul este invizibil şi intangibil

Rezultatul muncii unei echipe ce dezvoltă un produs informatic este compus dintr-o colecţie de "texte" de diferite tipuri: documente de analiză şi proiectare, cod sursă, manuale de utilizare şi operare etc. Doar o parte dintre acestea interesează sau au vreo semnificaţie pentru cei care vor utiliza produsul.

Clientul final tinde să evalueze un produs informatic după ceea ce vede, şi ceea ce vede este în general o interfaţă grafică cu utilizatorul.

Deoarece nu există nimic concret de arătat clientului în faza de analiză a cerinţelor, acesta îşi formează o imagine proprie asupra rezultatului final care de cele mai multe ori nu se potriveşte cu produsul dezvoltat. În plus, există tendiţa de a include în cadrul specificaţiilor elemente care reprezintă mai degrabă dorinţe decât nevoi reale de business. Se ajunge astfel într-un punct caracterizat de un grad ridicat de frustrare, în care echipa de proiect ştie că a dezvoltat conform specificaţiilor funcţionale dar clientul nu poate utiliza aplicaţia finală pentru că nu este ceea ce şi-a imaginat că va fi. Acest rezultat poate fi ameliorat prin prezentarea unuia sau mai multor prototipuri în fazele timpurii ale dezvoltării produsului, însă clientul nu va face întotdeauna diferenţa între acestea şi produsul final crezând că nu s-a depus un efort semnificativ între timp, interfaţa cu utilizatorul rămânând aproape neschimbată.

Tot din cauza invizibilităţii softului şi implicit a complexităţii acestuia, cerinţele iniţiale par foarte uşor de modificat şi implementat în cadrul unei aplicaţii.

3. Softul are o complexitate ridicată

Fără doar şi poate produsele software au o structură extrem de complexă. Într-o aplicaţie de dimensiuni medii există extrem de multe conexiuni între diverse elemente software care fac aproape imposibilă testarea şi validarea completă a acestora. Un exemplu simplu în care folosim nouă condiţii succesive intercalate poate rezulta într-un număr impresionant de căi posibile care trebuie testate fiecare în parte pentru o validare completă. Acest lucru însă ar putea să nu fie realizabil nici într-o săptămână, chiar dacă testul fiecărei căi ar dura o secundă. Mai mult, aceste teste ar trebui reluate de fiecare dată când se face o modificare. Prin urmare multe dintre bug-uri persistă o vreme îndelungată (chiar ani de zile) într-o aplicaţie până să fie descoperite sau, mai rău, până să îşi arate efectele.

După cum se spunea în aceeaşi carte menţionată anterior, "The Healthy Software Project: a guide to successful development": "...în cazul proiectelor software aşa numitele proceduri de control al calităţii au uneori de-a face mai degrabă cu limitarea defecţiunilor decât cu garantarea calităţii produsului final." Şi acest lucru a rămas valabil şi în 2012, în ciuda tuturor metodologiilor moderne de dezvoltare a softului apărute în ultimii ani.

Complexitatea softului este dată şi de numărul de tranziţii şi "traduceri" ce trebuie realizate între fazele ciclului de viaţă al unui produs. Specificaţiile funcţionale (redactate în limbaj natural) sunt translatate într-un model de analiză (diagrame vizuale care modelează toate soluţiile posibile ale problemei enunţate în specificaţii), care ulterior este translatat într-un model de proiectare (unde se particularizează modelul de analiză pentru o soluţie specifică), care mai apoi este translatat în cod sursă, acesta din urmă fiind translatat într-un model executabil (prin compilare sau interpretare). Tot acest lanţ de translatări, în ciuda faptului că anumite tranziţii sunt automatizate, face procesul de dezvoltare a softului mult mai vulnerabil la erori umane. Acest lucru este cauzat de greşeli de "traducere" sau prin persistarea erorilor nedescoperită la timp în fazele de specificare sau analiză până în modelul executabil.

4. Softul este dinamic

Dinamismul cu care se confruntă proiectele software se manifestă în trei direcţii relevante. Pe de o parte există atracţia noutăţii tehnologice. Ştim că tehnologia avansează foarte rapid şi an de an apar biblioteci şi framework-uri noi, şi versiuni îmbunătăţite ale limbajelor şi mediilor de dezvoltare. Din punct de vedere al unui project manager, păstrarea framewok-urilor iniţiale în care a fost dezvoltat un anumit soft este o condiţie elementară de păstrare a stabilităţii acestui soft. Pe de altă parte nu trebuie ignorată apetenţa echipei pentru a lucra cu ultimele tehnologii (inerent mai instabile şi cu neajunsuri încă nerezolvate sau nediscutate pe forumurile de specialitate). Există un efort constant şi care nu trebuie neglijat, de păstrare a unui echilibru între stabilitate şi eliminarea unui sentiment de plafonare a echipei de dezvoltare.

A doua direcţie ce conferă dinamism proiectelor software este fluctuaţia personalului, care în domeniul IT este foarte ridicată. O fluctuaţie "sănătoasă" pentru o organizaţie se situează undeva în jurul a 10 procente. Un studiu realizat de Ziarul Financiar arată ca în domeniul IT în România fluctuaţia de personal este la nivelul de 20%, şi ea nu se datorează în principal nivelului de salarizare (cum este în cazul altor domenii) ci diferenţelor de cultură şi a sentimentului de nerealizare profesională. Efectele acestei fluctuaţii, după cum subliniam şi în secţiunea 1, constau în reconsiderarea planificărilor anterioare şi de adaptare a noilor veniţi la proiect. Nu trebuie însă neglijată tendinţa noilor veniţi de a respinge codul scris de predecesorii lor, încercând uneori chiar să îşi asume responsabilitatea înlocuirii complete a acestui cod, acţiune ce conduce la anularea validărilor anterioare.

În fine, o dinamică aparte faţă de alte proiecte o au cererile de modificare frecvente venite din partea clientului în diverse faze ale ciclului de viaţă a dezvoltării unui proiect software. Această caracteristică a proiectelor software a condus la dezvoltarea medologiilor Agile care includ acest aspect ca pe o componentă activă a procesului de dezvoltare.

Concluzii

Am încercat să evidenţiem unele dintre aspectele care considerăm că diferenţiază în mod clar proiectele software de alte proiecte existente şi care au o contribuţie decisivă în situarea acestor proiecte pe un loc fruntaş în topul eşecurilor pe tipuri de proiecte.

Desigur că alături de dificultăţile de măsurare, invizibilitatea, intangibilitatea, complexitatea, şi dinamismul proiectelor software, există şi alte aspecte specifice. De exemplu, sporirea resurselor într-un proiect software întârziat nu elimină decalajul ci sporeşte întârzierea, deoarece capacitatea de efort a membrilor echipei scade cu o cantitate egală cu efortul de comunicare cu noul membru. Aceste lucruri nu se întâmplă în marea majoritate a proiectelor în care se desfăşoară cu preponderenţă activităţi de rutină.

Scopul articolului nu a fost acela de a emite soluţii de gestionare a particularităţilor, acestea putând contitui subiectul unui viitor articol. Cu siguranţă însă, categoria metodologiilor Agile de dezvoltare a softului are în vedere o bună parte a acestor particularităţi.

Nu dorim să încheiem articolul fără a pune o întrebare firească ce rezultă în urma acestei analize: "Cum se face că, în pofida tuturor acestor neajunsuri, industria software rezistă şi chiar înfloreşte?" Răspunsul este unul optimist, ce se referă la beneficiile aduse de rezultatele proiectelor software şi a necesităţii acestora. Fără doar şi poate, aplicaţiile software au menirea de a ne face viaţa mai simplă într-o multitudine de aspecte ale vieţii cotidiene. Chiar dacă uneori ele se blochează sau funcţionează eronat, le acceptăm, trecem cu uşurinţă peste multe dintre aceste erori sau găsim căi de ocolire a lor deoarece avantajele obţinute pun în umbră aceste neajunsuri.

LANSAREA NUMĂRULUI 141

Analiza de business (BA)

miercuri, 27 martie, ora 18:00

sediul Accesa

Facebook Meetup StreamEvent YouTube

NUMĂRUL 140 - Generative AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO