Processo di sviluppo

Di seguito è descritta la metodologia di sviluppo adottata, il sistema di versionamento con le relative convenzioni e le pipeline di CI/CD implementate durante il progetto.

Metodologia

È stato adottato un approccio SCRUM-inspired, che ha permesso di gestire le attività in modo agile ed iterativo. Questo ha garantito flessibilità e la capacità di adattarsi rapidamente ai cambiamenti dei requisiti.

Il processo è stato affinato progressivamente attraverso cicli di retrospettiva e miglioramento continuo, così da ottimizzare sia le pratiche di lavoro che la collaborazione all'interno del team. Con il tempo, il gruppo ha acquisito maggiore maturità, consolidando sia le competenze tecniche che quelle organizzative, con un impatto positivo sull'efficacia complessiva dello sviluppo.

Inoltre al termine di ogni sprint, a partire dal secondo, sono state pubblicate delle release del software, in modo da fornire risultati tangibili e con già un valore allo stakeholder.

Ruoli

• Product Owner – Pier Costante Babini
  Si è occupato di mantenere la visione complessiva del progetto allineata con le richieste del committente, gestendo le priorità e coordinando il team di sviluppo. Ha contribuito anche direttamente alla parte implementativa.

• Scrum Master – Michele Monti
  Ha facilitato l'adozione delle pratiche agili, supportato l'organizzazione del lavoro e rimosso eventuali ostacoli che rallentavano il team. Inoltre, ha partecipato attivamente allo sviluppo.

• Stakeholder – Marco Morelli
  In qualità di committente ha definito obiettivi e requisiti del progetto, garantendo attenzione alla qualità e all'usabilità del prodotto. Ha ricoperto anche un ruolo operativo nello sviluppo.

Meeting

Le tipologie di meeting utilizzate nel corso del progetto sono state le seguenti:

• Initial planning: incontro iniziale (kick-off) che ha coinvolto l'intero team. In questa fase sono stati definiti il Product Backlog, gli obiettivi del primo sprint e le tecnologie da adottare, selezionate in funzione delle necessità tecniche e degli obiettivi di lungo periodo del progetto.

• Sprint review e retrospettiva: al termine di ogni sprint è stata organizzata la Sprint Review, durante la quale il team ha presentato i risultati raggiunti allo stakeholder, raccogliendo feedback e identificando possibili aree di miglioramento del prodotto. Successivamente si è svolta la Sprint Retrospective, focalizzata sull'analisi del processo di lavoro e sull'individuazione di azioni concrete per migliorare la qualità e l'efficacia della collaborazione del team

• Sprint planning: meeting di pianificazione in cui il team, insieme al Product Owner, ha selezionato le attività da svolgere nel successivo sprint e ne ha definito lo Sprint Goal, assicurandosi che fosse chiaro e condiviso.

• Daily Scrum: breve aggiornamento quotidiano della durata di circa 15–30 minuti, volto a sincronizzare il lavoro del team, discutere i progressi rispetto allo Sprint Goal ed evidenziare eventuali ostacoli. Quando necessario, sono stati organizzati ulteriori incontri di approfondimento per analizzare in dettaglio specifici aspetti progettuali.

Notion

Per la gestione del Product Backlog, degli sprint e delle attività è stato utilizzato Notion. Durante ogni Sprint Planning gli item presenti nel backlog sono stati suddivisi in sotto-task da svolgere nello sprint settimanale. L'assegnazione è stata gestita secondo le seguenti modalità:

• i task più rilevanti sono stati assegnati direttamente ai membri del team;
• i task rimanenti potevano essere scelti autonomamente dai membri che avevano completato i propri incarichi;
• i task non completati nello sprint precedente sono stati riassegnati allo sprint successivo.

DVCS

Per la gestione del codice sorgente è stato adottato il modello GitFlow, che prevede l'utilizzo di diversi branch. In particolare, il branch develop è stato impiegato come principale punto di integrazione dei branch secondari, mentre il branch main è stato aggiornato esclusivamente in occasione delle release.

Conventional commit

Per la stesura dei messaggi di commit è stata utilizzata la Conventional Commits.

Conventional branch

Per la denominazione dei branch è stata utilizzata la Conventional Branch.

Definition of Done

Una feature è considerata finita ed integrabile in develop se soddisfa i seguenti criteri:

• Sono eseguite con successo le pipeline di CI/CD, che controllano:
  • building del progetto
  • testing del progetto
  • formattazione del codice
  • correttezza della convezione utilizzata per i commit
• Il codice è stato correttamente documentato

Testing

Per garantire la qualità e la correttezza delle funzionalità implementate, è stato adottato il paradigma Test Driven Development (TDD), applicato in particolare al model e controller del progetto. Tale approccio consente di individuare e correggere tempestivamente eventuali bug a livello di singoli componenti durante le fasi di sviluppo, favorendo un ciclo di feedback continuo e affidabile

Il processo di sviluppo secondo TDD si articola in tre fasi principali:

1. Fase Red (testing): si scrive un test che descrive il comportamento atteso di un componente o di una funzionalità. Poiché l'implementazione non è ancora presente, il test fallisce inizialmente.

2. Fase Green (implementation): si procede con l'implementazione necessaria affinché il test precedentemente definito venga superato con successo.

3. Fase Refactor: una volta superato il test, si effettua il refactoring del codice per migliorarne qualità, leggibilità e manutenibilità, mantenendo comunque i test positivi.

Building

Il build tool scelto è stato Sbt, per gestire:

• Le dipendenze del progetto
• L'esecuzione dei test
• La generazione della documentazione
• La creazione degli artefatti
• La produzione del report di coverage

Code Quality

Per garantire la qualità del codice sono stati utilizzati i seguenti strumenti:

• Scalafmt, per garantire la qualità e la formattazione automatica del codice.
• Wartremover, per favorire una corretta adesione al paradigma funzionale.

CI/CD

Per le attività di Continuous Integration e Continuous Delivery sono state utilizzate le GitHub Actions, definendo diversi workflow specifici:

• BuildAndTest: esegue la build del progetto e l'avvio dei test su diverse configurazioni (Windows, macOS, Ubuntu).

• DeployReportSite: genera la documentazione del progetto, comprensiva di Scaladoc e report di coverage, e ne effettua il deploy su GitHub Pages.

• Release: gestisce il rilascio di una nuova versione del progetto su GitHub, includendo la generazione del file JAR e la sua pubblicazione tra gli asset della release.

NOTA: la pipeline di release viene eseguita esclusivamente a seguito dell'accettazione di una pull request su main. La pipeline DeployReportSite, invece, è attiva solo su main e sui branch docs/*.

Report

Per il report del progetto è stato utilizzato VitePress, un generatore di siti statici basato su Vue.js che ha permesso la generazione ed il caricamento su Github Pages del report in modo semplice e veloce, versionando anche ogni sezione Markdown.