Dynamic System Development Method
Questo tipo di metodologia fonda i propri principi sulla regola “80-20 di Pareto”: per la realizzazione dell’ 80% di un applicazione è necessario il 20% dello sviluppo che servirebbe per completare l’applicazione. Il tutto si traduce in una quantità di lavoro minima, che permette l’avanzamento al successivo incremento. La restante parte dello sviluppo verrà completato successivamente quando saranno disponibili più requisiti o verranno richieste modifiche da parte del committente. I progetti coinvolti in questo tipo di attività, solitamente sono composti da un minimo di due persone (lato sviluppo) e una per il cliente.
A differenza degli altri metodi di sviluppo NON vengono definite le caratteristiche che il sistema dovrà e quindi aggiustati i budget e i tempi di sviluppo. Prima vengono fissati i budget e tempi, e solo successivamente vengono impostate le funzionalità ed i requisiti.
Si procede allo sviluppo impostando delle timebox, la cui durata viene stabilita in tenedno conto di tutte le variabili del progetto finale.
La metodologia DSDM è composta di cinque fasi. In particolare le prime due vengono eseguite solo alla prima iterazione. Le altre vengono eseguite iterando fino al completamento dello sviluppo.
- Feasibility Study: in questa fase viene verificata la possibilità di applicare il metodo DSDM al progetto da realizzare. Da questa prima fase di sviluppo vengono prodotti i rapporti di fattibilità. Potrebbe anche essere necessario procedere con lo sviluppo di un prototipo.
- Business Study: subito la fase di analisi della fattibilità, vengono stabilite le caratteristiche del progetto, le persone coinvolte sia lato sviluppo, sia lato committente. Viene prodotto il piano del prototipo da realizzare e la strategia di sviluppo dei protipi allo stadio successivo.
- Functional Model: Entriamo nella fase dello sviluppo vero e proprio. In particolar modo nella fase di prototipazione. Vengono studiati i modelli incrementali con cui interagire con il cliente finale. In questo modo verranno definiti gli eventuali raffinamenti fatti con il cliente. Inoltre viene anche prodotta la documentazione in tutti i suoi aspetti. In particolare viene anche prodotta l’analisi dei rischi.
- Design and build: si procede con l’implementazione del software collaudato che soddisfi i requisiti minimi. Si possono introdurre ulteriori modifiche, da far reiterare nel Functional Model.
- Implementation: rappresenta il passaggio naturale dall’ambiente di sviluppo all’ambiente di produzione. Il prodotto viene passato al cliente finale, che inizia ad utilizzarlo (con la documentazione prodotta). Se tutti i requisiti sono stati soddisfatti, non è necessario procedere con ulteriori operazioni di sviluppo. Nel caso in cui si rendano necessarie nuove implementazioni, il processo può essere reiterato partendo dalle fase intermedie. In rari casi si potrebbe verificare la necessità di ritornare alla fase di Feasibility study.
Anche in questo caso vengono definite una serie di figure con i ruoli fondamentali:
- Developer: il ruolo adibito allo sviluppo. L’unico. Può assumere lo status di Senior Developer ed un livello di leadership.
- Technical Coordinator: definisce l’architettura del sistema ed è responsabile della qualità tecnica del progetto.
- Ambassador User: trasmette la sua conoscenza agli utilizzatori ed al team di sviluppo.
- Visionary: solitamente è la persona che ha avuto l’idea di sviluppare il progetto. Il suo scopo è quello di analizzare tutti i requisiti dell’applicazione e che vengono rispettati i vincoli imposti dalla progettazione.
- Executive Sponsor: è il committente che ha responsabilità e autorità finanziarie ed il potere decisionale sulle scelte progettuali.