Nuova puntata del racconto sull‘esperienza di progettazione e programmazione del software per rover planetari presso l‘università del Tohoku. Sulla base di concetti quali proprio il kaizen di nipponica ascendenza, si continua a definire il sistema che andrà implementato, immersi nell‘afa di inizio estate. Senza dimenticare il piacere di un buon caffè, anche nella patria del thè verde…

La stagione delle pioggie

Vivere in un ambiente poco familiare come il Giappone richiede uno spirito di avventura e una forte capacità di adattamento. Nel primo mese e mezzo mi dovetti adattare, tra le altre cose, a un clima non particolarmente piacevole. Tra la fine di maggio e i primi di luglio, in Giappone c’è la cosiddetta stagione delle piogge. “Stagione delle piogge” è un nome ingannevole: più che piovere, c’è un’eccesso costante di umidità nell’atmosfera, una specie di nebbiolina calda e appiccicosa da cui non c’è riparo. La mattina presto, in particolare, si ha la spiacevole impressione di nuotare in una gigantesca gelatina, tiepida e molliccia. L’ombrello è quasi inutile in queste situazioni, e la giacca a vento fa sudare inutilmente, peggiorando la sensazione di umidità: l’unica soluzione è imparare a convivere con la cosa, senza dargli troppa importanza.

A volte attacca una pioggerella fine e persistente che puo durare 5 minuti o 10 ore. Per ovviare a questa seccatura, in Giappone gli ombrelli sono di fatto considerati proprietà pubblica. Se, al momento di uscire da un ristorante, scoprite che ha iniziato a piovere, potete prendere un qualunque ombrello e utilizzarlo fino alla prossima tappa, dove lo lascerete a disposizione di chiunque altro ne abbia bisogno. Ovviamente di quando in quando ci si trova costretti a comprare un ombrello nuovo per l’Universo: in questo caso il prezzo è poco meno di un euro al più vicino Seven-Eleven.

Un aroma familiare

Adattarsi a un ambiente diverso significa sperimentare e accettare le novità, con spirito curioso e attento. Ma una strategia che consenta di mantenere un buon equilibrio tra nuove scoperte e vecchie certezze richiede anche la capacità di trovare una costante, qualcosa che permetta di tornare per un attimo con il pensiero a ciò che è familiare. E cosa c’è di più familiare per un Italiano di un buon caffè espresso? Il Giappone è un grosso consumatore di thè; il caffè è considerato un prodotto di nicchia, e non è facile trovarne uno buono. Nella mia nuova sistemazione, a Sendai, ebbi la fortuna di trovare vicino alla facoltà di ingegneria un bar, il “Boook Cafe” (non è un errore… Boook è scritto proprio con tre “o”; del resto il concetto di “Engrish” dovrebbe ormai esservi familiare), che serviva un ottimo caffè espresso, buono come quello italiano e di costo solo lievemente superiore.

L’attività del bar è un’altra curiosa dimostrazione delle particolarità dell’approccio giapponese alla contaminazione culturale. L’es-pu-res-so sin-go-ru (nipponizzazione dei termini “espresso single”) che servivano era in tutto e per tutto equivalente al miglior espresso italiano: colore bruno, cremoso in superficie, caldo come un abbraccio e profumato come il mattino. Ma nonostante le ragazze del “Boook Cafe” utilizzassero una macchina identica a quelle che abbiamo qui in Italia, la preparazione di un espresso era un rituale tutto diverso, che comprendeva una attenta valutazione della quantità di caffè da utilizzare, una delicata pressione sul filtro, l’attesa paziente della percolazione, la pulizia della tazzina da eventuali gocce fuori posto e il posizionamento scientifico della tazzina all’interno del piattino, con il cucchiaino posto a una precisa angolazione rispetto al manico della tazzina. L’operazione richiedeva quasi un minuto, il tempo che impiega un barista italiano a servire 50 caffè nell’ora di punta. Ma non c’era mai fretta al Boook Cafè, e in breve cominciai ad apprezzare l’approccio contemplativo a un rituale, quello del caffè, che da noi finiamo a volte per compiere in maniera meccanica. Evidentemente, una millenaria cultura di ritualizzazione delle pratiche quotidiane (dalla preparazione del thè alla disposizione dei fiori, per esempio) ha ancora il suo peso anche nel Giappone moderno.

L’ambiente era talmente piacevole che ne feci il mio ufficio. L’assenza di Internet WI-FI e la necessità di lavorare con il rover nel laboratorio mi impedì di adottare questa sistemazione in pianta stabile, ma in ogni caso finii per trascorrere molto tempo in questo luogo, che ebbe un ruolo fondamentale nello sviluppo del mio progetto.

L’importanza di un nome

Nel frattempo mi stavo portando avanti con la mia soluzione. Ma c’era una cosa estremamente importante da fare prima ancora di iniziare il lavoro: definire un nome e un mission statement. Durante la mia analisi, avevo pesantemente criticato la politica di dare nomi criptici ai componenti di sistema. I nomi ricoprono un ruolo estemamente importante in un progetto. Fanno molto di più che descrivere una funzione o un componente: aiutano a definire l’identità di ogni elemento, il ruolo all’interno del sistema, i pattern utilizzati o più in generale la metafora sottostante. I nomi espandono il nostro linguaggio, e forniscono uno strumento per definire le interazioni tra le varie entità. I nomi rendono più facile la comunicazione, dando un soggetto preciso di cui parlare. Un grosso numero di problemi, in informatica come nella vita, sono la conseguenza di fraintendimenti nella comunicazione. Nel dare un nome, facciamo un passo avanti nella direzione della chiarezza, e utilizzando i nomi in maniera consistente semplifichiamo i nostri discorsi, riducendo l’ambiguità. I nomi insomma sono una parte integrante della soluzione, e non una semplice decorazione.

Nella mia posizione di Gaijin, mi sentii in dovere di fare un passo nella direzione di coloro che mi stavano ospitando. Avendo constatato una certa resistenza verso la lingua inglese, decisi di adottare nomi giapponesi. Il risultato fu fonte di grande ilarità: il mio uso del giapponese era chiaramente percepito come una sorta di “Engrish” al contrario; ma in ultima analisi aiutò a creare un clima di amicizia e complicità con i miei colleghi di laboratorio.

Kaizen

Il nome che scelsi per il progetto fu Kaizen 2010. Questo nome merita una piccola spiegazione. Tutto ebbe inizio a fine maggio, quando scrissi Kaizen 1, un programma di due righe di codice che mi richiese un pomeriggio di lavoro. Poi venne Kaizen 2, che era pieno di errori e non compilava. Quindi Kaizen 3, che aveva una piccola interfaccia grafica. Nelle settimane successive andai avanti con Kaizen 4, 5, 6 e così via, creando miglioramenti incrementali fino a “raggiungere la perfezione” con Kaizen 2010.

Kaizen è una parola giapponese composta dall parole KAI (= “cambiamento”) e ZEN (= “in meglio”), e denota un processo di miglioramento costante e senza fine. Kaizen è anche il nome di un processo industriale introdotto negli anni Cinquanta da William Demming per accelerare la ricostruzione del Giappone dopo la guerra. La parola Kaizen non ha un equivalente nella lingua inglese o italiana, e per questa ragione mi parve una scelta particolarmente azzeccata in questo caso: la mia intenzione era infatti di consegnare, oltre al sistema, un report che fornisse una documentazione del processo di sviluppo, in modo da lasciare ai ragazzi del laboratorio una traccia sulla quale sviluppare i loro lavori successivi.

Mission statement

Il mission statement è la definizione sintetica degli obiettivi di un progetto. Un mission statement breve e chiaro ha maggiori possibilità di essere capito di uno lungo ed articolato, un atteggiamento che premia la capacità di sintesi. Il mission statement di Kaizen 2010 era:

“Fornire strumenti user-friendly per il supporto decisionale alla navigazione e controllo semi-autonomo di un prototipo di rover planetario, in condizioni di ritardo di comunicazione.”

Il linguaggio è abbastanza tecnico (si tratta di “rocket science” dopotutto) per cui credo sia opportuna una piccola spiegazione. L’obiettivo di Kaizen 2010 era quello di fornire strumenti di supporto decisionale all’utente finale del sistema. Questi strumenti dovevano essere user friendly, ossia progettati tenendo a mente le esigenze dell’utente finale, e non quelle della macchina. Il supporto decisionale serviva a valutare la posizione del rover (navigazione) e a modificarla (controllo), con un meccanismo semi-autonomo. Semi-autonomo significa che l’operatore specifica un percorso, lasciando al rover la decisione su come implementarne l’esecuzione. Per finire, il sistema doveva permettere all’utente di operare in condizioni di ritardo di comunicazione, ossia una condizione in cui esiste un ritardo non trascurabile tra la generazione di un impulso e la ricezione del feedback (la Luna non è esattamente a qualche isolato di distanza).

Un sistema informativo spaziale

Yoshida e Keiji mi avevano chiesto di realizzare un’interfaccia grafica per il controllo target-based del rover. Mostrando forse una mancanza di tatto, avevo fatto presente che la soluzione preesistente andava scartata senza troppi complimenti. C’erano un sacco di ragioni dietro la mia proposta. La ragione più importante era che la soluzione preesistente era una collezione caotica di programmi che non costituiva un sistema. A mio avviso, questo stato di cose era una conseguenza del fatto che il problema non era stato configurato in maniera corretta al principio. Il controllo remoto di un rover è una funzionalità complessa, che richiede un approccio sistemico. Creare un’interfaccia grafica non è un problema particolarmente complesso, se le informazioni sottostanti sono presenti in un formato adeguato. Il problema reale è: come gestisco il flusso di informazioni?

Da una collezione di programmi a un sistema

Un sistema informativo è una qualunque combinazione di tecnologie informatiche e attività di utenti di tali tecnologie che supporta operazioni e processi di managment e decision making. Un programma denota una serie di funzioni, ed è progettato attorno alla macchina che lo esegue. Un sistema informativo denota una serie di interazioni, o azioni, che due o più attori mettono in atto l’uno sull’altro per raggiungere un certo obiettivo, ed è progettato attorno all’utente. Un programma è insomma un elemento di un sistema informativo.

Un sistema informativo comprende aspetti strettamente funzionali, come quelli attinienti alla programmazione, al design della base di dati, al design del sistema all’analisi delle performance e così via. Ci sono poi una serie di aspetti non funzionali, come l’ergonomia, il design dell’interfaccia grafica e il modello di interazione. In un progetto ben fatto, gli aspetti funzionali e gli aspetti non funzionali hanno una proporzione 80/20. Lo sviluppo degli aspetti funzionali, insomma, richiede quattro volte più tempo della progettazione e sviluppo di quelli non funzionali. Vuol forse dire che gli aspetti funzionali sono più importanti? Dipende tutto da qual è l’obiettivo del prodotto. In ogni prodotto destinato a un operatore umano, gli aspetti non funzionali contribuiscono per l’80% al successo. Prendete tre prodotti funzionalmente equivalenti, come Microsoft Word, Open Office e Apple Pages. Sul piano puramente funzionale, questi tre programmi fanno esattamente la stessa cosa: se escludiamo alcune funzionalità esoteriche, qualunque cosa puoi fare con uno la puoi  fare anche con l’altro. Ma sul piano dell’interazione con l’utente, questi tre sistemi per il word processing usano un approccio totalmente differente, al punto che l’utente di un sistema trova inconcepibile utilizzare gli altri due. Quel 20% di aspetti non funzionali produce pertanto l’80% di risultati in termini di successo dell’applicazione presso un certo pubblico.

Tempi di sviluppo

C’è poi un’altra considerazione da fare. Lo sviluppo di aspetti funzionali è un’attività laboriosa, che richiede molto tempo, ma che in compenso è per la maggior parte meccanica. Nella programmazione, la parte creativa copre circa un 20%, un 20% molto importante: tutto il resto è pura meccanica. Come unico sviluppatore di Kaizen 2010, mi fu chiaro dall’inizio che dovevo spendere le mie energie in quel 20%, e inserire il “pilota automatico” nel restante 80%. Il Boook Cafè mi fornì l’ambiente ideale per trascorrere quel lungo e noioso 80%, tenendo alto il morale con le sue paste e il suo caffè.

Il modello di interazione di sistema

Kaizen 2010 è un sistema che comprende tre attori: il rover El Dorado, un computer che agisce da ground station e l’operatore che ci lavora sopra. L’operatore è insomma parte integrante del sistema, e le sue interazioni devono essere progettate con attenzione. Progettare un sistema informativo senza considerare il ruolo dell’operatore è un errore di impostazione piuttosto grave, che produce una serie di problemi a cascata.

Ad alto livello, il flusso di dati è un ciclo che parte dal rover. Il rover produce informazioni di posizione (le coordinate cartesiane della posizione del rover all’interno di una mappa), di attitudine (gli angoli di orientamento relativo ai tre assi), l’odometria (direzione e velocità di rotazione di ciascun motore) e il rilevamento del rilievo topografico dell’ambiente che si trova di fronte al rover.

Queste informazioni vengono passate alla ground station, che produce una rappresentazione grafica e tabellare dello stato del rover. L’operatore a questo punto valuta le informazioni, compie una valutazione e progetta un percorso. Il percorso viene creato sulla ground station, e quindi inviato al rover sotto forma di istruzioni di alto livello (“vai alla posizione x1,y1, poi alla posizione x2,y2 e così via). Il rover a questo punto implementa la sequenza tenendo in considerazione valutazioni contingenti all’ambiente circostante.

Scendendo più nel dettaglio (figura 7), un rover planetario può essere visto come un sistema real-time per la raccolta e gestione delle informazioni provenienti dall’ambiente circostante. In ogni istante, un il rover processa informazioni provenienti dai sensori montati sulle ruote, e dai sensori ambientali, come scanner, telecamere e sensori di prossimità. Questi dati possono poi essere complementati da informazioni provenienti dalla piattaforma di atterraggio o da un satellite in orbita attorno al pianeta.

Il rover produce un flusso di informazioni, che viene analizzato a terra e salvato sul database di missione. L’operatore ha accesso a una rappresentazione grafica e testuale dello stato del rover. Questa informazione può essere complementata da informazioni storiche, tipo mappe o rilevamenti geologici, o dal risultato di simulazioni

L’operatore a terra può valutare l’ambiente e pianificare un percorso attorno agli ostacoli. Il percorso viene poi caricato nel rover ed eseguito in maniera semi-autonoma. Il rover deve avere una certa autonomia su come implementare il percorso, e allo stesso tempo deve avere dei meccanismi di rilevamento ostacoli che gli permettano di fermarsi quando ci sia un impedimento. Le informazioni di ritorno vengono analizzate dall’operatore.

Conclusioni

Con questa analisi ad alto livello del sistema che abbiamo implementato, ci fermiamo per questo numero. Nella prossima parte analizzeremo i modelli non funzionali che hanno guidato lo sviluppo del sistema.

Ma prima di concludere, voglio dare un saluto a una delle protagoniste di questo diario di viaggio: la mia cagnolina Emy è venuta a mancare a fine giugno 2011, proprio nei giorni in cui concludevo questo articolo. Chi ha avuto un animale domestico sa che non esistono parole per descrivere il vuoto che segue la scomparsa di un inseparabile compagno.

Emy è stata una costante nella mia vita, una compagna fedele e affettuosa che mi ha accompagnato nel mio percorso di crescita, e mi ha dato supporto nei momenti difficili. Dedico a lei questo articolo, in ricordo dei 12 meravigliosi anni passati assieme e delle mille avventure che abbiamo condiviso, incluso lo straordinario anno che abbiamo vissuto a Strasburgo nel mio periodo di permanenza alla International Space University.