Ad ogni modo, a me fa molta più paura e mi sembra molto meno rispondente alla sicurezza areonautica, il fatto che Boeing annunci una nuova release a breve (del tipo “ci siamo quasi, massimo 10 giorni ed è pronta”), con il fiato sul collo di vari soggetti e l’opinione pubblica mondiale che sta a guardare, per far ripartire la giostra quanto prima.
Non sono un informatico, ma ho la sensazione che sia il peggior modo di operare per ritoccare/riscrivere un software.
Ciao.
Io di professione sono un Analista Programmatore.
Tento di dare una mia personale risposta, limitatamente al mio campo d'azione, per così dire...
Un modo giusto, unico, oppure standard, oppure anche "globale" per fixare un programma, sfortunatamente non esiste.
Io non lavoro per una grande azienda, il nostro software può vantare, per così dire, circa 700 installazioni.
A volte capita che, facendo uscire una nuova release del programma, si ricevano poi in assistenza una serie di richieste legate direttamente proprio all'ultimo rilascio.
Allora, per chi non è del mestiere, potrebbe giustamente venire da pensare: ma cavolo!??!!? ma voi le cose prima di rilasciarle, non le provate?
Posso assicurare che noi le cose le proviamo, eccome se lo facciamo!
Però ed è la cosa più difficile per tutti da capire, noi compresi, è che nel nostro mondo esiste una lotta perenne fra algoritmi e dati.
Lo stesso programma, identico alla virgola, può generare un errore da un cliente e non generare il medesimo errore da nessun'altra parte...
Come si può spiegare questa cosa?
In 2 modi:
1) uno o più algoritmi sono errati, ma non in assoluto, sono errati quando entrano in contatto con alcuni dati; i programmatori, i tester e tutta la filiera di rilascio non sono mai incappati e nemmeno hanno mai avuto idea del fatto che potessero esistere delle simili condizioni.
2) tutti gli algoritmi sono corretti, anche in assoluto (posso accettare questa condizione), ma uno o più di loro fallisce in modo catastrofico entrando in contatto con dati errati. Questo perchè la produzione del dato non è sempre necessariamente opera del programma che poi lo va a gestire; a volte i dati sono prodotti da strumenti/elementi esterni. Pur avendo precise specifiche ed ovviamente avendole testate tutte, quando si va in produzione, accade a volte che al programma arrivi roba strana, malformata e/o lacunosa.
Un esempio reale: lo scorso giovedì ho installato una nuova release da un mio cliente.
Dalla versione 2019.01++ è passato alla versione 2019.01+++ (poca roba di differente, davvero poca).
Venerdì mattina il cliente segnala un problema.
L'errore è in un punto del programma che è sotto test da 6 mesi ed è già stato dichiarato stabile e può passare in produzione.
L'ultima release da me installata, lo giuro, non ha subito alcun genere di modifica; il codice sorgente è lo stesso, identico alla virgola, rispetto alla release precedente!
Perchè è andato in errore allora?
Un altro fornitore, il quale fornisce il dato su cui il nostro programma poi agisce, ha modificato qualcosa.
A noi non era stato detto e comunque, a posteriori, anche se ci avessero comunicato la modifica, l'avremmo approvata serenamente perchè era poco più di una banalità.
Questa banalità ha mandato tutto in crash... dopo 6 mesi di test e collaudi... un errore catastrofico e sistemico...
L'altro fornitore in alcuni casi anzichè inviare valori coerenti, invia dei valori nulli (e questo fatto per noi è fuori specifica).
Lui non sa di inviare valori null fuori specifica ma di fatto questa cosa accade!
Noi non sappiamo di ricevere valori null, perchè essendo fuori specifica ed avendo impostato sia il DB che il nostro SW in modo tale che questa condizione non si crei, non siamo in alcun modo ricettivi in tal senso.
Ma il valore null viene prodotto e viaggia inosservato per tutto il canale di comunicazione ed arriva a destinazione senza colpo ferire.
Il risultato finale è un crash totale di quella parte di programma.
E la risoluzione di tutto questo non è immediata.
A volte ci vuole tempo solo per capire cosa succede.
Una volta capito questo, serve altro tempo per capirne il perchè, ovvero la causa scatenante; in particolar modo quando il dato errato non è sempre, tutte le volte, errato!
Poi ci vuole tempo per studiare la strategia d'azione.
Altro tempo per creare la correzione, FACENDO ENORME ATTENZIONE A NON PRODURRE DELLE REGRESSION !!! Ovvero a non creare un qualcosa che corregge questo problema ma che poi va a scassare qualcos'altro da qualche altra parte = ciò che prima funzionava bene e che funzionava bene anche in caso di errore, con la correzione deve continuare a funzionare !!!
Infine serve altro tempo per mettersi lì a testare, ritestare, collaudare e ricollaudare lo specifico problema in primis ed il generale infine.
Non oso nemmeno pensare a cosa voglia dire fare tutto ciò in materia di Aviazione Civile...
SE è davvero un problema software del MCAS che ha causato ben 2 incidenti fatali, allora non mi meraviglio affatto che la soluzione software al problema si faccia attendere.
Anche perchè coi dati di quest'ultimo incidente dovranno come minimo ripartire dall'analisi iniziale del problema e verificare se ciò che hanno scoperto finora, incrociato coi nuovi dati, regge e garantisce di aver trovato il vero perchè del problema, oppure solo di una sua parte...
Tutto nella mia umilissima e minima esperienza.