Contract
|
|
|
|
|
Progettazione e Realizzazione del Sistema Informativo Unitario Regionale per la Programmazione, Gestione e Monitoraggio degli Investimenti Pubblici e relativi servizi di assistenza |
||||
Disegno del SIURP
Progetto: |
SIURP |
Cliente: |
Regione Calabria |
Protocollo: |
N/A |
Redatto da: |
Xxxxx Xx Xxxxx, Xxxxxxx Xxxxxxx |
Verificato da |
Comitato di Coordinamento |
Data di Emissione: |
3 Marzo 2015 |
Consegnato a: |
Xxx. Xxxxxx Xxxxxx |
Versione: |
5.0 |
Nome documento: |
ChQEXl3QUu3.doc |
REVISIONI
Versione |
Motivo |
Data |
Responsabile Progetto |
1.0 |
Bozza |
21/01/2010 |
Xxxxxxx Xxxxxxxxxx |
2.0 |
Prima Emissione |
05/03/2010 |
Xxxxxxx Xxxxxxxxxx |
3.0 |
Rivisto a seguito Osservazioni del DEC |
08/04/2010 |
Xxxxxxx Xxxxxxxxxx |
4.0 |
Aggiornato in seguito ad ulteriori osservazioni dell’Amministrazione |
29/04/2010 |
Xxxxxxx Xxxxxxxxxx |
4.1 |
Nuovo modulo Monitoraggio Controlli |
31/07/2014 |
Xxxxxxx Xxxxxxxxxx |
5.0 |
Aggiornamento infrastruttura |
13/03/2015 |
Xxxxxxx Xxxxxxxxxx |
Sommario
3.2 Schema architettura funzionale 14
3.3 Struttura di navigazione 20
Principi generali di navigazione 21
4.1 Schema architettura applicativa 37
4.4 Componente Programmazione 41
Modello Organizzativo di riferimento 41
Relazione con altre componenti 42
4.5 Componente Procedure ad Evidenza Pubblica 42
Modello Organizzativo di riferimento 43
Relazione con altre componenti 44
4.6 Componente Gestione Interventi 45
Modello Organizzativo di riferimento 45
Relazione con altre componenti 46
4.7 Componente Monitoraggio Controlli 46
Modello Organizzativo di riferimento 47
Relazione con altre componenti 47
4.8 Componente Anagrafica Ausiliaria 47
Modello Organizzativo di riferimento 48
Relazione con altre componenti 48
4.9 Componente Cruscotto Direzionale 49
4.10 Componente System Reporting 50
4.11 Componente Document Management 50
Relazione con altre componenti 50
4.12 Componente Esb / Flow Engine 50
4.13 Componente Integrazione Sistemi Esterni 51
4.14 Componente Gestione Servizi CMS 51
5.2 Schema architettura esecutiva 56
Sistema SSO e Profilazione Utenti 58
1Introduzione al documento
1.1Scopo del documento
Il Sistema Informativo Unitario Regionale per la Gestione e il Monitoraggio degli Investimenti Pubblici, d’ora in poi SIURP, definisce un’infrastruttura che permette un’organizzazione razionale del processo di gestione e monitoraggio degli investimenti pubblici e dei servizi da mettere a disposizione delle diverse tipologie di utenza.
Il presente documento ha l'obiettivo di fornire una visione completa del sistema in realizzazione, articolata in quattro sezioni:
nella prima, Architettura Funzionale, verrà descritto l’insieme di funzioni che la soluzione deve fornire, descrivendo le stesse dal punto di vista dell’utente finale;
nella seconda, Componenti / Architettura Applicativa, verrà descritto l’insieme di moduli che implementano le funzioni individuate nella prima sezione dal punto di vista architetturale;
nella terza, Architettura Esecutiva si descriverà la piattaforma tecnologica su cui la soluzione verrà implementata, in termini di soluzioni applicative preconfezionate, frameworks, software di base e design patterns scelti;
nella quarta, Architettura Fisica si descriverà l’ambiente hardware.
Il presente documento non può considerarsi esaustivo per il livello di dettaglio di informazioni che vengono trattate e a questo scopo si rimanda ai documenti di analisi funzionale che verranno prodotti in accordo con quanto previsto dal Piano di Lavoro. Di seguito si riporta l’elenco dei suddetti documenti:
SIURP_WEB_AFUN_AnalisiFunzionaleWebSite.doc
SIURP_AUX_AFUN_AnalisiFunzionaleAUX.doc
SIURP_PEP_AFUN_AnalisiFunzionaleProcedureAdEvidenzaPubblica.doc
SIURP_GIN_AFUN_AnalisiFunzionaleGestioneInterventi.doc
SIURP_PRG_AFUN_AnalisiFunzionaleProgrammazione.doc
SIURP_INT_AFUN_AnalisiFunzionaleIntegrazioneAltriSistemi.doc
SIURP_ATEC_GEN_CanonicalDataModel.doc
SIURP_ATEC_GEN_ModelloLogicoDati.doc
SIURP_CRD_AFUN_CruscottoDirezionale.doc
SIURP_MC_AFUN_AnalisiFunzionaleMonitoraggioControlli.doc
1.2Riferimenti
Titolo documento |
Descrizione |
2_allegato_capitolato_tecnico_siurp_rc3.pdf |
Capitolato tecnico |
2.1_appendice_a_capitolato_tecnico_siurp-v1.0-rc3.pdf |
Appendice al capitolato tecnico – Processi di Business |
2.2_ar-cal-01-scp_appendice_b_capitolato_tecnico_siurp_rc3.pdf |
Appendice al capitolato tecnico – Requisiti di sistema |
SIURP_Regione_Calabria_Offerta_Tecnica.pdf |
Offerta Tecnica |
ChQEXl3QUu3.doc |
Analisi dei processi della Regione Calabria Piano di qualità |
|
|
1.3Termini e definizioni
Sigla/Termini/Definizioni |
Descrizione |
SIURP |
Sistema Informativo Unitario Regionale per la Gestione e il Monitoraggio degli Investimenti Pubblici |
POR |
Programma Operativo Regionale |
ESB |
Enterprise Service Bus |
DM |
Document Management |
CMS |
Content Management System |
PEP |
Procedura ad Evidenza Pubblica |
CRD |
Cruscotto Direzionale |
PRG |
Programmazione |
GIN |
Gestione Interventi |
REP |
Sistema di reporting |
AUX BDU SIT CUP PA SOA |
Anagrafica Ausiliaria e Profilatore Banca Dati Unificata Sistema Informativo Territoriale Codice Unico di Progetto Pubblica Amministrazione Service Oriented Architecture |
MC |
Monitoraggio Controlli |
2Obiettivi
2.1Contesto
In coerenza con le linee programmatiche di unificazione della politica regionale aggiuntiva per il periodo 2007 – 2013, delineate nel Quadro Strategico Nazionale, la Regione Calabria ha deciso di destinare parte delle risorse per la progettazione e l’implementazione del nuovo Sistema Informativo Unitario Regionale per la Gestione e il Monitoraggio degli Investimenti Pubblici, SIURP.
Tale sistema ha l’obiettivo di supportare l’amministrazione in tutte le fasi di programmazione, istruzione, attuazione e rendicontazione degli investimenti pubblici, in modo da fornire una visione integrata dell’attuazione delle politiche e al fine di valutare la valenza della strategia dell’impianto programmatico.
2.2Descrizione del sistema
Il SIURP rappresenta lo strumento destinato a realizzare i seguenti macro obiettivi:
consentire la visione integrata di dati per la politica regionale unitaria, contribuendo così a migliorare il sistema di programmazione e gestione delle risorse FAS, dei fondi strutturali e degli investimenti regionali,
controllare gli investimenti pubblici rispetto a quanto programmato assicurando trasparenza ed evidenza delle attività realizzate e l’incremento dell'efficacia dell'azione amministrativa attraverso la disponibilità diffusa dei dati sugli investimenti da parte del RUP e di tutti gli attori coinvolti negli investimenti stessi.
Offrire uno strumento concreto per la gestione di tutte le procedure ad evidenza pubblica.
Supportare l’Amministrazione nel colloquio con i sistemi nazionali e regionali.
Migliorare la trasparenza dei processi amministrativi verso i Cittadini.
Lo schema riportato di seguito fornisce una visione d’insieme del modello logico-concettuale del nuovo sistema.
Figura 1 Schema logico del sistema
2.3Requisiti
Il presente paragrafo, in conformità con quanto descritto nel Piano Qualità in merito ai processi di controllo e tracciatura dei requisiti, illustra in sintesi i requisiti generali del sistema.
Si rimanda ai documenti di analisi funzionale dei componenti applicativi per una tracciatura puntuale dei relativi requisiti.
Si riportano di seguito i requisiti generali del sistema SIURP.
Si specifica che i requisiti riportanti all’interno del codice il simbolo ‘#’ fanno riferimento all’appendice B del Capitolato Tecnico (Rif. 2.2_ar-cal-01-scp_appendice_b_capitolato_tecnico_siurp_rc3.pdf), mentre quelli che riportano il simbolo ‘$’ si riferiscono all’Offerta Tecnica e a quelli desunti dall’analisi tecnica di tutta la documentazione di gara.
-
Requisito funzionale
Area GEN – generale
Codice requisito
Il sistema deve, per ciascun progetto/operazione afferente il ciclo della programmazione 2007-2013, supportare le “piste di controllo” della Regione Calabria relative alle fasi di programmazione, selezione, attuazione e certificazione, con riferimento alle tipologie dei
macro-processi definiti dall’IGRUE e implementando anche i controlli su tempi e soggetti correlati alle verifiche.GEN#010
Il sistema deve colloquiare con la Banca Dati Unificata consentendo la trasmissione dei dati di monitoraggio e rendicontazione in conformità al Protocollo di Colloquio e il Protocollo Applicativo, nelle versioni aggiornate rilasciate dall’IGRUE
GEN#015
Il sistema deve consentire l’inserimento e la modifica e aggiornamento dei dati di avanzamento dei progetti/operazioni tramite accesso web al sistema.
GEN#020
Il sistema deve gestire il flusso di lavoro tra attori del sistema e attori (umani o sistemi) esterni al sistema
GEN#025
La gestione dei flussi di lavoro deve essere indipendente dalla logica di business del sistema tramite un componente di workflow engine
GEN#030
Il sistema deve consentire l’aggiornamento/modifica/ eliminazione dei dati solo agli utenti specificamente abilitati
GEN#035
Il sistema deve tenere traccia di tutte le operazioni che vengono effettuate su di esso, identificandole in maniera univoca. Le operazioni e i dati ad essa connesse sono archiviate in appositi registri accessibili dai singoli componenti, in funzione dell’operazione o del processo specifico
GEN#040
Parte delle attività relative ai processi di business devono
essere supportate da specifiche check-list che, in particolare, devono prevedere: il controllo sui documenti a supporto delle verifiche, il controllo sui tempi associati alle verifiche, il controllo sui soggetti correlati alle verifiche, la propedeuticità/obbligatorietà delle verifiche. Le check-list dovranno essere personalizzate in base alla titolarità e tipologia dell’operazione (regia/titolarità; opere pubbliche/ acquisizione di beni e servizi/ erogazione di contributi/ formazione), ed in base all’attività che deve essere espletata.GEN#045
Nel caso in cui ad un’attività sia associata un check-list, il sistema non deve consentire l’espletamento della fase in assenza della compilazione della check-list
GEN#050
Il sistema deve consentire l’allineamento, automatico (con periodicità stabilita o in funzione di eventi predefiniti) o a richiesta, con il sistema della contabilità regionale
GEN#055
Il sistema deve colloquiare con il sistema di protocollo Informatico regionale per la protocollazione di tutti i documenti in uscita/entrata da/verso l’Amministrazione regionale
GEN#060
Il sistema deve colloquiare con il sistema per l’assegnazione del numero di repertorio dell’Amministrazione per tutti gli atti/ documenti che vengono trasmessi all’interno dell’Amministrazione Regionale tra diversi Dipartimenti/ Settori/ Servizi
GEN#065
Il sistema deve prevedere l’interazione con i sistemi di firma digitale utilizzati dall’Amministrazione in tutti i casi in cui sia prevista la trasmissione di documenti tra i diversi utenti del sistema salvo indicazione in senso contrario da parte dell’Amministrazione.
GEN#070
Il sistema deve sempre effettuare un controllo formale sui dati inseriti.
GEN#075
Il sistema dovrà offrire un supporto alla produzione di documenti relativi ai processi interni (verbali/rapporti di vario genere)
GEN$005
3Architettura funzionale
3.1Premessa
Il SIURP ha come obiettivo la realizzazione di un nuovo sistema informativo regionale integrato per la programmazione, la gestione e il monitoraggio degli investimenti pubblici della Regione Calabria, gestiti con le seguenti fonti di finanziamento:
FAS 2007/2013 e relative premialità
POR FESR 2007/2013
POR FSE 2007/2013
Il disegno architetturale del SIURP e gli strumenti a suo supporto garantiscono le eventuali evoluzioni funzionali in risposta a nuove fonti di finanziamento che l’Amministrazione intenderà gestire.
Il ciclo di vita all’interno del quale vengono svolte le attività di programmazione e monitoraggio degli investimenti pubblici può essere rappresentato attraverso uno schema del tipo:
Figura 2 Ciclo di vita dei processi
In accordo con quanto descritto nel documento di dettaglio di analisi dei processi, i macro-flussi che regolano lo svolgersi di tali attività sono:
Processo di programmazione
Processo di gestione delle procedure di selezione
Processo di avanzamento delle operazioni
Processo di certificazione della spesa
Processo di gestione delle irregolarità e dei recuperi/revoche
Processo di audit
L’architettura funzionale del sistema informativo SIURP deriva da un’accurata analisi di tali processi ed ha l’obiettivo di fornire concreto supporto per le attività che ne derivano.
3.2Schema architettura funzionale
La soluzione proposta è logicamente articolata in macroaree funzionali e la figura seguente ne illustra lo schema a blocchi. In tale schema l’ architettura è suddivisa in aree omogenee, denominati sottosistemi: Sottosistema Portale; Sottosistema Gestione Contenuti; Sottosistema Gestione Sicurezza; Sottosistema Cruscotto Operativo.
Figura 3 Schema a blocchi del Siurp
Nello specifico:
Il sottosistema Portale raggruppa le funzioni che supportano la comunicazione con gli utenti e rappresenta il punto di accesso alle risorse. E’ il web site pubblico che valorizza e promuove le informazioni relative ai programmi cofinanziati e alle operazioni realizzate, informa i cittadini e rende pubblici i dati relativi ai programmi ed ai progetti in carico alla Regione ;
Il sottosistema gestione contenuti, ovvero il Content Management System, contempla tutte le funzioni che servono a rendere fruibile il patrimonio informativo, creato aggregando le informazioni provenienti dalle varie fonti informative;
Il sottosistema per la gestione della sicurezza governa le policies di sicurezza che permettono il riconoscimento degli utenti e la gestione delle autorizzazioni all’accesso alle risorse erogate attraverso il sistema Siurp. Esso fornisce:
funzioni per censire gli utenti abilitati a servizi protetti (Accounting)
funzioni per il riconoscimento in base alle credenziali presentate (Autenticazione),
funzioni che profilano i servizi accessibili a fronte del riconoscimento (Abilitazioni),
Il Cruscotto Operativo offre funzionalità di notifica, quali il completamento delle attività richieste sulla contabilità, l’avvenuto completamento/inizio delle attività da parte di altri attori del sistema, l’avanzamento degli iter sui progetti/selezioni in lavorazione, la richiesta di informazioni/supporto da altri attori del sistema; costituisce inoltre il punto di accesso alle componenti applicative, alle quali è demandata la gestione delle funzionalità di relativa competenza:
Programmazione
Procedure ad evidenza pubblica
Gestione interventi
Monitoraggio Controlli
System Reporting
Cruscotto Direzionale
L’architettura funzionale sopra rappresentata può essere illustrata secondo una suddivisione a servizi, in base alla seguente tipologia di aggregazione:
Servizi Informativi
Servizi Interattivi
Servizi di Utilità
Al fine di rendere più agevole la lettura del documento, si riporta, qui di seguito, la mappa del sistema:
Figura 4 Mappa di navigazione
Il sistema Siurp è dunque suddiviso in macro-aree principali, ognuna delle quali ospita le diverse funzionalità previste, suddivise in base alla tipologia di utente fruitore. I paragrafi seguenti illustrano tale suddivisione e presentano le relative specifiche operative in termini di strutture di navigazione e di progettazione grafica.
Servizi informativi
Con servizi informativi si indicano tutti quei servizi che presentano funzionalità di ricerca e consultazione. Tra questi troviamo ad esempio le aree di presentazione news ed eventi, il servizio di ricerca avanzata su bandi, operazioni e beneficiari finali e di produzione dei relativi report.
In riferimento alle modalità di accesso ai singoli servizi (anonimo, registrato, censito §4.3 “Target Di Utenza”), per linee generali, le sezioni informative offriranno una consultazione libera, che non richiede esplicitamente il riconoscimento dell’utente per consentire la fruizione dei contenuti.
Servizi interattivi
Con servizi interattivi si indicano quei servizi che presentano funzionalità che richiedono interazione diretta con l’utente.
Appartengono questa area i servizi di front end come la community e collaboration (forum, wiki, rss, calendar), i servizi di back end che espongono le funzionalità specifiche della parte gestionale del sistema, ad esempio gestione delle procedure ad evidenza pubblica, gestione interventi.
In riferimento alle modalità di accesso ai singoli servizi (anonimo, registrato, censito §4.3 “Target Di Utenza”), per linee generali, le sezioni interattive richiedono l’identificazione di un utente che sia registrato al sistema. In particolare, per alcuni di essi, saranno richieste, oltre che la registrazione, anche specifiche abilitazioni.
Servizi di utilità
Con servizi di utilità si indicano quei servizi che forniscono supporto agli utenti. Appartengono a questa area il servizio di consultazione della documentazione messa a disposizione dall’amministrazione, la navigazione tra i link utili ed il servizio di autoregistrazione al portale.
In riferimento alle modalità di accesso ai singoli servizi (anonimo, registrato, censito §4.3 “Target Di Utenza”), per linee generali, le sezioni informative offriranno una consultazione libera, che non richiede esplicitamente il riconoscimento dell’utente per consentire la fruizione dei contenuti.
3.3Struttura di navigazione
Secondo una suddivisione ormai standard de facto e dunque ben recepita dagli utenti dei portali informativi, l’organizzazione della struttura proposta per il sistema Siurp rispetta un criterio di suddivisione “verticale”, tesa a distinguere nettamente le aree ed i servizi ad accesso pubblico da quelli ad accesso privato.
Questa scelta offre alcuni innegabili benefici:
“nascondendo” ai diversi profili di utenza la complessità dell’intera struttura dei servizi, si facilita la navigazione e la memorizzazione da parte dell’utente del paradigma di navigazione proposto dal sistema, migliorando la cosiddetta user-experience e la confidenza nell’uso dell’interfaccia grafica e dei diversi elementi grafici;
si facilita il compito della Redazione, in quanto offre un’organizzazione di primo livello dei contenuti ed individua le principali aree e modalità di pubblicazione previste per i contenuti predisposti dalla Redazione.
Tale paradigma di navigazione potrà facilitare ulteriormente la user-experience delle diverse tipologie di utenza del portale soprattutto nel tempo, al crescere dei contenuti (che in portali di questo tipo, generalmente è abbastanza sostenuto e costante), in quanto l’utente avrà già familiarizzato con la possibilità di “navigazione tematica” dei contenuti, e disporrà di una semplice ed intuitiva opzione di filtro dei contenuti/servizi del portale.
Principi generali di navigazione
Il paragrafo definisce alcune delle linee guida di carattere generale poste a base dell’ipotesi di interfaccia utente proposta per il sistema SIURP. Tali linee guida sono via via cresciute con l’evoluzione delle modalità di fruizione di Internet da parte dell’utenza mondiale, dei contenuti e dei metodi di rappresentazione proposti e, non ultimo, con i progressi tecnologici compiuti sul fronte delle tecnologie legate al Web, sino ad evolvere in veri e propri standard de facto della progettazione di siti e applicazioni basati su tecnologia Web.
L’interazione fondamentale dell’utente con un’applicazione web based consiste nel “cliccare” link ipertestuali per muoversi all’interno di uno spazio informativo, spesso costituito da centinaia di pagine. Dal momento che lo spazio è così vasto, la navigazione potrebbe risultare difficile ed è sempre preferibile perciò fornire un aiuto per visualizzare la posizione dell’utente e mostrare i possibili movimenti rispetto alla struttura dello spazio informativo soggiacente. Tale scelta si pone anche nell’ottica di voler rispettare le due regole fondamentali riguardo alla struttura di un sito:
la struttura deve riflettere il modello che l’utente ha del sito, delle informazioni e dei servizi offerti;
la struttura dovrebbe derivare dalle operazioni che gli utenti vi devono eseguire, anche se ciò significa che in una singola pagina devono comparire informazioni provenienti da settori/contesti diversi.
Nell’ambito della struttura, tipicamente sono due le tipologie applicabili:
struttura gerarchica, dove le informazioni sono più dettagliate mano a mano che si scende di livello;
struttura tabellare, dove le pagine sono classificate sulla base di alcuni attributi o parametri. In questo modo l’utente può trovare tutte le pagine relative ad un determinato argomento.
La struttura proposta per il SIURP è una combinazione delle due: prevedendo una struttura tabellare per aggregare tutte le informazioni e le funzioni relative alle aree di lavoro ed ai servizi offerti ed una struttura gerarchica per la navigazione all’interno delle stesse.
Un altro elemento da tenere in considerazione, per la definizione del paradigma di navigazione del sistema informativo, è quello relativo all’ampiezza/profondità.
Il primo approccio (ampiezza) ha il vantaggio di rammentare in ogni momento agli utenti l’intero spettro di scelte disponibili e consiste nell’elencare per esteso le sezioni del livello superiore del sito.
Il secondo approccio (profondità) consiste nel mostrare l’intero percorso gerarchico dalla homepage alla pagina attuale, attraverso tutti i livelli intermedi. In questo modo gli utenti hanno una visione completa della loro posizione rispetto alla struttura del sito.
Una soluzione valida è seguire un approccio misto ampiezza/profondità, mostrando molti livelli della gerarchia di navigazione (profondità) e per ciascuno di essi elencare le varie sezioni disponibili (ampiezza). Lo svantaggio di questa tecnica è che può occupare molto spazio sull’interfaccia grafica, dovendo presentare in ogni momento della navigazione la struttura completa del sistema.
Tuttavia, usando alcuni accorgimenti tecnici, si potrebbe dare visibilità permanente a tutti i livelli (profondità) e far comparire temporaneamente le sezioni alternative (ampiezza) del solo livello selezionato dall’utente, utilizzando a tal scopo il componente “Menu”, in modo da non impegnare in modo permanente lo spazio a disposizione sul layout di interfaccia grafica ipotizzato.
Come immaginabile, le combinazioni possibili sono molteplici e ciascuna con vantaggi e svantaggi valutabili con criteri oggettivi ma comunque influenzati dalla soggettività di percezione degli elementi dell’interfaccia (disposizione, dimensioni, colori, controlli attivi, ecc.).
In ogni caso, l’obiettivo a cui si deve comunque tendere è costruire interfacce di navigazione che aiutino gli utenti a trovare le risposte a tre domande fondamentali, che devono guidare il processo di progettazione e realizzazione di un’interfaccia utente:
dove mi trovo ?
dove sono stato ?
dove posso andare ?
La posizione dell’utente deve essere mostrata in relazione alla struttura del sito; le indicazioni, in tal senso, possono venire fornite mostrando una parte dell’alberatura ed evidenziando l’area alla quale appartiene la pagina che si sta visualizzando.
Progetto grafico
Il progetto grafico proposto per il sistema informativo Siurp presenta una struttura classica a colonne con caratterizzazioni di colore studiate per garantire una chiara identificazione delle aree tematiche principali, pur mantenendo un’unità di stile che garantisca una facile consultazione.
Nella sua struttura di base la pagina è ripartita in tre colonne (la home page e le prime pagine delle aree principali) o in due colonne (schema adottato principalmente per le pagine di dettaglio e di approfondimento dei contenuti).
Il progetto di seguito proposto, oltre a soddisfare i requisiti posti dalle diverse tipologie di contenuto trattate e dalle esigenze di comunicazione del Portale, in relazione alle tipologie di utenza previste, tiene conto anche delle possibilità tecniche offerte dall’adozione di un’architettura di presentazione su Web basata su una soluzione concettualmente analoga a quanto implementato dai Portal Server compatibili con le specifiche JSR168, che introducono il concetto di portlet.
In sintesi, una portlet è un componente web che definisce e gestice dinamicamente l’interazione di pubblicazione di una o più classi di contenuto del Portale. Ogni portlet, dunque, definisce le caratteristiche dell’interfaccia di pubblicazione di un dato insieme di contenuti, e offre i controlli per poter interagire con i servizi che operano sui contenuti gestiti. Le singole portlet, elaborate da uno specifico Portlet Engine, “cooperano” alla composizione dell’interfaccia utente del sistema, mantenendo tuttavia precipue caratteristiche di configurabilità e di interazione con gli altri componenti dell’architettura.
Analogamente, la soluzione adottata per il Siurp, prevede la definizioni di singoli componenti specializzati per la composizione delle pagine di interfaccia del sistema, la cui esecuzione viene coordinata da un unico oggetto che offre, così come il Portlet Engine, un ambiente di esecuzione omogeneo e controllato.
Tale paradigma di progettazione offre l’opportunità di organizzare e suddividere ciascuna zona dell’interfaccia, a sua volta, in sotto-zone (definite in un apposito template) ognuna con le proprie caratteristiche di pubblicazione dei contenuti offerti. La combinazione di tali componenti “elementari” del sistema dà luogo alla formazione dell’interfaccia di pubblicazione, da intendersi come “insieme coordinato ed omogeneo” di componenti specializzati di interfaccia, in analogia all’architettura basata su portlet.
Di seguito si propone l’applicazione del progetto grafico fin qui descritto alle tre viste di base che caratterizzano il sistema Siurp:
la home page del web site pubblico;
Il cruscotto operativo;
la componente applicativa;
Figura 5 Home Page Siurp
Figura 6 Il cruscotto operativo
Figura 7 Pagina principale componente applicativa
L’interfaccia presenta i seguenti elementi fissi di navigazione ed identificazione, comuni a tutte le viste proposte:
Testata
Barra di navigazione (sotto la testata)
Menu principale (colonna sinistra)
Contenuti (parte centrale)
Spalla (colonna destra)
Footer (barra di chiusura)
Nel seguito, si illustrano caratteristiche e finalità degli elementi di interfaccia sopra citati.
La Testata
La testata è un elemento fisso del sistema ed destinata a contenere il banner del Siurp e i loghi istituzionali, quali ad esempio lo stemma della Regione Calabria e quello dell’Unione Europea.
Figura 8 Testata – da modificare
La Barra di Navigazione
Vista web site pubblico
Nel caso di accesso anonimo al portale Siurp, questo elemento offre, sotto forma di tasti, i collegamenti ai servizi informativi erogati dal portale (§ “Servizi Informativi”). Facilita l’uso e la memorizzazione della struttura dei contenuti e dei servizi offerti dal Portale, classificati secondo l’area informativa di interesse.
Figura 9 Barra di navigazione - servizi informativi
Vista Cruscotto Operativo
Nel caso in cui un utente effettui una autenticazione al sistema, su questa barra saranno abilitati i tasti per l’accesso ai servizi interattivi (§ “Servizi Interattivi”), in funzione delle abilitazioni possedute
Figura 10 Barra di navigazione - servizi interattivi
Si noti che l’utilizzo di un elemento fisso dell’interfaccia per la selezione di una specifica area di interesse, semplifica anche l’interazione con il sistema da parte delle diverse tipologie di utenza previste, possibilmente interessate a conoscere ed a fruire di informazioni e servizi strettamente connessi ad una specifica area tematica, e non all’intero parco di iniziative ed informazioni gestite dal sistema Siurp.
Vista componente applicativa
Una volta selezionato uno specifico elemento della Barra di navigazione, il Portale presenterà la pagina iniziale della specifica area selezionata. In questo caso la barra di navigazione conterrà i collegamenti alle funzionalità specifica della singola componente, in funzione delle abilitazioni possedute.
Figura 11 Barra di navigazione - componente applicativa
Il Menu Principale
Contiene i collegamenti a tutti i servizi di utilità (§ “Servizi di utilità”) a disposizione dell’utente, in funzione delle abilitazioni possedute. I collegamenti sono raggruppati per categorie, rappresentate sotto forma di schema ad albero.
Figura 12 Menu di sinistra
L’Area Contenuti
Costituisce l’area di massimo rilievo per il fruitore del Portale, in quanto è la zona dell’interfaccia destinata ad ospitare le informazioni di dettaglio e le mappe di interazione dei servizi offerti dal sistema.
E’ dunque la zona a più alta “variabilità”, sia in termini di contenuti (per definizione) sia in termini di disposizione dei contenuti a video.
In particolare, con riferimento agli schemi previsti per l’interfaccia grafica del Siurp, l’area Contenuti occupa sempre la zona centrale dell’interfaccia, come nel caso degli schemi a tre colonne, estendendosi sino al limite del margine destro, nel caso delle pagine a due colonne.
Tuttavia, tale organizzazione del layout non va considerata come una definizione statica in quanto, proprio per le molteplici “destinazioni d’uso” dell’area, questa dovrà essere duttile e prestarsi ad una organizzazione specifica dei contenuti, in funzione dei singoli servizi previsti.
Le ipotesi di esempio allegate costituiscono, dunque, solo alcune delle possibili layout che si potranno organizzare in questo componente dell’interfaccia utente del Portale.
Si propongono di seguito, esclusivamente a titolo esemplificativo, alcune possibili interfacce. Si rimanda ai documenti di analisi funzionale di dettaglio per la progettazione grafica dei mockup relativi alle singole componenti applicative, i cui documenti di riferimento sono indicati in premessa.
Vista web site pubblico
Figura 13 Area contenuti portale
Vista cruscotto operativo
Figura 14 Area contenuti cruscotto operativo vista beneficiario
Figura 15 Area contenuti cruscotto operativo vista autorità di gestione
La Spalla
Come il componente Menu, ospita principalmente collegamenti a funzioni e servizi a disposizione dell’utente ma presenta collegamenti a contenuti in evidenza e più contestualizzati rispetto al percorso di navigazione ed all’area tematica di appartenenza dei contenuti/servizi richiesti dall’utente.
Figura 16 La spalla
Il Footer
E’ l’elemento che graficamente delimita l’estensione in verticale dell’interfaccia grafica del Portale.
Racchiude collegamenti ad informazioni e contatti di carattere generale del Portale, visualizzati ed attivabili dall’utente da qualsiasi livello.
I Fogli di Stile
Per impostare il layout di impaginazione, i colori di sfondo, i caratteri, le caratteristiche dei link, ecc., senza alterare o predefinire la posizione degli oggetti o dei contenuti nelle varie pagine è prevista la realizzazione di appositi fogli di stile, secondo lo standard CSS v.2.0 (Cascading Style Sheets).
Il vantaggio principale dei fogli di stile è assicurare la continuità visiva di un sito durante la navigazione, garantendone al contempo una manutenzione semplice e tempestiva in termini di modifiche/innovazione dell’interfaccia grafica.
E’ previsto l’utilizzo di un unico foglio di stile per tutto il sito, o in generale si tenderà a limitarne il numero ad un ristretto insieme, nel caso si abbiano pagine con necessità di presentazione notevolmente differenziate.
Affinché tale soluzione funzioni, è necessario non utilizzare alcun tag di presentazione nelle pagine da impostare poiché, in caso contrario, le impostazioni definite dai tag di formattazione presenti nelle pagine HTML prevalgono sugli stili definiti dai CSS.
Sempre nell’ottica di mantenere l’unità stilistica del sito e di semplificare gli interventi di manutenzione correttiva/evolutiva, saranno prodotti sempre fogli di stile connessi (cioè mantenuti in file separati, a cui ciascuna pagina fa riferimento). Tale accorgimento, in oltre, sfruttando le tecniche di caching offerte ormai dalla totalità dei browser oggi utilizzati, renderà le pagine del Portale anche più snelle e veloci da scaricare.
4Componenti Software
4.1Premessa
L’architettura funzionale descritta nei precedenti paragrafi, si traduce in una architettura applicativa a componenti, nella quale ciascun modulo software presenta un’identità funzionale univoca e implementa le funzioni caratterizzanti i diversi sottosistemi logici.
Nei successivi paragrafi si fornirà una breve descrizione di ogni modulo, in termini di funzionalità offerte e interfacce esposte; tuttavia si rimanda all’analisi e progettazione di dettaglio per informazioni che si possano considerare esaustive, i cui documenti di riferimento sono indicati in premessa.
Allo stesso modo, per ciascun componente verrà presentato il modello organizzativo di riferimento ed il processo di business intercettato, per i cui dettagli si rimanda al documento di analisi dei processi specifico.
Si riporta di seguito il Component Diagram, in standard UML 2.1, che fornisce una rappresentazione dell’ architettura applicativa proposta. Per quanto concerne l’esplicitazione delle relazioni tra le componenti si precisa che esse saranno oggetto di analisi funzionale dei singoli moduli.
4.2Schema architettura applicativa
Figura 17 Component Diagram
Nello schema proposto sono state rappresentate tutte le componenti che costituiscono il sistema Siurp:
ll web site pubblico (§4.4)
Il package Cruscotto Operativo, al cui interno troviamo le singole componenti applicative:
Programmazione – PRG (§4.5);
Procedure ad Evidenza Pubblica – PEP (§4.4);
Gestione Interventi – GIN (§4.7);
System Reporting – REP (§4.11);
Gestione e amministrazione dei servizi CMS (§4.15);
Cruscotto Direzionale – CRD (§4.10);
Monitoraggio Controlli – MC (§4.8)
Il componente ESB / Flow Engine (§4.13);
Il modulo di Anagrafica Ausiliaria – AUX (§4.9);
Il Document Management (§4.12).
Il diagramma contiene inoltre al suo interno un componente, denominato INT (§4.14), che ha lo scopo di rappresentare l’integrazione della piattaforma Siurp con i sistemi esterni, nazionali e regionali.
4.3Target di utenza
Scopo del presente paragrafo è fornire una macro-tassonomia al fine di esaminare il target di utenza potenziale a cui sono indirizzati i diversi servizi messi a disposizione.
Sarà oggetto dei documenti di analisi funzionale di dettaglio, identificare i profili specifici a cui sono destinate le singole funzionalità di ciascuna componente applicativa.
Il suddetto target può essere suddiviso nella maniera seguente:
utenti anonimi, in questa classe rientrano gli utenti che accedono ai servizi informativi e di utilità: questa utenza non ha bisogno di effettuare autenticazione ed è abilitata ad accedere solo a risorse pubbliche;
utenti registrati, in questa classe rientrano gli utenti che hanno effettuato una auto registrazione al portale Siurp e che dunque accedono ai servizi interattivi di front-end. E’ necessario effettuare un’autenticazione per accedere a tali servizi riservati.
utenti censiti, in questa classe rientrano gli utenti che sono formalmente autorizzati all’uso del sistema Siurp e pertanto sono abilitati all’accesso delle componenti gestionali tramite le funzioni amministrative del componente di anagrafica ausiliaria AUX .
In fase di start up dei sistemi il componente AUX sarà popolato con i dati relativi alle utenze provenienti dall’attuale sistema Rendiconta, importati secondo le modalità che saranno specificate nel Piano di Transizione dei Sistemi.
4.4Componente Portale
L’obiettivo principale del sito web pubblico è fornire la massima diffusione delle caratteristiche e delle opportunità offerte dalla programmazione integrata 2007-2013.
Il portale SIURP offre le seguenti tipologie di servizi di front-end:
Informativi (§ “Servizi Informativi”)
Accesso a contenuti informativi (news, eventi, ecc)
Consultazione di avvisi, bandi, interventi finanziari
Ecc
Interattivi (§ “Servizi Interattivi”)
Servizi di community
Invio domande di partecipazione a bandi (se previsto dalla tipologia di bando)
Ecc
Di Utilità (§ “Servizi di utilità”)
Registrazione al portale
Consultazione documentazione
Ecc
In accordo con le leggi in materia di trasparenza e di diritto di accesso ai documenti amministrativi, i servizi informativi e di utilità saranno ad accesso pubblico.
Essi consentiranno a tutti i cittadini non solo di effettuare ricerche avanzate secondo svariati criteri, ma anche di produrre schede sintetiche e reports stampabili.
Per recuperare le informazioni relative a bandi, avvisi e interventi finanziati, il portale SIURP dovrà colloquiare con i moduli Gestione Interventi e Procedure ad Evidenza Pubblica.
Per quanto riguarda i servizi interattivi, essi saranno ad accesso riservato e dunque sarà necessaria una fase di registrazione e di autenticazione, nel caso di utenti non censiti nel sistema.
4.5Componente Programmazione
Il modulo supporta tutte quelle attività che vanno dall’approvazione del programma operativo fino alla predisposizione delle procedure necessarie alla corretta attuazione delle operazioni (criteri di selezione). Rientrano inoltre in tale componente le funzionalità a supporto della definizione del documento di attuazione, l’individuazione di progetti integrati/grandi progetti e l’individuazione di operazioni. Sono infine incluse in tale modulo le attività di definizione del piano finanziario e delle piste di controllo a supporto dei processi operativi.
Modello Organizzativo di riferimento
Vengono di seguito indicati gli organismi regionali coinvolti a vario titolo nei processi di business implementati all’interno del componente, tuttavia si rimanda al documento di analisi dei processi per una descrizione più accurata:
Giunta Regionale;
Consiglio Regionale.
Autorità di Gestione;
Nucleo Regionale di Valutazione;
Comitato di Coordinamento;
Comitato di Sorveglianza;
Responsabile di Linea/ Settore/Asse;
Dirigente Generale di Dipartimento;
Dipartimento Bilancio – Settore Ragioneria;
Organismo Intermedio
Processi di business
I processi di business che troveranno realizzazione nel componente di Programmazione sono:
Definizione POR;
Definizione PAR;
Definizione Criteri di Selezione;
Definizione Xx.Xx.Xx.;
Definizione del documento di Attuazione;
Approvazione Grandi Progetti;
Attivazione PISR/PISL/PISU;
Riprogrammazione
Relazione con altre componenti
Si riporta un elenco indicativo delle interfacce che il componente renderà disponibili:
Interrogazione piste di controllo;
Interrogazione dei criteri di selezione.
Saranno inoltre attivati meccanismi di comunicazione con i sistemi di bilancio e contabilità e gestione documentale previsti nel SIAR.
4.6Componente Procedure ad Evidenza Pubblica
Il componente per la gestione delle procedure ad evidenza pubblica supporta l’Amministrazione Regionale nelle attività relative alle fasi di attuazione della programmazione, l’obiettivo principale è automatizzare, tramite flussi dinamici, le attività del processo di gestione degli avvisi pubblici e dei bandi di gara.
Secondo quanto fin qui analizzato, per quanto riguarda la ricezione delle domande, il sistema prevede l’acquisizione delle stesse mediante tre modalità:
Cartacea e caricata sul sistema dall’utente interno all’amministrazione;
Inoltrata dal cittadino ed acquisita dal sistema via web;
Inoltrata sia via web che in forma cartacea
Il sistema rende disponibile l’associazione della modalità di ricezione a seconda della tipologia di bando/avviso messa in atto.
Parte dei dati relativi al bando/avviso, di interesse pubblico, saranno fruibili dai cittadini attraverso il portale SIURP, mediante appositi servizi informativi.
I dati relativi ai progetti aggiudicati, ove presenti, saranno automaticamente disponibili nel modulo di Gestione degli Interventi, che sarà di supporto per l’attuazione degli stessi.
Modello Organizzativo di riferimento
Vengono di seguito indicati gli organismi regionali coinvolti a vario titolo nei processi di business implementati all’interno del componente, tuttavia si rimanda al documento di analisi dei processi per una descrizione più accurata:
Ufficio Controlli di I livello;
Comitato di Sorveglianza;
Giunta Regionale;
Dirigente di settore;
Comitato di Coordinamento;
Dirigente Generale di Dipartimento;
Dipartimento Bilancio – Settore Ragioneria;
Responsabile linea di intervento;
Autorità di audit;
Autorità di certificazione;
Segretariato;
Responsabile di asse;
Commissione di valutazione;
Responsabile del procedimento amministrativo;
Processi di business
I processi di business che troveranno realizzazione nel componente Procedure ad Evidenza Pubblica sono:
Piani di settore e procedure negoziali;
Selezione
Attuazione della selezione
Relazione con altre componenti
Si riporta un elenco indicativo delle interfacce che il componente renderà disponibili:
Interrogazione anagrafica bando;
Ricerca bando per criterio;
Salva anagrafica bando.
Saranno inoltre attivati meccanismi di comunicazione con i seguenti sistemi esterni (§4.14):
SIAR – Protocollo informatico
SIAR – Contabilità regionale
SIAR - Sistema documentale
SIAR – Sistema gestione decreti e delibere
Banca Dati Esperti
Banca Dati Anagrafica
CUP
4.7Componente Gestione Interventi
Il modulo supporta tutte le attività previste nella fase di attuazione degli interventi, dalla registrazione degli estremi identificativi alla rendicontazione delle spese fino alla chiusura delle operazioni. Si riportano, a titolo esemplificativo, alcune delle funzionalità che il componente dovrà realizzare:
Inizializzazione e classificazione dell’intervento;
Definizione del piano finanziario;
Registrazione dei dati sui tre assi fondamentali del monitoraggio: fisico, finanziario e procedurale;
Supporto alle attività di monitoraggio e Autorità di Audit;
Gestione delle irregolarità;
Gestione del flusso di certificazione della spesa.
Modello Organizzativo di riferimento
Vengono di seguito indicati gli organismi regionali coinvolti a vario titolo nei processi di business implementati all’interno del componente, tuttavia si rimanda al documento di definizione dei processi per una descrizione più accurata:
Autorità di Gestione;
Autorità di Certificazione;
Autorità di Audit;
Ufficio Controlli di I livello;
Responsabile di Linea/ Settore/Asse;
Responsabile di Monitoraggio;
Dirigente Generale di Dipartimento;
Dipartimento Bilancio – Settore Ragioneria;
Dipartimento Bilancio – Xxxxxxx Xxxxxxxx;
Organismo Intermedio
Beneficiario Finale
Processi di business
I processi di business che troveranno realizzazione nel componente Gestione Interventi sono:
Attuazione (Titolarità/Regia);
Certificazione della Spese e generazione della domanda di pagamento;
Irregolarità e recuperi/revoche;
Audit di Sistema;
Audit delle operazioni;
Monitoraggio
Relazione con altre componenti
Si riporta un elenco indicativo delle interfacce che il componente renderà disponibili:
creazione intervento;
interrogazione interventi per bando;
interrogazione interventi per criterio di ricerca.
Saranno inoltre attivati meccanismi di comunicazione con i sistemi di bilancio e contabilità e gestione documentale previsti nel SIAR oltre che con sistemi esterni al dominio Regione Calabria allo scopo, ad esempio, di trasmettere i dati di monitoraggio e certificazione, richiedere e acquisire il codice CUP.
4.8Componente Monitoraggio Controlli
Il modulo supporta tutte le attività previste nella fase di controllo di primo livello sugli interventi e sulle procedure di attivazione. Si riportano, a titolo esemplificativo, alcune delle funzionalità che il componente dovrà realizzare:
Controlli di primo livello desk;
Controlli di precertificazione;
Controlli in loco
Modello Organizzativo di riferimento
Vengono di seguito indicati gli organismi regionali coinvolti a vario titolo nei processi di business implementati all’interno del componente, tuttavia si rimanda al documento di definizione dei processi per una descrizione più accurata:
Ufficio Controlli di I livello;
Unità di controllo dipartimentale.
Processi di business
I processi di business che troveranno realizzazione nel componente Monitoraggio Controlli sono:
Controlli di I livello;
Relazione con altre componenti
Si riporta un elenco indicativo delle interfacce che il componente renderà disponibili:
Attivazione controllo desk;
Definizione criticità.
4.9Componente Anagrafica Ausiliaria
Il modulo di anagrafica ausiliaria raggruppa le funzionalità da realizzare per soddisfare i requisiti relativi a:
gestione dei destinatari dei pagamenti, che si esplicita in : trattamento delle informazioni anagrafiche dei soggetti e delle eventuali sospensioni e gestione dei raggruppamenti dei soggetti, utili nelle fasi di liquidazione degli importi;
censimento degli utenti del sistema, in termini di gestione delle informazioni anagrafiche e attribuzione delle credenziali di accesso;
gestione delle autorizzazioni all’utilizzo delle risorse da parte degli utenti (profilo di accesso). Ogni utente censito sul sistema sarà caratterizzato da:
profilo (secondo quanto rilevato nel capitolato di gara e nell’analisi dei processi);
unità organizzativa di riferimento;
responsabilità su uno specifico elemento di articolazione del programma (es. linea di intervento FESR o obiettivo specifico FSE);
abilitazione (full/read-only) alle specifiche aree e funzioni realizzate nell’ambito dei vari moduli.
gestione delle informazioni oggetto di autorizzazione (profilazione del sistema), ad esempio censimento delle unità organizzative, delle funzioni, ecc.
Il componente riveste un ruolo centrale all’interno di SIURP: tutti i moduli si dovranno interfacciare con esso allo scopo di consentire l’accesso ai servizi in maniera opportuna, previa verifica delle autorizzazioni assegnate all’utente.
Modello Organizzativo di riferimento
Vengono di seguito indicati i profili abilitati all’utilizzo delle funzionalità realizzate nel componente:
Amministratore di Sistema;
Responsabile delle operazioni (RLI – Beneficiario Finale – Organismo intermedio – Soggetto Attuatore);
Relazione con altre componenti
Si riporta un elenco indicativo delle interfacce che il componente renderà disponibili:
creazione utente;
assegnazione profilo utente;
acquisizione profilo utente;
creazione beneficiario dell’intervento;
interrogazione beneficiario dell’intervento.
Saranno inoltre attivati meccanismi di comunicazione con il sistema di Gestione della Sicurezza del SIAR, allo scopo di rendere allineate le anagrafiche dei beneficiari e degli utenti con quelle presenti nei sottosistemi di contabilità e personale.
4.10Componente Cruscotto Direzionale
Questa componente offre strumenti per la reportistica ad alto livello, l’analisi multidimensionale (OLAP) e l’interrogazione libera e diretta del proprio dominio dati. A questi servizi, affianca moduli analitici per la gestione dei processi collaborativi, per il calcolo dei KPI (Key Performance Indicators) e per la rappresentazione dei dati su supporto geografico (Location Intelligence).
Il modulo ha lo scopo di offrire una visione globale dell’insieme dei dati gestiti, secondo modalità tipiche di un sistema di analisi multidimensionale. Le funzionalità sono attivate sui dati consolidati, opportunamente adattati rispetto ai dati operativi per meglio rispondere alle esigenze di interrogazione e di rappresentazione statistica. Su tali dati possono essere definiti differenti prospetti di analisi, che consentono di evidenziare determinati fatti d’interesse, quali ad esempio:
quadro finanziario degli interventi per fondo/linea d’intervento piuttosto che per provincia o tipologia;
avanzamento dei pagamenti rispetto a quanto previsto;
aree/capitoli per i quali risultano criticità (scarsa quantità di spesa, frequenti revoche di finanziamento);
elevati tempi di completamento di un processo (process mining).
Per maggiori dettagli si rimanda al documento SIURP_CRD_AFUN_CruscottoDirezionale.doc.
4.11Componente System Reporting
Gli obiettivi principali del modulo
di reporting sono essenzialmente la generazione di elaborati (in
formato pdf, xls, csv, ecc) che supportino l’utente nelle normali
attività operative (es. elenco
bandi per obiettivo in Procedure
ad Evidenza Pubblica o elenco interventi per beneficiario in Gestione
Interventi) e nelle fasi di generazione e trasmissione dei dati di
monitoraggio all’IGRUE.
4.12Componente Document Management
E’ il componente documentale di supporto ai moduli applicativi di Programmazione, Gestione Interventi e Procedure ad evidenza pubblica che consente la definizione di un fascicolo elettronico, nel quale confluiscono sia i documenti prodotti dal sistema a partire da templates predefiniti che quelli creati successivamente dagli utenti del sistema.
Relazione con altre componenti
Si riporta un elenco indicativo delle interfacce che il componente renderà disponibili:
creazione nuovo documento;
assegnazione permessi;
checkin documento;
checkout documento;
4.13Componente Esb / Flow Engine
Il componente di ESB e Flow Engine centralizza le funzionalità di supporto alla comunicazione tra i componenti del SIURP ed i sistemi esterni (rif. Componente Integrazione Sistemi Esterni4.14). Consente, infatti, di esporre i servizi applicativi tramite un’unica interfaccia, garantendo una visione unica ed integrata di tutte le componenti del sistema.
Al suo interno possono essere distinti tre diversi livelli:
Il Motore di orchestrazione / BPMN per pubblicare e orchestrare i servizi del sistema informativo
Il Monitoring che permette ai responsabili della gestione dei processi di controllare singole istanze (anche correlate), identificare problemi, identificare valori rilevanti, gestire la ripartenza
L’ ESB che consente l’interscambio informativo, offre funzionalità di comunicazione e servizi di base (routing, trasformazione, schedulazione, validazione,..)
4.14Componente Integrazione Sistemi Esterni
Il sistema informativo Siurp, come già detto in precedenza, prevede una integrazione con sistemi nazionali e regionali, esistenti ed in corso di realizzazione, quali (l’elenco è da intendersi non esaustivo):
Il SIAR, per quanto concerne il protocollo informatico, il sistema documentale, gestione decreti e delibere, il sistema anagrafico dipendenti ed il sistema di contabilità regionale;
La BDU per la trasmissione dei dati di attuazione delle operazioni all’IGRUE;
Equitalia, per effettuare eventuali controlli di “morosità”;
Il Sistema Informativo Territoriale SIT per consentire l’esposizione, sul territorio calabrese, dei dati di programmazione ed attuazione degli interventi;
Il CUP per l’acquisizione dei dati utilizzati per la creazione del codice unico di progetto nel sistema ministeriale;
BDA
4.15Componente Gestione Servizi CMS
Il componente consente di gestire le sezioni del portale che offrono contenuti di tipo informativo. In questo modulo sono raggruppate tutte le funzioni che supportano:
la creazione dei contenuti;
la messa in linea dei contenuti;
la presentazione dei contenuti.
Tutti i contenuti, di qualsiasi tipo essi siano, seguono un ciclo di vita costituito da alcuni passi principali che possiamo così riassumere:
redazione;
approvazione;
messa in linea
manutenzione
Anche se tale tali passi risultano eseguiti in modalità diverse a seconda del tipo di contenuto, nell’area applicativa riservata alla Redazione sono a disposizione tutte le funzionalità destinate a supportare tale ciclo di vita.
5Architettura Esecutiva
5.1Requisiti
Si riportano di seguito i requisiti non funzionali dell’architettura esecutiva del sistema SIURP
-
Requisito non funzionale
Area GEN – generale
Xxxxxx requisito
Il sistema deve consentire, con un unico profilo di accesso, la gestione dell’intero ciclo dei progetti/operazioni a valere sui finanziamenti comunitari e nazionali
GEN#005
Il sistema, per la parte RDBMS, dovrà basarsi su tecnologia PostgreSQL
GEN$001
Il sistema di autenticazione (Jasig CAS) dovrà supportare sia l’autenticazione con userid/password che con i certificati digitali
GEN$004
Il sistema di autenticazione dovrà integrarsi il repository utenti dell’amministrazione per la verifica delle credenziali e sarà basato su sistema LDAP
GEN$006
Il sistema di autenticazione dovrà supportare meccanismi di Single Sign On (SSO), permettendo all’utente di autenticarsi una volta e di poter accedere a tutti i servizi web correttamente integrati con il sistema per mezzo di meccanismi di scambio di ticket di autenticazione
GEN$007
Il sistema di accounting sarà costituito dall’integrazione di un prodotto open source per il logging ed il tracciamento delle operazioni che potrà essere integrato nei vari sistemi sviluppati al fine di andare ad alimentare un repository centralizzato di informazioni.
GEN$008
Il Front-end deve essere web based ed accessibile tramite i più diffusi browser web
GEN#1300
Il Front-end dovrebbe evitare di prevedere l’utilizzo di plug-in da installare nei software di navigazione, ad ogni modo non è ammesso l’utilizzo di plug-in dipendenti dalla piattaforma client.
GEN#1305
Al fine di garantire migliori livelli di interazione tra l’utente e l’applicazione, le interfacce utente devono essere realizzate utilizzando tecnologie AJAX realizzando la comunicazione tra i componenti di interfaccia ed i servizi di Back-End, siano essi web service o pagine dinamiche, secondo la notazione JSON o lo standard XML
GEN#1310
Il Front-end, se sviluppato su piattaforma Java, dovrà utilizzare le specifiche JSR 168/286, in ogni caso dovrà supportare lo standard WSRP
GEN#1315
Il Front-end per l’interfaccia utente dovrà essere utilizzato lo standard XHTML per la struttura ed il CSS per il layout delle pagine
GEN#1320
L’interfaccia utente del sistema dovrà comunque conformarsi alle leggi ed i regolamenti nazionali in materia di accessibilità.
GEN##1325
Requisito non funzionale
Area CRD - cruscotto direzionale
Codice requisito
Il cruscotto sarà realizzato sulla piattaforma SpagoBI
CRD$302
Requisito non funzionale
Area WEB – web site pubblico
Codice requisito
Il portale dovrà essere realizzato utilizzando l’infrastruttura open source Liferay Portal
WEB$506
Requisito non funzionale
Area ESB – sistema ESB
Codice requisito
Il sistema dovrà gestire l’orchestrazione dei processi tra i diversi componenti ed essere quindi dotato di un motore di orchestrazione.
ESB#1005
La configurazione dovrà essere basata su interfacce grafiche minimizzando gli interventi su codice
ESB#1015
Il sistema dovrà essere il più possibile basato su standard
ESB#1020
Il sub componente di orchestrazione deve essere supportato da strumenti grafici basati su BPMN che generino, in modalità Model Driven (guidata dai modelli), la configurazione dell’orchestrazione (processi).
ESB#1025
Il sistema dovrà consentire l’interscambio informativo in più modalità, dalla cooperazione applicativa basata sullo standard SPCoop a meccanismi più snelli quali Web service e produzione di flussi su tracciato standard
ESB$401
Il sistema dovrà essere in grado di fornire ad ogni utilizzatore una visione unica ed integrata di tutte le componenti
ESB$402
Il sistema dovrà fornire funzionalità di comunicazione, servizi di base (routing, trasformazione, schedulazione, validazione,..), orchestrazione/BPM e supporto verso tutti gli attori coinvolti nel ciclo di vita della soluzione (progettazione funzionale e tecnica, sviluppo, monitoraggi e gestione)
ESB$403
Il sistema dovrà supportare i due standard principali alla base del funzionamento delle architetture a servizi: UDDI (tramite JUDDI) ed ebXML (tramite freeEBXML
ESB$404
Il registry dei servizi dovrà essere basato sullo standard UDDI 3
ESB#1100
Il sistema dovrà essere utilizzato sia a design-time che a run-time;
ESB#1105
5.2Schema architettura esecutiva
L’architettura applicativa della soluzione proposta è stata disegnata con un forte orientamento ai servizi, in accordo con i principi fondamentali dell’architettura SOA (service-oriented architecture) per garantire il continuo allineamento all’evoluzione normativa e alle diverse funzioni applicative richieste dalle dinamiche organizzative della Regione Calabria.
Lo strumento software risulta:
conforme al modello web/internet: è server centrico con l’utilizzo di client leggero.
completamente aperto e compatibile con gli standard tecnologici e di riferimento di mercato (XML, J2EE, Web Services, W3C);
scalabile e distribuito su 3 livelli elaborativi distinti nel rispetto dei design pattern di riferimento quali, ad esempio, il Model-View-Controller (MVC), Page Controller, ecc.
Lo schema seguente rappresenta le componenti dell’architettura applicativa che compongono il sistema di SIURP.
Figura 18 Architettura Applicativa
Tutti i componenti presenti nello schema precedente sono esaminati in dettaglio nel prosieguo del documento.
In particolare, il dettaglio architetturale dei singoli layers, di ciascuna componente applicativa J2EE è descritto nella tabella che segue:
Figura 19 Dettaglio layers applicativi
Gli applicativi vengono successivamente integrati nel Portal Server (Liferay) mediante l’utilizzo di una portlet, consentendo così la condivisione della sessione http del portale web.
Sistema SSO e Profilazione Utenti
Il sistema di SSO è realizzato mediante il CAS Server JA-SIG Central Authentication Service.
La fase di autenticazione e autorizzazione dell’utente del portale seguirà le fasi descritte in seguito:
Il client web richiede una pagina presente nel backend di SIURP;
Il web server ridireziona la richiesta verso il server CAS;
Il client web si interfaccia con CAS mediante la pagina di login inviando a CAS la username e la password dell’utente;
Se le credenziali sono corrette CAS restituisce al client web un ticket e un coockie di sessione;
Il client richiede nuovamente la pagina del backend inviando anche il ticket che ha restituito CAS;
L’applicativo che contiene la pagina richiesta chiede al server CAS di validare il ticket;
il server CAS conferma la validità del ticket
L’utente viene riconosciuto;
Viene richiesto il profilo dell’utente;
Viene restituito il profilo utente;
Viene inoltrata la richiesta dell’utente della pagina del backend da visualizzare all’application server
Viene visualizzata la pagina sul client web dell’utente.
I passi descritti sono schematizzati nella figura di seguito.
Figura 20 Autenticazione e profilazione utente
La profilazione delle utenze è affidata ad un profiler denominato AUX che interagisce con CAS per la gestione delle utenze e restituisce la profilatura dell’utente all’interno del portale e dei vari applicativi presenti nel portale.
La scelta di progettazione di un applicativo del backend si basa sui seguenti 4 layers:
Presentazione o Client Tier
Applicazione o Web Tier
Logica di business o Business Tier
Persistenza o EIS (Enterprise Information Systems)Tier.
Presentation Layer
Il framework di base utilizzato per la costruzione delle interfacce utente (UI) è JavaServer Faces (JSF 2.0). La tecnologia JSF nasce a completamento della Java Enterprise Edition (J2EE).
Se J2EE è noto essere una piattaforma matura, solida e affidabile, per applicazioni enterprise, una delle critiche più comuni che le si rivolgono è sempre stata la mancanza di un modello di riferimento per lo sviluppo dell'interfaccia utente.
C
Figura 21 Lifecycle JSF
Lo standard JSF prevede un ampio insieme di classi e relative API che oltre a definire i componenti dell’interfaccia utente (UI), permette anche di gestire il mantenimento del relativo stato e il verificarsi dei relativi eventi.
In breve, i componenti che mette a disposizione JSF sono:
Gestione degli eventi: che servono a gestire le azioni e i comportamenti dell'applicazione;
Componenti predefiniti: che possono essere richiamati nelle pagine Web dell'applicazione;
Componenti di validazione: che ci permettono di validare i dati nei form.
JSF inoltre permette di:
semplificare il sistema di gestione della navigazione tra le pagine della web application;
realizzare dei componenti personalizzati (Custom Component), che estendano e potenzino le funzionalità delle classi base del framework;
inglobare i concetti di internazionalizzazione e di accessibilità dell'applicazione.
utilizzare l’EL (Expression Language) per la realizzazione del value-binding e il method-binding, mediante i quali è possibile legare le proprietà dei componenti della UI direttamente con la business logic;
elaborare le richieste seguendo uno specifico ciclo di vita suddiviso in una serie di fasi; questo garantisce un livello di controllo delle richieste molto dettagliato, in ogni istante è possibile sapere lo stato delle variabili che intercorrono;
utilizzare i backing beans (managed beans) costituenti la business logic, con la possibilità di istanziarli in un qualsiasi momento on demand.
Il sistema di gestione delle viste relative alle interfacce utente, meglio conosciuto come View Handler, rappresenta l’infrastruttura tecnologica attraverso cui le varie componenti JSF vengono erogate. Il framework utilizzato per implementare tale livello logico è Faceletes. Facelets introduce all’interno dell’architettura tecnologica del sistema una serie di vantaggi quali:
Templating - possibilità di creare delle sezioni comuni che possono essere facilmente riutilizzate e mantenute.
Composition components
Custom logic tags
Expression functions
Designer-friendly page development – creare delle pagine che siano la base per un design armonico delle varie componenti, in modo da garantire usabilità e fruibilità dei contenuti.
Creating component libraries
Il framework JSF che verrà utilizzato all’interno degli applicativi SIURP è Icefaces, questo framework, basato sulle specifiche JSF.
Icefaces è un framework per lo sviluppo e la distribuzione di applicazioni Ajax-J2EE e client RIA (Rich Internet Application). Le applicazioni sono sviluppate in puro Java secondo il modello thin-client, e non è necessario utilizzare plugins di browser proprietari o sviluppare applet ad-hoc.
Icefaces utilizza JSF (Java Server Faces) come standard per la scrittura delle pagine web.
Uno dei suoi punti di forza è l’utilizzo della tecnologia Ajax Push, che permette l’aggiornamento automatico del browser allo scatenarsi di eventi sul server.
Si possono avere così attività di interazione fra più browser-client permettendo l’aggiornamento in tempo reale delle informazioni.
Il funzionamento dell’Ajax Push è mostrato nella seguente figura:
Figura 22 Ajax Push
Come si evince, questo meccanismo permette di inviare al browser, in modo asincrono, blocchi di pagina (DOM Changes) che contengono solo le informazioni necessarie all’aggiornamento dei dati. Questo può essere fatto, sia a partire da una richiesta scatenata dal browser, che da eventi occorsi sul server. Sarà comunque garantito, come previsto dal Capitolato, il rispetto della legge vigente in materia di accessibilità.
Service Layer
Il framework utilizzato per la gestione della parte dei servizi è Spring. Le caratteristiche di base di Spring sono:
Spring è completo e modulare. Ha un architettura a layer che ci permette di scegliere solo quello che serve del framework senza dover per forza fare una scelta del tipo "o tutto o niente".
Spring è semplice. Spring utilizza puri e semplici POJO, ovvero normali classi Java. Non impone quindi l’implementazione di astruse interfacce ne’ vincola ad esso il proprio codice applicativo. È semplice da testare a differenza di quanto accade con molti framework a componenti.
Xxxxxx è disegnato in modo da imporre le minime dipendenze alla propria applicazione.
Spring è leggero ma fornisce tutti i servizi necessari a una applicazione enterprise.
Spring impone uno stesso stile architetturale a diverse aree di sviluppo.
Il layer di servizi di una applicazione enterprise comprende la gestione di vari aspetti, ad esempio:
Gestione delle transazioni.
Gestione dell’interoperabilità verso altri applicativi.
Gestione della sicurezza;
Gestione del flusso dei dati;
Gestione del flusso (workflow) dell’applicativo.
Il pattern di base sul quale è costruito Spring è l’inversion of control (IoC) ossia la possibilità di istanziare gli oggetti solo nel momento in cui vengono invocati. L’IoC di spring si basa sulla Dependency Injection (DI), la dependency injection delega al container di spring la gestione delle relazioni tra i diversi oggetti dell’applicativo. Questo significa che è possibile sviluppare il sistema utilizzando dei semplici POJO, dotati di opportuni costruttori e metodi setter, senza doversi preoccupare delle dipendenze con altri oggetti. Sarà il container mediante la setter injection o la constructor injection a costruire tutte le dipendenze necessarie.
Con Spring verrà gestito:
DAO.
Transazioni su db.
Web Services.
Classi di interfacciamento con il sistema di workflow
Gestione dell’autenticazione e della profilatura
La logica di business interna ad ogni applicativo sarà orientata ai processi, questo permette di gestire le interazioni all’interno e all’esterno degli applicativi mediante un workflow. Un processo rappresenta ciò che deve accadere all'interno del sistema durante un processo di business o una procedura e può essere composta da un insieme di sotto-processi. Ciascun processo e sotto-processo è composto, a sua volta, da un insieme di attività. Ogni attività è un singolo step logico all'interno del processo.
Un workflow esegue attività automatiche; la definizione di un processo, invece, descrive tutte le attività sia automatiche sia manuali.
La definizione di un processo (cosa debba essere fatto, in che ordine e da chi) viene formalizzata in termini di:
Stato (nodo): Uno stato all'interno di un processo specifica una dipendenza rispetto ad un attore esterno. A runtime questo comporta che il motore di workflow deve attendere fino a quando un attore esterno notifica che l'esecuzione è stata portata a termine.
Azione: Un'azione è la logica applicativa che deve essere eseguita dal motore di workflow in seguito al presentarsi di un evento specifico. I flussi di esecuzione concorrenti sono modellati con fork e join, mentre i flussi di esecuzione esclusivi sono modellati con merge e punti di decisione.
Transizioni: rappresentano lo spostamento del processo da uno stato ad un altro attraverso l'applicazione di una predeterminata azione.
Process Context: è il contesto del processo gestito dal workflow.
Il sistema di workflow verrà implementato utilizzando Spagic workflow che permette l’esecuzione di workflow jBPM. L’utilizzo di spagic workflow permette una definizione visuale di un processo attraverso lo Spagic Studio, che a partire dal disegno del processo genererà un file xml di definizione del processo secondo lo standard jBPM. La definizione di un processo mediante Spagic workflow può essere fatta mediante le seguenti componenti:
Elemento di Start: entry point del flusso.
Elemento di End: end del flusso.
Task :rappresenta l’esecuzione di una operazione o di un sotto-processo.
Split Element: permette la divisione di più task che possono essere eseguiti contemporaneamente.
Join Element: indica che bisogna eseguire almeno uno dei task splittati prima di passare al task successivo
Ad un task può essere assegnato un permesso legato alla profilatura degli utenti e una action ad esempio l’invio di una email al completamento del task oppure dell’intero processo.
Per ogni workflow definito mediante Spagic è possibile monitorare lo stato del processo attraverso la spagic console che permette il monitoring visuale del processo, indicando con il colore verde i task eseguiti e con il colore giallo i task avviati ma non ancora completati.
Figura 23 Spagic monitoring
Oltre al sistema di workflow degli applicativi, a Spagic verrà demandato anche la gestione dell’interfacciamento delle interazioni degli applicativi esterni verso il SIURP e delle interazioni del SIURP verso gli applicativi esterni.
In questo modo sempre attraverso l’ambiente integrato di spagic sarà possibile gestire e definire dei processi distribuiti da e verso il sistema SIURP, mediante l’orchestratore di processi presente in spagic.
Per poter garantire l’indipendenza dalla tecnologia dei sistemi per i quali si deve gestire l’interscambio informativo, per ogni servizio implementato è prevista la definizione di un Canonical Data Model che sarà realizzato attraverso schemi XSD. Tutti i servizi esposti dal SIURP sull'ESB presenteranno un'interfaccia WSDL le cui operazioni faranno riferimento a questo Canonical Data Model.
Eventuali attività di armonizzazione dal Canonical Data Model verso i formati dati specifici di ciascuna componente applicativa del Siurp, verranno gestite attraverso trasformazioni dati di tipo XSLT, applicate a runtime sui messaggi scambiati.
Persistence Layer
L’interazione con il database relazionale avviene attraverso il Persistence Layer (Livello di persistenza), implementato tramite Hibernate; le entità/oggetto vengono mappate in uno schema relazionale secondo quelli che sono i canoni dello standard JPA (Java Persistence API). I quattro pilastri su cui poggia la tecnologia JPA sono:
Le entità – rappresentano uno strumento di accesso da un livello organizzato secondo uno schema di sviluppo orientato agli oggetti ad un livello organizzato secondo il paradigma relazionale.
La persistence unit (rapresentata a runtime da un manager persistence factory)
Il persistence manager
Le transazioni – riducono il rischio di avere dati corrotti o inconsistenti.
Figura 24 Schema delle transazioni
Il contesto di persistenza permette quindi di realizzare una netta separazione tra la gerarchia delle classi (le entità) e lo schema del data base. Tale separazione logica (database independence) ha come diretta conseguenza la portabilità tra i diversi DB relazionali e la possibilità di avvalersi di tutte le proprietà tipiche della programmazione ad oggetti (incapsulamento, ereditarietà, polimorfismo…) in ogni momento della progettazione e dello sviluppo del sistema. La stessa gestione delle query avviene attraverso delle politiche di ottimizzazione e di caching che producono un miglioramento delle le performance complessive del sistema.
Document Management
Gli applicativi presenti nel backend di SIURP interagiranno con il sistema di Document Management Alfresco, per la gestione e la produzione di documenti. La scelta di Alfresco come sistema di Document Management ci permette di avere i seguenti vantaggi:
Facilità d'uso e di introduzione: l'utente dispone di un'interfaccia semplice e flessibile con la quale interagire per gestire i documenti.
Disco condiviso avanzato: Alfresco permette di sostituire il classico disco di rete con un repository centralizzato di documenti, organizzato e strutturato in modo totalmente personalizzato
Gestione delle autorizzazioni: è possibile definire livelli di accesso diversi per i singoli utenti su cartelle ma anche su singoli documenti. Alfresco consente di dare l'accesso in sola lettura, in modifica, permette l'aggiunta di nuovi documenti e/o di cancellare documenti esistenti. Il tutto completamente configurabile
Integrazione con Microsoft Office: è possibile gestire i documenti direttamente da Word, Excel, Powerpoint e tutti gli altri prodotti della suite Microsoft
Regole per l'automatizzazione di processi: il repository di Alfresco permette l'introduzione di regole per l'esecuzione in maniera automatica di processi ricorrenti. Ad esempio è possibile introdurre una regola che, ogni volta che un documento word viene caricato in una data cartella, lo converte in un documento pdf e lo invia ad un gruppo di utenti predefinito. Attraverso queste regole di automatizzazione dei processi, è possibile, ad esempio, attivare dei processi per la gestione della fatturazione attiva e passiva, per l'approvazione di ordini e invio conferme ai fornitori e molto altro ancora.
Estrazione automatica dei metadati: all'atto del caricamento di un documento o della modifica di un documento esistente, Xxxxxxxx è in grado di leggere il documento stesso ed estrarne dei metadati che potranno essere usati per eseguire delle ricerche mirate. Xxxxxxxx, inoltre può eseguire ricerche full-text sul contenuto dei documenti.
Workflow personalizzati: uno dei punti di forza di Alfresco è la possibilità di creare dei workflow di approvazione, revisione, collaborazione, ecc. sui documenti. Non ci sono vincoli o limiti ed è possibile replicare fedelmente il processo aziendale per la pubblicazione di un documento.
Registrazione degli accessi: Alfresco registra tutte le operazioni che vengono svolte sui documenti e gli accessi agli stessi. In questo modo è sempre possibile risalire all'autore di una modifica o sapere chi ha letto, ed in che data, un determinato documento.
Gestione ed archiviazione della posta: a partire dalla versione 3.2, Alfresco ha introdotto la funzionalità di server IMAP all'interno del core. E' quindi possibile utilizzare Alfresco come gestore delle mail e per l'archiviazione di tutte le mail aziendali, gestendo di fatto la mail come se si trattasse di un documento qualsiasi. Inoltre, mediante le regole di automatizzazione dei processi, è possibile definire dei filtri per la suddivisione delle mail in base al mittente, alla priorità, all'oggetto, definire dei redirect per inoltrare le mail che soddisfano taluni requisiti e molto altro ancora.
Alfresco permette di essere perfettamente integrato all’interno di liferay attraverso l’utilizzo di una portlet già disponibile e integrata all’interno del portale liferay.
L’integrazione e l’utilizzo di Alfresco con gli applicativi J2EE presenti nel backend può avvenire in diversi modi, ad esempio:
JCR (Java Content Rules): consiste nell’utilizzare le API messe a disposizione da Alfresco direttamente all’interno di un’applicativo Java. Tramite JCR è possibile interagire con tutte le funzionalità messe a disposizione da Alfresco. La soluzione JCR prevede l’integrazione utilizzando chiamate Java RMI verso il sistema Al fresco.
Web Services: consiste nell’accedere al repository di Alfresco, mediante chiamate ai Web Services esposti e definiti dal sistema Alfresco, baandosi su WSDL già definiti.
Le modalità con cui verrà effettuata l’integrazione con Alfresco saranno valutate ed individuate a seconda dei casi di utilizzo e specificate all’interno dei documenti di Analisi Tecnica di ogni componente oggetto di realizzazione.
La figura riassume le due modalità di integrazione previste.
Figura 25 Modalità di integrazioni con Alfresco
Alfresco permette inoltre di avere una costruzione customizzata delle interfacce web mediante il protocollo REST. Questa integrazione permette di avere delle interfacce denominate RESTful, ossia fornisce la possibilità di creare pagine web customizzate attraverso un linguaggio di scripting e mediante delle componenti UI disponibili con Alfresco SURF.
Reportistica Avanzata
La reportistica dei vari applicativi verrà prodotta interagendo con SpagoBI.
SpagoBI è una piattaforma di integrazione per la Business Intelligence realizzata interamente nella filosofia del Free e Open Source Software (FOSS). SpagoBI integra motori analitici specifici su ogni area (reportistica, olap, dashboard, data mining, etc) e permette di utilizzare più motori contemporaneamente sulla stessa area analitica (più strumenti di reportistica insieme, più motori di data mining etc.).
La composizione modulare della piattaforma permette di avviare i progetti anche utilizzando solo alcune delle componenti previste, per poi evolvere nel tempo verso un utilizzo completo e gestire con gradualità la complessità e ricchezza della soluzione. Ogni progresso in tal senso si inserisce naturalmente in un organico disegno di componenti e relazioni.
I moduli principali della piattaforma SpagoBI sono:
Delivery Layer: Il delivery layer ha la responsabilità di rendere i servizi di Business Intelligence fruibili in diverse modalità e facilitare l’interazione con la piattaforma attraverso diverse tecnologie, tutto questo avviene mediante una interfaccia grafica, senza la necessità di scrivere pagine HTML o JSP.
Analytical Layer: E’ lo strato della piattaforma che modella e governa il modello analitico in termini di:
documenti analitici (report, OLAP, Dashboard, Data Mining, Qbe, etc.) per la presentazione dell’informazione all’utente finale, diversificati in termini di espressività, modalità di interazione, grado di libertà e movimento sui dati, capacità elaborativa e focalizzazione tematica
modello comportamentale che istituisce e governa le regole di presentazione di ogni singolo documento e la visibilità sui dati da questi presentati, in relazione ai ruoli degli utenti finali
componenti di servizio a supporto dei processi di analisi, della gestione e manutenzione del sistema complessivo.
BI Engine: SpagoBI copre tutte le aree analitiche (report, OLAP, Dashboard, Data Mining, Qbe, etc) integrando motori analitici già presenti nel panorama FOSS o realizzandone di nuovi ed originali per le aree non ancora coperte.
Data & Metadata Layer: Il Data e Metadata Layer si posiziona a livello del data warehouse (e non di un sistema transazionale), ma il disegno logico e fisico del data warehouse stesso non rientra nell’ambito di competenza di SpagoBI in quanto piattaforma. Tale disegno è infatti la prima attività progettuale da affrontare quando si inizia un progetto, indipendentemente da quale sia la piattaforma analitica scelta. Questo strato dell’architettura include gli strumenti necessari per costruire i processi di ETL necessari per la fase di acquisizione ed alimentazione dei diversi livelli costituenti il modello dei dati del DWH (Fonti Esterne, DB Operativi -> Staging Area -> DW -> Datamart) e per la gestione dei relativi metadati. Come tool di ETL, SpagoBI integra il prodotto FOSS Talend Open Studio (xxxx://xxx.xxxxxx.xxx/xxxxxxxxx-xxxx/xxxx-xxxxxx.xxx), che offre una completa interfaccia grafica per definire sia il proprio business model concettuale che i singoli processi di trattamento dei dati.
6Architettura fisica
6.1Criteri di progettazione
L’approccio multi-strato è pervasivo di tutto il progetto; esso è implementato anche dal punto di vista hardware, tramite disaccoppiamento fisico della capacità elaborativa dedicata ai servizi di DB, a quelli applicativi ed alla presentation. Questa separazione fisica dei servizi, dislocati su server differenti, consente, in prima istanza, di poter realizzare un miglior tuning dei diversi ambienti, e, successivamente, conferisce elasticità ad ogni adeguamento di potenza e/o aggiornamento dell’intero sistema (capacity planning).
Condividendo e quindi recependo pienamente tali principi fondanti della progettazione architetturale, anche la componente fisica dell’ architettura è stata disegnata ponendosi come obiettivi il raggiungimento di:
Disponibilità
Scalabilità
Sicurezza
Praticità operativa
Prestazioni
come di seguito descritto:
Disponibilità
Si è raggiunta un’altissima disponibilità dei sistemi, ai vertici delle attuali possibilità offerte dalla tecnologia, sia mediante accorgimenti interni, sull’hardware fornito, sia attraverso soluzioni architetturali globali.
A livello complessivo l’alta affidabilità è raggiunta mediante:
clusterizzazione dei database server: questa configurazione garantisce l’alta affidabilità del sistema in quanto, anche in caso di caduta di uno dei nodi, i servizi attivi sono interamente presi in carico dai nodi ancora operativi,
bilanciamento di carico: tutti i server di front-end e gli application server sono configurati in bilanciamento di carico ed in failover per i servizi non bilanciabili (relativi all’ESB), per cui l’alta affidabilità è ottenuta implicitamente; in caso di avaria di un sistema, tutte le richieste di servizi vengono automaticamente indirizzate ai sistemi rimanenti.
A livello interno, l’affidabilità è garantita dalla totale ridondanza dei dispositivi critici, nonché dalla configurazione in alta affidabilità di tutti i dischi, anche di sistema e degli switch Ethernet e Fibre Channel
La totale ridondanza dei dispositivi ed il loro parallelismo, consente agli amministratori del sistema di operare senza interrompere il servizio (ad es., in caso di necessità di applicazione di una patch agli application server, si può mettere off-line un server alla volta, senza curarsi di chi in quel momento lo stia usando, applicare la patch, e poi rimetterlo on-line). In conseguenza di ciò, gli amministratori di sistema hanno raramente la necessità di interrompere la disponibilità del servizio agli utenti finali, beneficiando in aggiunta, a loro volta, dell’assenza di vincoli dovuti a finestre temporali ristrette, o disagevoli (es. giorni festivi), per espletare le attività di manutenzione ordinarie e straordinarie.
Scalabilità
L’architettura proposta è stata concepita per offrire ampi margini di scalabilità, sia orizzontale che verticale.
L’espandibilità verticale, è rappresentata dalla possibilità di incrementare le risorse (RAM, capacità disco, …) per ogni elemento inserito nell’architettura. L’espandibilità verticale, è praticamente limitata all'area storage (disk array e tape library), non a caso l'unica area dove si ha necessità, di avere un unico dispositivo, ed alla fisiologica capacità di espansione in termini di RAM e disco da parte dei server; questa è una situazione voluta, e ritenuta assolutamente conveniente sia tecnicamente che economicamente, in vista di potenziamenti che si rendessero opportuni in futuro, in base al tasso di crescita del carico del sistema, dovuto ad un aumento degli utenti o ad un aumento delle funzionalità.
Vero elemento di eccellenza della soluzione proposta è la sua espandibilità orizzontale, rappresentata dalla possibilità di aumentare la potenza del sistema semplicemente incrementando il numero di server, sia aggiungendo server al pool in bilanciamento (anche a caldo) per gli strati WEB ed Application, sia aggiungendo nodi ai cluster database e suddividendo sui nuovi nodi i servizi di database supportati dai nodi preesistenti.
In questo modo, si coglie un doppio beneficio:
scalare il sistema in modo mirato (upgrade sul solo servizio che lo necessita)
aumentare la longevità dell’hardware poiché, anche se dopo qualche anno di utilizzo l’upgrade di un singolo server non è più economicamente conveniente, è possibile l’affiancamento di un nuovo sistema senza perdere la capacità elaborativa precedente con un “saldo prestazionale” decisamente superiore (capacity planning).
Sicurezza
Si è curato questo aspetto prevedendo ed includendo in fornitura, i seguenti sottosistemi:
tape library connessa direttamente in SAN (Storage Area Network): questo accorgimento consente di poter effettuare i backup in modo organico e automatizzato, il che è di per sé la miglior garanzia che i backup esistano e siano efficaci.
disk array centralizzato di classe enterprise, dotato quindi di grande affidabilità, oltre che sulla logica di controllo, anche sulla sicurezza dei dati (configurazione in RAID dei dischi, con dischi di hot-spare).
Predisposizione al Disaster Recovery. L’architettura proposta risulta già idonea per la gestione di un proprio sito di Disaster Recovery, anche in modalità “Warm Start”, ovvero in grado di intervenire nell’arco di pochi minuti dalla richiesta con sistemi dedicati e sempre accesi le cui basi dati sono tenute costantemente allineate con quelle di produzione. I database adottati dispongono infatti di potenti strumenti di scripting in grado di automatizzare l’allineamento dati con il sito di Disaster Recovery. La modalità di allineamento così ottenuta, basata su processi “logici” degli stessi database o programmi, presenta diversi vantaggi, tra i quali: garanzia, in ogni momento, di integrità e coerenza di dati; nessun vincolo di identità (né di vendor né di configurazione) fra i dispositivi hardware, storage in particolare, dei due siti; nessun vincolo sul sistema operativo impiegato.
Praticità operativa
La praticità operativa nella gestione dei sistemi viene facilitata dai seguenti fattori:
la totale ridondanza dei dispositivi ed il loro parallelismo, consente agli amministratori del sistema di operare senza interrompere il servizio anche per espletare le attività di manutenzione ordinaria e straordinaria;
la fornitura di una completa suite di backup (HP DataProtector) per gestire in modo automatizzato e centralizzato le politiche di backup;
la fornitura di una completa suite di management & monitoring centralizzato, in grado di controllare costantemente hardware e software, nonché fornire informazioni aggregate, utili alla prevenzione dei problemi; questa suite integra gli strumenti di rilevazione e storicizzazione della vitalità e delle performances non solo dell’hardware, ma anche degli ambienti software d’ambiente (DB, application server, ecc) ed anche delle applicazioni sviluppate. Poiché è in grado di rilevare automaticamente e continuamente gli indicatori di rispetto degli SLA del sistema, sgrava gli operatori da attività ripetitive ed elimina inoltre la componente di errore umano
diffusa presenza di dispositivi “hot-swap”, quali dischi rigidi, alimentatori e ventole, che consentono quindi la sostituzione a caldo, senza interrompere il servizio, eventualmente anche da parte di personale non specializzato
Prestazioni
Adeguate performance, rispetto lo scenario di utenza prefigurato nell’Allegato Tecnico, sono garantite da:
utilizzo come database server principale di 2 server utilizzante sistema operativo Linux, più efficiente di Windows in questo ambito;
fornitura di storage centralizzato ad alte prestazioni, connesso in SAN con fibre channel , e dotato di dischi con interfaccia fibre canne;
distribuzione del carico elaborativo su tutti i server del “tier”, beneficiando così di economie di scala;
adozione della rete SAN che, oltre a garantire un collegamento tra server e sistemi di storage ad elevata velocità, permette, di evitare la saturazione della LAN, che, quindi, può essere totalmente dedicata alla comunicazione fra i server e verso gli utenti finali, migliorando così le performance globali
6.2Schema infrastruttura
Nella figura seguente viene riporta l’architettura fisica del sistema
Figura 26 – Architettura Fisica
Di seguito si riporta una sintetica descrizione del ruolo funzionale dei componenti che compongono l’architettura:
DB1 e DB2: E’ la coppia di server, in configurazione cluster, con funzione di database server. I servizi di database, per tutte le applicazioni del sistema, sono basati sulla piattaforma open source PostgreSQL.
Entrambi i server sono collegati alla SAN (Storage Area Network) mediante un doppio canale fibre channel che garantisce l’accesso in alta affidabilità al sistema di storage condiviso.
AS1 TOM e AS2 TOM: E’ la coppia di application server sui quali sono presenti i servizi ESB (Enterprise Service Bus) basati sulla piattaforma open source Apache ServiceMix.
AS1 MIX e AS2 MIX: E’ la coppia di application server, in bilanciamento di carico, che ospita i componenti applicativi (business logic) basati su piattaforma java. La distribuzione di carico viene gestita dalla coppia di server di front-end (LBL1 e LBL2). Entrambi i server sono collegati alla SAN (Storage Area Network) mediante un canale fibre channel che garantisce l’accesso al sistema di storage condiviso, grazie al file system OCFS2 installato.
LBL1 e LBL2: E’ la coppia di server di front-end che costituisce il punto di accesso per tutte le applicazioni e che ha la funzione di ripartire il traffico sui vari server applicativi. Entrambi i server sono installati all’interno della zona di rete indicata con DMZ (DeMilitarized Zone); questo tipo di configurazione permette di evitare accessi diretti verso i server applicativi la cui installazione è prevista sulla LAN INTERNA, conferendo al sistema un elevato grado di sicurezza. Queste macchine sono basate sul prodotto TCO Project LBL Load Balancer Standard Edition.
DA: E’ il disk array condiviso attestato alla rete SAN (Storage Area Network) attraverso un doppio canale Fibre Channel da 4Gb/s; su questo storage sono memorizzati tutti i dati gestiti dal sistema, sia strutturati (RBDMS) che non strutturati (file system) ed appartenenti sia all’area di Produzione che di Test e Sviluppo.
TL: E’ la tape library, dotata di un drive in tecnologia LTO4, che ha la funzione di consentire le attività di backup sul sistema. La libreria è direttamente collegata alla Storage Area Network (SAN) attraverso un canale fibre channel, evitando così di appesantire la LAN durante le operazioni di trasferimento su nastro.
VCENTER1 e VCENTER2: sono i due server su cui è installata la componente software Vmware, per la gestione di un’infrastruttura virtualizzata. Le macchine virtuali ospitano gli application server dei moduli applicativi realizzati durante il progetto e non previste nella fase iniziale.
XXX 0000: è il sistema che mette a disposizione lo storage necessario ad ospitare i server virtuali gestiti tramite VCENTER1 e VCENTER2.
DB TS, AS TS MIX, AS TS TOM e LBL TS: Sono i sistemi dedicati alle attività di test di tutte le piattaforme software che compongono il sistema SIURP. In particolare, sul server DB TS è prevista l’installazione delle basi dati di test, sui server AS TS MIX e AS TS TOM sono replicati i vari ambienti applicativi, mentre, sul server LBL TS è prevista l’istallazione di una istanza di test del sistema di bilanciamento di carico.
|
|
Pagina 16 di 80 |
