Si intende che ogni esaminando, come previsto da Agile (collective ownership) ha la responsabilità dell'intero progetto, pertanto deve essere in grado illustrare le tecnologie principali impiegate ad ogni livello architetturale dell'applicazione. Ad esempio, alla domanda "l'utente clicca su questo bottone. Cosa succede?" si deve essere in grado di aprire il codice e capire che, ad esempio, viene invocato un certo metodo di un centro controller Angular; poi, leggendo il codice, mi deve saper dire  che viene chiamato un service, il quale crea la richiesta HTTP con il Json come Payload ed effettua la chiamata REST; a questa richiesta risponde il server con l'endpoint E, deployato da qualche parte e implementato come Spring Controller etc etc.Chi ha lavorato non deve preoccuparsi di questa tipologia di domanda, perché il codice non va studiato prima; basta leggerlo insieme in sede d'esame. Chi ha impiegato il proprio effort solo su certi livelli architetturali (e.g. solo frontend) è plausibile che abbia qualche difficoltà a navigare il codice degli altri livelli architetturali, ma il requisito minimo è che conosca QUALI altri livelli architetturali esistono ed entrano in gioco, quali tecnologie sono impiegate e dove andare a cercare il codice che viene eseguito.In pratica, è come simulare un'attività di debugging su un progetto di cui si è responsabili: il codice probabilmente non l'abbiamo scritto tutto noi, ma dobbiamo essere in grado di seguirne l'esecuzione e capire cosa sta succedendo.Di queste domande deve preoccuparsi solo chi non ha lavorato, perché non sa dove mettere le mani e non sa spiegare cosa sta succedendo al livello tecnico richiesto.Manuel2016-07-13 19:19 GMT+02:00 Leo De laurentiis < " target="_blank"> >:Gentile Professor Cantone,ci è sorto un dubbio riguardo la frase: "-Navigare nel codice, in ogni sua parte. Sebbene sia naturale che ogni sviluppatore si sia dedicato a sviluppare solo una parte del progetto assegnato al gruppo, ciascuno membro deve aver fatto almeno un "round-trip" (dalla GUI alla persistenza, passando per le chiamate REST al bus)."Per "round-trip" Lei intende semplicemente che ogni membro del gruppo deve conoscere tutto il codice, anche di porzioni non sviluppate in prima persona? Oppure per "round-trip" Lei intende che ogni membro del gruppo deve aver implementato in prima persona almeno una porzione di codice per ogni "sezione" (dalla GUI alla persistenza, passando per le chiamate REST al bus)?Distinti Saluti.Il giorno 13 luglio 2016 15:35, < " target="_blank"> > ha scritto:Lista per gli studenti iscritti al corso di Ingegneria dei Sistemi Software e
Relativamente all'esame - parte tecnica, si invitano a presenziare, ad esempio tramite il responsabile di integrazione, i gruppi non già esaminati e responsabili per lo sviluppo di fasi o sottofasi connesse con quelle i cui gruppi sono sotto esame. In mancanza di una tale presenza, poi non saranno ammesse deleghe di responsabilità verso gruppo già esaminati per mancanza di dati o quant’altro.
Il calendario d’esami è stato pubblicato. Ad esempio, dato che il primo giorno d’esami, il 18 luglio 2016, saranno esaminati;
-Â Â Â Â di mattina, il gruppo 1 (fasi 0, 1 e 2.1), dovrebbero presenziare almeno i rappresentanti dei gruppi responsabili della fase 6 e della sub-fase 2.2;
-Â Â Â Â di pomeriggio, il gruppo 6 (responsabile del bus di integrazione), dovrebbero presenziare i rappresentanti di tutti gruppi.
Si ricorda che, per ogni gruppo, si partirà dai requisiti del progetto assegnato al gruppo, al riporto di chi nel gruppo ha fatto che cosa, ai documenti di analisi e progettazione, per poi procedere verso la costruzione del software fino alla messa in produzione.
Si anticipa altresì che, tra le varie domande, verranno poste peraltro le seguenti:
- Analizzare, fase per fase, il grado di integrazione raggiunto con tutte le altre fasi. Questo significa che il gruppo dovrà mostrare e spiegare la specifica delle API Rest definite ed invocate per la
comunicazione tra le fasi di GQM+S.
- Effettuare una demo con l'applicazione deployata "in produzione" e in grado di comunicare con le altre fasi. Laddove non fosse possibile la comunicazione con le altre fase, sarà necessario motivare adeguatamente ed accuratamente tale impossibilità e mostrare il funzionamento dell'applicazione con dei dati di esempio (sempre sfruttando il bus).
- Navigare nel codice, in ogni sua parte. Sebbene sia naturale che ogni sviluppatore si sia dedicato a sviluppare solo una parte del progetto assegnato al gruppo, ciascuno membro deve aver fatto almeno un "round-trip" (dalla GUI alla persistenza, passando per le chiamate REST al bus).
- Illustrare come sono state impiegate le tecnologie (Spring, Git, librerie) e il processo seguito (documentato tramite Time-sheet).
Eventuali rilevanti esperienze con carattere di generalità , positive o negative, occorse durante lo svolgimento del progetto, saranno riportate e discusse nella presentazione orale, già programmata per un giorno successivo.
Si ricorda che l'esame è individuale. A una domanda dovrà rispondere soltanto l’interrogato e gli altri studenti presenti non dovranno intervenire in alcun modo: così facendo, raggiungerebbero il solo effetto di togliere alla persona interrogata tempo prezioso pur concesso dalla Commissione per riflettere e rispondere o, insistendo, ad essere espulsi dall'aula.
Giovanni Cantone
Manuel Mastrofini
dei Servizi di Rete (ISSSR) di Roma Tor Vergata.
La iscrizione a/cancellazione da questa lista e' libera per gli studenti di ISSSR.
Le iscrizioni resteranno aperte fino 31 marzo del corrente A. Acc.
All'atto della iscrizione inserire recapito email e poi, separati da uno spazio,
Nome, Cognome e Matricola del biennio magistrale, se già disponibile,
altrimenti quella del triennio o altra sede di provenienza. In
alternatica, usare un indirizzo email professionale. Si considerano accettabili, ad esempio:
" target="_blank"> , oppure l'indirizzo email ufficiale tipo
@studenti.uniroma2.it. ISCRIZIONI ANONIME POTRANNO ESSERE RIMOSSE ANCHE SENZA PREAVVISO.
Gli annunci sono pubblicati sulla mailing list.
Le slide sono inviate via mailing list.
Lista per gli studenti iscritti al corso di Ingegneria dei Sistemi Software e
dei Servizi di Rete (ISSSR) di Roma Tor Vergata.
La iscrizione a/cancellazione da questa lista e' libera per gli studenti di ISSSR.
Le iscrizioni resteranno aperte fino 31 marzo del corrente A. Acc.
All'atto della iscrizione inserire recapito email e poi, separati da uno spazio,
Nome, Cognome e Matricola del biennio magistrale, se già disponibile,
altrimenti quella del triennio o altra sede di provenienza. In
alternatica, usare un indirizzo email professionale. Si considerano accettabili, ad esempio:
" target="_blank"> , oppure l'indirizzo email ufficiale tipo
@studenti.uniroma2.it. ISCRIZIONI ANONIME POTRANNO ESSERE RIMOSSE ANCHE SENZA PREAVVISO.
Gli annunci sono pubblicati sulla mailing list.
Le slide sono inviate via mailing list.
Lista per gli studenti iscritti al corso di Ingegneria dei Sistemi Software e
dei Servizi di Rete (ISSSR) di Roma Tor Vergata.
La iscrizione a/cancellazione da questa lista e' libera per gli studenti di ISSSR.
Le iscrizioni resteranno aperte fino 31 marzo del corrente A. Acc.
All'atto della iscrizione inserire recapito email e poi, separati da uno spazio,
Nome, Cognome e Matricola del biennio magistrale, se già disponibile,
altrimenti quella del triennio o altra sede di provenienza. In
alternatica, usare un indirizzo email professionale. Si considerano accettabili, ad esempio:
"> , oppure l'indirizzo email ufficiale tipo
@studenti.uniroma2.it. ISCRIZIONI ANONIME POTRANNO ESSERE RIMOSSE ANCHE SENZA PREAVVISO.
Gli annunci sono pubblicati sulla mailing list.
Le slide sono inviate via mailing list.
Archivio con motore MhonArc 2.6.16.