Giovedì 15 ottobre 2015 si è tenuto il workshop #openIQUII dedicato alle Software Engineering Practices. Durante l'incontro abbiamo visto insieme quali sono i problemi maggiori per chi si cimenta nello sviluppo software, quali sono gli approcci giusti da utilizzare, come strutturare il design, quanto siano importanti i test, e come gestire le criticità.

1. 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

2. PA O L O M U S O L I N O
I O S S O F T WA 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

3. S V I L U P PA R E S O F T WA 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 WA R E .

4. 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 WA R E
1 ° A N N O
Fonte: https://medium.com/@webseanhickey/the-evolution-of-a-
software-engineer-db854689243

5. 2 ° A N N O

6. 3 ° A N N O

7. 5 ° A N N O

8. 1 0 ° A N N O
L E S S I S M O R E

9. 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
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.

10. – 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

11. – 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.

12. 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

13. A P P R O C C I O C L A S S I C O
M E T O D O WA T E R FA L L
1) Analisi dei requisiti
2) Progettazione
3) Sviluppo
4) Collaudo
5) Manutenzione

14. I L P R O C E S S O D I S V I L U P P O S O F T WA R E
D E I N O S T R I S O G N I
O 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

15. L A R E A LTÀ D E L L O
S V I L U P P O S O F T WA 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
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

16. 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

17. S V I L U P PA R E
T 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 G
S 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

18. T E S T I N G E F E E D B A C K
S 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 T
C O N T I N U O U S
I N T E G R AT I O N

19. 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

20. 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

21. 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

22. 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.

23. – 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”.

24. 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 WA R E ?
• Sviluppo iterativo
• Gestire i requisiti
• Architettura basata su
componenti
• Modellare visivamente il
software
• Verifica della qualità
• Controllo sui cambiamenti

25. 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

26. 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.

27. 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

28. 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 WA 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

29. 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.

30. 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.

31. Q U A L È I L V O S T R O A P P R O C C I O ?

32. Segui @iquii