Bookmark and Share
 Ingegneria del Software: modelli di ciclo di vita

Università Wednesday 28 November 2007 alle 13:51

Dopo aver analizzato le fasi del modello tradizionale del ciclo di vita di un software, rieccomi per fare un elenco, spero piuttosto completo, di tutti quelli che sono i modelli creati durante questi ultimi 20 anni, 20 anni di crescente sviluppo nel ramo della programmazione.

Darò una spiegazione generale di ogni modello, elencandone, se possibile, pregi e difetti, per porre tutti coloro che hanno poco chiaro l’argomento in grado di comprendere meglio l’evoluzione di questi modelli.

Modello a cascata (o document based)

Questo modello, nato negli anni 50, diventa famoso solamente intorno agli anni 70, anni in cui un numero sempre crescente di persone si pone di fronte ad un computer per produrre software. Prevede anche due varianti (retroazione singola e a fontana).

Modello a Cascata

Prende nome dal flusso preciso delle fasi che lo compongono, partendo dalla raccolta dei requisiti e cadendo (come l’acqua dalla montagna) attraverso tutte le altre fasi, fino ad arrivare al cliente. Una volta che il progetto è consegnato al cliente, questo modello non prevede nemmeno la fase di manutenzione.
È anche chiamato “document based” perchè presuppone una fortissima rigidità nella compilazione di documenti di specifiche: i reparti che si occupano di gestire le fasi non comunicano tra loro e la documentazione deve essere per questo motivo il più chiara possibile.

Pregi: si possono fissare nei dettagli le scadenze delle singole fasi.

Difetti: rigidità (impossibile fare modifiche), congelamento dei sotto prodotti, stima dei costi solo iniziale, monoliticità. Anche per il cliente che cambia idea in un secondo momento non c’è possibilità di modifica.

Variante: retroazione singola

La variante a retroazione singola prevede che ogni fase può intervenire al livello precedente per effettuarne modifiche e/o correzioni. Diventa però un modello troppo libero e non mi permette di seguire un percorso chiaro e preciso.

Variante: modello a fontana

Questo modello prevede l’aggiunta delle fasi di manutenzione e evoluzione: come in una fontana l’acqua viene spinta verso l’alto per poi ricadere nella vasca, questo modello prevede il passaggio attraverso tutte le fasi della produzione e, giunto alla fase di manutenzione (o alla fase di evoluzione), ritorna all’inizio. Per ogni modifica che si vorrà effettuare al progetto si riaffronteranno così tutte le fasi, una per una.

Modello a V (o dente di pescecane)

Modello particolare che prevede che, ad ogni passo avanti effettuato lungo la sequenza delle fasi, vengano effettuati due differenti test. Il primo è il test di verifica rispetto alla fase precedente, il confronto con le specifiche fornite dal livello superiore, il secondo è il test di validazione che viene effettuato con l’utente.

Ogni volta che mostrerò il sistema all’utente, l’utente avrà un’idea più completa di quello che vuole e potrà fornirmi informazioni di specifica più precise e complete.

Modello Evolutivo e Incrementale

Tra questi due modelli c’è una sostanziale differenza, anche se sono molto simili tra loro.

Nel modello evolutivo, consegnerò il sistema completo all’utente ogni volta che si presenterà una modifica sensibile (che crea un aggiunta di valore) per lo stesso.

Il modello incrementale, invece, prevede un continuo balzare dalla fase di coding (di scrittura del codice dell’applicativo) alla fase di analisi dei requisiti, fino a quando sarò certo di aver creato il programma definitivo: solo a questo punto lo consegnerò all’utente.

Difetti: in entrambi i modelli non posso determinare quanti cicli effettuerò e la pianificazione diventa così difficile da gestire.

Modello Prototipale

Modello discutibile, prevede in sostanza di effettuare il lavoro almeno due volte.
Il primo lavoro sarà il prototipo del sistema e servirà al programmatore, quanto al cliente, per avere un’idea precisa di cosa fare, delle problematiche che si possono incontrare lungo il cammino e avere un feedback completo.
Si potrà così buttare via tutto per affrontare il lavoro in maniera completa.

Pregi: ottimo per le interfacce utente, che verranno mostrate senza alcun codice correlato.

Modello Flipper

Poco da dire: il ciclo di vita è quasi puramente casuale. Il sistema è come una pallina che rimbalza a caso tra le fasi. Non ci sono vincoli temporali e nulla è misurabile.

Meta-modello a spirale (risk based)

Questo meta modello è una sorta di framework attraverso cui posso inquadrare tanti altri modelli. Prevede di analizzare ciclicamente (allontanandomi dal centro e aumentando i costi) tutte le fasi dello sviluppo, permettendomi, per esempio, di terminare ad ogni momento la produzione.

Modello a Spirale

Le fasi di analisi cicliche, ideate da Boehm, sono

  • determinazione degli obiettivi, delle alternative e dei vincoli
  • valutazione di eventuali alternative e identificazione dei rischi
  • fase di sviluppo e di verifica
  • pianificazione nei dettagli della fase successiva

Sempre Boehm, in seguito, creò a questo la variante Win Win, attraverso la quale si ottimizzano le specifiche tramite una contrattazione tra programmatore e utente: entrambi avranno l’illusione finale di aver vinto (win) circa le proprie idee.

Modello COTS (component of the shelf)

Perchè sono obbligato a ripartire sempre dal principio e riscrivere sempre le stesse cose partendo da zero? Ecco che, finalmente, il riutilizzo del codice diventa importante. Nascono le librerie, che raccolgono le funzioni base più utilizzate.

Una volta che avrò raccolto le specifiche del sistema, dovrò guardarmi in giro per cercare qualcosa di già pronto e il più simile a quanto mi è necessario: potrò anche andare a variare le specifiche, semplificandole, per adattarmi a quanto trovato.

Difetti: se così possono essere definiti le difficoltà di archiviazione dei moduli e la capacità di ricerca degli stessi.

Modello Agile Programming

Il modello Agile Programming (che comprende anche il modello dell’eXtreme Programming) è un modello che prevede un continuo contatto con il cliente/utente, in modo da facilitare la richiesta di requisiti e la soluzione ad alcuni dubbi o problemi sollevati dallo sviluppo. Non esiste una vera documentazione scritta come nella maggior parte dei modelli analizzati: il codice è scritto secondo convenzioni e standard tali da permetterne in maniera molto rapida (agile) l’analisi.

Introduce quattro variabili: portata (il numero di funzionalità del sistema), tempistiche (deadline – scadenze), qualità (quanto deve essere buono e bello il prodotto finale) e costo. Attraverso il dialogo, si porta l’utente/cliente a scegliere 3 di queste quattro variabili in modo da permettere di calcolare l’ultima anche se un cliente vorrà sempre tutto, in poco tempo, con la massima qualità e un costo pari a zero!!!

Il cliente ha il diritto di cambiare idea quando e come vuole, facendomi buttare quanto già fatto se di poca utilità o evitandomi del lavoro inutile. Grazie all’uso delle priorità, però, i lavori iniziali saranno sicuramente quelli più sicuri e assodati, che delineeranno il prodotto finale e permetteranno al cliente di aggiungere/modificare/eliminare tutte quelle funzionalità con bassa priorità.

Il tentativo di questi modelli è quello di ridurre al minimo i fallimenti, rilasciano piccoli “aggiornamenti” sensibili in finestre temporali di piccole dimensioni (qualche settimana circa), diminuire i costi di produzione e godere della piena soddisfazione del cliente.

Bookmark and Share

Commenti a “Ingegneria del Software: modelli di ciclo di vita”

  • mmm come faccio ad identificare il modello che utilizzo?
    ad esempio cerco di capire ciò che vuole il cliente, poi lo analizzo, poi lo sviluppo e testo in locale e poi lo mostro al cliente in una sorta di demo; quindi un modello a cascata per le varie fasi, ma anche incrementale perché molte volte modifico l’analisi, dovuto al fatto che cerco sempre componenti già realizzati, secondo quanto definito nel modello COTS.
    una volta mi è capitato di utilizzare il modello a V poiché il cliente non sapeva bene cosa volesse, ho iniziato secondo le prime richieste frammentarie e alla fine siam riusciti a sfornare il prodotto finale.

Lascia un commento

Ti ricordo che è sempre necessario trascrivere le due parole che leggi nel box rosso. È una misura antispam.