Inutile nasconderlo: il software perfetto non esiste. Qualunque sistema, dal più semplice al più complesso, ha immancabilmente un aspetto non ottimizzato. Una situazione dovuta a molteplici cause: dalla mancanza di tempo alla ridotta disponibilità di risorse economiche e tecniche, passando attraverso aspettative troppo elevate ed effettivi limiti dei sistemi operativi.
Qualunque carenza, però, ha immancabilmente un costo, in termini di efficienza, efficacia e successiva manutenzione necessaria…
Come un qualunque debito, inoltre, il suo costo (anche economico) aumenta nel tempo, a causa dei rallentamenti e delle inefficienze introdotte sin dalla fase di installazione. É questo il cosiddetto “debito tecnico”, una sorta di metafora per far capire, sia agli sviluppatori che ai non addetti ai lavori, che un intervento non ottimale sul software ha sempre un costo economico. Inoltre, come ogni debito, deve essere ripagato con gli interessi.
Oltre agli errori e alle carenze, inoltre, il mancato raggiungimento dell’obiettivo è dovuto anche ad autentici errori nella definizione dell’obiettivo stesso, con il tentativo di inserire funzionalità non necessarie, ma che distolgono l’attenzione dall’autentico scopo di una soluzione, aggravando ulteriormente la situazione.
La misura del debito
In questo ambito, come spiega Pascal Jansen, Managing Director & Partner di inspearit, il primo parametro da valutare è rappresentato dalla qualità del software. Un concetto difficile da definire, che può essere calcolato sulla scorta di una metrica SQALE – Software Quality Assessment based on lifecycle Expectations. Si tratta, in pratica, di un metodo di valutazione di un’applicazione software sviluppato per valutare oggettivamente il codice sorgente di un’applicazione.
Una simile valutazione si basa, tipicamente, sull’analisi di tre specifici aspetti:
- Qual è la qualità del codice sorgente che gli sviluppatori hanno consegnato?
- Il codice sorgente può essere facilmente sottoposto a evoluzione e manutenzione, convertito per altri sistemi hardware/software, riutilizzato in altri contesti?
- Cosa è migliorato, o peggiorato, tra due versioni dello stesso codice?
Come si percepisce da questi quesiti, SQALE gode il vantaggio di essere un metodo generico, indipendente dai linguaggi di programmazione e dagli strumenti di analisi del codice. Essendo pubblicato con licenza “Open Source”, inoltre, può essere utilizzato e implementato negli strumenti di analisi automatica del codice. Inoltre il metodo, sviluppato da inspearit, viene correntemente utilizzato da diverse aziende ed è implementato da vari strumenti di analisi statica del codice.
La perfezione non esiste
Dato per assunto il fatto che non esiste il “perfect code”, inspearit è riuscita definire il “right code”. “Proprio identificando la cosiddetta area di ‘codice corretto’ – sottolinea il Business Director Roberto Davico – si possono riconoscere le caratteristiche che rendono una soluzione comunque accettabile e adeguata alle effettive esigenze del committente”. Al contrario, quando gli attributi non vengono rispettati e lo stato dello sviluppo ricade nell’area cosiddetta “not right” la conseguenza è una riduzione della produttività, che corrisponde a un “interesse” da pagare.
Proprio muovendosi all’interno di un simile schema, il metodo SQUALE fornisce un indicatore sintetico e facilmente integrabile con il dashboard del management. In questo modo i decisori aziendali possono valutare il costo necessario per colmare la presenza di un debito tecnico, portandosi nell’area di accettabilità, senza necessariamente raggiungere le condizioni ideali. Scrivere il “perfect code”, infatti, richiederebbe un costo di sviluppo eccessivamente elevato.
All’atto pratico, come spiega Jansen, SQALE “permette di valutare i costi necessari per rimuovere il debito e i potenziali danni in caso di mancata rimozione”.
Questo significa che, attraverso due modelli di stima, è possibile trasformare le violazioni in costi. Un primo modello, basato sulla natura tecnica della violazione, definisce infatti il debito tecnico, mentre un secondo modello, in grado di valutare la severità della violazione stessa, rende conto dell’impatto sul business.
Un simile metodo assume un’importanza fondamentale soprattutto nei progetti più complessi. In un emblematico esempio citato da Davico, l’analisi effettuata da SQALE ha identificato che, a fronte di oltre 58mila linee di codice di un programma in fase di sviluppo, solo l’11% costituiva un effettivo debito tecnico legato a violazioni bloccanti. Questo significa che, spendendo circa 157 giorni/uomo correttamente indirizzati, sarebbe stato possibile eliminare tutte le situazioni critiche, riducendo in maniera significativa l’esposizione al rischio. Ciò ha messo a disposizione degli utilizzatori una soluzione già adeguata alle loro esigenze, anche se ottimizzabile sotto alcuni aspetti comunque secondari. In questo modo, inoltre, qualunque intervento risulta perfettamente mirato e specifico, o correggendo tempestivamente i principali problemi e consentendo il rispetto dei tempi di sviluppo.
Il tutto anche in considerazione del fatto che una soluzione software è soddisfacente quando ha conseguito l’80% degli obiettivi. Un valore che viene raggiunto in tempi molto più rapidi se si opera attraverso il cosiddetto sviluppo incrementare (feature driven), che permette di misurare l’avanzamento in prodotto software funzionante. In tal modo è possibile interrompere l’attività prima della fine del progetto, quando l’80% del valore è stato creato, massimizzando così il lavoro “non fatto”.
Una programmazione Agile
Ottimizzare i processi di sviluppo significa sfruttare i benefici dell’agilità nell’ambito dell’Ict. Agile, infatti, è un paradigma che sposta l’attenzione dai processi di realizzazione del software alla produzione di valore per il cliente. Questo cambio di prospettiva è supportato nei team agili da tecniche di software engineering scelte in base al contesto organizzativo e agli obiettivi di business. L’adozione delle tecniche agili implica la creazione di un ambiente collaborativo e l’esercizio di un processo di project management in grado di adattare lo scope del progetto in sintonia con le esigenze del cliente. Un ambito nel quale inspearit ha sviluppato, negli anni, la competenza necessaria per curare la costruzione e la diffusione, all’interno delle organizzazioni, del mindset Agile attraverso piani di transizione che bilanciano agilità e disciplina, in accordo alla complessità dell’organizzazione e al contesto nel quale essa opera. L’adozione dei metodi agili, inoltre, avviene in modo incrementale, coerentemente con i diversi livelli di maturità dei processi organizzativi, garantendo significativi ritorni dell’investimento a breve termine.
