Ciclo di vita del software
Definizione
Caratteristico di un prodotto di IS è il suo ciclo di vita, cioè l'insieme degli stati che il prodotto assume dal concepimento al ritiro[1]. Senza di esso non esisterebbe la figura dell'ingegnere del software. Conviene vedere il ciclo di vita come una macchina a stati, in cui gli stati sono il grado di maturazione del prodotto e gli archi rappresentano attività (suddivise in processi) che servono a far avanzare il prodotto nel suo grado di maturazione. La durata temporale entro uno stato del ciclo di vita e un altro è detta fase. Misura del successo di un prodotto è un ciclo di vita lungo, speso per lo più in manutenzione, magari con un buon feedback da parte degli utenti. Distinguiamo tre tipi di manutenzione:
- correttiva
:(per correggere difetti; - di adattamento
:|per adattare il sistema a variazioni di requisiti; - evolutiva
;)per aggiungere funzionalità al sistema.
Esempio di manutenzione evolutiva è Firefox.
Modelli di ciclo di vita
I processi software, di per sé, non seguono un ordinamento; le relazioni temporali e logiche tra essi sono fornite da un modello di ciclo di vita. Esistono diversi possibili cicli di vita, che si distinguono non per numero o significato degli stati, bensì per le transizioni tra essi e le loro regole di attivazione. Alcuni modelli di ciclo di vita sono:
- sequenziale — tipo catena di montaggio;
- incrementale — realizzazione in più passi, con numero crescente di funzionalità;
- evolutivo — con ripetute iterazioni interne;
- a spirale — contesto allargato e modello astratto;
- agile — dinamico, a cicli iterativi e incrementali.
È bene tenere a mente che i vari modelli, per quanto differiscano tra di loro in questo o in quel dettaglio, si possono dividere in due grandi famiglie: quelli sequenziali e quelli iterativi; i modelli incrementale, evolutivo, a spirale e agile sono tutti esempi di modelli iterativi.
In genere un modello del ciclo di vita di un prodotto[2] include un modello del ciclo di vita dello sviluppo[3] (più eventuali altri processi che riguardano fornitura, manutenzione, evoluzione...). Attenzione: il ciclo di vita dello sviluppo non deve per forza seguire lo stesso modello del ciclo di vita dell'intero prodotto!
Tra le qualità che contraddistinguono l'IS — sistematicità, disciplina, quantificabilità — i modelli di ciclo di vita nascono con l'obiettivo di perseguire la quantificabilità, che è la più difficile da soddisfare.
Il modello sequenziale
Nel 1970, grazie a Winston Royce, venne ideato il modello sequenziale (o a cascata), ispirato alle catene di montaggio. Questo è una successione di fasi rigidamente sequenziali. Il modello originale prevede che non si possa mai essere in due stati diversi allo stesso tempo e che non si possa tornare ad uno stato precedente. Il passaggio da una fase alla successiva è basato sulla documentazione: ogni fase produce documenti che la concretizzano e devono essere approvati per il passaggio alla fase successiva. Nello specifico, ogni fase viene definita in termini di:
- attività previste;
- prodotti attesi in ingresso;
- prodotti attesi in uscita;
- ruoli coinvolti;
- scadenze di consegna.
Questo modello ha il pregio di individuare fasi distinte e ordinate nelle quali decomporre il progetto. Suo difetto principale è l'eccessiva rigidità. Tuttavia questo approccio può funzionare se il cliente è consapevole (e abbastanza sicuro) di ciò che vuole, pur tenendo conto che il modello genera software vero e proprio molto tardi nel ciclo di vita.
Allora, si pensò di correggere il modello creando un "ibrido", introducendo dei prototipi "usa e getta" oppure la possibilità di tornare ad uno stato precedente. Tuttavia risalire la cascata fa risalire il progetto nel tempo e genera iterazioni, non incrementi.
Il modello incrementale
Per superare le difficoltà del modello sequenziale ibrido, nacque il modello incrementale: in esso, i cicli non sono più iterazioni ma incrementi — con l'eccezione dell'analisi e della progettazione, che si affrontano all'inizio e non vengono ripetute. Il modello prevede rilasci multipli e successivi; ciascuno realizza un incremento di funzionalità, approssimando sempre meglio la soluzione. Un grande vantaggio è che le funzionalità più importanti vengono affrontante all'inizio. Questo modello è meno idealista ma più gentile.
Il modello evolutivo
Il modello evolutivo, che è incrementale, prevede che gli incrementi successivi siano versioni (prototipi) usabili dal cliente. Più versioni posso essere mantenute in parallelo e ogni fase ammette iterazioni multiple.
Il modello a spirale
Nel 1988 Barry Boehm propose il modello a spirale, che introduce il concetto di "rischio di progetto" (cercando di contenere tali rischi). Lo sviluppo procede a cicli sempre più lenti; difatti i cicli esterni sono così lenti che possono aderire, ognuno, ad un altro modello di ciclo di vita. Ad ogni ciclo si analizzano i rischi e si compiono simulazioni. Misura del successo di un progetto è il diametro della spirale. Questo modello viene usato solo da chi intraprende progetti sperimentali, che nessuno ha mai realizzato, e richiede forte interazione tra committente e fornitore. Un ciclo si articola generalmente in quattro momenti:
- definizione degli obiettivi;
- analisi dei rischi;
- sviluppo e validazione;
- pianificazione della successiva iterazione.
Il modello a componenti
Più pragmatico è il modello a componenti, che prevede l'integrazione di componenti già implementati. L'idea nasce dal fatto che molto di quel che ci serve fare è già stato fatto e molto di quel che faremo ci potrà servire ancora. Difatti, l'IS è un insieme di best practices che assembla componenti già esistenti, più che crearle ex novo.
I metodi agili
I metodi agili nascono alla fine degli anni '90 come reazione all'eccessiva rigidità dei modelli allora in vigore. Si basano su quattro princìpi:
- individuals and interactions over processes and tools;
- working software over comprehensive documentation;
- customer collaboration over contract negotiation;
- responding to change over following a plan.