Non esistono “formule magiche” che permettano di stimare al centesimo il costo della produzione di software. Esistono però molte “buone pratiche” che aiutano significativamente il Project Manager in tale attività. In questo articolo, affrontiamo l‘argomento.

Introduzione

Uno degli aspetti più delicati e controversi nella gestione di un progetto di sviluppo software è la stima dei costi. Tutti vogliono sapere “quanto costerà” il Software che deve essere sviluppato: il cliente, il capo progetto e i responsabili delle aziende interessate.

Un’accurata stima dei costi per i progetti software può portare svariati benefici sia a un’azienda che costruisce software sia a un’organizzazione che acquisisce software [ATSCSSW].

La gestione del progetto necessita di un valore attendibile, non di una cifra esatta, per:

• dimensionare il budget;
• stipulare contratti sensati (sia dal punto di vista del fornitore sia dal punto di vista dell’acquirente);
• prevedere tempi di sviluppo ragionevoli (sia dal punto di vista del fornitore sia dal punto di vista dell’acquirente) e di conseguenza ipotizzare il conseguente time to market;
• dimensionare opportunamente il team di sviluppo;
• influenzare le scelte sui fornitori ed eventualmente il “make or buy”

Stimare tempi (e costi) è attività tutt’altro che banale. Tipicamente la stima del costo è richiesta fin dall’inizio, quando le informazioni sono scarse e i contorni stessi del progetto non sono ancora ben definiti.

Purtroppo non esistono “formule magiche” che permettano di stimare il costo del Software, tuttavia il corpus di conoscenze in tale ambito si è accresciuto in modo significativo e esistono molte good practices che aiutano in tale attività il Project Manager.

In questo articolo parleremo dei principali aspetti relativi alla Software Cost Estimation illustrando alcune tecniche nelle loro linee essenziali che si collocano all’interno dell’ampia disciplina conosciuta come Software Measurement (“misurazione” del software) il cui oggetto è la quantificazione degli attributi dimensionali e qualitativi dei prodotti software e delle attività correlate al loro sviluppo (i processi).

Considerazioni preliminari

Le stime nel mondo informatico sono difficili da dare per il semplice fatto che il software è un bene “immateriale”, non è il risultato di un’attività produttiva di tipo classico e inoltre dipende molto dal fattore umano (lo sviluppatore, la metodologia utilizzata e l’organizzazione progettuale contano ovviamente più dell’IDE, del linguaggio o del Sistema Operativo che si utilizza).

La stima rappresenta un dimensionamento del tempo necessario per completare un certo sviluppo software. La stima, in quanto tale, è affetta da un margine di errore. Ovviamente la certezza assoluta nella valutazione dei costi è ottenibile solo quando il progetto è prossimo alla conclusione o è già finito (a consuntivo).

Generalmente, se si traccia l’andamento dell’errore della stima in funzione del tempo, si ottiene una curva del tipo “ramo di iperbole”: all’inizio la stima è affetta da un margine di errore che man mano decresce con l’avanzamento del progetto, con l’acquisizione di informazioni e con il tracking dei lavori [INGSW].

È bene quindi tenere presente che le stime iniziali hanno un maggiore grado di incertezza.

Citando Kent Beck e Kent Fowler: “Do not expect too much of early estimations, but do expect them to improve. The first plan is the hardest and least accurate part of release planning. Fortunately you only have to do it once. The further ahead we plan, the less accurate we will be!” [KBMFPXP].

Spesso (purtroppo) le stime vengono richieste anche se ci sono poche informazioni al contorno; in queste situazioni il rischio di commettere errori (anche grossolani) è elevato. Per questo la stima non dovrebbe essere costituita da un singolo numero, ma almeno da due: la stima e il grado di incertezza della stessa.

La stima non è “fire & forget”, cioè, non si stima una sola volta e basta [CE5PF]. La stima va sempre costantemente aggiornata e tenuta sotto controllo mediante controlli periodici e definiti (a esempio durante lo stato di avanzamento dei lavori settimanale).

A fine progetto la differenza tra la stima preventivata e il consuntivo dovrà essere oggetto della valutazione qualitativa e quantitativa delle performance del progetto (End Project document e documento di Lessons Learned).

 Figura 3 – Aggiornamento della stima lungo il ciclo di vita di progetto

Così facendo, l’esperienza progettuale (sia che il progetto sia andato “bene” o “male”) sarà cumulativa e costituirà un bagaglio informativo prezioso per i progetti futuri.

Molti e di natura diversa sono i fattori che influenzano lo sforzo necessario (effort) per eseguire un progetto software. [ATSCSSW]. Alcuni, comuni a molti ambienti, sono riportai di seguito

Dimensione del software

Tale fattore sembra essere comunemente accettato come quello principale e viene utilizzato da molti modelli di stima.

Fattori umani

La produttività dipende fortemente dalle capacità delle risorse umane impiegate, e riguarda

• Motivazioni. Il team è motivato? Il capo progetto è in grado di motivarlo? Le condizioni “ambientali” sono favorevoli al progetto? C’è “feeling” nel team e con il cliente?
• Training e skill. Il team è adeguatamente preparato? Occorrono corsi di formazioni e/o mentoring?
• Ciclo si sviluppo del Software. Il SDLC è definito? È consolidato? Prevede le opportune metriche di Qualtiy Software Assurance?

Complessità dell’applicazione

A parità di tutti gli altri fattori, applicazioni diverse possono avere livelli diversi di difficoltà.

Stabilità dei requisiti

Si tratta senz’altro di uno dei fattori più critici, soprattutto per i problemi che possono essere causati da variazioni dei requisiti a progetto già avviato, specialmente quando il progetto sia già in fase avanzata.

Nuove tecnologie

Utilizzare tecnologie nuove, che non sono già state ampiamente utilizzate in progetti precedenti, può aggiungere un aspetto di complessità.

Ambiente di sviluppo

L’utilizzo di determinati ambienti di sviluppo ha la sua importanza nei progetti.

Ambiente lavorativo

Si comprende facilmente che anche questo ha la sua influenza sul progetto.
Uno degli approcci più comuni si basa sul fattore esperienza operando per analogia con implementazioni similari (prassi totalmente qualitativa).
Lo stesso PMBOK, Project Management Body of Knowledge [PMBOK] prevede tra le tecniche per la stima della durata delle attività di un progetto l'”expert judgement” (stima basata sull’esperienza) e la stima per analogia (“analogous estimating”), mentre al terzo posto prevede l’utilizzo di modelli (“simulation”).

La misurazione di qualsiasi entità dovrebbe però essere il più possibile guidata da valutazioni oggettive e non soggettive o quantomeno tentando di riportare a oggettivo quello che per sua natura oggettivo non è: “You cannot control what you cannot measure”.
In linea teorica sarebbe quindi preferibile un criterio quantitativo o quantomeno un mix tra i due approcci (come vedremo più avanti).
È fondamentale tenere bene presente che la Software Cost Estimation non ha l’obiettivo di “indovinare” o “predire” il numero esatto di giorni uomo necessari per sviluppare un’applicazione, bensì fornirne una stima.

Metodologie di cost estimation

L’immagine che segue riassume le principali metodologie di cost estimtion.

Di base è possibile effettuare una distinzione tra due famiglie di metodi di stima: quelli basati su modelli e quelli che non lo sono.

Metodi basati su modelli

I modelli di cost estimation permettono di calcolare tempi ed “effort” a partire da una stima delle dimensioni complessive del software da sviluppare. L’effort che si ottiene è in funzione del “size” del software:

effort=f(size)

Il punto di partenza per il calcolo dell’effort è la dimensione di un progetto. Esistono vari tipi di metriche per la misurazione del software. Le Metriche Dimensionali: definiscono le dimensioni del prodotto software in funzione del numero di occorrenze di un determinato oggetto: Line Of Code (LOC), numero di programmi, strutture dati.

Le Metriche Funzionali definiscono le dimensioni di un prodotto software in termini di funzionalità fornite all’utente. Si basano su formule empiriche, stabilite su base statistica (Function Points, Use Case Points, Object Points).

I più noti modelli di Software cost estimation sono:

• COCOMO TRW (Boehm)
• FUNCTION POINTS IBM (Albrecht)
• ESTIMACS Computer Associates (Rubin)
• PRICE RCA
• SLIM QSM (Putnam)
• SPQR Software Productivity Research

Tra questi COCOMO è uno dei più consolidati. Il modello COCOMO 81 (COnstructive COst MOdel, sviluppato da Barry Boehm a partire dell’inizio degli anni Ottanta) è stato sviluppato con il presupposto che sarebbe stato usato un processoWaterfall (analisi, progetto, sviluppo e test) e che tutto il software sarebbe stato sviluppato da zero.
Il modello COCOMO è espresso da più formule che forniscono lo sforzo e il tempo necessario per lo svolgimento delle attività dal progetto fino al test di accettazione. I costi per la pianificazione e l’analisi dei requisiti sono calcolati a parte. Tali formule sono state ottenute in base ai dati relativi ai costi di una serie di progetti reali appartenenti a alcuni settori applicativi.

Nel modello base l’unica variabile indipendente considerata è la dimensione S in KLOC (KiloLines Of Code, “migliaia di linee di codice”) dell’applicazione, che viene utilizzata per calcolare innanzitutto lo sforzo M in mesi-persona e il tempo di sviluppo T in mesi e inoltre fornisce anche la ripartizione di sforzo e tempo tra le diverse fasi in base a percentuali che dipendono dalle dimensioni dell’applicazione. Oltre a questo, il modello COCOMO permette di effettuare anche il dimensionamento del team di sviluppo per ciascuna fase. Il numero di appartenenti al team di sviluppo in una qualsiasi fase si ottiene dividendo lo sforzo necessario per la fase per il tempo necessario per svolgere la fase.

Dalla sua formulazione (COCOMO 81) ci sono stati molti cambiamenti nell’ingegneria del software. COCOMO II è l’aggiornamento del modello COCOMO 81 ed è stato progettato per adattarsi ai diversi nuovi approcci dello sviluppo del software [WP_COCOMO].

Una lista di tool di Software Cost Estimation che applicano il metodo COCOMO è disponibile al seguente link

http://www.laatuk.com/tools/effort_estimation_tools.html

Figura 6 – Costar COCOMO Effort estimation tool [COSTAR]

Metodi parametrici

Il metodo parametrico consiste nell’introduzione delle caratteristiche del progetto in un modello matematico per la stima del costo utilizzando una serie di fattori con dei relativi pesi. Il costo totale deriva dalla sommatoria di tutti i fattori per il relativo peso.

Function Points & Use Case Points

La Function Point Analysis (FPA) e lo Use Case Points sone metriche standard per la misurazione delle applicazioni Software viste dal punto di vista dell’utente.

Il modello dei Function Point introdotto da Albrecht è diventato successivamente uno standard internazionale per la misurazione funzionale riconosciuto a livello ISO (International Organization for Standardization) che dimensiona la parte funzionale del software, ossia considera le funzionalità in esso contenute a partire dal punto di vista dell’utente finale e indipendentemente da considerazioni di tipo tecnico come linguaggi, piattaforma, architettura, ecc.

Lo scopo del metodo è quindi quello di quantificare solo le funzionalità che il programma offre all’utente. Questa tecnica è fondata su due requisiti fondamentali: i FP devono essere indipendenti dalla tecnologia e devono misurare tutte e sole le funzioni consegnate all’utente.

Di seguito viene illustrata, a grandi linee, la procedura per il conteggio dei Function Points e le sue componenti (per dettagli vedere [FPJP])

Lo Use Case Points (Gustav Karner nel 1993) è una modifica al Function Points e basa il suo funzionamento sugli Use Case dell’utente.

Use Case Point Cost Estimation

Questa tecnica di stima si basa sul concetto di Use Case Point (UCP) il cui valore misura la “grandezza” (o il peso) dell’applicazione.

Il numero di UCP è direttamente proporzionale ai seguenti parametri:

• Numero e complessità dei Casi d’Uso del sistema
• Numero e complessità degli Attori coinvolti nel sistema
• Requisiti non-funzionali (come portabilità, performance, manutenibilità, …)
• Fattori relativi all’ambiente dove viene sviluppato il progetto (p.e.: tecnologie, strumenti di sviluppo, motivazione del team, meodologia di sviluppo, …)

L’equazione per determinare l’UCP si compone di 5 variabili:

• Peso Totale dei Casi D’Uso (Unadjusted Use Case Weight – UUCW)
• Peso Totale degli Attori (Unadjusted Actor Weight – UAW)
• Fattore di complessità Tecnica (Technical Complexity Factor – TCF)
• Fattore di complessità dell’Ambiente (Enviroment Factor – EF)
• Fattore “correttivo” (FC)

Ogni variabile è definita e calcolata separatamente; l’equazione completa è:

UCP = UUCP * TCF * ECF * FC (dove UUCP = UUCW + UAW)

Peso Totale dei Casi D’Uso (UUCW)

Il “Peso” di ogni singolo caso d’uso è proporzionale alla sua complessità espressa in termini di transazioni ossia dal numero dei passi necessari per raggiungere il suo scopo cioè lo “User Goal” “[CBWEUC].

 Figura 8 – Esempio di conteggio delle transazioni di uno Use Case [MCEWUCP]

Partendo dall’analisi degli use case steps (con tutte le difficoltà annesse e connesse al conteggio dovute alla bontà e al giusto livello di dettaglio di descrizione [EOOSPWUC]) è possibile classificare un caso d’uso su tre categorie di complessità diverse (semplice, medio e complesso) e ottenere il relativo “peso”.

Sommando tutti i pesi dei singoli casi d’uso del sistema si ottiene il valore della variabile “Unadjusted Use Case Weight” (UUCW) ossia il peso totale “non adeguato” dei casi d’uso.

 

Figura 9 – Esempio di UUCW [TEISDP]

Peso Totale degli Attori (UAW)

Analogamente ai Casi d’Uso, è possibile classificare la tipologia di Attori in semplice, medio e complesso.

• Semplice: Interazioni di basso livello con protocolli conosciuti (p.e.: interazione con DBMS, Web Services, …)
• Medio: Interazioni di basso livello con protocolli non standard o poco conosciuti
• Complesso: Interfaccia utente (complessità di realizzazione e soggetta a frequente revisione)

Con il termine “Attore” viene identificato qualsiasi “soggetto” che interagisce esternamente con il sistema (p.e.: un operatore, un altro programma/servizio, un sistema hardware, …). Ogni tipologia di Attore ha un determinato peso in funzione della complessità che apporta al sistema per permettergli di interfacciarsi. Ad esempio: un operatore potrebbe interagire con il sistema attraverso un’interfaccia “spartana” a linea di comando mentre un altro potrebbe richiedere un’interfaccia grafica complessa (GUI oppure Web); il peso che si deve attribuire (in termini di complessità di progettazione e sviluppo) alle diverse tipologie di operatori deve essere differente.

Figura 10 – Esempio di UAW [TEISDP]

Calcolando la sommatoria dei prodotti di tutti pesi delle singole tipologie per il numero di attori relativi si ottiene il valore della variabile “Unadjusted Actor Weight” (UAW) ossia il peso totale “non adeguato” degli attori.

UUCP = UAW + UUCW

Calcolo del Technical Complexity Factor (TCF)

Il passo successivo è calcolare la complessità tecnica del sistema decretando gli opportuni pesi per ogni fattore. I valori da assegnare devono essere compresi tra 0 (irrilevante) e 5 (importante).

La sommatoria di tutti i 13 pesi per il relativo valore assegnato prende il nome di TFactor. Il fattore di complessità tecnologico è calcolato mediante la seguente formula:

TCF = 0,6 + (0,01 * TotalFactor)

dove 0,6 e 0,01 sono i valori attribuiti alle costanti C1 e C2.

Calcolo dell’Environment Factor (EF)

Analogamente a quanto fatto per i fattori tecnologici, si deve adesso valutare il fattore “ambiente” (Environment Factor) tenendo conto a esempio dei seguenti elementi:

Anche in questo caso i valori da assegnare devono essere compresi tra 0 (ininfluente) e 5 (determinante). La sommatoria di tutti gli 8 pesi per il relativo valore assegnato prende il nome di EFactor.
La formula per il calcolo dell’EF è:

EF = C1 + (C2 * Efactor)

dove C1 e C2 sono due costanti che valgono rispettivamente 1,4 e -0,03.

Calcolato quindi i fattori relativi al peso dei casi d’uso, al peso degli attori in gioco, i fattori TCF e EF è possibile calcolare lo Use Case Points (UCP). Bisogna moltiplicare tra loro i fattori UUCP, TCF e EF precedentemente calcolati.

UCP = UUCP * TCF * EF

dove

UUCP = UAW + UUCW

Il risultato ottenuto deve essere moltiplicato per un fattore “correttivo” (FC) che permette la conversione degli Use Case Points in ore uomo. Karner determinò che tale fattore dovesse essere di 20 ore uomo per ogni use case.

Stima finale UCP = UCP * 20

Successivamente, Schneider e Winters proposero che tale fattore moltiplicativo potesse variare a secondo della complessità dei fattori ambientali (Efactor). [AUCAPC]

Nello specifico si prevede che il fattore correttivo sia 28 (quindi il 40% in più rispetto al valore originario 20) nel caso in cui ci siano 3 fattori ambientali di rischio simultaneamente. [EOOSPWUC].

A esempio nell’immagine seguente si riportano due casi di estimation. Nel primo caso (fig. 13A) il fattore correttivo è 20 perche’ si è in presenza di due soli fattori ambientali critici (E4 e E6). Nel secondo caso (fig. 13B), essendo i fattori critici ben quattro (E2, E4, E5 e E6) il fattore correttivo è 28. Si noti che la stima passa da 37,7055 gu (giorni uomo) a 57,6356 gu.

Il modello UCP può essere facilmente realizzato mediante un foglio di calcolo tipo Excel, anche se a oggi inizia a essere disponibile nei tool come a esempio in Enterprise Architect di Sparx
http://www.sparxsystems.com.au/resources/ucmetrics.html

Metodi non basati su modelli

Tali metodi non implicano la costruzione di modelli, ma direttamente la produzione di una stima.

Pricing-to-win

Come suggerisce il nome, il metodo Pricing-to-win. viene utilizzato per aggiudicarsi una gara o un contratto su base meramente economica.
Se da un lato può essere effettivamente utile per aggiudicarsi un contratto, può portare molti problemi di processo (ad esempio difficoltà nel rispettare tempi/costi stabiliti) e il prodotto finale può esserne pesantemente influenzato (ad esempio qualità inferiore) con possibili danni di immagine e sopravvivenza dell’organizzazione di sviluppo nel lungo termine (il vero cliente è quello che ti cerca almeno per la seconda volta).
Il Price-to-win porta sistematicamente a problemi grossi di gestione di progetto e tali rischi devono essere pesati e gestiti (Risk Management) prima di consegnare l’offerta.
Per onore di cronaca è bene citare la cosiddetta “Stima alla Parkinson” in cui si assume che un progetto software consumi semplicemente tutto il budget a sua disposizione (!?). Ovviamente questa valutazione segue razionali esclusivamente commerciali e in realtà non ha alcuna dignità metodologica: la valutazione prescinde totalmente dall’applicazione, dall’ambiente e dal team.

Expert judgement

Si effettua consultazione di uno o più esperti (se possibile almeno due, per avere un check incrociato) per derivare una stima dello sforzo che è di tipo soggettivo.
Lo sforzo può essere determinato bottom-up oppure top-down, in base a una scomposizione per componenti oppure per attività. Si può inoltre effettuare una stima dello sforzo d’integrazione dei componenti oppure delle attività, in modo da ottenere un totale quanto più possibile accurato.

Estimation by analogy

La stima per analogia consiste nel riuso dell’esperienza accumulata e opportunamente documentata (diagrammi di Gantt precedenti, lessons learned, PID, End Project document, …) per fornire previsioni su quanto si dovrà realizzare. L’idea principale è quella di identificare progetti già completati che siano particolarmente simili a un progetto nuovo.
Di fatto si deducono a consuntivo gli standard di produttività per le WBS su cui esiste un insieme significativo di esperienze.

Tale metodologia è applicabile solo se si ha un adeguato processo di PM e se si ha un Repository di progetti da cui attingere. Nelle strutture complesse, questo è il tipico compito di un PMO che controlla l’avvenuta chiusura dei progetti, il loro utilizzo e la loro storicizzazione.

Programming based time estimation

Questa regola empirica si basa nel dare un generico modello che riporta le percentuali per ogni fase prevista dal ciclo di sviluppo Software. Di fatto è una “rules of thumb”, una regola empirica, che permette una facile e immediata (quanto sommaria) stima dei costi senza richiedere particolari calcoli e ragionamenti al contorno.
A esempio, la regola sotto proposta prevede che l’analisi cubi il 10% del tempo totale di lavoro, il Design e la raccolta dei dati di test il 20%, lo sviluppo il 35%, il test il 25%, la documentazione e il delivery 5%, con un overhead del 5%.

Figura 15 – Programming based time estimation (rules of thumb) [TEISDP]

Considerazioni

Da quanto fin qui descritto, è facile desumere che non esiste una verità assoluta o un metodo che funzioni sempre e comunque. L’importante è utilizzare un metodo di cost estimation in modo serio e pragmatico stando sempre attenti a effettuare l’opportuna “calibrazione” in modo iterativo e continuativo. Riporto ad esempio le mie esperienze relative alle attività e ai progetti che mi coinvolgono.
Quando è possibile, utilizzo un mix dei differenti approcci visti precedentemente. Per prima cosa stimo in base all’esperienza (“by experience”) e poi si confronta tale stima con una ottenuta per analogia (“by analogy”). La stima che ottengo dal confronto di queste due la sottopongo a un “controllo” qualitativo con la regola empirica “Programming based time estimation”. Se è vero che questa regola approssimativa è “debole” da utilizzare da sola, è altrettanto vero che può essere un buon controllo per verificare la stima sino a ora candidata. Infine applico lo Use Case Point. “Incrociando” tra loro le stime ottenute, mi ricavo la stima da presentare al cliente decidendo il fattore di incertezza. Quest’ultimo è basso se le stime calcolate “convergono” allo stesso ordine di grandezza.

Un esempio pratico

In una applicazione Multicanale mi è stata richiesta la stima per fare evolvere un servizio per gestire un nuovo canale. Tale servizio si occupa di recuperare una lista di operazioni da un DBMS e di effettuare il filtraggio di tali dati con logiche specifiche per il canale in esame. By experience, il mio “braccio destro” ha dichiarato una stima di 32 gu (giorni-uomo) derivante da queste voci:

• 3 gu di Analisi
• 5 gu di Design
• 3 gu per accedere al DBMS
• 3 gu per la logica di filtro del servizio
• 5 gu per la parte Web
• 7 gu per i test
• 1 gu per le procedure di SQA (Audit code, code Covergae e report dei test)
• 2 gu per la documentazione di rilascio
• 2 gu per il delivery
• 1 gu per il test d’integrazione

il tutto ipotizzando un Design in base al precedente sviluppo e tenendo conto delle Linee Guida Architetturali del progetto.

“By analogy”, reperendo le informazioni relative al consuntivo dei precedenti sviluppi degli altri canali ho a disposizione una stima di 37 gu (ottenuta dalla media dei consuntivi ottenuti per lo sviluppo dei tre precedenti canali: 44 gu del primo canale, 30 gu del secondo e 37 del terzo canale). Confrontando le due stime tra di loro (32 gu e 37 gu) abbiamo che sono dello stesso ordine di grandezza. Prendo come stima candidata la media tra le due approssimandola per eccesso per comodità di calcoli: 35 gu. Applichiamo ora la regola empirica Programming based time estimation tenendo conto che lo sviluppo in esame avviene mediante un ciclo di sviluppo iterativo incentrato sulla pratica agile TDD [MOKA-METH] e partendo dalla previsione di 3 gu per l’analisi.

Otteniamo 28,5 gu che conferma indicativamente il precedente ordine di grandezza della trentina di giorni. Per il momento confermo quindi la stima candidata di 35 gu.

Eseguo come ultimo passo del nostro processo di cost estimation il calcolo mediante UCP. Classificando gli Use Case Point prevedo due attori di bassa complessità (l’interfaccia Web via HTTP e l’accesso a DBMS mediante Hibernate) e uno Use Case di media complessità.

Il risultato che ottengo è: 30,356 gu.

Tiriamo le somme. L’attività sembra essere dell’ordine di grandezza della trentina di giorni. Confrontando i 35 gu sino a ora calcolati (By experience, By Analogy e Programming based time estimation ) con la stima UCP di 30,35 gu scelgo come valore della stima la media tra le due, approssimandola per eccesso: 33 gu. L’affidabilità della stima è buona perche’ i vari valori delle stime ottenute sono indicativamente dello stesso ordine di grandezza; assumo quindi un valore di incertezza del solo 10%. Se le singole stime invece risultassero molto diverse tra di loro, assumerei un maggiore fattore di incertezza (20% o 30%). Nel caso di fattore d’incertezza maggiore del 30% mi sembra doveroso esigere un approfondimento del contesto del progetto per essere in grado di diminuire il fattore d’incertezza e dare una stima più affidabile.

Figura 20 – Stima dell’esempio proposto

Conclusioni

Il tema Software Cost Estimation riveste una grande importanza economica, sia per i costruttori sia per gli acquirenti di software e spesso guida e determina importanti decisioni di business. Come si è visto, non è possibile definire regole precise valide in tutti gli scenari e in generale la stima dei costi è una prassi ardua e delicata su cui è bene maturare esperienze e riflessioni.
La stima dei costi non è un’attività che deve essere compiuta “una tantum”, ma deve essere controllata e revisionata periodicamente. Solo attraverso un processo rigoroso e basato sul miglioramento continuo (storicizzazione dei Gantt di progetto, analisi dei consuntivi, lesson learned, …) il proprio approccio alla Software Cost estimation può essere efficace.

Riferimenti

[KBMFPXP] K. Beck – M. Fowler, “Planning Extreme Programming”, Addison Wesley, 2000

[PMBOK] “A Guide to the Project Management Body of Knowledge (PMBOK)”, 2000 Edition, Project Management Institute, ISBN 1-880410-23-0
http://www.pmi.org/

[EOOSPWUC] K. Ribu (University of Oslo-Department of Informatics), “Estimating Object-Oriented Software Projects with Use Cases”
http://heim.ifi.uio.no/~kribu/oppgave.pdf

[MCEWUCP] M. Cohn, “Estimating With Use Case Points”
http://www.methodsandtools.com/archive/archive.php?id=25
http://www.methodsandtools.com/PDF/mt200503.pdf

[TEISDP] Thomas Fihlman, “Time estimation in software development projects”
http://www.callista.se/ITPartner/timeart.htm

[AUCAPG] G. Schneider – Jason P. Winters, “Applying Use Cases: A Practical Guide”

[GKREFOP] Gustav Karner, “Resource Estimation for Objectory Projects”
http://www.bfpug.com.br/Artigos/UCP/Karner%20%20Resource%20Estimation%20for%20Objectory%20Projects.doc

[AJALBRECHT] A.J Albrecht, “Measuring Application Development Productivity”, Proc. of IBM

[RCPEUCP] Roy Clem, “Project Estimation with Use Case Points”
http://www.codeproject.com/gen/design/usecasep.asp

[ISSCE]
Ian Sommerville, “Software Engineering 7”, “Chapter 26: Software Cost Estimation”
http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/SampleChapters/index.html

[AC-UCG] A.R. Cockburn, “Writing Effective Use Cases”, Addison-Wesley, 2001
http://alistair.cockburn.us/index.php/Structuring_use_cases_with_goals

[AUCAPG] G.Schneider – J. P. Winters, “Applying Use Cases. A Practical Guide”

[PMRDA] R.D. Archibald, “Project Management. La gestione di progetti e programmi complessi”, Franco Angeli, 2006

[WPCOCOMO]
http://en.wikipedia.org/wiki/COCOMO

[INGSW] A. Binato – A. Fuggetta – L.Sfardini, “Ingegneria del Software. Creatività e metodo”, Pearson/Addison Wesley, 2006

[WP_FPA]
http://en.wikipedia.org/wiki/Function_point_analysis

[COCOMONASA]
http://cost.jsc.nasa.gov/COCOMO.html

[COSTAR]
http://www.softstarsystems.com/

[FPJP] M.Lelli, “Misurare il software con i Function Points”
http://www.javaportal.it/rw/39650/editorial.html

[CE5PF] F. Rabini, “Software Cost Estimation. 5 pezzi facili”
http://www.cs.uniroma2.it/upload/2006/ASS/Software%20Cost%20%20Estimation.pdf

[ATSCSSW] S. Morasca, “Analisi di tecniche di stima dei costi di sviluppo del software”
http://www.cnipa.gov.it/site/_files/Morasca-convegno%20FP.pdf

[MOKA-METH] Articoli della sezione di Metodologia a cura di Stefano Rossini
1. “Offshore. I parte: Le Metodologie Agili & i Progetti Offshore”, MokaByte 108, Giugno 2006
2. “Offshore. II parte: Best Practices per la gestione di Progetti Offshore (1)”, MokaByte 109, Luglio/Agosto 2006
3. “Offshore. III parte: Best Practices per la gestione di Progetti Offshore (2)”, MokaByte 110, Settembre 2006
4. “Offshore. IV parte: Best Practices per la gestione di Progetti Offshore (3)”, MokaByte 111, Ottobre 2006
5. “Pratiche di sviluppo del software. I parte: TDD: Test Driven Development”, MokaByte 86, Giugno 2004
6. “Pratiche di sviluppo del software. II parte: Continuous Integration: la teoria”, MokaByte 87, Luglio/Agosto 2004
7. “Pratiche di sviluppo del software. III parte: Continuous Integration: la pratica”, MokaByte 88, Settembre 2004
8. “Pratiche di sviluppo del software. IV parte: Refactoring”, Mokabyte 89, Ottobre 2004
9. “Pratiche di sviluppo del software. V parte: Spike Solution”, MokaByte 93, Febbraio 2005
10. “Pratiche di sviluppo del software. VI parte: QSA mediante Code Coverage”, MokaByte 99, Settembre 2005
11. “SDLC: Processi e metodologie di sviluppo. I parte: introduzione alle metodologie di sviluppo”, MokaByte 83, Marzo 2004
12. “SDLC: Processi e metodologie di sviluppo. II parte: le metodologie agili”, MokaByte 85, Maggio 2004
13. “Quality Software Assurance. I parte: QSA mediante auditing del codice”, MokaByte 90, Novembre 2004
14. “Quality Software Assurance. II parte: i Test”, MokaByte 91, Dicembre 2004
15. “Il profiling di applicazioni Java”, MokaByte 90, Novembre 2004