MILANO – L’analisi della produttività delle attività di sviluppo e mantenimento delle applicazioni software risponde a obiettivi di contenimento dei costi da parte dei dipartimenti It e consente di ‘oggettivizzare’ le varie decisioni di sourcing sia sul fronte dello sviluppo applicativo sia sul piano del testing. A dirlo è Bill Curtis, direttore del Cisq-Consortium for It Software Quality e senior Vp & Chief Scientist dei Research Labs di Cast, esperto mondiale nell’ambito del software engineering e coautore del Capability Maturity Model (Cmm), intervistato di recente in esclusiva da ZeroUno.
Il software influenza ormai pesantemente la produttività e, quindi, la crescita del business di un’azienda. Eppure, quando si parla di qualità del software e, soprattutto, di economics della qualità, ancora molti sono gli ostacoli da superare. “La cultura legata alla qualità del software è ‘minata’ dalle continue esigenze di time-to-market delle aziende che portano i team di sviluppo a rilasciare le soluzioni in tempi sempre più rapidi a discapito di processi di testing e controllo – osserva Curtis -. Ma questi approcci ‘quick and dirty’ hanno dimostrato la loro inefficacia perché generano quello che in gergo chiamiamo ‘technical debt’, un debito derivante da problemi tecnici, codice errato, criticità funzionali che, rispetto alle esigenze di business odierne, non sono più accettabili dato il loro diretto impatto sulla reddittività”.
Il valore della qualità del software si spiega allora con termini ‘cari’ al business come produttività e rischio che, di fatto, diventano anche nuovi approcci all’Adm, Application Development Management.
Bill Curtis, direttore del Cisq-Consortium for It Software Quality e senior Vp & Chief Scientist dei Research Labs di Cast
“Le pratiche di controllo e verifica della produttività dello sviluppo software intervengono nel miglioramento dei processi, nell’identificazione delle migliori scelte di sourcing (di attività ma anche di tool, strumenti, servizi, competenze) e di gestione/governance delle attività – spiega Curtis – ma questo richiede capacità di analisi e misurazione completamente diverse dal passato”.
La misurazione standard per la stima dell’effort dedicato allo sviluppo software e della sua produttività è il ‘function point’ (unità di misura che serve a valutare i requisiti funzionali di una soluzione software). “Obiettivi dell’analisi dei function point sono: misurare le funzionalità che l’utente riceve e richiede; misurare i risultati dello sviluppo e/o la manutenzione del software indipendentemente dalla tecnologia utilizzata; fornire una misura che sia coerente tra progetti e produttori differenti”, puntualizza Curtis. “I function point possono essere messi in correlazione con molte variabili come il costo del progetto di sviluppo o quello della manutenzione evolutiva di un software, le ore di lavoro impiegate o previste, lo staff e le competenze necessarie, la durata del progetto e dei singoli processi. Tuttavia, la dimensione funzionale rappresenta solo un aspetto del prodotto software: i requisiti tecnici e, in generale, i requisiti non funzionali non vanno mai dimenticati”.
Di function point se ne parla ormai da decenni (l’unità di misura è stata definita per la prima volta nel 1975) ma ciò che oggi cambia è la prospettiva, ossia il suo impatto sulla redditività del business. “Redditività che deve andare ‘a braccetto’ con il concetto di analisi del rischio affinché si possano identificare le pratiche di sviluppo e testing più idonee – commenta Curtis -. Di fatto, lo sviluppo e il testing applicativo sono processi costosi che richiedono le giuste competenze. È fondamentale identificare quindi la via migliore in base alle necessità aziendali e al proprio bilanciamento dei rischi”.
“Fortunatamente in questo complesso scenario vengono in aiuto gli standard metodologici come quelli sviluppati dall’Object Management Group (Omg) che ha identificato un sistema di misurazione standard per stimare la produttività dei processi di sviluppo e testing tenendo conto delle raccomandazioni e delle pratiche suggerite dal Cisq e delle direttive dell’International Function Point User Group (Ifpug)”, sottolinea ancora Curtis. “Uno standard che Cast ha fatto ‘proprio’ portandolo all’interno di uno strumento che consente di automatizzare la misurazione della produttività nello sviluppo software consentendo di avere dei risultati immediati (attraverso interfacce anche semplici da comprendere e utilizzare) in qualsiasi fase del processo”.
