Curs 1_Introducere in Ingineria Programarii

Page 1

Ingineria programarii ICurs 1

Introducere in ingineria programarii

Page 2

<Ingineria programarii I><Gabriela Varvara>Capitolul 1: Introducere in ingineria programarii – cursul 1

Obiective curs 1:

Obiectivul 1: introducere in disciplina de inginerie a programarii: necesitate, definitii si raportare la disciplinele adiacente. Obiectivul 2: terminologie si incadrarea ingineriei programarii in domeniu. Costuri in dezvoltarea software.Obiectivul 3: formularea raspunsurilor legate de practica ingineriei programarii, precum si o scurta prezentare a aspectelor legate de etica acestei profesiiObiectivul 4: introducere in ingineria programarii asistata de calculator; utilitare suport in dezvoltarea software.Obiectivul 5: definire sistem critic – legatura intre caderea sistemului si consecintele pe plan economic si/sau uman. Dimensiunile increderii in exploatarea unui sistem: disponibilitate fiabilitate siguranta incredere Evitare greseli detectare si eliminaredisponibilitate, fiabilitate, siguranta, incredere. Evitare greseli, detectare si eliminare erori, limitare distrugeri provocate de caderea sistemului.Subiecte tratate: raspunsuri la cele mai frecvente intrebari legate de ingineria programarii, responsabilitate profesionala si etica, exemplu de sistem critic din punct de vedere al sigurantei, gradul de incredere in folosirea produselor software, disponibilitate si fiabilitate siguranta securitate

2

disponibilitate si fiabilitate, siguranta, securitate

Page 3


NECESITATEA DISCIPLINEI INGINERIA PROGRAMARII

Economiile tuturor statelor dezvoltate se bazeaza pe software

Din ce in ce mai multe sisteme sunt controlate software

Complexitatea produselor software a evoluat exponential in timp:Complexitatea produselor software a evoluat exponential in timp:

In 1946 Goldstine si von Neumann considerau ca 1000 de instructiuni reprezinta o limita superioara rezonabila pentru complexitatea problemelor rezolvabile cu calculatorul.

Desi initial Bill Gates afirma ca 64KB de memorie RAM reprezinta o limita superioara pentru orice program ce ruleaza pe un calculator personal, in 1995 el recunostea ca ultimele 2 gdecenii au adus schimbari majore in acest sens

Sistemul de operare System V, versiunea 4.0 (UNIX) a fost obtinut prin compilarea a 3 700 000 linii de cod

Pentru realizarea sistemului de operare IBM OS360 au fost necesari 5000 de ani-om.

Programele scrise pentru naveta spatiala NASA au aproximativ 40 milioane de linii de cod obiect

3

Page 4


GRESELI CELEBRE

IBM continea la fiecare lansare 1000 greseliIBM continea la fiecare lansare 1000 greseli

Pierderea vehiculului de explorare VENUS a fost explicata prin prezenta unei “,” intr-o bucla FOR

Explozia navetei Ariane 5, datorata unei greseli in software a produs o pierdere de 500.000.000$

O greseala software la centrul informatic de la Pentagon a determinat activarea sistemului anti-racheta americanracheta american.

Etc…

4

Page 5


Ce este ingineria programarii?

Prima definitie a fost data in 1968 de catre NATO – Ingineria programarii reprezinta stabilirea si utilizarea de principii ingineresti solide pentru a obtine in mod economic programe care sunt sigure si functioneaza eficient pe masini de calcul concrete.

O definitie mai recenta (1983), formulata de IEEE poate fi regasita in Standard Glossary of Software Engineering Tehnology – Ingineria programarii reprezinta abordarea sistematica a dezvoltarii functionarii intretinerii si retragerii din functiune a programelordezvoltarii, functionarii, intretinerii si retragerii din functiune a programelor

Intr-o maniera didactica si sistematica consideram la ora actuala sofware engineering drept o disciplina ce se ocupa cu toate aspectele legate de productia de software. Inginerii software vor trebui sa lucreze sistematic si organizat si sa utilizeze utilitare si tehnici adecvate problemei detrebui sa lucreze sistematic si organizat si sa utilizeze utilitare si tehnici adecvate problemei de rezolvat, constrangerilor de dezvoltare si resurselor disponibile.

5

Page 6


Diferenta dintre ingineria programarii si stiinta calculatoarelor

Stiinta calculatoarelor este o disciplina teoretica ce se ocupa cu definirea conceptelor fundamentaleStiinta calculatoarelor este o disciplina teoretica ce se ocupa cu definirea conceptelor fundamentale ale domeniului. Ingineria programarii se ocupa de aspectele practice legate de dezvoltarea si livrarea de software util

Spre deosebire de alte discipline, cum ar fi ingineria electrica, teoriile formulate de stiinta gcalculatoarelor nu ofera un suport complet pentru ingineria programarii.

Ingineria programarii are drept preocupare toate aspectele dezvoltarii sistemelor informatice –harware, software si ingineria proceselor.

6

Page 7


Costurile alocate programelor

Costul programelor este de obicei mai mare decat costul echipamentului pe care acestea ruleaza

Costul de dezvoltare al unui program este mai mic decat costul de intretinere al acestuia. In cazul sistemelor cu o durata mare de viata, costul de intretinere poate depasi de cateva ori costul de dezvoltare

Reducerea costurilor de dezvoltare si intretinere este una din preocuparile ingineriei programarii

7

Page 8


Costurile de dezvoltare

In cadrul unui ciclu complet de dezvoltare software ~50% sunt costuri de dezvoltare propriu-zisa, restul fiind costuri pentru testare.

Costurile depind de tipul sistemului si de cerintele de dezvoltare impuse (atat functionale cat si f ti l )nefunctionale)

Distributia costurilor este dependenta de modelul de dezvoltare folosit

8

Page 9


Costurile alocate programelor

9

Page 10


Terminologie in domeniu – legaturi intre notiuni

Software = totalitatea programelor de calculator si a documentatiei asociate (caietul de sarcini, modele de proiectare si manuale utilizator)

Produsele software pot fi dezvoltate pentru o anumita piata (produse generice) sau doar pentru un client anume

P d l ft t t lt i d lt d l 0 i iProdusele software nou create pot rezulta prin dezvoltarea de la 0 a unor noi programe, prin configurarea sistemelor software generice sau prin reutilizarea unor componente software existente

Stiinta calculatoarelor = domeniu teoretic ce se ocupa cu aspectele fundamentale ale creerii si exploatarii produselor informatice precum si ale echipamentelor pe care acestea sunt executate

Spre deosebire de stiinta calculatoarelor, ingineria programarii se ocupa cu practicile de dezvoltare si livrare de software de calitate

Ingineria sistemelor software are drept obiect toate aspectele legate de sistemele informatice (hardware, software, inginerie de proces). Ingineria software este parte a ingineriei de proces, ce se ocupa cu dezvoltarea infrastructurii de programare aspectele de control aplicatiile si bazele de dateocupa cu dezvoltarea infrastructurii de programare, aspectele de control, aplicatiile si bazele de date din sistem.

Inginerii de sistem sunt implicati in procesul creerii specificatiilor, proiectarea arhitecturala, integrare si desfasurare a produselor software.

10

Page 11


Ce este un proces software?

Un set de activitati ce au drept scop dezvoltarea sau intretinerea unui produs software

Orice proces software are un numar de activitati generice de tipul:

Crearea specificatiilor – precizarea a ceea ce sistemul ar trebui sa faca precum si a constrangerilor de dezvoltareconstrangerilor de dezvoltare

Dezvoltarea – producerea sistemului software

Validarea – verificarea gradului de adecvanta intre asteptarile clientilor si capabilitatile produsului software dezvoltat

Intretinerea – modificarea produsului ca rezultat al diferitelor cereri de schimbare

11

p

Page 12


Ce este un model al unui proces software?

O reprezentare simplificata a unui proces software prezentata dintr-o anume perspectiva

Exemple de perspective ale unui proces software:

Fluxul de activitati – workflow

Fluxul de informatie – dataflow

Corelatia rol/activitate – cine ce face

Exemple de modele de proces generice:

Modelul in cascadaModelul in cascada

Modelul dezvoltarii iterative

Modelul de inginerie software bazat pe componente

12

Page 13


Ce sunt metodologiile software?

Suma de proceduri de dezvoltare structurata a produselor software ce include modele notatii reguliSuma de proceduri de dezvoltare structurata a produselor software ce include modele, notatii, reguli, ghiduri de proiectare si de derulare a proceselor:

Modele – cel mai adesea au o descriere grafica si reprezinta schematic produsul dintr-o anumita perspectiva

Reguli – constrangeri ce sunt aplicate modelelor sistemelor

Recomandari – sfaturi privind bune practici de proiectare

Ghiduri de proces – succesiunea de activitati de desfasurat

13

Page 14


Ingineria software bazata pe calculator (Computer-Aided Software Engineering – CASE)

Ce este CASE?Ce este CASE?

Sistemele software ce ofera suport pentru automatizarea activitatilor dintr-un proces software, de regula pentru o anumita metodologie

Upper – CASE – utilitare suport pentru activitati de stabilire a cerintelor software si proiectare

Lower – CASE - utilitare suport pentru activitati tardive cum ar fi scrierea de cod, depanarea si testare.

14

Page 15


Atributele unui software de calitate

Are functionalitatea si performantele cerute de client in conditiile asigurarii unui grad inalt incredere in utilizarea produsului, maintenanta, eficienta si acceptare pe piata.

Maintenanta – modificarea produsului ca rezultat al modificarii cerintelor

Eficienta – produsul trebuie sa nu risipeasca resursele sistemului

Acceptare produsul trebuie sa fie acceptat de segmentul de piata pentru care a fost creatAcceptare – produsul trebuie sa fie acceptat de segmentul de piata pentru care a fost creat. Pentru aceasta el trebuie sa fie usor de inteles si folosit, dar si compatibil cu alte produse.

15

Page 16


Problemele majore cu care se confrunta ingineria programarii

Exista o mare diversitate de platforme si medii de dezvoltare cu diferente notabile de la una la altaExista o mare diversitate de platforme si medii de dezvoltare, cu diferente notabile de la una la alta

Dezvoltarea de tehnici pentru livrarea rapida de produse software

Dezvoltarea de tehnici care sa demonstreze ca produsele software sunt demne de deplina incredere a utilizatorului

16

Page 17


Responsabilitati profesionale si etice

Ingineria software implica responsabilitati extinse dincolo de simpla exercitare a unor abilitati tehnice

Inginerii software trebuie sa se comporte intr-o maniera onesta si cu responsabilitati etice daca doresc gastigarea respectului pe linie profesionala

Comportamentul etic implica mai mult decat aplicarea aspectelor legale intr-o maniera stricta

17

Page 18


Caracteristici definitorii ale unui comportament responsabil profesional

Confidentialitate – inginerii trebuie sa respecte confidentialitatea atat in rapor cu colegii cat si cuConfidentialitate inginerii trebuie sa respecte confidentialitatea atat in rapor cu colegii cat si cu clientii indiferent daca s-a semnat sau nu un acord scris in acest sens

Competenta – implica refuzul de a ccepta sarcini de serviciu ce depasesc compententa personala.

Drepturi de proprietate intelectuala – inginerii trebuie sa fie avertizati asupra legilor locale ce guverneaza proprietatea intelectuala (legi patentare, copyright, etc). Ei vor trebui sa se asigure ca proprietatea intelectuala a clientilor si angajatilor este protejata.

Utilizare gresita a calculatorului – inginerii software nu vor utiliza expertiza proprie in scopul utilizarii gresite a masinilor de calcul (folosire Internet in scopuri personale, jocuri pe masinile puse la dispozitia angajatilor, diseminari virusi, etc).

18

Page 19


Codul de etica

ACM (Association for Computer Machinerie)/IEEE (Institute for Electrical and Electronics Engineers)

Rod al colaborarii societatilor profesionale din statele Unite, codul de etica in practica ingineriei programarii contine 8 principii pe care se bazeaza activitatea practicienilor si teoreticienilor, formatorilor si cursantilor, managerilor si vizionarilor din domeniu.

In preambul se specifica necesitatea angajarii active si personale a celor ce activeaza in domeniul ingineriei programarii de a realiza analiza, specificarea, proiectarea, dezvoltarea, testarea si intretinerea produselor software in contextul beneficiului si respectului fata de profesie.

19

Page 20


Codul de etica

ACM(Association for Computer Machinerie)/IEEE (Institute for Electrical and Electronics Engineers)

Principiile codului de etica profesionala in ingineria software:

Interesul public – inginerii trebuie sa actioneze in mod consistent in directia interesului public;

I t l li t l i i l j t l i i i ii t b i ti i t t i di tiInteresul clientului si al angajatului – inginerii trebuie sa actioneze consistent in directia intereselor atat a clientilor cat si a angajatilor cu respecterea simultana a interesului public;

Produsul – produsele software si orice modificare a acestora vor trebui sa respecte cele mai inalte standarde posibile din domeniu;

Decizia inginerii vor trebui sa pastreze integritatea si independenta in luarea deciziilor de ordinDecizia – inginerii vor trebui sa pastreze integritatea si independenta in luarea deciziilor de ordin profesional;

Managementul – conducatorii vor trebui sa adopte metode etice de management in dezvoltarea si intretinerea produselor software;

Profesia – practicienii vor trebui sa promoveze consistent integritatea si buna reputatie a acestei p p g pprofesii, cu respectarea simultana a interesului public

Colegialitatea – inginerii trebuie sa fie corecti si sa-si ofere voluntar suportul pentru ceilalti colegi;

Atitudine personala – inginerii trebuie sa participe permanent la programe de perfectionare f i l i t d l ti d ti f i l

20

profesionala si sa promoveze metodele etice de practica profesionala.

Page 21


Codul de etica

ACM(Association for Computer Machinerie)/IEEE (Institute for Electrical and Electronics Engineers)

Dileme etice in profesia ingineria programarii:

Dezacord de principii cu politicile praticate de managementul la varf dintr-o companie;

Activitati desfasurate fara respectarea principiilor de etica profesionala de catre angajati cu livrarea sistemelor critice din punct de vedere a securitatii fara a se fi terminat fazele de testare;

Participarea in programe militare ce vizeaza dezvoltarea de armament si sisteme nucleare.

21

Page 22


Sisteme critice – definitii si caracteristici fundamentale

Sintagma critic poate referi vulnerabilitati diferite:Sisteme critice din punct de vedere al securitatii – esecul in evolutie duce la ranire sau chiar pierderi de vieti omenesti si/sau deteriorarea mediului inconjurator ( exemplu –sistem protectie pentru o intreprindere chimica)Si t i i iti l i l ti d t i l ti it ti di itSisteme cu misiune critica – esecul in evolutie determina esecul unor activitati din suita de activitati presupuse de realizarea scopului misiunii ( exemplu – sistemul de navigatie al aeronavelor)Sisteme critice din punct de vedere business – esecul in evolutia sistemului determina pierderi economice ( exemplu – sistemul de gestiune a conturilor clientilor dintr-o banca)p ( p g )

22

Page 23


Sisteme critice – gradul de dependenta

Pentru sistemele critice cea mai importanta proprietate o reprezinta dependabilitatea. Aceasta reflecta gradul de incredere al utilizatorului in acel sistem. Acest lucru inseamna ca sistemul opereaza conform asteptarilor clientului si ca nu va esua in situatii normale de functionare.de functionare.

A fi util si a fi de incredere sunt doua notiuni diferite in contextul sistemelor software. Un sistem poate fi util si in conditiile in care nu exista un grad de incredere (dependabilitate) semnificativ in acesta.Sistemele ce nu genereaza o dependenta a utilizatorului sunt nefiabile si nesigure si pot fi rejectate de catre potentialii utilizatori. Aceasta deoarece caderea sistemului poate determina pierderi importante de informatie pentru a caror recuperare costurile pot fi extrem de mari.

23

Page 24


Sisteme critice – metodologie specifica dezvoltare

Metodologia de dezvoltare a sistemelor critice este diferita de cea a sistemelor ne-critice si poate fi mult mai costisitoare in contextul adresarii unor riscuri majore specifice.

Exemple de metode de dezvoltare pentru sisteme critice:Metode formale pentru dezvoltarea sistemelor software;Analiza statica;Asigurarea din exterior a calitatii

24

Page 25


Caderea sistemelor critice

Caderea hardware – exista erori de fabricatie sau timpul de buna functionare a expirat;

Cadere software – erori in specificatii, design sau implementare;

Cadere din motive de operare – operatorul uman a realizat una sau mai multe manevre gresite ( este cea mai frecventa cauza a caderii sistemeor critice).

25

Page 26


Exemplu de sistem critic software - Pompa de insulina controlata software (1)

Caracteristici sistem:

Folosita de diabetici in stimularea pancreasului sa creeze insulina, hormon esential in metabolizarea glucozei sangvine;Masoara cantitatea de zahar (glucoza) din sange cu ajutorul unui micro-senzor si calculeaza doza de insulina necesara metabolizarii acesteia;

26

Page 27


Exemplu de sistem critic software – Pompa de insulina controlata software (2)Organizarea componentelor sistemului:

Insulin reservoir

Needleassembly

Pump Clock

Sensor AlarmController

Display1 Display2

Power supply

27

Page 28


Exemplu de sistem critic software - pompa de insulina controlata software (3)Organizarea fluxului functional al sistemului:

Blood

Blood sugaranalysis

Blood sugarsensor

Blood

Bloodparameters

Blood sugarlevel

Insulinrequirementcomputation

InsulinInsulin

Pump controlcommands InsulinInsulin

deliverycontroller

Insulinpump

Insulin commands Insulinrequirement

28

Page 29


Exemplu de sistem critic software - pompa de insulina controlata software (4)

Cerinte de dependabilitate impuse sistemului:

Sistemul trebuie sa livreze insulina ori de cate ori i se solicita acest lucru;

Sistemul trebuie sa functioneze in conditii de fiabilitate crescuta si sa livreze cantitatea corecta de insulina necesara anihilarii glucozei din sange;

Cea mai importanta cerinta de siguranta impusa – sa nu se livreze niciodata o doza excesiva de i li d i t i t l i i i linsulina deoarece ar pune viata pacientului in pericol;

Cerinta de dependabilitate impusa sistemului echivaleaza cu gradul de incredere acordat acestuia de catre utilizatori ( in cazul nostru pacienti cu diabet).

29

Page 30


Dimensiuni ale dependabilitatiiPrincipalele dimensiuni ale dependabilitatii sunt:

Disponibilitatea

Fiabilitatea

Siguranta

Securitatea

Dependability

Availability Reliability SecuritySafety

The ability of the systemto deliver services when

requested

The ability of the systemto deliver services as

specified

The ability of the systemto operate withoutcatastrophic failure

The ability of the systemto protect itelf against

accidental or deliberateintrusion

30

Page 31


Alte caracteristici ale dependabilitatii

Reparabilitatea – reflecta in ce masura sistemul poate sa-si recupereze valentele operationale in contextul producerii unui eveniment de cadere in functionareMaintenabilitatea – reflecta in ce masura sistemul poate fi adaptat la noi cerinte;Maintenabilitatea – reflecta in ce masura sistemul poate fi adaptat la noi cerinte;

Este un atribut static al sistemului legat de usurinta repararii sistemului dupa o cadere sau de modificare a sistemului pentru a include noi caracteristiciEste de importanta deosebita pentru sistemele critice deoarece, in mod frecvent, problemele de maintenanta introduc erori in sistemproblemele de maintenanta introduc erori in sistem

Supravietuirea – reflecta masura in care sistemul poate furniza servicii pe perioada cat se afla sub influenta unui atac ostil

Atacurile pot fi accidentale sau deliberateEste un atribut semnificativ pentru sistemele distribuite ce isi pot compromiteEste un atribut semnificativ pentru sistemele distribuite ce isi pot compromite securitateaSubsumeaza notiunea de rezilienta a sistemului definita ca abilitate a sistemului de a-si continua operarea chiar si la caderea unor componente

Toleranta la eroare – reflecta masura in care erorile de intrare pot fi inlaturate sau tolerate

31

Toleranta la eroare – reflecta masura in care erorile de intrare pot fi inlaturate sau tolerate

Page 32


Costurile dependabilitatii

Cresc exponential odata cu cresterea nivelului de dependabilitate dorit din 2 motive:

Se utilizeaza hardware si tehnici de dezvoltare mai scumpeSe depun eforturi sporite pentru testare si validare cu scopul convingerii clientului ca s-a atins nivelul dorit de dependabilitate

Datorita costurilor mari pentru dezvoltarea de sisteme dependabile, uneori se prefera crearea de sisteme cu un grad de incredere mai ic, platindu-se ulterior costurile remedierii unui sistem ce a cazutPentru crearea/mentinerea reputatiei unei companii se prefera ca in anumite conditii sa se suporte costurile dezvoltarilor cu grad de dependabilitate maresuporte costurile dezvoltarilor cu grad de dependabilitate mareDependabilitatea depinde de tipul de sistem dezvoltat – pentru un sistem business se accepta si un grad de incredere moderat

32

Page 33


Disponibilitatea si fiabilitatea sistemelorFiabilitatea – reprezinta probabilitatea cadere a sistemului in conditiile operarii in mediu, timp si scop specificate.Disponibilitatea – probabilitatea ca sistemul la un anumit moment de timp dat sa fieDisponibilitatea – probabilitatea ca sistemul la un anumit moment de timp dat sa fie operational si sa furnizeze serviciile cerute.

Obs. Ambele atribute pot fi exprimate cantitativ.Uneori este posibila includerea disponibilitatii in cadrul fiabilitatii sistemului – este evident ca un sistem cazut nu livreaza serviciile cerute.ca un sistem cazut nu livreaza serviciile cerute. Exista situatii in care se cere disponibilitatea pentru un sistem cu fiabilitate scazuta; atata timp cat caderile sistemului pot fi reparate repede si nu duc la deteriorarea datelor, o fiabilitate scazuta poate sa nu reprezinte o problema.Disponibilitatea ia in calcul si timpul cat dureaza reparatiile. p p p

33

Page 34


Terminologie din domeniul fiabilitatiiCadere sistem = eveniment ce apare la un moment de timp si impiedica sistemul sa livreze serviciile solicitateEroare sistem = o stare eronata a sistemului ce deterina comportarea acestuia intr-oEroare sistem = o stare eronata a sistemului ce deterina comportarea acestuia intr-o maniera neasteptata pentru utilizatoriDefect sistem = o caracteristica a unui sistem ce poate conduce la aparitia unei erori in sistem. De exemplu defectul neinitializarii unei variabile poate determina folosirea unei valori gresite a acesteia pe parcursul executiei unui sistem software.Eroare/ greseala umana = comportare a operatorului uman ce determina introducerea de defecte in sistem.

34

Page 35


Defecte si caderi ale sistemelor

Caderile sunt o consecinta uzuala a erorilor sistemului ce apar ca urmare a aparitiei defectelor in sistem.Cu toate acestea, un defect nu determina implicit o eroare in sistem.

O stare defecta poate fi temporara si corectata inaintea producerii unei eroriO stare defecta poate fi temporara si corectata inaintea producerii unei erori.Erorile nu determina, in mod necesar, caderea sistemului.

Erorile pot fi corectate prin detectare si recuperare de tip build-in.Facilitatile de protejare build-in p j

35

Page 36


Perceptii ale fiabilitatii

Definitiile formale ale fiabilitatii nu reflecta, adesea, perceptia utilizatorului, , p pIpotezele presupuse pentru mediul de evolutie a sistemului pot fi incorecte (folosirea unui sistem intr-un birou este probabil foarte diferita de folsirea lui intr-un mediu universitar)Consecintele caderii sistemului afecteaza perceptia asupra fiabilitatii

Caderea motorului unui autovehicul este perceputa cu o pondere sporita in raport cu alte caderiO instalatie de umidificare are o functionare irelevanta intr-un mediu uscat

36

Page 37


Realizari ale fiabilitatii

Evitarea defectiunilor – tehnicile de dezvoltare vor urmari minimizarea sau reducerea greselilor inainte ca acestea sa introduca defectiuni in sistemDetectarea si inlaturarea defectelor – folosirea acelor tehnici de verificare si validare ce cresc probabilitatea de detectie si corectare a erorilor inainte de livrarea pe piata a produsului

f fToleranta le defecte – se folosesc in dezvoltare tehnici run-time ce ce impiedica defectele sistemului sa determine aparitia de rezultate eronate si/sau erorile sistemului sa conduca la caderea acestuia

37

Page 38


Modelarea fiabilitatiiModelarea fiabilitatii

Se poate recurge la un model intrare-iesire al sistemului, unde unele intrari vorproduce iesiri eronate (Fig.1)Fiabilitatea sistemului reprezinta probabilitatea ca o intrare particulara sa apartinadomeniului de intrari ce produc functionare defectuoasaDeoarece sistemul poate fi folosit diferit de diferiti utilizatori, aceasta probabilitate nueste un atribut static al sistemului, depinzand de mediul acestuia (Fig.2).

Inputs causing

Possibleinputs

User1

Erroneousinputs

IeInput set

Inputs causingerroneous outputs

User3

User2

OeOutput set

Program

Erroneousoutputs

38

Fig.1 Fig.2

Page 39


Imbunatatirea fiabilitatii

Inlaturarea a X% din erorile sistemului nu va determina in mod necesar crestereaInlaturarea a X% din erorile sistemului nu va determina in mod necesar cresterea

fiabilitatii cu X% ( de ex. Un studiu IBM a demonstrat ca eliminarea a 60% din

defectele unui produs va imbunatati fiabilitatea acestuia doar cu 3%)

Defectele dintr-un program pot sa existe in zone rar executate, astfel incat sa nu fie

intalnite de utilizatori. Eliminarea acestor erori nu va fi perceputa ca o crestere a

fiabilitatii

Un program cu erori cunoscute poate totusi sa fie acceptat ca fiabil de catre

utilizatorii sai.

39

Page 40


SigurantaSigurantaEste o proprietate a unui sistem ce reflecta abilitatea acestuia de a opera, normal sau anormal, fara a pune in pericol vieti omenesti si/sau mediul inconjurator.Este extrem de util sa analizam siguranta produselor software deoarecedin ce in ce mai multe dispozitive incorporeaza sisteme sotfware de controlmai multe dispozitive incorporeaza sisteme sotfware de control Cerintele de siguranta specifica situatiile indezirabile si nu servicii solicitate sistemuluiSistemele critice din punct de vedere al sigurantei se clasifica in:

Sisteme primare – sistem incorporate a caror cadere provoaca caderi hardware si, in consecinta, afecteaza oameniSisteme secundare – sistemele ce prin cadere determina caderea altor sisteme ce, la randul lor, pot ameninta siguranta factorului uman

Fiabilitatea si siguranta sunt legate dar reprezinta notiuni diferite:Fiabilitatea se ocupa de conformanta la specificatii a unui anumit serviciuSiguranta urmareste ca sistemul sa nu produca accidente indiferent daca se conformeaza sau nu specificatiilor

40

Page 41


Sisteme fiabile si nesigure

Si t l i i ifi tii i t i t l t f i t l dSistemele cu erori in specificatii – in acest caz sistemul se poate conforma cerintelor dar sa produca accidente

Caderi hardware ce genereaza intrari neasteptate – greu de anticipat in specificatii

Comenzi dependente de context – determina erori de operare umana, cum ar fi cazul unei comenzi corecte data la un moment gresitcomenzi corecte data la un moment gresit

Terminologie specifica:

Hazard – conditie ce poate sa produca un accident (ex. Caderea unui senzor ce ar trbui sa detecteze obstacolele din fata unei masini)

Ha ard l este caracteri at prin se eritate (care este cea mai mare stricaci ne ce poate fiHazardul este caracterizat prin severitate (care este cea mai mare stricaciune ce poate fi produsa) si probabilitate de producere a conditiei asociate.

Asigurarea sigurantei

Evitarea hazardului

Detectia si inlaturarea hazardului inainte de asi produce efectele negative

Limitarea stricaciunilor

Accidentele din sistemele complexe au cauze multiple, in contextul in care acestea au fost proiectate sa fie reziliente la caderi singulare. Atingerea sigurantei complete este un deziderat imposibil de atins

41

imposibil de atins.

Page 42


SecuritateaProprietate ce reflecta abilitatea unui sistem de a se proteja impotriva atacurilorexterne accidentale sau deliberate.Securitatea reprezinta a cerinta obligatorie pentru atingerea disponibilitatii, fiabilitatiisi sigurantei, mai ales in contextul operarii unui sistem in reteaProblema asigurarii securitatii porneste de la ipoteza ca sistemul dezvoltat esteacelasi cu cel ce se executa in conditii normale de operare. Trebuie avut in vedere,insa, ca o intruziune poate modifica sistemul ce se executa si/sau datele sale. Dinacest punct asigurarea fiabilitatii si sigurantei nu mai pot fi asumate.

Consecinte ale insecuritatii:Refuzul unui serviciu – sistemul este fortat sa intre intr-o stare in care serviciile normal nu mai sunt disponibile sau mecanismul de furnizare a acestora este degradat semnificativgCorupere de programe/date – modificare neautorizata de programe/dateExpunerea de informatii confidentiale – date gestionate exclusiv de catre sistem devin accesibile in citire/modificare de catre persoane neautorizate

42

Page 43


Asigurarea securitatiig

Evitarea vulnerabilitatilorVulnerabilitate – slabiciune a sistemului ce poate fi exploatata in vedereaproducerii de pierderiproducerii de pierderiSistemul este proiectat astfel incat vulnerabilitatile sa nu apara (ex. Nu existaconexiune cu reteaua)

Detectia si eliminarea atacurilor – atacurile asupra vulnerabilitatilor vor fi gasite sieliminate inainte de a produce posibile pierderi/coruperi in sistem (ex. Antivirus)

Limitarea efectelor negative ale expunerii la atacuri – determina minimizarea efectelori t it ( liti il d b k )unui atac reusit (ex. politicile de backup)

43

Documents

Curs 1_Introducere in Ingineria Programarii