PPS-22-smartgh

1. Processo di sviluppo

Per il processo di sviluppo, il team di lavoro ha deciso di utilizzare un approccio SCRUM-inspired. In particolare, SCRUM è un framework di sviluppo software agile, iterativo e incrementale, che consente la gestione dello sviluppo del prodotto.

Specificatamente, tale processo prevede di:

  1. nominare uno studente (ad esempio, chi ha l’idea del progetto) che fungerà da committente o esperto del dominio, e che cercherà di garantire l’usabilità e la qualità del risultato;
  2. designare uno studente (ad esempio, chi pensa di avere doti di coordinamento) che ricoprirà il ruolo di product owner;
  3. effettuare un meeting iniziale in cui redigere un product backlog e definire un primo sprint organizzativo;
  4. utilizzare sprint corti, da 15-20 ore di lavoro, con l’obiettivo di ottenere ad ogni sprint dei risultati “tangibili”, ossia con un valore per gli stakeholder;
  5. fare meeting frequenti ed a inizio/fine sprint (opportunamente documentati da un brevissimo report del risultato, anch’esso da tenere in versione), realizzando uno sprint backlog per mantenere traccia dell’organizzazione dei lavori.

1.1 Meetings

I meetings sono stati realizzati definendo, inizialmente, un ordine del giorno redatto principalmente dal product owner, in collaborazione con gli altri membri del gruppo che possono suggerire modifiche o nuovi aspetti da discutere.

Sono stati svolti incontri brevi e frequenti, pressoché quotidiani, in modo da mantenere aggiornati i diversi membri del gruppo sullo stato di avanzamento del progetto.

Per quanto riguarda gli sprint, come specificato precedentemente, essi sono stati svolti nell’arco di una settimana lavorativa e discussi in incontri a inizio e fine periodo.

In particolare, durante l’incontro di inizio sprint, viene definito il product backlog relativo mentre, durante quello di fine Sprint, vengono discussi i risultati ottenuti e viene revisionato il lavoro svolto.

I diversi meetings sono stati tenuti in modalità smart-working, attraverso l’utilizzo di piattaforme per videoconferenze.

Ogni meeting e il rispettivo ordine del giorno sono stati tracciati in un apposito file, che è possibile trovare fra gli artefatti del progetto.

1.1.1 Sprint planning

Lo sprint planning è un meeting in cui il team pianifica il lavoro che deve essere svolto e portato a termine durante lo sprint. Questo prevede di individuare i diversi elementi del product backlog e i differenti sprint tasks che devono essere effettuati per poter raggiungere gli obiettivi prefissati. Di conseguenza, durante i diversi sprint planning sono stati discussi i seguenti punti:

  1. definizione dell’obiettivo principale dello sprint;
  2. stato di sviluppo da raggiungere alla fine dello sprint, tramite il raffinamento del product backlog;
  3. definizione dei diversi tasks da svolgere per il raggiungimento degli obiettivi preposti;
  4. assegnazione dei task ai diversi membri del gruppo.

1.1.2 Sprint review

Lo sprint review è un meeting che ha luogo alla fine dello sprint e che ha l’obiettivo di revisionare e valutare il lavoro svolto dal team di sviluppo.

Pertanto, durante i differenti sprint review sono stati discussi i seguenti punti:

  1. analisi dell’incremento ottenuto rispetto al risultato precedente, valutando il lavoro che è stato svolto;
  2. aggiornamento e adattamento del product backlog;
  3. valutazione di eventuali ritardi rispetto ai tempi definiti in precedenza;
  4. formalizzazione del risultato ottenuto, riportandolo nello sprint result del relativo product backlog.

1.1.3 Daily SCRUM

Il daily SCRUM rappresenta un momento in cui il team si riunisce e ogni membro mette al corrente i collaboratori del proprio operato. Il meeting è breve (circa 15-20 minuti) e durante questo tipo di incontro ogni membro del gruppo espone i seguenti punti:

  1. il lavoro svolto nella giornata corrente;
  2. le eventuali problematiche riscontrate durante lo sviluppo, chiedendo consigli agli altri membri del team su come poterle risolvere;
  3. la pianificazione dei successivi compiti che si intende svolgere, a fronte di quanto emerso nei precedenti punti.

Va specificato che questi meetings non sono stati svolti necessariamente tutti in videoconferenza, ma anche via chat. Inoltre, queste occasioni di discussione, in quanto giornaliere e di breve durata, non sono state documentate.

1.2 Divisione dei tasks

All’avvio di ciascuno sprint settimanale, mediante il product backlog, sono stati assegnati a ciascun membro del team una serie di tasks da svolgere.

In particolare, ogni componente del team ha contribuito al progetto realizzando i tasks descritti di seguito.

Folin Veronika

Macro-obiettivo Task
Selezionare le piante da coltivare all'interno della serra Caricamento delle piante selezionabili in un file Prolog
Creare interfaccia componente pianta
Avvio della simulazione Creare layout schermata di visualizzazione stato globale della serra
Creare componente Model per gestire l'avvio del tempo
Consentire lo scorrimento fra le diverse pagine dell'applicazione Realizzazione architettura MVC tramite cake pattern per la visualizzazione dello stato globale della serra
Realizzazione MVC globale della simulazione*
Realizzazione collegamento fra i diversi MVC*
Visualizzare lo stato aggiornato della simulazione Aggiornamento parametri ambientali tramite richieste periodiche*
Gestione e visualizzazione aggiornamento tempo
Visualizzare lo stato aggiornato delle singole aree Gestire interazione e collegamento fra: l'environment e i sensori*
Consentire la gestione di un'area Refactor e ottimizzazione views dell'applicazione
Collegare mvc dettaglio aree all'applicazione*
Miglioramento reattività dell'applicazione Gestire tramite reactive programming le richieste per i parametri dell'ambiente
Miglioramento dell'esperienza utente Sistemare elementi dell'interfaccia grafica*
Verifica del coretto funzionamento dell'applicazione tramite test manuali*
Sostituzione piante prive di descrizione o con descrizione non esaustiva
Guida utente per l'applicazione Inserire guida utente nell'applicazione
Documentazione Raffinare diagrammi UML*
Terminare report*
Scrivere file README
Applicazione finale Operazioni finali di refactoring del codice, miglioramento dei test e ottimizzazione degli imports*
Realizzare file .jar*
Valutare coverage finale ottenuta*
Effettuare prima release dell'applicazione*

Mengozzi Maria

Macro-obiettivo Task
Selezionare la città di ubicazione della serra Caricamento delle città in un file Prolog
Creare interfaccia componente città
Realizzazione meccanismo di salvataggio della città selezionata
Avvio della simulazione Realizzare la visualizzazione della suddivisione in aree e del nome delle piante in ciascuna zona della serra
Consentire lo scorrimento fra le diverse pagine dell'applicazione Realizzazione architettura MVC tramite cake pattern per la divisione in aree della serra
Realizzazione MVC globale della simulazione*
Realizzazione collegamento fra i diversi MVC*
Visualizzare lo stato aggiornato della simulazione Aggiornamento parametri ambientali tramite richieste periodiche*
Definizione interfaccia area e realizzare la sua implementazione
Gestire il collegamento fra: la serra, le aree e le piante
Visualizzare lo stato aggiornato delle singole aree Gestire interazione e collegamento fra: le aree e i sensori*
Consentire la gestione di un'area Realizzare model dettaglio aree
Realizzare controller dettaglio aree*
Collegare mvc dettaglio aree all'applicazione*
Miglioramento dell'esperienza utente Sistemare elementi dell'interfaccia grafica*
Verificare adattabilità dei diversi componenti alla dimensione dello schermo e al resizing
Verifica del coretto funzionamento dell'applicazione tramite test manuali*
Miglioramento stile aree nella schermata principale
Refactor gestione stati aree e sensori
Guida utente per l'applicazione Scrivere guida utente per l'applicazione*
Documentazione Raffinare diagrammi UML*
Terminare report*
Applicazione finale Operazioni finali di refactoring del codice, miglioramento dei test e ottimizzazione degli imports*
Realizzare file .jar*
Valutare coverage finale ottenuta*
Effettuare prima release dell'applicazione*

Vitali Anna

Macro-obiettivo Task
Selezionare le piante da coltivare all'interno della serra Creare layout schermata di selezione delle piante
Realizzazione meccanismo di salvataggio delle piante selezionate
Avvio della simulazione Creare componente Controller gestire l'avvio del tempo
Creare layout schermata di fine simulazione
Consentire lo scorrimento fra le diverse pagine dell'applicazione Realizzazione architettura MVC tramite cake pattern per la selezione delle piante
Realizzazione MVC globale della simulazione*
Realizzazione collegamento fra i diversi MVC*
Visualizzare lo stato aggiornato delle singole aree Impostazione formula di aggiornamento dei valori dei sensori*
Definizione interfaccia sensori*
Implementazione sensore luminosità
Implementazione sensore temperatura
Gestire interazione e collegamento fra: le aree e i sensori*
Gestire interazione e collegamento fra: l'environment e i sensori*
Consentire la gestione di un'area Refactor e ottimizzazione controllers dell'applicazione
Collegare mvc dettaglio aree all'applicazione*
Miglioramento reattività dell'applicazione Gestire tramite reactive programming le richieste per i parametri delle piante
Miglioramento dell'esperienza utente Sistemare elementi dell'interfaccia grafica*
Verifica del coretto funzionamento dell'applicazione tramite test manuali*
Miglioramento stile schermata selezione delle piante
Refactor registrazione callbacks timer*
Guida utente per l'applicazione Scrivere guida utente per l'applicazione*
Documentazione Raffinare diagrammi UML*
Terminare report*
Applicazione finale Operazioni finali di refactoring del codice, miglioramento dei test e ottimizzazione degli imports*
Realizzare file .jar*
Valutare coverage finale ottenuta*
Effettuare prima release dell'applicazione*

Yan Elena

Macro-obiettivo Task
Selezionare la città di ubicazione della serra Creare layout schermata di selezione della città
Realizzazione live search delle città
Avvio della simulazione Gestire l'aggiornamento dello scorrere del tempo
Gestire la modifica della velocità dello scorre del tempo
Consentire lo scorrimento fra le diverse pagine dell'applicazione Refactoring schermata BaseView, con aggiunta pulsanti per la navigazione
Realizzazione architettura MVC tramite cake pattern per la selezione della città
Realizzazione MVC globale della simulazione*
Realizzazione collegamento fra i diversi MVC*
Visualizzare lo stato aggiornato delle singole aree Impostazione formula di aggiornamento dei valori dei sensori*
Definizione interfaccia sensori*
Implementazione sensore umidità dell'aria
Implementazione sensore umidità del terreno
Gestire interazione e collegamento fra: le aree e i sensori*
Gestire interazione e collegamento fra: l'environment e i sensori*
Consentire la gestione di un'area Realizzare controller dettaglio aree*
Realizzare view dettaglio aree
Collegare mvc dettaglio aree all'applicazione*
Miglioramento dell'esperienza utente Sistemare stile pulsanti delle diverse schermate
Sistemare elementi dell'interfaccia grafica*
Verifica del coretto funzionamento dell'applicazione tramite test manuali*
Aggiunta icona applicazione
Refactor registrazione callbacks timer*
Refactor gestione stati pulsanti della schermata dettaglio area
Documentazione Raffinare diagrammi UML*
Terminare report*
Applicazione finale Operazioni finali di refactoring del codice, miglioramento dei test e ottimizzazione degli imports*
Realizzare file .jar*
Valutare coverage finale ottenuta*
Effettuare prima release dell'applicazione*

* questi task sono stati completati a seguito di una collaborazione fra più componenti del gruppo (vedere i diversi product backlog relativi al progetto per maggiori dettagli).

1.2.1 Aggregazione dei risultati

Il progetto è stato realizzato attraverso l’utilizzo di un repository GitHub.

In questo modo, dopo che ad ogni membro del gruppo sono stati affidati i diversi compiti da svolgere, è possibile procedere all’esecuzione dei tasks in modo indipendente, aprendo un proprio branch di lavoro sul repository del progetto.

Al termine dello sprint, i diversi branches vengono chiusi e uniti, tramite l’operazione di merge, al branch di sviluppo principale (develop).

Tuttavia, nel caso in cui il completamento del lavoro di uno dipenda dall’esecuzione di quello di altri, i membri coinvolti collaborano al fine di unire i diversi branches o ne creano di nuovi da cui partire, in modo da proseguire e completare i tasks successivi.

Una volta che tutti i lavori per il progetto sono stati terminati e si è quindi pronti per la prima release dell’applicazione, si provvederà all’unione del branch develop con il branch master, che contiene le versioni rilasciate del progetto.

1.2.2 Revisione dei task

Al termine di ogni sprint, si procede alla revisione del lavoro svolto durante la settimana. In particolare, si verifica la realizzazione dei tasks affidati a ogni membro del gruppo, analizzandone la loro completezza in base alla definition of done stabilita all’inizio del progetto.

Se durante l’incontro ci si rende conto di alcuni aspetti del lavoro svolto che potrebbero essere migliorati o di incompletezze nel risultato ottenuto, si richiede al rispettivo membro responsabile di correggere o completare i lavori che gli sono stati affidati, prima di proseguire con il successivo sprint.

Infine, a seguito dell’incontro di sprint review, si può decidere di effettuare il refactoring di elementi già realizzati, dando luogo a nuovi tasks che dovranno essere realizzati nello sprint successivo.

1.3 Strumenti utilizzati

Per la realizzazione del progetto sono stati utilizzati differenti tool a supporto del processo di sviluppo. Tali strumenti hanno come obiettivo quello di agevolare gli sviluppatori durante tutta la realizzazione del progetto, cercando di automatizzarne i diversi aspetti.

Pertanto, gli strumenti impiegati per il progetto sono riportati di seguito: