Quality Control

1. Software Quality
Assurance:
QUALITY CONTROL

2. 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.

3. Verification & Validation
Verification – 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

4. 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.

5. Terminology: Dynamic/Static Analysis
Dynamic analysis:
The process of evaluating a system or
component based on its behavior during
execution.

6. Terminology: Dynamic/Static Analysis
Static analysis:
The process of evaluating a system or
component based on its form, structure,
content, or documentation.

7. Dynamic vs. Static Analysis
Dynamic analysis (testing):
 execution of system components;
 running the software
Static analysis:
 investigation without operation;
 pencil and paper reviews etc.
 Modelling (mathematical representation)

8. Static Analysis Techniques
Overview
Reviews and Inspections
Walkthroughs, inspections, personal reviews
Formal technical reviews
Summary
Other Techniques
Control-flow analysis, data-flow analysis, metrics, …

9. Reviews and Inspections
A 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

10. Purpose/Objectives
Verify that
software meets its requirements
software follows predefined standards
software is developed in uniform manner

11. Purpose/Objectives
Catching errors
Sooner
More and different
Breaking frame of reference

12. Purpose/Objectives
Make projects more manageable
To identify new risks likely to affect the project
 Improving communication
Crossing organization boundaries
 Providing Education
 Making software visible

13. 1 Personal Review
Features
◦ Informal
◦ Done by the producer
Implications
◦ Not objective
◦ Available to any developer
◦ Different mindset
◦ Need for review
◦ Product completion
Limited screening efficiency!

14. 2 Inspections
Features
◦ 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

15. 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

16. 4 Formal Technical Review
Features
Formal
Scheduled event
Defined procedure
Reported result
Independent review team
Producers not present
Implications
More preparation time
Less material per meeting
Product