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

<<simple>>

,

<<medium>>

,

<<complex>>

. Nel nostro esempio abbiamo salomonicamente tre casi d'uso per tipo: il risultato sarà quindi quello di figura 6.

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 <<simple>>, <<medium>>, <<complex>>. Nel nostro esempio abbiamo salomonicamente tre casi d'uso per tipo: il risultato sarà quindi quello di figura 6. TCF = 0,6 + (0,01 * TFactor)

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

AUCP = UUCP TCF ECF

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

Total effort = PF * AUCP

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

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.