Sisteme Critice

Cuprins

1.Introducere -Louise Mühlbächer

2. Dezvoltarea sistemelor critice -Bogdan Malai

3. Validarea și verificarea sistemelor critice -Cosmin Mosteanu

4.Protectia sistemelor critice -Louise Mühlbächer

5.Bibliografie

1.Introducere

Orice sistem software care poate ‘eșua’/funcționa prost și amenința viața umana sau produce pagube organizației care folosește sistemul se poate numi un sistem software critic.

Exemple de sisteme critice pot fi:

Sisteme de comunicare , cum ar fi telefon,sisteme de comutare , sisteme radio de aeronave , etc.

Sisteme de control integrate pentru instalații industriale, dispozitive medicale , etc.

Sisteme de comandă și de control cum ar fi de trafic aerian,sisteme de control , sisteme de gestionare a dezastrelor ,etc.

Sistemele financiare , cum ar fi de schimb valutar,sisteme de tranzacție , de administrare a contului, etc.

Astfel,se pot distinge trei categorii de sisteme critice,în funcție de efectele pe care acestea le au:

Sisteme de siguranță critice, care,prin proasta lor funcționare,amenință integritatea vieții umane și a planetei.

Sisteme de scop critice,care,prin poroasta lor funcționare,nu poate îndeplini scopul activității.

Sisteme economice critice care,prin proasta lor functionare,poate produce pagube financiare organizației care folosește sistemul.

Atributele stării critice sunt următoarele:

Fiabilitate

• Preocupată cu incapacitatea de a efectua conform specificațiilor

  Disponibilitate

• Preocupată cu incapacitatea de a furniza serviciile necesare

Mentenabilitate

• Preocupat cu capacitatea sistemului de a evolua

Siguranță

• Preocupată cu un comportament care amenință în mod direct sau indirect viața umană

Securitate

• Preocupat cu capacitatea sistemului de a proteja atributele stării critice

Sistemele critice sunt din ce în ce mai răspândite pe masură ce crește complexitatea societății și a activităților automatizate. Nu sunt multe sisteme critice complet automatizate,majoritatea fiind controlate și monnitorizate de către oameni. Așadar,oamenii(operatori) au un rol important deoare ce pe de o parte ei pot cauza probleme dar le și pot rezolva/redresa pe cele neprevăzute în sistem.

În afară de utilizarea incorectă a sistemului de către operatori,sistemul mai poate ceda din cauza sistemului hardware(erori de fabricatie,defectarea componentelor etc) sau a software-ului(greseli de proiectare,de punere in aplicare etc).

Cheltuielile pentru producerea sistemelor software sunt imense.Costul este influențat de cerințele impuse pentru funcționarea acestuia. De asemenea, timpul mare de viață și frecventele modificări cerute pentru menținerea sistemului sau pentru adăugarea unor noi facilități vor mări costurile generale iar cu cât produsul soft este mai complex, mai mare, cu atât costurile totale vor crește.

Costul de defactare pe care il au sistemele critice poate depasi chiar 50% din totalul costului întregului sistem.

Tocmai de aceea este foarte important ca posibilitatea de aparitie a erorilor sa fie cat mai redusa,sa fie minimă,lucru pe care designerii de sisteme critice trebuie sa aibă în vizor.

2. Dezvoltarea sistemelor critice

In ultimul timp s-a creat o tendinta pentru companii de a-si transforma sistemele software intr-o forma mai incrementala folosing un principiu un ciclu de viata special pentru dezvoltarea sistemelor software mai agil. Aceste procese au fost folosite si inainte, dar procesele agile au adaugat o noua planificare de proiect si noi principii de management.

Avantajele pentru o dezvoltare iterativa :

-riscul redus

-riscul timpuriu este mai scazut

-gazduieste si provoaca schimbari timpurii

-sistemele au o complexitate gestionabila

-datorita succeselor repetate creste increderea echipelor

-productie partial timpurie

-previzibilitate mai buna

-mai putine defecte si calitate mai inalta

-produsul final se potriveste mai bine cu cerintele clientilor

-reglarea procesului

-angajamentul si comunicarea sunt necesare

Procesele agile moderne ofera mai multe beneficii in comparatie cu cele iterative si anume:

-lansarile sunt mai frecvente si timpul este mai redus

-procesul este mai lin datorita unei comunicari mai bine

-clientul participa mai mult

Clientul beneficiaza cel mai mult de avantajele lansarii timpurii si de intelegerea sistemului deoarece il poate folosi din timp. Toate organizatiile, publice si private, au schimbat modelele lor in cascada cat si cele cu incrementare cu modele de proiecte agile. Acest lucru s-a intamplat in toate domeniile de dezvoltare. Sistemele agile au fost folosite in mare parte in proiectele mai mici, proiectele mari fiind in faza de cercetare.

Dezvoltarea sistemelor critice pentru siguranta se gaseste in asemenea arie. Ele se clasifica dupa urmatoarele criterii:

-tipul sistemului si produsului – dispositive medicale, central nucleare etc.

-rolul software-ului in sistem

-dimensiunile si scopul sistemului

-nivelul de risc al sistemului

Anatomia dezvoltarii agile

Sistemele software agile sunt alcatuite din urmatoarele elemente:

-principii

-model de proiect

-ciclul de viata pe care il are sistemul software

-tehnicile, practicile si metodele ingineresti software

Principiile constau in modelele de gandire ale persoanelor profesionale. Modelul de proiect este modul planificatii proiectului si bine inteles al executiei lui. O mare parte a executiei proiectului este dezvoltarea ciclului de viata software caruia I se potriveste sistemului respective. Practicile ingineresti software sunt:

-arhitectura

-manipularea dependentelor dintre cerinte

-bunul simt, ingrijirea si gandirea

-fundamente de utilizare

-documentare

Orientari pentru a face procesul mai agil

Cerinte preliminare – dezvoltarea agila este un mijloc de satisfacere a afacerilor sau a altor obiective. Pentru orice schimbare intr-o organizatie, ar trebui sa fie un scop si un sens clar, comun de urgenta, pentru a modifica procesele precum si un sentiment ca modul actual de actiune nu mai este suficient.

Procesul de intelegere solida si viziune

Ar trebui sa existe o intelegere a proceselor de dezvoltare a produsului si a software-ului care sa ajute la intrebarea : timtim spre o abordare echilibrata sau o agilitate maxima? Scopul principal este sa obtina cele mai bune rezultate, nu de a fi agil.

Profesionalism in actiune

Abordarea traditionala privind schimbarea unui proces poate provoca haos si esec. Inainte de transformare ar trebui ca organizatia sa ia masura de indeplinire a cerintelor IEC 61508 sau bine inteles si alte standard aplicabile in aceasta situatie. Calitatea activitatilor curente ar trebui sa fie ridicata si executia procesului current, profesionala. Daca nu este cazul, modificarea nu ar trebui incercata.

Expertiza si colaborare

O expertiza amanuntita este necesara pentru a ghida personalul in procesul de transformare. Sunt necesari si consultant pentru acest process care sa conduca transformarea. Este de notat ca acesti consultant care se ocupa de sistemele agile nu inteleg neaaparat toate principiile de conducere de siguranta , cerintele procesului de dezvoltare critica si gestionarea riscurilor.

Notiuni generale de orientare pentru dezvoltarea unui proces:

-respectati-va propriile experiente si abilitatile de inginerie in procesul de dezvoltare

-trebuie inteles ca “mai agil” nu inseamna mereu “mai bun”

-cu cat un sistem este mai critic cu atat este mai important sa existe un control mai mare pentru process ceea ce inseamna mai putina agilitate

-nicio paradigm unica nu este suficienta deoarece fiind doar agil nu va gi niciodata sufficient

-pentru ca sistemele sa fie sigure si critice este necesara o gestiune amanuntita a riscurilor

-“Gasiti stilul cel mai potrivit pentru dumneavoastra” este mesajul in toate dezvoltarile. Daca te porti ca toata lumea, cum poti fi cel mai bun din bransa ta?

-cooperarea si colaborarea dintre partile interesate este o problema cheie a sistemelor critice. Aceeasi regula se aplica si pentru procesul de dezvoltare

Strategie pas cu pas

O strategie este de a pune in aplicare prima data cateva practivi permissive si alte elemente de procese care aduc beneficii oricarui process de dezvoltare. Acestea includ:

-asigurarea codului de calitate si unitati de testare mai amanuntita

-integrare continua, astfel incat sa existe mereu un produs de lucru la indemana pentru a putea evalua modul in care se comporta

-automatizare de testare-automatizarea cat mai multor sarcini posibile

-automatizarea proceselor agile

-o urmarire automatizata

Claritatea regulilor

Sistemul critic impune reguli clare pentru success iar libertarea este mereu cea mai buna in cazul constrangerilor, de aceea este nevoie de urmatoarele informatii:

-detinatorul produselor si afacerii

-detinatorul procesului de dezvoltare

-principiile de dezvoltare a produsului

-cantarirea opiniilor partilor interesate

-deschiderea fata de client

-angajamentul subcontractantilor

Comunicare si colaborare

Se doreste sa existe comunicare pentru ca oamenii sa invete constant si trebuie sa fie creat un mediu propice ca sa se intample asta.

Este necesara mai multa auto-reflexie in acest process. Toti participantii trebuie sa se uite frecvent in produs si in process pentru a putea vedea ce trebuie imbunatatit. Asta solicita lectii frecvente/retrospectiva intalnita in process

Team-building si o echipa de conducere mai buna. Echipele trebuie sa fie capabile sis a invete sa lucreze ca o echipa. Pentru a invata sa conduci o echipa sa colaboreze necesita timp

Imbunatatirea instrumentelor de comunicatii. Orice lucru care ajuta oamenii sa comunice mai bine furnizeaza un mediu mai linistit pentru a indeplini sarcinile

Imbunatatirea comunicarii dintre site-urile distribuite. Nicio parte nu trebuie sa aiba un rol secundar in comunicare

Asigurarea eficientei in consumul de timp

Pentru a avea o eficienta crescuta in consumul de timp, procesele trebuie sa fie dezvoltate astfel incat validarea si certificarea sa fie foarte eficiente.

Crearea de procese externe in afara procesului incremental principal de dezvoltare

Intelegerea clara a orelor la care sarcinile legate de validare trebuie sa fie effectuate

A face o distinctive foarte clara intre nivelurile critice pentru siguranta si alte cerinte si nivelele SIL, astfel incat elementele care necesita validare sau revalidare pot fi identificate exact

Sisteme eficiente de informare, astfel incat orice documente, rutine sau gasirea si inregistrarea verificarii dezvoltarii sa nu ia timp

Aranjamente flexibile pentru validare. In cazul in care se utilizeaza validatoare externe, situatia poate fi reevaluata

Asigurarea controlului

Pentru asigurarea controlului se au in vedere urmatoarele problem:

Divizarea cerintelor in elemente mai mici, cu scopul de a ajuta la estimare si planificare

Imbunatatirea reuniunilor

Creare sisteme de informare si tablouri de bord pentru o vizualizare a starii proiectului

Impartirea procesului

Factorii principali pentru dezvoltarea procesului pot fi impartiti in mai multe iteratii:

Un lant de evenimente care decurg de la planificare pana la evaluarea realizarilor

Urmarind atingerea fiecarei incrementari

O planificare amanuntita la inceputul fiecarei incrementari

Utilizarea practicilor reale de dezvoltare a produsului in definirea cerintelor

Adaugarea practicilor care aduc valoare

Pentru noile idei de dezvoltare de procese se gasesc mai multe zone:

Stiinta software

Dezvoltarea noilor proiecte

Analiza sigurantei, siguranta si gestionarea riscului

Testarea

Gestionarea calitatii

Comunicatia

Gestionarea informatiei

Controlul procesului

Imbunatatirea continua

Imbunatatirea continua are un rol foarte important in orice organizatie. Procesele sunt optime numai intr-un context anume iar imbunatatirea procesului se continua, rezolvand toate problemele una cate una.

3. Validarea și verificarea sistemelor critice

3.1 Noțiuni generale

Verificarea și validarea reprezintă procesele prin care se stabilește dacă un produs software îndeplinește cerințele inițiale și îndeplinește scopul pentru care a fost dezvoltat.“ Împreună aceste doua procese se regăsesc sub denumirea controlul calității software. Este important de știut că verificarea și validarea nu sunt același lucru, cu toate că adese ori sunt confundate.

Pe scurt, verificarea asigură că produsul a fost dezvoltat corect , pe când validarea confirmă dacă produsul îndeplinește sau nu scopul pentru care a fost dezvoltat. Un produs este considerat validat dacă satisface nevoile consumatorului. Validarea presupune asigurarea că procesele de dezvoltare și verificare duc la realizarea unui produs ce respectă necesitațile si specificațiile inițiale. În cazul apariției unei probleme în cadrul procesului de dezvoltare sau verificarea, va fi necesară modelarea problemei folosind procedurile de validare (ce presupun si simulări) pentru a evita procesele invalide sau incomplete de dezvoltare/verificare. „Exista si proceduri de validare auxiliare care asigura ca o data ce a fost modelată problema inițială, produsul finit va respecta cerintele inițiale.”

Pe scurt , validarea poate fi definita prin intrebarea “Construiesc produsul potrivit?

Iar verificare: Construiesc corect produsul?”

Validarea este etapa in care beneficiarul accepta sau nu produsul. Beneficiarul nu este interesat de metodele prin care s-a obtinut produsul final.Utilizatorul este in cea mai mare parte interesat de structura programului,de fiabilitatea acestuia cat si de complexitate si de adaptarea la nevoile sale.Beneficiarul va testa programul pentru a obtine rezultatele obtinute cu date reale nu cu unele experimentale.

Verificarea este o faza care incepe inca de la proiectarea programului si se termina in ultima faza de predare a produsului.

– analiza specificațiilor;

– inspectarea proiectării

– executia algoritmilor folositi in conceperea progamului

– testarea produsului final;

Verificare și validarea sistemelor critice are foarte multe in comun cu validarea oricariu alt produs . Procesele de V&V ar trebui sa demonstreze ca sistemul isi indeplineste functiile si sunt respectate toate cerintele utilizatorului.

Scopul final al V&V este să stabilească încrederea că sistemul software se potrivește scopului său. Nivelul de încredere depinde de scopul sistemului, de așteptările utilizatorilor și de mediul de marketing:

.Funcția software. Daca soft-ul este foarte necesar pentru forma vom avea discuta de un nivel critic,odata ce necesitatea produsului pentru firma respectiva scade,va scadea proportional si nivelul critic al produsului

Așteptările utilizatorilor. Utilizatorii nu se asteapta ca mereu produsul software sa fie in cele mai bune limite de functionare. Se intelege nevoia de feedback pentru producatori,deoarece acestia din urma vor putea imbunatati performantele produsului in functie de ceririle utilizatorului.

Mediul de marketing. Odata ce produsul esta dat spre vanzare va trebui sa se aiba in vedere raportul dintre pretul acestuia si calitatile lui. Când utilizatorii nu sunt dispusi să plăteasca un pret mai ridicat, ei pot fi dispuși să tolereze mai multe erori.

In procesul de V&V există 2 abordări complementare pentru sistemul de inspecție și analiză:

Inspecții de softare care analizează și verifică reprezentarea sistemului în documentație, diagrame de design și cod sursă. Acestea sunt tehnici statice de V&V, iar pentru a se asigura de buna functionare a produsului acestea nu vor avea nevoie de rularea acestui produs;

Testarea software spre deosebir de inspectiile de test,testarea software implica testarea soft-ului cu anumite date de test si se asteapta rezultate. Aceste rezultate pot avea o marja de eroare deoarece produsul nu este in ultimul stadiu de dezvoltare.

Sistemul se poate testa doar atunci când există un prototip sau o versiune executabilă a programului.

Verificarea si validarea sunt realizate pentru a se evidentia erorile de sistem.

Debugging-ul este un proces care localizează defectele și le corectează;

Localizarea defectelor într-un program nu este întotdeauna un proces simplu, pentru că defectul poate să nu fie aproape de locul unde programul se defectează.

După ce un defect a fost descoperit, el trebuie corectat și sistemul trebuie revalidat. Se testează faptul că acestă corecție nu a introdus erori noi în sistem..

3.2 Planificarea verificării și validării

Verificarea și validarea sunt procese costisitoare. Pentru unele sisteme, cum ar fi cele in timp real cu constrangeri nefuncționale complexe, mai mult de jumătate din bugetul de dezvoltarea a sistemului este cheltuit pe V&V. O planificare ingrijită este necesară pentru a obtine maximul din testare si inspecție și pentru a controla costurile procesului de verificare și validare.

model de dezvolate sistem software

Planificarea verificării și validării trebuie pornită la faza de inceput in care se afla proiectul initial. In figura de mai sus este prezentat modelul pentru dezvoltarea unui produs soft.

Din procesul de planificare V&V fac parte decizia privind raportul de tehnici de abordare statice și dinamice pentru validare și verificare, definirea de standarde și proceduri pentru inspecția software-ului, și definirea planului de testare.

Planificare testarii ajuta managerii sa aloce resursele necesare pentru dezvoltarea aplicatiei, cat si inginerii care sunt implicati in testare sau in designul aplicatiei. Planificarea testarii este concentrata asupra stabilirii standardelor pentru procesul de testare cat si asupra descierii testelor implicate in testarea produsului.

Structura unui plan de testare software:

Procesul de testare :

Urmărirea cerintelor

Componentele testate

Programul de testare

Inregistrarea procedurilor de testare

Cerintele hardware si software

Constrângeri

Activități de verificare pe parcursul ciclului de viață

Documentul de cerințe software este verificat față de documentul de cerințe utilizator, conform sectiunii SR din planul de verificare și validare.

„ADD – SRD”

„DDD –ADD”

„Code –DDD” Unit tests „verifică faptul că modulele software funcționează corect ca entități independente, conform specificației din DDD și secțiunii UT din SVVP.”

„Integration tests” „System tests” „Acceptance tests”

Acestea sunt reprezentate in schema de mai jos.

Sursa foto: http://software-document.blogspot.ro/2011/06/software-verificatio-introduction.html

3.3. Metode de validare:

1.Validare în perspectivǎ reprezintă activitațile desfǎșurate înainte ca articolele noi sǎ fie lansate pentru a se asigura caracteristicile de interes pentru ca produsul sa functioneze corect si sigur.

.2.Validare retrospectivǎ Este valabila pentru articolele deja date in uz, acestea fiind resupune la testele initiale sau specifice pentru probleme intimpinate in timp de catre utilizatori.

.3.Validare curentǎ are loc concomitent cu procesul de proiectare/dezvoltare.

3.3.1. Validarea sistemelor critice

Verificare și validarea sistemelor critice are, evident, multe în comun cu validarea oricărui alt sistem. Procesele de V&V ar trebui să demonstreze că sistemul își îndeplinește specificațiile și că sunt realizate toate cerintele utilizatorului. Totuși, pentru sisteme critice, unde este nevoie de o mare fiabilitate, teste și analize adiționale sunt necesare pentru a putea concluziona că sistemul este de încredere. Sunt două motive pentru care ar trebui făcut acest lucru:

Costul esecului: Costurile esecului sunt cu atat mai mari cu cat sistemul are o prioritate mai mare pentru firma. Pentru a atenua aceste costuri, manageri vor acorda timp pentru testarea produsului, deoarece costurile pentru testare sunt mult mai mici decat cele care vor aparea dupa scoaterea produsului pe piata

Validarea fiabilității atributelor: pentru garantarea faptului că sistemul își îndeplinește cerințele de fiabilitate trebuie oferite documente oficiale; acest lucru necesită activități V&V specifice; in anumite cazuri va fi nevoie de documente aparte pentru a garanta fiabilitatea produselor. De exemplu intr-o firma de proiectare de matrici vom avea nevoie de garantii ca produsele folosite vor oferi siguranta lucratorilor cat si faptul ca isi vor indeplinii functiile pentru care au fost create.

Pentru aceste motive, costurile V&V pentru sisteme critice sunt de obicei mult mai mari decât pentru alte clase de sisteme.

3.3.2. Validarea fiabilitatii

Un numar de metode de masură au fost dezvoltate pentru a specifica cerințele de fiabilitate ale unui sistem. Fiabilitate produsului trebuie testata de utilizator pentru a se putea pronunta in favoarea acestor cerinte. In urmatoare schema vom reprezenta procesul de masurare al fiabilitatii:

Acest proces implica 4 etape:

Se începe cu studiul sistemelor existene de același tip pentru a stabili profilul operațional;

Se va construi un set de date care face referire la profilul operational;

Se testează sistemul folosind aceste date și se numară câte erori apar; va fi inregistrat si timpul de aparitie al erorilor

Fiabilitate produsului software se va calcula dupa inregistrarea unui numar semnificativ de erori care vor aparare in urma testarii sistemului.

Această metoda se numeste testare statistică. In urma acestei metode se va stabili fiabilitate produsului. Principalele dificultăți întâlnite in practica apar datorită:

Incertitudinii profilelor operaționale

Costurile crescute ale generării de date

Incertitudinea statistică atunci cand avem evoie de o fiabilitate mai mult decat buna

Pentru un rezultat favorabil se va folosii un generator de date care va fi setat sa ofere intrarile pozitive pentru profilui operational selectat.

3.3.3 Predicția fiabilității

Funcția treaptă este unul dintre cele mai simple modele care pun in lumina modul de dezvoltare a fiabilitatii. Odata ce un set de erori este descoperit fiabilitate va creste cu o constanta. Modelul presupune ca update-ul produsului software va fi mereu implementat si ca la urmatorul update numarul de erori va scadea.

În practică totuși, erorile din software nu sunt întotdeauna reparate în debugging și când se modifică un program se adaugă erori noi. Pentru un update de soft probabilitate ca eroarea initiala sa fie corectata este mai mica ca aceea de a aparea noi erori.

Modelele dezvoltate ulterior iau în considerare aceste considerente prin introducerea elemetului aleator în creșterea fiabilității. Fiecare reparație nu mai rezultă într-o îmbunătățire egală a fiabilității. Modelele prezentate pot duce si la scaderii fiabilitatii atunci cand update-urile vor aduce noi erori.

Vom putea prezice actuala fiabilitate prin comparatia cu alte fiabilitati masurate anterior cu un model cunoscut.

3.4. Metode de verificare:

4.1. Recenzii;

4.2. Verificări formale.

Recenzii (Reviews) –proiectul va fi examinat de personalul care a creat produsul pentru a arata publicului calitatile acestuia cat si defectele.

Tipuri de recenziilor:

1) .Analiza codului

2). Inspecțiile software

3) Prezentări (Walkthrough)

4). Recenziile tehnice

5). Auditurile informatice

4.1.2. Inspectii de software

Inspecția de software este un proces static al V&V în care sistemul software este revăzut pentru a găsi erori, omiteri și anomalii.

In general,inspecțiile se concentrează pe codul sursă, dar orice reprezentare citibilă a software-ului, așa cum ar fi cerințele sau design-ul, pot fi inspectate. Atunci când se inspectează un sistem, se folosesc cunoștințele despre acel sistem, despre domeniul de aplicare și despre limbajul de programare.

Parametrii inspectiei tehnice

Ideea de inspectie nu este chiar noua. Există mai multe studii și experimente care demonstrează că inspecția este mai eficientă pentru descoperirea de defecte decât testarea.

Fagan a apreciat că mai mult de 60% dintre erori dintr-un program pot fi detectate utilizând inspecții informale de program.

Mills a sugerat că o abordare mai formală a inspecției bazată pe corectitudinea argumentelor poate detecta 90% dintre erorile dintr-un program.

3.4.1.3. Prezentări (Walkthrough)

Acest tip de verificare este utilă în evaluarea tdin timp a documentelor, a modelelor cat si a codului. Prezentarea produsului software se va efectua pentru a se identifica problemele aparute in urma dezvoltarii si pentru a se pune in discutie solutii pentru rezolvarea acestor probleme.Prezentarile,spre deosebire de celelalte faze mai au un efect secundar,acela de a educa publicul in folosirea aplicatie si inovarea acesteia.

3.4.2 Verificarea formală

Metodele formale de dezvoltare de software sunt bazate pe reprezentarea matematică a software-ului, în mod uzual ca o specificare formală. Aceste metode formale sunt în principal concentrate pe analiza matematică a specificațiilor, cu transformarea specificațiilor într-o reprezentare echivalentă, dar mai detaliată sau pe verificarea echivalentelor între formele de reprezentare.

Se poate spune că metodele formale sunt cele mai avansate metode de verificare statică. Ele au nevoie de analize detaliate ale specificațiilor de sistem și ale programului. Utilizarea lor este adesea scumpă și consumatoare de timp. În consecință, ele sunt folosite în dezvoltarea software-ului pentru sigurantă sau pentru situații critice.

Argumetul pentru utilizarea specificațiilor formale este acela că ele obligă o analiză detaliată a specificațiilor.

Argumentul împotriva utilizarii specificațiilor formale este acela că utilizează notații specializate.

In anumite cazuri utilizarea metodelor formale conduc la dezvoltarea unor sisteme mai fiabile și mai sigure. Nu este nicio îndoială că specificațiile de sistem formale au o șansă mai mica de a conține anomalii care trebuie rezolvate, dar acest lucru nu este o garanție că software va fi fiabil 100% în utilizarea practică.

Verificarea formalǎ pentru software include mai multe tipuri de verificări:

1.Modelul checking;

2.Inferența logică;

3.Derivarea de program.

3.4.2.1. Model checking

Metoda model checking constǎ în explorarea sistematicǎ si exhaustivǎ a modelului matematic. Acest mode de lucru poate opera pe variabile finite cat si pe variabile infinite, deoarece cele infinite sunt considerate teoretic ca fiind finite

Problema care este rezolvata de acest model consta in faptul ca se va verifica daca modelul verifica o anumita specificatie data.Pentru a rezolva aceasta problema se va construi un limbaj matematic specific.

Model checking-ul este un automat cu stǎri finite

Etapele modelului :

– Se specifică proprietățile produslui soft și se traduc în limbaj C;

– Deoarece programul poate fi complex, se folosește abstracția în verificare. Acest lucru se realizeazǎ prin tehnica program cicling.

– Se va formula programul(C,C++) pentru predicatele din specificatii.

– Se calculeaza multimea starilor din programul prezentat la punctul anterior.

– Dacǎ se depisteaza erori se vor genera contraexemple și noi predicate;

3.4.2.2. Inferența logicǎ

O altǎ abordare este reprezentatǎ de inferența logicǎ care constǎ in folosirea unei versiuni formale a unui raționament matematic. In principiu se vor folosii teoreme(axiome) precum HOL, ACL2, Isabelle, Coq. Instrumentele mai noi precum Perfect Developer și Escher C Verifier incearcǎ sǎ automatizeze complet procesul. Logica liniarǎ și cea temporalǎ poate fi folosita la interfata logica,dar modelul check-ingului nu va vi singurul model unde se va putea aplica aceasta logica

3.4.2.3. Derivarea de program

O alta metoda este reprezentată de derivarea de program. Aceasta medota pleaca de la specificatiile functionale, dupa care se vor urma o serie de pasi pentru a se conserva corectitudinea.

4.Protecția sistemelor critice

Sistemele critice de siguranță sunt acele sisteme a căror proastă funcționare poate duce la ranirea chiar și la pierderea de vieti umane.

Sistemele critice pentru siguranță definesc cinci niveluri de condiții de avarie la care software-ul ar putea contribui:

catastrofale,

periculoase(hazard),

majore,

minore,

nici un efect.

Se pot încadra in 3 categorii:

Mishap(sau accident):un eveniment sau o secvență de evenimente neplanificate care pot cauza ranirea unei persoane sau moartea ei,

Incident:un esec al sistemului care se poate transforma în accident,

Hazard:o condiție care poate cauza sau contribui la un incident.

Exemple:

Accident de mașină rezultat în urma unui esec al sistemului de frânare:

Hazard: software de control a frânei defect

Incident:mașina nu frânează atunci când șoferul apasă pedala de frânare

Accident:mașina părăsește drumul si se isbește de obstacol.

Administrarea dozajului incorect de medicament în urma unui eșec in instrucțiunile de operare:

Hazard:asistenta medicală urmează un set de instrucțiuni eronate utilizare a medicamentului livrat de catre sistem

Incident:dozare incorectă a medicamentului calculata de către sistem

Accident:dozajul incorect de medicament livrat bolnavului

Siguranța se poate realiza prin evitarea hazardului – dezvoltarea sistemul astfe încat sa fie conform specificațiilor;asigurarea că pericole nu duc la incidente – adăugarea in sistem a funcționalitaților de a detecta și corecta pericolele(hazardul);evitarea accidentelor-adăugarea de caracteristici sistemului,furnizarea unei copii de rezervă sistemului de frânare;reducerea șanseleor ca accidentele să ducă la rănirea oamenilor prin adăugarea protectiei sistemului-adăugarea centurilor de siguranță și a airbag-urilor.

Design-ul unui asemenea sistem trebuie să aibă la bază faptul ca nu cedează de la o singură eroare,el fiind cat de poate de tolerant.Accidentele de asemenea nu apar de la un singur esec al unei parti componente ci de la mai multe esecuri simultane ale mai multor parti ale sistemului(sub-sisteme) iar esecul in interactiunile intre acestea sunt greu de anticipat.

IEC 61508 este un standard de "generic", destinat să satisfacă nevoile în toate domeniile de activitate. Este un document mare, format din șapte părți și un total de aproximativ 400 de pagini.

Partea 1 (Cerințe generale) definește activitățile care urmează să fie desfășurate în fiecare etapă a ciclului de viață precum și cerințe pentru documentare, conformitatea cu standardul,management și evaluare a siguranței.

Partea 2 (Cerințe pentru Electrice / Electronice / programabil Electronic (E / E / PE) Sisteme de siguranță similare) și partea 3 (Cerințe Software) abordează cerințele generale din partea 1 contextul de hardware și software. Acestea sunt specifice la faza 9 a ciclului de viață de siguranță global, ilustrat în Figura 1.1 de mai jos.

Partea 4 (Definiții și abrevieri) oferă definiții ale termeni utilizați în standard.

Partea 5 (Exemple de metode pentru determinarea nivelurilor de siguranță integrată) oferă exemple de analiză a riscurilor și demonstrează alocarea nivelurilor de integritate de siguranță.

Partea 6 (Orientări privind aplicarea părțile 2 și 3) oferte indicații cu privire la titlul.

Partea 7 (Prezentare de tehnici și măsuri) prevede scurt descrieri ale tehnicilor utilizate în siguranță și inginerie software,precum și trimiteri la surse de informații mai detaliate despre ele.

În orice aplicație dat, este puțin probabil că întreaga standardul ar fi

fie relevante. Astfel, un aspect important al utilizării inițială este de a defini părțile corespunzătoare și clauzele.

În mod ideal, ar trebui să fie folosit ca bază pentru scrierea mai specific (de exemplu, specific domeniului și specific aplicației) a altor standarde, dar este, de asemenea, destinat să fie utilizat direct în cazul în care acestea specificatii suplimentare nu exista. A devenit o cerință a multor clienți, și principiile sunt percepute ca definind o mare parte din ceea ce se consideră a fi bune practici-management al siguranței.

Scopul standardului IEC61508

IEC 61508 nu este doar un ghid tehnic.

Într-adevăr, primul său subiect este managementul siguranței, și esste de la sine înțeles faptul că abordează aspectele tehnice implicate în proiectarea și dezvoltarea sistemelor. Standardul urmărește să introducă managementul siguranței și siguranța ingineriei, nu numai în software-ul și ingineria de sistem, dar, de asemenea, în gestionarea tuturor aspectelor sistemelor. Standardul cuprinde întregul ciclu de viață al unui sistem, de la concept la dezafectare.

Funcții de risc și de siguranță pentru a proteja sistemul împotriva lor

Deși standardul se limitează în mod oficial la acele aspecte de securitate care depind de hardware și software-ul de electrice / electronice / programabile sisteme electronice (E / E / PE), principiile sale sunt generale și formează un cadru pentru abordarea tuturor aspectelor legate de siguranța toate sistemele.

Ciclul de viață global al siguranței(Figura 1.1)este crucial pentru standardul IEC 61508. Nu numai că oferă un model a etapelor managementului de siguranță în viața unui sistem, dar aceasta formează, de asemenea, structura pe care standardul în sine se bazează.

Astfel,cerințele sunt prezentate în ordinea definită de etapele de ansamblu a ciclul de viață de siguranță.

Scopul ciclului de viață global de siguranță este de a forța siguranța să fie abordată independent de probleme funcționale, depășind astfel presupunere că fiabilitatea funcțională va produce în mod automat siguranță.Apoi, precizând cerințele speciale de siguranță le permite să fie validate independent de funcționalitate, oferind astfel încrederea de siguranță în toate condițiile de funcționare și de eșec. Paradoxul,cu toate acestea, este faptul că activitățile de siguranță nu ar trebui să se efectueze, sau să fie total deconectat de la alte proiecte sau activități operaționale.Ele au nevoie să fie integrate într-o perspectivă totală a sistemului în toate fazele ciclului de viață.

Figura 1.1.Ciclul de viață al siguranței

În ciclul de viață general de siguranță, Fazele 1 și 2 indică necesitatea de a lua în considerare implicațiile de siguranță ale EUC si sistemul sau de control, la nivel de sistem, atunci când sunt concepute.

În Faza 3, riscurile sunt identificate, analizate, evaluate pe baza criteriilor de tolerabilitate.

În Faza 4, cerințele de siguranță pentru măsurile de reducere a riscurilor sunt menționate.

În faza 5 acestea sunt translatate în proiectarea funcțiilor de siguranță, care sunt puse în aplicare în sisteme de securitate,în funcție de modul selectat de implementare, în faza 9,10 și 11. Cu toate acestea funcțiile de siguranță sunt realizate, nici o cerere pentru siguranță nu se poate face decât luțnd in considerare planificarea securității globale iar acest lucru se reflectă în fazele 6, 7 și 8. Apoi, transportarea funcțiilor de instalare și de punere în funcțiune,de validare de siguranță,și exploatarea și întreținerea,se observă în fazele 12, 13 și 14 să fie pe sistemele generale, indiferent de tehnologiile sistemelor de siguranță.

Faze de 15 și 16 acoperă mai târziu modificarea și reabilitarea sistemului,respectiv dezafectarea.

Ciclul de viață global de siguranță se referă nu numai la dezvoltarea unui sistem, ci întregului său ciclu de viață, iar acest lucru este ilustrat prin includereafazelor de la 12 la 16.

În același timp, la fel ca toate modelele, acesta este o aproximare. Fazele sale sunt afișate secvențial, astfel,iterațiile între ele nu sunt portretizate. De exemplu, dacă modificarea și aducere (Faza 15) este realizată de un sistem operațional, toate activitățile,de la analiza de risc,conform specificațiilor, la revalidare, ar trebui să se efectueze, dar acest lucru nu este explicit în model.

O lecție pe care o putem trage din aceasta este că un model nu poate fi un substitut pentru inginerie bun sau un bun management, nu ar trebui să fie invocate în întregime ca un ghid de ce să facă, și ar trebui să fie utilizate numai pentru a sprijini bine inteles,bune practici.

Alte omisiuni din ciclul de viață sunt activități, cum ar fi management-ul, documentarea, verificarea, asigurarea calității și evaluarea siguranței, care sunt esențiale pentru toate fazele – dar acestea sunt stabilite ca cerințe în clauzele standardului.

Siguranța vs. Securitatea sistemelor critice

În trecut,sistemele software critice de siguranță și de securitate au fost luate în considerare complet separat din cauza diferențele de nume "siguranță" și "securitate" dar și că acesta din urmă presupune implicarea de pierdere a vieții umane.

Funcțiile celor două tipuri de sisteme digitale au devenit din ce în ce mai mult tip software și acest lucru a contribuit la estomparea diferenței dintre siguranță și securitate.

De exemplu, proasta funcționare a funcției de control a zborului ar putea duce la un eșec catastrofal, ceea ce ar duce la pierderea de vieți omenești. Prin urmare, este complet necesara siguranța sistemului critic.

Pe de altă parte, un defect al funcției criptografice ar putea duce la o încălcare a securității sau poate duce la pierderi financiare și, prin urmare, un sistem de securitate a sistemului critic este necesar.

Cu toate acestea,în prezent, o astfel de încălcare a securității ar putea de obicei duce la un atac terorist de succes, care ar putea duce astfel la pierderea de vieți omenești.Acest lucru,astfel, duce la necesitatea unei sistem critic de securitate care sa fie un sistem critic de siguranță.

5.Bibliografie

www.dopopan.ro/facultate/inginerie/software

http://www.nexor.com

http://courses.cs.washington.edu

http://www.mtl-inst.com

[1].Ian Sommerville,Software Engineering,Ed.Addison-Wesley,2007

[2] http://bigfoot.cs.upt.ro/~dan/curs/fis/Cap7_Testare.pdf

[3].Militon Frențiu, Verificarea și validarea sistemelor soft,Ed.Presa Universitară Clujeană,2010

[4]. http://en.wikipedia.org/wiki/Verification_and_validation_(software)

[5].http://www.ionivan.ro/ANUL-UNIVERSITAR%202010-2011/ZZZZcartea%20structuri%20date/F00036000-inspectie.pdf

[6]. http://en.wikipedia.org/wiki/Verification_and_validation

[7]. http://en.wikipedia.org/wiki/Model_checking

[8]. http://en.wikipedia.org/wiki/Formal_verification

[9]. http://alecu.ase.ro/articles/economistul_2005.pdf

[10]. http://en.wikipedia.org/wiki/Software_walkthrough

[11]. http://en.wikipedia.org/wiki/Software_review

[12]. Ian Sommerville ,Software Engineering ,Eighth Edition [13]. Timo Malm, Matti Vuori, Jari Rauhamäki, Timo Vepsäläinen,Johannes Koskinen, Jari Seppälä, Heikki Virtanen, Marita Hietikko & Mika Katara, Safety-critical software in machinery applications