Programmazione/ L'Extreme Programming (III)

Giunti all'ultima parte di questa breve serie di articoli sui modelli di processo software arriviamo finalmente a parlare dell'Extreme Programming, un modello innovativo adatto soprattutto alle piccole e medie realtà

Eccoci all'ultimo appuntamento di questo breve speciale sui modelli di processo software. Nelle prime due parti abbiamo introdotto il concetto di modello di processo software e abbiamo visto l'antesignano di tutti i modelli, il Waterfall model. Abbiamo inoltre accennato alle difficoltà che si possono incontrare nell'introdurre determinate pratiche in piccole realtà. Vediamo ora quali sono le caratteristiche di un modello proposto dai suoi creatori proprio per le piccole imprese: l'Extreme Programming.

Le fasi individuate nella presentazione del modello a cascata sono ovviamente ancora valide, in quanto caratterizzano l'attività di produzione del software e non un particolare modello. Quello che cambia è l'organizzazione, ovvero il ciclo di produzione. Se nel modello a cascata analisi, design, implementazione e testing sono organizzate sequenzialmente, in Extreme Programming le cose cambiano sulla scorta di una riflessione che è alla base di tutti i modelli che hanno seguito il Waterfall: non è detto che si riesca a fissare una volta per tutte i requisiti del sistema e non è detto che l'analisi fatta sia esente da errori o che non sia possibile migliorarla. Il set di caratteristiche che un sistema deve esibire non è un insieme statico, al contrario tende ad evolvere durante il processo di sviluppo in quanto sia gli utenti che gli sviluppatori aumentano la conoscenza che hanno del problema.
Inoltre bisogna anche prendere in considerazione l'eventualità per cui modifiche ai requisiti raccolti siano apportate per interventi esterni: molti progetti non sono legati alle necessità di un particolare utente ma sono finalizzati alla realizzazione di un prodotto che si inserisca in una particolare nicchia di mercato (un browser, una suite per office automation, etc.): in questi casi le decisioni della sezione marketing devono essere trattate dagli sviluppatori come se fossero requisiti utente.
Facciamo un esempio per chiarire questo ultimo concetto. Poniamo che la ditta "Rossi Software Solutions", RSS, (ovviamente nome di fantasia) si proponga di contrastare le grosse firme del software nel campo dei browser. Il browser della RSS per essere concorrenziale dovrà ovviamente prevedere la totale compatibilità con gli standard vigenti in fatto di WWW (linguaggi, plug-in, sicurezza, etc.). Dopo un'accurata indagine di mercato la sezione di amministrazione della RSS comunica le sue decisioni al team di sviluppo che provvederà a trasformarle in una serie di requisiti tecnici. I lavori cominciano e mentre già è iniziata la fase di implementazione salta fuori una nuova tecnologia per la gestione di audio e video via Internet che promette scintille. Il team di sviluppo alla RSS si guarda bene dal pensare di rimettere in discussione quello che è già stato fatto, ma dall'amministrazione arriva la notizia che una indagine di mercato portata a termine dalla sezione marketing sottolinea come l'opinione pubblica sia notevolmente attratta dalla nuova tecnologia. Il risultato è che gli sviluppatori, o meglio, coloro che si occupano di analisi e design, devono ritornare sui loro passi e includere questa nuova caratteristica nel progetto.
TAG: sw