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. 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 top-down (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 s implu 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 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 elementele constructive 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.

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 t est, 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 dorit i 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.

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 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. 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 corectat i 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 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 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 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. 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 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 clientulu i. 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.