UNIUNEA EUROPEANĂ GUVERNUL ROMÂNIEI Fondul Social European Instrumente Structurale OIPOSDRU UNIVERSITATEA

MINISTERUL MUNCII, PSD DRU 2007 - 2013 2007 - 2013 TEHNICĂ DE

FAMILIEI ŞI CONSTRUCŢII DIN
PROTECTIEI SOCIALE BUCUREŞTI
AMPOSDRU

Investeşte în oameni !
Proiect cofinanţat din FONDUL SOCIAL EUROPEAN
prin Programul Operaţional Sectorial Dezvoltarea Resurselor Umane 2007 – 2013
Axa prioritară 1: „EDUCAŢIA ŞI FORMAREA PROFESIONALĂ ÎN SPRIJINUL CREŞTERII ECONOMICE ŞI DEZVOLTĂRII SOCIETĂŢII
BAZATE PE CUNOAŞTERE”
Domeniul major de intervenţie 1.2 „Calitate în învăţământul superior”
Cerere de propuneri
prop neri de proiecte: nr.
nr 86 „Universitate
Uni ersitate pentru
pentr viitor”
iitor”
Titlul proiectului: Reţea naţională de centre pentru dezvoltarea programelor de studii cu rute flexibile şi a unor instrumente didactice la specializarea de licenţă
şi masterat, din domeniul Ingineria Sistemelor
Numărul de identificare al contractului: POSDRU/86/1.2/S/63806

Gabriela Varvara
Ingineria Programarii I

Curs 5-6
Cerinte software
Procesul de inginerie a cerintelor

Partener P4

MINISTERUL EDUCAŢIEI, UNIVERSITATEA UNIVERSITATEA TEHNICĂ UNIVERSITATEA TEHNICĂ UNIVERSITATEA SC ASTI AUTOMATION SRL
CERCETĂRII, TINERETULUI ”POLITEHNICA” DIN ”GHEORGHE ASACHI” ”POLITEHNICA”
ŞI SPORTULUI DIN CLUJ-NAPOCA DIN DIN
BUCUREŞTI IAŞI TIMIŞOARA

Agenda curs

Obiective :
Obiectivul 1:definirea conceptelor de cerinta utilizator, respectiv cerinta software.
Obiectivul 2:definirea si explificarea notiunilor de cerinta functionala, respectiv nefunctionala.
Obiectivul 3: explicarea modalitatilor de organizare a cerintelor software in documentul de
cerinte.
Obiectivul 4:descrierea principalelor activitati din cadrul procesului de inginerie a cerintelor,
precum si a legaturilor dintre acestea.
Obiectivul 5:prezentarea tehnicilor de identificare si analiza a cerintelor.
Obiectivul 6:prezentarea modalitatilor de validare a cerintelor; procesul de review pentru cerinte.
Obiectivul 7:definirea elementelor de management a cerintelor; rolul activitatilor de management
in cadrul procesului de inginerie a cerintelor
cerintelor.

Subiecte tratate: Partea I - definirea cerintelor functionale si nefunctionale, cerinte utilizator,

cerinte sistem, specificatii ale interfetei, documentul de cerinte software. Partea a II a: studii de
fezabilitate, identificare si analiza cerinte, validarea si managementul cerintelor.

Page 1
 Ce este o cerinta?

Orice este cuprins intre o specificatie functionala detaliata analitic si un enunt abstract
pentru un serviciu/constrangere sistem

Aceasta definitie este o consecinta directa a functiei duale a cerintelor:

Baza juridica pentru un proces de licitatie – din acest motiv trebuie sa fie deschis
pentru interpretare
Baza juridica pentru un contract formal – trebuie sa fie definit in detaliu
Daca o companie doreste sa contracteze un proiect software va trebui sa isi defineasca
nevoile intr-o maniera suficient de abstracta pentru a se crea premizele primirii mai
multor oferte cu solutii alternative. Odata atribuit un contract, firma contractoare va
trebui sa defineasca sistemul mult mai detaliat, astfel incat clientul sa poata intelege si
valida proiectul ce urmeaza a fi dezvoltat.
Ambele documente poarta denumirea de “document cu cerinte ale sistemului”.

Ingineria cerintelor

Reprezinta procesul de stabilire a serviciilor pe care clientul le solicita

proiectului software precum si constrangerile in care acesta va fi dezvoltat
si/sau va opera.

Cerintele reprezinta descrieri ale serviciilor sistem precum si constrangerile ce

vor fi generate in cadrul procesului de inginerie a cerintelor.

Page 2
 Cerinte utilizator/sistem

Cerinte utilizator – sunt formate din documente textuale scrise in limbaj

natural si diagrame ale serviciilor furnizate de catre sistemul dezvoltat
precum si din constrangeri operationale.

Cerinte sistem – sunt reprezentate printr-un document structurat ce prezinta

functiile, serviciile si constrangerile operationale. El poarta denumirea de
Document de specificare a cerintelor sistem. Ultimativ, acesta defineste ce
trebuie implementat si poate reprezenta parte dintr-un contract intre client si
contractor.

Cerinte utilizator/sistem - exemplu

Definitia unei cerinte utilizator:

1. Sistemul trebuie sa permita accesul si reprezentarea fisierelor externe
create cu alte utilitare

Specificatia software aferenta cerintei utilizator:

1.1 utilizatorul trebuie sa furnizeze facilitatile de definire a fisierelor externe
1.2 fiecare tip de fisier extern are asociat un utilitar ce ii poate fi aplicat
1.3 fiecare tip de utilitar extern poate fi reprezentat printr-o pictograma
specifica pe ecranul utilizatorului
1 4 facilitatile oferite de pictograme vor fi definite de catre utilizator
1.4
1.5 cand utilizatorul selecteaza o pictograma ce reprezinta un tip de fisier
extern, efectul va fi de aplicare a utilitarului asociat acelui tip fisierului
reprezentat prin pictograma

Page 3
 Cine acceseaza cerintele?

Cerinte utilizator – managementul client, utilizatori finali sistem, ingineri client,

managementul firmei IT contractoare, arhitecti sistem

Cerinte software - utilizatori finali sistem, ingineri client, arhitecti sistem,

programatori

Specificatia de proiectare software - ingineri client (posibil), arhitecti sistem,

programatori

Cerinte functionale/nefunctionale
Cerinte functionale:
enunta serviciile furnizate de sistem, modul de reactie pentru intrari particulare,
comportamentul in situatii specifice
Depind de tipul produsului software si a sistemului in care acesta va fi folosit si de
asteptarile utilizatorilor
Daca cerintele functionale ale utilizatorilor pot fi enunturi generale referitoare ce ar
trebui sa faca produsul, specificatiile de cerinte functionale ale sistemului trebuie sa
furnizeze o descriere detaliata a serviciilor ce vor trebui implementate
Cerinte nefunctionale:
Enunta constrangerile la care sunt supuse serviciile /functiile produsului; pot fi
temporale, referitoare la procesul de dezvoltare, standarde, cuplare cu sisteme
externe, etc.
Cerinte din domeniul aplicatiei
Reflecta specificul domeniului de aplicare a produsului

Page 4
 Cerinte functionale - exemplu
Se doreste dezvoltarea unui sistem de interfatare cu articolele stiintifice
memorate in bazele de date din diferite biblioteci. Utilizatorul poate accesa
aceste articole in vederea descarcarii pe masina proprie/ listarii acestora.
Cerinte functionale posibile:
Utilizatorul trebuie sa poata cauta in toate bazele de date de documentare
sau doar in subseturi selectate de utilizator
Sistemul trebuie sa prevada mecanisme adecvate de tip viewer pentru
documentele citite din bazele de date de documentare
Fiecare ordin al utilizatorului trebuie sa fie identificat printr-un cod unic
(ID_ORDIN) pe care utilizatorul sa il poata copia in zona de memorare
aferenta contului sau
Mentionarea intr-o maniera ambigua a cerintelor poate duce la interpretarea
diferita a acestora la nivelul utilizator/proiectant:
Ex. Termenul “mecanisme
mecanisme adecvate de tip viewer”
viewer poate fi interpretat:
La nivel utilizator – viewer aferent tipului de document (.doc, .pdf, .txt)
La nivel proiectant – furnizarea unui viewer text pentru afisarea continutului
documentelor
Cerintele trebuie sa fie, in principiu, complete si consistente (fara conflicte/contradictii intre
facilitatile descrise), deziderat greu de realizat in practica.

Cerinte nefunctionale

Refera proprietati ale sistemului de tip constrangere (limitari ale dispozitivelor

I/E, ale sistemelor externe cu care produsul interactioneaza, impunere CASE
pentru dezvoltare, platforma/limbaj imlementare, metoda de dezvoltare),
performanta (timp, executie concurentiala), fiabilitate, uzabilitate (refera
proprietati legate de conlucrarea utilizator-aplicatie), maintenabilitate,
portabilitate etc
portabilitate, etc.
Pot fi:
Cerinte legate de produs – specifica modul particular in care se
comporta produsul (viteza executie, fiabilitate, etc.)
Cerinte organizationale – sunt o consecinta a politicilor, procedurilor si
standardelor folosite in firma IT
Cerinte externe – refera probleme de tip interoperabilitate, cerinte
legislative etc.
legislative, etc

Cerintele nefunctionale pot fi mai critice decat cerintele functionale;

neindeplinirea lor face sistemul de neutilizat.

10

Page 5
 Tipuri de cerinte nefunctionale (dupa Ian Sommerville)

11

Cerinte nefunctionale - exemple

Cerinte de produs: interfata aplicatiei de acces la baze de date pentru

documentare trebuie sa fie implementata in cod HTML, fara cadre sau applete
Java

Cerinte organizationale: procesul de dezvoltare al produsului si documentele

livrate clientului trebuie sa se conformeze standardelor XYZCo-SP-STAN-95.

Cerinte externe: sistemul nu trebuie sa permita celor ce opereaza cu el

accesul la informatiile personale ale clientilor, cu exceptia numelui si codului
de identificare.

Conflictele pe cerintele nefunctionale sunt uzuale pentru sistemele complexe

(ex. Pentru un sistem software pentru un avion vor trebui indeplinite conditii
externe de tipul implementare multi-procesor cu numar redus de procesoare
pentru minimizarea greutatii, respectiv folosire de procesoare de consum
redus, deci implicit in numar mare.)

12

Page 6
 Legatura dintre scopurile utilizator si cerintele nefunctionale

In multe situatii practice cerintele nefunctionale nu pot fi formulate cu precizie si, drept
consecinta nu pot fi verificate.
O cerinta nefunctionala verificabila este o afirmatie ce poate fi testata cu ajutorul unei
anumite masuri.
Prin scop utilizator intelegem o intentie generala a utilizatorului legata de usurinta
interactiunii cu produsul dezvoltat.

Ex.
Scop sistem: sistemul de ghidaj al zborurilor dintr-un aeroport trebuie sa fie usor de
folosit de controlerii cu experianta si organizat in asa fel incat erorile utilizator sa fie
minimizate.
Cerinta nefunctionala verificabila: controlerii cu experienta sa poata utiliza toate
p doua ore de antrenament. Dupa
functionalitatile dupa p acest proces,
p controlerii
antrenati nu trebuie sa aiba, in medie, mai mult de 2 erori/zi.)

13

Elemente de masura pentru cerinte nefunctionale

Cerinta Masura
viteza numar tranzactii procesate/sec

timp raspuns utilizator/eveniment

timp refresh ecran
marime Mbytes
numar chip-uri ROM
usurinta in utilizare timp antrenare
numar de cadre help
fiabilitate timp mediu pana la cadere
probabilitatea de a fi nedisponibil
frecventa de aparitie a caderilor
disponibilitatea
robustetea timp repornire dupa cadere
procentul de evenimente ce provoaca caderea
probabilitatea de corupere a datelor dupa cadere
portabilitatea procentul de afirmatii dependente de o tinta
numarul sistemelor tinta

14

Page 7
 Cerinte de domeniu

Provin din domeniul de aplicare al solutiei software (descrie acele caracteristici

ale sistemului ce reflecta domeniul)
Sunt concretizate prin noi cerinte functionale, constrangeri asupra cerintelor
existente sau definesc moduri de procesare specifice.
Daca cerintele
D i t l de
d domeniu
d i nu suntt satisfacute
ti f t s-ar putea
t ca sistemul
i t l sa nu
poata lucra

Ex. Pentru aplicatia de interfatare cu bazele de date pentru documentare:

Interfata utilizator cu toate bazele de date trebuie sa se conformeze
standardului Z39.50
Datorita unor restrictii de copyright, unele documente trebuie sterse
imediat dupa descarcare. Depinzand de cerintele utilizatorului, aceste
d
documente t vor fi ti
tiparite
it pe serverull llocall iin vederea
d uneii trimiteri
t i it i
ulterioare catre masina utilizator sau trimise spre tiparire pe imprimanta
de retea.

15

Probleme ale cerintelor de domeniu

Gradul de intelegere:
Aceste cerinte sunt exprimate in limbajul domeniului de aplicare ce nu
este intotdeauna inteles p p de catre echipa
pe deplin p de dezvoltare

Caracterul implicit al exprimarii:

Specialistii din domeniu cunosc atat de bine aria de aplicare incat nu
considera necesar sa expliciteze cerintele de domeniu.

16

Page 8
 Cerinte utilizator
Trebuie sa acopere cerinte functionale si nefunctionale formulate
astfel incat sa fie intelese de utilizatorii finali ce nu au cunostinte
tehnice avansate

Sunt definite prin intermediul limbajului natural, tabele si diagrame

in masura in care acestea sunt pe deplin intelese de catre toti
utilizatorii

Probleme in folosirea limbajului natural:

Lipsa claritate – formulari ad-hoc ce cresc dificultatea de a intelege documentul
Confuzie pe cerinte – exista tendinta de a amesteca cerinte functionale cu nefunctionale
Amestec de cerinte – cerinte de tipuri diferite sunt adesea exprimate impreuna, in aceeasi
fraza
fraza.
Ambiguitate – cititorii/redactorii documentului de cerinte trebuie sa interpreteze aceleasi
cuvinte in acelasi mod
Supra-flexibil – acelasi lucru poate fi exprimat diferit in locuri diferite in acelasi document
Absenta modularitatii – limbajul natural este inadecvat in structurarea cerintelor sistemului

17

Alternative la limbajul natural

Limbajul natural structurat – are la baza folosirea de formulare si sabloane

pentru specificarea cerintelor
Limbaje de descriere a proiectarii – au la baza folosirea limbajelor asemanatoare
j
cu limbajele p g
de programare p
cu caracteristici suplimentare g
legate de
abstractizare; specifica cerintele sistemului prin definirea unui model operational
al acestuia. Actualmente aceasta metoda nu este des folosita, desi este extrem
de utila in crearea specificatiilor pentru interfete.
Notatii grafice – folosirea unui limbaj grafic caruia i se aduga adnotari textuale
poate fi folosit pentru specificarea cerintelor functionale ( ex.UML)
Specificatii matematice – au la baza concepte matematice cum ar fi masina de
stari finite sau notiunea de set. Reprezinta o maniera lipsita de ambiguitate in
specificarea cerintelor functionale. Au drept dezavantaj faptul ca multi clienti nu
inteleg specificatiile formale si tind sa nu le accepte in redactarea unui contract
formal.

18
Course 6: Software requirements

Page 9
 Specificatii prin limbaj natural structurat
Impune limitarea libertatii de formulare intr-un limbaj natural prin folosirea
unor sabloane predefinite pentru specificarea cerintelor
Toate cerintele au o formulare standard in cadrul sablonului
Recurge la o terminologie de descriere limitata
A avantajul
Are t j l ca impune
i un anumit
it grad
d de
d uniformitate
if it t formularilor
f l il
Exista 2 sabloane folosite pe scara larga:
formularul de specificare a cerintelor ce contine:
Definitia functiei/entitatii
Descriere intrari si specificare sursa intrari
Indicarea altor entitati cerute
Specificare pre/post conditii (daca este cazul)
Efecte colaterale ale functiei/entitatii ( daca exista)
Formularul de specificare a cerintelor ( vezi slide-ul urmator)

19

Formular specificare noduri

Pompa de insulina / Software control /SRS/ 3.3.2

¾Functie: calcul doza insulina – nivel glucoza sigur
¾Descriere: calculeaza doza de insulina ce va fi livrata atunci cand nivelul de glucoza masurat este in zona
sigura intre 3 si 7 unitati
t a nivel
¾Intrari: e ccitiri
t cu curente
e te g
glucoza
uco a ((r2),
), ccitiri
t a anterioare
te oa e ((r0
0 ssi r1))
¾Sursa: citire curenta de la senzor si alte valori adaugate din memorie
¾Iesiri: doza calculata (CompDose) de insulina ce va fi livrata
¾Destinatie: bucla de control main
¾Actiune: CompDose va fi 0 daca nivelul glucozei este stabil sau in descrestere, sau daca nivelul este in
crestere, dar rata de crestere este in descrestere. Daca nivelul creste cu o rata in crestere, CompDose se va
calcula prin impartirea diferentei dintre valoarea curenta glucozei si cea precedenta la 4, cu rotunjirea
rezultatului. Daca rezultatul este rotunjit la 0 se va livra doza minima de insulina ce poate fi furnizata
¾Cerinte: doua citiri anterioare p
pentru a p
putea calcula rata de modificare a nivelului g
glucozei in sange
g
¾Preconditii: rezervorul de insulina contine macar o doza unica maxim admisa
¾Postconditie: r0 este inlocuit de r1, apoi r1 este inlocuit de r2
¾Efecte colaterale: nu exista

20

Page 10
 Specificatii de tip tabelar

Sunt folosite pentru a completa specificatiile in limbaj natural

Sunt utile atunci cand se cer definite mai multe alternative posibile de derulare
a actiunii entitatii specificate

Conditie Actiune
Nivel insulina in descrestere (r2<r1) CompDose=0
Nivel insulina stabil (r2=r1) CompDose=0
Nivel ins. In crestere si rata crestere in descrestere
((r2-r1)<(r1-r0)) CompDose=0
Nivel insulina in crestere si rata de crestere este stabila sau in crestere
CompDose =round ((r2-r1)/4)
((r2 r1)/4)
daca rezultat rotunjit =0
CompDose=MinimumDose

21

Notatii grafice

utile in specificarea secventelor de actiuni sau a modificarilor de stare

22

Page 11
 Limbaje pentru descrierea proiectarii pentru specificarea interfetelor
Majoritatea sistemelor trebuie sa opereze impreuna cu alte sisteme prin intermediul unor
interfete operationale
Orice interfata este definita pe 3 nivele:
Interfata procedurala
Structuri de date transferate pe interfata
Reprezentari de date
Folosirea modelelor formale este o tehnica extrem de utila in specificarea cerintelor de
interfatare:

23

Ghid de redactare a cerintelor

Trebuie g
gasit/inventat un format standard pentru
p specificarea
p cerintelor
Limbajul de descriere trebuie folosit intr-o maniera consistenta. Se prefera
folosirea lui “trebuie” pentru cerinte obligatorii si “este de dorit” pentru cele ce
se doresc a fi implementate
Identificarea partilor cheie a cerintelor prin text accentuat/subliniat
Evitarea folosirii jargoanelor IT

24

Page 12
 Cerinte sistem versus cerinte utilizator

Cerintele sistem:
Spre deosebire ce cerintele utilizator, realizeaza descrierea
functiilor/serviciilor produsului, precum si a constrangerilor cu un grad de
detaliere mai mare
Reprezinta punctul de start in proiectarea produsului
Pot fi incluse intr-un contract formal
Definesc ce ar trebui sa faca produsul; faza de proiectare va descrie cum se
realizeaza functionalitatile
In practica, cerintele nu pot fi separate de proiectare:
Arhitectura sistemului va permite structurarea cerintele
Sistemul p
poate inter-opera
p cu alte sisteme ce isi impun
p cerintele in faza
de proiectare
Folosirea unui stil de proiectare specific este, in fond, o cerinta de
domeniu

25

Documentul cu specificatiile sistem – Software Requirement Specification (SRS)

Este un document oficial ce specifica ce se cere de la dezvoltatorii produsului

Include atat definitiile cerintelor utilizator cat si specificatiile de sistem
Nu este un document de proiectare, el descriind ce trebuie sa faca produsul si nu cum trebuie sa fie
implementate dezideratele.
Standardul IEEE 830-1998 specifica continutul si elementele de asigurare a calitatii pentru
documentul de specificare a cerintelor software
software.
Ca structura generala acest document are urmatoarele parti:
Introducere
Glosar de termeni
Difinitiile cerintelor utilizator
Arhitectura sistem
Specificarea cerintelor de sistem
Modele sistem
Evolutia sistemului
Anexe
Index

26

Page 13
 Utilizatorii documentului de cerinte

Clientii produsului – specifica cerintele utilizator si le citesc pentru a verifica daca

acestea corespund
p propriilor
p p nevoi.
Managerii – folosesc documentul de cerinte pentru a planifica caietul de sarcini in
vederea licitarii implementarii si/sau pentru a planifica procesul de dezvoltare al
produsului.
Inginerii de sistem – folosesc cerintele pentru a intelege natura sistemului ce urmeaza a
fi dezvoltat.
Echipa de testare a sistemului – folosesc cerintele pentru a dezvolta testele de validare
ale sistemului
Inginerii maintenanta sistem – folosesc cerintele pentru intelegerea sistemului ca intreg
d sii a relatiilor
dar l tiil ce exista
i t intre
i t partile
til sale.
l

27

Procesul de inginerie a cerintelor

Aceste proces are un grad mare de variabilitate in functie de domeniu
Exista, insa, un numar de activitati generice pentru oricare proces vizat:
Extragerea
Analiza cerintelor
Validarea Studiu   Extragere si
fezabilita analiza cerinte
Managementul te
Specificare 
cerinte
Raport Validare cerinte
fezabilitate

Modele 
sistem

Cerinte utilizator
si sistem

Document cerinte 

28

Page 14
 Ingineria cerintelor – detalii proces
Specificare
cerinte

Specificare si modelare 
cerinte sistem

Specificare cerinte utilizatori

Specificare cerinte businesss

Extragere cerinte sistem
Studiu fezabilitate
Extragere cerinte
utilizator
Prototipizare

Extragere  cerinte
Review‐uri Validare
cerinte

Document cerinte sistem

29

Studiul de fezabilitate
Stabileste daca proiectul merita sa fie dezvoltat
Este un studiu de dimensiuni reduse focalizat pe:
Gradul de contributie al sistemului la obiectivele organizationale
Stabilirea masurii in care sistemul poate fi construit inginereste folosind tehnologia actuala cu
incadrarea in buget
Stabilirea masurii in care sistemul poate fi integrat cu alte sisteme aflate in uz
Elaborarea unui studiu de fezabilitate se va baza pe evaluarea informatiei (ce se cere a fi construit),
gruparea informatiilor redactarea de rapoarte.
Vor trebui oferite raspunsuri la urmatoarele intrebari:
Ce se va intampla daca sistemul nu va fi implementat?
Care sunt problemele proceselor actuale?
Cum va ajuta sistemul propus in rezolvarea problemelor?
Care sunt problemele de integrare?
Este necesara tehnologia de ultima generatie? Ce anume?
Ce facilitati trebuie sa aiba sistemul propus?

30

Page 15
 Extragerea si analiza cerintelor

Implica activitati derulate de personal cu expertiza tehnica. Uneori poarta denumirea de

descoperire a cerintelor
Implica lucrul personalului tehnic cu clientii in identificarea domeniului in care va fi
dezvoltata aplicatia, serviciile pe care va trebui sa le furnizeze si constrangerile
operationale.
Implica discutii cu utilizatorii finali
finali, manageri,
manageri ingineri intretinere
intretinere, experti din domeniu,
domeniu
organizatii specifice (toti numiti generic sustinatori ai proiectului - stakeholders).

Probleme ce pot aparea in procesul de analiza a cerintelor

Sustinatorii nu stiu precis ce isi doresc.
Sustinatorii exprima cerintele in terminologie proprie.
Sustinatori diferiti pot introduce cerinte contradictorii.
Factori organizationali si politici influenteaza cerintele.
cerintele
Cerintele se schimba pe perioada procesului de analiza; pot aparea noi sustinatori,
mediul de business poate evolua.

31

Spirala cerintelor

Requirements
q Requirements
q
classification and prioritization and
organisation negotiation

Requirements Requirements
discovery documentation

32

Page 16
 Activitati ale procesului de inginerie a cerintelor

Extragere/descoperire cerinte
Interactiunea cu sustinatorii pentru descoperirea cerintelor. Cerintele din domeniu sunt
descoperite tot in aceasta faza.
Clasificarea si organizarea cerintelor
Gruparea cerintelor asemanatoare si organizarea acestora pe grupuri coerente.
Prioritizare si negociere
Prioritizarea cerintelor si rezolvarea conflictelor pe cerinte.
Documentarea cerintelor
Cerintele sunt puse in documente formale si se intra pe urmatorul ciclu al spiralei.

33

Descoperirea cerintelor
Procesul de obtinere a informatiilor (din specificatii ale sustinatorilor sistemului,
din specificatii ale sistemelor similare, din documentatie) despre sistemul
propus si cele similare existente si extragerea cerintelor utilizator si sistem din
aceste informatii.
Interviul – metoda de dialog informal/formal prin care echipa de inginerie a
cerintelor formuleaza intrebari sustinatorilor despre structura/modul de utilizare
all produsului
d l i ce urmeaza a fi dezvoltat.
d lt t
Exista 2 tipuri de interviu – inchis ( cu set predefinit de intrebari), deschis (fara o
agenda stabilita, bazat pe un proces de explorare permanenta). In practica
interviurile sunt un mix al celor 2 tipuri mentionate.
Interviul nu este o metoda prin care sa poata fi extrase cerintele ce tin de
domeniu fie datorita neintelegerii domeniului de catre echipa IT, fie datorita
familiaritatii excesive a domeniului – piedica reala in formalizarea si structurarea
acestuia.
Pentru a fi abilitat sa p
preia un interviu,, membrul echipei
p IT trebuie sa nu aiba
prejudecati, sa fie un bun ascultator si o persoana cu vederi largi.

34

Page 17
 Perspective (view)

Reprezinta o modalitate de structurare a cerintelor pentru a grupa perspectivele diferitilor

sustinatori ai proiectului. Totul pleaca chiar de la diferitele perspective din care pot fi vazuti
sustinatorii.
Analiza pluri-perspectiva este importanta desi nu este singura modalitate corecta de analiza a
cerintelor.
Tipuri de puncte de vedere:
De interactiune – identificare sisteme/persoane ce interactioneaza direct cu sistem.
Indirecte- sustinatori ce nu folosesc direct sistemul, dar pot influenta cerintele (ex.
management, inginerii de sistem responsabili cu securitatea aplicatiei)
Puncte de vedere specifice domeniului - reprezinta caracteristici si restrictii ce influenteaza
cerintele.
Identificarea punctelor de vedere se realizeaza prin consultarea:
Furnizorilor si beneficiarilor serviciilor sistemului
Reglementari si standarde
Surse de cerinte business si nefunctionale
Ingineri implicati in dezvoltarea si intretinerea sistemului
Alti sustinatori din zona marketing, etc.

35

Scenarii

Sunt exemple ale modului in care poate fi utilizat in practica produsul

Un scenariu trebuie sa includa
O descriere a situatiei de pornire;
O descriere a fluxului normal de evenimente;
O descriere a ceea ce ar putea sa mearga eronat;
Informatii despre alte activitati concurente;
O descriere a starii cand scenariul se va sfarsi.
Cazurile de utilizare (use-case) reprezinta tehnica UML bazata pe scenarii ce
identifica actorii dintr-o interactiune, dar descrie si interactiunea insasi.
Setul cazurilor de utilizare trebuie sa descrie toate interactiunile posibile cu
sistemul
Alaturi de diagramele de use-case, diadrame de secvente pot sa ilustreze
suplimentar fluxul de evenimente procesat de sistem

36

Page 18
 Exemple use-case

37

Factori sociali si organizationali ce influenteaza cerintele

Pot influenta toate punctele de vedere

Nu exista o modalitate sistematica de analiza a acestor factori desi o buna
analiza nu ar trebui sa ii excluda
Etnografia = studiul bazat pe experienta trecuta a practicilor prezente
Studiile etnografice au aratat ca lucrul cotidian este mult mai complex decat il
sugereaza modelele sistemului
Etnografia este folosita pentru identificarea acelor cerinte ce deriva :
din modul concret in care lucreaza utilizatorii si nu din fluxurile standard
definite de activitati
Din cooperare si constientizarea altor activitati corelate

38

Page 19
 Validarea cerintelor
Demonstreaza ca cerintele definesc sistemul pe care il doreste clientul
Este o activitate importanta deoarece costul erorilor pe cerinte este mare – eliminarea
unei astfel de erori in faza de livrare a produsului costa de 100 ori mai mult decat
eliminarea unei erori de codificare
Practic, se pot identifica urmatoarele tehnici de validare:
Revizuire cerinte (requirements review) – analiza manuala sistematica a cerintelor
Prototipizarea – folosirea unui model executabil al sistemului
Generarea cazurilor de utilizare – dezvoltarea de teste pentru cerinte; se evalueaza
si testabilitatea cerintelor
Ce se verifica la un sistem:
Validitatea - furnizeasa sistemul acele functii ce acopera nevoile clientului?
Consistenta - exista conflice pe cerinte?
Completitudinea – sunt incluse toate cerintele functionale ale clientului
Realismul – pot cerintele sa fie implementate
Verifiacabilitatea - pot fi verificate cerintele?

39

Revizuirea cerintelor

Revizuirile curente ar trebui facute chiar in momentele in care cerintele sunt

definite
In procesele de review vor fi implicati clienti si dezvoltatori deopotriva
Revizuirile p
pot fi formale (se
( completeaza
p anumite documente)) sau informale. O
buna comunicare intre dezvoltatori, beneficiari si utilizatori poate rezolva
problemele in fazele incipiente ale dezvoltarii
Ce urmaresc verificarile de revizuire:
Verifiacabilitatea – este in mod realist testabila cerinta?
Comprehensibilitatea - este cerinta inteleasa corect?
Trasabilitatea - este originea cerintei statuata clar?
Adaptabilitatea – se poate modifica o cerinta fara un impact major asupra
celorlalte cerinte?

40

Page 20
 Managementul cerintelor

Reprezinta procesul de management al schimbarii cerintelor pe durata proceselor de inginerie

a cerintelor si de dezvoltare a produsului
Cerintele sunt, in mod inevitabil, incomplete si inconsistente
Apar noi cerinte datorate modificarilor de business si aprofundarii gradului de intelegere a
sistemului dezvoltat
Uneori puncte de vedere diferite induc cerinte diferite si contradictorii.

41

Schimbari in cerinte

Pe parcursul dezvoltarii se pot schimba:

Prioritatile cerintelor atribuite unor puncte de vedere diferite
Cerintele ce produc conflicte
Cerintele ce reflecta mediul tehnic si de business ce a evoluat intre timp
Din aceasta perspectiva, cerintele pot fi:
Stabile – nu sufera modificari; deriva din nucleul activitatii derulate in organizatia
client . Adesea sunt identificate din modele ale domeniului.
Volatile – se schimba pe parcursul dezvoltarii sau a utilizarii sistemului.
Clasificarea cerintelor in raport cu schimbarea acestora:
Mutabile – se schimba datorita schimbarii modului de operare in organizatia client
Emergente – apar pe masura ce clientul intelege mai bine sistemul ce va fi dezvoltat
Consecinta – deriva din introducerea tehnologiei IT in organizatia client (procesele din
acea organizatie se schimba)
De compatibilitate: depind de un sistem /proces particular in organizatia client

42

Page 21
 Planificarea in procesul de management al cerintelor
In procesul de inginerie a cerintelor se vor planifica activitati de:
Identificare cerinte – modul de extragere a fiecarei cerinte
Procesul de management al modificarilor – ce activitati vor fi desfasurate cand se
analizeaza o cerere de modificare de cerinta
Politicile de trasabilitate – ce si cate informatii despre relatiile intre cerinte vor trebui
inregistrate si gestionate
Trasabilitatea se ocupa cu relatiile dintre:
cerinte (modeleaza gradul de dependenta intre cerinte),
sursele lor (sustinatori ce au propus acele cerinte) si
proiectarea aplicatiei (legaturile de la o cerinta la componente ale proiectului)
Utilitare CASE folosite – ce medii de dezvoltare vor trebui folosite pentru gestiunea sigura
a:
C i t l (in
Cerintelor (i faza
f d inginerie
de i i i a cerintelor)
i t l )
Modificarilor – stabilirea fluxului de activitati dintr-un proces de schimbare cu
automatizarea anumitor fluxuri de transfer de date
Trasabilitatii – regasirea automata a legaturilor dintre cerinte

43

Un exemplu de matrice de trasabilitate

Req. 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

id
1.1 D R
1.2 D D D
1.3 R R
2.1 R D D
2.2 D
2.3 R D
3.1 R
3.2 R

44

Page 22
 Gestiunea schimbarilor de cerinte
Trebuie aplicate tuturor schimbarilor de cerinte propuse.
Faze principale ale procesului:
Analiza problemei si propunerea schimbarii
Evaluarea costurilor si a efectelor schimbarii asupra celorlalte cerinte
Implementarea schimbarii. Modificarea documentului de cerinte si a altor
documente ce reflecta schimbarea.

problema identificata revizuire 
Analiza  cerinte
Analiza  schimbare 
problema si Implementare 
si evaluare schimbare
specificare  schimbare costuri

45

Specificarea sistemelor critice – obiective

Identificarea cerintelor dependabile prin analiza de risc asupra sistemului critic
Generarea pe baza analizei de risc a cerintelor de siguranta
Deducerea cerintelor de securitate
Metrici folosite in specificarea fiabilitatii

Subiecte tratate
Specificare bazata pe riscuri
Specificatii de siguranta
Specificatii de securitate
Specificatii de fiabilitate software

Page 23
 Cerinte de dependabilitate

Cerinte functionale ce definesc facilitatile de verificare erori si recuperare,

precum si protectia impotriva caderii sistemului

Cerinte nefunctionale ce definesc fiabilitatea si disponibilitatea impuse pentru

sistem

Cerinte de excludere ce definesc starile si conditiile ce nu trebuie sa apara

Specificarea bazata pe risc

Obligatorie pentru sistemele critice

Utilizata pe scara larga pentru sistemele critice din punct de vedere al sigurantei
si securitatii
Scopul – intelegerea riscurilor si definirea cerintelor ce reduc aceste riscuri

Fazele analizei bazate pe riscuri:

Identificare riscuri potentiale
Analiza si clasificare riscuri
Descompunere riscuri – pentru a identifica cauzele primare de producere
Evaluarea reducerii riscurilor – definirea modului de eliminare/reducere risc in
faza de proiectare a sistemului

Identificare Analiza si Descompunere Evaluare

risc clasificare risc risc reducere
risc
Descriere Evaluare Analiza Cerinte
risc risc cauzei dependabilitate
radacina

Page 24
 Identificare riscuri
Pentru sistemele critice din punct de vedere a sigurantei, riscurile sunt acele
elemente de hazard ce pot genera accidente
Pentru sistemele cu securitate critica, riscurile sunt reprezentate prin atacurile
potentiale asupra sistemului.
Identificarea presupune determinarea claselor de riscuri (cadere serviciu, risc
electric etc…)
electric, etc ) si incadrarea fiecarui risc in aceste clase

Exemplul pompei de insulina

Supradoza insulina (esec seviciu)
Subdozare insulina (esec serviciu)
Descarcare baterii alimentare (electric)
Contact imperfect
p la sensor/actuator (fizic)
( )
Rupere ac cateter (fizic)
Infectie produsa prin utilizarea dispozitivului (biologic)
Reactie alergica la materiale/insulina (biologic), etc…

Analiza si clasificarea riscurilor

Se urmareste intelegerea probabilitatii de producere a riscurilor precum si a

consecintelor potentiale ale incidentelor/accidentelor posibil a se produce
Clasificarea riscurilor:
Intolerabile – nu trebuie sa se produca, iar cand se produc in mod cert va
rezulta un accident
La un nivel rezonabil de mic din punct de vedere practic (ALARP) – se vor
minimiza costurile legate de producerea riscurilor ce nu pot fi tolerate ca
atare
Acceptabile – consecintele legate de riscurile de acest tip sunt asumate si nu
se aloca sume suplimentare in vederea reducerii probabilitatii de producere a
riscului

Page 25
 Niveluri ale riscurilor

Regiune neacceptabila
Riscul nu poate fi tolerat

Risc tolerat doar daca reducerea
Risc tolerat doar daca reducerea
Regiune  nu este practica
ALARP sau este prea costisitoare

Regiune acceptabila

Risc neglijabil

Acceptabilitatea la nivel social a riscurilor. Evaluare riscuri

Acceptabilitatea unui risc tine de factori umani, sociali si politici.

In majoritatea societatilor cu trecerea timpului limita intre regiuni este impinsa in sus
deoarece se accepta din ce in ce mai putin producerea riscurilor
De exemplu costurile inlaturarii efectelor poluarii pot fi mai mici decat costurile de prevenire a
acesteia, dar din punct de vedere social acest risc nu poate fi acceptat

Evaluare risc = estimare a probabilitatii de producere a hazardului asociat si a severitatii

Evaluarea riscurilor este un proces guvernat de subiectivism

Riscurile evaluate ca fiind probabile, improbabile, etc. au o clasificare dependenta de
e a ua o
evaluator
Se lucreaza cu valori imprecise de tipul: improbabil, rar, frecvent, foarte mare, etc.

Scopul trebuie sa fie excluderea riscurilor cu probabilitate mare de producere sau care
sunt extrem de severe prin consecinte

Page 26
 Exemplu evaluare risc

hazard identificat probabilitate severitate risc estimat acceptabilitate

hazard hazard
1. Supradoza insulina mediu mare mare intolerabil
2. Subdozare insulina mediu mic mic acceptabil
3. Cadere alimentare mare mic mic acceptabil
4. Dispozitiv fixat gresit mare mare mare intolerabil
5. Cateter rupt la utilizare mic mare mediu ALARP
6. Infectie de la cateter mediu mediu mediu ALARP
7. Interferente electrice mic mare mediu ALARP
8
8. R
Reactie
ti alergica
l i mic
i mic
i mic
i acceptabil
t bil

Descompunere risc
Presupune descoperirea cauzelor primare ale producerii riscurilor intr-un sistem
particular
Tehnicile de lucru au fost preluate, in cea mai mare masura, din analiza
sistemelor critice din punct de vedere al securitatii si pot fi:
Inductive – de jos in sus; incep de la considerarea caderii si evalueaza
hazardurile ce pot sa apara de aici
Deductive – de sus in jos; se porneste cu hazardul si se deduc cauzele ce l-au
produs.
Analiza pe arborele de erori – este o tehnica deductiva
Pune riscul sau hazardul ca radacina a arborelui si identifica starile
sistemului ce au putut produce acel hazard
Atunci cand se impune
impune, acestea vor fi conectate prin conditii de tip “si”/”sau”
Un scop ar putea fi minimizarea numarului cauzelor singulare ce au produs
caderea sistemului

Page 27
 Arborele de erori pentru pompa de insulina
doza insulina 
administrata incorect

sau

masurare eronata nivel 
Incorr ect livrare doza corecta la 
Corr ect dose
cadere sistem 
Deli v ery
glucoza v el
sugar le moment eronat
deli v er ed a t livrare
system
measur ed wr ong time failure

sau sau

cadere senzor
Sensor eroare calcul glucoza
Sugar T cadere 
imer Insulin
eroare calcul insulina semnale 
Pump
failur e computa tion timer e
failur computa tion incorecte pompa
signals
err or incorr ect incorr ect

sau sau

Eroare Eroare aritmetica Eroare algoritm Eroare aritmetica

algoritm

Evaluarea modului de reducere a riscurilor

Scopul – identificarea cerintelor de dependabilitate ce specifica modul de gestionare al riscurilor
pentru a asigura neproducerea incidentelor/accidentelor.
Strategii de reducere a riscurilor
Evitare risc;
Detectie si inlaturare risc;
Limitare efecte distructive.
Strategia folosita
Pentru sistemele critice se folosesc grupat mai multe strategii de reducere a riscurilor
Intr-un sistem de control al unui proces chimic vor fi inserati senzori de detectie a cresterii
presiunii din reactor cu mecanismele de corectie aferente. Suplimentar va fi inclus un sistem de
protectie independent ce va deschide o valva de supraplin in cazul detectiei unei presiuni peste
limita admisa.
Exemplu – pompa de insulina – riscuri software:
Erori aritmetice
Calcul ce produce valori prea mici/mari ale variabilelor. Poate fi inclus un handler de exceptie
pentru fiecare tip de eroare aritmetica
Erori de algoritm – se compara doza ce urmeaza a fi livrata cu doza precedenta sau cu doza
maxima sigura. Pentru depasiri se reduce doza.

Page 28
 Cerinte de siguranta – pompa de insulina

SR1: sistemul nu trebuie sa livreze nici o doza de insulina mai mare decat doza
maxima pentru utilizatorul
SR2: sistemul nu trebuie sa livreze doza zilnica cumulativa de insulina mai mare
d
decat
t doza
d maxima
i pentru
t utilizatorul
tili t l
SR3: sistemul trebuie sa includa facilitati hardware de diagnostic ce trebuie
executate minim de 4 ori/ora
SR4: sistemul trebuie sa includa un handler de exceptie pentru toate exceptiile
din tabelul de identificare riscuri
SR5: alarma sonora trebuie activata la descoperirea oricarei anomalii
hardware/software si un mesaj de diagnostic adecvat trebuie sa fie afisat
SR6: la producerea unui eveniment alarma in sistem, livrarea de insulina va fi
suspendata
d t pana ce utilizatorul
tili t l va reseta
t sistemul
i t l sii va sterge
t

Specificatii de siguranta

Cerintele de siguranta trebuie specificate separat

Au la baza analiza hazardurilor si riscurilor posibile

Cerintele de siguranta se aplica de regula intregului sistem si nu sub-sistemelor

componente. In termeni de inginerie a programarii siguranta unui sistem este o
proprietate emergenta (care rezulta in urma asigurarii altor proprietati).

IEC 61508 – Standard international pentru managementul sigurantei proiectat special

pentru asigurarea protectiei sistemelor. Nu se aplica tututror sistemelor critice.
Incorporeaza un model sigur al ciclului de viata si acopera toate aspectele
g
managementului sigurantei
g de la definirea domeniului proiectului
p pana
p la dezafectarea
sistemului.

Page 29
 Cerinte de siguranta pentru un sistem de control

Ciclul de viata sigur

Definire concept
Cerinte Functionale – specificarea si univers

functiilor legate de asigurarea

protectiei sistemului. Analiza hazard
si risc

Cerinte de integritate din punct de

vedere a sigurantei – definesc Deducere cerinte siguranta. Alocare cerinte siguranta.

fiabilitatea si disponibilitatea
sistemului de protectie. Au la
Planificare si dezvoltare

baza perioada estimata de Planificare Dezvoltare sisteme Facilitati externe 

pentru siguranta reducere riscuri
folosire a produsului si se
Validare O & M Instalare

clasifica folosind o scara de

integritate a sigurantei de la 1 la 4. Validare siguranta  Instalare si comisionare

Operare si maintenanta

Decomisionare sistem 

Page 30
 Specificarea securitatii
Exista unele asemanari cu specificarea sigurantei:
Nu este posibil sa se specifice cantitativ cerintele de securitate;
Specificatiile sunt mai curand de tipul “nu trebuie…” decat “trebuie…” .
Diferente
Din punct de vedere al managementului securitatii nu exista o definitie
acceptata pentru notiunea de securitate pentru ciclul de dezvoltare si nici nu
exista standarde de securitate;
Securitatea este caracterizata mai curand prin amenintari generice, decat prin
hazarduri specifice sistemului;
Exista tehnologii mature dedicate securizarii (criptare, transmisie pe linii
securizate, etc.). Totusi exista inca probleme in utilizarea pe scara larga a
acestora;
Dominanta furnizorilor singulari pe anumite sectoare de piata software (ex.
Microsoft) determina influentarea unui numar mare de sisteme printr-o unica
amenintare.

Procesul de specificare a securitatii

Analiza
tehnologiei 
de securitate

Analiza
tehnologie
Analiza
Identificare amenintari Specificare
active  si evaluare cerinte
protejate riscuri securitate
Atribuire
amenintari

Lista active Matrice Cerinte

sistem amenintari si
i i i securitate
riscuri
Descriere
active
si amenintari

Page 31
 Etape in specificarea securitatii

Identificarea si evaluarea elementelor ce trebuiesc protejate

Se identifica datele si programele ce trebuie protejate, precum si gradul de protectie ce
trebuie asigurat pentru fiecare. Gradul de protectie depinde de valoarea entitatii
protejate ( de exemplu un fisier cu parole este mult mai valoros decat un set de pagini
web publice)
p )
Analiza amenintarilor posibile si evaluarea estimativa a riscurilor
Atribuirea amenintarilor
Amenintarile identificate sunt corelate cu datele si programele sistemului dezvoltat,
astfel incat fiecare entitate sa aiba asociata o lista de amenintari posibile.
Analiza de tehnologie
Sunt analizate si se evalueaza utilitatea si aplicabilitatea, incazul amenintarilor curente,
a tehnologiilor de securitate disponibile.
Specificarea cerintelor de securitate
Acolo unde se impune, alaturi de specificare se va mentiona explicit si tehnologia de
securitate la care se va recurge.

Tipuri de cerinte de securitate

De identificare
De autentificare
De autorizare
De imunitate
De integritate
De detectie a intruziunilor
De non-repudiere
De asigurare a spatiului privat
De a
auditare securitatii
ditare a sec ritatii
De intretinere a securitatii sistemului

Page 32
 Exemplu de cerinte de securitate pentru o aplicatie de acces la
resurse de documentare (LIBSYS)

SEC1: toti utilizatorii sistem trebuie sa fie identificati prin numarul cardului de
biblioteca si parola personala
SEC2: utilizatorii privilegiati trebuie asignati conform clasei de utilizare (student,
personal biblioteca, profesori)
SEC3: inaintea executiei oricarei comenzi, LIBSYS trebuie sa verifice daca
utilizatorul are suficiente privilegii sa acceseze si sa execute comanda solicitata
SEC4: cand un utilizator solicita un document, acesta trebuie sa fie logat. Vor fi
memorate date de logare precum timp, ordin, identificator utilizator, articole
comandate
SEC5: trebuie executat bakup pe datele sistem o data pe zi, iar fisierele de bukup
memorate inafara sistemului intr-o locatie securizata
SEC6: utilizatorii nu trebuie sa aiba mai multe sesiuni proprii deschise simultan
pe sistem

Specificarea cerintelor de fiabilitate

Fiabilitate hardware
Care este probabilitatea ca o componenta de echipament sa cada si cat
timp dureaza repararea componentei?

Fiabilitate software
Cu ce probabilitate o componenta software va produce o iesire
incorecta? Caderile software sunt diferite de cele harware in sensul ca
acestea nu vor produce de cele mai multe ori incapacitate de operare ci
iesiri incorecte.

Fiabilitatea in operare
Cu ce probabilitate operatorul sistemului va comite o eroare?

Page 33
 Cerinte functionale/nefunctionale ce refera fiabilitatea
Cerinte functionale de fiabilitate (exemple)
Se specifica gama permisa a valorilor introduse de catre operator si se verifica
incadrarea valorilor curente in limitele prestabilite
La initializare sistemul trebuie sa verifice existenta blocurilor defecte de memorare
Crearea mai multor programe cu functionalitati similare generate din acelasi set de
cerinte mai cu seama in implementarea in industria auto a sistemului de control al
cerinte,
franarii
Sistemul sa fie implementat intr-un subset sigur Ada si verificat prin analiza statica.
(Ada este un limbaj de programare imperativ destinat dezvoltarii de sisteme incorporate
cu nivel de integritate crescut si pentru care corectitudinea raspunsurilor este extrem de
importanta)

Cerinte nefunctionale de fiabilitate (exemple)

Exprimarea cantitativa a nivelului de fiabilitate ce trebuie asigurat pentru sistem.
Fiabilitatea este un atribut dinamic al sistemului – specificatiile de fiabilitate pe cod nu
pot fi corelate direct cu fiabilitatea produsului (ex. mai putin de N defecte/1000 linii cod).
Erorile pe cod sunt utile in procesul de analiza post-livrare in care se evalueaza cat de
buna a fost tehnica de dezvoltare abordata.
Pentru specificarea fiabilitatii globale a sistemului vor trebui alese metrici adecvate

Metrici de fiabilitate

Sunt unitati de masura a fiabilitatii sistemului

Fiabilitatea globala se masoara prin numararea caderilor operationale ale sistemului si corelarea
acestor valori, acolo unde este cazul, cu cererile adresate sistemului si timpul cat acesta a fost
operational.
Pentru evaluarea fiabilitatii sistemelor critice, se impune un program de masuratori pe termen
lung.
g
Metric Explanation

POFOD The likelihood that the system will fail when a service request is made. A POFOD of 0.001 means that 1 out of a thousand service requests may result in
Probability of failure on demand failure.

ROCOF The frequency of occurrence with which unexpected behaviour is likely to occur. A ROCOF of 2/100 means that 2 failures are likely to occur in each
Rate of failure occurrence 100 operational time units. This metric is sometimes called the failure intensity.

MTTF The average time between observed system failures. An MTTF of 500 means that 1 failure can be expected every 500 time units.
Mean time to failure

AVAIL The probability that the system is available for use at a given time. Availability of 0.998 means that in every 1000 time units, the system is likely to be
Availability available for 998 of these.

Page 34
 Metrici de fiabilitate - definire
Probabilitatea de cadere a sistemului atunci cand se face o cerere de serviciu asupra acestuia. De
regula cererile de serviciu ce intra in discutie sunt frecvente si intermitente.
Este adecvata pentru protectia acelor sisteme pentru care serviciile sunt apelate ocazional si
pentru care consecintele nelivrarii acestora sunt serioase.
Relevanta pentru multe sisteme critice din punct de vedere al sigurantei ce au componente de
g
management p
a exceptiilor.
Ex. Oprirea de urgenta a unui proces chimic

Frecventa de producere a erorilor (ROCOF)

Reflecta frecventa de aparitie a caderilor din sistem.
ROCOF de 0.002 inseamna 2 caderi sunt probabil sa apara la fiecare 1000 unitati de timp de
operare (ex. 2 caderi/1000 ore operare).
Relevanta pentru sistemele de operare, procesele de tranzactionare, procesele cu cereri similare
frec ente
frecvente.
Ex.: sistem de procesare a unui card bancar, sistem de rezervare locuri.

Metrici de fiabilitate – definire

Media timpului intre caderi (media timpului de buna functionare – MTBF)
Masoara timpul intre caderile observabile ale sistemului. Measure of the time between observed
failures of the system. Este inversa frecventei de producere a erorilor ROCOF pentru sistemele
stabile.
MTBF de 500 inseamna ca timpul mediu intre caderi este de 500 unitati temporale.
Relevanta p
pentru sisteme cu tranzactii lungi
g (timpul
( p necesar procesarii
p unei singure
g tranzacti
este mare). Normal MTBF trebuie sa fie mai mare decat durata de procesare a unei tranzactii (ex.
Sisteme CAD unde proiectantul poate persista pe un model timp indelungat sau procesoarele de
text).
Disponibilitatea
Masoara procentul de timp in care sistemul este disponibil pentru a fi folosit.
Necesita considerarea timpilor de reparatie si restartare sistem
Disponibilitate de 0.998 inseamna ca sistemul este disponibil 998 unitati temporale din 1000.
Relevanta pentru sistemele ce functioneaza continuu, fara oprire (ex. Sisteme de comutare intr-o
centrala
t l telefonica,
t l f i sistemele
i t l de
d comanda d macaz in
i transportul
t t l feroviar,
f i etc.)
t )
Metricile de fiabilitate nu tin cont de consecintele caderilor.
Unele defecte temporare pot sa nu aiba consecinte reale, altele, insa, pot duce la pierdere/corupere
date si pierdere in serviciu furnizat de catre sistem.
Uneori este necesara identificarea categoriilor de caderi si folosirea unor metrici diferite pentru
fiecare clasa. Va rezulta o structurare a cerintelor de fiabilitate.

Page 35
 Consecinte si clasificare caderi ale sistemului

Clasa cadere Descriere

Tranzitorie Apare numai pentru anumite intrari

Permanenta Apare pentru toate intrarile

Recuperabila Sistemul se poate recupera fara interventia operatorului

Nerecuperabila E necesara interventia operatorului pentru recuperarea sistemului dupa cadere

Faracorupere sistem Caderea nu corupe starea sistemului si datele

Cu corupere sistem Caderea corupe starea sistemului si datele

Pasi in specificarea fiabilitatii

Pentru fiecare sub-sistem , se face analiza consecintelor caderilor posibile.
Se continua analiza eventualelor caderi prin impartirea caderilor in clase adecvate.
Pentru fiecare clasa identificata, se vor alege metrici de fiabilitate. Pot fi folosite metrici
diferite pentru cerinte diferite de fiabilitate
Se vor identifica cerintele de fiabilitate functionala ce reduc probabilitatea de producere a
caderilor critice
critice.
Ex.:ATM (fiecare ATM este folosit 300 ori pe zi, banca are 1000 ATM-uri, durata intre 2
actualizari este de 2 ani, fiecare masina gestioneaza in medie 200000 tranzactii, sunt
aproximativ 300000 tranzactii zilnice pe baza de date). Pentru acest sistem specificarea
cerintelor de fiabilitate ar putea fi:
Failure class Example Reliability metric
Permanent, The system fails to operate with any card that is ROCOF
non-corrupting. input. Software must be restarted to correct failure. 1 occurrence/1000 days
Transient,
T i non- The
Th magnetici stripe
i data
d cannot be
b readd on an ROCOF
corrupting undamaged card that is input. 1 in 1000 transactions
Transient, A pattern of transactions across the network causes Unquantifiable! Should
corrupting database corruption. never happen in the
lifetime of the system

Page 36
 Validarea specificatiilor de fiabilitate

Specificatiile ce urmaresc asigurarea unei fiabilitati ridicate sunt imposibil de

validat
lid t empiric
ii
De exemplu o corupere acceptabila pentru baza de date ar insemna o
probabilitate de cadere pe invocarea unui serviciu (POFOD) mai mica de 1 la 1
milion.
Pentru o tranzactie ce dureaza 1 sec., simularea tuturor tranzactiilor pentru o
intreaga zi va dura 3.5 zile.
In multe cazuri durata testelor de fiabilitate depaseste ciclul de viata al
sistemelor.
sistemelor

Page 37