Archivi categoria: qualità

La crisi del software è discutibile

Una ricerca spesso citata sullo sviluppo software è il Chaos Report, pubblicato periodicamente a partire dal 1994 dallo Standish Group. Il Chaos Report classifica i progetti in tre categorie: successo (risultati coerenti con i requisiti iniziali, forniti nei tempi e con le risorse previsti); discutibili (risultati inferiori alle attese e/o tempi e/o costi maggiori); fallimenti.

I dati del Chaos Report si possono interpretare in diversi modi: una critica ragionevole in questo articolo di Scott Ambler sul Dr. Dobb’s Journal: The Non-Existent Software Crisis:  Debunking the Chaos Report.

Talento e specializzazione

Per diventare “campioni” in una disciplina servono almeno 10.000 ore di esercizio, ma la pratica da sola non è sufficiente, il talento è decisivo.

In un ambito multidisciplinare come lo sviluppo software, comunque, è essenziale che gli specialisti collaborino tra loro per il successo dei progetti, anche svolgendo attività al di fuori della loro specializzazione, come argomenta Jim Coplien in “Can You Scrum Art?“.

Tracciabilità strategica dei requisiti

“La tracciabilità deve essere pianificata a livello strategico. Tipicamente, tracciare ogni singolo requisito non è né sensato dal punto di vista dei costi né particolarmente utile. Anzi, questo livello di tracciabilità porta probabilmente a creare un’infrastruttura documentale non mantenibile […]. La tracciabilità, per essere efficace, deve vivere e respirare in linea con il sistema che supporta.”

In Thinking about Quoins: Strategic Traceability of Architecturally Significant Requirements (su IEEE Software, settembre-ottobre 2013) Jane Cleland-Huang propone di tracciare solo i requisiti che influenzano le scelte architetturali, ma di farlo attivamente e in modo sistematico, misurando nel tempo le evoluzioni del sistema rispetto ai suoi requisiti.

In un articolo precedente Strategic Traceability for Safety-Critical Projects (su IEEE Software, maggio-giugno 2013, a pagamento), Cleland-Huang e altri analizzano la validità delle informazioni di tracciabilità inviate dai produttori di sistemi critici alle autorità competenti per il loro controllo, e propongono tecniche per migliorarne l’efficacia.

Organizzazioni antifragili

Gli errori sono inevitabili. Nell’hardware, nel software, nell’uso che ne facciamo. Quando poi i sistemi sono attivi nel cloud, la complessità globale aumenta, ed aumentano di conseguenza i possibili errori. Come ridurli, o ridurne gli impatti negativi?

In The Antifragile Organization (su Communications of the ACM, agosto 2013 – articolo a pagamento) Ariel Tseitlin propone di non basarsi solo su verifiche in ambiente di test, ma di provare a creare in modo sistematico malfunzionamenti anche sui sistemi in esercizio, per renderli progressivamente sempre più robusti: “Embracing failure to improve resilience and maximise availability”.

Debito tecnico

Quando il software è fatto bene, gli utenti lo usano senza problemi. Chi dà assistenza non è subissato dai reclami. Per chi lo fa evolvere è facile aggiornarlo, modificando le funzioni esistenti quando è il caso, o introducendone di nuove.

Non tutti, purtroppo, viviamo in questo mondo ideale. Non sempre, almeno. Perché il software può essere anche fatto male, e (se lavoriamo nel settore dello sviluppo software) può darsi che l’abbiamo fatto male noi.

Perché, a volte, il software è fatto male? In alcuni casi, per l’incompetenza di chi lo sviluppa, problema in genere superabile con un’adeguata formazione professionale. In altri casi, però, il motivo non è la mancanza di competenza. Anche sviluppatori molto capaci producono a volte software non ottimale. Per fare più in fretta, per spendere meno tempo, perché non c’è più tempo. Per rilasciare prima, in tempo, la nuova versione del software.

Ogni volta che produciamo un software con dei problemi, che lo modifichiamo in un modo non ottimale, ad esempio facendo “copia e incolla” di porzioni di codice invece di riprogettare adeguatamente il programma, diminuiamo il livello di qualità del prodotto. Rendiamo più difficili, lunghe e costose le modifiche successive, che verranno anch’esse, probabilmente, fatte male. Così il software degrada ad ogni successiva modifica, e può accadere che anche prodotti inizialmente validi peggiorino ad ogni nuovo rilascio.

Questo è il debito tecnico. “Debito tecnico” è una metafora ideata da Ward Cunningham per far capire, sia agli sviluppatori che ai non addetti ai lavori, il costo economico che ha un intervento non ottimale sul software. Ogni volta che contraiamo un debito, ad esempio un mutuo (o il debito pubblico di una nazione), dobbiamo ripagarlo con gli interessi. Nel caso del software, ogni volta che effettuiamo un intervento inadeguato, scegliendo la strada più veloce anziché la migliore, abbassiamo la qualità e rendiamo più difficili e costosi gli interventi futuri.

Questo non significa che fare in fretta non sia necessario. A volte dobbiamo per forza scegliere la strada veloce anziché la migliore, perché non abbiamo alternative. Ma poi bisogna mettere le cose a posto, se si vuole evitare il peggio.

Una piramide per la qualità del software

Deve essere installato e funzionare. Se lo è,
deve avere sufficienti prestazioni, ed essere sicuro. Se lo è,
deve essere usabile. Se lo è,
deve essere utile. Se lo è,
può avere successo.

Rappresentata come una piramide, questa scala di livelli di qualità del software è analoga alla piramide di Maslow sul soddisfacimento dei bisogni degli esseri umani.

Per Maslow, innanzitutto vanno soddisfatti i bisogni primari (cibo, temperatura ecc.). Soddisfatti questi, vanno soddisfatti i bisogni di sicurezza personale. Poi i bisogni legati alle relazioni e all’affettività. Poi i bisogni legati al riconoscimento e alla stima. Infine quelli legati alla realizzazione del proprio potenziale.

Se un livello precedente non viene soddisfatto, vengono compromessi i livelli successivi (ad esempio, se non si ha cibo sufficiente, l’attenzione alla sicurezza personale può diminuire).

L’analogia tra la scala dei bisogni di Maslow e i livelli di qualità del software è descritta in modo brillante da Gojko Adzic.

CAST 2012 – Video

CAST è la Conference of the Association for Software Testing. Conferenza annuale, che nel 2012 si è tenuta a San Jose, USA, dal 16 al 18 luglio.

I video della conferenza CAST2012 sono disponibili su YouTube. Interessante in particolare la keynote di Elisabeth Hendrickson, The Thinking Tester Evolved.

Sempre da CAST2012, da seguire l’intervento Software Metrics: Threats to Validity di Cem Kaner sulla validità delle metriche usate nell’ingegneria del software, ed in particolare nel testing.

Metriche e controllo

Lord Kelvin: “Se non si può misurare, non si può migliorare”.

Tom DeMarco, in Controlling Software Projects (1986): “Non si può tenere sotto controllo ciò che non si riesce a misurare”.

Phillip G. Armour, su Communications of the ACM, June 2012, rovescia il punto di vista: “Se non si migliorano le cose, è difficile misurarle bene; sotto alcuni aspetti, non possiamo misurare ciò che non controlliamo”.

Alcuni esempi illuminanti di misurazioni dubbie citate nell’articolo: durata, produttività, costo, qualità dei progetti software.