Contract

Capitolato Speciale d’Appalto

Tipo procedura: Aperta (Sopra Soglia)

Criterio di scelta: Offerta economicamente più vantaggiosa

Appalto per la realizzazione e la manutenzione di un sistema informativo di gestione dei servizi demografici, tributari e finanziari del Comune di Napoli.

Definizioni

SA=Stazione Appaltante

CSA= Capitolato Speciale di Appalto

SI = Sistema informativo integrato oggetto di gara composto dal modulo demografico, tributario e finanziario

Short time Services = servizi e/o forniture da erogare nella fase iniziale del contratto

All time Services = servizi e/o forniture da erogare per tutta la durata del contratto

S.A.S.I. = Servizio Autonomo Sistemi Informativi

INDICE

Premessa 5

Sezione I – Caratteristiche generali dell’Appalto			Pag
Art. 1	Oggetto		8
Art. 1 bis	Opzione di scelta		9
Art. 1 ter	Periodo di parallelismo		10
Art. 1 quater	Parziale estensione della garanzia		10
Art. 2	Durata		10
Art. 3	Cronoprogramma		10
Art. 4	Accesso al know how attuale e ai sistemi		10
Art. 5	Quadro giuridico di riferimento		10
Art. 6	Importo a base di gara		11
Art. 7	Servizi innovativi		11
Art. 8	Luogo ed orario di lavoro		11
Sezione II – Aspetti tecnici
Art. 9	Contesto tecnologico attuale		14
9.1	Sistema Informativo Tributario		14
9.2	Sistema Informativo Demografico		18
9.3	Sistema Informativo Finanziario		21
9.4	Server Farm		22
Art. 10	Requisiti della soluzione applicativa		25
10.1	Requisiti minimi della soluzione offerta		25
10.2	Requisiti aggiuntivi		28
10.3	Requisiti minimi specifici per area		29
Art. 11	Servizi e formazione		32
11.1	Manutenzione/Gestione applicativi		32
	11.1.1	Manutenzione correttiva e adeguativa	33
			34
	11.1.2	Manutenzione evolutiva
	11.1.3	Modalità di erogazione	36
	11.1.4	Figure professionali	41
	11.1.5	Dimensionamento della fornitura della manutenzione evolutiva	45
11.2	Manutenzione sistemistica		46
	11.2.1	Modalità di erogazione dei servizi di assistenza sistemistica	50
	11.2.2	Figure professionali richieste	52
	11.2.3	Dimensionamento della fornitura della manutenzione sistemistica	54
11.3	Formazione		55
	11.3.1	Aspetti generali	55
	11.3.2	Corso per Operatori	56
	11.3.3	Corso per Amministratori di sistema	56
11.4	Help Desk		57
Sezione III – Gestione del contratto
Art. 12	Referente tecnico dell’Aggiudicatario		60
Art. 13	Documentazione tecnica per l’Aggiudicatario		60
Art. 14	Gestione della Qualità		61
Art. 15	Direzione dei lavori		91
Art. 16	Progettazione del test e Collaudi		96
Art. 17	Ponderazione finanziaria dei moduli		98
Art. 18	Modalità di fatturazione e prezzi		99

Art. 19	Penali	99
Art. 20	Brevetti e diritti d’autore	103
Art. 21	Cessazione del servizio e attività di fine contratto	103
Art. 22	Condizioni del servizio e responsabilità	103
Art. 23	Norme di sicurezza	104
Art. 24	Estensione del contratto	104
Art. 25	Obblighi derivanti dal rapporto di lavoro	104
Art. 26	Assicurazione	105
Art. 27	Garanzie	105
Art. 28	Subappalto	105
Art. 29	Cessione del contratto	106
Art. 30	Tracciabilità dei flussi finanziari	106
Art. 31	Fallimento dell’appaltatore o morte del titolare	106
Art. 32	Sospensione del servizio	106
Art. 33	Sciopero	107
Art. 34	Tutela della privacy e riservatezza	107
Art. 35	Cauzioni	107
Art. 36	Responsabile del procedimento	108
Art. 37	Riferimenti della Stazione Appaltante	108
Art. 38	Informazioni varie	108
Art. 39	Riferimenti dell’Aggiudicatario	108
Art. 40	Rinuncia all’aggiudicazione	108
Art. 41	Foro competente	108
Art. 42	Rinvio ad altre leggi e disposizioni	109
Art. 43	Risoluzione	109
Sezione IV – Disciplina della gara
Art. 44	Soggetti ammessi	111
Art. 45	Requisiti di partecipazione	111
Art. 45 bis	Sopralluogo	112
Art. 46	Avvalimento	112
Art. 47	Contributo a favore dell’AVCP	112
Art. 48	Garanzia provvisoria	112
Art. 49	Criteri di valutazione dell’offerta	112
Art. 50	Offerta tecnica	113
Art. 51	Offerta economica	116
Art. 52	Discriminanti in caso di parità di punteggio complessivo	116
Art. 53	Video Tutorial e Demo	116
Art. 54	Partecipazione alla gara	118
Art. 55	Contenuto della “Busta A- Documentazione Amministrativa”	118
Art. 56	Contenuto della “Busta B - Offerta tecnica”	120
Art. 57	Contenuto della “Busta C- Offerta economica”	120
Art. 58	Procedura di aggiudicazione e verifica dei requisiti	121
Art. 59	Inizio della fornitura	122
Art. 60	Richieste di chiarimenti	122
Art. 61	Disposizioni finali e avvertenze	122

Premessa

Il Comune di Napoli con la procedura disciplinata dal presente CSA intende ottimizzare l’utilizzo di parte del proprio sistema informativo in termini organizzativi, tecnici ed economici, attraverso la razionalizzazione dell’attuale infrastruttura tecnologica ed applicativa, in linea con la strategia dell’Amministrazione rispetto all’ICT e attraverso la riduzione dei costi di gestione dell’attuale sistema, che non si basa sull’integrazione moltiplicando e duplicando in taluni casi le risorse da impiegare. Nello specifico, i vantaggi che ne conseguirebbero sono di seguito descritti:

a) aumentare la fruibilità dei dati, l’ottimizzazione dei flussi informatici e l’interconnessione con le banche dati interne ed esterne al Comune di Napoli;

b) rimuovere gli attuali limiti di integrazione e sinergia fra i principali sistemi informativi dell’Amministrazione, eliminando i limiti indotti da un approccio verticale che ne hanno caratterizzato spesso il percorso di sviluppo;

c) consolidare le attività di cooperazione informatica tra la Toponomastica cittadina, il Catasto, l’Anagrafe Tributaria, l’Anagrafe Comunale, l’Agente della Riscossione e l’Anagrafe della Camera di Commercio;

d) attivare processi di Data quality (normalizzazione, standardizzazione e validazione dei dati);

e) migliorare, razionalizzare ed integrare la comunicazione con il cittadino (stakeholder) in termini di trasparenza, semplicità di accesso anche con canali distributivi alternativi, alleggerendo, contemporaneamente, gli uffici dall’afflusso agli sportelli (front-office);

f) incrementare la lotta all’evasione/elusione tributaria;

a) ridurre la frammentazione delle forniture e definire un indirizzo gestionale unico che consenta di contenere i costi di gestione e manutenzione del software di base, d’ambiente ed applicativo, ed aumentare parallelamente la qualità dei servizi;

b) incrementare le attività formative del proprio personale tecnico informatico anche secondo la modalità “training on the job” finalizzandole ad una sempre più autonoma e completa attività di gestione;

c) dotarsi di una infrastruttura tecnologica per le attività di gestione, misurazione e controllo dei parametri di qualità dei servizi erogati;

d) rendere più efficaci ed efficienti le attività di conduzione e gestione secondo una vision sempre più professionale e tecnologicamente avanzata.

Pertanto l’ente ha deciso di bandire una gara per “la realizzazione e la manutenzione di un sistema informativo per la gestione dei servizi demografici, tributari e finanziari del Comune di Napoli”. Tale sistema dovrà risultare coerente con le linee guida del nuovo CAD - Codice dell'Amministrazione Digitale - di cui al D.Lgs. 235/2010, che stabilisce le regole per la digitalizzazione della Pubblica Amministrazione che deve favorire gli utenti ( i cittadini ed imprese) nell’accesso ai nuovi diritti che il codice stesso precisa e definisce.

La riforma del CAD di cui al X.Xxx. 235/2010 assume tra i presupposti la convinzione che la digitalizzazione dell'azione amministrativa sia una vera e propria funzione di governo, imperniata sui principi di Effettività e Risparmio come di seguito evidenziato:

• Effettività: si introducono misure premiali e sanzionatorie, incentivando, da una parte, le amministrazioni virtuose anche con la possibilità di quantificare e riutilizzare i risparmi ottenuti grazie alle tecnologie digitali e sanzionando, dall’altra, le amministrazioni inadempienti;

• Risparmio: dalla razionalizzazione della propria organizzazione e dall’informatizzazione dei procedimenti, le pubbliche amministrazioni ricaveranno dei risparmi che potranno utilizzare per l’incentivazione del personale coinvolto e per il finanziamento di progetti di innovazione.

Fonte: Presidenza del Consiglio dei Ministri 22 Dicembre 2010

In armonia con gli obiettivi generali di revisione della spesa pubblica perseguiti dall'Amministrazione, la soluzione applicativa richiesta, fermo restando il consistente miglioramento della qualità dei servizi e le nuove modalità di erogazione, anche attraverso la disponibilità di accesso ad internet h24, dovrà determinare una significativa revisione della spesa complessiva, attraverso una considerevole riduzione dei costi (canoni annuali di manutenzione del software di base ed applicativo, costi delle licenze a scadenza, costo dei servizi di ass istenza collegati).

La soluzione applicativa richiesta dall'Amministrazione dovrà risultare: scalabile, basata su livelli avanzati della ICT, aperta a future implementazioni software, ampiamente referenziata su scala nazionale, in grado di migliorare sensibilmente l'efficacia, l'efficienza dei servizi da erogare agli uffici preposti ovvero alle PP.AA. (articoli 50, 52, 58 del CAD) ed ai cittadini attraverso il web.

Con riferimento alle disposizioni sancite dal CAD - all'art. 63 - Organizzazione e finalità dei servizi in rete - ed all'art. 64 - Modalità di accesso ai servizi erogati in rete dalle pubbliche amministrazioni - l'Amministrazione intende ricomprendere nella riqualificazione dei servizi di cui al presente Capitolato Speciale d'Appalto, l'attivazione ad ampio spettro ai servizi di e-government, affinché, attraverso il ricorso al personal computer e ad internet, i cittadini, le famiglie e le imprese possano colloquiare con tutte le amministrazioni locali e centrali.

L'Aggiudicatario dovrà garantire la realizzazione dell'appalto nel rispetto delle modalità, dei tempi e dei livelli di servizio descritti nel presente Capitolato Speciale di Appalto, nel suo complesso, che contiene quindi tutti gli elementi minimi che devono essere in ogni caso garantiti nonché accettati incondizionatamente nell'offerta presentata dai concorrenti. II mancato rispetto dei requisiti minimi indicati nel presente Capitolato Speciale di Appalto determina la non ammissibilità dell'offerta o la non accettazione dell'offerta.

L'Aggiudicatario dovrà altresì garantire la perfetta esecuzione a regola d'arte dell'appalto, ivi comprendendo tutti gli accorgimenti necessari ed opportuni anche se non espressamente specificati nei documenti di gara.

Sezione I

Caratteristiche Generali dell’Appalto

Art. 1 – Oggetto

Oggetto della procedura di gara è “la realizzazione e la manutenzione di un Sistema Informativo di gestione dei servizi demografici, tributari e finanziari del Comune di Napoli”.

I servizi e le forniture che l’Aggiudicatario è tenuto a garantire secondo le modalità esplicitate nel presente CSA sono :

Short time Services (da erogare nella fase iniziale del contratto)

A

I servizi di installazione e avviamento del Sistema Informativo

B

Fornitura Hardware necessario per quantità e tipologia a garantire il funzionamento del Sistema Informativo

C

La formazione del personale utente ed amministratore del Sistema Informativo

D

Il recupero degli dell’aggiudicazione

archivi

informatici

preesistenti

e

collegati

agli

applicativi

in

uso

al

momento

E

L’attività di sviluppo di nuovo software e/o modifica di quello esistente, relativa agli obiettivi dettagliatamente riportati nella sezione II del presente CSA

All time Services (da erogare per tutta la durata del contratto)
F	La manutenzione correttiva e adeguativa come specificato nel presente CSA all’art. 11
G	La manutenzione evolutiva nei limiti delle “giornate uomo” indicate nel presente CSA all’art. 11
H	L’assistenza sistemistica delle apparecchiature sulle quali sarà installato il Sistema Informativo oggetto di gara (disponibili presso la Server Farm) 1. per un anno (1) solare (dall’avvio della progettazione) in modo continuativo 2. per gli altri anni di contratto, “a chiamata” (nei limiti delle “giornate uomo” indicate nella sezione II del presente CSA)
I	L’assistenza telefonica (call center dedicato) e on site per l’utilizzo e la gestione del Sistema Informativo cosi come specificato nel presente CSA all’art. 11

Tab. A: Short time Services

Tab. B: All time Services

Il costo complessivo dei servizi e delle forniture elencati nelle precedenti tabelle (A e B) è dato dal valore dell’offerta economica dell’ Aggiudicatario e null’altro sarà dovuto.

I requisiti, le caratteristiche tecniche, i tempi e le modalità di esecuzione della prestazione sono riportati nella Sezione II del presente CSA denominata “Aspetti tecnici”.

Il codice identificativo di gara per l'Autorità di Vigilanza sui Contratti Pubblici di Lavori, Servizi e Forniture (CIG) è:

5577210B47.

L'aggiudicazione sarà effettuata ai sensi dell'art.83 del D.Lgs. 163/2006 e ss.mm.ii., mediante il criterio dell'offerta economicamente più vantaggiosa riservando un massimo di 80 punti all’offerta tecnica e un massimo di 20 punti all’offerta economica.

L’appalto rientra nella categoria di servizi n° 7 (servizi informatici ed affini) CPV 72268000-1 (servizi di fornitura software) NUTS ITF33.

Art. 1 Bis – Opzione di scelta

L’Aggiudicatario ha la facoltà di optare relativamente ad ogni modulo per:

• Opzione A: la gestione di uno o più applicativi in funzione presso la Stazione Appaltante al momento dell’Aggiudicazione (vedasi art. 9 – Contesto Tecnologico Attuale);

• Opzione B: la fornitura di una soluzione la cui proprietà sarà ceduta alla SA;

• Opzione C: il ricorso ad una soluzione commerciale di cui detiene i diritti di utilizzo, fornendone licenza d’uso illimitata alla SA.

La scelta dell’opzione dovrà essere riportata nell’allegato K che dovrà essere inserito nella “Busta A – Documentazione Amministrativa”.

Quale che sia la scelta opzionale, l’Aggiudicatario deve personalizzare e modificare gli applicativi di base in modo da realizzare un sistema informativo integrato che soddisfi i tutti requisiti di cui al presente CSA.

Nel caso in cui l’Aggiudicatario optasse per la gestione dei software in uso presso l’Amministrazione (opzione A) e dei quali la stessa detiene al momento dell’aggiudicazione la proprietà del codice sorgente, si sottolinea che i moduli aggiunti, le modifiche implementate, i diritti dell’applicativo e la relativa documentazione resteranno alla SA.

Qualora la soluzione offerta venisse ceduta in proprietà all’Amministrazione (opzione B) il codice sorgente (compresi i moduli aggiunti e le modifiche implementate), la documentazione e tutti i diritti dell’applicativo resteranno alla Stazione Appaltante. Se richiesto dall’Amministrazione, il codice sorgente risiederà su ambienti specifici indicati dalla stessa.

Nel caso in cui l’Aggiudicatario scegliesse l’opzione B oppure l’opzione C, dovrà farsi carico del recupero dei dati degli applicativi in uso e della relativa migrazione garantendo l’integrità e la qualità degli stessi, assumendosi in tal senso tutte le responsabilità.

Inoltre sempre nel caso in cui l’Aggiudicatario optasse per B o C sarebbe opportuno predisporre un “video tutorial” per illustrare alcune delle funzioni dei moduli richiesti cosi come previsto all’art. 53 del presente CSA.

Qualora la soluzione offerta fosse ceduta in licenza d’uso illimitata, la soluzione di partenza e tutte le personalizzazioni per l’Amministrazione devono essere opportunamente documentate.

Indipendentemente dall’opzione scelta, il nuovo software dovrà:

1. fornire le stesse funzionalità dei sistemi informativi in uso al momento dell’aggiudicazione (vedasi art. 9 – Contesto Tecnologico Attuale);

2. fornire le nuove funzionalità richieste all’art. 10 – Requisiti della soluzione applicativa;

3. integrare tra loro il modulo demografico, tributario e finanziario secondo quanto indicato agli art. 10;

4. interagire con altri sistemi, cosi come esistenti al momento dell’aggiudicazione (es. collegamento alla Tesoreria Comunale …);

5. predisporre le interfacce (attraverso Web Services) necessarie per garantire future interazioni con altri software già esistenti al momento dell’aggiudicazione o di futura realizzazione (in particolar modo sarà fondamentale e imprescindibile il collegamento con i sistemi realizzati in ambito del progetto Coopera et Eroga attualmente in fase di programmazione).

In ogni caso la proprietà degli archivi informatici collegati ai tre moduli del Sistema Informativo e la relativa documentazione connessa, resterà al Comune di Napoli, al quale l’Aggiudicatario dovrà fornire la formazione necessaria a gestirla e le credenziali di accesso come amministratore. Per i dettagli si rimanda alla Sezione II – Aspetti tecnici.

Art. 1 Ter – Periodo di parallelismo

Fino a tutto il 31/12/2014 coesisteranno con il nuovo sistema informativo i vecchi applicativi al fine di verificare il corretto funzionamento delle nuove soluzioni.

Art. 1 Quater – Parziale estensione della garanzia

Qualora vi fosse una attività di manutenzione del software (sviluppo e/o adeguamento) nel corso dell’ultimo anno di contratto (2020), l’Aggiudicatario si impegna a fornire la relativa manutenzione correttiva alle variazioni in discussione a tutto il 31/12/2021.

Art. 2 – Durata

La durata dell’affidamento è di 80 mesi a partire dall’1/05/2014 e fino a tutto il 31/12/2020.

Art. 3 – Cronoprogramma

1. Entro il 15/09/2014 dovrà essere collaudato il modulo finanziario come previsto all’art. 16 del presente CSA.

2. Entro il 31/10/2014 dovrà avvenire il collaudo di tutto il Sistema Informativo secondo le specifiche indicate all’art. 16 del presente CSA.

3. In data 1/01/2015 l’intero Sistema Informativo oggetto di gara dovrà essere in esercizio, prevedendosi a discrezione dell’Amministrazione la dismissione dei vecchi applicativi.

Eventuali slittamenti temporali dei collaudi saranno possibili solo se autorizzati dalla Stazione Appaltante.

Art . 4 - Accesso al know how attuale e ai sistemi

Dall’aggiudicazione definitiva, sarà possibile accedere ai sistemi in uso e al know how disponibile per poter avviare la fase di studio, progettazione e successiva implementazione del nuovo Sistema Informativo, nel rispetto dei tempi, dei costi e dei parametri qualitativi richiesti dal presente CSA.

Art. 5 – Quadro giuridico di riferimento

L'appalto è soggetto alle norme e condizioni previste dal D.Lgs. n. 163/2006 e ss.mm.ii., dal Decreto del Presidente della Repubblica del 5 ottobre 2010, n. 207 - Regolamento di esecuzione ed attuazione del decreto legislativo 12 aprile 2006, n. 163, recante «Codice dei contralti pubblici relativi a lavori, servizi e forniture in attuazione delle direttive 2004/17/CE e 2004/18/CE», dalla L.R. della Campania 3/2007 "Disciplina dei lavori pubblici, dei servizi e delle forniture in Campania" e dalle disposizioni del bando di gara, dal presente Capitolato speciale di appalto e da tutta la documentazione posta a base di gara, oltre che, per quanto non regolato dalle clausole e condizioni suddette, dalle norme del Codice Civile. I requisiti, le caratteristiche tecniche, le modalità e i termini ai quali dovrà rispondere la prestazione della fornitura sono stabiliti dal presente Capitolato Speciale d'Appalto.

Art. 6 – Importo a base di gara

Il valore omnicomprensivo dell’appalto, caratterizzato da un unico lotto indivisibile, è pari a € 1.500.000,00 (unmilionecinquecentomila/00) oltre IVA al 22% di € 330.000,00 (valore complessivo € 1.830.000,00). Non sono ammesse offerte economiche che comportano una spesa superiore a detto importo. Si procederà all’aggiudicazione anche in presenza di una sola offerta valida. Il periodo di tempo durante il quale l’offerente è vincolato alla propria offerta è di sei mesi dalla data della seduta pubblica di gara.

L'offerta è omnicomprensiva di tutti i costi necessari allo svolgimento delle forniture e dei servizi connessi all'appalto (indicati all’art. 1 del presente CSA) e di ogni altro costo connesso alla soluzione proposta (inclusi costi delle licenze per l'utilizzo di prodotti di terze parti). Il prezzo offerto è formulato in base a calcoli di propria convenienza.

Art. 7 – Servizi innovativi

L’Aggiudicatario può proporre, senza ulteriori costi rispetto al corrispettivo massimo di cui all’art. 6 e comunque nei limiti dell’offerta economica presentata, soluzioni innovative che migliorino il servizio offerto. Tali soluzioni se ritenute adeguate dalla SA diverranno parte integrante dell’appalto.

Art 8 – Luogo ed orario di lavoro

8.1 LUOGO DI LAVORO

I servizi richiesti nel capitolato tecnico saranno erogati dall’Aggiudicatario prevalentemente nei locali del Centro Polifunzionale sito in Soccavo alla xxx Xxxxxxx - Xxxxxx, sede della Server Farm del Comune di Napoli, eventuali diverse modalità saranno esplicitamente indicate e disciplinate nel presente CSA.

L’Amministrazione, per i servizi richiesti in sede, garantirà al personale dell’Aggiudicatario, i locali, le postazioni di lavoro (esclusi persona computer/laptop e relativo software a corredo) e le credenziali informatiche necessarie all’accesso ai software in uso.

L’Aggiudicatario s’impegna al rispetto di tutte le politiche di sicurezza (accesso ai locali, utilizzo di credenziali di accesso ai sistemi ed alle informazioni…..) definite dall’Amministrazione.

L’Amministrazione si riserva la facoltà di richiedere, senza alcun onere aggiuntivo, l’erogazione dei servizi anche presso altre sedi.

Si riporta, i seguito, l’elenco indicativo ma non esaustivo, delle sedi principali:

Descrizione	Ubicazione
Area Reti Tecnologiche (Server Farm)	viale Xxxxxxx n.40 – Polifunzionale di Soccavo – Napoli
Area Sviluppo Applicativi	viale Xxxxxxx n.40 – Polifunzionale di Soccavo – Napoli
Servizio Anagrafe	II traversa privata di via dell’Epomeo - parco Quadrifoglio – Napoli
Affari Generali e Controlli Interni D.C.S.F.	Xxxxx Xxxxxxx Xxxxx, 00/00 Xxxxxx
Servizio Bilancio	Xxxxxx Xxxxxxxxx - Xxxxxxx Xxx Xxxxxxx - Xxxxxx

L’Aggiudicatario, inoltre, deve assicurare la propria disponibilità ad incontri di lavoro presso qualsiasi sede dell’Amministrazione comunale.

Per quanto riguarda la quantificazione degli oneri economici, in ragione della natura esclusivamente intellettuale delle prestazioni richieste all'aggiudicatario, non si prevede il verificarsi di “interferenze” pericolose con le attività dei dipendenti ed incaricati del Comune presenti nelle sedi di lavoro, e pertanto non si prevedono oneri per la sicurezza specificamente connessi alla esecuzione del presente appalto.

8.2 ORARIO DI LAVORO

Le prestazioni dei servizi di assistenza specialistica richiesti nel presente Capitolato tecnico devono essere erogate nei giorni lavorativi dal lunedì al venerdì nell’ arco dell’orario di servizio dell’Amministrazione così come definito nel paragrafo Definizioni e convenzioni di carattere generale.

Come orario standard di lavoro per il personale tecnico dell’Aggiudicatario si assume l’arco temporale giornaliero che va dalle ore 9.00 alle ore 18.00 comprensivo di un’ora per la pausa pranzo.

Si precisa tale arco temporale giornaliero è da ritenersi di riferimento, infatti modifiche dell’orario di lavoro per l’erogazione di specifiche attività (ad es. assistenza sistemistica continuativa) sono precisate nei paragrafi successivi.

Nei giorni antecedenti e/o di svolgimento delle consultazioni popolari (elezioni, referendum …) o in occasione di eventi straordinari allo stato non prevedibili, la dizione giorno lavorativo dovrà comprendere anche i giorni festivi e la fascia oraria potrà subire slittamenti di orario (ad. es. 11.00 – 20.00 / 13.00 – 22.00).

Eventuali modifiche (transitorie o permanenti) dell’orario standard di lavoro dovranno essere preventivamente concordate ed autorizzate dall'Amministrazione.

Sezione II Aspetti Tecnici

Art. 9 – Contesto Tecnologico Attuale

Prima di illustrare gli aspetti generali del Sistema Informativo Tributario , Demografico e Contabile attualmente in uso, rimandando alla documentazione visionabile durante il sopralluogo (vedi art. 45 bis) per una più completa descrizione dell’architettura applicativa e tecnica dei S.I. de quo, si precisa che qualora nel corso della fornitura dei servizi richiesti con il presente Capitolato si rendessero necessari variazioni del contesto tecnologico iniziale della fornitura, il Fornitore si impegna ad assicurare l’erogazione ottimale dei servizi richiesti con personale tecnico avente competenze adeguate al mutato contesto, senza alcun onere aggiuntivo per l’Amministrazione.

Per il sistema informativo tributario e demografico la Stazione Appaltante detiene tutti i diritti sulla documentazione e codici sorgenti in quanto gli applicativi sono di proprietà del Comune di Napoli. Per quanto riguardo il sistema informativo contabile la Stazione Appaltante detiene la licenza d’uso illimitata.

9.1 SISTEMA INFORMATIVO TRIBUTARIO

9.1.1 Descrizione

Fin dal 1998 la Direzione Servizi finanziari si è dotata di un autonomo sistema informativo automatizzato composto da dispositivi hardware, di comunicazione, software (di base, d’ambiente ed applicativo) costituenti un autonomo polo elaborativo della Direzione Servizi Finanziari con infrastruttura tecnologica collocata nella sala server posta al settimo piano di C/so Xxxxxxx Xxxxx 66/82.

La gestione di tutti i tributi comunali e delle banche dati tributarie è stata assicurata sino al 31/12/2013, dall’applicativo Thebit, offerto in concessione ad uso gratuito (deliberazione di Giunta Municipale n° 3654 del 04/08/1995) e gestito dalla soc. Società Engineering Tributi S.p.A a cui fu affidata l’installazione del software di base per il funzionamento del package Thebit e la relativa personalizzazione.

La suddetta società ha inoltre realizzato e messo in produzione nell’anno 2009 il “Portale delle Entrate” finanziato con fondi regionali POR misura 6.2.C.

Il Portale delle Entrate è il portale, integrato nel Portale del Comune di Napoli, attraverso cui il contribuente, tramite web, consulta la propria posizione tributaria (Ici/Imu, Tarsu e Cosap, verifica i pagamenti effettuati, anche da cartella di pagamento, avvia pratiche e segnala eventuali anomalie….). Il Portale delle Entrate sarà sostituito dal Portale del Contribuente, realizzato nell’ambito del progetto S.I.R. (Sistema Informativo Riscossione) in fase di collaudo e prossimo al rilascio.

Le criticità dell’applicativo Thebit rappresentate dall’obsolescenza architetturale (client/server), delle tecnologie utilizzate (versione 7.2.3 del dbms Oracle; software di tipo proprietario Magic 5.1 per lo sviluppo delle applicazioni;

s.o. dei server Unix TRU 64 ver. OS04FD), dei server H.P. che la ospitano e la cui manutenzione sarà sospesa a dicembre 2013, i limiti nell’utilizzo delle licenze dell’emulatore TUN EMUL 8.51 per i client Windows ed i connessi costi di gestione e manutenzione sistemistica ed applicativa, hanno indotto l’Amministrazione ad attivare da tempo un radicale processo di innovazione tecnologica i cui principali driver sono rappresentati dall’integrazione e dalla qualità delle informazioni, dall’interoperabilità degli sviluppi applicativi, dall’utilizzo di piattaforme e tecnologie open source, dalla necessità di ridurre le spese razionalizzando le infrastrutture tecnologiche, dall’accelerare l’ integrazione delle procedure e delle banche dati interne ed esterne all’Ente moltiplicando l’offerta dei servizi al cittadino e diversificando non solo le possibilità di fruizione degli stessi ma anche le modalità di interazione del cittadino con gli uffici tributari.

Pertanto, nell’ambito dello stesso appalto del “Portale delle Entrate”, la medesima Società Engineering Tributi S.p.A ha provveduto a realizzare l’applicativo Thebit-Web (sviluppato in architettura J2EE web-oriented three-tier), che sarà rilasciato a dicembre 2013 e rappresenta per l’area tributi, unitamente al Portale delle Entrate, l’oggetto dei servizi richiesti nel presente capitolato per l’area tributi. Sarà garantita la gestione dell’intero pacchetto applicativo in uso ai tributi sino al 31/12/2014.

9.1.2) Contesto operativo HW/SW

L’applicativo Thebit Web, che utilizza tecnologie di tipo web, linguaggi di tipo open, database Oracle 11g, codice aperto, è di proprietà del Comune di Napoli, è integrato con il già citato portale, è la naturale evoluzione dell’applicativo Thebit di cui ne eredità le funzionalità ed è finalizzato a soddisfare i fabbisogni informativi della Direzione Centrale Servizi Finanziari per ciò che riguarda i tributi comunali, integrandone la gestione ed adeguandola alle esigenze organizzative e funzionali degli uffici tributari.

A partire dalla gestione dei soggetti (persone fisiche e giuridiche) e degli oggetti (terreni e fabbricati) che insistono nel territorio del Comune di Napoli, sulla base delle dichiarazioni dei contribuenti e/o delle rilevazioni di ufficio ed in accordo con Regolamenti Tributari dell’Ente e con la normativa vigente, la banca dati Thebit Web:

• gestirà tutte le fasi operative dei tributi I.C.I. - T.A.R.S.U. - C.O.S.A.P, dalla determinazione dell’importo dovuto alla acquisizione ed alla verifica dei pagamenti eseguiti in ragione dei flussi inviati al soggetto terzo, a cui è demandata l’attività di riscossione, spontanea e coattiva, delle entrate tributarie ed extratributarie dell’Ente. Con determina di aggiudicazione n.1 del 04/05/2011 l’Amministrazione ha esternalizzato e affidato in concessione, per la durata di anni sei (6), alla RTI costituito da Equitalia Polis S.p.A ed Engineering Tributi

S.p.A le “attività di riscossione volontaria e coattiva dell'imposta comunale sugli immobili (ICI), del canone per l'occupazione di spazi ed aree pubbliche (COSAP), del canone di fognatura e depurazione, della gestione dei procedimenti scaturenti dagli atti afferenti ai medesimi tributi, della riscossione coattiva relativa alla tassa smaltimento rifiuti solidi urbani, in conformità alla vigente normativa in materia”. Tale affidamento prevede, tra l’altro, la realizzazione del progetto S.I.R. (sistema informativo riscossione). L’elenco delle funzionalità sia online che batch è indicato nel documento AllVerb0032-27022013-ThebitWeb-DocumentazioneTecnica - ElencoFunzionalita_Rif08 facente parte della documentazione relativa all’applicativo Thebit Web e consultabile durante il sopralluogo (vedi art. 45 bis);

• provvederà alla elaborazione e predisposizione di certificazioni, attestazioni, estrazioni e trasmissioni dati (generaziaone Bollettazione COSAP, degli Inviti al Pagamento , degli Atti Ingiuntivi e dei Ruoli Ordinari e Coattivi, Scarico Ruolo Principale Tarsu per Equitalia (Tracciato 290), generazione massiva delle Liquidazioni e Accertamenti, generazione di tutti i documenti relativi agli atti ordinari e sanzionatori, formazione e report consuntivi della Riscossione Diretta e dei Ruoli Coattivi, etc. ) ed altre attività previste a carico dell’Ente da norme di legge o disposizioni regolamentarie ovvero specifiche esigenze dell’Amministrazione e/o convenzioni con enti e strutture esterne;

• provvederà con funzionalità batch, all’acquisizione, all’integrazione ed all’incrocio dei propri dati con quelli acquisibili da flussi informativi interni ed esterni all’Amministrazione, finalizzando tali attività all’aggiornamento dei propri dati ed alla bonifica delle informazioni ma soprattutto alla lotta all’evasione ed all’elusione tributaria che rappresenta un obiettivo prioritario per l’Amministrazione.

Relativamente alla Gestione dell’Imposta Municipale Propria (I.M.U.) ed alla Gestione dell’Imposta Tariffa Rifiuti e Servizi (T.A.R.E.S. – art. 14 X.Xxx. 201 del 06 Dic. 2011), la società Engineering Tributi S.P.A. completerà entro il 31/12/2013 le attività di sviluppo dei moduli software previsti in Thebit Web per la gestione di tali imposte e provvederà ad aggiornarne la documentazione.

Per quanto riguarda la Gestione dell’Imposta di Soggiorno (art. 4 del Decreto Legislativo 14/03/2011 n.23) attualmente essa è assicurata dall’applicativo GE.I.S. "GEstione Imposta di Soggiorno" (sviluppato in architettura J2EE web-oriented three-tier).

Tale applicativo, a fronte dell'esigenza manifestata dallo stesso Comune di dotarsi di un gestionale dedicato, è stato fornito dalla società Engineering Tributi S.p.A in licenza d’uso gratuita al Comune di Napoli fino al 30/06/2014.

Rappresenta pertanto obiettivo primario per l’Amministrazione lo sviluppo di un apposito modulo software (parte front office e parte back office) per la gestione integrata di tale imposta.

La seguente tabella, suddivise per tributo, fornisce alcuni parametri quantitativi (meramente indicativi e non definitivi) riferiti alle principali informazioni contenute nella b.d. Thebit (dati si riferiscono al Processo di Migrazione attivato il 06 Aprile 2013):

Tributo I.C.I.	TOT.
n. righe denunce	896.070
n. righe liquidazioni	433.941
n. righe accertamenti	43.216
n. righe sgravi	27.349
n. righe ruoli	136.236
n. righe ricorsi	10.933
n. righe reversali	7.452
n. righe rimborsi	4.792
n. righe versamenti	9.016.567
Tributo T.A.R.S.U	TOT.
n. righe denunce	1.160.207
n. righe riscossione (diretta)	307.800
n. righe sgravi	209.256
n. righe ruoli	4.503.252
n. righe ricorsi	13.120
n. righe reversali	24.884
n. righe versamenti da riscossione diretta	462.181
Tributo C.O.S.A.P	TOT.
n. righe denunce	51.108
n. righe bollettazione	123.716
n. righe versamenti	108.462
n. righe verbali	18.924
n. righe abusività	28.971
n. righe ruoli	3.777
n. righe reversali	134
n. righe ricorsi	519
n. righe rateizzazioni	535

La seguente tabella fornisce dati riepilogativi di natura economica riferita ai principali tributi ed all’anno 2012:

Ruolo Principale Tarsu	€ 163.952.273,93	quota Comune
	€ 67.220.018,34	quota Provincia
Riscossione diretta Tarsu	€ 7.485.087,00	Accertamenti
	€ 9.104.376,00	Liquidazioni
Ruolo Coattivo Tarsu	€ 38.189.423,67
Versamenti Spontanei ICI/IMU	€ 242.000.000
Ruolo Coattivo ICI	€ 7.433.045
Accertamento ICI	€ 16.358.123,01
Liquidazione ICI	€ 5.379.007	Anno 2007
	€ 3.052.939,49	Anno 2008
	€ 3.814.017	Anno2009
	€ 13.218.093	Anno 2010

Di seguito si riportano, a mero scopo indicativo, alcuni risultati dei test effettuati ai fini della determinazione delle prestazioni del Sistema Thebit WEB. Tali risultati sono estrapolati dal documento AllVerb0149-05082013-Thebit Web-

DocumentazioneTecnica-PrestazioniSistema_Rif09-v2 consultabile durante il sopralluogo (vedi art. 45 bis), facente parte della documentazione relativa all’applicativo Thebit Web e sono relativi ad un ambiente di test in cui sono state registrate le metriche aventi le seguenti caratteristiche:

• Un Application Server:

▪ Sistema Operativo: Linux 2.6.18-308.16.1.el5 x64

▪ Processore: Intel® Xeon® x5647 2.93 GHZ

▪ Ram: 4 GB

▪ Unità Disco: 200 GB

• Un DataBase Server:

▪ Sistema Operativo: Windows Server 0000 X0 x00 Service Pack 2

▪ Processore : Intel® Xeon® E5410 2.33 GHZ

▪ Ram: 8GB

▪ Unità Disco: 475 GB - 2 LSI MegaRAID SAS RMB SCSI Disk Device

a) Tempi di risposta delle operazioni online:

Operazione	Tempo di risposta (ms)
Inserimento Denuncia TARSU – Nuova Iscrizione	263
Modifica quadro immobile TARSU	107
Inserimento rilevazione d’Ufficio TARSU	259
Visualizzazione Provvedimento – Xxxxxx Xxxxxxxxx	85
Cambia Stato provvedimento	96
Stampa Provvedimento ACRD	760
Visualizzazione discarico	270
Inserimento Denuncia variazione ICI	203
Inserimento Rilevazione d’Ufficio ICI	183
Modifica Rilevazione d’Ufficio ICI	195
Visualizzazione Provvedimento di Liquidazione	110
Stampa Provvedimento di Liquidazione	720
Protocollazione di un provvedimento	131
Ricerca di una Partita	360
Ricerca di un Documento	270
Visualizzazione Reportistica Documenti Generati	320

b) Tempi di attesa per la generazione dei ruoli tributari:

Tributo	Tipo Emissione	Tipo Elaborazione	Tempi Attesi (min)
XXXXX	Xxxxx Principale	Generazione Provvedimenti	2880
XXXXX	Xxxxx Principale	Generazione Partite ed Articoli	226
XXXXX	Xxxxx Principale	Scarico su Tracciato 290	60
TARSU	Riscossione Diretta	Generazione Provvedimenti	1440
TARSU	Riscossione Diretta	Stampa Atti	150
TARSU	Ruolo Coattivo	Generazione Partite ed Articoli	20
TARSU	Ruolo Coattivo	Scarico su Tracciato 290	5
ICI	Liquidazioni	Generazione Provvedimenti	3600
ICI	Liquidazioni	Stampa Atti	2880
ICI	Ruolo Coattivo	Generazione Partite ed Articoli	20
ICI	Ruolo Coattivo	Scarico su Tracciato 290	5
COSAP	Bollettazione	Generazione Provvedimenti	30

L’applicativo “Portale delle Entrate” è già in esercizio presso la Server Farm del Comune di Napoli; una versione di test dell’applicativo Thebit Web, di supporto alle attività di collaudo, è operativa già dal 2012 presso la Server Farm del Comune di Napoli ove è previsto il suo futuro esercizio.

Infine si rappresentano alcune caratteristiche delle componenti infrastrutturali presso la Server Farm del Comune di Napoli di supporto al s.i. tributario rimandando nel contempo, per ogni ulteriore documentazione, a quanto previsto nell’art 9.4.

Attualmente gli Host presenti nella Server Farm sono tutti della seguente tipologia:

• Server Blade Fujitsu "Primergy BX960-S1"

• 2 o 4 CPU "Intel Xeon E7520 1.87 Ghz 4 Core/8 Thread"

• 64 GB RAM.

• S.O. Windows Server 2008 R2/Windows Server 2012

• Ambiente di Virtualizzazione Hyper-v.

Lo Storage è allocato su Sistema Fujitsu Eternus DX8400.

Dbserver Thebit Web e Portale delle Entrate: Server fisico Fujitsu con le caratteristiche suddette 2 CPU, Storage consistente in 2 LUN da 80 GB e 500 GB (in corso richiesta di aumento a 1 TB).

Application server Thebit Web:server virtuale con 8 vCPU/ 16 GB RAM / Storage 1 TB

Application server Portale delle Entrate: Server virtuale con 2 vCPU/ 8 GB RAM / Storage 50 GB (una vCPU alloca risorse computazionali sui server fisici corrispondenti all'incirca a mezzo Core)

Web Server portale delle Entrate:

• computer: Fujitsu Siemens Primergy TX150 S6 Dual Core

• S.O.: Windows server 2003 R2 Service Pack 2

• CPU: Fujitsu Siemens Intel Xeon 2,33 Ghz

• SCSI disk device: 70 GB

• scheda di rete: Intel(R) PRO/1000 GT BROADCOM NetXtremeGigabit Ethernet

9.1.3) Documentazione Tecnica

Per ulteriori dettagli è possibile consultare i seguenti documenti durante il sopralluogo (vedi art. 45 bis):

• AllVerb0032-27022013-Thebit Web-DocumentazioneTecnica-ElencoFunzionalita_Rif08; AllVerb0149-05082013-Thebit Web-DocumentazioneTecnica-PrestazioniSistema_Rif09-v2

• AllVerb0009-All.C-Integrazione Portale Entrate-Mappe Thebit WEB e Portale Entrate

9.2 SISTEMA INFORMATIVO DEMOGRAFICO

Il Comune di Napoli utilizza dal 2002 la procedura ARCADIA per la gestione dei sevizi demografici e la tenuta sistematica ed informatizzata degli atti di Stato Civile, degli archivi anagrafici ed elettorali del Comune. La gestione dei servizi demografici è in parte centralizzata presso il Servizio Anagrafe, Stato Civile, Elettorale ed in parte decentrata presso gli uffici delle dieci Municipalità.

9.2.1) Descrizione

La procedura ARCADIA è costituita da una serie di moduli correlati che consentono l’aggiornamento delle informazioni riguardanti il nucleo familiare, il cittadino, la sua posizione elettorale e la sua collocazione nel territorio comunale (abitazione), nazionale (emigrazione, immigrazione) ed internazionale (AIRE).

La procedura è costituita dai seguenti moduli:

🞏 Modulo Gestione Unità Territoriali - Consente la suddivisione del territorio comunale in unità territoriali quali: Sezioni Elettorali, Quartieri, Municipalità, C.a.p., Sezioni Censuarie, ecc…

🞏 Modulo Anagrafico - Consente la gestione dell’Anagrafe della Popolazione: l’aggiornamento in tempo reale di tutte le informazioni che riguardano l’individuo e la famiglia: iscrizioni e cancellazioni APR, cambio abitazione, ecc… Il modulo è integrato con il Portale dei Servizi On Line che permette al cittadino di usufruire di alcuni servizi.

🞏 Modulo Elettorale - Consente la gestione sistematica ed informatizzata delle Liste elettorali.

🞏 Modulo Stato Civile - consente di gestire la manutenzione sistematica ed informatizzata degli atti di Stato Civile: Nascita, Pubblicazioni di Matrimonio, Matrimonio, Morte e Cittadinanza. Il modulo è integrato con il Portale dei Servizi On Line che permette al cittadino di usufruire di alcuni servizi, quali le prenotazioni per la redazione delle pubblicazioni di Matrimonio e delle annotazioni di comunione o separazione dei beni.

🞏 Modulo Carte Identità – Consente la gestione del rilascio delle Carte d’identità agli individui residenti e non residenti dagli uffici decentrati (Municipalità).

🞏 Modulo Certificazione – Consente la gestione del rilascio dei Certificati agli individui residenti e non residenti dagli uffici decentrati (Municipalità).

🞏 Modulo Leva Militare – Consente la gestione delle varie fasi operative per la determinazione delle liste di leva e ruoli matricolari

🞏 Modulo Albo Scrutatori – Consente la gestione dell’archivio degli iscritti all’Albo Scrutatori. Comprende l’estrazione casuale delle nomine a scrutatore degli elettori iscritti all’albo. Il modulo è integrato con il Portale dei Servizi On Line che permette al cittadino di usufruire di alcuni servizi, quali l’inoltro delle domande di iscrizione all’albo tramite Internet.

🞏 Xxxxxx Presidenti di Seggio – Consente la gestione dell’archivio degli iscritti all’Albo Presidenti di Seggio. Il modulo è integrato con il Portale dei Servizi On Line che permette al cittadino di usufruire di alcuni servizi, quali l’inoltro delle domande di iscrizione all’albo tramite Internet.

🞏 Xxxxxx Xxxxxxx Popolari – Consente la gestione dell’archivio degli iscritti all’Albo Giudici Popolari.

🞏 Modulo Gestione Elezioni – Consente la Gestione dei seguenti tipi di elezioni: Europee, Politiche (Camera e Senato), Regionali, Provinciali, Amministrative (Comunali, Municipali), Referendum e del Ballottaggio per le elezioni che lo prevedono. Il modulo è comprensivo di funzionalità che consentono l’estrazione di elaborati statistici per la Prefettura, una componente per l’invio e la ricezione di informazioni al Sistema Elettorale Centrale mediante WS ed una componente WEB che consente la visualizzazione su Internet dei dati di affluenza e di scrutinio per area Geografica ( sezione, quartiere, Municipalità, ecc...).

La procedura Arcadia comprende anche una componente WEB costituita da portali e WS realizzati per la visualizzazione dei dati e la cooperazione applicativa con gli enti esterni. Essa è costituita dai seguenti moduli:

• Arcadia Web - Portale utilizzato dagli altri Uffici del Comune ed Enti Esterni autorizzati per la ricerca e la visualizzazione delle informazioni relative agli individui ed alle famiglie (Visure).

• SIAC (Sistema Informativo Anagrafico Cooperativo) - Costituito da un portale utilizzato dall’ASL del territorio comunale per la ricerca e visualizzazione delle informazioni anagrafiche riguardanti il cittadino e le famiglie e da una porta di dominio realizzata per l’alimentazione dell’Anagrafe Sanitaria dell’ASL al verificarsi degli eventi anagrafici di nascita, morte e cambio residenza/domicilio.

• Arcoweb - WS disponibile per le interrogazioni INPS

• Elezioni - Applicazione per la gestione delle elezioni (tornate elettorali), esposizione su WEB dei dati relativi alle affluenze ed allo scrutinio ed invio delle informazioni al Sistema Elettorale Centrale gestito dal Ministero degli Interni.

• SAIA - Modulo per l’invio delle variazioni anagrafiche al sistema SAIA.

9.2.2) Contesto Operativo HW/SW

Di seguito sono elencate le caratteristiche tecniche del Sistema Informativo Demografico:

🞏 L’Applicazione è sviluppata in Power Builder versione 6.51, ed è costituita da moduli applicativi tutti integrati, per la gestione completa, secondo quanto illustrato, per cui gli aggiornamenti effettuati in uno qualsiasi dei moduli sono disponibili in tempo reale sugli altri.

🞏 Installata su 5 Server virtualizzati, sistema operativo Windows 2000

🞏 I Server virtuali, in configurazione di bilanciamento di carico mediante Citrix metaframe, sul quale è prevista l’installazione di tutti i componenti applicativi, realizzano il Sistema Demografico e permettono l’accesso a tutti i Servizi forniti

🞏 Il bilanciamento della piattaforma Citrix metafreme consente di effettuare installazioni software remote, rimappando i driver (es. CD ROM) della macchina dell'amministratore (ServerFarm.) sulla macchina remota, e pilotando la macchina remota tramite visualizzazione del suo desktop sul proprio. Dalla ServerFarm (o da altre sedi designate), è possibile non solo “copiare” files sui vari application server, ma, con un unico CD ROM, è possibile installare applicazioni su tutti gli application server, senza essere fisicamente presenti nelle sedi di installazione, consentendo di aggiornare in modo automatico e centralizzato il software memorizzato sul firmware dei client (Client ICA)

🞏 L’attuale database del software per la gestione dei Servizi Demografici è su un database relazionale Oracle versione 11.

🞏 Le apparecchiare periferiche di cui è dotato il Comune sono Win-Terminal, il cui accesso è vincolato all’utilizzo di smart-card nominative, con la segnatura della collocazione fisica dell’apparecchiatura, quindi S.A.M. – Anagrafe – Elettorale – Stato Civile

9.2.2.1) Cooperazione tra Anagrafe e Tributi

Ad oggi l’integrazione fra i vari moduli (“Cooperazione Applicativa”) è realizzata mediante le seguenti modalità:

• Integrazione in Tempo Reale – gli aggiornamento effettuati da un modulo sono disponibili agli altri moduli immediatamente: es. le variazioni anagrafiche dei cittadini e delle famiglie, effettuate dal modulo Anagrafe, sono visibili e certificabili in tempo reale in tutti gli altri moduli ( variazione di generalità, professione, titolo di studio, ecc…)

• Integrazione con comunicazioni – gli aggiornamenti effettuati da un modulo sono resi disponibili agli altri moduli mediante comunicazioni (o prenotazioni): es. le prenotazioni elettorali, generate in automatico dalle funzionalità dell’anagrafe ed elaborate successivamente dal modulo elettorale in fase di revisione delle liste elettorali, l’attività di sincronizzazione fra il modulo di Stato Civile e l’Anagrafe effettuata periodicamente dal sevizio anagrafe e le variazioni anagrafiche inviate alle ASL mediante la cooperazione applicativa.

• Integrazione periodica - gli aggiornamenti effettuati da un modulo sono disponibili agli altri moduli mediante scarico periodico delle informazioni: es. lo scarico annuale dei residenti in Anagrafe effettuato da Thebit per la composizione del ruolo TARSU.

9.2.3) Documentazione Tecnica

Per ulteriori dettagli è possibile consultare i seguenti documenti durante il sopralluogo (vedi art. 45 bis):

• All_Requisiti ARCADIA

9.3 SISTEMA INFORMATIVO FINANZIARIO

9.3.1) Descrizione

L’attuale sistema informativo finanziario in uso al Comune di Napoli è ASCOT WEB fornito in licenza d’uso illimitata dalla società Insiel Mercato Spa.

Tale sistema informativo Consente l’automazione della contabilità finanziaria relativamente a: bilancio, movimenti contabili di entrata e spesa, rendiconti, contabilità analitica della spesa, contabilità IVA, contabilità del sostituto d’imposta, contabilità delle casse economali, contabilità dei mutui e degli impegni e accertamenti pluriennali, contabilità dei funzionari delegati, contabilità dei rapporti con il tesoriere

9.3.2) Contesto Operativo HW/SW

L’applicativo utilizza un sistema di journaling che registra ogni variazione apportata specificandone l’indirizzo del posto di lavoro, la data o l’ora dell’intervento.

La procedura attualmente in uso è raggiungibile dagli utenti aggiungendo la relativa stringa sul browser utilizzato, previa autorizzazione del Dirigente del Servizio Bilancio Comunale.

Le postazioni attualmente utilizzate sono dislocate in diversi uffici dell’Ente e sono circa 500.

Il software prevede le seguenti funzionalità:

• Contabilità economica ed analitica

• Contabilità finanziaria (gestione bilancio, gestione comunicazioni alla Corte dei Conti ed al tesoriere, Gestione Movimenti Contabili, Gestione Mutui, Gestione Opere, Contabilità IVA, Gestione Sostituto di imposta ecc.. )

Le seguenti tabelle forniscono dei parametri quantitativi (meramente indicativi e non definitivi) riferiti alle principali informazioni contenute nella b.d ASCOT (dati si riferiscono al 18 novembre 2013):

Tipo Movimenti	Progressivi movimenti presenti sul sistema
Accertamenti	1723
Delibera	11849
Documenti	23818
Impegni	5844
Liquidazioni	15090
Mandati	13756
Prenotazioni	235
Reversali	24499
Variazioni Accertamento	2331
Variazioni Bilancio Pluriennale	690
Variazioni Bilancio Gestione	368
Variazioni Bilancio Previsione	60
Variazioni Bilancio Impegni	3960
Vincolo Reversali Mandati	96

Di seguito si evidenziano i saldi della previsione in essere in termini quantitativi:

Annuale 2013	4.240.757.612,35
Previsione Xxxxxxxxxxx 0000	2.181.044.097,17
Previsione Xxxxxxxxxxx 0000	2.380.294.292,07

Di seguito si evidenziani i saldi della riscossione e dei pagamenti in termini quantitativi

Riscossioni	1.595.271.899,83
Pagamenti	1.630.859.679,01

Di seguito si evidenzia l’entità dei residui attivi e passivi riportati in termini quantitativi

Residui attivi	2.961.132.285,10
Residui passivi	3.592.828.546,05

In ultimo si rappresenta che, in termini di transazioni, le registrazioni in Partita Doppia dell’anno 2012 risultano assunte al numero progressivo di 85.830, significando che per le stesse deve essere valutato l’opportuna declinazione,

in termini di contabilità analitica, in specificanti riqualificazioni di fattore produttivo utilizzato, e centro di costo utilizzatore.

Di seguito, invece si descrive brevemente l’architettura hardware e la dislocazione logistica dell’attuale sistema informativo ASCOT:

• una macchina con applicativo

• una macchina con database di produzione

• una macchina definita e specializzata per utenti esterni

• una macchina, dislocata attualmente in un ufficio del primo piano della sede della Direzione Servizi Finanaziari (vedi art. 8 - Luogo di Lavoro), in regime di stand by data base, sulla quale effettuare lo switch in caso di malfunzionamento del sistema di produzione.

In particolare di seguito si esplicitano le caratteristiche delle apparecchiature su cui è in funzione l’applicativo ASCOT: Application Server:

• S.O. Oracle Linux Red Hat >=5 a x86_64;

• Software di base Oracle Application server 10G; Rdbms:

• S.O. Oracle Linux Red Hat 6 x86_64;

• Oracle database 11gR2 chset UTF8 (necessario per l’utilizzo dei caratteri diacritici);

Rdbms per stand by database:

• S.O. Oracle Linux Red Hat 6 x86_64;

• Oracle database 11gR2 chset UTF8 (necessario per l’utilizzo dei caratteri diacritici);

9.3.3) Documentazione aggiuntiva

Per i dettagli dei requisiti funzionali si rimanda al documento All_Requisiti ASCOT consultabile durante il sopralluogo (vedi art. 45 bis).

9.4 SERVER FARM

La Server Farm (data center) è una infrastruttura tecnologica complessa altamente specializzata a supporto dei servizi telematici erogati dal Comune di Napoli, composta da ambienti computazionali sia fisici che virtuali, quest’ultimi basati su piattaforma Hyper-V R2 di Microsoft (“Microsoft System center” quale suite di management).

Di seguito, sono elencate e descritte le principali componenti architetturali:

a) Sistemi computazionali

b) Storage.

c) network

rimandando ai documenti consultabili durante il sopralluogo (vedi art. 45 bis) per una più approfondita conoscenza degli aspetti riguardanti la topologia della rete, delle politiche di sicurezza logica e fisica, degli aspetti architetturali complessivi e dei singoli dispositivi della Server farm.

a) Sistemi computazionali

I sistemi computazionali sono Fujitsu basati su tecnologia blade server. Con la fornitura Administra sono stati forniti:

• n. 8 Enclosure blade

• n. 14 Server Fujitsu Primergy BX960S1 (4CPU Intel Xeon E7520)

• n. 8 Server Fujitsu Primergy BX960S1 (4CPU Intel Xeon E7520)

• n. 6 Server Fujitsu Primergy BX922s2 (2CPU Intel Xeon E7520)

Si premette che allo stato sono presenti n.7 Blade Chassis Fujitsu BX900 contenenti ciascuno n.9 slot.Ciascuno slot può ospitare, in alternativa, le seguenti tipologie di Blade Server:

Quantità	Tipo Blad Server	Num. Processori	Core per processore	Tot. Core per Blade Server
1	Quad Cpu	4	4	16
2	Dual Cpu	2	4	8

La seguente tabella rappresenta lo stato della disponibilità attuale degli slot:

Slot Totali	Slot utilizzati	Slot disponibili
63	25	38

Per quanto la situazione dei Blade Server riferita alle istanze Oracle, premesso che in ambito Administra furono acquisite 24 licenze Oracle“Full Use” (Enterprise Edition 11g R2 e Oracle Real Application Cluster ) sufficienti a coprire l'utilizzo di n.6 Blade Server della tipologia prevista per l'impiego nel RAC Oracle, attualmente n.2 server sono utilizzati in ambiente Oracle RAC e la seguente tabella fornisce un quadro sinottico del consumo delle risorse dell’ambiente Oracle RAC (in termini di memoria e CPU) rilevate nel mese di ottobre 2013 (fonte: "Enterprise Manager"):

	%CPUmedia	%CPUMax	%MEMmedia	%MEMmax
DBSERVER 1	5	18	55	75
DBSERVER 2	n.a	n.a	n.a	n.a

I restanti n.4 server, in seguito ad una recente riorganizzazione delle risorse, costituiscono un Cluster Hyper-V su cui sono allocati i Server virtuali che utilizzano tali istanze.

Quindi, attualmente, sono impegnate tutte e 24 le licenze Oracle Enterprise Edition. Numero 8 licenze delle suddette 24, sono impegnate sull’ambiente Oracle Rac ove risiede il database del gestionale demografico.

Restano quindi disponibili 16 licenze di tipo Oracle Real Application Cluster che consentirebbero l’estensione dell’ambiente RAC.

Ulteriori n° 6 licenze Oracle Enterprise Edition 11g R2 (“Full Use”) saranno utilizzate (a partire dal 01/01/2014) per il database del gestionale tributario.

Tale Cluster è dotato di n. 64 vCPU e n. 256 GB di RAM, dei quali per esigenze di ridondanza sono effettivamente utilizzabili solo il 75%, ossia N.48 vCPU e N. 192 GB di RAM.

L'impiego delle risorse disponibili è attualmente pari a circa il 50% di quelle utilizzabili

b) Storage

La gestione dello storage è realizzata con apparati unified storage SAN/NAS (NetApp versione v-Series) attraverso l’integrazione delle seguenti componenti:

1. Fujitsu ETERNUS DX 8400 per la componente di mass storage SAN/NAS

2. Controller Nas Gateway (NetApp V-series V3140)

3. Ambiente Disk library consolidato su V3140 Gateway (10 TB di spazio utile)

4. Brocade per gli switch SAN

5. ADIC Scalar i500 ADIC Scalar® i500 per la Tape Library

6. Hitachi Content Platform 300 per il CAS

Relativamente al punto 1) il dispositivo Fujitsu ETERNUS DX 8400 è composto, tra l’altro, da n. 2 Rack dotati di complessivi N. 16 "Drive Enclosure", ognuno dei quali ha N.15 Slot per inserire gli opportuni Hard Disks. Il Software di gestione è ETERNUS SF Storage Cruiser. Sono pertanto presenti n. 240 Slot, di cui liberi n. 112.

Relativamente al punto 4) allo stato sono presenti n. 2 Switch Brocade 5100, i quali dispongono ognuno di n.5 gruppi di n.8 porte. Attualmente sono licenziati n.3 gruppi per un totale di 24 porte utilizzabili, di cui 21 già occupate. Atteso che ogni Blade Server, per ridondanza, deve essere connesso ad entrambi gli switch, la disponibilità attuale di connessioni alla SAN, coperta da licenze, è assicurata per solo ulteriori n.3 server. Il numero totale di server che è

possibile connettere, previo acquisto di ulteriori licenze ed altre componenti (tranceiver e cavi in fibra ottica) è pari a

16. La seguente tabella rappresenta sinteticamente tale situazione:

Totale Porte	Totale Porte Licenziate		Totale Porte Non licenziate
40	24	21 occupate	16
		3 libere

Alla luce di quanto esposto, pertanto, è possibile ancora connettere alla SAN altri 3 Blade Server senza l'acquisto di ulteriori licenze, mentre, previo acquisto delle relative licenze nonché altri dispositivi (tranceiver e cavi in fibra ottica) è possibile connettere ulteriori N.16 Server.

Realativamente al punto 5) la Tape Library è in uso esclusivo alla piattaforma Symantec NetBackup Enterprise 7.0 che con le seguenti componenti: Netbackup Master Server 7.0, SSO Shared Storage Option, NDMP Option, NBU Vault, Netbackup Live Update,OPS Center (racchiude le funzionalità dei due software di monitoring “NetBackup Operations Manager (NOM)” e “Veritas Backup Reporter (VBR)”) assicura i backup ed ripristini degli ambienti multipiattaforma, dei database e delle macchine virtuali Hyper-V.

La tape library ADIC Scalar i500 ADIC Scalar® i500 presenta la seguente configurazione:

• Cabinet da rack 14U

• 2x Drive LTO4 FC espandibili a 18

• 87 Slot disponibili espandibili a 400

Allo stato solo 10 slot sono occupati dalle sole 10 tape cassette di cui una utilizzata per il clearing.

Relativamente al punto 6 si rappresentano, di seguito, le seguenti caratteristiche del modello Hitachi Content Platform 300:

• Spazio Storage utile: 12.5 TB

• Protezione dati tramite RaidS e DPL2 (doppia copia)

• 1 nodo search ( specializzato nell'indicizzazione -full text- dei dati e metadati, e successiva ricerca) fornito di interfaccia web -stile motore di ricerca tramite query a testo libero.

Allo stato tale risorsa, che rappresenta una soluzione autoconsistente basata su architettura RAIN, con API per integrazione con terze parti che utilizzano protocolli di comunicazione standard, è stato acquisito quale repository di 'fixed content" ( documenti amministrativi o legali, delibere di giunta, determinazioni e materiale di riferimento, allegati di posta elettronica, ... ) di oggetti allocati per il tramite di applicativi che utilizzano specifiche API, è non alimentato elettricamente né connesso ad alcuna rete di comunicazione, pertanto, non utilizzato ovviamente da alcuna applicazione.

c) Network

L’architettura di rete del nuovo data center è basata su n° 4 switch modulari AT-SBx908 di Allied Telesis, per complessive 288 porte ethernet da 1 Gbps necessarie all’interconnessione dei blade chassis, della CAS, dello storage e di tutto quanto debba essere collegato in Lan Ethernet.

Attualmente il numero delle porte ethernet occupate è pari a circa il 50%. Occorre però tener presente che l'eventuale implementazione della ridondanza potrebbe incrementare tale occupazione fino a circa il 70 %.

Atteso che ogni server dispone di N.6 porte, il restante 30% sarebbe sufficiente a connettere almeno ulteriori N.14 Server, previo acquisto di tranceiver e cavi opportuni.

Art. 10 – Requisiti Soluzione Applicativa

Le ditte partecipanti hanno la facoltà di arricchire ed integrare i moduli applicativi esistenti e di proprietà del Comune di Napoli e/o fornire soluzioni applicative nuove soddisfacenti i requisiti funzionali dei moduli de quo.

La cessione della proprietà intellettuale alla Stazione Appaltante della soluzione applicativa sarà valutata positivamente in fase di aggiudicazione.

I requisiti della soluzione nella sua interezza e le specifiche esigenze dei servizi comunali coinvolti sono di seguito rappresentati.

10.1) Requisiti Minimi della soluzione offerta

La mancanza o la inesattezza di un solo requisito del presente paragrafo comporta l’esclusione dalla gara:

1. Le applicazioni devono essere sviluppate in tecnologia web oriented. I client devono utilizzare un web browser per interfacciarsi con i gestionali in questione. I moduli applicativi dovranno essere compatibili con i maggiori browser in uso (Internet Explorer, Mozilla Firefox, Google Chrome, Opera, Safari ) di cui almeno uno non legato ad ambienti operativi proprietari. Gli applicativi devono essere interfacciabili con altri sistemi informativi attraverso Web Services (di cui devono essere rese disponibili le API);

2. I singoli moduli gestionali costituenti la soluzione offerta dovranno consentire l’utilizzo concorrente di più operatori.

3. La soluzione offerta, comprensiva delle procedure di cui si compone, dovrà attenersi alla normativa nazionale, regolamenti interni ed implementare tutte le funzionalità ivi richieste. A titolo esemplificativo e non esaustivo riportiamo alcuni obblighi normativi che la soluzione dovrà assolvere:

🞏 Il gestionale dei servizi demografici dovrà adottare dei criteri di codifica delle entità (persone, immobili, località, ecc.) che siano conformi alle direttive Ministeriali;

🞏 Coerenza con le linee guida del nuovo C.A.D.” Codice dell'Amministrazione digitale” di cui al D.Lgs.vo 7 Marzo 2005, n.82, come modificato dal D.L. 18 Ottobre 2012,n.179, convertito, con modificazioni, dalla L. 17 Dicembre 2012, n. 221

🞏 Garantire la realizzazione del progetto che istituisce l' A.N.P.R. ( Anagrafe Nazionale della Popolazione Residente) che subentrerà all'INA e all' A.I.R.E..

4. Il sistema deve prevedere la possibilità dell’esportazione e creazione di documenti compatibili con i formati comunemente in uso compresi quelli open source (PDF, formati Open Office, file di testo, CSV, ods, xml, etc…). Le stampe e gli export devono essere previsti per tutti i moduli funzionali costituenti la soluzione applicativa.

5. La soluzione fornita deve assicurare le medesime funzionalità e personalizzazioni (di tipo funzionale) degli applicativi preesistenti comprese le interazioni con tutti gli applicativi (interni ed esterni) all’Amministrazione, consentendo la customizzazione del prodotto in funzione di specifiche esigenze dell’Amministrazione.

6. La soluzione offerta deve preservare la completa autonomia funzionale e prestazionale delle aree coinvolte. E’ fondamentale che l’autonomia organizzativa e funzionale dei servizi sia rispecchiata nella soluzione architetturale e funzionale proposta. Ad esempio esigenze di particolari elaborazioni massive e/o operazioni di manutenzione dell’applicativo in uso agli uffici tributari, non devono inficiare e/o essere inficiate né funzionalmente né prestazionalmente da strumentazioni informatiche in uso presso altre aree organizzative dell’Amministrazione (Anagrafe, Bilancio).

7. Interoperabilità: tutti gli applicativi forniti dovranno concorrere a formare un sistema informativo completamente integrato in grado di interagire con gli altri applicativi in uso presso l’Amministrazione e con interfacce che rendano agevole l’interoperabilità con altri sistemi informativi esterni in accordo con il programma avviato dall’Ente con il progetto Coopera et Eroga1; le informazioni dovranno essere condivise da tutte le applicazioni prediligendo, laddove possibile, l’automatismo.

1 Il progetto “Coopera et Eroga” ha come obiettivo la realizzazione di una Piattaforma Cooperativa Comunale trasversale a tutti i Sistemi Informativi attualmente in uso e tale da attingere informazioni, dalle basi informative locali e distribuite, per consentire lo scambio dei dati con altre Banche Dati della PA, in modo efficiente, attraverso regole precise e facilmente governabili, in linea con la normativa in materia anagrafica e del Servizio Pubblico di Connettività.

Tale progetto individua come strumento fondamentale la Costituzione dell'Anagrafe degli Oggetti Territoriali. A partire dalle Anagrafe Territoriali già esistenti (Viario, Unità Immobiliare, Unità Censuaria, etc.) si intende integrarle, uniformando elementi essenziali quali il civico, l’interno, il codice catastale ed arricchirle con la georeferenziazione.

L’infrastruttura tecnica della soluzione dovrà altresì rispettare tutti le indicazioni e le regole inerenti l’interoperabilità e la cooperazione applicativa con enti esterni così come richiesto dall’art. 7 comma 1 del Dlgs. N.42 del 2005.

Oltre a garantire le attuali consistenze e livelli di integrazione e cooperazione applicativa descritti, dovrà essere garantito un ulteriore set di elementi di integrazione/interoperabilità e cooperazione applicativa richiesti per i moduli oggetto della gara e di seguito riportati:

🞏 La platea dei contribuenti del gestionale tributi deve integrare le informazioni di natura anagrafica (Nome/Cognome/Indirizzo/Decesso/…) direttamente dal sistema informativo demografico. Le variazioni dei dati di natura anagrafica devono, laddove opportuno, modificare in automatico la posizione contributiva dei soggetti coinvolti (Es: decesso del contribuente comporta l’automatica chiusura della posizione contributiva; la modifica dell’indirizzo del soggetto residente a Napoli, qualora risulti contribuente del Comune, deve essere riportata anche nella banca dati tributaria, etc..);

🞏 In riferimento alle necessità degli uffici tributari e contabilità è necessario definire una cooperazione applicativa tra il gestionale in uso agli uffici tributari e quello relativo alla contabilità in particolar modo per poter associare le somme riscosse dall’Ente alle corrispettive voci di bilancio;

🞏 La soluzione deve prevedere l’integrazione e/o l’integrabilità e conseguenziale analisi ed elaborazione all’interno del gestionale in uso agli uffici tributari delle informazioni provenienti dalle seguenti banche dati:

• Agenzia delle Entrate (dichiarazione redditi, locazioni, utenze elettriche, bonifici ristrutturazioni, anagrafe tributaria, etc …)

• Dominio delle Camere di Commercio ( registro delle imprese)

• Dominio della Motorizzazione civile e dell’ACI

• Demanio marittimo

• IRAP ed IRES

• Sistema informativo del lavoro

• Attività produttive

• Edilizia privata, concessioni edilizie

• Toponomastica

• Agenzia del Territorio ( per ciò che concerne informazioni aggiuntive non attualmente integrate quali planimetrie, catasto metrico etc…)

A seguito dell’alimentazione della banca dati tributaria con dati esterni devono innescarsi modifiche automatiche inerenti la posizione contributiva dei soggetti coinvolti (Es: Il cambio di indirizzo di un soggetto giuridico presente nell’anagrafe tributaria comporta l’allineamento automatico dell’indirizzo sul gestionale tributi) oppure devono essere proposte agli operatori delle liste di attività (Es: Chiusura della società nella Camera di Commercio comporta la proposizione di una lista di soggetti giuridici presenti sulla banca dati tributaria e per i quali è necessaria una attività degli operatori Cosap, analogo procedimento per la cessazione della partita iva).

🞏 Garantire il “dialogo” con Enti terzi per il corretto assolvimento dei compiti dell’area demografica (XML SAIA, Xxxxxx, Isi-Istatel, AnagAire, A.N.P.R., etc…).

🞏 Dovrà essere altresì possibile permettere agli Enti pubblici, accreditati o a quelli che intendono accreditarsi, di potere accedere alle informazioni concernenti il singolo Cittadino, la famiglia, i residenti in un determinato indirizzo ad una certa data storica etc... I servizi erogati saranno diversi in base al tipo di autorizzazioni

🞏 La soluzione deve potersi integrare con l’ISTAT al fine di effettuare indagini statistiche.

🞏 La soluzione deve poter gestire le richieste telematiche di certificati dal Casellario giudiziale e dalla Questura

8. Requisiti di Sicurezza. La soluzione deve:

🞏 Adottare procedure di gestione delle credenziali di autenticazione

🞏 Utilizzare un sistema di autorizzazione

🞏 Impedire la perdita/distruzione dei dati

🞏 Garantire l’integrità e l’autenticità delle informazioni

🞏 Assicurare la riservatezza del dato

🞏 Tracciare gli accessi e le operazioni degli amministratori di sistema

🞏 Tracciare le modifiche degli operatori

🞏 Tracciare l’emissione di documenti con relativa marcatura temporale

🞏 Definire le politiche di configurazione e di aggiornamento dei sistemi server in termini di sistema operativo e applicazioni di base (host hardening).

Oltre ai suddetti punti è altresì richiesto che vengano ottemperate tutte le prescrizioni riportate dal “Disciplinare Tecnico in materia di misure minime di sicurezza”, Allegato B del Decreto Legislativo n.196 del 30/6/2003

I succitati requisiti devono essere sostanziati in un apposito documento (“Sicurezza Informatica della Soluzione”) e nel quale si richiede che ciascuno dei suddetti punti sia dettagliato tecnicamente (esplicitando protocolli, configurazioni, porte, algoritmi, policy e tecnologie, …).

9. Requisiti progettuali. L’offerta tecnica delle ditte partecipanti dovrà comprendere:

🞏 Una descrizione dell’architettura hardware e software del sistema che realizza gli ambienti logici di sviluppo, collaudo ed esercizio

🞏 Una descrizione dell’architettura e delle componenti software, dei moduli applicativi, delle interfacce e delle caratteristiche di interoperabilità così come richiesto nel punto 7) del presente paragrafo.

🞏 I requisiti di cui al punto 8) devono essere sostanziati in un apposita sezione (“Sicurezza Informatica della Soluzione”) nella quale si richiede che ciascuno dei punti sia dettagliato tecnicamente (esplicitando protocolli, configurazioni, porte, algoritmi, policy e tecnologie, …).

🞏 Un documento o insieme dei documenti nei quali è descritto il modello logico e fisico dei dati.

🞏 Le metodologie e le tecniche con le quali sarà effettuato il processo di migrazione, fermo restando l’obbligo di articolare e rendicontare l’attività di migrazione così come richiesto nel articolo 15.7.

🞏 A valle di tutte le attività propedeutiche (analisi, progettazione, definizione delle procedure automatiche e non, etc…), la Stazione Appaltante stabilisce in un massimo di tre giorni solari il tempo utile per l’esecuzione del completo trasferimento dei dati sul nuovo sistema (Fase di Realizzazione della Migrazione – par. 13.2 ) al fine di non gravare eccessivamente sulla operatività degli uffici coinvolti. Altresì sarà richiesto l’espletamento di almeno due fasi di caricamento dati da realizzarsi in corrispondenza del “pronti all’uso” ed al termine della “fase di parallelismo”.

🞏 E’ fatto obbligo di stilare le proposte progettuali attenendosi al template fornito in allegato [AllegatoB_SchedaOffertaTecnica]

10. Data Quality. L’Amministrazione richiede che in sede di presentazione delle offerte venga redatta una proposta progettuale inerente alla definizione di un sistema atto alla misurazione, monitoraggio e reportistica della qualità delle banche dati così come specificato nell’allegato [AllegatoC_Data_Quality]. Tutti gli elementi costituenti la suddetta proposta progettuale saranno considerati parte integrante della soluzione offerta.

11. La soluzione deve essere predisposta presso la Server Farm del Comune di Napoli, laddove necessario dovranno essere fornite e predisposte le apparecchiature hardware ed in ogni caso deve essere garantita la manutenzione hardware dei dispositivi forniti nell’ambito della soluzione offerta per tutto il periodo contrattuale anche se gli stessi sono già nelle disponibilità dell’Amministrazione.

Saranno valutate favorevolmente le soluzioni che si integreranno e potenzieranno con l’ambiente Oracle RAC attualmente predisposto presso la Server Farm.

La soluzione dovrà altresì essere integrata all’interno dell’infrastruttura di rete fonia e dati predisposta presso la Stazione Appaltante.

12. Servizi di firma digitale e fornitura dei certificati di firma. Il sistema informativo fornito deve essere integrabile con gli strumenti di firma digitale attualmente in uso al Comune di Napoli (visionabili durante il sopralluogo vedi art. 45 bis) e con tutti gli strumenti di firma digitale che la Stazione Appaltante utilizzerà durante tutta la durata contrattuale.

13. Fornire una soluzione che razionalizzi, integri e potenzi i servizi online in possesso dell’Amministrazione (vedi Portale delle Entrate e Servizi Online del Comune di Napoli) e relativi alle aree interessate (Anagrafe, Tributi e Contabilità). I suddetti servizi devono essere esposti tramite predisposto link disponibile sul sito istituzionale, organizzati sulle rispettive aree tematiche, ed acceduti attraverso il sistema di autenticazione dei “Servizi Online” del Comune di Napoli. Ad integrazione dei servizi online già predisposti, di seguito elenchiamo alcuni dei nuovi servizi online che dovranno essere esposti:

🞏 I Xxxxxxxxx accreditati devono poter consultare i propri dati, prelevare le modulistiche necessarie alle loro esigenze, iscriversi ai vari albi gestiti dal Comune ( Scrutatori, Presidenti di Seggio, Giudici popolari etc…), interagire con gli Uffici, o accedere ad un servizio di autocertificazione.

🞏 Richiesta del duplicato/rinnovo della tessera elettorale e del tagliando aggiornamento tessera elettorale

🞏 Consultazione on-line del cartellino individuale e della famiglia alla data attuale

🞏 Consultazione on-line del cartellino individuale e della famiglia alla data storica

🞏 Avvio pratiche di iscrizione, emigrazione, immigrazione e cambio di abitazione

🞏 Visualizzazione dei Tributi locali pagati e da pagare

🞏 Pagamento dei Tributi locali online

E’ altresì richiesto che la grafica e gli stili in uso per i suddetti servizi siano resi omogenei a quelli attualmente in uso per i Servizi Online del Comune di Napoli.

14. Definizione di un ambiente di replica disponibile presso sede comunale differente dalla Server Farm. La base dati dell’ambiente di replica dovrà essere periodicamente allineata mediante procedure schedulate. Gli intervalli di schedulazione e di allineamento saranno concordati con la Stazione Appaltante e terranno conto delle prestazioni inerenti all’infrastruttura tecnologica messa a disposizione e della mole di variazioni medie nell’arco di tempo cui i singoli moduli gestionali sono soggetti.

10.2) Requisiti aggiuntivi

Requisiti desiderati ma non vincolanti sono di seguito riportati:

1. I moduli gestionali oggetto di gara devono consentire l’archiviazione ottica dei documenti e debbono integrarsi con un sistema di archiviazione documentale e con il Content Addressable-Storage (CAS) sito presso la Server Farm al fine di fornire agli operatori dell’Amministrazione una rapida consultazione degli atti (Es.: possibilità di caricare atti giudiziari relativi a contenziosi con i contribuenti; caricamento atti di autotutela del contribuente; …)

2. L’insieme dei servizi online esposti dal Comune di Napoli, così come rimodulato secondo le disposizioni del punto 13 del paragrafo 10.1, deve consentire all’utenza l’invio di istanze e comunicazioni con firma elettronica digitale e con la possibilità per il contribuente di ricevere il protocollo di ricezione del documento e, per il Comune, di visualizzare e, in caso di accettazione, di acquisire senza alcuna digitalizzazione ed istantaneamente il documento ed i dati all'interno del sistema integrato dei tributi/anagrafe e contabilità, variando in tempo reale la posizione amministrativa/contributiva anche nel portale (invio istanze di autotutela, cessazione posizione Tares, iscruzione in anagrafe, cambio di residenza, …)

3. Possibilità di disegnare in autonomia la struttura (in termini sia di layout, sia di contenuto) di tutti i certificati e di tutte le comunicazioni

4. Fornitura hw e sw dell’ambiente di sviluppo del software oggetto di gara e di proprietà dall’Amministrazione.

10.3) Requisiti Minimi Specifici per Area

10.3.1) Requisiti specifici area Demografica

Di seguito si elencano requisiti minimi richiesti specifici dell’area Demografica, non assolti dal gestionale attualmente in uso presso l’Amministrazione.

🞏 Deve essere definito un modulo che gestisca i dati della toponomastica con particolare riferimento all’elenco ufficiale delle strade, pubblicato sul portale del Comune; gli indirizzi devono essere normalizzati secondo i parametri della legge Anagrafica (DPR 30/05 1989). La struttura dell’indirizzo deve essere composta:

o Specie (o Dug) – Via, Viale, Piazza, Strada Comunale, Vico, Vicoletto, etc.

o Inter – Del, Della, Di, etc.

o Denominazione - Nome e Cognome, etc.

o Civico – campo numerico

o Suffisso o esponente – Campo alfanumerico – A, B, C, Bis, etc.

o Identificativo Edificio – Attuale lotto, isolato, palazzina etc.

o Scala – A, B, C, 1,2 etc.

o Interno. (identificativo della singola unita immobiliare)

Per ogni indirizzo si dovrà prevedere la possibilità di agganciare una coppia di coordinate geografiche.

🞏 Il sistema deve prevedere funzionalità avanzate di invio massivo di documenti agli indirizzi PEC memorizzati anche in base a criteri di filtraggio dei destinatari;

🞏 Predisposizione all’esportazione dei dati e certificati verso il sistema informativo delle poste (documento consultabile durante il sopralluogo vedi art. 45 bis);

🞏 Per i certificati da rilasciare ai privati, e per i diritti di segreteria deve essere prevista la gestione del bollo virtuale;

🞏 Gestione certificazione relativa al godimento dei diritti politici con storicizzazione;

🞏 Gestione Leva scolastica;

🞏 Gestione dati Censimenti della popolazione, estrazione dei dati per creare il file per la L.A.C., gestione delle zone censuarie territoriali, ed inserimento automatico, sulle schede di famiglia ed individuali, dei dati di censimento. Dovrà essere possibile effettuare estrazioni dei Cittadini censiti, non censiti, e di quelli che presentano dati duplicati. Gestione revisione post censuaria, incrocio dati ed estrazione automatica dei risultati richiesti per la creazione dei files da trasferire all’ISTAT;

🞏 Gestione donazione organi come tratto identitario e Testamento biologico: il gestionale in uso agli uffici demografici deve poter gestire le informazioni dei "donatori" condiviso dalle Municipalità, con la finalità di memorizzare la volontà dei Cittadini che esprimono presso gli Uffici delle Municipalità il desiderio di aderire al sistema informativo trapianti (donazione organi), e la volontà dei Cittadini di essere/non essere sottoposti a trattamenti medici in caso di perdita di coscienza permanente ed irreversibile (testamento biologico). Il database dovrà essere integrato con il software anagrafe, e dovrà provvedere comunque ad inviare i dati inseriti ogni giorno al sistema informativo trapianti nazionali, e a registrare i dati di acquisizione e conservazione dei dati relativi alla dichiarazione anticipata di volontà sui trattamenti medici. L'applicativo deve fornire le funzioni sia per memorizzare la volontà nel donare gli organi, sia per gestire le dichiarazioni di volontà del testamento biologico, con creazione di registri protocolli. L’applicazione deve consentire, per la donazione organi, il trasferimento/modifica e cancellazione dei nominativi da e verso il sistema informativo trapianti, per il testamento biologico analoghe funzioni da e verso la banca dati interna; relativamente alla modulistica la procedura dovrà produrre e gestire tutti i moduli cartacei propedeutici e consequenziali, ed opportunamente adattati alle esigenze di gestione delle funzionalità in parola da e verso Uffici/Cittadini;

🞏 Gestione delle funzionalità esposti ad enti esterni al comune secondo le convenzioni stipulate;

🞏 Gestione di tutti documenti elettorali, prodotti dall’ufficio elettorale medesimo o provenienti da altri Comuni, e che costituiscono il fascicolo attribuito ad ogni elettore; il modulo gestionale dovrà consentire la creazione del fascicolo per nominativo, con relativa assegnazione di progressivo, ed inclusione dei documenti prodotti e/o pervenuti sia in formato cartaceo sia in formato elettronico. Dovrà essere altresì possibile effettuare rilevazioni dei fascicoli degli elettori cancellati (emigrati, deceduti, irreperibili, etc…) e consentire la stampa e/o invio (PEC, email) ad altri Comuni di codesti listati.

Per ogni elettore dovrà sempre essere possibile la visualizzazione, l’estrazione, e la stampa di singoli documenti o dell’intero fascicolo;

🞏 Gestione dei dati relativi ai Candidati e ai Cittadini che sottoscrivono le Liste elettorali, identificazione casi anomali (Es. Candidati presenti in più liste, Sottoscrittori presenti in più liste, …);

🞏 Gestione di più revisioni dinamiche straordinarie in concomitanza di più consultazioni elettorali, con conseguente gestione separata delle Liste elettorali da inviare ai Seggi;

🞏 Gestione e visualizzazione di tutte le consultazioni elettorali , con storicizzazione dei dati riferiti al singolo elettore; fornitura di dati statistici (Es. dati sulla partecipazione alla tornata elettorale, …); stampa ed export dei prospetti riepilogativi; rilevazioni antecedenti alla chiusura dei seggi; raffronti con le precedenti elezioni; risultati in tempo reale; rilevazione delle preferenze singoli Candidati e Liste; calcolo automatico dei seggi; modelli riepilogativi per la Prefettura;

10.3.2) Requisiti specifici area Tributi

Di seguito si elencano requisiti specifici dell’area Tributi, non assolti dal gestionale attualmente in uso presso l’Amministrazione:

🞏 La soluzione offerta per il modulo gestionale dei tributi dovrà includere la funzionalità per il trattamento dell’imposta di soggiorno.

🞏 Il gestionale dei tributi deve poter gestire tutte le fasi relative alla riscossione del tributo locale

10.3.3) Requisiti specifici area Finanziaria

Nel caso specifico dell’Aria Finanziaria, l’applicazione deve garantire i seguenti punti:

🞏 La continuità gestionale attraverso la presenza in linea ( consultabili dagli utenti registrati ) degli esercizi dal 1996 ad oggi, garantendo altresì il mantenimento in linea degli esercizi precedenti, con accessi e modalità operative differenziate per gli utenti abilitati affinché si possano effettuare operazioni di gestione sull’esercizio in corso e su quello precedente (fino all’approvazione del consuntivo). Le operazioni di interrogazione possono essere effettuabili su qualsiasi esercizio archiviato;

🞏 La Configurabilità del piano dei conti della contabilità finanziaria e della contabilità economica ed analitica, nella fattispecie ai capitoli ed ai conti devono essere liberamente attribuibili codici di classificazione per rappresentarne le più diverse caratteristiche, anche non definibili preliminarmente (natura, commessa, programma, rigidità della spesa, etc.). I codici devono poter essere liberamente utilizzati secondo i criteri tipici dell’analisi multidimensionale: creazione di gerarchie – sulla base di esigenze ed esperienze specifiche dell’ente e gestite direttamente dagli utenti .Inoltre il sistema deve prevedere la configurabilità della struttura organizzativa (Settori, Servizi, Centri di Responsabilità) e del Piano dei conti economico-patrimoniale senza vincoli dettati dal programma e la configurabilità della struttura programmatoria (Programmi, Progetti) per i bilanci pluriennali e la relazione previsionale programmatica; Il sistema deve anche dare la possibilità di generare automaticamente la movimentazione della Contabilità economica ed analitica contestualmente alle transazioni della Finanziaria. Le scritture di partita doppia così generate devono essere configurabili parametricamente in base alle esigenze dell’Ente. La contabilità analitica deve essere intesa come disaggregazione degli eventi contabili di natura economico-patrimoniale ma anche finanziaria (impegni, liquidazioni e mandati), per attivare un processo di lettura gestionale degli stessi, dalla rilevazione dell’incidenza dei singoli centri di responsabilità, alla valorizzazione delle prestazioni e dei servizi erogati;

🞏 Il decentramento ai Settori esterni funzioni di consultazione (possibilità di analisi dei dati contabili con diverse modalità di visualizzazione e di lettura e con la possibilità di accedere ai soli dati di propria pertinenza) ma anche di immissione dati (ad es. la liquidazione tecnica), a tal proposito l’amministratore di sistema deve avere la possibilità di parametrizzare le abilitazioni degli operatori non solo per funzione e operazione, ma anche in funzione dei Centri di Responsabilità di riferimento, in modo che le funzioni decentrate utilizzate dai funzionari amministrativi dei vari Settori dell’Ente operino solo sui dati di competenza (Peg Contabile per Cdc);

🞏 La Generazione automatica delle registrazioni di contabilità economico-patrimoniale ed analitica a partire dalle transazioni finanziarie, secondo il seguente schema di massima:

o Possibilità di inserire il conto dare ed avere:

1) nell’ anagrafica del capitolo/articolo

2) nell’ impegno/accertamento

3) nei documenti contabili attestanti l’entrata o spesa (es. fattura)

o Possibilità di scelta di creazione automatica delle scritture di contabilità economico-patrimoniale ed analitica da:

1) movimenti finanziari di impegno e accertamento;

2) movimenti finanziari di liquidazione

3) movimenti finanziari di emissione mandato di pagamento e ordinativo d’incasso

o Nell’anagrafica del capitolo/articolo di previsione deve essere possibile indicare il conto di rilevazione del costo (o ricavo) o di variazione patrimoniale;

o Nelle transazioni di registrazione accertamenti/impegni e documenti contabili (fatture o altri documenti attestanti entrate o spese) deve potersi indicare il periodo di competenza economica;

o La gestione dei movimenti economico-patrimonali, indipendentemente dalla creazione (automatica da movimenti fmanziari o con registrazione manuale dell’operatore), deve poter essere resa

autonoma dalla contabilità finanziaria e gestita in modo libero dall’ufficio di controllo di gestione;

o Produzione automatica di Conto del patrimonio Conto Economico (anche per singolo centro di costo), Prospetto di Conciliazione.

🞏 La Gestione della Contabilità IVA, della Contabilità del Sostituto di imposta, della tenuta della Contabilità ai fini IRAP.

🞏 Gli automatismi nella gestione della contabilità economica ed analitica: deve garantire Il collegamento uno ad uno dei capitoli vincolati, che deve essere gestito dal sistema in un ottica di gestione flessibile degli eventi. In particolare, la gestione degli elementi utili alla registrazione in Partita Doppia in particolare dei documenti, delle fatture, delle liquidazioni, degli impegni, dei mandati di pagamento, degli accertamenti e delle reversali d’incasso deve essere scatenata con regole di derivazione – gestite in forma autonoma dall’Ente - che consentano con automatismi di gestire la contabilità economica ed analitica. Sulla Relazione Previsionale e Programmatica, oltre ai dati storici e prospettici recuperati dalla contabilità, il sistema deve dare la possibilità di gestire con diverse modalità di lavoro la parte descrittiva. Inoltre deve dare la possibilità di recuperare automaticamente, come base di partenza, l’impianto descrittivo definito nell’anno precedente.

🞏 La Contabilità Fiscale che deve risultare completamente integrata all’interno della Contabilità Finanziaria ed Economica al fine di avere una gestione univoca, a partire dagli eventi di gestione finanziaria interessati (documenti, ordinativi di pagamento e di riscossione, ecc).

🞏 La Gestione degli ordinativi informatici attraverso l’integrazione del sistema alla procedura Unimoney. In particolare si devono gestire oltre le casistiche standard dei pagamenti, anche le seguenti casistiche:

o provvisori da regolarizzare parziali e gestiti in remoto dai competenti servizi dell’Ente;

o mandati di pagamento consecutivi a più liquidazioni con CIG diversi;

o vincoli di entrata e spesa e controllo del saldo;

o gestione dei girofondi;

o bonifico estero;

o cessione del credito;

o trattenute;

o assegnazioni in forza di atti di terzi;

🞏 L’integrazione totale con il modulo di gestione finanziario attraverso l’acquisizione automatica di documenti contabili provenienti da altre procedure esterne, attraverso opportuni file di scambio o altre modalità. In particolare, la procedura deve consentire le seguenti operazioni:

• Estrazione dei file per l’invio telematico del rendiconto e allegati alla Corte dei Conti, secondo le previsioni dell’art. 227 del D.Lgs. n. 267/2000 del 18.08.2000, adeguandosi alle esigenze di trasmissione telematica di dati previste dalla normativa attuale e dalla sua evoluzione;

• Integrazione con sistemi di data warehouse per la generazione di reportistica per il Controllo di Gestione;

• Esportazione ed importazione di dati che consentano l’integrazione con gli altri sistemi presenti presso l’amministrazione, nella fattispecie si dovrà disporre di un modulo per l’estrazione automatica di dati in diversi formati, e consentire, pertanto, l’import dei dati da file esterni, attraverso l’utilizzo di istruzioni basate su script SQL, con le quali verrà garantito oltre all’import dati (istruzione INSERT) anche l’aggiornamento delle informazioni (istruzione UPDATE) e cancellazioni (istruzione DELETE), attività riservata a specifici utenti debitamente autorizzati dall’Amministratore di sistema

• Integrazione tra i moduli di contabilità finanziaria autorizzatoria, contabilità economico patrimoniale, tenuta in partita doppia, con la produzione del conto economico e il conto del patrimonio, contabilità analitica per centro di costo e sperimentazione del bilancio consolidato del sistema Comune.

• Generazione automatica della movimentazione della Contabilità economica ed analitica contestualmente alle transazioni della Finanziaria. Le scritture di partita doppia così generate devono essere configurabili parametricamente in base alle esigenze dell’Ente. La contabilità analitica deve essere intesa come disaggregazione degli eventi contabili di natura economico- patrimoniale ma anche finanziaria (impegni, liquidazioni e mandati), per attivare un processo di lettura gestionale degli stessi, dalla rilevazione dell’incidenza dei singoli centri di responsabilità, alla valorizzazione delle prestazioni e dei servizi erogati;

• Collegamento uno ad uno dei capitoli vincolati, gestito dal sistema in un ottica di gestione flessibile degli eventi In particolare, la gestione degli elementi utili alla registrazione in Partita Doppia in particolare dei documenti, delle fatture, delle liquidazioni, degli impegni, dei mandati di pagamento, degli accertamenti e delle reversali d’incasso deve essere scatenata con regole di derivazione – gestite in forma autonoma dall’Ente - che consentano con automatismi di gestire la contabilità economica ed analitica;

• Nell’ottica dell’Armonizzazione, la Gestione del Fondo vincolato pluriennale dovrà necessariamente contemplare la trasmigrazione degli accertamenti di entrata anche quando sono stati movimentati, idem nella parte spesa, connaturando la natura della obbligazione originaria. Le due funzioni devono comunque tenere in linea la partenza della obbligazione ( anno codice - tipologia di finanziamento la cui definizione deve essere lasciata libera per essere validata dall' utente debitamente autorizzato );

• Gestione di tutti i moduli (bilancio, movimenti contabili, IVA, mutui, cassa economale, ), con

un sistema di riclassificazioni che consenta di impostare l’evidenza di fenomeni contabili per i quali non sono previste specifiche funzioni dettate dal Legislatore, ma rispondono ad esigenze dell’Ente o dei decisori politici.

• Gestione delle Opere e schede di somme vincolate, e delle relative sub opere attraverso un sistema che deve risultare integrato, ridondante, seppure non legato al concetto di competenza finanziaria.

Art. 11 – Servizi e Formazione

11.1) Manutenzione /gestione applicativa

I servizi di assistenza applicativa richiesti nel presente capitolato tecnico e che il Fornitore si obbliga ad effettuare per tutto il periodo contrattuale sono finalizzati alla manutenzione delle applicazioni software in gestione e/o fornite ex novo di seguito a tutti i moduli applicativi, compresi quelli correlati e che costituiscono il s.i. integrato oggetto della fornitura.

I servizi di assistenza applicativa sono finalizzati a assicurare, nelle modalità e nei tempi di seguito specificati:

• la manutenzione correttiva ed adeguativa;

• la manutenzione evolutiva;

In ogni caso l’aggiudicatario deve garantire l’ottimale fruizione dei servizi erogati sia all’utenza interna all’Amministrazione che a quella esterna ed assicurare che tutti gli moduli applicativi gestiti e/o forniti abbiano le caratteristiche funzionali e qualitative richieste, siano adeguati agli scopi e mantenuti costantemente allineati alle esigenze dell’Amministrazione ed alla normativa vigente.

Sono considerate parte integrante dell’erogazione dei servizi di assistenza tutte le attività volte all’aggiornamento ed all’integrazione della documentazione a corredo degli applicativi oggetto della fornitura.

Si precisa che negli ultimi due mesi di validità contrattuale il Fornitore è obbligato a fornire all’Amministrazione o a terzi dalla stessa designati, ogni informazione e/o documentazione atta al trasferimento del know-how sulle attività condotte, senza alcun onere aggiuntivo per l’Amministrazione, tanto al fine al fine di rendere l’eventuale prosecuzione delle attività quanto più efficace possibile.

Come parte integrante dell’offerta tecnica, il Fornitore deve indicare il sistema informativo che intende fornire all’Amministrazione, entro tre mesi dalla data di inizio delle attività (o entro il termine previsto nell’offerta tecnica, se migliorativo), per il controllo della fornitura relativa all’area in questione e dei singoli servizi di assistenza applicativa che la compongono, preferibilmente ma non necessariamente integrato alla Stazione di Gestione, Monitoraggio e Controllo.

Di seguito si enucleano, in via indicativa ma non esclusiva, le funzionalità che il sistema informatico deve garantire:

• inventario funzionale degli applicativi;

• repository della documentazione degli applicativi oggetto della fornitura (con caricamento di quanto preesistente);

• gestione del change e configuration management;

• strumenti di controllo e verifica dei requisiti di qualità e dei livelli di servizi richiesti;

• risultati sulle misurazioni dei livelli di servizi;

• strumenti di cruscottistica;

• esiti delle attività di test e di collaudo;

• gestione dei progetti di sviluppo applicativo e manutenzione adeguativa ed evolutiva;

• Piattaforma di trouble ticketing nella quale dovrà essere registrata ogni segnalazione della Stazione Appaltante ed ogni intervento di manutenzione attribuendo loro la corrispondente categoria di malfunzionamento e collegando tra loro le segnalazioni relative ad un unico guasto.

Allo scadere del contratto Il sistema informatico integrato, unitamente alla infrastruttura tecnologica di supporto al sistema ed alle licenze d’uso del software offerto, rimarrà di proprietà dell’Amministrazione.

L’Amministrazione valuterà eventuali proposte migliorative riguardanti le modalità di erogazione dei servizi richiesti per l’area e finalizzate a migliorare i s.i. de quo in termini organizzativi, tecnici ed economici.

Gli standard e le norme tecniche di riferimento applicabili all’Area Gestione Applicativi sono quelle di seguito riportate a meno di nuove release vigenti alla data :

□ UNI EN ISO 9001:2008 Sistema di gestione per la qualità – Requisiti

□ UNI EN ISO 9004:2009 Sistema di gestione per la qualità – Linee guida per il miglioramento delle prestazioni.

11.1.1) Manutenzione Correttiva ed Adeguativa

La manutenzione correttiva comprende tutte le attività volte alla diagnosi e quindi alla rimozione delle cause e degli effetti delle malfunzioni delle procedure e dei programmi in esercizio, comunque verificatesi (ad es. blocco della applicazione/funzione, differenze tra l’effettivo funzionamento del software applicativo e quello atteso, come previsto dalla documentazione o comunque determinato dai controlli che vengono svolti durante l’attività degli utenti…….), garantendo nei tempi previsti il completo ripristino delle funzionalità degli applicativi oggetto dell’appalto e, laddove possibile, migliorando la qualità originale degli applicativi in modo da ottimizzare i tempi di successivi interventi.

Sono altresì oggetto di interventi di manutenzione correttiva i malfunzionamenti derivanti da difetti (errori presenti nel software, latenti finché non rilevati, che danno luogo a malfunzione) presenti nel codice sorgente e non rilevati durante il ciclo di sviluppo, collaudo e test della specifica applicazione.

Per malfunzioni derivanti da difetti non imputabili al software applicativo ma ad errori tecnici, operativi o ad altre componenti tecnologiche infrastrutturali (ad es. software di base, d’ambiente, rete…) i servizi di manutenzione correttiva dovranno comunque assicurare un valido supporto all’attività diagnostica sulla causa della specifica malfunzione, la cui soluzione è comunque demandata ad altre strutture.

Il costo di tale tipologia di manutenzione è da intendersi già incluso nella somma all’ art. 6.

La manutenzione adeguativa deve comprendere tutte l’attività di manutenzione volte ad assicurare la costante aderenza degli applicativi, oggetto dell’appalto, alla evoluzione dell’ambiente tecnologico del sistema informativo ed al cambiamento dei requisiti (organizzativi, normativi, d’ambiente) ed include in maniera indicativa ma non esclusiva:

1. adeguamenti dovuti a seguito di cambiamenti di condizioni al contorno (ad esempio per variazioni al numero utenti, miglioramenti delle performances, aumento delle dimensioni delle basi dati, ecc.);

2. adeguamenti dovuti all’introduzione di nuove release del software di base, d’ambiente comprese l’introduzione di nuovi prodotti o modalità di gestione del sistema;

3. migrazioni di piattaforma;

4. modifiche anche massive, non a carattere funzionale, delle applicazioni (ad. es. cambiamento layout maschere);

5. adeguamenti dovuti a seguito di cambiamenti organizzativi, nuove disposizioni di legge, regolamenti, direttive in ambito nazionale o sovranazionale da effettuarsi nei tempi utili affinchè il sistema informativo sia sempre a norma e consenta agli uffici la normale e completa erogazione dei servizi ad essi afferenti;

6. modifiche al normale funzionamento dell’applicativo al fine di consentire ai preposti uffici la lavorazione di pratiche anche in virtù di possibili anomalie procedurali (Es. eliminazione vincoli degli applicativi a causa di ritardi nella lavorazione delle pratiche; eliminazione di vincoli legati ad un presupposto di base dati priva di anomalie, ecc..)

7. modifiche necessarie per rendere il sistema informativo realizzato integrato ed interoperabile con altri sistemi anche esterni individuati con particolare riferimento alle attività di integrazione di sistemi informativi di cui al progetto Coopera et Eroga.

Relativamente agli interventi di manutenzione adeguativa a seguito di nuove disposizioni di legge e/o regolamenti e/o direttive in ambito nazionale o sovranazionale, si precisa che comunque l’Aggiudicatario, anche in assenza di esplicita richiesta da parte della Stazione Appaltante è tenuto a:

• tenersi aggiornato sulle modifiche di normativa

• darne comunicazione alla Stazione Appaltante

• realizzare entro i termini stabiliti per legge gli interventi in questione, precisando che in tale fattispecie la mancata realizzazione dei necessari interventi di manutenzione adeguativa è in ogni caso responsabilità dell’Aggiudicatario, a cui si potranno addebitare le penali per mancata consegna intervento nei termini (che in mancanza di comunicazione esplicita da parte della Stazione Appaltante sono quelli stabiliti dalla normativa) oltre ad eventuali risarcimenti del danno nei confronti della Stazione Appaltante.

Gli obiettivi che la manutenzione correttiva ed adeguativa deve in ogni caso assicurare sono:

🞏 mantenere operativa la soluzione (software) attraverso attività che assicurino in via continuativa la rimozione delle malfunzioni;

• assicurare il miglioramento tempestivo delle funzionalità e delle prestazioni, per esempio quando un programma non ha prestazioni adeguate al livello di servizio richiesto e ciò viene percepito come una malfunzione, richiedendo un intervento di correzione;

• garantire l’evoluzione tecnico funzionale della soluzione;

• fornire servizi di supporto per risolvere tempestivamente problemi relativi a malfunzioni ed errori;

• assicurare l’aggiornamento periodico della soluzione, attraverso il miglioramento della funzionalità, dell’affidabilità e dell’efficienza dei prodotti. L'aggiornamento presuppone il rilascio di nuove versioni e/o correzioni dei prodotti da parte del relativo fornitore.

La manutenzione adeguativa è suddivisa in Obiettivi, ognuno dei quali può essere assimilato ad un “progetto”, la cui esecuzione è suddivisa in fasi, secondo un ciclo di sviluppo dipendente dalle dimensioni, dalla criticità e dalla tipologia di applicazione, come descritto nel art 11.1.3.2 .

Per tutti gli applicativi oggetti di intervento di manutenzione adeguativa, il Fornitore si impegna ad assicurare, per la versione conseguente all’intervento stesso, i servizi di manutenzione correttiva senza alcun onere aggiuntivo per l’Amministrazione.

Per gli interventi di manutenzione adeguativa effettuati durante l’ultimo anno di vigenza contrattuale, i servizi di manutenzione correttiva dovranno essere assicurati per i successivi 12 mesi senza alcun onere aggiuntivo per l’Amministrazione.

11.1.2 Manutenzione Evolutiva

I servizi di assistenza applicativa finalizzati alla manutenzione evolutiva degli applicativi devono includere, nella fattispecie, i seguenti aspetti:

🞏 Sviluppo di Software, che comprende:

o gli sviluppi di interi nuovi sistemi applicativi, o parti autonome degli stessi, che risolvono esigenze specifiche a fronte di funzionalità non assolte informaticamente;

o rifacimento di sistemi applicativi, le cui funzionalità non sono soddisfatte con le modalità o le caratteristiche richieste, previa valutazione che non sia conveniente attuare una Manutenzione Evolutiva al software esistente (punto immediatamente successivo).

🞏 Manutenzione Evolutiva, che comprende gli interventi volti ad arricchire il prodotto (di nuove funzionalità o di altre caratteristiche non funzionali, quali l’usabilità, le prestazioni, ecc.) o comunque a modificare o integrare le funzionalità del prodotto. Tale manutenzione implica la scrittura di funzioni aggiuntive d’integrazione a sistemi applicativi esistenti o parti di funzioni (anche in sostituzione di altre già esistenti) di dimensione significativa e di cui è possibile preventivamente definire i requisiti o quantomeno identificare le esigenze. In pratica si tratta di implementazioni di uno specifico sistema informatico, sovente aggregabili fra loro, che comunque danno luogo a una nuova release / baseline del prodotto iniziale.

Durante tutto il periodo contrattuale il fornitore dovrà inoltre essere di supporto per l’analisi e la valutazione di nuove soluzioni e adeguamenti tecnologici, formulando eventuali proposte migliorative motivate ed indicando i costi e benefici connessi. Dovrà inoltre fornire la propria collaborazione per verificare la possibilità di integrare nel Sistema anche soluzioni applicative di altri fornitori attualmente in uso e verificare l'opportunità di utilizzo di banche dati già in dotazione o presenti in altre amministrazioni.

Per le fasi di collaudo, messa in esercizio e post go-live relative al software sviluppato il Fornitore deve essere assicurare il necessario supporto al personale tecnico dell’Amministrazione.

A tal fine si riporta di seguito, in via indicativa ma non esclusiva, un set di attività che dovranno essere comunque assicurate:

🞏 predisposizione dell’ambiente di collaudo e di testing ;

🞏 esecuzione dei test proceduralizzati;

🞏 supporto alle attività di collaudo e risoluzione tempestiva dei malfunzionamenti riscontrati;

🞏 passaggio di conoscenza alle strutture preposte;

🞏 eventuale assistenza agli utenti sia attraverso sessioni di affiancamento (training on the job) sia con documentazione predisposta ad hoc, ad esempio FAQ;

🞏 supporto al passaggio in esercizio: predisposizione dell’ambiente di esercizio (supporto alla configurazione dell’ambiente fisico, configurazione della piattaforma software in funzione dei requisiti statici e dinamici, installazione del software applicativo, definizione e caricamento della base dati,)

🞏 avvio in esercizio del software realizzato;

🞏 partecipazione al tuning dell’applicazione post go-live con il personale tecnico dell’amministrazione all’uopo designato.

La manutenzione evolutiva rilascia prodotti che modificano la consistenza della baseline del sistema, che di norma si incrementa, salvo casi di cancellazione in contemporanea di funzioni obsolete e eventualmente sostituite da quelle nuove sviluppate. Il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari a mantenere aggiornata la baseline.

Qualunque modifica che comporti aggiunta/rimozione di moduli applicativi, modifiche all’infrastruttura e/o schema della base dati deve essere adeguatamente documentata e tendere ad una maggiore riusabilità del prodotto nel suo insieme.

La manutenzione evolutiva è suddivisa in Obiettivi, ognuno dei quali può essere assimilato ad un “progetto”, la cui esecuzione è suddivisa in fasi, secondo un ciclo di sviluppo dipendente dalle dimensioni, dalla criticità e dalla tipologia di applicazione, come descritto nell’art 11.1.3.2.

Per ogni sviluppo di software l’Aggiudicatario, a valle dell’attività di definizione progettuale, deve fornire garanzie all’Amministrazione circa l’impossibilità del riutilizzo di software o parti di esso sviluppati già per la pubblica amministrazione. L’Amministrazione si riserva il diritto di effettuare verifiche anche ex post. Tali verifiche comporteranno, in caso di accertata violazione di quanto dinanzi esposto, la non corresponsione di quanto dovuto al Fornitore.

Per gli interventi di manutenzione evolutiva, il Fornitore si impegna ad assicurare, per la versione conseguente all’intervento stesso, i servizi di manutenzione correttiva ed adeguativa senza alcun onere aggiuntivo per l’Amministrazione.

Per gli interventi di sviluppo e manutenzione evolutiva effettuati durante l’ultimo anno di vigenza contrattuale, i servizi di manutenzione correttiva ed adeguativa dovranno essere assicurati altresì per i successivi 12 mesi senza alcun onere aggiuntivo per l’Amministrazione.

Atteso che il costo della manutenzione evolutiva è da intendersi già incluso nella somma all’art. 6 la realizzazione degli interventi di manutenzione evolutiva eccedenti i limiti di servizio inclusi nell’importo di cui all’art. 6 sono soggetti a verifica di copertura finanziaria dell’anno in cui sono richiesti.

11.1.3) Modalità di erogazione del servizio

L’interfaccia unica dell’Amministrazione verso il Fornitore per i servizi di assistenza applicativa (manutenzione correttiva, adeguativa ed evolutiva) è il Dirigente dei Sistemi Informativi del Comune di Napoli o suoi delegati, differenziati per applicativo.

Il Dirigente del Servizio Autonomo Sistemi Informativi comunicherà formalmente all’Aggiudicatario, entro la data di inizio attività, un elenco dei suoi delegati con indicazione dell’applicativo di riferimento.

Si sottolinea, pertanto, che nessuna erogazione di servizi di assistenza applicativa può essere attivata da personale dell’Amministrazione diverso del Dirigente dei Servizi Informativi o dai suoi delegati.

I servizi di assistenza applicativa decorrono dal 1 gennaio 2015.

Tutte le attività di assistenza applicativa saranno svolte presso l’Amministrazione, così come precisato nell’art. 8 (Xxxxxx ed Orari di lavoro) o presso le sedi dell’Aggiudicatario.

Per le attività svolte presso le sedi dell’Aggiudicatario sarà cura dello stesso dotare le postazioni di lavoro del necessario corredo hardware e software. Il tipo di collegamento dovrà essere di tipo Vpn dedicata, il costo delle linee

di collegamento e di quanto necessario per la loro attivazione (ad. es. router…) sarà a carico del Fornitore così come gli orari e le modalità organizzative del lavoro.

Nei casi di carenza di documentazione l’attribuzione della tipologia di manutenzione sarà effettuata, di concerto con il Fornitore, secondo regole di correttezza, buona fede e ragionevolezza precisando , però, che l’onerosità della soluzione in alcun caso potrà essere considerata valido discrimine.

La documentazione tecnica relativa ai servizi di manutenzione adeguativa e evolutiva dovrà essere sviluppata con metodologia UML e comprenderà almeno i seguenti moduli:

• Use case diagram;

• Class Diagram

• Deployment diagram

• Interaction diagram (collaboration and sequence diagram).

Le modalità di erogazione dei servizi di assistenza applicativa richiesti sono indicate nella tabella seguente che fornisce una matrice di corrispondenza tra le tipologie di manutenzione richieste e le modalità di esecuzione previste e la valorizzazione contrattuale per la definizione del corrispettivo:

Tipo manutenzione	Metrica	Modalità di esecuzione	Modalità valorizzazione contrattuale	Sede
Correttiva	GP	Non progettuale	Continuativa a canone	Amministrazione/Fornitore
Adeguativa	GP	Progettuale	Continuativa a canone	Amministrazione/Fornitore
Evolutiva	GP	Progettuale	a consumo	Amministrazione/Fornitore

Le attività di assistenza applicativa saranno attivate con una richiesta formale di intervento inoltrate al Fornitore via telefono, fax, e-mail, portale Internet e rendicontate nelle modalità di seguito esplicitate per le varie tipologie di manutenzione. Il Fornitore predisporrà e comunicherà i relativi recapiti dedicati alla ricezione delle chiamate, indicando la modalità principale di ricezione delle richieste di assistenza.

11.1.3.1) Erogazione manutenzione correttiva

Il servizio di manutenzione correttiva, che viene normalmente attivato da uno specifico evento di malfunzione degli applicativi o rilevato dal personale tecnico dell’Amministrazione, deve essere erogato in modalità continuativa dalla richiesta formale di intervento, inviata al Fornitore dal Dirigente dei Servizi Informativi o suoi delegati, fino alla risoluzione della malfunzione stessa.

I tempi relativi alla manutenzione correttiva sono dati dalla sommatoria dei tempi di attivazione dei tecnici del Fornitore (dalla segnalazione della malfunzione) ed dei tempi per la risoluzione della malfunzione. Il calcolo del tempo di risoluzione della malfunzione decorre dalla data e dall’ora di ricezione della richiesta formale di intervento.

La richiesta formale di intervento dovrà indicare, tra l’altro, la categoria della malfunzione.

L’Amministrazione individua, al momento, le seguenti categorie di malfunzione:

🞏 Cat. 1 – livello gravità 1: è impedito l’uso dell’applicazione o di una o più funzioni o il funzionamento risulta non corretto;

🞏 Cat. 2 – livello gravità 2: è impedito l’uso di una funzione dell’applicazione in alcune specifiche condizioni (ad es. per alcuni dati di input, per alcuni utenti, ecc.);

🞏 Cat. 3 – livello gravità 3: è impedito l’uso della funzione, ma lo stesso risultato è ottenibile con altra modalità operativa ed i malfunzionamenti sono di tipo marginale;

🞏 Cat. 4 – livello gravità 4: malfunzione di tipo marginale non rientrante nelle precedenti categorie (ad. es. anomalie rilevate nella documentazione, nel dizionario dati, ecc..) .

Una diversa e più completa casistica di tipologie di malfunzione può essere proposta dal Fornitore in sede di offerta. L’Amministrazione si riserva la facoltà di accettare o meno la proposta del Fornitore.

Le attività a carico dell’Aggiudicatario per gli interventi di manutenzione correttiva sono:

1. Analisi delle cause della malfunzione, analisi dell’impatto della malfunzione sull’applicazione, specifica delle componenti (moduli/funzioni/……) da modificare, identificazione della soluzione, definizione della strategia di testing per la soluzione della malfunzione;

2. rimozione della malfunzione tramite gli opportuni interventi sull’applicativo nell’ambiente di sviluppo;

3. attività di test per la verifica del completo ripristino delle funzionalità dell’applicativo compromesse dalla malfunzione. Tale attività deve essere svolta congiuntamente con il personale tecnico dell’Amministrazione;

4. eventuale aggiornamento della documentazione.

Tutte le attività dei punti esposti dovranno essere formalizzate in un Rapporto di Malfunzione in cui si precisano altresì:

🞏 dati identificativi della richiesta formale di intervento;

🞏 data e ora di ricezione della richiesta formale di intervento;

🞏 richiedente;

🞏 relazione tecnica sulle cause e sulla risoluzione della malfunzione, la denominazione delle componenti software impattate, con documentazione dei risultati dei test di ripristino funzionalità eseguiti . Qualora l’intervento di manutenzione non comporti l’aggiornamento della documentazione, ne devono essere esplicitate le motivazioni;

🞏 nominativo del tecnico che ha eseguito l’intervento;

🞏 data ed ora della eventuale soluzione temporanea della malfunzione;

🞏 data ed ora della conclusione definitiva dell’intervento di manutenzione;

🞏 effort per l’intervento di manutenzione;

🞏 funzionario dell’Amministrazione che ha validato, previo verifica, l’intervento del Fornitore;

🞏 eventuale data ed ora dell’aggiornamento della documentazione;

🞏 eventuali variazioni del livello di qualità subite dal software a seguito dell'intervento.

Possono essere previste attività volte alla temporanea soluzione della malfunzione, in modo da assicurare l’erogazione dei servizi assicurati dall’applicativo e, nel contempo, approfondire le motivazioni della malfunzione rilevata, senza intaccare la produttività delle soluzioni. In questo il Fornitore renderà disponibile una soluzione temporanea, da utilizzare fino a quando il problema non sarà definitivamente risolto.

Dietro esplicito consenso del Dirigente dei Servizi Informativi o suo delegato, si potrà considerare ripristinata la funzionalità, anche temporaneamente, tramite l’adozione di bypass, workaround, purché sia assicurato il ripristino delle funzionalità principali e purché venga dato seguito immediato alla correzione definitiva (ad. es. alcune funzionalità degli applicativi possono essere attivate ed utilizzate tramite diversi accessi o transazioni). In caso di attivazione non immediata della correzione definitiva, l’intervento di manutenzione correttiva non sarà considerato chiuso.

L’eventuale aggiornamento della documentazione a corredo dell’applicativo deve essere trasmessa entro n. 2 giorni lavorativi successivi alla conclusione dell’intervento per le malfunzioni di gravità 1 e 2, entro n. 5 giorni lavorativi successivi alla conclusione dell’intervento per le malfunzioni di gravità 3.

11.1.3.2) Erogazione manutenzione adeguativa ed evolutiva

I servizi di manutenzione adeguativa ed evolutiva sono erogati in modalità progettuale ed ogni progetto è scomposto in obiettivi caratterizzati da una dimensione ed un tempo di esecuzione.

Gli obiettivi sono suddivisi in fasi, tipiche del ciclo di vita di un progetto software, delimitate da eventi (milestone), che rappresentano punti di controllo all’interno di ciascuna fase oppure punti di consegna dei deriverables previsti per la specifica fase.

Nella tabella seguente si riportano, in via indicativa, le fasi previste ed i principali prodotti attesi per un ciclo di sviluppo completo:

FASE	Milestone	Attore	Deliverables	Criterio di Uscita
	Richiesta Stima	Xxx.xx	Richiesta Formale al Fornitore di procedere alla stima dei tempi e dei costi per l'obiettivo.
DEFINIZIONE		Fornitore	Piano di Progetto dell’Obiettivo; Piano di Qualità dell’Obiettivo Stima dell’intervento (gg/persona); Specifiche requisiti.	Autorizzazione Attivazione dell’Obiettivo
	Attivazione	Xxx.xx	Lettera di autorizzazione al Fornitore in cui si approvano i prodotti della fase di definizione e si dà mandato allo stesso di attivare l'obiettivo secondo quanto previsto nell'offerta.
ANALISI		Fornitore	Analisi di dettaglio dei requisiti funzionali e non funzionali; Modello concettuale dei dati; Consolidamento della stima di revisione dell’intervento (gg/uomo); Piano di test funzionali e non funzionali; Eventuale prototipo.	Approvazione
	Approvazione	Xxx.xx	Verbale di approvazione dei documenti di analisi;
DISEGNO		Fornitore	Architettura della soluzione; Modello logico e fisico dei dati; Modello statico e dinamico delle componenti; Piano di test e collaudo; Piano delle attività di supporto alla fase di passaggio in produzione comprensiva della fase di addestramento degli utenti;	Approvazione
	Approvazione	Xxx.xx	Verbale di approvazione della documentazione relativa alla fase di Disegno.
REALIZZAZIONE		Fornitore	Codice sorgente/Release Package configurati; Lista oggetti software; Documentazione utente; Manuale di gestione server; Manuale di gestione applicativo; Esito casi di test prodotti dal fornitore; Rapporto indicatori di qualità; Piano di adeguamento degli ambienti; Codice di test e collaudo.
	Consegna	Fornitore	Xxxxxxx di consegna dei prodotti intermedi e/o finali.	Accettazione dei prodotti intermedi e finali
	Accettazione Prodotti	Xxx.xx	Verbale di accettazione finale dei prodotti e della documentazione ed autorizzazione al passaggio alla fase di collaudo
COLLAUDO		Xxx.xx Fornitore	Rendicontazione delle attività di test e collaudo; Verbale di collaudo;	Approvazione
	Approvazione	Xxx.xx	Approvazione del verbale di collaudo ed autorizzazione al passaggio in produzione;
PASSAGGIO IN PRODUZIONE		Fornitore Xxx.xx	Pubblicazione sul server di produzione del software rilasciato; Rendicontazione attività di supporto	Accettazione Obiettivo (Go live del servizio)
	Accettazione Obiettivo	Xxx.xx	Verbale di accettazione del software sviluppato e della documentazione prodotta.

L’intero processo è caratterizzato da due aspetti:

• Pianificazione

• Attuazione

La pianificazione è richiesta dal Dirigente dei Servizi Informativi o suo delegato con atto formale, nel quale viene esposta l’esigenza (obiettivo) da soddisfare, l’applicativo o gli applicativi coinvolti, gli ambienti tecnologici interessati ed il personale tecnico dell’Amministrazione coinvolto. Tale richiesta, in via indicativa ma non esclusiva, conterrà:

• la data di inizio attività (non oltre i 5 gg lavorativi dalla data dell’atto);

• la data limite richiesta per il completamento della fase di definizione;

• eventuali riferimenti alla documentazione esistente.

L’attuazione è subordinata all’approvazione dei documenti della fase di Definizione, a tal uopo l’Amministrazione si riserva la facoltà di valutare, con il personale tecnico interno o con Enti Terzi, la congruità della predetta valutazione, e la sua durata decorre dalla data dell’atto formale con cui il Dirigente dei Servizi Informativi o suo delegato autorizza il Fornitore ad attivare l’obiettivo secondo quanto previsto nell’offerta.

Pertanto per durata dell’obiettivo si definisce l’intervallo di tempo che decorre dalla milestone Attivazione a quella di

Accettazione dell’obiettivo.

Gli obiettivi non autorizzati dall’amministrazione non comporteranno alcun onere per quanto prodotto nella fase di

Definizione.

In fase di Definizione ed in funzione delle specifiche caratteristiche dello specifico obiettivo, il Fornitore e l’Amministrazione concorderanno l’opportuno ciclo di sviluppo da adottare tra quelli di seguito indicati:

• ciclo di sviluppo completo : modalità comunemente adottata per lo sviluppo di applicazioni ed interventi di manutenzione caratterizzati da dimensioni di rilievo in termini di effort progettuale ed i termini temporali;

• ciclo di sviluppo ridotto: prevede l’accorpamento di fasi (ad. es. analisi e disegno) e milestones nonchè deliverables semplificati. Tale ciclo può essere adottato per obiettivi di dimensioni limitate in termini di effort progettuale e termini temporali.

• ciclo a fase unica: si compone di una unica fase e si conclude con l’accettazione dell’intervento. La documentazione (in particolare aggiornamento manuale utente, manuale di gestione) potrà essere completata entro 10 gg. successivi alla consegna del software. Tale ciclo prevede un grado di flessibilità nell’organizzazione del Fornitore, allo scopo di garantire, in tempi brevi, la realizzazione dell’intervento.

A titolo esemplificativo sono indicati criteri oggettivi che possono orientare ad individuare il ciclo di sviluppo appropriato:

	Dimensioni in Giorni/Persona
DURATA		< 20	< 40	40 -100	>100
	< 15 gg	Unico	non applicabile	non applicabile	non applicabile
	15gg - 1 mese	ridotto	Ridotto	ridotto	non applicabile
	1 – 3 mesi	non applicabile	Ridotto	completo	completo
	>3 mesi	non applicabile	non applicabile	completo	completo

Il fornitore è tenuto presentare in sede di offerta e per ogni cicli di vita che sarà utilizzato per l’attività progettuale (completo, ridotto ed a fase unica), le fasi, i deliverables e le milestones.

Entro 10 giorni lavorativi dalla data di inizio delle attività, il Fornitore deve predisporre e consegnare la versione definitiva dei cicli di vita proposti, impegnandosi a recepire ogni ulteriori eventuale esigenze formalizzata dall’Amministrazione, per la definitiva approvazione degli stessi da parte di quest’ultima .

In ogni caso la calendarizzazione dell’obiettivo dovrà prevedere:

• l’inizio delle attività di attuazione del progetto entro un tempo massimo di n. 5 giorni lavorativi dalla data dell’atto formale con cui il Dirigente dei Servizi Informativi o suo delegato autorizza il Fornitore ad attivare l’obiettivo Informativi e prevedono l’impegno continuativo delle risorse impiegate dal Fornitore.

• La durata del Passaggio in produzione in un tempo massimo di mesi 2 (due) a decorrere dalla data di

Approvazione del verbale di collaudo ed autorizzazione al passaggio in produzione.

Qualora nella fase Passaggio in produzione si rendesse necessario l’intervento di figure professionali per un supporto specialistico e/o sistemistico per la configurazione del software di base e d’ambiente dell’infrastruttura tecnologica su cui insiste l’applicativo, sarà cura del Fornitore integrarlo nel gruppo di lavoro senza onere aggiuntivo per l’Amministrazione.

Le attività di collaudo e di eventuale formazione non saranno oggetto di quotazione né genereranno oneri aggiuntivi di alcun tipo per l’Amministrazione.

Eventuali attività di formazione per l’utenza finale saranno concordate, per ciò che riguarda le modalità ed i tempi, tra il Fornitore ed il Dirigente dei Servizi informativi o suo delegato.

La quantità e la tipologia delle malfunzioni rilevate durante il periodo di messa in esercizio costituiscono, tra gli altri, parametri per la valutazione della qualità del software.

Ciascun obiettivo commissionato dovrà prevedere, da parte del Fornitore, la nomina di un capo progetto.

Per la manutenzione evolutiva il costo totale indicato per l’obiettivo , salvo condizione di miglior favore offerta dal Fornitore, è dato dalla sommatoria dei costi delle singole fasi concordate. Il costo della singola fase risulterà dal prodotto dei giorni/persona delle figure professionali previste per le corrispondenti quotazioni unitarie indicate nell’offerta economica relativa alla presente Gara.

A tal fine si precisa che la stima iniziale dell’intervento deve essere effettuata con accuratezza in funzione degli elementi a disposizione, deve essere consolidata in sede di revisione quando tutti gli elementi di valutazione sono definiti e successivamente consuntivata ponendo come limite il 10% in più di quanto previsto in sede di revisione, indipendentemente dall’effettivo consumo di risorse a cui il Fornitore può andare incontro in corso d’opera. La stima dell’intervento risultante a consuntivo, sarà assunta come riferimento ai fini della fatturazione.

Solo in casi eccezionali, a seguito di eventi non prevedibili di forza maggiore, il limite del 10% in più rispetto alla stima di revisione potrà essere riconsiderato, previa approvazione dell’Amministrazione.

Si precisa altresì che l’Amministrazione potrà attivare uno o più obiettivi. Costituisce un onere del fornitore garantire le figure professionali occorrenti secondo gli skills di seguito indicati ed il capo progetto per ogni obiettivo. La serializzazione dei progetti non potrà mai essere accettata per l’impegno di una specifica risorsa in altri obiettivi.

In caso di cancellazione degli obiettivi per cause non imputabili al Fornitore e non motivate da eccezioni di mancato adempimento contrattuale da parte del Fornitore, verrà corrisposto allo stesso quanto dovuto in termini proporzionali al tempo ed alle figure professionali impiegate.

Ogni modifica di obiettivi al termine di altre fasi di lavoro, sarà concordata dall’Amministrazione e dal Fornitore e comporterà comunque la corresponsione al Fornitore di quanto dovuto in termini proporzionali al tempo ed alle figure professionali impiegate e la ridefinizione dell’obiettivo.

Tutta la documentazione prodotta dal Fornitore dovrà essere redatta prevedendo l’utilizzo di formalismi standard (ad. es UML, schema ER, logico, fisico…..).

Per le soluzioni software realizzate per l’interazione con i Sistemi Informativi di altre Amministrazioni, il Fornitore è tenuto al rispetto delle norme previste (ad. es. Dlgs. N.82 del 2005 e relative regole tecniche, Legge 9 gennaio 2004 sull’accessibilità dei siti web). A fronte di eventuali accertati casi di non conformità, il Fornitore è tenuto

all’adeguamento di quanto realizzato ai predetti standard, senza alcun onere aggiuntivo per l’Amministrazione.

Il Dirigente dei Servizi Informativi o suo delegato sarà responsabile del controllo della qualità di quanto prodotto dal Fornitore per lo specifico obiettivo, alla verifica del rispetto dei tempi ed, unitamente al capo progetto indicato dal Fornitore, alla gestione delle criticità che possano sorgere in sede di attuazione dell’obiettivo, attivando tutte le iniziative necessarie a governarle.

11.1.4) Figure professionali

Le figure professionali richieste per i servizi di assistenza applicativa sono:

• Capoprogetto sistemi informativi

• Analista Funzionale

• Analista Programmatore

Per essi il Fornitore dovrà fare riferimento ai profili di seguito descritti che specificano le esperienze professionali e le conoscenze tecniche minimali. Tali profili hanno valore indicativo ma non prescrittivo, in quanto l’Amministrazione si riserva la facoltà di accettare o meno una figura professionale proposta dal Fornitore anche sulla base delle effettive capacità.

Le certificazioni, le esperienze lavorative, le conoscenze indicate dal Fornitore per le figure professionali proposte per i servizi di assistenza applicativa richiesti nel presente capitolato tecnico, laddove non completamente esplicitate nei profili di seguito descritti, sono valutate come competenza core per l’esecuzione della fornitura solo se riferite alle componenti applicative di cui al presente capitolato.

Le conoscenze tecniche indicate nei profili non sono totalmente esaustive, in quanto, nel corso della fornitura, l’Amministrazione si riserva la facoltà di richiedere al Fornitore ulteriori competenze.

Per le figure professionali previste saranno ritenuti validi solo i titoli professionali rilasciati da organismi nazionali/Internazionali ufficialmente riconosciuti nell’ambito ICT e Università, Consorzi, Produttori di beni ICT, ottenuti tramite il superamento di un esame finale.

In sede di offerta il Fornitore potrà proporre ulteriori figure professionali.

CAPO PROGETTO
Titolo di Studio	Laurea in discipline tecniche – scientifiche
Certificazioni/Xxxxxx/ Abilitazioni	Certificazione PMI
Anzianità lavorativa	Minimo 12 anni, di cui almeno 5 anni di provata esperienza nella gestione di progetti di grandi dimensioni con più team cross-functional richiedenti definizione e applicazione di processi organizzativi complessi.
Esperienze Lavorative	• Sono apprezzate esperienze lavorative nella Pubblica Amministrazione Italiana; • Esperienze e competenze rilevanti per la definizione di strategie IT – con focalizzazione su obiettivi strategici e di disegno – e di un percorso di Informatizzazione innovativo e ad alto valore aggiunto; • Uso di tecniche e prodotti software per project management e risk management; • Controllo realizzazione procedure; • Stima di risorse per la realizzazione di progetto; • Redazione di documentazione di progetto; • Stima di tempi e pianificazione attività; • Analisi e progettazione di sistemi informativi, package, procedure complesse; • Responsabilità su gruppi di progetto;
Conoscenze	• Metodologie di sviluppo sw; • Normative Generali (qualità, sicurezza…) • Metodologie e Metriche per la misura progetti e dei relativi stati di avanzamento; • Redazione di specifiche di progetto; • Uso di tecniche e prodotti per project management e risk management; • Tematiche applicative gestionali in ambito Pubblica Amministrazione; • Tecnologie utilizzate nel progetto con particolare riferimento ad Oracle DB (release da 10 a 11g R2); • Analisi di processi; • Ottime capacità relazionali • Coordinamento di gruppi di lavoro; • Tecniche di controllo di progetto.

ANALISTA FUNZIONALE
Titolo di Studio	Laurea in discipline tecniche – scientifiche
Certificazioni/Xxxxxx/ Abilitazioni
Anzianità lavorativa	Minimo 8 anni, di cui almeno 3 nella funzione
Esperienze Lavorative	• Sono apprezzate esperienze lavorative nella Pubblica Amministrazione Italiana; • Redazione di specifiche di progetto; • Redazione di modelli dei processi; • Redazione di documentazione di progetto; • Controllo realizzazione procedure; • Stima di risorse per lo sviluppo software; • Stima di tempi e pianificazione attività; • Analisi requisiti utente; • Coordinamento di gruppi di lavoro; • Disegno e progettazione di test; • Sviluppo e Manutenzione progetti in ambiente Oracle Db.
Conoscenze	• Metodologie di analisi dei processi; • Metodologie di analisi e disegno di prodotti SW; • Metodologie di analisi e disegno dati; • Tecniche di controllo di progetto; • Tecniche di programmazione strutturata; • Tecniche di programmazione in ambiente web; • Tecniche di modellazione ed integrazione dati; • Strumenti di workflow management; • Tecniche di programmazione in ambiente Microsoft e Java; • Metodologie e tecniche per la gestione dei metadati; • Tematiche applicative gestionali in ambito Pubblica Amministrazione; • Metodologie di analisi e disegno Object Oriented con UML; • sistema di virtualizzazione Hyper-V Microsoft; • DBMS relazionali; • Metodologie e tecniche per il cleaning e la qualità dei dati • Ottime capacità relazionali.

ANALISTA PROGRAMMATORE
Titolo di Studio	Laurea in discipline tecniche – scientifiche
Certificazioni/Xxxxxx/ Abilitazioni
Anzianità lavorativa	Minimo 5 anni, di cui almeno 2 nella funzione
Esperienze Lavorative	• Verifica della corretta applicazione di metodi e standard; • Sviluppo di analisi tecnica di media complessità; • Realizzazione siti web accessibili (legge n.4 del 09/01/2004); • Documentazione procedure; • Preparazione di casi di test ed esecuzione di test; • Partecipazione a gruppi di progetto di medie/grandi dimensioni; • Programmazione strutturata in ambiente client-server, Web, SOA • Documentazione procedure; • Installazione e personalizzazione di sistemi anche complessi; • Progettazione ed integrazione di sistemi; • Tecnologie emergenti.
Conoscenze	• Metodologie di analisi e disegno di prodotti SW; • Strumenti di modellazione di dati; • Tecniche di programmazione Object oriented; • Conoscenza della metodologia UML; • Conoscenza dei s.o. Windows, Linux (Red Hat, Centos); • Ottima conoscenza dei linguaggi di programmazione: ASP, HTML/XTML/XML/javascript,pl/sql; • Tecniche di realizzazione di Web Services • Tecniche di programmazione in ambiente Web; • Tecniche di programmazione in ambiente J2EE, PHP e .NET; • DBMS Oracle,sql; • Strumenti per il cleaning e la qualità dei dati; • Ottime capacità relazionali.

11.1.5) Dimensionamento della fornitura per la manutenzione evolutiva

Per quanto attiene il dimensionamento della fornitura dei servizi richiesti nel presente CSA, relativamente alla Manutenzione Evolutiva, si riportano le quantità in giorni/persona che si intendono comprese nell’importo della procedura di gara di cui in oggetto, divise per area applicative e totali.

Le stesse potranno essere utilizzate solo su esplicita richiesta della Stazione Appaltante e sono da intendersi valide ed utilizzabili per tutta la durata contrattuale.

Area Servizi Demografici

FIGURA PROFESSIONALE	MASSIMALE GIORNI/UOMO
Capo Progetto	33
Analista Funzionale	66
Analista programmatore	166

Area Servizi Tributari

FIGURA PROFESSIONALE	MASSIMALE GIORNI/UOMO
Capo Progetto	34
Analista Funzionale	67
Analista programmatore	167

Area Servizi Finanziari

FIGURA PROFESSIONALE	MASSIMALE GIORNI/UOMO
Capo Progetto	33
Analista Funzionale	67
Analista programmatore	167

Totale

FIGURA PROFESSIONALE	MASSIMALE GIORNI/UOMO
Capo Progetto	100
Analista Funzionale	200
Analista programmatore	500

Nel caso in cui prima della fine contrattuale la Stazione Appaltante abbia esaurito tutta la disponibilità di giornate uomo per la manutenzione evolutiva l’Aggiudicatario si impegna ad erogare il servizio applicando le tariffe e per un massimo di giorno uomo definiti nella seguente tabella.

Area Servizi Demografici - Tariffe

FIGURA PROFESSIONALE	TARIFFA GIORNALIERA IN EURO	MASSIMALE GIORNI UOMO
Capo Progetto	500	150
Analista Funzionale	400	300
Analista programmatore	350	700

Area Servizi Tributari - Tariffe

FIGURA PROFESSIONALE	TARIFFA GIORNALIERA IN EURO	MASSIMALE GIORNI UOMO
Capo Progetto	500	150
Analista Funzionale	400	300
Analista programmatore	350	700

Area Servizi Finanziari - Tariffe

FIGURA PROFESSIONALE	TARIFFA GIORNALIERA IN EURO	MASSIMALE GIORNI UOMO
Capo Progetto	500	150
Analista Funzionale	400	300
Analista programmatore	350	700

Totale

FIGURA PROFESSIONALE	TARIFFA GIORNALIERA IN EURO	MASSIMALE GIORNI UOMO
Capo Progetto	500	450
Analista Funzionale	400	900
Analista programmatore	350	2100

I massimali di giorni uomo sono da intendersi applicati a tutta la durata contrattuale e non sono vincolanti per la SA che può decidere di non utilizzare o utilizzare in parte tale servizio aggiuntivo.

11.2) Manutenzione sistemistica

Tutte le attività riferite a tale area devono essere svolte dal personale tecnico del Fornitore congiuntamente al personale tecnico dell’Amministrazione all’uopo preposto e/o in modalità “training on the job”.

In ogni caso tali attività devono essere finalizzate al raggiungimento dell’autonomia operativa del personale tecnico dell’Amministrazione nella conduzione della Server Farm.

L’assistenza sistemistica deve essere finalizzata alla completa gestione dei sistemi (fisici e/o in ambiente virtualizzato) intesi ciascuno nel complesso della propria architettura funzionale e delle relative banche dati, alla prevenzione, al monitoraggio ed alla risoluzione di tutte le problematiche, nessuna esclusa.

Deve assicurare la continuità operativa ed il mantenimento ottimale delle performance di tutte le componenti l’infrastruttura IT (sistemi, sottosistemi, applicazioni e servizi) attraverso attività tecnico sistemistiche riguardanti il software di base, d’ambiente, virtualizzato, i database ed includendo, altresì, quelle attività che prevedono l’integrazione di prodotti di terze parti con componenti dei sistemi operativi.

Deve garantire la modularità, l’integrazione, l’isolabilità delle componenti, l’affidabilità, il bilanciamento del carico, la scalabilità e la sicurezza dell’intera architettura.

Di seguito si riporta, in via indicativa ma non esclusiva, un elenco di attività che dovranno essere assicurate:

Gestione sistemi:

🞏 la gestione operativa di tutte le risorse di elaborazione dei sistemi, considerate nel complesso di tutte le componenti;

🞏 attività volte al completo ripristino funzionale dei sistemi in caso di guasto e/o malfunzionamento (ripristino configurazioni, applicazioni, dati);

🞏 Attività volte a verificare e mantenere i requisiti definiti dall’Amministrazione in termini di sicurezza (fisica e logica) degli apparati e dei sistemi oggetto del servizio, anche con procedure atte a individuarne le vulnerabilità;

🞏 definizione di chiare e precise politiche di accesso ai sistemi. A tal proposito si precisa che qualsiasi sistema in gestione deve essere accessibile al personale tecnico dell’Amministrazione deputato al controllo del servizio/area. In assenza di suddetto personale, utenze di acceso dovranno essere rese disponibili al Dirigente del Servizio Autonomo Sistemi Informativi. L’utenza di accesso ai sistemi deve essere personale, laddove non lo fosse, qualsiasi cambio di utenza deve essere reso noto al personale tecnico dell’Amministrazione interessato;

🞏 adozione di procedure di gestione delle credenziali di autenticazione;

🞏 facilitare la comunicazione e la collaborazione con tutti gli attori tecnologici, sia interni al Comune di Napoli sia quelli con i quali l’Ente ha qualsiasi rapporto di collaborazione, per il supporto alla soluzione di tutti quei problemi che non richiedono l’intervento diretto presso i sistemi;

🞏 fornire tutte le informazioni necessarie per il corretto uso dei prodotti/sistemi;

🞏 gestione dei backup/restore dei dati di sistema, con adozione di procedure per la custodia di copie di sicurezza, il ripristino della disponibilità dei dati e dei sistemi;

🞏 creazione di ambienti di test;

🞏 definire, documentare e aggiornare protocolli di intervento per ogni procedura operativa di gestione, nessuna esclusa (ad. es. procedure di ripristino ovvero di escalation della operatività dei sistemi e dei servizi erogati, parametrate sulla criticità della condizione di malfunzione verificatasi). Le stesse devono essere validate dal responsabile del personale tecnico comunale;

🞏 creazione e gestione di un repository “Registro di schedulazione job” quale riferimento per l’esecuzione di tutte le attività di gestione con evidenza della presenza di vincoli (necessità di eseguire le attività in una sequenza predeterminata);

🞏 creazione e gestione di un repository “Registro di configurazione” per l’identificazione, la rintracciabilità ed il controllo degli apparati hw e sw coinvolti e della loro configurazione (Configuration Management) che consenta, tra l’altro:

• l’identificazione delle componenti hardware nell’ambito della configurazione di base (ad esempio: elaboratori, periferiche storage, collegamenti, periferiche di output, ecc.);

• attribuzione e tracciamento delle versioni del s.o. ed software di base e ambiente;

• tracciamento delle modifiche alla configurazione e alle sue singole componenti;

• produzione di rapporti e statistiche;

• audit delle configurazioni;

🞏 attività di monitoraggio dei sistemi :

• rilevazione di anomalie e malfunzioni in corrispondenza di eventi specifici che vengono segnalati sulle console di sistema e/o sulle console degli strumenti di monitoraggio centralizzato;

• rilevazione di superamento di soglie mediante opportuni indicatori rappresentativi del servizio erogato;

🞏 assistenza alla conduzione operativa in caso di necessità;

🞏 collaborazione con i responsabili delle applicazioni per la definizione di parametri ottimali di configurazione dei sistemi e dei sottosistemi tecnologici di supporto alle stesse;

🞏 creazione e gestione di un repository “Registro rapporto di malfunzione” per la rendicontazione degli interventi attivati a seguito di segnalazioni di malfunzioni che comportano interruzione o degrado nella fruizione dei servizi. In via indicativa ma non esclusiva, Il Rapporto di malfunzione deve comprendere:

o identificativo e descrizione della malfunzione;

o livello di gravità della malfunzione livello di gravità della malfunzione secondo criteri predefiniti (xx.xx.)

Livello di Gravità	Definizione
Livello 1 – bloccante	Il servizio erogato è non disponibile
Livello 2 – non bloccante	Degrado delle prestazioni del servizio erogato

o identificativo, descrizione e tipo del componente in errore;

o data e orario evento di malfunzione (rilevata xx.xx. da log, file di alert… etc)

o data e orario di rilevazione

o data e orario segnalazione della malfunzione;

o data e orario di inizio intervento del personale tecnico del Fornitore preposto alla risoluzione della malfunzione;

o data e orario di risoluzione della malfunzione;

o descrizione dell’intervento effettuato per risolvere della malfunzione;

o nominativo del tecnico che ha eseguito l’intervento;

o funzionario dell’Amministrazione che ha validato, previo verifica, l’intervento del Fornitore.

Attività di manutenzione proattiva, reattiva, evolutiva:

🞏 attività volte a prevenire tutte le problematiche che comportino interruzione o degrado del servizio all’utenza compreso gli aggiornamenti o adeguamenti del software di base e d’ambiente oppure modifiche correttive, adeguative, evolutive di applicazioni esistenti;

🞏 attività di manutenzione ordinaria dei sistemi eseguite con cadenza periodica anche a seguito di un’attività di monitoraggio continuativo dei file di log e di alert dei sistemi e delle applicazioni software;

🞏 attività finalizzate a garantire la disponibilità dei sistemi e dei collegamenti, ad individuare criticità e/o malfunzionamenti, ad intraprendere le azioni necessarie a garantire la corretta esecuzione delle attività schedulate in coerenza con i calendari di attività elaborative rivolte all’utenza, sia interna che esterna;

🞏 attività di tuning dei sistemi. Questa attività fa riferimento ai requisiti funzionali e prestazionali che devono essere rendicontati attraverso la creazione e la tenuta di un repository “Registro Rapporto sulle prestazioni”;

🞏 attività di manutenzione, a seguito di malfunzioni o guasti, volta a ridurre i tempi di fermo delle apparecchiature e dei sistemi(manutenzione correttiva);

🞏 attività volte al miglioramento delle prestazioni dei sistemi in termini di gestione dei picchi del carico elaborativo e di distribuzione del carico on-line e batch (job balancing), anche con modifiche architetturali hardware e software, e, comunque, volte a garantire l’efficienza dei sistemi rispetto all’utilizzo delle risorse (manutenzione evolutiva);

🞏 attività di analisi dei dati prestazionali e dei trend di crescita dei sistemi in esercizio;

Gestione ambienti di elaborazione

🞏 attività di installazione, configurazione, aggiornamento dei sistemi/sottosistemi middleware (Web server, Application server…), personalizzazioni necessarie alla loro integrazione;

🞏 garantire la disponibilità attraverso la distribuzione del carico sulle risorse utilizzate attraverso attività di analisi prestazionali degli ambienti con l’utilizzo di strumenti hardware e software specifici (load balancing device, etc. );

🞏 garantire la scalabilità, sia orizzontale che verticale, dei sistemi da gestire;

🞏 monitoraggio delle condizioni dei sottosistemi middleware (parametri di funzionamento e prestazionali). In via indicativa ma non esclusiva, si riassumono le principali categorie interessate:

o memoria RAM utilizzata dall’applicazione;

o tempi di risposta (il tempo di risposta è dato dalla somma del tempo di servizio e del tempo di attesa delle risorse necessarie);

o ammontare di lavoro del database (throughput), è l’ammontare di lavoro eseguito da un application server nell’unità di tempo. Un indicatore di throughput può essere il numero di transazioni al minuto effettuate, per esempio, in applicazioni J2EE;

o tempi di attesa, in particolare nel caso di contesa di risorse;

o larghezza di banda della rete utilizzata per collegare tra loro gli application server;

o numero di utenti concorrenti nell’unità di tempo;

🞏 amministrazione degli accessi;

🞏 rendicontazione periodica dell’utilizzo delle principali risorse hardware in uso degli applicativi al fine di una continua ottimizzazione delle risorse a disposizione della Server Farm;

🞏 stesura e messa in esercizio di procedure di gestione operativa, le stesse devono essere validate dal personale tecnico comunale in cogestione;

🞏 gestione del patching hardware, del software di base e del software di ambiente;

🞏 installazioni di procedure e programmi negli ambienti di esercizio;

🞏 fornire garanzie che siano identificati e segnalati tutti gli aspetti legali e contrattuali relativi all’introduzione di software di terze parti;

🞏 definire, documentare e aggiornare protocolli di intervento per ogni procedura operativa, nessuna esclusa, le stesse devono essere validate dal personale tecnico comunale in cogestione per la specifica attività;

Gestione dello Storage (Management infrastrutture DISK/SAN )

🞏 pianificazione, gestione (inizializzazione, smontaggio, ricollocazione), controllo e reportistica dello storage (dischi e/nastri) sia di esercizio che dedicati ai backup;

🞏 i valori di occupazione dello spazio fisico ed il loro uso effettivo devono essere misurati e confrontati con valori di riferimento;

🞏 gestione delle politiche dei salvataggi delle varie tipologie di backup, anche applicativi, sulle librerie robotizzate, verifiche sulla leggibilità dei dati, sulla loro obsolescenza con eventuale recupero di supporti danneggiati;

🞏 riorganizzazione, ottimizzazione, bonifica degli archivi;

🞏 definire, documentare e aggiornare protocolli di intervento per ogni procedura operativa, le stesse devono essere validate dal personale tecnico comunale in cogestione per la specifica attività ;

Gestione banche dati

🞏 installazione e configurazione dei database;

🞏 migrazione ed ottimizzazione banche dati oracle in ambiente Oracle RAC;

• gestione delle strutture logiche di memorizzazione (tablespaces,segments,….) ;

• gestione delle strutture fisiche di memorizzazione (datafile con distribuzione tablespaces per datafile, redo log files, control files, archived redo log files);

• gestione delle strutture logiche del database (tabelle, indici,constraints, viste, users, schemi, dblink….);

🞏 predisposizione di procedure per il controllo, la sicurezza, l’auditing dei database, con particolare riferimento alla gestione (autenticazione, autorizzazioni, accounting) degli utenti del database;

🞏 predisposizione e/o ottimizzazione degli script gestionali per le procedure di backup e restore con l’ausilio del tool Oracle Recovery Manager ed armonizzazione delle stesse politiche con quelle di salvataggio su sistemi NAS, librerie a nastro o quant’altro in dotazione all’Amministrazione;

🞏 attività di test sui restore delle banche dati (almeno due volte all’anno)

🞏 interventi di adeguamento sulle strutture logiche dei database e sui parametri di configurazione;

🞏 procedure da attivare in caso di failure del database o di qualche sua componente, con particolare riferimento:

🞏 guasto da supporto fisico (perdita control files, redo log, datafiles);

🞏 guasto da utente (cancellazione accidentali oggetti logici);

• supporto all’attività di ottimizzazione del codice in ragione di analisi prestazionali sugli applicativi;

• gestione della scalabilità dei database, ovvero sulla capacità di adeguare le funzionalità di storage e di ricerca dei dati alle risorse hardware e software disponibili;

🞏 monitoraggio e tuning dei database mediante l’utilizzo degli strumenti messi a disposizione dal RDBMS o eventuali script, con relativa gestione degli alert. L’attività di tuning dovrà essere parametrizzata su configurazioni hardware ottimali e riguardare, in via indicativa ma non esaustiva, i seguenti aspetti:

o tempi di risposta per un subset generico di operazioni delle procedure “online”;

o ammontare di lavoro del database (throughput) nell’unità di tempo;

o tempi di attesa, in particolare nel caso di contesa di risorse (oggetti del database, file di database, ecc.);

o numero di utenti concorrenti nell’unità di tempo;

o numero di transazioni ultimate nell’unità di tempo;

o andamento nel tempo della dimensione della base dati;

o memoria RAM utilizzata da tutte le componenti dell’applicativo (application server, database[SGA/PGA], etc…)

o “dimensione fisica dei dati / unità di tempo” (Gb/s) per il caricamento massivo dei dati tramite batch

o tempi attesi per elaborazioni massive.

Dopo aver rappresentato, in via indicativa ma non esclusiva, il set minimale delle attività che il Fornitore deve assicurare, si precisa che lo stesso dovrà produrre, come parte integrante dell’offerta tecnica:

a) una versione preliminare del Piano delle attività da espletare nel primo anno di attività di assistenza sistemistica continuativa, contenente in via indicativa ma non esclusiva, la descrizione dettagliata delle singole attività, le risorse utilizzate ,tempificazioni a livello di milestone e comprensiva del relativo diagramma di Gantt.

Entro 10 giorni lavorativi dalla data di inizio attività, il Fornitore dovrà predisporre e consegnare la versione definitiva del piano medesimo, che dovrà recepire ogni ulteriori eventuale esigenze formalizzata dall’Amministrazione, per la definitiva approvazione da parte di quest’ultima;

b) il sistema informatico integrato, preferibilmente definito con tecnologie di tipo open source, che il Fornitore intende fornire all’Amministrazione entro tre mesi dalla data di inizio attività (o entro il termine previsto nell’offerta tecnica, se migliorativo) quale “Stazione di Gestione, Monitoraggio e Controllo” che integri i repository “ Registro di schedulazione job”, ” Registro di configurazione”, “Registro rapporto di malfunzione”, “Registro Rapporto sulle prestazioni”, che consenta la gestione delle richieste di intervento di assistenza sistemistica (par. 11.2.1 ) e che preveda altresì un sistema di pubblicazione contenente, in via indicativa ma non esclusiva, le seguenti funzionalità di base:

• presentazione dei dati anche in modalità Web Based (per motivi di sicurezza tutti i dati trattati dovranno essere ospitati all’interno della intranet dell’Amministrazione);

• gestione della sicurezza (accesso, dati);

• gestione dei diversi profili utenti (management, amministratore di sistema, livello operativo);

• consultazione di script/protocolli di procedure operative.

Allo scadere del contratto Il sistema informatico integrato di cui al punto b), unitamente alla infrastruttura tecnologica di supporto al sistema ed alle licenze d’uso del software offerto, rimarrà di proprietà dell’Amministrazione.

Gli standard e le norme tecniche di riferimento applicabili all’Area Gestioni Sistemi e Banche dati sono:

🞏 UNI EN ISO 9001:2008 Sistema di gestione per la qualità – Requisiti

🞏 UNI EN ISO 9004:2009 Sistemi di gestione per la qualità – Linee guida per il miglioramento delle prestazioni

🞏 CEI EN 60300-1:2003 Gestione della fidatezza – Parte 1: Sistemi di gestione della fidatezza

🞏 IEC 60300-2:2004 Gestione della fidatezza – Parte 2: Linee guida per la gestione della fidatezza

🞏 UNI EN ISO 10007:2006 Guida per la gestione della configurazione o versioni vigenti alla data.

Il software di base e d’ambiente presente presso la Server Farm, oggetto della richiesta di assistenza sistemistica del presente CSA, potrà subire variazioni per quanto riguarda le quantità e la tipologia.

L’erogazione dei servizi per l’Area Gestione Sistemi e Banche dovrà essere assicurata dal Fornitore e non determinerà variazioni degli importi contrattuali anche a seguito dell’introduzione di nuove versioni e/o release del software di base e d’ambiente attualmente presente. L’Aggiudicatario dovrà assicurare l’aggiornamento professionale del proprio personale tecnico senza alcun onere aggiuntivo per l’Amministrazione.

11.2.1) MODALITA’ DI EROGAZIONE DEI SERVIZI DI ASSISTENZA SISTEMISTICA

L’erogazione dei servizi di assistenza sistemistica per l’Area Gestione Sistemi e Banche Dati prevede due modalità valorizzazione contrattuale per la definizione del corrispettivo:

A. continuativa a canone: il corrispettivo è fisso a fronte delle prestazione delle specifiche figure professionali richieste nel presente capitolato tecnico e che devono costituire il nucleo di cui al Presidio (art. 11.2.2);

B. a consumo : il corrispettivo è determinato, a consuntivo, dalla sommatoria dei prodotti delle quotazioni delle figure professionali, così come specificate nell’offerta economica relativa alla presente Gara, per il numero di giorni impiegati per l’erogazione dello specifico intervento di assistenza sistemistica, laddove il numero di giorni deve essere scalato da una disponibilità di budget predefinita.

I servizi di assistenza sistemistica, da erogare nel primo anno della fornitura a decorrere dal 1 gennaio 2015, saranno erogati in modalità continuativa a canone dal personale tecnico del Fornitore e costituiranno un Presidio presso la Server Farm dell’Amministrazione.

Per tale Xxxxxxxx sono previste le seguenti figure professionali:

□ Sistemista senior,

□ Data base administrator.

Tali servizi dovranno essere prestati nell’orario di servizio dell’Amministrazione nella fascia oraria dalle ore 8.00 alle ore 17.00 nei giorni lavorativi dal lunedì al venerdì. Le modalità di fruizione della pausa pranzo dovranno essere tali da garantire comunque la presenza continuativa del personale tecnico dell’Aggiudicatario.

Per particolari esigenze operative l’Amministrazione potrà richiedere un prolungamento dell’ orario di lavoro oltre le ore 17.00 e fino alle ore 19.42.

Tale prolungamento di orario potrà essere compensato nelle modalità (posticipo orario di ingresso/anticipo orario di uscita) e nei tempi concordati con l’Amministrazione e dalla stessa autorizzati.

L’Aggiudicatario, dovrà garantire la continuità dei servizi oggetto dell’appalto nei giorni e negli orari indicati anche in caso di sciopero e/o agitazione sindacali.

A copertura dei giorni e degli orari non compresi nel presente paragrafo e quelli non compresi nel paragrafo 1.4.2 per l’attività di assistenza sistemistica a chiamata (anni successivi al primo), il Fornitore dovrà assicurare il servizio di reperibilità come di seguito specificato.

L’Aggiudicatario dovrà specificare nell’offerta tecnica le modalità tecniche ed organizzative con le quali intende assicurare all’Amministrazione, per tutta la durata contrattuale, il servizio di reperibilità delle figure professionali di a) Sistemista senior, b) Data base administrator, incaricate di intervenire in casi di emergenza nei giorni e negli orari non compresi nell’attività di Presidio e/o nel art. 8 (Luoghi ed Orari di lavoro).

La copertura del servizio dovrà essere assicurata 24 ore al giorno e gli interventi potranno essere attivati anche con sistemi di chiamata automatica.

Gli interventi potranno essere forniti:

• On site

• Da remoto

In ogni caso dovranno essere chiaramente indicati, per ciascuna delle due modalità, i tempi di intervento.

Per le attività svolte da remoto sarà cura del Fornitore dotare le postazioni di lavoro del necessario corredo hardware e software. Il tipo di collegamento dovrà essere di tipo Vpn dedicata, il costo delle linee di collegamento e di quanto necessario per la loro attivazione (ad. es. router…) sarà a carico del Fornitore.

Tanto premesso tutte le attività di assistenza sistemistica da erogare nel corso del primo anno a decorrere dal 1 gennaio 2015 (assistenza sistemistica continuativa) e di cui al Piano delle Attività (art. 15) devono essere rendicontate in un “Rapporto di Attività/Intervento” firmato dal tecnico dell’Aggiudicatario di cui al Presidio e controfirmato dal Funzionario dell’Amministrazione all’uopo designato;

All’atto della messa in esercizio della “Stazione di Gestione, Monitoraggio e Controllo” le informazioni contenute nei “Rapporto di Attività/Intervento” , incluse quelle relative ai mesi precedenti, dovranno alimentare i repository della “Stazione di Gestione, Monitoraggio e Controllo”.

Le attività di assistenza sistemistica a seguito di malfunzionamento, nel corso del primo anno a decorrere dal 1 gennaio 2015 (assistenza sistemistica continuativa), saranno attivate con una richiesta formale di intervento consegnata dal Funzionario dell’Amministrazione, all’uopo delegato, al personale tecnico del Fornitore di cui al Presidio e rendicontate in un “Rapporto di malfunzione” firmato dal tecnico del Fornitore di cui al Presidio e controfirmato dal Funzionario dell’Amministrazione.

Nel primo anno di assistenza sistemistica (assistenza sistemistica continuativa) i tempi di risoluzione della malfunzione decorrono dalla data e dall’orario di consegna della richiesta formale di intervento al personale tecnico del Fornitore di cui al Presidio. Tale data e orario dovrà essere riportata altresì nel Rapporto di Malfunzione come data e orario di segnalazione della malfunzione (data e orario della richiesta formale di intervento = data e orario di segnalazione della malfunzione).

All’atto della messa in esercizio della “Stazione di Gestione, Monitoraggio e Controllo” le informazioni contenute nelle richieste di intervento e nei “Rapporto di Malfunzione” , incluse quelle relative ai mesi precedenti, dovranno essere inserite e gestite nella “Stazione di Gestione, Monitoraggio e Controllo”. I tempi di segnalazione della malfunzioni e quelli associati di risoluzione dovranno essere posti altresì in formato elettronico che ne consenta successive elaborazioni.

Al fine di evitare gravi disservizi, laddove ricorrano motivi di urgenza e si verifichi la momentanea non reperibilità del personale tecnico dell’Amministrazione, il personale tecnico del Fornitore deve attivarsi indipendente dalla richiesta formale di intervento e comunque rendicontarla.

Per gli anni successivi al primo (assistenza sistemistica a chiamata) i servizi di assistenza sistemistica non derivanti da malfunzioni, saranno attivati da formale richiesta del Dirigente del Servizio Sistemi Informativi al Referente Tecnico del Fornitore che dovrà produrre entro e non oltre 10 (dieci) giorni dalla richiesta un Piano delle Attività per lo specifico intervento. Il Piano delle Attività, in cui saranno indicate , tra l’altro, la calendarizzazione delle attività da esplicare con tempificazione a livello di milestone e le figure professionali occorrenti, dovrà prevedere l’inizio delle attività entro un tempo massimo di n. 3 giorni lavorativi dalla data di approvazione di tale piano da parte del Dirigente del Servizio Sistemi Informativi o suo delegato. L’ attivazione dell’intervento avverrà con una richiesta formale di intervento inoltrata al Fornitore via telefono, fax, e-mail, portale Internet e dovrà essere rendicontato in un “Rapporto di Attività/Intervento” firmato dal tecnico indicato dal Fornitore e controfirmato dal Funzionario dell’Amministrazione all’uopo designato ed alimenterà i repository della “Stazione di Gestione, Monitoraggio e controllo”. Il Fornitore predisporrà e comunicherà i relativi recapiti dedicati alla ricezione delle richieste di assistenza sistemistica, indicando la modalità principale di ricezione delle stesse.

Le attività di assistenza sistemistica a seguito di malfunzione, nel corso degli anni successivi al primo (assistenza sistemistica a canone), saranno attivate con una richiesta formale di intervento inviata dal Funzionario dell’Amministrazione, all’uopo delegato, con le modalità indicate dal Fornitore per la ricezione delle richieste nel paragrafo precedente.

Nel corso degli anni successivi al primo (assistenza sistemistica a canone) i tempi di risoluzione del malfunzionamento decorrono dalla data e dall’orario della richiesta formale di intervento. La data e l’orario della richiesta formale di intervento = data e orario di segnalazione della malfunzione inviata dal Fornitore dovranno essere riportate nel “Rapporto di Malfunzione” che rendiconterà l’intervento effettuato e dovrà essere firmato dal tecnico del Fornitore di cui al Presidio (riferimento paragrafo) e controfirmato dal Funzionario dell’Amministrazione.

Le informazioni contenute nelle richieste di intervento e nel “Rapporto di Malfunzione” dovranno essere inserite e gestite nella “Stazione di Gestione,Monitoraggio e Controllo”.

A partire dal terzo mese dalla data di inizio delle attività e per tutta la durata del contratto, Il Fornitore, con la “Stazione di Gestione, Monitoraggio e Controllo”, deve garantire che la gestione delle richieste di intervento consenta di tracciare il percorso risolutivo (trouble ticketing) degli interventi stessi e deve fornire all’Amministrazione strumenti di reportistica, di supervisione e controllo del livello dei servizi erogati all’utenza e di controllo e verifica del corretto rispetto ed applicazione degli obblighi contrattuali assunti dalla Fornitore.

11.2.2 Figure Professionali Richieste

Le figure professionali richieste per i servizi di assistenza sistemistica sono:

• Sistemista multipiattaforma con seniority su sistemi e ambienti di elaborazione (sistemista senior);

• Data base administrator

e per essi l’Aggiudicatario dovrà fare riferimento ai profili di seguito descritti che specificano le esperienze professionali e le conoscenze tecniche minimali. Tali profili hanno valore indicativo ma non prescrittivo, in quanto l’Amministrazione si riserva la facoltà di accettare o meno una figura professionale proposta dal Fornitore anche sulla base delle effettive capacità.

Le certificazioni, le esperienze lavorative, le conoscenze indicate dal Fornitore per le figure professionali proposte per i servizi di assistenza sistemistica richiesti nel presente capitolato tecnico, laddove non completamente esplicitate nei profili di seguito descritti, sono valutate come competenza core per l’esecuzione della fornitura solo se riferite alle componenti dell’infrastruttura IT della Server Farm del Comune di Napoli.

Le conoscenze tecniche indicate nei profili non sono totalmente esaustive, in quanto, nel corso della fornitura, l’Amministrazione si riserva la facoltà di richiedere al Fornitore competenze specifiche per ulteriori prodotti, sistemi, tecnologie, metodologie.

Per le figure professionali previste saranno ritenuti validi solo i titoli professionali rilasciati da organismi nazionali/Internazionali ufficialmente riconosciuti nell’ambito ICT e Università, Consorzi, Produttori di beni ICT, ottenuti tramite il superamento di un esame finale. In sede di offerta il Fornitore potrà proporre ulteriori figure professionali.

SISTEMISTA SENIOR
Titolo di Studio	Laurea in discipline tecniche – scientifiche. In caso di mancanza della laurea indicata , è richiesta una anzianità lavorativa di 13 anni, di cui almeno 8 nel ruolo di sistemista.
Anzianità lavorativa	Minimo 10 anni, di cui 5 nel ruolo
Esperienze Lavorative	✓ Installazione, personalizzazione, tuning e troubleshooting di server e client in ambienti Microsoft, Red Hat, Centos e Linux; ✓ Esperienza specialistica su tecnologie e prodotti di SAN e back-up; ✓ Attività di installazione, configurazione ed update del software, sia di s.o. che di altri prodotti di infrastruttura tecnologica; ✓ Tuning ed ottimizzazione della configurazione dei sistemi per garantirne la massima efficienza (utilizzo della cpu, memoria,I/O dischi e spazio); ✓ Configurazione/ gestione di sottosistema dischi ed integrazione in ambiente SAN; ✓ Stesura di documenti tecnici ed operativi; ✓ Progettazione test integrati; ✓ Architetture dei sistemi software, dei sistemi operativi, di DBMS, di applicazioni web, di prodotti e tecnologie HW/SW presenti sul mercato; ✓ Problem solving operativo, di orientamento al risultato, di coordinamento di gruppi di lavoro e di integrazione in gruppi compositi; ✓ Assistenza di tipo specialistico sull’utilizzo dei sistemi e sui prodotti e/o programmi di ausilio al sistema operativo; ✓ E’ titolo preferenziale l’esperienza con tale qualifica in progetti di sale operative complesse.
Conoscenze	✓ Configurazioni cluster Oracle Rac o soluzioni di clusterizzazioni differente o riferita ad altro rdbms; Configurazioni di infrastruttura di Storage e sistemi di backup; ✓ Conoscenza Sistemi Operativi Windows Server 2003,2008,2012, Red Hat 5.8, Centos 6,2; ✓ Linguaggi: C - C++ ; ✓ Sistema di virtualizzazione Hyper-V; ✓ Conoscenze specialistiche delle applicazioni enterprise conformi agli standard Java; ✓ Skill specifico nella gestione, configurazione e tuning di Application Server; ✓ Progettazione di dettaglio e conduzione di sistemi operativi complessi o di rete, assicurando il loro aggiornamento periodico; ✓ Ottimizzazione, gestione e tuning delle risorse hardware; ✓ Integrità, riservatezza ed affidabilità dei sistemi informativi ✓ Configurazione e gestione apparecchiature HW Enclosure, Server blade, Server tradizionali e Storage, Tape Library (Veritas Netbackup); ✓ Realizzazione di programmi che interfacciano il sistema operativo di base e/o la sua estensione partecipando all’installazione, configurazione, personalizzazione delle componenti software e hardware di base, di ambiente; ✓ Gestione della configurazione hardware e software di base, tecniche di controllo dello stato delle basi dati, utilizzo di strumenti e modalità per assicurare la loro efficienza e protezione; ✓ Metodologie di verifica funzionale e di benchmarking prestazionali, da applicare a nuovi prodotti e tecnologie, delle problematiche di sicurezza dati e protezione archivi; ✓ Metodologie e tecniche relative alla sicurezza informatica; ✓ Personalizzazione e configurazione delle componenti di back office; ✓ Configurazione e gestione servizi Wins, DHCP, DNS; ✓ Configurazione e gestione piattaforme e sistemi Microsoft Microsoft Server 2003, 2007 e 2010, Red Hat, Centos; ✓ Conoscenza approfondita delle tecniche di eliminazione delle vulnerabilità dei sistemi ✓ Conoscenze di piattaforme Open Source ✓ Piattaforme di monitoraggio ✓ Conoscenza di: Protocolli di rete, Architettura di rete TCP/IP, Protocolli di routing, Sistemi di network management. ✓ Shell scripting.

DBA2
Titolo di Studio	Laurea in discipline tecniche – scientifiche
Certificazioni/Titoli/ Abilitazioni	Certificazione PMI, sono particolarmente apprezzate certificazioni (OCA,OCP) Oracle DBA ,O RAC, Oracle Performance and Tuning.
Anzianità lavorativa	Minimo 6 anni, di cui almeno 4 nella funzione
Esperienze Lavorative	• esperienza lavorativa nella specifica funzione di DBA Oracle per la gestione di sistemi informatici complessi anche in ambiente Oracle RAC; • Installazione,configurazione e gestione Oracle database 10g e 11g; • politiche di backup e restore con RMAN, gestione delle performance e del Tuning di sistemi informatici complessi
Conoscenze	• Conoscenza Sistemi Operativi Windows Server 2003,2008,2012, Red Hat 5.8, Centos 6,2; • Real Application Clusters Administration; • Grid Infrastructure; • Oracle Data Guard; • Clusterware and ASM • Enterprise Manager Administration; • Enterprise performance Management; • Database Architecture, Management,Security and Auditing; • Performance and tuning base database Oracle; • Physical and Logical Backup and recovery; • Sql Tuning; • Sql e Pl/sql; • Application servers e Insfrastructure;

11.2.3) Dimensionamento della manutenzione sistemistica

Per quanto attiene il dimensionamento della fornitura dei servizi richiesti nel presente capitolato tecnico per l’Area Gestione Sistemi e Banche Dati, le due tabelle, di seguito fornite, sintetizzano le modalità di valorizzazione contrattuale e le quantità relative alle figure professionali richieste3:

• la tab. a) riporta, per anno di fornitura e per figura professionale, la modalità di valorizzazione contrattuale per la definizione del corrispettivo;

• la tab. b) riporta, per anno di fornitura e per figura professionale, il numero di giorni/persona richiesti e che costituiscono la disponibilità di budget minimo, predefinito, al meglio delle conoscenze attuali. Per le figure professionali in cui il numero di giorni non è specificato (nell’apposita cella è indicato CC), si intende modalità di erogazione continuativa a canone :

2 Relativamente a tale figura professionale, le certificazioni/titoli/abilitazioni, esperienze lavorative, conoscenze sono chiaramente riferite ad un DBA Oracle essendo tale rdbms prevalentemente in uso presso la Server Farm. Qualora il/i fornitori intendano utilizzare qualunque altro rdbms, i requisiti richiesti devono essere riferiti a quest’ultimo. In particolare sono richieste conoscenze e certificazioni relative ai seguenti aspetti: installation, configuration e administration, monitoring, auditing e security, backup e recovery, performance e tuning, cluster configuration e administration, high-availability

3 I dati della tabella b) vanno concordati necessariamente con la Server Farm

PROFILO di COMPETENZA	1° anno	2° anno	3° anno	4° anno	5° anno	6° anno
Sistemista multipiattaforma con seniority su sistemi e ambienti di elaborazione	Continuativa a canone	Consumo	Consumo	Consumo	Consumo	Consumo
Data base administrator	Continuativa a canone	Consumo	Consumo	Consumo	Consumo	Consumo

Tabella A

PROFILO di COMPETENZA	1° anno	2° anno	3° anno	4° anno	5° anno	6°anno
Sistemista multipiattaforma con seniority su sistemi e ambienti di elaborazione	CC	30	20	20	10	10
Data base administrator	CC	30	20	20	10	10

Tabella B

Si precisa che per le figure professionali e per tutti gli anni ad eccezione dell’ultimo in cui è prevista la modalità valorizzazione contrattuale a consumo4:

• qualora il numero di giorni effettivamente utilizzati entro il 31 dicembre dell’anno preso in considerazione non esaurisca la disponibilità di budget definita per l’anno stesso, L’Amministrazione si riserva la facoltà di utilizzare il numero residuale di giorni nel corso dell’anno successivo a quello considerato ed alle stesse condizioni previste nell’offerta del Fornitore. Tali giorni si sommeranno alla disponibilità di budget previsto per l’anno successivo a quello considerato (ad es. figura professionale: Data base administrator, anno considerato 2°, giorni/persona previsti a budget n.30 (trenta), giorni effettivamente utilizzati al 31 dicembre del secondo anno: n. 20 (venti), ne consegue che per la medesima figura professionale nel xxxxx xxx 0x xxxx xx xxxxxxxxx (xxxx successivo a quello considerato), il numero di giorni utilizzabili a partire dal 01 gennaio del terzo anno sarà aumentato di n.10 (dieci) giorni;

• variazioni in aumento del numero di giorni utilizzati nel corso di un anno della fornitura per una specifica figura professionale, non determinano alcun aumento di spesa, ma trovano compensazione in corrispondenti variazioni in diminuzione dei giorni utilizzabili per la stessa figura professionale per l’anno successivo a quello considerato, entro il limite del 30% dei giorni previsti per la medesima figura professionale quale budget per l’anno successivo oppure saranno compensate da equivalenti (in termini temporali ed economici) variazioni in diminuzione di altre figure professionali previste per la specifica area

1.3) FORMAZIONE

11.3.1) Aspetti Generali

Oggetto di fornitura del presente capitolato è anche l’erogazione dei servizi professionali di formazione e addestramento del personale del Comune all’uso delle nuove soluzioni introdotte con l’infrastruttura tecnologica e la piattaforma applicativa previste in fornitura.

La formazione si concluderà entro i primi sei mesi dall’inizio dalla data di collaudo positivo previa relazione di ogni responsabile di servizio sul raggiungimento degli obiettivi del corso; nel caso in cui gli obiettivi non fossero raggiunti saranno richiesti compresi nel prezzo ulteriori giorni formativi fino al raggiungimento di un ottimale livello di autonomia lavorativa da parte dell’impiegato addetto.

Il fornitore deve indicare i ruoli e le responsabilità delle figure professionali coinvolte nelle varie fasi realizzazione del servizio; i relativi profili di competenza dovranno essere attestati tramite un curriculum standard predefinito;

4 La fattibilità di attuazione dei punti di seguito esposti necessita di verifica amministrativa/finanziaria

Nel caso che la fornitura del servizio venga effettuata da ATI (Associazione Temporanea d’Impresa) o RTI (Raggruppamento Temporaneo d’Impresa) devono essere chiaramente definite le responsabilità delle singole società nelle varie fasi in cui si articola il servizio.

Di seguito si elencano i requisiti minimi organizzativi e metodologici, cui il Fornitore dovrà attenersi nell’erogazione dei predetti servizi formativi:

11.3.2) Corso per Operatori

11.3.2.1) Obiettivi e Contenuti Formativi

I corsi di formazione - espressamente rivolti al personale del Comune interessato all’utilizzo della piattaforma applicativa per le aree funzionali dell’area Demografica, Tributi, Bilancio e Toponomastica del Comune di Napoli dovranno essere finalizzati al trasferimento all’utenza target delle abilità e delle competenze necessarie per l’accesso e l’uso di tutte le funzionalità messe a disposizione dalla nuova piattaforma applicativa. I corsi dovranno essere erogati in base ad un piano di formazione proposto dall’Aggiudicatario in base alle esigenze della Stazione Appaltante. Tale piano di formazione deve essere accettato dalla Stazione Appaltante.

A scopo meramente indicativo e non esaustivo, durante il corso dovranno essere trattati i seguenti argomenti:

• accesso all’applicazione, interfaccia utente e modalità d’interazione, navigazione nei menù, accesso agli help e alla documentazione in linea, ecc. ;

• attivazione delle funzionalità, immissione, controllo e validazione dei dati, funzioni di ricerca, interrogazione, visualizzazione e stampa, chiusure periodiche, ecc. accesso alla documentazione tecnica e alla manualistica di riferimento;

• parametrizzazioni, sviluppo di report personalizzati, produzione di stampe massive, ecc.;

• funzionalità di import/export, di interoperabilità e interscambio con prodotti di office automation

11.3.2.2) Modalità di Erogazione

I corsi dovranno essere organizzati distintamente per ciascuna delle aree funzionali e, in relazione al numero dei partecipanti, pianificati e tenuti in più edizioni. Le modalità di erogazione dovranno prevedere:

• sessioni teoriche frontali in aula indicata ed appositamente allestita dal Comune, con un numero massimo di partecipanti per ciascuna edizione non superiore alle 20 unità;

• sessioni pratico‐applicative, da svolgere con le modalità tipiche del “training on the job”, affiancando direttamente sul posto di lavoro un gruppo di utenti, funzionalmente omogeneo;

• moduli formativi, FAQ, tutoriali ed un dettagliato manuale utente (tutto in lingua italiana) fruibili in modalità e-Learning.

In particolare, come requisito minimo, si richiede che si tengano:

• n. 3 giornate formative in aula per gli utenti individuati;

• n. 5 giornate di affiancamento per gli utenti individuati;

11.3.2.3) Utenza target

Si prevede un numero indicativo di utenti da formare pari a 240 dipendenti così divisi tra le varie aree:

• area servizi demografici: 80

• area tributi: 80

• area servizi finanziari: 80

I corsi dovranno essere erogati negli uffici in cui svolgono regolare servizio i dipendenti delle aree sopra elencate.

11.3.3) Corso Amministratori di sistema

11.3.3.1) Contenuti e Obiettivi Formativi

I corsi di formazione ed addestramento - espressamente rivolti al personale dipendente addetto alla gestione e conduzione dell’infrastruttura tecnologica e della piattaforma applicativa - saranno finalizzati al trasferimento delle competenze in relazione all’amministrazione, alla gestione e alla conduzione operativa delle componenti applicative e del database.

I corsi dovranno essere finalizzati, inoltre, al trasferimento delle competenze in relazione ad:

• accesso, gestione, attività di storage management, di backup e ripristino delle configurazioni e delle banche dati di supporto;

• attività di gestione delle policy di sicurezza ed amministrazione degli utenti (autorizzazioni e profilazione, definizione gruppi, ecc.).

• accesso, interrogazione e modifica al database

• deploy, configurazione e gestione degli applicativi

• utilizzo interfacce del sistema verso sistemi esterni

11.3.3.2) Modalità di erogazione

I corsi dovranno essere organizzati ed erogati distintamente, sulla base dei contenuti formativi e delle diverse tematiche trattate. Le modalità di erogazione dovranno prevedere lezioni teoriche frontali sulle tecnologie utilizzate in aula (presso la Stazione Appaltante). Dovranno essere forniti ai partecipanti materiale didattico, FAQ ed un dettagliato manuale per amministratore di sistema fruibili in modalità e-Learning.

In particolare, come requisito minimo, si richiede che si tengano:

• n. 5 giornate formative in aula per tutto il personale individuato;

11.3.3.3) Utenza Target

L’utenza target dei corsi è rappresentata dal personale afferente il Settore dei Sistemi Informativi del Comune e d il numero di utenti da formare è venti.

11.4) HELP DESK

L’Aggiudicatario è tenuto a fornire assistenza telefonica e/o mediante altri sistemi di collaborazione online (permesso il solo utilizzo di strumenti informatici open source) e per tutta la durata della fornitura. L’assistenza si deve esplicitare in due tipologie di contatto, uno legato a problematiche dell’utenza ed uno legato a problematiche tecniche specialistiche e ad esclusiva disponibilità del personale tecnico interno dell’Amministrazione.

L’ help desk relativo alle problematiche dell’utenza supporterà in particolare:

• l'esecuzione operativa delle funzioni per quanto non espressamente documentato nella manualistica d'uso o di gestione, ovvero non opportunamente descritto in sede di addestramento;

L’ help desk relativo alle problematiche tecniche specialistiche dovrà:

• sopperire a difetti e/o a malfunzionamenti dei programmi applicativi;

• istruire il personale specializzato per il superamento, la correzione o l'aggiramento di eventuali errori presenti nei programmi;

• supportare l’installazione di nuove versioni dei programmi;

• dare assistenza sistemistica e consulenza riguardo all’utilizzo del software di base ed applicativo e per la risoluzione dei diversi problemi di esercizio connessi al funzionamento delle apparecchiature o all’impiego delle funzionalità applicative

• dare assistenza (anche ad eventuali altre aziende fornitrici) su come utilizzare le interfacce verso sistemi esterni (in particolare per l’attività di integrazione di banche dati avviata con il progetto Coopera et Eroga) per realizzare una cooperazione di sistemi.

L’assistenza può essere fornita in remoto, ma, su richiesta del Committente, dovrà essere fornita in locale (cioè presso il Committente).

Sono richieste attività di assistenza telefonica nelle ore di ufficio del comune dalle ore 08 alle ore 18.00 e H24 (durante i periodi richiesti per non più di 20 (venti) giorni all’anno e durante le consultazioni elettorali dal 45° giorno antecedente la consultazione stessa fino al compimento di tutte le operazioni inerenti l’elezione) e di numero 10 (dieci) interventi on site annuali di cui il comune dovrà tenere apposita documentazione in registro a cura dell’ufficio CED. Non verranno riconosciuti interventi non concordati ed autorizzati dal Servizio Autonomo Sistemi Informativi. Tali servizi di assistenza on-site dovranno essere prestati nell’orario di servizio dell’Amministrazione (art. 8 Luoghi ed Orari di lavoro). Le modalità di fruizione della pausa pranzo dovranno essere tali da garantire comunque la presenza continuativa del personale tecnico del Fornitore.

Per particolari esigenze operative l’Amministrazione potrà richiedere un prolungamento dell’ orario di lavoro fino alle ore 19.42.

8.1) REQUISITI

Compito del centro di contatto è la collaborazione a tale definizione con il committente, portando la propria esperienza e professionalità in modo da rendere coerenti e sinergiche le modalità di relazione. Tali politiche di relazione devono rispettare gli elementi descritti di seguito.

Riservatezza

Il centro di contatto deve rendere espliciti all’utente gli eventuali codici aziendali di autoregolamentazione, che definiscono requisiti che integrano quelli previsti dalle disposizioni legislative vigenti, in materia di riservatezza e tutela delle informazioni emessi sia dal centro di contatto stesso sia dal committente.

Verifica della soddisfazione dell’utente

Premesso che il committente esegue con cadenza periodica, almeno semestrale, un rilevamento della soddisfazione degli utenti, il centro di contatto deve rendere disponibili i dati necessari, affinché il campione sia statisticamente valido.

I risultati dovranno essere condivisi e valutati, nell’ottica del miglioramento, tra committente e centro di contatto. Tale rilevamento deve essere mirato a valutare come elementi minimi di conoscenza almeno:

• soddisfazione relativamente al servizio erogato;

• soddisfazione relativamente all’interazione con l’operatore (per esempio disponibilità, cortesia, chiarezza, competenza);

• eventuali criticità da migliorare;

• suggerimenti utili.

Al rilevamento di cui sopra, il committente può affiancare una serie di verifiche in incognito, mirate a valutare meglio gli aspetti procedurali del servizio erogato. Tali verifiche vengono effettuate simulando il comportamento e le esigenze tipiche degli utenti (mistery call o mistery audit).

Sezione III Gestione del contratto

Art. 12 - Referente tecnico dell’Aggiudicatario

Entro la data di inizio progetto (1/05/2014) l’Aggiudicatario dovrà segnalare formalmente all’Amministrazione un Referente Tecnico delegato alla supervisione dell’esecuzione del contratto e ai rapporti con il Dirigente del Servizio Autonomo Sistemi Informativi e i suoi delegati.

Si segnalano in via non esaustiva le attività che il Referente Tecnico dovrà svolgere:

🞏 coordinamento e l’armonizzazione delle risorse della propria azienda in ragione delle direttive dell’Amministrazione;

🞏 gestione del team di lavoro;

🞏 gestione delle eventuali sostituzioni in itinere del personale tecnico specializzato (le sostituzioni dovranno essere preventivamente concordate con l’Amministrazione, previa presentazione ed approvazione dei curricula e il costo complessivo della sostituzione non rappresenta un maggior costo per la SA);

🞏 ricerca di personale specializzato necessario per fronteggiare improvvisi carichi di lavoro;

🞏 controllo e rendicontazione di tutte le attività di cui al presente CSA;

🞏 comunicazione immediata di potenziali interruzioni o degradi dei livelli di servizio;

🞏 supporto per eventuali cambiamenti proposti dall’Amministrazione al progetto.

Il Dirigente del Servizio Autonomo Sistemi Informativi, con apposita disposizione, conferirà al Referente Tecnico dell’Aggiudicatario, che si obbliga ad accettare, l’incarico di “Responsabile Esterno al trattamento dei dati personali” (ex art. 29 L. 196/03) relativamente ai servizi richiesti nel presente capitolato.

L’eventuale sostituzione del Referente Tecnico, dovrà essere comunicata immediatamente e formalmente all’Amministrazione.

Nei periodi di assenza del Referente Tecnico dovrà essere fornito al Dirigente del Servizio Autonomo Sistemi Informativi il nominativo e i riferimenti del sostituto.

Anche nel caso in cui l’Aggiudicatario sia un RTI il Referente Tecnico dovrà essere unico e farsi carico anche della gestione dei rapporti tra i componenti del raggruppamento e di questi con l’Amministrazione..

Art. 13 - Documentazione tecnica per l’Aggiudicatario

La documentazione tecnica di cui al presente rappresenta un supporto descrittivo per la comprensione delle infrastrutture tecnologiche elaborative e degli applicativi in uso e, come tali, non possono essere considerate esaustive.

Inoltre, in aggiunta a quanto disponibile con il presente CSA, è possibile integrare con ulteriori documenti come di seguito descritto:

• recandosi presso gli uffici dell’Area Reti tecnologiche del Servizio Autonomo Sistemi Informativi - Centro Polifunzionale sito in Soccavo alla xxx Xxxxxxx - Xxxxxx, sede della Server Farm del Comune di Napoli per prendere visione della documentazione tecnica relativa alla gestione sistemistica e delle basi di dati;

• recandosi presso gli uffici dell’Area Sviluppo Applicativi del Servizio Autonomo Sistemi Informativi – Parco Quadrifoglio sito in Soccavo - Napoli per prendere visione della documentazione tecnica relativa all’applicativo di supporto ai servizi demografici;

• recandosi presso gli uffici del Servizio Affari Generali e Controlli Interni della Direzione Servizi Finanziari – Xxxxx Xxxxxxx Xxxxx 00 per prendere visione della documentazione tecnica relativa all’applicativo di supporto al sistema tributario e al portale delle entrate;

• recandosi presso gli uffici del Servizio Bilancio Comunale della Direzione Servizi Finanziari- Piazza Municipio, Palazzo San Xxxxxxx, primo piano per prendere visione della documentazione tecnica relativa all’applicativo di supporto ai servizi finanziari

La documentazione è disponibile negli orari di servizio dell’Amministrazione solo in consultazione e col divieto di ottenerne copia di qualsiasi natura.

La richiesta di visione di ulteriore documentazione dovrà essere presentata a mezzo PEC al Dirigente del Servizio Autonomo Sistemi Informativi con una modulo (allegato D) a firma del rappresentante legale dell’operatore che intende concorrere alla presente gara, in cui sia indicato, in particolare, la denominazione e la ragione sociale della società e gli estremi identificativi della/e persona/e (massimo tre) incaricate, l’indicazione della PEC alla quale intende ricevere le comunicazioni dall’Amministrazione.

La domanda, con allegata la fotocopia del documento di identità del richiedente, dovrà pervenire al Dirigente entro il 15° (quindicesimo) giorno lavorativo antecedente il termine di scadenza per la presentazione delle offerte. Non saranno prese in considerazione richieste pervenute oltre il termine sopra indicato.

In ogni caso è possibile la visione della documentazione aggiuntiva durante il sopralluogo (vedi art. 45 bis)

Art. 14 – Gestione della Qualità

14.1) Livello di Qualità Atteso (LQA)

L’Amministrazione intende, con la presente fornitura, proseguire nel processo di continuo e costante miglioramento del suo sistema informativo complessivo anche attraverso la predisposizione di processi e tecnologie funzionali alla misurazione della qualità dei servizi erogati sia verso i clienti interni che esterni.

Tale esigenza richiede oggettive rilevazioni ottenibili dal confronto tra i valori attesi (SLA) e quelli effettivi consentendosi cosi all’Amministrazione una puntuale attività di:

• controllo della corretta applicazione ed esecuzione della fornitura;

• monitoraggio del servizio offerto;

• analisi decisionali per la definizione di strategie di investimento e/o interventi correttivi o migliorativi nella gestione dei processi organizzativi anche durante l’erogazione del contratto.

Pertanto per tutta la durata contrattuale la qualità della fornitura deve essere assicurata e rendicontata dall’Aggiudicatario che dovrà produrre il Piano della Qualità e specificare le tecnologie (hw e sw) , che si impegna a predisporre, installare e condurre unitamente al personale tecnico interno, i criteri organizzativi ed operativi che, atteso i contesto operativo, siano idonei a gestire tutte le attività di misurazione, di pubblicazione dei dati prodotti in ragione degli indicatori definiti e da proporre (IQA) per una puntuale verifica dei livelli di qualità .

L’Amministrazione si riserva la facoltà di riprodurre, con il personale tecnico interno, le misure fornite dal Aggiudicatario mediante strumenti da esso forniti e/o da terzi.

Con il suddetto Piano della Qualità l’Aggiudicatario, recependo pienamente le esigenze e gli obiettivi dell’Amministrazione e nel rispetto dei principi di assicurazione e di gestione della qualità della norma UNI EN ISO 9001:2008 o versioni vigenti alla data, dovrà fornire un documento di riscontro per la definizione puntuale dei parametri oggetto di misura, della metodologia delle rilevazioni prefissate e le verifiche dei livelli di servizio, degli indicatori di qualità proposti (IQA) ad integrazione o ottimizzazione nonché valori di soglia migliorativi di quelli richiesti, della reportistica fornita(analisi, dettaglio, storici e sintesi).

Il Piano di qualità, coerentemente a quanto previsto dalla circolare 5 agosto 1994 n. AIPA/CR/5 e alla norma EN ISO 10005 e successive modifiche ed integrazioni, deve:

• fornire lo strumento per collegare i requisiti specifici dei servizi contrattualmente richiesti, con le procedure generali del sistema qualità del Aggiudicatario già esistenti;

• identificare i servizi e i controlli (test, review, verifiche, validazioni) che il Aggiudicatario svolge per assicurare la qualità della fornitura e relativi piani di verifica;

• illustrare l'organizzazione e le risorse previste dal Aggiudicatario in termini di ruoli, competenze, con specifico riferimento alle responsabilità riguardo i controlli da svolgere e per la gestione dei problemi e delle non conformità;

• dettagliare metodi, tecniche, procedure, metriche e strumenti previste dal Aggiudicatario per assicurare la qualità della fornitura, anche per ulteriori eventuali obiettivi di qualità del servizio proposti dal Aggiudicatario che non sono state oggetto di specifica richiesta;

• esplicitare la calendarizzazione delle attività di monitoring e reportistica;

• fornire eventuali proposte di ottimizzazione delle attività e dell'organizzazione che possano portare ad un miglioramento della qualità dei servizi, ad una riduzione dei costi ed alla quantificazione di tale riduzione;

• indicare la documentazione a supporto della valutazione della qualità che espliciti, tra l’altro, modalità di misura, modalità di calcolo ed aggregazione di misure per il computo di indicatori derivati, frequenza delle misure, periodi temporali di riferimento.

In ogni caso la metodologia per la raccolta dati, la loro elaborazione e aggregazione, la conservazione e la produzione di reportistica, deve comunque garantire i seguenti obiettivi minimi:

• standardizzare la modalità di conservazione dei dati di dettaglio o di sintesi;

• far coincidere, laddove possibile, gli strumenti di raccolta dati con quelli per il monitoring dei sistemi;

• garantire la flessibilità delle funzioni di reportistica (rapporti di analisi, di dettaglio, storici e di sintesi) e di modificabilità degli stessi, come la possibilità di incrocio dei dati o di aggregazioni con dati da fonti diverse e consultazioni anche con modalità drill-down:

• fornire una verifica diretta dei dati di rendicontazione;

• consentire un’analisi delle variazioni delle grandezze significative, utili alla analisi delle variazioni del carico e del capacity planning;

• rendere disponibili i dati statistici e di rendicontazione su specifica richiesta dell’Amministrazione.

Il Piano della Qualità deve essere sottoposto all’approvazione dell’Amministrazione e sarà aggiornato dall’Aggiudicatario, recependo osservazioni/integrazioni che l’Amministrazione riterrà opportuno introdurre nel corso della fornitura, anche a seguito di significativi cambiamenti di contesto e/o proposte di miglioramento che scaturiscano da incontri periodici di verifica sul buon andamento del servizio.

L’Aggiudicatario si impegna effettuare i suddetti incontri con cadenza almeno semestrale.

Costituisce inoltre obbligo dell’Aggiudicatario fornire nuove versioni integrali del Piano della Qualità entro 10 giorni lavorativi dalla formalizzazione dei rilievi.

14.2) Indicatori/ misuratori dei Livelli di Qualità Attesa (LQA Index)

In questo articolo sono definiti gli indicatori atti a descrivere i livelli di qualità della fornitura.

L’Aggiudicatario dovrà consegnare all’Amministrazione, in allegato al Rapporto di riepilogo, la documentazione di riepilogo dei livelli di qualità delle applicazione realizzate. I report dovranno evidenziare i risultati delle misure effettuate, con gli eventuali scostamenti rispetto ai livelli di servizio contrattuali, l’indicazione del conseguente ammontare delle penali, le motivazioni degli eventuali scostamenti in negativo ed i relativi correttivi.

La documentazione dovrà includere le informazioni di dettaglio sulle modalità di computo dei dati riportati su ciascun report.

Sarà valutata con punteggio, in sede di valutazione delle offerte, l’indicazione di ulteriori indicatori di qualità (IQA) da parte dell’Aggiudicatario.

In linea generale la gestione delle misure è parte integrante del Sistema di Project Management di cui il Aggiudicatario dovrà essere dotato.

Per le misure che si riferiscono a fasi del ciclo di vita per le quali è necessario verificare affidabilità e prestazioni in esercizio del prodotto sviluppato il sistema di gestione potrà essere parte del sistema di rilevazione e controllo dei livelli di servizio .

Classe di fornitura	GESTIONE SISTEMI	Tabella II.A
Caratteristica /Sottocaratteristica	Funzionalità/Accuratezza
Indicatore/Misura	Correttezza delle esecuzioni delle attività – CASS
Sistema di gestione delle misure	Per ogni attività schedulata si misura la correttezza di esecuzione nel rispetto della tempistica di schedulazione. Sono considerate sia le attività schedulate standard, sia quelle derivanti da richieste estemporanee accettate. Si misura la correttezza di esecuzione nel rispetto della tempistica concordata. Vanno considerate • le attività schedulate nel periodo di osservazione corrente • le attività nel periodo di osservazione precedente e terminate in quello corrente
Unità di misura	Percentuale
Dati elementari da rilevare	Numero delle attività schedulate correttamente eseguite nel periodo di osservazione
Periodo di riferimento	3 mesi
Frequenza esecuzione misure	4 volte l’anno
Regole di campionamento	La misura si fa sulla totalità delle attività schedulate
Formula di calcolo	Dati necessari numero delle attività schedulate nel periodo di osservazione numero delle attività correttamente eseguite nel periodo di osservazione, nel rispetto della tempistica di schedulazione CASS = Nattività _ schedulate _ correttamente _ eseguite ×100 Nattività _ schedulate
Regole di arrotondamento	Il valore va arrotondato alla frazione decimale di punto percentuale sulla base del secondo decimale - per difetto se la seconda parte decimale è ≤ 0,05 - per eccesso se la seconda parte decimale è > 0,05
Obiettivi (valori soglia)	CASS ≥ 99 %
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di tre mesi dalla data di inizio delle attività

Classe di fornitura	GESTIONE SISTEMI	Tabella II.B
Caratteristica /Sottocaratteristica	Affidabilità/ Tolleranza ai guasti
Indicatore/Misura	Disponibilità del sistema – DIS1
Sistema di gestione delle misure	La disponibilità viene misurata contando il numero dei fermi non programmati di sistema e la loro durata, nell’arco della finestra di erogazione del servizio. L’indicatore relativo alla disponibilità dei sistemi riguarda la disponibilità dell’intera infrastruttura hardware e software necessaria all’erogazione di una applicazione verso l’utente finale e non quindi la disponibilità di un singolo elemento del sistema. L’indicatore relativo alla disponibilità dei sottosistemi (db) e prodotti del middleware (Web Server, Application Server, ecc.) in questo contesto riguarda la disponibilità delle prestazioni o la fruizione dell’applicazione nella sua interezza.
Unità di misura	Percentuale
Dati elementari da rilevare	• Data e ora di fermo (al minuto) • Data e ora di riattivazione (al minuto)
Periodo di riferimento	3 mesi
Frequenza esecuzione misure	4 volte l’anno
Regole di campionamento	Vanno considerati i fermi non programmati, non dovuti all’applicazione, rilevabili dal log di sistema e/o dai registri di conduzione operativa. • Xxxxx occorsi e risolti nel periodo di osservazione corrente • Xxxxx occorsi nel periodo di osservazione precedente e risolti in quello corrente.
Formula di calcolo	Dati necessari • durata del fermo a valle della segnalazione (dopo il 1° anno della fornitura) • tempo totale = tempo contrattuale di erogazione del servizio nel periodo di riferimento (esclusi i fermi programmati) La disponibilità si rappresenta come DIS1 = Tempo _ totale − ∑ Durata _ fermo ×100 Tempo _ totale
Regole di arrotondamento	La percentuale va arrotondata alla frazione decimale di punto percentuale sulla base del secondo decimale - per difetto se la parte decimale è ≤ 0,05 - per eccesso se la parte decimale è > 0,05
Obiettivi (valori soglia)	Obiettivi DIS1 ≥ 99,0%(sistemi in ambiente Oracle RAC5) DIS1 ≥ 98,0% (per gli altri sistemi)
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di tre mesi dalla data di inizio delle attività

5 L’ambiente Oracle Rac costituisce il core applicativo dell’Amministrazione

Classe di fornitura	GESTIONE SISTEMI	Tabella II.C
Caratteristica /Sottocaratteristica	Efficienza/Efficienza temporale
Indicatore/Misura	Tempo di ripristino erogazione dei servizi –TRES
Sistema di gestione delle misure	Nella misurazione dei tempi di ripristino erogazione dei servizi non devono essere considerati i tempi dipendenti da terzi diversi dal Fornitore (fornitori di hw,sw, logistica etc)
Unità di misura	Percentuale
Dati elementari da rilevare	• data e orario(al secondo) di segnalazione della malfunzione che provoca l’interruzione nell’erogazione dei servizi (D_segnal_mal) • data e orario (al secondo) di chiusura della malfunzione che ha provocato l’interruzione nell’erogazione dei servizi ovvero data e orario di risoluzione della malfunzione (D_chiusura_mal) • Numero totale ticket di segnalazioni di malfunzione che hanno provocato l’interruzione nell’erogazione dei servizi (N_int_tres) • tempi dipendenti da terzi diversi dal Fornitore (T_est)
Periodo di riferimento	3 mesi
Frequenza misure	4 volte l’anno
Regole di campionamento	Vanno considerati i ticket di segnalazione di malfunzione che provocano l’interruzione nell’erogazione dei servizi, non dovuti all’applicazione, rilevabili dal sistema di gestione del trouble ticketing..
Formula di calcolo	La disponibilità si rappresenta come TRES1 = N_interv(T_interv ≤ h1) × 100 N_interv_tres TRES2 = N_interv(T_interv ≤ h2 ) × 100 N_interv_tres dove : T_interv = ((D_chiusura_mal-D_segnal_mal) - T_est) h1= x ore (3h) h2= y ore (5h)
Regole di arrotondamento	La percentuale va arrotondata alla frazione decimale di punto percentuale sulla base del secondo decimale - per difetto se la parte decimale è ≤ 0,05 - per eccesso se la parte decimale è > 0,05
Obiettivi (valori soglia)	TRES1 ≥95% per sistemi in ambiente Oracle Rac TRES2 ≥ 95% per gli altri sistemi fisici e virtuali
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di tre mesi dalla data di inizio delle attività

Classe di fornitura	MANUTENZIONE SISTEMI	Tabella II.D
Caratteristica /Sottocaratteristica	Funzionalità/Accuratezza
Indicatore/Misura	Accuratezza ripristino corretto funzionamento - ARCF
Sistema di gestione delle misure	Verifica degli interventi correttivi con esito positivo . Sono considerate le apparecchiature ripristinate correttamente rispetto al totale delle apparecchiature su cui sono stati eseguiti gli interventi di manutenzione correttiva. Vanno considerati • gli interventi iniziati e terminati nel periodo di osservazione corrente • gli interventi iniziati nel periodo di osservazione precedente e terminati in quello corrente
Unità di misura	Percentuale
Dati elementari da rilevare	• Numero totale di chiamate di intervento per manutenzione correttiva • Numero di interventi andati a buon fine
Periodo di riferimento	6 mesi
Frequenza esecuzione misure	2 volte l’anno
Regole di campionamento	Tutte le chiamate di intervento nel periodo di osservazione
Formula di calcolo	Dati necessari • numero delle chiamate di intervento per manutenzione correttiva nel periodo di osservazione • numero degli interventi andati a buon fine nel periodo di osservazione ARCF = N int_ andati _ a _ buon _ fine ×100 Nchiamate _ per _ manutenzione _ correttiva
Regole di arrotondamento	Il valore va arrotondato alla frazione decimale di punto percentuale sulla base del secondo decimale - per difetto se la seconda parte decimale è ≤ 0,05 - per eccesso se la seconda parte decimale è > 0,05
Obiettivi (valori soglia)	ARCF ≥ XX (98)
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di tre mesi dalla data di inizio delle attività

Classe di fornitura	GESTIONE DELLA CONFIGURAZIONE	Tabella II.E
Caratteristica /Sottocaratteristica	Funzionalità/Adeguatezza
Indicatore/Misura	Correttezza dell’aggiornamento della configurazione - CRAC
Sistema di gestione delle misure	Gli aggiornamenti apportati alla configurazione degli elementi del sistema non devono introdurre problemi. Sono identificati i seguenti livelli di gravità: 1. blocco totale dei servizi erogati 2. degrado dei servizi erogati
Unità di misura	Percentuale
Dati elementari da rilevare	Numero degli aggiornamenti con problemi
Periodo di riferimento	6 mesi
Frequenza esecuzione misure	2 volte l’anno
Regole di campionamento	La misura si fa sulla totalità degli interventi di aggiornamento pianificati durante la normale gestione, può anche essere effettuata durante l’esecuzione degli audit sulla configurazione.
Formula di calcolo	Dati necessari: • Numero di aggiornamenti alla configurazione • Numero di aggiornamenti che determinano problemi (per gravità) CRAC = Ninterventi con problemin ×100 i Ntotaleinterventi i = 1,2 (gli interventi sono classificati in funzione della gravità)
Regole di arrotondamento	La frequenza va arrotondata al punto percentuale sulla base del primo decimale - al punto % per difetto se la parte decimale è ≤ 0,5 - al punto % per eccesso se la parte decimale è > 0,5
Obiettivi (valori soglia)	Valori soglia • CRAC1 = X% (1%) CRAC2 = Y% (3%) per sistemi in ambiente Oracle RAC CRAC1 = W% (2%) CRAC2 = Z% (4%) per altri sistemi
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di tre mesi dalla data di inizio delle attività

Classe di fornitura	GESTIONE DELLA CONFIGURAZIONE	Tabella II.F
Caratteristica /Sottocaratteristica	Funzionalità / Accuratezza
Indicatore/Misura	Completezza dell’aggiornamento di configurazione - CMAC
Sistema di gestione delle misure	L’archivio di configurazione deve comprendere tutte le componenti previste, corredate delle informazione necessarie alla gestione, per esempio: identificativo del componente, stato, richiesta di modifica in corso, stato della richiesta, ecc. Viene utilizzato lo stesso sistema di gestione della configurazione, che contiene i dati elementari necessari per l’indicatore. NOTA: Per elemento mancante si intende anche un elemento non conforme, ovvero che non ha tutti gli attributi previsti.
Unità di misura	Numero di elementi mancanti
Dati elementari da rilevare	Numero degli elementi di configurazione (EC) mancanti
Periodo di riferimento	6 mesi
Frequenza esecuzione misure	2 volte l’anno, o secondo pianificazione degli audit
Regole di campionamento	La misura si fa sulla totalità degli interventi di aggiornamento pianificati, al termine della scadenza del piano, durante la normale gestione, può anche essere effettuata durante l’esecuzione degli audit sulla configurazione.
Formula di calcolo	Dati necessari: Conteggio del numero di elementi mancanti
Regole di arrotondamento	Non applicabile
Obiettivi (valori soglia)	Obiettivo • nessun elemento di configurazione mancante nell’archivio di configurazione
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di tre mesi dalla data di inizio delle attività

Classe di fornitura	GESTIONE BASE DATI	Tabella II.G
Caratteristica /Sottocaratteristica	Funzionalità / Accuratezza
Indicatore/Misura	Accuratezza dei restore dei database - ARDB
Sistema di gestione delle misure	Strumenti per la raccolta dei dati elementari (restore effettuato, data e ora, tempo di restore) L’indicatore misura la differenza fra il tempo previsto per il restore del database e il tempo effettivo di restore impiegato. Le durate sono classificate per livelli di gravità secondo quanto stabilito entro e non oltre i primi tre mesi di attività di presidio. Per esempio: • alta (utente bloccato, non riesce ad utilizzare l’applicazione); • media (utente bloccato su una singola funzionalità dell’applicazione); Si fa riferimento alle analisi di rendicontazione delle attività di manutenzione. Tale parametro è valido per il primo anno di assistenza sistemistica di tipo continuativo
Unità di misura	Percentuale
Dati elementari da rilevare	• tempo di restore database come da contratto (TRDB) • tempo effettivo di restore database (TEDB)
Periodo di riferimento	6 mesi
Frequenza esecuzione misure	2 volte l’anno
Regole di campionamento	Vanno considerate tutte le operazioni di restore effettuate
Formula di calcolo	Dati necessari • tempo contrattuale di restore database (TRDB) • tempo effettivo di restore database (TEDB) ARDB = TEDB − TRDB
Regole di arrotondamento	• Le durate vanno arrotondate all’ora
Obiettivi (valori soglia)	Obiettivi • ARDB ≤ valore normale • ARDB ≤ valore limite Valori soglia valori normali e valori limite sono stabiliti con il Dirigente del Servizio Sistemi Informativi o suo delegato, in funzione della gravità del disservizio legato all’indisponibilità del data-base e delle dimensioni dello stesso. Entro i primi tre mesi dalla data di inizio attività.
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di tre mesi dalla data di inizio delle attività

Classe di fornitura	GESTIONE BASE DATI	Tabella II.H
Caratteristica /Sottocaratteristica	Funzionalità / Accuratezza
Indicatore/Misura	Completezza dei back-up effettuati – CBKE
Sistema di gestione delle misure	Strumenti per la raccolta dei dati elementari dei back-up effettuati (nome back-up, repository, data e ora). . Tale parametro è valido per il primo anno di assistenza sistemistica di tipo continuativo
Unità di misura	Numero di elementi mancanti
Dati elementari da rilevare	• numero di back-up richiesti per applicazione • numero di back-up realmente effettuati per applicazione
Periodo di riferimento	6 mesi
Frequenza esecuzione misure	2 volte l’anno o secondo pianificazione degli audit
Regole di campionamento	Vanno considerati tutti tutti i backup effettuati
Formula di calcolo	Dati necessari • numero di back-up richiesti per applicazione (NBR) • numero di back-up realmente effettuati per applicazione (NBE) e non in errore. CBKE = NBR − NBE La quantità CBKE indica il numero di elementi (back-up) mancanti
Regole di arrotondamento	NA
Obiettivi (valori soglia)	Obiettivi • CBKE = 0
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di tre mesi dalla data di inizio delle attività

Classe di fornitura	MANUTENZIONE CORRETTIVA	Tabella II.I
Caratteristica /Sottocaratteristica	Funzionalità/Accuratezza
Indicatore/Misura	Tasso di backlog - TAB
Sistema di gestione delle misure	L’indicatore misura il numero degli interventi di manutenzione correttiva non evasi rispetto al totale degli interventi richiesti. Sono identificati quattro categorie i livelli di malfunzione • cat. 1–livello gravità 1: è impedito l’uso dell’applicazione o di una o più funzioni o il funzionamento risulta non corretto; • cat. 2–livello gravità 2: è impedito l’uso di una funzione dell’applicazione in alcune specifiche condizioni (ad es. per alcuni dati di input, per alcuni utenti, ecc.) (livello di gravità 2); • cat. 3–livello gravità 3: è impedito l’uso della funzione, ma lo stesso risultato è ottenibile con altra modalità operativa ed i malfunzionamenti sono di tipo marginale; • cat. 4–livello gravità 4: malfunzione di tipo marginale non rientrante nelle precedenti categorie (ad. es. anomalie rilevate nella documentazione, nel dizionario dati, ecc..)
Unità di misura	Percentuale
Dati elementari da rilevare	• numero di interventi correttivi inevasi • numero di interventi correttivi richiesti
Periodo di riferimento	6 mesi
Frequenza misure	2 volte l’anno
Regole di campionamento	Vanno considerate tutte le richieste pervenute, suddivise per gravità
Formula di calcolo	Dati necessari ▪ numero di interventi correttivi inevasi ▪ numero di interventi correttivi richiesti Si calcola quindi la frequenza degli interventi inevasi TAB = Ninterventiinevasi ×100 i Ntotaleinterventi richiesti i = 1,2,3,4 (gli interventi sono classificati in funzione della gravità)
Regole di arrotondamento	La frequenza va arrotondata al punto percentuale sulla base del primo decimale ▪ al punto % per difetto se la parte decimale è ≤ 0,5 ▪ al punto % per eccesso se la parte decimale è > 0,5
Obiettivi (valori soglia)	Obiettivi: TAB < 1% per valore normale TAB < 2% per valore limite Il valore dei tempi di evasione degli interventi è indicato contrattualmente in funzione della gravità.
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di tre mesi. Le conseguenze del mancato rispetto delle richieste nei tempi previsti non viene applicato se le cause non sono imputabili al fornitore MAC.

Classe di fornitura	MANUTENZIONE CORRETTIVA E ADEGUATIVA	Tabella II.K
Caratteristica /Sottocaratteristica	Efficacia
Indicatore/Misura	Recidività di errore - REC.
Sistema di gestione delle misure	Misura il grado di efficacia degli interventi di manutenzioni misurando la percentuale di errori che si ripresentano dopo l’intervento correttivo.
Unità di misura	Numerosità degli interventi recidivi
Dati elementari da rilevare	• numero totale degli interventi di manutenzione correttiva • numero di errori recidivi
Periodo di riferimento	6 mesi
Frequenza esecuzione misure	2 volte l’anno
Regole di campionamento	Vengono considerati tutti gli interventi di manutenzione effettuati
Formula di calcolo	Dati necessari • numero totale degli interventi di manutenzione correttiva (T) • numero di errori recidivi (R) REC = R x100 T
Regole di arrotondamento	La percentuale va arrotondata alla cifra intera
Obiettivi (valori soglia)	Obiettivi: REC < 2% valore normale REC < 5% valore limite
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di osservazione dall’avvio del servizio della durata di 3 mesi. Le conseguenze del mancato rispetto delle richieste nei tempi previsti non viene applicato se le cause non sono imputabili al fornitore di servizi.

Classe di fornitura	MANUTENZIONE CORRETTIVA	Tabella II.J
Caratteristica /Sottocaratteristica	Efficienza/Efficienza temporale
Indicatore/Misura	Rispetto dei tempi di risoluzione del problema – RTRP
Sistema di gestione delle misure	L’indicatore misura la differenza tra il tempo previsto contrattualmente per la risoluzione del problema ed il tempo effettivamente impiegato per la risoluzione del problema. Le durate sono classificate per tipo sulla base dei livelli di gravità definiti dall’Amministrazione. Per esempio: • cat. 1–livello gravità 1: è impedito l’uso dell’applicazione o di una o più funzioni o il funzionamento risulta non corretto; • cat. 2–livello gravità 2: è impedito l’uso di una funzione dell’applicazione in alcune specifiche condizioni (ad es. per alcuni dati di input, per alcuni utenti, ecc.) (livello di gravità 2); • cat. 3–livello gravità 3: è impedito l’uso della funzione, ma lo stesso risultato è ottenibile con altra modalità operativa ed i malfunzionamenti sono di tipo marginale; • cat. 4–livello gravità 4: malfunzione di tipo marginale non rientrante nelle precedenti categorie (ad. es. anomalie rilevate nella documentazione, nel dizionario dati, ecc..) .
Unità di misura	Percentuale
Dati elementari da rilevare	• durata prevista di risoluzione problema • durata effettiva di risoluzione problema
Periodo di riferimento	Non inferiore a 6 mesi solari consecutivi
Frequenza esecuzione misure	Nei momenti stabiliti dal Dirigente del Servizio Autonomo Sistemi Informativi o suo delegato per verificare il livello di qualità del servizio di manutenzione
Regole di campionamento	Vanno considerate tutte le richieste pervenute
Formula di calcolo	Dati necessari: • durata prevista di risoluzione problema (Tp) • durata effettiva di risoluzione problema (Te) RTRP = Tp − Te Si calcola quindi la frequenza delle durate inferiori al valore normale FN i = N (durata ≤ valore normale) ×100 RTRP Neventi e la frequenza delle durate superiori al valore limite FL i = N (durata ≤ valore limite) ×100 RTRP Neventi i = 1,...,4 (le durate sono classificate in funzione della gravità)

Regole di arrotondamento	• Le durate vanno arrotondate al giorno • La frequenza va arrotondata al punto percentuale sulla base del primo decimale al punto % per difetto se la parte decimale è ≤ 0,5 al punto % per eccesso se la parte decimale è > 0,5
Obiettivi (valori soglia)	Obiettivi: • RTRP ≤ valore normale con FNRTRP ≥ frequenza normale • RTRP ≤ valore limite con FLRTRP ≥ frequenza limite Valori soglia: I valori normali per la soluzione del problema sono definiti in funzione della gravità, e decorrono dalla data e ora di segnalazione formale della malfunzione: • gravità 1: 4/6 ore lavorative • gravità 2: 6/12 ore lavorative • gravità 3: 8/24 ore lavorative • gravità 4: 16/48 ore lavorative I valori limite per la soluzione del problema sono definiti contrattualmente in funzione della gravità, tali valori per manutenzione correttiva sono compresi tra 1 giorno nel caso di gravità 1, fino a 4-5 giorni per gravità 4. • gravità 1: 1 giorno lavorativo • gravità 2: 2 giorni lavorativi • gravità 3: 3 giorni lavorativi • gravità 4: 4 giorni lavorativi frequenza normale = 95% frequenza limite = 100%
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di osservazione dall’avvio del servizio della durata di 3 mesi. Le conseguenze del mancato rispetto delle richieste nei tempi previsti non viene applicato se le cause non sono imputabili al fornitore di servizi.

Classe di fornitura	MANUTENZIONE ADEGUATIVA/EVOLUTIVA	Tabella II.L
Indicatore/Misura	SPCP – scostamento puntualità consegna prodotti fase
SPECIFICA	Misura il grado di puntualità nella consegna dei prodotti previsti ad ultimazione di ciascuna fase dello specifico ciclo di vita del progetto adottato (completo,ridotto,unico) considerato ad eccezione della fase di collaudo.
Unità di misura	Giorno lavorativo
Formula di calcolo	𝑛 SPCP = ∑(𝐷𝐸𝐶 − 𝐷𝑃𝐶) 1 n=numero dei prodotti previsti per la specifica fase considerata DEC=Data Effettiva Consegna DPC=Data prevista consegna
Obiettivi (valori soglia)	SPCP <X gg (5 gg) per ciclo completo; SPCP < Y gg (3 gg) per ciclo ridotto; SPCP < Z gg (2 gg) per ciclo a fase unica

Classe di fornitura	SVILUPPO E MEV DI SOFTWARE	Tabella II.M
Caratteristica /Sottocaratteristica	Funzionalità / Accuratezza
Indicatore/Misura	Densità dei test rispetto alla dimensione del sw (analisi) – TSTD
Sistema di gestione delle misure	L’obiettivo è quello di verificare che la progettazione dei test funzionali e di integrazione, per i test che devono essere documentati e consegnati (specifiche di test), preveda una copertura minima delle condizioni di test (esempio condizione positive, condizione non valida, condizioni negative) e di utilizzo che ogni singola funzione può possedere, misurando il numero complessivo dei test progettati rispetto al numero di funzionalità elementari. Questo indicatore è da utilizzare in fase di approvazione del piano e delle specifiche di test, al termine della fase di progettazione. Ha lo scopo primario di validare l’attività di progettazione del test sotto l’aspetto della copertura e dei volumi richiesti, mentre la valutazione del livelli minimi di copertura dei test rispetto ai requisiti si considera esaurita in fase di approvazione delle specifiche. E’ limitato ai soli test funzionali e di integrazione. La rilevazione può essere fatta durante l’analisi delle specifiche di test, in validazione al termine della fase di analisi, o con gli appositi tool di test management utilizzati.
Unità di misura	TSTD = percentuale.
Dati elementari da rilevare	Numero totale di funzionalità elementari definite nelle Specifiche o in altra documentazione (piano di test) (Nfunz) Numero totale dei test funzionali e di integrazione sviluppati sulle funzionalità elementari (Ntest_funz).
Periodo di riferimento	La durata della fase di analisi
Frequenza esecuzione misure	Una volta, al termine del periodo di riferimento
Regole di campionamento	NA
Formula di calcolo	TSTD = (Ntest_funz / (NFunz ^ 1.2)) x 100 esempio: sono stati sviluppati e documentati 350 casi di test per 500 Funzionalità elementari previste. NFunz ^ 1.2 = 500 ^1.2 = 1.733 (arrotondato all’intero) TSTD = (350 / 1733) x 100 = 20%
Regole di arrotondamento	Il risultato della misura va arrotondato al punto % intero: - per difetto se la parte decimale è <= 0,5 - per eccesso se la parte decimale è > 0,5

Obiettivi (valori soglia)

Nell’ambito della metrica si considerano solo i test funzionali e di integrazione oggetto di pianificazione e la parte rappresentativa degli stessi che deve essere documentata e consegnata all’amministrazione, in modo da garantirne il futuro riutilizzo. Si considera accettabile una soglia del 20% sul rapporto numero di test = (funzionalità elementari) ^1,2 E’ importante che la definizione del test, dei suoi confini e dimensioni, sia univoca e condivisa all’interno del progetto, affinchè sia possibile utilizzare l’indicatore correttamente.

Eccezioni

Le eccezioni riguardano quelle tipologie di forniture di sviluppo software dove non sia possibile o coerente l’utilizzo della scomposizione funzionale. In questi casi la metrica potrà essere rivista sulla base delle diverse tecniche utilizzate per il dimensionamento del software o della fornitura.

Classe di fornitura	SVILUPPO E MEV DI SOFTWARE	Tabella II.N
Caratteristica /Sottocaratteristica	Affidabilità / maturità
Indicatore/Misura	Difettosità – NDIF
Sistema di gestione delle misure	Verrà utilizzato lo stesso sistema di gestione sia per le attività di nuovo sviluppo sia per gli interventi di manutenzione evolutiva. Il sistema dovrà essere in grado di raccogliere ed elaborare i dati elementari in particolare nelle fasi di test, collaudo e nell’arco temporale relativo all’ avviamento/diffusione. Il sistema di rilevazione deve prevedere una classificazione delle malfunzioni in base alle seguenti tipologie: − non bloccante: malfunzione che, pur impedendo l’uso delle funzioni software, non inibisce l’operatività da parte dell’utente; l’utente può cioè ugualmente pervenire ai risultati attesi mediante l’utilizzo di altre funzionalità comunque offerte dal sistema; − bloccante: malfunzione che rende totalmente o parzialmente non utilizzabili le funzionalità disponibili all’utente. I fermi dell’applicazione sono provocati da errori bloccanti. La rilevazione può essere fatta automaticamente con appositi tool di defects tracking o con modalità mista. Ogni malfunzione rilevata deve essere analizzata e classificata per rilevarne la causa. Malfunzioni derivanti dalla medesima causa devono essere conteggiate una sola volta.
Unità di misura	percentuale
Dati elementari da rilevare	• Nr malfunzioni per tipo. • Fase di rilevazione (test, collaudo, avviamento / diffusione).
Periodo di riferimento	Intera durata contrattuale
Frequenza esecuzione misure	NA
Regole di campionamento	NA
Formula di calcolo	Dati necessari NDIFB = MBTOT / FE NDIFNB = MNBTOT / FE MBTOT = numero totale di Malfunzioni Bloccanti rilevate nel periodo di riferimento; MNBTOT = numero totale di Malfunzioni Non Bloccanti rilevate nel periodo di riferimento; FE= Funzionalità elementari Il valore va espresso come percentuale.
Regole di arrotondamento	La percentuale va arrotondata al decimale successivo dell’ultimo decimale significativo del valore di soglia. (es. per valore di soglia = 0,01 l’arrotondamento è al terzo decimale).

Obiettivi (valori soglia)

Obiettivi L’obiettivo è quello di tenere sotto controllo l’affidabilità dell’applicazione, monitorando il tasso degli errori applicativi che provocano il fermo dell’applicazione. Valori soglia: si pongono gli stessi valori soglia sia per i nuovi sviluppi che per la MEV; i valori soglia sono riferiti alla fase di avviamento / diffusione. I valori soglia da definire dipendono dalla criticità delle applicazioni che esprime il grado di affidabilità che viene richiesto al software in relazione ai rischi che si corrono nel caso in cui lo stesso presenti inconvenienti in esercizio; si fa riferimento alla seguente classificazione Classe Valore soglia Valore soglia di Descrizione errori non errori bloccanti criticità bloccanti Sanzioni civili e penali, consistenti 1 perdite economiche, gravi ripercussioni 0,01% 0,5% sull’immagine Interruzione del servizio con 2 conseguenti danni economici e di 0,1% 1% immagine 3 Perdite moderate, facilmente 0,2% 2% recuperabili 4 Perdite scarse, facilmente recuperabili 0,5% 5% 5 Inconvenienti lievi 1% 5%

Eccezioni

L’applicazione delle regole contrattuali può iniziare dopo un periodo di osservazione dall’inizio dell’avviamento/diffusione (esempio, della durata di 1-2 mesi).

Classe di fornitura	SVILUPPO E MEV DI SOFTWARE	Tabella II.O
Caratteristica /Sottocaratteristica	Efficienza temporale
Indicatore/Misura	Tempo medio di risposta – TMR
Sistema di gestione delle misure	Tale metrica fornisce una misura di quanto la media dei tempi di risposta delle transazioni, rilevata in un determinato arco temporale (in fase di test, collaudo e avviamento / diffusione) si discosta da un valore limite prefissato. La rilevazione è fatta tramite tool automatici di controllo delle prestazioni.
Unità di misura	millisecondi
Dati elementari da rilevare	Tempi di esecuzione delle transazioni delle applicazioni soggette alla metrica.
Periodo di riferimento	Fasi di test, collaudo, avviamento / diffusione.
Frequenza esecuzione misure	Ad ogni esecuzione delle transazioni.
Regole di campionamento	NA
Formula di calcolo	TMR = MM / VL dove: MM = media mensile (o settimanale o giornaliera,…) dei tempi di risposta delle transazioni VL = Valore limite prefissato La media dei tempi di risposta delle transazioni è calcolata considerando come tempo di risposta di ogni esecuzione di ogni transazione, il tempo che intercorre tra l’inizio ingresso dei dati di input sul sistema di elaborazione e l’inizio uscita dei dati di output dal sistema di elaborazione. Il valore 1 dell’indicatore indica che la media nel periodo di riferimento dei tempi di risposta delle transazioni coincide con il valore limite prefissato; valori minori o maggiori di 1 indicano, rispettivamente, media mensile dei tempi di risposta delle transazioni inferiore o maggiore del valore limite prefissato.
Regole di arrotondamento	interi
Obiettivi (valori soglia)	Il tempo limite si stabilisce in base all’esigenza del requisito prestazionale in fase di utilizzo del prodotto realizzato. Il valore di soglia dell’indicatore è il seguente: TMR ≤ 800 ms Possono essere previsti più valori per il tempo limite in base ai requisiti delle singole funzionalità in fase contrattuale che vanno comunque da 200 a 2000 ms per funzionalità real-time (la maggior parte delle funzionalità saranno di questo genere) e con tempi da stabilire in base alle funzionalità ed esigenze per le operazioni asincrone.
Eccezioni	L’applicazione delle regole contrattuali si limita alle attività di avviamento / diffusione ed inizia dopo un periodo di osservazione dall’inizio dell’avviamento / diffusione di 2 mesi

Classe di fornitura	SVILUPPO E MEV DI SOFTWARE	Tabella II.P
Caratteristica /Sottocaratteristica	Usabilità / Operabilità
Indicatore/Misura	Facilità d’uso – FUSO
Sistema di gestione delle misure	L’indicatore misura la capacità di supportare l’utente nella sua operatività. Le informazioni necessarie vengono rilevate da un campione selezionato di utenti finali. La raccolta delle informazioni avviene tramite analisi delle risposte inseriti in opportuni questionari distribuiti al campione prescelto.
Unità di misura	Percentuale
Dati elementari da rilevare	Voto (in una scala predefinita) attribuito a ciascuna risposta del questionario
Periodo di riferimento	Durante la fase di consegna e collaudo
Frequenza esecuzione misure	La misura viene effettuata ad ogni riedizione del prodotto.
Regole di campionamento	Per ogni applicazione e per ogni profilo utente deve essere inserito nel campione almeno un utente per ogni livello professionale.
Formula di calcolo	Dati necessari: • numero utenti soddisfatti (USOD), per ogni applicazione • numero utenti selezionati (USEL), per ogni applicazione FUSO = USOD ×100 USEL Un utente viene considerato soddisfatto se la percentuale pesata di risposte positive al questionario è superiore alla soglia stabilita. Il peso attribuito ad ogni risposta tiene conto della importanza attribuita alla domanda.
Regole di arrotondamento	Il valore percentuale va arrotondato alla cifra intera.
Obiettivi (valori soglia)	FUSO ≥ 90
Eccezioni	NA

Classe di fornitura	SVILUPPO E MEV DI SOFTWARE	Tabella II.Q
Caratteristica /Sottocaratteristica	Affidabilità / ripristinabilità
Indicatore/Misura	Efficienza di rimozione errori – RERR
Sistema di gestione delle misure	Il sistema si applica sia alle attività di nuovo sviluppo sia agli interventi di MEV. Il sistema dovrà essere in grado di raccogliere ed elaborare i dati elementari in particolare nell’arco temporale relativo all’avviamento / diffusione / garanzia. La rilevazione può essere fatta in modalità mista con appositi tool di defects tracking e trouble ticketing.
Unità di misura	RERRBL, RERRNBL = percentuale. T = ora
Dati elementari da rilevare	• Nr malfunzioni rilevate per Tipo; • Nr interventi di rimozione effettuati con esito positivo; • Tempo di rimozione e ripristino.
Periodo di riferimento	Nel corso dell’avviamento / diffusione.
Frequenza esecuzione misure	Trimestrale
Regole di campionamento	NA
Formula di calcolo	Malfunzioni rimosse nel tempo limite (valori espressi come percentuale): RERRBL= MBLrimossi/ MBLrilevati RERRNBL= MNBLrimossi/MNBLrilevati dove: MBLrimossi/rilevati = numero totale delle Malfunzioni Bloccanti rimosse nel tempo limite / rilevate nel periodo di osservazione; MNBLrimossi/rilevati = numero totale delle Malfunzioni Non Bloccanti rimosse nel tempo limite / rilevate nel periodo di osservazione; Tempo di rimozione e ripristino T = (D-fi) – (D-in) D-in= data/ora inizio intervento eseguito nel tempo limite D-fi= data/ora fine intervento eseguito nel tempo limite Gli indicatori esposti devono essere misurati distintamente per ciascuna “Classe di criticità “
Regole di arrotondamento	La percentuale va arrotondata al primo decimale.
Obiettivi (valori soglia)	L’obiettivo è quello di controllare l’efficienza e l’efficacia del periodo di avviamento/diffusione monitorando la tempestività di intervento per malfunzionamenti. Valori soglia: RERRBL ≥ 98% con tempo limite = 3 - 4 ore. Il restante 2% dei casi deve essere risolto nel tempo limite = 6 – 12 ore. RERRNBL ≥ 95% con tempo limite = 4 – 12 ore; il restante 5% dei casi deve essere risolto nel tempo limite = 16 – 24 ore. Il valore della % di rimozione fa riferimento alla misura a fine avviamento / diffusione riferita all’intero arco temporale. I malfunzionamenti bloccanti riscontrati nel periodo coperto da garanzia devono comunque essere tutti rimossi.
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di osservazione dall’inizio dell’avviamento / diffusione della durata di 2 mesi.

Classe di fornitura	MIGRAZIONE E CONVERSIONE APPLICATIVI	Tabella II.R
Caratteristica /Sottocaratteristica	Funzionalità / Accuratezza
Indicatore/Misura	Difettosità - DIFE
Sistema di gestione delle misure	Vengono rilevati il numero di errori avvenuti durante il collaudo ed il numero di malfunzionamenti rilevati durante il periodo di transizione. Viene utilizzata la repository dei dati elementari del verbale di collaudo e quella dei malfunzionamenti successivamente rilevati. Sono identificate quattro classi di rischio per l’applicazione: • Classe A: Applicazione caratterizzata da un’elevatissima criticità dovuta alle possibili responsabilità civili e/o penali legate all’importanza economica dei dati elaborati ed al loro potenziale impatto sull’esterno. Una malfunzione può provocare danni gravi e diffusi verso terzi oppure causare una consistente perdita di immagine/economica. • Classe B: Applicazione caratterizzata da limitate responsabilità civili e/o penali in caso di malfunzioni, pur trattando dati rilevanti economicamente e/o informazioni riservate. Una malfunzione può provocare danni e/o una certa perdita di immagine. • Classe C: Applicazione caratterizzata da informazioni non critiche; una malfunzione comporta la sola perdita del lavoro svolto o danni di limitato valore economico. Sono definite tre gravità degli errori: • Gravità 1: Malfunzione che impedisce l’uso dell’applicazione o di una o più funzioni; • Gravità 2: Malfunzione che impedisce l’uso di una funzione dell’applicazione in alcune specifiche condizioni (per esempio, solo per alcuni dati di input); • Gravità 3: Malfunzione che non ha un impatto immediato sugli utenti, per esempio relativa a descrizioni non appropriate nelle maschere di input.
Unità di misura	Percentuale di difetti per unità di misura
Dati elementari da rilevare	• Errori durante i test di accettazione dell’applicazione di destinazione • Trouble-ticket relativi ad errori nell’applicazione di destinazione • Difettosità dell’applicazione di partenza
Periodo di riferimento	3 mesi dall’avviamento
Frequenza esecuzione misure	La misura viene effettuata due volte: al collaudo ed al termine del periodo di transizione osservazione in esercizio
Regole di campionamento	Vanno considerati tutti gli errori e tutte le chiamate pervenute nel periodo di transizione
Formula di calcolo	Dati necessari: • difettosità per unità di volume nell’applicazione di partenza (DIF1) • difettosità per unità di volume nell’applicazione di destinazione (DIF2) DIFE = DIF2 - DIF1 La difettosità è a sua volta: DIFi = NSDi AS NSDi = numero totale di anomalie rilevate nel periodo di riferimento (per gravità) AS = dimensione (KLOC, FP, ecc.)

Regole di arrotondamento	Il valore percentuale va arrotondato alla prima cifra decimale
Obiettivi (valori soglia)	DIFE ≤ 0 Il primo obiettivo è che la difettosità dell’applicazione di destinazione sia inferiore a quella dell’applicazione di partenza. Il secondo obiettivo è che i valori assoluti di difettosità dell’applicazione di destinazione (DIF2), dipendenti dalla classe di rischio e dalla gravità siano i seguenti: Classe di rischio Gravità Obiettivo A 1-2-3 DIF2=0 (nessuno difetto) B 1 DIF2=0 (nessuno difetto) B 2 DIF2<1% B 3 DIF2<2% C 1 DIF2<1% X 0 XXX0x0% X 0 XXX0x0%
Xxxxxxxxx	XX

Classe di fornitura	FORMAZIONE E ADDESTRAMENTO	Tabella II.S
Caratteristica / Sottocaratteristica	Efficacia
Indicatore/Misura	Efficacia delle tecnologie e delle metodologie didattiche – ETMD
Metodi e strumenti di misura	La rilevazione viene effettuata tramite il questionario di gradimento da somministrare alla fine dell’erogazione di ciascun corso, tramite l’item “Come valuta l’efficacia delle tecnologie e delle metodologie didattiche impiegate?”. Il giudizio viene dato su scala 1-10
Unità di misura	Numero
Dati elementari da rilevare	Livello di soddisfazione del partecipante
Periodo di riferimento	Fase di erogazione del servizio
Frequenza esecuzione misure	Tutte le edizioni dei corsi in cui risulta articolato il servizio formativo
Regole di campionamento	N.A.
Formula di calcolo	Valore medio dei giudizi espressi per singola edizione del corso
Regole di arrotondamento	Arrotondamento alla seconda cifra decimale
Obiettivi, valori soglia	Risultato atteso > 7
Eccezioni

Classe di fornitura	FORMAZIONE E ADDESTRAMENTO	Tabella II.T
Caratteristica / Sottocaratteristica	Efficacia
Indicatore/Misura	Efficacia del materiale didattico – EMD
Metodi e strumenti di misura	La rilevazione viene effettuata tramite il questionario di gradimento da somministrare alla fine dell’erogazione di ciascun corso, tramite l’item “In quale misura ritiene che il materiale didattico sia esaustivo rispetto ai contenuti trattati in aula?. Il giudizio viene dato su scala 1-10
Unità di misura	Numero
Dati elementari da rilevare	Livello di soddisfazione del partecipante
Periodo di riferimento	Fase di erogazione del servizio
Frequenza esecuzione misure	Tutte le edizioni dei corsi in cui risulta articolato il servizio formativo
Regole di campionamento	N.A.
Formula di calcolo	Valore medio dei giudizi espressi per singola edizione del corso
Regole di arrotondamento	Arrotondamento alla seconda cifra decimale
Obiettivi, valori soglia	Risultato atteso > 7
Eccezioni

Classe di fornitura	FORMAZIONE E ADDESTRAMENTO	Tabella II.U
Caratteristica / Sottocaratteristica	Efficacia
Indicatore/Misura	Efficacia didattica del docente – EDD
Metodi e strumenti di misura	La rilevazione viene effettuata tramite il questionario di gradimento da somministrare alla fine dell’erogazione di ciascun corso, tramite gli item “Come valuta il grado di efficacia (profondità e ampiezza dei contenuti) dei docenti nel trattare i temi/argomenti del corso?” e “Come valuta la chiarezza espositiva dei docenti nel trattare i temi/argomenti del corso?”. Il giudizio, dato su scala 1-10 su ciascuno dei quesiti, risulta dalla media aritmetica delle due risposte.
Unità di misura	Numero
Dati elementari da rilevare	Livello di soddisfazione del partecipante
Periodo di riferimento	Fase di erogazione del servizio
Frequenza misure	Tutte le edizioni dei corsi in cui risulta articolato il servizio formativo
Regole di campionamento	N.A.
Formula di calcolo	Valore medio dei giudizi espressi per singola edizione del corso
Regole di arrotondamento	Arrotondamento alla seconda cifra decimale
Obiettivi, valori soglia	Risultato atteso > 7
Eccezioni

Classe di fornitura	FORMAZIONE E ADDESTRAMENTO	Tabella II.V
Caratteristica / Sottocaratteristica	Funzionalità / Adeguatezza
Indicatore/Misura	Adeguatezza delle attrezzature didattiche – AAD
Metodi e strumenti di misura	La rilevazione viene effettuata tramite il questionario di gradimento da somministrare alla fine dell’erogazione di ciascun corso, tramite gli item “Come valuta l’adeguatezza delle aule e delle attrezzature didattiche?” e “Come valuta l’adeguatezza dei servizi logistici previsti (accoglienza, assistenza tecnica, …)?”. Il giudizio, dato su scala 1-10 su ciascuno dei quesiti, risulta dalla media aritmetica delle due risposte.
Unità di misura	Numero
Dati da rilevare	Livello di soddisfazione del partecipante
Periodo di riferimento	Fase di erogazione del servizio
Frequenza misure	Tutte le edizioni dei corsi in cui risulta articolato il servizio formativo
Campionamento	N.A.
Formula di calcolo	Valore medio dei giudizi espressi per singola edizione del corso
Arrotondamento	Arrotondamento alla seconda cifra decimale
Obiettivi, valori soglia	Risultato atteso > 7
Eccezioni

Classe di fornitura	FORMAZIONE E ADDESTRAMENTO	Tabella II.W
Caratteristica / Sottocaratteristica	Soddisfazione
Indicatore/Misura	Accettazione corso / modulo didattico tradizionale – ACT
Metodi e strumenti di misura	Elaborazione indicatori relativi all’erogazione della singola edizione del corso/modulo (EDD, AAD)
Unità di misura	Numero
Dati elementari da rilevare	Livello di soddisfazione del partecipante
Periodo di riferimento	Fase di erogazione del servizio
Frequenza esecuzione misure	Tutte le edizioni dei corsi in cui risulta articolato il servizio formativo
Regole di campionamento	N.A.
Formula di calcolo	ACT = 0,3*EDD+0,3*AAD+0,2*ETMD+0,2*EMD Media pesata degli indicatori relativi a: • EDD: Efficacia didattica del docente • AAD: Adeguatezza attrezzature didattiche • ETMD:Efficacia delle tecnologie e delle metodologie didattiche • EMD: Efficacia materiale didattico
Regole di arrotondamento	Arrotondamento alla seconda cifra decimale
Obiettivi, valori soglia	ACT > 6
Eccezioni

Classe di fornitura	ASSISTENZA IN REMOTO E IN LOCALE	Tabella II.X
Caratteristica /Sottocaratteristica	SODDISFAZIONE
Indicatore/Misura	Percentuale di utenti soddisfatti del servizio reso – CSA
Sistema di gestione delle misure	Misurazione del livello di soddisfazione come rapporto tra la qualità attesa dall’utenza e quella percepita. La qualità effettiva del servizio è misurata attraverso interviste a cui un campione di utenti, nel rispetto dell’art. 13 della legge 196 sulla Privacy, accetta di rispondere. La rilevazione avviene attraverso una procedura automatica che seleziona un campione di utenti relativi ai contatti gestiti nel giorno precedente e tracciati attraverso l’applicativo utilizzato nel servizio dagli operatori. Ogni utente selezionato viene contattato tramite un sistema automatico IVR all’interno della fascia oraria compresa tra le 10.30 e le 16.30 e, per ogni parametro che contribuisce a definire la qualità del servizio reso, gli viene chiesto di esprimere la sua valutazione digitando sulla tastiera del telefono un numero compreso tra 0 e 9 dove 0 indica un servizio non soddisfacente, 5 un servizio sufficiente e 9 un servizio ottimo.
Unità di misura	Percentuale
Dati elementari da rilevare	Per ogni contatto viene richiesta la valutazione dei seguenti parametri: • RO = risposta operatore (l’operatore risponde in modo cortese e comprensibile); • PRI = personalizzazione del rapporto con l’Utente (l’operatore utilizza una forma di accoglienza personalizzata all’interlocutore (sig.; sig.ra), fornisce il proprio identificativo e la ragione sociale del Centro di Contatto e/o del Committente); • COI = correttezza operativa Inbound (rispetto dei tempi concordati con l’interlocutore per il contatto successivo); • COR = correttezza dell’informazione fornita dall’operatore; • NMI = numero medio di informazioni fornite in ciascuna chiamata; • COM = commiato (l’operatore ha ringraziato per aver chiamato e ha salutato); • PRT = proattività, ovvero capacità dell’operatore di proporre soluzioni alternative nel caso di richieste complesse o non standard; • CAR = capacità relazionale dimostrata nel corso della chiamata.
Periodo di riferimento	Una settimana
Frequenza misura	2 volte l’anno
Regole di campionamento	La procedura automatica provvede ad escludere: • contatti non utilizzabili (chiamate nulle, numeri di telefono non identificabili); • utenti che non hanno dato il loro consenso ad essere contattati; • utenti già contattati negli ultimi 3 mesi.
Formula di calcolo	CSA = ((mRO+mPRI+mCOI+mCOR+mNMI+mCOM+mPRT+mCAR)/8 Dove mRO, mPRI, mCOI, mCOR, mNMI, mCOM, mPRT, mCAR rappresentano la media aritmetica settimanale per ciascun parametro di determinazione del CSI. I parametri possono assumere valori compresi tra 0 e 5.
Arrotondamento	Il CSA si arrotonda alla prima cifra decimale.
Obiettivi (valori soglia)	CSA ≥ 4.
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento stabilito contrattualmente

Classe di fornitura	ASSISTENZA IN REMOTO E IN LOCALE	Tabella II.Y
Caratteristica /Sottocaratteristica	Efficacia
Indicatore/Misura	Chiamate risolte – CR
Sistema di gestione delle misure	L’efficacia della prestazione viene valutata come percentuale di chiamate chiuse. Viene utilizzato il sistema automatico di gestione dei contatti (TTS o CRM), in grado di raccogliere ed elaborare i dati elementari. Per tutte le unità elementari di servizio (chiamate) nel periodo di osservazione si deve contare il numero di chiamate chiuse. La finestra temporale da considerare varia a seconda delle esigenze dell’Amministrazione ed è definita contrattualmente.
Unità di misura	Percentuale
Dati elementari da rilevare	• Casi smistati (CS); • Casi chiusi (C2).
Periodo di riferimento	3 mesi solari consecutivi
Frequenza esecuzione misure	4 volte l’anno
Regole di campionamento	Vanno considerati tutti i casi aperti nel periodo di osservazione
Formula di calcolo	Dati necessari: numero dei casi assegnati (CS) ed il numero dei casi chiusi al 2° livello (C2) CR2 = C2 /CS * 100
Regole di arrotondamento	• CR2 va arrotondato al punto percentuale sulla base del primo decimale: - al punto % per difetto se la parte decimale è ≤ 0,5; - al punto % per eccesso se la parte decimale è > 0,5.
Obiettivi (valori soglia)	CR2 ≥ 65%
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento stabilito contrattualmente Le penali non sono applicabili se i volumi del servizio eccedono del 25% i volumi previsti contrattualmente.

Classe di fornitura	ASSISTENZA IN REMOTO E IN LOCALE	Tabella II.Z
Caratteristica /Sottocaratteristica	EFFICIENZA
Indicatore/Misura	Accessibilità del servizio telefonico – ATS
Sistema di gestione delle misure	Misurazione del rapporto tra il tempo in cui tutte le linee assegnate per l’accesso al servizio sono occupate ed il tempo totale dichiarato per l’orario del servizio.
Unità di misura	Percentuale
Dati elementari da rilevare	• Minuti di occupazione contemporanea di tutti i canali di accesso dedicati al servizio nell’arco del periodo di osservazione • Minuti totali di servizio previsti
Periodo di riferimento	Mese
Frequenza esecuzione misure	Mensile
Regole di campionamento	Vanno considerate tutte le linee dedicate al servizio preso in esame
Formula di calcolo	ATS = (TO /MT)*100 Dove TO è il tempo totale di occupazione di tutte le linee assegnate al servizio, MT è il numero di minuti totali di servizio previsti.
Regole di arrotondamento	ATS si arrotonda alla prima cifra decimale.
Obiettivi (valori soglia)	ATS ≤ 3 % (valore di riferimento indicato nella norma UNI 11200). Tale valore deve essere rettificato in base alle esigenze specifiche
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento stabilito contrattualmente Le penali non sono applicabili se i volumi del servizio eccedono del 25% i volumi previsti contrattualmente.

Art. 15 - Direzione dei lavori

L’Aggiudicatario dovrà predisporre e mantenere costantemente aggiornata la pianificazione di tutte le attività, con la seguente articolazione:

• Piano di Lavoro Generale (PLG) che comprende la descrizione e la pianificazione delle attività di carattere generale, il piano di affiancamento ad inizio fornitura e il piano di trasferimento del know how;

• Piano della Qualità (PdQ) che comprende la descrizione e la pianificazione delle attività di assicurazione della qualità;

A fronte di una nuova pianificazione autorizzata dalla Stazione Appaltante, dovrà essere predisposta una nuova versione dei relativi Piani.

La stazione Appaltante dovrà approvare tutti i Piani sopra citati ed ogni loro aggiornamento. Non è prevista approvazione per tacito assenso.

Dopo la prima approvazione, sarà cura dell’Aggiudicatario comunicare tempestivamente e concordare ogni eventuale rimodulazione della pianificazione delle attività, aggiornando e riconsegnando alla stazione Appaltante il relativo Piano di Lavoro secondo i vincoli temporali di cui al paragrafo successivo.

15.1) Piani di lavoro

Il Piano di Lavoro generale (PLG) comprensivo del piano di subentro a fine fornitura, dovrà essere consegnato entro 10 giorni lavorativi dalla data di inizio progetto.

Il Piano di lavoro delle attività continuative (PLA) relativo al primo anno di assistenza sistemistica dovrà essere consegnato entro 60 giorni dalla data di inizio progetto.

Per le attività svolte in modalità progettuale il Piano di Progetto dell’Obiettivo (PLO) relativo al singolo obiettivo dovrà essere consegnato entro la fase di Definizione o secondo quanto previsto dal ciclo di vita adottato in funzione delle specifiche caratteristiche dell’Obiettivo. Dovrà contenere, in fase di Definizione, l’indicazione dell’esatta composizione del team che si intende impiegare sull’Obiettivo con riferimento ai curriculum vitae (CV) consegnati, alla figura professionale, alla percentuale stimata di impiego. Eventuali modifiche di questi dati genereranno un aggiornamento del Piano che dovrà essere approvato dalla Stazione Appaltante.

Mensilmente entro 5 giorni lavorativi dal termine del mese solare di riferimento, l’Aggiudicatario dovrà aggiornare il Piano di Lavoro Generale e predisporre la sezione Stato avanzamento lavori del mese in chiusura (per area ed attività). I piani così aggiornati sono soggetti all’approvazione da parte della stazione Appaltante, unitamente al Rendiconto di utilizzo delle risorse.

Inoltre si sottolinea che per qualunque ripianificazione dovrà essere riconsegnato il Piano di Lavoro interessato entro il termine di 5 giorni lavorativi dall’approvazione della ripianificazione stessa.

Ogni scostamento rispetto al piano deve essere comunicato e verbalizzato a cura del Aggiudicatario ed espressamente approvato dalla Stazione Appaltante.

15.2) Stato Avanzamento lavori (SAL)

L’Aggiudicatario dovrà mantenere aggiornato lo stato di avanzamento dei lavori relativamente ai Piani di Lavoro approvati, fornendo tempestivamente indicazioni sulle attività concluse ed in corso, esplicitandone la percentuale di avanzamento, su eventuali rischi/criticità/ritardi, su eventuali impatti dei rischi/criticità, su azioni di recupero e razionali dello scostamento, sulle attività in servizio esteso ed in reperibilità.

15.3) Consuntivazione

La consuntivazione delle attività svolte deve essere consegnata dall’Aggiudicatario con periodicità trimestrale, entro il quindicesimo giorno successivo al periodo al quale si riferisce; quindi viene sottoposta alla approvazione formale dell’Amministrazione, la quale ha facoltà di richiedere, se necessario, modifiche e/o integrazioni dei suoi contenuti.

La consuntivazione ha lo scopo di rendicontare le attività svolte durante il periodo di riferimento e di rappresentare lo stato di avanzamento delle stesse in conformità a quanto contenuto nei Piani di Lavoro ed il rispetto dei livelli di

servizio. Essa si articola nella sezione Stato Avanzamento Lavori di ciascun Piano di Lavoro relativamente a ciascuna area applicativa e ciascun servizio e nel documento Rapporto dei Livelli di Servizio.

La rendicontazione sarà articolata come specificato di seguito:

• descrizione degli interventi autorizzati, in corso e completati nel periodo;

• elenco nominativo del personale impiegato dal Aggiudicatario con l’indicazione del profilo professionale;

• dettaglio dei giorni o frazioni di giorno impiegati da ciascuna risorsa per ogni attività svolta nel periodo di riferimento;

• prodotti/deliverable consegnati ed approvati;

• stato di avanzamento degli interventi e risorse consuntivate rispetto a quanto pianificato, criticità rilevate e proposte di risoluzione;

• misura dei livelli di servizio applicabili ed evidenza di eventuali non conformità e relative penali. Dovranno, in ogni caso, essere riportate nello Stato Avanzamento Lavori relativo al Piano di Lavoro generale:

• la situazione complessiva delle risorse impiegate dall’inizio del contratto in riferimento ai massimali contrattuali per servizio e per tipologia professionale;

• il corrispettivo maturato a fronte delle attività svolte nel periodo a cui si riferisce la rendicontazione, articolata per servizio;

• il totale dei corrispettivi erogati dall’inizio del contratto a fronte dei massimali contrattuali.

Per quanto riguarda i livelli di servizio la rendicontazione dovrà avvenire secondo modalità e report il cui dettaglio sarà concordato con La Stazione Appaltante.

All’Aggiudicatario è richiesta la predisposizione di un ambiente di monitoraggio, in tempo reale dei sistemi/servizi e conseguenti SLA per la consultazione e verifica da parte di personale autorizzato dalla Stazione Appaltante. La soluzione proposta dovrà essere riportata nella proposta tecnica del Aggiudicatario.

15.4) Regolare esecuzione attività di sviluppo software

Per le attività di sviluppo software, a seguito della verifica dei prodotti di fase, la struttura tecnica rilascerà un attestato di buon esito.

Le attività di collaudo formale, da parte della commissione all’uopo nominata, potranno avere luogo solo se accompagnate dagli attestati di buon esito rilasciati dalla struttura tecnica competente nelle fasi di Definizione, Analisi, Disegno, Realizzazione e Collaudo (sia funzionale che in ambiente di pre-esercizio).

Soltanto a seguito dell’esito positivo del collaudo formale e del corretto passaggio in produzione, che è parte integrante delle attività progettuali, potrà avvenire la regolare esecuzione delle attività.

15.5) Pianificazione

Si richiede all’Aggiudicatario di predisporre il “Piano di progetto” e il “Piano delle attività” da presentarsi come di seguito indicato:

A. in sede di presentazione dell’offerta (contenuto nella busta – Offerta tecnica);

B. alla data di inizio progetto (1/05/2014).

Per quanto riguarda la documentazione di cui al punto A), è necessario che essa rappresenti in linea di massima le risorse che si intendono dedicare al progetto, il tipo di organizzazione, i profili professionali individuati, i ruoli, le responsabilità e le metodologie adottabili.

Per quanto riguarda la documentazione di cui al punto B), l’Aggiudicatario dovrà fornire con ampio dettaglio, il “Piano di progetto” e il “Piano delle attività” contenenti le linee guida per l’esecuzione del progetto. Entrambi i documenti saranno modificabili in caso di nuove e significative informazioni assunte in itinere.

Contenuto minimo del Piano di progetto:

• sintesi delle caratteristiche del progetto (requisiti e/o obiettivi che il progetto si prefigge di soddisfare e/o raggiungere);

• descrizione del prodotto e/o del servizio che il progetto dovrà realizzare per soddisfare i requisiti del contratto;

• durata complessiva (inizio – fine);

• eventuali vincoli;

• eventuali risorse che devono essere rese disponibili dall’Amministrazione;

• indicazione del responsabile di progetto e dell’organizzazione;

• le entità organizzative coinvolte;

• le risorse assegnate ed i relativi ruoli e profili professionali;

• le interfacce organizzative e tecniche;

• la scomposizione dei deliverable contrattuali al fine di definire unità di lavoro al livello di dettaglio idoneo ad esercitare un efficace controllo in fase di esecuzione;

• la baseline per misurare le prestazioni di tempi e costi;

• la definizione della periodicità con cui verrà rilevato lo stato di avanzamento lavori (SAL), gli indicatori da utilizzare per misurare l’avanzamento, le date programmate di svolgimento di Riesami e Verifiche;

• le principali milestone, ossia l’indicazione dei momenti a cui corrispondono fatti rilevanti dal punto di vista gestionale e che costituiscono dei punti di controllo essenziali per la verifica del corretto avanzamento dei lavori;

• i problemi aperti e/o le decisioni in pending;

• le modalità per la gestione dei cambiamenti.

Contenuto minimo del Piano delle attività:

• la stima dei costi di ogni attività (unità di lavoro);

• la programmazione temporale delle attività;

• le assegnazioni di responsabilità per ciascuna attività.

I piani di cui trattasi al punto B), dovranno essere presentati all’Amministrazione con cadenza trimestrale e comunque ogni volta che subiranno una modifica affinché possano essere validati e approvati.

15.6) Esecuzione, controllo e rendicontazione

L’Aggiudicatario dovrà svolgere le attività di sviluppo e manutenzione evolutiva nel rispetto del Piano di progetto approvato dall’Amministrazione per ciascun trimestre.

Con riferimento alle attività pianificate per ciascun trimestre, dovrà allegare al Piano di progetto un “Rapporto di riepilogo” delle prestazioni effettuate nel trimestre precedente ovvero, un documento che consenta di controllare lo stato delle attività. Lo stesso dovrà indicare, rispetto ai dati di pianificazione contenuti nel Piano di progetto a cui il Rapporto si riferisce:

• lo stato delle attività relative allo sviluppo e alla manutenzione evolutiva, con l’indicazione dei tempi effettivi di attivazione di ciascuna fase del ciclo di sviluppo, i deliverables prodotti.

• l’andamento complessivo del progetto in termini di rispetto dei tempi, il riepilogo delle risorse impiegate, le eventuali criticità e, ove possibile, le relative azioni correttive previste o in essere.

Il rapporto di riepilogo approvato dall’Amministrazione autorizzerà il pagamento dei corrispettivi, previa applicazione di eventuali penali a fronte del mancato rispetto dei livelli di qualità, come descritto nel successivo Art. 19.

15.7) Migrazione dei dati

Nel caso in cui l’Aggiudicatario dovesse sostituire una o più base dati attualmente in uso la prima attività da svolgere è il recupero degli archivi informatici (supportato da opportuno diagramma di GANTT) entro i tempi indicati nel crono programma (Art. 3).

L’Aggiudicatario deve certificare la correttezza dei dati trasferiti; per ciascuna procedura o area di intervento, il corretto trasferimento dei dati deve essere verificato in contraddittorio tra l'Aggiudicatario e i responsabili degli uffici, mediante un controllo a campione tra la procedura attualmente in uso (che dovrà essere mantenuta in funzione almeno fino a sei mesi oltre il collaudo positivo dell’applicazione) e quella di nuova installazione, con l'elaborazione di un certificato finale o con qualunque metodo richiesto dal responsabile dell'ufficio. Alla fine delle attività di recupero dei dati, tutte le informazioni contenute nei sistemi informativi in uso devono essere contenute nelle nuove procedure.

I servizi di migrazione si articolano nelle seguenti macro attività:

- presa in carico tecnica dell’applicazione con eventuale ricostruzione della documentazione mancante (inventario delle componenti software, acquisizione della conoscenza, ricostruzione dei modelli logico / fisico dei dati, misurazione della difettosità residua);

- definizione del nuovo modello architetturale;

- esecuzione migrazione dei dati sul nuovo ambiente, con conseguente eliminazione di errori/ridondanze;

- documentazione dei dati della nuova applicazione.

Le fasi della migrazione dati e dei prodotti sono elencati nella seguente tabella

Migrazione dati	Prodotti	Profilo di competenza Responsabile
Analisi dei requisiti	1. Specifiche dei requisiti 2. Piano di Progetto	Responsabile di Basi di Dati
Progettazione tecnica migrazione	3. Progetto tecnico	Responsabile di Basi di Dati
Progettazione applicativa migrazione	4. Specifica funzionale	Responsabile di Basi di Dati
Progettazione Test e Collaudo	5. Specifiche di test 6. Specifiche di collaudo	Tecnico di Collaudo e Integrazione di Sistemi
Realizzazione migrazione	7. Programmi di migrazione 8. Dati migrati	Responsabile di Basi di Dati
Predisposizione del sistema	9. Infrastruttura hardware e software di collaudo ed esercizio 10. Rapporto di esecuzione dei test	Tecnico di Collaudo e Integrazione di Sistemi
Qualificazione finale	11. Comunicazione pronti al collaudo 12. Rapporto di esecuzione dei test	Tecnico di Collaudo e Integrazione di Sistemi
Collaudo	13. Codice software, dati migrati in versione definitiva	Tecnico di Collaudo e Integrazione di Sistemi

15.8) Piano di Qualità

Al fine di salvaguardare il Sistema di Qualità in vigore, l’Aggiudicatario dovrà produrre, aggiornare, gestire e consegnare all’Amministrazione un piano di qualità che:

a) fornisca lo strumento per collegare i requisiti specifici dei servizi contrattualmente richiesti con le procedure generali del Sistema Qualità già esistenti;

b) espliciti le disposizioni organizzative e metodologiche adottate allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;

c) dettagli i metodi di lavoro messi in atto dal Aggiudicatario facendo riferimento o a procedure relative al proprio Sistema e per questo descritte nel Manuale Qualità, o a procedure sviluppate per lo specifico contrattuale, a supporto delle attività in esso descritte, in questo caso da allegare al piano;

d) indichi, in particolare, gli strumenti e le procedure utilizzate per garantire la gestione delle configurazioni;

e) indichi, tra l’altro:

• gli obiettivi di qualità;

• le metriche per la misura della qualità effettivamente fornita, a fronte di quella attesa, inclusi i valori di soglia per le misure da svolgere che tengano conto delle indicazioni espresse in merito ai livelli di servizio di cui al art 14.2;

• i controlli da svolgere internamente per assicurare la qualità della fornitura e i relativi piani di verifica, incluse le specifiche responsabilità riguardo alla gestione delle non conformità, alla gestione delle configurazioni ed al controllo delle sub-forniture;

• metodi, tecniche, strumenti, risorse, competenze previste dal Aggiudicatario per assicurare la qualità della fornitura in corso d’opera;

f) garantisca il corretto e razionale evolversi delle attività contrattualmente previste e la trasparenza e tracciabilità di tutte le azioni messe in atto dalle parti in causa.

Il piano di qualità dovrà essere predisposto secondo le prescrizioni della norma EN ISO 10005.

15.9) Gestione delle configurazioni

Al fine di garantire l’integrità del patrimonio di software applicativo dell’Amministrazione l’Aggiudicatario dovrà realizzare e gestire un ambiente di collaudo, distinto da quello di sviluppo e dall’ambiente di esercizio, in cui memorizzare tutto il codice eseguibile di tutte le applicazioni realizzate nel corso del contratto. Sono espressamente esclusi da questo trattamento tutti i prodotti normalmente reperibili sul mercato (Software standard) e di cui l’Amministrazione o lo stesso Aggiudicatario ne detengono licenze d’uso a vario titolo (ad esempio, database, emulatori di terminale, ecc.). Sono invece inclusi in questo trattamento tutte le personalizzazioni eventualmente effettuate a prodotti di mercato. L’obiettivo è di verificare la compatibilità ed integrazione, nonché gli impatti delle modifiche e/o degli aggiornamenti effettuati.

Ogni modifica a livello architetturale, di ambiente o di prodotto standard, dovrà essere testata in termini di compatibilità e integrazione prima di essere rilasciata in produzione. L’Aggiudicatario, utilizzando l’ambiente di collaudo da sé predisposto, verificherà l’integrazione, la coesistenza e, più in generale, gli effetti degli aggiornamenti, dei nuovi prodotti e dei processi di gestione prima dell’installazione.

L’ambiente sarà inoltre utilizzato per l’esecuzione dei test delle modifiche derivanti dalla manutenzione delle applicazioni in esercizio e sarà utilizzato, su richiesta e compatibilmente con le attività in corso, per test da parte dell’Amministrazione.

L’Aggiudicatario dovrà predisporre e consegnare all’Amministrazione, entro trenta giorni solari dalla sottoscrizione dall’inizio del progetto, un Piano di gestione delle configurazioni.

L’Aggiudicatario dovrà consegnare all’amministrazione, contestualmente alla presentazione delle “Specifiche funzionali” e delle “Specifiche di collaudo” di cui all’Art. 16, le “Specifiche dell’ambiente di collaudo”, necessarie per consentire la predisposizione e l’adeguamento dell’ambiente di collaudo.

L’Aggiudicatario inoltre dovrà fornire all’Amministrazione contestualmente ai precedenti documenti un manuale in cui descrive dettagliatamente come interagire con il Sistema Informativo realizzato. Nel caso in cui la documentazione fornita risulti poco chiara o non sufficiente all’espletamento del compito designato l’Amministrazione si riserva la possibilità di chiedere anche in un secondo momento chiarimenti e/o approfondimenti che il Aggiudicatario dovrà rendere disponibili entro 5 (giorni) lavorativi. In caso di ritardi verranno applicate le penali di cui all’Art. 19.

Art. 16 – Progettazione del test e Collaudi

Le caratteristiche delle attività di test e collaudo sono le seguenti:

Test

• viene pianificato e sviluppato in fase di analisi e progettazione tecnica, prima della realizzazione;

• viene eseguito durante ed alla fine dello sviluppo;

• si articola in test di unità, di integrazione e di sistema;

• ha connotati sia di verifica che di validazione;

• viene eseguito in un ambiente di prova;

• deve garantire la copertura completa dei requisiti;

• deve garantire la densità dei test prevista dagli accordi contrattuali rispetto alla dimensione del software;

• viene eseguito dal fornitore, generalmente da un gruppo dedicato (gruppo test);

• necessita di specifiche di test.

Collaudo

Il collaudo viene eseguito dopo il completamento dei test ed è orientato all’accettazione formale; ha connotati di validazione e deve garantire la copertura completa dei requisiti.

Si articola in due fasi:

1. una prima fase di qualificazione finale, condotta dal fornitore, al fine di assicurare la corretta predisposizione del sistema e dell’ambiente di collaudo.

2. una seconda fase a cura dell’amministrazione con il supporto del fornitore; viene eseguito dall’Amministrazione, che può delegare a ciò una terza parte; necessita di specifiche di collaudo.

L’attività di test prevede la pianificazione, progettazione ed esecuzione dei test per la verifica del corretto funzionamento del software e l’aderenza ai requisiti, ed include, quando previsto, anche la loro automazione e gestione tramite appositi strumenti di test.

La progettazione del test e collaudo inizia con la fase di analisi ed è parte integrante del processo di progettazione tecnica ed applicativa. Consiste nella pianificazione e progettazione dei test eseguiti dal Fornitore prima del rilascio al collaudo, per garantire che quanto realizzato sia conforme ai requisiti indicati nelle Specifiche dei Requisiti e agli obiettivi fissati nel Piano della Qualità.

I prodotti di questa attività sono le Specifiche di test e le Specifiche di collaudo. Le Specifiche di Test sono utilizzate dal fornitore per l’esecuzione dei propri cicli di prove, mentre le Specifiche di Collaudo sono il riferimento per l’Amministrazione per le attività di collaudo.

Le specifiche di test, costituite dal Piano di Test e dalla Specifica di Test, sono un deliverable contrattuale, necessario all’amministrazione per verificare la corretta allocazione di risorse ed impostazione del processo di test (e più in generale di verifica e validazione) da parte del fornitore, dove le fasi di pianificazione, progettazione, preparazione ed esecuzione del test si devono affiancare ed integrare alle corrispettive fasi di realizzazione della fornitura.

Il Piano di Test deve contenere gli aspetti organizzativi del test, le risorse ed i ruoli, gli obiettivi, le tecniche, la strategia e le tipologie di test previste, i requisiti e vincoli per l’ambiente di test, l’identificazione degli oggetti sottoposti a test e dei casi di test, da realizzare sulla base delle specifiche dei requisiti e della specifica funzionale.

Il Piano di Test accompagna la fornitura lungo tutto il ciclo di vita: si prevede che il piano di test sia fornito in prima versione nelle fasi iniziali del progetto (analisi), per poi essere implementato ed arricchito durante le fasi di progettazione e di realizzazione.

I test pianificati e poi realizzati e documentati nella Specifica di Test, devono possedere elevate caratteristiche di qualità e riusabilità, al fine di garantire il massimo livello di qualità nel software e consentire un loro riutilizzo in successivi ricicli e futuri interventi di manutenzione.

Deve essere inoltre sempre garantita la tracciabilità dei test con il documento di Specifiche funzionali e Specifiche dei requisiti e la coerenza con i requisiti stessi.

Le Specifiche di collaudo rappresentano un documento, o insieme di documenti, il cui scopo è definire il test per la validazione dei requisiti espressi nei documenti contrattuali e meglio dettagliati nella Specifica dei requisiti.

L’approvazione formale e completa di tutti i prodotti dell’ attività, da parte dell’Amministrazione, è propedeutica alle attività successive.

La tabella seguente riassume gli adempimenti dell’attività di Installazione e Collaudo.

Obiettivi	Pianificare, eseguire e verificare le attività pre - avvio in produzione del sistema.
Prerequisiti per l'avvio della fase	• Test d’Integrazione accettato; • Processi di business configurati.
Principali input	• Ambiente di test configurato e disponibile; • Ambiente di produzione disponibile per le conversioni; • File e programmi di conversione completati e testati; • Documentazione utente.
Principali attività	• Trasporto configurazione nell’ambiente di Produzione; • Conversione dati; • Verifica dati convertiti; • Attivazione interfacce sull’ambiente di Produzione; • Attivazione degli enhancement sull’ambiente di Produzione; • Formazione utenti finali; • Svolgimento delle attività per l’inizio dell’utilizzo produttivo dei sistemi; • Test per il caricamento dati; • Conduzione dei test per verificare il corretto dimensionamento dell’ambiente di produzione; • Formazione degli utenti finali; • Riorganizzazione del team di lavoro in vista della partenza (istituzione di un help desk e problematiche di manutenzione del sistema); • Prenotazione dei servizi di assistenza per l’entrata in produzione; • Travaso dei dati dai vecchi sistemi, integrati con eventuali caricamenti manuali; • Verifica della correttezza dei dati caricati; • Avvio/Utilizzo produttivo del sistema.
Principali input	• Ambiente di test configurato e disponibile; • Ambiente di produzione disponibile per le conversioni; • Specifiche di test e specifiche di collaudo; • File e programmi di conversione completati e testati; • Documentazione utente.
Principali output	• Sistema di Produzione predisposto e configurato; • Dati convertiti e verificati sul Sistema di Produzione; • Interfacce attivate; • Collaudo ed accettazione (Xxxxxxx di accettazione del collaudo)

Il collaudo verrà effettuato da una Commissione nominata con apposito provvedimento dall’Amministrazione e composta da un massimo di 5 membri.

Le operazioni di collaudo consisteranno nella verifica delle funzionalità realizzate attraverso gli interventi di sviluppo e di manutenzione.

Le attività di collaudo verranno svolte dalla Commissione di cui sopra, in contraddittorio con un rappresentante designato dall’Aggiudicatario.

Le “Specifiche di collaudo” dovranno essere sottoposte preventivamente all’Amministrazione per accettazione entro il termine indicato nel Piano di progetto e comunque entro i venti giorni solari precedenti la data prevista di rilascio della dichiarazione di pronti al collaudo.

Tale documento, una volta accettato dall’Amministrazione, rappresenterà una guida per la Commissione di collaudo, che potrà effettuare, comunque, tutte le prove che riterrà necessarie. Eventuali ulteriori prove che si deciderà di effettuare dovranno essere verbalizzate e costituiranno un addendum alle norme di collaudo sopra citate.

Secondo i tempi indicati nel Piano di progetto approvato dall’Amministrazione, l’Aggiudicatario comunicherà per iscritto il “pronti al collaudo” e contestualmente consegnerà all’Amministrazione la dichiarazione di conformità alle norme specificate. Xxx il collaudo non risulti positivo in tutto o in parte, l’Aggiudicatario dovrà rimuovere i malfunzionamenti riscontrati nei 20 giorni solari successivi.

La Stazione Appaltante sottopone comunque ad un periodo di prova i programmi, avvalendosi del giudizio dei responsabili dei vari uffici che li hanno in uso. L’Ufficio segnalerà immediatamente gravi anomalie e con cadenza mensile i problemi rilevati sull’uso del programma gestionale. Il periodo di prova è stabilito in trenta giorni dalla data del processo verbale di installazione e comunque non potrà protrarsi oltre la data del 31/12/2014 salvo diversa volontà dell’Amministrazione.

Nel caso in cui, al termine del periodo di prova, la Stazione Appaltante accetti i programmi, verrà redatto apposito processo verbale sottoscritto dalle parti.

Entro sei mesi dall’entrata in produzione del Sistema Informativo la Stazione Appaltante, su indicazione degli utenti, può segnalare l’esistenza di eventuali requisiti aggiuntivi non contemplati in fase di analisi, senza alcun aggravio di costi.

Qualora in sede di collaudo si riscontrino difetti o malfunzionamenti pregiudizievoli al servizio, il collaudo, così come attestato dalla sottoscrizione del relativo verbale, avrà valore negativo. In questa ipotesi l’Aggiudicatario sarà tenuto alla eliminazione dei difetti o delle carenze ad essa imputabili entro 20 giorni solari dal giorno di collaudo negativo dando comunicazione scritta all’Amministrazione di essere disponibile al nuovo collaudo.

Qualora trascorsi tali 20 giorni il servizio non sia disponibile per il collaudo, ovvero le nuove prove di collaudo risultino negative, l’Amministrazione ha la facoltà di applicare le penali di cui al successivo art. 19 del presente CSA.

Art. 17 - Ponderazione finanziaria dei moduli

In considerazione del fatto che la gara in oggetto ha come obiettivo la realizzazione di un Sistema Informativo Integrato che si comporrà di tre moduli la cui gestione amministrativo-contabile è rimessa a tre Unità Organizzative distinte, è necessario individuarne il “peso” singolo al fine di imputare correttamente le risorse finanziarie e le relative competenze degli uffici per gli adempimenti consequenziali. In ragione delle esigenze sopra richiamate, la ponderazione è stata cosi definita:

1. Modulo tributario 40% del valore economico dell’offerta presentata dall’Aggiudicatario;

2. Modulo demografico 35% del valore economico dell’offerta presentata dall’Aggiudicatario;

3. Modulo finanziario 25% del valore economico dell’offerta presentata dall’Aggiudicatario;

I valori cosi individuati sono omnicomprensivi di tutte le voci imputabili al singolo modulo (es. costo di progettazione, formazione, hardware necessario, etc …)

Art. 18 - Modalità di fatturazione e prezzi

Anno 2014: il pagamento relativo al primo anno di attività, caratterizzato dalla progettazione, dalla formazione del personale, dalle attività di verifica e collaudo funzionali alla messa in produzione e dalla fornitura dell’hardware necessario, sarà corrisposto in un’unica soluzione solo ad esito positivo del collaudo di tutti i moduli da completarsi, salvo eccezioni, entro il 31/12/2014.

Anni successivi: il pagamento per i successivi anni di contratto sarà posticipato e semestrale. L’Aggiudicatario emetterà ogni semestre tre fatture imputabili ai tre moduli di cui trattasi nel rispetto della “ponderazione finanziaria” descritta all’art. 17 e secondo lo schema che segue:

Anno	Valore annuale appalto	Valore dei moduli	Liquidazione
2014	11,00% dell’importo offerto in sede di gara	Tributario: 40% (di 11,00%) Demografico: 35% (di 11,00%) Finanziario: 25% (di 11,00%)	Entro il 31/12/2014 Se positivo l’esito del collaudo del SI
2015	14% dell’importo offerto in sede di gara	Tributario: 40% (di 14,00%) Demografico: 35% (di 14,00%) Finanziario: 25% (di 14,00%)	(50% del valore di ogni modulo) 1° semestre: entro il 30/06/2015 2° semestre: entro il 31/12/2015
2016	15% dell’importo offerto in sede di gara	Tributario: 40% (di 15%) Demografico: 35% (di 15%) Finanziario: 25% (di 15%)	(50% del valore di ogni modulo) 1° semestre: entro il 30/06/2016 2° semestre: entro il 31/12/2016
2017	15% dell’importo offerto in sede di gara	Tributario: 40% (di 15%) Demografico: 35% (di 15%) Finanziario: 25% (di 15%)	(50% del valore di ogni modulo) 1° semestre: entro il 30/06/2017 2° semestre: entro il 31/12/2017
2018	15% dell’importo offerto in sede di gara	Tributario: 40% (di 15%) Demografico: 35% (di 15%) Finanziario: 25% (di 15%)	(50% del valore di ogni modulo) 1° semestre: entro il 30/06/2018 2° semestre: entro il 31/12/2018
2019	15% dell’importo offerto in sede di gara	Tributario: 40% (di 15%) Demografico: 35% (di 15%) Finanziario: 25% (di 15%)	(50% del valore di ogni modulo) 1° semestre: entro il 30/06/2019 2° semestre: entro il 31/12/2019
2020	15% dell’importo offerto in sede di gara	Tributario: 40% (di 15%) Demografico: 35% (di 15%) Finanziario: 25% (di 15%)	(50% del valore di ogni modulo) 1° semestre: entro il 30/06/2020 2° semestre: entro il 31/12/2020

In tempo utile saranno forniti tuti i dati necessari all’intestazione delle fatture.

I prezzi sono da considerarsi invariabili pertanto, non subiranno le conseguenze di eventi e circostanze sfavorevoli o eventuali aumenti improvvisi di costi e comprensivi di tutte le componenti necessarie per effettuare la prestazione richiesta.

Il corrispettivo massimo e omnicomprensivo del servizio, è pari a quanto risultante dall' offerta economica presentata e dovrà garantire quanto contemplato all’art. 1 e all’art. 2 del presente CSA.

Dal corrispettivo saranno dedotte eventuali penalità riscontrate come previsto dall'art. 19 del presente CSA previa emissione di apposita nota di credito.

Art. 19 - Penali

Nel caso in cui l’Aggiudicatario non dovesse rispettare le condizioni di fornitura previste nel presente CSA, ad esclusione dei casi preventivamente autorizzati dall’Amministrazione con sospensioni e/o proroghe oppure riconducibili ad eventi di forza maggiore generalmente riconosciuti e documentati, si applicheranno penali di seguito indicate proporzionali alla gravità riscontrata, salvo comunque il risarcimento di ogni ulteriore danno.