Differenza tra studio di fattibilità, specifica dei requisiti e progettazione del sistema software

Studio di Fattibilità

Lo studio di fattibilità si differenzia dagli altri stadi di lavorazione perché non si tratta di un’attività fondamentale per lo sviluppo di un software o di una sua evoluzione. Questo stadio di lavorazione viene in genere effettuato prima di incominciare il vero e proprio processo di produzione.

Lo studio di fattibilità si differenzia a seconda del fatto che si tratti di uno sviluppo che mira alla creazione di un software nuovo o di uno sviluppo che riguarda una o più componenti di un software già esistente.

Nel primo caso l’input dello studio di fattibilità sono una serie di requisiti, ovvero una descrizione pratica di come il sistema si debba comportare in tutte le condizioni possibili e di come esso supporta il processi di business del cliente. Il cliente inoltre si impegna a fornire una stima del budget e della data di consegna.

Nel secondo caso l’unica differenza consiste nel fatto che lo studio di fattibilità si preoccupa di trovare miglioramenti per problemi messi in evidenzia dal cliente su un software già costruito.

In entrambi l’IT manager, grazie anche al supporto di tecnici (come l’analista funzionale, sviluppatori…), si occupa di costruire, valutare e proporre diverse soluzioni software fornendo anche una valutazione sui tempi, sui costi, e sulla qualità. La qualità, ovviamente, è maggiore per quelle soluzioni che supportano al meglio il processo di business del cliente.

Tuttavia bisogna precisare che non esiste ‘la soluzione ottima‘, ma la soluzione deve essere contestualizzata alle esigenze e alle priorità del cliente. Sarà infatti il cliente stesso a scegliere le soluzioni proposte.

In questa fase, inoltre, soprattutto per i progetti di grosse dimensioni è possibile definire degli obiettivi di performance che il sistema deve raggiungere. Questi obiettivi sono valutati attraverso quelli che sono chiamati i KPI, ovvero Key Performance Indicator (KPI).

Acquisizione, analisi e specifica dei requisiti

Il concetto di requisito risulta essere indispensabile per comprendere a fondo questo stadio di lavorazione che risulta essere uno dei più importanti. Sbagliare questa fase, che di solito risulta essere una delle prime ad essere eseguite, significa compromettere inevitabilmente quelle successive. Per tale motivo è considerata uno degli stadi di lavorazione più importanti durante lo sviluppo di un software.

Definizione e classificazione di requisito

Un requisito, secondo il glossario standardizzato di ingegneria del software, è definito come:

1. Una condizione o capacità di cui necessita l’utente del software per risolvere un problema o per raggiungere un obiettivo;
2. Una condizione o una capacità che deve essere soddisfatta o posseduta dal sistema o da una componente del sistema per soddisfare un contratto, uno standard o una specifica particolare;

Nell’ingegneria del software i requisiti si distinguono in requisiti funzionali ed in requisiti non funzionali.

I requisiti funzionali specificano come il sistema debba comportarsi una volta che si determina una condizione o l’utente effettui una precisa azione.

I requisiti non funzionali descrivono invece la modalità attraverso il quale il sistema si comporta e quali sono i limiti che esistono quando viene eseguita una determinata funzionalità.

Specifica dei requisiti

L’obiettivo principale di questo stadio di lavorazione è quello di definire tutti i requisiti, funzionali e non funzionali. Non bisogna includere alcun dettaglio riguarda la struttura o la progettazione delle varie componenti software. Si dovrebbe lasciare al progettista la piena autonomia e responsabilità di agire come meglio crede. Idealmente bisognerebbe spiegare semplicemente il comportamento esterno del sistema ed i vincoli che esistono tra le varie operazioni. Tuttavia, soprattutto nello sviluppo di software complessi, risulta quasi impossibile non includere informazioni riguardanti la progettazione del software. Le motivazioni sono diverse in particolare:

1. La definizione della struttura del sistema potrebbe aiutare a comprendere meglio alcuni requisiti;
2. L’uso di una specifica struttura potrebbe essere cruciale per la soddisfazione di un particolare requisito.

L’output di questo processo è un documento il quale deve essere redatto attraverso l’utilizzo di un linguaggio semplice e chiaro e deve essere fornito sia di diagrammi che di tabelle per rendere più efficace la comprensione del documento che risulta cruciale per la fase successiva ovvero della progettazione del sistema.

Parallelamente a questo documento, in alcuni casi, viene redatto un secondo documento: ‘Il manuale utente’ che spiega in maniera dettagliata come l’utente finale interagirà con il sistema per eseguire una determinata azione. Questo tipo di documento viene consegnato al committente in modo tale che può verificare che tutti i requisiti richiesti siano stati effettivamente raccolti e/o compresi.

Come anticipato più volte nei paragrafi precedenti, questa fase di lavorazione risulta essere cruciale per il successo dell’intero sviluppo software. Infatti non eseguire correttamente la raccolta dei requisiti dal cliente, inevitabilmente comporterà degli errori anche nelle fasi successive.

Definizione e Progettazione del Sistema

La fase successiva alla raccolta e alla specificazione dei requisiti del software è la definizione e la progettazione dettagliata della struttura del software. In questo stadio di lavorazione i progettisti insieme all’aiuto degli analisti e sviluppatori cercano di descrivere come i requisiti sono soddisfatti attraverso il software ed effettuano un’analisi a diversi livelli di dettaglio. Il numero di livelli di dettaglio dipendono dalla complessità e dalla grandezza del software. Ai livelli più bassi di dettaglio i progettisti si preoccupano di definire le componenti principali e quali sono le macro relazioni che esistono fra di loro. A questo livello di progettazione viene definita, inoltre, la componente hardware, i sistemi operativi da adoperare, il sistema di gestione dei dati (DBMS, Database Management Sysyem) ed i linguaggi di programmazione da utilizzare nello stadio di lavorazione successiva di codifica.

Ad un livello intermedio di dettaglio i progettisti si preoccupano di scomporre ogni componente in moduli definendone i vincoli e le iterazioni tra di esse.

Al livello più alto di dettaglio i progettisti, grazie anche all’aiuto degli sviluppatori, definiscono il funzionamento di ogni modulo e quali sono le tipologie di informazioni che sono processate in ogni modulo. In altre parole i progettisti in questo livello di dettaglio prendono decisioni rilevanti riguardo la struttura tecnica di ogni modulo. Non è importante specificare tutti i dettagli necessari per sviluppare ciascun modulo, ma bisogna fornire il numero giusto di informazioni sufficienti a guidare le persone che svilupperanno i moduli. Questa fase risulta essere cruciale perché le decisioni tecniche prese dai progettisti in questa fase incidono principalmente sul soddisfacimento dei requisiti non funzionali.