Contrast:High contrast|Normal view
Qualità di un software (parte 3)
“Software Is Eating the World”, lo scriveva Marc Andreessen in un articolo pubblicato nel 2011 sul Wall Street Journal (n.d.t. “Perché il software si sta mangiando il mondo”) ed è chiaro che oggi siamo completamente dipendenti dal software. Negli anni è diventato una parte fondamentale di ogni prodotto/servizio e sta trasformando le aziende in qualunque settore rendendole sempre più “aziende software”. Tali cambiamenti stanno sconvolgendo interi mercati offrendo nuove opportunità e ponendo in discussione molte aziende leader che, spesso, faticano ad adattarsi mettendo a rischio la loro stessa esistenza.
Il software è sempre più un asset strategico per le aziende, indipendentemente dalla dimensione o dal mercato a cui si rivolgono. Ma la vera sfida è comprenderne il valore ed i costi associati (ad esempio relativi a manutenzione, evoluzione, ecc.). Questa non è un’operazione semplice e richiede competenze specifiche che vanno al di là di quelle di uno sviluppatore o di un project manager. Sono attività difficilmente standardizzabili e sono strettamente collegate alla ricerca sulla qualità del software portata avanti da grandi aziende software (IBM, Microsoft, Google, ecc.) e da centri di ricerca in tutto il mondo. Alcuni ambiti di applicazione sono:
- la valutazione del rapporto qualità/prezzo dei sistemi acquistati da un fornitore esterno
- la valutazione del rapporto qualità/costo dei sistemi sviluppati internamente
- il supporto alle decisioni relative ad effettuare sviluppi interni o esterni
- il supporto alla previsione dei costi di manutenzione di un prodotto (sia sviluppato internamente che esternamente)
- l’offerta di evidenze ai clienti riguardo la qualità dei sistemi venduti
- …
L’attività di valutazione non è solamente un’analisi tecnica di un sistema software ma comprende un’analisi più o meno dettagliata del contesto in cui tale sistema è stato sviluppato, le decisioni tecniche e di business correlate, la strategia aziendale, l’evoluzione del sistema nel tempo, ecc. Tutti questi aspetti permettono di avere un quadro più completo che non sarebbe possibile ottenere analizzando solamente il software.
Per comprendere meglio come viene effettuata questa tipologia di analisi, prendiamo come esempio quella effettuata presso Microtec srl, azienda con sede a Bressanone e leader mondiale nello sviluppo di sistemi per l’automazione di segherie che sviluppa internamente sia le macchine che i sistemi software di supporto. L’azienda voleva iniziare un percorso di miglioramento del livello qualitativo del proprio software per garantire capacità di mantenere e far evolvere nel tempo i sistemi software venduti. Per farlo era necessario ottenere una fotografia completa dell’azienda, analizzando il processo di produzione del software e il software stesso, coinvolgendo diverse figure professionali aziendali con il supporto del top management:
- Management: CEO, CTO, project manager
- Team di sviluppo: team lead, sviluppatori
Il coinvolgimento diretto del CEO ha permesso di identificare in modo chiaro gli obiettivi di alto livello, i prodotti e gli aspetti di qualità da prendere in considerazione. In particolare, si è deciso di focalizzare l’analisi sulla manutenibilità dei sistemi sia dal punto di vista della capacità di risolvere eventuali difetti sia dal punto di vista della possibilità di far evolvere i prodotti aggiungendo nuove funzionalità.
Una volta definita questa prima parte, insieme al CTO, sono stati analizzati in dettaglio aspetti più tecnici come l’organizzazione dei team di sviluppo a livello aziendale, l’organizzazione del codice, gli strumenti utilizzati, la comunicazione ed i processi decisionali che coinvolgono più team, ecc. Inoltre, si sono analizzati gli aspetti che caratterizzano i team di sviluppo localizzati nelle diverse sedi dell’azienda nel mondo e come vengono gestiti. Questa fase ha permesso di comprendere aspetti che riguardano sia il processo di produzione del software sia l’organizzazione generale del codice (in particolare lo sviluppo del codice condiviso tra diverse applicazioni).
Si è passati poi ai product manager che gestiscono i diversi prodotti. I sistemi sviluppati dall’azienda sono molto complessi e devono essere integrati con i dispositivi ed i sistemi già in uso presso i clienti. Quindi, risulta necessaria una attività preliminare di integrazione e di configurazione per adattarsi alle caratteristiche specifiche degli impianti (ad esempio tipo di legno trattato, caratteristiche funzionali delle macchine, ecc.). Le integrazioni e le personalizzazioni specifiche per ogni impianto devono essere implementate tenendo conto dell’evoluzione generale dei prodotti dell’azienda per garantirne la compatibilità con le future versioni ed effettuare aggiornamenti. La gestione di potenziali conflitti tra modifiche specifiche e quelle del prodotto è un aspetto che può influenzare la manutenibilità dei singoli impianti e dei prodotti stessi. Per questa ragione, con ognuno dei project manager si sono analizzati gli aspetti relativi alla gestione dei requisiti e dei feedback provenienti dai clienti.
A livello di team lead, si sono analizzati aspetti riguardanti il processo di sviluppo adottato, la gestione dei requisiti, la gestione delle personalizzazioni, la gestione del personale (in particolare la formazione dei nuovi membri del team). Inoltre, si è anche analizzata l’architettura del sistema ad alto livello e la documentazione esistente con le relative attività di gestione.
Infine, sono stati coinvolti gli sviluppatori concentrando l’analisi sull’organizzazione del codice, sull’architettura dei sistemi e sulle pratiche di sviluppo adottate. Inoltre, sono stati considerati aspetti relativi alla scrittura del codice, alle attività di debug e di testing.
Una volta raccolte tutte queste informazioni, si è passati alla fase di allineamento per verificare l’omogeneità dei parametri di qualità ritenuti importanti dalle diverse figure aziendali. In pratica, si verifica se e come le attività svolte quotidianamente dai team di sviluppo vadano nella direzione identificata dal top management e se la percezione di qualità sia effettivamente la stessa. Questo allineamento deve tenere conto anche delle priorità che vengono date ai diversi parametri di qualità dalle diverse figure aziendali. Una perfetta coincidenza permette all’azienda di perseguire efficacemente gli obiettivi e di introdurre velocemente azioni correttive in caso di problemi. Un disallineamento, invece, richiede una attenta analisi delle cause che, di solito, sono relative ad una difficoltà di comunicazione interna che si riflette poi sul software, non rispettando le direttive del top management.
Nel caso considerato, l’allineamento tra le figure aziendali era presente ma, a causa di diverse limitazioni tecniche dovute alla necessità di raggiungere alte prestazioni di calcolo, si è scelto di andare in un’altra direzione. Questo è accaduto perché le ottimizzazioni necessarie per raggiungere le prestazioni volute hanno richiesto di strutturare il codice in modo molto complesso, riducendone la leggibilità e la manutenibilità. La consapevolezza dei compromessi che devono essere raggiunti per bilanciare i requisiti ed i diversi parametri di qualità con le necessità tecniche è un aspetto fondamentale della valutazione di un sistema software e delle relative capacità dell’azienda di gestirne l’evoluzione.
Terminata questa prima parte di analisi si è passati al codice. L’analisi ha riguardato tutta l’evoluzione dei prodotti andando indietro nel tempo fino a quanto i dati lo hanno consentito. Infatti, l’evoluzione temporale del codice è in grado di fornire un quadro più preciso delle condizioni del software e della capacità dell’azienda di gestire la complessità che, ovviamente, aumenta nel tempo con l’aggiunta di nuove funzionalità. Questa analisi si è focalizzata su tre aspetti:
- complessità
- comprensibilità
- manutenibilità
Sono stati usati diversi strumenti di misura che hanno raccolto un gran numero di dati e che sono stati utilizzati per valutare i tre aspetti identificati. In questo caso, si è potuto constatare che alcuni prodotti avevano subito diverse riorganizzazioni interne nel corso degli anni limitandone la degradazione della qualità, nonostante l’aumento delle funzionalità e della dimensione del codice. Grazie a queste attività di ristrutturazione, l’azienda ha potuto concentrare gli sforzi sull’evoluzione del prodotto continuando ad aggiungere nuove funzionalità senza interruzioni nello sviluppo.
L’analisi dell’evoluzione ha permesso di identificare i moduli più problematici e di focalizzare le attività di miglioramento su una ristretta porzione del codice, massimizzando i benefici e minimizzando i relativi costi. Inoltre, è stato possibile paragonare l’evoluzione di diversi prodotti per comprendere se diversi team gestivano i prodotti in modo alternativo. In particolare, questa analisi è servita per paragonare sistemi sviluppati da aziende acquisite con quelli sviluppati nell’impresa capogruppo.
Infine, sono stati messi insieme tutti i dati raccolti per verificare quanto gli obiettivi di qualità definiti ad alto livello dal management abbiano influenza sul software stesso e sul come sia stato sviluppato. Questo tipo di analisi ha permesso di definire un quadro dettagliato dello stato dello sviluppo software dei prodotti in esame ed identificare le aree di miglioramento a diversi livelli: codice, architettura, project management ed interazione tra diversi team.
Sulla base dei risultati ottenuti, si è proceduto a definire un piano operativo per introdurre dei miglioramenti nelle aree specifiche identificate. Successivamente, con cadenza periodica (6-12 mesi) si sono ripetute parte delle analisi per verificare i miglioramenti introdotti.
Questo esempio ha descritto uno dei casi più complessi di analisi della qualità del software che ha permesso di avere un quadro molto preciso dello stato del software e delle capacità dell’azienda. Tuttavia, non sempre è richiesto un livello di dettaglio di questo tipo e le analisi devono essere adeguate agli obiettivi che si vogliono perseguire.
BIO
Alberto Sillitti è co-fondatore e CEO del Centre for Applied Software Engineering s.r.l., una PMI innovativa, con sedi a Bolzano e Genova, che si occupa di digital transformation e di analisi della qualità del software sviluppando sistemi di valutazione, offrendo servizi di consulenza, audit e formazione in questi ambiti. Fino al 2022, ha ricoperto il ruolo di professore ordinario presso la Facoltà di Informatica ed Ingegneria della Innopolis University (Federazione Russa) dove ha diretto le attività di ricerca nel campo della qualità del software industriale in collaborazione con diverse realtà industriali internazionali, PMI e start-up.