Feature Driven Development: differenze tra le versioni

Versione delle 11:40, 2 apr 2007

Versione delle 12:50, 2 apr 2007

Riga 3:

Come s'intuisce dal nome è una forma di sviluppo ''guidata dalle funzionalità'' richieste e necessarie del programma. Sono disponibili diversi strumenti di supporto free, alcuni anche [[open source]], essendo strettamente basata sull'utilizzo del [[Unified Modeling Language|UML]] e naturalmente sulla versione ''colorata'' del UML ideata dagli autori. Inoltre esiste una community molto attiva che si occupa di questa metodologia e degli strumenti utili per automatizzarne l'utilizzo, sviluppandoli e confrontandosi.

È forse il miglior compromesso e la miglior soluzione agile possibile, ma è molto meno conosciuta di [[Extreme Programming]], pur essendo indicata nell’nell'[[Agile Manifesto]]. [[Serguei Khramtchenko]] fa un confronto diretto (vedi Bibliografia) dal quale emerge sorprendentemente che Feature Driven Development è addirittura più flessibile di Extreme Programming anche se la prima ha una fase di progettazione ''classica'' che la seconda elimina proprio per guadagnarne in flessibilità.

==Le fasi di sviluppo==

Il progetto viene diviso in cinque fasi, dette processi:

* '''sviluppare un modello generale'''

** ''criteri d’ingressod'ingresso'': avere scelto gli esperti del problema, i capi-programmatori ed il capo-architetto;

** ''attività'': il project manager deve formare il team di modellazione; il team di modellazione deve offrire una panoramica del dominio del problema, preparare i documenti funzionali e, diviso in piccoli gruppi, sviluppare il modello; il capo-architetto deve rifinire il modello generale ad oggetti insieme al team di modellazione e scrivere le note al modello insieme ai capi-programmatori;

** ''verifica'': il team di modellazione deve effettuare un accertamento interno ed esterno con riferimento agli esperti di business ed ai futuri utenti;

** ''criteri d’uscitad'uscita'': avere definito il modello ad oggetti avendo quindi a disposizione i diagrammi delle classi, i metodi e gli attributi delle classi, la sequenza delle classi (se esiste), le note al modello;

* '''costruire una lista di funzionalità'''

** ''criteri d’ingressod'ingresso'': avere scelto gli esperti del problema, il capo-programmatore ed i capi-architetti;

** ''attività'': il project manager deve formare il team della lista delle funzionalità che deve comprendere i capi-programmatori del team di modellazione; il team della lista delle funzionalità deve definire la lista delle funzionalità in termini di azione-risultato-oggetto;

** ''verifica'': il team della lista delle funzionalità deve effettuare un accertamento interno ed esterno con riferimento agli esperti di business ed ai futuri utenti;

** ''criteri d’uscitad'uscita'': avere definito la lista delle funzionalità avendo quindi a disposizione la lista delle aree oggetto, la lista delle attività di business per ogni area oggetto, la lista delle funzionalità che soddisfino tutti i punti di ogni lista delle attività;

* '''pianificare per funzionalità'''

** ''criteri d’ingressod'ingresso'': è stato portato a termine il processo ''costruire una lista di funzionalità'';

** ''attività'': il project manager deve formare il team di progettazione che comprende capi-programmatori e manager dello sviluppo; il team di progettazione deve definire la sequenza di sviluppo, assegnare le attività di business ai capi-programmatori ed assegnare le classi agli sviluppatori;

** ''verifica'': il team di progettazione deve effettuare un’autoverificaun'autoverifica sul lavoro svolto;

** ''criteri d’uscitad'uscita'': avere definito un piano di sviluppo comprendente le attività di business con le date di completamento ed i capi-programmatori responsabili assegnati, la date di completamento delle aree oggetto (derivate da quelle delle attività di business), la lista delle classi con relativi sviluppatori;

* '''progettare per funzionalità'''

** ''criteri d’ingressod'ingresso'': è stato portato a termine il processo ''pianificare per funzionalità'';

** ''attività'': ogni capo-programmatore forma il team delle funzionalità; ogni esperto del problema definisce la strada per affrontare il problema e risolverlo; il team delle funzionalità studia i documenti dei requisiti delle proprie funzionalità; il team di progettazione sviluppa i diagrammi di sequenza; il capo-programmatore raffina il modello ad oggetti per definire se scrivere o modificare classi, metodi, attributi; il team delle funzionalità scrive le classi e gli header dei metodi;

** ''verifica'': il team delle funzionalità ispeziona il progetto in tutti i suoi aspetti funzionali e temporali;

** ''criteri d’uscitad'uscita'': avere definito un pacchetto di progettazione completo che comprenda un documento esplicativo dell'intero progetto con le specifiche referenziate (se esistono riferimenti), i diagrammi di sequenza, le alternative di progetto (se esistono), il modello ad oggetti completo di classi, metodi e attributi, gli header di classi e metodi, una todo list con un calendario delle scadenze per ogni attività ed ogni membro del team;

* '''sviluppare per funzionalità'''

** ''criteri d’ingressod'ingresso'': è stato portato a termine il processo ''pianificare per funzionalità'' ed è stato ispezionato con successo il progetto in tutti i suoi aspetti funzionali e temporali;

** ''attività'': il team delle funzionalità implementa classi e metodi, ispeziona il codice ed effettua i test unitari; il capo-programmatore decide (dopo i test unitari) insieme al team delle funzionalità quali classi siano ''promuovibili'' come utili alla costruzione del progetto in riguardo alle funzionalità richieste;

** ''verifica'': il capo-programmatore sovrintende affinché siano completate effettivamente in tutti i punti dal team delle funzionalità l'ispezione dei codici ed la soddisfazione dei test unitari;

** ''criteri d’uscitad'uscita'': avere ottenuto classi e metodi che siano stati ispezionati e testati con successo, infine promossi all'integrazione nel progetto (ovviamente a copertura di tutte le funzionalità previste).

In pratica si può ridurre l'iterazione al semplice ciclo composto dai soli ultimi due passi: ''definire una lista di funzionalità'' / ''sviluppare per funzionalità''. Il processo critico è il primo, ossia ''sviluppare un modello generale'', ed è questo deve dare in uscita la documentazione [[Unified Modeling Language|UML]]. Questi diagrammi devono essere impostati in maniera tale da ottenere una frammentazione (una granularità) dall’altodall'alto verso il basso, in modo da avere funzionalità da sviluppare che possano essere prodotte in brevi iterazioni. Queste funzionalità devono poi essere riunite in un singolo package alla fine di ogni iterazione.

Ogni iterazione è composta da sei fasi:

Riga 41:

* Development (si implementa il codice previsto con i relativi unit test);

* Code review meeting (la revisione del codice viene effettuata da tutti i programmatori);

* Release meeting (le funzionalità implementate vengono “promosse”"promosse" al processo di integrazione).

==Il processo di sviluppo==