ETAPELE DE DEZVOLTARE

A SISTEMELOR DE
PROGRAME

Elev:Bujac Igor
Grupa:PAP1613G
 CICLUL DE VIAŢĂ

Există patru faze fundamentale ale metodologiilor ingineriei software:

 analiza (ce dorim să construim);
 proiectarea (cum vom construi);
 implementarea (construirea propriu-zisă);
 testarea (asigurarea calităţii).

Deşi aceste faze se referă în mod special la ciclul de viaţă al

produsuluisoftware, ele pot fi aplicate şi altor stadii de existenţă prin
care trece un programde la „naştere” până la „moarte”: lansare,
întreţinere, ieşire din uz.
 FAZA DE ANALIZĂ

Această fază defineşte cerinţele sistemului, independent de modul în care

acestea vor fi îndeplinite. Acum se defineşte problema pe care clientul doreşte să
o rezolve. Rezultatul acestei faze este documentul care conţine specificarea
cerinţelor şi care trebuie să precizeze clar ce trebuie construit.
Faza de analiză poate fi văzută ca o rafinare a detaliilor. Distincţia dintre
detaliile de nivel înalt şi cele de nivel scăzut sunt puse mai bine în evidenţă de

abordările top-down (unde se merge către detaliile de nivel scăzut) şi bottom-up

(care tind către detaliile de nivel înalt).
 FAZA DE
PROIECTARE

Pe baza cerinţelor din faza de analiză, acum se stabileşte arhitectura

sistemului: componentele sistemului, interfeţele şi modul lor de comportare:
 Componentele sunt elementele constructive ale produsului. Acestea pot fi

create de la zero sau reutilizate dintr-o bibliotecă de componente.

Componentele rafinează si capturează semnificaţia detaliilor din
documentul cerinţelor;
 Interfeţele ajută la îmbinarea componentelor. O interfaţă reprezintă graniţa
dintre două componente, utilizată pentru comunicarea dintre acestea. Prin
intermediul interfeţei, componentele pot interacţiona;

 Comportamentul, determinat de interfaţă, reprezintă răspunsul unei

componente la stimulii acţiunilor altor componente.
 FAZA DE
IMPLEMENTARE

În această fază, sistemul este construit, ori

plecând de la zero, ori prin
asamblarea unor componente pre-existente.
Pe baza documentelor din fazele anterioare,
echipa de dezvoltare ar trebui să ştie exact
ce trebuie să construiască, chiar dacă
rămâne loc pentru inovaţii şi flexibilitate.
 ERORI
 Erori critice: Împiedică sistemul să satisfacă în mod complet scenariile

de utilizare. Aceste erori trebuie corectate înainte ca sistemul să fie

predat clientului şi chiar înainte ca procesul de dezvoltare ulterioară a

produsului să poată continua;

 Erori necritice: Sunt cunoscute, dar prezenţa lor nu afectează în mod

semnificativ calitatea observată a sistemului. De obicei aceste erori

sunt listate în notele de lansare şi au modalităţi de ocolire bine

cunoscute;

 Erori necunoscute: Există întotdeauna o probabilitate mare ca

sistemul să conţină un număr de erori nedescoperite încă. Efectele

acestor erori sunt necunoscute. Unele se pot dovedi critice, altele pot fi

rezolvate cu patch-uri sau eliminate în versiuni ulterioare.

 FAZA DE TESTARE

Calitatea produsului software este foarte importantă.

Multe companii nu au învăţat însă acest lucru şi produc
sisteme cu funcţionalitate extinsă, dar cu o
calitate scăzută. Totuşi, e mai simplu să-i explici
clientului de ce lipseşte o anumită funcţie decât să-i
explici de ce produsul nu este performant. Un client
satisfăcut de calitatea produsului va rămâne loial firmei
şi va aştepta noile funcţii în versiunile următoare.
 TESTELE DE REGRESIUNE

Testele de regresiune sunt colecţii de programe

care testează una sau mai multe trăsături ale sistemului. Rezultatele testelor sunt
adunate şi dacă există erori, eroarea este corectată. Un test de regresiune valid
generează rezultate verificate, numite „standardul de aur”.
Validitatea rezultatului unui test ar trebui să fie determinată de documentul
cerinţelor.
 TESTAREA INTERNĂ

Testarea internă tratează implementarea de nivel scăzut. Fiecare funcţie

sau componentă este testată de către echipa de implementare. Aceste
teste se mai numesc teste „clear-box” sau „white-box”, deoarece toate
detaliile sunt vizibile pentru test.
 TESTAREA UNITATILOR

Testarea unităţilor testează o unitate ca un întreg. Aici se testează

interacţiunea mai multor funcţii, dar numai în cadrul unei singure unităţi. Testarea
este determinată de arhitectură. De multe ori sunt necesare aşa-numitele
„schele”, adică programe special construite pentru stabilirea mediului de test.
Numai când mediul este realizat se poate executa o evaluare corectă. Programul
schelă stabileşte stări şi valori pentru structurile de date şi asigură funcţii externe fictive.
 CONCLUZIE

Problematica domeniului ingineriei software este diversă şi se amplifică

pe măsura creşterii continue a complexităţii sistemelor software.
Toate eforturile au fost şi sunt direcţionate către satisfacerea cât mai
completă a cerinţelor utilizatorilor, a creşterii calităţii sistemelor şi a scăderii
costurilor de producere.
MULTUMESC PENTRU
ATENTIE!!!