Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software engineering practices - Open IQUII Ottobre 2015

359 views

Published on

Le aziende, oggi, con l’ingrandirsi delle codebase dei loro software, vanno a scontrarsi in problematiche molto complesse, che richiedono un’enorme mole di denaro per fronteggiare il gap tecnologico che va costituendosi man mano che i loro applicativi software crescono di complessità.

Il più delle volte ciò è da attribuire ad una bassa qualità del codice, a performance di esecuzione non accettabili, a poca manutenibilità ed estendibilità, che non consente all’azienda di far fronte ai rapidi cambiamenti richiesti dal mercato.

Il segreto quindi è quello di formare i propri ingegneri con buone software engineering practices per utilizzare tecniche che consentano di creare software di alta qualità, manutenibili nel tempo, e che sul lungo periodo facciano diminuire i costi di gestione.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Software engineering practices - Open IQUII Ottobre 2015

  1. 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. 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. 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. 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. 5. 2 ° A N N O
  6. 6. 3 ° A N N O
  7. 7. 5 ° A N N O
  8. 8. 1 0 ° A N N O L E S S I S M O R E
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31. Q U A L È I L V O S T R O A P P R O C C I O ?
  32. 32. Segui @iquii

×