analisi-disegno.com
Le stime sono valutazioni, non obiettivi da raggiungere:
"Determinazione di un valore ignoto mediante una valutazione soggettiva e approssimativa: stima a occhio della distanza, fare una stima del tempo necessario." (Dizionario italiano De Mauro, Paravia, 2006)
Le stime, per definizione, possono essere imprecise, e devono poter essere modificate man mano che si acquisiscono nuovi elementi di conoscenza sul lavoro da fare.
Nel mondo dello sviluppo software, in particolare, è diffusa la consapevolezza dei limiti delle attività di stima. Le stime iniziali di un progetto di sviluppo sono poco attendibili, perché ogni progetto richiede un'acquisizione di conoscenza non disponibile in precedenza. Il livello di precisione (affidabilità) delle stime aumenta man mano che il progetto avanza.
“Gli sviluppatori esperti sanno che tutti i loro sforzi per stimare l’impegno necessario risultano comunque inadeguati, rispetto a ciò che il progetto richiederà effettivamente.” (Philip Armour - The Laws of Software Process).
Vi sono comunque; alcuni approcci utili per ridurre il rischio associato alle stime:
Tecniche ed unità di misura dimensionali.
Misurazioni di produttività e qualità.
Strumenti di supporto alle stime.
Servono a stimare la quantità, la dimensione delle "cose da fare".
Le unità di misura dimensionale utilizzate storicamente nel software, come linee di codice e numero programmi, si sono rivelate poco adeguate per la stima dell'impegno necessario nei progetti, stima che per motivi contrattuali deve essere effettuata già all'inizio dei lavori.
Si è quindi cercato di sostituirle con unità di misura più adatte a stime precoci. La più diffusa è il punto funzione (function point), ideata da Allan Albrecht (IBM) nel 1979. I function point:
L'IFPUG è l'istituzione che definisce gli standard di utilizzo dei FP e gestisce la certificazione degli stimatori. Il GUFPI è la sezione italiana dell'IFPUG.
Oltre ai function point - la più standardizzata e utilizzata - esistono numerose altre unità di misura dimensionale, e tecniche di misurazione ad esse collegate. Tra le più recenti, gli Use Case Point e gli Story Point.
La misurazione dimensionale è solo un passo propedeutico alla stima necessaria per i progetti. Quello che è necessario stimare è l'impegno (effort) in giorni/persona - quanti giorni/mesi/anni sono necessari per fare il lavoro - ed il costo.
Le organizzazioni che sviluppano software possono tenere traccia della produttività dei propri progetti, e del livello di qualità dei prodotti che rilasciano. Conoscendo la propria produttività, possono stimare i nuovi progetti in modo più affidabile. Le organizzazioni hanno tutti i dati per farlo. Ma non sempre lo fanno:
"È raro che siano disponibili dati storici aziendali per calibrare le stime. Le aziende che non memorizzano informazioni sull’utilizzo del personale, sui tempi, sui costi e sui livelli di qualità dei progetti sono sempre a rischio quando devono effettuare delle stime. Gli investimenti effettuati per la realizzazione di buon sistema metrico vengono abbondantemente ripagati nel corso del tempo." (Capers Jones, Software Cost Estimation in 2002, CrossTalk, June 2002)
Quando non sono disponibili dati dell'organizzazione, è possibile fare riferimento a statistiche internazionali su produttività e qualità. Le fonti più utilizzate sono ISBSG, e Software Productivity Research.
Nascono dalla consapevolezza della imperfezione connaturata alle attività di stima. Mettere a confronto le stime di diverse persone può contribuire a ridurre i rischi.
Il metodo Delphi consiste in un processo di stima collettiva che avviene in modo strutturato e progressivo.
Viene formato un gruppo di stimatori. Ogni stimatore riceve le medesime informazioni di partenza sul progetto e stima l'effort, indipendentemente e in modo anonimo.
Un coordinatore raccoglie le stime, elabora dati di sintesi (medie, minimi, massimi, …) e le presenta per confronto agli stimatori. Viene effettuata un'analisi congiunta, che porta tendenzialmente allo scarto dei valori estremi, e favorisce l'approfondimento dei fattori critici. Il giro di stima successivo conducegeneralmente ad una convergenza delle stime.
Per approfondire è utile un articolo di Karl Wiegers su Wideband Delphi.
Il più significativo è CoCoMo (Constructive Cost Model), ideato da Barry Boehm.
"Confronto (1998) di 50 stime manuali con 50 stime supportate da strumenti, per progetti attorno ai 5.000 punti funzione. In entrambi i casi, stime effettuate da project manager, e confrontate con i risultati effettivi.
Solo 4 tra le stime manuali si discostavano meno del 10% dai risultati effettivi. 17 sono risultate ottimistiche tra il 10 e il 30%, mentre 29 sono risultate ottimistiche per più del 30%.
Tra le stime supportate da strumenti, 22 si discostavano meno del 10% dai risultati effettivi. 24 erano pessimistiche tra il 10 e il 25%, mentre 3 oltre il 25%. Solo 1 è risultata ottimistica, del 15%. " (Capers Jones, Social and Technical Reasons for Software Project Failures, CrossTalk, June 2006)
Gli strumenti di supporto alle stime possono essere molto sofisticati e costosi, ma anche gratuiti. Sono comunque utili, perché lo strumento indica una serie di aspetti di cui tenere conto nelle attività di stima, e perché spesso contengono valori di riferimento derivati da statistiche internazionali.
Pagina principale sui processi di sviluppo software
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.