Trento, Aprile 2008




           Un approccio sistematico ed
           organizzato allo sviluppo del
                  ...
Di cosa parleremo?
• Della differenza tra un programma e un
  prodotto software.
• Del processo di sviluppo del software e...
Cos’è un programma
• E’ un insieme di linee di codice, di cui
  l’utente è anche lo sviluppatore.
• E’ scarsamente (o per ...
Prodotto software
• E’ un prodotto utilizzato da persone
  diverse da chi lo ha implementato.
• Spesso si opera in un merc...
Il prodotto software secondo l’IEEE
• “Un prodotto software è un’insieme di procedure, tool,
  dati e documentazione.”

• ...
Necessità di un approccio
           ingegneristico
• L’ingegneria del software è una disciplina
  che cerca di fornire le...
Necessità di un approccio
           ingegneristico
• Per questo è necessario utilizzare un
  approccio sistematico ed org...
Il processo software
• Il processo software è costituito da un
  insieme organizzato di attività tra loro
  correlate, sec...
L’importanza del processo
• Un processo non gestito
  professionalmente è strettamente legato
  allo sviluppatore.
• Probl...
L’importanza del processo
• E’ difficile stimare la qualità del prodotto
  finale.
• Problemi:
  – Verificare che il nostr...
Gli obiettivi che il nostro processo
          deve raggiungere
• Efficacia
  – È diversa da efficienza. Ci permette di
  ...
Gli obiettivi che il nostro processo
          deve raggiungere
• Ripetibilità
   – Il processo, una volta definito, dovre...
I principali modelli di sviluppo
• Il processo di sviluppo del software è suddiviso in varie
  fasi.
   – Il ciclo di vita...
Modello a cascata




                    14
Il modello a cascata
• L’output di una fase è l’input della fase successiva.
• Non sono previsti meccanismi di retroazione...
V&V con retroazione




Verifica: stiamo costruendo il prodotto nel modo giusto?

Validazione: stiamo costruendo il giusto...
Modello a spirale di Boehm
•   E’ un modello iterativo.
•   Fissa gli obiettivi .
•   Si opera in modo incrementale.
•   D...
Attività del modello di Boehm
1. Determina gli obiettivi e i vincoli.
2. Valuta le alternative.
3. Identifica i rischi.
4....
Unified process
• E’ un altro modello iterativo.
• E’ composto da 4 fasi:
   –   Fase iniziale (Inception Phase)
         ...
Fase iniziale: gli obiettivi
•   Stabilire l’obiettivo del progetto
•   Definire i criteri di accettazione.
•   Identifica...
Fase di elaborazione : gli obiettivi
• Individuare i requisiti non funzionali .
• Dettagliare il piano di progetto nelle
 ...
Fase di costruzione: gli obiettivi
• Il sistema è :
  – Sviluppato
  – Integrato
  – Testato
• La milestone di questa fase...
Fase di completamento: gli obiettivi
• Superamento del test di accettazione del
  cliente.
• Il progetto è concluso.
• Mod...
Lo sforzo nelle fasi




                       24
Gli artefatti in UP




                      25
Gli artefatti durante il processo
• Ogni artefatto si riferisce in particolare ad una
  fase dello Unified Process.




  ...
Processo guidato dagli artefatti




                               27
Processo guidato dai documenti




                             28
Processi agili: eXtreme
               Programming
• Le pratiche di XP:
   – Customer centric (il cliente è parte integrat...
Problemi con XP
• La scarsa documentazione, potrebbe nel
  medio-lungo periodo avere un impatto
  negativo sulla manutenzi...
Processi agili: Test Driven
           Development
• Recepisce le pratiche dell’XP.
• Pone il test al centro dello svilupp...
Un prodotto software di qualità
• In generale un prodotto è di qualità se è
  risponde alle aspettative.
• Nel software qu...
L’impatto della qualità nel processo
             produttivo
• La qualità non porta dei benefit solo
  all’utente.
• La qu...
Qualità per il processo e per il
              prodotto
• Qualità del processo: quality management
  – Pianificazione
  – ...
ISO/IEC-9126
• Standard di valutazione della qualità dei
  prodotti software.
• L’approccio di qualità:
  – La qualità del...
Il modello di qualità ISO/IEC - 9126




                                   36
Come si misura il software
• Misurazione = processo
• Misura = risultato della misurazione
• Attraverso misure:
  – Dirett...
Come si misura il software
• Attributi interni (osservabili senza la messa
  in esercizio del sistema):
  – Modularità
  –...
Esempio di un possibile piano di
              qualità
• Modello di qualità proposto
  – Caratteristiche di qualità consid...
Esempio di un possibile piano di
              qualità
• Metriche di qualità
  – Per il processo.
  – Per la documentazion...
Il test di Joel
• Joel Spolsky è il fondatore della Fog Creek
  Software, una software house statunitense
  (NY).
• Ha mol...
Il test di Joel
• Avete un sistema di versionamento del codice?
  – CVS (open source)
• Quanti passi ci vogliono per una b...
Il test di Joel
• Avete un database dei bug?
  – Lista dei passi per riprodurre il bug, comportamento
    atteso, comporta...
Il test di Joel
• Avete delle specifiche?
  – Nella fase di progettazione se si scopre un errore
    basta cambiare qualch...
Riferimenti
• Ian Sommerville, I. Sommerville, Software Engineering (6th edition,
  2001),Addison Wesley.
• Bernd Bruegge ...
Upcoming SlideShare
Loading in...5
×

Un Approccio Sistematico Ed Organizzato Allo Sviluppo Del Software

1,290

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

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

No notes for slide

Un Approccio Sistematico Ed Organizzato Allo Sviluppo Del Software

  1. 1. Trento, Aprile 2008 Un approccio sistematico ed organizzato allo sviluppo del software Alessandro M. Martellone Analista programmatore a.martellone@fmail.com 1
  2. 2. Di cosa parleremo? • Della differenza tra un programma e un prodotto software. • Del processo di sviluppo del software e delle metodologie di sviluppo. • Di come valutare e misurare la qualità del prodotto software e del processo produttivo. • Misuriamo la qualità della nostra squadra di sviluppo con : “Il test di Joel”. 2
  3. 3. Cos’è un programma • E’ un insieme di linee di codice, di cui l’utente è anche lo sviluppatore. • E’ scarsamente (o per nulla) documentato. • Non è quasi mai testato. • Non vi è un manuale utente • Non c’è un progetto. 3
  4. 4. Prodotto software • E’ un prodotto utilizzato da persone diverse da chi lo ha implementato. • Spesso si opera in un mercato dove sono presenti diversi competitor. • Le applicazioni che si vogliono sviluppare presentano diverse criticità. • Vi sono un budget e delle scadenze da rispettare. 4
  5. 5. Il prodotto software secondo l’IEEE • “Un prodotto software è un’insieme di procedure, tool, dati e documentazione.” • Per cui non vi è solo codice! • Ci sono tutti gli artefatti che lo accompagnano e che sono prodotti durante il suo sviluppo: – Codice – Specifiche di progetto – Documentazione – Test – Procedure di organizzazione e gestione – Manuale utente – … 5
  6. 6. Necessità di un approccio ingegneristico • L’ingegneria del software è una disciplina che cerca di fornire le regole per il processo di produzione del software. • E’ quindi necessario utilizzare tecniche e strumenti appropriati al tipo di problema, ai vincoli presenti e al budget a disposizione. 6
  7. 7. Necessità di un approccio ingegneristico • Per questo è necessario utilizzare un approccio sistematico ed organizzato nel processo di sviluppo, così da ottenere: – Il giusto prodotto – Al giusto costo – Nel tempo giusto – E con la giusta qualità 7
  8. 8. Il processo software • Il processo software è costituito da un insieme organizzato di attività tra loro correlate, secondo vincoli, specifiche, risorse umane e tool, con il fine di raggiungere uno specifico e comune obiettivo. 8
  9. 9. L’importanza del processo • Un processo non gestito professionalmente è strettamente legato allo sviluppatore. • Problemi: – E’ difficile fare la manutenzione al software. Manca una pianificazione del lavoro, non sono state seguite delle convenzioni per lo sviluppo,.. 9
  10. 10. L’importanza del processo • E’ difficile stimare la qualità del prodotto finale. • Problemi: – Verificare che il nostro software sia in accordo ai criteri di qualità del cliente. • Il team di sviluppo lavora senza coordinamento: • Problemi: – Un overhead nel lavoro di ciascun sviluppatore. – Non si impara dalle esperienze degli altri. 10
  11. 11. Gli obiettivi che il nostro processo deve raggiungere • Efficacia – È diversa da efficienza. Ci permette di produrre: “la cosa giusta”. • Manutenibilità – Quanto costa localizzare e risolvere un problema. • Prevedibilità – Di quali e quante risorse abbiamo bisogno? Quanto durerà lo sviluppo? 11
  12. 12. Gli obiettivi che il nostro processo deve raggiungere • Ripetibilità – Il processo, una volta definito, dovrebbe essere riutilizzabile per altri progetti. • Qualità – Poter verificare l’idoneità del prodotto finale a dei requisiti. • Miglioramento – Dovrebbe essere prevista la possibilità di migliorare ed riadattare il processo in seguito al cambiamento di qualche obiettivo. • Tracciamento – Dar la possibilità al management, agli sviluppatori ed al cliente di seguire lo stato di avanzamento del processo. 12
  13. 13. I principali modelli di sviluppo • Il processo di sviluppo del software è suddiviso in varie fasi. – Il ciclo di vita del software (CVS). • Il CVS è descritto da un modello. • Modelli sequenziali – A cascata (1970) – V&V con retroazione (variante “a cascata” - 1992) • Modelli iterativi – Modello a spirale di Boehm (1988) – Unified process (1999) – Processi agili (eXtreme Programming, Test Driven Development 1999-2003) 13
  14. 14. Modello a cascata 14
  15. 15. Il modello a cascata • L’output di una fase è l’input della fase successiva. • Non sono previsti meccanismi di retroazione. • Questo è il maggior limite del modello a cascata. • Risulta difficile e molto costoso apportare delle modifiche in corso d’opera. • Si interagisce con il committente solo all’inizio e alla fine. • Ha rappresentato un punto di partenza per lo studio dei processi software. • Utilizzato dal dipartimento della difesa U.S dagli anni 80 agli anni 90. 15
  16. 16. V&V con retroazione Verifica: stiamo costruendo il prodotto nel modo giusto? Validazione: stiamo costruendo il giusto prodotto? 16
  17. 17. Modello a spirale di Boehm • E’ un modello iterativo. • Fissa gli obiettivi . • Si opera in modo incrementale. • Domanda fondamentale: ”Qual è la componente a più alto rischio?” – Attacca quella per prima! 17
  18. 18. Attività del modello di Boehm 1. Determina gli obiettivi e i vincoli. 2. Valuta le alternative. 3. Identifica i rischi. 4. Assegna le priorità ai rischi. 5. Sviluppa un prototipo per ogni rischio; comincia da quello più alto. 6. Segui il modello a cascata per ogni prototipo. 7. Se il rischio è stato superato, allora valuta il risultato e pianifica il prossimo step. 8. Se il rischio non è stato superato, termina il progetto. 18
  19. 19. Unified process • E’ un altro modello iterativo. • E’ composto da 4 fasi: – Fase iniziale (Inception Phase) Analisi e design – Fase di elaborazione (Elaboration Phase) Implementazione, – Fase di costruzione (Costruction Phase) test e messa in – Fase di transizione (Transition Phase) esercizio 19
  20. 20. Fase iniziale: gli obiettivi • Stabilire l’obiettivo del progetto • Definire i criteri di accettazione. • Identificare i casi d’uso e gli scenari critici. • Stimare i costi. • Sviluppare il piano di progetto. • Definire e stimare i rischi. 20
  21. 21. Fase di elaborazione : gli obiettivi • Individuare i requisiti non funzionali . • Dettagliare il piano di progetto nelle scadenze e nei costi. • Alla fine della fase l’architettura (organizzazione interna del sistema e tecnologie scelte) è stabile. • Dimostrare, attraverso il test dei prototipi, che i principali rischi sono stati affrontati e risolti. 21
  22. 22. Fase di costruzione: gli obiettivi • Il sistema è : – Sviluppato – Integrato – Testato • La milestone di questa fase si chiama quot;Initial Operational Capabilityquot;. 22
  23. 23. Fase di completamento: gli obiettivi • Superamento del test di accettazione del cliente. • Il progetto è concluso. • Modifiche ed evoluzioni successive innescano un nuovo progetto di manutenzione evolutiva. 23
  24. 24. Lo sforzo nelle fasi 24
  25. 25. Gli artefatti in UP 25
  26. 26. Gli artefatti durante il processo • Ogni artefatto si riferisce in particolare ad una fase dello Unified Process. 26
  27. 27. Processo guidato dagli artefatti 27
  28. 28. Processo guidato dai documenti 28
  29. 29. Processi agili: eXtreme Programming • Le pratiche di XP: – Customer centric (il cliente è parte integrate dello sviluppo). – Pair programming (2 programmatori, 1 monitor, 1 tastiera). – Sviluppare oggi una soluzione semplice, permetterà, eventualmente, di cambiarla domani a un basso costo. – Costanti review. – Integrazioni continue. – Test di unità automatizzati. – Refactoring (ristrutturare il codice senza cambiarne le funzionalità). – Codice funzionante anziché documentazione omnicomprensiva. – 40 hour week. – Coding standards. 29
  30. 30. Problemi con XP • La scarsa documentazione, potrebbe nel medio-lungo periodo avere un impatto negativo sulla manutenzione. • La mancanza di un processo ben definito e di ruoli formali, fa si che il raggiungimento dell’obiettivo dipenda fortemente dalla capacità di collaborazione all’interno del gruppo. 30
  31. 31. Processi agili: Test Driven Development • Recepisce le pratiche dell’XP. • Pone il test al centro dello sviluppo. • Già in fase di progettazione descrivere i test di unità. – L’obiettivo è scrivere codice di qualità. – Identificare sin dall’inizio le failure 31
  32. 32. Un prodotto software di qualità • In generale un prodotto è di qualità se è risponde alle aspettative. • Nel software questo non è sufficiente. • La qualità è la somma di: – Funzionalità – Usabilità – Affidabilità – Performance – Sicurezza – Scalabilità – Ed altri fattori 32
  33. 33. L’impatto della qualità nel processo produttivo • La qualità non porta dei benefit solo all’utente. • La qualità diventa un valore aggiunto a tutto il processo di sviluppo. – Più innovazione – Più reattività ai cambiamenti – Minor costo di sviluppo 33
  34. 34. Qualità per il processo e per il prodotto • Qualità del processo: quality management – Pianificazione – Controllo e verifica – Metriche e misurazione – Qualità del processo: quality management • ISO – 9001 – Set di standard per organizzazioni che si occupano di progettazione, sviluppo e manutenzione di prodotti. 34
  35. 35. ISO/IEC-9126 • Standard di valutazione della qualità dei prodotti software. • L’approccio di qualità: – La qualità del processo migliora la qualità del prodotto. – La qualità del prodotto migliora la qualità in uso. 35
  36. 36. Il modello di qualità ISO/IEC - 9126 36
  37. 37. Come si misura il software • Misurazione = processo • Misura = risultato della misurazione • Attraverso misure: – Dirette – Indirette (utilizzate per predire) • Iso 9126 stabilisce inoltre metriche che misurano: – Attributi esterni (attributi osservabili durante l’esercizio del sistema). • Funzionalità • Usabilità • Efficienza 37
  38. 38. Come si misura il software • Attributi interni (osservabili senza la messa in esercizio del sistema): – Modularità – Complessità – Testabilità – Complessità – L’osservazione e lo studio di questi attributi ci può far predire ad esempio lo sforzo necessario alla manutenzione del sistema. 38
  39. 39. Esempio di un possibile piano di qualità • Modello di qualità proposto – Caratteristiche di qualità considerati • Organizzazione del progetto – Modello del processo di sviluppo – Struttura organizzativa – Ruoli – Comunicazione • Processo di sviluppo dei documenti – Caratteristiche di qualità considerati • Revisione dei documenti 39
  40. 40. Esempio di un possibile piano di qualità • Metriche di qualità – Per il processo. – Per la documentazione. – Per il codice. • Software quality assurance – Linee guida per la stesura del codice. – Review del codice. • Risk management 40
  41. 41. Il test di Joel • Joel Spolsky è il fondatore della Fog Creek Software, una software house statunitense (NY). • Ha molti anni di esperienza nel campo dello sviluppo (Microsoft). • E’ autore di alcuni libri del settore. Hi,I’m Joel! • Gestisce un famoso blog : www.joelonsoftware.com. 41
  42. 42. Il test di Joel • Avete un sistema di versionamento del codice? – CVS (open source) • Quanti passi ci vogliono per una build pronta per la distribuzione? – Le buone squadre hanno un solo script che fa il checkout da zero, ricompila tutto il codice, crea il pacchetto di installazione e tutto il resto di cui si necessita. • Fate compilazioni quotidiane? – Ci si assicura che errori accidentali (es. un nuovo file non aggiunto al CVS) non passino inosservati. 42
  43. 43. Il test di Joel • Avete un database dei bug? – Lista dei passi per riprodurre il bug, comportamento atteso, comportamento ottenuto, a chi è assegnato, se è stato sistemato oppure no. • Sistemate i bug prima di produrre nuovo codice? – In generale, più aspetti a risolvere un bug, più è costoso (in termini di tempo e di denaro) correggerlo. • Avete una tabella di marcia aggiornata? – Pianificazione con ufficio management, comunicazione, sviluppo, … 43
  44. 44. Il test di Joel • Avete delle specifiche? – Nella fase di progettazione se si scopre un errore basta cambiare qualche riga di testo. Dovrebbe essere fatta rispettare la regola :”Niente codice, senza specifiche!”. • Inoltre vi sono altre considerazioni, come: – Far lavorare gli sviluppatori in un luogo tranquillo – L’importanza dei test e dei tester – I test di usabilità (usabilità “da corridoio”). – L’importanza di utilizzare i migliori tool sul mercato. 44
  45. 45. Riferimenti • Ian Sommerville, I. Sommerville, Software Engineering (6th edition, 2001),Addison Wesley. • Bernd Bruegge & Allen H. Dutoit, Object-Oriented Software Engineering: Using UML, Patterns and Java, (2nd edition), Prentice- Hall, 2003. • J.Arlow, I. Neustadt,UML2 and the unified process (2nd edition,2006),Addison Wesley • http://www.acm.org/crossroads/xrds6-4/software.html • http://www.analisi-disegno.com • http://www.extremeprogramming.org • http://www.manifestoagile.org • http://www.joelonsoftware.com/ • Quality characteristics and metrics for reusable software – U.S. Department of Commerce 45
  1. A particular slide catching your eye?

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

×