Allegato tecnico. Requisiti di sistema software IMAGACT-MED. Architettura. Gestione utenti

Transcript

1 G500 - avviso per verifica unicità del fornitore per affidamento ex art. 63 c. 2 lett. b) p. 3 d.lgs. 50/2016 di affidamento della fornitura del servizio concernente la Realizzazione di sistemi distribuiti di processi di formazione e gestione delle basi di dati dedicate alle relazioni tra rappresentazioni 3D dell azione e la loro categorizzazione multilingue Allegato tecnico Obiettivo generale del contratto Progettazione, realizzazione, prototipazione, testing e ottimizzazione di un infrastruttura di sistema dedicata alla realizzazione di messaggi multimediali in ambiente collaborativo, alla realizzazione di un database multimediale e relativo sistema di query. Requisiti di sistema software IMAGACT-MED Il sistema software da sviluppare nell ambito del progetto IMAGACT-MED richiede di supportare diversi requisiti architetturali, di deployment e di interazione con utenti e altri sotto-sistemi software. Il sistema software sarà definito, in relazione ai requisiti di base identificati di seguito. La definizione della specifica finale sarà concordata tra il contraente e il committente nelle fasi di analisi durante il primo anno del progetto. Architettura L architettura deve essere disegnata per il rilascio in ambiente cloud. Le prime versioni saranno testate in ambienti cluster/grid privati, ma deve essere possibile, a fine progetto fare deployment su cloud come AWS; a tale scopo si seguirà un design secondo il paradigma SOA (Service Oriented Architecture). I servizi dovranno essere in grado di interfacciarsi con i sistemi di rendering 3D e video sviluppati da MICC, orchestrarne il lancio e monitorarne l esecuzione. Si richiede che siano utilizzati linguaggi e strumenti informatici multipiattaforma. Non dovranno esistere restrizioni nelle licenze delle tecnologie e degli strumenti utilizzati tali da impedire o limitare la commercializzazione del prodotto finale o di una o più componenti. Si richiede che l architettura sviluppata sfrutti strumenti e tecnologie di larga diffusione, gratuite ed open-source. Gestione utenti Il sistema dovrà prevedere l esistenza di diversi tipi di utenti con diversi livelli di accesso, da gestire con il massimo livello di sicurezza e usando protocolli sicuri e criptati data la necessità di trattare

2 dati in ambito medico. Per ogni tipo di utente verranno sviluppate specifiche tipologie di interfacce, disegnate in modo tale da ridurre ogni tipo di interazione richiesta per lo svolgimento dello specifico compito secondo le migliori pratiche di disegno HCI. Le interfacce andranno disegnate dovranno essere responsive per supportare diverse tipologie di dispositivi, da specificare secondo il tipo di utenti e le loro necessità operative (es. interfacce eseguibili su dispositivi mobili e non per gli utenti finali, su dispositivi tablet e PC per i medici, su C per gli amministratori di sistema, etc.). Le interfacce dovranno avere look e feel coerente e reattivo per le principali piattaforme (Linux/Windows e Mac su PC; ios e Android su dispositivi mobili, eventualmente usando diversi tipi di browser web per ogni piattaforma). Interfacce Tra le principali interfacce previste, cui eventualmente potranno aggiungersene altre durante l analisi dei requisiti e lo sviluppo del sistema si possono citare: Interfaccia di scripting per il medico: deve consentire la formulazione di descrizioni di azioni e sequenze video secondo ontologia e linguaggio visuale sviluppato dai partner del progetto (DILEF-LABLITA), consentendo anche l aggiunta di elementi testuali e visuali da librerie di dati multimediali già presenti nel sistema. L interfaccia deve essere eseguibile in browser web, sviluppata usando HTML5 e framework Javascript come jquery, React, AngularJS, Angular; etc. Il sistema deve prevedere l uso di drag&drop per la creazione e visulizzazione di storyboard. Gli script creati devono essere versionati e associati a diversi utenti; ogni utente deve poter definire il livello di distribuzione del materiale da lui creato. L interfaccia deve consentire di esaminare e validare gli storyboard creati da filmmaker, o cercare ed esaminare lavori precedentemente sviluppati, usando metadati ed eventualmente descrittori di contenuti visuali secondo il paradigma content-based multimedia indexing. Interfaccia di creazione storyboard per filmmaker: deve consentire la creazione di storyboard usando elementi multimediali presenti nel sistema o consentire in alternativa l importazione di asset grafici. Ogni storyboard deve essere versionabile, e con diversi livelli di accessibilità definibili dal filmmaker. Interfaccia utente finale: deve consentire il consumo di video e animazioni 3D su dispositivi mobili e PC, usando se possibile browser per la visualizzazione allo scopo di non obbligare l installazione di App specifiche. Riguardo i video, questi dovranno essere visualizzati sulle più importanti piattaforme attualmente sul mercato: o browser moderni per PC (Microsoft Windows, GNU/Linux, Mac OSX) o browser per Android o browser per ios Predisposizione di un interfaccia di gestione controllo dei pazienti, per consentire al medico di controllare se le indicazioni terapeutiche sono state controllate ed eventualmente eseguite. Gli editor di script e storyboard devono gestire messaggi multilingui, consentire validazione del lavoro nell ambito di workflow disegnabili dall amministratore di sistema, consentire il design e

3 descrizione di azioni specificando vincoli temporali per i singoli elementi e per il risultato complessivo dei prodotti. Tutti gli asset presenti nel sistema o generati con queste interfacce dovranno essere annotabili e ricercabili mediante inserimento di metadati specifici in ambito medico o del dominio del problema. I dati di tipo testuale dovranno essere resi disponibili per servizi di traduzione esterna, e consentire la gestione del workflow di queste traduzioni, fino al livello di validazione ed accettazione dei risultati. In generale per ogni tipo di asset dovrà essere possibile definire un workflow che lo gestisca dal momento della produzione fino alla sua accettazione, e quindi riuso. Dato che alcune tipologie di utenti non avranno specifiche conoscenze nella creazione di script, le interfacce dovranno privilegiare l aspetto di interazione visuale su quello più tradizionale come form e menu. Entrambe le tipologie di interfacce dovranno essere disegnate per essere rispondenti alla grammatica che verrà sviluppata da DILEF-LABLITA per la descrizione di azioni. Infrastruttura e workflow Il sistema dovrà supportare la creazione di workflow per la creazione e gestione di tutti i documenti (multimediali, metadati, script, etc.) creati, garantendone riservatezza e gestendo i livelli di accesso definiti dai vari utenti. Il sistema dovrà fornire funzioni di accesso al pubblico e distribuzione di diversi artefatti come animazioni 3D, video a diverse risoluzioni da fornire in streaming e progressive download, descrizioni di azioni 3D per sistemi di riconoscimento di azioni mediante Kinect, etc. Data la riservatezza dei dati, sarà compito dell infrastruttura fornire la pubblicazione dei materiali per gli utenti finali, da dare in forma anonima, pubblica o protetta da accesso controllato. Per quanto riguarda l implementazione del workflow di pubblicazione questa dovrà essere realizzata a livello di Business Logic applicativa. Dovranno essere utilizzate tecnologie per il Business Process Management quali jbpm (jbpm.org) per la definizione rigorosa delle politiche di gestione documentale e la loro conversione in codice. Per la gestione dei dati si dovranno usare diverse architetture e piattaforme come: MySQL, PostgreSQL, MariaDB o altri database relazionali per memorizzare tutti i tipi di dato testuale e per associare i dati testuali ai video. Lucene / SOLR per l indicizzazione di dati testuali. Questi strumenti saranno utilizzati per rendere la ricerca il più veloce e flessibile possibile. Alfresco Community Edition come piattaforma per il content management. Sarà utilizzata per immagazzinare in modalità versionata i contenuti multimediali prodotti. Integrazione con componenti software per rendering Il sistema dovrà integrarsi e monitorare le componenti software sviluppate dal MICC per il rendering di video e animazioni 3D create per gli utenti finali. Oltre a queste dovrà gestire anche la descrizione di azioni per il loro riconoscimento basato su Kinect, e gestire la comunicazione con le applicazioni sviluppate per il riconoscimento di azioni e loro aderenza alle specifiche definite dai medici, così da poter definire un protocollo di controllo dei pazienti in remoto. Dovrà essere possibile inserire e ricercare descrittori visuali e di moto generati dai sistemi del MICC; allo scopo di fornire funzioni di approximate nearest neighbor search di oggetti

4 multimediali, per consentire un più facile riuso di asset multimediali da parte di medici e filmmaker. Dato il costo computaizonale del rendering e la necessità di distribuirlo in grid, il sistema dovrà consentire il monitoraggio di sistemi distribuiti con definizione di workflow appropriati per la gestione di eventuali problemi (es. interruzione di rendering e loro riavvio). Pratiche di sviluppo e ingegneria del software L attività di sviluppo del software sarà portata avanti seguendo le principali buone pratiche come: versionamento del codice su sistemi di Source Code Management testing integrato a livello di unità di test e di integrazione con sistemi per il test di interfacce come Selenium bug tracking utilizzo di un modello di sviluppo basato su gitflow o equivalente, ovvero che permetta di distinguere i rami di sviluppo, da quelli di produzione, hotfix e releasing. Gli sviluppatori avranno la facoltà di creare un qualunque numero di rami per implementare le feature richieste o per correggere bug non bloccanti, cioè bug che non richiedano un intervento urgente sull applicazione/servizio in produzione. realizzazione di due ambienti ( produzione e staging ) con le stesse caratteristiche architetturali, ma che abbiano implementate funzionalità diverse: o produzione: funzionalità stabili o staging: funzionalità da testare L ambiente di staging sarà accessibile solo ad un numero di utenti ristretto e selezionato dal consorzio. Requisiti del fornitore Si richiede che il fornitore fornisca evidenza di esperienze riguardanti: l archiviazione documentale e multimediale su repository documentale Alfresco; si richiede che i progetti di questo tipo abbiano previsto la personalizzazione dello strumento; la personalizzazione di repository documentali basati su Alfresco sia almeno quinquennale; il trattamento e la formazione di basi di dati multilingui associate a contenuti multimediali la realizzazione di interfacce web di gestione e fruizione di basi di dati multilingui associate a contenuti multimediali la realizzazione di ambienti collaborativi per la creazione, gestione e fruizione di dati in sistemi distribuiti in situazione di sicurezza e riservatezza delle informazioni trattate Si richiede che il fornitore dimostri competenze sui seguenti argomenti: gestione sicura delle informazioni in riferimento alla proprietà intellettuale, alla riservatezza e alla profilazione degli utenti coinvolti a garanzia della privacy in tutte le fasi dello sviluppo Si richiede che il fornitore sia disponibile a sottoscrivere un accordo di riservatezza e non divulgazione delle conoscenze e tecnologie acquisite e sviluppate durante il periodo di lavorazione del progetto e per 5 anni successivi alla conclusione, in previsione di una potenziale brevettazione di una o più componenti.

5 Si richiede che il fornitore metta a disposizione del committente una piattaforma di visualizzazione e scaricamento del codice sorgente prodotto, sia durante lo sviluppo del progetto sia per 3 anni successivi alla fine del progetto. Si richiede che il fornitore metta a disposizione del committente una piattaforma di issue e feature tracking che permetta al committente di monitorare costantemente lo stato di avanzamento delle correzioni dei problemi e delle implementazioni delle feature accettate. Si richiede che il fornitore metta a disposizione almeno le seguenti figure professionali per i 2 anni di durata prevista del contratto e comunque fino alla fine del progetto: 1 capo progetto con più di 10 anni di esperienza nella gestione della produzione di applicazioni web in ambito multilingue 1 sviluppatore con più di 5 anni di esperienza nello sviluppo di applicazioni web in ambito enterprise 1 sviluppatore con più di 2 anni di esperienza nello sviluppo di applicazioni web in ambito enterprise Si richiede che il fornitore produca i risultati attesi nei tempi indicati nella convenzione IMAGACT- MED stipulata tra UNIFI-DILEF e Regione Toscana.