Sviluppo rapido

Sviluppo rapido

La rapidità dello sviluppo e consegna è oggi spesso il requisito più critico per i sistemi software. Si è disposti a transigere sulla qualità, pur di avere una rapida consegna delle funzionalità essenziali.

Sviluppo basato su specifiche e consegna iterative è il solo modo per consegnare il software rapidamente. Non esiste una specifica dettagliata e la documentazione di progetto è ridotta al minimo. Il sistema è sviluppato iterativamente in una serie di incrementi. Gli utenti valutano ciascun incremento e quindi propongono modifiche e fanno proposte per i successivi incrementi.

. Vantaggi: Gli incrementi rilasciano dapprima le funzionalità a maggiore priorità per il cliente. Gli utenti sono coinvolti nel processo di sviluppo fornendo i propri feedback: di qui, maggiore probabilità di soddisfarne I bisogni, e maggiore volontà degli utenti di fare funzionare il sistema.

. Problemi: Problemi di gestione - gli avanzamenti del lavoro e gli eventuali problemi possono essere valutati con difficoltà, giacché non tutta la documentazione di sistema viene prodotta. Problemi contrattuali -  è difficile scrivere un contratto senza una specifica; il contratto può essere scritto sulla base del tempo impiegato, ma può essere insoddisfacente sia per i clienti che gli sviluppatori. Problemi di Validazione - senza una specifica, rispetto a cosa si può verificare e validare il sistema. Problemi di Manutenzione - le modifiche continue tendono a corrompere la struttura del software, rendendo più difficile le modifiche future.

. Applicabilità: Non è usabile per sistemi molto complessi o critici.

RAD, Rapid Application Development (più famoso proposto da James Martin nel 1991)

Elementi essenziali del RAD

> Prototipizzazione (per raffinare i requisiti, viene fatto evolvere iterativamente).

> Sviluppo Iterativo e Time Boxed (incrementi a feature ridotte).

> Piccoli Team di lavoro (SWAT, skilled workers with advanced tools).

> Management del progetto (deve evitare il rischio di lunghi cicli di lavoro).

> Strumenti RAD (linguaggi per la programmazione di Database, generatori di codice come generatori di interfacce, collegamenti ad applicazioni office, generatori di rapporti).

- Sviluppo Agile del Software

L'insoddisfazione per l'eccessivo overhead richiesto dai sistemi di progettazione ha portato negli anni '90 alla creazione dei metodi agili.

Motivazioni dell'introduzione dei Modelli Agile:

. Spesso i requisiti non sono chiari.

. Progetti grandi falliscono più spesso dei piccoli.

. La eccessiva documentazione rallenta i tempi di sviluppo.

. La comunicazione tramite documenti non è chiara come la comunicazione diretta.

. Gli imprevisti e i cambiamenti sono inevitabili.

. Mancanza visione di quello che si sta facendo.

Possibili Soluzioni:

. Il cliente dovrebbe partecipare attivamente allo sviluppo.

. Riconosce che i piani hanno vita breve. Fare rilasci multipli (incrementi software).

. Sviluppo dando enfasi alle attività di costruzione invece che di documentazione.

. Incentivare la comunicazione diretta fra tutti i partecipanti.

. Avere una efficace risposta (rapida e flessibile) ai cambiamenti.

. Organizzare un team in modo da controllare il lavoro svolto.

Principi dei Metodi Agili:

. Coinvolgimento del cliente: Portare il cliente nel team di lavoro.

. Consegna Incrementale: Il software è sviluppato in incrementi.

. Persone, non processi: Le persone devono poter liberamente sviluppare con

i propri metodi, senza imposizioni di processi prescrittivi.

. Accettare i cambiamenti: Prevedere i requisiti che cambieranno e progettare il sistema in modo da accettare i cambiamenti.

. Mantenere la semplicità: Semplicità sia nel software che si sviluppa, che nel processo adottato.

Vantaggi grazi ai cicli di consegna più brevi: Consegne più predicibili; Rapida risposta ai cambiamenti dei bisogni utente; Alta produttività; Rischi attenuati.

eXtreme Programming

XP prevede uno sviluppo incrementale, realizzato attraverso release piccole e frequenti ogni 2-4 settimane. Il coinvolgimento del cliente nel processo di sviluppo deve essere a tempo pieno. Si dà attenzione alle persone (e non al processo) attraverso la programmazione a coppie, il possesso collettivo del codice e con tempi di lavoro non eccessivo. Le modifiche sono supportate da release costanti del sistema.

In XP, i requisiti sono espressi come scenari, le cosiddette storie utente. Gli scenari sono scritti su schede (Story Card) e il team di sviluppo le suddivide in task da implementare. Tali task sono la base per la stima dei costi e la schedulazione del lavoro. Il cliente sceglie le storie da includere nella prossima release sulla base della loro priorità e del costo stimato.

Per rendere più semplice l'implementazione delle modifiche, XP propone un continuo miglioramento del codice (refactoring). Il Refactoring è necessario perché con I rilasci frequenti il codice (sviluppato incrementalmente) tende a deteriorarsi.

XP richiede di progettare I test prima di scrivere il codice. Lo sviluppo dei test avviene in modo incrementale a partire dagli scenari. Si automatizza l'esecuzione dei test in modo da testare tutte le unità ogni volta che viene prodotta una nuova release. Ciò permette di verificare che la nuova funzionalità non abbia introdotto errori.

Il coinvolgimento del cliente è essenziale in XP. Il ruolo del cliente è molteplice: aiuta a sviluppare storie che corrispondono ai requisiti; aiuta a definire le caratteristiche da includere in ogni release; aiuta a sviluppare i test di accettazione per controllare che il sistema soddisfi i suoi requisiti.

Pratiche dell'eXtreme Programming: (1)The Planning Process. (2)Small Releases. (3)Metaphor. (4)Simple Design. (5)Testing. (6)Refactoring. (7)Pair Programming. (8)Collective Ownership. (9)Continuous Integration. (10)40-hour Week. (11)On-site Customer. (12)Coding Standard.

Problemi di XP:

Coinvolgimento del cliente: Può essere difficile trovare un cliente rappresentativo di tutti gli stakeholder e che possa lasciare il normale lavoro per far parte del team di XP.

Progetto architetturale: Lo stile incrementale di sviluppo comporta che possano farsi

scelte architetturali inadeguate nelle prime fasi del processo.

Compiacimento per i Test: A causa del testing automatico, c'è la tendenza a sviluppare test

facili da automatizzare, piuttosto che test realmente validi (ma difficili da automatizzare).