11/10/2003, White paper

Introduzione

Uno dei punti di maggior interesse per un Project Manager è quello di poter calcolare l’effort necessario per sviluppare un progetto il prima possibile e con il maggior livello di confidenza possibile. Buona parte dei progetti sviluppati basano la stima sul fattore esperienziale; la capacità del PM di prevedere i possibili rischi di progetto nel modo più accorto possibile, ma totalmente qualitativo, per analogia con esperienze o implementazioni simili è sicuramente una pratica largamente diffusa.

D’altronde anche una guida di riferimento come il Project Management Body of Knowledge (PMBOK) [PMI00] nei processi “core”, in particolare quello di “Activity Duration Estimation” (6.3), identifica tra le tecniche per la stima della durata delle attività di un progetto al primo posto l’”expert judgement”, al secondo la stima per analogia (analogous estimating) e solo al terzo posto un criterio quantitativo (quantitatively based durations), dato dalla moltiplicazione di una qualsivoglia unità di conteggio tecnica per il livello medio di produttività. In conclusione, il PMBOK indica un cuscinetto di effort (contingency o buffer) da considerare per fronteggiare eventuali rischi di progetto.

La misurazione di qualsiasi entità dovrebbe però essere il più possibile guidata da valutazioni oggettive e non soggettive. Quantomeno tentando di riportare ad oggettivo quello che oggettivo per sua natura intrinseca non è, al fine di poterlo opportunamene gestire. “You cannot control what you cannot measure” recita il celebre adagio di Tom De Marco [BUGL03a].  Andrebbe quindi preferita, se possibile, la terza via suggerita dal PMBOK.

Negli ultimi 25 anni la comunità dell’Ingegneria del Software ha indirizzato notevoli sforzi ed attenzione al tema della stima. La diffusione ed applicazione di modelli basati sull’analisi di regressione quali COCOMO [BOEH81] [BOEH00] può dare una misura di quanto affermato, dove la relazione tra effort e size è la seguente:

ovverosia il punto di partenza per il calcolo dell’effort è la dimensione di un progetto, il suo “size”. In questa sede non si discuteranno le possibili varianti della funzione f per derivare l’effort necessario a realizzare una data entità rimandando a [CONT86], testo di riferimento per i temi della stima in un progetto di sviluppo sofware.

Ma quali “sizing units” sono tipicamente utilizzate per dimensionare un progetto software?

I Function Points [ALBR79][ALBR84] con le sue diverse varianti ed evoluzioni (identificabili come FSM – Functional Size Measurement methods [2] ) sicuramente rappresentano la famiglia di tecniche di dimensionamento più affidabile e in crescente diffusione nel mondo del Software Engineering. [JONE97] riassume efficacemente la questione del paradosso della produttività comparando cosa comportava un conteggio usando Linee di Codice (LOC – Lines of Code) in luogo di una misura funzionale [3] .  I concetti alla base della misurazione funzionale si riassumo sinteticamente in un conteggio del numero di funzionalità (incluse nel boundary) dal punto di vista dell’Utente, espresse  attraverso un dato numero di entità tecniche, ciascuna delle quali pesata secondo il rispettivo livello di complessità, a cui sommare una porzione aggiuntiva legata alla complessità generale di quella specifica soluzione software. Si potrebbe riassumere in modo generico il tutto nella seguente maniera:

Ma in quale momento si può calcolare il size e sulla base di quali informazioni?

Nel FPA CPM (Counting Practice Manual – Manuale delle Regole di Conteggio) 4.1.1 [IFPU00], si identificano nel Capitolo 3 tre categorie di documenti – derivati dallo studio di fattibilità - rispetto ai quali il livello di dettaglio e di precisione nel conteggio aumenta progressivamente:

·        Initial User Requirements (Requisiti Utente iniziali): questa fase rappresenta i requisiti utente antecedenti l’incontro tra l’utente ed il gruppo di sviluppo. Le caratteristiche associate all’utilizzo di documentazione in questo stadio sono quelle di poter essere: incompleta, non presentare alcune utilità non evinte dall’analisi, difficoltà nell’implementazione, eccessiva genericità dei requisiti che non permettono di poter ottenere il corretto numero di Function Points.

·        Initial Technical Requirements (Requisiti Tecnici Iniziali): questa fase rappresenta il punto di vista degli sviluppatori dei requisiti utente creati nello studio di fattibilità. Sono quindi inclusi elementi tecnici per l’implementazione, che comunque potrebbero non essere tenuti presenti nel conteggio. Le caratteristiche associate all’uso di documentazione a questo stadio sono quelle di poter essere: dipendente dalla tecnologia, identificazione non corretta delle necessità fuunzionali dell’Utente, eccessiva enfasi sugli aspetti tecnici, confini (boundaries) definiti in funzione dell’architettura tecnica di altre applicazioni dell’Organizzazione.

·        Final Functional Requirements (Requisiti Funzionali Finali): questa fase rappresenta infine il risultato dell’incontro tra l’Utente e il gruppo di sviluppo, e permette di poter rendere consistente e completa la definizione dei Requisiti Funzionali (functional requirements). Tale versione finale si ottiene quindi prima che inizi la fase di sviluppo. Come recita il Manuale di Conteggio, “Il conteggio dei Function Points, assumendo che non vi siano stati cambiamenti nell’ambito del conteggio, dovrebbe essere consistente con il conteggio alla fine dello sviluppo”.

Pertanto, il calcolo della dimensione di progetto con un metodo FSM come FPA può essere effettuato però solo a seguito della fase di “Analisi” nel ciclo di vita di un progetto, disponendo di un dettaglio informativo “avanzato” sulle modalità implementative del software da rilasciare al Cliente.

Le esigenze di business richiedono però sempre più di anticipare il momento della stima della dimensione, per poter effettuare quella sull’effort necessario e definire il costo (e i ricavi attesi) di un progetto. A convalida di tale tendenza, sono state difatti create a tal scopo negli ultimi anni versioni “anticipate” dei Function Points o più recentemente dei COSMIC-FFP [MELI97], che permettono chiaramente un risparmio sul tempo per effettuare il conteggio, sebbene a fronte di una approssimazione meno accurata del risultato finale di size e conseguentemente, se utilizzati in un sistema previsionale, dell’effort stimato da considerare per lo sviluppo della soluzione software rispetto all’uso “pieno” di una data tecnica di conteggio.

Metodi “anticipati” e “standard”: collaborativi o concorrenti? 

Tali versioni “early”, sebbene con un livello di dettaglio minore, presentano comunque un conteggio delle entità tecniche (input, output, enquiry, microfunzionalità, ....). Correttamente, a fronte di un database consistente di dati di progetto misurati sia con la tecnica “piena” che con quella “anticipata” è possibile calcolare un valore di conversione da poter applicare poi suoi nuovi progetti, usando la tecnica anticipata, che permetterà di ottenere con buona approssimazione il numero di size “standard”. Riassumendo in forma generalizzata:

Quindi, attraverso l’analisi degli MRE (Mean Relative Errors) e del PRED(0.25) di progetto e quelli dell’intero database dei progetti, è possibile verificare e valutare la bontà delle stime effettuate con i due sistemi, quello “standard” e quello “anticipato”.

Altra possibile soluzione rimane quella di adottare solo il metodo anticipato, valutando MRE e PRED(0.25) solo con riferimento agli effort stimati e consuntivati, cioè rispetto a sé stesso, per derivare in tal modo il valore di aggiustamento da applicare per derivare il numero corretto di giorni/uomo.

Metodi “anticipati”:  in quale fase del Software Life Cycle?

Uno standard sui cicli di vita del software (SLC – Software Life Cycle) come ISO/IEC 12207:1995 [ISO95] riporta un elenco dei “processi, attività e compiti” da applicare per lo sviluppo o manutenzione di un sistema software, ma espressamente  “non specifica i dettagli per l’implementazione o eseguire i compiti inclusi nei singoli processi” (capitolo 1.5).

Prescindendo dal dettaglio tecnico sulle diverse organizzazioni di “cicli di vita” (waterfall, spirale, prototipale, ...) e i relativi criteri di selezione, va considerata una ulteriore fase antecedente, quella del bid (offerta tecnica), il cui output informativo – in caso di vincita - è più consistente del solo studio di fattibilità. I principali modelli di Software Process Improvement (SPI) sono di ausilio nel ricavare tale informazione nascosta.

- SPICE98 (ISO/IEC 15504:1998)

Il processo relativo al Project Management è codificato in SPICE98 come MAN.2 (Project Management) e presenta 12 Base Practices (BP), definite in sequenza temporale di implementazione. In particolare va notato che MAN.2.BP4 (Size and Estimate tasks and resources) precede temporalmente la BP.10 (Establish and implement Project Plans). Nell’Appendice A della parte 5 del modello ISO [ISO98] vengono inoltre elencati gli input e gli output per ciascuno dei processi definiti, figurando per MAN.2 difatti una serie di outcomes dal processo di bid (es: contratto, agreement con il cliente, specifiche funzionali di alto livello, informazioni sull’ambiente per lo sviluppo, ...). La fase di analisi dei “requisiti tecnici finali” per il calcolo dei Function Points in SPICE è identificabile nei processi primari, in ENG.1.3 (Software design), al termine del quale saranno disponibili anche i dettagli sui database, necessari per un corretto calcolo dei DET e dei RET per la componente dati nella FPA.

- Sw-CMM v1.1 (1993)

Il processo di Pianificazione in Sw-CMM v1.1 [PAUL93] è incluso nella KPA di Livello 2 denominata SPP (Software Project Planning). In particolare l’attività 9 (Ac9) al punto 1 indica che le stime per il dimensionamento del software debbono essere effettuate per tutti i principali software work products ed attività incluse nel progetto, indicando nell’esempio alcune metriche di riferimento tra cui LOC e Function Points, mentre l’attività 2 (Ac2) specifica che la pianificazione del progetto software (intesa come sottoparte del progetto complessivo) inizia nelle prime fasi e in parallelo con la pianificazione dell’intero progetto. La attività di analisi viene invece regolata nella KPA di Livello 3 denominata SPE (Software Product Engineering). In particolare il Software Design è descritto nella attività 3 (Ac3), con analoghe considerazioni rispetto a quanto detto sopra per i processi SPICE.

Quindi, se non si disponesse del dettaglio informativo necessario per produrre il numero di Function Points in un certo momento del ciclo di vita del progetto, quale valore di size dovrebbe dichiarare un Project Manager per poter effettuare la stima dell’effort e quindi pianificare le attività e creare il Gantt?

Project Size Units (PSU)

La domanda precedente è volutamente provocatoria, ma deriva dall’esperienza concreta sviluppata dall'Autore e in corso d’opera per l’implementazione interna in SchlumbergerSema, volta al raggiungimento del Maturity Level 3 (ML3) del Sw-CMM v1.1 per la fine del 2003. Per motivi di riservatezza si riportano i soli concetti guida, senza però esprimere l’interezza dei dettagli implementativi.

Alcune premesse necessarie: non tutti i progetti passati, censiti in un database storico, dichiaravano una size unit, basandosi – come introdotto in apertura – sul fattore esperienziale e sulla stima per analogia, i primi due criteri elencati dal PMBOK.

Se però l’applicazione di un criterio quantitativo (terzo criterio del PMBOK) quale quello dei Function Points o misure funzionali similari è possibile solo dopo la chiusura della fase di Analisi e Disegno, quale è il giusto “metro” – che ne rispetti gli stessi principi guida - per dimensionare la soluzione software in oggetto ed utilizzare tale numero in un sistema previsionale, al fine di derivare nella fase di Pianificazione il numero di giorni/uomo necessario?

La risposta, già introdotta, è stata quella di pensare ed introdurre una tecnica di stima “anticipata”. Nel caso di SchlumbergerSema, questa tecnica originale prende il nome di PSU (Project Size Unit) [BUGL03b], mutuata dalla logica della misurazione funzionale espressa nella Function Point Analysis. Se, come detto, la FPA misura la dimensione funzionale di un software al momento t_x nel ciclo di vita, PSU intende – almeno nelle intenzioni – riprendere gli stessi principi ispiratori, trasponendoli al momento t_(x-1) del ciclo di vita, riferiti agli oggetti disponibili in quel dato momento temporale. Riprendendo l’equazione generica per il calcolo del size usando un metodo funzionale:

i seguenti punti sono stati affrontati:

·        Entità. La domanda di partenza è stata: quali informazioni sono disponibili nel momento in cui viene richiesto di effettuare la stima, ovverosia al termine dell’aggiudicazione di un Bid? Il dettaglio – non indifferente - è di fornire una “risposta” consistente per tutti i i progetti, indipendentemente dalle singole particolarità o modus operandi del singolo Project Manager. Gli oggetti sicuramente disponibili sono i Requisiti Utente, diversamente formulati dal Cliente, come tutti gli allegati tecnici prodotti dal Fornitore con la soluzione tecnica accettata (si presuppone che la gara sia vinta e si stia iniziando con la pianificazione del progetto), ma ancora non sufficientemente dettagliati per poter effettuare un calcolo a livello di numero di input, output, files, tabelle e via dicendo. Pertanto i semplici requisiti utente rappresenterebbero una sovra-semplificazione. Il loro raffinamento – ancora prima di stilare il documento di requisiti funzionali e i documenti di disegno – può, concordato all’interno del Team di Progetto, produrre una lista di dettaglio dei requisiti. Pertanto l’entità è data dal numero di requisiti utente di dettaglio da sviluppare nel seguito del progetto. 

·        Livello di complessità delle entità considerate. Una volta determinata l’entità da misurare, il passo successivo è dato dalla ponderazione del livello di complessità da attribuire alle varie istanze dell’entità considerata. Uno dei punti di maggior dibattito per i metodi di misurazione funzionale è dato per l’appunto dalla ponderazione delle entità misurate e dalla maniera di effettuarla. Il risultato ad oggi è che anche nel recepimento dei Function Points e misure similari si considera il fattore di aggiustamento come opzionale, considerando quindi principalmente la misura “unadjusted” in quanto derivata oggettivamente con riferimento allo sviluppo delle attività tecniche, primo obiettivo di Albrecht. Nel nostro caso, avendo scelto di misurare non un elemento di dettaglio quale un input o un file ma un’entità di livello più alto, il requisito da cui tali elementi saranno derivati, non è possibile prescindere da una loro ponderazione. Come può pesarsi un requisito, date queste premesse?

L’obiettivo finale per cui si intende calcolare il size di un progetto è la stima dell’effort necessario per produrlo. Pertanto il passaggio successivo per un Project Manager, qualora sapesse di non dover necessariamente calcolare un size (vedi primo criterio indicato nel PMBOK), sarebbe quello di abbozzare un Gantt semplicemente elencando le attività di dettaglio ed attribuendo una durata di massima alle singole attività. Volendo creare una uniformità nello “scrivere” e stimare i progetti, sarà quindi necessario determinare una scale temporale (statisticamente determinata) per parametrare i task al tempo necessario per essere eseguiti, ovverosia all’effort:

1 Req.Utente ® x Req.Utente di dettaglio ® y task ® z giorni/uomo

Considerando tre livelli di complessità (alta, media, bassa) dall’analisi dei dati storici di progetto e osservando il livello di granularità dei task inseriti nei Gantt, si è assegnata una corrispondenza temporale univoca per ciascun requisito utente di dettaglio rispetto al numero di task che ne derivano (agganciato ad un effort standard in giorni/uomo). Supponendo che da un UR di dettaglio derivino 2 attività da inserire sul Gantt, ciascuna delle quali per convenzione non pesi più di 5 giorni/uomo (totale: 10 gg/uu), si attribuisce complessità complessità “bassa” e via via verso la definizione di complessità “alta”.

La discussione all’interno del Team di Progetto sul numero di task in cui dettagliare l’UR di dettaglio ha chiaramente influenza sul numero finale di PSU “unadjusted” calcolate. È chiaro che un UR con 1 task di complessità alta pesi meno di un UR con un certo numero di task di complessità bassa. Pertanto l’indicazione derivata statisticamente sul numero massimo di giorni/uomo per ogni livello di complessità ha lo scopo ultimo di uniformare la modalità di espressione del progetto. Difatti, comparando diversi Gantt di progetto, a prescindere dal numero di giorni/uomo conclusivo, oltre che nella dialettica con il Cliente, vedere una sola voce “Analisi” per un totale di 40 gg/uomo piuttosto che non un dettaglio puntuale per ciascun UR concordato, permette anche di “leggere” a posteriori se le attribuzioni effettuate siano state reali, sopra o sottostimate. Non avendo una comparabilità “visuale” tra progetti simili, la stima rimane un’attività totalmente nelle mani e nell’esperienza del PM, assolutamente agganciata ad un fattore per nulla oggettivo.

Sicuramente a questo punto sorge naturale una domanda: perchè non calcolare direttamente l’effort senza conteggiare null’altro? Sembrerebbe che, come dice l’adagio, sia “il serpente che si morde la coda”: ipotizzare un effort (quello per l’effort medio per task) per stimarne un altro (quello complessivo di progetto, per aggregazione). La risposta, pur apparendo banale, trova fondamento nella prima formula esposta: l’effort è funzione della dimensione di un progetto, che è esprimibile fondamentalmente dal numero di “cose da fare”. Raffinando il concetto (ad un livello che potremmo denominare L-2), le “cose da fare” prendono il nome nella FPA di dati e transazioni, classificati nelle cinque entità ben conosciute (ILF, EIF, EI, EO, EQ). Ad un livello leggermente più alto (livello L-1), dove non è ancora possibile conteggiare tali entità di dettaglio, rimane il “cosa fare” ed il conteggio – necessario – si può agganciare esclusivamente al numero di “cose da fare”. La ponderazione, legata chiaramente all’effort richiesto, può quindi avvenire solo in funzione del “numero di cose da fare (task)”.

I due risultati di questa fase saranno pertanto:

a)      il numero di task associati ad ogni UR di dettaglio, conteggiati sulla base di una tabella che associa il numero di gg/uomo da spendere mediamente per un’attività considerata di complessità alta o media o bassa (che si risolve quindi nell’applicazione diretta della produttività media di cui sopra);

b)      il peso – statisticamente determinato dall’analisi periodica del database storico dei dati di progetto – associato a ciascuno dei livelli di complessità determinati.

Il prodotto tra il numero di entità (UR di dettaglio) per i pesi dei tre livelli di complessità restituisce quindi il PSU unadjusted, primo valore determinato.

·        Fattore di aggiustamento generale. La quantità sopra determinata (PSU unadjusted) si riferisce esclusivamente allo sforzo di natura tecnica da produrre per il progetto. Rimangono ancora esclusi gli effort per i task di natura qualitativa così come quelli gestionali puri. Tale effort, rispetto a quelle che SPICE o ISO/IEC 12207 chiamano processi primari, sarà proporzionale all’ammontare di tali attività tecniche. Anche in questo caso è possibile dal database dei dati di progetto ricavare quali, storicamente, siano stati i valori medi con riferimento alla quantità di attività tecniche stimata, ovverosia ai PSU unadjusted sopra calcolati. Pertanto periodicamente si revisiona una tabella che relaziona il numero di PSU unadjusted all’effort gestionale-qualitativo da aggiungere in proporzione. Come indicato dalla quarta voce del PMBOK (contingency o buffer), il fattore di aggiustamento inteso come rischio da considerare rispetto la nuda stima tecnica è incluso implicitamente qui dentro e ricavato dallo storico degli effort consolidati per i progetti già conclusi. 

Pertanto il risultato di questa fase è la determinazione di una tabella, riportante le proporzioni di effort aggiuntivo per il lavoro gestionale e qualitativo sul totale dei PSU unadjusted.

Il prodotto tra i PSU unadjusted e il fattore di aggiustamento restituisce infine il numero finale di PSU per il progetto. Si riporta nella seguente tabella la comparazione tra agli elementi base nella formula di conteggio del size per FPA e PSU.

Metodo \ Elementi	Entità	Complessità	Fattore di Aggiust.	Complessità
FPA (standard)	Dati (ILF, EIF) e Transazioni (EI, EO, EQ) relativi ai requisiti funzionali di un sistema software	3 livelli (A/M/B) per ciascuna tipologia di entità	14 caratteristiche generali di sistema (GSC)	Peso (0-5) per ciascuna delle 14 GSC, con un ±35% sul valore di FP unadjusted
PSU (anticipato)	UR funzionali di dettaglio e task derivati (regola: 1 task = max x gg/uomo) per le fasi tecniche del SLC	3 livelli (A/M/B) per ciascun UR di dettaglio rispetto al n. di task di dettaglio per UR (e quindi di gg/uomo, statisticamente determinati)	Ponderazione % per valutare l’ammontare di effort richiesto in proporzione per i task di tipo qualitativo e gestionale.	Tale percentuale è derivata dall’analisi del db storico dei dati di progetto, ed è proporzionale al numero di PSU unadjusted.

Conclusioni e Prospettive

Non esistono verità, solo punti di vista. Come per tutte le scelte da effettuare, esisterà un punto di trade-off, sopra o sotto il quale converrà maggiormente l’adozione di una tecnica di stima anticipata o standard. Il problema di valutare l’opportunità nell’adozione di una tecnica di stima anticipata deriva esclusivamente dal momento in cui tale informazione deve essere resa disponibile, non sempre coincidente con il termine della fase di Disegno.

La logica della misurazione funzionale, espressa nei metodi FSM (Functional Size Measurement) quali la FPA rappresentano sicuramente il “verso dove” proseguire il cammino. Recuperando tale logica, pensare un sistema di stima anticipato come PSU comporta minori costi ma una ridotta affidabilità del sistema previsionale collegato alla stima del size del progetto. La correlazione dei risultati di stima prodotti sia con un sistema standard che anticipato sicuramente produce valori idonei a valutare tale trade-off.

La tecnica PSU, creata da L. Buglione nell’estate del 2003 ed applicata in SchlumbergerSema , attualmente in corso di validazione interna, si applica per effettuare stime sui futuri progetti di sviluppo tentando di ottimizzare l’effort per dimensionare un progetto e minimizzare il margine di errore nella stima. Appena disponibili, i risultati per validare statisticamente la tecnica saranno pubblicati.

Appendice A: Metodi di stima “anticipati” e “standard” del size

	Metodi Anticipati (PSU)	Metodi Standard (FPA)
Fase SLC applicazione	Pianificazione (livello L-1)	Disegno (livello L-2)
Livello di accuratezza	Minore dei metodi standard (media)	Maggiore dei metodi anticipati (media)
Parametri controllo per accuratezza stime	In entrambi i casi, andranno confrontati MRE e Pred(0.25) di progetto sull’effort stimato attraverso il size e consuntivato al termine del progetto e il MMRE e il Pred(0.25) sull’intero set di progetti inclusi nel database storico utilizzato per il sistema previsionale
Livello informativo necessario	Documentazione dalla fase di Bid	Documentazione della fase di Analisi
Skill richiesti per stima	Project team	Contatore Function Points (preferibilmente certificato, CFPS)
Tempo richiesto per stima	0.5 m/d (per conteggi PSU)	1.5-2 m/d (per conteggi FPA)
Vantaggi	·                   Rapidità nel calcolo ·                   non richiesta conoscenza FPA ·   stima del progetto effettuabile prima di iniziare l’Analisi & Disegno	·  Maggior accuratezza nel calcolo del size da usare per la stima ·  Comparabilità esterna dei risultati
Svantaggi	·  Minor accuratezza nel calcolo del size da usare per la stima, verifica livello di correlazione con la tecnica “standard” ·  Comparabilità interna dei risultati	·  Maggior lavoro per derivare il numero di FPs ·  Richiesta conoscenza FPA ·  stima del progetto effettuabile prima di iniziare la fase di Costruzione (codifica)
Annotazioni	Sperimentale ed interna, in corso di validazione.	Consolidata e diffusa, con regole di conteggio in costante monitoraggio da parte di organi internazionali

 

Bibliografia

[ALBR79]	Albrecht A.J., Measuring Application Development Productivity, Proceedings of the IBM Applications Development Symposium, GUIDE/SHARE, October 14-17, 1979, Monterey, CA, pp. 83-92
[ALBR84]	Albrecht A.J., AD/M Productivity Measurement and Estimate Validation, IBM Corp., NY, 1984
[BOEH81]	Boehm B., Software Engineering Economics, Englewood Cliffs N.J., Prentice-Hall Inc., 1981, ISBN 0138221227
[BOEH00]	Boehm B.W., Horowitz E., Madachy R., Reifer D., Clark B.K., Steece B., Brown A.W., Chulani S & Abts C., Software Cost Estimation with COCOMOII, Prentice Hall, 2000, ISBN 0130266922
[BUGL03a]	Buglione L., Misurare il Software. Quantità, qualità, standard e miglioramento di processo nell’ICT, 2° edizione, FrancoAngeli, FA724.20, ISBN 88-464-4634-8, Maggio 2003, URL: http://www.geocities.com/lbu_measure/libri/mis.htm
[BUGL03b]	Buglione L., Project Size and Effort Estimation, SchlumbergerSema, Internal Document, September 2003
[CONT86]	Conte S., Dunsmore H. & Shen V.Y., Software Engineering Metrics and Models, Benjamin Cummings: Manlo Park, CA, 1986, ASIN 0805321624
[IFPU00]	IFPUG, Function Points Counting Practices Manual (release 4.1.1), International Function Point User Group, Westerville, Ohio, April 2000, URL: http://www.ifpug.org
[ISO95]	ISO/IEC JTC1/SC7/WG7 N72, International Standard 12207 - Information Technology : Software Life Cycle Processes, 22/02/95, URL: http://www.iso.ch
[ISO98]	ISO/IEC JTC1/SC7/WG10, TR 15504-5, Software Process Assessment - Part 5: An Assessment Model and indicators guidance, v.3.03, 1998
[JONE96]	Jones C., Applied Software Measurement: assuring productivity and quality, 2/e, McGraw-Hill, 1996, ISBN 0070328269
[JONE97]	Jones C., What are Function Points?, Software Productivity Research Inc., 1997, URL: http://www.spr.com/library/0functmet.htm
[MELI97]	Meli R., Punti Funzione Anticipati: un nuovo metodo di stima per i progetti software, Proceedings of the 8th ESCOM Conference, Berlin, May  26-28, 1997, URL: http://www.dpo.it
[PAUL93]	Paulk M.C., Weber C.V., Garcia S.M.,  Chrissis M.B. & Bush M., Key Practices of the Capability Maturity Model Version 1.1, Software Engineering Institute/Carnegie Mellon University, CMU/SEI-93-TR-25, February 1993, URL: http://www.sei.cmu.edu/cmms/
[PMI00]	PMI, A Guide to the Project Management Body of Knowledge (PMBOK), 2000 Edition, Project Management Institute,  ISBN 1-880410-23-0, 2000, URL: http://www.pmi.org