Software QualityAssurance:

QUALITY CONTROL

Foundations

Quality Control

is the series of inspections, reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it.

Verification & ValidationVerification – The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase

Validation - The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements

Verification & Validation

Verification: refers to the set of activities that ensure that software correctly implements a specific function.

Validation: refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.

Terminology: Dynamic/Static Analysis

Dynamic analysis:

The process of evaluating a system or component based on its behavior during execution.

Terminology: Dynamic/Static Analysis

Static analysis:

The process of evaluating a system or component based on its form, structure, content, or documentation.

Dynamic vs. Static AnalysisDynamic analysis (testing):

execution of system components;

running the software

Static analysis:

investigation without operation;

pencil and paper reviews etc.

Modelling (mathematical representation)

Static Analysis TechniquesOverview

Reviews and Inspections

Walkthroughs, inspections, personal reviews

Formal technical reviews

Summary

Other Techniques

Control-flow analysis, data-flow analysis, metrics, …

Reviews and InspectionsA family of techniques

(1) Personal reviews

(2) Inspections

(3) Walkthroughs

(4) Formal technical reviews

Review / inspect

To examine closely

With an eye toward correction or appraisal

Purpose/ObjectivesVerify that

software meets its requirementssoftware follows predefined standardssoftware is developed in uniform manner

Purpose/Objectives

Catching errorsSoonerMore and differentBreaking frame of reference

Purpose/ObjectivesMake projects more manageable

To identify new risks likely to affect the project

Improving communication

Crossing organization boundaries

Providing Education

Making software visible

1 Personal ReviewFeatures◦ Informal

◦ Done by the producer

Implications◦ Not objective

◦ Available to any developer

◦ Different mindset◦ Need for review

◦ Product completionLimited screening efficiency!

2 InspectionsFeatures◦ Team reviews materials separately

◦ Team and producers meet to discuss

◦ May review selected product aspects only

Implications◦ Focus on important issues

◦ If you know what they are

◦ More material per meeting

◦ Less preparation time

3 Walkthroughs Features Less formal

Producer presents or provides information

Implications Larger groups can attend (education)

More material per meeting

Less preparation time

Disadvantage: Harder to separate Product and presenter

Explanation and justification

4 Formal Technical ReviewFeatures

FormalScheduled event

Defined procedure

Reported result

Independent review teamProducers not present

Implications

More preparation time

Less material per meeting

Product