EMB_79

EMBEDDED FEBBRAIO 64 SOFTWARE | SW TRACING DevOps per lo sviluppo embedded Consentire ai dispositivi IoT di inviare avvisi nel À ) soft- ware comporta notevoli vantaggi. La conoscenza diretta delle anomalie e la possibilità di effettuar- ne una diagnostica accurata creano un circolo virtuoso tra gli sviluppatori e il codice installato, consentendo ai primi di correggere gli errori in tempi più brevi e distribuire più rapidamente gli À ' 1 tipo, che va sotto il nome di DevOps (acronimo di Development/Operations), si è imposto come stan- dard nello sviluppo di applicazioni mobili e per il cloud e l’introduzione di piattaforme IoT basate su 1 À - À ) ' Dal punto di vista aziendale, il monitoraggio basato sulla meto- dologia DevOps si traduce in una riduzione del nu- mero di clienti insoddisfatti, in quanto il numero À ) alla presenza di bug nel codice di produzione sarà inferiore. La maggior parte del software embed- ded al momento del rilascio contiene alcuni errori che non sono stati individuati nonostante tutti gli À ! si manifestano direttamente a tutti gli utilizzatori. Esiste quindi un lasso di tempo utile per risolvere il problema prima che coinvolta un numero mag- giore di utilizzatori, a patto che si possa venire a conoscenza in anticipo dell’esistenza del problema stesso. Con DevAlert, gli sviluppatori vengono in- formati nel giro di pochi secondi dal primo avviso e la diagnostica del trace che viene fornita consente di effettuare l’analisi e la successiva correzione in ) ' / 1 - re un aggiornamento in modalità OTA automatico per risolvere il problema. La consapevolezza im- mediata dell’esistenza del problema e la diagnosi del trace possono contribuire a ridurre sensibil- mente il tempo richiesto per effettuare la corre- zione e minimizzare quindi il numero di clienti coinvolti. U À ) 2 non solo riduce i rischi connessi alla responsabilità delle aziende, ma anche i costi legati all’assistenza clienti, ai resi e al debug. La diagnostica che vie- ne fornita permette agli sviluppatori di riprodurre in modo molto più semplice le problematiche degli utenti in quanto possono ottenere informazioni direttamente dal dispositivo e non devono quindi À 1 della situazione. In assenza di un riscontro auto- ! À À per segnalare eventuali problemi e fornire infor- À ' d’errore generico come ad esempio “il sistema ha smesso di rispondere” non risulta particolarmente utile e potrebbero volerci parecchie settimane per individuarne la causa. E anche allora si tratterà di un’ipotesi in quanto non è possibile accertarsi che sia stato risolto il vero problema. Non solo bug Un aspetto da tenere in considerazione è il fatto che gli avvisi non devono necessariamente riguar- dare solamente i bug che non sono stati individua- ti e i malfunzionamenti che ne derivano. Poiché gli sviluppatori sono liberi di decidere dove e perché gli avvisi debbano essere generati, possono anche sfruttare questi ultimi per monitorare le metriche per la misura delle prestazioni dell’applicazione e visualizzare i motivi di problemi occasionali che riguardano le prestazioni. Il monitoraggio dell’in- terfaccia utente è anche fonte di utili informazioni. Si supponga una situazione in cui l’utente apra un menù su uno schermo touchscreen, come ad esempio quello del sistema di infotainment della vettura, e 1 À 2 navigazione. Per affrontare un problema di questo tipo lo sviluppatore dell’applicazione può prevedere l’avvio di un timer dopo ogni evento di input (quindi un tocco in questo caso) e la generazione di un avviso nel caso non venga rilevato un altro input entro un tempo prestabilito (ad esempio 5 secondi). La rice- zione di parecchi avvisi relativi alla medesima se- zione dell’interfaccia utente può essere un riscontro molto utile che può contribuire alla realizzazione di prodotti migliori e più semplici da utilizzare. In de- À ! software di trace e degli avvisi basati su cloud per i dispositivi installati sul campo comporta numerosi vantaggi e non dà luogo a com- plicazioni se si utilizza una soluzione come DevAlert di Percepio. In ogni caso, per sfruttare completa- Á di lavoro basato sull’approccio DevOps è richiesta la 2 À modalità OTA e la disponibilità di un’organizzazione di sviluppo reattiva in grado di comprendere i limiti connaturati al collaudo del software e l’importanza di apportare miglioramenti su base continua anche successivamente al rilascio di un prodotto.