Un Approccio Sistematico Ed Organizzato Allo Sviluppo Del Software
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,367
On Slideshare
2,359
From Embeds
8
Number of Embeds
2

Actions

Shares
Downloads
57
Comments
0
Likes
1

Embeds 8

http://www.slideshare.net 7
http://webcache.googleusercontent.com 1

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. Trento, Aprile 2008 Un approccio sistematico ed organizzato allo sviluppo del software Alessandro M. Martellone Analista programmatore a.martellone@fmail.com 1
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Modello a cascata 14
  • 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. V&V con retroazione Verifica: stiamo costruendo il prodotto nel modo giusto? Validazione: stiamo costruendo il giusto prodotto? 16
  • 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. 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. 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. 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. 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. Fase di costruzione: gli obiettivi • Il sistema è : – Sviluppato – Integrato – Testato • La milestone di questa fase si chiama quot;Initial Operational Capabilityquot;. 22
  • 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. Lo sforzo nelle fasi 24
  • 25. Gli artefatti in UP 25
  • 26. Gli artefatti durante il processo • Ogni artefatto si riferisce in particolare ad una fase dello Unified Process. 26
  • 27. Processo guidato dagli artefatti 27
  • 28. Processo guidato dai documenti 28
  • 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. 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. 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. 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. 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. 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. 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. Il modello di qualità ISO/IEC - 9126 36
  • 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. 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. 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. 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. 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. 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. 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. 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. 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