Gli ingegneri dei sistemi hanno a lungo considerato la V come una parte fondamentale della buona ingegneria. Ultimamente, però, la V dell’ingegneria dei sistemi ha ricevuto una cattiva reputazione. La nuova generazione di ingegneri la vede come un simbolo di pratiche di ingegneria lente e a cascata. Considerano queste pratiche irrilevanti per la velocità richiesta per lo sviluppo del software.
I sostenitori dell’ingegneria tradizionale preferiscono la V ai metodi “agili”. Questo è particolarmente vero quando si tratta di sistemi critici.
A chi dovremmo credere?
Beh, se siamo onesti, quando la V esiste come un unico glorioso passaggio per un intero sistema, la nuova generazione ha un ottimo argomento. La V può davvero rallentare il buon sviluppo del software.
Al suo centro, la V dell’ingegneria dei sistemi è un costrutto logico. Descrive la scoperta dei requisiti di sistema scomponendo un sistema in parti più piccole e poi assemblando e validando quelle parti.
Gli ingegneri dei sistemi applicano la V in vari contesti. Più spesso, la V appare in grandi organizzazioni, come il Dipartimento della Difesa degli Stati Uniti. È anche prominente nelle istituzioni accademiche.
Questi grandi programmi o organizzazioni usano la V come parte del loro processo di esecuzione di alto livello. Il flusso di lavoro generale ha sette fasi:
Il processo inizia sul lato sinistro della V dove (1) vengono generati i concetti. Successivamente, (2) i requisiti per l’intero sistema sono definiti, decomposti e assegnati. Poi, (3) i componenti del sistema sono progettati in dettaglio.
L’implementazione avviene nella parte inferiore della V (4). Qui è dove i componenti progettati sono creati secondo i requisiti di prima nel processo.
Muovendosi sul lato destro della V, questi componenti sono (5) integrati insieme nel sistema finale. Il sistema integrato viene poi verificato per assicurare che soddisfi i requisiti originali e convalidato per assicurare che soddisfi le esigenze dell’utente (6). Infine, (7) il sistema viene consegnato e mantenuto.
Sfide del V
Eseguire il processo V si rivela problematico per molti grandi progetti, specialmente quelli che includono software.
Integrazione
Un problema importante è che l’integrazione avviene troppo tardi nel processo di sviluppo. I programmi che si affidano alla V aspettano che i componenti del software siano completi per ridurre il costoso lavoro di integrazione.
L’integrazione manuale dei componenti del software richiede una quantità enorme di tempo. La realtà che tutti sappiamo essere vera è che il software non è mai finito. Le attività di integrazione lasciate alla fine sono affrettate per rispettare la tabella di marcia del programma.
Nella V, i componenti integrati di solito soddisfano i requisiti funzionali, ma spesso non sono sicuri o corretti.
Verifica &Convalida
Aspettare che il sistema sia stato completamente integrato per condurre la verifica e la validazione (V&V) aggrava questo problema. L’implementazione di correzioni provoca increspature in tutto il sistema, rendendo difficile e costoso affrontare i problemi che sorgono durante la V&V.
I programmi spesso mettono in atto correzioni “a livello di sistema” invece di risolvere il problema alla radice – un approccio da cerotto. Il rischio del software è spesso mitigato da pratiche come firewall a livello di sistema e software anti-virus piuttosto che affrontarlo nel codice.
I cerotti diminuiscono la possibilità che gli utenti incontrino la falla, ma la falla stessa non è riparata e continua ad annidarsi nel sistema.
Rispondere alla sfida
I concetti nella V dell’ingegneria dei sistemi non sono il problema – è la struttura della V che non si applica al software
Le tecniche moderne possono permettere l’integrazione continua del software, anche su programmi grandi. L’uso di strumenti e processi che abbracciano l’integrazione e la verifica precoce non nega i concetti fondamentali della V – migliorano la V in modo che funzioni per lo sviluppo del software.
Il risultato finale è un software che è corretto alla creazione, e un sistema che è più economico, più sicuro e più veloce da consegnare.
Il risultato finale è un software che è corretto alla creazione, e un sistema che è più sicuro e più veloce da consegnare.