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 segna-re la strada da seguire: non ci fermeremo in ogni luogo e non visiteremo in dettaglio ogni lo-calità, ma viaggeremo con lo scopo di far capire quale sia il percorso e cosa sia utile conosce-re 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 utiliz-zare Spring al posto di EJB (o viceversa), Hibernate al posto di JPA: sarà poi compito del let-tore cercare il materiale (anche su MokaByte) per approfondire i temi trattati da un punto di vista più tecnico e puntuale.
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, è quel-lo 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ò ac-cadere più frequentemente di quanto si possa immaginare).
In questa puntata della serie passeremo ad analizzare il lavoro dell'analista cercando di capi-re 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 pros-simo 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 diffi-cile 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 prelimi-nare delle varie macroattività che il software dovrà implementare. Il diagramma mindmap pubblicato mostrava come il lavoro complessivamente potesse essere scomposto in varie par-ti secondo un processo che poi avrebbe portato alla definizione di moduli e use case dell'ap-plicazione. 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 contemporanea-mente di permettere al project manager di raffinare le proprie valutazioni e tenere sotto con-trollo 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.
Con l'avanzare delle attività di indagine funzionale e dei requisiti (secondo un processo ricor-sivo 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 dura-ta delle attività.
Per poter arrivare a mettere un numero di giorni accanto ad ogni attività, è necessario un ti-po 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 ultimamen-te è 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.
Figura 5 - La separazione delle iterazioni può essere "compressa": se i ruoli sono separati, si pas-sa 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 proget-to 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 ri-cava 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 sce-nario.
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 ri-schio 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 tecni-co e rappresenta una sintetica formalizzazione di quanto raccolto durante le prime conversa-zioni 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 cam-po 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 secon-daria 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 la-voro durante la normale attività di progettazione e sviluppo. Nel prossimo articolo vedremo come nella pratica questi concetti, qui esposti in modo intro-duttivo 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