• Like
C:\documents and settings\inzerillo\desktop\units\software development nel mondo industriale
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

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

  • 310 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
310
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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