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

Semnarea specificaţiilor software

În capitolul Locul Analizei în proiectul software am început un exemplu ipotetic, pentru realizarea proiectului ALPHA. Pentru a bifa realizarea şi semnarea specificaţiilor, echipa de proiect a făcut eforturi mari pentru a finaliza această prima etapă.

Ceea ce nu am spus acolo este faptul că, odată cu începutul etapei de scriere de cod, au apărut tot felul de întrebări din partea echipei de dezvoltare. Se solicitau diverse detalii sau lămuriri care erau fie retransmise către client fie rezolvate pe loc pe baze logice. De asemenea în discuţiile ulterioare, clientul şi-a amintit că uitase să ceară câteva lucruri importante şi, mai mult, a cerut modificarea unor cerinţe. Prevalându-se de semnăturile existente pe document şeful de proiect a încercat să respingă cerinţele noi şi modificările cerinţelor existente dar nu a reuşit decât să provoace un scandal, în care au fost implicaţi seful său de departament şi chiar, la un moment dat, managerul general al companiei. I s-a reproşat că refuză să ţină cont de cerinţele clientului.

Convins acum că specificaţia, deşi semnată, nu a fost altceva decât pierdere de timp, a refuzat să o mai actualizeze (nefiind utilizată ca un instrument de lucru în proiect, în această fază specificaţia nu era altceva decât un consumator inutil).

Ce a greşit totuşi echipa noastră de proiect? Singurul efect al semnării specificaţiilor software, pe care echipa proiectului ALPHA l-a avut în vedere, este acela al responsabilizării participanţilor la proiect, astfel încât exprimarea cerinţelor să fie pe deplin asumată de către autorii lor. Acest lucru s-a dovedit a fi însă insuficient.

Echipa proiectului ALPHA nu a înţeles că cerinţele într-un proiect software evoluează, că este imposibil să le îngheţi odată pentru totdeauna şi că semnarea specificaţiilor nu echivalează cu blocarea oricărei modificări ci este doar trecerea într-un alt stadiu, în care cerinţele se modifică doar printr-un proces definit, altul decât cel de până atunci.
Voi face aici trimitere la capitolul Axiome ale dezvoltării software, unde ne-am înţeles deja că în proiectele software apar întotdeauna schimbări ale cerinţelor şi că acest lucru trebuie recunoscut ca atare, nu negat sau ignorat (axioma A1 ne spune că întotdeauna cerinţele se schimbă pe parcursul derulării proiectului).

Prin urmare, semnarea specificaţiilor software nu înseamnă îngheţarea acestora ci reprezintă momentul trecerii proiectului într-o nouă etapă, în care baza o reprezintă specificaţia software, aşa cum este ea în momentul semnării, iar schimbările se fac printr-un proces mult mai strict şi pot fi însoţite de renegocieri ale bugetelor.
Semnarea specificaţiilor software înseamnă intrarea în vigoare a procedurilor de control a evoluţiei cerinţelor (despre acestea în capitolul Managementul cerinţelor).

Locul semnării specificaţiilor în Managementul cerinţelor

În excelenta sa carte, Software Requirements, domnul Karl E. Wiegers, unul dintre maeştrii Analizei Software, sugerează un text care poate să însoţească documentele de specificaţii, în pagina pentru semnături, text pe care l-am adaptat astfel:

"Suntem de acord că acest document reprezintă cea mai bună înţelegere a cerinţelor software şi că obiectul proiectului de dezvoltare este rezolvarea acestor cerinţe, aşa cum sunt descrise aici. Suntem de acord ca modificarea acestui document să se facă numai printr-un proces strict controlat şi numai cu acordul formal al părţilor. De asemenea înţelegem şi suntem de acord că modificările acestui document pot determina renegocierea costurilor, resurselor sau termenelor proiectului."

Desigur, textul de mai sus este orientativ. Fiecare companie poate concepe propriul text, importante fiind ideile transmise aici:
- documentul reprezintă cea mai bună înţelegere a cerinţelor clientului, la momentul de timp al semnării lui, evoluţiile nefiind excluse;
- dimpotrivă, evoluţiile sunt acceptabile, cu condiţia să fie agreate de ambele părţi şi să se facă printr-un proces strict controlat;
- cerinţele exprimate în document pot fi dezvoltate cu bugetele aprobate, dar modificarea cerinţelor actuale poate conduce la necesitatea unui buget mai mare, la suplimentarea echipei sau modificarea termenelor de finalizare. Aceste elemente trebuie renegociate.

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Tipuri de informaţii primite de la client




  


  Adauga un comentariuSpune-ti parerea despre acest articol!