techIT.ro Do we have a problem? Let's tech it!    












Daca ai impresia ca educatia e scumpa,
atunci încearca sa vezi cum e ignoranta.
Andy McIntyre









Home  |  Dictionar IT  |  Download  |  Forum  |  Despre noi  |  Contact

Locul Analizei în proiectul de dezvoltare software

Locul Analizei în proiectul software. Povestea unui Proiect software

Modelele din articolele precedente sunt nişte modele călăuzitoare pentru lumea reală. Aşa cum rezultă de aici, Analiza Software este o disciplină care se află în relaţie de dependenţă cu celelalte discipline din proiect. Concret, task-urile din proiectul software sunt condiţionate unele de altele, iar task-urile specifice analizei sunt task-uri fără de care ciclurile din cadrul iteraţiilor nu pot avea loc.

Să luăm ca exemplu într-un proiect, pe care îl vom numi în continuare proiectul ALPHA, cu o echipă mare, cu un termen de livrare de cel puţin un an, cu o echipă de dezvoltare de 20 de persoane şi cu un client adesea indecis, care îşi schimbă cerinţele de la o lună la alta (acestea nu sunt condiţii excepţionale, nemaiîntâlnite într-un proiect software, ci dimpotrivă, sunt chiar condiţiile reale cel mai des întâlnite în practică). Proiectul porneşte cu mult entuziasm şi, în ciuda unor experienţe trecute nu prea plăcute, speranţele sunt mari. Şeful de proiect este (ce şansă!) un tip simpatic ales dintre programatorii cei mai experimentaţi un ins serios şi plin de calităţi iar echipa de programatori este o echipă cu experienţă, sudată în proiecte grele din trecut.

Proiectul se startează efectiv printr-o întâlnire faţă în faţă între cei mai valoroşi membrii ai echipei de dezvoltare şi şeful de proiect din partea clientului, însoţit şi el, bineînţeles, de câţiva dintre oamenii care au responsabilităţi legate de proiect. După manual întâlnirea se numeşte kick-off meeting şi trebuie făcută „ca să avem un prim contact cu ei”. Întâlnirea decurge bine pentru că echipa noastră de proiect ştie precis ce trebuie să întrebe şi discuţia este fructuoasă: discutăm despre cum să arate ecranul de introducere a datelor, cam care sunt rapoartele de care au ei nevoie, le explicăm că funcţionalitatea X nu se poate face chiar aşa cum credeau dar putem rezolva altfel, în fine... colaborarea este OK şi asta contează.
Se iau şi notiţe şi urmează ca pe baza lor să începem lucrul la specificaţie. Cu cât începem lucrul la specificaţie mai devreme, că să obţinem semnătura clientului pe ea, cu atât mai bine.
Spre finalul discuţiei o doamnă de la contabilitate îşi aminteşte că ea vrea neapărat un buton cu care sistemul să facă automat importul facturilor din Excel. I se explică rapid că această funcţionalitate necesită nişte dezvoltări care nu erau prevăzute dar asta o nemulţumeşte profund: se subînţelege că sistemul trebuie să facă asta pentru că altfel este inacceptabil. Ea nu are nevoie de acest sistem dacă nu face atâta lucru şi că ea nu este dispusă să bage de mână facturile în sistem. Abil, şeful nostru îi promite că va căuta o soluţie şi micul conflict se aplanează.

Întoarsă acasă, echipa de dezvoltare începe organizarea. Este numit un responsabil cu scrierea „specificaţiei” care trebuie terminată în două săptămâni că să scăpăm de treaba asta şi să ne apucăm de lucru. Scrierea specificaţiei va fi bineînţeles supervizată de şeful de proiect, cel mai în măsură să facă asta (chiar ar face el specificaţia dar nu are timp).

În fine, după alte trei şedinţe cu clientul şi după o lună de efort, „specificaţia” este gata, semnată şi parafată. Echipa poate începe să lucreze cu adevărat.
Se împart task-urile pentru programatori: tu te ocupi de capitolul 1 din specificaţie, tu de capitolul 2 şi aşa mai departe. Dacă sunt neclarităţi programatorii sunt liberi să întrebe.
Se fac şedinţe săptămânale în care se găsesc soluţii tehnice la diversele probleme. Din când în când şeful de proiect mai cere lămuriri la client în legătură cu o problemă sau alta. Dacă unele "lămuriri" se bat cap în cap cu specificaţia, se planifică o întâlnire la client şi se ia o decizie, de comun acord. Proiectul merge bine, în direcţia aşteptată chiar dacă apar din când în când bug-uri sau probleme de integrare (este interesant că aproape toată lumea poate face astfel de evaluări, chiar dacă "direcţia aşteptată" este definită vag şi, de obicei, se rezumă la evoluţia cantităţii de cod scris).


După opt luni de la începutul proiectului, echipa actuală începe să realizeze că există unele întârzieri. Pentru anumite module se pune problema că programatorul care a început treaba a plecat din echipă, iar cel care i-a luat locul nu înţelege prea bine ce are de făcut şi nici de ce s-a făcut într-un fel sau altul.
Şeful de proiect s-a săturat să tot pună întrebări la client aşa că răspunde la problemele ridicate de programatori cu nişte presupuneri logice, care, „simte” el că nu au cum să nu fie acceptate. Oricum, şi în echipa de proiect a clientului s-au făcut modificări şi nimeni nu mai ştie ce s-a cerut cu câteva luni în urmă.
Actualizarea specificaţiilor a fost abandonată demult pentru că nu mai era timp pentru aşa ceva şi oricum s-a dovedit o activitate inutilă.

După unsprezece luni şi jumătate este clar că proiectul e în întârziere. Deşi s-a dezvoltat aproape tot, mai sunt câteva probleme importante care nu au fost încă abordate din lipsă de timp, pentru care nu există o soluţie sau soluţia dată nu este acceptată de client şi trebuie făcute dezvoltări complexe. Testarea, care acum merge în plin, dă foarte mult de lucru echipei de dezvoltatori care nu mai fac faţă rezolvării bug-urilor.
Şedinţele de analiză cu şeful de departament arată clar că principalul vinovat este clientul care nu ştie prea bine ce vrea şi care şi-a schimbat foarte mult cerinţele. Evident, şi echipa este puţin vinovată pentru că nu a reuşit să îl ţină în frâu, dar acum clientul trebuie să înţeleagă că proiectul nu se poate termina la termen.

După alte şase luni, şeful de proiect din partea clientului îl anunţă pe directorul său general că proiectul, deşi se află în mare întârziere, nu este deloc ceea ce se aştepta să fie (deşi, privind în urmă putem vedea că această aşteptare nu a fost niciodată definită riguros), că responsabilii din departamente nu sunt mulţumiţi de sistem, iar unii au declarat că ei nu îl pot folosi sub nici o formă. La departamentul de producţie este evident că utilizarea sistemului ar produce un blocaj.

Se decide o nouă întâlnire între părţi, se analizează situaţia, se iau măsuri...

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Ciclul de dezvoltare iterativ (în spirală)
Articolul următor:  Modele teoretice de abordare a problemelor. Decompoziţia



  


  Adauga un comentariuSpune-ti parerea despre acest articol!