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 DI SVILUPPO PHP
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 4
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 di Trasformazione Digitale della Presidenza del Consiglio è una struttura commissariale istituita il 16 Settembre 2016 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.
I macro-progetti presenti in Developers Italia sono visualizzabili direttamente dal sito, ma la lista è in aggiornamento e crescerà quindi nei prossimi 12 mesi. In particolare, un ruolo centrale è rivestito da quelle che nel piano sono indicate come “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.
Per ciascuno di questi macro-progetti, TD ha identificato (o identificherà) tramite delle roadmap pubbliche gli specifici progetti di sviluppo software open source ritenuti necessari a creare un ecosistema software che consenta una veloce integrazione delle tecnologie da parte delle Pubbliche Amministrazioni (e dei loro fornitori), diminuendone quindi i tempi di adozione e riducendo i costi. A titolo di esempio, è possibile leggere la Roadmap di SPID per vedere un elenco dei progetti software open source a supporto di SPID ad oggi identificati, e il loro stato di avanzamento.
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, e in particolare il Team Developer Community, 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 Team Developer Community, 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.
Nel prosieguo del documento, i riferimenti al TD sono da intendersi riferiti al Team Developer Community che fa parte di TD.
4. Definizione della fornitura
4.1. Oggetto della fornitura
La fornitura sarà composta da task che si possono raggruppare in tre grosse 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 del 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 PHP: principalmente, si tratterà di applicazioni web, siti web, plugin o SDK che implementano API. Di volta in volta, sarà discusso e deciso anche lo specifico framework di riferimento, privilegiando i più diffusi sul mercato. Si lavorerà anche sull’estendere con dei componenti i principali CMS scritti in questo linguaggio (ad es. Wordpress o Drupal).
4.3. Dimensionamento della fornitura
Si riporta nella tabella che segue nella tabella 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 5 mesi |
Responsabile del contratto | 1 | 30 |
Sviluppatori PHP | 4 | 80 a sviluppatore* |
*Per i 4 sviluppatori, dunque, si richiede un numero complessivo minimo di giornate pari a 320.
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
L’IA deve garantire che tutti gli sviluppatori che impiegherà per l’erogazione dei servizi oggetto della fornitura rispondano ai seguenti requisiti minimi:
● Almeno 3 anni di esperienza professionale nel linguaggio PHP;
● Conoscenza approfondita di almeno 2 dei principali framework di sviluppo web in PHP, quali ad esempio:
○ Xxxxxxx
○ CodeIgniter
○ CakePHP
○ Pyramid
● Conoscenza di almeno 1 dei principali sistemi di CMS, quali ad esempio:
○ Wordpress
○ Xxxxxx
○ Drupal
○ Mediawiki
○ Concrete5
● Conoscenza delle tecniche di programmazione backend dello stack web
● Conoscenza di paradigmi di design di API (ad es. REST)
● Capacità di progettare delle librerie software, curando le relative API pubbliche
● Conoscenza base della programmazione front-end (HTML5, CSS, Javascript)
● Esperienza in contribuzioni a progetti open source;
● Esperienza nell’utilizzo di GitHub e nel GitHub Flow;
● Capacità di technical writing di documentazione tecnica in Italiano e Inglese.
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.
In caso di indisponibilità per cause di forza maggiore di uno o più dei 4 sviluppatori, l’IA dovrà garantirne la sostituzione proponendo al TD 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.
5.2. Responsabile del contratto
È richiesto che l’IA nomini 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.
Questi sono i requisiti minimi richiesti per il RC:
● laurea ad indirizzo tecnico-scientifico o cultura equivalente;
● buona conoscenza della lingua inglese parlata e scritta;
● completa padronanza delle tecniche di conduzione di progetti;
● elevata capacità di coordinamento, motivazione e guida delle persone;
● capacità organizzative e doti comunicative;
● capacità di intrattenere rapporti con i fornitori di hardware, software e servizi;
● esperienza professionale non inferiore a 8 (otto) anni.
Si noti che l’RC, pur essendo il punto di riferimento organizzativo, non deve assolutamente fungere funzione di filtro tra TD e le risorse dell’IA, né tra l’IA e altri sviluppatori presenti su Developers Italia. È richiesto che le risorse infatti siano presenti personalmente all’interno degli strumenti di lavoro e collaborazione e tutte le conversazioni tecniche di dettaglio avverranno direttamente con contatti diretti con le risorse.
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 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
● 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.