Capitolato Tecnico
Capitolato Tecnico
Procedura negoziata ai sensi dell’art. 36 comma 2 lett. b) del D. Lgs. 50/2016, con il criterio di selezione dell’offerta economicamente più vantaggiosa, tramite l’utilizzo del mercato elettronico, per per servizi di sviluppo software secondo il modello di sviluppo in open source e open-governance, da effettuarsi nell’ambito dei progetti previsti nel portale Developers Italia - LINGUAGGIO PYTHON CIG: 7965485E27
1. Definizioni e acronimi 2
2. Premessa 2
3. Contesto di riferimento 2
3.1. Contesto tecnologico 2
3.2. Contesto organizzativo 3
4. Definizione della fornitura 3
4.1. Oggetto della fornitura 3
4.2. Tecnologie impiegate 3
4.3. Dimensionamento della fornitura 4
4.4. Termini di esecuzione dei servizi 4
5. Modalità di esecuzione dell’appalto 4
5.1. Risorse di sviluppo impiegate 4
5.2. Responsabile del contratto 5
5.3. Assegnazione dei task 6
5.4. Modalità di erogazione dei servizi di sviluppo 6
5.4.1. Modalità generali 6
5.4.2. Contribuzione a progetti open source esistenti 7
5.4.3. Creazione di nuovi progetti open source 7
5.4.4. Mantenimento di progetti open source 8
5.5. Luogo di esecuzione delle attività 8
1. Definizioni e acronimi
Nel presente Capitolato Tecnico, i termini di seguito definiti hanno il seguente significato:
TD o Team Digitale: Il Team per la Trasformazione Digitale è la struttura di supporto del Commissario straordinario per l'attuazione dell'Agenda digitale, con funzioni di coordinamento e direzione centrali della trasformazione digitale del Paese. Svolge la funzione di stazione appaltante per questa gara.
IA o Impresa Aggiudicataria: l’operatore economico risultante come vincitore della gara, cui la Stazione Appaltante affida il presente appalto.
2. Premessa
Il Team Digitale (di seguito TD) intende effettuare una gara per individuare aziende tecnologiche in grado di fornire consulenze specialistiche di sviluppo software secondo il modello di sviluppo in open source e open-governance, da effettuarsi nell’ambito dei progetti previsti nel portale Developers Italia.
L’Impresa Aggiudicataria (di seguito IA) dovrà fornire i servizi richiesti, secondo le modalità ed alle condizioni espresse nel presente Capitolato Tecnico che descrive il contesto organizzativo e applicativo, oggetto dell’appalto, nonché le attività che devono essere svolte in fase di esecuzione.
3. Contesto di riferimento
3.1. Contesto tecnologico
TD ha redatto e pubblicato il “Piano Triennale”, un documento programmatico che indirizza l’evoluzione tecnologica del digitale in Italia. Nel capitolo 7, intitolato “Strumenti per la Generazione e la Diffusione di Servizi Digitali”, si descrive un nuovo approccio allo sviluppo di software e servizi pubblici, basato sull’uso di componenti open source e di un modello collaborativo orientato all’apertura verso le community tecnologiche.
In particolare, TD ha pubblicato e gestisce la piattaforma Developers Italia, all’interno della quale vengono progressivamente iniziati e condotti gli sviluppi di software open source e documentazione tecnica a supporto dello sviluppo dei servizi pubblici digitali italiani.
Sono stati identificati quindi alcuni progetti che ricoprono un ruolo chiave nell’attuazione del Piano Triennale nei prossimi mesi: alcuni di essi afferiscono alle cosiddette “Piattaforme Abilitanti”, cioè quelle tecnologie di base quali SPID (l’identità digitale), CIE (la carta d’identità elettronica) o ANPR (l’anagrafe centrale dei cittadini), che dovranno essere la base di tutti i nuovi servizi digitali italiani; altri sono di importanza strategica per il successo operativo delle stesse, come Docs Italia (la piattaforma per la condivisione dei documenti pubblici).
Con il presente appalto, verranno dunque reperite le risorse necessarie ad effettuare una parte degli sviluppi necessari ad iniziare, portare avanti o completare gli sviluppi dei progetti che fanno parte di Developers Italia.
3.2. Contesto organizzativo
TD manterrà su tutti gli ambiti di intervento il ruolo di coordinamento dei progetti oggetto dell’appalto e potrà partecipare con propri specialisti a tutte le fasi di realizzazione degli stessi.
Il TD avvalendosi eventualmente anche dei servizi richiesti nell’ambito del presente appalto, svolge i seguenti ruoli:
● coordinamento e raccordo di tutte le attività e servizi oggetto del presente appalto;
● definizione delle linee guida architetturali dei nuovi progetti;
● definizione dei requisiti funzionali;
● definizione del processo di sviluppo comprensivo della definizione dei metodi e delle tecniche da adottare;
○ definizione degli standard di progettazione e sviluppo;
○ definizione degli standard della documentazione, di gestione della qualità e sicurezza;
○ gestione degli strumenti di sviluppo;
● supporto alla progettazione.
4. Definizione della fornitura
4.1. Oggetto della fornitura
La fornitura sarà composta da task che si possono raggruppare in tre categorie:
● Contribuzione a progetti open source esistenti. TD chiederà all’IA di effettuare dei bugfix, introdurre nuove feature, o migliorare la documentazione di un progetto open source esistente già in Developers Italia. Il task comporterà quindi lo studio della base di codice esistente, la discussione con il maintainer del progetto sul miglior modo per introdurre la modifica, la scrittura del codice esistente;
● Creazione di nuovi progetti open source;
● Mantenimento di progetti open source.
4.2. Tecnologie impiegate
I progetti open source oggetto dell’attività saranno scritti o dovranno essere scritti a maggioranza con linguaggio Python: principalmente, si tratterà di applicazioni web, siti web, o implementazione di API. Di volta in volta, sarà discusso e deciso anche lo specifico framework di riferimento, privilegiando i più diffusi sul mercato. È richiesta anche la conoscenza del server di ricerca
ElasticSearch, per l’implementazione di motori di ricerca con accesso dinamico, e lo sviluppo di interfacce web per completare l’esperienza utente dei progetti.
4.3. Dimensionamento della fornitura
Si riporta nella tabella che segue il dimensionamento minimo delle allocazioni dei profili professionali richiesti e la distribuzione degli stessi rispetto ai servizi oggetto dell’appalto:
Figura professionale | Numero | Minimo giorni/persona in un periodo stimato di 5 mesi |
Responsabile del contratto | 1 | 30 |
Sviluppatori Python | 2 | 90 a sviluppatore* |
Sviluppatore ElasticSearch | 1 | 90 |
Sviluppatore Web | 1 | 90 |
*Per i 4 sviluppatori, dunque, si richiede un numero complessivo minimo di giornate pari a 360.
4.4. Termini di esecuzione dei servizi
La prestazione dei servizi oggetto di gara impegnerà l’IA - nel rispetto della durata del contratto di cui all’art. 2.3 del Disciplinare - per un periodo complessivo stimato di 5 mesi dal momento della data di avvio dei servizi.
5. Modalità di esecuzione dell’appalto
5.1. Risorse di sviluppo impiegate
Per l’esecuzione dell’appalto, viene richiesto l’utilizzo di un totale di 4 sviluppatori, da impiegare sui vari progetti secondo un piano organizzativo concordato con il TD.
Gli sviluppatori impiegati nell’erogazione dei servizi oggetto della fornitura devono rispondere ai seguenti requisiti minimi, il cui possesso deve emergere chiaramente dai curricula allegati all’offerta tecnica:
Sviluppatori Python:
● Almeno 3 anni di esperienza professionale nelle tecniche di programmazione backend con linguaggio Python e con framework per lo sviluppo web Django;
Sviluppatore ElasticSearch:
● Almeno 1 anno di esperienza nell’utilizzo del motore di ricerca ElasticSearch;
Sviluppatore Web:
● Almeno 3 anni di esperienza nella programmazione front-end (HTML5, CSS, Javascript).
In caso di indisponibilità per cause di forza maggiore di uno o più dei 4 sviluppatori, l’IA dovrà garantirne la sostituzione con profili professionali analoghi a quelli offerti in sede di gara, previa approvazione del CV proposto da parte di TD.
Durante l’appalto, TD si riserva la possibilità di richiedere la sostituzione di una risorsa ritenuta inadeguata per il progetto, a proprio insindacabile giudizio, fornendone comunque una motivazione scritta.
Con riferimento specifico al ruolo e alle competenze dello sviluppatore Web, si rappresenta che questi dovrà essere in grado di trasformare layout grafici in pagine web interattive, attraverso la conoscenza dei linguaggi HTML5, CSS3 e Javascript, e conoscere le moderne pratiche di sviluppo e gli standard necessari ad ottenere pagine responsive, performanti ed esenti dai rischi di sicurezza noti, come SQL injection o XSS. È equiparabile alla figura denominata "Frontend Web Developer" nelle Linee Guida delle professioni ICT pubblicate da AgID e visibili a questo indirizzo: xxxxx://xxxx.xxxxxx.xx/xxxxxx/xxxxxxxxx-xxxxxx/xx-xxxxxxxxxxxxxxxxxx-xxxx/xx/xxxxxxx/xxx/xxxxxxxxx e_specialistiche/lg-competenze/profili-competenza.html#frontend-web-developer o a pagina 17 qui xxxx://xxxx.xxx.xx/xx-xxxxxxx/xxxxxxx/0000/00/xxxxxxxxxxx-XXX.xxx
5.2. Responsabile del contratto
Per l’esecuzione dell’appalto gli operatori economici concorrenti devono individuare un Responsabile del Contratto (RC) che garantisca la qualità complessiva dei servizi erogati, gestisca gli stati di avanzamento lavori, operi quale referente amministrativo e organizzativo verso TD, anche al fine di risolvere potenziali criticità che dovessero insorgere durante il rapporto contrattuale.
Il Responsabile del Contratto, in particolare, dovrà partecipare alle riunioni organizzative, svolgere funzioni di monitoraggio delle risorse impiegate, garantendone il rispetto dei termini contrattuali, il recepimento delle indicazioni tecniche e organizzative di TD, e la corretta esecuzione.
Il Responsabile del Contratto deve rispondere ai seguenti requisiti minimi, il cui possesso deve emergere chiaramente dal curriculum allegato all’offerta tecnica:
● laurea ad indirizzo tecnico-scientifico con esperienza professionale nel settore oggetto dell’appalto non inferiore a 6 (sei) anni, di cui almeno 2 anni nel coordinamento di progetti
oppure:
● cultura equivalente corrispondente ad almeno 10 (dieci) anni di esperienza professionale nel settore oggetto dell’appalto, di cui almeno 4 anni nel coordinamento di progetti.
Il RC, pur essendo il punto di riferimento organizzativo, non deve fungere da filtro tra il TD e gli sviluppatori impiegati su Developers Italia. Gli sviluppatori, infatti, devono essere presenti personalmente all’interno degli strumenti di lavoro e collaborazione; tutte le conversazioni tecniche di dettaglio avverranno direttamente con contatti diretti con gli sviluppatori.
Gli operatori economici concorrenti dovranno garantire, mediante apposita dichiarazione resa in sede di partecipazione alla procedura, che le risorse proposte (Sviluppatori e Responsabile del Contratto) siano in possesso dei corrispondenti requisiti minimi, il cui possesso deve emergere dai curricula allegati all’offerta tecnica.
5.3. Assegnazione dei task
Il TD effettuerà meeting periodici (cadenza prevista: ogni 14 giorni) con il RC per:
● Monitorare lo stato di avanzamento dei task assegnati;
● Aggiornare le stime di completamento dei task;
● Accettazione dei task completati;
● Discutere dei nuovi task.
In base ai task in completamento e a quelli nuovi da cominciare, alle competenze degli sviluppatori, e alle necessità organizzative interne dell’IA, l’RC può gestire la turnazione interna dei 4 sviluppatori previsti dal contratto, presentando delle proposte per approvazione al TD.
In linea generale, è preferibile che gli sviluppatori assegnati ai task si dedichino all’esecuzione in modo continuativo e senza giornate di interruzione, finché il task non è finito per mantenere la massima concentrazione, ma in caso di necessità TD valuterà anche proposte che comprendono interruzioni.
Come eccezione, una delle tipologie di task previsti (“mantenimento di progetti open source”) richiede quasi esclusivamente reattività ad input esterni (risposta alle domande, mantenimento dell’issue tracker, ecc.) e sarà possibile quindi assegnarlo anche a sviluppatori che lavorino senza continuità.
5.4. Modalità di erogazione dei servizi di sviluppo
Lo sviluppo del software avverrà in due diverse modalità, in base agli specifici task che verranno assegnati:
● Contribuzione a progetti open source esistenti, con particolare focus sul progetto per la gestione di documenti pubblici Docs Italia (xxxx.xxxxxx.xx);
● Creazione di nuovi progetti open source
● Mantenimento di progetti open source
5.4.1. Modalità generali
Tutti i progetti di Developers Italia sono ospitati all’interno di GitHub, nell’organizzazione “italia”. Tutto lo sviluppo previsto nell’ambito di questo contratto deve avvenire direttamente su GitHub, utilizzando le best practice di sviluppo open source.
In particolare, verrà utilizzato il GitHub Flow per gestire il flusso di modifiche e code-review prima dell’integrazione.
Tutta la comunicazione tra l’IA e il TD avverrà principalmente tramite Slack, ed è richiesto che tutte le risorse dell’IA siano presenti in modo continuativo su Slack durante la giornata lavorativa.
5.4.2. Contribuzione a progetti open source esistenti
I task che richiedono di contribuire a progetti open source già esistenti in Developers Italia, o su progetti open source di terze parti, devono seguire le best-practice di collaborazione, in particolare:
● Adeguamento al coding style del progetto
● Adeguamento alle richieste tecniche del progetto (es: copertura con test automatizzati, testing su più piattaforme, ecc.).
● Discussioni preliminari con i maintainer del progetto su come implementare la modifica necessaria
● Invio di pull-request semanticamente atomiche e accompagnate da una descrizione accurata
● Utilizzo dello strumento di code-review per comunicare con il maintainer
● Iterazioni successive sul codice contribuito fino ad approvazione
● Supporto a posteriori se la modifica dovesse risultare problematica
In generale, è richiesto sempre di operare con spirito collaborativo e con una buona comunicazione aperta con i maintainer. In caso di situazioni di stallo, è necessario fare escalation della problematica direttamente su TD per sbloccare la situazione e arrivare a completamento del task.
5.4.3. Creazione di nuovi progetti open source
Nel caso venga assegnato un task che richieda la creazione di un nuovo progetto, è necessario seguire le best-practice sulla creazione di un progetto open source, e in particolare:
● Tutto lo sviluppo, fin dal primo commit, deve avvenire direttamente su GitHub.
● Sebbene sia consigliabile utilizzare fin da subito il GitHub Flow, può essere accettabile una fase di struttura iniziale in cui si lavora direttamente sul branch di sviluppo.
● Si devono utilizzare le Issue e i Project su GitHub per tracciare l’avanzamento
● Il progetto deve essere ben documentato fin dall’inizio:
○ a livello di overview generale, tramite un README che dettagli gli scopi, l’architettura generale, lo stato di avanzamento, e le indicazioni su come contribuire.
○ a livello di reference, tramite una documentazione di dettaglio dei principali moduli software e delle API pubbliche (ove presenti).
● Si deve valutare fin dall’inizio una buona copertura a livello di test automatizzati, e la configurazione di un sistema di continuous integration.
● Si devono accettare e gestire fin dall’inizio eventuali contribuzioni esterne, sia a livello tecnico (valutazione delle pull-request), sia organizzativo (inclusione di eventuali contributori esterni nel flusso organizzativo di sviluppo).
5.4.4. Mantenimento di progetti open source
In aggiunta agli specifici task assegnati, TD può richiedere che l’IA svolga il ruolo di maintainer di un progetto open source. Il ruolo di maintainer dovrà essere svolto secondo le best-practice del mondo open source, e in particolare:
● Monitoraggio delle eventuali problematiche segnalate dagli utenti come Issue; si richiede che venga fornito almeno un feedback iniziale su ogni nuova issue in tempi molto brevi (1gg lavorativa nel 90% dei casi), mentre una risposta più accurata che comprenda l’attività di analisi di dettaglio della problematica, conferma e suggerimento di possibili workaround può essere effettuata nei giorni successivi (comunque entro i 10gg lavorativi). NOTA: la risoluzione della issue in senso stretto non è necessaria, e può essere schedulata come task successivo, in accordo alla pianificazione prevista tra TD e RC.
● Monitoraggio delle feature request richieste dagli utenti in forma di Issue; si richiede che venga fornito almeno un feedback iniziale su ogni nuova issue in tempi brevi (3gg lavorativi nel 90% dei casi), mentre una risposta più accurata che comprenda un’analisi di come sarebbe possibile implementare la feature richiesta può essere effettuata nei giorni successivi (comunque entro i 10gg lavorativi). L’analisi è utile per favorire e indirizzare correttamente eventuali contribuzioni esterne.
● Monitoraggio delle pull-request aperte sul repositorio; si richiede che venga fornito almeno un feedback iniziale su ogni nuova issue in tempi molto brevi (1gg lavorativa nel 90% dei casi), mentre una code-review più accurata può essere effettuata nei giorni successivi (comunque entro i 5gg lavorativi). È importante comunicare in modo efficace la modalità con la quale la pull-request deve essere modificata per diventare accettabile, oppure chiarire il motivo di un eventuale rifiuto definitivo.
● Risposta alla domande degli utenti sul forum di Developers Italia; è possibile che gli utenti facciano richieste anche tramite il forum invece di GitHub; anche in questo caso, è necessario fornire un feedback immediato (1gg lavorativo nel 90% dei casi), rimandando una risposta più accurata successivamente (comunque entro i 5gg lavorativi).
● Verifica dello stato di salute dei servizi accessori al progetti; per esempio, se il progetto prevede un sistema di continuous integration o un ambiente di staging, monitorare l’uptime e la corretta configurazione, intervenendo in caso intervenga una anomalia.
È interesse di TD che l’IA possa svolgere in modo efficace questa attività per cui verrà tipicamente richiesto all’IA di svolgere l’attività di maintainer su progetti realizzati dall’IA stessa in task precedenti, oppure su progetti sui quali è stato possibile familiarizzare tramite task di contribuzione.
5.5. Luogo di esecuzione delle attività
Le attività possono essere svolte in telelavoro, nelle modalità preferite dall’IA.
È richiesto che la sede di lavoro sia dotata di una stabile e veloce connessione ad Internet, che consenta il normale svolgimento delle attività di sviluppo, incluse videoconferenze, senza lunghe attese o problemi di connessione.
Sarà necessario effettuare frequenti conference call di coordinamento e allineamento, per cui è richiesto che le risorse impiegate siano dotate della strumentazione necessaria per videochiamate di buona qualità sia singole, sia di gruppo (intero team).
Periodicamente, potrebbe essere richiesto di svolgere delle giornate di meeting a Roma, con un massimo di 4 incontri della durata totale di 8 giornate lavorative. Gli oneri relativi alle trasferte sono in carico all’IA e sono da intendersi inclusi nel corrispettivo globale della fornitura.