Contract
INPDAP – Istituto Nazionale di Previdenza per i Dipendenti delle Amministrazioni Pubbliche Gara per Implementazione del Sistema Istituzionale INPDAP Mediante Re-engineering
Normalizzazione del
Sistema Informativo dell’Istituto:
IMPLEMENTAZIONE DEL SISTEMA ISTITUZIONALE INPDAP MEDIANTE RE-ENGINEERING
Capitolato tecnico
Capitolato Tecnico Pag. I/II
INDICE
1.1 Le Problematiche generali 1
1.2 Il Programma di Normalizzazione 2
2. IL SISTEMA INFORMATIVO ATTUALE 3
2.3 Limiti del Sistema attuale 5
3. LINEE EVOLUTIVE DEL SISTEMA INFORMATIVO INPDAP 6
3.1 Strategia di rinnovamento 6
3.2 Infrastruttura Hardware e Software 7
3.3 Architettura applicativa dell’ambiente target 10
4.2.1 Le applicazioni esistenti oggetto del progetto di reenginnering 13
4.2.3 Il processo di sviluppo 17
4.3 Gestione coesistenza Banca Dati 17
4.5 Manutenzione Adeguativa, Migliorativa, Evolutiva 18
4.6 Manutenzione Correttiva 19
4.7 I SERVIZI ASSOCIATI AL PROGETTO 19
4.7.1 Conduzione del Progetto 19
4.7.3.2 Formazione on line (WBT) 23
4.7.4 Assistenza agli Utenti 24
4.7.4.1 Conduzione Funzionale 24
4.7.4.2 Help Desk 2° Livello 25
4.7.4.3 Rilascio a fine fornitura 25
4.7.5 Avviamento in Esercizio 26
4.7.5.1 Supporto al Collaudo 26
4.7.5.2 Assistenza per l’avviamento in esercizio 27
Capitolato Tecnico Pag. II/II
4.7.6 Supporto alla gestione operativa 27
5. MODALITA’ DI ESECUZIONE DELLA FORNITURA 28
5.1 Gestione della fornitura 28
5.1.2 Consuntivazione e Controllo avanzamento 28
5.1.3 Monitoraggio del Progetto 29
5.1.4 Prodotti e documentazione di fase 29
5.2 Dimensionamento, mix delle risorse e modalità di remunerazione 31
5.2.2 Altri servizi misurati in Punti Funzione 32
5.2.3 Servizi misurati in Giorni Persona 33
5.5 Infrastrutture necessarie allo svolgimento dei lavori 35
6. ORGANIZZAZIONE E PROFILI PROFESSIONALI 36
7.2.1 Indicatori di qualità nello sviluppo software 45
7.2.2 Indicatori di qualità dei servizi 50
INDICE DELLE FIGURE
FIGURA 1 – L’AMBIENTE DI ESERCIZIO 8
FIGURA 2 – L’AMBIENTE DI SUPPORTO 9
INDICE DELLE TABELLE
TABELLA 1 – AREE FUNZIONALI OGGETTO DI RE-ENGINEERING 13
TABELLA 2 – SERVIZI DELLA FORNITURA - PRINCIPALI PRODOTTI 31
TABELLA 3 – DIMENSIONE DELLE SINGOLE AREE FUNZIONALI 31
TABELLA 4 – SERVIZI MISURATI IN PUNTI FUNZIONE 32
TABELLA 5 – SERVIZI MISURATI IN GIORNI PERSONA 33
TABELLA 6 – LIVELLI E PROFILI PROFESSIONALI 36
1. INTRODUZIONE
Il presente documento rappresenta il Capitolato Tecnico relativo alla fornitura per la “Implementazione delle aree Sistema Istituzionale ottenibili mediante Re-Engineering” da attuare nell’ambito complessivo del programma di Normalizzazione del Sistema Informativo dell’Istituto Nazionale di Previdenza per i Dipendenti della Pubblica Amministrazione.
1.1 LE PROBLEMATICHE GENERALI
L’INPDAP nasce dalla fusione degli Enti preposti alla previdenza dei dipendenti dello stato e delle amministrazioni locali. Istituito con il Dlgs 30/6/1994, l’INPDAP ha unificato in un nuovo soggetto giuridico le funzioni in precedenza attribuite a una pluralità di enti ed istituti (ENPAS, INADEL, ENPDEP e le quattro casse pensionistiche gestite dagli Istituti di Previdenza del Ministero del Tesoro: CPDEL, CPS, CPI, CPUG).
L’INPDAP costituisce oggi il polo unico responsabile della gestione previdenziale obbligatoria per il settore pubblico. Il suo ruolo è complementare a quello svolto dell’INPS, responsabile della gestione obbligatoria per il settore privato.
L’attuale Sistema Informativo è il risultato dell’aggregazione dei sistemi informativi appartenenti agli Enti ora disciolti. Le funzionalità del Sistema, corrispondenti inizialmente a quelle fornite dai singoli sistemi aggregati, si sono ampliate nel tempo al crescere dei compiti affidati all’Istituto. Tali compiti sono connessi in particolare alla gestione della posizione contributiva e all’erogazione delle prestazioni Pensionistiche per i dipendenti pubblici, in precedenza di competenza delle Direzioni Provinciali del Tesoro.
Allo stato attuale il Sistema è caratterizzato da:
• presenza di procedure informatiche residenti su piattaforme eterogenee, non integrate, spesso fondate su tecnologie proprietarie (con la conseguente difficoltà di manutenzione e gestione operativa ) e non adeguatamente documentate sia dal punto di vista tecnico che funzionale
• copertura funzionale parziale rispetto ai compiti istituzionali dell’INPDAP e la scarsa integrazione tra le funzioni
• obsolescenza delle tecnologie informatiche utilizzate (specialmente per la componente Previdenziale).
Il Sistema richiede inoltre di essere potenziato, sia funzionalmente che tecnologicamente, per far fronte agli obiettivi di breve/medio periodo (cartolarizzazione, denuncia contributiva, protocollo informatico,…) e alle nuove esigenze organizzative previste nelle strategie dell’Istituto:
• decentramento amministrativo
• integrazione delle funzioni informatiche e di governo
• recupero di efficienza
• cooperazione con altre Istituzioni dello Stato.
1.2 IL PROGRAMMA DI NORMALIZZAZIONE
Nell’intento di fornire una risposta complessiva alle problematiche inerenti il Sistema Informativo, l’Istituto ha intrapreso un programma di profonda revisione (Normalizzazione del Sistema Informativo) che investirà le infrastrutture, le applicazioni informatiche e i servizi che sono alla base dello stesso sistema. Il programma dovrà garantire il miglioramento dei processi amministrativi e dei servizi istituzionali offerti dall’INPDAP, ottenendo nel contempo un significativo recupero dell’efficienza e una riduzione, in prospettiva, degli oneri di conduzione e di manutenzione.
Nel quadro di tali finalità generali l’Istituto ha individuato le seguenti linee di intervento:
• La Normalizzazione del Sistema Istituzionale, che prevede il rinnovamento delle applicazioni informatiche della previdenza da realizzarsi sia attraverso il possibile “riuso” del patrimonio informatico reso disponibile dall’INPS sia attraverso l’adattamento (re- engineering) del software INPDAP, sia infine attraverso lo sviluppo di nuove funzioni software a completamento del sistema.
• La realizzazione del nuovo sistema di Autogoverno, comprendente le applicazioni responsabili dei servizi interni di contabilità e gestione del personale;
• La realizzazione di Progetti specifici, relativi tipicamente ad interventi circoscritti, aventi caratteristiche di particolare necessità ed urgenza e non rinviabili rispetto ai tempi previsti per la revisione complessiva e tali comunque da essere integrabili nel progetto di normalizzazione dell’intero sistema informativo;
• L’Adeguamento tecnologico dell’Infrastruttura, comprendente la fornitura e la successiva conduzione delle apparecchiature relative alle piattaforme di esercizio, da realizzare con l’obiettivo di rendere omogenea la tecnologia di riferimento e consolidare i sistemi centralmente semplificandone la conduzione e la gestione logistica.
Per garantire il pieno controllo del programma, ciascuna linea d’intervento è articolata in progetti autoconsistenti che saranno realizzati in modo coordinato così da consentire, nel corso dello sviluppo, la piena operatività del sistema e il graduale avvio delle infrastrutture e dei servizi rinnovati.
In particolare, il progetto “Servizi e Progetti di Integrazione del Sistema” - nel seguito indicato come il “Progetto di Integrazione” - avrà il compito di individuare gli standard e le regole comuni, di governare la pianificazione complessiva del programma e di garantire la coerenza fra le diverse componenti e tecniche realizzative nell’ambito della Normalizzazione.
Il presente Capitolato Tecnico definisce i requisiti per la realizzazione dello specifico progetto di “Implementazione delle aree del sistema istituzionale, ottenibili mediante il Re-engineering delle applicazioni dell’INPDAP”, referenziato nel seguito del documento semplicemente come “Progetto di Re-Engineering”.
2. IL SISTEMA INFORMATIVO ATTUALE
Nei seguenti paragrafi è sinteticamente descritto l’attuale Sistema Informativo dell’INPDAP nelle sue componenti tecnologiche e applicative. La rappresentazione fornisce un quadro generale e preliminare dell’ambiente che costituisce la base di riferimento per il processo di re- engineering. L’analisi delle criticità del sistema attuale, non esaustiva, ha lo scopo di fornire all’offerente elementi per la definizione della proposta tecnica e per la valutazione dell’impegno necessario.
2.1 AMBIENTE TECNOLOGICO
L’ambiente tecnologico dell’attuale Sistema Informativo è costituito da un insieme di piattaforme eterogenee, comprendenti:
• Sistema Sun-Solaris, Oracle 8, ambiente NATSTAR/NCL, responsabile delle applicazioni istituzionali Previdenziali, realizzate a partire dal 1997 e parzialmente rilasciate in esercizio dal 2002
• Sistema Unisys, Cobol, Sistema Operativo e DB proprietario, fisicamente collocato nel centro di Latina, che gestisce l’esercizio delle procedure mensili per il Pagamento delle Pensioni per i dipendenti della Pubblica Amministrazione (di competenza in passato delle Direzioni Provinciali del Tesoro)
• Sistema Bull in ambiente GCOS 8, Cobol, DBMS DMIV/TP responsabile delle procedure per l’erogazione del TFR ai dipendenti delle amministrazioni statali e delle procedure per la Previdenza Complementare (SIPC)
• Sistema IBM-AIX, Web/Java, Oracle, acquisito a fine 2003 per far fronte agli sviluppi ed al successivo esercizio delle procedure di gestione dei crediti cartolarizzati
• Stazioni locali Windows, Access/VB, utilizzate per la gestione del calcolo e della liquidazione delle Pensioni per i dipendenti degli enti locali
• Sistemi server Windows, ASP/HTML, utilizzati per la gestione del sito WEB istituzionale dell’INPDAP e la gestione dei contenuti informativi in esso presenti
Il sistema di Autogoverno, non integrato con le componenti del Sistema Istituzionale, è costituito dale seguenti piattaforme:
• Sistema LSX-Olivetti, utilizzato per l’esercizio delle procedure di gestione presenze; non più coperto da tempo da alcun contratto di manutenzione sia come hardware che come software di base
• Sistema Siemens, in ambiente Unix-Reliant 5.43 e DBMS Oracle 8, utilizzato per l’esercizio delle procedure di contabilità interna sviluppate su piattaforma SAP R/3 4.OB IS/PS, in linguaggio ABAP 4
2.2 PATRIMONIO APPLICATIVO
Le macro aree funzionali del Sistema informativo Istituzionale dell’INPDAP sono le seguenti:
ANAGRAFICA
L’area anagrafica gestisce sia l’anagrafica delle amministrazioni/enti che quella dei soggetti, iscritti e non, che a qualunque titolo sono venuti a contatto con l’Istituto, in particolare:
• Anagrafica Amministrazioni Gestisce i dati anagrafici di “base” delle amministrazioni ovvero denominazione, indirizzo, competenza di lavorazione da parte Inpdap, iscrizione alle casse di competenza, attraverso funzioni di acquisizione, aggiornamento e visualizzazione.
• Anagrafica Iscritti Gestisce la posizione previdenziale (anagrafica e rapporti di lavoro) dei dipendenti pubblici attivi.
PROCESSI COMUNI
L’area gestisce, per ogni sottosistema, l’iter amministrativo della pratica nelle varie fasi di lavorazione: dall’impianto, con l’acquisizione della documentazione necessaria, all’assegnazione della pratica ad un dipendente Inpdap per la lavorazione. Inoltre, gestisce il fascicolo unico riferito al singolo iscritto e le movimentazioni dei fascicoli tra le sedi Inpdap.
ENTRATE
L’area gestisce la contribuzione obbligatoria per gli enti locali. Per il sottosistema credito, esistono funzioni di scomputo, ovvero funzioni che operano l’imputazione del versato sulle singole rate dei piani di ammortamento.
ATTIVITA’ SOCIALI
L’area gestisce i servizi sociali e di assistenza rivolti agli iscritti e ai familiari. In particolare:
• La gestione delle borse di studio
• Assicurazione sociale vita.
BASI di CALCOLO
L’area gestisce la posizione assicurativa degli iscritti che costituisce la base per la determinazione delle prestazioni previdenziali offerte dall’Istituto.
L’area comprende la gestione della posizione contributiva obbligatoria e la gestione della posizione contributiva riconosciuta e/o ricongiunta.
CREDITI
L’area gestisce i servizi inerenti l’erogazione di prestiti personali e mutui agli iscritti e le variazioni che questi subiscono nell’arco del periodo contabile.
TFS
L’area comprende la gestione dell’erogazione della buonuscita al momento della cessazione dal servizio dell’iscritto e la gestione della richiesta di riscattare periodi ai fini del TFS per aumentare l’entità della buonuscita.
RISCATTI e RICONGIUNZIONI
Le aree gestiscono l’erogazione delle prestazioni Riscatti e Ricongiunzioni ai fini pensionistici.
PENSIONI DIPENDENTI ENTI LOCALI
PENSIONI EX-DPT
L’area gestisce il primo pagamento della pensione e le successive variazioni, per i dipendenti della pubblica amministrazione (centrale e locale).
TFR
L’area gestisce l’erogazione del TFR ai dipendenti delle amministrazioni statali e locali.
2.3 LIMITI DEL SISTEMA ATTUALE
Il Sistema Informativo dell’INPDAP, nato come aggregazione di sistemi eterogenei per funzionalità e piattaforme tecnologiche, risulta oggi inadeguato a svolgere in modo efficiente i compiti istituzionali ad esso affidati. I limiti, già sintetizzati nella introduzione, sono riconducibili a:
• Scarso livello di integrazione (funzionale, informativa e tecnologica) delle diverse procedure informatiche relative agli Enti confluiti nell’INPDAP
• Copertura funzionale insufficiente rispetto ai compiti attuali e scarsa flessibilità verso adeguamenti normativi previsti
• Insoddisfacente livello qualitativo del sistema in termini di usabilità, portabilità, gestibilità, manutenibilità
I seguenti aspetti in particolare costituiscono fattori critici per il mantenimento della qualità dei servizi e della efficienza gestionale:
Tecnologia
Le diverse piattaforme tecnologiche che supportano il Sistema non costituiscono una base di riferimento valida per l’evoluzione e il rinnovamento del sistema. In particolare, l’ambiente Nastar (sul quale sono state implementate le componenti Previdenziali) risulta obsoleto sia come tool di progettazione che come ambiente target applicativo.
Banca Dati
L’immissione di dati, incoerenti e non controllati, potrebbero causare il degrado delle informazioni relative alla posizione assicurativa degli iscritti, con conseguenti ritardi e malfunzionamenti nelle procedure di certificazione della posizione assicurativa e di erogazione delle prestazioni.
Sicurezza
La politica di sicurezza implementata nel sistema non consente la gestione della profilazione degli utenti (tutti gli operatori possono operare sull’intero sistema sia per la parte anagrafica, sia per la parte prestazioni), né garantisce la tracciabilità delle operazioni effettuate. L’autenticazione degli utenti (a carico delle diverse applicazioni) poggia su archivi locali, di difficile gestione e non protetti da intromissioni e manomissioni.
3. LINEE EVOLUTIVE DEL SISTEMA INFORMATIVO INPDAP
Il progetto di Re-Engineering dovrà essere coerente, come dettagliatamente specificato nel seguito, con le linee generali di rinnovamento e con i progetti in corso o in fase di avviamento nelle diverse aree d’intervento del programma di Normalizzazione del Sistema Informativo dell’INPDAP.
Gli aspetti salienti che dovranno essere presi in considerazione per garantire tale coerenza riguardano:
• Compatibilità con la nuova infrastruttura tecnologica dell’Istituto. Costituisce il requisito fondamentale e l’obiettivo primario del progetto di Re-engineering
• Conformità al modello di architettura applicativa e agli standard tecnologici di progettazione e sviluppo previsti per l’intero Sistema Informativo
• Integrabilità della soluzione progettuale con le altre componenti funzionali e di servizio del Sistema Informativo (in primo luogo la Base Dati comune). Tale requisito si traduce nella necessità di conformare il progetto alle direttive tecniche e agli standard che saranno forniti dall’Istituto. Tali standard saranno prodotti nell’ambito del progetto “Servizi e Progetti d’Integrazione”.
Le linee di evoluzione del Sistema Informativo e lo stato dell’arte relativo ai progetti di rinnovamento dell’architettura tecnologica sono descritti nei paragrafi seguenti.
3.1 STRATEGIA DI RINNOVAMENTO
Il Sistema Istituzionale rinnovato dovrà rispondere ai requisiti architetturali e funzionali delineati nei successivi paragrafi. Il sistema, anche nell’ottica di una futura possibile integrazione con gli altri sistemi previdenziali, sarà caratterizzato da:
• Architettura tecnica (Hardware e Software di ambiente) di tipo aperto, conforme a standard di mercato, e omogenea per le diverse componenti funzionali del sistema
• Architettura Applicativa di tipo Web Based, linguaggio di programmazione JAVA, client WEB-Browser standard.
• Metodologie di sviluppo che prevedano l’impiego di UML (Unified Modeling Language) come linguaggio di modellazione e tool Case a larga diffusione di mercato.
• Indipendenza dalla Piattaforma (Portabilità). Il software non avrà dipendenze dai servizi e dalle caratteristiche peculiari di una piattaforma HW e SW.
• Reperibilià degli skill tecnici. La piattaforma e la tecnologia di sviluppo saranno di larga diffusione. Gli skill necessari per l’utilizzo saranno facilmente reperibili.
• Sinergia con gli altri sistemi della Pubblica Amministrazione per garantire servizi di: o Disaster Recovery
o Business Continuity
o Comunicazione e Cooperazione
• Qualità del Software Il sistema dovrà essere conforme ai livelli qualitativi definiti, con particolare riferimento alla completezza funzionale, alla usabilità, manutenibilità e affidabilità
• Rafforzamento della sicurezza del Sistema L’architettura tecnica dovrà favorire il controllo centrale delle risorse, della sicurezza, e delle misure di prevenzione
3.2 INFRASTRUTTURA HARDWARE E SOFTWARE
Il programma di Normalizzazione del Sistema Informativo INPDAP prevede il totale rinnovamento delle infrastrutture Hardware e Software di ambiente al fine di razionalizzare e potenziare al tempo stesso le componenti tecniche del sistema a supporto dei nuovi servizi offerti.
L’architettura HW e SW è stata ridisegnata in funzione del nuovo assetto dei servizi totalmente in chiave WEB/Internet.
Le linee generali del nuovo progetto infrastrutturale dell’INPDAP prevedono:
• La riorganizzazione dei Sistemi Centrali, al fine di ridurre il numero e la tipologia delle piattaforme elaborative
• La razionalizzazione degli ambienti operativi (Sistemi Operativi) al fine di uniformare le piattaforme software per i diversi servizi del sistema
• L’adozione di prodotti/piattaforme aperte e allo stato dell’arte relativamente ai servizi primari del sistema:
RDBMS e Datawarehouse Web e Application Server
Sistema di Sicurezza e Single Sign-On Servizi di Portale e Content Management Prodotti di System and Network Management
• L’adozione di un sottosistema di Storage (SAN) a garanzia della massima efficienza nell’accesso ai dati e della disponibilità e integrità delle informazioni
• Separazione ai fini della sicurezza dell’area di accesso al sistema (Front-end) dall’area di produzione dei servizi (back-end)
• Separazione logica/fisica dei sistemi in rapporto alle finalità di utilizzo (esercizio, supporto/sviluppo, sistemi legacy
Il layout generale della nuova architettura tecnologica del sistema è rappresentato dalla seguente figura e descritto in dettaglio nei paragrafi successivi.
Web Server
………
Web Host 1 Web Host 2 Web Host 3 Web Host n
FW
Load Balancer
SAN
Application Server
Switch Fiber Channel (ridondato)
………
partizione 1 partizione 2
partizione 3 partizione n
Sottosistema dischi
FW
RAID 5
Libreria nastro
Data Server
………
partizione 1 partizione 2 partizione 3 partizione n
Replica dati
Dati in linea
Internet
Intranet
Figura 1 – L’ambiente di esercizio
3.2.1 Ambiente di Esercizio
L’ambiente ospiterà le applicazioni e i dati responsabili dei servizi in produzione; tra cui le procedure informatiche rilasciate dalle attività previste nella presente fornitura.
E’ progettato per rispondere ad elevati requisiti di bilanciamento dinamico del carico, continuità del servizio e sicurezza ed integrità dei dati.
L’ambiente di esercizio è costituito dai sottosistemi Web, Application e Data Server opportunamente dimensionati e configurati per garantire gli obiettivi prestazionali, di continuità e di sicurezza definiti:
• per il sottosistema WEB il Sistema operativo è Linux e il Server http è Apache
• per il sottosistema Application il Sistema Operativo è UNIX rispondente agli standard open XPG4 e successivi e l’Application Server è realizzato sul prodotto IBM Websphere Application Server Network Deployment Versione 5 o successive,
• il RDBMS è Oracle 10g Enterprise Edition con l’opzione Real Application Cluster (RAC).
Nell’ambiende di esercizio sono compresi i sottosistemi di storage e di back-up, nonché tutte le apparecchiature per la gestione del traffico di rete, la sicurezza e il monitoraggio dell’intero sistema.
3.2.2 Ambiente di Supporto
L’Istituto metterà a disposizione del Fornitore un ambiente di supporto completo, che comprenderà tutte le infrastrutture necessarie alla realizzazione, messa in produzione e manutenzione delle applicazioni oggetto della presente fornitura, con l’eccezione degli strumenti di analisi e sviluppo.
In particolare, l’ambiente di supporto comprende i sistemi di Sviluppo, Collaudo, Manutenzione e Formazione.
L’ambiente è costituito da sistemi server aventi caratteristiche e funzionalità del tutto simili a quelle dell’ambiente di esercizio anche se di potenza inferiore.
Intranet
La figura che segue mostra l’architettura dell’Ambiente di Supporto.
Web Server
………
Web Host 1 Web Host 2 Web Host 3 Web Host n FW
Load Balancer
SAN
Application Server
Switch Fiber Channel (ridondato)
………
Sottosistema dischi
RAID 5
partizione 1 partizione 2 partizione 3 partizione n
Libreria nastro
FW
Data Server
………
partizione 1 partizione 2 partizione 3 partizione n
Replica dati
Dati in linea
Figura 2 – L’ambiente di Supporto
Le procedure oggetto della presente fornitura saranno implementate nell’ambito delle partizioni dedicate al sistema Istituzionale.
I sistemi operativi e i prodotti di ambiente messi a disposizione sono gli stessi dell’esercizio.
In particolare saranno rese disponibili al fornitore le necessarie licenze di WebSphere Application Server Network Deployment, Versione 5 o successive e di Oracle 10g Enterprise Edition.
3.3 ARCHITETTURA APPLICATIVA DELL’AMBIENTE TARGET
Il software applicativo implementato nell’ambito della presente fornitura dovrà essere realizzato in linguaggio Java in accordo allo standard, J2EE sull’Application Server di mercato reso disponibile dall’Istituto (IBM Websphere), descritto nei paragrafi precedenti.
In accordo allo standard J2EE, l’architettura applicativa del nuovo sistema INPDAP sarà suddivisibile nei livelli logici:
• Livello di Presentazione: | Sul lato Client, l’interfaccia utente e di presentazione dovrà essere realizzata attraverso pagine HTML gestite da un Browser standard senza nessuna componente software aggiuntiva. |
• Livello di Logica Applicativa: | I servizi di dialogo con il client e di instradamento alle applicazioni dovranno essere implementati attraverso un WEB Server. I servizi applicativi saranno implementati da un Application Server conforme allo Standard J2EE. |
• Livello Dati: | Il livello Dati del sistema dovrà essere implementato sulla piattaforma RDBMS ORACLE. |
Ciascun livello logico dell’applicazione dovrà essere realizzato secondo le modalità previste nello standard J2EE e con l’impiego dei componenti Java elementari.
In particolare:
Implementazione del Livello di Presentazione e Interfaccia Utente
Le pagine di presentazione saranno realizzate in HTML con l’inserimento di eventuali controlli di tipo Java Script. La preparazione dinamica delle pagine di presentazione sarà attuata attraverso componenti JSP (Java Server Page) presenti sul lato server. In generale non sarà consentito l’utilizzo di tecnologie ActiveX e/o applet Java, eventuali deroghe a tale limitazione saranno individuate e definite, in accordo con l’Istituto e in aderenza alle indicazioni fornite dal progetto “Servizi e Progetti di Integrazione del Sistema”.
Implementazione del Livello di Logica Applicativa
I servizi di dialogo con il livello client e di accesso ai servizi applicativi saranno implementati attraverso Servlet eseguite sotto il controllo di un WEB Server. Dovranno essere supportati i protocolli di comunicazione Http, Https e SSL.
Il progetto prevederà la separazione dei componenti che implementano la logica applicativa dai componenti di accesso ai dati. I componenti applicativi saranno realizzati sullo standard EJB Session Beans e Entity Beans. I servizi batch saranno implementati come componenti Java.
Implementazione del livello Dati
La nuova Base Dati riprogettata e popolata delle informazioni migrate dall’attuale sistema sarà gestita dal RDBMS Oracle per garantire la continuità di esercizio e la massima portabilità delle informazioni.
Integrazione con le componenti generalizzate
Il progetto dovrà garantire l’integrazione delle funzioni re-ingegnerizzate con le componenti di servizio e applicative realizzate nell’ambito del progetto generale di Normalizzazione del Sistema Informativo dell’Istituto. In particolare dovrà essere garantita l’integrazione verso lo strato di servizi comune all’intero sistema Normalizzato (per esempio Sicurezza) ovvero verso i sottosistemi esterni cooperanti (ad esempio Workflow , Contabilità).
4. OGGETTO DELLA FORNITURA
Oggetto del presente capitolato è l’insieme delle attività di implementazione di procedure software e dei correlati servizi necessari per il corretto avvio delle applicazioni sviluppate - ivi compresa la formazione agli utenti - e per la successiva gestione:
• Implementazione procedure software: o Sviluppo software
o Gestione coesistenza Banca Dati
o Popolamento Banca Dati
o Manutenzione evolutiva, adeguativa e migliorativa
o Manutenzione correttiva
• Servizi correlati
o Conduzione del Progetto
o Consulenza
o Formazione
o Avviamento in esercizio
o Assistenza utenti
o Supporto alla gestione operativa
4.1 DURATA DEL PROGETTO
La durata complessiva del progetto è stimata in 32 mesi, a partire dalla data stipula del contratto. Esso prevede:
• un avvio ipotizzato della fornitura per Xxxxxxx 2005;
• l’attività anche “in parallelo” su più aree funzionali e, per ogni area, l’erogazione dei seguenti servizi:
o consulenza
o sviluppo software
o popolamento banca dati e gestione coesistenza
o formazione
o avviamento
o manutenzione, assistenza e supporto alla gestione operativa.
L’ultimo rilascio in esercizio dovrà avvenire non oltre sei mesi prima della scadenza del contratto.
Il fornitore, in sede d’offerta dovrà presentare una prima bozza di Piano di Progetto che dovrà contenere l’ipotesi proposta per la tempificazione dei rilasci.
4.2 SVILUPPO SOFTWARE
4.2.1 Le applicazioni esistenti oggetto del progetto di reenginnering
Circa il 72% del patrimonio applicativo oggetto dell’attività di re-engineering è stato progettato e realizzato con l’impiego della tecnologia Nastar. La rimanente parte (circa il 27%) è stata invece sviluppata in linguaggio Cobol su modello applicativo Batch o On-line. La base dati corrente è di tipo relazionale (Oracle) corredata da archivi locali di tipo IS o sequenziale.
L’oggetto del re-engineering è costituito da una parte dell’attuale Sistema Informativo Istituzionale, relativamente alle aree funzionali elencate nella seguente tabella insieme agli specifici obiettivi di sviluppo previsti
Area Funzionale | Obiettivi |
Anagrafiche | Aggiornamento da denunce delle Amministrazioni |
Gestione da comunicazioni delle Amministrazioni/Sedi | |
Prestazioni Previdenziali | Trattamenti di fine rapporto |
Trattamenti di fine servizio e relativi riscatti | |
Previdenza complementare | |
Fascicolo unico | |
Gestione pratiche prestazioni previdenziali | |
Attività sociali | Borse di studio |
Assicurazione sociale vita | |
Vacanze Studio | |
Case di Soggiorno | |
Crediti | Crediti agli iscritti |
Crediti cartolarizzati | |
Credito enti/Cooperative |
Tabella 1 – Aree Funzionali oggetto di Re-Engineering
Il patrimonio applicativo esistente, oggetto dell’attività di re-engineering, sarà reso disponibile al fornitore, corredato della documentazione esistente, all’atto di avviamento del progetto.
Tale documentazione non appare oggi adeguata né dal punto di vista tecnico né da quello funzionale; per questo motivo l’Istituto nel primo periodo della fornitura, ove richiesto, organizzerà delle sessioni di illustrazione del sistema esistente.
Anagrafica Amministrazioni
Gestione della posizione, come soggetto contributivo, delle singole amministrazioni sia centrali che locali. Deve comprendere le procedure di amministrazione della posizione attraverso la rilevazione delle comunicazioni periodiche nonché i servizi rivolti alle Amministrazioni fruibili attraverso il WEB.
Anagrafica Iscritti
Gestione della posizione previdenziale (anagrafica e rapporti di lavoro) dei dipendenti pubblici sia attivi che pensionati. Deve comprendere le procedure di acquisizione, aggiornamento e consultazione nonché i servizi rivolti agli iscritti fruibili attraverso il WEB.
Dichiarazioni mensili delle Amministrazioni
Gestione della ricezione e dell’acquisizione attraverso diversi canali informatici, delle dichiarazioni delle singole amministrazioni relative ai dipendenti pubblici in carico e delle relative retribuzioni e contribuzioni.
Entrate
Gestione della ricezione delle entrate finanziarie per diverso titolo (contribuzione, crediti, riscatti, etc) e della corretta attribuzione degli importi ricevuti rispetto al credito accertato. Deve essere strettamente integrata con il sistema contabile da cui deve ricevere le informazioni sui flussi finanziari. Deve, inoltre, attivare le procedure per verificare la congruità del pagamento con gli importi dovuti. Offrire servizi WEB agli utenti (Amministrazioni, Iscritti) per la verifica della posizione contabile.
Prestazioni Previdenziali
Gestione delle prestazioni previdenziali offerte dall’Istituto sulla base della posizione assicurativa degli iscritti.
L’area deve comprendere sinteticamente:
• La gestione della posizione contributiva obbligatoria
• Le procedure per l’invio dell’estratto conto periodico agli iscritti
• La gestione del Trattamento di Fine Servizio e relativi riscatti
• La gestione delle ricongiunzioni e dei riscatti ai fini pensionistici
• La tenuta del conto di previdenza complementare
L’iter amministrativo relativo alle singole prestazioni deve essere coordinato attraverso la gestione automatica della pratica e la tenuta del fascicolo unico riferito al singolo iscritto.
A completamento delle funzionalità descritte, l’area deve offrire servizi WEB agli iscritti per la verifica della posizione assicurativa e delle pratiche in corso.
Monitoraggio entrate e morosità
Gestione delle le funzioni di identificazione e di recupero della morosità, sia nell’area della contribuzione che del credito.
Pensioni
Gestione delle funzionalità di calcolo, erogazione periodica e revisione delle prestazioni pensionistiche.
L’area Pensioni dovrà riassorbire le funzioni attualmente svolte dai sistemi di calcolo e pagamento pensione per i dipendenti di enti locali (procedura stand-alone) e dei dipendenti delle pubbliche Amministrazioni Centrali (procedure ereditate dal DPT).
Le funzionalità devono comprendere:
• L’istruttoria della pensione
• Il calcolo e la liquidazione della prima pensione
• L’erogazione periodica
• L’adeguamento della pensione
• Gli adempimenti fiscali
• La produzione dei modelli reddituali
L’iter amministrativo relativo alla pratica pensionistica deve essere coordinato attraverso la gestione automatica della pratica.
A completamento delle funzionalità descritte, l’area deve offrire servizi WEB agli iscritti e ai pensionati per la verifica della stato delle pratiche in corso.
Attività Sociali
L’area deve gestire i servizi sociali e di assistenza rivolti agli iscritti e ai familiari. In particolare:
• La gestione delle borse di studio
• Assicurazione sociale vita
• Vacanze studio
• Case di soggiorno
A completamento delle funzionalità descritte, l’area deve offrire servizi WEB agli iscritti e ai pensionati per la divulgazione e la gestione operativa dei servizi erogati.
Crediti
L’area deve offrire i servizi inerenti l’erogazione di prestiti personali e mutui agli iscritti e le successive incombenze per la riscossione dei ratei di pagamento fino alla completa estinzione del debito.
Deve comprendere anche i servizi volti alla gestione dei crediti ceduti attraverso la cartolarizzazione.
A completamento delle funzionalità descritte, l’area deve offrire servizi WEB agli iscritti e ai pensionati per la divulgazione e la gestione operativa dei servizi erogati.
4.2.2 Obiettivi generali
Il progetto di Re-Engineering dovrà rispondere ai requisiti tecnici, funzionali e organizzativi descritti in dettaglio nei paragrafi successisi. Tali requisiti possono essere sintetizzati nei seguenti punti:
3) Il processo di Re-Engineering, autonomamente proposto dall’offerente, dovrà consentire la trasformazione verso le architetture target di riferimento, garantendo la completezza funzionale e la massima salvaguardia del patrimonio applicativo e informativo corrente.
4) Il progetto di Re-Engineering dovrà prevedere un piano di realizzazione e di rilascio in esercizio che garantisca la massima continuità di servizio e la più agevole transizione fra il sistema corrente e il sistema re-ingegnerizzato. Il piano dovrà tener conto delle evoluzioni che potrebbero intervenire nel sistema nel corso dell’attività di re-ingegnerizzazione e dovrà attuare soluzioni definite dal “Progetto di integrazione” per il recupero e la trasformazione dei dati dal vecchio al nuovo modello dati.
L’approccio proposto dal Fornitore dovrà prevedere:
• il riutilizzo parziale del patrimonio applicativo esistente per le componenti che risultino funzionalmente soddisfacenti rispetto ai requisiti del nuovo sistema
• la progettazione ex-novo delle componenti applicative che risultino, nell’attuale sistema, gravemente carenti sotto l’aspetto funzionale, prestazionale o operativo (manutenibilità, usabilità, operatività), o per le quali non risulti praticabile o conveniente nessuna operazione di parziale riutilizzo o re-ingegnerizzazione
• l’integrazione delle strutture dati, utilizzate dalle funzionalità applicative implementate nel progetto di Re-Engineering, nel modello della nuova Base Informativa, definito nell’ambito del Progetto di Integrazione (vedi par. 4.3 e 4.4)
• una fase preliminare di censimento, catalogazione e valutazione del patrimonio software esistente, al fine di individuare le componenti re-ingegnerizzabili e le componenti da sviluppare ex-novo
Per le procedure che saranno il risultato dell’attività di sviluppo dovranno comunque essere rispettati i seguenti vincoli progettuali:
1) Abbandono del linguaggio originario. Non è ammessa la presenza, nell’applicazione re- ingegnerizzata, di parti residuali scritte nel linguaggio originario Natstar/NCL o Cobol.
2) Tecniche di Wrapping. Non è ammesso l’inglobamento delle funzioni software originarie all’interno di funzioni applicative ri-progettate. Non è ammessa la sola modifica dell’interfaccia d’uso delle funzioni software che lasci inalterata la struttura interna. Non è
3) Emulazione run-time. Non sono accettabili soluzioni basate su strati software in grado di emulare, a run-time, le caratteristiche dell’ambiente originario. Tale vincolo è volto sia a ridurre gli over-head elaborativi, a scapito delle prestazioni, che a garantire la manutenibilità del sistema (vedi punto sulla manutenzione)
4) Dipendenza da librerie non standard. Non è ammesso l’uso di librerie di funzioni (classi) proprietarie o non incluse nel Development Kit di Java, con l’esclusione delle componenti applicative sviluppate e fornite in forma sorgente.
5) Prodotti di mercato Non può essere previsto l’utilizzo di prodotti di mercato per lo svolgimento di servizi applicativi
6) Garanzia delle Prestazioni Il sistema re-ingegnerizzato deve garantire prestazioni adeguate alle esigenze d’uso degli utenti (funzioni on-line) o all’esigenze di gestione e amministrazione delle applicazioni (funzioni batch o di back-ground).
7) Mantenimento dei livelli funzionali originari Il sistema re-ingegnerizzato deve offrire tutte le funzionalità dell’attuale sistema, facendo riferimento alle funzioni già in esercizio, alle funzioni in corso di realizzazione e infine, alle funzioni il cui sviluppo è programmato nel corso della vita del contratto.
4.2.3 Il processo di sviluppo
Il Fornitore nell’offerta tecnica dovrà descrivere il processo di sviluppo proposto e, in particolare, le modalità operative e tecniche che consentano la transizione verso il nuovo sistema re-ingegnerizzato.
E’ a carico del fornitore l’approvvigionamento degli strumenti per l’analisi e il disegno. Tali strumenti dovranno essere coerenti con quanto già in uso presso l’Istituto: in particolare per la fase di analisi dovrà essere utilizzato il prodotto Entriprise Architect e per la fase realizzativa IBM WebSphere Application Development.
La strategia di sviluppo proposta dal fornitore dovrà prevedere la realizzazione di un prototipo tecnico funzionante che consenta di valutare la qualità e la fattibilità delle scelte tecniche operate. Il prototipo costituirà lo strumento principale per la condivisione con l’Istituto dell’impostazione tecnico/funzionale data al progetto.
Tale prototipo, soggetto ad approvazione dell’Istituto, deve implementare un Caso d’Uso significativo dell'applicazione, comprendente funzionalità di colloquio con l’utente e di accesso al Data Base.
4.3 GESTIONE COESISTENZA BANCA DATI
In considerazione dell’avvio graduale del Sistema Istituzionale Normalizzato, il servizio è volto a realizzare le procedure necessarie a gestire la transizione al nuovo sistema normalizzato, garantendo la coesistenza delle applicazioni del vecchio e del nuovo sistema.
Sarà responsabilità dei “Servizi e Progetti di Integrazione del Sistema” la definizione del nuovo Modello dei Dati, unico a livello dell’intero Sistema Istituzionale.
In particolare oggetto del servizio è lo sviluppo delle componenti che consentono la piena operatività del Sistema Istituzionale nel periodo transitorio in cui alcuni dati saranno presenti contemporaneamente nel vecchio e nel nuovo sistema, in aderenza con quanto definito dal “Progetto di Integrazione”
4.4 POPOLAMENTO BANCA DATI
Nell'ambito di questo servizio dovranno essere realizzate le procedure di estrazione, trasformazione e popolamento dei dati per la migrazione dei dati dalla base dati corrente alla base dati del Nuovo Sistema Istituzionale. Le attività relative dovranno essere coordinate con le corrispondenti attività di sviluppo e rilascio dei diversi moduli funzionali.
4.5 MANUTENZIONE ADEGUATIVA, MIGLIORATIVA, EVOLUTIVA
Il servizio prevede l’esecuzione di interventi di manutenzione del software applicativo operante in ambiente di esercizio. Gli interventi sono raggruppabili, in funzione dei motivi dai quali trae origine l’intervento stesso, nelle seguenti tipologie di manutenzione:
• Manutenzione adeguativa;
• Manutenzione migliorativa;
• Manutenzione evolutiva.
Gli interventi saranno inseriti in un Piano di Manutenzione del Software nel quale le attività vengono pianificate in relazione alla priorità degli interventi.
Il piano si riferisce ad un determinato intervallo temporale ed individua, per tale periodo, gli interventi da svolgere, la loro sequenza temporale, le date di inizio e fine attività.
La pianificazione iniziale potrà essere modificata anche in corso d’opera, in funzione di mutate o sopravvenienti esigenze.
Al completamento dell'intervento il software interessato, dovrà essere sottoposto a test e collaudo di accettazione prima del suo trasferimento in produzione.
Successivamente alla realizzazione dell'intervento di manutenzione ed al relativo collaudo, viene aggiornata la configurazione del sistema e trasferita in produzione la soluzione definitiva.
Nel caso di interventi urgenti, essi potranno essere realizzati anche in deroga al Piano di manutenzione, su esplicita richiesta dell'Istituto.
Manutenzione Adeguativa
La Manutenzione adeguativa è volta ad assicurare la costante aderenza delle procedure e dei programmi alla evoluzione dell’ambiente tecnologico del sistema informativo.
Gli interventi riguarderanno, ad esempio, l’innalzamento dei livelli di software di base, l’introduzione di nuovi prodotti e/o apparecchiature, l’adozione di nuove modalità di gestione dei sistemi, in un contesto di generale compatibilità con l’esistente.
Manutenzione Migliorativa
Gli interventi di manutenzione adeguativa e migliorativa possono essere generati da:
• segnalazioni da parte degli utenti;
• esigenze dell’Istituto;
• evoluzioni del software di base o dell’ambiente di elaborazione;
• proposte dal servizio di gestione operativa.
Manutenzione Evolutiva
Per manutenzione evolutiva si intende la realizzazione di funzioni aggiuntive o di modifiche al sistema già rilasciato che si dovessero rendere necessarie in seguito a sopravvenute esigenze non prevedibili o programmabili e/o a variazioni normative/operative.
4.6 MANUTENZIONE CORRETTIVA
Il servizio prevede la diagnosi e la rimozione delle cause e degli effetti dei malfunzionamenti delle procedure e dei programmi.
L’attivazione del servizio di manutenzione correttiva è innescata, di norma, da una richiesta di intervento effettuata al servizio di Help Desk II livello, a seguito di impedimenti all’esecuzione dell’applicazione o differenze riscontrate fra l’effettivo funzionamento del software applicativo rispetto a quello atteso, desunto dalla documentazione disponibile.
Ogni intervento di manutenzione correttiva dovrà essere registrato e documentato nella banca dati del servizio di Help Desk di II livello.
4.7 I SERVIZI ASSOCIATI AL PROGETTO
4.7.1 Conduzione del Progetto
Il servizio comprende tutte le attività necessarie alla corretta conduzione del progetto. Le attività dovranno essere svolte in stretto contatto con il “Progetto di Integrazione”, cui è demandata la formulazione del Piano dell’intero Programma di Normalizzazione.
Le attività previste a carico del Fornitore comprendono:
• la gestione del contratto per ciò che attiene all’intero progetto e il coordinamento del progetto: redazione e gestione dei piani di lavoro, formalizzazione dello start up dei singoli task, rendicontazione delle attività e dello stato di avanzamento dei lavori, monitoraggio dei livelli di servizio, adempimenti per la fatturazione, ecc
• l’assicurazione qualità: redazione e gestione del piano di qualità, verifiche di qualità interne, supporto al monitoraggio del contratto
• l’alimentazione del Sistema di Controllo e Governo1, per la parte di propria competenza.
Il Fornitore nominerà un Direttore Xxxxxx che costituirà il riferimento principale per il responsabile nominato dall’INPDAP, al quale verranno affidate le mansioni di:
• controllo della corretta esecuzione dell’intero progetto;
• supervisione e coordinamento di tutte le attività e prestazioni svolte dal Fornitore;
• responsabilità del completo raggiungimento degli obiettivi di qualità.
Il Direttore Xxxxxx sarà affiancato dai responsabili dei diversi servizi che potranno assumere specifiche competenze e responsabilità nella esecuzione di una o più parti della fornitura, interagendo, di norma, con le corrispondenti figure di riferimento nominate dall'Istituto.
La funzione di "Assicurazione qualità" dovrà garantire:
• la gestione del Piano di Qualità, in aderenza al Piano di Qualità generale del programma, attraverso il controllo dei risultati richiesti dal Piano stesso approvato dall'Istituto;
• la pianificazione ed effettuazione dell’audit del sistema per assicurare il raggiungimento degli obiettivi di qualità e la gestione delle non-conformità rilevate;
• la raccolta ed archiviazione delle informazioni sulla qualità del progetto, a supporto dell’attività per la gestione degli SLA e della funzione di monitoraggio.
Durante tutta la durata del contratto l'attività di Conduzione del Progetto dovrà essere svolta in stretto contatto con i referenti INPDAP e con i referenti del “Progetto di Integrazione” che supporta l’Istituto nella conduzione e gestione dell’intero Programma di Normalizzazione del Sistema.
Tale interazione dovrà essere supportata da:
• rendicontazioni periodiche sullo stato di avanzamento dei lavori, sul rispetto dei livelli di servizio e dei vincoli contrattuali;
1 Il Sistema di Controllo e Governo, realizzato nell’ambito del Progetto di integrazione, è un Sistema Informativo di supporto all’Istituto per la gestione dell’intero programma, che consentirà:
• il controllo dei livelli di servizio (SLA manager);
• la gestione della documentazione (Document manager).
• comunicazioni di carattere estemporaneo finalizzate alla esecuzione e rendicontazione di specifiche attività, alla segnalazione di problemi e alla proposizione delle relative soluzioni.
A titolo esemplificativo e non esaustivo, la rendicontazione periodica dovrà riportare:
• il consuntivo, alla data, dello stato del contratto e delle attività di governo messe in atto per garantirne il buon fine;
• le informazioni di sintesi necessarie al fine di permettere una valutazione sulle soluzioni scelte e sulle modalità di realizzazione della soluzione messe in atto, nonché di supportare l'identificazione e pianificazione degli eventuali interventi di miglioramento.
4.7.2 Consulenza
Il servizio di consulenza prevede l'affiancamento del personale delle funzioni amministrative e tecniche designato dell'Istituto da parte di personale qualificato del Fornitore, nello svolgimento delle seguenti attività:
• formulazione e redazione di provvedimenti normativo/amministrativo aventi impatto sul Sistema istituzionale;
• individuazione delle azioni di tipo organizzativo/procedurale da attuare per ottimizzare l’impatto dell’introduzione delle nuove funzionalità nelle sedi centrali e periferiche;
• gestione dei rapporti con Organismi esterni (Enti, commissioni, gruppi di lavoro) su problematiche attinenti flussi informativi (analisi e definizione delle modalità di scambio dati), o comunque aventi impatto sul Sistema Istituzionale;
• organizzazione di attività per la rilevazione dei carichi di lavoro allo scopo di costituire e gestire una banca dati di sintesi di interesse direzionale.
Il servizio di Consulenza interagirà con il corrispondente servizio di Consulenza svolto all’interno del “Progetto di Integrazione”, cui è demandata, tra l’altro, l’attività di indirizzamento e verifica complessiva al fine di mantenere la coerenza globale con le linee strategiche dell’Istituto.
4.7.3 Formazione
Il processo di realizzazione del nuovo sistema istituzionale dell'INPDAP, considerata la sua complessità funzionale ed organizzativa, richiede anche una forte attenzione allo sviluppo delle nuove competenze gli utenti.
Il Fornitore dovrà quindi predisporre un Piano di Formazione che identifichi e pianifichi dettagliatamente tutte le componenti del servizio.
La soluzione formativa proposta dal Fornitore dovrà conformarsi ai seguenti requisiti:
• formazione formatori: formazione in aula di personale dell'Istituto cui sarà demandata la successiva formazione capillare e specifica degli utenti finali;
• presenza di strumenti di e-learning (CBT/ WBT), da affiancare ai tradizionali corsi in aula;
• assistenza e tutoring in una fase successiva alla formazione in aula;
• rilevazione della Customer Satisfaction al fine di valutare l’impatto dell’azione formativa.
4.7.3.1 Formazione in aula
La formazione in aula interesserà persone dell'Istituto individuate e preventivamente formate dall’Istituto per assumere il ruolo di “Formatori”.
Per limitare interferenze con le attività lavorative dei formatori dislocati presso circa 100 sedi periferiche, saranno previsti interventi formativi che aggregano gli avviamenti di più funzionalità. Sulla base delle attuali pianificazioni sono previsti tre diversi interventi formativi.
Si prevede che in aula siano mediamente presenti 10 discenti.
Nell’ambito dei corsi saranno illustrati i corrispondenti avviamenti e i WBT/CBT che saranno distribuiti agli utenti finali. I corsi si svolgeranno presso le sedi dell’Istituto in aule attrezzate, che saranno individuate e definite ad inizio attività. Eventuali variazioni delle sedi saranno comunicate al Fornitore almeno trenta giorni prima dell’inizio di ogni intervento formativo.
Per consentire l’effettuazione dell’intervento formativo in modo tempestivo rispetto agli avviamenti in produzione, il fornitore dovrà pianificare l’erogazione contemporanea su più sedi periferiche, stimate in un numero massimo di dieci. La progettazione dei corsi da realizzare ed erogare, la tempificazione e la dislocazione delle sedi dell’Istituto, sarà opportunamente dettagliata nel Piano di Formazione.
Documentazione di supporto
Dovranno essere forniti gli strumenti didattici (software, materiale didattico di supporto, ecc.) necessari sia per l’erogazione dei corsi, sia per le attività di valutazione correlate.
• Materiale didattico di supporto (Manuale utente, Slides del corso, Manuale del corso);
• Cartella docente costituita da un kit didattico rivolto al formatore come ausilio all’illustrazione delle funzionalità;
• Questionario sulla qualità percepita.
• Modulo di rilevazione delle attività didattiche. (vedi punto successivo) A tutti i partecipanti sarà inoltre fornito il WBT/CBT completo del corso.
Rilevazione attività didattiche e questionario di gradimento
Per ogni edizione dei corsi verrà prodotto un resoconto/verbale (“Rilevazione attività didattiche”) dove saranno riportate le seguenti informazioni:
• Titolo del corso
• Destinatari
• Durata
• Sede
• Nome docente
• Considerazioni del docente
• Firma partecipanti
• Data e timbro dell’Ufficio
Dovrà inoltre essere sottoposto ai partecipanti un Questionario dove riportare le proprie considerazioni relativamente al corso, al docente, ai materiali, ecc., che verrà concordato fra le parti, e che potrà essere sottoposto a revisione all’atto della pianificazione.
4.7.3.2 Formazione on line (WBT)
Considerando le dimensioni del bacino d’utenza, lo strumento più indicato per raggiungere tempestivamente ed in modo omogeneo gli utilizzatori del sistema è la fruizione di corsi interattivi.
I corsi interattivi dovranno essere fruiti dai partecipanti direttamente sulle proprie postazioni di lavoro. Il corso in autoistruzione ha lo scopo di:
• far acquisire i contenuti e familiarizzare con le funzioni operative che saranno utilizzate dall'utente;
• acquisire operatività in ambiente simulato, al fine di essere guidati e assistiti nelle prime attività applicative sul nuovo sistema;
• consentire l’autoverifica dell’apprendimento e del livello di acquisizione dei contenuti operativi, al fine di approfondire o rivedere gli argomenti o i passi operativi non ancora consolidati.
Il corso in autoistruzione sarà una base di knowledge management, navigabile per profili utente; dovrà prevedere almeno due sezioni:
• tutorial, che raccoglie la presentazione delle funzioni e i casi di studio necessari per illustrare le funzioni stesse;
• esercitativa che introduce all’operatività sulle funzioni di specifico interesse significative dell’intero processo.
Gli argomenti trattati all’interno del WBT/CBT dovranno coprire le diverse funzionalità implementate. La composizione del corso in autoistruzione dovrà essere composta da moduli didattici autoconsistenti che saranno a loro volta composti da segmenti didattici in relazione alla durata del modulo.
La progettazione dei corsi in autodistruzione sarà opportunamente dettagliata nel Piano di Formazione.
4.7.3.3 Tutoring
Una volta terminato il corso agli utenti dovrà essere offerto un servizio di tutoring svolto da personale specializzato del fornitore, che fornirà supporto sull’utilizzo dei WBT/CBT o, ove richiesto dall’Istituto, supporto on site all’utilizzo delle funzionalità rilasciate.
Il servizio di tutoring sarà fruibile da tutto il personale utente dell'Istituto che potrà inoltrare richieste di chiarimenti al tutor tramite posta elettronica.
Le risorse occupate nell’ambito del servizio opereranno presso le sedi INPDAP.
La pianificazione del servizio dovrà essere opportunamente dettagliata nel Piano di Formazione.
4.7.4 Assistenza agli Utenti
Il servizio richiesto è finalizzato ad assicurare in modo continuativo il supporto all’utente per l’esercizio del sistema e per il suo migliore utilizzo.
Il servizio è mirato al corretto ed ottimale utilizzo delle funzioni automatizzate del Sistema Informativo da parte degli utenti, nonché alla rilevazione, analisi e valutazione di ulteriori esigenze tecnico-funzionali da parte degli utenti stessi.
Le attività vengono svolte a stretto contatto con i livelli decisionali e operativi della struttura organizzativa dell'INPDAP.
Nell'ambito del servizio di assistenza utente sono comprese le attività connesse con:
• la conduzione funzionale;
• l'help desk di II livello;
• il rilascio del sistema a fine periodo.
4.7.4.1 Conduzione Funzionale
Il servizio di conduzione funzionale comprende l’insieme delle attività volte a garantire la piena funzionalità del sistema implementato, anche a seguito delle modifiche e degli adeguamenti conseguenti alle sopraggiunte esigenze dell’Istituto, alle variazioni normative, alla verifica di eventuali scostamenti dai livelli di servizio.
Tale servizio comprende, inoltre, le attività di ripristino delle funzionalità in esercizio nel rispetto dei livelli di servizio richiesti contrattualmente.
Le attività svolte nell'ambito della conduzione funzionale comprendono:
• la rilevazione in modo proattivo di eventuali malfunzionamenti del sistema;
• la verifica con l’utente degli eventuali malfunzionamenti software rilevati dall’utente stesso;
• la rilevazione delle osservazioni degli utenti sulle procedure automatizzate al fine di migliorarne l’utilizzo e le prestazioni;
• il supporto all’utilizzo delle funzioni automatizzate previste dal sistema;
• l'effettuazione di modifiche estemporanee, puntuali e circoscritte di porzioni della base dati e/o di prodotti del Sistema;
• la fornitura di specifici prodotti, non previsti dalle applicazioni software del sistema, ma richiesti dall’utente a fronte di esigenze estemporanee e di norma non ripetibili nel tempo, quali: report ricavati dall’estrazione ed elaborazione di dati presenti nella base informativa.
• la gestione della configurazione del software, cioè la mappa costantemente aggiornata dei programmi, delle procedure, delle basi dati, del software di base e di ambiente e dei sistemi su cui operano.
L’Help desk di 2° livello è attivato su segnalazione dell’Help Desk di I livello, attività svolta dall’Istituto.
Il modello organizzativo di funzionamento prevede che, a fronte di una richiesta di intervento, qualora l’operatore di I livello non sia in grado di concludere direttamente l’intervento, individui il servizio da attivare e provveda ad inoltrare la segnalazione.
L’Help Desk di II livello, costituito da personale specializzato, prende in carico la chiamata ed interviene svolgendo le seguenti attività:
• presa in carico della richiesta, analisi e classificazione del problema, assegnazione livello di priorità, valutazione delle possibili soluzioni/sottounità da contattare, tipo di soluzione, tempi di intervento;
• completamento della risposta con eventuale richiamo all’utente per problematiche complesse e/o che richiedono un’analisi più accurata (back office);
• attivazione dello specifico settore specialistico (esempio la manutenzione correttiva), dove il problema non è risolubile direttamente;
• gestione di una banca dati del servizio contenente le chiamate pervenute, i tempi di intervento e di risoluzione delle relative problematiche;
• produzione di report statistici riepilogativi dei dati contenuti nella banca dati del servizio con frequenza periodica da stabilire e su richiesta specifica dell’Istituto.
Il servizio dovrà svolgersi on site presso l’Istituto.
Saranno resi disponibili dall’Istituto lo strumento di registrazione e di tracciatura dei malfunzionamenti, un numero telefonico (con segreteria telefonica), una casella e-mail e un ulteriore numero da utilizzarsi quale servizio telefax
4.7.4.3 Rilascio a fine fornitura
Su richiesta dell’Istituto, negli ultimi tre mesi di vigenza contrattuale, il Fornitore dovrà provvedere al trasferimento del know-how sulle attività condotte al personale INPDAP, o a terzi da esso designati, al fine di garantire la continuità e l’affidabilità dell'esercizio del sistema.
Tale richiesta dovrà essere formulata dall’Istituto entro sei mesi prima del termine contrattuale. Il Fornitore dovrà predisporre prima dell'inizio delle attività di rilascio, un "Piano di Trasferimento", nel quale dovranno essere indicati:
• il programma temporale delle attività di affiancamento;
• il dimensionamento delle risorse per lo svolgimento delle attività di affiancamento per ogni specifico servizio, in termini di personale impiegato e giornate lavorative complessivamente dedicate;
• la tempificazione degli incontri per la verifica dello stato avanzamento attività;
• il programma temporale delle attività di consegna (Piano di Consegna).
Durante il periodo di affiancamento:
• la responsabilità dei servizi viene mantenuta dal Fornitore fino al termine previsto contrattualmente;
• un gruppo di risorse del Fornitore appositamente designato affiancherà le risorse dell'Istituto e/o del Fornitore subentrante per il trasferimento delle conoscenze sui servizi e sulle relative attività di gestione;
• verrà effettuata dal Fornitore la consegna di quanto realizzato e della relativa documentazione.
Le attività di trasferimento delle conoscenze saranno organizzate in sessioni di lavoro. Ciascuna sessione di lavoro sarà relativa ad una specifica entità ben identificabile in relazione agli obiettivi di servizio. Ogni sessione di lavoro sarà articolata in uno o più incontri e potrà comprendere presentazioni, tavole rotonde, riunioni.
Al termine delle attività di trasferimento verrà stilato, in contraddittorio fra le parti, un verbale di completamento delle attività di trasferimento che sancirà la data di conclusione della attività.
4.7.5 Avviamento in Esercizio
Il progetto prevede il completamento dell’Intervento di Normalizzazione in diverse fasi realizzative. Al termine di ciascuna fase deve essere pianificato e fornito un servizio di supporto relativo al collaudo dei moduli realizzati ed all'avviamento in esercizio delle nuove funzionalità.
4.7.5.1 Supporto al Collaudo
Il collaudo dei servizi e della funzionalità rese disponibili dagli applicativi oggetto della fornitura è di responsabilità di Inpdap. Il servizio richiesto è di supporto a tale attività.
Il collaudo consiste nell’esecuzione di tutte le procedure previste dal Piano di collaudo, consegnato dal Fornitore prima della data prevista di collaudo ed approvato dall'Istituto.
Nel Piano di collaudo il Fornitore dovrà specificare:
• le modalità operative attraverso le quali verranno effettuati i test;
• le modalità attraverso le quali verranno tempestivamente risolti gli eventuali malfunzionamenti.
Durante la fase di collaudo le attività richieste al fornitore sono:
• supporto alla predisposizione dell’ambiente di collaudo
• supporto al test dell’ambiente predisposto
• supporto durante l’esecuzione del collaudo
4.7.5.2 Assistenza per l’avviamento in esercizio
Il servizio di assistenza all’avviamento consiste nel fornire supporto nella configurazione e nell’utilizzo del sistema applicativo messo in esercizio ed è finalizzato ad affiancare il personale operativo dell’Istituto nella fase iniziale di entrata in vigore delle nuove procedure informatiche.
Il servizio deve prevedere il supporto alle attività di competenza dell’Istituto, relative alla messa in produzione delle procedure realizzate quali ad esempio:
• trasferimento del software in ambiente di esercizio
• configurazione delle basi dati di esercizio
• profilazione degli utenti
• ecc
4.7.6 Supporto alla gestione operativa
La gestione operativa delle procedure sarà svolta da INPDAP. Il servizio richiesto dovrà prevedere l’affiancamento del personale tecnico dell’Istituto, supportandolo nelle diverse attività. Il servizio decorre a partire dal primo collaudo positivo e si conclude al termine delle attività contrattuali.
Nel servizio vengono incluse tutte le attività ordinarie di carattere applicativo/sistemistico che garantiscono il mantenimento ottimale del sistema informativo e consentono la erogazione dei servizi. Le attività in cui il fornitore affiancherà l’INPDAP riguardano:
• Esecuzione di operazioni straordinarie di backup connesse ad eventi particolari o richieste dal supporto di 2° livello;
• Esecuzione di operazioni di ripristino delle basi informative da backup richieste dal supporto di 2° livello;
• Schedulazione ed esecuzione di attività batch;
• Controllo della occupazione di spazio dei database e degli archivi;
• Verifica dell’allineamento dei contenuti informativi presenti nelle Banche Dati e effettuazione delle necessarie azioni per ripristinare i contenuti informativi eventualmente disallineati
• Controllo sul Popolamento della nuova Banca dati volta alla verifica della qualità dei dati, analisi degli scarti e risoluzione dei conflitti.
5. MODALITA’ DI ESECUZIONE DELLA FORNITURA
5.1 GESTIONE DELLA FORNITURA
L’esecuzione ed il controllo della fornitura avverranno attraverso un’attività continua di pianificazione e consuntivazione di cui il Piano di progetto è lo strumento di riferimento. Il Piano di progetto dovrà conformarsi alle indicazioni riportate nel “Piano di programma”, definito nell’ambito di “Servizi e Progetti di Integrazione del Sistema”. Il Piano di Programma riferendosi all’intero programma di Normalizzazione del Sistema Informativo dell’Istituto, rappresenta infatti il riferimento per tutti gli interventi di Normalizzazione.
Il Piano di programma sarà consegnato al fornitore all’inizio delle attività contrattuali. Tutte le successive modifiche e revisioni saranno tempestivamente rese disponibili.
5.1.1 Pianificazione
All’inizio delle attività il Fornitore dovrà consegnare il Piano di progetto iniziale (Piano di lavoro con attività, tempi, stime di impegno) contenente il dettaglio di tutte le componenti della fornitura in modo tale da consentire il controllo in ogni momento dello stato reale di esecuzione della fornitura.
In sede d’offerta il fornitore dovrà presentare una prima bozza di Piano di Progetto.
In particolare, tale Piano di progetto dovrà contenere i piani operativi inerenti le attività previste, i tempi necessari al completamento delle singole attività, le responsabilità e le risorse associate alle attività, le milestones.
Il Piano dovrà essere approvato dall’Istituto prima di diventare operativo. L’INPDAP provvederà a comunicare al Fornitore la propria determinazione in merito all’approvazione del Piano. Nel caso in cui l’INPDAP chieda delle modifiche al Piano, il Fornitore dovrà provvedere tempestivamente a consegnare la nuova versione del documento.
Successivamente, nel corso della fornitura, sarà cura del Fornitore comunicare e concordare con l'Istituto ogni eventuale ripianificazione delle attività, aggiornando il Piano di lavoro. Tale ripianificazione verrà formalizzata sotto forma di verbale.
Il Piano di lavoro e le sue modifiche, come formalizzate nei verbali, rappresentano l’impegno del Fornitore, accettato da INPDAP, su stime, tempificazione delle attività e relative date di consegna dei prodotti.
5.1.2 Consuntivazione e Controllo avanzamento
Per gli oggetti di fornitura, il Fornitore dovrà predisporre mensilmente il documento di “Stato Avanzamento Lavori (SAL)”. Tale documento, oltre che la consuntivazione delle attività svolte con regolamentazione a tempo e spesa dovrà riportare, con riferimento a ciascun obiettivo di sviluppo, indicazioni sulle attività concluse ed in corso, sugli eventuali criticità/ritardi, sulle relative azioni di recupero e razionali dello scostamento. Le eventuali osservazioni sui contenuti di tale documento e le conseguenti modifiche saranno formalizzate sotto forma di verbale o altra comunicazione scritta.
5.1.3 Monitoraggio del Progetto
Il monitoraggio del progetto, in coerenza con la circolare AIPA CR/38 del 28.12.2001 e successive modifiche e integrazioni, sarà effettuata da uno specifico organismo distinto da Fornitore e Strutture Tecniche dell’Istituto responsabili delle attività inerenti la Normalizzazione del Sistema Istituzionale. Il Fornitore si impegna a prestare la massima collaborazione e a fornire tutti i documenti necessari alle attività di controllo a partire dalla data di inizio di esecuzione delle attività.
5.1.4 Prodotti e documentazione di fase
Nel seguito si riassumono le fasi secondo cui strutturare il piano di progetto con le relative scadenze e i principali prodotti previsti.
Servizio | Fase | Prodotto | Consegna |
Conduzione dell’intervento | Piano di Progetto | All’attivazione dell’intervento e a seguito di variazioni significative dell’oggetto di intervento | |
Piano di Qualità | |||
Stato avanzamento (SAL) | Mensile | ||
Consulenza | Prodotti degli specifici interventi richiesti | Secondo quanto riportato nel Piano di progetto | |
Sviluppo software | Analisi dei requisiti | Documento di definizione dei requisiti | Secondo quanto riportato nel Piano di progetto |
Stima dei function point | |||
Progettazione | Prototipo | ||
Documento di descrizione delle funzioni e disegno delle interfacce (Manuale utente 1° versione) | |||
Conteggio Function Point |
Servizio | Fase | Prodotto | Consegna |
Documento di progettazione | |||
Documento base dati (livello logico e fisico) | |||
Progettazione del piano di test | |||
Realizzazione/ Test di integrazione | Realizzazione Piano di test | ||
Piano di collaudo | |||
Codice sorgente | |||
Conteggio function point | |||
Documentazione e manualistica utente | |||
Documentazione e manualistica tecnica | |||
Gestione Coesistenza Banca Dati | Secondo quanto riportato nel Piano di progetto | ||
Popolamento Banca Dati | Prodotti previsti dallo sviluppo 2 | Secondo quanto riportato nel Piano di progetto | |
Avviamento in esercizio | Verbale di Collaudo Reportistica attività | Mensile | |
Formazione | Piano di Formazione | Secondo quanto riportato nel Piano di progetto | |
Materiale didattico | |||
CBT/WBT | |||
Consuntivazione corsi erogati (comprensiva dei questionari per la rilevazione della Customer Satisfaction) | |||
Reportistica attività di tutoring | Mensile | ||
Assistenza utenza | Reportistica attività | Mensile |
2 Il ciclo di vita utilizzato per gli interventi di Gestione Coesistenza Banca Dati e Popolamento Banca Dati potrà essere variato, semplificando le differenti fasi, in funzione della tipologia dell’intervento, della dimensione, della criticità e urgenza dello stesso.
Fase | Prodotto | Consegna | |
Piano di trasferimento di fine fornitura | Almeno 3 mesi prima della fine fornitura | ||
Supporto alla gestione operativa | Reportistica attività | Mensile | |
Manutenzione correttiva | Reportistica attività | Mensile | |
Manutenzione evolutiva, adeguativa e migliorativa | Piano di manutenzione | Secondo quanto riportato nel Piano di progetto |
Tabella 2 – Servizi della fornitura - Principali prodotti
Tutti i prodotti previsti devono essere consegnati entro le date definite nel Piano di progetto.
I prodotti della fase di analisi e della fase di progettazione devono essere approvati dall’Istituto. Tale approvazione, vincola lo svolgimento delle fasi successive. INPDAP si riserva un massimo di 20 giorni lavorativi per comunicare la propria determinazione in merito all’approvazione e all’autorizzazione a procedere alle fasi successive.
I prodotti di fine realizzazione sono sottoposti al collaudo del Committente, per accettazione
5.2 DIMENSIONAMENTO, MIX DELLE RISORSE E MODALITÀ DI REMUNERAZIONE
5.2.1 Sviluppo Software
Lo sviluppo software è stimato in 43.000 Punti Funzione, di cui 16.600 derivanti dal re- engineering del software esistente e 26.400 di sviluppo ex-novo.
Nel compilare l’offerta economica il Fornitore non potrà modificare tale stima dimensionale. Nella seguente tabella è riportato il dimensionamento stimato sulle singole aree funzionali.
Punti Funzione Stimati | ||
Re-Engineering | Ex-Novo | |
Anagrafiche | 900 | 2.100 |
Prestazioni Previdenziali | 7.000 | 11.000 |
Attività sociali | 2.300 | 5.700 |
Crediti | 6.400 | 7.600 |
Totale | 16.600 | 26.400 |
Tabella 3 – Dimensione delle singole aree funzionali
3 Il ciclo di vita utilizzato per gli interventi di manutenzione potrà essere variato, semplificando le differenti fasi, in funzione della tipologia dell’intervento della dimensione, della criticità e urgenza dello stesso.
• nella fase di “Analisi dei requisiti” si effettua l’analisi dei requisiti utente e si identificano le funzioni software da realizzare. Al termine della fase il fornitore definisce e condivide con l’Istituto una stima in Punti Funzione delle dimensioni dell'obiettivo, comprensiva della distinzione per i punti funzione che saranno sviluppati ex-novo e per i punti funzione sviluppati con riuso del software. Tale indicazione sarà effettuata anche sulla base delle caratteristiche del software da riusare, così come risultanti dall’attività di censimento di inizio fornitura;
• nella fase di “Progettazione” questi valori verranno affinati, mettendo a confronto le funzioni della vecchia applicazione con quelle dell’obiettivo da realizzare ed individuando le variazioni che intercorrono tra vecchie e nuove funzionalità; al termine della fase di “Progettazione” si effettua quindi il conteggio dei Punti Funzione per l’obiettivo, distinguendo i Punti Funzione che saranno sviluppati con riuso da quelli che saranno sviluppati ex-novo;
• al termine della fase di “Realizzazione” si determina il consuntivo dei Punti Funzione effettivamente realizzati per l’obiettivo.
L’attività sarà remunerata sulla base dei punti funzione effettivamente realizzati e in base ai prezzi indicati nel contratto per i punti funzione sviluppati ex-novo e per quelli sviluppati mediante reengineeering.
L’attività di censimento ad inizio fornitura si intende remunerata nell’ambito del corrispettivo dei Punti Funzione.
Le modalità di conteggio dei punti funzione saranno conformi alla direttiva IFPUG 4.1.1
5.2.2 Altri servizi misurati in Punti Funzione
Nella tabella seguente è riportata la dimensione degli altri servizi misurati in punti funzione. I servizi inerenti la gestione coesistenza Banca Dati e Popolamento Banca Dati sono stati dimensionati sulla base delle attuali banche dati e di una stima della banca dati futura. Il servizio di manutenzione, evolutiva, adeguativa e migliorativa, è stato dimensionato considerando una percentuale media di manutenzione pari a circa il 10% dei FP totali del sistema.
Punti Funzione | |
Gestione Coesistenza Banca Dati | 3.300 |
Popolamento Banca Dati | 2.400 |
Manutenzione Evolutiva, Adeguativa e Migliorativa | 4.300 |
Totale | 10.000 |
Tabella 4 – Servizi misurati in Punti Funzione
Le modalità di conteggio dei punti funzione saranno conformi alla direttiva IFPUG 4.1.1
5.2.3 Servizi misurati in Giorni Persona
Nella tabella seguente è riportata la stima dimensionale dei servizi misurati in giorni persona.
Giorni Persona | |
Conduzione del Progetto | 657 |
Consulenza | 2.800 |
Assistenza Utente | 1.350 |
Avviamento in Esercizio | 300 |
Supporto alla gestione operativa | 421 |
Totale | 5.528 |
Tabella 5 – Servizi misurati in giorni persona
Nel compilare l’offerta economica il Fornitore non potrà modificare tale stima dimensionale.
Le attività relative ai servizi del presente paragrafo saranno misurate sulla base dei giorni persona effettivamente utilizzati nell’erogazione dei servizi e remunerate in base alle relative tariffe indicate nel contratto.
Una quota parte dei giorni persona indicati in tabella – stimata in circa il 3% - è da intendersi relativa all’erogazione dei servizi effettuati extra orario di cui al par. 5.4. che saranno remunerati alle medesime tariffe dei relativi servizi.
5.2.4 Formazione
Formazione in aula
Nella tabella seguente sono riportate le dimensioni stimate per il servizio di formazione in aula. Nel compilare l’offerta economica il Fornitore non potrà modificare tale stima dimensionale.
Formazione formatori | |
Interventi formativi | 3 |
sedi di effettuazione dei corsi | 100 |
n° edizioni per sede | 1 |
giorni previsti per singolo corso | 3 |
X.xx di giornate di docenza | 900 |
Tutoring
Per l’attività di tutoring sono stati stimati 270 giorni/persona.
Nel compilare l’offerta economica il Fornitore non potrà modificare tale stima dimensionale.
Le attività relative ai servizi del presente paragrafo saranno misurate sulla base dei giorni persona effettivamente utilizzati nell’erogazione dei servizi e remunerate in base alle relative tariffe indicate nel contratto.
5.2.5 Mix delle Risorse
Nel seguito si riporta la ripartizione dei profili professionali stimata per i servizi oggetto della presente fornitura.
Livello A | Livello B | Livello C | Xxx. D | ||||||||||||
PMS | CP | LM | PM | C | AS | AIT | DBA | D | A | PS | S | T | EBD | P | |
Cond. del progetto | 40% | 60% | |||||||||||||
Consulenza | 50% | 50% | |||||||||||||
Assistenza | 5% | 10% | 15% | 35% | 35% | ||||||||||
Avviamento | 5% | 21% | 34% | 40% | |||||||||||
Gestione operativa | 4% | 5% | 21% | 20% | 50% | ||||||||||
Sviluppo | 5% | 5% | 20% | 5% | 5% | 10% | 20% | 5% | 5% | 20% | |||||
Coesistenza BD | 10% | 20% | 13% | 10% | 17% | 5% | 10% | 15% | |||||||
Popolamento BD | 10% | 10% | 20% | 20% | 10% | 15% | 15% | ||||||||
Evol., adeg. e migl. | 10% | 15% | 10% | 30% | 7% | 15% | 13% | ||||||||
Formazione | 11% | 9% | 80% | ||||||||||||
Tutoring | 4% | 18% | 78% |
Tale stima rappresenta un’indicazione di massima; il Fornitore dovrà indicare, nella propria offerta, il mix di profili professionali (in termini percentuali) previsto sui diversi servizi e che a suo parere garantiscono l’ottimale erogazione dei servizi stessi.
5.3 LUOGO DI LAVORO
Le attività oggetto del presente Capitolato saranno svolte presso le sedi dell’Istituto.
Le sedi presso le quali effettuare i servizi saranno indicate dall’Istituto all’avvio della fornitura ed eventuali variazioni di sede saranno comunicate di volta in volta durante il periodo di validità del contratto. Le sedi si intendono dislocate sul territorio del comune di Roma.
Gli ambienti messi a disposizione saranno disponibili nel normale orario di lavoro. Per esigenze straordinarie potrà essere congiuntamente definito un ampliamento dell’orario di disponibilità.
5.4 ORARIO DEI SERVIZI
Per i servizi di tipo continuativo viene richiesto il seguente “Orario standard di Servizio”:
• giorni lavorativi Lun – Ven 8,30 – 17,30
Il Servizio di Help Desk (2° livello) di cui al par. 4.7.4.2 dovrà prevedere la ricezione delle richieste di intervento dal 1° livello con fax/Segreteria telefonica/e-mail, H24.
Per tali servizi di tipo continuativo, l’Istituto potrà, inoltre, richiedere al RTI, con un preavviso minimo di 15 giorni, l’erogazione di servizi extra-orario oppure nei giorni festivi e non lavorativi in genere.
5.5 INFRASTRUTTURE NECESSARIE ALLO SVOLGIMENTO DEI LAVORI
La strumentazione centrale di supporto alla fornitura, a carico dell’Istituto, è da intendersi comprensiva delle apparecchiature HW Server, del relativo SW di base e delle licenze dei prodotti software utilizzati nell’ambito dell’esecuzione dei servizi. Sono da intendersi inoltre a carico dell’Istituto le infrastrutture di rete e i servizi di accesso a beneficio del gruppo di lavoro.
5.6 GARANZIA
Tutti i prodotti collaudati dovranno prevedere un periodo di garanzia per la correzione dei difetti degli oggetti software nuovi e/o modificati che copra l’intero periodo contrattuale e comunque un anno a partire dalla data di collaudo positivo, nel rispetto dei livelli di servizio previsti per la manutenzione correttiva.
L’estensione della garanzia è esclusa per gli oggetti modificati da un soggetto diverso da quello impegnato a fornire la garanzia.
6. ORGANIZZAZIONE E PROFILI PROFESSIONALI
L’offerente dovrà descrivere, nella propria offerta, la struttura organizzativa proposta per lo svolgimento della fornitura. Le esperienze e le capacità delle figure chiave inserite nell’organizzazione del progetto dovranno essere comprovate da dettagliati Curricula allegati alla offerta tecnica.
Il gruppo di lavoro proposto dall’offerente potrà includere le figure di cui nel seguito si descrivono i profili professionali, evidenziando responsabilità e competenze professionali minime.
6.1 PROFILI PROFESSIONALI
Sigla | Profilo professionale | Livello | Caratteristiche del livello |
CP | Consulente Partner | A | A tale livello fanno riferimento professionisti con elevata esperienza (da 12 a 18 anni), che hanno maturato una competenza approfondita nello specifico ruolo per cui vengono richiesti (almeno 6 anni). Costituiscono, per quanto di propria competenza, le figure di riferimento per la Committenza. |
LM | Learning Manager | ||
PjMS | Project Manager Senior | ||
PjM | Project Manager | B | A tale livello fanno riferimento professionisti con elevata esperienza (da 10 a 12 anni), che hanno maturato una competenza significativa nello specifico ruolo per cui vengono richiesti (almeno 4 anni). |
C | Consulente | ||
D | Docente | ||
AS | Analista Senior | ||
AIT | Architetto IT | ||
DBA | DBA Applicativo | ||
T | Tutor | C | Si tratta di figure professionali (da 5 ad 8 anni) che vengono richieste per ruoli operativi nei quali hanno maturato una significativa esperienza (almeno 3 anni). |
A | Analista | ||
PS | Programmatore Senior | ||
S | Sistemista | ||
XXX | Xxxxxxx basi dati | ||
P | Programmatore | D | Si tratta della figura professionale di programmatore per cui vongono richieste risorse che abbiano maturato almeno 2 anni di esperienza. |
Tabella 6 – Livelli e Profili Professionali
PROJECT MANAGER/ PROJECT MANAGER SENIOR |
Finalità del ruolo |
Condurre progetti di complessità/strategicità medio-alta coordinando tutte le fasi e attività necessarie al buon esito del progetto e le risorse ad esso assegnate. |
Anzianità professionale: circa 15 anni per il PMS, circa 12 anni per il PM |
Anzianità nel ruolo: almeno 6 anni per il PMS, almeno 4 anni per il PM |
Attività tipiche del ruolo |
Contribuire alla corretta esecuzione dei progetti in cui è coinvolto, apportando le proprie conoscenze tecniche, nel rispetto degli indirizzi e degli obiettivi stabiliti |
Pianificazione delle attività previste nel piano ed allocazione delle risorse relativamente all’area di propria competenza Definire il Piano di qualità e assicurare che tutte le attività siano svolte in aderenza al Piano. Pianificare ed effettuare l’audit del sistema |
Sviluppare il progetto nel rispetto dei tempi e dei costi pianificati, attraverso il coordinamento delle risorse interne ed esterne ad esso dedicate |
Gestire le fasi di collaudo e rilascio del sistema |
Produrre la documentazione e le analisi a supporto del controllo di consuntivazione dei progetti. |
Conoscenze ed esperienze lavorative |
Tecniche e uso di strumenti software di ausilio al project e risk management |
Conoscenza del dominio applicativo di interesse |
Tecnologie e principali servizi Internet |
Tecniche e metodologie di pianificazione operativa, budget e controllo |
Possiede buona conoscenza delle metodologie di analisi dati, architetture e sistemi software |
Conoscenza delle funzionalità delle piattaforme utilizzate per il progetto |
Esperienza pluriennale nella conduzione di progetti complessi Conoscenze degli standard dettati dal World Wide Web Consortium (W3C) e dalla normativa italiana vigente relativi all’usabilità e all’accessibilità dei siti web Metodologie e tecniche di misurazione di prodotti e servizi e dei relativi livelli qualitativi, con particolare riferimento agli standard ISO 9000:2000 Metodologie e metriche di misurazione di prodotti e servizi, con particolare riferimento alla metrica dei function point (IFPUG) |
CONSULENTE PARTNER/CONSULENTE |
Finalità del ruolo |
Supportare il cliente nella definizione e realizzazione dei processi di cambiamento e di sviluppo organizzativo coerenti con le strategie e con gli obiettivi di business. |
Anzianità professionale: 18 anni per il CP e a 10 per il C |
Anzianità nel ruolo: almeno 8 anni per il CP e 4 per il C |
Attività tipiche del ruolo |
Risolvere in autonomia le problematiche di processo e organizzative legate all’esecuzione dei progetti affidati, allineandosi costantemente con il responsabile di progetto e con la struttura Program Management del Cliente. |
Garantire la corretta esecuzione dei progetti a lui assegnati curandone gli aspetti sia tecnici che gestionali |
Conoscenze ed esperienze lavorative |
Conoscenza del settore pubblico, in particolare della Pubblica Amministrazione |
Conoscenza dei processi per la pianificazione strategica e l’organizzazione |
Capacità ed esperienza maturata, in progetti simili, nella gestione dei rapporti interpersonali |
Capacità di interpretare le esigenze del Cliente |
LEARNING-MANAGER |
Finalità del ruolo |
E’ la figura professionale che coordina l’insieme delle operazioni che assicurano la regolarità e la qualità del servizio di formazione. |
Anzianità professionale: circa 12 anni |
Anzianità nel ruolo: almeno 6 anni |
Attività tipiche del ruolo |
Pianificazione delle attività formative, coordinamento delle attività di erogazione, condivisione con il committente dei piani formativi. |
Identificazione dei target, predisposizione dei test di verifica e di gradimento |
Verifica livello di qualità e gradimento della formazione erogata |
Conoscenze ed esperienze lavorative |
Metodologie e tecniche formative |
Approfondita conoscenza su tecniche e metodologie di analisi organizzative, disegno dei processi e gestione del cambiamento |
Tecniche e strumenti di comunicazione |
Metodologie per l’apprendimento di gruppo |
Metodologie e strumenti per la gestione delle risorse umane |
Ottima conoscenza dei prodotti informatici e delle applicazioni negli ambienti di competenza |
Buona conoscenza delle tecnologie a sostegno della formazione a distanza |
Metodologie e tecniche di valutazione della formazione ivi compresa la preparazione e correzione di test di apprendimento e affiancamento utenti |
ARCHITETTO IT |
Finalità del ruolo |
E’ la figura professionale che, grazie alle ampie ed approfondite competenze multidisciplinari su prodotti e servizi ICT, e sulla front line tecnologica, gestisce iniziative di elevata complessità, integrando esigenze ed apporti distinti e propone soluzioni Hw e Sw a problematiche su progetti ad elevato rilievo |
Anzianità professionale: circa 10 anni |
Anzianità nel ruolo: almeno 4 anni |
Attività tipiche del ruolo |
Determinare le architetture necessarie alla implementazione di applicazioni anche complesse |
Configurare e parametrizzare il sistema, integrandolo con dispositivi esterni hardware/software |
Analisi generale del sistema informativo |
Gestione autonoma di problemi tecnici |
Interazione costante con i progettisti dei servizi |
Analisi del contesto tecnico/applicativo di riferimento |
Definizione delle caratteristiche hardware e software di sistema dei componenti necessari alla realizzazione del sistema informativo (scelta e dimensionamento prodotti) |
Definizione della architettura di dettaglio del sistema informativo |
Conoscenze ed esperienze lavorative |
Architetture e sistemi ICT |
Tecnologie ed infrastrutture di rete |
Sistemi di trasmissione (impianti, apparecchiature, sistemi) |
Evoluzioni tecnologiche di infrastrutture di rete, prodotti/servizi/applicazioni |
Conoscenza dei prodotti e delle procedure di space management, security management, account management e di disaster recovery |
Metodologie e tecniche di qualità del SW - Metodi e standard di sicurezza |
DBA APPLICATIVO |
Finalità del ruolo |
E’ la figura professionale che definisce il modello concettuale globale, garantisce la corretta normalizzazione della base informativa e definisce il modello fisico della BD. |
Anzianità professionale: circa 10 anni |
Anzianità nel ruolo: almeno 4 anni |
Attività tipiche del ruolo |
Progettazione concettuale, logica e fisica di banche dati Ottimizzazione prestazioni di banche dati e applicazioni |
Gestione della predisposizione, del popolamento iniziale, della disponibilità e della sicurezza della base dati |
Conoscenze ed esperienze lavorative |
Valutazione/scelta DBMS e tools di supporto Metodi e tecniche di migrazione tra modelli di banche dati Metodi e tecniche di progettazione concettuale, logica e fisica di banche dati Tecniche di ottimizzazione prestazioni di banche dati e applicazioni Problematiche di integrità dati. Esperienza nella progettazione e realizzazione di DB basati su Oracle e relativi ambienti di sviluppo |
ANALISTA/ ANALISTA SENIOR |
Finalità del ruolo |
Questa figura si occuperà dell’analisi del contesto applicativo d’interesse e produzione delle informazioni necessarie alla definizione del modello dei dati e funzionali (classificazione e caratterizzazione dei contenuti). Ha conoscenza ed esperienza del quadro amministrativo di riferimento, degli aspetti funzionali delle applicazioni e delle loro modalità d’uso |
Anzianità professionale: circa 7 anni per A; circa 10 anni per AS |
Anzianità nel ruolo: circa 3 anni per A; circa 6 anni per AS |
Attività tipiche del ruolo |
Definizione di modelli dei processi e redazione di specifiche di progetto Pianificazione e controllo della realizzazione procedure Stima delle risorse e dei tempi per la realizzazione di progetto Coordinamento di gruppi di lavoro Disegno e progettazione dei test del prodotto prima del rilascio all’utente |
Conoscenze ed esperienze lavorative |
Metodologie e strumenti di analisi dei processi, di analisi e disegno di prodotti SW, di analisi e disegno dati Metodologie e tecniche di test Tecniche di controllo di progetto e di programmazione strutturata |
Procedimenti amministrativi e caratteristiche tecniche e funzionali delle applicazioni informatiche nell’ambito della Pubblica Amministrazione., con particolare riferimento alle applicazioni previdenziali Tecniche di programmazione in ambiente Client-server, e in ambiente Java Metodologie e metriche di misurazione di prodotti e servizi, con particolare riferimento alla metrica dei function point (IFPUG). |
PROGRAMMATORE/PROGRAMMATORE SENIOR |
Finalità del ruolo |
Progettazione e realizzazione di applicazioni in ambiente tradizionale e in Internet. Gestione delle applicazioni e delle interconnessioni con sistemi collegati (EAI). Progettazione e realizzazione di siti web. Manutenzione ordinaria e straordinaria delle postazioni di lavoro. |
Anzianità professionale: circa 5 anni per PS; circa 2 anni per P |
Anzianità nel ruolo: circa 3 anni per PS; circa 2 anni per P |
Attività tipiche del ruolo |
Parametrizzare i prodotti, realizzare le procedure per la migrazione dei dati pregressi e “popolare” le basi dati, Fornire supporto al test |
Programmazione avanzata in ambiente WEB |
Uso di tecniche o prodotti per l’implementazione della sicurezza dei dati e/o siti di commercio elettronico |
Conoscenze ed esperienze lavorative |
Conoscenza del sistema operativo di riferimento a livello utente |
Esperienza nell’ Editing e publishing |
Concetti di base di applicazioni in architettura WEB. Linguaggi, software e tecniche per il webdesign |
Conoscenza approfondita delle principali piattaforme di sviluppo e dei linguaggi di programmazione più evoluti (C, C++, Java, ecc.). |
SISTEMISTA |
Finalità del ruolo |
E’ la figura professionale che disegna soluzioni/prodotti/servizi software efficienti e affidabili nel rispetto delle esigenze del cliente garantendo l’ottimizzazione delle prestazioni dei sistemi e dei servizi. |
Anzianità professionale: circa 6 anni |
Anzianità nel ruolo: almeno 4 anni |
Attività tipiche del ruolo |
Installazione, avviamento e gestione delle apparecchiature e dei sistemi di telecomunicazione. |
Manutenzione ordinaria, identificazione e rintracciabilità, nonché esecuzione di modifiche hardware. |
Collegamento e permutazione di punti LAN sui relativi apparati attivi di comunicazione |
Controllo delle funzionalità degli apparati di comunicazione ed interventi per le eventuali anomalie. |
Conoscenze ed esperienze lavorative |
Metodologie, linguaggi, tecniche di programmazione e tool di sviluppo negli ambienti operativi di competenza |
Ambienti di sviluppo/piattaforme applicative |
Tecniche di progettazione e sviluppo di applicazioni informatiche e basi dati |
Conoscenza procedure operative di manutenzione ordinaria e straordinaria delle apparecchiature. |
DOCENTE |
Finalità del ruolo |
E’ la figura professionale che coordina l’insieme delle operazioni che assicurano la regolarità e la qualità del servizio di formazione, eroga gli interventi formativi nel rispetto del piano e dei contenuti previsti. |
Anzianità professionale: circa 10 anni |
Anzianità nel ruolo: almeno 5 anni |
Attività tipiche del ruolo |
Progettazione ed erogazione dei corsi di formazione |
Predisposizione del materiale didattico e dei supporti multimediali a utilizzare |
Conoscenze ed esperienze lavorative |
Metodologie e tecniche formative |
Didattica |
Tecniche e strumenti di comunicazione |
Metodologie per l’apprendimento di gruppo |
Ottima conoscenza dei prodotti informatici e delle applicazioni negli ambienti di competenza |
TUTOR |
Finalità del ruolo |
E’ la figura professionale che fornisce supporto agli utenti durante la fruizione dei servizio e, in particolare, durante i percorsi formativi. |
Anzianità professionale: circa 8 anni |
Anzianità nel ruolo: almeno 3 anni |
Attività tipiche del ruolo |
Sviluppo dei percorsi formativi in particolare di training on the job, attraverso l’utilizzo di metodologie didattiche attive |
Conoscenze ed esperienze lavorative |
Capacità ed esperienza maturata, nella gestione dei rapporti interpersonali Capacità di comunicazione e chiarezza espositiva Conoscenza approfondita di tecniche di comunicazione Conoscenza approfondita di tecniche per la verifica dell’autoapprendimento. Conoscenza dei prodotti informatici e delle applicazioni negli ambienti di competenza ·Conoscenza approfondita delle tecniche multimediali |
ESPERTO BASI DATI |
Finalità del ruolo |
Governa le fasi di caricamento/elaborazione dei dati, di produzione dei report, di interpretazione e analisi dei risultati, di presentazione e discussione degli stessi. |
Anzianità professionale: circa 8 anni |
Anzianità nel ruolo: almeno 3 anni |
Attività tipiche del ruolo |
Studio e disegno di sistemi applicativi e di strutture dati |
Impiego di tecniche avanzate per la gestione di database |
Studio e disegno Controllo e ottimizzazione delle prestazioni del DBMS |
Conoscenze ed esperienze lavorative |
Dispone di competenze sulle metodologie di analisi dei dati e di progettazione logica e fisica di data base relazionali e object oriented, di implementazione di base dati in sistemi complessi e in sistemi distribuiti, di gestione di problematiche di recovery e sicurezza |
Conoscenza delle più avanzate tecniche di organizzazione, registrazione e reperimento dati |
7. QUALITÀ DELLA FORNITURA
7.1 IL PIANO DI QUALITÀ
Il Piano di Qualità dell’intervento sarà redatto dal Fornitore sulla base del proprio manuale di qualità e in conformità a quanto richiesto dalle circolari AIPA/CR/5 del 5 agosto 1994 e AIPA/CR/38 del 28 dicembre 2001, quanto suggerito dalla Deliberazione AIPA n. 49/2000 del 9 novembre 2000 e con quanto previsto dagli standard internazionali ISO:9000:2000
Il Piano di Qualità dovrà contenere, almeno, i seguenti elementi:
• metodologie utilizzate nelle fasi di analisi dei requisiti, progettazione, sviluppo e migrazione;
• tecniche e strumenti utilizzati per il riesame della progettazione e del disegno della banca dati;
• organizzazione del team (o dei team) con dettaglio dei ruoli e delle attività previste per ciascuna risorsa impiegata;
• classificazione e priorità dei requisiti;
• metodologie e metriche di controllo della qualità sia in fase di collaudo che post-collaudo;
• dettaglio della documentazione di progetto prevista e step temporali di approvazione suggeriti (in termini di giorni solari).
Il Piano, redatto ad inizio fornitura, dovrà essere approvato dall'Istituto prima di diventare operativo. Le eventuali modifiche richieste dall’Istituto saranno tempestivamente recepite.
Il Piano della Qualità potrà essere aggiornato in corso d'opera. Gli aggiornamenti potranno essere proposti dal Direttore Lavori del Fornitore e dovranno essere approvati dall’Istituto prima di diventare operativi.
Il fornitore in offerta dovrà riportare una prima versione del Piano di Qualità.
Il Piano della Qualità dovrà basarsi sugli indicatori di qualità specifici per la fornitura dettagliati nei paragrafi seguenti, a meno di eventuali proposte migliorative offerte dal Fornitore.
7.2 I LIVELLI DI SERVIZIO
7.2.1 Indicatori di qualità nello sviluppo software
Gli indicatori di qualità riportati nelle tabelle seguenti si applicano a tutti gli obiettivi di sviluppo software, gestione coesistenza Banca Dati, popolamento Banca Dati e a quelli di manutenzione evolutiva, adeguativa e migliorativa.
SV1 - Ritardo nella conclusione degli obiettivi
Codice | SV1 | |||||
Caratteristica | Efficienza | Sottocaratteristica | Prestazioni temporali | |||
Aspetto valutare | da | Slittamento della fine dell’obiettivo rispetto alla data concordata nell’ultima pianificazione | ||||
Unità di misura | Giorni | Fonte dati | Piano di progetto Resoconto accettazione | |||
Periodo riferimento | di | Durata dell’obiettivo | Frequenza misurazione | di | Una volta al termine periodo di riferimento | del |
Dati elementari da rilevare | Data di fine collaudo pianificata (rispetto all’ultima pianificazione concordata): Data_fine_prevista Data di accettazione dell’obiettivo: Data_fine_effettiva | |||||
Regole di campionamento | nessuna | |||||
Formula calcolo | di | Data_fine_effettiva - Data_fine_prevista | ||||
Regole di arrotondamento | nessuna | |||||
Valore di soglia | <=0 | |||||
Azioni contrattuali | penale | |||||
Eccezioni | nessuna |
SV2 – Prodotti consegnati senza rilievi critici
Codice | SV2 | ||
Caratteristica | Funzionalità | Sottocaratteristica | Accuratezza |
Aspetto da valutare | Prodotti consegnati non affetti da rilievi critici. (Per rilievi critici si intendono quei rilievi che non consentono l’approvazione/accettazione da parte dell’Amministrazione) | ||
Unità di misura | Su base percentuale | Fonte dati | Piano di progetto Lettere di approvazione Lettere di rilievo Resoconto accettazione |
Periodo di riferimento | Durata dell’obiettivo | Frequenza di misurazione | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Numero di prodotti consegnati (o riconsegnati) non affetti da rilievi critici (Numero_prodotti_ok) Numero prodotti consegnati (o riconsegnati) (Numero_prodotti_totali) | ||
Regole di campionamento | Vanno considerate tutti i prodotti previsti nell’ultimo piano di progetto approvato. | ||
Formula di calcolo | Numero_prodotti_ok/ Numero_prodotti_totali * 100 | ||
Regole di arrotondamento | Il risultato della misura va arrotondato: al punto % per difetto se la prima cifra decimale è ≤ 0,5 al punto % per eccesso se la prima cifra decimale è > 0,5 | ||
Valore di soglia | >= 95% | ||
Azioni contrattuali | penale | ||
Eccezioni | nessuna |
SV3 – Recidività dei rilievi sullo stesso documento
Codice | SV3 | ||
Caratteristica | Funzionalità | Sottocaratteristica | Accuratezza |
Aspetto da valutare | Recidività di rilievi sui documenti soggetti ad approvazione dell’Amministrazione | ||
Unità di misura | Numero di rilievi | Fonte dati | Lettere di rilievo dell’Amministrazione |
Periodo di riferimento | Durata dell’obiettivo | Frequenza di misurazione | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Numero di rilievi su uno stesso documento soggetto all’approvazione dell’Amministrazione (Numero_rilievi) | ||
Regole di campionamento | Vanno considerate tutte le lettere di rilievo su documenti soggetti all’approvazione dell’Amministrazione |
Formula di calcolo | Numero_rilievi |
Regole di arrotondamento | nessuna |
Valore di soglia | <=1 |
Azioni contrattuali | penale |
Eccezioni | nessuna |
SV4 – Copertura del test
Codice | SV4 | ||
Caratteristica | Affidabilità | Sottocaratteristica | Maturità |
Aspetto da valutare | Copertura del test | ||
Unità di misura | Su base percentuale | Fonte dati | Piano di test Specifiche di progettazione |
Periodo di riferimento | Durata della fase di progettazione dell’obiettivo | Frequenza di misurazione | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Numero di funzionalità definite nelle specifiche di progettazione (Numero_funzionalità) Numero di funzionalità definite nelle specifiche di progettazione per le quali è previsto almeno un test nel piano di test) (Numero_test) | ||
Regole di campionamento | Vanno considerate tutti i test previsti nel Piano di test e tutte le funzionalità previste nelle specifiche di progettazione | ||
Formula di calcolo | Numero_test/ Numero_funzionalità * 100 | ||
Regole di arrotondamento | Il risultato della misura va arrotondato: • al punto % per difetto se la prima cifra decimale è ≤ 0,5 • al punto % per eccesso se la prima cifra decimale è > 0,5 | ||
Valore di soglia | = 100% | ||
Azioni contrattuali | Lettera di rilievo sul prodotto piano di test | ||
Eccezioni | nessuna |
SV4 – Test positivi in collaudo
Codice | SV4 | ||
Caratteristica | Affidabilità | Sottocaratteristica | Maturità |
Aspetto da valutare | Test positivi in collaudo | ||
Unità di misura | Su base percentuale | Fonte dati | Piano di test e collaudo Segnalazioni di test non positivo |
Periodo di riferimento | Durata della fase di collaudo | Frequenza di misurazione | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Numero di segnalazioni relativi a casi di test in collaudo non ok (Numero_test_non_ok) Numero di casi di test previsti nel Piano di Test e collaudo (Numero_test) | ||
Regole di campionamento | Vanno considerate tutti i test previsti nel Piano di test e collaudo e le segnalazioni di test in collaudo non positivi | ||
Formula di calcolo | Numero_test_non_ok/ Numero_test * 100 | ||
Regole di arrotondamento | Il risultato della misura va arrotondato: • al punto % per difetto se la prima cifra decimale è ≤ 0,5 • al punto % per eccesso se la prima cifra decimale è > 0,5 | ||
Valore di soglia | <= 5% | ||
Azioni contrattuali | penale | ||
Eccezioni | nessuna |
SV5 - Tempestività di ripristino in collaudo
Codice | SV5 | ||
Caratteristica | Affidabilità | Sottocaratteristica | Maturità |
Aspetto da valutare | Ripristino dell’operatività in collaudo | ||
Unità di misura | Giorni/ore | Fonte dati | Modulo registrazione intervento |
Periodo di riferimento | La durata della fase di collaudo | Frequenza di misurazione | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Data/ora di comunicazione al fornitore dell’intervento (inizio) Data/ora di fine esecuzione da parte del fornitore (termine) Numero di interventi segnalati per errori bloccanti (Numero_bloccanti) Numero di interventi segnalati per errori bloccanti (Numero_non_bloccanti) |
Regole di campionamento | Devono essere considerate tutte le segnalazioni occorse nel periodo di riferimento suddivise in: • segnalazioni relative ad errori bloccanti ovvero che impediscono la prosecuzione del collaudo • segnalazioni relative ad errori non bloccanti ovvero che non impediscono la prosecuzione del collaudo |
Formula di calcolo | Numero_bloccanti_risolti_2_giorni = somma di tutti gli interventi relativi a segnalazioni bloccanti per i quali (termine – fine <= 2 giorni) Numero_non_bloccanti_risolti_5_giorni = somma di tutti gli interventi relativi a segnalazioni non bloccanti per i quali (termine – fine <= 5 giorni) Percentuale_bloccanti _risolti= Numero_bloccanti_risolti_2_giorni / Numero_bloccanti * 100 Percentuale_non_bloccanti_risolti = Numero_non_bloccanti_risolti_5_giorni / Numero_non_bloccanti * 100 |
Regole di arrotondamento | Il risultato della misura va arrotondato: • al punto % per difetto se la prima cifra decimale è ≤ 0,5 • al punto % per eccesso se la prima cifra decimale è > 0,5 |
Valore di soglia | Percentuale_bloccanti_risolt i>= 95% Percentuale_non_bloccanti_risolti >= 95% |
Azioni contrattuali | penale |
Eccezioni | nessuna |
7.2.2 Indicatori di qualità dei servizi
Nel seguito si considera come “Orario standard di Servizio” quanto definito nel cap. 7. CP1 - Adeguatezza delle risorse
Codice | CP1 | ||||
Caratteristica | Gestione delle risorse umane | Aspetto valutare | da | Adeguatezza delle risorse | |
Unità di misura | percentuale | Fonte dati | Lettere di richiesta sostituzione da parte dell’Amministrazione | ||
Periodo riferimento | di | Un anno | Frequenza misurazione | di | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Numero di sostituzioni richieste formalmente dall’Amministrazione (sostituzioni) Numero medio di risorse utilizzate dal Fornitore nel periodo di riferimento (risorse) | ||||
Regole di campionamento | Si considerano tutte le risorse adoperate sulla fornitura e tutte le sostituzioni richieste formalmente dall’Amministrazione | ||||
Formula calcolo | di | Sostituzioni/ risorse * 100 | |||
Regole di arrotondamento | Il risultato della misura va arrotondato: al punto % per difetto se la prima cifra decimale è ≤ 0,5 al punto % per eccesso se la prima cifra decimale è > 0,5 | ||||
Valore di soglia | <= 8% | ||||
Azioni contrattuali | penale | ||||
Eccezioni | nessuna |
CP2 - Turn over del personale
Codice | CP2 | |||||
Caratteristica | Gestione delle risorse umane | Aspetto valutare | da | Turn over del personale | ||
Unità di misura | percentuale | Fonte dati | Lettere di sostituzione Fornitore | del | ||
Periodo riferimento | di | Un anno | Frequenza misurazione | di | Una volta al termine periodo di riferimento | del |
Dati elementari da rilevare | Numero di sostituzioni non richieste dall’Amministrazione (sostituzioni) Numero medio di risorse utilizzate dal Fornitore nel periodo di riferimento (risorse) |
Regole di campionamento | Si considerano tutte le risorse adoperate sulla fornitura e tutte le sostituzioni non richieste dall’Amministrazione |
Formula di calcolo | Sostituzioni/ risorse * 100 |
Regole di arrotondamento | Il risultato della misura va arrotondato: al punto % per difetto se la prima cifra decimale è ≤ 0,5 al punto % per eccesso se la prima cifra decimale è > 0,5 |
Valore di soglia | <= 10% |
Azioni contrattuali | penale |
Eccezioni | nessuna |
CP3 - Ritardo nella consegna dei prodotti
Codice | CP3 | ||||
Caratteristica | Prestazioni temporali | Aspetto valutare | da | Xxxxxxx nella consegna di un prodotto rispetto all’ultimo piano di progetto approvato | |
Unità di misura | Xxxxxx | Xxxxx dati | Piano di progetto | ||
Periodo di riferimento | Trimestrale | Frequenza misurazione | di | Una volta al termine del periodo di riferimento | |
Dati elementari da rilevare | Data prevista di consegna/riconsegna di un prodotto, riportata nell’ultimo Piano di Progetto approvato (prevista) | ||||
Data di consegna/riconsegna effettiva (effettiva) | |||||
Numero totale di prodotti da consegnare/riconsegnare nel periodo di riferimento, secondo quanto pianificato nell’ultimo Piano di Progetto approvato (numero_prodotti) | |||||
Regole di campionamento | Devono essere considerati tutti i prodotti da consegnare/riconsegnare nel periodo di riferimento, secondo quanto pianificato nell’ultimo piano di progetto approvato |
Formula di calcolo | Durata = effettiva – prevista prodotti_consegnati_alla_data = somma di tutti i prodotti per i quali risulta Durata=0 prodotti_consegnati_entro_5_giorni = somma di tutti i prodotti per i quali risulta Durata<= 5 giorni percentuale_prodotti_consegnati_alla_data = prodotti_consegnati_alla_data / numero_prodotti * 100 percentuale_prodotti_consegnati_entro_5_giorni = prodotti_consegnati_entro_5_giorni / numero_prodotti * 100 |
Regole di arrotondamento | Il risultato della misura va arrotondato: • al punto % per difetto se la prima cifra decimale è ≤ 0,5 • al punto % per eccesso se la prima cifra decimale è > 0,5 |
Valore di soglia | percentuale_prodotti_consegnati_alla_data>= 95% percentuale_prodotti_consegnati_entro_5_giorni <= 5% |
Azioni contrattuali | penale |
Eccezioni | nessuna |
CP4 - Ritardo nella consegna dei prodotti soggetti ad approvazione
Codice | CP4 | |||||
Caratteristica | Prestazioni temporali | Aspetto valutare | da | Ritardo nella consegna dei prodotti soggetti ad approvazione modificati in base alle richieste dell’Amministrazione | ||
Unità di misura | Giorni | Fonte dati | Verbale di richiesta modifica | |||
Periodo riferimento | di | Trimestrale | Frequenza misurazione | di | Una volta al termine periodo di riferimento | del |
Dati elementari da rilevare | Data del verbale di richiesta modifica (verbale) Data di consegna prodotti modificati (consegna) | |||||
Regole di campionamento | Si considerano tutti i prodotti di fine analisi e fine progettazione, soggetti ad approvazione da parte dell’Amministrazione, per i quali sono state richieste modifiche |
Formula di calcolo | Consegna - verbale |
Regole di arrotondamento | nessuna |
Valore di soglia | <= 10 |
Azioni contrattuali | penale |
Eccezioni | nessuna |
CP5 - Mancata consegna del Piano di progetto
Codice | CP5 | |||||
Caratteristica | Efficienza | Aspetto valutare | da | Mancata consegna del Piano di progetto | ||
Unità di misura | Giorni | Fonte dati | Verbali di ripianificazione | |||
Periodo riferimento | di | Intera fornitura | Frequenza misurazione | di | Alla prima consegna A tutte le riconsegna successive | |
Dati elementari da rilevare | Data effettiva di consegna (effettiva) Data prevista di consegna (prevista) | |||||
Regole di campionamento | nessuna | |||||
Formula calcolo | di | Effettiva - prevista | ||||
Regole di arrotondamento | nessuna | |||||
Valore di soglia | <= 0 | |||||
Azioni contrattuali | penale | |||||
Eccezioni | nessuna |
MC1 - Tempestività di ripristino in esercizio per interventi di categoria 1
La categoria dell’intervento viene indicata dall’Amministrazione su proposta del fornitore:
• categoria 1: “malfunzionamenti per cui è impedito l’uso dell’applicazione o di una o più funzioni”;
• categoria 2: “malfunzionamenti per cui è impedito l’uso di una funzione dell’applicazione in alcune specifiche condizioni (ad esempio per alcuni dati di input)”;
• categoria 3: “malfunzionamenti per cui non è impedito l’uso delle funzioni”;
• categoria 4: “malfunzionamenti di tipo marginale”(non rientranti nelle precedenti tre categorie).
Codice | MC1 | ||
Caratteristica | Ripristino dell’operatività | Aspetto da valutare | Tempestività di ripristino negli interventi di manutenzione correttiva |
Unità di misura | Giorni/ore | Fonte dati | Modulo registrazione intervento |
Periodo di riferimento | trimestrale | Frequenza di misurazione | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Data/ora di comunicazione al fornitore dell’intervento (inizio) Data/ora di fine esecuzione da parte del fornitore (termine) Numero di interventi di manutenzione correttiva di categoria 1 chiusi nel periodo di riferimento (Numero_categoria_1) | ||
Regole di campionamento | Devono essere considerati tutti gli interventi di manutenzione correttiva di categoria 1 chiusi nel periodo di riferimento | ||
Formula di calcolo | Durata = termine – inizio Risolti_entro_8_ore = somma di tutti gli interventi per i quali durata<= 8 ore Risolti_entro_1_giorno = somma di tutti gli interventi per i quali durata > 8 ore e durata<= 1 giorno Risolti_entro_2 giorni = somma di tutti gli interventi per i quali durata > 1 giorno e durata<= 2 giorno) A = Risolti_entro_8_ore / Numero_categoria_1 * 100 B = Risolti_entro_1_giorno / Numero_categoria_1* 100 C = Risolti_entro_2 giorni / Numero_categoria_1 * 100 | ||
Regole di arrotondamento | Il risultato della misura va arrotondato: • al punto % per difetto se la prima cifra decimale è ≤ 0,5 • al punto % per eccesso se la prima cifra decimale è > 0,5 | ||
Valore di soglia | A>= 90% B<= 5% C<= 5% |
Azioni contrattuali | penale |
Eccezioni | nessuna |
MC2 - Tempestività di ripristino in esercizio per interventi di categoria 2
Codice | MC2 | ||
Caratteristica | Ripristino dell’operatività | Aspetto da valutare | Tempestività di ripristino negli interventi di manutenzione correttiva |
Unità di misura | Giorni/ore | Fonte dati | Modulo registrazione intervento |
Periodo di riferimento | trimestrale | Frequenza di misurazione | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Data/ora di comunicazione al fornitore dell’intervento (inizio) Data/ora di fine esecuzione da parte del fornitore (termine) Numero di interventi di manutenzione correttiva di categoria 2 chiusi nel periodo di riferimento (Numero_categoria_2) | ||
Regole di campionamento | Devono essere considerati tutti gli interventi di manutenzione correttiva di categoria 2 chiusi nel periodo di riferimento | ||
Formula di calcolo | Durata = termine – inizio Risolti_entro_12_ore = somma di tutti gli interventi per i quali durata<= 12 ore Risolti_entro_3_giorni = somma di tutti gli interventi per i quali durata > 12 ore e durata<= 3 giorni Risolti_entro_6 giorni = somma di tutti gli interventi per i quali durata > 3 giorni e durata<= 6 giorni A = Risolti_entro_12_ore / Numero_categoria_2 * 100 B = Risolti_entro_3_giorni / Numero_categoria_2 * 100 C = Risolti_entro_6_giorni / Numero_categoria_2 * 100 | ||
Regole di arrotondamento | Il risultato della misura va arrotondato: • al punto % per difetto se la prima cifra decimale è ≤ 0,5 • al punto % per eccesso se la prima cifra decimale è > 0,5 |
Valore di soglia | A>= 90% B<= 5% C<= 5% |
Azioni contrattuali | penale |
Eccezioni | nessuna |
MC3 - Tempestività di ripristino in esercizio per interventi di categoria 3
Codice | MC3 | ||
Caratteristica | Ripristino dell’operatività | Aspetto da valutare | Tempestività di ripristino negli interventi di manutenzione correttiva |
Unità di misura | Giorni/ore | Fonte dati | Modulo registrazione intervento |
Periodo di riferimento | trimestrale | Frequenza di misurazione | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Data/ora di comunicazione al fornitore dell’intervento (inizio) Data/ora di fine esecuzione da parte del fornitore (termine) Numero di interventi di manutenzione correttiva di categoria 3 chiusi nel periodo di riferimento (Numero_categoria_3) | ||
Regole di campionamento | Devono essere considerati tutti gli interventi di manutenzione correttiva di categoria 3 chiusi nel periodo di riferimento | ||
Formula di calcolo | Durata = termine – inizio Risolti_entro_3_giorni = somma di tutti gli interventi per i quali durata<= 3 giorni Risolti_entro_5_giorni = somma di tutti gli interventi per i quali durata > 3 giorni e durata<= 5 giorni Risolti_entro_10_giorni = somma di tutti gli interventi per i quali durata > 5 giorni e durata<= 10 giorni A = Risolti_entro_3_giorni / Numero_categoria_3 * 100 B = Risolti_entro_5_giorni / Numero_categoria_3 * 100 C = Risolti_entro_10_giorni / Numero_categoria_3 * 100 |
Regole di arrotondamento | Il risultato della misura va arrotondato: • al punto % per difetto se la prima cifra decimale è ≤ 0,5 • al punto % per eccesso se la prima cifra decimale è > 0,5 |
Valore di soglia | A>= 90% B<= 5% C<= 5% |
Azioni contrattuali | penale |
Eccezioni | nessuna |
MC4 - Tempestività di ripristino in esercizio per interventi di categoria 4
Codice | MC3 | ||
Caratteristica | Ripristino dell’operatività | Aspetto da valutare | Tempestività di ripristino negli interventi di manutenzione correttiva |
Unità di misura | Giorni/ore | Fonte dati | Modulo registrazione intervento |
Periodo di riferimento | trimestrale | Frequenza di misurazione | Una volta al termine del periodo di riferimento |
Dati elementari da rilevare | Data/ora di comunicazione al fornitore dell’intervento (inizio) Data/ora di fine esecuzione da parte del fornitore (termine) Numero di interventi di manutenzione correttiva di categoria 4 chiusi nel periodo di riferimento (Numero_categoria_4) | ||
Regole di campionamento | Devono essere considerati tutti gli interventi di manutenzione correttiva di categoria 4 chiusi nel periodo di riferimento |
Formula di calcolo | Durata = termine – inizio Risolti_entro_10_giorni = somma di tutti gli interventi per i quali durata<= 10 giorni Risolti_entro_15_giorni = somma di tutti gli interventi per i quali durata > 10 giorni e durata<= 15 giorni Risolti_entro_20_giorni = somma di tutti gli interventi per i quali durata > 15 giorni e durata<= 20 giorni A = Risolti_entro_10_giorni / Numero_categoria_4 * 100 B = Risolti_entro_15_giorni / Numero_categoria_4 * 100 C = Risolti_entro_20_giorni / Numero_categoria_4 * 100 |
Regole di arrotondamento | Il risultato della misura va arrotondato: • al punto % per difetto se la prima cifra decimale è ≤ 0,5 • al punto % per eccesso se la prima cifra decimale è > 0,5 |
Valore di soglia | A>= 90% B<= 5% C<= 5% |
Azioni contrattuali | penale |
Eccezioni | nessuna |
MC5 - Difettosità in esercizio
La classe di rischio di una applicazione, indicata dall’Amministrazione su proposta del fornitore, è definita come:
• Classe A: l’applicazione è caratterizzata da una elevata 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 tratta dati rilevanti economicamente e/o informazioni riservate Eventuali malfunzionamenti implicano limitate responsabilità civili e/o penali, ma possono provocare danni e/o una certa perdita di immagine
• Classe C: l’applicazione gestisce informazioni non critiche; un eventuale malfunzionamento comporta la sola perdita del lavoro svolto, o danni di limitato valore economico.
Codice | MC5 | |||||
Caratteristica | Affidabilità | Aspetto valutare | da | Difettosità in esercizio | ||
Unità di misura | Difetti /FP | Fonte dati | Modulo registrazione intervento/ Conteggio function point | |||
Periodo riferimento | di | trimestrale | Frequenza misurazione | di | Una volta al termine periodo di riferimento | del |
Dati elementari da rilevare | Numero totale di difetti (segnalati su Moduli di registrazione intervento) nel periodo di riferimento relativi ad applicazioni di una specifica classe di rischio in esercizio oggetto della fornitura evidenziati (Numero_difetti) Numero totale di FP delle applicazioni di una specifica classe di rischio in esercizio oggetto della fornitura (Numero_FP_classe) | |||||
Regole di campionamento | Vanno considerati tutti i difetti, rilevati durante il periodo di riferimento, sulle applicazioni in esercizio, oggetto della fornitura, di una specifica classe di rischio | |||||
Formula calcolo | di | Numero_difetti/ Numero_FP_classe | ||||
Regole di arrotondamento | Il risultato della misura va arrotondato: al punto % per difetto se la prima cifra decimale è ≤ 0,5 al punto % per eccesso se la prima cifra decimale è > 0,5 | |||||
Valore di soglia classe di rischio A | <= 0,05 | |||||
Valore di soglia classe di rischio B | <= 0,1 | |||||
Valore di soglia classe di rischio C | <= 0,2 | |||||
Azioni contrattuali | penale | |||||
Eccezioni | nessuna |