Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Stefano Russo » 18.Classificazione e analisi dei difetti software


Migliorare la qualità del sw

Conoscere la qualità e la quantità dei difetti in un prodotto software è importante ai fini del miglioramento del processo di sviluppo.

Tre possibili approcci:

  • Statistical Defect Models
  • Causal Analysis
  • Orthogonal Defect Classification

Statistical Defect Models

L’obiettivo di questa tecnica è di predire la qualità di un prodotto software.

Questa viene misurata in termini di:

  • Numero di difetti ancora presenti nel prodotto
  • Failure rate del prodotto
  • Detection rate di difetti nel prodotto

Pros. Fornisce una buona “report card” per il prodotto software.
Cons. È applicabile solo nelle ultime fasi del ciclo di sviluppo, quindi di poco valore per migliorare il processo.

Causal Analysis

L’obiettivo di questa tecnica è di identificare le cause principali dei difetti e di intraprendere azioni correttive per eliminarle.
I difetti vengono analizzati uno per volta da un team di esperti.

Pros. Fornisce un feedback agli sviluppatori durante tutte le fasi del processo di development.

Cons. L’analisi è qualitativa e limitata al range delle ispezioni umane.

Non si presta a misure o analisi quantitative.
Lo sforzo richiesto è significativo

Orthogonal Defect Classification

Le due tecniche presentate rappresentano due estremi opposti:

  • Misure quantitative
  • Analisi qualitativa

Una buona tecnica di misurazione che riesce anche a fornire un feedback significativo agli sviluppatori è l’ODC.

Orthogonal Defect Classification

Idea:

  • Un difetto nel software è anche un difetto nel processo di sviluppo;
  • Per migliorare la qualità del processo e quindi la qualità del prodotto occorre legare i difetti al processo di sviluppo.

Orthogonal Defect Classification

In sostanza ODC vuol dire organizzare i difetti in classi che consentano di inferire sul processo di sviluppo del software.

Un tipico esempio di inferenza consente di identificare quale fase del processo di sviluppo richiede maggiore attenzione.

Uno dei rischi presenti nel processo di classificazione è legato al fatto che viene condotto da un essere umano.

Orthogonal Defect Classification

Questo problema viene ridotto se il processo di classificazione è semplice ed i dati da interpretare sono anch’essi di semplice interpretazione, lasciando poco spazio a confusione o possibilità di errore.

La ODC è caratterizzata da:

  • Un piccolo insieme di classi di difetti, che semplifica la scelta;
  • Ortogonalità delle classi, che assicura l’identificazione univoca.

Condizioni

Necessaria:
Deve esistere una classificazione semantica dei difetti, tale da poter mettere in relazione la classe di un difetto con il processo di sviluppo.
Questa relazione deve poter raccontare lo stato di avanzamento del prodotto nel processo.
(es. Dove sono i problemi in questo prodotto?)

Sufficiente:
L’insieme di tutte le classi di difetti deve formare una base dello spazio del processo di sviluppo.

Condizioni

Sulla base della condizione necessaria le classi di difetti devono essere ortogonali e associabili al processo che si vuole studiare.

La condizione sufficiente assicura che il numero di classi sia adeguato per questo compito: tutto ciò che è presente nello spazio del processo deve cioè poter essere descritto.

La natura sperimentale rende difficile garantire a priori che la condizione sufficiente sia verificata.

Schema di Classificazione

  • Defect Type – Rappresenta un difetto nel codice sorgente;
  • Defect Trigger – Rappresenta l’insieme delle condizione ambientali o delle attività che hanno portato all’identificazione del difetto.

Defect Analysis


Defect Type Analysis

Obiettivo: Caratterizzare i problemi del processo di sviluppo che hanno portato alla introduzione di difetti.

Step 1: Identificare un set di defects.
Step 2: Identicare i Defect Types.
Step 3: Plot delle distribuzioni dei Defect Types.
Step 4: Maping dei Defect Types sulle attività di development.

Defect Type

Il “defect type” è scelto dalla persona che corregge il difetto, sulla base del metodo di correzione.

Soddisfa la condizione necessaria.

Esempio:

  • Viene identificata una Capability non corretta;
  • Si tratta di un difetto della classe Function;
  • Un difetto di tipo Function è associabile alla fase di highlevel design che ne era responsabile.

Defect Type

FUNCTION: affects a sizeable amount of code and refers to capability that is either implemented incorrectly or not implemented at all.

LOGIC: Affects the functionality of a code module and can be fixed by re-implementing an algorithm or local data structure without a need for requesting a high level design change.

INTERFACE: Affects the interaction of components via macros, call statements and/or parameters.

CHECKING: Affects program logic that would properly validate data and values before they are stored or used in computation.

ASSIGNMENT: Requires change in a few lines of code, such as initialization of control blocks or data structures.

TIMING/SERIALIZATION: Affects the proper management of shared and real-time resources.

BUILD/PACKAGE/MERGE: Affects product version or configuration; requires a formal changes to reconfigure or rebuild the product.

Esempio

L’andamento della distribuzione dei difetti nelle diverse fasi del processo di sviluppo offre interessanti spunti di riflessione.

L'andamento della distribuzione dei difetti nelle diverse fasi del processo di sviluppo offre interessanti spunti di riflessione.


Esempio


Defect Trigger Analysis

Obiettivo: Caratterizzare i problemi del processo di sviluppo che hanno consentito ai difetti di sfuggire alle fasi di controllo.

Step 1: Identificare un set di defects.
Step 2: Identificare i Defect Triggers.
Step 3: Plot delle distribuzioni: Defect Trigger by Family, Review Triggers, Function Test Triggers, System Test Triggers.
Step 4: Mapping dei Defect Triggers sulle attività di detection.

Defect Trigger

Condizioni o attività che mettono in luce un difetto.

I trigger sono individuati durante le fasi di test e di verifica.
Possono essere identificati sul campo da clienti o da esperti di diagnosi.

Il concetto di trigger fornisce una indicazione sul processo di verifica (non sul processo di sviluppo).
Idealmente la distribuzione dei trigger per i difetti individuati sul campo dovrebbe essere simile alla distribuzione trovata durante i test di sistema.
La presenza di una discrepanza significativa è indicativa di potenziali falle nell’ambiente di test.

Defect Trigger

Diversi trigger possono evidenziare il medesimo difetto.

I trigger sono classificati sulla base delle tre principali attività di verifica:

  • Review / Inspection
  • Function test
  • System test

Review/Inspection Triggers

DESIGN CONFORMANCE: Comparing the implemented design against a reference –design document, pattern, or guideline.
LOGIC/FLOW: Checking for correctness or flaws using knowledge of the practice.
BACKWARD COMPATIBILITY: Examining compatibility with prior version of the product.
LATERAL COMPATIBILITY: Examining for compatibility with other products and platforms that need to work with this release.
CONCURRENCY: Serialization, shared resources, multi-threaded tasks, timing, etc.
INTERNAL DOCUMENT: Inconsistencies in prologs, and sections in the same work product.
LANGUAGE DEPENDENCY: Programming standards, specific implementation considerations, environment restrictions, execution modes, etc.
SIDE EFFECTS: Usage behavior beyond design, but relevant in context. Do A; B happens.
RARE SITUATION: Unusual issues related to idiosyncrasy of environment, hardware, or software.

Function Test Triggers

SIMPLE PATH: White box – Straightforward usage of code path and branches.
COMPLEX PATH: White box – Exercising conditionals, and circuitous coverage.
COVERAGE: Black box – Straightforward usage of function or single parameterized execution.
VARIATION: Black box – Straightforward like coverage, but with a variety of parameters.
SEQUENCING: Black box – Multiple functions, with a specific sequence (order is important).
INTERACTION: Black box – When two or more bodies of code are involved (order is not important).

System Test Triggers

WORKLOAD STRESS: Pushing the limits of performance, resources, users, queues, traffic, etc.
RECOVERY: Invoke exception handling, recovery, termination, error percolation, etc.
STARTUP/RESTART: Major events of turning on, off, or changing the degree of service availability.
HARDWARE CONFIGURATION: Issues surfaced as a consequence of changes in hardware setup.
SOFTWARE CONFIGURATION: Issues surfaced as a consequence of changes in software setup.
BLOCKED TEST/NORMAL MODE: Test could not run during System Test, or customer found nonspecific trigger. Look for additional trigger.

Esempio

Review/Inspection  ↔  Peer Reviews or Inspections

Function Test  ↔  Testing of specified scenarios

System Test  ↔  Testing in real-world scenarios or extreme scenarios

Esempio di mapping tra fasi e tipo di trigger.

Esempio


  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93