Una delle ragioni che rendono così interessanti i casi d‘uso come meccanismo di raccolta dei requisiti è che permettono di definire l‘intera applicazione da sviluppare come somma dei suoi casi d‘uso. In questo articolo concludiamo il discorso sui casi d‘uso come metodo di stima dei progetti software.

Nell’articolo precedente abbiamo illustrato il funzionamento della tecnica degli Use Case Points per la stima dei progetti software. Abbiamo anche fatto riferimento all’antica arte etrusca dell’aruspicina, in cui si prevedeva il futuro esaminando il fegato di animali sacrificati…
Non sono mancate le sorprese e i contrattempi. Oltre ad una protesta formale da parte della LIPU che denunciava sospette stragi di piccioni nelle prossimità di alcune software house, sono giunte anche alcune reprimende da parte dei lettori che denunciavano la scarsa leggibilità delle interiora dei pennuti. Il piccione è tradizionalmente meno affidabile della rondine (statisticamente il margine di errore è del 18% rispetto al 6-7% di una rondine europea, ed al 5% di una rondine africana [1]). Le statistiche però sono viziate dall’incidenza dell’inquinamento metropolitano: studi recenti mettono in luce quanto lo smog stia severamente deteriorando l’attendibilità dell’aruspicina.

Cosa stiamo stimando?

La definizione che abbiamo dato nel precedente articolo può essere per certi versi un po’ oscura: cerchiamo di chiarirla meglio. Il risultato del processo di stima è una cifra che rappresenta l’effort complessivo associato al progetto; in assenza di “artifici contabili” questo rappresenta la somma delle ore consuntivate da tutti i partecipanti al progetto sotto la voce “progetto”, quindi includendo analisi, design, implementazione, test, documentazione, gestione del progetto, rilasci etc.
In altre parole stiamo stimando un costo, non un tempo. Non c’è una relazione “diretta” tra il valore ricavato dal meccanismo di stima e una potenziale data di consegna. La data di consegna è dipendente dal processo di sviluppo utilizzato (quante iterazioni e quanto frequenti) ma non coincide con la fine del progetto. I veri problemi in genere iniziano dopo la consegna. Nel calcolo figureranno anche le giornate di manutenzione spese a risolverli.

Perche‘ i casi d’uso?

Una delle ragioni che rendono così interessanti i casi d’uso come meccanismo di raccolta dei requisiti è che permettono di definire il sistema, ovvero l’intera applicazione da sviluppare come somma dei suoi casi d’uso. Sembra banale, ma non è un risultato di così poco conto: stiamo dicendo che l’intero sistema è formato solo dalla somma dei casi d’uso. In altre parole non esiste alcun comportamento del sistema che non sia descritto da un caso d’uso. Se abbiamo implementato tutti i casi d’uso, abbiamo implementato l’intero sistema. Fine. Tutti a casa. Spegnete la luce.
Questa corrispondenza fra il tutto e le sue parti è una proprietà non secondaria dell’analisi basata sui casi d’uso e permette di limitare le sorprese: se posso scomporre l’intero progetto in parti più piccole, e posso misurare queste con un sufficiente grado di approssimazione, è ragionevole supporre che la stima che ne deriva sia sufficientemente accurata. Anche altre tecniche di scomposizione agili basate su Features, o User Stories hanno la stessa proprietà.

Dal diagramma dei casi d’uso alla stima

Nell’articolo precedente abbiamo preso in esame un generico diagramma dei casi d’uso, e abbiamo utilizzato le informazioni presenti sul diagramma per ricavare gli argomenti numerici del nostro procedimento di calcolo. Tuttavia, a partire dalla stessa applicazione obiettivo, è possibile ricavare Use Case Diagram piuttosto diversi tra loro, in maniera legata al particolare “stile” dell’analista. Tali diversità possono influenzare il modello di stima: è bene quindi adottare una serie di comportamenti ripetibili, per minimizzare l’effetto perturbante degli “stili”.

Conteggio degli attori

Della separazione di tipo tecnologico fra gli attori, che porta a una diversa attribuzione del peso ai diversi attori, abbiamo già parlato nel precedente articolo [6]. Tuttavia, qualche dubbio sulla corretta modalità di conteggio potrebbe nascere nel caso fossero presenti relazioni di generalizzazione fra attori. In questo caso abbiamo qualche elemento di arbitrarietà nella suddivisione (“conteggiamo tutti gli attori o solo le categorie principali?”), da gestire con il classico buon senso: nel corso di un progetto il costo di un attore è principalmente legato alla gestione del canale di comunicazione con lo specifico domain expert. Se la classificazione degli attori non riflette un’effettiva differenziazione dei ruoli o delle interfacce di comunicazione, ma è semplicemente il risultato di una schematizzazione (e quindi alla fine parlo sempre e solo con la stessa persona), può non avere senso contare “tutti” gli attori evidenziati, ma solo le categorie principali.

Nell’esempio in Figura 2, possiamo pensare di considerare i due attori separatamente, se abbiamo diversi domain expert o rappresentanti di riferimento. Come uno solo, se si tratta semplicemente di una classificazione allo scopo di raggruppare le voci dei menu.
In generale, il conteggio degli attori impatta solo in minima parte sul risultato complessivo, specialmente nel caso di sistemi complessi, per cui una valutazione “ad istinto” può dirsi corretta nel 90% dei casi.

Conteggio dei casi d’uso

Diverso è il caso del conteggio dei casi d’uso. Abbiamo disegnato il nostro bel diagramma, e ci siamo scatenati con le relazioni di generalizzazione, inclusione ed estensione. E ora? Probabilmente era il caso di aspettare un attimo a effettuare le scomposizioni e le riorganizzazioni dei casi d’uso. Dal punto di vista della stima ci rifacciamo alla definizione “canonica” del caso d’uso:

“Un caso d’uso rappresenta una interazione tra un utente ed il sistema per il raggiungimento di un risultato”

Il processo di scomposizione arriva successivamente; in effetti si tratta già di un’attività di design del sistema, e porta con se‘ una buona dose di arbitrarietà che in questo contesto è decisamente nociva. Particolarmente pericolosa è la relazione di inclusione che può essere applicata ricorsivamente, scomponendo un caso d’uso in pezzi man mano più piccoli. In generale, il diverso modo di intendere le relazioni di inclusione, generalizzazione ed estensione rappresenta in qualche modo la “firma” dell’analista, ed è legata più all’esperienza, o – se vogliamo – allo stile dell’analista.
Per compensare questa arbitrarietà è necessario comportarsi con coerenza e uniformità, applicando qualche accorgimento che minimizzi gli effetti delle differenti scelte di modellazione:

1. Ignoriamo i casi d’uso inclusi. La relazione di inclusione serve ad individuare porzioni comuni tra più casi d’uso, e quindi le eventuali dipendenze. In certi casi la porzione comune è piccola, tale da poter essere classificata come sub-function [2], e in ogni caso non rilevante rispetto alla dimensione complessiva del progetto.
2. Consideriamo solo i casi d’uso in relazione diretta con gli attori. È un altro modo per esprimere l’affermazione precedente (ma che compensa le diversità di stile degli analisti). Se un caso d’uso è un interazione tra l’utente e il sistema, un caso d’uso che non è in relazione con l’utente non è un caso d’uso, quindi non lo consideriamo ai fini del conteggio.
3. Manteniamo solo le relazioni di generalizzazione o estensione effettivamente significative. In questo caso le diverse strategie di modellazione tenderebbero a compensarsi: un caso d’uso complesso può essere scomposto in 2 o più casi d’uso di peso minore, e il risultato macroscopicamente non varia. Spesso però, la presenza di molte generalizzazioni è indice di un possibile eccesso di modellazione sullo stesso caso d’uso (p.e.: l’utente B ha la ricerca B che è uguale alla Ricerca A ma con un campo in più che solo B può vedere…) che potrebbe più correttamente essere specificato sullo Use Case Form, senza andare a sovraccaricare di significati il diagramma. Il che ci porta ad affermare che solo le generalizzazioni/estensioni che possono essere realizzate in un secondo tempo rappresentano una vera e propria estensione ai fini della stima (ed anche della modellazione…).

Tornando all’esempio in Figura 2, “Generazione PDF” non sarebbe da conteggiare come caso d’uso, ai fini della stima, mentre “Estratto conto”, “Rendicontazione Movimenti” e “Rendicontazione Movimenti in valuta estera” sì, (assumendo che gli ultimi due possano essere sviluppati in tempi differenti).

Complessità tecnologica

Dal punto di vista della complessità tecnologica, non c’è molto da dire (i termini sono piuttosto auto esplicativi) tuttavia un discorso a parte può essere fatto sui parametri T6 – Easy to Install, e T8 – Portability, che in Java non rappresentano un problema che si scarica direttamente sullo sviluppo ma sono gestite dalla piattaforma: sia pure al prezzo della scrittura dei deployment descriptor, etc.. si tratta sempre del buon vecchio “write once, run anywhere” che mi sembra possa tradursi più o meno “scrivi una volta e scappa dove ti pare” 🙂 In altre parole, salvo casi particolari ha senso considerare questi due valori come costanti e assegnarvi un valore di comodo (io personalmente uso 2 per entrambi).

Fattori ambientali

Entriamo nella zona più critica dal punto di vista delle stime: sia perche‘ i fattori ambientali complessivamente hanno un grande impatto sul risultato complessivo, sia perche‘ la valutazione di questi fattori è in larga parte soggettiva e ha valore di self-assessment. In molti casi, ciò significa dare un giudizio su noi stessi e sul nostro team, e, come se non bastasse, presentarlo al boss. Cerchiamo di approfondire i vari parametri punto per punto.

E1. Familiarità col processo di sviluppo: in quest’area ricade tutta l’esperienza del gruppo nelle attività condivise: design, pianificazione, rilasci, coordinamento del sistema SCM, build, test, etc. In altre parole in questa voce non ricade solo la familiarità con una documentazione standard ma tutte quelle attività che pur non essendo direttamente legate alla scrittura di codice, al termine del progetto hanno fatto perdere un sacco di tempo. Ambienti disallineati, versioni non etichettate, e via dicendo. Considerate questo fattore come una misura del livello di disciplina del gruppo. Un modo per capire “a che punto siamo” è quello di confrontarsi con una checklist come ad esempio quella presentata da Joel Spolsky [3] o quelle presenti in “Software Project Survival Guide” [4] di Steve McConnell.
Un altro elemento che impatta fortemente la familiarità con il processo di sviluppo è il numero di persone coinvolte, che si ripercuote come vedremo anche sul punto E7.

E2. Esperienza del dominio applicativo: in questo caso le considerazioni sono piuttosto ovvie: più ne sappiamo, meno dobbiamo imparare. L’esperienza sarà massima nel caso si debba sviluppare un IDE o un tool di supporto alla programmazione, media nel caso di domini non di uso comune ma relativamente facili. Da considerare anche la difficoltà del reperimento di informazioni riguardo al dominio: a volte possiamo reperire pubblicazioni o informazioni via internet, altre volte siamo vincolati in maniera molto forte all’esperto di dominio.

E3. Esperienza del paradigma adottato: qui c’è un punto dolente legato alla OOP. La maggior parte di noi programmatori si ritiene esperta di OOP, però produce codice zeppo di if, instanceof, metodi di 500 righe e così via. Probabilmente, il metodo migliore per affrontare il punto E3 è darci un voto e poi sottrarre 1 punto da tale valutazione (tranne se il voto è 0, ovviamente).

E4. Capacità dell’analista: altra piccola “rogna”, in mezzo a parametri generici (e quindi un po’ di tutti e un po’ di nessuno) il fattore E4 va “sul personale”. In generale questo è vero anche nel caso di analisi svolta in gruppo in quanto il parametro si riferisce all'”analista capo”. Un modo sufficientemente impersonale per affrontare la questione della valutazione, sulla base delle esperienze passate è “quanto sono utili i deliverables prodotti?” che ci permette di valutare sia l’eccesso di documentazione, sia la carenza e quindi il continuo ricorso alle riunioni, al telefono, alle mail integrative, e così via. Sotto questa voce va considerata anche la possibilità dell’analista di accedere alle informazioni di interesse: disponibilità dei domain expert e così via.

E5. Motivazione del gruppo: come valutarla? Nell’informatica la motivazione può raggiungere dei picchi incredibili: gente che “spontaneamente” lavora 16 ore al giorno, tiene il sacco a pelo in ufficio e non esce finche‘ il rilascio non è andato a buon fine. Ok, quello è il valore 5. Può succedere se lavori a Google su un progetto che cambia il mondo e ti regala delle stock options, o magari in una piccola startup se veramente credi nell’idea che ci sta dietro, ma la maggior parte dei progetti si colloca decisamente più indietro. L’altro problema è che molto di rado il gruppo dichiarerà di essere poco motivato: è pertanto necessario interpretare determinati segnali quali

• L’uso de “la Gazzetta dello Sport” come tappetino per il mouse. Sopra il mouse.
• La frequenza di frasi come “Bastardo, ti ho colpito, tiè!”, durante le fasi di sviluppo.
• La pausa caffè di 45 + 45 minuti con possibilità dell’incubo dei supplementari e della lotteria dei calci di rigore.

E6. Stabilità dei requisiti: è il fattore di maggior impatto. Qualcuno potrà storcere il naso, a questo punto: ormai è assodato che la stabilità dei requisiti è una chimera, tanto è vero che le metodologie agili come XP, Scrum etc. cercano di minimizzare il costo del cambiamento piuttosto che cercare di stabilizzare i requisiti. È però evidente che ri-fare le cose è comunque un costo maggiore rispetto a farle una volta sola. Dal punto di vista delle stime, non dobbiamo però dimenticare che ci troviamo in una fase preliminare del progetto e non siamo in grado di valutare esattamente la quantità dei cambiamenti. Quello che possiamo (e dobbiamo) valutare in questa fase è la possibilità di accedere alle corrette sorgenti di informazioni: abbiamo un vero esperto di dominio? Abbiamo un rappresentante degli utenti? Possono essere considerati affidabili? In altre parole il contesto “politico” in cui il progetto nasce può già presentare delle evidenti criticità, che vanno considerate sotto questo fattore.

E7. Presenza di lavoratori part time: lungi dall’essere un fattore socialmente discriminante, E7 è una misura dell’impatto delle difficoltà di comunicazione legate alla distanza fra i membri del team. Distanza che può essere in termini di tempo, ma anche di spazio, disponibilità etc. Detto in altri termini, è una misura della difficoltà che ha un’informazione nel raggiungere correttamente tutti i destinatari. Gli elementi che concorrono quindi alla determinazione del fattore E7 sono:

• Presenza di lavoratori con orario differenziato (il tempo in cui sono insieme è minore)
• Presenza di lavoratori in altre sedi (la comunicazione avviene attraverso canali meno efficienti del faccia a faccia) [5]
• Presenza di lavoratori interinali, occasionali o di altre aziende (c’è un livello di formalismo in più da considerare su determinate comunicazioni)
• Presenza di gruppi di sviluppo offshore (oltre alla delocalizzazione, aggiungiamo il fuso orario e il problema della lingua)

E8. Difficoltà del linguaggio di programmazione: siamo a metà tra l’ambientale e il tecnologico:, di fatto si tratta di una valutazione di quanto tempo verrà speso imparando conoscenze relative del linguaggio, o dei framework che andremo ad utilizzare. Java in generale si colloca tra i linguaggi difficili, anche per la smisurata quantità di librerie a corredo, ma visto che ci troviamo in una scala da 0 a 5 e che esistono linguaggi molto più perversi, siamo comunque tra valori medi.

Conclusioni

Qualche raccomandazione: siate onesti. Evitate di “arrotondare” le vostre valutazioni sulla base dell’impatto che queste potranno avere, specialmente sul vostro capo. Meglio una valutazione onesta d’istinto che un faticoso compromesso. Utilizzate tutta la scala di valori, da 0 a 5. Non usate i decimali, sono uno squallido trucco.
Poteva andare peggio. Altre culture – in particolare i Maya – sopperivano allo scarso sviluppo di arti predittive, con “strumenti di project management” più empirici, quali ad esempio cruenti rituali sacrificali per ottenere il favore degli dèi:

“Xhuatlàn, ho visto il Gantt e siamo in ritardo con la versione Beta”.
“È vero, sommo Onomatoepec, ma è così perche‘ il cliente ha cambiato i requisiti”.
“Hai ragione, ma abbiamo comunque deciso di sacrificarti in onore del dio serpente piumato, che propizierà il rilascio della versione 1.0”.

Riferimenti

[1] Monty Python, “The Holy Grail”

[2] Alistair Cockburn, “Writing Effective Use Cases”, Addison Wesley

[3] The Joel Test: 12 steps to better code
http://www.joelonsoftware.com/articles/fog0000000043.html

[4] Steve McConnell, “Software Project Survival Guide”, Microsoft Press

[5] Alistair Cockburn, “Agile Software Development”, Addison Wesley

[6] A. Brandolini, “Use Case Points. I parte: Stimare le dimensioni di un progetto software”, MokaByte 123, Novembre 2007