Ottenere la Dependability per un sistema informatico

Un sistema, per l’ingegneria del software, può innanzitutto essere classificato sulla base del fatto che sia o meno tollerante ai guasti. Identifichiamo quindi due classificazioni: sistemi tolleranti ai guasti e i sistemi non toleranti ai guasti.

I sistemi non tolleranti ai guasti sono quei sistemi dove si cerca esclusivamente di rendere meno probabile possibile il verificarsi dei fallimenti. Si opera sia a livello hardware che software. Sostanzialmente a livello hardware si cercherà di utilizzare componenti altamente aﬃdabili, mentre a livello software si tenderà piuttosto a soﬀermarsi sulle fasi di testing agevolando l’individuazione dei guasti. Avendo già accennato a quanto sia diﬃcile evitare che un sistema possa essere distribuito con la certezza di essere privo di guasti, possiamo immaginare come questi sistemi, pur avendo superato tutte le fasi di testing, non possano considerarsi assolutamente immuni da fallimenti. Questo poiché, non essendo il sistema tollerante ai guasti, l’attivarsi anche di un solo guasto potrebbe causare il fallimento di tutto il sistema.

I sistemi tolleranti ai guasti sono invece sistemi pensati e progettati al fine, più che di evitare l’insorgenza di errori, di ridurre e contenere le conseguenze del verificarsi di un errore. In questo modo è possibile evitare che il sistema pur essendo aﬀetto da guasti degeneri in fallimento, finendo per diventare inutilizzabile.

Dire che questi sistemi devono essere progettati in un determinato modo fa capire come la gestione del processo di sviluppo software rivesta un ruolo importante per raggiungere l’obbiettivo di costruire sistemi aﬃdabili. Il processo di sviluppo software è identificato da una serie di passi che bisogna necessariamente svolgere per ottenere risultati di qualità. Le attività fondamentali che compongono lo sviluppo del software sono:

Analisi. Consiste nello studio preliminare del prodotto che deve essere realizzato, nel senso che deve essere definito il problema che si vuole risolvere. Questa attività può essere scomposta in sotto-attività tra cui l’analisi dei requisiti del Il documento risultante da questa attività è il cosiddetto documento di specifica, contenente appunto le specifiche del prodotto software.
Progettazione. Consiste nella definizione della struttura generale del prodotto software sulla base dei requisiti espressi nella fase precedente. Se nella fase precedente si è definito il problema da risolvere, in questa fase viene invece definito come il problema deve essere risolto.
Implementazione. Consiste nella realizzazione vera e propria del prodotto software sulla base della struttura definita nel passo All’interno di questa attività vengono poi definite alcune sotto-attività come: lo sviluppo separato dei moduli che compongono il software e l’integrazione di questi nel medesimo prodotto.
Collaudo. Consiste nel verificare quanto il software realizzato rispetti le specifiche definite nell’attività di Analisi. Anche in questo caso l’attività può essere scomposta nell’attività di verifica dei singoli moduli e nella successiva verifica dell’interazione tra questi nel programma completo. É principalmente in questa fase che si tenta di individuare e risolvere i guasti inseriti nel programma al momento dell’implementazione. L’attività di collaudo termina con la validazione del prodotto.
Rilascio. Consiste nel rilascio del programma una volta che è stato validato e nella successiva messa in opera.
Manutenzione. Consiste nelle operazioni di modifica al programma apportate successivamente al rilascio dello Tali operazioni sono volte a correggere errori individuati nel codice o ad estendere le funzionalità del sistema.

Aumentare la Dependability di un sistema informatico

L’organizzazione di queste attività identifica i vari modelli di sviluppo software. Lo studio e la progettazione di questi modelli è uno degli obbiettivi dell’Ingegneria del Software. Alla base di questa disciplina c’è la considerazione del software come risultato di un processo di sviluppo suddiviso in diverse attività. L’organizzazione di tali attività identifica il ciclo di vita del software.

Sulla base degli approcci di progettazione del sistema vengono quindi identificate dallo stesso Laprie quattro metodologie volte ad aumentare la Dependability di un sistema e che si distinguono tra loro per la fase del ciclo di vita del software in cui vengono adottate:

Prevenzione dei guasti (fault prevention): cerca di prevenire l’inserimento dei guasti nel sistema e viene quindi utilizzata nelle attività di analisi e progettazione.
Tolleranza ai guasti (fault tolerance): mantiene il sistema funzionante anche in presenza di guasti e deve essere adottata nelle fasi di progettazione e implementazione del programma.
Rimozione dei guasti (fault removal): cerca di eliminare il più possibile i guasti presenti nel sistema e viene utilizzata nelle attività di collaudo e manutenzione del software.
Previsione dei guasti (fault forecasting): cerca di stimare la presenza dei guasti all’interno del sistema.

Le prime tre metodologie cercano di conferire al sistema un certo grado di aﬃdabilità, mentre l’ultima è volta a stimare l’aﬃdabilità del sistema. La scelta di una di queste tecniche non esclude la possibilità di implementare anche le altre. Inoltre la scelta delle metodologie influenza inevitabilmente il livello di Dependability del sistema risultante, e viceversa le aspettative che si hanno sul grado di Dependability condizionano certamente la scelta delle tecniche da utilizzare tra quelle sopra elencate.