Affidabilità del software

0
L’affidabilità di sistemi e prodotti complessi, definita come misura della capacità di soddisfare specificati requisiti operativi e di sicurezza, integrità ed incolumità, è legata alla qualità di due componenti: software e hardware. Tra questi la componente software sta assumendo un peso sempre più importante. Si pensi alle applicazioni avanzate ad alta tecnologia in campo industriale, civile, guida assistita o automatizzata, energia, finanza e assicurazioni, difesa e spazio, per comprendere l’importanza di sistemi affidabili e sicuri. Questo articolo affronta, seppur sommariamente, le tematiche relative all’affidabilità del software tralasciando volutamente altri temi, non meno importanti, della disponibilità e manutenibilità.

Perché è importante l’affidabilità

Affidabilità è la probabilità che un sistema (o un suo componente) mostri le caratteristiche per cui è stato realizzato senza presentare alcun malfunzionamento nell’ambiente di destinazione per tutto il tempo richiesto. Il funzionamento corretto e prolungato del software incorporato (embedded) nei sistemi di cui ci si serve quotidianamente è di estrema importanza per i milioni di utenti che li utilizzano (passeggeri dei voli aerei e dei treni, automobilisti, utenti delle centrali nucleari, banche, ecc.).

Affidabilità e competitività

La competitività di un prodotto software dipende da vari fattori: qualità, affidabilità, prestazioni, costo del ciclo di vita. La misura dell’affidabilità è dunque un elemento di competitività sul mercato. Se si commercializza, ad esempio, un prodotto con un valore di MTTF (Mean Time To Failure) pari a mille ore, ci si potrà permettere di effettuare la manutenzione ogni 20 giorni; invece, se il valore di MTTF fosse di 10.000 ore si potrebbe aumentare l’intervallo di manutenzione ad oltre un anno (416 giorni). Per aumentare l’affidabilità del sistema si dovrà ovviamente spendere di più nel realizzare componenti di maggiore qualità. Diminuiscono i costi di manutenzione e delle garanzie di contratto e aumentano i costi di sviluppo. La funzione somma dei costi mostra che per ogni sistema e per ogni tipo di sviluppo software esiste un punto minimo del Costo del ciclo di vita. Tale punto indica al produttore la sua massima competitività sul mercato in quanto minimizza i suoi costi. La curva ci dice anche quanto sia inutile aumentare l’affidabilità del sistema oltre il minimo richiesto per soddisfare le aspettative del cliente o del contratto, perché non verrebbe ripagata da nulla.

Figura 1. L’influenza dell’affidabilità sui costi del ciclo di vita (LCC)

Figura 1. L’influenza dell’affidabilità sui costi del ciclo di vita (LCC)

Figura 2. Assicurazione dell'affidabilità nel ciclo di vita

Figura 2. Assicurazione dell’affidabilità nel ciclo di vita

Affidabilità nel ciclo di vita

L’affidabilità è determinata fin dalla fase di progettazione applicando un processo di predizione con l’obiettivo di ottenere un valore dipendente dall’architettura del sistema e dalle sue caratteristiche tecnologiche. Il processo di assicurazione dell’affidabilità prevede varie analisi da ripetersi in modo iterativo e, sulla base dei risultati ottenuti ciascuna volta, determina le azioni correttive più opportune sul progetto fino ad assicurare la convergenza verso un’architettura ed una tecnologia caratterizzate dall’affidabilità richiesta come mostrato nella Figura 2.
Il processo di assicurazione dell’affidabilità nel ciclo di vita di un software inizia già dalla fase di definizione dei suoi requisiti. Si instaura, a seguire, un processo rivolto al soddisfacimento dei requisiti di ogni tipo, inclusi quelli di affidabilità, fin dall’inizio. Le successive fasi sono protese al conseguimento degli obiettivi di affidabilità attesi: analisi dei requisiti; analisi funzionale; progettazione architetturale e di dettaglio; test; validazione; operatività. Nello sviluppo di sistemi software, a differire sono le tecniche usate per la predizione dell’affidabilità: mentre nell’hardware la predizione è effettuata sulla base dell’architettura e della tecnologia del prodotto, nel caso del software si effettua sulla base dell’architettura e degli attributi del software che si vogliono realizzare.

Affidabilità e sicurezza

L’affidabilità del software, si è detto, è spesso strettamente legata alla sicurezza (Safety). Essa può essere raggiunta utilizzando varie tecniche. Una volta identificato come “safety- critical”, il software è sottoposto ad analisi di tipo SFMECA (Software Fault Mode Effects and Criticality Analysis), SFTA (Software Fault Tree Analysis) e SHA (Software Hazard Analysis). Analisi che mirano a: identificare i rischi; dimostrare l’assenza di rischi specifici; determinare i possibili effetti dannosi derivanti dai rischi; determinare le cause di un pericolo; identificare i criteri di progettazione di sicurezza per eliminare, ridurre o controllare i pericoli identificati; valutare l’adeguatezza dei controlli di pericolo.
La SFMECA è utilizzata per classificare le criticità del software assegnando a ciascun componente la propria categoria di criticità corrispondente alla modalità di guasto. Inoltre, al fine di valutate la categoria finale di criticità, sono prese in considerazione le potenziali propagazioni del guasto tra i diversi componenti software. Tale analisi è condotta secondo differenti punti di vista: funzionale, di interfaccia, di dettaglio, di realizzazione, di manutenzione e di uso.
La SFTA è invece un approccio top-down per l’analisi dei guasti software che si manifestano con un evento indesiderato e definisce tutti i modi in cui possono accadere. Essa determina che cosa sia in grado di produrre ad alto livello un singolo fallimento o fallimenti multipli. Condizioni di errore che si prendono in considerazione includono: falsi allarmi; gestione insufficiente degli errori; sequenza di accadimento; tempificazione; terminazioni non corrette; uscite valide ma non previste.
La SHA, infine, è una forma di analisi del rischio dei sottosistemi o moduli. Serve a convalidare che uno specifico comportamento del software soddisfi i criteri generali di progettazione del sistema di sicurezza. Il software può essere considerato “pericoloso” se può creare direttamente un pericolo oppure può essere utilizzato per controllare a sua volta un pericolo. Tali analisi, dunque, esaminano i componenti o le funzioni del software per determinare se il loro comportamento (rendimento normale, degradazione funzionale, insufficienza funzionale, funzione non intenzionale o funzione involontaria) possa costituire un pericolo per il sistema.

Metodi e tecniche di predizione dell’affidabilità

I modelli di base a partire dai quali sono stati prodotti fino ad oggi i metodi di applicazione maggiormente utilizzati ed efficaci sono:

  • Modello di Shooman: consente, in modo particolarmente semplice ed accurato la determinazione dell’Affidabilità di un applicativo software a partire dal numero di bugs corretti nella fase di debugging;
  • Modello di Musa: effettua la predizione dell’affidabilità di un applicativo software nel corso della fase di test e ne consente il miglioramento; •Modello di Putnam: prevede l’andamento nel tempo del numero di bugs dell’applicativo;
  • Modello RL-TR-92-52: messo a punto dal Rome Laboratory, determina l’affidabilità dell’applicativo, già prima che il software sia stato scritto, sulla base dell’architettura e degli attributi; è tuttora sottoposto a significativi aggiornamenti.

Affidabilità e test

Il software è sempre più intimamente integrato in prodotti e sistemi che, secondo i settori, spaziano da mercati di nicchia a quelli di largo consumo.
Con vario peso, sono fondamentali i diversi aspetti di RAMS1, dove la “S” sta a denotare sia Sicurezza fisica (Safety) sia Sicurezza applicativa (Security).
È bene concentrarsi su “R” (Reliability – Affidabilità) senza però tralasciare “S” (Safety) per gli impatti sull’incolumità degli utilizzatori e Security per gli impatti sulla sicurezza ed integrità dei sistemi.
Mercati di nicchia e mercati di largo consumo sono differenziati dal numero profondamente diverso di esemplari di prodotti software replicati e quindi dalla base su cui possono essere ripartiti i costi di progettazione, sviluppo, integrazione e test. Questo può influenzare la definizione dei piani di test, sia per gli aspetti di affidabilità (R) sia per quelli di sicurezza (S).
Nel caso di prodotti di nicchia i piani dovrebbero essere massimamente rappresentativi delle condizioni operative reali. Purtroppo, ragioni di costi e tempi possono lasciare inesplorate aree grigie o nere, potenziali cause di guasti. E l’esercizio potrebbe richiedere tempi lunghi per evidenziare anomalie o bachi da recuperare attraverso procedure FRACAS con conseguenti inefficienze dovute a costi di mantenimento della relativa struttura, sia di sviluppo sia presso l’utente. Nel caso di prodotti di largo consumo i piani di test dovrebbero garantire il raggiungimento di un livello minimo di Affidabilità (R) e sicurezza (S), potendo contare su informazioni di ritorno dal campo generato dall’impiego massivo di tali prodotti, misurabile in miliardi di ore cumulate per anno. Questo, molto probabilmente, consentirebbe di collaudare i prodotti software in tutte le possibili condizioni operative (in parte questo già avviene con le versioni beta che vengono rilasciate con ogni nuovo prodotto). Cruciale è in questo caso la raccolta, gestione ed uso del flusso di informazioni che impattano certamente sulla progettazione di un efficiente sistema FRACAS.
FRACAS ha, in questo caso, una duplice valenza: aiuta a migliorare l’affidabilità (R) e la sicurezza (S) del software attraverso l’approntamento delle misure correttive e permette di definire piani di test per lo sviluppo di prodotti futuri similari.

Figura 3. Assicurazione dell'affidabilità nel ciclo di vita

Figura 3. Assicurazione dell’affidabilità nel ciclo di vita

Il ritorno dal campo (processo FRACAS)

I dati caratterizzanti le avarie rilevate sul campo sono sottoposti ad un processo di analisi noto come FRACAS (Sistema di analisi dei rapporti sui difetti e relative azioni correttive) 2. Si tratta di un sistema organizzato a “ciclo chiuso” (Closed Loop) che, partendo dai rapporti ricevuti sulle anomalie rilevate, effettua la loro analisi, definisce le azioni correttive e ne valuta l’efficacia una volta messe in atto (vedi Figura 3). Per essere efficace un tale processo richiede la disponibilità di strumenti di raccolta e analisi dei dati relativi ai malfunzionamenti imputabili al software che consentano di eseguire le necessarie analisi per l’approntamento delle misure correttive3. Una maggiore efficacia è ottenuta applicando il processo lungo tutte le fasi del ciclo di vita del software.

Conclusioni

L’affidabilità è una caratteristica intrinseca del software e come tale deve essere definita in termini di requisiti, progettata adeguatamente, sviluppata coerentemente con il disegno e valutata lungo l’intero ciclo di vita. Le tecniche da applicare sono diverse e richiedono competenze specifiche e strumenti a supporto (SFMECA, SFTA, SHA). L’affidabilità è “predetta” ad ogni fase con modelli statistici e verificata a consuntivo. Particolare rilievo assume il processo FRACAS per identificare le cause dei difetti e rimuovere direttamente le cause originali con opportune azioni.

NOTE

1 RAMS, Reliability (Affidabilità), Availability (Disponibilità), Maintainability (Manutenibilità), Security (Sicurezza).
2 FRACAS = Failure Reporting and Corrective Action System
3 Meccanismi di reporting automatici che provvedano alla raccolta delle informazioni relative al malfunzionamento e all’invio all’organizzazione di sviluppo software rappresentano strumenti di grande utilità.

BIBLIOGRAFIA

Martin L. Shooman. Probabilistic Reliability: An Engineering Approach. 2nd Edition. Robert E. Krieger Publishing Company, Malabar, Florida. 1990 John D. Musa, Anthony Iannino, Kazuhira Okumoto. Software Reliability Measurement, Prediction, Application. McGraw-Hill Publishing Company. 1990 Lawrence H. Putnam, Ware Myers. Measures for Excellence – Reliable Software on Time, within Budget. Yourdon Press, Upper Saddle River, New Jersey 07458. 1992 Rome Laboratory. Air Force Systems Command. Griffiss Air Force Base. NY 13441-5700. RL-TR-92-52, – Software Reliability, Measurement, And Testing – Software Reliability and Test Integration, vol. I and II. 1992 GRUPPO DI LAVORO Gli autori dell’articolo fanno parte del gruppo di lavoro costituito in Aicq-ci con il fine di diffondere i concetti dell’affidabilità del software presso il grande pubblico oltre che per gli addetti ai lavori. Essi operano (o hanno operato), a vario titolo e con responsabilità diverse, in aziende in cui i temi dell’affidabilità sono cruciali per il loro business e che hanno come principali clienti European Space Agency (ESA), Agenzia Spaziale Italiana (ASI), Telespazio, Thales Alenia Space e Difesa di varie nazionalità, IBM e altre.

Systems and complex products reliability, defined as a measure of the ability to meet specified requirements and operational security, integrity and safety, is related to the quality of two components: software and hardware. Software component is assuming an increasingly important role. Advanced high-tech applications in industrial, civil, assisted or automated guidance, energy, finance and insurance, defence and space, to understand the importance of reliable and safe are relevant examples. This article briefly discusses the issues related to the reliability of the software deliberately ignoring other issues, not least, the availability and maintainability.

GRUPPO DI LAVORO

Gli autori dell'articolo fanno parte del gruppo di lavoro costituito in Aicq-ci con il fine di diffondere i concetti dell'affidabilità del software presso il grande pubblico oltre che per gli addetti ai lavori. Essi operano (o hanno operato), a vario titolo e con responsabilità diverse, in aziende in cui i temi dell'affidabilità sono cruciali per il loro business e che hanno come principali clienti European Space Agency (ESA), Agenzia Spaziale Italiana (ASI), Telespazio, Thales Alenia Space e Difesa di varie nazionalità, IBM e altre.
Share.

Comments are closed.