Introduzione
Abbiamo visto nel numero scorso la fase di discovery e le figure professionali necessarie per la sua attuazione. Inoltre l'interazione fra cliente, business analists e UI designers ha permesso di costruire il documento "Proof Of Concept" con la lista completa dei requisiti. Questo documento utilizza gli standard dell'azienda e viene preparato da una persona specializzata. Vediamo ora cosa avviena nel passaggio successivo.

Design Phase
Il risultato della fase di Discovery e' il documento "Proof Of Concept" (POC) che contiene la lista di tutti i requisiti del sistema da costruire con i corrispondenti "Use Cases" accompagnati da una descrizione grafica della UI, che forniscono una specifica funzionale.
Abbiamo visto anche che il POC e' stato ufficialmente accettato dal cliente. Questo e' un passaggio fondamentale perche' la non ufficializzazione del POC lascia spazio alla possibilita' di modifiche, da parte del cliente, che possono minare la buona riuscita del progetto. L'accettazione dei requisiti e' un atto di professionalita' da entrambe le parti, che getta le basi alla fase di design.
Il meeting di ufficializzazione deve prevedere la rivisita del POC di fronte al cliente, tramite una chiara presentazione di tutti i requisiti e funzionalita' del sistema da costruire. Durante questo meeting e' possibile apportare minimi cambiamenti, ma l'impianto base deve rimanere intatto. Puo' considerarsi minimo cambiamento la modifica di un messaggio utente, oppure l'utilizzo di una list box invece di una text box, e cosi via. In generale modifiche alla UI sono considerate modifiche minime, tranne quando sono utilizzate per l'introduzione di nuove funzionalita': questo e' definitivamente un 'NO, NO'.
Il project manager deve guidare un po' queste scelte, cedendo opportunatamente su richieste che sa bene sono di facile implementazione e assolutamente rifiutare modifiche che invalidano l'impianto del POC.

Abbiamo detto in precedenza di rimanere flessibili all'eventualita' di grandi modifiche e dare la possibilita' di una loro implementazione in una release successiva, in ogni caso spiegate chiaramente al cliente il motivo e le difficolta' nell'assecondare particolari richieste. Tali ragioni possono essere non soltanto tecniche, ma anche legate al budget e al tempo disponibile per l'implementazione.

Se tutto e' andato a buon fine, alla fine del meeting il cliente avra' accettato, tramite firma, il POC e siamo pronti ad iniziare la fase di design, che vede come protagonisti i team leaders, gli architetti e gli sviluppatori.
L'importanza di questa fase aumenta all'aumentare della complessita' del sistema da implementare e troppo spesso viene ridotta a semplice momento di raccolta di idee per poi tuffarsi nella fase di implementazione: cercate di non fare questo errore di valutazione. La fase di design mappa i requisiti in soluzioni ed e' impensabile procedere alla fase implementativa senza una chiara soluzione dei requisiti.
Molto spesso la difficolta' maggiore e' iniziare la fase di design, ma guidati dal buon senso e da alcune regole fondamentali di design vedremo che in realta' l'intero processo ha una sua linearita'. Il POC con i relativi use case e' la fase iniziale della costruzione di un'entita' piu' grande chiamata Domain Model. Tutti gli oggetti (anche se non descritti formalmente), gli attori ed altre entita', la loro relazione e la loro interazione sono state descritte in modo particolareggiato. E' arrivato il momento di estendere il domain model per includere risposte alle domande del tipo:

• Quale piattaforma e quale sistema operativo utilizzare?
• Quale linguaggio di programmazione?
• Come verra' distribuito il workload del sistema?
• Come verranno distributi gli aggiornamenti (updates)?
• Quale tipo di database utilizzare?
• Come realizzare il sistema per fornire le prestazioni promesse?
• Dobbiamo avere particolare attenzione per l'utilizzo di memoria?
• L'applicazione da costruire ha un'architettura distribuita?

Cercate di scrivere il numero maggiore di domande che pensate siano legate al progetto a cui state lavorando. Un buon design deve fornire una chiara risposta a tutte queste domande, inoltre il documento finale deve includere una stima del tempo necessario per l'implementazione ed i relativi costi.
Naturalmente se il progetto in questione e' una miglioria di un sistema esistente, la maggior parte di queste domande avra' gia' una sua risposta, ed il design sara' una semplice descrizione della soluzione adottata per ogni nuovo use case.
Anche se questo articolo e' lontano dal voler essere una discussione di tecniche di design, sappiamo che uno dei passi fondamentali e' la modellizzazione dei dati che il sistema dovra' gestire. Tale modellizzazione puo' avvenire con un procedimento Top-Bottom partendo, cioe', da dati complessi e arrivare ad un insieme di dati piu' semplici o elementari di cui questo e' composto; oppure viceversa, partire da dati elementari e, tramite composizione, giungere alla struttura dell'informazione complessa che si vuole modellare.
Questa fase di modellazione e' necessaria, perche' definisce l'insieme dei dati su cui il sistema dovra' fornire il suo output. Solitamente una modellazione sbagliata aumenta le difficolta' nel trovare una soluzione efficiente, fino a rendere impossibile la soddisfazione di alcuni requisiti. Se vi trovate in questa situazione, considerate seriamente il fatto di modificare il modello che avete scelto.
Il nostro comunque non e' un approccio qualsiasi, ma piuttosto un approccio OO "Object Oriented", cioe' orientato agli oggetti, ed ecco che oltre al modello dei dati, introduciamo il comportamento, "Behavior", che il sistema deve operare su tali dati. L'insieme delle coppie modello/behaviour definisce i componenti OO che costituiranno il sitema finale. L'approccio e le tecniche OO non sono soggetto di questo articolo, e la particolare tecnica utilizzata dipende molto dal particolare sistema che si intende costruire, ma quello che mi preme puntualizzare e' il fatto che nella fase di design e' opportuno utilizzare modelli che si adattano particolarmente all'approccio OO e cioe': UML.
Questo linguaggio formale di modellazione ha una capacita' espressiva senza precedenti e permette una descrizione chiara e formale delle varie componenti che si stanno progettando. I vari modelli costruiti utilizzando UML costituiranno la parte piu' importante del Detailed Design Document (DDD) che si andra' a costruire.
A tale proposito suggerisco la lettura di una ottima serie di articoli su UML pubblicati da Mokabyte e scritti da Luca Vetti Tagliati che forniranno al lettore un'ottima base su cui partire nell'utilizzare UML:

• UML e lo sviluppo del software (Mokabyte n. 34, Ottobre 1999)
• Use Cases (Mokabyte n. 35, Novembre 1999)
• Diagrammi di classi (Mokabyte n. 36/37, Dicembre 1999/Gennaio 2000)
• Activity Diagram (Mokabyte n. 40, Aprile 2000)
• Component View (Mokabyte n. 41, Maggio 2000)
• Deployment View (Mokabyte n. 43, Luglio 2000)

Il "Detailed Design Document" (DDD) deve contenere tutte le informazioni necessarie per comunicare chiaramente agli sviluppatori ed al cliente l'approccio utilizzato, l'uso di particolari tecniche di sviluppo (patterns, metodologie software, etc) e la soluzione dettagliata di ogni use case presente nel documento POC (Proof Of Concept).
Inoltre, il DDD deve dare una chiara esposizione dell'architettura del sistema che si vuole implementare, con particolare attenzione a:

• Architectural Views: che descrivera' l'architettura del sistema. Questo e' l'insieme delle seguenti views:
  • Logical View: descrive le parti significative del design, come i sub-systems di cui il sistema e' composto con i relativi componenti e moduli. La logical view descrive anche le classi principali con i loro attributi e responsabilita'.
  • Process View: descrizione dell'approccio utilizzato nella gestione dei processi. Se si e' scelto un'approccio multi-threading allora vogliamo descrivere come risolvere il problema della concorrenza. Nel caso di applicazioni web questa gestione e' delegata all'application server, e quindi non e' necessaria una descrizione approfondita.
  • Deployment View: anche se non strettamente necessaria, questa view descrive la configurazione dell'hardware utilizzato. In particolare viene definito l'architettura generale, cioe' se il sistema e' client/server, n-tiers o distribuito.
• Design Guidelines: risponderanno a domande relative a particolari framework o patterns utilizzati.
• Distributed Objects: se l'approccio utilizzato e' distribuito e' opportuno dettagliare il tipo di tecnologia utilizzata nella comunicazione degli oggetti che costituiranno il sistema. In particolare deve essere chiara la scelta operata. Le architetture distribuite piu' conosciute possono essere ricondotte a: RMI, EJBs, Messaging system, Sockets, HTTP/CGI, CORBA, COM/DCOM.

A grandi linee direi che un buon Design Document puo' essere organizzato nel modo seguente:

• Introduzione: specificate gli obiettivi del documento che state preparando e la sua organizzazione. Ad esempio per ogni area di design potete proporre la seguente organizzazione:
  • Scope: breve spiegazione riguardo l'argomento trattato e l'obiettivo principale che deve essere raggiunto.
  • Soluzione Proposta: in questa sezione dovreste proporre la vostra soluzione al problema introdotto nella sezione precedente (Scope). Potete inserire una descrizione sommaria dei dettagli implementativi e la modifica di sistemi/oggetti esistenti.
  • Use Cases e dettagli implementativi: La soluzione proposta viene formalizzata attraverso l'uso degli Use Cases nel documento POC. Per ognuno di essi devono essere specificate le Pre-Condizioni (cioe' sotto quali circostanze lo scenario e' valido) e le componenti coinvolte nella soluzione. In questa sezione deve anche essere introdotta una stima del tempo necessario nell'implementare lo scenario descritto.
    

  
  Inoltre specificate nell'introduzione tutti i documenti che, eventualmente, devono essere allegati, come il POC, oppure documenti di release precedenti. Se avete una lista di sigle utilizzate nel resto documento, inseritele pure nell'introduzione.

• Overview dell'Architettura: Dopo l'introduzione e' giusto fornire i dettagli delle architecture views del systema che si dovra' sviluppare. Questo e' il posto ideale per diagrammi di network, diagrammi multi-tiers, e cosi via. In questa sezione dovrete specificare in dettaglio eventuali Patterns utilizzati e quale beneficio si ha nel loro utilizzo.
  Descrivete anche, la piattaforma, il tipo di database, il linguaggio di sviluppo e tutta la serie di prodotti hardware/software che verranno utilizzati nell'implementare il sistema.
  
  
• Data Modelling: Questa e' la descrizione dello schema del database come risultato della mappatura dei dati. La lista delle tabelle, delle relationships tra di esse deve essere descritta chiaramente. Ho creato una sezione separata per questa descrizione, perche' ho notato che lo schema del database e' uno dei pilastri di riferimento per lo sviluppatore e per il cliente.
  
  
• Corpo del documento: Ogni scenario specificato nel POC deve essere dettagliatamente risolto nel documento. Come detto precedentemento, il mio suggerimento e' quello di considerare ogni Use Case e per ognuno di essi includere un paragrafo con la seguente struttura:
  
  • Scope
  • Soluzione Proposta
  • Dettagli Implementativi
    
    
  Nei dettagli implementativi ogni Use Case trova la sua soluzione. Riportate in questa sezione il Use Case Diagram e le immagini relative alla UI, ed introducete la soluzione utilizzando tutti gli strumenti che UML mette a disposizione: Use Cases, Diagramma di Classi, Activity Diagram, Sequence Diagram e/o Collaboration Diagram sono piu' che sufficienti nella formalizzazione della soluzione.
  E' in questa fase che UML manifestera' tutta la sua potenza ed utilita'. L'uso e la facilita' di lettura dei suoi diagrammi facilitera' incredibilmente la comprensione e la lettura della soluzione. Per la descrizione implementativa di ogni metodo appartenente ad una classe, utilizzare il linguaggio naturale o uno pseudo-language.

Per arrivare ad un buon design suggerisco al team leader e all'architetto, di lavorare in team con i programmatori. Costruite insieme lo scheletro generale e riempite i dettagli man mano che si procedete alla discussione di ogni use case. Ho trovato di enorme aiuto questo approccio perche' permette a tutti di famigliarizzare con la soluzione da implementare, ma sopratutto permette di condividere la professionalita' di ognuno come momento di crescita professionalmente.
Naturalmente la grande professionalita' ed esperienza del team leader deve guidare tutte queste energie in modo costruttivo e non disperderle in discussioni inconcludenti.
Nella formalizzazione del DDD, il team leader e il designer, devono comunicare con i business analyst e UI designer, allo scopo di ricevere tutti i chiarimenti del caso; quindi sentitevi autorizzati a chiedere tutte le spiegazioni necessarie.
Una cosa da evitare, a mio avviso, e' il fatto di reinventare qualcosa gia' noto. Se, ad esempio, il vostro approccio fara' uso di "connection pooling" non c'e' bisogno di dover analizzare e fornire una vostra implementazione. Molto spesso il "connection pooling" e' parte integrante dell'application server utilizzato, e, in ogni caso, ci sono molti algoritmi gia' implementati che forniscono una soluzione ottima al problema. Quindi non perdete tempo su questi componenti e concentratevi su cio' che veramente deve essere implementato da zero.
Il project manager dovra', di quando in quando, comunicare con il team leader per avere una descrizione del design che si sta costruendo. Considero l'input del project manager molto importante perche' e' la persona piu' vicina alla visione del cliente.
La stesura del DDD dovrebbe avvenire di pari passo con la costruzione del design e, anche in questo caso, preparatevi a reiterare sul documento piu' di una volta, fino ad arrivare alla versione che soddisfa tutti i requisiti.
A questo punto il project manager aggiornera' il progetto secondo i tempi specificati nel DDD e comunichera' al cliente la fine della fase di design con i dettagli della scaletta e delle relative scadenze della fase di implementazione. Per quanto riguarda i tempi implementativi che devono essere inclusi nel documento, la mia raccomandazione e' di essere il piu' onesti possibili: non preoccupatevi se pensate che un particolare oggetto necessita di due settimane/uomo per essere implementato. Queste stime dipendono dal gruppo di sviluppatori, ed il project manager solitamente deve aumentarle di un certo fattore per avere una fase di implementazione realistica ed evitare di spingere truppo sul gruppo di sviluppo. La chiave a questo punto e' veramente: utilizzate il buon senso.
Per la stesura del DDD, vale la stessa regola che abbiamo adottato per il POC, e cioe' utilizzate uno specialista che conosce gli standard adottati dall'azienda.
A questo punto (dipende dalla grandezza del progetto) viene organizzato un meeting formale con il cliente per la presentazione del DDD e per la sua accettazione formale.
A questo meeting parteciperanno il project manager, i business analist, il team leader, i designers ed i programmatori. Solitamente il cliente partecipera' al meeting con una persona tecnica di sua fiducia per avere un'opinione sul design presentato. Non fatevi intimorire dalla sua presenza, il fatto che il design sia stato concepito dall'intero gruppo, vi permettera' di rispondere facilmente a tutte le domande che verranno eventualmente poste.
Alla fine del meeting, il design dovrebbe essere stato approvato e il gruppo e' pronto per la fase di implementazione.
In qualita' di team leader, alla fine della fase di design, spingo sempre il Project Manager nel dare qualche giorno di ferie al gruppo. Questo permettera' all'intero gruppo di rilassarsi un poco prima della fase di implementazione e godersi il meritato successo della fase di design.

Conclusione
La fase di design e' il risultato di un grande lavoro di gruppo e porta con se un enorme creativita'. La potenza espessiva dell'UML sara' fondamentale nel comunicare l'approccio utilizzato ed i relativi dettagli implementativi. Ricordate, infatti, che lo scopo della fase di design e' quella di comunicare e non semplicemente creare qualcosa che poi nessuno comprendera'.

Giancarlo Crocetti si e' laureato in Scienze dell'informazione all'universita' "La Sapienza" di Roma per poi conquistare il Master in Computer Science alla Rutgers University del New Jersey nel 1998. Dal 1996 vive a New York dove lavora come consulente per importanti aziende ed enti governativi come: Computer Science Corporation, United Nations, Merrill Lynch, Lockheed Martin e per il governo degli Stati Uniti.
Da piu' di quattro anni il 60% dei sistemi da lui architettati e sviluppati vengono implementati utilizzando tecnologie Java. Nel 2000 ha creato la propria azienda Nous USA inc., che offre servizi di consulenza e di training concentrate soprattutto su tecnologie Java.