Cosa è il rischio in un progetto software?
Il rischio rappresenta la possibilità del verificarsi di una condizione svantaggiosa in relazione alle attese ed alla scala dei valori dei soggetti coinvolti e che, una volta presentatasi, possa creare loro dei danni.
Per la sua natura, la probabilità associata ad un rischio deve essere misurata. La valutazione del potenziale danno associato al verificarsi di un evento, pertanto, parte dalla comprensione della scala dei valori e del risultato atteso dagli stakeholder di un progetto. Da ciò si evince che nella corretta definizione dei requisiti, è fondamentale riconoscere e coinvolgere fin dalle prime fasi gli stakeholder che trarranno vantaggi o svantaggi dall’esito progettuale. Tipici stakeholder da considerare sono i committenti, gli utilizzatori diretti ed indiretti, i partecipanti allo sviluppo, i rappresentanti dell’esercizio dei sistemi, il management ed i regolatori esterni (autorità di vario tipo non partecipanti al progetto ma interessate al rispetto di vincoli esterni predeterminati).
Nell’ambito di un progetto, un rischio rappresenta la probabilità del non raggiungimento degli obiettivi prefissati in termini di quantità di prodotti (numero e tipo di funzionalità, dati), di qualità dei risultati (requisiti non funzionali), di costo e durata delle attività.
Dunque, tra le principali cause di insuccesso di un progetto emergono l’indeterminatezza, l’ambiguità, la genericità (intesa come scarsa qualità della formulazione), la mutevolezza degli obiettivi progettuali.
Infatti, poichè dietro una formulazione ambigua di un obiettivo possono nascondersi una moltitudine di differenti formulazioni specifiche, essa difficilmente potrà prestarsi da guida per il lavoro a valle. Pertanto, è necessario che ciascun obiettivo sia ben formulato, condiviso e misurabile dalle parti interessate, cioè clienti e produttore.
Capita spesso che gruppi di progetto con esperienza e capacità tecnologiche, non presentino la stessa attitudine a mettere a fuoco gli obiettivi da perseguire, calandoli nel contesto reale.
Questo atteggiamento è dovuto alla scarsa attenzione dedicata alla fase iniziale del progetto e comporta un ulteriore investimento di risorse per revisionare, testare e correggere gli errori propagati sul prodotto finale. Infatti, porre l’accento sulle attività, confondendole con i risultati, porta spesso a trascurare soluzioni alternative meno immediate, ma talvolta più efficaci.
Causa di scarsa qualità è la difficoltà di far condividere gli obiettivi tra stakeholder con interessi talvolta divergenti, nonchè le errate motivazioni che spingono il gruppo incaricato del progetto a concentrarsi sullo strumento da produrre, perdendone di vista lo scopo per cui viene richiesto.
Alcuni studi hanno mostrato che la percentuale di progetti falliti, o che hanno richiesto risorse maggiori rispetto a quelle stanziate, sia elevatissima.
In questo scenario, un peso importate è stato attribuito agli errori nei requisiti: come è noto, la rimozione di un errore commesso durante la fase di definizione può costare fino a 20 volte di più di uno commesso durante la fase di realizzazione del prodotto.
Inoltre, alcune stime mostrano che un gran numero di progetti falliscono per erroti commessi nella fase di definizione dei requisiti e ciò ha portato all’introduzione di una ben definita disciplina: l’Ingegneria dei Requisiti.
