Verifica e validazione: introduzione

Transcript

Verifica e validazione
IS
Verifica e
validazione:
introduzione
IS
IS
Verifica e validazione – 2

La verifica si occupa di accertare che l’esecuzione
delle attività di processi svolti nella fase in esame non
abbia introdotto errori nel prodotto

La validazione si occupa di accertare che il prodotto
realizzato sia conforme alle attese
validazione
Ingegneria del Software
prodotto
intermedio
requisiti
V. Ambriola, G.A. Cignoni,
C. Montangero, L. Semini
verifica
Aggiornamenti di: T. Vardanega (UniPD)
Dipartimento di Informatica, Università di Pisa

Software verification



1/28
IS
Provides objective evidence that the design outputs of a particular
phase of the software development life cycle meet all of the
specified requirements for that phase
Software verification looks for consistency, completeness, and
correctness of the software and its supporting documentation, as it
is being developed, and provides support for a subsequent
conclusion that software is validated
2/28
prodotto
verifica
verifica
3/28
IS
validazione (vista cliente)
TA
verifica
validazione (vista fornitore)
RS
verifica
TS
verifica
DA
TI
verifica
Confirmation by examination and provision of objective evidence
that software specifications conform to user needs and intended
uses, and that the particular requirements implemented through
software can be consistently fulfilled
prodotto
intermedio
RU
Software validation

...
DD
verifica
TU
4/28
IS

Forme di analisi
Analisi statica



La più piccola quantità di SW che è conveniente verificare
singolarmente

La sua natura specifica dipende dal linguaggio di
programmazione in uso

Conformità a regole date, assenza di difetti, presenza di proprietà positive
Richieste esecuzione del programma


Viene effettuata tramite prove (test)
Usata sia nella verifica che nella validazione
5/28
IS

Unità
Analisi dinamica


Analisi dinamica: definizioni
Prevalentemente usata in verifica, quando il sistema non è ancora disponibile
Studia caratteristiche del codice sorgente (talvolta anche del
codice oggetto) e della documentazione associata



Non richiede esecuzione di alcuna parte del prodotto SW

IS
Analisi dinamica: ambiente di prova
Ambiente (HW, stato iniziale, …)

Specifica (ingressi richiesti, comportamenti attesi)

Procedure (esecuzione, analisi dei risultati)
Va sempre intesa in senso architetturale

Non linee di codice ma entità di strutturazione (procedura, classe, package)

Il «modulo» è parte dell’unità

Il «componente» integra più unità
7/28
IS
Stub e driver
U
Test di unità su U
M1
M2
a
D2
M3
b
D3
c
M1
Con driver
Strumenti
M2

Driver
componente attiva fittizia per pilotare una parte

Stub
componente passiva fittizia per simulare una parte

Logger componente non intrusivo di registrazione dei dati
di esecuzione per analisi dei risultati

Unità U composta
dai moduli M1, M2, M3
La ripetibilità è requisito essenziale

Tipicamente prodotta da un singolo programmatore
6/28
M3
M2
M3
Con stub
a
M1
S2
S3
b
M1
M2
S3
c
M1
M2
M3
8/28
IS
Tipi di test
Modulo
Test di unità
Modulo
Unità

Test di integrazione
Build
Modulo
Unità
Sistema
Collaudo
Sistema



Build
Modulo
Unità
Componenti sviluppati in parallelo e verificati
incrementalmente
In condizioni ottimali l’integrazione è priva di problemi
Quali problemi rileva

Modulo
Test di integrazione
Costruzione e verifica incrementale del
sistema

Test di sistema
IS


Errori residui nella realizzazione dei componenti
Modifica delle interfacce o cambiamenti nei requisiti
Riuso di componenti dal comportamento oscuro o inadatto
Integrazione con altre applicazioni non ben conosciute
Modulo
9/28
IS

Attività di analisi dinamica





Con il supporto di attività mirate di analisi statica
Si svolge con il massimo grado di parallelismo
Validazione

Test di sistema come attività interna del fornitore

Collaudo come attività supervisionata dal committente

Dello stesso programmatore per le unità più semplici
Di un verificatore indipendente (meglio un automa) altrimenti


10/28
Per accertare la copertura dei requisiti SW
Per dimonstrazione di conformità del prodotto sulla base di casi di prova
specificati nel o implicati dal contratto
Implicazioni contrattuali

Verificare la correttezza del codice «as implemented»
Test di sistema e collaudo

Obiettivi

IS
Responsabilità


Test di unità
11/28
Il collaudo è attività formale
Al collaudo segue il rilascio del prodotto (con eventuale
garanzia) e la fine della commessa (con eventuale
manutenzione)
12/28
IS

L’insieme di test necessari ad accertare che la
modifica di una parte P di S non causi errori in P o
nelle altri parti di S che dipendono da P


Test di regressione
13/28
IS
Forme di analisi statica

Non richiedono esecuzione di parti del sistema SW

Applicano a ogni prodotto di processo e non solo al
codice

Metodi di lettura (desk check)


Inspection e Walkthrough

Metodi pratici
Ripetizione di test già previsti ed effettuati per ogni parte coinvolta
Il rischio aumenta all’aumentare dell’accoppiamento e al diminuire
dell’incapsulazione

Basati sulla lettura della documentazione sul prodotto

Di efficacia dipendente dall’esperienza dei verificatori



Nell’organizzare le attività di verifica
Nel documentare le attività svolte e i risultati ottenuti
Modalità relativamente complementari
15/28
IS
Inspection


Impiegati solo per prodotti semplici
Metodi di lettura

Modifiche effettuate per aggiunta, correzione o
rimozione non devono pregiudicare le funzionalità già
verificate

IS
Obiettivi

Rivelare la presenza di difetti

Eseguire una lettura mirata [del codice]
Agenti

Verificatori distinti e separati dai programmatori
Metodi formali




Basati sulla prova assistita di proprietà
La cui dimostrazione dinamica può essere eccessivamente onerosa

Verifica di equivalenza o generazione automatica
Strategia
Focalizzare la ricerca su presupposti

14/28
Error guessing
16/28
IS
Attività di inspection
IS
Attività di walkthrough

Fase 1: pianificazione

Fase 1: pianificazione

Fase 2: definizione della lista di controllo

Fase 2: lettura

Fase 3: lettura [del codice]

Fase 3: discussione

Fase 4: correzione dei difetti

Fase 4: correzione dei difetti

In ogni fase

In ogni fase

Documentazione come rapporto delle attività svolte

17/28
IS
Documentazione come rapporto delle attività svolte
IS
Inspection contro walkthrough
Walkthrough

Obiettivo



A largo spettro

Senza l’assunzione di presupposti

Agenti



Rivelare la presenza di difetti
Eseguire una lettura critica [del codice]

Gruppi misti ispettori/sviluppatori ma con ruoli ben distinti
Strategia (per il codice)

Percorrerlo simulandone possibili esecuzioni
18/28
19/28
Affinità

Controlli basati su desk check

Programmatori e verificatori su fronti opposti

Documentazione formale
Differenze

Inspection basato su (errori) presupposti

Walkthrough richiede maggiore attenzione

Walkthrough più collaborativo

Inspection più rapido
20/28
IS


Verifica e validazione di qualità
Serve a raccogliere evidenza di qualità

Affidabilità
Dimostrabile tramite combinazione di prove e
analisi statica

A fronte di specifiche metriche e di obiettivi definiti

Verificare (validare) per dare evidenza

Analisi statica come attività preliminare

Controllo (interno) e accertamento (esterno)

Prove a completamento

ISO/IEC 9126 come riferimento
Liste di controllo rispetto ai relativi requisiti

Robustezza

Quali strumenti per quali caratteristiche?

Capacità di ripristino e recupero da errori

La qualità in uso è valutata a posteriori

Adesione alle norme e alle prescrizioni

21/28
IS
Funzionalità
Dimostrabile tramite prove
 Analisi statica come attività preliminare
 Liste di controllo rispetto ai relativi requisiti







Accertata la compatibilità tra le soluzioni realizzative adottate

22/28
Analisi statica come attività complementare
Liste di controllo rispetto ai manuali d’uso

Comprensibilità

Apprendibilità

Adesione a norme e prescrizioni
Questionari sottomessi agli utenti

Valutazione di accuratezza
Usabilità
Le prove sono imprescindibili

Tutte le funzionalità richieste per tutti e soli i componenti necessari
Sicurezza del prodotto e dei suoi componenti
Adesione alle norme e alle prescrizioni
23/28
IS
Interoperabilità

Valutazione di maturità
Completezza ed economicità


IS
Facilità e piacevolezza d’uso
24/28
IS

Le prove sono necessarie


Analisi statica come attività complementare
Margini di miglioramento e confidenza

L’efficienza provata fornisce confidenza nel prodotto

L’analisi statica fornisce indicazioni specifiche sui margini di
miglioramento prestazionale
25/28
IS
Manutenibilità

Analisi statica come strumento ideale

Liste di controllo



Analisi statica come strumento ideale

Liste di controllo rispetto a specifiche norme
di codifica

Quelle che puntano all’efficienza nel tempo e nello spazio
Rispetto a specifiche norme di codifica

Analizzabilità

Modificabilità

Ripetibilità

Verificabilità
Prove di stabilità
26/28
Adattabilità
Prove come strumento complementare

Facilità d’installazione e di sostituzione

Compatibilità ambientale
IS
27/28
Riferimenti

Standard for Software Component Testing,
British Computer Society SIGIST, 1997

M.E. Fagan, Advances in Software Inspection,
IEEE Transaction on Software Engineering,
luglio 1986

G.A. Cignoni, P. De Risi, “Il test e la qualità
del software”, Il Sole 24 Ore, 1998
Rispetto alle prove per accertarne

Portabilità

Liste di controllo rispetto alle norme di
codifica


Efficienza
IS
28/28

Verifica e validazione: introduzione

Transcript

Documenti analoghi

Partenaires del progetto L`approccio VITA alla valuta

1000 1100 1200 1300 1400 1500 1600 1700 Intensity (a rbitrary u

Invito 18.12.2015-A. Fascetti- Fazio degli Uberti poeta pisano

33 False verità sull`Europa Lorenzo Bini Smaghi

Analisi anagrafica stazioni qualità dell`aria ed estrazione dei

anche un indirizzo PEC di tipo CEC-PAC

Invito/programma

food hospitality world india

Clicca qui - Scuola di Ingegneria