ALM, PLM, SE, MBSE, Digital Thread — chi si occupa di sviluppo prodotto si muove in un vero dedalo di acronimi. La parte insidiosa è che la maggior parte di questi termini ha senso nel proprio contesto specifico. Ma chi non conosce i collegamenti, cosa vale dove e in quale contesto, si ritrova semplicemente confuso. Un vero bullshit bingo.
L’ALM ne è un esempio perfetto: Application Lifecycle Management. A volte indica un approccio di management, a volte un tool, a volte qualcosa di completamente diverso. È tempo di fare chiarezza.
ALM come approccio di management
Da un lato, ALM indica un approccio di management a 360 gradi: l’obiettivo è accompagnare l’intero ciclo di vita di un’applicazione o di un software, dalla prima idea allo sviluppo e all’esercizio, fino alla manutenzione e al «End of Life». Nel migliore dei casi vengono coinvolte tutte le discipline e tutti gli attori: sviluppo, test, esercizio, quality management, product owner e così via.
L’ALM diventa così la cornice di management sotto la quale i processi sono definiti con chiarezza, i passaggi di consegna fluidi e le informazioni trasparenti.
ALM come categoria di tool
Nella pratica, però, ALM viene usato almeno altrettanto spesso come sinonimo di una determinata classe di tool software. Nomi come Polarion, Codebeamer, Jira, Azure DevOps o IBM Engineering Lifecycle Management sono ormai un punto fermo in molte aziende. Questi tool offrono di solito un’intera gamma di funzioni:
-
Gestione dei requisiti
-
Test management
-
Gestione di task e bug tracking
-
Gestione delle modifiche e gestione della configurazione
-
Tracciabilità (Traceability)
-
Reporting e automazione
L’obiettivo: riunire su un’unica piattaforma il maggior numero possibile di fasi del processo di sviluppo, per evitare interruzioni nel flusso di informazioni tra i sistemi e facilitare la collaborazione. Spesso con interfacce verso sistemi di gestione del codice sorgente come Git o simili.
Un mercato in movimento, tra l’altro: Polarion fa ormai parte di Siemens, Codebeamer di PTC. I grandi fornitori di PLM hanno inserito nel proprio portfolio strumenti ALM in modo mirato. Già questo mostra come i confini tra le categorie siano tutt’altro che netti. Ne parlerò più avanti.
L’ALM oltre lo sviluppo software
Molti di questi «tool ALM» oggi non vengono più utilizzati solo per i progetti software. Alcune aziende li usano come piattaforma centrale per il Systems Engineering, cioè per la gestione di prodotti complessi in cui il software è solo uno dei tanti elementi.
Mi è anche capitato di vedere ALM usato semplicemente come sinonimo di tool per la gestione dei requisiti. Non è del tutto sbagliato: la gestione dei requisiti è in effetti uno dei grandi punti di forza dei tipici tool ALM. Ma rappresentano molto di più. Chi riduce l’ALM alla gestione dei requisiti si lascia scappare buona parte del potenziale.
Proprio nei settori regolamentati come automotive, dispositivi medici o aerospaziale emerge un altro schema: lì i tool ALM sono spesso in uso soprattutto per le loro capacità di documentazione e dimostrazione di conformità (parola chiave: traceability), non solo per le classiche funzioni di sviluppo software.
ALM, PLM e Systems Engineering: chi sta dove?
Ho perso il conto di quante volte, internamente, ci siamo «scontrati» sulla domanda se l’ALM stia a fianco del PLM o ne sia una parte. La risposta è al tempo stesso deludente e rassicurante: entrambe le affermazioni sono corrette. Dipende da quale prospettiva si guarda.
Nei prodotti puramente software, ALM è l’equivalente del PLM (Product Lifecycle Management): comprende tutti i compiti del lifecycle management, ma riferiti al software. In questo caso ALM sta a fianco del PLM.
Nei prodotti meccatronici (prodotti fisici con componenti software), invece, l’ALM è tipicamente un sottoinsieme all’interno del PLM, più ampio: il PLM governa il prodotto nel suo complesso, dall’idea allo sviluppo e alla produzione fino alla messa fuori servizio, mentre l’ALM si occupa delle componenti software. Sempre che si voglia davvero fare questa distinzione, perché nella situazione ideale i due mondi sono strettamente integrati, dal punto di vista tecnico e organizzativo. Ad esempio tramite interfacce e una traceability continua, affinché requisiti, modifiche ed evidenze restino coerenti attraverso tutte le discipline.
PLM e ALM descrivono il ‘cosa’, il Systems Engineering il ‘come’ e i tool sono il ‘con cosa’
E come si inserisce il Systems Engineering in questo quadro? Anche qui aiuta la distinzione fatta all’inizio:
Se si intende l’ALM come categoria di tool, la questione è chiara: il tool ALM è uno strumento, il Systems Engineering è la cassetta degli attrezzi metodologica. Nella pratica, i tool ALM vengono quindi spesso usati come piattaforma per il Systems Engineering: supportano esattamente ciò che il SE richiede dal punto di vista metodologico, cioè la collaborazione tra le discipline e la tracciabilità continua dal requisito al test.
Se invece si intende l’ALM come approccio di management, le cose si fanno più complicate. In questo caso l’ALM (come anche il PLM) è piuttosto un termine ombrello astratto per il cosa: quale ciclo di vita, quali artefatti, quali responsabilità vengono gestiti. Il Systems Engineering descrive il come: con quali metodi si sviluppa. Ma solo per una parte di ciò che rientra nell’ALM — ad esempio bug tracking, DevOps e support non sono tipicamente terreno del SE.
Se si vuole ridurlo a una formula: PLM e ALM descrivono il cosa, il Systems Engineering il come, e i tool sono il con cosa. Come ogni formula, semplifica, ma come bussola per orientarsi nel dedalo terminologico funziona benissimo.
Conclusione: l’ALM è quello che se ne fa
Chi parla di ALM dovrebbe quindi sempre fermarsi un momento e chiarire cosa intende esattamente:
-
Si tratta dell’approccio di management complessivo?
-
Di metodi di sviluppo per lo sviluppo software?
-
Di un tool specifico o di una categoria di tool?
-
Di un caso d’uso molto specifico, come il Requirements Engineering, o del supporto ad altre capability di Systems Engineering?
-
O del ruolo dell’ALM in relazione al PLM per il prodotto nel suo complesso?
La risposta è quasi sempre: «dipende». E va benissimo così, purché tutti i soggetti coinvolti condividano la stessa comprensione. Il bullshit bingo iniziale non nasce perché i termini sono sbagliati, ma perché vengono usati senza contesto.
Un’ultima cosa: l’ALM non è un progetto che si realizza una volta e si archivia. È un campo che evolve insieme ai prodotti, ai metodi di sviluppo e ai requisiti normativi. Questo lo rende impegnativo e costantemente rilevante.
L’ALM è polisemico — e va bene così. L’importante è che tutti i soggetti coinvolti intendano la stessa cosa. E che i tool, i processi e i metodi scelti corrispondano alle esigenze reali, non a un’immagine generica di ALM da manuale.
Stai pianificando un’iniziativa ALM o sei nel bel mezzo di uno di questi temi? Contattami pure: in BHC e PROSTEP affianco le aziende nella strategia, nella scelta dei tool e nell’implementazione. In modo neutrale rispetto ai fornitori e con un approccio pratico.
Domande frequenti
Cosa significa ALM (Application Lifecycle Management)?
ALM sta per Application Lifecycle Management e nella pratica viene usato in due modi: come approccio di management a 360 gradi, che accompagna un software dalla prima idea allo sviluppo e all’esercizio fino all’End of Life, oppure come denominazione di una categoria di tool come Polarion, Codebeamer o Azure DevOps. Quale significato sia quello giusto emerge solo dal contesto.
L’ALM è la stessa cosa del PLM?
Non del tutto, dipende dal prodotto. Nei prodotti puramente software, l’ALM è l’equivalente del PLM e sta al suo stesso livello. Nei prodotti meccatronici con una componente software, invece, l’ALM è di solito un sottoinsieme all’interno del PLM più ampio, che governa il prodotto nel suo complesso tra hardware e software.
Quali tool rientrano tra i tool ALM classici?
Tra i tool ALM più conosciuti figurano Polarion (Siemens), Codebeamer (PTC), Jira, Azure DevOps e IBM Engineering Lifecycle Management. Tipicamente coprono su un’unica piattaforma gestione dei requisiti, test management, gestione di task e bug tracking, gestione delle modifiche e della configurazione, oltre a traceability e reporting.
Che relazione c’è tra ALM e Systems Engineering?
Il Systems Engineering è la cassetta degli attrezzi metodologica, i tool ALM ne sono spesso la piattaforma. Se si intende l’ALM come categoria di tool, i tool ALM supportano esattamente ciò che il SE richiede dal punto di vista metodologico: collaborazione tra le discipline e tracciabilità continua dal requisito al test. Se si intende l’ALM come approccio di management, il SE descrive piuttosto il ‘come’ per una parte di ciò che l’ALM comprende come ‘cosa’.
