Contract

Il presente documento ha l’obiettivo di quantificare e qualificare i servizi oggetto della fornitura per l’evoluzione e la manutenzione del software applicativo che costituisce il Sistema Informativo Normalizzato (SIN) della Gestione ex Inpdap, che nel seguito indicheremo come INPS – Gestione Dipendenti Pubblici.

Infatti con l’art. 21, comma 1, della legge 22 dicembre 2011, n. 214, il legislatore ha disposto la soppressione dell’INPDAP e dell’ENPALS a decorrere dal 1° gennaio 2012 e l’attribuzione delle relative funzioni all’INPS che succede in tutti i rapporti attivi e passivi.

Il nuovo assetto organizzativo dell’Istituto, derivante dall’attuazione del predetto art. 21 della legge 214/2011, si colloca nell’ambito del processo di convergenza ed armonizzazione del sistema previdenziale pubblico del Paese ed è finalizzato ad una migliore efficienza ed efficacia dell’azione amministrativa nel settore previdenziale ed assistenziale.

Anche a seguito della citata innovazione normativa l’INPS, con il suo Sistema Informativo, occupa, nel Panorama della Pubblica Amministrazione italiana una posizione di grande rilievo sia per l’importanza e l’eterogeneità delle tematiche istituzionali trattate, sia per la complessità del sistema gestito in termini di dimensioni del patrimonio applicativo, ampiezza e varietà dell’utenza e dei servizi offerti.

Nel corso degli anni, l’impegno del sistema informativo INPS – Gestione Dipendenti Pubblici è stato costantemente rivolto a rispondere alle spinte evolutive che, da un lato recepiscono le indicazioni strategiche di soggetti esterni ed interni all’Istituto, dall’altro derivano dalla continua e rapida evoluzione del settore ICT che comporta un adeguamento continuo dei sistemi al fine di scongiurare rischi di obsolescenza e garantire alti livelli di servizio.

Il SIN è un sistema di applicativi integrati di supporto alle principali funzionalità del sistema dei servizi, diretti agli iscritti, pensionati, personale interno, pubbliche amministrazioni, intermediari, che ha contribuito alla modifica del modello lavorativo e organizzativo degli uffici dell’Istituto in sintonia con l’attuazione del processo, organizzativo e tecnologico, orientato a mettere l’utente al centro dei servizi.

Il percorso evolutivo dell’informatica dell’INPS Gestione Dipendenti Pubblici si è, negli anni, attestato su due direzioni principali:

▪ lo sviluppo di nuovi servizi informatici rispondenti ai principi di multicanalità, dematerializzazione, delocalizzazione;

▪ il mantenimento e l’evoluzione del parco applicativo e tecnologico esistente, al fine di mettere a frutto le potenzialità offerte dalle nuove tecnologie.

A questo si devono aggiungere le recenti evoluzioni normative introdotte nel settore della previdenza e del welfare che ricadono sull’INPS Gestione Dipendenti Pubblici e che comportano la necessità di

intraprendere alcune nuove iniziative di sviluppo software e di manutenzione evolutiva sul software esistente.

Contesto di riferimento

1.1. Le direttive dell’Istituto

In considerazione degli interventi legislativi descritti l’Istituto è impegnato su un complesso percorso di sviluppo finalizzato a:

• realizzare efficacia, efficienza ed economicità dell’azione amministrativa ottimizzando il rapporto costi/risultati;

• sviluppare sistemi di governance dell’azione amministrativa e delle performance a tutti i livelli organizzativi per controllare l’adeguatezza delle scelte compiute in sede di attuazione dei piani, programmi e altri strumenti di determinazione dell’indirizzo politico;

• garantire la legittimità, la regolarità e la correttezza dell’azione amministrativa.

In questo quadro l’Istituto non può non orientare la propria strategia alla soddisfazione delle aspettative dei cittadini, dei lavoratori, delle imprese e dei pensionati, nonché all’ottimizzazione dell’utilizzo delle risorse pubbliche; il tutto teso al miglioramento continuo della qualità dei servizi, puntando:

• al miglioramento della qualità dei servizi, alla riorganizzazione dei processi primari all’utenza, attraverso la riqualificazione del personale sulle attività istituzionali e lo sviluppo della tecnologia per la modernizzazione dei sistemi gestionali;

• al controllo della qualità dei servizi erogati, attraverso la gestione di informazioni corrette, esaurienti e tempestive e il monitoraggio del livello di “soddisfazione” dell’utenza;

• al rafforzamento del governo e del controllo del sistema produttivo;

• all’ottenimento di economie di gestione attraverso un miglior utilizzo delle risorse e la razionalizzazione delle funzioni amministrative di supporto.

Tutto ciò implica lo sviluppo in INPS di nuovi modelli gestionali e di governance per:

• pianificare e monitorare l’andamento economico-finanziario e quindi migliorare l’efficacia e l’efficienza generale;

• innovare i processi produttivi, in termini di efficienza ed efficacia;

• promuovere un costante e continuo processo di “automiglioramento” della gestione;

• sviluppare le competenze professionali;

• valorizzare le potenzialità dei sistemi informativi/informatici in uso.

Il percorso di innovazione avviato dall’Istituto si fonda su tre principali strategie di sviluppo:

• l’organizzazione – per l’innovazione e l’adeguamento della struttura organizzativa centrale e territoriale rispetto alle mutate esigenze produttive e gestionali e ai nuovi input normativi;

• l’efficacia e l’efficienza dei processi – per la rilevazione delle criticità e individuazione delle possibili soluzioni all’interno dei processi istituzionali o di supporto, ponendo maggiore attenzione a quei processi strategici per i quali un miglioramento porti ad un effettivo e immediato avanzamento delle performance generali dell’Istituto, soprattutto in termini di efficienza produttiva e qualità dei livelli di servizio;

• le sinergie interistituzionali – per la definizione del contributo di INPS al riordino del sistema di previdenza e per identificare le possibili convergenze verso gli obiettivi di maggiore efficienza ed efficacia del settore previdenziale.

Per l’attuazione delle strategie di sviluppo l’INPS ha adottato una serie di provvedimenti che introducono linee guida e procedure operative sulle modalità di attuazione delle prescrizioni legislative e degli obiettivi di innovazione su cui l’Istituto è impegnato.

Gli obiettivi riportati nella "Relazione programmatica per gli anni 2014-2016" (Deliberazione CIV n. 7 del 16 aprile 2013) delineano le attività dell’Istituto per il triennio 2014-2016 in una prospettiva d’innovazione ed ammodernamento dei processi che possa meglio rispondere ad esigenze di efficienza, efficacia e qualità del servizio.

1.2. Il contesto normativo di riferimento

Negli ultimi anni sono state molteplici le disposizioni governative finalizzate a una convergenza e armonizzazione del sistema pensionistico a al miglioramento dell’efficienza e dell’efficacia dell’azione amministrativa nel settore previdenziale e assistenziale.

Fra questi si segnalano:

Legge 14 settembre 2011, n. 148 “Conversione in legge, con modificazioni, del decreto legge 13 agosto 2011, n. 138 recante ulteriori misure urgenti per la stabilizzazione finanziaria e per lo sviluppo”. Tale legge ha introdotto, tra l’altro, alcune novità in materia previdenziale:

• Nuove decorrenze dei trattamenti pensionistici per il personale del comparto scuola e AFAM (art. 1, comma 21)

• Ultimo stipendio ai fini del calcolo del trattamento pensionistico e di fine servizio in caso di incarichi dirigenziali inferiori a tre anni conferiti a dirigenti civili delle amministrazioni statali (art. 1, comma 32)

• Nuovi termini di pagamento dei trattamenti di fine servizio e fine rapporto (art. 1, commi 22 e 23)

Legge 12 novembre 2011, n. 183 “Disposizioni per la formazione del bilancio annuale e pluriennale dello Stato (c.d. Legge di stabilità 2012)”. Tale legge, tra l’altro, ha previsto:

• l’istituzione presso l’Inpdap della “Gestione degli interventi assistenziali e di sostegno alla gestione previdenziale”.

Direttiva n. 14/2011 del Ministro della Pubblica amministrazione e della semplificazione, avente ad oggetto “Adempimenti urgenti per l’applicazione delle nuove disposizioni in materia di certificati e dichiarazioni sostitutive di cui all’art. 15 della legge 12 novembre 2011, n.183” che chiarisce che tali disposizioni hanno quale obiettivo ultimo la completa “decertificazione” del rapporto tra la pubblica amministrazione e i cittadini.

Legge 22 dicembre 2011, n. 214 “Conversione in legge, con modificazioni, del decreto legge 6 dicembre 2011, n. 201, recante disposizioni urgenti per la crescita, l’equità e il consolidamento dei conti pubblici” (c.d. Salva Italia) che, tra le tante disposizioni, ha previsto:

• la soppressione dell’Inpdap e dell’Enpals ed il trasferimento delle loro funzioni, risorse strumentali, umane e finanziarie all’Inps (art. 21 comma 1);

• il divieto di trasferimento di denaro contante di importo pari o superiore a 1.000 euro e l’obbligo per le pubbliche amministrazioni di utilizzare strumenti di pagamento elettronici per la corresponsione di stipendi, pensioni e compensi di importo superiore a tale cifra ( art. 12 commi 1 e 2).

Tale legge ha inoltre introdotto significative novità in campo pensionistico (sistema di calcolo, requisiti di accesso, aliquote contributive, ecc).

Decreto legge 6 luglio 2012, n. 95 “Disposizioni urgenti per la revisione della spesa pubblica con invarianza dei servizi ai cittadini” che, applicando la spending review, ha previsto una serie di norme dirette alla razionalizzazione della spesa pubblica che hanno avuto un notevole impatto sull’attività dell’Istituto.

Decreto legge 18 ottobre 2012 , n.179 “Ulteriori misure urgenti per la crescita del Paese”, pubblicato sulla Gazzetta ufficiale n. 245 del 19 ottobre 2012, che ha introdotto, in particolare all’art. 15, modifiche all’art. 5 del CAD, riguardante i pagamenti elettronici a favore delle PA e dei conseguenti obblighi.

Legge di stabilità 2013 approvata con la Legge 24 dicembre 2012 n. 228, pubblicata sulla Gazzetta ufficiale n. 302 del 29 dicembre 2012, che introduce una serie di interventi di cui si segnalano alcuni di maggiore rilevanza:

• I commi da 231 a 237 prevedono norme per i “salvaguardati”, stabilendo che la disciplina vigente prima dell’entrata in vigore della legge “Fornero” n. 201/2011, si applica anche ai lavoratori che maturano i requisiti successivamente al 31 dicembre 2011 quando sono in possesso di taluni requisiti;

• I commi da 238 a 248 rinnovano per gli iscritti alle gestioni CPDEL, CPS, CPI e CPUG, cessati dal servizio senza diritto a pensione entro il 30 luglio 2010, la possibilità di costituire a domanda la posizione assicurativa presso l’Inps ai sensi della legge n. 322/58.

1.3. La missione dell’INPS - Gestione Dipendenti Pubblici

L'Istituto Nazionale di Previdenza e Assistenza per i Dipendenti dell'Amministrazione Pubblica (INPDAP) era un ente pubblico non economico istituito, a seguito della delega conferita al governo con la legge 24 dicembre 1993, n. 537, dal d.lgs. 30 giugno 1994, n. 479.

Il decreto legge 6 dicembre 2011, n. 201, convertito con la legge 24 dicembre 2011, n. 214 ha disposto la soppressione dell'INPDAP trasferendo all'INPS le relative funzioni.

L’ex INPDAP, nel seguito INPS - Gestione Dipendenti Pubblici, provvede a molteplici servizi nel settore della previdenza e dell'assistenza dei pubblici dipendenti:

• gestisce i contributi previdenziali ed assistenziali della quasi totalità dei dipendenti pubblici;

• eroga le pensioni al personale collocato in quiescenza;

• eroga il trattamento di fine servizio (TFS) o (divenuto per gli assunti dal 01/01/2001) il trattamento di fine rapporto (TFR), l’assicurazione sociale Vita, nonché la previdenza complementare ai dipendenti pubblici;

• definisce il riconoscimento di servizi e periodi utili a pensione e/o previdenza.

Provvede inoltre alla gestione di attività di welfare:

• eroga prestiti, cessioni e mutui edilizi a tasso agevolato al personale iscritto all'Istituto;

• eroga prestazioni sociali a iscritti, pensionati e figli di iscritti (borse di studio, master, case albergo, vacanze studio in Italia e all’estero).

I servizi del primo gruppo corrispondono ad analoghi servizi che, seppur sulla base di normative e conseguenti differenti regole, INPS svolge a favore dei dipendenti privati; i servizi del secondo gruppo non trovano invece corrispondenza e rappresentano una assoluta peculiarità della Gestione Dipendenti Pubblici.

A decorrere dal 1º gennaio 1996, la Gestione Dipendenti Pubblici ha in carico la gestione separata dei trattamenti pensionistici dei dipendenti statali e delle altre categorie di personale i cui trattamenti di pensione sono a carico del bilancio dello Stato.

Le gestioni amministrate sono:

• Cassa Trattamenti pensionistici dei dipendenti statali

• Cassa Pensioni Dipendenti Enti Locali

• Cassa Pensioni Insegnanti

• Cassa Pensioni Sanitari

• Cassa Ufficiali Giudiziari

• INADEL

• ENPAS

• ENPDEDP

• ENAM

• Cassa Unica del Credito

Ogni mese gli Enti Pubblici presentano la Denuncia Mensile all'Istituto. Si tratta di una dichiarazione telematica contenente i dati previdenziali, i contributi, le retribuzioni e le contribuzioni destinate ai fondi di previdenza complementare, dei lavoratori retribuiti nel mese precedente.

Il sistema informativo Istituzionale dell’INPS – Gestione Dipendenti Pubblici

Il Sistema Informativo della Gestione Dipendenti Pubblici, denominato “SIN” (Sistema Informativo Normalizzato), è uno dei più rilevanti e complessi della Pubblica Amministrazione, per dimensioni, livello di aggiornamento tecnologico, numero di utenti e di servizi erogati.

Il SIN è il risultato del programma di normalizzazione dei pregressi sistemi informativi dell’Istituto, attuato attraverso una serie di iniziative pluriennali avviate fin dal 2005.

Finalità primarie del programma sono state il consolidamento dei diversi ambienti tecnologici disomogenei da cui era composto il sistema informativo, in un’unica infrastruttura omogenea e moderna e la realizzazione delle principali funzionalità applicative, necessarie alla automazione dei processi produttivi dell’Istituto, sia sul fronte dei servizi istituzionali (rivolti a pensionati, dipendenti pubblici, cittadini, imprese e altre amministrazioni pubbliche), sia sul versante di altri servizi, come previsti dalla normativa che regola il funzionamento delle pubbliche amministrazioni.

Il programma si è inoltre arricchito nel tempo di obiettivi specifici, sulla base dei Piani Industriali predisposti dall’Istituto e degli adempimenti posti in capo alla Gestione Dipendenti Pubblici dalla normativa via via emanata, crescendo e modificandosi in coerenza con questi riferimenti.

La prima fase di sviluppo del SIN, che si può far coincidere sostanzialmente con il periodo che va dal 2005 alla metà del 2010, quando si sono conclusi i contratti per la realizzazione delle funzioni applicative istituzionali del SIN sottoscritti nel 2005, ha realizzato l’automazione dei processi produttivi degli uffici, consolidato l’architettura tecnologica nel Data Center di Roma, realizzato le funzioni base di autogoverno e la piattaforma per la gestione degli adempimenti fiscali.

La seconda fase, avviata nella metà del 2010 con la pubblicazione della gara a procedura aperta per un contratto triennale per la manutenzione evolutiva e gli ulteriori sviluppi di applicativi a supporto delle funzioni istituzionali dell’Ente, e successivamente arricchita con le nuove gare a procedura aperta per contratti, sempre di durata triennale, per l’evoluzione del sistema di autogoverno e della piattaforma fiscale dell’Istituto, si è posta come obiettivi il miglioramento della qualità dei servizi e la modernizzazione della struttura secondo le linee di indirizzo del Piano delle Performance e del Codice dell’Amministrazione Digitale (CAD).

Nei paragrafi seguenti è riportata una breve sintesi della struttura attuale e della dimensione del SIN.

1.4. Area Istituzionale

Il SIN è il sistema informativo istituzionale basato su processi e servizi comuni che condividono un’unica base dati integrata. In particolare l’architettura, realizzata interamente in accordo con il modello SOA (Service Oriented Architecture), è impostata su 8 aree applicative distinguibili in due gruppi:

1. Anagrafica, Entrate, Posizione Assicurativa, Pensioni, Prestazioni pensionistiche in vigenza;

2. Prestazioni previdenziali, Credito, Attività sociali

Il primo gruppo è quello che trova corrispondenza in analoghe aree applicative della Gestione Dipendenti Privati; il secondo gruppo è quello peculiare della Gestione dipendenti pubblici.

L’area dei Processi Trasversali e di integrazione mette a disposizione delle aree applicative diversi servizi tra cui un sistema di automazione e gestione processi (“scrivania virtuale”) e servizi comuni di gestione della documentazione in entrata e in uscita.

Le diverse aree rendono poi disponibili specifici servizi per lo svolgimento di attività di comune utilizzo, ad esempio servizi di anagrafe, servizi di posizione assicurativa, piani di ammortamento, calcolo dell’anzianità contributiva, funzioni di pre-calcolo della pensione.

Gli standard architetturali prevedono quindi il totale disaccoppiamento fra le diverse componenti (presentation, business logic, data layer) e l’apertura a servizi “esterni”.

L’obiettivo di una tale architettura applicativa è quello di agevolare l’integrazione completa di sistemi dipendenti, attraverso processi di business facilmente gestibili, automatizzando le interazioni tra i vari applicativi. Ogni area governa i dati di ‘proprietà’ e sviluppa servizi per il governo della stessa ed i servizi richiesti dalle altre aree, visto che nessun’area può accedere direttamente ai dati dell’altra, se non attraverso i servizi.

Tutto questo comporta vantaggi sull’efficienza complessiva del sistema, derivanti essenzialmente dalle interazioni attraverso servizi condivisi e dalla disponibilità di componenti trasversali comuni (strumenti informatici e servizi a supporto) finalizzati alla qualità, ottimizzazione e razionalizzazione delle funzioni.

Agevola inoltre nuovi processi di integrazione degli applicativi sia a livello “orizzontale” (ovvero integrazioni fra componenti di business), sia a livello “verticale” ovvero integrazione della logica di business di diversi presentation o diversi Data Base. L’architettura SOA, infatti, consente ad esempio di utilizzare qualsiasi soluzione tecnica di protocollo, archiviazione documentale, workflow management, oltre ad una agevole integrazione (grazie alla logica “a servizi”) con sistemi esterni quali quelli dei datori di lavoro, patronati e altri partner istituzionali come MIUR e MEF.

L’esempio riportato nella figura seguente rappresenta l’architettura applicativa orientata ai servizi (SOA), riferita ad una singola prestazione. L’area Prestazioni Pensionistiche condivide servizi applicativi con Posizione Assicurativa, Anagrafe e Entrate utilizzando i servizi trasversali (documenti in entrata e in uscita, Gestione pratica e fascicolo).

L’architettura applicativa Esempio: Prestazioni Pensionistiche

1.5. Baseline

Di seguito sono riportati i dati di consuntivo per area istituzionale dei recenti contratti di sviluppo presso INPS Gestione Dipendenti Pubblici.

Area Funzionale	TOTALI

Anagrafica	6.861,82
Entrate	23.389,38
Posizione Assicurativa	10.282,06
Pensioni	57.085,60
Prestazioni pensionistiche in vigenza	21.776,78
Prestazioni previdenziali	15.628,80
Credito	24.348,40
Attività sociali	11.406,48
Processi trasversali e di integrazione	49.850,80
TOTALE	220.630,12

La tabella non riporta i dati relativi agli interventi che sono in corso di realizzazione e che non sono ancora conclusi. Si ipotizza che a fine contratto la baseline di riferimento sarà pari a 261.000 FP.

1.6. Le banche dati del SIN

La Banca Dati Unificata e la Banca Dati Normalizzata

La Banca Dati Unificata (BDU) è l'insieme delle strutture dati in cui è stato rappresentato il patrimonio informativo delle attività istituzionali su cui operava il vecchio sistema informativo NSI. Il sistema NSI è stato chiuso nel 2011, completandone la migrazione delle applicazioni nel SIN.

La Banca Dati Normalizzata (BDN) è la banca dati su cui invece si basa il sistema SIN.

Referenti Istituto

DBA

Gruppi Applicativi

Governo del Patrimonio Informativo del SIN

1.7. Alcuni dati dimensionali del sistema

Dal punto di vista delle infrastrutture tecnologiche, il SIN è realizzato su una architettura centralizzata, in cui il Data Center di Roma, costituito da una server farm di circa 500 server logici, basata su moderne tecnologie, eroga servizi agli utenti, interni ed esterni, attraverso collegamenti in rete, intranet o internet.

Gli utenti del SIN, oltre ai dipendenti dell’Istituto, sono:

▪ i cittadini (iscritti - circa 3,5 milioni- pensionati – circa 2,7 milioni - loro familiari);

▪ i datori di lavoro (Amministrazioni ed Enti della Pubblica Amministrazione);

▪ gli altri Enti Previdenziali, i Ministeri e gli organi di controllo;

▪ i CAF, i patronati e gli operatori finanziari (per un totale di circa 9.000 operatori abilitati).

Nell’ambiente di esercizio sono gestite circa 5.700 tabelle totali (di cui 3.700 gestionali e 2.000 informative statistiche). La dimensione della Banca dati è di circa 7,3 TB.

Le posizioni anagrafiche gestite nel SIN sono:

▪ circa 32.000 datori di lavoro pubblico – complete della storia di fusioni e cessazioni;

▪ circa 3,5 milioni di dipendenti pubblici in servizio, la cui posizione assicurativa è aggiornata mensilmente;

▪ circa 2,7 milioni di pensionati.

L’Inps Gestione Dipendenti Pubblici ha sviluppato un elevato livello di informatizzazione dei propri dipendenti:

• tutti i dipendenti sono dotati di postazione di lavoro informatica, hanno accesso alla posta elettronica e possono, previa richiesta del Dirigente, accedere a internet;

• tutte le AOO, i dirigenti, i professionisti, dispongono di casella di PEC, referenziata sul sito web nell’indice della PA gestito dall’Agenzia per l’Italia Digitale (ex DigitPA);

• è possibile firmare digitalmente i documenti, anche quelli trasmessi via PEC;

• gli utenti interni dispongono di servizi di “collaboration”, che consentono, tra l’altro, la condivisione dei documenti e del workflow di gestione dei documenti su siti web intranet “sharepoint”, la video comunicazione collaborativa, con possibilità di usufruire di servizi di videocomunicazione punto-punto e multi-punto dal proprio PC, anche per svolgere sessioni di formazione a distanza, l’Integrazione VoIP con il centralino telefonico tradizionale, l’istant messanging;

• i dipendenti possono usufruire di una piattaforma per il telelavoro (accesso da remoto alle risorse informatiche della rete interna), basata su tecnologia Citrix e Microsoft, che consente loro di accedere in sicurezza, anche da remoto, alla intranet, alla posta elettronica e ai servizi SIN;

• i servizi del SIN si interfacciano con il protocollo Inps – Gestione dipendenti Privati, chiamato GFD/PIU.

1.8. I principali ambiti evolutivi

Di seguito sono riportati i principali ambiti evolutivi previsti per il biennio 2014-2015 risultanti dalle esigenze amministrative dell’Istituto sia ai fini del miglioramento dei servizi offerti che del recepimento delle modifiche normative.

Servizi on line per la Previdenza e il Welfare

In coerenza con quanto indicato dal CAD e previsto nel Piano industriale 2009-2011 e nel Piano delle Performance 2011-2013, l’Inps Gestione Dipendenti Pubblici ha concentrato i suoi sforzi per rendere i propri servizi progressivamente disponibili agli utenti soprattutto in modalità on line, agendo nel contempo anche per semplificarli e renderli sempre più accessibili, anche in modalità multicanale.

In tale ambito sono stati avviati diversi interventi, in parte già completati altri in corso.

Dematerializzazione dei rapporti con i cittadini, con le P.A. e con i dipendenti.

L’Istituto ha avviato una serie di interventi finalizzati a realizzare la gestione completamente

informatizzata dell’intero iter delle pratiche, dalla presentazione del modulo di richiesta da parte dell’utente, alla gestione della documentazione allegata, attraverso il sistema di gestione documentale in uso presso l’Istituto, fino all’eventuale pagamento che tiene conto delle evoluzioni normative introdotte dal nuovo CAD nell’ambito dell’uso della PEC e della firma digitale.

Ottimizzazione della integrazione tra Posizione Assicurativa e Prestazioni

La disponibilità di una posizione assicurativa aggiornata degli iscritti è di fondamentale importanza per poter definire le prestazioni cui l’iscritto ha diritto: pensioni, indennità di fine servizio, trattamenti di fine rapporto, prestiti e mutui, riscatti e ricongiunzioni. La posizione assicurativa consente, inoltre, all’iscritto di accertare se possiede i requisiti richiesti dalla normativa per l´accesso alla pensione e di valutare se aderire a fondi di previdenza complementare. La Gestione Dipendenti Pubblici costruisce e gestisce la posizione assicurativa di ogni dipendente pubblico iscritto (dati anagrafici, amministrazione datore di lavoro, stato di servizio, retribuzioni, periodi di “servizio riconosciuto” - i periodi ricongiunti, riscattati o, comunque, computati nella complessiva anzianità contributiva).

La posizione assicurativa è alimentata dalle Amministrazioni e dagli Enti pubblici, in qualità di datori di lavoro, che trasmettono all’Istituto, certificandoli, i dati anagrafici e previdenziali dei propri dipendenti. L’alimentazione avviene tramite un flusso informatico mensile (la Denuncia Mensile UNIEMENS) e attraverso interventi sulla posizione assicurativa effettuati online (applicazione Passweb).

Recentemente è stato predisposto un nuovo progetto, noto come SIN 2, che sostanzialmente, pur conservando le specificità del pubblico impiego, allinea la gestione delle prestazioni e della posizione assicurativa della Gestione Dipendenti Pubblici a quella della Gestione Dipednenti Privati. Le principali linee previste sono:

• Unicità della fonte (DMA) per l’alimentazione del patrimonio informativo;

• Centralità della banca dati delle posizioni assicurative per l’erogazione di tutte le prestazioni istituzionali;

• Xxxxxxx coerenza fra posizione giuridica, posizione retributiva e posizione contributiva degli Iscritti;

• Più estesa cooperazione con Enti esterni;

• Monitoraggio e controllo qualitativo e quantitativo dei prodotti in ingresso e dei prodotti in uscita dal sistema e di tutte le fasi di produzione.

Gli impatti per il sistema informatico sono rilevanti, non solo sulle applicazioni della denuncia mensile, ma anche sulla struttura della banca dati (anche per la gestione dei dati storici) e sulle applicazioni di posizione assicurativa, ma anche sulle applicazioni delle aree inerenti alle prestazioni istituzionali.

Entrate e regolarità contributiva

In materia di entrate e regolarità contributiva l’Istituto ha dato indicazioni di orientarsi verso un aumento della capacità di riscossione delle entrate contributive e in direzione di una completa realizzazione della correntezza contributiva delle amministrazioni pubbliche.

L’evoluzione in corso consiste nella implementazione degli applicativi che consentiranno di garantire la correntezza dei versamenti contributivi da parte delle Amministrazioni Pubbliche, di effettuare le verifiche di congruenza tra accertato e riscosso e di attivare i recuperi di contributi e dei crediti.

Prestazioni Previdenziali,

Si tratta di prestazioni specifiche della Gestione Dipendenti Pubblici che, in questi ultimi anni, la normativa ha spesso modificato nelle regole e modalità di calcolo imponendo continue evoluzioni applicative.

Analoghe evoluzioni normative si prevedono per i prossimi anni vista l’attenzione alla materia pensionistica ed al welfare in generale. In particolare si prevedono nuovi sviluppi in relazione alle tematiche del Trattamento di Fine Servizio (TFS) e della Previdenza Complementare.

Prestazioni Creditizie e Sociali

Sono prestazioni Welfare, anche queste specifiche della Gestione Dipendenti Pubblici, che l'Istituto propone attravero forme di finanziamento agevolate e di interventi socio-assistenziali a favore degli iscritti, pensionati, e loro familiari.

Si prevedono nuovi sviluppi sw attivati con periodicità ricorrente dalla Direzione amministrativa competente, sia a fronte di cambiamenti normativi, sia a fronte delle opportunità che di volta in volta portano la Direzione competente a rivedere le condizioni dei bandi o ad intraprendere nuove iniziative di Welfare.

Unificazione alimentazione datawarehouse

Sono interventi finalizzati alla individuazione della componente dati necessaria ad alimentare il datawarehouse centralizzato dell’Istituto per sviluppare una “reportistica direzionale“, di supporto decisionale.

TECNOLOGIA DEL SIN

1.9. Contesto tecnico

Le attività oggetto di fornitura dovranno essere erogate nel contesto tecnico di seguito illustrato. In particolare dovranno essere garantite:

• la conformità al modello di architettura applicativa e agli standard tecnologici di progettazione e sviluppo previsti per l’intero Sistema Informativo;

• l’integrabilità delle realizzazione software 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 dell’Istituto.

L’architettura hardware e software del sistema informativo è stata disegnata in funzione del nuovo assetto organizzativo dell’Istituto e della volontà di offrire un sempre più ricco portafoglio di servizi agli utenti in modalità on line, tramite WEB/Internet.

Le componenti della infrastruttura prevedono:

• L’adozione di prodotti/piattaforme aperte relativamente ai servizi primari del sistema:

- Web e Application Server,

- Sistema di Access & Identity management,

- Servizi di Portale e Content Management,

- Prodotti di System and Network Management,

- RDBMS;

• un sottosistema di Storage (SAN) a garanzia della massima efficienza nell’accesso ai dati e della disponibilità e integrità delle informazioni,

• la separazione ai fini della sicurezza dell’area di accesso al sistema (Front-end) dall’area di produzione dei servizi (back-end),

• la separazione logica/fisica dei sistemi in rapporto alle finalità di utilizzo (esercizio, supporto/sviluppo, sistemi legacy).

Di seguito è riportato il disegno complessivo della infrastruttura tecnologica del sistema SIN per l’ambiente di Produzione. Gli ambienti di supporto hanno disegno analogo, pur se in configurazione ridotta.

1.9.1. L’Architettura tecnologica

L’ambiente tecnologico ospita le applicazioni e i dati per l’ambiente di produzione e di supporto ed è progettato per rispondere ad elevati requisiti di bilanciamento dinamico del carico, continuità del servizio, sicurezza ed integrità dei dati. L’alta affidabilità è realizzata sugli ambienti di Produzione, Collaudo e Preesercizio.

Il Layer di Frontend è realizzato su Server virtuali (su piattaforma VMWare), con Sistema operativo Linux Red Hat e l’impiego di IHS (IBM HTTP Server). L’alta affidabilità è realizzata mediante l’impiego di bilanciatori Hardware.

Il Layer Application Server e Policy Server è realizzato:

• per la componente Application Server, su LPAR (logical partition) con Sistema operativo AIX, su processori IBM PowerSystem 6 e 7, e l’impiego di IBM WebSphere Application

Server Network Deployment ed XD Versione 6.1. L’alta affidabilità è realizzata mediante l’impiego di ODR (On Demand Router) a loro volta in cluster software (WebSphere).

• per la componente Policy Server, su sistemi Intel virtuali su piattaforma VMWare.

Il Layer Data server è realizzato su LPAR con Sistema operativo AIX, su processori IBM PowerSystem 6 e 7, e l’impiego di RDBMS Oracle 9/10g/11 Enterprise Edition. L’alta affidabilità è realizzata mediante l’impiego del componente RAC (Real Application Cluster), dove applicabile.

In particolare sono presenti per l’ambiente di Produzione SIN:

• N. 5 server virtuali con la componente Web Server, per un totale di 10 CPU ed 640 GB di RAM,

• N. 6 Policy server virtuali, per un totale di 12 cpu e 192GB di RAM,

• N. 4 Sistemi IBM Power System P795 per la componente Application Server e DB Server, con la seguente configurazione hardware e software complessiva,

• N° 45 LPAR per un totale di n° 87 CPU a 4,0 GHz,

• 844 GB di RAM,

• S.O. AIX 5.3/6.1,

• PowerHA,

• GPFS,

• Virtual IO Server,

• Partition Load Manager.

L’ambiente di Supporto comprende gli ambienti di Sviluppo/Integrazione, Collaudo, Manutenzione, Pre-esercizio 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, ed in particolare:

• N. 4 server virtuali per la componente Web Server, per un totale di 8 CPU e 256 GB di RAM,

• N. 7 server virtuali per la componente Policy Server, per un totale di 14 cpu e 112GB di RAM,

• N. 4 sistemi IBM Power System P595 per la componente Application Server e DB Server con la seguente configurazione hardware e software complessiva:

o N° 66 LPAR per un totale di n° 94 cpu Power 6 a 4,2 GHz;

o 759 GB di RAM;

o S.O. AIX 5.3/6,1 ;

o PowerHA;

o GPFS;

o Virtual IO Server;

o Partition Load Manager.

Nell’ambiente di esercizio e di supporto sono compresi i sottosistemi di storage (comuni al resto della infrastruttura nativa INPS) e di back-up, nonché tutte le apparecchiature per la gestione del traffico di rete, la sicurezza e il monitoraggio dell’intero sistema.

La configurazione degli ambienti software SIN si completa con l’utilizzo delle seguenti tecnologie (l’elenco ha carattere esemplificativo, e non esaustivo):

• IBM MQ*Series,

• CA ETrust SiteMinder e Sun Java System IdM,

• LDAP Tivoli Directory server v.6.0,

• Suite AXWAY XFB,

• IBM Porta di dominio,

• Business Objects,

• SAS,

• Orsyp $UNIVERSE (schedulatore batch),

• Adobe.

L’Istituto metterà a disposizione dell’Impresa appaltatrice un ambiente di supporto che comprende i sistemi di Collaudo, Pre-esercizio e Formazione.

Sono invece a carico del Fornitore gli strumenti e gli ambienti per lo sviluppo, MEV e MAC del software, inclusivi dei tools (di analisi e disegno, di gestione della configurazione, di gestione dei test), che devono essere conformi agli standard adottati dall’istituto al fine di garantire l’omogeneità degli strumenti utilizzati anche al fine di semplificare le attività di manutenzione.

1.10. Architettura Applicativa

Il software applicativo di riferimento è realizzato in linguaggio Java in accordo con lo standard, J2EE, utilizzando l’Application Server reso disponibile dall’Istituto (IBM Websphere), descritto nei paragrafi precedenti.

In accordo allo standard J2EE, l’architettura applicativa del SIN è composta dai livelli logici riportati nella tabella che segue.

Livello di Presentazione

Sul lato Client, l’interfaccia utente e di presentazione è 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 sono implementati attraverso un WEB Server. I servizi applicativi sono implementati da un Application Server conforme allo Standard J2EE.
Livello Dati	Il livello Dati del sistema è implementato sulla piattaforma RDBMS ORACLE.

Ciascun livello logico dell’applicazione è 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 sono state realizzate in HTML con l’inserimento di eventuali controlli di tipo Java Script. La preparazione dinamica delle pagine di presentazione è stata attuata attraverso componenti JSP (Java Server Page) presenti sul lato server.

Implementazione del Livello di Logica Applicativa

I servizi di dialogo con il livello client e di accesso ai servizi applicativi sono stati implementati attraverso Servlet eseguite sotto il controllo di un WEB Server. Possono essere supportati i protocolli di comunicazione Http, Https e SSL.

Il progetto prevede la separazione dei componenti che implementano la logica applicativa dai componenti di accesso ai dati. I componenti applicativi sono stati realizzati sullo standard EJB Session Beans e Entity Beans. I servizi batch sono stati implementati come componenti Java.

Implementazione del livello Dati

La Base Dati viene gestita dal RDBMS Oracle per garantire la continuità di esercizio e la massima portabilità delle informazioni.

Definizione della Fornitura

1.11. Gli obiettivi della Fornitura

Obiettivo principale dell’Istituto per ciò che attiene la presente fornitura è quello di garantire la flessibilità e rapidità nella risposta alle esigenze di sviluppo e manutenzione applicativa, cioè garantire l’agilità nella risposta alle mutevoli esigenze dell’amministrazione al variare del contesto normativo, delle direttive della azione politica e della missione dell’Istituto.

Per il raggiungimento di tale obiettivo la presente fornitura prevede servizi di sviluppo e manutenzione del parco applicativo esistente e di quello che sarà sviluppato nel corso della durata della fornitura.

In tale ambito, s’individuano le seguenti linee di intervento:

• L1 - Unificazione – volta ad individuare, definire ed attuare percorsi per eliminare le sovrapposizioni tra servizi erogati per la Gestione Dipendenti Privati e servizi erogati per la Gestione Dipendenti Pubblici e ricondurre ad una modalità unitaria la gestione di servizi analoghi, a valle della revisione dei processi amministrativo-organizzativi. Sarà pertanto necessario supportare le Direzioni amministrative nell’analisi delle aree di coincidenza dei servizi attualmente erogati, valutando, caso per caso, quale sia conveniente migrare dal sistema informativo della Gestione dei Dipendenti Pubblici e in che misura.

• L2 - Reingegnerizzazione – volta ad individuare, definire ed attuare percorsi per la reingegnerizzazione dei servizi erogati nel contesto unitario, a valle della revisione dei processi amministrativo-organizzativi e per il raggiungimento della piena omogeneità con quelli della Gestione Dipendenti Privati. Le relative attività sono necessarie al fine di ridisegnare la modalità di erogazione dei servizi esistenti, alla luce della riorganizzazione che l’Istituto sta affrontando a seguito dell’accorpamento dei due enti.

• L3 - Consolidamento – finalizzata a far evolvere le componenti del SIN che, non sovrapponendosi ad analoghi servizi forniti dalla Gestione Dipendenti Privati, in quanto relative a processi specifici della Gestione Dipendenti Pubblici, continueranno ad essere oggetto di sviluppo e manutenzione evolutiva nel nuovo contesto unitario. Sarà infatti necessario realizzare nuove funzionalità nell’ambito delle aree credito, attività sociali e prestazioni previdenziali derivanti da esigenze di evoluzione specifiche, anche periodiche, delle aree suddette e allineare nel tempo le applicazioni già in esercizio ad eventuali nuove esigenze funzionali (derivanti da modifiche del contesto normativo, organizzativo o amministrativo ) e/o tecnologiche dell’Istituto.

La confluenza dell’Inpdap nell’Istituto non ha cancellato infatti la specificità del sistema previdenziale pubblico; ad esempio, nell’ambito delle prestazioni previdenziali, la necessità di perseguire l’obiettivo dell’aggiornamento del “conto previdenziale” rende indispensabile l’adeguamento della banca dati delle posizioni assicurative della Gestione dei Dipendenti Pubblici, attraverso l’alimentazione continua effettuata da tutte le amministrazioni pubbliche (cfr. “CIV- Relazione programmatica 2014-2016”).

Inoltre, con Circolare INPS n.31 del 25 febbraio 2013, è stata avviata, con decorrenza 1 aprile 2013, la fase di sperimentazione del nuovo modello organizzativo integrato di Direzione provinciale, che interesserà inizialmente un campione di sedi. Il percorso previsto per il riassetto organizzativo delle sedi territoriali tiene conto coerentemente delle specificità delle prestazioni erogate dalla Gestione dei Dipendenti Pubblici , delle procedure e dei processi organizzativi utilizzati dagli stessi, nonché della necessità di assicurare elevati standard qualitativi dei servizi. Da qui l’esigenza di perseguire il consolidamento dei servizi applicativi sottostanti le prestazioni erogate dalle sedi all’utenza.

Sarà inoltre necessario:

• assicurare il corretto funzionamento delle applicazioni curando la rimozione delle eventuali malfunzioni;

• supportare l’avviamento in esercizio delle applicazioni;

• provvedere al mantenimento e alla evoluzione del modello concettuale della banca dati del SIN nell’ambito del più ampio patrimonio dati dell’Istituto;

• supportare il personale nell’uso appropriato delle applicazioni SIN, affiancando l’Istituto anche nella ridefinizione dei processi lavorativi ed organizzativi, nella definizione delle modalità di integrazione tra le funzioni istituzionali del SIN e quelle fornite da altri sistemi in uso presso l’Istituto, nel colloquio con le altre amministrazioni pubbliche;

• assicurare l’integrazione tra le diverse Aree funzionali del SIN e l’integrazione delle applicazioni del SIN con gli altri ambienti tecnologici dell’Istituto.

1.12. Oggetto della Fornitura

I servizi oggetto della fornitura in esame sono:

• Sviluppo (SV);

• Manutenzione Evolutiva (MEV);

• Manutenzione Adeguativa (MAD);

• Manutenzione Correttiva (MAC);

• Gestione Applicativa (GA);

• Supporto Specialistico Tecnico (SST).

1.13. Suddivisione in Lotti della Fornitura

La fornitura dei suddetti servizi è articolata in 2 Lotti. Ciascun Lotto:

• prevede in misura diversa tutti i servizi oggetto della fornitura e fa riferimento ad uno specifico parco applicativo sviluppato ed esistente;

• comprende sia attività di tipo progettuale che attività di tipo continuativo volte a rispondere alle esigenze di nuovi sviluppi ed evoluzioni ed a garantire un presidio stabile per la continuità e qualità dei servizi applicativi erogati agli utenti.

La ripartizione in Lotti è stata concepita per garantire la maggiore flessibilità di intervento da parte dell’Istituto e soprattutto per assicurare la responsabilizzazione dei fornitori rispetto alla peculiarità delle diverse linee di intervento individuate.

Infatti la prime due Linee di Intervento (L1 – Unificazione e L2 – Reingegnerizzazione) afferiscono a tutte le iniziative dell’Istituto volte al raggiungimento della piena omogeneità delle due Gestioni sia dei Dipendenti Privati che Pubblici, mentre la terza Linea di Intervento (L3 – Consolidamento) è rivolta all’evoluzione dei servizi specifici della Gestione Dipendenti Pubblici.

L’Istituto ha già da tempo intrapreso un percorso volto ad una forte strutturazione e sistematizzazione

delle attività di governance dei contratti IT per definire i meccanismi di interazione tra le singole forniture e componenti di servizio, con particolare attenzione alla definizione dei punti di interazione e dei livelli operativi.

I servizi sono relativi alle aree in cui si articola il sistema informativo della Gestione Dipendenti Pubblici secondo le linee di intervento previste:

• Lotto 1 – Unificazione (Linea L1) e Reingegnerizzazione (Linea L2)

• Lotto 2 – Consolidamento (Linea L3)

La tabella seguente indica la distribuzione dei servizi previsti dalla fornitura, suddivisi per Area applicativa/Linea di intervento ragguppati in Lotti:

Aree applicative SIN	Lotto n.1		Lotto n.2
Aree applicative SIN	X0	X0	X0
Anagrafica	X	x
Entrate	X	x
Posizione assicurativa	X	x
Pensioni	X	x
Prestazioni pensionistiche in vigenza	X	x
Prestazioni previdenziali			X
Credito			X
Attività sociali			X
Processi trasversali e di integrazione	x	x

Si riportano di seguito la descrizione del contenuto generale dei due Lotti in cui si articola la fornitura.

1.13.1. Lotto 1

Linea di intervento L1– Unificazione

Nell’ambito della linea riguardante l’unificazione, si riportano di seguito le aree di intervento di maggior rilievo:

• Unificazione pagamento pensioni - predisposizione di una stessa modalità per la gestione di servizi di pagamento delle pensioni e della loro rendicontazione, unificando in tale modo anche il flusso finanziario.

• Unificazione sistemi contabili - emissione centralizzata dei mandati di pagamento, nell’ambito del sistema contabile.

• Unificazione Riscossione coattiva – Estratto Conto Amministrazione per Ente ed unificazione con

S.I. INPS Gestione Dipendenti Privati per ‘infasamento’ crediti.

• Unificazione alimentazione datawarehouse - Individuazione della componente dati necessaria ad alimentare il datawarehouse centralizzato dell’Istituto per sviluppare una “reportistica direzionale“, di supporto decisionale.

Linea di intervento L2 – Reingegnerizzazione

A valle della riorganizzazione amministrativa in atto nell’Istituto e delle conseguenti revisioni dei

processi, tutte le aree applicative del SIN, ad eccezione di quelle previste nella linea di ‘Consolidamento’, sono interessate dalla reingegnerizzazione. In questo ambito, è stato previsto l’utilizzo della maggior parte dei servizi di supporto specialistico.

1.13.2. Lotto 2

Linea di intervento L3 – Consolidamento

Questa linea di intervento prevede sviluppi nell’ambito delle aree applicative specifiche della Gestione Dipendenti pubblici di seguito descritte:

• Attività Sociali - Sono prestazioni attraverso cui l’Istituto eroga interventi socio-assistenziali a favore degli iscritti, pensionati e loro familiari. Si prevedono nuovi sviluppi sw attivati con periodicità ricorrente dalla Direzione amministrativa competente, sia a fronte di cambiamenti normativi, sia a fronte delle opportunità che di volta in volta portano la direzione competente a rivedere le condizioni dei bandi o ad intraprendere nuove iniziative di Welfare.

• Credito – Sono prestazioni attraverso cui l’Istituto eroga forme di finanziamento agevolate a favore degli iscritti, pensionati e loro familiari. Si prevedono nuovi sviluppi sw attivati con periodicità ricorrente dalla Direzione amministrativa competente, sia a fronte di cambiamenti normativi.

• Prestazioni Previdenziali – Si tratta di prestazioni che in questi ultimi anni la normativa ha spesso modificato nelle regole e modalità di calcolo, imponendo continue evoluzioni applicative. Analoghe evoluzioni normative si prevedono per i prossimi anni, considerata l’attenzione alla materia pensionistica. In particolare si prevedono nuovi sviluppi in relazione alle tematiche del Trattamento di Fine Servizio (TFS) e della Previdenza Complementare.

1.13.3. Dimensionamento dei Lotti

I Lotti comprendono i servizi oggetto della fornitura dimensionati come segue:

Lotto n.1

Servizio	Metrica	Criteri dimensionamento	Quantità
Sviluppo	FP	Servizi	48.750
Manutenzione Adeguativa	Giorni Uomo	65% di 7 FTE totali per 20 gg per 24 mesi	2.184
Manutenzione Correttiva (nuovi sviluppi)	Canone	65% dei 48.000 FP che entrano in MAC	Previsti 31.200 FP
Manutenzione Correttiva (software esistente)	Giorni Uomo	65% di 4 FTE totali per 20 giorni per 24 mesi	1.248
Gestione applicativa help desk 2° livello	Canone	65% di 12 FTE equivalent totali per 20 giorni al mese per 24 mesi	3.744
Gestione applicativa: Assistenza applicativa	Giorni Uomo	65% di 90 FTE totali per 20 giorni al mese per 24 mesi	31.200
Gestione applicativa: Supporto al Governo del Patrimonio Informativo	Giorni Uomo	65% di 10 FTE totali per 20 giorni al mese per 24 mesi.	31.200
Supporto Specialistico Tecnico	Giorni uomo	65% di 50 FTE totali per 20 giorni per 24 mesi	15.600

Totale FP = 48.750, Totale GG/PP = 50.232

Lotto n.2

Servizio	Metrica	Criteri dimensionamento	Quantità
Sviluppo	FP	Servizi	26.250
Manutenzione Adeguativa	Giorni Uomo	35% di 7 FTE per 20 gg per 24 mesi	1.176
Manutenzione Correttiva (nuovi sviluppi)	Canone	35% dei 48.000 FP che entrano in MAC	Previsti 16.800 FP
Manutenzione Correttiva (software esistente)	Giorni Uomo	35% di 4 FTE totali per 20 giorni per 24 mesi	672
Gestione applicativa help desk 2° livello	Canone	35% di 12 FTE equivalent totali per 20 giorni al mese per 24 mesi	2.016
Gestione applicativa: Assistenza applicativa	Giorni Uomo	35% di 90 FTE totali per 20 giorni al mese per 24 mesi	16.800
Gestione applicativa: Supporto al Governo del Patrimonio Informativo	Giorni Uomo	35% di 10 FTE totali per 20 giorni al mese per 24 mesi.	16.800
Supporto Specialistico Tecnico	Giorni uomo	35% di 50 FTE totali per 20 giorni per 24 mesi	8.400

Totale FP = 26.250, Totale GG/PP = 27.048

Descrizione dei servizi e Modalità di erogazione della Fornitura

1.14. Descrizione dei servizi oggetto della fornitura

1.14.1. Sviluppo Software e Manutenzione Evolutiva (SV e MEV)

Descrizione e requisiti del servizio di Sviluppo e MEV

Tra gli interventi previsti nell’ambito del servizio di Sviluppo software, sono compresi:

• gli sviluppi di applicazioni che risolvono esigenze specifiche a fronte di funzionalità non informatizzate;

• il rifacimento di sistemi informativi o applicazioni, le cui funzionalità non sono soddisfatte con le modalità esistenti, previa valutazione che non sia conveniente attuare una manutenzione evolutiva al software in esercizio.

Il dettaglio degli interventi previsti è descritto in Allegato 1.

Manutenzione Evolutiva di software comprende gli interventi volti ad arricchire il prodotto (di nuove funzionalità o di altre caratteristiche non funzionali, quali l’usabilità, le prestazioni, ecc.) o comunque a modificare o integrare le funzionalità del prodotto o garantire l’allineamento del sistema alle modifiche normative ordinarie e straordinarie. Il servizio implica l’ integrazione di funzioni aggiuntive o parti di funzioni ad applicazioni esistenti (anche in sostituzione di altre già esistenti) di dimensioni anche significative e di cui non è possibile preventivamente definire i requisiti o quantomeno identificare le esigenze. Si tratta di implementazioni anche aggregabili fra loro, che comunque danno luogo a una nuova release/baseline del prodotto iniziale.

Il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari a mantenere aggiornata la Baseline in punti funzione (FP).

Criteri di Dimensionamento e misura del servizio

Il servizio di Sviluppo e MEV verrà dimensionato unicamente in base alle seguenti metriche

Servizio	Modalità	Metrica
Sviluppo e Manutenzione Evolutiva (MEV)	Progettuale	FP

I valori dei Function Point che saranno conteggiati dall’Istituto, dovranno essere rendicontati rispetto alle tre diverse tipologie di FP: ADD, CHG, DEL. In particolare, per gli interventi di sviluppo e MEV gestiti si chiede al fornitore di evidenziare l’effort sostenuto a fronte delle 3 differenti tipologie di risultato prodotto dall‟intervento applicativo. Occorrerà, pertanto, distinguere se l’intervento applicativo darà luogo alla realizzazione di:

• nuove funzionalità (ADD);

• eliminazioni di precedenti funzionalità (DEL);

• modifica funzionalità esistenti (CHG).

Ciò anche al fine di determinare in modo differenziato il corrispettivo per l’intervento prestato, così come riportato nello schema di contratto.

Di seguito si riporta la tabella di riepilogo che sintetizza, per linea di intervento all’interno di ciascun Lotto, la distribuzione in Function Point degli interventi.

Aree applicative SIN	Lotto n.1		Lotto n.2
Aree applicative SIN	X0	X0	X0
Anagrafica	2.115	1.725	0
Entrate	3.173	3.450	0
Posizione assicurativa	3.173	3.450	0
Pensioni	6.344	10.350	0
Prestazioni pensionistiche in vigenza	2.115	6.900	0
Prestazioni previdenziali	0	0	8.700
Attività sociali	0	0	8.650
Credito	0	0	8.900
Processi trasversali e di integrazione	4.230	1.725	0
Totale FP Lotti	48.750		26.250

Dettagli sulle attività incluse nel costo del Function point

Si precisa che oltre a tutte le attività che compongono il ciclo di vita del sw dalla definizione dei requisiti utente fino al passaggio in produzione, il Fornitore è tenuto a garantire senza oneri aggiuntivi per l’Istituto, quindi già incluse nel costo del FP, le seguenti attività:

• Assistenza Post-Rilascio: assistenza necessaria a valle del passaggio in produzione per il tuning della applicazione (per raggiungimento dei livelli di performance previsti dai requisiti) in affiancamento alle risorse dedicate alla gestione applicativa per un periodo di 8-10 settimane a valle del rilascio.

• Passaggio Conoscenza alle strutture di Gestione Applicativa: attività di predisposizione della documentazione ed affiancamento pre- e post-rilascio alle strutture di supporto agli utenti di primo (Help Desk I Livello) e secondo livello (Gestione Applicativa) siano esse risorse del fornitore, dell’Istituto o di fornitori terzi dell’Istituto.

• Attività per la Sicurezza Applicativa: attività inerenti la garanzia della Sicurezza Applicativa (sicurezza del codice) degli sviluppi e della manutenzione eseguita, ivi compresa la individuazione di rischi e contromisure nonché la pianificazione, disegno ed esecuzione di test specifici per la sicurezza.

• Attività di supporto alla pianificazione dei rilasci: partecipazione a meeting con personale INPS o di fornitori terzi per la corretta pianificazione dei rilasci di nuove applicazioni sviluppate (o nuove versioni di applicatizioni esistenti oggetto di manutenzione evolutiva).

• Attività di pianificazione e packaging di “Release” del SW: attività volte alla individuazione e raggruppamento di interventi di sviluppo o manutenzione di qualsiasi tipo in “release”/versioni del sw oggetto degli interventi.

• Attività propositive di miglioramento: partecipazione a meeting di individuazione di interventi migliorativi dei processi di gestione del ciclo di vita del sw in cui il fornitore è coinvolto.

1.14.2. Manutenzione Adeguativa (MAD)

Descrizione e requisiti del servizio

La Manutenzione Adeguativa comprende l’attività volta ad assicurare la costante aderenza delle procedure e dei programmi alla evoluzione dell’ambiente tecnologico del sistema informativo

In particolare si intendono:

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

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

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

• migrazioni di piattaforma;

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

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

Criteri di Dimensionamento e misura del servizio

Il servizio di MAD verrà dimensionato unicamente in base alle seguenti metriche:

Servizio

Modalità

Metrica

Manutenzione Adeguativa nuovi sviluppi e codice esistente

Progettuale

gg/persona

Il servizio è misurato in giorni/persona, calcolato sull’ipotesi di 7 FTE totali sui due Lotti per 20 giorni al mese per 24 mesi.

Tabella 11

MAD
Lotto	GG/PP
Lotto n.1	2.184
Lotto n.2	1.176
Totale	3.360

1.14.3. Manutenzione Correttiva (MAC)

Descrizione e requisiti del servizio

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

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

I malfunzionamenti imputabili a difetti presenti nel codice sorgente, o nelle specifiche di formato o di base dati, non rilevati a suo tempo durante il ciclo di vita o in collaudo, sono risolti dal servizio di manutenzione correttiva con la correzione del codice sorgente. Nel caso di software in garanzia da parte di un precedente Fornitore, il servizio di manutenzione correttiva consiste nell’affidare a tale Fornitore la correzione, il test, l’assistenza al collaudo e all’installazione in ambiente di esercizio.

La categoria dei malfunzionamenti è così definita:

Guasti Bloccanti:

- sono i malfunzionamenti per cui è impedito l'uso dell'applicazione o di una o più funzioni;

- sono i malfunzionamenti per cui è impedito l'uso di una funzione dell'applicazione in alcune specifiche condizioni (ad es. per alcuni dati di input);

Guasti Non bloccanti:

- sono i malfunzionamenti per cui è impedito l'uso della funzione, ma lo stesso risultato è ottenibile con altra modalità operativa" ed i malfunzionamenti di tipo marginale;

- sono le anomalie rilevate sulla documentazione, sui prodotti di fase documentali.

La classificazione suddetta potrà subire nel corso della fornitura modifiche volte a dettagliare ulteriormente le casistiche incluse in ogni tipologia di guasto. In corso di erogazione del servizio, l’ Istituto potrà richiedere la verifica e modifica della assegnazione di un dato guasto ad una data categoria ove necessario.

Per impedimento all’uso dell’applicazione o delle sue funzioni si intende una malfunzione vera e propria dell’applicazione o gli effetti che tale malfunzione ha causato alla base dati (es. anomalie in un programma batch che corrompono la base dati).

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

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

Sono parte integrante del servizio di Manutenzione Correttiva le seguenti attività:

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

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

• rimozione della difettosità residua su tutto il software per l’anno successivo all’ultimo contrattuale operando attraverso il Fornitore che subentra nel servizio

La tempestività di ripristino delle applicazioni a fronte di malfunzionamento è misurata rispetto a valori calcolati in funzione sia della classe di rischio dell’applicazione (ove difinita da INPS) che della categoria di malfunzionamento.

Criteri di Dimensionamento e misura del servizio

Il servizio di MAC verrà dimensionato unicamente in base alle seguenti metriche

Servizio

Modalità

Metrica

Manutenzione Correttiva Nuovi Sviluppi

Continuativa

canone mensile

Manutenzione Correttiva Software Esistente

Continuativa ad evento/richiesta

Giorno/persona

La manutenzione correttiva dei nuovi sviluppi viene calcolata a canone ed è attivata a valle di un periodo di garanzia del SW pari a 12 mesi, in base al numero di FP entrati in esercizio.

Il canone sarà pari al 8% del prezzo unitario del punto funzione messo a base d’asta per ciascun mese calcolato sulla base del totale dei FP che entrano in manutenzione suddiviso su 8 mesi.

Il predetto periodo di 8 mesi è calcolato ipotizzando che il primo gruppo di FP entrerà in esercizio non prima del 5° mese dall’inizio del contratto, da cui decorre il periodo di garanzia.

MAC nuovi sviluppi
Lotto	N. FP in manutenzione
Lotto n.1	31.200
Lotto n.2	16.800
Totale	48.000

Il servizio di manutenzione correttiva sul software esistente sarà remunerato a giorni/persona in quanto appartenente alla categoria di software stabile e con bassa difettosità residua. L’Istituto ritiene pertanto conveniente utilizzare questa modalità di remunerazione. L’ipotesi adottata prevede in totale sui Lotti 4 FTE per 20 giorni al mese per 24 mesi, suddivisi come segue:

MAC
Lotto	GG/PP
Lotto n.1	1.248
Lotto n.2	672
Totale	1.920

1.14.4. Gestione Applicativa (GA)

Descrizione e requisiti del servizio

I servizi di gestione applicativa sono svolti da risorse professionali del Fornitore, sotto la supervisione dei referenti INPS, e sono orientati a garantire l’adeguata funzionalità ed il corretto utilizzo delle applicazioni a regime. Tale servizio corrisponde alla classe di fornitura “Gestione Applicativi e Basi Dati” individuata dall’Agenzia per l’Italia Digitale (ex DigitPA).

Per ciò che attiene le attività di manutenzione e le attività di gestione applicativa, il fornitore dovrà operare adottando processi operativi (ispirati al modello ITIL) al fine di garantire il raggiungimento degli obiettivi di qualità sui servizi applicativi erogati dall’Istituto. Il fornitore si impegna ad operare, come da migliori pratiche di mercato, secondo tali processi operativi e rispettando i livelli operativi di servizio necessari per la corretta esecuzione dei processi stessi e la interazione con il personale INPS.

Il servizio è articolato nelle seguenti componenti:

• Help-desk di secondo livello su problemi applicativi;

• Assistenza Applicativa;

• Supporto al Governo del Patrimonio Informativo.

Per il servizio in questione si intendono, a titolo indicativo e non esaustivo, le attività elencate:

Help-desk di secondo livello su problemi applicativi:

Il componente richiesto è costituito da un Help Desk di secondo livello di supporto al funzionamento:

• delle applicazioni SIN in esercizio, attivato su segnalazioni degli utenti della INPS Gestione Dipendenti Pubblici effettuate all’ Help desk di I° livello gestito dall’Istituto (piattaforma Remedy di Trouble Ticketing);

• dei servizi on-line SIN, attivato su segnalazioni dei cittadini effettuate tramite i canali del Contact Center INPS.

Il servizio deve essere in grado di risolvere direttamente le problematiche più semplici e di attivare le strutture specialistiche appropriate nel caso di problemi non risolvibili direttamente.

Il servizio dovrà essere disponibile dal lunedì al venerdì dalle ore 8:00 alle ore 19:00 e il sabato dalle 8:00 alle 13:00.

Le richieste di assistenza assegnate al servizio di help desk di II livello fuori di detta finestra temporale saranno prese in carico il giorno lavorativo successivo.

Per la erogazione dei servizi, ed in particolare per la erogazione dei servizi continuativi di Gestione Applicativa, il fornitore dovrà prevedere l’integrazione con i sistemi in uso presso l’Istituto per la tracciatura completa delle attività di intervento.

A fronte di ogni richiesta di assistenza pervenuta al servizio, le informazioni minime che il servizio deve tracciare e che devono essere inserite nel sistema di Trouble Ticketing sono le seguenti:

• data di richiesta dell’assistenza,

• soggetto che l’ha richiesta,

• descrizione sintetica della richiesta,

• modalità di intervento prevista,

• eventuale escalation del problema effettuata,

• data chiusura della richiesta di assistenza,

• modalità di soluzione del problema,

• eventuali livelli di servizio conseguiti.

Assistenza Applicativa:

Il componente richiesto ha l’obiettivo di supportare l’Istituto nell’uso, gestione ed ottimizzazione delle funzioni applicative del SIN, assicurandone nel tempo la migliore funzionalità per l’utenza, 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.

Tra le attività si segnalano le seguenti, senza pretesa di esaustività:

• risoluzione delle richieste di intervento smistate dal servizio di Help desk di 2° livello;

• intercettazione e registrazione dei problemi alla fonte, classificazione, eventuale riproduzione dell’errore e, se necessario, conseguente attivazione del servizio di Manutenzione Correttiva e verifica dell’esito dell’intervento effettuato;

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

• supporto al ripristino base dati;

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

• verifica ed aggiornamento di eventuale documentazione di area che descrive le modalità di esecuzione di particolari attività del servizio di Gestione Applicativa (ad esempio manutenzione preventiva, etc.) in collaborazione con i gruppi di sviluppo;

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

Il servizio richiesto consiste inoltre nel dare supporto all’Istituto nelle attività da svolgere, al termine della fase di collaudo degli interventi di sviluppo e manutenzione evolutiva, propedeutiche all’avvio in esercizio del software realizzato e/o modificato. In particolare, nell’ambito del servizio saranno richieste, a titolo non esaustivo, le seguenti macro-attività:

• Avviamento in esercizio delle applicazioni software;

o pianificazione degli avviamenti in ambiente di esercizio e controllo dell’avanzamento delle attività previste;

o raccolta della documentazione di rilascio delle applicazioni per una sua corretta gestione e distribuzione;

o verifica delle risorse necessarie e disponibili, strumentali e umane, per un ottimale avviamento, e definizione delle azioni preventive necessarie per la gestione di eventuali criticità;

o presa in carico e gestione delle procedure applicative, nel rispetto dei parametri di disponibilità nei diversi ambienti operativi e delle policy di sicurezza predefinite dall’Istituto;

o verifica della coerenza della configurazione delle applicazioni trasferite rispetto agli ambienti di utilizzo;

o configurazione delle basi dati di esercizio e delle utenze applicative;

o controllo puntuale dei tempi e delle modalità con cui vengono richiesti tutti i rilasci delle procedure;

o attivazione di tutti i gruppi coinvolti in ciascun rilascio e loro coordinamento per l’esecuzione delle attività richieste;

o raccolta di segnalazioni di anomalie legate ai rilasci effettuati con conseguente analisi e risoluzione;

o gestione di criticità e urgenze di rilascio delle procedure con particolare attenzione all’ambiente di esercizio;

o verifica della corretta sequenza di rilascio nei diversi ambienti operativi;

o verifica dei rilasci nei diversi ambienti operativi;

o supporto al dimensionamento sistemi e capacity planning;

o analisi delle possibili evoluzioni degli ambienti operativi in termini di potenziamento ed adeguamento tecnologico, al fine di supportare il funzionamento degli applicativi;

o gestione dei test di performance di sistema (scenari e reportistica).

• Assistenza per l’utilizzo del software rilasciato;

o supporto all’organizzazione del lavoro in funzione del nuovo contesto organizzativo/funzionale;

o supporto per la contestualizzazione dell’iter amministrativo rispetto al sistema organizzativo nel suo complesso;

o supporto per l’individuazione delle giuste priorità nelle operazioni da svolgere;

o supporto per la rilevazione di eventuali nuove o diverse esigenze.

• Trasferimento know how a fine fornitura;

o presentazione esaustiva degli aspetti organizzativi, amministrativi e tecnici della fornitura, dei processi di riferimento, dell’architettura generale del sistema nonché delle architetture di ogni singola area applicativa e/o applicazione;

o estrazione, verifica e consegna di tutti gli oggetti software al fine di permettere la predisposizione di un ambiente operativo parallelo;

o estrazione, verifica e consegna di tutti i documenti previsti dal presente contratto;

o predisposizione di quadri di sintesi architetturali e funzionali di livello superiore al documento di sintesi;

o predisposizione di questionari e sessioni di domande/risposte per verificare il grado di apprendimento sia sugli ambienti tecnologici, sia funzionali e tecnici;

o presentazione degli aspetti di criticità di ogni servizio/area applicativa con l’esposizione chiara delle soluzioni proposte ed attuate durante la fornitura;

o presentazione delle modalità organizzative, degli obiettivi e delle risorse richieste per la predisposizione della test factory del progetto in INPS.

Si misura in giorni/persona, calcolato sull’ipotesi di 90 FTE totali sui Lotti per 20 giorni al mese per 24 mesi.

Supporto al Governo del Patrimonio informativo:

Il servizio richiesto è finalizzato a garantire, nell’ambito del SIN, un utilizzo del patrimonio informativo dell’Istituto volto al miglioramento dei livelli di certificazione ed all’assicurazione della qualità dei dati dello stesso; in particolare il servizio dovrà supportare l’Istituto nel governo delle banche dati del SIN rispetto alla piena integrazione delle sue diverse componenti.

Attualmente le banche dati da gestire in ambiente SIN sono:

• la banca dati gestionale composta da 2 istanze Oracle: Banca Dati Unificata – BDU e Banca Dati Normalizzata – BDN;

• la banca dati informativa statistica per la Business Intelligence - BDW.

Tutti gli ambienti applicativi del SIN (sviluppo, integrazione, collaudo, formazione, pre-esercizio, esercizio) si interfacciano con le Banche Dati.

Si riportano di seguito, a titolo non esaustivo, le principali attività oggetto del servizio:

• Mantenimento, ed al tempo stesso miglioramento del livello di qualità, integrità, completezza ed efficienza del modello dei dati del SIN.

• Supporto alle attività di completamento della certificazione dei contenuti della Banca Dati, da perseguire anche attraverso la cooperazione con Enti ed Amministrazioni responsabili dell’Informazione e certificatrici del dato, e la definizione dei flussi di ingresso e di uscita finalizzati all’accesso, all’aggiornamento, all’integrazione della Banca Dati stessa.

• Governo della predisposizione ed evoluzione delle strutture di banca dati nei diversi ambienti (sviluppo, collaudo, formazione, pre-esercizio, esercizio e manutenzione).

• Supporto per la valutazione degli impatti sul SIN a fronte di variazioni della banca dati.

• Supporto per la definizione delle politiche della qualità del dato.

• Supporto ai gruppi applicativi per il governo delle componenti software trasversali e della loro configurazione nei diversi ambienti (collaudo, formazione, pre-esercizio, esercizio, manutenzione).

• Supporto per la migrazione del patrimonio informativo dell'istituto su BDN (collaborazione con i gruppi applicativi per la definizione delle specifiche di migrazione e interfaccia con i gruppi tecnici).

• Supporto per la definizione e l’attuazione di politiche di bonifica dei dati esistenti.

• Supporto ai gruppi applicativi per la progettazione integrata degli schemi dati: concettuale e logico e interfaccia verso i gruppi tecnici per la progettazione dello schema fisico.

• Gestione centralizzata del contenuto informativo delle principali tabelle tipologiche in tutti gli ambienti.

• Verifica della rispondenza delle applicazioni ai criteri dell'architettura integrata (ad es. IDM, Profili/Ruoli, area riservata/scrivania virtuale).

Si misura in giorni/persona, calcolato sull’ipotesi di 10 FTE totali sui Lotti per 20 giorni al mese per 24 mesi.

Criteri di Dimensionamento e misura del servizio GA

I componenti del servizio di Gestione Applicativa sono remunerati secondo le modalità descritte nella seguente tabella:

Servizio

Modalità

Metrica

Help-desk su problemi applicativi

Continuativa

Canone

Assistenza applicativa

Continuativa

Giorni persona

Supporto al Governo del Patrimonio Informativo

Continuativa

Giorni persona

Il dimensionamento del servizio a canone è calcolato sull’ipotesi di 12 FTE totali sui Lotti per 20 giorni al mese per 24 mesi, facendo riferimento all’esperienza pregressa. La tariffa applicata è quella di operatore di help desk.

Tale dimensionamento è suddiviso nei due Lotti come segue:

GA – Help desk
Lotto	FTE equivalent
Lotto n.1	3.744
Lotto n.2	2.016
Totale	5.760

L’Impresa nell’Offerta tecnica dovrà proporre l’ organizzazione di questo servizio (quantità e qualità delle risorse utilizzate, compiti affidati, workflow di lavoro, modalità di verifica della qualità etc.). Non sono ammessi dimensionamenti inferiori al minimo richiesto.

Il dimensionamento totale dei servizi a giorni persona, calcolato su una ipotesi di 100 FTE totali per 20 giorni al mese per 24 mesi, è suddiviso nei due Lotti come segue:

GA – Assistenza e Supporto
Lotto	GG/PP
Lotto n.1	31.200
Lotto n.2	16.800

Totale

48.000

1.14.5. Supporto Specialistico Tecnico (SST)

Descrizione e requisiti del servizio

Per il corretto svolgimento delle attività sopra esposte e come servizio aggiuntivo a quelli di sviluppo, la presente fornitura prevede il ricorso a servizi professionali specialistici, al fine di:

• definire le esigenze connesse ad interventi di manutenzione informatici, ed in particolare di:

o analisi delle esigenze relative ai processi operativi e di controllo, ai cambiamenti normativi, ai requisiti contabili e finanziari ed ad altri elementi amministrativi ed operativi che richiedano la realizzazione o il cambiamento dei sistemi informatici;

o analisi degli obiettivi, dei rischi e degli impatti organizzativi, contabili, ecc.. degli interventi informatici richeiesti dalle Direzioni amministrative;

• definire e pianificare le esigenze di interventi informatici per specifiche aree o per singole Direzioni dell’Istituto, ivi compresa l’analisi delle dipendenze tra progetti diversi;

• fornire supporto al servizio di Gestione Applicativa per le problematiche di alto livello;

• fornire supporto specialistico all’uso dei prodotti software;

• trasferire know-how funzionale e tecnico all’Istituto oggetto della fornitura anche attraverso attività di supporto alla formazione;

• supportare l’analisi degli aspetti organizzativi relativi alla semplificazione e al miglioramento dell’interazione con l’esterno dell’Istituto (Enti, Amministrazioni);

• supportare l’integrazione dei processi organizzativi attraverso l’utilizzo delle applicazioni;

• fornire supporto specialistico alla predisposizione di relazioni tecniche per studi di fattibilità etc;

• partecipare a gruppi di lavoro costituiti dall’amministrazione per supportare gli utenti delle applicazioni per la rilevazione analisi dei dati;

• fornire supporto all’integrazione tra i processi/progetti del SIN, attraverso la verifica delle aree di intersezione tra le diverse componenti verticali;

• fornire supporto alla verifica dell’ambito delle singole componenti verticali del SIN, sviluppate e in corso di sviluppo, delle modalità di utilizzo dei componenti trasversali;

• fornire supporto alla completezza e uniformità dei processi legati alle prestazioni.

Sarà inoltre richiesto:

• supporto tematico a redazione di studi, analisi di fattibilità, stima dei tempi e costi, stima dei

benefici, comparazione tra diverse possibili soluzioni, valutazione di soluzioni che prevedano l’utilizzo e l’eventuale personalizzazione di prodotti software presenti sul mercato;

• analisi dei processi;

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

Dimensionamento del servizio

La metrica impiegata per il Supporto Specialistico Tecnico è quella in giorni/persona.

Servizio

Modalità

Metrica

Supporto Specialistico Tecnico

A progetto

Giorni persona

Il servizio sarà valutato in giorni/persona calcolato sull’ipotesi di 50 FTE totali sui Lotti per 20 giorni per 24 mesi, suddivisi come segue:

Tabella 16

SST
Linea	GG/PP
Lotto n.1	15.600
Lotto n.2	8.400
Totale	24.000

1.14.6. Referenti

Il Fornitore dovrà indicare, il Responsabile unico delle attività contrattuali, cui l’Istituto farà riferimento per gli aspetti generali e per ogni problema riguardante la fornitura stessa.

Tale risorsa sarà individuata dal Fornitore in sede di offerta e non comporterà alcun onere aggiuntivo per INPS.

Il Responsabile unico delle attività contrattuali coadiuvato dai referenti di area (descritti di seguito) dovrà riferire a INPS sulle tematiche contrattuali, quali ad esempio:

• predisposizioni e variazioni del Piano globale della fornitura;

• predisposizione e garanzia del rispetto del Piano della Qualità tenendo conto delle specificità dei servizi richiesti;

• livelli di servizio sulle attività oggetto della fornitura ed eventuali azioni correttive a fronte del mancato rispetto delle soglie previste e/o a fronte di rilievi;

• risultati sui livelli di servizio;

• problematiche relative a problematiche relative ad eventuale mancata aderenza delle risorse impiegate rispetto ai profili professionali richiesti.

Il Fornitore dovrà, inoltre, indicare un referente per ciascuna area applicativa (Anagrafica, Entrate, etc…)

Si precisa che una stessa persona non potrà ricoprire il ruolo di referente di area per più aree applicative; quindi questo ruolo dovrà essere svolto sulle diverse aree applicative da risorse differenti.

Il Referente di area svolgerà le seguenti attività:

• Servizio di Sviluppo, MEV e Manutenzione Adeguativa. Il referente avrà il compito di:

o interfacciare i capo progetto INPS nella fase di recepimento dei requisiti utente, ed in tutte le fasi della progettazione e realizzazione per la revisione dei requisiti;

o collaborare con i capo progetto INPS nella individuazione delle più idonee soluzioni realizzative;

o collaborare con le strutture tecniche INPS nella ricerca delle migliori soluzioni tecnico/architetturali per i prodotti in via di realizzazione e/o progettazione;

o garantire la piena compatibilità ed integrazione dei prodotti in fase di sviluppo con le architetture tecniche disponibili per l’area, segnalando per tempo eventuali problemi e/o criticità al capo progetto INPS incaricato;

o assicurare la correttezza, accuratezza ed affidabilità del calcolo dei Punti Funzioni in linea con quanto disciplinato dal presente capitolato e con riferimento alle regole di conteggio.

• Servizio di Manutenzione correttiva. Il referente avrà il compito di:

o interfacciare il responsabile INPS per l’ottimale svolgimento delle attività di correttiva dell’area;

o assicurare la massima collaborazione nella prima fase di analisi delle anomalie segnalate;

o garantire il rispetto dei livelli di servizio offerti;

o garantire, nei casi eccezionali di criticità ed urgenza, le necessarie sinergie e la soluzione tempestiva delle malfunzioni aperte in reperibilità;

o garantire l’ottimale e costante dimensionamento, in quantità e qualità, del team di correttiva.

• Servizio di Gestione Applicativa. Il referente avrà il compito di:

o garantire proattivamente l’ottimale e costante dimensionamento, in quantità e qualità, del team di Gestione Applicativa rispettando le indicazioni del responsabile

INPS. Ciò comporta la gestione delle fisiologiche temporanee sostituzioni delle risorse (es. esempio ferie, malattie, indisponibilità in genere) al fine di garantire la regolare disponibilità del servizio ordinario;

o stabilire un costante colloquio con il responsabile INPS al fine di prevedere i periodi di picco o di particolare criticità e predisporre Piani di potenziamento delle risorse in Gestione Applicativa e risorse per estensione dell’orario di servizio;

o predisporre, aggiornare e garantire l’attuazione del Piano di Gestione Applicativa, ponendo particolare attenzione all’organizzazione ed al funzionamento della reperibilità delle risorse in tutti i suoi aspetti documentali, strumentali (pc portatile, connessioni remote …) , procedurali ed organizzativi;

o recepire le richieste di estensione dell’orario di servizio ed organizzare entro 1 ora (tempo minimo di preavviso) il team dell’orario esteso con le modalità espresse nel paragrafo “orario di servizio”;

o mantenere un costante colloquio con il team dell’orario esteso o con la risorsa in reperibilità, nonché con il responsabile INPS, al fine di garantire l’efficacia e l’efficienza del servizio, il supporto all’Amministrazione e la risoluzione nel più breve tempo possibile delle problematiche e delle criticità. Ciò comporterà, sentito il responsabile INPS, l’eventuale sostituzione di risorse e/o integrazione al fine di garantire le competenze specifiche richieste.

o Operare come referente unico tra il fornitore ed i centri di competenza dedicati alla attività di gestione delle infrastrutture. Le attività di interfaccia dovranno riguardare in particolare il presidio dei principali processi operativi di erogazione del servizio (quali a titolo indicativo: incident management, problem management, release management, etc..).

Si sottolinea che, a prescindere dall’organizzazione che il Fornitore adotterà per l’erogazione dei servizi, è richiesto un alto grado di sinergia tra le risorse impiegate nel servizio di Sviluppo e MEV, nel servizio di manutenzione correttiva e quelle impiegate nella gestione delle attività di avviamento in esercizio dell’applicazione, al fine di garantire un costante e adeguato grado di conoscenza e di attenzione, evitando discontinuità. E’ responsabilità del referente di area assicurare la sinergia suddetta.

1.14.7. Inquadramento servizi nel ciclo di vita del sw

La fornitura comprende, nella realizzazione del sw per nuove realizzazioni e manutenzione evolutiva ed adeguativa, l’esecuzione di tutta la serie delle attività connesse al “ciclo di vita del software applicativo”, che possono essere definite come segue:

• Progettazione, articolata nelle distinte attività di analisi dei requisiti, realizzazione di eventuale “prototipo”(il cui utilizzo è previsto, per esempio, nei casi di procedure software

particolarmente complesse o di rilevante criticità), redazione delle specifiche di progetto, del disegno esterno, del modello dati e del disegno interno delle procedure;

• Realizzazione, comprensiva di codifica, documentazione per il Personale Tecnico ed Amministrativo/Operativo, prove funzionali, prove d’integrazione e prove di sistema;

• Supporto al collaudo, in termini di predisposizione dei casi di prova, predisposizione dell’ambiente di collaudo e analisi delle anomalie riscontrate;

• Messa in produzione, in termini di individuazione delle modalità di predisposizione dell’ambiente operativo di produzione sia per il sistema centrale che per i sistemi periferici, delle procedure di installazione e dei meccanismi di distribuzione per il primo impianto e i successivi aggiornamenti. Tale attività si svolgerà in affiancamento al Personale Tecnico dell’Istituto, ovvero mediante redazione di apposita documentazione, realizzazione di procedure automatiche e supporto remoto durante le operazioni di installazione;

• Manutenzione evolutiva ed adeguativa per tutto il periodo di validità del contratto sia delle applicazioni nuove sviluppate dal Fornitore, sia di quelle preesistenti già in esercizio;

• Supporto alla formazione del Personale dell’Istituto all’uso delle nuove applicazioni che verrà fornito mediante la preparazione e lo svolgimento di corsi sull’uso dell’applicazione. L’addestramento si svolgerà presso la Direzione Generale, e se necessario presso le Sedi Regionali, e sarà finalizzato a rendere i partecipanti non solo autonomi nell’uso dell’applicazione ma anche in grado di fornire un supporto di primo livello ai colleghi che non avranno partecipato ai corsi;

• Assistenza agli utenti, svolta da un gruppo centralizzato di esperti che danno supporto remoto agli Utenti Esterni ed Interni sull’uso dell’applicazione;

• Garanzia sulle malfunzioni per i 12 mesi successivi all’effettivo rilascio in esercizio; tale garanzia è da intendersi anche per le applicazioni realizzate nel corso dell’ultimo anno di durata contrattuale, con interventi di:

o analisi di inconvenienti e malfunzionamenti segnalati dall'Istituto;

o assistenza di tipologia riconducibile alla Problem Determination ed al Problem Solving delle applicazioni;

o assistenza all’installazione di correzioni, etc..

L’Istituto valuterà positivamente la realizzazione di software riusabile, avente canoni di modularità, modificabilità, conformità, adattabilità, coesistenza e agevole apprendibilità.

1.14.8. Profili professionali richiesti

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

I curricula vitae del personale da impiegare nei vari servizi dovranno essere resi disponibili a INPS secondo quanto previsto dal contratto.

L’Istituto valuterà positivamente ogni riferimento a competenze su attività o metodologie basate sull’adozione di prodotti e/o a componenti di essi che sono in uso nell’ambito dei sistemi informativi gestiti da INPS. Competenze su altri prodotti o su componenti di essi non in uso saranno valutati in minor misura e comunque solo se associate alle competenze proprie dell’Istituto.

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

Si precisa, inoltre, che nei profili professionali di Analista Funzionale, Analista Programmatore, Programmatore/Programmatore web, Specialista di Prodotto/Tecnologia, Amministratore Basi Dati, Esperto Basi Dati, Sistemista e Operatore Help Desk Applicativo vengono riassunte le attuali necessarie conoscenze sui diversi ambienti applicativi e tecnologici in uso e per i diversi servizi oggetto del presente capitolato. E’ evidente che tali conoscenze devono essere presenti nel complesso delle risorse professionali richieste al Fornitore sulle diverse attività e/o servizi e non in una unica persona.

L’elenco dettagliato dei profili professionali richiesti è riportato nell’ Allegato 2 – Profili Professionali, di seguito si riporta una sintesi con il mix professionale richiesto:

Figure professionali	Mix proposto
Responsabile Coordinamento (Program Manager)	1%
Capo Progetto (Project Manager)	3%
Analista Funzionale	23%
Analista Programmatore	15%
Programmatore/Programmatore web /operatore help desk	15%
Specialista di prodotto/tecnologia	4%
Consulente Senior	30%
Istruttore	3%
Amministratore Basi Dati	2%
Esperto Basi Dati	1%
Sistemista	3%

1.15. Modalità di erogazione

1.15.1. Premessa

INPS si riserva di modificare le modalità di esecuzione descritte, di introdurre nuove modalità, di definire/modificare gli attuali standard, anche in corso d’opera, dandone congruo preavviso al Fornitore. In aggiunta, tali modalità di esecuzione potranno essere congiuntamente riviste, su proposta del Fornitore, e potranno essere concordate opportune semplificazioni o variazioni in funzione delle specificità dei singoli Interventi.

INPS si riserva di chiedere al Fornitore di utilizzare prodotti o modulistica specifica, messi a disposizione da INPS stessa, di supporto alla gestione dei servizi oggetto della fornitura (ad esempio: registrazione errori, log interventi, richiesta attività, ecc.). Segue una descrizione più dettagliata delle modalità previste per l’esecuzione dei servizi.

Si sottolinea che al Fornitore è richiesto in tutte le attività il rispetto degli standard e delle linee guida adottate da INPS; il Fornitore deve farsi carico di conoscere e diffondere al proprio interno tali conoscenze, di applicarle proattivamente, e di recepirne tempestivamente eventuali variazioni.

Al Fornitore è richiesta l’osservanza dei processi e l’utilizzo degli strumenti da INPS predisposti per l’interfacciamento con le strutture tecniche; in particolare si sottolinea l’introduzione dei processi ITIL nelle modalità operative dei CED, per la gestione dei problemi e delle richieste di cambiamento.

1.15.2. Fasi e modalità di erogazione

Le fasi e le modalità di erogazione della fornitura sono le seguenti:

• l’Istituto individuerà gli sviluppi da realizzare secondo un piano di priorità, e saranno affidate ai responsabili di progetto già individuati nell’ambito della Direzione Sistemi Informativi dell’Inps Gestione Dipendenti Pubblici.

• per gli sviluppi da realizzare, il Fornitore valuterà e comunicherà all’Istituto:

o le misure prestazionali attese (tempi di risposta per transazione, tempo di esecuzione per singola operazione, ecc…);

o le risorse elaborative che essa impegnerà in esercizio (CPU, spazio dischi, infrastrutture di rete, ecc…), in accordo con gli Uffici preposti alla gestione delle infrastrutture, assumendosi la responsabilità degli eventuali successivi “scostamenti” da tali stime, che saranno considerati come malfunzionamenti;

• l’Istituto ed il Fornitore, stimeranno congiuntamente la quantità di Punti Funzione necessari che sarà formalizzata all’interno della scheda attività di prodotto (vedi allegato);

• Per ciascun software applicativo da realizzare saranno stimati i termini di “consegna-di- prodotto” e di “avvio-in-esercizio”;

• secondo il piano di progetto, verranno eseguite le operazioni previste (disegno progettuale, analisi, con realizzazione di un eventuale “prototipo”, codifica, collaudo, …) per ciascuna delle quali il responsabile di progetto dell’Istituto rilascerà il proprio benestare;

• il rappresentante del Fornitore ed il rappresentante dell’Istituto procederanno alle operazioni di controllo della qualità e di verifica della quantità del prodotto; il prodotto non conforme alle caratteristiche ed ai criteri qualitativi stabiliti e previsti non sarà accettato e sarà ritenuto non ancora consegnato;

• il Fornitore consegnerà il software sviluppato, nonché la corrispondente documentazione, la documentazione operativa, i manuali d’uso, etc., evento, che costituisce il termine dell’attività produttiva (consuntivo-prodotto). In particolare, tale documentazione dovrà essere in linea con la tipologia di documentazione valutata tra i criteri di aggiudicazione e comunque con le indicazioni fornite dall’Istituto;

• si provvederà alla messa in produzione, nel rispetto dei tempi programmati;

• dopo la messa in produzione, il Fornitore garantirà, durante l’avvio in esercizio, l’assistenza agli utenti secondo le modalità concordate.

A partire dalla fase di sviluppo il fornitore dovrà garantire la gestione della configurazione.

Negli ultimi quattro mesi di validità del contratto potrà essere richiesto al fornitore di fornire al personale dell’Istituto, o a terzi dallo stesso indicati, il trasferimento del know-how sulle attività condotte.

Per “Valore dell’applicazione” si intende il totale dei Punti Funzione necessari per lo sviluppo già comprensivi delle attività incluse nel valore del Punto Funzione.

Dal punto di vista della determinazione dei corrispettivi finali hanno rilevanza i conteggi di consuntivo certificati e approvati da INPS.

In relazione alle modalità di erogazione descritte per le attività di sviluppo il pagamento potrà essere così ripartito:

• alla fine della fase di analisi dei requisiti il 20% del valore complessivo dei punti funzione risultanti dal Documento di Analisi e Progettazione approvato dal Responsabile del Progetto dell’Istituto;

• alla data di collaudo del prodotto il 60% del valore complessivo dei punti funzione così come risultanti dal Verbale di Collaudo di cui all’allegato approvato dal Responsabile del Progetto dell’Istituto;

• alla data di messa in esercizio il 20% del valore complessivo dei punti funzione così come risultanti dalla lettera per la consegna di prodotto/servizio di cui all’allegato approvato dal Responsabile del Progetto dell’Istituto.

1.15.3. Piano di Progetto

Il Piano di Progetto, relativo a ciascuna applicazione da realizzare, è lo strumento di riferimento per l’esecuzione ed il controllo della fornitura.

L’Istituto parteciperà alla definizione delle specifiche funzionali e dei requisiti utente con le proprie strutture amministrative (esperti di processo) ed informatiche (capi-progetto, analisti, …); detta fase congiunta sarà inclusa nel Piano di Progetto; ove, in tale fase, si verifichino slittamenti temporali per cause imputabili all’INPS, tali periodi, opportunamente documentati, saranno considerati in sede di verifica del rispetto dei termini di esecuzione della fornitura.

Nel caso si verifichino lungo tutto il ciclo del progetto, per cause oggettivamente rilevanti, scostamenti dal piano di progetto inizialmente definito, sia per quanto attiene al valore dell’applicazione sia alla tempistica di realizzazione, si potrà procedere ad una sola ri-pianificazione purché autorizzata da INPS.

L’approvazione del Piano comporta l’approvazione delle stime/previsioni di impegno e sui tempi previsti per tutte le attività.

Tale Piano sarà predisposto dal Fornitore.

Il Piano di Progetto è costituito dal dettaglio delle attività e relativa tempificazione (diagramma di Gantt) e da una serie di documenti che conterranno le seguenti informazioni:

A preventivo:

• Elenco delle attività e relative date di inizio e fine;

• Applicazioni che verranno rilasciate e date previste di consegna;

• Architetture e prodotti che saranno utilizzati;

• Stima del volume in PF, suddivisa per elementi aggiunti, variati, eliminati;

• Data inizio lavori;

• Termine di consegna;

• Eventuali rischi e piano di azione di recupero;

• Attività di assistenza da svolgere;

• Razionali di ripianificazione eventuale sulle date, sull’impegno, sul volume.

A consuntivo:

• Descrizione dell’obiettivo;

• Attività concluse e loro date;

• Prodotti rilasciati e loro date di consegna;

• Misura del volume in PF, suddivisa per elementi aggiunti, variati, eliminati;

• Risultanze delle attività di verifica, validazione e collaudo;

• Eventuali imprevisti ed azioni di recupero effettuate;

• Attività di assistenza svolte;

• Razionali di scostamento eventuale sulle date, sull’impegno, sul volume;

• Documenti di autorizzazione, approvazione, accettazione e consegna.

1.15.4. Cicli di Sviluppo

Con riferimento al ciclo di sviluppo del software, le attività sono suddivise in fasi come riportato al precedente paragrafo “ciclo di vita del software applicativo”. Nella seguente tabella, per ciascuna fase, vengono associati i prodotti di fornitura ed il criterio di uscita di fase.

Fase	Prodotto di fase			Criterio di uscita	Descrizione criterio
Pianificazione	Piano di Progetto			Approvazione	Processo formale di verifica e validazione
Pianificazione	Piano di Qualità			Approvazione	Processo formale di verifica e validazione
Analisi	Specifiche comprensive Utente	dei	funzionali Requisiti	Approvazione	Processo formale di verifica e validazione
Analisi	Prototipo (nei casi in cui sarà previsto)			Approvazione	Processo formale di verifica e validazione
Disegno	Disegno di dettaglio comprensivo di Modello dei Dati e del Piano di Test e Collaudo			Approvazione	Processo formale di verifica e validazione
Realizzazione	Codice sorgente			Consegna	Processo formale di rilascio prodotti realizzati	ad INPS	dei
	Codice di test e collaudo			Consegna	Processo formale di rilascio prodotti realizzati	ad INPS	dei
	Documentazione utente e gestionale (operativa)			Consegna	Processo formale di rilascio prodotti realizzati	all’INPS	dei
Collaudo	Applicazione			Accettazione	Esito positivo della verifica delle attività
Avviamento Esercizio	in	Supporto alla formazione		Accettazione	Erogazione delle attività

	Messa in produzione	Accettazione	Esito positivo della verifica delle attività
	Assistenza agli utenti	Accettazione	Erogazione delle attività
Collaudo	Avvio in esercizio	Accettazione	Esito positivo della verifica delle attività

All’interno di ogni fase, per tutto il ciclo, sono comprese (parte integrante della fornitura) le attività di:

• pianificazione, conduzione e rendicontazione;

• verifica e validazione, svolte dal Fornitore in accordo al Piano di Qualità;

• supporto sistemistico quale ottimizzazioni e tuning delle prestazioni, predisposizione ambiente di test, banche dati di prova, etc..

Nel corso della fornitura l’Istituto si riserva, a sua completa discrezione, la possibilità di attivare cicli di sviluppo semplificati in funzione della ridotta complessità o del carattere di urgenza dell’intervento.

1.15.5. Attività di Affiancamento

1. Il Fornitore si impegna a svolgere un periodo di affiancamento, senza oneri aggiuntivi per l’Istituto; nei sei mesi precedenti la scadenza contrattuale, il Direttore dell’Esecuzione indicherà la durata del periodo di affiancamento, atto a garantire il passaggio di conoscenze con il Fornitore entrante, nel caso di subentro nella gestione di applicazioni non gestite in precedenza, , al fine di acquisire tutte le informazioni necessarie a svolgere correttamente i servizi richiesti ed a garantire la continuità del servizio nel passaggio tra fornitori.

2. Al termine di tale periodo, l’Appaltatore e il fornitore uscente dovranno redigere un verbale attestante il corretto passaggio di consegne e la completezza di tutta la documentazione oggetto di trasferimento. Pertanto nella propria offerta il Fornitore dovrà descrivere nel dettaglio le attività previste per il passaggio di conoscenze e l’affiancamento in entrambi i casi.

2.1.1. Regole per la manutenzione, Gestione Applicativa sul parco applicativo esistente

Il Fornitore prenderà in carico le applicazioni esistenti ai fini della erogazione dei servizi di Gestione Applicativa e Manutenzione Correttiva.

Il Fornitore si impegna senza costi aggiuntivi a mettere a disposizione dell’Istituto le risorse che ritenesse necessarie per il passaggio di conoscenza riguardo all’ambito applicativo preso in carico.

2.1.2. Misure

Calcolo Punti Funzione

La misurazione delle attività per lo sviluppo del software applicativo sarà attuata, come già rappresentato, mediante il conteggio dei Punti Funzione di ogni applicazione da realizzare o da manutenere.

Il conteggio sarà effettuato secondo le modalità di cui al Manuale delle Regole di Conteggio dei Function Point approvato da IFPUG (International Function Point User Group), versione 4.2 o seguente o in alternativa in uno dei metodi standard ISO/EIC 14143. Per la stima iniziale sarà utilizzato il metodo Early Funzion Point 4.2. Al termine del collaudo con esito positivo potrà essere fatta la consuntivazione dell’intervento, contestualmente al conteggio dei Punti Funzione.

Non verrà applicato nessun coefficiente correttivo (VAF) e le stime e le misure saranno espresse in Unadjusted Function Point (UFP).

Il FP comprende, per definizione (in quanto misura delle funzioni finite, consegnate e collaudate), tutte le attività che di norma fanno parte dei processi produttivi del software, incluse quelle necessarie al recepimento ed applicazione degli standard d’Istituto in quanto a prototipazione, alimentazione dei repository di documentazione, produzione e test, nonché, ovviamente, tutte le attività riguardanti la Qualità.

Non sarà consentita in nessun caso il calcolo della dimensione in Punti Funzione degli sviluppi effettuato a partire dal corrispettivo economico ritenuto remunerativo e dal prezzo unitario concordato a contratto, indipendentemente dalla quantità funzionale di prodotto effettivamente rilasciata.

A richiesta dell’Istituto, il dimensionamento degli interventi di sviluppo sarà effettuato in Giorni Persona (Punti funzione Equivalenti – FPE), ma sempre a corpo, previo calcolo a priori del corrispettivo sulla base della stima delle figure professionali da impiegare.

Il valore economico del punto funzione sarà esattamente determinato, sulla base dell’offerta dell’aggiudicatario, e sarà posto a base di tutte le formule di valorizzazione delle attività, dei compensi e delle eventuali penali.

Stime e misure

Per il governo ed il controllo della fornitura verranno pianificate una serie di attività di stima e misura da porre in relazione alle diverse fasi del ciclo di sviluppo del software. Si specifica che i termini “misura” e “stima” indicano distinte modalità di stabilire la dimensione funzionale del software.

Attività

Quando

Finalità

Utilizzo contrattuale

Stima iniziale

Avvio progetto

Predisposizione del piano di progetto, valutazione da parte dell’Amministrazione sull’opportunità di autorizzare l’avvio effettivo del

progetto

Il fornitore è vincolato a fornire la stima con le evidenze che hanno condotto al risultato

Stime o misure intermedie

Al termine della fase di analisi o progettazione o fase analoga, in corso d’opera

Determinazione con un buon margine di precisione del valore finale della fornitura

Nel caso in cui la misura intermedia superi la stima autorizzata all’avvio del progetto l’Amministrazione deve autorizzare la quota aggiuntiva (fase di ripianificazione come da

par. 6.3.3)

Stime o misure intermedie dei

cambiamenti di requisiti in corso

d’opera

In corso d’opera

Determinazione dell’entità del cambiamento dei requisiti in corso d’opera

Fase di ripianificazione come da par. 6.3.3

Misura finale

Al termine della fase di realizzazione dopo il collaudo della

fornitura

Determinazione dell’ammontare finale di FP per il prodotto finale della fornitura

Nel caso in cui la misura finale superi quanto in precedenza autorizzato l’Amministrazione deve autorizzare la quota aggiuntiva

La letteratura indica diversi metodi per stimare il dimensionamento in FP, alcuni di questi, comunque accettati, sono indicati al cap. 9 del manuale dell’Agenzia per l’Italia Digitale (ex DigitPA), “Strategie di acquisizione delle forniture ICT”.

In nessun caso una stima iniziale più alta della misura finale costituirà budget di spesa di riferimento per l’attività, se non espressamente verificata ed autorizzata.

Qualifica per le attività metriche contrattuali

Le attività di misura funzionale richiedono competenze e attitudini specialistiche. Al fine di garantire in misura maggiore la qualità delle prestazioni e la riduzione dei possibili contenziosi, il Fornitore deve utilizzare figure specialistiche certificate, come i Certified Function Point Specialist (CFPS) IFPUG o ISO equivalenti, che assumano la responsabilità delle misure stesse.

Durante l’esecuzione del contratto, il numero di Function Point, per l’attività di prodotto e di avvio in esercizio, verrà valutato, per ciascuna area applicativa, dapprima, in fase di stima, ed, in seguito, a valle del consolidamento del valore dell’applicazione. I calcoli saranno effettuati dai Rappresentanti dell’Istituto e del Fornitore sempre secondo quanto previsto dalla metrica sopraindicata, in base alle caratteristiche generali dell’applicazione.

Tali caratteristiche sono desumibili in via preliminare ed al solo scopo della stima iniziale dalla descrizione delle singole aree sopra riportata.

2.1.3. Termini di esecuzione

Per ciascun software applicativo da realizzare saranno stimati, di concerto fra l’Istituto ed il Fornitore, i termini di “consegna-di-prodotto” e di “avvio-in-esercizio”, che consentiranno di effettuare uno stretto controllo del raggiungimento degli obiettivi specifici, in relazione alle esigenze dell'Istituto.

I termini di scadenza saranno individuati di concerto fra l’Istituto ed il Fornitore. Elementi di individuazione delle scadenze sono :

• La formula di calcolo numero dei Punti Funzione “elevato a 0,4” utilizzata in materia di “ricerche

sulla produttività software”, il cui risultato indica i mesi necessari per la realizzazione;

• La produttività media mensile stimata per addetto, pari a 30 Punti Funzione.

Nel caso di scostamento oggettivo, per entrambe le attività, tra i Punti Funzione preventivati e quelli consuntivati, si procederà al ricalcolo dei relativi termini, che verranno proporzionalmente adeguati.

Il Fornitore, cui è stata richiesta una realizzazione progettuale con un termine di esecuzione fissato delle relative attività, deve poter disporre di tutti gli elementi necessari, di pertinenza dell’Istituto, per l’esecuzione della medesima.

Pertanto, in vista della decisione di realizzare una nuova applicazione, sarà cura dell’Istituto provvedere alla raccolta ed alla definizione degli elementi di studio progettuali che sono necessari al Fornitore per poter intraprendere le attività di sua competenza, decorrenti dalla segnalazione dell’Istituto effettuata per iscritto tramite l’inoltro di e-mail o di fax.

2.1.4. Strumenti a supporto della erogazione: raccolta requisiti, testing, change management

Le principali componenti necessarie per la realizzazione dei progetti e manutenzione del software, in linea con le soluzioni progettuali individuate dall’Istituto sono:

Raccolta dei requisiti di progetto

Il Fornitore dovrà raccogliere i requisiti di progetto secondo la tipizzazione normalmente disposta dall’ingegneria del software e concordata con i referenti dell’Istituto con strumenti integrabili con le piattaforme INPS.

In linea generale i requisiti dovranno essere dettagliati rispettando le seguenti tipologie minime:

• requisiti amministrativi o di business;

• requisiti utente;

• requisiti funzionali;

• requisiti procedurali;

• requisiti architetturali e/o tecnologici;

• requisiti di test.

La completezza dei requisiti raccolti costituisce punto di riferimento per il processo di sviluppo del software. Pertanto, la verifica ed accettazione formale dei requisiti da parte dei referenti dell’Istituto potrà avvenire anche in forma documentale purché sia il risultato dell’esportazione dal repository centralizzato gestito dall’Istituto.

In altri termini, non potrà considerarsi completa la raccolta di requisiti che non abbia alimentato il sistema gestito da INPS.

La mancanza di ambiguità dei requisiti dovrà essere assicurata dall’opportuna alimentazione dei dizionari usati, eventualmente personalizzati in collaborazione con il personale dell’Istituto.

Raccolta dei casi di test, documentazione ed automazione dei test funzionali e prestazionali

Il Fornitore dovrà concordare, al pari dei requisiti del progetto, i casi di test funzionali e prestazionali

delle applicazioni che realizzerà con i referenti dell’Istituto.

Lo scopo dei test funzionali è quello di realizzare automaticamente le verifiche minime che mostrino la funzionalità applicativa sia nella fase di collaudo delle applicazioni realizzate sia in ogni occasione l’Istituto ritenga necessario procedere ad una verifica di non regressione delle applicazioni stesse.

Lo scopo dei test prestazionali è quello di verificare la resistenza al carico, lo stress, la stabilità dei sistemi sui quali insistono le applicazioni realizzate e la loro integrazione.

In ottica di economicità, nonchè di una sua corretta valorizzazione, sarà utile realizzare anche test di qualità che pervengano alla misurazione di designati parametri peculiari del codice sorgente del software, quali quelli suggeriti dalla normativa ISO/IEC 9126, ovvero il numero di righe di commento inserite nel codice, il minimo numero di classi utilizzate, il minimo numero di metodi utilizzati da ciascuna classe, il numero medio di chiamate esterne effettuate dalle varie classi.

Ogni test di prestazioni dovrà prevedere almeno l’esistenza contemporanea di 150 utenti attivi e dovrà essere impostato secondo i parametri di sollecitazione (tempo di riflessione dell’utente virtuale, ciclicità delle transazioni) concordati con i referenti dell’Istituto e comunque non inferiori al carico atteso delle applicazioni. Ad ogni buon conto, per le verifiche prestazionali, dovrà essere sempre prodotto un test a rottura che fornisca elementi di valutazione inerenti il carico di lavoro gestibile dal sistema informativo dell’Istituto.

Pertanto, è fondamentale che il fornitore proceda alla documentazione dei casi di test funzionale e prestazionale secondo gli schemi già predisposti dall’Istituto.

La documentazione dei casi di test, concordata, verificata ed accettata dai referenti dell’Istituto potrà avvenire anche in forma documentale purché sia il risultato dell’esportazione dal repository centralizzato gestito dall’Istituto.

Il fornitore provvederà, una volta realizzata l’applicazione, a:

• raccogliere i dati necessari all’esecuzione dei test e renderli disponibili;

• a registrare gli script di test derivanti dai casi di test concordati, negli appositi strumenti di test automatico in dotazione all’Istituto;

• a predisporre e documentare le basi di dati e quanto altro sia necessario alla ripetizione del test;

• ad alimentare il repository centralizzato dei test dell’Istituto;

• ad eseguirli, in collaborazione ed alla presenza dei referenti applicativi dell’Istituto, nell’ambiente di collaudo dell’Istituto e produrne i relativi report.

Gli strumenti utilizzati per i test dovranno consentire di effettuare almeno:

a) test prestazionali;

b) test funzionali;

c) prevedere un repository dei test e relativa reportistica;

d) la registrazione dei test funzionali.

Metodologia di Change Management

Il controllo del versioning del software realizzato dovranno svolgersi presso l’Istituto. Il fornitore dovrà prevedere l’integrazione con i sistemi in uso presso l’Istituto per la gestione del deposito centralizzato degli oggetti software.

Esso include le seguenti funzioni:

• controllo delle versioni;

• tracciatura delle attività del progetto (commenti, log, history….);

• possibilità di estrazione ed archiviazione dati.

Il controllo degli accessi consente di regolare le operazioni di modifica dei file e di assicurarsi che gli autori non introducano modifiche incoerenti cercando di aggiornare contemporaneamente lo stesso file.

Gli sviluppatori non devono modificare direttamente il codice sorgente contenuto all’interno del repository, ma ognuno di loro lavorerà su una copia locale dei file. Una volta effettuate le modifiche necessarie (di solito ci si assicura che il codice venga compilato correttamente), il codice modificato viene inviato al sistema che si preoccupa di memorizzare solo le differenze dalla versione precedente a quella del repository e quindi di aggiornare la versione corrente del progetto.

Fase di censimento e caricamento di un applicazione

Censimento: gli applicativi producono la documentazione necessaria per la definizione dell’applicazione nell’infrastruttura: informazione sulla piattaforma applicativa, il numero degli oggetti, la tipologia degli oggetti, i referenti applicativi,le utenze da abilitare fin dalla fase di richiesta configurazione in ambiente di sviluppo.

Caricamento: gli oggetti che compongono l’applicazione dovranno essere forniti dagli applicativi nelle librerie di censimento, definite nell’infrastruttura di riferimento.

Ciclo di vita del software nell’infrastruttura di Change Management Applicativo

1. Gli oggetti da manutenere vengono prelevati da una sorgente origine (Baseline) e portati nell’area di sviluppo applicativo dove vengono modificati.

2. A seguito delle modifiche devono essere eseguiti negli specifici ambienti:

• il test unitario (in ambiente locale);

• il test integrato ;

• il collaudo.

3. A seguito dell’esito positivo del collaudo viene eseguito il passaggio in produzione che consiste

nell’aggiornamento dell’ambiente di Produzione con le nuove modifiche e nell’aggiornamento della libreria dei sorgenti (Baseline) con la nuova versione.

2.1.5. Soluzioni per il controllo della fornitura

Il fornitore dovrà prevedere l’integrazione con i sistemi in uso presso l’Istituto per il controllo della fornitura che offra almeno queste funzioni:

• L’archiviazione, distribuzione, consultazione e modifica dei consuntivi periodici prodotti dall’Impresa in esecuzione del contratto;

• L’archiviazione, distribuzione, consultazione e modifica di tutta la documentazione dei singoli progetti in esecuzione del contratto;

• L’archiviazione, distribuzione, consultazione e modifica degli ulteriori documenti prodotti dalle parti in esecuzione del contratto;

• La consultazione di riepiloghi dell’utilizzo delle risorse contrattuali, per tipologia, per l’intero contratto, per servizio e per area di competenza; i dati devono essere pubblicati sul portale sia con riferimento al periodo “mese”, sia con riferimento all’intero periodo di vigenza contrattuale;

• La consultazione di riepiloghi dell’utilizzo del budget contrattuale, per l’intero contratto, per servizio e per area di competenza; i dati devono essere pubblicati sul portale sia con riferimento al periodo “mese”, sia con riferimento all’intero periodo di vigenza contrattuale;

• La consultazione dei livelli di servizio erogati dall’Impresa;

• Il calcolo delle penali per inadempienze relative ai livelli di servizio;

• La consultazione dell’orario di lavoro effettivamente prestato dalle risorse dell’Impresa presso INPS (nominativamente, per servizio / processo di lavoro cui sono assegnate); questi dati devono essere aggiornati giornalmente.

L’obiettivo è quello di rendere disponibili all’Istituto i risultati delle analisi sulle performance contrattuali attraverso funzionalità di reporting.

2.1.6. Ambienti di Sviluppo e Luoghi di Lavoro

Le attività oggetto del presente capitolato saranno svolte presso i locali delle società aggiudicatarie delle forniture, che predisporranno i posti di lavoro previsti, salvo quanto necessario per la raccolta, definizione dei requisiti e l’interlocuzione con le Direzioni amministrative, nonché le attività di sviluppo a partire dai test di integrazione di sistema, che avverranno di norma presso il CED dell’Istituto.

INPS si riserva in ogni caso di chiedere al Fornitore, anche con breve preavviso, la presenza di personale (in tutto o in parte) presso la sede dell’Istituto, qualora nel corso dell’erogazione dei servizi si presenti la necessità di svolgere alcune attività presso sedi diverse da quelle indicate. In tal caso INPS renderà disponibili i locali di lavoro, la cui ubicazione verrà comunicata al Fornitore, adeguatamente attrezzati per poter svolgere le attività richieste.

Per l’accesso ai sistemi INPS di sviluppo e test sono previsti collegamenti VPN tra i centri di sviluppo del fornitore e la rete INPS, con costo a carico del Fornitore. L’Istituto definirà le politiche di sicurezza che il fornitore dovrà rispettare sia per i collegamenti che per le stazioni di lavoro degli operatori.

I costi per gli spostamenti del personale del Fornitore saranno a totale carico dello stesso. Qualsiasi deroga a quanto sopra descritto dovrà essere autorizzata dall’INPS.

2.1.7. Regole per le Figure Professionali

Il Fornitore garantisce che tutte le risorse che impiegherà per l’erogazione dei servizi oggetto della fornitura rispondono ai requisiti minimi espressi dal presente Capitolato.

In sede di Offerta devono essere presentati almeno due CV, anche in forma anonima, per ogni figura professionale richiesta da impiegare nei servizi contrattuali previsti.

Il Fornitore, a seguito dell’aggiudicazione e con le modalità ed i tempi previsti dal contratto, sottopone all’Istituto per la valutazione i CV del personale impiegato nelle attività previste dalla fornitura, secondo il template di Curriculum previsto in Allegato 2. In ogni caso, per l’accettazione del personale proposto, INPS si riserva la possibilità di procedere ad un colloquio di approfondimento per verificare la corrispondenza delle competenze elencate nel CV, ed anche eventualmente di richiedere altre figure professionali.

Per il personale ritenuto da INPS inadeguato, a insindacabile giudizio dell’Istituto, qualunque sia il ruolo ed il servizio nel quale è impiegato, si procederà alla richiesta formale di sostituzione – con nota del Responsabile INPS del contratto - che dovrà avvenire entro 5 (cinque) giorni lavorativi dalla data della richiesta, con risorsa in possesso delle competenze ed esperienze richieste dal Capitolato.

Si precisa che nessuna risorsa dell’Impresa potrà essere allocata e impiegata in più di un servizio contemporaneamente.

2.1.8. Metodologia e Strumenti di sviluppo

Nell’espletamento delle proprie attività, il Fornitore dovrà attenersi agli standard ed alle metodologie di sviluppo utilizzate dall’INPS, ed autorizzate nei singoli Piani di Progetto finalizzati alla realizzazione delle relative applicazioni.

Le licenze tool di sviluppo software (Application server, documentale e repository, Adobe per la produzione di stampe) sono a carico del Fornitore, secondo quanto descritto nell’architettura applicativa di riferimento.

Il Fornitore potrà utilizzare, inoltre, altri prodotti e strumenti di sviluppo, diversi da quelli standard utilizzati dall’Istituto, purché approvati dall’Istituto col relativo Piano di Progetto ed a condizione che ciò non si traduca in un aggravio economico per l’Istituto.

Anche nel caso in cui il Fornitore venga ad utilizzare, autorizzato, tali prodotti e strumenti di sviluppo, le relative licenze d’uso dovranno essere intestate all’INPS, senza costi per l’Istituto.

2.1.9. Valutazione tecnologica

Con cadenza trimestrale, sarà indetto un incontro formale tra i Rappresentanti dell’Istituto e quelli del fornitore, per :

• valutare se le applicazioni di più recente realizzazione - in corso e/o in fase di studio - utilizzano architetture, metodologie e prodotti software adeguati allo stato della più recente e confacente evoluzione tecnologica;

• individuare, concertare e promuovere l’uso delle più innovative ed efficaci modalità di realizzazione delle applicazioni software, anche alla luce dell’evoluzione dell’architettura del Sistema Informativo dell’Istituto.

Indicatori di Qualità della Fornitura

2.2. Definizioni per la rilevazione dei livelli di servizio

Ai fini della presente fornitura, si intendono applicate le seguenti definizioni e convenzioni:

• Orario primario di servizio: orario convenuto durante il quale deve essere garantita la disponibilità del servizio agli utenti. Salvo ove diversamente concordato tale servizio verrà svolto, nelle ore comprese fra le 8,00 e le 18,00 dei giorni lavorativi, dal lunedì al venerdì, anche per le attività da svolgersi presso locali messi a disposizione dall’amministrazione.

• Finestra temporale di erogazione: arco di tempo per il computo dei livelli di servizio. E’ assunto pari all’orario primario di servizio.

• Giorni: giorni lavorativi, salvo ove diversamente specificato.

• Ore: ore lavorative comprese nell’orario primario di servizio, salvo ove diversamente specificato.

• Errore bloccante: malfunzione di una o più componenti del sistema informatico che impedisce la fruibilità di uno o più servizi da parte di un utente per più del 50% della sua attività lavorativa;

• Obiettivo: individua uno o più prodotti attesi al termine di un intervento. ciascun obiettivo è caratterizzato da un livello di qualità;

• Applicazione sw (o “applicazione”): in questo contesto viene definita “applicazione” una qualsiasi realizzazione software (sia sviluppata “ad-hoc”, sia implementata attraverso l’impiego e la personalizzazione di prodotti e/o ambienti di mercato) volta a fornire un insieme di funzionalità e/o servizi agli utenti, sia interni che esterni, dell’Istituto;

• Componenti applicative: porzione (modulo) di codice sw;

• Procedura software: insieme di moduli software, correlati tra loro, che vengono processati da un compilatore (o analogo strumento di “program prepara-tion”) o da un interprete (es. “job control program”, “query manager”);

• Sviluppo sw: insieme delle attività di:

A) analisi, progetto e realizzazione di applicazioni software e/o di componenti applicative;

B) integrazione di tali applicazioni/componenti con i prodotti sw di mercato eventualmente forniti;

C) manutenzione (correttiva, adeguativa ed evolutiva) effettuate su detti prodotti, applicazioni e componenti.

Lo sviluppo sw comprende anche la predisposizione e/o l’aggiornamento di tutta la documentazione (tecnica, gestionale, utente, ecc.) prevista a corredo delle applicazioni, componenti o prodotti interessati dal processo.

Lo sviluppo sw si intende articolata in singoli “interventi”, da effettuarsi nei modi e termini più oltre specificati.

• Intervento: specifica attività finalizzata allo “sviluppo sw” o “manutenzione” di applicazioni, componenti e prodotti sw.

• Risultato (o “prodotto”): elemento (sia sw che documentale) atteso quale esito di un intervento (o di una sua singola fase o attività). Ciascun risultato deve essere caratterizzato da uno o più obiettivi di qualità prestabiliti, predicibili, misurabili e riproducibili.

• Consegna: processo formale attraverso il quale dovranno essere rilasciati i “risultati” (anche parziali) ottenuti durante l’esecuzione di un intervento (o di sue singole fasi e attività).

• Approvazione: processo formale di verifica e validazione dei “risultati” attesi al termine di ciascun intervento (documenti tecnici e di progetto, porzioni di codice sw, prototipi, piani di test, ecc.).

• Accettazione: avvenuta esecuzione, con esito positivo, delle attività di collaudo di tutti i risultati dell'intervento.

2.3. Livelli di Qualità dei Prodotti SW

2.3.1. Linee guida per la qualità dei prodotti SW

Per assicurare i necessari livelli di qualità dei prodotti sviluppati e la rispondenza funzionale e qualitativa nei tempi, nei modi e nei costi concordati del prodotto medesimo al contratto, il Fornitore, nella produzione del software, dovrà attenersi alle “linee guida” di cui al presente paragrafo.

Occorre sottoporre a verifica, non solo il prodotto finale ma tutti i prodotti del processo di sviluppo attuato dal Fornitore, ossia:

• i Prodotti Finiti Intermedi, che possono essere documenti in fase di lavorazione, requisiti, prototipi del sistema finale, codice sorgente in fase di stesura ecc.;

• i Prodotti Finiti Finali, che possono essere specifiche di realizzazione, documenti di sistema, documenti di descrizione e di pianificazione del processo di produzione seguito, codice sorgente dei moduli dell'applicazione, componenti del sistema finale in esecuzione etc..

Con queste verifiche si analizzano e si risolvono tutti quei problemi, legati alla qualità dei prodotti, che nascono durante la fabbricazione del prodotto.

Al fine di consentire il monitoraggio dei prodotti realizzati, il Fornitore renderà accessibili al monitore, con le modalità indicate ai paragrafi successivi:

• la documentazione prevista nel contratto oggetto di monitoraggio;

• i risultati delle attività di verifica previste dal Fornitore (quali ad esempio ispezioni ai documenti, al codice sorgente ecc);

• i risultati delle attività di test previste dal processo del fornitore (quali, ad esempio, test d'unità, test d'integrazione, test di sistema, test di efficienza, collaudo ecc);

• documentazione dei difetti rilevati dalle attività di verifica (test e ispezioni) previste dal fornitore;

• documentazione delle azioni correttive eseguite dal fornitore per risolvere i difetti rilevati.

Per i prodotti software i parametri di qualità da valutare devono comunque essere quelli previsti dallo standard ISO 9126, che prevede la verifica del conseguimento di obiettivi di qualità quali funzionalità, portabilità, usabilità, manutenibilità, efficienza e affidabilità.

Per valutare i parametri individuati, gli indicatori sono quelli indicati nel seguente paragrafo.

2.3.2. Indicatori per la qualità dei Prodotti SW

Le valutazioni sulla qualità del prodotto sono fatte sulla base di misure rilevabili in diverse fasi del processo di produzione, quali ispezioni dei documenti o del codice sorgente, prove di sistema, collaudo etc..

Il piano è sviluppato sulla base delle specifiche da controllare e dei metodi di valutazione da utilizzare, ed è strutturato in modo da anticipare il più possibile l’individuazione di “criticità” e assicurare che le componenti del sistema rispondano alle caratteristiche di qualità prefissate.

Per ciascuna caratteristica di qualità da valutare viene riportata una tabella riassuntiva che specifica lo scopo delle attività di verifica, le sotto - caratteristiche o attributi di qualità da valutare, le fasi del processo di sviluppo in cui eseguire le verifiche.

Vengono di seguito illustrati i requisiti di qualità richiesti per la presente fornitura. Tali requisiti vengono misurati attraverso la descrizione di:

▪ caratteristiche/sottocaratteristiche, intese come classificazione dei requisiti di qualità finalizzati ad evidenziare gli obiettivi attesi;

▪ metriche, intese come modalità di rilevazione delle caratteristiche e sottoca-ratteristiche individuate;

▪ valori di soglia, intesi come valori “limite” che stabiliscono la conformità o meno dei prodotti/servizi ai livelli qualitativi attesi.

Si precisa che:

▪ nel caso in cui una o più delle caratteristiche/sottocaratteristiche di qualità di seguito illustrate risulti difforme dai valori di soglia attesi, il Fornitore si impegna ad adottare ed applicare tutte le misure e gli interventi necessari per riportare gli stessi entro limiti di accettabilità;

▪ il raggiungimento delle caratteristiche di qualità sarà verificato durante le operazioni di collaudo e sarà propedeutico alla accettazione finale di quanto sviluppato/fornito e, pertanto, alla corretta chiusura del servizio.

Caratteristiche di qualità per il codice sorgente

Gli indicatori e le misure di seguito indicate hanno l’obiettivo di garantire che il codice prodotto risponda a caratteristiche di qualità considerate basilari dall’Istituto.

Caratteristica: Funzionalità

Misura la rispondenza di quanto prodotto alle necessità espresse dai referenti dell’Istituto che utilizzeranno le nuove applicazioni.

Caratteristica: FUNZIONALITÀ
Sottocaratteristica	Metrica	Soglia
Adeguatezza: rispondenza funzionale del software a quanto richiesto dall’utente.	% di funzioni sviluppate rispetto a quelle approvate nel documento di “Specifica dei Requisiti” (copertura funzionale)	100%
	% di funzioni descritte nel documento di “Specifiche funzionali” rispetto a quelle sviluppate (copertura documentale)
Accuratezza: rispondenza della esecuzione delle funzioni a quanto richiesto dall’utente (in termini di risultati attesi e/o effetti).	% di test eseguiti in fase di test rispetto a quanto previsto nel Piano di Qualità.	100%
	% di copertura dei casi di prova rispetto agli obiettivi del Piano della Qualità.
	% di test eseguiti con successo prima del rilascio, rispetto al n° di test previsti dal Piano di Qualità.

La sottocaratteristica di adeguatezza viene verificata all’interno del “Processo di Realizzazione e Collaudo” durante la fase di “Qualificazione finale”.

La sottocaratteristica di accuratezza viene verificata all’interno del “Processo di Realizzazione e Collaudo” durante la fase di “Collaudo”.

Caratteristica: Manutenibilità

Misura la qualità del software prodotto per assicurare facilità di modifica, incluse evoluzioni, correzioni, adattamenti e ristrutturazioni garantendo minori costi di gestione e più facili e veloci interventi futuri al variare delle esigenze applicative.

Caratteristica: MANUTENIBILITÀ
Sottocaratteristica	Metrica	Soglia
Leggibilità: facilità di comprensione del codice sorgente prodotto a partire dalle descrizioni (commenti)	densità dei commenti	> 5% rispetto al codice sorgente
	linee di codice commentate	< 2% rispetto al codice sorgente
Analizzabilità: facilità di ”problem determination” e di identificazione delle parti da modificare.	% di “codice inerte” (ovvero mai percorso in fase di esecuzione) rispetto al volume totale di codice sorgente prodotto.	0%
	Livello massimo di annidamento delle istruzioni – Profondità del codice	<5
	Complessità Ciclomatica	<=20
	Complessità Essenziale	<4
	Numero Metodi per Classe	<=14
	Dipendenza Classe dai Child	Nessuna
	Violazioni Incapsulamento	0

Le misure delle due precedenti sottocaratteristiche vengono effettuate all’interno del “Processo di Realizzazione e Collaudo” al termine della fase “Codifica”.

Per la “Leggibilità”, iI calcolo della densità dei commenti è dato dal rapporto percentuale fra il numero di linee commento ed il numero di linee di codice (LOC). Sono considerate “linee commento” le seguenti:

▪ numero di linee di solo commento;

▪ numero di linee su cui sono presenti istruzioni e commenti.

La rilevazione viene effettuata dall’Istituto (o società da questo incaricata) all’interno del “Processo di Realizzazione e Collaudo” al termine della fase “Codifica” attraverso l’ispezione, con strumenti di analisi automatica del codice, dei sorgenti prodotti dal Fornitore.

Per la “Analizzabilità” vale la seguente convenzione:

▪ il “livello di annidamento” o “profondità del codice” indica il numero massimo di volte che strutture di controllo (Do…; For...; If…;ecc) sono contenute l’una dentro l’altra.

Per la descrizione estesa dei requisiti di qualità del SW si rimanda alla Allegato 4 – Strumenti per la Misura della qualità del SW.

Caratteristica: Usabilità

Misura la facilità di apprendimento e di uso da parte dell’utente.

L’operabilità viene misurata all’interno del “processo di realizzazione e collaudo” durante la fase di “collaudo”. La valutazione utente viene effettuata dall’Istituto, su ciascun modulo sw, attraverso questionari predisposti dal fornitore, verificati/approvati dai referenti INPS, compilati da un gruppo di utenti all’uopo individuati dall’Istituto stesso.

Caratteristica: USABILITÀ
Sottocaratteristica	Metrica	Soglia
Operabilità: Misura lo sforzo necessario agli utenti per le operazioni ed il relativo controllo. La finalità è principalmente quella di valutare il grado di soddisfazione dell'utente.	% di funzionalità che dispongono di help in linea context- sensitive*	100%
	% di funzionalità che dispongono di supporto formativo di autoistruzione*	100%
	Valutazione utente in merito a: ▪ chiarezza dei messaggi, facilità d'uso, ergonomicità del prodotto; ▪ capacità del prodotto di essere utilizzato con efficacia (facilità, efficienza e sicurezza)	≥ 8/10

* calcolato solo su funzionalità per le quali è stato concordato in fase di disegno la necessità di help contestuale e supporto autoformativo

Qualità della documentazione a corredo del sw applicativo

La documentazione prodotta a corredo del software applicativo deve:

• risultare conforme a quanto indicato nel “Piano di Qualità” del progetto;

• evidenziare, in modo chiaro e facilmente rintracciabile, le informazioni necessarie per l’identificazione di ciascun documento e in particolare:

o titolo, tipologia di documento e versione;

o responsabile della verifica e responsabile dell’approvazione;

o data di emissione;

o storia delle modifiche e lista di distribuzione;

• evidenziare chiaramente la componente SW in esame (funzionalità applicativa o sua parte componente);

• essere rilasciata sia in modo cartaceo che elettronico, quest’ultimo realizzato in formato predefinito (MS Word, Acrobat o HTML) da concordare preventivamente con l’Istituto.

Nel caso di impiego di prodotti/ambienti SW, la documentazione potrà essere quella che correda il prodotto/ambiente SW utilizzato.

Responsabilità del fornitore per le risorse informatiche impegnate dalle nuove applicazioni rilasciate in esercizio

Qualora una nuova applicazione rilasciata in esercizio presenti livelli “prestazionali” peggiori e/o impegno di risorse elaborative maggiori, rispetto a quanto il Fornitore aveva stimato e garantito nella fase di studio e previsione del lavoro da realizzare, il Fornitore medesimo sarà assoggettato, nei termini della durata contrattuale, alla penale per la “responsabilità del Fornitore per risultati conseguiti difformi dalle stime”.

Responsabilità del fornitore per la “robustezza” delle applicazioni rilasciate in esercizio

Il numero di errori insiti mediamente in una applicazione software che superano la fase di test e di collaudo può essere definito indice di sinistrosità, ossia di guasti medi attesi e tollerabili. A tal proposito, l’aspettativa normale di errori che si potrebbero verificare in 500 Punti Funzione è rappresentabile dalla seguente tabella:

Caratteristica: DIFETTOSITA’
Caratteristica	Sottocaratteristica						Soglia
DIFETTOSITA’: Misura della difettosità del codice	Metrica Totale errori per 500 FP
prodotto	Metrica Totale errori per 500 FP
prodotto	In fase di collaudo						20
	Primo trimestre						15
	Secondo trimestre						7
	Terzo trimestre						5
	Quarto trimestre						3
	Periodo	successivo	fino	alla	scadenza	della	0
	garanzia

Il che evidenzia come il maggior numero di errori, intesi come malfunzioni riferibili all’applicazione (esclusi, pertanto quelli dell’utente e quelli di natura sistemistica) e “contati” una sola volta, anche se “segnalati” da “più utilizzatori” contemporaneamente, hanno luogo nel primo periodo, con una tendenza a scomparire dopo 12 mesi.

Ciò premesso, si ritiene adeguato che il Fornitore garantisca, in relazione e proporzione al sopra

descritto contingente-base-di-riferimento di 500 Punti Funzione, tutti i contingenti trimestrali di software sviluppato e posto in esercizio con una linea di sinistrosità non superiore a quella delineata in tabella, o a quella inferiore eventualmente dichiarata, per ciascuno dei 5 “periodi”.

Pertanto, per ogni trimestre, decorrente dalla data di inizio del contratto, saranno cumulati i Punti Funzione delle applicazioni rilasciate in esercizio. Ciascuno di tali contingenti sarà “posto sotto osservazione” per il controllo della sua singola linea di “sinistrosità”, rispetto ai valori “standard” richiesti sopra citati, nel corso dei trimestri successivi dell’arco contrattuale.

2.4. Livelli di qualità SW in Manutenzione

I livelli di qualità del codice sw modificato non devono peggiorare le caratteristiche di manutenibilità dello stesso.

Si precisa che:

• nel caso in cui una o più delle caratteristiche/sottocaratteristiche di qualità richieste risulti difforme dai valori di soglia attesi, il fornitore si impegna ad adottare ed applicare tutte le misure e gli interventi necessari per riportare gli stessi entro limiti di accettabilità;

• il raggiungimento delle caratteristiche di qualità sarà verificato a posteriori dello specifico intervento e sarà propedeutico alla accettazione finale del sw manutenuto e, pertanto, alla corretta chiusura dell’intervento in esame.

2.5. Livelli di qualità per le Attività Progettuali

Gli interventi di sviluppo e di manutenzione riguardano la progettazione e l’implementazione di nuove funzionalità applicative e/o la modifica di funzionalità esistenti. Tale attività comporta la realizzazione ex-novo e/o la modifica (anche correttiva) di programmi software (SSW) ovvero la parametrizzazione di funzioni standard e la personalizzazione all’interno di soluzioni applicative commerciali (SSC).

Il procedimento mediante il quale viene attivato un intervento di sviluppo e manutenzione è quello descritto in precedenza relativo alla modalità di erogazione della fornitura.

Da tale procedimento scaturisce quindi Il Piano di Progetto, relativo a ciascun intervento da realizzare che rappresenta il riferimento per la rilevazione dei livelli di qualità delle attività progettuali.

Si ribadisce che gli interventi di sviluppo e di manutenzione evolutiva e adeguativa sono da intendersi in garanzia per un anno dalla loro messa in esercizio.

I tempi d’intervento in caso di errori, anomalie o malfunzionamenti dovranno essere i medesimi indicati per la manutenzione correttiva.

Gli indicatori di qualità delle attività di tipo progettuali sono i seguenti:

Caratteristica: RISPETTO DEI TEMPI E COSTI DI REALIZZAZIONE

Sottocaratteristica

Metrica

Soglia

Scostamento dei tempi di completamento intervento e/o consegna prodotti: scostamento dei tempi di consegna/completamento rispetto a quanto pianificato - per

cause imputabili al fornitore

% scostamento dei tempi di consegna prodotti intermedi e finali e di completamento rispetto ai tempi indicati nel piano di progetto (o nella

ripianificazione successiva)

Scostamento dei costi di realizzazione intervento e prodotti intermedi : scostamento dei costi rispetto a quanto pianificato -

per cause imputabili al fornitore

% di scostamento dei costi a consuntivo rispetto ai costi di realizzazione indicati nel piano di progetto

(o nella ripianificazione successiva)

2.6. Livelli di qualità Servizio di Gestione Applicativa

L’attività di Gestione Applicativa è erogata secondo quanto definito nei precedenti paragrafi per procedure applicative realizzate nell’ambito della Gara in oggetto ed avviate in esercizio, ovvero per applicazioni esistenti.

Per le applicazioni esistenti, la sua durata sarà concordata tra l’Amministrazione ed il Fornitore, anche in relazione alla complessità delle applicazioni.

La qualità del supporto di secondo livello verrà valutata in base ad indicatori di tempestività ed efficacia, secondo le seguenti definizioni, sulla base del tempo medio intercorso (in termini di ore lavorative) tra la segnalazione di un problema e la soluzione, ove possibile, ovvero la diagnosi del problema e smistamento al servizio di manutenzione correttiva o verso altro servizio competente secondo le regole definite da INPS. A tal fine vengono individuati i seguenti livelli di servizio, applicabili per attività di competenza del fornitore.

Caratteristica: TEMPI DI INTERVENTO E RISOLUZIONE

Sottocaratteristica

Metrica

Soglia

Richiesta con priorità Urgente:

Urgente, attività indispensabile per garantire la continuità di servizio o il servizio stesso a una o più sedi e strutture

Tempi di presa in carico e risoluzione

Presa in carico 30 minuti

Risoluzione 2 ore

Richiesta con priorità Alta

Attività necessaria per garantire la continuità di servizio o il servizio stesso a uno o più utenti di una sede/struttura

Tempi di presa in carico e risoluzione

Presa in carico 1 ora

Risoluzione 4 ore

Richiesta con priorità Media

Attività necessaria per garantire la continuità di servizio o il servizio stesso a uno o più utenti di una sede/struttura

Tempi di presa in carico e risoluzione

Presa in carico 1 ora

Risoluzione 8 ore

Richiesta con priorità Bassa

Tempi di presa in carico e risoluzione

Presa in carico 1 ora

Risoluzione giorno lavorativo successivo o oltre ove richiesto da INPS

Nel caso di richiesta proveniente da Help Desk di Xxxxx Xxxxxxx, la presa in carico si intende automatica dall’avvenuto smistamento del ticket su sistema Help Desk eseguito dagli operatori di Help Desk verso i II livelli interessati.

Nel caso di ricezione diretta (es. richiesta diretta da parte di personale INPS o segnalazione da evento interno), il fornitore è obbligato a tracciare su sistema di Help Desk l’orario di ricezione della richiesta ed il nominativo del richiedente. Vale come orario di presa in carico l’orario di immissione a sistema del ticket. L’orario di ricezione delle richiesta sarà oggetto di verifica da parte di INPS.

Alle attività di Gestione Applicativa svolte sul parco SW esistente si applica unicamente l’indicatore di qualità relativo al Tempo di Intervento.

2.6.1. Sostituzione del personale

Caratteristica: GESTIONE DEL PERSONALE
Sottocaratteristica	Sottocaratteristica	Sottocaratteristica
Turn over: numero di risorse sostituite su iniziativa del Fornitore	% di risorse sostituite dal Fornitore su base semestrale	< 10 %
Personale della fornitura inadeguato: numero di risorse sostituite, perche’ non ritenute adeguate, su richiesta di INPS	% di risorse sostituite su richiesta di INPS su base semestrale	< 10 %
Ritardo del fornitore nell’inserire o sostituire personale	Tempo intercorso per il raggiungimento della piena produttivita’ del nuovo personale	3 mesi

2.7. Livelli di Qualità per il Servizio di Manutenzione Correttiva

Con specifico riferimento al servizio di “Manutenzione correttiva delle funzioni applicative”, si riportano qui di seguito i livelli di qualità attesi. I criteri indicati sono applicabili agli interventi di manutenzione correttiva, che vengono attivati principalmente dalla struttura di “help-desk” di 2° livello. Le rilevazioni indicate nella successiva tabella si intendono effettuate, nei rispettivi periodi di riferimento, durante l’orario primario di servizio.

Rientrano nel conteggio della metrica anche gli interventi che saranno eseguiti nel periodo di garanzia.

2.7.1. Caratteristiche di qualità Caratteristica: Efficienza

Misura la capacità del Fornitore di intervenire nel rispetto dei tempi previsti contrattualmente.

Caratteristica: EFFICIENZA
Sottocaratteristica	Metrica			Soglia
TEMPI DI INTERVENTO E RISOLUZIONE Alta Priorità - GUASTI BLOCCANTI	tempo massimo di risoluzione (calcolati su base mensile)	intervento	e	INTERVENTO: 2h* RIPRISTINO: 6h*
TEMPI DI INTERVENTO E RISOLUZIONE Media Priorità - GUASTI NON BLOCCANTI	tempo massimo di risoluzione (calcolati su base mensile)	intervento	e	INTERVENTO: 4h* RIPRISTINO: 16h*

*tempi massimi (95% dei casi)

Per le attività di manutenzione correttiva svolte sul parco SW esistente si applica unicamente l’indicatore relativo al Tempo di Intervento.

I criteri di classificazione delle priorità di intervento derivano dalle seguenti indicazioni di massima:

⮚ Alta priorità – Guasti Bloccanti, Livello di severità 1: errori “blocco o fermo delle attività”, per i quali dovrà essere fornita una soluzione. L’indisponibilità del sistema o di sue componenti comporta per gli Utenti/Uffici la mancata erogazione di tutti o parte dei servizi disponibili e/o l’impossibilità di svolgere tutte o parte delle funzioni istituzionali.

⮚ Media priorità – Guasti non Bloccanti, Livello di severità 2: errori “che non comportano fermo delle attività”. L’indisponibilità del sistema o di sue componenti comporta per gli utenti il mancato svolgimento di funzioni non critiche.

I tempi indicati nella precedente tabella si intendono comprensivi dei seguenti adempimenti a carico del personale del Fornitore:

• rilascio in esercizio del prodotto SW oggetto dell’intervento. Il rilascio si intende effettuato nei confronti di tutti gli utenti del prodotto stesso;

• aggiornamento della documentazione (tecnica, operativa, gestionale, ecc.) che correda il prodotto SW. In tale ambito, si intendono aggiornati anche:

o i testi e le funzionalità dell’Help in linea;

o gli eventuali supporti formativi di autoistruzione che corredano il prodotto;

• inserimento (eventuale) del SW sorgente (moduli, librerie, etc.) e della documentazione (tecnica, operativa, gestionale, ecc.) all’interno del Sistema di gestione della configurazione.

Riciclo Correttivo

Caratteristica: EFFICIENZA

Sottocaratteristica

Metrica

Soglia

Riciclo Correttivo (numero di interventi di manutenzione correttiva recidivi per lo stesso

malfunzionamento)

numero di interventi correttivi riguardanti uno stesso malfunzionamento su base trimestrale

0 (zero)

Penali

2.7.2. Sviluppo e Manutenzione del software applicativo – caratteristiche di qualita’ per il codice sorgente

Caratteristiche di qualità per il codice sorgente rilevate:

• funzionalità;

• manutenibilità;

• usabilità;

• documentazione prodotta a corredo del SW applicativo.

Nel caso in cui una o più delle caratteristiche rilevate al termine di ciascun intervento si difformi dai livelli richiesti e indicati nel Capitolato tecnico (o nell’offerta tecnica, se migliorativi), il Fornitore si impegna ad adottare ed applicare tutte le misure e gli interventi necessari per riportare gli stessi entro limiti di accettabilità.

Il raggiungimento dei livelli di qualità richiesti sarà verificato durante le operazioni di collaudo e accettazione di ciascun singolo intervento e sarà propedeutico per la positiva conclusione del collaudo stesso. Le eventuali penali, pertanto, saranno computate in ragione dei giorni di ritardo nella conclusione del collaudo.

2.7.3. Manutenzione correttiva delle funzioni applicative

Le penali previste per gli interventi di manutenzione correttiva sono applicate in tutti i casi in cui si venissero a verificare contemporaneamente tutte le seguenti condizioni:

1. i malfunzionamenti rilevati sono imputabili a moduli applicativi sviluppati e/o manutenuti dal Fornitore nel corso del presente contratto;

2. i servizio di manutenzione correttiva non risulta essere stato svolto in modo conforme ai livelli di servizio richiesti nel capitolato tecnico (o nell’offerta tecnica se migliorativa).

Il computo della penale è calcolato in percentuale sul valore del Deposito Cauzionale Definitivo (DCD) ed è valutato nella misura seguente:

Ambito

Parametro o caratteristica

Penale

Efficienza temporale Intervento - MAC: rispetto dei tempi di intervento per la

risoluzione delle anomalie segnalate.

Tempo di intervento: tempo medio di intervento (in ore lavorative) valutato su

base bimestrale

0,2% del DCD per ogni 0,1% di aumento

Efficienza temporale Risoluzione - MAC : rispetto dei tempi di risoluzione delle anomalie segnalate.

Tempo medio di risoluzione: tempo medio di risoluzione del problema (in ore lavorative) valutato su base bimestrale in modo distinto per i seguenti casi:

▪ Alta priorità (Ap)

▪ Media priorità (Mp)

Ap:

0,6 % del DCD per ogni 0,1% di aumento

Mp:

0,4% del DCD per ogni

0,1% di aumento

Relativamente alle caratteristiche del software, gli interventi correttivi devono garantire il non peggioramento delle caratteristiche di qualità per il codice sorgente già descritte.

Nel caso in cui una o più delle caratteristiche di qualità rilevate al termine di ciascun intervento si difformi dai livelli richiesti e indicati nel Capitolato tecnico (o nell’offerta tecnica, se migliorativi), il Fornitore si impegna ad adottare ed applicare tutte le misure e gli interventi necessari per riportare gli stessi entro limiti di accettabilità.

Il raggiungimento dei livelli di qualità richiesti sarà verificato durante le operazioni di collaudo e accettazione di ciascun singolo intervento e sarà propedeutico per la positiva conclusione del collaudo stesso. Le eventuali penali saranno computate in ragione dei giorni di ritardo nella conclusione del collaudo.

2.7.4. Collaudi

2.7.4.1. Disponibilità al Collaudo

Qualora il Fornitore, per fatti ad esso direttamente imputabili o direttamente connessi con lo svolgimento delle attività affidategli, non si renda disponibile per il collaudo nei termini di cui “Riferimento alla norma che definisce i termini previsti per il collaudo” rispetto alle date previste all’interno del Piano di progetto, si applica una penale, computata in ragione del valore economico della specifica attività nella misura seguente:

Ambito	Parametro o caratteristica	Penale
Disponibilità collaudo	Fino al raggiungimento 10° giorno.	0,1% per ogni giorno solare di ritardo
	Tra l’11° ed il 30° giorno.	0,25% per ogni giorno solare di ritardo
	Oltre il 30° giorno	0,75% per ogni giorno solare di ritardo

2.7.4.2. Esito Sfavorevole del Collaudo

Nel caso in cui il primo collaudo abbia avuto esito sfavorevole non si applicano penali.

Qualora tuttavia, entro 15 giorni lavorativi dal primo esito sfavorevole, il Fornitore non risulti disponibile per un successivo collaudo si applica una penale, computata in ragione del valore economico della specifica attività, nella misura seguente:

	Parametro o caratteristica	Penale
Esito collaudo	Fino al raggiungimento 10° giorno di ritardo, oltre i quindici giorni previsti dal primo esito sfavorevole.	0,5% per ogni giorno solare di ritardo
Esito collaudo	Ogni ulteriore giorno solare di ritardo.	1,00% per ogni ulteriore giorno solare di ritardo

Laddove le nuove prove di collaudo risultino nuovamente negative l’Istituto, a suo insindacabile giudizio, si riserva la facoltà di avvalersi della clausola risolutiva di cui allo schema di contratto.

2.7.4.3. Ritardata Consegna del Prodotto

Nel caso in cui la consegna del prodotto (nel rispetto delle caratteristiche prestabilite) non avvenga nei termini previsti nella scheda di intervento, sarà applicata, a carico del Fornitore inadempiente, una penale giornaliera pari all’1% del valore del singolo intervento, ossia n°. Punti Funzione * valore unitario Punto Funzione offerto, fino ad un massimo di 30 giorni di ritardo, salvo il risarcimento dell’eventuale maggior danno.

Ambito	Parametro o caratteristica	Penale
Consegna Prodotto dell’intervento	Giorni ritardo consegna prodotto	penale giornaliera pari 1% del valore del singolo intervento, ossia n°. Punti Funzione * valore unitario Punto Funzione offerto, fino ad un massimo di 30 giorni di ritardo

2.7.4.4. Difettosità del Prodotto durante il Periodo di Collaudo

Il prodotto realizzato, durante l’intera fase di collaudo, non può presentare un numero di errori superiore a 20 per ogni 500 Punti Funzione sviluppati.

Ove ciò abbia luogo, per ogni errore che superi la predetta soglia, il Fornitore sarà assoggettato ad una penale pari, per ogni unità di superamento, all’1% del valore del singolo intervento, ossia n°. Punti Funzione * valore unitario Punto Funzione offerto, fino ad un massimo del 10% del valore dell’applicazione stessa.

Ambito

Parametro o caratteristica

Penale

Difettosità al collaudo

Numero errori eccedenti la soglia di 20 errori per ogni 500 Punti Funzione sviluppati

per ogni unità di superamento, all’1% del valore del singolo intervento, ossia n°. Punti Funzione

* valore unitario Punto Funzione offerto, fino ad un massimo del 10% del valore dell’applicazione stessa

2.7.4.5. Prodotto Collaudato con Esito Negativo

In caso di collaudo con esito negativo, il Fornitore dovrà eliminare le difettosità riscontrate e ripresentare il prodotto per la riesecuzione di un nuovo collaudo entro il termine 10 giorni decorrenti dalla data del verbale di “collaudo negativo”. Per ogni giorno di ritardo rispetto a tale termine, la società sarà assoggettata ad una penale giornaliera pari all’1% del valore del singolo intervento, ossia n°. Punti Funzione * valore unitario Punto Funzione offerto, fino ad un massimo di 15 giorni, salvo il risarcimento dell’eventuale maggior danno.

Superato tale ultimo termine, il collaudo si intenderà “definitivamente negativo”.L’Istituto si riserva il diritto di fare effettuare da altri le prestazioni non eseguite, ponendo a carico del Fornitore la spesa all'uopo sostenuta, rivalendosi sia su eventuali crediti del Fornitore, sia sulla cauzione, salvo il risarcimento dell’eventuale maggior danno.

Ambito	Parametro o caratteristica	Penale
Esito Xxxxxxxx	Xxxxxx di ritardo risoluzione difettosità e riesecuzione collaudo - oltre 10gg dal collaudo con esito negativo	penale giornaliera pari all’1% del valore del singolo intervento fino ad un massimo di 15 giorni

2.7.4.6. Ritardato avvio in esercizio

Nel caso in cui l’avvio in esercizio del prodotto già consegnato non avvenga nei termini previsti, sarà applicata, a carico del Fornitore inadempiente, una penale giornaliera pari all’1% del valore del singolo intervento, ossia n°. Punti Funzione * valore unitario Punto Funzione offerto, fino ad un massimo di 60 giorni di ritardo, salvo il risarcimento dell’eventuale maggior danno.

Ambito

Parametro o caratteristica

Penale

Avvio in esercizio

Giorni di Ritardo Avvio in Esercizio

penale giornaliera pari all’1% del valore del singolo intervento, ossia n°. Punti Funzione * valore unitario Punto Funzione offerto, fino ad un massimo di 60 giorni di ritardo

2.7.5. Malfunzioni del Prodotto durante il Periodo di Garanzia

Durante il periodo di garanzia, il Fornitore dovrà assicurare una efficiente e tempestiva assistenza tecnica che dovrà garantire il ripristino della funzionalità delle applicazioni in errore entro il termine di 2 giorni lavorativi dalla chiamata.

L’evento “malfunzione”, che avrà avuto luogo per cause non imputabili all’Istituto, ovvero a “forza maggiore” o a “caso fortuito, verrà segnalato “via mail” con l’indicazione del giorno e dell’ora della chiamata stessa.

Decorso il suddetto termine, per ogni giornata naturale consecutiva di malfunzionamento dell’applicazione in errore, è applicata una penale pari all’1% del valore del singolo intervento, ossia n°. Punti Funzione * valore unitario Punto Funzione offerto, fino ad un massimo di 30 giorni di fermo. Le eventuali penalità verranno trattenute anche dal deposito cauzionale definitivo, che, in tal caso, dovrà essere tempestivamente ripristinato.

Ambito	Parametro o caratteristica	Penale
Malfunzionamenti in garanzia	Ritardo correzione malfunzionamento oltre 2gg dalla chiamata	penale pari all’1% del valore del singolo intervento fino ad un massimo di 30 giorni di fermo

Superato tale termine, se il Fornitore non adempirà all’obbligo di ripristino delle funzionalità interrotte, l’Istituto si riserva il diritto di fare effettuare da altri le prestazioni non eseguite, ponendo a carico del Fornitore la spesa all'uopo sostenuta, rivalendosi sia su eventuali crediti del Fornitore, sia sulla cauzione, salvo il risarcimento dell’eventuale maggior danno.

2.7.6. Sinistrosità del Software Rilasciato in Esercizio

Il Fornitore deve garantire, per i contingenti di software sviluppati trimestralmente, una linea di

sinistrosità non superiore a quella indicata dall’Istituto nel presente Capitolato tecnico.

Pertanto, per tutta la durata del presente contratto, nonché per i 12 mesi successivi della garanzia, saranno poste sotto osservazione le linee di sinistrosità di ogni contingente di software trimestrale sviluppato.

In caso di inosservanza di ciascuna linea di sinistrosità determinatasi, per ogni unità di superamento, e fino ad un totale di 10 errori in eccesso rispetto alla relativa soglia del periodo in esame, il Fornitore sarà assoggettato ad una penale pari al 2% del valore dei Punti Funzione in osservazione.

Ambito	Parametro o caratteristica	Penale
Difettosità in esercizio	Unità di superamento soglie di difettosità	per ogni unità di superamento, e fino ad un totale di 10 errori in eccesso: penale pari al 2% del valore dei Punti Funzione in osservazione.

Al fine di evitare alti fattori di complessità gestionale, atteso che sulla manutenzione correttiva l’Istituto nulla deve corrispondere, nei rimanenti casi di manutenzione (evolutiva ed adeguativa ) il computo avverrà come segue :

• saranno trascurati i conteggi relativi a “manutenzioni” su applicazioni già realizzate dal Fornitore fino ad un massimo del 50% di valore dei Punti Funzione dell’applicazione originaria; in tal caso, continua la precedente “linea di sinistrosità”;

• nel caso di valori superiori al 50%, sarà ritirata dal precedente trimestre di “rilascio in esercizio” l’applicazione mantenuta; per conseguenza, la “nuova applicazione” manutenuta e rilasciata in nuovo esercizio sarà inserita nel corrispondente trimestre di rilascio per un valore di Punti Funzione corrispondente al valore ricalcolato della nuova applicazione risultante.

2.7.7. Ritardato Ripristino

La qualità della Gestione Applicativa verrà valutata in base ad indicatori di tempestività ed efficacia nelle risposte, secondo le seguenti definizioni, sulla base del tempo medio intercorso tra la segnalazione di un problema e la soluzione, ovvero la diagnosi del problema e smistamento del problema ove applicabile.

Si precisa che per intervento si deve intendere “presa in carico del problema, inizio delle attività”; per ripristino si deve intendere “ripristino della funzionalità” di competenza del Fornitore, e, comunque, “diagnosi del problema ed individuazione della soluzione”.

Qualora il blocco o fermo delle attività sia dovuto ad una anomalia (errore) del software prodotto dal Fornitore, il problema ricadrà nel servizio di Garanzia e dovrà intendersi come “data segnalazione errore” la data in cui il problema è stato diagnosticato come errore e trasferito al servizio di Garanzia.

Segnalazioni contemporanee della “stessa malfunzione” saranno equiparate ad “una sola malfunzione”.

Ambito

Parametro o

caratteristica

Penale

Richiesta con priorità Urgente:

Attività indispensabile per garantire la continuità di servizio o il servizio stesso a una o più sedi e strutture

Presa in carico 30 minuti

Risoluzione 2 ore

1000 euro per attività completata in ritardo

Richiesta con priorità Alta

Attività necessaria per garantire la continuità di servizio o il servizio stesso a uno o più utenti di una

sede/strutture

Presa in carico 1 ora

Risoluzione 4 ore

750 euro per attività completata in ritardo

Richiesta con priorità Media

Attività indispensabile per garantire la continuità di servizio o il servizio stesso a un utente di sede o struttura

Presa in carico 1 ora

Risoluzione 8 ore

500 euro per attività completata in ritardo

Richiesta con priorità Bassa

Presa in carico 1 ora Risoluzione giorno lavorativo successivo o oltre ove richiesto da INPS

250 euro per attività completata in ritardo

2.7.8. Responsabilità del Fornitore per Risultati Conseguiti Difformi dalle Stime

Qualora una nuova applicazione rilasciata in esercizio presenti livelli “prestazionali” peggiori e/o impegno di risorse elaborative maggiori rispetto a quanto il Fornitore aveva stimato e garantito nella fase di studio e previsione del lavoro da realizzare, il Fornitore medesimo sarà assoggettato, nei termini della durata contrattuale, ad una penale pari all’1% del valore del singolo intervento, ossia n°. Punti Funzione * valore unitario Punto Funzione offerto, per ogni 10 punti percentuali della differenza di valore del livello prestazionale “peggiore” e/o del maggiore impegno di risorse elaborative, col limite massimo del valore dell’applicazione.

Ambito

Parametro o caratteristica

Penale

Livelli Prestazionali

% differenza livello prestazionale reale rispetto al livello stimato

1% del valore del singolo intervento, ossia n°. Punti Funzione

* valore unitario Punto Funzione offerto, per ogni 10 punti percentuali della differenza di valore del livello prestazionale peggiore

2.7.9. Mancata Continuità nella Presenza degli Addetti

Alla società che dovrà introdurre un nuovo addetto, avendo già esaurito i subentranti e senza poter certificare che l’”introduzione” ha avuto luogo a fronte di una precedente conclusione di rapporto di

lavoro, sarà applicata la Penale per Mancata Continuità nella Presenza degli Addetti, pari a € 15.000,00, per addetto, per un numero massimo 10 addetti.

Allegato 1 – Elenco interventi previsti

Lotto 1 - Linea L1 Unificazione

Area Applicativa

Titolo Progetto / Ambito e Obiettivo

Priorità

Benefici

Metrica

Anagrafica

U1 – Gestione anagrafica centralizzata a supporto delle prestazioni di tutte le Gestioni, inclusa l’anagrafica pensionistica

• Affidabilità delle risposte

• Aumento efficienza nei controlli

• Miglioramento dell’immagine dell’Istituto

• Miglioramento qualità dei dati

• Miglioramento efficacia dei controlli

• Omogeneizzazione procedure

• Razionalizzazione nell'uso delle risorse disponibili

% condivisione dati originati da diversi sistemi

Entrate

U2 – Gestione unificata delle trattenute sui trattamenti pensionistici erogati dalle gestioni INPS

• Efficienza della P.A.

• Efficienza negli accertamenti ispettivi

• Incremento della consapevolezza da parte degli assicurati dell'importanza della contribuzione previdenziale

• Miglioramento della qualità dei dati

• Miglioramento dell'efficacia dei controlli

• Riduzione dei costi di gestione dei procedimenti amministrativi

• N. domande prestazioni per Ente

• % riduzioni morosità

Entrate

U3 – Adeguamento alle modalità di pagamento in uso presso INPS (es. MAV)

Entrate

U4- Unificazione delle denunce contributive (UNIEMENS)

Posizione assicurativa

U5 – Estratto conto certificato

Pensioni

U6 – Unificazione del pagamento pensioni

• Incremento della qualità del servizio percepita dall’utente

• Miglioramento della qualità dei dati

% incremento consultazione estratti conto certificati

Prestazioni pensionistiche in vigenza

U7 –Determinazione dei provvedimenti di computo e condivisione delle informazioni necessarie alla definizione dei provvedimenti (certificazione CER,

...).

• Aumento della produttività complessiva

• Certezza e celerità dei tempi di erogazione dei servizi

• Efficientamento nei controlli

• Miglioramento dell’efficacia dei controlli ispettivi

• Miglioramento della qualità dei dati

• Riduzione dei costi di gestione

% incremento scambio flussi

Processi trasversali e di integrazione

U8 – Unificazione sistemi contabili

• Aumento della percezione della qualità del servizi

• Certezza e celerità dei tempi di erogazione dei servizi

• Dematerializzazione dei documenti cartacei

• Efficacia, efficienza ed economicità dell'azione

amministrativa

% diminuzione tempi di pagamento

Processi trasversali e di integrazione

U9 - alimentazione del datawerhouse dell’Istituto per lo sviluppo di una “reportistica direzionale”

• Certezza e celerità dei tempi di erogazione dei servizi

• Dematerializzazione dei documenti cartacei

• Facilità di accesso e semplicità di

utilizzo dei servizi offerti

• % incremento informazioni condivise

Lotto 1 - Linea L2 – Reingegnerizzazione

Area Applicativa	Titolo Progetto / Ambito e Obiettivo	Priorità	Benefici	Metrica
Anagrafica	R1 – reingegnerizzazione dei servizi al fine dell’anagrafica unica	1	• Affidabilità delle risposte • Efficientamento nei controlli • Miglioramento dell’immagine dell’Istituto • Miglioramento qualità dei dati • Miglioramento efficacia dei controlli • Omogeneizzazione procedure • Razionalizzazione nell'uso delle risorse disponibili	% condivisione dati originati da diversi sistemi
Entrate	R2 – Reingegnerizzazione della correntezza e della correttezza delle entrate contributive	2	• Miglioramento della qualità dei dati Miglioramento dell'efficacia dei controlli • Riduzione dei costi di gestione dei procedimenti amministrativi	• % riduzioni morosità • % aumento incassi
Posizione assicurativa	R3 – Reingegnerizzazione ai fini della liquidazione della pensione	1	• Incremento della qualità del servizio percepita dall’utente • Miglioramento della qualità dei dati	% incremento consultazione estratti conto certificati
Pensioni	R4 - Reingegnerizzazione dei trattamenti pensionistici	1	• Aumento della produttività complessiva • Certezza e celerità dei tempi di erogazione dei servizi • Efficientamento nei controlli • Miglioramento dell’efficacia dei controlli ispettivi • Miglioramento della qualità dei dati • Riduzione dei costi di gestione	% incremento scambio flussi
Prestazioni pensionistiche in vigenza	R5 – Reingegnerizzazione per la simulazione dei calcoli	2	• Aumento della percezione della qualità del servizi • Certezza e celerità dei tempi di erogazione dei servizi • Dematerializzazione dei documenti cartacei • Efficacia, efficienza ed economicità dell'azione amministrativa	% incremento domande computo
Processi trasversali e di integrazione	R6 – Reingegnerizzazione delle procedure a supporto delle prestazioni, in particolare la gestione del sistema di automazione e gestione processi, la gestione della documentazione in entrata e uscita e l’interfaccia al portale dei pagamenti	1	• Certezza e celerità dei tempi di erogazione dei servizi • Dematerializzazione dei documenti cartacei • Facilità di accesso e semplicità di utilizzo dei servizi offerti	% incremento informazioni condivise

Lotto 2 – Linea L3 Consolidamento

Area Applicativa	Titolo Progetto / Ambito e Obiettivo	Priorità	Benefici	Metrica
Attività Sociali	C1 – Borse di studio – High School Program	1	• Ampliamento del bacino d’utenza dei servizi offerti • Certezza e celerità dei tempi di erogazione dei servizi • Efficacia, efficienza ed economicità dell’azione amministrativa • Efficienza negli accertamenti ispettivi • Miglioramento della qualità dei dati • Potenziamento dei servizi di risposta	% incremento erogazione prestazioni
Attività Sociali	C2 – Ospitalità in Nonno House	1
Attività Sociali	C3 – Borse di studio Dottor J	1
Attività Sociali	C4 – Borse di studio – Aggiornamento professionale ai dipendenti	1
Attività Sociali	C5 – Borse di studio – Stagione 2014/2015	1
Attività Sociali	C6 – Home Care Premium – Bando 2013/2014	1
Attività Sociali	C6 – Convitti e Collegi Universitari – stagione 2014/2015	1
Attività Sociali	C7 – Convitti – Gestione turnazione convittori per definire il numero posti da mettere a bando	1
Attività Sociali	C8 – Vacanze Studio – stagione 2014/2015	1
Attività Sociali	C9 – Soggiorno Benessere – stagione 2014/2015	1
Attività Sociali	C10 – Climatico-termale – stagione 2014/2015	1
Attività Sociali	C11 – Prestazioni ex-Enam	1
Attività Sociali	C12- Prestazioni ex-Ipost	1
Attività Sociali	C13 – prestazioni altre Gestioni Assistenziali	2
Credito	C14- Colloquio con Enti pubblici per decertificazione	1	• Aumento della percezione della qualità del servizi • Certezza e celerità dei tempi di erogazione dei servizi • Efficacia, efficienza ed economicità dell'azione amministrativa Efficienza della P.A. • Facilità di accesso e semplicità di utilizzo dei servizi offerti • Miglioramento della qualità dei servizi erogati • Semplificazione dell’accesso ai servizi	% incremento erogazione prestazioni
Credito	C15 - Adeguamento funzioni con Posizione Assicuratiiva	1
Credito	C16 - Integrazione con area Entrate Piani di ammortamento e riscossione	1
Credito	C17 - Integrazione con Equitalia per Riscossione e verifica carichi pendenti in fase di erogazione	1
Credito	C18 - Integrazione con Agenzia Entrate per gestione ipoteche	1
Credito	C19 - Mutui Ipotecari Edilizi - Evolutive per la prestazione a seguito di esigenze già espresse dalla Direzione amministrativa	1
Credito	C20 - Mutui Ipotecari Edilizi – Servizi online	1
Credito	C21 - Mutui Enti e Cooperative - Evolutive per la prestazione a seguito di esigenze già espresse dalla Direzione amministrativa	1
Credito	C22- Mutui Enti e Cooperative – Servizi online	1
Credito	C23 - Prestiti/Convenzioni - Evolutive per la prestazione a seguito di esigenze già espresse dalla Direzione amministrativa	1
Credito	C24 - Prestiti/Convenzioni – Servizi online	1
Credito	C25 – Gestione piani di ammortamento	1
Prestazioni Previdenziali	C26 -TFS/TFR - Gestione comunicazioni online da Enti ai fini TFS/TFR	1	• Aumento della percezione della qualità del servizi • Certezza e celerità dei tempi di erogazione dei servizi • Dematerializzazione dei documenti cartacei • Efficacia, efficienza ed economicità dell'azione amministrativa • Facilità di accesso e semplicità di utilizzo dei servizi offerti • Incremento della qualità del servizio percepita dall’utente • Miglioramento dell’accessibilità delle applicazioni per tutte le categorie di utenti • Miglioramento della qualità dei servizi erogati • Semplificazione dell’accesso ai	% incremento erogazione prestazioni
Prestazioni Previdenziali	C27 - TFS/TFR - Gestione riliquidazioni d’ufficio	1
Prestazioni Previdenziali	C28 - Previdenza Complementare - Gestione riscatti dal Fondo	1
Prestazioni Previdenziali	C29 - TFS - Gestione cessione TFS	1
Prestazioni Previdenziali	C30 - Riscatti ai fini TFS/TFR - Istanze di esonero, anticipata estinzione, rinuncia di riscatti	1
Prestazioni Previdenziali	C31 - Riscatti ai fini TFS/TFR - Acquisizione massiva domande riscatto ai fini TFS/TFR da Enti	1
Prestazioni Previdenziali	C32 -TFR/TFS - Gestione processo per la gestione della mobilità in ingresso	1
Prestazioni Previdenziali	C33 - TFR/TFS - Gestione ricongiunzioni non onerose ai fini TFS/TFR	1
Prestazioni Previdenziali	C34 - Previdenza Complementare - Ripartizione onere ritardato conferimento tra Ente e Istituto	1
Prestazioni Previdenziali	C35 - Previdenza Complementare - Registrazione dei flussi inviati ai Fondi	1

Area Applicativa

Titolo Progetto / Ambito e Obiettivo

Priorità

Benefici

Metrica

Prestazioni

Previdenziali

C36 - Previdenza Complementare - Gestione

Recupero crediti da Fondo

servizi

• Semplificazione, efficienza ed ottimizzazione nei processi

Prestazioni Previdenziali

C37 – Evoluzione per la certificazione delle informazioni necessarie per l’erogazione delle

prestazioni di propria competenza

Allegato 2 – Figure Professionali

2.8. Figure di Gestione Progetti e Programma.

Responsabile Coordinamento

(Program Manager)

Titolo di Studio

Laurea in discipline economico-gestionali o cultura equivalente

Esperienze Lavorative

• Anzianità lavorativa di almeno 12 anni con esperienze nel settore pubblico, ed in particolare nella Pubblica Amministrazione Centrale

• Almeno 8 anni di provata esperienza consulenziale con specifico riferimento a processi organizzativi

• Provata esperienza di consulenza strategica su temi relativi la definizione della mission, la definizione di piani strategici ed in particolare il disegnodi scenari alternativi, lo sviluppo di business case

• Capacità di unire sinergicamente componenti organizzative, normative, di processo e tecnologiche, con l’obiettivo di indirizzare soluzioni avanzate erealmente efficaci

• Esperienze e competenze rilevanti per la definizione di strategie IT, evidenziando capacità di focalizzazione sugli obiettivi strategici e di disegno di un percorso di informatizzazione innovativo e ad alto valore aggiunto

Conoscenze

• Approfondita conoscenza del settore della Pubblica Amministrazione italiana e in particolare del contesto degli Enti Previdenziali

• Provata esperienza di almeno 2 anni di Consulenza su temi relativi alle procedure inerenti l’ambito operativo del committente,

• Approfondita conoscenza ed uso di tecniche di Program Management e risk management, nonché di assicurazione e controllo qualità sui progetti.

• Ottime capacità relazionali

Capo Progetto (Project

Manager)

Titolo di Studio

Laurea in discipline scientifiche o cultura equivalente

Esperienze Lavorative

• Minimo 12 anni, di cui almeno 4 nella funzione

• Redazione di documentazione di progetto

• Controllo realizzazione procedure

• Stima di risorse per realizzazione di progetto

• Stima di tempi e pianificazione attività

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

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

• Responsabilità e coordinamento di gruppi di progetto

Conoscenze

• Approfondita conoscenza del settore della Pubblica Amministrazione italiana e in particolare del contesto degli Enti Previdenziali

• Conoscenza del Software Configuration Management (SCM), Application Lifecycle Management (ALM) e Software Development Lifecycle (SDLC)

• Metodologie di sviluppo (gestionale, siti web)

• Ottima conoscenza della Legge n°4/2004

• Tecnica di misura funzionale progetti: Punti Funzione –International Function Point User Group (IFPUG)

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

• Tematiche applicative gestionali preferibilmente in ambito Pubblica Amministrazione

• Autorevolezza e comprovata esperienza pluriennale in progetti di grandi dimensioni

• Ottime capacità relazionali

• Buona conoscenza di applicazioni, sistemi, linguaggi

2.9. Figure per l’analisi e lo sviluppo

Analista Funzionale

Titolo di Studio

Laurea in discipline tecniche o cultura equivalente

Esperienze:

Esperienze Lavorative

• Minimo 8 anni, di cui almeno 4 come analista

•

• Redazione di documentazione di progetto

• Controllo realizzazione procedure

• Stima di risorse per lo sviluppo di software

• Stima di tempi e pianificazione attività

• Coordinamento di gruppi di lavoro

• Disegno e progettazione di test

Conoscenze

• Approfondita conoscenza del Software Configuration Management (SCM), Application Lifecycle Management (ALM) e Software Development Lifecycle (SDLC)

• Buona conoscenza del settore della Pubblica Amministrazione italiana e in particolare del contesto degli Enti Previdenziali

• Tecnica di misura funzionale progetti: Punti Funzione –International Function Point User Group (IFPUG), Certificazione IFPUG o equivalente a norma ISO

• Metodologie di analisi di prodotti SW (gestionale, siti web)

• Metodologie e tecniche di test

• Metodologie di disegno di prodotti SW (gestionale, siti web)

• Tecniche di controllo di progetto

• Ottime capacità relazionali

• Ottima conoscenza della Legge n° 4/2004 e sue implicazioni

• Tecniche di programmazione strutturata

• Tecniche di modellazione e integrazione dati

• Metodologia di analisi e disegno Object Oriented con UML

•

• Conoscenza dei procedimenti amministrativi e delle caratteristiche tecniche e funzionali delle applicazioni informatiche

nell’ambito dell Pubblica amministrazione, con particolare

riferimento alle applicazioni previdenziali

• Buona conoscenza delle piattaforme Microsoft e dell’ambiente Java

• Ottima conoscenza di editor Html e della suite Adobe

• Buona Conoscenza delle principali piattaforme di sviluppo e dei linguaggi di programmazione più evoluti (C, C++, Java, ecc.) con particolare attenzione a piattaforme e linguaggi di riferimento per l’Istituto (cfr. Capitolo 4).

• Buona conoscenza di SQL Server

• Buona conoscenza delle architetture SOA

• Buona conoscenza della piattaforma J2EE

• Application Server IBM Websphere

• Esperto web designer (analisi)

• Buona conoscenza di applicazioni, sistemi, linguaggi OpenSource

• Buona conoscenza di Content Management System, con capacità a individuare la soluzione migliore per le implementazioni;

• Buona conoscenza della suite di Office Automation Microsoft

•

• Buona conoscenza di prodotti specifici per analisi e statistiche dei siti WEB

• Buona conoscenza di prodotti per la realizzazione di reportistica

Analista Programmatore

Titolo di Studio

Laurea o Diploma

Esperienze Lavorative

Minimo 4 anni come programmatore e 2 nella funzione

• Coordinamento di piccoli gruppi di lavoro

• Verifica della corretta applicazione di metodi e standard

• Sviluppo di analisi tecnica di media complessità

• Documentazione procedure

• Preparazione di casi di test

• Esecuzione di test

• Partecipazione a gruppi di progetto di medie/grandi dimensioni

Conoscenze

• Approfondita conoscenza del Software Configuration Management (SCM), Application Lifecycle Management (ALM) e Software Development Lifecycle (SDLC)

• Metodologie di disegno di prodotti software (gestionale, siti web)

• Tecniche di programmazione strutturata

• DBMS relazionali

• Strumenti di modellazione dati

• Tecniche di programmazione Object Oriented

• Buona conoscenza di applicazioni, sistemi, linguaggi

• Sviluppo di applicazioni web in tecnologia ASP, XXX.XXX, J2EE

• Conoscenza della Legge n°4/2004 e sue implicazioni

• Conoscenza della piattaforma Microsoft

• Ottima conoscenza di editor Html e della suite Adobe

• Conoscenza approfondita delle principali piattaforme di sviluppo e dei linguaggi di programmazione più evoluti (C, C++, Java, ecc.) con particolare attenzione a piattaforme e linguaggi di riferimento per

l’Istituto (cfr. Capitolo 4)

• Conoscenza di SQL Server (capacità di creare store procedure, DTS, Job);

• Buona conoscenza delle architetture SOA

• Ottima conoscenza degli Application Server IBM Websphere

• Web designer (grafico)

• Conoscenza di Content Management System

• Microsoft Office

• Conoscenza di prodotti specifici per analisi e statistiche dei siti WEB

• Conoscenza della metodologia UML

Programmatore/Programmatore web
Titolo di Studio	Diploma di perito informatico o diploma analogo
Esperienze Lavorative	• Minimo 2 anni come programmatore • Sviluppo di analisi tecnica di bassa complessità • Esecuzione di test
Conoscenze	• Conoscenza del Software Configuration Management (SCM), Application Lifecycle Management (ALM) e Software Development Lifecycle (SDLC) • Tecniche di programmazione Oject Oriented; • Conoscenze della metodologia UML; • Conoscenze delle piattaforme Unix/Linux; • Conoscenza delle piattaforme Microsoft sia server che client; • Ottima conoscenza di editor Html e della suite Adobe; • dei linguaggi di programmazione più evoluti (C, C++, Java, ecc.) con particolare attenzione ai linguaggi di riferimento per l’Istituto (cfr. Capitolo 4); • Buona conoscenza di SQL, T-SQL, XML; • Conoscenza delle applicazioni per dispositivi Smart Device; • Buona conoscenza ambienti di programmazione ed utilizzo dei prodotti tecnologici: o Microsoft visual studio o IBM RAD • Conoscenza Web designer (grafico) • Conoscenza di Content Management System • Microsoft Office Tools • Conoscenza di prodotti specifici per analisi e statistiche dei siti WEB • Conoscenza della Legge n°4/2004 e sue implicazioni

Istruttore

Titolo di Studio

Diploma di perito informatico

Esperienze Lavorative

• 4 anni di cui almeno 2 nella mansione

• Lavoro di gruppo ed interazione

Conoscenze

• Ambienti operativi Windows;

• Capacità organizzative e di espletamento di seminari con la preparazione e predisposizione del materiale per la formazione

• Conoscenza approfondita dei principali linguaggi di programmazione su tecnologia Microsoft e Java

Specialista di

prodotto/tecnologia

Titolo di Studio

Laurea in discipline tecniche o cultura equivalente

Esperienze Lavorative

• Minimo 8 anni, di cui almeno 3 nella funzione

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

• Progettazione test integrati

• Redazione di specifiche di gestione e procedure

• Redazione di studi di fattibilità ad alto contenuto innovativo

• Stima di risorse per realizzazione attività

• Spiccata attitudine al problem solving

•

Conoscenze

• Metodologie di analisi

Conoscenza dei sistemi e degli ambienti software di riferimento per l’Istituto. (cfr. Capitolo 4)

• Architettura di cooperazione applicativa

• Strumenti MS Office

• Sistemi MS Windows

• Ottima conoscenza sulle piattaforme di sviluppo e sulle architetture

applicative più diffuse (proprietarie e opensource)

• Sistemi Operativi e browser per dispositivi mobili

•

• Capacità di valutazione e individuazione prodotti/tecnologie

• Esperienza di modellazione dei dati e di politiche di sicurezza e integrità del modello

• Conoscenza di metodologie e tecniche standard di sicurezza

Consulente Senior

Titolo di Studio

Laurea in discipline economiche o scientifiche, eventuale specializzazione post-laurea (master o dottorato) in informatica e metodi quantitativi con preferenza per i settori ingegneria informatica.

Esperienze Lavorative

Almeno 8 anni di esperienza su progetti di sviluppo applicazioni software preferibilmente nel settore della Pubblica Amministrazione,

Conoscenze

• Approfondita conoscenza del settore della Pubblica Amministrazion italiana e in particolare del contesto degli Enti Previdenziali.

• Tematiche applicative gestionali preferibilmente nell’ambito della Pubblica Amministrazione

• Autorevolezza e comprovata esperienza in progetti di grandi dimensioni

• Ottime capacità relazionali

• Buona conoscenza di applicazioni, sistemi, linguaggi

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

• Capacità di lavorare in gruppo in realtà dinamiche

• Collaborazione diretta con il personale dell’Istituto e le società terze fornitrici di servizi informatici

• Tecnica di misura funzionale progetti: Punti Funzione –International Function Point User Group (IFPUG),

Conoscenza dei processi per la pianificazione strategica e l’organizzazione

Amministratore Basi Dati

Titolo di Studio

Laurea o diploma

Esperienze Lavorative

• 8 anni di cui almeno 3 nella mansione

• 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

• 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

Esperto Basi Dati

Titolo di Studio

Laurea

Esperienze Lavorative

• 10 anni di cui almeno 4 nella mansione

• Governo delle fasi di caricamento/elaborazione dei dati

• Interpretazione e analisi dei dati, presentazione e discussione degli stessi

• Studio e disegno di sistemi applicativi e di strutture dati.

• Impiego di tecniche avanzate per la gestione di database.

• Controllo e ottimizzazione delle prestazioni del DBMS.

Conoscenze

• Metodologie di analisi dei dati e di progettazione logica e fisica di data base relazionali e object oriented

• implementazione di base dati in sistemi complessi e in sistemi distribuiti

• gestione di problematiche di recovery e sicurezza.

• tecniche avanzate di organizzazione, registrazione e reperimento dati.

Sistemista

Titolo di Studio

Laurea o diploma

Esperienze Lavorative

• 8 anni di cui almeno 5 nella mansione

• Progettazione degli ambienti tecnologici su piattaforme Unix, Linux e Windows

• Installazione, avviamento e gestione delle apparecchiature e dei sistemi di telecomunicazione.

• Tuning e performance dei sistemi e della rete

• Analisi ed individuazione prodotti

• Gestione autonoma di problemi tecnici

• Capacità di definizione e coordinamento per l’auditing dei processi di Test Management

Conoscenze

• Installazione, configurazione e gestione dei WEB server, Application server e DB server.

• Redazione di specifiche di progetto.

• Progettazione test integrati.

• Conoscenza procedure operative di manutenzione ordinaria e straordinaria delle apparecchiature.

• Attitudine al lavoro di gruppo e facilità d’interazione.

• Installazione, personalizzazione e gestione del sistema operativo UNIX(AIX , SUN, BULL), Windows 2003, Windows 2000.

• Realizzazione ed analisi risultati di test da eseguire relativamente ad ogni singolo requisito utente espresso, in stretta collaborazione con il Management del Servizio.

• Comprovata esperienza nella progettazione, tuning e configurazione sui prodotti e le tecnologie in uso presso l’Istituto.

• Comprovata capacità operativa di conduzione e gestione di server e piattaforme HW, SW, TLC presenti in Istituto.

Operatore Help Desk applicativo

Titolo di Studio

Diploma di scuola media superiore

Esperienze Lavorative

• Almeno 4 anni di cui almeno 2 nella mansione

• Risoluzione diretta di richieste di assistenza più semplici e Attivazione di strutture specialistiche appropriate nel caso di problemi non risolvibili direttamante

Conoscenze

• Ambiente applicativo dell’Istituto

• Contesto organizzativo dell’Istituto

Allegato 3 - Requisiti specifici per le applicazioni ed i prodotti realizzati

Si evidenziano i seguenti requisiti specifici e imprescindibili che devono caratterizzare il servizio di Sviluppo e Mev di Software ad hoc ed i prodotti realizzati (esempio: pagine HTML, ecc.):

▪ accessibilità da parte dei soggetti diversamente abili: la legge n. 4 del 9 gennaio 2004 “Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici” e successive modifiche, prevede che le Pubbliche Amministrazioni non possano stipulare, a pena di nullità, contratti per la realizzazione e la modifica di servizi applicativi Internet

quando non è previsto che essi siano conformi ai requisiti di accessibilità stabiliti dal decreto del Ministro per l’innovazione e le tecnologie dell’8 luglio 2005;

▪ realizzazione di prodotti e servizi web accessibili rispettando i seguenti standard:

1. raccomandazioni del World Wide Web Consortium (W3C): HTTP 1.1, HTML 4.0.1 strict o XHTML (eXtended Hypertext Markup Language) 1.0 strict o XHTML 1.1, e CSS

2.0 e xForms (eXtended Forms);

2. compatibilità con i seguenti browser: Internet Explorer 6.x o superiori, Netscape 6.0/7.0 o superiori, Firefox 2.0 o superiori (obbligatori); Opera 6.0/7.0 o superiori (raccomandato);Jaws e altro browser per soggetti diversamente abili;

3. standard per l’accesso sicuro a pagine web: SSL 2.0 (obbligatorio) e SSL 3.0 (opzionale).

▪ compatibilità con i seguenti standard di gestione dei contenuti :

1. JSR 168 (specifica dei “portlet”);

2. JSR 170 (API standard per accedere ai servizi di un sistema di Gestione Contenuti Web);

3. WSRP 1.0 (Web Services for Remote Portlet);

▪ compatibilità con i seguenti standard relativi ai formati di descrizione dei contenuti:

1. XML (Extensible Markup Language, vedi xxxx://xxx.x0.xxx/XXX/), RDF (Resource Description Framework, vedi xxxx://xxx.x0.xxx/XXX/) e RSS (Really Simple Syndication);

2. PRISM (Publishing Requirements for Industry Standard Metadata, vedi xxxx://xxx.xxxxxxxxxxxxx.xxx/);

3. XMP (Extensible Metadata Platform, creato da Adobe);

▪ compatibilità con i seguenti standard internazionali e successivi:

1. ISO 9241-11, ISO 9126-4: effectiveness, efficiency, (safety), satisfaction;

2. ISO 20282-2: Usability of every day products.

Inoltre tutte le componenti applicative che prevedono un’interazione con i Sistemi Informativi di altre Amministrazioni dovranno essere realizzate rispettando gli standard previsti dal Sistema Pubblico di Connettività per la cooperazione applicativa (SPC) e con caratteristiche che possano agevolare il riutilizzo anche da parte di altre amministrazioni pubbliche.

Allegato 4 - Strumenti per la misura della qualità del sw

Nel corso degli ultimi anni l'Istituto ha realizzato una piattaforma di analisi metrica e qualitativa del software attraverso i prodotti della “CAST Software”. Questa piattaforma permette di analizzare l'intero patrimonio del software custom sviluppato per l'Istituto in termini sia quantitativi (dati volumetrici sugli oggetti sorgenti: LOC, Backfired Function Points) che qualitativi secondo metriche ed indicatori di qualità internazionalmente riconosciuti da standards come l’International Standards Organization (ISO 9126-2) ed enti internazionali come SEI (Software Engineering Institute), il Center for Software Engineering, l’Institute of Electrical and Electronics Engineers (IEEE). Le citate organizzazioni hanno definito delle metriche per rendere “oggettivamente misurabile” la qualità di un software, misure note anche come Application Health Factors che includono: Trasferibilità, Modificabilità, Robustezza (Stabilità e Testabilità), Performance, Sicurezza, Manutenibilità, Technical Size e Peso Funzionale.

Attraverso questa piattaforma è possibile seguire la qualità del software sviluppato durante tutto il ciclo di vita dell'applicazione: dallo sviluppo alla messa in produzione e durante la manutenzione, fino alla sua messa in dismissione.

Obiettivo dell'Istituto è quello di mettere a disposizione la piattaforma di analisi qualitativa del software e le proprie conoscenze acquisite in questi anni, al fine di monitorare e migliorare progressivamente la qualità delle forniture software secondo metriche ed indicatori generali e/o specifici per ogni tecnologia di sviluppo (Java, XX.Xxx, etc..).

A tal fine le imprese/RTI aggiudicatarie, durante l'intero periodo di fornitura e in corrispondenza di ogni rilascio di una nuova release o di un pacchetto di modifica (Change request), e durante il collaudo della stessa, dovranno sottoporre ad analisi preventiva di qualità i prodotti rilasciati, finalizzata anche all’individuazione della violazione di Best Practice più comuni specifiche delle corrispondenti tecnologie.

La piattaforma, attraverso un cruscotto (dashboard) personalizzato rispetto alle applicazioni gestite, permettere un monitoraggio e una autodiagnosi continua dei prodotti rilasciati direttamente dagli sviluppatori.

La piattaforma permette inoltre di acquisire la conoscenza dell’applicazione poiché attraverso strumenti di analisi anche Cross Application e Cross Platform è in grado di fornire una conoscenza dettagliata sulla struttura interna dei componenti di tutto il parco applicativo e sulle relazioni che intercorrono tra essi, cosiddetta Application Mining, utile sia nella fase di presa in carico dell’applicazione da mantenere sia per il reverse engineering.

Il sistema di Application Intelligence realizzato, è integrato con l’infrastruttura centralizzata di Software configuration management che gestisce centralmente il ciclo di vita delle applicazioni custom sviluppate in Istittuto.

Il processo di integrazione realizzato avviene seguendo il criterio di intercettazione dei pacchetti software rilasciati in ambiente di Esercizio.

L’infrastruttura di integrazione facilita notevolmente la produzione dei deliverable di qualità e quantità realizzati attraverso la componente di analisi di CAST, poiché permette di raggiungere obiettivi quali:

• Visibilità proattive dei fattori di rischio, che permettono di evitare criticità ai sistemi che possono minare gli obiettivi e l’immagine dell’Istituto;

• Il repository dell’anagrafica Cast viene incrementato in modo sincrono all’aggiunta di una nuova applicazione, evitando la manualità delle operazioni;

• Analisi automatizzata del software: i processi di analisi e di calcolo metrico possono essere schedulati in periodi a bassa criticità, eliminando i disservizi all’utenza;

• Con una gestione trasparente viene mitigato il richio di lock-in dell’outsourcing;

• Razionalizzazione dei cicli di sviluppo e delivery: le statistiche sulla movimentazione del software possono fornire dati utili ad intraprendere azioni correttive sull’allocazione delle risorse;

• Minori rework, più riutilizzo, e applicazioni più robuste;

• L’acquisizione automatica del software modificato dall’infrastruttura di Change Management non deve essere eseguita manualmente dall’utente ma viene innescato in automatico da processi batch con un notevole risparmio di risorse e tempo;

• Produzione dei risultati di qualità, quantità ed effort del sw in gestione;

• Generazione automatica di snapshot fruibili dalla dashboard;

• Report prodotti in automatico nei formati standard di mercato (html, xml, pdf);

• L’integrazione dei dati provenienti dall’infrastruttura di ALM (numero di rilasci, gruppi applicativi, ecc…) con i dati di qualità e quantità derivanti dall’analisi con Cast danno una visione completa dello scenario applicativo a tutte le figure coinvolte dal management ai team di sviluppo.

Di seguito sono delineate le best practice e metriche di qualità che verranno misurate attraverso la piattaforma:

Best practice comuni a tutte le tecnologie

• La densità dei commenti deve essere in percentuale maggiore al 5% rispetto al codice sorgente.

• La percentuale delle linee di codice commentate deve essere in percentuale minore del 2% rispetto al codice sorgente.

• Depth of Code non superiore a 5: ovvero la profondità del codice che è misurato come il numero massimo di istruzioni di controllo nidificato in un artefatto; ad esempio un artefatto che contiene un IF che a sua volta contiene un ciclo While e che a sua volta contiene un altro IF avrà una profondità di 3.

• La complessità ciclomatica per gli artefatti non dovrà superare il valore 20 (tale metrica va applicata per tutte le tecnologie). La complessità ciclomatica è data dalla misura della complessità della struttura di un artefatto quantificata dal numero di percorsi linearmente indipendenti calcolati nell'esecuzione del software;

• Dead code (codice inerte) raggruppa una serie di metriche che vanno ad individuare a seconda della singola tecnologia quali sono gli elementi che seppur definiti nel codice sorgente, non vengono utilizzati.

Best practice di qualità distinte per principali tecnologie in uso presso l’Istituto Specifiche per la tecnologia SQL Server

• Evitare che le tabelle vengano accedute via codice, ma solo da Stored Procedure;

• I trigger non dovrebbero essere ricorsivi;

• Non è tollerata una percentuale di Funzioni, Stored Procedure con Elevata Complessità di integrazione superiore al 10%. La soglia attuale che definisce una complessità elevata è 2;

• Evitare gli statement “select *”;

• Evitare che le stored procedure effettuino una insert/delete/update sulle tabelle all’esterno di una transazione;

• Evitare l’uso dello statement truncate;

• Evitare l’uso degli oggetti temporanei;

• Evitare l’uso del GOTO;

• Evitare che le stored procedure effettuino una insert/delete/update sulle tabelle senza una gestione dell’errore;

• Le stored procedure devono restituire un codice di stato (return code);

• Le stored procedure/funzioni non dovrebbero avere una complessità ciclomatica superiore a 20 in misura percentuale superiore al 20% del codice complessivo;

• Evitare di effettuare query su più di 4 tabelle contemporaneamente;

• Evitare di creare StoredProcedure/Funzioni con subquery;

Specifiche per la tecnologia ASP

• Non è tollerata una percentuale di oggetti ASP (funzioni, file, property, event, etc.) con Elevata Complessità di integrazione superiore al 10%. La soglia attuale che definisce una complessità elevata è 20;

• Gli oggetti ASP (funzioni, file, property, event, etc.), non devono avere una complessità ciclomatica superiore a 20 in misura percentuale superiore al 20% del codice complessivo.;

• Evitare pagine asp con più di 1000 righe di codice;

• Le estensioni dei file devono rientrare nel seguente elenco: .asp, .asa, .html, .htm, .inc;

Specifiche per la tecnologia .NET

• Le pagine .NET dovrebbero accedere alle Stored Procedure invece che alle tabelle;

• Evitare che una classe implementi più di 7 interfacce.

• Non è tollerata una percentuale di artifact con Elevata Complessità di integrazione superiore al 10%. La soglia attuale che definisce una complessità elevata è 20;

• Evitare di creare classi con un numero di figli superiore a 3;

• Evitare metodi con più di 100 righe di codice;

• Evitare che le classi abbiano piu’ di 30 metodi;

• Evitare che le classi abbiano piu’ di 4 costruttori;

• Evitare l’uso di public class fields;

• Evitare l’accesso alle tabelle (preferibile la chiamata alle stored procedure);

• Non è tollerata una percentuale di artifact (preferibile la chiamata alle stored procedure);

• Evitare di istanziare variabili senza dichiararne il tipo;

• Evitare l’uso dell’istruzione string.empty;

• Evitare di costruire classi con una profondità dell’albero di ereditarietà superiore a 4;

Specifiche per la tecnologia JAVA

• Evitare che una classe implementi più di 7 interfacce;

• Evitare l’override di metodi statici;

• Evitare l’override degli attributi di una classe;

• Non creare classi che ereditino da java.lang.Throwable;

• Evitare di creare classi con un numero di figli superiore a 3;

• Evitare che le classi abbiano un numero di metodi superiore a 30;

• Evitare che le classi abbiano un numero di attributi superiore a 30.

• Evitare che le classi abbiano più di 4 costruttori;

• Evitare che i metodi abbiano piu’ di 100 righe di codice;

• Evitare statement catch vuoti;

• Dichiarare tutte le classi di eccezioni che un metodo può sollevare;

• Evitare di omettere il default in uno switch case;

• Evitare l’uso di oggetti deprecati;

• Non è tollerata una percentuale di artefatti con una complessità di integrazione superiore al 10%;La soglia attuale che definisce una complessità elevata è 20;

• Non è tollerata una percentuale di artefatti con una complessità ciclomatica superiore a 20Evitare l’uso della system.gc;

• Evitare l’uso del vector;

• Evitare l’uso della system.err e della system.out;

• Evitare l’uso della system.printstacktrace;

• Evitare la costruzione di classi con una profondità dell’albero di ereditarietà superiore a 4;

Obiettivo dell’Istituto è migliorare progressivamente la qualità del proprio software anche attraverso il miglioramento degli indicatori sopra menzionati, indicatori basati su misure effettivamente eseguite sul software rilasciato.

Pertanto, per le applicazioni già sviluppate e da manutenere il fornitore dovrà migliorare progressivamente i livelli degli indicatori corrispondenti e misurati al momento della presa in carico

(snapshot di riferimento). Al fornitore è data facoltà di prevedere SLA aggiuntivi per un miglioramento di tali indicatori da ottenere durante la fornitura.

Per le nuove applicazioni da sviluppare il livello degli indicatori sarà dato dalla media per la singola tecnologia di sviluppo.

Allegato 5 – Dettagli per il Calcolo dei Livelli di Qualità

Di seguito si riporta per alcuni Livelli di Qualità un dettaglio delle formule per il calcolo

Scostamento dei tempi di esecuzione dell’Intervento
Caratteristica	Rispetto dei tempi e dei costi di realizzazione	Sottocaratteristica	Scostamento dei tempi di completamento intervento e/o consegna prodotti
Aspetto da valutare	Slittamento della fine effettiva dell’intervento (data di accettazione) rispetto a quella concordata nell’ultima pianificazione, partendo dalla data di attivazione, per cause imputabili al fornitore.
Unità di misura	Xxxxxx lavorativi	Fonte dati	Piano di progetto
Periodo di riferimento	Durata dell’intervento	Frequenza di misurazione	Dopo il termine dell'obiettivo
Dati da rilevare	• Data di accettazione (Data_accett) • Data di accettazione prevista dall'ultimo Piano di Progetto approvato (Data_pian_accett) • Data di completamento (Data_compl)
Regole di campionament o	nessuna
Formula	IQ= (Data _ accett) −(Data_pian_accett −)
Regole di arrotondamento	nessuna
Valore di soglia	%
Azioni contrattuali	Penali associate: Penali su Collaudo
Eccezioni	Nessuna

Scostamento costi di esecuzione dell’Intervento
Caratteristica	Rispetto dei tempi e dei costi di realizzazione	Sottocaratteristica	Scostamento dei costi di completamento intervento e/o consegna prodotti
Aspetto da valutare	Superamento del costo complessivo dell’intervento stimato nell’ultima pianificazione concordata rispetto a quello consuntivato per cause imputabili al fornitore.
Unità di misura	Punti Funzione	Fonte dati	Piano di progetto

Periodo di riferimento	Durata dell’intervento	Frequenza di misurazione	Dopo il termine dell'obiettivo
Dati da rilevare	• Punti Funzione stimati come da scheda attività di prodotto (Punti_Funzione_stimati) • Punti Funzione consuntivati come da Piano di progetto (Punti_Funzione_consunt)
Regole di campionament o	Nessuna
Formula	IQ= (Punti_Funzione_consunt - Punti_Funzione_stimati)
Regole di arrotondamento	Nessuna
Valore di soglia	≤5% dei punti funzione stimati
Azioni contrattuali	N.a.
Eccezioni	Nessuna

Densità dei commenti del software sviluppato
Caratteristica	Manutenibilità	Sottocaratteristica	Leggibilità
Aspetto da valutare	Densità dei commenti del software sviluppato in linguaggio Java/
Unità di misura	Punto percentuale	Fonte dati	Cast
Periodo di Riferimento	La durata della fase di realizzazione	Frequenza di misurazione	Una volta (Al termine del periodo di riferimento)
Dati da rilevare	• Numero di linee di codice del singolo modulo nuovo (Nloc) • Numero di linee di commento del singolo modulo nuovo (Ncomm Per il linguaggio Java si conteggeranno come commenti solo quelli inseriti all’interno del modulo
Regole di campionamento	Vanno considerati tutti i moduli software nuovi dell’obiettivo scritti in linguaggio Java
Formula	Ncomm / Nloc
Regole di arrotondamento	Il risultato della misura va arrotondato: - per difetto se la prima cifra decimale è ≤ 0,5 - per eccesso se la prima cifra decimale è > 0,5
Valore di soglia	>5%
Azioni contrattuali	Cfr. Penali
Eccezioni	Nessuna

Document Metadata

Table of Contents

Contract

Document Metadata