Safety Critical System Toolset

Imagine preview
(8/10)

Acest referat descrie Safety Critical System Toolset.
Mai jos poate fi vizualizat un extras din document (aprox. 2 pagini).

Arhiva contine 1 fisier doc de 16 pagini .

Iti recomandam sa te uiti bine pe extras si pe imaginile oferite iar daca este ceea ce-ti trebuie pentru documentarea ta, il poti descarca. Ai nevoie de doar 3 puncte.

Domeniu: Calculatoare

Extras din document

SCSET a fost un proiect mic(de numai 16 luni ian 1992- mai 1993),care initial a fost gandit ca o prima faza a unui proiect de trei ani. Obiectivele proiectului au fost:

- sa defineasca cerintele majore pentru realizarea unui set de instrumente pentru ingineria sistemelor critice de siguranta;

- sa stabilieasca aplicabilitatea metodelor, instrumentelor si seturilor de instrumente integrate in prezent disponibile, sau care ar putea fi disponibile in viitorul apropiat, in procesul de dezvoltare a sistemelor critice de siguranta;

- sa stabileasca metrici adecvate pentru evaluarea unui set de instrumente;

- sa identifice deficientele acestor instrumente si seturi de instrumente si sa recomande imbunatatiri, rezultand astfel niste specificatii initiale SCSET;

- sa defineasca un proiect de testare adecvat.

La scara mica, software-ul non-critic este scris adesea intr-un mod satisfacator, fara sa se ia in considerare procesul de dezvoltare viitor. Totusi, pentru software-ul critic, un anumit process, de exemplu un anumit set de taskuri care produce un anume set de documente si alte rezultate, este esential pentru controlul de gestiune si , prin urmare, pentru asigurarea sigurantei.

Printre obiectivele acestui proiect se regasesc:

-definirea procesului in ansamblu;

-tratarea problemei de schimbare a cerintelor;

- consideratii juridice in procesul de dezvoltare;

-modelarea procesului folosind tehnici de AI;

-comunicarea(si esecurile de comunicare) in procesul de dezvoltare.

In fiecare caz scopul a fost de a reduce riscul in proces, dar in moduri diferite.Prima abordare a fost de a analiza un proces de dezvoltare conventional cu scopul de a identifica potentialul de automatizare pentru reducerea erorilor umane, in special acolo unde exista riscul ca ca eroarea umana sa treaca de la o etapa a procesului la alta. Lucrul la managementul schimbarii, a demonstrat ca schimbarea este inevitabila , si daca este gestionata corespunzator, constituie calea spre succes prin evolutie.Sunt propuse modalitati prin care schimbarea ar putea fi redusa , facilitata sau cel putin identificata la timp, astfel incat sa poata fi mai usor de gestionat.Al treilea proiect recomanda o abordare proactiva de gestionare a riscurilor legale prin atasarea unui pas legal sau a unei procedure fiecarui eveniment din ciclul de viata.

Ultimele doua proiecte, aplica o tehnologie relativ recenta(modelare AI si respectiv,Metode formale)reducand astfel riscul in procesul de dezvoltare.

Safety Critical Systems Engineering Process

Ca parte a investigatiei cerintelor pentru Safety Critical Systems Engineering Toolset(set de instrumente pentru sistemele critice de siguranta), proiectul SCSET a dezvoltat un model extins al procesului de dezvoltare a sistemului.

Procesul a fost definit in termeni de:

-Faze majore;

-Activitati in fiecare faza;

-Sarcini in cadrul fiecarei activitati;

-Flux de informatii(inclusive dependente) intre sarcini.

Proiectul a trecut in revista ce instrumente si metode au fost disponibile pentru a asista fiecare sarcina, a identificat deficientele si lacunele in aria de acoperire si a luat in consideratie ce metrici ar putea fi utilizate pentru a evalua beneficiile de a utiliza un set de instrumente de inginerie.

Modelarea procesului

La inceputul proiectului, erau disponibile un numar de modele ciclu de viata binecunoscute,dar in curnad a devneit evident faptul ca cele mai multe dintre ele erau puternice pe fazele majore si activitati, dar furnizau informatii limitate cu privire la taskurile individuale su fluxul de informatii dintre ele.Modele de tip Cascada au avut tendinta de a se concentra pe activitatile de baza pe cheltuiala activitatilor de support, cum este Configuration Management.Modele, cum ar fi ASD/SEE, acopereau cele mai milte activitati, dar erau slabe in definirea conexiunilor si intersactiunilor, si au fost folosite mai mult pentru clasificare decat pentru definirea proceselor. Toate modele au fost puternic orientate spre ciclurile de viata software, si au acordat o atentie limitata la sistemele sau aspectele hardware de dezvoltare.

Fisiere in arhiva (1):

  • Safety Critical System Toolset.doc