Sqa I

University of Paderborn
Software Engineering Group
Software Quality
Assurance:
Introduction
Dr. Holger Giese
Room E 3.165
Tel. 60-3321
Email: hg@upb.de
Outline
I
II
III
IV
V
VI
VII
Introduction
Software Life Cycle
Quality Control
Infrastructure
Management
Standards
Conclusion & Summary
Dr. Holger Giese
WS04/05 Software Quality Assurance I Introduction
I-2
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
Dr. Holger Giese
I-3
I.1 Motivation
[Galin2004]
The Software Crisis:

IBM Consulting group estimates that 55% of large
distributed systems projects cost more than expected, 68%
overrun their schedules, and 88% require redesign.
The Standish group estimated the cost of bad software for
US businesses at $85 billion for 1998.
The Y2K problem was estimated to cost $1 to $2 trillion.
W.W Gibbs, in Software's Chronic Crisis in the Scientific
American, September 1994 estimates that the average
software project overshoots its schedule by half.
How to develop quality software?
Dr. Holger Giese
I-4
Software's Chronic Crisis

Denver's new international air port was to be the pride of the Rockies, a wonder of modern
engineering. Twice the size of Manhattan, 10 times the breadth of Heathrow, the airport is big
enough to land three jets simultaneously-in bad weather. Even more impressive than its girth
is the airport's subterranean baggage-handling system. Tearing like intelligent coal-mine cars
along 21 miles of steel track, 4,000 independent "telecars" route and deliver luggage between
the counters, gates and claim areas of 20 different airlines. A central nervous system of some
100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and
56 bar-code scanners orchestrates the safe and timely arrival of every valise and ski bag.
At least that is the plan. For nine months, this Gulliver has been held captive by Lilliputianserrors in the software that controls its automated baggage system. Scheduled for takeoff by
last Halloween, the airport's grand opening was postponed until December to allow BAE
Automated Systems time to flush the gremlins out of its $193-million system. December
yielded to March. March slipped to May. In June the airport's planners, their bond rating
demoted to junk and their budget hemorrhaging red ink at the rate of $1.1 million a day in
interest and operating costs, conceded that they could not predict when the baggage system
would stabilize enough for the airport to open.
W. W. Gibbs. Software's chronic crisis. Scientific

American, 271(3):72--81, September 1994.
http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html
Dr. Holger Giese
I-5
Denver International Airport Baggage System

The Denver International
Airport has a modern,
automated baggage-handling
system designed by BAE
Automated Systems, Inc. (In
June, 2003 G & T Conveyor
Company, Inc. acquired BAE)
See:
See:
Schloh,Michael.
Michael.Analysis
Analysisofofthe
theDenver
Denver
Schloh,
InternationalAirport
Airportbaggage
baggagesystem
system
International
http://www.csc.calpoly.edu/~dstearns/SchlohProjec
http://www.csc.calpoly.edu/~dstearns/SchlohProjec
t/csc463.html
t/csc463.html
Eipe,Rohit.
Rohit.The
Theimportance
importanceofofsoftware
software
Eipe,
architecture:
Denver
International
Airport's
architecture: Denver International Airport's
automated
baggage
handling
system:
report
automated baggage handling system: AAreport
http://wiki.cs.uiuc.edu/cs427/Essay+by+Rohit+Eipe
http://wiki.cs.uiuc.edu/cs427/Essay+by+Rohit+Eipe
:+Denver+Intnl+Airport:+Baggage+System
:+Denver+Intnl+Airport:+Baggage+System
Nice,Karim.
Karim.How
HowBaggage
BaggageHandling
HandlingWorks,
Works,
Nice,
HowBIZWorks
HowBIZWorks
http://biz.howstuffworks.com/baggage-handling.htm
http://biz.howstuffworks.com/baggage-handling.htm
Dr. Holger Giese
I-6
Automated Baggage-Handling System (1/3)
check-in
plane unloading
Move bags from the check-in

area to the departure gate
Move bags from one gate to
another during transfers
Move bags from the arrival
gate to the baggage-claim area
conveyer belt
The baggage handling system

at an airport plays a crucial
role. It makes the difference in
an airport's ability to attract or
keep a major airline hub ("an
airport that serves as a central
connecting point)
A baggage-handling system
has three main jobs:
Conveyors equipped with

junctions and sorting
machines automatically route
the bags to the gate.
load DCV
Dr. Holger Giese
I-7
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

DIA has:
More than 5 miles (8
km) of conveyor belts
More than 19 miles
(30 km) of DCV tracks
About 4,000 DCVs
unload DCV
enabling it to handle
over 1,000 bags per
minute.
baggage-claim
Dr. Holger Giese
load plane
I-9
Observation: First System Test (March 1994)
Telecars jumped tracks, crashed into each other; pieces of baggage

were flung off telecars, in some cases chewed to pieces.
Baggage was sent to the wrong places.
Line balancing algorithm problems arose, where there were bags lined
up waiting for telecars to come by, and yet empty telecars would just go
by without picking up these bags.
In peak conditions, the system quickly became overloaded with tracking
all the telecars in transit.
Head of line blocking occurred at popular telecar intersections in the
tunnel network, and rerouting of approaching telecars didnt always take
place.
Poorly printed baggage tags led to the laser scanners at one point
rejecting 70% of all baggage tags, sending them to manual baggage
stations.
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.
Dr. Holger Giese
I-10
Observation: Timeline (1/2)
The project was begun in the mid 80s by US Transportation

Secretary Fredrico Pena, the previous Denver mayor.
Construction was supposed to begin in September 1989
with an opening date set for October 31st 1993.
On March 2nd, 1993 the first delay was announced,
changing the date to December 19th, 1993.
October that year was the second delay.
March 1994 was the third.
After this Logplan was brought in, yet the fourth delay was
announced on May 2nd, 1994.
DIA finally began operations on February 28th, 1995.
Dr. Holger Giese
I-11
Observation: Timeline (2/2)
DIA finally began operations sixteen months behind

schedule, with a reduced number of gates operational,
concourse A being postponed indefinitely, the only having
been implemented in concourse B, an inability to handle
transfer flights, and with a capacity for handling only 30
bags a minute.
As of November 1996, DIAs automatic baggage handling
system was still not working. The airport was not even
increasing its air traffic; in 1995 the number of passengers
dropped by 2 million from when Stapleton was running, in
1994. High fees associated with Denver charging each
airline a $20 fee per passenger, which must have been
passed on to the customer, are supposedly the reason for
this disappointing performance.
Dr. Holger Giese
I-12
Observation: Financial Damages

Automated baggage handling system:
Originally planed budget was $193 million
the amount finally spent was close to $311 million (included
the cost of installing a manual system)
DIA
planed DIA costs were $1.7 billion
the final cost was more than 2.5 times that, at $4.5 billion
Delay costs:
estimated costs for every month that the DIA remained
closed was about $33.3 million
Dr. Holger Giese
I-13
Cause: Lack of Management
The baggage handling system has been implemented almost as an

afterthought! Thus the system of tunnels was not designed with a
particular baggage handling system in mind, and as it turned out, the
small tunnels and many sharp turns made BAEs job rather difficult.
The airport designers didnt even design their system with a baggage
handling system in mind, so BAE had to work around all kinds of
problems.
This was the reason that the management team never saw the baggage
handling system, of all things, to be so important that it could have such
a profound economic impact on the project.
The planning of the system was done in a completely haphazard way.
Little communication took place between DIAs airport designers, the
city officials, the airlines, and BAE.
The planning instead was driven by higher level management with little
or no understanding of the complexity of the system, and by consultants
contracted to develop a specification of the system, but who had no
direct responsibility to the team(s) that would actually develop the
system.
Dr. Holger Giese
I-14
Cause: Impossible Schedule/Plan
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)
Dr. Holger Giese
I-15
Cause: Complexity Problems
As it turned out, when a change needed to be made to one

part of the system, it was not clearly understood how that
change would impact the rest of the system. When the
system was eventually test-run, BAE found it incredibly
difficult to even understand why things were going wrong.
BAEs design was such that the number of components
working together was very high, and they were very tightly
coupled, and there was little redundancy.
sheer size of the system made it so complex that not even
the people who designed it were able to understand it very
well, leave alone a third party
to weed out problems at the design stage than to implement
a design that had rather glaring faults, and then try to
perform frantic firefighting
Dr. Holger Giese
I-16
Cause: Many Interfaces

One extremely difficult problem that BAE
faced was the task of conversing with United
AirlinesApollo reservation computers.
BAEs computers had to speak the same
software language as each of the airlines
The process of language translation that was
necessitated was painful and bug-filled at
best.
Dr. Holger Giese
I-17
DIA Conclusions
Missing communication between the stakeholders

The schedule didnt allow enough time to fully
design the system before jumping into
implementation.
The design of the baggage handling system was
not integrated into the design of the airport.
Not entirely inappropriately, the DIA was coined as
being DOA dead on arrival!
Dr. Holger Giese
I-18
How can we circumvent such

disasters?
Observation:
Quality problems prevent the system from functioning
Management decisions results in wrong reactions
Missing design reviews

Fixing rather than analyzing
Erratic debugging rather than systematic testing
Therefore even larger delays result
Systematic approach for the development of high quality

software is required
Dr. Holger Giese
I-19
I.2 Definitions & Terminology
Software
Software quality
Definition & characterization

Why do the classical approach to QA not apply?
Definition
Quality models
Quality attributes
Measure quality
Dr. Holger Giese
Reliability, Availability, safety, maintainability,

Defect counts
Software errors, faults and failures
Classification of the causes of software errors
I-20
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]
Dr. Holger Giese
I-21
[Galin2004]
What is special about Software?
Invisibility of the product

Limited opportunities to detect defects
(bugs)
Often new demanding functionality has to be
realized
Often software has to realize extraordinary
high complexity
Dr. Holger Giese
I-22
Classical Quality Assurance (Hardware)
Requirements: complete set of external quality

characteristics complete set of internal quality
characteristics and a detailed and complete set of
requirements and specifications
Design:
Design that satisfies the requirements and specifications

design for reliability (wear out)
design for manufacturability
design for maintainability (e.g., self-diagnosis)
Manufacturing: statistical production process control with

acceptance sampling
Operation: collect failure data for continuous improvement
and predictions (intelligent maintenance)
Dr. Holger Giese
I-23
Software Quality Assurance?
Requirements:
Completeness
is hard to achieve (complexity)
Design:
design
for reliability only in special cases

design for manufacturability is not required
design for maintainability in special cases
Focal area of software quality assurance!
Manufacturing Implementation:
limited
success with statistical process control (metrics)
Operation:
Fixing
Dr. Holger Giese
found bugs
I-24
What is quality?
[Sommerville2004]
Quality, simplistically, means that a product

should meet its specification.
This is problematical for software systems
There
is a tension between customer quality

requirements (efficiency, reliability, etc.) and
developer quality requirements (maintainability,
reusability, etc.);
Some quality requirements are difficult to specify
in an unambiguous way;
Software specifications are usually incomplete
and often inconsistent.
Dr. Holger Giese
I-25
Approaches to Tackle Quality

Transcendental view: quality is universally
identifiable, absolute, unique and perfect
Product view: the quality of a product is
measurable in an objective manner
User view: quality is fitness for use
Manufacturing view: quality is the result of
the right development of the product
Value-based view (Economic): quality is a
function of costs and benefits
Dr. Holger Giese
I-26
Software Quality IEEE View

Software quality is:
(1) The degree to which a system, component,
or process meets specified requirements.
(2) The degree to which a system, component,
or process meets customer or user needs
or expectations.
[IEEE_Std_610.12-1990]
Dr. Holger Giese
I-27
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.
[Pressman2004]
Dr. Holger Giese
I-28
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
Quality Models
Such general definitions of

software quality are not
sufficient in practice
Thus, software quality is
described by specific
quality models
causal relationship from
intangible quality views to
tangible software
measures
Two main approaches:

Standard Models:
McCall
ISO/IEC 9126
Application or company
specific quality models
FURPS
GQM Approach
[ISO/IEC 9126]
Dr. Holger Giese
I-30
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.
Dr. Holger Giese
Software Quality
Quality
factor 1
Quality
factor 2
Quality
factor 3
Quality
criterion 1
Quality
criterion 2
Quality
criterion 3
Quality indicators (metrics)
I-31
McCalls Factor Model Tree
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
The Six Quality Characteristics of

a Software (ISO/IEC 9126)
[ISO/IEC 9126]
Dr. Holger Giese
Software quality: The totality of

features and characteristics of a
software product that bear on its
ability to satisfy stated or implied
needs. (ISO 9126: 1991, 3.11)
Software quality characteristics:
A set of attributes of a software
product by which its quality is
described and evaluated. A
software quality characteristic may
be refined into multiple levels of
sub-characteristics. (ISO 9126:
1991, 3.13)
Each characteristic is refined to a
set of sub-characteristics
Each sub-characteristic is
evaluated by a set of metrics.
Some metrics are common to
several sub-characteristics.
I-33
Characteristics
Functionality
Subcharacteristics
Suitability
Attributes of software that bear on the presence and appropriateness of a set of

functions for specified tasks.
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
Attributes of software that bear on its ability to maintain a specified level of

performance in case of software faults or of infringement of its specified interface.
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
Dr. Holger Giese
Definitions
I-34
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
Attributes of software that bear on the risk of unexpected effect of modifications.
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
Attributes of software that make the software adhere to standards or conventions

relating to portability.
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
Dr. Holger Giese
Definitions
I-35
Hewlett Packard: F.U.R.P.S. (1/2)
Result of a statistical project survey at Hewlett

Packard 1987 to improve its products:
Factors:
Functionality:
functions it performs, their generality and
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?
FURPS is originally a company specific quality

model
Dr. Holger Giese
I-36
Hewlett Packard: F.U.R.P.S. (2/2)

Quality
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
Mean time to failure
Response time
Compatibility
Adaptability
Configurability
Serviceability
Installability
Localizability
Dr. Holger Giese
I-37
GQM: Goal-Question-Metric
A measurement program can be more successful

if designed with the goals in mind.
GQM approach provides a framework with 3
steps:
1.
2.
3.
List the major goals of the development/maintenance

project
Derive from each goal the questions that must be
answered to determine if the goals are being met
Decide what must be measured to answer the
questions adequately
[Basil&Rombach1988]
Dr. Holger Giese
I-38
Example
GOAL:
Evaluate effectiveness of coding standard
QUESTIONS: Who is using What is coder

Standard?
productivity?
What is code
quality?
METRICS:
Proportion of
Coders
-using standard
-using language
Dr. Holger Giese
Experience of
Coders
-with standard
Code
size
Errors
Effort
-with language
-with environment
etc
I-39
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
Dr. Holger Giese
I-40
Measuring Quality?
Users view:
Reliability
(number of failures over time)

Availability
Usability etc.
Often directly measurable
Manufacturers view:
Defect
counts
Rework costs
Dr. Holger Giese
I-41
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.
Note that t is important

If a system only needs to operate for ten hours at a
time, then that is the reliability target.
Dr. Holger Giese
I-42
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.
Literally, readiness for service
Dr. Holger Giese
I-43
Safety
[Storey1996]
Safety is a property of a system that it will

not endanger human life or the environment.
A safety-related system (safety-critical

system) in one by which the safety of
equipment or plant is assured.
Dr. Holger Giese
I-44
Maintainability
Maintenance is the action taken to retain a

system in, or return a system to, its designed
operating conditions. Maintainability is the
ability of a system to be maintained (ability to
undergo repairs and modifications).
Mean time to repair (MTTR)
Problem: Maintenance induced failures

Dr. Holger Giese
I-45
Defect Counts
software errors are the cause of

poor software quality
[Galin2004]
In software, higher quality (in the

form of lower defect rates) and
reduced development time go
hand in hand.
[McConnell 1996]
Unlike the low-defect kind of

quality, attention to this kind of
quality tends to lengthen the
development schedule.
[McConnell 1996]
Dr. Holger Giese
Intuitively, the occurrence of

defects is negatively related to
functionality and reliability.
Defects also interfere, to some
degree, with other dimensions of
quality.
I-46
Relative Cost of Correcting Defects

[Pressman2004]
Dr. Holger Giese
I-47
Faults, Errors and Failures
A fault is a defect within the system.

(Error cause, German: Fehlerursache)
An error is a derivation of the required operation of the system or

subsystem.
(Manifestation of a fault in a system, German: Fehlzustand)
software errors are a human action which results in software

containing a fault
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]
Dr. Holger Giese
I-48
Recursive Nature of Faults

A fault in a component can infect all other
components which depend on it.
Chain of Faults/Failures
User
Operator
?
?
?
Physical
process/system
Dr. Holger Giese
System
(server)
component
(server)
component
(server)
System
component
(server)
component
(server)
component
(server)
I-49
Fault/Failure Chain
Fault
Error
Failure
Fault
Error
Failure
next hierarchy level
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
Examples for Fault/Failure Chain

Program error (software):
a dormant fault in the written software (instruction or data)
upon activation the fault becomes active and produces an
error (system state)
if the erroneous data affects the delivered service, a failure
occurs
Electromagnetic interference (hardware):
leads to faulty input value (either digital or analog)
by reading the input the fault becomes active and produces
an error
if the erroneous input value is processed and becomes
visible at the interface a failure occurs
Dr. Holger Giese
I-51
Fault/Failure state transitions
Dr. Holger Giese
I-52
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
Nature: Degradation Faults
The system used to work but now it does not

Something broke for some reason:
Infant
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
Nature: Failure Bathtub Curve

wear out
Infant mortality
Dr. Holger Giese
I-55
Nature: Design Faults

The system never worked
Nothing broke
The design is flawed
Examples:
Incorrect electrical wiring
Software defect!
Dr. Holger Giese
I-56
Dealing With Faults

Fault Prevention:
Development techniques that prevent the
introduction of faults
Fault Elimination:
Development techniques that find and remove
faults already introduced
Fault Forecasting:
Estimate current number, future incidence and
likely consequences
Fault Tolerance (not considered here):
Execution-time techniques that cope with the
effects of faults
Dr. Holger Giese
I-57
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
Reducing the number and

seriousness of faults
(fault removal):
SWT, formal methods, high level

languages, CASE tools,
Analysis diagnosis correction
Evaluating the present number

future incidents, and severity of
faults (fault forecasting):
Statistics & management
I-58
Main causes for software faults:

1.
2.
3.
4.
5.
6.
Faulty requirements definition

Client-developer communication failures
Deliberate deviations from software requirements
Logical design errors
Coding errors
Non-compliance with documentation and coding
instructions
7. Shortcomings of the testing process
8. User interface and procedure errors
9. Documentation errors
[Galin2004]
Dr. Holger Giese
I-59
I.3 Quality Management
[Sommerville2004]
Quality Management System [ISO 9000]:

The organizational structure, responsibilities,
procedures, processes and resources for
implementing quality management
Concerned with ensuring that the required level of

quality is achieved in a software product.
Involves defining appropriate quality standards
and procedures and ensuring that these are
followed.
Should aim to develop a quality culture where
quality is seen as everyones responsibility.
Dr. Holger Giese
I-60
Environment Characteristics
Dr. Holger Giese
[Galin2004]
Being contracted
Subjection to customersupplier relationship
Requirement for teamwork
Need for cooperation and
coordination with other
development teams
Need for interfaces with
other software systems
Need to continue carrying
out a project while the
team changes
Need to continue
maintaining the software
system for years
I-61
The Cost of Quality
Cost of Quality includes all costs incurred in the pursuit of

quality or in performing quality related activities such as
appraisal costs, failure costs and external failure costs.
[Pressman2004]
The Quality Compromise:
We cannot wait for specifications to improve before paying

attention to quality management.
We must put quality management procedures into place to
improve quality in spite of imperfect specification.
[Sommerville2004]
Dr. Holger Giese
I-62
Scope of Quality Management
Quality management is particularly

important for large, complex systems. The
quality documentation is a record of
progress and supports continuity of
development as the development team
changes.
For smaller systems, quality management
needs less documentation and should focus
on establishing a quality culture.
[Sommerville2004]
Dr. Holger Giese
I-63
Quality Management and

Software Development
Software development
process
D1
D2
D3
D4
[Sommerville2004]
D5
Quality management
process
Standards and
procedures
Dr. Holger Giese
Quality
plan
Quality review reports
I-64
Quality Management Activities

(1) Quality assurance
Establish organisational procedures and standards for

quality.
(2) Quality planning
Select applicable procedures and standards for a

particular project and modify these as required.
(3) Quality control
Ensure that procedures and standards are followed

by the software development team.
Quality management should be separate from

project management to ensure independence.
[Sommerville2004]
Dr. Holger Giese
I-65
(1) Quality Assurance

Quality Assurance [ISO 9000]:
All those planned and systematic actions necessary to
provide adequate confidence that a product or service will
satisfy requirements for quality
Software quality assurance [IEEE]:
1. A planned and systematic pattern of all actions necessary
to provide adequate confidence that an item or product
conforms to established technical requirements.
2. A set of activities designed to evaluate the process by
which the products are developed or manufactured.
Contrast with: quality control.
Dr. Holger Giese
I-66
Quality Assurance
Software quality assurance is [Galin2004] :
A systematic, planned set of actions necessary to provide
adequate confidence that the software development
process or the maintenance process of a software system
product conforms to established functional technical
requirements as well as with the managerial requirements
of keeping the schedule and operating within the budgetary
confines.
Quality assurance consists of the auditing and reporting

functions of management [Pressman2004]
Dr. Holger Giese
I-67
(2) Quality Planning
Quality planning is the process of

assessing the requirements of the
procedure and of the product and the
context in which these must be observed.
Quality assurance plan is the central aid

for planning and checking the quality
assurance.
[Pressman2004]
Dr. Holger Giese
I-68
Quality Assurance Plan
[Sommerville2004]
A quality assurance plan sets out the desired

product qualities and how these are assessed and
defines the most significant quality attributes.
The quality assurance plan should define the
quality assessment process.
It should set out which organisational standards
should be applied and, where necessary, define
new standards to be used.
Dr. Holger Giese
I-69
Quality Assurance Plans
Quality assurance plan structure:
[Sommerville2004]
Product introduction
Product plans
Process descriptions
Quality goals
Risks and risk management
Quality assurance plans should be

short,
succinct
(If they are too long, no-one will read them)
Dr. Holger Giese
I-70
Example: SQA Plan
Purpose of Plan
References
Management
organization structure, SQA tasks,

their placement in the process
roles and responsibilities related to
product quality
Documentation
Standards, Practices and

Conventions
Reviews and Audits
Test
project documents, models,

technical documents, user
documents.
test plan and procedure
Problem Reporting and Corrective

action
Tools, Techniques and

Methodologies
Code Control
Media Control
Supplier control
Records Collection,
Maintenance and
Retention
Training
Risk Management
[IEEE_Std_730-1998, Pressman2004]
Dr. Holger Giese
I-71
22
(3) Quality Control

Quality Control [ISO 9000]:
The operational techniques and activities
that are used to fulfil requirements for quality
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.
[Pressman2004]
Dr. Holger Giese
I-72
Quality Control
[Sommerville2004]
This involves checking the software

development process to ensure that
procedures and standards are being
followed.
There are two approaches to quality control
Quality reviews;
Automated software assessment and software
measurement.
Dr. Holger Giese
I-73
Quality Control
Objective:
minimize the produced defects
increase the product quality
Implementation approaches:
Fully automated
Entirely manual
Combination of automated tools and human
interactions
Dr. Holger Giese
I-74
Quality Control
Quality control includes a feedback loop to the process:
provide management with the necessary data about product
quality.
gain the insight and confidence of product quality
Two types of quality control:
Quality design: the characteristics that designers specify
for an item (includes: requirements, specifications, and the
design of the system).
Quality of conformance: the degree to which the design
specification are followed. It focuses on implementation
based on the design.
[Pressman2004]
Dr. Holger Giese
I-75
Quality Assurance System
Quality assurance system is the organizational

structure, responsibilities, procedures, processes
and resources for implementing quality
management.
[Pressman2004]
Dr. Holger Giese
I-76
Process and Product Quality
The quality of a developed product is influenced

by the quality of the production process.
This is important in software development as
some product quality attributes are hard to
assess.
However, there is a very complex and poorly
understood relationship between software
processes and product quality.
[Sommerville2004]
Dr. Holger Giese
I-77
Process-based Quality
There is a straightforward link between process

and product in manufactured goods.
More complex for software because:
[Sommerville2004]
The application of individual skills and experience is

particularly important in software development;
External factors such as the novelty of an application
or the need for an accelerated development schedule
may impair product quality.
Care must be taken not to impose inappropriate

process standards - these could reduce rather
than improve the product quality.
Dr. Holger Giese
I-78
Process-based quality
Dr. Holger Giese
[Sommerville2004]
I-79
Practical Process Quality
[Sommerville2004]
Define process standards such as how

reviews should be conducted, configuration
management, etc.
Monitor the development process to ensure
that standards are being followed.
Report on the process to project
management and software procurer.
Dont use inappropriate practices simply
because standards have been established.
Dr. Holger Giese
I-80
I.4 Components of a SQA System

(1) Pre-project components
(2) Software project life cycle components
(3) Infrastructure components for error prevention
and improvements
(4) Management SQA components
(5) SQA standards, system certification and
assessment components
(6) Organizing for SQA the human components
and considerations guiding construction of
organizations SQA system
Dr. Holger Giese
I-81
(1) Pre-project Components

Pre-project
Contract reviews
Development and quality plans
(see Chapter II and III)
Dr. Holger Giese
I-82
(2) Project Life Cycle Components

Development
Reviews
Expert opinions
Software testing
Assurance of the quality of external participants
work
Maintenance
Software maintenance components
(see Chapter II and III)
Dr. Holger Giese
I-83
(3) Infrastructure Components
Procedures and work instruction

Templates and checklists
Staff training, retraining and certification
Preventive and corrective actions
Configuration management
Documentation control
(see Chapter IV)
Dr. Holger Giese
I-84
(4) Management SQA Components

Project progress control
Software quality metrics
Software quality costs
(see Chapter V)
Dr. Holger Giese
I-85
(5) Standards, Certification, Assessment
Project process standards

Quality management standards
Objectives:
Utilization of international professional knowledge
Improvement of coordination with other
organizations quality systems
Objective professional evaluation and
measurement of the organizations SQA
achievement
(see Chapter VI)
Dr. Holger Giese
I-86
(6) Organizing for SQA

Managements role in SQA
The SQA unit
SQA trusties
SQA committees
SQA forums
(see Chapter I.5)
Dr. Holger Giese
I-87
[Galin2004]
The Software Quality Shrine

(1)
ct SQ
e
j
o
r
Pre-p
ts
onen
p
m
A co
Project
Development plan
and Quality Plan
Contract review
(3) Quality Infrastructure components

Procedures
Supporting
Devices
Training
Instruction
Preventive
Actions
Configuration
Management
Documentation
Control
SQA of External Participants
Software Maintenance
Software Testing
Experts Opinion
Peer Reviews
Formal Design Reviews
(2) Project Life Cycle SQA components
(4) Quality Management
(5) Standards
Project
Progress
Control
Management
Software
Quality
Metrics
Software
Quality
Costs
Quality
Standards
Project
Process
Standards
(6) Organizational Base Human components

Management
Dr. Holger Giese
SQA Unit
SQA Trustees
SQA Committees
SQA Forums
I-88
[Galin2004]
I.5 Organizing for SQA

a)
a)
b)
b)
c)
c)
d)
d)
e)
e)
Project
Development plan
and Quality Plan
Contract review
(3) Quality Infrastructure components

Procedures
Supporting
Devices
Training
Instruction
Preventive
Actions
Configuration
Management
Software Maintenance
Software Testing
Experts Opinion
Peer Reviews
Formal Design Reviews
(2) Project Life Cycle SQA components
Documentation
Control
Management
Management
SQAUnit
Unit
SQA
SQATrustees
Trustees
SQA
SQACommittees
Committees
SQA
SQAForums
Forums
SQA
SQA of External Participants
(1)
ts
onen
p
m
o
QA c
S
t
c
ro j e
Pre-p
(4) Quality Management
(5) Standards
Project
Progress
Control
Management
Software
Quality
Metrics
Software
Quality
Costs
Quality
Standards
Project
Process
Standards
(6) Organizational Base Human components

Management
Dr. Holger Giese
SQA Unit
SQA Trustees
SQA Committees
SQA Forums
I-89
Management
Exec.
Exec .
Exec.
Executive
responsible for
software quality
The SQA framework

SQA unit
Other
Departments
Software
Testing
Department
Software
Development
and
Maintenance
Department
SQA
Committees
Legend
SQA
Forums
Line of authority
line for SQA
issues
Flow of Forum s
recommendations
line
[Galin2004]
Dr. Holger Giese
Software
Testing
Teams
Software
Development
Teams
SQA
Trustees
I-90
The SQA Framework: Participants

Managers
Testers
Top management executives,

especially the executive in
charge of SQA
Software development and
maintenance department
managers
Software testing department
managers
Project managers and team
leaders of development and
maintenance projects
Leaders of software testing
teams
Dr. Holger Giese
Members of software testing

teams
SQA professionals and

interested practitioners
SQA trustees
SQA committee members
SQA forum members
SQA unit team members
I-91
a) Management
Overview:
Top managements quality assurance activities
Software quality policy
The executive in charge of software quality
Management review
Department management responsibilities for

quality assurance processes
Project management responsibilities for quality

assurance
Dr. Holger Giese
I-92
TOP Management Responsibilities
[Galin2004]
Assure the quality of the Companys software products

and software maintenance services.
Communicate the importance of product and service
quality in addition to customer satisfaction to employees.
Assure full compliance with customer requirements.
Ensure that SQA objectives are established and
accomplished.
Initiate planning and oversee implementation of changes
to adapt the SQA system to changes related to the
organization's clientele, competition and technology.
Intervene directly to resolve of crisis situations and
minimize damages.
Ensure availability of resources required by SQA
systems.
Dr. Holger Giese
I-93
SQ Policy Requirements
[Galin2004]
Quality policy refers to the basic aims and objectives of

an organization regarding quality as stipulated by the
management.
[Pressman2004]
Conformity to the organization purpose and goals

Commitment to:
General software quality assurance concepts
The quality standards adopted by the organization
Allocate adequate resources for software quality

assurance
Continuous improvement of the organizations quality and

productivity
Dr. Holger Giese
I-94
Responsibilities (Executive in Charge)
Responsibility for preparation of an annual

SQA activities program and budget
Responsibility for preparation of SQA system

development plans
Overall control of implementation of the

annual SQA regular activities program and
planned SQA development projects
Presentation and advocacy of SQA issues to

executive management
[Galin2004]
Dr. Holger Giese
I-95
Management Reviews
Def.: Management review is the name given to the periodic meeting
convened to allow executives to obtain an overview of their
organizations software quality issues.
Typical items:
Periodic performance reports, including quality metrics
Customer satisfaction feedback
Follow up reports for SQA annual regular activity program and SQA
development projects
Summary of special quality events related to customers, suppliers,

subcontractors, etc.
Review of significant findings of internal and external quality audits as

well as special surveys
Identification of new software quality risks and unsolved pre-existing

risks
Recommendations for software quality management improvements.

[Galin2004]
Dr. Holger Giese
I-96
Management Reviews: Objectives
Assess achievement of quality objectives set

for the organizations software quality
management system
Initiate updates and improvements of the
software quality management system and its
objectives
Outline directions for remedying major SQA
deficiencies and software quality management
problems.
Allocate additional resources to the software
quality management system.
[Galin2004]
Dr. Holger Giese
I-97
Department Responsibilities (1/2)

The quality system-related responsibilities:
Preparation of the departments annual SQA

activities program and budget, based on
recommended SQA unit program.
Preparation of the departments SQA systems

development plans, based on recommended
SQA unit plan.
Control of performance of the departments

annual SQA activities program and development
projects
Presentation of the department's SQA issues to

the executive in charge of software quality. [Galin2004]
Dr. Holger Giese
I-98
Department Responsibilities (2/2)

Project-related responsibilities
Control of compliance to quality assurance procedures in the

department's units
Detailed follow up of contract review results and proposal approvals
Review of unit performance of planned review activities; approval of

project documents and project phase completion
Follow up of software tests; approval of projects software products.
Follow up of progress of software development project schedules

and budget deviations. Advise and support project mangers in
resolving difficulties.
Follow up of quality of maintenance services
Detailed follow up of project risks and their solutions
Follow up of project's compliance with customer requirements and

customers satisfaction.
Approval of large software change orders and significant deviations

from project specifications.
[Galin2004]
Dr. Holger Giese
I-99
Project Management Responsibilities

Professional hands-on tasks:
Preparation of project and quality plans and their updates.
Participation in joint customer-supplier committee
Close follow up of project team staffing, including recruitment,

training and instruction.
Management tasks The follow up issues:
Performance of review activities and the consequent corrections,

including participating in some reviews.
Software development and maintenance units performance with

respect to development, integration and system test activities,
corrections and regression tests and acceptance tests
Software installation in customer sites and the running-in of the

software system by the customer
SQA training and instruction of project team members
Schedules and resources allocated to project activities.
Customer requests and satisfaction
Evolving project development risks, application of solutions and

control of results.
[Galin2004]
Dr. Holger Giese
I-100
b) The SQA Unit

Overview:
Activities
Responsibilities
Tasks performed by the head of the SQA unit
SQA sub-unit tasks related to the project life cycle
SQA sub-unit infrastructure operations tasks
SQA sub-unit audit and certification tasks
SQA sub-unit support tasks
SQA sub-unit standards and procedures: Development

and maintenance tasks
SQA sub-unit information system tasks
Dr. Holger Giese
I-101
SQA Unit Tasks
[Pressman2004]
Quality assurance planning oversight, record keeping,

analysis and reporting
Participates in the development of the projects software
process
Reviews software engineering activities to verify compliance
with the defined software process.
Audits designated software work products to verify
compliance with those defined as part of the software
process.
Ensures that deviations in software work and work products
are documented and handled according to a document
procedure.
Records any noncompliance and reports to senior
management.
Dr. Holger Giese
I-102
12
Unit: Organizational Structure
[Galin2004]
Head
SQA Unit
SQA
Operations
Project
Life Cycle
SQA
SQA
Standards
and
Procedures
Internal and
Certification
SQA Audits
SQA
Infrastructure
Operations
Dr. Holger Giese
SQA
Development
and Maintenance
SQA
Support
SQA
Information
Systems
SQA
Engineering
I-103
SQA Unit Head Tasks (1/2)

Planning tasks
Preparation of proposals for the Units annual activity program and

budget
Planning and updating the organizations software quality
management system and recommended annual SQA activities
programs for the software development and maintenance
departments.
Preparation of recommended SQA systems development plans for
the software development and maintenance departments.
Management tasks
Management of SQA team's activities

Monitoring implementation of the SQA activity program
Nomination of team members, SQA committee members and SQA
trustees
Preparation of special and periodic status and performance reports.
[Galin2004]
Dr. Holger Giese
I-104
SQA Unit Head Tasks (2/2)

Contacts with customers and other external bodies and
the executive in charge of software quality
Serving as the customers address for software quality issues of

software products and services supplied
Representation of the organization before external bodies regarding
software quality issues
Drafting the management review reports
Raising SQA organizational issues and preparing requested material
for top management's consideration
SQA professional activities
Participation in project joint committees

Participation in formal design reviews
Review and approval of deviations from specifications
Consultation to project managers and team leaders
Participation in SQA committees and forums
[Galin2004]
Dr. Holger Giese
I-105
Life Cycle Tasks (Sub-Units)

Project life cycle control tasks
Follow up of development and maintenance teams compliance with
SQA procedures and work instructions
Approval or recommendation of software products (design reports

and code).
Monitoring delivery of software maintenance services to internal and

external customers
Monitoring customer satisfaction (surveys, etc.) and maintaining

contact with customers SQA representatives
Participation tasks participation in:
Contract reviews
Preparation and updating of project development and project quality

plans
Formal design reviews
Subcontractors formal design reviews
Software testing, including customer acceptance tests
Software acceptance tests of subcontractors software products
Installation of new software products
[Galin2004]
Dr. Holger Giese
I-106
Infrastructure Tasks (Sub-Units)
Publication of updated versions of procedures, work instructions,

templates, checklists, etc., with their circulation.
Training and instruction to new and current staff and SQA trustees
regarding SQA procedures, work instructions, new and revised
procedures, development tools and methods, etc.
Monitoring and supporting implementation of new and revised SQA
procedures
Follow up of staff certification activities
Proposal of subjects requiring preventive and corrective actions
Follow up of configuration management activities
Follow up of compliance with documentation procedures and work
instructions
[Galin2004]
Dr. Holger Giese
I-107
Types of Audits (in or by SW Org)
Internal audits
Audits of subcontractors and suppliers to
evaluate their SQA systems
External audits performed by certification
bodies
External audits performed by customers
who wish to evaluate the SQA system prior
to accepting the organization as a supplier
[Galin2004]
Dr. Holger Giese
I-108
Audits and Certifications (Sub-Units)
Preparation of annual programs for SQA audits

Performance of SQA audits
Follow up of corrections
Preparation of periodic summary reports
Collection of data on the performance of the audited
organization from internal and external sources
Periodic evaluation of the audited organization
Coordination of the external audit's contents and
schedule
Preparation of documents as specified by external
auditors
Instruction of the audited teams and performance of
preparations for external audits
Participation in the audit
[Galin2004]
Dr. Holger Giese
I-109
Support Tasks (Sub-Units)
Preparation of project development plans and

project quality plans
Staffing review teams
Choice of development methodologies and tools
that reflect the accumulated failure experience
Choice of measures to solve identified software
development risks
Choice of measures to solve schedule delays
and budget overruns
Choice of SQA metrics and software costs
components
Use of SQA information systems
[Galin2004]
Dr. Holger Giese
I-110
Standard and Procedures (Sub-Units)
Prepare an annual program for development of new

procedures and procedure updates
Responsibility for development of new procedures and

procedure updates, including participation in appropriate
committees and forums
Follow up of developments and changes in SQA and
software engineering standards; introduction of additional
relevant procedures and changes
Initiation of updates and adaptations of procedures in
response to changes in professional standards, including
adoption or deletion of standards applied by the
organization.
[Galin2004]
Dr. Holger Giese
I-111
Engineering (Sub-Units)
Testing quality and productivity aspects with respect to

new development tools and new versions of currently
used development tools
Evaluation of quality and productivity of new and
improved development and maintenance methods
Development of solutions to difficulties confronted in
application of currently used software development tools
and methods
Development of methods for measuring software quality
and team productivity
Provision of technological support to CAB committees
during analysis of failures and formulation of solutions
[Galin2004]
Dr. Holger Giese
I-112
Information Systems (Sub-Units)
Development of SQA information systems for

software development and maintenance units for:
Collection of activity data.
Processing of information delivered by the

units: periodic reports, lists, exception
reports, queries and estimates of software
quality metrics and software quality costs.
Updating of SQA information systems
Development and maintenance of the
organization's SQA Intranet/Internet site
[Galin2004]
Dr. Holger Giese
I-113
SQA Unit Plan
[Pressman2004]
Evaluations to be performed
Audits and reviews to be performed
Standards that are applicable to the project
Procedures for error reporting and tracking
Documents to be produced by the SQA group
Amount of feedback provided to software
project team
Dr. Holger Giese
I-114
c) SQA Trustees
Unit-related tasks:
Support their colleagues' attempts to solve difficulties in the

implementation of SQA procedures and work instructions
Help their unit manager in performing his or her SQA tasks Promote
compliance and monitor implementation of SQA procedures and work
instructions by colleagues
Report substantial and systematic non-compliance events to the SQA
unit
Report severe software quality failures to the SQA unit
Organization-related tasks
Initiate changes and updates of organization-wide SQA procedures

and work instructions
Initiate organization-wide improvements of development and
maintenance processes and applications for solutions to recurrent
failures observed in their units
Identify organization-wide SQA training needs and propose an
appropriate training or instruction program
[Galin2004]
Dr. Holger Giese
I-115
d) SQA Committees
Permanent committees commonly deal with:
SCC (software change control),
CA (corrective actions),
Procedures,
Development of method, tools and quality metrics.

Ad-hoc committees commonly deal with specific cases:
Updates of a specific procedure,
Analysis and solution of a software failure,
Elaboration of software metrics for a targeted process or

product,
Updating software quality costs,
Data collection methods for a specific issue.

[Galin2004]
Dr. Holger Giese
I-116
e) SQA Forums
SQA forums typically focus on:
SQA procedures improvements and implementation
Quality metrics
Corrective actions analysis of failure and success cases
Quality system issues development and implementation of new

tools
Quality line management problems daily operational software

quality problems
Members of an open forum may include:
SQA unit members
SQA trustees
Software development and maintenance staff
SQA and software engineering consultants/experts
Customer representatives
[Galin2004]
Dr. Holger Giese
I-117
Other Relevant Structures
[Pressman2004]
Requirements Control Board

All
requirement changes must be formally

reviewed and approved
Software Control Board

All
design changes must be formally reviewed

and approved
Interface Control Board
Dr. Holger Giese
I-118
I.6 Discussion & Summary
General quality definitions of quality are not sufficient in

practice. Thus, software quality is described by specific
quality models which determine the causal relationship
from intangible quality views to tangible software measures
[ISO/IEC 9126]
We cannot wait for specifications to improve before paying
attention to quality management. We must put quality
management procedures into place to improve quality in
spite of imperfect specification.
Quality management activities consist of quality assurance,
quality planning, and quality control.
Dr. Holger Giese
I-119
Discussion & Summary
The quality of a developed product is influenced by the

quality of the production process. This is important in
software development as some product quality attributes are
hard to assess. However, there is a very complex and poorly
understood relationship between software processes and
product quality.
The main instrument for quality is the software quality
assurance system.
Components of a software quality assurance system for the
pre-project phase, each life cycle phase, management,
infrastructure, standardization, and organization exist.
Organizing for SQA involves mainly the management, SQA
Unit, SQA Trustees, SQA Committees, and SQA Forums
Dr. Holger Giese
I-120
I.7 Bibliography (1/4)

[Basili&Rombach1988] V.R. Basili, H. D. Rombach, "The TAME Project:
Towards Improvement-Oriented Software
Environments," IEEE Transactions on Software
Engineering, vol.SE-14, no.6, June 1988, pp.758-773
[Glass1992]
R.~L. Glass, Building Quality Software. Englewood
Cliffs, NJ, USA: Prentice Hall, 1992.
[Galin2004]
D. Galin, Software Quality Assurance: From theory to
implementation. Harlow, England: Pearson Addison
Wesley, 2004.
[Horch1996]
J.~W. Horch, Practical guide to software quality
management. Boston, USA: Artech House, first ed.,
1996.
[Horch2003]
J.~W. Horch, Practical guide to software quality
management. Boston, USA: Artech House, second ed.,
2003.
Dr. Holger Giese
I-121
I.7 Bibliography (2/4)

[ISO9000]
[ISO9001]
[ISO 9004]
[ISO 9000addon]
Dr. Holger Giese
ISO 9000:2000, Quality management systems

Fundamentals and vocabulary
ISO 9001:2000, Quality management systems
Requirements
ISO 9004:2000, Quality management systems Guidelines
for performance improvements
"ISO 9000 Introduction and Support Package" guidance
documents from ISO/TC 176 SC2:
N524 - Guidance on ISO 9001:2000 Sub-clause 1.2
'Application'
N525 - Guidance on the Documentation Requirements of
ISO 9001:2000
N526 - Guide to the Terminology used in ISO 9001:2000 and
ISO 9004:2000
N544 - Guidance on the Concept and Use of the Process
Approach for management systems
N630 - Guidance on Outsourced Processes
I-122
Bibliography (3/4)
[ISO9000-2002]
ISO Handbook:2002, ISO 9001:2000 for small businesses What to

do, Advice from ISO/TC 176
[ISO/IEC 9126]
Information technology - Software Product Evaluation - Quality
characteristics and guidelines for their use - 1991.
http://www.cse.dcu.ie/essiscope/sm2/9126ref.html
ISO/IEC 9126-1:2001: Software engineering -- Product quality -- Part
1: Quality model
ISO/IEC TR 9126-2:2003: Software engineering -- Product quality -Part 2: External metrics
ISO/IEC TR 9126-3:2003: Software engineering -- Product quality -Part 3: Internal metrics
ISO/IEC TR 9126-4:2004: Software engineering -- Product quality -Part 4: Quality in use metrics
[IEEE_Std_610.12-1990] Standards Coordinating Committee of the IEEE Computer Society,
The Institute of Electrical and Electronics Engineers, Inc. 345 East
47th Street, New York, NY 10017-2394, USA. IEEE Std 610.121990, IEEE Standard Glossary of Software Engineering
Terminology. (Revision and redesignation of IEEE Std 729-1983).
[IEEE_Std_730-1998] Standards Coordinating Committee of the IEEE Computer Society,
The Institute of Electrical and Electronics Engineers, Inc. 345 East
47th Street, New York, NY 10017-2394, USA. IEEE Std 730-1998,
IEEE Standard fro Software Quality Assurance Plans.
Dr. Holger Giese
I-123
Bibliography (4/4)
[Lyu1996]
Michael R. Lyu, editor. Handbook of software reliability

engineering. IEEE Computer Society Press, Los
Alamitos, Calif., 1996.
[McCall +1977]
J.A. McCall, P.K. Richards, and G.F. Walters, Factors
in Software Quality, Vol. 1, AD/A-049-014/015/055,
Nat'l Tech. Information Service, Springfield, Va., 1977.
[McConnell 1996] Steve McConnell. Software Quality at Top Speed.
Software Development. August 1996
[Pressman2004]
Roger Pressman. Software Engineering: A
Practitioner's Approach. McGraw-Hill, 6 ed., 2004.
[Sommerville2004] Ian Sommerville. Software Engineering. Addison
Wesley. 7 ed., 2004.
[Schulmeyer1992] G. G. Schulmeyer, ed., Handbook of software quality
assurance. Van Nostrand Reinhold, 1992.
Dr. Holger Giese
I-124

Sqa I

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sqa I

Caricato da

Copyright:

Formati disponibili

University of Paderborn

Software Engineering Group

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

The Software Crisis:

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Software's Chronic Crisis

W. W. Gibbs. Software's chronic crisis. Scientific

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Denver International Airport Baggage System

WS04/05 Software Quality Assurance I Introduction

Automated Baggage-Handling System (1/3)

Move bags from the check-in

The baggage handling system

Conveyors equipped with

WS04/05 Software Quality Assurance I Introduction

Automated Baggage-Handling System (2/3)

WS04/05 Software Quality Assurance I Introduction

Automated Baggage-Handling System (3/3)

Observation: First System Test (March 1994)

Telecars jumped tracks, crashed into each other; pieces of baggage

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Observation: Timeline (1/2)

The project was begun in the mid 80s by US Transportation

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Observation: Timeline (2/2)

DIA finally began operations sixteen months behind

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Observation: Financial Damages

WS04/05 Software Quality Assurance I Introduction

Cause: Lack of Management

The baggage handling system has been implemented almost as an

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Cause: Impossible Schedule/Plan

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Cause: Complexity Problems

As it turned out, when a change needed to be made to one

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Cause: Many Interfaces

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

Missing communication between the stakeholders

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

How can we circumvent such

Missing design reviews

Systematic approach for the development of high quality

Dr. Holger Giese

WS04/05 Software Quality Assurance I Introduction

I.2 Definitions & Terminology

Definition & characterization

Dr. Holger Giese