Conoscere la qualità e la quantità dei difetti in un prodotto software è importante ai fini del miglioramento del processo di sviluppo.
Tre possibili approcci:
L’obiettivo di questa tecnica è di predire la qualità di un prodotto software.
Questa viene misurata in termini di:
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.
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
Le due tecniche presentate rappresentano due estremi opposti:
Una buona tecnica di misurazione che riesce anche a fornire un feedback significativo agli sviluppatori è l’ODC.
Idea:
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.
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:
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.
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.
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.
Il “defect type” è scelto dalla persona che corregge il difetto, sulla base del metodo di correzione.
Soddisfa la condizione necessaria.
Esempio:
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.
L'andamento della distribuzione dei difetti nelle diverse fasi del processo di sviluppo offre interessanti spunti di riflessione.
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.
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.
Diversi trigger possono evidenziare il medesimo difetto.
I trigger sono classificati sulla base delle tre principali attività di verifica:
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.
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).
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.
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.
1. Caratterizzazione dei sistemi distribuiti
2. Modelli di sistemi distribuiti
3. Tempo e sincronizzazione nei Sistemi Distribuiti
4. Stato globale nei Sistemi Distribuiti
5. Problemi di consenso nei sistemi distribuiti
7. Algoritmi di mutua esclusione nei sistemi distribuiti
8. Algoritmi di elezione nei sistemi distribuiti
10. Il Network File System di SUN Microsystems
11. AFS (Andrew File System) e GFS (Google File System)
12. Transazioni e controllo di concorrenza
13. Transazioni
15. Affidabilità (dependability) dei sistemi software distribuiti
16. Affidabilità dei sistemi software distribuiti
17. Software Faults
18. Classificazione e analisi dei difetti software