Sunteți pe pagina 1din 17

Inginerie software

Ingineria software este disciplina inginereasc ce urmrete dezvoltarea


sistemelor software cu un raport bun pre-calitate.
De-a lungul anilor, ncepnd cu 1968, atunci cnd termenul a fost utilizat pentru
prima dat, au fost dezvoltate noi metode i tehnologii pentru proiectarea de soft i
controlul acestuia proces, mai ales datorit complexitii inerente a sistemelor software
actuale.
Aceste metode, rezultate din conectarea calculatoarelor i a sistemelor de
comunicaii au condus ctre apariia unor noi provocri pentru inginerii software.
Un sistem software, de obicei, const dintr-un numr de programe separate, fiiere
de configurare, documentaie de sistem, ce descrie structura unui sistem, documentaia
utilizatorului, ce definete utilizarea sistemului, precum i pagini web pentru utilizatori,
utilizate pentru descrcarea celor mai recente informaii referitoare la produs.
n ceea ce privete produsele software, acestea pot fi mprite n dou categorii:
- Produse generice Sisteme de sine stttoare ce sunt produse de o organizaie
de dezvoltare i vndute pe piaa liber ctre orice client. n aceast categorie, pot
intra software-ul pentru calculatoarele personale, de exemplu: baze de date,
procesoare de text, pachete de desenare, instrumente de marketing, etc.
- Produse aplicative Aceste produse sunt comandate de un anumit client. Un
dezvoltator software produce acest produs doar pentru acel client. Exemple de
asftel de produse sunt: tipuri de software ce includ sisteme de control pentru
echipamente electronice, sisteme scrise pentru procese particulare cum ar fi
controlul traficului aerian i auto.
Trebuie precizat c delimitarea dintre cele dou tipuri de produse, de multe ori, nu
este foarte clar. Multe companii, productoare de soft, produc un sistem generic, dup
care acesta este particularizat n funcie de cerinele unui anumit client.
Activitile specifice unui proces de producere a soft-ului pot fi grupate astfel:
- Specificaiile soft-ului n aceast etap inginerii i clienii definesc soft-ul ce
va fi produs, precum i constrngerile n producerea acestuia
- Dezvoltarea soft-ului este etapa de proiectare i programare
- Validarea soft-ului etapa de verificare a ndeplinirii cerinelor clientului
- Evoluia soft-ului n aceast etap soft-ul este modificat pentru a se adapta la
schimbrile i cerinele pieei.
Un model al procesului de producere a soft-ului este o descriere simplificat,
incluznd activiti ce sunt parte constituent a procesului, a produselor soft, precum
i a oamenilor implicai n ingineria software.
Cele mai multe modele se bazeaz pe unul dintre cele trei modele generale ale
dezvoltrii de soft, i anume:
- Abordarea de tip cascad (waterfall) activitile sunt reprezentate ca i faze de
proces separate, cum ar fi: specificaiile cerute, proiectarea software,
implementarea, testarea, etc. Dup terminarea fiecrei etape, se trece la urmtoare,
s.a.m.d.
- Dezvoltarea iterativ aceast abordare intercaleaz activitile de specificare,
dezvoltare i validare. Un sistem iniial este dezvoltat pe baza unor specificaii
abstracte. Acesta, este apoi prelucrat pe baza intrrilor furnizate de un client
pentru a produce un sistem ce satisface nevoile acestuia. Odat cu distribuirea
sistemului, poate fi reimplementat pentru obinerea unui sistem robust i uor de
ntreinut prin utilizarea unei abordri mai structurale
- Inginerie software bazat pe componente aceast abordare presupune c deja
exist anumite pri ale sistemului. Etapa de dezvoltare a soft-ului se concentreaz
pe integrarea acelor pri, i nu pe dezvoltarea acestora de la zero.
Ingineria software bazat pe computer (CASE) acoper o gam larg de programe
diferite ce sunt utilizate pentru a susine activitile procesului de producere a soft-ului,
de exemplu: analiza cerinelor, modelarea sistemului, depanare i testare. Toate metodele
actuale utilizeaz aceast tehnologie, i anume: editoare pentru notaii, module de analiz
ce verific modelul sistemului n concordan cu regulile impuse i generatoare de raport,
utilizate n creare documentaiei de sistem. Instrumentele CASE, pot include, de
asemenea, un generator de cod ce genereaz n mod automat cod surs de la modelul
sistemului, precum i anumite sugestii pentru inginerii software.
Modelul de tip cascad
Principalele etape ale modelului cuprind urmtoarele activiti fundamentale de
dezvoltare:
1. Analiza i definirea cerinelor prin consultarea utilizatorilor sunt stabilite
serviciile de sistem, constrngerile i scopul. Apoi, se realizeaz detalierea
acestora, constituind specificaiile sistemului.
2. Proiectarea sistemului i a soft-ului se proiecteaz componentele proceselor,
necesare altor sisteme hardware sau software. Se stabilete o arhitectur general
a sistemului. Proiectanii soft-ului identific i descriu sistemul soft fundamental,
precum i relaiile ce apar.
3. Implementarea i unitatea de testare n aceast etap, este realizat proiectarea
soft-ului printr-un set de programe sau uniti de program. Unitatea de testare
verific dac fiecare unitate ndeplinete specificaiile sale.
4. Integrarea i testarea sistemului unitile de program individuale sunt integrate
i testate ca un sistem ntreg pentru a asigura faptul c cerinele soft-ului au fost
ndeplinite. Dup testare, sistemul soft este transmis cumprtorului.
5. ntreinere i operare sistemul este instalat i dat n folosin. ntreinerea
implic corectarea erorilor care nu sunt descoperite n etapele precedente ale unui
ciclu de via, mbuntirea implementrii unitilor sistemului.
Din punct de vedere teoretic, fazele descrise anterior nu ar trebui s fie realizate
pn cnd faza anterioar nu s-a terminat. n practic, ns, aceste faze se suprapun,
folosind informaii de la celelalte etape.
Procesul de producere a soft-ului implic, deci, o secven iterativ a activitilor
de dezvoltare. Datorit costului generat de producia i aprobarea documentelor, dup un
numr mic de iteraii este normal nghearea anumitor pri ale dezvoltrii, cum ar fi
specificaiile. Aceast oprire permatur a ndeplinirii cerinelor poate conduce la
nendeplinirea specificaiilor clientului.
n timpul fazei finale a ciclului de via (operare i ntreinere), soft-ul este pus n
funciune. Erorile i omisiunile din cerinele iniiale sunt descoperite. Ies la suprafa
erorile de programare i proiectare, precum i nevoia de noi funcionaliti. Pentru a
rmne util este nevoie ca soft-ul s evolueze. ntreinerea soft-ului poate implica
repetarea etapelor anterioare.
Avantajul modelului n cascad este legat de faptul c documentaia este produs
la fiecare etap i se potrivete cu alte modele ale proceselor inginereti. Dezavantajul
major este legat de inflexibilitatea n ceea ce privete partiionarea proiectului n etape
distincte. Prin urmare acest model ar trebui utilizat doar atunci cnd cerinele sunt
nelese i este puin probabil modificarea radical a acestora n timpul dezvoltrii
sistemului. Procesele software bazate pe aceast abordare sunt, nc, utilizate pentru
dezvoltarea software, n particular cnd proiectul software este parte a unui proiect mare
de ingineria a sistemelor.
Dezvoltarea iterativ
Dezvoltarea unei versiuni iniiale, transmis clientului este urmat de mai multe
versiuni, mbuntite, pn cnd sistemul adecvat este dezvoltat. Figura urmtoare
prezint acest tip de abordare.

Specificaii Versiune
iniial

Dezvoltare Versiuni
Descriere intermediare
schematic

Validare Versiune
final

Figura 1.
Exist dou tipuri de dezvoltare iterativ:
1. Dezvoltare exploratorie n care unul dintre obiectivele procesului este lucrul cu
clientul, n ideea de a descoperi necesitile acestuia i a oferi versiunea final a
sistemului. Dezvoltarea ncepe cu acele pri de sistem ce nu sunt nelese.
Sistemul evolueaz prin adugarea de noi funcionaliti propuse de client.
2. Dezvoltarea de prototipuri unde obiectivul este acela de a nelege necesitile
clientului, i, n consecin de a dezvolta o definire mult mai bun a cerinelor
pentru sistem. Prototipurile se axeaz pe experimentarea necesitilor mai puin
nelese ale clientului.
O astfel de abordare pentru dezvoltarea soft-ului este de multe ori mai eficient
dect abordarea n cascad, deoarece specificaiile pot fi dezvoltate incremental.
Dezavantajele acestei abordri sunt:
- procesul nu este vizibil Administratorii au nevoie de livrabile la intervale
regulate. Dac sistemul este dezvoltat rapid, atunci nu este eficient din punct de
vedere al costului s produc documente care reflect fiecare versiune a
sistemului.
- Sistemul este adeseori foarte slab structurat modificrile continue au tendina
de a corupe structura soft-ului. ncorporarea modificrilor devine mai dificil i
costisitoare.
Ingineria software bazat pe componente
n majoritatea proiectelor de producere a soft-ului, exist o reutilizare a unor
anumite pri de soft. Spre exemplu, dac se dorete proiectarea unui soft i exist deja
cod scris, similar cu acela, atunci se realizeaz o modificare a acestuia, precum i o
ncorporare n noul sistem. Ingineria software bazat pe componente folosete aceast
operaie de reutilizare a codului.
Aceast abordare se bazeaz pe reutilizarea la scar larg a componentelor
software, precum i a cadrului de integrare a acestor componente. Componentele sunt fie
proprietatea dezvoltatorului de soft, fie comerciale, asigurnd anumite funcionaliti cum
ar fi formatarea de text sau calcule numerice.
Descrierea formal a acestei abordri este prezentat n figura urmtoare:

Specificaiile Analiza Modificarea Proiectarea


cerinelor componentei cerinelor sistemului cu
reutilizare

Dezvoltare i Validarea
integrare sistemului

Figura 2.
1. Analiza componentei date fiind specificaiile cerinelor, se realizeaz o cutare a
componentelor ce implementeaz aceste specificaii. De obicei, nu exist o
potrivire exact. Componentele care se reutilizeaz asigur doar anumite
funcionaliti.
2. Modificarea cerinelor n aceast etap, cerinele sunt analizate folosind
informaii despre componentele gsite. Apoi, acestea sunt modificate, iar dac
modificarea nu este posibil, activitatea de analiz a componentei poate fi
repornit pentru cutarea unor soluii alternative.
3. Proiectarea sistemului cu reutilizare aceast etap presupune proiectarea
cadrului de lucru pentru sistem, sau este reutilizat un cadru de lucru existent.
Proiectanii consider componentele care sunt reutilizate i organizeaz cadrul de
lucru n consecin. Anumite poriuni de soft trebuie proiectate innd cont c
anumite componente reutilizabile nu sunt disponibile.
4. Dezvoltare i integrare soft-ul ce nu poate fi procurat dintr-o surs extern, este
dezvoltat, iar componentele sistemului sunt integrate pentru a crea noul sistem.
Integrarea sistemului, n aceast abordare, poate fi parte a procesului de
dezvoltare, mai degrab dect o activitate separat.
Metoda prezentat are avantajul de a reduce cantitatea de soft ce trebuie
dezvoltat, i, prin urmare, de a reduce costurile i riscurile. Totui, compromiterea
cerinelor este inevitabil, putnd conduce ctre un sistem care nu ndeplinete
necesitile reale ale utilizatorilor. Mai mult, o parte a controlului asupra evoluiei
sistemului este pierdut innd cont c noile versiuni ale componentelor reutilizabile nu
sunt sub controlul organizaiei care le utilizeaz.
Setul specific de atribute al unui sistem software, este dependent de aplicaie,
putnd fi generalizat n urmtoarele patru caracteristici:
- Mentenabilitate Soft-ul ar trebui scris astfel nct s poat evolua n funcie de
modificrile aduse de client.
- Fiabilitate Fiabilitatea software cuprinde un set de caracteristici ce includ
autenticitate, securitate i siguran.
- Eficien Resursele sistemului (procesor, memorie) trebuie utilizate n mod
corespunztor. Prin urmare aceast caracteristic include timpul de rspuns,
timpul de procesare, utilizarea memoriei, etc.
- Utilizabilitate Soft-ul trebuie s fie utilizabil, fr prea mare efort, de ctre
utilizatorii normali. Existena unei interfee a utilizatorului i a unei documentaii
adecvate sunt cerine minimale.
Prin definiie un sistem este o colecie de componente interdependente ce lucreaz
mpreun pentru atingerea unor anumite obiective. Sistemele ce includ software pot fi
grupate n dou categorii:
- Sisteme tehnice bazate pe computer sunt sistemele ce includ doar componente
hardware i software, fr proceduri sau procese. Aceast categorie poate include sisteme
tv, telefoane mobile, precum i majoritatea soft-urilor utilizate de calculatoarele personale.
- Sistemele socio-tehnice ce includ unul sau mai multe sisteme tehnice, dar, de
asemenea includ i cunotine despre utilizarea sistemului n vederea obinerii anumitor
rezultate. Acest tip de sisteme includ operatori umani ca i pri componente, fiind
guvernate de politici organizaionale i reguli, putnd fi afectate de constrngeri
referitoare la legi i politici de reglementare.
Sintetiznd, ingineria software este activitatea de specificare, proiectare,
implementare, validare, dezvoltare i meninere a sistemelor socio-tehnice. Inginerii
implicai n aceast direcie nu se axeaz doar pe software, dar i pe hardware, precum i
pe interaciunile sistemului cu utilizatorii i cu mediul su. Acetia trebuie s ia n
considerare serviciile pe care sistemul le furnizeaz, constrngerile sub care sistemul este
construit i trebuie s funcioneze, precum i modul n care sistemul i ndeplinete
scopul. Figura 3 prezint fazele procesului de inginerie a sistemelor, conceput ca i model
n cascad.
Definirea Dezafectarea
cerinelor sistemului

Proiectarea Evoluia
sistemului sistemului

Dezvoltarea sub- Instalarea


sistemelor sistemului

Integrare
Figura 3. sistemului
Aa cum s-a precizat ingineria sistemelor este o activitate interdisciplinar,
implicnd echipe de lucru ce provin din diverse domenii. Acestea sunt necesare pentru
necesarul vast de cunotine necesar n proiectarea sistemului. Spre exemplu, un sistem
de monitorizare a traficului aerian, ce utilizeaz radare i ali senzori implic conlucrarea
dintre ingineri din 8 domenii diferite, aa cum se observ n figura 4.

Inginerie Inginerie Inginerie


software electronic mecanic

Inginerie n Inginerie Proiectarea


construcii aeronautic interfeei
(monitorizare utilizator
trafic aerian)

Arhitectur
Inginerie
civil
Inginerie
electric

Figura 4.

Definirea cerinelor de sistem


Definirea cerinelor de sistem specific ce ar trebui s fac sistemul (definirea
funciilor acestuia), precum i a proprietilor de sistem dorite i eseniale. Trei tipuri de
necesiti pot fi definite:
- Necesiti funcionale abstracte. Funciile de baz pe care sistemul trebuie s le ofere
sunt definite la un nivel abstract. Specificaiile necesare, funcionale sunt detaliate la
nivelul sub-sistemului.
- Proprietile sistemului. Acestea sunt proprieti sistemice nefuncionale, cum ar fi:
disponibilitatea, performana i sigurana. Aceste proprieti nefuncionale afecteaz
necesitile pentru toate subsistemele.
- Caracteristici pe care sistemul nu trebuie s le dezvolte. De cele mai multe ori trebuie
specificat ce ar trebui i ce nu s fac sistemul.
O parte important a acestei faze este stabilirea unui set de obiective generale pe
care sistemul ar trebui s le ndeplineasc.
Proiectarea sistemului
Proiectarea sistemului este axat pe modalitatea de asigurare a funcionalitii
sistemului prin intermediul componentelor sale. Activitile, aa cum sunt prezentate n
figura 5, sunt:
- Necesitile partiiei se realizeaz analiza necesitilor, acestea fiind, apoi,
organizate n grupuri corespunztoare. Partiionarea se poate realiza n mai multe
moduri posibile.
- Identificarea subsistemelor trebuie identificare subsistemele ce pot ndeplini
cerinele, individual sau mpreun.
- Repartizarea necesitilor ctre subsisteme dac etapa precedent a fost riguros
realizat, atunci, aceast etap poate fi uor de ndeplinit.
- Specificarea funcionalitilor subsistemului trebuie specificate funciile oferite de
fiecare subsistem. De asemenea, trebuie identificate relaiile dintre subsisteme.
- Definirea interfeelor corespunztoare subsistemelor trebuie definite interfeele ce
sunt oferite i cerute de fiecare subsistem. Odat ce interfeele au fost definite, este
posibil dezvoltarea acestor subsisteme n paralel.

Definirea interfeelor
specifice subsistemelor
Necesitile
partiiei

Specificarea
Identificarea funcionalitii
subsistemelor subsistemelor

Repartizarea necesitilor
ctre subsisteme

Figura 5
Modelarea sistemului
Pe parcursul activitii de proiectare a sistemului i definire a necesitilor,
sistemul poate fi modelat ca un set de componente i relaii ntre aceste componente.
Arhitectura sistemului poate fi prezentat ca o diagram bloc, n care sunt
prezentate principalele subsisteme, precum i interaciunile dintre acestea.
De exemplu, figura 6 prezint un sistem de alarmare, prin componentele sale
principale.

Senzori de Senzori
micare pentru u

Controller de
alarmare

Siren Sintetizator Linie de Centrul extern de


de voce apelare control

Figura 6
Principalele funcii ndeplinite de subsistemele descrise anterior pot fi sintetizate,
astfel: Senzorii de micare detecteaz micarea n camerele monitorizate de sistem,
Senzorii pentru u detecteaz deschiderea uilor exterioare ale cldirii, Controllerul de
alarmare realizeaz controlul tuturor operaiilor din sistem, Sirena emite semnale sonore
de alarmare dac un intrus este detectat, Sintetizatorul de voce realizeaz transmiterea
unui mesaj vocal, transmind locaia intrusului, Linia de apelare realizeaz transmiterea
de apeluri n exterior ctre poliie, agenie de securitate, etc.
Prin urmare, fiecare subsistem trebuie reprezentat, pn cnd sistemul este
descompus n componente funcionale, ce asigur realizarea unei singure funcii.
Modelul arhitecturii sistemului este utilizat pentru identificarea componentelor
hardware i software care pot fi dezvoltate n paralel. Totui, abordrile actuale folosesc
capabilitile de calcul nglobat (embedded). De exemplu, un echipament de conexiune n
reea este alctuit att din cabluri, ct i din repetoare i pori (gateway). Repetoarele i
porile includ procesoare i software, precum i componente electronice specializate.
La acest nivel, trebuie realizat o clasificare a subsistemelor n concordan cu
funciile ndeplinite nainte de luarea deciziilor n ceea ce privete stabilirea unui
compromis ntre hardware i software.
Diagramele bloc pot fi utilizate chiar i pentru descrierea sistemelor complexe. La
rndul lor, anumite subsisteme pot fi la rndul lor sisteme mari.
Figura urmtoare prezint subsistemele implicate, precum i conexiunile dintre
acestea, ntr-un sistem de control a traficului aerian.

Sistem radar Transpoder Sistem de Sistem de Sistem


comunicaii comunicaii telefonic
al datelor al aeronavei

Procesor pentru Procesor pentru Procesor pentru Procesor pentru


determinarea determinarea comunicaii comunicaii
poziiei poziiei (rezerv)
(rezerv)

Sistem de Baz de date ce


simulare al conine orarul
aeronavei zborurilor

Sistem pentru
monitorizarea
condiiilor meteo

Controllerul
Sistem sistemului Controllerul
financiar informaional consolelor

Sistem de
nregistrare al
activitii
Figura 7
Integrarea sistemului
Procesul de integrare a sistemului presupune alturarea subsistemelor dezvoltate
individual. Integrarea poate fi realizat printr-o abordare de tipul big-bang n care, toate
subsistemele sunt integrate n acelai timp. Totui, din cauza unor considerente tehnice si
manageriale integrarea subsistemelor trebuie realizat incremental.
Aceast abordare are dou avantaje:
- este aproape imposibil planificarea dezvoltrii tuturor subsistemelor astfel nct
acestea s fie terminate n acelai timp.
- integrarea incremental reduce erorile. Dac mai multe subsisteme sunt integrate
simultan, o eroare aprut n etapa de testare poate fi n oricare dintre subsisteme.
Dup etapa de integrare, are loc etapa de testare a sistemului. Se vor testa
interfeele dintre componente, precum i comportarea sistemului n ansamblul su.
Erorile sistemului sunt depistate n acest etap. n anumite situaii, nu exist o
dezvoltare separat a subsistemelor, prin urmare etapa de integrare este chiar faza de
implemantare a sistemului.
Evoluia sistemului
Sistemele mari, complexe au o durat mare de via. n acest timp, acestea sufer
modificri pentru corectarea erorilor aprute n sistemul iniial i pentru implementarea
unor noi funcionaliti.
Progresul tehnologic, cerinele utilizatorului de sistem, condiiile de mediu n care
sistemul lucreaz sunt factori ce determin schimbrile produse n sistem.
Desigur, evoluia sistemului este, n mare msur, determinat de evoluia
tehnologiei hardware i software.
Dezafectarea sistemului
Dezafectarea sistemului se produce dup expirarea perioadei sale de operare.
Dezafectarea hardware presupune casarea echipamentelor, n timp ce pentru dezafectarea
soft-ului nu exist o procedur fizic.
Desigur, componentele dezafectate ale unui sistem, pot fi integrate ntr-un alt
sistem. De asemenea, datele dintr-un sistem dezafectat, pot fi reutilizate, prin convertire,
ntr-un alt sistem. Aceast reutilizare, atrage dup sine o reduce considerabil a
sistemului nou creat.
Sistemele motenite (legacy systems)
Sistemele motenite sunt sisteme computerizate, socio-tehnologice, ce au fost
dezvoltate n trecut, adesea cu tehnologie veche sau nvechit. Aceste sisteme includ nu
numai hardware i software, dar i proceduri i procese nvechite. Sistemele motenite
sunt sisteme critice. Acestea sunt meninute, deoarece este prea riscant schimbarea
acestora. Utilizarea acestor sisteme, dei nvechite, se poate face din mai multe motive:
nc ofer utilizatorilor cerinele dorite, compatibilitatea cu formatul fierelor i
codificarea caracterelor, dificultile inerente n administrarea schimbrilor ce se produc
n timp, etc.
Sisteme critice
Sistemele critice sunt acelea n care defeciunile conduc ctre pierderi economice
importante, distrugeri fizice sau ameninri asupra vieii umane. Trei tipuri de sisteme
critice pot fi evideniate:
1. Sisteme critice de siguran sunt sistemele a crui cdere conduce
ctre rnire, pierderea vieii sau deteriorarea mediului. Un exemplu de
astfel de sistem este sistemul de control al unei instalaii de produse
chimice.
2. Sisteme critice orientate pe scop sunt acele sisteme n care
defeciunile pot conduce ctre nendeplinirea unor activiti specifice,
de exemplu sistemul de navigare al unei aeronave.
3. Sisteme critice financiare defectarea unui astfel de sistem poate
conduce ctre costuri mari n afacerile ce utilizeaz acel sistem. Un
exemplu de astfel de sistem este sistem de cont bancar dintr-o banc.
Cea mai important proprietate a unui sistem critic este fiabilitatea. Acesta rezid
din urmtoarele considerente:
- Sistemele care nu sunt de ncredere, nesigure sau neprotejate sunt de cele mai multe
ori refuzate de utilizatorii si. Prin urmare, aceste sisteme nu sunt vandabile.
- Costurile legate de stricarea sistemului pot fi foarte mari. De exemplu, defectarea
unui sistem de control a unui reactor este mult mai mare dect costul unui sistem de
control.
- Sistemele care nu sunt de ncredere pot determina pierderea informaiei. Colectarea
i ntreinerea informaiilor este, de cele mai multe ori, mult mai valoroas dect
echipamentul pe care acestea sunt procesate. O soluie, n acest caz este utilizarea
unor copii de siguran pentru datele procesate.
Pentru dezvoltarea sistemelor critice trebuie utilizate tehnici i metode de
ncredere, testate, neeficiente din punct de vedere al costului. De exemplu, metode
matematice formale au fost utilizate pentru dezvoltarea sistemelor critice de securitate i
siguran.
Pentru sistemele critice, costul verificrii i validrii poate depi 50% din costul
total al dezvoltrii. Costul acestor sisteme este determinat i de necesitatea existenei
operatorilor care s se ocupe cu rezolvarea situaiilor neprevzute ce pot s apar n
sistem.
Sistemele critice se pot defecta ca urmare a urmtoarelor componente de sistem:
- Defeciunile hardware pot s apar ca urmare a unor greeli n etapa de proiectare,
datorit erorilor de fabricaie sau pentru c anumite componente i-au atins limita
maxim de funcionare.
- Defeciunile software pot s apar datorit specificaiilor greite, proiectrii sau
implementrii defectuoase.
- Defeciunile introduse de operatorii umani, ce utilizeaz incorect sistemul.
Un exemplu tipic de sistem critic este preluat din ingineria medical i vizeaz
tratarea bolnavilor de diabet.
Diabetul este o afeciune caracterizat prin faptul c pancreasul este incapabil s
produc suficient insulin. Tratamentul convenional const n injectarea la intervale
bine stabilite a unei anumite doze de insulin, pe baza nivelului de zahr din snge.
Problema ce apare n acest mod de abordare este c nivelul insulinei din snge, depinde
nu numai de nivelul glucozei din snge dar i de momentul n care insulina a fost
injectat. Acest lucru poate conduce fie la un nivel sczut al glucozei (dac este prea
mult insulin), fie un nivel ridicat al zahrului din snge (dac este prea puin insulin).
Ambele situaii sunt critice, pe termen lung sau scurt, pentru viaa pacientului.
Tehnologiile actuale (senzori miniaturizai) au fcut posibil dezvoltarea unui
sistem automat de distribuire a insulinei. Aceste sisteme monitorizeaz nivelul zahrului
din snge i distribuie doza corespunztoare de insulin, atunci cnd este necesar. Astfel
de sisteme exist, n prezent, n spitale. Pe lng componentele hardware ale sistemului,
exist i o component software n strns legtur cu achiziia datelor de la pacient,
determinarea dozei necesare de insulin i transmiterea unor semnale (comenzi) ctre o
pomp miniaturizat ce distribuie insulin prin intermediul unui ac, ataat permanent.
Parametrii
Snge Senzor pentru sngelui Analizarea zahrului
determinarea zahrului din snge
din snge Nivelul zahrului
din snge

Determinarea
necesarului de
insulin

Comenzi Necesarul
Insulin Pomp de ctre pomp Controllerul de
insulin repartizrii insulinei insulin

Figura 8.
Sistemele critice de siguran sunt sistemele n care operarea este totdeauna sigur,
iar acestea nu ar trebui niciodat s rneasc persoane sau strice mediul, chiar dac apare
un defect. Exemple de astfel de sisteme sunt cele de monitorizare n aeronautic,
sistemele de control al proceselor chimice, n industria auto, etc.
Controlul hardware al sistemelor critice de siguran este uor de implementat i
analizat. Desigur, sistemele actuale, complexe, nu pot fi controlate doar la nivel hardware.
Este necesar un control software, datorit numrului mare de senzori i elemente de
execuie ce trebuie administrate.
Dou categorii de soft-uri critice de siguran pot fi evideniate:
1. Soft-uri critice de siguran, primare acestea sunt nglobate ca i
controller ntr-un sistem. Proasta funcionare a unui astfel de software conduce ctre
defeciuni hardware, conducnd ctre rnirea utilizatorilor sau deteriorarea mediului.
2. Soft-uri critice de siguran, secundare astfel de sisteme pot fi cele de
proiectare prin intermediul calculatorului, a cror proasta funcionare poate conduce ctre
defeciuni de proiectare ale obiectului proiectat. Sistemul poate cauza rnirea
utilizatorilor, dac proiectarea este prost realizat.
Pentru asigurarea siguranei i prevenirea accidentelor sau limitarea efectelor
acestora, se pot avea n vedere urmtoarele proceduri:
- Evitarea hazardului sistemul este proiectat astfel nct hazardul s fie evitat.
- Detecia i nlturarea harzardului sistemul este proiectat astfel nct riscurile sunt
detectate i nlturate nainte de producerea unui accident.
- Limitarea pagubelor sistemul poate include elemente de protecie care limiteaz
pagubele ce pot rezulta ca urmare a unui accident.
Sistemele controlate prin soft pot monitoriza o gam larg de condiii, fa de
sistemele electrice i mecanice, putnd crete sigurana sistemelor. Se pot adapta rapid, i
pot furniza conexiuni de siguran complicate, oferind strategii de control ce reduc timpul
petrecut de oameni n medii cu potenial risc.
Securitatea
Securitatea este un atribut al sistemului ce reflect abilitatea acestuia de a se
proteja de atacurile externe deliberate sau accidentale. Securitatea a devenit mai
important odat cu conectarea sistemelor la Internet.
Securitatea este un atribut esenial al sistemelor critice. Fr un nivel de securitate
adecvat, disponibilitatea, fiabilitatea i sigurana sistemului poate fi compromis prin
atacurile externe ce produc avarii.
Erorile n dezvoltarea sistemului pot conduce ctre bree n siguran. dac
sistemul nu rspunde la intrri neprevzute sau limitele irurilor de date nu sunt verificate.
Sistemele militare, sistemele pentru comer electronic, i sistemele ce implic
procesarea i interschimbarea informaiilor confideniale trebuie proiectate astfel nct s
aib un nivel ridicat de securitate.
Trei tipuri de avarii pot fi cauzate prin intermediul atacurilor externe, i anume:
1. Refuzul serviciilor (denial of service) sistemul este forat s intre ntr-o
stare unde serviciile sale normale nu sunt disponibile. Disponibilitatea
sistemului este astfel afectat.
2. Coruperea programelor sau a datelor componentele software ale sistemului
pot fi alterate ntr-un mod neautorizat. Acest lucru poate afecta
comportamentul sistemului, i prin urmare fiabilitatea i sigurana.
3. Dezvluirea informaiilor confideniale Informaia administrat de sistem
poate fi confidenial, iar atacurile externe pot compromite acest lucru. Acest
tip de atac poate afecta sigurana sistemului, dar i prin atacuri ulterioare,
disponibilitatea i fiabilitatea sistemului.
Pentru asigurarea securitii unui sistem, se pot utiliza i urmtoarele abordri:
- Evitarea vulnerabilitii Sistemul este proiectat astfel nct vulnerabilitile s
nu apar. De exemplu, sistemul nu este conectat la o reea public, astfel nct
atacurile externe nu sunt posibile.
- Detectarea atacurilor i neutralizarea Sistemul este proiectat s detecteze
vulnerabilitile i s le nlture nainte ca acestea s fie exploatate. De exemplu,
un soft de verificare a prezenei viruilor i analiza fiierelor de intrare.