CURS 4

1.2.3.5. SISTEME DE GESTIUNE A RETELELOR

Comunicarea între nodurile reţelei
• Sistemele de gestiune a retelelor administrează şi monitorizează retelele pe care
organizatiile se bazează
➢ pentru a transporta date între noduri.
• Aceste sisteme trebuie să fie interoperabile, fiabile şi tolerante la defecte, deoarece
➢ majoritatea utilizatorilor lor nu îşi pot permite să aibă comunicaţiile perturbate
[34].
1.2.3.6 SISTEME PENTRU TELECOMUNICATII
Sistemele de telecomunicatii reprezintă coloana vertebrală a modelului de afaceri al
operatorului de telecomunicatii.
• Ele folosesc infrastructuri uriaşe precum
➢ turnurile de telecomunicatii,

➢ sateăţii şi

➢ cablurile submarine
• şi regrupează functiile de
➢ operare,

➢ administrare,

➢ Intretinere şi

➢ furnizare.
Tipuri de sisteme
• Aceste functii de gestionare executate de structuri IT mari furnizează sisteme sau
retele pentru
➢ indicarea defecţiunii,

➢ monitorizarea performantei,

➢ managementul securităţii,
1
➢ functine de diagnosticare a traficului,

➢ configurare,

➢ facturarea şi

➢ datele furnizate de furnizorii de date.

Tehnologia telecomunicaţiilor
Trebuie luat în considerare faptul că
➢ tehnologia de telecomunicatii existentă variază

✓ de la sisteme vechi incorporateln diferite tipuri de hardware

✓ până la instalafii moderne şi complet informatizate

- toate acestea trebuie să coopereze şi să coexiste într-o manieră productivă.
Caracteristicile de calitate
Caracteristicile de calitate care răspund acestor preocupări sunt:
➢ funcţionalitate,

➢ fiabilitate,

➢ utilizabifitate

➢ eficienţa [32].
1.2.3.7 SI PENTRU MANAGEMENT
• SI pentru management sunt utilizate în principal de
➢ managerii şi expertii in domeniul afacerilor pentru

✓ a face previziuni şi a lua decizii de afaceri.

• Având în vedere că aceşti utilizatori au, de obicei, o competentă IT limitată,
➢ uşurinta utilizării este o caracteristică importantă a eficientei.
• Din perspectivă de utilizare a afacerii, 51 pentru management oferă date necesare
pentru luarea deciziilor strategice, oferind servicii ca:
Servicii ale SI pentru management
➢ generarea situati ilor financiare, a rapoartelor de inventar sau a rapoartelor privind
starea vânzărilor
2
➢ răspunsuri la intrebările manageri lor oferind diferite scenarii de decizie şi
rezultatele lor
➢ sprijin al procesului decizional în domeniul resurselor umane.

➢ furnizarea de informatii pentru analiză şi planificare bugetară.

➢ facilitarea auditurilor prin furnizarea unei piste complete de audit.

Subcaracteristici de calitate
• Subcaracteristicile de calitate importante pentru aceste servicii sunt:
➢ funcţionalitate,

➢ utilizabilitate şi

➢ întreţinere (32).
1.2.3.8 SISTEME DE GESTIUNE A INFORMATIILOR
Sisteme de gestiune a informatiilor
Sistem de gestiune a informatillor este un termen larg care descrie o multitudine de
sisteme, al căror obiectiv principal este
➢ gestionarea informatiilor.
• Unele dintre subcategoriile acestor tipuri de sisteme sunt
➢ sistemele de gest ionare a continutului,

➢ sistemele de gest ionare a documentelor,

➢ sistemele de gest ionare a activelor digitale sau

➢ sistemele de informatii geografice [351].

Informaţiile
• Funcţionalitatea comună a acestor sisteme este capacitatea de a
> regăsi,
➢ stoca si

➢ manipula informaţiile.
• Ceea ce este interesant este faptul că in multe cazuri factorul de risc critic care
afectează aceste sisteme nu este legat de infrastructura sistemului în sine, ci

3
➢ de informatiiile pe care le gestionează.
Factori de calitate
Cei mai importanţi factori de calitate pentru acest tip de sisteme:
➢ securitate,

➢ operabilitote,

➢ acurateţe şi

➢ schimbabilitate (32).
1.3 CALITATEA UNUI SI CA INDICATOR AL MATURITATII
Calitatea este un indicator al maturităţii?
• Nu este o evaluare ultimă şi totdea una adevărată, dar în cele mai multe cazuri
➢ calitatea se asociază cu maturitatea.
• Companiile tinere, imature, de obicei, nu îşi pot permite să dezvolte mai mult decăt
un set de functionalităti atractive, în timp ce
➢ organizatiiie mature pot dezvolta şi calitatea, astfel incăt în acest sens

✓ nivelul de calitate observat intr-un SI este

- un indicator al nivelului de maturitate al dezvoltatorului său.

Evaluarea maturităţii
• La evaluarea maturitătii unei organizatii de dezvoltare software,
➢ se pot aplica metode şi modele sofisticate (CCMI, SPICE sau ISO 9000),

➢ dar se poate ajunge la concluzii care nu reflectă in întregime realitatea.

• Toate cele mai bune procese nu vor înlocui indicatorii tangibili ai maturitătii reale:
➢ functionalitătile şi

➢ calitatea SI.
Calitatea: indicator mai restrictiv
• Se poate spune chiar că, pentru că
➢ funcţionalitălde sunt întotdeauna prezente într-un SI şi în schimb,

➢ calitatea este doar uneori prezentă,

4
 ✓ calitatea este un indicator mai restrictiv.
1.3.1 CMM/CMMI
CMM şi CMMI
• Modelul de maturitate a capacitătilor (Capability Maturity Model: CMM) s-a născut
în 1990 ca urmare a efortului specialiştilor de la Institutul de Inginerie Software (SEI)
al Universitătii Carnegie Mellon [7].
• Următoarea versiune, Integration Model Capability Maturity (Capability Maturity
Model Integration: CMMI), este cunoscută în industrie ca model de bune practici.
CMMI
• Aceasta combină practicile de ingineria sistemelor, ingineria software, procesul
integrat de dezvoltare a produselor (IPPD) şi disciplinele furnizorilor de surse.
• CMMI este folosit în principal pentru a "oferi orientări pentru o organizatie care să-
şi imbunătătească
➢ procesele şi capacitatea de a gestiona dezvoltarea,

➢ achizitia
CMMI: model unitar
CMMI (Tab. 1.2) a fost conceput pentru a permite organizatiilor
➢ să se bazeze pe un model unitar pentru

✓ a-şi evalua maturitatea şi capacitatea,

✓ a-şi stabili priorităti pentru Imbunătăţiri şi

✓ a le ajuta să-şi amelioreze practicile.

5
Zone de proces
• CMMI este disponibil pentru diverse combinatii de discipline in două reprezentări:
➢ planificat şi

➢ continuu.
• Modelul este impărţit în zone de proces (Process Areas),
➢ fiecare continând un set de practici generke si spedfice (Fig.1.6)

✓ care prin existenta sau lipsa lor pot evidenţia maturitatea unei organizaţii.
6
 Procesul calitatii
• În manualul CMM / CMMI găsim:
➢ "[in CMM], expresia obiective de calitate performanţa procesului acoperă
obiectivele şi cerintele privind calitatea produselor, calitatea serviciilor şi
performanta proceselor."
• În manualul CMM/CMMI o analiză detaliată oferă peste 400 de referinte la
calitate,
➢ dar toate vor purta notiunea de proces care, într-un fel sau altul, ar trebui să
ajute la crearea unui produs software de calitate.
Calitatea în nivelele de maturitate
• O ilustrare rapidă a prezentei subiectului calitătii în nivelele de maturitate ar
putea arăta după cum urmează:
> Nivelul 1: Nici unul
> Nivelul 2: Obiective specifice pentru performanta procesului, e.g.
✓ calitatea,

✓ durata ciclului şi

✓ scara de timp,

✓ utilizarea resurselor

➢ Nivelul 3: La fel ca Nivelul 2.

➢ Nivelul4: Calitatea şi performanta procesului sunt intelese în termeni

statistici şi sunt gestionate pe toată durata procesului

7
 ➢ Nivelul S: Selectarea şi implementarea în mod sistematic a imbunătătirilor
de proces şi tehnologie care contribuie la îndeplinirea obiectivelor de calitate şi de
performantă stabilite.
• Care este atunci legătura dintre maturitatea unei organizaţii şi calitatea
produselor sale?
Legătura dintre maturitate şi calitate
• În primul rănd: nu este automată.
• Organizatia poate să aibă toate cele mai bune procese existente, să fie
certificată continuu ISO 9000 şi totuşi
➢ să producă incă produse care nu vor supravietui nici măcar o zi.
• Nivelul de maturitate ar putea fi comparat cu cunoaşterea unui cămp de luptă
—
➢ cu căt cunoaşterea este mai profundă, cu atât mai mari sunt şansele de
victorie.
✓ Dar sunt incă doar şanse, nu certitudine.
1.3.2 SPICE ISO 15504
SPICE
• Software Process Improyement and Capability Determination (SPICE) este o
initiativă internaţională de sprijinire a elaborării unui standard international pentru
evaluarea proceselor software [36].
• Primul proiect de lucru a fost elaborat în iunie 1995, cu transmiterea către ISO / IEC
a procesului normal de dezvoltare a standardelor internationale.
SPICE are zece părţi
• În 1998, documentele au fost publicate cal50/1EC TR 15504: 1998 - Evaluarea
proceselor software.
• SPICE în ISO/IEC 15504 are zece părţi:
➢ Partea 1: Concepte şi vocabular

➢ Partea 2: Efectuarea unei evaluări

➢ Partea 3: Ghid pentru efectuarea unei evaluări

8
➢ Partea 4: Ghid pentru imbunătăţirea procesului şi determinarea capacităţii
procesului
➢ Partea 5: Un model exemplar de evaluare a procesului

➢ Partea 6: Un model exemplar de evaluare a procesului ciclului de viaţă al

sistemului
➢ Partea 7: Evaluarea maturităţii organizaţionale

➢ Partea 8: Un model exemplar de evaluare a procesului pentru managementul

serviciilor IT
➢ Partea 9: Profilul ţintă al procesului

➢ Partea 10: Prelungirea siguranţei

Cadru pentru evaluarea proceselor
• SPICE oferă un cadru pentru evaluarea proceselor.
➢ Acest cadru poate fi utilizat de către organizatiile implicate în

✓ planificarea, gestionarea, monitorizarea, controlul şi Imbunătătirea achizifiel,

furnizării, dezvoltării, functionăni, evolutlei sustinerii
❖ produselor / serviciilor.
Utilizarea rezultatelor evaluării
• Evaluarea proceselor analizează
➢ procesele utilizate de o organizatie pentru

✓ a determina dacă sunt eficientein atingerea obiectivelor.

• Rezultatele pot fi utilizate pentru a conduce
➢ activităRiledeimbunătăsire a procesului sau

➢ determinarea capacitătii procesului prin

✓ analizarea rezultatelor in contextul nevoilor organizatiei,

❖ identificănd punctele forte, punctele slabe şi riscurile inerente

proceselor.
Scopurile evaluării cu SPICE

9
• SPICE oferă o abordare structurată pentru evaluarea proceselor in următoarele
scopuri:
➢ prin sau in numele unei organizatii, cu scopul de a intelege stadiul propriilor
procese pentru imbunătătirea lor
➢ prin sau în numele unei organizatii, cu scopul de a determina adecvarea propriilor
procese pentru o anumită cerintă sau clasă de cerinte.
➢ prin sau In numele unei organizatii, cu scopul de a determina adecvarea proceselor
unei alte organizatii pentru un anumit contract sau clasă de contracte.
CadruI pentru evaluarea proceselor propus in SPICE este destinat:
➢ facilitării autoevaluării

➢ oferirii unei baze pentru utilizarea în imbunătătirea procesului şi determinarea

capacitătii
➢ să tină seama de contextul în care este implementat procesul evaluat,

➢ să producă un rating de proces,

➢ abordării capacitătii procesului de a-şi atinge scopul

➢ utilizării in toate domeniile de aplicatii ale organizatiei

➢ să ofere şansa unui punct de referintă obiectiv între organizatii.

Fig. 1.7, Process assessment relationship

SPICE, maturitate, calitate

• Relatia dintre SPICE, maturitatea procesului si calitatea produselor software este
indirectă si
> prezinta caracteristici precum cele indicate atunci cand a fost discutata CMM /
CMMI.
• Maturitatea i eficienta proceselor existente intr-o organizatie care dezvoltă SI
> genereaza un fundament important pentru calitatea produsului,
10
 ✓ dar influenta se termină aici.
Calitatea: sarcina inginerilor software
• Restul trebuie facut de ingenerii software care stiu
sa inglobeze calitatea in ceea ce urmeaza sa produca.
1.3.3 SWEBOK

Scopul SWEB OK
• Scopul Guide to Software Engineering Body of Knowledge (SWEBOK) este
 de a oferi o caracterizare validata consensual a limitelor disciplinei ingineria software si de
a furniza un acces la corpul cunoasterii (Body of Knowledge) care susutine aceasta
disciplina
• Editia 2004 a Body of Knowledge este impartota in 10 domenii de cunostinte (KA) si
 descrierile KA sunt cencepute pentru a distinge diferitele concepte importante, permitand
cititorilor sa isi gaseasca rapid drumul spre subiectele de interes

SQA = Software Quality Assurance

V&V = Verification & Validation

• Printre aceste 10 domenii ale cunoasterii, un loc distinctiv are KA dedicat caliatii software
• La fel ca toate celelalte KA din SWEBOK, subiectul caliatatii software-ului este defalcat
si apoi discutat in subiecte individuale grupate in 4 sectiuni:
1. Concepte de calitate software (SQC)
2. Scopul si planificarea SQA si V&V (P&P)
3. Activitati si tehnici pentru SQA si V&V (A&T)
4. Alte teste SQA si V&V (OT).

• Deoarece continutul Software Quality KA din SWEBOK este destul de voluminos, nu

poste fi discutat in intregime in a cest capitol.
• In Software Quality Concepts, ghidul discută problemele
 legate de identificarea și gestionarea costurilor legate de calitate (si, indirect, de
lipsa acestuia) si modelarea calitati
 subliniaza importanta calitatii in contextul sigurantei in functionarea SI
 subliniaza exisenta unuor perspectove de calitate, altele decat perspectivele
clasice percepute prin lentilele seriei de standardele ISO/IEC 9126.
Topici din SWEBOK
• Purpose and Planning of SQA and V&V analizeaza planificarea si obiectivele
asigurgraii calitatii software (SQA) si a proceselor de verificare si validare (V&V) in
contextul a ce este, cand si cum trebuie atinsa calitatea.
• Activities and Techniques for SQA and V&V abordeaza aspectele practice ale
executiei SQA si V &V prezentand printre altele tehnicile statice si dinamice
Topici din SWEBOK

11
• Measurement Applied to SQA and V&V prezinta notiunile de baza ale teoriei si
practicilor de masurare in contextul mgsurarii soft-ului si a calitatii soft-ului.
• Observatie: Ultima versiune SWEBOK este v3.0 din 2014.

CAP. 2 CONCRETIZAREA STANDARDELOR DE CALITATE IN SI

• Realizarea calitatii intr-un context industrial real
> necesită cunostinte organizate, obtinute fie
1. prin ani de experientă practică fie
2. prin procesul educational.
• Aceste cunostinte, pentru a fi complete, ar trebui să cuprinda
> abordări practice pentru ingineria calitătii soft-ului,
1. incepând cu conceptele de bază necesare, apoi
2. cu cerintele, proiectarea, implementarea si V&V,
3. terminand cu deciziile manageriale referitoare la intregul proces

2.1CONCEPTE DE BAZA ALE CALITATII SI

întrebari
• In Sec. 1.1.1, cand am discutat despre calitatea Si in lumea reală am pus
urmatoarele două intrebari:
> Cine, intre utilizator si furnizor, ar trebui să fie expert, mai ales pe un concept
atat de dificil de definit ca cel de calitate?
> Nu ar trebui ca furnizorui să fie cel care solicită, identifică si defineste
atributeie de calitate necesare prin dialog cu utilizatorul si apoi dezvoltă un SI care
sa le inglobeze
Ignoranta
• Printre numeroasele rationamente la aceste Intrebari, unul se pare ca este de o
importanta deosebita:
> conceptele de baza ale calitătii software sunt relativ necunoscute in comunitatea
utilizatorilor IT 51,
> ceea ce este mult mai rău, uneori sunt,necunoscute sau neglijate de atre
comunitatea dezvoltatorilor SI.
2.1.1 INGINERIA CALITATII SOFTWARE: NATURA SI DEFINITIE
12
 Inginerul: problema + rezolvare
• Un proces ingineresc poate fi in esenta exprimat in termeni
> de problema si rezolvare a acesteia.
• Cu alte cuvinte, un inginer este o persoana avizata, care
➢ prin educatie sustinuta de experienta,

➢ este capabil sã inteleaga (i.e. investigheze, identifice si descompune) o

problema si
✓ sä furnizeze o solutie care sa o rezolve.
• A fi un inginer inseamna a fi un rezolvitor de probleme

Inginerul: un mod de gandire

• A fi inginer inseamna altceva:
>"un inginer nu este nici profesie, nici cariera, este un mod de gandire".
• Aceasta observatie utilizata in practica zilnica,
> diferentiaza creatorii de cei care repeta.
Definitia ingineriei
• Ingineria este profesia in care
> o cunoanere a niintelor matematice natu rale,
✓ dobandita prin studiu, experien;a i practica,
> este aplicata cu ratiune

13
 ✓ pentru a dezvolta modalitati de a utiliza, economic, materialele fortele
naturii
> in beneficiul omenirii.
Definitia ingineriei software
• La o scara mai mica, definitia ingineriei software a fost propusa in standardul IEEE
610.12 [3]:
(1) Aplicarea unei abordari sistematice, disciplinate si cuantificabile pentru
dezvoltarea, operarea intretinerea soft-ului,
(2) Studiul abordarilor ca in (1).
Definitia ingineriei calitajii software
• Definitia ingineriei calitatii software [4]:
(1) Aplicarea unei abordari continue, sistematice, disciplinate si cuantificabile
pentru dezvoltarea si mentinerea calitatii pe parcursul intregului ciclu de viata at
produselor si sistemelor software,
(2) Studiul abordarilor ca in (1).
2.1.2 OBIECTELE INGINERIEI CALITATII SOFTWARE
Obiect al ingineriei calitalii soft
• Ce este exact un obiect al ingineriei calitatii software in secolul 21?
> Este o colectie de linii de cod care ar trebui sa faca ceva si ar trebui sa o faca
corect?
➢ Sau poate o colectie de module software care, atunci cand sunt conectate
impreuna, pot furniza un serviciu?
• Daca mergem mai departe, se poate presupune ca caljtatea ar trebui sa se aplice si
structurilor software mari, din multe parti, dar asta este totul unde este limita?
Soft-ul
• Pentru a raspunde la aceasta intrebare, trebuie sä Intrebam si altceva:
> Ce reprezinta produsul soft real care trebuie sä fie acceptat de utilizator?
> Software-ul este:
(1) instructiuni (programe de calculator) care, atunci cand sunt executate,
asigura functia si performantele dorite,

14
 (2) structurile de date care permit programelor sa manipuleze in mod
adecvat informatiile si
(3) documente care descriu operatiunile si utilizarea programelor.
Valabilitatea definitiei
• In sec. 21, aceasta definitie este Inca valabila, dar nu suficient de cuprinzatoare,
deoarece nu contine
> toata bogatia produselor dezvoltate, aplicatiile lor reale si asteptarile
utilizatorilor lor.
• Produsele soft contemporane variaza de la
> soft standard (off-the-shelf OTS) la
> sisteme globale sofisticate,
✓ aplicatiile acestora variind de la prelucrarea textului la controlul
zborului spatial, iar
> utilizatorii lor pot reprezenta indivizi sau organizatii gigant.
Completitudinea sistemului
• Notiunea care corespunde mai bine acestei realitati este sistem.
• Sistemul poate fi foarte complex sau nu, dar contine
➢ atat elemente tehnice,
> cat non-tehnice (Fig. 2.2),
✓ care ofera completitudinea a ceea ce este necesar si trebuie livrat unui
client pentru a fi satisfacut.

15
 Sistemul informatic (SI)
• Un SI poate fi definit ca:
> O colecTie de componente soft aranjate functional, artefacte, resurse servicii
conexe
✓ care sunt organizate pentru a realiza un scop predefinit prin procesarea
informatilion
• Un sistem este o combinatie de software (Cu toata complexitatea sa intrinseca) si
elementele suplimentare solicitate de utilizator pentru a-si executa sarcinile in mod
efectiv si eficient oferind satisfactie utilizatorului.
Ce este satisfactia clientului?
• Va fi utilizatorul multumit de produsul care are o multitudine de functionalitati, dar
din tend in and se blocheaza, se restarteaza necontrolat pierzand datele utilizatorului?
• Va felicita utilizatorul pe furnizor dace sistemul este robust, dar rateaza jumatate din
functionalitatile solicitate?
• Furnizorul va fi platit in totalitate daca sistemul este furnizat fara documentatie si
instruire adecvata?
Client satisfacut
• Orice dintre aceste cazuri va duce la un client serios nemultumit si la posibilitatea
de a pierde piata.
• Singura situatie care poate crea un client pe deplin satisfacut este atunci cand
➢ sistemul prezinta serviciile solicitate,

✓ completate cu o calitate corespunzatoare

➢ insotite de o documentatie buna completa, de un service profesional si de

instruire.
Perspectivele calitalii SI
• Pentru a identifica obiectele ingineriei calitatii software,
> trebuie definite perspectivele din care poate fi perceputa calitatea SI.
• ISO 9126-1:2001 si inlocuitorul sau: ISO/IEC 25010:2011, propun 3 puncte de
vedere distincte care corespund celor 3 categorii de parti interesate:
ISO/IEC 25010: perspectivele calitatii

16
➢ Calitatea interna reprezinta perspectiva dezvoltatorului si a intretinatorului (mai
tarziu in ciclul de viata al unui SI)
➢ Calitatea extena reprezinta perspectiva intretinatorului, operatorului si, in parte, a
utilizatorului final (in ceea ce priveste utilizabilitatea acestuia)
➢ Calitatea in utilizare reprezinta perspectiva utilizatorului final.
Fazele procesului de dezvoltare
• Aceste perspective pot fi legate de fazele unui model generic al procesului de
dezvoltare:
➢ Calitatea interna este cruciala in faza de constructie
> Calitatea externa joaca cel mai mare rol in proiectare si mai tarziu, de la
faza de testare a sistemelor pana la scoaterea din functiune a sistemului
> Calitatea in utilizare trebuie sã fie respectata in faza de definire a cerintelor
apoi din faza de testare a sistemului pana la scoaterea din functiune a sistemului..
Obiectul ingineriei calitatii software

• Luand in considerare toate aceste aspecte, se poate spune ca obiectul real

al ingineriei calitatii software-ului este
> un Si cu toate componentele sale,
✓ dar care este supus unei inginerii de calitate adecvata si cerut5 de faza actual
a ciclului sat, de viata care
❖ corespunde perspectivelor partilor interesate care participa la aceasta etapa.

2.1.3 MODELE DE CALITATE

Rolul modelelor de calitate
• Modelele de calitate prezinta o abordare care imbina diferite atribute de
calitate cu objective de bazd pentru:
> a ajuta la intelegerea modului in care mai multe fatete de calitate contribuie
la intreg
➢ a evidentia: calitatea soft este mult mai mult deck simple defectiuni caderi
> a ajuta la identificarea definirea cerintelor de calitate
17
 Rolul modelelor de calitate
➢ a ajuta la navigarea pe harta caracteristicilor de
calitate, a sub-caracteristicilor si a metricilor
corespunzatoare (formule si sari de masurare)
➢ a ajuta la definirea unui profil de evaluare (exact ce trebuie evaluat).
• Ingineria calitatii soft solicits o gestionare formalci a pe intreaga
durată de viata SI.
Gestionarea formals a calitatii
• Pentru a Indeplini aceasta cerinta, un model de calitate ar trebui sa aiba
capacitatea de a sustine
➢ atat definirea cerintelor de calitate, cat si ➢ evaluarea ulterioara a acestora.
• Acest lucru poate fi explicat prin referire la perspectiva de fabricatie a
calitatii, care prevede
➢ "calitatea este conform5 cu cerintele".
Standardul IEEE 1061-1998
• Un model de calitate care trebuie utilizat in definirea cerintelor de
calitate ar trebui sa contribuie
➢ atat la specificarea cerintelor de calitate, ➢ cat si la evaluarea calit5tii SI.
• Standardul IEEE 1061-1998 [8] defineste aceasta ca o a bordare a
calitatii
➢ de sus in jos

➢ de jos in sus:
Perspectiva top to bottom
➢ Din perspectiva de sus in jos, cadrul calitatii faciliteaza:
 stabilirea de catre clienti managerii la inceputul ciclului de viata al SI a
factorilor asociati cerintelor de calitate
 comunicarea personalului tehnic a factorilor de calitate stabiliti, sub
forma subfactorilor de calitate
 identificarea metricilor legate de factorii de calitate stabiliti de subfacto

18
 Perspectiva bottom to top
➢ Din perspectiva de jos in sus, cadrul calitatii permite personalului
managerial si tehnic să obtină feedback prin:
 evaluarea produselor software si a proceselor la nivel de metrici
 analizarea valorilor metricilor pentru estimarea si evaluarea factorilor de
calitate.
Modele de calitate generice

 Inca de la Inceputul anilor 1970, au existat incercari continue de a crea

> un model de calitate valabil,

acceptat pe scars larga.

 Exists propuneri de modele de calitate generice, personaliza bile (e.g. GEQUAMO [9]),

> care permit oricarei parti interesate sa iii construiasca propriul model

in functie de cerinte.

Discutii asupra modelelor de calitate
• Un sondaj [10] printre practicieni (Marea Britanie, Grecia, Egipt, Cipru)
a indicat importanta data caracteristicilor de calitate ale produselor, rezultand
propuneri de imbunatatire a modelelor de calitate existente cum ar fi
> adaugarea a doua not caracteristici ale extensibilitatii si securitatii modelului
de calitate ISO/IEC 9126.
• Exista insa dezacorduri/opinii diferite atat in printre cercetatori, cat si in
industrie
➢ cu privire la calitatea software-ului.
Scopul unui model de calitate
• Scopul unui model de calitate este, in esenta,
➢ de a oferi o definitie operationala a calitatii.
• Desi au fost stabilite definitii specifice anumitor contexte,
> nu exists un consens in ceea ce priveste calitatea, in sensul general, in
ingineria software.
• Din perspectiva ingineriei calitatii soft-ului, pentru ca un model de
calitate sä fie util, ar trebui:

19
 sa suporte cele 5 perspective ale calitatii definite de Kitchenham & Pfleeger
[11] (vezi Sect. 1.1)
> sa poata fi utilizat top to bottom, asa cum este definit de standardul IEEE
1061-1998 [8], adica sa permita definirea cerintelor de calitate ;i
 descompunerea lor ulterioara in caracteristici de
calitate, sub-caracteristici si metrici adecvate
➢ sa poata fi utilizat bottom to top, a;a cum este definit de standardul IEEE
1061-1998 [8], adica sa permita masuratorile necesare si apoi agregarea si evaluarea
rezultatelor obtinute.
Modele dezvoltate
• Mai multe modele de calitate au fort dezvoltate in ultimul timp,
>unele fiind recunoscute in mare parte de comunitatea
➢altele obtinand si recunoaStere In cadrul industriei.
• Cele mai cunoscute modele, prezentate in continuare, sunt:
> McCall ➢ Dromey
 Boehm > ISO/IEC 9126 silSO/IEC 25010

20