Ciclo di vita del software

Da Wikipedia, l'enciclopedia libera.

Il ciclo di vita del software, in informatica, e in particolare nell'ingegneria del software, si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività di realizzazione di prodotti software in sottoattività fra loro coordinate, il cui risultato finale è il prodotto stesso e tutta la documentazione ad esso associata. Fasi tipiche includono lo studio o analisi, la progettazione, la realizzazione, il collaudo, la messa a punto, la manutenzione e l'estensione.[1]

Storia[modifica | modifica sorgente]

La comparsa in letteratura e nella pratica dello sviluppo del software dei concetti di ciclo di vita e di processo software si può far coincidere con la nascita dell'ingegneria del software, in quanto rappresenta un passaggio storico dallo sviluppo del software inteso come attività "artigianale" (ovvero affidata alla libera creatività dei singoli individui) a un approccio più industriale, in cui la creazione di programmi e sistemi software viene considerata come un processo complesso che richiede pianificazione, controllo, e documentazione appropriati (così come avviene tradizionalmente nei settori più maturi dell'ingegneria).

Questa transizione si può ricondurre, in ultima analisi, all'aumentata complessità dei sistemi, all'avvento di un vero e proprio mercato del software, nonché a nuovi e più stringenti requisiti di qualità, legati per esempio all'uso di sistemi informatici in contesti critici (centrali energetiche, sistemi aerospaziali, armamenti e così via). Questo mutamento di prospettiva iniziò a verificarsi, storicamente, fra la fine degli anni sessanta e l'inizio della decade successiva. Da allora, la ricerca su questi temi è stata estremamente prolifica sia in ambito industriale che accademico.

Le attività fondamentali[modifica | modifica sorgente]

Quasi tutti i modelli di ciclo di vita del software prevedono una scomposizione del processo di sviluppo in insiemi di attività simili (quando non addirittura identici). Le distinzioni fra diversi cicli di vita si evidenziano su altri aspetti, quali:

  • l'enfasi relativa che si attribuisce a ciascuna attività;
  • l'individuazione degli attori specifici incaricati di ciascuna attività;
  • l'ordine in cui le attività si svolgono.

In tutti i cicli di vita del software svolge inoltre un ruolo essenziale la documentazione dei prodotti delle varie sottoattività; la stesura della documentazione viene quindi regolamentata nello stesso modo delle attività menzionate.

Analisi[modifica | modifica sorgente]

L'analisi è l'indagine preliminare del contesto in cui il prodotto software deve inserirsi, sulle caratteristiche o requisiti che deve esibire ed eventualmente su costi e aspetti logistici della sua realizzazione; questa fase può essere scomposta in sottoattività quali analisi di fattibilità, analisi e modellazione del dominio applicativo, analisi dei requisiti e così via. In senso più ampio si può dire che l'analisi ha lo scopo di definire (il più precisamente possibile) il problema da risolvere. Questa fase è costituita anche da raccolta dei dati tramite colloqui tra cliente/committente e relativi sviluppatori. Al termine della fase verrà creato un documento che descrive le caratteristiche del sistema, tale documento viene definito documento di specifiche funzionali.

Progettazione[modifica | modifica sorgente]

Nell'attività di progettazione si definiscono le linee essenziali della struttura del prodotto software in funzione dei requisiti evidenziati dall'analisi, tipicamente appannaggio di un analista programmatore. Anche la progettazione può essere scomposta in sottoattività, dal progetto architetturale al progetto dettagliato. Si può dire che la progettazione ha lo scopo di definire (a un certo livello di dettaglio) la soluzione del problema. In questa fase sarà sviluppato un documento che permetterà di avere una definizione della struttura di massima (architettura di alto livello) e una definizione delle caratteristiche dei singoli componenti (moduli).

Implementazione[modifica | modifica sorgente]

L'implementazione, detta anche sviluppo o codifica del prodotto software, è la fase di programmazione vera e propria da parte di uno o più programmatori e consiste nella realizzazione di uno o più programmi in un determinato linguaggio di programmazione, benché possano essere coinvolte anche tecnologie diverse (database, linguaggi di scripting ecc...). L'infrastruttura utilizzata in tale fase è detta ambiente di sviluppo (spesso in locale sui PC degli sviluppatori). Si può dire che l'implementazione è la concreta realizzazione della soluzione. Nella maggior parte dei casi è possibile distinguere almeno una sottoattività di implementazione dei singoli moduli che costituiscono il sistema e la sottoattività dell'integrazione di tali moduli a formare il sistema complessivo.

Tipicamente in questa fase si usano strumenti di sviluppo noti come software development kit (SDK) e sistemi di controllo versione delle varie versioni software rilasciate dai componenti del team di sviluppo (es. CVS, Subversion, GIT, ecc...), mentre la documentazione relativa al codice scritto si ottiene in maniera automatica a partire dai commenti scritti all'interno del codice sorgente attraverso tool opportuni. Il prodotto finale di questa fase solitamente è un software in versione alfa seguito da uno in versione beta con feedback da parte dei tester della successiva fase di collaudo, fino al rilascio della versione ultima che soddisfa le specifiche funzionali richieste.

Collaudo[modifica | modifica sorgente]

Il collaudo o testing, appannaggio di uno o più tester, consiste nella verifica e validazione di quanto (misurabilità) il prodotto software implementato soddisfi i requisiti individuati dall'analisi. La relativa infrastruttura di supporto utilizzata in tale fase è detta ambiente di testing; il collaudo, in altre parole, valuta la correttezza rispetto alle specifiche. Anche per il collaudo possono essere individuate le due sottoattività di collaudo dei singoli moduli e collaudo del sistema integrato; inoltre possono essere individuate ulteriori sottoattività per ogni aspetto del prodotto software che interessa collaudare: collaudo funzionale, collaudo di performance, collaudo di rottura, collaudo di regressione, collaudo di sicurezza, collaudo di accessibilità, collaudo di accettazione, ecc... . In caso di mancato rispetto delle specifiche il software, assieme al documento delle anomalie o bug, torna indietro agli sviluppatori con il compito di risolvere i problemi riscontrati attraverso anche il debugging del software. In genere le anomalie di funzionamento sono gestite tramite appositi software gestori di segnalazione anomalie, detti anche sistemi di ticketing o di bug tracking, che registrano i problemi segnalati al team di sviluppo e ne facilitano la relativa organizzazione, classificazione e gestione (p. es. Bugzilla, Mantis, Atlassian Jira, ecc.).

Rilascio[modifica | modifica sorgente]

Il rilascio o deployment consiste nell'installazione del prodotto software che ha superato il collaudo nell'infrastruttura di esecuzione utilizzabile dagli utenti detta anche ambiente di produzione. A seconda della complessità di tale infrastruttura il rilascio può essere scomposto in varie sottoattività; esso, infatti, può variare dalla semplice copia di un file, alla copia opportuna di molti file organizzati in una complessa gerarchia di directory e componenti software, eventualmente distribuiti su hardware differenti.

Manutenzione[modifica | modifica sorgente]

La manutenzione comprende quelle sottoattività necessarie a modifiche del prodotto software successive al rilascio, al fine di correggere ulteriori errori attraverso patch (manutenzione correttiva), adattarlo a nuovi ambienti operativi (manutenzione adattativa o migrazione di ambiente), estenderne le funzionalità (manutenzione evolutiva) o convertirne l'implementazione seconda altra struttura (es. migrazione di framework). La manutenzione incide sui costi per una stima che si aggira intorno al 60% dei costi totali. Ogni modifica al software comporta necessariamente la necessità di nuovi collaudi, sia relativi alle nuove funzionalità eventualmente introdotte, sia mirati a verificare che le modifiche apportate non abbiano compromesso funzionalità preesistenti (collaudo di regressione).

Documentazione software[modifica | modifica sorgente]

Parallelamente alle fasi di sviluppo di cui sopra è abitudine e buona norma da parte del team di progettazione, sviluppo e testing provvedere alla redazione della corrispondente documentazione che sarà corredata al software in fase finale o durante le singole fasi stesse a supporto della fase successiva.

Processi di sviluppo software[modifica | modifica sorgente]

La maggior parte delle metodologie di sviluppo del software consiste, almeno in linea di principio, in un linguaggio di modellazione e un processo.

  1. Il linguaggio di modellazione è la notazione usata dalle metodologie per esprimere le caratteristiche di progetto;
  2. il processo è l’elenco delle indicazioni riguardanti i passi da intraprendere per produrre il progetto stesso.

L’UML (Unified Modeling Language), ad esempio, è un linguaggio di modellazione, utilizzato dai processi per realizzare, organizzare, documentare i prodotti realizzati dalle fasi di cui il processo si compone. Coloro che, individualmente o in gruppo, lavorano allo sviluppo o alla modifica di un software, adottano necessariamente un certo approccio nel modo di relazionarsi con i propri clienti/utenti, nell'organizzare il proprio lavoro, nella scelta delle tecniche da utilizzare, adottano un processo.

In modo consapevole o meno, ogni sviluppatore (o gruppo di sviluppatori) software ha un proprio processo di sviluppo, cioè un proprio modo di lavorare, basato sulla propria esperienza, sulla propria cultura, e sul contesto culturale ed organizzativo in cui si trova ad operare.

La storia dei successi (e soprattutto degli insuccessi) dei progetti di sviluppo software ha insegnato che ogni processo di sviluppo ha i propri pregi ed i propri limiti e che un processo di sviluppo inadeguato alle concrete esigenze dello specifico progetto può condurre al fallimento del progetto stesso, o comunque all'insoddisfazione dei clienti/utenti e degli stessi sviluppatori.

Il ciclo di sviluppo del software, nella maggior parte dei casi, è iterativo, e ogni iterazione produce una sua release. Elenchiamo di seguito le fasi principali che possono far parte di ogni singola iterazione:

  1. Specifica dei requisiti: ciò che viene richiesto dal committente;
  2. Studio di fattibilità (make or buy);
  3. Analisi e Design dove per analisi si intende lo studio di cosa deve fare il sistema (punto di vista "logico") e per design lo studio di come il sistema deve essere implementato (punto di vista "tecnico"). Negli ultimi anni, la distinzione tradizionale tra analisi e design è entrata in crisi.
  4. Implementazione;
  5. Integrazione e test.

Se originariamente i modelli di ciclo di vita del software erano strumenti di natura esclusivamente concettuale, i moderni ambienti di sviluppo CASE (Computer aided software engineering) spesso automatizzano l'applicazione di un particolare ciclo di vita così come di altri aspetti di un processo software.

Alcuni esempi di modelli[modifica | modifica sorgente]

Modello a cascata[modifica | modifica sorgente]

Exquisite-kfind.png Per approfondire, vedi Modello a cascata.

Storicamente, il modello a cascata fu il primo modello di ciclo di vita del software. Prevede l'esecuzione sequenziale delle fasi di analisi, progetto, sviluppo, collaudo e manutenzione.

Modelli iterativi[modifica | modifica sorgente]

Nella categoria dei modelli iterativi rientrano tutti i processi di sviluppo che permettono di ritornare ad una fase del procedimento già affrontata in precedenza. Per ogni fase "iterabile" si tende a partire con un abbozzo della soluzione che verrà successivamente raffinata al prossimo passaggio.

I modelli incrementali ed evolutivi sono una specificazione dei modelli iterativi.

Modelli incrementali[modifica | modifica sorgente]
Exquisite-kfind.png Per approfondire, vedi Modello incrementale.
Modelli evolutivi[modifica | modifica sorgente]
Exquisite-kfind.png Per approfondire, vedi Modello evolutivo.

Secondo la visione più comune nella moderna ingegneria del software, il modello a cascata non è più adatto ad essere applicato, almeno per la maggior parte delle applicazioni. Fra gli elementi che hanno contribuito al tramonto di questo modello ci sono l'aumento di complessità delle applicazioni, l'introduzione delle GUI (che hanno portato all'attenzione dei progettisti questioni di usabilità precedentemente di scarso rilievo), e l'avvento di nuovi paradigmi di programmazione e metodologie di analisi e progetto, in particolare quelle legate al paradigma object-oriented.

In particolare, si sono affermati una vasta classe di cosiddetti modelli evolutivi, tutti basati sull'idea centrale di coinvolgere maggiormente il committente (o l'utente), sottoponendogli periodicamente versioni parziali o prototipi del prodotto finale. Una tecnica tradizionale in questo senso è, per esempio, quella della prototipazione rapida. In questa linea di pensiero una delle ultime generazioni è quella delle cosiddette metodologie agili.

Fasi del ciclo di vita[modifica | modifica sorgente]

Modelli di sviluppo del software e metamodelli di ciclo di vita[modifica | modifica sorgente]

Note[modifica | modifica sorgente]

  1. ^ (EN) N. D. Birrell e Martyn A. Ould, A Practical Handbook for Software Development, Cambridge University Press, 1988, ISBN 978-0-521-34792-1.

Voci correlate[modifica | modifica sorgente]