Menu

separate-gade-ribaltata

Triple-V-Model

separate-gade

Descrizione del modello

Il modello a "V" rappresenta un processo di sviluppo software (applicabile anche allo sviluppo di hardware) che può essere considerato un'estensione del modello a cascata.

V-model-1Invece di scendere verso il basso in maniera lineare, le fasi del processo, dopo la fase di codifica, sono piegate verso l'alto per formare la tipica forma a V. Il modello a V illustra le relazioni tra ogni fase del ciclo di vita di sviluppo e la fase di testing ad essa associata. L'asse orizzontale rappresenta il tempo o la completezza del progetto (da sinistra a destra); l'asse verticale il livello di astrazione (livello di astrazione minore in basso, livello di astrazione maggiore in alto).

Il ramo discendente (sinistro) della V rappresenta la macro-fase di "definizione" ovvero è la macro fase di ideazione e progettazione; il vertice della V rapprenta la fase di implementazione (scrittura) del codice; il ramo ascendente (destro) della V rappresenta la macro-fase di testing e di integrazione.

Il modello a V prevede la possibilità che ci siano dei feedback (da destra a sinistra) tra le fasi di testing / integrazione e le fasi di definizione poste allo stesso livello. Tali feedback costituiscono le correzioni e le modifiche da applicare quale esito negativo delle fasi di testing e di integrazione.

Descrizione delle fasi

V-model-2Il modello prevede 4 fasi di definizione (progettazione), una fase di implementazione e 4 fasi di testing / integrazione:

Requirements analysis

Nella fase di analisi di requisiti, che costituisce il primo passo nel processo di definizione, i requisiti del sistema sono raccolti analizzando le necessità dell'utente. Questa fase si occupa di stabilire quello che il sistema ideale dovrebbe compiere, ma non si occupa di determinare come il software sarà progettatto o sarà implementato. In questa fase, gli utenti vengono intervistati e viene generato un documento denominato specifica dei requisiti utente.

Ci sono diversi metodi per raccogliere i requisiti utente: interviste, questionari, analisi di documenti, osservazione, prototipi a perdere, casi di utilizzo e schemi statici e dinamici elaborati assieme gli utenti.

System design

La fase di System Design è la fase in cui i sistemisti, studiando la specifica dei requisiti utente, analizzano e capiscono i compiti del sistema proposto. Se dall'analisi risulta che uno qualsiasi dei requisiti non è fattibile, l'utente viene informato del problema, quindi viene trovata e condivisa una soluzione, ed il documento di requisiti viene modificato di conseguenza.

In questa fase viene redatta la specifica dei requisiti del software che servirà come piano architetturale per la fase di sviluppo. Questo documento abitualmente contiene l'organizzazione generale del sistema, la struttura dei menu, le strutture di dati, ecc.; può inoltre contenere esempi di scenari di funzionamento, esempi di finestre e report per una migliore comprensione del sistema. In questa fase sarà prodotta altra documentazione tecnica come i diagrammi di entità ed il dizionario di dati. In questa fase vengono infine preparate le specifiche per il test del sistema.

Architecture design

Architectural View ModelLa fase di progettazione dell'architettura hardware e software spesso viene denominata progettazione di alto livello; il punto di riferimento nel selezionare l'architettura software dovrebbe essere quello di realizzare tutto ciò che è necessario per definire l'elenco dei moduli, la funzionalità in breve di ogni modulo, le loro relazioni di interfaccia, le dipendenze, le tabelle delle basi di dati, i diagrammi architetturali ed i dettagli relativi alle tecnologie da usare.

In questa fase vengono progettati i test di integrazione.

Module design

La fase di progettazione del modulo può anche essere denominata progettazione a basso livello. Il sistema progettato è suddiviso in unità molto piccole, dette moduli; ognuno di essi è specificato in modo che il programmatore possa iniziare immediatamente la codifica.

La specifica di programma, o documento di progettazione di basso livello, conterrà: la descrizione funzionale dettagliata del modulo scritta in pseudocodice; le tabelle di database con tutti gli elementi, compresi il loro tipo e dimensione; tutti i dettagli delle interfacce con i riferimenti completi delle API; tutti i problemi concernenti le dipendenze; la lista dei messaggi di errore; tutti gli input e gli output del modulo.

In questa fase viene sviluppata la progettazione dei test di unità.

Coding

In questa fase si procede alla codifica, ovvero all'implementazione dei moduli.

Unit testing

Unit-testGli "unit test" sono un metodo mediante il quale singole unità di codice sorgente vengono testate per determinare se sono idonee per l'uso. L'unità è la più piccola parte testabile di un'applicazione; nella programmazione procedurale solitamente l'unità è una singola funzione o procedura.

Gli "unit test" sono creati dai programmatori e solitamente sono costituiti di test di tipo a "scatola bianca". Lo scopo è quello di verificare la logica interna del codice testando ogni possibile ramo all'interno della funzione (concetto noto come copertura del testing). Per facilitare questo processo spesso vengono utilizzati strumenti di analisi statica, mediante i quali tutte le variazioni dei dati di input sono passati alla funzione in modo da testare ogni possibile caso.

Integration testing

I test di integrazione possono essere suddivisi in due differenti classi:

  • Integrazione SW: i moduli vengono testati insieme per individuare gli errori nelle interfacce e nell'interazione tra componenti integrati. I test solitamente sono di tipo a "scatola nera" in quanto il codice non è direttamente controllato per trovare gli errori.
  • Integrazione HW/SW: vengono verificati i requisiti di architettura che descrivono l'interazione del SW con la relativa piattaforma HW sottostante. Anche in questo caso i test solitamente sono di tipo a "scatola nera".
System testing

Il testing di sistema è il testing eseguito su un sistema completo e integrato ed ha lo scopo di valutare la conformità del sistema con i requisiti specificati. Il testing di sistema ricade nell'ambito di test a "scatola nera" e, come tale, non richiede alcuna conoscenza del design interno del codice o della sua logica.

Come regola, il testing di sistema accetta come input tutti i componenti software "integrati" tra di loro che hanno superato il test di integrazione e l'intero software integrato con tutti i sistemi hardware applicabili.

User-Acceptance-TestingUser acceptance testing

Il testing di accettazione è la fase di test utilizzata per determinare se un sistema soddisfa i requisiti specificati in fase di analisi dei requisiti. La progettazione dei test di accettazione è derivata dal documento dei requisiti utente. Questa è la fase utilizzata dal cliente per determinare se accettare il sistema.

In sintesi il testing di accettazione;

  • aiuta a determinare se un sistema soddisfa i criteri di accettazione;
  • consente al cliente di determinare se accettare il sistema, o no;
  • permette di testare il software nel "mondo reale" degli utilizzatori.

 


Il modello a "V" nel ciclo di vita di sicurezza del SW

separate-gade-ribaltata

V-Model-SW

separate-gade

SafetyLifeCycleIl modello di sviluppo a "V" applicato al ciclo di vita di sicurezza del software presenta qualche differenza rispetto al modello standard. Ciò è dovuto al fatto che le norme relative alla sicurezza funzionale definiscono due cicli di vita, uno per il sistema, ed uno per il software. I due cicli di vita tuttavia sono strettamente correlati ed interdipendenti; questo traduce la preoccupazione della normativa che preme affinché hardware e software siano perfettamente integrati tra loro, ed in effetti il software viene pensato come un componente un po' speciale del sistema.

 

Le differenze principali tra i due modelli a "V" sono le seguenti:

  • Nel modello applicato al ciclo di vita di sicurezza mancano le fasi di analisi dei requisiti e di system design. Questo è dovuto al fatto che le fasi di concezione e pianificazioni vengono svolte a livello di sistema in quanto sono strettamente correlate alle analisi di sicurezza (ad esempio hazard & risk analysis).
  • Nel modello applicato al ciclo di vita di sicurezza la prima fase è costituita dalla definizione dei requisiti di sicurezza del SW. Tali requisiti vengono derivati dai requisiti di sicurezza del sistema e pertanto discendono dalle analisi di sicurezza relative al sistema nel sua globalità.
  • V-Model-SW-1Nei progetti complessi e di grandi dimensioni la fase di specificazione dell'architettura può esser divisa in due fase: la prima si occupa di scomporre il software nei suoi componenti principali, la seconda si occupa di scomporre ulteriormente il software fino ad arrivare alla identificazione dei singoli moduli che realizzano ogni componente. La prima di queste due fase viene chiamata ancora di specificazione dell'architettura, mentre la seconda viene chiamata "software system design" e non deve essere confusa con la fase di "system design" del modello standard.
  • Il modello applicato al ciclo di vita di sicurezza, oltre alle normali attività di validazione (testing), prevede una serie di attività di verifica. Tali attività hanno lo scopo di controllare la coerenza di quanto prodotto in ogni fase con i requisiti di sicurezza. Validazione e verifica (la cosiddetta V&V) sono considerate tra le principali attività che hanno lo scopo di assicurare l'integrità della sicurezza del sistema in via di realizzazione.

Contatti

Telefono: +39 02.2897.0440; +39 02.2871.305
Fax: +39 02.9475.8909

Info generali: Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.

Info commerciali: Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.
Rif. commerciale: +39 340.3466.704

Sede legale: I-20129 Milano, via Plinio 1
Uffici: I-20127 Milano, via Natale Battaglia, 27

Più informazioni ...

Settori di attività

Settori

HINTSW - T&T Systems opera da oltre un decennio nell'ambito della sicurezza funzionale dei principali settori industriali e dei trasporti pubblici.

Più informazioni ...

Consulenza

consulting

La divisione HINTSW fornisce consulenze altamente professionali e specializzate per lo sviluppo di sistemi elettronici programmabili utilizzati in applicazioni critiche per la sicurezza umana.

Più informazioni ...

Certificazione di sicurezza

certificazione

La certificazione di sicurezza di un sistema o di un apparato è spesso una sfida ardua da vincere, HINTSW fornisce tutto il supporto e il know-how necessari per poterla vincere brillantemente.

Più informazioni ...

Formazione

formazione

HINTSW, attingendo dalle proprie competenze, propone una vasta gamma di servizi nell'ambito della formazione professionale.

Più informazioni ...

Go to top