Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

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

pittogramma Zerouno

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

14 Apr 2008

di Rinaldo Marcandalli

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.

Rinaldo Marcandalli
Giornalista

Consulente aziendale e giornalista. 40+ anni di esperienza nello sviluppo software, laboratorio IBM e field, nelle telecomunicazioni prima e poi nelle applicazioni e nel governo del Dipartimento It. Esperienze sul campo in settori bancario, in particolare interbancario, assicurativo e pubblica amministrazione. Da 20+ anni segue prima da consulente e poi come giornalista l’evoluzione dei processi nei settori e da 10+ anni la loro trasformazione progressiva al digitale, specializzandosi nello studio della riorganizzazione agile, digitale e smart delle Aziende.

Articolo 1 di 5