rischi 1 - dmi.unict.itnicolosi/lezionips200809/lezione9.pdf · rischi 1 • definizione di rischio...
Post on 14-Feb-2019
258 Views
Preview:
TRANSCRIPT
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
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
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
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
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
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,..
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
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
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
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
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
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
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
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
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
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
Come gestire un rischio?
• Evitarlo• Prevenirlo (controllo)• Assunzione (riconoscere un rischio e
accettarne le conseguenze)• Trasferimento• Conoscenza attraverso la ricerca
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
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• …
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
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
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
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
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
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
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)
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
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
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
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
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
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
top related