Ingineria programrii Cursul 1

Fazele dezvoltrii unui produs software

1 0 1
2 3 4 2 Ce este ingineria programrii? 2. Fazele ingineriei programrii 2.1. Faza de analiz 2.2. Faza de proiectare 2.3. Faza de implementare 2.4. Faza de testare Concluzii

1. Ce este ingineria programrii?

tiina calculatoarelor este un domeniu relativ nou. Primele calculatoare au fost construite la mijlocul anilor 1940 i de atunci au avut loc dezvoltri spectaculoase. n anul 1946 Goldstine i von Neumann apreciau c1000 de instruciuni reprezint o limit superioar rezonabil pentru complexitatea problemelor ce pot fi concepute ca rezolvabile cu ajutorul calculatorului. Dup ce a prevzut n 1981 c nici un program pentru calculatoare personale nu va necesita vreodat mai mult de 640 KB de memorie RAM, Bill Gates admite n 1995 c lucrurile s-au schimbat n ultimele dou decenii. Urmtoarele exemple ofer o imagine asupra gradului de complexitate la care au ajuns programele n zilele noastre: sistemul de rezervare a biletelor pentru compania aerian KLM coninea, n anul 1992, dou milioane de linii de cod n limbaj de asamblare; o sistemul de operare System V versiunea 4.0 (UNIX) a fost obinut prin compilarea a o 3.700.000 linii de cod; programele scrise pentru naveta spaial NASA au circa 40 de milioane de linii de cod; pentru realizarea sistemului de operare IBM OS360 au fost necesari 5000 de aniom.

Creterea programelor n dimensiune i complexitate a depit cu mult progresele fcute n domeniul tehnicilor de programare. De aceea, programarea a devenit i a rmas mai mult o art dect o meserie. O paralel cu ingineria construciilor este atractiv. Dac dorim s construim o cuc pentru cine, putem s mergem prin grdin, s cutam lemne i cuie, s lum un ciocan i s ncepem s lucrm. Avem anse destul de bune s reuim, mai ales dac suntem ndemnatici. Dac totui nu reuim, putem ncerca a doua zi din nou cu alte lemne i alte cuie. Iar dac cinele nu ncape n cuc, putem putem ncerca a treia zi din nou cu mai multe lemne. Lucrurile stau radical diferit atunci cnd dorim s construim o cas pentru familia

noastr. Atunci va trebui sau s angajm un arhitect care s ne fac un proiect, sau s cumprm un proiect standard de cas. Va trebui s negociem cu o firm de construcii preul, durata de realizare, calitatea finisajelor. Nu ne permitem s riscm economiile familiei pe o construcie care se va drma la a doua rafal de vnt. n plus, dac membrilor familiei nu le place orientarea ferestrelor sau peisajul, nu i putem schimba cu alii (n cel mai ru caz, ne schimb ei pe noi). Cu att mai mult, dac o firm pltete cteva milioane de dolari pentru a ridica un zgrie nori, reprezentanii acesteia vor fi foarte ateni cu cine i n ce condiii vor lucra. Ei vor dori garanii c proiectul este viabil, vor angaja mai multe firme de arhitectur pentru a-l verifica. De asemenea, studii geologice, de fizic a pmntului sau meteorologie vor fi obligatorii. Vor fi folosite cele mai performante materiale i se vor angaja cei mai competeni i cu experien constructori. Eecul nu mai este o opiune pentru contractantul proiectului. tim c inginerii constructori ntocmesc planuri, construiesc machete, studiaz proprietile materialelor folosite i fac rapoarte privind progresul operaiunilor. Construcii de o complexitate foarte mare au fost realizate n acest fel ntr-un mod raional i economic. Inginerii de programe ar trebui s procedeze similar pentru ca dezvoltarea programelor s nu mai fie un proces impredictibil. Pe msur ce complexitatea programelor cretea, la sfritul anilor 60 ncepea s se prefigureze deja o criz a programrii. Un raport prezentat de ctre o companie, n care erau analizate cteva proiecte i stadiile lor de finalizare, a constatat c: 2% din sistemele software contractate au funcionat de la predare; 3% din sistemele software au putut funciona dup cteva modificri; 29% au fost predate dar n-au funcionat niciodat; 19% au fost folosite dar au fost abandonate; 47% au fost pltite dar niciodat predate.

Pentru a contracara aceste tendine, la conferina organizat de comitetul tiinific al NATO n anul 1968, a fost propus termenul de ingineria programrii (engl. software engineering), ntr-un mod oarecum provocator. Se dorea ca arta programrii s mprumute din rigoarea tiinelor inginereti pentru a putea livra programe la timp i n mod economic. Prima definiie dat ingineriei programrii a fost enunat astfel (F. L. Bauer): Ingineria programrii este stabilirea i utilizarea de principii inginereti solide pentru a obine n mod economic programe sigure i care funcioneaz eficient pe maini de calcul reale. n IEEE Standard Glossary of Software Engineering Technology (1983) ingineria programrii este definit dup cum urmeaz: Ingineria programrii reprezint abordarea sistematic a dezvoltrii, funcionrii, ntreinerii, i retragerii din funciune a programelor.

Remarcm c a doua definiie este mai vag dect prima, ntruct nu face referire la cost i la eficien. Mai mult, se pare c experiena n general negativ acumulat a fcut s se renune la formularea principii inginereti solide, ntruct se pare c acestea nu pot fi identificate fr a fi supuse contestaiilor. A doua definiie adaug ns referiri la perioade importante din viaa unui program, ce urmeaz crerii i funcionrii, i anume ntreinerea i retragerea din funcionare. Considerm c ingineria programrii are urmtoarele caracteristici importante: este aplicabil n producerea de programe mari; este o tiin inginereasc; scopul final este ndeplinirea cerinelor clientului.

Programele mici se pot scrie relativ uor, de ctre un singur programator, ntr-o perioad destul de scurt de timp. Un program de 100 de instruciuni este cu siguran un program mic. Nu putem identifica precis grania dintre un program mic i unul mare, ns pe msur ce dimensiunea programului crete, apar provocri noi, calitativ diferite. ntruct un singur sau civa programatori nu pot avea timpul fizic pentru terminarea programului, este necesar crearea uneia sau mai multor echipe de lucru. Este necesar coordonarea i comunicarea ntre echipe. Complexitatea sistemului software i a organizaiei care realizeaz sistemul software devine important, putnd depi capacitatea de nelegere a unui singur individ. Apare ca dezirabil o abordare riguroas a acestor probleme, ce include stilul de lucru, modul de scriere a codului etc. Nerespectarea cerinelor poate avea efecte serioase. Un sistem de livrare a insulinei pentru diabetici poate provoca moartea pacientului dac nu funcioneaz corect. Funcionarea incorect a unui sistem de control al unui satelit poate provoca pagube de milioane de dolari. Un program este fiabil dac funcioneazi continu s funcioneze fr ntreruperi un interval de timp. Aceast noiune exprim de fapt rezistena la condiiile de funcionare. Un sistem de operare trebuie s fie fiabil pentru c trebuie s funcioneze o perioad suficient de lung de timp fr s cad, indiferent de programele care ruleaz pe el, chiar dac nu totdeauna la performane optime. Programul este sigur dac funcioneaz corect, fr operaii nedorite. Un program pentru un automat bancar trebuie s fie sigur, pentru a efectua tranzaciile n mod absolut corect, chiar dac funcionarea sa poate fi ntrerupt din cnd n cnd. Atunci cnd funcioneaz ns, trebuie s funcioneze foarte bine. Programul este sigur dac funcioneaz corect, fr operaii nedorite. Un automat bancar trebuie s fie sigur, pentru a efectua tranzaciile n mod absolut corect, chiar dac funcionarea sa poate fi ntrerupt din cnd n cnd. Atunci cnd funcioneaz ns, trebuie s funcioneze foarte bine. Un program are o eroare (engl. bug) dac nu se comport corect. Se presupune c dezvoltatorul tia ce ar fi trebuit programul s fac, iar comportamentul greit nu este intenionat. Iat cteva erori celebre:

n primii ani n care calculatoarele au fost introduse la staiile de benzin din SUA, consumatorii primeau cecuri pe sume enorme. Faptul era privit n general cu umor i reclamaiile erau rezolvate repede; Sistemul de operare IBM OS360 coninea aproximativ 1.000 de greeli la fiecare nou versiune care ncerca s rezolve greelile din versiunea precedent; Un vehicul de explorare a planetei Venus a fost pierdut deoarece programul primit de pe Pmnt pentru rectificarea orbitei coninea linia 'DO 3 I = 1.3'; instruciunea corect n limbajul FORTRAN ar fi trebuit s conin virgul n loc de punct; n 1979 s-a descoperit o eroare n programele pentru sistemele de rcire n centralele nucleare din SUA; din fericire, nu fusese niciodat nevoie de execuia rutinelor ce conineau erorile; Din cauza unei erori n sistemul de avertizare mpotriva atacului cu rachete balistice, procedurile de contraatac au fost declanate nainte de a se descoperi c a fost o eroare; Racheta Arianne 5 a explodat n iunie 1996 din cauza unei greeli de programare; costurile s-au ridicat la 500 milioane dolari.

Ingineria programrii are ca scop obinerea de sisteme funcionale chiar i atunci cnd teoriile i instrumentele disponibile nu ofer rspuns la toate provocrile ce apar. Inginerii fac lucrurile s mearg, innd seama de restriciile organizaiei n care lucreazi de constrngerile financiare. Problema fundamental a ingineriei programrii este ndeplinirea cerinelor clientului. Aceasta trebuie realizat nu punctual, nu n acest moment, ci ntr-un mod flexibil i pe termen lung. Ingineria programrii se ocup cu toate etapele dezvoltrii programelor, de la extragerea cerinelor de la client pn la ntreinerea i retragerea din folosin a produsului livrat. Pe lng cerinele funcionale, clientul dorete (de obicei) ca produsul final s fie realizat cu costuri de producie ct mai mici. De asemenea, este de dorit ca aceasta s aib performane ct mai bune (uneori direct evaluabile), un cost de ntreinere ct mai mic, s fie livrat la timp, i s fie sigur. Rezumnd, atributele cheie ale unui produs software se refer la: posibilitatea de a putea fi ntreinut: un produs cu un lung ciclu de via este supus deseori modificrilor, de aceea el trebuie foarte bine documentat; fiabilitate: produsul trebuie s se comporte dup cerinele utilizatorului i s nu cad mai mult dect e prevzut n specificaiile sale; eficien: produsul nu trebuie s foloseasc n pierdere resursele sistemului ca memoria sau ciclii procesor; interfaa potrivit pentru utilizator: interfaa trebuie sin seama de capacitatea i cunotinele utilizatorului.

Optimizarea tuturor acestor atribute e dificil deoarece unele se exclud pe altele (o mai bun interfa pentru utilizator poate micora eficiena produsului). n cazurile n care eficiena este critic, acest lucru trebuie specificat explicit nc din faza de preluare a cerinelor utilizatorului, precum i compromisurile pe care ea le implic

privind ceilali factori. Trebuie spus c ingineria programrii nu rezolv toate problemele care apar atunci cnd se scriu programe. Ingineria programrii nu ofer nici teorii. Inginerii fac lucrurile s mearg. Totui, n momentul de fa, ingineria programrii ne poate spune sigur ce s nu facem.

2. Fazele ingineriei programrii

Exist patru faze fundamentale ale metodologiilor ingineriei programrii: analiza (ce dorim s construim); proiectarea (cum vom construi); implementarea (construirea propriu-zis); testarea (asigurarea calitii).

Dei aceste faze se refer n mod special la ciclul de via al produsului software, ele pot fi aplicate i altor stadii de existen prin care trece un program de la natere pn la moarte: lansare, ntreinere, ieire din uz. 2.1. Faza de analiz Aceast faz definete cerinele sistemului, independent de modul n care acestea vor fi ndeplinite. Aici se definete problema pe care clientul dorete s o rezolve. Rezultatul acestei faze este documentul cerinelor, care trebuie s precizeze clar ce trebuie construit. Documentul ncearc s redea 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. Grania dintre descrierile de nivel nalt i cele de nivel sczut nu este foarte bine trasat. Uneori, dac un detaliu tehnic important trebuie specificat, el va aprea n document. Totui, aceasta trebuie s fie excepia i nu regula. Aceste excepii pot fi determinate de necesitatea meninerii compatibilitii cu alte sisteme deja existente, sau a unor anumite opiuni dorite de client, de exemplu utilizarea unui anumit standard sau o constrngere asupra dimensiunilor imaginii aplicaiei, care poate fi destinat unei categorii speciale de utilizatori sau care va rula pe nite sisteme cu o serie de particulariti (monitoare care nu suport rezoluii mari). Faza de analiz poate fi vzut ca o rafinare a detaliilor. Distincia dintre detaliile de nivel nalt i cele de nivel sczut sunt puse mai bine n eviden de abordrile topdown (unde se merge ctre detaliile de nivel sczut) i bottom-up (care tind ctre detaliile de nivel nalt). Documentul cerinelor poate fi realizat ntr-o manier formal, bazat pe logic matematic,sau poate fi exprimat n limbaj natural. n mod tradiional, el descrie obiectele din sistem i aciunile care pot fi realizate cu ajutorul obiectelor. Aici

noiunea de obiect nu trebuie confundat cu obiectul din programarea orientat obiect. Descrierea obiectelor i aciunilor trebuie s fie general i s nu depind de o anumit tehnologie. Desigur, ntr-o abordare POO, descrierile vor lua forma obiectelor i metodelor, ns n alte abordri, obiectele pot fi de exemplu servicii care acceseaz baze de date. n general, documentul cerinelor descrie ontologia proiectului, adic vocabularul de cuvinte cheie (n special construcii substantivale i verbale) care va fi utilizat pentru definirea protocolului specific aplicaiei. Descrierile acestea nu implic proiectarea arhitecturii aplicaiei, ci enumerarea prilor componente i a modului n care acestea se comport. Mai trziu, n faza de proiectare, acestea vor fi transformate n primitive informatice, precum liste, stive, arbori, grafuri, algoritmi i structuri de date. 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; 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 tratarea excepiilor, monitorizarea proceselor etc.; Cerine incomplete sau nemonotone: O enumerare complet a cerinelor pentru toate situaiile care pot aprea 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 iterativi 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.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 elementele constructive ale produsului. Acestea pot fi create de la zero sau reutilizate dintr-o bibliotec de componente. Componentele rafineazi 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.

Documentul de proiectare descrie planul de implementare a cerinelor. Se identific detaliile privind limbajele de programare, mediile de dezvoltare, dimensiunea memoriei, platforma, algoritmii, structurile de date, definiiile de tip globale, interfeele etc. n aceast faz trebuie indicate i prioritile critice pentru implementare. Acestea sugereaz sarcinile care, dac nu sunt executate corect, conduc la eecul sistemului. Totui, chiar dac prioritile critice sunt ndeplinite, acest fapt nu duce automat la succesul sistemului, ns crete nivelul de ncredere c produsul va fi o reuit. Folosind scenariile tipice i atipice, trebuie realizate compromisurile inerente ntre performan i complexitatea implementrii. Analiza performanelor presupune studierea modului n care diferitele arhitecturi conduc la diferite caracteristici de performan pentru fiecare scenariu tipic. n funcie de frecvena de utilizare a scenariilor, fiecare arhitectur va avea avantaje i dezavantaje. Un rspuns rapid la o aciunea a utilizatorului se realizeaz deseori pe baza unor costuri de resurse suplimentare: indeci, managementul cache-ului, calcule predictive etc. Dac o aciune este foarte frecvent, ea trebuie realizat corect i eficient. O aciune mai rar

trebuie de asemenea implementat corect, dar nu este evident care e nivelul de performan necesar n acest caz. O situaie n care o astfel de aciune trebuie implementat cu performane maxime este nchiderea de urgen a unui reactor nuclear. Planul de implementare i planul de test, descrise mai jos, pot fi incluse de asemea n fazele de implementare i respectiv testare. ns unul din scopurile fazei de proiectare este stabilirea unui plan pentru terminarea sistemului, de aceea cele dou planuri au fost incluse n paragraful curent. Planul de implementare stabilete programul dup care se va realiza implementarea i resursele necesare (mediul de dezvoltare, editoarele, compilatoarele etc.). Planul de test definete testele necesare pentru stabilirea calitii sistemului. Dac produsul trece toate testele din planul de test, este declarat terminat. Cu ct testele sunt mai amnunite, cu att este mai mare ncrederea n sistem i deci crete calitatea sa. Un anume test va verifica doar o poriune a sistemului. Acoperirea testului este procentajul din produs verificat prin testare. n mod ideal, o acoperire de 100% ar fi excelent, ns este rareori ndeplinit. De obicei, un test cu o acoperire de 90% este simpl, ns ultimele 10% necesit o perioad de timp semnificativ. De exemplu, s considerm BIOS-ul (Basic Input/Output System) construit de IBM la nceputul anilor 80 n strns legtur cu sistemul de operare DOS (Disk Operating System) al firmei Microsoft. Din raiuni de performan, BIOS-ul a fost plasat ntr-un chip ROM, i deci patch-urile pentru eventualele erori erau imposibile. Astfel, au fost necesare teste cu acoperire de 100%. Codul propriu-zis al BIOS-ului era destul de mic, cteva mii de linii. ns deoarece BIOS-ul are o natur asincron, testul a presupus mai nti crearea unui mediu asincron care s aduc sistemul n starea doriti apoi trebuia generat un eveniment care s declaneze un test. Foarte repede, setul de test a devenit mult mai mare dect BIOS-ul. A aprut astfel problema testrii nsui a mediului de test! n final, o acoperire de 100% a fost atins, dar cu un cost foarte ridicat. O soluie mai ieftin a fost nscrierea BIOS-ului ntr-o combinaie dintre EPROM (Electronic Programmable Read Only Memory) i ROM. Cea mai mare parte a produsului era plasat n ROM, iar patch-urile erau plasate n EPROM. Aceasta a fost abordarea adoptat de Apple pentru Macintosh. n general, este suficient ca testele s cuprind scenariile tipice i atipice, fr s verifice ntregul sistem, cu absolut toate firele de execuie. Acesta poate conine ramificaii interne, erori sau ntreruperi care conduc la fire de execuie netestate. Majoritatea sistemelor sunt pline de bug-uri nedescoperite. De obicei, clientul particip n mod logic la testarea sistemului i semnaleaz erori care vor fi ndeprtate n versiunile ulterioare. 2.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 stie exact ce trebuie s construiasc, chiar dac rmne loc pentru inovaii i flexibilitate. De exemplu, o component poate fi proiectat mai restrns, special pentru un anumit sistem, sau mai general, pentru a

satisface o direcie de reutilizare. Echipa trebuie s gestioneze problemele legate de calitate, performan, biblioteci i debug. Scopul este producerea sistemului propriu-zis. O problem important este ndeprtarea erorilor critice. 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 listate 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. 2.4. Faza de testare Calitatea produsului software este foarte important. Multe companii nu au nvat ns acest lucru i produc sisteme cu funcionalitate extins, dar cu o calitate sczut. Totui, e mai simplu s-i explici clientului de ce lipsete o anumit funcie dect s-i explici de ce produsul nu este performant. Un client satisfcut de calitatea produsului va rmne loial firmei i va atepta noile funcii n versiunile urmtoare. n multe metodologii ale ingineriei programrii, faza de testare este o faz separat, realizat de o echip diferit dup ce implementarea s-a terminat. Motivul este faptul c un programator nu-i poate descoperi foarte uor propriile greeli. O persoan nou care privete codul poate descoperi greeli evidente care scap celui care citete i recitete materialul de multe ori. Din pcate, aceast practic poate determina o atitudine indiferent fa de calitate n echipa de implementare. Tehnicile de testare sunt abordate preponderent din perspectiva productorului sistemului. n mod ideal, i clientul trebuie s joace un rol important n aceast faz. 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, bug-ul 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 cerinelor. n practic, echipa de implementare este responsabil de interpretarea validitii. Testele sunt colectate, mpreun cu rezultatele standardelor de aur, ntr-un pachet de test de regresiune. Pe msur ce dezvoltarea continu, sunt adugate mai multe teste noi, iar testele vechi pot rmne valide sau nu. Dac un test vechi nu mai este valid, rezultatele sale sunt modificate n standardul de aur, pentru a se potrivi ateptrilor curente. Pachetul de test este rulat din nou i genereaz noi rezultate. Acestea sunt comparate cu rezultatele standardelor de aur. Dac sunt diferite, n sistem a aprut o greeal. Greeala este corectati dezvoltarea continu. Acest mecanism detecteaz situaiile cnd starea curent de dezvoltare a produsului

invalideaz o stare existent. Astfel, se previne regresiunea sistemului ntr-o stare de eroare anterioar. 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 interni a unitilor poate fi automatizat cu ajutorul instrumentelor de acoperire (engl. coverage tools), care analizeaz codul sursi genereaz un test pentru fiecare alternativ a firelor 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. 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 interni 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 automatizeazi 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. Asociate cu fiecare eveniment sunt 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 dificili 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 dezaloc. Testul pare s funcioneze corect, ns dup ce este rulat de mai multe ori, memoria disponibil se reduce iar sistemul cade.

3. Concluzii
n acest curs s-a fcut mai nti o introducere n problematica domeniului ingineriei programrii, insistndu-se pe cauzele care au determinat dezvoltarea sa: creterea continu a complexitii sistemelor software. Apoi s-au descris cele patru faze fundamentale ale metodologiilor ingineriei programrii: analiza, proiectarea, implementarea i testarea, necesare pentru realizarea unor sisteme de calitate.