Argomenti
Rational Unified Process (RUP) è un framework di processi che Rational Software ha rifinito negli anni e che è ha
trovato vasto impiego in tutti i tipi di progetti software, piccoli o grandi che siano. Di recente, un numero crescente
di processi "agili", quali eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) e Crystal Clear
Methodology, sono riconosciuti sempre più come metodi efficaci per la progettazione di sistemi di dimensioni ridotte.
(Per ulteriori informazioni su Agile Alliance, vedere www.agilealliance.org).
Le sezioni successive sono destinate ad assistere i team di progetto nel valutare alcune delle pratiche "agili"
individuabili in uno di detti metodi per determinare come gli stessi sono risolti in maniera più completa dal processo
di sviluppo software definito da RUP (per ulteriori informazioni su RUP, vedere Introduzione a RUP).
La comunità agile ha sintetizzato un numero di "pratiche migliori" applicabili specialmente a team di progetto piccoli
colocalizzati. Sebbene RUP sia concepito per team di progetto di qualsiasi dimensione, può essere applicato con
successo anche a progetti piccoli. In genere, RUP e i processi della comunità Agile hanno una visione simile delle
pratiche migliori chiave necessarie per sviluppare software di qualità, ad esempio, l'applicazione di sviluppo
iterativo e focalizzando sugli utenti.
La sezione successiva esamina come applicare alcune delle pratiche migliori identificate nella comunità agile per
progetti basati su RUP che desiderano sfruttare alcune di dette pratiche.In questo caso, l'obiettivo è puntato in modo
specifico sulle pratiche presentate dalla metodologia eXtreme Programming (XP). (Per ulteriori informazioni su XP, fare
riferimento al sito Web: http://www.extremeprogramming.org.)
Pratiche XP
XP si compone di quattro "attività" base - codifica, verifica, ascolto e progettazione, che sono di fatto in linea con
i dettami di RUP. Dette attività XP vengono eseguite utilizzando una serie di pratiche
che richiedono l'esecuzione attività supplementari, che sono associate ad altre discipline in RUP. Le pratiche di XP,
secondo quanto riportato nel testo Extreme Programming Explained, sono:
-
Planning game: determinare velocemente l'ambito del rilascio successivo, combinando le priorità di business
e le stime tecniche. Quando la realtà impatta il piano, aggiornare il piano.
-
Small releases: avviare rapidamente la produzione di un sistema semplice, quindi rilasciare nuove versioni a
breve.
-
Metaphor: guidare tutta la fase di sviluppo con una storia semplice da condividere che descrive le
funzionalità del sistema.
-
Simple design: la progettazione del sistema deve essere sempre la più semplice possibile. Altre complessità
possono essere rimosse non appena identificate.
-
Testing: i programmatori scrivono test di unità in maniera sistematica, che devono essere eseguiti senza
errori per proseguire con lo sviluppo. I clienti scrivono test per dimostrare che le funzioni sono state ultimate.
-
Refactoring: i programmatori ristrutturano il sistema senza cambiarne le funzionalità per rimuovere
duplicati, migliorare le comunicazioni e aggiungere flessibilità.
-
Pair programming: tutto il codici di produzione è scritto in coppie di programmatori presso un solo
computer.
-
Collective ownership: il codice può essere modificato da chiunque, in qualsiasi momento ovunque nel sistema.
-
Continuous integration: integrare e progettare il sistema molte volte al giorno, ogni volta che si completa
un compito.
-
40-hour week: di regola, non lavorare più di 40 settimanali. Non lavorare mai in straordinario due settimane
di seguito.
-
On-site customer: inserire nel team un utente reale, disponibile a tempo pieno per chiarimenti.
-
Coding standards: i programmatori scrivono tutto il codice in conformità con le regole con particolare
enfasi sulla comunicazione tramite codice.
Le attività eseguite quale risultato della pratica di "planning game", ad esempio, mapperanno essenzialmente la
disciplina di gestione del progetto del RUP. Alcuni argomenti RUP, quali distribuzione del software rilasciato, non
rientrano nell'ambito di XP. La deduzione dei requisiti è ampiamente fuori la portata di XP, in quanto è il cliente a
definire e fornire i requisiti. Inoltre, poiché per la sua capacità di affrontare progetti di sviluppo più semplici, XP
può trattare poco le problematiche che invece RUP è in grado di trattare nel dettaglio in termini di disciplina di
gestione della configurazione e delle modifiche e di disciplina dell'ambiente.
Pratiche XP compatibili con RUP
Nelle discipline in cui XP e RUP si sovrappongono, le seguenti pratiche descritte in XP potrebbero e, in alcuni casi
già sono, impiegate in RUP:
-
The planning game: la guida XP sulla pianificazione può essere utilizzata per raggiungere molti degli
obiettivi illustrati nella disciplina Gestione progetti di RUP for anche per progetti molto piccoli. Ciò è
particolarmente utile per progetti per cui non è richiesto di produrre artefatti sulla gestione del progetto
intermedi.
-
Test-first design and refactoring: queste sono buone tecniche da applicarsi nella disciplina di
implementazione di RUP. La consuetutidine di XP di eseguire verifiche, che richiede un approcci test-first design,
è particolarmente indicato per chiarire i requisiti a livello dettagliato. La sezione successiva illustrerà come il
refactoring potrebbe non essere in grado di scalare nel caso di sistemi più grandi.
-
Continuous integration: RUP supporta questa pratica attraverso buil a livello di sottosistema e sistema
(all'interno di un'iterazione). Componenti testati a livello di unità vengono integrati e testati nel contesto del
sistema emergente.
-
On-site customer: molte attività RUP potrebbero trarre enorme vantaggio dalla presenza in sede del cliente
quale parte integrante del team, riducendo il numero di documenti necessari in modo specifico per il componente
distribuibile. Il mezzo di comunicazione tra cliente e sviluppatore preferito da XP è il dialogo diretto, che si
affida alla continuità e alla familiarità per raggiungere il successo; tuttavia, quando un sistema, anche piccolo,
è in fase di transizione, è necessario molto più del dialogo. XP utilizza questo metodo nel caso di un
ripensamento, ad esempio, per i documenti di progettazione alla fine di un progetto. Sebbene non proibisca la
produzione di documentazione o altri artefatti, XP consiglia di produrre solo quelli effettivamente necessari. RUP
condivide questo approccio, ma descrive cosa è necessario disporre quando continuità e familiarità non sono ideali.
-
Coding standards: RUP propone linee guida per la programmazione di artefatti che da considerarsi quasi
sempre obbligatori. (La maggior parte dei profili di rischio del progetto, in quanto fattore determinante per la
personalizzazione, rende obbligatoria l'imposizione di standard di codifica.)
-
Forty-hour week: come in XP, anche RUP suggerisce di non esagerare con lo straordinario, anche se XP non
impone un limite rigoroso di 40 ore, riconoscendo diversi livelli di tolleranza all'orario di lavoro. Gli ingegneri
software sono noti per lavorare ore extra senza essere compensati, per la sola soddisfazione ottenuta dal progetto
ultimato e i responsabili non devono interrompere questa abitudine in maniera arbitraria. Il responsabile non deve
sfruttare questa pratica o imporla, mantenendo un registro di tutti gli orari lavoro effettio, anche se non è
retribuito. Se il registro delle ore lavorate di un particolare individuo sembra sia particolarmente elevato per
lungo periodo, è necessario investigare; tuttavia, queste sono problematiche da risolversi al momento in cui se ne
presenta la circostanza, tra il responsabile e l'interessato, ascoltando anche eventuali considerazioni del del
resto del team. Quaranta ore è un criterio-guida, sebbene deciso.
-
Pair programming: XP sostiene che la programmazione in coppia è vantaggiosa per la qualità del codice e una
volta acquisito, questo metodo di lavoro è più piacevole. RUP non descrive la meccanica di produzione del codice in
maniera granulare, sebbene sia certamente possibile utilizzare la programmazione in coppia in un processo basato su
RUP. Alcune informazioni sulla programmazione in coppia, così come test-first design e refactoring, è offerta
adesso su white paper. Ovviamente, l'utilizzo di una qualsiasi di dette pratiche non è un requisito in RUP,
tuttavia in un ambiente di team, dove vige la cultura di comunicazione aperta, si può ipotizzare che i vantaggi
ottenuto dalla programmazione in coppia, in termini di effetti sul costo totale del ciclo di vita sarebbero
difficili da determinare. Collaboratori si riuniscono per discutere e risolvere problemi naturalmente in un team
che funziona bene, senza essere obbligati.
L'idea che un buon processo debba essere applicato al microlivello spesso non viene accolta con piacere e potrebbe non
adeguarsi alla cultura aziendale. L'applicazione rigorosa, pertanto, non è sostenuta da RUP. Tuttavia, in alcune
circostanze, lavorare in coppia e altre pratiche da svolgersi in team sostenute da XP, ha i suoi vantaggi, in quanto
ogni membro può aiutare l'altro; ad esempio:
-
nei primi giorni, quando si forma il team e i collaboratori incominciano a conoscersi
-
team con poca esperienza in alcune nuove tecnologie
-
team con personale composto da professionisti e principianti
Pratiche XP poco scalabili
Le seguenti pratiche XP non scalano facilmente su sistemi più grandi, tantomeno XP sostiene diversamente, quindi l'uso
delle stesse è soggetto a questa condizione in RUP.
-
Metaphor: per sistemi più grandi e complessi, ridurre l'architettura a una metafora non è sufficiente. RUP
offre un framework descrittivo più ricco per l'architettura che non è - come Extreme
Programming Explained la descrive - "grandi contenitori e connessioni". Anche nella comunità XP, il valore
della metafora è stato sminuito. La metafora non è più una pratica in XP e, fino ad ora, non è stata tuttavia
sostuita da un'altra pratica.
-
Collective Ownership: è utile se i membri di un team responsabile di un piccolo sistema o di un sottosistema
sia pratico di tutto il relativo codice. Ma la necessità di avere tutti i membri del team cono lo stesso livello di
conoscenza dovrebbe dipendere dalla complessità del codice. Potrebbe essere più veloce e sicuro assegnare una
correzione a un individuo o una coppia a lavoro sul segmento di codice rilevante. La conoscenza con anche il codice
scritto nel modo migliore, in particolare se composto di algoritmi complessi, diminuisce rapidamente nel tempo.
-
Refactoring: in un grande sistema, l'esecuzione frequente del refactoring non sostituisce la mancanza di
architettura. Extreme Programming Explained sostiene che la strategia progettuale
di XP assomiglia a un algoritmo per scalare una collina. Vale a dire, rendere una progettazione semplice e renderla
più complessa, quindi semplificarla di poco e renderla di nuovo più complessa. Il problema con questi algoritmi è
raggiungere la condizione ottimale, dove grandi cambiamenti, anziché piccoli, possono fare la differenza. In RUP,
l'architettura offre la visuale e l'accesso a una "montagna", per rendere un sistema grande e complesso, gestibile.
-
Small Releases: la velocità a cui il cliente può accettare e distribuire nuovi rilasci dipende su molti
fattori, tra cui, in genere, le dimensioni del sistema, correlato con l'impatto sul business. Un ciclo bimensile
potrebbe essere troppo breve per alcuni tipi di sistemi; la logistica della distribuzione potrebbe essere
proibitiva.
Pratiche da impiegarsi con cautela
Infine, una pratica XP, Simple Design, che a prima vista potrebbe sembrare utilizzabile in RUP, deve essere rielaborata
e gestita con cautela quando applicata in generale.
-
Simple Design
XP si affida molto alle funzionalità: le "storie" dell'utente vengono selezionate, scomposte in compiti e quindi
implementate. Secondo Extreme Programming Explained, la versione corretta del
software progettato, è quella che esegue tutti i test in qualsiasi momento, non ha duplicati logici, esprime ogni
intenzione di rilievo per i programmatori e il numero di classi e metodi è ridotto al minimo. XP non crede
nell'aggiungere elementi che non hanno valore commerciale per il cliente.
Il problema qui, simile a quello delle ottimizzazioni locali, è cercare di gestire quelli che RUP definisce
come requisiti "non funzionali". Anche questi requisiti hanno valore commerciale per il cliente, ma sono più
difficili da esprimere in "storie. Alcuni di ciò che XP definisce vincoli cadono in questa categoria. Anche RUP
non supporta la progettazione di più di quanto necessario in modo eccessivo, tuttavia supporta la progettazione
basata su un modello strutturale, elemento chiave per soddisfare anche i requisiti non funzionali.
Pertanto, RUP concorda con XP che il "simple design" debba includere l'esecuzione di tutti i test, ma con la
postilla che vengano inclusi test che dimostrano che software soddisferà anche i requisiti non funzionali. Si
sottolinea che ciò si profila come un problema importante all'aumentare della dimensione e della complessità
del sistema oppure quando l'architettura non ha precedenti o è sovraccarica di requisiti non funzionali. Ad
esempio, quando è necessario eseguire la collazione dei dati, per lavorare in un ambiente distribuito ed
eterogeneo, sembra che il codice diventi troppo complesso, tuttavia, sarà necessario per la produzione del
programma.
Mappatura degli artefatti in un progetto piccolo
Quando si personalizza un RUP per un progetto piccolo e si riduce ilProdotto di
lavoro in base ai requisiti, come si rapporta all'equivalente degli artefatti in un progetto XP? La Tabella 1
illustra un insieme tipico di artefatti RUP in un piccolo progetto RUP.
Tabella 1: Mappatura da XP a RUP degli artefatti per un progetto piccolo
Sebbene la granularità degli artefatti varia in entrambi i framework, in genere gli artefatti per piccoli progetti in
RUP, il tipo XP è in grado di affrontare facilmente, si mappano piuttosto bene a quelli di un progetto in XP.
Si sottolinea che la tabella include anche alcuni artefatti cui XP non si dedica. Tra cui Modello di dati e artefatti correlati alla distribuzione, quali Documentazione di supporto dell'utente.
Attività
RUP definisce un'Operazione come
un lavoro eseguito da unRuolo,
utilizzando e trasformando artefatti di input o producendo artefatti nuovi o modificati di output. RUP enumera dette
attività e le suddivide in categorie in base allediscipline di RUP. Le discipline sono, tra le altre: requisiti, analisi e
progettazione, distribuzione e gestione progetto.
Le attività sono correlate al tempo attraverso gli artefatti che producono e consumano: un'attività può avere inizio
logico quando i suoi input sono disponibili e hanno raggiunto lo stato di maturazione appropriato. Vale a dire che le
coppie di attività produttore-consumatore possono sovrapporsi nel tempo, se lo stato dell'artefatto lo consente; non
devono essere sequenziate in maniera rigida. Le attività sono destinate a fornire linee guida rigorose su come produrre
un artefatto e possono essere anche utilizzate per assistere il responsabile progetto con la pianificazione.
Intrecciate nel RUP come è stato descritto in termini di ciclo di vita, artefatti e attività, sono le "pratiche
migliori": i principi progettuali del software che hanno provato di generare software di qualità costruito in base a
pianificazione e budget prevedibili. RUP, attraverso le proprie attività e gli artefatti ad esse associati, supporta e
realizza dette pratiche, sono temi che attraversano il RUP, che sostengono iprincipi chiavi che corroborano il RUP stesso. Si sottolinea che anche XP utilizza
la nozione di "pratiche", ma come verrà illustrato di seguito, il concetto non è in linea perfetta con la definizione
di pratiche migliori di RUP.
XP propone una visione semplice e coinvolgente dello sviluppo del software composto da quattro attvitià di base -
codifica, verifica, ascolto e progettazione - da abilitare e strutturare in conformità con alcune delle pratiche di
supporto (come esaminato in Extreme Programming Explained, Capitolo 9). In realtà, come segnalato in precedenza, le
attività di XP sono più simili in termini di ambito alle discipline e non alle attività di RUP e la maggior parte di
ciò che accade in un progetto XP, oltre alle quattro attività base, deriva dall'elaborazione e dall'applicazione delle
sue pratiche.
Pertanto, un equivalente XP della attività di RUP esiste, ma le "attività" di XP non sono identificate o descritte
formalmente come tali. Ad esempio, esaminando il Capitolo 4, "User Stories" (storie dell'utente) Extreme Programming Installed, l'intestazione richiede di definire i requisiti con storie
scritte su cartoncini e prosegue con un misto di descrizioni del processo e di linee guida che definiscono cosa sono le
storie dell'utente e come e da chi devono essere prodotte. Così per tutto il capitolo; in varie sezioni dei libri di XP, nelle intestazioni che sono misto di artefatti e attività, le "things produced"
(elementi prodotti) e "things done" (elementi ultimati) sono descritte con vari gradi di regolamentazione e dettaglio.
L'apparente alto grado di regolamentazione di RUP è il risultato della propria completezza e il maggiore formalismo nel
trattare le attività e relativi input e output. XP non manca di regolamentazione, forse nel tentativo di restare
leggero, formalismo e dettaglio sono semplicemente omessi. La mancanza di specificità non è ne un punto di forza ne di
debolezza, ma la mancanza di informazioni dettagliate in XP non deve essere confusa con semplicità. Non disporre di
dettagli può essere accettabile per sviluppatori esperti, ma in molti casi, è vero il contrario per membri del team
nuovi o che stanno familiarizzando con l'approccio adottato dal team nello sviluppo del software.
Con Attività, così come con Artefatti, è importante concentrare l'attenzione sull'obiettivo fissato. L'esecuzione di
un'attività alla ceca non è mai buona prassi. Le attività e le linee guida ad esse associate sono da consultare per
raggiungere gli obiettivi, ma non devono essere utilizzate come scusante per non determinare cosa si sta tentando
raggiungere. Questo spirito è ben articolato in XP e si ritiene debba essere applicato ad ogni utente di RUP.
Ruoli
In RUP, leattività sono eseguite daruoli o più
precisamente da individui o gruppi che assumono ruoli. Ai ruoli sono attribuite anche responsabilità per l'artefatti; il ruolo responsabile in genere crea l'artefatto e garantisce che
eventuali modifiche eseguite da altri ruoli, ove consentite, non lo interrompano. Un individuo o un gruppo può assumere
un solo ruolo o una serie di ruoli. Non è necessario mappare un ruolo a un'unica posizione o "slot" in
un'organizzazione.
Extreme Programming Explained identifica sette ruoli applicabili ad XP -
Programmatore, Cliente, Tester, Tracker, Coach, Consulente e Big Boss - ne descrive le responsabilità e le capacità che
gli individui devono possedere per assumerli. Riferimenti sono anche fatti a questi ruoli in alcuni degli altri libri di XP. La differenza nel numero di ruoli in XP e RUP è facile da spiegare:
-
XP non si occupa di tutte le discipline esaminate da RUP.
-
I ruoli XP sono paragonabili più alle posizioni all'interno di un'organizzazione (possibilmente con più
responsabilità) che ai ruoli RUP. Ad esempio, il Programmatore XP esegue più ruoli RUP - Implementatore,
Esaminatore codice e Integratore - che richiedono capacità leggermente diverse.
Ruoli XP e RUP in un progetto piccolo
Quando i ruoli di RUP sono mappati a un progetto piccolo, il numero di ruoli XP simili cui corrispondono si riduce
considerevolmente, ovvero il numero di posizioni o titoli è 5. La Tabella 3, estratta da un RUP, mostra questa
mappatura con il corrispondente Ruolo XP.
Tabella 3: Mappatura dei ruoli XP ai ruoli RUP in progetti piccoli
Utilizzo delle pratiche XP con RUP
RUP è un framework di processi da cui determinati processi possono essere configurati e quindi installati. RUP deve
essere configurato, un passaggio obbiligatorio definito in RUP stesso. Nello specifico, si dovrebbe paragonare una
versione personalizzata di RUP con una diXP, vale a dire con RUP personalizzato in base alle caratteristiche del
progetto stabilite chiaramente e quelle sottese da XP. Un processo RUP personalizzato di questo genere potrebbe non
accogliere molte delle pratiche di XP, come pair programming, test-first design e refactoring, tuttavia non sarebbe
identico ad XP per l'enfasi data da RUP all'architettura, all'astrazione (in modellazione) e al rischio e relative
strutture che si differenziano nel tempo (fasi ed iterazioni).
XP è diretto intenzionalmente all'implementazione di processi leggeri per progetti piccoli. Facendo così, include anche
descrizioni, almeno nei testi, che non sono elaborati a pieno. In un'implementazione XP saranno sempre presenti
elementi che devono essere individuati, inventati o definiti immediamente. RUP è in grado di accogliere progetti che si
adattano e vanno oltre l'ambito di XP, per scala e tipologia. Come dimostrato da questo piano di sviluppo, RUP è
abbastanza compatibile con la maggior parte delle pratiche descritte nella documentazione su XP.
Ricordare che l'essenza di XP è il concentrare l'attenzione sull'organizzazione, gli individui e la cultura. Ciò è
importante in tutti i progetti ed è certamente applicabile ai progetti che si servono di RUP. Progetti piccoli possono
trarre grande vantaggio dall'utilizzo contemporaneo di dette pratiche.
Riferimenti per il processo agile
-
eXtreme Programming (XP) (Per ulteriori informazioni, vedere http://www.extremeprogramming.org/more.html.):
-
Extreme Programming Explained: Embrace Change. Kent Beck esamina i concetti e la filosofia
dietro extreme programming. Questo libro insegna cosa e perché, ma non come.
-
Refactoring Improving the Design of Existing Code. Martin Fowler redige il primo autorevole
volume sul refactoring. Presentato come pattern. Propone numerosi esempi in Java. Questo libro insegna
come eseguire il refactoring e perché.
-
Extreme Programming Installed. By Ron Jeffries, Chet Hendrickson, and Ann Anderson. Questo libro
si occupa di specifiche pratiche XP in dettagli più granulari rispetto a Extreme Programming Explained.
Questo libro insegna come programmare nello stile XP.
-
Planning Extreme Programming. By Kent Beck, and Martin Fowler. Questo libro illustra i pensieri
più recenti su come pianificare il software in ambienti a consegna rapida. Questo libro insegna come
eseguire un progetto XP.
-
Extreme Programming Examined. By Giancarlo Succi and Michele Marchesi. Documenti presentanti
all'XP2000. Una raccolta esaustiva di documenti su molti argomenti.
-
Extreme Programming in Practice. By Robert C. Martin, James W. Newkirk. Un progetto reale che ha
utilizzato XP descritto nel dettaglio.
-
Extreme Programming Explored. By William C. Wake. Basato sul noto sito Web XPlorations.
Argomenti specifici sono esplorati nel dettaglio.
-
Extreme Programming Applied: Playing to Win. By Ken Auer and Roy Miller. Esperienze dai pionieri
dell'applicazione dell'XP. Pubblicazione prevista per settembre.
Per ulteriori informazioni sugli altri membri della Agile Alliance vedere http://www.agilealliance.org.
|