Calitatea Software Ului

8/9/2019 Calitatea Software Ului

1/21

Calitatea software-ului


2/21

1. Introducere

De i calitatea este un lucru bun, calitatea unui sistem, n practic , poatefi un atribut vag i insuficient definit. De aceea trebuie s se defineasc exact ce calit i cerem unui sistem.

Calitatea prive te toate etapele planific rii i execut rii proiectului, dar sedovede te de un interes particular n urm toarele etape:

Identificarea infrastructurii proiectului; analiza caracteristicilor proiectului;

identificarea produselor i activit ilor;

revizuirea i editarea planului.


3/21

2. Importana calit ii software-ului

Caracteristicile speciale ale software-ului, n particular inatngibilitatea icomplexitatea, cer anumite lucruri speciale: Natura critic n cre tere a software-ului . Utilizatorul e anxiosgndindu-se la calitatea software-ului, mai ales la fiabilitatea acestuia. Ecazul organizaiilor care devin din ce n ce mai dependente de sistemelede calcul i software-ul e utilizat din ce n ce mai mult n arii care suntcritice d.p.d.v. al siguranei, cum ar fi controlul avioanelor.

Intangibilitatea software-ului . Acest lucru face dificil cunoa tereafaptului c o anumit sarcin n proiect a fost completat satisf c tor.Rezultatele acestor sarcini pot fi f cute tangibile cernd dezvoltatorului s

produc deliverables care s fie examinate pentru calitate. Acumularea erorilor n timpul dezvolt rii software . Deoareceprodusul e f cut dintr-un num r de pa i unde ie irea unuia devine intrareaaltuia, erorile produse n etapele timpurii ale proiectului conduc laamplificarea lor. Cu ct o eroare e descoperit mai trziu, cu att mai multcost reparaea ei.


4/21

3. Definirea calit ii software-ului

Pentru orice sistem software, ar trebui s fie trei specificaii: o specificaie funcional descriind ceea ce trebuie s fac sistemul;

o specificaie de calitate, ce prive te ct de bine opereaz funciile;

o specificaie de resurse, ce prive te ct de mult se cheltuie te pesistem.

James A.McCall ( An Introduction to Software Quality Metrics, 1978 ) ncearc s identifice calit i specifice produselor, potrivite software-ului.El grupeaz calit ile software n 3 mulimi:

product operation qualities ; product revision qualities ;

product transition qualities .


5/21

Factorii product operation quality Corectitudinea . Marja pn la care programul staisface specificaiile i

ndepline te obiectivele utilizatorului; Fiabilitatea. Marja pn la care se a teapt ca programul s lucreze nparametrii specificai cu precizia dorit ; Eficiena. Cantitatea de resurse cerut de software;

Integritate . Marja pn la care accesul la software sau date apersoanelor neautorizate poate fi controlat; Usability (mod de utilizare) . Efortul necesar pentru a nva, opera,preg ti intrarea i interpreta ie irea.

Factorii product revision quality ntreinere . Efortul necesar pentru localizarea i repararea erorii ntr-unprogram operaional; Testabilitatea . Efortul necesar pentru a testa un program pentru aasigura c lucreaz n parametrii specificai; Flexibilitate. Efortul necesar pentru a modifica un program operaional.


6/21

Factorii product transition quality Portabilitate . Efortul necesar pentru transferul programului de pe o

configuraie hardware i un mediu software pe alta/altul; Refolosirea . Marja pn la care un program poate fi utilizat n alteaplicaii; Interoperabilitate . Efortul necesar pentru a cupla un sistem cu altul.

Pentru fiecare criteriu, trebuie inventate ni te msuri pentru a evaluagradul n care calitatea e prezent .

Orice msur relativ bun trebuie s compare num rul unit ilor lamaximul posibil n acele circumstane. De exemplu, num rul maxim deerori ntr-un program va fi raportat la m rimea programului, astfel nctmsura num rul de erori la mia de linii de cod e mai util dect num rulde erori din program.

n anumite cazuri putem msura calitatea n mod direct, n timp ce naltele lucrul msurat nu e calitate propriu-zis , dar reprezint un indicator care s indice n ce grad e prezent calitatea.


7/21

4. ISO 9126 (standard publicat n 1991)

ISO 9126 identific 6 categorii de calitate a software-ului: funcionalitate , care acoper funciile pe care produsul software leasigur pentru satisfacerea nevoilor utilizatorilor;

siguran (reliability ), care se refer la capabilitatea software-uluipentru a men ine nivelul de performan ; usability , care se refer la efortul cerut pentru a utiliza software-ul; eficien , care se refer al resursele fizice folosite cnd software-ul e

executat; mentenabilitate , care se refer la efortul cerut pentru a face schimb risoftware-ului; portabilitate , care se refer la abilitatea software-ului de a fi transferat

n diferite medii.

ISO 9126 ofer subcaracteristici pentru fiecare categorie primar , utile

pentru clarificarea categoriei principale.


8/21

Funcionalitate Suitability (ct de potrivit este)Acuratee

Interoperabilitate (abilitatea de a interaciona)Conformitate(compliance )(fa de standardele legale)Securitate

Siguran Maturitate (frecvena e ecurilor datorate erorilor)Toleran la eroriRecuperabilitate

Usability nelegere (Understandability ) nvare (Learnability )Operabilitate (Operability )

Obs. Understandability e calitatea de a putea p trunde conceptele logice i aplicabilitatealor. Learnability este diferit de operability . Un instrument software poate fi uor de nvat,dar consumator de timp la utilizare, deoarece, de exemplu, utilizeaz un num r mare demeniuri n cascad .

Eficien Comportare n timpComportare d.p.d.v. al resurselor


9/21

Mentenabilitate AnalisabilityFlexibilitate (Changeability)

StabilitateTestabilitate

Obs. Analisability (sau diagnosability ) este u urina cu care de determin cauza unui e ec.Changeability (sau flexibility ) implic faptul c furnizorii de software l schimb totdeauna.Stabilitatea nseamn c exist un risc mic ca o modificare a software-ului s aib efectenea teptate.

Portabilitate AdaptabilitateUurina instal rii (Installability )Conformitate (Conformance )Uurina de a fi nlocuit (Replaceability )

Obs. Conformance , spre a se distinge de compliance , se refer la acele standarde careprivesc portabilitatea. Exemplu: folosirea unui limbaj de programare standard n multe mediisoftware/hardware e exemplu de conformance .

Obs. Replaceability se refer la factori care dau compatibilitatea n sus ntre componentelesoftware vechi i cele noi.


10/21

ISO 9126 ofer anumite indicaii privind folosirea caracteristicilor decalitate. Pentru sistemele interactive (interactive end user system ),

elementul primordial d.p.d.v. al calit ii ar fiusability .O dat cerinele software stabilite, se stabilesc urm torii pa i:

Selectarea metricilor de calitate . Nu sunt date indicaii n standardul ISO

9126 privind aplicabilitatea diverselor msuri ce trebuie folosite.Definirea nivelelor de rating . Metricile folosite trebuie s se mapeze pescale care s indice gradul n care au fost satisf cute cerinele.

Definirea criteriilor de evaluare . Este felul n care scorurile d.p.d.v. alcalit ii se combin pentru a da o vedere de ansamblu asupra produsului.Mai jos e dat un exemplu de acordare a scorurilor:


11/21

5. Msuri practice ale calit ii software

Mai jos sunt date orientativ anumite modalit i de msurare a unor calit iparticulare. Fiecare proiect va trebui s aib ns propriile msuri.

Reliability Aceasta poate fi msurat n termeni de: disponibilitate( availability) , procentul unui interval de timp n caresistemul poate fi folosit; timpul mediu dintre e ecuri , timpul total de lucru, mp r it la num rulde e ecuri; e ec la cerere , probabilitatea ca un sistem s nu fie disponibil la un

anumit timp sau probabilitatea ca o tranzacie s eueze; activitatea de suport ( support activity ), num rul de rapoarte de erori.


12/21

Mentenability Poate fi vzut ca flexibilitate plusdiagnosability, care poate fi definit drept timpul mediu necesar pentru diagnosticarea unei erori.Obs . D.p.d.v. al utilizatorului,mentenability prive te timpul scurs ntredetectarea unei erori i corectarea ei, iar d.p.d.v. al managementului de

programare ca efortul necesar.

Extendibility (capacitatea de a fi extins)E o component a flexibilit ii. Se define te ca productivitatea necesar pentru a ncorpora anumite caracteristici noi n sistemul existent.


13/21

6. Standarde externe

Unele standarde de calitate au fost gndite pentru toate produsele, nudoar pentru produsele software.I) O privire asupra cerinelor standardului BS EN ISO 9001:

a) Conducerea trebuie s defineasc i s documenteze politic privindcalitatea i trebuie s asigure c aceast politic e adus la cuno tinapersoanelor din toate nivelele;

b) Toate procedurile de control al calit ii trebuie documentate;

c) Toate contractele pentru a furniza bunuri i servicii trebuie s conin cerine agreate mutual pe care dezvoltatorul este capabil s le livreze;d) Trebuie s existe proceduri pentru controlul i verificrea designului

sistemului ce urmeaz s fie livrat, astfel nct s fie ndeplinitecerinele stabilite cu utilizatorul;

e) Trebuie s existe proceduri care s aprobe designul i documentaiaauxiliar .

f) Acolo unde componentele sistemul ce urmeaz s fie livrate suntobinute de la un partener extern, trebuie s existe proceduri care s asigure, s verifice i s menin calitatea acestor componente;


14/21

g) Produsele individuale trebuie s fie identificabile, precum icomponentele sale;

h) Procesul prin care e creat produsul final trebuie s fie planificate imonitorizare;

i) Inspecia i testarea trebuie s aib loc n timpul fazei de dezvoltare i nainte de livrare. De asemenea, testele i inspeciile trebuie s se fac

i asupra componentelor obinute de la parteneri extern. j) Echipamentul folosit n procesul de producie trebuie s fie controlatadecvat n privina calit ii;

k) Statutul test rii pentru toate componentele i sistemele trebuie s fie nregistrat clar n toate etapele;

l) Trebuie avut grij ca itemii care sunt cunoscui ca potenial de a sedefecta s fie folosii cu mare aten ie;

m) Cnd se identific un defect, trebuie luate msuri pentru ndep rtareap r ii defecte i pentru a ne asigura c defectul nu apare din nou;n) Trebuie s existe proceduri corespunz toare manipular rii, stoc rii,

mpachet rii i livr rii produsului;o) Trebuie meninute suficiente nregistr ri care s demonstreze c

sistemul de asigurare a calit ii lucreaz cu succes;


15/21

p) Sistemul de management al calit ii software trebuie s fie supusauditului;

q) Activit ile de service i suport trebuie s fie subiect pentru sistemul demanagement al calit ii;

r) Dezvoltatorul trebuie s stabileasc tehnici statistice potrivite care s verifice c produsul final poate fi recepionat.

II) TickIt. Department of Trade and Industry (DTI) a formulat standardul

TickIt, care d interpretarea standardului ISO 9000 (mai ales n ceea ceprive te dezvoltarea software). Acesta include cerine, cum ar fi:

a) Trebuie s existe un plan de dezvoltare detaliat de a ncepe

dezvoltarea;b) Vor fi folosite proceduri de control n toate etapele dezvolt rii;c) Trebuie f cute revizuiri ale designului;d) Trebuie revizuit metodologia suitability designului;e) Trebuie revizuit progresul sistematic;


16/21

f) Trebuie s fie posibil gsite caracteristicile designului software laspecificaii i cerine;

g) Designul trebuie documentat corespunz tor;h) Trebuie produse planurile de testare potrivite, specificaiile i

nregistr rile;i) Trebuie pus n practic un code of practice , care guverneaz felul n

care software-ul e dezvoltat.

Code of practice trebuie s includ cerine precum:

Designul trebuie s fie divizat pe nivele, fiecare cu intr ri i ie iriidentificabile;

Software-ul trebuie organizat pe module;

Un modul trebuie s ndeplineasc n mod normal o singur funcie sauo mulime de funcii nrudite;

o descriere trebuie s existe pentru fiecare modul.


17/21

III)Capability process models n loc s verifice c un sistem e n stare s detecteze erori, un client poatecere c vad dac furnizorul folose te metode i instrumente dedezvoltare software care s fie potrivite pentru a produce un software debun calitate.

n SUA s-a dezvoltat uncapability maturity model (CMM) la SoftwareEngineering Institute (SEI). Acesta ncearc s plaseze organiza iile careproduc software ntr-unul dintre cele 5 nivele de maturitate pentru a indicact de sofisticate sunt i ct de calitative sunt practicile de producere asoftware-ului. Aceste nivele dunt definite dup cum urmeaz :

Nivelul 1: InitialProcedurile urmate tind s fie ntmpl toare. Anumiteproiecte vor avea succes, dar asta datorit doar priceperii unor profesioni ti din echip (inclusiv managerii). Nu exist nivel 0 i deaceea orice organiza ie va fi implicit la acest nivel.

Nivelul 2: Repeatable Organizaiile de la acest nivel vor aveaproceduri de baz pentru managementul proiectelor. Totu i felul ncare o sarcin individual e dus la bun sfr it va depinde n maremsur de persoana care o face.

Nivelul 3: Defined Org ni iile definit fel l n c re fiec re s rcin


18/21

Nivelul 3: Defined Organizaiile au definit felul n care fiecare sarcin a ciclului de via al dezvolt rii software va fi f cut .

Nivelul 4: Managed Produsele i procesele implicate n dezvoltareasoftware sunt subiect al msurii i controlului.

Nivelul 5: Optimizing mbun t irile aduse procedurilor suntconcepute i implementate folosind datele adunate n proceseul demsurare.

Pentru fiecare dintre aceste nivele, exceptnd nivelul 1, s-au identificat ariide proces cheie ( key process areas KPAs ) care s fac distincia ntrenivelul curent i nivelele mai joase. Aceste KPAs sunt listate mai jos:


19/21

7. Tehnici care ajut la cre terea calit ii software

Tehnicile care ajuta la creterea calit

ii software por fi ncadrate n trei

mari teme:

Increasing visibility Un pas important pentru a face procesele dedezvoltare software mai vizibile a fost pledoaria lui Gerald Weinbergpentru o programare mai puin egoist (egoless programming ), care a

ncurajat practica simpl a programatorilor care s se uite la codulcelorlai.

Procedural structure S-au dezvoltat, de-a lungul anilor, metodologii ncare fiecare proces n ciclul de dezvoltare software s fie cu gruj planificat pe etape.

Checking intermediate stages Un element important n vedereaobinerii unor practici pentru calitate a fost verificarea corectitudiniimuncii n etapele incipiente, conceptuale. Ideea este s se poat obine modele ale muncii, chiar dac nu perfecte, care s poate fidepanate ulterior.


20/21

Dintre tehnicile specifice temelor majore aminitite, enumer m:

Inspec iile Metoda Fagan (vezi M.E.Fagan: Design and code inspections to reduceerrors in program development, IBM System Journal, 15(3) ).

Programarea structurat (Dijkstra a introdus conceptul, iar Harlan Mills adezvoltat conceptul, mp r ind dezvoltarea software n 3 echipe: una

pentru specifica ii, una pentru dezvoltare a codului i una de testare)

Metode formale (care definesc pre- i post- condi ii pentru fiecare procedur )

Software quality circles (SWQC) ( tehnic ap rut n Japonia): un quality

circle e un grup de 4-10 oameni lucrnd n aceea i arie, care se ntlnesco or pe s ptmn (de exemplu) pentru a identifca, analiza i rezolvaproblemelor legate de munca lor comun .

Abordarea GQM (Goal/Question/Metrics)


21/21

Concluzii

Calitatea n sine e un concept vag i cerinele de calitate practice trebuiedefinite cu mare atenie Trebuie s existe moduri practice de testare a prezen ei sau absen ei

calit ii Multe dintre calit ile care sunt aparente utilizatorilor de software pot fitestate doar atunci cnd sistemul e complet

E nevoie deci de modalit i de verificare a calit ii probabile n timpuldezvolt rii Anumite tehnici de cre tere a calit ii se concentreaz pe testarea

produselor procesului de dezvoltare, n timp ce altele ncearc s evalueze calitatea proceselor de dezvoltare folosite.

Calitatea Software Ului

Documents

Transcript of Calitatea Software Ului