Mission-critical

Oggi si usa meno, ma per molti anni l’espressione “mission-critical” è stata onnipresente nella gran parte delle schede informative dei vari prodotti hardware e software che i dipartimenti IT delle grandi aziende dovevano acquistare. Quindi c’erano server adatti alle situazioni “mission-critical”, database management system per gestione di basi di dati in contesti “mission-critical” e così via.

Il concetto era di chiara ascendenza militare: ci sono singole componenti in grado di far fallire una missione nel caso in cui non siano totalmente affidabili e robuste. Il concetto era stato esteso in particolare alle missioni aerospaziali che, cinquant’anni fa, portarono i primi astronauti a calpestare il suolo lunare. In quell’ambito, davvero ogni componente del sistema doveva essere pensato per situazioni “mission-critical”. Oggi si tende a usare maggiormente i termini safety-critical o life-critical, ma insomma, siamo lì.

Ciò nonostante, non mancarono gli incidenti nel periodo di preparazione e, in particolare, anche durante l’effettuazione delle missioni. Resta celebre quello della missione Apollo 13 (“Okay, Houston, we’ve had a problem here”) con l’esplosione di un serbatoio di ossigeno: quest’ultima situazione, davvero “mission-critical”, fu risolta brillantemente con coraggio, ingegnosità e determinazione sia da parte della base sulla Terra che degli astronauti, e l’equipaggio riuscì a tornare sano e salvo sul nostro pianeta.

Anche in un programma dal budget enorme — nel 1966 il finanziamento della NASA arrivò a essere pari al 5.5% dell’intero bilancio federale USA — i problemi ci furono comunque. Ma si era in un territorio nuovo, pieno di aspetti incogniti e necessitante di reale sperimentazione.

Apollo Guidance Computer

Sicuramente tra i componenti “mission-critical” va collocato anche l’AGC (Apollo Guidance Computer) che, pur con una potenza di calcolo e una memoria minima se paragonate anche solo ai nostri smartphone, a fronte di un peso dell’intero apparato di ca. 32 kg, il computer di bordo fu comunque in grado di assistere gli astronauti nelle operazioni più delicate. L’interfaccia DSKY (display / keyboard) era davvero spartana: una semplice tastiera numerica, un display a segmenti illuminati, alcune spie: non troppo dissimile da quello delle vecchie calcolatrici scientifiche…

Dopo la corsa allo spazio

Tutta questa introduzione serve a dire sostanzialmente quattro cose:

• tra la fine degli anni Sessanta e i primissimi anni Settanta del secolo scorso, l’uomo è andato sulla luna e tornato grazie a tecnologie missilistiche, aerospaziali e anche informatiche;
• tutto questo sforzo tecnologico, le cui ricadute ancor oggi sono presenti nella nostra vita quotidiana, ha avuto un costo enorme in termini di finanziamenti, giustificato dalla situazione geopolitica del tempo, con gli Stati Uniti decisi a colmare la distanza con l’Unione Sovietica nella corsa allo spazio, fino a ribaltare la partita e vincere questa competizione su tutti i fronti;
• nonostante l’enorme investimento, non sono mancati malfunzionamenti, incidenti, problemi, necessità di rivedere i piani iniziali;
• in molti casi, si è trattato di inventare e percorrere strade fino ad allora sconosciute, creando pratiche in campo tecnologico, informatico, organizzativo e di project management che hanno rappresentato la via maestra nei decenni a seguire.

I tempi cambiano

Oggigiorno è impensabile ipotizzare un’epopea simile a quella dello sbarco sulla Luna, anzitutto per ragioni di costi: anche le missioni spaziali più avanzate e innovative, come quelle che hanno portato sonde esplorative sul suolo marziano, possono usufruire di budget drasticamente più ristretti rispetto a quelli di un tempo.

La produzione di software è ormai un settore produttivo fiorente, e alcuni tra i più grandi colossi industriali del mondo sono, a tutti gli effetti, anche o principalmente produttori di software. Dai tempi della NASA, molti sono stati i cambiamenti non solo tecnologici, ma anche organizzativi, di tipo gestionale, che hanno consentito di produrre software sempre più avanzato a costi sempre più sostenibili. L’attuale “rivoluzione” in senso Agile è un’ulteriore passo di questa evoluzione.

Ma la corsa alla riduzione dei costi della produzione di software è in grado non solo di portare a una “democratizzazione” dell’uso di certi strumenti, ma anche di causare malfunzionamenti gravi. È quello che vedremo di seguito.

Il caso Boeing

E arriviamo a un caso, di cui si parla molto in questo periodo, in cui i tagli eccessivi al costo di produzione del software hanno finito per creare non un risparmio ma perdite significative: saremmo nell’ambito di un caso di scuola di management aziendale se non fosse che tali perdite sono state, anzitutto, di vite umane.

Incidenti aerei

Probabilmente qualcuno ricorderà i due gravi incidenti aerei verificatisi tra l’autunno e l’inverno scorsi: prima a ottobre in Indonesia (189 vittime), poi a marzo in Etiopia (157 vittime) aerei dello stesso modello (Boeing 737 MAX 8) si schiantarono al suolo poco dopo il decollo, senza che ci fossero apparenti cedimenti strutturali o problemi meccanici.

Pur derivando da un modello progettato negli anni Novanta del secolo scorso, si trattava comunque di aerei “re-ingegnerizzati” e di fabbricazione molto recente, per cui le ipotesi inerenti ai motivi dei due incidenti avevano ben presto scartato i classici guasti dovuti all’età del mezzo, all’usura o alla mancata manutenzione.

L’importanza dei sistemi di controllo automatico

Nei moderni aeroplani, i sistemi di assistenza automatica al volo hanno un ruolo sempre più preponderante. Sia chiaro: i piloti sono addestrati per essere in grado di operare “manualmente” sul velivolo e farlo decollare, virare e atterrare. Ma, di fatto, il loro intervento più diretto tende a limitarsi alle fasi di decollo e atterraggio e alle eventuali situazioni di emergenza: in condizioni normali e tranquille, è il “pilota automatico” — vale a dire, oggigiorno, un sistema hardware/software molto complesso — a fare il grosso del lavoro.

Questi sistemi si sono evoluti negli ultimissimi decenni al punto che gli aerei sono dotati di numerosi sensori (temperatura, umidità, velocità, assetto, geolocalizzazione… e stiamo semplificando oltremodo) sempre più sofisticati che inviano enormi quantità di dati agli elaboratori. L’analisi e la “comprensione” di questi dati indica al sistema di guida automatica quali aggiustamenti adottare e quali comportamenti imporre agli organi meccanici del volo.

Questo tipo di approccio basato su sensori e software ha consentito, ad esempio, di ridurre al minimo gli sprechi di carburante, di migliorare l’efficienza dei velivoli, di prevenire e fare fronte a certi malfunzionamenti dei quali un pilota si sarebbe accorto solo con estrema difficoltà e così via.

Problemi di sistema

Ciò che però sta emergendo in queste ultime settimane, e che già appariva ipotesi plausibile di lavoro fin dal primo incidente, è che se il software funziona male, esso finirà per complicare — se non addirittura compromettere — il volo, invece di renderlo più lineare e sicuro. Ovvietà degna di un Massimo Catalano [1], di cui si potrebbe quasi sorridere se fosse, appunto solo una battuta e non ci fosse di mezzo la morte di circa trecentocinquanta persone. Ma purtroppo è la cruda verità.

A essere precisi, il problema riguarderebbe proprio il sistema di controllo nel suo complesso (MCAS, Maneuvering Characteristics Automation System) non solo nell’aspetto software, ma anche in qualche elemento hardware, come emergerebbe da recenti test [2].

Ad ogni modo, che la situazione sia grave è dimostrato anche dal fatto che, dopo il secondo incidente, tutti gli aerei dello stesso modello sono stati fermati e non voleranno più fino a risoluzione della questione.

Ma in cosa consiste esattamente questo malfunzionamento? Semplificando al massimo, in presenza di una serie di parametri che segnalano un certo tipo di instabilità e di perdita di quota, il sistema di controllo automatico correggerebbe al contrario l’assetto dell’aereo, puntando la prua verso il basso invece che verso l’alto! Oltretutto, a un tentativo di correzione manuale da parte del pilota umano, corrisponderebbe una ulteriore, errata correzione del sistema, il che avrebbe causato la caduta dell’aeromobile. La cosa va ancora approfondita, ma, a grandi linee, il problema sembra configurarsi in questi termini.

Tagliare i costi… a tutti i costi

Ma l’aspetto più inquietante che sta emergendo è questo: alla base di gran parte dei problemi di cui stiamo parlando ci sarebbe l’ossessione di Boeing per tagliare i costi di sviluppo e produzione. Scottata da un successo della concorrente Airbus che nel 2010 aveva progettato un nuovo aereo molto efficiente sul piano del risparmio di carburante il quale, anche per questo, aveva incontrato subito l’interesse di acquisto di molte compagnie aeree, Boeing decise di correre ai ripari cercando di comprimere tempi e costi per lo sviluppo del suo nuovo aereo di tipologia analoga.

Reingegnerizzare un prodotto vincente

Una delle prime scelte adottate in tal senso fu quella di non creare un velivolo completamente nuovo, ma di far evolvere e reingegnerizzare un progetto vincente come quello del 737 che, dalla fine degli anni Sessanta fino alle nuove incarnazioni degli anni Novanta, aveva rappresentato un caposaldo dell’industria aeronautica. Il Boeing 737 MAX sarebbe stata la quarta generazione di una consolidata linea di aeromobili.

Reimpiegare personale già formato

Un altro aspetto importante nella strategia di riduzione di tempi e costi adottata dalla Boeing per il nuovo 737 MAX comportava che i piloti non avrebbero necessitato di riqualificazione e di nuovi brevetti: per quanto il nuovo modello presentasse ovviamente delle novità, esso non si discostava eccessivamente da quelli precedenti. Questo implicava che i piloti dei vecchi 737 non avrebbero necessitato di un nuovo addestramento su un nuovo modello — con conseguente aumento dei costi e dei tempi per le compagnie che l’avrebbero acquistato — ma solamente di un “aggiornamento” sulle novità introdotte: un ulteriore bel risparmio.

Tra l’altro, tale aggiornamento, sarebbe stato svolto su computer o tablet e non avrebbe necessitato di sistemi di simulazione più complessi e costosi. A tal proposito, il pilota Chesley Sullenberger, divenuto celebre per l’atterraggio di fortuna sul fiume Hudson di una decina di anni fa raccontato poi anche in un film, ha osservato che, al contrario, qualche ciclo di addestramento su un simulatore “fisico” di grande realismo avrebbe consentito ai piloti di prendere effettiva confidenza con il reale comportamento dell’aereo nella situazione problematica [3].

Sviluppare i sistemi in outsourcing

Ulteriore passo per tagliare i costi fu quello di esternalizzare lo sviluppo del software che avrebbero fatto funzionare diverse parti del sistema di controllo di volo. In particolare, sulla base di informazioni attendibili raccolte in modo non ufficiale — le aziende direttamente coinvolte non hanno rilasciato dichiarazioni ufficiali in tal senso — due aziende indiane si sarebbero occupate dello sviluppo del software per la strumentazione e l’equipaggiamento di volo: la HCL e la Cylent Ltd.

Alla base di questa scelta ci sarebbe stato un duplice ordine di motivi: da un lato il desiderio di ridurre i costi, con il personale tecnico delle aziende indiane pagato 9-10 dollari orari a fronte dei 35-40 dei corrispondenti professionisti statunitensi. Dall’altro, il fatto che Boeing aveva promesso investimenti in quello Stato a fronte di grossi acquisti da parte delle compagnie aeree operanti India avvenuti negli anni preecedenti.

Con ogni probabilità, questo secondo ordine di motivi ti natura “politico-commerciale” ha finito per pesare di più: In realtà, la riduzione dei costi e la compressione dei tempi ipotizzate inizialmente con l’outsourcing dello sviluppo dei sistemi software in India non si sono poi rivelate così drastiche, dal momento che spesso è stato necessario un “rimpallo” continuo tra sviluppatori in India e casa madre negli USA, con un meccanismo che ben conosce chiunque, anche solo per poco tempo, abbia lavorato in un progetto che prevedesse sviluppo offshore.

Nonostante le affermazioni [4] fatte da un manager della Boeing secondo cui non sarebbero serviti ingegneri esperti perché il livello di maturità del software era già avanzato e ad esso avrebbe potuto lavorare anche personale qualificato ma senza grande esperienza, alla prova dei fatti le cose non si sono dimostrate così lineari.

“Fu vera gloria?”

O, meglio, traducendo la citazione poetica nel concreto, fu vero risparmio? No di certo se guardiamo la questione in termini assoluti: al di là della perdita di vite umane, che resta indiscutibilmente al primo posto, le perdite economiche sono state notevoli.

Anzitutto, il risparmio effettivo sui costi di sviluppo software non è stato così drastico come si poteva pensare: il rapporto di 1 a 4 per quello che riguardava il costo della “manodopera” è stato molto diluito dal fatto che, per le ragioni più disparate — distanza geografica, diversità culturali, difficoltà comunicative — molte cose andavano comunque rifatte una volta completate, con aggravio di tempi e costi.

Poi, la gravità degli incidenti ha intaccato pesantemente il valore di Boeing come azienda: si calcola che praticamente nel giro di un giorno, Boeing abbia perso più di 6 miliardi di dollari sul mercato! [5]

E infine, c’è un costo culturale non indifferente da pagare: se le indicazioni che arrivano dal management mettono al primo posto risparmio e velocità a scapito anche della qualità del software consegnato e del miglioramento continuo, alla fine gil sviluppatori si adegueranno e conformeranno le loro pratiche a quella esigenza. Si perde di vista il metro di misura, che in definitiva è il software funzionante, a favore del rendere contento il management che impone determinate richieste. E di questo fatto si avevano numerosi segnali, riscontrabili nelle dichiarazioni di alcuni sviluppatori che tendevano a mettere il luce solo i tempi rispettati o i risparmi ottenuti senza parlare della effettiva qualità del software rilasciato.

Buone pratiche di sviluppo

A fronte di tutti gli elementi visti fin qui — e ovviamente in attesa di ulteriori sviluppi della questione e della risoluzione dei problemi finora riscontrati sugli aerei 737 MAX che continuano a non volare fino a nuovo ordine — basterebbe un semplice riepilogo di alcuni principi e pratiche Agile.

Software funzionante

Uno dei valori del Manifesto per lo sviluppo agile di software [6] afferma di considerare importante “Il software funzionante più che la documentazione esaustiva” e specifica ulteriormente questa affermazione nel principio “Il software funzionante è il principale metro di misura di progresso”.

È evidente che, nel caso che stiamo esaminando, queste proposizioni non siano state tenute nella debita considerazione. Sono mancate — o più probabilmente sono state trascurate, visti i limiti di tempo e di budget — alcune pratiche che avrebbero garantito una migliore qualità del software:

• la scrittura di congrui criteri di accettazione;
• un Test Driven Development (TDD) fatto bene;
• politiche approfondite di Software Inspection / Code Review;
• una adeguata simulazione in produzione usando pratiche di Continuous Integration/Continuous Delivery (CI/CD);

e altro ancora.

La cosa assurda è che spesso queste pratiche sono messe in atto per realizzare codice in contesti commerciali “normali” e dovrebbero a maggior ragione essere utilizzati in contesti life-critical.

Conoscenza collaborativa

Altro aspetto da non sottovalutare è quello espresso nei principi [6] che recitano “Gli individui e le interazioni più che i processi e gli strumenti” e “La collaborazione col cliente più che la negoziazione dei contratti”.

Uno degli aspetti negativi che emerge con maggior chiarezza è un approccio “a silos” nello sviluppo di questi sistemi. Non è stata ottimale l’interazione fra i diversi attori coinvolti, né tantomento la collaborazione con il cliente “finale”. Che in questo caso andava individuato non solo nella azienda che costruisce l’aereo, ma anche nei piloti che lo guidano.

Non c’è stato l’apporto di conoscenza che i piloti avrebbero potuto fornire — e l’indicazione del retraining da fare al computer o sul tablet invece che al simulatore già spiega tanto… — e non c’è stata ricerca di varie soluzioni possibili, emergenti. Probabilmente la necessità di bruciare le tappe e tagliare i costi ha ridotto anche le possibilità e i tempi a disposizione per la ricerca: ricerca di soluzioni tecniche migliori (altri linguaggi di programmazione? altre architetture di sistema? altri tool di sviluppo?) e qui si finisce a parlare di eccellenza tecnica che è un altro tema importante del Manifesto Agile (“La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità”).

Conclusioni

I prossimi mesi forniranno finalmente risposte dettagliate su cosa sia successo veramente negli incidenti aerei che hanno imposto lo stop a terra di tutti i Boeing 737 MAX. Ma già fin d’ora è possibile individuare una serie di principi e buone pratiche che dovranno guidare lo sviluppo del software per correggere gli errori riscontrati.

L’ossessiva politica di riduzione dei costi e di abbreviamento dei tempi ha portato a pratiche controproducenti: gli errori compiuti, già problematici in contesti “normali”, non possono essere ripetuti in situazioni mission-critical laddove, al di là dei profitti di una grandissima azienda, sia a rischio anche la vita delle persone.