Programming and Development paradigms 2016/2017

    Main     Info     Exam

Regole relative all'esame

Si riportano qui di seguito le regole di svolgimento e di gestione degli esami relativamente all'anno di corso 2016/2017 del corso di "Sistemi di Sviluppo Software" (S3), che comprende entrambi i sotto-corsi "Paradigmi di Programmazione e Sviluppo" (PPS) e "Programmazione Concorrente Distribuita" (PCD). Ogni studente è tenuto a conoscere le regole di cui sotto al momento in cui comincia la preparazione dell'esame, e a leggere il presente documento prima di chiedere informazioni ai docenti. Per qualunque aspetto che esuli da quanto riportato qui sotto si contatti il/i docente/i.

Aspetti generali

L'esame si articola di due valutazioni, incentrate sulla preparazione di un "progetto" di gruppo volto alla costruzione di un sistema distribuito. Completato il progetto, gli studenti svolgeranno una discussione individuale col prof.Ricci per la parte relativa a PCD, e una discussione di gruppo col prof.Viroli per la parte relativa a PPS. Entrambe le discussioni potranno vertere sui contenuti del corso, sullo svolgimento del progetto, e sugli assignment (se consegnati). La parte PPS dovrà necessariamente essere svolta a progetto finito, mentre quella PCD potrà essere svolta in una fase preliminare del progetto (da concordare con Ricci). Soddisfatti questi vincoli sarà possibile sia sostenere prima quella PPS che quella PCD.

Scelta e svolgimento del progetto

P1. Il progetto è sviluppata da gruppi di studenti. Il numero preferito è 4, numero che permette di cimentarsi con gli aspetti di "team" di design e implementazione, e consente di sviluppare sistemi non banali. Agli studenti che non riuscissero a formare un tale gruppo, si chiede di dichiarare per tempo la propria disponibilità sul forum "Progetti-gruppi" presso il sito e-learning di PPS, in modo da favorire l'aggregazione spontanea di studenti in nuovi gruppi. Eccezioni a gruppi di 4 sono possibili se opportunamente motivate, ma portano (in particolare con un numero inferiore di studenti) a maggiori possibilità che la discussione si focalizzi su aspetti "teorici" di metodologia (aspetti che è molto meglio aver sperimentato in pratica).

P2. Nel concepire un possibile progetto, ogni studente tenga conto che dovrà investire nell'attività circa 100 ore di lavoro (ossia né molte di più, né molte di meno). Lo studente dovrà sempre tenere traccia delle ore di lavoro svolte via via e fornirle al docente a richiesta.

P3. In generale, ogni studente sarà interamente responsabile della parte di progetto relativa a requisiti, design architetturale, e relazione finale; sarà in più responsabile della parte di design di dettaglio e implementazione, del sottoinsieme di classi a cui ha contribuito o co-contribuito (e tale parte non dovrà essere inferiore, per quantità, a un quarto del complessivo, nel caso di 4 studenti).

P4. In fondo a questo documento sono presenti alcune meta-proposte di progetto, ma spetterà agli studenti ispirarsi a queste per concepire una proposta precisa. Si consiglia agli studenti di non impiegare troppo tempo, nel progetto, ad aspetti tecnologici che esulano da questo corso (Android, database, Web), perché non verranno valutati in dettaglio. Comunque, il progetto proposta dovrà essere (sostanzialmente) JVM-based e riguardare un sistema distribuito.

P5. Concepita una proposta di progetto, gli studenti la sottoporranno ai docenti con un post sul forum "Progetti" del sito PPS. Il subject della proposta dovrà essere completo di: deadline scelta (una data entro 2 mesi dal post), acronimo (tassativamente non più di 10 caratteri alfanumerici minuscoli, inclusi eventualmente solo del simbolo "-"), cognome dei membri del gruppo, titolo in esteso. Il corpo della proposta includa le email dei membri del gruppo e i seguenti aspetti di massima (espressi in modo sintetico, anche non definitivo): principali aspetti del processo di sviluppo che verrà seguito, compiti di ogni studente, e sintesi dei requisiti di massima del sistema da realizzare.

P6. Gli studenti sviluppino il progetto in modalità cooperativa, utilizzando Git, Gradle (o SBT) ed un repository BitBucket con nome S3-16-acronimo, che consentirà ai docenti di accedere più facilmente ai sorgenti e per la valutazione finale. All'atto della consegna tale repository dovrà avere nella sezione "download": information un file PDF per la relazione e (ii) i (fat) JAR eseguibili dell'applicazione. Questi ultimi dovranno essere eseguibili indipendentemente dalla piattaforma supportante (dovrà essere eseguibile su Linux, ed eventualmente in Windows/MacOS X). Se possibile, non si consegnino altri file o risorse esterne al jar eseguibile. Il software dovrà funzionare senza problemi a partire dai jar: per deployment più complessi si contattino i docenti. All'atto della consegna, la sezione "sources" dovrà contenere tutti i file rilevanti per il progetto come tracciati da Git (il codice sorgente, i file di configurazione IntelliJ del progetto, i file di configurazione della build). Il progetto, una volta clonato, dovrà essere direttamente eseguibile in Gradle /SBT e importabile in IntelliJ. 

P7. La relazione dovrà contenere tassativamente i seguenti capitoli:

  1. Processo di sviluppo adottato (modalità di divisione in itinere dei task, meeting/interazioni pianificate, modalità di revisione in itinere dei task, scelta degli strumenti di test/build/continuous integration) 
  2. Requisiti (funzionali, non funzionali, etc..)
  3. Design architetturale (pattern architetturali usati, componenti del sistema distribuito, scelte tecnologiche cruciali ai fini architetturali -- corredato da pochi ma efficaci diagrammi)
  4. Design di dettaglio (pattern di progettazione, organizzazione del codice -- corredato da pochi ma efficaci diagrammi)
  5. Implementazione (per ogni studente, una sotto-sezione descrittiva di cosa fatto/co-fatto e con chi)
  6. Restrospettiva (descrizione finale dettagliata dell'andamento dello sviluppo, del backlog, delle iterazioni; commenti finali)

Si noti che la retrospettiva è l'unica sezione che può citare aneddoti di cosa è successo in itinere, mentre le altre sezioni fotografano il risultato finale. Se gli studenti decideranno (come auspicato) di utilizzare un product backlog e/o dei backlog delle varie iterazioni/sprint, è opportuno che questi siano file testuali tenuti in versione in una cartella "process", così che sia ri-verificabile a posteriori la storia del progetto.

P8. Un processo di sviluppo consigliato (SCRUM-inspired, eventualmente modificabile) è il seguente:

  • uno studente (ad esempio, chi ha l'idea del progetto) fungerà da product owner, oltre che da sviluppatore
  • in un meeting iniziale si rediga un product backlog, e si definisca un primo sprint organizzativo (preparazione della build, identificazione requisiti base e architettura)
  • si definiscano via-via delle sprint da 25-30 ore di lavoro (una settimana full-time), in modo da realizzarne 3-4 in tutto
  • si cerchi ad ogni sprint di ottenere risultati "tangibili", con già un valore per gli stakeholder (i docenti)
  • si tenga anche uno sprint backlog, e si facciano meeting frequenti, e meeting a inizio/fine sprint (con brevissimo report del risultato, anch'esso da tenere in versione)

Consegna

C1. Un progetto si ritiene ultimato quando tutti gli studenti hanno raggiunto il monte ora sopra indicato, è stato realizzato l'insieme delle funzionalità necessarie, il codice è opportunamente commentato (con commenti javadoc) e testato, la relazione è stata prodotta in formato corretto, e il repository è strutturato come da regola P8.

C2. Fatte salve le indicazioni sopra fornite, agli studenti viene lasciata libertà nella scelta di quale progetto realizzare, processo di sviluppo adottare, linguaggio/i utilizzare, librerie esterne adottare, eccetera. Si consideri tuttavia che laddove un progetto risulterà "carente" nel coprire certe parti del corso integrato S3, allora sarà probabile che tali argomenti saranno sviscerati poi durante i colloqui coi docenti. E' quindi opportuno che gli studenti includano (anche non tutti, ma) vari aspetti quali: parti del codice in Scala, elementi di agilità nel processo di sviluppo, uso sistematico del testing, tecnologie/tecniche studiate nel corso PCD, eccellenza tecnica in ogni sorgente prodotto.

C3. Completato il progetto, questo dovrà essere consegnato entro la deadline proposta dagli studenti, attraverso un post sul forum. A fronte di una consegna non corretta, si riceveranno eventuali feedback per la sua correzione (da realizzarsi in poche ore).

Discussione

D1. Le discussioni delle parti PPS e PCD avverranno in momenti diversi, senza vincoli di ordine (prima PCD o prima PPS).

D2. Consegnato il progetto, si potrà prendere appuntamento per una unica discussione col prof.Viroli per la parte PPS. Per questo incontro gli studenti preparino su PC una demo del progetto e tengano ben accessibili i sorgenti/eseguibili degli assignment di tutti gli studenti. 

D3. Per la discussione PCD si prenda appuntamento singolarmente col prof.Ricci. Sarà possibile farlo anche prima della consegna del progetto, ossia quando la parte architetturale e un prototipo di base del sistema sarà disponibile (ad esempio, dopo 1-2 iterazioni preliminari). Si concordi col prof.Ricci il livello di sviluppo del progetto necessario per la discussione dell'esame PCD.

D4. Alla fine delle due discussioni, e in caso di valutazione positiva, ogni studente riceverà un voto in 30-esimi ottenuto con media aritmetica delle valutazioni proposte dai due docenti, e potrà verbalizzare il voto finale. Solo in casi eccezionali, i docenti potrebbero richiedere agli studenti una integrazione al loro lavoro.

Esempi di progetti

Ricordando allo studente che ha massima libertà nel proporre progetti, che comunque devono riguardare un sistema distribuito, forniamo qui di seguito esempi possibili/consigliati:

  • *Game*: applicazione che realizza un gioco in modalità distribuita multi-giocatore, sia esso nuovo o clone di un game esistente
  • *Gestionale*: applicazione di natura gestionale in modalità distribuita (con più utenti e parte server)
  • *Simulazione*: simulazione distribuita di un sistema fisico naturale o artificiale
  • *Coordination*: sistema server di coordinamento di device fissi/mobili, con funzionalità di monitoring, interazione coi dispositivi, coordinamento del loro funzionamento

E' possibile che i docenti abbiano qualche proposta di progetto specifica: se interessati li si contattino. 

Modalità di bootstrap del progetto

  • Per proporre un progetto, uno dei componenti crei una discussione sul forum (seguendo il template di discussione già creato)
  • I docenti accetteranno la proposta rispondendo entrambi al post iniziale, eventualmente suggerendo qualche proposta di modifica.
  • Ove necessario, in itinere gli studenti potranno porre domande su quanto stanno facendo
  • Gli studenti comunicheranno la consegna finale (tutto il materiale sarà sul repo)
  • I docenti daranno eventuali feedback su micro-modifiche e gli studenti realizzeranno le poche modifiche
  • Si contattino i prof. per la fase delle discussioni (Ricci eventualmente anche prima della fine)