Linea guida: Elenco dei rischi
Questa linea guida descrive come identificare e gestire i rischi di un progetto software.
Relazioni
Elementi correlati
Descrizione principale

Introduzione

"La prontezza è tutto." - Amleto V:ii:215

Un progetto, come la vita, è incerto. I rischi vengono identificati non per il gusto di farlo ma per anticiparli e ridurli, se possibile, o per affrontarli direttamente quando le strategie di mitigazione non hanno funzionato.

Il rischio guida i piani di iterazione; le iterazioni vengono pianificate per risolvere dei rischi specifici, tentando o di contenerlo o di ridurlo. L'elenco dei rischi viene revisionato periodicamente per valutare l'efficacia delle strategie di mitigazione del rischio, che a sua volta guida le revisioni al piano del progetto e ai conseguenti piani di iterazione.

La chiave per gestire il rischio è non aspettare che si materializzi (e diventi un problema o un errore), per decidere cosa fare. Come una modifica di pochi gradi alla rotta di un volo transoceanico ha un grosso effetto su dove atterra l'aereo, la gestione precoce del rischio è quasi sempre meno costosa e fastidiosa di una pulizia dopo l'accaduto.

Strategie di gestione dei rischi

Esistono tre principali strategie [BOE91]:

  • Evitare il rischio. Riorganizzare il progetto in modo che non possa essere influenzato da quel rischio.
  • Trasferimento del rischio. Riorganizzare il progetto in modo che qualcun'altro o qualcos'altro si occupi del rischio (cliente, fornitore, banca, altro elemento, ecc.). Una strategia specifica dell'evitare il rischio.
  • Accettazione del rischio. Decidere di convivere con il rischio come circostanza imprevista. Monitorare i sintomi del rischio e decidere sul piano di emergenza da utilizzare nel caso emerga il rischio.

Se si decide di accettare il rischio, si può tentare di mitigarlo, vale a dire intraprendere qualche azione immediata per ridurne l'impatto.

Tipi di rischi

E' importante distinguere fra rischi diretti e indiretti. In parole povere, un rischi diretto è quello su cui si ha un qualche grado di controllo; i rischi indiretti sono quelli impossibili da controllare.

Pur non restando ignoranti sui rischi indiretti, hanno poche conseguenze in senso pratico: poiché non è possibile modificarli, non è costruttivo preoccuparsene eccessivamente. A dispetto del fatto che il mondo potrebbe finire domani, potrebbe anche non finire e se non finisce sarebbe stato meglio se il lavoro fosse stato continuato!

A volte un rischi indiretto può essere in realtà un rischi diretto camuffato. Ad esempio, si può dipendere da dei fornitori esterni per un componente o un insieme di componenti. Questo sembra essere un rischio indiretto, ma disponendo di piani di emergenza per quei componenti, è possibile prendere il controllo di quel rischio: si possono scegliere dei fornitori alternativi o sviluppare da soli la funzionalità. In molti casi si ha più controllo di quanto si pensi!

Con i rischi indiretti, o si individua un metodo per acquisire un certo grado di controllo sui rischi, o se ne prende semplicemente nota e si passa avanti. Non ha senso angosciarsi su qualcosa che non può cambiare.

Rischi delle risorse

Organizzazione
  • C'è sufficiente impegno sul progetto (incluso il settore dirigenziale, i tester, QA ed altre parti esterne coinvolte)?
  • Si tratta del più grande progetto mai tentato da questa organizzazione?
  • Esiste un processo ben definito per la progettazione software? Acquisizione e gestione dei requisiti?
Finanziamento
  • E' disponibile il finanziamento per portare a termine il progetto?
  • Sono stati stanziati dei fondi per la formazione e il mentoring?
  • Esistono dei limiti di budget tali da dover distribuire il sistema ad un costo fisso o da correre il rischio di una cancellazione del progetto?
  • Le stime dei costi sono accurate?
Persone
  • Sono disponibili persone sufficienti?
  • Hanno gli skill e l'esperienza appropriati?
  • Hanno già lavorato insieme prima?
  • Credono nel successo del progetto?
  • Le rappresentative di utenti sono disponibili a partecipare alle revisioni?
  • Sono disponibili esperti del dominio?
Tempi
  • La pianificazione è realistica?
  • La funzionalità può essere gestita dall'ambito per rispettare i tempi?
  • Quanto è critica la data di distribuzione?
  • Esiste un tempo per "farlo bene"?

Rischi di business

  • Cosa succede se la concorrenza raggiunge prima il mercato?
  • Cosa succede se i fondi sono a rischio (un altro modo di vederla è chiedersi "cosa può garantire un finanziamento adeguato")?
  • Il valore proiettato del sistema è maggiore del costo proiettato? (accertarsi di giustificare il tempo-valore del denaro ed il costo del capitale).
  • Che succede se non vengono stipulati i contratti con i fornitori chiave?

Rischi tecnici Inizio pagina

Rischi dell'ambito
  • L'esito positivo può essere misurato?
  • Esiste un accordo su come misurare l'esito positivo?
  • I requisiti sono abbastanza stabili e ben compresi?
  • L'ambito del progetto è fisso o continua ad espandersi?
  • Le scale temporali dello sviluppo del progetto sono brevi ed inflessibili?
Rischi tecnologici
  • La tecnologia è stata comprovata?
  • Gli obiettivi di riutilizzo sono ragionevoli?
    • Un prodotto di lavoro deve essere utilizzato almeno una volta, prima di poter essere riutilizzato.
    • Potrebbero essere necessari diversi rilasci di un componente prima che sia sufficientemente stabile da poterlo riutilizzare senza modifiche significative.
  • I volumi di transazione nei requisiti sono ragionevoli?
  • Le stime di incidenza della transazione sono credibili? Sono troppo ottimistiche?
  • I volumi di dati sono ragionevoli? Possono essere mantenuti sui mainframe attualmente disponibili o, se i requisiti portano a credere che una workstation o un sistema di reparto faranno parte della progettazione, i dati possono ragionevolmente risiedere lì?
  • Esistono dei requisiti tecnici insoliti o impegnativi che richiedono al team del progetto di affrontare problemi dei quali non hanno esperienza?
  • L'esito positivo dipende da prodotti, servizi o tecnologie nuovi o non provati, oppure hardware, software o tecniche nuove o non provate?
  • Esistono dipendenze esterne da interfacce per altri sistemi, inclusi quelli esterni all'impresa?  Le interfacce richieste esistono o devono essere create?
  • Sono presenti dei requisiti di disponibilità e sicurezza estremamente inflessibili (ad esempio, "il sistema non deve mai dare errore")?
  • Gli utenti del sistema sono inesperti nei confronti del tipo di sistema da sviluppare?
  • Esiste un rischio aumentato a causa della dimensione o della complessità dell'applicazione o della novità della tecnologia?
  • E' presente un requisito per il supporto della lingua nazionale?
  • E' possibile progettare, implementare ed eseguire questo sistema? Alcuni sistemi sono troppo vasti o complessi per funzionare correttamente.
Rischio da dipendenza esterna
  • Il progetto dipende da altri progetti di sviluppo (paralleli)?
  • L'esito dipende da prodotti pronti o da componenti sviluppati esternamente?
  • L'esito dipende dall'integrazione di tool di sviluppo (tool di progettazione, compilatori e così via), da tecnologie di implementazione (sistemi operativi, databases, meccanismi di comunicazione fra processi ecc. ecc.)? Si dispone di un piano di riserva per distribuire il progetto senza queste tecnologie?

Rischi di tempificazione

L'esperienza insegna che l'85% dei rischi hanno un impatto diretto o indiretto sui tempi e quindi implicitamente sui costi. Forse il 5% ha solo un impatto sui costi. Il resto non ha impatto diretto sui costi o sui tempi, ma sulla qualità, ad esempio.

Se il nemico è una scadenza, affrontarlo con distribuzioni incrementali. Evitare di avere una distribuzione enorme nel tentativo di rispettare la pianificazione.

Alcuni progetti hanno delle scadenze "improrogabili". Ad esempio. il software per analizzare "dal vivo" il risultato di un'elezione nella notte dell'elezione ha poco valore se è pronto la settimana dopo le elezioni. Oppure il software potrebbe essere reso obsoleto dalla concorrenza: viene lanciato un prodotto concorrenziale migliore quando il proprio software è ancora in fase di costruzione. Improvvisamente si è fuori dal gioco e non c'è molto che si possa fare. In generale, tuttavia, pochi progetti hanno delle scadenze così critiche. I ritardi inficiano principalmente sui costi.

In generale, pianificare i tempi in modo uguale alla migliore stima, più una ragionevole contingenza,

commitment = stima + contingenza

Altri suggeriscono di impostare le aspettative della tempificazione uguali alla strategia di riserva, vale a dire basarle sui piani di emergenza, ma questo è un po' troppo pessimistico perché non tutti i rischi si materializzeranno davvero.

I rischi della tempificazione sono integrati in alcuni tool di stima e dei costi. Ad esempio nel modello COCOMO, molti dei portatori di costo, come:

  • complessità (cplx)
  • vincoli in tempo reale (time)
  • vincoli di memoria (stor)
  • esperienza (Vexp)
  • disponibilità di buoni tool (tool)
  • pressione sui tempi (sced)

sono in effetti dei fattori di rischio.

Tecniche più sofisticate per la gestione del rischio implicano l'uso della simulazione Monte Carlo, in cui viene eseguito un enorme numeri di "scenari" con un tool di simulazione per calcolare i rischi globali e le contingenze [KAR96].