Modelli di processo

Il processo di sviluppo
Processo di sviluppo software = framework all'interno del quale si svolgono
le 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 di
un software, adottano necessariamente un certo approccio nel modo di
relazionarsi con i propri clienti / utenti, nell'organizzare il proprio lavoro, nella
scelta 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 ed
organizzativo in cui si trova ad operare.
La storia dei successi (e soprattutto degli insuccessi) dei progetti di sviluppo
software ha insegnato che ogni processo di sviluppo ha i propri pregi ed i propri
limiti. E che un processo di sviluppo inadeguato alla concrete esigenze dello
specifico progetto può condurre al fallimento del progetto stesso, o comunque
all'insoddisfazione dei clienti / utenti e degli stessi sviluppatori.
1
Il processo di sviluppo
A Common Process Framework
Common process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
2
Il processo di sviluppo
Un generico processo di sviluppo software è costituito da uno o più set di
Attività portanti (Framework Activities), cioè dalle attività necessarie per
garantire l'avanzamento del processo di produzione del software.
Le attività portanti rappresentano il fondamento del processo di sviluppo, in
quanto comprendono le attività direttamente legate alla realizzazione del
prodotto 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
3
Il processo di sviluppo
Alle attività portanti si affiancano le Attività ausiliarie (Umbrella Activities), che
rappresentano l'insieme di tutte le attività non direttamente collegate alle fasi
produttive, 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
4
Capability Maturity Model
Il Modello di Maturità delle Capacità (CMM - Capability Maturity Model) individua
un insieme di capacità corrispondenti al livello di maturità di processo di una
software house.
Misura esclusivemente la validità di processo, dunque non fornisce una
valutazione della validità tecnica e/o architetturale del prodotto dell'azienda.
Il CMM è stato elaborato dal Software Engineering Institute nel 1993, sulla base
del processo di sviluppo descritto nello standard Mil-Std-498, sviluppato negli
Stati 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 livelli
precedenti.
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 sviluppatori
KPA: nessuna!
5
Capability Maturity Model
2. Livello Ripetibile: nell'azienda esistono processi basilari per la gestione dei
progetti, al fine di tenere sotto controllo costi, tempi e soddisfacimento dei
requisiti.
Æ le metodologie usate in progetti di successo precedenti vengono ripetute
in progetti successivi.
KPA:
– Gestione
– Garanzia di qualità del sw
– Gestione dei sottocontratti (Outsourcing)
– Controllo e sorveglianza del progetto
– Pianificazione del progetto
– Gestione dei requisiti
6
Capability Maturity Model
3. Livello Definito: il processo è conforme ad uno standard aziendale definito,
stabile e documentato sia per quanto riguarda le attività portanti che per
quanto 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 valutati
quantitativamente e qualitativamente sulla base di misure dettagliate.
KPA:
– Gestione della qualità del software
– Gestione quantitativa del processo
7
Capability Maturity Model
5. Livello Ottimizzato: utilizzo di tecnologie e metodologie innovative al fine
di raggiungere un livello ottimo di gestione del processo software e sviluppo
del prodotto.
KPA:
– Gestione del cambiamento nel processo
– Gestione del cambiamento tenologico
– Prevenzione dei difetti
8
Modelli di processo
La strategia adottata da un’azienda per gestire il processo di sviluppo software
(comprendente metodologie, tecniche e strumenti) è denominata Modello di
Processo o Paradigma di Ingegneria del Software dell’azienda.
Qualunque modello di processo adotti un’azienda, esistono elementi comuni.
problem
definition
technical
development
status
quo
solution
integration
9
Modelli di processo
(L. Raccoon, “The chaos model end the chaos lifecycle”, ACM Software
Engineering Notes, vol.20 n.1, 1995)
Lo status quo dello sviluppo software viene modificato attraverso delle iterazioni
che prevedono:
• La definizione del problema
• Lo sviluppo tecnico
• L’integrazione della soluzione
Una iterazione produce un nuovo status quo che può essere modificato con
successive iterazioni.
Il ciclo di Raccoon è indipendente dal modello di processo e dalla tecnologia
adottata; le attività portanti ed accessorie descritte in precedenza si possono
facilmente 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 di
integrazione.
10
Modelli di processo
Possiamo osservare che il ciclo di Raccoon si applica a più livelli di dettaglio: a
livello dell’intera applicazione, a livello di progettazione dell’infrastruttura di
base, di progettazione di componenti, fino allo sviluppo di parti di codice.
Qualunque siano il modello di processo e le tecnologie adottate, le fasi di
definizione del problema, sviluppo tecnico e integrazione della soluzione
coesistono ad un certo livello di dettaglio.
Durante il cammino verso lo sviluppo di un’applicazione completa, le quattro fasi
si applicano ricorsivamente dalla raccolta dei requisiti utente fino ai più piccoli
dettagli implementativi.
Æ Il risultato è una visione frattale del processo di sviluppo software!
11
Modelli di processo – Il Modello Sequenziale Lineare
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)
System/information
engineering
analysis
design
code
test
12
Modelli di processo – Il Modello Sequenziale Lineare
Il progetto è organizzato in una sequenza di fasi, ciascuna delle quali produce
un output che costituisce l'input per la fase successiva.
All'inizio di ciascuna fase si verifica la qualità del lavoro effettuato nella fase
precedente, con possibilità di ricicli per modifica
Le fasi individuate da Royce prevedono:
• Strutturazione e modellazione del sistema e dei dati
Il modello sequenziale lineare prevede una fase iniziale di macro-analisi
durante la quale vengono esaminati tutti i requisiti e viene progettata
l’infrastruttura dell’applicazione e dei dati. Il processo viene raffinato nelle due
fasi successive di analisi e progettazione.
• Analisi dei requisiti
Prevede la definizione dettagliata (e relativa documentazione) di funzionalità,
prestazioni, interfacce del software.
13
Modelli di processo – Il Modello Sequenziale Lineare
• Progettazione
La fase di progettazione traduce i requisiti utente in una modellazione del
software, ossia in una documentazione che consenta di valutare la qualità del
software prime che inizi la codifica.
Si articola in modellazione di architettura, struttura dati, interfacce ed algoritmi
di elaborazione.
• Codifica
• Testing
Il modello sequenziale lineare si applica sia alla realizzazione iniziale di un
software, sia alla sua manutenzione, cioè alla revisione del software stesso al
fine di correggere errori o soddisfare le mutate esigenze del committente.
14
Modelli di processo – Il Modello Sequenziale Lineare
Diffusione del processo a cascata
E' probabilmente il processo di sviluppo software più diffuso al mondo, anche
perché segue il modello della catena di montaggio tipico della produzione
industriale della prima metà del novecento. Ma è considerato irrimediabilmente
obsoleto, ed è raro trovare esperti che lo raccomandino ancora. I settori
economici per i quali la qualità e produttività dei progetti di sviluppo software
sono più critici hanno da tempo abolito la pratica dello sviluppo a cascata, in
quanto troppo rischioso.
Vantaggi
9 E' molto semplice da capire, quasi intuitivo (anche per chi non ha mai
sviluppato software): prima si raccolgono tutti i requisiti, poi si fa tutta
l'analisi, poi tutto il design, poi tutta la codifica, ...
9 E' semplicissimo organizzare il piano di progetto (non che sia facile pianificare
le date di conclusione delle fasi, ma non ci sono dubbi sulla sequenza delle fasi
stesse).
9 Si adatta perfettamente a logiche organizzative e politiche del personale
basate su una divisione del lavoro accentuata.
15
Modelli di processo – Il Modello Sequenziale Lineare
Svantaggi
9 E' altamente rischioso. Le prime verifiche concrete, in termini di risultati visibili
e comprensibili da committenti e utenti, arrivano verso la fine del progetto, nel
periodo finale della fase di test. E se ci si accorge che qualcosa non funziona
(accade...), ossia che il sistema realizzato non corrisponde ai requisiti, impliciti
ed espliciti, i tempi ed i costi del progetto possono crescere in misura
notevole.
9 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 le
parti interessate nel merito delle soluzioni concrete, senza verificare
l'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 accordo
effettivo sul merito di problemi (e che non ci si renda conto della cosa fino
alla verifica finale)
16
Modelli di processo – Il Modello Sequenziale Lineare
- che si raggiunga la "paralisi dell'analisi", con il progetto che non riesce a
chiarire alcune aree di ambiguità e l'impossibilità per il committente e le
parti interessate di fornire i chiarimenti richiesti.
2. Che una volta ottenuto l'accordo sui requisiti (tipicamente, con la produzione
di 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 per
progetti di complessità media o elevata.
3. Che sia possibile definire i requisiti, e stimare tempi e costi del progetto, senza
possedere la competenza necessaria sugli aspetti tecnici ed implementativi.
Questo non è in sé un limite del processo di sviluppo a cascata, ma della sua
attuazione concreta in organizzazioni nelle quali esiste una forte divisione del
lavoro. In molte realtà, la definizione dei requisiti viene effettuata da persone,
nel ruolo di analisti, che non hanno le competenze tecniche necessarie allo
sviluppo software. Oppure che avevano, anni addietro, competenze tecniche,
ma basate sull'utilizzo di tecnologie diverse da quelle utilizzate nel progetto. E
che non sono quindi in grado, da sole, di produrre stime attendibili.
17
Modelli di processo – Il Modello Sequenziale Lineare
Possiamo quindi concludere che raramente un progetto reale si adatta allo
schema sequenziale.
Nota: Royce era consapevole dei limiti del modello a cascata, e il suo articolo
originale proponeva dei correttivi, che purtroppo hanno avuto una diffusione
assai limitata.
18
Modelli di processo – Il Modello Incrementale
Il Modello Incrementale è una derivazione del processo di sviluppo a cascata.
19
Modelli di processo – Il Modello Incrementale
(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 due
aspetti:
• 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 di
sottoprogetti realizzativi, ciascuno dei quali produrrà uno o più sottosistemi
(parti del sistema complessivo).
20
Modelli di processo – Il Modello Incrementale
I sottoprogetti realizzativi potranno essere condotti in sequenza rigida (uno dopo
l'altro), oppure essere condotti parzialmente in parallelo (con sovrapposizioni
temporali).
Diffusione del processo incrementale
Viene spesso utilizzato, in progetti di complessità medio-grande, come variante
di un processo a cascata, in quanto costituisce un modo di ridurne i rischi.
Vantaggi
9 Rispetto al processo a cascata, permette di arrivare a consegnare qualcosa di
concreto prima di aver completato l'intero sistema. In questo modo si
ottengono feedback (riscontri) concreti, con indicazioni utilizzabili anche nei
sottoprogetti realizzativi ancora in corso o successivi. E si riducono i rischi di
insuccesso.
9 L'articolazione del piano di progetto è più complessa (rispetto al processo di
sviluppo a cascata), ma permette una maggiore flessibilità nell'assegnazione
delle persone ai compiti progettuali, quando i sottoprogetti vengono pianificati
con una parziale sovrapposizione temporale.
21
Modelli di processo – Il Modello Incrementale
Svantaggi
Condivide 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 soluzioni
concrete
• i requisiti non cambino dopo che sono stati concordati
22
Modelli di processo – Il Modello Prototipale
Il principale limite del modello a cascata è che l’utente deve attendere fino al
termine della fase di sviluppo prima di poter valutare il prodotto.
Se il committente non è in grado di definire con sufficiente chiarezza i propri
requisiti, il modello a cascata si rivela inadeguato.
Il Modello Prototipale pone l’accento sul ruolo centrale del committente nella
definizione dell’applicazione, e pertanto agevola la definizione dei requisiti.
listen
to
customer
build/revise
mock-up
customer
test-drives
mock-up
23
Modelli di processo – Il Modello Prototipale
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 incentrata
sull’interfaccia utente.
• Una fase di realizzazione di un prototipo.
Il prototipo deve soddisfare i requisiti noti al momento dello sviluppo, ma per la
sua realizzazione non si è tenuti a rispettare alcune caratteristiche fondamentali
del software di qualità: es. prestazioni, qualità del codice, riusabilità,
manutenibilità.
Lo scopo del prototipo è solo quello permettere al committente di valutare
l’aderenza dell’applicazione alle proprie necessità.
Il feedback dell’utente relativamente al funzionamento del prototipo genera un
successivo ciclo durante il quale il prototipo viene raffinato.
24
Modelli di processo – Il Modello Prototipale
Una volta raggiunto l’accordo con il committente riguardo alla definizione delle
specifiche, è 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 successive
senza particolare attenzione alla sua architettura, la fase di ingegnerizzazione
prevede di gettare via il prototipo!
Vantaggi
9 Il committente vede crescere il prodotto, quindi è molto improbabile
consegnare un prodotto finale che non soddisfi il committente.
9 Lo sviluppatore è molto agevolato nella fase di negoziazione dei requisiti
9 I tempi di sviluppo sono molto rapidi (in apparenza!)
Svantaggi
9 La tentazione di considerare il prototipo come un prodotto è molto forte… sia
l’utente che lo sviluppatore tendono a farlo. Il risultato è che spesso si
rinuncia all’ingegnerizzazione del prodotto, e si consegna un’applicazione
funzionante, ma di scarsa qualità.
25
Modelli di processo – Il Modello Prototipale
9 Il committente ha per le mani in tempi rapidi un oggetto funzionante, che
soddisfa le sue esigenze, ed è portato a pensare che con pochi ritocchi sia
possibile trasformarlo in un prodotto realmente operativo.
Le difficoltà (ed i conseguenti costi) della fase di ingegnerizzazione sono
percepiti con difficoltà dal committente Æ si generano inevitabilmente dei
contrasti.
26
Modelli di processo – Il Modello a Spirale
Il Modello a Spirale prevede uno sviluppo del software in versioni crescenti.
Pla nning
Risk Analysis
Customer
Communic a tion
Engineering
Customer
Evaluation
Construc tion & Relea se
27
Modelli di processo – Il Modello a Spirale
(Barry Boehm, "A Spiral Model of Software Development and Enhancement", in
Computer, 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 il
progetto. Ogni ciclo (o iterazione) comporta l'effettuazione di una serie di
attività, 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 modello
sequenziale lineare:
• analisi dei requisiti
• progettazione
28
Modelli di processo – Il Modello a Spirale
• codifica
• test
Cioè le stesse attività che, in un processo di sviluppo a cascata, sono
considerate come delle fasi da svolgersi in sequenza rigida, una dopo l'altra. Nel
processo iterativo, in ogni iterazione (in ogni ciclo della spirale) vengono svolte
le medesime tipologie di attività.
L'articolazione di un progetto iterativo è guidata non da una rigida sequenza di
fasi predefinite, ma da una gestione sistematica dei rischi di progetto, per
arrivare alla loro progressiva diminuzione.
All'inizio di un progetto di sviluppo software, i rischi sono tipicamente molto
elevati. Manca la chiarezza sui requisiti, le scelte sulle tecnologie e sulla
strutturazione del sistema (le scelte architetturali) sono ipotesi non ancora
consolidate. In alcuni casi, sono state scelte tecnologie innovative, per le quali
manca però una sufficiente esperienza nel gruppo di progetto. In altri, anche a
fronte di tecnologie conosciute, esistono incertezze legate alla necessità di fare
fronte a un numero di utilizzatori contemporanei molto elevato, o a volumi di
dati mai gestiti in precedenza.
29
Modelli di processo – Il Modello a Spirale
Ogni iterazione, in un progetto iterativo, ha lo scopo di ridurre i rischi di
progetto.
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), per
affrontare i rischi legati alla scelta delle tecnologie ed i dubbi sulla strutturazione
del sistema.
Successivamente, quando i rischi principali sono stati messi sotto controllo, ogni
iterazione ha lo scopo di costruire, in modo progressivo, nuove porzioni del
sistema, via via integrate con le precedenti, e di verificarle con il committente e
le altre parti interessate. Sotto questo profilo, esiste più di un'affinità con il
processo di sviluppo incrementale; ma anche una differenza significativa. Un
processo iterativo, infatti, prevede il cambiamento di requisiti in corso d'opera.
Prevede, in particolare, la "nascita" di nuovi requisiti espressi dal committente e
dalle altre parti interessate al sistema come effetto dell'utilizzo del sistema
stesso (delle sue parti già rese disponibili agli utilizzatori).
30
Modelli di processo – Il Modello a Spirale
Vantaggi
9 Gestione sistematica dei rischi di progetto, attraverso iterazioni volte alla loro
progressiva riduzione.
9 Rispetto al processo di sviluppo a cascata, salvo eccezioni, maggiore qualità
dei prodotti, e maggiore produttività dei progetti (costi e tempi inferiori).
Svantaggi
9 La pianificazione dei progetti condotti in modo iterativo è più complessa, e
meno "banale". All'inizio del progetto è impossibile prevedere esattamente il
numero delle iterazioni, la durata di ogni singola iterazione, i suoi obiettivi
specifici. Il piano di un processo iterativo evolve durante tutta la durata del
progetto stesso, e richiede un controllo sistematico degli avanzamenti.
9 Un punto cruciale per il successo di un progetto iterativo è la collaborazione
sistematica tra committenti (e altre parti interessate) e gruppo di progetto. Da
un lato, il gruppo di progetto deve fornire in modo sistematico visibilità sugli
avanzamenti, in termini di prodotti concreti da valutare. Dall'altro, se i
committenti (e le altre parti interessate) non forniscono periodicamente
31
Modelli di processo – Il Modello a Spirale
riscontri concreti ai prototipi ed alle porzioni di sistema realizzate dal gruppo di
progetto, la progressiva riduzione dei rischi non ha luogo.
Il modello a spirale è una strategia realistica per lo sviluppo di sistemi software
di grandi dimensioni.
Quanto più il successo dei progetti software è critico per gli obiettivi di
un'organizzazione, tanto più è probabile che il processo di sviluppo adottato
abbia caratteristiche di natura iterativa.
I modelli iterativi sono particolarmente adatti allo svilupo di sistemi objectoriented.
32
Modelli di processo – Extreme Programming
I Processi Agili sono stati sviluppati a partire dalla seconda metà degli anni ’90.
Traggono origine dal Manifesto for Agile Software Development, che
recita:
"Stiamo scoprendo approcci migliori per sviluppare il software, praticandoli ed
aiutando altri a praticarli. Grazie a questo lavoro siamo arrivati a ritenere
importanti:
• 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 quelli
riportati 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.".
33
Modelli di processo – Extreme Programming
Nella loro maggioranza, i proponenti dei processi agili rigettano come burocratici
ed inefficaci gli approcci tradizionali dell'ingegneria del software.
Più interessante, però, è il fatto che molti degli autori più rilevanti del software
engineering "tradizionale" (ad esempio Barry Boehm, Tom De Marco, Grady
Booch) 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 osservare
che ciascuna di esse ha senso anche se applicata in modo autonomo,
eventualmente nel contesto di un diverso processo di sviluppo.
34
Modelli di processo – Extreme Programming
35
Modelli di processo – Extreme Programming
Whole Team
XP rifiuta la suddivisione dei compiti in ruoli rigidi, e vede ogni persona coinvolta
nel processo di sviluppo come parte integrante di una entità denominata “Whole
Team”.
Il committente fa parte del team e lavora fianco a fianco con gli sviluppatori per
l’intera durata del progetto. Il committente fornisce i requisiti e stabilisce le
priorità; definisce inoltre i test di accettazione del prodotto, coadiuvato dagli
analisti del team.
Normalmente il team prevede anche un “coach” che ha l’incarico di mantenere il
team focalizzato sull’obiettivo.
Planning Game
XP pone l’accento su come indirizzare il progetto verso l’obiettivo finale, man
mano che ci si avvicina ad esso, piuttosto che sulla definizione esatta
dell’obiettivo finale in fase di analisi del progetto. XP prevede due diversi tipi di
pianificazione:
Release Planning – fase nella quale il committente presenta al team i propri
requisiti, che vangono valutati in termini di costi e difficoltà di realizzazione; la
36
Modelli di processo – Extreme Programming
stima è necessariamente imprecisa. In questa fase il team realizza un
canovaccio di project plan, che sarà rivisto nelle fasi successive.
Iteration Planning – XP costruisce il codice mediante iterazioni di durata
prefissata: due settimane. L’obiettivo è produrre software funzionante (anche
se non completo) al termine di ogni iterazione.
Durante Iteration Planning, il committente presenta al team le features richieste
per le due settimane successive; il team le valuta in termini di costi e fattibilità e
definisce un piano per l’iterazione.
Gli obiettivi non pienamente soddisfatti al termine dell’iterazione non sono presi
in considerazione. In questo modo il committente vede crescere il prodotto ed è
in grado di controllare il progetto attraverso le varie iterazioni.
Customer Tests
Il committente, insieme ad ogni feature richiesta, deve obbligatoriamente
definire i test di accettazione. Il team costruisce delle procedure di test
automatici che devono essere eseguiti ad ogni iterazione.
37
Modelli di processo – Extreme Programming
Small Releases
Attraverso il meccanismo delle iterazioni, il team si pone l’obiettivo di realizzare
quanto più frequentemente possibile delle release parziali del prodotto da
consegnare agli utenti finali.
Simple Design
Attitudine a scegliere costantemente la soluzione "più semplice" ad un dato
problema, senza porsi il problema di anticipare i futuri cambiamenti. XP
propone 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 per
l’intera durata del progetto (in ogni iterazione e nelle fasi di realizzazione delle
Small Releases). Questa attività di costante revisione dell’architettura è
denominata Refactoring.
Pair Programming
In XP, tutta l’attività di stesura di codice è svolta da coppie di programmatori
che lavorano fianco a fianco sulla stessa macchina. Questa pratica fa sì che
38
Modelli di processo – Extreme Programming
tutto il codice sorgente sia costantemente monitorato e validato da almeno un
programmatore, con il risultato di produrre codice meglio progettato, più
efficiente, meno incline agli errori.
Può sembrare inefficiente avere due programmatori che fanno il lavoro di
unosolo, ma alcune ricerche specifiche provano che due programmatori che
lavorano in coppia producono gli stessi risultati (in termini di tempo e feature
soddisfatte) che produrrebbero lavorando singolarmente, ma realizzano codice
intrinsecamente migliore.
Il Pair Programming ha anche l’effetto di diffondere la conoscenza attraverso il
team, se le coppie cambiano durante lo sviluppo del progetto.
Test-driven Development
In XP il processo di sviluppo deve essere ossessivamente guidato dai test: i test
di feature devono essere realizzati (o quanto meno definiti) prima di sviluppare il
relativo codice, e devono essere eseguiti con esito positivo al 100% ogni volta
che un programmatore modifica una singola riga di codice sorgente.
XP incoraggia anche i programmatori stessi a definire dei test per il modulo
software da loro realizzato.
39
Modelli di processo – Extreme Programming
Continuous Integration
In un progetto XP l’integrazione dei vari moduli software che compongono la
soluzione è garantita dalla generazione continua di “build” (8-10 volte al giorno,
contro il ciclo di build settimanale adottato dalla maggior parte delle software
house). Inoltre, la costruzione del build è a carico del team, non di terze
persone meno coinvolte nel processo di sviluppo.
In questo modo, a fronte di un carico di lavoro notevole per gli sviluppatori del
team, si ha la garanzia che il prodotto sia costantemente funzionante e si
evitano gli errori (spesso molto subdoli) dovuti all’integrazione fra moduli.
Collective Code Ownership
Nei progetti XP, ogni coppia di programmatori può liberamente modificare
porzioni di codice scritte da altri: la proprietà del codice è dell’intero team, e non
esistono moduli di esclusiva pertinenza di alcune persone.
In questo modo l’intero codice riceve le attenzioni di più programmatori, e risulta
migliore e meno incline agli errori.
La Collective Code Ownership potrebbe rappresentare un problema se le
persone fossero costrette a lavorare alla cieca su codice che non conoscono.
40
Modelli di processo – Extreme Programming
XP evita questo problema mediante la pratica di Pair Programming e
l’esecuzione continua di test.
Coding Standard
XP incoraggia l’adozione di stili e standard di codifica comuni per tutti gli
sviluppatori, in modo che tutto il codice sembri scritto da una sola persona. In
questo modo ogni porzione di codice appare familiare a tutti gli sviluppatori.
Il codice sorgente deve essere quanto più possibile autoesplicativo; XP sconsiglia
l’utilizzo di documentazione interna di progetto.
Metaphor
I team XP sviluppano una visione comune del funzionamento generale del
sistema attraverso l’uso di metafore.
In termini meno poetici, XP promuove l’adozione di terminologia comune
all’intero team, univocamente compresa da tutti i suoi membri, in modo da
evitare incomprensioni.
41
Modelli di processo – Extreme Programming
Sustainable Pace
Attraverso questa pratica (detta anche “40-hour week”) XP promuove un livello
di sollecitazione e impegno sostenibile da tutti i membri del team per un periodo
di durata indefinita. Il ricorso a lavoro straordinario per far fronte a necessità
contingenti è sconsigliato, in quanto riduce la produttività del team nel lungo
periodo.
42
Modelli di processo – Extreme Programming
In sintesi, l’impostazione generale del processo XP è:
43
Modelli di processo – Extreme Programming
Diffusione di XP
Ancora limitata, almeno in Italia, ma in crescita.
Vantaggi
9 E' un processo molto efficiente, e in grado di fare fronte al cambiamento di
requisiti. Il sottotitolo del testo di Kent Beck è "Embrace Change": abbracciare
il cambiamento.
9 Fornisce risultati migliori, in termini di qualità del prodotto, rispetto a molti
progetti condotti con altri approcci, grazie alle pratiche sistematiche e
quotidiane di testing e di continuous integration.
9 Porta ad una assunzione di responsabilità collettiva da parte del gruppo di
lavoro, e favorisce la creazione di team coesi.
9 E' molto apprezzato da chi lo pratica.
Svantaggi
9 XP è inadatto a contesti progettuali in cui sia richiesta una tracciatura
sistematica dei requisiti.
44
Modelli di processo – Extreme Programming
9 L'adozione di XP (dell'insieme completo delle pratiche XP) richiede
trasformazioni profonde degli assetti organizzativi e delle politiche del
personale, in quanto modifica in modo sostanziale ruoli consolidati a livello
organizzativo. Può anche richiedere una trasformazione degli aspetti logistici,
in quanto richiede che il gruppo di lavoro (tipicamente costituito da circa una
decina di persone) operi in una singola locazione. E' molto più semplice
adottare XP per una software house (in particolare, per una software house
appena nata) che non per il settore sistemi di una grande organizzazione.
9 XP richiede che le persone siano capaci di lavorare in gruppo: non tutti sono in
grado di farlo.
9 Richiede inoltre l'utilizzo di strumenti di sviluppo evoluti, per programmare,
testare, ristrutturare il codice in modo realmente produttivo.
45