LA MISURA DEL SOFTWARE
s
Rubrica a cura di Luigi Buglione – GUFPI-ISMA
Metrologia e Contratti Parte 11 – Una Stima non è (e non può essere) una Misurazione METROLOGY AND CONTRACTS – PART 11: ESTIMATION IS NOT (AND CANNOT BE) A MEASUREMENT Eleventh paper based on the new GUFPI-ISMA guidelines on the proper use of “Principles, Assumptions and Contractual Best Practices” (vol.1, 2016), it deals with estimation, too often managed in a trivial way more than it could be useful.
RIASSUNTO Undicesimo articolo basato sulle nuove linee guida GUFPI-ISMA sul corretto uso di “Principi, Assunzioni e Best Practice Contrattuali” (vol.1, 2016), riguarda gli aspetti di estimation, troppo spesso banalizzati e semplificati più di quanto possa essere invece utile. INTRODUZIONE
Undicesimo appuntamento con la disamina dell’applicazione di buoni principi di misurazione ai contratti (ICT e non), relativo agli aspetti di corretto censimento delle misure e loro utilizzo in un piano di misurazione, altro spunto incluso nelle “linee guida contrattuali” GUFPI-ISMA 2016 [1]. Il mestiere di un misuratore è quello di creare maggiore confidenza nel proporre stime che siano il più possibile vicine al valore finale determinato al termine di un progetto. E per poterlo fare servono almeno alcuni punti di attenzione, tra cui: – aver perimetrato il corretto scope (ambito) progettuale; – non aver sottovalutato i possibili rischi e imprevisti, sia di prodotto/servizio che di progetto; – disporre di dati storici, possibilmente i propri, per un’analisi non solo analogico/esperienziale. Una stima non è una misurazione, altrimenti nessuno si sbaglierebbe mai e l’errore di stima sarebbe pari allo 0%... eppure tutti vorrebbero ottenere un risultato positivo senza spendere tempo, energie e conoscenze per conseguirlo ... Come poter accorciare i relativi tempi e costi? Analizziamo ora uno scenario
to di sovra/sotto-stimare quantità, effort e costi e quindi non ottimizzare in ogni caso la gestione di un progetto: una sotto-stima comporterebbe una minore percezione del valore di un progetto da parte dei clienti/utenti con possibili richieste di modifica in corso d’opera; una sovra-stima invece bloccherebbe un numero di asset maggiori del necessario, che potrebbero invece essere più profittevolmente utilizzati in altri progetti. Ma qual è il corretto trade-off da applicare e soprattutto come poter “indovinare” una stima minimizzando l’errore?
tipico in un contratto ICT e quali spunti IL CONO (O L’IMBUTO) migliorativi potrebbero essere inseriti. DELL’INCERTEZZA: QUANTO ERRORE È AMMESSO? PARTIRE DALLE ATTIVITÀ QUOTIDIANE PER IMPARARE NELL’ICT...
Nel mondo “quotidiano” leggere la pagina di un ricettario sembrerebbe banale, ma in fondo contiene tutto ciò che ci servirebbe per effettuare una stima. Dagli ingredienti e relative quantità (asset management), proporzionate su un dato numero di commensali (capacity management), si illustra anche la difficoltà nella preparazione del piatto (risk management), il tempo di preparazione e cottura (effort/duration), i passi da seguire per cucinare (processo/procedura) e gli eventuali abbinamenti (requisiti non-funzionali)... Insomma, ci sarebbe di tutto anche nei progetti ICT se ci fossero database e repository altrettanto “maturi” da racchiudere anni di esperienza, utili ad affinare una stima iniziale effettuata in modo analogico/esperienziale [2]. Ma analizzando le practice delle organizzazioni, da quelle più grandi a quelle più piccole, sembra sempre che non ci sia tempo (o budget) per poter operare in questo modo, con il risulta-
La Fig. 1 illustra il c.d. “cono” (o “imbuto”, se si ruotasse in senso orario di 90°) dell’incertezza e illustra come anche raccogliendo dati sugli errori commessi si possa in modo iterativo imparare a migliorare le prossime stime, affinando il margine di errore nel tempo. Maggiore (e migliore) la capacità d’imparare e non ripetere un errore, maggiore la riduzione della curva verso un range di errore ammissibile: anche nel mondo fisico i metrologi hanno una guida all’incertezza sulle misure e si propone altresì una taratura periodica degli strumenti di misurazione proprio per minimizzare gli errori, che per natura non possono non esistere [5]. Ma che possono (ovviamente) essere limitati sapendo e avendo contezza del motivo per il quale li avremmo commessi in passato. Presidente GUFPI-ISMA - Gruppo Utenti Function Point Italia Italian Software Metrics Association luigi.buglione@gufpi-isma.org
T_M
N.
1/19 ƒ 59
