Software Development nel mondo industriale: specificità e problematiche Ing.Mauro Inzerillo Maggio 2010
Chi sono, chi siamo <ul><li>Mi chiamo Mauro Inzerillo, sono responsabile della business unit  RED Team </li></ul><ul><li>S...
sommario <ul><li>Il software industriale </li></ul><ul><li>Un modello di business dello sviluppo software </li></ul><ul><l...
Cos’è il  software industriale <ul><li>Vita attesa del software: anni </li></ul><ul><li>Variabilità dei requisiti (sistema...
Il problema della dimensione <ul><li>Le dimensioni di un sistema impattano ogni aspetto del sistema che costruiamo </li></...
Il problema della dimensione <ul><li>La dimensione altera il problema </li></ul><ul><ul><li>Competenze </li></ul></ul><ul>...
Il problema del timeframe <ul><li>Cosa cambia con l'allungamento della durata attesa del software ? </li></ul><ul><ul><li>...
Il problema del timeframe <ul><li>Changing requirements: le esigenze cambiano nel tempo </li></ul><ul><ul><li>Il cambiamen...
Il problema del timeframe <ul><li>Changing requirements: le esigenze cambiano nel tempo </li></ul><ul><ul><li>I cambiament...
Il problema del timeframe <ul><li>i cambiamenti introdotti nel tempo introducono un nuovo asse </li></ul><ul><ul><li>il so...
La dimensione economica per il cliente <ul><li>un cliente è disposto a pagare una cifra massima per un sw (valore aggiunto...
La dimensione economica per il fornitore <ul><li>un fornitore deve conseguire un utile (differenza ricavi-costi) dallo svi...
La dimensione economica del progetto <ul><li>Qualunque attività è un  progetto , ossia un’attività che ha </li></ul><ul><u...
Tipico modello di business di un’azienda IT <ul><li>La produzione di software è un’attività  labour intensive , i costi so...
Dove stanno i costi ? <ul><li>Il software industriale è un sistema complesso </li></ul><ul><li>I costi di “primo sviluppo”...
Tipi di manutenzione <ul><li>Evolutiva (pianificata) </li></ul><ul><li>Correttiva (NON pianificata) </li></ul><ul><ul><li>...
Dove stanno i costi ? <ul><li>capire l’esistente </li></ul><ul><li>progettare la modifica </li></ul><ul><li>realizzare la ...
Test live <ul><li>Modifichiamo un software esistente </li></ul><ul><ul><li>Leggo un file contenente dati di attività di pe...
risultati <ul><li>la parte critica è CAPIRE </li></ul><ul><li>la modifica  A  era molto più semplice nel caso flat  </li><...
Le differenze <ul><li>Codice “flat” </li></ul><ul><ul><li>La modifica A era facilmente applicabile perchè i concetti impli...
Le differenze <ul><li>Codice object oriented </li></ul><ul><ul><li>La modifica A era facilmente applicabile ma impattava m...
Lessons learned <ul><li>I requisiti di un sistema sono la chiave per poter sviluppare un sistema in maniera economicamente...
Lessons learned <ul><li>I costi di un sistema sono primariamente determinati dalla  comprensibilità  del sistema </li></ul...
Lessons learned <ul><li>la semplicità paga sempre (a parità di requisiti) </li></ul><ul><li>Non sovradimensionare </li></u...
Rivisitazione dei concetti OO <ul><li>Ereditarietà </li></ul><ul><ul><li>Diminuisce il numero di righe di codice tramite f...
Lesson learned <ul><li>La  leggibilità (in senso lato)  è la caratteristica che regna sovrana su tutte le altre, che, se a...
ESEMPIO… <ul><li>Il progetto esegue più o meno le stesse cose di quello di prima </li></ul><ul><li>Quali differenze ci son...
Sviluppare è… <ul><li>Una forma di  comunicazione </li></ul><ul><ul><li>Verso la macchina </li></ul></ul><ul><ul><li>Verso...
La regola del “7 +- 2” <ul><li>E’ stato ampiamente dimostrato da studi psicometrici che il cervello umano è in grado di el...
Progettiamo sistemi perchè… <ul><li>Dal punto di vista del computer, non c’è alcuna esigenza di strutturare un sistema. Se...
GRAZIE PER L’ATTENZIONE <ul><li>La presentazione è disponibile all’indirizzo </li></ul><ul><li>http://www.slideshare.net/g...
Upcoming SlideShare
Loading in...5
×

C:\documents and settings\inzerillo\desktop\units\software development nel mondo industriale

182

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
182
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

C:\documents and settings\inzerillo\desktop\units\software development nel mondo industriale

  1. 1. Software Development nel mondo industriale: specificità e problematiche Ing.Mauro Inzerillo Maggio 2010
  2. 2. Chi sono, chi siamo <ul><li>Mi chiamo Mauro Inzerillo, sono responsabile della business unit RED Team </li></ul><ul><li>Sono stato sviluppatore, architetto, analista, project manager </li></ul><ul><li>Ci occupiamo di progettare soluzioni IT in aziende di diversa dimensione e settore </li></ul>
  3. 3. sommario <ul><li>Il software industriale </li></ul><ul><li>Un modello di business dello sviluppo software </li></ul><ul><li>Dove stanno i costi di sviluppo ? </li></ul><ul><li>Test live </li></ul><ul><li>Motivi ed obiettivi della progettazione di sistemi </li></ul>
  4. 4. Cos’è il software industriale <ul><li>Vita attesa del software: anni </li></ul><ul><li>Variabilità dei requisiti (sistema che evolve) </li></ul><ul><li>Applicazione mission critical (dal buon funzionamento del sistema dipendono una o più funzioni aziendali fondamentali) </li></ul><ul><li>Dimensione del sistema (programming in the large) </li></ul>
  5. 5. Il problema della dimensione <ul><li>Le dimensioni di un sistema impattano ogni aspetto del sistema che costruiamo </li></ul><ul><li>Esempi di problemi semplici </li></ul><ul><ul><li>Costruire un aquilone (10 metri apertura alare) </li></ul></ul><ul><ul><li>Fare la cena (per 1.000 persone) </li></ul></ul><ul><ul><li>Andare a Milano (1.000 persone) </li></ul></ul>
  6. 6. Il problema della dimensione <ul><li>La dimensione altera il problema </li></ul><ul><ul><li>Competenze </li></ul></ul><ul><ul><li>Materiali (piattaforme: frameworks, third-party libraries, server systems) </li></ul></ul><ul><ul><li>Strumenti (tools: versioning, change management, ide, </li></ul></ul><ul><ul><li>Tecniche (rup, metodi agile, project management) </li></ul></ul><ul><ul><li>Overhead (planning risorse, ) </li></ul></ul>
  7. 7. Il problema del timeframe <ul><li>Cosa cambia con l'allungamento della durata attesa del software ? </li></ul><ul><ul><li>Un insieme di persone diverse sarà chiamata, in momenti diversi , a manutenere ed evolvere il sistema </li></ul></ul><ul><ul><li>Una persona diversa è anche la stessa persona passato un sufficiente intervallo di tempo </li></ul></ul>
  8. 8. Il problema del timeframe <ul><li>Changing requirements: le esigenze cambiano nel tempo </li></ul><ul><ul><li>Il cambiamento è poco prevedibile nel cosa e nel quando </li></ul></ul><ul><ul><li>I cambiamenti devono implicare il dispendio di tempo più basso possibile </li></ul></ul><ul><ul><li>Il software deve opporre poca “inerzia” ai cambiamenti introdotti </li></ul></ul>
  9. 9. Il problema del timeframe <ul><li>Changing requirements: le esigenze cambiano nel tempo </li></ul><ul><ul><li>I cambiamenti devono implicare il dispendio di tempo più basso possibile </li></ul></ul><ul><ul><li>Il software deve opporre poca “inerzia” ai cambiamenti introdotti </li></ul></ul>
  10. 10. Il problema del timeframe <ul><li>i cambiamenti introdotti nel tempo introducono un nuovo asse </li></ul><ul><ul><li>il software è stateful: quanto vedete nei sorgenti accumula tutta la storia delle revisioni occorse nel tempo (anni) </li></ul></ul><ul><ul><ul><li>in momenti diversi (cambiano librerie, frameworks,persone) </li></ul></ul></ul><ul><ul><ul><li>da persone diverse </li></ul></ul></ul><ul><ul><ul><li>con interlocutori diversi </li></ul></ul></ul><ul><ul><li>il software dev’essere progettato per un cambiamento pianificato </li></ul></ul><ul><ul><ul><li>occorre individuare le direzioni del cambiamento </li></ul></ul></ul><ul><ul><ul><li>occorre modulare la complessità della soluzione con la probabilità prevista del cambiamento </li></ul></ul></ul>
  11. 11. La dimensione economica per il cliente <ul><li>un cliente è disposto a pagare una cifra massima per un sw (valore aggiunto) </li></ul><ul><li>il valore aggiunto è completamente scorrelato dalla complessità tecnica o dalla struttura interna del software </li></ul><ul><li>oltre alla dimensione costo assume un valore fondamentale l’aspetto del tempo di consegna ( time to market, elapsed ) </li></ul>
  12. 12. La dimensione economica per il fornitore <ul><li>un fornitore deve conseguire un utile (differenza ricavi-costi) dallo sviluppo </li></ul><ul><li>in un progetto il prezzo è fissato, il costo è dato dal prodotto costoPersona * gg. </li></ul><ul><li>Il tempo di consegna rappresenta un vincolo importante spesso determinante (generatore di vincoli ulteriori) </li></ul>
  13. 13. La dimensione economica del progetto <ul><li>Qualunque attività è un progetto , ossia un’attività che ha </li></ul><ul><ul><li>Un obiettivo preciso </li></ul></ul><ul><ul><li>Un tempo assegnato (disponibile: offerte, gare, penali,…) </li></ul></ul><ul><ul><li>Un budget assegnato (oltre, comincio ad erodere il guadagno fino a perderci) </li></ul></ul>
  14. 14. Tipico modello di business di un’azienda IT <ul><li>La produzione di software è un’attività labour intensive , i costi sono legati essenzialmente al costo della manodopera </li></ul><ul><li>L’industria sviluppa metodi, strumenti, metodologie tali da minimizzare il costo a parità di risultato </li></ul>
  15. 15. Dove stanno i costi ? <ul><li>Il software industriale è un sistema complesso </li></ul><ul><li>I costi di “primo sviluppo” assorbono il 30% del totale </li></ul><ul><li>Il restante 70% è “manutenzione” </li></ul>
  16. 16. Tipi di manutenzione <ul><li>Evolutiva (pianificata) </li></ul><ul><li>Correttiva (NON pianificata) </li></ul><ul><ul><li>E' quella maggiormente critica </li></ul></ul><ul><li>Scenario </li></ul><ul><ul><li>Sistema in roll-out </li></ul></ul><ul><ul><li>Bug bloccante </li></ul></ul><ul><ul><li>Correzione “a qualunque costo” </li></ul></ul><ul><ul><li>“ cristallizzazione” </li></ul></ul>
  17. 17. Dove stanno i costi ? <ul><li>capire l’esistente </li></ul><ul><li>progettare la modifica </li></ul><ul><li>realizzare la modifica </li></ul><ul><li>Qual è la parte preponderante ? </li></ul>
  18. 18. Test live <ul><li>Modifichiamo un software esistente </li></ul><ul><ul><li>Leggo un file contenente dati di attività di persone su diversi progetti </li></ul></ul><ul><ul><li>In output vengono mostrati i dati delle ore lavorate per ogni commessa </li></ul></ul><ul><li>Modifiche richieste </li></ul><ul><ul><li>Aggiungere un campo “business unit” al file. Scrivere nell'output le ore lavorate per business unit </li></ul></ul><ul><ul><li>Leggere i dati da array e non da file </li></ul></ul>
  19. 19. risultati <ul><li>la parte critica è CAPIRE </li></ul><ul><li>la modifica A era molto più semplice nel caso flat </li></ul><ul><li>la modifica B era più semplice nel caso o.o. </li></ul><ul><li>PERCHE’ ? </li></ul>
  20. 20. Le differenze <ul><li>Codice “flat” </li></ul><ul><ul><li>La modifica A era facilmente applicabile perchè i concetti implicati erano pochi e vicini </li></ul></ul><ul><ul><li>La modifica B risultava meno semplice, dovendo praticamente riscrivere tutto il codice (concetti non isolati) </li></ul></ul>
  21. 21. Le differenze <ul><li>Codice object oriented </li></ul><ul><ul><li>La modifica A era facilmente applicabile ma impattava molte più righe di codice e componenti (concetti presenti NON mappavano le future esigenze) </li></ul></ul><ul><ul><li>La modifica B era facilmente applicabile, il concetto di alimentazione dati è incapsulato, disaccoppiando il resto del codice da tale aspetto </li></ul></ul>
  22. 22. Lessons learned <ul><li>I requisiti di un sistema sono la chiave per poter sviluppare un sistema in maniera economicamente sostenibile (constraint di tempo, tecnologia, costo) </li></ul><ul><li>Un “buon software” modula la sua complessità in ragione del mix di requisiti e risorse disponibili </li></ul>
  23. 23. Lessons learned <ul><li>I costi di un sistema sono primariamente determinati dalla comprensibilità del sistema </li></ul><ul><li>La comprensione di un sistema è influenzata da </li></ul><ul><ul><li>Leggibilità </li></ul></ul><ul><ul><li>Dimensione </li></ul></ul><ul><ul><ul><li>Numero componenti </li></ul></ul></ul><ul><ul><ul><li>Legami tra componenti </li></ul></ul></ul>
  24. 24. Lessons learned <ul><li>la semplicità paga sempre (a parità di requisiti) </li></ul><ul><li>Non sovradimensionare </li></ul><ul><li>la comprensibilità è il fattore chiave </li></ul><ul><li>la dimensione e la leggibilità sono le chiavi della comprensibilità </li></ul><ul><li>NON SOVRADIMENSIONARE </li></ul><ul><li>NON SOVRADIMENSIONARE </li></ul><ul><li>NON SOVRADIMENSIONARE </li></ul>
  25. 25. Rivisitazione dei concetti OO <ul><li>Ereditarietà </li></ul><ul><ul><li>Diminuisce il numero di righe di codice tramite fattorizzazione di classi base </li></ul></ul><ul><li>Polimorfismo </li></ul><ul><ul><li>Diminuisce il numero di righe di codice tramite definizione di interfacce (socket cpu-chip) </li></ul></ul><ul><li>Incapsulamento </li></ul><ul><ul><li>mi permette di capire meglio abbassando il numero di componenti (percepite) </li></ul></ul>
  26. 26. Lesson learned <ul><li>La leggibilità (in senso lato) è la caratteristica che regna sovrana su tutte le altre, che, se assente, riesce a vanificare ogni sforzo di comprensione e successiva modifica di quanto presente </li></ul>
  27. 27. ESEMPIO… <ul><li>Il progetto esegue più o meno le stesse cose di quello di prima </li></ul><ul><li>Quali differenze ci sono ? </li></ul><ul><ul><li>GLI IDENTIFICATORI </li></ul></ul><ul><ul><ul><li>Sono orientati al problema nel primo caso, alla soluzione nel secondo caso </li></ul></ul></ul><ul><ul><ul><li>Sono orientati all’ essere umano nel primo caso, alla macchina (che NON ne ha bisogno) nel secondo caso </li></ul></ul></ul>
  28. 28. Sviluppare è… <ul><li>Una forma di comunicazione </li></ul><ul><ul><li>Verso la macchina </li></ul></ul><ul><ul><li>Verso altri esseri umani </li></ul></ul><ul><li>La seconda è enormemente più importante della prima ! </li></ul><ul><li>Rivolgete il vostro sguardo di sviluppatori verso gli esseri umani </li></ul>
  29. 29. La regola del “7 +- 2” <ul><li>E’ stato ampiamente dimostrato da studi psicometrici che il cervello umano è in grado di elaborare ragionamenti con un numero molto limitato di “elementi” contemporanei </li></ul><ul><li>Tale numero è 7 (+ o – 2) </li></ul><ul><li>Tale numero è molto limitato e vincola grandemente la nostra capacità di comprensione di un sistema, specia al crescere della sua dimensione </li></ul>
  30. 30. Progettiamo sistemi perchè… <ul><li>Dal punto di vista del computer, non c’è alcuna esigenza di strutturare un sistema. Se a progettare fosse una “mente digitale”, non avrebbe alcuna esigenza di strutturazione </li></ul><ul><li>Sono le nostre limitazioni cognitive a “costringerci” a progettare sistemi per farli funzionare nel tempo, a costi accettabili </li></ul>
  31. 31. GRAZIE PER L’ATTENZIONE <ul><li>La presentazione è disponibile all’indirizzo </li></ul><ul><li>http://www.slideshare.net/guesta554cd/software-development-nel-mondo-industriale </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×