Integrazione di hardware e sviluppo software nella distribuzione di prodotti digitali

Ogni giorno il software diventa sempre più cruciale per il funzionamento del nostro mondo. Più software è contenuto nei prodotti, più complesso ne diventa lo sviluppo e maggiore è il margine di errore. Nel frattempo, la pressione per innovare e introdurre nel mercato prodotti complessi di qualità più rapidamente è più forte che mai. A questo si aggiunge la sfida di gestire in modo efficiente i flussi di sviluppo paralleli di innovazione hardware, software e dei servizi, garantendo la trasparenza e integrando tutti questi elementi in un unico prodotto.

I produttori che non vogliono restare indietro nella corsa all'ottimizzazione dello sviluppo di prodotti complessi devono fare evolvere in modo significativo i processi, i sistemi e la mentalità del team. In caso contrario, rischiano di essere sostituiti da concorrenti che hanno concepito le proprie aziende su misura per questi obiettivi sin dall'inizio.

Il fattore chiave di questa evoluzione:

• Stabilire una visione metodica del sistema complessivo
• Usare metodi di Systems engineering
• Aprire l'organizzazione al pensiero interdisciplinare
• Utilizzare strumenti PLM/ALM adeguati

Da un punto di vista commerciale, questi sviluppi rappresentano sia un'opportunità sia una sfida per i produttori. Un'opportunità perché, a causa dell'aumento della concorrenza e della pressione verso l'innovazione, i prodotti basati su software consentono di ridurre i tempi di sviluppo e creare modelli di business assolutamente nuovi.

Ma perché una sfida?

Team interdisciplinari

Nonostante la riduzione delle soluzioni temporanee dal punto di vista meccanico, per lo sviluppatore del prodotto la complessità del sistema complessivo aumenta a causa di tutto il software e della stretta interrelazione tra questi componenti. Inoltre, per il software stesso esistono team di sviluppo diversi che gestiscono tutti i cicli di innovazione, ma a modo proprio e alla propria velocità. È difficile coordinarne il lavoro e integrare questi flussi di sviluppo paralleli.

Convalida del sistema

I produttori devono anche tenere conto del modo in cui l'intero sistema può essere convalidato, in particolare nel contesto di prodotti strategici per la sicurezza. A seconda del settore e del prodotto in questione, gli standard richiedono che ogni fase di sviluppo e modifica sia riconducibile ai requisiti originali.

Toolchain disconnesse

I toolkit utilizzati per lo sviluppo software si sono evoluti in ciò che oggi conosciamo come l'Application Lifecycle Management (ALM) e il modello di processo associato è stato integrato nel Systems engineering moderno. Tuttavia, in molte aziende l'attenzione era ed è tuttora rivolta alla gestione dei molti singoli componenti. Il processo che va dalla definizione coerente dei requisiti fino al prodotto finito non sempre è supportato da un concetto di gestione del ciclo di vita del prodotto (PLM), con metodo e strumenti, stabilito in modo coerente nell'intera azienda.

Per quanto riguarda l'integrazione di sempre più software in aziende che sono cresciute concentrandosi principalmente su prodotti meccanici ed elettromeccanici, possiamo osservare queste tendenze:

Approccio A: il software viene trattato come appendice dell'hardware

Questo avviene quando il software è considerato un'estensione o un'aggiunta rispetto all'hardware, come a suggerire: "Questo piccolo strumento software è solo un altro numero di parte". I componenti software sono equiparati a quelli elettromeccanici e viene loro assegnato un numero di parte. Pur potendo ancora identificare almeno la ECU in una struttura di prodotto, in definitiva sarà impossibile riconoscere tutte le dipendenze reciproche in una distinta base piatta.

Approccio B: ALM e PLM coesistono fianco a fianco

In alcuni casi, parallelamente alla gestione del ciclo di vita del prodotto (PLM) viene configurato un ambiente parallelo indipendente per la gestione del ciclo di vita dell'applicazione (ALM). Qui potremmo descrivere la situazione come: "Non so che cosa fanno e neanche mi interessa".

Liberati dai vincoli dello sviluppo elettromeccanico, gli sviluppatori di software possono esprimere a pieno le proprie capacità dinamiche nell'ambiente ALM. Il software viene ottimizzato per soddisfare le attuali esigenze dei clienti in brevi iterazioni e in modo molto agile.

Tuttavia, quello che in genere viene trascurato in uno scenario di separazione completa è la sincronizzazione reciproca tra i mondi PLM e ALM, producendo purtroppo un'incoerenza che si riflette sulla produzione e sul prodotto finito.

Sfortunatamente, nessuno dei due scenari delineati sopra è ideale per la simbiosi funzionale tra ingegneria meccanica, elettronica e software complesso.

L'"arte" dell'ottimizzazione dello sviluppo di prodotti basati su software consiste nello stabilire processi, metodi e strumenti che offrano a tutte le parti coinvolte trasparenza, uno spazio efficiente per collaborare e tutti gli strumenti necessari per crescere.

Detto questo, i singoli settori devono ancora essere coordinati per garantire che il prodotto finale soddisfi tutti i requisiti e le funzioni come un'unica unità. Tuttavia, non è solo una questione di strumenti e metodologia. È necessario anche un cambiamento organizzativo ampio e profondo, che deve essere fortemente voluto. È consigliabile assegnare a qualcuno un ruolo attivo nella supervisione delle modifiche e fornire linee guida efficaci per il coordinamento all'interno dell'organizzazione.

Come mossa successiva, il processo di sviluppo collaborativo deve essere controllato attivamente nel complesso ambiente dello sviluppo tecnologico. I metodi utilizzati nel Systems engineering forniscono basi adeguate. Questi includono già toolkit estremamente utili che possono essere utilizzati per modificare tutti i componenti di un prodotto o di un sistema in base ai requisiti condivisi.

Che si tratti di implementare uno degli standard di Systems engineering esattamente in base a quanto specificato o semplicemente utilizzarlo come linea guida è quasi una questione di preferenze, a meno che, naturalmente, non si debba dimostrare ai clienti o ad altre parti interessate la conformità a determinati standard (come richiesto in alcuni settori), caso in cui la prima opzione diventa fondamentale.

Il fondamento metodologico

È fondamentale che l'azienda scelga un modello procedurale appropriato (come il modello a V, ad esempio) e lo utilizzi come bussola.

Che cosa significa nel contesto di un prodotto basato su software? È fondamentale pensare sin dall'inizio a quello che il prodotto deve essere in grado di fare e quali altri requisiti (ad esempio, gli standard) deve soddisfare. È bene procedere nel modo più imparziale possibile e senza un approccio specifico in mente.

I passaggi successivi sono indicati di seguito.

• Descrivere quello che il prodotto deve essere in grado di fare
• Dividere il sistema in modo sensato in fase di architettura
• Fornire una prima definizione astratta delle interdipendenze
• Creare un meccanismo di sincronizzazione

È importante tenere presente che, nonostante tutti gli sforzi tesi alla semplicità, le interdipendenze tra sottosistemi hardware e software possono rapidamente diventare molto diversificate e complesse. È quindi essenziale che il reparto IT aiuti a tenere traccia di tutte queste interdipendenze nel miglior modo possibile.

La definizione del tipo di modello metodologico descritto sopra è alla base della capacità di sviluppare con successo prodotti basati su software in modo affidabile durante l'intero processo di sviluppo. Un modello completo di Systems engineering, in particolare, fornisce supporto cruciale.

Oggi la maggior parte delle aziende sta già mettendo in pratica molti di questi concetti in un modo o nell'altro. Spesso manca semplicemente un coordinamento ottimizzato e più orientato agli obiettivi, che può essere ottenuto cambiando mentalità, ponendo qualcuno al comando e usando strumenti adeguati per supportare l'iniziativa.