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 (Management reviews, Technical reviews, Inspections, Audits) Miglioramento della qualità (se previsto dal modello adottato). 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 qualita 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: CMM ISO 9126 McCall 3

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 crescite o cambiamento è una deviazione dalla specifica 5

6 Fattori di qualità (secondo McCall) Correttezza: grado di aderenza del software alle specifiche (tracciabilità, consistenza e completezza) Affidabilità: grado con cui un programma svolge la propria funzione con la precisione richiesta. (tolleranza all errore, consistenza, 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 Garanzia di qualità software 1. Il modello di tutte le attività pianificate e sistematiche per fornire una confidenza adeguata che un prodotto è conforme a dei requisiti tecnici stabiliti 2. Un insieme di attività definite per valutare il processo con cui i prodotti vengono sviluppati o realizzati 8

9 Contenuto di un piano SQA I contenuti generali di un piano SQA devono includere 1. Una lista di task 2. Uno schedule per l esecuzione dei task 3. L identificazione delle responsabilità dei task 4. Le regole (standard, pratiche, politiche,..) impiegate nell esecuzione del task 9

10 Attività di SQA 1. Selezione e modifica delle pratiche per la garanzia di qualità: identificazione di tool specifici, tecniche, e requisiti per il monitoraggio della qualità dello sviluppo del software. Modifica di ogni tool e tecnica per adattarla agli aspetti unici dello 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 è assicurata 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. Adattare le procedure di garanzia di qualità 10

11 Quality gate Nei punti chiave del processo di sviluppo, un insieme dei quality gate viene integrato nel processo di sviluppo per monitorare la qualità del prodotto intermedio prima che quest ultimo possa passare al prossimo passo di sviluppo Sono revisioni formali e informali che hanno l obiettivo di fornire un mezzo per valutare il processo usato per sviluppare il software, la conformità del prodotto software alle esigenze del cliente e alle caratteristiche tecniche attese 11

12 Quality gate Sono eventi programmati regolarmente e condotti seguendo una procedura standard Va/non va: La revisione non viene tenuta se non si verificano certi eventi Il processo di sviluppo software riprende solo dopo che tutto il lavoro passato in revisione è stato completato e approvato dai revisori Revisioni tecniche formali (walkthrough: prova): condotte dai tecnici del sofware, è uno strumento efficace per miglioare la qualità del software 12

13 Effetti dei difetti software sui costi L obiettivo principale delle revisioni tecniche formali è di scoprire degli errori durante il processo di sviluppo per impedire che diventino difetti dopo la consegna del software No propagazione errori Nell attività di progettazione si introducono fra il 50% e il 65% di tutti gli errori (e di tutti i difetti) del processo software D altra parte le tecniche di revisione formali possono scoprire fino al 75% degli errori di progettazione 13

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

15 Amplificazione ed eliminazione dei difetti Mediante un modello di amplificazione dei difetti 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 15

16 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 uni forme 5. Rendere i progetti più governabili 16

17 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 17

18 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 18

19 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 19

20 Piano per la garanzia di qualità software generico Strumento principale per il piano sono i quality gate. I compiti di di garanzia di qualità dunque sono: La preparazione per i quality gate Sviluppo delle checklist e delle domande applicabili al prodotto da revisionare Identificazione degli attributi correlati al review insieme alle metriche appropriate, e la collezione e analisi dei valori associati a ciascun attributo Partecipazione alle revisioni Redazione del report post revisione 20

21 Piano per la garanzia di qualità software generico - outline 1. Scopo del piano qualità 2. Descrizione di tutti i prodotti lavorati dell ingegneria del software (modelli, documenti, codice sorgente) che rientrano nell ambito della SQA 3. Tutti gli standard e le pratiche applicati durante il processo di sviluppo software 4. Compiti relativi alla qualità 5. Strumenti e metodi che supportano le azioni e i compiti di SQA 6. Descrizione del controllo sui prodotti intermedi 21

22 Processo per la garanzia della qualità software 1 Il processo SQA comincia facendo una revisione in profondità sul processo di sviluppo del software CHECKLIST 1. I limiti del piano sono definiti in maniera chiara? 2. La terminologia è ben definita? 3. Le risorse richieste sono ragionevoli? Sono disponibili? 4. L analisi dei rischi è stata fatta? E il piano contenimento e/o prevenzione? 5. I compiti sono stati definiti e schedulati? 6. Le stime di costo e schedule sono ragionevoli? 7. E stato applicato uno standard nella stesura della documentazione? 8. Come sarà controllato il piano del progetto? 9. E necessario un ambiente per lo sviluppo del software? 22

23 Checklist per i requisiti software 1. Tutte le funzioni sono state definite chiaramente? 2. Ogni requisito funzionale è testabile? 3. E stato fatto un piano di test e di integrazione? I criteri di accettazione dei test sono stati già negoziati con il cliente? 4. Lo studio di fattibilità è completo? 5. L analisi dei rischi è stata iniziata/completata? 6. Sono stati applicati degli standard alla documentazione? 7. Come è andata la revisione? 23

24 Checklist per la specifica architetturale 1. Ci sono ancora dei requisiti aperti? Se sì, si progetta di chiuderli? 2. Il partizionamento è completo e documentato? 3. Tutte le interfacce hardware e software interne ed esterne sono state definite adeguatamente in termini di protocolli, range ecc..? 4. Il modello dei dati è stato completamente e accuratamente definito? 5. Possono essere soddisfatti i requisiti non funzionali? 6. Il partizionamento soddisfa i criteri di modularità? 7. Sono state definite le interfacce fra i moduli? 8. Il design della struttura dati è consistente con i requisiti dei dati? 9. Manutenibilità e flessibilità sono attributi di qualità considerati nel design? 10. Quali attributi di qualità sono applicati? 11. Gli standard di documentazione sono stati raggiunti? 12. Sono stati applicati degli standard nella pseudocodifica? Se sì, sono stati applicati? 13. Come è andata la revisione? 24

25 Checklist per la specifica di dettaglio 1. Sono stati tenuti in considerazione tutti i requisiti? 2. La specifica dettagliata è consistente con la precedente? 3. Lo pseudocodice o i diagrammi sono stati correttamente trasformati in codice? Hanno soddisfatto gli standard richiesti? 4. Sono stati soddisfatti gli standard per la documentazione? 5. I commenti soddisfano degli standard? 6. I tipi di dati e la dichiarazione dei dati è corretta? 7. I dati sono corretti? 8. Sono stati tenuti in conto gli attributi di qualità? 9. Come è andata la revisione? 25

26 Checklist del testing 1. I criteri di accettazione dei test sono stati definiti, negoziati ed accettati? Le revisioni sono state fatte come richiesto? 2. I piani di test sono stati preparati e revisionati? 3. L attività di testing è stata presa in considerazione in altre fasi di sviluppo? 4. Gli ambienti di test (strumenti e risorse) sono definiti in maniera adeguata e disponibili quando necessario? 5. La tracciabilità fra requisiti e test di conferma è stata completata e corretta? 6. Le funzioni principali sono confermate presto nella fase di testing? 7. Sono stati definiti degli standard per condurre i test? I tester sono stati sottoposti a training? 8. Sono stati definiti test limite e test di stress? 9. Il testing è fatto in maniera completa? 10. La gestione degli errori e delle eccezioni è stata testata? 11. Come è andata la revisione? 26

27 Checklist per la valutazione della 1. Il materiale è completo? revisione 2. Il materiale è stato distribuito in tempo? 3. Gli standard applicabili sono disponibili? 4. I partecipanti erano preparati a contribuire? 5. La valutazione è iniziata in tempo? 6. La revisione è stata condotta attraverso protocolli standard? 7. E stato identificato un certo numero di difetti? 8. Sono stati riportati gli attributi di qualità? 9. Si e cominciato a tracciare i difetti? 27