CAPITOLATO TECNICO UIRNET S.P.A.

Transcript

1 UIRNET S.P.A. MODULI APPLICATIVI INTEGRATI CON LA PIATTAFORMA LOGISTICA NAZIONALE (PLN) A SUPPORTO DELL OPERATIVITA DEI NODI LOGISTICI (SOLUTION CORE) CUP G50C Procedura aperta: art. 3, comma 37 e art. 55, comma 5, Decreto Legislativo n. 163/2006 e Parte IV del D.P.R. n. 207/2010; criterio di aggiudicazione: offerta economicamente più vantaggiosa, ai sensi dell art. 83 del Decreto Legislativo n. 163/2006 CAPITOLATO TECNICO Prot. n del 03_12_2013

2 SOMMARIO 1 INTRODUZIONE CONTESTO DI RIFERIMENTO REQUISITI FUNZIONALI Descrizione e obiettivi Modulo 1: Gestione anagrafica autisti Descrizione Anagrafica degli autisti Richieste di permesso di accesso presso i nodi logistici Gestione delle richieste di accesso da parte dei Nodi Logistici Integrazione con la PLN Modulo 2: Nodo logistico integrato Descrizione Integrazione con la PLN Modulo 3: Gestione eventi in sicurezza Descrizione Integrazione con la PLN Altri elementi di interscambio e di integrazione con la PLN Funzionalità di supporto Successive integrazioni con la PLN REQUISITI TECNOLOGICI Architettura software Caratteristiche salienti dei servizi back end Sviluppo software Linguaggio di programmazione Lavoro del gruppo di sviluppo software Rispondenza allo standard ARTIST Scalabilità per evoluzione delle performance hardware Utilizzo di soluzioni Open Source Interfaccia uomo/sistema Sicurezza pag 2

3 4.5 Compatibilità con hardware e software di base della PLN Erogazione di servizio hosting nel corso della Fase di Gestione REQUISITI DIMENSIONALI E PRESTAZIONALI Modulo Modulo 2 e Modulo ESECUZIONE PROGETTUALE Trasversale: Processo di Gestione Progettuale Obiettivi Attivazione del processo Attività e prodotti Pianificazione del progetto Pianificazione delle comunicazioni Pianificazione della qualità Esecuzione del progetto Controllo del progetto Revisione, riesame e valutazione Definizione dell infrastruttura Manutenzione dell infrastruttura Definizione dei processi Valutazione dei processi Miglioramento dei processi Definizione delle esigenze. Piano della Formazione Sviluppo del materiale di formazione Esecuzione della formazione Conclusione del progetto Chiusura del processo Trasversale: Processo di Documentazione Obiettivi Attivazione del processo Attività e prodotti Pianificazione Progettazione e sviluppo Distribuzione e conservazione Manutenzione Chiusura del processo Trasversale: Processo di Assicurazione Qualità Obiettivi Attivazione del processo Attività e prodotti Pianificazione Assicurazione qualità Verifica Validazione Riesame congiunto Verifica ispettiva pag 3

4 Risoluzione dei problemi Chiusura del processo Implementazione: Processo di Progettazione Obiettivi Attivazione del processo Attività e prodotti Analisi dei Requisiti Progettazione Tecnica Progettazione Applicativa Progettazione Test e Collaudi Chiusura del processo Approfondimento dei contenuti e delle modalità del Processo Implementazione: Processo di Realizzazione e Collaudo Obiettivi Attivazione del processo Attività e prodotti Codifica Predisposizione del sistema Produzione della documentazione Qualificazione finale Installazione Collaudo Avviamento alla gestione operativa Chiusura del processo Gestione: Processo di Gestione operativa Obiettivi Attivazione del processo Attività e prodotti Prove delle forniture rilasciate in esercizio Gestione Operativa Assistenza agli utenti Chiusura del processo Gestione: Processo di Manutenzione Manutenzione MAC Obiettivi Attivazione del processo Attività e prodotti Analisi delle modifiche Esecuzione delle modifiche Riesame/Accettazione delle modifiche Migrazione Dismissione Chiusura del processo Manutenzione Evolutiva (MEV) Trasversale: Processo di Gestione della Configurazione Obiettivi Attivazione del processo Attività e prodotti Pianificazione Identificazione della configurazione Controllo della configurazione Registrazione dello stato della configurazione pag 4

5 6.8.8 Rilascio e consegna Chiusura del processo TEMPI E LUOGHI DEL PROGETTO DEFINIZIONE DEL SERVIZIO Servizi e copertura dei processi previsti Breve descrizione dei servizi Servizio SSW Sviluppo e MEV di software ad hoc Servizio GSI Gestione Sistemi Servizio ASS Assistenza in locale e remoto Servizio MAC Manutenzione Adeguativa e Correttiva Servizio PGE Gestione e Processi Organizzativi Servizio FOR Formazione e Istruzione Servizio PGC Gestione della Configurazione Servizio PGD Gestione della Documentazione Servizio PAQ Assicurazione della Qualità Composizione dei gruppi di lavoro Indice di produttività Caratteristiche del Gruppo di Lavoro del Committente Caratteristiche del Gruppo di Lavoro del Prestatore Curricula delle Figure Professionali Livello delle risorse impiegate nelle attività Altri obblighi del Prestatore Rispetto delle normative vigenti Custodia Esecuzione di prove, test, omologazioni Varianti ed espansioni Proprietà dei dati Esonero di responsabilità e trasferimento dei rischi Dimensionamento del Servizio Servizio SSW Progettazione Servizio SSW Sviluppo Servizio GSI Conduzione del sistema Servizio ASS Assistenza agli utenti Servizio MEV Manutenzione Evolutiva Servizio MAC Manutenzione adattativa e correttiva Servizio PGE Gestione generale del progetto Servizio FOR Formazione Servizio PGC Configurazione del sistema Servizio PGD Progettazione della documentazione Servizio PAQ Assicurazione della Qualità Tabella di sintesi del servizio ELEMENTI DI QUALITA Elementi qualitativi di base pag 5

6 9.1.1 Rispetto della scadenza contrattuale Rispetto degli standard documentali Elementi qualitativi rispetto al servizio SSW (Sviluppo software ad hoc e Manutenzione Evolutiva) Dimensione in Punti Funzione Densità del test rispetto alla dimensione del software Tempo medio di risposta Livello di documentazione Efficienza di rimozione errori Elementi qualitativi rispetto al servizio GSI (Gestione Sistemi) Correttezza delle esecuzioni delle attività Disponibilità del sistema Elementi qualitativi rispetto al servizio ASS (Assistenza in remoto e locale) Completezza dei dati raccolti Reclami riguardanti il servizio di contatto Elementi qualitativi rispetto al servizio MAC (Manutenzione adeguativa e correttiva) Tasso di backlog Efficienza di rimozione errori Elementi qualitativi rispetto al Servizio PGE (Gestione del Progetto) Turnover dei ruoli chiave Affiancamento dei ruoli chiave Elementi qualitativi del servizio FOR (Formazione) Efficacia del materiale didattico Efficacia didattica del docente Accettazione del corso Elementi qualitativi rispetto al servizio PGD (Gestione Documentale) Sicurezza dei documenti Elementi qualitativi del servizio PGC (Gestione della Configurazione) Correttezza dell aggiornamento della configurazione Completezza dell aggiornamento della configurazione Tabella riassuntiva VALUTAZIONE DELL OFFERTA Criteri di valutazione Offerta tecnica (elementi di natura qualitativa) Offerta economica (elementi di natura quantitativa) Contenuto dell offerta e griglia di valutazione Interpretazione dei calcoli per le offerte pag 6

7 1 INTRODUZIONE La procedura di gara Solution Core ha lo scopo di istituire una Anagrafica Nazionale Autisti e di dotare i Nodi Logistici italiani di Moduli Applicativi a supporto della loro operatività realizzando l integrazione dei medesimi con la Piattaforma Logistica Nazionale della quale si dirà al successivo capitolo 2 (nel seguito PLN o Piattaforma). Il presente documento costituisce il Capitolato Tecnico e definisce i requisiti relativi all oggetto del servizio richiesto oltre che le modalità di redazione, di presentazione e di valutazione delle Offerte. Si precisa che l oggetto della procedura di gara, indetta ai sensi dell art. 55, comma 5, del D.Lgs. n. 163/2006, è suddiviso in due componenti: Componente principale e obbligatoria: prevede la realizzazione di Moduli software; l erogazione di Servizi comprendenti, tra l altro, la successiva gestione di quanto implementato e la contestuale assistenza agli Utenti; la manutenzione evolutiva dei Moduli software nel corso del periodo di gestione; Componente opzionale: prevede l eventuale successiva integrazione dei Moduli software (di cui al precedente punto) con la PLN attraverso l Enterprise Service Bus e l interoperabilità applicativa con un sistema di Identity and Access Management. pag 7

8 2 CONTESTO DI RIFERIMENTO UIRNet S.p.A. (di seguito, per brevità, UIRNet) ai sensi dell art. 61 bis della Legge 24 marzo 2012 n. 228, è soggetto attuatore unico del Ministero delle Infrastrutture e dei Trasporti per la realizzazione e la gestione della Piattaforma per la gestione della rete logistica nazionale. Detta Piattaforma, definita nelle sue caratteristiche fondamentali dal D.M. n. 18 T del 20 giugno 2005, è stata istituita con l obiettivo di migliorare l efficienza e la sicurezza del trasporto merci e della logistica in Italia, favorendo l interconnessione dei Nodi di interscambio modale. UIRNet fornisce servizi info-telematici per migliorare l organizzazione delle attività di trasporto merci, per migliorare i processi di logistica integrata, per fornire servizi in tempo reale per le aziende e per chi viaggia con particolare attenzione alle problematiche connesse alla sicurezza. Più in generale, UIRNet realizza la messa in opera di un ITS integrato, unico nel suo genere, in grado di erogare servizi specifici destinati ai soggetti pubblici e privati coinvolti nella catena - anche intermodale - del trasporto e della logistica industriale. La PLN, infatti, mette in rete diversi attori (trasportatori; aziende di logistica; gestori di interporti, porti, centri e infrastrutture logistiche; aziende produttive, istituzioni), permettendo di integrare la loro operatività in modo intelligente. Il progetto di realizzazione della PLN nasce dalla necessità di iniziare a considerare la rete logistica nazionale, ad oggi molto frammentata, come un insieme unitario di Nodi interconnessi tra loro. Per realizzare tale interconnessione, i Nodi della rete devono essere opportunamente infrastrutturati, con interventi materiali ed immateriali che migliorino l efficienza e la sicurezza dell operatività interna ed esterna: Infrastrutture Fisiche Infrastrutture immateriali Focus interno Varchi di accesso, sistemi di security perimetrale, sistemi di videosorveglianza, connettività su fibra per le comunicazioni interne, ecc. Sistemi di controllo degli accessi, sistemi di gestione intelligente dei piazzali e dei terminal, sistemi di controllo del traffico interno, ERP, ecc. Focus esterno Collegamenti con gli archi stradali e con gli archi ferroviari, banchine attrezzate, connessioni alle WAN in banda larga, ecc. Sistemi di gestione degli arrivi, sistemi di gestione delle code in ingresso, sistemi di prenotazione di servizi, sistemi di interazione con i flussi, ecc. Per realizzare una gestione virtuosa della rete logistica nel suo complesso e, quindi, dei Nodi, le infrastrutture di Nodo (interne ed esterne, fisiche ed immateriali) non sono da sole sufficienti. Preliminarmente, è necessaria una sovra-infrastruttura immateriale - la PLN - che, gestita a livello centrale con una visione globale, coordini ed aggreghi tutte le informazioni del Sistema, raccolte dalle infrastrutture appena descritte o dai vettori che viaggiano nella rete, le elabori e le ridistribuisca in maniera intelligente, ricercando un ottimizzazione complessiva per il Sistema. pag 8

9 UIRNet, pertanto, ha i seguenti obiettivi: realizzare la sovra-infrastruttura immateriale, cioè la PLN; infrastrutturare i Nodi Logistici (porti, interporti, centri merce e piastre logistiche); Riguardo al primo obiettivo, i Moduli che raccolgono i servizi di sistema (di base e avanzati) della PLN, attualmente focalizzati sul trasporto su gomma, sono stati completati (per approfondimenti si veda Allegato A) e UIRNet sta avviando la sperimentazione dei propri servizi sui principali Nodi Logistici nazionali. L obiettivo è creare circuiti virtuosi tra i Nodi Logistici e le aziende di autotrasporto. Riguardo al secondo obiettivo, UIRNet ha realizzato in 8 strutture intermodali di Primo Livello (interporti di Bologna, Livorno, Marcianise, Padova, Parma, Rivalta-Scrivia, Verona e Nola) infrastrutture materiali per incrementare la loro sicurezza interna e, segnatamente: sistemi di controllo elettronico degli accessi e di tracciabilità dei percorsi interni all'interporto con modalità sistematica; sistemi di videosorveglianza e videoanalisi e potenziamento della capacità di vigilanza, anche attraverso il rilevamento digitale dei movimenti; sistemi di vigilanza e controllo (attivo e passivo) del perimetro della struttura; sistemi di protezione di "network/siti web e regole di accesso (sistemi finalizzati a proteggere la rete informatica ed i dati da attacchi esterni o dalla perdita accidentale dei dati); sistemi di analisi automatizzati dei contenuti delle unità di trasporto intermodale; sistemi specifici (sistemi di messaggistica con pannelli a messaggio variabili, rete cablata in fibra ottica per le comunicazioni interne). UIRNet, inoltre, dal punto di vista dell infrastrutturazione immateriale e materiale, ha in cantiere ulteriori interventi: la realizzazione di una Anagrafica Nazionale Autisti e l implementazione di una soluzione standard di nodo cooperante con la Piattaforma; l interfacciamento dei sistemi di controllo elettronico degli accessi installati con la Piattaforma; il collegamento dei Nodi Logistici con la rete fissa a banda larga, attraverso la realizzazione dei tratti di ultimo miglio delle reti, ad oggi mancanti od obsoleti; l implementazione di sistemi di security presso ulteriori interporti e porti. pag 9

10 3 REQUISITI FUNZIONALI 3.1 Descrizione e obiettivi UIRNet, con la presente procedura di gara, intende dotarsi di una Anagrafica Nazionale degli Autisti che operano nel trasporto merci su gomma e di una soluzione immateriale standard di Nodo Logistico. Dovranno essere definiti standard tecnologici e realizzate soluzioni informatiche per integrare e migliorare la gestione della logistica all interno dei Nodi Logistici a vantaggio sia dei Responsabili delle strutture - che potranno meglio pianificare, organizzare e controllare le proprie attività interne - sia degli autotrasportatori e delle Aziende di autotrasporto che, a loro volta, potranno usufruire di tali servizi. L oggetto del servizio richiesto consiste nella progettazione, nella realizzazione, nell implementazione, nell attivazione e nella gestione di una soluzione tecnologica che vede il proprio baricentro in specifici Moduli Applicativi di cui si dirà nel prosieguo del presente paragrafo. In particolare, la richiesta del servizio si colloca nella fase di sviluppo della PLN denominata UIRNet Solution il cui l obiettivo primario è la creazione di un flusso informativo continuo e puntuale con i diversi Nodi, attraverso l interoperabilità con la PLN che, a propria volta, fungerà da collettore di dati e di informazioni di interesse sia per i gestori sia per gli utilizzatori di tali infrastrutture. A tal fine dovranno essere individuati standard tecnologici e offerte soluzioni pensate per migliorare ed integrare la gestione della logistica all interno dei nodi a vantaggio sia dei gestori delle infrastrutture, che potranno meglio pianificare, organizzare e controllare le proprie attività interne, che degli autotrasportatori e organizzatori del trasporto che potranno usufruire di tali servizi, indipendentemente dal tipo di Nodo Logistico utilizzato. I Moduli Applicativi dovranno essere entità auto consistenti ma, allo stesso tempo, dovranno scambiare informazioni con la PLN ed essere in essa integrati attraverso le interfacce SOA (Service Oriented Architecture: architettura informatica orientata ai servizi) esposte dagli stessi e dagli altri Moduli Applicativi di quest ultima. Pertanto, i Moduli Applicativi si dovranno configurare come applicazioni cooperanti con gli altri Moduli della PLN e dovranno essere concepiti con la finalità essere aperti, interoperabili, scalabili e facilmente integrabili con i sistemi già in uso presso Nodi e operatori. Per quanto sopra detto, i Moduli Applicativi possono essere sommariamente individuati come segue: Modulo 1 - Gestione Anagrafica Autisti Sistema di gestione della Anagrafica Nazionale degli Autisti, atto a fornire anche in tempo reale le informazioni necessarie a consentire l identificazione degli autotrasportatori e il loro accesso presso le strutture dei Nodi dotate di varco; Modulo 2 - Nodo logistico integrato Sistema di integrazione tra le attività di Nodo e la PLN. In particolare, il Modulo 2 dovrà garantire che i Nodi Logistici siano in grado di integrarsi con la PLN per la pag 10

11 gestione degli spazi, dei servizi, delle operazioni e di tutte le regole che sovrintendono al funzionamento della struttura; Modulo 3 - Gestione Eventi in Sicurezza Sistema di gestione delle informazioni correlato agli eventi che occorrono all esterno ed all interno del Nodo al fine di organizzare l operatività degli stessi, massimizzando l efficienza delle attività e limitando i disagi per gli utenti del nodo in caso di imprevisti. L erogazione del servizio di realizzazione dei Moduli Applicativi, così come di seguito descritta, comprenderà anche un periodo di gestione in esercizio oltre che un periodo, contestuale, di ulteriore sviluppo evolutivo dei Moduli stessi; il tutto concentrato in un arco temporale di almeno sei mesi. 3.2 Modulo 1: Gestione anagrafica autisti Descrizione L obiettivo del Modulo 1 è di costituire uno strumento di gestione delle autorizzazioni di accesso ai varchi di controllo dei Nodi Logistici per gli autisti. Il Modulo è finalizzato a fornire le informazioni necessarie per consentire l accesso degli autotrasportatori presso le strutture dotate di varco permettendo l identificazione, anche automatizzata, degli autisti in ingresso e uscita. L idea progettuale di base è di avere una gestione centralizzata a livello nazionale dell anagrafica autisti in modo da consentire ai Nodi Logistici una gestione semplificata e in piena autonomia del rilascio dei permessi di accesso. Gli utenti del Modulo sono: le aziende di autotrasporto con autisti alle proprie dipendenze; autisti che svolgono attività di lavoro autonomo, prefigurandosi anch essi come aziende di autotrasporto; i Responsabili dei Nodi Logistici; gli addetti al controllo dei varchi. Le prime tre categorie di utenza hanno accesso al Modulo per attività di inserimento e modifica dei dati (cd. utenti abilitati) mentre gli addetti al controllo utilizzano il Modulo per sola attività di consultazione, finalizzata alla verifica dei requisiti che consentono all autista di accedere ai Nodi Logistici. I varchi di accesso possono anche essere automatizzati, con gli addetti al controllo che svolgono attività di supervisione, e il sistema che gestisce l automazione potrà accedere al Modulo 1, al momento dell accesso, per la consultazione delle autorizzazioni che fanno capo all autista. Il processo portante del sistema può essere così esemplificato: 1. le aziende di autotrasporto inseriscono le informazioni relative agli autisti, secondo criteri di competenza; 2. i Nodi Logistici descrivono i criteri a cui è necessario rispondere nel formulare la richiesta di permesso di ingresso; 3. le Aziende di Autotrasportano formulano le richieste di permesso di accesso; pag 11

12 4. i Nodi Logistici, secondo la propria competenza, accettano o respingono le richieste; 5. gli autisti si presentano ai varchi dei Nodi Logistici per l accesso e i Nodi, attraverso l attività diretta di addetti al controllo ovvero tramite sistemi automatizzati, consultano le liste di autorizzazione per consentire ovvero negare l accesso. Pertanto il Modulo Gestione Anagrafica Autisti, abilitato allo scambio informativo con la PLN, deve fornire un sistema completo e centralizzato a livello nazionale che consenta di gestire: i dati identificativi e di riconoscimento degli autisti; la gestione dei requisiti e dei processi di autorizzazione all accesso ai Nodi Logistici; l effettivo accesso presso i Nodi Logistici Anagrafica degli autisti La gestione dell Anagrafica degli Autisti deve fornire la possibilità di: gestire informazioni sul singolo autista, anche straniero (quindi con documenti di riconoscimento e autorizzazione alla guida stranieri), atte a riconoscerlo e autorizzarlo al passaggio di un varco; consentire agli utenti della PLN abilitati alla gestione autisti di inserire, modificare, esportare, cancellare i dati degli autisti di propria pertinenza. Il concetto di pertinenza rileva nel senso che un autista inserito nel Modulo 1 deve sempre essere collegato ad un rapporto di lavoro con una Azienda di autotrasporto, anche se si tratta della propria in quanto lavoratore autonomo; il venir meno di tale legame obbliga l Azienda ad aggiornare il dato, anche prevedendo la cancellazione dell autista dalla anagrafica. Ogni Azienda avrà accesso ai dati pertinenti agli autisti che sono alle proprie dipendenze e non avrà accesso, in alcun caso, a dati diversi da quelli che la riguardano. Pertanto, sarà necessario l inserimento e la gestione dei dati che descrivono l Azienda di autotrasporto sotto il profilo anagrafico, in quanto si tratterà di un elemento di collegamento con gli autisti gestiti in questo ambito. Per quanto concerne gli autisti, le informazioni che li riguardano saranno: di tipo anagrafico (nome, cognome, data di nascita, ecc.); di tipo autorizzativo (patenti, abilitazioni, ecc.); di tipo amministrativo (azienda di appartenenza, ecc.). A livello di interfaccia utente, questa componente del Modulo 1 dovrà essere realizzata in modo che i campi di inserimento e gestione dei dati corrispondano esattamente ed interamente a quelli dei documenti di riconoscimento e/o di abilitazione alla guida dell autista. Inoltre, deve essere realizzata la condizione per cui: sia semplice e rapido il confronto tra un documento (ad esempio presentato dall autista al varco) e la schermata di consultazione ai dati che lo descrivono; le fasi di inserimento e modifica siano semplificate e guidate; l addetto al controllo non dovrà effettuare approfondimenti per comprendere l attinenza tra il dato cartaceo e quello visualizzato quale risultato di ricerca nell ambito del Modulo 1. Pertanto, il Modulo 1 dovrà essere in grado, soprattutto per gli autisti che dispongono di documenti emessi all estero, di offrire soluzioni relative alla traduzione dei campi descrittivi ed alla eventuale traslitterazione di termini. pag 12

13 E da prevedersi la possibilità che il sistema classifichi gli autisti per livelli di sicurezza, ad esempio: Livello 0: Il sistema registra i dati dell autista e non vengono forniti documenti di riscontro; Livello 1: Il sistema registra i dati dell autista e acquisisce copia digitale della patente e/o del libro matricola aziendale; Livello 2: Oltre alle verifiche del livello 1, sono effettuati controlli incrociati con altre basi dati dello Stato italiano utilizzati per la gestione ed il controllo dei dati relativi alle persone ed alle concessioni di guida. Il Modulo 1, infine, deve essere predisposto alla gestione dei dati biometrici di identificazione (ad es. fotografia, impronte digitali, firma digitale ) Richieste di permesso di accesso presso i nodi logistici Gli utenti abilitati sulla PLN alla gestione autisti possono richiedere ai Nodi Logistici registrati sulla PLN il permesso di accesso. Le richieste devono: essere mirate al particolare Nodo Logistico; fornire i dati richiesti dal Nodo Logistico; rispettare le modalità di richiesta dei permessi formulate dal Nodo Logistico. Le richieste, come sopra specificato, si riferiranno sempre agli autisti che sono l unico oggetto delle autorizzazioni; pertanto, la richiesta crea un legame tra l azienda proponente, un autista, il Nodo Logistico e vede come allegato la rispondenza ai dati richiesti. A livello di interfacciamento con l utente, il Modulo 1 dovrà consentire tali operazioni in modalità estremamente semplificate in modo che l azienda di autotrasporto: possa, eventualmente, effettuare la selezione, anche massiva, di autisti da autorizzare con l utilizzo di check mark da apporre su liste; possa, eventualmente, gestire in un unica istanza la servizio dei dati richiesti dal Nodo Logistico, riferendosi a più autisti da autorizzare Gestione delle richieste di accesso da parte dei Nodi Logistici I Responsabili della gestione del Nodo Logistico possono formulare richieste di dati, finalizzati alla qualificazione dell accesso degli autisti, per quanto concerne la propria competenza. Il principio della competenza comporta che un Responsabile di Nodo Logistico avrà la possibilità di gestire, ed anche di consultare, esclusivamente il proprio Nodo Logistico. In senso generale, si tratterà: della previsione di obbligatorietà di informazioni relative all autista; della richiesta di informazioni aggiuntive, correlate a quelle standard; del rispetto dei termini temporali di inoltro e di durata della richiesta; della rispondenza e contestuale accettazione di vincoli e/o limiti, relativi alle operazioni all interno del Nodo Logistico. Riguardo l ultimo punto, occorre considerare che potranno esservi indicazioni specifiche, in merito alla prassi inerente la cd. cessione del viaggio tra aziende di autotrasporto. pag 13

14 Le richieste di accesso formulate dalle aziende di autotrasporto, sulla base dei formulari impostati dal Responsabile del Nodo Logistico, dovranno seguire un iter autorizzativo, non essendo previsto un meccanismo automatico di accettazione anche in caso di sussistenza di tutti gli elementi positivi richiesti. Si prevede che la gestione delle autorizzazioni possa essere basata su un meccanismo di White List (autisti autorizzati) e Black List (autisti respinti) per ogni Nodo Logistico utente del sistema. Sempre secondo il citato principio di pertinenza, ogni Nodo Logistico gestisce le proprie liste in autonomia e può accedere ai dati degli autisti solo se questi hanno fatto richiesta di accesso al Nodo stesso. A livello di interfaccia utente, si tratterà di porre a disposizione del Responsabile dei Nodi due differenti elementi finalizzati: il primo alla realizzazione semplificata e possibilmente guidata di schermate che costituiranno il modulo per la richiesta di autorizzazione all accesso che le aziende di autotrasporto dovranno a propria volta compilare; il Responsabile dovrà avere la possibilità di rendere obbligatori alcuni, se non tutti, i campi di inserimento di base già esistenti nell anagrafica autisti e di altri secondo le proprie esigenze; il secondo, volto alla valutazione delle richieste possibilmente rappresentate come liste, accompagnate da un indice di completamento di quanto obbligatoriamente richiesto; il Responsabile del Nodo dovrà esprimere il proprio responso in maniera semplificata, ad esempio, anche solo apponendo il proprio qualificato check mark Integrazione con la PLN Il Modulo 1 Gestione Anagrafica Autotrasporto deve interfacciarsi con la Piattaforma Logistica Nazionale consentendo l allineamento e/o l aggiornamento di quanto di seguito elencato: dati anagrafici relativi agli autisti, alle aziende di autotrasporto, ai Nodi Logistici; gestione dei rapporti di lavoro tra aziende di trasporto e/o di logistica (partnership); Oltre all interfaccia utente che deve essere intuitiva, immediata, completa e rispettare le linee guida dell interfaccia utente PLN, il Modulo deve offrire un interfaccia SOA per l integrazione con i sistemi di controllo accesso e con altri sistemi di gestione dei dati anagrafici; l interfaccia SOA e l interfaccia utente devono essere funzionalmente equipotenti. 3.3 Modulo 2: Nodo logistico integrato Descrizione L obiettivo del Modulo 2 consiste nel fornire ai Nodi uno strumento atto a gestire la disponibilità dei propri servizi al fine di rendere possibile e agevole programmare operazioni tramite prenotazioni e avvisi di arrivo. Il Modulo sarà fortemente integrato con la PLN al fine di consentire lo scambio delle informazioni necessarie tra gli utenti addetti ai Nodi Logistici e gli utenti addetti al trasporto. Lo strumento deve consentire ad ogni Nodo Logistico di configurare le proprie capacità di servizio e le regole logiche per l accettazione o il diniego delle richieste effettuate dagli utenti. pag 14

15 La PLN, con il modulo Booking, consentirà di formulare richieste di erogazione del servizio (prenotazioni). I Nodi, tramite il Modulo 2, potranno rispondere alle prenotazioni in forma automatica (avendo impostato le regole di gestione della disponibilità e dell accettazione richieste), in forma semiautomatica (demandando a un operatore la decisione finale sulla base delle informazioni di supporto fornite dal sistema) o in forma manuale. Il Modulo deve essere integrato con la Gestione Anagrafica Autisti in maniera tale da poter collegare gli accessi al Nodo per usufruire dei servizi offerti con le autorizzazioni autisti. La progettazione e la realizzazione devono almeno consentire a ogni Responsabile di Nodo Logistico di: configurare i propri servizi: o inserire descrizioni, immagini, categorie di appartenenza, geolocalizzazione, o o o impostare capacità di servizio, orari, regole e modalità di accesso, impostare regole logiche di accettazione del servizio basate per criteri su disponibilità, tipo di richiesta, tipologia di utenza, operazioni da svolgere, impostare la modalità di accettazione delle richieste (automatica, semiautomatica, manuale), gestire e comunicare le capacità di accettazione delle strutture di Nodo (per gate/terminal/magazzino ) e le relative disponibilità (ad es. in termini di finestre di arrivo); recepire dai moduli PLN SmarTruck e Booking le missioni/prenotazioni con tutti i dati inerenti per il riscontro con il servizio richiesto presso la struttura e comunicare, quale risposta, la possibilità di svolgere il servizio; fornire al modulo Booking le caratteristiche necessarie a rendere prenotabile il servizio; comunicare/recepire il gate in/gate out di veicolo e carico; comunicare l avvenuta effettuazione del servizio; comunicare eventuali segnalazioni inerenti le operazioni in atto. Le capacità gestionali del Modulo 2 dovranno essere soprattutto rivolte alla gestione di servizi: di tipo terminalistico (manovra container e casse mobili) ; di tipo gestione carico (carico/scarico rinfuse); di tipo gestione stalli e disponibilità di stazionamento/parcheggio automezzi, rimorchi e semirimorchi. A tal fine si reputa necessaria una predisposizione del Modulo al fine di: interfacciare i sistemi di controllo accessi per recepire informazioni di ingresso e uscita e per comunicare se il veicolo/autista sono attesi e autorizzati a usufruire del servizio o possono lasciare l area; interfacciare il sistema di gestione del Nodo Logistico (e delle strutture ad esso affiliate ad es. terminal) al fine di consentire lo scambio di informazioni di tipo operativo e gestionale. Considerando inoltre la generalità dell accezione di Nodo Logistico il Modulo 2 deve gestire almeno le seguenti situazioni: Nodo logistico unico e unicamente localizzato. Nodo logistico padre, in relazione di controllo e amministrazione di altri nodi logistici (ad es. centro merci composto da magazzini diversi), sia nel caso di contiguità geografica sia nel caso di distribuzione spaziale (ad es. una catena di magazzini). In pag 15

16 questo caso il nodo logistico padre agisce da amministratore di altri nodi logistici che, a propria volta, saranno definibili come figli. Nodo logistico padre che controlla solo il perimetro entro cui operano nodi figli operativamente e amministrativamente indipendenti (ad es. interporto e operatori interni all interporto). In questo caso il padre recepisce informazioni solo per quanto riguarda le funzioni di propria pertinenza: o o Autorizzazione all accesso e all uscita per usufruire di un servizio; Veicoli previsti in ingresso/uscita ai gate Integrazione con la PLN Il Modulo Nodo Logistico Integrato deve interfacciarsi con la PLN al fine di consentire almeno: il recepimento delle informazioni necessarie all elaborazione dei dati missione per la verifica delle disponibilità degli slot e la conferma verso la PLN; l invio di informazioni per l avvio, l avanzamento e la chiusura della missione; lo scambio di informazioni relative alla gestione delle prenotazioni; il recepimento delle autorizzazioni all accesso degli utenti e i loro profili funzionali. Oltre all interfaccia utente che deve essere intuitiva, immediata, completa e rispettare le linee guida dell interfaccia utente PLN, il modulo deve offrire un interfaccia SOA dedicata a sistemi terzi; l interfaccia SOA e l interfaccia utente devono essere funzionalmente equipotenti. 3.4 Modulo 3: Gestione eventi in sicurezza Descrizione L obiettivo del Modulo 3 consiste nel fornire uno strumento di gestione delle informazioni che riguardano gli eventi che possono incidere sulla normale operatività dei nodi logistici. Il Modulo software in oggetto deve consentire ai Responsabili del Nodo Logistico di usufruire di un cruscotto di controllo degli accessi e dello svolgimento dell erogazione dei servizi, in modo che possa intervenire con tempestività al verificarsi di un evento inatteso capace di influire negativamente sulla operatività ordinaria e di poter gestire con tempestività l avvicinamento dei veicoli e, eventualmente, indirizzarne la viabilità all interno del Nodo Logistico e/o l eventuale stazionamento temporaneo dei veicoli e/o delle merci in aree buffer. Il Modulo 3 dovrà poter essere configurato dal Responsabile del Nodo Logistico almeno per: 1. ricevere come input o rilevare situazioni di emergenza quali: a. operatività del nodo diminuita o assente (improvvisa chiusura) b. variazioni nell operatività programmata (variazione finestre di imbarco, ritardo treno ) c. anomalie nel traffico in accesso al nodo (eccessivo o carente) d. anomalie sulla viabilità che possono incidere nei flussi di accesso 2. consentire, attraverso i canali di comunicazione della PLN, di: a. Inviare messaggi di notifica alle aziende di trasporto e agli automezzi potenzialmente coinvolti dall evento negativo; pag 16

17 b. Formulare indicazioni contingenti alla situazione, anche attivando i servizi di cui al Modulo 2 Nodo Logistico Integrato, quali ad esempio: i. consigliare la sosta in aree alternative o esterne al nodo logistico ii. comunicare i nuovi orari di servizio iii. proporre finestre alternative di servizio iv. proporre servizi alternativi 3. ricevere dalla PLN gli eventi di Infologistica e consentire ai Nodi Logistici la configurazione di regole, basate anche sulla localizzazione dell evento, che scatenino la segnalazione di allarme Integrazione con la PLN Il Modulo 3 Gestione Eventi in Sicurezza deve interfacciarsi con la PLN al fine di consentire almeno: al Modulo 3 Gestione Eventi in Sicurezza la trasmissione verso la PLN dei messaggi da inoltrare a aziende e automezzi; al Modulo 3 Gestione Eventi in Sicurezza la ricezione degli eventi di infologistica dalla PLN al Modulo 3 Gestione Eventi in Sicurezza la ricezione dei dati di geolocalizzazione e le stime di avvicinamento dei mezzi al nodo Oltre all interfaccia utente che deve essere intuitiva, immediata, completa e rispettare le linee guida dell interfaccia utente PLN, il modulo deve offrire un interfaccia SOA dedicata a sistemi terzi; l interfaccia SOA e l interfaccia utente devono essere funzionalmente equipotenti. 3.5 Altri elementi di interscambio e di integrazione con la PLN Si ribadisce nuovamente che i tre Moduli Applicativi devono essere auto consistenti e autonomi rispetto sia alla PLN, sia a qualsiasi altro sistema già utilizzato presso i Nodi Logistici e/o le Aziende di autotrasporto. E comunque prevista l interazione tra i Moduli Applicativi e gli altri sistemi, compresa la PLN, tramite l interscambio di dati che dovrà tenere conto, oltre che di quanto descritto in precedenza, anche delle seguenti peculiarità: in linea generale, i tre Moduli devono essere integrati con la PLN al fine di garantire l allineamento dei dati comuni e l aggiornamenti di quelli gestiti esclusivamente dalla PLN; in caso di disservizio ovvero di mancanza di collegamento con la PLN deve essere comunque garantito il funzionamento e la capacità di gestione dei Moduli; il Modulo 1, Gestione Anagrafica Autisti, deve essere completamente autonomo rispetto alla PLN e ai Moduli 2 e 3; pertanto deve esserne garantito il funzionamento indipendentemente dallo stato di servizio della PLN e degli altri due Moduli; Il Modulo 2, Nodo Logistico Integrato, e il Modulo 3, Gestione Eventi in Sicurezza, possono essere fortemente accoppiati al punto di prevedere la condivisione delle medesime strutture di base (data base, run time, ecc.); dal punto di vista funzionale devono, invece, essere nettamente distinti e distintamente attivabili dalle rispettive utenze; pag 17

18 le anagrafiche delle Aziende di autotrasporto e degli autotrasportatori saranno gestite prevalentemente dalla PLN; i Moduli faranno riferimento alla PLN per l allineamento dei dati necessari al funzionamento, ferma restando la possibilità di gestione delle anagrafiche anche solo accedendo dai Moduli stessi; i tre Moduli devono essere integrati con la PLN al fine di recepire utenze e profilature di accesso; in caso di disservizio ovvero di mancanza di collegamento con la PLN deve essere comunque garantito il funzionamento e la capacità di gestione dei Moduli. 3.6 Funzionalità di supporto Ognuno dei tre Moduli, considerato singolarmente, deve essere progettato e realizzato in maniera tale da: offrire strumenti di ricerca e consultazione (per anagrafiche, richieste e utenti); consentire lo scambio di informazioni, in termini di caricamento e aggiornamento, anche in forma massiva con altri sistemi di gestione tra i quali, prioritariamente, la PLN; allo stesso modo, consentire l esportazione dei risultati delle ricerche in formati dati noti, con procedure semplificate e controllate; offrire una reportistica adeguata al controllo gestionale del Modulo 1, con selezione semplificata dei dati da rappresentare sotto forma di liste ovvero di schede singole; rappresentare e predisporre la stampa di statistiche. 3.7 Successive integrazioni con la PLN Considerato che la procedura di gara è indetta ai sensi del D.Lgs. n. 163/2006, art. 55, comma 5, il presente paragrafo identifica e descrive sommariamente una ulteriore componente progettuale da considerare come opzionale. Tale opzione potrà essere esercitata successivamente alla contrattualizzazione di quanto descritto negli altri paragrafi del presente Capitolo 3, attraverso la stipula eventuale, a procedura negoziata, di un atto aggiuntivo con il medesimo Prestatore che si aggiudicherà la realizzazione del progetto. A beneficio dei proponenti sono di seguito esposte le linee guida della realizzazione opzionalmente prevista: le interfacce utente dei Moduli Applicativi dovranno essere implementate con l obiettivo di consentire la completa cooperazione applicativa con la PLN tramite Enterprise Service Bus, quest ultimo oggetto di altra realizzazione; I Moduli Applicativi dovranno fare riferimento, per la gestione di accessi e ruoli, a un sistema di Identity and Access Management; quest ultimo oggetto di altra realizzazione. Si specifica ulteriormente che: la progettazione e l implementazione delle componenti opzionali potranno essere richieste anche durante il periodo di realizzazione del sistema; di questo, ne erediteranno tutte le specifiche espresse in termini di modalità di realizzazione; pag 18

19 UIRNet Spa si impegna a fornire requisiti e indicazioni tecniche di dettaglio nel minor tempo possibile, rispetto alla propria disponibilità del Enterprise Service Bus e del sistema di Identity and Access Management; tutti i requisiti funzionali e tecnologici relativi al progetto saranno ritenuti vigenti ed inalterati, ove oggettivamente applicabili rispetto alle caratteristiche del Enterprise Service Bus e del sistema di Identity and Access Management. pag 19

20 4 REQUISITI TECNOLOGICI 4.1 Architettura software Si rammenta il principio per cui i Moduli Applicativi dovranno essere auto consistenti e, nel contempo, cooperare attivamente con la PLN e/o con altri sistemi di trattamento delle informazioni, già in uso presso Aziende di autotrasporto e Nodi Logistici. Lo sviluppo dei Moduli deve prevedere l utilizzo di un architettura informatica orientata ai servizi (cd. SOA); in tale ottica: i back end esporranno i servizi per ogni processo gestionale; i front end che, come detto, saranno Web Interface e/o Mobile Application dovranno prevedere proprie procedure di verifica dei dati inseriti (sotto il profilo della correttezza formale e sostanziale) ma, per il trattamento dei dati, si affideranno solo ai servizi esposti dal back end. Sotto il profilo ingegneristico generale, la soluzione dovrà essere complessivamente modellata secondo la logica del multi-tier architecture, con precisa preferenza per una struttura three-tier in cui sia garantita: l alta affidabilità; l assoluta scalabilità in senso orizzontale e verticale. 4.2 Caratteristiche salienti dei servizi back end Sotto il profilo delle modalità di comunicazione, i servizi dovranno essere esposti adottando i protocolli JSON over HTTPS (JavaScript Object Notation) e SOAP (Simple Object Access Protocol) e XML (extended Markup Language). Nel caso di realizzazione dei servizi basati su JSON over HTTPS si richiede l applicazione dei principi previsti dal paradigma architetturale REST (REpresentational State Transfer). In merito alle caratteristiche di interoperabilità per i servizi esposti su protocollo SOAP, si richiede l adozione degli standard definiti dall OASIS e dal W3C, con particolare riferimento ai seguenti profili definiti dal primo: WS-I Basic Profile 1.2 e 2.0 WS-I Basic Security Profile 1.0 e 1.1 WS-I Reliable Secure 1.0 Per ciascun servizio realizzato dovranno essere generati i codici sorgente di base, a partire da un modello concettuale del servizio, per Proxy e Stub, nonché quelli relativi a unit test, integration test e stress test, che dovranno essere eseguiti secondo una dettagliata pianificazione. I servizi dovranno corrispondere ai seguenti principi di progettazione: pag 20

21 autoconsistenza: i servizi dovranno esporre funzioni di business complete ed indipendenti idempotenza: i servizi dovranno garantire il corretto funzionamento in caso di richieste duplicate stateless: i servizi non dovranno fare affidamento su informazioni conservate nella session dell Application Server per l elaborazione della risposta Qualora risulti necessario nella fase di progettazione esecutiva derogare a tali principi per uno ovvero più servizi esposti, il Prestatore dovrà motivare le esigenze tecniche da cui deriva tale scelta e dettagliare le soluzioni tecnologiche adottate per ovviare agli inconvenienti che da tale deroga possono derivare, sia in termini di affidabilità della soluzione sia di scalabilità della stessa. Le interfacce dei servizi dovranno seguire le Best Practice internazionali, realizzando i principi di completezza, autoconsistenza delle stesse e comprensibilità (ad es. dovrà essere escluso l utilizzo di oggetti di tipo enumerativo identificati da numeri interi, prediligendo l uso di stringhe Human Readable); 4.3 Sviluppo software Il progetto prevede la realizzazione di un servizio cd. a corpo comprendente lo sviluppo software dei Moduli Applicativi da parte del Prestatore. Il Committente intende partecipare attivamente alle attività di sviluppo software, sia nella prima fase di sviluppo ad hoc che in quella successiva di MEV (manutenzione evolutiva), con una presenza che non sia limitata al mero riscontro del lavoro svolto, ma si concretizzi con la partecipazione continua ed attiva alle fasi analitiche, decisionali ed esecutive. Si precisa, tra l altro, che la sola erogazione del servizio di manutenzione evolutiva sarà a consumo nella quantità che sarà ritenuta utile dal Committente. In questo modo, il Committente intende massimizzare il proprio investimento e ottenere garanzie sulla effettiva rispondenza del risultato, rispetto alle necessità della propria Organizzazione Linguaggio di programmazione I software devono essere sviluppati in Java Platform Enterprise Edition Lavoro del gruppo di sviluppo software Dovranno essere adottati i seguenti principi quale base, non esaustiva, della modalità di lavoro: modalità di lavoro flessibile e leggera, con adozione di paradigmi precisi ed espliciti; utilizzo di strumenti professionali che consentano lo sviluppo tramite la modellazione del software che si intende implementare, secondo i principi del Model Driven Software Development. avanzamento delle attività di sviluppo secondo principi di Continuos Integration e Test Based Development. pag 21

22 definizione di nomenclatura e standard di coding, prima dell avvio della progettazione di dettaglio. realizzazione di funzionalità fine-grained quali servizi elementari che, tramite orchestratore, possano essere, successivamente e gradualmente, assemblate in servizi coarse-grained per l esecuzione di complete funzioni di business Rispondenza allo standard ARTIST E richiesto che le realizzazioni di progetto siano conformi alle indicazioni dello standard ARTIST (ARchitettura Telematica Italiana per il Sistema dei Trasporti) di cui al sito Tale conformità dovrà essere auto certificata dal Proponente Scalabilità per evoluzione delle performance hardware E richiesto che la soluzione software sia complessivamente concepita, già dalla fase di progettazione esecutiva, e realizzata con caratteristiche di scalabilità che dovranno consentire un significativo incremento delle performance, rispetto a quelle indicate nel successivo Capitolo 5, nel caso in cui siano attuate le seguenti evoluzioni: aumento del numero dei nodi/server; si cita ad esempio, il futuro inserimento di bilanciatori hardware per server di front end e applicativi ovvero, sempre a titolo di esempio, il futuro utilizzo di soluzioni grid per i database; già in fase di progettazione della soluzione dovrà essere prevista la clusterizzazione del database, al fine di assicurare l alta affidabilità della soluzione; incremento di CPU e RAM sui nodi/server esistenti ovvero implementati secondo quanto affermato nel punto precedente Utilizzo di soluzioni Open Source Si evidenzia che la scelta delle soluzioni per piattaforme ed architetture sarà preferibilmente basata su tecnologie open-source, quale scelta strategica per l ottimizzazione delle risorse economiche e per la creazione di asset durevoli in forza al Committente. Le scelte dovranno essere effettuate secondo quanto stabilito dalla Legge del 7 agosto 2012 n Conversione in legge, con modificazioni, del Decreto Legge 22 giugno 2012, n. 83, recante misure urgenti per la crescita del Paese, pubblicato in Gazzetta Ufficiale n. 187 del 11 agosto 2012 al supplemento ordinario, con particolare riferimento all art. 22,comma 10, che per completezza si riporta nel seguito:... Le pubbliche amministrazioni acquisiscono programmi informatici o parti di essi a seguito di una valutazione comparativa di tipo tecnico ed economico tra le seguenti soluzioni disponibili sul mercato: a) software sviluppato per conto della pubblica amministrazione; b) riutilizzo di software o parti di esso sviluppati per conto della pubblica amministrazione; c) software libero o a codice sorgente aperto; d) software combinazione delle precedenti soluzioni. Solo quando la valutazione comparativa di tipo tecnico ed economico dimostri l impossibilità di accedere a soluzioni open source o già sviluppate all interno della pubblica amministrazione ad un prezzo inferiore, è consentita l acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d uso. La valutazione di cui al presente comma è effettuata secondo le modalità e i criteri definiti dall Agenzia per l Italia Digitale, che, a richiesta di soggetti interessati, esprime altresì parere circa il loro rispetto... pag 22

23 4.3.6 Interfaccia uomo/sistema Il Prestatore dovrà garantire la realizzazione di tutte le interfacce utente in linea ed in coerenza con il look & feel dell iniziativa UIRNet. Tutte le interfacce web devono essere funzionanti almeno con browser Microsoft Internet Explorer 8 (e successivi, in ambiente Microsoft Windows XP o successivi) e Firefox 3 e successivi (indipendentemente dal sistema operativo sottostante). Le realizzazioni devono essere fornite multilingue; per questa funzione si ritiene indispensabile la realizzazione di un sistema di etichette amministrabili ovvero di file di configurazione, gestibili da parte UIRNet. Gli applicativi devono essere realizzati e consegnati con interfacce utente in lingua italiana (entro il termine della Fase di Implementazione) e in lingua inglese (entro il termine della Fase di Gestione); anche la traduzione della messaggistica in inglese dovrà essere parte della servizio. Si intende evidenziare l importanza della facilità d uso delle interfacce utente (cd. principio di usabilità): la realizzazione dovrà avere interfacce utente con look & feel completamente conforme rispetto a quelle della Piattaforma Logistica Nazionale UIRNet, oltre che una coerente struttura di assistenza all utente (tooltip, help in linea, ecc.) la realizzazione dovrà avere una sintassi dell interfaccia utente facile da imparare e ricordare (uniformità negli stili dei controlli, pulsanti, modo d uso dei tab, delle finestre di ricerca, ecc.); l output all utente dovrà essere prodotto in un tempo sufficiente per essere oggettivamente utilizzabile nei contesti applicativi di riferimento; la tempistica di dettaglio sarà stabilita in fase di progettazione di dettaglio e costituirà un requisito obbligatorio a carico del Prestatore da valutare nel corso dei collaudi; in alcun modo, l adozione del sopra citato principio di facilità d uso dovrà derogare alla consistenza della sicurezza ed alla protezione dei sistemi; le interfacce Web pubbliche dovranno corrispondere ai requisiti di Accessibilità stabiliti dalla cd. Legge Stanca. 4.4 Sicurezza La soluzione applicativa sviluppata dal Prestatore dovrà essere dotata di misure in grado di garantire un adeguato livello di sicurezza. Il concetto sopra espresso è assoluto; alla sua formulazione corrisponde un preciso vincolo per il Prestatore al quale fa capo l onere di formulare una dettagliata proposta per tutto ciò che concerne la sicurezza. I contenuti della proposta dovranno essere omnicomprensivi riguardo la tematica, e non limitarsi agli aspetti di seguito elencati che, comunque, costituiscono un preciso vincolo di indirizzo e contenuto. Le funzioni di sicurezza dovranno prevenire accessi non autorizzati - volontari o accidentali - sia ai programmi sia ai dati. pag 23

24 Dovranno, pertanto, essere progettate e realizzate opportune soluzioni atte ad assicurare i seguenti requisiti, di carattere generale, in merito agli aspetti di sicurezza: Identificazione ed Autenticazione: verifica dell identità allo scopo di prevenire accessi non autorizzati al sistema e alle risorse di rete; Autorizzazione: controlla quale sistema, informazione e applicazione può essere dato ad un utente; Integrità: assicura che sia i dati presenti negli archivi sia quelli che transitano sulla rete non vengano cambiati o compromessi da manipolazioni non autorizzate; Riservatezza: prevenzione dell utilizzo indebito delle informazioni. Tale requisito presuppone che l accesso alle informazioni venga controllato attraverso adeguate misure di protezione; Protezione della privacy: previene la lettura di dati privati da parte di utenti non autorizzati; Non ripudiabilità: verifica che la trasmissione dei dati è stata eseguita dal mittente mediante l adozione di firme digitali che prevengano contestazioni circa l autenticità e la immutabilità del contenuto; Disponibilità: intesa come prevenzione dei pericoli di occultamento e/o di impossibilità di accesso ai dati, necessari per la conduzione di una attività lecita. Più in particolare, è necessario che siano rispettati anche i seguenti requisiti: ogni sistema deve implementare la propria gestione delle credenziali e delle permission per l'accesso e la manipolazione dei dati; ogni Back End deve esporre servizi per la manipolazione delle credenziali e dei profili (ad es. creazione, profilazione, cancellazione etc.) per la gestione, sia mediante Web Interface che mediante strumenti di provisioning centralizzato, quali quelli offerti da sistemi di Identity & Access Management; le Web Interface devono offrire strumenti per il self provisioning gestendo, nelle more dell'implementazione di un sistema di Identity & Access Management nella PLN, il workflow di autorizzazione. Infine, si dovrà tenere conto che per ogni back end dovranno essere previste due versioni dei servizi esposti: una completa ed autoconsistente per quanto concerne gli aspetti di sicurezza con l adozione di protocolli di sicurezza standard quali WS-I Security e WS-I Secure Conversation promulgati dal W3C e dall OASIS ed integrabile con sistemi di Identity & Access Management per la pubblicazione su Extranet ed Internet; una priva dei meccanismi di autenticazione per l uso con front end certificati prevedendo l adozione di meccanismi di trusting a livello di layer di comunicazione, quali ad es. SSL basato su certificati e controlli a livello di protocollo TCP/IP. 4.5 Compatibilità con hardware e software di base della PLN. E richiesto che i Moduli Applicativi siano progettati e realizzati per poter funzionare sull infrastruttura virtualizzata, già operativa presso il Centro Elaborazione Dati di UIRNet. Presso questa struttura, la piattaforma PLN è gestita con i seguenti software di base: ambiente VMWare; server Unix like (Linux Red Hat ES5); pag 24

25 database Oracle (versione 11g o seguenti); web server Apache 2.2; application server Java Red Hat JBoss. Quanto sopra non costituisce un vincolo per lo sviluppo oggetto del Progetto se non per la piena compatibilità con le scelte che saranno individuate dal Prestatore. 4.6 Erogazione di servizio hosting nel corso della Fase di Gestione Per il periodo della Fase di Gestione, successivamente dettagliato nel Paragrafo 6, il Prestatore dovrà provvedere ad erogare un servizio di hosting che abbia caratteristiche tali da assicurare la piena operatività dei Moduli Applicativi, così come previsto nel presente Capitolato. Pertanto, le caratteristiche del hardware, della connettività, delle connessioni VPN verso la PLN ed altro, devono essere coerenti con le esigenze del progetto soprattutto in termini di scalabilità e modularità. Particolare riferimento dovrà essere posto agli aspetti di sicurezza che dovranno essere completamente coerenti con le previsioni progettuali e con le linee guida che saranno identificate ed applicate nel corso del Progetto. pag 25

26 5 REQUISITI DIMENSIONALI E PRESTAZIONALI I Moduli Applicativi oggetto di sviluppo dovranno essere progettati e realizzati per conseguire gli obiettivi di esercizio operativo descritti nei paragrafi seguenti. 5.1 Modulo 1 Il Modulo dovrà rispondere ai seguenti requisiti operativi: Scalabilità: il Modulo 1 dovrà avere una capacità gestionale corrispondente a autisti; capacità di elaborazione: il Modulo 1 dovrà gestire richieste di verifica di credenziali anagrafiche al minuto con Response Time, sull application server, non superiore a 3 secondi (escluso controllo biometrico). In fase di progettazione esecutiva dovranno essere evidenziati e giustificati i criteri tecnici finalizzati a garantire l obiettivo. In fase di Collaudo, l accertamento prestazionale in merito ai requisiti sopra citati, sarà verificato mediante la gestione di un anagrafica di autisti e l effettuazione di 200 richieste di verifica credenziali al minuto con Response Time, sull application server, non superiore a 3 secondi, e la capacità del sistema di scalare ai valori sopra indicati mediante opportune prove di carico a risorse variabili da definirsi in fase di progettazione esecutiva. 5.2 Modulo 2 e Modulo 3 I due Moduli dovranno rispondere ai seguenti requisiti operativi: Scalabilità: i due Moduli, singolarmente considerati, dovranno avere una capacità gestionale corrispondente a nodi logistici. capacità di elaborazione: il Modulo 2 dovrà gestire 500 richieste di erogazione di servizi al minuto con Response Time, sull application server, non superiore a 3 secondi; il Modulo 3 dovrà gestire 300 invii di allerta al minuto con Response Time, sull application server, non superiore a 3 secondi. In fase di progettazione esecutiva dovranno essere saranno evidenziati e giustificati i criteri tecnici finalizzati a garantire l obiettivo. In fase di Collaudo, l accertamento prestazionale in merito ai requisiti sopra citati, sarà accertato mediante la gestione di un anagrafica di nodi logistici; il Modulo 2 dovrà gestire 50 richieste di erogazione di servizi al minuto e il Modulo 3 dovrà gestire 30 invii di allerta al minuto, entrambi con Response Time, sull application server, non superiore a 3 secondi, e la capacità del sistema di scalare ai valori sopra indicati mediante opportune prove di carico a risorse variabili. pag 26

27 6 ESECUZIONE PROGETTUALE L esecuzione del progetto è distinta in due fasi principali che si intende definire come: Fase di Implementazione; Fase di Gestione. Si tratta di gruppi logici in cui sono concentrate le attività (definite anche Processi ) da realizzare e, contestualmente, i servizi che il Prestatore dovrà erogare al fine di conseguire correttamente gli obiettivi di progetto. Nella Fase di Implementazione le attività sono sequenziali, per cui l esito positivo di ognuna comporta l avvio della successiva, mentre nella Fase di Gestione sono previsti due filoni paralleli di attività che possono anche non avere relazioni di reciprocità. Più in dettaglio, la Fase di implementazione prevede: il Processo di Progettazione; il Processo di Realizzazione e Collaudo; mentre la Fase di Gestione raggruppa: il Processo di Gestione Operativa; il Processo di Manutenzione. Ai processi che compongono le Fasi, si affiancano processi trasversali che hanno inizio successivamente alla stipula contrattuale ed affiancano il progetto per tutta la durata; consistono in: Processo di Gestione Progettuale; Processo Documentale; Processo di Gestione della Configurazione; Processo di Assicurazione Qualità. I contenuti del presente capitolo sono estratti da vigenti documenti dell Agenzia per l Italia Digitale, da tenere in considerazione per le parti che si ritengono utili e necessarie per questo progetto. L obiettivo del capitolo consiste nella definizione esatta dei contenuti dei processi da svolgere per soddisfare le esigenze di progetto e nell identificazione degli output da produrre; allo scopo, sono utilizzati i codici identificativi utilizzati nei documenti dell Agenzia per l Italia Digitale. Nella didascalia seguente è rappresentata la sequenza di start dei vari processi, indipendentemente dalla loro durata e dalle successive interrelazioni tra gli stessi. Si ritiene utile descrivere l esecuzione progettuale seguendo proprio l elencazione dei processi nella didascalia, dall alto verso il basso. pag 27

28 GE Gestione progetto DO Documentazione AQ Assicurazione Qualità PR Progettazione RE Realizzazione e collaudo MA Manutenzione GO Gestione operativa CO Configurazione Sequenza di START dei processi 6.1 Trasversale: Processo di Gestione Progettuale Obiettivi Obiettivo del processo di gestione progettuale è consentire al Prestatore la conduzione coordinata del Progetto che deve essere sviluppato in esecuzione del contratto, con l obiettivo ultimo di completare con successo il medesimo, nel rispetto dei requisiti di tempi, costi e qualità indicati nei documenti contrattuali. Ricadono nell ambito di questo processo tutte le attività preliminari all avvio del processo di progettazione, come la pianificazione delle attività, l acquisizione delle risorse, la definizione dell organizzazione del progetto e l avvio delle attività, e tutte le attività di coordinamento delle risorse assegnate al progetto in corso d opera. Il processo include, inoltre, le attività di controllo dell andamento del progetto, la produzione di stati di avanzamento di tutte le attività necessarie al conseguimento degli obiettivi contrattuali, inclusa la servizio, alle parti interessate, delle informazioni sulle evoluzioni e sugli avanzamenti del progetto nonché la servizio della opportuna documentazione e delle informazioni inerenti le attività condotte per identificare, valutare e gestire i rischi del Progetto. Ricade, altresì, nell ambito del Processo di Gestione Progettuale la definizione e la manutenzione dell infrastruttura necessaria allo svolgimento degli altri processi. pag 28

29 L infrastruttura può includere hardware, software, strumenti, tecniche, norme e apparecchiature per i processi di Progettazione, Realizzazione, Gestione Operativa e Manutenzione, ed anche per il processo di Gestione della Documentazione. Il processo ha anche l obiettivo di misurare e migliorare i processi attuati dal Prestatore nell ambito del ciclo di vita della servizio, fino alla conclusione di tutti i processi svolti dal Prestatore per eseguire il servizio oggetto del contratto. Anche rendendo disponibile, in via continuativa, personale adeguatamente preparato formato all avvio di ciascuna attività pianificata per l esecuzione del contratto. e Attivazione del processo Il processo è svolto sotto la responsabilità del Prestatore ed è attivato a valle della sottoscrizione del contratto. Sono dati di input del processo l insieme dei documenti che costituiscono la baseline di contratto, prodotti nell ambito dei processi di acquisizione e di servizio, ovvero il Contratto, il Capitolato tecnico, l Offerta tecnico-economica del Prestatore. A questi, si aggiungono l insieme dei documenti prodotti nel processo di progettazione per quanto concerne la definizione dell infrastruttura e le registrazioni prodotte nel corso della esecuzione delle attività, rilevanti ai fini delle misure da effettuare per ciascun processo, per quanto concerne il miglioramento dei processi produttivi. Le attività di pianificazione vera e propria di tempi, costi, qualità, gestione rischi e gestione delle comunicazioni, sono propedeutiche a tutti i processi del ciclo di vita e sono volte a programmare tutte le attività da svolgere nel corso della esecuzione del contratto, in modo da rispettare i vincoli ed i requisiti previsti nel contratto stesso. I documenti di pianificazione ed, in particolare, la baseline dei tempi, dei costi e della qualità, costruita in questa fase iniziale, costituiscono il programma di riferimento con il quale confrontare i successivi aggiornamenti nelle fasi realizzative ed esercitare le funzioni di controllo fino alla conclusione del Progetto Attività e prodotti Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di Gestione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti. Processo di Gestione Attività Prodotti GE-A1 Pianificazione del progetto GEA1-01 Piano di progetto GE-A3 Pianificazione della comunicazione GEA3-01 Piano di gestione delle comunicazioni GE-A4 Pianificazione della qualità GEA4-01 Piano di qualità GE-A5 Esecuzione del progetto GEA5-01 Registrazioni GEA5-02 Richieste di cambiamenti GE-A6 Controllo del progetto GEA6-01 Stato Avanzamento Lavori (SAL) GE-A7 Revisione, Riesame e valutazione GEA7-01 Registrazioni GEA7-02 Richieste di cambiamenti GE-A8 Definizione dell infrastruttura GEA8-01 Specifiche dell infrastruttura GE-A9 Manutenzione dell infrastruttura GEA9-01 Registrazioni pag 29

30 Processo di Gestione Attività Prodotti GE-A10 Definizione dei processi GEA10-01 Disegno dei processi GE-A11 Valutazione dei processi GEA11-01 Registrazioni GE-A12 Miglioramento dei processi GEA12-01 Piano di miglioramento dei processi GE-A13 Definizione delle esigenze GEA13-01 Piano di formazione GE-A14 Sviluppo del materiale di formazione GEA14-01 Materiali didattici e strumentazione GE-A15 Esecuzione della formazione GEA15-01 Registrazioni GE-A16 Conclusione del progetto GEA16-A1 Archivio del progetto Pianificazione del progetto. Il punto di partenza per la pianificazione del Progetto da realizzare in esecuzione del contratto è la definizione degli obiettivi del Progetto medesimo (ambito del progetto) ovvero dei criteri qualitativi e quantitativi che devono essere soddisfatti perché il progetto possa considerarsi completato con successo; segue, quindi, l individuazione di tutte le entità organizzative (individui o organizzazioni) che sono attivamente coinvolte nel Progetto. Segue, inoltre, la pianificazione operativa vera e propria che, a partire dai deliverable contrattuali, ovvero dalle attività e dai prodotti propri dei processi primari, ed attraverso una scomposizione secondo un livello di dettaglio via via crescente, porta a definire una disaggregazione gerarchica del lavoro da svolgere ed all individuazione delle unità elementari di lavoro, alle quali è possibile assegnare tempi di esecuzione, risorse e costi. Tale attività consente di definire la baseline di riferimento per misurare le prestazioni di tempi e utilizzo di risorse nel corso della esecuzione del Progetto. Il risultato dei compiti sopra descritti è contenuto nel Piano di progetto, ovvero un documento (o un insieme di documenti) formale, approvato, utilizzato per gestire e controllare l esecuzione del Progetto. Il Piano di progetto è un documento dinamico, che può variare man mano che si consolidano le informazioni sul progetto, a differenza della baseline dei tempi e dei costi che invece è uno strumento di controllo, che può variare di regola solo a fronte di cambiamenti approvati degli obiettivi di progetto. Il Piano di progetto può essere organizzato e presentato in diversi modi; in genere include almeno, direttamente o attraverso il riferimento ad altri documenti, le seguenti informazioni: informazioni di sintesi sulle caratteristiche del progetto (requisiti e/o obiettivi strategici che il progetto si prefigge di soddisfare; descrizione del prodotto e/o del servizio che il progetto dovrà realizzare per soddisfare i requisiti del contratto; durata complessiva (inizio fine); eventuali vincoli e supposizioni; eventuali risorse che devono essere rese disponibili dal Committente; Responsabile di progetto assegnato); gli obiettivi del progetto e le entità organizzative coinvolte; l organizzazione di progetto, le risorse assegnate ed i relativi ruoli e profili professionali; le interfacce organizzative e tecniche; la Work Breakdown Structure (WBS) riferita alle attività ed ai prodotti propri dei processi primari, ovvero la scomposizione dei deliverable contrattuali al fine di definire le unità di lavoro al livello di dettaglio in base al quale sarà necessario esercitare il controllo in fase di esecuzione del progetto; pag 30

31 la programmazione temporale delle attività e le assegnazioni di responsabilità per ciascuna unità di lavoro della WBS; la baseline di riferimento per misurare le prestazioni; la definizione dei momenti in cui verrà rilevato lo stato di avanzamento lavori (SAL), le logiche da utilizzare per misurare l avanzamento, le date programmate di svolgimento di Riesami e Verifiche; le principali milestone, vale a dire i momenti a cui corrispondono fatti rilevanti dal punto di vista gestionale e che sostituiscono dei punti di controllo essenziali per la verifica del corretto avanzamento dei lavori; i problemi aperti e/o le decisioni pendenti; le modalità per la gestione dei cambiamenti Pianificazione delle comunicazioni. È l attività con la quale si determinano le esigenze di informazione e di comunicazione di tutte le entità organizzative coinvolte nel Progetto e/o destinatarie dei risultati del Progetto. Il prodotto dell attività è il Piano di gestione delle comunicazioni, o un documento equivalente, che includa almeno: un metodo di raccolta ed archiviazione delle varie tipologie di informazione; un sistema di distribuzione, che dettagli a chi andranno le informazioni ed in che modo (rapporti scritti, incontri, ecc.): una descrizione delle informazioni da distribuire (tipologia, formato, contenuto, livello di dettaglio, convenzioni/definizioni da assumere); una programmazione temporale, che assicuri la tempestività nella generazione e distribuzione delle informazioni; un metodo per aggiornare e revisionare il Piano di gestione delle comunicazioni in funzione delle evoluzioni del progetto. Il livello di dettaglio del documento è dettato dalle esigenze di condivisione di informazioni e comunicazioni determinate dal Progetto Pianificazione della qualità. E l attività con la quale, a partire dai requisiti specificati nei documenti contrattuali, si dettagliano e si documentano tutti i requisiti di qualità espressi, impliciti ed obbligatori e si definisce come tali requisiti saranno soddisfatti e controllati. Il prodotto dell attività è il Piano di qualità, o un documento equivalente, che deve indirizzare il controllo di qualità, l assicurazione di qualità ed il miglioramento di qualità per tutte le fasi del ciclo di vita della servizio. Descrive almeno gli obiettivi di qualità, i controlli e le verifiche, i criteri di entrata/uscita delle varie fasi progettuali, i criteri di accettazione dei prodotti delle fasi Esecuzione del progetto. L attività consiste nella esecuzione di quanto pianificato nel Piano di progetto, nel Piano di gestione delle comunicazioni e nel Piano di qualità. pag 31

32 In particolare in tale fase si dà luogo alla esecuzione delle attività proprie dei processi primari, secondo il programma temporale definito nel Piano di progetto, nonché alla distribuzione delle informazioni secondo il Piano di gestione delle comunicazione. Nel corso di tale attività, sulla base dei risultati dell attività di Controllo del progetto di seguito descritta, il Prestatore deve rilevare, analizzare e risolvere criticità e problemi emersi. La risoluzione di tali problemi può comportare modifiche ai piani. I prodotti dell attività, oltre ai prodotti propri di ciascuna attività afferente ai processi primari che vengono svolti in tale ambito, sono: le Registrazioni delle attività svolte; eventuali richieste di cambiamenti (estendere l ambito del progetto; modificare la stima dei costi, ecc.), che danno quindi luogo ad una modifica ai piani Controllo del progetto Il controllo viene esercitato costantemente durante l esecuzione del Progetto. L obiettivo è rilevare e gestire i cambiamenti rispetto ai piani, al fine di assicurare il completamento del Progetto nel rispetto dei tempi, dei costi e della qualità richiesta. I compiti principali sono costituiti dal controllo complessivo dei cambiamenti e dalle registrazione delle prestazioni di progetto. Il controllo complessivo dei cambiamenti consiste essenzialmente nel coordinare e gestire i cambiamenti attraverso tutto il Progetto. I cambiamenti si rilevano attraverso: il controllo dei tempi: rilevazione dei cambiamenti alla schedulazioni rispetto alla baseline dei tempi; il controllo dei costi: rilevazione dei cambiamenti al budget del progetto rispetto alla baseline dei costi; il controllo della qualità: verifica che i risultati delle varie fasi rispettino i requisiti di qualità; il controllo dei rischi: verifica dell efficacia delle azioni previste per mitigare/evitare i rischi e gestione dei cambiamenti nei rischi individuati. La registrazione delle prestazioni di progetto ha lo scopo di raccogliere in modo sistematico i risultati sull andamento del Progetto, in modo da fornire alle entità organizzative interessate le informazioni sull avanzamento delle attività in termini di quantità messe in opera (attività completate e/o deliverable prodotti). Il risultato finale dell attività di Controllo del progetto è uno Stato Avanzamento Lavori (SAL), ovvero un documento, o un insieme di documenti, prodotti periodicamente, secondo la periodicità e le modalità indicate nel Piano di progetto ed approvate dal Committente, che contenga almeno le seguenti informazioni: registrazioni sullo stato delle attività alla data; registrazioni sull avanzamento alla data; previsioni e stime a finire risultati delle attività svolte in esecuzione del Piano di progetto (quali deliverable sono stati parzialmente o completamente realizzati, in che tempi e con quali costi rispetto alle previsioni indicate nelle rispettive baseline). pag 32

33 6.1.9 Revisione, riesame e valutazione. Periodicamente, secondo la periodicità e le modalità indicate nel Piano di progetto e nel Piano di qualità e comunque quando opportuno, devono essere effettuate alcune Revisioni a vari livelli (nell ambito del team di progetto; con le entità organizzative interessate), aventi ad oggetto elementi quali: esame delle attività correnti e del loro stato; verifica dello stato di avanzamento delle attività e degli eventuali scostamenti dai piani; esame delle criticità ed identificazione delle relative azioni correttive; analisi dei rischi in essere e delle azioni collegate. Il Prestatore deve assicurare che i Piani e le attività svolte nell ambito del processo di gestione siano adeguati rispetto ai requisiti contrattuali. I prodotti dell attività, sono: le Registrazioni; eventuali richieste di cambiamenti, che danno quindi luogo ad una modifica ai Piani Definizione dell infrastruttura. All avvio del processo di Progettazione, il Prestatore deve pianificare e definire l infrastruttura necessaria per svolgere tutte le attività previste nell ambito dei processi del ciclo di vita del servizio. In particolare, sulla base delle prescrizioni, della specifica dei requisiti e considerando le procedure applicabili, le norme, gli strumenti e le tecniche, il Prestatore deve definire le risorse hardware e software, i mezzi materiali e quanto altro necessario a soddisfare i requisiti del processo che utilizza l infrastruttura e deve pianificare e documentare la relativa configurazione, in accordo con il processo di Gestione della Configurazione. Il risultato dell attività è costituito dalle Specifiche dell Infrastruttura ovvero un documento o un insieme di documenti nel quale, per ciascun processo che utilizza il processo di Infrastruttura, è definita l infrastruttura da utilizzare e sono indicate le modalità di realizzazione con i vincoli temporali connessi, le caratteristiche di funzionalità, prestazioni, sicurezza, riservatezza, disponibilità, requisiti di spazio e attrezzature, la configurazione delle risorse hardware, software e della documentazione. L installazione della infrastruttura è propedeutica alla esecuzione del processo che la richiede Manutenzione dell infrastruttura. Il Prestatore deve assicurare che l infrastruttura sia gestita, mantenuta e se necessario modificata, al fine di garantire che continui a soddisfare i requisiti del processo che la utilizza. Detta attività è svolta nell ambito dei processi di Gestione operativa e di Manutenzione e dà luogo ai prodotti ivi evidenziati. Il Prestatore nel corso dell attività produce le Registrazioni relative alla gestione della infrastruttura e alle modifiche effettuate pag 33

34 Definizione dei processi. Con riferimento ai processi che caratterizzano il ciclo di vita della servizio, il Prestatore identifica, organizza e gestisce la propria rete di processi e le relative interfacce. In particolare devono essere individuati e pianificati tutti i processi che hanno diretta influenza sulla qualità della servizio e che possono avere impatto sulla soddisfazione dell utente. Detti processi sono descritti in un documento o in un insieme di documenti, Disegno dei processi, nel quale oltre ad essere indicati attività, input ed output dei processi, sono indicate le loro applicazioni a specifici casi ed i meccanismi di controllo volti a sviluppare, monitorare, valutare e migliorare i processi stessi Valutazione dei processi. E l attività volta a misurare le prestazioni di ciascun processo, in termini qualitativi e quantitativi. Le valutazioni sono condotte periodicamente ad intervalli definiti, secondo piani, sulla base dei dati (dati prestazionali; dati tecnici; dati sui costi della qualità; ecc.) tratti dalle Registrazioni delle attività svolte in esecuzione dei processi stessi. I risultati di ciascuna valutazione, documentati nelle relative Registrazioni, costituiscono i dati di input necessari per il miglioramento dei processi Miglioramento dei processi. I risultati dell attività di valutazione vengono analizzati dal Prestatore per individuare i punti di forza e di debolezza dei processi impiegati. Queste analisi rappresentano l input per la definizione ed attuazione di un Piano di miglioramento dei processi, che individui le azioni correttive e preventive da adottare al fine di risolvere e prevenire i problemi e le non-conformità nei prodotti oggetto di servizio, nonché allo scopo di raccomandare modifiche nello sviluppo del progetto (o di progetti successivi) e determinare i necessari avanzamenti tecnologici. Nel corso di tale attività è aggiornata la documentazione dei processi, per riflettere le modifiche attuate per migliorare i processi stessi Definizione delle esigenze. Piano della Formazione. Sulla base dei requisiti del progetto, il Prestatore definisce le esigenze di acquisizione di nuove risorse specialistiche e/o di sviluppo delle capacità professionali esistenti all interno dell organizzazione. In particolare il Prestatore, in relazione alle attività indicate nel Piano di progetto, definisce la tipologia delle risorse necessarie con il livello di formazione richiesto e predispone un Piano di formazione, nel quale sono decritti i requisiti delle risorse, le necessità di formazione, i contenuti degli interventi formativi richiesti, le modalità di erogazione della formazione (corsi in aula, training on the job, ecc.), i materiali didattici e gli strumenti da utilizzare, i tempi di esecuzione. pag 34

35 Il Piano deve prevedere, inoltre, specifiche attività di valutazione del grado di apprendimento degli allievi, ai fini della valutazione dell efficacia del processo formativo. Nella pianificazione degli interventi formativi il Prestatore deve assicurare che personale adeguatamente formato sia disponibile in modo tempestivo per le attività pianificate Sviluppo del materiale di formazione. E l attività di predisposizione del materiale didattico e degli strumenti da utilizzare per eseguire gli interventi formativi, in accordo con quanto stabilito nel Piano di formazione Esecuzione della formazione. E l esecuzione del Piano di formazione, secondo tempi e modi ivi indicati. L attività dà luogo alle Registrazioni degli interventi formativi effettuati, che consentono di valutare l efficacia del processo formativo e di pianificare ulteriori interventi, in funzione di nuove esigenze Conclusione del progetto. E l attività conclusiva, che comprende l esecuzione di tutti gli adempimenti di fine contratto, la verifica del completamento effettivo di tutte le attività e la verifica finale, avente lo scopo di misurare il successo del Progetto rispetto agli obiettivi. E parte integrante dell attività la storicizzazione dei documenti e delle registrazioni prodotte nel corso della esecuzione del processo, che devono essere archiviati secondo modalità specificate nel contratto. Il risultato dell attività è l Archivio di progetto, inteso come l insieme di tutte le informazioni che lo definiscono e lo caratterizzano, in riferimento all intero ciclo di vita, raccolte, gestite ed utilizzate dalla nascita al completamento, ovvero fino alla conclusione del contratto con il Committente Chiusura del processo Il processo di Gestione si conclude quando risultano completate tutte le attività e gli adempimenti previsti dal contratto e siano soddisfatti gli obiettivi del Progetto. 6.2 Trasversale: Processo di Documentazione Obiettivi Obiettivo del processo è consentire al Prestatore la gestione sistematica dei documenti prodotti nel ciclo di vita del progetto. I meccanismi di gestione della documentazione si applicano sia ai documenti che ai dati. pag 35

36 I dati possono essere tabelle, grafici, diagrammi di flusso, banche dati, prospetti, dati informatici e qualunque altra forma di rappresentazione di informazioni relative al ciclo di vita della servizio. Il processo si esplica attraverso un insieme di attività volte a pianificare, progettare, produrre e distribuire i documenti necessari a tutte le entità organizzative interessate Attivazione del processo Il processo è svolto dal Prestatore in via continuativa, indipendentemente dai processi primari attivati con la sottoscrizione del contratto. La definizione delle modalità di gestione dei documenti connessi al ciclo di vita della servizio segue le attività iniziali del processo di Gestione del Progetto che, a propria volta, si conclude con le attività GE-A1, GE-A3, GE-A4, di cui al paragrafo e seguenti. Sono dati di input i requisiti indicati nei documenti che costituiscono la baseline di contratto, prodotti nell ambito dei processi di acquisizione e di servizio, nonché i documenti prodotti nell ambito del processo di progettazione, nei quali sono specificati regole, strumenti, standard e convenzione per la produzione e gestione dei documenti relativi alla servizio Attività e prodotti Nello schema che segue, si fornisce una rappresentazione delle attività proprie del processo di Documentazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti. Processo di Documentazione Attività Prodotti DO-A1 Pianificazione DOA1-01 Piano di gestione della documentazione DO-A2 Progettazione e sviluppo DOA2-01 Documento approvato DO-A3 Distribuzione e conservazione DOA3-01 Registrazioni DO-A4 Manutenzione DOA4-01 Documento approvato (nuova versione) Pianificazione. Il Prestatore deve definire e documentare le modalità per identificare tutti i documenti che devono essere prodotti durante il ciclo di vita della servizio e per regolamentare le relative modalità di progettazione, sviluppo, distribuzione, conservazione e manutenzione. I documenti prodotti nel ciclo di vita della servizio possono essere di origine interna e di origine esterna. I documenti di origine interna sono tutti i documenti generati all interno della organizzazione del Prestatore, prodotti nel corso della esecuzione del contratto; possono essere deliverable contrattuali, quali documenti di specifiche, manuali utente, documenti di pianificazione ed altro ovvero possono essere documenti contenenti istruzioni ovvero guide sulle attività da svolgere e sulle relative modalità di svolgimento. pag 36

37 I documenti di origine esterna includono i documenti prodotti da entità organizzative esterne all organizzazione del Prestatore e rilevanti per la servizio, quali ad esempio le norme, gli standard, i documenti emessi dal Committente, i documenti dei sub-fornitori, ecc. Tutti i documenti devono essere gestiti esclusivamente in configurazione secondo il loro livello di aggiornamento (revisione, versione, ecc.) e secondo le modalità previste di distribuzione e di conservazione. Il risultato dell attività di pianificazione è il Piano di gestione della documentazione, ovvero un documento o un insieme di documenti nel quale sono identificati e classificati, per tipologia e contenuti, secondo criteri ivi indicati, tutti i documenti che devono essere prodotti durante il ciclo di vita della servizio. Per ciascun documento identificato sono indicati un identificativo (titolo o nome), lo scopo, i destinatari, le procedure e responsabilità per input, sviluppo, riesami, modifiche, approvazioni, produzione, conservazione, distribuzione, manutenzione, gestione della configurazione, pianificazione delle versioni intermedie e finali Progettazione e sviluppo. Sulla base del Piano di gestione della documentazione, ciascun documento di origine interna identificato deve essere progettato secondo modelli di documentazione applicabili per quanto riguarda formati, descrizioni del contenuto, marcature di sicurezza e di proprietà ed altri eventuali elementi di presentazione, in accordo con i requisiti e con gli standard eventualmente fissati nei documenti contrattuali e/o nell ambito del processo di Progettazione. Completato il disegno dei documenti, è possibile attivare per ciascun documento il flusso di sviluppo, utilizzando strumenti automatici per la documentazione e prevedendo le appropriate forme di controllo (redazione, verifica ed approvazione) da parte di personale autorizzato, che ne verifica l adeguatezza rispetto ai requisiti indicati. Il risultato dell attività è il documento approvato, che può proseguire nel successivo iter di distribuzione e di conservazione, secondo le modalità fissate nel Piano di gestione della documentazione Distribuzione e conservazione. E l attività relativa alla distribuzione dei documenti e alla loro conservazione, secondo le modalità indicate nel Piano di gestione della documentazione. L attività riguarda sia i documenti di origine interna sia i documenti di origine esterna. La distribuzione è finalizzata ad assicurare che siano disponibili edizioni appropriate dei documenti a tutte le entità organizzative interessate, siano esse interne o esterne all organizzazione del Prestatore. Per la distribuzione possono essere utilizzati diversi supporti, quali carta, dispositivi elettronici o altre tipologie di supporto. La distribuzione è effettuata di regola secondo elenchi di distribuzione prestabiliti e può avvenire in forma controllata o non controllata, a seconda che sia a carico dell entità emittente distribuire eventuali nuove versioni del documento o debba essere l entità ricevente a richiederne eventuali nuovi aggiornamenti. pag 37

38 Per quanto riguarda la conservazione, di cui è parte integrante l archiviazione, i materiali originali devono essere conservati secondo i requisiti di tempi e modi relativi a conservazione delle registrazioni, riservatezza, sicurezza, manutenzione ed eventuali prescrizioni normative. La conservazione dei documenti deve prevedere modalità, quali ad esempio la gestione di elenchi dei documenti, atte ad impedire l utilizzo di documenti non più validi e superati. Il risultato dell attività è rappresentato dalle Registrazioni relative alla distribuzione ed alla conservazione dei documenti Manutenzione. Nel caso in cui i documenti di origine interna, approvati e distribuiti, debbano essere modificati, si applica il processo di manutenzione, con particolare riferimento alle attività di analisi dei problemi e delle modifiche, esecuzione delle modifiche, riesame/accettazione delle modifiche. La progettazione e lo sviluppo del documento modificato la relativa distribuzione e conservazione, sono condotte attraverso le attività sopra descritte e secondo il Piano di gestione della documentazione. Per i documenti da gestire in configurazione, le modifiche devono essere apportate in accordo con il processo di gestione della configurazione. Il risultato dell attività è costituito dal documento nella nuova versione Chiusura del processo Il processo di Gestione della documentazione si chiude con la conclusione del ciclo di vita della servizio, quando risultino completate tutte le attività relative alla distribuzione e conservazione dei documenti ed in generale tutte le attività previste nel Piano di gestione della documentazione. 6.3 Trasversale: Processo di Assicurazione Qualità Obiettivi Il processo ha l obiettivo di fornire adeguate assicurazioni che i prodotti ed i processi svolti nel ciclo di vita della servizio siano conformi ai requisiti specificati e conformi ai relativi piani. Il processo di Assicurazione Qualità dovrà essere svolto in modo coordinato con i processi di Verifica, Validazione, Riesame congiunto, Verifica Ispettiva e Risoluzione dei problemi. Per tale motivo detti processi, nel seguito, sono visti come attività proprie del processo di Assicurazione Qualità, essendo ad esso strettamente collegati. pag 38

39 6.3.2 Attivazione del processo L avvio del processo segue le attività iniziali del processo di Gestione del Progetto che, a propria volta, si conclude con le attività GE-A1, GE-A3, GE-A4, di cui al paragrafo e seguenti. Il processo è svolto dal Prestatore secondo attività pianificate, in accordo quanto definito nel Piano di qualità Attività e prodotti Nello schema che segue si fornisce una rappresentazione delle attività del processo di Assicurazione Qualità; sono incluse in tale ambito anche le attività proprie dei processi di Verifica, Validazione, Riesame congiunto, Verifiche ispettive e Risoluzione dei problemi, in quanto sono strettamente connesse all assicurazione qualità. Per tutte le attività ed i prodotti evidenziati, si fornisce a seguire una descrizione delle finalità e dei contenuti. Processo di Assicurazione Qualità Attività Prodotti AQ-A1 Pianificazione AQA1-01 Piano di assicurazione qualità AQ-A2 Assicurazione qualità AQA2-01 Registrazioni AQ-A3 Verifica AQA3-01 Registrazioni AQ-A4 Validazione AQA4-01 Registrazioni AQ-A5 Riesame congiunto AQA5-01 Registrazioni AQ-A6 Verifica ispettiva AQA6-01 Piano di verifica AQA6-02 Rapporto di verifica AQ-A7 Risoluzione dei problemi AQA7-01 Piano di gestione dei problemi AQA7-02 Registrazioni Pianificazione. Sulla base dei requisiti del Progetto e in accordo con il Piano di qualità ed il Piano di progetto, il Prestatore deve sviluppare ed attuare, per tutta la durata del contratto, un Piano di assicurazione qualità che contenga i seguenti elementi: livelli di qualità, metodologie, procedure e strumenti per svolgere le attività di assicurazione qualità; procedure relative al riesame del contratto ed alla conseguente coordinazione; risorse, programma temporale e responsabilità della conduzione delle attività di assicurazione qualità, ivi incluse le attività di Verifica, Validazione, Riesame congiunto, Verifica ispettiva Assicurazione qualità. L attività si specializza nelle seguenti: Assicurazione di prodotto: è volta ad assicurare che tutti i piani predisposti in esecuzione del contratto soddisfino il contratto stesso, siano tra di loro compatibili e pag 39

40 siano eseguiti secondo le modalità richieste. E finalizzata, inoltre, ad assicurare che i prodotti siano realizzati in aderenza ai piani e che, al momento della consegna, soddisfino i requisiti contrattuali e siano accettabili dal Committente. Assicurazione di processo: è finalizzata ad assicurare che tutti i processi relativi al ciclo di vita del servizio (Servizio, Progettazione, Realizzazione, Gestione operativa, Manutenzione e processi di supporto), sviluppati in esecuzione del contratto, soddisfino il contratto stesso e siano aderenti ai piani. Ha l obiettivo, inoltre, di assicurare che quanto realizzato da eventuali sub-fornitori soddisfi i requisiti del contratto principale stipulato dal Prestatore con il Committente. Assicurazione del sistema qualità: include le ulteriori attività di gestione della qualità che devono essere assicurate secondo i requisiti della norma ISO 9001 e per come specificato nel contratto. Il risultato dell attività è rappresentato dalle Registrazioni relative alle attività svolte ed ai risultati conseguiti Verifica. Le verifiche sono eseguite, secondo piani, su attività e prodotti del ciclo di vita che si ritengono critici in base alle finalità, all impatto sul Progetto ed alla complessità. La verifica può specializzarsi nelle seguenti attività: Verifica del contratto: ha lo scopo di verificare aspetti quali la capacità del Prestatore di soddisfare i requisiti, la coerenza dei requisiti e l adeguatezza rispetto alle necessità dell utente, l esistenza di procedure formali per la gestione delle modifiche ai requisiti, per la risoluzione dei problemi, per l accettazione della servizio e per la gestione dei rapporti tra i contraenti; Verifica del processo: è volta a verificare che ciascun processo sviluppato per l esecuzione del progetto sia adeguato ed eseguito secondo i piani ed in accordo con il contratto e che il personale assegnato sia adeguato alle esigenze ed opportunamente formato, come richiesto dal contratto; Verifica dei requisiti: è eseguita al fine di assicurare che i requisiti siano coerenti, fattibili, verificabili e che siano appropriatamente distribuiti sugli elementi hardware, sugli elementi software e sulle attività manuali, in accordo con i criteri di progettazione e possano essere sottoposti a prove; Verifica della progettazione: ha lo scopo di assicurare la correttezza e la coerenza della soluzione progettuale rispetto ai requisiti; Verifica del prodotto: è volta a determinare che il prodotto software, il sistema o, più in generale, il risultato di un attività soddisfi i requisiti o le condizioni imposti dalle attività precedenti, che detti elementi siano tracciabili verso la progettazione e verso i requisiti, che siano corretti e verificabili; Verifica della integrazione: è volta a verificare che le unità ed i componenti software di ciascun elemento siano stati completamente e correttamente integrati, che gli elementi hardware, gli elementi software e le attività manuali siano stati completamente e correttamente integrati nel sistema, e che i compiti e le attività di integrazione siano state svolti secondo i piani; Verifica della documentazione: ha lo scopo di assicurare che la documentazione sia adeguata, completa e coerente, che sia prodotta tempestivamente e che sia gestita in configurazione secondo le procedure previste. Il risultato dell attività è rappresentato dalle Registrazioni relative alle attività svolte e ai risultati conseguiti. pag 40

41 6.3.7 Validazione. La validazione ha lo scopo di determinare che il prodotto realizzato soddisfi i requisiti iniziali, fissati nel contratto, e che operi correttamente in relazione alla sua destinazione d uso. L attività è condotta secondo un piano (Piano di test ovvero documento equivalente) nel quale sono indicati gli elementi da validare, i test da eseguire, le risorse necessarie e le relative responsabilità, il programma temporale di esecuzione dei casi di test, le modalità di notifica dei risultati agli interessati. Il risultato dell attività è rappresentato dalle Registrazioni relative alle attività svolte, di cui sono parte integrante i risultati dei test eseguiti (Test Data Report) Riesame congiunto. E eseguito dalle parti contraenti, il Committente e il Prestatore, con lo scopo di valutare lo stato ed i prodotti di un attività; il riesame congiunto può essere eseguito periodicamente per tutta la durata del contratto, secondo date indicate nel Piano di progetto. In ogni caso è eseguito previa definizione dei prodotti e dei problemi oggetto di riesame, delle risorse coinvolte, dei mezzi e delle modalità di conduzione. Il riesame congiunto può essere: Riesame della gestione del progetto: è volto a valutare lo stato del progetto in relazione ai piani di progetto, ai documenti di stato avanzamento lavori, alle norme e linee guida applicabili. Ciò allo scopo di verificare che le attività procedano secondo i piani e di intraprendere, eventualmente, le opportune azioni per modificare la direzione del progetto e/o valutare e gestire i rischi rilevati; Riesame tecnico: è condotto sui prodotti delle attività, con lo scopo di verificare che essi siano completi, conformi alle norme e alle specifiche, nonché che siano realizzati in accordo con il programma temporale e possano essere dati in input all attività successiva. L attività è anche volta a verificare che la progettazione, la realizzazione, la gestione operativa e la manutenzione siano condotte secondo i piani. Il risultato dell attività è rappresentato dalle Registrazioni relative alle attività svolte e ai risultati conseguiti. Per quanto riguarda i risultati, in particolare, le parti devono concordare quanto necessario al compimento delle azioni conseguenti Verifica ispettiva. Le Verifiche Ispettive interne (verifiche ispettive di prima parte), di responsabilità del Prestatore, sono eseguite allo scopo di determinare se le attività svolte ed i risultati ottenuti sono in accordo con quanto pianificato e risultano adeguati per il conseguimento degli obiettivi contrattuali. Sono programmate e condotte periodicamente, secondo date indicate nei piani di progetto, e sono effettuate da personale con competenze multidisciplinari, individuato in modo da assicurare la completa indipendenza da chi ha diretta responsabilità per le attività ed i prodotti sottoposti a verifica. pag 41

42 L esecuzione di ciascuna verifica ispettiva è preceduta dalla predisposizione e dall invio alla/e organizzazione/i interessata/e di un Piano di verifica, volto a stabilire obiettivi ed estensione della verifica, attività e prodotti oggetto di verifica, entità organizzative interessate, modalità di esecuzione, documenti di riferimento e criteri di entrata e di uscita della verifica. La verifica è di regola condotta attraverso colloqui con il personale, esame delle registrazioni delle attività interessate e dei relativi prodotti, esame dei documenti di riferimento ed osservazione diretta del modo di operare rispetto ai documenti di riferimento. A conclusione della verifica viene redatto un rapporto di verifica, o documento equivalente, distribuito alla parte verificata ed alle entità organizzative interessate, nel quale sono indicati i risultati della verifica e la pianificazione delle azioni di soluzione ai problemi o alle non conformità rilevate Risoluzione dei problemi. Il processo ha l obiettivo di analizzare i problemi e le non-conformità, qualunque sia la loro natura o origine, che vengono individuati durante l esecuzione dei processi del ciclo di vita del servizio. L obiettivo è fornire un modo tempestivo, responsabile e documentato per assicurare che tutti i problemi rilevati siano analizzati e risolti nonché per assicurare che siano individuati per tempo criticità che potrebbero diventare problemi da risolvere, al fine di intraprendere tempestivamente adeguate azioni preventive. I problemi e le non-conformità relativi ad attività e prodotti devono essere gestiti dal Prestatore secondo un ciclo chiuso, in grado di assicurare che per ciascun problema sia intrapresa una azione, che le parti interessate siano informate dell esistenza del problema e della sua evoluzione, che siano identificate, analizzate e rimosse le cause e siano fornite soluzioni in merito, che sia tracciato e riportato lo stato del problema e siano conservate le relative registrazioni, in accordo con quanto previsto dal contratto. Per ciascun problema il Prestatore, in un Piano di gestione dei problemi o in un documento equivalente, deve definire le modalità di gestione, provvedendo in particolare a classificare ciascun problema per categoria e priorità, secondo uno schema predefinito, ad eseguire analisi volte a verificare l impatto del problema sul progetto, le linee di tendenza, le soluzioni da implementare, le responsabilità ed i tempi per implementare le soluzioni, le relative modalità di esecuzione e verifica. Le verifiche devono assicurare che le modifiche siano state apportate correttamente, che non abbiano introdotto ulteriori problemi e che le linee di tendenza negative siano state invertite. L esecuzione del Piano di gestione dei problemi, documentata dalle Registrazioni relative alle attività svolte, consente la risoluzione del problema e delle sue cause, che deve essere verificata secondo quanto previsto nel Piano e notificata tempestivamente alle parti interessate Chiusura del processo Il processo di Assicurazione Qualità è attuato in via continuativa fino alla conclusione di tutti i processi svolti dal Prestatore per eseguire la servizio oggetto del contratto. Le Registrazioni ed i prodotti delle attività relative al processo di Assicurazione Qualità devono essere resi disponibili al Committente. pag 42

43 6.4 Implementazione: Processo di Progettazione Obiettivi Obiettivo della Progettazione è specificare le caratteristiche della servizio a partire dai requisiti indicati negli atti contrattuali, definendo le modalità di realizzazione, di verifica e di collaudo, di gestione operativa e manutenzione della servizio, anche con riferimento ai mezzi ed alle risorse umane e materiali necessarie per svolgere tutte le attività proprie dei processi Attivazione del processo Il processo è svolto dal Prestatore ed è attivato a seguito delle attività iniziali del processo di Gestione del Progetto che, a propria volta, si conclude con le attività GE-A1, GE-A3, GE-A4, di cui al paragrafo e seguenti. Sono dati di input del processo l insieme dei documenti che costituiscono la Baseline di contratto prodotti nell ambito dei processi di Acquisizione e di Servizio, ovvero il Contratto, il Capitolato tecnico, l Offerta tecnico-economica del Prestatore Attività e prodotti Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di Progettazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti. Processo di Progettazione Attività Prodotti PR-A1 Analisi dei requisiti PRA1-01 Specifica dei requisiti PR-A2 Progettazione tecnica PRA2-01 Architettura tecnica PRA2-02 Specifiche dei servizi PRA3-01 Specifiche funzionali PR-A3 Progettazione applicativa PRA3-02 Disegno della Base Dati PRA3-03 Prototipo PR-A4 Progettazione Test e Collaudi PRA4-02 Specifiche di Collaudo Analisi dei Requisiti. A partire dai contenuti del servizio indicati nei documenti di gara, il Prestatore definisce tutti i requisiti, espliciti, impliciti ed obbligatori, che regoleranno la erogazione del servizio nel corso della esecuzione del contratto. In tale attività è necessario preliminarmente identificare con precisione tutti gli attori interessati alla erogazione del servizio, i destinatari diretti e gli utenti finali e confermare/rivedere le rispettive necessità relative ad obiettivi e requisiti della servizio. Sulla base delle necessità degli utenti, delle relative priorità e delle caratteristiche specifiche di ogni tipologia di servizio, devono essere definiti e documentati i requisiti sia organizzativi sia pag 43

44 legati a profili utenti e casi d uso, i requisiti di sicurezza e di riservatezza, i requisiti di ingegneria dei fattori umani (ergonomia), i requisiti del sistema, del prodotto software e/o del servizio, con riferimento al profilo di qualità previsto nel Piano di qualità ed alle caratteristiche di funzionalità, usabilità, manutenibilità, prestazioni ed altro; i requisiti di progettazione, realizzazione, gestione operativa e di manutenzione, i requisiti di qualificazione, i vincoli normativi e/o di aderenza a standard, i vincoli tecnologici, i vincoli ambientali e/o legati al riuso di componenti, le esigenze di addestramento degli utenti. Nella specificazione dei requisiti deve essere assicurata la soddisfazione delle necessità del Committente, la coerenza con le necessità stesse, la fattibilità della progettazione, della gestione operativa e della manutenzione. Il risultato dell attività è costituito dalla Specifica dei requisiti, ovvero da un documento o insieme di documenti, nei quali sono descritti tutti i requisiti della servizio, identificati e classificati, nel senso sopra indicato, secondo criteri documentati Progettazione Tecnica. Sulla base dei requisiti indicati nella Specifica dei requisiti, il Prestatore definisce l architettura tecnica del sistema. L architettura tecnica individua le componenti hardware, software oltre che le eventuali esigenze infrastrutturali del sistema, le relative configurazioni e le operazioni manuali. Il Prestatore definisce il servizio da fornire e le relative modalità di realizzazione, di erogazione e di controllo delle caratteristiche di qualità. Per la soluzione progettuale devono essere garantite la rintracciabilità dei requisiti, la coerenza con i requisiti stessi, l adeguatezza delle norme di progetto e dei metodi utilizzati, la fattibilità della realizzazione, della gestione operativa e della manutenzione. Il risultato dell attività è costituito dalle seguenti tipologie di prodotti: architettura tecnica: documento o insieme di documenti, nel quale è descritta la soluzione progettuale, ovvero l architettura hardware e software del sistema che realizza gli ambienti logici di sviluppo, collaudo ed esercizio; specifiche del servizio: documento in cui è descritto il servizio con le relative caratteristiche (Specifiche del servizio), i mezzi e le modalità per realizzare ed erogare il servizio (Specifiche di realizzazione del servizio) e per controllare i livelli di qualità (Specifiche di controllo qualità) Progettazione Applicativa. Con riferimento ai requisiti del prodotto software da sviluppare e/o del servizio da erogare, indicati nella Specifica dei requisiti, il Prestatore definisce l architettura del prodotto e gli elementi software dettagliando, per ciascun elemento, le componenti ad alto livello e le relative unità software (moduli applicativi) che devono essere codificate e sottoposte a prova. Il Prestatore definisce, altresì, le interfacce (tra unità software, tra componenti, tra prodotto ed utente), il disegno concettuale, logico e fisico della Base Dati, la documentazione utente (manuali, help, tutorial, wizard, ed altro), il diagramma delle classi e delle interazioni e quanto specifico in funzione della tecnologia di sviluppo da adottare. Nella soluzione progettuale deve essere garantita la rintracciabilità dei requisiti e la coerenza esterna con i requisiti, la coerenza interna tra i componenti e le unità software, la fattibilità della realizzazione, della gestione operativa e della manutenzione. pag 44

45 Il risultato dell attività può essere costituito dalle seguenti tipologie di prodotti: Specifiche funzionali: documento o insieme di documenti nei quali è indicata l architettura e le componenti software, il dettaglio dei moduli applicativi, il disegno delle interfacce e della documentazione utente. Il documento contiene la rappresentazione dei processi e del flusso di dati che tali processi utilizzano e trasformano, le interazioni tra il prodotto da realizzare ed il sistema. Disegno della Base Dati: documento o insieme dei documenti nei quali è descritto il modello concettuale e logico dei dati. Prototipo: modello che contiene tutte le caratteristiche tecniche (funzionali, prestazionali, di usabilità, ecc.) di un prodotto Progettazione Test e Collaudi. E parte integrante del processo di progettazione, la definizione dei test interni (test unitari, test funzionali, test di prodotto, test di integrazione, test di sistema e test di qualificazione finale) che dovranno essere eseguiti dal Prestatore prima del rilascio del pronti al collaudo, per garantire che quanto realizzato sia conforme ai requisiti indicati nella Specifica dei Requisiti e agli obiettivi fissati nel Piano di qualità. Tutti i test interni dovranno essere descritti nel Piano di test, ovvero in un documento o in un insieme di documenti nel quale, oltre ai casi di test, sono descritti l ambiente e le risorse necessarie per l esecuzione dei casi di test e le modalità di gestione delle anomalie, in coerenza con il processo di Risoluzione dei problemi. In fase di esecuzione del collaudo, la Commissione di Collaudo incaricata dal Committente può prendere visione del Piano dei test e dei relativi risultati (Test Data Report). Nel corso di tale attività il Prestatore deve specificare le operazioni di verifica che saranno effettuate dal Committente per eseguire il collaudo. La Committente ha facoltà di implementare le modalità con cui saranno eseguiti i collaudi. Nella descrizione delle prove di Collaudo deve essere garantita la rintracciabilità dei requisiti indicati nei documenti contrattuali e nella Specifica dei Requisiti e la coerenza con i requisiti stessi. Il risultato dell attività è costituito dalle Specifiche di Collaudo, ovvero da un documento o insieme di documenti che potranno essere utilizzati a titolo di guida dalla Commissione di Collaudo nominata dal Committente per eseguire il Collaudo. Il documento definisce le prove di Collaudo in coerenza con i requisiti indicati nei documenti contrattuali e meglio dettagliati nella Specifica dei requisiti; definisce le specifiche dell ambiente di Collaudo, che dovrà riprodurre fedelmente l ambiente di esercizio, e le figure professionali che saranno messe a disposizione dal Prestatore per assistere la Commissione nella esecuzione delle operazioni di Collaudo. In coerenza con quanto indicato nel successivo Paragrafo , il documento di Progettazione di Test e Collaudi dovrà essere oggetto di revisione, nel corso del Processo di Realizzazione e Collaudo, in coerenza con le eventuali variazioni che impattano su quanto previsto nel Processo di Progettazione Chiusura del processo La progettazione deve essere sottoposta a Verifica, allo scopo di assicurare la correttezza e la coerenza rispetto ai requisiti in ingresso. pag 45

46 Il processo si conclude di norma con un riesame della progettazione, ovvero con un analisi formale della capacità di quanto progettato di soddisfare i requisiti, espliciti, impliciti ed obbligatori, indicati nei documenti di gara e/o espressi dal Committente. La funzione è a carico del Prestatore ed è svolta in collaborazione formalizzata con il Committente, nell ambito del processo di Riesame congiunto. Il riesame si completa con la Validazione da parte del Prestatore e l approvazione formale dei prodotti del processo da parte del Committente, approvazione che definisce la baseline di progettazione. Il processo di Progettazione produce alla fine i seguenti risultati: conferma/specifica dei requisiti utente; baseline di progettazione, intesa come insieme dei documenti che descrivono la soluzione progettuale e che regolano le modalità di realizzazione, di gestione operativa e di manutenzione della servizio; aggiornamento dei prodotti del processo di Gestione, (Piano di progetto, Piano di qualità, ecc.) Approfondimento dei contenuti e delle modalità del Processo In stretta aderenza a quanto indicato nel paragrafo 4.3.2, si evidenziano alcuni aspetti da ritenere obbligatori per lo svolgimento del Processo di Progettazione e, di conseguenza, anche per il successivo Processo di Realizzazione e Collaudo. Il primo concerne la nomenclatura e standard di coding, la cui definizione deve essere considerata mandatoria nell ambito della progettazione. Ai fini della chiusura del processo, l assenza ovvero la parzialità della definizione darà luogo alla non accettazione del servizio erogato dal Prestatore, con la contestuale applicazione delle azioni correttive correlate. Il secondo aspetto, da ritenere centrale nell ambito del rapporto tra Committente e Prestatore nel corso della Fase di Implementazione, riguarda l applicazione del principio di flessibilità e leggerezza che devono essere alla base della modalità di lavoro. La chiusura del Processo di Progettazione e la contestuale approvazione dei documenti di output non precludono, in alcun modo, la possibilità del Committente di realizzare un tuning delle soluzioni individuate, oggetto del Processo di Realizzazione e Collaudo, con l obiettivo di conseguire il migliore risultato oggettivamente possibile, nell ottica di massimizzazione del proprio investimento. Sulla base dell esperienza accumulata dal Committente nella realizzazione di progetti con le medesime caratteristiche, l applicazione del cennato principio di flessibilità può avere un impatto quantitativamente identificabile come segue: nel corso del primo terzo del Processo di Realizzazione e Collaudo, di una percentuale che impatta mensilmente dal 8% al 10% dell effort individuato da Committente e Prestatore nel corso del Processo di Progettazione; nel corso del secondo terzo del Processo di Realizzazione e Collaudo, di una percentuale mensile di impatto che va dal 5% al 8%; nel corso dell ultimo terzo, di una percentuale mensile pari al 5% di effort. La definizione di quanto sopra costituisce, pertanto, un approfondimento non esaustivo di quanto definito nel paragrafo 4.3.2, rimandando al Prestatore la possibilità di indicare, in fase di offerta, modalità in grado di esaltare maggiormente l applicazione dei principi sopra elencati. pag 46

47 6.5 Implementazione: Processo di Realizzazione e Collaudo Obiettivi Obiettivo della Realizzazione è l implementazione della soluzione progettuale, in termini di infrastruttura tecnologica, codice, basi di dati, documentazione utente, servizi; seguono l esecuzione dei test ed il Collaudo di quanto realizzato, secondo le specifiche prodotte nel processo di Progettazione Attivazione del processo Il processo è svolto sotto la responsabilità del Prestatore e partecipato solo ai fini del controllo della correttezza degli avanzamenti dalla Committente nella misura in cui è stabilito dalla modalità di lavoro applicata (vedi par ), ed è attivato a chiusura del processo di Progettazione. Sono dati di input del processo la Specifica dei requisiti e l insieme dei documenti che costituiscono la baseline di progettazione, prodotti nell ambito del processo di Progettazione Attività e prodotti Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di Realizzazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti. Processo di Realizzazione e Collaudo Attività Prodotti RE-A1 Codifica REA1-01 Prodotto software RE-A2 Predisposizione del sistema REA1-02 Infrastruttura di Collaudo e di esercizio RE-A3- Produzione della documentazione REA1-03 Documentazione utente RE-A4 Qualificazione finale REA4-01 Certificazione di rilascio al Collaudo RE-A5 Installazione REA5-01 Piano di installazione REA6-01 Verbale di Collaudo RE-A6 Collaudo REA6-02 Servizio (prodotto software - sistema - documentazione utente) in esercizio nella configurazione di base Codifica. In accordo con i documenti di output del processo di Progettazione, il Prestatore avvia la realizzazione di quanto richiesto contrattualmente e, sulla base delle Specifiche funzionali, pag 47

48 realizza il prodotto, procedendo alla codifica del software, sviluppando e documentando moduli, componenti e banche dati. A completamento dei test unitari sui singoli moduli il Prestatore, per ciascun elemento software definito nel processo di Progettazione, procede alla integrazione delle unità software e dei componenti, eseguendo quindi i test funzionali per verificare che nell insieme gli aggregati soddisfino i requisiti dell elemento software. Segue quindi l integrazione degli elementi software e l esecuzione del test di prodotto, volto a verificare che il software realizzato, con relativi dati e documentazione, soddisfi i requisiti specificati nel processo di Progettazione. È parte integrante dell attività la produzione di procedure operative che regolamentino sia le modalità di gestione operativa che le modalità di manutenzione. Il risultato dell attività è il Prodotto software, ovvero l insieme degli elementi software integrati, con relativi dati e documentazione nella configurazione finale risultante dal test di prodotto Predisposizione del sistema. In accordo con i documenti che descrivono l architettura tecnica e/o le Specifiche di realizzazione del servizio, il Prestatore procede alla predisposizione della infrastruttura hardware e software necessaria per realizzare il sistema che ospiterà gli ambienti logici di collaudo e di esercizio, provvedendo ad eseguire l installazione e l integrazione delle componenti. In accordo con il Piano di Test, il Prestatore esegue i test unitari delle specifiche componenti, i test di integrazione, volti soprattutto a verificare gli aspetti di integrazione inter-intra componenti ed i test di sistema, volti a verificare il corretto funzionamento del sistema rispetto ai requisiti specificati nel processo di Progettazione. È parte integrante dell attività la produzione di procedure operative per regolamentare sia le modalità di gestione operativa, sia le modalità di manutenzione. Il risultato dell attività è l Infrastruttura che ospiterà gli ambienti logici di Collaudo ed esercizio, intesa come insieme di componenti integrati, con relativa documentazione, con le procedure e con quanto propedeutico all installazione ed esercizio del prodotto software sviluppato o all erogazione del servizio, nella configurazione finale risultante dal test di sistema Produzione della documentazione. Parallelamente alla codifica del software e/o alla predisposizione del sistema il Prestatore procede alla produzione della Documentazione utente (manuali utente, tutorial, help, wizard ed altro). La documentazione utente deve essere predisposta secondo standard e requisiti fissati nel processo di Progettazione e deve essere oggetto di verifiche formalizzate per verificarne la successiva corrispondenza. Le verifiche devono inoltre accertare l accuratezza, la comprensibilità e più in generale l usabilità della documentazione. pag 48

49 6.5.7 Qualificazione finale. Propedeutica al Collaudo presso il Committente è l esecuzione di test di validazione o qualificazione finale di quanto realizzato (prodotto software; infrastruttura di Collaudo ed esercizio; documentazione utente), come ultima valutazione dello stato di consolidamento della servizio e della sua capacità di superare il Collaudo finale. I risultati di tale test, insieme a quelli di tutti i test, verifiche, validazioni e riesami effettuati precedentemente, anche relativamente ai prodotti output del processo di Progettazione, concorrono alla formulazione, da parte del Prestatore, di una Certificazione di rilascio al Collaudo Installazione. L attività riguarda l installazione del prodotto software sviluppato nell ambiente di esercizio e/o l esecuzione di compiti, non svolti nell ambito dell attività di Predisposizione del sistema, volti a rendere operativo il sistema o l ambiente di erogazione del servizio. Detti compiti possono riguardare, senza la pretesa di essere esaustivi: l attivazione di profili utente per la sicurezza; l attivazione di postazioni di lavoro; la configurazione di prodotti software; l eventuale caricamento iniziale di dati nelle basi dati, a partire da sistemi preesistenti (legacy system) per il tramite di attività di migrazione ovvero direttamente da dati cartacei tramite attività di acquisizione dati (data entry). L attività è svolta secondo un Piano di installazione, correlato al Piano di progetto, nel quale sono indicati attività, tempi, modi e risorse necessarie. Il risultato dell attività è il sistema che ospita l ambiente di erogazione del servizio, con il prodotto software sviluppato e le relative basi dati installate e correttamente funzionanti, secondo i requisiti contrattuali e progettuali ovvero con tutto quanto necessario a garantire l erogabilità dei servizi oggetto di servizio, nel rispetto dei requisiti contrattuali e di progettazione Collaudo. L attività è eseguita da una Commissione di Collaudo nominata dal Committente ed individuata, nella sua composizione, sulla base delle capacità professionali e di giudizio richieste. La Commissione opera con autonoma responsabilità e secondo le prescrizioni della normativa di riferimento ed ha il compito di verificare che quanto realizzato dal Prestatore sia conforme ai requisiti indicati nella baseline di contratto. Possono essere oggetto di Collaudo, secondo quanto richiesto nel contratto, il prodotto software realizzato, il sistema che ospita l ambiente di esercizio, il modello di funzionamento del servizio oggetto di servizio e tutta la documentazione utente. Le prove di Collaudo sono di regola eseguite nell ambiente di Collaudo predisposto dal Prestatore secondo quanto specificato nel processo di Progettazione. Il Prestatore deve supportare la Commissione nella esecuzione delle prove, nel rilevamento dei risultati, nella stesura del rapporto finale. pag 49

50 Per svolgere le prove di Collaudo la Commissione può utilizzare, a titolo di guida, le Specifiche di Collaudo predisposte dal Prestatore nell ambito del processo di Progettazione e può prendere visione dei risultati dei test interni eseguiti dal Prestatore nel corso del processo di Realizzazione e di ogni registrazione concernente le attività di Riesame, Verifica e Validazione svolta. Il Piano di Collaudo, la documentazione di esecuzione delle prove e delle non-conformità rilevate dovranno essere formalizzati in documenti. La verifica con esito positivo della servizio termina con l emissione di un Verbale con esito positivo relativo al Collaudo, che sancisce la conformità ai requisiti contrattuali del prodotto software e/o l erogabilità del servizio oggetto di servizio. L accettazione da parte del Committente dell esito positivo del Collaudo, dà luogo all accettazione della servizio. In caso di esito negativo del Collaudo e/o di non-conformità rispetto ai requisiti contrattuali, il Prestatore, in accordo con il processo di Risoluzione dei problemi, è tenuto a rimuovere i malfunzionamenti e a svolgere nuovamente il Collaudo, nei tempi e nei modi stabiliti. La conclusione del Collaudo con esito positivo e l accettazione da parte del Committente della servizio, comportano il congelamento della configurazione di base del prodotto software e/o del sistema che ospita l ambiente di erogazione del servizio Avviamento alla gestione operativa. Successivamente all accettazione della servizio è previsto l avvio della Fase di Gestione che consisterà, tra l altro, nell esercizio del prodotto software nella configurazione di base presso utenze pilota. Tale attività avrà l obiettivo di verificare l affidabilità, le prestazioni, l usabilità, la sicurezza del prodotto e la sua manutenibilità. In questo contesto sarà fornito un Rapporto su qualità e prestazioni del prodotto software in cui sono riportati gli indicatori rilevati ed il relativo andamento rispetto ai valori di soglia e/o target di riferimento prefissati Chiusura del processo La Realizzazione si conclude con il completamento con esito positivo del Collaudo. Il processo produce, in sintesi, i seguenti risultati: rilascio del prodotto software e/o del sistema che realizza l ambiente di erogazione del servizio, corredati della relativa documentazione utente; detti elementi sono individuati e documentati, nelle loro componenti, nella configurazione risultante dal Collaudo, che rappresenta la configurazione di base per le successive attività previste nell ambito dei processi di Gestione operativa e Manutenzione; rilascio della documentazione utente, nella configurazione risultante dal Collaudo; aggiornamento della baseline di progettazione e dei prodotti del processo di Gestione. pag 50

51 6.6 Gestione: Processo di Gestione operativa Obiettivi Obiettivo del processo è l erogazione dei servizi, unita alla conduzione funzionale e tecnica del sistema Attivazione del processo Il processo è attivato al termine del processo di Realizzazione, con la messa in esercizio del prodotto software e/o del sistema che ospita l ambiente di erogazione del servizio, corredati della documentazione utente e della documentazione necessaria per la gestione. In particolare sono input del processo, oltre ai prodotti delle attività di Realizzazione, la Specifica dei requisiti, le Specifiche del servizio, le Specifiche di realizzazione del Servizio e le Specifiche di controllo qualità del servizio, prodotte nel processo di Progettazione, come eventualmente modificate dal processo di Realizzazione, nonchè le procedure operative prodotte nell ambito del processo di Realizzazione Attività e prodotti Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di Gestione operativa e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti. Processo di Gestione operativa Attività GO-A1 Prove delle forniture rilasciate in esercizio Prodotti GOA1-01 GO-A2 Gestione operativa GOA2-01 Servizio (prodotto software sistema - documentazione utente) nella nuova configurazione Registrazioni relative alla conduzione tecnico-funzionale del sistema Prove delle forniture rilasciate in esercizio. Per ogni nuova versione dei componenti del prodotto software e/o del sistema rilasciata in esercizio, il Prestatore deve svolgere appropriati test che verifichino la capacità del componente (nella versione in prova) di soddisfare i requisiti specificati per la sua gestione operativa. L esecuzione di tali test deve essere propedeutica alla accettazione in gestione operativa del componente. In particolare, i test devono accertare che il componente si attivi, esegua correttamente le sue funzioni, termini le sue attività così come descritto nei manuali di gestione operativa e nei piani relativi e che non determini malfunzionamenti nelle altre componenti del sistema (test di non regressione). Il risultato dell attività è il prodotto software e/o il sistema nella nuova configurazione (configurazione corrente). pag 51

52 Gestione Operativa. In accordo con le Specifiche di realizzazione del servizio e le Specifiche di controllo qualità del servizio, il Prestatore eroga il servizio oggetto di servizio. Oltre ai compiti che sono specifici della tipologia di servizio da erogare, indicati nei documenti sopra citati, il Prestatore nell ambito di tale attività svolge in via continuativa un insieme di compiti che sono finalizzati a garantire che il sistema operi in accordo con quanto contenuto nelle Specifiche del servizio e nella documentazione utente e che rendono possibile la corretta fruizione del servizio da parte dell utente finale. Detti compiti possono includere, ad esempio: inizializzazione e disattivazione di componenti del sistema; presidio degli strumenti di controllo e degli ambienti di controllo; gestione delle procedure operative; gestione degli accessi e delle convenzioni; interventi sui malfunzionamenti hardware e software per il ripristino delle funzionalità; controllo della operatività del sistema e gestione delle procedure di restart e recovery; gestione dei supporti utilizzati nella gestione dei dati e delle stampe; schedulazione ed esecuzione delle attività e produzione rapporti di riepilogo. L attività di Gestione operativa deve essere svolta in accordo con il Piano di progetto, il Piano di qualità ed eventuali documenti correlati ed in accordo con le procedure e la documentazione predisposta allo scopo nell ambito del processo di Realizzazione. Nello svolgimento di questa attività, devono essere identificate, registrate e risolte, le anomalie riscontrate, in accordo con il processo di Risoluzione dei problemi. È parte integrante dell attività la predisposizione ed attivazione del sistema per controllare in via continuativa che le Specifiche del servizio siano soddisfatte e per rilevare e misurare la qualità del servizio erogato. Le registrazioni delle misure effettuate devono permettere di valutare l andamento del servizio e le azioni correttive/preventive da intraprendere per assicurare il rispetto dei requisiti di qualità contrattuali. Il risultato dell insieme dei compiti che il Prestatore svolge nella Gestione operativa è costituito dalle Registrazioni delle attività svolte per garantire il corretto funzionamento del sistema e l erogazione del servizio all utente finale in accordo con le Specifiche del servizio e la documentazione utente Assistenza agli utenti. Il Prestatore, su richiesta, deve fornire assistenza e consulenza agli utenti nell utilizzo del sistema. Le richieste di assistenza, che devono essere registrate e tracciate fino alla loro conclusione, possono dare luogo a modifiche al sistema. Tali modifiche, che possono consistere in correzioni permanenti, nuove versioni che includano funzionalità o funzioni precedentemente omesse o miglioramenti del sistema, devono essere gestite in accordo con il processo di Manutenzione. pag 52

53 Chiusura del processo Il processo di Gestione operativa è attuato in via continuativa fino alla scadenza del contratto. Il processo produce, in sintesi, i seguenti risultati: corretto funzionamento del sistema ed erogazione del servizio agli utenti nel rispetto delle Specifiche del servizio e della documentazione utente; aggiornamento alla configurazione di base del prodotto software e/o del sistema e conseguenti modifiche alla documentazione utente 6.7 Gestione: Processo di Manutenzione Nel corso del Processo di Manutenzione, saranno condotte due attività: la prima consisterà nella Manutenzione Adattativa e Correttiva (MAC), tramite la quale si conseguirà l obiettivo, prioritario, di preservare l integrità del Sistema; la seconda invece, riguarderà la Manutenzione EVolutiva (MEV) del Sistema sviluppato nella Fase di Implementazione Manutenzione MAC Obiettivi Obiettivo del processo consiste nel sottoporre a modifica il prodotto software e/o il sistema preservandone l integrità; il processo include le attività di migrazione e dismissione Attivazione del processo Il processo è attivato quando è necessario apportare modifiche al prodotto software, al sistema ed alla relativa documentazione. Sono input del processo i prodotti del Processo di Progettazione e di Realizzazione. Il processo deve essere attuato secondo piani e procedure documentate Attività e prodotti Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di Manutenzione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti. Processo di Manutenzione Attività Prodotti MA-A1 Analisi dei problemi e delle modifiche MAA1-01 Piano delle modifiche MA-A2 Esecuzione delle modifiche MAA2-01 Servizio (prodotto software - sistema - documentazione utente) nella nuova configurazione MAA2-02 Registrazioni relative alle modifiche ed alle prove MA-A3 Riesame/accettazione delle modifiche MAA3-01 Servizio (prodotto software - sistema - documentazione utente) in esercizio nella nuova configurazione (configurazione pag 53

54 Attività Processo di Manutenzione corrente) Prodotti MA-A4 Migrazione MAA4-01 Piano di migrazione MA-A5 Dismissione MAA5-01 Piano di dismissione Analisi delle modifiche. Il Prestatore deve analizzare le richieste di modifica provenienti dall utente, e ogni altra richiesta o esigenza di modifica al prodotto software e/o al sistema, in base ai seguenti elementi: tipologia: correttiva, migliorativa, preventiva, adattativa ad un nuovo ambiente; evolutiva, in risposta alle necessità individuate dal Committente al fine di aderire all oggettivo miglioramento del Sistema per il soddisfacimento dei bisogni dell utenza di riferimento. campo di applicazione: ampiezza della modifica, elementi del sistema da modificare, tempi richiesti, costi previsti; criticità: impatto sul funzionamento del sistema, sulle prestazioni e sulla sicurezza. Le modifiche sono innescate da impedimenti all esecuzione di funzioni o da differenze riscontrate fra l effettivo funzionamento del prodotto software e quello atteso, previsto nella relativa documentazione o comunque determinato dalla prassi dell utente. Per quanto concerne l impedimento all esecuzione di funzioni, le modifiche seguono una modalità di esecuzione di tipo continuativo ed, in linea di massima, non sono pianificabili, essendo orientate alla rimozione dei difetti causati dal prodotto software o dal sistema stesso. Parimenti, le modifiche che costituiscono evoluzioni al fine di migliorare il Sistema nel senso sopra cennato, saranno pianificate ed analizzate su input del Committente che, allo stesso modo, indicherà gli obiettivi da conseguire. Il risultato dell attività è il Piano delle modifiche ovvero un documento o un insieme di documenti nel quale sono indicati le tipologie di modifiche, i risultati dell analisi per quanto riguarda il campo di applicazione e la criticità di ciascuna modifica, nel senso sopra indicato, le opzioni di soluzione. Fatta eccezione per le modifiche di tipo correttivo che non sono pianificabili, il Prestatore deve ottenere dal Committente l approvazione del Piano delle modifiche prima di dare luogo alla esecuzione delle modifiche individuate Esecuzione delle modifiche. Sulla base del Piano delle modifiche, il Prestatore realizza le modifiche seguendo il processo di Progettazione ed il processo di Realizzazione ed in particolare assicurando che: siano definiti, eseguiti e documentati i test (unitari, funzionali, di prodotto, di sistema, di non regressione) delle parti modificate e non modificate (unità software, componenti ed elementi di configurazione) del sistema. L esecuzione dei test deve essere effettuata nell ambiente di Collaudo ed i risultati devono essere documentati. sia assicurata la completa e corretta realizzazione dei requisiti nuovi o modificati. Deve essere inoltre assicurato il corretto funzionamento del sistema rispetto ai requisiti originali non modificati. pag 54

55 Il risultato delle attività è costituito dal prodotto software e/o dal sistema, con relativa documentazione, nella nuova configurazione, verificata nell ambiente di Collaudo rispetto ai requisiti nuovi e ai requisiti non modificati Riesame/Accettazione delle modifiche. L attività è volta a verificare l integrità del sistema modificato, attraverso riesami condotti con il Committente o con l organizzazione che autorizza le modifiche sulla base di tutte le registrazioni relative alle modifiche effettuate ed ai risultati delle prove eseguite (Test Data Report). L approvazione delle modifiche da parte del Committente, secondo modalità stabilite nel contratto, comporta l accettazione da parte del Committente del prodotto software e/o del sistema, con la relativa documentazione, nella nuova configurazione (configurazione corrente), che diviene operativa nell ambiente di esercizio e in relazione alla quale sono svolte le attività proprie dei processi di Gestione operativa e di Manutenzione Migrazione. L attività è svolta nel caso in cui debba essere effettuata la migrazione del prodotto software e/o del sistema che realizza l ambiente di erogazione del servizio in un nuovo ambiente operativo o nel caso in cui debba subentrare un nuovo soggetto nella erogazione del servizio oggetto di servizio contrattuale. In tal caso il Prestatore deve pianificare ed eseguire tutte le attività necessarie a garantire il corretto funzionamento del prodotto software e/o del sistema o a garantire la corretta erogazione del servizio in un nuovo ambiente. Il Prestatore deve predisporre un Piano di migrazione, che indichi: requisiti della migrazione; attività di migrazione; mezzi, modalità e tempi per eseguire la migrazione; modalità di verifica del prodotto software, del servizio e/o del sistema nel nuovo ambiente operativo. Il Prestatore deve svolgere in parallelo le attività del processo di gestione operativa nell ambiente di origine, fino al completamento della migrazione ed alla verifica del corretto funzionamento di quanto realizzato. Il completamento delle attività di migrazione deve essere notificato a tutti gli interessati. Tutta la documentazione, il codice e i dati associati al prodotto software, al sistema o al servizio devono essere archiviati, quando necessario, e accessibili in accordo con i requisiti contrattuali Dismissione. Quando il Committente deciderà di procedere alla dismissione del prodotto software e/o del sistema o di sospendere l erogazione del servizio, il Prestatore dovrà predisporre ed eseguire un Piano di dismissione delle attività connesse, con particolare riferimento alle attività di gestione operativa e di manutenzione. Il documento deve contenere dati di pianificazione con riferimento agli elementi di seguito elencati: pag 55

56 cessazione totale o parziale del servizio e dell assistenza dopo un determinato periodo di tempo; archiviazione del prodotto software e della relativa documentazione associata; responsabilità per ogni eventuale necessità di assistenza da fornire in futuro; transizione al nuovo prodotto software e/o al nuovo sistema, qualora applicabile; accessibilità alle copie degli archivi dei dati e della documentazione Il Piano di dismissione, con l indicazione delle attività previste, deve essere notificato agli utenti interessati. Le notifiche devono comprendere: descrizione delle attività di sostituzione o di aggiornamento, con relative date di disponibilità; descrizione delle altre opzioni di assistenza disponibili una volta che il supporto sarà stato rimosso. Nel corso dell avvio del nuovo prodotto software in sostituzione del precedente, dovranno essere condotte attività di parallelo tra dismissione del vecchio ambiente ed avvio del nuovo. Il completamento delle attività di dismissione deve essere notificato a tutti gli interessati. Tutta la documentazione, il codice e i dati utilizzati dal prodotto software e/o dal sistema o ad essi associati devono essere archiviati, quando necessario, e accessibili in accordo con i requisiti contrattuali Chiusura del processo Il processo di Manutenzione è attuato in via continuativa fino alla scadenza del contratto. Il processo produce, in sintesi, i seguenti risultati: corretto funzionamento del prodotto software e/o del sistema, attraverso attività che assicurano in via continuativa la rimozione dei malfunzionamenti, il miglioramento delle funzionalità e delle prestazioni, l adeguamento costante all ambiente tecnologico; definizione delle modalità di migrazione e dismissione del prodotto software e/o del sistema o di cessazione del servizio. Si affianca all obiettivo principale l applicazione di evoluzioni funzionali ed applicative che il Committente può ritenere opportune, a seguito dell entrata in servizio del sistema e del suo contestuale utilizzo da parte dell utenza. In base all esperienza del Committente in altri progetti con le medesime caratteristiche, la necessità di evoluzioni corrisponderà ad un intervento pari al 4% dello sviluppo effettuato in Fase di Implementazione. Per questo, si ritiene che il Processo di Manutenzione debba prevedere l attuazione di attività corrispondenti alla percentuale sopra indicata oltre agli interventi di natura correttiva eventualmente necessari per il perseguimento del citato principio di integrità Manutenzione Evolutiva (MEV) Nel corso della Fase di Gestione, si potrebbe ritenere utile procedere ad attività di Manutenzione Evolutiva dei moduli software sviluppati nel corso della Fase di Implementazione. La Fase di Gestione prevede l utilizzo del Sistema in modalità operativa e precedenti esperienze progettuali condotte dal Committente in attività similari, hanno indotto a ritenere che saranno necessari interventi di rifinitura e perfezionamento dello sviluppo effettuato. pag 56

57 Pertanto, la Manutenzione Evolutiva si prefigura come una seconda fase del processo di sviluppo ad hoc che potrebbe intervenire durante la fase di Gestione Operativa del Sistema. Si ritiene che l entità della MEV sia pari al 15% dello sviluppo effettuato nella Fase di Implementazione. Per quanto concerne i Processi per lo svolgimento della MEV, sono i medesimi che determinano lo sviluppo ad hoc; allo stesso modo, come approfondito nel successivo capitolo 8, sono forniti anche i medesimi servizi. 6.8 Trasversale: Processo di Gestione della Configurazione Obiettivi Il processo ha l obiettivo di garantire l integrità e la rintracciabilità di tutti gli elementi che compongono la servizio nell intero ciclo di vita, attraverso attività, sia tecniche che gestionali, d identificazione e documentazione delle caratteristiche funzionali e fisiche degli elementi, di controllo dei cambiamenti delle caratteristiche, di registrazione e notifica dello stato di realizzazione. La gestione della configurazione identifica la configurazione di un prodotto in alcuni momenti del ciclo di vita; si basa sulla creazione progressiva di baseline, ognuna delle quali definisce lo stato del prodotto in un dato momento. Ogni modifica apportata ad un elemento della baseline deve essere effettuata in modo controllato Attivazione del processo Il processo è svolto dal Prestatore in via continuativa, indipendentemente dai processi primari attivati con la sottoscrizione del contratto. La definizione delle modalità di gestione della configurazioni dei prodotti connessi al ciclo di vita della servizio segue la sottoscrizione del contratto. Sono dati di input i requisiti indicati nei documenti che costituiscono la baseline di contratto, prodotti nell ambito dei processi di Acquisizione e di Servizio, nonché i documenti prodotti nell ambito del processo di Progettazione, nei quali sono specificati regole, strumenti e modalità per la gestione delle configurazioni dei prodotti oggetto del contratto Attività e prodotti Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di Gestione della Configurazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti. Processo di Gestione della Configurazione pag 57

58 Attività Prodotti CO-A1 Pianificazione COA1-01 Piano di gestione della configurazione CO-A2 Identificazione della configurazione COA2-01 COA2-02 Documenti di configurazione Prodotto nella configurazione di base CO-A3 Controllo della configurazione COA3-01 Prodotto nella configurazione corrente CO-A4 Registrazione dello stato di configurazione COA4-01 CO-A5 Rilascio e consegna COA5-01 Registrazioni Registro delle configurazioni Pianificazione. Il Prestatore deve definire e documentare le modalità di gestione delle configurazioni dei prodotti durante il ciclo di vita, attraverso la predisposizione di un Piano di gestione della configurazione, ovvero di un documento o di un insieme di documenti nel quale sono indicati: le attività di gestione della configurazione, le procedure, il programma temporale di svolgimento delle attività; le entità organizzative coinvolte nella esecuzione delle attività, le responsabilità assegnate a ciascuna e la loro interrelazione con altre organizzazioni, tra le quali quelle preposte alle attività proprie dei processi di Realizzazione e Manutenzione; gli strumenti, le tecniche e le metodologie di gestione della configurazione da utilizzare; lo stadio al quale ciascun elemento dovrebbe essere passato sotto controllo di configurazione Identificazione della configurazione. Il Prestatore, in accordo con il Piano di gestione della configurazione, deve identificare e documentare gli elementi di configurazione e le loro versioni. Per ciascuna versione di ciascun elemento devono essere identificati la documentazione che stabilisce la baseline, le connessioni con la versione, ogni altro dettaglio che ne permetta l identificazione, ivi incluse le necessarie caratteristiche funzionali e fisiche di ciascun elemento, con le interfacce, le modifiche, le deroghe e le concessioni (documenti di configurazione). Per esempio per i prodotti software, per ciascuna versione di un elemento devono essere identificati le specifiche tecniche e funzionali, gli strumenti di sviluppo che abbiano influenza su tali specifiche, le interfacce con altri elementi software o con l hardware ed i documenti e gli archivi informatici relativi all elemento. L identificazione dell elemento software deve essere di regola organizzata in modo che si possa dimostrare la relazione tra l elemento ed i requisiti contrattuali. Il Prestatore deve identificare le versioni degli elementi di configurazione che, integrati tra loro, costituiscano una specifica versione del prodotto completo. Con accordi formali, in momenti determinati del ciclo di vita, deve essere stabilita la configurazione di base del prodotto ed usata come punto di partenza per il controllo formale della configurazione e per lo sviluppo delle versioni successive (configurazione corrente). pag 58

59 Per esempio, in un rapporto contrattuale tra Prestatore e Committente la configurazione di base di un prodotto a completamento del processo di Realizzazione è ratificata dalla conclusione con esito positivo del Collaudo. L attività di identificazione della configurazione, produce come risultati i documenti di configurazione, che descrivono le caratteristiche funzionali e fisiche di ciascun elemento di configurazione, secondo quanto sopra indicato, e la ratifica della configurazione di base del prodotto Controllo della configurazione. L attività è svolta secondo il Piano di gestione della configurazione ed ha lo scopo di assicurare che, dopo il rilascio iniziale dei documenti di configurazione e la ratifica della configurazione di base, tutte le modifiche siano apportate in modo controllato. In particolare nel corso di tale attività il Prestatore deve: identificare e registrare le richieste di modifica; analizzare e valutare le modifiche, con riferimento ai requisiti, al campo di applicazione (ampiezza della modifica; elementi da modificare) ed alla criticità (impatto sul funzionamento del prodotto, sulle prestazioni e sulla sicurezza). sottoporre i risultati dell analisi all iter di approvazione previsto nel Piano di gestione della configurazione; attuare e verificare le modifiche approvate; rilasciare gli elementi modificati. Per proteggere l integrità della configurazione e fornire la base per il controllo delle modifiche è necessario che gli elementi di configurazione, le unità che le costituiscono e la documentazione relativa siano tenuti dal Prestatore in un ambiente che: sia commisurato con le condizioni ambientali richieste (ad esempio software, dati, documenti, ecc.); li protegga da modifiche non autorizzate o da danneggiamenti; fornisca i mezzi per ricostruirli in caso di danneggiamento; nel caso di software, dati, documenti e disegni, permetta il recupero di una copia dell originale sotto controllo; consenta di relazionare la configurazione del prodotto come risultante rispettivamente dal processo di Progettazione e dal processo di Realizzazione. Il risultato dell attività è rappresentato dall insieme degli elementi modificati che nell insieme costituiscono il prodotto nella configurazione corrente Registrazione dello stato della configurazione. L attività consiste nel predisporre registrazioni sulla gestione della configurazione e rapporti di situazione che mostrino lo stato e la storia degli elementi controllati, inclusi i documenti relativi alla baseline. La registrazione dello stato di configurazione inizia dal momento in cui i dati di configurazione sono generati per la prima volta. Il Prestatore in particolare deve alimentare e gestire un Registro delle configurazioni, che consenta di documentare lo stato di costruzione di ciascun prodotto e dei relativi elementi nelle diverse versioni e nelle diverse fasi del ciclo di vita, con particolare riferimento a: pag 59

60 prodotti in corso di realizzazione, di gestione operativa e di manutenzione o in esercizio; elenco degli elementi controllati e dei documenti relativi alla baseline; configurazione di base ciascun prodotto, che rappresenta la definizione del prodotto nel momento specifico; configurazione corrente, costituita dalla configurazione di base e dalle modifiche approvate, realizzate e collaudate; documentazione riguardante le modifiche e lo stato di attuazione, verifica e collaudo delle stesse Rilascio e consegna. L attività riguarda il rilascio, la consegna e la conservazione dei prodotti e della relativa documentazione. Propedeutica al rilascio è la valutazione della configurazione del prodotto, avente lo scopo di assicurare la completezza funzionale e fisica degli elementi rispetto ai requisiti. I materiali originali (codice, documenti, ecc.) devono essere mantenuti per tutto il ciclo di vita e devono essere trattati, consegnati e conservati nel rispetto di requisiti relativi a conservazione delle registrazioni, riservatezza, sicurezza, manutenzione ed eventuali prescrizioni normative. Il risultato dell attività è rappresentato dalle Registrazioni relative al rilascio ed alla consegna dei prodotti Chiusura del processo Il processo di Gestione della Configurazione si conclude con la conclusione del ciclo di vita della servizio, quando risultino completate tutte le attività relative al rilascio ed alla consegna dei prodotti ed in generale tutte le attività previste nel Piano di gestione della configurazione. pag 60

61 7 TEMPI E LUOGHI DEL PROGETTO Il progetto ha una durata pari a diciassette mesi solari e continuativi, senza considerare quanto il Prestatore intenderà specificare in sede di offerta per quanto concerne le previsioni di cui al successivo Paragrafo Relativamente allo svolgimento dei Processi, la tabella seguente illustra la durata in mesi solari e continuativi Fase Processo Durata in mesi solari IMPLEMENTAZIONE GESTIONE TRASVERSALE PR PROGETTAZIONE 4 RE - REALIZZAZIONE E COLLAUDO 6 GO - GESTIONE OPERATIVA 6 MA MANUTENZIONE 6 GE - GESTIONE DEL PROGETTO 17 DO DOCUMENTAZIONE 1 CO CONFIGURAZIONE 6 AQ - ASSICURAZIONE QUALITA' 16 Per quanto concerne lo Start del progetto, lo stesso avrà inizio con le attività previste nel processo GE Gestione del Progetto per la produzione dei documenti GEA1-01, GEA3-01, GEA4-01, GEA8-01, GEA10-01 entro 30 giorni solari e continuativi. Per quanto concerne le successive attività, si illustra di seguito un ipotetico Gantt di progetto specificando che, in ogni caso, la tempificazione definitiva è uno dei risultati dell attività di pianificazione iniziale. Le attività saranno svolte presso i locali del Prestatore o presso la sede di UIRNet. Si evidenzia che tutte le riunioni, a qualsiasi titolo, tra il Committente ed il Prestatore saranno svolte presso la sede operativa di UIRNet in Roma; ogni eccezione alla regola indicata, dovrà comunque essere esplicitamente e formalmente autorizzate da UIRNet stessa. pag 61

62 pag 62

63 8 DEFINIZIONE DEL SERVIZIO Si ribadisce che l erogazione del servizio sarà effettuata a corpo ed è composta da una serie di servizi. Il presente capitolo descrive: i servizi che dovranno essere erogati; l effort stimato di progetto; i profili professionali coinvolti con la contestuale organizzazione di progetto; la valutazione in termini di SLA dei servizi svolti, con le corrispondenti azioni contrattuali ( penali ) che possono essere applicate al Prestatore in caso di inosservanza. Il contenuto del Capitolo si attiene ai Lemmi del Dizionario ICT dell Agenzia per l Italia Digitale; di seguito, sono contenuti rimandi alle schede di dettaglio dei servizi che costituiscono l appendice al presente Capitolato e ne costituiscono parte integrante. Il contenuto delle schede in appendice fornisce altresì, qualora necessario, un approfondimento logico oltre che il dettaglio interpretativo rispetto a quanto descritto nel precedente Capitolo 6, in merito alle attività ( processi ) che compongono l intero Progetto. 8.1 Servizi e copertura dei processi previsti. I servizi che il Prestatore dovrà erogare sono i seguenti: Servizio SSW GSI ASS MAC PGE FOR PGC PGD PAQ Descrizione Sviluppo e MEV di software ad hoc Gestione Sistemi Assistenza in remoto e locale Manutenzione correttiva ed adeguativa Gestione e processi organizzativi Formazione e addestramento Gestione della configurazione Documentazione Assicurazione della Qualità Ognuno dei servizi elencati nella tabella precedente, prevede lo svolgimento di attività di tipo progettuale e/o di pianificazione (a più alto costo per la tipologia di figure professionali coinvolte) e di attività di tipo esecutivo (con costi relativamente più contenuti). La tabella seguente fornisce la stima del peso dell attività progettuale rispetto a quella esecutiva. pag 63

64 Servizio Progettazione/Pianificazione Esecuzione SSW 20% 80% GSI 0% 100% ASS 50% 50% MAC 50% 50% PGE 56% 44% FOR 40% 60% PGC 20% 80% PGD 100% 0% PAQ 20% 80% Media 39,6% 60,4% Il dato è di interesse nella determinazione dei requisiti richiesti con riferimento ai profili professionali - e, di conseguenza, nella determinazione del relativo valore economico - che devono essere coinvolti nelle attività al fine di corrispondere alle necessità ed agli obiettivi progettuali. Di seguito, si fornisce la mappatura della corrispondenza tra i servizi che il Prestatore dovrà erogare e le attività che sono state identificate come necessità progettuale. Anche qui è indicata la distinzione tra le attività più prettamente progettuali e quelle di tipo esecutivo. Come detto, le schede allegate al presente Capitolato approfondiscono i contenuti di ogni servizio fornendo il dettaglio dei diversi processi; il Prestatore dovrà tenere conto esclusivamente di quelle indicate nella tabella seguente, nelle colonne SERVIZIO/Progettazione Pianificazione e SERVIZIO/Esecuzione. Difatti, non tutte le attività inserite in ognuno degli otto servizi sono state ritenute utili per la realizzazione del Progetto e, per questo, alcune di esse non sono indicate nella tabella. Si noterà l eccezione del Servizio PGD/Esecuzione/Distribuzione e Conservazione della Documentazione che produce i due Output DOA3-01 e DOA4-01, graficamente evidenziata con lo sfondo della cella. In quel caso l Output è atteso quale risultato dell attività gestionale, ma sarà governato nell ambito del Servizio PGE/Esecuzione/Esecuzione e controllo del progetto. Per quanto sopra, i contenuti del Capitolo 6 e le schede dei servizi, allegate, costituiscono il contenuto effettivo della servizio. A tutto ciò si aggiunge, nell ambito del servizio FOR, relativo alle attività di formazione ed addestramento, un costo relativo al materiale didattico (supporti CD, stampe, ecc.) che sarà oggetto di servizio per lo svolgimento dei corsi e come riserva per ulteriori, eventuali, attività addestrative future. pag 64

65 GESTIONE IMPLEMENTAZIONE FASE NOME PR - Progettazione RE - Realizzazione e Collaudo GO - Gestione operativa CODE PR-A1 PR-A2 PR-A3 ATTIVITA' SERVIZIO OUTPUT PROGETTAZIONE PIANIFICAZIONE Analisi dei requisiti Progettazione tecnica Progettazione applicativa ESECUZIONE NOME CODE Sviluppo e MEV di software ad hoc SSW PROGETTAZIONE PIANIFICAZIONE Analisi dei requisiti Progettazione tecnica ESECUZIONE CODE PRA1-01 PRA2-01 PRA2-02 PRA3-01 PRA3-02 PRA3-03 PR-A4 Progettazione Test e Collaudi Progettazione Collaudo PRA4-02 RE-A1 RE-A2 RE-A3 RE-A4 Codifica Predisposizione del sistema Produzione della documentazione Qualificazione finale Realizzazione codifica Predisposizione del sistema Qualificazione finale REA1-01 REA1-02 REA1-03 REA4-01 RE-A5 Installazione Installazione REA5-01 RE-A6 GO-A1 GO-A2 Collaudo Prove delle forniture rilasciate in esercizio Gestione operativa Gestione Sistemi GSI Collaudo Avviamento Presa in carico di nuovi sistemi/ applicazioni Gestione delle prestazioni Gestione della schedulazione Gestione delle malfunzioni REA6-01 REA6-02 GOA1-01 GOA2-01 pag 65

66 TRASVERSALI FASE NOME MA - Manutenzione GE - Gestione del progetto CODE MA-A1 MA-A2 MA-A3 ATTIVITA' SERVIZIO OUTPUT PROGETTAZIONE PIANIFICAZIONE Analisi dei problemi e delle modifiche ESECUZIONE NOME CODE Assistenza agli utenti Esecuzione delle modifiche Riesame/accettazione delle modifiche Assistenza in remoto e locale Manutenzione correttiva ed adeguativa ASS MAC PROGETTAZIONE PIANIFICAZIONE Analisi dei requisiti Analisi dei problemi e delle modifiche Progettazione tecnica Progettazione Collaudo ESECUZIONE Conduzione operativa sistemi Gestione dello storage Attuazione delle modifiche Rendicontazione CODE MAA1-01 MAA2-01 MAA2-02 MAA3-01 MA-A4 Migrazione MAA4-01 MA-A5 Dismissione MAA5-01 GE-A1 GE-A3 GE-A4 GE-A5 Pianificazione del progetto Pianificazione della comunicazione Pianificazione della qualità Esecuzione del progetto Gestione e processi organizzativi PGE Pianificazione del progetto e delle attività di gestione Pianificazione delle comunicazioni Pianificazione della qualità Esecuzione e controllo del progetto GEA1-01 GEA3-01 GEA4-01 GEA5-01 GEA5-02 GE-A6 Controllo del progetto GEA6-01 GE-A7 Revisione, Riesame e valutazione Riesame e valutazione GEA7-01 GEA7-02 pag 66

67 FASE NOME DO - Documentazione CO - Configurazione CODE ATTIVITA' SERVIZIO OUTPUT PROGETTAZIONE PIANIFICAZIONE ESECUZIONE NOME CODE PROGETTAZIONE PIANIFICAZIONE ESECUZIONE GE-A8 Definizione dell infrastruttura GEA8-01 GE-A9 Manutenzione dell infrastruttura CODE GEA9-01 GE-A10 Definizione dei processi GEA10-01 GE-A11 GE-A12 GE-A13 GE-A14 GE-A15 GE-A16 DO-A1 Definizione delle esigenze (formative) Pianificazione Valutazione dei processi Miglioramento dei processi Sviluppo del materiale di formazione Esecuzione della formazione Conclusione del progetto Formazione e addestramento Documentaz. FOR PGD Analisi dei requisiti Pianificazione Progettazione e sviluppo contenuti Gestione operativa GEA11-01 GEA12-01 GEA13-01 GEA14-01 GEA15-01 GEA16-A1 DOA1-01 DO-A2 Progettazione e sviluppo Progettazione DOA2-01 DO-A3 Distribuzione e conservazione Distribuzione e Conservazione della Documentazione DOA3-01 DO-A4 Manutenzione DOA4-01 CO-A1 CO-A2 CO-A3 CO-A4 Pianificazione Identificazione della configurazione Controllo della configurazione Registrazione dello stato di configurazione Gestione della configurazione PGC Pianificazione della Configurazione Realizzazione del servizio Controllo della Configurazione COA1-01 COA2-01 COA2-02 COA3-01 COA4-01 CO-A5 Rilascio e consegna Audit sulla COA5-01 pag 67

68 FASE ATTIVITA' SERVIZIO OUTPUT NOME CODE PROGETTAZIONE PIANIFICAZIONE ESECUZIONE NOME CODE PROGETTAZIONE PIANIFICAZIONE ESECUZIONE Configurazione CODE AQ - Assicurazione Qualità AQ-A1 Pianificazione Pianificazione AQA1-01 AQ-A2 Assicurazione qualità Realizzazione AQA2-01 AQ-A3 Verifica AQA3-01 AQ-A4 Validazione AQA4-01 AQ-A5 Riesame congiunto Assicurazione Qualità PAQ Verifica AQA5-01 AQA6-01 AQ-A6 Verifica ispettiva AQA6-02 AQ-A7 Risoluzione dei problemi Risoluzione dei problemi AQA7-01 AQA7-02 pag 68

69 8.2 Breve descrizione dei servizi In allegato al seguente Capitolato, sono fornite le schede servizi ricavate da documenti in vigore dell Agenzia per l Italia Digitale. Dalle stesse fonti si ricava una breve descrizione dei servizi oggetto di servizio che, come detto, possono essere approfonditi nelle schede allegate. L intento della descrizione è di chiarire e delimitare con la massima precisione possibile quali saranno le prestazioni richieste al Prestatore Servizio SSW Sviluppo e MEV di software ad hoc Concerne lo sviluppo di software specifico per il Committente che include lo sviluppo di applicazioni secondo vari metodi, mezzi e modalità, singolarmente o in modo congiunto, in dipendenza dagli obiettivi, funzionali o meno, richiesti. Potrà quindi essere previsto l utilizzo di linguaggi di III e IV generazione, metodi Object Oriented, sviluppi WEB Based. Include lo sviluppo di applicazioni custom e la reingegnerizzazione di software pre-esistente e la Manutenzione Evolutiva di software (MEV), attraverso l introduzione di nuove funzioni, o la modifica di funzioni preesistenti, nell ambito di software ad hoc già sviluppato Servizio GSI Gestione Sistemi Riguarda tutte le attività necessarie per prendere in carico, condurre e mantenere sempre aggiornata e funzionante una infrastruttura hardware e software utilizzata per l erogazione di uno o più servizi informatici. Questa tipologia di servizio, quindi, si identifica come la gestione dell esercizio dei sistemi e comprende: le installazioni dell hardware e del software di base, la loro configurazione, personalizzazione ed eventuale distribuzione presso sistemi periferici in relazione ad aggiornamenti di configurazioni esistenti; la conduzione operativa dei sistemi (accensione e spegnimento, produzione di stampe, start-up dei collegamenti, ecc.); il monitoraggio dei sistemi per la rilevazione e la risoluzione di malfunzionamenti hardware e software; la configurazione e la definizione delle modalità di utilizzo dello storage in termini di regole di allocazione e movimentazione dei dati; il miglioramento delle prestazioni dei sistemi; la definizione, la realizzazione, la schedulazione e l esecuzione delle procedure di gestione dei sistemi e dei collegamenti; la gestione dei backup/restore dei dati di sistema. Non sono comprese in questa tipologia di servizio le attività necessarie per la introduzione di nuove tecnologie e/o sistemi hardware e software che comportano cambiamenti di configurazione e/o organizzazione e che richiedono attività di progettazione e sviluppo Servizio ASS Assistenza in locale e remoto Questa tipologia di servizio fornisce agli utenti interni o esterni del Committente un punto di accesso unificato ad un insieme di funzioni di assistenza. pag 69

70 Si tratta di soluzioni di assistenza basate sull uso dei canali telematici volti alla gestione dei malfunzionamenti e/o alle richieste di tipo amministrativo/funzionale. Essi devono consentire il censimento delle problematiche e le relative risoluzioni delle stesse. Il Servizio deve prevedere la disponibilità di personale dedicato che sia in grado di dare risposte nei tempi definiti dagli SLA contrattuali e che costituisca un ponte tra il Committente/Utente e i gruppi di sviluppo nella Fase di Gestione, consentendo la pronta risoluzione delle problematiche rilevate sul sistema. Il Servizio deve essere in grado, per mezzo di strumenti dedicati, di tracciare univocamente i tempi di risoluzione dei malfunzionamenti, registrare le azioni di ripristino adottate e comunicare ai soggetti interessati lo stato di funzionamento dei vari sistemi. Il personale dovrà essere in grado, infine, di comunicare efficacemente con gli utenti per approfondimenti di problematiche o per assistenza all utilizzo del Software. Più in particolare, il Committente già dispone di un servizio di assistenza di primo livello e sarà questo a corrispondere all utenza nel momento del contatto iniziale. Sarà necessario progettare i contenuti dell assistenza di primo livello, aggiornare il tool utilizzato dagli operatori quale strumento di consultazione per corrispondere alle richieste ricevute e addestrare gli operatori alle nuove esigenze. Inoltre, è necessaria la completa predisposizione e servizio di un servizio di secondo livello che sarà erogato per tutto il periodo corrispondente alla Fase di Gestione Servizio MAC Manutenzione Adeguativa e Correttiva Concerne tutte le attività inerenti: la manutenzione correttiva, che comprende la diagnosi e la rimozione delle cause e degli effetti delle malfunzioni delle procedure e dei programmi; la manutenzione adeguativa, che comprende l attività di manutenzione volta ad assicurare la costante aderenza delle procedure e dei programmi all evoluzione dell ambiente tecnologico del sistema informativo e al cambiamento dei requisiti (organizzativi, normativi, d ambiente). Invece, si parla di manutenzione evolutiva quando occorre adattare la soluzione a nuove esigenze dei processi; in questo caso la manutenzione comporta l aggiunta, il cambiamento ed eventualmente la rimozione di funzionalità ed è trattata nella classe di servizio Sviluppo e MEV di software ad hoc (SSW) Servizio PGE Gestione e Processi Organizzativi Obiettivo del Servizio PGE è la conduzione coordinata delle attività ad esso correlate nel rispetto dei requisiti di tempi, costi e qualità. Sono comprese le attività preliminari all avvio della Progettazione, come la pianificazione delle attività, l acquisizione delle risorse, la definizione dell organizzazione del progetto e l avvio delle attività, nonché tutte le attività di coordinamento delle risorse assegnate al progetto in corso d opera. Il processo include, inoltre, le attività di controllo dell andamento del progetto, la produzione di stati di avanzamento, inclusa la servizio alle parti interessate delle opportune informazioni e documentazioni e le attività condotte per identificare, valutare e gestire i rischi del progetto. Dal risultato delle attività di controllo in corso d opera sono definiti e adottati tutti gli interventi per il miglioramento dei processi di produzione intervenendo anche sullo sviluppo delle pag 70

71 competenze del personale addetto attraverso un processo di formazione e istruzione pianificato sulla base delle esigenze e delle figure professionali a disposizione. Il processo di gestione comprende anche tutte le attività di definizione, predisposizione e manutenzione dell infrastruttura necessarie allo svolgimento dei processi primari da gestire che può comprendere hardware e software, strumenti di misura, metodologie, tecniche e apparecchiature Servizio FOR Formazione e Istruzione Comprende i servizi finalizzati all aggiornamento e allo sviluppo delle conoscenze, delle competenze e delle capacità professionali delle risorse umane, al fine di supportare il processo d innovazione innescato dalla Committente con la realizzazione del Progetto. Un servizio di formazione si caratterizza per i contenuti, per le metodologie didattiche e per le modalità di realizzazione, che possono prevedere tutto lo spettro di soluzioni blended che intercorrono tra la modalità di formazione sincrona in aula e la modalità di formazione asincrona on-line Servizio PGC Gestione della Configurazione La gestione della configurazione è un processo che ha lo scopo di assicurare la conoscenza, la completezza, l integrità, la consistenza e la correttezza delle componenti di un sistema, in particolare in relazione alle dipendenze esistenti tra le stesse, attraverso la registrazione della configurazione iniziale e la conoscenza dello stato delle modifiche proposte, della loro motivazione, della loro approvazione, della loro attuazione e della loro evoluzione. La gestione della configurazione comprende, quindi, le seguenti attività integrate: identificazione della configurazione, controllo della configurazione, registrazione dello stato di configurazione, audit sulla configurazione Servizio PGD Gestione della Documentazione La gestione sistematica dei documenti si applica sia ai documenti veri e propri, sia a qualunque altra forma di rappresentazione di informazioni prodotte nel ciclo di vita di una servizio (tabelle, grafici, diagrammi di flusso, banche dati, prospetti). Il processo si esplica attraverso un insieme di attività svolte dal Prestatore in via continuativa, indipendentemente dai processi primari attivati con la sottoscrizione del contratto, e volte a pianificare, progettare, produrre e distribuire i documenti necessari a tutte le entità organizzative interessate. La definizione delle modalità di gestione dei documenti, connessi al ciclo di vita della erogazione del servizio segue la sottoscrizione del contratto. Sono dati di input i requisiti indicati nei documenti che costituiscono la baseline di contratto, prodotti nell ambito dei processi di Acquisizione e di Servizio, nonché i documenti prodotti nell ambito del processo di Progettazione, nei quali sono specificati regole, strumenti, standard e convenzione per la produzione e gestione dei documenti relativi alla servizio. pag 71

72 8.2.9 Servizio PAQ Assicurazione della Qualità Concerne l insieme delle attività sistematiche e pianificate messe in campo dal Prestatore per dare evidenza e fiducia al Committente che i servizi e i prodotti contrattualmente forniti siano conformi ai requisiti. Mentre le caratteristiche e i requisiti di qualità sono riferiti al prodotto finito o al servizio erogato, in questa classe di servizio sono definiti le modalità e i momenti in cui è possibile intervenire durante il processo produttivo, e su quali semilavorati valutare o stimare la presenza della qualità richiesta nel prodotto finale. È importante considerare l assicurazione della Qualità, e con essa il sistema di Controllo della Qualità (ad esempio il piano di test e il sistema realizzato per effettuarlo) e gli altri sistemi connessi (ad esempio gestione della configurazione), come parte integrante della erogazione del servizio, e non un mezzo finalizzato alla sola consegna ed accettazione della servizio. Questa considerazione, se applicata, permette di innescare un meccanismo di assicurazione della qualità tale da permettere un progressivo e continuo miglioramento dei livelli qualitativi. 8.3 Composizione dei gruppi di lavoro Si riporta, di seguito, per ognuno dei servizi considerati, il mix medio delle risorse professionali individuate dalle schede dei servizi come da utilizzare/considerare, calcolato in base: all esperienza pregressa; alle necessità progettuali: al contenuto delle schede dei servizi allegate al Capitolato, con particolare riferimento alla tabelle Matrice di responsabilità attività Profilo di competenza e alla tabella di stima del effort % per ogni attività contenuta nel paragrafo di descrizione delle attività e dei prodotti. Si è ritenuto utile distinguere, nell ambito di ognuno dei servizi, tra le attività svolte in ambito di progettazione e pianificazione, e le attività svolte nel corso dell esecuzione progettuale. Difatti, si è considerato che l impiego di figure professionali nelle attività progettuali debba coinvolgere risorse con caratteristiche professionali più elevate, rispetto a quelle coinvolte in fase di esecuzione. Si tratta di analisi effettuate per stimare, in maniera ritenuta ottimale dal Committente, l impegno finanziario che costituisce la base d asta sulla quale si confronteranno le diverse offerte. Si ribadisce che il mix non indica alcun obbligo per il Proponente che effettuerà le proprie considerazioni e formulerà la richiesta che ritiene più opportuna, al fine di conseguire il risultato progettuale, fatti salvi gli obblighi in tema di contenuti dei processi, dei servizi, dei parametri qualitativi. A fianco di ogni figura professionale è indicato il livello della risorsa assegnato, nel mix, per quanto concerne l ambito progettuale ed anche quello di esecuzione. I livelli sono quelli di seguito indicati; per quanto riguarda il valore economico di ogni figura professionale, si fornisce una stima di rapporto tra i valori relativi ad ogni livello considerando, come base, il valore della figura economicamente più bassa. pag 72

73 Livello Rapporto con la figura base Master +50,0% Specialista +46,3% Esperto +38,6% Senior +23,2% Operativo valore base La tabella seguente riassume il mix di figure professionali ed indica il livello assegnato alle risorse coinvolte. pag 73

74 PROG ESEC TOT PROG ESEC TOT PROG ESEC TOT PROG ESEC TOT PROG ESEC TOT PROG ESEC TOT PROG ESEC TOT PROG ESEC TOT PROG ESEC TOT PROG ESEC I numeri nella tabella sono in %. LIVELLO SERVIZIO SSW GSI MAC ASS PGE FOR PGC PGD PAQ AMBITO TOTALI Operat. Operat. Altri Profili Special. Senior Analista di Sistemi Informativi Esperto Senior Analista Programmatore Esperto di Applicazioni Web Esperto Senior Analista Programmatore Master Senior Master Senior Capoprogetto di Sistemi Informativi Consulente per la Vendita e l Applicazione di Tecnologie ICT Special. Senior Formatore IT Operat. Operat. Personale esecutivo Special. Senior Progettista di Sistemi Informatici Esperto Senior Progettista per la Sicurezza Esperto Senior Responsabile della Configurazione e del Centro Dati Esperto Senior Responsabile di Basi di Dati Senior Senior Responsabile di Rete Esperto Senior Revisore di Sistemi Informativi Senior Senior Sistemista Senior Senior Senior Senior Supervisore di un Centro di Assistenza Tecnico di Collaudo e Integrazione di Sistemi pag 74

75 8.3.1 Indice di produttività Per quanto concerne gli obiettivi misurati in punti funzione la produttività calcolata come valore medio sui servizi di sviluppo e manutenzione evolutiva è pari a 1,70 Punti Funzione per giorno/persona. Si rammenta che la servizio sarà effettuata a corpo, ad eccezione della sola erogazione del servizio di manutenzione evolutiva che sarà a consumo nella quantità che sarà ritenuta utile dal Committente. Inoltre, la misura del Punto Funzione, oltre che per la stima delle prestazioni da fornire da parte dei Concorrenti, trova la propria applicazione pratica nei cd. elementi qualitativi del progetto ed anche in quanto descritto nei successivi paragrafi e Caratteristiche del Gruppo di Lavoro del Committente Fermo restando quanto indicato nelle schede dei servizi allegate al Capitolato, il Committente intende sottolineare che nell ambito della erogazione dei servizi, svolge attività di supervisione e controllo del Progetto includendo attività di: partecipazione attiva allo sviluppo, fornendo consulenza organizzativa e validazione delle soluzioni tecnologiche proposte Project Management in collaborazione con il Prestatore per la pianificazione degli obiettivi da raggiungere, relativamente al progetto; analisi e sviluppo dei requisiti nonché sviluppo e validazione delle soluzioni applicative in collaborazione con il Prestatore; controllo delle attività progettuali e delle attività di gestione dei servizi; partecipazione ai test finali ed ai collaudi e supporto alla valutazione finale; accettazione/approvazione dei deliverable prodotti dal Prestatore; reporting di progetto al top management UIRNet tramite la raccolta ed evidenziazione dei dati di avanzamento lavori e degli elementi necessari alla valutazione dei risultati; controllo qualità e attività ispettiva Caratteristiche del Gruppo di Lavoro del Prestatore Gli obblighi del Prestatore sono puntualmente indicati nelle schede dei servizi allegate al Capitolato. Si intende evidenziare che il Prestatore ha in carico l intero progetto e svolge le varie attività per realizzare il progetto sino alla messa a punto finale dei software applicativi ed alla loro gestione ed evoluzione, ed al passaggio in produzione dell intero progetto. Le attività sono sempre concordate e autorizzate dal Direttore dell esecuzione di UIRNet. Il Project Manager del Prestatore dovrà essere in grado di gestire le richieste di UIRNet in modalità univoca, ovvero costituendo un punto singolo di contatto. Il Prestatore deve rendersi disponibile a sessioni lavorative (oltre agli incontri ufficiali programmati, sessioni di SAL, ecc.) congiunte, anche articolate in più giorni consecutivi di lavoro, di natura sia tecnica che gestionale da svolgersi, a discrezione della Committenza, presso i locali di Sede UIRNet o del Prestatore. Più in dettaglio le attività prioritarie consistono: nel project management con la supervisione della progettazione di dettaglio e della sperimentazione delle varie componenti prototipali, supervisionando i vari sotto- Capitolato Tecnico - Moduli applicativi integrati con la PLN a supporto dell operatività dei Nodi pag 75

76 progetti, che costituiscono il progetto complessivo, controllandone la pianificazione di dettaglio e partecipando al disegno di dettaglio; nella progettazione, realizzazione della servizio software richiesta, e delle specifiche di cooperazione operativa con i servizi della PLN; nella system integration del progetto, con l obiettivo di garantire la coerenza delle soluzioni progettuali adottate e delle scelte definite nei documenti di progetto, effettuando i test di integrazione a livello del sistema complessivo anche gestendo l ambiente di prova (test bed d integrazione); nella gestione dell applicazione del sistema di assicurazione della qualità e di quanto ad essa collegato; nella realizzazione e gestione del ciclo di vita dei servizi Curricula delle Figure Professionali Unitamente alla propria offerta, il Proponente dovrà fornire i curricula vitae delle risorse che intenderà coinvolgere nel progetto; inoltre, spetta al Proponente l identificazione delle Figure Professionali che intenderà impiegare. I curricula dovranno essere redatti in base al formato CV Europass con l indicazione di un codice in sostituzione delle generalità dei soggetti cui si riferiscono, quindi senza alcun riferimento ad età, sesso, nazionalità, residenza e ad ogni altro dato che possa identificare la persona. Capitolato Tecnico - Moduli applicativi integrati con la PLN a supporto dell operatività dei Nodi pag 76