UDA 19 - Ciclo di vita e modelli di sviluppo del software - 19.3 Modelli di sviluppo di software

24 Novembre 2014

di Maria Pia Accogli

19.3 Modelli di sviluppo di software

Un modello è il principio teorico alla base di una metodologia, un modello di sviluppo software definisce le caratteristiche generali del metodo utilizzato nel progettare e nello scrivere un programma. Esistono diversi modelli di sviluppo del software che si adattano a diverse situazioni e vincoli del contesto. Non esiste un modello migliore degli altri ma ognuno si adatta meglio a particolari situazioni, a volte i vari modelli si possono anche combinare tra loro per generarne uno più adatto alla specifica situazione. I modelli di sviluppo del software si dividono in tre tipologie: sequenziali, incrementali ed evolutivi in funzione del modello secondo cui si succedono le attività e secondo cui si realizzano i deliverable.

Modello a cascata

In ingegneria del software, il modello tradizionale di ciclo di vita del software è il modello a cascata chiamato waterfall model oppure waterfall lifecycle. L’elemento caratterizzante del modello a cascata è l’esecuzione in sequenza lineare di tutti gli elementi:

• il processo di sviluppo è strutturato in fasi sequenziali;
• ogni fase produce un output che è usato come input per la fase successiva;
• ogni fase del processo viene documentata perché necessaria alla fase successiva.

Figura 52: modello a cascata del ciclo di vita del software

Il modello a cascata prevede le seguenti fasi principali:

1. studio di fattibilità: ha lo scopo di determinare se lo sviluppo il sistema è possibile da un punto di vista tecnico e/o se è conveniente da un punto di vista economico;

2. analisi dei requisiti: ha lo scopo di determinare cosa deve fare il sistema;

3. progettazione: ha lo scopo di determinare come deve essere fatto il sistema per poter realizzare quanto stabilito nell’analisi dei requisiti. La fase di progettazione deve prevedere inoltre la scomposizione del sistema in moduli e le relazioni fra di essi;

4. sviluppo: ha come obiettivo lo sviluppo e l’integrazione dei moduli software;

5. collaudo o test: prevede l’esecuzione di test di verifica della corretta implementazione dei singoli moduli e, dopo l’integrazione, l’esecuzione di prove di verificare del corretto funzionamento dell’intero sistema;

6. manutenzione: comprende tutte le attività volte a migliorare, estendere e correggere il sistema nel tempo, dopo la consegna o delivery del prodotto finale al cliente.

Questo modello segue la successione tipica dei passi della produzione manifatturiera ed è stato il primo a essere utilizzato, per poi essere progressivamente abbandonato, dall'industria del software restando comunque un importante riferimento teorico. Il ciclo di vita a cascata ha avuto un enorme successo negli anni settanta perché si adattava perfettamente alla programmazione procedurale e strutturata alla base dei linguaggi allora in uso. Con l'evoluzione del software e dei linguaggi di programmazione il modello è stato sottoposto a profonde critiche e revisioni. Ancora oggi il ciclo di vita a cascata continua a rimanere un punto di riferimento importante, rappresenta sempre il modello "canonico" rispetto al quale vengono solitamente descritte le "variazioni" moderne. Rimane sempre il primo modello di sviluppo software che si insegna agli studenti.Il modello a cascata può essere ridefinito facilmente con specifiche varianti, possono essere formalizzati degli standard e imposti vincoli al processo di realizzazione riguardo alla natura, al formato, alla struttura e/o ai contenuti dei documenti (deliverable) prodotti nelle varie fasi. Tutti questi elementi alla base del modello a cascata hanno lo scopo di consentire un controllo rigoroso sullo stato di avanzamento del progetto e sulla qualità del lavoro svolto. Il limite del modello a cascata è rappresentato dalla eccessiva rigidità del modello che non facilita i miglioramenti in corso d’opera ed conseguentemente il dialogo con il committente che necessita di tempo e verifiche per poter esprimere compiutamente i suoi fabbisogni.

Modello a V

Figura 53: modello a V di sviluppo del software

Il Modello a V (V-model) è una estensione del modello a cascata di sviluppo del software, il modello invece di discendere lungo una linea retta, dopo la fase di codifica risale con una tipica forma a V. Il modello mette in evidenza la relazione tra ogni fase del ciclo di vita dello sviluppo del software e la sua fase di testing o collaudo del software.

Il modello a V realizza un metodo ben strutturato, in cui ogni fase è implementabile partendo dalla documentazione dettagliata della fase precedente, tale collegamento è indicato dalle frecce che nella parte sinistra del grafico collegano la fase precedente con la successiva. Durante l’implementazione di ogni attività vengono progettati e descritti anche i test necessari per la verifica di quanto progettato/realizzato; i test normalmente vengono derivati dalle specifiche appena progettate oppure dal codice appena sviluppato.La progettazione e descrizione dei test permette di iniziare la verifica già nel momento (fase) in cui i test vengono definiti, semplicemente analizzando e verificando quanto si sta definendo. Questa operazione permette di individuare eventuali errori o anomalie prima della fase successiva e di conseguenza permette di evitare il propagarsi degli errori con conseguente risparmio di tempo. Gli stessi test verranno poi utilizzati nelle successive fasi di testing descritte nella parte destra del grafico dal basso verso l’alto. Per esempio i test della fase di progetto dell’architettura, sono progettati, descritti e verificati durante la fase, poi a seguire vengono implementate le successive fasi di progettazione dei moduli e codifica. Terminata la fase di codifica si continua (parte destra del grafico) con il test dei singoli moduli, progettati nella fase di progettazione dei moduli. Testati i moduli si passa al test d’integrazione dei moduli che permette di verificare l’architettura del software eseguendo i test appositamente progettati.

Modello evolutivo o prototipizzazione

Il modello evolutivo è uno dei modelli del ciclo di vita del software che cerca di superare i limiti principali del modello a cascata. Questo modello si basa sulla costruzione di prototipi della soluzione, realizzati con strumenti software che permettono la rapida realizzazione di versioni semplificate. I prototipi permettono di sperimentare le funzionalità, di verificare i requisiti e conseguentemente di revisionare facilmente il progetto.

Figura 54: modello evolutivo di sviluppo software

La prima versione di un software spesso presenta degli errori o delle limitazioni che costringono a rifare gran parte dell’applicazione. Il modello evolutivo considera la prima versione come un throw-away (un prototipo "cestinabile") che serve a fornire al progettista un feed-back di analisi e verifica, dopodiché viene cestinata e si procede alla realizzazione dell'applicazione vera e propria. Il modello evolutivo è costituito da alcune fasi che si ripetono:

a) costruzione del prototipo sulla base dell’analisi dei requisiti;

b) valutazione del prototipo

c) verifica del prototipo con il cliente;

d) elaborazione del progetto sulla base delle valutazioni.

La seconda versione può essere poi sviluppata seguendo il modello a cascata attraverso le fasi di Realizzazione e Collaudo. Questo approccio evolutivo però fornisce una soluzione parziale ai problemi del modello a cascata, elimina gli errori nei requisiti ed è utile per valutare i costi, i tempi di realizzazione, la risposta del cliente e altro ancora, ma non riduce i tempi di realizzazione del ciclo di sviluppo. Il prototipo non è una necessità avvertita solo nei tempi moderni, ma è un'esigenza sentita fin da quando ci si poteva affidare solo a carta e attrezzi da disegno e la realizzazione del prototipo permetteva di effettuare importanti osservazioni sul progetto da realizzare.

Modello incrementale

La necessità di ridurre i tempi e le attività da cestinare ha portato alla trasformazione del modello evolutivo nel modello incrementale; tale modello prevede la realizzazione di un prototipo parziale capace di implementare un insieme significativo di funzionalità valutabili dal cliente, rimandando il resto a fasi successive.

Tabella 38: WBS del modello incrementale del ciclo di vita del software

Al cliente vengono forniti una serie di prototipi successivi che integrano i feedback in maniera incrementale. Questa tipologia viene detta modello di sviluppo a rilascio incrementale. Il modello incrementale presenta il limite che tende a complicarsi in quanto le fasi possono anche entrare in concorrenza, a esempio mentre si sta integrando una versione può accadere che sia stata già avviata la progettazione di quella successiva senza aver ancora valutato completamente i feedback della soluzione precedente. Con questo modello si riducono notevolmente i tempi, ma aumenta il rischio di perdere il controllo delle attività. Per evitare problemi è indispensabile definire degli standard di processo seguendo il modello a cascata. Nel modello incrementale la fase di manutenzione, poiché è vista come attività di evoluzione continua, viene gestita come una evoluzione del prototipo durante il progetto. In alcuni casi il prototipo cestinabile (throw-away) può essere sostituito con un prototipo evolutivo che poco per volta si trasforma nell’applicazione finale. Anche nell’uso del modello incrementale, il modello evolutivo rimane comunque è molto utile per verificare alcune componenti del software come le interfacce, queste infatti possono essere create velocemente e adattate all’utente.

Modello a spirale

Figura 55: modello a spirale di sviluppo del software

Il modello a spirale è paragonabile a un meta modello che consente di rappresentare i diversi modelli di ciclo di vita del software. Il modello a spirale permette di scegliere il modello di sviluppo più appropriato (evolutivo o a cascata) in funzione del livello di rischio. La scelta del modello da utilizzare avviene sulla base degli elementi e delle situazioni di rischio che possono pregiudicare il processo di sviluppo e la qualità del software. Il modello a spirale si concentra sull'identificazione e sulla eliminazione dei problemi ad alto rischio tralasciando quelli a basso rischio e impatto. La caratteristica principale del modello è quella di essere ciclico e non lineare, ogni ciclo di spirale si compone di quattro fasi, il raggio rappresenta il costo sostenuto sino a quel momento mentre l’angolo rappresenta sia la fase in esecuzione che il livello di avanzamento del processo all'interno di essa:

1. Prima fase: identificazione degli obiettivi e delle soluzioni;

2. Seconda fase: valutazione delle soluzioni e rilevazione delle potenziali aree di rischio;

3. Terza fase: sviluppo e verifica del prodotto;

4. Quarta fase: revisione dei risultati delle fasi precedenti.

Il modello a spirale è un modello di sviluppo del software che abbina la natura iterativa della prototipazione e gli aspetti controllati e sistematici del modello sequenziale lineare, consentendo un rapido sviluppo di versioni del software sempre più complete.Nel modello a spirale, il software viene sviluppato attraverso versioni successive e crescenti mediante la realizzazione di fasi successive che caratterizzano ogni giro della spirale. La spirale ha il pregio di considerare tutto il ciclo di vita sino alla consegna del software e oltre in quanto permette di strutturare e programmare anche l’attività successiva all'installazione, cioè la manutenzione, che molti altri modelli trascurano. Il modello a spirale è consigliato per progetti di grandi dimensioni perché permette di raffinare a ogni giro il materiale precedentemente elaborato e approvato dal cliente; si parte dalla definizione degli intenti e dello scopo finale, poi si passa alla costruzione, verifica e validazione dei prototipi, fino a giungere al prodotto conclusivo.

Metodologia agile

Nell'ingegneria del software, con il termine metodologia agile (o leggera) si indica una famiglia di metodi di sviluppo software che si ispirano ai principi riportati nel Manifesto Agile concepito nel 2001 dall'organizzazione non-profit Agile Alliance (http://www.agilealliance.org).L’organizzazione in quegli anni riuniva un considerevole gruppo di progettisti software e guru dell'informatica che sulla base di esperienze dirette e con il chiaro intento di ridurre il rischio di fallimento dei progetti di sviluppo software elaborarono questa metodologia. Il modello Agile Programming è un modello che prevede un continuo contatto con il cliente-utente mirato a facilitare la richiesta di requisiti e la soluzione di alcuni dubbi/problemi sollevati dallo sviluppo. Non esiste una vera documentazione scritta come nella maggior parte dei modelli analizzati sinora perché il codice è scritto secondo convenzioni e standard tali da permetterne in maniera molto rapida (agile) l’analisi. I principi base della metodologia agile sono i seguenti:

• le persone e le loro interazioni sono più importanti dei processi e degli strumenti, ossia le relazioni e la comunicazione tra gli attori di un progetto software sono la miglior risorsa del progetto;
• è più importante avere software funzionante che documentazione; è opportuno rilasciare nuove versioni del software a intervalli frequenti, bisogna mantenere il codice semplice e avanzato tecnicamente riducendo la documentazione al minimo indispensabile;
• bisogna collaborare con i clienti al di là del contratto perché la collaborazione diretta offre risultati migliori dei rapporti contrattuali;
• bisogna essere pronti a rispondere ai cambiamenti più che aderire al progetto e di conseguenza il team di sviluppo dovrebbe essere autorizzato a suggerire modifiche al progetto in ogni momento.

I metodi che derivano dall'applicazione della metodologia agile sono molteplici e dipendono fortemente dal contesto in cui questi debbano essere applicati, ma tutte le tecniche più diffuse sono simili fra loro e possono essere riconducibili a un numero limitato di principi.

Coinvolgimento del cliente

Sono previsti differenti gradi di coinvolgimento del cliente:

• in alcuni casi il coinvolgimento è totale (ad esempio nell'Extreme Programming il cliente è invitato a partecipare persino alle riunioni settimanali dei programmatori);
• in altri casi, il cliente è coinvolto in una prima fase di progettazione e non oltre;
• in altri ancora il cliente partecipa indirettamente e viene implicitamente utilizzato come tester della versione rilasciata.

Comunicazione diretta

Questo è l'unico vero aspetto che rende leggera una metodologia. Per “comunicazione diretta” si intende la comunicazione interpersonale, fra tutti gli attori del progetto e con il cliente prima di tutti. Ciò serve ad avere una buona analisi dei requisiti e una proficua collaborazione fra programmatori anche in un ambito di quasi totale assenza di documentazione.

Consegne frequenti

Effettuare rilasci frequenti di versioni intermedie del software consente di ottenere più risultati contemporaneamente: da una parte si offre al cliente qualcosa con cui lavorare, distraendolo così da eventuali ritardi nella consegna del progetto completo, dall'altra si può impiegare lo stesso committente come tester dal momento che, utilizzando il software rilasciato, sarà lui stesso a segnalare eventuali anomalie, infine è possibile ottenere informazioni sempre più dettagliate sui requisiti di progetto.

Progettazione e documentazione

Sebbene l'importanza attribuita a queste due attività venga sensibilmente ridimensionata nella metodologia Agile, sarebbe errato credere che le stesse siano del tutto assenti dal processo di sviluppo. In più occasioni i teorici della metodologia Agile hanno avvisato che sarebbe un errore trascurare o addirittura omettere queste due fasi, semplicemente, la quantità di progettazione e di documentazione da produrre, escludendo i casi estremi, viene demandata a chi ha la responsabilità del progetto.

Automazione

Se l'obiettivo delle metodologie leggere è concentrarsi sulla programmazione, allora le attività collaterali (es. test e documentazione) possono essere automatizzate. La tecnica per ottenere in maniera automatica la documentazione a partire da codice già prodotto è detta retro-ingegneria. Questa è una delle pratiche più diffuse e più controverse: diffusa perché permette un guadagno enorme in termini di tempo, ma controversa perché, molto spesso, la documentazione prodotta è inutilizzabile e viene conservata solo per motivi burocratici pur senza avere una reale utilità.

Gerarchia

La scelta di creare una struttura gerarchica all'interno del team di sviluppo è delicata: se si decide per una struttura gerarchica ad albero, si ottiene la possibilità di gestire un numero molto alto di programmatori e di lavorare a diversi aspetti del progetto parallelamente; se viceversa si decide per una totale assenza di gerarchia si avrà un team di sviluppo molto compatto e motivato, ma questo dovrà essere necessariamente piccolo in termini di numero di programmatori.

Programmazione di coppia

Programmare in coppia, ossia: due programmatori, due sedie, una scrivania, un computer, una tastiera e un mouse; uno dei due scrive, l'altro verifica, entrambi scelgono la soluzione costruttiva migliore. È stato dimostrato che i costi di questa scelta sono inferiori ai benefici che apporta, ma ci sono esempi pratici che indicano come questa pratica possa essere insopportabile per alcuni programmatori e quindi controproducente.

Refactoring

Riscrittura completa di parti di codice mantenendone invariato l'aspetto esterno, nel caso di una funzione ciò significa riscriverne completamente il core mantenendone invariato header e ovviamente sintassi, trattandola cioè come una black box. È una delle pratiche più diffuse e suggerite, ma anche questa, come la programmazione di coppia, ha differenti studi che ne attestano l'inutilità e in alcuni casi la dannosità.

Miglioramento della conoscenza

Nata con l'avvento della programmazione Object-Oriented, non è altro che la presa di coscienza della produzione di conoscenza che si fa in un un'azienda man mano che si produce codice. Questa conoscenza prodotta non deve andare perduta ed è per far ciò che si sfruttano spesso le altre pratiche, come la comunicazione stretta o la condivisione della proprietà del codice.

Semplicità

Uno dei punti chiave delle metodologie leggere, direttamente mutuato dalla programmazione Object-Oriented, è la semplicità; semplicità nel codice, semplicità nella documentazione, semplicità nella progettazione, semplicità nella modellazione; i risultati così ottenuti sono una migliore leggibilità dell'intero progetto e una conseguente facilitazione nelle fasi di correzione e modifica;

Controllo di versione

Una delle conseguenze dirette dell'iterazione nella produzione è la necessità di introdurre un modello, un metodo, uno strumento, per il controllo delle versioni del software prodotto e rilasciato.

Extreme programming

La metodologia chiamata Extreme Programming, o semplicemente XP, è uno degli esempi più celebri di metodologia agile. Si tratta di un recente approccio all'ingegneria del software il cui principale merito è quello di aver dato un impulso importante alla diffusione delle metodologie leggere e alla discussione sulle singole pratiche e sulle conseguenze dei loro utilizzi.

Principi guida

XP si basa su quattro principi guida:

• Comunicazione (tutti possono parlare con tutti, persino l'ultimo dei programmatori con il cliente);
• Semplicità (gli analisti mantengano la descrizione formale il più semplice e chiara possibile);
• Feedback (sin dal primo giorno si testa il codice);
• Coraggio (si dà in uso il sistema il prima possibile e si implementano i cambiamenti richiesti man mano).

Regole

Alla base di XP vi sono 12 regole che possono essere raggruppate nelle seguenti quattro aree principali:

1. 1. Feedback a scala fine:

• Pair Programming (programmazione in coppia) - il codice deve venir prodotto da coppie di programmatori che lavorano insieme su una sola workstation.
• Planning Game (riunione di pianificazione) - è una riunione che avviene a ogni nuova iterazione e tipicamente una volta a settimana.
• Test-driven Development (sviluppo guidato dalle verifiche) - i test automatici (sia unitari che di accettazione) vengono scritti prima di scrivere il codice.
• Whole Team (fare squadra tutti insieme) - in XP, il "cliente" non è colui che paga il conto, ma la persona che realmente utilizza il sistema. Il cliente deve essere quindi presente alle riunioni (possibilmente settimanali) e disponibile a verificare.

1. 2. Processo continuo:

• Continuous Integration (integrazione continua) - integrare continuamente i cambiamenti al codice eviterà ritardi più avanti nel ciclo del progetto.
• Refactoring o Design Improvement (migliorare la progettazione)– è una "tecnica strutturata per modificare la struttura interna di porzioni di codice senza modificarne il comportamento esterno", è basata sul principio che è opportuno riscrivere il codice in modo da renderlo più semplice e generico, ma senza alterarne le funzionalità esterne,.
• Small Releases (frequenti rilasci) – consegna del software avviene tramite frequenti rilasci di funzionalità che creano del valore concreto.

1. 3. Comprensione condivisa:

• Coding Standards (standard di codifica) - scegliere e utilizzare un preciso standard di scrittura del codice stabilendo un insieme di regole concordate all'intero team di sviluppo.
• Collective Code Ownership (proprietà collettiva del codice) - ognuno è responsabile di tutto il codice; ne consegue che contribuisce alla stesura dello stesso chiunque sia coinvolto nel progetto.
• Simple Design (progettazione semplice) - i programmatori dovrebbero utilizzare un approccio del tipo "semplice è meglio".
• System Metaphor (metafora di sistema) - descrivere il sistema con una metafora, anche per la descrizione formale. Questa può essere considerata come una storia che ognuno - clienti, programmtori, e manager - può raccontare circa il funzionamento del sistema.

1. 4. Benessere dei programmatori:

• Sustainable Pace (ritmo sostenibile) - i programmatori non dovrebbero lavorare più di 40 ore alla settimana.

Ciclo di vita

Il modello del ciclo di vita della metodologia XP prevede quattro fasi di progetto ognuna delle quali ha delle sue regole interne:

•  Pianificazione,
•  Progettazione,
•  Sviluppo,

Considerazioni finali

Extreme Programming è una metodologia molto famosa ma è anche molto controversa. In effetti anche se molto particolareggiata nella definizione delle fasi, dei principi e delle regole, rimane comunque una metodologia leggera non troppo differente dalle altre. Deve sicuramente la sua fortuna al lavoro degli autori che hanno ha saputo coglierne gli aspetti positivi e trasmetterli, anche quando i progetti gestiti sono falliti. Sono stati gli stessi autori ad ammettere i fallimenti, a considerarli parte integrante della filosofia di fondo della metodologia e a confermare che di tutte le pratiche di Extreme Programming la più importante è il carisma del project manager. Extreme Programming ha dato un impulso importante alla diffusione delle metodologie leggere e alla discussione sulle singole pratiche e sulle conseguenze dei loro utilizzi..

• < Prec
• Succ >