Lezioni apprese nella gestione dei requisiti: volo 501 di Ariane 5

Il disastro del volo 501 di Ariane 5 mostra perché dovremmo sempre riflettere due volte prima di riutilizzare così come sono requisiti, progetti ingegneristici e test di progetti precedenti. 

Nello sviluppo di prodotti hardware, è comune riutilizzare requisiti, routine software, casi di test o decisioni di progettazione da progetti precedenti. Questo può far risparmiare tempo, ma solo se le condizioni che rendevano valide quelle scelte sono ancora applicabili.

Ariane 5 Flight 501 è stato il primo volo del razzo europeo Ariane 5 il 4 giugno 1996. Il razzo riutilizzava parte del software del sistema di riferimento inerziale di Ariane 4, un precedente razzo europeo in cui quel software aveva funzionato con successo. Ma Ariane 5 seguiva un profilo di volo diverso, un valore ha superato l’intervallo previsto dal software e il razzo è stato distrutto meno di un minuto dopo il lancio.

La lezione è semplice, ma facile da dimenticare: prima di riutilizzare il lavoro di progetti precedenti, verificate se nel nuovo progetto valgono ancora le stesse ipotesi e condizioni operative.

Punti chiave

• Riutilizzare requisiti, software, test o decisioni di progettazione già collaudati fa risparmiare tempo, ma il contesto originale deve essere riesaminato.
• Esaminate i casi di test riutilizzati prima di usarli per dimostrare lo stesso requisito in un altro prodotto.
• Riducete il rischio mantenendo collegati requisiti, procedure di test, evidenze e stato.

Cosa è successo nel lancio di Ariane 5

Il 4 giugno 1996, Ariane 5 effettuò il suo primo volo da Kourou, nella Guyana francese, trasportando quattro satelliti di ricerca Cluster per l’Agenzia Spaziale Europea. La missione durò meno di un minuto. Circa trentasette secondi dopo l’inizio del volo, il razzo deviò dalla traiettoria prevista e venne distrutto.

Il problema proveniva dal sistema di riferimento inerziale, che inviava dati di assetto e velocità al computer di bordo del razzo. Ariane 5 riutilizzava software di Ariane 4, inclusa una routine di allineamento che rimaneva attiva per circa 40 secondi dopo il lancio. Questa routine aveva funzionato in Ariane 4, ma Ariane 5 seguiva un profilo di volo diverso.

A causa di quel diverso profilo, si verificarono rapidamente diversi eventi in successione:

• Un valore di velocità orizzontale divenne più grande di quanto il software si aspettasse.
• Il software cercò di convertire il valore da un numero in virgola mobile a 64 bit in un intero con segno a 16 bit, ma il valore non rientrava più nell’intervallo consentito.
• La conversione andò in overflow e il sistema di riferimento inerziale trattò questo evento come un errore, spegnendosi.
• Il sistema di backup eseguiva lo stesso software e si spense per la stessa ragione.
• Senza dati di volo validi, il computer di bordo usò invece dati diagnostici, impartì comandi di volo errati e il razzo venne distrutto.

Questo è ciò che rende il caso utile per la gestione dei requisiti. Il software riutilizzato aveva funzionato in precedenza, ma portava con sé un’ipotesi del razzo precedente: che questo valore sarebbe rimasto entro un intervallo sicuro. Ariane 5 ha cambiato il contesto attorno a quell’ipotesi, quindi questa doveva essere resa visibile e verificata di nuovo nel nuovo sistema.

L’esempio ricorda che anche il lavoro ingegneristico riutilizzato richiede ancora un semplice controllo: le ipotesi su cui si basa sono ancora vere nel nuovo sistema?

Cosa possono imparare i team hardware dal caso Ariane 5

La maggior parte dei team hardware non costruisce razzi, ma riutilizza continuamente lavoro già collaudato. Un blocco PCB di un prodotto precedente può essere copiato in un nuovo progetto. Una routine firmware può essere trasferita a una nuova revisione hardware. Una procedura di test può rimanere invariata anche dopo modifiche all’architettura di alimentazione. 

Questo è normale lavoro ingegneristico. Il riutilizzo aiuta i team a muoversi più velocemente. Il passaggio importante è assicurarsi che il requisito, l’ipotesi e la verifica siano ancora allineati con il nuovo sistema.

Riesaminate i requisiti riutilizzati

Un requisito che ha funzionato in un prodotto non dovrebbe essere considerato automaticamente valido nel successivo. Le stesse parole possono ancora sembrare corrette, ma le condizioni operative che le circondano potrebbero essere cambiate. Per esempio, un limite di corrente, un intervallo termico o un vincolo di interfaccia possono essere sicuri in un progetto e richiedere una revisione in un altro. Prima di riutilizzare un requisito, il team dovrebbe verificare se il nuovo prodotto opera ancora entro le stesse ipotesi.

Collegate le ipotesi alle procedure di verifica

Alcune delle ipotesi ingegneristiche più importanti non vengono mai scritte come requisiti formali. Rimangono in note di progetto, vecchi piani di test o nella memoria di qualcuno. Questo può diventare rischioso quando il lavoro viene riutilizzato. Se un’ipotesi influisce su una decisione di progettazione, il team deve avere un modo per collegarla a un controllo di verifica. Altrimenti, è facile riutilizzare la decisione senza vedere il motivo che l’aveva resa sicura in origine.

Riesaminate i test quando i requisiti cambiano

Un caso di test che è stato superato nel progetto precedente non dimostra sempre la stessa cosa in quello successivo. Se il requisito cambia, oppure cambia il sistema attorno al requisito, anche la procedura di test correlata potrebbe dover cambiare. Questo è particolarmente importante quando i team riutilizzano casi di test, criteri di accettazione o evidenze di conformità.

Come aiuta un flusso di lavoro dei requisiti connesso

Un flusso di lavoro dei requisiti migliore non tratta un requisito come una riga di testo isolata. Mantiene il requisito collegato alla motivazione che lo giustifica, al lavoro di progettazione su cui influisce e al lavoro di verifica che dimostra se è ancora valido. 

È questo l’aspetto più importante quando qualcosa cambia. Un requisito riutilizzato può ancora sembrare corretto, ma l’ipotesi su cui si basa potrebbe non essere più coerente con il nuovo prodotto. Un test può ancora esistere, ma potrebbe non verificare più la condizione giusta.

In un flusso di lavoro connesso, i team possono mantenere vicini gli elementi importanti: il requisito, il contesto che lo giustifica, il metodo di verifica, la procedura, il risultato, l’evidenza e lo stato attuale. Invece di cercare tra vecchi documenti o report di test, gli ingegneri possono vedere cosa è collegato e cosa potrebbe richiedere un’ulteriore revisione.

Altium Requirements Portal supporta questo tipo di flusso di lavoro mantenendo requisiti, tracciabilità, responsabilità e attività di verifica in un unico ambiente condiviso. Questo aiuta i team a riutilizzare lavoro già collaudato con maggiore fiducia, perché il requisito e i controlli che lo circondano rimangono collegati.

Le vecchie ipotesi nel vostro progetto sono ancora vere?

Ogni team hardware riutilizza lavoro già collaudato. Non è una scorciatoia da evitare, ma un modo pratico per sviluppare più rapidamente e portare avanti buone decisioni ingegneristiche. 

La domanda utile è cosa sia cambiato attorno a quel lavoro riutilizzato:

• L’intervallo operativo è cambiato? 
• Il test deve essere rivisto? 
• Le ipotesi alla base della decisione originale sono ancora valide?

Quando i team sanno rispondere a queste domande, del riutilizzo ci si può fidare più facilmente. Il requisito non è isolato. La motivazione che lo sostiene, il controllo di verifica e l’evidenza rimangono abbastanza vicini da permettere al team di riesaminarli quando cambia il contesto del prodotto. 

Questa è la lezione che Ariane 5 continua a offrire oggi ai team hardware: il riutilizzo funziona al meglio quando il contesto che lo sostiene rimane collegato.

Rendete più facili da verificare e più affidabili le decisioni di riutilizzo con uno strumento di gestione dei requisiti accessibile a tutto il team.

Iniziate con Requirements Portal →

Domande frequenti

Il riutilizzo del lavoro ingegneristico può diventare rischioso?

Il riutilizzo del lavoro ingegneristico può diventare rischioso quando il contesto del prodotto cambia ma le ipotesi originali, i limiti operativi o i controlli di verifica non vengono riesaminati. Il lavoro può ancora sembrare corretto, ma le condizioni che lo rendevano valido nel progetto precedente potrebbero non essere più applicabili.

Cosa dovrebbero controllare gli ingegneri prima di riutilizzare un requisito, un test o una decisione di progettazione?

I team dovrebbero verificare se il nuovo prodotto usa le stesse condizioni operative, interfacce, limiti e criteri di accettazione del progetto originale. Dovrebbero anche confermare che il metodo di verifica correlato dimostri ancora la cosa giusta nel nuovo sistema.

In che modo la tracciabilità aiuta quando i requisiti vengono riutilizzati?

La tracciabilità aiuta i team a vedere come un requisito si collega a decisioni di progettazione, ipotesi, procedure di test, evidenze e stato. Quando il lavoro riutilizzato viene trasferito in un nuovo progetto, questi collegamenti rendono più facile capire cosa è ancora valido e cosa potrebbe richiedere una revisione.