Introduzione
Quando si affronta la progettazione e lo sviluppo di sistemi complessi, gli aspetti da tenere in considerazione sono numerosi e particolarmente critici: scelta accurata dei vari elementi (strumenti, persone, metodologie), ma anche attenzione alla mutua integrazione con l'obiettivo della massima sinergia, il tutto in un adeguato contesto di Project Management. Abbiamo più volte parlato su queste pagine della Model Driven Architecture (MDA), la metodologia di sviluppo di OMG, con particolare attenzione all'ambito J2EE [1]. Obiettivo del presente articolo è quello invece di discutere l'utilizzo di MDA in progetti in cui si sia scelto DSDM [2], paradigma RAD particolarmente apprezzato e in rapida diffusione. Una valida metodologia, d'altra parte, va anche inserita in efficienti contesti di Project Management: è quindi per tale motivo che nella seconda parte di questo articolo vedremo come l'approccio MDA-DSDM analizzato in questa prima parte possa inserirsi in maniera totalmente integrata in un contesto progettuale che abbia adottato PRINCE2, la metodologia di Project Management di maggiore successo e diffusione in ambito europeo da qualche anno a questa parte.

RAD: non è tutto oro…
Probabilmente tutti sanno che RAD (Rapid Application Development) è una metodologia di sviluppo iterativa e incrementale, basata su alcuni principi base, tra cui:
Fino all'80% del prodotto finale può essere consegnato nel 20% del tempo
Il coinvolgimento continuo e costante dell'utente finale è una chiave per il successo
Mentre nel tradizionale approccio "waterfall" il cliente finale definisce in modo chiaro, esplicito e completo i suoi requisiti all'inizio del processo di sviluppo (ed essi costituiscono il riferimento di base per tutta la durata del progetto), l'ambito RAD nega che tali requisiti possano essere chiari fin dall'inizio, e prevede una serie di evoluzioni incrementali per far fronte a quanto - dinamicamente - l'utente finale richiede
Le date di consegna sono fissate in modo irremovibile (tecnica del timeboxing)
Fino a qualche anno fa gli strumenti RAD sembravano davvero una panacea, la metodologia vincente del "tutto e subito". Già, ma non del "tutto, subito e anche bene"……nulla si guadagna senza fatica, e se da un lato RAD equivale a "faccio tutto quello che mi ha chiesto il cliente e in pochissimo tempo", è anche vero che la qualità del prodotto finale consegnato lasciava spesso a desiderare, come l'esperienza ha in molti casi dimostrato. Colpa del RAD o di come è stato applicato? "Non fa scienza senza lo ritener aver inteso" diceva il Poeta…..espressione equivalente più o meno al più moderno "A fool with a tool is still a fool"…come dire che lo strumento adatto in mano a chi non sa utilizzarlo si rivela inutile ………e allora?

DSDM: cos'è?
Come spesso accade, la soluzione si chiama "best practice", è significa grosso modo "applicare una data metodologia in modo saggio, mettendone in pratica le parti che l'esperienza ha insegnato essere le migliori e nel modo più efficiente possibile". Questo è uno dei tanti motivi che hanno portato alla nascita e diffusione delle metodologie cosiddette "agili" ([3]), anch'esse orientate al rilascio rapido di prodotti, ma con un occhio più che attento anche alla qualità di quanto viene effettivamente rilasciato. E' più o meno così che persone dotate di spirito razionale e molto concreto hanno creato Dynamic Systems Development Method (DSDM, [2]), una nuova interpretazione del RAD che sta conoscendo un sempre maggiore successo (alcuni studi su progetti che hanno impiegato DSDM riportano un ROI del 200%, vedere [4]). Piuttosto che una metodologia nel senso letterale del termine, DSDM può più correttamente essere definito come un framework focalizzato a produrre rapidamente soluzioni di qualità.

DSDM è basato su tre caratteristiche principali:

• Prototipizzazione: i sistemi vengono creati secondo le necessità dell'utente finale. E' lui a determinare cosa fa il sistema
  
• Sviluppo iterativo: i requisiti del sistema possono variare durante lo sviluppo, e il team deve essere pronto ad affrontare e gestire questo aspetto. Incorporare ulteriori funzionalità verrà deciso dagli utenti finali, con il conseguente costo
  
• Funzionalità variabili: ogni progetto presenta tre "aspetti gestionali" principali, ossia tempo, risorse e funzionalità (figura 1). DSDM stabilisce che solo le funzionalità sono variabili, mentre il tempo e le risorse vengono considerati fissi. Le funzionalità vengono scelte secondo un paradigma detto MoSCoW (Must have, Should have, Could have, Won't have now). Sono le priorità assegnate a decidere cosa va fatto prima di cos' altro

Figura 1 – I tre "management aspects" di DSDM

DSDM: ciclo di vita e processi
DSDM divide il tempo a disposizione per svolgere i progetti in "scatole", i cosiddetti "time-box", normalmente tali da abbracciare un periodo che va dalle sei alle otto settimane. Al termine di ciascun time-box, viene rilasciato un qualcosa che l'utente finale deve essere in grado di utilizzare. All'interno di ciascun time-box, le attività vengono svolte secondo un ben determinato ciclo di vita, basato sui diversi requisiti che caratterizzano quel determinato time-box (fig 2). Ciascuna attività è organizzata in fasi. Le prime due fasi vengono eseguite prima del primo time-box e indicano ciò che il progetto deve fare, in quale ambito temporale (time frame) e con quali risorse, e sono:
Studio di fattibilità, che risponde al quesito "Siamo in grado di ottenere ciò che vogliamo ottenere usando DSDM?"
Analisi del Business, che ha l'obiettivo di arrivare a ottenere abbastanza comprensione del progetto da definire con precisione ambiti temporali (time frame), time-boxes e risorse

Le fasi successive vengono eseguite basandosi sui time-box definiti nel corso delle due fasi precedenti, e sono costituite da:
Iterazione sul modello funzionale, che definisce esattamente cosa il sistema deve fare da un punto di vista business oriented. Vengono individuati e definiti aspetti funzionali e anche non-funzionali
Iterazione progettazione-sviluppo, che ha l'obiettivo di far confluire i requisiti in qualcosa di realmente funzionante, abbastanza stabile da poter essere utilizzato dagli utenti finali. Si prevede che la fase di testing faccia idealmente parte di questa fase
Implementazione, ossia transizione dall'ambiente di sviluppo a quello di esercizio, incluse le attività di training verso quegli utenti che non sono stati coinvolti nel processo di sviluppo
Il team di sviluppo tipico di DSDM è formato da almeno otto persone, e prevede la presenza di varie figura tra cui un team leader, uno o più rappresentanti dell'utente finale (i cosiddetti "ambassador"), uno o più sviluppatori, uno o più tester. Il tutto è completato da un project manager e (idealmente) da un technical architect.

Figura 2 – Ciclo di vita di DSDM

MDA: componenti di base
MDA, già trattata su queste pagine dal punto di vista dell'impiego in ambiti applicativi J2EE [1], basa la sua efficacia sulla potenza espressiva intrinseca nel modello iniziale di business (Platform Independent Model o PIM) che permette di modellare il solo core-business aziendale. Da esso vengono derivati tutti i modelli applicativi necessari (Platform Specific Model o PSM), uno per ciascuna delle tecnologie scelte per la successiva implementazione (fig. 3)

Figura 3 – Model Driven Architecture in J2EE

L'idea di lavorare per modelli, in cui ciascuno costituisce un'astrazione del modello sottostante permette di operare in modo molto più efficiente e controllato, permette di concentrarsi principalmente sugli aspetti del business (PIM) ovvero sui modelli applicativi (PSM) prima di essere costretti a mettere mano al codice sottostante. Senza contare il fatto che gli strumenti MDA offrono anche la possibilità di sincronizzare tra di loro tutti i diversi modelli - quindi modificandone uno, la modifica viene immediatamente e automaticamente propagata agli altri - e possono offrire altresì la possibilità di intervenire direttamente sui meccanismi di trasformazione da un modello all'altro, implementando le best practices maggiormente valide e consolidate (ad esempio i Core J2EE Patterns per costruire il codice J2EE a partire dai PSM).

Uso di MDA in sviluppi DSDM
E' proprio grazie a questa natura particolarmente flessibile che gli strumenti basati su MDA (ad esempio [5]) garantiscono elevati incrementi di produttività e sono particolarmente adatti a essere inseriti in tutti quei contesti in cui si utilizzino metodologie "agili". DSDM non fa certo eccezione, perchè uno strumento basato su MDA è per sua natura strutturato in modo da definire con rigore dei modelli su cui viene basata l'infrastruttura di base dell'applicazione finale. Proprio a partire da tali modelli viene derivata l'applicazione completa, con estrema rapidità (è molto più facile lavorare a livello di modelli che non a livello di codice), in modo affidabile (le trasformazioni previste e codificate da MDA sono congegnate al fine di garantire la qualità del prodotto finale), e in modo iterato, giacchè sono i modelli, con i loro successivi raffinamenti, a guidare attraverso i vari step verso un'applicazione sempre più vicina a quella da consegnare. Non ultimo, il fatto che uno strumento basato su MDA può offrire anche la possibilità di suddividere il progetto principale in sotto-progetti, affrontabili da team di sviluppo di dimensioni ridotte e coordinando i prodotti rilasciati da ciascun team ([6] e [7]). Questo tipo di partizionamento può essere senz'altro effettuato nel corso della fase DSDM detta "Analisi del Business". Nella tabella di fig.4, è riportata una corrispondenza tra le varie fasi previste da DSDM e le corrispondenti fasi e attività previste da MDA. Nel nostro caso ci si riferisce allo sviluppo di un progetto J2EE.

Figura 4 – Confronto DSDM vs MDA

Conclusioni
MDA, la metodologia di sviluppo standardizzata da Object Management Group possiede una natura estremamente flessibile e per ciò stesso particolarmente adatta a essere inserita in tutti quei contesti di sviluppo in cui si scelgano paradigmi cosiddetti "agili", focalizzati allo sviluppo rapido di applicazioni ma tenendo anche in adeguato conto la qualità del prodotto finale offerto, a differenza di quelli che erano i primi veri e propri strumenti RAD. Immaginando quindi di adottare DSDM quale paradigma di sviluppo per il proprio progetto J2EE, appare particolarmente produttivo scegliere uno strumento basato su MDA. Tutto questo però ancora non basta, perchè è necessario anche misurare l'efficacia delle scelte metodologiche fatte nel reale contesto progettuale con cui dobbiamo misurarci. Spostiamo quindi il focus dallo sviluppo vero e proprio all'ambito Project Management, riferiamoci a una delle metodologie di Project Management più promettente e diffusa (PRINCE2) e vediamo come calare in essa MDA-DSDM. Questo sarà l'argomento che affronteremo nella seconda parte di questo articolo.

Bibliografia
[1] Mokabyte - "Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE”, parte 1 http://www.mokabyte.it/2004/07/mda-1.htm e parte 2 http://www.mokabyte.it/2004/09/mda-2.htm)
[2] DSDM Consortium - http://www.dsdm.org
[3] Agile Alliance - http://www.agilealliance.org
[4] "DSDM Xansa Metrics Study" http://www.dsdm.org/kss/details.asp?fileid=405
[5] "Compuware OptimalJ” - http://www.optimalj.com
[6] Mokabyte - " Sviluppare Applicazioni J2EE di grandi dimensioni: un approccio concreto e affidabile”, http://www.mokabyte.it/2005/03/huge_progect.htm
[7] Mokabyte - " Skill differenti per Applicazioni J2EE di successo: la sfida del teamworking”, http://www.mokabyte.it/2005/12/teamworking.htm

Doriano Gallozzi è nato a Roma nel 1964 e si è laureato in Ingegneria Elettronica (indirizzo Informatica) nel 1989. Da sempre interessato a problematiche di analisi, progettazione e sviluppo di Sistemi Informativi, ha lavorato per diversi anni in aziende del settore informatico italiano (gruppo ENI, gruppo Telecom Italia), dove ha acquisito diverse esperienze tanto nel campo della progettazione e sviluppo del software (in ambiente M/F come in ambiente distribuito) quanto nel campo dei RDBMS (DBA su diversi progetti per clienti finali quali Telecom Italia). Da gennaio 2000 lavora nella Divisione Prevendita di Compuware Italia. La sua attività verte principalmente sulla piattaforma J2EE e tecnologie correlate, ma anche su ambiti tecnologici quali le soluzioni di Project Management per IT-Governance, i Portali Web, gli strumenti di Business Process Automation, l’Enterprise Application Integration.