Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del...

28
Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 1 / 28 Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali Emette: Ing. Stefano Alì Verifica e Approva: Comune di Catania PROGETTO ESECUTIVO Riorganizzazione dei Sistemi Informativi Comunali Aspetti generali D.R.G. 2156 del 29/12/2008 Committente: Comune di Catania Commessa: comct-0901 STORIA DELLE REVISIONI Data Motivo Emette Verifica e Approva 1.0 18/11/2009 Prima emissione Ing. Stefano Alì Comune di Catania

Transcript of Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del...

Page 1: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 1 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

Emette: Ing. Stefano Alì Verifica e Approva: Comune di Catania

PROGETTO ESECUTIVO

Riorganizzazione dei

Sistemi Informativi Comunali

Aspetti generali

D.R.G. 2156 del 29/12/2008

Committente: Comune di Catania

Commessa: comct-0901

STORIA DELLE REVISIONI

N° Data Motivo Emette Verifica e Approva

1.0 18/11/2009 Prima emissione Ing. Stefano Alì Comune di Catania

Page 2: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 2 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

Sommario

DOCUMENTI APPLICABILI 4

DEFINIZIONI 4

GLOSSARIO 4

1. INTRODUZIONE 5

2. SPECIFICHE GENERALI SUL CONTESTO OPERATIVO 7

2.1 Gestione autenticazione e autorizzazioni 8

2.2 Piattaforma operativa client 9

2.3 Piattaforma server 10

2.4 Infrastruttura applicativa 10

3. CHANGE MANAGEMENT 12

3.1 Fattori critici di successo 12

4. APPROCCIO ALL’INTEGRAZIONE CON IL SISTEMA INFORMATIVO ESISTENTE 13

4.1 Integrazione dei dati 13

4.2 Integrazione col Protocollo 13

4.3 Banca dati del personale 17

4.4 Tributi Ragioneria 18

4.5 Sistema Informativo Territoriale 19

4.6 Pagamenti on-line 19

4.6.1 Integrazione delle utenze esterne 20

5. PIANIFICAZIONE DI MASSIMA 22

6. MODALITÀ DI ESECUZIONE DEL PROGETTO 23

6.1 Fasi del progetto 23

6.1.1 Fase I – Impostazione del progetto 23

6.1.2 Fase II – Realizzazione del progetto 23

6.1.3 Fase III – Rilascio 24

6.1.4 Fase IV – Gestione e Manutenzione 24

6.2 Luogo di Esecuzione 25

6.3 Lingua 25

6.4 Piano di lavoro 25

Page 3: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 3 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

6.5 Team 25

6.6 Monitoraggio del progetto 25

6.7 Deliverable 26

7. GARANZIA, VINCOLI E PENALI 27

8. DOCUMENTI DA PRESENTARE NELL’OFFERTA TECNICA DI FORNITURA 27

Page 4: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 4 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

Documenti applicabili Codice Titolo Editore Data di

pubblicazione

Bando di gara del Comune di Catania

Siged Web Services Siged

Web services sistema pagamento on line Regulus

Definizioni Nel corso della presente proposta si intende quanto segue:

• Fornitore : Ditta Aggiudicataria dell’implementazione del progetto.

• Committente : Comune di Catania

• Cliente/Utilizzatore Finale : Comune di Catania

Glossario • LDAP: Lightweight Directory Access Protocol

• SSO: Single Sign-On

• CAS: Central Authentication Service

• I.E.: Internet Explorer

• XML: eXtensible Markup Language

• WMI: Windows Management Instrumentation

• SNMP: Simple Network Management Protocol

• SLA: Service Level Agreement

• S.I.T.: Sistema Informativo Territoriale

• P.E.C. Posta elettronica certificata

Page 5: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 5 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

1. Introduzione In data 08/10/2009 Xenia Progetti è risultata aggiudicataria provvisoria dell’affidamento del servizio di progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti da 2 a 6.

Gli obiettivi del progetto di riorganizzazione dei sistemi informativi vengono di seguito riassunti.

• Sottoprogetto1 – Potenziamento strumenti informatici dell’Amministrazione Comunale

• Sottoprogetto2 – Diffusione Gestione Documentale

• Sottoprogetto3 – Interventi a supporto delle politiche di equità fiscale

• Sottoprogetto4 – Estensione dei servizi di pagamento online

• Sottoprogetto5 – Programmazione, monitoraggio e controllo di gestione dell’Amm. Comunale

• Sottoprogetto6 – Interventi di ammodernamento tecnologico della Sala Consiliare

Le scelte e le motivazioni che hanno spinto l’Amministrazione verso l’individuazione di questi ambiti progettuali sono ampiamente descritti nel bando di gara per l’assegnazione della progettazione esecutiva.

L’incarico ricevuto copre i sottoprogetti da 2 a 6 mentre per ciò che riguarda il primo sottoprogetto la ditta aggiudicataria è stata la ditta Regulus di Bologna.

Gli elaborati consegnati al Comune di Catania da Xenia Progetti, in riferimento all’incarico ricevuto, sono i seguenti:

• Il presente documento che copre le problematiche comuni ai 5 sottoprogetti ed individua anche delle linee guida generali applicabili a progetti futuri;

• I progetti di dettaglio relativi ai diversi sottoprogetti;

• I singoli capitolati relativi alle gare in cui verrà scorporata la fornitura.

I diversi documenti forniti evidenziano sia le relazioni fra i diversi sottoprogetti sia i legami con quanto ambito del sottoprogetto 1 che costituisce la componente trasversale, infrastrutturale e tecnologica a servizio dei 5 sottoprogetti oggetto dell’incarico.

Durante l’analisi preliminare alla realizzazione del progetto di dettaglio commissionatoci, è emerso come la piattaforma applicativa del Comune di Catania sia già ampiamente consolidata.

Il sistema informativo oggi implementato risente chiaramente di una crescita a macchia di leopardo in cui le diverse procedure utilizzate hanno risentito di una progettazione non sempre guidata dai Sistemi Informativi e che quindi non ha tenuto conto delle necessità di integrazione, alla base di un sistema informativo complesso come quello dei Sistemi Informativi del Comune di Catania. Il sistema informativo deve sì rispondere alle problematiche più disparate ma molte delle informazioni gestite “localmente” hanno rilevanza anche per altri sottosistemi.

Da queste considerazioni è emersa l’idea di redigere lo studio suddividendo gli elaborati in documenti distinti. Un primo documento, il presente, che individua una serie di condizioni generali che si applicano ai sottoprogetti oggetto della fornitura, ma che individua aspetti di progettazione e di gestione che possono essere applicati a quanto oggi costituisce il sistema informativo Comunale.

Questo documento si occupa di dare degli indirizzi sia tecnologici che gestionali che possono costituire la base per realizzare documenti di specifiche tecniche o procedure organizzative che servano a guidare la crescita ed il mantenimento dei sistemi informatici del comune di Catania.

Visto l’ambito dell’incarico verranno evidenziate le problematiche più attinenti agli aspetti applicativi, evidenziando comunque i requisiti infrastrutturali minimi.

Page 6: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 6 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

Allegati a questo documento vengono forniti i documenti specifici oggetto di capitolato secondo la ripartizione dei diversi progetti. In ognuno di questi verranno evidenziate le caratteristiche specifiche delle forniture e dei servizi e le modalità in cui si ritiene più opportuno procedere alle gare.

In particolare approfondendo le tematiche specifiche dei diversi sottoprogetti si è giunti alla scelta di suddividere la fornitura nelle seguenti parti:

• Sottoprogetto 2 – Diffusione Gestione Documentale

• Sottoprogetto 3A – Aggiornamento ed estensioni delle funzionalità base del SIT

• Sottoprogetto 3B – Adozione di strumenti informatici per la gestione delle pratiche edilizie

• Sottoprogetto 3C – Adozione di strumenti informatici per la gestione delle licenze commerciali

• Sottoprogetto 4 – Estensione dei servizi di pagamento online

• Sottoprogetto 5 – Programmazione, monitoraggio e controllo di gestione dell’Amministrazione Comunale

• Sottoprogetto 6 – Interventi di ammodernamento tecnologico della Sala Consiliare

La scelta di scomporre il terzo sottoprogetto in 3 diverse forniture nasce dalla considerazione che le competenze e gli ambiti sono diversi. Mentre per l’estensione del SIT è necessario prevedere il riuso di quanto oggi posseduto dall’Ente, sia in termini di dati che di piattaforme, le altre due forniture non sono strettamente legate ed è preferibile che si vada a gara in modo da selezionare il prodotto più adatto alle esigenze del Comune di Catania.

Page 7: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 7 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

2. Specifiche generali sul contesto operativo Come indicato nell’introduzione i Sistemi Informativi del comune di Catania gestisce piattaforme e applicazioni operanti nei contesti più vari. Durante l’analisi è emersa in maniera netta l’esigenza di definire standard che permettano l’interazione tra le piattaforme.

Dal punto di vista applicativo, devono essere previsti dei meccanismi di integrazione fra le procedure informatiche, per permettere sia interrogazioni in real time sia in modalità back office. I meccanismi devono permettere sia l’integrazione a livello di dato, avendo quindi accesso e conoscenza delle specifiche banche dati, sia attraverso funzionalità messe a disposizione dalle diverse piattaforme che garantiscano in maniera assoluta la congruenza delle operazioni.

Devono inoltre essere individuate delle piattaforme, sia di sistema che database, che siano di riferimento. Questa scelta è essenziale in modo da limitare sia le piattaforme hardware da implementare, sia le competenze di chi deve amministrare i sistemi.

Un ultimo aspetto che deve essere formalizzato è la centralizzazione delle utenze. La centralizzazione è un’esigenza sia per gli amministratori dei sistemi che oggi hanno degli obblighi particolari nel verificare la correttezza delle abilitazioni degli utenti, sia funzionali garantendo che vengano assegnate correttamente secondo il modello organizzativo dell’Ente, oltre che soddisfino a tutti i requisiti del D.lvo 196/2003.

Dal punto di vista degli utenti, a tendere ci sarà il grande vantaggio di utilizzare un unico account ed un’unica password sincronizzata su tutte le piattaforme.

Di seguito vengono evidenziate alcune delle misure minime di sicurezza nel trattamento dei dati con strumenti elettronici che hanno una ricaduta dal punto di vista applicativo, indicando il punto in cui vengono richiamati.

Punto 3 All’incaricato sono assegnate o associate individualmente le credenziali per l’autenticazione.

Punto 5 La parola chiave deve essere di almeno 8 caratteri, non contiene riferimenti all’incaricato (cognome, nome, username non devono essere una parte della password). Deve essere necessariamente modificata al primo utilizzo e deve scadere ogni 6 mesi. Tranne che nel caso di applicazioni che permettano il trattamento di dati sensibili, nel qual caso è prevista una politica più restrittiva.

Punto 6 Il codice identificativo (normalmente username) non può essere assegnato ad utenti diversi in tempi diversi. Le singole applicazioni dovranno, infatti, tenere traccia delle operazioni e risalire agli autori delle stesse.

Punto 7 L’applicazione deve disattivare le utenze non utilizzate per più di 6 mesi. Deve conservare quindi l’ultimo accesso di ogni utente.

Punto 8 Disattivazione dell’autorizzazione in caso di perdita del ruolo. Questo punto è estremamente complesso da gestire se non per il caso di cessazione dell’utenza. Nel caso di perdita del ruolo è compito dell’amministratore dell’applicazione farsi carico dell’attività.

Punto 14 Almeno annualmente è verificata la sussistenza dei livelli autorizzativi. Serve quindi un report complessivo di utenze ed assegnazione di profili specifici delle singole applicazioni.

Punto 19 Azioni e tempo di recupero di archivi e programmi. (Utile fare dei Test di recupero su ambienti offline)

Da un punto di vista organizzativo è necessario individuare una struttura centralizzata che alla luce delle varie interdipendenze fra sistemi, possa definire chiaramente quali sono gli asset ed i processi del Comune, potendo così redigere correttamente il documento programmatico di sicurezza. Evidenziando l’elenco dei trattamenti, l’analisi dei rischi, le politiche di sicurezza, le lettere agli incaricati etc.

Un ruolo particolare lo rivestono gli amministratori dei sistemi (Amministratori di sistemi operativi, Gestore delle infrastrutture di rete e sicurezza, DBA, Gestore delle applicazioni). Essi dispongono di privilegi di accesso particolari avendo visibilità dei dati e dei log di accesso ai sistemi.

Il garante della Privacy ha stabilito delle disposizioni sugli adempimenti in merito che dovranno essere messe in atto al più presto (ultima proroga a dicembre 2009).

Tali problematiche non riguardano specificatamente il progetto, vengono comunque evidenziate delle funzionalità richieste ai software e l’opportuna documentazione per permettere all’Ente di adempiere agli obblighi di Legge.

Page 8: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 8 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

2.1 Gestione autenticazione e autorizzazioni E’ stata rilevata la mancanza di uno standard di gestione delle utenze trasversale a tutte le applicazioni. Tale limite deve essere superato attraverso la realizzazione di un sistema di gestione integrato delle utenze.

Il sistema ad oggi non è stato ancora definito, è comunque auspicabile che si poggi su una piattaforma LDAP standard e possibilmente open source. In modo che tutte le applicazioni baseranno il proprio sistema di autenticazione su questa piattaforma.

Questo passo centralizza le utenze, ma lascia aperto il problema legato all’autenticazione integrata, senza la quale l’utente dovrà provvedere ad autenticarsi sui diversi sistemi, anche se utilizzando le medesime credenziali. Tale inconveniente verrà superato, in futuro, attraverso un sistema di SSO o CAS e facendo sì che le applicazioni dispongano degli opportuni plug-in.

La definizione di tale problematica è comunque ambi to del sottoprogetto 1.

Dal punto di vista applicativo sarà titolo qualificante nella valutazione delle applicazioni proposte l’integrazione con la piattaforma LDAP attraverso cui effettuerà l’autenticazione degli utenti. Ogni applicazione sarà comunque responsabile:

• Della definizione degli utenti abilitati all’applicazione, tra quelli presenti nel sottosistema LDAP;

• Dei profili con cui operano, che saranno specifici dell’applicativo.

Il meccanismo autorizzativo legato ai profili è estremamente complesso e troppo specifico delle singole piattaforme. Solo in realtà in cui è molto avanzato lo sviluppo interno delle applicazioni si può realizzare l’integrazione stretta tra i profili applicativi ed i profili degli utenti presenti nella banca dati del personale attraverso l’assegnazione dei profili alle unità organizzative.

Da questo punto di vista è titolo qualificante per le applicazioni disporre di meccanismi di reporting delle utenze utilizzate e dei profili associati. I report possono essere interni all’applicazione o più funzionalmente possono essere delle query SQL che estraggano l’associazione degli utenti ai profili. Attraverso opportuni moduli, a carico dei Sistemi Informativi, sarà possibile individuare discrepanze tra le informazioni presenti nella banca dati del personale e le autorizzazioni specifiche nell’applicazione.

La centralizzazione delle utenze garantirà comunque agli amministratori del sistema di poter effettuare l’eliminazione di utenze da tutti i sistemi.

Le applicazioni dovranno quindi:

1. Essere conformi a quanto previsto dal D.lvo 196/ 2003 così come applicato dal documento programmatico sulla sicurezza (D.P.S,);

2. Sarà titolo qualificante essere integrate con il sistema degli accessi definito nel sottoprogetto 1 ;

3. Sarà titolo qualificante la possibilità di inter rogare il sistema interno di profilazione attravers o query SQL;

4. Tutte le applicazioni dovranno disporre di strum enti di logging degli accessi utente e delle operazioni effettuate, visibili dagli amministrator i di sistema.

Il sistema di gestione delle utenze esterne, cittadini, aziende etc, per l’accesso ai servizi web risulta, invece, centralizzato nell’applicazione di gestione dei pagamenti online. Tutte le applicazioni che esporranno dei servizi su internet e che richiederanno il riconoscimento dell’utente, dovranno appoggiarsi al sistema di autenticazione previsto dal sistema dei pagamenti online.

Questo permetterà di razionalizzare la consegna e la gestione delle utenze.

Nel paragrafo relativo al sistema dei pagamenti online vengono descritte le modalità operative ed i requisiti per permettere l’integrazione.

Un ultimo aspetto che riguarda i responsabili del sottoprogetto 1 è la disponibilità di share condivise attraverso un sistema di autenticazione integrato per condividere file fra gli utenti.

Questo concetto riguarda ad esempio la condivisione di documenti rilevanti per uno stesso gruppo di utenti. Nel tempo questa problematica si è man mano spostata passando dalla semplice condivisione di spazi di disco a sistemi di gestione integrati più affini ad un concetto di portali di collaborazioni, con condivisione di documenti, agende, scadenziari, etc.

Page 9: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 9 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

In questo settore esistono una vasta gamma di prodotti sia commerciali (es. Microsoft Sharepoint) sia open source (Alfresco, etc.). Questa problematica dovrebbe essere attenzionata in eventuali progetti futuri essendo al di là degli scopi del sottoprogetto 1.

2.2 Piattaforma operativa client La definizione della piattaforma operativa client (denominata “build”) non è ambito del presente incarico di progettazione.

Nella selezione della piattaforma operativa non è mai possibile effettuare una scelta, definitiva, puramente tecnica fra:

• Soluzione Web, semplice da rendere disponibile agli utenti, facilmente manutenibile

• Soluzione Client Server, normalmente con un’interfaccia utente più ricca e che sfrutta meglio le potenzialità hardware della postazione utente.

In una struttura così complessa come quella del comune di Catania in cui i costi di gestione operativa delle applicazioni sono rilevanti è preferibile disporre di soluzioni web che permettono l’abbattimento di tali costi.

Ove quindi non sia necessario procedere ad attività molto intense dal punto di vista della cpu, o con interfacce particolarmente complesse come ad esempio le attività legate alla cartografia, è titolo qualificante che la soluzione venga implementata attraverso soluzioni w eb based perché di più semplice gestione.

E’ richiesta inoltre la perfetta compatibilità con gli strumenti OpenOffice, ove ad esempio l’applicaz ione disponga di modelli di documenti. Tali modelli, mac ro o simili dovranno interagire perfettamente con l a piattaforma OpenOffice, di utilizzo nei computer re centemente acquistati dall’Amministrazione Comunale .

Nella fornitura dovrà essere indicata la modalità di funzionamento e le componenti che dovranno essere presenti in ogni postazione client (prerequisiti software). Le eventuali licenze di tali componenti saranno a carico del Fornitore. Dovranno essere anche indicate le caratteristiche hardware minime delle postazioni utente.

Nel variegato panorama delle postazioni utente oggi disponibili possono essere evidenziate le seguenti caratteristiche comuni:

1. Piattaforma di produttività individuale basata su Openoffice

2. Microsoft Office 2000/2003 nei PC installati nel passato

3. Piattaforma di posta elettronica basata su Lotus Notes, utilizzata via web dalla intranet

4. Sistema di navigazione su internet IE 7

5. Sistema antivirus Karspesky

L’attività di installazione dell’applicazione sarà a carico del fornitore. Poiché tale operazione non si completerà con la conclusione della fornitura ma verrà passata in gestione ai Sistemi informativi è necessario che le applicazioni client:

1. Dispongano di una efficiente procedura di instal lazione, sia dell’applicazione stessa che di eventuali componenti base

2. Che la procedura sia perfettamente documentata e venga descritta agli operatori dei Sistemi Informativi che la prenderanno in carico

3. Sia conforme agli standard più comuni di install azione di applicazioni software in modo da essere gestita tramite gli strumenti di rilascio dei softw are client nel desktop management.

L’applicazione, sia nel caso web che client server, dovrà disporre di interfacce utente ergonomiche, valutate come titolo qualificante in fase di aggiud icazione.

Le applicazioni inoltre dovranno garantire tempi di risposta compatibili con le attività dell’operator e e le diverse transazioni non dovranno mai rallentare l’o perato dell’utente se non per report o query particolarmente complesse.

La ditta aggiudicataria dovrà A PROPRIO CARICO evid enziare che eventuali ritardi di risposta non siano imputabili all’applicazione ed al contempo individu arne la causa (disservizi o limitazioni alla banda di

Page 10: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 10 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

comunicazione, sovraccarico della postazione o dei server sia in termini di cpu che di memoria, incompatibilità con altri software).

Tale attività dovrà essere garantita sia in fase di implementazione e collaudo sia durante la manutenz ione dell’applicazione.

2.3 Piattaforma server La definizione di una piattaforma server comune a tutte le applicazioni non è ambito della fornitura. Di seguito vengono evidenziate le piattaforme operative qualificanti per evitare che nell’ambito dei sistemi di base ci sia una proliferazione di piattaforme.

Dal punto di vista dell’ambito dei sottoprogetti in esame si ritiene qualificante per le applicazioni proposte operare nei seguenti ambienti:

• Sistema operativo

o Microsoft Windows Server 2008 o successivi

o Piattaforma Linux

• Piattaforma database

o Microsoft SQL Server 2005 o successivi

o Oracle 10 o successivi

o Piattaforma open source MySQL

• Pubblicazione web

o Microsoft IIS 6.0 o successivi (Piattaforma Microso ft)

o Apache Tomcat (Java)

o IBM WebSphere

Sono, infatti, queste le piattaforme standard già presenti o che saranno implementate sui sistemi virtualizzati messi a disposizione dal sottoprogetto 1.

Non sono al momento definibili piattaforme specifiche di Application Server (nel modello three tier).

In fase di aggiudicazione delle diverse gare verranno effettuate delle razionalizzazioni dei sistemi, accentrando ad esempio i database operanti sulla stessa piattaforma in modo da semplificare la manutenzione e risparmiando eventuali costi di licenza.

E’ quindi necessario che in fase di offerta vengano evidenziate:

• Piattaforma server (o ipotesi alternative)

• Costi delle licenze di base

Sarà compito del fornitore installare le componenti server specifiche dell’applicazione. Tali attività dovranno essere effettuate attraverso opportune procedure di setup specificatamente documentate.

2.4 Infrastruttura applicativa In questo paragrafo vengono evidenziate delle caratteristiche legate all’infrastruttura offerte dai sistemi.

In particolare oltre a quanto descritto precedentemente, tutti i sistemi devono garantire:

• Apertura della banca dati su cui si poggiano. Quest a deve essere accessibile attraverso query SQL e deve essere aperta e totalmente documentata;

Risulta titolo qualificante

• Che la piattaforma dati sia nativamente relazionale .

• Che la soluzione preveda nativamente l’utilizzo di web services o altri strumenti analoghi di interoperabilità. Il dettaglio delle interfacce ric hieste sarà specificato nell’ambito del singolo progetto, se previsto nella fornitura, ma un’impost azione tecnologica di questo tipo, anche se non specificatamente richiesta, potrà permettere integr azioni future oggi non evidenziate.

Page 11: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 11 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

• Application Instrumentation, cioè che l’applicazion e sia dotata di tutti gli strumenti di logging e monitoring atti ad individuare e risolvere le probl ematiche sistemistiche (carenze di risorse, etc.), e che inoltre tali informazioni potranno essere inter rogate attraverso tecnologie standard (SNMP o WMI). A regime queste informazioni potranno permett ere la definizione e la verifica degli SLA per i diversi ambiti.

• Nativamente integrabile con sistemi di posta elettr onica per le funzionalità di workflow e comunicazione.

• Anche nel caso di applicazioni client server, le fu nzionalità elementari di interrogazione dovranno essere rese disponibili via web, garantendo la sicu rezza dei dati. Tale modalità di funzionamento, orientata ad un accesso illimitato deve essere comp resa nella fornitura e non richiedere costi successivi.

Page 12: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 12 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

3. Change Management Le esigenze di change management non sono oggetto di questo progetto.

E’ comunque necessario che l’amministrazione preveda con sufficiente anticipo e definisca opportunamente attività la cui ricaduta più che informatica sia di tipo organizzativo.

Questo è ad esempio il caso di passaggio all’ufficio senza carta, verificando le modalità di scansione ed acquisizione, o più semplicemente la gestione dei workflow di assegnazione della pratica allo specifico servizio tramite il protocollo con la segnalazione tramite mail.

E’ inoltre essenziale un supporto organizzativo nell’avvio delle nuove procedure. L’organizzazione deve definire chiaramente ruoli ed operatività attraverso specifiche procedure operative (ordini di servizio).

3.1 Fattori critici di successo Il principale fattore critico del successo di un’informatizzazione è dato dal supporto degli utenti che utilizzeranno il sistema.

E’ necessario quindi che l’utente sia pienamente coinvolto e consapevole del ruolo che svolge. Questo si otterrà attraverso:

• Azioni di stimolo dell’Amministrazione dattraverso ordini di servizio, progetti incentivanti etc.

• Corretta copertura applicativa delle attività svolte. Questa attività riguarda sia l’analisi del progetto, la selezione dell’applicazione, ma anche l’implementazione con il corretto disegno del workflow e l’utilizzo di key users che possono meglio rappresentare le problematiche e trasferire il know how ai colleghi.

• Buona rispondenza degli applicativi alle esigenze degli utenti con sistemi veloci e performanti

• Ampia e completa formazione degli utenti

Page 13: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 13 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

4. Approccio all’integrazione con il Sistema Inform ativo esistente Vengono di seguito descritti gli aspetti generali di integrazione fra sistemi e dati. Per quanto riguarda l’integrazione applicativa fra sistemi viene evidenziata la modalità di interazione dei sistemi di workflow ed il protocollo.

In particolare verrà data una panoramica sui seguenti sistemi:

- Protocollo

- Banca dati del personale

- Sistema dei tributi e della contabilità

- Sistema Informativo Territoriale

- Sistema di gestione dei pagamenti on line

Alcuni di questi sono ambito del progetto, altri sono invece banche dati da cui attingere o da alimentare.

Le integrazioni qui descritte saranno comunque dettagliate con gli specifici requisiti nei singoli sottoprogetti. Qui si intende solo dare una visione generale.

4.1 Integrazione dei dati Di seguito un quadro riassuntivo delle integrazioni previste nei vari sottoprogetti.

4.2 Integrazione col Protocollo Molti dei flussi operativi gestiti dalla macchina burocratica comunale e specifici dei diversi servizi hanno forti interazioni col sistema di gestione documentale e col protocollo in particolare. In questo documento si intende identificare una soluzione applicabile alle procedure che sono ambito del progetto (gestione delle pratiche edilizie e rilascio delle licenze commerciali) ma che diventi anche un paradigma per le problematiche analoghe che si presenteranno nel futuro.

La soluzione di trasformare l’integrazione in gestione unitaria, rendendo cioè la procedura di gestione documentale responsabile di tutti i flussi è sicuramente la più semplice, ma non è assolutamente applicabile. Ogni flusso è legato a problematiche specifiche che vengono risolte in maniera verticale dalle applicazioni appositamente progettate allo scopo, inoltre ogni fornitore si caratterizza con prodotti più rispondenti a determinati settori non essendo inoltre garantito che la soluzione copra tutti i servizi.

Page 14: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 14 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

I costi derivanti dall’utilizzo di una soluzione di workflow general purpose, parametrizzandola opportunamente o addirittura tramite sviluppi ad hoc e la conseguente minore esperienza specifica del fornitore, sarebbero di gran lunga maggiori di qualsiasi beneficio derivato dall’unificazione.

L’unica strada perseguibile è dunque quella dell’integrazione delle applicazioni verticali col prodotto che gestisce il protocollo e la gestione documentale.

Sono già state implementate nell’ambito dei Sistemi Informativi del comune di Catania alcune integrazioni fra il protocollo ed applicazioni esterne sia leggere, legate alla consultazione del protocollo, sia più invasive che permettono di scrivere nel protocollo. In particolare il software per la gestione dell’ufficio per le attività produttive consente di protocollare eventuali richieste pervenute all’ufficio, questo avviene attraverso delle apposite interfacce offerte dall’applicativo del protocollo. Tali interfacce sono semplificate essendo i due prodotti realizzati sulla medesima piattaforma applicativa “Lotus Domino”.

Vincolare la piattaforma su cui le applicazioni da integrare devono essere realizzate non è comunque accettabile, tale scelta limiterebbe eccessivamente i prodotti utilizzabili.

La soluzione di integrazione indicata in questo progetto, deve essere dunque indipendente sia dalla piattaforma applicativa che di base su cui vengono fornite le applicazioni. Essa risponde a degli standard di mercato ampiamente consolidati, basandosi sull’utilizzo di web services.

Poiché la problematica non è specifica per il Comune di Catania, è titolo qualificante se la soluzione di integrazione è implementata in maniera nativa, facilmente configurabile e non è frutto di una personalizzazione dell’applicativo per il Comune di Catania. Questo garantisce infatti il mantenimento delle funzionalità di integrazione nella evoluzione dei prodotti e minori costi di manutenzione per l’ente.

Di seguito vengono indicati dei flussi standard evidenziando quali sono i requisiti a cui devono soddisfare sia il software di gestione documentale sia l’applicazione generica da implementare. Vengono anche evidenziati alcuni aspetti organizzativi.

Si farà riferimento alla gestione dei flussi attuali, ma vengono anche evidenziate le esigenze applicative nel momento in cui verranno attivati i meccanismi di firma digitale e di eliminazione dei passaggi di carta. Le soluzioni fornite dovranno essere coerenti a questi requisiti.

Per semplicità, nel seguito la procedura da integrare verrà indicata come Applicazione, mentre il sistema di gestione documentale comprensivo di protocollo verrà indicato come Protocollo.

L’entry point di tutte le richieste verso l’ente è il protocollo, in particolare tutte le richieste cartacee giungono a Palazzo degli Elefanti dove vengono protocollate e smistate verso i diversi servizi. Analogo a questo processo è l’invio della richiesta alla PEC del comune.

In aggiunta a ciò in alcuni casi la documentazione arriva direttamente alle singole Direzioni che hanno un proprio ufficio di protocollo e smistamento pratiche (è così per Pratiche Edilizie e Licenze Commerciali), dal punto di vista operativo cambia solo l’operatore che avvia la pratica sul Protocollo.

Nella definizione del flusso si deve quindi tenere conto di questa specificità. Verrà, comunque, anche indicata l’opzione di prevedere un meccanismo informale di invio di dati ed allegati necessari alla istruzione della pratica e che possano, previa verifica da parte del funzionario comunale, scatenare un nuovo elemento di protocollo. Questo è ad esempio il caso di una richiesta web attraverso l’interfaccia nativa dell’applicazione.

L’integrazione fra il protocollo e l’applicazione prevede che tutte le informazioni scambiate con l’ente, comprensive di eventuali allegati, anche firmati digitalmente vengano mantenute dal protocollo che deve garantire la corretta conservazione di tutti i documenti a prescindere dal mantenimento di altre applicazioni. E’ previsto inoltre che per semplicità le applicazioni, oltre a puntare alle informazioni presenti nel protocollo, ne creino una copia interna in modo da garantire una consultazione rapida e completa della pratica.

1) Richiesta proveniente dall’esterno con conseguen te istruzione di una nuova pratica a. Il primo passo avviene all’interno del programma del protocollo in cui manualmente, a seguito di una

missiva o di un fax, viene creata una nuova voce. Ciò avviene in automatico per le comunicazioni via PEC. Oggi nell’ambito delle attività del protocollo non viene definito un fascicolo, risultandone impossibile la verifica/definizione all’utente che inserisce i dati relativi alla richiesta.

L’operatore del protocollo assegna la pratica al responsabile del servizio interessato.

b. Il messo consegnerà fisicamente la pratica al responsabile, fino alla attivazione della comunicazione senza carta.

c. Il responsabile del servizio (o un suo delegato) istruisce la pratica sull’applicazione. Egli viene informato dell’esistenza della richiesta, oltre che dal messo, tramite il meccanismo di alert integrato nel

Page 15: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 15 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

protocollo. Sia quindi attraverso la posta elettronica sia attraverso opportune viste, ad esempio per data e servizio sul protocollo. Questo diventerà essenziale nel momento in cui non ci sarà più il messo che consegnerà la documentazione cartacea. Nell’istruire la pratica è opportuno che il protocollo e l’applicazione riescano a dialogare, trasferendo le informazioni rilevanti presenti nel protocollo all’applicazione attraverso opportuni web services. Per semplicità questa operazione può essere guidata dall’utente che nell’applicazione indica il protocollo da cui attingere. L’applicazione oltre che il numero del protocollo manterrà anche un URL allo specifico elemento di protocollo. Nell’istruire la nuova pratica l’operatore tramite l’applicazione potrà definire un nuovo fascicolo sul protocollo, in modo da garantire che le comunicazioni successive, generate dall’applicazione, siano gestite correttamente all’interno dello stesso fascicolo. La procedura dovrà comunque prevedere anche la trascrizione manuale, per garantire la continuità del servizio anche in mancanza del collegamento al protocollo.

Il responsabile del servizio, attraverso gli strumenti nativi del protocollo potrà effettuare le verifiche sul corretto assegnamento della pratica ed eventualmente rifiutarla, prima di procederne alla lavorazione all’interno della specifica applicazione.

Di seguito vengono evidenziati i requisiti dei diversi sistemi.

Protocollo • Deve esporre un web service che dato un numero restituisca le informazioni principali e gli allegati, garantendo la privacy di elementi non visibili a tutti.

• Deve esporre un web service per assegnare il fascicolo alla pratica • Deve essere interrogabile via web dalla intranet aziendale restituendo le

informazioni fondamentali opportunamente rappresentate • Deve fornire dei meccanismi di alert in caso in cui si riceva l’assegnazione di

una pratica. Sia attraverso la e-mail, sia attraverso delle viste nell’ambito del protocollo.

Applicazione • Deve essere parametrizzabile in modo da interrogare in maniera opportuna il web service esposto dal protocollo e acquisire i dati rilevanti e gli allegati presenti nel protocollo.

• Deve poter definire attraverso un opportuno web service il fascicolo della pratica sul protocollo, garantendo che questo sia univoco.

• Deve poter essere configurabile il titolario del protocollo da utilizzare. • Deve rispettare il meccanismo di autenticazione previsto dal web service del

protocollo, possibilmente in maniera trasparente all’utente che non deve digitare le proprie credenziali nel protocollo.

Organizzazione • Spingere ad utilizzare un meccanismo di verifica delle pratiche in carico e di eventuali rifiuto/reindirizzo

2) Comunicazioni interne all’applicazione, workflow della pratica

a. In questo ambito vengono trattati i passaggi di stato interni all’applicazione. Gli operatori autorizzati, nell’ambito delle funzionalità del proprio dominio, inseriscono le informazioni di loro competenza e effettuano ulteriori assegnazioni. Alcuni di questi passaggi è necessario che possano essere protocollati, anche quando sono interni all’ente. E’ opportuno che l’applicazione preveda che sia configurabile la registrazione dell’assegnazione sul protocollo. Il protocollo deve solo esporre l’interfaccia per permettere di salvare le informazioni rilevanti. Come nel caso dell’avvio della pratica deve essere conservato il link al protocollo così creato.

Non è prevista l’evidenza della Presa in Carico.

La reale comunicazione dell’assegnazione utilizza le funzionalità dell’applicazione (popup, mail se configurata nell’applicativo, comparsa negli elenchi delle pratiche di propria competenza, etc.).

b. Il messo consegnerà fisicamente la pratica in caso di protocollazione.

Questo aspetto risolve anche la problematica di invio di informazioni tra applicazioni differenti, entrambe legate a meccanismi di workflow, ma che non abbiano un’interfaccia nativa. Ad esempio copre la comunicazione fra SUAP e Licenze Commerciali. Cioè la richiesta verso il SUAP avverrà in questa modalità, mentre l’eventuale risposta o la richiesta arriverà come indicato al punto 3.

Protocollo • Deve esporre un web service che permetta di registrare una nuova voce nel protocollo, definendo anche il mittente.

• Deve esporre un web service che permetta di selezionare i destinatari già definiti nel protocollo, soprattutto quelli interni, per evitare di sporcare

Page 16: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 16 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

l’anagrafica dei destinatari con voci duplicate. • Deve eventualmente permettere di aggiungere un nuovo destinatario.

Applicazione • Deve essere parametrizzabile sui passaggi da effettuare. • Deve essere parametrizzabile in modo da interrogare in maniera opportuna il

web service e trasferire le informazioni nel protocollo all’interno del fascicolo corretto.

3) Comunicazioni verso l’esterno (pareri, ulteriore documentazione, accettazioni, dinieghi) a. In questo caso l’uscita deve avvenire tramite il protocollo che permette, attraverso le stesse

funzionalità utilizzate dalla procedura SUAP, di registrare sul fascicolo gli esiti. Deve trasferire al protocollo anche gli allegati che la procedura produce (nel caso in esame modelli di documenti compilati con i campi della pratica).

E’ perfettamente analogo al punto precedente.

4) Pareri ed integrazioni alla pratica dall’esterno E’ analogo alla tipologia di prima comunicazione, l’applicazione deve poter acquisire ulteriori allegati dal protocollo. I dati della pratica non possono essere modificati.

Protocollo • Identici al primo step

Applicazione • Deve essere parametrizzabile in modo da interrogare in maniera opportuna il web service esposto dal protocollo e acquisire ulteriori allegati, qualificandoli opportunamente. Deve mantenere il link al protocollo

La spedizione fisica, che utilizza lo strumento più adatto, cartaceo, fax o PEC, rimane all’interno dell’applicativo del protocollo, non viene resa dis ponibile attraverso web services.

Migliorie al flusso (attuale):

1) Precaricamento dei dati. In questo caso un utente esterno validato (per le pratiche edilizie abbiamo proposto di precaricare gli ingegneri, i geometri e gli architetti dai dati degli albi della provincia di Catania), inserisce le informazioni rilevanti per la pratica e fissa un appuntamento. Può anche inserire degli allegati. L’operatore accetta la pratica e la trasforma in un elemento di protocollo attraverso l’opportuno web service. Già indicato al punto 2. L’applicazione esterna deve garantire dei meccanismi di alert verso l’utente finale in modo che sia garantito sia della presa in carico del sistema sia della presa in carico da parte di un utente all’interno dell’applicazione.

2) Firma Digitale ed eliminazione della carta . Il compito della firma digitale deve essere a carico dell’applicazione. Attraverso le interfacce già analizzate vengono passati al protocollo i file firmati digitalmente. La procedura deve permettere di firmare digitalmente sia i documenti che le eventuali stampe su pdf. Il protocollo deve comunque gestire e permettere la firma digitale.

Page 17: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 17 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

Figura 1 - Gestione

Figura 2 - Consultazione

4.3 Banca dati del personale La gestione di questo sottosistema è fuori dall’ambito dell’incarico.

Page 18: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 18 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

Le informazioni gestite in questo ambito hanno una rilevante ricaduta sugli altri sottosistemi:

• Collegamento alle utenze applicative (creazione dismissione)

• Definizione corretta dei profili organizzativi

• Banca dati del personale ed organizzazione degli uffici.

La banca dati del personale e l’organigramma hanno una ricaduta oltre che sulla specifica gestione del personale, permettendo di tracciare i passaggi di uffici, mansioni, responsabilità etc. su tutti i sistemi di workflow, ma anche sul sistema di controllo di gestione per individuare l’assegnazione del personale, dei beni e dei capitoli di spesa, sul sistema di gestione dell’inventario etc.

Ha anche una funzione basilare nella verifica offline dei profili autorizzativi dei diversi utenti.

E’ opportuno che ciò sia ambito di un futuro progetto verticale.

L’applicazione del protocollo oggi dispone del repository più aggiornato riguardo all’organizzazione comunale.

Nell’ambito di questo progetto (sottoprogetto 2) verrà resa disponibile attraverso una piattaforma relazionale l’insieme delle informazioni anagrafiche relative all’organizzazione Comunale presenti sul protocollo ed in particolare direzioni, posizioni organizzative, responsabili, ruoli facenti funzione e di segreteria oltre che il personale appartenente alle stesse.

Tutte le applicazioni interessate dovranno fare riferimento a queste strutture in modo da centralizzare l’informazione.

4.4 Tributi Ragioneria Il sistema Tributi/Ragioneria è fortemente legato verso gli altri sottosistemi.

Attingerà dati dai seguenti sottosistemi:

• Sistema del commercio:

o Elenco licenze commerciali con dettagli di tipologia, superfici, inizi e durate, atti a definire la TARSU;

o Elenco licenze commerciali ambulanti e fiere con dettagli atti a definire la TOSAP;

• SIT:

o Passi carrai con dettagli, in fase di censimento, atti a definire la TOSAP

• SIT Catasto/Anagrafe Edilizia:

o Informazioni atte a verificare TARSU e ICI (Immobili, aree edificabili)

• Pratiche Edilizie

o Notifica flussi previsionali per periodi

Page 19: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 19 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

Fornirà dati ai seguenti sottosistemi:

• Sistema del commercio:

o Posizioni TOSAP e TARSU

• Controllo di gestione

o Dati relativi alla contabilità

Deve permettere l’interrogazione sullo stato dei pagamenti, e registrare i pagamento effettuati on line.

4.5 Sistema Informativo Territoriale Il sistema informativo territoriale riveste un ruolo fondamentale nei confronti degli altri sottosistemi. Esso infatti dispone delle informazioni relative al territorio, sia di tipo cartografico che relazionale.

Nell’ambito del presente progetto si prevede che possa mettere a disposizione oltre alla cartografia di base completata con i civici degli edifici, anche l’anagrafe edilizia comunale alimentata dalle informazioni provenienti dal catasto e che si prevede di bonificare con il prossimo censimento.

È anche in corso un censimento dei passi carrai.

Gli strumenti messi a disposizione e le informazioni ospitate risultano fondamentali per:

• Una corretta pianificazione. Attraverso l’integrazione con l’anagrafe, già operativa, si ha una chiara visione della distribuzione geografica della popolazione; è inoltre obiettivo del presente progetto individuare la localizzazione delle diverse attività commerciali.

• Una corretta gestione dell’anagrafe edilizia con ricadute sul piano dell’equità fiscale.

• Mettere a disposizione banche dati di supporto a tutti gli altri uffici.

4.6 Pagamenti on-line Il sistema di pagamenti on line mette a disposizione una piattaforma e un insieme di procedure per l’espletamento e la visualizzazione dei pagamenti on line e per la validazione degli utenti esterni.

A parte Contravvenzioni e ICI (peraltro già interessate dalla gestione dei pagamenti On line nel progetto Etn@Online) che utilizzano form di pagamento specifici, tutte le altre forme di incasso identificabili univocamente tramite un “Id” (Es. num/anno) sono candidate a poter essere trattate attraverso forme di pagamento e visualizzazione On Line. Tra le possibili tipologie di pagamento effettuabili si citano le più interessanti:

• Oneri concessioni edilizie

• Diritti di istruttoria Sportello Unico Attività Produttive

• Diritti di segreteria delle attività del Servizio Urbanistica

• Canoni illuminazione votiva

• Incassi per operazioni cimiteriali

• Incassi per Servizi Educativi: Colonia marina e centri estivi

• Incassi Servizi Educativi: Asili nido, mense, trasporto scolastico, prescuola

• incassi per ICP (Imposta Comunale sulla Pubblicità)

• Incassi TOSAP (Tassa per l'occupazione spazi ed aree pubbliche)

• incassi per concessioni Sale Comunali Circoscrizionali ed Aree Ortive

• Quote per l'utilizzo di Impianti Sportivi

L’interazione tra il sistema di pagamenti On Line e le applicazioni può avvenire sia attraverso l’utilizzo di Web Services (sia sul lato dell’applicazione che sul lato della piattaforma di pagamenti on line) che mediante l’utilizzo di scambio reciproco di files batch. Di fatto viene preferita in assoluto la prima soluzione.

Page 20: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 20 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

Al fine di poter fruire del servizio di pagamenti on line anche rispetto ad applicazioni non integrabili con lo standard di comunicazione sopradescritto viene prevista una modalità di scarico batch unilaterale (piattaforma pagamenti on-line�applicazione) degli incassi ricevuti, al fine di consentire una importazione off-line dei dati relativi ai pagamenti ricevuti.

Vengono previsti infine strumenti di management e reportistica per la visualizzazione delle liste e del dettaglio dei pagamenti effettuati filtrati per scope di interesse e user authorization.

Pagamenti On Line

• Espone Web Service e Web Method per il recupero dei dati relativi ai pagamenti effettuati.

• Fornisce strumenti di management per il filtering dello scope di interesse e le policy di user authorization.

• Fornisce strumenti per l’export, la visualizzazione di insieme e di dettaglio dei pagamenti effettuati secondo i filtri sopra descritti.

Applicazione • Espone Web Service e Web Method per il recupero dei dati relativi ai pagamenti da effettuare ed effettuati sotto altra forma.

4.6.1 Integrazione delle utenze esterne

Il sistema Etn@Online gioca un ruolo centrale nella gestione delle utenze di cittadini ed aziende che usufruiscono di servizi web messi a disposizione dal Comune di Catania.

Come già descritto nel paragrafo relativo all’autenticazione degli utenti, questo è l’unico sistema di definizione e validazione di utenti esterni, su cui devono poggiarsi tutte le applicazioni che esporranno delle funzionalità web soggette ad autenticazione.

La problematica è ben definita, esistono anche degli standard in via di assestamento come ad esempio il “SAML”.

Security Assertion Markup Language. SAML definisce uno standard per lo scambio di dati di autenticazione e autorizzazione tra domini di sicurezza distinti, garantendo il dialogo tra un identity provider (entità che fornisce informazioni di identità) e un service provider (entità che fornisce servizi). Il formato delle asserzioni SAML è basato su XML.

Il problema principale che SAML cerca di risolvere è quello del Web Single Sign-On (SSO) tra entità appartenenti a organizzazioni e domini di sicurezza distinti.

Page 21: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 21 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

SAML definisce che l'utente (detto "principal") sia registrato presso almeno un identity provider. L'identity provider deve provvedere ad autenticare l'utente. Il service provider a questo punto si affida all'identity provider per identificare il principal. Su richiesta del principal l'identity provider passa una asserzione SAML al service provider sulla base della quale quest'ultimo decide se permettere o negare l'accesso ai propri servizi da parte del principal.

Lo standard SAML non è ancora del tutto consolidato e non rappresenta ancora uno “standard di mercato” Sarà elemento qualificante essere compliant a SAML2.

Come nel caso del protocollo vengono qui descritte le modalità di interazione che dovranno essere garantite sia dalla piattaforma Etn@Online che da tutte le applicazioni web che richiedono servizi di autenticazione.

La piattaforma Etn@Online dovrà:

o Mantenere il database degli utenti esterni

o Garantire i servizi di autenticazione degli utenti esterni per tutta la piattaforma web del Comune di Catania

Di seguito viene indicato il flusso standard evidenziando quali sono i requisiti a cui devono soddisfare sia il software Etn@Online sia l’applicazione generica da implementare. Vengono anche evidenziati alcuni aspetti organizzativi. Il caso in esame è quello della richiesta di accesso a servizi non anonimi da parte di un utente non validato.

Applicazione generica Piattaforma Etn@Online

Redirect ad un’apposita pagina web del portale Etn@Online con l’indicazione della pagina per la registrazione dell’utenza da richiamare al termine di un riconoscimento con successo.

Consente il logon all’utente.

In caso di successo:

• Crea un ticket per individuare l’utente

• Richiama la pagina indicata nella richiesta di autenticazione passando il ticket

La pagina da utilizzare per la registrazione dell’utenza richiama un web service messo a disposizione dalla piattaforma Etn@Online con parametro il ticket ricevuto.

Il Web service per la gestione del ticket restituisce i dati significativi dell’utente che è stato validato (Codice Fiscale o Partita IVA) ed altre informazioni puramente descrittive (cognome e nome) etc.

Quindi rimuove il ticket

Da questo momento in poi utilizza le informazioni ricavate dal web service per permettere all’utente le azioni di sua competenza, secondo il profilo che gli compete.

Nel caso di primo accesso lo registra nella propria anagrafica.

Non si ritiene necessario ai fini di una gestione semplificata delle utenze dover definire in maniera esplicita gli utenti (attraverso la chiave codice fiscale o partita iva) anche nelle applicazioni generiche. Potranno essere registrati al primo accesso attraverso le informazioni ricavate dal web service.

Nel caso in cui, si voglia invece controllare gli utenti abilitati all’utilizzo dell’applicazione generica, gli stessi potranno essere definiti all’interno dell’applicazione con un profilo particolare.

Page 22: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 22 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

5. Pianificazione di massima In questo capitolo viene riportato un GANTT complessivo che è solamente indicativo e non è assolutamente vincolante, delle durate e delle relazioni fra i vari progetti. La pianificazione riportata è particolarmente ottimistica prevedendo:

o Tempi rapidi di pubblicazione ed aggiudicazione dei bandi di gara

o Assenze di ritardi

o Ampio grado di parallelismo

Le durate e le scadenze verranno specificate in maniera dettagliata nei singoli sottoprogetti.

L’avvio dei singoli sottoprogetti avverrà secondo le disponibilità delle diverse direzioni interessate e secondo le modalità di aggiudicazioni utilizzate.

Le durate saranno inoltre condizionate anche dalle durate dei progetti da cui dipendono in particolare dal sottoprogetto 1.

ID Task Name Durata

1 Sottoprogetto 1 21 giorni?

2 Aggiudicazione 0 giorni?

3 Consegna Hardware 21 gi orni?

4 Disponibi lità server 0 giorni?

5 Sottoprogetto 2 60 giorni?

6 Affidamento servi zi 0 giorni?

7 Svi luppi e personal izzazi oni 20 gi orni?

8 Instal lazione e formazione 20 gi orni?

9 Col laudo fi nale 0 giorni?

10 Sottoprogetto 3 - S.I.T. 84 giorni?

11 Affidamento servi zi 0 giorni?

12 Anali si, migrazi one piattaforma e dati 22 gi orni?

13 Upgrade pi attaforma e install azione appl icazioni 22 gi orni?

14 Creazione banche dati e formazione 22 gi orni?

15 Col laudo fi nale 0 giorni?

16 Sottoprogetto 3 - Pratiche Edil izie ############

17 Aggiudicazione 0 giorni?

18 Anali si e sviluppo del la soluzione finale 40 gi orni?

19 Instal lazione, formazione e avviamento 64 gi orni?

20 Col laudo fi nale 0 giorni?

21 Sottoprogetto 3 - Licenze Commercial i 89 giorni?

22 Aggiudicazione 0 giorni?

23 Anali si e sviluppo del la soluzione finale 35 gi orni?

24 Instal lazione, formazione e avviamento 54 gi orni?

25 Col laudo fi nale 0 giorni?

26 Sottoprogetto 4 90 giorni?

27 Affidamento servi zi 0 giorni?

28 Upgrade della piattaforma Pagamenti OnLine 44 gi orni?

29 Confi gurazi one pagamenti per Prat iche Edili zie 20 gi orni?

30 Formazione e aff iancamento 20 gi orni?

31 Col laudo fi nale 0 giorni?

32 Sottoprogetto 5 80 giorni?

33 Aggiudicazione 0 giorni?

34 Anali si e sviluppo del la soluzione finale 40 gi orni?

35 Instal lazione 20 gi orni?

36 Formazione 20 gi orni?

37 Col laudo fi nale e Inizio service 1° Anno 0 giorni?

38 Sottoprogetto 6 ############

39 Aggiudicazione 0 giorni?

40 Anali si e sviluppo del la soluzione finale 40 gi orni?

41 Cablaggi o, instal lazione HW e SW, formazi one 95 gi orni?

42 Col laudo fi nale 0 giorni?

29/01

Disponibilità server 26/02

04/01

26/03

04/01

29/04

01/03

28/07

01/03

01/07

04/01

07/05

01/03

18/06

01/03

03/09

28/12 11/01 25/01 08/02 22/02 08/03 22/03 05/04 19/04 03/05 17/05 31/05 14/06 28/06 12/07 26/07 09/08 23/08 06/09gennai o febbrai o marzo aprile maggio giugno luglio agosto settembre

Page 23: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 23 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

6. Modalità di esecuzione del progetto In questo capitolo vengono riportati dei requisiti di natura organizzativa comuni all’esecuzione di tutti i progetti.

6.1 Fasi del progetto In questo paragrafo vengono riportate le varie fasi in cui si scompone un progetto di informatizzazione, evidenziando deliverables, templates e linee guida che regolano tutto il ciclo di vita del progetto.

Di seguito si propone il ciclo di esecuzione ‘tipo’ di un progetto realizzativo e per ogni fase esecutiva si propone l’elenco dei documenti che devono essere prodotti.

6.1.1 Fase I – Impostazione del progetto

In questa fase vengono definite le attività preliminari all’implementazione. Riguardano solo l’ambito successivo all’aggiudicazione e non le progettazioni di massima e di dettaglio su cui si basa il capitolato.

Attività Descrizione attività Deliverables Milestones

Analisi e definizione della soluzione

Presentazione documento 4 Documento di analisi 4 Pianificazione 4 Curriculum Risorse

Aggiudicazione Gara

Impostazione del progetto

Impostare il progetto in termini di ambito, tempi e modi, team di lavoro. Specifiche di Dettaglio.

4 Piano di gestione del progetto

4 Piano di gestione dei rischi

4 Specifiche di dettaglio

Piano di gestione del progetto e dei rischi approvato

Pianificazione attività

Pianificare nel dettaglio la fase Condivisione pianificazione

4 Piano di progetto 4 Fabbisogni GdL

Piano di dettaglio approvato

Lancio ufficiale del progetto

Preparazione del kick-off Riunione di kick-off che ufficializza e presenta l’avvio delle attività già concordate

4 Kick-off kick-off approvato

6.1.2 Fase II – Realizzazione del progetto

In questo paragrafo sono indicate le fasi relative alla realizzazione, alla consegna ed al test dell’applicazione

Attività Descrizione attività Deliverables Milestones

Impostazione della fase

Verifica logistica; Installazione del sistema predisposizione dell’ambiente

4 Documento dei requisiti tecnici della piattaforma

Predisposizione ambiente operativo

Sviluppo del sistema

Realizzazione del Sistema Test Sistema; Realizzazione manuali; Analisi e disegno profili applicativi;

4 Documentazione tecnica Soluzione

4 Disegno dei profili 4 Manuali utente 4 Manuale Amministratori 4 Documentazione Banca dati

Sviluppo concluso

System test Pianificazione system test Predisposizione system test Realizzazione system test

4 Piano dei test 4 Verbale di collaudo

System test approvato

Page 24: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 24 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

6.1.3 Fase III – Rilascio

In questo paragrafo sono indicate le fasi relative al rilascio in produzione dell’applicazione.

Attività Descrizione attività Deliverables Milestones

Impostazione della fase

Pianificazione di dettaglio del rilascio (Import dati – attivazione interfacce – schedulazioni job – installazioni - test di rilascio)

4 Manuale per l’esecuzione dei Job 4 Report dei Job 4 Manuale interfacce

Predisposizione ambiente

Addestramento utenti Chiusura tutte attività tecniche propedeutiche al rilascio

4 Piano della formazione 4 Documentazione utente

Ambiente pronto Utenti addestrati

Rilascio del sistema

Comunicazione popolazione interessata sulle modalità di rilascio e del post-avviamento Go live Rilascio del sistema in esercizio e passaggio di consegne ai Sistemi Informativi

4 Manuali per l’Operation (tecnici, monitoring, etc..)

4 Verbale chiusura progetto 4 Piano di Collaudo

Sistema rilasciato

Collaudo Collaudo finale della fornitura 4 Verbale di collaudo finale Sistema collaudato

6.1.4 Fase IV – Gestione e Manutenzione

In questa fase vengono richiesti i rapporti di intervento.

Attività Descrizione attività Deliverables Milestones

Post avviamento Gestione post avviamento 4 Rapporti di intervento

Si richiedono almeno 24 mesi di garanzia dalla data di collaudo della soluzione. Sarà elemento di valutazione preferenziale un periodo maggiore di qu ello espressamente indicato.

La manutenzione sia nel periodo di garanzia che quella acquistata successivamente deve garantire i seguenti servizi:

• Aggiornamenti programmati del software applicativo (service pack, nuove versioni) e della documentazione, inclusi upgrade che scaturiscono da aggiornamenti normativi che non modificano in maniera sostanziale le logiche applicative.

• Manutenzione correttiva (tutte le azioni necessarie ad identificare e rimuovere errori e/o comportamenti dell'applicazione non conformi alle specifiche contenute nella documentazione di progetto e/o prodotto)

• Hot-line telefonica e tele-assistenza con analisti e programmatori su tematiche di malfunzionamenti o verifiche di fattibilità entro 30 minuti dalla richiesta

• In caso di errore deve essere garantita la ripresa della funzionalità entro giorni tre dalla richiesta.

• In caso di manifesta esigenza l’intervento on-site deve essere garantito entro giorni tre e negli orari di servizio dell’Ente, a giudizio insindacabile di quest’ultimo.

Per la definizione della manutenzione alla scadenza della garanzia, si richiede al Fornitore in fase di Gara di fornire il costo annuale a cui si atterrà a meno delle rivalutazioni ISTAT. Il costo di tale servizio costituirà elemento qualificante nell’aggiudicazione.

Page 25: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 25 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

6.2 Luogo di Esecuzione I sopralluoghi, le attività di analisi, le riunioni (Kick off, SAL, Incontri, ecc.) e le attività di installazione e collaudo verranno effettuati presso i Sistemi Informativi del Comune di Catania.

6.3 Lingua Le attività progettuali e la documentazione di progetto saranno in italiano.

6.4 Piano di lavoro L’esecuzione delle attività di progetto verrà regolata da un apposito piano di dettaglio in cui il Fornitore indicherà l’elenco delle attività da svolgere, i materiali da utilizzare, la stima dei tempi, delle scadenze, delle interdipendenze, delle responsabilità e delle risorse necessarie per ciascuna attività. All’interno del piano dovranno essere indicate le milestones di rilascio per ogni deliverable e di approvazione del cliente.

Il Fornitore dovrà altresì fornire una descrizione del percorso critico del piano di lavoro, con l’indicazione dei possibili impatti che il ritardo di ogni attività potrà causare sulla data pianificata di completamento del progetto.

Tale piano:

• Terrà in considerazione le date di rilascio vincola nti indicate nel progetto esecutivo;

• Sarà vincolante;

• Sarà parte integrante del contratto previa approvazione da parte del Comune.

6.5 Team Vista l’importanza e la rilevanza di risorse e mezzi coinvolti, il progetto necessita di una struttura organizzativa, di controllo e di reporting efficace.

Si richiede, pertanto, una proposta di struttura organizzativa del progetto (es.: Comitato guida, Team di lavoro, Capo Progetto Fornitore, ecc.) mista tra Comune di Catania, Direzione dei lavori e Fornitore, con l’indicazione delle funzioni del Comune di Catania che dovranno essere parte integrante della struttura e l’indicazione precisa e puntuale dei ruoli, delle competenze e delle responsabilità, sia delle risorse del Fornitore che di quelle del Comune di Catania con il dettaglio del piano di effort mensile, stimato in numero di giornate identificate per ciascun mese del progetto per tipologia di figura professio nale .

Si richiede inoltre che durante lo svolgimento delle normali attività di progetto siano osservate le seguenti linee guida nella gestione delle risorse:

• Garantire continuità sul Core Team, senza sostituzione di risorse per tutta la durata del progetto. Nel caso in cui si rendesse necessaria una sostituzione per cause di forza maggiore le modalità di sostituzione e le tempistiche dovranno essere concordate con la direzione dei lavori;

• Garantire la presenza continuativa delle risorse senior per tutta la durata del progetto. Nel caso in cui si renda necessaria la sostituzione di una tale figura, il Fornitore deve garantire un preavviso di almeno 30gg ed un periodo di affiancamento non inferiore a 15 gg.

Il Fornitore dovrà allegare all’offerta il dettaglio dei CV delle singole risorse che faranno parte del Team dedicato. La Direzione dei lavori si riserva il diritto di valutare il CV delle risorse basata sulle esperienze pregresse presenti all’interno della documentazione fornita.

6.6 Monitoraggio del progetto Il Fornitore dovrà, inoltre, pianificare, con cadenza quindicinale, le riunioni di avanzamento lavori (SAL) e con cadenza mensile gli incontri del comitato di gestione, con particolare evidenza di:

• Scostamenti rispetto al programma previsto;

• Problematiche sorte;

• Suggerimenti o proposte di adeguamento delle soluzioni progettuali.

Nel caso in cui si verifichino dei ritardi nell’attività si richiede al Fornitore di:

Page 26: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 26 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

• segnalare l’entità del ritardo;

• analizzarne le cause;

• valutarne le conseguenze;

• redigere un opportuno piano di rientro.

6.7 Deliverable In questo paragrafo vengono descritti tutti i deliverables da consegnare nei singoli sottoprogetti.

Queste informazioni sono generali ma non necessariamente applicabili integralmente a tutti i sottoprogetti.

La documentazione, il software e tutti gli elaborati previsti dovranno essere consegnati alla Direzione dei Lavori, che provvederà ad approvarli. In particolare la documentazione dovrà coprire l’intero ciclo di sviluppo e contenere la traccia dei procedimenti seguiti, delle scelte logiche e tecniche concordate, degli interventi di correzione ed ottimizzazione eseguiti.

Il Fornitore, quindi, deve consegnare, oltre ai documenti di gara, tutti i seguenti elaborati previsti dai documenti di specifica citati nel presente Capitolato:

Fase 1 (Impostazione del progetto):

• Piano di gestione del progetto • Specifiche di dettaglio • Piano di progetto • Piano dei rischi • Fabbisogni GdL • Documento di Kick Off

Fase 2 (Fornitura ed installazione degli apparati e Piattaforma informatica)

• Documentazione tecnica dei requisiti di base e di installazione; • Procedure per la creazione degli schema sul DB • Procedure di installazione sia lato client che lato server • Documento infrastruttura; • Documentazione tecnica Soluzione • Disegno dei profili • Manuali utente • Manuale Amministratori • Documentazione Banca dati • Pianificazione della fase di test. • Verbale di collaudo

Fase 3 (Rilascio)

• Job di import • Manuale per l’esecuzione dei Job • Report dei Job • Documentazione Interfacce • Piano della formazione • Documentazione utente • Manuali di esercizio: tecnici, monitoring, help desk, Gestione Profili; • Documento della Sicurezza • Manuale utente; • Verbale chiusura progetto • Piano di collaudo • Verbale di collaudo finale

Page 27: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 27 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

Il Documento della Sicurezza contiene i requisiti di sicurezza logica dell’applicazione in termini di integrità, riservatezza, disponibilità e le specifiche per l’accessibilità al sistema, sia per le attività ordinarie che per le attività di auditing, e i controlli e le modalità di registrazione e archiviazione delle operazioni. Sono descritte in modo dettagliato le politiche di backup implementate con la descrizione della metodologia applicata, la periodicità delle operazioni di salvataggio sia riferita all’ambiente applicativo che alla Base Dati. Contiene inoltre tutte le informazioni utili a redigere il documento programmatico sulla sicurezza.

7. Garanzia, vincoli e penali Condizione necessaria per l’ammissibilità e per l’approvazione della chiusura di progetto sarà il rispetto dei requisiti definiti nel Capitolato.

Saranno considerate, come riferimento in caso di contenziosi, le richieste espresse nel presente Capitolato e non quanto definito nelle offerte tecniche del Fornitore.

Il contratto che verrà stipulato tra il Comune di Catania ed il Fornitore, prevederà penalità, ammontare massimo delle stesse e facoltà di risoluzione del contratto da parte del Comune di Catania, ed eventuale valutazione dei danni stimati, in caso di ritardo rispetto al piano di lavoro condiviso.

La direzione dei lavori applicherà penali in caso di ritardata fornitura rispetto alla tempistica individuata nei diversi sottoprogetti.

8. Documenti da Presentare nell’Offerta Tecnica di Fornitura L’offerta tecnica di fornitura dovrà essere composta da tutti i documenti che contengano le informazioni che intervengono nella valutazione complessiva dell’offerta:

• Descrizione della soluzione proposta, indicando il prodotto e le personalizzazioni, allegando eventuali depliants (Documento massimo 20 pagine). Dovranno essere esplicitamente indicate tutte le caratteristiche qualificanti della soluzione, come evidenziate nel presente documento e nel progetto specifico, in modo da poterla valutare correttamente.

• Il Comune di Catania si riserva la possibilità di escludere dall’acquisto singole parti (come ad esempio licenze base) dell’offerta totale formulata dal Fornitore, o procedere successivamente all’estensione di servizi come la formazione o la manutenzione. L’offerta economica dovrà quindi essere ampiamente dettagliata per permettere tali attività.

Il fornitore deve evidenziare quindi, oltre al costo complessivo, il dettaglio dei costi relativi a:

o Licenze base delle applicazioni

o Eventuali licenze di software di base richieste (es. database)

o Personalizzazioni

o Servizi di installazione e configurazione

o Servizi di formazione con l’indicazione del costo giornaliero

o Servizi di avviamento

o Servizi aggiuntivi (import di dati, etc.)

o Costo di manutenzione annuo

• Livelli di Servizio – Documento massimo 2 pagine

• Descrizione del Fornitore e delle referenze – Documento massimo 10 pagine

• Piano di Progetto – Documento Project

• Team di lavoro del Fornitore – Documento massimo 10 pagine

• Deliverable (secondo quanto richiesto nel par. 6.6) – Documento massimo 2 pagine

Per quanto riguarda l’aspetto architetturale si richiede:

• Di evidenziare le componenti Hardware e Moduli Software che il Fornitore utilizzerà per la realizzazione dell’architettura proposta.

Page 28: Riorganizzazione dei Sistemi Informativi Comunali · progettazione e direzione lavori del “Progetto di riorganizzazione dei sistemi informativi comunali” relativamente ai Sottoprogetti

Data 18/11/2009 Committente: Comune di Catania Progetto Esecutivo generale Pagina 28 / 28

Rev. 1.0 Commessa: comct-0901 Riorganizzazione dei Sistemi Informativi Comunali

• Di fornire una descrizione dettagliata dei moduli standard che dovranno essere implementati, inclusiva delle specifiche quantitative/qualitative delle possibilità di customizzazione di ciascun modulo.

• Di descrivere il ciclo di vita del prodotto: indicare quando è stato realizzato, quanti aggiornamenti successivi ci sono stati, i piani futuri di sviluppo del prodotto con l’indicazione delle major release previste.

Al fine di valutare l’usabilità (standard ISO) di ogni singola soluzione proposta, ove necessario, verrà richiesta una dimostrazione in loco del prodotto offerto, da realizzarsi secondo criteri, tempi e punti di interesse prefissati. Le modalità e le caratteristiche delle dimostrazioni da effettuare sono specificate nel c.s.a. dei sottoprogetti interessati da tale attività.