Risk management : Breve analisi del processo di gestione dei progetti software
•Transferir como PPT, PDF•
2 gostaram•3,588 visualizações
L’analisi del processo di gestione dei rischi dei progetti software è attuata attraverso una revisione sia della letteratura di riferimento che delle best practices più diffuse nel mondo professionale, ottenendo una visione sistematica ed integrata dell’argomento. Dopo un’analisi delle peculiarità dei progetti software e dei principali modelli di processo software, si valutano le motivazioni che hanno, poi, portato gli accademici e i professionisti del settore ICT a definire e specializzare i processi di gestione rischi per i progetti software dei quali si esamina la natura e origine dei principali rischi. A conclusione dell’attività di “censimento” dei rischi più diffusi e/o comuni riguardanti lo sviluppo del software, è proposta, sulla base delle diverse top ten software risk presenti in letteratura, una rielaborazione di una lista strutturata di rischi utilizzabile da un Project Manager nella fase di identificazione dei rischi.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (10)
Semelhante a Risk management : Breve analisi del processo di gestione dei progetti software
Semelhante a Risk management : Breve analisi del processo di gestione dei progetti software (20)
Risk management : Breve analisi del processo di gestione dei progetti software
- 1. Risk Management: Un’analisi del processo di gestione dei rischi dei progetti software 1 Roma, 15 Luglio 2013
- 2. Obiettivi Analizzare il processo di gestione dei rischi dei progetti software in un quadro di riferimento metodologico di Risk Management Standard del Risk Management ed approcci al Project Risk Management Origini e classificazione dei rischi software Processo di gestione dei rischi dei progetti software Tecniche e metodi del processo di gestione dei rischi dei progetti software. 2
- 3. Risk Management: Quadro di riferimento Principali approcci al PRM (Project Risk Management) AS/NZS 4360 del Standards Association of Australia: ( recepita in ISO 31000:2009) Project Risk Analysis and Management (PRAM) dell’ UK Association for Project Management Project Management Body of Knowledge (PMBOK®) del PMI edizione 2013. Famiglia di standard di gestione del rischio applicabile a qualsiasi organizzazione ed attività: ISO GUIDE 73:2009 (Vocabolario) ISO/IEC 31000:2009 (Principi e Linee Guida) => UNI EN ISO 31000:2010 ISO/IEC 31010:2009 (Tecniche di valutazione del rischio) 3
- 4. Progetto Software Caratteristiche peculiari •Produzione di un bene intangibile; •Intrinseca complessità del problema e delle probabili soluzioni; •Richieste di cambiamenti dovuti ad innovazioni tecnologiche; •Maturità dell’ambiente di sviluppo •Possibile esistenza di requisiti non ancora noti; •Livello di stabilità dei requisiti noti; •Esigenza di rilasci ‘early’ di parziali funzionalità; •Modello di processo software da adottare non corrispondente a all’organizzazione del management Non esiste un modello di processo software che sia migliore di altri o che sia ”ideale” (Sommerville, 2007) che risponda meglio alle esigenze del progetto. 4
- 5. Gestione dei rischi in un Progetto Software Il 67% dei progetti sw falliscono (prodotto software scadente o progetto con tempi e costi di sviluppo fuori budget (Chaos Report Standish Group) (*) (*) dati riferiti al 2010 su 10.000 progetti considerando fallimento anchei progetti con successo parzilae o e che hanno, comunque, apportato maggiori costi e tempi di rilascio oltre che fornire al cliente meno funzionalità di quelle previste inizialmente. (http://www.computerworld.com/s/article/9220591/It_s_not_the_coding_that_s_hard_it_s_the_people) Necessità di adottare un processo di gestione dei rischi di un progetto software • ‘’stress” dovuti ai cambiamenti per il veloce “invecchiamento” dei requisiti e dei relativi prodotti • necessaria conoscenza di tecniche innovative • rischi imprevedibili e non definiti • tempi sempre più limitati, risorse limitate • caratteristiche di multi-progetto/ multi cliente • siti di produzione del software su differenti posizioni geografiche 5
- 6. Origine dei rischi di un Progetto Software RBS per un progetto software 6
- 7. Fattori di rischio di un Progetto Software Distribuzione dei fattori di rischio (rielaborazione personale) 7 Dimensioni del rischio (Wallace & Kell,2004)
- 8. Processo di gestione dei rischi software Identificazione Rischi Analisi Qualitativa Analisi Quantitativa Monitoraggio e Controllo Pianificazione della risposta ai rischi Brainstorming, Tecnica Delphi Valutazione della Probabilità e dell’Impatto Interviste/Colloqui Distribuzioni di probabilità Rivalutazione dei rischi Strategie per rischi negativi o minacce Giudizio degli esperti Matrice di Probabilità ed Impatto Giudizio degli esperti Verifiche dei rischi Strategie per rischi positivi o opportunità Analisi degli Assunti Valutazione della Qualità dei Dati Analisi sensitività Analisi EMV Analisi dello scostamento Analisi in base a liste di controllo Categorizzazione dei rischi Analisi dell’albero delle decisioni Misurazione prestazioni tecniche Diagrammi causa effetto Diagrammi d’influenza Valutazione dell’urgenza dei rischi Metodo Monte Carlo Analisi della riserva Analisi S.W.O.T. Riunioni sullo stato d’avanzamento 8
- 9. Tecniche e Metodi Identificazione Rischi Analisi Qualitativa Analisi Quantitativa Monitoraggio e Controllo Pianificazione della risposta ai rischi Brainstorming, Tecnica Delphi Valutazione della Probabilità e dell’Impatto Interviste/Colloqui Distribuzioni di probabilità Rivalutazione dei rischi Strategie per rischi negativi o minacce Giudizio degli esperti Matrice di Probabilità ed Impatto Giudizio degli esperti Verifiche dei rischi Strategie per rischi positivi o opportunità Analisi degli Assunti Valutazione della Qualità dei Dati Analisi sensitività Analisi EMV Analisi dello scostamento Analisi in base a liste di controllo (Checklist) Categorizzazione dei rischi Analisi dell’albero delle decisioni Misurazione prestazioni tecniche Diagrammi causa effetto Diagrammi d’influenza Valutazione dell’urgenza dei rischi Metodo Monte Carlo Analisi della riserva Analisi S.W.O.T. Riunioni sullo stato d’avanzamento 9
- 10. Identificazione Rischi Analisi Qualitativa Analisi Quantitativa Monitoraggio e Controllo Pianificazione della risposta ai rischi Brainstorming, Tecnica Delphi Valutazione della Probabilità e dell’Impatto Interviste/Colloqui Distribuzioni di probabilità Rivalutazione dei rischi Strategie per rischi negativi o minacce Giudizio degli esperti Matrice di Probabilità ed Impatto Giudizio degli esperti Verifiche dei rischi Strategie per rischi positivi o opportunità Analisi degli Assunti Valutazione della Qualità dei Dati Analisi sensitività Analisi EMV Analisi dello scostamento Analisi in base a liste di controllo (Checklist) Categorizzazione dei rischi Analisi dell’albero delle decisioni Misurazione prestazioni tecniche Diagrammi causa effetto Diagrammi d’influenza Valutazione dell’urgenza dei rischi Metodo Monte Carlo Analisi della riserva Analisi S.W.O.T. Riunioni sullo stato d’avanzamento ..Tecniche e Metodi 10
- 11. Conclusione e futuri sviluppi La FASE CRITICA è l’Identificazione dei rischi: Disponibilità di affidabili fonti informative Notevole esperienza del Project Manager Bilanciamento dei costi e relativi benefici Sistemi software di “Project Risk Knowledge Management” per Supportare la fase di identificazione dei rischi Favorire a comunicazione e la diffusione di una “cultura aziendale” fortemente orientata alla gestione del rischio Catturare la «conoscenza tacita» del gruppo di Project Management Indagine e studio su sviluppo di Home 11
- 12. Identificazione dei rischi Principali fattori di rischio di un progetto software nelle sei dimensioni indicate da (Wallace & Keil, 2004) Rielaborazione personale tratta da (Arnuphaptrairong, 2011) 12
- 13. Tecniche di Analisi Qualitativa Probabilità / Impatto Basso Medio Alto Basso Ignorare Ignorare Ignorare Medio Ignorare Attenzione Rispondere Alto Attenzione Rispondere Rispondere Probabilità Minacce Opportunità 0.90 0.05 0.09 0.18 0.36 0.36 0.18 0.09 0.05 0.70 0.04 0.07 0.14 0.28 0.28 0.14 0.07 0.04 0.50 0.03 0.05 0.10 0.20 0.20 0.10 0.05 0.03 0.30 0.02 0.03 0.06 0.12 0.12 0.06 0.03 0.02 0.10 0.01 0.01 0.02 0.04 0.04 0.02 0.01 0.01 0.05 0.10 0.20 0.40 0.40 0.20 0.10 0.05 Elevato Rischio Medio Rischio Basso Rischio Tabella 1 Valutazione della probabilità del rischio Impatto Scala qualitativa Ordinale Scala qualitativa Cardinale Lineare Scala qualitativa Cardinale Non Lineare Impatto molto Basso 0.1 0.05 Impatto Basso 0.3 0.1 Impatto Medio 0.5 0.2 Impatto Alto 0.7 0.4 Impatto Molto Alto 0.9 0.8 Tabella 2 Valutazione dell’impatto Probabilità del rischio Livello probabilità Ordinale Livello probabilità Cardinale Criterio molto bassa 0.1 improbabile che si verifichi bassa 0.3 più probabile che non si verifichi media 0.5 probabilità uguale che si verifichi o non si verifichi alta 0.7 più probabile che si verifichi molto alta 0.9 improbabile che non si verifichi Tabella 3 Valutazione Analisi qualitativa ALTO, MEDIO, BASSO Tabella 4 Rappresentazione alternativa di una Tabella BASSO, MEDIO, ALTO Tabella 5 Matrice di Probabilità ed Impatto 13
- 14. Tecniche di Analisi Quantitativa Stima del rischio totale Stima del’impatto totale Albero delle decisioni Analisi della sensitività Diagramma «Tornado» Diagramma «Spider» 14
- 15. Pianificazione delle risposte Strategie per rischi negativi o minacce Strategia Attività • Possibili azioni Evitare (Avoid) Si cambia il piano di PM per eliminare la causa. Tale tecnica annulla il rischio Rimozione di un WP (Work Package) o di una risorsa Riduzione di un obiettivo Chiarimento dei requisiti Trasferire (Transfer) Si trasferisce la responsabilità del rischio ad un altro soggetto Tale tecnica NON annulla il rischio Assicurazione, garanzie, fideiussioni Outsourcing del lavoro Contratto a rimborso spese (se si è fornitore) Contratto a prezzo prefissato (se si è l’acquirente) Chiedere al cliente di prendere in carico una parte del lavoro Mitigare (Mitigation) Si riduce la probabilità e/o l’impatto di una minaccia, Viene spesso adottata l’azione che presenta la maggiore riduzione Tale tecnica NON annulla il rischio Adottare processi meno complessi Eseguire più test Scegliere un fornitore più affidabile o seguirlo attentamente Realizzare un prototipo Usare sistemi Hw ridondanti Formare le risorse Accettare (Accept) Non si modifica il Piano di Project Management Nessuna azione (Riserva per contingency) 15
- 16. Pianificazione delle risposte Strategie per rischi positivi o opportunità Strategia Attività • Possibili azioni Sfruttare (Exploit) Si cambia il piano di PM per garantire che le opportunità si realizzino. E’ il contrario dell’evitare • Rimozione di un WP (Work Package) o di una risorsa • Riduzione di un obiettivo • Chiarimento dei requisiti Condividere (Share) Consiste nel condividere la responsabilità con una terza parte che è in grado di realizzare l’opportunità. • Creare una partnership o un joint venture • Affidare in outsourcing Migliorare (Enhance) Si aumenta la probabilità e/o gli impatti positivi dell’evento di rischio. 16
Notas do Editor
- Mi presento. Sono Donato Bellino, già laureato nel 1982 in Scienze dell’Informazione e da oltre vent’anni, in qualità di Quadro Aziendale Telecom ho svolto principalmente attività di Project Management ICT sia in fase di Progettazione che in fase di Realizzazione di Sistemi Informatici per la Pubblica Amministrazione Locale (Enti Locali ed ASL), Ancora prima mi sono interessato di produzione software ricoprendo tutti i ruoli della filiera produttiva di sviluppo del software fino ad essere responsabile di una struttura di produzione componentistica software di circa 50-60 tra programmatori e progettisti software.
- Lo scopo di questo elaborato, è l’analisi , in un quadro di riferimento metodologico di Risk Management, del Project Risk Management (PRM), un processo sistematico di identificazione, analisi e risposta ai rischi di progetto, con un particolare focus sul processo di gestione dei rischi dei progetti software. Come proposto dall’agenda, l’analisi del processo di gestione dei rischi dei progetti software (Software Project Risk Management) è stata effettuata attraverso una revisione ed integrazione della letteratura di riferimento che delle best practices più diffuse, in modo da avere una visione sistematica ed integrata dell’argomento. Sono stati esaminati prima gli standard proposti per gestione dei rischi di un generico progetto analizzando le motivazioni che hanno, poi, portato gli accademici e i professionisti del settore ICT a definire e specializzare i processi di gestione rischi per i progetti software. Successivamente è stata esaminata la natura ed origine dei rischi di un progetto software e le numerose proposte di “top ten software risk” presenti in letteratura. In particolare, in questo elaborato, attraverso, un’attività di “censimento” e “clusterizzazione” dei rischi definiti dagli autori nelle diverse liste, è anche proposta una lista strutturata dei più comuni rischi di progetti software utilizzabile da un Project Manager. Dopo aver esaminato le principali caratteristiche di un progetto software e dei vari modelli di processo software utilizzabile da un Project Manager sono stati esaminati i principali approcci al processo di gestione dei rischi dei progetti software. Infine sono state esaminate le tecniche e i metodi utilizzati nelle varie fasi del processo di gestione dei rischi evidenziando gli scopi e le condizioni di applicabilità e con un’indagine effettuata nella rete Internet, è stato anche identificato un insieme di tools software commerciali e non a supporto delle varie fasi del processo di gestione dei rischi di un progetto software.
- Il RISK MANAGEMENT è una disciplina in rapida evoluzione ed esistono molte concezioni e definizioni diverse dei suoi contenuti, delle modalità di gestione e delle sue finalità. PERTANTO, è necessario attenersi ad un standard, ad un quadro di riferimento comune, per essere certi di condividere: la terminologia relativa utilizzata Il processi di attuazione la struttura organizzativa le finalità Uno standard di riferimento è costituito dalla triade ISO 31000 che fornisce un framework che la letteratura e i vari standard e le best practices hanno poi adottato dando forma a vari framework specialistici operativi di gestione dei rischi dipendenti dalla natura e tipologia dei rischi oggetto di gestione ( SRM, FRM, ERM, IRM, DRM, CRM) In particolare, una istanza del Risk Management è Il Project Risk Management (PRM) , insieme di conoscenze finalizzato a stimare e gestire l’incertezza ed il rischio dei progetti connesso alla possibile evoluzione di eventi futuri. Il PRM risulta essere un processo fondamentale in tutti i settori che prevedono una gestione per progetti (cantieristico, consulenza, information technology, sviluppo software, automobilistico, edile, civile, etc.). Le due organizzazioni professionali più importanti che pubblicano orientamenti sul Project Risk Management sono: il Project Management Institute (PMI); l’Association for Project Management (APM). Esistono diversi approcci per il Project Risk Management che seppure alternativi non si scontrano fra loro. In ognuno ci sono differenze significative nei loro obiettivi, stili e approcci ed alcune caratteristiche peculiari rendono ogni approccio adatto in determinati contesti Essi sono: l’Australian and New Zealand AS/NZS 4360 del Standards Association of Australia; il Project Risk Analysis and Management (PRAM) dell’ UK Association for Project Management; il Project Management Body of Knowledge (PMBOK®) del PMI (Project Management Institute);
- Secondo la definizione data dal PMI (Project Management Institute) nel PMBOK®, un progetto “ è uno sforzo temporaneo intrapreso allo scopo di creare un prodotto, un servizio o un risultato unici” (Project Management Institute (PMI), 2004). Ogni progetto unico nel suo genere, con un proprio ciclo di vita di cui si parlerà in seguito è fortemente dipendente dal settore di riferimento, e risponde alle seguenti caratteristiche fondamentali: deve raggiungere obiettivi ben definiti di durata, costo (budget) e risultato finale provenienti dal cliente; ha associato dei rischi specifici; può durare poche settimane o svariati anni ed avere ha una sequenza di attività interconnesse; ha dei vincoli di qualità da rispettare; può coinvolgere poche o molte persone di una o più organizzazioni/funzioni ed ha termine quando gli obiettivi sono raggiunti non necessariamente in modo positivo. Nel nostro caso il progetto crea un prodotto software che è l’insieme di tutti gli artefatti che permettono l'utilizzo di un programma da parte di un utente: codice, documentazione, prodotti intermedi quali casi di test, manuali tecnici, ecc. A differenza dell’industria manifatturiera, nella produzione del software non sono utilizzate tutte le componenti classiche di un processo di produzione (mezzi di produzione, forza lavoro e materie prime), ma è impiegata in modo rilevante la forza lavoro. Il processo di produzione del software, molto simile ad una progettazione continua del software (ciclo di vita del software) piuttosto che ad un processo tradizionale, produce in effetti un prodotto immateriale frutto dell’attività intellettuale. Il software non si può paragonare al generico prodotto industriale, in quanto si sviluppa e non si costruisce, e si ingegnerizza, ma non si fabbrica. L’adozione di un particolare modello di processo software dipende dai requisiti che deve soddisfare il processo di produzione in relazione ad aspetti come: tolleranza del modello ai rischi che si potranno incontrare; facilità di comunicazione tra sviluppatori e utilizzatori; stabilità dei requisiti noti; probabilità di esistenza di requisiti non ancora noti; importanza di rilasci ‘early’ di parziali funzionalità; intrinseca complessità del problema e delle probabili soluzioni; anticipata conoscenza di frequenza e dimensione di richieste di cambiamento; maturità dell’applicazione; disponibilità e priorità di fondi; flessibilità dello scheduling e budget; criticità del rispetto di scheduling e budget; adeguatezza del processo ‘istituzionale’ e tool di sviluppo dello sviluppatore; corrispondenza tra organizzazione del management e il modello da adottare. Il processo di produzione del software viene attuato con diversi modelli di processo software ( predittivi ed a adattivi) i cui paradigmi di processo vanno dal classico modello Waterfall (a cascata) ai metodi “Agili” passando dai modelli iterativi, incrementali, evolutivi e specializzati (sviluppo a componenti o software orientato dall’aspetto). Nei cicli di vita predittivi la preminenza è data all’ottimizzazione, rispetto all’adattabilità… mentre in quelli adattivi si cerca di rendere le fasi progettuali più compatibili con le esigenze del cambiamento in corso d’opera, rinviando il più possibile la pianificazione di dettaglio”
- Tra le tecniche e metodologie che certamente contribuiscono allo sviluppo del software, secondo un processo definito, controllato, misurato e migliorato, occorre considerare anche il Risk Management. Il rischio nell’area del software è stato rappresentato in modo sistematico da B. Bohem negli anni ’80 attraverso il Modello a Spirale che ha, appunto, come principio l’essere iterativo ed orientato al rischio, dato che per ciascuna iterazione viene eseguita un’analisi dei rischi (Boehm, 1991). La principale differenza tra il modello a spirale e gli altri modelli di processo software è proprio l’esplicita considerazione dei rischi (Sommerville, 2007). Attualmente, l’area che affronta i rischi nell’Ingegneria del Software si è evoluta da un'analisi all’interno di un modello di sviluppo, come proposto, dal modello a spirale, ad una tecnica di gestione che interessa tutti i processi del ciclo di vita del software.. I progetti che si riferiscono allo sviluppo del software sono intrinsecamente attività ad alto rischio poiché hanno l’obiettivo di rispondere a problemi complessi con delle soluzioni innovative entro vincoli di pianificazione, budget, risorse e tecnologie. In particolare, i progetti software, sono sempre più sottoposti a “stress” dovuti ai cambiamenti per il veloce “invecchiamento” dei requisiti e dei relativi prodotti, necessaria conoscenza di tecniche innovative, rischi imprevedibili e non definiti, tempi sempre più limitati, risorse limitate, caratteristiche di multi-progetto/multi cliente, coordinamento trasversale di team funzionali, siti di produzione del software su differenti posizioni geografiche. Il rischio, che la qualità di un prodotto software sia scadente o che si superino i tempi e costi di sviluppo, è elevato, come emerge dai dati riportati dallo Standish Group nel Chaos Report (Standish Group, 2009) dove si riporta che circa tre progetti software su cinque falliscono e/o non rispettano gli obiettivi prefissati di budget o di pianificazione. La vera sfida per l’attuale sviluppo del software è, pertanto, una efficace gestione dei rischi che migliori il rapporto successo/fallimento dei progetti software. Ciò richiede un profondo cambiamento di atteggiamento del team di progetto nel modo in cui il progetto stesso debba essere condotto. L'ambito di applicazione del progetto deve essere, inoltre, necessariamente ampliato sia per tenere conto di alternative modalità di sviluppo del progetto sia per analizzare i diversi fattori che potrebbero influenzare gli eventi I dati sconfortanti sulla probabilità di successo, hanno pertanto convinto il Management aziendale oltre che i Project Manager della necessità di adottare un processo di gestione dei rischi per i progetti software per i quali i rischi anche se non possono essere eliminati possono essere ragionevolmente gestiti e minimizzati. Il problema essenziale in tali progetti è individuare sono solo i “giusti rischi”, ma anche quelli che sono ovvi per i manager e professionisti del settore. Il Project Management nell’ambito di progetti software afferenti all’Information Technology, ha, quindi, adottato tecniche e metodi di gestione dei rischi di progetto software in accordo allo standard più diffuso come ISO 31000:2009 (Paragrafo 4.5) ed utilizzando le linee guida del PMBOK®, della PMI. In letteratura e nelle best practices si possono individuare tutta una serie di proposte adatte al contesto specifico dei progetti software con particolar riferimento all’individuazione dei fattori di rischio. Secondo il PMI (Project Management Institute (PMI), 2004) “ la gestione dei rischi di un progetto riguarda la conduzione dei processi legati alla pianificazione della gestione dei rischi, alla loro identificazione e analisi, alla preparazione delle risposte ai rischi e al loro monitoraggio e controllo nel corso del progetto”. La maggior parte di questi processi è aggiornata di pari passo con l’avanzamento del progetto. Gli obiettivi alla base della gestione dei rischi di progetto consistono nell’aumentare la probabilità e l’impatto di eventi positivi e nel diminuire la probabilità e l’impatto di eventi dannosi per il progetto
- Il rischio è un potenziale difetto il cui verificarsi comporta dei danni che possono essere o il non raggiungimento di uno o più obiettivi (benefici attesi) o costituire il fallimento totale del progetto. All’interno del processo di sviluppo del software ci sono molte aree di rischio e gli ingegneri software devono sviluppare dei modi e dei mezzi per assicurare che una possibile occorrenza di un evento indesiderato possa essere determinata presto. In questo modo sarà possibile applicare un piano correttivo per evitare conseguenze disastrose senza che ciò abbia un forte impatto sui costi. Pertanto, il rischio nello sviluppo del software può anche essere definito in termini generali come la probabilità che un evento dannoso per il processo di sviluppo del software possa verificarsi. Il rischio viene misurato come l’effetto combinato della probabilità che l’evento indesiderato occorra e la possibilità che una particolare conseguenza quantificata, misurata o accertata possa scaturire dal verificarsi dell’evento indesiderato. Esiston o diverse classi di rischi di progetto software: rischi generici comuni a tutti i progetti e rischi specifici del progetto. Alcuni di questi sono facilmente identificabili e gestibili. Altri sono meno ovvi e più difficili da predirne la probabilità e/o l’impatto. Ciò è complicato dalle multiple dimensioni di un progetto software come grandezza, struttura, complessità, composizione, contesto, innovatività, pianificazione a lungo termine ed orizzonte di esecuzione e volatilità delle modifiche. Anche se tutti i rischi non arrivano da pratiche software, essi potenzialmente impattano sul risultato di un processo software che rilasciano l’artefatto software. Come già evidenziato, i rischi di un progetto software derivano essenzialmente dalle incertezze intrinseche che la maggior parte dei progetti devono affrontare: requisiti definiti in modo approssimativo; difficoltà di stimare il tempo e le risorse richieste per lo sviluppo del software; dipendenza dalle singole capacità; modifica dei requisiti dovuti ai cambiamenti delle necessità del cliente Le numerose origini dei rischi di un progetto software sono principalmente individuabili in categorie come Fattori Tecnici (Requisiti, Tecnologia, Complessità ed interfacce, Prestazioni ed affidabilità, Qualità), Fattori Esterni (Subappaltatori, Normativo, Mercato, Cliente), Fattori Organizzativi (Relazioni di dipendenza dal progetto, Risorse, Finanziamenti, Priorità) e Project Management (Stima, Pianificazione, Controllo, Comunicazione). Una utile rappresentazione che permette di comprendere le origini da cui provengono i rischi è data dall’adozione di una struttura di scomposizione del rischio RBS (Risk BreakDown Structure), di cui in seguito si vedranno alcuni esempi, che ovviamente va adattata per i diversi tipi di progetto software ed organizzazione.
- In questo elaborato è stata effettuata un’analisi delle numerose proposte provenienti dalla letteratura (Boehm, 1991), (Schmidt, Lyytinen, Keil, & Cule, 2001), (Han & Huang, An Empirical Analysis of Risk Components and Performance on Software Projects, 2007), (Pare, G.; Sicotte, C.; Jaana, M.; Girouard, D., 2008), (Addision & Vallabh, 2002) (Arnuphaptrairong, 2011): Con un’attività di eliminazione delle sovrapposizioni o di raggruppamento di definizioni similari di rischio date dagli autori nelle diverse liste, è stata messa a punto una lista dei più comuni rischi di progetti software Dall’esame della sola frequenza dei rischi software nell’ambito delle top ten list, provenienti dalle diverse indagini emerge che la categoria di rischi oggetto di molta attenzione da parte dei Project Manager intervistati è la Pianificazione e Controllo. Infatti, la fase non solo è la più numerosa in termini di distinti fattori di rischio, ma anche perché i fattori di rischio componenti la dimensione indicati sono molto presenti nelle diverse top ten list esaminate. Si evince dalla distribuzione dei fattori di rischio rappresentata in Figura, che i Project Manager in fase di identificazione dei rischi prestano più attenzione ai rischi software relativi all’incomprensione dei requisiti, mancanza di commitment e supporto, mancanza del coinvolgimento dell’utente, fallimento nell’ottenere un impegno del cliente, fallimento nella gestione ed aspettative dell’utente, cambi dei requisiti e mancanza di una effettiva metodologia di Project Management. Non viene data, invece, molta importanza a fattori di rischio relativi alla Complessità Tecnologica e al Team (i fattori di rischio del Team sono più che altro relativi a qualità ed aspetti motivazionali del gruppo di lavoro).
- In letteratura, sono proposti numerosi paradigmi di gestione dei rischi in un progetto software (Boehm, 1991) (Williams, Pandelios, & Behrens, 1999) (Higuera & Haimes, June 1996) (Carr, Konda, Monarch, Ulrich, & Walker, 1993) (IEEE Standard 1540-2001, March 2001). Ciascuna di queste proposte, in sostanza, comprendono, pur con qualche specificità, processi ed attività, le seguenti fasi: Pianificazione della gestione dei rischi; Identificazione dei rischi; Analisi dei rischi; Classificazione dei rischi; Risoluzione o trattamento dei rischi ; Monitoraggio e controllo dei rischi; Tutte le fasi concorrono alla definizione ed aggiornamento del Registro dei rischi (o Plan Risk) che insieme al Piano di gestione dei rischi prodotto dalla fase di Pianificazione della gestione dei rischi costituiscono i principali risultati del processo di gestione dei rischi. Il processo di gestione dei rischi, produce inoltre anche aggiornamenti al piano di Project Management di cui il Piano di gestione dei rischi è un componente. Nella fase di Identificazione, viene fatto un inventario dei possibili rischi che potrebbero avere un impatto sul raggiungimento di determinati obiettivi. La fase parte con un’attività preparatoria per “candidare” i rischi e continua successivamente con la verifica di eleggibilità dei rischi usando varie tecniche come brainstorming, interviste, analisi dello scenario, etc.. che saranno esaminate nel capitolo successivo. Durante questa fase, vengono identificati i rischi, le loro conseguenze, gli effetti, le sorgenti dei rischi, cause del rischio e, successivamente, i rischi vengono categorizzati. Nella fase di Analisi dei Rischi, sono analizzati e classificati i rischi di un progetto. Si analizza individualmente ciascun rischio, studiando il rischio identificato e valutando il suo impatto, probabilità, esposizione e severità. L’analisi può essere condotta usando differenti tecniche come matrici di impatto, albero di decisioni ed analisi dello scenario. Dato che il rischio potrebbe implicare una potenziale perdita, si devono stimare due elementi del rischio: la probabilità che il rischio diventi un problema e l’effetto che il problema potrebbe avere sul risultato del progetto. Per i progetti software, ad esempio, il risultato auspicato è un prodotto accettabile entro il tempo e budget stabilito. I fattori che influenzano l’accettabilità del prodotto software comprendono le prestazioni delle funzionalità, uso delle risorse, affidabilità, versatilità, facilità di uso. L’approccio seguito, spesso, è valutare la probabilità del rischio calcolando la distribuzione di probabilità della grandezza del prodotto definita con opportuna metrica (numero di linee di codice o function point) e la complessità per determinare l’effetto del problema sorto sul progetto software. Monitorare e controllare i rischi è il processo di implementazione dei piani di risposta ai rischi, di rilevamento dei rischi identificati, di monitoraggio dei rischi residui, di identificazione di nuovi rischi e di valutazione dell’efficacia della gestione dei rischi durante l’intero progetto La pianificazione delle risposte ai rischi consiste essenzialmente in un processo di sviluppo delle opzioni e delle azioni per potenziare le opportunità e ridurre le minacce agli obiettivi del progetto. Il processo si occupa dei rischi in base alla loro priorità e necessità emerse, e produce un aggiornamento del Piano di Project Management inserendo risorse e attività nel budget, nella schedulazione. Il principale contributo dei modelli di processo gestione dei rischi è che essi guidano e gestiscono in modo diretto l’azione del rischio. I modelli di processo non forniscono, però, soluzioni “cookie cutter” per la gestione del rischio di progetti software. Un processo di gestione dei rischi con i relativi strumenti associati e tecniche pratiche richiede un’applicazione persistente di abilità e giudizio. La letteratura, in riferimento alla strategia di risposta, fornisce generiche opzioni per rispondere ai rischi di un progetto software (DeMarco & Lister, 2003) (Schwalbe, 2007). (Kerzner H. , 2003). Tipicamente, la strategia di risposta ai rischi punta a ridurre o eliminare la probabilità che si verifichi una minaccia oppure a limitare l’impatto del rischio nel caso si realizzi o punta a una combinazione di entrambi. Queste strategie sono formulate ed implementate in risposta ai rischi ogni volta che essi sono identificati e valutati come minacce che devono essere controllate.
- Tecniche e metodi per la fase di Analisi del rischio La lista dei rischi ottenuta nella fase di identificazione ci indica dove focalizzare l’attenzione e gli sforzi per poterli eventualmente fronteggiare, ma non dà nessuna indicazione sul “quanto” mettere in campo in termini di risorse economiche, umane e di tempo. A questo punto va definita anche l’effettiva probabilità (in termini numerici) di raggiungere gli specifici obiettivi di progetto, e un indicatore dell’esposizione verso i singoli rischi, che possano permettere di valorizzare le “riserve di contingenza” da prevedere ed accantonare. Il dimensionamento della reale portata delle conseguenze ipotizzate viene, di norma, effettuato con l’ausilio di tecniche diversificate a seconda che si adotti un approccio di tipo meramente quantitativo o si utilizzi un criterio rigorosamente quantitativo. Il primo porta ad una classificazione della rilevanza delle conseguenze dannose, mentre nel secondo si perviene ad un dimensionamento secondo una metrica coerente ed adatta al rischio da valutare. Gli strumenti utilizzabili, logicamente suddivisi in due categorie (una relativa all’analisi qualitativa e l’altra relativa all’analisi quantitativa dei rischi) sono molteplici: analisi di valutazione della probabilità ed impatto, che consente di esaminare la probabilità che ciascun rischio si verifichi e l’effetto potenziale del rischio su un obiettivo di progetto; analisi di sensitività, che consente di stabilire la relazione fra singolo rischio e obiettivo di progetto considerato; analisi decisionale “ad albero”, che aiuta a scegliere tra le varie alternative; simulazione, che usa modelli matematici per calcolare il potenziale impatto delle “incertezze” sugli obiettivi di progetto. Un esempio di tecnica è dato da Matrice di probabilità e impatto: ai rischi vengono assegnate della priorità in base alla combinazione dei loro indici di probabilità e impatto. Lo strumento più utilizzato per l'assegnazione della priorità è la matrice di probabilità e impatto, grazie alla quale, come sarà esaminato nell'analisi qualitativa, è possibile assegnare ai rischi una priorità “bassa”, “media” o “alta”. Le matrici di probabilità e impatto sono specifiche per ciascun obiettivo del progetto. La valutazione dell’importanza di ciascun rischio e delle relative priorità viene in genere condotta mediante una tabella di consultazione o una matrice di probabilità e impatto. Questo tipo di matrice specifica le combinazioni di probabilità ed impatto che portano alla classificazione dei rischi in bassa, media o elevata. Spesso si utilizzano valori numerici al posto della classificazione qualitativa. A seconda delle preferenze della struttura organizzativa, è possibile utilizzare anche termini descrittivi o valori numerici. Le regole di classificazione, ovvero le combinazioni di probabilità e impatto che conducono ad una classificazione di rischio elevato, medio o basso, vengono specificate dall’organizzazione prima all’avvio del progetto e possono essere personalizzate per il singolo progetto in fase di Pianificazione della gestione dei rischi. Si può assegnare una priorità ai rischi per un’ulteriore analisi quantitativa ed una risposta sulla base della relativa valutazione di rischio. La valutazione dell’importanza di ciascun rischio e, di conseguenza, la priorità di attenzione, è solitamente condotta utilizzando una tabella di associazione o una matrice di probabilità e impatto. Spesso, viene utilizzata una matrice di probabilità e impatto come quella rappresentata nella Tabella ( clicca per vedere la tabella)
- Analisi dell’albero delle decisioni Un generico processo decisionale consiste in un procedimento logico che si sviluppa attraverso una serie di passi (Definizione degli stati del sistema, Selezione delle decisioni, Stima degli esiti, Matrice dei pay-off, Valutazione delle alternative) in corrispondenza di ognuno dei quali possono essere assunte decisioni alternative che, in funzione di differenti circostanze esterne, producono un guadagno (o una perdita) monetaria. Un modo per calcolare i risultati finanziari di una interdipendenza da rischio su un progetto è l’utilizzo dell’albero decisionale, una tecnica sviluppata nel contesto della Teoria delle Decisioni. Tale tecnica è una efficace rappresentazione grafica che, oltre a rendere di immediata e agevole comprensione il particolare processo logico del project manager, si dimostra particolarmente utile per evidenziare le alternative ottimali nel contesto di processi decisionali particolarmente complessi. Infatti, la rappresentazione di Figura ( clicca per vedere un esempio) un albero delle decisioni (“decision tree”) consiste in un diagramma nel quale vengono indicate sia le possibili decisioni che si ipotizza di assumere al verificarsi di una particolare circostanza, sia gli esiti economico-finanziari che ragionevolmente potrebbero conseguirne.
- Criteri di Applicazione del processo di gestione rischi di un progetto software La funzione di presidio dei rischi rappresenta una componente essenziale dell’attività di gestione complessiva di un progetto e, proprio, per questo motivo necessita di un approccio sistematico, che ne assicuri la corretta impostazione, e formalizzato da apposite procedure aziendali in modo da garantirne i corretti canoni di applicazione. E’ molto importante, infatti, che la gestione dei rischi di progetto venga effettuata secondo regole aziendali istituzionalizzate, tese a definire quando deve essere svolta e come deve essere svolta. In riferimento al primo punto, bisogna applicare il più generale tra i principi manageriali, secondo il quale bisogna prestare attenzione al bilanciamento dei costi e dei relativi benefici. L’attività dovrà essere riservata soltanto a contesti di dimensioni (durata del progetto, anni/persona previsti per lo sviluppo del software, etc.) e/o criticità rilevanti (ambiente tecnologico fortemente innovativo, attenzione del top management, etc.), tali da assorbire, da una parte, e giustificare, dall’altra, gli inevitabili costi connessi alla sua conduzione. Anche per il livello di dettaglio al quale spingere tale analisi deve comunque limitarsi alla generazione di informazioni la conoscenza delle quali risulti economicamente utile in rapporto ai costi generati dal loro ottenimento. Ciò significa che, a livello aziendale, devono essere stabilite delle regole tese a definire per il progetto di sviluppo software: i limiti dimensionali: ovvero i valori al di sopra o al di sotto dei quali, rispettivamente, va applicato o meno il processo di gestione dei rischi. Nel caso di progetti software, gli intervalli dimensionali vengono espressi in unità di misura come l’effort in aa/pp (carico di lavoro anni/persona necessari per la realizzazione del prodotto software), durata temporale e valore economico complessivo. il grado di approfondimento: ovvero il livello di dettaglio (tipologia delle fonti di rischio da considerare, tecniche da utilizzare) al quale spingere l’analisi dei rischi relativamente a ciascun intervallo dimensionale, “calibrando” opportunamente il processo da utilizzare. Il livello ottimale al quale spingere il grado di sofisticazione delle metodologie è determinabile dalla condizione di pareggio tra costi e benefici marginali
- Come illustrato nella Matrice di probabilità ed impatto, un’organizzazione può valutare un rischio separatamente per ciascun obiettivo (ad es. costi, tempi e ambito). Inoltre, può sviluppare modi per determinare una valutazione generale per ciascun rischio. Si può sviluppare uno schema di valutazione generale del progetto per riflettere la preferenza dell’organizzazione per un obiettivo rispetto a un altro e utilizzare tali preferenze per sviluppare una ponderazione dei rischi valutati per obiettivo. Infine, le opportunità e le minacce possono essere gestite nella stessa matrice utilizzando le definizioni dei diversi livelli di impatto relative a opportunità e minacce. La valutazione del rischio aiuta a guidare le risposte ai rischi. Ad esempio, i rischi che hanno un impatto negativo sugli obiettivi, se si verificano (minacce) e che sono nella zona a rischio elevato (grigio scuro) della matrice, possono richiedere un’azione prioritaria e strategie di risposta aggressive. Le minacce nella zona a basso rischio (grigio medio) possono non richiedere azioni di gestione proattive oltre a essere poste su una lista di osservazione o aggiungere una riserva per contingency. Analogamente, le opportunità nella zona a rischio elevato (grigio scuro) che possono essere ottenute con maggiore facilità e offrono i maggiori vantaggi devono essere fissate come primo obiettivo. Le opportunità nella zona a basso rischio (grigio medio) devono essere monitorate. I valori forniti sono rappresentativi e il numero di gradini della scala è predeterminato e dipende dalle scelte dell’organizzazione. La matrice contiene nella colonne l’impatto atteso e nelle righe la probabilità di accadimento . E’ pertanto, possibile definire un SOGLIA DI ATTENZIONE che definisce il livello di esposizione al rischio ritenuto «significativo» Ciascun evento rischioso viene posizionato in una casella della matrice, evidenziando in tal modo , quelli che, essendo situati nel settore matriciale delimitato dalla SOGLIA DI ATTENZIONE richiederanno, in corso d’opera, un presidio più attento da parte del PM responsabile. In un approccio di tipo qualitativo, i singoli intervalli di valore vengono definiti attraverso una scala «aggettivale» che, per esempio, per quanto riguarda la variabile IMPATTO, secondo PRESSMANN potrebbe risultare catastrofico, critico, marginale, trascurabile. In modo del tutto analogo, anche per la probabilità si può definire una scala aggettivale caratterizzata dai seguenti livelli: molto alta, alta, media, bassa. Il passo successivo consiste nel fissare la scala di valori relativa al livello di esposizione del rischio che potrebbe essere, ad esempio, elevato, medio, basso e nello stabilire, infine, i criteri di confluenza, in base ai quali associare a ciascuna casella della matrice il corrispondente livello di esposizione. Resta da fissare solo il settore della matrice delimitato dalla soglia di attenzione .
- Il ricorso alle metodologie e alle tecniche sviluppate nel contesto della «teoria delle decisioni» risulta particolarmente utile in sede di quantificazione dei rischi di natura economico finanziaria e fornisce al valutatore un valido supporto metodologico che gli consente di confrontare l’efficacia associata a differenti alternative decisionali. Un generico processo decisionale consiste in un procedimento logico che si sviluppa attraverso una serie di passi successivi in corrispondenza di ognuno dei quali possono essere assunte decisioni alternative che, in funzione di differenti circostanze esterne, producono un guadagno (o una perdita) monetaria. La rappresentazione di un albero delle decisioni consiste in un diagramma nel quale vengono indicate sia le possibili decisioni che si è ipotizzato di assumere al verificarsi di una particolare circostanza, sia gli esiti economico finanziari che ragionevolmente potrebbero conseguirne. Per convenzione, il grafo viene costruito, da sinistra a destra e nell’ordine di seguito indicato: Circostanza: descrizione dell’evento di cui vogliono valutare i diversi risultati economici Decisione: descrizione della possibile decisione della quale si vuole valutare lo specifico risultato economico; Situazione o Stato futuro: scenario ipotizzato (s1, s2,..sn) unitamente alla probabilità (p1, p2,..pn) con la quale si prevede che lo stesso possa verificarsi; Esito: importo monetario stimato ottenuto per lo scenario in esame, da evidenziare nei nodi terminali posti all’estremità dei singoli rami. Vincoli: gli stati del sistema devono essere mutuamente esclusivi: gli stati considerati sono esaustivi ovvero non possono esistere altri oltre quelli contemplati; le decisioni debbono considerarsi mutuamente esclusive (Di∩Dj = 0) Per individuare la scelta più conveniente si inizia dai nodi terminali e si procede, quindi, risalendo all’indietro (da destra verso sinistra) lungo l’intero albero. Durante tale procedimento, si calcolano i guadagni (o le perdite) attesi e si riporta il valore monetario atteso (EMV) in corrispondenza dello specifico nodo. Quindi, per individuare la più conveniente tra le “m” possibili alternative decisionali si ricorre al “criterio a priori” suggerito da Bayes secondo il quale la decisione raccomandata è quella che rende massimo il guadagno atteso nel rispetto delle probabilità degli Stati futuri del Sistema. Gli alberi decisionali, permettono di assumere decisioni in condizioni di rischio e, quindi, permettono di determinare il rischio complessivo di una serie di rischi, ma va, comunque, sottolineato che gli alberi decisionali sono buone tecniche quando: le probabilità di accadimento di un rischio dipendono dai risultati di un rischio precedente, cioè, i rischi sono collegati; ci sono pochi risultati probabili per ogni punto decisionale e non un numero infinito. Se ci fosse un grande numero di potenziali risultati, questa tecnica sarebbe molto più complessa; ci sono implicazioni monetarie sui calcoli del rischio. Un esempio di albero delle decisioni è rappresentato in Figura dove si può osservare che la decisione migliore è “Ricorso al Fornitore B” in quanto presenta il migliore EMV.