PROMETEO

Il Collaudo del software

Principi e metodologie di lavoro Autore: G. Ceseri

PROMETEO

Contenuti Fondamenti di qualità del software Principi del TQM Il modello del SEI La normativa ISO 9000-3 Attributi del software Prerequisiti dell’attività di collaudo Tecniche di collaudo Fasi dell’attività di collaudo Collaudo di regressione Strumenti per il collaudo del software Documentazione di collaudo e relativi standard Automazione delle attività di collaudo Manutenzione e SCM Raccolta e gestione di dati metrici sulla qualità del software Preventivazione, pianificazione, organizzazione e gestione delle attività di collaudo e manutenzione

PROMETEO

Fondamenti di qualità del software I difetti non si ottengono gratis. Qualcuno li ha prodotti, ed è stato pagato per farli. W.E. Deming

PROMETEO

Principi del Total Quality Management

PROMETEO

L’obiettivo fondamentale é la ‘Customer Satisfaction’. Essa è il fattore di traino, il giudice ultimo della qualità. Per questo motivo l’imperativo fondamentale è: conoscere il proprio cliente.

PROMETEO

La relazione cliente-fornitore va globalizzata, estesa ai rapporti interaziendali. Ad esempio la produzione deve essere vista dalla progettazione come un cliente. Questo atteggiamento orientato al cliente, evita che i vari settori aziendali ‘scarichino’ i problemi sulla ‘fase di lavorazione’ successiva.

PROMETEO

La qualità riguarda tutti, non è il lavoro di un gruppo di specialisti. Per questo assumono un ruolo essenziale il coinvolgimento, la formazione e in generale la qualità del personale dell’azienda. Lo specifico ruolo del management è quello di attivare e mantenere un meccanismo di ‘quality improvement’.

PROMETEO

E’ essenziale assumere una attitudine rivolta ad agire sulle ‘cause’ e non a rimediare ai ‘sintomi’. Req. Cod. Ist. Pro. Test Uso

La qualità va incapsulata DENTRO i prodotti e i processi produttivi.

PROMETEO

Non ha senso eseguire il controllo qualità ‘off-process’. In un certo senso è come pianificare i difetti, strutturandosi per trovarli e rimuoverli successivamente. Fra l’altro, operando così, solo una parte dei difetti verrà effettivamente rimossa. La qualità deve essere ottenuta ‘in-process’: non trovare , ma prevenire i difetti (approccio zero-defect). La qualità nasce dall’introduzione di un meccanismo di ‘quality improvement’ continuo del processo.

PROMETEO

Bisogna minimizzare il costo ‘globale’ del prodotto: di acquisto e di manutenzione (ovvero il costo del ciclo di vita). Non è vero che la qualità costa (se valutata sull’intero ciclo di vita). Il 25-40% dei costi delle aziende non operanti in regime di qualità, è da imputare proprio ai bassi livelli qualitativi. Tali costi scendono al 5% nelle aziende eccellenti.

PROMETEO

Solo in alcuni casi la qualità deriva da innovazioni rivoluzionarie. Essa deriva più frequentemente da un processo di miglioramento continuo (Kaizen). La qualità non è un obiettivo, è un viaggio.

PROMETEO

ACT PLAN

CHECK DO

Il ciclo PDCA deve essere iterato continuamente, apportando nuove migliorie nello stadio ACT.

TQM

PROMETEO

Per poter affinare continuamente il processo è essenziale instaurare un sistema di raccolta dati sul processo, da cui derivare le indicazioni su come modificarlo.

PROMETEO

Classificazione del livello di maturità del processo di produzione del

software

Il modello SEI

PROMETEO

1 Initial level 2 Repeatable level 3 Defined level 4 Managed level 5 Optimizing level

PROMETEO

1 Initial level Processo sotto controllo statistico

Anarchia (i programmatori si considerano artisti creativi, non soggetti a regole)

In situazioni di crisi si abbandona ogni procedura e ci si butta nel sano ‘code and testing’

PROMETEO

2 Repeatable level

L’organizzazione ha raggiunto un processo stabile (ma non formalizzato per iscritto), con un livello ripetibile di controllo statistico, attraverso un project management rigoroso dei commitments, dei costi, dello schedule e delle modifiche Prerequisiti * Esistenza di un gruppo di SW quality * SW commitments mgmt * Pianificazione SW e stima costi * Metriche su dimensioni e difetti * SCM e controllo modifiche * Procedure formali di gestione progetto * Procedure formali di SW testing TUTTO OK FINO A QUANDO NON SI SVILUPPANO NUOVI TIPI DI SISTEMI

PROMETEO

3 Defined level L’organizzazione ha definito il processo, per garantire realizzazioni consistenti e per fornire una base per comprendere il processo. Prerequisiti * Modello formale del processo * Standard formali e controllo del loro uso * Ispezioni * Politica formale di test e regression test * Programma di formazione specialisti * SCM più avanzato * Esiste un ‘SW Eng. Process Group’ IL PROCESSO E’ ISTITUZIONALIZZATO

PROMETEO

Solo al livello 3 (processo definito) l’impiego di CASE tool può dare risultati significativi.

Process

People Tools

PROMETEO

4 Managed Level

L’organizzazione ha iniziato un’attività completa di raccolta dati sul processo (non solo relativi a dimensioni e difetti). Prerequisiti * Procedura formale per l’adozione di nuove tecnologie * Sistema organico di metriche SW * Attività sistematica di stima e consuntivazione di dati metrici * Programma formalizzato di SW quality improvement

A QUESTO PUNTO COMINCIANO GLI INCREMENTI PIU’ SIGNIFICATIVI DI QUALITA’

PROMETEO

5 Optimizing Level

A questo punto l’organizzazione ha una base su cui fondare miglioramenti e ottimizzazioni continui del processo. Prerequisiti * Procedura formale per identificare e rimpiazzare tecnologie obsolete * E’ operante un meccanismo per analizzare le cause degli errori * E’ operante un meccanismo per avviare azioni di prevenzione dei difetti

PROMETEO

Evoluzione del processo

Basic mgmt control Process definition Process mgmt Process control

Initial

Repeatable

Defined

Managed

Optimizing

PROMETEO

Aspetti chiave 1. Chaos 2. Project Management Produttività 3. Methods and Tools & Qualità 4. Metrics 5. Qualità

PROMETEO

La situazione al 1991

7 % 12 % L 3 L 2 L 1 81 %

PROMETEO

Quale è il risultato ottenibile? Vari studi condotti in tempi diversi Sackman-Erikson-Grant (1968) B. Boehm, COCOMO (1982) De Marco- Lister (1987) Evidenziano che esiste un rapporto di benchmarking di circa 1:10 fra la peggiore e la migliore organizzazione.

PROMETEO

ISO 9000 - 3 Guida per l’applicazione di ISO 9001

allo sviluppo, alla fornitura e alla manutenzione del software

PROMETEO

ISO 9001

Sistema di qualità- Modello per la garanzia di qualità nel progetto/sviluppo, produzione, istallazione e servizio

PROMETEO

Responsabilità del management Deve essere definita la responsabilità e autorità delle persone che eseguono e verificano attività che influenzano la qualità.

Design review e audit del sistema di qualità, dei processi e/o dei prodotti devono essere svolti da personale indipendente.

Deve esistere un rappresentane del management responsabile del controllo della applicazione dei requisiti ISO 9001.

Deve avvenire una review periodica del sistema di qualità.

L’acquirente è responsabile della nomina di un rappresentante per la gestione cooperativa del rapporto contrattuale.

PROMETEO

Sistema di qualità

Deve essere stabilito un sistema di qualità documentato che copra tutto il ciclo di vita, tendente a prevenire i difetti e soggetto ad un affinamento continuo.

Per ogni sviluppo software deve essere prodotto un Quality Plan.

Deve essere eseguito un insieme organico di attività di quality audit pianificate e documentate.

Devono esistere procedure documentate per le azioni correttive.

PROMETEO

Attività nel ciclo di vita Aspetti generali

Il contratto deve essere soggetto a procedura formale di reviewing, con particolare riguardo a criteri di accettazione, cambiamenti di requisiti, criteri per la gestione di problemi rilevati dopo l’accettazione, responsabilità dell’acquirente, elementi forniti dall’acquirente, standard e procedure da usare. L’acquirente deve fornire o comunque firmare per accettazione un documento dettagliato di specifica dei requisiti. Deve essere definito un accurato piano di sviluppo, integrato con i piani di qualità, di configuration management, di integrazione e di test. Bisogna definire con esattezza gli strumenti e le metodologie da adottare. Ogni fase di attività deve essere accompagnata da un’appropriata fase di verifica.

PROMETEO

Contenuti del Quality Plan

Obiettivi di qualità, espressi in termini quantitativi quando possibile.

Input e Output di ogni fase di attività.

Identificazione dei tipi di attività di test, verifica (stiamo facendo il prodotto nel modo corretto?) e validazione (stiamo facendo il prodotto giusto?).

Piano delle attività di test, verifica e validazione.

Definizione delle responsabilità organizzative per le attività legate alla qualità.

PROMETEO

Collaudo e validazione Il Test Plan Document deve includere: - piano di collaudo, - test case - ambiente, strumenti e software di collaudo - criteri per la valutazione dei test - definizione del personale richiesto e del relativo training.

I risultati dei test debbono essere documentati e vanno valutati tutti i possibili impatti che il loro esito può avere, anche su aree di sistema diverse da quella sotto test.

Il software deve essere sottoposto a validazione completa nelle condizioni operative finali dell’applicazione, prima di procedere alla esecuzione del collaudo di accettazione col commitente.

PROMETEO

Consegna

Bisogna provvedere ad una adeguata duplicazione e archiviazione della software release consegnata. E’ essenziale predisporre anche un opportuno disaster recovery plan.

La consegna e la installazione debbono poi essere soggette ad una accurata attività di pianificazione.

PROMETEO

Manutenzione Le esigenze e quindi le modalità del servizio di manutenzione debbono essere definite in fase di stipulazione del contratto. La durata del contratto e l’area delle attività di manutenzione (correttiva, adattiva e perfettiva) debbono essere definite. Deve essere definita l’organizzazione di supporto, con identificazione dei rappresentanti sia lato fornitore, sia lato commitente. Devono essere predisposti: una procedura di gestione della documentazione di manutenzione e uno standard per la redazione dei documenti. Devono essere tenuti dati statistici su failure e interventi. Deve esistere una procedura definita per la emissione delle software release.

PROMETEO

Configuration Management

Devono esistere regole per identificare in modo univoco la versione di ogni componente e delle release complete di prodotto. Deve esistere un Configuration Management Plan che identifichi le responsabilità organizzative, gli strumenti, le metodologie e lo stadio in cui i componenti debbono essere messi sotto controllo di configurazione. Le modifiche debbono essere eseguite nel rispetto di una procedura definita e documentata. Deve essere mantenuto aggiornato un rapporto sullo stato della configurazione (stato dei componenti, richieste di modifiche, ecc.).

PROMETEO

Documentazione Tutta la documentazione (sia tecnica, sia gestionale) deve essere gestita in base ad una procedura rigorosa e documentata.

E’ necessario inoltre mantenere, in modo accurato, un archivio di documenti che attestino lo stato del sistema di qualità adottato dall’organizzazione.

PROMETEO

Misure E’ necessario eseguire un rilievo metrico su ogni prodotto, che permetta di mantenere il prodotto sotto controllo di qualità.

Debbono essere mantenuti dati metrici anche sul processo di sviluppo, in modo da poterlo tenere sotto controllo e migliorarlo.

PROMETEO

Acquisti

I prodotti o i servizi software acquisiti dall’esterno devono essere ordinati sulla base di documenti che descrivono in dettaglio l’oggetto di fornitura.

Devono esistere: una procedura organica per la selezione dei fornitori esterni (qualificazione della qualità) e una procedura per mantenere un archivio di dati su di essi.

Il fornitore è responsabile della validazione delle attività decentrate all’esterno.

PROMETEO

Attributi del software Io non mi preoccupo che una cosa sia economica o costosa. Mi preoccupo che sia buona. Se sarà buona abbastanza, il pubblico pagherà per essa. W. Disney

PROMETEO

Alcune definizioni

Requirement funzione o proprietà richiesta al sistema

Error eseguito in progetto o

codifica, implica la non soddisfazione di uno o piu’ “requirement”

Fault evento in cui uno stimolo

(input) porta a manifestare un “error” non rilevato precedentemente

Failure evento per cui il sistema perde

la capacità di compiere la sua missione, come conseguenza di uno o più “fault”

PROMETEO

Affidabilità

Qualità dell’analisi funzionale + Qualità del progetto + Qualità del codice + Qualità del collaudo + Qualità della manutenzione e del SCM = Affidabilità L’AFFIDABILITA’ SI MANIFESTA CON UN BASSO TASSO DI FAULT

PROMETEO

Manutenibilità

Astrazione + Struttura + Leggibilità + Tracciabilità + Bassa complessità dei componenti + Buona documentazione + Buon SCM = Manutenibilità

PROMETEO

Tracciabilità

quale modulo software

quale funzionalità

quale elemento della struttura dati

quale sottosistema dell’architettura

Difetto

PROMETEO

Tracciabilità

quale modulo software

quale funzionalità

quale elemento della struttura dati

quale sottosistema dell’architettura

nuova esigenza funzionale

PROMETEO

Tracciabilità

E’ pesantemente influenzata dalla complessità

delle interfacce software. Esse debbono essere:

- poche

- a basso throughput

- assoggettabili a monitoring

PROMETEO

Robustezza

Capacità di ‘assorbire’ input anomali + Capacità di operare in un ambiente hardware degradato + Capacità di operare in un ambiente di software di sistema degradato + Capacità di operare in un ambiente applicativo degradato + Capacità di sopportare carichi superiori a quelli nominali + Capacità di autocorrezione di situazioni anomale = Robustezza

PROMETEO

Processo di gestione del software

Affidabilità, manutenibilità, robustezza e tracciabilità permettono al software di beneficiare di un lungo ciclo di vita, con conseguente aumento del ritorno dell’investimento.

Tali attributi debbono essere mantenuti e possibilmente migliorati nel ciclo di vita, attraverso procedure corrette di manutenzione e SCM e attraverso rilievi metrici che consentano di identificare i “punti deboli”.

PROMETEO

Regola di Pareto

L’ 80% dei problemi deriva dal 20% dei sottosistemi.

PROMETEO

Preparazione dell’attività di collaudo Gestisci le cose difficili quando sono ancora facili. Risolvi i grandi problemi quando sono ancora piccoli. Prevenire grandi problemi con piccole azioni è più facile che risolverli. Attraverso piccole azioni possono essere conseguite grandi cose. Lao Tzu

PROMETEO

Premesse

1) Il collaudo del software è l’attività di progetto più costosa.

2) La rimozione degli errori è tanto più costosa quanto più avanti avviene nel ciclo di sviluppo.

3) La dimostrazione formale di correttezza è inattuabile allo stato dell’arte. Ne segue che:

a) ogni prodotto software incorpora un

certo numero di errori

b) il quality assurance mira a ottenere prodotti dotati del voluto livello di affidabilità.

PROMETEO

Prerequisiti dell’attività di collaudo

1) Documentazione di Requirement

2) Documentazione di Progetto Software

3) Piano di progetto

4) Software Quality Assurance Plan (SQAP)

5) Software Configuration Management Plan (SCMP)

PROMETEO

Software Quality Assurance Plan

Definisce il piano di qualità adottato

per uno specifico sviluppo software.

PROMETEO

Struttura del SQAP

1. Scopo 2. Documenti di riferimento 3. Management 4. Documentazione di progetto 5. Standard, norme e convenzioni 6. Review e audit 7. Configuration management 8. Reporting dei problemi e azioni correttive 9. Strumenti, tecniche e metodologie

10. Controllo del codice 11. Controllo dei media 12. Controllo dei fornitori

IEEE STD 730-1984 / ESA PSS-05-0

PROMETEO

Preparazione delle attività di collaudo (fase 1)

1. Identificazione dei requisiti

2. Associazione dei requisiti alle unità di software

3. Definizione dei test e delle catene/sequenze di test

Req. Doc

Matrice di verifica

SW Design Doc.

Matrice di tracciabilità

Test case e catene di test

PROMETEO

Matrice di verifica Metodo I = ispezione del codice

A = esecuzione di calcoli (i.e., calcolo di occupazione di memoria)

T = esecuzione Livello M = modulo/sottosistema

S = sistema

I = installazione (hw + sw)

Numero di Req. Paragrafo Descrizione

LivellMetodo

M S I I A T

0340101 3.4.1.1

PROMETEO

Matrice di tracciabilità

Aggiunge alla matrice di verifica una

colonna, per identificare le unita’ di

software coinvolte nel conseguimento del

requisito.

PROMETEO

Diagramma di sequenza di test

Req. 4 Req. 1 Req. 3

Req. 2

Hardware speciale

PROMETEO

Catena di test

E’ una unita’ di lancio che raggruppa un certo insieme di test, correlati da:

1) esigenza delle stesse condizioni di attrezzaggio iniziale, 2) appartenenza alla stessa area funzionale (opzionale).

PROMETEO

Preparazione delle attività di collaudo (fase2)

4. Definizione del materiale di supporto

5. Definizione di date e durate

6. Predisposizione di un piano di integrazione

7. Scrittura del STP

Lista materiale

Project Plan

SQAP

SCMP

STP

Test case e catene di test

Matrice di tracciabilità

PROMETEO

Materiale di supporto

Software di collaudo Strumenti di collaudo Simulatori

PROMETEO

Tecniche di integrazione

1) Big - Bang 2) Top - Down 3) Bottom - Up 4) SW Layers

PROMETEO

Ovviamente la stesura di un

STP è, di norma, ottenuta

mediante un processo di

affinamento successivo.

PROMETEO

Procedura ESA PSS-05-0

Implementation of tests

List of acceptance test

Documento UR SR AD DD

SQAP

SCMP

STP

Fase

Detailed SQAP

Initial SQAP

STP3 STP1 STP2

SCMP

Design of test

PROMETEO

Tecniche di collaudo Non esistono proiettili d’argento. Frederik Brooks

PROMETEO

Ispezione

Utile per collaudare situazioni difficilmente riproducibili (i.e., condizioni di errore di system services).

Analisi

Verifiche eseguite per calcolo (i.e., occupazione di memoria calcolata dai dati contenuti nelle link map).

Dimostrazione e Test

Esecuzione di test case. Certificazione

Pura consegna di documentazione dei test eseguiti.

Implicazione

Verifica di requisiti attraverso la verifica di requisiti implicanti.

PROMETEO

Tecniche di test

Black-Box testing

E’ la tecnica di test fondamentale. L’unica valida per i test formali di accettazione.

SISTEMA

OUTPUT

OUTPUT ATTESO

STIMOLO

?

PROMETEO

Tecniche di test

White-Box testing (Glass-Box testing)

Di solito è usato informalmente (istintivamente) a livello di test di modulo.

TEST 2

TEST 1

OUT OK?

PROMETEO

La copertura funzionale

E’ in sostanza la percentuale di funzionalità elementari coperte dal collaudo.

E’ perseguita dal black-box testing.

PROMETEO

La copertura topologica

C0 = N. istruzioni esercitate almeno una volta / N. totale di istruzioni eseguibili

(copertura istruzioni)

C1 = copertura dei ‘segmenti’ di programma

C2 = copertura del richiamo di moduli e sottoprogrammi

C3 = copertura dei cammini dall’ingresso all’uscita del programma.

E’ perseguita dal white-box testing. La copertura topologica media di un prodotto immesso sul mercato con una qualificazione non sistematica è in genere del 20-25 %.

PROMETEO

Tipologia dei test

TEST POSITIVI funziona!

TEST NEGATIVI è robusto!

PROMETEO

Fasi dell’attività di collaudo

La montagna c’è e ci sarà finchè esiste la coscienza. Robert Pirsing

PROMETEO

Test di modulo

Test di integrazione

Test funzionale

Test di sistema

Test di accettazione

PROMETEO

Test di modulo

E’ noto anche come unit test.

La ‘unità’ soggetta a test può cambiare da progetto a progetto (tipicamente è una task in sistemi a task concorrenti).

E’ condotto prevalentemente con tecnica glass-box.

PROMETEO

Test di integrazione

Ha come scopo principale il collaudo delle interfacce software, oppure la verifica della corretta interazione fra hardware e software.

PROMETEO

Test funzionale

Ha lo scopo di validare funzionalmente il sistema.

E’ condotto con tecnica black-box.

PROMETEO

Test di sistema

Il sistema funziona ma:

1) regge le varie condizioni di carico? 2) gestisce adeguatamente i picchi? 3) come reagisce alle anomalie hardware? 4) come reagisce ad un uso improprio? 5) quale è il suo MTBF?

PROMETEO

Test di sistema

E’ condotto essenzialmente con tecnica black-box e porta ad eseguire prevalentemente test negativi. L’esito del test non è semplicemente ‘affermativo o negativo’, ma porta spesso al rilievo di dati quantitativi.

PROMETEO

Test di accettazione

E’ il collaudo formale condotto prima del rilascio del prodotto al committente. E’ eseguito secondo procedure concordate fra committente e fornitore.

PROMETEO

Documentazione di collaudo

Standard per STP

Come questa tazza, disse Nan-in, tu sei ricolmo delle tue opinioni e congetture. Come posso spiegarti lo Zen, se prima non vuoti la tua tazza. 101 Storie Zen

PROMETEO

IEEE 829-1983

IEEE 829-1998

DOD-STD-2167A

MIL-STD-498

ESA PSS-05-0

ECCS STD

PROMETEO

IEEE 829-1983

PROMETEO

Section 1 - Test Plan Identifier Si limita a fornire un identificatore univoco del STP. Esso può essere relativo ad un intero sistema, a parte di esso o ad una specifica attività di test (i.e., performance test).

Section 2 - Introduction Contiene una sintetica descrizione del sistema e fornisce i riferimenti alla documentazione di progetto esistente in area gestionale (i.e., SQAP, SCMP).

PROMETEO

Section 3 - Test Items Elenca gli oggetti da sottoporre a test, la loro versione/revisione, i media impiegati per trasferirli alla struttura di collaudo. Fornisce i riferimenti alla documentazione tecnica di progetto, rilevante per il test da eseguire. Definisce cosa non deve essere sottoposto a collaudo (i.e., unità di acquisizione dati, ma non la connessione verso host system).

Section 4 - Feature to be tested Per ogni ‘test item’ elencato in Sezione 3 identifica tutte le ‘feature’ o le combinazioni di ‘feature’ da sottoporre a test. Identifica le specifiche di progettazione di test per ogni ‘feature’ o combinazione di ‘feature’. Per ‘feature’ si intende una caratteristica del software (i.e., funzionalità, prestazioni, ecc.). La scrittura di questa sezione è enormemente semplificata dalla definizione di una matrice di verifica nella fase di attività che prepara la stesura del STP.

PROMETEO

Section 5 - Features not to be tested Strutturalmente molto simile alla precedente, questa sezione ha uno scopo diverso. Essa serve a illustrare al committente, cui il STP è sottoposto per approvazione, quali ‘feature’ non verranno collaudate, in modo da evitare malintesi. E’ ovviamente buona norma indicare perchè tali ‘feature’ non verranno collaudate e quando esse verranno collaudate (presumibilmente nell’ambito di un altro STP).

Section 6 - Approach E’ la sezione più ‘corposa’ del STP, normalmente divisa in varie sottosezioni. Per ogni ‘feature’ o combinazione di ‘feature’ vengono specificate le attività, le tecniche e gli strumenti usati per il collaudo. In sostanza per ogni gruppo di ‘feature’ elencato in Sezione 4, viene definito in dettaglio il ‘test run’ da eseguire. Il livello di dettaglio deve essere sufficiente almeno per identificare con cura le attività di test da eseguire e per poterle pianificare dettagliatamente.

PROMETEO

Section 7 - Item Pass/Fail Criteria Specifica, per ogni ‘test item’ identificato in Sezione 3, i criteri per stabilire se il collaudo ha avuto esito positivo o meno. Se non esiste una documentazione separata di Specifica di dettaglio del collaudo, può essere necessario specificare in questa Sezione quali ‘input’ verranno applicati al sistema e quali sono gli ‘output’ attesi. In ogni caso deve essere chiaramente definito il criterio adottato per giudicare il risultato del collaudo (i.e., il test dell’item sarà positivo se alla fine della sessione di collaudo si saranno verificati meno di 3 ‘fault’ che non compromettono la funzionalità generale del sistema). In caso di eventuali ‘fault’ è necessario specificare i criteri di ricollaudo successivi (i.e., tutto il collaudo previsto dal STP o una sua parte).

PROMETEO

Section 8 - Suspension/Resumption Criteria Specifica i criteri di interruzione del collaudo e le attività da eseguire quando si riprende l’attività di collaudo. La sospensione può ovviamente essere normale (i.e. alla fine di una giornata di lavoro) o anomala (i.e., in caso di guasto hardware). Per le sospensioni normali la cosa migliore, se possibile, è indicare nel STP i punti di possibile sospensione del collaudo. In questo caso potrebbe essere automaticamente definito anche il criterio di ripresa del collaudo a seguito di una sospensione anomala (i.e. l’ultimo punto di sospensione normale raggiunto prima dell’insorgere dell’anomalia).

PROMETEO

Section 9 - Test Deliverables Questa Sezione elenca cosa deve essere consegnato al cliente alla fine del collaudo. Lo standard IEEE 829-1983, raccomanda il seguente elenco: Test Plan (STP) Test design specifications Test case specifications Test procedure specification Test item transmittal reports Test logs Test incident reports Test summary reports Test input and output data Test tools (i.e., stubs) Ovviamente questo elenco può non adattarsi a tutte le situazioni.

PROMETEO

Section 10 - Testing Tasks Identifica tutte le attività necessarie per preparare ed eseguire il collaudo. Identifica tutte le dipendenze fra attività e le specifiche competenze necessarie per eseguirle.

Section 11 - Environmental Needs Definisce come deve essere predisposto l’ambiente di collaudo (hardware, software, strumenti). Specifica gli eventuali strumenti di test che debbono essere sviluppati per eseguire il collaudo (i.e., software stub, simulatori, ecc.).

PROMETEO

Section 12 - Responsabilities Identifica i gruppi responsabili di gestire, progettare, preparare, eseguire, presenziare, controllare e risolvere problemi nella implementazione del STP. In particolare identifica i gruppi responsabili per la fornitura dei ‘test items’ (Sezione 3) e per la realizzazione dell’ambiente di collaudo (Sezione 11).

Section 13 - Staffing and Training Specifica le esigenze di personale di collaudo per livello di ‘skill’ (competenze e livello di esperienza professionale). Definisce come eseguire il training per fornire l’appropriato livello di ‘skill’. La valutazione deve essere eseguita per ogni attività di collaudo pianificata in Sezione 10.

PROMETEO

Section 14 - Schedule Include il Gantt delle attività di collaudo. Ovviamente deve essere appropriatamente coordinato col piano complessivo di progetto.

Section 15 - Risks and Contingencies Identifica i rischi associati alla esecuzione del piano (i.e., un ritardo nella consegna di ‘test items’) e definisce le tattiche di gestione (che comunque dovranno essere approvate dal project manager e dal commitente). Questa Sezione può essere la più importante del piano. Ovviamente è essenziale focalizzarsi solo sulle cose che potrebbero accadere con più alta probabilità e/o che potrebbero avere il più alto impatto sull’esecuzione del piano. Il punto di partenza per elaborare questa sezione può essere un riesame di tutti i ‘test items’ necessari (Sezione 3) e di tutte le esigenze relative all’ambiente di collaudo (Sezione 11).

PROMETEO

Section 16 - Approvals Include l’elenco di tutte le persone che debbono approvare il piano, lasciando lo spazio per la loro firma.

PROMETEO

IEEE 829-1998

PROMETEO

Lo standard IEEE 829-1983 è stato emendato nell’anno 1998. Non sono state introdotte sostanziali modifiche nei contenuti, tuttavia l’architettura descritta nella nuova release dello standard IEEE 829-1998 risulta leggermente modificata.

Section 1 – Identifier Identifica in modo univoco il test tramite un codice. Unitamente al codice identificativo (i.e. codice prodotto) sono riportati tutti gli identificativi di Versione/Revisione (i.e. V2.1a) nonché la Revision History (elenco di tutte le revisioni effettuate sul documento comprensivo di data ed autore della revisione e causa della revisione).

PROMETEO

Section 2 – References Contiene i riferimenti univoci a tutta la documentazione inerente al test plan (ad esempio: specifiche di design, documentazione su metodologie di test, guide di installazione di SW commerciale di supporto, report di anomalie riscontrate sul SW di supporto, documentazione relativa alla configurazione del SW, riferimenti al codice, etc). Section 3 – Introduction In questa sezione sono riportate tutte le informazioni di corredo ai test (i.e. scopo delle attività di test, enti coinvolti nei test, budget delle attività di test, breve sunto delle attività di test, descrizione della filosofia di test applicata, etc). Questa sezione contiene anche una indicazione di massima della documentazione che verrà prodotta al termine dell’esecuzione del test plan (Test Report).

PROMETEO

Section 4 - Test configurations Elenca gli oggetti (item) da sottoporre a test, la loro versione/revisione, i media impiegati per trasferirli alla struttura di collaudo. Fornisce i riferimenti alla documentazione tecnica di progetto, rilevante per il test da eseguire. Definisce cosa non deve essere sottoposto a collaudo (i.e., unità di acquisizione dati, ma non la connessione verso host system).

Section 5 - Product risk issues Identifica le aspettative essenziali e gli eventuali rischi connessi al test. Questa sezione deve dare un breve cenno alle aspettative (i.e. funzionalità, sicurezza, privacy) che si desidera raggiungere nel test ed evidenziare, ove possibile, gli impatti aziendali di possibili failure (i.e. feedback sulla progettazione, ritardi nelle linee di produzione, etc).

PROMETEO

Section 6 - Features to be tested Per ogni ‘test configuration item’ elencato in Sezione 4 identifica tutte le feature o le combinazioni di feature da sottoporre a test. Identifica le specifiche di progettazione di test per ogni feature o combinazione di feature. Unitamente alle feature da testare, occorre elencare tutte le feature escluse dal test. La scrittura di questa sezione è enormemente semplificata dalla definizione di una matrice di verifica nella fase di attività che prepara la stesura del STP. Nella matrice occorre spiegare, in caso di presenza di feature non testate, la ragione che ne impedisce il test (i.e., mancanza di specifiche, mancanza di componentistica)

Section 7 - Approach E’ la sezione più ‘corposa’ del STP, normalmente divisa in varie sottosezioni. Per ogni feature o combinazione di feature vengono specificate le attività, le tecniche e gli strumenti usati per il collaudo. In sostanza per ogni

PROMETEO

gruppo di feature elencato in Sezione 6, viene definito in dettaglio il ‘test run’ da eseguire. Il livello di dettaglio deve essere sufficiente almeno per identificare con cura le attività di test da eseguire e per poterle pianificare dettagliatamente.

Section 8 - Termination criteria and resumption requirements Identifica i seguenti punti: • Requisiti di Recovery dopo un test fallito

(devono essere specificati i requisiti necessari a definire una nuova condizione sicura di partenza dei test)

• Politica di Test Regression (modalità di ripetizione di test già eseguiti con esito positivo. Tal volta si rende necessario rieseguire alcuni test; tipicamente a seguito di failure su altri test, o per attività di retesting dovute all’introduzione di nuove feature)

• Criterio di determinazione del completamento dei singoli test e del test plan (indicazione di test eseguito, fine attività di test)

PROMETEO

• Criteri di sospensione di una porzione o dell’intero test plan (possono essere presenti sospensioni normali o sospensioni anomale)

• Criterio di determinazione dell’esito Positivo o Negativo del singolo test

Non è sempre possibile identificare tutti i criteri e le politiche in oggetto, in ogni caso deve essere sempre chiaramente definito il criterio adottato per giudicare il risultato del collaudo. In caso di eventuali ‘fault’ è necessario specificare i criteri necessari a ricollaudi successivi (i.e., tutto il collaudo previsto dal STP o una sua parte).

PROMETEO

Section 9 - Test deliverables Questa Sezione elenca cosa deve essere consegnato al cliente alla fine del collaudo. Lo standard IEEE 829-1998, raccomanda il seguente elenco: Test Plan (STP) Test design specifications Test case specifications Test procedure specification Test item transmittal reports Test logs Test incident reports Test summary reports Test input and output data Test tools & user manual (i.e., stubs) Ovviamente questo elenco può non adattarsi a tutte le situazioni.

PROMETEO

Section 10 - Testing tasks Identifica tutte le attività necessarie per preparare ed eseguire il collaudo. Identifica tutte le dipendenze fra attività e le specifiche competenze necessarie per eseguirle. Identifica le responsabilità associate ad ogni attività.

Section 11 - Environmental needs Definisce come deve essere predisposto l’ambiente di collaudo (hardware, software, network, strumenti). Specifica gli eventuali strumenti di test che debbono essere sviluppati per eseguire il collaudo (i.e., software stub, simulatori, ecc.).

PROMETEO

Section 12 - Staffing & training needs Specifica le esigenze di personale di collaudo per livello di ‘skill’ (competenze e livello di esperienza professionale). Definisce come eseguire il training per fornire l’appropriato livello di ‘skill’. La valutazione deve essere eseguita per ogni attività di collaudo pianificata in Sezione 10.

Section 13 - Summary of responsibilities Identifica i gruppi responsabili di gestire, progettare, preparare, eseguire, presenziare, controllare e risolvere problemi nella implementazione del STP. In particolare identifica i gruppi responsabili per la fornitura dei ‘test configuration items’ (Sezione 4) e per la realizzazione dell’ambiente di collaudo (Sezione 11).

PROMETEO

Section 14 – Schedule Contiene il Gantt delle attività di collaudo, identifica e specifica le principali attività da svolgere (key activities) e le principali scadenze tecniche/commerciali (milestones) relative agli item sotto test.

Section 15 - Planning risks & contingencies Identifica i rischi associati alla esecuzione del piano (i.e., un ritardo nella consegna di ‘test configuration items’) e definisce le tattiche di gestione (che comunque dovranno essere approvate dal project manager e dal commitente). Questa Sezione può essere la più importante del piano. Ovviamente è essenziale focalizzarsi solo sulle cose che potrebbero accadere con più alta probabilità e/o che potrebbero avere il più alto impatto sull’esecuzione del piano. Il punto di partenza per elaborare questa sezione può essere un riesame di tutti i ‘test

PROMETEO

configuration item’ necessari (Sezione 4) e di tutte le esigenze relative all’ambiente di collaudo (Sezione 11). Ove possibile vengono elencate alternative plausibili per risolvere situazioni di rischio. Section 16 - Approvals Include l’elenco di tutte le persone che debbono approvare il piano, lasciando lo spazio per la loro firma.

Section 17 – Glossary Elenca tutti i termini essenziali per la comprensione del documento.

PROMETEO

DOD-STD-2167A

PROMETEO

Section 1 - Scope

Definisce lo scopo del Test Plan. Va tenuto presente che lo standard DOD è orientato alla definizione di collaudi di tipo formale (i.e., acceptance test).

Paragraph 1.1 - Identification

Riporta il numero di identificazione, il nome e la sigla del sistema o del sottosistema da sottoporre a collaudo. Può includere un diagramma di struttura di alto livello del sistema.

Paragraph 1.2 - System Overview

Contiene una sintetica descrizione del sistema da collaudare.

PROMETEO

Paragraph 1.3 - Document Overview

Descrive la struttura del documento, evidenziando eventuali difformità rispetto allo standard DOD.

Paragraph 1.4 - Relationship to other plans Descrive le relazioni con le attività di test definite in altri piani di progetto (i.e., collaudi di tipo non formale).

Section 2 - Referenced Documents Indica tutta la documentazione di progetto rilevante allo scopo della implementazione del Test Plan.

PROMETEO

Section 3 - Software Test Environment

Questa sezione è dedicata alla descrizione di tutte le risorse (software, firmware e hardware) necessarie per la esecuzione del collaudo. Si tenga presente che le risorse software possono includere anche software di test o software commerciale necessario per il test (i.e, debugger, librerie di utilità).

Paragraph 3.1 - Software Items

Lista tutti i software item (sistemi operativi, compilatori, code auditor, dynamic path analyzer, test driver, preprocessori, generatori di dati di test e postprocessori) necessari per l’esecuzione del test e ne definisce lo scopo.

PROMETEO

Paragraph 3.2 - Hardware and firmware items Come per il paragrafo precedente ma riferito a oggetti hardware (i.e., computer, oscilloscopio, ecc.) o a firmware.

Paragraph 3.3 - Proprietary nature and government rights Definisce aspetti legati a fattori come licenze di software. Lo scopo è anche quello di definire come certi strumenti di collaudo possono essere approvvigionati da parte del committente, per la gestione post-progettuale del prodotto.

PROMETEO

Paragraph 3.4 - Installation, testing and control Definisce il piano per la installazione, il collaudo (i.e, uso di diagnostici hardware) e il controllo (i.e., controllo delle release di hardware e software) dell’ambiente di collaudo.

PROMETEO

Section 4 - Formal Qualification and Test Identification Questa sezione descrive in dettaglio tutti i collaudi da eseguire.

Paragraph 4.X - (CSCI name and project-unique identifier) Il Test Plan può includere il collaudo di più CSCI (Computer Software Configuration Item).

PROMETEO

Subparagraph 4.X.1 - General Test Requirements Definisce i requisiti generali del collaudo del CSCI (i.e., misure di dimensione e di tempi di risposta, requisiti di error recovery, ecc.).

Subparagraph 4.X.2 - Test Classes Definisce le categorie di test cui il CSCI deve essere sottoposto. Lo standard elenca le seguenti categorie: Stress (ambiente operativo non più conforme a quello delle specifiche di progetto), Timing, Erroneous input, Maximum Capacity (carico di elaborazione massimo tollerabile). Esso non cita un’altra categoria essenziale: il collaudo funzionale.

PROMETEO

Subparagraph 4.X.3 - Test Levels Indica i livelli a cui il collaudo va condotto: a livello CSCI, a livello di integrazione fra CSCI (controllo della soddisfazione dei requisiti delle interfacce esterne), a livello di integrazione col target hardware, a livello sistema.

Subparagraph 4.X.4 - Test Definitions Elenca tutti i collaudi da eseguire per il CSCI X.

PROMETEO

Subparagraph 4.X.4.Y - (Test name and project-unique identifier) Contiene la definizione del test Y da eseguire sul CSCI X. Oltre al nome e all’identificatore (un numero), deve essere definito quanto segue:

- obiettivo del test - requisiti particolari (i.e., attrezzaggi particolari) - test level: uno di quelli definiti in 4.X.3 - test class: una di quelle definite in 4.X.2 - metodo di qualificazione: ispezione, analisi (calcolo) o dimostrazione (esecuzione); in caso di collaudo simultaneo di più requisiti è meglio includere una matrice requisito-metodo - riferimenti alla documentazione di Software Requirement Specification per i requisiti da collaudare - come sopra ma riferito alla documentazione di Interface Requirements Specification - tipo di dati da registrare: risultato globale del test, misure di tempo di risposta, ecc. - assunzioni e vincoli che debbono essere tenuti in considerazione nella esecuzione del test.

PROMETEO

Subparagraph 4.X.5 - Test Schedule Contiene ovviamente il piano di collaudo per il CSCI X. Section 5 - Data Recording, Reduction and Analysis Questa sezione riporta tutti gli algoritmi necessari per valutare la correttezza del software. In sostanza indica come manipolare i dati raccolti durante il collaudo, in accordo a quanto specificato in 4.X.4.Y.

Section 6 - Notes Questa sezione può essere usata per riportare informazioni aggiuntive e complementari utili per la esecuzione del collaudo. Le informazioni contenute qui non vengono considerate vincolanti da un punto di vista contrattuale.

PROMETEO

Appendici Contengono informazioni aggiuntive come le note incluse in Section 6. Le differenze sono però due: a) i contenuti delle appendici sono considerati contrattualmente vincolanti, b) le appendici possono essere staccate dal corpo base del Test Plan e pubblicate/ trasmesse separatamente; per questo possono essere utilmente usate per includere informazioni considerate particolarmente critiche (i.e., in applicazioni militari).

PROMETEO

MIL-STD-498

PROMETEO

Lo standard MIL-STD-498, definito nell’anno 1994 dal Departement of Defense (USA) come sviluppo del precedente DOD-STD-2167A, si basa su documenti identificabili con l’acronimo DID (Data Item Description). Tali documenti descritti utilizzando sezioni e paragrafi, riassumono le specifiche da rispettare per sottostare allo standard medesimo. Analizzeremo ora la documentazione specifica per realizzare un test plan di progetto (Software Test Plan – DOD o STP-DID).

PROMETEO

Section 1 – Scope Definisce lo scopo del Test Plan. Va tenuto presente che lo standard MIL è orientato alla definizione di collaudi di tipo formale (i.e. acceptance test). Paragraph 1.1 – Identification Riporta il numero di identificazione, il nome e la sigla del sistema o del sottosistema e del softaware da sottoporre a collaudo. Paragraph 1.2 – System Overview Contiene una sintetica descrizione del sistema da collaudare. Identifica gli enti (Customer, Developer, Tester, …) coinvolti nel progetto. Paragraph 1.3 – Document Overview Descrive la struttura del documento, evidenziando eventuali difformità rispetto allo standard MIL.

PROMETEO

Paragraph 1.4 – Relationship to other plans Descrive le relazioni con le attività di test definite in altri piani di progetto (i.e. collaudi di tipo non formale). Section 2 – Referenced Documents Indica tutta la documentazione di progetto rilevante allo scopo dell’esecuzione del test plan. Ove questa documentazione non sia comunemente disponibile, ne indica le fonti d’approvvigionamento. Section 3 – Software Test Environment Questa sezione è dedicata alla descrizione di tutte le risorse (software, hardware, firmware, etc…) necessarie per l’esecuzione del collaudo. Si tenga presente che le risorse software possono includere anche software di test o software commerciale necessario al test (i.e. debugger, librerie di utilità).

PROMETEO

Paragraph 3.x – (Name of test site(s)) Identifica la sede ove avvengono le attività di test. Sono individuati tutti gli item (i.e. apparecchiature, software, personale, etc ) necessari al test plan per la specifica sede di test. Nel caso più sedi siano presenti (i.e. test remoti) più paragrafi di questo tipo saranno presenti. Paragraph 3.x.1 – Software Items Lista tutti i software item (sistemi operativi, compilatori, code auditor, database, dynamic path analyzer, test driver, preprocessori, generatori di dati di test e postprocessori) necessari per l’esecuzione del test e ne definisce lo scopo. Paragraph 3.x.2 – Hardware and firmware Items Come per il paragrafo precedente, ma riferito a oggetti hardware (i.e. computer, oscilloscopio, multimetri, etc…) o a firmware.

PROMETEO

Paragraph 3.x.3 – Other materials Come per il paragrafo precedente, ma riferito tutti i materiali di supporto (manuali, listati, tape, unità magnetiche, …). Ogni elemento presente in questo paragrafo deve essere identificato mediante un codice ed una tipologia esclusiva (formato del media, template del documento, etc). Paragraph 3.x.4 – Proprietary nature, acquirer’s right and licensing. Identifica la natura della proprietà (i.e. copyright) ed i diritti dell’acquirente (i.e. facoltà di distribuzione). In oltre definisce aspetti legati a fattori legali come licenze del software. Lo scopo è di definire come certi strumenti di collaudo possono essere approvvigionati da parte del committente per la gestione post-progettuale del prodotto.

PROMETEO

Paragraph 3.x.5 – Installation, testing and control Definisce il piano per l’installazione, il collaudo (i.e. uso di diagnostici hardware) ed il controllo (i.e. controllo delle release hardware e software) dell’ambiente di collaudo. Paragraph 3.x.6 – Partecipating organizations Identifica gli enti organizzativi partecipanti, il loro ruolo e responsabilità. Paragraph 3.x.7 – Personnel Identifica la tipologia di personale (skill, numero di elementi, rotazione e turni, …) necessaria all’esecuzione dei test. Se presenti, sono evidenziati gli skill essenziali per assicurare la continuità dei test prolungati.

PROMETEO

Paragraph 3.x.8 – Orientation Plan Descrive tutte le attività preliminari di addestramento specifico necessarie al personale prima di intraprendere l’attività di test. Se le attività di addestramento specifico sono numerose, occorre evidenziare un planing opportuno delle medesime. Paragraph 3.x.9 – Test to be performed Identifica i test da svolgere referenziando, ove opportuno la successiva sezione 4. I test elencati in un paragrafo 3.x, sono intesi relativi alla sola sede di test x.

PROMETEO

Section 4 – Test Identification Questa sezione descrive in dettaglio tutte le attività di test previste nel test plan da eseguire. Paragraph 4.1 – General information Questo paragrafo specifica informazioni generali applicabili alle attività di test. Paragraph 4.1.1 – Test levels Indica i livelli a cui il collaudo va condotto: livello CSCI (Computer Software Configuration Item), livello d’integrazione fra CSCI (controllo della soddisfazione dei requisiti delle intrefacce esterne), livello d’integrazione del target hardware e livello di sistema. Paragraph 4.1.2 – Test classes Identifica la tipologia delle attività di test (i.e. performance test, overload test, negative test). Sono previste casistiche di test negativi.

PROMETEO

Paragraph 4.1.3 – General test conditions Questo paragrafo elenca le condizioni applicabili alla totalità dei test e quelle applicabili a ciascun sottogruppo di test. Per ogni test occorre: � indicare un tempo approssimativo

d’esecuzione � dare un riferimento del peso relativo del

singolo test sul totale dei test da effettuare (i.e. percentuale di completamento dell’intero test plan)

� fornire indicazioni sulle attività di re-test e sui test di regressione.

Paragraph 4.1.4 – Test progression In caso di test cumulativi (i.e. test su sotto-unità e test sulla unità complessiva) o progressivi (i.e. test a catena) questo paragrafo identifica le corrette sequenze d’esecuzione dei singoli test.

PROMETEO

Paragraph 4.1.5 – Data recording, reduction and analysis Questo paragrafo riporta tutti gli algoritmi necessari per valutare la correttezza del software. In sostanza indica come manipolare i dati “grezzi” raccolti durante i test. Paragraph 4.2 – Planned tests Questo paragrafo raggruppa la totalità delle attività di test da svolgere. Paragraph 4.2.x – (Item(s) to be tested) Questi paragrafi identificano ogni CSCI, sottosistema, sistema o entità tramite una sigla univoca all’interno del progetto definendo tutti i test alla quale sono sottoposti durante il test plan. I test in questo paragrafo sono da intendersi come insiemi di test elementari (test case); non è scopo di questo documento descrivere ogni singolo test elementare (i.e. Nel caso di test su una calcolatrice, nel presente documento troveremo solo la definizione del test sulle operazioni aritmetiche di base, non 4 test dettagliati sulle singole operazioni +,-,*,/.).

PROMETEO

Paragraph 4.2.x.y – (Project-unique identifier of a test) Contiene la definizione del test y da eseguire sull’item (CSCI, sottosistema, sistema…) x. Oltre all’identificativo deve essere definito quanto segue: � Obiettivo del test � Test level: uno di quelli definiti in 4.1.1 � Test class: una di quelle definite in 4.1.2 � Metodo di qualificazione: ispezione, analisi

(calcolo) o dimostrazione (esecuzione); in caso di collaudo simultaneo di più requisiti è meglio includere una matrice requisito-metodo

� Riferimenti ai requisiti del CSCI da validare � Riferimenti alla documentazione di Software

Requirement Specification per i requisiti da collaudare

� Requisiti particolari (i.e. strumentazione particolare)

� Tipologia di dati da registrare: risultato globale del test, misure di tempo di risposta, etc

� Metodologia di registrazione dei dati (i.e. annotazioni, plot, …)

PROMETEO

� Assunzioni e vincoli che debbono essere tenuti in considerazione nell’esecuzione del test

� Considerazioni sull’incolumità, sulla sicurezza e sulla privacy associate al test

Section 5 – Test schedules Questa sezione contiene il piano di collaudo (tutti i test) cosi raggruppato: � Descrizione delle sedi di test e delle sessioni

di test � Schedule delle attività per ogni sede di test

(durata, attività, principali requisiti testati, etc)

PROMETEO

Section 6 – Requirements traceability Questa sezione contiene: � Descrizione della copertura d’ogni test sui

requisiti dei CSCI e sui requisiti applicabili presenti nel Software Requirements Specifications (eventualmente richiamando quanto descritto nei vari paragrafi 4.2.x.y)

� Tracciabilità di ogni requisito CSCI coperto dal test plan (si noti che alcuni requisiti specificati potrebbero essere lasciati intenzionalmente scoperti dal test plan, di qui la necessità di evidenziare l’effettiva copertura; tale nota vale anche per i punti successivi)

� Tracciabilità di ogni requisito applicabile descritto nel Software Requirements Specifications coperto dal test plan

� Tracciabilità di ogni requisito applicabile descritto nel Interface Requirements Specifications coperto dal test plan

� Tracciabilità di ogni requisito applicabile descritto nel System/Subsystem Specification coperto dal test plan

PROMETEO

Lo standard non specifica in modo diretto il mezzo da utilizzare per rappresentare la tracciabilità dei requisiti. Una sperimentata metodologia di lavoro risulta quella di definire una o più matrici “requisiti – test”, eventualmente focalizzate su specifiche aree funzionali del test plan (i.e. funzioni di acquisizione, funzioni di conversione, funzioni di archiviazione, etc). Ad esempio una possibile matrice, senza nessuna validità di standard: Test_D1 Test_ID2 Test_ID3 Acquisizione Si No In parte Conversione In parte Si In parte Archiviazione No No Si

Tramite tali matrici è possibile mappare l’effettiva copertura dei requisiti ed identificare agevolmente il test da eseguire per un dato requisito.

PROMETEO

Section 7 – Notes Questa sezione può essere usata per riportare informazioni aggiuntive e complementari utili all’esecuzione del collaudo (i.e. acronimi, glossario, etc). Le informazioni contenute qui non sono considerate vincolanti da un punto di vista contrattuale. Section 8 – Appendixes Contengono informazioni aggiuntive come nel caso della sezione 7. Le differenze sono però due: � i contenuti delle appendici sono applicabili e

quindi considerati contrattualmente vincolanti � le appendici possono essere staccate dal corpo

base del Test Plan e pubblicate/trasmesse separatamente. Per questo possono essere utilmente usate per includere informazioni considerate particolarmente critiche (i.e. in applicazioni militari)

PROMETEO

NOTE: Sempre nel medesimo standard sono specificati ulteriori documenti validi nelle procedure di test: � documento per la preparazione dei singoli

test, per la realizzazione di test case e procedure per la validazione dei singoli elementi software (CSCI, sottositemi, etc). Il DID di riferimento in questo caso si identifica con SOFTWARE TEST DESCRIPTION – DID o STD- DID.

� documento per l’archiviazione delle operazioni svolte e dei risultati ottenuti durante l’esecuzione dei singoli test (test report). Il DID di riferimento in questo caso si identifica con SOFTWARE TEST REPORT o STR-DID.

PROMETEO

ESA PSS-05-0

PROMETEO

STP, Part 1 Sviluppato nella fase SR, definisce l’elenco degli acceptance test

STP, Part 2 Sviluppato nella fase AD, include il progetto di ogni test e la specifica degli archivi dati e del software di test necessari al collaudo

STP, Part 3 Sviluppato nella fase DD, definisce le procedure di esecuzione dei test.

PROMETEO

Struttura tipica del STP 1. Scopo del Test Plan (descrizione dell’approccio e dei principi su cui basare l’acceptance test) 2. STP, Part 1. Lista dei test. 3. STP, Part 2. Progetto dei test e archivi dati necessari 3.1 Definizione dell’hardware e dell’ambiente di esecuzione del collaudo 3.2 Archivi dati di collaudo 4. STP, Part3. Lista dei test e relative procedure 5. Riferimenti alla documentazione rilevante

PROMETEO

ECCS STD

PROMETEO

Lo standard ECSS STD si deve considerare una revisione dello standard ESA-PSS-05. Al momento esistono solo draft parziali del nuovo standard. Si prevedono ancora alcuni anni prima di poter usufruire della documentazione definita del nuovo stantard.

PROMETEO

Conclusioni Lo standard ESA è un po' povero, però può essere utile per progetti con budget di collaudo limitato. Lo standard IEEE (in entrambe le release) è il più organico, ma richiede la realizzazione di un numero notevole di documenti (l’STP è un documento puramente gestionale), lo standard MIL (DOD) presenta invece una complessità intermedia.

PROMETEO

Collaudo di regressione Al momento della Qualità pura soggetto e oggetto sono identici. Robert Pirsing

PROMETEO

Quando si esegue una modifica alla

Software Configuration (correttiva,

perfettiva o adattativa) devono essere

eseguiti collaudi che mirano a verificare che

non siano insorti ‘effetti collaterali’ inattesi.

Questo tipo di collaudi sono chiamati

regression test.

PROMETEO

Gli ‘effetti collaterali’ su parti di codice non modificato possono derivare da: 1) connessioni sui dati,

2) interdipendenze temporali,

3) interdipendenze fra requisiti di sistema (cambiare R1 porta a non soddisfare R2)

PROMETEO

In teoria, dopo ogni modifica, si dovrebbe quindi rieseguire per intero il testing del prodotto software. Questo è però molto oneroso e quindi si deve ricorrere ad approcci diversi.

PROMETEO

Approcci al regression testing

1) Identificazione di tutte le interconnessioni ‘potenziali’ e ricollaudo, oltre che del modulo modificato, di tutti i moduli influenzabili.

2) Esecuzione del regression testing

mediante il lancio di un ‘caso prova’ che copra il sistema in modo significativo.

3) Esecuzione automatica del regression

testing. 4) Procedure di SCM che accorpano le

modifiche nella emissione di una nuova ‘release’, sottoposta ad un collaudo severo.

5) Combinazione delle tecniche precedenti.

PROMETEO

La non corretta gestione delle modifiche e del regression testing portano a fenomeni di ‘entropizzazione’ del software.

PROMETEO

Andamento dei fault

MODIFICHE

CURVA IDEAL E

ENTROPIZZAZIONE

HARDWARE

SOFTWARE

TEMPO

TEMPO

MORTALITA’ INFANTILE

USURA

(R. S. Pressman, 1987)

PROMETEO

L’incremento di fault rate conseguente a modifiche dipende da:

1) qualità dell’architettura (struttura intellettuale) del sistema,

2) conoscenza del sistema da parte del

manutentore software, 3) coerenza delle modifiche con la

struttura intellettuale del sistema, 4) qualità del regression testing.

PROMETEO

Strumenti per il collaudo del software Tutto deve essere fatto il più semplice possibile, ma non più semplice. Attribuito ad A. Einstein

PROMETEO

Poichè l’attività di collaudo è estremamente costosa, è necessario eseguirla con gli strumenti opportuni. Tutti gli strumenti necessari debbono essere identificati nel STP.

PROMETEO

Strumenti per l’analisi e la simulazione dell’I/O

• Multimetri, oscilloscopi

• Logic state analyzer

• Monitor di linee seriali

• Analizzatori di protocollo

• Generatori e simulatori di segnali

• Generatori di protocolli

PROMETEO

Strumenti orientati al codice

• Analizzatori statici di codice

• Analizzatori di complessità del codice

• Debugger simbolici

PROMETEO

Strumenti orientati al sistema

• System level debugger

• Performance profiler

• Gestori di versioni e generatori di • software release

• Generatori di dati di test

• Analizzatori di interdipendenze per • regression testing

• Logger di dati di test

PROMETEO

Strumenti orientati all’applicazione

• Software stub

• Simulatori completi per il test automatico

• Tracciatori

Normalmente vengono sviluppati ‘ad hoc’ per il collaudo di un prodotto software e vanno posti sotto SCM.

PROMETEO

Strumentazione del codice

Un codice ‘strumentato’ include parti espressamente dedicate al supporto della attività di collaudo, ad esempio:

1) istruzioni di stampa,

2) istruzioni di asserzione,

3) variabili per la memorizzazione di risultati intermedi.

Va tenuto presente che il codice di ‘strumentazione’ non può essere rimosso a fine collaudo, in quanto la rimozione altera l’immagine eseguibile e quindi il comportamento (specie quello dinamico) del prodotto.

PROMETEO

Strumenti per la gestione della documentazione

• Gestori di documentazione per la

specificazione e il progetto dei test. • Generatori di test report • Gestori di dati su modifiche e di ‘history’

del codice.

PROMETEO

Strumenti di gestione di dati metrici

Si tratta essenzialmente di gestori di basi di dati metrici legati alla qualità del software: - numero di fault,

- ripartizione per classe,

- fault rate trending,

- tempo medio di correzione, . . .

PROMETEO

Automazione delle

attivita’ di collaudo

Io ho sei onesti servitori (essi mi hanno insegnato tutto quello che so). I loro nomi sono Cosa e Perche’ e Quando e Come e Dove e Chi. Rudyard Kipling

PROMETEO

Gestori di dati di collaudo

Esecutori automatici

Generatori di dati di prova

Generatori di casi di prova

Automazione del collaudo

PROMETEO

Gestori di dati di collaudo - data base di casi prova - data base di esiti del collaudo - generatori di ‘test report’ - generatori di statistiche su campagne di collaudo.

PROMETEO

Generatori di dati di prova Possono essere di tipo ‘custom’ (realizzati per uno specifico progetto o prodotto) o di tipo ‘general purpose’ (operanti su descrizioni della struttura dati in ingresso).

misure

Generatore file

Generatore segnali

Sistema sotto

collaudo

PROMETEO

Generatori di casi di prova Si tratta di sistemi capaci di generare un elenco di casi di prova a partire da una dettagliata descrizione formale del sistema sotto collaudo.

PROMETEO

Esecutori automatici Si tratta normalmente di monitor di lancio capaci di mandare in esecuzione automatica i casi di prova. Sono normalmente ‘custom’, ma possono basarsi su prodotti ‘general purpose’ (i.e., generatori di applicazioni di controllo).

PROMETEO

Esempio 1 Monitor di lancio per ‘unit test’.

Monitor di lancio

Sw Stub

Software unit

stimoli reazioni

Sw Stub

PROMETEO

Esempio 2

‘Regression test’ da I/O archiviato. Applico l’input da ‘file A’ e controllo la congruenza fra output ridiretti su ‘file B e C’ e ‘file B e C’ campioni.

Sistema

out video (file B)

Input (file A)

out printer (file C)

PROMETEO

Esempio 3 ‘Regression test’ automatico. Monitor di lancio e analizzatore esiti

Sistema RT

Test report

Test description

I

O

PROMETEO

Ovviamente devo avere delle descrizioni di correlazioni fra casi di prova, in modo da stabilire quali casi si possono eseguire in presenza di esiti anomali.

tc1

tc2

tc3

tc4

tc5

PROMETEO

Manutenzione e

Software Configuration Management Tutto si deve fare con equilibrio, tenendo conto dei deboli. La Regola di S. Benedetto

PROMETEO

L’essenza del problema di SCM

Frequentemente i SW engineer considerano il

software da loro sviluppato come un loro effetto

personale (il famigerato SW mio) e non come

un componente da inserire e gestire nell’ambito

di un sistema complessivo.

PROMETEO

L’essenza del problema di SCM

Alcuni effetti di questo tipo di attitudine sono i seguenti:

I l codice è scarsamente leggibile.

Conseguentemente la documentazione è scarsa e poco aggiornata.

Conseguentemente un SW engineer può difficilmente modificare il SW scritto da altri.

A lla domanda “questo sistema funziona?” si risponde spesso “il mio SW si”.

A lla domanda “è stato eseguito il back-up dei sorgenti?” si risponde spesso “per il mio SW si”.

Normalmente il materiale di progetto è malamente classificato e mantenuto in un disordine estremo.

PROMETEO

Definizioni di SCM

PROGRAMMI (SORGENTI ED ESEGUIBILI)

PROCEDURE DI COMANDO

DOCUMENTI

AMBIENTI DI COLLAUDO

STRUTTURE DATI

REPORT (i.e. ,TEST REPORT)

SOFTWARE ENGINEERING

SOFTWARE CONFIGURATION

SOFTWARE CONFIGURATION SOFTWARE CONFIGURATION ITEM

PROMETEO

Definizioni di SCM Il SCM ha come area di intervento primaria il

controllo dei “change”. Esso si occupa anche

della identificazione dei SCI e delle varie

versioni del software, dell’audit della

configurazione software per assicurare che sia

stata sviluppata in modo appropriato, e del

reporting di tutte le modifiche eseguite.

PROMETEO

Le attività del SCM

• Identificazione dei SCI • Controllo dei “change” • Audit della configurazione (*) • Report sullo stato della

configurazione

(*) controllo del rispetto degli standard di SCM

PROMETEO

Lo standard ESA PSS-05-0

Software Configuration Management

AD/R

SR/R

SR

UR/R

AD

UR

SCMP

PROMETEO

Lo standard ESA PSS-05-0

Il flusso dei configuration item (CI)

LIBRERIA DI INTEGRAZ.

LIBRERIA DI SVILUPPO

DA VERIFICARE VERIFICATE DA CORREGGERE COLLAUDATI

MASTER LIBRARY

MODULI COLLAUDATI

VERSIONI VERIFICATE

RELEASE ESTERNE

PROMETEO

Lo standarad ESA PSS-05-0

Procedura di gestione dei change

1. Generazione del Software Problem Report (SPR).

2. Il Software Review Board passa il SPR

al tecnico competente per l’analisi. 3. Il Software Review Board esamina le

conclusioni dell’analisi e decide se autorizzare uno o più change.

4. Ogni change è specificata da un

Software Change Request (SCR). 5. Ogni change eseguita va documentata

con un Software Modification Report (SMR), a cui fa seguito l’aggiornamento della Master Library.

PROMETEO

Struttura del Software Configuration Management Plan

∗ Introduzione

- Scopo - Area di intervento - Definizioni e Acronimi - Riferimenti

∗ Gestione

- Organizzazione - Responsabilità di SCM - Controllo delle interfaccie (HW/SW) - Realizzazione del SCMP - Politiche, direttive e procedure

* Attività di SCM

- Identificazione della configurazione - Controllo della configurazione - Accounting dello stato della configurazione - Audit e review

∗ Tools, tecniche e metodologie

∗ Controllo dei fornitori

∗ Raccolta e classificazione delle registrazioni (gestione della documentazione di SCM) (IEEE STD 828/1983)

PROMETEO

Quando mettere gli SCI sotto controllo di configurazione può dipendere dalle esigenze specifiche di ogni singolo progetto. E’ tuttavia evidente che tutti gli SCI debbono essere sotto controllo di configurazione alla data di rilascio del prodotto al cliente, in quanto l’efficacia e l’efficienza delle attività di manutenzione sono fortemente influenzate dalla qualità del SCM.

PROMETEO

L’attività di manutenzione deve essere fortemente finalizzata a non ‘entropizzare’ il prodotto software. D’altra parte ciò è fortemente influenzato dai seguenti fattori:

a) qualità dell’architettura del sistema,

b) conoscenza del sistema da parte del manutentore software,

c) coerenza delle modifiche con la struttura intellettuale del sistema,

d) qualità del regression testing

e) efficace raccolta di dati metrici sulla qualità e di dati sui change eseguiti (SCM),

f) norme per la esecuzione dei change (SCM),

g) norme per la gestione delle release (SCM),

h) norme per la catalogazione e gestione dei SCI (SCM).

PROMETEO

Raccolta e gestione di dati metrici

sulla qualità del software Conta cosa può essere contato, misura cosa può essere misurato, e cosa non è misurabile rendilo misurabile. Galileo Galilei

PROMETEO

Modello USAF per la previsione della affidabilità del software

PROMETEO

F = A x D x S1 x S2

F : fault density per numero di LOC A : base fault density da precedenti esperienze (i. e., 0.0018 per applicazioni di controllo processi dell’USAF) D : moltiplicatore per ambiente di sviluppo S1 : moltiplicatore per metodologia

di sviluppo S2 : moltiplicatore per tecniche di codifica

PROMETEO

D : moltiplicatore per ambiente di sviluppo

viene usata una classificazione di Boehm

Ambiente D Note

Organic

Semi-detached

Embedded

.76

1

1.3

Piccoli gruppi che conoscono l’applicazione

Intermedio

SW contracted con vincoli stringenti

PROMETEO

S1 : moltiplicatore per metodologie di sviluppo S1 = SA x ST x SQ

PROMETEO

.9 < SA < 1.1 Sulla base del rigore di definizione input e di preprocessing e correzione automatica di errori sull’input Più del 90% dei requirement

ST di progetto sono esplicita- mente coperti dal SW design Discrepanze fra requirement SQ e design su numero di requirement inferiore al 50%

1

1.1

1

1.1

PROMETEO

S2 : moltiplicatore per tecniche di codifica S2 = SL x SM x SX x SR

PROMETEO

SL = SM = NM = u + w + x ; numero moduli u numero moduli con < 200 LOC w numero moduli con 200-3000 LOC x numero moduli con > 3000 LOC

+ 1.4

ALOC

SLOC

HLOC

SLOC H : high-level

S : source A : assembler

0.9u + w + 2x

NM

PROMETEO

SX = NM = a + b + c ; numero moduli a numero moduli con complessità ciclomatica > 20 b numero moduli con 7 < C.C. < 20 c numero moduli con C.C. < 7 SR

1.4a + b + .8c

NM

1.5

.75

1

più del 50% di moduli fuori coding standard

meno del 25% di moduli fuori standard

intermedio

PROMETEO

Conclusioni da modello USAF

I fattori esaminati sembrano avere un impatto rilevante. Ad esempio, su un’ applicazione di controllo processo di 50 KLOC i due casi estremi risultano i seguenti:

OTTIMO : 33 fault PESSIMO : 915 fault

PROMETEO

Ovviamente il modello USAF non dovrebbe

essere utilizzato ‘as is’, ma andrebbe

ritarato statisticamente sullo specifico

‘software lab’ cui si vuole applicarlo. Da

qui l’importanza del rilievo sistematico di

dati metrici.

PROMETEO

In ogni caso il modello USAF può fornire una indicazione qualitativa dell’impatto sulla ‘fault density’ dei vari fattori esaminati 1. Ambiente di sviluppo fino a +71% 2. Metodologie di sviluppo 2.1 Controllo input fino a +22% 2.2 Copertura requirement fino a +10% 2.3 Discrepanze requirement fino a +10% 3. Tecniche di codifica 3.1 Linguaggi h-l fino a +40% 3.2 Dimensione moduli fino a +122% 3.3 Complessità moduli fino a +75% 3.4 Standard di codifica fino a +100%

PROMETEO

Alcune esperienze HP

PROMETEO

Esempio 1 Rilievo dell’andamento mensile dei seguenti fattori:

- numero di difetti segnalati ma non diagnosticati - tempo medio di diagnosi - numero di difetti seri non risolti - tempo medio di ‘fix’ di un difetto serio ripartito per divisione della società.

PROMETEO

Il problema più complesso è la

interpretazione dei dati raccolti.

PROMETEO

Ad esempio in HP il numero di difetti seri non risolti è risultato sempre crescente nel tempo, ma ciò è dovuto al fatto che il volume dell’attività software è cresciuto più rapidamente dell’incremento di qualità del processo di produzione. Esigenza di normalizzazione dei dati.

PROMETEO

Un ulteriore esempio è il seguente: un

buon prodotto software installato in

molti siti può avere un tasso di difetti

segnalati più alto di un prodotto meno

buono ma installato in pochi siti.

PROMETEO

Un ulteriore fattore da considerare è

che le metriche di difetti sono molto

influenzate dalla classificazione dei

difetti e dalle modalità adottate per la

loro registrazione.

Inoltre per avere dati sufficienti è

necessaria una raccolta di almeno 3

anni.

PROMETEO

Classificazione degli errori Priorità 1 : errore che impedisce l’ottenimento di una funzione essenziale Priorità 2 : errore che influenza negativamente l’ottenimento di una funzione essenziale e per il quale non esistono soluzioni alternative Priorità 3 : errore che influenza negativamente l’ottenimento di una funzione essenziale ma per il quale esiste una ragionevole soluzione alternativa Priorità 4 : errore che crea solo un disturbo all’operatore Priorità 5 : altri errori. DOD - STD - 1679A

PROMETEO

Esempio 2

- Raccolta di dati di ‘fault’ classificati per categorie - Analisi di Pareto per identificare la/le categoria/e di maggior impatto - Analisi delle cause per migliorare il processo.

PROMETEO

Esempio 3

Una divisione HP aveva sviluppato un modello sul tempo necessario, in ore di collaudo, per rilevare e correggere gli errori. Sulla base di questo modello erano in grado di tracciare una previsione di ‘defect rate’ per una campagna di collaudo.

Difetti su 1000 ore di collaudo

WKn WK1 WK2 tempo

PROMETEO

In questo modo, fissando una condizione di ‘stop’ (i.e., 50 difetti su 1000 ore, ovvero 20 ore di collaudo senza difetti), era possibile determinare la durata prevista per la campagna di collaudo.

50

Difetti su 1000 ore di collaudo

WK10 tempo

PROMETEO

Ovviamente la campagna di collaudo era interrotta sulla base del ‘defect rate’ effettivo e non sulla base di quello previsto.

50

tempo

Difetti su 1000 ore di collaudo

WK12

PROMETEO

La scelta della condizione di arresto della campagna di collaudo è basata su considerazioni di questo tipo: Costo orario di collaudo x 20 > Costo di ‘fix’ post-release

PROMETEO

Preventivazione, pianificazione,

organizzazione e gestione delle attivita’ di collaudo

e manutenzione

E debbasi considerare, come non e’ cosa piu’ difficile a trattare, ne’ piu’ dubia a riuscire, ne’ piu’ pericolosa a maneggiare, che farsi capo ad introdurre nuovi ordini. Niccolo’ Machiavelli

PROMETEO

Preventivazione Il costo di collaudo normalmente e’ pari al 40% del costo di sviluppo. Un prodotto con alta esigenza di affidabilita’ puo’ pero’ avere costi di collaudo superiori. Il collaudo pero’ intercetta normalmente il 70% degli errori presenti, l’ispezione puo’ rimuoverne l’80-90% prima del collaudo, un buon processo invece previene gli errori.

PROMETEO

Preventivazione Il costo di manutenzione, nel ciclo di vita del prodotto, e’ normalmente molto piu’ alto del costo di sviluppo.

PROMETEO

Pianificazione L’attivita’ di collaudo va’ opportunamente pianificata mediante un SQAP e uno o piu’ STP correlati fra loro e con i piani delle attivita’ di sviluppo.

PROMETEO

Pianificazione E’ necessario eseguire un rilievo sistematico di metriche su ‘fault’ e attivita’ di manutenzione, per dimensionare correttamente, nelle varie fasi del ciclo di vita, le risorse di manutenzione.

PROMETEO

Pianificazione e Gestione I rilievi metrici costituiscono la base per le decisioni sui prodotti software, che debbono essere gestiti come cespiti patrimoniali.

analisi

mantengo

re-ingegnerizzo

muovo su altre piattaforme

sostituisco

dati metrici

PROMETEO

Organizzazione Gli assertori del TQM sono assolutamente contrari all’esistenza di gruppi di collaudo separati dai gruppi di progetto. I difetti vanno rimossi ‘in process’. Ogni sw engineer deve essere responsabile della qualita’ del suo prodotto, il management deve essere responsabile del ‘process improvement’. Si stima infatti che l’85% dei difetti siano derivanti dalla bassa qualita’ dei processi di produzione attuali.

PROMETEO

Organizzazione Una posizione piu’ consona allo stato corrente dei processi di produzione, puo’ essere la seguente:

a) lo stadio finale di ‘formal testing’ e’ eseguito da una unita’ organizzativa separata,

b) la maggioranza delle attivita’ di

collaudo sono demandate al gruppo di sviluppo, ma con ‘accounting’ delle ore lavorative su ‘budget’ separato e rigorosa documentazione dell’attivita’ di collaudo eseguita.

PROMETEO

Organizzazione E’ di vitale importanza dimensionare correttamente lo ‘staff’ di manutenzione, selezionando con cura le persone sulla base delle competenze richieste e fornendo un adeguato livello di ‘training’.

PROMETEO

Organizzazione L’esecuzione della manutenzione da parte dei gruppi di R & D, priva rapidamente l’azienda di una organizzazione di R & D.

2º

livello

1º

livello

campo

R & D Manutenzione

PROMETEO

Gestione Responsabilita’ gestionali, preventivi, consuntivi dovrebbero inquadrare il problema esaminando l’intero ciclo di vita del prodotto e non solo la fase di sviluppo.