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).

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

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– …

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)

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

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à)

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)

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

9

Contenuto di un piano SQAI contenuti generali di un piano SQA devono includere

1. Una lista di task2. Uno schedule per l’esecuzione dei task3. L’identificazione delle responsabilità dei task4. Le regole (standard, pratiche, politiche,..) impiegate

nell’esecuzione del task

10

Attività di SQA1. Selezione e modifica delle pratiche per la garanz ia 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à

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

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

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

14

Effetti della rilevazione anticipata degli errori

cost to findcost to findand fix a defectand fix a defect

100100

1010

loglogscalescale

11

Req.Req.DesignDesign

codecodetesttest

testtestfieldfield

useuse

0.750.75 1.001.001.501.50

3.003.00

10.0010.00

60.0060.00--100.00100.00

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 ereditati

Errori amplificati 1:x

Errori generati ex novo

Erroridel passoprecedente

Efficien-za per-centualerileva-zioneerrori

Errori passati alla fasesuccessiva

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 requisiti3. Garantire che il software sia rappresentato secondo gli

standard predefiniti4. Accertare che il software sia sviluppato in modo uni

forme 5. Rendere i progetti più governabili

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

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

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

20

Piano per la garanzia di qualità software generico

Strumento principale per il piano sono i qualitygate. 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

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 SQA6. Descrizione del controllo sui prodotti intermedi

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?

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?

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?

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?

26

Checklist del testing1. 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?

27

Checklist per la valutazione della revisione

1. Il materiale è completo?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?