V-Model

Il V-Model è un modello del ciclo di vita del software per la pianificazione e l’esecuzione di progetti. Esso puo’ essere visto come un evoluzione del modello a cascata.

Osservando l’immagine del modello a V, possiamo vedere(figura 1) che il ramo  discendete comprende le fasi  della progettazione, la base del modello rappresenta l’implementazione e il ramo discendente comprende le fasi del testing e dell’integrazione del progetto.

Analizziamo, nel dettaglio, le single fasi del modello a V.

 

Requirements analysis

Questa fase ci occupa dell’analisi dei requisiti, cioè di stabilire quello che il sistema dovrebbe compiere, analizzando le necessità dell’utente finale. La raccolta dei requisiti avviene in diversi modi, tra i quali: interviste agli utenti dell’applicazione, questionari, schemi e prototipi.

Il mio punto di vista: Importante fase del ciclo di vita del software perché è in questa fase, attraverso la raccolta dei requisiti, che si riesce a capire cosa si aspetta il cliente e/o l’utente finale. Quindi è una fase dove si creano delle solide fondamenta di partenza del progetto.

System design

In questa fase i sistemisti creano la specifica dei requisiti del software, la specifica viene utilizzata come piano architetturale per la fase di sviluppo. Se si verifica che uno dei requisiti non sia fattibile, il cliente viene informato e insieme si trova una soluzione al problema riscontrato, di conseguenza il documento di requisiti viene modificato.

Nel piano architetturale troviamo, la struttura dei menu, la grafica, le strutture dati, ecc.

Il mio punto di vista: In questa fase si iniziano a creare i primi pilastri del progetto.  La cosa importante di questa fase è lo studio di fattibilità dei requisiti.

Architecture design

In questa fase viene selezionata l’architettura software/hardware che dovrebbe essere implementata. L’architettura ad alto livello descrive in breve la funzionalità di ogni modulo, la lista dei moduli, le relazioni di interfaccia, le dipendenze, i diagrammi architetturali, la struttura delle basi dati e i dettagli della tecnologia da usare.

Il mio punto di vista: In questa fase si iniziano a fare le prime scelte sull’architettura e tecnologia da usare. La cosa importante e scegliere un’architettura e una tecnologia flessibile e robusta che permetta un domani, nel caso in cui fosse richiesto, l’aggiunta di nuove funzionalità.

Module design

In questa fase abbiamo la progettazione a basso livello dei singoli moduli. Per ogni modulo si ha, a basso livello, la descrizione funzionale dettagliata. Il documento di progetto contiene tutti i dettagli per consentire al programmatore la codifica. In particolare troviamo I riferimenti delle API, tutti gli input e gli output, la lista degli allarmi, la lista degli errori, la lista degli attributi, le tabelle del database e le dipendenze.

Il mio punto di vista: Il moduli, essendo l’unità più piccola, sono i mattoni del progetto. I moduli dovrebbero, se possibile, essere realizzati con l’ottica del riuso del codice. Questo perché un domani, un modulo, potrebbe esse riutilizzato in un altro progetto.

Implementation

L’implementazione dei singoli moduli avviene seguendo i dettagli riportati nel documento di progetto e rispettando gli standard di codifica. Si hanno numerose revisioni del codice prima di ottenere un rilascio finale nel repository.

Il mio punto di vista: Nell’implementazione, se possibile, considererei la misura del costo logaritmico cioè il tempo di esecuzione di un algoritmo. Questo migliora l’efficienza del software.

Unit testing

Nella programmazione procedurale gli unit test sono le singole procedure o funzioni. In questa fase gli unit test vengono isolati dal resto dei codici per verificare se funzionano correttamente. Lo scopo è quello di eliminare i bug a livello di codice.

Il mio punto di vista: In questa fase si verificano gli input e gli output delle singole procedure o funzioni. L’ottimizzazione della singola unit test si riflette sul progetto finale.

Integration testing

I test di integrazione vengono eseguiti per testare la coesistenza e la comunicazione dei moduli all’interno del sistema. Lo scopo è quello di individuare gli errori nelle interfacce e nell’interazione tra componenti integrati. Esistono diverse tecniche e metodologie atte a verificare la correttezza delle integrazioni fra i singoli componenti, le piu comune sono top down, bottom up, sandwich e big bang.

Nell’approccio top down l’integrazione dei moduli parte dall’alto dell’albero e scende fino alle radici. La tecnica bottom up prevede la verifica dei moduli che non sono dipendenti da altri moduli e successivamente si sale nell’albero eseguendo un nuovo livello di controllo. L’approccio sandwich si usano contemporaneamente la tecnica bottom up e la tecnica top down. Nell’approccio big bang non si ha una strategia, ma si va direttamente al controllo unico di sistema. L’attività di integrazione viene condivisa con il team di progetto.

Il mio punto di vista: I test di integrazione portano alla visione di insieme del progetto. In questa fase si integrano i vari moduli del progetto e si verificano i requisiti, l’architettura e le funzionalità del sistema.

System testing

Il testing di sistema viene eseguito su un sistema completo e integrato. Ha lo scopo di verificare che il risultato ottenuto è conforme ai requisiti di sistema.  Questo avviene attraverso un piano di test ben strutturato che valuta il sistema su diversi aspetti. Gli aspetti principali sono:

  • Facility test mira a controllare che ogni funzionalità prevista nei requisiti sia stata implementata correttamente.
  • Security test verifica la sicurezza del sistema.
  • Usability test verifica la facilità d’uso del sistema da parte dell’utente finale.
  • Performance test verifica l’efficienza del sistema in base ai tempi di elaborazione e ai tempi di risposta.
  • Storage use test verifica l’efficienza del sistema in particolar modo la richiesta di risorse(memoria).
  • Volume test verifica le funzionalità del sistema in una condizione di carico di lavoro massimo previsto dai requisiti.
  • Stress test verifica la capacità di recovery sottoponendo il sistema ad un carico di lavoro superiore a quello previsto dai requisiti.
  • Configuration test verifica tutte le configurazioni previste dal sistema.
  • Compatibility verifica la compatibilità del sistema con altri prodotti software.

Il mio punto di vista: E’ la fase in cui si valuta la funzionalità, l’affidabilità, l’efficienza e la portabilità del sistema.

User acceptance testing

E’ la fase finale in cui il fornitore verifica che il prodotto consegnato rispetta i requisiti del committente. Questo avviene tramite il collaudo di accettazione.

Il mio punto di vista: La soddisfazione del cliente è una grande leva motivazionale che fa crescere il team di progetto.