Archive for the ‘Life Cycle Process’ Tag

Agile e Model Driven Engineering

Pubblicato il 27/06/2009 da Stefano Cazzella in Software

Ogni progetto avrebbe bisogno di una fase di inizializzazione in cui pianificare le risorse necessarie, selezionare le tecnologie e le metodologie, ecc.; fra queste scelte riveste un ruolo non secondario anche il modello di sviluppo da adottare.

L’esperienza personale e le letture (frutto dell’esperienza altrui) possono aiutare ad impostare correttamente tale aspetto cruciale di ogni progetto.

Bibliografia

(continua…)

 

Meta Data Warehouse

Pubblicato il 30/10/2006 da Stefano Cazzella in Business Intelligence,Metadata Management

Dal 30 ottobre al 2 novembre si terrà a Londra la consueta Data Management and Information Quality Conference. La new entry dell’anno è una track dedicata ai temi di Data Warehousing e Business Intelligence. Scorrendo le presentazioni degli interventi di maggior rilievo in merito alla gestione dei metadati mi sono reso conto che il focus è tutto incentrato su come costruire, alimentare e gestire un un repository centralizzato dei metadati in cui vengano integrati i metadati prodotti durante il ciclo di sviluppo del sistema. Tale integrazione viene condotta tipicamente “a posteriori” ossia, nel migliore dei casi, al termine di ciascuna fase di un’iterazione progettuale.

Questo è il medesimo approccio che ho seguito nel disegnare la metodologia su cui si basa il sistema di gestione dei metadati realizzato nell’ambito del Data Warehouse della RGS. Tale sistema è costituito da prodotti commerciali e componenti software scritte ad-hoc al fine di ricostruire una “visione integrata, omogenea e strutturata” del sistema di data warehousing nel suo complesso. Tale esperienza è riassunta in un documento (in versione DRAFT) che ho preparato a valle del processo di certificazione del sistema di data warehousing condotto da Bill Inmon anche in seguito all’interesse e agli apprezzamenti che la componente di gestione dei metadati ha suscitato in tale sede.

Architettura a repository centralizzato Il mercato dei prodotti commerciali in ambito data warehouse è pressoché allineato nel seguire tale approccio generale che prevede la generazione dei metadati relativi alle diverse componenti in maniera pressoché indipendente e scorrelata. In particolare i diversi tool (case di modellazione dati, ETL, front-end, ecc.) utilizzati per la produzione delle diverse componenti del sistema (base dati, processi di alimentazione, reposrtistica, ecc.) hanno un proprio repository di metadati che descrive la componente prodotta; un sistema di gestione dei metadati interroga ciascun repository (attraverso delle API, tramite una sua rappresentazione in XML, ecc.) per estrarre una versione dei metadati da integrare nel proprio repository.

Un repository integrato dei metadati offre una serie di servizi ritenuti fondamentali sia per migliorare la qualità del servizio offerto agli utenti del sistema,sia per suportare la gestione del sistema stesso:

  • offrire all’utente indicazioni sul significato delle informazioni numeriche fornite attraverso la reposrtistica o gli ambienti di analisi multi-dimensionale (OLAP);
  • aiutare gli utenti a trovare le informazioni di cui hanno bisogno con sistemi di ricerca guidata;
  • suportare le attività di manutenzione attraverso le funzioni di cross-impact-analysis;
  • monitorare l’esito dei caricamenti e la crescita del sistema;
  • ecc.

Spesso però la qualità complessiva del sistema risulta scarsamente influenzata da una gestione dei metadati “a posteriori”; infatti l’integrazione “a posteriori” dei metadati può al limite evidenziare incongruenze fra il disegno delle diverse componenti, fra l’analisi e la progettazione delle stesse o fra la progettazione e lo sviluppo, ma non intervenendo attivamente nel processo produttivo, non migliora la qualità del prodotto.

Processo di integrazione “a priori”

Innovare il processo produttivo vuol dire innovare tanto le metodologie quanto gli strumenti di lavoro. Dal punto di vista metodologico il processo produttivo dovrebbe essere basato sul continuo riuso dei metadati: ogni attività dovrebbe arricchire i metadati del sistema integrando quanto già realizzato con nuove informazioni. Ad esempio la modellazione logica di un Data Mart dovrebbe partire dalla definizione del suo modello dimensionale arricchendolo con “i dettagli” utili alla sua implementazione in tecnologia ROLAP o MOLAP. Analogamente i metadati del medesimo modello dimensionale e della sua implementazione logico/fisica dovrebbero essere utilizzati nella definizione dello strato semantico attraverso cui gli utenti si interfacceranno e condurranno le proprie analisi OLAP.

Tale integrazione “a priori” dei metadati garantisce nel corso del processo produttivo una maggiore coerenza fra le componenti software realizzate. Inoltre, poiché il processo produttivo parte proprio dalla raccolta e formalizzazione dei requisiti e dall’analisi del patrimonio informativo e procede con l’integrazione dei metadati relativi agli aspetti progettuali e realizzativi del sistema, le probabilità che i requisiti utente siano sodisfatti aumentano. Si accorciano inoltre i ritardi nel rilevare problemi di incoerenza fra analisi e progettazione, progettazione e realizzazione o soddisfacibilità di requisiti.

Dal punto di vista degli stumenti software per la realizzazione di data warehouse, ad oggi non mi risulta che esista alcun tool in grado di seguire tutto il processo di analisi, progettazione e realizzazione di un sistema di Data Warehousing in modo integrato. Inoltre non sono molti i tool di front-end e back-end i cui repository di metadati siano aperti anche “in scrittura”, come avviene ad esempio per i cataloghi dei DBMS che vengono manipolati con linguaggi ormai standardizzati (DDL – Data Definition Language). Tuttavia il processo di integrazione dei diversi strumenti in suite tecnologiche può essere una spinta verso la realizzazione di un processo di questo tipo, purché l’integrazione non rimanga puramente commericale e ci sia una reale attenzione a coprire l’intero ciclo produttivo (mentre spesso fasi cruciali come l’analisi e la formalizzazione dei requisiti sono sottovalutate).