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
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;
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.
