Capitolato Tecnico Application Management

Transcript

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
7.4
8
Termine del servizio
Capitolato Tecnico
49
Allegati ...................................................................................................................... 50
3/50
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




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
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
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
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


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
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
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
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


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
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
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
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
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
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
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
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
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
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
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
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
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








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
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
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
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
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






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
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
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
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
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 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
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
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
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
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
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

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.
Test Request
Adaptation Request
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



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
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
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
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
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.

Test Request
Adaptation Request
Change Request
Piccoli Sviluppi
Nuovi Sviluppi
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
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
Test Request
Adaptation Request
Change Request
Piccoli Sviluppi
Nuovi Sviluppi
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
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




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
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




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
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
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
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
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
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
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

Capitolato Tecnico Application Management

Transcript

Documenti analoghi

Convegno Propeller Club Livorno 20 gennaio 2014 “Sea Shepherd

Spec Sheet for sea doo sportster le di `

Fish Menu KAISERSTUBE - Union Hotels Canazei

CELENTANO

APRE OGGI IL NUOVO NEGOZIO HERMES AL

modulo d`iscrizione al corso “tecniche di audit: iso 19011”

the sea il mare folco quilici paul watson shark angels

ISLAND HOTEL KATARINA - ROVINJ A 25/09

software - Maurizio Gambino.it