Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software Estimation White Paper

Fabio Pelosin
July 09, 2015
56

Software Estimation White Paper

Fabio Pelosin

July 09, 2015
Tweet

Transcript

  1. The first 90 percent of the code accounts for the

    first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. Tom Cargill, Bell Labs
  2. • Le due cause più comuni dello slittamento nella consegna

    dei progetti software sono la redazione superficiale dei requirements ed una stima troppo ottimistica della complessità generale. 
 • Maggiore è il livello di innovazione di un progetto software, più elevato sarà il livello di incertezza ad esso relativo. 
 • Ad un aumento del 10% della complessità del problema, vi è un incremento del 100% della complessità della soluzione software (crescita esponenziale della complessità). 
 • Dato che non esistono software privi di difetti, l’obiettivo è minimizzare e ridurre l’impatto dei malfunzionamenti non di eliminarli. 
 • Un problema software raramente ha una unica soluzione chiaramente superiore a tutti le altre, ma spesso si possono individuare più soluzioni alternative di merito equiparabile. 
 • Migliorare la qualità di una caratteristica specifica spesso ne compromette un’altra. Ad esempio, tentativi di migliorare l’efficienza influiscono negativamente sulla flessibilità del codice sorgente. 
 • Un clima di pressione dovuto all’incertezza relativa ad esigenze di business in continua evoluzione causa il deterioramento della funzionalità e la riduzione della qualità del software. 
 • Vige il principio di Pareto: l’80% del progetto viene terminato nel 20% del tempo a disposizione. Il completamento del progetto richiede un tempo addizionale che aumenta in maniera esponenziale nella fase finale dell’implementazione. Considerazioni sviluppo software SOFTWARE ESTIMATION
  3. • Un aspetto molto importante da prendere in considerazione è

    il tasso di innovazione di un progetto in quanto: È facile stimare ciò che si conosce (attività affrontate in passato); È difficile stimare ciò che non si conosce (attività da investigare identificabili ex-ante); È estremamente difficile stimare quanto non si conosca (complicazioni identificabili solo in corso). • L’industria informatica è nella peculiare posizione di poter implementare il software che effettui in forma automatica i propri processi ripetitivi. Ciò ha dato origine alla nascita di un vibrante comunità open source che crea e mantiene librerie, frameworks e applicativi per codificare questa automazione. Inoltre, il software open source viene continuamente migliorato comportando un continuo aumento delle componenti qualitative alle quali il mercato si abitua. • Implementare software che risponda a bisogni diffusi spesso è semplice in quanto aumenta la possibilità di trovare una soluzione pronta all’uso già disponibile nella comunità open source. Implementare funzionalità che rispondano a bisogni specifici può essere più complesso in quanto è necessario sviluppare una soluzione ad hoc. Ne consegue che si possono sviluppare in tempi rapidi progetti la cui capacità di generare valore risulti essere limitata dalla loro replicabilità. Per generare valore tramite un progetto software è quindi importante individuare soluzioni che risolvano un problema difficile (no free lunch). Il software è quindi un’attività dominata da una fondamentale componente creativa. Tasso di innovazione SOFTWARE ESTIMATION
  4. • Esistono alcuni fattori psicologici che spiegano la tendenza comune

    a generare stime ottimiste. Questi fattori sono presenti anche quando si utilizzano tecniche di stima formali, dato che molti degli input nel processo di stima sono prodotti da giudizio umano. Tali bias sono radicati nella mente umana e risulta difficile (se non impossibile) identificarli ed eliminarli completamente a priori dato che risiedono nella sfera inconscia della mente umana. Alcuni dei fattori più importanti sono: • Wishful thinking. È la convinzione secondo la quale le persone prendono decisioni in base a quello che desiderano o vogliono immaginare rispetto ad appellarsi all’evidenza dei fatti, alla razionalità oppure alla realtà. • Anchoring. È un bias cognitivo che descrive la tendenza ad utilizzare la prima informazione acquisita nel contesto di una decisione come punto di riferimento per tutte le altre informazioni. Ne consegue che la prima informazione condiziona ingiustificatamente la decisione. • Planning fallacy. È una fenomeno secondo il quale le previsioni riguardo al tempo necessario per completare uno compito futuro causa un bias ottimistico (sottostima del tempo necessario). Questo si verifica recidivante. • Neglect of probability. È la tendenza ad ignorare completamente eventi con probabilità remote ma pur sempre presenti. • Discontinuity In sede di pianificazione e programmazione di progetti complessi adotta strategie e tattiche di stima efficaci a ridurre il più possibile gli effetti negativi che tali fattori psicologici hanno nel processo di decision making. Limitazioni al processo di stima SOFTWARE ESTIMATION
  5. • Il PERT (detta anche stima a tre valori o

    three-point-estimation) è un metodo statistico di determinazione dei tempi delle attività di un progetto. Rispetto alla semplice stima a valore singolo, il metodo presuppone la determinazione di valori di stima ottimale, probabile e pessimistico che risultano più adeguati a valutare tempi e costi di attività di progetti che presentano incertezza o complessità come nel caso dello sviluppo di software innovativi. Nel metodo PERT la durata del progetto è una variabile aleatoria rappresentata con una funzione di densità di probabilità di tipo Beta. La distribuzione Beta viene calcolata matematicamente per ottenere la stima della durata totale attesa del progetto. Metodo SOFTWARE ESTIMATION