Attualmente dedicarsi allo sviluppo software comporta l’utilizzo di nuove metodologie che ben poco hanno a che vedere con le tradizionali metodologie. Infatti le nuove applicazioni devono sempre di più interfacciarsi con sistemi e piattaforme informatiche che possono essere anche molto diverse o poco interfacciabili tra loro. Per consentire la migliore integrazione delle moderne tecnologie e l’ottimizzazione della gestione dei problemi che possono sorgere dall’utilizzo di tecnologie diverse, è nata la Model Driven Architecture (Mda).
Quando si affronta la progettazione e lo sviluppo di sistemi complessi, innumerevoli sono gli aspetti da tenere in considerazione soprattutto per la numerosità oltre che per la criticità: per esempio la scelta dei vari elementi (strumenti, persone, metodologie), ma soprattutto è importante prestare particolare attenzione alla sinergica integrazione degli stessi mediante l’implementazione del Project Management. In questo articolo descriviamo l’utilizzo di Mda in progetti in cui si sia scelto il Dsdm (Dynamic Systems Development Method), modello Rad (Rapid Application Development) 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 possa inserirsi in maniera totalmente integrata in un contesto progettuale che abbia adottato Prince2, metodologia di Project Management sviluppata e istituita in Uk dall’agenzia governativa Ogc e oggi quella di maggiore successo e diffusione in ambito europeo.
Lo sviluppo del Software:
problemi e inconvenienti
Il processo di sviluppo del software, così come è attuato oggi, è spesso costituito da una progettazione effettuata a livello basso e gran parte dell’enfasi viene data all’attività di codifica.
Un tipico processo (figura 1) è caratterizzato dalle seguenti fasi:
1. Acquisizione requisiti e bisogni
2. Analisi
3. Progettazione dell’architettura
4. Codifica
5. Test
6. Implementazione
Nelle prime tre fasi viene svolta un’intensa attività documentale che deve consentire la corretta definizione di bisogni, parametri, metodologie e architetture per la realizzazione della specifica procedura. Naturalmente le modifiche richieste nella fasi successive saranno prodotte in funzione delle esigenze che si manifesteranno durante le fasi di testing e utilizzo della procedura. Ciò, molto spesso, determina un non allineamento tra le specifiche dettate nella fase di analisi e quelle effettivamente realizzate.
Questo aspetto ha determinato la nascita della filosofia di Estreme Programming che definisce le attività di codifica e testing come quelle di maggiore criticità e produttività. Inoltre i problemi possono aumentare enormemente quando i team di sviluppo cambiano nel tempo e le richieste di modifica si susseguono senza termine. A ciò si aggiunge un aspetto di particolare problematicità: le aziende che operano nel settore del software propongono senza interruzione nuove tecnologie sempre più stabili, flessibili e affidabili, che possono consentire di agevolare e semplificare il lavoro dei programmatori. Prodotti come Java, Xml, Uml, J2ee, Flash sono solo alcune di queste tecnologie. Di conseguenza molte aziende sono portate ad aggiornate sistematicamente le loro piattaforme anche per garantire la scalabilità e l’aggiornamento dei propri sistemi alle nuove tecnologie It.
Nel corso degli anni, questi comportamenti hanno prodotto un nuovo tipo di situazione che ha determinato la nascita del concetto di interoperabilità del software. In buona sostanza, nessun sistema software può operare in condizione di isolamento.
La prima regola di un buon prodotto software è quella di potersi interfacciare con qualsiasi sistema indipendentemente dalla piattaforma hardware/software utilizzata. Pertanto la tendenza che si è consolidata in un meccanismo di riferimento è quella di realizzare prodotti software “basati su componenti” per garantire una maggiore interazione di ambienti e di facilità di manutenzione.
Figura 1
Processo di Sviluppo
del Software secondo la metodologia tradizionale
Cliccare sull’immagine per visualizzarla correttamente
Fonte: Antonio Teti, 2008
Rad: una metodologia
di sviluppo dinamico
La metodologia Rad consente di effettuare lo sviluppo interattivo di programmi e applicazioni mediante l’implementazione di alcuni principi fondamentali:
la possibilità di utilizzare una metodologia interattiva tra fornitore e cliente che può consentire di ridurre i tempi di realizzazione anche fino all’80% dei tempi mediamente richiesti con metodologie diverse;
il coinvolgimento totale e costante dell’utente finale che rappresenta il fattore di successo dell’obiettivo prefissato.
In un approccio tradizionale di tipo “a cascata”, il cliente stabilisce in modo chiaro e completo i suoi bisogni nella fase iniziale del processo di sviluppo, e non sono previsti, se non in casi eccezionali, stravolgimenti dei parametri forniti durante la fase iniziale di analisi. La metodologia Rad consente la “non definizione” di tutte le informazioni utili per la definizione dei fabbisogni del cliente e prevede una serie di implementazioni incrementali per consentire di “aggiornare” il prodotto finale. In altri termini, lo sviluppo del prodotto può svolgersi in maniera “dinamica” agevolando e facilitando la gestione degli errori e delle eventuali esigenze che si manifestassero in momenti successivi. Naturalmente l’interazione tra il cliente e il fornitore deve essere continua e costante e si conclude solo nella fase di consegna del prodotto richiesto. Anche se la metodologia appare elastica e dinamica, i tempi di consegna del prodotto devono essere necessariamente fissati secondo criteri di rigidità e irremovibilità, per garantire una data certa per la conclusione del lavoro richiesto. Tuttavia anche se la metodologia Rad può apparire come la soluzione rapida e vincente per la realizzazione di un’applicazione, è necessario sottolineare alcuni aspetti di particolare criticità:
il concetto di “rapidità” della realizzazione del prodotto rischia di influire sulla qualità del medesimo, determinando, in alcuni casi, anche la non completa fruibilità dell’applicazione;
il rapporto tra il fornitore e il cliente deve essere continuo e deve essere improntato sulla massima chiarezza nella definizione dei bisogni e delle aspettative.
In conclusione in concetto di “tutto e subito” se non è gestito in maniera opportuna, può condurre ad errori enormi che possono riflettersi sulla funzionalità del prodotto e sui rapporti tra cliente e fornitore.
Figura 2
Gli elementi fondamentali di DSDM
Cliccare sull’immagine per visualizzarla correttamente
Fonte: Antonio Teti, 2008
Figura 3
Ciclo di vita di DSDM
Cliccare sull’immagine per visualizzarla correttamente
Fonte: Antonio Teti, 2008
Dsdm: l’applicazione
Delle pratiche migliori
Negli ultimi tempi molteplici riflessioni e dibattiti hanno portato alla conclusione che la metodologia di sviluppo migliore può derivare dall’utilizzo delle pratiche migliori (best practices) che derivano da concrete esperienze effettuate sul campo. Ciò ha determinato la concretizzazione di un nuovo “modus pensandi” che pone l’esperienza concreta, frutto della sperimentazione effettuata dall’utente finale, come riferimento fondamentale per garantire l’efficienza e la qualità dei processi e delle metodologie di management.
L’applicazione di questo concetto ha consentito la nascita e la diffusione di metodologie che potessero consentire il rilascio di prodotti in tempi rapidi ma con un livello qualitativo decisamente superiore. In tal modo è stato realizzato il Dynamic Systems Development Method (Dsdm) che rappresenta la naturale evoluzione del Rad e sta ottenendo successi inaspettati. Non a caso, secondo alcuni studi effettuati su applicazioni pratiche, l’implementazione di Dsdm ha consentito il raggiungimento di un Roi (Return of Investment) del 200%.
Dsdm può essere considerato un “modello strutturale” incentrato sulla qualità e si basa su tre elementi fondamentali (figura 2):
Fase prototipale. Il sistema viene implementato secondo le esigenze e i fabbisogni del cliente. La definizione dei parametri rappresenta quella di maggiore criticità.
Fase di sviluppo e verifiche interattive. I fabbisogni espressi dal cliente possono subire delle variazioni, pertanto si rende necessario predisporre un gruppo di lavoro che intervenga nel momento in cui si manifestino tali necessità e che sia pronto a sopperire alle richieste di modificazioni espresse dal cliente.
Funzionalità e variabilità. Generalmente un qualsiasi progetto include tre parametri su cui focalizzare la propria attenzione: il tempo, le risorse necessarie e la funzionalità. Il modello Dsdm stabilisce che: la funzionalità può essere variabile, mentre il tempo e le risorse richiesti non possono variare in funzione di quanto stabilito nella fase prototipale. Per quanto concerne la funzionalità, viene adottato uno schema meglio identificato come MoSCoW (Must have, Should have, Could have, Won’t have now). In altri termini, vengono assegnate le priorità in funzione delle esigenze che hanno una priorità maggiore.
Dsdm: lo schema di funzionamento
Il modello Dsdm si basa su uno schema di lavoro strutturato in “time-box”. Il time-box è assimilabile a un “contenitore di lavoro” che prevede un intervallo temporale (che può variare in funzione della tipologia di lavoro da realizzare ma che non supera i due mesi) necessario per realizzare una tipologia di prodotto (applicativo, sistema, ecc).
La conclusione del time-box prevede il rilascio del prodotto realizzato che verrà testato dal cliente che lo ha commissionato. Il time-box è strutturato in attività definite che seguono un lifecycle ben definito (figura 3). Ogni attività è strutturata in fasi distinte che definiscono gli obiettivi del progetto, quali sono i contesti temporali (time frame) e quali sono le risorse disponibili. Essi sono:
Studio di fattibilità. È la fase in cui si esaminano gli obiettivi e la congruità del Dsdm per il raggiungimento degli stessi.
Analisi del business. È la fase in cui si chiarisce il contenuto del progetto per consentire la definizione di ambiti e contesti temporali (time frame) oltre che dei time-boxes.
Le fasi che seguono quelle precedentemente descritte sono:
Functional model management. Fase in cui si descrive la funzionalità e gli utilizzi del sistema per garantire il raggiungimento degli obiettivi orientati al business.
Planning management and development. Fase operativa in cui le esigenze e i bisogni vengono tradotti in processi funzionali. Rappresenta la fase operativa in cui si procede anche al testing del sistema implementato.
Implementation. Fase in cui si effettua il passaggio dalla fase di sviluppo a quella di utilizzo del sistema. Sono incluse anche le attività di formazione e addestramento verso gli utilizzatori del sistema. Generalmente un team Dsdm comprende un organico di circa 10 persone (con responsabilità e specialità diverse). Il team è gestito e rappresentato, solitamente, da un Project Manager.
Mda (model driven application): architettura e componenti
Model Driven Architecture (Mda) è una metodologia che consente di realizzare applicazioni software mediante un processo di implementazione di modelli. Mda, mediante regole e standard aperti non proprietari, permette a modelli funzionali, scritti in Uml da business-analyst, senza alcuna competenza sui sistemi informativi, possano creare applicazioni specifiche e complete. Pertanto ai realizzatori non sono richieste competenze Ict in funzione del fatto che il prodotto realizzato potrà funzionare egregiamente indipendentemente dalle piattaforme hardware e software prescelte. Quindi le interfacce funzionali sono indipendenti dalle specifiche tecnologiche e ciò consente di evitare le interazioni tra i programmatori e il personale del settore business. Pertanto i due aspetti nevralgici dell’applicazione (funzionale e strutturale) sono indipendenti e autonomi e ciò rende lo sviluppo delle applicazioni indipendente dalle esigenze del business (figura 4).
Figura 4
Model Driver Architecture
Cliccare sull’immagine per visualizzarla correttamente
Fonte: Antonio Teti, 2008
Ogni volta che sarà necessario, il modello funzionale viene incrociato con lo specifico modello della struttura di riferimento grazie a un generatore di applicazioni che si assumerà l’onere di creare l’applicazione idonea alla gestione dei database.
Mda identifica l’esistenza di due tipi di modelli:
Platform Independent Model (Pim). Modello indipendente dalla piattaforma utilizzata;
Platform Specific Model (Psm). Modello utilizzato specificatamente per la piattaforma.
Entrambi i modelli sono descritti nel linguaggio Uml, attualmente unico linguaggio per metamodelli usato dai produttori di strumenti di modellazione.
La possibilità di realizzare dei modelli funzionali (che si innestano in modelli strutturati hardware/software) consente di lavorare in maniera più efficiente permettendo agli utilizzatori di concentrarsi maggiormente su aspetti legati al business. Inoltre gli strumenti Mda consentono anche di sincronizzare tra loro i diversi modelli permettendo l’integrazione automatica dei dati.
Uso di mda in sviluppi dsdm
Grazie a queste peculiarità in termini di flessibilità e indipendenza, gli strumenti che si basano su Mda possono garantire elevati livelli di produttività ed efficienza. Pertanto Dsdm, essendo basato su Mda, è per sua natura strutturato in modo tale da consentire di definire dei modelli su cui viene basata l’infrastruttura di base dell’applicazione finale.
È importante sottolineare che uno strumento basato su Mda può consentire di suddividere il progetto principale in sub-progetti gestibili da workgroup indipendenti che lavorano interagendo tra loro solo su alcuni aspetti del progetto. Tale frazionamento dei progetti viene gestito in una fase definita “Business Analysis”. In figura 5 viene evidenziata la corrispondenza tra le varie fasi previste da Dsdm e le corrispondenti fasi e attività previste da Mda.
Figura 5
Confronto DSDM E MDA
Cliccare sull’immagine per visualizzarla correttamente
Fonte: Antonio Teti, 2008
Conclusioni
La maggiore delle peculiarità di Mda risiede nella sua estrema flessibilità e quindi si adatta perfettamente per tutti i contesti di sviluppo in cui prevale la massima agilità di realizzazione di applicazioni, pur preservando la massima attenzione sulla qualità del prodotto finale offerto, a differenza dei primi strumenti Rad. Adottando Dsdm quale modello di sviluppo per il proprio progetto è poi logico scegliere uno strumento basato su Mda. Nel contempo risulta fondamentale anche misurare l’efficacia delle scelte metodologiche fatte nella fase di progettazione rivolgendo particolare attenzione alla fase di Project Management. Uno dei modelli di gestione del Project management è sicuramente Prince2, che negli ultimi anni sta assumendo una diffusione sempre maggiore.
*Antonio Teti è Responsabile dell’I.C.T.S. – Information and Communication Technology Service – Università degli Studi “G. d’Annunzio” di Chieti – Pescara
