Rischi 1. Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi

Transcript

1 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

2 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

3 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

4 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

5 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

6 Alcune aree di rischio per lo sviluppo software 1 1. Insufficienza di personale Gestione: assunzione di personale adeguato, subappalto, Pianificazione e budget non realistico Gestione: stima dettagliata dei costi e del programma, modello di sviluppo incrementale, rinegoziazione con il cliente, 3. Sviluppo delle funzioni software sbagliate Gestione: 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 sbagliata Gestione: costruzione prototipo, analisi casi d uso,..

7 Alcune aree di rischio per lo sviluppo software 2 5. Instabilità dei requisiti Gestione: 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 esterno Gestione: benchmarking, analisi di compatibilità, test di accettazione, 7. Gold Plating Gestione: 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 complesse Gestione: analisi tecnica, analisi costi benefici, analisi della performance, analisi delle dimensioni

8 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 specificati 2. La definizione dell interfaccia è inadeguata 3. I requisiti sono dichiarati in maniera vaga e inconsistente 4. Si fa poco uso del linguaggio di specifica 5. Manca la definizione di un test per ogni requisito 6. C è poca documentazione e di cattiva qualità 7. C è una definizione inadeguata dei bisogni e dei desideri del cliente

9 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

10 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

11 Valore Tre fattori che riguardano il rischio di requisiti instabili Qualità della specifica Sono necessarie poche correzioni Alcuni problemi nella spec. richiedono abbastanza lavoro per essere risolti.i problemi vengono risolti. Piano a posto Restano problemi rilevanti. Qualche attività attualmente in corso per risolvere problemi gravi Ci sono problemi gravi nella spec. Risorse insufficienti per occuparsi dei problemi e risolverli Problemi gravi nella spec. Nessun piano di soluzione Controllo dei cambiamenti Gerarchia di commissioni di controllo. Forte disciplina. Commissioni di controllo a posto. Tendenza ad una disciplina rilassata L attività di cambiamento non segue procedure formali stabilite. Le procedure informali funzionano Le procedure informali non funzionano bene (quelle formali vengono ignorate) Non c è nessun processo di controllo formale Impegno del cliente E d accordo con il criterio di accettazione Comprende il bisogno di stabilire dei criteri di accettazione. Gli operatori fanno emergere nuovi requisiti Gli operatori non si preoccupano del costo e dello schedule Il cliente non vuole controllare richieste di cambio operatore/utente

12 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 fattore PF = (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

13 Fattori correlati alle conseguenze di fallimento (rischio requisiti) Valore Costo Schedule Performance 0.1 Nel budget Nel piano Conseguenze minime, gestibile 0.3 Incremento dell 1-5% Slittamento minimo: 1 mese Piccola riduzione nel prodotto, performance e funzione 0.5 Incremento del 5-20% Slittamento di 1-3 mesi Qualche riduzione nel prodotto, performance e funzione 0.7 Incremento del 20-40% Slittamento maggiore di 3 mesi Significativa riduzione nel prodotto, performance e funzione 0.9 Incremento maggiore del 40% Slittamento maggiore di 6 mesi Il prodotto è inutilizzabile e rigettato dal cliente

14 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 fattore CF = (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

15 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

16 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

17 Come gestire un rischio? Evitarlo Prevenirlo (controllo) Assunzione (riconoscere un rischio e accettarne le conseguenze) Trasferimento Conoscenza attraverso la ricerca

18 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

19 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

20 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 documentazione 3. 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 organizzazione 5. 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

21 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

22 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 operatori 3. Dettagli migliorati (specialmente quelli di input/output) 4. Qualità del documento migliorata 5. 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

23 Esempio rischi della specifica dei requisiti Conseguenze negative specifiche associate a questi fattori includono 1. Inizio tardivo del design del software 2. Alto livello dell attività di cambiamento 3. Cambiamenti tardivi ai requisiti (nel processo di sviluppo sw) 4. Compromessi nelle funzionalità e performance del prodotto

24 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

25 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, schedule e 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

26 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 sviluppo 3. 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)

27 Esempio rischi della specifica dei requisiti Evento Tutti i TBD vengono chiusi in un mese 75% dei TBD vengono chiusi in 6 settimane Metà dei TBD vengono chiusi in 3 mesi 25% dei TBD vengono chiusi in 4 mesi Solo pochi TBD vengono in modo soddisfacente in 6-9 mesi Probabilità di fallimento

28 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

29 Esempio rischi della specifica dei requisiti PF ChiusuraTBD Operatori soddisfatti Dettagli migliorati Qualità migliorata Problema contratto 0.1 Tutti in un mese In gran parte soddisfatti Redistribuzione specifica Sì Sì 0.3 ¾ in 1.5 mesi ¾ soddisfatti Miglioramento significativo 75% 75% 0.5 ½ in 3 mesi ½ soddisfatti Qualche miglioramento 50% 50% 0.7 ¼ in 4 mesi ¼ soddisfatti Piccoli cambiamenti 25% 25% 0.9 Pochi in 6-9 mesi Ancora scontenti Nessun cambiamento No No

30 Esempio rischi della specifica dei requisiti CF Costo Schedule Performance 0.1 Impatto minimo Minimo Preoccupazione minima 0.3 Incremento del 5% Slittamento di 1 mese Piccola riduzione nella performance 0.5 Incremento del 10% Slittamento di 1-3 mese Qualche riduzione nella performance 0.7 Incremento del 25% Slittamento di 3 mesi Riduzione significativa nella performance 0.9 Incremento del 50% Slittamento di più di 3 mesi Performance insoddisfacente

31 Esempio rischi della specifica dei requisiti Ray stima che PF = ( )/ 5 = 0.34 CF = ( )/3 = 0.5 RF = PF + CF (PF * CF) = (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

32 Esempio rischi della specifica dei requisiti Lista di alcune idee per il piano di contenimento 1. Assegnare alcuni degli migliori ingegneri del software esperti per assistere gli ingegneri del team nel chiudere i TBD 2. Coinvolgere operatori di esperienza nel lavoro di design preliminare 3. Incoraggiare il manager a ripubblicare la specifica 4. Rendere noto al cliente del problema potenziale e di che cosa si sta facendo per correggere la situazione 5. Negoziare un cambiamento dello schedule del contratto 6. Dividere la specifica in due moduli separati e produrli sequenzialmente