Testarea Aplicatiilor Software. Studiu Privind Managementul Procesului Decizional

INTRODUCERE

Obiectivul lucrării este de a enunța mai întâi teoria care sta la baza testării software, iar apoi, o încercare de exemplificare a principiilor de testare enunțate pe o aplicație ce implementeaza un proces decizional.

Necesitatea acestei lucrări a fost determinată de:

Dezvoltarea software de mare anvergură din ultimele decenii, acesta devenind o parte intrinsecă a oricărei afaceri. Aproape orice afacere din orice domeniu contează pe aplicații informatice în dezvoltarea, producerea, marketing-ul și suportul produselor și serviciilor sale.

Procesul de detectare, localizare și rezolvare a defectelor care apar în cadrul aplicațiilor.

Combinarea diferitelor tipuri de testare(testarea unitara, testarea integrala, testarea sistemului, teste de regresie și testare de acceptare) este folositoare în realizarea aplicațiilor software.

Găsirea de modalități riguroase de a realiza cea mai bună aplicație software

Rețelele de calculatoare au o extindere rapidă într-o multitudine de domenii cum ar fi sistemul bancar, administrația publică, alocarea temporară de resurse în hoteluri, rezervarea biletelor de avion, rezervarea biletelor de tren etc. Aplicațiile moderne iau în considerare accesul unui număr cât mai mare de utilizatori, mai ales de când se prevede extinderea folosirii cardurilor și crește numărul personalelor care utilizează Internetul.

Testarea software este procesul căutării erorilor în program, indiferent dacă acestea au cauze logice sau fizice. Obiectivul principal al testării software este găsirea erorilor, altfel spus, de a identifica neconcordanța dintre ceea ce este planificat să efectueze aplicația și ceea ce realizează în realitate. Testarea nu presupune identificarea cauzei erorilor și corecția acestora, acestea fiind activități specifice depanării. Activitatea de testare trebuie asociată cu fiecare pas în procesul de dezvoltare. Acest lucru permite descoperirea erorilor devreme în procesul de dezvoltare software având drept consecință costuri mai mici de corecție.

IMM-urile(Întreprinderile Mici și Mijlocii) , ca forme specifice de organizare a activității economice, sunt în mod direct implicate în procesul de transformare impus mediului socio-economic de explozia tehnologică a ultimului deceniu.

Dacă in mod clasic, IMM-urile își desfășoară activitatea în interiorul frontierelor naționale, deplasarea economică spre piața virtuala conduce la posiblitatea internaționalizarii lor prin stabilirea cu mai multă ușurință a relațiilor de afaceri externe sau chiar prin cucerirea de piețe externe.

Mijloace. Pentru realizarea aplicației s-au studiat caracteristicile produselor software existente, unul dintre ele, modulul de workflow implementat de Oracle, precum și documente referitoare la procesul decizional și la activitatea de testare software. S-a ales realizarea aplicației în mediul de dezvoltare Microsoft Visual Studio Express .NET 2005, prin utilizarea unui web service de interpretare a datelor necesare pentru trimiterea emailurilor, precum și de avansare a decizilor la fazele următoare, a serverului de date Microsft SqlServer 2005, în cazul sistemului de administrare a comenzilor.

Abordarea demonstrează avantajele diverse oferite de instrumentele de dezvoltare existente la ora actuala pe piața si susține metodologia de construcție a sistemelor software:

Exploatează la maxim structura hardware și software existentă

Se potrivește modelului de business al beneficiarului

Oferă scalabilitate astfel încat orice element sa poata fi îmbuntățit daca este necesar

Oferă interoperabilitate: toate componentele sa lucreze împreuna ca un tot unitar

Oferă flexibilitate: orice componenta sau tehnologie nouă să poata fi cât mai ușor integrată in sistem

Oferă accesibilitate astfel incat solutia sa poata fi accesata, și de la distanță, cât și de pe platforme diferite de lucru

Are cel mai bun cost pentru beneficiar, fiind indicată întreprinderilor mici și mijlocii

Oferă posibilitatea de a lua decizii strategice in timp real

Urmărind o abordare tehnico-economică, lucrarea este fundamentată științific pe arhitectura a patru capitole. Gradat sunt tratate probleme legate de date si selectarea lor ca input-uri pentru procesul de testare, principalele tipuri și metode de testare software, urmând ca în final sa se exemplifice pe aplicația de realizare a workflow-ului în cadrul procesului decizional.

1. ACTIVITATEA DE DEZVOLTARE SOFTWARE

Un moment hotărâtor în dezvoltarea industriei software poate fi urmărit încă din anul 1969, când Departamentul de Justiție al Statelor Unite a forțat firma IBM sa separe software-ul dezvoltat de aceasta de hardware și i-a cerut sa vândă sau sa-și închirieze produsele. Înaintea acestui moment, aproape toate sistemele de operare și aplicațiile software erau dezvoltate de manufacturieri de hardware, dominați de IBM sau de programatori din organizațiile care îl foloseau. Dezvoltatorii de software, intre anii ’50 și ’60 lucrau independent sau în mici echipe în abordarea sarcinilor specifice, rezultând produse obișnuite, uzuale, fără prea multe complicații. Insa, după regula impusa de guvern, s-a dezvoltat foarte mult piața produselor software, dezvoltatorii și inginerii software au trecut printr-o serie de paradigme în dezvoltare[Egan99]

In anii ’70, îmbunătățirile capacităților de dezvoltare a dus la o necesitate a marilor companii de a folosi diferite activități automatizate, ca procesarea informațiilor. Utilitare simple ca limbaje de programare și programe de debug au fost introduse în scopul ajutării programatorului și de creștere a productivității acestuia. Introducerea calculatoarelor personale și procurarea acestora de către programatorii din întreaga lume, după 1980 a accelerat cererea de programe software, intr-un mod extraordinar de rapid.

Abordarea istorica a procesului de dezvoltare software, care s-a axat pe specificațiile și construcția sistemului era bazata deseori pe Modelul Cascada, definit ca în figura următoare[AndBerg95].

Modelul în Cascada

Acest model arata cum este împărțită dezvoltarea produsului software în funcție de procesele respective, astfel: mai întâi sunt analizate cerințele și problema în sine, apoi sunt desenate sistemele. Testarea se face în doua stadii: se testează funcționalitatea de baza a programului în sine, iar în faza următoare se testează programul în funcție de celelalte programe cu care poate acesta sa lucreze. Dezvoltarea se încheie cu operarea cu programul respectiv și mentenanța. Nu exista bucle decât intre starea curenta și cea precedenta sau următoarea stare. Aceste bucle de feedback de-a lungul întregului proces de dezvoltare software duce la determinarea parților din aplicație care pot fi refolosite. Acesta e atributul cheie în dezvoltarea software bazata pe componente(CBSD – Computer Based Software Development). Astfel în realizarea programelor nu se ia în considerare doar cerințele actuale doar un anumit modul, ci și capacitatea acestuia de a se integra și în alte posibile sisteme.

In anii ’60, ’70, dezvoltarea software era concentrată pe scrierea codului și testarea anumitor linii din cod. Se depunea puțin efort în determinarea gradului de integrare a noilor module cu un sistem mai mare. Testarea era văzuta ca un rău necesar cu scopul de a ii demonstra utilizatorului final ca produsul mergea. Andersson și Bergstrand estimau cam 80% din timpul dedicat atunci dezvoltării aparținea programării în sine și testării pe module(„unit testing”). Începând cu anii ’70, programatorii au început sa citească cerințele și sa analizeze în scopul proiectării unui sistem eficient, acest lucru ajungând chiar și pana la 20% din timp. Ulterior, aceștia au început sa aloce mai mult timp și resurse în integrarea diferitelor module ale aplicației și testarea acestora ca un sistem unitar, mai degrabă decât pe module. Efortul depus în dezvoltarea cerințelor și analiza acestora, au crescut forte mult în importanta, ajungând ca în zilele de azi, mai mult de 40% din timp sa fie alocat fazei de definire și analiza a cerințelor. De asemenea, proiectarea a ajuns la un procent de 30%, deoarece atunci se poate stabili în ce măsura un modul nou apărut poate fi reutilizat.

Abordarea istorică a dezvoltării software.

Limbajele de programare reprezintă unul din principalele mijloace de comunicare om-masină, evolutia lor fiind nemijlocit legată de cea a calculatoarelor electronice, a căror eră începe în 1944. Primele calculatoare puteau fi programate numai în limbaj masină, dar, chiar la începutul anilor ’50, se înregistrează trecerea la programarea simbolică, prin aparitia limbajelor de asamblare caracterizate prin folosirea codurilor mnemonice pentru instructiuni si a adresării simbolice a operanzilor. După aparitia primului limbaj de nivel înalt, limbajul FORTRAN (1954), se observă o proliferare accelerată a limbajelor de programare. Într-o listă considerată exhaustivă la data respectivă (1969), J.E. Sammet identifica 120 de limbaje de programare cu o largă utilizare; trei ani mai târziu, acelasi autor extindea această listă la 170 [Dodescu et al., 1987]. În primii ani ai deceniului opt, un sondaj efectuat în S.U.A. identifica, la nivelul unui singur domeniu de activitate – sistemele informatice ale armatei americane – utilizarea a peste 450 de limbaje de programare sau dialecte ale unor limbaje.

Evoluția tehnicilor de programare determină realizarea unor produse program caracterizate prin complexitate ridicată si prin consumuri de resurse reduse. Activitatea programului devine o dată cu eliminările restricțiilor impuse de sistemele de calcul o activitate de alocare si nivelare a resurselor software.

Dintr-o multitudine de limbaje, medii de programare si biblioteci de programe trebuie alese si asamblate acele componente care conduc la produse program performanțe. Pentru efectuarea unei alegeri corespunzatoare, resursele trebuie cunoscute în cele mai mici detalii.

2 . TESTARE DATE

2.1 Datele

În mod tradițional prin date înțelegem tot ceea ce face obiectul unor stocări, arhivări sau calcule. În continuare se impune efectuarea unei generalizări. Există, pe de o parte, realitatea, formată din obiecte, ființe, fenomene, acțiuni, interacțiuni, și pe de altă parte, datele cu ajutorul cărora sunt reflectate părți ale realității. Datele sunt rezultatul unor măsurători sau observații și fac obiectul stocării și/sau analizei. Ele se prelucrează, fundamentează decizii și determină acțiuni. Apar fenomenele de percepție, de receptare și de difuzare. Datele au trasee și reprezintă modalitatea principală de comunicare, de aceea, produsele software implementate trebuie să satisfacă cerințele de utilizare și performanță ale beneficiarului potențial.

Date numerice. Se consideră un alfabet format din simbolurile 0,1,2,3,4,5,6,7,8,9 și o regulă de construire a cuvintelor (numere)

<întreg fără semn>::=<cifră>|< întreg fără semn ><cifră>|<cifră><întreg fără semn>

pentru numere întregi fără semn. Astfel, 12345 este un număr întreg fără semn.

În același fel se definesc și întregii cu semn.

<semn>::=+|- <întreg cu semn>::=<semn><întreg fără semn>

În același fel se construiesc numerele zecimale, numerele cu exponenți. Datele numerice caracterizează durate ale unor acțiuni, dimensiuni ale unor obiecte, greutăți, presiuni sau alte caracteristici ale ființelor, plantelor, obiectelor, fenomenelor, acțiunilor și proceselor.

Pentru evaluarea și dezvoltarea proceselor social-economice, datele numerice sunt importante întrucât pentru ele s-au elaborat numeroși algoritmi de prelucrare statistică, care conduc la fundamentarea deciziilor sau la identificarea tendințelor de evoluție a fenomenelor.

Problemele care apar referitoare la datele numerice sunt strict legate de regulile de efectuare a măsurătorilor, de acuratețea asigurată, de intervalul de timp dintre două măsurători și de asigurarea completitudinii datelor în raport cu un anumit interval de timp și o anumită colectivitate descrisă. Datele numerice independente sunÎntr-o listă considerată exhaustivă la data respectivă (1969), J.E. Sammet identifica 120 de limbaje de programare cu o largă utilizare; trei ani mai târziu, acelasi autor extindea această listă la 170 [Dodescu et al., 1987]. În primii ani ai deceniului opt, un sondaj efectuat în S.U.A. identifica, la nivelul unui singur domeniu de activitate – sistemele informatice ale armatei americane – utilizarea a peste 450 de limbaje de programare sau dialecte ale unor limbaje.

Evoluția tehnicilor de programare determină realizarea unor produse program caracterizate prin complexitate ridicată si prin consumuri de resurse reduse. Activitatea programului devine o dată cu eliminările restricțiilor impuse de sistemele de calcul o activitate de alocare si nivelare a resurselor software.

Dintr-o multitudine de limbaje, medii de programare si biblioteci de programe trebuie alese si asamblate acele componente care conduc la produse program performanțe. Pentru efectuarea unei alegeri corespunzatoare, resursele trebuie cunoscute în cele mai mici detalii.

2 . TESTARE DATE

2.1 Datele

În mod tradițional prin date înțelegem tot ceea ce face obiectul unor stocări, arhivări sau calcule. În continuare se impune efectuarea unei generalizări. Există, pe de o parte, realitatea, formată din obiecte, ființe, fenomene, acțiuni, interacțiuni, și pe de altă parte, datele cu ajutorul cărora sunt reflectate părți ale realității. Datele sunt rezultatul unor măsurători sau observații și fac obiectul stocării și/sau analizei. Ele se prelucrează, fundamentează decizii și determină acțiuni. Apar fenomenele de percepție, de receptare și de difuzare. Datele au trasee și reprezintă modalitatea principală de comunicare, de aceea, produsele software implementate trebuie să satisfacă cerințele de utilizare și performanță ale beneficiarului potențial.

Date numerice. Se consideră un alfabet format din simbolurile 0,1,2,3,4,5,6,7,8,9 și o regulă de construire a cuvintelor (numere)

<întreg fără semn>::=<cifră>|< întreg fără semn ><cifră>|<cifră><întreg fără semn>

pentru numere întregi fără semn. Astfel, 12345 este un număr întreg fără semn.

În același fel se definesc și întregii cu semn.

<semn>::=+|- <întreg cu semn>::=<semn><întreg fără semn>

În același fel se construiesc numerele zecimale, numerele cu exponenți. Datele numerice caracterizează durate ale unor acțiuni, dimensiuni ale unor obiecte, greutăți, presiuni sau alte caracteristici ale ființelor, plantelor, obiectelor, fenomenelor, acțiunilor și proceselor.

Pentru evaluarea și dezvoltarea proceselor social-economice, datele numerice sunt importante întrucât pentru ele s-au elaborat numeroși algoritmi de prelucrare statistică, care conduc la fundamentarea deciziilor sau la identificarea tendințelor de evoluție a fenomenelor.

Problemele care apar referitoare la datele numerice sunt strict legate de regulile de efectuare a măsurătorilor, de acuratețea asigurată, de intervalul de timp dintre două măsurători și de asigurarea completitudinii datelor în raport cu un anumit interval de timp și o anumită colectivitate descrisă. Datele numerice independente sunt rezultatul măsurării unor caracteristici primare, de bază ale obiectelor, ființelor sau fenomenelor. Datele numerice dependente sunt și ele rezultatul unor măsurători (de regulă de verificare) dar, în realitate, reprezintă prelucrări, de obicei de tip agregare, ale unor date numerice independente.

În multe domenii datele numerice apar atât sub forma de date independente (primare), cât și sub forma de date rezultative (dependente). De exemplu, ștatul de salarii conține date independente cum ar fi nume, vechime, număr ore lucrate, salariu orar și date derivate în categoria cărora se înscriu impozitul, pensia, sporurile și salariul net. Tot în rândul datelor derivate intră și totalurile pe coloane, reprezentând sume care se ridică de la bancă sau sume care se datorează statului sub formă de contribuții și impozite.

Datele alfabetice. În rezolvarea unor probleme cu ajutorul calculatorului se folosesc date de tip alfabetic. Astfel sunt date denumiri de localități, nume de persoane, nume de țări. Multe prescurtări (mnemonice) cu care se operează și multe cuvinte cheie ale limbajelor de programare sunt date de tip alfabetic. Pentru caracterizarea elementelor unei mulțimi prin date de tip alfabetic, în primul rând se definește un alfabet format din simboluri numite litere. Lor le corespund sunete articulate din vorbirea oamenilor. În al doilea rând, se construiesc reguli de utilizare a simbolurilor, în vederea construirii de cuvinte. Se are în vedere performanța indivizilor de a pronunța și de a reține. Aici apar elementele de similitudine și ortogonalitate dintre cuvinte. În timp ce similitudinea evidențiază elemente comune din construcția a două cuvinte, ortogonalitatea, din contră, vizează diferențierea maximă dintre acestea.

Astfel, cuvintele cascador, cascadă și cascadorie au un grad de similitudine destul de ridicat. Cuvintele read și write, des întâlnite ca instrucțiuni în limbajele de programare au un nivel de ortogonalitate maxim.

Sunt situații în care creează o corespondență între text și forme grafice. Astfel, după descrierea verbală a unor persoane se construiesc portretele robot cu ajutorul cărora se identifică persoane. Pentru a se realiza acest lucru, se predefinesc valori ale elementelor definitorii ale fizionomiei unui individ, cum ar fi: frunte, ochi, nas, bărbie. Aceste valori se referă la expresia verbală folosită și forma grafică ce corespunde descrierii verbale. Din multitudinea de combinații ale elementelor de fizionomie rezultă o gamă variată de indivizi. Prin fixarea valorilor particulare, aplicându-se elementul de fizionomie echivalent descrierii verbale, se obține imaginea vizuală generală a unui individ. Datele alfabetice se regăsesc în orice tipuri de descrieri in care apare necesitatea de comunicare între doi sau mai mulți indivizi.

Date alfanumerice. Sunt reprezentate prin cuvinte construite din alfabetul rezultat din concatenarea literelor cu cifrele. Datele alfanumerice sunt cel mai frecvent întâlnite. De exemplu se poate scrie: "este ora șapte și douăzeci de minute", sau mai simplu: "este ora 7h20`" Un alt exemplu: propoziția "A trecut autobuzul liniei o sută doi cu numărul patru mii cinci sute șaizeci și șapte" se va rescrie "A trecut autobuzul liniei 102 cu numărul 4567".

Utilizarea numerelor adaugă precizie în prezentarea persoanelor, obiectelor, acțiunilor sau fenomenelor. Aplicațiile informatice prelucrează atât date numerice, alfabetice cât și alfanumerice. Mecanismele de regăsire a informației folosesc indecși care sunt date numerice, și chei de regăsire, care sunt de tip alfanumeric.

Rapoartele, cererile, cărțile științifice includ atât date numerice cât și date alfabetice, deci sunt rezultate ale unui vocabular obținut prin reuniunea a două vocabulare. Sistemele de codificare, pentru a se obține o probabilitate de criptare care să le facă operaționale, sunt bazate pe alfabete extinse, dintre care cel rezultat din litere și cifre este cel mai des întâlnit.

Date grafice. Lumea reală este un subiect permanent al reprezentărilor cu ajutorul petelor de culoare. Datele grafice se obțin prin mijloace "mecanice" precum fotografierea, filmarea și înregistrarea pe suport magnetic. Datele grafice se obțin prin mijloace artistice cu ajutorul vopselelor și al pânzei, al creionului, al cărbunelui sau al altor materiale cu ajutorul cărora se redau simbolurile grafice.

Date spațiale. Preocuparea pentru reprezentarea în spațiul tridimensional este veche. Datele spațiale au un caracter atât de cuprinzător încât utilizarea acestui limbaj devine foarte cuprinzătoare. Existența vieții este rezultatul comunicării. Comunicarea nu înseamnă numai cuvinte spuse sau scrise, receptate sau citite de o altă persoană. Comunicarea include toate schimburile care există între două sau mai multe sisteme. Comunicarea include cuvinte, simboluri. Efectuând o astfel de abordare se obțin similitudini între domenii foarte variate, cu efecte benefice asupra dezvoltării acestora.

Pentru a exemplifica toate aceste tipuri de date, vom face referire la aplicația pe care am realizat-o.

Astfel, pentru modulul de situații decizionale care apar în cadrul une companii, am reținut, s-au retinut date de tip alfabetice si alfanumerice. Se observa un camp numit description care poate ocupa maxim 255 caractere si în care am preferat sa rețin note și observatii legate de situația decizionala cu care se confrunta managerul, sau firma, la un moment dat.

În mod similar pentru tabela utilizatori, se vor memora date legate de utilizatorii care au acces în aplicație.

Astfel, pentru ei se va reține numele de login, parola, funcția ocupata de acesta în cadrul companiei, numǎrul de telefon, precum si adresa acestuia, data angajarii de tip data, adresa de mail care este de tip alfanumeric și se va încerca o tratare a modului în care este verificaǎ în momentul inserării și încercării de salvare a unor valori care nu sunt conforme cu template-ul de email și nu în ultimul rând rolul acestuia în aplicație. Astfel, putem preciza că sunt 3 tipuri de persoane care se pot loga în aplicație. Pentru rol=valoarea 1, el va intra în pagina de administrare a utilizatorilor și va avea posibilitatea de creare de noi utilizatori. Pentru valoarea 2, se va putea loga in pagina de definire a tipurilor de decizii, a fazelor, notificărilor și a template-urilor de mail care vor urma a fi trimise utilizatorilor în anumite faze ale procesului decizional.

2.2 Operații pe date

Adăugarea de date. Se consideră un șir inițial de date D={d1, d2, &, dn}. Se consideră că adăugarea se efectuează fie la începutul fie la sfârșitul șirului și că se adaugă unul sau mai multe elemente. Dacă la șirul D se adaugă elementul dn+1, se va obține un nou șir D'={d1, d2, &, dn, dn+1}. Dacă la șirul D se adaugă elementul d0, se va obține șirul D"= {d0, d1, d2, &, dn}.

Dacă se consideră zilele anului și se înregistrează zilnic un indice bursier, se construiește șirul b1, b2, &, b365, unde bi reprezintă indicele bursier din ziua i a anului. Șirul {bi} rezultă prin adăugare la sfârșit, element de element.

Un tabel T este format din rândurile r1, r2, &, rk. Dacă se face o nouă înregistrare în tabel, se va obține șirul r1, r2, &, rk, rk+1, prin adăugare. Disciplina ultimul venit, ultimul înscris (UV-UÎ) corespunde tuturor situațiilor de lucru pe liste.

Există și situații în care adăugarea se efectuează în fața primului element. De exemplu, putem considera o garnitură de tren. Suplimentarea de vagoane se efectuează atât în raport cu ultimul vagon, cât și în raport cu primul.

Inserarea de date. Se consideră șirul b1, &, bi, bi+1, &, bn de date. Elementul α este inserat între elementele bi și bi+1, rezultând un șir cu n+1 componente: b1, &, bi, α, bi+1, &, bn.

Inserarea este frecvent întâlnită în toate domeniile de activitate. Scopul în care se realizează inserarea de elemente este de a aduce un spor de cunoaștere, de calitate. În realitate, este posibil să nu se obțină acest efect.

Inserarea de date, indiferent de natura lor, este însoțită de creșterea volumului textului inițial. Accepțiunea largă de alfabet (simboluri) de cuvinte implică automat creșterea ariei conceptului de text.

Ștergerea de date. Se consideră șirul format din elementele b1, b2, &, bi-1, bi, bi+1, &, bn. Ștergerea elementului bi conduce la obținerea șirului b1, b2, &, bi-1, bi+1, &, bn.

Să considerăm un vocabular ale cărui cuvinte sunt reprezentate din elemente altele decât cele din lingvistică. Arderea unui manuscris este tot o ștergere. Fiecare filă este un cuvânt. Cuvintele dispar unul câte unul. Dacă din șirul b1, b2, &, bn sunt șterse rând pe rând toate cuvintele, va rezulta textul vid. Scoaterea unor opere din manualele de liceu este o operație de ștergere

Interschimbul de date.Interschimbul de date corespunde situației în care în șirul b1, b2, &, bi-1, bi, bi+1, &, bj-1, bj, bj+1, &, bn, elementul bi ia locul elementului bj, șirul devenind b1, b2, &, bi-1, bj, bi+1, &, bj-1, bi, bj+1, &, bn.

În tabele se procedează la interschimb de date pentru a reflecta ordinea acestora după criteriul mărimii au al momentului efectuării unor operații.

Modificarea datelor. Modificarea datelor este o operație complexă care se poate efectua în mai multe moduri. Una dintre modalitățile de efectuare este prin înlocuirea unei date cu alta. Aceasta echivalează cu înlocuirea elementului bi sin șirul b1, b2, &, bi-1, bi, bi+1, &, bn cu elementul α, șirul devenind b1, b2, &, bi-1, α, bi+1, &, bn. În al doilea rând, modificarea presupune efectuarea unei operații pe un cuvânt dat. De exemplu, în șirul cod material b1, cantitate existentă în stoc b2, cantitate intrată b3, cantitate ieșită b4, la elementul b2 se adună un număr obținându-se b2', care reprezintă existentul în stoc modificat. Ieșirile b4 se pot diminua, devenind b4'.

Concatenarea de date. Se consideră șirurile b1, b2, &, bn și c1, c2, &, cm. Prin concatenare rezultă șirul b1, b2, &, bn, c1, c2, &, cm. Exemple de concatenări sunt colecțiile de legi și decrete, culegerile de folclor, operele complete, colecțiile de artă, obiectele expuse în muzee cu diverse tematici. Cărțile de istorie sunt rezultatul concatenării de capitole care se referă la evenimente diferite.

Stocarea datelor. Datele se stochează pe diferiți suporți. Stocarea datelor pe hârtie se întâlnește în cazul documentelor de evidență, documentelor istorice și a producțiilor tipografice în general și înscrisurilor oficiale sau private. Documentele se îndosariază, se codifică și se arhivează. Stocarea datelor pe suporți magnetici este cea mai modernă formă de stocare. Datele în acest caz sunt concatenate în fișiere, baze de date, depozite de date.

Făcând referire la aplicația de urmărire a workflow-ului procesului decizional, se poate spune că s-a încercat pe cât posibil asigurarea funcțiilor de adaugare, stergere și inserare pentru fiecare modul al aplicației.

2.3 Calitatea datelor

Calitatea este unul dintre cei mai importanți indicatori pentru evaluarea competitivității unei activități. Calitatea nu poate crește fără concentrarea conducerii asupra aspectelor calității. Managementul calității presupune în primul rând luarea deciziilor pe baza unei cunoașteri clare și foarte corecte a realității. Primul pas în rezolvarea unei probleme cronice este recunoașterea faptului că aceasta există. Datele de slabă calitate reprezintă regula și nu excepția, dar multe organizații se află într-o stare de negare a existenței acestei probleme.

  Avantajul competitiv poate rezulta din îmbunătățirea calității datelor. Datele slabe din punct de vedere calitativ pot avea un impact economic și social substanțial, prin impunerea unor costuri enorme și de cele mai multe ori ascunse asupra operațiilor care au drept suport acele date. Există un acord general asupra faptului că datele pot fi extrem de costisitoare, deoarece datele sunt de cele mai multe ori cele mai importante resurse ale unei organizații. Calitatea ridicată nu doar reduce costurile, dar crește și disponibilitatea și bunăvoința clientului de a plăti pentru bunurile și serviciile oferite, ceea ce duce la îmbunătățirea poziției competitive.

  Datele noncalitative există sub diverse forme, inclusiv:

date redundante, conducând la costuri de producție ridicate;

date incomplete sau neactualizate, conducând la alterarea imaginii firmei;

 date slab definite, ceea ce duce la folosirea eronată a informației.

  Întrucât aplicația este realizată în ASP.NET, cu utilizarea unei baze de date din Microsoft SqlServer, prin intermediul adapterilor si data seturilor, se poate asigura o actualizare a tuturor datelor care sunt memorate, acest lucru fiind benefic pentru firma precum și pentru colaboratori, aceștia având posibilitatea în orice moment de a avea acces la date reale, putându-și forma o idee despre situațiile decizionale apărute, la zi.

În continuare se furnizează definiții și liste de atribute ale celor mai frecvent menționate douăzeci dimensiuni ale calității datelor: 

credibilitate (de încredere sau credibile): gradul în care datele sunt acceptate sau privite ca adevărate, reale și credibile. După cum am spus mai sus, având în vedere comunicarea între aplicație și baza de date care se realizează cu ajutorul sql data adapterilor care genereaza data-seturi, la fiecare refresh, se poate spune că datele care sunt afișate în aplicație sunt și cele reale, păstrate în BD. Este adevarat ca nu fac un update de tip real time, dar totuși capacitatea de a afișa date credibile este destul de ridicată.

valoare adăugată (datele oferă un avantaj competitiv, datele adaugă valoare activității economice): gradul în care datele aduc beneficii și furnizează avantaje prin folosirea lor. Întrucât procesul decizional se bazeaza pe problemele apărute la nivelul unei companii sau grup de companii este necesar ca documentația si partea de suport al acesteia să fie facută în regula. Faptul că decizia se ia pe baza datelor afișate de către aplicație, cu siguranță că este procesul fundamental de documentare și luare a celei mai bune decizii. Așadar, valoarea activității economice, cu siguranță crește.

relevanță (aplicabile, relevante, interesante, folositoare): gradul în care datele sunt aplicabile și folositoare pentru activitatea de realizat. În urma unei analize profunde a procesului decizional, s-a ajuns la concluzia că nu trebuie să se stocheze în baza de date decât minimul de date necesar. Astfel, se poate spune ca gradul de relevanță al datelor tinde spre maxim.

acuratețe, exactitate (datele sunt certificate ca fiind fără erori, corecte, fără greșeli, erorile pot fi identificate cu ușurință, integritatea datelor, date precise, exacte): gradul în care datele sunt corecte, de încredere, și certificate ca fiind fără erori. Este foarte adevarat că în orice aplicație se pot introduce greșeli, voie sau nevoite, făcute de persoana care le introduce, dar, având în vedere faptul ca datele pot fi ușor modificate, existând operația de update pe orice modul din aplicație, în cazutl în care se determină date incorecte, inexacte, ele pot fi ușor remediate.

interpretabilitate (interpretabile): gradul în care datele sunt prezentate într-un limbaj adecvat, definirile sunt clare. Pentru persoanele care știu deja în ce constă un workflow, nu neapărat pentru procesul decizional, este foarte probabil ca fatele care apar ca fiind introduse de utilizatori, pot fi interpretate ușor. Pentru celelalte persoane, însă, se va asigura o perioadă de training care va sta la baza înțelegerii ulterioare a valorilor datelor preluate din baza de date.

ușurința înțelegerii (ușor de înțeles, clare, ușor de citit): gradul în care datele sunt clare, fără ambiguități și ușor de înțeles. În măsura în care datele au fost introduse corect și legăturile au fost bine realizate, după perioada de training acordată, ar trebui ca procesul de funcționare a aplicației sa fie corect înteles și astfel, va crește gradul de ușurință al întelegerii.

accesibilitate (accesibile, ușor de regăsit, viteza de acces, disponibile, actuale): gradul în care datele sunt disponibile sau ușor de regăsit. Datorită utilizării interfeței C# .NET și a facilităților oferite de acesta, ActiveX Data Object (ADO) – ADO.NET are la bază limbajul XML, asigurând în acest mod un nivel ridicat de portabilitate și accesibilitate a datelor.

obiectivitate (imparțiale, obiective): gradul în care datele sunt neprejudiciate și imparțiale. Gradul de obiectivitate al datelor introduse este relativ la persoana care introduce cererea – situația decizională la care s-a ajuns, acest lucru neputându-se garanta. În schimb, modul în care sunt tratate datele în interiorul aplicației, este același pentru datele de același tip, în ideea ca nu se face diferențiere, de exemplu, între situațiile decizionale care apațin aceluiași tip(”Decizii simple”).

oportunitate (oportune): gradul în care vechimea datelor este adecvată pentru activitatea de realizat. Decizia, componenta primara a sistemului decizional, constituie un element esențial al managementului, fiind instrumentul sau specific de exprimare, nivelul calitativ al conducerii unei organizații manifestându-se prin deciziile elaborate si aplicate. Deci, datele trebuie sa fie oportune.

completitudine (cantitatea, detalierea și domeniul informațiilor conținute în date): gradul în care datele acoperă calitativ și cantitativ domeniul activității de realizat. Cu siguranță decizional necesită multe alte informații decât cele utilizate în aplicație, dar, dat fiind faptul ca poate fi considerată o variantă inițială a proiectului, o variantă Alfa, care va fi apreciată de client în funcție de nevoile sale, vor putea fi făcute modificări în urma unei analize asigurând un grad de completitudine cât mai apropiat de valoarea maxima cerută de client.

posibilitatea de urmărire (bine documentate, ușor de urmărit, verificabile): gradul în care datele sunt documentate, verificabile și au sursa ușor de identificat. Având in vedere faptul că softul poate fi utilizat de o companie sau de un grup de companii și că utilizatorii aplicației sunt credibili, putând furniza documente cu privire la cerințele sau problemele care apar, pentru a demonstra corectitudinea lor, posibilitatea de urmărire a datelor poate fi considerată mare.

reputație (reputația sursei datelor, reputația datelor): gradul în care datele sunt apreciate din punct de vedere al sursei sau conținutului lor. Introducerea datelor în aplicație se va face la sediul clientului, de către utilizatorii asignati de către un administrator. Placând de la ideea că există un contract încheiat între firmă și angajații săi, cu siguranță nici un angajat nu va prejudicia activitatea firmei.

consistența reprezentării (datele sunt în mod continuu reprezentate în același format, reprezentate consistent, formatate consistent, datele sunt compatibile cu date istorice): gradul în care datele sunt mereu prezentate în același format și sunt compatibile cu formatele precedente. Prin utilizarea bazelor de date, se asigură introducerea de date omogene, necontând momentul introducerii acestora, interfața fiind aceeași.

eficiența din punct de vedere al costului (costul acurateței datelor, costul achiziției datelor): gradul în care costul achiziționării datelor potrivite este rezonabil. Plecând de la ideea ca un produs software o data achiziționat se face pe baza unui fond de calculatoare, disponibil, introducerea datelor nu presupune un cost mult prea mare.

ușurința operării (ușor de realizat joncțiuni, ușor de modificat, ușor de actualizat, ușor de descărcat, încărcat, datele pot fi folosite în scopuri multiple, manipulabile, ușor de agregat, ușor de reprodus, datele pot fi ușor integrate, ușor de customizat): gradul în care datele sunt ușor de manevrat și manipulat (de exemplu, actualizare, mutare, agregare, reproducere, customizare). Prin utilizarea produsului Microsoft SqlServer, toate datele se stochează într-o bază de date care permite portabilitatea. Actualizarea datelor se face foarte rapid prin interfața asigurată de ADO .NET, iar interogarea, prin intermediul adapterilor sql folositi în aplicație care generează dataseturi pentru orice tabela folosită, se face de asemenea foarte ușor.

varietatea datelor și a surselor (există o varietate a datelor și a surselor acestora): gradul în care datele sunt disponibile din mai multe surse diferite. Aplicația s-a încercat a fi foarte flexibilă astfel încât să permită introducerea de mai multe tipuri de decizii în funcție de necesitățile clientului, introducerea lor, putând fi făcută de orice utlizator care are dreptul de a intra in aplicație. Asfel, se poate spune ca varietatea datelor este cât se poate de ridicată.

concizie (bine prezentate, concise, reprezentate compact, bine organizate, plăcute din punct de vedere estetic, forma de reprezentare, bine formatate, formatul datelor): gradul în care datele sunt reprezentate compact, nu în cantități foarte mari (de exemplu, prezentare scurtă, totuși completă și la obiect). Datorită părții vizuale asigurate de C# .NET, formatarea datelor se face destul de bine, aplicația fiind considerată a fi, din punct de vedere estetic, foarte plăcută. Reprezentarea se face in pagini diferite de tip .aspx, folosind un control de tab care permite efectuarea operațiilor de adăugare, modficare, vizualizare și ștergere, simulând pagini diferite.

securitatea accesului (datele nu pot fi accesate de către competitori, datele sunt proprietatea companiei, accesul la date poate fi restricționat și securizat): gradul în care accesul la date poate fi restricționat, și astfel protejat. Deoarece se poate intra in aplicație doar prin intermediul unui cont de utilizator cu o parola aferentă, capacitatea de trecere peste aceasta pagină este limitată. Astfel se seteaza o variabila pe care o pun in Session, de exemplu: Session["IsUserLogged"] care ia valoarea true, dacă utilizatorul s-a logat cum trebuie, în caz contrar aceasta fiind null sau false. Astfel, în orice pagină aș vrea să intru, testez:

if (Sesion["IsUserLogged"] != null && Sesion["IsUserLogged"] == true)

atunci, intru în pagina respectivă. În caz contrar, se face o redirectare la login page.

cantitate suficientă de date (cantitatea de date): gradul în care cantitatea sau volumul de date este adecvat. Gradul de satisfacere a cantității datelor stocate depinde de client și de necesitățile acestuia.

flexibilitate (adaptabile, flexibile, extensibile, expandabile): gradul în care datele sunt expandabile, adaptabile și răspund cu ușurință și altor cerințe. Gradul de flexibilitate al datelor este cat se poate de mare, orice parte din aplicație putând fi configurată în funcție de dorințele clientului în măsura în care asocierile între entități se face cum trebuie.

2.4 Certificarea datelor

A certifica datele de intrare ale unei aplicații înseamnă a evidenția principalele calități ale datelor, cum ar fi:

completitudinea,

corectitudinea,

credibilitatea,

acuratețea / exactitatea,

securitatea accesului

relevanța

A certifica rezultatele unei prelucrări înseamnă a evidenția:

–         verificarea unor corelații suplimentare față de caracteristicile datelor inițiale,

–         existența unei structuri definite ,

–         corectitudinea prelucrărilor în toate cazurile de utilizare.

Certificarea datelor este un proces complex care vizează orice fel de date, având în vedere utilitatea și importanța acestora.

  Un aspect important al certificării datelor îl reprezintă certificarea bazelor de date. Certificarea bazelor de date vizează:

stabilirea concordanței dintre conținutul enunțat și cel existent,

verificarea existentului cantitativ de date,

verificarea concordanței dintre documentele inițiale și cele existente.

De exemplu într-o bază de date cu acte juridice se iau în considerare: intervalul de timp, tipurile actelor normative, sursele de unde se preiau datele, persoanele responsabile cu introducerea și verificarea datelor, tehnicile de regăsire a datelor etc. Certificarea acestei baze de date se face pas cu pas sau prin sondaj.

Certificarea datelor este strâns legată de procesul de testare a datelor. Testarea datelor înseamnă parcurgerea unor etape prin care sunt evidențiate caracteristicile de calitate pentru seturi concrete de date. Testarea datelor evidențiază că acestea sunt reprezentative, complete, corecte, sunt înzestrate cu acuratețe.  

Testarea completitudinii datelor înseamnă definirea conceptului de completitudine în contextul fiecărui document inclus într-un flux sau în contextul lansării în execuție a unui produs software. Testarea caracteristicii de calitate completitudinea, înseamnă extragerea dintr-o mulțime de documente a unui eșantion reprezentativ și cuantificarea gradului de completitudine în raport cu criteriile definite anterior. De exemplu se consideră documentele de tipuri T1, T2, …, Tn. Se extrag pentru verificarea completitudinii documente de tipul Tk, Tj, Tr, unde k, j și r {1, 2, …, n}. Pentru mulțimea tipurilor de documente T1, T2, …, Tn se identifică o structură caracterizată prin frecvențele F1, F2, …, respectiv, Fn. Se calculează frecvențele relative p1, p2, …, pn și pentru Tk, Tj, și Tr se extrage un eșantion în care să se regăsească elementele structurii pk, pj, respectiv, pn. Fiecare tip de document Ti este caracterizat printr-un număr Mi de câmpuri. În fiecare formular se completează anumite câmpuri, nu toate. Se contorizează numărul câmpurilor completate din fiecare formular și se construiește un indicator Ci, al gradului de completitudine: 

Ci =

 unde:

Ci – este indicatorul gradului de completitudine

S – numărul de formulare de tip Ti de document din eșantion;

mij – numărul de câmpuri din documentul j al eșantionului de tip Ti;

Mi – numărul standard al câmpurilor care definește documentul.

  Testarea datelor în raport cu caracteristica de completitudine nu se oprește la calculul indicatorului Ci, ci merge mai departe la introducerea datelor din eșantion, la prelucrarea acestora cu un produs software considerat și la analiza completitudinii rezultatelor finale.

  În același fel se procedează și pentru testarea celorlalte caracteristici ale datelor în raport cu aplicații informatice complexe.

  Testarea datelor devine importantă atunci când utilizatorii de software au depășit stadiile obținerii de hardware și de software necesar prelucrărilor, materia primă – datele reprezentând singurul factor de influențare a rezultatelor finale.

  Rezultatele testării datelor au rolul de a restructura documente, de a redimensiona efortul de completare a documentelor și de a crea modalități specifice de introducere date pentru a obține aplicații clasice sau aplicații pe Internet operaționale. 

Calitatea datelor care sunt stocate în baze de date accesate prin Internet trebuie să fie asigurată întrucât beneficiarii le accesează în vederea declanșării unor activități (cumpărare de produse, cumpărare de servicii turistice, înscriere la universități, preluare de componente din biblioteca digitală, extragerea de tabele din statistica oficială). De aceea, se impune urgentarea elaborării unor convenții foarte largi pentru protecția aplicațiilor pe Internet și elaborarea unor standarde care să definească obligativitatea asigurării completitudinii, corectitudinii, fiabilității, acurateței, credibilității, exactității, relevanței datelor la nivele care să le dea caracter operativ. Chiar dacă la început aceste restricții nu sunt perfecte, ele sunt perfectibile. Legile juridice, standardele creează un cadru instituțional, generează specializări care au rolul să impună o limitare severă a noncalității.

3. TESTARE SOFTWARE

3.1 Obiectivele testării software

Testarea se face atât pentru un produs software luat ca un întreg, cât și pentru componentele acestuia. Dacă se testează sistemul de programe procesul se desfășoară da la simplu spre complex. Se testează mai întâi modulele apoi programul și în final sistemul de programe ca ansamblu complex. Rezultatele asamblării, software integrat, este testat în continuare (integration testing).

Atingerea tuturor ramurilor din fiecare modul presupune dezvoltarea grafului asociat modulului și corespunzător generarea de date de test care să activeze nodurile grafului. Testarea software are un caracter statistic prin activarea selectivă a unor ramuri din structura arborescentă asociată programului.

Efectul testării-corectării este nelinear atât ca volum de erori corectate, cât și ca volum de erori introduse. Testarea este un proces cu periodicitate, însoțit de efect de ondulanță. Eliminarea tuturor erorilor este însoțită de costuri mari. De aceea se impune găsirea unui echilibru între numărul erorilor rămase în software și costul eliminării.

În condițiile dezvoltării software după toate cerințele definite prin tehnologii, testarea software nu este necesară. Cum însă aceste condiții nu sunt îndeplinite integral, testarea apare ca singura posibilitate de a face software operațional. Este componentă a etapelor procesului de dezvoltare software. Fiecare etapă aduce erori specifice, ceea ce implică modalități, de asemenea, specifice, de testare.

Primul obiectiv al testării este acela de a determina obținerea de programe bune. Un program este bun din punct de vedere al producătorului și același program este bun din alt unghi, dacă este privit de utilizator. Rezultă că nu întotdeauna un program bun din punctul de vedere al producătorului este bun și din punct de vedere al utilizatorului.

De dorit este ca producătorul să canalizeze eforturile pentru a dirija structura programelor așa fel încât acestea să fie bune mai ales din punct de vedere al utilizatorilor. Neîncrederea în software generează situații în care programe comandate nu sunt achiziționate, programe achiziționate nu sunt utilizate, multe programe sunt abandonate sau se solicită elemente de mentenanță.

Al doilea obiectiv al testării este evidențierea comportamentului software în situații particulare (de excepție). Se consideră un sistem de programe care utilizează fișiere. Componentele se activează separat, controlul creării de fișiere nefiind posibil. Se testează cum se execută programul care utilizează fișiere, atunci când acestea lipsesc. Rolul testării este acela de a pune în evidență punctele slabe ale programului. Adică situațiile în care programul nu oferă rezultate corecte, ba mai mult determină întreruperea execuției și transferul controlului spre funcții ale sistemului de operare.

În al treilea rând, rolul testării este de a stabili locul, momentul producerii unei erori și tipul acesteia. Stabilirea cauzelor de producere a erorilor stau în seama celor care au construit programul. Testarea determină acumularea de experiență și conduce la dezvoltarea de secvențe, proceduri, module care elimină neajunsuri anterioare și ridică pe un plan superior activitatea de programare.

În al patrulea rând, testarea are menirea de a pune în evidență măsura în care un program realizează ceea ce este descris în specificații. Specificațiile descriu rapoartele (ieșirile) pe care le editează/afișează un program, modul de calcul și informațiile inițiale (datele de intrare).

Se consideră seturi de date de test și se evidențiază dacă programul:

editează/afișează rapoartele indicate în specificații;

conduce la obținerea de rezultate corecte;

activează prin datele de test toate secvențele.

3.2 Specializarea în testarea software

Testarea presupune preluarea software și a specificațiilor. De asemenea, sunt utilizate și aplicațiile software care asistă procesul de testare. Se construiesc exemple de test și se utilizează exemplele furnizate în specificații. Toate acestea presupun o calificare adecvată.

Personalul specializat în testarea software trebuie să cunoască tehnicile de analiză, proiectare și programare orientate obiect, să înțeleagă problema pe care programul o rezolvă și să aibă capacitatea de a distinge diferențele care apar între rezultatele oferite de program și cele obținute prin specificații sau rezultate proprii.

În literatura de specialitate, persoana care se ocupă de testare software se numește software tester. Procesul de testare se recomandă a fi independent de producător și de utilizator pentru a asigura rigurozitatea rezultatelor și a interpretării corecte a acestora. Testerul elaborează totalitatea rapoartelor privind rezultatele testărilor cu indicarea tipurilor de erori identificate. De asemenea, testerul colectează date despre erori ale programului la utilizatori, reproduce condițiile de obținere a lor și confirmă în rapoarte noi tipuri de erori neidentificate în procesul de testare curentă. Testerul clasifică erorile, le stabilește frecvențele și cuantifică efectele pe care acestea le generează la utilizatori. Rapoartele finale sunt cele care direcționează dezvoltarea de versiuni de lucru. Variantele sunt specifice perioadei de colectare de date privind comportamentul software direct de la utilizatori.

Software complex este testat în cadrul echipei de testeri. Organizarea echipei vizează specializare pe tipuri de aplicații și în cadrul tipurilor de aplicații pe tipuri de funcții de prelucrare. La nivelul programării orientate obiect testarea software trece dincolo de identificarea de erori și atinge și laturile calitative ale definirii, referirii de clase și obiecte. Prezintă importanță intensitatea cu care sunt referite clase deja existente în biblioteci. De asemenea testarea pune în evidență măsura în care sunt realizate nivelele de încapsulare, moștenire și polimorfism.

3.3 Economia testării software

În dezvoltarea software, există o serie de costuri asociate testării programelor, pentru că trebuie să se:

– realizeze planul de testare;

– scrie cazurile de testare;

– seteze echipamentul necesar testării;

– execute sistematic cazurile de testare;

– urmărească problemele identificate;

– înlăture defectele găsite în aplicații.

Se poate întâmpla să se găsească și defecte puțin importante care să nu fie repetate datorita necesității de implementare a codului și are ca urmare o creștere a costurilor de producere a produsului software. Aceste efecte pot rămâne in produsul implementat pana la următorul release său pentru totdeauna. Daca însă se întâmplă să se livreze produsul cu defecte mai grave este posibil ca ele să fie descoperite de clienți având ca urmare o pierdere a încrederii acestora in capacitățile firmei in cauza. Pe lângă încrederea pierduta, clientul își poate pierde de asemenea și o parte din bani, trebuind ca programatorul să ia avionul pentru a ajunge la client cu scopul de a remedia problema. Acest lucru presupune pe de o parte costul deplasării și a rezolvării problemelor s pe de alta parte neimplicarea clientului in determinarea apariției defectului.

Calitatea produsului software realizat depinde de natura activității, de exemplu, un produs software pentru aviație trebuie să fie mult mai calitativ decât un joc. De aceea in primul caz este necesară o testare mult mai ampla ajungându-se la un timp și cost alocat de pana la de 3-5 ori mai mult decât in cazul testării sistemelor simple.

Pentru a minimiza costul testării, un scop al testării software consta in descoperirea a cat mai multor defecte posibile intr-un timp cat mai scurt. Cu alte cuvinte, se solicita scrierea de cazuri de test care au o capacitate cat mai mare de descoperire a defectelor. Este aproape imposibila testarea tuturor posibilităților / combinațiilor de input/output.

3.4 Tipuri de testare software

Există două tipuri principale de testare software, “blackbox testing ” și “whitebox testing”. Testarea software este una din metodele V&V (verificare și validare). Alte practici V&V sunt “unit testing”, inspecții și programarea pe echipe. Prin verificare , se asigură implementarea corectă a anumitor funcții. De exemplu, prin rularea unor teste specifice, se poate verifica că noile date introduse nu pot avea aceleași valori cu cele existente. Prin validare, ne asigurăm că ceea ce s-a implementat s-a făcut in concordantă cu cerințele clienților. De exemplu, se validează ca o valoare adăugată de noi pentru o variabilă poate fi ștearsă din sistem. [Boehm] a făcut o prezentare scurtă într-o fază pentru a reliefa diferența dintre verificare și validare.

Verificare “Se implementează corect produsul”

Validare “Se implementează produsul cerut”

In „blackbox testing”, testerul software nu are său nu ar trebui să aibă acces la cod. Codul se considera a fi o cutie neagra in care nu se poate vedea nimic. Se știe doar ca se pot introduce diferite date in cutia neagra, care va trimite ceva in schimb, pe baza operațiilor ce se fac in interior. Pe baza cerințelor clientului, testerul software știe la ce să se aștepte ca rezultat din cutia neagra, și verifica doar daca rezultatele sunt conforme cu rezultatele predefinite pe baza cerințelor.

In mod alternativ, „whitebox testing” se bazează pe structura interna a codului. Testerul „whitebox” este adeseori rezultatul codului respectiv, el știe cel mai bine cum arata codul și realizează cazuri de testare executând funcții cu diferiți parametri.

Revenind la verificare și validare, „blackbox testing” este folosita deseori pentru validare („implementam ceea ce ni s-a cerut”) și „whitebox testing” este folosita pentru verificare („implementam software-ul cum trebuie”).

3.5 Metode și niveluri de testare software

Ar trebui să se încurajeze planificarea cazurilor de testare cat mai devreme și să se execute cat mai des posibil. Este mult mai economic să se elimine defectele (din cod și din documente) cat mai devreme posibil, imediat ce ele au fost introduse in cod.

Se poate preveni aparitia defectelor sau cel putin eliminarea lor in cel mai scurt timp daca odata cu primirea documentatiei si planificarea cazurilor de testare se trece la executarea lor imediat ce apare un cod ce implementeaza cerintele din documentatie.

Exista diferite niveluri de testare ce ar trebui să se realizeze pe un sistem software dezvoltat.

„unit testing” – folosind testarea „whitebox testing”, testerii (de obicei dezvoltatorii aplicației software) certifică daca codul face ceea ce ar trebui, la un nivel software foarte jos. De exemplu, testerul va scrie un cod de testare care va apela o metoda cu anumiți parametri și se va asigura ca returnează o valoare predefinită pe baza cerințelor clientului. Când este disponibil, programatorul va examina nivelul de proiectare a aplicației. In celelalte cazuri, testerul va examina structura codului, uitându-se chiar el in cod. „Unit testing” este in general realizata intr-o clasă său o componenta. Având în vedere faptul că aplicația realizată este foarte bine modularizată, ea permite realizarea de „unit testing”. Astfel, se poate face un astfel de tip de testare, pe modulul de tipuri de decizie, întru-cât e cel mai simplu modul.

De exemplu, am urmatoarea bucată de cod:

public bool ShowViewInformations(int id)

{

DataLayer.dsNotif.NotificariRow dr = dlDecizie.GetCampuriNotif().Notificari.FindByID(id);

if (dr!=null)

{

txtNotif.Text = System.Web.HttpUtility.HtmlEncode(dr.name);

txtTempl.Text = System.Web.HttpUtility.HtmlEncode(dr.description);

return true;

}

else

return false;

}

private void btnView_Click(object sender, System.EventArgs e)

{

PD.NetControls.RowSelectorColumn rsc = PD.NetControls.RowSelectorColumn.FindColumn (this.GridNotificari);

if(NoSelection())

return;

int IDNotifSelectata = System.Convert.ToInt32(GridNotificari.DataKeys[rsc.SelectedIndexes[0]]);

ShowViewInformations(IDNotifSelectata);

TabNotif.ActiveTab = (int)Tabs.VIEW_NOT;

}

Un exemplu de Unit Testing poate apărea așa:

„Integration testing” – folosește ambele tehnici de testare („whitebox” și „blackbox”), testerul (in cazul in care programatorul nu are timpul necesar) verifica integrarea părților componente intr-o baza mai mare de cod. Doar pentru faptul ca fiecare modul in parte funcționează individual, nu înseamnă și ca atunci când sunt asamblate, se poate, constata ca interfețele dintre module nu au fost implementate corect, ca mesajele de eroare nu au fost definite corect. Pentru planificarea cazurilor de test pentru integrare, testerii se uita atât la nivelurile superioare cat și la cele inferioare de proiectare aflate in documentație.

„Functional & System testing” – folosind tehnica „blackbox testing”, testerii examinează proiectarea la nivel înalt și analiza cerințelor utilizatorilor, pentru a realiza cazurile de tastare care vor verifica daca aplicația face ceea ce se cere. „Functional testing” implica verificarea funcționalității specificate in cerințele clienților. „System testing” implica testarea programului in cat mai multe medii (sisteme de operare și alte programe cu care are legătura său care ar putea-o împiedica să funcționeze etc.). Astfel se poate testa pe o interfata de Windows XP, Windows NT respectiv 2000.

„Acceptance testing” – după „Functional & System testing”, produsul este livrat clientului, care va rula propriile teste „blackbox acceptance” bazându-se pe propriile înțelegeri ale cerințelor. Aceste teste sunt deseori predefinite și trimise care departamentul de testare al firmei care implementează aplicația. Clientul își rezerva dreptul de a refuza produsul daca testele de acceptare eșuează. Testele sunt de obicei rulate in medul clientului. Pentru a se asigura ca testele vor funcționa pe calculatoarele clientului este necesar ca departamentul de testare să ruleze testele primite de la client și să-și realizeze și execute propriile teste de acceptare.

„Regression testing” – pe parcursul întregii implementări sunt rulate cazuri de testare de regresie. Ele sunt o subcategorie a cazurilor de testare originale. Ele sunt rulate des după orice modificare semnificativa (repararea defectelor sau remodelări). Scopul acestor teste este de a verifica daca noul cod rulează corect și nu s-a stricat nimic din ceea ce s-a implementat înainte.

In cazul sistemelor mici și medii (cu cel mult 100 clase) studiul și re-rularea testelor de regresie este fezabilă. Din moment ce testele de regresie se rulează in tot ciclul dezvoltării, se poate folosi metoda „whitebox” „regression testing” la nivel de Unit & Integration și „blackbox” la integration, function, system & nivelul testelor de acceptare.

In momentul alegerii testelor de regresie, trebuie avute in vedere următoarele:

se alege un set de teste reprezentativ care analizează întregul sistem de funcții ale aplicației software respective.

se aleg acele teste care pot verifica componentele (funcțiile) care s-au modificat.

Se aleg cazuri de testare adiționale ce se refera la funcțiile care pot și afectate in mod direct sau indirect de modificare.

Este esențial ca testarea să se înceapă imediat ce perioada de analiza a cerințelor clientului s-a terminat. Astfel, ar trebui să se înceapă scrierea cazurilor de testare de tip „blackbox testing”. Prin acest lucru, testerii pot determina daca cerințele sunt incomplete. Echipa poate pune întrebări clientului sau analistului software cu scopul de a clarifica cerințele in vederea realizării unui plan de testare bine pus la punct. Răspunsul la aceste întrebări este folositor și dezvoltatorului ca, codul să fie altfel proiectat și implementat încât să permită execuția testelor automate.

Pentru a concluziona, testarea și planificarea testelor la orice nivel al implementării aplicației este cel mai bun lucru pentru a minimiza timpul de dezvoltare.

3.6 Relația dintre nivele, tipuri și instrumentele de testare

Anumite tipuri de testare software sunt asociate cu nivele de testare particulare. In timpul acestor activități de testare, sunt asociate diferite tipuri de testare cu diferite parți ale industriei software.

H=heavy, M=medium, L=light

3.7 Testarea automată

În noua economie, producătorii de soluții IT sunt confruntați cu o nouă cerință care îi obligă să schimbe total modul de construcție a unui produs, fără a face compromisuri de calitate. A fi primul pe piață cu ultimele tehnologii este mai important ca oricând. Lucrând cu o infrastructura software și hardware din ce în ce mai complexă, confruntați cu creșterea continuă a cerințelor de calitate și cu necesitatea reducerii costurilor, firmele de software încep să prețuiască tot mai mult soluții solide, inginerești, de dezvoltare de software. Testarea produsului este în software o componentă majoră în procesul de dezvoltare. În limbaj de specialitate se discută despre asigurarea calității (Quality Assurance). Firmele din industria tradițională – de ex. industria de mașini, de construcții, de produse electronice sau alimentare au de zeci de ani departamente de testare și verificare a calității. În materie de software, organizarea și automatizarea muncii de testare și verificare a produselor a început din motive istorice evidente abia în anii '80.

Testarea manuală, mult timp văzută ca singura soluție de a descoperi eventualele defecte, întârzie foarte mult lansarea pe piață a produsului și induce cheltuieli semnificative mai ales în cazul descoperirii efectelor laterale – atât în procesul dezvoltării unei aplicații cât și în cazul de schimbări ulterioare.

Totodată procedurile de testare manuală, prin natura lor limitată, nu reușesc să descopere toate defectele și nu au nici o șansă să simuleze condiții de utilizare simultană, intensivă, a unei aplicații.

Există numeroase căi de a îmbunătăți procesul de testare, una dintre cele mai eficiente fiind testarea automată.

Testele automate execută o secvență de acțiuni fără intervenție umană și pot simula utilizarea unei aplicații în condiții de simultaneitate ridicată. În general, majoritatea produselor necesită să fie testate de mai multe ori, pe mai multe platforme software și hardware, ca și după schimbările ulterioare sau la lansarea unei noi versiuni de produs. Prin folosirea testării automate, costurile testărilor repetate se reduc aproape la zero.

Cele mai importante beneficii sunt:

acoperirea tuturor etapelor de testare de la concepție până la lansare

posibilitatea simulării testării cu mai mulți utilizatori

posibilitatea repetării testelor

creșterea siguranței în produs.

Un sistem de testare automată trebuie să aibă la bază două caracteristici principale:

module reutilizabile

întreținerea și urmărirea activității dintr-un singur punct de control

De aceea una din calitățile care trebuie să le aibă un astfel de sistem este capabilitatea de a fi ușor configurat și adaptat în același ritm cu software-ul ce se testează.

Sistemele de testare automată sunt o tehnologie în plină dezvoltare care au ca scop descoperirea și raportarea eventualelor defecte, mărirea longevității produsului și reducerea procesului de întreținere.

Testarea automată înseamnă mai mult decât o simplă captură de ecran și răspunsul la câteva scripturi : ea trebuie să înceapă cu planificarea și design-ul procedurii de testare, să conțină o serie de teste repetabile, o interfață de management al scenariilor de test și un mecanism de raportare și gestionare a bug-urilor descoperite în urma testării. Un sistem de test evoluat sprijină utilizatorii printr-un sistem de documentare pe tot parcursul acestui proces.

Într-o abordare mai detaliată testarea automată înseamnă:

planificare

identificarea cerințelor și a funcționalităților

gruparea acestora în condiții de test

crearea cazurilor de test pentru aceste condiții

design

construcția scripturilor de test

generarea testelor de rulare

execuție

crearea scenariului de rulare a scripturilor

rularea uneltelor monitor pentru înregistrarea datelor

înregistrarea rezultatelor pentru fiecare rulare

raportarea și gestionarea bug-urilor

management

generarea rapoartelor și graficelor

controlul dintr-un singur punct de comandă

documentarea permanentă a stadiului curent al proiectului

3.7.1 Tipuri de testare automată

structurală (white-box testing) – se verifică structura software-ului și necesită acces complet la codul sursă. Acest tip de testare verifică dacă structura codului este eficientă: bucle complicate, zone de date comune, mii de linii de cod încurcate sunt numai câteva din problemele care pot fi îndepărtate. Scopul acestui test este mărirea performanței aplicației și a lizibilității codului.

funcțională (black-box testing) – se definesc așteptările clientului de la aplicație și se verifică automat dacă software-ul se comportă conform acestor așteptări. Prin testele ce se execută se observă comportamentul aplicației, evidențiat prin datele de ieșire, fără a se face referire la funcțiile interne.

regresivă (regression testing) – se verifică dacă s-a modificat neașteptat comportamentul aplicației în urma implementării unor noi cerințe/schimbări (change requests).

negativă (negative testing) – se solicită aplicația, producând deliberat cazuri complicate, neobișnuite sau particulare pentru a forța apariția erorilor.

de solicitare (stress testing) – se determină capabilitățile absolute ale aplicației și ale infrastructurii pe care este implementată; cu ajutorul acestui tip de test se dezvăluie caracteristicile de performanță ale unui sistem menținut în condiții de încărcare totale, adică sunt pornite și rulate toate serviciile care în mod normal ar fi fost rulate separat în timp și independent.

de performanță (performance testing) – în urma acestui tip de testare se verifică dacă performanța aplicației este adecvată pentru cerințele stabilite, în termeni de viteză de acces, resurse de sistem utilizate și procesarea cererilor de acces.

de încărcare (load testing) – se determină punctele slabe ale aplicației și dacă sunt necesare îmbunătățiri ale infrastructurii hardware sau software prin măsurarea caracteristicilor de performanță și scalabilitate a principalelor componente ale aplicației web; de regulă aceasta se realizează prin creșterea numărului de sesiuni utilizator sau a conexiunilor TCP/IP.

3.7.2 Limitele testării automate

Sunt multe lucruri pe care uneltele de testare automată nu le pot face și este important să se cunoască aceste limitări pentru a alege pe cea mai potrivită. Un sistem de testare automată nu poate spune când ceva "arată bine" pe ecran sau când o poză sau fereastră nu este bine încadrată. De asemenea un test automat nu poate decide dacă logica programului are lipsuri funcționale decât în măsura în care au fost definite complet cerințele aplicației respective. Unele teste, mai ales pentru aplicații mici și pentru aplicații care se concentrează mai ales pe grafică și nu pe business logic, sunt mult mai ușor realizabile de către operatorul uman decât de către un computer. De aceea trebuie alcătuit un plan bine definit al procedurii de testare, când, unde și în ce condiții este fiabilă introducerea automatizării.

3.7.3 Tipuri de unelte pentru testarea automată

Sistemele de testare automată pot include unelte de genul :

GUI , prin folosirea metodei "înregistrare/redare"

analizoare de cod – analizează complexitatea codului scris, respectarea unor standarde de scriere a codului

analizoare de memorie – detectează depășirea memoriei alocate, suprascrieri în zone nealocate și zone rămase nedealocate

testare de solicitare/performanță – pentru testarea aplicațiilor web și client/server în diferite scenarii de solicitare

testare servere web – verifică validitatea și integritatea link-urilor, a codului html, programe client-side și server-side, securitatea transmiterii datelor

alte unelte – pentru managementul documentației, raportării bug-urilor, configurației, etc.

3.7.4 Procesul testării automate

Majoritatea uneltelor de testare automată sunt compatibile cu entitățile software ce intervin pe traseul de la clienți la furnizorul de aplicații. În orice punct de pe traseu se pot face teste si evaluări de performanță. În diagrama de mai jos sunt prezentate cele mai cunoscute și utilizate componente software ce intervin într-un astfel de proces.

Procesul de testare automată presupune un efort de management deosebit. Acest proces începe încă din faza de analiză a aplicației și continuă în toate etapele de dezvoltare. În diagrama următoare se pot observa etapele procesului, ordinea și frecvența acestora, precum și locul central pe care îl ocupă managementul defectelor și serviciile. Un factor important este menținerea centrală a comunicării între etape pentru managementul bug-urilor.

3.8 Comparație între testarea manuală și automată

Testarea manuală și testarea automată sunt mai degrabă două procese diferite, decât două căi diferite de a executa același proces : dinamica lor este diferită precum și modul de a releva bug-urile.

AVANTAJE

DEZAVANTAJE

Testarea manuală este mai folositoare în situațiile în care este nevoie urgent de rezultatele unor tipuri de teste specifice și limitate, când se dorește ca timpul de feedback să fie foarte scurt, iar costurile să fie relativ mici. Cum îmbunătățirea calității produsului implică costuri adiționale pentru găsirea bug-urilor și gestionarea acestora până la repararea lor definitivă, testarea manuală s-a dovedit a fi în timp extrem de costisitoare. Testarea manuală pe scară largă presupune alocarea de resurse hardware și umane destul de mari, iar riscul să apară erori este amplificat de factorul uman.

Testarea automată necesită un efort inițial mai mare pentru planificarea, organizarea și producerea testului, criteriul principal în obținerea de rezultate bune fiind planificarea atentă, amănunțită și precisă a acestuia.

O alternativă interesantă este așa-numita "testare parțială". Această soluție este combinație de jumătate testare manuală și jumătate testare automată, aceasta din urmă fiind folosită numai acolo unde se pot obține beneficii maxime.

Testarea automată se dorește a fi soluția ideală pentru reducerea timpului de dezvoltare și a costurilor. O echipă de testeri poate să pornească uneltele de testare automată, să le lase să ruleze și în final să colecteze și analizeze rezultatele. Timpul este astfel mai bine organizat și poate fi petrecut pentru izolarea și raportarea bug-urilor.

În zilele noastre sunt multe unelte pe piață care pot ajuta la planificarea, execuția și crearea de rapoarte în activitatea de testare. Majoritatea acestor unelte necesită cunoștințe de specialitate pentru a le implementa și utiliza corespunzător. De asemenea, este bine de știut, că suitele profesionale de unelte specializate în asigurarea calitătii oferă întotdeauna un produs de sine stătător care preia partea de management de proiect și pe cea de bug reporting/ticketing. Un asemenea produs este de exemplu TestDirector de la firma Mercury Interactive – market leader în materie de produse pentru asigurarea calității.

Soluțiile elegante pentru testarea sistemelor sofisticate sunt adesea limitate numai de imaginația tester-ilor.

Câteva dintre avantajele utilizării testării automate sunt:

a) avantaje privind eficiența și costurile

prevenirea erorilor prin abordarea structurată a procesului de dezvoltare a proiectului

detectarea erorilor ce au ajuns până în faza de producție(teste de regresie automată)

reutilizarea informației acumulate (condiții de test, scripturi)

reducerea creării de noi scripturi (refolosindu-le și adaptându-le pe cele vechi)

execuția automată a testelor de performanță în fazele de început ale proiectului poate evita eforturile de redesign în fazele ulterioare

odată ce scripturile de testare automată sunt implementate, o parte din personal poate fi redirecționat către alte necesități

b) avantaje privind economia de timp

analiză rapidă și exactă în cazul schimbării parametrilor sistemului

durată scurtă a ciclurilor de testare

estimări mai exacte pentru procesul de planificare a testului

posibilitatea efectuării mai multor teste (scripturile de testare pot fi rulate și după orele de program economisind astfel timp)

generarea rapidă a condițiilor de testare

c) avantaje privind calitatea

o mai bună înțelegere a scopului testării

o acoperire mai mare a elementelor de testat

rezultate mai consistente datorită repetabilității testelor

compararea automată a rezultatelor

Făcând referire la aplicația de urmărire a desfășurării procesului decizional, am schițat folosind un instrument de testare automată pe care l-am avut la dispoziție, un exemplu de test cu următorii pași:

Astfel, am generat un test care se loghează cu userul: felicia, parola: felicia, intră in pagina de Configurare, selectează Definire de Tipuri decizionale. Intră in pagina de definire, selecteaza un tip de decizie și apasă butonul de View. Este deschis astfel tabul de vizualizare a tipului decizional, cu numele si descrierea aferentă care au fost salvate in baza de date, apoi, se apasă butonul de Close și ulterior, Logout.

După rularea automată a testului, se obțin rezultatele ce pot fi văzute în pozele atașate. Se testează astfel, atât partea funcțională a aplicației cât și cea vizuală( html, imagini, frame-uri, scripturi, linkuri invalide etc.). Dupa cum se poate vedea, procentul de trecere a testului este de 100%. Problema se pune in felul următor: există posibilitatea ca de la o variantă la alta a aplicației, să se facă modificări in cod, și se poate ca unele elemente sa nu fie acolo unde au fost înregistrate. Pentru ca testele sa ruleze neluând în considerare chestiile de imagine, cel mai bine ar fi să se scoată testarea de interfață și să se lase doar partea de testare funcțională.

De asemenea, pentru ca testele sa poată rula cu o serie de alte date, diferite de cele introduse la înregistrarea testului, este important să se mapeze variabilele înregistrate pe o serie de variabile interne care-si vor prelua conținutul dintr-un fișier excel de tip *.csv. Acest lucru este foarte util în simularea testării cu mai mulți utilizatori, pentru metodele de Stress Testing și Performance Testing.

În concluzie, testarea automată nu va putea înlocui în întregime testarea manuală și nici nu trebuie. Tester-ii pot să observe cum un utilizator poate interacționa cu produsul, în timp ce un sistem de testare automată nu poate întotdeauna să prevadă aceste acțiuni sau să găsească cea mai bună cale de a le testa. Dacă sunt bine folosite, programele de testare automată măresc considerabil productivitatea QA, economisesc costuri, măresc semnificativ consistența și calitatea produsului și ajută la optimizarea și accelerarea procesului de dezvoltare al unei aplicații. Deja există cerința ca toate produsele software din sectorul militar, medical, guvernamental și financiar să fie testate cu unul din sistemele recunoscute de testare automată, iar rapoartele automate asupra felului cum a decurs testarea constituie baza acceptării unei aplicații de către client.

4. WORKFLOW-UL PROCESULUI DECIZIONAL

4.1 Decizia si procesul decizional în management

Pentru o buna perioada de timp managementul a fost considerat o adevărată arta, talent însușit prin învățarea din încercări si erori. O varietate de stiluri individuale, deseori bazate pe creativitate, raționament uman, intuiție si experiența au fost folosite în rezolvarea problemelor de același tip, si aceasta în defavoarea metodelor cantitative si a abordărilor științifice. Complexitatea afacerilor si a mediului de desfășurare a acestora a crescut însă simțitor în ultimele decenii. Managerii eficace trebuie să ia decizii pentru a soluționa problemele care apar în cadrul organizațiilor. Este necesar să se ia o decizie atunci când sunt îndeplinite următoarele condiții: există o discrepanță între rezultatele dorite și situația actuală, decidentul este conștient de această discrepanță, este motivat să o elimine și dispune de resursele necesare pentru aceasta. Așadar, decizia constituie punctul central al activității de management întrucât ea se regăsește în toate funcțiile acestuia, si mai mult, integrarea firmei în cadrul mediului depinde de calitatea deciziei. În același timp, calitatea procesului decizional influențează reducerea costurilor, eficiența folosirii fondurilor, creșterea profitului etc.

4.2 Caracteristici fundamentale ale deciziei

Decizia, componenta primara a sistemului decizional, constituie un element esențial al managementului, fiind instrumentul sau specific de exprimare. În fond, nivelul calitativ al conducerii unei organizații se manifesta prin deciziile elaborate si aplicate.

Decizia de conducere reprezintă procesul de alegere a unei linii de acțiune în scopul realizării unor obiective, prin a cărei aplicare se influențează activitatea a cel puțin unei alte persoane decât decidentul Nicolescu98.

Deciziile manageriale, spre deosebire de deciziile generale, se refera la misiunea, strategiile si politica pe termen lung ale firmei, coordonarea principalelor domenii de activitate, atingerea eficientei dorite, soluționarea si medierea conflictelor, masuri de maxima importanta pentru viitorul firmei.

Luarea deciziilor reprezintă activitatea centrală a unui manager; toate celelalte activități sunt desfășurate pentru a se asigura luarea de decizii corecte sau, dacă decizia a fost deja adoptată, pentru implementarea și monitorizarea eficienței sale.

În practică decizia manageriala îmbracă doua forme: actul decizional si procesul decizional. Actul decizional se refera la situații decizionale de complexitate redusa, cu caracter repetitiv sau în care variabilele implicate sunt foarte bine cunoscute de către decident. Procesul decizional implica un consum mare de timp, pe parcursul căreia se culeg si analizează informații, se consulta persoane în vederea conturării situației decizionale. În esența procesul decizional consta într-un ansamblu de etape prin intermediul cărora se pregătește, adopta, aplica si evaluează decizia manageriala.

Procesul rațional de luare a deciziilor constă dintr-o serie de pași pe care managerii îi urmează, fie formal, fie pe baza intuiției, în alegerea alternativei considerate optimă.

Acești pași sunt: identificarea problemei, generarea de soluții alternative, selectarea alternativei celei mai benefice, implementarea alternativei alese și obținerea de feedback în vederea evaluării eficacității deciziei([COR04]).

Pasul întâi: identificarea problemei. Una dintre dificultățile pe care le ridică rezolvarea de probleme o reprezintă identificarea corectă a problemei. Se întâmplă uneori ca managerii să se grăbească să aleagă alternative înainte de a fi identificat problema fundamentală.

Obstacole în calea definirii corecte a problemei. Problemele nu sunt întotdeauna evidente, și în calea identificării lor pot sta o serie de obstacole, a căror depășire permite managerilor să vadă care este cu adevărat problema. Printre aceste obstacole cele mai întâlnite sunt:

·         Acordarea de atenție efectelor, iar nu cauzelor. Prea frecvent se întâmplă ca managerii să definească problemele în termenii simptomelor, iar nu în termenii cauzelor.

·         Percepția selectivă. Datorită faptului că fiecare dintre noi deținem o serie de percepții bazate pe experiența personală, managerii au adesea tendința de a defini problemele în termenii dictați de trecutul și instruirea lor. Pentru a depăși obstacolul pe care îl constituie percepția selectivă, managerii trebuie să ia în considerare mai multe puncte de vedere înainte de a defini problema.

·         Definirea problemelor prin soluții. Problemele trebuie să fie definite precis, fără asocierea lor cu anumite soluții. Ce este o problemă? Procesul identificării problemelor este esențial pentru selectarea celei mai bune alternative. Managerii eficienți caută în permanență să identifice ocaziile și problemele care apar în mediu.

În acest stadiu al luării deciziei managerii se pot ajuta de una dintre următoarele abordări:

Abateri de la performanțele anterioare. Dacă există un tipar stabilit al nivelului satisfăcător de performanțe și acesta se modifică, managerii sunt alertați de apariția unei probleme.

Abaterea de la plan. Problema sau problemele pot fi sugerate de apariția unei discrepanțe între performanțe și rezultatele prevăzute.

Primirea de feedback. Managerii pot descoperi existența unei probleme din discuțiile cu furnizorii și clienții organizației sau cu subalternii sau superiorii lor ierarhici.

Concurența. Performanțele organizației din care face parte managerul în raport cu cele ale concurenților săi reprezintă un indicator al existenței unor eventuale probleme.

Pasul al 2-lea: generarea de soluții alternative. Odată ce problema a fost identificată, al doilea pas în procesul de luare a deciziilor îl reprezintă generarea de soluții alternative. În această fază a procesului decizional este esențială creativitatea.

O abordare care permite stimularea creativității în faza de generare de soluții alternative o reprezintă brainstormingul. Într-o ședință de brainstorming, un număr de indivizi cheie sunt adunați cu scopul de a genera abordări alternative pentru rezolvarea unei probleme date, indiferent de cât de nepotrivite ar putea părea aceste alternative. Una dintre regulile brainstorming-ului o reprezintă faptul că nu sunt permise evaluarea sau criticarea sugestiilor, astfel că participanții se simt liberi să își exprime părerile. Ideile generate în ședințele brainstorming reprezintă uneori alternative importante și demne de luat în seamă în procesul de luare de decizii.

În căutarea de alternative, decidenții se confruntă cu o serie de constrângeri care limitează numărul de alternative, și care pot fi cauzate de resursele financiare limitate, de factorul uman din organizație, care poate limita posibilitatea de implementare a anumitor alternative, sau de facilitățile materiale neadecvate. Este important ca decidenții să cunoască aceste constrângeri, în așa fel încât să nu fie consumat în mod inutil timpul cu evaluarea unor alternative care nu sunt viabile, și să fie eliminată posibilitatea ca alternative semnificative să nu fie luate în calcul datorită faptului că managerii nu cunosc obstacolele pe care aceste alternative le pot întâmpina.

Pasul al 3-lea: selectarea alternativei optime. După identificarea soluțiilor alternative, acestea trebuie să fie evaluate și comparate în termenii fezabilității și consecințelor lor. Este apoi aleasă cea mai bună decizie pentru obiectivele organizației.

Selectarea alternativei optime poate părea un proces de identificare a avantajelor și dezavantajelor fiecărei alternative și de alegere a alternativei preferate sau a celei optime. Din nefericire, alegerea este dificilă atunci când decizia este complexă și implică mari grade de nesiguranță sau risc. Iată câteva dintre aceste dificultăți:

1.       Două sau mai multe variante pot părea la fel de atractive. În aceste condiții este nevoie de o mai atentă analiză și evaluare a acestor alternative de către decident.

2.       Este posibil ca nici o alternativă să nu permită atingerea în întregime a obiectivului stabilit. În aceste condiții, este de dorit implementarea a două sau chiar trei alternative.

3.       În situația în care nici una dintre alternative nu ar permite atingerea obiectivului stabilit, este nevoie de o revenire la etapa căutării de alternative.

4.       Decidentul poate fi confuz din cauza numărului mare de alternative atractive, fiind nevoie în această situație de o mai atentă comparare și evaluare.

Datorită faptului că managerii nu au cunoștință de toate alternativele existente și de consecințele acestora, ei pot alege prima alternativă care le va da impresia că poate rezolva problema.

Pasul al 4-lea: implementarea soluției alese. Odată ce a fost aleasă o alternativă, trebuie luate măsuri de implementarea a acesteia, deoarece chiar și cea mai bună decizie cu putință este inutilă dacă nu este transpusă în practică în mod eficient.

Cheia implementării eficiente o reprezintă buna comunicare și planificarea acțiunilor. Indivizii care sunt afectați de decizie trebuie să fie informați și trebuie să li se solicite sprijinul pentru implementarea planului. Resursele trebuie obținute și alocate (împărțite între departamente și proiecte în așa fel încât să permită atingerea obiectivelor organizaționale). Managerii stabilesc bugetele și planurile operaționale detaliate, permițând monitorizarea progreselor. Se atribuie apoi responsabilitatea îndeplinirii sarcinilor anumitor departamente și persoane.

Implementarea, deși a fost identificată ca etapă distinctă a procesului decizional, este legată de toate etapele acestuia și reprezintă legătura cu fiecare dintre funcțiile manageriale.

Pasul al 5-lea: urmărire și evaluare. Evaluarea este o etapă a procesului decizional neglijată de obicei, deși reprezintă un element esențial. Managerii eficienți vor dori întotdeauna să compare rezultatele reale cu cele prevăzute pentru a vedea dacă problemele au fost rezolvate cu adevărat.

4.3 Elemente ale procesului decizional

Procesul decizional este definit ca fiind o serie de pași care încep cu analiza informației, continua cu selectarea dintre mai multe alternative si verificarea alternativei selectate pe problema aflata în studiu.

In orice proces decizional de management se regăsesc următoarele elemente:

         Decidentul este reprezentat de persoana sau grupul de persoane care urmează sa aleagă varianta optima din cele posibile. În cazul problemelor complexe decizia se ia de către un grup de persoane, iar în cazul deciziilor curente, operative deciziile sunt luate de o singura persoana. Calitatea deciziei depinde de calitățile, cunoștințele, aptitudinile decidentului.

         Problema decizionala. Decizia se adopta pentru soluționarea unei probleme decizionale. În absenta problemei decizia nu are obiect.

         Obiectivele deciziei sunt nivelele propuse de către decident pentru a fi atinse în urma implementării variantei decizionale alese.

         Utilitatea fiecărei consecințe a diferitelor variante se exprima în aceeași unitate de măsura care variază între 0 si 1, utilitatea reprezentând folosul așteptat de decident în urma faptului ca o anumita consecința se realizează

Mai sunt și alte componente care însă nu ne interesează.

Informația – element esențial în cadrul procesului decizional. Importanta informației si a sistemelor informatice a fost sintetizata de J. Naisbitt în rezultatul unui calcul care a încercat sa determine câte procente din forța de munca a Statelor Unite este direct implicata în crearea, utilizare sau distribuirea de informație. Având în vedere ca studiul a fost realizat la începutul anilor '80 rezultatele sunt impresionante, chiar si pentru Statele Unite – procentul de asa-numiti knowledge workers s-a dovedit a fi în jur de 70 din total. Dezvoltarea tehnologiei informaționale a condus la includerea informației ca a șasea resursa organizațională, alături de resursele umane, mașini, resursele financiare, materiale si management. Chiar in condițiile intangibilității, informația reprezintă o modalitate extrem de eficienta si economica de a reuni celelalte resurse ale firmei. In plus, informația este utilizata atât pentru asistarea celorlalte cinci resurse în coordonarea activităților organizaționale, cât si pentru planificarea, direcționarea si controlarea acestor activități.

După cum considera Peter Drucker, "Cele mai multe decizii trebuie sa se bazeze pe cunoștințe incomplete, fie deoarece informația nu este disponibila, fie pentru ca ar costa prea mult în timp si bani pentru a o obține" Drucker73. Totuși, pentru a lua decizia corecta, managerii trebuie sa aibă la dispoziție informații relevante care duc la creșterea cunoștințelor, reduc incertitudinea, si sunt utile pentru scopul propus.

4.4 Decizia de grup

Mecanismul cel mai semnificativ al relației conducător-grup îl reprezintă luarea in grup e deciziilor.

Sunt din ce in ce mai prezente manifestări ca: dorința de participare in comun la construirea perspectivei unității in care lucrează, certitudinea ca fiecare este folosit in folosul succesului colectiv, siguranța ca in rezultatele obținute se evidențiază corect si stimulativ contribuția fiecăruia.

Luarea in grup a deciziilor antrenează si afectează de cele mai multe ori acțiunile si interesele unei anumite colectivități.

In afara acestor elemente si factori, deciziile mai sunt influențate si de nivelul mai înalt de pregătire si experiența a conducătorului, care are in acest fel, acces la un număr însemnat de surse de informare, ceea ce mărește numărul factorilor care trebuie luați in considerare, îngreunând procesul individual de luare a deciziilor.

In condițiile unei decizii bazate pe o contribuție exclusiva, sau in cea mai mare parte individuala, este greu de imaginat motivarea ei fata de participanți, in vederea executării.

Lipsa unei colaborări permanente, a unei consultări pe tot parcursul elaborării unei decizii, va determina un sentiment de frustrare la colaboratori si va face greu de realizat decizia respective.

Problema luării deciziilor, analizata teoretic, ca si experiența practica a multor întreprinderi au demonstrat ca deciziile importante cele mai corespunzătoare sunt luate in condițiile participării colective si deliberative, la pregătirea lor.

Luarea deciziilor prin cooperare creează condiții de dezvoltare a spiritului de echipa, de creștere a cunoștinței si responsabilității lucratorilor.

După adoptarea deciziei, urmează in mod necesar o etapa de control a tuturor elementelor ce au stat la fundamentarea deciziei; aceasta reprezintă o analiza care supune unei examinări de ansamblu factorii, împrejurările si rațiunile care au condus la decizia luata. Analiza si încheie cu stabilirea de detaliu a planului de aplicare, identificarea, cu multa atenție a tuturor dificultăților posibile precum si a cailor de rezolvare. Aceasta analiza finala este deosebit de importanta si nu se recomanda a fi neglijata. Daca consecințele deciziei nu sunt in concordanta cu cele așteptate sau daca dificultățile de aplicare sunt importante, se impune o reconsiderare totala; aceasta poate conduce la reluarea ciclului de la început, respectiv inițierea unui nou proces de analiza a deciziei.

Avantaje și dezavantaje ale deciziilor de grup

Avantaje:

1.       În procesul decizional de grup sunt generate mai multe informații și sunt utilizate mai multe cunoștințe.

2.       Sunt generate mai multe alternative decizionale.

3.       Implicarea în aplicarea deciziei finale va fi mai mare din partea celor implicați.

4.       Se poate ajunge la îmbunătățirea comunicării, datorită faptului că managerii implicați își informează subalternii în legătură cu motivele luării deciziei.

5.       În selectarea alternativei optime, grupurile pot fi mai dispuse să își asume riscuri mai mari decât decidenții individuali.

6.       Creșterea creativității rezultată din existența mai multor abordări și puncte de vedere diferite.

7.       Subalternii își îmbunătățesc capacitatea de a lua decizii.

Dezavantaje:

1.       Procesul decizional de grup durează mai mult și presupune deci costuri mai mari.

2.       Datorită faptului că grupurile nu pot răspunde pentru succesul implementării, această abordare poate determina apariția unei situații în care nimeni nu este răspunzător.

3.       Membrii grupului pot fi presați să accepte decizia preferată de majoritate; de asemenea, unul sau mai mulți membri pot domina grupul, reducându-i eficacitatea.

4.       Deciziile de grup pot fi, în unele situații, rezultatul compromisului sau al indeciziei unei părți a grupului.

5.       Indivizii pot începe să creadă că ar trebui să fie implicați în toate deciziile, inclusiv în cele care în mod normal sunt unilaterale și impuse din partea superiorilor.

6.       Poate interveni fenomenul numit “gândire de grup”.

4.5 IMM-urile și avantaje ale folosirii softului procesului decizional în luarea deciziei

IMM-urile, ca forme specifice de organizare aactivității economice, sunt în mod direct implicate în procesul de transformare impus mediului socio-economic de explozia tehnologică a ultimului deceniu.

Studiul poate reprezenta un instrument util inprocesul de aliniere a IMM-urilor din România la noile realități economice europene și mondiale.

În conceptia UE, IMM sunt întreprinderi al căror număr de salariați nu depășește 500 de persoane și care au imobilizări nete până la 75 de milioane de euro, din care mai puțin de o treime din capital să fie deținut de către o firmă de dimensiuni mari.Bidilean00.

În legislația româneasă condițiile de încadrare a IMM-urile sunt definite astfel:"întreprinderi cu pâna la 250 de angajati și cifra de afaceri anuală cuprinsă între 20 de milioane si 100 miliardelei. Nu se încadrează în prevederile legii societățile bancare, societățile de asigurare si reasigurare, societățile de administrare a fondurilor financiare de investiții, societățile de valori mobiliare si societățile cu activitate exclusivă de comerț exterior.

Cu o structură organizatională simplă, caracterizată prin flexibilitate comportamentala și lipsa birocrației, prezente în toate sectoarele industriei, ale comerțului și serviciilor, IMM-urile se adaptează cu ușurință condițiilor economice și sociale in schimbare, fiind capabile să “inoveze și exploateaze piete neglijate de marile întreprinderi”Bidilean00.

Dacă in mod clasic, IMM-urile își desfășoară activitatea în interiorul frontierelor naționale, deplasarea economică spre piața virtuala conduce la posiblitatea internaționalizarii lor prin stabilirea cu mai multă ușurință a relațiilor de afaceri externe sau chiar prin cucerirea de piețe externe. Din această perspectivă se impune însă construirea unui cadru legislativ global adecvat care să ofere legi comune în ceea ce privește fiscalitatea, concurența, etc.

În ideea implementării pe piața economică românească a noilor tehnologii informaționale si comucaționale, lucrarea propune un model conceptual al unui sistem software destinat managementului unui IMM virtual. Prin proiectare si implementare se realizează in final validarea din punct de vedere tehnic a modelului.

Explozia Internet-ului, dezvoltarea comerțului electronic și apariția firmelor virtuale au condus însă la posibilitatea transformarii unui IMM clasic într-o firmă virtuală (sau chiar pur virtuală) pentru care sistemul informatic nu mai reprezintă un element complementar, ci chiar fundamentul structurii organizaționale.

În aceste condiții utilizarea unui sistem informatic pentru asistarea procesului decizional este o consecință naturală, impusă atât de mediul economic, prin necesitatea transformării stilului de conducere, cât și de cel tehnologic.

4.6 Workflow-ul procesului decizional

Indiferent sfera de acțiune, publică sau privată, procesele de afaceri devin din ce în ce mai complexe si mai importante la nivelul economiei globale. Există din ce in ce mai multe persoane implicate în fiecare proces și care pot fi plasate oriunde în birourile instituției sau chiar în întreaga lume. În acelasi timp, clienții, furnizorii, partenerii și angajații solicita din ce in ce mai multa eficiență si viteza de reactie în derularea unui proces de afaceri, în principal al procesului de luare a deciziei.

Urmărind ca scop creșterea eficienței în procesele de afaceri și câștigarea de avantaje strategice, în fața competitorilor, companiile au nevoie de automatizarea fluxurilor de lucru (workflow) pentru îmbunătățirea proceselor de afaceri, eliminarea întarzierilor si maximizarea productivității și în acelasi timp de un sistem de management al procesului decizional, care să asigure accesul rapid la informație, în condiții de maximă securitate și la costuri minime.

Prin workflow se înțelege fluxul de date, care implică două entitati: o parte pasivă (deciziile) si o parte activa (transmiterea informațiilor necesare luării celei mai bune decizii, în funcție de traiectoria stabilită inițial, intre angajați, in ordinea descrescătoare atribuțiilor fiecăruia). Analiza fluxului de date într-o unitate comercială are ca efect identificarea unor trasee ale documentelor, de la intrarea în flux, aprobarea sau revocarea de catre sefii ierarhici si eventual returnarea documentului la persoana care l-a generat. Aceste trasee ale informațiilor într-o entitate organizatorica (societate comerciala) poartă numele de fluxuri de lucru sau workflow-uri si ele pot primi o reprezentare grafică. Documentele electronice vor circula prin poșta electronică între persoanele sau rolurile care sunt pe traseul unui proces decizional.

Avantaje

Din punct de vedere al managerului / supervizorului

Situația actuală: numărul mare de probleme care apar în procesul de conducere a unei afaceri
Problema: dificultatea de a urmari viteza de reactie si gradul de implicare a angajaților la primirea unei solicitari

Soluția: automatizarea fluxurilor de lucru in procesul de luare a deciziei, implicând și subalternii care au posibilitatea, dar totodată și obligația de a rezolva probeme mai puțin importante care nu necesită atenția managerului general, printr-o aplicație de workflow
Beneficii:

– obtineti un suport de decizie puternic ce permite monitorizarea, administrarea, controlul si marcarea performantelor pentru toate procesele de management

identificarea rapida a nodurilor si punctelor critice in proces astfel incat sa puteti aloca noi resurse dupa nevoi

sporirea eficientei proceselor de afaceri prin instrumente de notificare automata si asignare de sarcini

posibilitatea de a automatiza chiar cele mai complexe procese

Din punctul de vedere al executantului

Situatie actuala: sarcinile curente sunt tot mai complexe si impun colaborari intre compartimente, apariția gâtuirilor generate de indisponibilitatea unui angajat și accesul limitat la informațiile deținute de acesta. Nu de puține ori angajații uită sa indeplineasca la timp o sarcină

Problema: dificultatea de a îndeplini mai multe sarcini în timp real, viteza de reacție scazută și nevoia de stabilire a unei proceduri de lucru, pentru îndeplinirea sarcinilor colective
Soluția: automatizarea fluxurilor de lucru în procesarea informațiilor cu scopul de a lua o decizie, printr-o aplicație de workflow

Beneficii:

– Permite utilizatorilor să colaboreze și să negocieze condițiile de satisfacție în îndeplinirea unor sarcini comune.

– Crește productivitatea angajaților prin folosirea instrumentelor automate de notificarea detaliilor de timp pentru îndeplinirea unei sarcini, transmiterea automată a unei sarcini la un alt angajat dupa ce acesta și-a spus părerea sa cu privire la situația în cauză , urmărirea raspunsurilor primite de la compartimentele care colaborează.

4.7 Descrierea aplicației

Aplicația este împarțită în trei module:

Partea de administrare – în care sunt realizate adăugările și modificările și ștergerile legate de utilizatori, aceastea putând fi facute doar de administrator, sau după caz, și de către alți utilizatori. Se poate modifica dreptul oricărui utilizator în funcție de necesitățile clientului.

Partea de configurare – în care sunt definite toate setarile legate de configurarea procesului decizional

creare, modificare și ștergere de tipuri de decizii, faze decizionale, notificări și template-uri de e-mail

asocieri între template-urile de e-mail și notificări, între fazele decizonale și notificări, precum și între notificări și template-urile de email

Partea de utilizare – interfața cu utilizatorul obișnuit care intră în aplicație doar pentru a introduce, modifica sau șterge o situație decizională, apărută la un moment dat.

Intrarea în aplicație se face prin intermediul ferestrei de login. Conturile de utilizator sunt create de catre administrator, ele fiind stocate în baza de date Microsoft SqlServer. Fiecare utilizator are asociat un profil în funcție de care va intra în aplicație într-unul din cele trei module( fie administrator, fie persoana care configurează procesul decizional, fie un utilizator obișnuit). Utilizatorul realizează activități specifice profilului caruia îi apartine.

Partea de administrare

Definirea utilizatorilor se face prin intermediul acestui modul, pentru fiecare utilizator, reținându-se următoarele date: numele și prenumele utilizatorului, numele de login, parola, adresa de mail, funcția pe care o deține în cadrul companiei, data angajării, adresa, numărul de telefon, precum și alte informații utile. În baza de date există un câmp numit rol în funcție de care se face redirectarea din pagina de login. Este permisă oricare din operațiile de adăugare, ștergere respectiv modificare în datele utilizatorilor.

Partea de configurare

Definirea de tipuri de decizii

Configurarea procesului decizional se face treptat, acest modul fiind foarte flexibil. Există o componentă de definire a tipurilor de decizii care pot apărea la nivelul unei companii sau grup de firme colaboratoare. În funcție de tipul de decizie ales, fiecare situație decizională apărută și introdusă în sistem va urma o anumită traiectorie, care la randul ei va putea fi configurată. La nivelul fiecarui tip de decizie, se va salva numele acesteia, precum și descrierea pe larg a ceea ce reprezintă.

Pot exista spre exemplu, decizii simple care ar putea urma o traiectorie nu foarte complicată și prea elaborată, implicând doar o parte din superiori în luarea deciziei, sau poate fi un tip de decizii complexe care impun o analiză mai profundă înainte de a se pronunța cu privire la aprobarea sau neaprobarea problemei studiate. Pe langa deciziile uzuale, se poate defini un tip de decizii urgente care necesită o aprobare imediată, urmând a se stabili persoana care va acționa etc.

Definirea de faze ale procesului decizional

Această componentă permite introducerea de faze decizionale care ulterior vor fi asociate tipurilor de decizii în funcție de acțiunea care trebuie realizată într-o anumită stare. O alta asociere se va face între o anumită fază decizională și notificările care sunt definite mai jos, și în funcție de care se va trimite mailul către persoanele ce urmează a fi implicate în luarea deciziilor.

Definirea de notificări

Această componentă permite introducerea de notificări care vor fi asociate fazelor decizionale în funcție de utilizatorul ce urmează a fi implicat în luarea deciziilor. O alta asociere se va face între notificare și template-ul de mail care va fi utilizat de către serviciul care va trimite mail pentru a anunța necesitatea aprobării sau neaprobării situațiiei decizionale apărute. La nivelul fiecarei notificări, se va salva numele acesteia, precum și descrierea pe larg a ceea ce reprezintă și utilizatorul caruia i se adresează.

Definirea de template-uri de e-mail

Această componentă permite introducerea de template-uri de email care vor fi stocate în baza de date și urmează a fi folosite de către serviciul de trimis mail care vor fi asociate fazelor decizionale în funcție de utilizatorul ce urmează a fi implicat în luarea deciziilor. La nivelul fiecarui template, se va salva numele acesteia, titlul e-mailului, conținutul.

Asocierile între componentele procesului decizional

Asocierile se va face între un tip de decizie și anumite faze decizionale, între o anumită fază decizională și o notificare aferentă stării repective, între notificare și template-ul de mail care va fi utilizat de către serviciul care va trimite mail pentru a anunța necesitatea aprobării sau neaprobării situațiiei decizionale apărute.

Partea de utilizare

Definirea de situații decizionale

O data configurarea procesului decizional se pot introduce în baza de date, situațiile decizionale. Astfel se vor stoca date referitoare la numele situației decizionale respective, data la care s-a intodus(se poate observa că în dreapta datei apare un calendar din care se poate selecta o anumita dată), utilizatorul care introducele datele respective, acest lucru setându-se o data cu logarea utilizatorului în aplicație. De asemenea se va selecta din lista de tipuri decizionale posibile pe cel care reflectă cel mai bine fluxul celei introduse. În funcție de tipul de decizie ales, fiecare situație decizională apărută și introdusă în sistem va intra în prima fază acestuia, urmând o anumită traiectorie, configurată anterior. La nivelul fiecarui tip de decizie, se va salva și descrierea pe larg a ceea ce reprezintă și care sunt motivele pentru care ar trebui să se aprobe. Ulterior, cu fiecare faza aprobată, se va trece automat în faza următoare, retrimițându-se mail la persoana corespunzatoare noii faze.

CONCLUZII

Lucrarea și-a propus să realizeze o aplicație care să implementeze workflow-ul procesului decizional. Decizia sau procesul decizional este un act caracteristic speciei umane, reprezentând elementul cel mai important, elementul esențial al activității manageriale fără de care întreprinderile si celelalte societăți comerciale nu s-ar putea integra in circuitul economic, si practic ele nu ar exista. De asemenea, decizia, pentru a fi profitabila trebuie sa fie colectivă, bine gândita, analizată si reanalizată înainte de a fi pusa în practică, deoarece de ea va depinde viitorul întregii firme.

Studiul poate reprezenta un instrument util în procesul de aliniere a IMM-urilor din România la noile realități economice europene și mondiale.

Bibliografie