Sistema Pubblico di Connettività - Lotto 4
Sistema Pubblico di Connettività - Lotto 4
Comune di Firenze
ReteCivica Comune di Firenze SitiTematici PROGETTO DEI FABBISOGNI
Servizi di realizzazione e gestione di Portali e Servizi on-line
SOMMARIO
3
2 ORGANIZZAZIONE DEL CONTRATTO ESECUTIVO
5
7
3.1 Progettazione, Sviluppo, MEV e Rifacimento di portali, siti e applicazioni web [L4.S1.2.a] 8
3.1.1 Sviluppo componenti custom 9
3.2 Manutenzione Adeguativa di siti web, portali, applicazioni web [L4.S5.2] 10
3.3 Conduzione Applicativa [L4.S6] 10
3.3.1 Modalità di erogazione del servizio 11
3.3.2 Livelli di servizio (SLA) e penali 11
3.3.4 Interfacce Web accessibili 13
3.4 Quadro riassuntivo dei servizi 13
3.5 Impegno delle risorse professionali 13
3.7 Modalità di consegna del codice 14
3.8 Modalità di esecuzione del collaudo dei servizi 15
4 MODALITÀ DI PRESENTAZIONE E APPROVAZIONE DEGLI STATI DI AVANZAMENTO MENSILI
16
4.1 Gestione dei SAL Mensili 16
4.2 Report di Stato di Avanzamento Mensile 16
18
5.2 Gestione della Sicurezza 18
19
Obiettivo del Comune di Firenze è lo sviluppo, la MEV e l’Assistenza per la Rete Civica del Comune di Firenze (xxxxx://xxx.xxxxxx.xx.xx), dei siti tematici verticali ad essa correlati. Inoltre l’Amministrazione si avvale della possibilità di richiedere lo sviluppo di nuovi servizi e applicazioni digitali di nuovi siti tematici da inserire nella rete civica.
◼ A questo scopo si fornisce una sintetica descrizione delle attività richieste:
◼ Sviluppi e manutenzione evolutiva per la rete civica e siti tematici verticali, sempre su Drupal 7/8 per un pacchetto di almeno 130 giornate/uomo
◼ Manutenzione ordinaria, bug fixing, assistenza con SLA pre-determinati e tempi di intervento critici per la Rete Civica del Comune di Firenze e siti tematici correlati (CMS Drupal 7 e 8 e OpenCMS):
o l’attività copre sia i template Drupal, sia il sistema Drupal stesso, che è in cluster, sia il sistema
OpenCMS, anch’esso in cluster
◼ Presidio accessibilità e introduzione patch eventualmente necessarie ai sensi normativa vigente
Scopo del documento è documentare e quantificare i servizi richiesti dall’Amministrazione. Si compone di:
◼ Progetto di Attuazione
◼ Modalità di presentazione e approvazione degli stati di avanzamento mensili
◼ Piano di Attuazione.
Il documento si applica al progetto SPC lotto 4. In particolare, ai seguenti servizi:
◼ Progettazione, Sviluppo, Mev e rifacimento di portali, siti web e applicazioni web
◼ Manutenzione correttiva/adeguativa siti web, portali e applicazioni web
◼ Supporto Specialistico
◼ Conduzione applicativa
Non applicabile.
Identificativo | Titolo/Descrizione |
Contratto Quadro del 04/08/2017 e relativi Allegati | Contratto Quadro relativo all’Appalto dei servizi di realizzazione e gestione di Portali e Servizi on-line (lotto 4) in favore delle PA. |
Allegato 5A alla lettera d’invito | Capitolato Tecnico Parte Generale |
Allegato 5B alla lettera d’invito | Capitolato Tecnico Lotto 4 |
Definizione / Acronimo | Descrizione |
AgID | Agenzia per l’Italia Digitale |
Consip | Consip S.p.a. |
RTI | Raggruppamento Temporaneo d’Impresa |
SPC | Sistema Pubblico di Connettività |
2 ORGANIZZAZIONE DEL CONTRATTO ESECUTIVO
Il RTI si avvale di un modello organizzativo di cooperazione, che ha come obiettivo quello di soddisfare le richieste di cooperazione delle Amministrazioni in maniera coordinata ed integrata sia a livello di singolo Contratto Esecutivo sia a livello di Contratto Quadro.
Per il Contratto Esecutivo si identificano:
◼ il Responsabile del Contratto Esecutivo: Xxxxxx Xxxxxxxxxx;
◼ il Responsabile delle funzioni di Project e Risk Management e di Quality Management specifiche per il CE: Xxxxxxx Xxxxxxx.
La figura seguente rappresenta l’organizzazione prevista per l’esecuzione del contratto.
Portale Web e Servizi
La tabella seguente riporta i nominativi/ruoli dell’organizzazione previsti per i servizi contrattuali erogati.
Ruolo | Nome | Cognome | Riferimenti |
Responsabile Centro Servizi | Xxxxxxxx | Xxxxxx | |
Responsabile Sviluppo | Xxxxxxx | Xxxxxxx | |
Responsabile Manutenzione | Xxxxxxx | Xxxxxxx | |
Responsabile Conduzione | Xxxxxxx | Xxxxxxx | |
Responsabile Supporto Specialistico | Xxxxxxx | Xxxxxxx |
Dalle esigenze espresse nel Piano dei fabbisogni è stato possibile definire specifici progetti realizzabili attraverso i servizi del Lotto 4
I paragrafi che seguono riportano una breve sintesi degli interventi progettuali approfonditamente descritti nel piano dei fabbisogni, e, per ognuno di essi, le stime dimensionali/economiche articolate secondo le modalità di erogazione dei servizi previste contrattualmente per il Lotto 4.
A seguito del rilascio dei requisiti definitivi da parte dell'amministrazione, i dimensionamenti dei vari
interventi potranno essere rimodulati in corso d’opera nel rispetto del massimale indicato.
L’Amministrazione comunale della città di Firenze ha la necessità di affidare gli sviluppi, la MEV e l’assistenza
applicativa della Rete Civica fiorentina e dei siti tematici correlati. A tale scopo sono richieste le seguenti attività:
◼ Sviluppi e manutenzione evolutiva per la Rete Civica e i siti tematici verticali basati su CMS Drupal. Il
supporto comprende anche i servizi infrastrutturali utilizzati da Drupal e dettagliati nel paragrafo successivo.
◼ Manutenzione ordinaria, bug fixing, assistenza con SLA predeterminati e tempi di intervento critici (di seguito dettagliati) per la Rete Civica del Comune di Firenze e siti tematici correlati basati su CMS Drupal e OpenCMS. L’attività copre sia i siti web, sia l’infrastruttura Drupal che quella OpenCMS.
◼ Sicurezza: Produzione di un report, con elenco dettagliato dei risultati e delle azioni svolte o da svolgere per porre rimedio ad eventuali anomalie rilevate, relativamente a:
o verifica periodica (annuale o semestrale) del rispetto dei requisiti minimi di sicurezza ai sensi della normativa vigente sul GDPR fino al livello applicativo (il livello sistemistico è gestito in modo autonomo dal Comune di Firenze) dei siti web e dell’infrastruttura Drupal e OpenCMS(in graduale dismissione)
o verifica periodica (annuale o semestrale) relativamente a vulnerabilità del codice, mediante
l’utilizzo di appositi strumenti (es.: OWASP ZAP) dei siti web
o verifica periodica (annuale o semestrale) relativamente a test di carico sull’infrastruttura, mediante l’utilizzo di appositi strumenti (es.: JMETER) dei siti web e dell’infrastruttura Drupal/OpenCMS.
◼ Accessibilità. Verifica periodica (annuale) sul rispetto da parte di tutti i siti web dei requisiti richiesti dalla normativa vigente sull’accessibilità e dalle linee guida del Comune di Firenze (Allegato 1). L’attività comprende anche la pubblicazione, entro il 31/3 di ogni anno, degli obiettivi di accessibilità per l’anno in corso e la rendicontazione degli obiettivi accessibilità dell’anno precedente.
Nella tabella che segue è riportato un mapping fra intervento progettuale e il servizio del Lotto 4 associato.
L4.S1 | L4.S2 | L4.S3 | L4.S4 | L4.S5 | L4.S6 | L4.S7 | ||
Nome servizio | Progettazione, Sviluppo, Mev e Rifacimento di APP | Content Management | Gestione Operativa | Manutenzione Correttiva/Adeguativa | Conduzione Applicativa | Supporto Specialistico | ||
1 | Sviluppo e MEV | X | ||||||
2 | MAD | X | ||||||
3 | Conduzione Applicativa | X | ||||||
4 | Supporto Specialistico | X | ||||||
L’orizzonte temporale di dispiegamento dei servizi richiesti dal Comune di Firenze è di 18 mesi a partire dalla data di attivazione dei servizi previsti nel contratto SPC Lotto 4.
Di seguito, il dettaglio dei servizi e degli sviluppi inquadrati nelle tipologie previste nel contratto SPC Lotto 4.
3.1 Progettazione, Sviluppo, MEV e Rifacimento di portali, siti e applicazioni web [L4.S1.2.a]
Al nascere di nuove esigenze, da parte dell’amministrazione comunale fiorentina, come:
◼ Sviluppo di nuovi siti tematici
◼ Migrazione su Drupal da altri CMS di siti esistenti, tra i quali il nuovo portale degli OpenData di Firenze
◼ Manutenzione evolutiva di quanto già attivo
si dovrà prevedere un team che possa implementare quanto richiesto su CMS Drupal.
Allo stato attuale, le versioni utilizzate dal comune di Firenze sono la 7.x e la 8.x. Nel corso del biennio 2018- 2019, si prevede l’adozione delle versioni di Drupal che diverranno nel tempo le versioni di riferimento, a partire dalla successiva 9.x. Il fornitore dovrà pertanto adeguare il proprio know-how in modo tale da poter rispondere alle esigenze che nel periodo contrattuale andrà di pari passo con le evoluzioni del CMS Drupal.
Sono da prevedere all’incirca un impegno di 130 gg/uomo.
L’utilizzo di queste giornate può avvenire in due modalità:
• Richiesta: Comune di Firenze e fornitore definiscono l’esigenza, il fornitore fa una stima delle giornate che
prevede siano necessarie per soddisfare tale esigenza e, una volta che il Committente approva il preventivo
di giornate il fornitore sviluppa quanto richiesto e consegna al Committente il prodotto realizzato con le modalità indicate più avanti.
• Training on the job: Comune di Firenze e fornitore definiscono l’esigenza e stabiliscono un numero di giornate durante le quali il fornitore affiancherà con una o più figure da Lui individuate i tecnici del comune di Firenze affinché questi abbiano gli strumenti per poter soddisfare l’esigenza in autonomia
Di seguito quanto previsto per le attività di sviluppo e MEV:
• Sviluppo di componenti custom1 o MEV di componenti custom esistenti. L’esigenza può scaturire dalla necessità di specifiche funzionalità necessarie all’Amministrazione ma non previste dalle componenti core o contrib2 di Drupal, oppure dal bisogno di ovviare a malfunzionamenti delle componenti core o contrib utilizzate.
• Progettazione Grafica di nuovi siti web o di revisioni di siti web esistenti, in accordo con quanto previsto dalle linee guida Agid per il design dei siti web dalla PA (xxxxx://xxxxxxxxx.xxxxxx.xx/) e in linea con le esigenze del comune di Firenze. La progettazione deve essere condotta mediante l’uso di opportuni strumenti di lavoro e corredata da semi lavorati quali ad esempio wireframe o mokup,
indispensabile per l’ottenimento del prodotto finale, ovvero una versione HTML completa e auto consistente del progetto.
• Aggiornamenti di sicurezza relativi a:
o core di Drupal
o componenti contrib
o componenti custom
• Aggiornamenti e tuning relativi a:
o tuning e aggiornamenti del servizio Unison utilizzato per allineare i diversi file system del sistema in cluster, di seguito meglio dettagliato
o tuning e aggiornamenti dei DB server
o tuning e aggiornamenti di Drush
3.1.1 Sviluppo componenti custom
Sviluppo di componenti custom o MEV di componenti custom esistenti. L’esigenza può scaturire dalla necessità di specifiche funzionalità necessarie all’Amministrazione ma non previste dalle componenti core o contrib di Drupal, oppure dal bisogno di ovviare a malfunzionamenti delle componenti core o contrib utilizzate.
L’Amministrazione potrà richiedere la progettazione Grafica di nuovi siti web o di revisioni di siti web esistenti, in accordo con quanto previsto dalle linee guida Agid per il design dei siti web dalla PA (xxxxx://xxxxxxxxx.xxxxxx.xx/) e in linea con le esigenze del comune di Firenze. La progettazione deve essere condotta mediante l’uso di opportuni strumenti di lavoro e corredata da semi lavorati quali ad esempio wireframe o mockup, indispensabile per l’ottenimento del prodotto finale, ovvero una versione HTML completa e auto consistente del progetto.
1 Col termine componente custom si intende una componente software realizzata dal comune di Firenze e integrata con la propria infrastruttura Drupal, come moduli (es.: modules/custom/firenze_homepage, modules/custom/firenze_contest, ecc.), temi (es.: themes/firenze), librerie, profili (es.: profiles/firenze_base_profile), ecc.
2 Col termine componente contrib si fa riferimento ad una componente software distribuita dalla comunità Drupal come ad esempio moduli, temi o librerie..
3.2 Manutenzione Adeguativa di siti web, portali, applicazioni web [L4.S5.2]
I servizi di Manutenzione correttiva ed adeguativa hanno come riferimento le modalità di fornitura così come specificate da AgID ed includono tutte le seguenti attività:
◼ la manutenzione correttiva, che comprende la diagnosi e la rimozione delle cause e degli effetti delle malfunzionamenti evinti dalle segnalazioni;
◼ la manutenzione adeguativa, che comprende l’attività di manutenzione volta ad assicurare la costante
aderenza delle procedure al cambiamento dei requisiti siano essi organizzativi o normativi.
Gli obiettivi della fornitura sono così definiti:
◼ mantenere operativa la soluzione (software) attraverso attività che assicurino in via continuativa la rimozione dei malfunzionamenti;
◼ assicurare il miglioramento tempestivo delle funzionalità e delle prestazioni, per esempio quando un programma non ha prestazioni adeguate al livello di servizio richiesto e ciò viene percepito come un malfunzionamento, richiedendo un intervento correttivo;
◼ garantire l’evoluzione tecnico funzionale della soluzione software;
le modalità di attivazione della Manutenzione correttiva ed adeguativa sono descritte nel paragrafo 3.3. I sistemi oggetto di manutenzione correttiva e adeguativa e della correlata conduzione applicativa sono:
- sistema Drupal già descritto nei paragrafi precedenti (a partire dalla stipula del contratto e fino a fine fornitura)
- sistema OpenCMS in cluster, costituito da: pagine residuali della Rete Civica del Comune di Firenze versione italiano e inglese, tutti i siti tematici correlati non ancora migrati su Drupal, e intranet
comunale per la parte pubblicata tramite i sistemi OpenCms dispiegati sull’infrastruttura comunale
(Allegato2 - Infrastruttura_OpenCms)
- l’infrastruttura OpenCms è in graduale dismissione via via che i vari siti tematici vengono migrati sul sistema Drupal. Si prevede quindi un’attività di manutenzione correttiva più importante per il 2019e via via in misura sempre minore (fino a fine fornitura)
3.3 Conduzione Applicativa [L4.S6]
A seguito di segnalazione di malfunzionamento, il team di lavoro prenderà in carico la stessa e valuterà se trattasi di MALFUNZIONAMENTO (Correttiva-bug fixing) e/o di EVOLUTIVA.
Tutte le segnalazioni inerenti l’indisponibilità totale e/o parziale della Rete Civica o di un qualsiasi sito tematico, in ambiente Drupal/OpenCMS, dovranno essere tracciate come di MALFUNZIONAMENTO e rientreranno nelle attività di Manutenzione Correttiva e/o Adeguativa suddetta.
Sono definiti interventi con carattere di urgenza tutti i malfunzionamenti che generano indisponibilità parziale e/o totale di contenuti sottoposti ad obbligo di pubblicazione dalla normativa vigente, quali la sezione trasparenza, bandi di gara e avvisi, profilo del committente, concorsi, comunicati stampa.
Per indisponibilità totale si intende l’impossibilità di raggiungere un sito web, o anche la sola home page: in
questo caso la richiesta d’intervento viene definita urgenza.
Per indisponibilità parziale si intende l’impossibilità di recuperare correttamente tutti i contenuti di una determinata URL, su almeno uno dei seguenti browser:
• Firefox
• Chrome
• Safari
• Internet Explorer
in questo caso la richiesta d’intervento viene definita anomalia.
Tutte le segnalazioni vengono inserite dal Committente o da persona da lui assegnata nel sistema di ticketing Mantis del Comune di Firenze.
Le segnalazioni di carattere EVOLUTIVA (Change Request o New Request) seguiranno le linee guida definite nel paragrafo 3.1.
Il servizio comprende l’assistenza on site e remota (telefonica, teleassistenza, …) da parte di personale tecnico
specializzato per:
◼ La presa in carico delle segnalazioni nei tempi definiti dagli SLA concordati con l’amministrazione
◼ L’analisi di primo livello per la categorizzazione della segnalazione
◼ Inoltro della problematica al Capo Progetto del fornitore per la definizione delle modalità di trattamento della segnalazione e delle tempistiche di attuazione nel caso si tratti di MEV.
3.3.1 Modalità di erogazione del servizio
Per far fronte ai fabbisogni dell’Amministrazione committente l’RTI garantisce un presidio giornaliero durante le ore lavorative (Lunedì - Venerdì con orario 8:00 - 18:00) e reperibilità il Sabato con orario 8:00-13:00.
3.3.2 Livelli di servizio (SLA) e penali
La tipologia entro cui far ricadere la singola RI (Richiesta Intervento), secondo quanto sopra descritto, viene definita in fase di presa in carico della segnalazione e secondo le regole su definite.
Una RI viene definita di tipo URGENZA quando vi è una segnalazione di impossibilità di raggiungere un sito web, o anche la sola home page.
Una RI viene definita di tipo ANOMALIA quando vi è una segnalazione di indisponibilità parziale , cioè
l’impossibilità di recuperare correttamente tutti i contenuti di una determinata URL, su almeno uno dei seguenti browser:
• Firefox
• Chrome
• Safari
• Internet Explorer
Di seguito una tabella che descrive nel dettaglio le tempistiche e relative penali se non rispettate, per le due tipologie di intervento:
SLA di riferimento | Valore atteso | Penale: Causale | Penale: Importo |
SLA1: Rispetto tempi di risposta per RI di tipo urgenza | Il Fornitore risponderà ad una RI di tipo urgenza entro 1 ora dall’orario della richiesta, prendendo in carico la segnalazione con almeno una e-mail di risposta. | Per ogni ora lavorativa di ritardo nella risposta con presa in carico della segnalazione, calcolata entro la finestra di erogazione del servizio. | 2 per mille dell'importo complessivo IV A esclusa della fornitura |
SLA2: Rispetto tempi di ripristino per RI di tipo urgenza | Il Fornitore ripristinerà il servizio fornendo almeno una patch (soluzione temporanea che ripristini anche in minima parte il servizio interrotto) entro 6 ore lavorative dal momento della risposta alla RI (con la e-mail di risposta di cui sopra), salvo diverse valutazioni concordate col Referente del Comune di Firenze. | Per ogni ora lavorativa di ritardo nel ripristino del servizio con almeno una patch, calcolata entro la finestra di erogazione del servizio. | 2 per mille dell'importo complessivo IVA esclusa della fornitura |
SLA3: Rispetto tempi di risposta per RI di tipo anomalia | Il Fornitore risponderà ad una RI di tipo anomalia correttiva per errore non bloccante entro 2 giorni lavorativi dalla RI, con una e-mail al Referente del Comune di Firenze di presa incarico. | Per ogni giorno lavorativo di ritardo nella risposta, calcolato entro la finestra di erogazione del servizio. | 1 per mille dell'importo complessivo IVA esclusa della fornitura |
SLA4: Rispetto tempi di ripristino per RI di tipo anomalia | Il Fornitore ripristinerà il servizio fornendo un patch correttiva entro 4 giorni lavorativi dal tempo di risposta alla RI, salvo diverse valutazioni concordate col Referente del Comune di Firenze. | Per ogni giorno lavorativo di ritardo nel ripristino del servizio, calcolato entro la finestra di erogazione. | 1 per mille dell'importo complessivo IVA esclusa della fornitura |
Le RI di carattere Evolutivo verranno concordate nelle modalità di erogazione e dei tempi con il committente. Le penali si intendono salvo risarcimento di maggior danno da concordare fra le parti o da stabilire mediante
ricorso all’autorità giudiziaria presso il tribunale competente.
Vista la complessità e numerosità dei sistemi che l’RTI dovrà prendere in carico, al fine di garantire un adeguato delle attività, il Committente esonera l’RTI dall’applicazione delle penali per due mesi solari dall’attivazione del contratto.
R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Advisory S.p.A
Sistema Pubblico di Connettività LOTTO 4
SPCL4-Comune di Firenze ReteCivica_SitiTematici-ProgettoFabbisogni-1.0
L’RTI assicura al Committente l’individuazione in fase di progettazione degli interventi degli standard tecnologici, delle architetture di riferimento.
In fase di implementazione degli applicativi negli ambienti di sviluppo e produzione saranno utilizzati i principali standard di mercato.
3.3.4 Interfacce Web accessibili
L’RTI assicura al Committente l’effettivo rispetto dei requisiti di accessibilità secondo la normativa Italiana
riguardante la produzione di codice Web.
Per la del rispetto di tali requisiti si utilizzeranno gli strumenti e le procedure di controllo in base alla normativa vigente3.
3.4 Quadro riassuntivo dei servizi
Di seguito si riporta il dimensionamento complessivo di tutti i servizi proposti nel presente progetto dei
fabbisogni. L’importo è da considerarsi IVA esclusa.
Cod. Servizio | Descrizione | Modalità di esecuzione | Modalità di Pricing | Prezzo unitario € | I ANNO (2018) | II ANNO (2019) | TOTALE | ||||||
N. MESI | Q.TA' | IMPORTO € | N. MESI | Q.TA' | IMPORTO € | N. MESI | Q.TA' | IMPORTO € | |||||
L4_S1 | Progettazione, sviluppo, Mev e rifacimento di portali, siti web e | progettuale | A Corpo | 189,85 | - | 60 | 11.391,00 | - | 52 | 9.872,20 | - | 112 | 21.263,20 |
L4_S5 | Manutenzione correttiva/adeguativa di | continuativa | Canone | 188,84 | 4 | 14 | 10.575,04 | 12 | 10 | 22.660,80 | 16 | 24 | 33.235,84 |
L4_S6 | Conduzione Applicativa | continuativa | Canone Mensile | 189,64 | 4 | 13 | 9.861,28 | 12 | 11 | 25.032,48 | 16 | 24 | 34.893,76 |
Totale | 31.827,32 | 57.565,48 | 89.392,80 | ||||||||||
3.5 Impegno delle risorse professionali
Il mix delle risorse professionali impegnate nelle attività, sarà quello previsto nel Contratto Quadro. Potrà variare a seguito di una specifica richiesta da parte dell’Amministrazione.
Il centro servizi del RTI può essere considerato a tutti gli effetti un Data Center “virtuale” ed è costituito dalle
sedi che le aziende del RTI hanno attivato per la erogazione di tutti i servizi previsti dal progetto SPC.
Il Centro Servizi è organizzato su 4 sedi (cfr. tabella seguente) dislocate sul territorio italiano: tre della mandataria Almaviva che ospitano sia il personale sia l’infrastruttura dedicata alle Amministrazioni contraenti, una di Xxxxx che prevede la presenza del solo personale.
Sede | Azienda RTI | Data Center | Indirizzo | Mq totali |
Casal Boccone | Almaviva | √ | Xxx xx Xxxxx Xxxxxxx 000/000 - Xxxx | 34.800 |
3 “Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici” riferibili al Decreto Ministeriale 8 luglio 2005, di cui l'Allegato A (aggiornato dal DM 20 marzo 2013 --‐ GU Serie Generale n. 217 del 16/9/2013) riporta i “Criteri e metodi per la verifica tecnica e requisiti tecnici di accessibilità previsti dalla legge 9 gennaio 2004, n. 4.”
Sede | Azienda RTI | Data Center | Indirizzo | Mq totali |
Scalo Prenestino | Almaviva | √ | Xxx xxxxx Xxxxx Xxxxxxxxxx 00 - Xxxx | 11.200 |
Missaglia | Almaviva | √ | Xxx Xxxxxxxxx 00 - Xxxxxx | 10.800 |
Xxxx | Xxxxx | Xxx Xxxxxxx Xxxx 00 - Xxxx | 2.600 |
I servizi oggetto del presente Progetto saranno erogati secondo le modalità previste dal Contratto Quadro.
Saranno inoltre erogati dal Centro Servizi i servizi trasversali a supporto del quadro contrattuale e di seguito elencati:
◼ SLA Management per il controllo e monitoraggio dei livelli di Servizio
◼ Portale di Governo della Fornitura
◼ Help Desk (assistenza sugli aspetti tecnici e amministrativi relativi al CQ e ai CE).
L’infrastruttura di Help Desk sarà ospitata nel Centro Servizi.
3.7 Modalità di consegna del codice
La consegna del codice deve avvenire tramite collegamento VPN sull’ambiente demo (drupaldemo.comune.intranet), qualsiasi sia l’istanza Drupal interessata, attraverso lo strumento di controllo di versione del codice Git.
L’infrastruttura Drupal del comune di Firenze è costituita da tre ambienti/istanze di riferimento:
• Demo. È l’ambiente di riferimento per il fornitore, sul quale deve dispiegare e testare le proprie consegne.
• Staging. È l’ambiente di pre-produzione, analogo in tutto e per tutto all’ambiente di produzione dal punto di vista del dispiegamento, ovvero dell’HW (virtuale) e delle versioni di tutte le componenti SW extra Drupal (OS, Apache, PHP, DB server, Git client, Drush).
• Produzione.
Per ogni istanza Drupal esiste un corrispondente progetto Git (es.: drupal7.git e drupal8.git), scaricabili dal git server dell’Ente e visionabili all’indirizzo xxxx://xxxxxxxxx.xxxxxx.xxxxxxx/xxxxxx. Ogni progetto prevede tre distinti rami (branch), ovvero uno per ogni ambiente di riferimento:
• demo => ambiente demo
• staging => ambiente di staging
• master => ambiente di produzione
le consegne devono essere effettuate sul ramo demo del corrispondente progetto Git (a seconda del sito web)
e testate dal fornitore sull’ambiente demo per una prima verifica sui sistemi dell’Ente del codice consegnato.
Per la consegna delle configurazioni, ovvero le modifiche riportate all’interno del DB di ogni singolo progetto, per i casi in cui Drupal metta a disposizione strumenti efficaci e funzionanti (es.: Drupal 8), queste devono essere preventivamente esportate su file system sotto forma di codice e trasmesse sui sistemi dell’Ente con le stesse
modalità sopra descritte (Git). È cura del fornitore importare le configurazioni consegnate sull’ambiente demo dell’istanza di riferimento e verificarne l’effettivo funzionamento su tale ambiente.
3.8 Modalità di esecuzione del collaudo dei servizi
I servizi oggetto del presente Progetto dei fabbisogni saranno sottoposti ad un collaudo “sul campo” da parte di RTI, che eseguirà i test previsti ed esposti dal RTI nel documento "Specifiche di dettaglio delle prove di collaudo” ed ogni altro test che riterrà opportuno.
Al termine delle attività di collaudo verrà redatto un apposito Verbale contenente il dettaglio di quanto effettuato e gli esiti.
Sarà responsabilità del RTI fornire sia il personale che tutta la documentazione necessaria alla esecuzione del collaudo
4 MODALITÀ DI PRESENTAZIONE E APPROVAZIONE DEGLI STATI DI AVANZAMENTO MENSILI
Gli stati di avanzamento mensili costituiscono lo strumento mediante il quale il RTI tiene informata l’Amministrazione su tutte le attività che costituiscono il provisioning dei servizi da erogare (dal sopralluogo fino al collaudo finale e la relativa migrazione) e, successivamente, sullo stato di funzionamento e la qualità dei servizi stessi.
A tale scopo il Fornitore ed il RTI attivano un servizio di project management consistente nella pianificazione, gestione e verifica delle attività mirate al completamento del progetto.
Il project manager del Fornitore si confronterà con il responsabile di progetto nominato dall’Amministrazione
per la definizione ed esecuzione delle attività.
I report saranno prodotti con cadenza mensile e consegnati all’Amministrazione secondo una modalità di
comunicazione definita tra RTI ed Amministrazione.
4.2 Report di Stato di Avanzamento Mensile
Per quanto concerne le attività legate all'implementazione dei servizi, il flusso comunicativo può essere sintetizzato come segue:
◼ il project manager del RTI invia, mediante E-mail, il report SAL all’Amministrazione;
◼ l’Amministrazione, nella persona del suo responsabile di progetto, analizza, congiuntamente con il project manager del fornitore, la situazione di avanzamento, le eventuali modifiche rispetto al piano operativo previsto e le contromisure che il fornitore intende mettere in atto per recuperare gli eventuali ritardi verificatisi.
◼ Il responsabile dell’Amministrazione approva il report mediante comunicazione e-mail verso il fornitore.
Il report di Stato di Avanzamento Mensile contiene le seguenti informazioni:
◼ Avanzamento/Rispetto dei tempi previsti nel piano di attivazione;
◼ Eventuali modifiche alla pianificazione
◼ Esito Tracking sui rischi;
◼ Esito dei test interni;
◼ Esito collaudi effettuati (con XxXX e/o con l’amministrazione stessa);
◼ Changes emersi nel periodo; Xxxxxx correttive/preventive applicate;
◼ Varie ed eventuali.
Tutti gli stati di avanzamento sono soggetti ad approvazione da parte dell’Amministrazione.
Nella fase di erogazione dei servizi il RTI manterrà la produzione mensile del SAL, orientati più a definire
l’andamento della erogazione, in termini di:
◼ Indicazioni su possibili problemi o anomalie eventualmente verificatisi;
◼ Proposte di modifiche/aggiornamenti da apportare;
◼ Proposte eventuali ottimizzazioni/migliorie da apportare all’organizzazione dei processi definiti;
◼ Varie ed eventuali.
Il piano di lavoro si sviluppa secondo quanto riportato nello schema seguente:
Xxxx | |||
Cod. Servizio | Descrizione | 2018 | 2019 |
L4_S1.1 | Progettazione, sviluppo, Mev e rifacimento di portali, siti web e applicazioni web | A Richiesta | |
L4_S5 | Manutenzione correttiva/adeguativa di siti web, portali e applicazioni web | A Canone | |
L4_S6 | Conduzione Applicativa | A Canone | |
Il documento SPCL4-SEC-Documento Programmatico sulla Sicurezza (DPS)-1.0.docx è il riferimento alle politiche di sicurezza implementate dal fornitore per SPC lotto 4.
Relativamente agli specifici progetti sviluppati nell’ambito dei servizi richiesti dall’Agenzia, sarà implementato nel progetto il profilo di sicurezza per la riservatezza dei dati nonché le misure per soddisfarlo.
Il documento SPCL4-GEN-PianoQualitaGenerale-2.0.docx è il piano di qualità di riferimento per il presente progetto.
La data stimata di attivazione dei servizi contrattuali è il 3 settembre 2018.
Per la data effettiva si rimanda al relativo verbale di attivazione dei servizi firmato dall’Amministrazione e dal
Fornitore.