Capitolato Tecnico Application Management applicazioni CORE BUSINESS

Transcript

1 Application Management applicazioni CORE BUSINESS

2 Indice dei contenuti 1 Introduzione Glossario Applicazioni da gestire Organizzazione SEA Squadra di lavoro Project Manager Service Manager Configuration Manager Team Supporto Applicativo Team di Sviluppo 18 6 Servizi Supporto Applicativo Calcolo delle priorità Processo Attività Compensi Vincoli SLA e penali Manutenzione Correttiva Calcolo della priorità Processo Attività Compensi Garanzia Vincoli SLA e penali Servizi di Sviluppo Manutenzione Adattativa Manutenzione Evolutiva Nuovi Sviluppi Processo Mix di risorse Deliverable Compensi Vincoli Penali Attività extra Configuration Management Project management Service Management 44 7 Avviamento e termine dei servizi Knowledge Transfer Obbligo di continuità Risoluzione anticipata del contratto 49 2/50

3 7.4 Termine del servizio 49 8 Allegati /50

4 1 Introduzione SEA intende appaltare, per un periodo di tre anni, l Application Management di una serie di applicazioni sviluppate internamente, oppure fatte sviluppare da software-house esterne e legate al core business dei servizi aeroportuali. I servizi oggetto dell appalto sono: Supporto Applicativo: Un servizio di pronto intervento (talvolta chiamato anche Help Desk di secondo livello), operativo in funzione della applicazione fino a 7x24h. Il sevizio deve garantire la pronta risoluzione di ogni tipo di disservizio applicativo (non risolto direttamente dal servizio di Help Desk di primo livello interno SEA). Manutenzione Correttiva: correzione di difetti (bug) del software applicativo che comportano errori di funzionamento o ripetuti disservizi (a requisiti utente immutati). Servizi di Sviluppo: o Manutenzione Adattativa: correzione e adattamento del software applicativo per adeguarlo a nuovi rilasci del software di base o dell ambiente di contorno (a requisiti utente immutati). Parametrizzazione / configurazione di nuovi messaggi standard IATA e ICAO (ricevuti da o diretti agli altri aeroporti) o di nuove etichette bagagli o carte di imbarco delle varie compagnie aeree. Campagne di test al variare di qualche applicazione esterna o modalità operativa che possa ipoteticamente influenzare l applicazione. o Manutenzione Evolutiva: piccole modifiche o estensioni delle applicazioni esistenti per cambiare o aggiungere funzionalità in base a modificati o nuovi requisiti utente. o Nuovi sviluppi: sviluppo di interi nuovi moduli o nuove applicazioni. Attività extra: attività on demand di analisi, di testing o altre attività connesse allo sviluppo software da svolgersi on site.. Configuration Management: archiviazione corretta e ordinata (con mantenimento del versioning, di tutti i sorgenti e i file di progetto e tutta la documentazione associata e rilascio formale dei package di deploy. Analisi attraverso il tool SonarQube (o simile, indicato da SEA) di tutti i sorgenti rilasciati (creati o modificati) a seguito dei servizi sopra detti. Project Management: Organizzazione e gestione del team di sviluppo. Predisposizione di piani, stime e preventivi per i relativi interventi. Partecipazione alle riunioni periodiche (SAL con cadenza bisettimanale o settimanale a seconda degli interventi in corso) e a riunioni su temi specifici secondo necessità. Service Management: documentazione dettagliata di tutti gli interventi svolti, dei livelli di servizio, del rispetto degli SLA concordati. Proposta, valutazione e attuazione di politiche correttive, nel caso in cui i livelli di servizio risultino insoddisfacenti, partecipazione alle riunioni periodiche (cadenza mensile) di verifica dell andamento dei servizi. Il presente documento nei successivi capitoli descrive: l elenco preciso delle applicazioni interessate dall erogazione dei servizi, 4/50

5 , le caratteristiche della squadra di lavoro che dovrà erogarli, per ciascun servizio le modalità operative ed i livelli di servizio richiesti, tempi e modalità di avvio (knowledge transfer) e termine. 5/50

6 2 Glossario Ambiente di Produzione: Una serie di server utilizzati per l esercizio della applicazione. Ambiente di Test: Una serie di server configurati in modo il più possibile simile all ambiente di produzione, permette di eseguire una serie di test su una applicazione, senza interferire con i processi di business. BHS: DBMS: IDE: AU: MU: GU: FTE: SLA: SAL: Bug: Patch: Workaround: Sorgenti: Presidio: Baggage Handling System, sistema di smistamento bagagli Data Base Management System Integrated Development Environment: ambiente di sviluppo software che integra più editor specializzati, compilatori, debugger, ecc Anno Uomo = 220 GU Mese Uomo = 20 GU Giorno Uomo Full Time Equivalent, equivalente di una persona a tempo pieno. Ad es. una persona che lavora mediamente 4 mezze giornate (ossia due giorni) al mese vale 0.1 FTE. Service Level Agreement, Valore di riferimento per il livello di servizio (solitamente un tempo massimo, un tempo minimo, una percentuale, un percentile ) Stato Avanzamento Lavori. Riunione periodica di verifica andamento di un progetto. Errore nel codice sorgente di una applicazione software. Soluzione provvisoria consistente in una modifica non ben integrata e ingegnerizzata dell applicazione. Consente di risolvere provvisoriamente un problema per un tempo limitato nell attesa di un intervento correttivo meglio strutturato. Procedura alternativa che permette di aggirare un problema. L insieme di tutti i file scritti o modificati manualmente dagli sviluppatori (ossia che non sono generati da una procedura automatica a partire da altri file). Si considerano parte dei sorgenti i file scritti in linguaggi di programmazione (Java, C#, C, C++, ObjectiveC, ecc..), i file di definizione dei web services (WSDL ), i file di script (JavaScript, ShellScript, Batch, Commad, ) i file web a tag e derivati (XML, HTML, XTSL, CSS, JSP, PHP, ASPX, DO ) di risorsa (immagini, icone, suoni, filmati ), i file di progetto (Maven, Ant, o dello specifico ambiente IDE), gli script SQL per la creazione o manipolazione dei database, i file di definizione dei flussi ETL, i file di definizione dei report o degli universi su cui i report sono basati. La presenza fisica di uno o più addetti alle postazioni dove essi erogano normalmente i servizi di loro pertinenza. 6/50

7 Reperibilità La possibilità di contattare telefonicamente o telematicamente una risorsa addetta ad un certo servizio, che prenda in carico la richiesta e la evada svolgendo tutte le attività necessarie da remoto, eventualmente anche in mobilità. 7/50

8 3 Applicazioni da gestire Le applicazioni inizialmente oggetto del contratto di Application Management sono le seguenti: Agente FIDS: Applicazione Java in ambiente Linux che controlla la visualizzazione sui pannelli di informativa al pubblico (riceve le informazioni da visualizzare tramite messaggi in formato XML da un complesso sistema di distribuzione della Solari di Udine che non rientra nel presente Appalto). BASH: Intercetta la stampa delle etichette bagagli (diverse da compagnia a compagnia aerea), interpreta codici e stringhe e acquisisce le informazioni chiave per il successivo smistamento nel sistema BHS. DBO: Database di registrazione e gestione degli eventi operativi (atterraggio, arresto in piazzola, arrivo del finger o della scaletta ) e relativa interfaccia utente web-based. DBO-FOX2G: Interfaccia di DBO su dispositivo mobile. EDRIMS: Sistema di invio messaggi ed ordini di servizio agli autisti di alcuni mezzi aeroportuali (mediante smartphone). GIRM: Gestione Integrata Riparazione Mezzi - Applicativo di gestione e controllo automezzi dedicato agli operatori di officina. GULP: Gestione Unificata Logistica Piazzale - Applicativo di gestione logistica dei mezzi ed attrezzature in dotazione al personale operativo aeroportuale. M-AIS Backend: Database dei voli (effettuati e schedulati a breve, medio e lungo termine) e relativi servizi di comunicazione verso tutte le applicazioni aeroportuali e gli aeroporti esterni (tramite WebServices, gateway, e processi batch). M-AIS BIO: (Business Intelligence Operative) Strumenti datawarehouse, analitici e previsionali legati al traffico aereo, passeggeri e bagagli. M-AIS Mobile: Varie applicazioni mobile specializzate per l accesso ai dati M- AIS. M-AIS Web: Varie web-application specializzate per l accesso ai dati M-AIS. SEAMESS: Produzione / ricezione e interpretazione dei messaggi operativi aeroportuali da e verso le compagnie aeree. SIBYL: (Scan It Before You Leave) Lettura/interpretazione e gestione delle carte d imbarco. XSMP (extend Semantic System): motore di interpretazione e produzione di messaggi testuali di ogni tipo (tramite conversione da e verso un formato XML intermedio e descrittori di sintassi anch essi codificati in XML). È utilizzato principalmente per la messaggistica standard aeroportuale IATA e ICAO. Il documento [A - Elenco Applicazioni] fornisce per ciascuna applicazione: Dati Storici: o Anno di prima introduzione o Anno di ultima modifica/estensione rilevante 8/50

9 Dati statistici 1 : o Numero medio di utenti; o Numero di segnalazioni di problemi al Supporto Applicativo; o Numero di interventi di manutenzione correttiva (debug); o Numero di interventi di manutenzione evolutiva / adattativa / sviluppo; o Effort in GU degli interventi di manutenzione evolutiva / adattativa / sviluppo. Metriche software (forniscono una indicazione della dimensione e qualità del software): o Complexity/method 2 per le parti in Java, C#, C, C++ o kloc 3 di sorgenti Java, C#, C, C++ (esclusi file generati automaticamente dai tool di sviluppo) o kloc di sorgenti JavaScript (escluse librerie open source o di terza parte) e/o ShellScript o kloc di HTML, XML, CSS, PHP, JSP o Numero di package di deploy (numero di distinte App mobile o.war per installazione su Application Server o.jar per applicazioni stand-alone ) o Somma del numero di oggetti DB di tipo Table, View e Schema o Somma del numero di oggetti DB di tipo Funcion, Procedure, Package (esclusi eventuali package di libreria di terze parti caricati senza modifiche) o Numero di fussi ETL (Extract, Transform, Load) o Numero di applicazioni esterne con cui interagisce. o Numero di Universi di BusinessObject o Numero di Report di BusinessObject o Numero di distinti Server di produzione (contando i vari Application Server, DB Server, Report Server, ecc contando doppio, o triplo se aeroporti o terminal diversi hanno server distinti, ma non contando eventuali ridondanze per cluster high-availability) o Numero di dispositivi Client che richiedono una specifica installazione di software (non rientrano quindi nel conteggio eventuali personal computer o o altri dispositivi che accedano all applicazione tramite normali browser preinstallati con il sistema operativo). Fornisce inoltre anche la classificazione (secondo SEA) delle suddette applicazioni in termini di: Criticità (importanza ai fini della missione aziendale di SEA): 2 = Mission-critical; 1 riferiti all ultimo anno, alla media degli ultimi 2 anni ove possibile o in qualche caso al riproporzionamento su 12 mesi di un dato riferito a un periodo leggermente più breve, in ogni caso i numeri si riferiscono a 12 mesi 2 Complessità ciclomatica (secondo la definizione di Thomas J. McCabe) media per funzione o metodo. Il valore è calcolato tramite analisi automatizzata con il software opensource SonarQube TM di sonarqube.org 3 LOC (Line of Code) è una misura delle linee che contengono codice (escluse le linee vuote o con soli commenti. Il valore è calcolato tramite analisi automatizzata con SonarQube TM 9/50

10 1 = Importante, ma non mission-critical; 0 = Bassa criticità. Complessità (flussi e dipendenze con altre applicazioni, articolazione in vari moduli distinti e interoperanti): 2 = Molti moduli e/o molte relazioni e/o molti flussi e/o funzionalità molto complesse; 1 = Tipica architettura 3-tired; 0 = Bassa complessità, applicazione molto semplice. Stabilità (basso numero di problemi, di segnalazioni, di bug): 2 = Applicazione non ancora ben rodata o comunque poco robusta e soggetta problemi più frequenti rispetto alla media. 1 = Applicazione in esercizio con problemi occasionali o nella media. 0 = Applicazione robusta, ben rodata, con pochi problemi; Tasso di Evoluzione (In fase di evoluzione o adattamento): 2 = In fase di sviluppo con numerose e significative estensioni recenti o in corso; 1 = Nell ultimo anno solo piccole estensioni o adattamenti. 0 = Senza significativi sviluppi o modifiche da uno o più anni. Per ciascuna applicazione è indicato sinteticamente l orario di servizio di Supporto Applicativo. Esso può essere in dipendenza dell applicazione: Codice Giorni Orari 7x24h Tutti i giorni dell'anno festività e domeniche incluse 7x12h x12h 8-20 Dal lunedì al sabato escluse festività nazionali Italiane 6x08h x12h Lunedì-Venerdì, escluse festività nazionali e 2 settimane x08h fra Natale ed Epifania e 2 settimane intorno a Ferragosto Per tutte le applicazioni gestite il servizio di Manutenzione Correttiva sarà erogato su orario 6x08h (se il supporto applicativo è 6x08h o maggiore) oppure 5x08h e tutti gli altri servizi invariabilmente su orario 5x08h. Per ciascuna applicazione infine è indicato sinteticamente il livello di servizio richiesto per Supporto Applicativo e Manutenzione Correttiva che può essere: Livello di Servizio Platino Oro Argento Descrizione Massima celerità nella soluzione dei problemi Alta celerità Celerità La definizione degli SLA Platino, Oro ed Argento è dipendente dalla tipologia di servizio (supporto applicativo, manutenzione correttiva, ecc.) e sarà più avanti definita. 10/50

11 Ciascuna applicazione è descritta in maggior dettaglio negli allegati [B - Schede Applicazione] e gli allegati [C Manuali e Specifiche]. In corso di contratto l elenco delle Applicazioni gestite potrebbe subire modifiche sia in incremento (ad esempio per effetto di aggiunta di qualche ulteriore applicazione, allo stato, in corso di sviluppo o anche da sviluppare in futuro) che in decremento (qualcuna di quelle elencate inizialmente potrebbe essere dismessa). Inoltre, qualche applicazione potrebbe subire un cambio negli orari o nel livello di servizio. In tal caso, per i criteri di ricalcolo dei canoni e dei costi, si rimanda all art. 5 del contratto Nel seguito si utilizzerà la locuzione applicazioni gestite per indicare in modo sintetico tutte le applicazioni oggetto di application management nell ambito del contratto d appalto. SEA ha disponibili e metterà a disposizione dell appaltatore (sotto vincolo di riservatezza e di assoluto non riuso al di fuori del presente appalto) la manualistica e i sorgenti completi di tutte le applicazioni gestite e ne consentirà l accesso amministrativo (anche da remoto e da postazioni in mobilità). Vincolo 1. Vincolo 2. Vincolo 3. Su richiesta di SEA l Appaltatore dovrà sottoscrivere clausole di non riutilizzo, di Non-Disclosure-Agreement ed eventualmente altre analoghe limitazioni di uso e/o diffusione in merito a informazioni e software di proprietà di SEA o di terze parti, su cui dovesse lavorare nell ambito del contratto. L Appaltatore si impegna anche a far sottoscrivere tali clausole da tutte le proprie persone coinvolte. L Appaltatore deve accettare le modalità di ricalcolo dei canoni e costi in caso di cambiamento degli orari o dei livelli di servizio richiesti modellate attraverso il foglio Modifica del Simulatore Variazione Economica. L Appaltatore deve prendere in carico nuove applicazioni che SEA decidesse di aggiungere anche sviluppate internamente da SEA o da terzi, accettando le modalità di calcolo dei canoni e costi modellate attraverso il foglio Nuovo del Simulatore Variazione Economica. 11/50

12 4 Organizzazione SEA Le seguenti entità e funzioni SEA sono coinvolti nei processi legati all Appalto, (v. Figura 1): SEA: La società appaltante. SEA Telecomunicazioni: Il dipartimento di SEA che gestisce le reti di comunicazione cablate e wireless dell azienda. SEA Sistemi Informativi: Il dipartimento di SEA che cura tutte le attività informatiche. ESU (Esercizio e Supporto Utenti): La sezione dei Sistemi Informativi che supporta gli utenti. Area Sistemi: La sezione dei Sistemi Informativi che si occupa dell infrastruttura hardware (host, device e periferiche) e i principali software di base legati all hardware (sistemi operativi, database e application server commerciali e opensource con contratto di assistenza e manutenzione).). Area Applicazioni: La sezione dei Sistemi Informativi che cura lo sviluppo e la manutenzione delle applicazioni. Figura 1 - Organizzazione SEA SEA eroga direttamente i seguenti servizi: Supporto Telecomunicazioni: Servizio del dipartimento Telecomunicazioni, operativo 7x24h, responsabile di: o gestione ed attivazione dei contratti di manutenzione e di intervento per le reti e i relativi dispositivi; o monitoraggio continuo delle infrastrutture di rete o primo intervento in caso di problemi alle reti. 12/50

13 Supporto Sistemistico: Servizio dell Area Sistemistica, operativo 7x24h, responsabile di: o gestione ed attivazione dei contratti di manutenzione e di intervento per l hardware, il software di base per cui esista un contratto di assistenza; o monitoraggio dell infrastruttura informatica; o primo intervento in caso di problemi hardware (o del software di base commerciale) segnalati o rilevati; o tutti i backup delle basi di dati (anche di DB commerciali e open-source) e dei file system su server, NAS e SAN; o procedure di disaster recovery. Help Desk: Servizio erogato dall ESU di SEA, operativo 7x24h, responsabile di: o monitoraggio preventivo dell infrastruttura informatica e della continuità operativa attraverso vari strumenti (ad es. XSprotter [ o supporto degli End User per qualsiasi problema; o creazione e modifica di account di sicurezza e di permessi a livello applicativo; o raccolta delle segnalazioni di malfunzionamento di ciascuna applicazione; o registrazione in un apposito registro informatico di trouble ticketing denominato HDA delle chiamate; o diagnosi e soluzione diretta dei problemi più semplici; o invocazione del Supporto Telecomunicazioni o del Supporto Sistemistico di SEA quando il problema sia facilmente identificabile come guasto di rete o hardware; o invocazione del servizio di Supporto Applicativo dell Appaltatore per tutti i restanti malfunzionamenti; o assistenza al Supporto Applicativo per quelle attività che richiedano una presenza fisica in loco (es. riavvi di macchine client, di dispositivi o di servizi non raggiungibili da remoto, verifiche in campo, ecc ); o approvazione della soluzione fornita dal Supporto Applicativo e chiusura del ticket. Non sono oggetto di appalto: i contratti di manutenzione e assistenza hardware; i contratti di assistenza del software di base commerciale e open-source; il servizio di Supporto Telecomunicazioni; il servizio di Supporto Sistemistico; il servizio di Help Desk (di primo livello); i servizi di Disaster Recovery. Nel seguito per brevità verrà indicato con la locuzione Supporto Hardware l insieme dei servizi di Supporto Telecomunicazioni + Supporto Sistemistico di SEA. SEA nominerà un Responsabile del Contratto, una persona che avrà la responsabilità di gestire tutta la relazione contrattuale con l Appaltatore, ossia: o verificare l esecuzione e il rispetto dei livelli di servizio; o discutere aggiunte e/o rimozioni di applicazioni dall elenco delle applicazioni gestite; 13/50

14 o discutere riclassificazioni o cambi degli orari o dei livelli di servizio per le applicazioni gestite; o filtrare e approvare le richieste del business in termini di nuove implementazioni e/o modifiche alle applicazioni/infrastrutture esistenti e chiedere stime di effort e commissionare interventi di sviluppo. Per ciascuna delle applicazioni gestite sono presenti in SEA i seguenti ruoli: Application Owner: il responsabile SEA della applicazione a lui spettano le ultime decisioni in merito a eventuali modifiche ed estensioni. End User: ogni utente dell applicazione (in funzione dell applicazione possono naturalmente esistere varie tipologie di utenti). Per talune applicazioni gli End User o quanto meno alcuni End User potrebbero anche essere esterni a SEA Key User: utente con approfondite competenze sull applicazione e sui processi supportati da essa. 14/50

15 5 Squadra di lavoro Per erogare i servizi richiesti l Appaltatore dovrà comporre una squadra di lavoro (non necessariamente stabilmente impegnata) che garantisca la presenza delle seguenti professionalità: Project Manager: Svolgerà il servizio di Project Management. Sarà il responsabile dell organizzazione e il riferimento unico nei confronti di SEA per tutti i servizi erogati che prevedono interventi sul codice delle applicazioni (ossia Manutenzione Correttiva, Adattativa ed Evolutiva). Dovrà prontamente preventivare, pianificare e (se il caso) coordinare le attività del Team di Sviluppo. Service Manager: Svolgerà (eventualmente coadiuvato da operatori di backoffice che non sono considerati parte della squadra) il servizio di Service Management. Configuration Manager: sarà incaricato di tutto il servizio di Configuration Management, ossia del controllo delle versioni di sorgenti, package rilasciati e documenti. Team di Sviluppo: un gruppo di analisti e sviluppatori che opererà, all occorrenza, presso la sede SEA di Linate. Erogherà i servizi di Manutenzione Correttiva, i servizi di Sviluppo e di Attività extra. Il team di sviluppo sarà così composto: o Fino a 5 Analyst o Designer part-time (che possono essere specializzati nella raccolta di requisiti utente, nella analisi funzionale o nella progettazione e verranno occasionalmente impiegati per gli sviluppi più complessi o per le attività in cui siano richieste specifiche capacità di analisi e progettazione). o Fino a 10 Senior Developer part-time (con esperienza e capacità di analisi e progettazione autonoma per gli interventi di piccola/media complessità), Costituiranno la base più stabile del team. o Fino a 12 Junior Developer. Potranno essere utilizzati all occorrenza per grossi sviluppi o su richiesta esplicita di SEA o previo accordo di SEA, ma non andranno mai impiegati per la Manutenzione Correttiva o per gli interventi di Manutenzione Adattativa. Essi saranno distinti a seconda delle competenze in Junior Web Developer: Con competenze nella redazione di pagine web in HTML e CSS (eventualmente PHP, JSP e linguaggi similari) e magari nella manipolazione di XML con regole di trasformazione XSLT Junior DB Developer. Con competenze nella manipolazione di database e nella creazione di flussi ETL e report Business Object. Junior Java Developer. Con competenze nella programmazione Java. o Fino a 10 Tester, per le attività di testing ripetitivo o altri lavori di basso profilo tecnico. Team di Supporto Applicativo: un gruppo di massimo 10 tecnici esperti che a rotazione opererà in teleassistenza in regime di reperibilità ed erogherà i servizi di Supporto Applicativo. In determinati orari (ad es. in orario d ufficio) oppure 15/50

16 anche permanentemente i componenti del team di supporto applicativo possono coincidere (in tutto o in parte) con i Senior Developer del team di sviluppo. Tutti i componenti della squadra di lavoro dovranno padroneggiare bene la lingua italiana, che sarà la lingua utilizzata in forma scritta e parlata per ogni interazione, per tutti i documenti, per le annotazioni nei sistemi di tracking, per la documentazione del codice, ecc Le persone, ad esclusione dei Junior Developer e dei Tester, verranno tutte identificate nominativamente all inizio del rapporto contrattuale, ma potranno essere in seguito sostituite dall Appaltatore, tuttavia per minimizzare l inevitabile dispersione di knowhow è richiesto un affiancamento tra persona sostituenda e subentrante di durata minima dipendente dal ruolo secondo la Tabella 1 (le durate sono espresse in GU, giorni uomo, e si intendono per ciascuno dei due soggetti 4 ). Le giornate di affiancamento, per entrambi i soggetti, sono a totale carico dell Appaltatore e si intendono compensate all interno dei canoni di servizio. La sostituzione non giustifica in alcun modo ritardi o altre violazioni degli SLA. Figura professionale Project Manager Service Manager Configuration Manager Tecnico del Supporto Applicativo Analyst (o Designer) Senior Developer (Analista Programmatore) Junior Developer Tester Affiancam. Minimo 10 GU 2 GU 3 GU 5 GU 4 GU 10 GU 4 GU 2 GU Tabella 1 - Affiancamento minimo in caso di sostituzione Vincolo 4. Vincolo 5. Verrà utilizzata la lingua Italiana in tutte le comunicazioni scritte e verbali fra SEA e l Appaltatore, nelle annotazioni nei sistemi di tracking, nella documentazione tecnica, nella manualistica, nei commenti del codice. Tutti i componenti della squadra di lavoro dovranno essere di madre lingua Italiana o in alternativa possedere almeno una competenza linguistica di livello B2 della scala QCER (Quadro Comune Europeo di Riferimento) del Consiglio d Europa [ comprovata da: (i) certificazione CELI 3 o superiore del Centro Valutazione Capacità Linguistiche dell Università per stranieri di Perugia [ (ii) oppure certificazione CILS 2 della Università per Stranieri di Siena [cils.unistrasi.it]; (iii) oppure residenza in Italia da almeno 15 anni; (iv) oppure frequenza per oltre 10 anni scolastici non contando eventuali anni ripetuti in scuole Italiane con insegnamento in lingua Italiana; (v) oppure possesso di titolo di studio estero equipollente a Laurea Magistrale con specializzazione in Lingua Italiana. 4 Ad es. se viene sostituito un Analyst, l Appaltatore dovrà calcolare 4 GU dell Analyst uscente e 4 GU dell Analyst entrante, a proprio carico, per il passaggio di consegne. 16/50

17 Vincolo 6. Tutti i componenti della squadra di lavoro devono avere una scolarità minima pari al diploma di scuola superiore o assimilabile e minimo 2 anni di anzianità di lavorativa generica. Vincolo 7. Per i ruoli per cui è richiesta l indicazione di un nome in Scheda Offerta Tecnica l Appaltatore dovrà allegare per ciascuno: curriculum dettagliato in formato Europeo [europass.cedefop.europa.eu] e copia delle certificazioni indicate nella scheda. Vincolo 8. Per i Tester e i Junior Developer non è richiesta l identificazione preventiva e potranno cambiare durante il contratto secondo le disponibilità dell Appaltatore. L Appaltatore fornirà curriculum in formato Europeo dettagliato in occasione del primo utilizzo. Vincolo 9. Per i Junior Developer in Scheda Offerta Tecnica è richiesta una specifica delle competenze minime garantite (per ciascuna delle tre tipologie). I Junior Developer utilizzati via via durante il contratto dovranno avere competenze uguali o superiori a quelle dichiarate. Vincolo 10. L Appaltatore ove debba, per qualsiasi motivo sostituire in corso di contratto uno dei membri della squadra, esclusi Junior Developer e Tester, dovrà farlo con altra persona che abbia profilo, competenze specifiche e curriculum uguale o superiore (per la verifica andranno utilizzate le medesime schede di curriculum presenti nella Scheda Offerta Tecnica). Vincolo 11. In caso di sostituzione l Appaltatore ha obbligo di provvedere, a proprie spese, e al di fuori delle giornate fornite a SEA ad un periodo di minimo di affiancamento fra persona sostituita e sostituto come da Tabella 1. Per Junior Developer e Tester l affiancamento è richiesto solo se la sostituzione avviene nel corso del medesimo progetto. Vincolo 12. Il Responsabile del Contratto SEA, già durante il periodo di knowledge transfer, può chiedere comunque, in forma scritta e motivata, la sostituzione di un qualsiasi membro della squadra. L Appaltatore, entro 30gg solari dalla richiesta, dovrà finalizzare la sostituzione incluso il prescritto affiancamento. Vincolo 13. Le persone fisiche devono corrispondere al curriculum e alle competenze dichiarate. Casi di dimostrata difformità sono motivo di risoluzione del contratto. L Appaltatore dovrà sempre garantire in corso di contratto la presenza di profili professionali pienamente coerenti con quelli proposti in sede di offerta tecnica. Relativamente alle figure professionali del Project Manager e del Configuration Manager ne dovrà essere garantita, almeno per il primo anno, la corrispondenza effettiva col soggetto cui il curriculum di offerta tecnica inerisce. In difetto, SEA si riserva l applicazione di una penale. 5.1 Project Manager Il Project Manager durante il periodo 5x08h dovrà essere presente presso la sede di Linate secondo le esigenze di progetti in corso per controllare e coordinare il team di sviluppo e per incontri con SEA. Nel resto del tempo deve risultare facilmente raggiungibile telefonicamente e/o per . 17/50

18 5.2 Service Manager Il Service Manager deve recarsi presso la sede di Linate solo in occasione di riunioni o incontri. Negli altri momenti all interno del periodo 5x08h deve risultare facilmente raggiungibile telefonicamente e/o per Configuration Manager Potrà svolgere il proprio lavoro in remoto se necessario. Vincolo 14. Il Configuration Manager dovrà essere esperto di SubVersion, Maven, Ant e dei principali compilatori e ambienti IDE in uso per le applicazioni gestite. 5.4 Team Supporto Applicativo Il team dovrà essere composto da tecnici con buone competenze di: problematiche e gergo di ambito aeroportuale; architettura, funzionamento e specificità delle applicazioni gestite. Può coincidere in tutto o in parte, sempre o solo in certi orari con il gruppo dei Senior Developer. 5.5 Team di Sviluppo Il team di sviluppo e in particolare il gruppo dei Senior Developer, dovrà disporre di competenze sufficienti a coprire tutte le tecnologie e le metodologie utilizzate per le applicazioni gestite, in modo proporzionato alla loro importanza in SEA per il tipo di applicazioni gestite. La verifica che ogni competenza sia sufficientemente rappresentata avverrà utilizzando la matrice, presente nella Scheda di offerta tecnica, che permette di incrociare competente/componenti del team effettivamente dedicato all attività. Dai dati storici si ritiene che le attività legate ai servizi di Sviluppo e Attività extra assommeranno a circa 4 AU (Anni Uomo) all anno distribuiti in modo irregolare durante i mesi. Per poter assorbire i picchi, solo nei mesi in cui ciò è necessario, verrà quindi chiesto all Appaltatore di mettere a disposizione una squadra più ampia con FTE 5 garantiti, come da Tabella 2. Figura FTE garantiti Analyst 0.5 Senior Developer 4 Junior Web Developer 1 Junior DB Developer 1 5 FTE, Full Time Equivalent, è una misura di quantità di risorse umane, in proporzione a una persona che lavori a tempo pieno, sull orario e calendario di riferimento. Ad es. 0,5 FTE è una persona che lavora tutti i giorni solo 4 ore su 8 oppure equivalentemente una persona che lavora mediamente un giorno ogni due. Oppure 0,2 FTE è una persona che lavora 4 giorni al mese (Convenzionalmente si considera un mese formato da 20 giorni lavorativi e un anno formato dal 220 giorni lavorativi). 18/50

19 Junior Java Developer 1 Tester 2 Tabella 2 FTE Garantiti minimi (base mensile) per tipologia di figura Il significato del FTE garantito è il seguente: Su esigenza di SEA (con i preavvisi indicati in Tabella 3) l Appaltatore dovrà mettere a disposizione ciascuna risorsa del team di sviluppo almeno fino al rispettivo limite del FTE garantito (i calcoli andranno effettuati su base mensile). In ragione di ciò, le esigenze SEA dovranno avere priorità rispetto a progetti di altri clienti almeno fino a raggiungimento di detto FTE garantito. SEA viceversa non si impegna in alcun modo a saturare le risorse del team di sviluppo, che per tutto il tempo non occupato da progetti SEA possono lavorare per altri progetti e altri clienti. Esigenza Fino a 3 GU Tra 4 e 6 GU oltre Preavviso Minimo 14 gg 21 gg 30 gg Tabella 3 - Preavvisi minimi (per ciascuna risorsa) Siccome il ruolo Senior Developer è anche incaricato della Manutenzione Correttiva, che si stima pesi mediamente almeno 1 FTE il numero di Senior Developer deve superare di almeno 1 il totale di FTE offerti da questi per le attività di sviluppo ed extra. Ad es. l Appaltatore non può offrire 4 FTE (il minimo ammesso) con una squadra di esattamente 4 Senior Developer ciascuno con FTE garantito = 1: infatti nei periodi di massimo impegno per attività di sviluppo ed extra, questi sarebbero totalmente saturi e non avrebbero tempo per la manutenzione correttiva. Poiché comunque la manutenzione correttiva viene richiesta in forma di servizio separato, il valore di 1 FTE non è assolutamente vincolante né tantomeno garantito. Qualora il ruolo dei Senior Developer sia anche incaricato del Supporto Applicativo anche questo ulteriore onere deve essere sottratto alla quantità massima di FTE erogabili per il ruolo in ragione di almeno 0.2 FTE complessivi per Supporto Applicativo 5x08h e almeno 0.1 FTE per Supporto Applicativo fuori orario. SEA non può impegnarsi, soprattutto per gli anni successivi al primo, a commissionare un flusso di lavori pari a 4 AU / anno. Tuttavia introduce la seguente clausola di salvaguardia a protezione dell Appaltatore: Qualora considerando un qualsiasi periodo di 12 mesi consecutivi SEA commissionasse lavori inferiori a 3 AU, per i 12 mesi seguenti gli FTE garantiti si intendono ridotti in proporzione 6. 6 Ossia, se per ipotesi si verificasse a consuntivo che SEA in un arco di 12 mesi qualunque (ad es. da ottobre 2015 a settembre 2016) avesse commissionato sviluppi ed attività extra per soli 1.5 AU (la metà di 3 AU), tutti i limiti di FTE garantiti si considererebbero dimezzati per i 12 mesi seguenti. 19/50

20 Vincolo 15. Ciascuno dei Junior Web Developer, dei Junior DB Developer e dei Junior Java Developer deve avere competenze uguali o superiori a quelle dichiarate in Offerta Tecnica. Vincolo 16. Tutte le figure devono avere FTE garantiti uguali o superiori ai minimi indicati in Tabella 2 Vincolo 17. Non sono accettabili offerte in cui una o più competenze siano classificate insufficienti secondo le formule del modello Excel Scheda Offerta Tecnica nei fogli #A e #S. 20/50

21 6 Servizi La seguente Tabella 4 riassume in sintesi: I servizi erogati. Le risorse responsabili all interno della squadra di lavoro. L orario (e quindi il calendario) di servizio. Il tipo di compenso: a canone mensile, a punti, a giornata. Servizi Supporto Applicativo Manutenzione Correttiva Servizi di Sviluppo Manutenzione Adattativa Manutenzione Evolutiva Nuovi sviluppi Attività extra Project Management Configuration Management Service Management 6.1 Supporto Applicativo Orari Dipende da Applicazione Dipende da Applicazione 5x08h Canone mensile X Tabella 4 - I servizi in sintesi Compensi Punti X Giornata X X X Servizio prestato senza compenso esplicito Servizio prestato senza compenso esplicito Il Supporto Applicativo (talvolta chiamato anche Help Desk di Secondo Livello) è un servizio di pronto intervento che deve garantire la pronta risoluzione di ogni tipo di disservizio software (non risolto direttamente dal servizio di Help Desk di primo livello interno SEA). Il servizio non può essere invocato direttamente dagli utenti, ma esclusivamente dall Help Desk (di primo livello di SEA) o, eventualmente, dal Responsabile Contratto (SEA) o dall Application Owner (SEA). Ogni applicazione ha un proprio specifico orario di assistenza (7x24h, 7x12h ) e un proprio livello di servizio richiesto (Platino, Oro, Argento) indicati in [A Elenco Applicazioni] e riportati nella Scheda Offerta Economica Calcolo delle priorità Per determinare la priorità di un problema occorrerà procedere a due distinte e indipendenti valutazioni. Una valutazione di Severità nella seguente scala: Molto Alta: Una funzionalità non è disponibile e/o gravemente errata (ad es. è in blocco o produce dati errati, ); 21/50

22 Alta: Media: Bassa: Una funzionalità è parzialmente disponibile, produce dati quasi del tutto corretti salvo pochi errori ben definiti, rintracciabili e facilmente correggibili a posteriori (a cura del servizio di Supporto Applicativo); Una funzionalità è disponibile, ma degradata (ad es. non visualizza o stampa correttamente alcuni dati, ma non crea, archivia o trasmette dati realmente errati o incompleti); La funzionalità è disponibile con dati corretti, ma presenta minori errori formali (ad es. etichette o intestazioni errate o disallineate ) Una valutazione di Impatto nella seguente scala: Alto: Medio: Basso: La funzionalità è utilizzata frequentemente dalla maggioranza degli utenti oppure trasmette dati in tempo reale ad altre applicazioni; La funzionalità è utilizzata solo occasionalmente o solo da pochissimi utenti; La funzionalità riguarda reportistiche o processi batch che possono essere eventualmente posticipati. Determinate Severità ed Impatto, sarà possibile attribuire una Priorità, incrociando le due valutazioni nella matrice di Tabella 5 Priorità Impatto Severità Molto Alta Alta Media Bassa Alto Bloccante Bloccante Alta Media Medio Bloccante Alta Media Bassa Basso Alta Media Bassa Bassa Tabella 5 - Matrice delle priorità Processo La Figura 2 (formalismo UML Activity Diagram) illustra il processo che scatta quando l Help Desk di SEA richiede il Supporto Applicativo dell Appaltatore: le swim-lane rosa rappresentano le risorse SEA, la swim-lane verde il team di Supporto Applicativo dell Appaltatore; i rettangoli all interno rappresentano le attività rispettivamente svolte (in bianco quelle strettamente parte del servizio, in grigio le altre attività complementari). Le frecce tratteggiate indicano il flusso sequenziale delle attività e rappresentano l istante di tempo in cui l attività precedente finisce e l attività seguente può iniziare. Alcune frecce sono evidenziate da un pallino giallo numerato (estensione al formalismo UML), per indicare con precisione gli istanti presi come riferimento per la misura dei tempi vincolati dagli SLA (v. Cap ). 22/50

23 Figura 2 - Attivazione del Supporto Applicativo Il processo inizia quando un End User segnala un problema al Help Desk. L Help Desk: Attribuisce Severità ed Impatto e in funzione di queste calcola la Priorità (secondo le regole definite nel Paragrafo 6.1.1). Apre un ticket nel sistema di trouble ticketing HDA in uso in SEA. Attua una prima diagnosi che può terminare in tre modi: o Il problema è banale: L Help Desk attua una soluzione diretta o aiuta l utente a risolvere autonomamente e infine chiude il ticket in HDA. o Il problema è hardware (reti o host o software di base): Chiama in causa il Supporto Hardware SEA (Telecomunicazioni o Sistemi, a seconda dei casi), che a loro volta posso risolvere direttamente o attivare in cascata gli specifici contratti di assistenza. o Il problema è applicativo: Invoca il servizio di Supporto Applicativo dell Appaltatore (Istante 1 di riferimento, v. pallino giallo in figura: corrisponde all inizio del colloquio telefonico oppure all ora di invio della mail che descrive il problema. NB: L apertura di un ticket in HDA 23/50

24 Il Supporto Applicativo: scatena l invio automatico di una mail al Supporto Applicativo). In caso di problema Bloccante o di Alta Priorità SEA attiverà immediatamente il Supporto Applicativo anche tramite telefono. Aggiorna eventualmente il ticket in HDA. Esegue una diagnosi più approfondita e quando è terminata richiama l Help Desk comunicando che: o Il problema è hardware (un guasto prima non riconosciuto esattamente dall Help Desk). o Il problema è in effetti software, delineando la soluzione che intende adottare (Istante 2 di riferimento, in caso di ricircoli conta l ultimo passaggio). In occasione della fine della diagnosi, il Supporto Applicativo notificherà il risultato via mail e anche telefonicamente all Help Desk. Se il problema è Bloccante o di Alta Priorità, qualora l Help Desk risulti telefonicamente irraggiungibile e non dia risposta alla mail di diagnosi entro 15, il supporto applicativo procederà secondo un principio di silenzio-assenso (freccia azzurra denotata con {timeout} in figura) L Help Desk può accettare o (molto ipoteticamente) respingere motivatamente la diagnosi e/o l ipotesi di soluzione proposta. Nel caso si ricircola fino ad arrivare ad una diagnosi condivisa e a una proposta di soluzione accettabile. Nel caso il problema sia effettivamente software e la soluzione proposta sia accettata l Help Desk da il via (Istante 3) e il Supporto Applicativo: Aggiorna HDA. Attua la soluzione o (in caso di bug) applica una patch o definisce un workaround. Notifica la soluzione all Help Desk (Istante 4 di riferimento, in caso di ricircoli conta l ultimo passaggio). L Help Desk verifica la soluzione in caso negativo si ricircola. In caso positivo il Supporto Applicativo aggiorna HDA e successivamente l Help Desk chiude il ticket in HDA. Il processo in caso di invocazione da parte dell Application Owner o del Responsabile Contratto è simile, salvo che apertura e chiusura del ticket in HDA sono a carico del Supporto Applicativo. Le comunicazioni da SEA verso Supporto Applicativo potranno avvenire via telefonica o via mail (in caso di problemi Bloccanti o di Alta Priorità sempre via telefonica) Attività Il Supporto Applicativo per risolvere il problema potrà/dovrà attuare qualsiasi intervento che non includa una nuova ricompilazione e rilascio di software o una modifica strutturale delle basi di dati. I tipi di interventi più comuni attuati dal Supporto Applicativo (l elenco non è esaustivo e non va inteso in senso restrittivo) prevedono ad es.: 24/50

25 Problem determination e riavvio di servizi applicativi (*) Problem determination e riavvio di applicazioni web e web service (*) Supporto al ripristino dei servizi in seguito ad operazioni di riavvio dei sistemi (**) Interventi di riconfigurazione dei parametri applicativi (es. cambi di indirizzo, di timeout, priorità, ecc ) Cancellazione di lock o sessioni bloccate o record con dati incoerenti o spuri presenti per qualsiasi ragione nei database (*) Supporto al ripristino downgrade alla versione precedente, in caso di fault, di package applicativo o RDBMS (**) Supporto all applicazione di patch o workaround software in seguito a problem determination (**) Riesecuzione flussi dati o batch per recupero dati a fronte di malfunzionamento (*) 7 Qualora l intervento del Supporto Applicativo non sia completamente risolutivo del problema che dipende da un bug software è compito del Supporto Applicativo attivare immediatamente il servizio di Manutenzione Correttiva. Successivamente, a correzione rilasciata, compete ancora al Supporto Applicativo: Supporto alla rimozione di eventuali patch applicate in precedenza e annullamento di workaround (**) Ri-esecuzione flussi dati o batch per recupero dati a fronte di malfunzionamento (*) Correzione tramite query manuali di dati memorizzati in forma errata (*) Compensi Il servizio di Supporto Applicativo verrà prestato dietro corresponsione di un canone mensile come dettagliato all articolo 5 del contratto Vincoli Il servizio Supporto Applicativo dovrà rispettare i seguenti vincoli. Vincolo 18. È richiesto un indirizzo e numero telefonico principale unici per l intero contratto (non differenziati per applicazione o in base a eventuali turni di reperibilità) personalizzati per SEA. È ammesso soltanto che esista un secondo numero di telefono (anche cellulare) da chiamare fuori orario o quando il numero principale risulti non presidiato. Vincolo 19. Alla chiamata telefonica deve rispondere direttamente un tecnico del Supporto Applicativo dedicato a SEA senza menù vocali o passaggio da call center generici o da segreterie telefoniche, senza inserimento di PIN o altri sistemi di identificazione della società che comportino una inutile perdita di tempo. Vincolo 20. Il Tempo di risposta telefonica intercorrente fra la fine della composizione del numero telefonico (la prima volta) e il momento in cui inizia il colloquio con il tecnico (o eventualmente questi richiama) è soggetto a SLA secondo Tabella 6. (*) compatibilmente con le politiche di accesso concordate (**) attività svolta in collaborazione al Supporto Sistemistico SEA 25/50

26 Vincolo 21. In caso di comunicazione via mail ogni mail deve ricevere riscontro via mail o via telefono. Il tempo di riscontro è soggetto a SLA secondo Tabella 6. Vincolo 22. Tutte le attivazioni del Supporto Applicativo devono essere tracciate nel sistema di trouble ticketing HDA di SEA. Vincolo 23. La registrazione minima deve prevedere: Applicazione ed eventuale modulo interessati, identificativo della persona di SEA che chiama o scrive, e delle persone dell Appaltatore che rispondono e prendono in carico la segnalazione, descrizione del problema, Istante 1, Istante 2, descrizione della diagnosi, Istante 3, Istante 4, descrizione della soluzione. Vincolo 24. Il tempo di diagnosi (da Istante1 a Istante2) è soggetto a SLA secondo Tabella 6. Vincolo 25. Il tempo di soluzione (da Istante 3 a Istante4) è soggetto a SLA secondo Tabella 6. Vincolo 26. Dopo ciascun intervento se il problema deriva da bug software dovrà attivare immediatamente il servizio di Manutenzione Correttiva. Vincolo 27. Dopo ogni intervento (in particolare in caso di workaround o patch) il Supporto Applicativo dovrà monitorare la soluzione attuata affinché il problema non si ripresenti identico a breve scadenza. La ripetizione del problema è soggetta a penale secondo Tabella SLA e penali Gli SLA del Supporto Applicativo sono distinti in funzione del livello di servizio richiesto per l applicazione. Platino Oro Argento Tempo di risposta telefonica In orario 5x8h 5' 5' 5' Fuori orario (in reperibilità) 10' 10' 10' Tempo di riscontro in orario 5x8h 30' 1h 2h Fuori orario (in reperibilità) 1h 2h 4h Tempo di diagnosi Problema bloccante 1h 2h 4h Problema alta priorità 2h 4h 8h Problema media priorità 4h 8h 12h Problema bassa priorità 8h 16h 24h Tempo di soluzione/workaround Problema bloccante 1h 2h 4h Problema alta priorità 4h 8h 16h Problema media priorità 12h 24h 48h Problema media priorità 24h 48h 72h Tabella 6 SLA Supporto Applicativo Tutte le tempistiche si calcolano entro l orario di assistenza associato all applicazione. Ad es. Se una applicazione è assistita con livello Oro 7x12h (ossia tutti i giorni dalle 8:00 alle 20:00) e viene segnalato un problema ad alta priorità alle ore 19:15, è sufficiente che 26/50

27 la diagnosi venga completata entro le 2h successive, cosa che concretamente significa entro le 9:15 del giorno seguente. Relativamente al servizio si applicano le penali di Tabella 7. Tutti i ritardi sono espressi in proporzione ai tempi rispettivamente previsti in Tabella 6. Con la formula sintetica N SLA si intende un tempo N volte superiore al tempo concesso dagli SLA per quella specifica prestazione, tempo che dipende dalla priorità del problema e dal livello di servizio 8. Violazione de Tempo di risposta telefonica e Tempo di riscontro Ritardo lieve: risposta avvenuta entro un tempo doppio dello SLA (ritardo pari o inferiore a 1 SLA) Penale 100 Ritardo grave: maggiore di 1 SLA e fino a 5 SLA 500 NB: Se il ritardo grave si ripete (anche per applicazioni diverse) più di 3 volte nello stesso mese le penali di questo gruppo raddoppiano ed è motivo di risoluzione del contratto Risposta/riscontro mai avvenuti o con ritardo maggiore di 5 SLA NB: Se il fatto si ripete per la seconda volta nel corso del contratto la penale raddoppia ed è motivo di risoluzione del contratto Violazione de Tempo di diagnosi e Tempo di soluzione/workaround Ritardo lieve: diagnosi o soluzione fornite con ritardo fino a 0.5 SLA 500 Ritardo grave: maggiore di 0.5 SLA e fino a 1 SLA NB: Se il ritardo grave si ripete (anche per applicazioni diverse) più di 3 volte nello stesso mese le penali raddoppiano ed è motivo di risoluzione del contratto Diagnosi o soluzione con ritardo maggiore di 1 SLA (ossia impiegando più del doppio del tempo concesso) NB: Se il fatto si ripete per la terza volta nel corso del contratto la penale raddoppia ed è motivo di risoluzione del contratto. Ripetizione del medesimo problema Nel caso in cui il medesimo problema, per la medesima applicazione, segnalato e chiuso in precedenza si ripeta per la seconda volta a distanza di meno di 24h Nel caso in cui il medesimo problema, per la medesima applicazione, segnalato e chiuso in precedenza due o più volte si ripeta una ulteriore volta nell arco di 72h Tabella 7 Penali Supporto Applicativo Da tutte le rilevazioni saranno esclusi gli impatti sui livelli di servizio determinati da cause non direttamente imputabili all Appaltatore e specificatamente: 8 Ad es. il Tempo di soluzione/workaround per un Problema di alta priorità di una applicazione assistita con livello Oro ha SLA = 8h. Dire che per violazioni del Tempo di soluzione/workaround si applica la penale Ritardo Lieve per ritardi fino a 0.5 SLA, significa in questa fattispecie ritardi fino a 4h. Naturalmente se il livello fosse Platino o il problema fosse Bloccante, lo SLA concederebbe solo 1h e il ritardo lieve si applicherebbe solo fino a /50

28 I fermi programmati. Situazioni di disastro. Black-out prolungati. Malfunzionamenti causati da prodotti hardware/software non più supportati dal relativo fornitore. Indisponibilità della rete trasmissione dati LAN e/o telefonica. Ritardi indotti da Terze Parti. In ogni caso la sospensione della misurazione dei tempi non esime l Appaltatore dal proseguire la ricerca di eventuali workaround che, in caso di attivazione, consentano agli utenti di proseguire nelle loro attività. 6.2 Manutenzione Correttiva Consiste nella pronta correzione di difetti (bug) del software applicativo, che comportano ripetuti disservizi o errori nel funzionamento (a requisiti utente immutati). Il servizio di Manutenzione Correttiva opera secondo l orario 6x08h per le applicazioni con orario di supporto applicativo uguale o superiore a 6x08h e 5x08h per le altre. Ciò significa in pratica che non è mai richiesta per il team di sviluppo la reperibilità notturna o festiva, ma al massimo, solo per le applicazioni più critiche, la reperibilità diurna al sabato o nei periodi feriali di agosto e dicembre Calcolo della priorità La priorità per gli interventi di correzione viene calcolata con gli stessi criteri descritti per il Supporto Applicativo (v. Paragrafo 6.1.1) Processo Il processo di Manutenzione Correttiva può essere attivato a seguito di errori singoli o ripetuti dall Help Desk (SEA), dall Application Owner (SEA), dal Responsabile del Contratto (SEA) o direttamente dal Supporto Applicativo dell Appaltatore. Il processo è illustrato in Figura 3. 28/50

29 Figura 3 - Processo di Manutenzione Correttiva Il processo inizia con la registrazione (a cura del richiedente) di una richiesta di correzione nel sistema di tracking SI-Issue a cui segue immediatamente l attivazione del team di sviluppo (Istante 1 di riferimento). Il lavoro di debugging / correzione / building e testing in ambiente di sviluppo deve essere svolto esclusivamente da uno o più Senior Developer con approfondita conoscenza dell applicazione (non sono ammessi Junior Developer o altri programmatori improvvisati). Quando in ambiente di sviluppo tutto funziona entra in gioco il Configuration Manager che verifica che tutti i sorgenti siano stati correttamente rilasciati ed aggiornati nel repository SubVersion deputato e, per controllo, riesegue il check-out dal repository e il build su una macchina diversa da quelle di sviluppo e rilascia alla fine i package di deploy. Il team di sviluppo può a questo punto eseguire autonomamente il deploy in ambiente di test ed eseguire tutte le opportune verifiche (di deploy e successivamente funzionali) in questo ambiente. Finalmente il rilascio si completa con l invio dei file di deploy al Supporto Sistemistico di SEA (Istante 2 di riferimento) che provvede all installazione in ambiente di produzione. A installazione avvenuta il team di Sviluppo informa con una nota di rilascio il richiedente che chiude la registrazione in SI-Issue. In parallelo il Configuration Manager farà riprocessare i sorgenti corretti al sistema di calcolo delle metriche SonarQube. 29/50

30 6.2.3 Attività Il servizio di Manutenzione Correttiva copre tutte le attività necessarie ad eliminare bug e (per quanto possibile) correggere dati errati prodotti per effetto di un bug. I tipi di interventi più comuni attuati (l elenco non è esaustivo e non va inteso in senso restrittivo) prevedono ad es.: Esecuzione di codice passo-passo (debug) Ispezione della memoria, di variabili, e degli stack operativi degli eseguibili Correzione di sorgenti; Check-out e check-in di file sorgenti e di progetto da e verso i repository. Compilazione / build / creazione di package di deploy; Test di unità, di integrazione e funzionali Deploy in ambiente di test; Creazione di script SQL per la modifica (senza perdita di dati) di tabelle, indici, stored procedure, funzioni, permission, ecc Creazioni query o procedure per la correzione di dati archiviati in modo errato o incoerente Compensi Il servizio di Manutenzione Correttiva è compensato con un meccanismo a punti nel seguente modo. Ogni intervento ha un valore espresso in punti determinato in base al valore di Severità del bug. Severità Note Punti Molto Alta Alta Media Bassa Una funzionalità non è disponibile e/o gravemente errata (ad es. è in blocco o produce dati errati, ); Una funzionalità è parzialmente disponibile, produce dati quasi del tutto corretti salvo pochi errori ben definiti, rintracciabili e facilmente correggibili a posteriori (a cura del servizio di Supporto Applicativo); Una funzionalità è disponibile, ma degradata (ad es. non visualizza o stampa correttamente alcuni dati, ma non crea, archivia o trasmette dati realmente errati o incompleti); La funzionalità è disponibile con dati corretti, ma presenta minori errori formali (ad es. etichette o intestazioni errate o disallineate ) /50

31 In Scheda Offerta Economica il concorrente fisserà un costo a punto per ogni applicazione, considerando le metriche dimensionali e i livelli di servizio richiesti. Il compenso per la manutenzione correttiva verrà calcolato a consuntivo alla fine di ciascun mese in base al numero di interventi, alle applicazioni coinvolte e alle severità del bug risolti. Il ricalcolo del costo per punto in seguito a modifiche del software eseguite direttamente da SEA o da terzi oppure in seguito a cambiamenti dei livelli di servizio è governato dalle stesse logiche che si applicavano ai canoni del Supporto Applicativo (vedi articolo 5 del contratto). L allegato Excel Simulatore Variazione Economica, con i fogli Modifica e Nuovo consente di ricalcolare i costi a punto rispettivamente per modifiche alle applicazioni in gestione e per nuove applicazioni. L orario di assistenza e il livello di servizio potranno essere modificati unilateralmente da SEA in base alle proprie esigenze di servizio a partire da qualunque mese, a patto di darne preavviso scritto con almeno 90 gg di anticipo. In tale evenienza il costo/punto verrà ricalcolato a partire dal costo base. NB: In caso i servizi di Manutenzione Correttiva, Adattativa o Evolutiva dell Appaltatore, dovessero modificare dimensionalmente l applicazione nessuna modifica di costo è dovuta. Viceversa il ricalcolo del costo è dovuto nel caso in cui SEA realizzi autonomamente o con il supporto di fornitori terzi modifiche ed estensioni alle applicazioni gestite oppure delle applicazioni vengano dismesse parzialmente (foglio Modifica ). Nel caso in cui SEA realizzi autonomamente o con il supporto di fornitori terzi nuovi moduli o applicazioni del tutto nuovi che vengono aggiunti all elenco di applicazioni gestite, il foglio Nuovo consentirà di calcolare il costo, utilizzando come riferimento l applicazione più simile (determinata in base a una formula di distanza in uno spazio N- dimensionale) Garanzia Per quanto riguarda moduli o applicazioni sviluppate o adattate dall Appaltatore nell ambito del servizio di Sviluppo, per tutto il periodo che parte dal rilascio fino ai primi 12 (dodici) mesi completi di pieno esercizio della applicazione/modulo, tutti gli interventi di manutenzione correttiva (per quella applicazione/modulo) si intendono svolti in garanzia, quindi senza compenso. Nel periodo successivo si applicheranno i normali compensi calcolati con il meccanismo dei punti, ma con un limite insuperabile di importo annuo pari al 5% (cinque percento) dei costi di Sviluppo (eventuali costi di Analisi esclusi) Vincoli La Manutenzione Correttiva è soggetta ai seguenti vincoli: Vincolo 28. La misura del tempo di rilascio (distanza fra Istante 1 ed Istante 2) è soggetta a SLA secondo Tabella 8 31/50

32 Vincolo 29. In occasione di un rilascio tutti i sorgenti e i file di progetto, i file necessari per eseguire il build della applicazione, gli script creazione o di modifica differenziale di database e di eventuale migrazione dei dati devono essere correttamente aggiornati (con coerente numero di versione) nel repository SubVersion deputato. Vincolo 30. In occasione di ogni rilascio il Configuration Manager si farà carico di riprocessare i sorgenti con lo strumento di analisi SonarQube. E preferibile che tale riprocessamento avvenga in automatico, tramite opportuna configurazione dei file di progetto maven, ant o simili. Vincolo 31. Qualsiasi modifica alla base dati (utile a correggere situazioni anomale) dovrà essere preventivamente approvata dell Application Owner. Vincolo 32. I Package di deploy e gli script di database devono essere testati sia per l installazione, sia funzionalmente in ambiente di test e solo in caso positivo consegnati a SEA per l installazione in ambiente di produzione. Vincolo 33. Ogni correzione deve risolvere il problema per cui è stata richiesta, senza introdurre nuovi bug. Sono previste penali nel caso in cui un rilascio (magari eseguito affrettatamente per rispettare gli SLA sui tempi di rilascio) non risolva il problema o introduca nuovi bug. Vincolo 34. Ogni rilascio deve essere accompagnato da una nota (che riassuma le modifiche introdotte nella nuova versione) ed essere tracciato nel sistema SI-Issue di SEA SLA e penali Il servizio di Manutenzione Correttiva è soggetto agli SLA seguenti. Platino Oro Argento Tempo di rilascio Problema bloccante 4h 6h 8h Problema alta priorità 2g 2g 4g Problema media priorità 5g 7g 10g Problema bassa priorità 10g 15g 20g Tabella 8 - SLA Manutenzione Correttiva Relativamente al servizio di manutenzione Correttiva si applicano le penali di cui alla Tabella 9. Tutti i ritardi sono espressi in proporzione ai tempi rispettivamente previsti in Tabella 8. Con la formula sintetica N SLA si intende un tempo N volte superiore al tempo concesso dagli SLA per quella specifica prestazione, tempo che dipende dalla priorità del problema e dal livello di servizio 9. Violazione del Tempo di rilascio Penale 9 Ad es. il Tempo di Rilascio per un Problema di alta priorità di una applicazione assistita con livello Oro ha SLA = 2g. Dire che per violazioni del Tempo di rilascio si applica la penale Ritardo Lieve per ritardi fino a 1 SLA, significa in questa fattispecie ritardi fino a 2g. Naturalmente se il livello fosse Platino o il Problema fosse bloccante, lo SLA concederebbe 4h e il ritardo lieve si applicherebbe solo fino a 4h di ritardo. 32/50

33 Ritardo lieve: rilascio avvenuto entro un tempo doppio dello SLA (ritardo pari o inferiore a 1 SLA) 500 Ritardo grave: maggiore di 1 SLA e fino a 2 SLA 1000 NB: Se il ritardo grave si ripete (anche per applicazioni diverse) più di 3 volte nello stesso mese le penali di questo gruppo raddoppiano ed è motivo di risoluzione del contratto Rilasci mai avvenuti o con ritardo maggiore di 2 SLA NB: Se il fatto si ripete per la terza volta nel corso del contratto la penale raddoppia ed è motivo di risoluzione del contratto Non soluzione del problema Se, dopo un intervento correttivo, il problema che lo aveva motivato si ripresenta entro 10g solari o comunque è richiesta la ripetizione dell intervento correttivo. Insufficiente testing Se dopo un intervento correttivo per la stessa applicazione entro 10g solari si verificano nuovi problemi evidentemente causati dal primo intervento. La penale si applica a ciascun nuovo problema. 6.3 Servizi di Sviluppo Tabella 9 - Penali servizio Manutenzione Correttiva Con servizi di Sviluppo si intende l insieme dei servizi di: Manutenzione Adattativa, Manutenzione Evolutiva, Nuovi Sviluppi. Poiché hanno molte caratteristiche comuni verranno trattati assieme. Penale Penale Manutenzione Adattativa La Manutenzione Adattativa riguarda gli interventi necessari a garantire che una applicazione continui a funzionare in un ambiente modificato. A titolo esemplificativo (non restrittivo) rientrano in questa casistica: Cambio release del sistema operativo ospitante. Cambio release del software di base (DBMS, Application Server, altro MiddleWare...) Cambio release di librerie utilizzate. Cambio dei tool di sviluppo utilizzati o (es. versione di Java o passaggio da Ant a Maven per compilazione o deploy). Introduzione di nuovi tipi di messaggi IATA o ICAO. Introduzione di nuove compagnie aeree (che richiedono qualche configurazione ad hoc per biglietti, etichette bagagli e/o carte d imbarco), di nuove piazzole di sosta aerei, gate, ecc... Modifica alle applicazioni confinanti che alimentano o che vengono alimentate quella in oggetto tramite ad es. web-service o flussi ETL (senza in teoria necessità di modifiche dei flussi). 33/50

34 In certi casi i cambiamenti al contorno di questo genere non richiedono delle effettive modifiche al software, ma soltanto delle pure campagne di test che dimostrino che l applicazione continua a funzionare regolarmente pur nel nuovo ambiente. In altri casi richiedono delle effettive modifiche magari limitate. In altri casi però l impatto può essere ampio. Verranno distinte nel seguito due tipologie di interventi: Test Request (Nessuna modifica al software, solo campagna di test) Adaptation Request (Modifica al software per adattarsi ad un nuovo ambiente): La richiesta di intervento, pur sintetica, è sufficientemente precisa per poter definire un piano di sviluppo, senza bisogno di analisi dei requisiti o analisi funzionale. La particolarità di questo genere di interventi è che comunque non è mai necessario redigere un documento di analisi dei requisiti utente e/o una specifica funzionale. L applicazione rimane (almeno da un punto di vista funzionale) invariata Manutenzione Evolutiva La Manutenzione Evolutiva consiste nella modifica del software per aggiungere o modificare le funzionalità in base a nuovi requisiti utente. Verranno distinte nel seguito due tipologie di interventi: Change Request (ad es., ma non limitatamente, piccole modifiche a maschere, a report, a web service, a flussi ETL ): La richiesta di intervento è sufficientemente dettagliata e precisa per poter definire un piano di sviluppo, senza bisogno di analisi dei requisiti o analisi funzionale. Piccoli Sviluppi (es. aggiunta di maschere, report, web service, flussi ETL o altre funzionalità ben definite): Non c è bisogno di analisi dei requisiti o analisi funzionale, tuttavia c è bisogno di un piccolo documento di progetto (ad es. il mock-up delle maschere o dei report o la precisa definizione del web service Nuovi Sviluppi Si tratta dello sviluppo di moduli o applicazioni del tutto nuovi. Si distinguono due casi: Nuovi Sviluppi a Specifiche Definite: Sviluppi medi o grandi per cui l analisi è già stata eseguita e correttamente documentata direttamente da SEA o da consulenti specializzati e per cui non è necessaria una ulteriore fase di analisi. Nuovi Sviluppi con Analisi: Sviluppi medio o grandi con specifiche non completamente definite e che richiedono una fase di analisi preventiva e solo successivamente una fase di sviluppo. Di seguito elenchiamo i nuovi sviluppi prioritari da effettuare: N Applicazione Tipo Descrizione 1 XSMP Adaptation Request Porting da JBoss a JBoss EAP 6 34/50

35 2 FOX2G Nuovo Sviluppo 3 SEAMESS Nuovo Sviluppo 4 M-AIS Nuovo Mobile Sviluppo Porting della applicazione da Windows Mobile 6.5 ad Android 4.x Rifacimento su piattaforma Java. Porting da Windows Mobile 6.x a Android 4.x del solo modulo PRM Tabella 10 - Interventi di Sviluppo prioritari SEA si riserva di decidere il momento, nell arco del contratto, in cui fare partire ciascuno di questi progetti in funzione delle proprie priorità ed esigenze. Per i 4 interventi (rifacimenti o adattamenti di applicazioni o moduli esistenti) il canone di supporto applicativo delle applicazioni coinvolte non subirà alcuna sospensione o variazione. Il costo a punto per la manutenzione correttiva rimarrà invariato Processo A macro livello, ogni richiesta di intervento Adattativo o Evolutivo o di Nuovo Sviluppo a Specifiche Definite segue il processo di Figura 4 Figura 4 - Processo di Stima e Sviluppo Le richieste di Nuovo Sviluppo con Analisi seguono il processo di Figura 5. 35/50