Capitolato Tecnico Application Management
Transcript
Capitolato Tecnico Application Management
Capitolato Tecnico Application Management applicazioni “CORE BUSINESS” AM applicazioni CORE Capitolato Tecnico Indice dei contenuti 1 2 3 4 5 Introduzione................................................................................................................ 4 Glossario...................................................................................................................... 6 Applicazioni da gestire ............................................................................................... 8 Organizzazione SEA ................................................................................................ 12 Squadra di lavoro ..................................................................................................... 15 5.1 5.2 5.3 5.4 5.5 6 17 18 18 18 18 Servizi ........................................................................................................................ 21 6.1 6.2 6.3 6.4 6.5 6.6 6.7 7 Project Manager Service Manager Configuration Manager Team Supporto Applicativo Team di Sviluppo Supporto Applicativo 21 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 21 22 24 25 25 26 Calcolo delle priorità Processo Attività Compensi Vincoli SLA e penali Manutenzione Correttiva 28 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 28 28 30 30 31 31 32 Calcolo della priorità Processo Attività Compensi Garanzia Vincoli SLA e penali Servizi di Sviluppo 33 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6 6.3.7 6.3.8 6.3.9 33 34 34 35 37 37 38 39 40 Manutenzione Adattativa Manutenzione Evolutiva Nuovi Sviluppi Processo Mix di risorse Deliverable Compensi Vincoli Penali Attività extra Configuration Management Project management Service Management 41 41 42 44 Avviamento e termine dei servizi ............................................................................ 48 7.1 7.2 7.3 Knowledge Transfer Obbligo di continuità Risoluzione anticipata del contratto 48 49 49 2/50 AM applicazioni CORE 7.4 8 Termine del servizio Capitolato Tecnico 49 Allegati ...................................................................................................................... 50 3/50 AM applicazioni CORE Capitolato Tecnico 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 AM applicazioni CORE Capitolato Tecnico , 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 AM applicazioni CORE Capitolato Tecnico 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: Baggage Handling System, sistema di smistamento bagagli DBMS: Data Base Management System IDE: Integrated Development Environment: ambiente di sviluppo software che integra più editor specializzati, compilatori, debugger, ecc… AU: Anno Uomo = 220 GU MU: Mese Uomo = 20 GU GU: Giorno Uomo FTE: 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. SLA: Service Level Agreement, Valore di riferimento per il livello di servizio (solitamente un tempo massimo, un tempo minimo, una percentuale, un percentile…) SAL: Stato Avanzamento Lavori. Riunione periodica di verifica andamento di un progetto. Bug: Errore nel codice sorgente di una applicazione software. Patch: 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. Workaround: Procedura alternativa che permette di aggirare un problema. Sorgenti: 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. Presidio: La presenza fisica di uno o più addetti alle postazioni dove essi erogano normalmente i servizi di loro pertinenza. 6/50 AM applicazioni CORE Reperibilità Capitolato Tecnico 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 AM applicazioni CORE Capitolato Tecnico 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 MAIS. 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 AM applicazioni CORE Capitolato Tecnico Dati statistici1: 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/method2 per le parti in Java, C#, C, C++ o kLOC3 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 AM applicazioni CORE Capitolato Tecnico 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 7x24h 7x12h 6x12h 6x08h 5x12h 5x08h Giorni Tutti i giorni dell'anno festività e domeniche incluse Dal lunedì al sabato escluse festività nazionali Italiane Lunedì-Venerdì, escluse festività nazionali e 2 settimane fra Natale ed Epifania e 2 settimane intorno a Ferragosto Orari 00-24 8-20 8-20 9-13 14-18 8 -20 9-13 14-18 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 AM applicazioni CORE Capitolato Tecnico 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 AM applicazioni CORE Capitolato Tecnico 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 AM applicazioni CORE Capitolato Tecnico 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 [www.xech.it]); 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 AM applicazioni CORE Capitolato Tecnico 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 AM applicazioni CORE Capitolato Tecnico 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 AM applicazioni CORE Capitolato Tecnico 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 soggetti4). 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. Affiancam. Figura professionale Project Manager Service Manager Configuration Manager Tecnico del Supporto Applicativo Analyst (o Designer) Senior Developer (Analista Programmatore) Junior Developer Tester 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 [www.coe.int] comprovata da: (i) certificazione CELI 3 o superiore del Centro Valutazione Capacità Linguistiche dell’Università per stranieri di Perugia [www.cvcl.it]; (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 AM applicazioni CORE Vincolo 6. Vincolo 7. Vincolo 8. Vincolo 9. Vincolo 10. Vincolo 11. Vincolo 12. Vincolo 13. Capitolato Tecnico 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. 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. 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. 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. 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). 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. 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. 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 email. 17/50 AM applicazioni CORE Capitolato Tecnico 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 email. 5.3 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 “FTE5 garantiti”, come da Tabella 2. Figura Analyst Senior Developer Junior Web Developer Junior DB Developer FTE garantiti 0.5 4 1 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 AM applicazioni CORE Capitolato Tecnico Junior Java Developer Tester 1 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 proporzione6. 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 AM applicazioni CORE Capitolato Tecnico 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 AM applicazioni CORE Capitolato Tecnico 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. Compensi Orari Canone mensile Supporto Applicativo Dipende da Applicazione X Manutenzione Correttiva Dipende da Applicazione Servizi Servizi di Sviluppo Manutenzione Adattativa Manutenzione Evolutiva Nuovi sviluppi Attività extra Project Management Punti Giornata X X 5x08h X X Servizio prestato senza compenso esplicito Servizio prestato senza compenso esplicito Configuration Management Service Management Tabella 4 - I servizi in sintesi 6.1 Supporto Applicativo 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. 6.1.1 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 AM applicazioni CORE Capitolato Tecnico Alta: 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); Media: 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); Bassa: 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: La funzionalità è utilizzata frequentemente dalla maggioranza degli utenti oppure trasmette dati in tempo reale ad altre applicazioni; Medio: La funzionalità è utilizzata solo occasionalmente o solo da pochissimi utenti; Basso: 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 Severità Priorità Impatto Alto Medio Basso Molto Alta Bloccante Bloccante Alta Alta Bloccante Alta Media Media Alta Media Bassa Bassa Media Bassa Bassa Tabella 5 - Matrice delle priorità 6.1.2 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. 6.1.6). 22/50 AM applicazioni CORE Capitolato Tecnico 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 AM applicazioni CORE Capitolato Tecnico 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. Il Supporto Applicativo: 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). 6.1.3 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 AM applicazioni CORE Capitolato Tecnico 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 (*) 6.1.4 Compensi Il servizio di Supporto Applicativo verrà prestato dietro corresponsione di un canone mensile come dettagliato all’articolo 5 del contratto 6.1.5 Vincoli Il servizio Supporto Applicativo dovrà rispettare i seguenti vincoli. Vincolo 18. È richiesto un indirizzo email 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 AM applicazioni CORE Capitolato Tecnico 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 7. 6.1.6 SLA e penali Gli SLA del Supporto Applicativo sono distinti in funzione del livello di servizio richiesto per l’applicazione. Tempo di risposta telefonica In orario 5x8h Fuori orario (in reperibilità) Tempo di riscontro email in orario 5x8h Fuori orario (in reperibilità) Tempo di diagnosi Problema bloccante Problema alta priorità Problema media priorità Problema bassa priorità Tempo di soluzione/workaround Problema bloccante Problema alta priorità Problema media priorità Problema media priorità Platino Oro Argento 5' 10' 5' 10' 5' 10' 30' 1h 1h 2h 2h 4h 1h 2h 4h 8h 2h 4h 8h 16h 4h 8h 12h 24h 1h 4h 12h 24h 2h 8h 24h 48h 4h 16h 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 AM applicazioni CORE Capitolato Tecnico 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 servizio8. Violazione de Tempo di risposta telefonica e Tempo di riscontro email Ritardo lieve: risposta avvenuta entro un tempo doppio dello SLA (ritardo pari o inferiore a 1 SLA) Ritardo grave: maggiore di 1 SLA e fino a 5 SLA 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 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) Penale 100 € 500 € 5 000 € 500 € 2 000 € 5 000 € 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 500 € 1 000 € 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 30’. 27/50 AM applicazioni CORE Capitolato Tecnico 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. 6.2.1 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) 6.2.2 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 AM applicazioni CORE Capitolato Tecnico 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 AM applicazioni CORE Capitolato Tecnico 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. 6.2.4 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 Una funzionalità non è disponibile e/o gravemente errata (ad es. è in blocco o produce dati errati,…); 4 Alta 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); 3 Media 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); 2 Bassa La funzionalità è disponibile con dati corretti, ma presenta minori errori formali (ad es. etichette o intestazioni errate o disallineate…) 1 30/50 AM applicazioni CORE Capitolato Tecnico 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 Ndimensionale). 6.2.5 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). 6.2.6 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 AM applicazioni CORE Capitolato Tecnico 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. 6.2.7 SLA e penali Il servizio di Manutenzione Correttiva è soggetto agli SLA seguenti. Tempo di rilascio Problema bloccante Problema alta priorità Problema media priorità Problema bassa priorità Platino Oro Argento 4h 2g 5g 10g 6h 2g 7g 15g 8h 4g 10g 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 servizio9. 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 AM applicazioni CORE Capitolato Tecnico 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 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 1000 € 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 5 000 € 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. Penale 2 000 € 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. Penale 1 000 € Tabella 9 - Penali servizio Manutenzione Correttiva 6.3 Servizi di Sviluppo 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. 6.3.1 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 AM applicazioni CORE Capitolato Tecnico 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. 6.3.2 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. 6.3.3 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 1 Applicazione Tipo XSMP Adaptation Request Descrizione Porting da JBoss 4.2.2 a JBoss EAP 6 34/50 AM applicazioni CORE 2 FOX2G 3 SEAMESS 4 M-AIS Mobile Capitolato Tecnico Nuovo Sviluppo Nuovo Sviluppo Nuovo 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. 6.3.4 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 AM applicazioni CORE Capitolato Tecnico Figura 5 - Il processo di Stima – Analisi – Stima – Sviluppo Le due attività in grigio (Stima Analisi e Stima Sviluppo) sono svolte dal Project Manager (eventualmente coadiuvato dal team di sviluppo), rientrano nel processo, ma sono considerate parte del servizio di Project Management e in quanto tali compensate all’interno di quel servizio. Le due attività di Analisi e Sviluppo non sono elementari, ma non vengono qui esplose per ragioni di semplicità. Come nei diagrammi precedenti (con un’estensione al formalismo UML) sono stati marcati con pallini gialli e numerati gli istanti di tempo usati come riferimento per gli SLA (v. Capp. 6.3.8, 6.3.9 e 6.6) In entrambi le attività di Stima il Project Manager fornirà la stima impegnativa di: 10 Quale effort (in giorni uomo) di quali risorse del team di sviluppo sono previste per la attività successiva (l’analisi o lo sviluppo, a seconda dei due casi). Quale effort (in giorni uomo) di Project Management è previsto. In che tempo di consegna (elapsed) potrà essere completata la fase successiva (in considerazione della disponibilità di risorse, degli altri progetti in corso, della priorità relativa del progetto in esame). In caso di progetto ad alta priorità che eventuali slittamenti comporterebbe sui progetti già in corso. Solo nel caso di Stima Sviluppo per Nuovi Sviluppi quantificherà anche anticipatamente e in modo fisso (indipendente dalle effettive metriche) il canone base10 di supporto applicativo e il costo base a punto di manutenzione correttiva massimi. (Attenzione: sui costi manutenzione correttiva si applicano le garanzie descritte nel Cap. 6.2.5) Ossia nell’ipotesi livello Argento e orario 8x05h 36/50 AM applicazioni CORE Capitolato Tecnico Per tutte le stime che superano i 5 (cinque) GU di effort totale il Project Manager fornirà anche una circostanziata relazione accompagnatoria che giustifichi la stima, un piano di lavoro dettagliato di lavoro con task, risorse coinvolte e deliverable di ciascun task. La stima potrà essere accetta (autorizzando implicitamente l’attività successiva) o respinta anche senza spiegazioni da SEA. Le fasi di Analisi e di Sviluppo verranno svolte dal team di sviluppo sotto la direzione del Project Manager e con il supporto del Configuration Manager per i rilasci. 6.3.5 Mix di risorse Per i servizi di sviluppo sono vigenti delle limitazioni alla quantità massima di giornate utilizzabili in funzione delle varie tipologie di risorsa rispetto al totale delle giornate come da Tabella 11. L’indicazione “libero” significa nessun limite, NO significa che quel tipo di risorsa non è ammesso, una percentuale indica che quel tipo di risorsa può essere impiegato al massimo fino a quel limite. Manutenzione Adattativa Test Request Adaptation Request Manutenzione Evolutiva Change Request Piccoli Sviluppi Nuovi Sviluppi Nuovi Sviluppi a specifiche definite Nuovi Sviluppi con analisi (Analisi) Nuovi Sviluppi con analisi (Sviluppo) Analyst Senior Dev. Junior Dev. Tester NO 20% NO libero NO libero NO 30% NO libero NO 30% 10% libero NO 30% 20% libero libero 30% libero 50% NO NO 10% libero libero 30% Tabella 11 – Limiti massimi incidenza figure in GU 6.3.6 Deliverable L’Analisi produrrà o raffinerà i seguenti documenti: Specifica dei Requisiti. Specifica Funzionale. Lo Sviluppo produrrà: Sorgenti aggiornati e archiviati nei repository. Package di deploy. Script o procedure di deploy o setup automatizzato. Script di creazione o aggiornamento struttura del DataBase. Procedure di migrazione dei vecchi dati (se applicabile). Per Nuovi Sviluppi: o Manuale Utente (distinto per ciascuna tipologia di utente); o Manuale di Esercizio. 37/50 AM applicazioni CORE Capitolato Tecnico o Architettura Hardware e Software. In caso di Manutenzione Evolutiva (o anche eventuali change request in corso di progetto per Nuovi Sviluppi) dovranno aggiornare in modo coerente con l’applicazione: o Specifica dei Requisiti; o Specifica Funzionale; o Architettura Hardware e Software. o Manuale Utente (per ciascuna tipologia di utente); o Manuale di Esercizio. Piano di collaudo. Checklist di collaudo. 6.3.7 Compensi Le attività di Analisi (ove necessaria) e di Sviluppo saranno pagate applicando le tariffe contrattuali al minore fra: le giornate preventivamente stimate dal Project Manager , le giornate effettive consumate dalle varie risorse a consuntivo; Nel caso di Nuovi Sviluppi, le eventuali Change request che dovessero intervenire durante l’esecuzione del progetto, prima del rilascio, saranno trattate secondo il consueto meccanismo di stima-approvazione. Tuttavia fino ad un importo pari al 10% dell’importo complessivo del progetto (analisi + sviluppo) saranno considerate fisiologiche e dunque non fatturate. Sarà fatturata solo la quota parte eccedente il 10%. Il supporto del Configuration Manager e il coordinamento del Project Manager non rientrano nel servizio di sviluppo (servizi dettagliati nei par. 6.5 e 6.6) . Qualora SEA affidasse una applicazione di Nuovo Sviluppo in esercizio all’Appaltatore per il servizio di Supporto Applicativo e/o per la Manutenzione Correttiva si applicheranno come canoni e costi a punto si applicheranno i valori minori fra: I canoni e costi base massimi stimati preventivamente dal Project Manager (ovviamente corretti per livello di servizio ed orario di servizio effettivamente richiesti). I canoni e costi calcolati con il modello di calcolo presente nel Simulatore Variazione Economica. Il canone per il supporto applicativo sarà corrisposto (ovviamente solo in caso di affidamento in gestione) a partire dal primo mese intero successivo all’entrata in pieno esercizio (e quindi anche a coprire quello che normalmente è considerato un periodo di garanzia, ma escludendo eventuali periodi di beta-test o avviamento “in parallelo” o comunque con un ristretto numero di utenti). Per applicazioni e moduli sviluppati dall’Appaltatore non è prevista la maggiorazione del 30% per i primi 6 mesi di esercizio (maggiorazione che si applica solo alle applicazioni sviluppate da SEA o da terzi). Per i costi di manutenzione correttiva si applica il compenso calcolato in base ai punti, salvo le limitazioni di garanzia descritte nel Cap. 6.2.5. 38/50 AM applicazioni CORE Capitolato Tecnico 6.3.8 Vincoli Vincolo 35. Tutte le attività di analisi e sviluppo devono essere svolte on-site presso la sede SEA di Linate. A questo scopo l’Appaltatore dovrà affittare gli spazi necessari. Le persone dovranno essere dotate di tesserino di riconoscimento aeroportuale. Tutte le pratiche e i costi connessi sono a carico dell’Appaltatore. SEA si riserva il diritto di verificare tramite sopralluoghi a campione o strumenti di controllo accessi le effettive presenze del team di sviluppo. Vincolo 36. L’impiego di persone con profilo Junior Developer è libero solo per Nuovi Sviluppi. Per interventi Adattativi ed Evolutivi è di norma proibito salvo esplicito e preventivo consenso di SEA. Più in generale valgono i limiti massimi indicati in Tabella 11. Vincolo 37. Tutti i documenti di specifica devono adottare per i diagrammi i formalismi UML. Vincolo 38. Tutta la documentazione deve essere prodotta su template SEA con loghi e copyright SEA e diventa di proprietà di SEA che potrà utilizzarla senza limitazioni anche eventualmente per chiedere quotazioni alternative a società terze. Vincolo 39. Le Specifiche Funzionali devono contenere come minimo i mockup delle maschere e dei report più importanti. Vincolo 40. Il documento di Architettura Hardware e Software deve contenere come minimo: un diagramma UML di deploy generale della applicazione, con indicazioni dei nodi dei moduli e delle relative dipendenze; la descrizione e lo scopo di ogni modulo e delle relative interfacce; la descrizione dei protocolli e dei flussi di dati e dei web services; il diagramma E/R del database e la descrizione dettagliata di tutte le tabelle e i campi. Vincolo 41. Tutti i documenti in generale devono rispettare come minimo scaletta e contenuti indicati nel rispettivo template. Vincolo 42. Nei nuovi sorgenti i copyright, i nomi e path di classi e packages, i namespace e le URI dell’XML e più in generale ovunque sia necessario indicare un ente o un dominio di riferimento andrà utilizzata la ragione sociale “SEA” e/o il dominio seamilano.eu e non quelli all’Appaltatore. Vincolo 43. Per misurare la qualità generale del software verrà utilizzato uno strumento di analisi automatizzata dei sorgenti (SonarQube). Verranno considerati principalmente i seguenti indici: Complexity/method; Comments(%); Duplicated lines(%); Public documented API (%)11. Per le manutenzioni Adattative ed Evolutive le modifiche non dovrà peggiorare nessuno dei citati indici rispetto all’applicazione/modulo originale. Per i Nuovi Sviluppi il software dovrà avere Complexity/method < 4; Comments(%) > 20%; Duplicated lines(%) < 10%; Public documented API (%) = 100% Vincolo 44. Gli sviluppatori nella creazione o modifica dei sorgenti dovranno seguire le best practice proprie dei vari linguaggi, tipi di file e ambienti di sviluppo e (ove definite) le specifiche regole e stili di codifica o denominazione delle variabili, degli oggetti indicati da SEA o in mancanza mantenere uno stile di codifica omogeneo a quello esistente. Per tutto il mondo Java valgono in particolare le raccomandazioni di Oracle. 11 Per una definizione formale delle metriche indicate si veda la pagina web: http://docs.codehaus.org/display/SONAR/Metric+definitions 39/50 AM applicazioni CORE Capitolato Tecnico Vincolo 45. Nei sorgenti tutti i nuovi oggetti (classi, metodi pubblici, tabelle…) andranno commentati con precisione, anche a livello di logica e di semantica. L’Application Owner o suo delegato potranno eseguire delle verifiche a campione. Vincolo 46. Nel caso in cui la stima di nuovi progetti ad alta priorità preveda slittamenti a progetti in corso o comunque tempi di consegna insoddisfacenti SEA ha facoltà di verificare che effettivamente tutte le risorse alternative possibili della squadra di sviluppo sono assorbite fino al limite di garanzia. Vincolo 47. Il piano di collaudo deve essere completo e accurato. È proibito rilasciare in produzione applicazioni instabili o con alto numero di bug. Vincolo 48. Il tempo di rilascio (elapsed: distanza fra istanti 3 e 4 oppure 6 e 7 nei processi di Figura 4 e Figura 5 eventualmente corretto per gli slittamenti introdotti da progetti successivi di maggior priorità) verrà misurato in giorni lavorativi interi nel calendario 5x08h è soggetto a SLA e penali come da Tabella 12. 6.3.9 Penali Relativamente ai servizi Sviluppo (con esclusione di cause di forza maggiore o comunque non imputabili all’Appaltatore) si applicano le penali di Tabella 12: Violazione del Tempo di rilascio Franchigia: rilascio avvenuto con ritardo fino a 5gg o (se superiore) al 10% dell’elapsed promesso. Ritardo lieve: rilascio avvenuto con ritardo fino 10gg o (se superiore) al 20% dell’elapsed promesso. (NB: la penale si applica in modo secco, non proporzionale ai giorni di ritardo) Ritardo grave: ritardo maggiore. La penale penale secca + incremento giornaliero. NB: Se il ritardo grave si ripete (anche per sviluppi diversi) più di 3 volte nello stesso anno è motivo di risoluzione del contratto. Mancata disponibilità risorse Se le risorse incaricate delle attività sul “cammino critico” di un progetto urgente a fine mese non risultano essere state presenti almeno come da FTE garantiti (su base mensile), per ogni giorno di mancata disponibilità (detratto il primo concesso come tolleranza) Insufficiente testing Se dopo un intervento di Manutenzione Adattativa o Evolutiva entro 10g solari dal rilascio in produzione si verificano problemi sull’applicazione causati dall’intervento. La penale si applica a ciascun problema. Se nei primi 30g dopo l’entrata in pieno esercizio di un Nuovo Sviluppo si verificano problemi. La penale si applica a ciascun problema. NB: Se i problemi nei primi 30g superano il numero di 10 è motivo di risoluzione del contratto. Insufficiente qualità del software Se a seguito di analisi automatizzata o di verifiche a campione si rilevasse una qualità insufficiente del software rilasciato il rilascio verrà respinto e l’Appaltatore provvederà a sue spese al perfezionamento del software. Inoltre verrà applicata una penale. Penale nessuna 2000 € 5000 € +200 €/g Penale 500 € Penale 500 € 1 000 € Penale 5 000 € 40/50 AM applicazioni CORE Capitolato Tecnico Tabella 12 - Penali servizi di Sviluppo 6.4 Attività extra Con i preavvisi previsti in Tabella 3 (pag. 19) SEA potrà chiedere di avere a disposizione “a giornata” per analisi, sviluppi e test condotti in proprio, senza il coordinamento del Project Manager dell’Appaltatore, qualsiasi componente del team di sviluppo per il tempo non già impegnato in altri progetti per SEA fino al limite del suo FTE garantito. Il compenso sarà calcolato a giornata sulla base delle diverse tariffe indicate in offerta economica per le varie figure. Vincolo 49. L’appaltatore non può negare una risorsa richiesta da SEA fino a saturare la sua disponibilità garantita. In caso di violazione del vincolo scatta la seguente penale. Mancata disponibilità risorse Se una risorsa richiesta con il dovuto preavviso e viene negata e a fine mese non risultasse essere stata impiegata almeno come da FTE garantiti (su base mensile), per ogni giorno di mancata disponibilità (detratto il primo concesso come tolleranza) Penale 500 € 6.5 Configuration Management Il servizio di Configuration Management consiste nel: Verificare prima di ogni rilascio per i servizi di Manutenzione Correttiva, Perfettiva e di Sviluppo che tutti i sorgenti aggiornati siano stati rilasciati ed archiviati dal team di sviluppo, con l’opportuno numero di versione, nell’opportuno repository SubVersion in uso in SEA. Verificare che tutti i documenti previsti siano stati aggiornati e rilasciati e siano coerenti con il software. Rigenerare il package di deploy ufficiale usando un computer diverso da quelli di sviluppo. Fare analizzare i sorgenti nel sistema controllo qualità dei sorgenti in uso in SEA (SonarQube). Il servizio verrà svolto dal Configuration Manager o in assenza dal Project Manager. Non è richiesta la presenza fisica presso SEA, potendo operare anche da remoto. Poiché il servizio di Manutenzione Correttiva opera talvolta 6x08h mentre il servizio di Configuration Management opera solo 5x08h potrebbe succedere occasionalmente di sabato o durante i periodi feriali estivi o invernali che il team di sviluppo debba procedere a un rilascio correttivo urgente senza la presenza del Configuration Manager. In tale evenienza uno dei Senior Developer ne svolgerà provvisoriamente le funzioni più urgenti e il Configuration Manager ri-verificherà e completerà il lavoro il primo giorno lavorativo utile. Il servizio di Configuration Management è da intendersi compreso e compensato nel corrispettivo contrattuale 41/50 AM applicazioni CORE Capitolato Tecnico 6.6 Project management Consiste nel lavoro del Project Manager (eventualmente coadiuvato da componenti del team di sviluppo o da altri tecnici dell’Appaltatore). In particolare prevede: Organizzazione e gestione del team di sviluppo. Predisposizioni di piani, verifiche e correzioni ai piani con lo scopo di garantire il rispetto dei tempi promessi. Predisposizione di piani, stime e preventivi per gli interventi di Sviluppo (Stima Analisi e Stima Sviluppo nelle Figura 4 e Figura 5) . Preparazione e partecipazione alle riunioni periodiche (SAL con cadenza bisettimanale o settimanale a seconda del numero di interventi in corso) e a riunioni su temi specifici secondo necessità. Redazione dei relativi verbali. La predisposizione di stime, la partecipazione ai SAL e ogni altra attività che non possa essere considerata strettamente legata ad uno specifico progetto di sviluppo è prestata senza un compenso esplicito (ovviamente l’Appaltatore è libero di tarare altri canoni, costi e tariffe in modo da coprire i propri costi di servizio). L’organizzazione e la gestione del team di sviluppo impegnato in progetti di sviluppo invece è consuntivata applicando le tariffe contrattuali del project manager al minore fra: le giornate preventivamente stimate dal Project Manager per il suo stesso impegno, le giornate effettive spese dal project manager a consuntivo sul progetto; Per i servizi di project management legati ai servizi di sviluppo sono vigenti le limitazioni della quantità massima di giornate spendibili (calcolate in proporzione all’effort totale di analisi o sviluppo) come da Tabella 13. L’indicazione NO significa che quel tipo di intervento non sono ammesse giornate di project management, una percentuale indica che il project manager può essere impiegato al massimo fino a quel limite. Manutenzione Adattativa Test Request Adaptation Request Manutenzione Evolutiva Change Request Piccoli Sviluppi Nuovi Sviluppi Nuovi Sviluppi a specifiche definite Nuovi Sviluppi con analisi (Analisi) Nuovi Sviluppi con analisi (Sviluppo) Project Manager NO NO NO 5% 10% 10% 10% Tabella 13 – Limiti massimi GU di project management 42/50 AM applicazioni CORE Capitolato Tecnico Vincolo 50. In caso di progetti di sviluppo in corso il Project manager dovrà organizzare riunioni SAL regolari. Fino a 100 GU complessivi di effort previsti nel mese il SAL sarà quindicinale. Oltre il SAL sarà settimanale. La mancata organizzazione/effettuazione di uno SAL (salvo previo accordo con il Responsabile del Contratto) è soggetta a penale. Vincolo 51. Almeno il giorno lavorativo precedente ogni SAL il Project manager dovrà distribuire a tutti i partecipanti i piani Gantt aggiornati dei progetti in corso e relazione dettagliata su criticità e interventi correttivi. Vincolo 52. Dopo ogni SAL o altro incontro il Project manager dovrà inviare il relativo verbale al Responsabile del Contratto e/o all’Application Owner in bozza per approvazione. Il tempo di verbalizzazione è entro i 3gg lavorativi successivi per ogni riunione. Appena ricevuta l’approvazione sarà cura del Project Manager inoltrarlo, entro il giorno lavorativo successivo, a tutti gli interessati. Vincolo 53. Il tempo di stima (distanza fra Istante di riferimento 1 e 2 oppure 4 e 5 in Figura 4 e Figura 5 del Cap. 6.3.4) e soggetto a SLA. I giorni lavorativi (elapsed) nel calendario 5x08h, concessi per elaborare le stime sono riportati a seconda dei casi nella Tabella 14. Stima Analisi Manutenzione Adattativa Test Request Adaptation Request Manutenzione Evolutiva Change Request Piccoli Sviluppi Nuovi Sviluppi Nuovi Sviluppi a specifiche definite Nuovi Sviluppi con analisi Stima Sviluppo 3 gg 10 gg 3 gg 5 gg 3 gg 10 gg 10 gg Tabella 14 - Tempi di Stima (SLA) del Project Management In caso di superamento dei tempi di stima o verbalizzazione o in caso di mancata organizzazione di riunioni scattano le seguenti penali. Ritardo sui tempi di Stima o sui tempi di Verbalizzazione Ritardo lieve: stima o verbale forniti con ritardo fino a 1 volta lo SLA. Penale 500 € Ritardo grave: maggiore di 1 SLA NB: Se il ritardo grave si ripete (anche per stime diverse) più di 5 volte nello stesso anno è motivo di risoluzione del contratto. 1000 € Mancato SAL Ogni SAL che non è stato organizzato (per negligenza del Project Manager) o per il quale non siano stati distribuiti il giorno precedente i documenti prescritti. Penale 1 000 € Tabella 15 - Penali per il Project Management 43/50 AM applicazioni CORE Capitolato Tecnico 6.7 Service Management Consiste nella documentazione e rendicontazione dettagliata di tutti gli interventi svolti, della attività dei componenti del team di sviluppo, dei livelli di servizio raggiunti, del rispetto (o non rispetto) degli SLA concordati. Il Service Manager organizzerà riunioni periodiche (è richiesto un incontro con cadenza mensile in caso di svolgimento regolare di tutti i servizi, almeno quindicinale in caso di problemi con i servizi e non rispetto di SLA) con gli Application Owner e/o il Responsabile Contratto. Durante l’incontro i convenuti valuteranno l’andamento di tutti i servizi oggetto di Appalto. In caso di problemi o non rispetto degli SLA il Service Manager proporrà politiche correttive che verranno discusse e nel caso deliberate durante la riunione. Gli obblighi di rendicontazione prevedono in particolare che il Service Manager fornisca al Responsabile di Contratto di SEA ogni mese: Elenco delle chiamate/interventi di Supporto Applicativo. Per ogni registrazione dovrà essere come minimo indicato: o Nome della persona SEA che ha aperto la chiamata o Applicazione e modulo coinvolto o Orari di servizio e livello di servizio previsti o Priorità della chiamata o Istante (T1) di apertura o Nome del componente del team di supporto che ha gestito la chiamata (dei componenti se più d’uno si è alternato) o Diagnosi o Istante (T2) di accettazione della diagnosi o Tempo di diagnosi (T2-T1) o Istante (T3) di avvio della soluzione o Descrizione della soluzione (o patch o workaround) o Istante (T4) di completamento della soluzione o Tempo di soluzione (T4-T3) o SLA previsti o Evidenza che gli SLA sono stati rispettati o ritardi e classi di ritardo Elenco delle chiamate/interventi di manutenzione Correttiva. Per ogni registrazione dovrà essere come minimo indicato: o Nome della persona SEA o dell’Appaltatore che ha richiesto la correzione e/o o Problemi affrontati dal Supporto Applicativo che hanno fatto scattare la correzione. o Applicazione e modulo coinvolto o Livello di servizio previsto o Severità del problema o Valore in “punti” del bug o Priorità della correzione o Istante (T1) di apertura o Nomi dei componenti del team di sviluppo che hanno gestito la correzione. 44/50 AM applicazioni CORE Capitolato Tecnico o Istante (T2) di rilascio o Tempo di correzione (T2-T1) o Descrizione della correzione o SLA previsti o Evidenza che gli SLA sono stati rispettati o ritardi e classi di ritardo Elenco dei rilasci per interventi sviluppo. Per ogni registrazione dovrà essere come minimo indicato: o Applicazione/Modulo rilasciato o Motivo del rilascio o Data di rilascio o Data promessa per il rilascio o SLA o Evidenza che gli SLA sono stati rispettati o ritardi Elenco delle stime (di analisi o di sviluppo) richieste da SEA e gestite dal Project manager. Per ogni registrazione dovrà come minimo essere indicato o Progressivo identificativo o Nome del richiedente o Tipo di richiesta o Sintesi della richiesta o Data di richiesta o Data di risposta o Sintesi della risposta o SLA o Evidenza che gli SLA sono stati rispettati o ritardi Elenco delle richieste di Attività extra. Per ogni registrazione dovrà come minimo essere indicato: o Progressivo identificativo o Nome del richiedente o Data di richiesta o Risorsa richiesta o Numero GU richiesti o Data inizio Attività extra o Data fine Attività extra o Numero GU effettivamente prestati o Note o Motivazione di eventuale diniego della risorsa. Presenze delle risorse. Per ogni componente del team di sviluppo e project manager: o Nome o Tipo Figura o FTE garantito o Giorni di lavoro effettivi (al netto di assenze documentate per malattia/ferie, ecc…) o GU totali nel mese prestati per SEA per ciascun progetto/attività di Sviluppo (o Analisi) o Attività extra. 45/50 AM applicazioni CORE Capitolato Tecnico o FTE Effettivi, come rapporto fra i due numeri precedenti (NB: Gli FTE Effettivi possono essere al di sotto degli FTE garantiti perché SEA non ha chiesto sviluppi o attività extra nel mese) o Evidenza se la sottoutilizzazione della risorsa è stata causa di ritardi o immotivato diniego di Attività extra. Dettaglio risorse/attività. Per ogni componente del team di sviluppo: o Nome della risorsa o Progetto di sviluppo oppure richiesta di attività extra oppure "Manutenzione Correttiva" oppure "Supporto Applicativo" o Task o Data inizio o Data fine o GU della risorsa sul task o (NB il totale dei GU deve essere inferiore alla presenza lavorativa totale del mese. Il totale esclusa "Manutenzione Correttiva" e "Supporto Applicativo" deve coincidere con i GU totali del mese del report precedente) Elenco delle distribuzioni di report di Service Management del mese precedente. Per ogni registrazione dovrà come minimo essere indicato: o Tipo di report distribuito o Data di distribuzione o Evidenza che gli SLA sono stati rispettati o ritardi Elenco delle riunioni (coinvolgenti il Project Manager o il Service Manager stesso). Per ogni registrazione dovrà come minimo essere indicato: o Data riunione o Tipo riunione o Organizzatore o Partecipanti o Data di distribuzione del materiale preparatorio o Data di distribuzione del verbale o SLA o Evidenza che gli SLA sono stati rispettati o ritardi Elenco delle sostituzioni (avvicendamenti di risorsa) Per ciascuna dovrà come minimo essere indicato: o Ruolo o Nome risorsa sostituita o Nome risorsa sostituta o Numero di giorni di affiancamento o Elenco date in cui è avvenuto l’affiancamento o Evidenza che l’affiancamento rispetta i minimi contrattuali. Il Service Manager, in caso di mancato rispetto degli SLA indicherà in una dettagliata relazione le azioni che saranno messe in atto per riportare i servizi nell’ambito degli SLA. I Sistemi Informativi della Committente potranno, per tutta la durata del contratto, fare visite ispettive a campionamento per verificare le procedure e le modalità operative dei servizi erogati. 46/50 AM applicazioni CORE Capitolato Tecnico Vincolo 54. Il corrispettivo per il servizio di Service Management è compreso è compensato nel corrispettivo contrattuale I rapporti (relativi al mese precedente) devono essere consegnati entro il quinto giorno lavorativo di ogni mese (su calendario 5x08h). Vincolo 55. Tutti e rapporti dovranno essere in formato Excel, in modo tale da poter essere facilmente archiviati, filtrati e ordinati secondo necessità. Colori e/o icone devono evidenziare visivamente le eventuali violazioni di SLA o vincoli. Vincolo 56. In occasione dell’invio dei rapporti il Service Manager deve anche convocare la riunione mensile inviando la relativa comunicazione a tutti i partecipanti previsti. La riunione va fissata non prima di 5 e non oltre 10 gg lavorativi di distanza. Vincolo 57. Almeno il giorno precedente la riunione il Service Manager deve distribuire la relazione preparatoria (formato Power Point) in cui evidenzia i problemi eventualmente riscontrati nei servizi e le politiche correttive intraprese o da intraprendere. Vincolo 58. Entro il quinto giorno lavorativo successivo a quello di svolgimento della riunione l’Appaltatore deve inviare a tutti i partecipanti il verbale dell’incontro ed avviare le azioni decise nel corso del meeting. Vincolo 59. In caso di specifica richiesta da parte della Committente l’Appaltatore deve convocare una riunione straordinaria; è compito dell’Appaltatore organizzare l’incontro, entro il terzo giorno successivo alla richiesta previa disponibilità delle figure deputate a parteciparvi e comunque non oltre il quinto giorno. In caso mancato invio di report nei tempi previsti, di mancata organizzazione di incontri nei tempi previsti o di superamento dei tempi di verbalizzazione scattano le seguenti penali: Mancato o parziale invio dei report entro i termini Penale NB: il rifiuto a rendicontare o una rendicontazione intenzionalmente falsata è motivo di risoluzione del contratto. Mancata organizzazione di riunione entro i termini Penale Mancata o ritardata verbalizzazione Penale Penale 5 000 € Penale 500 € Penale 500 € Tabella 16 - Penali per il Service Management 47/50 AM applicazioni CORE Capitolato Tecnico 7 Avviamento e termine dei servizi Successivamente alla stipula dell’Accordo Quadro, e prima dell’attivazione dei singoli contratti applicativi e conseguente erogazione dei relativi canoni mensili, sotto la responsabilità e la pianificazione del Responsabile del Contratto, opera un periodo transitorio finalizzato al knowledge transfer. 7.1 Knowledge Transfer La durata del periodo transitorio sarà superiore o uguale a 40gg solari e inferiore a 71gg e sarà determinata in modo tale da far decorrere il primo contratto applicativo esattamente dal primo giorno del mese . Durante il periodo transitorio le società che hanno attualmente in carico l’Application Management continueranno a erogare regolarmente il servizio, dando tempo al nuovo Appaltatore di organizzare i servizi e istruire le persone. SEA organizzerà un ciclo di affiancamento/formazione denominato per brevità Knowledge Transfer destinato ai Senior Developer e (ove diversi) ai componenti del team di Supporto Applicativo. Il Knowledge Transfer sarà articolato in varie sessioni parallele che riguarderanno gruppi di applicazioni diverse, come sintetizzato in Tabella 17. La durata di ogni sessione è espressa in giorni lavorativi di 8h (non necessariamente continuativi) e seguirà un proprio calendario che sarà comunicato al momento della stipula. Sessione Applicazioni 1 Agente FIDS, DBO, DBOFOX2G, EDRIMS, GIRM, GULP 2 3 4 M-AIS – Backend M-AIS - BIO, Mobile, Web BASH, SEAMESS, SIBYL, XSMP Durata 10gg 10gg 10gg 10gg Tabella 17 - Knowledge Transfer Ogni sessione sarà affidata a uno o più formatori che potranno appartenere al personale della Committente o delle società che hanno attualmente in gestione le applicazioni. La frequenza per tutti i Senior Developer e (ove diversi) per tutti i tecnici del Supporto Applicativo è obbligatoria: ciascuno di loro deve seguire almeno una sessione per non meno del 90% della sua durata e ad ogni sessione deve partecipare almeno un Senior Developer e (ove distinti) almeno un tecnico del Supporto Applicativo. Per gli altri componenti della squadra la partecipazione è libera, a piena discrezione dell’Appaltatore. Come dimostrazione certa che l’architettura e il funzionamento tecnico di ciascuna applicazione siano stati pienamente compresi, l’Appaltatore dovrà produrre su template SEA il “Manuale di Esercizio” di ciascuna applicazione in gestione entro 10 gg lavorativi dal termine della rispettiva sessione. Tali documenti diverranno di proprietà SEA, ma saranno ovviamente utilizzati per il servizio di supporto applicativo. 48/50 AM applicazioni CORE Capitolato Tecnico Il ciclo di Knowledge Transfer è gratuito (l’Appaltatore non dovrà pagare SEA per la formazione ricevuta), ma anche non retribuito (SEA non pagherà in alcun modo le giornate consumate dalle risorse dell’Appaltatore né durante la formazione, né durante la redazione dei Manuali di Esercizio). Qualora ad insindacabile giudizio dei rispettivi Application Owner il livello dei manuali di Esercizio dimostrasse una insufficiente o addirittura errata comprensione dell’architettura e del funzionamento tecnico di qualche applicazione il Responsabile del Contratto potrà posticipare di un mese l’emissione del primo contratto applicativo e prevedere alcune giornate integrative di Knowledge Transfer. L’Appaltatore dovrà provvedere al rifacimento/perfezionamento dei manuali incompleti o inesatti. Un secondo rilascio di manuali incompleti o inesatti costituirà giusta causa per la risoluzione del contratto. 7.2 Obbligo di continuità Qualora, allo scadere dell’Accordo Quadro ovvero dell’ultimo contratto applicativo attivato sul medesimo, per intervenuti impedimenti connessi all’individuazione del nuovo Appaltatore, SEA non fosse in grado di procedere alla nuova contrattualizzazione (ad esempio a motivo delle vicende giudiziali che hanno interessato la procedura di affidamento del nuovo contratto) l’Appaltatore, su richiesta di SEA formulata entro il termine di scadenza, espressamente riconosce e accetta sin d’ora di svolgere, in regime di prorogatio, i Servizi agli stessi patti e condizioni di cui all’Accordo quadro per un periodo della durata massima di 6 (sei) mesi. 7.3 Risoluzione anticipata del contratto Qualora a causa del non rispetto dei livelli di servizio o del verificarsi di altre gravi manchevolezze, indicate espressamente nel presente capitolato come motivo di risoluzione del contratto, si arrivasse a una interruzione anticipata del rapporto per volontà di SEA, l’Appaltatore avrà comunque l’obbligo di garantire la continuità del servizio per il periodo che verrà indicato da SEA, comunque non oltre i sei mesi successivi. 7.4 Termine del servizio Nell’ultimo mese di servizio, l’Appaltatore si impegna fin d’ora a mettere a disposizione, secondo le richieste di SEA fino a 60 giornate di Senior Developer aggiuntive (retribuite secondo tariffe in essere) e concentrate in 30gg solari per un ciclo di knowledge transfer verso la o le società subentranti analogo a quello ricevuto in avvio. 49/50 AM applicazioni CORE Capitolato Tecnico 8 Allegati [A – Schede Applicazione] AM CORE SCHEDE APPLICAZIONI.ZIP (un file per applicazione contenente descrizione tecnica degli ambienti) [B – Manuali e Specifiche Funzionali] AM CORE MANUALI E SPECIFICHE FUNZIONALI.ZIP (all’interno il file “elenco_documenti.xlsx” contiene l’elenco dei documenti) [C – Template Documenti di progetto] AM CORE TEMPLATE DOCUMENTI PROGETTO.ZIP 50/50