Upload
iquii
View
262
Download
0
Embed Size (px)
Citation preview
S O F T WA R E E N G I N E E R I N G P R A C T I C E S
O P E N I Q U I I - 1 5 O T T O B R E 2 0 1 5
H A S H TA G : # O P E N I Q U I I
PA O L O M U S O L I N O
I O S S O F T W A R E E N G I N E E R I N I Q U I I
T W I T T E R : @ P M U S O L I N O
C H I S O N O
S V I L U P PA R E S O F T W A R E È F I G O . T U T T I S A N N O S C R I V E R E C O D I C E .
P O C H I S A N N O S V I L U P PA R E S O F T W A R E .
L’ E V O L U Z I O N E D I U N I N G E G N E R E S O F T W A R E
1 ° A N N O
Fonte: https://medium.com/@webseanhickey/the-evolution-of-a-software-engineer-db854689243
2 ° A N N O
3 ° A N N O
5 ° A N N O
1 0 ° A N N O
L E S S I S M O R E
I P R O B L E M I N E L L O S V I L U P P O S O F T W A R E
D E A D L I N E M A N C A T E C O S T I E X T R A
F U N Z I O N I M A I U T I L I Z Z A T E R I S C H I S C O N O S C I U T I
I M P I E G A T I N O N M O T I VA T I B U G E D E R R O R I
S I S T E M I L E G A C Y S V I L U P PA T O R I I N C O M P E T E N T I
T E C H N I C A L D E B T T R O P P O A LT O
La motivazione dello sviluppatore contribuisce alla qualità del software perché il programmatore/sviluppatore fa un lavoro di cui vede i risultati solo dopo molto tempo. Quindi è importante non generare frustrazione.
– A G I L E R E P O R T 2 0 1 3 D I A G I L E T U R K E Y
Il 50% dei progetti IT in Turchia, vengono cestinati.
Smirne
– M E R C E R C O N S U LT I N G
L’80% dei progetti IT nel mondo costano di più rispetto al loro effettivo ritorno.
8 R E G O L E D A T E N E R E A M E N T E
• Lo scopo finale del progetto deve essere la soddisfazione del cliente
• In genere, il cliente non sa cosa vuole realmente
• L’incertezza esiste in ogni fase del processo
• I requisiti iniziali cambieranno
• Lo sviluppo software non è solo programmazione
• Il software necessita di manutenzione dopo esser passato in produzione
• Lo sviluppo software è un’attività di teamwork
• Prima o poi pagherai il technical debt
A P P R O C C I O C L A S S I C O M E T O D O W A T E R FA L L
1) Analisi dei requisiti 2) Progettazione 3) Sviluppo 4) Collaudo 5) Manutenzione
I L P R O C E S S O D I S V I L U P P O S O F T W A R E D E I N O S T R I S O G N IO G N I S T E P PA R T E I N S E Q U E N Z A
I M P L E M E N TA Z I O N E
D E S I G N
R I C H I E S T E
M A N U T E N Z I O N E
I M P L E M E N TA Z I O N E
D E S I G N
R I C H I E S T E
M A N U T E N Z I O N E
L A R E A LTÀ D E L L O S V I L U P P O S O F T W A R E
I M P L E M E N TA Z I O N E
D E S I G N
R I C H I E S T E
M A N U T E N Z I O N E
M A N U T E N Z I O N E
R I C H I E S T E
R I C H I E S T E
I M P L E M E N TA Z I O N E
R I C H I E S T E
M A N U T E N Z I O N E I M P L E M E N TA Z I O N E
D E S I G N
M A N U T E N Z I O N E
I M P L E M E N TA Z I O N E
R I C H I E S T E
R I C H I E S T E
M A N U T E N Z I O N E
D E S I G N
I M P L E M E N TA Z I O N E
D E S I G N
M A N U T E N Z I O N E
G L I S V I L U P PAT O R I S O N O TA L E N T I ,
N O N S E M P L I C I R I S O R S E
S V I L U P PA R ET I P S & T R I C K S G I T
C O D E B R A N C H I N G
C O D E / P E E R R E V I E W
C L E A N C O D E P R I N C I P L E S
PA I R P R O G R A M M I N G
R E FA C T O R I N GS V I L U P PA C O M E S E
F O S S E O P E N S O U R C E
O W N E R S H I P C O L L E T T I VA
T E S T I N G E F E E D B A C KS E N Z A , N O N S I R A G G I U N G E A L C U N G O A L
A / B T E S T I N GT D D
U N I T T E S TC O N T I N U O U S I N T E G R AT I O N
T D D - T E S T D R I V E N D E V E L O P M E N T
1) Aggiungere i test 2) Test che falliscono 3) Scrivere codice che non fa fallire i test 4) Far girare i test 5) Refactoring
C A U S E D I U N P E S S I M O S V I L U P P O S O F T WA R E
• Comunicazioni non chiare • Complessità elevata • Test insufficienti • Gestione dei requisiti insufficiente • Incoerenze rilevanti tra requisiti, design e implementazione
• Architettura fragile
S I N T O M I D E I P R O B L E M I N E L L O S V I L U P P O S O F T WA R E
• Pessima qualità del software • Performance inaccettabili • Software difficile da manutenere ed estendere
• Cattiva comprensione delle esigenze degli utenti finali
• Incapacità di far fronte alle nuove esigenze del cliente
• Scoperta di gravi carenze nel progetto, solo alla fine
C O S A V O G L I A M O
• Costruire software di alta qualità che sia robusto, stabile, flessibile, estendibile.
• Un team motivato e altamente competente.
• Persone che si adattano ad ogni circostanza, in maniera veloce ed efficiente.
– A LT UĞ B I L G I N A LT I N TAŞ
“Non c’è metodologia che funzioni se non si è appassionati e disciplinati”.
Q U A L I S O N O L E B U O N E P R AT I C H E D A U S A R E I N I N G E G N E R I A D E L S O F T W A R E ?
• Sviluppo iterativo
• Gestire i requisiti
• Architettura basata su componenti
• Modellare visivamente il software
• Verifica della qualità
• Controllo sui cambiamenti
S V I L U P P O I T E R AT I V O
• Le criticità sono risolte prima di effettuare grossi investimenti
• L’iterazione iniziale permette un feedback immediato dell’utente/cliente
• I test e l’integrazione sono continui • Gli obiettivi di ogni iterazione forniscono un focus a breve termine
G E S T I R E I R E Q U I S I T I
• I requisiti cambiano - cercare di evitare i cambiamenti in fase di sviluppo (o comunque durante una iterazione)
• La comprensione dei requisiti desiderati dal cliente cresce col tempo
• Capire con il cliente ciò che il sistema deve fare, non come deve farlo
• Tenere traccia dei requisiti passati e futuri, notificando a chi di competenza un cambiamento degli stessi.
A R C H I T E T T U R A B A S ATA S U C O M P O N E N T I
• Usare singoli componenti ne permette il riuso (Library Oriented Programming)
• I componenti, velocizzano moltissimo lo sviluppo del software e lo rendono stabile e modulare
• La manutenibilità e l’estensibilità aumenta • In un team di sviluppatori, permette una divisione dei ruoli sul singolo software
M O D E L L A R E V I S I VA M E N T E I L S O F T W A R E
• Modellare il software visivamente permette di gestire l’aumento della complessità nel tempo
• Permette di capire a colpo d’occhio struttura e comportamento dei componenti
• Nasconde o espone dei dettagli in base al compito di chi sta visualizzando il modello
• Evita ambiguità nella comunicazione
V E R I F I C A D E L L A Q U A L I TÀ
• Cos’è la qualità? E’ la caratteristica di creare un prodotto che soddisfa o supera i requisiti del cliente.
• I problemi software (cercare e fixare i bug) sono più costosi in termini di tempo, rispetto allo sviluppo stesso delle singole funzioni.
• Sviluppare una suite di test per ogni iterazione che comprendono test di funzionalità, affidabilità e performance.
C O N T R O L L O S U I C A M B I A M E N T I
• Senza controllo, lo sviluppo parallelo in team finisce in caos.
• Scomporre l’architettura in problemi più piccoli, e assegnare ai membri del team singole responsabilità per ogni sottosistema.
• Isolare i sottosistemi, in maniera tale che solo il responsabile possa effettuare modifiche.
• Istituire un meccanismo di controllo delle modifiche: ogni modifica ha una priorità, ogni modifica viene valutata, viene stilato un piano per introdurre il cambiamento in una particolare iterazione.
Q U A L È I L V O S T R O A P P R O C C I O ?
Segui @iquii