Contract
1
Ricerca di soggetti qualificati
per un servizio di estensione e manutenzione dell’ecosistema digitale
di Muoversi in Toscana
Lotto unico
CIG: 8184985F48 ID gara: 7667842
Codice commessa: PROG/72
Allegato 1 - Capitolato Tecnico Prestazionale
2
1. Oggetto e scopo del CTP
Il presente documento contiene le indicazioni necessarie a circoscrivere e dettagliare i servizi oggetto del relativo Contratto di appalto, rispondenti alle esigenze gestionali e organizzative di FST. Questo documento individua le caratteristiche tecniche generali con lo scopo di indicare lo standard qualitativo prestazionale imposto all’esecutore, affidatario del relativo appalto, in conformità alle normative tecniche vigenti ed alle previsioni di legge e contrattuali.
2. Oggetto del Servizio e contesto di riferimento
L’aggiudicatario del presente appalto si impegna – come da contratto di cui questo Capitolato costituisce allegato tecnico e in riferimento al contesto descritto nel Disciplinare e nelle Specifiche Tecniche – a procedere con la progettazione di estensioni e adattamenti funzionali delle componenti software fondamentali dell’ecosistema digitale di Muoversi in Toscana, nonché con la presa in carico della manutenzione correttiva per l’intero sistema.
Come contesto di riferimento, vale quanto segue:
• Regione Toscana ha realizzato un ecosistema digitale che ha il compito principale di raccogliere i dati, sia offline che in tempo reale, provenienti dalle aziende autorizzate per il trasporto pubblico nel territorio regionale e di restituire funzioni a valore aggiunto agli utenti finali.
• Le principali componenti software di tale ecosistema sono:
o Back-end, che riceve I flussi di dati in ingresso dalle aziende di trasporto, effettua la ricerca georeferenziata di linee e di percorsi, gestisce l’interscambio delle informazioni in tempo reale e le notifiche agli utenti finali, gestisce le credenziali e le preferenze degli utenti finali.
o App per smartphone, in versione iOS e Android, che costituisce il canale principale di fruizione dell’ecosistema digitale su smartphone e dispositivi analoghi; consente la ricerca dei percorsi, la visualizzazione integrata di social network e di news, permette la registrazione e la sottoscrizione a notifiche su linee e corse.
o Sito web (Travel Planner), che costituisce il canale principale web per la fruizione dell’ecosistema, consente la ricerca dei percorsi, la visualizzazione integrata di social network e di news.
Per le versioni attualmente pubblicate delle componenti di cui sopra si veda anche [1][2][3] nell’Art. 3 del presente Capitolato.
Dal punto di vista tecnico, le componenti software dell’ecosistema digitale di Muoversi in Toscana sono descritte in dettaglio nell’Allegato 2-Specifiche Tecniche.
Nell’ambito del contesto sopra descritto, l’oggetto del servizio include:
a) Estensioni funzionali del back-end: integrazione di nuove sorgenti dati (ulteriori aziende di trasporto, estensione al tempo reale), estensione dell’integrazione al trasporto multimodale, integrazione di funzioni di supporto all’uso combinato di mezzi di trasporto privati e pubblici, creazione di una API accessibile a terze parti con chiave d’accesso, estensione delle funzioni di ricerca con calcolo della sostenibilità ambientale e proposte di alternativa all’uso di mezzi privati.
b) Estensioni funzionali della app per smartphone: integrazione delle informazioni turistico-culturali georeferenziate provenienti da Visit Tuscany di Fondazione Sistema Toscana, identificazione automatica dei percorsi abituali, suggerimento anche proattivo di alternative di percorso a maggiore sostenibilità ambientale, logging delle attività sulla app (behavior intelligence).
c) Estensioni funzionali del sito web (Travel Planner): funzioni di creazione di widget da inserire in siti web di terze parti per ricerca percorsi, news e integrazione social, creazione di un’area riservata agli utenti registrati, integrazione di funzioni di registrazione utenti e di gestione profilo in modalità multipiattaforma (app smartphone + sito web e travel planner).
d) Manutenzione adattativa ed estensiva dell’ecosistema digitale: progettazione e realizzazione di
adattamenti ed evoluzioni dell’ecosistema digitale, in collaborazione con Fondazione Sistema
3
Toscana, secondo le necessità e le opportunità che potranno emergere nell’ambito della durata del
servizio.
e) Manutenzione correttiva dell’ecosistema digitale, intesa come garanzia di corretto funzionamento e di continuità operativa dell’ecosistema digitale dispiegato sulle infrastrutture hardware, software e di rete gestite da Fondazione Sistema Toscana, per la durata di 26 mesi a partire dalla data di avvio dei servizi del presente appalto, rinnovabile per un massimo di ulteriori 12 mesi.
Per tutte le estensioni funzionali e le manutenzioni sopra indicate si intende che il fornitore dovrà farsi carico, oltre che della progettazione esecutiva in collaborazione con Fondazione Sistema Toscana e della realizzazione effettiva, anche della messa in esercizio sulle infrastrutture hardware, software e di rete gestite da Fondazione Sistema Toscana, secondo le modalità operative indicate da quest’ultima.
La progettazione delle estensioni funzionali sopra indicate include anche la progettazione delle estensioni della user experience per gli utenti finali, laddove necessario. Il progetto delle estensioni della user experience per gli utenti finali dovrà essere esplicitamente approvato da Fondazione Sistema Toscana.
Le specifiche del servizio sono dettagliate nei paragrafi successivi.
3. Riferimenti
[1] App ‘Muoversi in Toscana’ come pubblicata su Google Play e Apple App Store xxxxx://xxxx.xxxxxx.xxx/xxxxx/xxxx/xxxxxxx?xxxxx.xxxxxxx.xxxxxxx.xxxxxxxxxxxxxxxxx xxxxx://xxxx.xxxxx.xxx/xx/xxx/xxxxxxxx-xx-xxxxxxx/xx000000000
[2] Componente web del portale di Regione Toscana dedicata al ‘Muoversi in Toscana’
xxxxx://xxx.xxxxxxx.xxxxxxx.xx/xxxxxxxx/xxxxxxxx-xx-xxxxxxx
[3] Componente web ‘Travel Planner’ del portale di Regione Toscana
xxxxx://xxx.xxxxxxxxxxxxxxxx.xx/xx/xxxxxxxxxxxxx/
4. Allegati
[4] Muoversi In Toscana, Documento Tecnico Descrittivo (Allegato 2 - Specifiche tecniche)
5. Requisiti funzionali e tecnici
5.1 Criteri generali
ID | Descrizione |
GEN.1 | Dal punto di vista strategico, in base alle indicazioni di Regione Toscana, gli obiettivi principali dell’ecosistema digitale di Muoversi in Toscana e più in generale del servizio qui descritto sono i seguenti: a) Fornire un servizio orientato al sostegno e alla promozione della mobilità sostenibile con attenzione particolare, ma non esclusiva, ai viaggiatori abituali (pendolari). b) Permettere la visibilità del sistema complessivo dei mezzi di trasporto pubblici e comunque condivisi sul territorio della Regione Toscana, con |
particolare riferimento a linee e orari prestabiliti, ai dati di circolazione in tempo reale e alle informazioni di servizio (news). c) Costituire un punto di collegamento tra gli utenti della mobilità pubblica e le principali social network, con obiettivo di aggregazione, condivisione e comunicazione anche diretta tra gli utenti dei servizi di mobilità. d) Promuovere la mobilità ‘eco friendly’ intesa come migliore sostenibilità delle modalità di trasporto adottate dagli utenti finali nell’ambito territoriale della Regione Toscana. |
4
5.2 Estensioni funzionali del Back-end
ID | Descrizione |
FUN.1 | Il modulo di Back-end deve essere esteso per integrare i flussi dati di ulteriori aziende di trasporto, riguardanti linee, corse e orari previsti, oltre che all’integrazione delle informazioni in modalità real-time, riguardanti i tempi effettivi delle corse. Riguardo all’integrazione dei flussi di dati, si assume quanto segue: • il formato standard di integrazione verso il Back-end delle linee e corse previste è il “General Transit Feed Specification” (GTFS), anche noto come “GTFS Static Transit” di Google; • il formato standard di integrazione verso il Back-end delle informazioni in tempo reale è il “GTFS Realtime” di Google. |
FUN.2 | Si assume, come inclusa nel servizio qui descritto e quindi a carico del fornitore, l’integrazione di flussi di dati in ingresso provenienti da nuove aziende di trasporto pubblico nonché l’adeguamento funzionale dei flussi esistenti, laddove necessario, nei termini dei formati standard sopra descritti, per tutta la durata del servizio stesso. Viceversa, per quanto riguarda l’adeguamento di flussi di dati in formati diversi dai formati standard sopra indicati, il fornitore si impegna a realizzare moduli di adattamento – laddove tecnicamente possibile – nell’ambito della manutenzione adattativa ed estensiva, come specificato più avanti. |
FUN.3 | Il Back-end dell’ecosistema digitale dovrà essere esteso ad integrare anche i flussi di dati relativi all’esempio di ATAF Firenze, per la quale al momento non sono disponibili informazioni in real-time del tipo richiesto da GTFS Realtime (informazioni relative alle corse specifiche), ma di tipo diverso (informazioni ‘alle paline’, indicanti i prossimi arrivi in fermata delle linee previste). L’integrazione dei flussi relativi alle informazioni in real-time di ATAF è inclusa nel servizio qui specificato e quindi a carico del fornitore, a titolo di integrazione pilota. Viceversa, l’integrazione di altri flussi analoghi sarà effettuata nell’ambito della manutenzione adattativa ed estensiva, come specificato più avanti. |
ID | Descrizione |
FUN.4 | Il modulo di Back-end deve essere esteso per migliorare il supporto alla mobilità multimodale. In particolare, il fornitore dovrà proporre integrazioni ed estensioni sulle seguenti tematiche: a) uso delle biciclette, con indicazione dei mezzi pubblici che ne ammettono il trasporto e introduzione della possibilità di ricercare percorsi adatti a tale modalità combinata; |
b) importazione dei luoghi dei parcheggi scambiatori e - laddove possibile – le indicazioni in tempo reale dei posti disponibili, introduzione della possibilità di ricercare percorsi adatti alla modalità combinata di mezzo privato e pubblico; c) importazione dei luoghi dei punti di ricarica dei veicoli elettrici e - laddove possibile – le indicazioni in tempo reale dei posti disponibili, introduzione della possibilità di ricercare percorsi adatti a veicoli elettrici con indicazione della prossimità di punti di ricarica. | |
FUN.5 | Il modulo di Back-end deve essere esteso per integrare le modalità di trasporto in mobility sharing (inteso come car, bike, motorbike e micromobility sharing). In particolare, il fornitore dovrà proporre integrazioni ed estensioni sulle seguenti tematiche: a) importazione delle aree servite in queste modalità da parte di aziende convenzionate con gli enti territoriali, con possibili collegamenti ai sistemi terzi di tali aziende; b) introduzione della possibilità di ricercare percorsi che integrino l’uso di mobility sharing. Per ovvie ragioni, la realizzazione delle proposte del fornitore potrà essere subordinata alla stipula di accordi specifici tra gli enti territoriali e le aziende di mobility sharing. |
ID | Descrizione |
FUN.6 | Il modulo di Back-end deve essere esteso per migliorare il supporto alla mobilità sostenibile. In particolare, il fornitore dovrà proporre integrazioni ed estensioni sulle seguenti tematiche: a) calcolo dell’impatto ambientale dei singoli percorsi, a partire dai metodi di calcolo attualmente adottati (in particolare basati sull’emissione di CO2), possibilmente con indicazione complessiva e di dettaglio per ciascuna linea; b) introduzione della possibilità di organizzare i risultati della ricerca dei percorsi in base alla sostenibilità ambientale, inclusa la possibilità di fornire suggerimenti e indicazione di percorsi alternativi. |
ID | Descrizione |
FUN.7 | Il modulo di Back-end deve essere predisposto per integrare le informazioni relativa al calcolo delle tariffe e in particolare con le informazioni relative sistema tariffario Pegaso di Regione Toscana. In quest’ottica, il fornitore dovrà proporre integrazioni ed estensioni funzionali riguardanti la gestione delle informazioni relative alle tariffe dei mezzi di trasporto e alle modalità di visualizzazione verso gli utenti finali. |
ID | Descrizione |
FUN.8 | Il modulo di Back-end deve essere esteso per integrare i dati relativi alle informazioni e alle attrazioni turistico/culturali provenienti dal sistema Visit Tuscany, gestito da Fondazione Sistema Toscana. In particolare, il fornitore dovrà proporre integrazioni ed estensioni sulle seguenti tematiche: a) importazione dei luoghi rilevanti a partire dal sistema Visit Tuscany e modalità di accesso automatico alle informazioni corrispondenti; |
5
b) introduzione della possibilità di collegare i risultati della ricerca dei percorsi ai luoghi rilevanti anche specificando filtri tematici sugli argomenti di interesse; c) ai luoghi di interesse potrà essere associato uno score di rilevanza, da utilizzare per selezionare la quantità dei luoghi da visualizzare in base alla scala e alla densità. |
ID | Descrizione |
FUN.9 | Il modulo di Back-end deve essere migliorato dal punto di vista del supporto all’immediate feedback per facilitare la ricerca di luoghi e indirizzi. Preferibilmente, tale feedback dovrà essere filtrato in base alla posizione da cui viene effettuata la richiesta. |
ID | Descrizione |
FUN.10 | Il modulo di Back-end deve essere migliorato dal punto di vista del supporto alla gestione dei flussi di informazioni e news di origine redazionale e gestite da Fondazione Sistema Toscana. |
ID | Descrizione |
FUN.11 | Si intende che le proposte del fornitore riguardo ai requisiti qui indicati dovranno essere esplicitamente descritte in offerta tecnica, incluse le precondizioni necessarie per la realizzazione, e sono impegnative, nel senso che il fornitore si impegna alla progettazione e realizzazione effettiva delle proposte stesse qualora siano soddisfatte le condizioni indicate nell’offerta tecnica. |
FUN.12 | In assenza di altra indicazione, si intende che il fornitore si farà carico di tutti gli oneri eventualmente derivanti dall’utilizzo di sistemi e servizi software di terze parti, per tutta la durata del servizio. Qualsiasi eccezione a quanto sopra, intesa come esclusione di costi comunque necessari al funzionamento del Back-end dovrà essere esplicitamente indicata in offerta tecnica ed accompagnata dall’indicazione dei costi necessari per l’acquisizione dei sistemi e/o dei servizi software. |
ID | Descrizione |
SWR.1 | Preferibilmente, il Back-end dovrà essere realizzato con tecnologie analoghe a quelle attualmente utilizzate. In ogni caso, il fornitore avrà a disposizione il codice sorgente dell’implementazione attuale. |
6
5.3 Estensioni funzionali della app per smartphone
ID | Descrizione |
FUN.13 | La app per smartphone deve essere dotata di un sistema di raccolta delle informazioni di utilizzo che permetta, previo consenso degli utenti finali, di raccogliere dati sull’uso della app a scopo di behavior intelligence. Di concerto con Regione Toscana e Fondazione Sistema Toscana, entro limiti eticamente e legalmente accettabili, la app per smartphone potrà anche raccogliere dati di posizione degli utenti finali, sempre previo consenso di questi ultimi. |
FUN.14 | La app per smartphone deve essere estesa per integrare la possibilità di visualizzare, insieme ai risultati della ricerca dei percorsi, i luoghi di interesse turistico-culturale descritti nel sistema Visit Tuscany. Dovrà essere possibile definire dei filtri tematici e dei filtri sulle caratteristiche di interesse da applicare alle ricerche. Dovrà essere possibile effettuare uno zoom su aree specifiche ed ottenere quindi la visualizzazione di un maggior numero di punti di interesse. |
FUN.15 | La visualizzazione dei risultati delle ricerche sulla app per smartphone deve essere integrata dalle indicazioni di sostenibilità ambientale del percorso prescelto. |
FUN.16 | Riguardo alla mobilità sostenibile, il fornitore dovrà proporre integrazioni ed estensioni sulle seguenti tematiche: a) proposta proattiva agli utenti finali di alternative a maggiore sostenibilità ambientale anche con lievi modifiche al percorso; b) definizione di punteggi ‘green’ differenziali, che possano premiare le scelte migliori a parità di percorso o con lievi modifiche, anche facendo uso delle funzioni di behaviour intelligence; c) estensione della attuale modalità di attribuzione del punteggio ‘green’ allo scopo di premiare non tanto il percorso singolo ma la scelta della modalità di trasporto complessivamente più sostenibile. Il fornitore potrà inoltre proporre l’uso di funzioni di behaviour intelligence allo scopo di identificare in modo automatico i percorsi abituali e, quindi, di proporre tramite la app alternative maggiormente sostenibili. Proposte di quest’ultimo tipo, se specificate in offerta tecnica, saranno impegnative per il fornitore e saranno oggetto di valutazione. |
FUN.17 | Deve essere prevista la possibilità di integrare un agente conversazionale (un chatbot) all’interno della app per smartphone, con lo scopo di facilitare le ricerche degli utenti finali, fornire indicazioni e news rilevanti, anche tramite il rinvio ai social, e proporre comportamenti di maggiore sostenibilità ambientale. In linea di principio si assume che il chatbot sia realizzato come un plugin che utilizza servizi in cloud. La realizzazione del chatbot non è inclusa nel servizio qui descritto e sarà oggetto di un affidamento a parte. |
ID | Descrizione |
FUN.18 | La app per smartphone deve essere estesa per includere la visualizzazione delle informazioni relative alle tariffe, incluse quelle riguardanti il sistema Pegaso di Regione Toscana. |
ID | Descrizione |
FUN.19 | La user experience della app per smartphone deve essere fruibile in lingua italiana e in lingua inglese, con una scelta per default che dipende dalla lingua utilizzata sullo smartphone (ITA => ITA, non ITA => ENG) che può essere modificata dall’utente. Attualmente, la app per smartphone è fruibile solo in lingua italiana. |
ID | Descrizione |
FUN.20 | Per tutte le estensioni funzionali della app per smartphone, il fornitore dovrà farsi carico della progettazione della user experience complessiva, intesa come estensione di quella attualmente esistente. Proposte di estensione in questo senso dovranno essere illustrate nell’offerta tecnica e saranno oggetto di valutazione. |
7
Il progetto della user experience da realizzare effettivamente nella app per smartphone dovrà essere ulteriormente raffinato nel corso dell’esecuzione del servizio, in collaborazione con Fondazione Sistema Toscana. |
ID | Descrizione |
SWR.2 | Preferibilmente, la app per smartphone dovrà essere realizzata con tecnologie analoghe a quelle attualmente utilizzate. In ogni caso, il fornitore avrà a disposizione il codice sorgente dell’implementazione attuale. |
8
5.4 Estensioni funzionali del sito web (Travel Planner)
ID | Descrizione |
FUN.21 | Il sito web e il Travel Planner devono essere estesi per permettere la funzione di registrazione e di accesso degli utenti finali. Tale sistema dovrà essere condiviso con quello già attualmente esistente per la app per smartphone, allo scopo di realizzare un sistema multicanale di gestione delle credenziali. Anche le funzioni di profilazione e di gestione delle preferenze, per ricerche e notifiche, dovrà essere condiviso. Dovrà inoltre essere introdotta la possibilità di ricevere notifiche tramite email. |
FUN.22 | Il sito web e il Travel Planner devono essere estesi per realizzare, nei limiti del possibile e di quanto opportuno, la parità di funzioni con la app per smartphone. |
FUN.23 | Il sito web e il Travel Planner devono essere estesi per includere la visualizzazione delle informazioni relative alle tariffe, incluse quelle riguardanti il sistema Pegaso di Regione Toscana. |
FUN.24 | Il sito web e il Travel Planner devono essere estesi per migliorare le possibilità di integrazione con le funzioni social e di accesso alle news. |
ID | Descrizione |
FUN.25 | Il Travel Planner deve essere esteso per includere la possibilità di comporre online un widget da inserire in siti web di terze parti. La composizione del widget dovrà permettere di facilitare la selezione dei criteri di ricerca da parte degli utenti finali in base alle indicazioni del progettista del sito web ospitante. Ad esempio, dovrà essere possibile preselezionare a scelta: • punto di arrivo e/o di partenza; • date e orari; • modalità di trasporto. Dovrà essere inoltre possibile inserire indicazioni speciali, da visualizzare all’accesso al widget, riguardanti ad esempio codici speciali di sconto o altre facilitazioni al trasporto o all’accesso. |
ID | Descrizione |
FUN.26 | Il sito web e il Travel Planner dovranno essere realizzati in modo da consentire un uso efficace e gradevole anche da smartphone e/o da tablet. |
ID | Descrizione |
SWR.3 | Il sito web dell’ecosistema di Muoversi in Toscana, incluso il Travel Planner, dovrà essere realizzato con tecnologia adeguata a permettere l’integrazione nel nuovo sito della Regione Toscana, attualmente in corso di dispiegamento. Preferibilmente, il sito web e il Travel Planner dovranno essere realizzati con tecnologie analoghe a quelle attualmente utilizzate. In ogni caso, il fornitore avrà a disposizione il codice sorgente dell’implementazione attuale. |
9
5.5 Realizzazione del software
ID | Descrizione |
SWR.4 | Il software del Back-end deve essere interamente realizzato utilizzando componenti open source. Il software delle due versioni della app per smartphone, per iOS e per Android, dovrebbe preferibilmente essere realizzato tramite componenti open source. Il software della componente web da integrare nel portale regionale deve essere interamente realizzato utilizzando componenti open source e di comprovata compatibilità con il portale di Regione Toscana. L’elenco completo e dettagliato delle componenti software che il fornitore intende utilizzare nell’ambito del servizio qui descritto dovrà essere incluso nell’offerta tecnica e tale elenco sarà oggetto di valutazione comparativa in fase di aggiudicazione. Successive modifiche e/o integrazioni di tale lista di componenti software saranno efficaci solo se comunicate in forma scritta ed esplicitamente approvate dal committente. L’utilizzo di componenti non open source dovrà essere esplicitamente indicato e debitamente motivato nell’offerta tecnica del fornitore. In ogni caso, i costi derivanti dall’utilizzo di componenti software di terze parti necessarie alla realizzazione e dispiegamento dell’ecosistema digitale di Muoversi in Toscana sarà a carico del fornitore. |
SWR.5 | Il software del Back-end dovrà essere idoneo al dispiegamento presso i sistemi gestiti da Fondazione Sistema Toscana. Il fornitore concorderà con Fondazione Sistema Toscana i requisiti dettagliati riguardanti hardware, software e rete per il dispiegamento effettivo. Fondazione Sistema Toscana metterà a disposizione del fornitore un’infrastruttura di staging locata presso i locali del TIX e accessibile da remoto, su cui verranno effettuati i dispiegamenti preliminari del software di Back-end. Successivamente, il trasferimento verso l’infrastruttura di produzione sarà effettuato dal personale incaricato da Fondazione Sistema Toscana, con la collaborazione del fornitore. |
SWR.6 | La realizzazione delle estensioni funzionali dell’ecosistema di Muoversi in Toscana sarà organizzata in due lotti principali, la cui composizione effettiva sarà concordata con il fornitore aggiudicatario nell’ambito della prima fase progettuale (si veda anche la sezione dedicata alla tempistica). |
5.6 Manutenzione correttiva
ID | Descrizione |
MNE.1 | Il servizio qui descritto include la manutenzione correttiva delle componenti software dell’ecosistema digitale di Muoversi in Toscana. |
ID | Descrizione |
Con manutenzione correttiva si intende la garanzia del corretto funzionamento del software e l’effettivo svolgimento delle funzioni previste, in base al codice sorgente, alla documentazione esistente e alla coerenza logica complessiva delle funzioni stesse per gli scopi intesi verso gli utilizzatori terzi. Sono invece esclusi dalla manutenzione correttiva gli adattamenti delle funzioni stesse a scopi diversi o ulteriori, al mutamento dovuto dal contesto applicativo, normativo o regolamentare, come sono escluse le estensioni di funzioni esistenti e l’introduzione di nuove funzioni. | |
MNE.2 | In base alla garanzia di manutenzione correttiva, il fornitore si impegna alla tempestiva presa in carico delle segnalazioni di malfunzionamenti da parte di Fondazione Sistema Toscana e alla loro eliminazione nel più breve tempo possibile. Il fornitore si impegna, inoltre, a dare tempestiva e completa informazione delle proprie attività e dello stato di avanzamento delle attività di correzione. Si intende che tutte le attività di manutenzione correttiva, dalla segnalazione all’effettiva correzione dei malfunzionamenti sono a carico del fornitore e incluse nel servizio richiesto. |
MNE.3 | La segnalazione dei malfunzionamenti avverrà utilizzando come strumento di riferimento un sistema web di issue tracking messo a disposizione da Fondazione Sistema Toscana. |
MNE.4 | A seguito della segnalazione del malfunzionamento, il fornitore si impegna ad effettuare le seguenti azioni: • (presa in carico) rispondere alla segnalazione e attivarsi nel più breve tempo possibile per l’identificazione del malfunzionamento e delle cause che lo hanno prodotto; • (risposta) eliminare le cause del malfunzionamento oppure rispondere indicando un piano d’azione dettagliato per l’eliminazione delle cause. Il piano d’azione dettagliato deve indicare chiaramente le azioni che il fornitore intende intraprendere, il risultato atteso e la scadenza entro la quale ciascuna azione sarà completata. Il piano d’azione può essere progressivamente esteso a seconda dei risultati delle azioni intraprese. Il piano d’azione e ciascuna successiva estensione devono essere approvati dal committente. |
MNE.5 | I criteri di massima per la classificazione dei malfunzionamenti e i relativi tempi massimi di presa in carico e per la risposta sono i seguenti: • Malfunzionamento bloccante: Malfunzionamento bloccante di un componente software che pregiudica una o più funzioni di servizio. Tempo di presa in carico: max 4 ore lavorative Tempo di risposta: max 8 ore lavorative • Malfunzionamento grave: Malfunzionamento potenzialmente bloccante su un componente software per cui esiste una soluzione temporanea. Tempo di presa in carico: max 8 ore lavorative Tempo di risposta: max 16 ore lavorative • Malfunzionamento: Malfunzionamento non bloccante e per cui esiste una soluzione temporanea. Tempo di presa in carico: max 16 ore lavorative Tempo di risposta: max 32 ore lavorative |
MNE.6 | Il fornitore si impegna, inoltre, a identificare e a proporre in modo proattivo eventuali accorgimenti, procedure o soluzioni software che possano migliorare |
10
ID | Descrizione |
l’affidabilità delle app e della componente web e l’identificazione anticipata dei malfunzionamenti o delle anomalie di funzionamento. |
11
5.7 Help desk e assistenza al personale addetto ai sistemi
ID | Descrizione |
MNE.7 | Per tutta la durata del servizio, il fornitore attiverà un servizio di Help Desk riservato al personale tecnico designato da Fondazione Sistema Toscana per la gestione operativa delle app e della componente web e in particolare come assistenza all’identificazione di malfunzionamenti e anomalie. Tale servizio di help desk dovrà prevedere come minimo: • un numero di telefono cellulare con garanzia di presidio durante il normale orario d’ufficio e a scopo di reperibilità dell’Help desk; • un indirizzo di mail per il contatto. |
MNE.8 | Per tutto il periodo del servizio, il fornitore si impegna a fornire piena assistenza al personale designato da Fondazione Sistema Toscana per la gestione dei sistemi hardware, software e di rete al per il corretto dispiegamento e configurazione delle app e della componente web e per la definizione di procedure per la scoperta delle anomalie di funzionamento. Tale assistenza deve includere come minimo: • la disponibilità per il contatto online (audio o testuale) secondo modalità da concordarsi per l’intera durata delle operazioni di dispiegamento del software o di aggiornamento dei sistemi; • nei casi urgenti o critici, la disponibilità alla presenza fisica del personale tecnico del fornitore presso la sede di Fondazione Sistema Toscana o il luogo di effettiva presenza dei sistemi, secondo modalità e limiti da concordarsi. |
5.8 Manutenzione adattativa ed estensiva
ID | Descrizione |
MNE.9 | Gli adattamenti e le estensioni delle componenti dell’ecosistema digitale di Muoversi in Toscana sono richiesti al fornitore in forma di realizzazione di software e documentazione in base alle specifiche tecniche approvate da Fondazione Sistema Toscana. Tali adattamenti ed estensioni sono intesi a coprire eventuali necessità che dovessero diventare note nel corso dell’esecuzione del servizio e non previste e quindi descritte nelle presenti specifiche tecniche. In altri termini, le attività di realizzazione di adattamenti ed estensioni qui descritte non sono in alcun modo incluse nelle attività descritte nelle sezioni precedenti e costituiscono quindi un ulteriore impegno del fornitore. Ciascuna realizzazione di software e documentazione deve essere trasferita a Fondazione Sistema Toscana nel rispetto dei requisiti sotto descritti relativi al trasferimento e alla licenza. In particolare, ciascuna realizzazione di software e documentazione verrà accettata da Fondazione Sistema Toscana previo collaudo effettuato con successo, secondo le modalità sotto descritte. |
ID | Descrizione |
All’atto della consegna e dell’accettazione, ciascuna realizzazione di software e documentazione diventerà parte integrante del software e della documentazione incluse nel servizio e come tale saranno soggetta alla manutenzione correttiva a carico del fornitore, per l’intera durata prevista del servizio. | |
MNE.10 | Per ciascun adattamento o estensione, verranno definite in forma collaborativa delle specifiche tecniche. Sulla base di tali specifiche, il fornitore valuta preventivamente l’effort necessario (vedi sotto) e la tempistica di realizzazione e consegna. L’approvazione delle specifiche tecniche, dei valori di effort e delle tempistiche compete a Fondazione Sistema Toscana. Qualsiasi successiva variazione delle specifiche tecniche, dei valori di effort e delle tempistiche è efficace solo se esplicitamente approvata da Fondazione Sistema Toscana. Resta inteso che, all’atto dell’approvazione, l’obbligo del fornitore nei confronti di Fondazione Sistema Toscana riguarderà la realizzazione completa e funzionante degli adattamenti ed estensioni così definite, inclusa la pubblicazione o il dispiegamento, con le modalità stabilite a seconda dei casi. |
MNE.11 | L’effort necessario da parte del fornitore per la realizzazione di ciascun adattamento o estensione viene misurato in giornate lavorative equivalenti per le diverse figure professionali coinvolte. Nel computo dell’effort necessario per la realizzazione di software e documentazione per la manutenzione adattativa ed estensiva il fornitore potrà inserire conteggiare solo le attività svolte dalle figure professionali sotto indicate. L’eventuale impiego di qualsiasi altra figura professionale sarà a carico del fornitore. Fondazione Sistema Toscana riconosce l’effort necessario al supporto per l’analisi e la progettazione tecnica delle funzioni estensive, purché esplicitamente indicato nel computo complessivo. |
MNE.12 | Per l’intera attività di manutenzione adattativa ed estensiva inclusa nel servizio il fornitore si impegna a mettere a disposizione un effort equivalente minimo di: • Esperto senior di tecnologia e analista funzionale: 40 giornate lavorative equivalenti; • Sviluppatore senior per il software di Back-end: 60 giornate lavorative equivalenti; • Sviluppatore senior di app per iOS e/o per Android: 80 giornate lavorative equivalenti; • Sviluppatore senior per il software web: 40 giornate lavorative equivalenti; • Senior designer per user experience di app e siti web: 40 giornate lavorative equivalenti. Resta comunque inteso che Fondazione Sistema Toscana si riserva di utilizzare effettivamente tale disponibilità del fornitore in base alle effettive necessità. |
12
13
5.9 Licenze software
ID | Descrizione |
TRA.1 | Il software e la documentazione comunque realizzati nell’ambito del servizio devono essere trasferiti alla Fondazione Sistema Toscana, completi di codice sorgente, con licenza d’uso generale non esclusiva, illimitata e irrevocabile. |
TRA.2 | Salvo diversa indicazione da parte della Fondazione Sistema Toscana, si intende che qualsiasi consegna di software e documentazione, anche intermedia, sarà costituita dalla forma binaria completa, direttamente installabile, e dal codice sorgente, completo in ogni sua parte. Per “completezza” del codice sorgente si intende la possibilità effettiva di ricostruire la forma binaria, utilizzando strumenti opportuni. Gli strumenti necessari alla ricostruzione delle forme binarie devono essere esplicitamente indicati e concordati con Fondazione Sistema Toscana. Il codice sorgente deve includere anche gli elementi necessari alla corretta configurazione degli strumenti stessi. Fanno inoltre parte del codice sorgente anche tutti gli elementi necessari per la corretta configurazione e predisposizione dell’ambiente di sviluppo e delle basi di dati coinvolte, inclusi gli schemi, la prima popolazione ed il trasferimento dei dati da altri sistemi, se necessario. |
TRA.3 | Dall’obbligo della consegna del codice sorgente, completo in ogni sua parte, sono escluse solo le componenti specifiche preventivamente approvate dalla Fondazione Sistema Toscana. |
5.10 Consegna e collaudo
ID | Descrizione |
TRA.4 | Per ciascuna realizzazione di software e documentazione, Fondazione Sistema Toscana definisce con il fornitore un test plan ovvero una modalità alternativa per l’effettuazione del collaudo. La responsabilità ultima per l’accettazione delle modalità di collaudo rimane della Fondazione. |
TRA.5 | Il collaudo di software e documentazione verrà effettuato dispiegando il software consegnato sui sistemi indicati dalla Fondazione Sistema Toscana. Il dispiegamento sarà effettuato dal personale della Fondazione. Il fornitore si impegna a fornire tutto il supporto necessario, nel luogo e ambiente indicato dalla Fondazione, per il dispiegamento e l’effettuazione del collaudo. Il collaudo verrà effettuato eseguendo il test plan ovvero la modalità prestabilita e l’esito sarà determinato confrontando i risultati attesi con i risultati effettivi. |
TRA.6 | A seguito del collaudo effettuato con successo, il sistema informativo interattivo verrà pubblicato o dispiegato sui sistemi di produzione indicati dalla Fondazione Sistema Toscana. Il dispiegamento sarà effettuato dal personale della Fondazione. Il fornitore si impegna a fornire tutto il supporto necessario, nel luogo e ambiente indicato per Fondazione, per il dispiegamento in produzione. |
Per la migliore ottimizzazione delle tempistiche e per un confronto, ad aggiudicazione avvenuta, sarà
organizzato un incontro preliminare tra l’operatore aggiudicante e FST.
14
6. Modalità di erogazione dei servizi
Al contratto di appalto si applicano le condizioni dettate nei documenti di gara: restano ferme le specifiche tecniche come definite dalla lex specialis (dunque, nel presente Capitolato Tecnico Prestazionale) e come fissati dalla misura dell’offerta dell'Aggiudicatario.
La completa esecuzione nei termini indicati, costituisce prestazione essenziale ai fini dell'esatto adempimento. Eventuali ritardi nell’esecuzione delle prestazioni oggetto dell’appalto devono essere giustificati da comprovati motivi di forza maggiore e comunque concordati con la Committente, a pena di applicazione delle penali contrattuali.
Il Direttore dell'esecuzione del Contratto controlla e supervisiona le attività richieste nel presente appalto. Il Direttore dell'esecuzione del Contratto può, per i compiti di verifica e coordinamento, delegare il personale interno di FST o professionisti comunque affidatari di incarichi conferiti da FST. L’Esecutore deve attenersi alle indicazioni fornite dal Direttore dell'esecuzione del Contratto (o dal personale da quest’ultimo delegato). La mancata osservanza di tali indicazioni, nella realizzazione degli interventi, da parte dell’Esecutore costituisce inadempimento e genera la relativa responsabilità.
Le attività seguiranno un calendario concordato con il Direttore dell'esecuzione del Contratto; i SAL (i documenti di stato avanzamento lavori), quale strumento ulteriore di monitoraggio del servizio svolto da parte dell’Aggiudicatario, verranno valutati e validati dal Direttore dell'esecuzione del Contratto. A questo punto l’Aggiudicatario è autorizzato a emettere la fattura corrispondente.
Al completamento del servizio, dovrà essere prodotta una Relazione di fine lavori, che dovrà essere valutata e validata da parte del Direttore dell'esecuzione del Contratto, che in seguito all’esito positivo del controllo produrrà il Certificato di regolare esecuzione.
Il Certificato di regolare esecuzione, munito delle sottoscrizioni dell’Esecutore e del Committente, autorizza l’Aggiudicatario a produrre la fattura a saldo ed è condizione per l’ammissione alla liquidazione del relativo corrispettivo.
7. Obblighi dell’Esecutore
L'aggiudicatario, ai sensi dell'art.24 della L. R. Toscana n.38/07, ha l'obbligo di informare immediatamente la stazione appaltante di qualsiasi atto di intimidazione commesso nei suoi confronti nel corso del contratto con la finalità di condizionarne la regolare e corretta esecuzione.
L'impresa si impegna a seguire con attenzione quanto previsto, le indicazioni delle specifiche tecniche incluse nel presente documento di gara, cosciente delle penali previste per inadempienza. Inoltre, per tutta la durata del contratto, l'impresa si impegna a fornire alla FST un referente e i suoi recapiti telefonici mobili e di posta elettronica, per le comunicazioni di servizio.
Per accettazione
Luogo, data