Fasi del ciclo di vita del software in informatica

Nell’ambito informatico, con il termine “ciclo di vita” del software ci si riferisce alle fasi attraversate da un progetto software durante la sua evoluzione, dall’idea iniziale alla manutenzione. Il risultato finale è il prodotto software stesso, accompagnato da tutta la documentazione ad esso associata. Vengono elencate e descritte le fasi comprese nella struttura base di un progetto software:

1. Raccolta dei requisiti
2. Analisi
3. Progettazione
4. Implementazione
5. Test
6. Installazione in produzione
7. Manutenzione (ordinaria ed evolutiva)

Raccolta dei requisiti ed analisi

Il progetto inizia con la fase di raccolta dei requisiti. In questa fondamentale fase vengono adottate e combinate tra loro diverse tecniche volte ad “estrarre dalla mente del cliente o del committente tutto ciò che il progetto software dovrà fare”. Il “Manuale dell’Analista” definisce questa fase come requirement elicitation, che può essere svolta con una combinazione di 12 metodi diversi quali ad esempio: Interviste, Osservazioni sul campo, Gruppi di Lavoro, ecc. Il termine elicitazione è mutuato dalla psicologia e significa “tirare fuori” informazioni, in questo caso, mediante domande o altri comportamenti stimolanti. Alla fase di raccolta requisiti segue quella di analisi. Fase estremamente importante, in quanto un errore commesso a questo punto può avere ripercussioni molto serie sul risultato finale.

A seconda delle dimensioni del progetto l’analisi può essere svolta in toto all’inizio, oppure iterativamente durante il processo. A seconda del modello di sviluppo che viene adottato, l’analisi può essere ripetuta o meno durante il ciclo di vita del software. L’obiettivo della fase di analisi è la descrizione completa e formalizzata, con un livello di dettaglio adeguato di tutto ciò che il sistema deve fare (requisiti funzionali), dell’ambiente in cui dovrà operare (requisiti non funzionali) e dei vincoli che dovrà rispettare. Notare che la descrizione specifica cosa il sistema dovrà fare, non il come (modello a scatola nera). Queste descrizioni vengono raccolte in documenti chiamati documenti di specifica, brevemente specifiche.

La fase di progettazione (Design)

Partendo dall’output della fase di analisi, che deve essere preciso e privo di ambiguità, la fase di progettazione definisce le istruzioni operative per la realizzazione del progetto (dettagli implementativi). Le istruzioni devono avere il giusto livello di dettaglio ed essere raccolte in documenti opportunamente strutturati. Pertanto, la progettazione di un’applicazione è composta dalle attività per individuare la soluzione implementativa migliore rispetto agli obiettivi funzionali, a quelli non funzionali ed ai vincoli. Queste attività possono essere di varia natura, possono essere svolte in tempi e modi diversi in base all’approccio seguito, ma in generale aiutano progettisti e team di sviluppo a prendere decisioni importanti, spesso di natura strutturale.

Il risultato della progettazione è la definizione dell’architettura del sistema, intendendo con questo termine l’organizzazione strutturale del sistema stesso, che comprende i suoi componenti software, le proprietà visibili esternamente di ciascuno di essi (l’interfaccia dei componenti) e le relazioni fra le parti. In analisi, requisiti e struttura del sistema sono rappresentati in forma astratta e (teoricamente) indipendente dalla tecnologia. La progettazione tiene conto anche di tutti i fattori relativi all’utilizzo di una tecnologia concreta e quindi, a differenza dell’analisi, la progettazione non può essere svolta indipendentemente dalla tecnologia utilizzata. Durante la progettazione devono anche essere definiti tutti gli aspetti necessari per una implementazione non ambigua. Uno strumento molto usato nella progettazione è il diagramma di flusso, oppure la sua evoluzione UML activity diagram. Entrambi gli strumenti servono a realizzare la scomposizione delle attività da compiere in elementi sempre più piccoli che possano essere facilmente implementati con opportuni insiemi di istruzioni del linguaggio di programmazione scelto.

La fase di implementazione (Coding)

La scrittura del codice sorgente può essere svolta con molti strumenti, il più semplice dei quali è l’editor di file ASCII di base (notepad, gedit, vi, emacs, ecc.). Per la complessità che i moderni linguaggi ad oggetti richiedono però tale approccio è troppo poco produttivo. Dovendo infatti garantire il rispetto di tempi stretti, è necessario disporre di tutte le funzioni di facilitazione integrate entro un unico strumento per la scrittura del codice sorgente. Un Integrated Development Environment (IDE), è un software che aiuta i programmatori nello sviluppo del codice. Normalmente consiste in un editor di codice sorgente, un compilatore e/o un interprete, un tool di building automatico, e (solitamente) un debugger.

Ormai sempre più spesso è integrato con sistemi di controllo di versione (SVN o GitHub, ad esempio), con sistemi di gestione delle dipendenze da librerie esterne (Maven, ad esempio) e con uno o più tool per semplificare la costruzione di una GUI. Alcuni IDE, rivolti allo sviluppo di software orientato agli oggetti, comprendono anche un navigatore di classi, un analizzatore di oggetti e un diagramma della gerarchia delle classi. Sebbene siano in uso alcuni IDE multi-linguaggio, come Eclipse, NetBeans e Visual Studio, generalmente gli IDE sono rivolti ad uno specifico linguaggio di programmazione.

La scrittura del codice sorgente, per quanto spesso poco considerata, rimane comunque la fase fondamentale di ogni progetto informatico. L’analisi e la progettazione possono essere state svolte al meglio, ma, se il codice viene scritto male, l’applicazione risultante avrà problemi e funzionerà male. Facendo un’analogia nell’ambito dell’ingegneria civile, è chiaro che anche il progetto più bello, se i pilastri non sono fabbricati bene, se i mattoni non sono posati con accuratezza o se i materiali impiegati sono di scarso pregio, darà origine ad un edificio di pessima qualità. Anche per questo, metodologie di programmazione più moderne tendono a fare diventare la fase di scrittura del codice quella principale in tutto il progetto informatico. Durante la stesura del codice ha luogo anche il primo debugging, ossia la rimozione degli errori di sintassi e degli errori più evidenti, come la mancata inizializzazione di variabili, che possono compromettere la compilazione o il funzionamento del programma. Gli IDE più moderni hanno ottimi sistemi di live debug. Tendono ad evidenziare in tempo reale, oltre al codice che inevitabilmente porterà ad errori di compilazione, anche frammenti di codice inutili, blocchi ripetuti, inizializzazioni di variabili non necessarie, ecc.

La fase di Test

Una volta che il programma è stato completato o comunque può iniziare a funzionare, occorre verificare che il suo funzionamento sia conforme a tutte le specifiche che erano state stabilite nella fase di analisi. Questo è lo scopo fondamentale della fase di test. Gli errori che portano al non rispetto delle specifiche sono di solito molto più insidiosi da scoprire rispetto a quelli che vengono trovati durante il debugging. Non sono errori di sintassi, ma errori logici e concettuali, come, per esempio, lo scrivere il segno ‘+’ invece del segno ‘-‘ entro un algoritmo che richieda la sottrazione e non la somma. La fase di test prevede quindi di verificare il comportamento effettivo del programma rispetto a quello previsto e di segnalare le differenze di comportamento ai programmatori che dovranno procedere alla ricerca e all’eliminazione delle cause di tali differenze.

I modelli di sviluppo software più moderni pongono l’accento sulla fase di test, anteponendola in alcuni casi alla fase di sviluppo e prevedendo l’esistenza di suite di test eseguite automaticamente durante la build ed il packaging del progetto, allo scopo di ridurre il più possibile il rischio di regressione.

La fase di avvio ed entrata in produzione

Dopo il test, raggiunto un livello sufficiente di qualità, il programma può entrare in produzione. Questo termine ha un significato diverso secondo il tipo di programmi in realizzazione. Per i programmi destinati alla vendita presso il pubblico, o alla distribuzione se gratuiti, questa fase rappresenta il rilascio sul mercato, fisico (negozio), virtuale (ecommerce, download) o mobile (PlayStore, AppStore) che sia. Per i programmi realizzati specificatamente per un cliente (i cosiddetti “programmi custom”), questa fase rappresenta l’installazione ed il collaudo presso la sede del cliente che li ha richiesti. In ultimo, per le applicazioni web (siti di e-commerce, portali, gaming-on-line, ecc) rappresenta l’installazione ed il collaudo su uno o più server web (Apache, Tomcat, IIS, ecc) ed il tuning di questi ultimi.

Al termine di questa fase i programmi iniziano la propria vita operativa, durante la quale svolgono il compito previsto nel contesto per cui sono stati progettati, che può proseguire anche per molti anni.

La fase di Manutenzione

Durante la vita operativa possono verificarsi necessità di interventi correttivi o di aggiornamento sui programmi, che prevedono nuove fasi di progettazione, implementazione e test. Tali interventi correttivi sono raggruppabili in due distinte famiglie:

1. Manutenzione ordinaria, l’insieme di interventi correttivi necessari per via di errori sfuggiti ai test o dovuti al funzionamento del programma in condizioni non previste durante la sua progettazione;
2. Manutenzione evolutiva, l’insieme di interventi di variazione od arricchimento delle funzioni del programma per via di nuove necessità operative del programma stesso; un esempio è l’aggiornamento continuo dei programmi gestionali per stare aggiornati rispetto alle normative fiscali. In generale, comunque, ogni programma durante la sua vita è soggetto a interventi evolutivi e correttivi. Solo una piccola percentuale di programmi non viene più toccata dopo il rilascio.