Imbunatatirea Calitatii Softului

INTRODUCERE

Necesitatea măsurării calității produselor soft a apărut deja în prima perioadă a revoluției computaționale în jurul anilor 1950. În această perioadă asigurarea calității produselor soft era sarcina programatorului. Cu apariția noilor arhitecturi și a limbajelor de programare care au permis realizarea unor proiecte de dimensiuni mai mari decât cele scrise de un singur programator s-a dovedit necesitatea dezvoltării acestei ramuri a informaticii, adică a măsurării și asigurării calității produselor soft. Astfel au apărut modele de calitate ale produsului soft ca și Modelul Boehm, Modelul McCall, Modelul Dromey și standardul ISO 9126, etc. Descrierea acestor modele se regăsește în capitolul I. Fiecare dintre ele definește o mulțime de atribute proprii ale produsului soft, atribute care în mod direct sau indirect pot fi măsurate prin metrici soft.

Această lucrare este destinată prezentării noțiunilor despre calitatea unui produs soft, dar mai ales a metodelor de îmbunătățire a calității unui produs soft care se regăsesc în capitolul al II-lea. Calitatea unui produs soft este o combinație a diverșilor factori. Fiecare dintre ei contribuie într-o măsură mai mare sau mai mică la calitatea produsului soft. Printre metrici de calitate putem aminti metricile Halstead, numărul liniilor de comentarii din codul sursă, lungimea medie a identificatorilor, numărul subprogramelor (funcțiilor sau procedurilor) și lungimea medie a lor.

Lucrarea prezintă unele modele și metrici de calitate, dar obiectivul principal este îmbunătățirea calității softului atât prin teorie cât și în practică. Cu acest scop au fost proiectate programele regăsite în capitolul al III-lea care analizează codul sursă al unui program dat ca și parametru de intrare.

Cap.I Definirea calității produselor soft

Punctul de pornire pentru a prezenta calitatea unui produs soft poate fi descris în felul următor:

“…un program care nu funcționează, în mod sigur este incorect, dar un program care funcționează nu este în mod necesar corect… (M. Jackson)”.

Măsurarea calității produsului soft este o activitate de umbrelă care cuprinde în întregime procesul de dezvoltare al acestuia. Organizația care desfășoară o activitate de dezvoltare a produselor soft trebuie să aibă un grup independent de specialiști care se ocupă de măsurarea calității produsului soft. Obiectivele măsurării calității produselor soft sunt următoarele:

Îmbunătățirea calității produselor soft, monitorizând atât produsul final cât și procesul de dezvoltare al acestuia;

Asigurarea produsului soft că în mod complet corespunde standardelor și procedurilor de proiectare și dezvoltare;

Asigurarea că fiecare deficiență (lipsă) în produs, în procesul de producție sau în standarde a atras atenția managerului, deci aceste deficiențe vor fi corectate.

Măsurarea calității produsului soft este câteodată referită ca și „ochi ai beneficiarului”, asigură organizației un atuu că face „lucruri corecte în timp util și în forma cea mai corectă”.

Azi, este acceptat într-un sens mai larg în lumea organizațiilor transpunerea producției de calitate în aceleași timp cu economisiri financiare. Mișcarea pentru măsurarea calității numită Total Quality Management (TQM – Managementul calității absolute) și-a început activitatea în prima parte a anilor 1940 cu lucrarea lui W. Edward Deming. Managementul calității absolute a fost folosit în industria automobilelor în Japonia, eliminând sistematic căile care au condus la erori. Calitatea, în prima perioadă a revoluției computaționale în jurul anilor 1950 și 1960 era numai responsabilitatea programatorului. Standardele pentru măsurarea calității au fost introduse în proiecte militare în jurul anilor 1970 după care au fost în mod rapid răspândite și în lumea comerțului. Principiile TQM au fost dezvoltate (specificate) în modelele de îmbunătățire a procesului de realizare a produsului soft, ca și CMM (Capability Maturity Model), ISO 9000 (International Organization for Standardization), COCOMO (Constructive Cost Model) și SPICE.

1.1 Asigurarea calității produsului soft

Software Quality Assuarance (SQA – asigurarea calității produsului soft) este o activitate care acoperă tot ciclul de viață al produsului soft, care se compune dintr-o activitate de gestiune a calității, o tehnologie de inginerie a produsului soft, revizii tehnice formale desfășurate în timpul procesului, o strategie de control la diferite nivele, gestiunea documentației și a modificărilor, o procedură care garantează conformitatea cu standardele de dezvoltare și, în sfârșit, mecanisme de măsurare și de redactare a rapoartelor [1].

Există trei abordări ale asigurării calității:

certificarea produsului. Un grup independent conduce un exercițiu limitat de verificare, validare și testare a componentei soft.

procesul de audit. Un grup independent conduce o evaluare a procesului de dezvoltare folosit pentru a proiecta, construi și distribui componenta soft.

satisfacția utilizatorului. Analiza comportamentului actual al componentei soft aflată în folosință.

1.1.1 Ce este calitatea?

Controlul calității are ca și element cardinal (fundamental) variația controlului de la un produs la altul: obiectivul dezvoltării produselor soft de calitate este minimalizarea diferențelor între produse. Minimalizarea variațiilor poate să însemne multe lucruri: minimalizarea resurselor prevăzute între resursele folosite în mod efectiv, numărul de erori ale produsului distribuit, variația erorilor de la o versiune la alta a aceluiași produs.

Calitatea unui obiect este o caracteristică care se bazează pe proprietățile măsurabile ale produsului, adică cantități confruntabile cu standarde prefixate. În cazul softului totuși aceste proprietăți „măsurabile” sunt mult mai dificil cuantificate decât obiectele fizice. Cu toate acestea și pentru soft au fost standardizate metrici referitoare la complexitatea ciclomatică, coeziunea, numărul liniilor codului sursă.

În evaluarea unui produs se pot individualiza (determina, identifica) două tipuri de calități:

Calitatea proiectării, relativ la analiza caracteristicilor specificate de către proiectant (materiale, toleranțe, prestări cerute) – este un parametru care se referă la cerințele, specificațiile și proiectarea sistemului.

Calitatea conformității reprezintă gradul de aderență al implementațiilor la specificațiile proiectului – este o caracteristică a implementațiilor.

Definim controlul de calitate ca și o mulțime de examinări, reviziuni și controale desfășurate pe parcursul ciclului de viață al produsului soft, al cărui scop este să garanteze că produsul satisface cerințele impuse; este important ca pentru fiecare lucrare dusă la capăt să aibă definite proprietăți măsurabile specifice care pot fi folosite ca și măsură pentru a evalua obiectele produse.

Asigurarea calității (QA – Quality Assuarance) constă din funcții de audit și redactarea rapoartelor de management; are ca și scop furnizarea informațiilor necesare managementului pentru a garanta că produsul satisface obiectivele calitative.

Costul calității este suma tuturor costurilor susținute pentru activitatea SQA și a activităților corelate. Acestea pot fi clasificate în felul următor:

Costuri de prevenții – cuprind costurile pentru planificări de calitate, pentru revizii tehnice formale, pentru echiparea necesară controalelor, și pentru instruirea personalului grupului SQA.

Costuri de estimare – sunt susținute pentru activități desfășurate pentru a evalua calitatea unui produs în prima fază a fiecărui proces.

Costuri de erori – aceste costuri dispar dacă produsul nu dezvăluie nici o eroare înaintea livrării acestuia clientului. Putem vorbi despre costuri interne în cazul în care o eroare iese în evidență înaintea livrării produsului respectiv (refaceri, reparații, analiza defecțiunilor) și respectiv costuri externe. Acestea din urmă sunt costuri legate de erori descoperite după livrarea produsului soft clientului (răspunsuri la reclamații, restituiri și substituiri ale produsului, asistență tehnică, obligații de garanție).

1.1.2 Calitatea componentei soft

Dezvoltarea componentei de bază și reutilizarea produselor soft plasează noi cereri în testarea produsului soft și a asigurării calității. Acest lucru este adevărat în mod special dacă, componentele sunt făcute pentru a fi vândute sau schimbate între companiile soft.

Întrebările la care un utilizator sau un furnizor al unei componente soft vrea să aibă răspunsuri sunt:

○ Cât de probabil este ca această componentă să funcționeze corespunzător în aplicația mea?
○ În ce moduri a fost testată componenta?
○ În ce măsură metodele de testare sunt relevante pentru utilizarea ce o intenționez?
○ A fost componenta deja utilizată în alte aplicații similare?
○ Cât de mult și cu ce rezultate a fost folosită în alte aplicații similare?
○ Care sunt implicațiile utilizării acestei componente?
– performanță/capacitate

– siguranță/robustețe

– abilitate de intreținere/portabilitate

Ca producător de componente soft trebuie să știm:

○ Ce probe sunt ca această componentă va funcționa corespunzător în aplicațiile reale?

○ A fost componenta testată în suficient de multe situații?

○ Este componenta proiectată pentru o performanță suficientă într-o gamă largă de contexte?

Scopul testării produslor soft și asigurării calității este acela de a confirma că soluția are nivelul dorit de calitate. Calitatea soluției este definită ca fiind totalitatea caracteristicilor soluției ce îi permit să satisfacă nevoile explicite sau implicite ale utilizatorului.

Testarea produsului soft și asigurarea calității sunt procese de descoperire a adevăratei calități a soluției. Procesul descoperirii adevăratului nivel de calitate va aduce îmbunătățiri ale calității. Acesta este principalul motiv de realizare a acestui proces. Dar nu există un sfârșit al procesului de descoperire. Nu există un punct în care putem spune: „Acum știm tot ce se poate știi despre calitatea acestei soluții”.[11]

1.1.3 Garantarea calității produsului soft

Măsurarea calității produsului soft acumulează (strânge) diverse sarcini asociate cu două părți foarte importante și diferite: – ingineria softului care este un lucru tehnic și grupul SQA care este responsabil pentru planul de asigurare a calității, pentru raporturi și analize.

Grupul SQA asistă echipa de ingineri soft pentru a realiza un produs de înaltă calitate, responsabilitatea lor cuprinde următoarele aspecte:

prepararea planului QA pentru proiect;

realizarea evaluărilor;

realizarea examenelor de revizii;

standarde aplicabile la proiect;

proceduri de redactare a rapoartelor, și căutarea erorilor;

documente de produs;

gradul de răspuns furnizat de către echipa proiectului;

participarea în dezvoltarea proceselor proiectului;

revizia activității desfășurate de către inginerii de soft pentru a verifica dacă satisfac (realizează) procesele cerute;

controlul produsului soft selectat în vederea verificării corespondenței cu părțile definite ca parte a procesului;

asigurarea că abaterile observate vor fi documentate și raportate managerului senior;

coordonarea managementului schimbării;

ajutarea colectării și analizării metricilor soft.

SQA este mult mai eficientă în ameliorarea calității produsului dacă membrii grupului SQA văd rolul lor de suport și nu sunt împiedicați de către personalul de dezvoltare și întreținere.[1]

1.1.4 Evaluarea calității produsului soft

În literatura de referință pe parcursul lucrării există foarte multe definiții pentru a descrie ce se înțelege prin calitatea unui produs soft.

De exemplu:

În conformitate cu cerințele explicit stabilite (exigențele) de performanță și de funcționalitate, standardele de dezvoltare explicit documentate și caracteristicile implicite trebuie să fie respectate de fiecare produs dezvoltat în mod profesional.

Această definiție accentuează trei aspecte importante ale calității produsului soft:

dusului soft și a asigurării calității. Acest lucru este adevărat în mod special dacă, componentele sunt făcute pentru a fi vândute sau schimbate între companiile soft.

Întrebările la care un utilizator sau un furnizor al unei componente soft vrea să aibă răspunsuri sunt:

○ Cât de probabil este ca această componentă să funcționeze corespunzător în aplicația mea?
○ În ce moduri a fost testată componenta?
○ În ce măsură metodele de testare sunt relevante pentru utilizarea ce o intenționez?
○ A fost componenta deja utilizată în alte aplicații similare?
○ Cât de mult și cu ce rezultate a fost folosită în alte aplicații similare?
○ Care sunt implicațiile utilizării acestei componente?
– performanță/capacitate

– siguranță/robustețe

– abilitate de intreținere/portabilitate

Ca producător de componente soft trebuie să știm:

○ Ce probe sunt ca această componentă va funcționa corespunzător în aplicațiile reale?

○ A fost componenta testată în suficient de multe situații?

○ Este componenta proiectată pentru o performanță suficientă într-o gamă largă de contexte?

Scopul testării produslor soft și asigurării calității este acela de a confirma că soluția are nivelul dorit de calitate. Calitatea soluției este definită ca fiind totalitatea caracteristicilor soluției ce îi permit să satisfacă nevoile explicite sau implicite ale utilizatorului.

Testarea produsului soft și asigurarea calității sunt procese de descoperire a adevăratei calități a soluției. Procesul descoperirii adevăratului nivel de calitate va aduce îmbunătățiri ale calității. Acesta este principalul motiv de realizare a acestui proces. Dar nu există un sfârșit al procesului de descoperire. Nu există un punct în care putem spune: „Acum știm tot ce se poate știi despre calitatea acestei soluții”.[11]

1.1.3 Garantarea calității produsului soft

Măsurarea calității produsului soft acumulează (strânge) diverse sarcini asociate cu două părți foarte importante și diferite: – ingineria softului care este un lucru tehnic și grupul SQA care este responsabil pentru planul de asigurare a calității, pentru raporturi și analize.

Grupul SQA asistă echipa de ingineri soft pentru a realiza un produs de înaltă calitate, responsabilitatea lor cuprinde următoarele aspecte:

prepararea planului QA pentru proiect;

realizarea evaluărilor;

realizarea examenelor de revizii;

standarde aplicabile la proiect;

proceduri de redactare a rapoartelor, și căutarea erorilor;

documente de produs;

gradul de răspuns furnizat de către echipa proiectului;

participarea în dezvoltarea proceselor proiectului;

revizia activității desfășurate de către inginerii de soft pentru a verifica dacă satisfac (realizează) procesele cerute;

controlul produsului soft selectat în vederea verificării corespondenței cu părțile definite ca parte a procesului;

asigurarea că abaterile observate vor fi documentate și raportate managerului senior;

coordonarea managementului schimbării;

ajutarea colectării și analizării metricilor soft.

SQA este mult mai eficientă în ameliorarea calității produsului dacă membrii grupului SQA văd rolul lor de suport și nu sunt împiedicați de către personalul de dezvoltare și întreținere.[1]

1.1.4 Evaluarea calității produsului soft

În literatura de referință pe parcursul lucrării există foarte multe definiții pentru a descrie ce se înțelege prin calitatea unui produs soft.

De exemplu:

În conformitate cu cerințele explicit stabilite (exigențele) de performanță și de funcționalitate, standardele de dezvoltare explicit documentate și caracteristicile implicite trebuie să fie respectate de fiecare produs dezvoltat în mod profesional.

Această definiție accentuează trei aspecte importante ale calității produsului soft:

Cerințele produsului soft trebuie respectate. Lipsa conformității cu cerințele înseamnă lipsa calității.

Standardele specificate definesc mulțimea criteriilor de dezvoltare care vor conduce modul în care softul va fi proiectat. Dacă aceste criterii nu sunt urmărite, în mod sigur lipsa calității o să apară.

Există o mulțime a cerințelor implicite care nu vor fi specificate (de exemplu, dorința ca softul să fie întreținut). Dacă softul corespunde cerințelor explicite dar nu sunt respectate cerințele implicite atunci calitatea softului rămâne de suspectat [1].

1.1.5 Organizarea măsurării calității produsului soft

Grupul SQA trebuie să pregătească raporturi la cererea lanțului independent de management (Independent Management Chain). Deci, dezvoltarea produsului soft trebuie să fie condusă de un manager, dar activitatea de control trebuie executată de către un alt manager și nici unul nu trebuie să-l anuleze pe celălalt. Deseori, cu apropierea termenului de livrare a produsului soft organizația trebuie să aleagă între două opțiuni nesatisfăcătoare:

1. consemnarea produsului în timp; sau

2. consemnarea produsului cu erori grave.

Amândoi managerii trebuie să raporteze dificultățile apărute managerului senior care vor balansa consecvențele pentru organizație și client.

1.1.6 Inspectarea produsului soft

Inspectările ar trebui să fie efectuate în diverse faze ale procesului de dezvoltare și au rolul de a descoperi erorile. Există diverse tipuri de revizii, de exemplu revizii tehnice formale(FTR – Formal Technical Review sau Walkthrough) care sunt revizii conduse de către tehnicieni pentru alți tehnicieni.

Revizii tehnice formale.

Scopurile unei revizii tehnice formale sunt:

descoperirea erorilor în funcțiile și logica produsului soft;

verificarea dacă produsul soft satisface cerințele;

garantarea că produsul soft va fi reprezentat conform standardelor predefinite;

acceptarea că produsul soft este dezvoltat în mod uniform;

asigurarea că proiectele sunt mai ușor de condus.

Reviziile tehnice formale permit printre altele instruirea tehnicienilor cu mai puțina experiență, care au ocazia pe parcursul reviziei să se confrunte cu diverse metode de analiză, de proiectare și de implementare a produsului soft, garantarea substituibilității și continuității în interiorul grupului de lucru, dacă tehnicieni descoperă părțile softului cu care nu s-a lucrat.

Inspecțiile, reviziile încrucișate sunt toate exemple de verificare, fiecare revizie se desfășoară sub o formă de reuniune.

Reuniunea pentru o FTR trebuie să respecte câteva caracteristici:

Trebuie să implice 3 – 5 persoane;

Fiecare participant la reuniune trebuie să desfășoare o activitate de preparare a reuniunii care nu durează mai mult de câteva ore;

reuniunea nu trebuie să dureze mai mult de două ore;

O FTR trebuie să se concentreze pe porțiuni mici ale softului; programatorul care a dezvoltat softul informează în momentul potrivit conducătorul proiectului despre faptul că lucrul a fost finalizat și necesită o revizie. Conducătorul proiectului nominalizează șeful reviziei care să asigure că produsul este pregătit pentru revizie și distribuie documentația participanților la reuniune; fiecare participant dedică nu mai mult de două ore consultării documentației ca să se familiarizeze cu produsul pregătit pentru revizie și să faca observații legate acesta. La reuniune participă programatorul softului, revizorul șef și alți revizori; unul dintre participanți îndeplinește funcția de secretar al reuniunii. La sfârșitul reuniunii revizorii decid dacă acceptă softul așa cum este, respingând cauzele erorilor grave sau acceptând cu rezerve, pentru că nu sunt erori grave, acestea putând fi corectate.

Fiecare revizie trebuie să fie documentată printr-un referat care descrie starea obiectului revizionat, de către cine a fost compilat, ce a descoperit și care sunt concluziile.

În cele ce urmează vom înșira câteva directive pentru revizii:

Revizuirea produsului soft, de o altă persoană decât programatorul;

Fixarea unei agende și respectarea ei;

Limitarea dezbaterilor;

Relevarea erorilor, nu rezolvarea tuturor erorilor pe parcursul reuniunii;

Luarea unor notițe;

Prevederea unui număr limitat de participanți pregătiți, care participă la reuniune;

Alocarea resurselor și prevederea timpului pentru FTR;

Instruirea revizorilor;

Reexaminare reviziilor promovate;

Din revizii putem extrage metricile în vederea evaluării procesului și produsului:

Timpul de inspecție pe pagină de documentație;

Timpul de inspecție pentru Kloc sau FP;

Erori descoperite pe o oră de revizie;

Erori descoperite pe oră de pregătire;

Erori descoperite pe task;

Numărul de erori minore;

Numărul de erori grave (ex. neconformitatea cu cerințele);

Măsurarea calității de obicei este exprimata în termeni de metrici. Metricile soft sunt o proprietate, un indicator a unui sau a mai multor criterii de calitate pe care le vom măsura.

1.2 Modele de calitate

Modelele de calitate sunt definite ca și „o mulțime de caracteristici și relații între ele, ce furnizează baza pentru a specifica cerințele calității și evaluarea calității ” sau altfel „o mulțime de proprietăți structurate pentru un obiect al unei clase pentru a atinge scopurile propuse ”.

Beneficiile modelelor de calitate sunt date de către descompunerea obiectului evaluabil (atât procesul, produsul și organizația) într-o listă de caracteristici, subcaracteristici și măsuri care sunt aplicabile pentru a prezice/evalua/verifica atingerea scopurilor propuse obiectului înainte de/în timp/după producerea lui.

Cele mai cunoscute modele de calitate pentru soft sunt acelea propuse de Boehm et al. și McCall et al. din care își au originea standardul de astăzi ISO/IEC 9126 publicat în 1991 (conține 6 caracteristici și 21 subcaracteristici).

Putem distinge modelele de calitate în funcție de numărul nivelelor în care sunt structurate:

2 nivele (Boehm șă McCall), aceștia prezintă o listă a caracteristicilor subdiviziunilor în mulțimi de subcaracteristici; mai sus de cele două nivele avem descrieri mai apropiate de punctul de vedere al utilizatorului;

3 nivele, unde este adăugat nivelul detaliat al măsurilor fiecărei subcaracteristică, în mod cert din punct de vedere mai apropiat de perspective tehnice. Permite cuantificarea unei evaluări în manieră extrem de subiectivă (subiectivitatea este intrinsecă în modelele de calitate).

Următoarea tabelă schițează termenele folosite în diferite modele de calitate soft.

Tabela 1 – Modele de Calitate Soft

O altă clasificare a modelelor de calitate folosește numărul relațiilor dintre cele două nivele:

Relație 1:n, ca și în ISO 9126 – fiecare caracteristică are mulțimea de subcaracteristici proprie;

Relație n:m, ca și în McCall Factor-Criteria Model – fiecare subcaracteristică este legată de una sau mai multe caracteristici [4].

1.2.1 Modelul de calitate Boehm

Boehm et. al. au construit unul dintre cele mai cunoscute modele ale calității softului. Ei descriu o ierarhie a metricilor, dintre care fiecare contribuie la calității absolute. Nivelul cel mai inferior este recomandat metricilor cantitative.

În centrul modelului Boehm se regăsește noțiunea „utilitatea pentru utilizator”. La nivelul cel mai superior (înalt) este Utilitatea Generală (General Utility) a softului; înainte de toate softul trebuie să fie util! Modelul se rafinează în nivele succesive, conceptul de utilitate respectând utilizatori diferiți. Primul tip de utilizator este chiar beneficiarul care evaluează softul în termeni Utilitatea așa cum este (As-is Utility). Totuși pot să existe alte persoane care au nevoie să folosească programul pe calculatoare diverse la locații diferite. Necesitatea acestor utilizatori secundari afectati de portabilitate au adăugat la grupul de proprietăți Utilitatea Generală, proprietatea Portabilitatea produsului soft pe platforme noi de hard sau noi sisteme de operare. Al treilea tip de utilizator este programatorul care întreține sistemul, executând schimbări cerute de către beneficiar sau corectarea erorilor depistate de către client.

Abilitatea de întreținere (Maintainability) a softului este afectata de către capacitatea programatorului de a înțelege, a testa și a modifica programul. Abilitatea de întreținere este ușurința cu care se pot efectua schimbări pentru a satisface cerințele noi sau pentru a corecta deficiențele. Un soft bine proiectat trebuie să fie destul de flexibil să se adapteze la schimbările viitoare la aparența noilor cerințe. Des, programatorul este responsabil pentru a scrie secțiuni de cod în felul în care nu este singurul care trebuie să întrețină programul. Din acest motiv calitatea documentației softului afectează semnificativ abilitatea de întreținere a produsului soft [4].

Figura 1. Modelul Boehm

Acest model implică prin urmare faptul că un produs soft de calitate ar trebui să:

Facă ceea ce utilizatorul dorește;

Folosească resursele calculatorului în mod corect și eficient;

Fie ușor de citit și folosit pentru utilizator (human engineering);

Aibă un design bun, să fie bine codificat și ușor testabil și de întreținut.

Această listă este mult mai utilă dacă programatorul verifică proprietățile înșiruite decât să fie o direcție urmărită în construirea programului.

1.2.2 Modelul de calitate McCall

Un alt model care descrie calitatea softului a fost creat de către McCall, Richards și Walters în 1977. Acest model leagă factorii de calitate în viziunea utilizatorului cu factorii de calitate în viziunea programatorului și pe acestea din urma le consideră ca fiind măsurabile. Nu include prestațiile hardului care se regăsesc în modelul Boehm [2].

Figura 2. Modelul McCall

1.2.3 Modelul de calitate ISO 9126

În 1991 s-a realizat standardul ISO 9126. Confruntându-l cu modelul Boehm și modelul McCall putem spune că în viziunea acestui standard orice caracteristică din partea dreaptă este în relație numai cu un singur atribut din partea stânga, fiecare caracteristică din partea dreapta referă la viziunea utilizatorului și nu a programatorului, este recomandat măsurarea caracteristicilor din partea dreapta adică cel relevant pentru utilizator, dar nu este specificat modul în care să fie făcut. Standardul nu explică de ce nu sunt incluse anumite atribute și altele da și nici nu explică cum trebuie să fie compusă evaluarea caracteristicilor la nivelul de jos (inferior) pentru a determina valorile pentru fiecare atribut.

Modelul de calitate ISO/IEC 9126 descrie un model cu două părți pentru produsul soft de calitate:

Calitate internă, calitate externă, și

Calitate în folosință (quality in use)

Figura 3. Ciclul de viață al modelului de calitate ISO

Prima parte a modelului specifică șase caracteristici pentru calitatea internă și externă care în continuare vor fi subdivizate în subcaracteristici. Aceste subcaracteristici se manifesta a fi externe când softul este folosit ca și parte a unui sistem de calculator, și rezultă atribute interne de soft.

Partea a doua a modelului specifică patru calități în caracteristica de folosință, dar nu elaborează modelul în felul în care calitățile de folosință să fie inferioare de celelalte. Calitatea în folosință pentru utilizator este efectul combinat a celor șase caracteristici de calitate a produsului soft.[3]

Figura 4. Caracteristicile modelului ISO

Subcaracteristici ale calității în folosință (quality in use):

○ Eficacitatea(Effectivness) – este capacitatea produsului soft de a permite utilizatorilor să își atingă scopurile dorite cu acuratețe și completitudine într-un anumit context de utilizare.

○ Productivitatea(Productivity) – este capacitatea produsului soft de a permite utilizatorilor să consume o cantitate corespunzătoare de resurse în legătură cu eficacitatea atinsă într-un anumit context de utilizare.

○ Siguranța(Safety) – este capacitatea produsului soft de a atinge niveluri acceptabile de risc, de rănire a oamenilor, produsului soft, echipamentului sau a mediului dintr-un anumit context.

○ Satisfacția(Satisfaction) – este capacitatea produsului soft de a satisface utilizatorii intr-un anumit context.[9]

Caracteristicile definite sunt aplicabile pe fiecare tip de soft, incluzând programe pentru calculatoare și firmware (partea programabilă a unui drive) ce conține date. Caracteristicile și subcaracteristicile asigură o terminologie consistentă pentru calitatea produsului soft. Ele asigură și o schemă pentru a specifica cerințele de calitate a produsului soft și făcând compromisuri între capabilitățile produsului soft.

Calitatea pentru utilizator (user quality) trebuie să fie inclusă printre cerințele calității în folosință în context specific de folosință. Aceste nevoi identificate pot fi folosite când se specifică calitățile externe și interne folosind calitatea produsului soft.

Evaluarea produsului soft în ordinea în care satisface nevoile calității soft este unul dintre procesele ciclului de viață a dezvoltării acestuia. Calitatea produsului soft poate fi evaluată măsurând atributele interne (măsurători statice tipice produsului intermediar), sau măsurând atributele externe (prin măsurători, prin comportamentul codului sursă când se execută), sau măsurând atributele calității în folosință. Obiectivul este ca produsul să aibă efectul cerut într-un context particular de folosință.

Calitatea procesului (calitatea fiecărui proces al ciclului de viață) contribuie la îmbunătățirea calității produsului și calitatea produsului contribuie la calitatea de folosință a acestora. Ca urmare evaluarea și îmbunătățirea procesului sunt calități de folosință. În mod similar evaluând calitatea de folosință putem asigura feedback pentru a îmbunătăți produsul și evaluând produsul putem asigura feedback în îmbunătățirea produsului.

Caracteristicile și subcaracteristicile adoptate de către modelul ISO/IEC 9126 sunt următoarele:

Figura 5. Modelul ISO 9126

Descrierea caracteristicilor și subcaracteristicilor prezentate în modelul ISO 9126 urmează în tabelul de mai jos [3,9].

1.2.4 Modelul lui Dromey

În acest model atributele sunt clasificate în patru grupuri disjuncte: proprietăți de corectitudine, proprietăți interne, proprietăți contextuale, proprietăți descriptive. Propune ca atributele de calitate să fie acelea de prioritate elevată în proiectul curent (deci, nu le fixează pe acestea cum sunt în modelele descrise mai înainte, ele se schimbă de la un proiect la altul). Propune o metodă în crearea modelelor, fiecare se referă la un produs al procesului de dezvoltare (cerințe, design, cod).

Metoda modelului Dromey

În primul pas această metodă identifică o mulțime de atribute de calitate (de ex. Cele șase atribute din Standardul ISO 9126). În al doilea rând, identifică componentele produsului soft (ex. variabile, expresii) după care urmează identificarea și clasificarea proprietăților, care vor fi identificatori de calitate pentru fiecare componenta. Propune o mulțime de axiome pentru a lega calitatea produsului cu atributele de calitate. În sfârșit trebuie evaluat modelul și trebuie identificate slăbiciunile lui [5].

Cap. II Metode și modele de îmbunătățire a calității softului

2.1 „Criza softului”

În anii 1990 s-a estimat că jumătate din forța de muncă a Statelor Unite ale Americii se bazează în întregime pe calculatoare și produse soft, ajutată în lucrul lor zilnic. În timp ce costul componentelor hard al calculatoarelor a continuat să scadă, necesitatea noilor aplicații soft a continuat să crească în ritm rapid. Inventarul de soft existent crește în continuare și efortul necesar pentru a-l întreține crește de asemenea. În același timp este o semnificativă insuficiență de profesioniști soft calificați. Combinând acești factori, într-un proiect în viitorul apropiat, fiecare utilizator va trebui implicat în dezvoltarea și întreținerea softului. Între timp, scena dezvoltării softului este des caracterizată de:

Estimații de plan și costuri inexacte (inacurate);

Soft de calitate inferioară;

Rata productivității care crește mult mai încet decât necesitățile pentru soft.

Această situație este des denumită ca și „criză soft” [Arthur85].[10]

2.2 Metrici de calitate

Se pot genera liste lungi de caracteristici de calitate a softului : corectitudine, eficiență, portabilitate, abilitatea de întreținere, credibilitate. etc. Din nefericire, caracteristicile de multe ori se suprapun sau se află în conflict una cu cealaltă; de exemplu, portabilitatea mărită (de dorit) poate avea ca rezultat o eficiență scăzută (de nedorit). Astfel, definiții utile de metrici de calitate generale sunt dificile de conceput, și majoritatea oamenilor de știință în domeniul calculatoarelor au abandonat toate eforturile de a găsi măcar o singură metrică care să cuprindă toate caracteristicile soft.

Cu toate că s-a depus multă muncă în acest domeniu s-au găsit mai puține definiții și direcții comune decât în cazul mărimii sau complexității soft. Cele trei domenii cărora li s-a acordat o atenție considerabilă sunt:

corectitudinea programului măsurat prin numărarea erorilor;

credibilitatea soft măsurată din imperfecțiunea datelor;

abilitatea de întreținere a softului măsurată prin diferite alte metrici inclusiv metricile de complexitate.

Calitatea soft este o caracteristică care, cel puțin teoretic, poate fi măsurată în fiecare fază a ciclului de dezvoltare soft.

2.2.1 Metrica lungimii medie a identificatorilor

Metrica lungimii medie a identificatorilor a fost definită pentru a putea fi folosită în măsurarea sau predicția abilității de întreținere și ca urmare măsoară totodată și calitatea produsului soft. Prin identificatori înțelegem nu numai denumirile variabilelor și denumirea subprogramelor ci și numele constantelor folosite în programul destinat analizării. În mod evident dacă o denumire este prea scurtă îngreunează înțelegerea codului sursă în consecvență scade calitatea programului.

2.2.2 Metrica numărului de comentarii

Pentru a facilita înțelegerea codului sursă este necesar introducerea comentariilor prin care sunt explicate funcționalitățile subprogramelor, variabilelor folosite și acțiunile efectuate care ne duc la rezolvarea problemei pentru care a fost destinat programul respectiv. Această metrică ca și cea precedentă este bazată pe analiza codului sursă. După procentul cât la sută din codul sursă este ocupat de către comentarii putem trage concluzia cât de bine este documentat codul sursă respectiv. Evident că trebuie să există un echilibru între numărul liniilor codului sursă și numărul comentariilor.

2.2.3 Metrica lungimii medie a subprogramelor

Ca și cele două metrici de mai sus și această metrică este derivată din analiza codului sursă. Din tehnicile de proiectare ale algoritmilor am văzut cât de important este descompunerea unei probleme în subprobleme ceea ce facilitează rezolvarea problemei inițiale creând părți ale programului (subprograme) reutilizabile, astfel codul sursă devine mai scurt, lizibil, clar. Dacă este necesar modificarea unei porțiuni de cod care apare mai multe ori atunci dacă porțiunea respectivă dacă se găsește într-un subprogram este suficient modificarea porțiunii de cod din subprogram. Deci numărul și lungimea subprogramelor sunt proprietăți esentiale în măsurarea calității programului.

2.2.4 Metrici pentru densitatea defectelor

Numărul erorilor în produsul soft ar trebui să fie ușor derivabil din produsul însuși; astfel se califică drept o metrică a produsului. Cu toate acestea din moment ce nu există o procedură efectivă de numărare a erorilor din program s-au propus următoarele măsurări alternative:

Numărul de schimbări în proiectare;

Numărul erorilor detectate la inspecțiile codului;

Numărul erorilor detectate pe parcursul testărilor programului;

Numărul schimbărilor necesare în cod.

Aceste măsurări alternative depind atât de program, cât și de rezultat (a unor faze a ciclului de dezvoltare).

Numărul defectelor observate într-un produs soft furnizează în sine o metrică de calitate soft. Studiile au încercat să stabilească relații între acestea și alte metrici care ar putea fi disponibile la începutul ciclului de dezvoltare și care, din această cauză, ar putea fi folositoare ca predicție privind calitatea programului.[10]

2.2.5 Complexitatea psihologică a sarcinii de intreținere a softului

Metrica abilității de efort a fost definită pentru a putea fi folosită în măsurarea sau predicția abilității de întreținere a produsului soft. De exemplu, în studiile lui Curtis, et. al, a fost investigată metrica abilității de efort a lui Halstead, E, și v(G) pentru a prezice complexitatea psihologică a sarcinii de întreținere a softului. Presupunând că astfel de predicții ar putea fi făcute cu acuratețe, metricile de complexitate ar putea fi atunci folosite în mod profitabil pentru a reduce costurile întreținerii softului.

Dat fiind un program oarecare, noi putem desena graful fluxului de control, G, în care fiecare nod corespunde unui bloc de cod secvențial și fiecare arc corespunde unei ramificații sau punct de decizie în program. Complexitatea ciclomatică are un comportament asemănător cu un graf și valoarea ei se poate calcula cu o formulă simplă din teoria grafelor, v(G)=e-n+2, unde e este numărul muchiilor și n este numărul nodurilor în graf. McCabe a propus că v(G) poate fi folosit ca și măsură de complexitate a programelor și, mai mult, ca și ghid în dezvoltarea și testarea lor. Pentru programe structurate v(G) poate fi calculat fără referință din graful fluxului program care folosește numai punctele de decizie în textul programului. Metrica de complexitate ciclomatică a lui McCabe a fost corelată cu efortul de programare, performanța corecției (debugging) și performanța abilității de întreținere (maintenance).

Myers a remarcat că măsura complexității ciclomatice a lui McCabe, v(G), furnizează o măsură pentru complexitatea programului, dar eșuează în diferențierea complexității unor cazuri destul de simple care implică condiții unice (ca și opus la condiții multiple) în instrucțiuni condiționale. Ca o îmbunătățire a formulei originale Myers sugerează extinderea lui v(G) la v’(G)=[l:u], unde l și u sunt limitele inferioare și respectiv superioare, ale complexității. Această formulă dă rezultate mai satisfăcătoare în cazurile amintite de Myers.[10]

2.3. Cererile producerii unui soft de calitate

Pentru a formula cererile producerii unui soft de calitate trebuie luate în considerare trei probleme: trebuie identificate diferitele grupuri de interese, trebuie specificate aplicațiile modelului și trebuie să se stabilească nevoile de calitate sau perspectivele diferitelor grupuri de interese.[6]

Un punct potrivit pentru a obține un set de cereri este de a pune întrebarea fundamentală:

Cine trebuie să fie satisfăcut de produsul soft?

Răspunsul este: clienții, sponsorii și utilizatorii. Aceste grupuri diferite de interese au nevoi diferite de produse soft și uneori nevoi primare ce intră în conflict. Pentru că un grup de interes în particular să fie satisfăcut cu produsul soft, acesta trebuie să se întâlnească cu cererile lor specifice funcționale și/sau nonfuncționale. Împreună, toate aceste cereri fac parte din cererile referitoare la calitate.

Următoarea întrebare fundamentală pentru obținerea unui set de cereri este:

De ce vrem să definim, să caracterizăm și să producem un model soft de calitate?

Suntem convinși de la început că utilizarea unei definiții a unei teorii sau a unui model ne poate face munca construirii acelei definiții, model sau teorii mult mai ușoară. Această evaluare ne oferă un scop concret și un set de cereri ce trebuie satisfăcute.

Sugerăm că aplicațiile primare ale unui astfel de model sunt:

○ A folosi aceste informații pentru a evalua și prescrie sau specifica calitatea cererilor pentru produsele soft

○ A înțelege ce este necesar în construirea produsului soft de calitate cu specificarea nivelelor de calitate

○ A accentua comportamentele și a facilita folosirea produsului soft

○ A folosi un astfel de material pentru a educa oamenii cum să producă produse soft de calitate

○ A oferi un cadru de referință ce poate fi extins la nevoi de calitate din domenii particulare

○ A avea un model ce poate fi inteles la un numar de nivele de catre diferite grupuri de interese ce folosesc produsul soft

○ A servi ca motor pentru avansarea cunoștințelor noastre de producere de soft de calitate.

În lansarea unui set de cereri pentru producerea unui soft de calitate este de asemenea bine să revizuim părerile lui Garvin despre calitate. Din studiile sale el concluzionează că, calitatea este un concept complex multifațetat care poate fi descris din 5 perspective:

○ Scopul transcendental – calitatea este reconoscibilă dar nu definibilă

○ Scopul utilizatorului – calitatea înseamnă potrivire de scopuri

○ Scopul producerii – calitatea înseamnă conformare la specificări

○ Scopul produsului – calitatea este legată de caracteristicile inerente ale produsului

○ Valorile de bază – calitatea depinde de cât este clientul dispus să plătească

2.4 Axiome pentru producerea unui produs soft de calitate

O întrebare esențială în determinarea calității unui produs soft este:

Ce parte din produsul soft îi determină calitatea?

Răspunsul la această întrebare este cuprins în următorul set de axiome care vor forma bazele pentru un model de calitate și o teorie empirică a producerii unui soft de calitate.

Prima axiomă.

Dacă admitem că produsul soft este compus din componente, atunci alegerea acestor componente, proprietățile lor intrinsic tangibile și contextuale și modul în care aceste componente sunt compuse, determină calitatea produsului soft.

Exemplu: La un nivel de bază, variabilele, tipurile, expresiile și nodurile sunt exemple de componente. La un nivel mai înalt modulele de acces, modulele de interfață soft/hard și datele de comunicație sunt exemple de componente compozite.

A doua axioma

Produsul soft prezintă un set de atribute de calitate și expune anumite comportamente observabile și utilizări ce corespund direct cu atributele sale de calitate.

A treia axioma

Proprietățile tangibile purtătoare de calitate ale componentelor produsului soft contribuie la una sau mai multe atribute de calitate intangibile și de înalt nivel ale produsului soft.

Exemplu: O posibilă instanțiere, augmentare a modelului ISO-9126 Standard este prezentată mai jos:

Figura 6. Instanțierea modelului ISO-9126

A patra axiomă

Asociată cu fiecare proprietate tangibilă purtătoare de calitate a unei componente este o afirmație empirică verificabilă care leagă proprietatea fie de o caracteristică soft, un comportament sau o utilizare și mai apoi de un atribut de calitate de înalt nivel.

Exemplu: un exemplu de afirmație empirică verificabilă este:

Identificatorii autodescriptivi contribuie la analizabilitatea și menținerea softului.

Ceea ce este important despre această a patra axiomă este că ea asigură că propunerea prezentă pentru producerea unui soft de calitate este construită în ultima instanță pe un set de afirmații empirice verificabile. Ea nu merge atât de departe încât să spună că astfel de afirmații au fost deja verificate, dar există întotdeauna opțiunea de a face acest lucru.

După cum deja am văzut, alegerea componentelor, proprietățile componentelor și modul în care componentele sunt compuse determină calitatea produsului soft.[6]

Studii de caz

Software Quality Engineering (SQE – Ingineria calității softului) este un proces care evaluează și îmbunătățește calitatea softului. Calitatea softului este definită ca fiind gradul în care produsul soft îndeplinește cererile de sigurantă, abilitătății de întreținere, transportabilității, etc. Calitatea trebuie construită într-un produs soft pe parcursul dezvoltării sale pentru a satisface cererile de calitate stabilite pentru acesta. SQE asigură că procesul de încorporare a calității în produsul soft este realizat corespunzător și că produsul soft rezultat îndeplinește cererile de calitate. Gradul de conformitate la aceste cereri trebuie să fie determinat prin analiză, în timp ce cererile de funcționare sunt demonstrate prin testare. SQE realizează o funcție complementară ingineriei de dezvoltare a softului. Scopul lor comun este să asigure realizarea unui produs soft sigur, de încredere și de calitate.

Un pas inițial în realizarea unui program SQE este de a selecta calitățile care sunt importante în contextul utilizării produsului soft ce este creat. După ce calitățile soft sunt selectate și ordonate atributele specifice ale produselor soft care ajută la creșterea acestor calități ar trebui identificate. De exemplu, modularitatea este un atribut care tinde să crească atât siguranța cât și abilitatea de întreținere. Produsul soft modular este proiectat să rezulte într-un cod alcătuit din componente mici și unice de funcționare. Codul modular este ușor de menținut deoarece interacțiunile dintre unitățile codului sunt ușor înțelese și funcții de nivel scăzut sunt conținute în câteva unități ale codului. Codul modular este de asemenea mult mai sigur deoarece este mai ușor să testezi complet o unitate mică. Nu toate calitățile produsului soft sunt la fel de simplu relaționate cu un model măsurabil și nici o calitate nu este atât de simplă încât să fie atât de ușor măsurată. Ideea este de a selecta modele măsurabile, analizabile sau testabile care vor crește calitățile dorite. Atribute precum ascunderea informației, puterea și coeziunea ar trebui considerate.[8]

Putem monitoriza calitatea softului în două moduri diferite. Dacă folosim factorii, criteriile și metricile unui model publicat precum McCall sau Boehm, atunci aceasta este numită abordarea model fix. Abordarea „definirea propriului model de calitate ” este al doilea mod de a monitoriza calitatea.

Calitatea este compusă din multe atribute, dar noi nu vom adopta caracteristicile de calitate ale unui model dat. În schimb vom alege noi înșine ce atribute calitative sunt importante.

Țelul construirii modelelor de produse soft este bineînțeles crearea și dezvoltarea unui produs soft mai bun.Dar ce înseamnă mai exact un produs soft mai bun? Pentru a răspunde la această întrebare trebuie luate în considerare câteva caracteristici calitative.

Abilitatea de întreținere a produselor soft (Maintainability)

Abilitatea de întreținere (Maintainability) este “ușurința cu care schimbările pot fi făcute pentru a satisface noile cereri sau pentru a corecta deficiențele” [Balci,97]. Un produs soft bine construit ar trebui să fie atât de flexibil încât să se acomodeze la schimbările viitoare, lucru ce va fi necesar pe măsură ce vor apărea noi cereri. Din moment ce întreținerea ocupă 70% din costul ciclului de viață a unui produs soft [Schach,99], importanța acestei caracteristici calitative nu poate fi omisă. Cel mai adesea programatorul responsabil cu scrierea unei secțiuni de cod nu este acela care trebuie să o și mențină. Din acest motiv calitatea documentației produsului soft afectează semnificativ abilitatea de întreținere a produsului soft.[2]

O altă definiție a abilității de întreținere a softului este ușurința de a găsi și corecta erorile din produsele soft. Ea este analoagă cu calitatea produselor hard de MTTR (mean time to repair – timp mediu de reparare). Deși nu există o modalitate de a măsura sau prezice direct abilitatea de întreținere a softului, există un corp semnificativ de cunoștințe despre atributele produselor soft care il fac mai ușor de menținut. Acestea includ modularitatea, documentarea internă, abilitatea de citire a codului (readability) și tehnici de codare structurate. Aceste atribute îmbunătățesc abilitatea de susținere, adică abilitatea de a face îmbunătățiri ale produsului soft.[8]

Metode de îmbunătățire a abilității de întreținere:

○ Inspectarea

○ Folosirea documentației pseudocod

○ Menținerea duală a sursei codului

○ Modularitatea

○ Structura logică a programului

Erorile sunt uneori introduse pentru a stabili o măsură a abilității de întreținere. De exemplu, un program are 100 de erori, de-a lungul evaluării sunt găsite 550 de erori, dintre care 50 sunt introduse. Poate fi estimat că 500 de erori reale rămân.

Menținerea produselor soft are costuri foarte ridicate. Ea include costuri de rescriere, testare, evaluare și integrare de noi trăsături.

Documentarea este unul dintre elementele care conduc la costuri de întreținere mari.[1]

Abilitatea de întreținere a sistemului soft depinde de:

○ Abilitatea de citire (Readability)

○ Extensibilitatea (Extensibility)

○ Testabilitatea (Testability)

Abilitatea de citire (Readability) a sistemului soft depinde de:

○ Forma de reprezentare

○ Stilul de programare

○ Consistența

○ Abilitatea de citire a limbajului de implementare a programului

○ Structurarea sitemului

○ Calitatea documentației

○ Instrumentele disponibile pentru inspectare

Extensibilitatea (Extensibility) permite ca modificărilor cerute la anumite locații să fie făcute fără efecte secundare nedorite.

Extensibilitatea depinde de :

○ Modularitatea sistemului soft

○ Posibilitatea limbajului implementat să indeplinească acest scop

○ Abilitatea de citire a codului

○ Disponibilitatea documentației inteligibile a programului

Testabilitatea (Testability) este calitatea care permite programatorului să urmeze executarea programului și evaluarea.

Testabilitatea sistemului soft depinde de:

○ Modularitate

○ Structurare

Programele modulare bine structurate sunt mult mai potrivite pentru testarea sistematică decât programele monolitice nestructurate.

Instrumentele de testare și posibilitatea de a formula condiții de consistență în sursa codului reduc efortul de testare și furnizează importante prerechizite pentru testarea extensivă și sistematică a tuturor componentelor sistemului.[7]

Siguranța calității produselor soft (Reliability)

Ar fi util să cunoaștem probabilitatea de eșec a softului, sau rata cu care erorile soft pot apărea. Deși aceste informații sunt moștenite în produsul soft, ele pot fi estimate numai din datele colectate din produsul soft defect ca și funcție în timp. Dacă anumite ipoteze sunt determinate, aceste date pot fi folosite în modelarea și calcularea metricilor de credibilitate. Aceste metrici încearcă să măsoare și să prezică probabilitatea eșecului pe durata unui interval de timp sau timpul mediu pentru eșec (mean time to failure – MTTF).

Siguranța hard este definită în termen de MTTF(mean time to failure) al unui anumit set de echipament. O noțiune analoagă este folositoare pentru produsul soft chiar dacă mecanismele de eșec sunt diferite și predicțiile matematice folosite pentru produsele hard nu au fost aplicate cu succes la produsule soft.

Siguranța produselor soft este definită ca măsură în care un program este așteptat să realizeze funcțiile intenționate cu o precizie cerută de-a lungul unei perioade date de timp. Proiectarea siguranței este preocupată de detectarea și corectarea erorilor în produsele soft; mai mult chiar, este preocupată cu tehnicile de compensare ale erorilor produselor soft necunoscute și ale problemelor din produsele hard și din mediile de date în care produsul soft trebuie să opereze.

O altă definiție a siguranței/credibilității (Reliability) este “frecvența cu care produsul soft eșuează, atunci când eșecul este un efect innaceptabil sau un comportament ce apare în condiții de operare ce sunt permise.”[Balci 97]. Frecvența eșecului produsului soft este măsurată de timpul mediu dintre căderi. La modul ideal, inginerii soft vor ca produsele lor să eșueze cât mai puțin posibil și să fie cât mai ușor de reparat. De exemplu, pentru anumite sisteme precum controlul de trafic aerian sau monitoarele cardiace, siguranța devine cea mai importantă caracteristică calitativă a produsului soft. Oricum, ar fi greu de imaginat un sistem de înaltă siguranță care să nu prezinte și o înaltă corectitudine și o bună abilitate de întreținere.[2]

Proprietățile abstracte ca toleranța la greșeli și abilitatea de recuperare sunt determinanți ai siguranței (reliability). Problema este: Sunt toleranța la greșeli și abilitatea de recuperare (recoverability) comportamente definitorii ale siguranței sau sunt caracteristici soft ce contribuie la siguranța și calitatea softului?

Cu ceea ce ne confruntăm este tensiunea dintre definițiile top-down ale atributelor de calitate și caracterizarea bottom-up (care este descrierea abstractă) ori clasificarea proprietăților soft (atât a proprietăților funcționale cât și a celor non-funcționale) care contribuie la atributele calitative de înalt nivel. Fie că privim toleranța la greșeli ca fiind un comportament, fie ca fiind o caracteristica soft, acest lucru nu are importanță. Ceea ce este important de recunoscut este că avem două căi de a ajunge la scopul nostru. Unele proprietăți ca modularitatea sau corectitudinea sunt clar caracteristici soft și nu comportamente sau utilizări. Cu altele precum toleranța la greseli nu este așa de ușor să faci distincție. Intuiția de bază pe care o folosim pentru a face astfel de distincții este aceea că, comportamentele tind să fie calități de sistem vast (system-wide qualities), în timp ce este bine să asociem caracteristicile soft cu componente particulare precum și cu un sistem global. Ca un exemplu, în ISO 9126, siguranța poate fi descompusă în toleranța la greșeli, maturitatea și abilitatea de recuperare.

Acest lucru este prezentat în urmatoarea schemă:

Figura 7. Descompunerea atributului calitativ siguranță

Caracterizarea atributului calitativ siguranță(reliability), prezintă câteva puncte importante legate de proiectera și implementarea modelelor calitative. Pentru a caracteriza orice atribut calitativ de înalt nivel este bine să formulăm un model funcțional de bază sau un model de utilizare și un model metric de suport. Astfel de modele ajută la minimizarea suprapunerii comportamentelor.

Siguranța caracterizează modul în care un sistem soft se comportă ca răspuns la patru tipuri de greșeli:

greșeli care duc la condiții anormale ce sunt generate extern și care apar ca input-uri ale sistemului soft ce îi violează capacitatea de a-și satisface comportamentele funcționale specifice.

Greșeli ce rezidă în erori care apar pe parcursul executării unui sistem soft ce provoacă devierea acestuia de la funcționalitatea sa specifică și prin urmare intrarea lui într-o stare anormală.

Erori care apar în output-urile sistemului soft ce sunt cauzate de greșeli în implementarea funcționalității.

Greșeli care conduc la eșecul sistemului soft.

Metricile corespunzătoare care carcaterizează siguranța unui sistem soft sunt comportamentele: maturitatea și disponibilitatea. Maturitatea poate fi interpretată ca fiind timpul mediu scurs între eșecuri de-a lungul vieții sistemului în timp ce disponibilitatea este timpul mediu de recuperare scurs după fiecare eșec.[6]

Figura 8. Clasificarea proprietăților atributului calitativ siguranță

Utilitatea produselor soft (Usability)

Pentru a ilustra procesele de definire și caracterizare vom explora un atribut calitativ, utilitatea(usability), mult mai aprofundat. Pentru început vom prezenta un set de proprietăți care definesc utilitatea sau sunt manifestări ale acesteia.

Figura 9. Descompunerea atributului calitativ utilitate

Pentru a aranja aceste proprietăți într-o ierarhie potrivită folosind strategia definire-caracterizare, vom clasifica întâi proprietățile ca fiind fie comportamente, utilizări sau caracteristici soft în funcție de definițiile acestor termeni.

Figura 10. Clasificarea proprietăților atributului calitativ utilitate

Comportamentele și utilizările candidează ca determinanți ai utilității. Putem avea, de asemenea, anumite comportamente care sunt subordonatele altora. Pentru a le ajusta, trebuie să interogăm sistematic fiecare proprietate dacă contribuie la/sau determină fiecare comporatment sau utilizare. [6]

De exemplu, trebuie să vedem dacă abilitatea de personalizare contribuie la abilitatea de învățare, la operabilitate, etc. Caracteristicile soft în schimb, caracterizează comportamentele și utilizările. O posibilă ierarhie definițională care apare ca rezultat al acestui întreg proces este prezentat mai jos:

Figura 11. Ierarhia definițională a utilității

2.5.4 Funcționalitatea produselor soft (Functionality)

Funcționalitatea este uneori mai importantă pentru funcționarea sistemului decât alte atribute. Definiția în ISO 9126 a funcționalității susuține că funcționalitatea este răspunsul scurt la întrebarea: „Ce vrei să facă acest produs soft ?”, fără a recurge la detalii referitoare la cum va realiza el acest lucru . Din punctul de vedere al calității, executarea funcționalității este baza ideplinirii nevoilor clientului. După aceasta, alte atribute calitative trebuie realizate cât mai bine posibil, dar pot fi compromise de scopuri economice.

Un model funcțional defensiv al siguranței este acela de a spune că la cel mai înalt nivel există trei clase nesuprapuse de funcționalitate pe care un sistem trebuie să le implementeze pentru a prezenta un comportament sigur: detectarea erorii, raportarea erorii (prin atributul calitativ vizibilitate subordonat funcționalității) și rezolvarea erorii. Funcționalitatea precedentă se confruntă numai cu situațiile în care sistemul este capabil să evite eșecul. Există un altfel de funcționalitate necesară recuperării/restaurării după eșecul sistemului soft (abilitatea de recuperare – recoverability). În fiecare dintre aceste tipuri de funcționalitate pot exista grade variate de sofisticare și completitudine și strategii alternative de abordare a situației.

2.5.5 Portabilitaea produselor soft (Portability)

Portabilitatea (Portability) este „ușurința cu care un produs soft poate fi folosit în configurații de calculator, altele decât cele curente pentru el.” [Balci 97]. Transpunerea produsului soft în alte configurații de calculator este importantă din mai multe motive. Primul, „produsele soft bune pot avea o viață de 15 ani sau mai mult, în timp ce produsele hard sunt frecvent schimabte la fiecare 4 sau 5 ani. Astfel, un produs soft de calitate poate fi implementat peste durata sa de viață în trei sau mai multe configurații hard diferite.” [Scach 99]. Al doilea, transpunerea produsului soft pe o nouă configurație de calculator poate fi mai ieftină decât construirea unui produs soft analog.[2]

Portabilitatea este acțiunea de producere a unei versiuni executabile a unui sistem soft într-un nou mediu bazat pe o versiune existentă. Există multe definiții pentru portabilitate. Una dintre ele este:

„O unitate soft este portabilă de-a lungul unei clase de medii în măsura în care costurile de transport și adaptare a ei într-un nou mediu sunt mai mici decât costurile sale de producere.”

Este important de reținut că portabilitatea este o alternativă la redezvoltare. O alternativă începe cu o implementare existentă, iar cealaltă începe cu o specificare. Când o nouă implementare este scopul, o decizie critică trebuie să fie făcută cu privire la ce abordare va fi mai puțin costisitoare.

O unitate soft va fi perfect portabilă dacă ar putea fi traspusă pe alte medii cu costuri nule, dar acest lucru nu este posibil niciodată în practică. În schimb, caracterizăm produsul soft prin gradul său de portabilitate care este în funcție de costurile de transoprtare și redezvoltare pentru un anumit mediu.

Entitatea primară ce trebuie transportată este de obiecei o aplicație sau un sistem soft. În anumite cazuri, produsele soft auxiliare precum instrumentele și bazele de date pot fi și ele transportate. Producerea documentației pentru noua implementare poate fi privită ca o activitate de transportare. Principalele tipuri de portabilitate sunt: portabilitatea binară (transportarea formei executabile) și portabilitatea sursei.

Portabilitatea binară oferă câteva avantaje, dar este posibilă numai între medii foarte similare, pe când portabilitatea sursei furnizează oportunități de adaptare a unității soft la o gamă largă de medii. Procesul de portabilitate are două componente principale: transportarea și adaptarea.

În final, trebuie să amintim că scopul portabilității nu este în mod necesar să producă multiple implementări care să se comporte identic în toate aspectele.

2.5.6 Eficiența produselor soft (Efficiency)

Eficiența (Efficiency) este „gradul în care produsul soft iși indeplinește scopul fără a risipi resursele” [Balci 97]. Eficiența este o caracteristică calitativă multifațetată și trebuie abordată ținând cont de o resursă particulară precum timpul de execuție sau spațiul de stocare. O măsură a eficienței este viteza de execuție a programului. O altă măsură este mărimea spațiului de stocare pe care programul îl cere pentru execuție. Cel mai adesea, aceste două măsuri sunt invers relaționate, adică creșterea eficienței de execuție cauzează o descreștere în eficiența de spațiu. Această relație este cunoscută ca interschimbarea spațiu-timp. Atunci când nu este posibil să construiești un produs soft eficient în fiecare aspect, cele mai importante resurse ale produsului soft trebuie să fie prioritare.[2]

Mai sunt multe calităti ale produselor soft, dar vom mai aminti doar: corectitudinea produselor soft (corectness) și abilitatea de reutilizare (reusability).

Corectitudinea(Correctness) este “gradul în care produsul soft corespunde la propriile cereri din specificație” [Balci 97]. La începutul ciclului de viață al unui produs soft cererile pentru producerea unui soft de calitate sunt determinate și formalizate în documentația de specificare. Un produs soft bine construit trebuie să satisfacă toate cererile menționate. Deși pare evident că produsul soft ar trebui să fie corect, realitatea este că această caracteristică este una foarte greu de evaluat. Datorită complexității enorme de produse soft este imposibil să realizezi o testare exhaustivă care să asigure că nu vor apărea erori în timpul rulării produsului soft. De asemenea, este important de ținut minte că anumite produse ale ciclului de viață ale softului precum și specificările de construire nu pot fi executate pentru testare. În schimb aceste produse trebuie testate cu alte tehnici variate precum inspecții sau alte tehnici.

Abilitatea de reutilizare(Reusability) este “usurința cu care produsul soft poate fi folosit pentru dezvoltarea altor produse soft ” [Balci 97]. Prin refolosirea unui produs soft existent producătorii pot crea un produs soft mult mai complex într-o perioadă de timp mult mai scurtă. Reutilizarea este deja o tehnică comună folosită în alte discipline de construcții. Produsul soft poate fi proiectat astfel încât să poată fi refolosit în multe situații. Un exemplu simplu de reutilizare a produsului soft ar putea fi dezvoltarea unei rutine de sortare eficiente care poate fi încorporată în multe aplicații viitoare.[2]

Unele dintre aceste calități nu vor fi importante pentru un anumit sistem soft și astfel nici o activitate nu va fi realizată pentru a le evalua sau îmbunătăți. Maximizarea unor calități poate cauza descreșterea altora. De exemplu, creșterea eficienței unei componente din produsul soft poate cere scrierea unor parți din ea în limbaj de asamblare. Aceasta va descrește transportabilitatea și abilitatea de întreținere a produsului soft.

Cu aceste caracteristici răspunsul la întrebarea „ Ce este un produs soft mai bun? ” devine mult mai precisă. Utilizând aceste caracteristici, inginerii de soft pot evalua punctele tari și slabe ale produselor soft. În plus, aceste caracteristici calitative pot fi folosite la compararea meritelor paradigmelor de dezvoltare ale produselor soft. În acest caz, inginerii soft nu se referă la paradigma în sine ca fiind de încredere sau portabilă. În schimb, ei se vor referi la produsele soft dezvoltate cu această paradigmă ca fiind mult mai de încredere sau mult mai portabilă decât produsele dezvoltate cu alte paradigme. Cele mai proeminente două paradigme de dezvoltare a produselor soft sunt: paradigma clasică sau procedurală și paradigma orientată spre obiect

CAP. III APLICAȚII PENTRU CALCULAREA INDICATORILOR ÎN VEDEREA EVALUĂRII CALITĂȚII SOFT

Capitolul de față este dedicat prezentării în practică a unei părți a teoriei prezentate în capitolele anterioare, datorită faptului că măsurarea calități produsului soft este un proces care durează pe tot parcursul ciclului de viață al produsului soft și nu poate fi scris un program care poate să decidă gradul de calitate în mod echivoc a unui produs soft.

Programele prezentate în acest capitol au ca și scop măsurarea anumitor indicatori care contribuie la procesul de măsurare a calității produsului soft. Unii dintre ei sunt destul de criticabili pentru că nu dau rezultate la fel de eficace folosind limbaje de programare diferite, sau din cauza faptului că rezultatele furnizate trebuie să fie integrate între alte informații pentru o bună evaluare a calității softului.

3.1 Numărul comentariilor în program

Numărul potrivit al comentariilor în program ne sugerează că programatorul, pentru a ușura înțelegerea programului în viziunea unei ulteriore modificări, ridică calitatea softului. Dacă, comentariile se găsesc într-un procent corespunzător în codul sursă însemnă că instrucțiunile sunt bine documentate, cu scopul de a ajuta grupul care se ocupă cu întreținerea programului în înțelegerea acestuia.

Lansând în execuție programul numar_comentarii.exe (după numele lui trebuie să apară numele fișierului ce conține codul sursa a unui program destinat analizării), ca rezultat vom obține numărul liniilor din codul sursă, numărul comentariilor și ne furnizează informații respectiv cât la sută din numărul liniilor codului reprezintă comentariile.

Codul sursă programului numar_comentarii.exe este următorul:

Fie conținutul fișierului de intrare următorul cod sursă:

{program test1.pas}

{ Sa se scrie un subalgoritm care genereaza primul numar prim

mai mare decat un numar natural n dat.}

program generare;

uses crt;

var n: longint;

{––––––––––––––––}

procedure CRSHIDE; assembler; {aceasta este o procedura assembler}

asm mov ax,$0100;

mov cx,$2607;

int $10;

end;

{––––––––––––––––}

procedure CRSSHOW; assembler; {aceasta este o procedura assembler}

asm mov ax,$0100;

mov cx,$0506;

int $10;

end;

{––––––––––––––––}

function NEXTPRIM(x:longint):longint; {aceasta este o functie}

{ genereaza primul numar prim mai mare decat X }

var i: longint;

prim: boolean;

begin

repeat

x:=x+1; prim:=(x=2); i:=3;

if not prim then prim:=odd(x) and (x>2);

if prim then

while (i<=trunc(sqrt(x))) and (prim) do

begin

prim:=(x mod i>0); inc(i,2);

end;

until prim;

nextprim:=x;

end;

{––––––––––––––––}

begin {acesta este programul principal}

textcolor(10); textbackground(0); clrscr;

gotoxy(20,12); write('Introduceti numarul '); read(n);

CRSHIDE; clrscr; gotoxy(16,12);

writeln('Numarul prim mai mare decat ',n,' este ',NEXTPRIM(n));

sound(600); delay(200); sound(480); delay(200);

nosound; readkey; textcolor(7); clrscr; CRSSHOW;

end.

Rezultatul rulării programului numar_comentarii.exe este următorul:

Numărul procedurilor și lungimea medie a lor

Valorile numerice ne pot furniza informații destul de utile privind complexitatea programelor. Programele care au proceduri foarte lungi în mod implicit sunt și mai complexe decât programele cu lungimea procedurilor mai redusa în care lizibilitatea este mai ridicata. Programul numără lungimea subrogramului nu prin numărarea liniilor din care este format subrogramul, ci prin numărarea operanzilor și operatorilor din care este alcătuit.

Codul sursă al programului lungime_medie_subprogram.exe este:

Fie conținutul fișierului de intrare următorul cod sursă:

Rezultatul rulării programului lungime_medie_subprogram.exe este următorul:

3.3 Lungimea medie a identificatorilor

Prin identificatori înțelegem denumirile variabilelor, constantelor, denumirile programelor, procedurilor și funcțiilor. Lungimea acestora este un indicator de calitate al programelor, sugerând cât de explicit sunt denumirile folosite în program astfel ajutând personalul de întreținere în înțelegerea și corectarea programului în caz de necesitate. În mod natural, dacă denumirile sunt prea lungi ne solicită prea mult timp citirea programului, dar având denumiri foarte scurte timpul de a înțelege programul este mult mai mic. Programul analizează lexical fișierul de intrare

Codul sursă programului lungime_medie_identificatori.exe este următorul:

Fie conținutul fișierului de intrare următorul cod de sursă:

Rezultatul rulării programului lungime_medie_subprogram.exe este următorul:

Bibliografie

[1] Kevin Englehart – Advanced Software Engineering – “Software Quality

Assurance”

http://www.ee.unb.ca/kengleha/courses/CMPE3213/SQA.htm

[2] Osman Balci – “Software Engineering”

http://courses.cs.vt.edu/csonline/SE/Lessons/Qualities/Lesson.html#refs#refs

[3] QA Systems – “Software Quality Problems”

http://www.qa-systems.com/concepts/iso9126.html

[4] Liugi Buglione, Alain Abran – “A Quality Factor for Software”

http://www.lrgl.uqam.ca/publications/pdf/408.pdf

[5] Larry Berstein – ISO 9126: The “Standard of Reference”

[6] R. Geoff. Dromey – „SOFTWARE PRODUCT QUALITY: Theory, Model,

and Practice”

http://www.sqi.gu.edu.au/docs/sqi/misc/SPQ-Theory.pdf

[7] Nguyen Xuan Huy – „Quality attributes of software products”

http://www.netnam.vn/unescocourse/se/12.htm

[8] Matias Nyman, Andreas Nals – „SOFTWARE QUALITY ENGINEERING”

http://satc.gsfc.nasa.gov/assure/agbsec4.txt

[9] Katalin Balla – „Software Quality and Management”

www.iit.bme.hu/~balla/SQM2-Product.ppt

[10] Everald E. Miles – “Software Metrics”

http://www.literateprogramming.com/cm12.pdf

[11] Richard Veryard – ”Software Component Quality”

http://www.users.globalnet.co.uk/~rxv/CBDmain/DIPQUE.htm