CFSS C06 Is1+sc1

Universitatea de Vest din Timişoara
Facultatea de Matematică şi Informatică
CALITATEA ŞI FIABILITATEA SISTEMELOR

SOFTWARE
L06 – Calitate & Fiabilitate
Dr. Ştefan IOVAN
Consultant în Informatică
FIABILITATEA
SISTEMELOR
SOFTWARE
Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 2

FIABILITATEA SISTEMELOR SOFTWARE
 Defectări ale produselor software
 Fiabilitatea specifică software
 Fiabilitatea factorului uman
 Metrici ce descriu fiabilitatea software
 Fiabilitatea sistemelor complexe

5. Defectări în produsele software
• Un sistem bine proiectat, corect realizat, minuţios verificat, judicios
utilizat nu ar trebui să prezinte defectări în funcţi-onare.
• Experienţa a arătat totuşi că şi cele mai bune sisteme în condiţiile
celei mai corecte exploatări nu exclud în întregime posibilitatea
apariţiei unor defecte în funcţionare.
• Defectul se poate defini ca o anomalie în funcţionarea corec-tă a
unui sistem.
sistem
• Încetarea capacităţii unui sistem de a îndeplini funcţia spe-cificată
(proiectată) poartă denumirea de cădere sau defec-tare.tare
• Defectarea poate să însemne că cel puţin una din perfor-manţele
sistemului a ieşit din limitele specificate.
specificate
• Performanţele sistemului sunt relevante faţă de o anume aplicaţie,
iar a ţine seama de toate performanţele sistemu-lui, chiar pentru un
sistem simplu, este extrem de dificil.

• Defectarea poate fi rezultatul unui proces continuu de vari-aţie a
performanţelor sistemului sau al modificării bruşte a valorii unei
performanţe,
performanţe starea de defectare aflându-se într-un raport de
continuitate sau discontinuitate faţă de starea de bună funcţionare a
sistemului.
• Indiferent de modul de variaţie al performanţelor sistemu-lui,
defectarea este un proces aleator.
aleator
• Toate modelele matematice ale fiabilităţii sunt de tip stohastic,
stohastic
astfel încât previziunea comportării viitoare a unui sistem,
sistem bazată pe
cunoasterea evoluţiei sale din trecut şi a structurii sale, poate fi
făcută numai pe baza teoriilor specifice probabilităţilor, cu un
anumit nivel de încredere, cu un nivel acceptat de incertitudine.
incertitudine
• Cauzele care pot determina defectarea pot fi datorate proiec-tării,
fabricaţiei şi/sau utilizării sistemului.

• Defectarea este provocată prin depăşirea unor stări limită,
limită care se
manifestă sub forma ruperii unei componente, apari-ţiei unui
scurtcircuit sau erori în program etc., mecanismul defectării putând
fi de natură fizică, chimică sau de altă natură.
• Există printre specialişti şi opinia conform căreia nu orice mică
defecţiune constituie o defectare,
defectare întrucât există defec-ţiuni care nu
împiedică îndeplinirea funcţiilor de bază ale produsului.
• Fiabilitatea software reprezintă probabilitatea ca software-ul să nu
producă defectarea unui sistem care utilizează cal-culatorul într-un
anumit interval de timp şi în condiţii spe-cificate.
• Este legată de abilitatea softului de a rula cum şi când este necesar
în momentul integrării în sistem.

• Defectarea softului nu este similară cu cea a hardului,
hardului este un
eveniment cauzat de pierderea abilităţii de realizare a unei funcţii
soft în limitele specificate şi se defineşte ca ma-nifestarea unui
defect în soft care poate împiedica realizarea performanţei cerute,
face să se obţină rezultate neaşteptate în funcţionarea acestuia,
discrepanţe între valorile obţinute şi cele specificate sau corecte din
punct de vedere teoretic.
• Defectările softului apar în mod aleatoriu în operarea siste-mului şi
pot surveni oricând în timpul ciclului de viaţă al sistemului.
• Atunci când apar sunt sistematice şi au caracteristici simi-lare.
lare Un
defect soft reprezintă incapacitatea unui soft de a opera din cauza
erorilor.
erorilor
• Un defect soft rămâne latent până când este activat în anu-mite
circumstanţe de funcţionare şi în mod normal devine inactiv când
aceste circumstanţe nu mai există.

• Un defect soft poate cauza defectarea sistemului.
sistemului
• Eroarea soft este o este de obicei produsă de acţiunea greşită a unui
programator în timpul codificării sau de interpreta-rea greşită de
către programator a cerinţelor specificaţiei soft, traducerea
incorectă (compilarea) în limbajele specifice sau omiteri ale
cerinţelor în specificaţia de proiectare.
proiectare
• În mod uzual se foloseşte termenul de eroare atât pentru o acţiune
greşită cât şi pentru manifestarea greşelii în pro-gram.
• Referitor la fiabilitatea software (a programelor), pre-ocupările au
fost direcţionate spre elaborarea unor progra-me cât mai bune, care
să nu conţină erori,
erori excluzând posibi-lităţile ca un program foarte
bun să se defecteze în tipul ci-clului de viaţă, să apară erori noi în
timpul utilizării unui anumit software.
• Pe parcursul acestui curs pentru software vom folosi frec-vent
termenul soft.

• În domeniul programelor defectarea constă în punerea în evidenţă a
unei erori latente conţinute în program şi care nu se datorează
uzurii.
• Datorită faptului că o anumită configuraţie de date, care pune în
evidenţă eroarea, apare după un interval de timp aleator de testare
sau utilizare, defectările software-ului pot fi tratate ca evenimente
aleatoare,
aleatoare care se produc de-a lun-gul unui interval de timp.
• În cazul programelor defectarea reprezintă manifestarea unei erori
prezente în program şi care este detectată prin:
- mesaje de eroare de execuţie;
- o durată de execuţie nefinită a programului;
- obţinerea unui rezultat clar eronat,
eronat în afara domeniu-
lui.
• S-a demonstrat că în timp, chiar într-un program foarte bun,
elaborat la firme mari se specialişti recunoscuţi şi mi-nuţios
verificate au apărut defecte.

• Prognoza defectării unui program este afectată de două sur-se de
incertitudine:
- variabilitatea datelor de intrare şi lipsa unei anumite
legi de succesiune a acestora;
acestora
- variabilitatea programelor care pot implementa o ace-
easi funcţie, respectiv variabilitatea raţionamentelor pentru
rezolvarea unei probleme.
• Elementele esenţiale în definirea defectării software,
software con-form
IEEE (ANSI) 982.2 din 1988 sunt: eroarea (error), ne-regula (fault,
bug), defectul (defect) şi defectarea sau căde-rea (failure).
• Monitorizarea funcţionării unui sistem de calcul implică atât partea
software cât şi partea hardware, operatorul uman si mediul de
lucru.
lucru
• Deseori, interacţiunile dintre aceste părţi pot conduce la de-fectări
chiar în absenţa unor defecte localizabile în vreuna dintre ele.

• De aceea, este important să se ia în considerare ansamblul om-
maşină,
ină format din hardware (HW), software (SW) şi personalul
utilizator, factorul uman (FU).
• Defectarea sistemului se poate produce din cauza unor mal-
funcţionări ale software-ului chiar dacă acesta nu conţine defecte
dar este utilizat necorespunzător.
necorespunzător
• O variantă de clasificare a defectelor software este urmă-toarea:
a) defecte ale specificaţiilor:
specificaţiilor
- date incomplete sau inconsistente;
- defecte de interfaţă între hard, soft şi utilizator;
b) defecte ale proiectului:
proiectului
- descriere incorectă;
incorectă
- definirea incompletă a datelor;
- interpretarea gresită a cerinţelor;
- control logic sau descriere logică incompletă;
incompletă

- lipsă de comunicare;
comunicare
- proceduri incomplete de identificare a posibilelor erori;
- aplicarea de standarde ieşite din uz.
uz
c) defecte de programare, de codare:
codare
- de logică;
- computaţionale;
- de prelucrare;
- de interfaţă;
- de comentariu;
comentariu
d) defecte inserate la compilare:
compilare
- compilare incorectă,
- interfeţe neadecvate;
neadecvate
e) defecte de documentare:
documentare
- defecte în documentele care însoţesc produsul software.
f) defecte introduse în timpul mentenanţei:
- corectare cu apariţia unei alte erori
• Din punct de vedere cantitativ se consideră două tipuri de erori în
execuţia unui program:
- eroarea de discriminare,
discriminare prin care o anumită valoare
de intrare este prelucrată pe o altă cale;
- eroare de omisiune,
omisiune prin care o valoare de intrare este
prelucrată în mod inadecvat pe una din căile
existente, în program nefiind prevăzută o cale
pentru prelucrarea corectă.

6. Fiabilitatea specifică software
Fiabilitatea software este o caracteristică de calitate im-portantă
pentru că:
- de ea depinde numărul rulărilor în care se obţin
rezultate complete şi corecte;
- permite abordări particulare în elaborarea
modelelor de estimare cu luarea în considerare a faptului
că produsele software nu au uzură fizică şi că odată cu
eliminarea cauzelor care generează întreruperea execuţiei
e posibilă obţinerea creşterii fiabilităţii;
- nivelul acestei caracteristici determină întreaga
abordare în realizarea unui produs software şi antrenează
consumuri şi costuri ce depind strict de modalităţile concrete
luate în considerare pentru creşterea nivelului fiabilităţii
uneia sau alteia dintre componentele produsului.

Fiabilitatea, notată Fiab a unui program se măsoară prin
indicatorul:
IFiab = rsucces / rtotal
unde:
rsucces - numărul rulărilor de succes ale progra-
mului, în care s-au obţinut rezultate
complete şi corecte;
rtotal - numărul total al rulărilor programului
considerat.
În timp au fost elaborate numeroase modele pentru studierea
fiabilităţii software pornind de la modelele existente în
energetică în general şi în energetica nucleară în special.

• Modelul de fiabilitate include variaţia de complexi-tate
pentru a reflecta dinamica programului la fie-care
moment, sau de la semnalarea unei erori până are loc
corectarea ei.
Evoluţia procesului de producere a erorilor de prelu-crare
este marcată de calitatea corectării,
corectării de modul în care s-a
identificat cauza şi de aria de cuprinde-re a elementelor
din program implicate în depista-rea cauzei.
Pentru fiabilitatea software este dedicată o bogată literatură
cu descriere de modele, cursul de faţă fiind orientat pe
utilizarea de metode statistice, accentuează pregătirea
seriilor de date necesare unora dintre modelele de
fiabilitate software.

Fiabilitatea Sistemelor Software
7. Fiabilitatea factorului uman
• Fiabilitatea umană se poate defini ca probabilitatea realiză-rii cu
succes de către om a unei activităţi sau sarcini în orice stadiu de
operare a sistemului, într-o limită de timp specifi-cată.
• Pornind de la premisa că studiul fiabilităţii se realizează utilizând
procese stohastice în care decizia factorului uman este subiectivă,
este aboslut obligatoriu să se ţină seama de factorul uman în
validarea rezultatelor obţinute.
• Teoria deciziilor reale este o ramură a psihologiei care stu-diază
comportarea persoanelor reale în situaţii ideale.
ideale
• Nu interesează modul real de luare a deciziilor reale de că-tre
persoane reale, ci modul raţional în care ar acţiona un subiect
idealizat.
• Prima condiţie de raţionalitate este coerenţa strictă,
strictă respec-tiv
repartiţia apriori considerată să acopere toate valorile adevărate
ale parametrului, adică tuturor valorilor adevă-rate ale
parametrului să li se asocieze o probabilitate apri-ori, astfel încât
toate deciziile privind acest parametru să nu fie eronate.

• A doua condiţie este condiţia de simetrie,
simetrie respectiv pentru aceleasi
informaţii prelucrate de analisti diferiţi să rezulte repartiţii apriori
identice, reducând la minimum subiecti-vitatea analistului.
• A treia condiţie se referă la modul de combinare a informa-ţiilor
apriori cu rezultatele experimentale,
experimentale respectiv la faptul că numai
rezultatele experimentale să influenţeze decizia analistului.
• Pentru activitatea de tip continuu, timpul mediu până la eroarea
umană - MTHE (Mean Time to Human Error), poa-te fi estimat pe
baza unei relaţii, unde: h(τ) este rata erorii umane iar τ este timpul.
• Rata erorii umane se poate determina experimental şi poate fi
constantă sau poate avea o distribuţie exponenţială, Weibull,
normală, gama, Poisson etc.

• Factorul uman intervine la toate fazele de dezvoltare a unui sistem
fie că este mecanic, electric, tehnic, social sau softwa-re, în toate
etapele ciclului de viaţă ale sistemului: la nivelul identificării
cerinţelor, conceperea şi proiectarea lui, realiza-re şi testare în
exploatare precum şi la culegerea datelor din exploatare sau
încercări, în vederea studierii şi îmbunătăţi-rii fiabilităţii sistemului.
• Concluziile specialiştilor spun că aproximativ 40% dintre defecţiuni
sunt datorate direct erorilor umane,
umane iar pentru echipamente
complexe (CNE, aerospaţial) cota ajunge la 70-80%.
• O parte din erorile umane sunt datorate concepţiei, fabrica-ţiei sau
instalării la locul de expolatare al sistemului.
• O serie din aceste erori pot fi corectate în diferite etape ale
controlului de calitate, la verificările intermediare şi finale, în
timpul încercărilor de punere în funcţiune precum şi în prima
perioadă de funcţionare a sistemelor.

• În exploatare, cele mai multe şi importante erori se datorea-ză
personalului.
• Erorile umane pot fi grupate în două mari categorii: erori tehnice şi
erori psihologice.
psihologice Nu ne von referi la erorile intro-duse cu rea
voinţă.
a) Erori tehnice pot fi în concepere si proiectare, exploatare, încercări
sau mentenanţă.
Erorile umane în faza de concepere/proiectare pot fi:
- neînţelegeri ale cerinţelor:
- comunicare incorectă între specialiştii implicaţi;
- descrieri incompete sau incorecte etc.
Erorile umane în exploatare pot fi:
- manevre greşite în urma unor indicaţii greşit aplicate sau
neaplicate,
neaplicate unor informaţii greşit intercepate sau unor fenomene rău
înţelese;
- alarme neglijate sau greşit interpretate ca fiind o de-fectare
a sistemului de alarmă;

- transmitere greşită de consemne între persoane;
persoane
- utilizarea de consemne incomplete sau perimate;
perimate
• Erori umane în timpul încercărilor periodice
- încercări periodice neefectuate sau greşit efectuate,
efectuate ero-ri
de etalonare şi reglaj;
- utilizarea de proceduri de încercare incomplete sau pe-
rimate;
rimate
- neglijarea sau uitarea de a efectua anumite operaţii,
operaţii care
fac ca sistemul să se afle la finele încercării într-o stare diferită de
cea prevăzută.
• Erori umane în timpul operaţiilor de mentenanţă
- proceduri de întreţinere nerespectate;
nerespectate
- utilizarea de proceduri incomplete sau perimate;
perimate
- neglijarea sau uitarea de a efectua anumite operaţii care
fac ca la sfârsitul operaţiei de mentenanţă sistemul să nu fie în
starea prevăzută.

b) Erori psihologice. Erorile psihologice ale operatorului uman se pot
clasifica în: erori de omisiune (de memorie, de atenţie) şi erori
pasive (de identificare, de interpretare, de operare).
• Erori de omisiune pot proveni de la oboseală şi de la lipsa de
antrenament profesional.
profesional
• Memoria poate fi ajutată prin instrucţiuni de lucru scrise şi afişate
la locuri vizibile, indicarea de nivele limită, condiţii critice.
• Atenţia poate fi ajutată de diferite forme de afisare, inclusiv prin
utilizarea culorilor de cod, a semnalelor auditive sau a oricăror alte
semnale.
• Există tendinţa de a reduce dimensiunile şi numărul de aparate de
pe panouri si din camerele de comandă si de a utiliza ecrane
concentratoare.

• Erorile pasive pot fi:
a) Erori de identificare care depind atât de concepţie cât şi
de utilizator sau operator.
operator Testarea psihologică a operato-rului unui
sistem complex este absolut necesară. Identifica-rea poate fi ajutată
prin divizarea voită a panourilor de co-mandă, astfel ca grupuri de
aparate, lămpi de semnalizare, butoane care deservesc o zonă sau
asigură o anumită funcţi-onalitate să poată fi grupate
corespunzător. Schemele mne-nomice servesc şi ele acest scop.
b) Erori de interpretare au loc prin înţelegerea greşită de
către operator a unor informaţii afişate sau a unor inscri-pţii (scale,
denumiri etc.) şi în consecinţă prin acţionarea într-un mod
impropriu. Culoarea diferită a unor inscripţii, marcarea specială a
unor descriptori alfa-numerici, ilumi-narea unor informaţii scrise
ajută la evitarea unor astfel de erori.

c) Erori de operare sunt cele la care mişcarea cu rol de
control (reglaj) este improprie în raport cu efectul dorit ca-uzele
sunt similare cu cele de mai sus, consecinţele pot fi foarte grave.
• În vederea diminuării efectului factorului uman în scăderea
fiabilităţii se impun o serie de acţiuni, respectiv măsuri pen-tru
proiectarea şi construcţia sistemelor care implică:
- efectuare a secvenţelor operaţionale în mod cât mai fa-cil,cil
uneori prin realizarea unor modele asociative mental ca-re să
câştige atenţia operatorului;
- eliminarea necesităţii de a interpreta o informaţie afi-şată
sau scrisă;
scrisă
- mişcările şi eforturile psihice să fie gândite cât mai er-
gonomic.
gonomic
• Pentru a preîntâmpina rezistenţa pasivă a personalului se impune:
- crearea unei atmosfere plăcute de lucru şi de cooperare

- stabilirea unui scop comun, recunoscut şi acceptat;
acceptat
- elaborarea de sarcini şi responsabilităţi specifice;
specifice
- urmărirea modului în care progresează îndeplinirea
scopului propus.
propus
• Comportamentele umane se pot ameliora prin obţinerea de
satisfacţii morale şi materiale prin analize de comporta-ment şi
eficienţă, prin selecţia personalului (inclusiv prin chestionare de
angajare, probe de lucru, teste psihologice sau alte metode).
• Principalele mijloace disponibile pentru a minimiza frecven-ţa
erorilor umane sunt:
- luarea în considerare a operatorului uman încă din fa-za
de concepţie;
- punerea la punct a unor reguli de utilizare şi întreţine-re
care să reducă dificultăţile de interpretare şi de aplicare (livrarea
sistemului împreună cu instrucţiuni de instalare şi utilizare);

- controlul calităţii în toate fazele (de proiectare, instala-re,
exploatare, scoatere din uz), existenţa instrucţiunilor de lucru la
locul efectuării operaţiei, afişarea regulilor de urmat;
- instruirea permanentă a personalului angajat;
angajat
- îmbunătăţirea continuă a nivelului instruirii ;
- îmbunătăţirea a mediului de lucru.
lucru
• În realizarea unei analize a fiabilităţii umane (HRA-Hu-man
HRA
Reliability Analysis) se ţine seama că omul operează asupra
entităţilor calitative şi realizează estimări posibile (comportament
de tip fuzzy):
fuzzy
- integrarea tehnologiilor noi în sisteme complexe deter-
mină ca datele experimentale asupra fiabilităţii sistemului să fie
insuficiente, caz în care se apelează la date previzio-nale de
fiabilitate.
- operatorii sistemelor complexe sunt instruiţi şi educaţi la
un nivel ridicat.
ridicat

- mare parte din criteriile de decizie sunt calitative,
calitative cu scală
diferită de la un caz la altul şi nu pot fi comparate direct.
• Există numeroase preocupări pentru un management inteli-gent şi
analiză a fiabilităţii umane din perspectiva implică-rii consiente şi
responsabile a personalului în exploatarea sistemelor, limitarea
acţiunilor care pot genera erori şi defectări.

8. Metrici ce descriu fiabilitatea software
• Metricii soft sunt caracteristici unui sistem soft ce pot fi mă-surate şi
cuantificate ce permit determinarea cantitativă a valorii unui
anumite performanţe a softului.
• Ei pot fi obţinuţi prin măsurare directă sau prin deducţie şi pot fi
cuantificaţi.
cuantificaţi
• In mod uzual pentru a măsura performanţa şi a evalua fia-bilitatea
sistemului soft sunt folosiţi următorii metrici:
- Densitatea de defecte reprezintă numărul de defecte
conţinute pe o mie de linii ale codului sursă (KSLOC Kilo
Source Lines of Code)
- Acoperirea codului este un indicator al rigurozităţii
testării softului, oferă o măsură a gradului în care codul
sursă al unui program soft a fost testat sistematic.
Indică procentul de defecte detectate în timpul testării
execuţiei codului;
- Rata de înlăturare a defectelor reprezintă numărul de
defecte detectate şi corectate în soft într-o perioadă de timp
determinată sau pe durata executării softului; permite stabilirea
tendinţelor de îmbunătăţire ale softului.
- Defectele reziduale din soft reprezintă numărul esti-
mat de defecte latente care au rămas în soft după testarea şi
înlăturarea defectelor sesizate.
- Timpul pentru lansarea softului reprezintă timpul es-
timat pentru graficul de lansare. Este bazat pe criteriile stabilite
pentru nivelul de acceptare al defectelor latente rămase în soft.
- Complexitatea softului oferă o măsură a gradului de
dificultate pentru proiectarea şi implementarea unei funcţii
soft sau sistem soft; alte măsuri bazate pe con- ceptul de
complexitate sunt complexitatea soft-ului, complexitatea
funcţională, complexitatea operaţională; metricii legaţi de
complexitate sunt utilizaţi ca date de intrare pentru evaluarea
fiabilităţii şi modele de previ-ziune.

• Standardele de specialitate noi recomandă şi alţi metrici pentru a fi
utilizaţi.
• In funcţie de modul de colectare,
colectare în timpul ciclului de viaţă al
softului, metricii soft pot fi grupaţi în trei categorii prin-cipale:
metricii despre defecte,
defecte metricii despre produsul soft,
soft şi metrici
despre procesul de realizare a softului
i) Metricii despre defecte colectează datele de raportare a problemei
soft pentru a măsura impactul defectelor şi efici-enţa procesului de
raportare a apariţiei defectelor. Se referă la:
a) Probleme de raportare a datelor
- Data şi momentul la care a fost detectat defectul
- Descrierea defectului detectat
- Defectul detectat în zona programului
- Persoana care a detectat defectul
- Simptomul defectului şi statutul
- Severitatea şi prioritatea

• Datele colectate din proiectele soft vor fi folosite pentru ra-portarea
problemelor de identificare.
b) Acţiuni corective
- Data corectării defectului
- Persoana care a corectat defectul
- Acţiunile de mentenanţă efectuate
- Descrierea modificării
- Identificarea modulelor modificate
- Timpul necesar pentru corectarea defectului
- Data verificării corectării defectului
- Persoana care a verificat corecţia
c) Defecte cumulate detectate şi corectate utilizate pentru
cunoaşterea defectelor care necesită acţiuni corective şi
urmărirea efectivităţii acţiunilor de corectare
e) Rata de detectare a defectelor
f) Rata de corectare a defectelor pentru a stabili priori-
tăţile pentru acţiunile de mentenanţă

g) Defecte pe locaţie pentru identificare a ariei specifice a
codului este se manifestă mai multee eroare.
h) Criticitatea defectelor,
defectelor număr şi procent de defecte
severe
i) Complexitatea structurală şi funcţională pe locaţie.
• ii) Metricii despre proces colectează informaţiile despre procesul de
realizare a softului şi condiţiilele funcţionale la momentul detectării
şi înlăturării defectului. Se referă la:
a) Număr şi procent de module care realizează mai mult
decât o funcţie:
ie Este un indicator al coeziunii folosit pentru
calcululul complexităţii
b) Număr şi procent de module care au o structură foar-
te complexă se urmăreste reducerea lor prin reproiectare pentru a
reduce complexitatea
c) Număr şi procent de module care au exact o intrare şi o
ieşire:
ire Indică un proiectului coeziv ce poate fi utilizat ca bază
pentru dezvoltarea softului;

d) Număr şi procent de module care sunt documentate
în concordanţă cu standardele utilizat pentru a determina dacă
codul conţine toate cerinţele.
e) Număr şi procent de defecte care sunt găsite în codul
refolosit este un indicator al non-fiabilităţii codului re- utilizat.
• iii) Metricii despre produs colectează informaţiile despre produsul
soft clasificând după mărime, funcţionalitate, complexitate, locaţia
utilizatorului şi alte caracteristici pen-tru a facilita utilizarea
datelor colectate experimental ca da-te de intrare în scopul
dezvoltării de noi produse:
- Defecte introduse în ciclul de viaţă indică când şi în ce
stadiu au fost introduse defectele pentru a adopta măsu- rile
adecvate
- Defecte detectate în ciclul de viaţă indică când şi în ce
stadiu au fost detectate defectele şi justifică întârzierile
acţiunilor corective pentru eliminarea defectelor.

- Timpul total consumat în analiză indică timpul nece-
sar de analiză pentru identificarea problemelor şi izolarea lor
pentru acţiunile corective precum şi resursele consumate
- Timpul total consumat în proiectare inclusiv resursele
consumate.
- Timpul total consumat în codificare inclusiv resursele
consumate.
- Timpul total consumat în testarea unităţii inclusiv re-
sursele consumate
- Timpul total consumat în testarea sistemului.
sistemului Indică
timpul consumat de testarea sistemului şi resursele consumate.
- Timpul total de mentenanţă. Indică inclusiv resursele
consumate.
- Timpul mediu de mentenanţă – administrare.
administrare Indică
timpul înainte şi după corectarea defectului, inclusiv timpul
petrecut cu asigurarea personalului de mente- nanţă, scoaterea
în evidenţă a corecţiilor într-o versiune nouă.

- Timpul mediu de acţiuni corective inclusiv resursele
consumate care indică costul activităţilor de mentenan- ţă.
- Motivul acţiunii corective pentru a descoperi sursa de-
fectelor.
fectelor Motive tipice sunt:
- acţiuni de mentenanţă trecute
- cerinţe noi
- schimbări de cerinţe
- cerinţe interpretate greşit
- cerinţe lipsă
- cerinţe ambigue
- schimbări în mediul soft
- schimbări în mediul hard
- erori de cod/logice
- erori de performanţă.
- Costul acţiunilor corective inclusiv pentru izolarea de-
fectelor, rezolvarea problemei şi pentru acţiuni de men- tenanţă
propriu-zise.

- Procentul de funcţii testate şi verificate. Indică acope-
rirea testelor, eficienţa testelor şi integralitatea.
- Procentul de căi independente testate şi verificate.
verificate In-
dică acoperirea testelor structurale şi integralitatea
- Procentul de linii sursă ale codului testat şi verificat.
verificat
Indică acoperirea testărilor codului soft şi integralitatea
- Date despre istoricul familiei de softuri dezvoltate în
timp pentru a identifica problemele de proiectare, proces şi
producţie.
• Colectarea de metrici este necesară pentru a determina ten-dinţele
în fiabilitate, frecvenţa şi timpul necesare pentru mentenanţa
softului,
softului timpul de răspuns pentru apelurile de serviciu, refacerea
performanţelor degradate şi cerinţele pen-tru suportul de
mentenanţă.
• Cantitatea şi tipurile de metrici trebuie să fie relativ simplu de
colectat, uşor de interpretat pentru analizare şi folositoa-re pentru
evaluarea, îmbunătăţirea şi creşterea fiabilităţii softului.

9. Fiabilitatea sistemelor complexe
• Problemele privind fiabilitatea software sunt asemănătoare din mai
multe puncte de vedere pentru orice sistem tehnic.
tehnic
• Din acest motiv, pentru produsele complexe vom utiliza ter-menul
generalizator de "sisteme tehnice" sau numai "siste-me”. me”
• Un sistem are bine definite intrările şi ieşirile. In categoria
sistemelor tehnice intră inclusiv sistemele hardware, sisteme
software şi componente electronice.
electronice
• Sistemele de software au câteva particularităţi,
particularităţi de aceea anumite
aspecte specifice numai fiabilităţii software vor fi tratate într-un
capitol separat din acest curs.
• Prin sistem înţelegem (in contextul acestui curs) un ansam-blu de
elemente legate funcţional între ele care realizează o anumită
funcţie tehnică concretă.
concretă
• Prin element vom inţelege o parte componentă a sistemului.
sistemului

• Pentru studii de fiabilitate un sistem se poate diviza într-un număr
de elemente componente, în funcţie de necesităţile de calcul,
calcul
divizare efectuată astfel încât pentru fiecare element să se poată
identifica funcţia pe care o realizează în cadrul sistemului şi defini
intrările şi ieşirile.
irile
• Această divizare are un caracter convenţional pentru că ele-mentele
componente ale unui sistem, o dată precizate, pot fi din nou divizate
în elemente de rangul al doilea s.a.m.d.
• In mod curent, elementele sistemului se numesc "subansam-ble",
"blocuri", "unităţi" "module", diviziunea de rangul cel mai mic fiind
"componenta" sau "linia de cod" pentru soft-ware.
• Buna funcţionare a produsului complex este rezultanta funcţionării
corecte a tuturor subansamblelor componente.
• La rândul lor subansamblele se compun din blocuri, module s.a.m.d.
până când procesul de divizare identifică compo-nentele, elementele
de legătură, reperele şi toate celelalte ele-mente, care determină
funcţionarea corectă şi fiabilitatea sistemului.

• Prin fiabilitate previzională se înţelege fiabilitatea ex-primată prin
indicatori de fiabilitate care au rezultat din calcule de prognoză
efectuate pe baza datelor de fiabilitate ale tuturor elementelor
componente.
• Fiabilitatea sistemului depinde de fiabilitatea tuturor ele-mentelor
componente (sau subsistemelor), de legăturile cau-zale stabilite
între ele şi de mediul în care funcţionează.
• Dacă un element se defectează, funcţionarea sistemului este afectată
total sau parţial şi pot apare următoarele situaţii:
- defectarea are un caracter minor, sistemul continuă
să funcţioneze (ex. O lampă de semnalizare);
- defectarea are un caracter major dacă întreaga func-
ţionare a sistemului este afectată (ex. defectarea totală a unor
subsisteme componente);
- o defectare are un caracter major iar funcţiile subsiste-
mului respectiv pot fi suplinite de un subsistem identic, aflat în
rezervă (redundanţă).

Funcţiile respective pot preluate de sistemul redundant
până la terminarea acţiunii de reparare. Vom reveni asupra
redundanţei.
• Pentru studiul fiabilităţii unui sistem este necesar să se de-finească
vectorul de intrare U = ( u1, u2 ... , un), vectorul de ieşire Y = ( y1,
y2, ... ,yp ) şi vectorul de stare S = ( s1, s2, ... , sm) prin intermediul
cărora se manifestă influenţa variabilelor de intrare asupra celor de
ieşire, propriu fiecă-rui sistem.
• Toţi aceşti vectori fiind mărimi fizice aleatoare.
aleatoare
• Considerând că dependenţa parametrilor componentelor de
solicitare se exprimă prin indicatorii de fiabilitate şi funcţi-ile de
distribuţie specifice se realizează calculul indicatori-lor de
fiabilitate ai sistemelor pornind de la indicatorii de fiabilitate ai
componentelor,
componentelor elaborând astfel modele struc-turale.

• Analiza structurală a fiabilităţii are drept scop stabilirea unei relaţii
între funcţia de fiabilitate a sistemului şi func-ţiile de fiabilitate ale
elementelor componente.
componente
• Analiza este precedată de o evaluare realistă a funcţiilor de
fiabilitate individuale ale elementelor componente {Rj, j = 1, 2, ...,
n}, care trebuie să ţină seama de criteriile de defectare reale,
impuse de structura sistemului şi de definirea corectă a defecţiunii
elementelor si sistemului.
• Dacă se cunosc caracteristicile de fiabilitate ale elementelor
constituente (determinate experimental în prealabil şi stoca-te într-o
bancă de date, prezentate în cataloage sau existente în tabele) şi
dacă se ţine seama de rolul şi solicitarea acesto-ra în sistem, se pot
estima caracteristicile de fiabilitate ale sistemelor, utilizand modele
structurale adecvate,
adecvate arbori de defectare sau de funcţionare, analiză
pe baza lanţurilor Markov sau alte modele specifice.

Mulţumesc pentru atenţie!
VĂ MULŢUMESC,
PENTRU CĂ POT SĂ MĂ SIMT
UTIL PRINTRE VOI, ÎN ACEASTĂ
ORGANIZAŢIE...

CFSS C06 Is1+sc1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CFSS C06 Is1+sc1

Încărcat de

Drepturi de autor:

Formate disponibile

Universitatea de Vest din Timişoara

Facultatea de Matematică şi Informatică

CALITATEA ŞI FIABILITATEA SISTEMELOR

L06 – Calitate & Fiabilitate

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 2

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 3

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 4

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 5

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 6

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 7

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 8

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 9

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 10

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 11

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 13

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 14

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 15

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 16

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 17

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 18

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 19

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 20

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 21

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 22

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 23

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 24

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 25

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 26

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 27

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 29

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 30

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 31

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 32

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 33

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 34

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 35

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 36

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 37

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 38

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 39

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 40

Calitate & Fiabilitate Dr. Stefan IOVAN - 2023 41

S-ar putea să vă placă și