Un approccio sistematico ed organizzato allo sviluppo del

software

Trento, Aprile 2008

1

Alessandro M. MartelloneAnalista programmatorea.martellone@fmail.com

software

Di cosa parleremo?

• Della differenza tra un programma e un prodotto software.

• Del processo di sviluppo del software e delle metodologie di sviluppo.

2

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”.

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.

3

• Non è quasi mai testato.• Non vi è un manuale utente• Non c’è un progetto.

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.

4

presenti diversi competitor.• Le applicazioni che si vogliono sviluppare

presentano diverse criticità.• Vi sono un budget e delle scadenze da

rispettare.

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:

5

sono prodotti durante il suo sviluppo:– Codice– Specifiche di progetto– Documentazione– Test– Procedure di organizzazione e gestione– Manuale utente– …

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

6

• E’ quindi necessario utilizzare tecniche e strumenti appropriati al tipo di problema, ai vincoli presenti e al budget a disposizione.

Necessità di un approccio ingegneristico

• Per questo è necessario utilizzare un approccio sistematico ed organizzato nel processo di sviluppo, così da ottenere:– Il giusto prodotto

7

– Il giusto prodotto– Al giusto costo– Nel tempo giusto– E con la giusta qualità

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

8

risorse umane e tool, con il fine di raggiungere uno specifico e comune obiettivo.

L’importanza del processo

• Un processo non gestito professionalmente è strettamente legato allo sviluppatore.

• Problemi:

9

• Problemi:– E’ difficile fare la manutenzione al software.

Manca una pianificazione del lavoro, non sono state seguite delle convenzioni per lo sviluppo,..

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.

10

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.

Gli obiettivi che il nostro processo deve raggiungere

• Efficacia– È diversa da efficienza. Ci permette di

produrre: “la cosa giusta”.

• Manutenibilità

11

• Manutenibilità– Quanto costa localizzare e risolvere un

problema.

• Prevedibilità– Di quali e quante risorse abbiamo bisogno?

Quanto durerà lo sviluppo?

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.

12

– 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.

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

13

• 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)

Modello a cascata

14

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.

15

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.

V&V con retroazione

16

Validazione: stiamo costruendo il giusto prodotto?

Verifica: stiamo costruendo il prodotto nel modo giusto?

Modello a spirale di Boehm

• E’ un modello iterativo.• Fissa gli obiettivi .• Si opera in modo incrementale.• Domanda fondamentale: ”Qual è la

17

• Domanda fondamentale: ”Qual è la componente a più alto rischio?”– Attacca quella per prima!

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;

18

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.

Unified process• E’ un altro modello iterativo.• E’ composto da 4 fasi:

– Fase iniziale (Inception Phase)– Fase di elaborazione (Elaboration Phase)– Fase di costruzione (Costruction Phase)

Analisi e design

Implementazione, test e messa in

19

– Fase di transizione (Transition Phase)test e messa in esercizio

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.

20

• Stimare i costi.• Sviluppare il piano di progetto.• Definire e stimare i rischi.

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

21

• 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.

Fase di costruzione: gli obiettivi

• Il sistema è :– Sviluppato– Integrato– Testato

22

– Testato

• La milestone di questa fase si chiama "Initial Operational Capability".

Fase di completamento: gli obiettivi

• Superamento del test di accettazione del cliente.

• Il progetto è concluso.• Modifiche ed evoluzioni successive

23

• Modifiche ed evoluzioni successive innescano un nuovo progetto di manutenzione evolutiva.

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.

26

Processo guidato dagli artefatti

27

Processo guidato dai documenti

28

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.

29

– 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.

Problemi con XP

• La scarsa documentazione, potrebbe nel medio-lungo periodo avere un impatto negativo sulla manutenzione.

• La mancanza di un processo ben definito

30

• 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.

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à.

31

test di unità.– L’obiettivo è scrivere codice di qualità.– Identificare sin dall’inizio le failure

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à

32

– Funzionalità– Usabilità– Affidabilità– Performance– Sicurezza– Scalabilità– Ed altri fattori

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.

33

tutto il processo di sviluppo.– Più innovazione– Più reattività ai cambiamenti– Minor costo di sviluppo

Qualità per il processo e per il prodotto

• Qualità del processo: quality management– Pianificazione– Controllo e verifica– Metriche e misurazione

34

– 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.

ISO/IEC-9126

• Standard di valutazione della qualità dei prodotti software.

• L’approccio di qualità:– La qualità del processo migliora la qualità del

35

– La qualità del processo migliora la qualità del prodotto.

– La qualità del prodotto migliora la qualità in uso.

Il modello di qualità ISO/IEC - 9126

36

Come si misura il software

• Misurazione = processo• Misura = risultato della misurazione• Attraverso misure:

– Dirette– Indirette (utilizzate per predire)

37

– Indirette (utilizzate per predire)• Iso 9126 stabilisce inoltre metriche che

misurano:– Attributi esterni (attributi osservabili durante l’esercizio

del sistema).• Funzionalità • Usabilità• Efficienza

Come si misura il software

• Attributi interni (osservabili senza la messa in esercizio del sistema):– Modularità– Complessità

38

– Complessità– Testabilità– Complessità– L’osservazione e lo studio di questi attributi ci

può far predire ad esempio lo sforzo necessario alla manutenzione del sistema.

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

39

– Struttura organizzativa– Ruoli– Comunicazione

• Processo di sviluppo dei documenti– Caratteristiche di qualità considerati

• Revisione dei documenti

Esempio di un possibile piano di qualità

• Metriche di qualità– Per il processo.– Per la documentazione.– Per il codice.

40

– Per il codice.

• Software quality assurance– Linee guida per la stesura del codice.– Review del codice.

• Risk management

Il test di Joel

• Joel Spolsky è il fondatore della Fog Creek Software, una software house statunitense (NY).

• Ha molti anni di esperienza nel campo

41

• Ha molti anni di esperienza nel campo dello sviluppo (Microsoft).

• E’ autore di alcuni libri del settore.• Gestisce un famoso blog :

www.joelonsoftware.com.

Hi,I’m Joel!

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

42

– 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.

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?

43

• 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, …

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!”.

44

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.

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

45

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