M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1. INTRODUZIONE

L’ ingegnere del software è, periodica-mente, bombardato dagli annunci di

approcci rivoluzionari che cambieranno defi-nitivamente il suo modo di lavorare, dando-gli, finalmente, la possibilità di conseguirequegli obiettivi di produttività e qualità cheha sempre sognato. Le cose stanno, in realtà,in maniera differente, ma non è sempre faciledistinguere quanto effettivamente ci sia diinnovativo e originale perché la rivoluzione è,innanzitutto, terminologica e spesso si usa-no parole nuove per ribadire concetti già no-ti. In un famoso articolo del 1987 [7], F.Brooks analizzò, a fondo, quali fossero le dif-ficoltà intrinseche e ineliminabili del softwa-re (essential difficulties), argomentando, inmodo molto efficace e convincente, che ilprogresso, fino ad allora, aveva solo aggredi-to gli aspetti più facili (accident). Le conclu-

sioni che venivano tratte erano che non esi-steva una panacea capace di rendere facile losviluppo del software. Secondo l’efficacemetafora di Brooks, non esiste il rassicurantesilver bullet capace di eliminare “il lupo man-naro delle favole dei bambini”. Purtroppo, ilmito del silver bullet ha continuato ad affac-ciarsi sulla scena della tecnologia software,manifestandosi attraverso la sopravvaluta-zione o la generalizzazione di metodi, tecni-che e strumenti che si dimostravano efficaciin certi contesti, ma che venivano, ingiustifi-catamente, proposti come soluzioni generalidefinitive. L’entusiasmo dei ricercatori e, an-cor più spesso, la propaganda commerciale,hanno in molti casi generato false aspettati-ve di soluzioni miracolistiche che, alla provadei fatti, hanno subito mostrato i propri limi-ti. Uno dei settori in cui più frequentementesi è assistito a questo fenomeno è quello deimetodi e strumenti di supporto al processodi produzione del software. In tale ambito,per l’appunto, si colloca l’eXtreme Program-

ming (XP). Il motivo dell’interesse per questotema è evidente, data la sua rilevanza econo-

L’XP, nel processo di sviluppo del software, ha l’obiettivo di evitare la produ-

zione di semilavorati diversi da quelli necessari alla realizzazione delle appli-

cazioni. Presentata come un approccio del tutto nuovo e originale, ha in

realtà le sue radici in metodi già noti e sperimentati. Secondo chi scrive,

inoltre, pur introducendo utili concetti e offrendo un approccio valido in al-

cuni specifici contesti, l’XP è troppo spesso proposta come una soluzione

universale ai problemi della moderna produzione industriale di software1.

Carlo GhezziMattia Monga

EXTREME PROGRAMMING:PROGRAMMAZIONEESTREMA O REVISIONISMOESTREMISTA?

3

1 Questo lavoro è stato svolto in parte nell’ambito delprogetto Sahara cofinanziato dal MIUR (Ministerodell’Istruzione dell’Università e della Ricerca).

3.1

mica. L’obiettivo, infatti, è quello di definirela struttura del processo di sviluppo in mododa renderlo, il più possibile, efficace e con-trollabile. Nei metodi tradizionali, la control-labilità è ottenuta dettagliando fasi e attivitàattraverso cui il processo deve evolvere, defi-nendo le regole di transizione da una fase al-la successiva e documentando ognuna di es-se secondo procedure standardizzate. Lepersone coinvolte nello sviluppo, perciò, so-no responsabili della produzione non solodel codice sorgente dell’applicazione, ma an-che di molti altri semilavorati, che non sononecessariamente rivolti alla pura generazio-ne del codice. Ogni applicazione, però, poneproblemi diversi, ed è difficile e irrealistico(se non addirittura impossibile) definire unprocesso universalmente valido, senza cade-re nei generici richiami al buon senso. Quan-do si cerca di adottare una qualche forma diprocesso senza progettarne l’adattamentoalle specifiche esigenze del caso, il lavoro ag-giuntivo finisce per essere percepito comeburocrazia inutile, che influisce in manieranegativa sulla flessibilità e l’efficienza.L’XP promette di mantenere la controllabilitàdel processo pur riducendo il lavoro di sup-porto e convogliando il massimo dello sforzosulla mera produzione dell’applicazione.Un altro problema ricorrente nella produzio-ne del software è che spesso i risultati otte-nuti da anni di lavoro finiscono per soddi-sfare solo le esigenze degli sviluppatori, an-ziché quelle dei committenti.L’XP promette di fornire i meccanismi perchégli sviluppatori possano acquisire, durante lo

sviluppo, la consapevolezza che ciò che stan-no costruendo soddisferà pienamente, almomento della sua posa in opera, le esigen-ze di chi l’ha commissionato. Quanto detto finora costituisce una pre-messa teorica al presente articolo che saràsuddiviso in tre parti. Nella prima (Para-grafo 2) si fornirà una breve presentazionedelle principali caratteristiche dell’XP. Nellaseconda (Paragrafo 3) si cercherà di colloca-re il metodo nel contesto dei metodi di defi-nizione dei processi software. Con ciò si in-tende mostrare come l’XP, che spesso vienepresentata come un approccio del tuttonuovo e originale, in realtà abbia le sue ra-dici in metodi noti da e sperimentati da mol-

ti anni. Infine, nella terza (Paragrafo 4) sifornirà una valutazione di XP, cercando dispiegare perché, secondo chi scrive, essapur introducendo utili concetti e ponendoreali problemi, possa essere complessiva-mente valutata come uno dei tanti silverbullet falliti. Alcune lezioni che essa insegnadevono senz’altro essere tenute in seriaconsiderazione dagli ingegneri del softwarema, altrettanto chiaro, deve risultare il fattoche non si tratta della soluzione definitiva aiproblemi dello sviluppo delle moderne ap-plicazioni software di qualità, come tantaletteratura sull’argomento vorrebbe far cre-dere. In altri termini, se è vero che alcunedelle raccomandazioni dell’XP si inquadra-no correttamente nel solco delle propostedi processi di produzione di software agili eflessibili e che in quanto tali, forniscono unbagaglio concettuale utile al progettista dioggi, nella visione radicale che realizza lasua formulazione data dai propri paladinicostituisce solo un revisionismo estremisti-co dei metodi tradizionali, che rischia di pro-durre un danno anche maggiore di quelloche vorrebbe eliminare.

2. XP: UN TUTORIAL

Con eXtreme Programming si intende unatecnica, proposta da K. Beck, per organizzareil processo di sviluppo del software con l’e-splicito obiettivo di evitare la produzione disemilavorati diversi da quelli strettamentenecessari alla realizzazione dell’applicazio-ne. Dettagliate specifiche formali, approfon-dite analisi e puntigliosa documentazionesono considerate attività troppo costose ri-spetto ai benefici apportati, in quanto limita-no la flessibilità del processo che deve potermodificare i propri obiettivi in ogni momento.La produzione di un’applicazione, secondoBeck, non è un’attività che possa essere ana-lizzata e precisamente pianificata a priori. In-vece, esattamente come quando si guidal’automobile, la condotta complessiva è il ri-sultato di un gran numero di minimi cambia-menti di rotta che il pilota decide in base allasua istantanea percezione di curve ed osta-coli. Il lavoro dei programmatori procede or-ganizzando quattro attività fondamentali chesi ripetono per tutto il corso del progetto:

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

0

0

0

1

4

❙ scrittura del codice dell’applicazione (co-ding);❙ verifica delle funzionalità (testing);❙ osservazione dell’ambiente, inteso comedesideri del committente, opportunità tecno-logiche, sviluppi di mercato (listening);❙ progetto dell’applicazione (design).I programmatori sono responsabili non solodella codifica dell’applicazione, ma anchedella sua verifica. Anzi, particolare enfasi èposta proprio su questa attività: nessunaistruzione dovrebbe essere considerata vera-mente parte dell’applicazione finché non nesia stato verificato l’effetto secondo le atte-se. La costruzione dell’applicazione procedein maniera iterativa, cogliendo le reazioni deicommittenti e riprogettando, in maniera ade-guata, le sue funzionalità e i meccanismiadottati per ottenerle.Perché queste attività possano essere svolteefficacemente, vengono identificate alcuneprassi fondamentali che aiutino i program-matori a rendere il loro lavoro il più efficientepossibile.Pianificazione delle attività (Planning the

game). Lo sviluppo dell’applicazione è ac-compagnato dalla stesura di un piano di la-voro. Il piano è definito e, continuamenteaggiornato, a intervalli brevi e regolari dairesponsabili del progetto, secondo le prio-rità aziendali e le stime dei programmatori,che partecipano, in modo attivo, alla pianifi-cazione. Il meccanismo per attuare, effica-cemente, la pianificazione è articolato comeun gioco in cui sono coinvolti utenti respon-sabili del progetto e sviluppatori per stabili-re un equilibrio dinamico fra le esigenze ditutti gli attori coinvolti. Gli utenti finali del-l’applicazione presentano gli obiettivi daraggiungere descrivendo una serie di sce-nari (storie) che il sistema deve soddisfare.Gli sviluppatori stimano il tempo necessarioper la realizzazione di ogni storia: qualoraciò non sia possibile, la storia viene suddivi-sa in storie più semplici. Le storie vengonoordinate da utenti e responsabili secondo laloro priorità di realizzazione, dopo che glisviluppatori ne hanno stimata la rispettivadifficoltà. Dalla sintesi di queste valutazionii responsabili del progetto generano la pia-nificazione delle attività, intesa come l’in-sieme di storie che dovranno essere realiz-

zate per il prossimo rilascio e le date previ-ste: sarà, inoltre, loro principale responsa-bilità misurare e controllare l’andamentodelle attività rispetto alla pianificazionestessa. Questo processo viene ripetuto do-po ogni rilascio per pianificare il successivo.Una pianificazione più dettagliata viene poidecisa dagli stessi sviluppatori, i quali defi-niscono i “compiti” elementari necessari al-l’implementazione delle singole storie. Perogni compito uno sviluppatore deve stimarei giorni necessari al suo completamento eassumersi la responsabilità della sua realiz-zazione. Il carico di ciascuno sviluppatorenon deve superare quello concesso dallapianificazione del rilascio, dopo essere sta-to pesato secondo un fattore di efficienza digruppo che tiene conto delle necessità dicooperazione tramite riunioni, incontri conil committente ecc..Rilasci frequenti (Short releases). La vita elo sviluppo dell’applicazione sono scanditidai rilasci di versioni del prodotto funzionan-ti, nel senso che realizzano qualcuna dellestorie che ne descrivono gli obiettivi. Ogni ri-lascio rappresenta il punto conclusivo di un’i-terazione di sviluppo e l’inizio di una nuovapianificazione. Per poter tener conto di cambidi prospettiva, errori di valutazione, nuovi re-quisiti, restrizioni di bilancio, ogni iterazionedovrebbe durare non più di qualche settima-na (in genere, da due a quattro).Metafora condivisa (Metaphor). Ogni pro-getto è guidato da una metafora condivisa daresponsabili e sviluppatori. La metafora nonè altro che una descrizione semplificata, maefficace, del sistema nel suo complesso. Ser-ve a fornire un vocabolario comune a tutte lepersone coinvolte, senza scendere nei detta-gli implementativi.Progetti semplici (Simple design). La strut-tura dell’applicazione deve essere la piùsemplice possibile. L’architettura del siste-ma deve essere comprensibile da tutte lepersone coinvolte nel progetto. Non devonoesserci parti superflue o duplicazioni. Le par-ti che compongono il sistema devono essere,soltanto, quelle strettamente necessarie alleesigenze correnti. Solo quando nuove circo-stanze lo richiederanno, verranno progettatinuovi componenti, eventualmente riproget-tando anche quelli già esistenti.

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

5

0

0

0

1

Ristrutturazione del codice (Refactoring).Come si è detto precedentemente, l’applica-zione necessita di continue riprogettazioniper eliminare parti divenute superflue e peradattare il sistema alle nuove esigenze. Que-sta attività è detta refactoring, ristrutturazio-ne, a intendere che, ogni volta che si intrave-de la possibilità di eliminare parti superflue odi semplificarne l’organizzazione, l’interastruttura del codice va adattata ai nuovi prin-cipi progettuali.Verifica di ogni funzionalità (Testing). Ognifunzionalità va sottoposta a verifica, in modoche si possa acquisire una ragionevole cer-tezza sulla sua correttezza. Ciò sia a livello disistema (test di sistema) sia a livello del sin-golo metodo (test di unità). I test di sistemasono costruiti sulla base delle storie concor-date con il committente che dice l’ultima pa-rola sulla convalida del sistema. I test diunità devono poter essere rieseguiti automa-ticamente, con tempi dell’ordine dei minuti:allo scopo è utile avvalersi di strumenti op-portuni [10]. Ogni ristrutturazione o modificadel codice deve mantenere inalterato il risul-tato dei test già considerati. I test vengono,generalmente, scritti prima della codifica del-la funzionalità. Il metodo prescrive, addirittu-ra, che il codice da sviluppare debba soddi-sfare tutti i test e niente di più. SecondoBeck, la verifica è sostanzialmente una falsi-ficazione di stampo “popperiano2”: una teo-ria (il codice dell’applicazione) viene messaalla prova grazie ad una serie di osservazioni(casi di test) che essa deve spiegare (ovvero,non deve disattendere le aspettative). Ogninuova teoria deve rimanere coerente con leosservazioni descritte precedentemente.Programmazione a coppie (Pair program-

ming). La scrittura vera e propria del codice èfatta da coppie di programmatori che lavora-no al medesimo terminale. Le coppie non so-no fisse, ma si compongono associando le

migliori competenze per la risoluzione di unospecifico problema. Il lavoro in coppia per-mette, scambiandosi periodicamente i ruoli,di mantenere mediamente più alto il livellod’attenzione. I locali dove si svolge il lavorodevono permettere senza difficoltà di lavora-re a coppie.Collettivizzazione del codice (Collective ow-

nership). Il codice dell’applicazione può es-sere liberamente manipolato da qualsiasisviluppatore. Ciò è possibile grazie al fattoche l’organizzazione è la più semplice possi-bile e che il codice è scritto rispettando rego-le condivise da tutti. La collettivizzazione èanche un meccanismo per stimolare la sem-plificazione delle parti più oscure del codice,che, essendo incomprensibili a tutti, fuorchéagli autori, hanno un’alta probabilità di esse-re eliminate. Naturalmente ogni modificanon deve pregiudicare la correttezza dei test.Integrazione continua (Continuous integra-

tion). Non sono previste sessioni particolaridi integrazione. In effetti, dato che il codicedell’intera applicazione è sotto il controllo ditutto il gruppo di sviluppo, l’integrazione dellavoro dei singoli è continua. Deve essere co-stantemente possibile ottenere una versionefunzionante dell’applicazione sulla qualeoperare le verifiche. Una piattaforma prontaper l’integrazione è sempre disponibile per iprogrammatori.Rinuncia al lavoro straordinario (40-hour

week). Lo sviluppo di applicazioni con i metodidell’eXtreme Programming è un’attività che ri-chiede grande concentrazione, entusiasmo ecreatività. Il lavoro in condizioni di stress, conripetute sessioni straordinarie, provoca neces-sariamente un deterioramento della qualitàdell’impegno e deve pertanto essere evitato.Per questo motivo, la pianificazione coinvolgeanche gli sviluppatori ed è aggiornata di fre-quente per tener conto di errori e imprevisti.Partecipazione del committente (Onsite cu-

stomer). Il committente deve essere coinvol-to nello sviluppo perché è l’unica fondamen-tale fonte di convalida del sistema. Partecipaperciò alla stesura dei test di sistema e verifi-ca, periodicamente, che il sistema realizzatocorrisponda effettivamente alle proprie esi-genze. Inoltre, è la principale fonte di infor-mazione per la conoscenza sul dominio diapplicazione. Secondo chi propone il meto-

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

0

0

0

1

6

2 Il filosofo di origine austriaca Karl Popper (1902-1994) sostenne che un’ipotesi scientifica non puòmai essere verificata da risultati sperimentali, chepossono tuttalpiú semplicemente corroborare lanostra fiducia in essa. Viceversa, un risultato spe-rimentale contrario alle aspettative (falsificazio-ne) permette di sviluppare nuova conoscenza, ob-bligando al rifiuto dell’ipotesi di partenza.

do, la comunicazione orale tra progettisti ecommittenti, unita alla definizione a prioridei test, allevia la necessità di produrre unaformulazione scritta e precisa dei requisiti.Uso di standard per la codifica (Coding stan-

dards). Il codice deve esplicitare le astrazionidei programmatori ed è il loro principale stru-mento di comunicazione. Deve, pertanto, es-sere scritto in maniera uniforme e omoge-nea. Tutti gli sviluppatori devono essere ingrado di capire e modificare ogni linea di co-dice scritta da altri.

3. IL CONTESTODELLE METODOLOGIEDI PROCESSO

Dalla fine degli anni ’60 in poi, con la nascitadell’ingegneria del software come disciplina,ci si è posti il problema di definire modelli delciclo di vita del software, dalla concezione ini-ziale dell’idea del prodotto fino al suo svilup-po, al suo rilascio e, infine, alla sua dismissio-ne. Tutti i prodotti industriali di cui si voglionoassicurare adeguati livelli di qualità vengono,infatti, sviluppati secondo processi sistemati-ci ben definiti. L’esistenza di un processo diproduzione ben definito viene, addirittura,considerato come un prerequisito necessarioperché il prodotto industriale possa aspirarea raggiungere un livello di qualità certificabile.Il primo e più noto modello di processo è no-to come ciclo di vita a cascata. Il ciclo di vita acascata, nato come esperienza all’interno disistemi militari sviluppati fin dagli anni ’50, ècaratterizzato da una progressione lineareattraverso fasi (per l’appunto, in cascata),quasi si trattasse di una catena di montaggioattraverso cui far procedere le attività di svi-luppo del software.Nel seguito, vengono presentate le caratteri-stiche fondamentali di un’organizzazione acascata del ciclo di vita.❙ La sequenzialità del processo. Secondo iproponenti, ciò dovrebbe garantire una mi-gliore controllabilità e prevedibilità del pro-cesso e, quindi, la capacità di tenere i costi e itempi di sviluppo sotto controllo. I ritorni al-l’indietro, infatti, vengono considerati danno-si ai fini di tenere il processo sotto controllo.❙ La definizione di fasi e attività standard. Perciascuna fase, viene definito, con esattezza,

il criterio di successo che permette di certifi-carne il completamento e, quindi, l’autorizza-zione a procedere alla fase successiva. Per dipiù, spesso vengono prescritti metodi speci-fici che i progettisti sono tenuti a seguire perlo svolgimento delle attività della fase.❙ Gli standard documentali. Si afferma, spes-so, che un ciclo di vita a cascata è document

driven. Con ciò si intende che i semilavorati diciascuna fase, che costituiscono input per lafase successiva, sono documenti che devonoseguire certi standard che l’organizzazioneproduttiva prescrive. Il completamento di cia-scuna fase, pertanto, viene a identificarsi conl’approvazione, da parte dei responsabili delprogetto, dei documenti che rispettano glistandard prescritti. Il ciclo di vita a cascata,posto ancor oggi, in molti casi, come modellogenerale di riferimento per lo sviluppo disoftware, è in realtà un modello irrealistico e,spesso, del tutto inadeguato. L’organizzazio-ne lineare del processo non può quasi maiavverarsi in pratica ma, anzi, il risultato dellosvolgimento di certe fasi comporta, spesso,la ripetizione di quanto è stato fatto in fasiprecedenti. Ciò è causato, principalmente,dalle difficoltà connesse con l’acquisizione especifica dei requisiti. È, in generale, illusoriopretendere di congelare i requisiti in una spe-cifica esaustiva che viene prodotta all’iniziodel processo, in base alla quale si procedepoi al progetto dell’architettura e all’imple-mentazione dell’applicazione. I requisiti sonospesso, inizialmente, confusi e, dunque, nonsono noti in maniera precisa e, qualora lo sia-no, è facile che vengano fraintesi dall’inge-gnere del software, che potrebbe non averealcuna competenza circa il dominio applicati-vo nel quale l’applicazione dovrà operare.Con un modello a cascata, errori o fraintendi-menti nella specifica dei requisiti verrebberoscoperti molto tardi, quando l’applicazioneviene rilasciata al committente o immessasul mercato. Il risultato è dunque che, imme-diatamente, inizia una fase di “manutenzio-ne”, che in realtà tende solo a rimediare glierrori introdotti all’inizio e, tornando indie-tro, a rielaborare l’analisi e la specifica dei re-quisiti. È anche stato osservato che moltospesso i requisiti si chiariscono solo dopoche una qualche forma dell’applicazione vie-ne posta nelle mani del committente e che,

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

7

0

0

0

1

quindi, risulta illusorio ipotizzare che il pro-cesso di sviluppo possa procedere in modolineare, basato su conoscenze che possonosolo in parte essere note a priori.In conclusione, il ciclo di vita a cascata nascecon l’obiettivo primario di ridurre il rischio chei costi e i tempi di sviluppo non siano control-labili. Nel cercare di limitare questo rischio,vengono ignorati i rischi ancora più gravi chesono dovuti alla scarsa conoscenza e all’in-stabilità dei requisiti, che fanno sì che la ridu-zione dei costi di sviluppo sia solo illusoria, eche si riversi, da un lato, in elevati costi di ma-nutenzione e, dall’altro, in insoddisfazionedei committenti. Un modo più astratto di ca-ratterizzare un ciclo di vita a cascata definisceil processo come una scatola nera, che riceve,in ingresso, la specifica dei requisiti dell’ap-plicazione e che, in uscita, fornisce l’applica-zione finale, ottenuta attraverso la sequenzalineare di fasi. Poiché il processo di acquisi-zione e specifica dei requisiti soffre dei pro-blemi intrinseci che sono stati riassunti inprecedenza, qualunque sia la scomposizionein fasi che viene scelta per articolare le atti-vità della scatola nera, si arriverà sempre, etroppo tardi, a scoprire che occorre procederea modifiche e ricalibrazioni, ripercorrendo intutto o in parte il processo di sviluppo.È anche possibile definire modelli flessibili,agili e incrementali in cui si abbandona l’ideadello sviluppo dell’applicazione intesa comeun prodotto monolitico, con un processo te-so a un’unica data finale di consegna. Al con-trario, il processo di sviluppo viene visto co-me una successione di rilasci incrementali,che adatta lo sviluppo in maniera flessibile airequisiti man mano che questi vengonoesplicitati.Viene così abbandonata l’idea che debba esi-stere un unico modello di riferimento daadottare come standard immutabile e univer-sale, ma viene invece accettato che il model-lo di processo debba essere di volta in voltadefinito in base alle specifiche caratteristichedell’applicazione.Pur senza entrare in dettagli che esulano dal-lo scopo di questo lavoro (e per una trattazio-ne dei quali si rimanda a un testo di Ghezzi etal. [8]), si ricorda che i modelli alternativi pro-posti di volta in volta hanno preso il nome dimodelli basati su rapid prototyping, di mo-

delli user driven, di modelli “a spirale” (percontrasto con la linearità del ciclo a cascata[1]). Esempi ben noti, e diversi tra loro, di or-ganizzazione innovativa del ciclo di vita delsoftware sono offerti dal cosiddetto Unified

Development Process, sviluppato nel conte-sto di UML (Unified Modeling Language) [12],dal metodo agile e flessibile adottato da Mi-crosoft, descritto da Cusumano e Selby [6] edefficacemente definito come synchronize &

stabilize e, infine, dai processi di tipo “ba-zaar” seguiti talvolta per lo sviluppo disoftware open-source [17]. È stato anche os-servato [7] che nell’èra di Internet sempre piùspesso chi sviluppa software innovativo puòseguire la strategia di sviluppare versioni ini-ziali rendendole, in qualche modo, disponibi-li, anche in forma gratuita, attraverso Inter-net. Ciò può incoraggiare molti potenzialiutenti, da un lato, a sperimentare l’uso del-l’applicazione e, dall’altro, a fornire utili sug-gerimenti per sue modifiche che potrebberoessere, successivamente, incorporate nelprodotto.In questo modo, si generano comunità virtua-li di early adopter che possono essere fideliz-zati al prodotto e che lo adotteranno quandoquesto verrà poi messo sul mercato, o checommissioneranno servizi aggiuntivi, stabi-lendo così un forte legame anche di naturaeconomica con il produttore di software. Laproposta dell’XP, si colloca, dunque, in uncontesto generale che, da tempo, ha ricono-sciuto l’improponibilità sia di metodi generalie universalmente adottabili per lo sviluppodelle applicazioni, sia l’inadeguatezza, se nonin casi molto specifici, di metodi rigidamentesequenziali, quali il ciclo di vita a cascata. Inparticolare, si colloca all’interno dei metodiagili e flessibili, che vogliono rispondere inmaniera efficace sia all’instabilità dei requisitiche all’esigenza di rapide risposte al mercato.

4. UN’ANALISI CRITICA DELL’XP

In che senso la produzione di software, se-condo la modalità proposta da Beck, deveessere considerata estrema? Probabilmen-te, l’intenzione dei proponenti era quella disuggerire l’idea che la costruzione di appli-cazioni è un’attività che deve essere svoltain condizioni particolarmente rischiose, in

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

0

0

0

1

8

cui i progettisti e gli implementatori, a diffe-renza di quanto accade in altre discipline in-gegneristiche, devono essere in grado direagire, prontamente, a ogni genere dieventualità impreviste: cambiamenti dei re-quisiti, stravolgimenti tecnologici e dell’am-biente in cui il sistema verrà utilizzato, turn-over dei lavoratori ecc..Ecco, allora, che in un contesto simile il “me-glio” diventa nemico del “bene” e l’unica co-sa che conta è generare, prima possibile,un’applicazione utilizzabile. A parere di chiscrive, invece, il termine “estremo” caratte-rizza bene un approccio che non si limita aproporre una collezione di buone tecnicheche l’ingegnere del software può scegliere divolta in volta, ma che fornisce una soluzioneradicale in cui le singole tecniche sono inte-grate in un approccio estremista.L’ipotesi, implicitamente accettata, sembraessere che l’analisi sia, in sé, un appesanti-mento del progetto. Il credo dei programma-tori estremi è che “ad ogni giorno deve basta-re la sua pena”, ovvero non serve prevedere ipossibili cambiamenti, perché la previsione èconsiderata troppo incerta per valere il suocosto. L’ingegneria del software tradizionaleinsegna che cambiare idea ha un costo checresce esponenzialmente nel corso del pro-getto. La curva di figura 1, che si trova su mol-ti testi classici di ingegneria del software [16],descrive, in maniera qualitativa3, quello che ènormalmente considerato l’andamento deicosti delle varianti in corso d’opera. In so-stanza, motiva la ragionevolezza del vecchioadagio ingegneristico (e non solo) secondocui “prevenire è meglio che curare”. SecondoBeck, invece, al giorno d’oggi, i progressi del-la tecnica nella produzione del software (so-prattutto la diffusione di linguaggi orientatiagli oggetti e la disponibilità di strumenti au-tomatici di verifica e di refactoring) fanno sìche l’andamento dei costi sia meglio descrit-to da una curva come quella di figura 2, percui è possibile rischiare una variante tardivaper risparmiare tempo prezioso nelle primefasi dello sviluppo. Questa curva, peraltro,non appare giustificata da reali dati di natura

empirica, ma viene presentata come la con-seguenza indiscutibile dei progressi tecnici emetodologici sopra ricordati, che per atto difede assumono così il ruolo di nuovi silverbullet. Si può ammettere l’esistenza di classidi applicazioni per le quali l’approccio dell’XPpuò risultare vantaggioso: sistemi non criticidi piccola-media dimensione, di tipo esplora-tivo (per esempio, nella ricerca e sviluppo) o,comunque, fortemente caratterizzati da re-quisiti poco definiti e instabili. Ma per tutti isistemi di una certa complessità che vengono

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

9

0

0

0

1

3 Per una curva rappresentante dati reali si vedal’articolo di Bohem [2].

100

80

60

40

20

00 20 40 60 80 100

Tempo dall’inizio del progetto

Cost

i

FIGURA 1Relazione tradizionale fra costi delle modifiche e momento in cui vengono attuate

0 20 40 60 80 100

Tempo dall’inizio del progetto

100

80

60

40

20

0

Cost

i

FIGURA 2Relazione fra costidelle modifiche emomento in cuivengono attuatesecondo XP

costruiti prevedendone una certa sopravvi-venza nel tempo, l’approccio dell’XP deve es-sere stemperato in forme meno estreme, inparticolare, attraverso un maggiore investi-mento nelle attività di acquisizione, analisi especifica dei requisiti. Sarcasticamente, Beckvede in tali attività una pura perdita di tempo:una produzione di graziosi diagrammi di dub-bia utilità che nessuno utilizza durante lo svi-luppo dell’applicazione. Non c’è dubbio che,in molti casi, questa fase cruciale venga inter-pretata come il burocratico aderire a stan-dard aziendali che prevedono la produzionedi moduli cartacei e di diagrammi talvolta su-perflui. Forse perché la metodologia propo-sta risulta essere particolarmente difficile daapplicare e facile ai fallimenti? Non sembraopportuno credere che Beck abbia sceltoquesto nome per insinuare alcunché di simi-le, né per sottolineare il suo approccio inte-gralista nel rifiuto delle pratiche correnti del-l’ingegneria del software. È anche vero che, inassenza di una focalizzazione mirata, esiste ilrischio di concentrarsi su aspetti dell’applica-zione che non hanno alcun interesse o scarsapriorità per il committente. Ma esiste un ri-schio anche più serio che lo sviluppo dei pro-dotti software degeneri in un processo senzafine del tipo code & fix [8]. La specifica dei te-st che devono essere superati da ciascunanuova versione del prodotto è, di fatto, soloun criterio illusorio di accettazione. Per loronatura, i test definiscono solo un campione fi-nito di possibili comportamenti del prodotto:non possono, dunque, esaurirne né la speci-fica né l’accettabilità. In sistemi dalle caratte-ristiche critiche e, a maggior ragione, in siste-mi safety critical, inoltre, è del tutto impropo-nibile che non si ponga l’accento sulla neces-sità di un’analisi a priori. La letteratura è ric-chissima di esempi di malfunzionamenti chesono da ascrivere ad un’errata comprensioneiniziale o a un’inefficace formulazione dei re-quisiti [19, 20]. Un’analisi fondata su metodirigorosi o formali potrebbe, invece, ridurre irischi o del tutto eliminare le cause dei mal-funzionamenti. Ciò è coerente con quanto ac-cade in settori ingegneristici dalla tradizionemaggiormente consolidata, che hanno spes-so reso obbligatorie alcune forme di analisipreliminari: si pensi ai calcoli del cemento ar-mato o ad altre forme di verifica che devono

essere svolte, a priori, per fare convalide pro-gettuali che devono necessariamente prece-dere la realizzazione. È, quindi, opportunal’enfasi che l’XP pone nel ricordare che costi,tempi, qualità dei risultati e generalità delprodotto non sono variabili indipendenti l’u-na dall’altra, ma si influenzano a vicenda:progettisti e manager tendono a volte a di-menticarlo provocando l’esplosione dei costi.Il suggerimento di Beck è, in sintesi, quello disacrificare la generalità, rinunciando ad anti-cipare aleatorie e imprevedibili evoluzioni fu-ture e, quindi, rinunciando a produrre solu-zioni progettuali che facilitino tale evoluzio-ne. Così facendo, però, Beck cade in contrad-dizione con ciò che Parnas ha insegnato at-traverso il principio di design for change [17]e che generazioni di ingegneri del softwarehanno (con maggiore o minor successo) mes-so in pratica nell’ultimo ventennio. Lo sforzodi individuazione delle possibili evoluzionifuture del sistema non deve certo diventareun esercizio sterile e del tutto teorico che ri-schia di prolungare i tempi di analisi senzareali riscontri pratici. Tuttavia, una costanteattenzione alle probabili future evoluzioni co-stituisce uno dei principi basilari su cui si fon-da l’ingegneria del software. Dunque non sipuò che convenire sull’opportunità che i pro-gettisti profondano molte energie e tutta laloro esperienza e sensibilità nell’identifica-zione di quelle parti del sistema suscettibili dimaggiori modifiche, strutturando le applica-zioni in modo tale che i cambiamenti più pro-babili siano anche i meno costosi, cosicché iloro sforzi siano ripagati nel tempo e gli inve-stimenti ammortizzati.Malgrado la proposta dell’XP, intesa comemetodo generale unitario sia, da chi scrive,ritenuta poco convincente, si deve constata-re che essa ha recentemente riscosso unacerta popolarità.Le ragioni sono duplici: da un lato, ragioni ef-fimere che derivano dalla moda e dalla novitàdell’approccio, dall’altra ragioni più profon-de che derivano dall’aver riproposto in unaforma nuova principi e metodi consolidati. Leragioni del primo tipo sembrano dovute prin-cipalmente a due fattori collaterali, più che alloro intrinseco valore:❙ l’uso della metafora e dello slogan teorizzatocome mezzo per comunicare e condividere gli

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

0

0

0

1

10

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

11

0

0

0

1

obiettivi; come insegna la realtà quotidiana,però, metafore e slogan, pur essendo formi-dabili metodi di aggregazione di massa, sonospesso delle grossolane semplificazioni chelasciano spazio a pericolose ambiguità, e tra-scurano aspetti fondamentali dei problemi;❙ l’uso di semplici ricette empiriche per gesti-re la complessità dello sviluppo; se è veroche ogni sforzo deve essere fatto per domi-narne l’intrinseca complessità, Brooks ha in-segnato che non esistono facili scorciatoie.Lo sviluppo di software è una complessa atti-vità di progettazione che si basa in primis

sulle capacità individuali delle persone e sul-la loro attitudine a cooperare nel lavoro digruppo. Non esistono ricette generali prefis-sate che si possono dare a supporto di que-sta attività, ma solo una serie di principi, me-todi, tecniche e strumenti che gli ingegneridel software, di volta in volta, devono esserein grado di aggregare in un processo atto asviluppare lo specifico progetto sul quale so-no impegnati. Purtroppo, invece, periodica-mente, il fascino illusorio della semplificazio-ne estrema dato dai ricettari standard riap-pare come un silver bullet nello scenario del-l’ingegneria del software.Si esaminano ora, invece, le ragioni positivedella diffusione dell’XP. Innanzitutto, si os-serva che, malgrado si sia cercato in passatodi introdurre metodi sistematici di sviluppo,la produzione artigianale di software (code &fix) è un approccio ancora, estremamente,diffuso. Le metafore e le ricette (magari so-stenute dall’uso di strumenti semplici e op-portuni) proposte dall’XP possono essere unmodo per insinuare alcune idee dell’ingegne-ria del software in ambienti altrimenti restii.Un po’ come è successo recentemente con ja-vadoc, lo strumento che Sun distribuisce conJava e che permette di ottenere documenta-zione direttamente dai commenti del codice:la literate programming non è, di per sé, un’i-dea rivoluzionaria, né una tecnica nata conJava, tuttavia, si deve riconoscere l’indubbiaefficacia che ha avuto la diffusione di un si-mile strumento sulla qualità della documen-tazione del software prodotto in ambito ac-cademico o di ricerca e sviluppo. Così, peresempio, l’organizzazione dello sviluppo ba-sata sulle “storie” riflette la necessità bennota di coinvolgere il committente nella vali-

dazione del sistema, fin dalle prime fasi dellasua costruzione, e l’opportunità dell’uso dielementi tangibili per la pianificazione e iltracciamento dei progressi del lavoro. La col-laborazione del committente allo sviluppo,quando è praticabile, è senz’altro auspicabi-le, anche perché riduce la conflittualità con-trattuale. Molto spesso, però, quello che sivorrebbe davvero è il coinvolgimento degliutenti finali che potrebbero avere obiettivi di-versi da quelli identificati dal committente e,soprattutto, diversi fra loro. Non convince, in-vece, l’idea che la mera partecipazione delcommittente all’interno del progetto riducala necessità di un’attenta documentazione dispecifica. Se si può convenire che tale speci-fica possa non essere necessaria sul momen-to, la sua necessità si giustifica quando oc-corre revisionare e far evolvere l’implementa-zione. In che modo è possibile risalire dal co-dice alle sue motivazioni? Come si può risali-re dall’implementazione ai principi ispiratoridelle scelte di progetto?La tecnica del pair programming appare utilein molti casi. La programmazione è, infatti,tradizionalmente considerata un’attività soli-taria praticata da persone introverse e sco-stanti anche se geniali. Tant’è che viene dachiedersi quanto questa mitologia del real

programmer [18] abbia influito sulla cronicascarsità di presenza femminile fra gli svilup-patori. L’XP propone la programmazione acoppie che può, in effetti, essere un modoper migliorare la comunicazione di tecniche eobiettivi all’interno del gruppo di lavoro ren-dendolo più omogeneo e per introdurre ripe-tute ispezioni del software volte a migliorar-ne la qualità. Le figure 3, 4 e 5 mostrano i ri-

FIGURA 3Confronto frail tempodi realizzazione cone senza pairprogramming [4]

CONFRONTO DEI TEMPI: SINGOLO PROGRAMMATORE VS COPPIA

Programma 1 Programma 2 Programma 3

Singolo programmatore Coppia di programmatori

200.0%

150.0%

100.0%

50.0%

0.0%

sultati di un esperimento [4] condotto per va-lutare gli effetti dell’introduzione della pro-grammazione a coppie. La correttezza (Figura4) e la compattezza (Figura 5) del codice au-mentano, significativamente, a prezzo di unamodesta diminuzione della produttività (Fi-gura 3). Secondo J. Nosek [14], il tempo ri-sparmiato assegnando a due programmatoriil lavoro che potrebbe fare uno solo è in me-dia il 29%. Altri studi [11] mostrano che la pro-grammazione a coppie permette di far cre-scere velocemente ed efficacemente le capa-cità dei novizi e migliora la qualità del lavoroperché le persone coinvolte beneficiano deirapporti interpersonali.L’uso delle tecniche di pair programmingcomporta, dunque, un aumento del costodel personale, ma permette di essere più

prontamente sul mercato e nel caso di pro-getti in cui il time to market è un fattore cri-tico, può effettivamente portare vantaggieconomici [13]. Inoltre, accoppiando pro-grammatori di diversa esperienza, essa ri-sulta essere un utile strumento didattico,anche se abbastanza costoso per tutte leparti in causa.Un’altra tecnica che ha raggiunto una certadiffusione è la scrittura di test di unità primadella codifica dell’unità stessa. La popolaritàdi tale tecnica la si deve soprattutto alla di-sponibilità di numerosi e pratici strumentiper la loro esecuzione automatica (il più notodei quali è Junit [10]). Nella sua essenza essapuò essere considerata una forma di pro-grammazione per contratto, in cui i contrattinon sono descritti in maniera dichiarativa,ma procedurale. Pur vantaggioso, l’approc-cio procedurale, comporta principalmentedue problemi:❙ una specifica dichiarativa (sostanzialmenteintensiva) è normalmente più sintetica e de-scrittiva di una procedurale (estensiva); perdi più, una specifica procedurale, data attra-verso casi di test in numero finito, risulta ne-cessariamente parziale;❙ alcune proprietà sono difficili da descriverein maniera procedurale; si pensi ad un pro-gramma Java che faccia uso di thread: perscrivere dei test che mettano in evidenza del-le corse critiche bisognerebbe poter manipo-lare la macchina virtuale Java.La tecnica di anticipare la scrittura dei testè, talvolta, ritenuta efficace per facilitare lastessa scrittura del codice dell’applicazio-ne. Uno studio recente [12] mostra che, ingenerale, ciò non accade, ma coerentemen-te con l’interpretazione della programma-zione per contratto, la presenza dei test fa-cilita il riuso del codice in contesti nuovi odiversi. L’integrazione continua garantisceche esista, in ogni momento, un prototipo ouna versione dell’applicazione funzionante.Questa è, in generale, una condizione assaidesiderabile, come del resto da tempo met-tono in evidenza molti autori4, perché per-

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

0

0

0

1

12

FIGURA 4Confronto fra la correttezza con e senza pair programming [4]

CORRETTEZZA VERIFICATA DOPO LO SVILUPPO

Programma 1 Programma 2 Programma 3

Singolo programmatore Coppia di programmatori

100.0%

80.0%

60.0%

40.0%

20.0%

0.0%

NUMERO DI ISTRUZIONI

Programma 1 Programma 2 Programma 3

Singolo programmatore Coppia di programmatori

120.0%

100.0%

80.0%

60.0%

40.0%

20.0%

0.0%

FIGURA 5Confronto fra

la compattezzadel programma

con e senza pairprogramming [4]

4 Il processo synchronize & stabilize adottato daMicrosoft [6] si basa fondamentalmente su questoprincipio.

mette di convalidare continuamente ciò cheè stato costruito. Non va dimenticato però,che affidando la convalida dei requisiti sem-pre e solo all’esecuzione dell’applicazione,la possibilità di esplorare soluzioni alterna-tive è fortemente ridotta. L’integrazionecontinua e la proprietà condivisa di tutto ilcodice, poi, sembrano tecniche del tuttoinapplicabili quando il numero di program-matori sale e il numero dei conflitti diventaingestibile. Considerazioni simili valgonoper le ristrutturazioni del codice. Al momen-to gli strumenti per operare queste ristrut-turazioni in maniera semi-automatica sonoancora piuttosto rozzi. Pertanto, attualmen-te, sembra possibile ristrutturare in manieraconsistente solo porzioni di codice di di-mensioni relativamente modeste.

5. CONCLUSIONI

L’eXtreme Programming è nata, negli ultimianni, come approccio radicalmente nuovo alprocesso di sviluppo del software. In questoarticolo, dopo averne illustrato i tratti salien-ti, si è cercato di collocare XP all’interno delquadro complessivo dei metodi di supportoal processo. È stato inoltre evidenziato comeXP abbia le proprie radici all’interno dellaclasse di metodi agili, flessibili ed incremen-tali che da molti anni sono stati proposti, elargamente applicati, in alternativa ai proces-si a cascata che si dimostravano invece ina-deguati nelle situazioni, per altro molto fre-quenti, caratterizzate da incertezza e variabi-lità nei requisiti o dalla necessità di rispostain tempi rapidi alle esigenze di un mercato inrapida e continua evoluzione.Il giudizio che viene espresso è che, se lemotivazioni alla base dell’approccio risulta-no largamente condivisibili, assai criticabileappare il tentativo di congelare la rispostain un metodo di processo che, a sua volta, sipresenta come predefinito e universale.Mentre alcuni singoli suggerimenti e tecni-che dell’XP pare che possano costituire utilistrumenti nel bagaglio degli attrezzi di cuipuò disporre l’ingegnere del software, si è,invece, fondamentalmente critici riguardoalla loro aggregazione in un metodo unita-rio che venga presentato come la soluzionedi tutti i problemi del processo software.

Questa idea, come si è detto, è fallita in pas-sato ed è destinata a fallire in quanto nontiene conto delle specificità che ogni singo-lo progetto e ogni singola organizzazionecaratterizzano [5].Da ultimo, si vuole, invece, evidenziarequello che, secondo il parere degli autoridel presente articolo, è il contributo più im-portante dell’XP al dibattito scientifico al-l’interno dell’ingegneria del software. Insintesi, XP ricorda con grande determinazio-ne che il fine ultimo dell’ingegneria delsoftware è produrre programmi: il codice,spesso considerato semplicemente come ilrisultato finale di un lungo ed elaborato pro-cesso, è il vero obiettivo e su di esso (che losi voglia o no) finiscono con il concentrarsigli sviluppatori.Si deve riconoscere che, troppo spesso, l’in-gegneria del software ha prodotto metodiinutilmente elaborati e onerosi e che, trop-po spesso, gli standard aziendali si sono di-mostrati eccessivamente meticolosi e buro-cratici. In molti casi, gli sviluppatori non so-no riusciti a vedere vantaggi sensibili nellaloro adozione, ma solo un intralcio nel pro-cedere verso l’implementazione. Gli stru-menti di Computer Aided Software Enginee-

ring (CASE) - ovvero, un altro silver bulletdel passato - sono in larga misura falliti pro-prio perché nel codice prodotto mancaval’evidenza della sua relazione con le fasi diprogetto e, quindi, alla fine, non portavanoa un codice migliore, più facile da far evol-vere, ma semplicemente sviluppato più ve-locemente.La lezione da trarre per il futuro è, dunque,che i metodi e gli strumenti di supporto alprocesso dovranno consentire una rapidatransizione al codice e dovranno fornire vi-sibili benefici in termini di verificabilità emodificabilità del codice. La documentazio-ne di analisi e di progetto non solo dovràautomaticamente essere legata al codiceed evolvere con esso, ma dovrà giocare unruolo attivo, sia nel generare automatica-mente parte dell’applicazione che nel ge-nerare automaticamente strumenti per lasua convalida.Sembra opportuno, a questo punto, conclu-dere sottolineando come le affermazioni diefficacia fatte dai paladini dell’XP, siano

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

13

0

0

0

1

quasi sempre argomentate su basi pura-mente ideologiche e perciò prive di suppor-to sperimentale.Gli studi recenti apparsi sull’argomento [4,12, 13] corroborano solo in parte le argo-mentazioni dell’XP. Molto lavoro di ricerca è,dunque, ancora necessario per valutare glieffetti delle singole tecniche proposte, inmodo che l’ingegnere del software possaveramente considerarle nuove frecce a di-sposizione del suo arco.

Bibliografia[1] Boehm BW: A spiral model of software develop-

ment and enhancement. IEEE Computer, Vol.21, n. 5, 1988.

[2] Bohem BW: Software engineering. Transactions

on Computers, Dec.1976.

[3] Brooks F: No silver bullet: Essence and acci-dents of software engineering. IEEE Computer,Vol. 20, n. 4, Apr. 1987.

[4] Cockburn A, Williams L: The costs and benefits

of pair programming. In Extreme ProgrammingExamined. Addison Wesley, 2001.

[5] Cugola G, Ghezzi C: Software processes: a re-

trospective and a path to the future. SoftwareProcess 14 Improvement and Practice 4, 3,Sept. 1998.

[6] Cusumano MA, Selby RW: Microsoft Secrets.The Free Press, New York, NY, 1995.

[7] Cusumano MA, Yoffie DB: Software develop-ment on Internet time. IEEE Computer, Vol. 32,n. 10, Oct. 1999.

[8] Ghezzi C, Jazayeri M, Mandrioli D: Fundamen-

tals of Software Engineering, second ed. Prenti-ce Hall PTR, Apr. 2002.

[9] Jacobson I, Rumbaugh J, Booch G: The Uni-

fied Software Development Process. ObjectTechnology Series. Addison-Wesley, Rea-ding/MA, 1999.

[10] Junit: http://www.junit.org.

[11] Lippert M, Roock S, Wolf H, Zullighoven H:JWAM and XP: Using XP for framework develop-

ment. In Extreme Programming Examined. Ad-dison Wesley, 2001.

[12] Muller M M, Hagner O: Experiment about test-

first programming. In Conference on EmpiricalAssessment In Software Engineering EASE ’02(Keele, Apr. 2002).

[13] Muller MM, Padberg F: Extreme programming

from an engineering economics viewpoint. InFourth International Workshop on Econo-mics-Driven Software Engineering Research(EDSER), Orlando, Florida, May 2002.

[14] Nosek J: The case for collaborative program-ming. Communications of the ACM, Vol. 41, n. 3,Mar. 1998, p. 105–108.

[15] Parnas DL: Designing software for ease of ex-

tension and contraction. In Proceedings of theThird International Conference on Software En-gineering, 10-12 May 1978,

[16] Pressman RS: Principi di Ingegneria del softwa-

re. Second ed. Mc Graw Hill, 1997.

[17] Raymond, ES: The Cathedral and the Bazaar.[Online.] Available:http://www.ccil.org/~esr/writings/cathedral-paper.html, Nov. 1997.

[18] Real programmers:http://www.cirr.com/~bark-ley/jokes/realprog.html.

[19] Neumann PG: Computer Related Risks. ACMPress 1995.

[20] Jackson M: Software Requirements and Specifi-

cation: a lexicon of practice, principles, and

prejudices. Addison-Wesley, 1995.

M O N D O D I G I T A L E • n . 4 - d i c e m b r e 2 0 0 2

1

0

0

0

1

14

CARLO GHEZZI è professore ordinario di Ingegneria del Software presso il Politecnico di Milano e responsabilescientifico dell’area di ricerca sull’ingegneria del software presso il CEFRIEL. Autore di numerosi articoli scien-tifici e libri, è editor in chief della rivista “ACM Transaction on Software Engineering and Methodology”.e-mail: ghezzi@elet.polimi.it

MATTIA MONGA ha conseguito il dottorato di ricerca in Ingegneria Informatica e Automatica presso il Politec-nico di Milano nel 2001. I suoi interessi di ricerca riguardano l’ingegneria del software in ambito Internet ei linguaggi di programmazione orientati agli aspetti. e-mail: monga@elet.polimi.it