Procesul de dezvoltare software (software development process) este definit in multe moduri. Software development life cycle (SDLC) reprezinta o structura, un ghid, un set de reguli care se impun in dezvoltarea unui produs software.
Dezvoltarea software poate fi privita ca o constructie a unei cladiri, implicand etapele de planificare, pregatire si executie. Explorand aceasta metafora, se pot gasi multe paralele. In functie de marimea si complexitatea proiectului, procesul se complica, iar planificarea va juca un rol esential in succesul/esecul proiectului.
Crearea unui produs software pleaca de la incercarea de rezolvare a unei probleme, problema care trebuie expusa din punctul de vedere al utilizatorului si care nu trebuie prezentata in termeni tehnici, pentru calculator (pentru ca solutia nu trebuie sa fie de fiecare data un nou produs software). De exemplu, daca avem un program software care inregistreaza numarul de masini vandute si care genereaza la sfarsitului anului un raport, iar noi dorim si un raport semestrial, solutia vine printr-un simplu calcul, cu un simplu calculator. Dar daca dezvoltarea pentru o functionalitate in plus a programului existent se face foarte greu, programatorii intampina probleme cu “uneltele de programare”, utilizatorii nu sunt multumiti de timpul de raspuns al programului, atunci se poate incepe cautarea unor rezolvari. Important este sa fim convinsi ca exista o problema, sa ii cunoastem toate detaliile si sa ne asiguram ca putem propune o solutie.
Specificatiile tehnice
Dupa identificarea problemei, este necesar un set de specificatii: (requirements analysis, requirements definition, software requirements, functional spec). Specificatiile sau cerintele unui proiect software descriu ceea ce viitorul sistem ar trebui sa faca. Ele reprezinta primul pas pentru solutia problemei utilizatorului. De asemenea, prin intermediul lor, utilizatorul reuseste sa se hotarasca daca functionalitatea este cea potrivita. Rolul major al specificatiilor il reprezinta diminuarea procentului de modificare al cerintelor dupa ce dezvoltarea propriu-zisa a inceput. In cazul in care in momentul scrierii codului, programatorul intalneste o eroare in specificatii, el poate fi nevoit sa modifice desgin-ul aplicatiei, sa elimine din codul scris pana atunci, sa rescrie cod (care dureaza mult mai mult decat cel initial), sa refaca testele, etc. Avand specificatii explicite, complete, programatorul nu va fi pus in situatia ca, in timpul dezvoltarii, sa ia decizii asupra implementarii/ modificarii functionalitii sau asupra design-ului proiectului.
Este cunoscut faptul ca in timpul procesului de dezvoltare, clientul/utilizatorul ajunge sa isi dea seama mult mai bine despre problema lui si astfel, schimbarile specificatiilor sunt inerente. Personal, nu am intalnit in cadrul nici unui proiect la care am lucrat, specificatii care sa nu fie modificate. In acest caz, un lucru important este ca toate partile implicate sa cunoasca implicatiile schimbarilor efectuate in timpul dezvoltarii. Se pot organiza sesiuni periodice in care utilizatorul/clientul sa propuna schimbarile, sa se discute costurile acestora si sa se hotarasca daca se vor aplica sau nu. Astfel, utilizatorul/clientul este multumit ca cererile lui sunt ascultate, iar programatorul este multumit ca eventuale schimbari se vor discuta doar la anumite perioade de timp. Modificarile frecvente si specificatii incomplete, abstracte, pot provoca esecul proiectului.
Dezvoltarea specificatiilor se realizeaza prin colectarea cerintelor rezultate din interviurile clientului/utilizatorului despre viziunea lui asupra viitorului sistem, prin construirea unui prototip interactiv sau prin analiza produselor concurente, similare. Rezultatele se vor centraliza in documente care vor fi analizate pentru identificarea caracteristicilor esentiale noului sistem.
O modalitate de documentare a cerintelor o reprezinta requirements checklist, o lista in care sunt furnizate specificatiile si care poate reprezenta un contract intre client si dezvoltator. Din pacate, o asemenea lista poate ajunge la sute de pagini, facand aproape imposibila citirea si intelegerea corecta si in totalitate a sistemului de catre un singur programator.
Specificatiile reprezinta un factor important in succesul dezvoltarii proiectului software. La inceputul proiectului, cand cerintele nu sunt clare, informatiile sunt insuficiente, recomandat este sa nu se inceapa dezvoltarea, ci dimpotriva, chiar amanarea acesteia, pana la obtinerea unor documente complete, actualizate, coerente, consistente, care sa nu fie ambigue.
