ALLEGATO 6 - CAPITOLATO TECNICO

Capitolato relativo all’affidamento dei servizi di

sviluppo, manutenzione e gestione dei sistemi di Bilancio e Finanza Pubblica del Sistema Informativo Integrato del Ministero dell’Economia e delle Finanze - Dipartimento della Ragioneria Generale dello Stato - e della Corte dei conti.

SOMMARIO

1 PREMESSA

1 PREMESSA‌

Il presente capitolato ha lo scopo di definire i requisiti relativi alla fornitura dei servizi in oggetto, in quantità, qualità e livelli di servizio adeguati allo sviluppo, mantenimento ed utilizzo dei sistemi di Bilancio e Finanza Pubblica, del Ministero dell’Economia e delle Finanze - Dipartimento della Ragioneria Generale dello Stato - e della Corte dei conti.

Con il termine “Consip” va intesa la CONSIP S.p.A.. Con il termine “Fornitore” va intesa l’Impresa aggiudicataria della fornitura. Con il termine “Amministrazione” va inteso il Ministero dell’Economia e delle Finanze - Dipartimento della Ragioneria Generale dello Stato e la Corte dei conti.

Quando non diversamente specificato, con “capitolato” si intende il presente documento, con “gara” si intende la gara da effettuare a fronte del capitolato, con “contratto” si intende il contratto che verrà sottoscritto a seguito dell’aggiudicazione della gara, con “fornitura” si intende il complesso delle attività e dei prodotti che il Fornitore è chiamato a compiere e a produrre per onorare il contratto.

In genere, ogni altro termine che potrebbe essere scritto in minuscolo, viene scritto in maiuscolo quando assume un ben preciso significato ai fini della comprensione del testo (es. “analisi”, per un’accezione qualsiasi presente in un dizionario della lingua italiana, “Analisi” ad indicare una ben precisa fase del ciclo di sviluppo software, specificatamente definita nel documento, ed il cui significato è formalmente collegato alla presente fornitura)

L’oggetto della fornitura è riportato nel capitolo 2, con lo scopo di definire a grandi linee i servizi richiesti. Nei capitoli 3 e 4 sono indicati i parametri quantitativi e le figure professionali previste per la fornitura. Le modalità di esecuzione dei servizi e delle attività nonché gli aspetti qualitativi della fornitura sono descritti nel capitolo 5.

Sono parti integranti del capitolato le seguenti appendici:

Appendice 1: Glossario dei termini di bilancio, contabilità e finanza pubblica in uso presso il Dipartimento della Ragioneria Generale dello Stato e la Corte dei conti;

Appendice 2: Descrizione delle funzionalità applicative, delle caratteristiche tecnologiche e degli Obiettivi dei Sistemi di Bilancio e Finanza Pubblica;

Appendice 3: Manuale d’uso del programma Base Informativa di Governo (BIG), utilizzato per la raccolta delle segnalazioni ed il monitoraggio delle attività di gestione;

Appendice 4: Raccoglitore standard Consip; Appendice 5: Indicatori di qualità della fornitura;

Appendice 6: Descrizione processo e contenuto prodotti;

Appendice 7: Descrizione tecnica degli ambienti tecnologici del MEF;

Appendice 8: Strumenti, standard e modalità d’uso per la gestione della configurazione.

1.1 Punti di innovazione ‌

Al solo scopo di facilitare la consultazione del capitolato e dei suoi Allegati, si elencano qui di seguito alcune innovazioni apportate rispetto a precedenti capitolati Consip emessi per contratti di servizi analoghi:

- Definizione aggiornata dei servizi realizzativi (vedi capitolo 2);

- Diversa modalità di remunerazione della manutenzione correttiva (vedi paragrafo 3.2.3)

- Modalità di esecuzione dei servizi (vedi capitolo 5)

- Tempo ottimale di sviluppo (vedi paragrafo 5.4.3)

- Aggiornamento documentazione di corredo al sistema applicativo (vedi paragrafo 5.6.1)

- Test automatici e certificazione (vedi paragrafo 5.7.5)

- Rilievi e penali (vedi paragrafo 5.7.4)

- Trasferimento di know how (vedi paragrafo 5.10.2)

- Conformità del software sviluppato agli standard indicati dai produttori (vedi Appendice 6)

- Ciclo di sviluppo sistemi conoscitivi (vedi Appendice 6)

- Standard aggiornati e nuovi (vedi Appendice 4).

2 OGGETTO DELLA FORNITURA‌‌

Il Sistema Informativo Integrato del Ministero dell’Economia e delle Finanze, Dipartimento della Ragioneria Generale dello Stato, si articola in aree funzionali, applicazioni, funzioni.

Il Sistema Informativo per il Controllo, le Audizioni e il Referto della Corte dei conti si articola in applicazioni e funzioni.

Con “sistemi di Bilancio e Finanza Pubblica” si intende l’insieme delle aree del Sistema Informativo Integrato del Ministero dell’Economia e delle Finanze, Dipartimento della Ragioneria Generale dello Stato, finalizzate direttamente alla gestione del Bilancio e della Contabilità Finanziaria dello Stato, e del Sistema Informativo per il Controllo, le Audizioni e il Referto della Corte dei conti.

Oggetto della fornitura sono:

• Servizi realizzativi;

• Servizi di manutenzione;

• Servizi di gestione;

dei sistemi di Bilancio e Finanza Pubblica, relativamente alle seguenti aree:

⮚ Sistema Informativo Integrato del Ministero dell’Economia e delle Finanze, Dipartimento della Ragioneria Generale dello Stato:

o Bilancio,

o Patrimonio,

o Finanza della PA,

o Entrate,

o Spese,

o Monitoraggio della Finanza Pubblica,

o Utilità,

o Contabilità finanziaria delle amministrazioni (SICOGE),

o Prelegislativa,

o Supporto alle decisioni.

⮚ Sistema Informativo della Corte dei conti:

o Controllo, Audizioni e Referti.

Si rimanda all’Appendice 2 per una descrizione tecnico-funzionale delle aree elencate. Si prevede di svolgere le attività relative alla fornitura:

• per 36 mesi, dalla data di inizio attività (o data di inizio fornitura);

• per ulteriori 12 mesi, ai soli fini di garanzia ed eventuale trasferimento know how.

2.1 Servizi realizzativi ‌

I servizi realizzativi si compongono di:

⮚ Sviluppo;

⮚ Servizi di supporto informatico.

2.1.1 Sviluppo

Per sviluppo si intende la realizzazione di funzionalità volte a soddisfare esigenze utente. La realizzazione riguarda nuove applicazioni non presenti nell’attuale sistema.

Lo sviluppo rilascia prodotti che modificano la consistenza del parco applicativo misurata in Punti Funzione (PF) chiamata anche baseline del sistema, che di norma si incrementa, salvo casi di cancellazione in contemporanea di applicazioni obsolete e eventualmente sostituite da quelle nuove sviluppate. Il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari a mantenere aggiornata la baseline come descritto al paragrafo 5.6.5.

Lo sviluppo è suddiviso in Obiettivi, ognuno dei quali può essere assimilato, dal punto di vista del Fornitore, 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 al capitolo 5.

L’elenco degli Obiettivi, per ciascuna area, è riportato in Appendice 2. Tale elenco non si può considerare esaustivo ed immutabile, ma potrà subire delle revisioni nel periodo di validità contrattuale. La descrizione associata agli Obiettivi, inoltre, non va intesa in termini vincolanti sul modo in cui avverrà la realizzazione.

2.1.2 Servizi di supporto informatico

Per supporto informatico si intendono le seguenti attività che di norma non modificano la baseline del sistema:

• supporto tematico a redazione di studi, analisi di fattibilità, stima dei tempi, costi e benefici, comparazione tra diverse possibili soluzioni;

• analisi dei processi;

• creazione o aggiornamento di documentazione non collegata a specifici interventi di sviluppo;

• redazione di presentazioni;

• esecuzione di sperimentazioni (che non producano software applicativo);

• sviluppo di prototipi, di tipo “usa e getta” per esigenze non direttamente collegabili all’attività amministrativa (ad esempio per partecipazione a convegni, seminari, eventi pubblici);

• sviluppo di soluzioni per training on the job;

• supporto sistemistico e supporto specialistico all’uso dei prodotti software

• supporto informatico alla predisposizione di relazioni tecniche per studi di fattibilità, alla redazione di documenti di architettura, all’individuazione dei requisiti di sistema, valutazioni, ecc.).

L’elenco non si può considerare esaustivo ed immutabile, ma potrà subire delle revisioni nel periodo di validità contrattuale per comprendere attività affini e comunque orientate a supportare lo sviluppo, la manutenzione e la gestione del SIRGS.

2.2 Servizi di manutenzione

I servizi di manutenzione si articolano in:

⮚ Manutenzione evolutiva;

⮚ Manutenzione adeguativa;

⮚ Manutenzione correttiva.

2.2.1 Manutenzione evolutiva

Per manutenzione evolutiva si intende la realizzazione di funzionalità volte a soddisfare esigenze utente che riguardano funzioni aggiuntive, modificate o complementari al sistema esistente. Sono riconducibili a manutenzione evolutiva anche le modifiche urgenti alle funzioni, da realizzarsi con risorse e tempi contenuti, quali ad esempio, la modifica di una transazione o di un tabulato per una diversa prospettazione dei dati.

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 come descritto al paragrafo 5.6.5.

La manutenzione evolutiva è suddivisa in Obiettivi, ognuno dei quali può essere assimilato, dal punto di vista del Fornitore, 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 al capitolo 5.

2.2.2 Manutenzione adeguativa

Con manutenzione adeguativa si intendono:

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

• adeguamenti necessari per innalzamento di versioni del software di base;

• adeguamenti intesi all’introduzione di nuovi prodotti o modalità di gestione del sistema;

• migrazioni di piattaforma;

• modifiche, anche massive, non a carattere funzionale, alle applicazioni (ad esempio cambiamento di titoli sulle maschere, ecc);

La manutenzione adeguativa tipicamente non varia la consistenza della baseline; nei casi di eccezione, il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari a mantenere aggiornata la baseline come descritto al paragrafo 5.6.5.

La manutenzione adeguativa è suddivisa in Obiettivi, ognuno dei quali può essere assimilato, dal punto di vista del Fornitore, 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 al capitolo 5.

2.2.3 Manutenzione correttiva

Per manutenzione correttiva si intende la diagnosi e la rimozione delle cause e degli effetti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio.

La manutenzione correttiva è normalmente innescata da una segnalazione di impedimento all’esecuzione dell’applicazione/funzione o dal riscontro di differenze fra l’effettivo funziona- mento del software applicativo e quello atteso, come previsto dalla relativa documentazione o comunque determinato dai controlli che vengono svolti durante l’attività dell’utente.

I malfunzionamenti imputabili a difetti presenti nel codice sorgente, o nelle specifiche di formato o di base dati, non rilevati a suo tempo durante il ciclo di sviluppo o in collaudo, sono risolti dal servizio di manutenzione correttiva con la riparazione del codice sorgente. Nel caso di software in garanzia da parte di un precedente fornitore, il servizio di manutenzione correttiva consiste nell’affidare a tale fornitore la riparazione, collaudarla e installarla nel sistema di esercizio.

I malfunzionamenti, le cui cause non sono imputabili a difetti presenti nel software applicativo, ma ad errori tecnici, operativi o d’integrazione con altri sistemi (ad esempio interruzione del collegamento TP, uso improprio delle funzioni, ecc.), possono comportare, da parte del servizio di manutenzione correttiva, il solo supporto all’attività diagnostica sulla causa del malfunziona- mento, a fronte della segnalazione pervenuta, ma sono poi risolti da altre strutture di competenza.

La manutenzione correttiva, di norma, non comporta la modifica della baseline; nei casi di eccezione, il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari a mantenere aggiornata la baseline come descritto al paragrafo 5.6.5.

Sono parte integrate della manutenzione correttiva le seguenti attività:

• acquisizione dal Fornitore precedente del necessario know how per operare, sia con riguardo alla baseline non in garanzia che a quella in garanzia; si precisa che la baseline è oggetto di servizio pieno a partire dal secondo anno contrattuale;

• partecipazione, durante il periodo di collaudo, alle attività di presa in carico dei prodotti sviluppati e da rilasciare in esercizio, al fine di acquisire il know how necessario al corretto svolgimento del servizio;

• contributi di competenza sistemistica e specialistica di prodotto necessaria alla corretta soluzione del malfunzionamento;

• garanzia (paragrafo 5.10.3) sulla rimozione della difettosità residua relativamente al software collaudato il terzo anno contrattuale, per la durata di un anno dopo il terzo anno contrattuale, operando attraverso il fornitore che subentra nel servizio.

La tempestività di ripristino delle applicazioni a fronte di malfunzionamento è misurata rispetto a valori articolati in funzione sia della classe di rischio dell’applicazione che della categoria di malfunzionamento (si rimanda all’appendice 5 per ulteriori dettagli).

2.3 Servizi di gestione

I servizi di gestione sono svolti da parte di risorse professionali del Fornitore, e sono orientati all’esercizio delle aree funzionali ed all’assistenza degli utenti. I servizi sono svolti all’interno di gruppi di lavoro misti Consip - Fornitore, ed è designata la persona Consip responsabile del servizio nei confronti dell’Amministrazione. Essi si articolano in:

⮚ Prodotti/servizio;

⮚ Front-end;

⮚ Back-end.

2.3.1 Prodotti/servizio

La categoria prodotti/servizio prevede la realizzazione di prodotti informatici o lo svolgimento di servizi “ad hoc”, per soddisfare particolari e puntuali esigenze dell’utente, non risolvibili con le funzionalità disponibili nel sistema informativo, e che di norma non entrano a far parte stabile del parco applicativo. Tipico esempio può essere un intervento puntuale di correzione di una banca dati, o un prospetto informativo usa-e-getta.

2.3.2 Front-end

Per front-end si intendono le seguenti attività:

• partecipazione alle attività di collaudo, al fine di acquisire il know how necessario al corretto svolgimento del servizio;

• supporto all’avviamento in esercizio;

• assistenza tecnico/funzionale agli utenti durante il periodo iniziale di esercizio delle applicazioni;

• assistenza operativa agli utenti, per l’uso appropriato delle funzioni secondo le modalità previste nei manuali d’uso;

• assistenza agli utenti su tematiche funzionali/amministrative per la risoluzione di problemi d’interpretazione delle norme d’uso, attivando se necessario i progettisti del sistema o gli esperti dell’Amministrazione sulla tematica

• supporto specialistico all’assistenza per le applicazioni in esercizio.

2.3.3 Back-end

Per back-end si intendono le seguenti attività:

1) gestione della configurazione, compresi gli ambienti per i quali non è ancora disponibile lo strumento di Configuration Management, ivi compreso il trasferimento, negli ambienti in uso alle applicazioni, dei nuovi oggetti software sviluppati o di oggetto modificati in seguito ad attività di manutenzione evolutiva, adeguativa o correttiva;

2) presa in carico di nuove funzionalità in esercizio:

• schedulazione e pianificazione del rilascio in esercizio di nuove funzionalità;

• verifica e validazione dei prodotti per la gestione: procedure, parametri e tabelle, manuale utente, manuale di gestione, definizioni relative ai dati;

• supporto alla predisposizione dell’ambiente di esercizio e quant’altro necessario a consentire l’inizio delle attività da parte degli utenti;

3) gestione delle funzionalità in esercizio:

• intercettazione e registrazione dei problemi alla fonte, classificazione, eventuale riproduzione dell’errore e, se necessario, conseguente attivazione e governo del servizio di manutenzione correttiva;

• validazione tecnica e controllo dei risultati delle elaborazioni, al fine di assicurare l’integrità e la correttezza dei dati presenti sulla base informativa, del contenuto dei flussi informativi provenienti o destinati ad organismi esterni, dei dati esposti negli elaborati del sistema;

• ripristino base dati;

• modifiche di parametri di esecuzione o di tabelle di riferimento o decodifica;

4) pianificazione funzionale del servizio (e ripianificazione, per eccezione), in accordo con gli organi tecnici ed amministrativi dell’Amministrazione:

• movimentazione giornaliera del batch;

• disponibilità del servizio on line (funzionalità TP);

• controllo e fasatura dell’introduzione di nuove versioni di software di base (anche in via estemporanea e/o transitoria) nell’ambiente gestito;

• pianificazione ed esecuzione di elaborazioni di prova, con relativa ripresa di dati reali, a scopo di manutenzione preventiva, per anticipare l’esito dell’elaborazione di procedure critiche per l’Amministrazione.

3 DIMENSIONI‌‌

3.1 Dimensioni dei servizi realizzativi

I servizi realizzativi sono dimensionati in:

• un massimale di Punti Funzione (PF), quale somma delle dimensioni in punti funzione dei singoli Obiettivi di sviluppo, il cui corrispettivo è calcolato sulla base dei PF dell’Obiettivo e del costo unitario del PF;

• un massimale in Giorni Persona (GP), quale somma delle dimensioni in giorni persona dei singoli Obiettivi di servizio di supporto informatico, il cui corrispettivo è calcolato sulla base dei GP dell’Obiettivo e del costo unitario delle figure professionali impegnate per il servizio di supporto informatico.

Per lo sviluppo, eccezionalmente (non oltre il 10% del massimale di Punti Funzione prestabilito), laddove la stima di impegno in punti funzione non fosse applicabile, l’Obiettivo sarà stimato e gestito in giorni persona, ma sempre a corpo, previo calcolo a priori del corrispettivo sulla base della stima delle figure professionali da impiegare, con conseguente diminuzione del massimale di sviluppo.

3.1.1 Sviluppo

La tabella che segue riporta il massimale di impegno in PF previsto per lo sviluppo, di cui:

• quota parte (prevalente) corrisponde agli Obiettivi elencati in Appendice 2, stimati su base esperienza, al meglio delle conoscenze disponibili alla data;

• quota parte (residua) costituisce una disponibilità da gestire in sede di revisione della pianificazione iniziale, come regolato da contratto, in caso di altre esigenze emergenti nel tempo.

Area	Impegno in PF per Sviluppo
	Totale		I° anno		II° anno		III° anno
	ADD+CHG	DEL	ADD+CHG	DEL	ADD+CHG	DEL	ADD+CHG	DEL
Bilancio	7.700	100	2.900	100	2.700	-	2.100	-
Patrimonio	5.200	1.000	1.200	-	4.000	1.000	-	-
Finanza della PA	8.500	-	4.300	-	2.200	-	2.000	-
Entrate	10.950	-	6.950	-	3.650	-	350	-
Spese	15.000	1.500	5.600	1.000	5.350	500	4.050	-
Monitoraggio della FP	21.000	1.400	8.000	700	8.000	350	5.000	350
Utilità	3.700	100	1.700	100	1.000	-	1.000	-
Corte dei conti	7.300	2.100	5.300	2.100	1.000	-	1.000	-
SICOGE	14.000	350	5.200	-	3.100	-	5.700	350
Prelegislativa	4.500	100	2.500	100	1.000	-	1.000	-
Supporto alle decisioni	11.100	2.200	4.400	1.000	4.000	800	2.700	400
Totale	108.950	8.850	48.050	5.100	36.000	2.650	24.900	1.100

Per quanto riguarda l’Area Monitoraggio della FP, occorre specificare che, oltre a quanto previsto nella presente gara, orientato in prevalenza a sviluppo di Data Mart di fruizione dell’informazione, Consip intende sviluppare in parallelo, attraverso altri contratti, anche funzioni e strumenti di servizio trasversale al DWH, che pertanto non sono riportati in questo dimensionamento.

3.1.2 Servizi di supporto informatico

La tabella che segue riporta il massimale di impegno in GP previsto per i servizi di supporto informatico, stimato in funzione delle caratteristiche e delle esigenze delle singole aree applicative.

Area	Impegno in GP per Supporto informatico
Area	Totale	I° anno	II° anno	III° anno
Bilancio	315	105	105	105
Patrimonio	315	105	210	-
Finanza della PA	630	210	210	210
Entrate	945	315	315	315
Spese	630	210	210	210
Monitoraggio della FP	-	-	-	-
Utilità	2.835	945	945	945
Corte dei conti	525	105	210	210
SICOGE	1.260	420	420	420
Prelegislativa	315	105	105	105
Supporto alle decisioni	630	210	210	210
Totale	8.400	2.730	2.940	2.730

In aggiunta a quanto riportato in tabella, specificatamente (ma non solo) per l’Area Monitoraggio della FP (Finanza Pubblica), occorre specificare che Consip intende acquisire altri servizi di supporto informatico, attraverso altri contratti.

3.2 Dimensioni dei servizi di manutenzione ‌

I servizi di manutenzione sono dimensionati in:

• un massimale di Punti Funzione, quale somma delle dimensioni in punti funzione dei singoli Obiettivi di manutenzione evolutiva, il cui corrispettivo è calcolato sulla base dei PF dell’Obiettivo e del costo unitario del PF;

• un massimale in Giorni Persona, quale somma delle dimensioni in giorni persona dei singoli Obiettivi di manutenzione adeguativa, il cui corrispettivo è calcolato sulla base dei GP dell’Obiettivo e del costo unitario delle figure professionali impegnate per l’Obiettivo;

• un canone mensile fisso costante omnicomprensivo per la manutenzione correttiva il cui corrispettivo è determinato sulla base della dimensione del parco applicativo non soggetto a garanzia.

Per la manutenzione evolutiva, eccezionalmente (non oltre il 10% del massimale di Punti Funzione prestabilito), laddove la stima di impegno in punti funzione non fosse applicabile, l’Obiettivo sarà stimato e gestito in giorni persona, ma sempre a corpo, previo calcolo a priori del corrispettivo sulla base della stima delle figure professionali da impiegare, con conseguente diminuzione del massimale di manutenzione evolutiva.

3.2.1 Manutenzione evolutiva

La tabella che segue riporta il massimale di impegno in PF previsto per la manutenzione evolutiva, di cui:

• quota parte corrisponde agli Obiettivi elencati in Appendice 2, stimati su base esperienza, al meglio delle conoscenze disponibili alla data;

• quota parte costituisce una disponibilità da gestire in sede di revisione della pianificazione iniziale, come regolato da contratto, in caso di altre esigenze emergenti nel tempo.

Area	Impegno in PF per Manutenzione evolutiva
	Totale		I° anno		II° anno		III° anno
	ADD+CHG	DEL	ADD+CHG	DEL	ADD+CHG	DEL	ADD+CHG	DEL
Bilancio	6.400	-	2.200	-	1.900	-	2.300	-
Patrimonio	4.450	-	1.550	-	1.500	-	1.400	-
Finanza della PA	2.200	-	200	-	1.000	-	1.000	-
Entrate	3.000	-	-	-	1.000	-	2.000	-
Spese	3.300	-	800	-	1.300	-	1.200	-
Monitoraggio della FP	-	-	-	-	-	-	-	-
Utilità	650	-	350	-	150	-	150	-
Corte dei conti	7.600	-	2.850	-	2.650	-	2.100	-
SICOGE	17.600	-	3.700	-	10.650	-	3.250	-
Prelegislativa	1.600	-	100	-	750	-	750	-
Supporto alle decisioni	4.200	-	2.000	-	1.200	-	1.000	-
Totale	51.000	-	13.750	-	22.100	-	15.150	-

3.2.2 Manutenzione adeguativa ‌

La tabella che segue riporta il massimale di impegno in GP previsto per la manutenzione adeguativa, stimato in funzione delle caratteristiche applicative delle singole aree e delle esigenze di adeguamento previste.

Area	Impegno in GP per Manutenzione adeguativa
Area	Totale	I° anno	II° anno	III° anno
Bilancio	630	210	210	210
Patrimonio	315	105	105	105
Finanza della PA	315	105	105	105
Entrate	315	105	105	105
Spese	1.890	630	630	630
Monitoraggio della FP	630	210	210	210
Utilità	3.150	1.050	1.050	1.050
Corte dei conti	315	105	105	105
SICOGE	1.260	420	420	420
Prelegislativa	-	-	-	-
Supporto alle decisioni	1.680	420	630	630
Totale	10.500	3.360	3.570	3.570

3.2.3 Manutenzione correttiva ‌

Il volume contrattuale di manutenzione correttiva è dimensionato sul numero di PF, non in garanzia, affidati per anno (baseline), come riportato nella seguente tabella. Il canone mensile del servizio dovrà tener conto di un possibile incremento di tale previsione, fino alla dimensione massima di PF 500.000.

Area	Baseline di Manutezione correttiva
Area	Totale	I° anno	II° anno	III° anno
Bilancio	86.200	26.400	29.900	29.900
Patrimonio	20.000	7.000	7.000	6.000
Finanza della PA	18.200	5.200	6.500	6.500
Entrate	29.400	24.400	2.500	2.500
Spese	73.400	22.900	25.500	25.000
Monitoraggio della FP	32.550	11.900	11.500	9.150
Utilità	4.400	1.200	1.600	1.600
Corte dei conti	53.400	19.200	17.100	17.100
SICOGE	130.900	36.900	47.000	47.000
Prelegislativa	3.100	500	1.300	1.300
Supporto alle decisioni	22.100	900	11.000	10.200
Totale	473.650	156.500	160.900	156.250

La colonna “I° anno” è al netto del software in garanzia prestata da parte del fornitore uscente nel primo anno contrattuale (complessivi 34.000 PF), e le altre colonne tengono comunque conto del software che man mano viene dismesso. Inoltre, limitatamente a “Monitoraggio della FP” e a “Prelegislativa” si precisa che la garanzia erogata da parte del fornitore uscente è prevista fino al 15 settembre 2005.

3.3 Dimensioni dei servizi di gestione

I servizi di gestione sono dimensionati in un massimale di GP stimato in base alle necessità delle singole aree applicative.

Le tabelle che seguono riportano:

⮚ i GP per area applicativa e per anno contrattuale;

⮚ le risorse full time equivalent (FTE) per servizio e anno contrattuale;

⮚ gli FTE per area applicativa e per servizio.

Si tratta di valori medi stimati al meglio delle conoscenze attuali, delle esigenze utente e della relativa evoluzione pianificata. Al mutare delle esigenze, e perciò delle risorse impegnate, in quantità e qualità, il piano potrà essere rivisto ed aggiornato, come regolato a contratto, nel limite del massimale di GP prestabilito.

Area	Impegno in GP per Gestione
Area	Totale	I° anno	II° anno	III° anno
Bilancio	5.355	1.785	1.785	1.785
Patrimonio	1.000	000	000	525
Finanza della PA	2.835	945	945	945
Entrate	3.780	1.260	1.260	1.260
Spese	4.410	1.470	1.470	1.470
Monitoraggio della FP	8.610	2.625	2.835	3.150
Utilità	2.730	840	840	1.050
Corte dei conti	2.835	945	945	945
SICOGE	4.410	1.470	1.470	1.470
Prelegislativa	1.260	420	420	420
Supporto alle decisioni	2.940	945	945	1.050
Totale	40.740	13.230	13.440	14.070

Impegno in FTE per Gestione
Totale	P/S	F/E	B/E
25,5	4,5	9	12
7,5	1,5	3	3
13,5	1,5	6	6
18	3	6	9
21	4,5	4,5	12
41	1	37	3
13	2,5	1,5	9
13,5	4,5	4,5	4,5
21	3	6	12
6	1,5	1,5	3
14	1,5	6	6,5
194	29	85	80

Attività	Impegno in FTE per Gestione
Prodotti/servizio	29	10	9	10
Front end	85	26	28	31
Back End	80	27	27	26
Totale	194	63	64	67

Nel terzo anno per l’Area Utilità sono previsti 210 GP di prodotto/servizio dedicati alle attività di docenza appositamente predisposte al trasferimento di know how. Tale collocazione temporale è indicativa, Consip si riserva di utilizzare tale disponibilità in qualsiasi momento, compreso l’anno di garanzia.

PROFILI PROFESSIONALI E COMPOSIZIONE GRUPPI DI LAVORO ‌‌

4.1 Profili professionali

Le figure professionali proposte per lo svolgimento dei servizi oggetto della fornitura dovranno fare riferimento ai profili di seguito descritti. Questi hanno valore indicativo e non prescrittivo, in quanto Consip si riserva in ogni caso di accettare o meno una risorsa per una certa qualifica sulla base delle effettive capacità, al di là del suo profilo personale. Ad esempio, 5 anni addizionali di esperienza professionale nel settore informatico possono corrispondere ad una cultura equivalente ad una laurea in discipline tecniche.

Ogni riferimento ad attività (es. Disegno) o metodologie basate sull’adozione di prodotti e ogni riferimento a prodotti (es. SAS) vanno intese in relazione ai prodotti e/o ai componenti di tali prodotti che sono effettivamente adottati per i sistemi di Bilancio e Finanza Pubblica. Se possedute, queste sono apprezzate come competenze core per l’esecuzione della fornitura. Competenze su altri prodotti, non adottati, o su componenti non utilizzate dei prodotti adottati sono apprezzate in minor misura e comunque solo se associate alle competenze core.

Tale scenario può cambiare in corso d’opera, in conseguenza dell’evoluzione delle piattaforme utilizzate. Pertanto, i profili delle figure che seguono non sono da considerare esaustivi delle esigenze della fornitura, in quanto Consip potrà richiedere in corso di esecuzione del contratto competenze specifiche in relazione ad ulteriori tematiche, prodotti, sistemi e metodologie.

Capo progetto

Titolo di studio

Laurea in discipline tecniche o cultura equivalente

Esperienze lavorative

• Minimo 12 anni, di cui almeno 4 nella funzione

• Redazione di documentazione di progetto

• Controllo realizzazione procedure

• Stima di risorse per realizzazione di progetto

• Stima di tempi e pianificazione attività

• Analisi e progettazione di sistemi informativi, package, procedure complesse

• Uso di tecniche e prodotti software per project management e risk management

• Responsabilità su gruppi di progetto

Conoscenze

• Metodologie di sviluppo

• Metodologie di misura progetti

• Conoscenze ed uso di tecniche e prodotti software per project management e risk management

• Tematiche applicative gestionali e/o data warehouse, preferibilmente in ambito economico, finanziario e Pubblica Amministrazione

• Autorevolezza e comprovata esperienza in progetti di grandi dimensioni

• Ottime capacità relazionali

Analista funzionale

Titolo di studio

Laurea in discipline tecniche o cultura equivalente

Esperienze lavorative

• Minimo 8 anni, di cui almeno 4 come analista

• Redazione di documentazione di progetto

• Controllo realizzazione procedure

• Stima di risorse per lo sviluppo di software

• Stima di tempi e pianificazione attività

• Coordinamento di gruppi di lavoro

• Disegno e progettazione di test

Conoscenze

• Metodologie di analisi di prodotti SW

• Metodologie di disegno di prodotti SW

• Tecniche di controllo di progetto

• Tecniche di programmazione strutturata

• Tecniche di modellazione e integrazione dati

• Metodologie e tecniche per la gestione dei metadati

• Metodologie e tecniche per il cleaning e la qualità dei dati

• Metodologia di analisi e disegno Object Oriented con UML

• Applicazioni OLAP, ROLAP e processi ETL

• Tematiche applicative gestionali e/o data warehouse, preferibilmente in ambito economico, finanziario e Pubblica Amministrazione

• Ottime capacità relazionali

Analista programmatore

Titolo di studio

Diploma di perito informatico o diploma analogo

Esperienze lavorative

• Minimo 4 anni come programmatore e 3 nella funzione

• Coordinamento di piccoli gruppi di lavoro

• Verifica della corretta applicazione di metodi e standard

• Sviluppo di analisi tecnica di media complessità

• Documentazione procedure

• Preparazione di casi di test

• Esecuzione di test

• Partecipazione a gruppi di progetto di medie/grandi dimensioni

Conoscenze

• Metodologie di disegno di prodotti software

• Tecniche di programmazione strutturata

• DBMS relazionali

• Strumenti di modellazione dati

• Tecniche di programmazione Object Oriented

• Applicazioni OLAP, ROLAP e processi ETL

• Ottime capacità relazionali

Programmatore

Titolo di studio

Diploma di perito informatico o diploma analogo

Esperienze lavorative

• Minimo 4 anni nella funzione

• Completa autonomia nello sviluppo

• Preparazione ed esecuzione di casi di test di unità

• Preparazione di documentazione di programmi

• Partecipazione alla stesura di specifiche tecniche

• Partecipazione a gruppi di progetto di medie dimensioni

Conoscenze

• Strumenti per la codifica dei programmi

• Tecniche di programmazione strutturata

• Tecniche di programmazione Object Oriented

Specialista di tematica

Titolo di studio

Laurea in discipline tecniche o cultura equivalente

Esperienze lavorative

• Minimo 8 anni, di cui almeno 3 nella funzione

• Supporto consulenziale su temi specifici

• Analisi organizzative e di processi

• Specialista di prodotto o piattaforma

• Uso di tecniche e prodotti SW su aree specifiche

• Sviluppo di soluzioni di formazione

Conoscenze

• Metodologie di analisi

• Conoscenza di tecniche e prodotti SW su aree specifiche

• Conoscenza del settore pubblico, e, preferibilmente, dell’ambito economico, finanziario e Pubblica Amministrazione Centrale

• Strumenti MS Office

• Ottime capacità relazionali

Specialista di prodotto

Titolo di studio

Laurea in discipline tecniche o cultura equivalente

Esperienze lavorative

• Minimo 8 anni, di cui almeno 3 nella funzione

• Analisi, progettazione e realizzazione di sistemi informativi, package, procedure complesse

• Progettazione test integrati

• Ottime capacità relazionali

• Spiccata attitudine al problem solving

Conoscenze

• Ottime capacità relazionali

• Strumenti MS Office

• Sistemi MS Windows

• Sistemi Unix

• MS SQL Server

• Tecnologia Java in particolare lo std J2EE

• Tecnologia MS .NET

• Sistemi Operativi e browser per dispositivi mobili (es. OPERA , WIN CE, PALM OS ECC.)

• Ambienti di programmazione ed utilizzo dei prodotti tecnologici:

o Visual Basic

o Html

o ASP

o COBOL – CICS – DB2 – DL/1

o Oracle

o Microstrategy

o Business Objects

o Power Center

o XML

o SAS

o Actuate e reporting suite

o Ascential (Metastage, Qualità Manager)

o Linguaggio C

o Crystal Report

o Java

Specialista tecnologico

Titolo di studio

• Laurea in discipline tecniche o cultura equivalente

Esperienze lavorative

• Minimo 8 anni, di cui almeno 3 nella funzione

• Redazione di specifiche di gestione e procedure

• Stima di risorse per realizzazione attività

• Spiccata attitudine al problem solving

Conoscenze

Elevata conoscenza di prodotti/tecnologie:

• Sistemi operativi: MS Windows, UNIX X-OPEN, Linux, Z/OS

• RDBMS – Oracle Database, IBM DB2 for OS/390 e MS SQL Server

• Piattaforma J2EE – in particolare gli Application Server IBM Websphere e Oracle Application Server

• Piattaforma Microsoft .NET

• Tecniche di OLAP, ROLAP e processi ETL

• MQseries

• Java Messages System

• Architetture DWH e strumenti di Business Intelligence

• Ottime capacità relazionali

4.2 Composizione dei gruppi di lavoro ‌

Di seguito vengono indicate le composizioni di riferimento dei gruppi di lavoro per i servizi oggetto della fornitura.

4.2.1 Sviluppo e manutenzione

Per i servizi di sviluppo e manutenzione, facendo la media di tutti gli Obiettivi su tutte le aree applicative, il fornitore dovrà dichiarare in offerta ed impiegare un mix di figure professionali tale da rientrare nei range riportati nella tabella seguente in modo che, rapportandosi ad una singola giornata lavorativa, il mix proposto rappresenti il 100% del gruppo di lavoro.

Figura Professionale	% Utilizzo
Figura Professionale	Min	Max
Capo progetto	5	15
Analista Funzionale	20	40
Analista Programmatore	30	50
Programmatore	5	25
Specialista di prodotto	5	5
Specialista tecnologico	5	5

4.2.2 Supporto informatico

Per i servizi di supporto informatico, il Fornitore dovrà impiegare le seguenti figure professionali:

• Specialista di tematica

• Specialista di prodotto

• Specialista tecnologico

4.2.3 Gestione

Per i servizi di gestione, il Fornitore dovrà impegnare le seguenti figure professionali:

• Analista funzionale

• Analista programmatore

L’offerta dovrà essere predisposta secondo il piano di impiego, mediato su tutti i servizi di tutte le aree applicative, riportato in tabella:

Figura Professionale	% Utilizzo
Analista Funzionale	60
Analista Programmatore	40

5 MODALITÀ DI ESECUZIONE DEI SERVIZI‌‌

5.1 Premessa

Al fine di descrivere chiaramente le modalità di esecuzione dei servizi oggetto della fornitura, viene di seguito esposta la matrice di corrispondenza tra i servizi stessi e le modalità di esecuzione:

Servizio	Variazione baseline	Metrica	Modalità	Ciclo di sviluppo	Sede
Sviluppo	Si	PF 1	Progettuale a corpo	Completo o ridotto	Fornitore 2
Supporto informatico	No	GP	Progettuale a corpo	Fase unica o altri tipi di ciclo	Fornitore
Manutenzione evolutiva	Si	PF1	Progettuale a corpo	Completo o ridotto o fase unica	Fornitore
Manutenzione adeguativa	No 3	GP	Progettuale a corpo	Completo o ridotto o fase unica	Fornitore
Manutenzione correttiva	No	-	Continuativa a canone	-	Fornitore
Prodotti / servizio	No	GP	Continuativa a consumo	-	Consip
Back-End	No	GP	Continuativa a consumo	-	Consip
Front-End	No	GP	Continuativa a consumo	-	Consip

Consip si riserva di modificare le modalità di esecuzione descritte, di introdurre nuove modalità, di definire/modificare gli attuali standard, anche in corso d’opera, dandone congruo preavviso al Fornitore. In aggiunta, tali modalità di esecuzione potranno essere congiuntamente riviste, su proposta del Fornitore, e potranno essere concordate opportune semplificazioni o variazioni in funzione delle specificità dei singoli Obiettivi. Inoltre Xxxxxx si riserva di chiedere al Fornitore di utilizzare prodotti o modulistica specifica, messi a disposizione da Consip, di supporto alla gestione dei servizi oggetto della fornitura (ad esempio: registrazione errori, log interventi, richiesta attività, ecc.). Consip si riserva inoltre di avvalersi di terzi per il supporto allo svolgimento di attività di propria competenza, ferma restando la responsabilità globale di Consip nello svolgimento di tali attività.

Segue una descrizione più dettagliata delle modalità e degli istituti previsti per l’esecuzione dei servizi. Si rimanda all’Appendice 6 per ulteriori approfondimenti in merito ai cicli di sviluppo, alle fasi progettuali e ai contenuti informativi dei documenti di progetto da consegnare.

1 Eccezionalmente GP (≤10% del relativo massimale)‌

2 Presso sedi dell’amministrazione a richiesta Consip

3 Eccezionalmente si potrebbero avere variazioni di entità limitata

5.2 Modalità progettuale ‌

I servizi oggetto della fornitura da erogare in modalità progettuale verranno scomposti in Obiettivi a cui verrà attribuita una classe di rischio, una dimensione e un tempo di esecuzione. Gli Obiettivi saranno suddivisi temporalmente in una o più fasi, secondo i diversi cicli di sviluppo che è possibile adottare per ciascun tipo di Obiettivo. Le fasi sono delimitate da eventi (milestone), che sono gli atti, formali o sostanziali, indicati nella tabella seguente:

Milestone

Attore

Descrizione

Richiesta stima

Consip

Richiesta al Fornitore di procedere alla stima dei tempi e costi di un Obiettivo di sviluppo, manutenzione o servizio

di supporto informatico

Stima

Fornitore

Comunicazione dei tempi e dei costi previsti per l’Obiettivo

Autorizzazione

Amministrazio ne

Autorizzazione a Consip per l’attivazione dell’Obiettivo, dimensionato in costi e tempi

Durata

Attivazione

Consip

Attribuzione della classe di rischio dell’Obiettivo, approvazione dei prodotti di fase e avvio del Fornitore a procedere con le attività sull’Obiettivo

Consegna

Fornitore

Rilascio dei prodotti di fornitura, sia intermedi (di fase) che finali

Consip

Riscontro dei prodotti consegnati in quantità e tipologia (ricevuta), senza valutazione di contenuto

Approvazione

Consip

Validazione dei prodotti intermedi di fornitura, previa verifica di merito

Accettazione

Consip

Validazione dei prodotti finali di fornitura, previo collaudo (l’accettazione è l’ultima approvazione del ciclo)

Il termine “durata” dell’Obiettivo è usato nel presente documento come sinonimo dell’intervallo di tempo decorrente tra le milestone Attivazione e Accettazione.

Segue una tabella che collega queste milestone con l’inizio e la conclusione delle varie fasi dell’ Obiettivo, con indicazione dei cicli di sviluppo che le prevedono o meno.

L’approvazione del Disegno, in caso di ciclo completo di sviluppo, può essere sostituita dalla semplice consegna, qualora il responsabile di progetto Consip lo ritenga opportuno, in ragione della dimensione, criticità e tipologia dell’Obiettivo considerato.

Attore	Milestone	Fasi	Ciclo applicazioni gestionali		Ciclo applicazioni conoscitive	Ciclo Fase unica	Altre tipologi e di cicli
Attore	Milestone	Fasi	Completo	Ridotto	Completo	Ciclo Fase unica	Altre tipologi e di cicli
Consip	Richiesta stima		Si	Non formale	Si	Da definire	Da definire
Fornitore		Definizione	Si	Non formale	Si	Da definire	Da definire
Xxx.xx	Autorizzazione		Si	Si	Si	Si	Si
Consip	Attivazione		Si	Si	Si	Da definire	Da definire
Fornitore		Analisi	Si	Si	No	Si	Da definire
Consip	Approvazione		Si	Si	No	No	Da definire
Fornitore		Disegno	Si	Si	Si	No	Da definire
Fornitore	Approvazione		Si	No	Si	No	Da definire
Fornitore		Realizzazione	Si	Si	Si	No	Da definire
Fornitore	Consegna		Si	Si	Si	No	Si
Consip		Collaudo	Si	Si	Si	Da definire	Da definire
Consip	Accettazione		Si	Si	Si	Si	Si

Sviluppo e manutenzione evolutiva o adeguativa

Per quanto riguarda sviluppo e manutenzione evolutiva ed adeguativa, sono fissati i seguenti criteri oggettivi che orientano nell’individuare quando applicare il ciclo di sviluppo appropriato:

		Dimensione in PF
		< 50	< 200	200 ÷ 300	>300
Durata	< 1 mese	Fase unica	Non applicabile	Non applicabile	Non applicabile
	1-3 mesi	Ridotto	Ridotto	Ridotto	Non applicabile
	3-4 mesi	Non applicabile	Ridotto	Completo	Completo
	> 4 mesi	Non applicabile	Non applicabile	Completo	Completo

Non applicabile significa che tale situazione non è ritenuta tecnicamente adeguata. Normalmente il ciclo ridotto non è applicato ad Obiettivi con classe di rischio A, e non può mai essere applicato a Obiettivi di data warehouse in cui sia prevista la modifica della base dati. Nei restanti casi invece non sempre tali criteri sono di aiuto, in quanto la scelta più appropriata può dipendere dalle specifiche caratteristiche dell’Obiettivo. Il miglior ciclo di sviluppo pertanto verrà concordato nella fase di Definizione, anche in considerazione di quanto stabilito in merito al tempo ottimale di sviluppo, di cui al paragrafo 5.4.3.

Il ciclo a fase unica è previsto, di norma, solo in caso di durata non superiore a 1 mese; in tale circostanza è richiesto al Fornitore un adeguato grado di flessibilità nella propria organizzazione al fine di garantire la realizzazione con tempi di intervento brevi.

Anche i servizi di supporto informatico sono suddivisi in Obiettivi, analogamente a quanto avviene per gli altri servizi gestiti con modalità progettuale, e sono attivati con le stesse modalità. Di norma, è applicato il ciclo a fase unica. In particolare, per attività legate a sperimentazioni e produzione di prototipi, si potrà applicare un ciclo di sviluppo “ad hoc” definito in funzione delle specifiche caratteristiche delle attività da espletare e dei prodotti da realizzare; potranno essere previste iterazioni di fase o dell’intero ciclo e i prodotti potranno essere realizzati in versioni successive.

5.2.1 Stima e attivazione Obiettivi ‌

Nel caso Xxxxxx richieda la stima di un Obiettivo prima della sua attivazione, lo comunicherà al fornitore indicando l’impegno massimo da impiegare per effettuare la fase di Definizione (giorni persona di servizio di supporto informatico, specialista di tematica). Nel caso l’iniziativa abbia poi seguito, tale impegno sarà poi riassorbito nei costi dell’Obiettivo.

La richiesta è in genere corredata di un insieme di informazioni utili alla definizione dell’Obiettivo, del tipo:

• data prevista di inizio attività;

• data prevista di fine attività;

• classe di rischio dell’Obiettivo;

• data limite richiesta per completamento fase di Definizione;

• eventuali date vincolo (ad esempio richieste utente di date di esercizio);

• riferimenti a documentazione esistente (ad esempio studi di fattibilità, requisiti utente già espressi, ecc).

Al termine della fase di Definizione, previa autorizzazione da parte dell’Amministrazione alla prosecuzione dell’Obiettivo, anche in considerazione del Piano di Lavoro e della stima di costo proposti dal fornitore e avallati da Consip, questa procede all’approvazione della fase di Definizione (attivazione) e ne dà comunicazione al fornitore , con gli effetti operativi e contrattuali che ne conseguono.

5.2.2 Cancellazione Obiettivi

Nel caso di non approvazione della fase di Definizione (cfr. 5.2.1), e quindi di abbandono dell’iniziativa, per cause non imputabili al fornitore, verrà riconosciuto allo stesso un corrispettivo massimo pari all’impegno massimo da impiegare, specificato da Consip, per effettuare a fase di Definizione.

Nel caso di cancellazione degli Obiettivi al termine delle altre fasi di lavoro, per cause non imputabili al fornitore, verrà riconosciuto allo stesso un corrispettivo massimo pari al valore di avanzamento del lavoro, calcolato sulla base del volume dello sviluppo e dell’avanzamento corrispondente al momento della cancellazione.

Ciò non vale nel caso la cancellazione sia motivata da eccezioni da parte di Consip di mancato adempimento contrattuale da parte del Fornitore.

5.2.3 Collaudo Obiettivi ‌

Come specificato nella tabella precedente (che collega fasi , attori e cicli di vita) per la fase progettuale di Xxxxxxxx l’attore responsabile è Consip o terzi da essa delegati.

In questa fase viene richiesto al fornitore che ha effettuato gli intervento oggetto di collaudo un supporto alla corretta predisposizione dell’ambiente di collaudo e all’attività di presa in carico, da parte della struttura di back end, del software oggetto intervento.

5.3 Modalità continuativa

I servizi oggetto della fornitura da erogare in modalità continuativa non sono scomponibili in fasi. L’attivazione è prevista a partire dalla data di inizio fornitura e l’erogazione è senza soluzione di continuità fino alla data di fine fornitura.

Gestione

I servizi di gestione sono caratterizzati da attività che sono pianificabili già ad inizio fornitura e da altre che, in funzione delle esigenze che si verranno a definire nel periodo di durata della fornitura stessa, potranno aggiungersi man mano (come ad esempio l’avviamento in esercizio di una nuova applicazione) e che Consip comunicherà con il massimo anticipo possibile,

Pertanto, ferma restando la regolamentazione contrattuale a consumo, è prevista la creazione e l’aggiornamento di un Piano di Lavoro della gestione per ogni area/servizio, soggetto all’approvazione di Consip.

Il diretto e assiduo contatto con l’utente nelle attività di front end richiede alle risorse dedicate al servizio una elevata capacità di analisi, al fine di individuare la soluzione più idonea a risolvere l’esigenza utente ed in linea con le strategie evolutive del sistema informativo. E’ inoltre indispensabile la capacità di relazione con le diverse strutture al fine di coinvolgere i supporti più adeguati, anche creando sinergie con gli altri gruppi coinvolti nella fornitura.

Le attività estemporanee, normalmente caratterizzate da carattere di urgenza (di norma, prodotti/ servizio), verranno comunicate da Consip secondo la modalità più idonea (fax, e-mail, telefono) e dovranno essere attivate dal Fornitore nel più breve tempo possibile. Le situazioni di criticità e urgenza in cui è possibile che debbano essere svolte le attività, richiedono elevate capacità tecniche e professionali: prontezza, precisione, affidabilità e competenza.

E’ essenziale perciò da parte del Fornitore un elevato grado di flessibilità nel rendere disponibili le risorse, nonché nel garantire le necessarie competenze. In particolare si sottolinea l’importanza della presa in carico del sistema a inizio contratto e delle nuove funzionalità sviluppate man mano, per acquisire un elevato grado di conoscenza funzionale ed operativa del software realizzato.

Manutenzione correttiva

Il servizio di manutenzione correttiva, anche se attivato su specifico evento scaturito da un malfunzionamento, viene erogato in modalità continuativa in quanto lo specifico evento non è pianificabile.

Ogni segnalazione di malfunzionamento costituisce richiesta di intervento di manutenzione correttiva, e verrà registrata dai gruppi di lavoro di gestione (talvolta anche dai gruppi di lavoro di sviluppo o di manutenzione) su BIG (o analogo strumento), con attribuzione della categoria di malfunzionamento. La discriminazione tra malfunzionamento e nuova esigenza è determinata da Consip sulla base della documentazione esistente o, per quanto non rilevabile dalla documentazione (ad esempio contenuti della base dati), dai controlli effettuati durante l’attività amministrativa. Nei casi di carenza di documentazione l’attribuzione verrà fatta secondo regole di correttezza, buona fede e ragionevolezza tecnica, in nessun caso l’onerosità della soluzione potrà essere valutata quale discriminante.

Dal momento in cui la richiesta è comunicata al Fornitore decorrono i tempi relativi ai livelli di servizio definiti nel Piano della Qualità generale, il Fornitore ha la responsabilità della esecuzione dell’attività ed è tenuto ad aggiornare le informazioni di propria competenza su BIG, secondo le modalità indicate nell’Appendice 3, fino alla soluzione del malfunzionamento stesso o, nel caso non segua un intervento di correttiva, fino alla registrazione su BIG delle relative motivazioni.

La Manutenzione correttiva dovrà prevedere, oltre alla soluzione del malfunzionamento, anche l’eventuale ripristino della base dati (tramite programmi, utilità, routine, ecc). e l’eventuale aggiornamento della relativa documentazione, se necessario.

La fine attività verrà comunicata a Consip, che si riserva di procedere al collaudo delle eventuali modifiche apportate a software, documentazione e base dati. Diverse modalità di accettazione del servizio verranno congiuntamente concordate.

Le modalità di esecuzione descritte ed i livelli di servizio previsti dal Piano della Qualità generale si applicano anche agli interventi in garanzia.

Come per il servizio di gestione, anche per la manutenzione correttiva si sottolinea l’importanza della presa in carico del sistema a inizio contratto e delle nuove funzionalità sviluppate man mano, per acquisire un elevato grado di conoscenza del disegno e del codice realizzato.

5.3.1 Orario del servizio, reperibilità, disponibilità

La copertura dei servizi di gestione deve essere garantita tra le ore 8:30 e le ore 18:30 nei giorni dal lunedì al venerdì (orario di servizio), secondo una distribuzione delle presenze da concordare con Consip.

La riduzione d’orario per ferie, malattie, indisponibilità in genere della persona impiegata nel servizio, può richiedere, a discrezione di Consip, una sostituzione temporanea della persona con un’altra di livello equivalente. Può essere necessario, per esigenze di servizio, un prolungamento occasionale di orario oltre le ore 18:30, a cui può corrispondere eventualmente una riduzione d’orario compensativa nei giorni seguenti, da concordare con Consip.

La reperibilità extra orario, attraverso un telefono appositamente assegnato alla persona e tenuto acceso, deve essere garantita, per un numero di 10 persone di norma impiegate nei servizi di gestione e designate di concerto con Consip in relazione alle criticità ed ai picchi stagionali di lavorazione dei sistemi in esercizio, per un arco orario esteso alle ore 24:00 nei giorni dal lunedì al venerdì.

La disponibilità ad intervenire extra orario, deve essere garantita, per un numero di 10 persone designate di concerto con Consip in relazione alle criticità ed ai picchi stagionali di lavorazione dei sistemi in esercizio, per un arco orario esteso alle 24.00 nei giorni dal lunedì al venerdì.

I livelli base di reperibilità e disponibilità suddetti, o eventuali livelli migliorativi contenuti in offerta, sono da considerare già remunerati nel corrispettivo globale della fornitura; le ore di presenza effettivamente prestate saranno perciò fatturate alla tariffa base stabilita a contratto per la relativa figura professionale, indipendentemente dal giorno o dall’ora della prestazione. Il Fornitore produrrà un rendiconto mensile del servizio prestato, che dovrà essere approvato da Consip

Eventuali esigenze eccezionali di reperibilità e/o disponibilità eccedenti i livelli contrattuali così fissati saranno all’occorrenza negoziate e regolate tra le parti.

5.4 Pianificazione e Consuntivazione

5.4.1 Piano di Lavoro

Per ogni servizio previsto a contratto dovrà essere predisposto e mantenuto costantemente aggiornato un Piano di Lavoro contenente attività, tempi e impegno, con la seguente articolazione:

• per i servizi a carattere continuativo, un piano per ogni area/servizio,

• per i servizi a carattere progettuale, un piano per ogni Obiettivo.

A livello aggregato, secondo criteri da definire congiuntamente a inizio lavori, potrà essere richiesta la predisposizione ed il mantenimento di piani riepilogativi di sintesi che permettano una vista integrata d’assieme di un set definito di servizi ed obiettivi.

La versione iniziale del piano dovrà essere prodotta dal Fornitore e approvata da Consip:

• per i servizi a carattere continuativo, a inizio fornitura o alla loro prima attivazione,

• per i servizi a carattere progettuale, durante la fase di Definizione.

La pianificazione iniziale verrà approvata con le modalità previste in funzione delle tipologie di fornitura, sotto forma di verbale o di lettera di approvazione. Successivamente sarà cura del Fornitore comunicare e concordare con Consip ogni eventuale ripianificazione delle attività, aggiornando e riconsegnando a Consip il relativo Piano di Lavoro. La ripianificazione verrà formalizzata sotto forma di verbale.

Il Piano di Lavoro e le sue modifiche, come formalizzate nei verbali, certificano ai fini contrattuali gli obblighi formalmente assunti dal Fornitore, e accettati da Consip, su stime e tempi di esecuzione delle attività e sulle relative date di consegna dei prodotti (scadenze).

5.4.2 Valutazione delle dimensioni degli Obiettivi

Il dimensionamento degli Obiettivi in termini di impegno progettuale dovrà essere effettuato ove previsto e possibile utilizzando la metrica dei Punti Funzione e ricavando l’impegno in Giorni Persona (da utilizzare per la pianificazione) in base alla produttività stabilita. Laddove la metrica dei Punti Funzione non sia prevista o non risulti applicabile, il dimensionamento degli Obiettivi sarà effettuato direttamente in Giorni Persona.

Gli Obiettivi relativi a prodotti software di mercato, da integrare nel SIRGS ed eventualmente personalizzare e/o adattare in termini di funzionalità, specialmente qualora assumano carattere rilevante e prevalente attività di riconfigurazione di parametri, variazioni e/o popolamento di template, variazioni di file di stile, variazioni di font, variazioni indotte da evoluzioni tecnologiche della piattaforma, ecc., generalmente non si prestano ad essere quantificati e conteggiati in Punti Funzione, in quanto non introducono funzionalità aggiuntive percepibili dall'utente. Essi saranno dimensionati direttamente in Giorni Persona.

Obiettivi misurati in Punti Funzione

Il dimensionamento degli Obiettivi misurati in Punti Funzione dovrà avvenire, sia per Obiettivi di tipo gestionale sia di tipo conoscitivo, nei seguenti momenti:

• Stima iniziale - in fase di Definizione;

• Stima di revisione - al termine della fase di Analisi (ciclo completo) o Analisi e Disegno (ciclo ridotto) o Progettazione (ciclo data warehouse) o analoga fase per gli altri cicli di sviluppo;

• Consuntivo - al termine della fase di Realizzazione (ciclo completo e ridotto) o analoga fase per gli altri cicli di sviluppo.

La stima iniziale va effettuata con la massima accuratezza in dipendenza degli elementi a disposizione; all’atto della revisione invece tutti gli elementi di valutazione sono disponibili.

Al termine della fase di Realizzazione dovrà essere effettuata la consuntivazione dell’Obiettivo, contestualmente al conteggio della baseline. La dimensione dell’Obiettivo risultante a consuntivo sarà assunta come riferimento ai fini della fatturazione, salvo il caso in cui superi di oltre il 10% la stima di revisione. In tal caso, ai fini della fatturazione, il valore definitivo dei PF di impegno dell’Obiettivo sarà pari alla stima di revisione aumentata del 10%.

Nel caso in cui, durante le fasi successive alla revisione, Consip richieda modifiche alle funzionalità previste o comunque requisiti che possono comportare variazioni di stima, occorre procedere ad una nuova stima dell’effort progettuale, che dovrà comunque essere approvata da Xxxxxx, e sarà assunta come stima di revisione in luogo della precedente.

Obiettivi misurati in Giorni Persona

Il dimensionamento degli Obiettivi misurati in Giorni Persona dovrà avvenire, sia per Obiettivi di tipo gestionale sia di tipo conoscitivo, in fase di Definizione. Tale valore costituisce un riferimento fisso ai fini della fatturazione, indipendentemente dall’effettivo consumo di risorse a cui il Fornitore potrà andare incontro in corso d’opera. Solo in casi eccezionali, a fronte di eventi imprevisti di forza maggiore, tale valore potrà essere riconsiderato, previa approvazione da parte di Consip.

Modalità di conteggio in Punti Funzione

Il dimensionamento in Punti Funzione degli Obiettivi dovrà essere effettuato secondo le modalità di conteggio descritte nei documenti Consip “Standard conteggio PF – Indicazioni generali “, “Standard conteggio PF – Applicazioni data warehouse” , “Standard conteggio PF – Applicazioni con interfaccia GUI”; “Standard conteggio PF – Regole per il Calcolo dell’Effort Progettuale”.

Le informazioni da riportare per il conteggio dei Punti Funzione sono dettagliate nell’Appendice 4.

5.4.3 Tempo ottimale di sviluppo ‌‌

Per ogni Obiettivo di sviluppo software gestionale gestito con modalità progettuale a ciclo completo si intende come “tempo ottimale di sviluppo” il valore indicato n:ella formula (1):

Tott = 2,5× PM 0,38

(1)

PM = PF

20× prod

dove PM è l’impegno complessivo espresso in mesi persona delle attività di sviluppo relative all’Obiettivo che sono a carico del fornitore (esclusa la garanzia in esercizio).

(2)

Quando è adottata la metrica PF, l’impegno si calcola a partire dai punti funzione (ADD + CFP + CHGA) dell’Obiettivo e dalla produttività dichiarata in offerta (PF al giorno persona), secondo la formula (2) indicata sopra.

Il valore Tott (espresso in mesi solari) costituisce la durata limite suggerita per la pianificazione dell’Obiettivo, calcolata come intervallo temporale che intercorre tra l’attivazione e l’accettazione finale da parte di Consip. Ogni Obiettivo avrà perciò una data fine (pianificata) e una data limite (applicando Tott). Le due date possono coincidere.

Il tempo ottimale di ciascun Obiettivo fissato in fase di Definizione potrà essere ricalcolato in caso di modifica dei requisiti in corso d’opera che comportino una variazione della dimensione dell’Obiettivo stesso. In tale eventualità, per fissare il nuovo valore di data limite, si potrà applicare un opportuno fattore correttivo che tenga conto del tempo già trascorso dalla data di attivazione alla data di ripianificazione.

5.4.4 Osservabilità

Nel Piano di Lavoro degli Obiettivi, la durata delle singole attività elementari non può superare di norma le 2 settimane solari; nel caso di attività la cui durata sia superiore alle 2 settimane, in ogni modo, dovranno essere previste milestone intermedie con indicazione dei prodotti attesi, anche semilavorati.

5.4.5 Stato avanzamento lavori

Per tutti gli Obiettivi e per i servizi di gestione, il Fornitore dovrà mantenere aggiornato lo stato di avanzamento dei lavori relativamente al Piano di Lavoro approvato, fornendo tempestivamente indicazioni sulle attività concluse ed in corso, su eventuali criticità/ritardi, su azioni di recupero e razionali dello scostamento.

5.4.6 Consuntivazione

La consuntivazione delle attività svolte con modalità a consumo dovrà essere predisposta mensilmente attraverso il paragrafo “Effort Progettuale” del Piano di Lavoro, relativamente a ciascuna area funzionale e ciascun servizio.

5.5 Qualità ‌

La qualità della fornitura dovrà essere assicurata dal Fornitore, rispettando i criteri di qualità del proprio processo, e con l’applicazione del Piano della Qualità Generale e del Piano della Qualità Obiettivo, descritti all’Appendice 6.

Il Piano della Qualità Generale definisce le caratteristiche qualitative cui deve sottostare l’intera fornitura, mentre il Piano della Qualità Obiettivo definisce le caratteristiche specifiche relative al singolo Obiettivo o le eventuali deroghe dal Piano della Qualità Generale. Se non esistono ragioni di specificità o deroghe a quanto previsto nel Piano della Qualità Generale il Piano della Qualità Obiettivo non è richiesto. Le attività continuative fanno riferimento al Piano della Qualità Generale.

Le eventuali deroghe al Piano della Qualità Generale possono riguardare anche una diminuzione o un innalzamento dei valori soglia di specifici indicatori, che potranno essere variati nell’interesse dell’Amministrazione e dovranno essere comunque concordati con Consip. Tali deroghe potranno essere applicate ad esempio nei casi in cui la pianificazione degli Obiettivi si discosti sensibilmente dal tempo ottimale di sviluppo.

Il Piano della Qualità Generale e il Piano della Qualità Obiettivo saranno redatti dal Fornitore sulla base del proprio manuale di qualità e dello schema esposto all’Appendice 6, e costituiranno il riferimento anche per le attività di verifica e validazione svolte dal Fornitore, all’interno dei propri gruppi di lavoro.

Il Piano della Qualità Generale dovrà basarsi sugli indicatori di qualità specifici per la fornitura dettagliati all’Appendice 5, a meno di eventuali proposte migliorative offerte dal Fornitore.

Il Piano della Qualità Generale e il Piano della Qualità Obiettivo dovranno essere aggiornati a seguito di significativi cambiamenti di contesto in corso d’opera, o comunque su richiesta Consip, ogni qual volta lo reputi opportuno. Essi devono essere riconsegnati aggiornati a livello di intero documento, e non per le sole parti variate, e dovrà essere possibile individuare le modifiche effettuate.

5.5.1 Classe di Rischio

La classe di rischio di una applicazione o di un Obiettivo è definita come segue:

• Classe A: l’applicazione o l’Obiettivo sono caratterizzati da una elevatissima criticità dovuta alle possibili responsabilità civili e/o penali connesse alla importanza economica di dati elaborati ed al loro potenziale impatto sull’esterno. Un malfunzionamento del prodotto può provocare danni gravi e diffusi verso terzi oppure causare una consistente perdita di immagine dell’Amministrazione e di fiducia verso i servizi da essa offerti ad altre Amministrazioni e verso l’esterno;

• Classe B: l’applicazione o l’Obiettivo implicano limitate responsabilità civili e/o penali in caso di malfunzionamenti, pur trattando dati rilevanti economicamente e/o informazioni riservate. Un malfunzionamento del prodotto può provocare danni e/o una certa perdita di immagine;

• Classe C: : l’applicazione o l’Obiettivo implicano la gestione di informazioni non critiche; un eventuale malfunzionamento comporta la sola perdita del lavoro svolto, o danni di limitato valore economico.

5.6 Prodotti della fornitura ‌

L’Appendice 6 contiene i prodotti di fornitura più frequenti, per ciascuno dei quali è definito lo standard di formato e di contenuto. Per le attività svolte a modalità progettuale tali prodotti, più eventuali altri non riportati in Appendice 6, rientrano comunque in una delle tipologie riportate nella tabella che segue, e sono adottati o meno all’interno di un ciclo di sviluppo, come indicato:

Gestionale completo

Gestionale ridotto

Object Oriented

Conoscitivo

Documentazione di progetto

Piano di Lavoro dell’Obiettivo	Si	Si	Si	Si
Piano della Qualità dell’Obiettivo	Eventuale	Eventuale	Eventuale	Eventuale
Specifiche requisiti	Si	Si	Si	Eventuale
Specifiche dell'intervento		Si
Specifiche funzionali	Si		Si
Contesti e funzionalità di analisi				Si
Prototipo	Eventuale		Si	Si
Piano di test, casi di test ed esiti	Si	Si	Si	Si
Campione tecnico	Eventuale			Eventuale
Convalida sulla tecnologia	Eventuale	Eventuale	Eventuale	Eventuale

Oggetti software

Codice del sistema applicativo	Si	Si	Si	Si
Software di corredo al sistema applicativo	Si	Si	Si	Si
Codice di test e collaudo (testware)	Si	Si	Si	Si

Documentazione di corredo al sistema applicativo

Documentazione utente	Si	Si	Si	Si
Manuale di gestione applicazione	Si	Si	Si	Si
Manuale di gestione server	Eventuale	Eventuale	Eventuale	Eventuale
Manuale operativo batch	Eventuale	Eventuale	Si	Si
Modello concettuale dati	Eventuale	Eventuale	Si	Si
Disegno funzioni e dati	Si	Eventuale	Si	Si
Lista Oggetti Software	Si	Si		Si
Conteggio FP	Si	Si	Si	Si

La tabella ha valore indicativo e non è rigorosa nella terminologia né esaustiva della casistica. Eventuali altri prodotti potranno essere previsti e concordati di volta in volta, a seconda delle specifiche esigenze dell’Obiettivo. In caso di manutenzione adeguativa, in aggiunta o sostituzione dei documenti previsti in tabella, potranno servire, ad esempio:

• analisi di impatto;

• analisi di performance;

• studi comparativi.

Consip si riserva di aggiornare il formalismo attuale e il contenuto dei prodotti descritti nell’Appendice 6, nonché di emettere nuovi standard, sia come contenuti che come modalità di produzione, anche durante il corso della fornitura. Verranno concordate di volta in volta le modalità di adozione dei nuovi standard, per gli Obiettivi in corso e per quelli a venire, nei casi in cui l’aggiornamento comporti un particolare onere per il Fornitore.

5.6.1 Aggiornamento della documentazione di corredo al sistema applicativo ‌

Applicazioni già esistenti

Lo sviluppo e la manutenzione di Punti Funzione di tipo CHG per applicazioni già esistenti a inizio fornitura, a prescindere dalla tipologia di intervento e dal ciclo di sviluppo adottato, comportano l’aggiornamento della documentazione preesistente, per quanto riguarda come minimo i seguenti documenti:

• Documentazione utente;

• Manuali di gestione;

• Manuale operativo del batch;

• Documentazione dati dell’area applicativa;

• Descrizione generale delle funzionalità applicative e delle caratteristiche tecnologiche dell’area applicativa (attualmente riportata nell’Appendice 2).

La modifica della restante documentazione, o di corredi documentali strutturati diversamente da quanto elencato, sarà effettuata secondo modalità da concordare di volta in volta e riportare nei piani di lavoro e di qualità dell’Obiettivo, anche in funzione delle specificità dei singoli interventi.

Nuove applicazioni

Lo sviluppo e la manutenzione di Punti Funzione di tipo CHG per applicazioni nuove o completamente ristrutturate all’interno della fornitura, comportano l’aggiornamento di tutta la documentazione a corredo e non solamente dei documenti citati sopra.

Modalità di aggiornamento

La documentazione dovrà essere riconsegnata aggiornata a livello di intero documento o intera area, e non per le sole parti variate in conseguenza del singolo Obiettivo, e dovrà essere possibile individuare le modifiche effettuate.

Le possibili variazioni in corso d’opera all’interno di un Obiettivo comportano anche l’aggiornamento della documentazione eventualmente già consegnata, di modo che alla fine del ciclo l’intero corredo documentale sia completo, omogeneo e coerente a prescindere dalle vicende progettuali trascorse. Ciò costituisce criterio di accettazione della fornitura.

5.6.2 Modalità di consegna dei prodotti ‌

Oggetti Software

Per il software sviluppato sugli ambienti di Consip la consegna dei prodotti avverrà tramite la richiesta di sottomissione dei relativi job di trasferimento negli ambienti target definiti, comunque accompagnati da comunicazione formale (es. lettera di consegna) corredata dalla documentazione prevista.

Per il software sviluppato sugli ambienti non collegati a Consip la normale modalità di consegna è tramite supporto magnetico (dischetto, CD, disk driver rimovibile ecc.), sempre accompagnati da comunicazione formale corredata dalla documentazione prevista.

La consegna di oggetti software deve essere sempre corredata dalla relativa lista oggetti software (LOS) completa di tutte le informazioni necessarie a Consip per la gestione della configurazione e per l’aggiornamento del Master Repository4 (INFAP, INSAP, ecc.), nei contenuti e tracciati che Consip si riserva di stabilire e di modificare a sua discrezione nel corso del contratto.

Documentazione

Ogni documento dovrà essere consegnato:

• su supporto cartaceo

• in formato elettronico corrispondente al cartaceo (direttamente stampabile)

• nel formato elettronico sorgente dei singoli strumenti utilizzati (ad es. Word, Xxxxx, ecc.).

La consegna del formato elettronico dovrà avvenire, fermo restando l’obbligo di comunicazione formale, in due modalità differenti:

• tramite supporto magnetico, come software di corredo ai sistemi informativi;

• tramite posta elettronica, agli indirizzi che saranno indicati da Consip.

Consip si riserva di definire diverse modalità di consegna della documentazione in formato elettronico, che potrà avvenire ed essere riscontrata in sola via telematica, anche accedendo ad apposite applicazioni messe a disposizione presso Consip o via web.

Assenza di virus

Tutti i prodotti consegnati su supporti magnetici o in via telematica dovranno essere esenti da virus. Consip si riserva di verificare l’assenza di virus secondo le modalità e gli strumenti che riterrà più opportuni.

4 Tale sistema continuerà ad essere sviluppato proprio all’interno del presente contratto.

5.6.3 Vincoli temporali sulle consegne:‌

Piani della Qualità

Il Piano della Qualità Generale dovrà essere consegnato entro 30 giorni solari dalla data inizio fornitura. Il Piano della Qualità Obiettivo, qualora necessario, dovrà essere consegnato in fase di Definizione.

In caso vengano formalizzate osservazioni a fronte dei quali occorra apportare variazioni di contenuto ai Piani della Qualità (sia Generale che di Obiettivo), queste dovranno essere consegnate entro 10 giorni lavorativi dalla formalizzazione delle osservazioni stesse.

Piani di Lavoro

Il Piano di Lavoro dovrà essere consegnato, per le attività svolte in modalità progettuale, entro la fase di Definizione e comunque secondo quanto previsto dal ciclo di sviluppo adottato in funzione delle specifiche caratteristiche dell’Obiettivo. Dovrà, inoltre, essere riconsegnato a fronte di ogni ripianificazione entro 5 giorni lavorativi dal relativo verbale.

Il Piano di Lavoro per i servizi di gestione dovrà essere consegnato entro 1 mese solare dalla data inizio fornitura ed aggiornato in funzione delle specifiche necessità individuate, alla fine di ogni mese solare di fornitura, ai fini della consuntivazione.

Prodotti di fase

Le attività svolte in modalità progettuale prevedono la consegna di oggetti (prodotti) prestabiliti in base al ciclo di sviluppo adottato, secondo una tempificazione che è concordata e riportata nel Piano di Lavoro, che coincide in genere con l’evento di fine fase, ma che in alcuni casi può differire, come ad esempio:

⮚ i manuali di gestione, le procedure di definizione e caricamento delle tabelle ed in genere ogni informazione necessaria alla predisposizione degli ambienti di collaudo, dovranno essere consegnati almeno 5 giorni lavorativi prima della fine della fase di realizzazione;

⮚ il campione tecnico, quando previsto, dovrà essere consegnato all’interno della fase di disegno, in data da concordare, in quanto sia il disegno di dettaglio che la casistica di test dipendono dai riscontri fatti a fronte del campione tecnico stesso.

5.6.4 Modalità di approvazione dei prodotti

Piani della Qualità

Consip si riserva 20 giorni lavorativi dalla consegna per l’approvazione del Piano della Qualità Generale. Non è prevista approvazione per tacito assenso. Finché esso non è approvato valgono gli indicatori presenti in capitolato, eventualmente migliorati dall’offerta, a giudizio di Xxxxxx.

Esso dovrà essere concordato con i responsabili Consip, recependo le eventuali osservazioni. Queste saranno comunicate formalmente. Il termine per la riconsegna del Piano modificato è di 10

giorni lavorativi, se non diversamente richiesto e specificato per iscritto nella comunicazione di formalizzazione dei rilievi.

Nel caso in cui il Fornitore certificato rispetto alla norma UNI EN ISO 9001:2000 non risolva le osservazioni notificate da Consip, questa si riserva di effettuare un'apposita segnalazione al SINCERT.

L’approvazione del Piano della Qualità generale non implica approvazione dei Piani della Qualità Obiettivo, che saranno oggetto di valutazione singola all’interno degli Obiettivi di pertinenza.

Piani di Lavoro

Per le attività svolte in modalità progettuale, il Piano di Lavoro è considerato un prodotto di fase ed è quindi soggetto alle stesse regole.

Per i servizi di gestione, qualora l’aggiornamento mensile del Piano di Lavoro sia variato rispetto al precedente solo incrementalmente, per il paragrafo relativo alla consuntivazione delle attività del mese, vige il silenzio assenso. Trascorsi 10 giorni lavorativi dall’inoltro del Piano senza comunicazione formale di osservazioni da parte di Consip, esso si intende tacitamente approvato ed il Fornitore può procedere alla fatturazione dei consumi mensili.

Prodotti di fase

Consip si riserva almeno 10 giorni lavorativi (5 nel caso di ciclo ridotto) dalla consegna dei prodotti per procedere all’approvazione, quando prevista. L’approvazione sarà effettuata attraverso comunicazione formale. Non è prevista l’approvazione per tacito assenso.

La presenza di anomalie di gravità tale da impedire lo svolgimento delle attività di verifica interromperà il termine per l’approvazione, che decorrerà ex novo dalla consegna di una versione rivista, da parte del Fornitore, dei prodotti di fase.

Nel caso in cui, all’interno di una fase, siano previsti più documenti, questi potranno essere approvati singolarmente, fermo restando che tutti i documenti previsti dovranno essere approvati perché sia possibile dichiarare conclusa la fase.

5.6.5 Inventario applicativo in Punti Funzione ‌

Ogni intervento sul parco applicativo, qualora generi una modifica alla dimensione in PF della baseline presente nell’Inventario Applicativo, deve prevedere al suo termine l’aggiornamento della baseline stessa (vedi Appendice 2) secondo le modalità di conteggio descritte nei documenti Consip “Standard conteggio PF – Indicazioni generali “, “Standard conteggio PF – Applicazioni data warehouse” , “Standard conteggio PF – Applicazioni con interfaccia GUI”; “Standard conteggio PF – Regole per il Calcolo dell’Effort Progettuale”.

Il Fornitore è tenuto a consegnare la baseline aggiornata al termine della fase di collaudo e comunque a conclusione dell’intervento; le informazioni da predisporre sono riportate nell’Appendice 6.

5.7 Governo e adempimenti generali della fornitura ‌

5.7.1 Comunicazione formale

Ogni comunicazione formale relativa alla gestione ed all’esecuzione del contratto dovrà essere indirizzata all’attenzione del referente Consip destinatario della comunicazione (responsabile di contratto, responsabile di progetto e/o di servizio, monitore).

Per quanto riguarda le milestone di progetto, la modalità usuale di comunicazione formale prevede l’utilizzo di supporti scritti (verbale, lettera, nota, ecc…) prodotti e inviati comunque in formato cartaceo, ed eventualmente anticipati via e-mail, nel qual caso fa testo data e ora di inoltro dell’e-mail. Anche la consegna degli oggetti magnetici di fornitura va effettuata accompagnandola da una comunicazione al responsabile di progetto Consip (lettera di consegna, di cui il supporto magnetico contenente il materiale di consegna è l’allegato).

Quanto sopra potrà subire evoluzioni derivanti dall’introduzione di strumenti automatici a ciò deputati (es. il portale per il governo della fornitura, di cui al paragrafo 5.7.2).

5.7.2 Portale di supporto al governo della fornitura ‌

Il Fornitore renderà disponibile a Consip entro 3 mesi (o entro il termine previsto nell’offerta tecnica, se migliorativo) dalla data di inizio fornitura e per tutta la durata della fornitura, l’utilizzo di uno strumento per la condivisione di tutta la documentazione di progetto e per il controllo della fornitura nel suo complesso e/o nelle singole attività. Esso dovrà permettere a Consip l’accesso via WEB per verificare in qualsiasi momento lo stato di avanzamento dei lavori.

Le informazioni minime che dovranno essere accedibili sono i documenti ed i prodotti previsti obbligatoriamente dal presente capitolato, senza peraltro che la catalogazione sul portale si sostituisca agli obblighi di comunicazione previsti dal presente capitolato.

Tuttavia, a fronte della soluzione proposta dal Fornitore, per le proposte e le modalità attuative concordate con Consip, il portale può ampliare il proprio scopo, rendendo disponibili altre informazioni (ad esempio: documenti in bozza, esiti delle attività di test, risultati delle misurazioni dei livelli di servizio o degli indicatori di qualità, ecc.) tese a facilitare la verifica dell’effettivo andamento dei lavori, ad anticipare la gestione dei problemi, ad efficientare le attività di monitoraggio.

5.7.3 Referenti

Per l’intera fornitura dovrà essere indicato dal Fornitore un responsabile unico (Responsabile delle attività contrattuali), cui Xxxxxx farà riferimento per gli aspetti generali, o potrà scalare per ogni problema riguardante la fornitura stessa, di norma nella persona del responsabile del contratto Consip.

E’ facoltà del Fornitore prevedere altri referenti, nel qual caso ne dovrà dare disponibilità in sede di offerta. Consip si riserva di decidere, sulla base delle proposte del Fornitore ma senza vincolo, le aree o servizi più idonei all’impiego di tali referenti.

Rientrano nella gestione dell’Obiettivo tutte le attività legate alla corretta esecuzione della fornitura, quali, ad esempio, la stima, la pianificazione e la consuntivazione, gli adempimenti legati alla qualità, il controllo dell’avanzamento lavori, le attività di valutazione e contenimento dei rischi. Si sottolinea a questo proposito il ruolo fondamentale dei capi progetto che il Fornitore intende impiegare sulle attività svolte a modalità progettuale, essi avranno un referente corrispondente di Consip, designato per la gestione di primo livello dell’andamento ordinario delle attività e dei problemi che dovessero presentarsi.

Si sottolinea infine che, a prescindere dall’organizzazione che il Fornitore adotterà per l’erogazione dei servizi, è richiesto un alto grado di sinergia tra le risorse impiegate nello sviluppo e quelle impiegate nella gestione nella fase di avviamento in esercizio dell’applicazione, al fine di garantire un costante e adeguato grado di conoscenza e di attenzione evitando discontinuità.

5.7.4 Rilievi e penali ‌

I rilievi sono le azioni di avvertimento da parte di Xxxxxx conseguenti il non rispetto delle indicazioni contenute nella documentazione contrattuale (contratto, capitolato e sue appendici, standard Consip, offerta, Piano della Qualità Generale, Piano della Qualità Obiettivo e Piano di Lavoro). Essi consistono di comunicazioni formali al Fornitore che non prevedono di per sé l’applicazione di penali, ma costituiscono avvertimento sugli aspetti critici della fornitura e, se reiterate e accumulate, possono dar adito a penali, secondo quanto previsto in Appendice 5 e determinato nel contratto.

I rilievi possono venire emessi dal responsabile del contratto Consip o dai responsabili di progetto e/o di servizio Consip, secondo una casistica definita, e sono formalizzati attraverso una lettera di rilievo.

5.7.5 Test automatici e certificazione ‌

Per ogni Obiettivo, la predisposizione e l’esecuzione automatica di tutte le attività di verifica e validazione [test di modulo, di funzione, di integrazione (o di sistema), di prestazione, di sicurezza, di compatibilità, di usabilità, di stress o di carico del sistema, ecc.] previste dal Piano di Test, è consigliata all’interno di ogni fase, ed in particolare nell’ambito della Realizzazione,

Per ogni Obiettivo di sviluppo di tipo gestionale, la predisposizione e l’esecuzione di test funzionali automatici è richiesta come obbligo contrattuale.

A fronte dell’effettivo utilizzo di strumenti automatici di test, il Fornitore dovrà consegnare i report prodotti. Tali report dovranno essere consultabili e verificabili da parte di Consip anche senza l’utilizzo dello strumento specifico.

Consip si riserva di definire, anche successivamente all’inizio delle attività contrattuali, il prodotto da utilizzare per i test funzionali. Tale prodotto dovrà essere adottato per gli obiettivi che saranno attivati successivamente a tale comunicazione. Per gli obiettivi/applicazioni per i quali esistesse già il codice di test, sviluppato su un prodotto diverso da quello indicato da Consip, verranno congiuntamente concordate le modalità di lavoro da applicare.

Automazione test funzionali

Un test di funzione o di applicazione si compone di una sequenza di test elementari (casi di test, ad ognuno dei quali tipicamente corrisponde una segnalazione5 di ok, di warning o di errore), che si possono distinguere in:

• casi di test informatici (es. controllo di validità di un valore in un campo);

• casi di test applicativi (es. controllo di quadratura dopo un’elaborazione di altri dati in input o presenti sulla base dati).

I test di funzione devono essere prodotti in modo da assicurare la seguente copertura:

⮚ almeno 1 test per ogni funzione e almeno 0,5 casi di test per Punto Funzione;

⮚ almeno 1 caso di test per ogni segnalazione intrafunzionale (di ok, di warning o di errore);

⮚ i casi di test sono di natura informatica e/o applicativa.

I test di applicazione devono essere prodotti in modo da assicurare la seguente copertura:

⮚ almeno 1 test per ogni applicazione e 0,2 casi di test per Punto Funzione;

⮚ almeno 1 caso di test per ogni segnalazione interfunzionale (di ok, di warning o di errore);

⮚ i casi di test devono essere tipicamente di natura applicativa.

I casi di test riusati sono conteggiati tante volte per quante volte sono usati. I livelli di copertura sui casi di test si intendono come valore medio dell’Obiettivo.

Codice di test e collaudo

Parte integrante del collaudo che Consip intende effettuare è la certificazione, presso un laboratorio appositamente predisposto, di ogni rilascio in esercizio, per garantire sia l’aderenza agli standard e la compatibilità alle piattaforme di riferimento dei sistemi applicativi, che la non regressione di effetti negativi sulle altre applicazione che condividono la stessa rete e lo stesso parco client.

A richiesta Consip, il codice di test e collaudo (casi di test, script, set up dati di prova ecc.) relativo agli Obiettivi di sviluppo di tipo gestionale, dovrà essere consegnato come parte integrante della fornitura, per essere catalogato e riusato nell’ambito delle attività di manutenzione e di certificazione.

Nel caso di manutenzione su applicazioni per le quali sia stato già prodotto il codice di test e collaudo, questo dovrà essere riutilizzato, aggiornato e riconsegnato a fronte dell’intervento di manutenzione effettuato.

Il codice di test e collaudo deve essere realizzato in forma autoconsistente. Il test perciò sarà composto di una prima parte di cleaning o set up della porzione di base dati che sarà utilizzata e di una seconda parte composta dall’insieme dei casi di test di cui il test si compone. La parte set up potrà essere realizzata in forma autonoma e comune per essere usata da più di un test.

5.7.6 Supporto sistemistico

Durante tutto il ciclo di sviluppo deve essere garantito dal Fornitore il supporto sistemistico ai propri sviluppatori, al fine di assicurare, in particolare:

• l’assistenza ad analisti e programmatori per lo sviluppo e la manutenzione;

5 Messaggio / risultato operazione comunicato dal programma all’utente attraverso un media d’interfaccia

• l’ottimizzazione delle prestazioni dei programmi;

• il tuning degli accessi alle basi dati;

• la predisposizione degli ambienti di test, delle banche dati di prova, ecc.

Inoltre il supporto sistemistico deve comprendere:

• l’acquisizione delle specifiche tecniche e delle architetture già definite che devono essere adottate per l’Obiettivo e/o le attività di interfaccia con i tecnici designati da Consip per concordare aspetti tecnici specifici;

• il supporto, rivolto a personale Consip (o a terzi da essa designati) per le attività connesse alla predisposizione e all’esecuzione del collaudo e all’avvio in esercizio.

5.7.7 Compatibilità

I prodotti che compongono gli ambienti di sviluppo, collaudo ed esercizio sono elencati nell’Appendice 2 e nell’Appendice 7. Tali prodotti potranno subire variazioni di release / livello nel corso della fornitura. Il software realizzato dovrà essere compatibile con il release / livello effettivo degli ambienti di collaudo / esercizio attivi al momento in cui il software verrà utilizzato. Ciò comporta la verifica, in fase di Definizione dell’Obiettivo, degli effettivi release e dell’eventuale piano di evoluzione degli ambienti. Nel caso di modifiche impreviste in corso d’opera dei prodotti in uso, si concorderà l’eventuale impegno per l’adeguamento dei prodotti già realizzati.

5.7.8 Configuration management

I prodotti di configuration management utilizzati per i sistemi di Bilancio e Finanza Pubblica sono i seguenti:

• CCC/LCM per ambiente MVS;

• Harvest per ambienti dipartimentali/distribuiti.

E’ in corso l’implementazione della soluzione Harvest per le varie aree/applicazioni. Non si prevede che essa sia terminata prima della data inizio fornitura su ambiente dipartimentale

/distribuito utilizzano al momento il prodotto di configuration.

Al Fornitore è richiesta la conoscenza di tali prodotti in quanto dovranno essere utilizzati dal Fornitore stesso per tutte le attività di propria competenza. Nel caso di sviluppi presso le proprie sedi, al Fornitore è richiesto comunque di predisporre quanto necessario ad una corretta gestione del software con tali prodotti e negli ambienti indicati, con cui dovrà interagire dal momento della consegna dei vari componenti.

Il dettaglio degli ambienti e le modalità di utilizzo sono descritte nell’Appendice 8.

5.8 Ambienti di sviluppo e luogo di lavoro ‌

Il luogo di esecuzione del contratto è fissato presso il Ministero dell’Economica e delle Finanze, Dipartimento della Ragioneria Generale dello Stato, Xxx X. Xxxxxxx, 00 Xxxx.

I servizi oggetto della fornitura saranno svolti presso le sedi del Fornitore, su posti di lavoro attrezzati di stazioni di lavoro a carico del Fornitore, oppure, in determinati casi, presso le sedi di Consip o dell’Amministrazione, nel qual caso valgono le condizioni riportate nella tabella seguente:

Servizio	Quando presso Consip	Chi provvede le stazioni di lavoro	Qual è la disponibilità di posti di lavoro
Sviluppo	A discrezione Consip	Fornitore	75 posti di lavoro
Supporto informatico
Manutenzione evolutiva
Manutenzione adeguativa
Manutenzione correttiva
Prodotti/servizio	Sempre	Consip	Numero sufficiente di posti di lavoro
Front end
Back end

I posti di lavoro attrezzati relativi ai servizi di gestione, come pure i 75 non attrezzati relativi agli altri servizi, sono disponibili presso il luogo di esecuzione del contratto.

Consip si riserva di ridurre in corso d’opera la disponibilità dei posti di lavoro non attrezzati presso le sedi dell’Amministrazione, dandone comunicazione al Fornitore con almeno 3 mesi di anticipo. Invece, ogni variazione del numero di posti di lavoro attrezzati disponibili presso sedi dell’Amministrazione sarà concordata tra le parti.

I posti di lavoro non attrezzati consistono di locali idonei ad accogliere gruppi di lavoro, dotati della normale attrezzatura di ufficio e cablati per il collegamento agli elaboratori, in modalità di tipo Ethernet. Il Fornitore è tenuto ad attrezzare tali posti di lavoro con proprie stazioni di lavoro (possibilmente PC non portatili, senza modem) dotate del relativo software di base, dei programmi antivirus e degli strumenti software necessari all’esecuzione dei servizi contrattuali, come ad esempio prodotti per lo sviluppo di software applicativo. Non è permesso al Fornitore utilizzare contemporaneamente le stazioni di lavoro per il collegamento alla rete Ethernet e remotamente via modem. Consip metterà a disposizione un pool di stazioni di lavoro da cui il Fornitore potrà accedere a Internet. Consip renderà disponibile al Fornitore il servizio di posta elettronica, tramite la definizione di caselle personali su serventi Consip.

I posti di lavoro necessari al Fornitore presso le proprie sedi, devono essere dotati, a suo carico, del necessario corredo hardware e software, sia di base che di sviluppo.

Per gli ambienti MVS, Unix data warehouse e Unix Actuate, Consip permetterà il collegamento all’ambiente di sviluppo. Inoltre Consip fornirà il software client Power Center. La definizione della tipologia ed il costo delle linee di collegamento e del router saranno a carico del Fornitore. Il tipo di collegamento dovrà essere router to router, ISDN o punto punto dedicato. Nel caso di necessità di scarico di dati in modo estemporaneo sarà possibile utilizzare FTP.

Relativamente a sviluppo e manutenzione basati su elaboratori Consip, a inizio fornitura verrà concordata con il Fornitore la potenza elaborativa di cui ha bisogno, in funzione della numerosità del gruppo di lavoro. Sarà poi cura del Fornitore organizzare le proprie modalità di lavoro in modo da sfruttare correttamente la potenza assegnata, utilizzando specifici strumenti, messi a disposizione da Consip, per monitorare il sistema. L’utilizzo di eventuali prodotti software (diversi da quelli in uso) che dovessero rendersi necessari per l’esecuzione di talune attività, se concordati con Consip, verranno resi disponibili da Consip stessa. Rimangono a carico del Fornitore tutte le attività connesse all’installazione di tali prodotti nei propri ambienti.

Una descrizione dettagliata degli attuali sistemi è riportata nell’Appendice 7.

5.9 Monitoraggio ‌

Consip si riserva di procedere al monitoraggio previsto dall’art.13 comma 2 del decreto legislativo n.39/93 secondo i criteri e le modalità stabiliti dalla circolare AIPA/CR/38 del 28 dicembre 2001 nei riguardi del Fornitore anche qualora non ricorrano i limiti di cui alla citata circolare.

Il Fornitore si impegna a fornire a Consip tutti i documenti necessari all’attività di monitoraggio, a partire dalla data di inizio fornitura, nei formati standard richiesti, salvo evoluzioni derivanti dall’introduzione di strumenti automatici a ciò deputati (es. il portale per il governo della fornitura, di cui al paragrafo 5.7.2).

La funzione di monitoraggio sarà svolta dalla Consip, o da soggetto da essa incaricato. Il Fornitore si impegna a inviare alla Consip la documentazione comprovante l’esito delle visite di sorveglianza della società di certificazione della qualità entro un mese dalla data della verifica. Inoltre il Fornitore e/o i subfornitori potranno essere fatti oggetto di verifiche ispettive effettuate dalla Consip tramite personale proprio o da terzi da essa incaricati, svolte nel rispetto di quanto prescritto dalla serie di norme UNI EN ISO 19011:2003.

Consip si riserva di effettuare controlli anche sullo stato di avanzamento delle attività presso la sede del Fornitore.

5.10 Gestione dell’avvicendamento contrattuale

5.10.1 Addestramento a inizio fornitura

Nei 2 mesi precedenti la data inizio fornitura è data la possibilità al Fornitore di richiedere a Consip di usufruire di addestramento, al fine di permettere al proprio personale di prendere in carico al meglio i servizi di manutenzione adeguativa, correttiva e di gestione. Tale addestramento potrà consistere, ad esempio, in riunioni di lavoro, esame della documentazione esistente con assistenza di personale esperto, affiancamento nell’operatività quotidiana di manutenzione correttiva e gestione condotta dal fornitore uscente, senza peraltro la possibilità di eseguire direttamente le attività (training on the job).

Le modalità di fruizione e la relativa pianificazione di tale addestramento dovranno essere concordate con Xxxxxx, anche sulla base delle proposte che il Fornitore potrà fare in sede di offerta. Consip garantirà la presenza di personale esperto, che potrà essere sia di Consip stessa che di terzi da essa designati.

5.10.2 Trasferimento di know how ‌

Nel corso dell’esecuzione del contratto il Fornitore dovrà, su richiesta Consip, trasferire a personale Consip, o a terzi da essa designati il know-how sulle attività condotte, al fine di rendere l’eventuale prosecuzione delle attività quanto più efficace possibile, secondo un programma formativo che preveda ad esempio docenze, sessioni riassuntive, sessioni di lavoro congiunto, presentazioni, tavole rotonde, ecc. su funzioni, disegno, codice e documentazione dei sistemi di Xxxxxxxx e Finanza Pubblica;

Nell’ambito di tale programma il Fornitore dovrà , se richiesto, ospitare il personale del nuovo Fornitore in affiancamento nell’operatività quotidiana di manutenzione correttiva e gestione condotta dal fornitore uscente, senza peraltro che questi abbia la possibilità di eseguire direttamente le attività (training on the job).

Le modalità di erogazione e la relativa pianificazione del trasferimento di know how dovranno essere concordate con Xxxxxx, anche sulla base delle proposte che il Fornitore potrà fare in sede di offerta. A parte l’ospitalità in affiancamento, le altre attività concordate e pianificate saranno remunerate, a consumo, all’atto dell’avvenuta prestazione (prodotto/servizio).

5.10.3 Garanzia ‌

Deve essere garantita, come parte integrante dei servizi di sviluppo e manutenzione, la correzione gratuita dei difetti:

• degli oggetti software nuovi e/o modificati;

• delle basi dati deteriorate come ripercussione dei difetti;

• della documentazione;

con gli stessi livelli di servizio previsti per la manutenzione correttiva:

⮚ per i primi tre anni contrattuali, per tutti i prodotti collaudati (o forma equivalente);

⮚ per il quarto anno contrattuale, per tutti i prodotti collaudati (o forma equivalente) nel corso del terzo anno.

Document Metadata

Table of Contents

ALLEGATO 6 - CAPITOLATO TECNICO

Document Metadata

ALLEGATO 6 - CAPITOLATO TECNICO

ALLEGATO 6 - CAPITOLATO TECNICO

4

6

12

17

22

Documentazione di progetto

Oggetti software

Documentazione di corredo al sistema applicativo

Document Metadata