Porfirio Tramontana » 25.Cicli di Vita del Software

Modello a cascata

Limitazioni del Waterfall model

Svantaggi
Difficoltà di gestire eventuali necessità di modifiche durante l’esecuzione del processo. Ciascuna fase deve infatti essere completata e i suoi output fissati, prima di passare alla fase successiva.

Il modello assume che i requisiti possano essere congelati alla fine della fase di specifica, ma ciò è impensabile per un sistema i cui requisiti non siano ben chiari neanche al committente.

In alcuni casi è auspicabile sviluppare prima una parte del sistema e poi completarlo (utente finale= mercato);
in alcuni casi lo sviluppo di tutta la documentazione richiesta è non necessaria (uso di ambienti di sviluppo visuali).

Problemi del Waterfall model

La suddivisione inflessibile del progetto in fasi distinte rende difficile rispondere alle richieste di cambiamento dei requisiti da parte del cliente.
Di conseguenza questo modello è adatto solo se I requisiti sono ben chiari fin dall’inizio ed è difficile che cambino durante lo sviluppo.
In realtà pochi sistemi presentano requisiti stabili.
Il modello a cascata si usa per lo più quando fa parte di un progetto più vasto di ingegneria dei sistemi.

Sviluppo evolutivo

Basato sull’idea di produrre una versione iniziale del software, esporla agli utenti e perfezionarla attraverso varie versioni. Due modelli fondamentali:

1. Sviluppo Esplorativo
   1. L’obiettivo è di lavorare col cliente per esaminare i requisiti iniziali e farli evolvere fino al sistema finale. Dovrebbe partire da pochi requisiti ben compresi e aggiungere nuove caratteristiche proposte dal cliente.
2. Prototipo Usa e Getta
   1. L’obiettivo è di comprendere i requisiti del sistema. Si parte da requisiti poco chiari e si realizzano prototipi per esplorare i requisiti e chiarirli.

Sviluppo evolutivo (segue)

Problemi

• Mancanza di visibilità del processo (è anti-economico documentare ogni versione del sistema);
• I sistemi diventano spesso mal strutturati (per i continui cambiamenti);
• Richiedono particolari skills (es. uso di linguaggi di prototipazione rapida).

Applicabilità

• A sistemi interattivi di piccole e medie dimensioni (<500.000 LOC);
• Per sviluppare alcune parti di sistemi di grandi dimensioni (per es. l’interfaccia utente);
• Per sistemi destinati a vita breve.

Per grandi sistemi è consigliabile un approccio misto.

Ingegneria del software basata su componenti (CBSE)

Sviluppo basato sul riuso sistematico, integrando componenti esistenti o interi sistemi COTS (Commercial-off-the-shelf).

Fasi del Processo:

• Specifica dei requisiti;
• Analisi dei componenti;
• Modifica dei Requisiti (specificando i componenti disponibili);
• Progettazione con riuso;
• Sviluppo e Integrazione.

Questo approccio viene sempre più usato grazie all’affermarsi di appositi standard per la specifica di componenti.

Processi di sviluppo Iterativi

I requisiti di un sistema cambiano SEMPRE nel corso di un progetto, e sono pertanto inevitabili nuovi cicli di processo in cui si ritorna sulle fasi già condotte, soprattutto per grandi sistemi.
I cicli di processo possono essere applicati ad ogni generico modello di processo.
Due possibili approcci:

• Sviluppo e Consegna Incrementale;
• Sviluppo a Spirale.

Sviluppo e Consegna Incrementale

Piuttosto che consegnare il sistema tutto in una volta, lo sviluppo e la consegna sono eseguiti per incrementi, dove ogni incremento rilascia parte delle funzionalità richieste.
Ai requisiti utente vengono associati livelli di priorità e quelli a priorità maggiore vengono rilasciati con I primi incrementi.
Una volta partito lo sviluppo di un incremento, i relativi requisiti devono essere congelati, mentre i requisiti coinvolti in incrementi successivi possono continuare ad evolvere.
I servizi comuni possono essere implementati all’inizio del processo, o quando una funzione è richiesta da un dato incremento.

Vantaggi dello sviluppo incrementale

I clienti non devono aspettare il sistema completo per la consegna, ma possono disporre al più presto dei requisiti più critici, attraverso i primi incrementi.
I primi incrementi possono essere usati come prototipo per aiutare a definire I requisiti degli incrementi successivi.
Si riduce il rischio di un fallimento totale del progetto.
I servizi a più alta priorità saranno anche testati più intensamente degli altri.

Alcuni problemi

Gli incrementi devono essere relativamente piccoli (<=20.000 LOC) ma può essere difficile predisporre i requisiti in incrementi della dimensione giusta.
Le funzionalità comuni (richieste da più requisiti) potrebbero non essere identificate abbastanza presto, giacchè bisogna prima attendere che gli incrementi siano completati per avere ben chiari tutti i requisiti.

Rational Unified Process

Un moderno modello di processo software derivato da UML e dal relativo processo.

Prevede 6 pratiche fondamentali:

1. Sviluppare il software ciclicamente;
2. Gestire i requisiti;
3. Usare architetture basate sui componenti;
4. Creare modelli visivi del software;
5. Verificare la qualità del software;
6. Controllare le modifiche al software.

Le fasi del RUP

Avvio
Stabilire gli obiettivi di business (e relativi limiti, fattibilità e giustificazioni economiche) per il sistema; organizzare le risorse necessarie alla sua soluzione.

Elaborazione
Ottenere una comprensione del dominio del problema (e specificare i requisiti), stabilire una struttura architetturale ed il piano di progetto.

Costruzione
Progettare, programmare e testare il sistema incrementalmente.

Transizione
Trasferire il sistema nel suo ambiente operativo.

Metodi Agili

L’insoddisfazione per l’eccessivo overhead richiesto dai sistemi di progettazione ha portato negli anni ‘90 alla proposta dei metodi agili. Tali metodi:

• Si concentrano sul codice, piuttosto che la progettazione;
• Sono basati su un approccio iterativo allo sviluppo software;
• Sono pensati per rilasciare software funzionante rapidamente, e per farlo evolvere rapidamente per soddisfare nuove esigenze;
• Propongono di coinvolgere il cliente il più possibile nel processo di sviluppo.

I metodi agili sono più adatti per sistemi aziendali di piccole/medie dimensioni o a prodotti per PC.

Alcuni Metodi Agili

• Extreme Programming (Ken Beck 1999);
• SCRUM;
• Crystal;
• DSDM (Dynamic System Development Method);
• Alcuni di questi metodi sono stati recepiti nel RUP;
• Ogni metodo propone un diverso processo, ma tutti condividono gli stessi principi.

Principi dei metodi agili

Coinvolgere del cliente il più possibile.
Sviluppo incrementale.
Concentrarsi sulle persone, più che sul processo.
Accettare i continui cambiamenti dei requisiti.
Mantenere la semplicità nel prodotto, adottando sempre le soluzioni più semplici e operando refactoring per migliorare la qualità continuamente.

Problemi dei metodi agili

Non sempre i clienti possono partecipare a tempo pieno al processo di sviluppo.
I membri del team non sono sempre adatti al coinvolgimento intensivo con altri membri che caratterizza I metodi agili.
Dare la priorità alle modifiche può essere difficile dove esistono vari stakeholders,ognuno con suoi interessi.
Mantenere la semplicità del sistema può richiedere lavoro extra (e tempo extra, non sempre disponibile).
Il contratto può non essere facilmente definito, come accade in altri approcci allo sviluppo iterativo.

Extreme programming

Forse è il metodo agile più noto ed usato.
Extreme Programming (XP) adotta un approccio estremo allo sviluppo software.

• L’approccio si basa su requisiti espressi come scenari (storie utente) che sono implementati direttamente;
• Nuove versioni possono esser prodotte più volte al giorno;
• Gli incrementi sono rilasciati al cliente frequentemente, in genere ogni 2-4 settimane;
• Ogni nuova versione viene completamente testata, e viene accettata solo se supera tutti i test.

Pratiche dell’Extreme Programming

The Planning Process (o Planning Game).
La pianificazione del processo in XP consiste nella definizione del business value di ogni caratteristica desiderata e nella stima dei costi per decidere in che ordine le caratteristiche debbano essere realizzate. Si tratta quindi di una strategia estremamente duttile, che può essere ripensata durante lo svolgimento del progetto.

Small Releases.
La vita e lo sviluppo dell’applicazione sono scanditi dai rilasci di versioni del prodotto funzionanti. Ogni rilascio rappresenta il punto conclusivo di un’iterazione di sviluppo e l’inizio di una nuova pianificazione. Per poter tener conto di cambi di prospettiva, errori di valutazione, nuovi requisiti, restrizioni di bilancio, ogni iterazione dovrebbe durare non più di qualche settimana (in genere, da due a quattro).

Metaphor.
I team di lavoro XP condividono un “sistema dei nomi”, nel quale siano compresi I concetti fondamentali relativi al software sotto sviluppo (in pratica il dominio dei dati)

Pratiche dell’Extreme Programming (segue)

Simple Design.
Un programma costruito con XP dovrebbe essere il programma più semplice in grado di soddisfare i requisiti. Non si cercano soluzioni che possano portare benefici in un prossimo futuro. La qualità del progetto é comunque tenuta alta, grazie anche alle attività di refactoring.

Testing.
Il testing é un elemento fondamentale dell’XP. I programmatori devono scrivere i test contemporaneamente alla scrittura del programma stesso (strumenti come XUnit sono particolarmente utili). Il testing di accettazione invece é demandato al cliente finale.

Refactoring.
Durante le fasi di integrazione del codice appena prodotto con il resto del sistema, bisogna operare in maniera da tenere alta la qualità della progettazione, evitando ridondanze dei dati e duplicazioni del codice. Fondamentale rimane ancora la comunicazione tra i vari gruppi.

Pratiche dell’Extreme Programming (segue)

Pair Programming.
I programmatori XP lavorano in coppia: due programmatori sulla stessa macchina. Uno dei programmatori é addetto alla scrittura fisica del codice, mentre l’altro ne controlla la correttezza, salvo scambiarsi I ruoli di tanto in tanto. Esperimenti dimostrano come la produttività sia superiore rispetto a quella di due programmatori separati.

Collective Ownership.
Ogni programmatore deve essere in grado di avere un’idea generale del progetto e di poter toccare qualunque punto del codice, anche di quello che non ha scritto lui personalmente. Quest’obiettivo può essere raggiunto seguendo il principio di Simple Design.

Continuous Integration.
Il processo di integrazione del sofware con i nuovi moduli avviene più volte al giorno. Ciò aiuta I programmatori ad essere sempre aggiornati sullo stato del progetto e riduce la maggior parte dei gravi problemi di integrazione che si verificano quando questa fase non é eseguita così spesso.

Pratiche dell’Extreme Programming (segue)

40-hour Week.
I programmatori stanchi commettono più errori. Essi non dovrebbero fare troppo straordinario, in modo da essere freschi, in salute e produttivi

On-site Customer.
Il committente deve essere coinvolto nello sviluppo perché è l’unica fondamentale fonte di convalida del sistema. Partecipa perciò alla stesura dei test di sistema e verifica, periodicamente, che il sistema realizzato corrisponda effettivamente alle proprie esigenze. Inoltre, è la principale fonte di informazione per la conoscenza sul dominio di applicazione.

Coding Standard.
I programmatori dovrebbero condividere uno stesso stile di scrittura del codice, in modo da rendere più semplice la comunicazione

XP e i principi agili

Lo sviluppo incrementale è realizzato attraverso release piccole e frequenti.
Il coinvolgimento del cliente nel processo di sviluppo deve essere a tempo pieno.
Si da’ 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.
Il mantenimento della semplicità è raggiunto attraverso pratiche continue di refactoring.