Il processo di sviluppo

1

Processo di sviluppo software = framework all'interno del quale si svolgonole attività necessarie per produrre software di alta qualità.

E' il modo in cui viene organizzato e praticato lo sviluppo dei sistemi software.Coloro che, individualmente o in gruppo, lavorano allo sviluppo o alla modifica diun software, adottano necessariamente un certo approccio nel modo direlazionarsi con i propri clienti / utenti, nell'organizzare il proprio lavoro, nellascelta delle tecniche da utilizzare. Adottano un processo.In modo consapevole o meno, ogni sviluppatore (o gruppo di sviluppatori)software ha un proprio processo di sviluppo - un proprio modo di lavorare.Basato sulla propria esperienza, sulla propria cultura, e sul contesto culturale edorganizzativo in cui si trova ad operare.La storia dei successi (e soprattutto degli insuccessi) dei progetti di svilupposoftware ha insegnato che ogni processo di sviluppo ha i propri pregi ed i proprilimiti. E che un processo di sviluppo inadeguato alla concrete esigenze dellospecifico progetto può condurre al fallimento del progetto stesso, o comunqueall'insoddisfazione dei clienti / utenti e degli stessi sviluppatori.

Il processo di sviluppo

2

AA CCoommmmoonn PPrroocceessss FFrraammeewwoorrkk

CCoommmmoonn pprroocceessss ffrraammeewwoorrkkFFrraammeewwoorrkk aaccttiivviittiieess

wwoorrkk ttaasskksswwoorrkk pprroodduuccttssmmiilleessttoonneess && ddeelliivveerraabblleessQQAA cchheecckkppooiinnttss

UUmmbbrreellllaa AAccttiivviittiieess

Il processo di sviluppo

3

Un generico processo di sviluppo software è costituito da uno o più set diAttività portanti (Framework Activities), cioè dalle attività necessarie pergarantire l'avanzamento del processo di produzione del software.

Le attività portanti rappresentano il fondamento del processo di sviluppo, inquanto comprendono le attività direttamente legate alla realizzazione delprodotto software.Fra queste possiamo citare:

la suddivisione del prodotto in moduli la codifica il controllo di avanzamento la verifica del livello qualitativo del software il bug fixing

Il processo di sviluppo

4

Alle attività portanti si affiancano le Attività ausiliarie (Umbrella Activities), cherappresentano l'insieme di tutte le attività non direttamente collegate alle fasiproduttive, ma che concorrono con esse al raggiungimento dell'obiettivo.

Software project management Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management

Capability Maturity Model

5

Il Modello di Maturità delle Capacità (CMM - Capability Maturity Model) individuaun insieme di capacità corrispondenti al livello di maturità di processo di unasoftware house.Misura esclusivemente la validità di processo, dunque non fornisce unavalutazione della validità tecnica e/o architetturale del prodotto dell'azienda.Il CMM è stato elaborato dal Software Engineering Institute nel 1993, sulla basedel processo di sviluppo descritto nello standard Mil-Std-498, sviluppato negliStati Uniti in ambito militare..

Il CMM prevede 5 livelli di valutazione, ad ognuno dei quali sono associate piùKey Process Areas (KPA); ogni livello comprende tutte le caratteristiche dei livelliprecedenti.

1. Livello Iniziale: il processo di svluppo è definito di volta in volta risulta confuso, spesso non è nemmeno definito la riuscita del progetto

dipende dalle capacità individuali degli sviluppatoriKPA: nessuna!

Capability Maturity Model

6

2. Livello Ripetibile: nell'azienda esistono processi basilari per la gestione deiprogetti, al fine di tenere sotto controllo costi, tempi e soddisfacimento deirequisiti.

le metodologie usate in progetti di successo precedenti vengono ripetutein progetti successivi.KPA:– Gestione– Garanzia di qualità del sw– Gestione dei sottocontratti (Outsourcing)– Controllo e sorveglianza del progetto– Pianificazione del progetto– Gestione dei requisiti

Capability Maturity Model

7

3. Livello Definito: il processo è conforme ad uno standard aziendale definito,stabile e documentato sia per quanto riguarda le attività portanti che perquanto riguarda le attività ausiliarie.KPA:– Revisioni– Coordinamento dei gruppi– Ingegneria del prodotto sw– Gestione integrata del sw– Programmi di addestramento– Definizione del processo azindale– Obiettivo primario del processo aziendale

4. Livello Gestito: sia il prodotto sia il processo software sono valutatiquantitativamente e qualitativamente sulla base di misure dettagliate.KPA:– Gestione della qualità del software– Gestione quantitativa del processo

Capability Maturity Model

8

5. Livello Ottimizzato: utilizzo di tecnologie e metodologie innovative al finedi raggiungere un livello ottimo di gestione del processo software e sviluppodel prodotto.KPA:– Gestione del cambiamento nel processo– Gestione del cambiamento tenologico– Prevenzione dei difetti

Modelli di processo

9

La strategia adottata da un’azienda per gestire il processo di sviluppo software(comprendente metodologie, tecniche e strumenti) è denominata Modello diProcesso o Paradigma di Ingegneria del Software dell’azienda.

Qualunque modello di processo adotti un’azienda, esistono elementi comuni.

statusquo

problemdefinition

technicaldevelopment

solutionintegration

Modelli di processo

10

(L. Raccoon, “The chaos model end the chaos lifecycle”, ACM SoftwareEngineering Notes, vol.20 n.1, 1995)

Lo status quo dello sviluppo software viene modificato attraverso delle iterazioniche prevedono:• La definizione del problema• Lo sviluppo tecnico• L’integrazione della soluzioneUna iterazione produce un nuovo status quo che può essere modificato consuccessive iterazioni.

Il ciclo di Raccoon è indipendente dal modello di processo e dalla tecnologiaadottata; le attività portanti ed accessorie descritte in precedenza si possonofacilmente ascrivere ad una delle fasi.Ad esempio, codifica e bug fixing appartengono alla fase di sviluppo tecnico,mentre la redazione di documentazione di progetto appartiene alla fase diintegrazione.

Modelli di processo

11

Possiamo osservare che il ciclo di Raccoon si applica a più livelli di dettaglio: alivello dell’intera applicazione, a livello di progettazione dell’infrastruttura dibase, di progettazione di componenti, fino allo sviluppo di parti di codice.

Qualunque siano il modello di processo e le tecnologie adottate, le fasi didefinizione del problema, sviluppo tecnico e integrazione della soluzionecoesistono ad un certo livello di dettaglio.

Durante il cammino verso lo sviluppo di un’applicazione completa, le quattro fasisi applicano ricorsivamente dalla raccolta dei requisiti utente fino ai più piccolidettagli implementativi.

Il risultato è una visione frattale del processo di sviluppo software!

Modelli di processo – Il Modello Sequenziale Lineare

12

Il Modello Sequenziale Lineare trae origine dal Modello a Cascata,originariamente proposto da Royce nel 1970.

(W.Royce, "Managing the Development of Large Software Systems",Proceedings of IEEE Wescon, 1970)

analysis design code test

System/informationengineering

Modelli di processo – Il Modello Sequenziale Lineare

13

Il progetto è organizzato in una sequenza di fasi, ciascuna delle quali produceun output che costituisce l'input per la fase successiva.All'inizio di ciascuna fase si verifica la qualità del lavoro effettuato nella faseprecedente, con possibilità di ricicli per modifica

Le fasi individuate da Royce prevedono:

• Strutturazione e modellazione del sistema e dei datiIl modello sequenziale lineare prevede una fase iniziale di macro-analisidurante la quale vengono esaminati tutti i requisiti e viene progettatal’infrastruttura dell’applicazione e dei dati. Il processo viene raffinato nelle duefasi successive di analisi e progettazione.

• Analisi dei requisitiPrevede la definizione dettagliata (e relativa documentazione) di funzionalità,prestazioni, interfacce del software.

Modelli di processo – Il Modello Sequenziale Lineare

14

• ProgettazioneLa fase di progettazione traduce i requisiti utente in una modellazione delsoftware, ossia in una documentazione che consenta di valutare la qualità delsoftware prime che inizi la codifica.Si articola in modellazione di architettura, struttura dati, interfacce ed algoritmidi elaborazione.

• Codifica

• Testing

Il modello sequenziale lineare si applica sia alla realizzazione iniziale di unsoftware, sia alla sua manutenzione, cioè alla revisione del software stesso alfine di correggere errori o soddisfare le mutate esigenze del committente.

Modelli di processo – Il Modello Sequenziale Lineare

15

Diffusione del processo a cascataE' probabilmente il processo di sviluppo software più diffuso al mondo, ancheperché segue il modello della catena di montaggio tipico della produzioneindustriale della prima metà del novecento. Ma è considerato irrimediabilmenteobsoleto, ed è raro trovare esperti che lo raccomandino ancora. I settorieconomici per i quali la qualità e produttività dei progetti di sviluppo softwaresono più critici hanno da tempo abolito la pratica dello sviluppo a cascata, inquanto troppo rischioso.

Vantaggi E' molto semplice da capire, quasi intuitivo (anche per chi non ha maisviluppato software): prima si raccolgono tutti i requisiti, poi si fa tuttal'analisi, poi tutto il design, poi tutta la codifica, ... E' semplicissimo organizzare il piano di progetto (non che sia facile pianificarele date di conclusione delle fasi, ma non ci sono dubbi sulla sequenza delle fasistesse). Si adatta perfettamente a logiche organizzative e politiche del personalebasate su una divisione del lavoro accentuata.

Modelli di processo – Il Modello Sequenziale Lineare

16

Svantaggi E' altamente rischioso. Le prime verifiche concrete, in termini di risultati visibilie comprensibili da committenti e utenti, arrivano verso la fine del progetto, nelperiodo finale della fase di test. E se ci si accorge che qualcosa non funziona(accade...), ossia che il sistema realizzato non corrisponde ai requisiti, implicitied espliciti, i tempi ed i costi del progetto possono crescere in misuranotevole. Si basa su alcune assunzioni, il più delle volte sbagliate:1. Che sia possibile, nella fase iniziale del progetto, chiarire tutti i requisiti del

sistema. E che sia possibile farlo senza discutere con il committente e leparti interessate nel merito delle soluzioni concrete, senza verificarel'accordo con la presentazione di prototipi utilizzabili.Questa assunzione sbagliata può provocare due effetti:

- che si raggiunga un accordo sulla carta, ma che non ci sia un accordoeffettivo sul merito di problemi (e che non ci si renda conto della cosa finoalla verifica finale)

Modelli di processo – Il Modello Sequenziale Lineare

17

- che si raggiunga la "paralisi dell'analisi", con il progetto che non riesce achiarire alcune aree di ambiguità e l'impossibilità per il committente e leparti interessate di fornire i chiarimenti richiesti.

2. Che una volta ottenuto l'accordo sui requisiti (tipicamente, con la produzionedi alcuni documenti testuali che specificano, in termini astratti, le funzionalitàdel sistema), i requisiti stessi non cambino più fino alla fine del progetto. Puòessere vero, per progetti molto, molto brevi. Ma non è certamente vero perprogetti di complessità media o elevata.

3. Che sia possibile definire i requisiti, e stimare tempi e costi del progetto, senzapossedere la competenza necessaria sugli aspetti tecnici ed implementativi.Questo non è in sé un limite del processo di sviluppo a cascata, ma della suaattuazione concreta in organizzazioni nelle quali esiste una forte divisione dellavoro. In molte realtà, la definizione dei requisiti viene effettuata da persone,nel ruolo di analisti, che non hanno le competenze tecniche necessarie allosviluppo software. Oppure che avevano, anni addietro, competenze tecniche,ma basate sull'utilizzo di tecnologie diverse da quelle utilizzate nel progetto. Eche non sono quindi in grado, da sole, di produrre stime attendibili.

Modelli di processo – Il Modello Sequenziale Lineare

18

Possiamo quindi concludere che raramente un progetto reale si adatta alloschema sequenziale.

Nota: Royce era consapevole dei limiti del modello a cascata, e il suo articolooriginale proponeva dei correttivi, che purtroppo hanno avuto una diffusioneassai limitata.

Modelli di processo – Il Modello Incrementale

19

Il Modello Incrementale è una derivazione del processo di sviluppo a cascata.

Modelli di processo – Il Modello Incrementale

20

(B. Boehm, “Software Engineering Economics”, Prentice-Hall 1981)

Il modello incrementale prevede che, una volta completata la fase di analisi,venga effettuata una attività di design dell'architettura del sistema. Vengono, cioè, effettuate le scelte "di alto livello" relative a:• strutturazione del sistema in macroparti distinte (sottosistemi)• responsabilità di ciascun sottosistema• modalità di dialogo tra i diversi sottosistemi (interfacce).

A questo punto vengono definite delle priorità di realizzazione, sulla base di dueaspetti:• priorità di natura funzionale (relativa alle esigenze dei committenti e delle

parti interessate) • priorità di natura architetturale (se un sottosistema A necessita del

sottosistema B per funzionare, B ha una priorità superiore) Sulla base delle priorità definite, il progetto viene articolato in una serie disottoprogetti realizzativi, ciascuno dei quali produrrà uno o più sottosistemi(parti del sistema complessivo).

Modelli di processo – Il Modello Incrementale

21

I sottoprogetti realizzativi potranno essere condotti in sequenza rigida (uno dopol'altro), oppure essere condotti parzialmente in parallelo (con sovrapposizionitemporali).

Diffusione del processo incrementaleViene spesso utilizzato, in progetti di complessità medio-grande, come variantedi un processo a cascata, in quanto costituisce un modo di ridurne i rischi.

Vantaggi Rispetto al processo a cascata, permette di arrivare a consegnare qualcosa diconcreto prima di aver completato l'intero sistema. In questo modo siottengono feedback (riscontri) concreti, con indicazioni utilizzabili anche neisottoprogetti realizzativi ancora in corso o successivi. E si riducono i rischi diinsuccesso. L'articolazione del piano di progetto è più complessa (rispetto al processo disviluppo a cascata), ma permette una maggiore flessibilità nell'assegnazionedelle persone ai compiti progettuali, quando i sottoprogetti vengono pianificaticon una parziale sovrapposizione temporale.

Modelli di processo – Il Modello Incrementale

22

SvantaggiCondivide con il processo a cascata le due assunzioni - erronee - che:• sia possibile definire tutti i requisiti alla partenza del progetto, senza entrare

con i committenti e le altre parti interessate nel merito delle soluzioniconcrete

• i requisiti non cambino dopo che sono stati concordati

Modelli di processo – Il Modello Prototipale

23

Il principale limite del modello a cascata è che l’utente deve attendere fino altermine della fase di sviluppo prima di poter valutare il prodotto.Se il committente non è in grado di definire con sufficiente chiarezza i proprirequisiti, il modello a cascata si rivela inadeguato.

Il Modello Prototipale pone l’accento sul ruolo centrale del committente nelladefinizione dell’applicazione, e pertanto agevola la definizione dei requisiti.

listento

customerbuild/revise

mock-up

customertest-drivesmock-up

Modelli di processo – Il Modello Prototipale

24

Il modello prototipale prevede:

• Una prima fase di raccolta dei requisiti analoga a quella del modello a cascata,ma più rapida ed informale, volta a definire dei requisiti di massima.

• Una fase di progettazione del prototipo, sulla base dei requisiti (incompleti)raccolti nella fase precedente. La progettazione è in genere incentratasull’interfaccia utente.

• Una fase di realizzazione di un prototipo.

Il prototipo deve soddisfare i requisiti noti al momento dello sviluppo, ma per lasua realizzazione non si è tenuti a rispettare alcune caratteristiche fondamentalidel software di qualità: es. prestazioni, qualità del codice, riusabilità,manutenibilità.Lo scopo del prototipo è solo quello permettere al committente di valutarel’aderenza dell’applicazione alle proprie necessità.Il feedback dell’utente relativamente al funzionamento del prototipo genera unsuccessivo ciclo durante il quale il prototipo viene raffinato.

Modelli di processo – Il Modello Prototipale

25

Una volta raggiunto l’accordo con il committente riguardo alla definizione dellespecifiche, è necessario passare ad una fase di ingegnerizzazione del prodotto,al fine di poter consegnare un prodotto di qualità.Dal momento che il prototipo è stato realizzato per approssimazioni successivesenza particolare attenzione alla sua architettura, la fase di ingegnerizzazioneprevede di gettare via il prototipo!

Vantaggi Il committente vede crescere il prodotto, quindi è molto improbabileconsegnare un prodotto finale che non soddisfi il committente. Lo sviluppatore è molto agevolato nella fase di negoziazione dei requisiti I tempi di sviluppo sono molto rapidi (in apparenza!)

Svantaggi La tentazione di considerare il prototipo come un prodotto è molto forte… sial’utente che lo sviluppatore tendono a farlo. Il risultato è che spesso sirinuncia all’ingegnerizzazione del prodotto, e si consegna un’applicazionefunzionante, ma di scarsa qualità.

Modelli di processo – Il Modello Prototipale

26

Il committente ha per le mani in tempi rapidi un oggetto funzionante, chesoddisfa le sue esigenze, ed è portato a pensare che con pochi ritocchi siapossibile trasformarlo in un prodotto realmente operativo.Le difficoltà (ed i conseguenti costi) della fase di ingegnerizzazione sonopercepiti con difficoltà dal committente si generano inevitabilmente deicontrasti.

Modelli di processo – Il Modello a Spirale

27

Il Modello a Spirale prevede uno sviluppo del software in versioni crescenti.

CustomerCommunication

Planning

Construc tion & ReleaseCustomerEvaluation

Engineering

Risk Analysis

Modelli di processo – Il Modello a Spirale

28

(Barry Boehm, "A Spiral Model of Software Development and Enhancement", inComputer, vol.21 n.5, 1988)

Il modello a spirale è il più diffuso modello di sviluppo di tipo Iterativo.La spirale parte dal centro, con un insieme di obiettivi e requisiti iniziali per ilprogetto. Ogni ciclo (o iterazione) comporta l'effettuazione di una serie diattività, dette task regions:• Comunicazione con il cliente• Pianificazione• Analisi dei rischi• Progettazione• Costruzione e rilascio• Valutazione da parte del cliente Le task regions, nel loro insieme, comprendono le fasi tradizionali del modellosequenziale lineare:• analisi dei requisiti• progettazione

Modelli di processo – Il Modello a Spirale

29

• codifica • test

Cioè le stesse attività che, in un processo di sviluppo a cascata, sonoconsiderate come delle fasi da svolgersi in sequenza rigida, una dopo l'altra. Nelprocesso iterativo, in ogni iterazione (in ogni ciclo della spirale) vengono svoltele medesime tipologie di attività. L'articolazione di un progetto iterativo è guidata non da una rigida sequenza difasi predefinite, ma da una gestione sistematica dei rischi di progetto, perarrivare alla loro progressiva diminuzione. All'inizio di un progetto di sviluppo software, i rischi sono tipicamente moltoelevati. Manca la chiarezza sui requisiti, le scelte sulle tecnologie e sullastrutturazione del sistema (le scelte architetturali) sono ipotesi non ancoraconsolidate. In alcuni casi, sono state scelte tecnologie innovative, per le qualimanca però una sufficiente esperienza nel gruppo di progetto. In altri, anche afronte di tecnologie conosciute, esistono incertezze legate alla necessità di farefronte a un numero di utilizzatori contemporanei molto elevato, o a volumi didati mai gestiti in precedenza.

Modelli di processo – Il Modello a Spirale

30

Ogni iterazione, in un progetto iterativo, ha lo scopo di ridurre i rischi diprogetto. Inizialmente, tramite la costruzione di prototipi. Prototipi di interazione(interfacce utente), per affrontare i rischi legati all'incertezza sui requisiti.Prototipi architetturali (realizzazione e test di aspetti infrastrutturali), peraffrontare i rischi legati alla scelta delle tecnologie ed i dubbi sulla strutturazionedel sistema.Successivamente, quando i rischi principali sono stati messi sotto controllo, ogniiterazione ha lo scopo di costruire, in modo progressivo, nuove porzioni delsistema, via via integrate con le precedenti, e di verificarle con il committente ele altre parti interessate. Sotto questo profilo, esiste più di un'affinità con ilprocesso di sviluppo incrementale; ma anche una differenza significativa. Unprocesso iterativo, infatti, prevede il cambiamento di requisiti in corso d'opera.Prevede, in particolare, la "nascita" di nuovi requisiti espressi dal committente edalle altre parti interessate al sistema come effetto dell'utilizzo del sistemastesso (delle sue parti già rese disponibili agli utilizzatori).

Modelli di processo – Il Modello a Spirale

31

Vantaggi Gestione sistematica dei rischi di progetto, attraverso iterazioni volte alla loroprogressiva riduzione. Rispetto al processo di sviluppo a cascata, salvo eccezioni, maggiore qualitàdei prodotti, e maggiore produttività dei progetti (costi e tempi inferiori).

Svantaggi La pianificazione dei progetti condotti in modo iterativo è più complessa, emeno "banale". All'inizio del progetto è impossibile prevedere esattamente ilnumero delle iterazioni, la durata di ogni singola iterazione, i suoi obiettivispecifici. Il piano di un processo iterativo evolve durante tutta la durata delprogetto stesso, e richiede un controllo sistematico degli avanzamenti. Un punto cruciale per il successo di un progetto iterativo è la collaborazionesistematica tra committenti (e altre parti interessate) e gruppo di progetto. Daun lato, il gruppo di progetto deve fornire in modo sistematico visibilità sugliavanzamenti, in termini di prodotti concreti da valutare. Dall'altro, se icommittenti (e le altre parti interessate) non forniscono periodicamente

Modelli di processo – Il Modello a Spirale

32

riscontri concreti ai prototipi ed alle porzioni di sistema realizzate dal gruppo diprogetto, la progressiva riduzione dei rischi non ha luogo.

Il modello a spirale è una strategia realistica per lo sviluppo di sistemi softwaredi grandi dimensioni. Quanto più il successo dei progetti software è critico per gli obiettivi diun'organizzazione, tanto più è probabile che il processo di sviluppo adottatoabbia caratteristiche di natura iterativa.I modelli iterativi sono particolarmente adatti allo svilupo di sistemi object-oriented.

Modelli di processo – Extreme Programming

33

I Processi Agili sono stati sviluppati a partire dalla seconda metà degli anni ’90.Traggono origine dal Manifesto for Agile Software Development, cherecita:

"Stiamo scoprendo approcci migliori per sviluppare il software, praticandoli edaiutando altri a praticarli. Grazie a questo lavoro siamo arrivati a ritenereimportanti:• Gli individui e le loro interazioni, più che i processi e gli strumenti • Il software funzionante, più che una documentazione onnicomprensiva • La collaborazione con il cliente, più che la negoziazione dei contratti • Il rispondere ai cambiamenti, più che seguire un piano

Cioè, mentre i concetti riportati a destra sono importanti, riteniamo che quelliriportati a sinistra siano più importanti.”

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries,Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. © 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.".

Modelli di processo – Extreme Programming

34

Nella loro maggioranza, i proponenti dei processi agili rigettano come burocraticied inefficaci gli approcci tradizionali dell'ingegneria del software. Più interessante, però, è il fatto che molti degli autori più rilevanti del softwareengineering "tradizionale" (ad esempio Barry Boehm, Tom De Marco, GradyBooch) guardano ai processi agili come un fenomeno positivo.

Tra i processi agili, il più diffuso è Extreme Programming (XP).

(Kent Beck, ”Extreme Programming Explained”, Addison-Wesley 2000)

XP è una disciplina di sviluppo software basata su valori di semplicità,comunicazione e feedback continuo.

XP si basa su una serie di pratiche (Practices).Le pratiche si integrano tra loro nel contesto di XP, ma è opportuno osservareche ciascuna di esse ha senso anche se applicata in modo autonomo,eventualmente nel contesto di un diverso processo di sviluppo.

Modelli di processo – Extreme Programming

35

Modelli di processo – Extreme Programming

36

Whole TeamXP rifiuta la suddivisione dei compiti in ruoli rigidi, e vede ogni persona coinvoltanel processo di sviluppo come parte integrante di una entità denominata “WholeTeam”. Il committente fa parte del team e lavora fianco a fianco con gli sviluppatori perl’intera durata del progetto. Il committente fornisce i requisiti e stabilisce lepriorità; definisce inoltre i test di accettazione del prodotto, coadiuvato daglianalisti del team.Normalmente il team prevede anche un “coach” che ha l’incarico di mantenere ilteam focalizzato sull’obiettivo.

Planning GameXP pone l’accento su come indirizzare il progetto verso l’obiettivo finale, manmano che ci si avvicina ad esso, piuttosto che sulla definizione esattadell’obiettivo finale in fase di analisi del progetto. XP prevede due diversi tipi dipianificazione:Release Planning – fase nella quale il committente presenta al team i proprirequisiti, che vangono valutati in termini di costi e difficoltà di realizzazione; la

Modelli di processo – Extreme Programming

37

stima è necessariamente imprecisa. In questa fase il team realizza uncanovaccio di project plan, che sarà rivisto nelle fasi successive.Iteration Planning – XP costruisce il codice mediante iterazioni di durataprefissata: due settimane. L’obiettivo è produrre software funzionante (anchese non completo) al termine di ogni iterazione.Durante Iteration Planning, il committente presenta al team le features richiesteper le due settimane successive; il team le valuta in termini di costi e fattibilità edefinisce un piano per l’iterazione.Gli obiettivi non pienamente soddisfatti al termine dell’iterazione non sono presiin considerazione. In questo modo il committente vede crescere il prodotto ed èin grado di controllare il progetto attraverso le varie iterazioni.

Customer TestsIl committente, insieme ad ogni feature richiesta, deve obbligatoriamentedefinire i test di accettazione. Il team costruisce delle procedure di testautomatici che devono essere eseguiti ad ogni iterazione.

Modelli di processo – Extreme Programming

38

Small ReleasesAttraverso il meccanismo delle iterazioni, il team si pone l’obiettivo di realizzarequanto più frequentemente possibile delle release parziali del prodotto daconsegnare agli utenti finali.

Simple DesignAttitudine a scegliere costantemente la soluzione "più semplice" ad un datoproblema, senza porsi il problema di anticipare i futuri cambiamenti. XPpropone di mantenere il design della soluzione sempre adatto alle funzionalitàcorrenti del sistema. Questo è possibile perché anche l’architettura del sistema èconsiderata in costante evoluzione, attraverso degli incontri mirati previsti perl’intera durata del progetto (in ogni iterazione e nelle fasi di realizzazione delleSmall Releases). Questa attività di costante revisione dell’architettura èdenominata Refactoring.

Pair ProgrammingIn XP, tutta l’attività di stesura di codice è svolta da coppie di programmatoriche lavorano fianco a fianco sulla stessa macchina. Questa pratica fa sì che

Modelli di processo – Extreme Programming

39

tutto il codice sorgente sia costantemente monitorato e validato da almeno unprogrammatore, con il risultato di produrre codice meglio progettato, piùefficiente, meno incline agli errori.Può sembrare inefficiente avere due programmatori che fanno il lavoro diunosolo, ma alcune ricerche specifiche provano che due programmatori chelavorano in coppia producono gli stessi risultati (in termini di tempo e featuresoddisfatte) che produrrebbero lavorando singolarmente, ma realizzano codiceintrinsecamente migliore.Il Pair Programming ha anche l’effetto di diffondere la conoscenza attraverso ilteam, se le coppie cambiano durante lo sviluppo del progetto.

Test-driven DevelopmentIn XP il processo di sviluppo deve essere ossessivamente guidato dai test: i testdi feature devono essere realizzati (o quanto meno definiti) prima di sviluppare ilrelativo codice, e devono essere eseguiti con esito positivo al 100% ogni voltache un programmatore modifica una singola riga di codice sorgente.XP incoraggia anche i programmatori stessi a definire dei test per il modulosoftware da loro realizzato.

Modelli di processo – Extreme Programming

40

Continuous IntegrationIn un progetto XP l’integrazione dei vari moduli software che compongono lasoluzione è garantita dalla generazione continua di “build” (8-10 volte al giorno,contro il ciclo di build settimanale adottato dalla maggior parte delle softwarehouse). Inoltre, la costruzione del build è a carico del team, non di terzepersone meno coinvolte nel processo di sviluppo. In questo modo, a fronte di un carico di lavoro notevole per gli sviluppatori delteam, si ha la garanzia che il prodotto sia costantemente funzionante e sievitano gli errori (spesso molto subdoli) dovuti all’integrazione fra moduli.

Collective Code OwnershipNei progetti XP, ogni coppia di programmatori può liberamente modificareporzioni di codice scritte da altri: la proprietà del codice è dell’intero team, e nonesistono moduli di esclusiva pertinenza di alcune persone.In questo modo l’intero codice riceve le attenzioni di più programmatori, e risultamigliore e meno incline agli errori.La Collective Code Ownership potrebbe rappresentare un problema se lepersone fossero costrette a lavorare alla cieca su codice che non conoscono.

Modelli di processo – Extreme Programming

41

XP evita questo problema mediante la pratica di Pair Programming el’esecuzione continua di test.

Coding StandardXP incoraggia l’adozione di stili e standard di codifica comuni per tutti glisviluppatori, in modo che tutto il codice sembri scritto da una sola persona. Inquesto modo ogni porzione di codice appare familiare a tutti gli sviluppatori.Il codice sorgente deve essere quanto più possibile autoesplicativo; XP sconsiglial’utilizzo di documentazione interna di progetto.

MetaphorI team XP sviluppano una visione comune del funzionamento generale delsistema attraverso l’uso di metafore.In termini meno poetici, XP promuove l’adozione di terminologia comuneall’intero team, univocamente compresa da tutti i suoi membri, in modo daevitare incomprensioni.

Modelli di processo – Extreme Programming

42

Sustainable PaceAttraverso questa pratica (detta anche “40-hour week”) XP promuove un livellodi sollecitazione e impegno sostenibile da tutti i membri del team per un periododi durata indefinita. Il ricorso a lavoro straordinario per far fronte a necessitàcontingenti è sconsigliato, in quanto riduce la produttività del team nel lungoperiodo.

Modelli di processo – Extreme Programming

43

In sintesi, l’impostazione generale del processo XP è:

Modelli di processo – Extreme Programming

44

Diffusione di XPAncora limitata, almeno in Italia, ma in crescita.

Vantaggi E' un processo molto efficiente, e in grado di fare fronte al cambiamento direquisiti. Il sottotitolo del testo di Kent Beck è "Embrace Change": abbracciareil cambiamento. Fornisce risultati migliori, in termini di qualità del prodotto, rispetto a moltiprogetti condotti con altri approcci, grazie alle pratiche sistematiche equotidiane di testing e di continuous integration. Porta ad una assunzione di responsabilità collettiva da parte del gruppo dilavoro, e favorisce la creazione di team coesi. E' molto apprezzato da chi lo pratica.

Svantaggi XP è inadatto a contesti progettuali in cui sia richiesta una tracciaturasistematica dei requisiti.

Modelli di processo – Extreme Programming

45

L'adozione di XP (dell'insieme completo delle pratiche XP) richiedetrasformazioni profonde degli assetti organizzativi e delle politiche delpersonale, in quanto modifica in modo sostanziale ruoli consolidati a livelloorganizzativo. Può anche richiedere una trasformazione degli aspetti logistici,in quanto richiede che il gruppo di lavoro (tipicamente costituito da circa unadecina di persone) operi in una singola locazione. E' molto più sempliceadottare XP per una software house (in particolare, per una software houseappena nata) che non per il settore sistemi di una grande organizzazione. XP richiede che le persone siano capaci di lavorare in gruppo: non tutti sono ingrado di farlo. Richiede inoltre l'utilizzo di strumenti di sviluppo evoluti, per programmare,testare, ristrutturare il codice in modo realmente produttivo.