Stimare la dimensione di un progetto è un‘attività complessa, spesso non affrontata con la dovuta scientificità. Il meccanismo di stima con la tecnica degli Use Case Points è un modo semplice e pratico per ottenere delle stime sufficientemente accurate in tempi ragionevoli, integrandosi facilmente nei processi di sviluppo iterativi.

La capacità  di prevedere il futuro ha sempre affascinato gli esseri umani. Alcuni di essi, nel corso dei secoli, hanno sviluppato diverse tecniche per poter dare una risposta ai dubbi ed alle angosce che qualsiasi impresa portava con sà©. Gli antichi Etruschi leggevano il futuro nel fegato degli animali sacrificati, attraverso la tecnica dell‘aruspicina. I Greci interrogavano gli oracoli prima di entrare in guerra. I pellerossa sfruttavano il peyote per indurre visioni nei loro sciamani.
Nel mondo del software, la cerimonia si ripete ogni qual volta ci si trova all‘inizio di un nuovo progetto e viene posta la fatidica domanda: “Quanto tempo ci vuole per svilupparlo?”. Generalmente questa domanda non viene rivolta ad una persona in particolare, tra i presenti, un po‘ come il “Chi di voi sa dirmi…” di certe domande bastarde dei professori del liceo, cercando di aumentare la suspence. Le reazioni tipiche appartengono generalmente a 2 categorie: chi sviluppa tende ad affrontare il problema alla radice applicando tecniche già  collaudate:

• Fingersi morto.
• Millantare un impegno urgente.
• Fissare un punto lontano ignorando le persone circostanti.
• Cercare di uccidere un piccione a mani nude per leggerne il fegato.

Nel frattempo, gli appartenenti alla seconda categoria se ne saranno usciti con una cifra a caso, ovviamente molto inferiore alla cifra che vi poteva sembrare ragionevole (tanto loro non sviluppano). In quel momento, chi sviluppa si rende conto della trappola e cerca di obiettare. Ma come sempre troppo tardi, la frittata è ormai fatta, e prima ancora di partire, il progetto è già  in ritardo…

Il punto di partenza

Stimare il costo di realizzazione di un progetto software è un problema complesso. Si tratta di un‘attività  immateriale ed ad alto tasso di incertezza. La determinazione di un ordine di grandezza, associato ad un progetto (sia pure accompagnato da un ingegneristico margine di errore) è comunque un‘attività  fondamentale per la gestione dei rischi associati allo sviluppo di software. Nel corso degli anni sono state sviluppate varie tecniche, con l‘obiettivo di ottenere una valutazione sufficientemente precisa di questo valore, tra le più note possiamo citare la Constructive Cost Model (meglio nota come CoCoMo [1]) e la Function Points Analysis (FPA) [2]. La diffusione dei casi d‘uso come strumento per la definizione del comportamento complessivo di un‘applicazione ha portato a una sintesi tra il meccanismo dei Function Points e la scomposizione dell‘applicazione in casi d‘uso in una tecnica denominata Use Case Points [3], il cui obiettivo è appunto quello di fornire una stima sufficientemente precisa dell‘effort complessivo necessario al completamento di un progetto, a partire dai casi d‘uso. Tale tecnica ha il vantaggio di adattarsi perfettamente ai processi di sviluppo basati sui casi d‘uso (il più noto è il Rational Unified Process [4], ma il concetto di caso d‘uso si è dimostrato valido anche in altri processi) senza la necessità  di decomporre l‘applicazione secondo tecniche specifiche relative al processo di stima, rendendo decisamente più agevole la produzione di una stima complessiva sulla base di criteri sufficientemente oggettivi.

Il modello di stima

L‘obiettivo che ci poniamo è quello di ottenere un valore sufficientemente accurato dell‘effort necessario al completamento del progetto. Questo valore sarà  ottenuto prendendo in esame parametri quantitativi (quanto è “grande” l‘applicazione: quante funzionalità  e quanti punti di contatto con l‘esterno espone) e da parametri qualitativi che saranno in varia misura dipendenti dal progetto, dalla tecnologia, ma anche dall‘organizzazione e dall‘esperienza.
Il risultato complessivo, da cui poter ricavare un valore corrispondente alle ore-uomo necessari a completare la nostra applicazione sarà  il risultato di una moltiplicazione:

UCP = UUCP * TCF * ECF * PF

all‘interno della quale compaiono il valori chiave del nostro metodo, che illustriamo brevemente:

• Use Case Points (UCP): il risultato del nostro processo di stima.
• Unadjusted Use Case Points (UUCP): il valore quantitativo grezzo relativo alle funzionalità  che devono essere esposte dall‘applicazione.
• Technical Complexity Factor (TCF): una misura della complessità  tecnologica dell‘applicazione da realizzare.
• Environmental Complexity Factor (ECF): una misura della complessità  legata al contesto in cui l‘applicazione viene sviluppata.
• Productivity Factor (PF): coefficiente che permette la conversione da generici Use Case Points a ore uomo.

Analisi quantitativa

Il primo elemento da considerare è un‘approssimazione del numero di funzionalità  che saranno esposte dalla nostra applicazione. In questa fase del processo di sviluppo abbiamo a disposizione un primo elemento che ci permette di definire una stima: l‘elenco dei casi d‘uso. In un progetto di piccole dimensioni questo si presenterà  probabilmente nella forma di uno Use Case Diagram. In progetti più complessi, questi saranno organizzati in packages e probabilmente gestiti in un elenco con uno strumento specifico. Anche in questo caso lo Use Case Diagram ci tornerà  utile per l‘individuazione e la categorizzazione degli attori coinvolti.
Supponiamo di poter disporre di un sistema modellabile come nello Use Case Diagram in figura 1

Figura 1 – Diagramma dei casi d‘uso del sistema d‘esempio

Il valore degli Unadjusted Use Case Points sarà  calcolato come:

UUCP = UAW + UUCW

Dove i parametri sono:

• Unadjusted Actor Weight (UAW): il peso dei diversi attori che andranno ad interagire con il nostro sistema.
• Unadjusted Use Case Weight (UUCW): il peso complessivo dei casi d‘uso che compongono il nostro sistema.

Classificazione degli attori

Nella modellazione con i casi d‘uso [5], gli attori rappresentano le diverse categorie di utenti che utilizzano il nostro sistema. Questi possono essere utenti in carne e ossa, oppure sistemi esterni. Il numero e il tipo di punti di contatto con l‘esterno della nostra applicazione influenza il tempo necessario a realizzarla. Il metodo di calcolo per l‘UAW prevede una somma del numero di attori, corretta da un fattore di complessità  associato al tipo di ogni singolo attore.

Figura 2- Tabella con il peso degli attori

La spiegazione della classificazione è evidente: il tempo speso ad effettuare un‘interfaccia “ricca” è maggiore di quello di un‘interfaccia di basso livello. Strumenti di progettazione visuale non possono nascondere il fatto che un utente in carne ed ossa ci chiederà  di modificare le schermate con frequenza molto maggiore di quanto non lo faccia un sistema che accede mediante un web service od un API.
Il valore dell‘Unadjusted Actor Weight sarà  quindi ottenuto come somma pesata del numero degli attori moltiplicato per il peso associato alla loro complessità , come evidente dalla tabella in figura 3

Figura 3 – Tabella UAW

Classificazione dei casi d‘uso

Analogamente, l‘Unadjusted Use Case Weight sarà  calcolato come somma pesata dei casi d‘uso associati ad un parametro che ne determini il peso, secondo lo schema riportato in tabella.

Figura 4 – Tabella con il peso per categorie di caso d‘uso

Ritornando al nostro diagramma, cerchiamo di evidenziare in qualche modo la classificazione dei casi d‘uso (figura 5):

Figura 5 – Diagramma con la classificazione dei casi d‘uso

In questo caso abbiamo utilizzato una classificazione basata sui colori. Un‘alternativa meno efficace sul web, ma più comoda dovendo stampare in bianco e nero è l‘uso degli stereotipi UML, come ad esempio <>, <>, <>. Nel nostro esempio abbiamo salomonicamente tre casi d‘uso per tipo: il risultato sarà  quindi quello di figura 6.

Figura 6 – Tabella UUCW + UUCP

In letteratura troviamo riportati criteri leggermente diversi per la classificazione dei casi d‘uso: numero di entità  o classi coinvolte, step del processo di implementazione. Non dobbiamo però dimenticare il nostro obiettivo principale: ottenere una stima della dimensione complessiva del progetto, il prima possibile. Ciò significa che non possiamo permetterci di analizzare tutti i casi d‘uso, perché il tempo speso ad analizzarli potrebbe già  essere out-of-scope. Tuttavia, nel momento in cui abbiamo raggiunto una definizione di quali siano i casi d‘uso della nostra applicazione, generalmente abbiamo già  la percezione della loro complessità  in termini di possibili scenari e del numero delle entità  coinvolte. Altre informazioni, quali il numero di tabelle o di classi coinvolte, in molti casi non sono disponibili, in quanto risultato di una fase di design a cui non siamo ancora arrivati. Detto in altri termini è preferibile lavorare in modalità  “egg-today”, non dimenticando che le informazioni raccolte nelle prime fasi di progetto potranno essere raffinate successivamente, al crescere delle informazioni in nostro possesso, raffinando il risultato delle nostre stime.

Complessità  tecnologica

Come ben sappiamo, la tecnologia adottata concorre pesantemente a determinare il tempo necessario a costruire una data applicazione. Tuttavia determinati vincoli architetturali ci portano a dover scegliere una strada anzichà© un‘altra. Il metodo UCP considera 13 diversi fattori tecnologici che concorrono a modificare il costo complessivo del progetto. Anche in questo caso abbiamo a che fare con un sistema di pesi che determina l‘importanza di singoli fattori.

Figura 7 – Tabella con il peso dei fattori tecnologici

Il nostro compito è di assegnare a ciascuno di questi parametri un valore da 0 a 5 che corrisponde alla complessità  percepita dello specifico fattore all‘interno del nostro progetto. L‘effetto combinato dei diversi fattori produrrà  il Technical Complexity Factor, come risultato della formula:

Dove Wi rappresenta il peso dello specifico fattore e Ti il valore associato. Più praticamente, se definiamo TFactor la somma di tutti i fattori moltiplicati per il corrispettivo peso, la formula di calcolo diventa:

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

Nella tabella di figura 8 vediamo un esempio del calcolo del TCF applicato al nostro progetto.

Figura 8 – Tabella con il calcolo del fattore di complessità  tecnica (TCF)

Valutazione della complessità  ambientale

Arriviamo quindi all‘elemento più critico del modello di stima: la valutazione dei cosiddetti “fattori ambientali”. Il procedimento è simile a quello appena utilizzato per la definizione del TCF. In questo caso però i fattori di cui tenere conto sono solamente 8.

Figura 9 – Tabella con il peso dei fattori ambientali

Notiamo come gli ultimi due parametri abbiano un coefficiente negativo, e anche quanto il parametro E6, la stabilità  dei requisiti, “la faccia da padrone” dal punto di vista del peso specifico associato al singolo fattore. Il calcolo dell‘Environmental Complexity Factor è ottenuto con una formula simile alla precedente, ma con diversi coefficienti:

Analogamente al caso precedente, Wj rappresenta il peso associato allo specifico fattore ed Ej il valore da noi associato. Più semplicemente, se consideriamo Efactor la somma di tutti i fattori moltiplicati per il loro peso, la formula si può esprimere come:

ECF = 1,4 + (- 0,03 * Efactor)

Come risulta più chiaro dalla tabella in figura 10.

Figura 10 – Tabella con il calcolo del fattore ambientale (EF)

Dai punti ai giorni-uomo

Il tassello mancante a questo punto è semplicemente l‘individuazione del coefficiente che permette di convertire il valore “aggiustato” degli use case points (Adjusted Use Case Points), ossia:

AUCP = UUCP * TCF * ECF

Nel nostro esempio abbiamo quindi:

AUCP = 99 * 0,83 * 0,98 = 80,5266

Il valore complessivo dell‘effort sarà  quindi calcolato come:

Total effort = PF * AUCP

Il fattore di produttività  rappresenta il rapporto tra Use Case Points (AUCP) e le ore uomo necessarie al completamento del progetto. Come ottenere questo valore? La letteratura è abbastanza chiara al riguardo: “dall‘analisi retrospettiva dei progetti passati” ovvero dividendo l‘effort misurato dei progetti già  fatti, per il corrispondente valore di AUCP calcolato per quel progetto. Hmmm… e se non avessimo a disposizione questi dati? Il valore proposto come punto di partenza è 20. Questo ci porta a dire che il nostro progetto richiederà :

Total Effort (ore uomo) = 20 * 80,5266 = 1610,532

all‘incirca 1610 ore uomo, ossia (è fondamentale non barare a questo punto…) poco più di 201 giorni uomo. Wow.

La soglia di Schneider

Apparentemente siamo giunti al termine. Tuttavia Schneider e Winters [4] propongono una modifica al modello che tenga conto dell‘effetto combinato dei fattori ambientali. In pratica, se 3 dei parametri ambientali risultano avere un valore critico (minore o uguale a 2 per E1..E6, maggiore o uguale a 3 per E7, E8) l‘effetto combinato di tre o più criticità  ambientali non è più lineare, ma è presagio di sciagure (il fegato del piccione lo conferma). Tale aumentato rischio si riflette in un diverso valore da attribuire al coefficiente PF, che varrà  28 rispetto al valore 20 citato poc‘anzi; quindi il 40% in più rispetto al valore originario. L‘effetto del superamento della cosiddetta “soglia di Schneider” è abbastanza dirompente in quanto il 40% si riflette direttamente in un aumento del 40% dell‘effort complessivo, ma riflette in maniera sostanzialmente corretta l‘”effetto valanga” che si verifica quando più parametri chiave del progetto sono fuori controllo.
Nell‘esempio precedente, i fattori ambientali in zona critica erano solamente E2 ed E5, per cui la soglia di Schneider non si applica. Un peggioramento di un altro fattore ambientale avrebbe portato ad un mutamento “pesante” della stima complessiva portando a superare le 280 giornate.

Avvertenze

In letteratura, e in rete, sono presenti versioni lievemente differenti dello stesso metodo di calcolo, con applicazione di coefficienti che rendono la scelta di una variante del metodo di calcolo anzichà© di un‘altra tutto sommato trascurabili. Considerando che il metodo trae la propria efficacia dall‘applicazione sistematica a più progetti, che portano ad un raffinamento dei coefficienti ambientali tipici, tendenzialmente ogni meccanismo di calcolo che dia garanzie di ripetibilità  è già  sufficientemente buono. In altre parole, scegliete una versione di riferimento ed insistete con quella. La versione cui facciamo riferimento in questo articolo è l‘evoluzione, documentata da Scheider e Winters [4] della proposta originale di Karner [3].

Conclusioni

Il meccanismo di stima qui presentato presenta alcune caratteristiche decisamente interessanti. In primo luogo calza come un guanto su un processo di sviluppo basato sulla scomposizione in casi d‘uso, permettendo di avere una prima definizione dell‘ordine di grandezza del progetto con un set limitato di informazioni. Essendo basato su considerazioni “aritmetiche” è meno legato ad uno specifico “esperto” e più a valutazioni oggettive legate alle caratteristiche del progetto, al linguaggio, al contesto, etc. Trattandosi di una operazione di “calcolo” basata su parametri che spesso risultano ripetibili da progetto a progetto (specialmente per quanto riguarda i fattori ambientali o tecnologici), l‘applicazione del modello di stima può essere fatta in maniera sufficientemente rapida e sistematica.
In letteratura il modello è presentato come statisticamente in grado di fornire una previsione accurata al 20% del costo complessivo del progetto, statisticamente comparabile se non migliore al margine di errore medio del “parere dell‘esperto”. Con un po‘ di esperienza e l‘applicazione sistematica del procedimento siamo riusciti ad avere stime ancora più precise di questo valore. Nel prossimo articolo vedremo quali accorgimenti utilizzare al momento di passare dalla teoria alla pratica.

Riferimenti

[1] Boehm B. “Software Cost Estimation with COCOMO II”, Addison Wesley, 2000

[2] Karner G. “Resource Estimation for Objectory Projects”, Objective Systems SF AB, 1993

[3] RUP

[4] Cockburn A.,”Writing Effective Use Cases”, Addison-Wesley, 2001

[5] Schneider G. – Winters J., “Applying Use Cases. A Practical Guide”, Addison Wesley Longman, Inc., 1998

[6] McConnell S., “Software Estimation. Demystifying the black art”, Microsoft Press, 2006

[7] Anda B., “Improving Estimation Practices by Applying Use Case Models”, 2003
http://www.cognizant.com/cogcommunity/presentations/

[8] Cohn M., “Agile Estimating and Planning”, Addison-Wesley, 2005

[9] Ortolani L., “Rat-Man”, Marvel Italia