Documente Academic
Documente Profesional
Documente Cultură
Software Quality
Assurance:
Introduction
Dr. Holger Giese
Software Engineering Group
Room E 3.165
Tel. 60-3321
Email: hg@upb.de
University of Paderborn
Software Engineering Group
Outline
I
II
III
IV
V
VI
VII
Introduction
Software Life Cycle
Quality Control
Infrastructure
Management
Standards
Conclusion & Summary
I-2
University of Paderborn
Software Engineering Group
I Introduction
I.1
I.2
I.3
I.4
I.5
I.6
I.7
Motivation
Definitions & Terminology
Quality Management
Components of a SQA System
Organizing for SQA
Discussion & Summary
Bibliography
I-3
University of Paderborn
Software Engineering Group
I.1 Motivation
[Galin2004]
I-4
University of Paderborn
Software Engineering Group
I-5
University of Paderborn
Software Engineering Group
I-6
University of Paderborn
Software Engineering Group
check-in
plane unloading
conveyer belt
load DCV
Dr. Holger Giese
I-7
University of Paderborn
Software Engineering Group
a DCV (telecar)
load DCV
tunel system
unload DCV
Dr. Holger Giese
Destination-coded
vehicles (DCVs),
unmanned carts
(also named
telecars)
propelled
by linear
induction motors
mounted to the
tracks
can load bags
(without stopping)
can unload bags
(without stopping)
I-8
University of Paderborn
Software Engineering Group
unload DCV
enabling it to handle
over 1,000 bags per
minute.
baggage-claim
Dr. Holger Giese
load plane
WS04/05 Software Quality Assurance I Introduction
I-9
University of Paderborn
Software Engineering Group
Remark 1: This famous demo of the system in which hundreds of bags were destroyed was not done by BAE, but was done
by the City of Denver when BAE told them not to do it because the system was not working. BAE claimed that the city
violated the contract many times, making it nearly impossible for them to finish the job. Eventually the city quit managing
the project and United Airlines took over, and BAE was able to finish the project.
I-10
University of Paderborn
Software Engineering Group
I-11
University of Paderborn
Software Engineering Group
I-12
University of Paderborn
Software Engineering Group
I-13
University of Paderborn
Software Engineering Group
I-14
University of Paderborn
Software Engineering Group
One reason, if it might be called that, that BAE didnt perform a review of their
own design was that they were being made to work under an impossible tight
schedule.
BAE claim that they protested at the outset that the timeline Denver city officials
proposed for the completion of the project was utterly unrealistic.
Denver on the other hand claims that BAE committed to delivering the system
within a certain period of time, and should have delivered a bug free system in
that time.
Whoever the culprit, one thing is for sure, the time required to fully understand
and do justice to a system of this size and complexity was grossly
underestimated, and this had direct bearing on the efficiency of the design that
was put forth, and ultimately implemented.
identify problems with the design, and take decisions about them early, instead
of reacting to those problems after they were uncovered in testing
BAE and Denver didnt heed the advice of others, and grossly underestimated
the time for developing and testing the system (The Munich airport, on which
DIA was modeled, spent two years testing the system and six months of running
the system 24x7 before opening)
I-15
University of Paderborn
Software Engineering Group
I-16
University of Paderborn
Software Engineering Group
I-17
University of Paderborn
Software Engineering Group
DIA Conclusions
I-18
University of Paderborn
Software Engineering Group
I-19
University of Paderborn
Software Engineering Group
Software
Software quality
Measure quality
I-20
University of Paderborn
Software Engineering Group
Basic Terminology
Software is:
Computer programs, procedures, and
possibly associated documentation and data
pertaining to the operation of a computer
system.
[IEEE_Std_610.12-1990]
I-21
University of Paderborn
Software Engineering Group
[Galin2004]
I-22
University of Paderborn
Software Engineering Group
I-23
University of Paderborn
Software Engineering Group
Requirements:
Completeness
Design:
design
Manufacturing Implementation:
limited
Operation:
Fixing
found bugs
WS04/05 Software Quality Assurance I Introduction
I-24
University of Paderborn
Software Engineering Group
What is quality?
[Sommerville2004]
There
I-25
University of Paderborn
Software Engineering Group
I-26
University of Paderborn
Software Engineering Group
I-27
University of Paderborn
Software Engineering Group
Software Quality
Software quality is :
Conformance to explicitly stated functional
and performance requirements, explicitly
documented development standards, and
implicit characteristics that are expected of
all professionally developed software.
[Pressman2003]
I-28
University of Paderborn
Software Engineering Group
Software Quality
Quality the degree of excellence of something. We measure
the excellence of software via a set of attributes.
[Glass1992]
( satisfying requirements)!
Quality is absolute or at least independent of the
requirements underlying the product.
It is part of the software development to get the right
requirements.
( user satisfaction)!
McDonalds restaurants are popular, but
Dr. Holger Giese
I-29
University of Paderborn
Software Engineering Group
Quality Models
McCall
ISO/IEC 9126
Application or company
specific quality models
FURPS
GQM Approach
[ISO/IEC 9126]
I-30
University of Paderborn
Software Engineering Group
Factor-Criteria-Metrics-Model
Classification into :
Factors (to specify): They
describe the external view
of the software, as viewed
by the users.
Criteria (to build): They
describe the internal view
of the software, as seen by
the developer.
Metrics (to control): They
are defined and used to
provide a scale and
method for measurement.
Software Quality
Quality
factor 1
Quality
factor 2
Quality
factor 3
Quality
criterion 1
Quality
criterion 2
Quality
criterion 3
I-31
University of Paderborn
Software Engineering Group
A quality factor
represents a behavioral
characteristic of the
system.
[MaCall+1977]
[Galin2004]
Dr. Holger Giese
Operation
Revision
Transition
A quality criterion is an
attribute of a quality
factor that is related to
software production and
design.
A quality metric is a
measure that captures
some aspect of a quality
criterion.
I-32
University of Paderborn
Software Engineering Group
[ISO/IEC 9126]
Dr. Holger Giese
I-33
University of Paderborn
Software Engineering Group
Characteristics
Functionality
Subcharacteristics
Suitability
Accurateness
Attributes of software that bear on the provision of right or agreed results or effects.
Interoperability
Attributes of software that bear on its ability to interact with specified systems.
Compliance
Attributes of software that make the software adhere to application related standards or
conventions or regulations in laws and similar prescriptions.
Security
Attributes of software that bear on its ability to prevent unauthorized access, whether
accidental or deliberate, to programs or data.
Maturity
Attributes of software that bear on the frequency of failure by faults in the software.
Fault tolerance
Recoverability
Attributes of software that bear on the capability to re-establish its level of performance
and recover the data directly affected in case of a failure and on the time and effort
needed for it.
Understandability
Attributes of software that bear on the users effort for recognizing the logical concept
and its applicability.
Learnability
Attributes of software that bear on the userseffort for learning its application.
Operability
Attributes of software that bear on the userseffort for operation and operation control.
Reliability
Usability
Definitions
I-34
University of Paderborn
Software Engineering Group
Characteristics
Subcharacteristics
Time behaviour
Attributes of software that bear on response and processing times and on throughput
rates in performances its function.
Resource behavior
Attributes of software that bear on the amount of resource used and the duration of
such use in performing its function.
Analyzability
Attributes of software that bear on the effort needed for diagnosis of deficiencies or
causes of failures, or for identification of parts to be modified.
Changeability
Attributes of software that bear on the effort needed for modification, fault removal or
for environmental change.
Stability
Testability
Attributes of software that bear on the effort needed for validating the modified
software.
Adaptability
Attributes of software that bear on the opportunity for its adaptation to different
specified environments without applying other actions or means than those provided for
this purpose for the software considered.
Installability
Attributes of software that bear on the effort needed to install the software in a
specified environment.
Conformance
Replaceability
Attributes of software that bear on opportunity and effort using it in the place of
specified other software in the environment of that software.
Efficiency
Maintainability
Portability
Definitions
I-35
University of Paderborn
Software Engineering Group
security
Usability: aesthetics, consistency, documentation
Reliability: frequency and severity of failure, accuracy of
output
Performance: response time, resource consumption
Supportability: can it be extended, adapted, corrected?
I-36
University of Paderborn
Software Engineering Group
Functionality
Usability
Reliability
Performance
Supportabilit
y
Feature set
Human factors
Frequ./severity of fail.
Speed
Testability
Capabilities
Aesthetics
Recoverability
Extensibility
Generality
Consistency
Predictability
Security
Documentation
Accuracy
Efficiency
Rsc.
consumption
Thruput
Maintainability
Response time
Compatibility
Adaptability
Configurability
Serviceability
Installability
Localizability
I-37
University of Paderborn
Software Engineering Group
GQM: Goal-Question-Metric
I-38
University of Paderborn
Software Engineering Group
Example
GOAL:
productivity?
What is code
quality?
METRICS:
Proportion of
Coders
-using standard
-using language
Experience of
Coders
-with standard
Code
size
Errors
Effort
-with language
-with environment
etc
I-39
University of Paderborn
Software Engineering Group
GQM Discussion
Benefits :
generates only those measures relevant to the goal
Several measurements may be needed to answer a single question.
A single measurement may apply to more than one question.
The goal provides the purpose for collecting the data.
Not evident from the GQM
The model needed to combine the measurement in a sensible way
so that the question can be answered.
It must be supplemented by one or more models that express the
relationship among the metrics. (equation definition is not clear)
Disadvantages:
Additional efforts to derive the goals and metrics
Error prone compared to standard models
I-40
University of Paderborn
Software Engineering Group
Measuring Quality?
Users view:
Reliability
Manufacturers view:
Defect
counts
Rework costs
I-41
University of Paderborn
Software Engineering Group
Reliability
Reliability is the probability of a component, or
system, functioning correctly over a given period of
time under a given set of operating conditions.
Quantitative:
Reliability R(t) is the probability that the system
will conform to its specification throughout a period
of duration t.
I-42
University of Paderborn
Software Engineering Group
Availability
The availability of a system is the probability that
the system will be functioning correctly at any given
time.
Quantitative:
Availability A (or V) is the percentage of time for
which the system will conform to its specification.
I-43
University of Paderborn
Software Engineering Group
Safety
[Storey1996]
I-44
University of Paderborn
Software Engineering Group
Maintainability
I-45
University of Paderborn
Software Engineering Group
Defect Counts
I-46
University of Paderborn
Software Engineering Group
I-47
University of Paderborn
Software Engineering Group
A system failure occurs when the system fails to perform its required
function.
(Transition to incorrect service delivery, German: Ausfall)
If the distinction between fault and failure is not critical, defect can be
used as a generic term.
[Storey1996,Liu1996]
I-48
University of Paderborn
Software Engineering Group
User
Operator
?
?
?
Physical
process/system
System
(server)
component
(server)
component
(server)
System
component
(server)
component
(server)
component
(server)
I-49
University of Paderborn
Software Engineering Group
Fault/Failure Chain
Fault
Error
Failure
Fault
Error
Failure
Fault error
a fault which has not been activated by the computation process is
dormant
a fault is active when it produces an error
Error failure
an error is latent when it has not been recognized
an error is detected by a detection algorithm/mechanism
Failure fault
a failure occurs when an error passes through and affects the service
delivered
a failure results in a fault for the system which contains or interacts with
the component
Dr. Holger Giese
I-50
University of Paderborn
Software Engineering Group
I-51
University of Paderborn
Software Engineering Group
I-52
University of Paderborn
Software Engineering Group
Fault Classification
Nature (Critical distinction):
random/hardware faults
logical/systematic/design faults
E.g., Degradation (wear-out) vs. design faults
Duration:
permanent, transient, intermittent
Extent:
localized, global
Dr. Holger Giese
I-53
University of Paderborn
Software Engineering Group
mortality
End of useful lifewear out
Physical damagevibration, humidity, temperature
Examples:
Light bulb burns out
Disk head crashes
Power supply fails
Dr. Holger Giese
I-54
University of Paderborn
Software Engineering Group
I-55
University of Paderborn
Software Engineering Group
Examples:
Incorrect electrical wiring
Software defect!
I-56
University of Paderborn
Software Engineering Group
I-57
University of Paderborn
Software Engineering Group
Fault Avoidance
Fault forecasting
Activities:
Preventing the introduction or
occurrence of faults
(fault prevention):
Fault prevention
int i;
while(i<10){
if (i>3) {
}
Fault removal
Dr. Holger Giese
I-58
University of Paderborn
Software Engineering Group
I-59