Pubblicato su Ingenium n. 117-118, gennaio-giugno 2019
Periodico di informazione dell’Ordine degli Ingegneri della provincia di Terni
(Rivista scientifica Cineca-MIUR n. E203872)
La stima di tempi, costi e risorse in genere è un’attività cardine nell’ambito dello sviluppo software, nonché una delle più incomprese e, talvolta, sottovalutate.
Che le stime relative allo sviluppo software siano particolarmente difficili da gestire è un problema noto da tempo: Frederick P. Brooks Jr. ne parla già nel 1975 nel suo celebre (per gli addetti ai lavori) libro sulla gestione di progetti software “The Mythical Man-Month: Essays on Software Engineering”. Brooks aveva gestito lo sviluppo del sistema operativo IBM System/360 e scrisse la sua opera ispirato dalla domanda che il presidente della IBM, all’epoca Thomas Watson Jr., gli aveva posto durante il colloquio di fine rapporto: per quale motivo gestire tempi e risorse in progetti software è assi più difficile che in progetti hardware? Nel suo libro Brooks esplora, con una serie di aneddoti, alcune criticità relative alla questione; la sua constatazione più famosa, al punto di diventare nota come “Legge di Brooks”, è che aggiungere manodopera ad un progetto software che è in ritardo non fa altro che ritardarlo ulteriormente.
Attualmente il problema delle stime relative ai progetti software è affrontato in molteplici modi. Nelle piccole realtà, o comunque in ambienti scarsamente formalizzati, in genere si usa la “stima esperta”: uno o più esperti forniscono delle stime basandosi sulla propria esperienza ed intuizione. Tuttavia questo modus operandi non è affatto ottimale: in genere gli esperti tendono ad essere troppo ottimisti e forniscono intervalli di stima troppo ridotti o, addirittura, dei numeri precisi, anche in contesti caratterizzati da un’evidente incertezza. Quasi sempre, peraltro, le “stime esperte” sono soggette a forti pressioni da parte degli stakeholder, risultando così doppiamente falsate.
Esistono diversi modi per derivare una stima complessiva a partire dalle stime fornite dagli esperti. Un approccio molto conosciuto è la stima a tre valori PERT (Program Evaluation and Review Technique), parte di una serie di strumenti di project management elaborati dalla marina statunitense negli anni ‘50. A differenza della semplice stima esperta, nella PERT vengono chieste tre stime: una stima pessimistica, una stima ottimistica ed una “più probabile”. Successivamente, assumendo una distribuzione di probabilità Beta, con deviazione standard pari ad un sesto dell’intervallo tra la stima ottimistica e quella pessimistica, la stima fornisce la durata attesa. Operativamente, date le “stime esperte” O, P e M (ottimistica, pessimistica e “most likely”, ovvero “la più probabile”), la loro combinazione con la tecnica PERT si riduce a questo semplice calcolo, che non è altro che l’approssimazione della media della distribuzione di probabilità definita sopra:
STIMA = (O + P + 4×M) / 6
L’uso della PERT è estremamente semplice e consente di attenuare i fattori di disturbo esterni ed interni che affliggono le stime esperte. Inoltre, essendo uno strumento molto diffuso, è anche integrato nei principali software di project management. Infine, nella PERT è implicita l’idea che una stima sia un intervallo, non un numero preciso. Tuttavia, anche le stime alla base della PERT sono comunque affette degli stessi bias delle stime esperte (ottimismo e pressioni esterne): il risultato è che gli intervalli temporali individuati dalla stima ottimistica e da quella pessimistica possono comunque essere troppo ridotti rispetto all’incertezza del contesto. Non solo: una stima “most likely” troppo ottimistica può falsare la stima complessiva in modo significativo, poiché rispetto alle altre due ha un peso quattro volte maggiore.
Tipica funzione di densità della distribuzione Beta usata nella tecnica PERT
In letteratura sono descritti numerosi metodi alternativi alla PERT per combinare le “stime esperte” (ad esempio, associandole a percentuali di fiducia nelle stesse; a tal proposito sono particolarmente interessanti i lavori di M. Jørgensen e quelli di C. Pescio), tuttavia l’impatto dei bias rimane comunque significativo. Per ovviare a questo problema è stato concepito un altro filone di metodi per la stima dei progetti software: i metodi formali. Il capostipite dei metodo formali è COCOMO (Constructive Cost Model), sviluppato da Barry W. Boehm negli anni ‘80: si tratta di una serie di modelli basati sul fitting di formule di regressione su dati derivanti da progetti passati. Nel corso degli anni sono stati elaborati ulteriori metodi formali, come ad esempio COSYMO (Constructive Systems Engineering Cost Model, del 2002) e WMPF (Weighted Micro Function Points, del 2009). Tutti questi metodi hanno in comune il fatto di basarsi su dati storici, il che li rende inefficaci in un mondo in continua evoluzione come quello software, sia per quanto riguarda le tecnologie disponibili che le aspettative dei clienti.
In altre parole, i metodi basati sulla stima esperta sono vulnerabili a causa della natura umana, mentre quelli formali sono poco flessibili in situazioni mutevoli o nuove: nonostante i progressi nel mondo dello sviluppo software, non abbiamo ancora a disposizione un metodo efficace per stimarne tempi e costi. A riprova di ciò, nel 2011, l’Havard Business Review ha pubblicato i risultati di uno studio su 1471 progetti software: mediamente i costi superavano del 27% quelli preventivati, ma nel 16% dei casi lo sforamento era del 200% in termini di costi e del 70% in termini di tempo. Non è cambiato nulla, dunque, dai tempi di Brooks e del suo “mitico mese-uomo”? Sicuramente i mezzi a disposizione del project manager in ambito software sono più numerosi: l’importante è usarli con onestà intellettuale ed essere consci delle loro caratteristiche. In questo senso, la terzietà degli ingegneri può essere una risorsa inestimabile per applicare efficacemente metodi di stima in qualsiasi progetto software.