Ciclo di vita del software
Da Wikipedia, l'enciclopedia libera.
L'espressione ciclo di vita 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 a esso
associato.
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.
Storicamente, il primo ciclo di vita del software di larga diffusione è stato il modello a cascata.
Esso suddivideva il processo software in un insieme di fasi che si ritrovano quasi puntualmente nei
modelli moderni (che spesso si discostano dal modello a cascata su altri aspetti, quali l'ordine in
cui devono essere svolte le attività corrispondenti alle varie fasi, o l'enfasi relativa che va
assegnata a ciascuna di esse).Ogni fase produce un output che è usato come input per la fase
successiva. In linea di massima vengono individuate 5 fasi:
1. Analisi e Specifica dei requisiti di che cosa fa il sistema
2. Progettazione che permette di specificare come è fatto il sistema
3. Codifica, la fase classifica di scrittura del codice
4. Integrazione e verifica, controllo del buon funzionamento
5. Consegna e manutenzione, tutto ciò che accade a sistema funzionante
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.
Esistono altri modelli di cicli di vita del software:
1. Evolutivo
2. Trasformativo
3. A spirale (è un metaprocesso)
Modello a cascata
La maggior parte dei modelli di ciclo di vita del software comprendono un insieme comune di
attività, elencate di seguito. Dev'essere tuttavia chiaro che il fatto che tali fasi debbano essere
eseguite in sequenza (come l'impaginazione necessariamente suggerisce) non è vero per tutti i
modelli. Ci si è inoltre limitati alle "macro-fasi", suggerendo di alcune di esse alcune ulteriori
scomposizioni tipiche e comuni a molti modelli di ciclo di vita del software.
la fase di analisi, ovvero l'indagine preliminare sul contesto in cui il prodotto software deve
inserirsi, sulle caratteristiche 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 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;
la fase di progetto, in cui si definiscono le linee essenziali della struttura del sistema da
realizzare, in funzione dei requisiti evidenziati dall'analisi e dal documento finale da essa
creato. Anche questa fase può essere scomposta in sottoattività, dal progetto architetturale
al progetto dettagliato. Si può dire che il progetto ha lo scopo di definire (a un certo livello
di dettaglio) la soluzione del problema. In questa fase verrà sviluppando 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);
la fase di implementazione o codifica del sistema, ovvero la sua realizzazione concreta;
questa tipicamente 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 e via dicendo). 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. Complessivamente, l'implementazione ha lo scopo di realizzare la
soluzione.
la fase di testing, volta a misurare in che misura il sistema realizzato soddisfa i requisiti
stabiliti nella fase di analisi, ovvero a valutarne la correttezza rispetto alle specifiche.
Anche il testing è normalmente scomponibile almeno nelle due attività del testing dei
singoli moduli e testing del sistema integrato. Le tipologie specifiche di test (prove) si
possono inoltre distinguere in funzione dei particolari aspetti dei moduli o del sistema che
vengono valutati; si parla per esempio di test funzionali, test di performance, test di
accettazione, test d'istallazione;
la fase di manutenzione, che comprende tutte le attività di modifica del software successive
al suo rilascio presso il cliente o la sua immissione sul mercato. Queste attività possono
essere volte a correggere errori del software, adattarlo a nuovi ambienti operativi, o
estenderne le funzionalità. La manutenzione incide sui costi, si stima che il 60% dei costi
dipende dalla manutenzione. Ogni modifica al software comporta necessariamente la
necessità di nuovi test, sia relativi alle nuove funzionalità eventualmente introdotte, sia
mirati a verificare che le modifiche apportate non abbiano compresso funzionalità
preesistenti (test di regressione). Una linea standard di verifica prevede dei test sui moduli
più precisamente si occupa di controllare che i moduli presi singolarmente funzionino e che
una volta assemblati assieme i moduli continuino a funzionare.
Modello evolutivo
Questo modello si propone di superare i limiti principali del modello a cascata, come la mancanza
di incrementalità e l'inadeguatezza a supportare l’evoluzione dell'applicazione. E’ costituito da
poche fasi che si ripetono e che prevendo questa sequenza:
1. Costruisci qualcosa
2. Consegnalo all’utente
3. Ottieni delle valutazioni
4. Modifica il manufatto in funzione delle valutazioni
Il rischio nell'attuazione di questo modello, è di essere indisciplinati, e si renderà necessario far
uso di standard di processo. Gli strumenti moderni sono adatti a supportare questo tipo di modello
accompagnati da certificazioni di qualità di processo.
Analisi dei requisiti
In ingegneria del software, l'analisi dei requisiti (talvolta detta semplicemente analisi)
rappresenta una delle prime fasi nel ciclo di vita di un prodotto software; scopo generale
dell'analisi è stabilire cosa il sistema in questione deve fare (mentre le decisioni sul come sono
rimandate alla successiva fase di progetto).
L'analisi dei requisiti avviene normalmente come negoziazione fra individui legati allo sviluppo
(analisti) e i clienti, oppure (nel caso di pacchetti software pensati per la grande distribuzione) fra
analisti e responsabili del marketing. Tale dialogo è tutt'altro che semplice: gli analisti possono
avere difficoltà a comprendere il linguaggio e il contesto culturale del cliente, e viceversa; e lo
stesso cliente potrebbe aver difficoltà a mettere a fuoco i propri reali bisogni e di conseguenza le
richieste o le proposte da mettere sul tavolo della discussione. Proprio a causa di queste difficoltà,
i modelli di ciclo di vita del software moderni hanno abbandonato l'assunzione che sia possibile
identificare i requisiti di un sistema software a priori, e tendono a privilegiare approcci iterativi in i
requisiti vengono esplicitati gradualmente, per esempio coinvolgendo l'utente nella prova di
prototipi e rilasci parziali del sistema in corso di sviluppo.
Il documento principale prodotto dall'analisi dei requisiti è la specifica dei requisiti; se la
metodologia e il modello di ciclo di vita del software utilizzati lo prevedono, essa può addirittura
portare già alla stesura del manuale d'uso del prodotto da sviluppare.
L'analisi dei requisiti è spesso accompagnata da altre attività di analisi come l'analisi del dominio o
l'analisi dei costi e benefici.
Analisi delle funzioni con i data flow diagram
La definizione delle funzionalità che il sistema deve offrire è importante e critica. Per un verso, costituisce la
base dell'accordo tra i committenti ed il gruppo di progetto, sulla cui base vengono concordati costi e tempi
di realizzazione; allo stesso tempo rappresenta l'input primario per le fasi di progettazione tecnica e di
realizzazione e test del sistema. La definizione deve risultare quindi chiara, non ambigua, completa,
sufficientemente dettagliata.
Esistono tecniche di analisi strutturata, che da oltre vent'anni forniscono una guida per la scoperta e la
definizione delle caratteristiche funzionali dei sistemi. Vengono utilizzati dei data flow diagram, che
permettono di partire dalla definizione del contesto del sistema, per poi arrivare alle tecniche utilizzabili per
la scomposizione in sottoprocessi, fino alla definizione dei processi elementari ed alla loro specifica.
Il Data Flow Diagram è un tipo di diagramma definito nel 1978 da Tom Demarco nel testo Structured
Analysis and Systems Specification per aiutare nella definizione delle specifiche.
É una notazione grafica molto usata per i sistemi informativi e per la descrizione del flusso di dati in quanto
permette di descrivere un sistema per livelli di astrazione decrescenti con una notazione di specifica molto
"intuitiva".
Attraverso i Data Flow Diagram si definiscono soprattutto come fluiscono (e vengono elaborate) le
informazioni all’interno del sistema, quindi l'oggetto principale è il flusso delle informazioni o, per meglio
dire, dei dati. Motivo per il quale diventa fondamentale capire dove sono immagazzinati i dati, da che fonte
provengono, su quale fonte arrivano, quali componenti del sistema li elaborano.
Componenti
Le componenti di questo tipo di diagramma sono:
Funzioni, rappresentate da bolle;
Flussi di dati, rappresentati da frecce;
Archivi di dati, rappresentati da scatole aperte;
Agenti esterni o Input/Output di dati, rappresentati da scatole chiuse.
Funzioni
Le funzioni rappresentano unità di elaborazione dei dati: trasformano i dati in ingresso in quelli in uscita
Flusso di dati
Le frecce collegano i diversi componenti di un diagramma tra loro:
Rappresentano i dati gestiti dal sistema;
Gli archivi e gli agenti esterni NON possono essere collegati tra loro;
Agente esterno
Gli Agenti Esterni rappresentano delle entità esterne al sistema:
Non sono soggette ad ulteriore modellazione;
Sono le sorgenti e le destinazioni dei dati del sistema;
Archivi
Gli archivi sono dei depositi permanenti di informazione:
Possono essere basati su qualunque tecnologia;
I dati che entrano in un archivio vengono scritti;
I dati che escono dall’archivio sono letti (ma non cancellati);
Modellazione
Un generico sistema è sempre rappresentabile nel seguente modo:
Se gli ingressi e/o le uscite sono molteplici si introducono nuovi flussi.
Questo tipo di rappresentazione ha un livello di astrazione molto alto e individua solo l’interfaccia tra il
sistema e il mondo esterno per cui vanno inseriti altri dettagli raffinando le funzioni. Ogni funzione, infatti, è
a sua volta specificabile mediante un Data Flow Diagram per cui è possibile ottenere diversi livelli con sempre
maggiore definizione.
Criteri di stesura
Nella stesura si ignora l’inizializzazione del sistema, la gestione degli errori e la terminazione, il sistema si
immagina come "up & running". Si ignorano anche le sincronizzazioni ed il flusso di controllo tra processi.
Individuare sempre le entrate e le uscite di un diagramma
Qualora i dati gestiti fossero particolarmente strutturati si complementa il Data Flow Diagram con un sistema
complementare.
Limiti
Questa notazione, quindi, presenta dei limiti consistenti:
Semantica: i simboli non sono sufficientemente chiari e i nomi vengono scelti dall’utente;
Controllo: gli aspetti di controllo non sono definiti dal modello e, quindi, anche la sequenza temporale
è poco chiara.
Quindi il Data Flow Diagram è adatto ad una descrizione rapida e intuitiva per cui non è una notazione
operazionale proprio perché alcuni aspetti non sono chiariti. Per questo motivo si parla di notazione
semiformale perché la sintassi è precisa, ma la semantica non lo è.
Si sono progettati diversi metodi per rimediare a queste difficoltà che possono essere classificati nel seguente
modo:
Usare una notazione complementare per colmare le lacune del data flow diagram;
Migliorare il modello in modo da completare la versione tradizionale
L'analista programmatore
Il lavoro dell'analista programmatore consiste nell’analizzare ed interpretare le esigenze degli utenti, nonché
nell’incaricarsi della progettazione, codifica e documentazione, collaudo e manutenzione dei programmi
(software) creati in risposta a tali esigenze. L'analista programmatore è perciò colui che sviluppa l'analisi di
un problema in termini informatici, e partecipa anche alla stesura dei programmi.
In alcune realtà, la figura dell'analista programmatore si può suddividere in due figure distinte: quella
dell'analista e quella del programmatore. L'analista si occupa della prima delle due fasi accennate
precedentemente: l'analisi delle esigenze del cliente e la traduzione di queste ultime in un progetto
funzionante attraverso il coordinamento di un gruppo di programmatori. Il programmatore, si occupa della
seconda fase: lo sviluppo del software nei vari linguaggi partendo dal progetto di un analista. L'analista
programmatore opera in genere all'interno di grandi imprese dotate di propri centri di elaborazione, nelle
software house (società che creano i software), in società di servizi, studi di consulenza, centri di ricerca
nonché in ambito universitario. I tempi medi di un progetto cui un analista programmatore prende parte sono
intorno ai sei mesi, ma su un caso particolarmente complesso o di grandi dimensioni il suo lavoro può
protrarsi anche uno-due anni. Il lavoro dell'analista programmatore si svolge a ritmi serrati, spesso si lavora
"a scadenza" per cui i suoi orari risultano piuttosto flessibili. L'analista programmatore può essere un
lavoratore dipendente o un libero professionista.
L'insieme delle attività dell'Analista programmatore può essere suddiviso in quattro fasi, una conseguente
all'altra:
dopo aver individuato le esigenze del cliente, egli elabora un documento con: i requisiti che il
software dovrà soddisfare; lo studio di fattibilità; l'analisi dei costi;
partendo da questo documento, l'analista programmatore elabora il progetto, realizza il software e
documenta l'intero procedimento;
effettua il collaudo, prima della consegna al cliente;
provvede alla manutenzione del programma, vale a dire ad apportare tutte le modifiche necessarie
per il suo buon funzionamento.
COMPETENZE
Per svolgere il suo lavoro, l'Analista programmatore deve:
instaurare un rapporto produttivo con il cliente, comprenderne i problemi e le richieste;
conoscere la logica e un certo numero di linguaggi di programmazione
essere in grado di sviluppare adeguate metodologie per i test;
saper documentare, con sintesi e chiarezza, i procedimenti tecnici.
In termini più generali, tra le competenze richieste spiccano:
conoscenza della lingua inglese tecnica;
flessibilità;
capacità di analisi;
capacità di operare in team.
Fondamentale è, inoltre, il continuo aggiornamento (learning).
