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

Ciclul de dezvoltare al produsului software (SDLC)

Deşi în limba engleză este denumit Software Development Life Cycle (SDLC) am ales traducerea „Ciclul de dezvoltare al produsului software”, chiar dacă tendinţa întâlnită cel mai adesea este să se traducă prin „Ciclul de viaţă al produsului software”. (Nu mai vorbim că traducerea mot a mot ar fi şi ea diferită.)

Rămâne la latitudinea dumneavoastră să alegeţi traducerea preferată. Noi, în aceste articole, vom folosi denumirea de „Ciclul de dezvoltare al produsului software” dar îl vom prescurta aşa cum face mai toată lumea: SDLC.


Ciclul de dezvoltare al produsului software este un model al apariţiei produsului software, pornind de la problema originară şi ajungând la un produs concret, care să răspundă acelei probleme.
Cu siguranţă, acest model nu îşi arată utilitatea în condiţiile unor proiecte mici, cu un programator răspunzând la cerinţele ad-hoc ale unui client, şi asta în termen de câteva zile sau săptămâni.

Însă, în condiţiile în care în proiectele software din zilele noastre sunt implicate echipe mari de dezvoltatori, analişti, arhitecţi software, designeri, manageri, în multe cazuri distribuiţi în ţări sau pe continente diferite, pe perioade de timp de ordinul lunilor sau anilor, acest model teoretic începe să aibă utilitate.

El este un prim pas către separarea a ceea ce este în interiorul proiectului, din punct de vedere al tipurilor de activităţi şi din punct de vedere temporal. Este, prin urmare, un prim pas către acel „divide et impera” care, aşa cum vom vedea, permite păstrarea controlului asupra proiectului.


În literatura de specialitate sunt descrise mai multe Cicluri de dezvoltare software. Dintre acestea, două au importanţă asupra a ceea ce dorim să discutăm în această carte şi, din acest motiv, le vom prezenta numai pe acestea două. De asemenea, nu voi intra în toate detaliile acestor cicluri ci voi prezenta numai ceea ce consider a fi util din punct de vedere al Analizei Software.


Ciclul de dezvoltare în cascadă (în V)

Cel mai vechi model şi cel mai cunoscut este ciclul în cascadă (waterfall). El este o secvenţă de stadii în care finalul unui stadiu este începutul altuia. Aceste stadii sunt (de notat că în unele cărţi apar mai multe, fiind incluse studiul de fezabilitate, integrarea sau instalarea, stadii care pentru lucrarea de faţă sunt mai puţin relevante şi pe care nu le vom prezenta):

Ciclul de dezvoltare in cascada



1. Analiză
În această etapă a proiectului are loc definirea a ceea ce trebuie dezvoltat. Obiectivul aici este să se afle nevoile clientului şi să se definească foarte clar cerinţele privind viitorul produc software. Cartea de faţă este despre această fază.


2. Design
Această etapă are ca obiectiv modelarea viitorului sistem, văzut ca soluţie a problemelor determinate în faza de analiză. Dacă Analiza îşi propunea să determine ce trebuie făcut, faza de Design trebuie să arate cum trebuie făcut.
În această fază sunt proiectate funcţionalităţile pe care viitorul sistem va trebui să le aibă.


3. Dezvoltare
Această fază înseamnă scrierea efectivă a codului, dezvoltarea efectivă a acestuia.


4. Testare
În această fază produsul este testat pentru descoperirea anomaliilor în funcţionare, astfel încât la final să corespundă cerinţelor definite în faza de Analiză.


În afară de aceste faze esenţiale ale procesului de dezvoltare, mai trebuie totuşi menţionate şi deploy-mentul, acceptanţa şi mentenanţa. Acceptanţa este faza (sau momentul) în care clientul recepţionează sistemul software, acceptă că acesta corespunde cerinţelor lui şi îşi dă acordul pentru intrarea în faza de mentenanţă. Intrarea în faza de mentenanţă înseamnă încetarea includerii oricăror noi cerinţe în sistem şi corectarea bug-urilor (anomaliilor în funcţionare). Această fază este importantă pentru că ea constituie adesea o fază costisitoare, dar şi prea adesea ignorată.


Modelul de mai sus este, cu siguranţă, un model mai degrabă teoretic, el bazându-se pe presupunerea (evident falsă) că cerinţele definite în prima fază nu se vor schimba până la sfârşitul proiectului. În realitate schimbarea cerinţelor este singurul lucru stabil în software. Întotdeauna, în decursul proiectului, cerinţele se vor schimba (axioma A1 – vezi capitolul Axiome ale dezvoltării de software).


Marele rezultat al existenţei acestui model este evident de ordin teoretic. El ne dă imaginea clară a faptului că anumite activităţi nu pot fi executate decât după finalizarea altora, de altă natură – sunt dependente de ele.



În continuare (partea a V-a a seriei), voi descrie ciclul de dezvoltare în spirală (iterativ).

techit.ro





Colecţia:  Analiza cerinţelor software

Articolul precedent:  Axiome ale dezvoltării de software
Articolul următor:  Ciclul de dezvoltare iterativ (în spirală)



  


  Adauga un comentariuSpune-ti parerea despre acest articol!