Project 2018-2019

Sito web per domande e risposte

Versione 1.2

Progettare e realizzare un sito web che permetta agli utenti iscritti di porre domande e di fornire risposte agli interrogativi proposti.

L’applicazione dovrà permettere ad un utente di:

  • Registrarsi al sito;
  • Inserire una nuova domanda;
  • Rispondere ad una domanda;
  • Visualizzare domande e risposte;
  • Dare un giudizio ad una risposta data da un altro utente (funzionalità disponibile solo per gli utenti “giudici”).

Registrazione al sito

Durante la registrazione al sito l’utente dovrà inserire obbligatoriamente le seguenti informazioni personali:

  • Nome utente (username);
  • Password;
  • Indirizzo email.

Inoltre l’utente potrà opzionalmente fornire i seguenti dati:

  • Nome e Cognome;
  • Sesso;
  • Data di nascita;
  • Luogo di nascita;
  • Luogo di domicilio o residenza.
  • Uno o più identificativi dell’utente su social network (e.g. un utente deve poter specificare il suo nome utente Twitter e il suo nome su Instagram ecc.)

Una volta registrato l’utente non potrà più modificare i propri dati.

Non è previsto un meccanismo di verifica dell’indirizzo mail, né di recupero password.

Tutte le informazioni inserite in sede di registrazione dovranno essere accessibili attraverso la pagina di profilo dell’utente.

Inserimento di una domanda

Un utente registrato potrà inserire una domanda, specificandone il testo (max 300 caratteri) e la categoria. Alla domanda l’utente potrà allegare uno o più link ad immagini presenti sul web (attenzione: non è richiesto che il sistema mantenga immagini ma solo delle url). Solo l’amministratore del sistema potrà eliminare la domanda.

Gestione della categorie

Al lancio del sistema, il sito web dovrà offrire alcune categorie di domande predefinite: Ambiente, Animali, Arte e cultura, Elettronica e tecnologia, Sport, Svago. Durante l’esercizio del sistema, l’amministratore potrà aggiungere nuove categorie, rinominare una categoria esistente o aggiungere una sotto categoria ad una categoria esistente. Una sotto categoria può avere a sua volta sotto categorie: es. Sport > Calcio > Serie A.

Rispondere ad una domanda

Un utente registrato potrà rispondere ad una domanda, specificando il testo (max 500 caratteri) ed eventualmente un utente potrà allegare uno o più link ad immagini presenti sul web (attenzione: non è richiesto che il sistema mantenga immagini ma solo delle url). L’amministratore e i giudici potranno eliminare la risposta.

Giudicare una risposta

Alcuni utenti detti “giudici” potranno dare un giudizio alla risposta di un utente. Il giudizio è un numero da 0 a 5. I giudici troveranno vicino ad ogni risposta 6 bottoni (uno per ogni livello di giudizio) e potranno cliccare su un bottone per esprimere il proprio giudizio alla risposta.

Una volta dato un giudizio non sarà possibile modificarlo.

Solo l’amministratore avrà la possibilità di nominare nuovi giudici scegliendoli tra gli utenti registrati.

Visualizzare domande e risposte

I visitatori (non registrati) troveranno nella pagina principale il testo delle ultime domande inviate dagli utenti. Le domande dovranno essere mostrate in ordine cronologico dalla più recente. Cliccando su una domanda i visitatori verranno indirizzati su una nuova pagina in cui verrà mostrata la domanda e le risposte date dagli utenti fino a quel momento. Le risposte vengono visualizzate in ordine cronologico dalle più alle meno recenti.

Gli utenti registrati, oltre a leggere le domande dalla pagina principale del sito, vi troveranno un menu a tendina (o una colonna laterale) dal quale potranno selezionare una categoria. Una volta selezionata una categoria verranno visualizzate solo le domande appartenenti a quella categoria e a sue eventuali sotto categorie. Una volta scelta una categoria verranno mostrate all’utente eventuali sotto categorie di quella scelta. L’utente potrà cliccare nuovamente su una sotto categoria per raffinare ulteriormente la lista di domande visualizzate.

Un utente potrà cliccare su una domanda e verrà indirizzato su una nuova pagina dove potrà visualizzare (dall’estremo superiore a quello inferiore della pagina): la categoria della domanda (se è una sotto categoria verranno visualizzate anche le sue sopra categorie, es. se la categoria è Serie A, verrà visualizzato Sport > Calcio > Serie A), il testo della domanda, le risposte giudicate (mostrati in ordine di giudizio e, per quelle a pari giudizio, in ordine cronologico dal più recente) con i relativi giudizi e il nome utente dei giudici che hanno dato il giudizio, e infine le risposte non giudicate (mostrate in ordine cronologico dal più recente).

Tutti gli utenti visualizzeranno affianco a domande e risposte la data e l’ora in cui sono state inviate e l’utente che l’ha inviate.

Modalità di realizzazione

  • Il modello di processo suggerito è un ibrido strutturato-agile composto da due fasi: inception e construction.
  • In inception vengono prodotti come artefatti una modellazione dei casi d’uso, un modello di dominio, un glossario (più eventualmente altri artefatti accessori).
  • In costruction si seguono le pratiche di gestione di processo di Scrum, due componenti del gruppo giocano il doppio ruolo di membri del team e di scrum master e product owner (i ruoli si ridistribuiscono al termine di ogni sprint). Sono rispettati gli eventi standard (Sprint planning, Daily scrum, Sprint review e Sprint retrospective) e vengono prodotti e gestiti gli artefatti standard (Product backlog, Sprint backlog, Burn down chart).
  • I casi d’uso identificati in inception vengono posti inizialmente nel backlog e raffinati in user stories (tipicamente una per scenario).

Prodotti da realizzare

Prima di consegnare controllare nuovamente questa lista e verificare che tutta la documentazione richiesta in seguito sia stata prodotta.

Ogni gruppo dovrà realizzare:

  • Artefatti obbligatori della fase di inception
      • Modello dei casi d’uso
      • Modello di dominio
  • Glossario
  • Diario del progetto: questo documento deve riportare in modo sintetico e schematico lo stato di avanzamento del progetto e le attività del gruppo. In particolare all’inizio di ogni sprint devono essere specificati lo stato dei backlog e i criteri seguiti per la popolazione dello sprint backlog attraverso l’assegnazione delle priorità e dell’effort agli elementi del product backlog. Deve inoltre essere presente un dettaglio delle attività del gruppo dove vengono riportate in modo sintetico e schematico: tutte le attività svolte dal gruppo giorno per giorno, inizio/fine iterazioni e sprint, eventi di scrum, ruoli assegnati tramite scrum, versioni intermedie o primordiali degli artefatti, link ai commit delle release di codice ed eventualmente screenshot delle board per il tracking del progetto. Al seguente link è possibile trovare un esempio di diario. Alla consegna del progetto condividere il link al documento permettendo la possibilità di modificare (scegliere l’opzione corretta da google doc).
  • Descrizione del metodo adottato, questa deve riportare: numero di iterazioni, milestone,  issue, criteri per l’assegnazione di priorità ai task e user stories.
  • Relazione su scelte progettuali e di interfaccia.
  • Manuale utente

Indicazioni di carattere generale da seguire obbligatoriamente

  • Il progetto dovrà essere realizzato in gruppo, ogni gruppo dovrà essere composto da massimo 3 persone.
  • Effettuare unit testing (utilizzando JUnit).
  • Utilizzare il linguaggio Java e GWT.
  • Il codice dovrà essere opportunamente commentato e indentato.
  • Utilizzare in maniera appropriata gli strumenti di versionamento del codice (Git), bug tracking e code review (creazione di branch, pull request ed attuazione dei merge);
  • Si dovrà utilizzare BitBucket per gli strumenti a supporto del progetto (gestione delle revisioni, issue/project tracking), La documentazione dovrà essere prodotta sotto forma di pagine wiki all’interno del progetto in BitBucket.
  • Il gruppo deve obbligatoriamente utilizzare Trello e Jira (issue tracker di bitbucket, seguire queste istruzioni per abilitarlo) per gestione dei backlog di scrum e per le issue. Il gruppo deciderà in seguito come utilizzare questi due strumenti. Ad esempio, potrebbe usare Trello per la gestione dei backlog e Jira per la gestione delle issue. Entrambi gli strumenti sono accessibili e integrati nella suite messa a disposizione da Bitbucket.
  • Tutte le informazioni gestite dal sito dovranno essere accessibili anche dopo il riavvio del server. Per gestire la persistenza è obbligatorio utilizzare MapDB (MapDB). Non si accetterà la consegna di progetti che usano altri meccanismi di gestione della persistenza.
  • L’utente amministratore dovrà avere come username “admin” e password “admin”. La sua registrazione non potrà avvenire attraverso interfaccia web.

Consigli

  • Si consiglia di utilizzare Eclipse come IDE.
  • E’ apprezzato l’uso di Google Doc per la stesura del diario e delle relazioni. Per i diagrammi si consiglia l’utilizzo di draw.io . Draw.Io è uno strumento che permette l’editing collaborativo di diagrammi UML. Si occupa di gestire le varie revisioni dei diagrammi ed è integrato con GoogleDrive (salva i diagrammi su una directory di GoogleDrive). Inoltre si occupa di fare l’export dei diagrammi in formato pdf o immagine. In alternativa ci sono anche altri strumenti come che permettono l’editing dei diagrammi offline (es. yEd)
  • Per prendere confidenza con GWT e MapDB si consiglia di seguire i relativi tutorial:
  • Se si hanno problemi con dipendenze (es. ClassNotFoundException), si consiglia l’utilizzo di Maven al fine di importare correttamente tutte le dipendenze necessarie per il progetto.  Molte delle distribuzioni di Eclipse includono Maven. Nel caso ci sia bisogno di installare il plugin si può seguire questa guida. Maven mette a disposizione tantissime funzionalità, l’unica che interessa ai fini del progetto è quella di gestore delle dipendenze.
  • Guida Utilizzo GIT
  • Un esempio di utilizzo di utilizzo di maven e map db potete trovarlo qui
  • Esempio di progetto GWT che utilizza MapDB (il classpath incluso andrà adattato) Repository GIT

Modalità e tempi di consegna

La consegna avverrà inviando una mail a luigi(punto)asprino(chiocciola)unibo(punto)it e invitando al repository di Bitbucket l’utente “luigi-asprino”. Successivamente ogni gruppo verrà convocato per discutere il progetto nelle date che verranno rese note di volta in volta nel sito del corso. Ci sarà orientativamente una data di discussione al mese e nel caso di necessità particolari potranno essere concordate date aggiuntive.

Valutazione

La valutazione del progetto avverrà tenendo conto dei seguenti punti:

  • La realizzazione delle specifiche funzionali;
  • L’organizzazione e la leggibilità del codice;
  • L’adozione di una metodologia e l’utilizzo appropriato degli strumenti di testing, versioning, bug tracking, code reviewing e project tracking;
  • L’adeguatezza della documentazione allegata al progetto e in particolare della descrizione del processo di sviluppo adottato;
  • La discussione del progetto.

Per qualsiasi dubbio o chiarimento riguardanti le specifiche del progetto non esitate a contattarmi all’indirizzo email luigi(punto)asprino(chiocciola)unibo(punto)it o utilizzate il forum dell’insegnamento.

Presentazione del 5/12/2018

Storia delle versioni

  • v1.1 : aggiunto link a draw.io (tool consigliato per l’editing dei diagrammi)
  • v1.2 : aggiunto link a istruzioni per abilitare issue tracker in Bitbucket