Da tre-quattro anni mi occupo quasi esclusivamente di architettura e design di sistemi e in questo periodo ho osservato che il 70/80% dei progetti vanno incontro ad tutta una serie di ostacoli perche' la fase di Project Management non viene applicata affatto o applicata soltanto in modo superficiale. Per piccoli progetti questo puo' non avere nessuna consequenza, ma per grandi sistemi in cui sono in ballo milioni di dollari, posso assicurarvi che la buona o cattiva riuscita di un progetto significa rispondere alla domanda: io e la mia azienda avremo un lavoro domani?
Continuo a vedere Project Managers che hanno difficolta' a portare avanti il processo di sviluppo, e la ragione e' da ricercarsi nella cattiva applicazione di alcune regole fondamentali che vanno sotto l'ombrello del Project Management. Continuero' a scrivere queste due parole in maiuscolo per ricordarne l'importanza.
Questo articolo vuole essere un momento di riscoperta dell'intero processo legato allo sviluppo di grandi sistemi software per le enterprise e di tutte le fasi e persone coinvolte. Ognuna di queste fasi e' importante e l'esclusivo uso di UML non si traduce direttamente nel successo del progetto stesso.
L'approccio che utilizzeremo sara' diviso in quattro fasi ben distinte:

1. Discovery Phase: viene identificato il business model e si procede alla descrizione di tutte le funzionalita' ad esso associate. Il risultato di questa fase sara' il documento "Proof Of Concept" che conterra' tutta la lista dei requisiti e la specifica funzionale.
2. Design Phase: Una volta che i requisiti vengono ufficialmente accettati dal cliente, viene creato il design del sistema che implementera' tali requisiti.
3. Development Phase: Quando il design viene ufficialmente accettato, il gruppo di programmatori inizia il suo lavoro di implementazione e di unit testing.
4. Deployment Phase: Quando il sistema sviluppato passera' il test da parte del QA (Quality Assurance) group, l'intera applicazione viene installata nell'ambiente di produzione. Una nuova fase di test e' necessaria per garantire la funzionalita' del sistema, dopodicche' il sistema e' pronto per essere utilizzato dall'utente finale.

Discovery Phase
Cominciamo facendo una banale osservazione:

"il cliente e' il soggetto piu' importante nell'intero processo."

Cosa significa? Significa che il cliente e' l'impulso dell'intero movimento, e' colui che vuole realizzare qualcosa e che si affida a noi per tradurre le sue necessita' in un sistema software. Sta a noi, alla nostra professionalita', onesta' e bravura cercare di guidare le necessita' del cliente in modo costruttivo verso un processo creativo del software.
Per far cio' il Project Manager deve scegliere un gruppo di persone, chiamate Business Analysts, che vengono affiancate al cliente per cercare di tradurre le necessita' dello stesso in modo formale. Questo processo e' uno dei piu' difficili perche' molto spesso il cliente non ha una chiara visione sulle proprie necessita' e a questo riguardo sceglierei come business analist, una persona che conosce gia' il mercato in cui il cliente si trova ad operare. Questo offre un enorme vantaggio, perche' il cliente viene guidato nel formulare le proprie necessita' ed ha un'immediata sensazione di essere compreso con la conseguente fiducia nei nostri confronti. Inoltre questa esperienza aiutera' lo stesso ad entrare nel processo di sviluppo: molte volte ho visto questa trasformazione in cui il cliente da persona sospettosa e confusa si trasforma in persona propositiva. Non sottovalutate affatto quest'aspetto.
Il business analist(s) lavorera' insieme con gli User Interface designers (UI) per catturare in modo visivo la funzionalita' del sistema che si sta cercando di realizzare. Concetto molto importante perche' aiutera' il cliente a visualizzare la funzionalita' del sistema finale evitando, cosi, modifiche in fase avanzata del progetto.
Questa fase viene chiamata Discovery Phase il cui risultato viene formalizzato in un documento chiamato Proof Of Concept in cui vengono chiaramente identificati gli obiettivi che si vogliono raggiungere e la lista dei requisiti del sistema da sviluppare con le relative specifiche funzionali.
Normalmente sono necessarie diverse iterazioni per arrivare ad una buona stesura dei requisiti. Quindi aspettatevi e preparatevi a dover cambiare questo documento piu' di una volta.
E' molto utile affiancare al gruppo degli analisti un Technical Writer, cioe' una persona il cui compito e' semplicemente quello di scrivere documenti. Solitamente il technical writer entra in scena nella fase formale della stesura dei documenti e non prima. I business analists e i UI designers forniscono il loro input al technical writer che provvede ad elaborarli in un'unico documento il cui formato segue gli standard aziendali.
Apro, qui, una piccola parentesi: e' molto importante che l'azienda abbia sviluppato degli standard nella stesura dei documenti al fine di migliorare la qualita' del servizio offerto.

A questo punto ci sono due scuole di pensiero: una che considera conclusa la fase di discovery, mentre l'altra che la considera completa soltanto a meta'.
Nel primo caso viene richiesto al cliente l'accettazione dei requisiti ed una volta accettati non possono essere cambiati: Questo e' categorico.
Se il cliente dopo l'accettazione, come spesso avviene, vuole cambiare i requisiti in modo sostanziale, considerate il fatto di dover addebitargli le spese di tale modifica, oppure prospettate la possibilita' di apportare queste modifiche in una release successiva. Di solito questo e' sufficiente a soddisfare il cliente. Questa trattativa e' chiaramente un compito del Project Manager.
Nel secondo caso i business analists vengono affiancati al team leader per la stesura dei vari Use Cases descritti dai requisiti. Questo e' di enorme importanza, perche' si comincia a dare una visione concreta al sistema che deve essere sviluppato e della relativa funzionalita', e puo' rivelare, anticipatamente, errori di valutazione che potenzialmente violano uno o piu' requisiti, e che possono insidiare la fase di design successiva.
Per maggiori dettagli sull'uso dei Use Cases rimando all'articolo n. 36 (Dicembre 1999) di Mokabyte scritto da Luca Vetti Tagliati che presenta in maniera chiara e lineare l'uso degli UML Use Case.
Come vedete UML comincia ad entrare nel progetto come uno strumento eccezionalmente valido, ma non sufficiente di per se alla formalizzazione del progetto nella sua interezza.
Per grandi progetti considero il secondo approccio piu' funzionale perche' organizza e formalizza, a priori, li grande lavoro che aspetta al team di sviluppo.
Come avete notato, fino a questo punto non e' stato coinvolto nessun analista/programmatore: anche se fortemente consigliabile, la loro partecipazione non e' necessaria. Se coinvolti nel processo di discovery, le loro menti cominciano a famigliarizzare con i concetti coinvolti nella realizzazione del sistema, facilitando la successiva fase di design ed implementazione.
Riporto qui tutte le figure professionali coinvolte nel processo di discovery e la loro funzione:

Figura 1 - Gerarchia di Gruppo (clicca per ingrandire)

Project Manager: e' la persona responsabile dell'intero progetto e punto di contatto con il cliente. Introduce e coordina tutti gli altri profili professionali, concentrandosi continuamente nell'uso di risorse per raggiungere gli obiettivi contrattuali entro il budget ed i tempi previsti. Se ci sono dei dissensi sulla strada da percorrere il Project Manager ha l'ultima parola. Un buon Project Manager ha sempre la situazione sotto controllo e riesce a bilanciare le necessita' del cliente con quelle del gruppo di lavoro. Sempre disponibile, riesce a persuadere le persone con la sua professionalita' ed a risolvere spiacevoli situazioni in modo da non lasciare traccia a cattivi umori.
Business Analist: persona solitamente esperta nel campo in cui viene chiamato ad operare. Abbiamo cosi Business Analist per sistemi e-commerce, bancari, pubblicitari e cosi via. Vengono affiancati al cliente per aiutarlo a formalizzare le sue necessita' in una serie di requisiti che debbono essere soddisfatti dal sistema. Il risultato del suo lavoro si traduce nel documento "Proof Of Concept" con i relativi Use Cases. Lavora a stretto contatto con il Project Manager e del UI Designer.
UI Designer: Lavora a fianco del Business Analist e costruisce gli schermi per gli Use Cases sviluppati. Puo' dare un enorme contributo sulla navigabilita' e usabilita' dell'applicazione.
Technical Writer: Raccoglie tutto il lavoro sviluppato dal Business Analist e UI designer e lo converte in un documento formale che adotta tutti gli standard aziendali.
Team Leader: Il Project Manager fara' uso di uno o piu' (dipende dalla dimensione del progetto) Team Leader, che e' responsabile nel comunicare e gestire il gruppo di designers e programmatori. Spesso il Team Leader e' il designer del sistema. Lavora in stretta collaborazione con il Project Manager e spesso e' chiamato a operare delle scelte importanti. Il Project Manager fara' molto affidamento sul Team Leader soprattutto per quanto riguarda i tempi di sviluppo, la gestione delle risorse e la comunicazione tra I vari gruppi coinvolti nello sviluppo e test del sistema.

Figura 2 - Iterazione del Gruppo

Tutto cio' che e' stato detto finora, e' un approccio generico, ma funzionale, che potete modificare secondo le vostre esigenze. Il metodo descritto in questa serie di articoli e' stato implementato con successo in molti progetti di medie dimensioni (diciamo dai 10 ai 40 milioni di dollari) e che quindi puo' essere considerato cosi com'e' nella maggioranza dei casi.
Per brevita' non descrivero' nei dettagli il lavoro del business analyst, del UI designer oppure del system designer. Suppongo che queste figure professionali siano ben conosciute al lettore. In caso contrario e' disponibile su internet una grande letteratura riguardo a tali profili.

Conclusione
L'esperienza insegna che l'approccio formale e l'uso di metodologie sono essenziali nella buona riuscita di un progetto. Ma tali metodi hanno senso soltanto se vengono applicati nella loro interezza. Molto spesso UML viene confuso come metodologia di progetto che promette la realizzazione di progetti complessi in modo facile e veloce. Questa serie di articoli riscoprira' l'approccio del Project Management e riposizionera' UML al suo posto come strumento essenziale nel descrivere e formalizzare modelli OO.
Nel prossimo articolo descriveremo la fase di design e vedremo come UML abbia, in questa fase, un ruolo fondamentale.

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.