Home
Questo progetto si propone di implementare un gestionale finalizzato a digitalizzare le principali mansioni di una scuola guida. In particolare l’obiettivo è quello di rendere semplice e rapida la gestione delle prenotazioni delle guide pratiche.
| Cognome Nome | Matricola | Account Github |
|---|---|---|
| Composta Elisa | 209077 | elisacomposta |
| Lorenzetti Andrea | 209548 | andrea-lorenzetti |
| Scevaroli Simone | 209427 | simonescevaroli |
| Zeni Luca | 210554 | ZeniiL |
Documentazione apiary qui.
Product backlog qui.
Test cases qui.
Backlog sprint 1 qui.
Backlog sprint 2 qui.
Nota: una copia dei documenti sopra riportati si trova in coda a questo documento.
Il file index.js serve a connettersi al mongodb locale e a mettersi in ascolto in una porta specifica (nel nostro caso la 8000).
Successivamente nella cartella app troviamo il file app.js, che contiene tutti i midllewares e i file da richiamare per fare il parsing corretto con le route, i suddetti file contenenti le api che gestiscono le route, i file di test e infine la cartella models contenente gli "schema" di mongodb.
La cartella static contiene i file necessari alla realizzazione della UI.
La strategia scelta per questo progetto è la "git feature branch workflow" in quanto risponde alle nostre esigenze di mantenere sempre il codice nel main branch funzionante e ci permette di dividere le feature da implementare tra i vari membri del gruppo, ognuno dei quali lavorerà su branch specifici a seconda di ciò che gli è stato assegnato.
È possibile visionare il backlog
qui .
È stato definito il concetto di done adottato dal team durante tutto lo sviluppo software dell'applicazione. Una feature è nello stato done quando:
- Il codice è stato testato e risulta funzionante rispetto al suo scopo, definito nella documentazione di progettazione delle user stories
- Il codice è ben commentato affinché ogni membro del gruppo capisca in breve tempo cosa faccia una particolare funzione
- Le API utilizzate sono state documentate su APIary
- Deve essere stato fatto il merge del codice nel branch main
Il goal per questo primo sprint è quello di sviluppare e documentare le API e le relative UI per alcune delle funzionalità tra quelle che saranno disponibili al termine del secondo sprint. Queste sono state scelte coerentemente rispettando la capacità di lavoro del team durante lo sprint #1 e basandosi inoltre sulla priorità definita nel product backlog.
È possibile vedere lo sprint backlog
qui.
All'inizio dello sprint il team si è riunito per pianificare il lavoro delle settimane successive.
Durante tale incontro, è stata calcolata la capacity del team (in numero di ore) e una stima della velocity ideale, in base alla disponibilità di ciascun membro.
Sono stati quindi definiti i task da completare durante il primo sprint, e per ciascuno di essi è stato stimato l'effort (in ore).
L'intero team ha poi collaborato, sempre in tale meeting, al design delle API, in modo che tutti potessero partire con delle linee guida uniformi e coerenti.
Tali task sono poi stati assegnati ai vari membri.
Nota: a ciascun membro sono state assegnate task eterogenee, in modo che ciascuno potesse sviluppare skill trasversali.
Nota: le capacità dei membri del team sono tra loro molto diverse (per motivi universitari), pertanto la quantità e il tipo di task sono state assegnate di conseguenza.
Durante i meeting, tenuti regolarmente durante lo sprint, ogni membro del team esponeva il proprio operato, definendo cosa aveva svolto, le difficoltà incontrate e le soluzioni attuate.
Dopo aver fatto il punto della situazione generale, si programmava il lavoro da svolgere fino al meeting successivo.
È stata rivista la priorità della feature "Modifica disponibilità", in quanto inizialmente era stata attribuita un'importanza troppo elevata.
È possibile vedere la descrizione dei test cases qui.
Al termine dello sprint è stato tenuto un meeting per fare il punto della situazione, di seguito esposta.
Durante il primo sprint, i daily scrum meeting non sono sempre stati brevi. Ci proponiamo quindi, per il secondo sprint, di ottimizzare i tempi per rientrare nei 15 minuti che avevamo previsto.
Durante questo sprint abbiamo scelto di svolgere pochi task perché eravamo consapevoli di necessitare del tempo per approfondire gli argomenti, senza i quali non saremmo riusciti a portare a termine il lavoro, dal momento che nessuno di noi aveva conoscenze pregresse in merito.
Ci aspettiamo quindi, nel prossimo sprint, di essere in grado di svolgere più task e con maggiore efficienza, ora che abbiamo assimilato le conoscenze necessarie.
Il goal per questo secondo ed ultimo sprint è quello di sviluppare e documentare le API e le relative UI per le funzionalità non considerate nello sprint #1 e inoltre di rifinire le API del primo sprint, completandole con il testing, da fare anche per tutte le nuove funzioni. Infine, una volta compiuta tutta la fase software, fare il deploy dell'applicazione.
È possibile vedere lo sprint backlog
qui.
All'inizio dello sprint, così come per il primo sprint, il team si è riunito per pianificare il lavoro delle due settimane successive.
È stata dunque calcolata la capacity del team e una stima della velocity ideale, in base alla disponibilità di ciascun membro.
Durante il primo sprint è stata acquisita da parte del team una consapevolezza maggiore sulle task da completare per prime, individuandone alcune come propedeutiche per la corretta funzione di altri task; proprio per questo motivo sono state riviste le priorità per alcune user storyese per ciascuna di esse è stato stimato l'effort (in ore), che è calato in media grazie alle conoscenze e alla manualità assimilati durante il primo sprint.
Infine i task sono poi stati assegnati ai vari membri.
Nota: così come per il primo sprint, a ciascun membro sono state assegnate task eterogenee, in modo che ciascuno potesse migliorare e rafforzare le skill trasversali apprese nello sprint #1.
Nota: le capacità dei membri del team sono tra loro molto diverse (per motivi universitari), pertanto la quantità e il tipo di task sono state assegnate di conseguenza.
Durante i regolari meeting durante lo sprint, ciascun membro del team illustrava agli altri il lavoro svolto, soffermandosi sulle difficoltà incontrate e le soluzioni attuate affinché possano essere di aiuto per lo sviluppo di task analoghe.
Dopo aver fatto il punto della situazione generale, si programmava il lavoro da svolgere fino al meeting successivo.
Così come era stato menzionato nella sezione di Sprint planning, la priorità di alcune task è stata rivista (come per esempio per la registrazione e i login) perché funzionali allo sviluppo di tutte le altre API. Inoltre si è ridotta la priorità della funzionalità "Modifica disponibilità", considerata di secondaria importanza e a causa di ciò non è stato possibile inserirla nello sprint #2 per motivi di tempo, dovuti alla capacity del team. Si lascia comunque la possibilità di implementarla in un futuro sprint (se previsto).
È possibile vedere la descrizione dei test cases
qui.
Durante una riunione con tutti i membri del team, si è pensato di fare i test solo sulle funzionalità di maggior rilevanza, tralasciando quelle più banali (come la sezione help).
Al termine dello sprint è stato tenuto un meeting per fare il punto della situazione, di seguito esposta.
Come ci si era prefissati al termine del primo sprint, i meeting sono calati nella durata, riuscendo a rientrare nei 15 minuti previsti. Nonostante ciò è calato anche il numero dei meeting svolti, causa impegni dei vari membri: ci si propone dunque di rialzare il numero dei meeting durante il prossimo sprint (se previsto) in quanto di estrema importanza per la coesione del team stesso.
Inoltre il tempo impiegato per svolgere le varie task è diminuito grazie alle competenze acquisite nel primo sprint, come era stato preventivato. Anche il numero di task svolte è aumentato, svolgendo molto più lavoro nello stesso lasso di tempo.
La struttura dell'applicazione è stata organizzata in questo modo:
- A sinistra nell'immagine (lato client) abbiamo il browser dell'user che utilizza le parti di frontend fornite dal server. Il Browser permette l'invio delle informazioni necessarie per l'utilizzo dei servizi offerti.
- Centralmente nell'immagine (lato server) abbiamo il backend e il frontend della nostra applicazione rilasciata al pubblico sulla piattaforma di hosting in cloud, Heroku. Il frontend, all'interno della cartella static, è composto da pagine statiche e da script di javascript che vengono inviati al Browser del client se richiesti. Il backend contiene la gestione delle richieste e delle risposte HTTP, la parte di gestione del Database e le API, che sincronizzano tutti questi sistemi utilizzati.
- La terza parte della webApplication è la parte di storage permanente dei dati. Questo ruolo è vestito dal servizio MongoDB in Cloud di Atlas. Il database e il backend, pur risiedendo in zone diverse del Cloud, vengono considerati comunque come facenti parte del lato server.
Per quanto riguarda la CI, ci siamo preoccupati di mantenere sempre aggiornata la nostra Web Application con codice testato e funzionante. In particolare, grazie al servizio Git-Actions fornito da Github, abbiamo indicato che il deploy di nuovo codice su Heroku della nostra applicazione deve prima passare i test gestiti attraverso il framework "jest". Git-Actions si occupa di testare il nuovo codice inserito nel branch "MAIN" e per farlo si avvale di un database di testing diverso dal database su cui vengono fatte le effettive operazioni degli utilizzatori della nostra applicazione.
I linguaggi di programmazione utilizzati per sviluppare il nostro progetto sono stati:
- HTML
- Javascript
- NodeJS
NodeJS in particolare è stato utilizzato in fase di produzione dell'applicazione, con i seguenti framework:
- Express: per gestire richieste http
- Body-parser: per gestire il corpo delle richieste HTTP Post
- Cors: per gestire richieste di domini differenti
- Jsonwebtoken: per gestire la generazione e la validazione dei token utilizzati in fase di autenticazione e utilizzo delle API
- Mongoose: per interagire con il database MongoDB in cloud oppure in locale
- Dotenv: per gestire le variabili d'ambiente dell'applicazione
In fase di sviluppo, invece, ai framework precedenti sono da aggiungere i seguenti framework di NodeJS:
- Jest: per la gestione dei test
- Supertest: per testare le API
Durante lo sviluppo dell’intero progetto, la prova sul campo di molte tecniche ha permesso di assimilarle meglio e di poter capire a pieno il vantaggio che esse portano. Il modello Scrum è stato a nostro avviso essenziale per la corretta riuscita del progetto, in quanto crediamo che la comunicazione e la collaborazione fra i membri del team sia di vitale importanza, tanto quanto la comunicazione con il customer finale. Ogni membro del team ha inoltre appreso ogni parte che compone lo sviluppo di un software, partendo dalla definizione del design, all’implementazione del backend, del frontend fino al deploy, permettendo anche di scoprire la parte che più preferiscono e su cui dedicheranno uno studio futuro più approfondito.
L’applicazione da noi sviluppata si è rivelata al di sopra delle nostre aspettative, considerando che le conoscenze di partenza dei linguaggi di programmazione utilizzati era pressoché nulla. L'impegno nel tempo che avevamo a disposizione e la costanza ci hanno permesso di completarla per tempo, con professionalità e con completezza, raggiungendo il compimento di ogni obbiettivo prefissato nei documenti "Backlog" redatti e nei quotidiani meeting tenuti.
Questa esperienza ci ha permesso di avere una panoramica generale di come lo sviluppo di un software viene organizzato e ha consentito a ciascuno di noi di vivere in prima persona ogni fase di questa progettazione, rendendoci consapevoli e facendoci assaporare quelle che potrebbero essere le attività quotidiane di un team di sviluppatori.
Riportiamo nel seguito le credenziali di alcuni utenti già esistenti nel database, in modo da semplificare la prova di utilizzo dell'applicazione.
Nota: l'account della segreteria è definito di default dall'applicazione, invece istruttori e studenti possono essere facilmente registrati.
-
Account segreteria:
nome utente: admin
password: admin -
Account istruttore:
nome utente: elon.musk
password: pass -
Account studente:
nome utente: foglio_rosa2000
password: pass