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