EMB_62

EMBEDDED

62 • NOVEMBRE • 2016

SOFTWARE

DEVOPS

ti, in un’organizzazione, il personale dedicato allo

sviluppo del codice collauda il nuovo software in un

ambiente di test, per poi rilasciarlo alle operation

in produzione, che successivamente si preoccupano

della sua manutenzione. L’inconveniente di questa

modalità di sviluppo sequenziale (modello ‘water-

fall’ o ‘a cascata’) è che passa troppo tempo tra i di-

versi rilasci del software, e che i due team di lavoro

esigenza di rilasciare il codice con maggior velocità

e frequenza, per rispondere con agilità alle dinami-

che necessità del business. Quello che invece serve

è implementare un costante processo di monitorag-

gio, sviluppo, integrazione e distribuzione del sof-

tware, e le iniziative DevOps possono permettere il

raggiungimento di questo obiettivo.

Il modello DevOps è di certo al momento un approc-

cio di sviluppo molto attuale e applicato negli am-

bienti IT, dov’è al centro dell’attenzione soprattutto

per l’opportunità che fornisce di rispondere ai nuovi

requisiti di velocità ed evoluzione del software, im-

posti dal cloud e dall’economia dei servizi digitali:

nell’era digitale diventa infatti essenziale riuscire a

facilitare il continuo sviluppo di nuove funzionali-

tà in prodotti e servizi, per raggiungere la massima

soddisfazione degli utenti.

In modo analogo, nel mondo embedded, l’implemen-

= 9 3

À F

qui tuttavia il processo d’adozione sembra trovarsi

ancora agli inizi. Lo indicano alcune recenti analisi

sul tema condotte dalla società VDC Research, che

evidenziano come il settore embedded stia sì conti-

nuando a muoversi verso una maggior collaborazio-

ne, ma con il rischio che i vantaggi promessi dalle

= 9

canza delle tecnologie e dei cambiamenti culturali

necessari. Da un lato infatti le metodologie DevOps

stanno arrivando a un punto critico di considerazio-

ne, in cui gli OEM sono preoccupati di migliorare

& À

dove anche i timori iniziali verso le tecniche di svi-

luppo agili tendono a scomparire, lasciando spazio

a un approccio ibrido, che combina lo sviluppo sof-

tware iterativo con il rigore necessario per la proget-

tazione dei sistemi embedded. Dall’altro lato, però,

rileva VDC, l’adozione di DevOps come framework

è ancora incerta, perché lo sviluppo iterativo è ti-

picamente più utilizzato come aggiunta strategica,

che sostituire, le vecchie e consolidate pratiche di

progettazione.

Ostacoli da superare

per un futuro più produttivo

Negli ambienti di sviluppo dedicati ai sistemi em-

bedded, applicare l’approccio metodologico de-

finito come ‘continuous delivery’ (CD) presenta

maggiori ostacoli, rispetto al settore IT. Alcune di

queste barriere sono analizzate in un post di David

Rosen, nel blog della società ElectricCloud. Su un

primo versante, c’è da considerare la grande ere-

dità di IP e quantità di base di codice (codebase)

proprietario in uso da lungo tempo, e spesso mo-

nolitico, quindi difficilmente scomponibile e gestibi-

le secondo le logiche del modello CD. In secondo

luogo, gli sviluppatori embedded, più di altri, hanno

una grande necessità di potenza computazionale,

richiesta dalla complessità dei progetti, che inclu-

dono componenti hardware e software. E a ciò si

aggiunge il problema di come integrare e gestire

in modo efficiente l’automazione di attività di test

basate su target fisici, quindi hardware embedded

diversi, spesso di tipo custom e ancora allo stadio

prototipale. Il fatto poi, osserva Rosen, che molti

sviluppatori embedded adottino linguaggi C/C++

per il loro ambiente di sviluppo software, piuttosto

che piattaforme come Java o .NET, comporta per

l’analisi di una ‘ baseline build’ dei lead time più

lunghi. Infine, sono da mettere in conto i costi e la

complessità di verifica del codice per la complian-

ce, ossia la conformità agli standard di qualità, si-

curezza e safety che molti prodotti embedded, ad

esempio nel settore medicale, automobilistico o

avionico, devono soddisfare rispetto alle normati-

ve vigenti. Tutto ciò, in conclusione, non semplifica

certo l’implementazione delle strategia di CD nel

mondo embedded.

Fig. 3 – Yocto

Project fornisce

agli sviluppatori

un framework

comune di stru-

menti e metodo-

logie per creare

sistemi Linux-

based custom

per prodotti

embedded, indi-

pendentemente

dall’architettura

hardware