Meeting SP7 - 16-10-2013

Agenda

14:30 - connessione e saluti, discussione ordine dei punti all'OdG
16:30 Chiusura lavori

Presenti

IREA: Basoni, Bordogna, Carrara, Fugazza, Oggioni, Pavesi, Pepe
ISMAR: Bastianini, Menegon, Minuzzo, Sarretta, Vianello
OGS: Giorgetti, Partescano

Ordine del Giorno

stato dei WP1, WP2, WP4
azioni per la progettazione e sviluppo dei prototipo
varie

Links utili

Macrorequisiti: http://sp7.irea.cnr.it/svn/SP7/WP1/AZ1/requisiti/macrorequisiti_panel.pdf
Valutazione macrorequisiti per gap analysis: http://sp7.irea.cnr.it/svn/SP7/WP4/AZ1/ValutazioneMacrorequisiti_CriteriMultipli.xlsx

Minute

Introduzione di Paola Carrara sugli obiettivi della riunione: fare il punto delle attività, partendo dalla conclusione di WP1_AZ1, andando verso il WP4, e, possibilmente, avviare la scelta del prototipo; sulla base dei documenti di riferimento (vedi link). Ringraziamenti ai partecipanti al lavoro (Pavesi, Sarretta, L'Astorina, Giorgetti, Bordogna).
Introduzione da parte WP4 leader (Oggioni): ribadisce l'obiettivo della riunione e richiama i documenti: 1) sintesi del lavoro di WP1 per quanto riguarda i macrorequisiti e le valutazioni del panel; 2) prima valutazione dei macrorequisiti sulla base di criteri diversi da quelli del panel.
Punto su Macrorequisiti e WP1 (Sarretta): il documento è di sintesi del lavoro di interviste, catalogazione e strutturazione dei requisiti (compresi strumenti di supporto informatico). a partire dall'archivio dei requisiti sono stati sintetizzati 6 macrorequisiti, descritti, semplificati e presentati al panel (sotto la direzione di Fabio Trincardi) e sono state assegnate delle priorità da 1 a 6. Il panel ha aggiunto anche dei commenti, per esemplificare la propria visione. Si è aggiunto anche una sorta di caso d'uso per il caso specifico della pesca sostenibile. E' stato precissato che questo ranking visto dall'alto deve essere raccordato con tempistiche e costi. Commenti al ranking dei macrorequisiti: 1) di base era prevedibile ci venisse rischiesta, anche se è impegnativo per la prototipazione (Oggioni); 2) condivisione di disegni sperimentali, con concordanza prima di condurre le ricerche; ma scambio di informazioni anche dopo le campagne, come commento anche le pubblicazioni scientifiche, ma anche prodotti della ricerca in genere da archiviare e distribuire; 3) gestione dei dati real-time e near-real-time, relazioni con SP5 e importanza strategica per l'intercalibrazione e quindi corredo con MD significativi, la Direzione di RITMARE considera il real-time se questo dato è accessibile anche fuori dalla comunità (così la scelta relativa al real-time). Questo coinvolge anche aspetti di data policy; 4) aggrega requisiti requisiti di visualizzazione avanzata, non solo mappe, ma anche visioni dinamiche, 3D, multimediali, anche per utenti diversi dai ricercatori. non presenti quindi nei portali standard, rendere dinamico l'accesso a informazioni statiche intrinsecamente, ma navigabili; 5) e 6) riguardano più un supporto dell'infrastruttura per i partner di RITMARE, servizi di supporto informatico e infrastrutturale per fornire servizi interoperabili (compresa la metadatazione), non solo kit per la deploy di servizi e persone di supporto, ma anche documentazione in 6) le richieste sono più tecnologiche HW e SW per elaborazione e calcoli pesanti (grid computing) magari condivise in rete e paralelizzate, o back-up sicuro dei dati, questo ovviamente richiede investimenti anche economici. Macrorequisito aggiunto dal panel usare il caso della pesca e della risorsa ittica come esempio per unificare una gestione attualmente altamente frammentata. Oggioni aggiunge che forse questa introduzione è dovuta ai problemi relativi allo sfruttamento del mare profondo. Sarretta: insiste sulla frammentarietà e ruolo crescente del CNR in questo ambito a livello internazionale.Domanda di Vianello sul tipo di visualizzazione se desktop o in linea. L'infrastruttura dovrebbe essere generalmente in linea (Sarretta e Oggioni), e comunque ci sono i dettagli nei requisiti (Carrara)
Valutazione macrorequisiti in base a criteri multipli (Bordogna): obiettivo: caratterizzare i macrorequisiti rispetto a diversi criteri che possono essere poi usati per l'ordinamento. Step: 1) selezione criteri; 2) aggregazione criteri per soddisfare diversi obiettivi (i.e. progettazione prototipo; progettazione infrastruttura). Schema di caratterizzazione dei macrorequisiti secondo criteri di rilevanza elicitati partendo da quelli usati da Pavesi e Sarretta usati per il clustering dei requisiti per aggregazione intermedia e macro a partire dai singoli . i criteri di rilevanza (Utilità del singolo requisito, Rappresentatività del singolo requisito, Priorità del macrorequisito come da panel, Corposità del macrorequisito tramite n° intermedi confluenti), come rilevato (vedi 3° foglio del file xls di riferimento). Utilità è calcolata in base al peso del benificiario qualificato in base al gruppo di riferimento (UO, AZ, WP, SP...), il peso del beneficiario può essere riassegnato. La rappresentatività è ottenuta associando alla delega dell'intervistato un peso diverso. Lo stesso si può fare per l'importanza (per esempio la corposità può essere 0). Passando al secondo foglio si ottiene l'ordinamento. (Prove di riordinamento cambiando i valori associati ai criteri di importanza). Bisogna osservare (Carrara) che il caso d'uso sulla pesca viene sempre 0, perché non c'era nei macrorequisiti né in quelli singoli, anche perché è in realtà è uno use case e non un vero requisito. Questo strumento è utile ad un'esplorazione dei macrorequisiti (Oggioni)e, per WP4, aiutarci a definire scenari ed interesse nei i diversi casi d'uso. Si sta facendo un lavoro analogo per le soluzioni con aspetti diversi da questi (quelli riportati nel documento gap analysis). Anche modificando i criteri non c'è una rivoluzione del ranking rispetto a quello creato dal panel (Carrara), questo è molto positivo, quindi la comunità è sensibile, come il panel allo stesso tipo di necessità. Le funzionalità di base (Oggioni) sono sempre molto in alto, anche modificando i pesi dei criteri. Domanda di (Menegon): i beneficiari non ci sono però in tutti i requisiti. Risposta (Bordogna): sono state fatte delle assunzioni, se nel DB non c'era nulla, in mancanza il beneficiario è l'unità rappresentata dal beneficiario (quindi lui medesimo), raddoppiato per beneficiari multipli con massimizzazione. Ci sono poi persone che non avevano ruoli definiti nel DB.
Sulla base di questi strumenti cominciare a definire un caso d'uso (Oggioni): cosa facciamo nel prototipo implementiamo il caso d'uso proposto dal panel (Carrara), Bordogna commenta che non possiamo classificarlo rispetto a l'analisi condotta perché non è stato espresso nelle interviste. Pepe: dubbi sulla maturità della comunità espressione del caso d'uso. Sarretta: indicazione su cosa presentare all'interno dell'infrastruttura, il primo caso d'uso deve essere maturo dal punto di vista dei dati forniti dal dominio che ci permetta di sperimentare le funzionalità; paura che non ci siano dati os semantica dei dati sufficienti, non come prototipo iniziale perché rischioso, e quindi lo metterei più avanti come test. Giorgetti condivide le perplessità.

Oggioni chiede quante interviste per SP2. Una: Mirto e Fiorentino insieme (Carrara), solo che le cose che hanno detto non erano particolarmente focalizzati sulla pesca. Sarretta ricorda che avevano problema di reperimento dati. Carrara chiede se IAMC ha espresso qualcosa di interessante a livello soluzioni e dati. Oggioni ricorda che I-marine offre soluzioni in questo ambito. Sarretta: è utile avere un caso tematico, o è più utile cercare di decidere cosa implementare fra le funzionalità, in modo indipendente dal caso tematico.