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.
L’esempio precedente ci fa capire una volta di più come la produzione di software non sia semplicemente tecnicismi e perizia nel programmare. Per venire incontro a eventualità come quelle descritte, sono state proposte organizzazioni del ciclo di produzione alternative a quella del modello a cascata. In particolare si è cercato di prevedere una ciclicità nelle fasi che permettesse di procedere per passi successivi partendo da un nucleo minimale di requisiti. Ogni passo comporta la progettazione e l’implementazione di alcune funzionalità. In Extreme Programming questa filosofia ha portato ad un ciclo di produzione che può essere schematizzato nella seguente figura:
il ciclo di produzione viene scomposto in più sottocicli ad ognuno dei quali corrisponde una release del sistema da sviluppare: una volta presentata all’utente, viene presa nota delle eventuali modifiche che saranno oggetto di un successivo sottociclo. Questo è, molto sinteticamente, quanto succede.
Vediamo ora di capire come si realizza al metodologia suggerita da Extreme Programming. L’oggetto fondamentale è quello che viene chiamato “storia”. Una storia raccoglie un insieme di funzionalità e caratteristiche che il sistema deve esibire. Questi insiemi sono determinati in modo da essere considerabili come unità indipendenti, testabili e tali da permettere una stima del costo necessario alla loro implementazione. Dopo una prima fase di analisi globale, gli sviluppatori producono una storia che raccoglie quelle che in una prima approssimazione è possibile considerare come tutte le funzionalità del sistema. A questo punto cominciano i cicli di cui in figura. Il cliente è invitato a scegliere alcune delle caratteristica del sistema così da individuare un nuovo insieme, una nuova storia. Tale scelta è supportata da una adeguata informazione per il cliente sui costi e sui tempi di realizzazione di ogni caratteristica, così che possa essere sempre ben cosciente di quello che succederà in futuro. Individuata una storia, gli sviluppatori si dedicano ad essa fino a realizzare una release del sistema da presentare al cliente per l’accettazione. Il cliente valuta la release prodotta e il ciclo riprende partendo dalle modifiche a quanto è stato fatto e comprendendo un’altra storia scelta dall’utente. All’inizio di ogni sottociclo, il cliente definisce anche una serie di test funzionali che verranno poi utilizzati in fase di integrazione per verificare il codice che implementa le caratteristiche incluse nella storia.
Questo per quanto riguarda la macro-struttura del modello, vediamo ora cosa succede all’interno di ogni sottociclo. Gli sviluppatori trasformano ogni storia in un insieme di task, di grana più fine rispetto le caratteristiche indicate nella storia. Ogni programmatore sceglie un sottoinsieme di questi task da sviluppare e testare. Tutto il lavoro di programmazione viene svolto in coppia, per avere un maggiore controllo in ogni istante: se ci sono dubbi i programmatori possono avere brevi incontri con il cliente oppure con altri programmatori più esperti. Durante la fase di codifica i programmatori si occupano anche di definire i casi di test per verificare la correttezza di quello che stanno producendo. Questi test verranno eseguiti sul codice insieme a quelli definiti dall’utente (test funzionali) e solo se verranno passati tutti si potrà integrare nella release corrente del sistema la nuova caratteristica.
Questo modo di procedere permette di avere sotto controllo in ogni istante parti relativamente piccole del sistema e di essere ragionevolmente sicuri di riuscire a completare quanto specificato in una storia entro i tempi dichiarati (sempre che le stime compiute da progettisti e programmatori siano attendibili!).
Una conseguenza diretta di questo modo di procedere è che il sistema comincia ad essere implementato molto presto ed è caratterizzato da release relativamente ravvicinate fra loro (ad ogni release corrisponde un ristretto numero di funzionalità): questo permette di avere maggiore feedback dal cliente in quanto è possibile fare test sul campo di ogni singola release e i risultati di tali test possono essere ricondotti ad insiemi di caratteristiche ben definite e possibilmente ristrette.
Una delle caratteristiche più peculiari dell’Extreme Programming, come si evince dalla pur riduttiva descrizione data, è che il cliente viene direttamente coinvolto nel ciclo di produzione, a tal punto che è prevista la presenza costante di un rappresentante del cliente nel team di sviluppo. Questo garantisce di ridurre le incomprensioni e le incompletezze nella comunicazione fra il cliente e gli sviluppatori.
Questo è quanto si può dire, senza nessuna pretesa di completezza, su Extreme Programming, resta il fatto, comunque, che per necessità di sintesi, è stato necessario tralasciare alcuni punti su cui sarebbe opportuno spendere qualche parola in più. Ad ogni modo l’obiettivo di questi articoli è quello di dare un’idea generale di quello che è un modello di processo software e di cosa significa sviluppare sistemi software. Se qualche lettore sente la necessità di ulteriori chiarimenti è caldamente invitato a mettersi in contatto con chi sta scrivendo.
Ti potrebbe interessare
17 apr 2000