Controllo della qualità

Sommario

Nelle righe di questo capitolo potete trovare una discussione sugli aspetti legati alla qualità sia di prodotto sia di processo, un nutrito compendio di informazioni riguardante il testing e l’introduzione del concetto di ispezione del codice; il capitolo si conclude con una paragrafo che verte sulla questione delle misure, dalla raccolta all’interpretazione.

Aspetti generali

La qualità di un prodotto software deve soddisfare un insieme di caratteristiche:

Specifiche funzionali
Essere estendibile
Essere facile da usare
Fare un uso efficiente delle risorse hardware
Esigenze del cliente

Qualità di prodotto e processo

Come fare a soddisfare questi requisiti e quindi ottenere qualità in un prodotto software? Per ottenere la qualità in un prodotto esistono due approcci complementari:

Definire e utilizzare un processo di qualità al fine di produrre prodotti di qualità
Definire ed eseguire un insieme di attività di controllo per assicurarsi (ed eventualmente migliorare) la qualità del singolo prodotto.

Se un processo è male organizzato e tecnicamente carente difficilmente genererà prodotti di qualità. Un processo è male organizzato se si verificano uno o più dei seguenti casi:

Specifiche non scritte
Progettazione inesistente
Pianificazione carente
Configurazioni e versioni non gestite

Il tutto porta ad avere prodotti di bassa qualità. Migliorando la qualità dei processi produttivi si genera una migliore qualità statistica dei prodotti. Ciò non assicura nulla però sulla qualità di uno specifico prodotto. Nella realtà si applicano tecniche per ottenere prodotti e processi di qualità. Il tutto funziona come un sistema retroazionato.

Partendo da obiettivi di qualità prefissati si effetuano azioni sul prodotto software e se ne misurano i risultati. Il processo di controllo qualità viene ripetuto ciclicamente fino a che non viene raggiunto un livello accertato di qualità. La fase di controllo della qualità può essere interrotta a causa di uno dei seguenti motivi:

Malfunzionamento, cioè funzionamento non corretto, cioè non corrispondente alle specifiche, di un programma. E’ legato al comportamento di un programma, non alla sua struttura statica. Il malfunzionamento è dato da un difetto.
Difetto, anomalia, bug, fault, il difetto è la causa di un malfunzionamento e si realizza in un componente non corretto. Riguarda la struttura statica. Se è percorso durante l’esecuzione di un programma genera un malfunzionamento. Questo implica che un difetto, se non percorso, rimane nascosto nel programma che, apparentemente, è corretto e funziona. Un malfunzionamento può essere generato da più difetti e più difetti possono avere un effetto complessivo nullo sul sistema.
Errore, riguarda una fase del processo utilizzato e non del prodotto. Un errore è la causa della generazione di un difetto. E’ dato da un errore d’analisi, d’interpretazione delle specifiche, di progettazione, di programmazione, di battitura, ecc. Riassumendo, si ha un errore che genera un difetto. Alla sua attivazione si ottiene un malfunzionamento. (Vedere anche la pagina Testing nella sezione Informatica 3.)
Verifica, si deve controllare che si stia costruendo il prodotto nel modo giusto.
Validazione, si deve controllare che si sta realizzando il prodotto corretto, quello cioè che si aspetta il cliente.

Modelli di qualità

I modelli di qualità sono uno schema di riferimento per definire la qualità di un prodotto. La normativa di riferimento è la ISO9126 (Software Product Quality, per la definizione della qualità del prodotto).

Funzionalità

Insieme di attributi correlati all’esistenza di un insieme di funzioni (che soddisfano i requisiti) e delle loro specifiche proprietà. Questi attributi sono:

Adeguatezza, presenza e appropriatezza di un set di funzioni:
Accuratezza, fornire risultati (o effetti) giusti o accettabili;
Interoperabilità, capacità di interagire con altri sistemi;
Security, capacità di prevenire accessi non autorizzati al sistema;
Conformità, rende il software conforme a norme, leggi che gli aspetti funzionali devono soddisfare.

Affidabilità

Insieme di attributi correlati con la capacità del software di mantenere un certo livello di prestazioni in determinate condizioni e per un certo periodo di tempo. Questi attributi sono:

Maturità, frequenza con cui si manifestano i difetti.
Tolleranza ai difetti, capacità di mantenere un certo livello di prestazioni anche in presenza di difetti del software.
Recuperabilità, capacità (intesa come sforzo e tempo) di ristabilire il livello richiesto di prestazioni e i dati persi dopo un malfunzionamento.
Conformità, rende il prodotto conforme alle norme per gli aspetti d’affidabilità.

Usabilità

Insieme di attributi correlati alla facilità d’uso del prodotto. Dipende dal contesto e dalle persone che lo devono usare. Gli attributi sono:

Comprensibilità, sforzo richiesto all’utente per comprendere la logica realizzata dal software.
Apprendibilità, sforzo richiesto all’utente per capire come si utilizza il software.
Operatività, sforzo richiesto all’utente per l’operatività del software.
Piacevolezza, qualità estetica dell’interfaccia del software.
Conformità, rende il software conforme alle norme degli aspetti d’usabilità.

Efficienza

Insieme di attributi correlati al livello di prestazioni del software e la quantità di risorse usate, in determinate condizioni. Gli attributi sono:

Prestazioni temporali, tempi di risposta e throughtput nell’esecuzione delle funzioni offerte dal software
Utilizzo di risorse, quantità di risorse e tempo utilizzati per realizzare le funzioni offerte dal software
Conformità, rende il software conforme alle norme degli aspetti di efficienza

Manutenibilità

Insieme di attributi correlati allo sforzo per effettuare certe modifiche. Gli attributi sono:

Analizzabilità, sforzo necessario per identificare le cause dei malfunzionamenti
Modificabilità, sforzo necessario per modificare il software, sia per rimuovere difetti, sia per modificare delle caratteristiche
Stabilità, rischi di effetti inaspettati a seguito di modifiche
Testabilità, sforzo necessario per validare il software
Conformità, rende conforme il software alle norme di modificabilità

Portabilità

Insieme di attributi correlati alla facilità di spostare un prodotto da un ambiente ad un altro. Gli attributi sono:

Adattabilità, capacità di adattarsi ad ambienti diversi rispetto a quelli in cui è stato concepito
Installabilità, sforzo necessario per installare un software in un ambiente
Coesistenza, capacità di coesistere con altri software in ambienti comuni, condividendo le risorse
Sostituibilità, sforzo necessario per usare il software al posto di un altro nello stesso ambiente
Conformità, rende il software conforme alle norme di portabilità

Tecniche di valutazione della qualità del prodotto

Per valutare i modelli di qualità e quindi i parametri che concorrono alla valutazione della qualità del prodotto esistono diverse tecniche tra cui il testing, le ispezioni, le misure.

Testing, il testing si esegue con delle verifiche basate sull’esecuzione del prodotto. Si confronta il risultato di prove effettuate sul programma con il documento di specifica e si verifica se il risultato corrisponde con quanto previsto.
Ispezioni, le ispezioni sono delle verifiche statiche dei documenti e del codice effettuate allo scopo di identificare problemi. Non richiedono l’esecuzione del codice e quindi possono essere effettuate prima della fase di codifica. Possono usare anche strumenti automatici.
Misure, si effettuano delle misure (qualitative o quantitative) di attributi del software da cui possono essere derivate stime del valore delle caratteristiche di qualità. Per esempio, la misura del grado di coesione e accoppiamento dei moduli può poterci aiutare per effettuare delle stime sulla manutenibilità di un prodotto. Le misure possono essere effettuate su tutti i documenti rilasciati dal progetto.

Processo di valutazione della qualità di un prodotto

La valutazione della qualità di un prodotto è basata sulla disponibilità dei documenti (specifica, progetto, codice). L’attività di valutazione avviene lungo tutto il processo di sviluppo. All’interno di un prodotto ogni caratteristica ha un suo peso determinato. Il processo di valutazione è composto da 4 passi fondamentali:

Definizione del profilo di qualità
Definizione del piano di qualità
Esecuzione del piano di durante il processo
Raccolta risultati e applicazione di regole di interpretazione al fine di esprimere un giudizio finale.

Definizione del profilo di qualità

Ad ogni caratteristica di qualità è assegnato un valore (importanza, criticità, valore di misura atteso) relativo all’intero prodotto (Esempio: un grande sistema di automazione richiede un’attenzione particolare alla manutenibilità e all’affidabilità). Il profilo si estrae dall’analisi dei requisiti e da interviste con utenti e il cliente.

Definizione del piano di qualità

Per ogni caratteristica di qualità è definito un modulo di attività di controllo (Test, ispezioni, misure). Un modulo di attività di controllo può eseguire verifiche su documenti diversi utilizzando tecniche diverse. Si ispeziona il documento di specifica per verificare la ricchezza delle funzioni messe a disposizione dell’utente. Si ispeziona il documento di progettazione per vedere se i risultati forniscono sufficiente garanzia di precisione).

Esecuzione del piano di durante il processo

Il piano viene eseguito dopo una delle fasi di studio del prodotto, come la progettazione architetturale o al termine della codifica.

Raccolta risultati e applicazione di regole di interpretazione al fine

di esprimere un giudizio finale Si effettua la raccolta dei risultati, si applicano delle regole di interpretazione e si valutano i risultati ottenuti. Criteri di valutazione possono essere: passa, non passa, insufficiente, sufficiente, buono, ottimo. In questo modo è possibile fornire delle spiegazioni al cliente sulle valutazioni, tali da poter essere utilizzate per migliorare il prodotto.

La valutazione ha delle complicazioni. Un prodotto software è costituito da più moduli e le caratteristiche di qualità non sono ugualmente importanti per tutti i componenti. Allora si crea una matrice di qualità per differenziare questi aspetti. Inoltre la caratteristica di un componente può essere considerata più critica e necessita di maggiori attenzioni. Dato che lo sforzo globale di controllo è limitato conviene concentrarsi nei componenti più critici, introducendo dei livelli nei moduli di controllo.

Spiegazioni

Questa fase ha il compito di fornire delle spiegazioni delle ragioni della valutazione tali da poter essere utilizzate per poter migliorare il prodotto. Il valore globale di una caratteristica di qualità è spiegato in termini di valori delle sottocaratteristiche e delle misure raccolte.

Testing

Alcune note teoriche

Il test del software è la verifica dinamica del comportamento di un programma. Tale verifica viene fatta con un numero finito di casi di test selezionati da un dominio di ingresso, rispetto ad un comportamento atteso specificato. Supponiamo di avere un programma P, funzione da dominio D (input) a un codominio R (output). Eseguire un test di P significa eseguire P per tutti i punti dati di D e controllare la coerenza dei risultati R. Un test ideale è un test esaustivo di D i cui risultati soddisfano le specifiche. Il caso esaustivo nella pratica è impossibile da realizzare, per ragioni pratiche, di costo e di tempo. Allora bisogna selezionarne un sottoinsieme mirato che permetta di ottenere risultati utili al fine di accrescere la fiducia nel prodotto sofware. Il testing quindi è uno strumento per accrescere la fiducia nei confronti del prodotto. Si deve evitare di pensare al testing come strumento per creare un programma corretto, ma per realizzarne uno affidabile. Effettuando un buon test l’utilizzatore acquisce fiducia nei confronti del programma. La safety definisce ciò che il programma non deve fare, in altre parole rappresenta i comportamenti indesiderati del sistema.

Costi

Il costo tipico del testing è circa il 30% del costo totale di progetto, anche se nella realtà questa percentuale è estremamente variabile. I soldi disponibili per effettuare il testing (budget del testing) sono pochi e a carico del fornitore. Il test è una fase critica non solo per i costi ma perchE’ è collocato nella fase finale del progetto, poco prima della data di consegna. Rischia di essere fatto di fretta, sotto pressione del cliente, per poter essere consegnato in tempo. Si rischia di effettuare un test carente, pericoloso perchE’ potrebbe non soddisfare il cliente. Il fornitore dovrebbe rimediare ai difetti allungando il periodo di lavoro e il cliente, insoddisfatto, continuerebbe a non pagare. Per evitare questi problemi è necessario definire una strategia di test che definisca le risorse disponibili e le utilizzi in modo appropriato rispetto a:

Costi
Soddisfazione del cliente (diversa da quella del fornitore)
Tipologia di prodotto
Tipologia del cliente
Criticità delle varie parti del prodotto.

Il test deve essere pianificato ed eseguito attraverso un processo di testing. Le tecniche di testing servono per offrire delle possibili soluzioni (anche se non esistono delle soluzioni giuste o sbagliate) a tipici problemi che si devono affrontare, come:

Qual è la soluzione migliore dati i costi e i tempi
Qual è la tecnica migliore in uno specifico caso

Le soluzioni offerte possono essere tecniche, euristiche, dettate dall’esperienze passate o dal confronto con casi analoghi. La strategia di un piano di test si trasforma in un processo omposto da tre punti principali:

Piano di test, elenco strutturato dei casi di test da eseguire in accordo con una strategia di test. (lista creata pensando ai casi di test delle parti principali del prodotto. Si compoone di nome del componente, codice che identifica la funzione - vedi specifiche - che deve realizzare, codice che identifica il caso di test, esito, descrizione del test).
Specifica del test, definizione delle caratteristiche di ogni caso di test
Rapporto di test, descrizione dei risultati dell’esecuzione del piano di test

Tipologie di test e copertura

Esistono tipologie di test:

Test funzionale (Black Box), vengono provate le funzioni del programma, indipendentemente da come il programma è costruito. Si considera il programma come una scatola nera e si valutano solo gli ingressi e le uscite.
Test strutturale (White Box), vengono provate le strutture interne del programma, considerando come è costruito il programma. Si utilizza la conoscenza della struttura interna del programma e si provano dei percorsi interni.

Esistono tre tipologie di copertura:

Copertura del testing, misura della quantità di controllo effettuata.
Copertura funzionale, misura della quantità di funzionalità (definite nella specifica) coperte dal testing. La copertura funzionale esaustiva è data dal rapporto tra n. di funzioni esercitate almeno una volta nel test e il n. totale di funzioni. Una funzione non implementata per un errore a monte (come nello studio delle specifiche) non viene rilevata per quanto il test funzionale sia accurato.
Copertura topologica, misura della tipologia e delle quantità di strutture esercitate, n_ istruzioni / istruzioni totali.

Struttura di un caso di test

Un caso di test è formato da quattro fasi:

Applicare i dati in ingresso
Effettuare azioni sul programma
Raccogliere i dati di uscita
Applicare un criterio per verificare che i dati di uscita corrispondono alla specifica (Criterio di successo o Oracolo).

Un caso di test può essere una struttura complessa che deve essere preparata prima. Applicarla per prodotti di mercato risulta più semplice rispetto a prodotti custom. Bisogna:

Predisporre il sistema nello stato iniziale prima di effettuare il test
Predisporre i dati di prova
Definire la procedura da seguire
Definire un oracolo, cioè un criterio di verifica del successo

Si può identificare il comportamento del sistema utilizzandolo (coscientemente) in modo corretto o sbagliato ed analizzarne i risultati. Sono entrambi test per verificare la robustezza del sistema. Si ottengono due tipi di test:

Test positivo, controlla il corretto funzionamento del programma a fronte di un uso corretto del sistema. Si inseriscono due numeri interi e il programma calcola la somma.
Test negativo, controlla il comportamento del programma a fronte di un uso scorretto del sistema, verifica la robustezza. Si inseriscono un numero intero e una stringa. Si possono raggruppare i test in insiemi di test, in cicli o catene per verificare aree funzionali. La catena incorpora regole di propedeuticità:
Caricamento di un dato
Verifica di corretto caricamento
Stampa
Verifica di corretta stampa
Cancellazione
Verifica di corretta cancellazione

Test funzionale (black box)

Un test funzionale è formato da diversi casi, a seconda delle esigenze. Quelli possibili sono i seguenti:

Casi di test da specifiche testuali

Si deve suddividere la specifica in aree funzionali omogenee. Per ogni area sono estratte le funzioni elementari semplicemente sottolineando le parole adeguate. Per ogni funzione elementare si definiscono casi di test. Si avrà una lista delle funzioni organizzata in sezioni.

Casi di test da modelli

La specifica è un modello formale o semi-formale da cui è possibile estrarre casi di test applicando un criterio definito. Esempio: un automa a stati finiti con tabella descrittiva.

Classi di equivalenza del dominio di ingresso

Si suppone che il programma si comporti allo stesso modo per ogni elemento della stessa classe. Si sceglie un caso di test per ogni classe.Ci sono delle regole euristiche che permetto di identificare queste classi. Esempio: nell’inserimento di numeri interi, le classi possono essere: numeri minori di 0, maggiori di 0 e lo 0.

Valori limite

I valori limite sono gli estremi delle classi di equivalenza. Sono le possibili fonti di errori perchE’ trattano casi particolari. Il programmatore tratta i casi normali, quelli limite possono essere dimenticati oppure gestiti con codice specifico.

Test negativi

I dati di input simulano un uso scorretto del sistema da parte dell’utente. Per effettuare i casi di test si individuano classi di equivalenza di questi dati di input (classi non valide)

Grafi causa effetto

Sono utilizzati per i casi di combinazioni complicate degli ingressi. Si selezionano casi di test significativi per verificare combinazioni di dati in ingresso che causano definite uscite. Si procede nel modo seguente:

Si identificano i fatti di ingresso e uscita (cause ed effetti);
La specifica è tradotta in una rete combinatoria che tratta cause ed

effetti. La rete aiuta a validare la specifica;

Seleziono un effetto;
Si riesegue il grafo effettuando tutte le combinazioni che generano

quell’effetto;

Per ogni combinazione si crea una colonna in una tavola di decisione;
Si procede così per tutti gli effetti.

Stima dei punti critici

Sulla base dell’esperienza del programmatore e del settore specifico applicativo un esperto del testing può identificare possibili situazioni causa di effetti e scrivere specifici casi di test

Casi di test da scenari

Si definisce un insieme di scenari di utilizzo. Per ogni scenario sono identificate le varianti considerate più significative o critiche. Gli scenari sono derivati dall’analisi dei requisiti o sono scritti ad hoc per il testing. Per ogni scenario è definito un caso di test. Gli scenari definiti verranno poi riutilizzati nel test di collaudo finale.

Test strutturale (white box)

Vengono definiti i casi di test sufficienti per rispettare un criterio di copertura di elementi definiti del programma. Il programma viene tradotto nel grafo di controllo, costituito da cerchi rapresentanti comandi, gruppi di comandi o condizioni e frecce rappresentanti i flussi di controllo. Il test strutturale viene eseguito basandosi su cinque criteri:

Copertura delle istruzioni, ogni istruzione (cerchio) deve essere percorsa almeno una volta.

C0 = n istr.eseguite / n istruzioni

Copertura delle decisioni, ogni decisione (arco) del grafo di controllo deve essere percorsa almeno una volta. C1=n archi percorsi / n archi percorribili
Copertura delle condizioni, ogni singola decisione che compare nel grafo deve essere percorsa sia per lo stato di vero che per lo stato di falso
Copertura dei cammini, ogni cammino deve essere percorso almeno una volta. Il numero massimo di percorrenze di un ciclo è la N copertura dei cicli. Cn=n. cammini percorsi / n. tot percorsi percorribili
Copertura del grafo di chiamata dei moduli, è un criterio di copertura a grana più grossa. Ogni arco che connette due moduli (chiamata di modulo) deve essere percorso almeno una volta.

Test di modulo, integrazione di sistema

Un sistema può essere costituito da più componenti interconnessi tra loro. E’ possibile effettuare dei test anche a insiemi di componenti per verificarne il funzionamento collettivo. Si utilizzano metodi diversi:

Big Bang Test, il sistema viene integrato e poi verificato globalmente.
Integration Test, il sistema viene verificato per parti e poi integrato progressivamente. Permette di identificare i difetti potenziali più agevolmente.
Top-Down Testing, si parte dal livello più alto del sistema, integrando i moduli uno alla volta, verificando passo per passo il loro funzionamento. E’ possibile usare dei componenti fittizi (stub) che simulano il comportamento di moduli di basso livello non ancora implementati. Nella pratica questa tecnica può essere combinata con la Bottom-Up.
Bottom-Up Testing, si parte dal livello più basso del sistema, verificando i singoli componenti. Li si integra progressivamente analizzando i livelli man mano più alti. E’ possibile usare componenti fittizi che simulano il comportamento di moduli di alto livello non ancora integrati (drivers). Nella pratica questa tecnica può essere combinata con la Top-Down.
Drivers e Stub, sono componenti software sviluppati ad hoc per permettere il test di integrazione senza effettuare una implementazione
Test gerarchico, si parte dallo strato più interno (per software con architettura a strati). Ogni strato deve essere testato dal punto di vista delle funzionalità attese dal suo utente, cioè lo strato superiore.
Test delle interfacce, sono realizzati insiemi di test progettati per validare l’interfaccia tra due componenti (es. diverse frequenze di aggiornamento dati tra le due interfacce, cambio dell’ordine dei parametri, ect).

Test di sistemi ad oggetti

Nei sistemi ad oggetti non si testano procedure ma classi e oggetti che incorporano procedure e dati (ogni oggetto ha una relazione di ingresso, di uscita e i suoi dati). Nel testing è necessario tenere conto dell’ereditarietà e del polimorfismo. Testare una classe vuol dire:

Test delle operazioni associate ad un oggetto
Definizione e interrogazione degli attributi
Test dell’oggetto nei suoi possibili stati

Nel testare ereditarietà e polimorfismo si deve considerare che l’informazione non è localizzata. Inoltre, quando si ereditano delle funzioni, è bene testare solo le differenze. Bisogna testare le diverse implementazioni per quegli oggetti che si riferiscono ad un certo codice solo a livello runtime. I sistemi ad oggetti non sono una struttura gerarchica ma una rete. Quindi un oggetto può vedere gli altri oggetti. I livelli di integrazione sono meno distinti e quindi bisogna studiare dei test che tengono conto di queste differenze. I livelli di test sono:

Test delle operazioni associate all’oggetto
Test delle classi
Test di gruppi di oggetti che collaborano
Test del sistema completo

Test di accettazione / collaudo

Il test di accettazione/collaudo utilizza la tecnica degli scenari. Si identificano un insieme di scenari di utilizzo, concordati con il cliente, i quali esercitano il prodotto nell’ambiente del cliente, con gli utenti tipici, nei casi tipici e in casi considerati critici. Gli scenari di test includono anche caratteristiche non funzionali.

Test di non regressione

Supponiamo di avere un insieme di casi di test T, eseguiti senza manifestare malfunzionamenti. Ad un certo punto si trova un difetto che viene corretto. La modifica però può aver introdotto altri difetti. Allora la batteria di test T viene rifatta, per accertarsi che la modifica non abbia introdotto difetti laterali. Questa procedura si può rifare risparmiando tempo se si studia una procedura automatica di test.

Test di caratteristiche non funzionali

Si possono costruire test relativi non solo a specifiche funzionali, ma anche a quelle non funzionali. Ad esempio:

Funzionalità e security, simulare un insieme di possibili attacchi
Affidabilità, simulare un insieme di possibili guasti
Efficienza, misurare le prestazioni in condizioni definite
Manutenibilità, non si eseguono dei test dinamici
Portabilità, non si eseguono dei test dinamici ma si effettuano delle stime allo scopo di verificare la propensione del prodotto ad essere portato

Strategia di test

La teoria del testing e le relative tecniche convergono nella strategia di test. Gli ingredienti per costruire una strategia di test sono:

Costi e tempi, che sono sempre limitati
Caratteristiche ed esigenze del cliente
Caratteristiche del prodotto e dell’ambiente di utilizzo

Bisogna sapere come bilanciare questi fattori per ottenere la strategia più adatta alla situazione. Scegliere la strategia di test più adatta implica sapere:

Cosa verificare
Come verificare
Quanto verificare

Le risorse e i tempi disponibili vanno negoziati con il cliente. Si devono analizzare gli scenari e i casi d’uso, in quanto non tutti gli aspetti sono critici. Di conseguenza bisogna scegliere le tecniche di testing e i criteri di copertura più adatti. Infine si deve creare il documento della strategia di test che definisca le scelte, ne spieghi il perchE’ e pianifichi le azioni.

Processo di test

Un processo di test è definito dalle seguenti fasi, che si intrecciano con quelle della progettazione del prodotto:

Definizione della strategia, che impatta significativamente sui costi
Specificazione
Preparazione del test black box
Progettazione architetturale
Inizio preparazione del test white box
Progettazione di dettaglio
Fine preparazione del test white box
Codifica
Esecuzione del test

Per facilitare e, in generale, velocizzare un processo di test è possibile realizzare un programma che automatizza alcune fasi, noiose e lunghe da preparare, come:

Raggiungimento dello stato iniziale del sistema
Predisposizione dei dati di prova
Lancio del programma sotto test
Verifica del successo (oracolo)

I processi di test devono essere adattati alle specifiche necessità e ai vincoli:

Dell’organizzazione di sviluppo
Dello specifico progetto

L’attività di test è una specifica competenza. E’ utile che venga eseguita da persone diverse dagli sviluppatori, per i seguenti motivi:

Indipendenza di giudizio, dato che non è legata ad aspetti particolari del prodotto
Esercizio di specifiche competenze dei tester
Utilizzo efficiente delle risorse umane, disponibili per altri lavori

Documenti

Il processo di test rilascia dei documenti:

Piano di test
Specifiche dei casi di test
Rapporti di esecuzione dei piani di test
Rapporto di qualificazione (rapporto sull’esito complessivo dell’attività di test)

Debugging

Il debugging è avviato dal manifestarsi di un malfunzionamento causato da un difetto di programma. Permette di identificare e correggere il difetto che ha causato il malfunzionamento. In questa fase ha molta rilevanza l’aspetto della manutenibilità del prodotto (come la comprensibilità e il rischio ridotto di generare effetti laterali non desiderati).

Analisi dei malfunzionamenti e dei difetti

Quando si rilevano degli errori devono essere registrati al fine di essere utilizzati:

Come indicatori dell’affidabilità del prodotto
Per diagnosticare le cause e migliorare il prodotto

I dati raccolti devono essere catalogati con processi ordinati:

Classificando i difetti per classi di attività e tipologia
Allocando i difetti al componente software, alle fasi, ai gruppi di lavoro

I dati raccolti possono essere analizzati con diverse tecniche, tra cui:

Analisi dei malfunzionamenti con modelli di affidabilità
Analisi e spiegazione causale dei difetti

Quando si ha una serie di dati che descrivono alcuni difetti è possibile valutare le cause di difficoltà per un eventuale intervento di correzione, come:

Complessità di un componente
Risorse non adeguate
Tempo ridotto
Progettazione carente

Ispezioni

Concetto e tipi di ispezione

Sono verifiche statiche di prodotto applicate alla documentazione (specifiche, architettura, ecc) e al codice sorgente. Hanno lo scopo di valutare aspetti di qualità del prodotto. Si possono eseguire delle verifiche di processo che permettono di capire a che punto del lavoro si è arrivati, quanto si ha speso e quanto rimane, sia in termini di denaro sia in termini di tempo. La procedura di ispezione è composta da quattro fas. Nella prima il gruppo di progetto definisce una release di uno o più documenti. Successivamente, un gruppo di ispezione esamina criticamente i documenti. I risultati vengono documentati e verranno intraprese azioni di sistemazione. Ci sono due tipi di ispezioni:

Review, il responsabile dell’ispezione opera all’interno dell’organizzazione di sviluppo,ma non ha partecipato alla realizzazione dei documenti su cui esegue la review. Ha diretto controllo delle azioni correttive intraprese dopo l’analisi della review.
Audit, il responsabile dell’ispezione non opera all’interno dell’organizzazione di sviluppo ma non ha partecipato alla realizzazione dei documenti su cui esegue la review. Non ha diretto controllo delle azioni correttive intraprese dopo l’analisi della review.

Per applicare queste due ispezioni con successo ci sono delle condizioni da rispettare:

I documenti devono essere disponibili
Familiarità degli ispettori con le tecniche da applicare, i formalismi e gli standard
Il management non deve utilizzare i risultati per valutare il personale, perché lo scopo è migliorare il prodotto. Valutare il personale può, anche se indirettamente, peggiorare la qualità del prodotto.

L’ispezione è una tecnica semplice ed utile che permette di:

Revisionare il progetto nei punti critici
Scoprire errori difficili da trovare con il testing del codice (dipendenti dal tempo)

Processo di ispezione

La verifica è eseguita in modo strutturato attraverso un processo definito. Si utilizzano due tecniche:

Walkthrought

Preparazione: si definisce un gruppo di revisione che riceve la documentazione

da revisionare e la legge separatamente

Analisi di gruppo: sotto la guida di un coordinatore la documentazione

è percorsa e sono documentati difetti scoperti, valutazioni ed azioni richieste

Inspection

Pianificazione: il responsabile degli ispettori concorda e pianifica l’attività
Overview: in una riunione gli autori illustrano i documenti oggetto dell’ispezione ai revisori
Preparazione: i revisori esaminano i documenti guidati da una checklist
Riunione congiunta d’ispezione: gli autori e i revisori valutano congiuntamente i documenti guidati da una checklist. Sono documentati difetti scoperti, valutazioni ed azioni richieste
Esecuzione delle modifiche: gli autori eseguono le modifiche richieste
Follow Up: il responsabile dei visori controlla la corretta esecuzione delle modifiche ed eventualmente indice una nuova sessione di revisione.

Gruppo di ispezione

Il gruppo di ispezione è formato da:

Gli estensori dei documenti da ispezionare
Almeno un revisore che non ha partecipato alla stesura dei documenti.

Deve essere definito un responsabile del processo che lo pianifica e lo gestisce. Inoltre uno dei partecipanti si incarica di annotare i risultati e le decisioni

Checklist

L’ispezione di un documento può essere strutturata e guidata da una lista predefinita di aspetti da esaminare. Nella checklist abbiamo:

Aspetti da esaminare.
Difetti tipici.
Suggerimenti su come eseguire le verifiche.

Strumenti automatici di analisi

Si utilizzano strumenti automatici di analisi statica. Si applicano a documenti scritti con linguaggi formali (tipicamente codice sorgente). Una di queste tecniche è l’analisi del codice:

Analisi del flusso di controllo (codice non raggiungibile).
Analisi di uso dei dati (come la dichiarazione di variabili mai utilizzate).
Analisi delle interfacce (consistenza tra la loro dichiarazione ed utilizzo).

Misure

Misure di prodotto, concetti generali

La qualità di un prodotto, conforme alle caratteristiche ISO 9126, può essere valutata non solo attraverso il testing o le ispezioni, ma anche raccogliendo misure relative a specifici aspetti del prodotto, al fine di stimare le caratteristiche di qualità. Esempio: dalla misura del grado di coesione e accoppiamento dei moduli, dalle dimensioni medie dei componenti in linee di codice, dalla densità dei commenti, è possibile stimare la manutenibilità. Alcune caratteristiche non sono valutabili effettuando dei test. La manutenibilità, per esempio, deve essere prevista organizzando in modo appropriato o con tecniche diverse la realizzazione del prodotto. A parità di condizioni si devono effettuare delle prove di manutenibilità ed osservare quale tecnica risulti esssere la più efficiente. Durante la vita di un prodotto software si possono misurare indicatori utili per predire o tenere sotto controllo caratteristiche di qualità (es. per l’affidabilità, è utile la copertura del test, il n_di difetti trovati / linee di codice nella fase di test, il n_ di difetti trovati / linee di codice in esercizio). La misura è il risultato della misurazione diuno specifico attributo.

La metrica è un insieme di regole per definire:

L’entità e l’attributo da misurare
L’unità di misura
Una procedura per assegnare numeri e simboli

Le misure interne misurano:

La coesione ed accoppiamento dei moduli software
Le dimensioni medie del componente in linee di codice
La densità di commenti nel codice
Sono valutate sui documenti

Le misure esterne sono valutate sul prodotto nell’ambiente di utilizzo. Ci sono una serie di assunzioni che si devono considerare:

Una proprietà globale del prodotto (Esempio: la manutenibilità) può essere misurata in modo quantitativo attraverso uno o più indicatori
Esiste una relazione tra gli indicatori (ciò che si misura) e le caratteristiche di qualità (ciò che si vuole stimare);
La relazione è stata formalizzata e validata e la stima ottenuta dal valore della caratteristica di qualità ha una capacità predittiva.

Definire e validare una relazione tra gli indicatori e le caratteristiche di qualità è difficile e controverso. E’ utile in contesti definiti anche se la capacità predittiva è difficile da ottenere.

Utilizzo

Ecco come utilizzare le misure:

Misura della qualità ai fine dell’accettazione, lo scopo è valutare le caratteristiche di qualità del prodotto (Esempio: manutenibilità, i cui valori sono definiti nei requisiti non funzionali).
Monitoraggio della qualità di prodotto durante il processo produttivo, lo scopo è di tenere sotto controllo il livello di qualità del prodotto durante lo sviluppo, al fine di identificare i problemi in anticipo ed intervenire. Le misure possono essere svolte dal produttore o, in casi di rilasci intermedi ufficiali, dal committente del prodotto o da terza parte.
Valutazione della qualità per diagnosi e reingegnerizzazione, lo scopo è valutare la qualità di un prodotto esistente la cui qualità deve essere migliorata. Bisogna individuare la convenienza ed i costi della reingegnerizzazione e le modifiche da apportare. Al termine della valutazione è fornita la diagnosi dello stato del prodotto e la terapia indicante le modifiche da intraprendere per l’ottenimento della qualità richiesta.

Esempi di misure

LOC (Line Of Code, linee di codice), numero di linee di codice esclusi i commenti. E’ usato da molto tempo come stimatore dello sforzo di programmazione. L’interpretazione di questa misura va comunque fatta in relazione al linguaggio di implementazione utilizzato e al tipo

di applicazione da realizzare.

Numero Ciclomatico (McCabe), dato il grafo di controllo di un programma, misura il numero di cammini linearmente indipendenti che, a partire dal nodo iniziale, raggiungono il nodo terminale:

V(G)=e-n+2

dove e è il numero di archi (flusso di controllo) e n è il numero di nodi (comandi). Un valore elevato di V(G) per un modulo indica una struttura complessa di controllo che influenzerà (assieme ad altri fattori) la manutenibilità del modulo stesso. Si dimostra che V(G)=d+1 (con d numero di decisioni binarie) misura un attributo della struttura di controllo di un programma. Non è una misura di manutenibilità.

Fan In, Fan Out, è applicato ad un modulo. Il fan in è il numero di moduli che chiamano il modulo misurato, il fan out è il numero di moduli che il modulo misurato chiama. Un fan in elevato suggerisce un alto grado di accoppiamento con il resto dei moduli dell’architettura, un fan out elevato suggerisce una complessità interna elevata del modulo.
Profondità dell’albero di ereditarietà, è il numero di livelli nel grafo di specializzazione delle classi. Più il valore di profondità è elevato, più il progetto è complesso e difficile da capire.

Es. confronto penna USB - smart card.

Raccolta, interpretazione e integrazione

Per ottenere stime di caratteristiche di qualità è necessario:

Raccogliere un insieme di misure diverse
Interpretare i singoli risultati
Integrare l’insieme dei risultati al fine di ottenere un valore dell’attributo stimato

Raccogliere un insieme di misure diverse vuol dire ottenere:

La dimensione media dei moduli in LOC
Numero ciclomatico medio dei moduli
Coesione ed accoppiamento
Indicatori di qualità di documentazione dei moduli
Indicatori di qualità di documentazione dell’architettura

Successivamente bisogna definire dei criteri per poter interpretare le misure ottenute. Si deve integrare l’insieme dei risultati al fine di ottenere, a partire dalle singoli interpretazioni, il valore stimato dell’attributo.

Misure di processo

Le misure relative ai prodotti possono essere utilizzate anche per valutare, controllare e gestire i processi. Possiamo individuare:

Valutazione di scarsa manutenibilità del prodotto può essere un possibile indicatore di carente progettazione, di carenza professionale dei programmatori, ect .
Difettosità elevata del prodotto in esercizio: possibile indicatore di carenze a livello di testing.

Un processo può essere gestito e migliorato attivando la raccolta e la valutazione periodica di un insieme di misure al fine di valutare la qualità del processo (maturità) e intraprendere azioni di miglioramento. Esempi di misure:

Numero di progetti fuori costo previsti a budget / numero totale di progetti
Numero di progetti fuori tempo previsto di consegna / numero totale di progetti
Numero di lamentele gravi di clienti
Numero di difetti sui prodotti rilasciati in esercizio / LoC

ControlloDellaQualita