EMBEDDED
52 • MAGGIO • 2014
66
SOFTWARE
QUALITY
limitato, ad esempio in caso di diagnosi di malfunzionamenti o
carenze, o di analisi e individuazione delle modifiche da appor-
tare. Il livello di modificabilità dipende dalla relativa facilità
di correzione, quando occorre rimuovere errori o sostituire
componenti. Un buona manutenibilità è legata anche a quanto
il sistema si rivela stabile (rischio ridotto di comportamenti
anomali e inattesi) dopo l’esecuzione delle modifiche, e alla
capacità che ha di essere collaudato facilmente per validare le
modifiche stesse.
Infine, la portabilità esprime la facilità con cui è possibile
trasportare il software da un ambiente operativo a un altro.
Quindi la sua capacità di adattamento al nuovo contesto,
limitando al massimo le modifiche necessarie; la facilità di
installazione in un determinato ambiente operativo; l’abilità
di coesistenza e condivisione di risorse con altri software, e
l’intercambiabilità, ossia la possibilità di essere sostituito a un
altro software per eseguire gli stessi compiti nel medesimo
ambiente.
Degrado del codice, i primi segnali
Un imperativo sempre più categorico, nell’interesse di tutti
gli attori cooperanti all’ecosistema di produzione dei software,
è fare in modo che la complessità degli attuali progetti, le
esigenze di rispettare tutti i requisiti delle applicazioni, e la
pressione del time-to-market, non incidano in modo negativo
sulla qualità del software. E ciò, specie nelle realtà con ampi
team di progettazione, impone l’adozione di metodologie di
co-design hardware-software, tool, e strategie organizzative di
monitoraggio della qualità, finalizzati a individuare ed elimina-
re i difetti del software il più possibile già nelle fasi iniziali del
ciclo di produzione, senza dover attendere di scoprire i bug
negli stadi finali di test e collaudo.
Tuttavia, più il proget-
to cresce, e i singoli
componenti e moduli
software diventano arti-
colati e interdipenden-
ti, più diventa difficile
eseguire operazioni di
manutenzione, modifi-
ca e test. Il consulente
software internazionale
Robert C. Martin para-
gona questo processo
di degradazione a quel-
lo di un pezzo di carne
che sta marcendo.
Anche nel caso del sof-
tware si possono sentire
‘cattivi odori’. Fra questi
‘bad smells’, avvisaglie
che il software sta perdendo qualità, ve ne sono cinque fonda-
mentali, definiti “rigidità”, “fragilità”, “immobilità”, “viscosità”
e “opacità”. Il software diventa rigido quando la modifica
anche di un limitato pezzo di codice obbliga lo sviluppatore
a effettuare ulteriori modifiche su altre parti. Fragile, quando
apportare un cambiamento causa il collasso del sistema in
punti apparentemente non in relazione con il problema a cui si
sta lavorando. Alcuni sviluppatori navigati, ricorda Rebecca M.
Riordan, progettista internazionale di sistemi computerizzati e
autrice del libro Fluent C#, sono soliti dire: “Esistono sempre
tre bug: quello che si conosce, quello che non si conosce e
quello che si sta creando per risolvere quello che si conosce-
va”. C’è poi la immobilità del codice. Tipicamente si riscontra
quando, ad esempio, si sta modificando un’applicazione e si
desidera riutilizzare un pezzo di codice, ma farlo risulta molto
arduo. La viscosità è la tendenza del software a facilitare la
commissione di errori da parte del programmatore, mentre
l’opacità si riferisce alla difficoltà di leggere e comprendere
bene il codice.
Dipendenze, buone e cattive
Un tema chiave strettamente connesso alla produzione e
manutenzione di codice di qualità e quello delle dipendenze
fra i vari pacchetti e moduli, specie in contesti tecnologici
come quelli attuali, in cui gli aggiornamenti del software sono
molto frequenti. La presenza delle dipendenze fa sì che, ad
esempio in Linux, a livello di amministrazione del sistema,
l’installazione di un nuovo pacchetto software possa richiede-
re a sua volta il soddisfacimento di varie dipendenze e quindi
l’installazione a catena di moduli software aggiuntivi. A livello
architetturale, un’elevata interdipendenza dei sottosistemi – in
cui un singolo cambiamento provoca a cascata la necessità
Fig. 2 – Una classificazione dei ‘code smells’
