Regole relative all'esame

Si riportano qui di seguito le regole di svolgimento e di gestione degli esami relativamente all'anno di corso 2019/2020 del corso di "Paradigmi di Programmazione e Sviluppo" (PPS). 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 al docente.

Aspetti generali

G1) L'esame è previsto in due modalità alternative: un progetto software da condurre in gruppo, o un progetto sperimentale per il singolo studente. Completato il progetto, gli studenti svolgeranno una discussione (di gruppo nel primo caso, singoli il secondo) col prof.Viroli, che potrà vertere sui contenuti del corso, sullo svolgimento del progetto, e su ulteriore materiale che gli studenti avessero prodotto (in genere programmi Scala o Prolog). Alla fine della discussione verrà pre-assegnato un voto in 30-esimi. Se (o non appena) sarà disponibile anche il voto della parte PCD dell'esame, verrà registrato il voto finale, che sarà ottenuto dalla media aritmetica fra i due.

G2) Vista la relativa difficoltà ad identificare progetti sperimentali appropriati, il docente auspica che la maggior parte degli studenti scelgano il progetto software. Precondizione per la scelta di un progetto sperimentale è comunque una elevata comprensione degli aspetti tecnici più avanzati visti nel corso. In ogni caso, è importante notare che il range di punteggio, e il numero complessivo di ore necessarie allo sviluppo è il medesimo (60-70 ore, ossia né molte di più, né molte di meno).

G3) Il docente proporrà una lista di possibili progetti sperimentali (ed eventualmente lo studente potrà proporne di simili) e li assegnerà agli studenti che ne faranno richiesta dopo breve colloquio (anche via mail). Verrà quindi anche concordata la modalità di consegna, che comunque comprenderà sempre una relazione e un repository software.

Le restanti regole considerano i dettagli del progetto software.

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 del numero di ore di lavoro sopra indicate. È quindi importante che ci si focalizzi su qualità e non su quantità, e su un processo di sviluppo agile che permetta di giungere velocemente a far funzionare un core, e quindi ad evolverlo aggiungendo funzionalità senza eccedere il monte ore. 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 di una sua parte di design di dettaglio e implementazione, che consiste nel 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). Non manchi una parte significativa del sistema interamente attribuibile al singolo studente.

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 proposto dovrà essere (sostanzialmente) JVM-based: potrebbe o non potrebbe includere aspetti di distribuzione.

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, eventualmente aumentata del periodo di chiusura per vacanze della sede), 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 o GitHub con nome PPS-19-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" o "releases": 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:

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)
Requisiti (delle varie tipologie, ossia: 1) business, 2) utente, 3) funzionali, 4) non funzionali, 5) di implementazione)
Design architetturale (architettura complessiva, descrizione di pattern architetturali usati, componenti del sistema distribuito, scelte tecnologiche cruciali ai fini architetturali -- corredato da pochi ma efficaci diagrammi)
Design di dettaglio (scelte rilevanti, pattern di progettazione, organizzazione del codice -- corredato da pochi ma efficaci diagrammi)
Implementazione (per ogni studente, una sotto-sezione descrittiva di cosa fatto/co-fatto e con chi, e descrizione di aspetti implementativi importanti non già presenti nel design)
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 fotografino 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 sorta di committente o esperto del dominio, oltre che da sviluppatore; cercherà di garantire l'usabilità/qualità del risultato
uno studente (ad esempio, chi pensa di avere doti di coordinamento) 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 corte da 15-20 ore di lavoro (una settimana half-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 o lo studente/committente)
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 scala/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 PPS, allora sarà probabile che tali argomenti saranno sviscerati poi durante il colloquio. È quindi opportuno che gli studenti includano (anche non tutti, ma) vari aspetti quali: parti significative del codice in Scala, elementi di agilità nel processo di sviluppo, uso sistematico del testing, tecniche FP avanzate, 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 potranno avvenire 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. Alla fine delle due discussioni PPS e PCD, 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, forniamo qui di seguito esempi possibili/consigliati:

*Game*: applicazione che realizza un gioco, sia esso nuovo o clone di un game esistente, con o senza modalità distribuita multi-giocatore
*Gestionale*: applicazione di natura gestionale, ad esempio in modalità distribuita (con più utenti e parte server)
*Simulazione*: simulazione (distribuita o non) di un sistema fisico naturale o artificiale
*Coordination*: sistema server di coordinamento di device fissi/mobili/IoT, 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)
Il docente accetterà la proposta rispondendo 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)
Il docente darà eventuali feedback su micro-modifiche e gli studenti realizzeranno le poche modifiche
Si contatti il docente per la fase delle discussioni

Note aggiuntive su come preparare la relazione

Non si faccia mancare all'inizio una descrizione anche sommaria di cosa il sistema implementato realizza.
Vista la mole di lavoro dietro al progetto, difficile pensare che i requirement occupino meno di 2-3 facciate: siano più sistematici possibili
Le scelte tecnologiche non dovrebbero essere anticipate troppo per ovvi motivi.. prima le fate prima impattano tutta la parte successiva e quindi diventano più difficilmente riconsiderabili (comunque in linea di principio ogni scelta ha una sua posizione logica precisa, e potrebbe essere nei requirement fino all'implementazione).
Attenzione in particolare ai requirement non funzionali: 1) non siano troppo vaghi altrimenti sono inverificabili, e quindi praticamente inutili; 2) se il sistema è distribuito, è inevitable dire cosa vi aspettate in termini di di robustezza a cambiamenti/guasti (quali?, come?), e scalabilità (in quale dimensione? fino a che punto?).
Ricordate che una scelta architetturale può ritenersi giustificata o meno solo a fronte dei requirement che avete indicato; viceversa, ogni requirement "critico" dovrebbe influenzare qualcuna della scelte architetturali effettuate e descritte.
L'architettura deve spiegare quali sono i sotto-componenti del sistema (da 5 a 15, diciamo), ognuno cosa fa, chi parla con chi e per dirsi cosa -- i diagrammi aiutano, ma poi la prosa deve chiaramente indicare questi aspetti.
Il design di dettaglio "esplode" (dettaglia) l'architettura, ma viene concettualmente prima dell'implementazione, quindi non metteteci diagrammi ultra-dettagliati estratti dal codice, quelli vanno nella parte di implementazione eventualmente.
L'implementazione "esplode" il design, ma solo laddove pensiate che serva dire qualcosa.
Cercate di dare una idea di quanto pensate che i vostri test automatizzati coprano il codice e dove: è importante per stimare il potenziale impatto di una modifica al software.
Ricordatevi che la lettura della relazione fino a: i requirement, deve essere sufficiente per uno sviluppatore per giungere ad un sistema che fa quello che fa il vostro; (ii) al design, deve essere sufficiente per uno sviluppatore per giungere ad un sistema che in più è organizzato come il vostro; (iii) alla implementazione, è essenzialmente equivalente al vostro.

Note su come prepararsi per la discussione

Preparare una presentazione per gruppo (con slide opzionali, oppure a braccio sulla relazione) con demo del sistema e breve descrizione dei principali aspetti architetturali e tecnologici: il tutto da fare in (meno di) 10 minuti senza domande
Conoscere la relazione nelle sue parti comuni (requisiti e architettura), oltre che la propria parte
Conoscere in dettaglio il codice che si è sviluppato e quello che si porta per l'esame
Preparasi eventualmente a rispondere a domande sui temi del corso
Sapere a richiesta dimostrate eventualmente operatività in Scala e Prolog