Ingineria programelor

Fazele IP
Fazele fundamentale
Exist patru faze fundamentale ale
metodologiilor ingineriei programrii:
analiza (ce dorim s construim);
proiectarea (cum vom construi);
implementarea (construirea sau realizarea
propriu-zis);
testarea (asigurarea calitii).
1. Faza de analiz
definete cerinele sistemului, independent de
modul n care acestea vor fi ndeplinite.
Rezultatul acestei faze este documentul
cerinelor (caietul de sarcini) care trebuie s
precizeze clar ce trebuie construit (realizat).
poate fi vzut ca o rafinare a detaliilor
Documentul cerinelor
conine cerinele din perspectiva clientului, definind
scopurile i interaciunile la un nivel descriptiv nalt,
independent de detaliile de implementare, cum ar fi, de
exemplu: formularea problemei, ateptrile clientului
sau criteriile pe care trebuie s le ndeplineasc
produsul.
poate fi realizat ntr-o manier formal, bazat pe
logic matematic, sau poate fi exprimat n limbaj
natural
descrie obiectele din sistem i aciunile care pot fi
realizate cu ajutorul obiectelor.
descrie ontologia proiectului, adic vocabularul de
cuvinte cheie (n special construcii substantivale i
verbale) care va fi utilizat pentru definirea protocolului
specific aplicaiei.
Documentul cerinelor (continuare)
Mai concret, documentul trebuie s conin descrieri pentru
urmtoarele categorii:
Obiecte: documentul trebuie s defineasc mai nti ontologia
sistemului, care este bazat n mare parte pe construcii substantivale
pentru identificarea pieselor, prilor componente, constantelor,
numelor i a relaiilor dintre acestea.
Aciuni: documentul trebuie s defineasc, de asemenea, aciunile pe
care trebuie s le ndeplineasc sistemul i care sunt sugerate n
general de construcii verbale. Exemple de aciuni sunt: metodele,
funciile sau procedurile.
Stri: Sunt definite ca mulimi de setri i valori care disting sistemul
ntre dou ipostaze spaio-temporale. Fiecare sistem trece printr-o
serie de schimbri de stare. Exemple de stri sunt: starea iniial, cea
final sau strile de eroare. Cele mai multe stri depind de domeniul
problemei. Strile sunt asociate cu obiectele sistemului. Un eveniment
declaneaz o tranziie de stare care poate conduce la ndeplinirea
unei aciuni de ctre sistem;
Documentul cerinelor (continuare)
Scenarii tipice: Un scenariu este o secven de pai urmai pentru ndeplinirea unui scop.
Cnd sistemul este terminat i aplicaia este disponibil, clientul trebuie s poat utiliza, ntr-o
manier ct mai facil i clar specificat, toate scenariile tipice ale aplicaiei. Scenariile tipice
trebuie s reprezinte majoritatea scenariilor de utilizare ale aplicaiei. Ponderea acestora
variaz de la un sistem la altul, dar 90% se consider o proporie acceptabil. Bineneles c
un sistem cu un singur scenariu de utilizare este relativ simplu de obinut, pe cnd unul cu mii
de scenarii posibile va fi mult mai dificil de analizat. Deseori este invocat regula 80/20: 80%
din funcionalitatea sistemului se realizeaz cu 20% din efortul de munc. Executarea restului
minoritar de funcionalitate necesit marea majoritate a timpului de lucru.
Scenarii atipice: Un scenariu atipic trebuie s fie ndeplinit de sistem numai n cazuri
speciale. Clientul poate s spere, de exemplu, c o eroare neprevzut este un eveniment
atipic. Totui, sistemul trebuie s gestioneze un numr ct mai mare de categorii de erori,
prin tehnici stabilite, precum secvene de tratare a erorilor, excepii, monitorizarea proceselor
etc.;
Cerine incomplete sau nemonotone: O enumerare complet a cerinelor pentru toate
situaiile care pot s apar n condiii de lucru reale nu este posibil. n logica tradiional, o
teorie este definit de o mulime finit de axiome. Teoremele din teoria respectiv sunt
propoziii adevrate. Dac se adaug ulterior noi axiome, teoremele existente rmn valide,
iar noile teoreme dezvoltate sunt adugate teoremelor stabilite. n logica nemonoton,
adugarea de noi axiome poate invalida unele teoreme care au fost demonstrate anterior. O
nou teorie nu mai este o simpl extensie a teoriei vechi, ci o mulime de teoreme noi,
mpreun cu o parte din teoremele vechi. Procesul de stabilire a cerinelor are o natur
iterativ i nemonoton. Mulimea iniial de cerine (axiomele) definete posibilitile
(teoremele) sistemului. Noile cerine pot infirma soluiile vechi. Pe msur ce un sistem
crete n dimensiuni i complexitate, stabilirea cerinelor devine din ce n ce mai dificil, mai
ales cnd procesul de colectare a cerinelor este distribuit, fiind realizat de indivizi cu
specializri diferite.
2. Faza de proiectare
Pe baza cerinelor din faza de analiz, acum se
stabilete arhitectura sistemului: componentele
sistemului, interfeele i modul lor de comportare:
Componentele sunt blocurile de construcie ale
produsului. Acestea pot fi create de la zero sau
reutilizate dintr-o bibliotec de componente.
Componentele rafineaz i captureaz semnificaia
detaliilor din documentul cerinelor.
Interfeele ajut la mbinarea componentelor. O
interfa reprezint grania dintre dou componente,
utilizat pentru comunicarea dintre acestea. Prin
intermediul interfeei, componentele pot interaciona.
Comportamentul, determinat de interfa, reprezint
rspunsul unei componente la stimulii aciunilor altor
componente.
3. Faza de implementare
n aceast faz, sistemul este construit, ori
plecnd 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 mai
rmne loc pentru inovaii i flexibilitate.
Scopul este producerea sistemului propriu-
zis. O problem important este ndeprtarea
erorilor critice.
Tipuri de erori
ntr-un sistem exist trei tipuri de 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 prezena lor nu
afecteaz n mod semnificativ calitatea observat a
sistemului. De obicei aceste erori sunt semnalate n notele
de lansare i au modaliti de ocolire bine cunoscute.
Erori necunoscute: Exist ntotdeauna o probabilitate mare
ca sistemul s conin un numr 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.
4. Faza de testare
Calitatea produsului software este foarte
important.
n multe metodologii ale ingineriei
programrii, faza de testare este o faz
separat, realizat de o echip diferit dup
ce implementarea s-a terminat.
Testele de regresiune
Testele de regresiune (engl. regression test) sunt
colecii de programe care testeaz una sau mai multe
trsturi ale sistemului.
Rezultatele testelor sunt adunate i dac exist erori,
trebuie s se procedeze la corectarea acestora.
Un test de regresiune valid genereaz rezultate
verificate, numite standardul de aur.
Validitatea rezultatului unui test ar trebui s fie
determinat de documentul cerinelor.
n practic, echipa de implementare este
responsabil de interpretarea validitii.
Testele de regresiune (continuare)
Exist patru puncte de interes n testele de regresiune pentru asigurarea calitii.
Testarea intern trateaz implementarea de nivel sczut. Fiecare funcie sau component
este testat de ctre echipa de implementare. Aceste teste se mai numesc teste clear-box
sau white-box, deoarece toate detaliile sunt vizibile pentru test.
Testarea unitilor testeaz o unitate ca un ntreg. Aici se testeaz interaciunea mai multor
funcii, dar numai n cadrul unei singure uniti. Testarea este determinat de arhitectur. De
multe ori sunt necesare aa-numitele schele, adic programe special construite pentru
stabilirea mediului de test. Numai cnd mediul este realizat se poate executa o evaluare
corect. Programul schel stabilete stri i valori pentru structurile de date i asigur funcii
externe fictive. De obicei, programul schel nu are aceeai calitate ca produsul software
testat i adesea este destul de fragil. O schimbare mic n test poate determina schimbri
importante n programul schel. Aceste teste se mai numesc teste black-box deoarece
numai detaliile interfeei sunt vizibile pentru test. Testarea intern i a unitilor poate fi
automatizat cu ajutorul instrumentelor de acoperire (engl. coverage tools), care analizeaz
codul surs i genereaz un test pentru fiecare alternativ a firelor de execuie. Depinde de
programator combinarea acestor teste n cazuri semnificative care s valideze rezultatelor
fiecrui fir de execuie. De obicei, instrumentul de acoperire este utilizat ntr-un mod oarecum
diferit: el urmrete liniile de cod executate ntr-un test i apoi raporteaz procentul din cod
executat n cadrul testului. Dac acoperirea este mare i liniile surs netestate nu prezint
mare importan pentru calitatea general a sistemului, atunci nu mai sunt necesare teste
suplimentare.
Testele de regresiune (continuare)
Testarea aplicaiei testeaz aplicaia ca ntreg i este determinat de scenariile echipei de
analiz. Aplicaia trebuie s execute cu succes toate scenariile pentru a putea fi pus la
dispoziia clientului. Spre deosebire de testarea intern i a unitilor, care se face prin
program, testarea aplicaiei se face de obicei cu scripturi care ruleaz sistemul cu o serie de
parametri i colecteaz rezultatele. n trecut, aceste scripturi erau create manual. n prezent,
exist instrumente care automatizeaz i acest proces. Majoritatea aplicaiilor din zilele
noastre au interfee grafice - GUI). Testarea interfeei grafice pentru asigurarea calitii poate
pune anumite probleme. Cele mai multe interfee, dac nu chiar toate, au bucle de
evenimente, care conin cozi de mesaje de la mouse, tastatur, ferestre etc. Pentru fiecare
eveniment de acest tip sunt asociate coordonatele ecran. Testarea interfeei presupune deci
memorarea tuturor acestor informaii i elaborarea unei modaliti prin care mesajele s fie
trimise din nou aplicaiei, la un moment ulterior.
Testarea la stres determin calitatea aplicaiei n mediul su de execuie. Ideea este crearea
unui mediu mai solicitant dect cel n care aplicaia va rula n mod obinuit. Aceasta este cea
mai dificil i complex categorie de teste. Sistemul este supus unor cerine din ce n ce mai
numeroase, pn cnd acesta cade. Apoi produsul este reparat i testul de stres se repet
pn cnd se atinge un nivel de stres mai ridicat dect nivelul ateptat de pe staia clientului.
Deseori apar aici conflicte ntre teste. Fiecare test funcioneaz corect atunci cnd este fcut
separat. Cnd dou teste sunt rulate n paralel, unul sau ambele teste pot eua. Cauza este
de obicei managementul incorect al accesului la resurse critice. Mai apar i probleme de
memorie, cnd un test i aloc memorie i apoi nu o mai elibereaz. Testul pare s
funcioneze corect, ns dup ce este rulat de mai multe ori, memoria disponibil se reduce,
putndu-se ajunge la blocarea sistemului.