La qualità dei progetti migliora con il “software per un software migliore”

Marzo 2008 – Visto che i programmi creati dagli umani sono soggetti a disfunzioni, errori e buchi di sicurezza, il paradosso per creare software più affidabile è usare ancora più software in vari stadi del processo di sviluppo: in primo luogo, per un teamwork più efficiente, in secondo luogo per scrutinare il software prodotto o il suo sorgente (in modo statico o dinamico), infine per quantificare qualità del codice, produttività degli sviluppatori, e rapporto efficienza costi, onde dare una priorità agli sforzi di risoluzione. Secondo Standish Group, il 35% dei progetti software cominciati nel 2006 si è completato “on time, on budget e on function”, contro il 16% del 1994; e all’estremo opposto la percentuale completamente fallita è scesa dal 31% al 19%. I progressi sono costituzionalmente più lenti che nelle performance e nella qualità dell’hardware, ma sono innegabili. Non tutti sono d’accordo, capofila dei pessimisti è il mitico Capers Jones: “Gli strumenti sono migliorati, ma il numero di bachi nel nuovo codice prodotto  resta attorno ai 5 errori per function point (l’equivalente in metrica software di una funzionalità media) e solo l’85% viene eliminato prima di andare in produzione”. Ma il fatto è che la prima tipologia di software, il software per rendere il teamwork di sviluppo più efficiente sta diventando una vera scienza sociale,  Grady Booch, altro guru, ha dimostrato e misurato che solo il 30% del tempo degli sviluppatori è speso a codificare, il 70% a parlare fra loro: ecco allora piattaforme di sviluppo collaborativo. La seconda tipologia è quella degli strumenti di low level per ricercare bachi, buchi di sicurezza, potenziali problemi. Proliferano strumenti dinamici, che esaminano il software in esecuzione per individuare dove s’inceppa, che sono complementari alla più storica analisi statica. E nasce l’offerta di servizi di analisi online sia statica che dinamica del codice. La terza tipologia fa discendere la priorità di intervento dal valore della rimozione dell’errore. L’idea è un approccio di analisi del rischio, con strumenti che individuano il problema e stimano il rischio associato a ciascuno di essi. Il problema della qualità funzionale software, o della rimozione dei bachi, è un problema nel suo complesso da mezzo trilione di dollari, tanto vengono pagati gli sviluppatori del pianeta. Va affrontato pensando a dove applicare il pesticida con un rapporto efficienza/costo ottimale.