Top Banner
Rischi 1 Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Un ingegnere del software viene coinvolto direttamente nel processo di identificazione delle aree potenziali di rischio in un ambiente di sviluppo del software
32

Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Feb 14, 2019

Download

Documents

buidiep
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Rischi 1

• Definizione di rischio nello sviluppo del software

• Analisi dei rischi• Gestione dei rischi

Un ingegnere del software viene coinvolto direttamente nel processo di identificazione delle aree potenziali di rischio in un ambiente di sviluppo del software

Page 2: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Rischi 2

• All’interno del processo di sviluppo del software ci sono molte aree di rischio

• 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

Page 3: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Rischi 3

Un rischio nello sviluppo del software può essere definito in termini generali come la probabilità che un evento dannoso per il processo di sviluppo del software possa occorrere

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 dall’occorrere dell’evento indesiderato

Page 4: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Gestione del rischio

• Identificare le aree di rischio• Quantificare il rischio• Sviluppare dei modi per predire

l’occorrenza di eventi indesiderati (attraverso misurazioni)

• Controllare le misurazioni più volte durante lo sviluppo del progetto

• Pianificare azioni alternative o correttive nel caso occorrano gli eventi indesiderati

Page 5: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Perché fare l’analisi dei rischi?

• La gestione senior la chiede frequentemente– Anche se i rischi associati al processo di sviluppo del

software sono stati accettati, non si vuole arrivare impreparati

– Eseguendo l’analisi dei rischi è possibile avvertire la gestione riguardo a zone di possibile difficoltàrelativamente presto

Nel processo di sviluppo del software l’analisi del rischio e lo sviluppo di un piano di contenimento è spesso responsabilità dell’ingegnere del software

Page 6: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Alcune aree di rischio per lo sviluppo software 1

1. Insufficienza di personaleGestione : assunzione di personale adeguato, subappalto,...

2. Pianificazione e budget non realisticoGestione: stima dettagliata dei costi e del programma, modello di

sviluppo incrementale, rinegoziazione con il cliente,…

3. Sviluppo delle funzioni software sbagliateGestione: indagini sugli utenti, costruzione prototipi, sviluppo di

prime versioni del manuale utente, sviluppo di e accordo su dei criteri di accettazione,..

4. Sviluppo dell’Interfaccia utente sbagliataGestione : costruzione prototipo, analisi casi d’uso,..

Page 7: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Alcune aree di rischio per lo sviluppo software 2

5. Instabilità dei requisitiGestione: modello di sviluppo incrementale e rinvio dei cambiamenti a un

incremento successivo, controllo stretto dei cambiamenti, accordo su dei criteri di accettazione,..

6. Inadeguatezza delle componenti fornite dall’ester noGestione: benchmarking, analisi di compatibilità, test di accettazione,…

7. Gold PlatingGestione: riduzione dei requisiti, analisi costi benefici,…

8. Inadeguatezza dei compiti forniti dall’esterno Gestione: controllo delle referenze, prototipizzazione o design competitivo,

costruzione del team,..9. Performance requisiti real-time inadeguati

Gestione: simulazione, benchmarking, modellazione, prototipizzazione, analisi della messa a punto della strumentazione

10. Difficoltà nell’uso di tecnologie complesseGestione: analisi tecnica, analisi costi benefici, analisi della performance, analisi

delle dimensioni

Page 8: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Instabilità dei requisiti

Se l’analista riconosce che questo è potenzialmente un rischio alto nello sviluppo del software, esaminerà i requisiti funzionali e non funzionali per vedere se:

1. Ci sono requisiti non ancora specificati2. La definizione dell’interfaccia è inadeguata3. I requisiti sono dichiarati in maniera vaga e inconsistente4. Si fa poco uso del linguaggio di specifica5. Manca la definizione di un test per ogni requisito6. C’è poca documentazione e di cattiva qualità7. C’è una definizione inadeguata dei bisogni e dei desideri del

cliente

Page 9: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Un modello per i rischi

I rischi possono essere modellati come l’interazione di due variabili:

PF: probabilità di fallimento

CF: conseguenze del fallimento

FATTORE DI RISCHIO

RF = PF + CF – PF*CF

Page 10: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Approccio generale all’analisi dei rischi

• Identificare aree di potenziale rischio

• Suddividere ogni area di rischio in fattori critici

• Esaminare le conseguenze di un fallimento

Page 11: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Tre fattori che riguardano il rischio di requisiti instabili

Il cliente non vuole controllare richieste di cambio operatore/utente

Non c’è nessun processo di controllo formale

Problemi gravi nella spec. Nessun piano di soluzione0.9

Gli operatori non si preoccupano del costo e dello schedule

Le procedure informali non funzionano bene (quelle formali vengono ignorate)

Ci sono problemi gravi nella spec. Risorse insufficienti per occuparsi dei problemi e risolverli

0.7

Gli operatori fanno emergere nuovi requisiti

L’attività di cambiamento non segue procedure formali stabilite. Le procedure informali funzionano

Restano problemi rilevanti. Qualche attività attualmente in corso per risolvere problemi gravi

0.5

Comprende il bisogno di stabilire dei criteri di accettazione.

Commissioni di controllo a posto. Tendenza ad una disciplina rilassata

Alcuni problemi nella spec. richiedono abbastanza lavoro per essere risolti.I problemi vengono risolti. Piano a posto

0.3

E’ d’accordo con il criterio di accettazione

Gerarchia di commissioni di controllo. Forte disciplina.

Sono necessarie poche correzioni0.1

Impegno del cliente

Controllo dei cambiamenti

Qualità della specificaValore

Page 12: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Risultato atteso per ciascuno di questi fattori probabilità di fallimento

Facendo la media:

PF = (somma dei valori assegnati a ciascun fattore)/(numero dei fattori)

Pesando ogni fattorePF = (0.5 * valore fattore 1) + (0.3 * valore fattore 2) +

+ (0.2 * valore fattore 3)

Arrivare a un valore per ogni fattore richiede un’analisi completa del fattore e una solida base di esperienza

Page 13: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Fattori correlati alle conseguenze di fallimento (rischio requisiti)

Il prodotto è inutilizzabile e rigettato dal cliente

Slittamento maggiore di 6 mesi

Incremento maggiore del 40%0.9

Significativa riduzione nel prodotto, performance e funzione

Slittamento maggiore di 3 mesi

Incremento del 20-40%0.7

Qualche riduzione nel prodotto, performance e funzione

Slittamento di 1-3 mesiIncremento del 5-20%0.5

Piccola riduzione nel prodotto, performance e funzione

Slittamento minimo: 1 mese

Incremento dell’1-5%0.3

Conseguenze minime, gestibile

Nel pianoNel budget0.1

PerformanceScheduleCostoValore

Page 14: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Risultato atteso per ciascuno di questi fattori conseguenze del fallimento

Facendo la media

CF = (somma dei valori per le conseguenze dei fattori di fallimento)/(numero dei

fattori)

Pesando ogni fattoreCF = (0.6 * valore fattore costo) + (0.2 * valore fattore schedule) +

+ (0.2 * valore fattore performance)

Anche in questo caso l’assegnamento dei pesi è altamente soggettivo e deve essere analizzato attentamente

Page 15: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Valutazioni

I valori di PF e CF vengono utilizzati per stabilire la gravità del rischio

• Valori più piccoli di 0.3 sono considerati minimali (rischio minimale)

• Valori fra 0.3 e 0.7 sono considerati moderati (rischio moderato)

• Valori superiori a 0.7 sono considerati valori di rischio alto

Page 16: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Critica all’approccio

• Metodo altamente soggettivo per analizzare e quantificare i rischi

SOLUZIONE:Fare sondaggi fra persone esperte e fare

una media delle loro risposte produrrà una quantificazione del rischio più obiettiva

Page 17: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Come gestire un rischio?

• Evitarlo• Prevenirlo (controllo)• Assunzione (riconoscere un rischio e

accettarne le conseguenze)• Trasferimento• Conoscenza attraverso la ricerca

Page 18: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Misurazioni di performance tecnica

TPM: Misurazione continuativa di un attributo quantificabile del prodotto software

1. Fornire una misura del valore attuale di un attributo rispetto a quello pianificato

2. Fornire un rilevamento prematuro di problemi che richiedono attenzione tecnica o amministrativa

3. Fare da indicatore dell’effetto dei cambiamenti nei prodotti software

Page 19: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Alcune tipiche TPM

• Utilizzo di memoria e CPU• Capacità di I/O• Affidabilità/disponibilità/manutenibilità• Tempo di risposta• Costo e schedule• Completamento dei casi di test• …

Page 20: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Il capo di Ray Luciani, Fred Shepherd, chiama Ray a rapporto per discutere un problema. Fred ha saputo che la specifica dei requisiti di un prodotto critico non è adeguata. Pare che:

1. Ci siano troppi requisiti TBD, 2. La qualità globale della specifica è povera, e si è progredito poco

per rispondere alle deficienze della documentazione3. Molti dei requisiti di interfaccia sono vaghi ed incompleti 4. Alcuni requisiti funzionali e non sono al centro di una lite

contrattuale fra il cliente e l’organizzazione5. Il cliente si lamenta poiché ritiene che gli ingegneri del software

non hanno capito molte cose riguardo all’area di applicazione e a come gli operatori lavorano

Molti, nella comunità di sviluppo del software pensano che la specifica si debba riscrivere e ridistribuire con un conseguente slittamento nella programmazione dello sviluppo del progetto

Page 21: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Ray individuò cinque fattori di rischio specifici che, riteneva, si sarebbero direttamente associati con l’occorrenza dell’evento indesiderato:

Che la specifica dei requisiti software avrebbe fallito di compiere la sua ragione d’essere, quella cioè di definire accuratamente e completamente i requisiti funzionali e non funzionali del software da sviluppare.

Un fallimento nella specifica porterebbe sicuramente delle gravi perdite in termini di costi, di piano del lavoro, di performance del prodotto

Page 22: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Le cinque aree sono:1. La chiusura dei requisiti TBD (completamento della definizione

dei requisiti)2. Considerare e affrontare le preoccupazioni degli operatori3. Dettagli migliorati (specialmente quelli di input/output)4. Qualità del documento migliorata5. Risoluzione dei problemi nel contratto riguardanti i requisiti

Ray stabilisce che a meno che queste 5 aree non vengano migliorate significativamente, saranno inevitabili notevoli conseguenze negative

Page 23: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Conseguenze negative specifiche associate a questi fattori includono

1. Inizio tardivo del design del software2. Alto livello dell’attività di cambiamento3. Cambiamenti tardivi ai requisiti (nel processo di

sviluppo sw)4. Compromessi nelle funzionalità e performance del

prodotto

Page 24: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Per ciascuna di queste componenti di rischio Ray ha costruito, con l’aiuto dei colleghi, un range di possibili occorrenze

Situazione best-case:• Tutti i TBD vengono chiusi in modo soddisfacente in un mese• I problemi degli operatori vengono sistemati presto• La specifica viene rivista e redistribuita con un miglioramento

sostanziale in dettaglio e qualità• I problemi riguardanti il contratto vengono risolti con successo

Situazione worst-case:Non si fa nulla, ci si disinteressa dei fattori critici evidenziati

Page 25: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

• Successivamente Ray passa a stimare la probabilità di fallimento associata a ciascuno dei possibili risultati

Esempio:Se tutti i TBD vengono sistemati in un mese, gli operatori soddisfatti, la

qualità della specifica migliorata, il problema del contratto risolto, la probabilità di fallimento nello sviluppo (in termini di costo, schedulee performance) è approssimativamente 0.1

Se non viene fatta nessuna azione, la probabilità di fallimento è 0.9

• Ora si tratta di riempire il resto del modello. Ray dovrà stimare l’occorrenza più probabile o più attesa per ogni fattore

Page 26: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Il primo fattore di rischio di cui Ray si occupa è quello dei TBD non risolti

1. Accertamento del grado di interesse e impegno del manager di chiudere i TBD (ottiene la lista intera dei TBD)

2. Revisiona questa informazione con il team di sviluppo3. Considerata la serietà e la reputazione delle persone

con cui ha parlato, la natura dei problemi tecnici, il grado di impegno del manager, pensa che ci siano buone probabilità che i TBD vengano chiusi in tempo (cioè che vengano inclusi nella corrente fase di design preliminare)

Page 27: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

0.9Solo pochi TBD vengono in modo soddisfacente in 6-9 mesi

0.725% dei TBD vengono chiusi in 4 mesi

0.5Metà dei TBD vengono chiusi in 3 mesi

0.375% dei TBD vengono chiusi in 6 settimane

0.1Tutti i TBD vengono chiusi in un mese

Probabilità di fallimentoEvento

Page 28: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Che probabilità di fallimento associare a questo fattore?

Malgrado le garanzie e promesse fatte dal manager e malgrado il grado di impegno, Ray percepisce che più probabilmente solo il 75% si sarebbe completato in un mese, un mese e mezzo.

A causa di questa conclusione assegna al fattore probabilità di fallimento 0.3

• I TBD sono troppi, • nello schedule non c’è margine di errore, ogni TBD dovrà essere

rigorosamente risolto in tempo

• Nello schedule c’è poco tempo per la revisione

Page 29: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

NoNoNessun cambiamento

Ancora scontenti

Pochi in 6-9 mesi

0.9

25%25%Piccoli cambiamenti

¼ soddisfatti¼ in 4 mesi0.7

50%50%Qualche miglioramento

½ soddisfatti½ in 3 mesi0.5

75%75%Miglioramento significativo

¾ soddisfatti¾ in 1.5 mesi0.3

SìSìRedistribuzione specifica

In gran parte soddisfatti

Tutti in un mese0.1

Problema contratto

Qualitàmigliorata

Dettagli migliorati

Operatori soddisfatti

ChiusuraTBDPF

Page 30: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Performance insoddisfacente

Slittamento di più di 3 mesi

Incremento del 50%0.9

Riduzione significativa nella performance

Slittamento di 3 mesiIncremento del 25%0.7

Qualche riduzione nella performance

Slittamento di 1-3 meseIncremento del 10%0.5

Piccola riduzione nella performance

Slittamento di 1 meseIncremento del 5%0.3

Preoccupazione minimaMinimoImpatto minimo0.1

PerformanceScheduleCostoCF

Page 31: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Ray stima che

PF = (0.3 + 0.5 + 0.3 + 0.5 + 0.1)/ 5 = 0.34CF = (0.5 + 0.7 + 0.3)/3 = 0.5

RF = PF + CF – (PF * CF) = 0.34 + 0.50 – (0.34 * 0.50) = 0.67

Un fattore di rischio di 0.67 è moderato, ma vicino al limite 0.7, e sebbene accettabile, non può essere ignorato

Page 32: Rischi 1 - dmi.unict.itnicolosi/LezioniPS200809/Lezione9.pdf · Rischi 1 • Definizione di rischio nello sviluppo del software • Analisi dei rischi • Gestione dei rischi Un ingegnere

Esempio – rischi della specifica dei requisiti

Lista di alcune idee per il piano di contenimento1. Assegnare alcuni degli migliori ingegneri del software esperti per

assistere gli ingegneri del team nel chiudere i TBD2. Coinvolgere operatori di esperienza nel lavoro di design

preliminare3. Incoraggiare il manager a ripubblicare la specifica4. Rendere noto al cliente del problema potenziale e di che cosa si

sta facendo per correggere la situazione5. Negoziare un cambiamento dello schedule del contratto6. Dividere la specifica in due moduli separati e produrli

sequenzialmente