Piano di gestione della qualità

Transcript

1 Piano di gestione della qualità Pianificazione della qualità Politica ed obiettivi della qualità Riferimento ad un eventuale modello di qualità adottato Controllo della qualità Procedure di controllo. Comunicazione e risoluzione di anomalie. Strumenti, tecniche, metodi (Technical reviews, Management reviews) Miglioramento della qualità 1

2 Qualità La qualità è il grado con cui un prodotto finito è conforme a dei requisiti stabiliti esplicitamente E anche il grado con cui lo sviluppo e la realizzazione di un prodotto è conforme alle pratiche standard e politiche esplicitamente stabilite E anche il grado con cui il prodotto possiede certe proprietà implicite e certe caratteristiche normalmente percepite dal consumatore come essere di alta qualità 2

3 Pianificazione della qualità Politica e obiettivi della qualità: intenzioni e direzione del team riguardo alla qualità del software scelta, costruzione e incidenza degli attributi di qualità Uso di modelli di qualità standard: McCall CMM ISO

4 Attributi della qualità Perché un attività di garanzia di qualità sia efficace, alcuni attributi della qualità devono comportarsi come degli indicatori di quanto il prodotto soddisferà i suoi requisiti Essi devono avere delle proprietà predittive: ci aspettiamo che le misurazioni fatte nelle prime fasi del ciclo di sviluppo forniscano indicazioni sulla qualità del prodotto finale Il numero e il tipo di errori trovati in una SRS durante una revisione (qualità dell SRS e del processo di revisione) Il numero e il tipo di difetti trovati nel testare un software (qualità del software e della specifica) 4

5 Attributi della qualità Fatta eccezione della correttezza, che viene misurata direttamente in termini del numero di difetti o deviazioni dalla specifica Tutti gli altri attributi di qualità dovrebbero essere deducibili dalla SRS se per esempio non c è un requisito specifico sulla flessibilità del sistema, fare il design tenendo conto di crescita o cambiamento è una deviazione dalla specifica 5

6 Fattori di qualità (secondo McCall) Correttezza: grado di aderenza del software alle specifiche (tracciabilità, coerenza e completezza) Efficienza: quantità di risorse e di codice necessarie perché il rpgramma adempia alla propria funzione(esecuzione, memorizzazione) Affidabilità: grado con cui un programma svolge la propria funzione con la precisione richiesta. (tolleranza all errore, accuratezza, semplicità) Integrità: grado con cui è possibile controllare l accesso al software o ai dati da parte di persone non autorizzate. (controllo degli accessi, valutazione degli accessi) Facilità d uso: misura l impegno necessario per imparare a usare il software, a prepararne i dati d ingresso e a interpretarne i dati d uscita. (operabilità, training, comunicabilità) Facilità di manutenzione: misura l impegno necessario per localizzare e correggere un errore nel programma (consistenza, semplicità, concisione, modularità, auto documentazione) Flessibilità: misura l impegno necessario per modificare il programma (espandibilità, generalità, auto documentazione, modularità) 6

7 Fattori di qualità (secondo McCall) 2 Collaudabilità: misura l impegno necessario per stabilire, tramite collaudo, se un programma svolge la funzione prevista (Semplicità, strumentazioni) Portabilità: misura l impegno richiesto per trasportare un programma da un ambiente hardware o software, a un altro. (auto documentazione, modularità, indipendenza da particolare macchina, indipendenza da sistema sw) Riutilizzo: misura il grado con cui un programma (o alcune sue parti) può essere utilizzato di nuovo in altre applicazioni; è correlato al modo in cui il programma è assemblato e alla portata delle funzioni svolte dal programma. (generalità, auto documentazione, modularità, indipendenza da particolare macchina, indipendenza da sistema sw) Interoperabilità: misura l impegno richiesto a far interagire il programma con altri programmi (modularità, standard di dati e di comunicazione) 7

8 Alcune attività da includere in un piano di qualità 1. Selezione delle pratiche per la garanzia di qualità: identificazione di tool specifici e tecniche per il monitoraggio della qualità dello sviluppo del software. Modifica di ogni tool e tecnica per adattarla agli aspetti unici del proprio processo di sviluppo. 2. Valutazione del piano di progetto software: il processo di valutazione del piano di sviluppo software è una delle revisioni più importanti e difficili da condurre 3. Accettazione della valutazione dei requisiti: essere concordi già nelle prime fasi del progetto su che cosa costituisca un prodotto accettabile è essenziale 4. Valutazione della specifica: requisiti mal definiti avranno un impatto negativo su ogni aspetto dello sviluppo del software inclusi i costi e lo schedule 5. Valutazione del processo di design: se i processi di design del software seguono una metodologia pianificata, sono saldamente basati sui requisiti, e sono gestiti e controllati in maniera rigorosa, la qualità del prodotto finale è superiore 6. Valutazione delle pratiche di codifica: una codifica scarsa può neutralizzare l effetto di una buona specifica dei requisiti e di un buon design 7. Valutazione del processo di test ed integrazione: è l indicatore più sicuro di un prodotto di qualità 8

9 Effetto degli errori sui costi L obiettivo principale delle revisioni tecniche formali è di scoprire degli errori durante il processo di sviluppo software No propagazione errori Nell attività di progettazione si introducono fra il 50% e il 65% di tutti gli errori del processo software D altra parte le tecniche di revisione formali possono scoprire fino al 75% degli errori di progettazione 9

10 Effetti della rilevazione anticipata degli errori cost to find and fix a defect 100 log scale Req. Design test code test field use 10

11 Amplificazione ed eliminazione degli errori Mediante un modello di amplificazione degli errori possiamo illustrare la generazione e la rilevazione degli errori nelle varie fasi di sviluppo Passo di sviluppo: Errori del passo precedente Errori ereditati Errori amplificati 1:x Errori generati ex novo Efficienza percentuale rilevazione errori Errori passati alla fase successiva 11

12 Revisioni tecniche formali Attività di garanzia di qualità del software svolta dai tecnici del software. Obiettivi: 1. Scoprire errori nelle funzioni, nella logica e nell implementazione di ogni parte del software 2. Verificare che il software soddisfi i requisiti 3. Garantire che il software sia rappresentato secondo gli standard predefiniti 4. Accertare che il software sia sviluppato in modo uniforme 5. Rendere i progetti più governabili 12

13 Revisioni tecnico formali indicazioni per un walkthrough Ci si concentra su una parte specifica e relativamente piccola del software (es una parte della SRS, il progetto dettagliato o il codice sorgente di un modulo) Riunione: Piccoli gruppi Lavoro di preparazione individuale sul lavoro da revisionare Riunione Valutazione: Accettazione senza modifiche Rigetto a causa di errori gravi (dopo la loro eliminazione si procederà a una nuova revisione) Accettazione con riserva 13

14 Revisioni tecnico formali indicazioni per un walkthrough Documentazione e registrazione delle revisioni Relazione Elenco di questioni sulla revisione Le revisioni vengono applicate solo a prodotti ritenuti più soggetti a errori 14

15 Strategie formali di SQA Esistono anche strategie più formali per la garanzia di qualità del software Si può affermare che un programma è un oggetto matematico sintassi e semantica rigorose Stessa cosa può dirsi di alcuni linguaggi di specifica che hanno semantica non ambigua Disponendo di una descrizione rigorosa dei requisiti (le specifiche) si possono applicare tecniche matematiche di dimostrazione di correttezza Verifica formale del programmi 15