Dopo aver lavorato per stabilire la fattibilità di un progetto, quali sono gli obiettivi da rag-giungere e soprattutto cosa il progetto sarà e non sarà (lo scope di progetto) proseguiamo con alcune considerazioni relative alle prime fasi di analisi del progetto. Questo articolo do-vrebbe rappresentare un passo transitorio verso i prossimi, quelli relativi alla analisi e alla implementazione del progetto
Introduzione
Sviluppare un progetto software (che sia Java la tecnologia scelta è un fattore ininfluente in questo momento) è una attività piuttosto complessa che prevede il coinvolgimento di diversi ruoli professionali e soprattutto necessita di scelte tecnologiche non sempre banali.
Lo scopo di questa serie è proprio quello di dare le indicazioni di massima per avere successo nell‘obiettivo prefissato: sviluppare il progetto.
Per ovvi motivi, questa serie di articoli non può rappresentare un compendio completo delle varie tematiche che verranno di volta in volta trattate, ma piuttosto dovrebbe aiutare a segnare la strada da seguire: non ci fermeremo in ogni luogo e non visiteremo in dettaglio ogni località , ma viaggeremo con lo scopo di far capire quale sia il percorso e cosa sia utile conoscere o visitare.
Con questo spirito quindi verranno analizzate le caratteristiche principali per comprendere, in funzione dello scope di progetto e delle scelte architetturali, se e quando convenga utilizzare Spring al posto di EJB (o viceversa), Hibernate al posto di JPA: sarà poi compito del lettore cercare il materiale (anche su MokaByte) per approfondire i temi trattati da un punto di vista più tecnico e puntuale.
Impostare l‘analisi
Con questo approccio ben chiaro in mente, siamo partiti il mese scorso con l‘obiettivo di fornire il punto di vista del project manager nelle fasi preliminari di startup del progetto.
Questo mese continueremo su questa strada riprendendo la trattazione relativa al punto di vista del project management e passando man mano a quello dell‘analista.
Come si è avuto modo di vedere nel precedente articolo, il ruolo del project manager, è quello di tenere sotto controllo ogni aspetto relativo alla normale evoluzione del progetto stesso: questo significa verificare, Gantt alla mano, che tempi, effort e costi restino nei limiti pattuiti.
Project management significa anche e soprattutto fare in modo che lo scope di progetto sia rispettato: in ogni momento si deve controllare che il lavoro stia producendo risultati in linea con gli obiettivi di progetto e soprattutto che non si stia realizzando qualcosa che esula dai limiti e dal dominio del problema stesso (sembra strano ma questo è un rischio che può accadere più frequentemente di quanto si possa immaginare).
In questa puntata della serie passeremo ad analizzare il lavoro dell‘analista cercando di capire per prima cosa come queste due figure (project manager e analista) entrano in contatto e collaborano durante le prime attività del progetto.
Per tutti gli approfondimenti legati alle metodologie iterative in stile RUP (oggetto del prossimo articolo) si rimanda all‘ottimo manuale scritto da Craig Larman [LAR]. Per quello che riguarda invece analisi e design, definizione degli Use Case sia tramite diagrammi che per mezzo degli Use Case Form (argomenti contenuti anche nel libro di Larman) si consiglia la lettura del libro scritto dal nostro collaboratore Luca Vetti Tagliati [LVT]. In entrambi i casi si tratta di tomi dalle dimensioni ragguardevoli, ma che spiegano in modo chiaro e mai difficile argomenti che semplici certamente non sono.
Il processo di implementazione: suddivisione dei ruoli e dei flussi di lavoro
L‘articolo pubblicato il mese precedente terminava affrontando le fasi di definizione preliminare delle varie macroattività che il software dovrà implementare. Il diagramma mindmap pubblicato mostrava come il lavoro complessivamente potesse essere scomposto in varie parti secondo un processo che poi avrebbe portato alla definizione di moduli e use case dell‘applicazione. Il compito degli analisti in questa fase è quello di raffinare il più possibile tale diagramma in modo da consentire il passaggio alla fase di progettazione e contemporaneamente di permettere al project manager di raffinare le proprie valutazioni e tenere sotto controllo il progetto in modo più preciso.
In questo momento le due figure e le relative attività vanno di pari passo, come si può verificare dalle figure 1, 2, 3, 4: a partire da un mindmap povero (quello che si genera durante la fase preliminare di analisi) si può produrre un Gantt che raccoglie solamente alcune macroinformazioni.
Figura 1 – Inizialmente il mindmap raccoglie solamente le macro
funzionalità o moduli funzionali dell‘applicazione.
Figura 2 – In questa fase anche il diagramma di Gantt non offre un livello
di precisione utile al lavoro del project manager.
Con l‘avanzare delle attività di indagine funzionale e dei requisiti (secondo un processo ricorsivo come mostrato nella figura 6) l‘elenco degli use case si raffina e quindi anche il Gantt può essere migliorato (se possibile fare delle stime, si possono iniziare a porre delle misure temporali).
Figura 3 – Il mindmap viene arricchito con un maggior frazionamento delle attività .
Figura 4 – Anche il Gantt può essere più dettagliato: a questo punto, appena arrivano
le prime stime, il project manager può iniziare a mettere dei valori piùprecisi sulle
scadenze e sulla durata delle attività .
Per poter arrivare a mettere un numero di giorni accanto ad ogni attività , è necessario un tipo di indagine più rigorosa: accanto all‘utilizzo di strumenti empirici (l‘esperienza è spesso considerato il modo migliore per sapere quanto tempo sarà necessario a un programmatore del proprio team per fare una attività già svolta in passato), si possono utilizzare approcci più rigorosi basati su calcoli matematici ponderati (quando la cosa da fare non è mai stata fatta prima o le condizioni ambientali sono cambiate). In questo ambito molto in voga ultimamente è la metodologia degli Use Case Points, della quale abbiamo pubblicato un primo articolo nel numero di novembre di MokaByte [BRA].
Qualora il processo di stima delle attività evidenzi che alcuni casi d‘uso siano troppo grandi per poter essere implementati con successo e pochi rischi, si potrà procedere ad un ulteriore frazionamento, cosa che porterà a una ulteriore modifica del diagramma di Gantt.
La domanda che in questo caso sorge spontanea è come capire quando il processo di raffinamento possa considerarsi completo, ossia quando una attività (uno use case) sia sufficientemente piccolo per poter procedere alla fase di implementazione.
Non esiste una risposta precisa a questa domanda, ma si può certamente dire che il processo di decostruzione degli use case tende a fermarsi quando si arriva ad avere attività di dimensioni compatibili con la grandezza del clock di ogni iterazione del processo iterativo. Si supponga ad esempio di lavorare con iterazioni lunghe un mese: ogni 4 settimane il gruppo di lavoro esegue un lavoro di implementazione o raffinamento di tutti gli use case; al termine di tale periodo tutte le parti (use case) del progetto saranno state eseguite per una percentuale di avanzamento direttamente proporzionale al numero della iterazione. Quindi al primo giro un po‘ tutto sarà fatto al 10-20% al secondo si salirà al 30-40% per arrivare al totale completamento del progetto verso le ultime iterazioni.
Questo meccanismo funziona bene se gli use case sono stati tagliati della grandezza giusta, in modo da permettere iterazioni corrette e fluide. In genere non ci sono modelli matematici o regole scritte che possano aiutare nel capire quale sia la dimensione giusta: sulla base di regole empiriche, non scritte, in genere si tende a dividere i progetti in attività mono-programmatore della durata massima che varia fra una settimana lavorativa per progetti medi, fino ad arrivare alle due settimane per progetti di grosse dimensioni (dimensioni maggiori rischiano di far perdere il controllo di quello che accade e degli eventuali ritardi e imprevisti).
Un eventuale errore di super-frazionamento (attività troppo piccole) può portare a un costo di gestione eccessivo, ma è certamente questo il minore dei due mali; se invece le singole attività sono troppo grandi, si corre il rischio di non poter tenere sotto controllo il lavoro e quindi di non riuscire ad accorgersi (o di accorgersi troppo tardi) se qualcosa va storto o non si stanno rispettando le scadenze.
Se il progetto è di grosse dimensioni si può pensare di organizzare le iterazioni in modo da spostare le varie figure da un use case a un altro in maniera orizzontale (la figura 5 spiega meglio di mille parole questo concetto). In [LAR] sono riportati alcuni esempi in modo meticoloso di cosa accade durante le varie fasi di sviluppo basate su una metodologia iterativa.
Figura 5 – La separazione delle iterazioni può essere “compressa”:
se i ruoli sono separati, si passa alla stessa fase dell‘iterazione
successiva, restando comunque allocati sullo stesso progetto.
In questo caso si immagina che tutti gli use case abbiano la stessa importanza nella economia del progetto, cosa che in realtà non capita quasi mai: di solito si decide di lasciare indietro alcune parti meno importanti per concentrare gli sforzi su quelle parti più importanti, quelle critiche, quelle necessarie per consentire il funzionamento delle altre. Spesso è il capo progetto che si prende in carico di gestire le priorità controllando le varie risorse.
È comunque importante tenere presente che le varie attività si susseguono in un processo che ciclicamente specifica i requisiti i quali raffinano la definizione del problema, dal quale si ricava il diagramma concettuale delle classi (entity diagram) e si possono specificare i vari casi d‘uso e le interdipendenze che vi sono. La figura 6 schematizza in modo efficace questo scenario.
Figura 6 – Il processo di analisi e di definizione del problema è basato su una serie
di attività che si rincorrono e che consentono passo dopo passo di arrivare
progressivamente a un raffinamento sempre maggiore dei vari manufatti
(diagrammi, questionari, documenti vari).
Questo approccio iterativo e incrementale offre maggiori garanzie di successo e riduce il rischio di rimanere bloccati nel caso in cui manchi qualche informazione; il prezzo da pagare ovviamente è che non è possibile mai avere la certezza matematica di essere giunti a termine, ovvero che il materiale prodotto sia quello necessario e sufficiente per poter passare alla fase di implementazione.
Un piccolo passo indietro: la raccolta dei requisiti e la definizione del dominio applicativo
La stesura del Gantt e la stima delle tempistiche dei singoli casi d‘uso prevedono di fatto che in un modo o nell‘altro si possa stilare l‘elenco degli use case, condizione che non è affatto scontata. Se si riconsidera quanto riportato in figura 6, si può notare come uno degli artefatti su cui investire è il documento dei requisiti, il quale è in genere scritto in un linguaggio tecnico e rappresenta una sintetica formalizzazione di quanto raccolto durante le prime conversazioni con qualcuno in grado di dirci cosa e come dovrà funzionare il programma. Spesso per giungere a tale documento si preferisce partire dalla classica intervista con il committente o con un esperto di dominio al fine di comprendere nel modo più dettagliato possibile il campo di cui l‘applicazione si dovrà occupare.
In questa fase, specialmente se l‘argomento stimola la curiosità dell‘analista, la conversazione si svolge in maniera il più naturale possibile spaziando a 360 gradi anche su aspetti di secondaria importanza: questo atteggiamento, che a volte può essere valutato come un inutile spreco di tempo, è invece molto importante perché permette all‘analista di entrare realmente nel mondo in cui opera quello che poi sarà l‘utilizzatore del software e gli consente da un lato di procedere alla definizione delle funzionalità (processo di analisi) nel modo più preciso possibile, dall‘altro permetterà di rispondere alle domande che sorgeranno nel gruppo di lavoro durante la normale attività di progettazione e sviluppo.
Nel prossimo articolo vedremo come nella pratica questi concetti, qui esposti in modo introduttivo e ad alto livello, possano essere tradotti in documentazione di progetto, analisi, prima definizione del modello dei dati e nell‘elenco degli use case.
Riferimenti
[FOW] Martin Fowler . Kendall Scott, “UML Distilled”, Addison-Wesley Professional
[LVT] Luca Vetti Tagliati, “UML e ingegneria del software”, Tecniche Nuove
[LAR] Craig Larman, “UML and Design Patterns”, Prentice Hall PTR
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.