Corso di Ingegneria del Software Paolo Bottoni

Transcript

1 Corso di Ingegneria del Software Paolo Bottoni Lezione 13: Gestione del progetto: Rischi e garanzia di qualità

2 Obiettivi Discutere rischio e processo di gestione rischio Discutere approccio alla qualità 2

3 Gestione dei rischi Identificazione rischi e disegno di piani per minimizzarne effetto su progetto. Rischio è probabilità di circostanza contraria Rischi progetto influenzano temporizzazione o risorse Rischi prodotto influenzano qualità o prestazioni software Rischi business influenzano organizzazione 3

4 Processo di gestione del rischio Identificazione rischio Identificare rischi di progetto, prodotto, business Analisi rischio Stabilire probabilità e conseguenze dei rischi Pianificazione rischio Evitare o minimizzare conseguenze Osservazione rischio Tenere sotto controllo rischi durante progetto Identificazione rischio Analisi rischi Pianificazione rischio Osservazione rischi Lista rischi potenziali Lista rischi prioritizzata Piani per evitare rischi e gestire contingenza Valutazione rischio 4

5 Identificazione dei rischi Rischi tecnologici Rischi legati a persone Rischi organizzativi Rischi in requisiti Rischi di stima 5

6 Esempi di rischio e tipi di rischio Rischio Influenza Descrizione Ricambio nel gruppo Progetto Membri esperti lasceranno progetto prima fine. Cambio dirigenza Progetto Futuro cambio gestione organizzativa con priorità diverse. Indisponibilità dell'hardware Cambiamenti nei requisiti Ritardi nelle specifiche Sottostima della taglia Prestazioni strumenti CASE insufficienti Cambiamenti di tecnologia Concorrenza al prodotto Progetto Progetto e prodotto Progetto e prodotto Progetto e prodotto Prodotto Business Business Hardware essenziale per progetto non sarà consegnato in tempo. Numero cambiamenti requisiti maggiore previsto. Specifica di interface essenziali non disponibili per scadenza prevista. Taglia progetto sottostimata. Strumenti CASE che supportano progetto non funzionano come previsto. Tecnologia di base per sistema sostituita da nuova tecnologia. Prodotto competitivo è commercializzato prima che sistema sia completato. 6

7 Analisi del rischio Stabilire probabilità e serietà rischi Scala di probabilità: molto bassa, bassa, moderata, alta, molto alta. Effetti rischi possono essere catastrofici, seri, tollerabili o insignificanti 7

8 Analisi del rischio (1) Rischio Probabilità Effetti Problemi finanziari organizzazione costringono a riduzioni bilancio progetto. Impossibile reclutare persone con competenze richieste per progetto. Bassa Alta Personale chiave ammalato in momenti critici. Moderata Seri Componenti software da riusare contengono difetti che ne limitano la funzionalità. Vengono proposti cambiamenti requisiti che comportano grossa ridefinizione progetto. Organizzazione ristrutturata, dirigenti diversi sono responsabili del progetto. Moderata Moderata Alta Catastrofici Catastrofici Seri Seri Seri 8

9 Analisi del rischio (2) Rischio Probabilità Effetti Base di dati usata in sistema non può gestire numero di transazioni / secondo atteso. Moderata Seri Tempo richiesto per sviluppare software sottostimato. Alta Seri Strumenti CASE non possono essere integrati. Alta Tollerabili Clienti non capiscono impatto cambiamenti in requisiti. Moderata Tollerabili Non disponibile addestramento richiesto per personale. Moderata Tollerabili Tasso di riparazione difetti sottostimato. Moderata Tollerabili Taglia software sottostimata. Alta Tollerabili Codice generato da strumenti CASE è inefficiente. Moderata Insignificanti 9

10 Tecniche di gestione del rischio Avoid Eliminare, ritirarsi, non farsi coinvolgere Reduce Ottimizzare, mitigare Retain Accettare e contabilizzare Transfer Esternalizzare o assicurare 10

11 Pianificazione del rischio Per ogni rischio sviluppare strategia di gestione Strategie per evitare Riducono probabilità che rischio emerga Strategie di minimizzazione Riducono impatto rischio su progetto o prodotto Piani di contingenza Se rischio emerge, come trattarlo Scatenati da evento significativo (trigger) 11

12 Strategie di gestione del rischio (1) Rischio Problemi finanziari organizzazione Problemi di reclutamento Malattie personale Componenti difettosi Strategia Preparare documento di aggiornamento per direzione che mostri contributo progetto a obiettivi economici. Allertare cliente su possibili difficoltà e ritardi, investigare acquisto di componenti. Riorganizzare gruppo: più sovrapposizione di lavori, persone capiscano lavoro altri. Rimpiazzare componenti potenzialmente difettosi con componenti acquistati con affidabilità nota. 12

13 Strategie di gestione del rischio (2) Rischio Cambiamenti nei requisiti Ristrutturazione organizzativa Prestazioni della base di dati Tempo di sviluppo sottostimato Strategia Derivare informazione di tracciabilità per stabilire impatto cambiamento requisiti, massimizzare modularità. Preparare documento di aggiornamento per direzione che mostri contributo progetto a obiettivi economici. Investigare possibilità di comprare base di dati con prestazioni migliori. Investigare acquisto di componenti, investigare uso di generatori di programmi. 13

14 Osservazione del rischio Valutare regolarmente ogni rischio identificato per valutare cambiamento probabilità Tenere sotto controllo indicatori specifici Valutare se effetti rischio cambiati Ogni rischio chiave dovrebbe venire discusso in incontri su progresso gestione. 14

15 Indicatori di rischio Tipo di rischio Tecnologia Persone Indicatori potenziali Tarda consegna di supporto hardware o softwate, riportati numerosi problemi tecnologici. Morale basso staff, relazioni povere fra membri gruppo, disponibilità di lavori. Organizzazionale Pettegolezzi organizzativi, mancanza azione dirigenti anziani. Strumenti Requisiti Stime Riluttanza a usare strumenti da parte gruppo, lamentele su strumenti CASE, richieste di macchine più potenti. Molte richieste di cambiamento requisiti. Lamentele cliente Piano di lavoro non rispettato, difetti riportati non corretti. 15

16 Livello di riferimento del rischio [Da SEPA 5/e] 16

17 RMMM Risk Mitigation, Monitoring, and Management Mitigation: Ridurre in anticipo probabilità e impatto rischi Monitoring: Osservare fattori che indicano cambiamento probabilità di rischio Management: Implementare piani di contingenza 17

18 Foglio di Informazione sul Rischio [Da SEPA 5/e] 18

19 Principi di SQA Approccio a gestione qualità Metodi / strumenti di SE efficaci Conduzione di revisioni tecniche Strategia di test multi-strato Controllo documentazione, aggiornamenti Procedure di adesione a standard Conduzione di misure, produzione di rapporti 19

20 Cos è la Qualità? Qualità progetto Analisi requisiti, specifiche Progetto architetturale, progetto dettagliato Valutare prodotto Progetto segue requisiti? Implementazione segue progetto? Prodotto soddisfa obiettivi prestazionali? Tracciabilità da requisiti a codice: fattore chiave per valutazione qualità 20

21 Fattori di qualità del prodotto Affidabilità Robustezza Prestazioni Usabilità Verificabilità Manutenibilità Riparabilità Evolvibilità Riusabilità Portabilità Comprensibilità Interoperabilità 21

22 Fattori di qualità del processo Produttività Visibilità Tempestività Qualità specifiche a tipo applicazione Es. sistemi informativi Integrità dati Sicurezza Disponibilità dati Prestazioni su transazioni 22

23 Controllo della Qualità Ispezioni, revisioni, test: Ogni modulo soddisfa requisiti? Feedback a processo di sviluppo Test automatizzati, manuali, ibridi Chiave: moduli devono avere specifiche definite e misurabili per valutazione uscite 23

24 Assicurazione della Qualità Funzioni di auditing e reporting Obiettivi: Fornire a management informazioni su qualità prodotto Permettere identificazione e soluzione problemi qualità 24

25 Attività SQA Gruppo o persona indipendente...ampie classi di errore sfuggono all originatore più facilmente che a chiunque altro [FRE90] Preparare piano SQA Valutazioni da eseguire Audizioni e revisioni da eseguire Standard applicabili a prodotto Rapporto e tracciamento errori Documenti da produrre da SQA Quantità/tipo di feedback a sviluppatori 25

26 Costo della Qualità (1) Costi di Prevenzione Pianificazione qualità Revisioni tecniche formali Testare attrezzatura e istruzione Costi di Valutazione first time through Progetto singolo vs. evoluzione storica Calibratura di attrezzatura e manutenzione Sforzo di testing 26

27 Costo della Qualità (2) Costi di errore includono: Costi di fallimento interno (prima di rilascio) Rilavorazione e riparazione Analisi modo di fallimento Costi di fallimento esterno (dopo rilascio) Risoluzione problema Ritiro e rimpiazzo prodotto Supporto con linea di aiuto Lavoro in garanzia 27

28 Costo della correzione dei difetti Costi relativi per trovare e riparare difetto crescono: Da prevenzione a individuazione Da interno a esterno Esempio IBM: Prevenzione = ~$90/difetto Correzione in campo = ~$25,000/difetto 280x più costoso! 28

29 [From SEPA 4/e] Costi di riparazione nelle fasi 29

30 Modello di amplificazione dei difetti [Da SEPA 4/e] 30

31 Defect Amplification: No Reviews [From SEPA 4/e] 31

32 Defect Amplification: w/reviews [From SEPA 4/e] 32

33 Rimozione dei difetti [Da SEPA 4/e] Percentage of Costly Defects Is Higher (66% vs. 93%) Total Number of Defects Much Greater 33

34 Revisioni Attività di progetto introducono 50-65% di errori Revisioni scoprono fino a 75% errori di progetto Risparmi per sviluppo e manutenzione 34

35 La riunione di revisione (1) 3-5 persone Preparazione in anticipo (< 2 ore per persona) Rivedere software, leggere documentazione Durata riunione < 2 ore Dare vincoli per limitare fuoco riunione Migliora probabilità di scoprire errori 35

36 La riunione di revisione (2) Agenda: Introduzione da parte sviluppatore Walk-through con domande e risposte Creare lista argomenti per revisione Decidere se: Accettare modulo senza modifiche Respingere per errori gravi (revisione da ripetere in futuro) Accettare con revisioni (senza nuova revisione) Rapporto riassuntivo / Elementi di Azione 36

37 Valutazione prodotti: livelli per DoD Item Target Malpractice Level Efficienza rimozione difetti >95% <70% Densità originale difetti <4 per function point >7 per function point Tempo o costo eccedenti dopo considerato rischio Crescita totale requisiti (function points o equivalente) 0% >=10% <1% per month average >= 50% Documentazione totale <3% pages per function point >6 pages per function point Ricambio staff 1 to 3% per year >5% per year

38 Gestione della Configurazione Software (SCM) Attività di ombrello con sottocompiti: Identificare cambiamento Controllare cambiamento Assicurare implementazione corretta Riportare cambiamenti ad altri Gestione efficiente cambiamento caratteristica di buona SE 38

39 SCI: Software Configuration Item Artefatti da gestire durante processo SE: Programmi Sorgenti, binari, file di risorse Documenti Dati Documenti tecnici, documenti utente In programmi o file separati 39

40 Relazioni tra Oggetti SCI Tracciabilità da requisiti a codice, fattore chiave per acquisire qualità 40

41 Baseline baseline (n): a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. (IEEE ) Baseline sono versioni finali stabilizzate dei prodotti 41

42 Baselined SCIs & Project Database [From SEPA 5/e] 42

43 Spazio delle versioni Particolare versione di entità può avere parecchie varianti! [Da SEPA 5/e] 43

44 Evoluzione degli Oggetti SCI Implementazioni alternative sviluppabili & valutabili in parallelo [From SEPA 5/e] 44

45 Evoluzione Controllata Strumenti per modellare cambio grafo evoluzione: CVS (Concurrent Versioning System) Subversion Strumenti peer-to-peer (es. git, Mercurial) Controllo di versione Procedure e strumenti per gestire versioni di oggetto Accesso e sincronizzazione vanno controllati 45

46 Controllo di Accesso & Sincronizzazione [Da SEPA 5/e] 46

47 Decidere se effettuare un cambiamento [From SEPA 5/e] 47

48 Realizzare il cambiamento [Da SEPA 5/e] 48

49 Verificare il cambiamento [From SEPA 5/e] 49