Progetto TraWell
Laurea Magistrale in Informatica - Università di Salerno
Corso Di Gestione Progetti Software - Prof.ssa F. Ferrucci
PROJECT MANAGMENT

Outline
● Gestione delle risorse
● Pianificazione
● Costi
● Monitoraggio attività
● Qualità
● Rischi
● Conclusioni

LA PIATTAFORMA TRAWELL
Una piattaforma Web per gli appassionati di viaggio che
permette:
● Condivisione di esperienze di viaggio
● Creazione di gruppi di viaggio
● Creazione di itinerari di viaggio
● Condivisione di servizi di car sharing
● Creazione di wallet per i viaggi

Gestione delle
risorse

Trawell Team

Analisi del sociogramma di Moreno
● Individuare le relazioni all’interno del
team
● Questionari basati sulla condivisione
di esperienze lavorative, esperienze
universitarie e tempo libero
● Creazione di due sotto-team
● Assegnazione dei ruoli

Organization Breakdown Structure

OBS
Filomena Ferrucci
Top Manager & Sponsor
Alexander Minichino
Project Manager
Aniello Florido
Project Manager

OBS
Filomena Ferrucci
Top Manager &
Sponsor
Alexander Minichino
Project Manager
Aniello Florido
Project Manager
Paolo Fasano
Team Leader
Vincent Milione
Team Leader
Mario Paone
Team Member
Gaetano Ruggiero
Team Member
Umberto Russomando
Team Member
Vincenzo Lamberti
Team Member
Davide Alfieri
Team Member

Tools di comunicazione & PM
● Comunicazione Formale
○ Slack
● Comunicazione Informale
○ Telegram
● Managment
○ Asana
○ Microsoft Project
● Condivisione Documenti
○ Google Drive

MOI
Motivation Organization Innovation

STRUTTURA MEETING
Revisione dei
task precedenti
Valutazione dei
progressi del
progetto
Analisi dei rischi Pianificazione task
futuri

Comunicazioni con Top Manager & Sponsor
Status report Agende & minute Email

Valutazioni Team
● Effettuate a ridosso del raggiungimento delle milestone
○ Partendo dal RAD completo
○ Suddividendo lo sviluppo & testing in due fasi
■ Iniziale: Configurazione ambiente, messa in pratica dei concetti illustrati nelle sessioni di
training, inizio dello sviluppo vero e proprio con annesso testing.
■ Finale: Conclusione del coding & testing, risoluzione bug, migliorie e deploy.
○ Utilizzando quattro diversi parametri di giudizio per ogni team member:
Proattività Rispetto Qualità degli
artefatti
Autonomia

Andamento Delle Valutazioni

Pianificazione

Planning:WBS

Costi

50h x 7 TM = 350h - 11.18€/h lordi per ogni TM

50h x 2 PM = 100h - 22,37€/h lordi per ogni PM
50h x 7 TM = 350h
11.18€/h lordi per
ogni TM

930,36€ per un abbonamento Cloud per i primi tre anni
50h x 7 TM = 350h
11.18€/h lordi per
ogni TM
50h x 2 PM = 100h
22,37€/h lordi per
ogni PM

3000€ campagna social su Facebook per 60 giorni
50h x 7 TM = 350h
11.18€/h lordi per
ogni TM
50h x 2 PM = 100h
22,37€/h lordi per
ogni PM
930,36€ per un
abbonamento Cloud
per i primi tre anni

50h x 7 TM = 350h
11.18€/h lordi per
ogni TM
50h x 2 PM = 100h
22,37€/h lordi per
ogni PM
3000€ campagna
social su Facebook
per 60 giorni
8052€ costo annuale per la manutenzione
930,36€ per un
abbonamento Cloud
per i primi tre anni

EVM
Trawell RAD Funzionale + kick off RAD Completo SDD & System TC ODD & Integration TC Implementazione & TR
Metric 14/11/2019 24/11/2019 06/12/2019 16/12/2019 15/01/2020
Budget at Completion
(BAC) € 385,71 € 754,58 € 1.403,02 € 1.973,20 € 3.918,45
Earned Value (EV) € 385,71 € 754,58 € 1.403,02 € 1.973,20 € 3.918,45
Actual Cost (AC) € 378,78 € 770,08 € 1.329,08 € 1.889,32 € 4.293,02
Planned Value (PV) € 385,71 € 754,58 € 1.403,02 € 1.973,20 € 3.918,45
%Progress 100% 100% 100% 100% 100%
Cost Variance (CV) € 6,93 -€ 15,50 € 73,94 € 83,88 -€ 374,57
Schedule Variance (SV) € 0,00 € 0,00 € 0,00 € 0,00 € 0,00
Cost Performance Index
(CPI) € 1,02 € 0,98 € 1,06 € 1,04 € 0,91
Schedule Performance
Index (SPI) € 1,00 € 1,00 € 1,00 € 1,00 € 1,00
Estimate to Completion
(ETC) € 0,00 € 0,00 € 0,00 € 0,00 € 0,00
Estimate at Completion
(EAC) € 378,78 € 770,08 € 1.329,08 € 1.889,32 € 4.293,02
Variance at Completion
(VAC) € 6,93 -€ 15,50 € 73,94 € 83,88 -€ 374,57
Stato GREEN YELLOW GREEN GREEN YELLOW

EVM

EVM

Monitoraggio
attività

Supervisione e versioning
Dopo opportune valutazioni si è deciso di adottare un approccio “open-source-like” al
controllo di versione.
Pertanto, abbiamo deciso di adottare il modus operandi della più grande fonte di
progetti IT open al mondo.

Github flow
Create a branch
“Sviluppa le tue ideee senza compromettere il master”

Github flow
Create, edit and commit
“Apporta modifiche e aggiungile al tuo branch”

Github flow
Open a Pull Request
“Avvia una discussione sui tuoi commit e richiedi l’approvazione delle modifiche”

Github flow
Discuss and review your code
“Discuti con la comunity dei cambiamenti che hai effettuato”

Github flow
Deploy
“Build, test, verifica che le tue modifiche non provochino difetti in produzione”

Github flow
Merge
“É tempo di effettuare il merge con il master!”

Dalla teoria alla pratica

/alexminichino/trawell
/PFasano99/trawell
/Renerine/trawell
/PFasano99/trawell:
/PFasano99/trawell
/PFasano99/trawell
/Renerine/trawell
/Renerine/trawell
Fork Upstream Layer
Branching from master layer

/PFasano99/trawell
/Renerine/trawell
/PFasano99/trawell:
/PFasano99/trawell
/PFasano99/trawell
/Renerine/trawell
/Renerine/trawell
/alexminichino/trawell
Commit Layer

/PFasano99/trawell
/Renerine/trawell
/PFasano99/trawell:
/PFasano99/trawell
/PFasano99/trawell
/Renerine/trawell
/Renerine/trawell
/alexminichino/trawell
Pull request layer
Commit Layer
P
R

CI & CD2
● Continuous integration
○ Permette di effettuare il merge con il master molto spesso e facilemnte
○ Automatizza building e testing: le modifiche vengono convalidate e testate su una
build in automatico
○ Garantisce un maggior controllo sul codice
○ Evita che si verifichino failure dovute all’integrazione di nuove modifiche
○ Il sistema non viene mai “interrotto” da commit sul ramo principale

CI & CD2
● Continuous delivery
○ É un’estensione del CI
○ Permette il rilascio di funzionalità e modifiche in modo sostenibile
○ Automatizza il rilascio e rende molto semplice la distribuzione
● Continuous deployment
○ Ogni modifica che supera tutte le fasi della pipeline viene distribuita ai clienti finali
○ Non necessita di interventi umani
○ Un solo test fallito impedisce che tutte le nuove modifiche vadano in produzione
○ Accelera il processo di feedback con i clienti
○ Gli sviluppatori possono vedere il loro lavoro funzionante dopo pochi minuti dal
commit

Travis
● Continuous integration cloud based
● Permette di costruire pipeline complesse con
semplicità
● Si integra alla perfezione con Github
● Supporta tutti i linguaggi di programmazione
● Permette la distribuzione su piattafome diverse
● Offre numerosi strumenti di messaggistica e avviso in
caso di failure

Trawell Pipeline
Test suite
Travis CI
Build & test
Pull request
Report
Merge Master
Metrics &
Coverage
Deploy
platforms

Qualità

Quality
Metriche
Per quantificare la bontà dell’elaborato sono state adoperate le seguenti metriche:
● Code size:
○ Lines of Code (LOC)
○ Lines of comment
○ Comment percentage
● Complexity:
○ Complessità ciclomatica: conta il numero di percorsi attraverso il codice, ogni
volta che il flusso di controllo ha una biforcazione, il contatore della
complessità aumenta di 1, ogni funzione di base ha complessità ciclomatica
pari a 1. Inoltre, la CC fornisce un’indicazione sul test, minore è la
complessità e maggiore è la facilità di esecuzione dei test.
○ Complessità cognitiva: misura quanto è difficile comprendere il flusso di
controllo del codice.

Quality
Metriche
● Maintainability
○ Code smells: conta il numero di code smells, ovvero porzioni di codice che
potrebbero presentare difetti.
○ SQALE method:
■ Technical Debt: effort necessario stimato per correggere tutte le code smells
presenti.
■ Technical Debt ratio: rapporto tra il costo per sviluppare il software e il costo
per effettuare fix, questo parametro è definito come il rapporto tra il
“remediation cost” e il “development cost”, ovvero:
Remediation cost / (Cost to develop 1 line of code * Number of
lines of code)
Esempio: assumendo che il costo per sviluppare una linea di codice sia 30 min
(valore di default) e che il Remediation cost sia 30 min per una classe di LOC
pari a 50, avremo un Technical Debt ratio = 30/(30*50)= 0.02.

Quality
Metriche
● Coverage:
○ Line Coverage: misura il livello di copertura del codice sorgente di una suite di
test.
○ Decision (o Branch) Coverage: misura il livello di copertura dei costrutti
decisionali di una suite di test.

Quality
Usability test
Per testare l’usabilità del prodotto finale è stato condotto un questionario che mirava a
valutare le seguenti caratteristiche ritenute essenziali per la riuscita del prodotto:
● Understandability: rappresenta la capacità di un prodotto software di permettere
all’utente di capire le sue funzionalità e come poterla utilizzare con successo.
● Learnability: rappresenta la capacità di un prodotto software di permettere
all’utente di imparare ad utilizzare l’applicazione.
● Attractiveness: rappresenta la capacità di un prodotto software di risultare
“attraente” per l’utente. La qualità è relativa alla progettazione dell’aspetto grafico
delle sue interfacce, all’utilizzo dei colori e delle immagini, ecc.

I risultati

Code Size
LOC
Classi: 72

Code Size
LOC

Code Size
Methods
Metodi: 444

Complexity
Cyclomatic complexity
Di progetto: 289

Complexity
Cyclomatic complexity average for Method

Complexity
Cognitive Complexity
Di progetto: 289

Complexity
Cognitive complexity average for Method

Maintainability
Code Smells
Di progetto: 152

Complexity
Code Smells average for Method

Maintainability
Technical Debt
Di progetto: 1 D
6H

Maintainability
Technical Debt Ratio %
A
Di progetto:
0,8%

Coverage
Line coverage

Coverage
Decision coverage

Usability: analisi risultati
● Pro:
○ Piattaforma semplice da usare
○ La maggior parte degli utenti trova che l’interfaccia grafica sia accattivante
○ Poco tempo richiesto per imparare ad utilizzare la piattaforma
● Contro:
○ Alcuni utenti hanno ritenuto che ci fossero alcune incoerenze tra le funzionalità del sito

Rischi

● Identificati 15 eventi potenzialmente dannosi per il progetto Trawell
● Ogni evento è stato classificato per impatto e probabilità di verificarsi con:
○ Low
○ Medium
○ High
● Per ogni evento è stato definito un piano di contingenza
Rischi identificati

● R_2: Documentazione tecnicamente inadeguata
○ È stato nominato un responsabile di revisione e correzione ✔
● R_5: Eccessivo carico di lavoro:
○ Il carico di lavoro è stato ridistribuito e le risorse in difficoltà sono state affiancate
da altri team member ✔
● R_8: Scarsa padronanza delle tecnologie da parte dei team member
○ Sono state effettuate ulteriori sessioni di training per colmare eventuali lacune ✔
Rischi riscontrati - previsti

● Scarsa comunicazione tra i membri del team e lavoro poco coordinato
○ È stata eseguita un’analisi retrospettiva attraverso colloqui e questionari che ha
evidenziato la necessità da parte del team di avere uno o più team leader ✔
○ Il team è stato suddiviso in due sotto team a cui è stato assegnato un team leader ✔
○ È stato nominato un responsabile comunicazione ✔
Rischi riscontrati - non previsti

Conclusioni

● Aspetti positivi:
○ Buona gestione della schedulazione delle attività
○ Obiettivi dei PM quasi sempre chiari
○ Utili sessioni di training
○ Team generalmente soddisfatto
● Aspetti negativi:
○ Poco tempo a disposizione
○ Difficoltà nell’utilizzo di nuove tecnologie
Post-mortem Review

Cosa abbiamo imparato
● Il ruolo del PM è molto difficile
● Abbiamo migliorato le nostre capacità di comunicazione
● Effettuare una pianificazione corretta è di essenziale importanza
● Il monitoraggio costante è alla base del successo di un progetto

Grazie per l’attenzione!