SW-ALM: perché usiamo ALM Tool per lo sviluppo della stazione meteo

SW-ALM: perché usiamo ALM Tool per lo sviluppo della stazione meteo

Questo articolo apre una nuova mini-serie che collega la parte teorica del metodo MBSE e di Magic Grid® al lavoro quotidiano di sviluppo software, riprendendo il discorso lasciato aperto nell’articolo sulla ISO/IEC 15288 e 12207: il modello a V governa la struttura di sistema, l’Agile governa il ritmo con cui il software evolve dentro quella struttura. Qui vediamo con quale strumento, concretamente, gestiamo quel ritmo.

Cos’è un ALM (Application Lifecycle Management)

Un ALM è la categoria di software che tiene insieme, in un unico posto tracciabile, le cose che normalmente finiscono sparse tra fogli di calcolo, email e chat: requisiti, backlog di sviluppo, versionamento del codice, bug, decisioni tecniche, documentazione. Non sostituisce l’IDE o il compilatore: sostituisce il caos di “dove avevamo scritto quel requisito?” con un grafo di riferimenti espliciti tra un requisito, il task che lo implementa, il commit che lo chiude e il test che lo verifica.

Per un progetto MBSE come il nostro, dove la matrice di tracciabilità (vedi MBSE 4 (pubblicazione in arrivo)) è già parte del metodo, un ALM è il passo naturale: prende quella tracciabilità e la rende uno strumento vivo, invece di una tabella statica che va aggiornata a mano.

Perché ALM Tool

Abbiamo scelto ALM Tool, piattaforma ALM open source (licenza GPLv2) nata nel 2011, per alcuni motivi concreti:

Open source e self-hosted — nessun vendor lock-in, il codice sorgente è ispezionabile e l’istanza gira su infrastruttura nostra.
Copre l’intero ciclo in un solo prodotto: Tracker per i requisiti, Git per il versionamento, Agile Dashboard per backlog/sprint, Document Manager per la documentazione — niente da integrare tra tool diversi.
Pensato per contesti ingegneristici complessi, non solo per lo sviluppo software puro: i Tracker sono configurabili al punto da rappresentare requisiti di sistema, non solo bug o user story.

I moduli che useremo

Tracker — per rappresentare requisiti di business, di sistema, di sottosistema e casi di test come artefatti collegati tra loro (lo vediamo nel prossimo articolo).
Agile Dashboard — backlog, board Kanban e sprint per la parte firmware, seguendo il ritmo iterativo di cui parla la ISO/IEC 12207.
Git — repository versionati, con collegamento esplicito tra commit e requisito/task che chiudono.
Document Manager — per gli schemi elettrici, i datasheet e i documenti che accompagnano ogni tutorial.

Un dettaglio tecnico: una copia di riferimento

Un aggiornamento operativo, utile a chi segue progetti open source: abbiamo scaricato l’intero mirror del codice sorgente — oltre un milione di oggetti Git, tutti i 35 plugin ufficiali, la history completa — per avere una copia di riferimento indipendente. Ne parliamo meglio nell’ultimo articolo della serie, insieme a come abbiamo replicato quel mirror sulla nostra istanza.

Conclusioni e prossimo passo

Nei prossimi articoli vedremo concretamente: come i requisiti della serie MBSE diventano Tracker collegati (con tanto di link alla matrice di tracciabilità), come organizziamo il backlog Agile del firmware ESP32/Nordic in ALM Tool, e come il Git di ALM Tool chiude il cerchio tra requisito e commit. L’obiettivo non è la teoria dell’ALM in astratto, ma mostrare, con screenshot della nostra istanza reale, come MBSE e sviluppo software quotidiano possano vivere nello stesso processo tracciabile.