Software Engineering Practices - [#OpenIQUII - Workshop]

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