PROCEDURA NEGOZIATA SENZA PREVIA PUBBLICAZIONE DI UN BANDO DI GARA AI SENSI DELL’ART. 1, COMMA 2, LETT. B) DEL DL 76/2020, CONVERTITO IN LEGGE 120/2020, MODIFICATO DAL DL 77/2021, PER L’ AFFIDAMENTO DELLA FORNITURA DI UN PROTOTIPO QUALE STRUMENTO DI...
Capitolato speciale d’oneri
PROCEDURA NEGOZIATA SENZA PREVIA PUBBLICAZIONE DI UN BANDO DI GARA AI SENSI DELL’ART. 1, COMMA 2, LETT. B) DEL DL 76/2020, CONVERTITO IN LEGGE 120/2020, MODIFICATO DAL DL 77/2021, PER L’ AFFIDAMENTO DELLA FORNITURA DI UN PROTOTIPO QUALE STRUMENTO DI SUPPORTO ALLE DECISIONI AMBIENTALI (EDSS) REALIZZATO SU UNA PIATTAFORMA WEB IN CLOUD
8844719D01 – CIG
D42F16001330006 – CUP
Area Gestione Infrastrutture e Servizi Servizio Gare e Acquisti Servizi e Forniture Dipartimento di Energia
Acronimi 3
Premessa 4
Art. 1 - Oggetto della fornitura 6
Art. 1.1 - Requisiti minimi inderogabili 6
Art. 1.1.1 - Backend 9
Art. 1.1.2 - Frontend 11
Art. 1.1.3 - Caratteristiche e funzionamento del Modello maschera (MM) 12
Art. 1.1.4 – Altre caratteristiche 24
Art. 1.2 - Requisiti addizionali 29
Art. 1.3 - Servizi Richiesti. 30
Art. 1.3.1 - Formazione 30
Art. 1.3.2 - Documentazione 30
Art. 1.3.3 - Revisione e supporto all’adeguamento dei MM 30
Art. 1.3.4 - Collaudo 31
Art. 1.3.5 – Ulteriori condizioni di fornitura 33
Art. 1.3.6 – Supporto alla migrazione 33
Art. 2 - Importo della fornitura 33
Art. 3 - Termine di esecuzione della fornitura 34
Art. 4 – Backup dei prototipi realizzati 35
Art. 5 - Team di progetto 35
Art. 6 - Garanzia definitiva per la stipula del contratto 35
Art. 7 - Penali 36
Art. 8 - Inadempimenti contrattuali e risoluzione del Contratto 37
Art. 9 - Recesso 37
Art. 10 - Modalità di presentazione delle fatture e pagamento 37
Art. 11 - Divieto di cessione del contratto 38
Art. 12 - Riservatezza 38
Art. 13 – Proprietà intellettuale 39
Art. 14 - Tracciabilità dei flussi finanziari 39
Art. 15 - Normativa anticorruzione 39
Art. 16 - Utilizzo del nome e del logo del Politecnico di Milano 40
Art. 17 - Norme di riferimento 41
Art. 18 - Foro competente 41
Art. 19 - Trattamento dati 41
Art. 20 - Responsabile del procedimento 41
Art. 21 - Contatti del Punto Ordinante 41
Art. 22 - Accesso agli atti 42
Art. 23 - Spese contrattuali 42
Acronimi
DOP: Denominazione di Origine Protetta
EDSS: Environmental Decision Support Software GP: Grana Padano
KPI: Key Performance Indicator
LCA: Life Cycle Assessment (Analisi del ciclo di Vita) MM: Modello Maschera
PEF: Product Environmental Footprint
PEFCR: Product Environmental Footprint Category Rules TTGG: The Tough Get Going
UE: Unione Europea
Premessa
Il Dipartimento di Energia del Politecnico di Milano è il coordinatore del progetto Europeo LIFE 16 ENV/IT/000225 – LIFE TTGG (The Tough Get Going).
Il progetto ha come obiettivo principale la realizzazione di un prototipo quale strumento di supporto alle decisioni ambientali (EDSS) di facile utilizzo per supportare stalle, caseifici e confezionatori delle filiere di prodotti DOP nella valutazione dell’impronta ambientale PEF (Product Environmental Footprint) e nell’individuazione di soluzioni di efficienza per la riduzione delle prestazioni sia ambientali che economiche nelle aziende attraverso l’elaborazione e l’analisi di specifici Key Performance Indicators aziendali.
Gruppo di lavoro e di ricerca
Il gruppo di lavoro e di ricerca che ha lavorato al progetto LIFE 16 ENV/IT/000225 – LIFE TTGG
– “The Tough Get Going” (xxx.xxxxxxxx.xx) e sviluppato l’idea del prototipo di EDSS software è composto da due Università con quattro dipartimenti ed uno spin-off universitario. A lato di ogni dipartimento è riportata l’area di intervento all’interno del progetto.
• Politecnico di Milano:
o Dipartimento di Energia
o Dipartimento di Design
• Università Cattolica del Sacro Cuore:
o Dipartimento di Scienze animali, della nutrizione e degli alimenti
o Dipartimento di Scienze e tecnologie alimentari per una filiera agro-alimentare sostenibile
• Enersem – Spin-off del Politecnico di Milano
La metodologia della Product Environmental Footprint – PEF
La Product Environmental Footprint – PEF è una metodologia, sviluppata con un progetto pilota della Commissione Europea, che consente di misurare le prestazioni ambientali di prodotti e servizi riguardo a tutto il ciclo di vita, dalla produzione di materie prime allo smaltimento della confezione finale. La metodologia adotta il metodo LCA (Life Cycle Assessment) regolamentando la sua applicazione attraverso la definizione di specifiche regole per categoria di prodotto.
La metodologia trae origine dalla Raccomandazione 2013/179/UE della Commissione Europea, che mira ad introdurre metodologie comuni per misurare e comunicare le prestazioni ambientali nel ciclo di vita dei prodotti.
Un simile strumento diventa quindi una strada per quantificare e ridurre l'impronta ambientale di prodotti/servizi e per comunicare ai consumatori le loro prestazioni ambientali secondo un approccio standardizzato, al fine di permettere una scelta di acquisto basata anche sulle qualità ambientali dei prodotti finali.
Il prototipo (EDSS software) oggetto di queto bando di gara dovrà permettere alle aziende delle filiere casearie a denominazione di origine di poter elaborare studi in conformità alla PEF
europea e di confrontare i risultati aziendali con dati medi della filiera oggetto di analisi e dati medi europei.
Identificazione misure di efficienza in stalla e caseificio
Nell’ambito del progetto LIFE TTGG sono stati effettuati degli audit in stalla e nei caseifici al fine di monitorare i flussi di input e output di materia ed energia ed individuare delle possibili soluzioni di efficienza implementabili nella filiera al fine di ridurre i consumi energetici e di acqua in caseificio e di ridurre le emissioni e migliorare l’efficienza produttiva in stalla.
L’esperienza acquisita con gli audit sarà integrata all’interno del EDSS software. Attraverso l’elaborazione dei dati aziendali il software produrrà dei valori di riferimento KPI (Key Performance Indicators) relativi ai consumi energetici alla gestione dell’acqua e alle emissioni in azienda. Attraverso un’anagrafica delle soluzioni tecnologiche già implementate in azienda e attraverso il confronto dei KPI con dei valori medi di riferimento per la filiera le aziende saranno guidate nel porre attenzione particolare alle fasi aziendali in cui hanno prestazioni inferiori alla media e saranno supportate nell’individuazione delle soluzioni di efficienza implementabili nella loro realtà aziendale.
Art. 1 - Oggetto della fornitura
Oggetto del presente capitolato è la fornitura di un prototipo realizzato su una piattaforma WEB in cloud che acquisendo i Modelli Maschera (MM) permette la realizzazione di una o più Applicazioni in grado di calcolare la Product Environmental Footprint (PEF) dei formaggi DOP ed incoraggiarne la riduzione, consentendo l'adozione di soluzioni e tecniche per ottimizzare le prestazioni ambientali dei formaggi DOP all’interno dell’intero ciclo di produzione e quindi a partire dalla produzione del latte crudo in stalla, passando dalla trasformazione del latte in formaggio, la stagionatura dei formaggi, il loro confezionamento e la distribuzione fino a casa del consumatore finale.
Le Applicazioni potranno essere utilizzate dalle aziende della filiera (stalle, caseifici, confezionatori) come un vero e proprio software di supporto alle decisioni ambientali (EDSS).
Il prototipo dovrà implementare, interagire e coordinare la gestione delle informazioni tra i Modelli Maschera (MM) realizzati per ogni fase del ciclo di vita (Stalla, Caseificio, Confezionamento, Gestione Energia).
Le parti relative alla “Stalla” e alla “Gestione Energia” dovranno essere scorporabili dal resto (stand alone) ma i loro risultati e semi-elaborati dovranno essere resi disponibili nelle altre fasi implementate nel prototipo di software web. Il prototipo pertanto dovrà permettere l’implementazione di anche solo un gruppo ristretto di Modelli Maschera magari riferiti solo ad una specifica fase del ciclo di vita (ad es. fase di Stalla o fase Gestione Energia) permettendo quindi di elaborare un applicativo relativo alla singola fase.
I Modelli Maschera (MM) sono file con estensione (.xlsx) che contengono testi ed un insieme di funzioni (dati e regole) che definiscono e governano una configurazione completa di una valutazione d'impatto ambientale. Un MM esemplificativo è presente tra gli allegati dell’avviso. L’elenco esaustivo delle funzioni utilizzabili è disponibile a questo link (xxxxx://xxxx.xxxxxxxxxx.xxx/xxxx-xxxxxxx/xxxxx/xxxxxxx-xxxx-xxxxxxxx).
Art. 1.1 - Requisiti minimi inderogabili
La Piattaforma Web, che implementa i MM, dovrà essere costituita dalle componenti qui di seguito riportate e che sono considerate come requisiti minimi inderogabili:
• Backend di elaborazione dati
È il componente che orchestra tutte le operazioni sui dati: colleziona domande e risposte della configurazione, alimenta il database, interroga l’engine del MM, eroga le API per la presentazione web dei dati e infine genera i documenti di output;
• Database di raccolta dei dati utente, delle configurazioni e degli output delle configurazioni stesse
È uno spazio di memorizzazione dei dati della configurazione, delle utenze e dei ruoli correlati. Memorizza anche le compilazioni parziali delle configurazioni e i risultati finali;
• Engine di esecuzione del Modello Maschera
Il MM è un file Excel, contenente sia valori statici che valori calcolati tramite formule, che ha bisogno di un motore di calcolo, che può essere costituito o da una sessione di Excel in memoria,
oppure da una libreria analoga capace di interpretare le funzioni disponibili a questo link (xxxxx://xxxx.xxxxxxxxxx.xxx/xxxx-xxxxxxx/xxxxx/xxxxxxx-xxxx-xxxxxxxx);
• Bus di comunicazione backend - frontend
Il bus permette di far transitare tutte le informazioni utili all’elaborazione, da e per i vari componenti della piattaforma. Si richiede l’utilizzo del formato dati Javascript Object Notation (JSON: xxxxx://xxx.xxxx.xxx/xxxx-xx.xxxx);
• Frontend web
È il layer di presentazione (User Interface) verso gli utenti che compilano la configurazione. Si ipotizza che il frontend sia realizzato con tecnologie web o attraverso qualunque altra analoga piattaforma di presentazione dati (mobile Android, mobile iOS, desktop, eccetera);
Nella Figura è riportato uno schema che rappresenta la piattaforma WEB.
Piattaforma
Databa se
Backe nd
Output
Output
Output
Frontend
UTENTE
Engine
MM
La piattaforma segue il flusso applicativo descritto qui di seguito:
1) Load del modello Maschera
2) Recupero delle informazioni di configurazione (domande/risposte)
3) Presentazione all’utente delle domande e raccolta delle risposte
4) Elaborazione dell’esito della configurazione
5) Memorizzazione risultati
6) Presentazione degli output finali
Qui di seguito sono riportati uno ad uno i vari passaggi del flusso applicativo, e le modalità con cui devono essere implementati.
1) Load del Modello Maschera
Viene effettuata in funzione dell’utente e del tipo di configurazione che deve essere avviata, il primo passo del flusso è il caricamento del MM all’interno del prototipo. Tutti i MM disponibili (cioè le configurazioni avviabili e relative lingue) si intendono già disponibili in una cartella sul server. Il caricamento è l’operazione di pick del file corretto e l’invio all’engine.
Oltre a ciò, si deve valutare se è opportuno mantenere una sessione utente per tutta la durata della configurazione, oppure adottare principi più REST (session less), e quindi caricare di volta in volta, ad ogni interazione frontend / backend, il MM nell’engine.
La scelta andrà operata sulla base delle performance di esecuzione e sulla scelta dell’engine di elaborazione.
In ogni caso, sul MM andranno poi eseguite le seguenti operazioni:
a. Inizializzazione nel motore di Excel o simile;
b. Injection dei dati di partenza (MM standard);
c. Injection della configurazione, nello stato corrente;
d. Recupero dei dati elaborati;
Il passo di load del MM, essendo la configurazione di fatto uguale al MM standard, è costituito dai primi due punti dell’elenco.
2) Recupero delle informazioni di configurazione (domande / risposte)
Una volta che il Load del MM è stato completato, il backend si occupa della trasmissione dei dati dell’intera configurazione al frontend, che mostra lo step iniziale all’utente e predispone gli elenchi delle risposte multiple e i vari default di risposta.
3) Presentazione all’utente delle domande e raccolta delle risposte
Quando il frontend ha preparato la presentazione della configurazione, può avviare l’interazione con l’utente.
Da qui inizia il loop di definizione della configurazione compilata, che è la successione dei seguenti punti:
a. Selezione o modifica di una risposta della configurazione. Se l’operazione utente è invece la chiusura della configurazione (tramite un Pulsante apposito), allora si passa al punto “h”;
b. Invio al backend del dato di risposta e delle sue coordinate all’interno della configurazione;
c. Injection del dato nella configurazione caricata nell’engine;
d. Elaborazione dei dati in funzione della modifica indotta dal dato (passo a carico di Excel o simile);
e. Recupero e invio dell’intera configurazione al frontend;
f. Aggiornamento della presentazione in binding alla configurazione;
g. Ripresa dal passo “a”;
h. Invio al backend del segnale di chiusura configurazione;
4) Elaborazione dell’esito della configurazione
La chiusura della configurazione dà avvio all’elaborazione finale, cioè alla raccolta complessiva di tutti gli output di configurazione, i report e i graph di presentazione dei risultati, e la loro ridefinizione completa.
Consultare “Art 1.1.3 Caratteristiche e funzionamento del Modello maschera (MM)” per la ridefinizione delle entità output, report e graph.
Per la descrizione invece delle operazioni di backend necessarie per la ridefinizione delle entità stesse, consultare il paragrafo successivo (Art 1.1.1 Backend).
5) Memorizzazione dei risultati
La configurazione completa in formato JSON, gli output che ne derivano e i documenti di report e graph generati (rispettivamente in formato PDF e image) vanno memorizzati nel database in relazione all’utente che ha compilato la configurazione.
6) Presentazione degli Output finali
Al termine di tutte le operazioni, è possibile mostrare all’utente (direttamente nelle pagine web e tramite il download dei documenti) tutti gli output generati dalla configurazione.
Art. 1.1.1 - Backend
Il backend è responsabile di quasi tutta l’elaborazione dei dati e della produzione degli output finali.
Nel dettaglio il backend si occupa di:
a) Load del Modello Maschera: Il backend effettua il pick del MM file scelto dall’utente e lo invia all’engine Excel o equivalente, che aprirà il Workbook posizionandosi sullo sheet denominato “Template”. Questo sheet deve esistere. Il backend recupera quindi, riga per riga, tutta la configurazione, seguendo le regole di definizione delle entità illustrate nell’Allegato I - Regole per la compilazione. Notare in particolare che laddove la Sequence non è compilata, l’Elemento di configurazione è definito come un commento e può essere ignorato. Questi dati, codificati in JSON, sono definiti “la configurazione base”, cioè
l’insieme di domande, risposte, regole di visibilità, output, report e graph al tempo zero, cioè prima che l’utente scelga o modifichi le risposte.
b) Invio “Configurazione di base” al frontend: Il JSON della “configurazione base” viene inviato al frontend tramite un’apposita API invocata dal frontend nell’evento di avvio configurazione. Si ipotizza REST + JSON.
c) Ricezione delle modifiche / compilazioni di risposta dell’utente: Ogni volta che l’utente effettua una selezione di risposta, le informazioni indicate dall’utente vengono inserite in un JSON che contiene anche le coordinate dell’Elemento del MM (tipicamente la Sequence), e quindi spedite al backend via API. Il backend riceve queste informazioni e le inserisce puntualmente nello sheet di Excel, guidato dalla Sequence che agisce come identificativo univoco.
d) Elaborazione delle modifiche di configurazione: Questo passo è a carico dell’engine di Excel o equivalente, ma il backend al termine dell’elaborazione recupera l’intera configurazione e la invia nuovamente al frontend per l’aggiornamento del layer di presentazione. Valutare la possibilità di eseguire un diff del JSON rispetto alla sua versione pre-modifica e inviare al frontend la sola parte differenziale, per questioni di performance e trasporto.
e) Completamento della configurazione: Quando il frontend segnala la chiusura della configurazione, il backend recupera l’ultima versione dei dati con tutte le modifiche indicate dall’utente, cioè la configurazione in stato finale. Tale configurazione viene salvata nel database.
f) Generazione degli output di configurazione: La configurazione in stato finale conterrà una serie di Elementi definiti come output: questi sono i parametri finali risultato della configurazione.
Oltre a ciò, ci saranno anche degli Elementi report da creare, insieme a degli Elementi graph.
I Report vengono generati iniettando gli output all’interno di appositi campi mergefields, usando come corrispondenza i name degli output e i nomi dei mergefields. Valori speciali degli output sono:
◦ Graph: vanno elaborati i grafici corrispondenti e inseriti nel report;
◦ File: deve essere recuperato il contenuto del file indicato dal value dell’output e inserito nel report; se il value è blank, il mergefield corrispondente va eliminato dal report
I Graph sono grafici da renderizzare come image PNG, e vanno costruiti secondo le regole indicate nel capitolo relativo agli Output - Grafici dell’Allegato I.
g) Memorizzazione dei risultati: All’interno del database devono essere memorizzati i dati di configurazione finale in formato JSON, e i corrispondenti report e i grafici, in corrispondenza dell’utente che ha compilato la configurazione.
Art. 1.1.2 - Frontend
Il frontend genera pagine web ed è responsabile della raccolta delle risposte degli utenti. Nel dettaglio si occupa di:
a) Presentazione all’utente delle domande
Quando il backend trasmette il JSON della configurazione al Frontend, questi è responsabile della sua presentazione all’utente.
Attenzione: questo documento non descrive layout e grafica da adottare per la presentazione all’utente: consultare il documento (Documento di Prototype and wireframe design).
Le informazioni che descrivono il modo in cui va organizzato il layer di presentazione sono - Elemento per Elemento - le seguenti:
◦ Sequence: Indica l’ordine con cui presentare le varie domande della configurazione.
◦ Step: Indica i raggruppamenti delle domande, da organizzare in un wizard a step successivi.
◦ Question: Sono i testi delle domande da presentare all’utente. Laddove non compilate, nessuna domanda va mostrata (si salta l’intero Elemento, che probabilmente sarà un output).
◦ MU: Indica l’unità di misura del valore associato alla risposta, da mostrare a completamento della domanda.
◦ Type: Indica il tipo di dato del valore associato alla risposta. In funzione del Type va usato un widget di raccolta dati da utente appropriato (es. checkbox per il Bool, combobox per le Answer, etc.).
Consultare il documento di UX/UI (Documento di Prototype and wireframe design) per la look & feel da adottare.
◦ Default: Indica il valore da mostrare per la risposta laddove l’utente non abbia ancora espresso preferenza.
◦ Answer: Indica l’elenco delle risposte multiple da mostrare in corrispondenza della domanda. Se il Type è definito a Mask, allora l’elenco è a selezione multipla (gruppo di checkbox), altrimenti è a valori mutuamente esclusivi.
◦ Visible: Quando Visible è uguale a 0, allora l’intero Elemento NON va mostrato all’utente (domanda + risposta). Per qualunque altro valore (tipicamente 1), l’Elemento va mostrato.
◦ Enabled: Quando Enabled è uguale a 0, allora l’Elemento va mostrato all’utente, ma disabilitato: nessuna interazione utente è possibile. Per qualunque altro valore (tipicamente 1), l’Elemento ammetterà la normale interazione.
◦ Panel: Il Panel governa la visibilità di un pannello informativo che contiene informazioni utili all’utente. Se l’Elemento corrispondente è visibile, il Panel va mostrato in corrispondenza di tale Elemento, altrimenti in una posizione ben visibile della pagina di configurazione.
Il Panel può assumere i seguenti valori:
0 - Comportamento standard: nessun messaggio informativo va mostrato all’utente.
1 - Va mostrato all’utente un pannello informativo con una icona INFORMATION e un testo che è il campo Info. L’utente prosegue tranquillamente con la configurazione.
2 - Va mostrato all’utente un pannello informativo con una icona WARNING e un testo che è il campo Info. L’Elemento corrispondente, se visibile, va evidenziato in giallo. L’utente prosegue tranquillamente con la configurazione.
3 - Va mostrato all’utente un pannello informativo con una icona ERROR e un testo che è il campo Info. L’Elemento corrispondente, se visibile, va evidenziato in rosso. L’utente non può proseguire con la configurazione.
◦ Info: è il testo da mostrare all’interno del pannello informativo.
b) Raccolta delle risposte
Quando l’utente modifica o seleziona una risposta, il campo Value dell’Elemento va restituito al backend con una chiamata all’API di update configurazione. Insieme al Value va restituita anche la Sequence dell’Elemento, per connotare le coordinate dell’Elemento all’interno della configurazione.
In caso di Answer definite, il frontend deve inviare al backend anche l’IdAnswer selezionata dall’utente, oltre al Value.
c) Aggiornamento layer di presentazione
Ad ogni modifica della configurazione (selezione di una risposta da parte dell’utente), il frontend invia il dato al backend, il quale raccoglie l’esito della modifica dall’engine Excel e reinvia la configurazione al frontend.
Il frontend è quindi responsabile dell’aggiornamento del layer di presentazione in funzione delle modifiche descritte dal backend. Attenzione: le modifiche potrebbero essere in qualunque punto della configurazione, anche se andranno mostrate all’utente solo se nel contesto dello step corrente.
Il frontend dovrà però avere la precauzione di verificare se ci sono eventuali Panel con stato ERROR e impedire in tal caso il completamento della configurazione. Sarebbe opportuno poter mostrare all’utente una sorta di mappa di ERROR o WARNING eventualmente presenti nella configurazione.
Art. 1.1.3 - Caratteristiche e funzionamento del Modello maschera (MM)
Una descrizione esaustiva del funzionamento dei modelli maschera (MM) in fase di sviluppo da parte del gruppo di ricerca è riportata qui di seguito. Il gruppo di ricerca ha realizzato un MM per ogni fase del ciclo di vita analizzata, potrà essere prevista la realizzazione di MM addizionali. Il MM, (tranne nel caso specifico dell’interazione tra il MM “Caseificio” e il MM “Gestione Energia”) è un sistema che riporta le domande per la raccolta dati, contiene le formule per la loro elaborazione e definisce gli output dell’analisi della singola fase.
Pertanto il MM è l'insieme di dati e regole che definiscono e governano una configurazione completa di una valutazione d'impatto ambientale ed identificazione di soluzioni di efficienza.
Il MM è strutturato su un File Excel (estensione .xlsx) e le funzioni utilizzate per il calcolo sono elencate a questo link (xxxxx://xxxx.xxxxxxxxxx.xxx/xxxx-xxxxxxx/xxxxx/xxxxxxx-xxxx- formulas).
Il presente documento illustra gli Elementi costitutivi del MM e delinea i criteri utilizzati per la sua realizzazione.
NOMENCLATURA
Modello Maschera/Template: è una sequenza ordinata di elementi che costituiscono e definiscono l’insieme che effettua la valutazione d'impatto ed identificazione di soluzioni di efficienza. Il MM è strutturato su un foglio di calcolo/workbook Excel. Ogni MM è definito in una sola lingua: se si vuole creare una configurazione multilingue, basta definire un MM per ogni lingua. Nel MM vi è un unico foglio di lavoro il cui nome è “Template”. Tutti gli altri fogli sono utilizzati per definire i dati del foglio “Template”.
Elemento/Element: Un Elemento è una singola riga (o più righe consecutive) del foglio di calcolo, che contengono tutte le informazioni relative al più piccolo set di dati del MM, che può essere una domanda della configurazione, una formula di calcolo, un parametro di valutazione, e così via. Non vi è alcuna restrizione sul numero di elementi definibili per un singolo modello.
Campo/Field: Un campo è una singola proprietà dell'Elemento a cui esso appartiene. I campi che definiscono un MM sono rappresentati nelle colonne del foglio “Template” del MM. Qui sotto sono riportate le definizioni delle tipologie di campo presenti nel MM.
▪ Sequence: è un numero che identifica e ordina l'elemento, solo a scopo di nomenclatura.
▪ Step: indica un raggruppamento di domande nella configurazione.
▪ Name: definisce uno spazio di memorizzazione dedicato a un aspetto particolare della configurazione. Aspetto significa una delle seguenti proprietà:
◦ Una domanda sulla configurazione;
◦ Una caratteristica fisica o un attributo dell'oggetto da configurare;
◦ Un parametro di valutazione;
◦ L'output di un rapporto di dati;
◦ Un passo intermedio di qualsiasi elaborazione di dati;
Fondamentalmente, ogni volta che si vuole ottenere un risultato di configurazione, si definisce una linea del MM e gli si assegna un Name. Il sistema riserva uno spazio di memorizzazione (un luogo virtuale dove possono essere memorizzati dati di qualsiasi tipo) che poi potrebbe essere arricchito in modo molto vario, come descritto in questo elenco.
▪ Question: è il testo di configurazione che verrà mostrato all'utente, colui che dovrà compilarne la risposta.
▪ MU: Acronimo di Unità di Misura è una qualsiasi unità di misura associata all'elemento. Quando questo dato non è indicato, l'elemento è associato a un numero puro, o a un tipo di dato non numerico.
▪ Output: indica che i dati dell'elemento sono un output finale della configurazione, cioè un parametro della valutazione dell'impatto.
▪ Type: contiene informazioni sul tipo di dati che costituiscono il corrispondente valore Element.
▪ Default: è una formula che indica quale dovrebbe essere il valore predefinito (corrispondente a nessuna selezione fatta dall'utente), e poi conservato nell'Element.
▪ Answer: indica l'insieme delle opzioni di risposta disponibili per la Domanda corrispondente.
▪ IdAnswer: Quando l'utente seleziona una risposta, il suo IdAnswer sarà messo dal sistema in questa cella.
▪ Value: è una formula che definisce completamente i dati da conservare nell'elemento corrispondente, eventualmente basato su altri elementi già definiti.
▪ Visible: gestisce la visibilità dell'elemento.
▪ Enable: gestisce l'abilitazione dell'elemento.
▪ Panel: Un valore che abilita un pannello informativo, e la modifica del flusso di inserimento.
▪ Info: Testo visualizzato nel pannello informativo
Configuration: è l'insieme degli elementi definiti nel MM
Data Type: Ogni elemento è creato per modellare un aspetto della configurazione, ed è definito con una natura specifica che lo identifica e lo caratterizza. Cioè, può essere un numero intero, un numero decimale, una selezione di opzioni disponibili, un dato, un testo e così via. Il Data Type corrispondente è comunque unico per ogni elemento.
Required: definisce se il campo è obbligatorio e quindi se non compilato il sistema non accetta il MM.
Optional: definisce se il campo è opzionale e quindi se non compilato il sistema accetta comunque il MM.
REGOLE SU CUI SI È BASATA LA COMPILAZIONE
Sequence: è un numero intero naturale positivo consequenziale. Ogni Valore di Sequence è pari al numero della riga precedente +1. Qualora il campo sia vuoto, la riga verrà ignorata.
Step: Definisce un raggruppamento omogeneo di Elementi. è un numero intero naturale positivo consequenziale che definisce il raggruppamento. L’utilizzo di questo valore permette di separare quegli elementi la cui elaborazione porta ad un elemento specifico successivo, permette pertanto di prevedere il completamento di uno Step prima che ne comincia uno nuovo.
Name: La proprietà “Name” è identificata da una singola parola che può consistere in lettere maiuscole o numeri, e dal carattere underscore/trattino-basso (“_”); nient'altro. Il primo carattere non può essere un numero. Il Name deve necessariamente essere unico, cioè, non ce ne possono essere due uguali, e sono obbligatori. I Name non possono essere uguali a comandi Javasript (JavaScript Reserved Words)
Question: Testo di lunghezza non definita ed illimitata composto da caratteri “Unicode” ad eccezione del carattere “return” che non può essere utilizzato. Tale Testo sarà visibile all’utilizzatore. La Question è un field opzionale e pertanto, se non specificato, può essere un altro tipo di field.
MU: Abbreviazione del sistema internazionale che definisce una dimensione fisica. Può anche essere una combinazione di unità del sistema internazionale. Il testo MU è opzionale, se riportato verrà reso visibile all’utilizzatore. Lo spazio di caratteri disponibili è molto limitato.
Output: Il riempimento del campo Output ammette solo i seguenti valori:
• Yes: l'elemento è un parametro di valutazione dell'impatto utilizzabile come risultato dell’elaborazione;
• No: l'elemento non è un parametro di valutazione, ma è qualcos'altro, per esempio una domanda, un risultato parziale dell'elaborazione, e così via;
Il campo Output è opzionale. Un valore vuoto è equivalente al valore No. Sono accettati sia caratteri maiuscoli che minuscoli.
Type: configura la natura dei dati. È un campo obbligatorio. Qui di seguito sono riportati i data Type utilizzati.
▪ Int: numero intero naturale
▪ Dec: numero decimale
▪ Text: testo privo di formattazione
▪ Date: data/ora
▪ Bool: valore booleano (Yes/No)
▪ Mask: simile al Type Int, utilizzato quando le rispose non sono mutualmente esclusive (risposte multiple). Il valore dell’elemento sarà la somma dei valori selezionati come risposta.
▪ Report: Una riga di modello speciale che definisce la posizione e il nome di un documento Word specifico che potrebbe generare un rapporto PDF in uscita con tutte le informazioni raccolte ed elaborate nel processo di configurazione.
▪ Graph: Questa riga di modello specifica un foglio che contiene le informazioni per disegnare un output grafico per un aspetto della configurazione.
▪ File: è valido solo negli elementi di Output: quando viene inserito in un rapporto, il suo valore sarà un “valid filename” nella cartella “Template”: il contenuto del file sarà inserito nel rapporto nella posizione di mergefield corrispondente. Se il valore è vuoto, il contenuto del mergefield verrà cancellato.
Default: valore con proprietà specifica che viene automaticamente selezionato dal sistema quando un utente non ha assegnato un valore alla cella corrispondente. Valore opzionale che deve essere compatibile con il “data Type”.
Answer: Quando una lista di possibili “Answer” viene assegnata ad una domanda, questa lista è inserita in un foglio di lavoro dedicato il cu nome è inserito in questo campo. Il foglio di lavoro è organizzato in questo modo:
• Nella prima colonna c’è il “Name” che identifica la risposta (valore statico alfanumerico unico con le stesse caratteristiche del “Name”).
• Nella seconda colonna è inserito il testo visibile all’utente.
• La terza colonna contiene il valore di “Answer”, formula che calcola l’effettivo valore “dell’Element”
• La quarta colonna contiene il parametro di visibilità dell’Answer (parametri di visibilità trattati più avanti).
La prima riga del foglio di lavoro è dedicata alle intestazioni delle colonne e deve essere ignorata. Le risposte sono sempre mutualmente esclusive a meno che il “Type” è definito come “Mask”. In questo caso l’elemento permetterà la selezione di risposte multiple.
IdAnswer: In questo campo il sistema dovrà inserire l’identificativo della risposta selezionata dall’utente. Se la risposta è del Type Mask, in questo campo sarà inserito il valore che concatena le risposte selezionate.
Value: I è il dato memorizzato al suo interno, associato al suo Name in una formula o in un report di presentazione quando viene compilata una risposta, il Value sarà compilato con l'identificatore della risposta selezionata dall'utente. Se la risposta è del Type Mask, in questo campo sarà inserito il valore che concatena le risposte selezionate.
Visible: questo campo accetta i seguenti valori:
• 0 – L’elemento sarà nascosto e lo User non potrà visualizzarlo.
• 1 – L’elemento sarà visibile allo User.
Enabled: questo campo accetta i seguenti valori:
• 0 – L’elemento verrà disabilitato e lo User non potrà interagire con esso.
• 1 – L’elemento sarà visibile ed attivo.
Panel: questo campo accetta i seguenti valori:
• 0 – Non sarà mostrato alcun pannello informativo per l’utente. Il flusso di compilazione procede regolarmente.
• 1 – l’utilizzatore potrà vedere un pannello con le informazioni in una specifica icona, compilata con il contenuto del messaggio. Il flusso di compilazione procede regolarmente. L’informazione sarà visibile anche qualora l’elemento non sarà visibile, per fornire suggerimenti allo user.
• 2 – l’utilizzatore vedrà il pannello di informazioni come un’icona di allerta (!), compilata con il contenuto del messaggio. L’elemento, se visibile, verrà sottolineato di colore Giallo. Il flusso di compilazione procede regolarmente, ma la configurazione potrebbe non essere completa.
• 3 – l’utilizzatore vedrà un pannello con un’icona di Errore (X rossa), compilata con il contenuto del messaggio. L’elemento se Visibile verrà sottolineato con colore Rosso. Il flusso legato alla compilazione si blocca e non è possibile avanzare alla cella seguente.
Info: Il campo conterrà il testo che verrà riportato nel Panel. Saranno compilati e ricalcolati in base all’interazione con l’utente (selezione/compilazione) così da rendere l’interfaccia user dinamica rispetto al dato inserito.
PRESENTAZIONE DEGLI OUTPUT
Vengono inoltre definiti degli Output del sistema che hanno la funzione di presentare i risultati del di una configurazione specifica al futuro utilizzatore finale del software. Tali output sono:
▪ Report, definiti anche come File (esportabile in formato PDF);
▪ Grafici, definiti anche come Graph (visualizzabili come risultato dell’analisi ed esportabili in formato immagine JPG o PNG)
Qui di seguito una loro definizione:
Report:
Il Report è un modello Word. Al suo interno vi sono alcuni segnaposto speciali ben definiti, dove il sistema può inserire tutte le informazioni estratte da un modello compilato.
I segnaposto speciali sono i “mergefields” di Word (gli stessi usati dalla funzione MailMerge).
I dati iniettati dal sistema nei mergefields sono il campo Value (calcolato nel contesto di configurazione) delle righe del MM contrassegnate come Output. Sono iniettati dal Name della riga, abbinato al nome del mergefield.
Quando tutte le righe di output abbinate al nome del mergefields sono inserite nel modello Word, il sistema genera automaticamente un documento PDF che risulta essere un documento di output ufficiale della configurazione.
L'amministratore del modello può definire tutti i rapporti che vuole. Per definire un documento di rapporto bisogna completare questi passi:
▪ Definire una sequenza
▪ Definire il nome di una riga del MM
▪ Definire il campo Tipo come Rapporto
▪ Definire una formula o dati statici nel campo Valore della riga
▪ Definire una formula o dati statici nel campo Visibilità della riga
Quando tutti questi passi sono completati e il valore di Visibilità è 1, il Report viene presentato all'utente. Se l’utente esegue questo passaggio, il documento PDF viene generato e inviato al browser per il download.
Grafici:
Il Grafico è una riga del MM con queste configurazioni:
▪ Definire una sequenza
▪ Definire il nome di una riga MM
▪ Definire il campo Type come Graph
▪ Definire il nome di un foglio Excel nel campo Valore della riga
▪ Definire una formula o dati statici nel campo Visibilità della riga
Per ogni grafico predefinito nel sistema, il foglio Excel MM è stato definito come segue:
1) Istogramma:
Range | Description |
A1 cella | Tipologia di Grafico: Histogram |
A2 cella | Titolo del grafico |
A3 cella | Sottotitolo del grafico |
A4 cella | Titolo asse Y |
B colonna | Etichette asse X |
C colonna | Serie di dati dell’istogramma |
D colonna | Dato di benchmark o riferimento |
La serie sarà chiusa alla prima riga vuota rilevata dal sistema. Esempio 1:
A | B | C | D |
Istogramma | Cogeneratore | 430 | |
Fonti energia elettrica | Rete elettrica | 510 | |
Consumo totale di energia elettrica del 2017, suddiviso per fonte | Biogas | 90 | |
Pannelli fotovoltaici | 60 |
Esempio 2:
A | B | C | D |
Istogramma | Packaging primario | 7,3 | 6,8 |
Confronto dell’impatto ambientale tra i processi di lavorazione | Packaging secondario | 5,4 | 5,7 |
Sono prese in considerazione | Packaging terziario | 3,9 | 3,8 |
mPti | Gas alimentare | 3,0 | 3,1 |
Acqua | 4,2 | 4,9 | |
Gas refrigeranti | 0,2 | 0,2 | |
Detergenti | 0 | 0 | |
Rifiuti | 5,2 | 4,9 | |
Trasporto forme in input | 0,5 | 0,9 |
2) Istogramma overlying:
Range | Description |
A1 cella | Tipo di Grafico: Overlying |
A2 cella | Titolo del Grafico |
A3 cella | Sottotitolo del Grafico |
A4 cella | Titolo Asse Y |
B colonna | Etichette Asse X (partendo dalla 2° riga) |
C1 cella e successive | Etichette dati |
C colonna e successive | Valori Serie (ad eccezione della riga 1) |
Esempio:
A | B | C | D | E | F | G |
Overlying | Gratt | Trancio | Forma | Energia | Altro | |
Categoria d’impatto | Trancio 450g | 1,1 | 1,1 | 0,3 | 0 | 0 |
Trancio 450g BIO | 1,2 | 1,2 | 1,7 | 0 | 0 | |
mPti | 1/8 Forma | 0,7 | 0,3 | 3,5 | 0,5 | 0,2 |
Trancio 800g | 0,6 | 0,2 | 3,3 | 0,4 | 1,2 | |
Gratt. 1 kg | 0,4 | 1,4 | 1,2 | 0,3 | 1,5 |
3) Grafico a Torta:
Range | Description |
A1 cella | Tipo di Grafico: Torta |
A2 cella | Titolo Grafico |
A3 cella | Sottotitolo Grafico |
A4 cella | Valori unità di Misura |
A5 cella | Indica se la torta mostra valori (vuoto) o percentuali (“%”) |
B colonna | Etichette serie (partendo dalla 2° riga) |
C1 cella e successive | Titolo serie di dati |
C colonna e successive | Valori Serie (ad eccezione della riga 1) |
Esempio:
A | B | C | D |
Torta/Pie | CR117 | Benchmark | |
Ciclo vita della produzione del Grana Padano | Stalla | 30,7 | 32,8 |
Contributi in percentuali di impatto ambientale di ogni fase del ciclo di vita di | Caseificio | 5,7 | 5,9 |
1 kg di Grana Padano DOP | |||
mPti | Confezionament o | 1,9 | 2,6 |
% | Distribuzione | 1,6 | 2,3 |
Uso | 1,2 | 1,9 | |
Dismissione | 0,4 | 0,7 |
4) Istogramma Orizzontale:
Range | Description |
A1 cella | Tipo di Grafico: Barre |
A2 cella | Titolo grafico |
A3 cella | Sottotitolo grafico |
B colonna | Etichetta serie (a partire dalla 2° riga) |
C1 cella e successive | Titolo serie dati |
C colonna e successive | Valori serie di dati (ad eccezione riga 1 1) |
Esempio:
A | B | C | D |
Barre | Prodotto | Benchmar k | |
Impronta ambientale confezionamento grana Padano DOP | Packaging primario | 50 | 60 |
Risultati per fasi di confezionamento comparati al benchmark | Packaging secondario | 55 | 52 |
Packaging terziario | 48 | 45 | |
Gas alimentari | 58 | 80 | |
Energia | 30 | 20 | |
Acqua | 6 | 7 | |
Detergenti | 1 | 9 | |
Gas refrigeranti | 8 | 10 | |
Rifiuti | 4 | 5 | |
Trasporto forme in input | 10 | 11 |
Logo/Immagine:
Range | Description |
A1 cella | Tipo di grafico: Logo |
B colonna | I 4 valori % per generare il Logo. |
Esempio:
A | B |
Logo | 38 |
33 | |
8 | |
21 |
Art. 1.1.4 – Altre caratteristiche
Il prototipo si occuperà di integrare i diversi Modelli Maschera oltre che a gestire l’interfaccia con i diversi utenti.
Il software dovrà essere installabile in un container docker su server Linux.
Qui di seguito sono riportate altre funzionalità minime inderogabili che il software dovrà avere.
FUNZIONALITÀ
Gestione EDSS software
1. Il software della parte relativa all'efficienza energetica “Gestione Energia” in caseificio e la parte relativa alla Stalla “Latte Crudo” dovrà essere scorporabile dal resto (stand alone) ma i suoi risultati e semi-elaborati dovranno essere resi disponibili nelle altre fasi. Pertanto, i MM delle parti sopracitate potranno essere acquisiti sia singolarmente che in concomitanza con gli altri modelli.
2. Il software dovrà provvedere ad acquisire ed integrare Modelli Maschera diversi per la realizzazione di uno studio di impatto ambientale riferiti alle diverse fasi di produzione.
(Latte Crudo, Caseificio + stagionatura, Confezionamento e distribuzione; Gestione Energia), permettendo quindi la realizzazione di applicazioni specifiche per prodotto finale (formaggio Grana Padano, Formaggio Comté etc.).
Accesso prototipo per l’acquisizione dei MM
Il prototipo per l’acquisizione dei MM dovrà disporre di un sistema integrato per la:
1. Acquisizione sostituzione dei MM predisposti
2. Creazione modifica ed eliminazione degli utenti
3. Gestione di differenti ruoli all’interno e all’esterno dell’organizzazione: ogni ruolo potrà essere configurato con un diverso insieme di diritti che determinano il particolare accesso alle informazioni e attività del sistema.
Le tipologie di utenti sono state delineate nel documento allegato “Studio di Prototype Design e specifiche funzionali.” Qualora vi fossero delle informazioni all’interno del presente capitolato in contrasto con quanto riportato nello studio di Prototype Design quanto riportato nel presente capitolato prevale.
Si specifica inoltre che:
L’utente amministratore ha accesso a tutte le funzionalità del prototipo per l’acquisizione dei MM, incluse il database degli Utenti Esterni e la gestione degli Utenti Interni
Sistema per la gestione dei contenuti
1. Il prototipo dovrà avere un sistema per la gestione dei contenuti (immagini, loghi, testi, titoli etc.) non inclusi nei diversi Modelli Maschera. Tale sistema potrà essere gestito o attraverso una piattaforma o tramite la modifica dei contenuti a database.
Realizzazione delle applicazioni A, B e C per la Gestione dei Consorzi
1. I MM saranno strutturati in base alle filiere casearie a denominazione d’origine e in ottica futura potranno essere estesi ad altre filiere. Ogni Consorzio analizzato nel progetto ha le sue peculiarità (dati medi di riferimento; formule per la stima di alcuni parametri; equazioni; fattori moltiplicatori) che sono specifici per la filiera analizzata. Il prototipo dovrà permettere la realizzazione di almeno tre applicazioni. Applicazione A (Grana Padano DOP), applicazione B (Comté PDO) che dovranno contenere riferimenti e loghi delle specifiche Denominazioni d’Origine ed un’applicazione C (di test) che potrà essere composta da una singola fase o da più fasi della filiera. Le applicazioni dovranno avere accessi degli utenti e domini distinti, ma basati sulla stessa piattaforma e installabili in un unico server.
2. L’applicazione C sarà il primo caso di replicazione di un nuovo prototipo basato su un MM destinato a filiere ancora da individuare. Il gruppo di ricerca dovrà essere in grado di elaborare un nuovo prototipo funzionante per ogni gruppo di MM o singolo MM che realizzerà.
Gestione Utenti generale:
1. applicazione web in cloud, con accessi differenziati per tipologia di utente;
2. Creare i profili degli utenti (amministratore, verificatore, consorzio, produttore latte; produttore caseificio, produttore confezionatore) con le rispettive interfacce grafiche/strutture del software e funzionalità, per ogni Consorzio. I profili condivideranno l’accesso sia per i tool di impatto ambientale (Stalla e Caseificio) che per il tool Gestione Energia.
3. Progettare il sistema di ticket/assistenza fra utenti e amministratore per la risoluzione dei problemi tecnico-informatici.
Specifiche Utenti
1. Utente Amministratore: L'utente amministratore lavora presso la società proprietaria del software. Fornisce assistenza clienti ed è in contatto diretto con gli sviluppatori per la manutenzione evolutiva.
Funzioni da implementare:
a. Gestisce le autorizzazioni degli utenti attraverso un’interfaccia di gestione utenti
b. Gestisce aziende
c. Analizza i dati inseriti nel software in una dashboard (vedi documento di prototype design e specifiche funzionali – paragrafo dashboard)
d. Analizza l'utilizzo dell'app (analytics system)
e. Il database deve essere accessibile per scaricare, esportare o modificare il contenuto.
f. Gestisce ticket di supporto (ticketing system)
g. Condivide approfondimenti con gli sviluppatori
h. Configura il Modello Maschera/Template
i. Aggiorna i fattori di calcolo analisi ambientale
2. Utente Produttore: Utenti produttori gestiscono i dati delle aziende che possono svolgere una o più tra le 4 tipologie di fasi nella produzione del formaggio: Stalla, Caseificio, Confezionamento. Gli utenti che svolgono gli stessi task, a differenza delle aziende che svolgono anche la trasformazione del latte (Caseificio) che hanno accesso anche ad uno strumento specifico - Efficientamento Energetico (MM Gestione Energia). Funzioni da implementare:
a. Registrazione al sistema
b. Gestione del proprio profilo di utente
c. Creazione e compilazione domande per una nuova valutazione
d. Visualizzazione report e informazioni su come migliorare
e. Analisi delle soluzioni di efficientamento energetico (Caseificio)
f. Dashboard con i grafici comparativi e riassuntivi
g. Download / stampa dati
h. Richiesta assistenza clienti
Produttore Latte: Aziende agricole, produttori di latte (allevamenti), producono latte e lo forniscono ai caseifici. A volte producono anche formaggio. Si occupano quotidianamente di allevare gli animali. Hanno una ridotta familiarità con gli strumenti digitali rispetto ad altri gruppi di utenti della catena. Il loro impatto nella catena del ciclo di vita del formaggio è maggiore rispetto ad altri attori.
Produttore Caseificio: I caseifici trasformano il latte, acquistato dagli allevamenti, producendo il formaggio. Spesso si occupano anche delle fasi di stagionatura, confezionamento e di vendita diretta al consumatore. Hanno personale amministrativo che ha familiarità con gli strumenti digitali
Produttore Confezionamento: Comprano le forme stagionate o le stagionano e le confezionano in diversi formati: porzionati (½, ¼, ⅛), grattugiati, scaglie, cubetti, snack etc. Sono più orientati verso la vendita, la promozione e il contatto diretto con il consumatore e i media.
3. Utente Verificatore: Il verificatore è un esperto nel settore, un consulente indipendente, assunto dal produttore per verificare la veridicità dei dati inseriti. Per farlo dovrà recarsi presso la sede aziendale o chiedere invio di materiale digitale e confrontare i dati disponibili con quelli dichiarati all’interno della valutazione (dati inseriti dall’utente); Rilascia un certificato o una richiesta di correzioni; Funzioni da implementare:
a. Gestisce il proprio profilo di utente
b. Visualizza i produttori e i prodotti a lui/lei assegnati
c. Analizza, esporta e stampa i dati
d. Xxxxxxx se rifiutare o accettare
e. Inserisce un messaggio di accompagnamento alle azioni o può effettuare l’upload di un documento relativo alla verifica
f. Effettua un upload del certificato finale.
4. Utente Consorzio: Il consorzio di tutela dei marchi riunisce i produttori consorziati, offre servizi ed informa i membri del consorzio e gestisce la promozione del marchio e la comunicazione di marketing. Funzioni da implementare (M):
a. Gestisce il proprio profilo di utente
b. Visualizza la lista di utenti e delle aziende
c. Monitora i progressi dei singoli membri
d. Analizza gli indicatori (KPI) in dashboard
e. Visualizza le analisi di efficienza energetica
f. Visualizza i progressi di validazione dei dati
g. Scarica / esporta dati aggregati a livello di consorzio, anno e prodotto.
Funzionalità database
1. Creazione di uno spazio di stoccaggio (database) dei dati inseriti nell’EDSS software ed elaborati (dati strutturali aziendali, dati per il calcolo dell’impatto ambientale, dati energetici, dati “semilavorati” frutto di una prima elaborazione dei dati aziendali, risultati finali, file e grafici). L’accesso al database deve essere tale per cui l’Utente Amministratore abbia la facoltà di interrogare il contenuto delle tabelle tramite query di qualsivoglia complessità.
2. I risultati della componente energetica e della componente ambientale devono essere salvati in un Database e richiamabili per possibile utilizzo in una fase di confronto con il benchmark o KPI o di realizzazione di nuovi benchmark o KPI.
3. Possibilità di estrapolare i dati salvati nel database in formato .xlsx o .csv per ogni fase della filiera (per tipologia di latte e GP, per soluzione di confezionamento).
4. Memorizzare i dati inseriti nel template web dall’utente, e le valutazioni effettuate (sia parziali, che complete) e i report e Grafici generati.
5. Progettare il sistema di grafici di confronto/media fra le diverse valutazioni effettuate negli anni dall’utente (es. disponibile nel documento prototype design e specifiche funzionali nel paragrafo statistiche).
Gestione Questionario
1. Scaricare la checklist base (nessun dato inserito), parzialmente terminata (alcuni dati inseriti) e completa (tutti i dati inseriti), il formato del file in cui verrà scaricata la check list verrà definito con l’azienda selezionata.
2. Occuparsi della grafica dell’interfaccia sulla base di quanto elaborato nella fase di prototype design (colori, titoli e sottotitoli, dimensioni, comparsa dei messaggi di errore in rosso, punti di spiegazione=“?” a fianco alle domande della checklist…).
Gestione Accessi e registrazione
1. Permettere, nell’ambito di una singola applicazione, allo stesso utente di accedere ai tre blocchi (Ambientale Stalla, Ambientale Caseificio e Gestione energia con stesso ID e Password). Alcuni utenti però potranno essere autorizzati ad inserire i dati in uno solo o in alcuni blocchi (es. esclusivamente Gestione energia, blocchi Ambientali (stalla + caseificio), blocchi ambientale caseificio e gestione energia)
2. Memorizzare a database i dati aziendali strutturali riferiti all’azienda (inseriti una volta sola dall’utente, per la prima valutazione) e riproporli automaticamente nelle domande strutturali a inizio delle successive nuove valutazioni (utente può lasciarli così se nulla è cambiato, o aggiornarli e sovrascriverli se ci sono state modifiche aziendali).
3. Prevedere un accesso per ogni utente con ID e Password e con un sistema di recupero e gestione password.
4. Abbinare l’utente alla sola applicazione della fase che può/vuole analizzare; associare all’utente che fa la valutazione le sedi per la quale può fare l’analisi d’impatto ambientale.
Eventualmente Gestite da un Modello Maschera
1. Progettare il sistema di media degli impatti delle fasi a monte, in input nel MM della fase successiva dell’analisi. Tale sistema potrà essere realizzato attraverso la creazione di un MM addizionale da elaborarsi con il supporto del fornitore.
2. Scoping selezione fase: stalla, caseificio, stagionatore, confezionamento, combinazioni dei precedenti. In fase d’analisi gli utenti potranno scegliere quali fasi della filiera vogliono
compilare. E nel caso anche più fasi di una stessa filiera, nel caso di più prodotti o di più stabilimenti all’interno della stessa azienda.
Art. 1.2 - Requisiti addizionali
Qui di seguito sono riportati dei requisiti addizionali per la realizzazione del tool. Sono requisiti che saranno oggetto di valutazione in sede di Offerta Tecnica secondo le prescrizioni fissate dal Disciplinare di Gara.
FUNZIONALITÀ ADDIZIONALI
Gestione Utenti generale:
1. Realizzare il sistema di condivisione e accesso ad una specifica valutazione con uno/più collaboratori (abilitati a inserire i dati, vedere gli impatti, scaricare il report, condividere l’impatto con una fase a valle).
2. Applicare alle singole pagine di raccolta dati delle limitazioni di accesso. Solo collaboratori autorizzati dall’utente aziendale hanno accesso al processo.
Specifiche Utenti
1. Utente Consorzio: Il consorzio di tutela dei marchi riunisce i produttori consorziati, offre servizi ed informa i membri del consorzio e gestisce la promozione del marchio e la comunicazione di marketing. Funzioni implementabili:
a. L’utente consorzio deve poter accedere ad una sua interfaccia in cui mettiamo a disposizione grafici, tabelle e KPI che riassumono i risultati principali fino a quel momento e lo stato di avanzamento sull'uso del tool da parte dei consorziati. Tale sistema potrà essere realizzato attraverso la creazione di un MM addizionale da elaborarsi con il supporto del fornitore.
Gestione Questionario
1. Inserire delle immagini nella checklist (es. 1: formati di GP; es. 2: tipologie di packaging primario; es. 3: aree geografiche per la distribuzione).
Gestione approcci
1. adattare raccolta dati in base alle diverse finalità (approccio base, 1° certificazione, sorveglianza 2° anno, etc.) e quindi con un diverso grado di complessità. Tale sistema potrà essere realizzato attraverso la creazione di un MM addizionale da elaborarsi con il supporto del fornitore.
Art. 1.3 - Servizi Richiesti.
Art. 1.3.1 - Formazione
Il fornitore dovrà predisporre ed erogare al gruppo di ricerca, presso le sedi del Politecnico di Milano e dell’Università Cattolica del Sacro Cuore (Piacenza), un adeguato piano di addestramento e formazione all’utilizzo del sistema per la gestione dei contenuti e di acquisizione dei modelli maschera. Tale piano di addestramento e formazione dovrà essere preventivamente approvato dal Politecnico di Milano. L’addestramento dovrà essere coadiuvato da materiale didattico necessario per il corretto svolgimento dell’attività formativa e dovrà portare i destinatari del piano di formazione ad un sufficiente livello di autonomia per lo svolgimento delle proprie attività. Il Politecnico di Milano valuterà il livello raggiunto e potrà richiedere all’aggiudicatario di adeguare senza costi aggiuntivi le attività formative prima di procedere con la consegna della piattaforma web. La formazione dovrà provvedere una parte teorica relativa al sistema di gestione dei contenuti e acquisizione dei MM e una parte di esercizi pratici che rispecchino l’operatività e gli use-case operativi. Gli utenti che prenderanno parte alle attività formative potranno variare da 3 a 10.
Art. 1.3.2 - Documentazione
Il fornitore è tenuto a predisporre tutta la documentazione necessaria, di seguito specificata:
1. Creare e mantenere aggiornati i Manuali utente e Manuali operativi per tutti gli utenti della piattaforma in lingua italiana e inglese, i manuali di supporto all’avvio e migrazione della piattaforma ed ogni altra documentazione necessaria ad assicurare l’utilizzo della piattaforma web (in lingua italiana).
2. Predisposizione dei modelli di documentazione da far approvare al Politecnico di Milano con i quali tracciare le fasi di progetto inerenti (in lingua italiana):
a. Descrizione e architettura implementata;
b. La documentazione comprovante il rispetto dei principi di “privacy by design” e “privacy by default”;
c. Descrizione funzionale della piattaforma web;
d. Descrizione delle interfacce e del sistema di gestione dei contenuti e acquisizione dei MM;
e. Descrizione delle modifiche apportate;
f. Descrizione dei processi implementati;
g. Modelli documenti utilizzati in fase di collaudo
h. I verbali di collaudo/precollaudo.
3. Predisporre i modelli per (in lingua italiana):
a. Gestione dei rischi;
b. Controllo delle variazioni in corso d’opera;
c. Monitoraggio delle variazioni;
d. Gestione dei problemi;
e. Revisioni.
Art. 1.3.3 - Revisione e supporto all’adeguamento dei MM
Il fornitore dovrà supportare il gruppo di ricerca nella revisione e dell’adeguamento dei MM al fine di garantirne la compatibilità con i prototipi in fase di realizzazione.
Art. 1.3.4 - Collaudo
Le attività di verifica e di collaudo sono interamente a carico del fornitore.
Art. 1.3.4.1 - Collaudo del prototipo e delle applicazioni A, B e C
Il Collaudo prevede la verifica del funzionamento della soluzione proposta dall’appaltatore. L’attività di collaudo avverrà durante le fasi di esecuzione del contratto e si suddivide in tre attività distinte:
c. Test funzionali in alcune aziende delle filiere DOP. In questa fase viso l’utilizzo all’estero delle applicazioni B e C deve essere garantita la disponibilità a supportare in remoto (videoconferenza) il gruppo di ricerca all’estero durante le fasi di collaudo.
Nel corso delle attività di collaudo, e successivamente durante l’esercizio dello strumento software, il gruppo di ricerca classificherà; secondo un suo insindacabile giudizio i difetti riscontrati nei prodotti forniti, nelle seguenti categorie:
• Difetti funzionali: Il difetto riscontrato rende non operativa una o più funzionalità del software, o il software non funziona in toto.
• Difetti di sicurezza: il difetto riscontrato non inficia il normale funzionamento del software web, ma non permette allo stesso di operare secondo i requisiti di sicurezza aziendale (ad es. permessi non correttamente assegnati, vulnerabilità, instabilità)
• Difetti di conformità legislativa: l’errore consiste nella non conformità alle norme applicabili al software web/sito web
• Difetti di integrità: il difetto mette a rischio l’integrità dei dati raccolti all’interno del software.
• Difetti non funzionali: errori trascurabili che non hanno un impatto sul funzionamento del software web (ad es. errori grammaticali nel testo, o errori di layout che non bloccano le funzionalità)
• Difetti tecnici: Errori che riguardano il non rispetto delle indicazioni e degli standard tecnici indicati in questo documento.
Il collaudo darà esito negativo in uno dei seguenti casi:
• È stato individuato un difetto funzionale;
• È stato individuato un difetto di Sicurezza;
• È stato individuato un difetto di conformità legislativa;
• È stato individuato un difetto di integrità
• È stato individuato un difetto tecnico sostanziale
Al termine delle prove, sarà redatto un opportuno e dettagliato verbale attestante il corretto svolgimento delle prove di conformità ai requisiti della fornitura.
Nel caso in cui una o più prove diano risultati non soddisfacenti, il Fornitore dovrà provvedere a risolvere tempestivamente gli eventuali inconvenienti in modo tale da consentire il completo superamento delle prove previste entro 15 giorni dal primo collaudo. Nell'ipotesi di inadempienza della fornitura tale da non consentire un esito positivo del collaudo entro 60 giorni dal primo collaudo, la Committenza potrà procedere alla risoluzione immediata del contratto, ai sensi dell'art. 1456 del c.c. applicando una penale pari al 10% del valore della fornitura.
Art. 1.3.4.2 - Requisiti Funzionali durante la fase di collaudo
Nel presente paragrafo vengono delineate le specifiche infrastrutturali della soluzione Software Web che l’aggiudicatario dovrà garantire durante le fasi di collaudo.
Il portale internet dovrà soddisfare i seguenti requisiti tecnologici minimi durante le fasi di collaudo:
1. Infrastruttura tecnologica stabile, performante e sicura.
2. Dimensionamento idoneo per gestire 30 accessi in contemporanea.
3. L’utilizzo di standard aperti (es. Json, Javascript).
4. L’accesso al portale e al sistema di gestione dei contenuti e di acquisizione dei MM attraverso un web browser con un’interfaccia full web senza sia necessario richiedere lo scaricamento in locale sul client di ambienti di runtime esterni. Sulla postazione client non dovrà essere richiesta l’installazione di alcun software specifico al funzionamento del portale né messi vicoli al tipo di dispositivo e/o sistema operativo. I browser da supportare dovranno essere almeno i seguenti (in versione desktop e mobile):
a. Microsoft Internet Explorer/Edge
b. Google Chrome
c. Firefox
d. Safari
5. Il portale, tutte le informazioni in esso contenute dovranno essere adeguatamente protetti mediante l’adozione di opportuni sistemi, conformi alle migliori pratiche applicate e riconosciute.
6. Un meccanismo di tracciamento esteso delle attività eseguite da utenti del sistema di gestione dei contenuti e di acquisizione dei MM, interni ed esterni attraverso registrazioni di sistema (log applicativi).
7. La sicurezza fisica del centro di elaborazione dati nella fase di test e collaudo del prototipo; qualora le risorse hardware utilizzate non siano di proprietà dell’aggiudicatario, l’impresa proprietaria di tali risorse dovrà sottostare a tutti gli obblighi di riservatezza richiesti.
8. Monitoraggio attivo di tutte le componenti software dell’architettura di sistema al fine di ricercare nuove versioni (upgrade) e correzioni (patch).
9. Funzione di salvataggio presente in ogni fase di utilizzo del sistema di gestione dei contenuti e di acquisizione dei MM.
10. L’aggiudicatario dovrà fornire documentazione dettagliata sui sistemi di firewall rete e applicativi, ips, siem, ed altri tool a protezione dell’infrastruttura.
Art. 1.3.5 – Ulteriori condizioni di fornitura
L’aggiudicatario, nel periodo di riferimento del contratto, dovrà garantire opportuna assistenza funzionale tramite gli strumenti e secondo i modi di seguito individuati.
• Help Desk per usufruire dell’assistenza. Le modalità di contatto e risposta verranno definite di comune accordo nella fase preliminare definita all’Art. 1.5. Il servizio di help desk dovrà essere raggiungibile 8 ore al giorno per 5 giorni la settimana e dovrà essere erogato tramite assistenza telefonica o in video conferenza immediata per risolvere rapidamente problematiche tecniche o ottenere supporto informatico. L’aggiudicatario dovrà mettere a disposizione i numeri telefonici tecnici specializzati che garantiscano assistenza Help Desk
I servizi di assistenza e manutenzione devono essere prestati dall’aggiudicatario e saranno comprensivi di:
• manutenzione correttiva: include le azioni volte a garantire una pronta correzione dei malfunzionamenti e il ripristino delle funzionalità, anche attraverso attività di supporto on-site;
• manutenzione evolutiva: comprendente tutte le attività inerenti il costante aggiornamento delle componenti software/firmware del sistema.
Diversamente dalle altre tipologie di richieste, la richiesta di intervento correttivo, rappresenta un evento improvviso che per gravità va gestito in tempi rapidi e con il minimo disservizio sull’operatività del sistema, soprattutto se il guasto è di tipo bloccante. Viene di seguito illustrato il flusso operativo del processo di presa in carico e successiva risoluzione.
Art. 1.3.6 – Supporto alla migrazione
Una volta completato ed approvato il collaudo a seguito dei test nelle aziende il fornitore dovrà supportare la stazione appaltante nella fase di migrazione del tool su server e dominio esterno al fornitore fino al raggiungimento di una completa funzionalità.
Art. 2 - Importo della fornitura
Il prezzo presunto e stimato e non garantito posto a base di gara è fissato in € 213.990,00 (duecentotredicimilanovecentonovanta/00 euro) oltre IVA per l’intera fornitura.
L’importo posto a base di gara è così composto:
- Importo per la fornitura € 111.150,00
- Opzione per la ripetizione servizi analoghi fino a un massimo di € 102.840, 00
I requisiti descritti nell’Art. 1 - Oggetto della fornitura, comprensivi di requisiti minimi inderogabili, eventuali requisiti addizionali che il fornitore avrà inserito nell’offerta tecnica ed i servizi richiesti rientrano nell’importo della fornitura pari a € 111.150,00.
In sede di offerta il fornitore dovrà indicare un costo a giornata per le figure professionali coinvolte, ed il numero di ore lavorate per ogni figura.
L’opzione per la ripetizione di servizi analoghi fa riferimento alla ripetizione delle attività svolte su altre filiere per la realizzazione di nuovi prototipi, per l’adattamento del software a nuove applicazioni e per l’inserimento di ulteriori funzionalità.
Si precisa anche che l’opzione della ripetizione dei servizi analoghi è condizionata anche al reperimento di finanziamenti che ne garantiscano la sostenibilità. Pertanto, è a discrezione del dipartimento DENG avviare o meno tali servizi analoghi.
Sia l’importo per la fornitura che l’importo per la ripetizione di servizi analoghi deve essere comprensivo di tutti gli oneri concernenti la fornitura, che devono, pertanto, intendersi a carico della Ditta offerente.
Il Fornitore:
• formulerà l’offerta avendo preso conoscenza di tutte le circostanze di fatto e di luogo, sia generali che particolari, che possono influire sulla determinazione delle condizioni economiche e che potranno incidere sull’esecuzione delle attività oggetto della fornitura.
• non eccepirà, nello svolgimento delle attività oggetto della fornitura, la mancata conoscenza di condizioni o la sopravvenienza di elementi non valutati o non considerati salvo che tali elementi si configurino come cause di forza maggiore contemplate dal C.C. e non escluse dalla legge.
• avendo tenuto conto di quanto sopra nella formulazione dell’offerta, riterrà quest’ultima complessivamente congrua e remunerativa senza riserva alcuna.
A norma della disciplina vigente (decreti legislativi nn. 50/2016 e 81/08) la Stazione appaltante reputa che non vi siano rischi interferenziali per la sicurezza dei lavoratori dell’aggiudicatario e pertanto non reputa opportuno scomputare dalla base di gara alcun costo sulla sicurezza.
Art. 3 - Termine di esecuzione della fornitura
L’ operatore economico aggiudicatario si impegna ad eseguire la fornitura entro e non oltre 6 mesi dalla stipula del contratto. Per l’esecuzione complessiva della fornitura sono previste le seguenti attività:
1. Fase preliminare (MAX 2 settimane): comprende tutte le attività preliminari all’impostazione del progetto. In questa fase sarà effettuato un incontro tra la stazione appaltante e il team di lavoro ed illustrato quanto è già stato elaborato. L’aggiudicatario dovrà predisporre i modelli preliminari di documentazione e presentare il gruppo di lavoro, verranno definite le scadenze delle diverse fasi progettuali e verrà approvato il paino dettagliato delle attività.
2. Fase di acquisizione del design (MAX 2 settimane): in questa fase verrà presentato quanto già è stato elaborato in termini di MM e Design della piattaforma e verranno definite eventuali correzioni e rielaborazioni di alcune fasi.
3. Fase di progetto (MAX 4 mesi): comprende la predisposizione degli ambienti e delle attività preparatorie all’acquisizione dei MM e alla messa in esercizio. Questa fase include tutte le fasi di collaudo approvazione dello stesso e la formazione. È possibile che in sede di affidamento possa essere definita una scadenza intermedia.
4. Fase di rilascio (MAX 2 settimane): fase in cui verrà rilasciata la versione definitiva del prototipo per permetterne l’installazione su server esterno.
5. Opzione per la ripetizione servizi analoghi: attività che potranno essere svolte nei 12 mesi successivi all’affidamento del bando, qualora il Politecnico di Milano reperisse le risorse finanziarie necessarie.
Art. 4 – Backup dei prototipi realizzati
Il fornitore dovrà realizzare un backup dei prototipi realizzati e collaudati al fine di renderli accessibili alla stazione appaltante per almeno 12 mesi dopo la conclusione delle attività.
Art. 5 - Team di progetto
Il team messo a disposizione dall’aggiudicatario dovrà avere le competenze e esperienze comprovate nell’ambito di progetti di progettazione e implementazione di siti internet, SaaS e software web di calcolo, e dovrà essere esplicitamente indicato prima dell’inizio della fase di avvio dell’esecuzione del contratto tramite la presentazione dei curricola professionali. Il gruppo di lavoro deve essere organizzato da un approccio organizzativo flessibile per rispondere alle esigenze che potranno emergere durante tutta la durata contrattuale.
In considerazione del tipo di attività oggetto del presente capitolato, il gruppo di lavoro dovrà essere composto dai seguenti profili professionali:
a. Analista sviluppatore senior con esperienza di almeno 5 anni su piattaforma enterprise;
b. Sviluppatore backend su linguaggi enterprise (Java EE, .NET o altri) con esperienza di almeno 5 anni su piattaforme enterprise;
c. Sviluppatore frontend web con competenze su: HTML, CSS, javascript su framework di presentation come Angular, Vue o React, con esperienza di almeno 5 anni su piattaforme enterprise;
d. Project manager, con esperienza di almeno 5 anni, per l'organizzazione generale del progetto.
Su espressa richiesta del Politecnico di Milano, tali risorse dovranno essere disponibili e si renderanno operative nei modi e nei tempi che l’aggiudicatario e i Politecnico di Milano decideranno congiuntamente in base alle tempistiche proposte nel piano di attività e diagramma di GANTT offerto in sede di gara.
Art. 6 - Garanzia definitiva per la stipula del contratto
Ai fini della stipula del contratto, l’operatore economico aggiudicatario dovrà prestare, una garanzia, denominata "garanzia definitiva", per l’importo e con le modalità stabilite dall’Art.103 del D.Lgs.50/2016.
La mancata costituzione della suddetta garanzia determina l’annullamento dell’aggiudicazione e la decadenza dell’affidamento.
Art. 7 - Penali
Il fornitore è sempre obbligato ad assicurare la regolarità e la corretta e puntuale esecuzione della fornitura di cui al presente Capitolato nel rispetto delle modalità sopra descritte.
Il fornitore riconosce al Committente il diritto di procedere, anche senza preavviso e con le modalità che riterrà più opportune o anche in contraddittorio, a verifiche e controlli volti ad accertare la regolare esecuzione dei servizi e l’esatto adempimento di tutte le obbligazioni assunte.
A fronte di eventuali inadempienze rilevate nell'esecuzione dei servizi, il Committente provvederà a notificare all’Appaltatore l’accertamento delle stesse e all’applicazione di penalità determinate dalle modalità di seguito descritte, fatto salvo il risarcimento di eventuali maggiori danni:
▪ A fronte del mancato rispetto delle scadenze previste dal presente capitolato, con particolare ma non esclusivo riferimento ai termini previsti in capitolato, potrà essere applicata, per ogni giorno solare di ritardo imputabile all’appaltatore, una penale pari allo 0,01% (zerovirgolazerouno per cento) del valore della fornitura.
▪ Nel caso in cui l’appaltatore non fosse in grado di implementare la totalità di quanto previsto dall’Offerta Tecnica presentata, potrà essere applicata una penale pari al 10% (dieci per cento) del valore complessivo della fornitura. Inoltre, la Committenza si riserva in questo caso il diritto di rescindere il contratto senza alcun onere ed eventualmente di procedere per danni nei confronti dell’Appaltatore.
▪ Fallimento di collaudi e di verifiche di conformità: nel caso in cui la medesima prova di collaudo dia esito negativo (prova fallita), sarà applicata una penale pari allo 0,1% (zerovirgolauno per cento) del valore della fornitura per ciascuna prova fallita oltre la prima.
Tutte le penali verranno applicate previo contraddittorio con l’Appaltatore, con la sola formalità della contestazione scritta dell’inadempienza all’Appaltatore, con termine di 5 giorni lavorativi dalla data di ricevimento della stessa per eventuali difese scritte da parte di quest’ultimo.
Il Committente si riserva, al raggiungimento di penali per un importo pari 10% (dieci per cento) dell’ammontare del contratto, indipendentemente da qualsiasi contestazione, di procedere alla risoluzione del rapporto, ai sensi dell'art. 1456 C.C., con PEC, fatte salve le penali già stabilite e l'eventuale esecuzione in danno del gestore inadempiente, salvo il risarcimento per maggiori danni.
Le sanzioni pecuniarie di cui sopra verranno fatturate dal Politecnico di Milano e, qualora non liquidate a scadenza, l’importo verrà prelevato direttamente dalla garanzia definitiva, con conseguente obbligo di reintegro.
Art. 8 - Inadempimenti contrattuali e risoluzione del Contratto
Il Politecnico di Milano, in qualità di committente, si riserva la facoltà di disporre la risoluzione del contratto, previa diffida ad adempiere ai sensi degli art. 1453 e 1454 del C.C., in caso di inadempimento dell’appaltatore anche di uno solo degli obblighi previsti dal presente contratto, salvo in ogni caso il risarcimento del danno.
Il contratto inoltre potrà essere risolto di diritto, ai sensi dell’Art. 1456 del C.C., allorché il totale delle penali accumulate superi il 10% del costo dell’intera fornitura, salvo in ogni caso il risarcimento del danno.
Resta tuttavia espressamente inteso che in nessun caso il Fornitore potrà sospendere la prestazione dei servizi e/o forniture.
È espressamente inteso che in caso di perdita dei requisiti di cui all’art. 80 del D. Lgs. n. 50/2016 e nei casi previsti dai patti di integrità il Politecnico di Milano si riserva la facoltà di risolvere il contratto e si riserva il pagamento in tal caso del corrispettivo pattuito solo con riferimento alle prestazioni già eseguite e nei limiti dell’utilità ricevuta.
In caso di risoluzione del contratto si procederà all’incameramento della cauzione definitiva ove richiesta o, in alternativa, l’applicazione di una penale in misura non inferiore al 10 per cento del valore del contratto.
Il Politecnico di Milano può inoltre risolvere il contratto nei casi e con le modalità previste dall’art.108 del D.Lgs. 50/2016.
Art. 9 - Recesso
Il Politecnico di Milano può inoltre recedere dal contratto nei casi e con le modalità previste dall’art.109 del D.Lgs.50/2016.
Art. 10 - Modalità di presentazione delle fatture e pagamento
La fattura potrà essere trasmessa solo a seguito di esito positivo del collaudo definitivo in conformità a quanto previsto dall’art. 4.
Le fatture dovranno essere trasmesse in forma elettronica, secondo il formato di cui all’allegato A “Formato della fattura elettronica” del DM n.55/2013, indirizzandola al Codice Univoco Ufficio riportato nella presente RDO.
Oltre al “Codice Univoco Ufficio” che deve essere inserito obbligatoriamente nell’elemento “Codice Destinatario” del tracciato della fattura elettronica, dovranno altresì essere indicate nella fattura anche le seguenti informazioni.
Informazione | Elemento del tracciato fattura elettronica |
Codice Unitario Progetto (se indicato in RDO) | <CodiceCUP> |
Codice Identificativo Gara | <CodiceCIG> |
Codice di progetto LIFE | LIFE 16 ENV/IT/000225 – LIFE TTGG |
ORDINE (se indicato): dovrà essere indicato l'identificativo ID_DG che verrà comunicato in sede di stipula | <Dati Generali><DatiOrdineAcquisto> |
CONTRATTO (se indicato): in caso di riferimento a contratto, dovrà essere indicato il numero di protocollo/repertorio che verrà comunicato in sede di stipula | <Dati Generali><DatiContratto> |
NOTE CREDITO (se indicato): dovrà essere indicato il numero della fattura trasmessa | <Dati Generali><DatiFattureCollegate> |
La compilazione e sottoscrizione dell’autocertificazione inerente la dichiarazione di regolarità del D.U.R.C. e la tracciabilità dei flussi finanziari dovrà precedere l’emissione della fattura.
La fattura sarà respinta tramite il Sistema di Interscambio in caso di mancato ricevimento della predetta documentazione.
Il pagamento avverrà entro 30 giorni dalla data di ricezione della fattura, previo accertamento della prestazione da parte del direttore dell'esecuzione del contratto (DEC).
L’operatore economico può chiedere anticipazione del prezzo, come previsto dall’art.35 punto 18 del D.Lgs.50/2016.
L'erogazione dell'anticipazione è subordinata alla costituzione di garanzia fideiussoria bancaria o assicurativa di importo pari all'anticipazione maggiorato del tasso di interesse legale applicato al periodo necessario al recupero dell'anticipazione stessa secondo il cronoprogramma della prestazione.
Art. 11 - Divieto di cessione del contratto
È fatto divieto assoluto di cedere a terzi l’appalto.
Qualsiasi cessione dell’appalto è nulla nei confronti del Concedente e comporta l'immediata revoca dell’appalto e la perdita della cauzione definitiva, fatto salvo ogni ulteriore risarcimento dei danni eventualmente arrecati al Politecnico di Milano.
Art. 12 - Riservatezza
Il Fornitore si impegna a conservare il più rigoroso riserbo in ordine a tutta la documentazione fornita dal Politecnico di Milano.
Il Fornitore si impegna altresì a non divulgare a terzi e a non utilizzare per fini estranei all’adempimento dell’accordo stesso procedure, notizie, dati, atti, informazioni o quant’altro relativo al Politecnico di Milano e al suo know-how.
Il Fornitore si impegna altresì a restituire al Politecnico di Milano, entro 10 giorni dall’ultimazione delle attività commissionatele tutti gli atti ed i documenti alla stessa forniti dalla committente ed a distruggere, ovvero rendere altrimenti inutilizzabili, ogni altro atto.
Eventuali violazioni commesse dal Fornitore sulle disposizioni di cui al presente paragrafo saranno sanzionate ai sensi della normativa vigente in materia.
Art. 13 – Proprietà intellettuale
La proprietà intellettuale del software web, dei prototipi, dei MM e delle formule in essi contenute, è del Gruppo di ricerca rappresentato dalla stazione appaltante, sia che essi siano sviluppati dalla società selezionata o precedentemente sviluppati dal gruppo di ricerca.
Art. 14 - Tracciabilità dei flussi finanziari
Al fine di assicurare la tracciabilità dei flussi finanziari finalizzata a prevenire infiltrazioni criminali, il Fornitore assume tutti gli obblighi di tracciabilità dei flussi finanziari di cui alla legge 136/2010.
Il fornitore si impegna inoltre a produrre, su richiesta della Stazione appaltante, documentazione idonea per consentire le verifiche di cui all’art. 3 comma 9 della legge 136/2010.
A pena di risoluzione del contratto, tutti i movimenti finanziari relativi alla fornitura devono essere registrati su conto corrente dedicato e devono essere effettuati esclusivamente tramite lo strumento del bonifico bancario o altri strumenti previsti dalla legge 136/2010, salvo le deroghe previste dalla legge stessa.
Art. 15 - Normativa anticorruzione
Il fornitore, firma digitalmente il presente capitolato, dichiarando contestualmente quanto segue.
1) RAPPORTI DI PARENTELA
Il Fornitore dichiara che non sussistono rapporti di parentela, affinità, coniugio, convivenza tra i titolari e i soci dell’azienda e il Rettore, Prorettori, Prorettori delegati dei Poli territoriali, Direttore Generale, Dirigenti, Componenti del Consiglio di Amministrazione, i Direttori di Dipartimento, Presidi di Scuola, visibili all’indirizzo xxxx://xxx.xxxxxx.xx/xxxxxx/, RUP della presente procedura.
2) TENTATIVI DI CONCUSSIONE
Il fornitore si impegna a dare comunicazione tempestiva alla Stazione appaltante e alla Prefettura, di tentativi di concussione che si siano, in qualsiasi modo, manifestati nei confronti dell’imprenditore, degli organi sociali o dei dirigenti di impresa.
Il predetto adempimento ha natura essenziale ai fini della esecuzione del contratto e il relativo inadempimento darà luogo alla risoluzione espressa del contratto stesso, ai sensi dell’art. 1456 del c.c., ogni qualvolta nei confronti di pubblici amministratori che abbiano esercitato funzioni relative alla stipula ed esecuzione del contratto, sia stata disposta misura cautelare o sia intervenuto rinvio a giudizio per il delitto previsto dall’art. 317 del c.p.
3) CONOSCENZA DEL CODICE COMPORTAMENTO DEI DIPENDENTI PUBBLICI DEL POLITECNICO DI MILANO E PIANO PREVENZIONE DELLA CORRUZIONE DI ATENEO
Il fornitore dichiara di conoscere il Codice di Comportamento dei dipendenti pubblici del Politecnico di Milano e il Piano Triennale di Prevenzione della Corruzione dell’Ateneo, reperibili all’indirizzo:
xxxx://xxx.xxxxxx.xx/xxxx-xx-xxxxxxxx/xxxxxx/xxxxxxxxxxxxxxx-xxxxxxxxxxx/xxxxx-xxxxxxxxx/
L’appaltatore ha l’obbligo di rispettare e di divulgare all’interno della propria organizzazione il Codice Etico e di Comportamento del Politecnico di Milano per tutta la durata della procedura di affidamento e del contratto.
Fatti salvi gli eventuali altri effetti, l’inosservanza delle norme e/o la violazione degli obblighi derivanti dal codice di comportamento dei dipendenti pubblici di cui all’art. 54 del D.Lgs. 165/2001 o al Codice Etico e di Comportamento del Politecnico di Milano comporta la risoluzione del presente contratto ai sensi dell’art.1456 del c.c.
4) EX DIPENDENTI
Il Fornitore dichiara di non avere concluso contratti di lavoro subordinato o autonomo e/o di non aver attribuito incarichi ad ex dipendenti che hanno esercitato poteri autoritativi o negoziali per conto dell’Università per il triennio successivo alla cessazione del rapporto e si impegna a non stipularli nel successivo triennio.
Art. 16 - Utilizzo del nome e del logo del Politecnico di Milano
Il Politecnico di Milano non potrà essere citato a scopi pubblicitari, promozionali e nella documentazione commerciale né potrà mai essere utilizzato il logo del Politecnico di Milano se non previa autorizzazione da parte del Politecnico stesso. Le richieste di autorizzazione possono essere inviate a xxxxxxxxxxxxx@xxxxxx.xx.
Art. 17 - Norme di riferimento
Per tutto quanto non espressamente previsto dagli atti e documenti di gara si fa riferimento al D. Lgs.50/2016 e al Codice Civile.
Art. 18 - Foro competente
Per ogni effetto del contratto, si riconosce per ogni controversia la competenza del Foro di Milano.
Art. 19 - Trattamento dati
Ai sensi e per gli effetti del Regolamento UE n. 679/2016, le Parti così come individuate, denominate e domiciliate dal presente contratto, in qualità di autonomi Titolari del trattamento, dichiarano reciprocamente di essere informate e di acconsentire, tramite sottoscrizione di questo documento, che i dati personali raccolti e considerati nel corso dell’esecuzione del presente contratto saranno trattati esclusivamente per le finalità previste dal contratto stesso ed in ottemperanza delle misure di sicurezza necessarie per garantire la loro integrità e riservatezza.
Le Parti, in qualità di Titolari autonomi del trattamento, si impegnano a raccogliere i dati degli interessati per le rispettive finalità rispettando il principio di minimizzazione e di consenso informato. L’eventuale utilizzo dei dati per finalità ulteriori è condizionato alla manifestazione di espresso consenso specifico da parte dell’interessato.
In caso di servizi che richiedano il trasferimento di dati personali dal Politecnico al Fornitore o la raccolta di dati personali da parte del Fornitore nell’ambito dello svolgimento del servizio, il Fornitore verrà nominato all’avvio dei servizi dal Committente con apposito atto negoziale ai sensi dell’art. 28 e seguenti del GDPR “Responsabile del trattamento” in relazione alle attività connesse alla esecuzione del presente contratto.
Le Parti di impegnano, inoltre, ad escludere la diffusione dei dati raccolti in Paesi extra UE e/o Organizzazioni internazionali.
Art. 20 - Responsabile del procedimento
Il Responsabile Unico del Procedimento di gara è il Xxxx. Xxxxxx Xxxxxx.
Art. 21 - Contatti del Punto Ordinante
Per eventuali informazioni è possibile contattare il Call Center del Politecnico di Milano, telefono 00 0000 0000 – 000 00 0000, email xxxxxxxxxx@xxxxxx.xx, dalle ore 8.00 alle ore 19.00 dei giorni feriali e il sabato dalle ore 8.00 alle ore 13.00.
Eventuali richieste di chiarimenti, in ordine al contenuto del Bando di gara, del presente Capitolato e del Disciplinare di gara potranno essere formulate esclusivamente per via telematica attraverso la funzione comunicazioni sulla piattaforma di gara Sintel.
Art. 22 - Accesso agli atti
In caso di richiesta di accesso agli atti, come previsto dal Regolamento di Ateneo, emanato con Decreto del Direttore Generale Rep. n. 3418 Prot. n. 40374 del 18/12/2013, verrà applicato il tariffario approvato dal Consiglio di Amministrazione il 17/12/2013 visibile al seguente indirizzo:
xxxx://xxx.xxxxxxxxx.xxxxxx.xx/xxxxxx/xxxxxxx/xxxx.xxx/000/Xxxxxxxxxx_xxxxxxx_xxxxxxxxx.x df
Art. 23 - Spese contrattuali
Tutte le spese, diritti e imposte, inerenti e conseguenti alla sottoscrizione del contratto, sono a carico dell'aggiudicatario.
Milano, lì 30/07/2021
IL RESPONSABILE UNICO DEL PROCEDIMENTO
Xxxx. Xxxxxx Xxxxxx