Software development nel mondo industriale
Upcoming SlideShare
Loading in...5
×
 

Software development nel mondo industriale

on

  • 560 views

 

Statistics

Views

Total Views
560
Views on SlideShare
557
Embed Views
3

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 3

http://www.slideshare.net 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software development nel mondo industriale Software development nel mondo industriale Presentation Transcript

  • Software Development nel mondo industriale: specificità e problematiche Ing.Mauro Inzerillo Maggio 2010
  • Chi sono, chi siamo
    • Mi chiamo Mauro Inzerillo, sono responsabile della business unit RED Team
    • Ci occupiamo di progettare e sviluppare soluzioni IT per grandi aziende
    • Parleremo di sviluppo industriale
  • sommario
    • Il software industriale
    • Modello di business dello sviluppo software
    • Dove stanno i costi di sviluppo ?
    • Test live
    • Motivi ed obiettivi della progettazione di sistemi
  • 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)
  • 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)
  • 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, )
  • 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
  • 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
  • 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
  • La dimensione economica
    • 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
    • un fornitore deve conseguire un utile (differenza ricavi-costi) dallo sviluppo
    • in un progetto il prezzo è fissato, il costo è dato dal prodotto costoPersona * gg.
  • 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)
  • 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
  • Dove stanno i costi ?
    • Il software industriale è un sistema complesso
    • I costi di “primo sviluppo” assorbono il 30% del totale
    • Il restante 70% è “manutenzione”
  • Dove stanno i costi ?
    • in cosa consiste la manutenzione ?
      • capire l’esistente
      • progettare la modifica
      • realizzare la modifica
    • Qual è la parte preponderante ?
  • 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
  • risultati
    • la parte preponderante è CAPIRE
    • la modifica A era molto più semplice nel caso flat
      • (% codice modificato, tempo assoluto)
    • la modifica B era più semplice nel caso o.o.
      • (% codice modificato, tempo assoluto)
    • PERCHE’ ?
  • 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)
  • 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
  • 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
  • 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
  • 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
  • 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
  • ESEMPIO…
  • 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
  • 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
  • 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
  • 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 necessarie nei chiamanti tramite
    • Incapsulamento
      • mi permette di capire meglio abbassando il numero di componenti (percepite)