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