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.
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.
“Più di metà degli apparecchi medici venduti in America (il maggior mercato di strumenti medici) è basata su software, spesso su molto software. Il software di un pace-maker può contenere oltre 80.000 righe di codice, un infusore di farmaci 170.000, e un apparato per la risonanza magnetica oltre 7 milioni di righe di codice.”
L’affidabilità di questo software è ovviamente critica. Uno studio condotto su apparati venduti negli USA dal 1999 al 2005 ha scoperto che un terzo di tali apparati sono stati tolti dal servizio per problemi legati al software.
Una strada per rendere il software medico più affidabile potrebbe essere l’open source, per permettere una migliore visibilità e la possibilità di esaminare il codice. Purtroppo, i regolamenti di approvazione del software stabiliti dagli enti di validazione (come la FDA, la Food and Drug Administration degli USA) sono fatti in modo da scoraggiare il ricorso alle pratiche collaborative tipiche dell’open source.
“When code can kill or cure”, The Economist, Technology Quarterly, June 2nd 2012.
http://www.despair.com/viewall.html
Tra i miei favoriti:
“Quality. The race for quality has no finish line.”
Un survey sui modi in cui vengono effettuate le revisioni architetturali nelle aziende:
Muhammad Ali Babar, Ian Gorton: “Software Architecture Review: The State of Practice“, in IEEE Computer, 07/2009.
Alcuni risultati. Per lo più, le revisioni architetturali:
La complessità dell’organizzazione coinvolta nello sviluppo software potrebbe essere il fattore più importante per prevedere la qualità del software stesso.
Uno studio empirico condotto da due ricercatori Microsoft e da Victor Basili (Università del Maryland) definisce otto misure relative alla struttura organizzativa, e le applica su dati provenienti dal progetto di Windows Vista.
Secondo lo studio, le misure sulla struttura organizzativa costituiscono un indicatore affidabile per prevedere la qualità del software. Più affidabile di altri indicatori che vengono usati comunemente, come il numero di difetti pre-release, il numero di dipendenze, la complessità ciclomatica, il numero di modifiche in corso d’opera.
Il Software Engineering Institute (SEI) è un’istituzione finanziata dal governo e da grandi aziende USA. Nei corsi che tengo sono solito raccomandare il sito del SEI come una delle fonti più autorevoli di documentazione sulle tematiche dello sviluppo software. Documenti di alta qualità, e gratuiti.
Tra le altre cose, il SEI è noto per aver creato il CMMI-SW (Capability Maturity Model Integration), un modello per la valutazione del grado di maturità delle organizzazioni che sviluppano software. Modello applicato dal governo americano e da molte organizzazioni internazionali per selezionare i propri fornitori nello sviluppo software.
Il CMMI-SW è spesso ritenuto, a torto, come un modello che porta a burocratizzare lo sviluppo, pesante e con effetti negativi sulla produttività e sulla flessibilità. Può essere applicato così, è vero. Ma pesantezza e burocrazia non sono affatto insite nel modello, bensì sono causate da chi lo interpreta in modo superficiale.
Una recente pubblicazione del SEI, “CMMI or Agile: Why Not Embrace Both!” evidenzia la compatibilità del CMMI con gli approcci agili.
by Les Hatton, in IEEE Computer, August 2007.
“Nobody knows how to produce a fault-free program. Nobody even knows how to prove it even supposing one we were magically provided. I teach my students that in their whole careers, they are unlikely ever to produce a fault-free program and if they did, they would never know it, they could never prove it and they could not systematically repeat it. It provides a usefully humble starting point.
[…] I’ve analysed enough failed systems in my time to know that there are two classic symptoms of a system on its way to the fairies. First, no independent audit is allowed and second, talking heads tell you everything is fine when the ultimate users tell you the opposite.
[…] The Linux kernel is now arguably the most reliable complex software application
humanity race has yet produced, with a mean time between failures reported in tens and in some cases, hundreds of years. Poetically, the development environment of Linux, which leverages the contributions of thousands of Web volunteers who give their spare time for the public good, breaks just about every rule which software process experts hold dear.”