Varvara Gabriela - Decembrie - 2012 - Anexa1 - SCI - IP1 - Curs 12 - Verificarea Si Validarea Sistemelor Critice PDF

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
Investeşte în oameni ! AMPOSDRU
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 de proiecte: nr. 86 „Universitate pentru viitor”
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 12 – Verificarea si validarea sistemelor critice

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
AMPOSDRU
Obiective
 Explicarea modului in care poate fi masurata fiabilitatea
sistemelor si cum pot fi folosite modelele de crestere a
fiabilitatii pentru predictia acesteia
 Descrierea argumentelor de siguranta si a modului de folosire
a acestora
 Detaliarea problemelor ce apar legate de asigurarea
sigurantei
 Introducerea cazurilor de siguranta si explicarea modului in
care acestea sunt folosite in validarea sigurantei
 Subiecte tratate:validarea fiabilitatii, asigurarea sigurantei,

evaluarea securitatii, cazuri de siguranta si dependabilitate
AMPOSDRU
Validarea sistemelor critice

 Costurile de verificare si validare a sistemelor critice
sunt legate de procese si analize suplimentare fata de
sistemele necritice deoarece:
– Costurile si consecintele esecului sunt insemnate, astfel
incat se justifica costul identificarii si inlaturarii defectelor;
– Sistemul trebuie dezvoltat conform unor prescriptii formale
sau reglementari stricte ce implica cerinte de dependabilitate.
Acestea pot solicita activitati specifice de verificare si
validare ce trebuiesc derulate obligatoriu.
 In mod normal costurile de verificare si validare (V&V)
depasesc 50% din costurile de dezvoltare
AMPOSDRU
Validarea fiabilitatii
 Implica executia programului in vederea stabilirii
atingerii nivelului cerut al fiabilitatii
– Acest tip de verificare nu poate fi inclus intr-un proces
normal de testare deoarece datele de testare forteaza
defectarea si sunt atipice pentru testarea functionarii normale
– Drept consecinta, masurarile de fiabilitate solicita seturi de
date de test proiectate special pentru a modela intrarile
procesate de sistem
AMPOSDRU
Activitati in procesul de validare a fiabilitatii

 Stabilirea profilului operational al sistemului
 Sinteza seturilor de date de test conform profilului operational
 Testarea sistemului si observarea numarului de caderi si a
momentelor cand se petrec acestea
 Calculul fiabilitatii dupa ce s-au observat un numar de caderi
relevant din punct de vedere statistic
Identificarea Pregatirea Aplicare Calcul

profilelor seturilor de teste fiabilitate
operationale date de test sistemului observata
AMPOSDRU
Testare statistica
 Nu are la baza contorizarea caderilor

 Presupune predictarea fiabilitatii pe baza numarului de erori
induse in produsul software
– Din motive statistice, vor fi induse mai multe erori decat numarul
maxim admis in specificatiile de fiabilitate
 Se va specifica un nivel acceptabil al fiabilitatii si softul va fi
testat si corectat pana la atingerea acestui nivel
AMPOSDRU
Probleme in masurarea fiabilitatii

 Necunoasterea certa a profilului operational
– Profilul operational nu reflecta corect modul de operare real al
sistemului
 Costuri mari pentru generarea datelor de test
– Costurile pot creste semnificativ daca seturile de date de test nu pot fi
generate in mod automat
 Incertitudini statistice
– Pentru calculul fiabilitatii este necesara producerea unui numar de
caderi, semnificativ din punct de vedere statistic, dar sistemele cu
fiabilitate crescuta esueaza extrem de rar.
AMPOSDRU
Profiluri operationale
 Un profil operational este reprezentat printr-un set de date de test ce au frecventa
de aparitie egala cu frecventa acelorasi valori pentru intrarile sistemului in
functionarea normala a acestuia
– O buna potrivire cu datele din functionarea normala este absolut necesara. In
caz contrar fiabilitatea dedusa din masuratori va fi diferita de fiabilitatea reala
a sistemului.
 Poate fi generat din date reale colectate de la un sistem existent, sau, mai frecvent,
din ipoteze facute asupra sabloanelor de utilizare a sistemului.
Numar de intrari
.. .
Clase de intrari
AMPOSDRU
Generarea profilului operational
 Ori de cate ori este posibil, trebuie sa poata fi generat

automat
 Pentru sistemele interactive, generarea automata a profilului
operational este dificila.
 Este usor de generat pentru intrari normale, dar este dificil de
obtinut pentru intrari ce apar cu probabilitate scazuta.
AMPOSDRU
Predictia fiabilitatii
 Modelul cresterii fiabilitatii reprezinta un model matematic al
modificarii fiabilitatii pe masura ce sistemul este testat si
erorile sunt indepartate
 El este folosit, prin extrapolare de la datele curente, ca
predictor al fiabilitatii:
– Simplifica planificarea testarii si procesul de negociere cu
clientii.
– Se poate estima cand se va termina procesul de testare
– Se poate demonstra clientilor daca se va putea realiza o
crestere de fiabilitate sau nu.
 Predictorul fiabilitatii versiunii aplicatiei depinde de modul
cum este folosita testarea statistica in calculul acestuia.
AMPOSDRU
Cresterea fiabilitatii in pasi egali
(ROCOF) Frecventa de aparitie a erorilor (Rate of OCcurrence Of Failures)
t1 t2 t3 t4 t5
Timp
AMPOSDRU
Crestere observabila a fiabilitatii
 Modelul cresterii cu pasi egali are avantajul simplitatii, dar nu

reflecta realitatea.
 Fiabilitatea nu creste, in mod necesar, odata cu introducerea
de modificari in cod, deoarece acestea pot introduce noi erori.
 Cresterea de fiabilitate este incetinita in timp, pe masura ce
erorile cu frecventa mare de aparitie sunt identificate si
inlaturate.
 Un model de crestere aleatoare in care fiabilitatea are
schimbari fluctuante reflecta mai corect influenta
schimbarilor asupra fiabilitatii.
AMPOSDRU
Crestere in trepte, in mod aleator, a fiabilitatii
Frecventa de aparitie a erorilor Se observa nivele diferite de modificare a fiabilitatii
(ROCOF) Eliminarea erorilor introduce noi erori

(crestere ROCOF)
t1 t2 t3 Timp t4 t5
AMPOSDRU
Selectia modelului de crestere

 Se pun in discutie mai multe modele de crestere a fiabilitatii -nu exista un model unic si
general aplicabil
 Se va masura fiabilitatea si datele observate vor fi raportate la mai multe modele
 Modelul ce reflecta cel mai bine comportarea reala va fi cel folosit pentru calculul
predictorului de fiabilitate
Fiabilitate
= fiabilitatea masurata
Modelul curbei de crestere a fiabilitatii
Fiabilitatea impusa
Timp estimat pentru atingerea fiabilitatii Timp
AMPOSDRU
Asigurarea sigurantei
 Asigurarea sigurantei si masurarea fiabilitatii sunt doua

probleme diferite:
– In cadrul unor limite pentru erorile de masurare, se poate sti daca
nivelul de fiabilitate impus a fost atins sau nu;
– Prin comparatie, masurarea sigurantei este un lucru imposibil
– Asigurarea sigurantei are drept scop stabilirea unui interval de
incredere pentru intreg sistemul
AMPOSDRU
Increderea in siguranta
 Increderea in siguranta sistemului poate varia in limite foarte

largi de la foarte joasa pana la foarte inalta.
 Increderea se dobandeste prin:
– Experienta trecuta de colaborare cu firma ce dezvolta softul;
– Folosirea de procese dependabile ce includ activitati destinate
asigurarii sigurantei;
– V & V extensiva, cu includerea tehnicilor de validare statica si
dinamica.
AMPOSDRU
Review-uri de siguranta
 Review pentru verificarea functionalitatii impuse.
 Review pentru verificare maintenabilitate si asigurarea unui
nivel acceptabil de intelegere a structurii sistemului.
 Review pentru verificarea algoritmilor si modului de
proiectare a structurilor de date in raport cu specificatiile.
 Review pentru verificarea consistentei codului in raport cu
algoritmii si structurile de date proiectate.
 Review de adecvanta pentru testarea sistemului.
AMPOSDRU
Sfaturi pentru review

 Softul trebuie creat cat se poate de simplu.
– Utilizarea de tehnici simple pentru dezvoltarea de software cu evitarea

constructiilor ce pot genera erori, cum ar fi pointerii si recursivitatea.
 Folosirea unor informatii ascunse pentru localizarea efectului

oricarui proces de corupere a datelor.
 Folosirea adecvata de tehnici tolerante la defect, fara a cadea

in capcana considerarii ca un soft tolerant la defecte este in
mod necesar sigur.
AMPOSDRU
Argumente de siguranta
 Argumentele de siguranta indica faptul ca sistemul nu poate
atinge o stare nesigura.
 Acestea sunt mai slabe decat indicatorii de corectitudine ce
demonstreaza ca softul se conformeaza propriei specificatii.
 De regula au la baza o demonstratie prin reducere la absurd:
– Se presupune ca o stare nesigura poate fi atinsa;
– Se demonstreaza cu ajutorul codului program ca acest
lucru este imposibil.
 Se poate dezvolta un model grafic al argumentelor de
siguranta
AMPOSDRU
Construirea unui argument de siguranta

 Se stabilesc conditiile de iesire sigura pentru o
componenta/program.
 Pornind de la punctul terminus al executiei codului
(STOP) se parcurge inapoi arborele de executie pana la
identificarea completa a tuturor cailor ce duc la STOP.
 Se presupune conditia de iesire ca fiind falsa (iesire
nesigura)
 Se demonstreaza ca ipotezele facute pentru fiecare
cale de la intrare la iesire contrazic presupunerea unei
iesiri nesigure din componenta.
AMPOSDRU
Ex. codul controlerului pentru dispozitivul de livrare a insulinei
dozaCurenta=calcul_Insulina();
//verificare siguranta – modificare dozaCurenta daca este necesar
// instructiunea if 1
if(dozaAnterioara==0) { if(dozaCurenta>16) dozaCurenta=16;}
else { if (dozaCurenta>(dozaPrecedenta*2) )dozaCurenta=dozaPrecedenta*2;
//instructiunea if 2
if(dozaCurenta<dozaMinima) dozaCurenta=0;
else if (dozaCurenta>dozaMaxima) dozaCurenta=dozaMaxima;
administrare_Insulina(dozaCurenta);
AMPOSDRU
Model al unui argument de siguranta

Administrare
supradoza
Administrare_Insulina
dozaCurenta> Preconditie pentru stare nesigura

dozaMaxima
or
Contradictie
dozaCurenta>=dozaMinima si
dozaCurenta<=dozaMaxima
Contradictie Contradictie
dozaCurenta =
dozaCurenta = 0
dozaMaxima
assign assign
dozaCurenta=0 dozaCurenta=
If 2 neexecutat dozaMaxima
If 2 If 2
ramura then ramura else
executata executata
AMPOSDRU
Caile de executie ale programului

 Nici o ramura a instructiunii if 2 nu se executa
– se produce daca dozaCurenta>=dozaMinima si <=
dozaMaxima
 Ramura then a instructiunii if 2 este executata
– dozaCurenta = 0
 Ramura else a instructiunii if 2 este executata
– dozaCurenta=dozaMaxima
 In toate cazurile, post conditiile contrazic conditia de
nesiguranta conform careia
doza administrata > doza maxima
AMPOSDRU
Asigurarea procesului
 Asigurarea procesului implica definirea unui proces
dependabil si asigurarea ca acest proces este urmat
pe toata durata dezvoltarii sistemului
 Folosirea unui proces sigur este un mecanism de
reducere a probabilitatii introducerii de erori in sistem
– Accidentele sunt evenimente rare, astfel ca testarea nu poate
identifica toate problemele.
– Cerintele de siguranta sunt formulate adesea in forma
“sistemul nu trebuie sa …” si deci sunt greu de demonstrat
prin testare.
AMPOSDRU
Activitati ale procesului legate de siguranta
 Crearea unui sistem hazard de login si monitorizare

 Intalniri intre inginerii responsabili cu siguranta sistemului
 Folosirea extensiva a review-urilor de siguranta
 Crearea unui sistem de certificare a sigurantei
 Implementarea unui sistem detaliat de management a
configuratiei
AMPOSDRU
Analiza hazardului
 Analiza hazardului implica identificarea hazardurilor din

sistem si a cauzelor ce le genereaza
 Va trebui asigurata o trasabilitate clara de la hazardurile
identificate la actiunile intreprinse in cadrul procesului pentru
tratarea acestora
 Un sistem log poate fi folosit pentru inregistrarea hazardurilor
in cursul intregului proces de dezvoltare dependabil
AMPOSDRU
Exemplu de intrare intr-un log pentru analiza de hazard al

sistemului de livrare de insulina
 Sistemul trebuie sa includa o componenta software de

autotestare, ce va testa sistemului de senzori, ceasul sistem
si sistemul de livrare a insulinei
 Sistemul de autotestare trebuie sa se executa la fiecare minut
 Daca sistemul de autotestare descopera o eroare in oricare
din componente va trebui sa produca o avertizare sonora si
afisajul pompei va trebui sa indice componenta eronata.
Livrarea de insulina se va opri imediat.
AMPOSDRU
Verificari de siguranta in timpul executiei

 Pe perioada executiei programului, verificarile de siguranta
pot fi incluse sub forma unor declaratii de solicitare a
verificarii executiei programului in contextul unui proces de
operare sigure
 Aceste declaratii pot fi introduse in cod sub forma unor
comentarii ce pot impune generare automata de cod pentru a
le verifica
AMPOSDRU
Administrare de insulina cu includerea de declaratii de siguranta

static void administrare_Insulina() throws SafetyException{
int nr_max_incremente=PompaInsulina.dozaMaxima/8;
int incremente=PompaInsulina.dozaCurenta/8;
// verificare dozaCurenta<=PompaInsulina.dozaMaxima
If (PompaInsulina.dozaCurenta>PompaInsulina.dozaMaxima)
throw new SafetyException (Pompa.dozaMare);
else
for(int i=1;i<=incremente;i++)
{
generareSemnal();
if(i>nr_max_incremente)
throw new SafetyException(Pompa.incrementeIncorecte)
} //bucla for
} // sfarsit administrare_Insulina
AMPOSDRU
Verificarea securitatii
 Verificarea securitatii are elemente de corelare cu verificarea
de siguranta.
 Ambele urmaress sa demonstreze ca sistemul nu poate
ajunge intr-o anume stare (nesigura sau lipsita de securitate)
 Cu toate acestea, intre cele 2 tipuri de verificari exista si
diferente:
– Problemele de sigura sunt accidentale, cele de securitate
sunt deliberate
– Problemele de securitate sunt generice (o larga categorie
de sisteme sufera de aceleasi probleme)
– Problemele de siguranta sunt legate de domeniul de
aplicare
AMPOSDRU
Validarea de securitate
 Validare bazata pe experienta:
– Sistemul este revizuit si analizat de echipa de validare in raport cu
tipurile de atacuri cunoscute
 Validarea bazata pe utilitare:
– Utilitare variate de verificarea securitatii (ex. verificatoare de parola)
sunt folosite pentru a analiza sistemul in procesul sau de operare
 Folosirea echipelor de atac (“tiger team”)
– Se costituie echipe de experti ce au ca scop crearea de brese de
securitate in sistem prin simularea de atacuri asupra acestuia
 Verificare formala
– Sistemul este verificat in raport cu un document de specificatie
formala a securitatii
Exemplu de liste de verificare a securitatii

AMPOSDRU
 Au toate fisierele din sistem setate permisiuni adecvate de

acces? O setare eronata a dreptului de acces poate determina
un acces neautorizat?
 Sesiunile utilizatorilor se termina automat dupa o perioada de
inactivitate? Sesiunile lasate active pot permite accesul
neautorizat?
 Daca programul este scris intr-un limbaj ce nu face
verificarea depasirii spatiului unui masiv, exista situatii in
care depasirea unui buffer poate fi exploatata prin trimiterea
de siruri cu cod pe care sistemul sa le execute?
 La sisteme cu parola se verifica taria acesteia? ( amestec de
litere, numere, alte caractere)
AMPOSDRU
Cazuri de siguranta si dependabilitate
 Reprezinta documente structurate ce ilustreaza argumente si

demonstratii detaliate ce atesta ca un nivel solicitat de
siguranta si dependabilitate a fost atins
 Sunt impuse de reglementarile in vigoare in vederea
certificarii sistemului inainte de demararii operationale a
acestuia
AMPOSDRU
Caz formal de siguranta

 Este solicitat in practica curenta inainte de punerea in functie
a sistemelor critice din punct de vedere al sigurantei, cum ar
fi sistemele de semnalizare, de control al traficului aerian, etc.
 Un caz de siguranta este :
– Un document evidenta ce furnizeaza argumente valide si
convingatoare conform carora sistemul are un nivel de
siguranta adecvat pentru o anume utilizare a sa intr-un
mediu dat
 Argumentele in cazurile formale de siguranta/dependabilitate
au la baza demonstratii formale, logici de proiectare,
demonstratii specifice de siguranta, etc. Factorii de proces
pot fi, de asemeni, inclusi.
AMPOSDRU
Componente ale unui caz de siguranta case

 Descrierea sistemului – o descriere de ansamblu si o descxriere a componentelor critice
 Cerinte de siguranta – extrase din specificatia de cerinte
 Analiza de hazard si risc – descrierea hazardurilor identificate si a masurilor aferente de
reducere a riscului
 Analiza proiectarii – set de argumente structurate care sa ateste ca proiectarea este un
proces sigur
 Verificare si validare – descrierea procedurilor V&V folosite, eventual a planurilor de testare,
precum si a rezultatelor V&V
 Rapoarte de review – toate review-urile de proiectare si siguranta
 Competentele echipei – documente ce atesta competenta echipei implicate in dezvoltarea si
validarea sistemelor de siguranta
 Procesul de asigurare a calitatii – descrierea proceselor de asigurare a calitatii derulate pe
parcursul dezvoltarii sistemului
 Procese de management a schimbarilor – modificarile propuse, actiuni intreprinse si, acolo
unde se impune, justificari legate de asigurarea sigurantei de catre schimbarile propuse
AMPOSDRU
Exemplu de argumentare a sigurantei pentru pompa de insulina

 Cerinta: o doza singulara maxima calculata de catre pompa
de insulina nu va trebui sa depaseasca doza maxima
– Evidenta – argument de siguranta prezentat in figura atasata (cod
program)
– Evidenta – seturile de date de testare
– Evidenta – raportul de analiza statica software
 Argument – argumentul de siguranta prezentat demonstreaza
ca doza maxima de insulina ce poate fi calculata este
=dozaMaxim. In 400 teste efectuate, doza a fost calculata
corect si nu a depasit niciodata dozaMaxima. Analiza statica a
softului de control nu releva anomalii. Este rezonabil sa se
considere cerinta indeplinita.
AMPOSDRU
Ierarhia de cerinte de siguranta
Pompa de insulina
nu va livra nici o
doza nesigura
Doza singulara maxima

dozaMaxima este dozaMaxima este sigura
calculata de softul pompei
setata corect la pentru utilizator
nu depaseste dozaMaxima
configurare pompa
in operarea normala doza daca softul cade doza

singulara nu depaseste maxima nu depaseste
dozaMaxima dozaMaxima
AMPOSDRU
Sumar prelegere
 Masurarile de fiabilitate se bazeaza pe exersarea sistemului utilizand un profil
operational – un set de intrare simulat, adecvat folosirii curente a sistemului
 Modelele de crestere a fiabilitatii demonstreaza modul de crestere a fiabilitatii pe
masura testarii si inlaturarii defectelor
 Argumentele/demonstratiile de siguranta reprezinta cai de a demonstra ca
niciodata nu poate sa se produca o conditie de hazard
 Dezvoltarea sistemelor critice din punct de vedere a sigurantei impune folosirea
unui proces dependabil. Acesta trebuie sa includa identificarea conditiilor de
hazard si activitati de monitorizare.
 Validarea securitatii implica analiza bazata pe experienta, pe utilitare, pe
recurgerea la echipe de tip “tiger” pentru a ataca sistemul.
 Cazurile de siguranta reunesc evidentele ce sustin argumentarea ca sistemul este
sigur.

Varvara Gabriela - Decembrie - 2012 - Anexa1 - SCI - IP1 - Curs 12 - Verificarea Si Validarea Sistemelor Critice PDF

Î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

Varvara Gabriela - Decembrie - 2012 - Anexa1 - SCI - IP1 - Curs 12 - Verificarea Si Validarea Sistemelor Critice PDF

Încărcat de

Drepturi de autor:

Formate disponibile

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

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

Investeşte în oameni ! AMPOSDRU

Proiect cofinanţat din FONDUL SOCIAL EUROPEAN

Numărul de identificare al contractului: POSDRU/86/1.2/S/63806

Curs 12 – Verificarea si validarea sistemelor critice

 Subiecte tratate:validarea fiabilitatii, asigurarea sigurantei,

Validarea sistemelor critice

Activitati in procesul de validare a fiabilitatii

Identificarea Pregatirea Aplicare Calcul

 Nu are la baza contorizarea caderilor

Probleme in masurarea fiabilitatii

Generarea profilului operational

 Ori de cate ori este posibil, trebuie sa poata fi generat

Cresterea fiabilitatii in pasi egali

(ROCOF) Frecventa de aparitie a erorilor (Rate of OCcurrence Of Failures)

Crestere observabila a fiabilitatii

 Modelul cresterii cu pasi egali are avantajul simplitatii, dar nu

Crestere in trepte, in mod aleator, a fiabilitatii

Frecventa de aparitie a erorilor Se observa nivele diferite de modificare a fiabilitatii

(ROCOF) Eliminarea erorilor introduce noi erori

Selectia modelului de crestere

Modelul curbei de crestere a fiabilitatii

Timp estimat pentru atingerea fiabilitatii Timp

 Asigurarea sigurantei si masurarea fiabilitatii sunt doua

 Increderea in siguranta sistemului poate varia in limite foarte

Sfaturi pentru review

– Utilizarea de tehnici simple pentru dezvoltarea de software cu evitarea

 Folosirea unor informatii ascunse pentru localizarea efectului

 Folosirea adecvata de tehnici tolerante la defect, fara a cadea

Construirea unui argument de siguranta

Ex. codul controlerului pentru dispozitivul de livrare a insulinei

Model al unui argument de siguranta

dozaCurenta> Preconditie pentru stare nesigura

Caile de executie ale programului

Activitati ale procesului legate de siguranta

 Crearea unui sistem hazard de login si monitorizare

 Analiza hazardului implica identificarea hazardurilor din

Exemplu de intrare intr-un log pentru analiza de hazard al

 Sistemul trebuie sa includa o componenta software de

Verificari de siguranta in timpul executiei

Administrare de insulina cu includerea de declaratii de siguranta

Exemplu de liste de verificare a securitatii

 Au toate fisierele din sistem setate permisiuni adecvate de

Cazuri de siguranta si dependabilitate

 Reprezinta documente structurate ce ilustreaza argumente si

Caz formal de siguranta

Componente ale unui caz de siguranta case

Exemplu de argumentare a sigurantei pentru pompa de insulina

Ierarhia de cerinte de siguranta

Doza singulara maxima

in operarea normala doza daca softul cade doza

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