Progettazione del Software

Transcript

appunti dalle lezioni
Marco Gasparini
Carlo Pane
Francesco Solera
59853
59202
59326
Università degli Studi di Modena e Reggio Emilia
Progettazione del Software, appunti dalle lezioni
This report was prepared by
Marco Gasparini, Carlo Pane, Francesco Solera
Professor
Flavio Bonfatti
Release date:
Course:
2011
Department:
Ingegneria Informatica
Comments:
Questo breve documento vuole essere un supporto didattico alle
lezioni del corso di Progettazione del Software. È stato scritto
a partire dagli appunti presi a lezione ed integrato, qualora
ritenuto necessario, con materiale dai libri di testo indicati dal
docente e riportati nella bibliografia.
Department of Information Engineering
Information Technologies and Computer Science
University of Modena e Reggio Emilia
www.dii.unimo.it
Introduzione
Il corso è indirizzato agli studenti della Laurea Magistrale in Ingegneria Informatica ai quali intende fornire le conoscenze e gli strumenti metodologici fondamentali
per l’impostazione, l’organizzazione e la gestione di progetti software complessi e
di grandi dimensioni. Gli argomenti trattati sono: :
Economia di un progetto software. Fattibilità di un progetto software, metodo
PERT-CPM. Classificazione delle tecniche di stima dei costi e dei tempi di un progetto. Metodo CoCoMo di Boehm (modello base, modello intermedio, cenni al
modello dettagliato). Funzione costo di Norden e metodo analitico di Putnam. Le
principali variabili di un progetto software. Progetto di piccole, medie e grandi
dimensioni secondo Putnam. Curva di sviluppo e curva di progetto. Equazione del
software. Software sizing per progetti nuovi e per rifacimenti. Studio del progetto
tramite planning zone e punto di lavoro.
Metodi avanzati di progettazione del software. Il Processo Unificato (UP).
Metodi agili di sviluppo del software e loro principali caratteristiche. Il metodo
Agile UP. Il metodo SCRUM. Il metodo Feature Driven Development (FDD). Il
metodo Dynamic Systems Development (DSDM). Il metodo Extreme Programming (XP). Tecniche agili di sviluppo del software. Cross-functional team, time
boxing, pair programming, test-driven development, code re-factoring. Confronto
critico dei diversi approcci. Software Process Improvement (SPI) e Capability Maturity Method integration (CMMi).
Linguaggi formali e tecniche di compilazione. Alfabeto, stringa, linguaggio
e relativi operatori. Espressioni e linguaggi regolari. Grammatiche generative,
definizione formale e classificazione di Chomsky. Grammatiche non contestuali.
Alberi sintattici, ambiguit‡ della grammatica. Grammatiche strettamente lineari
sinistre, equivalenza con espressioni regolari. Automi a stati finiti, equivalenza con
grammatiche strettamente lineari sinistre. Automi non deterministici. Derivazione
degli automi deterministici equivalenti, automi minimi. Notazione polacca postfissa
e forma a quadruple, generazione del codice oggetto.
Contents
II
Metodi avanzati di progettazione del software
1 Il Processo Unificato
3
1.1
Caratteristiche dello Unified Process . . . . . . . . . . . . . . . . . .
4
1.2
Ciclo di vita del progetto . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . .
6
2 Modelli agili di progettazione e sviluppo del software
11
2.1
Agile UP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3
FDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.4
Dynamic System Development Method . . . . . . . . . . . . . . . . .
26
2.5
XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3 Sistemi di qualità
III
1
37
3.1
ISO 9001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.2
Capability Maturity Model integration . . . . . . . . . . . . . . . . .
37
Linguaggi formali e tecniche di compilazione
43
Part II
Metodi avanzati di
progettazione del software
1
Chapter
1
Il Processo Unificato
Fino ad ora abbiamo sempre avuto a che fare con un metodo di progettazione
del software chiamato a cascata. Il modello a cascata o ciclo di vita a cascata
(waterfall model o waterfall lifecycle in inglese) è un modello di ciclo di vita del
software (ovvero di processo software) secondo cui la realizzazione di un prodotto
software consta di una sequenza di fasi strutturata in analisi dei requisiti, progetto,
sviluppo, collaudo, integrazione e manutenzione. Ciascuna di queste fasi produce
un ben preciso output che viene utilizzato come input per la fase successiva.
Purtroppo questo modello viene definito rigido, poiché una volta terminata una fase,
questa viene bloccata e diventa insensibile a nuovi requisiti che il cliente potrebbe
chiedere o modifiche che il team di sviluppo riconosce come necessarie. Quando
si sviluppano software medio-grandi con un modello a cascata occorre mettersi
nell’ottica che:
• Il 25%-50% dei requisiti probabilmente cambieranno durante la durata del
progetto
• Almeno il 45% dei requisiti implementati non saranno utilizzati dal cliente
• Il cliente finanziatore non vedrà niente fino alla fine del processo di sviluppo
del software
Spesso questi vincoli non risultano essere apprezzati nè dal cliente, che inizia a
vedere i risultati dopo lunghi mesi dal momento del finanziamento, nè per il team
di sviluppo che è costretto a fare i conti con la rigidità e la linearità di questo approccio. Da queste necessità è nato un nuovo paradigma di progettazione, chiamato
Unified Process. Lo UP non è un semplice processo ma piuttosto un framework,
un ambiente di lavoro, che dovrebbe essere personalizzato per particolari aziende e
progetti. Anche lo Unified Process divide il tempo di sviluppo del software in fasi:
Inception, Elaboration, Construction e Transition; per ognuna di queste fasi sono
definiti obiettivi ben chiari, ma nessun particolare vincolo è imposto sulle differenti
discipline necessarie allo sviluppo (come ad esempio i requisiti). Questa caratteristica permette di riprendere in mano il lavoro già svolto anche in fasi successive e di
3
1.1. Caratteristiche dello Unified Process
procedere in maniera parallela verso il momento di rilascio del prodotto. Lo UP è
particolarmente gradito anche al cliente che può toccare con mano l’evoluzione del
suo software in una sempre maggiore implementazione dei requisiti.
1.1
Caratteristiche dello Unified Process
Iterativo ed incrementale
Lo UP è un processo di sviluppo iterativo ed incrementale. Le fasi di Elaboration, Construction and Transition sono divise in una serie di iterazioni di durata
definita. Ogni iterazione risulta in un incremento, ovvero in un rilascio del prodotto
che contiene funzionalità aggiunte o migliorate rispetto alla release precedente.
Nonostante la maggior parte delle iterazioni includeranno contributi da una buona
parte delle discipline (requisiti, analisi, progettazione, implementazione e testing),
l’importanza di questi contributi cambierà nel corso del progetto.
Basato sugli Use Case
Nello UP, i casi d’uso sono usati per catturare i requisiti funzionali e per definire
il contenuto di ogni iterazione. Ogni iterazione si occupa di gestire un certo sottoinsieme di casi d’uso o di scenari dai requisiti fino all’implementazione, test e
rilascio.
Incentrato sull’architettura
Per lo UP è importante che l’architettura del software sia alla base della preoccupazione e degli sforzi del team di sviluppo. In quanto nessun modello da solo
è sufficiente per catturare tutti gli aspetti del sistema, lo UP supporta vari modelli architetturali. Uno degli impegni più importanti del processo di sviluppo è
l’architettura della baseline eseguibile che viene creata durante la fase di Elaboration. Questa implementazione parziale, dovrebbe rispondere ai requisiti critici e caratteristici individuati in fase di analisi dei requisiti e serve per validare
l’architettura globale del progetto. Inoltre diventerà, se ritenuta valida, la base per
il resto dello sviluppo del software.
Pilotato dai fattori di rischio
Lo UP richiede che il team di sviluppo sia preoccupato di risolvere i rischi più critici
nelle prime fasi del progetto.
1.2
Ciclo di vita del progetto
Come già accennato anche lo UP prevede che il ciclo di vita del progetto sia suddiviso in quattro fasi.
4
1.2. Ciclo di vita del progetto
Il grafo RAPIT
Il grafo RAPIT (Requisiti, Analisi, Progettazione, Implementazione, Test) permette
di caratterizzare dinamicamente per ogni progetto quando e con quale importanza
le varie discipline della progettazione del software entreranno in gioco nelle varie
fasi di sviluppo del prodotto.
Figure 1.1: Il grafo RAPIT, mette in relazione le discipline della progettazione
del software con le fasi di sviluppo del prodotto.
Inception
L’inception è la fase più breve nella progettazione, e così deve essere: una fase
di inception prolungata indica un eccessivo lavoro di specificazione a priori, che è
contrario allo spirito dello UP. Obiettivo: definire a grandi linee ciò che il software
dovrà fare. Artefatti: requisiti principali, valutazione dei rischi, glossario del
progetto, una prima documentazione dell’architettura, una prima pianificazione
dello sviluppo e i prototipi.
Elaboration
Durante la fase di Elaboration, il team di sviluppo dovrebbe catturare la maggior parte (si può stimare un 80%) dei requisiti del software finale. Comunque lo
scopo principale di questa fase è quella di produrre una prima baseline eseguibile
che verifichi l’appropriatezza del modello architetturale adottato. Una baseline è
un’implementazione parziale del sistema che include il cuore e le specifiche caratterizzanti del progetto. È costruito e migliorato ciclicamente in una serie di iterazioni
e per la fine della fase di elaborazione il modello architetturale deve essere fissato e rimanere stabile fino alla fine dello sviluppo, inoltre la baseline eseguibile
deve dimostrare che la scelta dell’architettura si rivela appropriata per supportare
le funzionalità chiave del prodotto in termini di performance, scalabilità e costi.
Obiettivi: creare una baseline eseguibile, perfezionare la valutazione dei rischi,
creazione dei casi d’uso di circa l’%80 dei requisiti fornendo alla fase di costruzione
5
1.3. Rational Unified Process
una solido piano (di costi e di scadenze) su cui lavorare. Artefatti: baseline, disegno architetturale, documento di valutazione dei rischi, diagrammi dei casi d’uso,
pianificazione dettagliata.
Construction
La Construction è la fase più lunga della progettazione. In questa fase quello
che rimane del sistema è costruito a partire dalla baseline prodotta dalla fase di
Elaboration. Le caratteristiche del software sono sviluppate durante una serie di
iterazioni di piccola durata alla fine delle quali deve essere prodotto una nuova
baseline eseguibile. Durante questa fase vengono spesso impiegate tecniche di progettazione UML(Activity, Sequence, Collaboration, State (Transition) and Interaction Overview diagrams). Obiettivo: capacitò operativa basilare, ovvero la release
prodotta da questa fase deve permettere già l’utilizzo delle funzioni caratteristiche
del software. Artefatti: prodotto software, modellazione UML, una prima versione
del manuale utente ed un piano di testing.
Transition
La fase finale del progetto è la Transition. In questa fase il sistema è consegnato
all’utente finale. Con il feedback ricevuto da una release iniziale uscente dalla
prima iterazione è possibile apportare modifiche e ridefinire scelte implementative.
Obiettivi: rilascio del prodotto, correzione dei difetti, formazione degli utenti
utilizzatori. Artefatti: prodotto software testato, risultato del test d’accettazione,
manuali d’uso aggiornati alla release definitiva e accordo di mantenimento.
1.3
Rational Unified Process
Il Rational Unified Process (RUP) (che è una estensione dello Unified Process) è
un modello di processo software iterativo ed incrementale sviluppato da Rational
Software (oggi parte di IBM). Fornisce un approccio disciplinato per l’assegnazione
dei compiti e delle responsabilità all’interno dello sviluppo di un progetto. Il suo
obiettivo è assicurare la produzione di un software di alta qualità che incontra
i bisogni dei clienti, pur rimanendo all’interno di un budget e di una tempistica
predefiniti.
Caratteristico di questa metodologia è occuparsi di descrivere chi sta facendo cosa,
come e quando. Il Rational Unified Process è rappresentato usando quattro elementi
primari di modellazione:
• Workers, the "who": definisce il comportamento e le responsabilità di un
individuo, o un gruppo di individui che lavorano insieme come team
• Activities, the "how": sono unità di lavoro che un individuo in quel ruolo può
svolgere, la granularità di un attività è tipicamente dell’ordine di poche ore o
pochi giorni
6
• Artifacts, the "what": è un pezzo di informazione che è prodotto, modificato
o usato da un processo, gli artefatti sono prodotti tangibili del processo
• Workflows, the "when": è una sequenza di attività che produce un risultato
di valore osservabile
Ci sono nove core process workflows o fasi specificate dal modello RUP, le quali
rappresentano una partizione di tutti i lavoratori e attività in gruppi logici. Le fasi
del ciclo di sviluppo del software sono divise in sei “engineering” workflows:
1. Business modeling workflow
2. Requirements workflow
3. Analysis & Design workflow
4. Implementation workflow
5. Test workflow
6. Deployment workflow
E tre workflows “di supporto”:
1. Environment workflow
2. Configuration and Change Management workflow
3. Project Management workflow
Anche se i nomi delle sei discipline ingegneristiche possono richiamare un idea di
processo a cascata, dobbiamo tenere in mente che sono fasi di un processo iterativo
e differiscono da queste in quanto sono riviste e riviste per tutta la durata del ciclo
di sviluppo del software.
Business modeling Uno dei problemi principali nella fase iniziale di progettazione di un software è che il team di software engineering ed il team di business
engineering non comunicano in modo appropriato. Questo comporta che il risultato prodotto dal business engineering non è usato in modo appropriato dal team di
software engineering e vice versa. Il RUP fornisce un linguaggio ed una metodologia
comune per tenere sincronizzati i modelli business e software.
Requirements. L’obiettivo di questo workflow è di descrivere cosa il sistema
dovrebbe fare e permettere agli sviluppatori ed ai clienti di concordare su tale
descrizione. Per ottenere questo esplicitiamo, organizziamo e documentiamo le
funzionalità, i vincoli e le decisioni prese in fase di analisi.
Analysis & Design Il goal principale qui è di far vedere come il sistema sarà
realizzato nella successiva fase d’implementazione. In breve realizza un astrazione
del codice che realizzerà i requisiti individuati.
7
Test Gli scopi della fase di testing sono: verificare l’interazione fra gli oggetti,
verificare l’integrazione di tutti i componenti del software, verificare che i requisiti siano tutti correttamente soddisfatti, individuare eventuali problemi prima del
rilascio del software.
Deployment Lo scopo di questa fase è quello di produrre con successo il rilascio del software e distribuirlo all’utente finale. Questa fase comprende anche
l’assistenza e l’aiuto all’utente.
Environment L’obiettivo del workflow di environment è quello di fornire al team
di sviluppo un ambiente, che comprende sia metodologie che strumenti, necessari
per la progettazione del prodotto, in particolare è importante chiarire le attività
volte all’inquadramento del processo all’interno di un progetto.
Configuration and Change Management In questo workflow è descritto come
controllare i numerosi artefatti prodotti dalle tante persone che lavorano su un
progetto comune. Avere controllo su questo piano significa evitare confusione e
assicurare che gli artefatti risultanti non siano in conflitto con altri a causa di
accessi multiplo, aggiornamenti simultanei o limitate notifiche.
Project Management Software Project Management è l’arte di bilanciare gli
obiettivi paralleli di un software, gestire i rischi e superare i vincoli, al fine di
rilasciare un prodotto che incontra i bisogni del cliente e degli utilizzatori finali.
Sviluppo efficace e buone pratiche
Il RUP descrive alcune pratiche che sono state osservate in progetti di successo
e che si ritiene possano essere d’aiuto nello sviluppare in modo efficace software
commerciale.
• Develop software iteratively: data la complessità dei software di oggi è impossibile delineare prima l’intero problema, disegnare una soluzione e poi
costruire il software e testarlo; è necessario un approccio iterativo che permetta di inserire nella progettazione la comprensione sempre maggiore che il
team di sviluppo ha sul problema e sulle funzionalità.
• Manage requirements: gestire in modo efficiente i requisiti funzionali è fondamentale per la buona riusciuta del software; è importante fin da subito
esplicitare, organizzare e documentare le funzionalità richieste ed i vincoli
imposti al fine di poter trarre decisioni e valutare compromessi, l’importanza
di questa pratica è data dal fatto che l’implementazione parte proprio da
queste considerazioni.
• Use component-based architectures: il processo si focalizza sull’inizio della
fase implementativa, si tratta di buttare delle fondamenta che siano robuste e
flessibili al tempo stesso, prima di arrivare ad avere una quantità di codice che
8
risulta mal strutturata ed ingestibile; a tale scopo sono importanti i concetti
di riusabilità e modularità.
• Visually model software: si tratta di accompagnare alla documentazione
scritta anche una modellazione visuale del comportamento dell’architettura e
dei componenti; questo permette di nascondere inutili dettagli e facilitare la
comunicazione di aspetti critici del software.
• Verify software quality: scarse prestazione e poca affidabilità sono fattori
che incidono pesantemente sull’accettabilità dei software moderni, quindi
la qualità dovrebbe essere valutata tenendo in considerazione fattori come
l’affidabilità, il rispetto dei requisiti e le performance dell’applicazione e del
sistema.
• Control changes to software: l’abilità di gestire modifiche - essere sicuri che
ogni modifica sia accettabile e rintracciabile - è essenziale in un ambiente in
cui le modifiche sono inevitabili.
9
10
Chapter
2
Modelli agili di progettazione e
sviluppo del software
Nell’ingegneria del software, per metodologia agile (o leggera) o metodo agile si
intende un particolare metodo per lo sviluppo del software che coinvolge quanto
più possibile il committente, ottenendo in tal modo una elevata reattività alle sue
richieste.
La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppando
il software in finestre di tempo limitate chiamate iterazioni che, in genere, durano
qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve contenere
tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità
del software. Anche se il risultato di ogni singola iterazione non ha sufficienti
funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi
delle iterazioni, deve avvicinarsi sempre di più alle richieste del cliente. Alla fine di
ogni iterazione il team deve rivalutare le priorità di progetto.
I metodi agili preferiscono la comunicazione in tempo reale, preferibilmente faccia
a faccia, a quella scritta (documentazione). Il team agile è composto da tutte le
persone necessarie per terminare il progetto software. Come minimo il team deve
includere i programmatori ed i loro clienti (con clienti si intendono le persone che
definiscono come il prodotto dovrà essere fatto: possono essere dei product manager,
dei business analysts, o veramente dei clienti).
L’agile manifesto
La formalizzazione dei principi su cui si basano le metodologie leggere è stata
oggetto del lavoro di un gruppo di progettisti software e guru dell’informatica che
si sono spontaneamente riuniti nell’Agile Alliance. Il documento finale di questo
lavoro è stato poi sottoscritto da un nutrito gruppo di questi professionisti, molti
dei quali hanno anche sviluppato alcune delle metodologie leggere più famose.
L’obiettivo è la piena soddisfazione del cliente e non solo l’adempimento di un
contratto. L’uso di queste metodologie, inoltre, serve ad abbattere i costi di sviluppo
11
Modelli agili di progettazione e sviluppo del software
del software.
Principi I principi su cui si basa una metodologia leggera che segua i punti indicati dall’Agile Manifesto, sono solo quattro:
• le persone e le interazioni sono più importanti dei processi e degli strumenti
(ossia le relazioni e la comunicazione tra gli attori di un progetto software
sono la miglior risorsa del progetto)
• è più importante avere software funzionante che documentazione (bisogna rilasciare nuove versioni del software ad intervalli frequenti, e bisogna mantenere
il codice semplice e avanzato tecnicamente, riducendo la documentazione al
minimo indispensabile)
• bisogna collaborare con i clienti al di là del contratto (la collaborazione diretta
offre risultati migliori dei rapporti contrattuali)
• bisogna essere pronti a rispondere ai cambiamenti più che aderire al progetto
(quindi il team di sviluppo dovrebbe essere autorizzato a suggerire modifiche
al progetto in ogni momento)
Considerazioni e buone pratiche La metodologia leggera non nasce per caso,
ma come presa di consapevolezza che alcune cose nel mondo della progettazione non
andavano. Essa, proprio perché nasce da alcune considerazioni fondanti fornisce
e suggerisce alcune pratiche che è bene avere in mente. Risulta particolarmente
importante, ad esempio, rilasciare frequentemente software con nuove funzionalità
mantenendo in questo modo alta la soddisfazione del cliente. Infatti un software
che funziona è molto più apprezzato di un mucchio di documentazione e di fogli
di progettazione in corso d’opera. Proprio per come è strutturata la metodologia,
anche il development team deve essere disposto ad accettare nuovi requisiti, nuove
funzionalità da inserire all’interno del software anche in fase di implementazione.
Questo forse è uno dei frutti principali della stretta collaborazione fra sviluppatori
e clienti, il rapporto faccia a faccia impedisce che ci siano periodi di inutile lavoro
sprecato poiché cambiato all’ultimo. Se il contatto con il cliente è continuo, allora la
progettazione risulterà più fluida. Infine il rischio di utilizzare queste metodologie
agili, è quello di credere che la progettazione formale sia in secondo piano, il che
non è assolutamente vero: è infatti importantissimo tenere in mente che obiettivo
principale è sempre quello dell’eccellenza tecnica e della qualità.
L’approccio agile contrappone un approccio adattativo (perché consente di rivedere
di continuo le specifiche e di cambiarle durante lo sviluppo mediante un forte scambio di informazioni e di pareri con il committente) rispetto ad uno predittivo (basato
su una precisa pianificazione iniziale). È comunque necessario precisare che le
metodologie agili non eliminano il concetto di progettazione, semplicemente è una
fase trasversale a tutto il ciclo di sviluppo del software.
I metodi agili hanno anche altri limiti oltre all’inevitabile abbassamento della qualità, riguardante la motivazione. Ossia, per portare avanti un progetto secondo
questa metodologia sono necessarie persone disponibili e con particolare esperienza;
12
inoltre le tecniche agili non si comportano bene con progetti enormi, con team distribuiti geograficamente, in aziende che sono particolarmente strutturate e gerarchiche, proprio perché queste situazioni intaccano i principi fondamentali dell’Agile
Manifesto.
Principi comuni dei modelli agili
Sin dall’inizio deve essere chiaro che questi approcci agili non sono la soluzione a
tutti i problemi, non hanno nessuna intenzione di abolire i metodi tradizionali, ma
possono introdurre un nuovo modo di affrontare particolari problemi. L’approccio
agile funziona molto bene in progetti a bassa criticità, se guidati da sviluppatori
senior, per software nuovi con requisiti ancora in fase di analisi. Di questi metodi
ce ne sono vari, i più famosi sono probabilmente Agile UP, Scrum, FDD, DSDM ed
XP. Anche se agili, questi metodi si fondano su un insieme di tecniche, pratiche che
permettono di disciplinare la progettazione (Cross-functional team, Time-boxing,
Pair programming, Test-driven development, Code refactoring). Le singole pratiche
applicabili all’interno di una metodologia leggera sono decine e dipendono essenzialmente dalle necessità dell’azienda e dall’approccio del project manager, tuttavia
alcune sono comuni.
Cross-functional team È l’idea di creare team di sviluppo capace di portare
avanti simultaneamente tutte le discipline della progettazione del software, quindi
dall’analisi dei requisiti, implementazione, test, etc. Ha la caratteristica di essere
self-directed, riceverà direttive ampie e generali da parte del managment, ma è il
team stesso che decide come organizzarsi e come procedere con la progettazione.
Questa tecnica porta con sè vari benefici, a partire dal modo di raggiungere gli
obiettivi, che passa da uni-directional ad una dinamica interna più ampia; non è
prestabilito chi fa che cosa, giorno per giorno. Le informazioni usate dal team per
svolgere le proprie azioni è più ampia, più ricca rispetto a quelle di un gruppo monofunzionali (greater scope of information). Non solo, oltre la vastità di informazioni,
anche la profondità di queste è notevolmente migliore (greater depth of information): supponiamo di essere in un gruppo di sola implementazione, allora tutto il
team potrebbe lavorare esclusivamente su quello che è già stato deciso e congelato
dagli analisti precedentemente; al contrario, in un cross-functional team possono
essere considerati e rivalutati molti più aspetti, anche in fase di implementazione.
Anche le persone coinvolte nel team ne traggono beneficio, non è più possibile utilizzare un gergo specifico o approssimativo nello svolgimento del proprio lavoro; ora
che si lavora in un gruppo interfunzionale è necessario essere comprensibili anche
ai membri specifici di altre discipline.
Time-boxing Questa pratica impone di dividere la progettazione in una serie
definita di intervalli di tempo prestabiliti, all’interno dei quali il lavoro deve essere
portato a termine. Se prima la logica era più incentrata sugli obiettivi (ed il tempo
si allungava fino all’esaurimento dell’obiettivo), ora con il time-boxing è il tempo
disponibile ad essere definito (ed eventualmente gli obiettivi vengono ridotti). È
importante quindi, che gli obiettivi vengano fin da subito commisurati con più real-
13
ismo al tempo necessario per portarli a termine. All’esaurire del tempo predefinito,
se l’obiettivo è ancora in fase di compimento, posso decidere se cancellare o rischedulare il lavoro in time-boxes successive. Se il vero vincolo del progetto è il tempo di
sviluppo, questa tecnica risulta particolarmente benefica. Il time-boxing può essere
utilizzata in piccola scala anche da una singola persona che voglia ottimizzare il
proprio tempo.
Pair programming Questa tecnica agile impiegata in vari metodi consiste nel
realizzare lo sviluppo del codice in due persone che se ne stanno insieme davanti
al display, uno con il ruolo di driver ed uno con il ruolo di navigator e con lo
scambio di questi ruoli particolarmente frequente (30 minuti). Il driver scrive il
codice, mentre il navigator anche non volendo svolge un ruolo particolarmente importante: ragiona sull’analisi, cioè mentalmente verifica in modo continuativo se il
codice scritto rispecchia la sua idea di implementazione dei requisiti, poi inizia a
progettare ciò che segue al codice scritto dal driver; infine evidentemente assume
un ruolo da debugger in real time, individuando gli errori compiuti dal compagno.
È un modo di lavorare molto interessante, che presenta vari benefici ma anche vari
limiti di applicazione. Fra i benefici attesi c’è la qualità del risultato che risulta essere perfettamente leggibile da due persone, e la cui chiarezza può essere apprezzata
anche al di fuori del tipico programmatore, probabilmente il codice risulta essere
particolarmente semplice anche se ugualmente efficace. Inoltre, in modo paradossale, il costo del progetto si riduce notevolmente (studi riconoscono l’incremento
del tempo di programmazione del 15%, ma il 50% in meno degli errori risultante in
un 20%-40% riduzione del tempo nella fase di debugging e testing).
Questa tecnica può essere utilizzata anche per la formazione di nuovi programmatori, che risultano essere autonomi molto più velocemente che con metodi di
apprendimento tradizionali. Risulta didattica anche la scelta di accostare due principianti, che possono aiutarsi nell’analisi e nel superamento delle difficoltà. Infine,
se per qualche ragione, un dipendente abbandona l’azienda, rimane la sicurezza di
conoscere il codice.
D’altra parte, non tutti hanno l’attitudine a collaborare e per alcuni l’esperienza
del pair-programming potrebbe non essere piacevole. Anche un principiante rischia
di sentirsi inappropriato ed intimidido se di supporto ad un senior programmer,
il quale fra l’altro rischia di annoiarsi. Possono inoltre nascere potenziali conflitti
dovuti alle differenti metodologie di programmazione utilizzati o dovuti al senso di
competizione che può scaturire fra i due.
Test-driven development Nello sviluppare il codice, per prima cosa, viene
scritto un test sul codice ancora inesistente. Successivamente scrivo il codice che
deve superare il test progettato. Se il codice supera il test, allora penso un altro
test, altrimenti devo tornare sul codice e cambiarlo. Questo procedimento richiede
un ambiente adeguato per scrivere test e sottoporre ai test frammenti di codice.
Una seconda osservazione è sulla scrittura dei test: essi sono scritti in modo lineare
rispetto allo sviluppo del codice, quindi può risultare particolarmente utile lavorare
in coppia, in modo che se uno ha pensato il test, l’altro scrive il codice senza sapere
come è stato strutturato e quindi viene evitato il rischio di scrivere codici con il solo
scopo di passare il test. Nonostante questo l’approccio è completamente diverso dal
14
2.1. Agile UP
pair programming, qui ottengo un codice pessimo, volto solo al superaramento del
test.
Avendo scritto un codice che soddisfa tutti i test, se i test sono scritti in modo
adeguato, probabilmente ho già fatto una buona parte del debugging (riducendo
quindi i tempi di sviluppo complessivi). Un secondo beneficio è che il lavoro è
guidato direttamente dai requisiti (che posso scegliere di tradurre in test). L’attenzione
è inoltre concentrata su un frammento di codice, portando ad un software più modulare ed estendibile. Anche questo metodo porta con se alcuni svantaggi fra cui la
richiesta sincronizzazione manuale fra codice del prodotto e codice dei test.
Code refactoring Questa tecnica risulta indispensabile nel caso di utilizzo del
TDD o nel caso di codice più volte maneggiato in tempi e da persone diverse.
Gli obiettivi del code refactoring sono la leggibilità del codice, la semplicità, la
mantenibilità, l’estendibile. Tutto questo risulta in un miglioramento interno del
software che spesso si riflettono in prestazioni migliorate e diminuzione dei costi
di mantenimento. Il code refactoring utilizza varie tecniche per migliorare alcuni
aspetti della progettazione:
• Astrazione. Incapsulare campi e dati in oggetti complessi, raggiungibili
tramite getter e setter. Generalizzare i tipi di dato che utilizzano informazioni
condivise. Sostituire condizioni con polimorfismo.
• Ristrutturazione. Estrarre e scomporre metodi in pezzi più piccoli. Estrarre classi con il loro codice associato.
• Leggibilità. Muovere metodi e campi su classi semanticamente coerenti.
Rinominare campi e metodi. Gerarchizzare le classi.
2.1
Agile UP
Questo metodo segue lo stesso approccio dell’UP originale, ma con la peculiare
differenza che le iterazioni non durano più 2/3 mesi, ma 4/5 settimane producendo
un incremento lineare del numero di iterazioni. Le discipline e le fasi individuate
dall’UP sono ritenute fondamentali e significative e non vengono abbandonate. Un
progetto di medie dimensioni può ad esempio essere composto da 20-25 iterazioni
della durata di circa 3 settimane l’una.
Iterazione #1
Primo workshop dei requisiti [2 giorni] (team, chief architect). La prima mattina
può essere chiesto di individuare i requisiti ad alto livello, magari indicando i nomi dei casi
d’uso, ed stabilire un 10% dei requisiti più critici (per l’architettura, per core-business o
per rischio). Il resto del tempo può essere speso per un analisi dettagliata di quel 10%.
Prima riunione di pianificazione [2 giorni]. Viene scelto un sottoinsieme dei requisiti analizzati da sviluppare durante la prossima iterazione. Il resto di questa iterazione può essere
impiegata per analizzare le condizioni di ben funzionamento dell’iterazione successiva.
Iterazione #2
UML [2 giorni] (team a coppie, chief architect). In questa prima parte dell’iterazione
gli sviluppatori si dividono in coppie e coordinati dal chief architect iniziano a pianificare
15
2.2. Scrum
l’implementazione dei requisiti ritenuti critici scelti nella prima iterazione.
Sviluppo e test [2 settimane]. Sviluppo e test dei requisiti modellati.
Controllo [1 settimana] Una settimana dalla fine dell’iterazione viene chiesto al team
se l’obiettivo originario dell’iterazione è stato raggiunto. In caso negativo, non si allunga
l’iterazione, ma si riducono gli obiettivi. Prima della fine della settimana il codice viene
congelato come prima baseline, ne viene data una dimostrazione al cliente e si iniziano
a raccogliere i primi feedback. L’ultimo paio di giorni si esegue il secondo workshop dei
requisiti, c’è una revisione del materiale e dei requisiti, si sceglie un altro 10% dei requisiti
da trattare e si conclude con una nuova riunione di pianificazione.
Dopo la seconda iterazione, la fase di inception si ritiene conclusa ed è realistico
pensare che dopo la quinta/sesta iterazione sia conclusa anche la fase di elaborazione, avendo raggiunto l’implementazione del circa 20% dei requisiti ed avendo
quindi a disposizione una baseline eseguibile affidabile.
2.2
Scrum
Lo scrum è una metodologia agile di sviluppo del software, ideata e sviluppata da
Ken Schwaber e Mike Beedle. Si basa su tre semplici punti: Sprint, Backlog e
Scrum Meeting e prevede di dividere il progetto in blocchi rapidi di lavoro (Sprint)
alla fine dei quali consegnare una versione al cliente, indica come definire i dettagli
del lavoro da fare nell’immediato futuro (Backlog) per averne una definizione estesa,
organizza riunioni giornaliere del team di sviluppo (Scrum Meeting) per verificare
cosa si è fatto e cosa si farà.
Ruoli dello Scrum process
Il termine Scrum è mutuato dal termine del Rugby che indica il pacchetto di mischia
ed è evidentemente una metafora del team di sviluppo che deve lavorare insieme
in modo che tutti gli attori del progetto spingano nella stessa direzione, agendo
come un’unica entità coordinata. I team consistono di tre ruoli principali e tre
ruoli ausiliari: ci si riferisce ai ruoli principali come pigs ed ai ruoli secondari come
chickens secondo la storia “La gallina ed il maiale”.
Storiella:
un maiale e una gallina si incontrano per creare un azienda agricola... Il maiale
dice: “come la chiamiamo?” e la gallina: “chiamiamola Hams & Eggs!!!” ed il
maiale contrariato risponde: “eh no: io ci devo mettere tutto mentre tu ci metti
solo una parte!!!”
Pigs: core Scrum roles I ruoli principali all’interno dei team Scrum sono quelli
che si occupano dello sviluppo vero e proprio del progetto, sono quelli che lo producono.
• Product Owner: rappresenta la voce del cliente ed è prezioso in quanto assicura (poiché è suo principale beneficio) che il team realizzi un prodotto valido
e di qualità
16
2.2. Scrum
• Team: è responsabile della consegna del progetto, tipicamente composto da
5-9 persone effettua il vero lavoro (analisi, design, sviluppo, test, documentazione, ...)
• Scrum Master: è colui incaricato di coordinare il team e di impedire che ci
siano ostacoli alla produzione di un buon software, non è il team-leader, ma
agisce come un buffer fra il resto del team ed eventuali problemi interni o
esterni che possono sorgere
Chickens: ancilliary Scrum roles I ruoli ausiliari o di supporto sono quegli
individui che non hanno un ruolo formale o frequente all’interno del processo di
progettazione, ma non per questo non devono essere considerati.
• Stakeholder: sono quelle persone (clienti o venditori) che hanno interesse nella
buona riuscita del progetto e pertanto lo finanziano, hanno quindi titolo per
influire sul progetto ma non sono responsabili della conduzione o della buona
riuscita del processo
• Manager: sono quelle persone che non lavorano direttamente alla progettazione del software ma curano l’ambiente ed il contesto di lavoro
Le fasi dello Scrum process
Un processo di progettazione che segue la metodologia Scrum, è caratterizzato da
tre fasi che prendono il nome di Sprint, come mostrato in Fig. 2.1.
Figure 2.1: Lo Scrum process che trasforma le specifiche di alto livello in un
incremento del prodotto potenzialmente rilasciabile.
• Product Backlog: insieme delle specifiche di alto livello ordinate per priorità, che sarebbe importante implementare ma ancora non lo sono state. Il
responsabile di questa parte è il Product Owner.
• Sprint Backlog: è una lista del lavoro che il team dovrà fare durante il
prossimo Sprint. Le funzionalità descritte nel Product Backlog sono suddivise
17
2.2. Scrum
in compiti (tasks) i quali dovrebbero avere la durata massima di due giorni.
A queto livello di dettaglio l’intero team capisce esattamente cosa deve fare e
potenzialmente, chiunque può scegliere un task dalla lista da implementare.
Questa iterazione ha durata tipica di un mese.
• Working Increment: è il rilascio del software funzionante a cui vengono
aggiunte le parti sviluppate nello Sprint appena concluso.
Figure 2.2: Dettaglio dello Scrum process. All’inizio il Product Owner crea il
Product Backlog (il quale viene mantenuto ed aggiornato per tutta
la durata del processo), a seguire iniziano le iterazioni di Sprint
che portano al rilascio incrementale del prodotto funzionante. Ogni
Sprint è caratterizzato da iterazioni giornaliere nelle quali vengono
sviluppati i singoli tasks.
Organizzazione del lavoro a Sprint Uno sprint ha durata tipica di un mese,
ma è importante all’inzio ed alla fine di uno sprint capire cosa si vuole realizzare
e cosa si è realizzato, come in ogni metodologia time-boxed. A tale scopo esistono
due fasi che racchiudono ogni Sprint:
• Sprint Planning Meeting: consiste nella fase di preparazione ed è una
riunione di 8 ore suddivisa in 2 sessioni da 4. Alla prima sessione sono presenti
tutti i ruoli principali e l’obiettivo è quello di estrarre i tasks che si andranno a
svolgere nel corso dello Sprint, ovvero si crea lo Sprint Backlog. Nella seconda
sessione sono presenti solo i membri del team e vengono definiti i tempi e le
strategie per lo svolgimento dei tasks scelti.
• Sprint Review Meeting e Sprint Retrospective: consiste nella fase di
conclusione. Nella prima riunione, della durata di 4 ore circa, si analizza
il lavoro svolto e quello che invece non è stato completato e si presentano
gli incrementi del prodotto agli Stakeholders sotto forma di demo. Nella
seconda riunione invece tutti i membri del team riflettono sullo Sprint appena
terminato, ci si chiede cosa è andato bene e cosa può essere migliorato nel
prossimo Sprint, questo incontro è presupposto durare circa 3 ore.
Meeting
Per la natura stessa della metodologia Scrum, è fondamentale che tutti gli individui
si comportino in conformità alla direzione del team, pertanto ogni giorno sono
organizzati due incontri: il Daily Scrum e lo Scrum of Scrums. Il Daily Scrum è
un incontro dove tutti possono partecipare, ma solo i pigs possono parlare, ha una
durata specifica di 15 minuti e durante il meeting si cerca di rispondere a domande
come “cosa hai fatto rispetto a ieri?”, “cosa intendi fare oggi?”, “hai incontrato
particolari problemi?”. Lo Scrum Master ha il compito di facilitatore: deve prendere
in considerazione questi problemi e stabilire come possono essere affrontati. Lo
18
2.3. FDD
Scrum of Scrums invece è un incontro sempre time-boxed, che ha luogo sono
per progetti che coinvolgono più team di sviluppo, ed al quale partecipano solo i
rappresentanti di ogni team che si aggiornano sullo stato attuale del lavoro e su
direzioni future. Nel caso ci fossero pezzi di software da trasferire da un team
all’altro, questo è il luogo per discuterne.
Artefatti
Durante la fase di progettazione di tutte le metodologie agili il team e gli altri core
roles producono dei documenti necessari per avanzare alle iterazioni successive; gli
Artefatti di Scrum includono il Product Backlog, il Release Burndown, lo Sprint
Backlog e lo Sprint Burndown.
Gli artefatti di Burndown sono grafici che visualizzano pubblicamente il lavoro che
rimane da fare in una determinata fase, in particolare lo Sprint Burndown misura
la quantità di elementi residui di uno Sprint Backlog nel corso di uno Sprint e viene
aggiornato ogni giorno, mentre il Release Burndown misura la quantità residua di
Product Backlog rispetto al piano di rilascio (Release Plan) e viene aggiornato solo
alla fine di ogni Sprint.
Considerazioni finali sul metodo Scrum
1. Il cliente partecipa attivamente (Product Owner) alla progettazione del software.
2. Si producono frequenti rilasci (demo) che il cliente stesso può apprezzare
durante lo Sprint Review Meeting alla fine di ogni sprint.
3. La stretta e frequente collaborazione di tutti gli individui fa si che eventuali
rischi emergano appena rilevati; questo permette di affrontare con prontezza
i problemi che si incontrano risparmiando tempo.
4. Non solo è un metodo agile, ma richiede anche poco tempo e pochi sforzi per
essere adottato.
5. Fra le tecniche agili adottate nello Scrum emergono il Cross-functional Team
e il Time Boxing.
2.3
FDD
Il feature driven development è una metodologia agile, ideata da Jeff De Luca e
Peter Coad, che propone una robusta fase di analisi e progettazione integrata con
un modello di sviluppo agile, è particolarmente indicato per lo sviluppo di progetti
di dimensioni medio-grandi. Come s’intuisce dal nome è una forma di sviluppo
guidata dalle funzionalità richieste e necessarie del programma e si prefigge come
scopo principale di rilasciare software tangibile e funzionante in maniera sistematica.
19
2.3. FDD
Fasi dell’FDD
L’FDD è un processo model-driven basato su iterazioni corte che consiste di 5 fasi
principali.
• Fasi sequenziali, stile waterfall
1. Develop Overall Model
2. Build Feature List
3. Plan by Feature
• Fasi iterative di durata massima di tre settimane
4. Design by Feature
5. Build by Feature
Develop Overall Model Il progetto inizia con una stesura ad alto livello degli
obiettivi del sistema software ed il suo campo di applicazione. A seguire viene
fatto uno studio approfondito dei domini, dei campi con i quali il software avrà
a che fare e diversi gruppetti giungono separatamente ad una prima modellazione
di questi domini. Questi gruppi si confrontano e viene scelto una o un in’insieme
delle modellazioni prodotte dai gruppi per ogni dominio; l’insieme di questi modelli
produce l’overall model che sta alla base di tutte le fasi successive, come descritto
in Tab. 2.1.
Sub-activity
Form Modeling
Team
Conduct
Domain Walkthrough
Study
Documents
Develop Small
Group Models
Develop Team
Model
Refine Overall
Object Model
Write
Notes
Model
Description
The MODELING TEAM comprises permanent members from the domain and development areas, specifically the domain experts and the chief programmers. Other
project staff members are then rotated through the modeling sessions so that everyone
gets a chance to participate and to see the process in action.
A domain expert gives a DOMAIN OVERVIEW of the domain area to be modeled.
This should also include information that is related to this DOMAIN AREA but not
necessarily a part of its implementation.
Optionally the team studies available REFERENCE or REFERENCED REQUIREMENTS documents such as object models, functional requirements (traditional or
use-case format), data models, and user guides.
Forming groups of no more than three, each SMALL GROUP will compose a SMALL
GROUP MODEL in support of the domain area. The Chief Architect may propose
a ´strawman´ model to facilitate the progress of the teams. A member from each
small group presents that groups proposed model for the domain area. The Chief
Architect may also propose further model alternatives.
The MODELING TEAM selects a proposed TEAM MODEL or composes a model
by merging ideas from the proposed models.
Every so often, the OVERALL MODEL, consisting of an overall SEQUENCE DIAGRAM and a CLASS DIAGRAM, is REFINED with the new model shapes produced
by iterations of the ‘Develop Team Model’ task above.
EXPLANATORY NOTES on detailed or complex model shapes and on significant
model alternatives are made for future reference by the project.
Table 2.1: Sub-activities caratteristiche della fase di Develop Overall Model.
Build Feature List La conoscenza acquisita durante la fase iniziale di modellazione è usata per identificare una lista di funzionalità. Questo è fatto decomponendo il dominio di applicazione del software in aree per argomenti comuni. Le
funzionalità all’interno di queste aree sono formalizzate a partire dalle richieste del
20
2.3. FDD
cliente tipicamente espresse nella forma azione-risultato-oggetto (calcola il totale dei
costi, valida la password dell’utente). Le funzionalità così elencate non dovrebbero
richiedere più di 2/3 settimane di lavoro per essere completate, oppure dovrebbero
essere separate in diversi pezzi. Questa fase è descritta in dettaglio in Tab. 2.2.
Sub-activity
Form Features
List Team
Build Features
List
Description
The FEATURE LIST TEAM comprises the chief programmers from the MODELING
TEAM in the process ‘Develop Overall Model’.
The FEATURE LIST TEAM shall identify the FEATURE LIST using the knowledge
obtained from the process ‘Develop Overall Model’. This is a simple functional decomposition into SUBJECT AREAS that come from the partitioning of the domain
by the domain experts for their domain area walkthroughs in the process ‘Develop
Overall Model’. It is decomposed into SUBJECT AREAS that comprise BUSINESS
ACTIVITIES that comprise BUSINESS ACTIVITY steps (FEATURES).
Table 2.2: Sub-activities caratteristiche della fase di Build Feature List.
Plan by Feature Ora la lista delle funzionalità è completa, il passo successivo è produrre un piano di sviluppo, questa procedura è dettagliata in Tab. 2.3.
L’assegnazione delle responsabilità è fatto ordinando ed assegnando funzioni, o insiemi di funzioni, come classi ai chief programmers.
Sub-activity
Form Planning
Team
Determine Development Sequence
Description
The PLANNING TEAM comprises the development manager plus the chief programmers.
The main tasks in the process ‘Plan By Feature’ are not a strict sequence. Like many
PLANNING activities they are considered together, with REFINEMENTS made
from one or more tasks and then considering the others again. The PLANNING
TEAM shall assign a DATE (month and year only) for completion of each BUSINESS
ACTIVITY. The identification of the BUSINESS ACTIVITY and the completion
DATE (and thus the DEVELOPMENT SEQUENCE) is based on:
•
•
•
•
•
Dependencies between FEATURES in terms of CLASSES involved;
Balancing load across CLASS OWNERS;
The complexity of the FEATURES to be implemented;
Bringing forward high-risk or complex BUSINESS ACTIVITIES;
Consideration of any external (visible) milestones such as betas, previews,
feedback checkpoints and the "whole products" that satisfy such milestones.
Assign
Business Activities
to Chief Programmers
The PLANNING TEAM shall assign chief programmers as owners of BUSINESS
ACTIVITIES. The assignment is based on:
Assign Classes
to Developers
The PLANNING TEAM shall assign developers as CLASS OWNERS. Developers
own multiple CLASSES. The assignment of CLASSES to developers is based on:
• The DEVELOPMENT SEQUENCE;
• Dependencies between FEATURES in terms of CLASSES involved;
• Balancing load across CLASS OWNERS (remember that chief programmers
are also CLASS OWNERS);
• The complexity of the FEATURES to be implemented.
•
•
•
•
Balancing load across developers;
The complexity of the CLASSES;
The usage (e.g. high-use) of the CLASSES;
The DEVELOPMENT SEQUENCE.
Table 2.3: Sub-activities caratteristiche della fase di Plan by Feature.
21
2.3. FDD
Design by Feature Per ogni funzione è prodotto un design package. Un chief
programmer seleziona un gruppo ristretto di funzionalità che devono essere sviluppate nella prossima iterazione (tipicamente 2/3 settimane). Insieme ai corrispettivi
responsabili per quella classe, il chief programmer produce una sequenza dettagliata
di diagrammi per ogni funzionalità e affina la qualità dell’overall model. A questo
punto i prologhi delle classi e dei metodi sono scritti ed alla fine viene effettuato una
verifica su tutta la procedura di design. Dettagli a riguardo di questa fase possono
essere trovati in Tab. 2.4.
Sub-activity
Form Feature
Team
Conduct
Domain Walkthrough
Study
enced
ments
Develop
quence
gram(s)
Refine
Model
ReferDocuSeDia-
Object
Write
Class
and
Method
Prologue
Design Inspection
Description
The Chief Programmer identifies the CLASSES likely to be involved in the design
of this set of FEATURES and updates the FEATURE database accordingly. From
the CLASS OWNER LIST, the Chief Programmer identifies the developers needed
to form the FEATURE TEAM. As part of this step, the Chief Programmer creates
a new DESIGN PACKAGE for the FEATURES(S) as part of the work package.
The domain expert gives a DOMAIN OVERVIEW of the domain area for the FEATURE to be designed. This should also include domain information that is related to
the FEATURE but not necessarily a part of its implementation. This is an optional
task based on the complexity of the FEATURE and/or its interactions.
The FEATURE TEAM studies the REFERENCED REQUIREMENT(S) for the
feature to be designed, all COVERING MEMOS, screen designs, external system
interface specifications and any other supporting documentation. This is an optional
task based on the complexity of the FEATURE and/or its interactions.
Develop the SEQUENCE DIAGRAM(S) required for the FEATURE to be designed.
The diagram files should be checked into the version control system. Any ALTERNATIVE DESIGNS, design decisions, requirements clarifications and EXPLANATORY
NOTES are also recorded and written up in the DESIGN ALTERNATIVES section
of the DESIGN PACKAGE.
The Chief Programmer creates a FEATURE TEAM Area for the FEATURE(S). This
area is either a directory on the file server or a directory on their PC that is backed
up to the server by the Chief Programmer as required or utilizes work area support
in your version control system. The purpose of the FEATURE TEAM Area is that
work in progress by the FEATURE TEAM can be shared and is visible amongst the
FEATURE TEAM but is not visible to the rest of the project. The Chief Programmer
makes some REFINEMENTS on the model to add new / updated CLASSES, methods, attributes and/or to make changes to existing CLASSES, methods or attributes
based on the SEQUENCE DIAGRAM(S) defined for the FEATURE(S). This results
in the implementation language source files being updated in the FEATURE TEAM
Area. The Chief Programmer creates model diagrams in a publishable format. These
files should be checked into the version control system and submitted for publishing
on the project intranet.
Using the updated implementation language source files from the ‘Refine Object
Model’ task in the shared FEATURE TEAM Area, the development owner of each
CLASS writes the CLASS AND METHOD PROLOGUE for each item defined by the
FEATURE and SEQUENCE DIAGRAM(S). This includes parameter types, return
types, exceptions and messages. Once each developer has completed this task, the
Chief Programmer generates the API documentation using <your tool> and submits
it for publication on the project intranet.
A design inspection with the FEATURE TEAM members or with other project members is held. The decision to inspect within the FEATURE TEAM or with other
project team members is that of the Chief Programmer. On acceptance a TODO
TASK LIST is generated per affected CLASS, and each team member adds their
tasks to their calendar task list. The Chief Programmer must also merge changes
from the shared FEATURE TEAM Area into the change control system.
Table 2.4: Sub-activities caratteristiche della fase di Design by Feature.
Build by Feature Dopo che la fase di design è avvenuta con successo si passa
ad un’attività più rivolta a produrre una funzione completa e che il cliente possa
valutare. I responsabili per la classe sviluppano il vero codice ed un unità di testing
ispeziona il codice. Se si ritiene l’iterazione valida, la funzionalità appena com-
22
2.3. FDD
pletata viene promossa ed integrata nella versione aggiornata del software, come
mostrato in Tab. 2.5.
Sub-activity
Implement
Classes
and
Methods
Inspect Code
Conduct
Test
Unit
Promote
Build
to
Description
The development CLASS owners will perform the IMPLEMENTATION of the items
necessary to satisfy the requirements of their CLASS for this FEATURE.
A CODE INSPECTION with the FEATURE TEAM members or with other project
members is held either before or after the unit test task. The decision to inspect
within the FEATURE TEAM or with other project team members is that of the
Chief Programmer. The decision to inspect before or after unit test is that of the
Chief Programmer.
The development CLASS owner tests their code to ensure all requirements of their
CLASS are satisfied. The Chief Programmer determines what FEATURE TEAMlevel unit testing is required (if any). That is, if any testing across the CLASSES
developed for this FEATURE is required.
PROMOTION to the BUILD of CLASSES is only possible after a successful CODE
INSPECTION. The Chief Programmer tracks the individual CLASSES being promoted, through feedback from the developers, and is the integration point for the
entire FEATURE.
Table 2.5: Sub-activities caratteristiche della fase di Build by Feature.
È riportato in Fig. 2.3 l’activity diagram complessivo delle fasi sopra descritte.
Milestones
In quanto le funzionalità sono piccole, completarne una è un compito relativamente
veloce. Per un report accurato dello stato dello sviluppo è comunque importante
segnare il progresso fatto per ogni feature. FDD definisce quindi sei milestone per
ogni funzionalità che devono essere completati consequenzialmente. Le prime tre
milestones sono compltate durante la fase di Design By Feature, mentre le ultime
tre sono completate nella fase di Build by Feature. Per aiutare a tenere traccia
del progresso viene assegnata una percentuale ad ognuna di queste milestones. In
Tab. 2.6 sono riportate le milestones e le relative percentuali di completamento.
Domain Walkthrough
1%
Design
40%
Design Inspection
3%
Code
45%
Code Inspection
10%
Promote To Build
1%
Table 2.6: Percentuali di progressione assegnate a ciascuna milestone.
Best practices
Feature-Driven Development è costruito attorno ad un insieme di best practices
riconosciute anche a livello industriale derivanti dall’ingegneria del software. Queste
pratiche sono tutte guidate dal punto di vista dell’utente ed è la combinazioni di
tutte queste pratiche che rende l’FDD così potente.
Domain Object Modeling Domain Object Modeling consists of exploring and
explaining the domain of the problem to be solved. The resulting domain
object model provides an overall framework in which to add features.
23
2.3. FDD
Figure 2.3: Activity Diagram complessivo del processo FDD.
24
2.3. FDD
Developing by Feature Any function that is too complex to be implemented
within two weeks is further decomposed into smaller functions until each subproblem is small enough to be called a feature. This makes it easier to deliver
correct functions and to extend or modify the system.
Individual Class (Code) Ownership Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner. The owner is
responsible for the consistency, performance, and conceptual integrity of the
class.
Feature Teams A feature team is a small, dynamically formed team that develops
a small activity. By doing so, multiple minds are always applied to each design
decision and also multiple design options are always evaluated before one is
chosen.
Inspections Inspections are carried out to ensure good quality design and code,
primarily by detection of defects.
Configuration Management Configuration management helps with identifying
the source code for all features that have been completed to date and to
maintain a history of changes to classes as feature teams enhance them.
Regular Builds Regular builds ensure there is always an up to date system that
can be demonstrated to the client and helps highlighting integration errors of
source code for the features early.
Visibility of progress and results By frequent, appropriate, and accurate progress
reporting at all levels inside and outside the project, based on completed work,
managers are helped at steering a project correctly.
Parking Lot Diagram
Esiste uno strumento che serve a visualizzare il progresso del progetto in fase di
implementazione: il Parking Lot Diagram. Seconda questa tecnica ad ogni feature
set è assegnata una scheda che raccoglie le informazioni principali sul suo stato di
avanzamento: il nome, il chief programmer, il numero di features che contiene, la
percentuale di completamento. Un esempio di tale scheda è mostrata in Fig. 2.4.
Figure 2.4: Una singola PLD card, associata ad un set di features.
25
2.4. Dynamic System Development Method
Ma la vera forza di questa tecnica è messa in evidenza quando queste feature sets
sono combinati in feature areas dando un’idea globale dello stato di avanzamento
del progetto, come mostrato in Fig. 2.5.
Figure 2.5: Una lavagna divisa in aree ed in features sets che mostra il livello
globale di avanzamento del progetto.
2.4
Dynamic System Development Method
Questo metodo può essere presentato come un’evoluzione del concetto di RAD
(Rapid Application Development), ma rispetto ad esso rivela una struttura molto
più organizzata. Gli obiettivi rimangono comunque molto chiari: tight schedule e
tight budget. Tutte le volte che un progetto software deve rispettare rigorosamente
i tempi di consegna ed i soldi a disposizione, questo metodo pare essere il più
indicato e pare essere quello che più di altri cerca di garantire il rispetto dei vincoli.
Chiaramente questo approccio non si ritiene adatto a tutti i tipi di progetto: infatti
non sempre è vantaggioso scegliere di rinunciare alla qualità a vantaggio dei tempi
e dei costi, ad esempio in applicazioni con pesanti implicazioni nel campo della
sicurezza. L’idea alla base di questa tecnica è una legge di Pareto: l’80% delle
esigenze del cliente sono tipicamente soddisfatte dal 20% delle funzionalità; occorre
puntare quindi a sviluppare il 20% in modo ottimale e veloce, lasciando al restante
80% delle funzionalità il tempo ed il budget rimanente.
Principi fondanti
I principi fondanti di questa metodologia sono il coinvolgimento dell’utente nel
ciclo di sviluppo, esso infatti è la chiave principale per svolgere un progetto in
modo efficiente ed efficace, dove sia gli utenti che gli sviluppatori si trovano nello
stesso posto in modo che le decisioni possano essere prese in modo tempestivo,
l’indipendenza del team di progetto ovvero il team di progetto deve essere
26
messo nelle condizioni di prendere decisioni importanti senza dover attendere autorizzazioni di livello più alto, l’individuazione delle funzionalità più critiche
secondo il principio che rilasciare un software buono presto è più apprezzabile che
qualcosa di perfetto in tempi inaccettabili per il cliente ed infine uno sguardo attento alle esigenze correnti del clliente: il software deve innanzittuto coprire
i bisogni reali attuali, le generalizzazioni e le astrazioni potranno essere fatte se ci
sarà tempo e denaro.
Principi operativi
Ci sono inoltre cinque punti operativi: lo sviluppo deve essere iterativo ed incrementale guidato dagli user-feedback., tutti i cambiamenti durante lo sviluppo devono
essere reversibili, i requisiti e gli obiettivi di alto livello (generici) devono essere
baselined (consolidati, costituire un punto di partenza) prima che inizi il progetto,
il collaudo deve essere condotto durante l’intero ciclo di vita del progetto, infine
la comunicazione e la coperazione fra tutti i responsabili del progetto deve essere
efficace.
Oltre questi principi vengono fatte anche alcune assunzioni, nelle quali si rispecchia
la validità del modello DSDM: è innanzittutto necessario essere consapevoli che
nessun sistema è perfetto al primo tentativo, ma non è neanche necessario che lo
sia, infatti si suppone vero che l’80% delle esigenze del cliente possano essere soddisfatte nel 20% delle funzionalità. Siccome il prezzo da pagare, in termini di qualità, è
elevato, è necessario che il rilascio del software sia on-time ed on-budget, altrimenti
non ne sarà valsa la pena. Il processo di sviluppo deve essere ben strutturato, solido
ma agile: ogni fase ha come unico requisito quello di essere abbastanza completo
per permettere l’avviamento dello step successivo; parte della strutturazione del
processo si deve al fatto che anche il project managment deve essere considerato,
lo stesso deve premiare il rilascio del software piuttosto che il completamento dei
task. La valutazione del rischio riguarda le funzionalità da rilasciare (tralasciando
tutti gli altri tipi di rischi). Le stime devono basarsi sulle funzionalità realizzate,
non sulle linee di codice.
Fasi principali del processo DSDM
Fatte queste premesse il metodo si articola in 3 fasi:
1. Pre-project
2. Project life-cycle
(a)
(b)
(c)
(d)
(e)
Feasibility study
Business study
Functional model iteration
Design and build iteration
Implementation
3. Post-project
27
Pre-project e Post-project Nella fase di Pre-project viene stabilito a grandi
linee cosa il progetto dovrà fare, vengono acquisiti i fondi: è un’attività preparatoria, non meglio precisata o strutturata. Una volta stabilito che il manager crede nel
progetto e ci finanzierà, possiamo iniziare il progetto. Nel Post-project invece finiscono tutte quelle attività che non vogliamo far rientrare nel project life-cycle (anche
se altri metodi agili li considererebbero tali): deve garantire il funzionamento del
software, vengono eventualmente corretti alcuni errori, viene eseguita una fase di
manutenzione, ed eventualmente possono venire estese le funzionalità del software.
Feasibility study In questo primo stage occorre decidere se il metodo DSDM è
adatto al tipo di progetto ed alle esigenze del cliente. Viene prodotto un feasibility
report, un documento in cui si spiegano le ragioni per la scelta di questo metodo
e viene rilasciato un global outline plan, una prima indicazione approssimativa
delle fasi e dei tempi dello sviluppo. Può essere allegato anche un risk-log, ovvero
uno strumento per conoscere a priori quali potranno essere i rischi ai quali questo
progetto è esposto.
Business study Questo secondo stage viene spesso considerato insieme al feasability study, ed insieme al pre-project formano la fase di preparazione all’implementazione
effettiva delle funzionalità, proprio perché anche il DSDM è comunque un metodo
agile, queste fasi non dovrebbero durare in tutto più di 2/3 settimane. In particolare
il business study deve raccogliere i primi requisiti generali, definire le priorità dello
sviluppo (quel 20% delle funzionalità di Pareto) ovvero produrre la prioritized requirement list ed una business area definition (focalizzare il contesto in cui questo
sistema si innesta, quindi uno studio sui bisogni che un software di questo tipo
dovrebbe coprire). Altri obiettivi di questo stage sono la produzione di una system
architecture (in termini di sottosistemi) ed un prototyping plan (suddivisione in
moduli software).
Figure 2.6: Cicli iterativi all’interno di un processo DSDM.
28
Functional Model Iteration I requisiti che sono stati individuati nelle fasi
precedenti sono ora convertiti in un modello funzionale. Questo modello consiste di
entrambi un prototipo funzionante ed alcuni modelli. La prototipazione è una delle
tecniche chiave all’interno di questa fase poiché aiuta ad integrare il contributo degli
utenti e del cliente all’interno del progetto. Il prototipo così sviluppato è sottoposto
alla visione di diversi utenti; in favore di garantire qualità, la fase di testing è implementata ad ongi iterazione DSDM anche se la maggior parte è svolta all’interno
del Functional Model Iteration, che può essere suddiviso in quattro sottofasi:
1. Identify Functional Prototype: determinare quali funzionalità implementare
nel prototipo che risulterà da questa iterazione.
2. Agree Schedule: mettersi d’accordo su come e quando sviluppare queste funzionalità.
3. Create Functional Prototype: sviluppo effettivo del prototipo, con annesso
un confronto dettagliato con i prototipi funzionali di iterazioni precedenti ed
applicazioni di eventuali modifiche.
4. Review Prototype: controllo della correttezza del prototipo realizzato. Questo
può essere fatto lasciandolo testare all’utente finale, utilizzando poi i test logs
e il feedback da parte dello user per generare il functional prototyping review
document.
Il risultato di queste fasi sono un modello funzionale ed un prototipo funzionale
che insieme rappresentano tutte le funzionalità che potrebbero essere utilizzate alla
fine di questa iterazione, pronte per essere testate dall’utente. Successivamente
a questo, viene aggiornata la lista dei requisiti, eliminando i task che sono stati
realizzati e ripensando eventuali priorità che necessitano di essere modificate.
Design and Model Iteration Lo scopo principale di questa iterazione è di
integrare i componenti funzionali della fase precedente all’interno di un sistema che
soddisfa i bisogni dell’utente. Ancora una volta il testing è fondamentale in questa
fase. Questo stage pul essere suddiviso in quattro sottofasi:
1. Identify Design Prototype: identificare requisiti funzionali e non-funzionali
che devono essere testati nel sistema.
2. Agree Schedule: mettersi d’accordo su come e quando sviluppare queste funzionalità.
3. Create Design Prototype: creazione di un sistema che può essere gestito in
modo sicuro dall’utilizzatore tramite un accesso quotidiano. È qui che si
realizza il nuovo prototipo per questa iterazione partendo dall’ultima release
rilasciata.
4. Review Design Prototype: controllo della correttezza del sistema progettato.
I risultati per questo livello sono un Design Prototype (che l’utente testerà e che
verrà poi rilasciato all’iterazione successiva) ed una documentazione utente.
29
2.5. XP
Implemetation Nella fase di implementazione, il sistema testato (con tanto di
utilizzatori e documentazione) è rilasciato al cliente così come suggerita un’attività
di formazione priore all’utilizzo del software. Il sistema che deve essere rilasciato
è stato controllato per includere i requisiti che sono stati fissati nelle fasi iniziali
del progetto. Anche la fase di implementazione può essere suddivisa in quattro
sottoparti:
1. User Approval and Guidelines: l’utente finale approva il sistema testato per
la sua implementazione e le sue linee guida.
2. Train Users: formare futuri utilizzatori del software.
3. Implement: installazione del software sulle macchine messe a disposizione
dall’utente finale.
4. Review Business: osserva l’impatto del software sviluppato nel contesto del
business, un problema centrare sarà quello di capire se il sistema incontra gli
obiettivi economici che erano stati stabiliti all’inizio del progetto.
Gli artefatti di questa fase sono un sistema distribuito on-location, utenti formati
e specializzati ed un documento di project revew del sistema.
MoSCoW
MoSCoW è una tecnica di prioritazzazione usata nello sviluppo di software per arrivare ad una comune comprensione con gli stakeholders sull’importanza dei singoli
requisiti. Le lettere maiuscole stanno per:
• M: MUST have this.
• S: SHOULD have this.
• C: COULD have this.
• W: WON’T have this.
2.5
XP
L’Extreme Programming (XP) è una metodologia agile di sviluppo del software che
si propone di migliorare la qualità del software a la sua reattività ai cambiamenti
frequenti dei requisiti descritti dal cliente. Come tutte le metodologie agili è caratterizzato da frequenti release in corte iterazioni, con le quali si cerca di aumentare
la produttività. La metodologia prende nome dall’idea che elementi comuni anche
alle altre metodologie agili sono presi e portato all’estremo secondo la teoria che se
qualcosa è buono, di più è meglio.
In realtà l’approccio XP è soggetto a parecchie critiche, anche da parte dei creatori stessi, che spaziano dalla possibile instabilità delle releases alla mancanza di
specifiche di un overall design e scarsa documentazione.
30
2.5. XP
Goals
La metodologia XP è descritta come una disciplina del software development che
organizza le persone allo scopo di produrre software di più alta qualità e più produttivamente. L’XP cerca di ridurre il costo delle modifiche che inevitabilmente
il cliente porta ad introdurre in fasi avanzate dello sviluppo tramite un numero
elevato di corte iterazioni. L’XP inoltre introduce un numero elevato di valori base,
principi e pratiche oltre quelle descritte nell’Agile Manifesto.
Principles
I principi che formano le basi della metodologia XP hanno lo scopo di velocizzare
il processo di sviluppo.
Feedback L’XP vede il feedback come il suo strumento più utile se utilizzato di
frequente in modo che il tempo che intercorre fre il completamento di task ed
il suo feedback siano critici per la comprensione e la modifica del task stesso.
Di conseguenza il cliente ha una visione chiara di come il sistema sta venendo
sviluppato ed ha la possibilità di cambiare in ogni momento direzione di alcune
decisioni. Anche il frequente uso di test partecipa all’idea di feedback.
Assuming simplicity Consiste nel trattare ogni problema come se la soluzione
fosse “estremamente” semplice. Tradizionalmente i metodi di sviluppo chiedono
di progettare il codice per la riusabilità, l’XP rifiuta questa idea; i sostenitori
dell’XP ritengono che fare grandi modifiche non sia efficiente, ma che tante
piccole modifice iterative ed incrementali siano di facile realizzazione.
Embracing change È il principio di accettare la filosofia delle modifiche continue. Tutto il ciclo di vita del progetto deve rimanere perennemente aperto
e disponibile ad eventuali modifiche che il cliente può richiedere.
Activities
L’XP descrive quattro attività base che sono compiute all’interno del processo di
sviluppo del software: coding, testing, listening and designing.
Coding I difensori di questa metodologia argomentano che l’unica vera parte importante del processo di sviluppo è la parte di coding. Senza il codice, non c’è
prodotto funzionante. Durante questa fase inoltre si acquisisce una conoscenza
più approfondita delle possibili problematiche e le soluzioni migliori vengono adottate: non solo, tramite l’utilizzo del codice anche problemi difficili da spiegare a
parole vengono formalizzati (perché la sintassi di un linguaggio di programmazione
è formale) nel codice e possono essere utilizzati come supporto nell’evidenziare un
problema od una soluzione. Il codice è sempre chiaro, conciso e la sua interpretazione è univoca, inoltre gli altri programmatori possono aggiungere i loro feedback
codificando anch’essi i loro pensieri a riguardo.
31
2.5. XP
Testing L’idea che l’XP ha riguardo questa fase è chiara: se un po’ di testing
può eliminare alcuni problemi, alcune falle, un bel po’ di testing ne può eliminare
un sacco. Il programmatore scrive tutti i test automatici che pensa siano necessari
per scoprire possibili incongruenze nel codice, se tutti i test finiscono con successo,
allora il codice è completo - ogni pezzo di codice scritto è testato prima di passare
alla fase successiva. Ci sono inoltre dei test di accettazione che devono verificare
che la comprensione dei requisiti dei programmatori fosse compatibile con quanto
intendeva il cliente.
Listening I programmatori devono ascoltare quali sono esattamente i bisogni del
cliente, quale business logic è necessaria. Devono capire questi bisogni abbastanza
bene da poter dare al cliente pareri tecnici riguardo i problemi che potrebbero o
meno essere risolti dal software. La comunicazione fra il cliente ed il programmatore
sarà poi approfondita nel Planning Game.
Designing Dal punto di vista della semplicità, uno potrebbe sostenere che lo
sviluppo di software non necessità niente di più che coding, testing e listening. In
effetti, se queste attività sono svolte bene il risultato è un sistema che funziona. In
pratica, questo non è mail il caso. Il sistema tende a diventare troppo complesso e
le dipendenze all’interno del progetto diventano sempre meno chiare: tutto questo
può essere evitato creando una design structure che organizza la logica del sistema.
Un buon design può evitare molte complicazioni ed il crearsi di inutili dipendenze,
ovvero cambiare una parte del sistema non richiede modifiche a valanga su altre
parti del sistema.
Values
L’XP riconosce come fondamentali cinque valori affinché la fase di progettazione e
sviluppo del software possa avvenire con successo:
1. Communication È consuetudine che il passaggio di conoscenza da un’attività
all’altra avvenga tramite documentazione nello sviluppo di grandi progetti,
al contrario l’XP incoraggia a confrontarsi spesso e verbalmente, poiché considerato più rapido ed efficiente. Il risultato è che tutto il team ha in ogni
momento la stessa visione sull’intero progetto che è, fra l’altro, la stessa visione che ha l’utente sul progetto. A tale scopo l’XP favorisce l’uso di design
semplici, metafore comuni, collaborazione fra utenti e programmatpri, comunicazione verbale frequente e feedback.
2. Simplicity L’XP suggerisce di partire con la soluzione più semplice, funzionalità extra possono essere aggiunte successivamente. Il focus più importante
è sui requisiti che devono essere sviluppati oggi, non quelli di domani, la settimana prossima o il mese prossimo (YAGNIN - “you ain’t gonna nedd it
now”). Per rendere il codice modificabile è però necessario tenerlo semplice e
ben strutturato.
3. Feedback Nell’XP ci sono diversi tipi di feedback: i feedback che vengono
dal sistema, tramite test specifici o test d’integrazione oppure i feedback
32
2.5. XP
dall’utente detti anche acceptance tests che misura se le funzionalità sviluppate erano veramente quelle che il cliente desiderava. È inoltre possibile che
anche il team di sviluppo produca dei feedback, quando ad esempio i clienti
propongono aggiunte di nuove funzionalità, un parere tecnico ed uno studio
di fattibilità è apprezzato.
4. Courage Questa metodologia chiede coraggio, soprattutto per i palesi rischi
ai quali apre, a partire dal fatto di programmare per oggi e non per domani.
Questo atteggiamento serve per evitare di perdersi in pianificazione e progettazioni che richiederebbero un sacco di tempo. Il coraggio permette agli
sviluppatori di sentirsi a proprio agio nel rimettere mano al proprio codice
quando sarà necessario. Un’altro esempio di coraggio è capire quando è il
momento di buttare via il codice e ripartire da capo: a volte è più veloce
che cercare di riorganizzarlo. Infine coraggio significa persistenza: per un
programmatore trovarsi bloccato su un problema complesso è all’ordine del
giorno, e magari il giorno dopo risolverlo velocemente, se si è stati persistenti.
5. Respect Il valore del rispetto include rispetto per gli altri e per se stessi. I
programmatori non dovrebbero mai fare modifiche che non permettono più di
compilare, che gravano su test già passati o che ritardano o vanificano il lavoro
di altri. Allo stesso tempo gli sviluppatori hanno rispetto per se stessi quando
cercano di lavorare dando il massimo di loro stessi nel realizzare un software
di alta qualità, implementando sempre la soluzione migliore. Inoltre adottare
i quattro valori precedenti porta a guadagnare il rispetto degli altri. Nessuno
nel team dovrebbe sentirsi ignorato o poco apprezzato. Questo garantisce un
alto livello di motivazione ed incoraggia alla lealtà verso il proprio team e
verso gli obiettivi del progetto. Questo valore dipende molto dagli altri.
Rules
Mentre tutte le altre metodologie introducono i concetti di fasi e specificano le
iterazioni necessarie durante il ciclo di sviluppo del progetto, i sostenitori dell’XP
giudicano che l’unico modo per poter apprezzare una metodologia è seguire alcune
chiare regole. Esistono due categorie di regole nell’XP: rules of engagement e rules
of play.
Rules of engagement Nel baseball, le rules of engagement potrebbero essere
pensate come quelle che definiscono la dimensione del campo, il numero di giocatori
di ogni squadra, il metodo di segnare punti, ... Il gioco non può iniziare senza
queste. Queste regole sono prominenti quando è definito un contesto ed il progetto
deve iniziare, ma sono anche presenti durante tutta la durata dell’attività anche
se a causa dell’intensità delle rules of play durante il gioco queste diventano meno
evidenti. Senza di esse, non si ha un gioco identificabile ma non sono loro che
definiscono le attività minuto per minuto, definiscono solo l’ambiente e le condizioni
di lavoro.
E1. Un team consiste di un gruppo di persone dedicate alla produzione del software.
Il prodotto può o meno essere parte di un prodotto più grande. Ci possono
33
2.5. XP
essere tanti ruoil all’interno del team, ma ci devono per forza essere almeno
un cliente ed uno sviluppatore.
E2. Il cliente deve definire e continuamente affinare gli obiettivi e le priorità basandosi su stime ed altre informazioni fornite dagli sviluppatori ed altri membri
del team. Gli obiettivi devono essere definiti in termini di cosa e non di come.
E3. Il cliente deve essere sempre reperibile e disponibile a fornire informazioni su
richiesta per assistere gli sviluppatori. Il cliente è parte integrante del team.
E4. In un qualsiasi momento, qualsiasi membro del team deve essere in grado
di misurare lo stato di avanzamento del team nella direzione degli obiettivi
definiti dal cliente.
E5. Il team deve agire come un efficace rete sociale, ovvero:
• Comunicazioni oneste che portano a migliorare la conoscenza condivisa.
• Minima distanza fra ciò che serve al team per fare progressi e le persone/risorse che possono colmare questi bisogni.
• Appiattimento (condivisione) di autorità e responsabilità.
E6. Il Timeboxing è usato per identificare i segmenti di sviluppo ed ogni segmento
non deve durare più di un mese.
Rules of play Le rules of play entrano in gioco all’interno delle rules of engagement ed insieme definiscono le attività minuto per minuto. Le regole del gioco nel
baseball definiscono i fondamentali, i falli, le strategie consuetudinali, ... Se un
battitore si vede arrivare contro una palla a 90 miglia orarie, non pensa a quanti
giocatori devono essere in campo in quel momento, penserà piuttosto a batterla il
più lontano possibile, così come il giocatore che cercherà di recuperare quella palla,
prima penserà a prenderla al volo e solo dopo cercherà di capire se tutti si sono
mossi secondo le regole di contorno.
P1. Il lavoro prodotto deve essere continuamente validato tramite testing.
P2. Scrivi i test prima di codificare, applica il pair-programming ed il code refactoring.
P3. Tutto il codice scritto che potenzialmente andrà a finire nella versione finale
deve:
• Passare tutti i test.
• Esprimere in modo chiaro gli obiettivi nel codice
• Non contenere duplicazioni.
• Non contenere parti superflue.
P4. Proprietà comune, non ci sono classi, metodi od insieme di funzionalità riconducibili a singole responsabilità. Tutti devono avere autorità sul codice ed
almeno due persone nel team devono avere tutte le conoscenze necessarie per
svolgere ogni compito.
34
2.5. XP
Practices
L’XP accetta ed addirittura propone una lista di pratiche, di tecniche che ritiene
importante seguire per lavorare a buoni livelli di progettazione e sviluppo:
• Planning the game. È il principale processo di pianificazione dell’XP ed è
un incontro che avviene una volta per iterazione.
• Small releases.
• Shared metaphor. È importante avere un’idea comune del progetto, una
metafora è un po’ come una storiella che tutto il team deve saper raccontare.
• Simple design. Significa che “simple is best”, si ritiene necessario rappresentare solo gli aspetti utili e dove possibile graficamente.
• Code refactoring.
• Automatic testing.
• Pair programming.
• Collective code ownership.
• Design improvement. Quando si formano troppe dipendenze ed il codice
non è più facilmente scalabile, il sistema necessità di essere rivisto a partire
dal code refactoring ed eventualmente cambiare archietettura, rendendola più
semplice e generica.
• Continuos integration. Tutto il team deve lavorare constantemente sull’ultima
versione del software, si tratta di tenere sincronizzato il proprio lavoro con
quello del gruppo.
• Sustainable pace. Si tratta di mantenere costante la produttività, è consigliato a tale scopo non eccedere le quaranta ore settimanali.
• Coding standards. È un accordo sull’insieme di regole che verranno utilizzate nel corso del progetto.
Criticisms
• A methodology is only as effective as the people involved, Agile does not solve
this
• Often used as a means to bleed money from customers through lack of defining
a deliverable
• Lack of structure and necessary documentation
• Only works with senior-level developers
• Incorporates insufficient software design
• Requires meetings at frequent intervals at enormous expense to customers
• Requires too much cultural change to adopt
• Can lead to more difficult contractual negotiations
• Can be very inefficient—if the requirements for one area of code change
through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of
code is expected to be written once.
• Impossible to develop realistic estimates of work effort needed to provide
a quote, because at the beginning of the project no one knows the entire
scope/requirements
35
2.5. XP
36
Chapter
3
Sistemi di qualità
3.1
ISO 9001
3.2
Capability Maturity Model integration
Il Capability Maturity Model Integration nell’ingegneria del software è uno standard
dei requisti di processo aziendali, sviluppato dal Carnegie Mellon University.
Rispetto alla certificazione ISO sussistono due principali differenze: prima di tutto
è una valutazione della qualità pensata per aziende che lavorano esclusivamente nel
mondo del software, si pone come obiettivo il miglioramento continuo dei processi di
progettazione, implementazione e supporto. La seconda differenza è che il CMMi
non è una vera e propria certificazione che può essere ottenuta tramite aziende
competenti, ma è una valutazione che spetta al SEI (Software Engineering Institute)
della CMU il quale rilascierà un appraisal.
Questo resoconto, non ha valore di certificazione della qualità sul mercato o all’esterno
dell’azienda, ma serve come documento interno per raccogliere informazioni, rilevare la qualità e suggerire metodologie per migliorare tutti i processi aziendali di
una tipica software house.
Lo standard è composto da tre modelli, ognuno di questi modelli si pone nelle
condizioni di valutare determinati aspetti dei processi aziendali:
• Model for Development (2006), si preoccupa di analizzare il processo di progettazione ed implementazione del software
• Model for Acquisition (2007), regolamenta l’approvigionamento di parti di
software o hardware non prodotti internamente
• Model for Services (2009), si occupa di valutare i servizi rivolti al cliente nella
fase di post-produzione
Noi prendiamo in considerazione solo il Development Model, il quale tratta essen-
37
3.2. Capability Maturity Model integration
Sistemi di qualità
zialmente di metodologie di valutazione per lo sviluppo di software.
Process areas
L’analisi della qualità dell’azienda che si sottopone alla valutazione passa per 22
process areas le quali indicano gli aspetti di sviluppo del prodotto e dei servizi che
devono essere implementati dai processi organizzativi. Dentro queste aree vengono
sviscerati tutti gli aspetti e tutti i processi che possono caratterizzare il core business di una software house. Queste 22 aree sono a loro volta suddivise in quattro
settori: Process Management, Project Management, Engineering e Support, come
mostrato in Tab. 3.1.
Process Managment
Organizational Process Definition (OPD)
Project Monitoring and Control (PMC)
Project Planning (PP)
Quantitative Project Management (QPM)
Requirements Management (REQM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
Engineering
Product Integration (PI)
Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Project Managment
Integrated Project Management (IPM)
Organizational Process Focus (OPF)
Organizational Performance Management (OPM)
Organizational Process Performance (OPP)
Organizational Training (OT)
Support
Causal Analysis and Resolution (CAR)
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
Table 3.1: Le 22 process areas divise nei quattro settori.
Ogni process area è rappresentata a partire dai suoi componenti obbligatori, dai
suoi componenti auspicati e da informazioni aggiuntive, come mostrato in Fig. 3.1.
Figure 3.1: Paradigma di descrizione dei componenti di un generico process area.
38
Sistemi di qualità
Vediamo un esempio semplificato di descrizione di una process area, il Configuration
Management.
Purpose Statement: The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration
audits.
Related Process Areas: Refer to the Project Monitoring and Control process
area for more information about monitoring the project against the plan and managing corrective action to closure. Refer to the Project Planning process area for
more information about developing a project plan.
Specific goals and practices:
SG 1 Establish Baselines
SP 1.1 Identify Configuration Items
SP 1.2 Establish a Configuration Management System
SP 1.3 Create or Release Baselines
SG 2 Track and Control Changes
SP 2.1 Track Change Requests
SP 2.2 Control Configuration Items
SG 3 Establish Integrity
SP 3.1 Establish Configuration Management Records
SP 3.2 Perform Configuration Audits
Generic goals and practices:
GG 1 Achieve Specific Goals
GP 1.1 Perform Specific Practices
GG 2 Institutionalize a Managed Process
GP 2.1 Establish an Organizational Policy
GP 2.2 Plan the Process
..
.
GP 2.10 Review Status with Higher Level Management
È importante notare che mentre i goal e le pratiche specifiche sono appunto “specifiche” di ogni area, quelle generiche sono trasversali a tutte.
Valutazione della qualità
Una volta specificati gli obiettivi ideali e le metodologie necessarie per raggiungerli,
ci occorre un criterio per valutare lo stato attuale rispetto a quanto è stato prefissato. Lo standard presenta due diverse rappresentazioni della qualità, due misure
complementary, la capability e la maturity.
La capability esprime un giudizio specifico per ogni area, lavora pertanto al livello
di obiettivi e pratiche specifiche come mostrato in Fig. 3.2. Questo tipo di analisi
permette di concentrare l’attenzione su singoli processi e pertanto dividere anche la
complessità della valutazione, la diretta conseguenza è che questo tipo di valutazione
39
Sistemi di qualità
può essere effettuato molto frequentemente: da questa considerazione questo tipo
di valutazione prende il nome di continuous representation.
La maturity fa invece riferimento agli obiettivi ed alle pratiche generali, esso lavora
sul complesso delle process areas come mostrato in Fig. 3.3. Chiaramente questa
rappresentazione è più complicata perché più vasta, siccome non può essere fatta
frequentemente si parla di staged rapresentation.
Figure 3.2: Esempio di descrizione dei componenti di un generico Process Area.
Figure 3.3: Esempio di descrizione dei componenti di un generico Process Area.
La continuous representation è pensata per permettere all’azienda di focalizzarsi sui
processi specifici che sono considerati importanti per gli obiettivi di breve termine
o per le quali l’azienda ha assegnato un alto gradi di rischio; infatti non tutte
40
Sistemi di qualità
Level
Level
Level
Level
Level
Level
Level
0
1
2
3
4
5
CR Capability Levels
Incomplete
Performed
Managed
Defined
SR Maturity Levels
Initial
Managed
Defined
Quatitatively Managed
Optimizing
Table 3.2: Livelli di valutazione per le rappresentazioni del CMMi.
le aree hanno la stessa importanza, alcune sono fondamentali, ma altre sono solo
ottimizzazioni. La staged representation invece serve ad indicare una sequenza
standard di miglioramenti che l’azienda è chiamata a fare e può essere usata come
livello di comparazione fra diversi progetti o diverse aziende.
Questi due tipi di rappresentazioni si concretizzano comunque su una scala di livelli,
mostrata in Tab. 3.2.
Incomplete: an incomplete process is a process that either is not performed or
is partially performed. One or more of the specific goals of the process area are
not satisfied and no generic goals exist for this level since there is no reason to
institutionalize a partially performed process.
Performed: a performed process is a process that accomplishes the needed work
to produce work products; the specific goals of the process area are satisfied. Although capability level 1 results in important improvements, those improvements
can be lost over time if they are not institutionalized. The application of institutionalization helps to ensure that improvements are maintained.
Manged: a managed process is a performed process that is planned and executed
in accordance with policy; employs skilled people having adequate resources to
produce controlled outputs; involves relevant stakeholders; is monitored, controlled,
and reviewed; and is evaluated for adherence to its process description. The process
discipline reflected by capability level 2 helps to ensure that existing practices are
retained during times of stress.
Defined: a defined process is a managed process typically described more rigorously than at capability level 2. A defined process clearly states the purpose,
inputs, entry criteria, activities, roles, measures, verification steps, outputs, and
exit criteria. At capability level 3, processes are managed more proactively using
an understanding of the interrelationships of the process activities and detailed
measures of the process and its work products.
Quantitatively Managed: at maturity level 4, the organization and projects
establish quantitative objectives for quality and process performance and use them
as criteria in managing projects. A critical distinction between maturity levels 3
and 4 is the predictability of process performance.
Optimizing: at maturity level 5, an organization continually improves its processes
based on a quantitative understanding of its business objectives and performance
needs. The organization uses a quantitative approach to understand the variation
inherent in the process and the causes of process outcomes.
41
Sistemi di qualità
Avanzare fra i livelli di maturità di un progetto. Mentre è semplice ed
immediato esprimere una valutazione da 0 a 3 per le singole aree, non è altrettando
intuitivo dare una valutazione globale. Affinché il metodo sia rigoroso ed oggettivo,
sono stati fissati dei paletti: ad ogni area è stato assegnato un valore di criticità
da 1 a 5, più il livello di criticità è basso più l’area è critica. Ora diremo che il
nostro maturity level è passato al punto due se e solo se tutte le aree con criticità 2
o inferiore hanno un capability level almeno di due. Diremo che il nostro maturity
level è passato al punto tre se e solo se tutte le aree con criticità 3 o inferiore hanno
un capability level almeno di tre. Lo stesso vale chiaramente per un maturity level
pari a 4 e a 5. Questa suddivisione permette di identificare quali siano i processi
chiave per lo sviluppo del prodotto e quali invece siano dei miglioramenti auspicabili
ma non fondamentali.
Infatti, secondo un resoconto del SEI della CMU, il 70% delle aziende piccole (meno
di 25 dipendenti) raggiunge al massimo il livello 2, mentre il 52% delle aziende
medio-grandi (fra 1000 e 2000 dipendenti) raggiunge anche il livello 5. Questo
evidenzia che ad una compagnia piccola non trae particolare guadagno dall’investire
risorse dall’analisi CMMi e di come non sia necessario raggiungere un livello di
maturità alto, poiché questo non significa che le aree critiche non abbiamo capability
levels alti.
42
Part III
Linguaggi formali e tecniche di
compilazione
43

Progettazione del Software

Transcript

Documenti analoghi

Corso di formazione

modelli agili - Dipartimento di Informatica

PAPERISSIMA SPRINT

"ACCELERAZIONI E SPRINT NEL GIOCO DEL CALCIO DALLA

Angelo Sala - Impara Digitale

curriculum vitae pietro scott jovane

Marco Calvani Actor

Melanie Gerren Actress

telefono sprint a buon mercato

Essential Coworking: idee per uno spazio di lavoro agile

2011 - 27 - Federazione Italiana Sport Orientamento