Università degli Studi dell’Insubria

FACOLTA’ DI SCIENZE MATEMATICHE FISICHE E NATURALI

Corso di Laurea in Informatica

Studio e applicazione di metodi agili nello sviluppo di prodotti

Software Open Source

Tesi di Laurea di: Relatore: Prof. Luigi Lavazza

MARCO BINDA Prof. Sandro Morasca Matricola: 607575

Correlatore:

Davide Taibi

Anno Accademico 2008-2009

ii

Riassunto

Nello studio dell’ingegneria del software si possono dividere i processi di sviluppo in due categorie: processi di sviluppo classici e processi di sviluppo agili. Quando si prende in considerazione un processo di sviluppo classico ci si riferisce a modelli come quello a cascata o a spirale, in cui la modalità di lavoro è fortemente orientata all’esecuzione di passi sequenziali dove si pianifica, si progetta e si sviluppa l’intero sistema software, con a volte la presunzione di implementare oltre alle funzionalità richieste quelle future. Questo modo di operare, ben si orienta allo sviluppo di progetti Closed Source Software (CSS). I processi di sviluppo Agili, come ad esempio Extreme Programming (XP) o SCRUM, si contrappongono a quelli classici. Questi modelli sono composti da una serie di fasi iterative, dove viene presa in considerazione una parte di progetto alla volta, piccola e ben definita. I processi di sviluppo Agili propongono un modo di lavorare fortemente orientato al risultato che ben si adatta allo sviluppo di progetto Open Source Software. In questo lavoro di tesi si è applicato un processo di sviluppo Agile, in particolare una versione modificata di SCRUM, ad uno strumento OSS contenuto all’interno del progetto Qualipso, in dettaglio allo strumento MACXIM. Gli obiettivi che ci siamo proposti all’inizio di questo lavoro sono quelli di valutare se sia possibile inserire il processo di sviluppo SCRUM in un progetto OSS già in fase di sviluppo, se sia possibile far cooperare un team di programmatori geograficamente distribuiti e se SCRUM ha contribuito effettivamente a migliorare la qualità del prodotto e la produttività del processo. SCRUM è stato studiato, modificato e adattato per poter essere applicato allo sviluppo di MACXIM. Sono state raccolte una serie di misure quantitative e qualitative prima e dopo l’introduzione di SCRUM nel processo di sviluppo, che hanno permesso una valutazione oggettiva ed empirica dell’applicazione di SCRUM a progetti OSS.

iii

Sommario 1   INTRODUZIONE ............................................................................................ 1  

1.1   OBIETTIVI DELLA TESI ....................................................................... 3  

1.2   STRUTTURA DELLA TESI .................................................................... 4  

2   I PROCESSI DI SVILUPPO ............................................................................ 5  

2.1   PROCESSI DI SVILUPO CLASSICI ...................................................... 5  

2.1.1   IL PROCESSO DI SVILUPPO A CASCATA ..................................... 5  

2.1.2   IL PROCESSO DI SVILUPPO ITERATIVO: A SPIRALE ................ 7  

2.1.3   IL PROCESSO DI SVILUPPO UNIFIED PROCESS ......................... 8  

3   I PROCESSI DI SVILUPPO AGILI .............................................................. 11  

3.1.1   EXTREME PROGRAMMING ........................................................... 14  

3.1.2   SCRUM ............................................................................................... 16  

3.1.3   FEATURE DRIVEN DEVELOPMENT ............................................ 19  

3.1.4   DYNAMIC SYSTEM DEVELOPMENT METHOD ........................ 21  

4   APPLICAZIONE DI SCRUM A PROGETTI OSS ....................................... 23  

4.1   LIGHT SCRUM ...................................................................................... 28  

5   CASO DI STUDIO ........................................................................................ 33  

5.1   MACXIM ................................................................................................ 33  

5.2   PROCESSO DI SVILUPPO ................................................................... 35  

5.3   APPLICAZIONE DI LIGHT SCRUM A MACXIM ............................. 36  

5.4   RISULTATI ............................................................................................ 38  

CONCLUSIONI E SVILUPPI FUTURI ............................................................... 45  

BIBLIOGRAFIA ................................................................................................... 47  

Appendice A - I PRINCIPI FONDANTI DEL MANIFESTO AGILE ................ 50  

Appendice B - PRATICHE ................................................................................... 52  

1

1 INTRODUZIONE

Nel corso degli anni ’90 si sono concretizzate ed hanno

avuto modo di evolvere una serie di metodologie per lo

sviluppo software denominato “Agile”.

Queste discipline si focalizzano sul conseguimento di

un obiettivo alla volta, breve e ben definito,

realizzando con un processo iterativo l’intero sistema.

Talvolta queste metodologie possono essere impiegate

per sviluppare prodotti software Open Source (OSS)[13].

Normalmente lo sviluppo di prodotti OSS avviene con

criteri molto elastici, in cui gli sviluppatori sono

distribuiti geograficamente, decidono il proprio lavoro

e come distribuirlo alla comunità.

Questa tipologia di sviluppo è in aperto contrasto con

le metodologie Closed Source Software (CSS), dove vi

sono dei paradigmi molto rigidi, come ad esempio quelli

implementati nel modello Waterfall [14], in cui i

programmatori devono seguire schemi di sviluppo

rigorosi e ben impostati.

Questo lavoro di tesi prende in esame due

considerazioni principali:

1. Il processo di sviluppo dei prodotti OSS è molto

simile al processo di sviluppo adottato nelle

metodologie Agili

2. I prodotti CSS sviluppati con processi classici

non hanno avuto modo in questi anni di abbracciare

le metodologie Agili emergenti, mantenendo

paradigmi di sviluppo rigidi.

2

Presa visione di queste due considerazioni, ho

sviluppato il mio lavoro di tesi applicando una

metodologia Agile ad uno strumento OSS nel progetto

Qualipso [18], effettuando delle misurazioni prima e

dopo l’impiego di tale processo di sviluppo, per

valutare se sia possibile ottimizzare la produttività

del team di sviluppo ed aumentare la qualità dei

prodotti OSS, attraverso un ambito più inquadrato

rispetto a quello completamente non strutturato che

caratterizza i progetti OSS.

Dopo aver preso visione delle diverse metodologie

Agili, valutando pregi e difetti di ciascuna, abbiamo

applicato il processo di sviluppo SCRUM [1] per lo

sviluppo di MACXIM (Model And Code Xml-based Integrated

Meter), uno strumento OSS che estrae misure

quantitative e oggettive da codice sorgente Java.

Terminata questa esperienza abbiamo confrontato i dati

raccolti prima e dopo l’introduzione di SCRUM e ne

abbiamo ricavato delle osservazioni su come applicare

SCRUM ai prodotti OSS.

Dai risultati ottenuti è emerso che SCRUM non ha

alterato significativamente la produttività del nostro

team di sviluppo e la qualità del nostro prodotto.

Tuttavia è stato possibile controllare meglio il

processo di sviluppo rispetto al periodo di non

sviluppo con la metodologia SCRUM.

3

1.1 OBIETTIVI  DELLA  TESI  

In questo progetto di tesi si è applicata una

metodologia si sviluppo Agile allo strumento MACXIM.

MACXIM è sviluppato nel contesto delle attività del

progetto Qualipso [18] che è dedicato alla valutazione

della qualità di progetti OSS, insieme a una serie di

altri strumenti. Considerando che il nostro interesse è

rivolto alla qualità dei prodotti OSS, è stato quindi

naturale includere MACXIM nella serie di prodotti OSS

da valutare. Come conseguenza la qualità di ciascuna

emissione di MACXIM è stata accuratamente misurata.

Gli obiettivi che ci siamo prefissati prima di

procedere all’applicazione del processo di sviluppo

SCRUM allo strumento OSS MACXIM sono convogliati nello

rispondere ai seguenti quesiti:

1. È possibile passare con successo da SCRUM a un

processo OSS in fase di sviluppo?

2. È possibile applicare SCRUM a una serie di

sviluppatori geograficamente distribuiti?

3. Può SCRUM contribuire a migliorare la qualità del

prodotto e la produttività del processo?

Per poter rispondere alle tre domande precedenti,

abbiamo individuato una serie di misure e confrontato i

dati ottenuti prima e dopo l’introduzione di SCRUM nel

processo di sviluppo dello strumento MACXIM. I dati

raccolti dopo essere stati analizzati e confrontati

hanno permesso una valutazione quantitativa e

qualitativa dell’applicazione si SCRUM a dei progetti

OSS.

4

1.2 STRUTTURA  DELLA  TESI  

In questo capitolo è stata presentata un’introduzione

al lavoro di tesi svolto.

Nel secondo capitolo vengono presentate i principali

processi di sviluppo classici, andando ad evidenziare

le principali caratteristiche legate ad ogni modello

analizzato.

Nel terzo capitolo vengono presentati i principali

modelli di sviluppo Agili, presi in considerazione per

poter portare a termine con successo gli obiettivi

prefissati.

Nel quarto capitolo viene spiegato come il processo di

sviluppo SCRUM è stato scelto e adattato allo sviluppo

dello strumento MACXIM.

Nel quinto capitolo viene descritto lo strumento

MACXIM, il processo di sviluppo adottato, come è stato

applicato LIGHT SCRUM allo strumento MACXIM ed i

risultati ottenuti a fine lavoro.

5

2 I PROCESSI DI SVILUPPO

Nell’ingegneria del software esistono vari processi di

sviluppo. Possiamo suddividere i processi di sviluppo

in due categorie: i processi classici ed i processi

agili.

2.1 PROCESSI  DI  SVILUPO  CLASSICI  

Nel corso degli anni sono stati sviluppati diversi

processi di sviluppo del software. In questo capitolo

ne verranno presentati alcuni tra i più noti.

• A cascata.

• A spirale.

• Unified Process.

2.1.1 IL  PROCESSO  DI  SVILUPPO  A  CASCATA  

Il processo di sviluppo a cascata (waterfall) è stato

il primo processo di sviluppo studiato nell’ingegneria

del software (Fig. 1).

Il processo di sviluppo a cascata è strutturato

secondo una serie di fasi. Le fasi di questo processo

di sviluppo sono lo studio di fattibilità, descrizione

del problema, progettazione della soluzione, sviluppo e

test di unità, integrazione e test del sistema,

deployment e manutenzione. Vengono svolte in forma

sequenziale: ogni fase per poter iniziare, deve

attendere la conclusione di quella precedente.

6

Fig. 1 Modello a cascata

Vi sono dei problemi evidenti in questo processo di

sviluppo: pur avendo una struttura semplice che

permette di semplificare il lavoro degli sviluppatori,

accade spesso che in una di queste fasi ci si rende

conto che sarebbe necessario tornare a quella

precedente.

Ad esempio, come spesso accade in fase di sviluppo,

emergono alcuni aspetti del sistema non noti in una

prima fase di analisi, che rendono quindi necessario

tornare alla fase precedente per poter chiarire questi

nuovi aspetti.

Un ulteriore problema del processo di sviluppo a

cascata è di non sposarsi bene con progetti dove i

requisiti utente cambiano con una frequenza alta.

7

Questo processo di sviluppo è più adatto allo sviluppo

di grossi progetti software, come ad esempio i primi

sistemi operativi.

2.1.2 IL  PROCESSO  DI  SVILUPPO  ITERATIVO:  A  SPIRALE  

Nel corso degli anni sono stati ideati altri processi

di sviluppo con l’intenzione di affrontare e risolvere

gli aspetti problematici di quello a cascata. È nato

cosi il processo di sviluppo iterativo, ancora oggi

ampiamente usato.

Il processo di sviluppo iterativo è composto da una

serie di iterazioni al termine delle quali è sempre

prodotto un particolare deliverable. Le iterazioni sono

mini-progetti formati da una ripetizione di fasi: le

attività e i deliverable prodotti cambiano in funzione

dello stato di avanzamento del progetto.

Il più famoso processo di sviluppo iterativo è quello a

spirale (Fig. 2).

Fig. 2 Modello a spirale

8

Il processo di sviluppo a spirale conserva gli aspetti

sistematici di quello a cascata, ma cerca di ridurre la

possibilità di errori. Per far questo, il processo di

sviluppo a spirale prevede la realizzazione del

prodotto software attraverso più rilasci incrementali.

Le attività che portano alla creazione di un rilascio,

sono ciclicamente ripetute per ogni versione

successiva, secondo una spirale.

Il processo di sviluppo a spirale è caratterizzato da

una struttura composta da task region. Ogni task region

è costituita da un insieme di attività.

Uno dei vantaggi principali di questo modello è

l’introduzione dell’analisi del rischio a ogni livello

di iterazione. La presenza dell’analisi del rischio

influenza in modo significativo le decisioni prese nel

progetto.

2.1.3 IL  PROCESSO  DI  SVILUPPO  UNIFIED  PROCESS  

Uno dei modelli iterativi più significativi è lo

Unified Process (UP) e il suo esempio più famoso, il

Rational Unified Process (RUP). UP è un modello che

definisce una struttura generica di processo: tale

struttura è poi specializzata per un’ampia classe di

sistemi software.

UP è iterativo e incrementale: è scomposto in progetti

di dimensione e complessità minori da svolgere in

singole iterazioni. Al termine di ogni iterazione è

necessario un momento di verifica e, se l’esito è

positivo, il progetto passa all’iterazione successiva.

Inoltre viene mantenuto un feedback di quanto fatto nel

9

corso dell’iterazione, in modo da assecondare eventuali

cambiamenti occorsi durante il progetto.

Il modello UP è strutturato secondo due diverse

dimensioni:

1. una dimensione temporale suddivisa in fasi che

determina la vita e la maturità del progetto (è la

sequenza di iterazioni citate in precedenza);

2. una dimensione di workflow del processo,

articolata in attività ripetute in ogni iterazione

di ciascuna fase (definisce la struttura di ogni

singola iterazione).

Le fasi del modello UP vengono illustrate in Fig. 3 e

sono inception, elaboration, construction e transition.

Mentre le attività individuate a ogni iterazione sono

requirements, analysis, design, implementation, test.

Fig. 3 Fasi del modello Unified Process

A volte queste fasi assumono un peso ritenuto fin

troppo rilevante. Per questo motivo negli ultimi anni

10

sono stati definiti nuovi processi di sviluppo,

identificati con l’espressione Agile Software

Development.

11

3 I PROCESSI DI SVILUPPO AGILI

L’Agile Software Development è un approccio che punta

l’attenzione verso la capacità di rispondere in modo

veloce ed efficace ai cambiamenti che caratterizzano il

processo di sviluppo del software.

Nel 2001 è stato pubblicato un manifesto dell’Agile

Software Development che ne descrive i principi

fondanti e i valori.

Il termine agile fa riferimento, in generale, alla

capacità di reazione al cambiamento, come ad esempio la

capacità di adattare la soluzione software in base ai

cambiamenti dei requisiti richiesti dall’utente, e alla

flessibilità del lavoro del team durante l’intero

progetto.

In Appendice A - I PRINCIPI FONDANTI DEL MANIFESTO

AGILEvengono riportati i dodici principi che stanno

dietro la stesura del manifesto mentre in [2] i

firmatari del documento.

Nel manifesto sono indicati quattro aspetti che

differenziano il processo di sviluppo agile rispetto ai

modelli esistenti:

• Lo sviluppo agile si focalizza sulle persone e

sull’interazione piuttosto che sul processo e i

tool.

• L’enfasi è sulla realizzazione del software

piuttosto che sulla redazione di una

documentazione esaustiva.

• L’aspetto essenziale è la collaborazione con

l’utente e non la negoziazione del contratto.

12

• È essenziale rispondere al cambiamento piuttosto

che seguire in modo rigido un piano di progetto

preordinato.

Sulla base di questi principi e dei dodici punti del

Manifesto Agile, sono nate un insieme di metodologie

agili, all’interno delle quali è possibile applicare

una o più pratiche in base all’esigenza del committente

del progetto.

Con il termine “pratica” si indica un modo di operare

associato alla metodologia.

Le singole pratiche applicabili alle metodologie agili

sono decine e nella loro scelta si deve tener conto

delle caratteristiche di ogni pratica, per i benefici

che apporta e le conseguenze che comporta. Le pratiche

più diffuse tra cui scegliere sono simili fra di loro e

possono essere raggruppate in categorie come riportato

in Appendice B - PRATICHE.

Qui di seguito verranno descritte le metodologie agili

più significative:

• Extreme Programming.

• SCRUM.

• Feature Driven Development.

• DSDM.

• Lean Software Development.

Tutte le metodologie agili condividono una serie di

caratteristiche comuni e fondamentali come

adattabilità, iteratività, rilasci frequenti, testing,

orientamento alle persone e applicabilità a progetti

dove i requisiti utente cambiano in continuazione.

Operativamente, quindi, le metodologie agili

13

ridimensionano l’importanza e lo sforzo impiegato nelle

attività preliminari del progetto, come ad esempio la

raccolta dei requisiti, la progettazione della

soluzione e in particolare dell’architettura di base.

Ciò non significa che queste attività non siano

eseguite, ma che il tempo e lo sforzo dedicati sono

minori rispetto ai processi di sviluppo software

classici.

14

3.1.1 EXTREME  PROGRAMMING  

Nel 1999 fu pubblicato Extreme Programming Explained

nel quale l’autore Kent Beck presenta un nuovo modo di

sviluppare software, che permette di limitare i rischi

di fallimento strettamente legati alla fase di

progettazione.

L’Extreme Programming (XP) è una metodologia agile,

come tale cerca di rispondere agli obiettivi fissati

dal manifesto agile. In particolare mira alla

realizzazione di un processo di sviluppo leggero e

flessibile, adatto a rispondere in tempi brevi e con

costi ridotti, alle mutevoli richieste del committente

anche in fase avanzata del progetto.

XP propone l’utilizzo di dodici pratiche agili, e

suggerisce di utilizzarle al massimo delle loro

potenzialità, da qui il termine “Extreme”.

Tra le pratiche consigliate troviamo progettare con il

cliente, test funzionali e unitari, refactoring

(riscrivere il codice senza alterarne le funzionalità

esterne), progettare al minimo, descrivere il sistema

con una metafora, proprietà del codice collettiva

(contribuisce alla stesura chiunque sia coinvolto nel

progetto), scegliere ed utilizzare un preciso standard

di scrittura del codice, integrare continuamente i

cambiamenti al codice, il cliente deve essere presente

e disponibile a verificare (sono consigliate riunioni

settimanali), open workspace, quaranta ore di lavoro

settimanali, pair programming (due programmatori

lavorano insieme su un solo computer).

Inoltre XP è caratterizzato da quattro valori chiave:

semplicità, feedback, comunicazione e coraggio. Questo

approccio si focalizza su una progettazione della

15

soluzione il più semplice, inclusiva delle sole

funzionalità che di volta in volta il team deve

rilasciare al committente. L’ideazione e la

pianificazione della soluzione avvengono tramite user

story.

Una user story è la descrizione, semplice e breve, di

una particolare funzionalità richiesta dal committente:

il team di sviluppo analizza tutte le user story e

decide in che ordine implementarle. Il feedback è

ottenuto dal testing continuo eseguito sul codice:

spesso i casi di test sono pensati prima

dell’implementazione del codice che viene quindi

realizzato per rispondere al test definito. Il team,

ricevendo i frequenti feedback del committente, può

adattare i rilasci successivi in modo flessibile.

XP riscuote molto successo nel mondo dello sviluppo e

dell’ingegneria del software, ma ha anche i suoi

detrattori. Essi evidenziano alcuni fattori critici del

metodo, sostenendo che XP funzioni solo con

programmatori di alto profilo (programmatori senior),

capaci di progettare applicazioni scalabili da subito o

in grado di applicare un buon refactoring. Inoltre

sostengono che il pair programming dimezzi il numero di

task eseguibili in parallelo e individuano nel test

driven development del lavoro aggiunto, in quanto

costringe a scrive e mantenere altro codice.

L’estremismo di questo metodo non sempre è apprezzato,

ma gli va riconosciuto il merito di evidenziare

pratiche agili di successo, tra queste può valere la

pena sperimentare in ambiente produttivo quelle che più

si avvicinano alla filosofia aziendale.

16

3.1.2 SCRUM  

SCRUM è stato creato da Ken Schwaber, Jeff Sutherland e

Mike Beedle.

La parola SCRUM non è un acronimo, viene utilizzato

cosi come si presenta dalle aziende per indicare

l’attuazione del processo stesso. Deriva probabilmente

dai primi documenti pubblicati da Ken Schwaber che

portavano nel titolo la parola in maiuscolo SCRUM. È un

termine che deriva dal Rugby ed indica il “pacchetto di

mischia”, dove ogni componente del team di sviluppo

deve “spingere” nella stessa direzione, agendo come

un’entità coordinata.

Di seguito in Fig. 4 viene mostrato il ciclo di vita

del processo SCRUM relativo allo svolgimento di un

Sprint Backlog.

Fig. 4 Ciclo di vita del processo SCRUM

Prima di descrivere il processo stesso, analizziamo le

parti che lo compongono. SCRUM è composto da tre ruoli,

tre cerimonie e tre artefatti.

17

I tre ruoli sono ricoperti da Product Owner, colui che

commissiona, finanzia il progetto ed ha la

responsabilità di definire le caratteristiche del

prodotto e di decidere la data di rilascio ed il

contenuto. Lo ScrumMaster deve garantire che il team di

lavoro sia funzionale e produttivo, una stretta

cooperazione in tutti i ruoli e le funzioni e che il

processo sia eseguito in ogni sua cerimonia, inoltre

deve schermare il team da interferenze esterne.

L’ultimo ruolo ma non meno importante è il team di

sviluppo. Esso si occupa di selezionare e portare a

termine l’obiettivo di ogni Sprint, inoltre si

organizza il proprio lavoro, mostrando i risultati

ottenuti per mezzo di demo al Product Owner.

La prima delle tre cerimonie è lo sprint planning

meeting, un incontro della durata di circa quattro ore,

in cui il Product Owner e il team di lavoro negoziano

su quali caratteristiche devono essere implementate

durante l’iterazione (Sprint), basando questa decisione

su quali caratteristiche con la massima priorità e un

alto valore commerciale è possibile portare a termine

in quel periodo. La seconda cerimonia è il daily scrum

meeting, un incontro mattutino della durata di quindici

minuti, in cui ogni componente del team di lavoro rende

noto cosa ha fatto nella giornata precedente, cosa farà

durante quella giornata e che problemi ha incontrato.

La terza cerimonia è data dallo sprint review meeting,

un incontro di quattro ore, in cui il team di lavoro

presenta al Product Owner ciò che è stato implementato

durante lo Sprint, inoltre viene deciso cosa

implementare nello Sprint successivo, ristabilendo le

priorità di ciascuna caratteristica.

18

I tre artefatti utilizzati in questo processo sono: il

product backlog, che consiste in una lista di

caratteristiche che definisco il prodotto finale. Lo

sprint backlog, è la lista di caratteristiche che il

team di lavoro deve implementare durante lo Sprint. La

burndown chart, contiene il lavoro che non è stato

svolto dal team durante lo Sprint.

In una fase di pre-processo si effettua uno sprint

planning meeting, tra il Product Owner e il team di

lavoro, in cui viene definito il product backlog e lo

sprint backlog. Dopo questa fase avviene il primo

sprint della durata di quattro settimane, in cui

quotidianamente avviene il daily scrum meeting,

presidiato dallo ScrumMaster. Al termine di questo

periodo si effettua lo sprint review meeting, in cui

ciò che non è stato completato viene aggiunto alla

burndown chart, mentre la parte di lavoro portata a

termine viene presentata tramite una demo al Product

Owner.

19

3.1.3 FEATURE  DRIVEN  DEVELOPMENT  

La feature driven development (FDD) è stata ideata da

Jeff De Luca e Peter Coad. Questa metodologia agile

basa la propria forma di sviluppo sulle funzionalità

richieste dal programma. Per poter applicare FDD è

necessario dividere il progetto in cinque fasi chiamate

processi.

Qui di seguito in Fig. 5 viene mostrato il ciclo di

vita del processo FDD con le rispettive fasi

Fig. 5 Ciclo di vita del processo FDD

La prima fase riguarda lo sviluppo di un modello

complessivo. Questa fase viene svolta da un team di

“modellatori”, persone altamente qualificate della

materia da trattare. Hanno il compito di sviluppare un

modello complessivo del dominio del problema. Questo

modello viene aggiornato iterativamente, sulla base dei

risultati ottenuti dal quarto processo.

La seconda fase consiste nella costruzione di una lista

di funzionalità, dove il modello complessivo è

suddiviso in aree più grandi. Ogni area ottenuta viene

20

a sua volta divisa in singole attività (funzionalità o

features), organizzate successivamente in una lista con

una struttura gerarchica.

La terza fase è una pianificazione del processo di

sviluppo sulla base delle funzionalità ottenute

precedentemente, in cui vengono considerate le attività

da svolgere e le relative priorità. Questo processo

coinvolge il capo del progetto, il responsabile dello

sviluppo e i capi programmatori.

Nella quarta fase vengono elaborate le funzionalità. Lo

svolgimento di questa parte è supervisionata dai capi

programmatori, i quali identificano e coordinano i

singoli programmatori per fargli sviluppare una singola

funzionalità.

Nella quinta fase vengono testate le funzionalità

sviluppate al passo precedente utilizzando dei test di

unità e successivamente revisionate dai capi

programmatori.

Una volta terminate queste due operazioni, il codice

viene inserito nel repository del codice di progetto

per poter essere condiviso da tutti gli sviluppatori e

quindi pronto per il rilascio.

21

3.1.4 DYNAMIC  SYSTEM  DEVELOPMENT  METHOD  

Il Dynamic System Development Method (DSDM) è stato

sviluppato in Gran Bretagna ed ora divenuto uno

standard europeo. L’evoluzione del processo agile DSDM

è gestito da un consorzio, che ne permette la

distribuzione gratuita.

Sviluppare un progetto con il processo DSDM, consiste

nel dividere tale sviluppo in tre fasi: pre-project,

ciclo di vita e post-project. Di seguito viene

rappresentata in Fig. 6 la fase ciclo di vita.

Fig. 6 Ciclo di vita del processo DSDM

Il processo DSDM si compone di tre fasi sequenziali,

dove nella fase di pre-project deve essere

concretizzato il finanziamento al progetto e

successivamente vengono individuati i candidati per

portarlo a termine. Nella fase ciclo di vita, composta

da cinque tappe, il progetto è realmente sviluppato.

22

La prima e la seconda tappa sono chiamate Studio, si

dividono rispettivamente in uno studio di fattibilità,

che consiste nel valutare se il processo DSDM è idoneo

per poter realizzare il progetto analizzato e in uno

studio businnes dove viene definito un elenco di

requisiti con le rispettive priorità.

La terza tappa chiamata modello funzionale

d’iterazione, consiste nello sviluppare un modello

funzionale contenente le funzionalità ricavate dal

elenco dei requisiti, accordarsi sugli orari

d’incontro, sviluppare un prototipo funzionale sulla

base del modello e controllarne la correttezza.

La quarta tappa denominata progettazione e costruzione

d’iterazione, è applicata per produrre una prima

release funzionate da consegnare agli utenti finali per

essere utilizzata come test.

Nella tappa finale chiamata attuazione, vengono

raccolti i feedback degli utenti, utilizzati come test,

per proseguire con un successivo raffinamento del

prodotto.

Nella terza fase di post-progetto, viene effettuata una

manutenzione del prodotto, effettuando una nuova

iterazione della seconda fase.

 

 

23

4 APPLICAZIONE DI SCRUM A PROGETTI OSS In genere lo sviluppo di prodotti Software Open Source

(OSS), non segue il tradizionale sviluppo software

proveniente dai paradigmi descritti nei libri di testo

dell’ingegneria del software.

In contrapposizione allo sviluppo OSS, vi sono i

paradigmi di sviluppo classici, pensati e progettati

per sviluppare Closed Source Software (CSS).

L’OSS ha ereditato caratteristiche che hanno reso

questi paradigmi difficilmente conciliabili. Per

esempio, OSS è spesso sviluppato da una comunità

distribuita di sviluppatori ed è liberamente

distribuito, come codice sorgente aperto e disponibile

sia per gli sviluppatori che per gli utilizzatori

finali, sotto specifiche licenze.

Come stiamo descrivendo in questo lavoro di tesi,

l’analisi di alcune caratteristiche intrinseche

dell’OSS [13] da un lato confermano che i paradigmi

rigidi di sviluppo, come ad esempio il modello

Waterfall [14], non sono applicabili all’OSS, mentre,

da un altro lato sembra suggerire che i paradigmi Agili

[15] possano aiutare gli sviluppatori OSS a migliorare

la qualità dei loro prodotti.

Questo è il risultato del fatto che i principi generali

dietro il Manifesto Agile [1] sono riflessi nel modo in

cui la maggior parte dei progetti OSS sono sviluppati e

rilasciati agli utenti finali.

Ciò che caratterizza molti progetti OSS è di non avere

una visione commerciale a breve termine, questo implica

che le attività di analisi del sistema e di

progettazione, di solito non sono pre-programmate nello

sviluppo OSS. Inoltre molti progetti OSS sono stati

24

avviati per risolvere il particolare problema di un

utente, ma a volte finiscono innovando profondamente il

campo del software (questo è il caso di Linux, Perl e

Word Wide Web) anche se non hanno avuto una visione a

lungo termine almeno alla loro nascita.

La necessità di una profonda evoluzione della maggior

parte dei progetti OSS è generalmente percepita dopo

che sono stati utilizzati con successo da una vasta

comunità di utenti.

Il successo di un prodotto OSS è di solito

imprevedibile. Esso è direttamente connesso al grado di

attrattività e di utilità che il prodotto ha nella

comunità degli utenti nel corso del tempo. È quindi

molto difficile pianificare in anticipo le nuove

versioni di un sistema, fatta eccezione per il breve

termine. Queste osservazioni rispecchiano i primi due

principi del Manifesto Agile:

1. Soddisfare il cliente attraverso la consegna

rapida e continua di software di valore.

2. Consegnare frequentemente il software prodotto.

Inoltre OSS è caratterizzato da un ambiente di lavoro

non strutturato, dove la maggior parte degli

sviluppatori OSS sono volontari, che, non si impegnano

a rispettare tempi di consegna e ad avere assegnati dei

compiti specifici.

Nei progetti CSS, ai membri del team sono assegnati

compiti specifici, mentre nei progetti OSS sono i

membri del team che scelgono i propri compiti.

A causa di queste libertà le attività che sono viste

come fattori nocivi, quali la definizione del piano di

progetto, la progettazione del sistema di valutazione e

25

l’analisi dei requisiti, non possono essere eseguite

seguendo paradigmi tradizionali nella comunità degli

sviluppatori OSS.

In molti contesti di sviluppo utilizzando processi

Agili, i requisiti che non sono stati definiti in

anticipo dagli analisti qualificati sono continuamente

discussi dagli sviluppatori.

I rischi vengono monitorati e gestiti nel corso del

ciclo di vita del progetto, in modo naturale, come

parte del normale sviluppo di lavoro.

Queste caratteristiche dell’OSS riflettono il principio

Agile: “Le architetture migliori, i requisiti e i

disegni, emergono da gruppi auto-organizzati”.

L’OSS è sviluppato in modo organizzativo e distribuito

[8]. I sistemi OSS sono sviluppati in un ampio contesto

di scala cooperativa, dove diverse squadre di utenti

privati, nuclei di sviluppatori appassionati e comunità

virtuali, creano la “società non strutturata” (ad

esempio Rymond lo ha soprannominato il “Bazaar”)

contribuiscono allo sviluppo del progetto.

Internet e il desktop, sono il ponteggio per queste

organizzazioni virtuali di sviluppo del software, dove

gli sviluppatori sono coordinati dalle politiche di

licenza semplice, senza meccanismi di controllo

gerarchico, altrettanto rigorosi nello sviluppo CSS.

Di conseguenza gli sviluppatori OSS non seguono quasi

mai metodologie di sviluppo, come ad esempio quelle

definite e seguite dagli sviluppatori CSS.

Inoltre lo sviluppo di progetti OSS è caratterizzato da

una crescita più rapida [16] e più creativa rispetto

allo sviluppo di progetti CSS [17], con l’obbiettivo di

soddisfare e rispondere più rapidamente alle esigenze

degli utilizzatori.

26

Ciò è dovuto principalmente a una organizzazione non

strutturata e informale della comunità. La struttura e

le regole possono “inibire pensatori innovativi e

portarli ai margini” [17], mentre l’informalità e la

libertà di azione promuovono la creatività.

Ciò richiede implicitamente la definizione di

architetture che sono intrinsecamente modulari e

scalabili. Questo per garantire l’estensibilità di un

sistema e l’interoperatività tra differenti hardware e

piattaforme software.

Queste osservazioni rispecchiamo il settimo principio

dell’Agile: “Costruire progetti intorno a persone

motivate, dare loro l’ambiente e il sostegno di cui

hanno bisogno e fidarsi di loro per ottenere il lavoro

svolto”.

L’uso massiccio della rete e delle risorse distribuite

favorisce la diffusione della conoscenza del progetto,

attraverso canali non strutturati come la mailing list,

i forum e la chat, in modo da facilitare la

comunicazione tra sviluppatori, utenti finali e

gestori.

Questo in parte si ricongiunge ai due principi Agili:

“Coloro che finanziano il progetto e gli sviluppatori,

devono lavorare insieme ogni giorno per tutta la durata

del progetto” e “Il più efficiente ed efficace metodo

di trasmissione delle informazioni da e all’interno di

un team di sviluppo è la conversazione face to face”.

Il lavoro riportato in questo documento prende in

considerazione due aspetti principali:

1. Il processo di sviluppo di prodotti OSS assomiglia

spesso ai processi di sviluppo Agili come XP, nei

quali ogni piccola granularità dello sviluppo

27

incrementale viene effettuata tramite un ciclo che

coinvolge la progettazione e l’esecuzione di test;

2. Mentre CSS in questi ultimi anni ha definito

paradigmi di sviluppo rigidi per abbracciare i

modelli Agili, rilasciando poche opere circa

l’applicazione di paradigmi Agili per lo sviluppo

di OSS (ad esempio [10]).

Dopo aver preso in considerazione le osservazioni fatte

fino ad ora, abbiamo applicato una metodologia Agile

allo sviluppo di uno strumento OSS nel progetto

Qualipso [18], e abbiamo effettuato delle misurazioni

per valutare se sia possibile migliorare la

produttività dei processi e la qualità dei prodotti OSS

attraverso un ambiente più controllato rispetto a

quello completamente non strutturato che caratterizza i

progetti OSS.

Più specificatamente abbiamo applicato il processo di

sviluppo SCRUM [1] per l’implementazione di MACXIM

(Model And Code Xml-based Integrated Meter), uno

strumento OSS che estrae misure quantitative e

oggettive da codice sorgente Java.

Abbiamo descritto un insieme di misure di qualità e

produttività che sono state applicate prima e dopo

l’introduzione della metodologia SCRUM nello sviluppo

di MACXIM.

Abbiamo poi confrontato i dati raccolti prima e dopo

l’introduzione di SCRUM, per capire se e come il

processo SCRUM abbia interessato lo sviluppo e abbiamo

ricavato una serie di osservazioni su come applicare

SCRUM ai prodotti OSS.

28

4.1 LIGHT  SCRUM    

Come descritto nel paragrafo precedente, abbiamo deciso

di adottare il processo di sviluppo SCRUM da applicare

allo sviluppo del prodotto MACXIM. Prima di poter

applicare il processo di sviluppo SCRUM al nostro

progetto, si è dovuto elaborare tale processo per

poterlo adattare alle nostre specifiche esigenze di

lavoro, principalmente per risolvere dei problemi

legati alla distribuzione geografica del team di

programmatori.

L'introduzione del processo di sviluppo SCRUM è

avvenuta a metà giugno ‘09 e abbiamo terminato il suo

utilizzo con il rilascio della prima release di MACXIM

alla fine di ottobre ‘09.

Prima di iniziare a utilizzare il processo di sviluppo

SCRUM in modo definitivo, abbiamo voluto effettuare un

periodo di prova di quattro settimane, coincidenti con

l’esecuzione di due “Sprint”.

Dopo che i periodi di prova sono andati a buon fine, si

è deciso di adottare il processo di sviluppo SCRUM.

Uno Sprint consiste in un periodo di due settimane,

dove ogni membro del team di lavoro deve portare a

termine delle funzionalità presenti nello “Sprint

Backlog”.

Uno Sprint Backlog è una lista di funzionalità,

contenente il carico di lavoro del team di

programmatori, necessario ad implementare un certo

numero di caratteristiche presenti nel “Product

Backlog”.

Il Product Backlog è una sequenza di obiettivi,

tradotti in caratteristiche, che il prodotto finale

deve essere in grado di soddisfare. Questa successione

29

di obiettivi è stata generata da un responsabile ad

alto livello del progetto Qualipso.

Ogni Sprint è iniziato con la generazione di uno Sprint

Backlog, che deve essere portato a termine dal team di

programmatori entro e non oltre l’inizio dello Sprint

successivo.

Lo ScrumMaster, colui che ha il compito di facilitatore

nello svolgimento del processo SCRUM, in collaborazione

con il team di programmatori, ha generato i vari Sprint

Backlog sulla base delle priorità di ogni obiettivo

contenuto nel Product Backlog.

Una o più funzionalità presenti nello Sprint Backlog

sono state assegnate dallo ScrumMaster ad ogni singolo

sviluppatore coerentemente con le capacità del membro

del team.

A causa della distribuzione fisica del team di sviluppo

di MACXIM, gli incontri giornalieri prescritti da

SCRUM non sono avvenuti di persona. Abbiamo adottato

una modalità di lavoro on-line, con l'uso di un forum e

di un sistema di videoconferenze. Nello specifico

abbiamo sostituito gli incontri mattutini con un forum

on-line.

Il forum è stato strutturato in modo che per ogni

giorno ci sia un argomento, all’interno del quale tutti

i membri del team devono scrivere i propri commenti in

riferimento a tre domande standard:

1. Che cosa hai completato relativamente allo Sprint

Backlog dell'ultimo incontro?

2. Quale obiettivo ti sei prefissato per oggi (in

relazione allo Sprint Backlog)?

3. Quali difficoltà hai incontrato nello svolgimento

del lavoro?

30

Di seguito in Fig. 7 viene riportata una pagina

d’esempio del forum utilizzato:

Fig. 7 Pagina d'esempio del forum utilizzato

Il forum completo è disponibile al sito

http://qualipso.uniinsubria.it/forum (in italiano).

Ogni mattina, tutti i membri del team di sviluppo

devono accedere al forum per leggere i post e se uno di

loro ha un idea di come risolvere i problemi postati è

incoraggiato a suggerire la soluzione.

La Fig. 8 da un esempio degli incontri mattutini.

Fig. 8 Esempio di incontro mattutino

31

Con l’introduzione del forum i membri del team non si

sono mostrati entusiasti di dover scrivere e leggere

ogni giorni i post mattutini.

Dopo alcuni giorni, il team di sviluppo ha iniziato a

comprendere l’utilità degli incontri virtuali ed

entrambi, il project manager e i nostri "clienti" (cioè

il responsabile ad alto livello del progetto Qualipso)

hanno la possibilità di tenere traccia del lavoro

svolto su base giornaliera.

Dopo aver introdotto il forum abbiamo fatto trascorrere

un periodo di assestamento, della durata di due Sprint

(quattro settimane), in modo che tutti i membri del

team si sono abituati alla nuova modalità di

interazione.

Successivamente abbiamo sostituito l’incontro di inizio

Sprint, tra ScrumMaster e il team di sviluppo, nel

quale viene definito lo Sprint Backlog con un report

on-line via forum, dove sono state riportate le

funzionalità da implementare abbinate ai rispettivi

sviluppatori.

Quindi gli incontri, non sono più avvenuti di persona,

ma on-line ogni due settimane.

Per ovviare a problemi di interazione dovuti al solo

colloquio via forum, abbiamo introdotto incontri in

videoconferenza per un tempo complessivo di quattro

ore, dove si è effettuato il punto della situazione in

merito al progetto ed i membri del team hanno ricevuto

delucidazioni sulle funzionalità da implementare.

Questi incontri sono stati riportati sul forum con un

report.

Durante questi incontri, il team ha iniziato a crescere

insieme, a mostrare maggiore interesse e padronanza del

progetto.

32

Il team di sviluppo ha portato a termine con successo

alcuni Sprint Backlog, mentre le funzionalità che non

sono state sviluppate nei tempi previsti, sono state

ricollocate nel successivo Sprint Backlog assegnato al

team di sviluppo al successivo Sprint.

Un fattore molto interessante che si è verificato con

l’introduzione di questa metodologia di sviluppo è

stato che nel momento in cui un membro del progetto si

è trovato di fronte a un problema che gli impediva di

proseguire con il proprio lavoro, gli altri

sviluppatori lo aiutavano.

Il risultato di aver introdotto il forum e gli incontri

in videoconferenza è stato quello di far condividere a

tutti i membri del team di sviluppo un obiettivo comune

da raggiungere ed un modo di collaborare efficiente.

Nonostante le due tipologie di incontro definite in

precedenza si è reso necessario introdurre degli

incontri di persona una volta al mese della durata di

quattro ore, per evitare un possibile rischio di

mancanza di interazione.

33

5 CASO DI STUDIO

Nel capitolo seguente viene descritto il caso di studio

relativo a questo progetto di tesi. Dopo aver applicato

un processo di sviluppo Agile a un progetto OSS in

particolare allo strumento MACXIM, in questo modo

abbiamo applicato un ambiente più controllato rispetto

a quello completamente non strutturato che caratterizza

i progetti OSS. In fine si è valutato se dalle

misurazioni effettuate è stato possibile ottenere dei

risultati soddisfacenti per migliorare produttività e

qualità dei prodotti OSS. Più precisamente il processo

di sviluppo applicato è stato LIGHT SCRUM, descritto

nel capitolo precedente.

Le misurazione prese in considerazione alla fine del

lavoro di tesi, sono state applicate prima e dopo

l’introduzione di LIGHT SCRUM nello sviluppo di MACXIM.

I dati raccolti sono stati comparati prima e dopo

l’introduzione di LIGHT SCRUM e abbiamo ottenuto una

serie di considerazioni su come applicare LIGHT SCRUM a

prodotti OSS.

5.1  MACXIM  

Lo sviluppo dello strumento MACXIM è iniziato in

maniera piuttosto strutturata e priva di un processo

ben definito. Questo ha comportato che le misure della

qualità di MACXIM, insieme con le misure che indicano

la velocità del progresso di sviluppo, non hanno

mostrato una situazione cosi buona come ci si poteva

immaginare.

34

I nostri obbiettivi di sviluppo servivano per trovare

le cause di tali prestazioni insoddisfacenti e per

trovare e utilizzare i meccanismi che potrebbero

consentire di migliorare il processo di sviluppo e la

qualità del nostro prodotto OSS.

L’analisi della prassi di sviluppo ha indicato che il

problema principale è stata la scarsità di

coordinamento tra gli sviluppatori, i quali, anche a

causa di una mancanza di comunicazione, favorito dalla

distanza fisica degli sviluppatori, non sono stati in

grado di raggiungere una visione condivisa del progetto

e ha omesso di agire in modo coerente.

Si è quindi deciso di migliorare la gestione del

progetto, applicando le attività di coordinamento.

Tuttavia, non abbiamo voluto introdurre troppi vincoli

agli sviluppatori, ma solo orientare i loro sforzi

verso un obbiettivo comune e condiviso.

A tal fine abbiamo deciso di adottare un processo di

sviluppo Agile, in particolare SCRUM [1], una tecnica

di gestione del progetto che consente agli sviluppatori

di raggiungere un compromesso molto buono tra un

coordinamento efficace e una agilità nel processo.

Prima di applicare questo processo di sviluppo allo

strumento MACXIM sono state rilevate delle misurazioni

relative alla situazione “pre-SCRUM”, in modo da poter

utilizzare questi dati come una base rispetto alla

quale abbiamo potuto confrontare i risultati ottenuti

dopo l’introduzione di SCRUM.

In particolare tali misure potrebbero aiutarci ad

effettuare una valutazione quantitativa e oggettiva

dell’impatto dell’introduzione di SCRUM in un contesto

di sviluppo OSS.

35

Questa valutazione ha portato a raggiungere tre

obiettivi principali della ricerca.

In primo luogo abbiamo voluto verificare la possibilità

di passare con successo da SCRUM a un processo OSS in

corso di sviluppo. Quando il nostro progetto è iniziato

è stato seguito da un processo di sviluppo diverso,

quindi non era chiaro se l’introduzione di SCRUM

sarebbe effettivamente stata utile al progetto.

In secondo luogo è stato valutato se l’applicabilità di

SCRUM a una serie di sviluppatori geograficamente

distribuiti poteva essere fattibile: una delle pratiche

di base del metodo di SCRUM è quello di partecipare

alle riunioni quotidiane che possono chiaramente essere

problematiche da organizzare se i partecipanti

risiedono lontano gli uni dagli altri.

In terzo luogo abbiamo voluto verificare in che misura

SCRUM possa aiutare a migliorare la qualità del

prodotto e la produttività del processo. Questo

obbiettivo potrebbe essere definitivamente misurato per

mezzo del set di strumenti di valutazione della qualità

Qualipso.

5.2 PROCESSO  DI  SVILUPPO  

Lo sviluppo del MACXIM è iniziato nel settembre 2007,

senza un preciso progetto in testa. Dopo alcuni mesi,

il project manager ha realizzato che i requisiti e le

scadenze del progetto stesso fossero difficili da

rispettare senza un piano di lavoro ben sviluppato e

senza un team interamente dedicato.

Un anno più tardi, è stato composto un team di

sviluppatori dedicati allo sviluppo di MACXIM e il

36

progetto MACXIM ha iniziato a seguire il suo percorso

naturale, partendo degli attributi di alto livello e

andando nello specifico passo a passo.

Il team era composto da due sviluppatori junior e un

project manager fino a maggio ‘09, quando un nuovo

sviluppatore junior fu coinvolto nel progetto.

Il team crebbe da tre a quattro sviluppatori nel

periodo tra giugno e ottobre ‘09 e ne perse uno in

ottobre.

Tutti gli sviluppatori junior erano coinvolti full-time

sullo sviluppo di MACXIM, mentre il project manager era

impegnato solo parzialmente (tre volte a settimana).

Come molti altri team di sviluppo di progetti OSS , il

nostro team era distribuito geograficamente, con gli

sviluppatori junior residenti a diversi chilometri di

distanza gli uni dagli altri.

Si sono verificati dei problemi di scadenze nel momento

in cui il team è passato da quattro a tre sviluppatori,

principalmente dovuti a esigenze di volatilità.

Come conseguenza il project manager raccomandò

l'introduzione della metodologia Agile per risolvere

questi problemi.

5.3 APPLICAZIONE  DI  LIGHT  SCRUM  A  MACXIM  

Abbiamo iniziato raccogliendo dati sulle misure di

qualità e produttività a Marzo 2009 e abbiamo finito la

raccolta dati alla fine di Ottobre 2009 con l’uscita

della prima release ufficiale di MACXIM. Per due

settimane, alla fine di giugno, abbiamo stoppato lo

sviluppo di MACXIM e abbiamo iniziato un’indagine di

37

qualità e testing per ridurre il numero di errori e

warning all’interno del codice.

L’indagine è stata organizzata sia implementando una

casistica di “unit-test” e “integration test”, ma anche

facendo analizzando il codice con dei tools esterni

come il PMD e Checkstyle, per migliorare la qualità del

codice e rispettare gli standard di codifica (coding).

Questa attività è finita all’inizio di luglio 2009.

A metà luglio abbiamo cambiato il processo di sviluppo,

mantenendo la raccolta dati come avevamo fatto nel

periodo precedente.

Come indicatori “fine-grained” per valutare gli

obiettivi iniziali di ricerca, abbiamo considerato le

misure per le seguenti caratteristiche di prodotto e

processo:

• Organizzazione del codice: abbiamo previsto che

una migliore coordinazione tra gli sviluppatori

poteva portare a un codice meglio strutturato.

Abbiamo usato il numero totale dei “packages”, il

numero medio delle effettive linee di codice

(eLoc) per classe e il numero totale di classi per

misurare l’organizzazione del codice.

• La velocità di produzione. Abbiamo usato il

numero di classi per misurare la “somma del

prodotto”, perché le classi sono più

rappresentative degli eLoc in uno sviluppo

“object-oriented”, sebbene sufficientemente “fine-

grained” per mostrare un progresso quantificabile

su base settimanale. In ogni caso, abbiamo anche

quantificato la produzione in termini di codice

prodotto e eravamo soliti a misurare gli eLoc per

valutare la produttività.

38

• Qualità del codice. Per la qualità interna abbiamo

usato misure tradizionali come le misure di

modularizzazione Chidamber e Kemerer e la misura

di complessità di McCabe, come regole elementari

di struttura del codice, che prevede valutazioni

piuttosto dure, ma significative e facili da

raccogliere. Inoltre, il totale dei commenti nel

codice, che è spesso un indice trascurato, è stato

considerato come un fattore di qualità.

• Efficacia. Infine, come misura di efficacia della

coordinazione di progetto attraverso il processo

di sviluppo SCRUM abbiamo considerato il numero di

“Sprint” andati a buon fine nel applicazione di

SCRUM, considerando l’evoluzione del team di

sviluppo.

5.4 RISULTATI    

Al termine del processo di raccolta dati abbiamo

iniziato l’analisi dei dati e abbiamo derivato un set

di grafici come in Fig. 9Fig. 10Fig. 11Fig. 12Fig. 13.

La Fig. 9 mostra l’evoluzione delle misure usate per

tracciare l’evoluzione del progetto e

dell’organizzazione del codice.

39

Fig. 9 Evoluzione delle misure

Abbiamo raccolto il numero totale di packages, il

numero medio di eLoc per classe e il numero totale

delle classi. La Fig. 9 mostra che il numero dei

packages e il numero totale delle classi è aumentato

con l’introduzione del processo di sviluppo SCRUM,

mentre il numero medio di eLoc per classi è diminuito.

I comportamenti dei numeri di packages e del numero

totale delle classi mostrano che la velocità di

crescita dello strumento MACXIM continua dopo

l’introduzione del processo di sviluppo SCRUM e il

codice sembra essere modulato meglio fino alla

dimensione prevista, da quando il numero medio di eLoc

appare in aumento. Sebbene questi trend sembrano

esistere prima della sua introduzione, lo SCRUM non era

dannoso… inoltre possiamo osservare che l’introduzione

dello SCRUM ha livellato il picco massimo e minimo di

eLocperclass medio che avevamo nel periodo precedente.

Questo è probabilmente dovuto alla funzione generale

dello SCRUM che suggerisce consegne a frequenza

intermedia con funzionalità di lavoro, come tutte le

altre forme di processi software agili. Così il

progetto può cambiare i suoi requisiti in accordo con

40

la modifica dei bisogni, focalizzando su piccole

funzionalità e implementando queste funzionalità in

classi meglio modulate.

La Fig. 10 mostra il numero medio di linee di commento

per eLoc.

Fig. 10 Numero medio di linee di commento

Un’osservazione preliminare del grafico mostra che

questa misura diminuisce dopo l’introduzione dello

SCRUM. Questo non è del tutto vero, perché noi possiamo

osservare solo una crescita durante il periodo di

qualità-testing tra la fine di giugno e l’inizio di

luglio 2009. Il numero medio di linee di commento per

eLoc stava già diminuendo prima di quel periodo, tra

metà aprile e meta giugno 2009. Lo stesso trend di

diminuzione è stato confermato anche dopo

l’introduzione dello SCRUM, nel periodo da metà luglio

a metà ottobre 2009.

La Fig. 11 mostra rapporti sulle misure di qualità del

codice.

41

Fig. 11 Misure della qualità del codice

Abbiamo calcolato la media di mancanza di coesione dei

metodi metriche (LCOM per classe), l'accoppiamento

media tra classi di oggetti (CBO per classe), e la

complessità media ciclomatica nei metodi di ogni

classe. Come indicato nella letteratura, i valori

elevati di queste misure sono indesiderabili, mentre

valori bassi indicano una buona qualità interna del

prodotto software object-oriented. Nella nostra

esperienza, la complessità ciclomatica diminuisce

lentamente ma costantemente, dopo l'introduzione di

SCRUM, mentre le altre due misure di seguire una

tendenza all'aumento. Per quanto riguarda CBO,

accoppiamento eccessiva tra le classi di oggetti è

dannosa per la progettazione modulare e impedisce il

riutilizzo. Il più indipendente di una classe è, più

facile è quello di riutilizzare in un'altra

applicazione. Manutenzione La più grande l'attacco,

maggiore è la sensibilità ai cambiamenti in altre parti

del disegno, e quindi è più difficile. Ciò è in

contrasto con i dati che abbiamo raccolto in Fig. 11

che sembrano suggerire un miglioramento della

42

modularizzazione del codice e, come conseguenza, la

manutenzione del codice. L'incremento del CBO possono

essere correlati a l'incremento elevato abbiamo avuto

sul numero totale di classi dopo l'introduzione di

mischia. In ogni caso, il valore del CBO MACXIM è molto

bassa (ad esempio, un alto valore CBO è considerato

maggiore di 14) [21]. Per quanto riguarda LCOM, la

qualità e la sperimentazione delle attività svolte poco

prima dell'adozione di SCRUM fortemente ridotto LCOM da

un valore di 10 ad un valore di 4. Questo valore

aumenta improvvisamente dopo l'introduzione di SCRUM,

con una punta di valore 7 alla fine di settembre 2009.

Questo valore è negativo si è verificato nello stesso

tempo come il valore massimo del numero complessivo di

classi, suggerendo così un rapporto tra le due misure.

In media, il valore calcolato LCOM durante il processo

a cascata è uguale a quella calcolata durante il

processo di mischia.

In ogni caso, il CBO ei valori LCOM sembrano suggerire

che l'attività di test effettuati durante il processo

di SCRUM, non è così efficace come quella effettuata

durante la qualità precedente / attività di testing.

Ciò può essere spiegato con l'inesperienza dei nostri

tester. Tester che non sono specializzati in processi

che l'uso del ciclo di vita iterativo possono

incontrare maggiori difficoltà quando si prova

all'interno di ogni iterazione, piuttosto che alla fine

di un ciclo di sviluppo, di decidere che cosa prova

quando un prodotto è ancora finito, e lavorando con

altri membri del team per capire cosa a prova,

piuttosto che dai documenti di requisiti di prova.

La Fig. 12 indica il numero di avvisi per ELOC

calcolata per mezzo di PMD e Checkstyle.

43

Fig. 12 Numero di avvisi per eLoc

Il numero di avvisi è stato molto elevato durante il

processo a cascata (una media di 5 avvisi per ELOC), un

brusco calo durante il periodo di controllo di qualità

(con il risultato di 1 avvertimento per ELOC), ed è

rimasta pressoché invariata, con uno molto lento e

lineare crescente tendenza (attualmente, 2 avvisi per

ELOC) dopo l'introduzione di SCRUM.

La Fig. 13 mostra il tasso di sprint il successo e

l'evoluzione del numero di sviluppatori nella nostra

squadra SCRUM.

44

Fig. 13 Evoluzione del tasso di Sprint avvenuti con successo

Con quattro sviluppatori consolidato il tasso di

successo aumenta fortemente dal 55% di sprint con

successo a un tasso del 85%. Il tasso di successo

peggiora con il rinnovamento inaspettata della squadra

alla fine di settembre. Probabilmente, questo

rinnovamento ha invalidato le previsioni e le stime

dello sforzo del team fissati all'inizio del processo

di mischia. L'andamento lineare di sprint di successo

(la linea di luce grigia del grafico) è quasi costante

al tasso del 65%. Probabilmente, una migliore

definizione di arretrati sprint e compiti potrebbero

aumentare questo tasso. Purtroppo, le caratteristiche

intrinseche del MACXIM resa difficile per abbattere le

sue caratteristiche in compiti di poche ore di lavoro.

45

CONCLUSIONI E SVILUPPI FUTURI

Al termine di questo periodo di lavoro, è stato

possibile trarre delle conclusioni in riferimento al

capitolo 1.1 di questo documento. La nostra esperienza

con l’applicazione di un processo di sviluppo agile, in

questo caso SCRUM, a un progetto OSS, in questo caso lo

strumento MACXIM, ha suggerito che:

1. È possibile applicare il processo di sviluppo

SCRUM a progetti OSS anche a progetto già

iniziato. L’analisi dei risultati ottenuti

conferma che l’introduzione di SCRUM non ha inciso

negativamente e in modo significativo sui valori

delle misure che abbiamo calcolato e, in alcuni

casi, abbiamo riscontrato un miglioramento di

queste misure, come ad esempio per la

modularizzazione del codice e la complessità

ciclomatica. Inoltre l’introduzione di SCRUM

induce a pensare che la produttività ha seguito un

andamento costante, senza sbalzi di picchi,

mantenendo una curva di evoluzione più lineare,

rispetto a quelle che abbiamo ottenuto durante lo

sviluppo cascata.

2. È possibile applicare il processo di sviluppo

SCRUM a sviluppatori geograficamente distribuiti,

andando a sostituire gli incontri giornalieri

face-to-face con meccanismi di comunicazione on-

line. Dai risultati ottenuti il team di sviluppo

ha dato una buona risposta in termini di

cooperazione e di raggiungimento di un obiettivo

comune.

46

3. Con l’applicazione del processo di sviluppo SCRUM

abbiamo ottenuto un codice di alta qualità, con un

rendimento medio della produttività da parte del

team di sviluppatori del 70%. Inoltre siamo stati

in grado di rispettare i tempi previsti per il

rilascio della prima release ufficiale dello

strumento MACXIM.

Come considerazione finale, applicando il processo di

sviluppo SCRUM originale, a una comunità di sviluppo

OSS non sarebbe possibile a causa di limitazioni

geografiche, culturali e problemi di comunicazione.

Spesso gli sviluppatori appartenenti a queste comunità

si trovano in tutto il mondo, in genere in diversi fusi

orari. Pertanto, non è possibile né avere incontri del

mattino, né incontri di pianificazione dello Sprint

Backlog. Nel nostro team, abbiamo applicato una

versione leggermente modificata di SCRUM e abbiamo

sostituito gli incontri di persona con un forum online.

Inoltre, pensiamo che SCRUM si possa applicare a

progetti OSS caratterizzati da un numero limitato di

partecipanti, per consentire una comunicazione puntuale

tra gli sviluppatori.

Attualmente, stiamo raccogliendo nuovi dati SCRUM dal

monitoraggio dello sviluppo della seconda release di

MACXIM prevista per la fine del 2010. Ci occupiamo di

raccogliere anche questi dati, al fine di confrontare

questi nuovi dati con quelli ottenuti da questo lavoro

e di confermare, con ulteriori risultati, le

conclusioni che abbiamo ottenuto con questa prima

esperienza. In realtà, ci aspettiamo un ulteriore

miglioramento di tutte le misure che abbiamo raccolto.

47

BIBLIOGRAFIA

1. Schwaber, K., Beedle, M.: Agile Software

Development with SCRUM. Prentice Hall (2001).

2. Beck, K., Beedle, M., van Bennekum, A., Cockburn,

A., Cunningham, W., Fowler, M., Grenning, J.,

Highsmith, J., Hunt, A., Jeffries, R., Kern, J.,

Marick, B., C. Martin, R., Mellor, S., Schwaber,

K., Sutherland, J., Thomas, D.: Manifesto for Agile

Software Development. Web published:

http://www.agilemanifesto.org/

3. Crisà, A.F., del Bianco, V., Lavazza, L.: A tool

for the measurement, storage, and pre-elaboration

of data supporting the release of public datasets.

In González-Barahona, J.M., Conklin, M., Robles, G.

(eds.) Workshop on Public Data about Software

Development (WoPDaSD 2006), Como (2006).

4. Chidamber, S.R., Kemerer, C.F.: A Metrics Suite for

Object Oriented Design. IEEE Transactions on

Software Engineering. 20, 476--493 (1994)

5. McCabe, T.J.: A complexity measure. IEEE

Transactions on Software Engineering. 2, 30--320

(1976).

6. Boehm, B.W.: A Spiral Model of Software Development

and Enhancement, IEEE Computer. 21(5), 61--72

(1988).

7. Northover, M., Northover, A., Gruner, S., Kourie,

D.G., Boake, A.: Agile software development: A

contemporary philosophical perspective. ACM

International Conference Proceeding Series. 226,

106--115 (2007).

48

8. Raymond, E.S.: The Cathedral & the Bazaar. O’Reilly

(2001).

9. Sutherland, J.: Agile can scale: Inventing and

reinventing scrum in five companies. Cutter IT

Journal. Cutter Information Corp. Vol. 14, No. 12,

December (2001).

10. Düring, B.: Sprint Driven Development: Agile

Methodologies in a Distributed Open Source Project

(PyPy). In XP 2006. 191--195 (2006).

11. Mann, C., Maurer, F.: A Case Study on the Impact of

SCRUM on Overtime and Customer Satisfaction. In

Agile Development Conference, 70--79 (2005).

12. Rising, L., Janoff, N.S.: The SCRUM Software

Development Process for Small Teams. IEEE Software,

17(4), 26—32 (2000).

13. Feller, J., Fitzgerald B., A framework analysis of

the open source software development paradigm,

Proceedings of the twenty first International

Conference on Information systems (2000).

14. Ghezzi, C., Jazayeri, M., Mandrioli, D.:

Fundamentals of Software Engineering, Second

Edition. Pearson, Prentice Hall (2002).

15. Northover, M., Northover, A., Gruner, S., Kourie,

D. G., & Boake, A.: Agile software development: A

contemporary philosophical perspective. ACM

International Conference Proceeding Series (Vol.

226, pp. 106–115) (2007).

16. Mockus, R., Fielding, T., and Herbsleb J.: A case

study of OSS development: the apache server, in

Proceedings of the International Conference on

Software Engineering (ICSE), pp. 263–272, (2000).

49

17. O’Reilly, T.: Lessons from Open-Source Software

development, Communications of the ACM, vol. 42,

no. 4, (1999).

18. QualiPSo portal. Web published:

http://www.qualipso.eu Accessed: December 2009

19. Checkstyle tool download. Web published:

http://checkstyle.sourceforge.net/ Accessed:

December 2009

20. PMD tool download. Web published:

http://pmd.sourceforge.net/ Accessed: December 2009

21. Sahraoui, H.A., Godin R., Miceli T.: Can Metrics

Help Bridging the Gap Between the Improvement of OO

Design Quality and Its Automation? In Proceedings

of the International Conference on Software

Maintenance (ICSM), (2000).

50

Appendice A - I PRINCIPI FONDANTI DEL MANIFESTO AGILE

• La nostra massima priorità è soddisfare il cliente

per mezzo di tempestivi e continui rilasci di

software di valore.

• Siano benvenuti i cambiamenti nelle specifiche,

anche a stadi avanzati dello sviluppo. I processi

agili sfruttano il cambiamento a favore del

vantaggio competitivo del cliente.

• Rilascia software funzionante frequentemente, da

un paio di settimane a un paio di mesi, con

preferenza per i periodi brevi.

• Manager e sviluppatori devono lavorare insieme

quotidianamente lungo il progetto.

• Basa i progetti su individui motivati. Dai loro

l'ambiente e il supporto di cui necessitano e

confida nella loro capacità di portare il lavoro a

termine.

• Il metodo più efficiente ed efficace di

trasmettere informazione verso e all'interno di un

team di sviluppo è la conversazione faccia a

faccia.

• Il software funzionante è la misura primaria di

progresso.

• I processi agili promuovono uno sviluppo

sostenibile. Gli sponsor, gli sviluppatori e gli

utenti dovrebbero essere in grado di mantenere un

ritmo costante indefinitamente.

• L'attenzione continua per l'eccellenza tecnica e

il buon design esaltano l'agilità.

51

• La semplicità - l'arte di massimizzare l'ammontare

di lavoro non svolto - è essenziale.

• Le migliori architetture, specifiche e design

emergono da team auto-organizzati.

• A intervalli regolari il team riflette su come

diventare più efficace, dopodiché mette a punto e

aggiusta il suo comportamento di conseguenza.

52

Appendice B - PRATICHE

• Automation - Se l'obiettivo delle metodologie

leggere è concentrarsi sulla programmazione senza

dedicarsi alle attività collaterali, allora

possono essere eliminate o automatizzate; la

seconda soluzione è migliore perché si può, ad

esempio, eliminare la documentazione aumentando il

testing, ma non si possono eliminare entrambe;

quindi si sceglie che strada si vuole percorrere e

si fa in modo da utilizzare strumenti per

automatizzare il maggior numero di attività;

• Close Communication - Secondo Alistar Cockburn,

probabilmente il primo teorico delle metodologie

leggere, questo è l'unico vero aspetto nodale che

renda leggera una metodologia. Per comunicazione

diretta si intende la comunicazione

interpersonale, fra tutti gli attori del progetto,

cliente compreso. Ciò serve ad avere una buona

analisi dei requisiti ed una proficua

collaborazione fra programmatori anche in un

ambito di quasi totale assenza di documentazione;

• Customer Involvement - Il coinvolgimento del

cliente è qui indicato singolarmente perché ci

sono differenti gradi di coinvolgimento possibili;

ad esempio in Extreme Programming il

coinvolgimento è totale, il cliente partecipa

persino alle riunioni settimanali dei

programmatori; in altri casi, il cliente è

coinvolto in una prima fase di progettazione e poi

non più; in altri ancora il cliente partecipa

53

indirettamente e viene usato come test della

versione rilasciata;

• Design & Documentation - Pensare che le

metodologie leggere eliminino la progettazione e

la documentazione è un errore, in effetti non è

così, le metodologie leggere introducono

un'iterazione nel ciclo di vita del progetto;

quanta progettazione fare e quanta documentazione

produrre, escludendo i casi estremi, è una scelta

lasciata a chi gestisce il progetto e spesso i

teorici dell'Agile Alliance avvisano che è un

errore trascurare o addirittura omettere queste

due fasi;

• Frequent Delivery - Effettuare rilasci frequenti

di versioni intermedie del software permette di

ottenere più risultati contemporaneamente: si

ricomincia l'iterazione avendo già a disposizione

un blocco di codice funzionante in tutti i suoi

aspetti, si offre al cliente 'qualcosa con cui

lavorare' e lo si distrae così da eventuali

ritardi nella consegna del progetto completo, si

usa il cliente come se fosse un test visto che

utilizzerà il software e riscontrerà eventuali

anomalie, si ottengono dal cliente informazioni

più precise sui requisiti che probabilmente non

sarebbe riuscito ad esprimere senza avere a

disposizione utilità e carenze del progetto;

• Hierarchy - La scelta di creare una struttura

gerarchica all'interno del team di sviluppo

dipende molto dall'approccio del project manager,

54

in ogni caso si ha una conseguenza non secondaria

facendo questa scelta; se si decide per una

struttura gerarchica ad albero e frammentata si

ottiene la possibilità di gestire un numero molto

alto di programmatori e di lavorare a diversi

aspetti del progetto parallelamente; se si decide

per una totale assenza di gerarchia si avrà un

team di sviluppo molto compatto e motivato, ma

necessariamente piccolo in termini di numero di

programmatori;

• Pair Programming - Programmare in coppia, ossia:

due programmatori, due sedie, una scrivania, un

computer, una tastiera ed un mouse; uno dei due

scrive, l'altro verifica, entrambi scelgono la

soluzione costruttiva migliore; è stato dimostrato

che i costi di questa scelta sono inferiori ai

benefici che apporta, ma ci sono esempi pratici

che indicano come questa pratica possa essere

insopportabile per alcuni programmatori e quindi

controproducente;

• Refactoring - Ossia la riscrittura completa di

parti di codice mantenendone invariato l'aspetto

esterno, nel caso di una funzione ciò significa

riscriverne completamente il core mantenendone

invariato header ed ovviamente sintassi,

trattandola cioè come una black box; è una delle

pratiche più diffuse e suggerite, ma anche questa,

come il Pair Programming, ha differenti studi che

ne attestano l'inutilità ed in alcuni casi la

dannosità;

55

• Reflective Improvement - Nata con l'avvento della

programmazione Object-Oriented, non è altro che la

presa di coscienza della produzione di conoscenza

che si fa in un un'azienda man mano che si produce

codice; questa conoscenza prodotta non deve andare

perduta ed è per far ciò che si sfruttano spesso

le altre pratiche, come la comunicazione stretta o

la condivisione della proprietà del codice;

• Reverse Engineering - Ossia ottenere, spesso in

maniera automatica, la documentazione a partire

dal codice già prodotto; è una delle pratiche più

diffuse e più controverse, diffusa perché permette

un guadagno enorme in termini di tempo, ma

controversa perché spesso la documentazione

prodotta è inutilizzabile oppure è prodotta solo

per una richiesta burocratica del cliente e non

verrà mai realmente utilizzata;

• Simplicity - Uno dei punti chiave delle

metodologie leggere, direttamente mutuato dalla

programmazione Object-Oriented, è la semplicità;

semplicità nel codice, semplicità nella

documentazione, semplicità nella progettazione,

semplicità nella modellazione; i risultati così

ottenuti sono una migliore leggibilità dell'intero

progetto ed una conseguente facilitazione nelle

fasi di correzione e modifica;

• Team forming & Code property - La formazione del

team di sviluppo è condizionata dalla scelta sulla

gerarchia interna, ma segue regole precise che

permettono di ottenere un team produttivo

56

nell'ambito della metodologia scelta; la scelta

dei membri del team è condizionata anche alla

scelta della proprietà del codice, che può essere

individuale o collettiva; nel primo caso la

responsabilità sullo sviluppo è individuale, nel

secondo dipende da tutto il team e quindi dal

project manager;

• Testing - Pratica diffusissima anche prima della

nascita delle metodologie leggere, ha prodotto una

letteratura vastissima ed una serie di approcci

differenti come il Rapid Testing o il Pair

Testing; nell'ambito delle metodologie leggere

vengono spesso utilizzati insieme tre tipi di test

differenti: i test funzionali, utilizzati per

verificare che il software faccia effettivamente

ciò che è previsto debba fare, i test unitari,

utilizzati per verificare che ogni pezzo di codice

funzioni correttamente, e i test indiretti

effettuati inconsciamente dal cliente ogni volta

che gli si consegna una versione;

• Version Control - Una delle conseguenze dirette

dell'iterazione nella produzione è la necessità di

introdurre un modello, un metodo, uno strumento,

per il controllo delle versioni del software

prodotto e rilasciato; uno degli strumenti più

diffusi e maggiormente suggeriti per ottemperare

automaticamente a questa pratica è il CVS.

57

RINGRAZIAMENTI