Ciclu Prelegeri at(2)

download Ciclu Prelegeri at(2)

of 72

Transcript of Ciclu Prelegeri at(2)

Testarea software o privire de ansamblu Scopul acestei prelegeri este de a face mai clare urmtoarele aspecte ale testrii software: Impactul erorilor software asupra vieii noastre Ce prezint erorile software i care este cauza apariiei lor Cine sunt testorii i care este rolul lor n procesul de elaborare a softului n secolul XXI nu ne putem imagina viaa fr produse software. Majoritatea populaiei sunt posesori de calculatoare personale. Tehnologiile informaionale s-au infiltrat n toate domeniile activitii umane. Mergnd la cumprturi putem primi mpreun cu o cutie de margarin sau de cereale un CD-ROM gratis cu un joc video sau cu muzic. Muli dintre noi nu pot petrece o zi fr Internet. Aplicaiile software au nlocuit funcionarii n diverse ramuri, astfel avnd un impact enorm asupra vieii i activitii umane. Pentru a asigura calitatea i sigurana aplicaiilor software se pune un accent deosebit pe testarea acestor din urm. Testarea de software a devenit o profesie tehnic foarte important. Urmtoare exemple pot ilustra foarte bine necesitatea testrii software. Dezvoltarea aplicaiilor software implic o serie de activiti, n care posibilitatea erorii umane este foarte ridicat. Testarea este un element cheie n procesul de dezvoltare, i reprezint o ultim recapitulare a specificaiilor, design-ului i codului. Un studiu al Institutului de Testare Software (Software Testing Institute), relev urmtoarele : Testorii implicai n industria software sunt mai muli dect n orice alt industrie (43%) Testarea software este executat mai degrab n cadrul departamentelor de programare (44%), dect n cadrul unui departament orientat exclusiv pe testare (39%) Doar 4% din productorii software supui acestui studiu prevd nfiinarea unui departament orientat exclusiv pe testare.

Testarea software, prin definiie, urmrete focalizarea pe procesul de identificare a posibilelor erori de program, erori care ar putea avea un impact negativ asupra produsului, i prin urmare asupra clienilor. Satisfacia clienilor este cheia reuitei oricrei afaceri, i asta nu mai este o necunoscut. Aceasta presupune c produsul oferit s fie de calitate ridicat, i s nu produc erori n timpul utilizrii de ctre client. Calitatea ridicat nu poate fi obinut doar cu ajutorul unei echipe de programatori de excepie. Este deja bine tiut faptul c orict de bine pus la punct ar fi produsul dezvoltat, acesta conine totui erori. Implicarea testrii n procesul de producie aduce urmtoarele avantaje: Organizare disciplinat a procesului/dezvoltare i testare matur a procesului de producie. Responsabilii i Managerii de proiect induc o linie bine trasat n scopul urmririi exacte a procesului de producie. nelegerea importanei calitii n procesul de producie, calitate care poate fi obinut doar n urma unei testri profesionale. Impunerea unor reguli i standarde care n timp vor duce la livrarea unor produse de cea mai nalt calitate, i a unor soluii de cea mai nalt calitate pentru clienii organizaiei Unele dintre cele mai scandaloase erori software 1. Aparat medical pentru terapie cu radiaie Therac-25 -6 accidente cu mori i rni grave (1985-87, SUA, Canada) Cauza direct: erori in programul de control Analiz retrospectiv [Leveson 1995]: ncredere excesiv n software (n analiza produsului) fiabilitate siguran 2. Racheta Ariane 5 -Autodistrugere dup o defeciune la 40 s de la lansare (1996) Cauza: conversia 64-bit float 16-bit int genereaz o excepie de depire netratat n programul ADA Cost: 500 milioane dolari (racheta), 7 miliarde dolari (proiectul) Analiz retrospectiv

1

principala cauz: reutilizarea nejudicioasa de software cod preluat de la Ariane 4, fr reanalizare corespunztoare: 3. Eroarea din procesorul Intel Pentium Eroare n unitatea de mprire cu virgula mobila, 1994 Cost: cca. 400 milioane dolari Analiz ulterioar Circuitul putea fi verificat formal -demonstrare automat de teoreme [Clarke, German & Zhao] -cu structuri speciale de date pentru reprezentarea nmulirii/mpririi [Bryant & Chen] Accentul a fost pus pe componente mai complexe (unitatea de execuie, coerena memoriei cache) Eroarea software Din exemplele de mai sus se poate vedea impactul erorilor software asupra noastr. Erorile pot fi catastrofice, cnd provoac pierderi de viei omeneti sau pot fi nite inconveniene dac este vorba de exemplu de un joc pe calculator. Majoritatea erorilor sunt mult mai complicate dect par la prima vedere. Sunt ns i erori simple, subtile despre care nu se poate cu siguran de spus, dac este o eroare adevrat sau nu. Un testor bun trebuie s poat folosi diferii termeni pentru a descrie ce s-a ntmplat cnd a euat softul. n continuare este dat o list cu termenii folosii: 1. Defect (Defect) 2. Excepie (Variance) 3. Eec (Failure) 4. Problem (Problem) 5. Eroare (Error) 6. Incident (Incident) 7. Anomalie (Anomaly) 8. Inconsisten (Inconsistency) 9. Aparen (Feature) 10. Neajuns (Fault) 11. Bug Care dintre aceti termeni vor fi folosii pentru descrierea erorilor ine doar de cultura companiei i de stadiul la care a fost descoperit eroarea. Dac ne uitm n dicionar, observm c toate aceste cuvinte se deosebesc foarte puii, unele fiind chiar sinonime De obicei orice eroare software este numit bug, ns acest termen nu poate fi acceptat cnd se completeaz diferite rapoarte despre testarea softului. n cadrul acestui curs v-om folosi termenul: eroare software. nainte de a formula definiia erorii software avem nevoie de un termen de reper: specificaia produsului software. Specificaia produsului este un acord al echipei de dezvoltare software, n care este definit: cum ar trebui el s fie, cum este ntr-adevr, ce trebuie s fac i ce nu trebuie s fac acest produs. Definiie. Erorile software apar cnd una sau mai multe dintre urmtoarele afirmaii sunt adevrate: 1. Softul nu execut ceva ce specificaiile spun c trebuie s execute. 2. Softul execut ceva ce specificaiile spun c nu trebuie s execute. 3. Softul execut ceva ce n specificaii nu este menionat. 4. Softul nu execut ceva ce specificaiile nu menioneaz dar ar trebui s menioneze. 5. Softul este greu de neles, greu de folosit, lent sau se vede c nu a fost proiectat corect. Aceast definiie a erorilor acoper o mare parte de probleme, de acea testorii folosesc aceste reguli pentru a identifica diferite tipuri de probleme n aplicaiile software. Cauzele i costul erorilor Poate fi surprinztor, dar cel mai mic procent de erori sunt cele provenite de programare. Cele mai multe erori sunt cauzate de deficienele din specificaie ( 60%), uneori specificaia pur i simplu nu este scris. Alte motive specificaia nu este descris n detaliu, a fost modificat constant i nu a fost adus la cunotina ntregii echipe de dezvoltare. Alt surs de erori este etapa de proiectare ( 30%), cauzele apariiei erorilor aici sunt similare cu cele din specificaii ( modificri, comunicarea rea etc.). Relativ puine (uneori sub 15%) sunt erorile directe de programare. Ele pot aprea din cauza complexitii softului, a documentaiei insuficiente (n special n

2

codul care a fost modificat), a timpului insuficient planificat pentru programare sau a erorilor de proiectare. Uneori programatorii nu neleg corect cerinele ori cerinele nu sunt formulate bine. Costul erorilor Erorile depistate i fixate in faza de scriere a specificaiilor nu cost practic nimic, cele care nu au fost depistate nainte de faza implementrii i testrii pot ajunge la sute de dolari. Dac ns clientul a gsit defecte dup livrarea i lansarea produsului, costul erorilor poate crete de la mii la milioane de dolari. Deci costul erorilor poate crete exponenial avansnd n procesul de producie de la specificare pn dup livrare. Locul testorului n procesul de elaborare a softului Definiia 1. Scopul testorului este de a depista erorile softului. Se poate rula programul i confirma c el funcioneaz, fr a pune accentul pe detectarea erorilor. Dac se testeaz doar componentele funcionale, pot fi omise multe erori. n cazul n care nu au fost depistate erorile la timp clientul risc s piard muli bani. Deci testorul nu trebuie s se concentreze doar pe detectarea erorilor, el trebuie s se gndeasc cum s fac acest lucru ct mai curnd posibil. De aici avem: Definiia 2. Scopul testorului este de a depista erorile softului ct mai devreme posibil. Dar nici aceasta nu este suficient. Testorul este ochiul clientului, primul care ncearc produsul i el dorete calitate. Deci: Definiia 3. Scopul testorului este de a depista erorile softului ct mai devreme posibil i se asigur c ele au fost fixate i luate msuri n legtur cu aceasta. Aceast definiie final este foarte important. La fel este important faptul c fixarea defectelor nu implic neaprat corectarea softului. n legtur cu aceasta poate fi adugat un comentariu n manualul utilizatorului sau poate fi fcut un seminar special cu utilizatorii. Calitile unui testor bun Cum am menionat mai sus testarea software este o profesie tehnic. Testorii trebuie implicai n procesul de dezvoltare software nc din fazele incipiente, pentru a asigura calitatea bun a produsului soft. Pentru a fi angajat i preuit un testor trebuie s posede urmtoarele caliti: 1. Trebuie s fie un explorator. Testorul software este cel care experimenteaz cu soft-uri noi ncercndu-le funcionalitile. 2. Trebuie s fie nenduplecai. Testorul software este mereu n cutare. El caut erori prin toate cile posibile. 3. Trebuie s fie creativ. Testarea superficial nu este suficient pentru testor. El trebuie s gndeasc creativ i s intuiasc unde poate gsi erori. 4. Trebuie s fie perfecionist. Testorii tind spre perfeciune, cu toate c neleg c n industria software ea este de neatins. 5. Trebuie s posede o bun judecat. Ei trebuie s decid ce trebuie de testat, ct timp i dac o oarecare problem este ntr-adevr o eroare sau nu. 6. Trebuie s aib tact i s fie bun diplomat. El este cel care aduce vetile rele programatorului. 7. Trebuie s fie perseverent. Erorile gsite nu totdeauna sunt vizibile i uneori sunt greu de descris. Testorul trebuie s-i poat expune punctul de vedere i s poat demonstra necesitatea fixrii i posibil corectrii erorilor gsite. Un testor nu trebuie s fie numaidect un programator, cunotinele din diferite domenii (economie, nvmnt, aviaie, medicin, culinrie , construcii ) pentru care sunt dezvoltate produse software vor fi de un imens ajutor pentru un testor. Psihologia testrii Testarea software este o disciplin tehnic, ns ea implic importante consideraii economice i psihologice. Ideal ar fi testarea tuturor combinaiilor posibile ale intrrilor i ieirilor programului. n cele mai multe cazuri ns aceasta este imposibil, deoarece chiar i un program simplu poate avea sute i chiar mii de combinaii ale intrrilor i ieirilor. Crearea cazurilor de test pentru toate aceste combinaii este destul de nepractic, pentru

3

aceasta este nevoie de resurse umane i financiare enorme, mai mult ca att procesul poate dura timp ndelungat. Plus la aceasta mai trebuie de luat n consideraie i viziunea testorului fa de crearea unui test de succes. Atitudinea testorului fa de produs este de asemenea foarte important. Pentru ca procesul de testare s nu se transforme ntr-o goan haotic dup erori este benefic de respectat unele principii ale testrii pe care le-a artat practica testrii i timpul i de cunoscut nite tehnici de testare, pentru a sistematiza acest proces. Definiii ale testrii O cauz important a calitii proaste a produselor soft este definirea incorect a procesului de testare. De exemplu se spune c: 1. Testarea e procesul de a demonstra c programul nu are erori (or acest lucru este imposibil folosind doar testarea) sau 2. Scopul testrii este de a arta c produsul este performant i funcioneaz corect sau 3. Testarea este procesul prin care se demonstreaz c produsul face ceea ce trebuie s fac Aceste definiii nu sunt rele doar c sunt pe cam pe dos. Este cunoscut c aciunea de testare a unui program se deosebete de celelalte faze prin care acesta trece (specificare, proiectare, programare) prin caracterul su n aparen "demolator". ntr-adevr, n timp ce alte faze au o esen constructiv, testarea are n aparen un caracter mai degrab distructiv, deoarece scopul acestei aciuni este de a pune n eviden proasta funcionare a produsului obinut. Din punct de vedere psihologic programatorul trebuie s adopte n aceasta etap o atitudine "dumnoas" fa de creaia sa i s-i expun defectele. Esena procesului este fr ndoial tot constructiv, scopul su fiind de a pune n operare real un produs la parametrii prevzui. Deci cele mai adecvate definiii ale testrii ar fi: 1. Testarea e procesul prin care se execut un program cu intenia de a gsi erori (Myers) sau mai mult ca att: 2. Testarea este utilizata pentru a semnala prezena defectelor unui program, fr a garanta absena lor( Dijkstra).

1. Un test de succes (test concludent) e acela care descoper (i localizeaz) o eroare.Principii ale testrii (Myers) Continund ideea acestei teme observm c cea mai important problem n testare este cea psihologic. Reieind din aceasta pot fi formulate nite principii ale testrii. Principiul 1: Un caz de test trebuie sa defineasc neaprat ieirea sau rezultatul dorit. Formularea acestui principiu este bazat pe psihologia uman. Dac rezultatul corect nu este predefinit , ansa c orice rezultat va fi interpretat ca corect este destul de mare. Avem aici fenomenul Vedem ceea ce dorim s vedem. Cu alte cuvinte noi subcontient ateptm rezultatul corect. O cale de combatere a acestui fenomen este ncurajarea examinrii detaliate a tuturor ieirilor. Conform acestui principiu un caz de test trebuie s fie compus din: 1. Descrierea instanei unui program. 2. Descrierea precis a rezultatului sau a ieirii programului pentru aceast instan. Principiul 2: Un programator ar trebui sa evite sa-i testeze propriul program. Orice scriitor tir, sau cel puin trebuie s tir, c este o idee nu prea bun s-i corecteze i s-i redacteze singur manuscrisele. Iari este vorba de un fenomen psihologic. Autorul nu dorete s descopere erori n propria lucrare. Dup ce programatorul a lucrat constructiv la designul i scrierea programului este foarte dificil s ia o atitudine distructiv fa de propria oper. Plus la aceasta programatorul subcontient nu dorete s gseasc erori de teama criticii din partea clientului sau beneficiarului. n afar de aceast problem psihologic mai este una important: Programul poate avea erori din cauza nenelegerii de ctre programator a sarcinii puse sau a specificaiei produsului. Astfel programatorul va transmite aceleai nenelegeri i testelor executate. Aceasta nu nseamn c programatorul nu trebuie sub nici o form s-i testeze propriul program, ns testarea de ctre o alt

4

persoan va fi mai eficient. Acest principiu nu poate fi aplicat i depanrii. Acest proces este mai bine efectuat de ctre programatorul care a codificat programul. Principiul 3: Companiile de programare nu ar trebui s-i testeze produsele proprii. Argumentele acestui principiu sunt similare cu cele de la principiul precedent. Aici pot avea loc probleme de planificare: produsul trebuie livrat la timp, orice ntrziere cost bani. Este destul de dificil ca o companie s fie obiectiv fa de calitatea propriului produs. Grupul de testori ar trebui s fie altul dect cel de dezvoltare, iar ntreinerea unui departament de testare este destul de costisitoare i nu orice companie poat s-i permit aceasta. Principiul 4: Fiecare rezultat al testului trebuie examinat foarte minuios. Acesta este probabil cel mai evident principiu. Ct de minuios nu ar fi fcut testarea este posibil s se strecoare diferite erori. Erorile depistate ntr-un stagiu tardiv de testare deseori se dovedesc a fi cele omise n stadii incipiente de testare. Principiul 5: Cazurile de test trebuie s fie scrise att pentru condiii de intrare valide ct i pentru cele invalide i neateptate. Este normal tendina de testa produsul pentru date valide de intrare, neglijnd datele incorecte. Este ns forte important comportamentul produsului cnd sunt introduse date incorecte sau ilegale. Acest principiu nu poate fi neglijat atunci cnd sunt elaborate cazurile de test. Principiul 6: Trebuie testat c produsul face ce trebuie i nu face ce nu trebuie. Putem considera acest principiu ca un corolar al principiului precedent. Programele trebuie supuse i examinate pentru efecte neateptate. Mai ales astfel de teste trebuie elaborate pentru produsele cu destinaie financiar. Principiul 7: Trebuie de pstrat i refolosit cazurile de test. Acest principiu este important i este respectat de specialitii n testare. Orice produs poate fi mbuntit i dac dorim s vedem dac schimbrile nu au avut un efect negativ asupra altor componente ale sistemului atunci este bine de testa cu testele vechi noul produs. Astfel se testeaz integritatea i funcionalitatea produsului. Refolosirea cazurilor de test este binevenit i atunci cnd au fost corectate unele erori deja gsite. Pstrarea testelor i refolosirea lor dup modificri n produs poart denumirea de testare regresiv (regression testing). Principiul 8: Nu se planific procesul de testare presupunnd c nu vor fi gsite erori. Este o greeal a managerilor de proiect cnd se folosete o definiie incorect a testrii. De exemplu: Testarea e procesul prin care se demonstreaz c produsul este performant i funcioneaz corect n locul Testarea e procesul prin care se execut un program cu intenia de a gsi erori Principiul 9: Probabilitatea de a gsi erori ntr-un fragment de cod este proporional cu numrul de erori deja gsite. Dac avem de exemplu un program din dou module A i B i n modulul A au fost gsite cinci erori iar n B numai una, i dac modulul A nu a fost supus intenionat unui test riguros, atunci acest principiu ne spune c probabilitatea c n modulul A vor fi gsite mai multe erori dect n modulul B este destul de mare. La prima vedere acest principiu nu are prea mult sens, ns este un fenomen prezent n majoritatea programelor. Principiul 10:Testarea este un lucru extrem de creativ i intelectual. Este probabil adevrat c creativitatea cerut la testarea produselor serioase depete creativitatea cerut n proiectarea acestora. Este clar c este imposibil de testat un produs suficient pentru a demonstra absena erorilor n acest produs. Metodologia pe care o vom studia n cadrul cursului va fi de un mare folos la elaborarea unui numr rezonabil de cazuri de test, ns aceast metodologie cere un nivel nalt de creativitate a testorului. Axiomele testrii (Patton) 1. Este imposibil testarea complet a unui program. Aceast axiom este adevrat din urmtoarele motive: Numrul intrrilor posibile este foarte mare. Numrul rezultatelor posibile este foarte mare. Numrul drumurilor ntr-un program este foarte mare. Specificaiile programului sunt subiective. Exemplul calculatorului

5

2. Testarea software este un exerciiu de apreciere a riscurilor. Dac ai luat decizia s nu testezi toate scenariile de test posibile, atunci i-ai asumat un oarecare risc. De exemplu, dac ai decis s nu testezi n calculator cazul 1024+1024=2048, iar programatorul accidental a greit aceast combinaie, nimerind acest produs la consumator, care este un contabil i a gsit aceast eroare, ce se va ntmpla n aa caz? Aceast eroare va costa foarte mult. Sun destul de urt aceasta, dar pe de alt parte este imposibil de testat tot, dar dac nu se testeaz totul este posibil s se strecoare diferite erori. Ce se poate de fcut n astfel de cazuri? Un element important este c testorul trebuie s nvee cum se poate reduce domeniul imens a datelor de intrare pn la nite seturi realizabile de teste i cum s ia decizii ce este important de testat i ce nu este. 3. Testarea nu poate arta c produsul nu are erori. Testarea poate arta c erorile exist ntr-un produs, dar nu poate arta c ele nu sunt n el. Pot fi perfecionate testele, pot fi gsite i raportate erorile, dar nu este posibil de garantat c erori n produs nu se vor mai gsi. Unicul lucru care se poate de fcut este de a continua testarea i posibil se vor mai gsi erori. 4. Cu ct mai multe erori gseti, cu att mai multe sunt. Erorile au tendina de a se gsi n grupuri. Dac ai gsit una, poi fi sigur c n vecintatea ei vor mai fi i altele. Deseori, trece destul de mult timp pn cnd testerul gsete o eroare. ns dac a fost gsit una el o va gsi i pe a doua i pe a treia etc. Exist motive serioase pentru aceasta: Programatorul a avut o zi grea. Codul scris ntr-o zi poate fi perfect, iar unul scris n alt zi poate avea o sumedenie de erori. O eroare gsit ne poate spune c mai sunt i altele prin zon. Programatorii foarte des fac aceleai erori. Un programator care a fcut aceiai greeal de mai multe ori o va repeta iar i iar. Fiecare eroare este ca un aisberg. Deseori proiectul i arhitectura software au probleme serioase. Testerul ar trebui s le depisteze pe acestea n primul rnd, dar de obicei ele sunt detectate dup ce au provocat multe probleme serioase. 5. Paradoxul pesticidelor: erorile devin rezistente la teste Paradoxul pesticidelor n testare descrie fenomenul: cu ct mai mult testezi cu att mai imun fa de teste devine softul. Analogic cu insectele i pesticidele: dac sunt aplicate aceleai pesticide de fiecare dat insectele devin imune la ele i chiar mai puternice dect au fost. Pentru a gsi erori noi e nevoie de teste noi. 6. Nu toate erorile gsite vor fi corectate. O realitate trist atestrii este, c dup ce s-a lucrat destul de mul i greu pentru a depista erorile, nu toate din ele sunt fixate i corectate. eii echipelor de testare trebuie s fac compromisuri i s ia decizii bazate pe riscuri n ceea ce privete fixarea anumitor erori. Acest lucru are motive serioase: Nu este suficient timp pentru aceasta. ntr-adevr nu este o eroare. Este prea riscant de fixat( fixarea ei poate provoca mai multe erori). Nu are nici o valoare. Procesul de luare a deciziilor fa de fixarea erorilor i implic pe testori, managerii de proiect i pe programatori i fiecare are opinia lui fa de eroarea respectiv ns nimeni nu tie cine are dreptate, aa c decizia luat este bazat pe anumite riscuri (exemplu Procesorul Intel Pentium) 7. E greu de spus cnd o eroare e o eroare ... n afar de acele afirmaii care alctuiesc definiia erorii testorii pot apela i la opinia altor persoane poate chiar a clientului, ce reprezint pentru el o eroare i i poate formula propria definiie a erorii. 8. Specificaiile produselor nu sunt niciodat definitive. Industria software se dezvolt foarte rapid. n acelai timp produsele soft devin tot mai complexe, iar termenii de predare mai scurte din cauza concurenei. Aceste dou aspecte sunt n conflict permanent i rezultatul conflictului este schimbarea constant a specificaiilor. Un alt motiv este perfecionarea unui product care a fost scos pe pia cu ceva timp n urm specificaiile au fost rescrise, dar nu conin i funcionalitile vechi ale produsului. 9. Testorii nu sunt cei mai populari membri ai echipei de proiect. Ne amintim de scopul unui testor. Cteva sfaturi utile pentru testori: Gsii erorile ct mai devreme. Toi vor fi mulumii dac o s gsii erorile serioase cu dou luni, dar nu cu o zi nainte de sfritul perioadei de testare.

6

Temperai-v entuziasmul. Ct de bucuros nu ai fi c ai gsit o eroare critic, fii diplomat cnd i-o spui programatorului.

Etapele dezvoltrii programelor Cnd pornim la dezvoltarea unui program avem nevoie de: nelegere clar a ceea ce se cere; un set de metode i instrumente de lucru; un plan de aciune. Planul de aciune se numete metodologie de dezvoltare. Dezvoltarea unui anumit program const ntr-un set de pai ce se fac pentru a-l realiza. Lund n considerare tipul pailor ce se efectueaz se creeaz un model de lucru, ce poate fi aplicat unei serii mai largi de proiecte. Acesta este motivul pentru care planul de aciune este numit model: el poate fi privit ca un ablon al dezvoltrii de programe. n timpul dezvoltrii programelor s-a constatat c exist anumite tipuri de activiti care trebuie fcute la un moment dat: Analiza cerinelor: Se stabilete ce anume vrea clientul ca programul s fac. Scopul este nregistrarea cerinelor ntr-o manier ct mai clar i mai fidel. Claritatea se refer la lipsa ambiguitii iar fidelitatea la nregistrarea ct mai exact (posibil cuvnt cu cuvnt); Proiectarea arhitectural: Din motive de complexitate, programele mari nu pot fi concepute i implementate ca o singur bucat. Programul va trebui construit aadar din module sau componente. Proiectarea arhitectural mparte sistemul ntr-un numr de module mai mici i mai simple, care pot fi abordate individual; Proiectarea detaliat: Se realizeaz proiectarea fiecrui modul al aplicaiei, n cele mai mici detalii; Scrierea codului: Proiectul detaliat este transpus ntr-un limbaj de programare. De obicei, aceasta se realizeaz modular, pe structura rezultat la proiectarea arhitectural; Integrarea componentelor: Modulele programului sunt combinate n produsul final. Rezultatul este sistemul complet. n modelul numit big-bang componentele sunt dezvoltate i testate individual, dup care sunt integrate n sistemul final. Avnd n vedere c funcionarea corect a componentelor individuale a fost testat, integrarea ar trebui s fie o formalitate. Din pcate, componentele nu pot fi testate exhaustiv, iar cnd acestea lucreaz mpreun pot s apar situaii pe care o anumit component nu le-a ntlnit n procesul de testare sau conflicte ntre anumite componente (de exemplu, conflicte de partajare a resurselor). S-a constatat c atunci cnd se aplic acest model, timpul de testare explodeaz, proiectul devenind greu de controlat; aceasta justific denumirea de big-bang. Modelul incremental propune crearea unui nucleu al aplicaiei i integrarea a cte o component la un moment dat, urmat imediat de testarea sistemului obinut. Astfel, se poate determina mai uor unde anume apare o problema n sistem. Acest tip de integrare ofer de obicei rezultate mai bune dect modelul big-bang; Validarea: n procesul de validare ne asigurm c programul ndeplinete cerinele utilizatorului. ntrebarea la care rspundem este: construim produsul corect? Un exemplu de validare este testul de acceptare, n care produsul este prezentat clientului. Clientul spune dac este mulumit cu produsul sau dac mai trebuie efectuate modificri; Verificarea: n procesul de verificare ne asigurm c programul este stabil i c funcioneaz corect din punctul de vedere al dezvoltatorilor. ntrebarea la care rspundem este: construim corect produsul? ntreinerea: Dup ce programul este livrat clientului, mai devreme sau mai trziu sunt descoperite defecte sau erori ce trebuie reparate. De asemenea, pot aprea schimbri n specificaiile utilizatorilor, care vor diverse mbuntiri. ntreinerea const n gestionarea acestor probleme. Se poate constata uor c aceste activiti sunt n strns legtur cu cele patru faze ale ingineriei programrii: analiza, proiectarea, implementarea i testarea. Metodologii generice n acest paragraf, vor fi prezentate trei categorii importante de metodologii: secvenial, ciclic i hibrid. n metodologia secvenial (cascad), cele patru faze urmeaz una alteia ntr-o modalitate serial. n metodologia ciclic (spiral), fazele sunt dispuse n cicluri care i genereaz incremental contribuiile la sistemul final. Metodologia hibrid (ecluz) combin progresul constant al metodologiei secveniale cu incrementele iterative ale metodologiei ciclice. Metodologia secvenial n metodologia secvenial, cunoscut i sub numele de metodologia cascad, are loc mai nti faza de analiz, apoi cea de proiectare, urmat de cea de implementare, iar n final se realizeaz testarea. Echipele care se ocup de fiecare faz pot fi diferite, iar la fiecare tranziie de faz poate fi necesar o decizie managerial.

7

Figura 1. Metodologia secvenial Avantaje Metodologia secvenial este potrivit cnd complexitatea sistemului este mic iar cerinele sunt statice. Ea spune c mai nti trebuie s ne gndim ce trebuie construit, apoi s stabilim un plan de lucru i apoi s realizm proiectul, innd cont de standardele de calitate. De asemenea, se aliniaz metodelor de inginerie hardware. Foreaz meninerea unei discipline de lucru care evit presiunea scrierii codului nainte de a cunoate precis ce produs va trebui de fapt construit. De multe ori, echipa de implementare se afl n situaia de a programa nainte de finalizarea analizei, ceea ce conduce inevitabil la descoperirea unor pri de cod inutile sau care contribuie foarte puin (poate chiar i ineficient) la funcionalitatea produsului final. Totui, acest cod devine un balast foarte costisitor: dificil de abandonat i greu de schimbat. Aceast metodologie foreaz analiza i planificarea naintea implementrii, o practic foarte nimerit n multe situaii. Un mare numr de sisteme software din trecut au fost construite cu o metodologie secvenial. Multe companii i datoreaz succesul acestui mod de realizare a programelor. Trebuie spus totui i c presiunea de schimbare din partea surselor externe era destul de limitat la momentul respectiv. Dezavantaje Unul din principalele dezavantaje ale metodologiei secveniale este faptul c acord o foarte mare importan fazei de analiz. Membrii echipei de analiz ar trebui s fie probabil clarvztori ca s poat defini toate detaliile aplicaiei nc de la nceput. Greelile nu sunt permise, deoarece nu exist un proces de corectare a erorilor dup lansarea cerinelor finale. Nu exist nici feedback de la echipa de implementare n ceea ce privete complexitatea codului corespunztor unei anumite cerine. O cerin simplu de formulat poate crete considerabil complexitatea implementrii. n unele cazuri, este posibil s fie chiar imposibil de implementat cu tehnologia actual. Dac echipa de analiz ar ti c o cerin nu poate fi implementat, ei ar putea-o schimba cu o cerin diferit care s satisfac cele mai multe dintre necesiti i care s fie mai uor de efectuat. Comunicarea dintre echipe este o problem: cele patru echipe pot fi diferite iar comunicarea dintre ele este limitat. Modul principal de comunicare sunt documentele realizate de o echip i trimise urmtoarei echipe cu foarte puin feedback. Echipa de analiz nu poate avea toate informaiile privitoare la calitate, performan i motivare. ntr-o industrie n continu micare, metodologia secvenial poate produce sisteme care, la vremea lansrii, s fie deja nvechite. Accentul att de mare pus pe planificare nu poate determina rspunsuri suficient de rapide la schimbare. Ce se ntmpl dac clientul i schimb cerinele dup terminarea fazei de analiz? Acest lucru se ntmpl ns frecvent; dup ce clientul vede prototipul produsului, el i poate schimba unele cerine. Metodologia ciclic Metodologia ciclic, cunoscut i sub numele de metodologia spiral, ncearc s rezolve unele din problemele metodologiei secveniale. i aceast metodologie are patru faze, ns n fiecare faz se consum un timp mai scurt, dup care urmeaz mai multe iteraii prin toate fazele. Ideea este de fapt urmtoarea: gndete un pic, planific un pic, implementeaz un pic, testeaz un pic i apoi ia-o de la capt. n mod ideal, fiecrei faze trebuie s i se acorde atenie i importan egale. Documentele de la fiecare faz i schimb treptat structura i coninutul, la fiecare ciclu sau iteraie. Pe msur ce procesul nainteaz, sunt generate din ce n ce mai multe detalii. n final, dup cteva cicluri, sistemul este complet i gata de lansare. Procesul poate ns continua pentru lansarea mai multor versiuni ale produsului.

Figura 2. Metodologia ciclic Documentele de la fiecare faz i schimb treptat structura i coninutul, la fiecare ciclu sau iteraie. Pe msur ce procesul nainteaz, sunt generate din ce n ce mai multe detalii. n final, dup cteva cicluri, sistemul este complet i gata de lansare. Procesul poate ns continua pentru lansarea mai multor versiuni ale produsului. Avantaje Metodologia ciclic se bazeaz pe ideea perfecionrii incrementale ale metodologiei secveniale. Permite feedback-ul de la fiecare echip n ceea ce privete complexitatea cerinelor. Exist etape n care pot fi corectate eventualele greeli privind cerinele. Clientul poate arunca o privire asupra rezultatului i poate oferi informaii importante mai ales n faza dinaintea lansrii produsului. Echipa de implementare poate trimite echipei de analiz

8

informaii privind performanele i viabilitatea sistemului. Acesta se poate adapta mai bine progresului tehnologic: pe msur ce apar noi soluii, ele pot fi ncorporate n arhitectura produsului. Dezavantaje Metodologia ciclic nu are nici o modalitate de supraveghere care s controleze oscilaiile de la un ciclu la altul. n aceast situaie, fiecare ciclu produce un efort mai mare de munc pentru ciclul urmtor, ceea ce ncarc orarul planificat i poate duce la eliminarea unor funcii sau la o calitate sczut. Lungimea sau numrul de cicluri poate crete foarte mult. De vreme ce nu exist constrngeri asupra echipei de analiz s fac lucrurile cum trebuie de prima dat, acest fapt duce la scderea responsabilitii. Echipa de implementare poate primi sarcini la care ulterior se va renuna. Echipa de proiectare nu are o viziune global asupra produsului i deci nu poate realiza o arhitectur complet. Nu exist termene limit precise. Ciclurile continu fr o condiie clar de terminare. Echipa de implementare poate fi pus n situaia nedorit n care arhitectura i cerinele sistemului sunt n permanen schimbare. Metodologia hibrid ecluz Metodologia ecluz (engl. watersluice), propus de Ronald LeRoi Burback (1998), separ aspectele cele mai importante ale procesului de dezvoltare a unui produs software de detaliile mai puin semnificative i se concentreaz pe rezolvarea primelor. Pe msur ce procesul continu, detaliile din ce n ce mai fine sunt rafinate, pn cnd produsul poate fi lansat. Aceast metodologie hibrid preia natura iterativ a metodologiei spiral, la care adaug progresul sigur al metodologiei cascad.

Figura 3. Metodologia hibrid ecluz La nceput, ntr-un proces iterativ, fazele de analiz, proiectare, implementare i testare sunt mprite n mai multe sarcini poteniale, fiecruia atribuindu-i-se o prioritate care reflect beneficiul ndeplinirii sarcinii respective pentru scopul final. La fiecare moment se execut sarcina cu prioritate maxim. n funcie de dimensiunea echipelor, mai multe sarcini pot fi realizate n paralel. Sarcinile rmase, de prioritate minim, sunt pstrate pentru examinare ulterioar. Descompunerea problemei este foarte important. Cu ct descompunerea i stabilirea prioritilor sunt mai bune, cu att mai eficient este metodologia. Pe msur ce sarcinile stabilite sunt ndeplinite, noi sarcini pot fi descoperite. Acestea sunt adugate sarcinilor rmase nesoluionate i se reatribuie prioritile. Procesul continu pn cnd produsul este gata de lansare. Prioritile se stabilesc pe baza unei funcii de prioritate, care depinde att de domeniul problemei i de normele firmei. Ea trebuie s realizeze un compromis ntre cantitate i calitate, ntre funcionalitate i constrngerile privind resursele, ntre ateptri i realitate. Toate funciile de prioritate ar trebuie s aib ca prim scop lansarea produsului. Pe lng rolul evident de a stabili prioritile i deci ordinea de execuie a sarcinilor de lucru, funcia mai trebuie s gestioneze sarcinile conflictuale i nemonotone. Ea trebuie s mpart aceste sarcini n grupuri consistente, s reglementeze selecia grupurilor consistente i apoi s dirijeze selecia sarcinilor din cadrul grupurilor. Pe msur ce sistemul crete, funcia de prioritate trebuie s aleag sarcini consistente cu partea deja constituit din sistem. O sarcin nemonoton vine n contradicie cu sistemul realizat deja i trebuie eliminat dac nu este absolut necesar pentru succesul sistemului. Odat ce o component este terminat i acceptat de echip, schimbrile asupra sa sunt ngheate. Componenta va fi schimbat numai dac modificrile sunt absolut necesare iar echipa este dispus s ntrzie lucrul la restul sistemului pentru a le efectua. Schimbrile trebuie s fie puine la numr, bine justificate i documentate.

9

Etapele principale ale metodei sunt: schia de principiu, prototipul, versiunile alfa/beta i produsul final. n prima etap, schia de principiu, echipele lucreaz simultan la toate fazele problemei. Echipa de analiz sugereaz cerinele. Echipa de proiectare le discut i trimite sarcinile critice de implementare echipei de implementare. Echipa de testare pregtete i dezvolt mediul de test n funcie de cerine. Echipa de implementare se concentreaz asupra sarcinilor critice, care n general sunt cele mai dificile. Aceast abordare contrasteaz cu practica curent de realizare mai nti a sarcinilor simple. Totui, majoritatea produselor care urmeaz acest model eueaz. Odat ce componentele critice au fost realizate, sistemul este gata de a face tranziia ctre stadiul de prototip. Unul din scopurile aceste etape este de a se convinge echipele c o soluie poate fi gsit i pus n practic. n cea de a doua etap, de prototip, cerinele i documentul cerinelor sunt ngheate. Schimbrile n cerine sunt nc permise, ns ar trebuie s fie foarte rare i numai dac sunt absolut necesare, deoarece modificrile cerinelor n acest stadiu al proiectului sunt foarte costisitoare. Este posibil totui ajustarea arhitecturii, pe baza noilor opiuni datorate tehnologiei. Dup ce sarcinile critice au fost terminate, echipa de implementare se poate concentra pe extinderea acestora, pentru definirea ct mai multor aspecte ale aplicaiei. Unul din scopurile acestei etape este de a convinge persoanele din afara echipelor c o soluie este posibil. Acum produsul este gata pentru lansarea versiunilor alfa i beta. Arhitectura este ngheat, iar accentul cade pe implementare i asigurarea calitii. Prima versiune lansat se numete n general alfa. Produsul este nc imatur; numai sarcinile critice au fost implementate la calitate ridicat. Numai un numr mic de clieni sunt n general dispui s accepte o versiune alfa i s-i asume riscurile asociate. O a doua lansare reprezint versiunea beta. Rolul su este de a convinge clienii c aplicaia va fi un produs adevrat i de aceea se adreseaz unui numr mai mare de clieni. Cnd o parte suficient de mare din sistem a fost construit, poate fi lansat n sfrit produsul. n aceast etap, implementarea este ngheat i accentul cade pe asigurarea calitii. Scopul este realizarea unui produs competitiv. n produsul final nu se accept erori critice. Avantaje Metodologia ecluz recunoate faptul c oamenii fac greeli i c nici o decizie nu trebuie s fie absolut. Echipele nu sunt blocate ntr-o serie de cerine sau ntr-o arhitectur imobil care se pot dovedi mai trziu inadecvate sau chiar greite. Totui, pentru respectarea termenelor limit, metodologia impune date de ngheare a unor faze. Exist timp suficient pentru corectarea greelilor decizionale pentru atingerea unui nivel suficient de ridicat de ncredere. Se pune mare accent pe comunicarea ntre echipe, ceea ce reduce cantitatea de cod inutil la care ar trebui s se renune n mod normal. Metodologia ncearc s mute toate erorile la nceputul procesului, unde corectarea, sau chiar renceperea de la zero a lucrului, nu sunt foarte costisitoare. Dezavantaje Metodologia presupune asumarea unor responsabiliti privind delimitarea etapelor i nghearea succesiv a fazelor de dezvoltare. Ea presupune crearea unui mediu de lucru n care acceptarea responsabilitii pentru o decizie care se dovedete mai trziu greit s nu se repercuteze n mod negativ asupra individului. Se dorete de asemenea schimbarea atitudinii echipelor fa de testare, care are loc nc de la nceput, i fa de comunicarea continu, care poate fi dificil, ntruct cele patru faze reprezint perspective diferite asupra realizrii produsului. Metodologii concrete Metodologia cascad Metodologia cascad, propus de Barry Boehm, este una din cele mai cunoscute exemple de metodologie de ingineria programrii. Exist numeroase variante ale acestui proces. ntr-o variant detaliat, metodologia cascad cuprinde urmtoarele etape:

1 0

Figura 4. Metodologia cascad Dup fiecare etap exist un pas de validare. Procesul curge de la etap la etap, ca apa ntr-o cascad. n descrierea originar a lui Boehm, exist o ntoarcere, un pas napoi interactiv ntre fiecare dou etape. Astfel, metoda cascad este de fapt o combinaie de metodologie secvenial cu elemente ciclice. Totui, n practica inginereasc, termenul cascad este utilizat ca un nume generic pentru orice metodologie secvenial. Acesta este modelul dup care de obicei sistemele sunt dezvoltate n practic. De asemenea, reordonarea fazelor s-a dovedit a fi sub-optimal. Exist o mare atracie pentru acest model datorit experienei, tradiiei n aplicarea sa i succesului pe care l-a implicat. O sarcin complex este mprit n mai muli pai mici, ce sunt mai uor de administrat. Fiecare pas are ca rezultat un produs bine definit (documente de specificaie, model, etc.) Modelul cascad cu feedback propune remedierea problemelor descoperite n pasul precedent. Problemele la pasul i care sunt descoperite la pasul i + 3 rmn neremediabile. Un model realist ar trebui s ofere posibilitatea ca de la un anumit nivel s se poat reveni la oricare dintre nivelele anterioare. Dezavantajul principal al modelului n cascad apare deoarece clientul obine o viziune practic asupra produsului doar n momentul terminrii procesului de dezvoltare. De asemenea, modelul nu are suficient putere descriptiv, n sensul c nu integreaz activiti ca managementul resurselor sau managementul configuraiei. Aceasta face dificil coordonarea proiectului. Dup cum am menionat la prezentarea metodologiei generice secveniale, i modelul cascad impune nghearea specificaiilor foarte devreme n procesul de dezvoltare pentru a evita iteraiile frecvente (rentoarcerile n fazele anterioare atunci cnd n faza curent s-au detectat erori: n timpul analizei se descoper erori de specificaii, n timpul implementrii se descoper erori de specificaii/proiectare etc., astfel nct procesul poate implica multiple secvene de iteraii ale activitilor de dezvoltare). nghearea prematur a cerinelor conduce la obinerea unui produs prost structurat i care nu execut ceea ce dorete utilizatorul. Conduce de asemenea la obinerea unei documentaii neadecvate deoarece schimbrile intervenite n iteraiile frecvente nu sunt actualizate n toate documentele produse. Metodologia spiral Metodologia spiral, propus tot de Boehm, este un alt exemplu bine cunoscut de metodologie a ingineriei programrii. Acest model ncearc s rezolve problemele modelului n cascad, pstrnd avantajele acestuia: planificare, faze bine definite, produse intermediare. El definete urmtorii pai n dezvoltarea unui produs: studiul de fezabilitate; analiza cerinelor;

1 1

proiectarea arhitecturii software; implementarea. Modelul n spiral recunoate c problema principal a dezvoltrii programelor este riscul. Riscul nu mai este eliminat prin aseriuni de genul: n urma proiectrii am obinut un model corect al sistemului, ca n modelul cascad. Aici riscul este acceptat, evaluat i se iau msuri pentru contracararea efectelor sale negative. Exemple de riscuri: n timpul unui proces ndelungat de dezvoltare, cerinele noi ale clientului sunt ignorate; clientul schimb cerinele; o firm concurent lanseaz un program rival pe pia; un dezvoltator/arhitect prsete echipa de dezvoltare; o echip nu respect un termen de livrare pentru o anumit component. n modelul spiral se consider c fiecare pas din dezvoltare conine o serie de activiti comune: pregtirea: se identific obiectivele, alternativele, constrngerile; gestionarea riscului: analiza i rezolvarea situaiilor de risc; activiti de dezvoltare specifice pasului curent (de exemplu analiza specificaiilor sau scrierea de cod); planificarea urmtorului stadiu: termenele limit, resurse umane, revizuirea strii proiectului. Metodologia spiral cuprinde urmtoarele etape, grupate pe patru cicluri:

Figura 5. Metodologia spiral Ciclul 1 Analiza preliminar: 1.Obiective, alternative, constrngeri 2.Analiza riscului i prototipul 3.Conceperea operaiilor 4.Cerinele i planul ciclului de via 5.Obiective, alternative, constrngeri 6.Analiza riscului i prototipul Ciclul 2 Analiza final: 7.Simulare, modele, benchmark-uri 8.Cerine software i validare 9.Plan de dezvoltare 10.Obiective, alternative, constrngeri 11.Analiza riscului i prototipul Ciclul 3 Proiectarea: 12.Simulare, modele, benchmark-uri 13.Proiectarea produsului software, validare i verificare 14.Integrare i plan de test 15.Obiective, alternative, constrngeri 16.Analiza riscului i prototipul operaional Ciclul 4 Implementarea i testarea: 17.Simulare, modele, benchmark-uri 18.Proiectare detaliat

1 2

19.Cod 20.Integrarea unitilor i testarea acceptrii 21.Lansarea produsului Procesul ncepe n centrul spiralei. Fiecare ciclu terminat reprezint o etap. Pe msur ce spirala este parcurs, produsul se maturizeaz. Cu fiecare ciclu, sistemul se apropie de soluia final. Dei este considerat ca un exemplu generic pentru metodologia ciclic, metoda are i elemente secveniale, puse n eviden de evoluia constant de la o etap la alta. Prototipizarea O problem general care apare la dezvoltarea unui program este s ne asigurm c utilizatorul obine exact ceea ce vrea. Prototipizarea vine n sprijinul rezolvrii acestei probleme. nc din primele faze ale dezvoltrii, clientului i se prezint o versiune funcional a sistemului. Aceast versiune nu reprezint ntregul sistem, ns este o parte a sistemului care cel puin funcioneaz. Prototipul ajut clientul n a-i defini mai bine cerinele i prioritile. Prin intermediul unui prototip, el poate nelege ce este posibil i ce nu din punct de vedere tehnologic. Prototipul este de obicei produs ct mai repede; pe cale de consecin, stilul de programare este de obicei (cel puin) neglijent. ns scopul principal al prototipului este de a ajuta n fazele de analiz i proiectare i nu folosirea unui stil elegant. Se disting dou feluri de prototipuri: de aruncat (throw-away); evoluionar. n cazul realizrii unui prototip de aruncat, scopul este exclusiv obinerea unei specificaii. De aceea nu se acord nici o importan stilului de programare i de lucru, punndu-se accent pe viteza de dezvoltare. Odat stabilite cerinele, codul prototipului este aruncat, sistemul final fiind rescris de la nceput, chiar n alt limbaj de programare. n cazul realizrii unui prototip evoluionar, scopul este de a crea un schelet al aplicaiei care s poat implementa n prim faz o parte a cerinelor sistemului. Pe msur ce aplicaia este dezvoltat, noi caracteristici sunt adugate scheletului existent. n contrast cu prototipul de aruncat, aici se investete un efort considerabil ntrun design modular i extensibil, precum i n adoptarea unui stil elegant de programare. Aceast metod are urmtoarele avantaje: permite dezvolttorilor s elimine lipsa de claritate a specificaiilor; ofer utilizatorilor ansa de a schimba specificaiile ntr-un mod ce nu afecteaz drastic durata de dezvoltare; ntreinerea este redus, deoarece validarea se face pe parcursul dezvoltrii; se poate facilita instruirea utilizatorilor finali nainte de terminarea produsului. Dintre dezavantajele principale ale prototipizrii amintim: deoarece prototipul ruleaz ntr-un mediu artificial, anumite dezavantaje ale produsului final pot fi scpate din vedere de clieni; clientul nu nelege de ce produsul necesit timp suplimentar pentru dezvoltare, avnd n vedere c prototipul a fost realizat att de repede; deoarece au n fiecare moment ansa de a face acest lucru, clienii schimb foarte des specificaiile; poate fi nepopular printre dezvolttori, deoarece implic renunarea la propria munc. Metodologia Booch Aceast metodologie asigur o dezvoltare orientat obiect n fazele de analiz i proiectare. Faza de analiz este mprit n mai muli pai. Primul pas este stabilirea cerinelor din perspectiva clientului, genernd o descriere de nivel nalt a funcionrii i structurii sistemului. Al doilea pas este analiza domeniului, realizat prin definirea claselor: atributele, metodele, motenirea. Faza de analiz este terminat cu un pas de validare. Aceast faz itereaz cei trei pai pn cnd soluia este consistent. i faza de proiectare este iterativ. Design-ul logic este transformat n design fizic, cu detalii privind firele de execuie, procesele, performanele, tipurile de date, structurile de date etc. Se creeaz un prototip i apoi se testeaz. Faza itereaz design-ul logic, cel fizic, prototipurile i testarea. Metodologia Booch este secvenial n sensul c mai nti este terminat analiza i apoi proiectarea. Ea este ciclic datorit iteraiilor din fiecare faz. Metoda se concentreaz n special asupra acestor dou faze, de analiz i proiectare, fr s insiste foarte mult asupra implementrii i testrii. Metode formale n acest model de dezvoltare, sunt folosite formalismul i rigoarea matematicii. n prima faz este construit o specificaie n limbaj matematic. Apoi, aceast specificaie este transformat n programe, de obicei printr-un proces incremental.

1 3

Avantaje: precizia obinut prin specificarea formal; pstrarea corectitudinii n timpul transformrii specificaiei n cod executabil; ofer posibilitatea generrii automate de cod; verificarea consistenei i testarea prin metode similare demonstrrii automate de teoreme. Dezavantaje: specificarea formal este de obicei o barier de comunicare ntre client i analist; necesit personal foarte calificat (deci mai scump); folosirea impecabil a tehnicilor specificrii formale nu implic neaprat obinerea de programe sigure, deoarece anumite aspecte critice pot fi omise din specificaiile iniiale. Datorit acestor caracteristici, metodele formale sunt potrivite n special pentru sisteme cu cerine critice. Exist mai multe limbaje pentru specificarea formal a funcionalitii programelor: Z, CSP (Communicating Sequential Processes), VDM (Vienna Development Method), Larch, FDM (Formal Development Methodology) etc. Extreme Programming Extreme Programming (Kent Beck, 1996) este o metodologie care propune rezolvri originale pentru problemele care apar n dezvoltarea de programe. Fiind o tehnologie nou (i extrem) are att adepi ct i critici. XP consider c dezvoltarea programelor nu nseamn ierarhii, responsabiliti i termene limit, aa cum se afl acestea pe masa administratorului, ci nseamn colaborarea oamenilor din care este format echipa. Acetia sunt ncurajai s i afirme personalitatea, s ofere i s primeasc cunotine i s devin programatori strlucii. De asemenea, XP consider c dezvoltarea de programe nseamn n primul rnd scrierea de programe. Aceast sintagm banal se pare c este uitat de multe companii care se ascund n spatele proceselor de dezvoltare stufoase, a edinelor i a rapoartelor de activitate. XP ne amintete cu respect ca fiierele PowerPoint nu se pot compila. De altfel, inspirarea proceselor de dezvoltare a programelor din ingineria construciilor se pare c nu este cea mai fericit alegere. Este adevrat c un inginer care vrea s construiasc un pod peste un ru face mai nti msurtori, realizeaz un proiect i abia apoi trece la execuie, toate acestea ntr-un mod secvenial i previzibil. Dar dezvoltarea de programe nu seamn cu aa ceva, orict am vrea s credem asta. Dac inginerului constructor respectiv i s-ar schimba cerinele de rezisten i i s-ar muta malurile chiar cnd a terminat de construit jumtate de pod, putem fi siguri c acel inginer i-ar schimba modul de lucru. Din pcate ns, nu tim (nc) cum. Iniiatorii XP definesc urmtoarele dou carte, ca baz filosofic pentru aceast metodologie. Carta drepturilor dezvolttorului: Ai dreptul s tii ceea ce se cere, prin cerine clare, cu declaraii clare de prioritate; Ai dreptul s spui ct i va lua s implementezi fiecare cerin, i s i revizuieti estimrile n funcie de experien; Ai dreptul s i accepi responsabilitile, n loc ca acestea s-i fie asignate; Ai dreptul s faci treab de calitate n orice moment; Ai dreptul la linite, distracie i la munc productiv i plcut. Carta drepturilor clientului: Ai dreptul la un plan general, s tii ce poate fi fcut, cnd, i la ce pre; Ai dreptul s vezi progresul ntr-un sistem care ruleaz i care se dovedete c funcioneaz trecnd teste repetabile pe care le specifici tu; Ai dreptul s te rzgndeti, s nlocuieti funcionaliti i s schimbi prioritile; Ai dreptul s fii informat de schimbrile n estimri, suficient de devreme pentru a putea reduce cerinele astfel ca munca s se termine la data prestabilit. Poi chiar s te opreti la un moment dat i s rmi cu un sistem folositor care s reflecte investiia pn la acea dat. Aceste afirmaii, dei par de la sine nelese, conin semnificaii profunde. Multe din problemele aprute n dezvoltarea programelor pornesc de la nclcarea acestor principii. Enumerm pe scurt cteva dintre caracteristicile XP: Echipa de dezvoltare nu are o structur ierarhic. Fiecare contribuie la proiect folosind maximul din cunotinele sale; Scrierea de cod este activitatea cea mai important; Proiectul este n mintea tuturor programatorilor din echip, nu n documentaii, modele sau rapoarte; La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerinelor; Codul se scrie ct mai simplu; Se scrie mai nti cod de test; Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se face fr mil;

1 4

Modificrile aduse codului sunt integrate continuu (de cteva ori pe zi); Se programeaz n echip (programare n perechi). Echipele se schimb la sfritul unei iteraii (1-2 sptmni); Se lucreaz 40 de ore pe sptmn, fr lucru suplimentar. Procesul de testare software n procesul de dezvoltare software testarea ocup cea mai mare parte din timpul alocat pentru proiect. Un mare dezavantaj n proiectele IT este acela c dezvolttorii subestimeaz testarea software, o neglijeaz. Ca urmare sunt puse n funciune aplicaii care n loc s uureze munca utilizatorului mai mult o ngreuneaz datorit erorilor generate de aplicaie. n dezvoltarea unui produs software testarea este un proces, care se desfoar n mai multe etape i pe mai multe nivele. Etapele procesului de testare software Etapele procesului de testare sunt: planificarea, analiza i proiectarea, implementarea i execuia i evaluarea testelor. Planificarea testelor Planificarea testelor se realizeaz n strns legtur cu planificarea derulrii proiectului. n faza de planificare a proiectului pentru testare se aloc resurse, specificndu-se bugetul i perioada de timp n care se va derula testarea. Pe baza acestora se realizeaz planificarea detaliat a procesului de testare. Planificarea testrii are scopul de a determina ce s testeze i ct s testeze, astfel nct procesul de testare s se ncadreze n limitele resurselor alocate. n urma planificrii testrii rezult planul de test, un document pe baza cruia se desfoar celelalte faze ale testrii. n aceast faz se identific i obiectivele testrii. Planul de test este un document important, fiind utilizat ca baz pentru desfurarea ntregului proces de testare. n plus, trebuie identificate i sursele de risc n testare. Planificarea testrii poate s nceap din momentul n care au fost elaborate cerinele aplicaiei software. n planul de test sunt descrise: aria de cuprindere; responsabilitile fiecrui membru al echipei de testare; resursele umane necesare; desfurarea n timp a testelor; descrierea i configurarea mediului specific aplicaiei; lista echipamentelor care trebuie achiziionate; crearea i managementul datelor de test; criteriile de acceptare a testelor. Deoarece este foarte dificil s se stabileasc momentul n care se va ncheia testarea, n planul de test se specific o serie de criterii care constituie o baz pentru determinarea finalizrii testrii. Analiza testelor n etapa de analiz se identific urmtorii pai: identificarea scopurilor, obiectivelor i a strategilor testrii de ctre echipa de testare; metodele de verificare sunt asociate cerinelor sistemului sau cazurilor de utilizare i sunt documentate n cadrul unei matrice de urmrire a cerinelor; analiza cerinelor testelor; construirea matricei cerinelor testelor, n care declaraiile cerinelor testelor sunt asociate cerinelor sistemului sau a cazurilor de utilizare; asocierea tehnicilor de testare cu declaraiile cerinelor testelor. n faza de analiz a procesului de testare, un aspect important l ocup analiza cerinelor pentru testare. Cerinele testrii trebuie s fie identificate i documentate astfel nct toate persoanele implicate n procesul de testare s fie contiente de scopul acestuia. Analiza se desfoar din mai multe puncte de vedere, depinznd de faza de testare. Astfel se identific o abordare structural i o abordare bazat pe comportament. Proiectarea testelor Etapa de proiectare a testelor urmeaz dup ncheierea analizei. n faza de proiectare, apar urmtorii pai: definirea modelului programului de test astfel nct acesta s reflecte tehnicile de testare utilizate; definirea arhitecturii de test; definirea procedurilor de test; luarea deciziei de automatizare a anumitor teste i de testare manual a altor componente;

1 5

asocierea datelor de test astfel nct fiecare cerin pentru datele de test s se reflecte pentru fiecare procedur de test. Programul de test se elaboreaz fie la nivelul proiectrii, fie la nivelul tehnicilor de testare. n primul caz, procedurile de test sunt asociate componentelor hardware i software ale aplicaiei, iar n al doilea caz procedurile de testare sunt vzute la nivelul tehnicilor de testare. Proiectarea procedurilor de test ncepe dup determinarea cerinelor testrii. Proiectarea procedurilor de test const n: analiza arhitecturii de test pentru determinarea tehnicilor de testare relevante; definirea procedurilor de test att la nivelul sistemului ct i la nivelul de implementare; elaborarea sau preluarea de standarde de utilizare a procedurilor de test; identificarea procedurilor de test care vor fi efectuate manual i a celor care vor fi efectuate automat; identificarea procedurilor de test complexe, pentru a fi proiectate n continuare n faza de proiectare detaliat; proiectarea detaliat. Implementarea testelor n etapa de implementare a testelor sunt construite cazurile de test i procedurile de test, pe baza rezultatelor fazei de proiectare. Cazurile de test descriu att parametrii de intrare ct i rezultatele ateptate dup execuie utiliznd aceti parametri. Realizarea de cazuri de test ct mai complete duce la descoperirea unui numr mai mare de erori. Procedurile de test identific toi paii necesari pentru executarea cazurilor de test specifice. Rularea testelor Faza de rulare a testelor are ca intrri planul de test i orarul execuiei procedurilor de test, mediul de test fiind pregtit corespunztor. Ieirile fazei de execuie a testelor sunt rezultatele testelor, leciile nvate i orarul modificat al testelor. Execuia modulelor se realizeaz n conformitate cu planul de test. Procedurile de test descriu intrrile i ieirile ateptate dup execuie. n aceast etap din cadrul procesului de testare sunt rulate secvenele de test. Execuia secvenelor de test se realizeaz pe ct posibil n mediul specific aplicaiei iar dac nu este posibil, acest mediu este simulat. Rezultatele execuiei secvenelor de test sunt evaluate pentru a determina dac produsul a trecut testul cu succes. Evaluarea rezultatelor testelor se face de ctre o persoan sau un instrument automat, care pe baza specificaiilor determin dac rezultatele execuiei testelor sunt corecte sau nu. Rezultatele execuiei testelor se vor memora ntr-o baz de date care conine i alte informaii referitoare la aplicaia software realizat. Execuia i evaluarea testrii de integrare necesit noi secvene de test pe msur ce se adaug module n cadrul structurii programului care se testeaz. Aprobarea de ctre beneficiar a rapoartelor testrii de modul i ale testrii de integrare constituie ncheierea acestor faze. n execuia i evaluarea testrii de sistem, beneficiarul aplicaiei se implic mai mult dect n celelalte faze. n mod asemntor, acesta trebuie s semneze raportul de test pentru a considera ncheiat aceast faz de testare. Nivelurile de testare software n dezvoltarea unui produs software testarea se realizeaz pe mai multe nivele: testarea de module, testarea de integrare, testarea de sistem i testarea de acceptare. Pentru ilustrarea acestor nivele vom folosi modelul-V, care corespunde metodologiei cascad de dezvoltare a softului, deoarece ne poate furniza mai multe detalii tehnice dect celelalte metodologii. Exist mai multe variante ale acestui model. n figura 6 este prezentat una dintre ele.

1 6

S p e c ific a ii a le c e rin e lo r

P la n ific a re a te s t rii d e a c c e p ta re P la n ific a re a te s t rii d e s is te m

T e s ta de acce

S p e c ific a ii fu n c io n a le

T e s ta re a d e s is te m

S p e c ific a ii te h n ic e

P la n ific a re a te s t rii d e in te g ra re

T e s ta re a d e in te g ra re

S p e c ific a ii P la n ific a re a a le p ro g ra m u lu i te s t rii d e m o d u le

T e s ta re a m o d u le lo r

C o d ific a reFigura 6. Modelul-V pentru dezvoltarea softului n partea stng a acestui model avem: Specificaiile cerinelor - reflect necesitile utilizatorilor. Specificaiile funcionale - definirea funciilor necesare pentru realizarea cerinelor. Specificaiile tehnice - proiectarea tehnic a funciilor identificate n specificaiile funcionale. Specificaiile programului - proiectarea detaliat a oricrui modul conform cerinelor de funcionalitate. Mijlocul aceluiai model ne demonstreaz c planificarea i testarea trebuie s nceap odat cu specificarea cerinelor pentru orice produs software. Astfel nc de la aceast etap se planific testele de validare a produsului. Partea dreapt se axeaz pe activitile de testare. Testarea conform cerinelor se realizeaz la etapa testrii de acceptare . Testarea conform specificaiilor funcionale se reia odat cu testarea sistemului Testarea conform specificaiilor tehnice are loc odat cu testarea de integrare. Testarea conform specificaiilor programului se realizeaz la faza de testare a modulelor. Aceasta permite orientarea testrii la detaliile predestinate produsului soft, ceea ce favorizeaz depistarea precoce a defectelor. Fiecare etap a testrii trebuie definitivat nainte de nceperea urmtoarei, astfel validarea soft-ului de ctre utilizatori se va produce exact la sfritul ciclului de dezvoltare. Dac cerinele beneficiarului nu au fost total respectate (receptate corect) sau au fost modificate, problema se soluioneaz doar dup ce acesta testeaz (utilizeaz) produsul. Rezolvarea problemei la etapa de validare este foarte costisitoare. Cu att mai mult se poate recurge la anularea proiectului. Termenul nivelul testrii indic scopului testrii i tipurile de probleme care le poate descoperi. Fiecare nivel va include teste care vor nltura problemele specifice etapei respective de dezvoltare. Aceste nivele pot fi aplicate i celorlalte metode de dezvoltare a softului. Acestea se modific n dependen de sistem. De ex., dac sistemul presupune folosirea unor componente soft dezvoltate de o parte ter, testarea de acceptare se petrece naintea testrii de sistem. n continuare sunt descrise mai n detaliu nivelele de testare.

Testarea de module n cadrul testrii de module se realizeaz verificarea celor mai mici uniti software care pot fi compilate i link-editate independent. n programarea clasic un modul este un subprogram (funcie sau procedur). n cadrul programelor orientate obiect, cea mai mic unitate testabil este clasa. Testarea de module se concentreaz asupra verificrii interfeelor modulelor, structurilor de date locale, condiiilor de la limite, cilor independente i cilor de tratare a erorilor.

1 7

Deoarece modulele nu sunt programe de sine stttoare, este necesar s se construiasc programe sau funcii care s ajute la testarea de module. O prim categorie o reprezint programele conductoare (drivers) care apeleaz modulele supuse testrii cu datele de test construite i preiau rezultatele execuiei. O alt categorie este reprezentat de funciile sau procedurile apelate de ctre modulul de testat. Acestea sunt substituite cu subprograme care au acelai prototip, ns cu funcionalitate redus la minim, denumite module vide (stubs). Modulele vide sunt funcii sau proceduri simple care nu fac nimic n afara returnrii controlului, sau sunt funcii sau proceduri complexe, care simuleaz efectul apelrii modulelor reale. n cele mai multe cazuri, modulele vide simple sunt nepotrivite. Un efort considerabil este necesar pentru implementarea de module vide complexe. Testarea de integrare Aceasta este o tehnic sistematic de construire a structurii programului prin gruparea componentelor n paralel cu testarea aspectelor legate de interfaa dintre componente. Aici se pot evidenia dou maniere de testare: neincremental sau incremental. Testarea neincremental (big-bang testing) const n integrarea componentelor prin gruparea tuturor modulelor dintr-o dat, urmat de testarea ntregului ansamblu. Acest tip de integrare nu este recomandat, deoarece corectarea erorilor va fi foarte greu de realizat. Testarea incremental presupune construirea structurii programului pas cu pas i testarea ansamblului obinut. Un element important n execuia testului este secvena n care modulele trebuie s fie testate. Astfel, testarea de integrare se realizeaz ascendent (bottom-up), descendent (top-down) sau mixt. Testarea de integrare se poate realiza prin cteva metode: Metoda de testare ascendent (bottom-up testing). Aceast metod presupune testarea mai nti a modulelor de pe cel mai de jos nivel al ierarhiei programului, apoi se continu n sus cu testarea celorlalte module. Metoda de testare ascendent necesit construcia de programe conductoare pentru a iniializa mediul i pentru a apela modulele.Modulul 1

Modulul 2

Modulul 3

Modulul 4

Modulul Modulul 5 6 Figura 7. Bottom-up integration testing

Modulul 7

Conform acestei scheme integrarea componentelor se va face n urmtoarea ordine: 4,2 5,2 6,3 7,3 2,1 3,1 Programele de pe nivelul de sus, care de obicei sunt critice, sunt testate ultimele. n timp sunt descoperite erori care pot influena multe module care au fost deja testate. Dup corecia erorilor este necesar ca toate modulele de pe nivelurile de jos s fie testate regresiv. Metoda de testare descendent (top-down testing).

1 8

n metoda testrii descendente modulul din vrful ierarhiei de programe este testat primul, procesul de testare continund cu modulele de pe nivelurile inferioare. Metoda de testare descendent necesit construcia de module vide asociate subprogramelor care nu sunt disponibile.

Modulul 1

Modulul 2

Modulul 3

Modulul 4

Modulul 5

Modulul 6

Modulul 7

Figura 8. Top-down integration testing Conform acestei scheme integrarea componentelor se va face n urmtoarea ordine: 1,2 1,3 2,4 2,5 3,6 3,7 Avantajul acestei metode este c dac este descoperit o eroare n modulele de pe nivelurile nalte, impactul va fi asupra modulelor de pe nivelurile de jos care nu au fost nc implementate, deci refacerea modulelor de pe nivelurile inferioare poate fi evitat. Metoda mixt. n cadrul metodei mixte, testarea urmeaz mai nti metoda descendent. Modulele selectate de pe nivelurile inferioare sunt testate utiliznd metoda ascendent. Aceast flexibilitate permite preluarea avantajelor metodelor de ascendent i descendent. n cele mai multe aplicaii, metoda mixt este cea mai potrivit modalitate de abordare. Pe msur ce sunt adugate noi module n cadrul testrii de integrare, apar schimbri n software, care pot s modifice comportamentul structurii obinute anterior. n acest context este executat testarea de regresie, prin care se re-testeaz noua structur obinut, utiliznd o parte din testele utilizate n etapa precedent. Testarea de integrare poate reprezenta mai mult dect un nivel de testare. De ex. : Testarea de integrare a componentelor se focuseaz pe interaciunea dintre elementele soft-ului i e realizat dup testarea modulelor (unit testing). Testarea se realizeaz de ctre dezvolttori. Testarea de integrare a sistemului se axeaz pe interaciunea dintre diferite sisteme i se poate efectua dup testarea fiecrui sistem n parte. De ex. un sistem comercial ntr-o banc de investiii va interaciona cu bursa de valori pentru a obine ultimul pre pentru fondurile i aciunile sale pe piaa internaional. Testarea se realizeaz de ctre testeri. Testarea de sistem Dac ne-am convins de funcionarea mpreun a elementelor la nivel de module, se trece la etapa urmtoare verificarea funcionalitii sistemului ca un tot ntreg. Activitatea poart numele de testarea sistemului. Testarea sistemului se impune din cauza c multe criterii ale testrii de module i testrii de integrare genereaz seturi de cazuri de test nereprezentative pentru condiiile reale de operare. Astfel testarea la aceste nivele este puin probabil s depisteze erori ale interaciunii cu ntregul sistem ori probleme de mediu. Testarea sistemului servete la nlturarea dezechilibrului prin concentrarea asupra comportamentului ntregului sistem/produs precum este definit de scopul dezvoltrii proiectului sau programului, ntr-un mediu de lucru reprezentativ. De obicei acesta este realizat de o echip independent. Independena asigur obiectivitatea evalurii sistemului, care se bazeaz pe specificaiile scrise, i nu pe codul produsului soft.

1 9

n modelul -V, comportarea adecvat a sistemului se documenteaz n specificaia funcional, care definete ce trebuie construit pentru a satisface cerinele sistemului. Specificaia funcional trebuie s conin definiiile ambelor cerine ale sistemului funcionale i non-funcionale. O cerin funcional este o cerin ce specific o funcie obligatorie a sistemului sau a unei componente a sistemului. De ex., ai vrea s fie posibil programarea unui zbor pe un website al unei companii turistice, n timp ce verifici on-line contul, dac ai suficiente mijloace bneti pentru a plti pentru zbor. Aceste cerine fundamentale furnizeaz detalii n baza crora se va dezvolta aplicaia. Testarea non funcional a sistemului examineaz aspectele importante, dar influeneaz direct funciile pe care le ndeplinete sistemul. Acestea sunt nite cerine generice (universale), care ar putea fi aplicate mai multor sisteme. n ex. de mai sus, de pild ai vrea ca ambele sisteme s rspund apelului nostru (implicaiilor) ntr-un timp rezonabil. Tipic aceste cerine vor aprecia ca normale ambele operaiuni la fel i comportamentul sistemului n circumstane excepionale. Astfel cerinele non-funcionale explic comportamentul aplicaiilor n practic. Exemple de cerine non-funcionale: Instabilitatea - proceduri de instalare. Interoperabilitatea - execuia aplicaiei n diferite medii de lucru. Stabilitatea - posibilitatea de a face schimbri n sistem. Performana - comportamentul normal, ateptat. ncrcarea ( loading) - comportamentul sistemului cnd resursele sunt ncrcate la maxim. Portabilitatea - utilizarea pe diferite platforme. Capacitatea de recuperare - restabilirea sistemului dup ncheerea necorespunztoare a execuiei. Fiabilitatea - capacitatea softului de a-si pstra funcionalitilor dup o perioad de timp. Utilizabilitatea - simplitatea de comunicare a utilizatorului cu sistemul. n literatura de specialitate, sunt prezentate cteva tehnici specifice pentru testarea de sistem: 1. Testarea pentru determinarea capacitii de recuperare este un test de sistem care, printr-o multitudine de ci, foreaz aplicaia software s i ncheie execuia n mod necorespunztor. Prin acestea se testeaz capacitatea aplicaiei de revenire dintr-o situaie necorespunztoare. 2. Testarea securitii se realizeaz pentru a verifica eficiena mecanismelor de protecie dintr-un sistem software i dac acesta se comport corespunztor la atacurile externe. 3. Testarea de solicitare se execut astfel nct sistemul s funcioneze cu un volum mai mare de resurse dect cel normal, cu scopul de a determina fiabilitatea aplicaiei i momentul n care funcionarea aplicaiei devine critic i pentru a lua msurile corespunztoare, astfel nct s nu se ajung n exploatarea de zi cu zi a sistemului informatic la astfel de situaii. 4. Testarea de ncrcare const n rularea sistemului software n condiiile n care resursele (memorie, microprocesor, reea) sunt ncrcate la maxim astfel nct se ajunge la situaii critice, n care o parte din resurse nu mai sunt disponibile. Se urmrete capacitatea sistemului de a-i ntrerupe funcionarea fr pierderea sau coruperea datelor. 5. Testarea performanelor se realizeaz pentru determinarea conformitii sistemului cu cerinele de performan impuse. De exemplu sistemul este ncrcat ntr-un interval de timp pornind de la capacitatea minim pn la capacitatea maxim i se verific dac resursele sistemului se afl n limitele corespunztoare i nu sunt ntrzieri n executarea funciilor aplicaiei. Securitatea se consider o cerin funcional a sistemului. Testarea de acceptare Testarea de acceptare are loc dup ce toate erorile de interfa descoperite n cadrul testrii de integrare au fost corectate. De ex., testarea de acceptare poate evalua starea de pregtire a sistemului pentru desfurare i utilizare. Testarea de acceptare este o responsabilitate a beneficiarului sau utilizatorului, ns pot fi implicai i ali membri ai echipei. Formele tipice ale testrii de acceptare includ urmtoarele: Testarea de acceptare a utilizatorului - testarea de ctre reprezentanii utilizatorilor pentru a verifica dac sistemul satisface cerinele de business. Testarea de acceptare a funcionalitii - denumit deseori testarea pregtirii pentru activitate. Aceasta presupune verificarea dac procesele i procedurile sunt n ordine i pot asigura utilizarea i stabilitatea sistemului. Activitatea include: - Posibilitile de back-up - Procedurile pentru restabilire dup eecuri

2 0

- Instruirea utilizatorilor - Procedurile de stabilitate - Procedurile de securitate Testarea de acceptare a contractului i reglementrilor - Testarea de acceptare a contractului - uneori criteriile de acceptare ale unui sistem sunt consemnate n contract. Testarea se efectueaz nainte de validarea sistemului, pentru confirmarea respectrii criteriilor solicitate. - Testarea de acceptare a reglementrilor - n unele industrii sistemul trebuie s respecte unele standarde guvernamentale, legale sau de securitate. n cadrul testrii de acceptare se regsesc testrile alfa i beta. Testarea alfa este realizat la firma care produce aplicaia software, beneficiarul fiind acela care conduce testele. Testarea beta este realizat la beneficiari i utilizatori finali. Acetia primesc o versiune a aplicaiei software, versiune apropiat de cea final i o utilizeaz n scopul descoperirii erorilor i a problemelor de performan i funcionalitate. Problemele aprute n cadrul acestei testri sunt raportate firmei care a realizat aplicaia. Dup ce perioada acordat pentru testarea beta s-a terminat, toate erorile aprute sunt corectate, urmnd s se realizeze versiunea final a aplicaiei software. Testarea regresiv Paragrafele anterioare arat necesitatea realizrii testrii la diferite etape ale dezvoltrii produsului. Nici o etap a testrii nu este absolvit de depistarea erorilor. Depistarea i nlturarea acestora mbuntete calitatea sistemului. Depistarea i nlturarea unei greeli atrage dup sine retestarea pentru a se asigura c problema a fost cu succes ameliorat. nlturarea defectului se numete debugging, care nu e o activitate de testare. Testarea detecteaz defectele, iar prin debugging ele sunt nlturate. Un sistem, care nu a fost modificat, de asemenea trebuie testat pentru a se asigura dac nu au fost introduse schimbri adiionale la schimbarea softului. Acest tip de testare se numete testare regresiv. Testarea regresiv se desfoar i cnd este schimbat mediul de lucru. Testarea regresiv presupune crearea unui set de teste care ar servi la demonstrarea c sistemul funcioneaz corect. Acestea se vor aplica de mai multe ori produsului testat. Repetarea testelor provoac, n unele cazuri, automatizarea testrii regresive. Testarea de ntreinere (maintenance testing) Pentru multe proiecte sistemul este realizat n medii reale de lucru, ceea ce asigur o funcionalitate ndelungat. n perioada de dezvoltare sistemul poate suferi schimbri condiionate. Schimbrile pot fi provocate de : Cerine adiionale solicitate. Schimbarea sistemului pe o platform de operare nou. Sistemul este n curs de retragere din uz - datele cer schimbare sau arhivare. Depistarea noilor erori. Odat ce s-au efectuat modificrile, sistemul trebuie testat (testul de confirmare) i trebuie supus analizei regresive pentru a verifica dac restul sistemului nu a suferit schimbri adverse din cauza lor. Testarea sistemului n condiii reale ( n mediu real de lucru) se numete testare de ntreinere. Orice modificare trebuie testat, n mod ideal, ntregul sistem trebuie supus testrii regresive. n practic activitile pot fi irealizabile sau costisitoare. Identificarea prii care poate fi afectat de modificri ar reduce numrul testrilor regresive. Activitatea se numete - analiza impactului( analizarea efectului schimbrilor asupra sistemului). Analizarea impactului este dificil pentru un sistem deja realizat, deoarece specificaiile pot lipsi, ori echipa de implementare lucreaz la un alt proiect, sau au prsit organizaia. Testarea static Capitolul prezint o introducere n una dintre cele mai importante arii ale testrii - tehnicile statice de testare. Tehnicile statice testeaz software fr a-l executa. Totui prezint importan prin abilitatea de a depista erorile i defectele nainte de executarea codului, n primele etape ale desfurrii proiectului, facilitnd i reducnd din cheltuielile necesare pentru depistarea i corectarea aceleiai greeli ntr-o etap mai avansat. Tehnicile de inspecie (review) se axeaz pe tehnicilor statice. Astfel n acest capitol vom cerceta diferite tipuri de inspecie i concordana lor cu procesul de testare definit n cap.2. Capitolul trateaz i analiza static a codului dezvoltat, considerat o tehnic de examinare a codului fr activarea lui pentru a identifica problemele actuale sau poteniale. Testarea static e deseori imposibil de realizat manual, astfel vom cerceta tipurile testrii statice care solicit anumite mijloace (instrumente). Ne vom axa pe tehnicile testrii statice, mijloacele caracteristice tipului de testare sunt descrise n alt capitol. (cap.6) Generaliti despre tehnicile statice

2 1

Tehnicile testrii statice presupun tehnicile de testare a soft-ului care nu implic executarea codului. Aceasta include att testarea produsului soft diferit de cod, cerinele tipice ori documentele ce conin specificaiile, i testarea codului fr executarea lui. Prima activitate se numete revizuire (inspecie) i e utilizat de obicei pentru nlturarea erorilor i ambiguitilor din documente nainte de a fi utilizate la dezvoltarea proiectului, astfel eliminnd o surs a defectelor n cod. A doua activitate e cunoscut sub numele de analiz static i permite cercetarea codului de defectele structurale i insuficienele sistematice care pot favoriza defectele. Inspeciile sunt fcute manual, analiza static se realizeaz de obicei automatizat cu ajutorul unor instrumente.(vezi cap.6) Verificarea i testarea Revizuirea este o examinare sistematic a documentului de ctre una sau dou persoane care au ca obiectiv detectarea i nlturarea erorilor. ncredinarea reexaminrii primei variante a documentului colegilor e cel mai simplu exemplu de revizuire i care de obicei scoate la iveal o mulime de erori anticipate. Revizuirea se aplic documentelor scrise sau tiprite: documente ca specificaiile cerinelor, design-urile sistemului, codul, test-planurile i cazurile de test. Revizuirea reprezint prima form de testare posibil n perioada de dezvoltare a soft-ului. Testarea documentelor ce conin specificaii prin revizuirea lor la etapa iniial a ciclului de nfiinare a soft-ului favorizeaz detectarea defectelor nainte de a fi incluse n codul surs. Astfel reducnd din efortul i cheltuielile necesare pentru nlturarea defectelor, acelai defect detectat de o testare dinamic va solicita un extra cost pentru re-crearea i testarea codului defect, diagnosticarea sursei defectului, corectarea problemei i rescrierea codului pentru eliminarea defectelor. Inspecia codului conform standardelor de dezvoltare poate preveni apariia defectelor la executarea testului. Dar i n aceste cazuri, dac codul a fost scris nu se pot evita unele cheltuieli. Pe lng economisirea timpului i a finanelor exist i alte avantaje ale depistrii timpurii a defectelor n perioada de dezvoltare: Poate fi mbuntit productivitii i reducerea limitelor temporale deoarece corectrile defectelor ntr-o etapa incipient vor asigura c produsul este clar i neambiguu. Aceasta ar trebui s-l ajute pe dezvolttor s se mite mai repede n procesul de scriere a codului. De asemenea, dac defectele s-au nlturat nainte ca proiectul s devin cod se vor detecta i fixa mai puine erori pe parcursul executrii testului. Costul i timpul testrii poate fi redus prin nlturarea principalelor ntrzieri ale testului, care au loc cnd defectele sunt depistate dup ce devin eecuri i testorul trebuie s atepte corectarea softului. Revizuirea codului i detectarea defectelor nainte de a deveni eecuri i permite testorului executarea mai rapid a testului. n realitate e posibil obinerea reducerii costului datorit numrului mic de defecte n final, care asigur c cheltuielile curente vor fi reduse. Comunicarea constructiv se datoreaz autorilor i colegilor lor care cerceteaz i nltur orice ambiguitate descoperit n timpul revizuirii pentru a asigura c orice participant a neles exact ce se livreaz. Cele mai tipice greeli depistate la revizuire: Abaterile de la standardele interne i reglementrilor / legal definite de Parlament sau de o organizaie comercial. Defectele cerinelor-de ex. cerinele sunt ambigue sau au unele elemente lips. Defectele de design - de ex. design-ul nu respect toate cerinele. Insuficiena stabilitii - de ex. codul este prea complex i greu de meninut. Interfaa incorect a specificaiilor - de ex. interfaa specificaiilor nu corespunde design-ului sau interfeelor de transmitere sau primire a datelor. Orice revizuire are ca scop depistarea defectelor, unele ns evideniaz anumite tipuri de defecte mai efectiv i mai eficient dect altele. Procesul de revizuire Procesele de revizuire variaz vizibil n dependen de gradul de formalitate - cnd formalitatea se asociaz cu nivelul structurii i documentarea cu activitatea. Unele tipuri de reexaminare au caracter informal, pe cnd altele sunt foarte formale. Stabilirea gradului de formalitate se bazeaz pe combinarea urmtorilor factori: Maturitatea procesului de dezvoltare: cu ct acesta este mai matur cu att revizuirea este mai formal. Cerinele legale sau reglementare. Acestea se folosesc la administrarea activitii de dezvoltare a soft-ului n anumite industrii, obligator n ariile de strict-securitate ca de exemplu semnalizarea cilor ferate. Necesitatea unei proceduri de audit. Procesele formale de revizuire asigur posibilitatea unei retrospective a procesului de dezvoltare a soft-ului. Nivelul formalitii tipului de analiz static utilizat ne poate ajuta s stabilim nivelul procesului de audit.

2 2

Revizuirea poate avea o varietate de obiective, iar termenul obiectiv de revizuire semnific scopul principal al revizuirii. Obiectivele revizuirii includ: Detectarea defectelor. nelegerea.. Generarea discuiilor. Deciziile luate n consens. Modalitatea revizuirii se stabilete n dependen de obiectivele specifice. Deci o revizuire orientat spre detectarea defectelor se va deosibi de una care reflect nelegerea unui document. Procesul fundamental de verificare Toate tipurile de revizuire manifest aceleai elemente fundamentale ale procesului: Documentele aflate n curs de examinare se studiaz de ctre inspectori. Inspectorii identific problemele i informeaz autorul verbal sau prin document scris, oficial printr-un raport al defectelor sau neoficial printr-o adnotare a documentului examinat. Autorul decide ce aciuni s adopte ca rspuns la comentarii i asupra adaptrii documentului la acestea. Procesul de baz se realizeaz permanent, dar n unele examinri formale se includ etape suplimentare, se insist mai mult pe documentare i pe msurare. Etapele reexaminrii formale Revizuirile din spectrul oficial ca revizuirile tehnice i inspeciile, dein anumite caracteristici prin care se deosebesc de cele mai puin oficiale. Figura 9 demonstreaz etapele cheie ale revizuirii formale: Planificarea: * Selectarea personalului - asigurarea c cei alei pot i vor aduga valoare procesului. Exist un criteriu de selectare a revizorilor care vor fi de-acord cu cele scrise de autor. Se recomand

K k -o ic ff

P n in la n g

In iv u l d id a p p ra n re a tio

F llo o w

-u p

Rv w e ie me g e tin

Figura 9. Etapele revizuirii formale includerea unor revizori din diferite departamente ale organizaiei, care au renume de oameni pretenioi i impariali. Revizorii ca i nunta uimesc prin ceva vechi , ceva nou, ceva mprumutat, ceva albastru. n acest caz ceva vechi va fi un profesionist experimentat, ceva nou un membru nou al echipei, ceva mprumutat cineva din alt echip, ceva albastru opoziionistul greu de mpcat. La etapa iniial a procesului de revizuire se stabilete un revizor lider. Acesta va dirija activitatea de revizuire. * Repartizarea rolurilor - fiecare revizor primete o anumit sarcin. Cineva poate testa testabilitatea i claritatea definiiei, altcineva simplitatea i claritatea relaiilor comerciale. Toi revizorii care lucreaz la acelai document au diferite perspective asupra acestuia. * Definirea criteriului de intrare i ieire, n special pentru tipurile de revizuire formal (de ex. inspecia). * Selectarea prilor documentelor care trebuiesc revzute (nu ntotdeauna necesar, aceasta depinde de mrimea documentelor: un document mai mare necesit mprirea lui n pri mai mici i analiza fiecrei pri de persoane diferite pentru a se asigura c documentul este revizuit n ntregime).

R w rk e o

2 3

Startul: distribuirea documentelor, explicarea obiectivelor, procesului i documentelor participanilor, verificarea criteriului de intrare. Aceasta poate fi desfurat ca o ntrunire sau simplu prin distribuirea detaliilor revizorilor. Metoda utilizat depinde de limitele temporale i de volumul de informaie. Un volum impuntor de informaie poate fi mprit mai bine la o ntlnire dect prin citirea paginilor de ctre utilizatori. Pregtirea individual: munca efectuat individual de fiecare participant naintea ntrunirii, care presupune citirea documentelor surs, consemnarea potenialelor defecte, ntrebri i comentarii. Aceasta este principala surs i poate fi constrns de timp, participanii primesc 2 ore pentru a-i definitiva pregtirea. ntrunirea de revizuire: aceasta poate include discuiile referitoare la orice defect gsit. Inspecia, un tip de revizuire mai formal, va documenta rezultatele. Participanii edinei pot doar nota defectele care urmeaz s fie corectate de autor. De asemenea pot face recomandri pentru corectarea defectelor .Determinarea abordrii se bazeaz pe unul sau pe toi factorii de mai jos: * Timpul disponibil (dac dispunem de puin timp ntrunirea poate doar colecta defectele). * Cerinele autorului (dac autorul accept ajutor la corectarea defectelor). * Tipul revizuirii (n cazul inspeciei se permite doar colectarea nu exist nici o discuie.) Refacerea: dup ntrunirea de revizuire autorul va avea mai multe defecte de corectat, corectarea defectelor se numete refacere. Autorul va nltura problemele depistate i va confirma necesitatea rectificrii. Continuarea: liderul reexaminrii va verifica dac defectele acceptate au fost localizate i va determina de ct timp a fost nevoie pentru revizuire i ct de multe defecte au fost depistate. Acesta va mai verifica criteriile de ieire (pentru inspecie) pentru a garanta ndeplinirea lor.

Rolurile i responsabilitile Rolul revizorilor rezid n cercetarea documentelor din perspectiva oferit; aceasta include utilizarea listei. Pentru identificarea defectelor se poate folosi o list bazat pe perspective particulare (utilizatorul, mecanicul, testerul sau operatorul) sau una mai general (ca problemele tipice ale cerinelor). n afar de acestea procesul de revizuire definete el singur roluri specifice i responsabiliti care trebuie ndeplinite pentru revizuirea formal: Managerul: el decide ce trebuie de revizuit (dac nu era definit nc), se asigur dac timpul alocat n planul proiectului va fi suficient pentru toate activitile de reexaminare necesare, i determin dac au fost realizate obiectivele analizei. Managerul nu se implic n procesul actual de revizuire dect n cazul cnd poate aduga ceva important, de exemplu dac el posed cunotine tehnice importante pentru activitatea respectiv. Moderatorul: e cunoscut uneori ca liderul revizorilor. E persoana care dirijeaz reexaminarea unui document sau a unui set de documente, planific activitatea, realizeaz ntrunirea i cele ce urmeaz. Dac e necesar, el va media ntre diferite puncte de vedere i deseori de el depinde succesul aciunilor rmase.La fel va realiza decizia final despre ce trebuie inclus n documentul de informare. Autorul: Autorul este cel care a scris sau persoana responsabil de dezvoltarea documentului care trebuie revizuit. Autorul va prelua n diferite instane responsabilitatea de a localiza i aproba greeala. Revizorii: Acestea sunt persoanele cu cunotine tehnice ori comerciale speciale (numii nc verificatori i inspectori), care dup o pregtire adecvat, identific i descriu cele observate (de ex. defectele) produsului revizuit. Dup cum am menionat mai sus inspectorii trebuie alei s reprezinte diferite perspective n procesul de revizuire i s participe la orice ntrunire a inspectorilor. Secretar (grefier): acesta particip la ntrunirile revizorilor i documenteaz toate problemele, defectele i prile discutabile care au fost depistate. Un rol indirect asociat cu revizuirea e cel al testerului. El deine un rol aparte n relaia cu documentul reexaminat. El va fi solicitat s analizeze documentul pentru a permite dezvoltarea testului. La analiza documentului acesta testerul va stabili scenariul, va nota dac este vreo lacun n cerine care ar stopa funcionarea produsului, aa ca lipsa unui proces sau absena unor date la momentul dat. Efectiv testerul ar putea fi invitat oficial al activitii de revizuire sau ar putea renuna la acesta. Tipurile de revizuire Un singur document poate fi supus mai multor tipuri de revizuire: de ex. o revedere informal poate precede o analiz tehnic, sau depinde de gradul de risc , revizia tehnic sau inspecia se poate aplica naintea controlului mpreun cu cumprtorul. Fiecare tip de revizuire are