OHT 1.

• The uniqueness of software quality assurance

• The environments for which SQA methods
are developed
• (significantly modified by R. Roggio, Fall 2011)

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.2
Introduction
• Why Quality Assurance?
• With all the methodology wars, numerous processes,
huge number of tools to assist in software development,
why this separate topic?
• What makes it important that it deserves separate
treatment?
• Why do so many companies add disclaimers to their
software?
– Don’t warranty the documentation…
– Not responsible for direct, indirect, consequential, loss?

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.3
What we are after;
that is, we want to be able to:
• 1. Identify the unique characteristics of software as a
product and as process that justify separate treatment of its
quality issues.
• 2. Recognize the characteristics of the software
environment where professional software develepment
and maintenance take place

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.4

• High complexity
– The potential ways in which a software product can be used with different
data / data paths reflecting different incoming data is almost infinite.
– Manner in which industrial products can be used are usually well-defined.
– Think about software: every loop with different values of data reflects a
different opportunity to see software fail.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.5

• Invisibility of the product

– In an industrial product, missing parts are obvious.
• Something missing? Easily identified.
– Not so in software products.
• May not be noticeable for years – if at all!
• Cite: phantom paths product at AFDSDC!

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.6

• Opportunities to detect defects (“bugs”)??

• Consider:
– Product Development
– Product Planning
– Product Manufacturing
–

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.7

• Product Development:
– Industrial: test product; voltages; performance; strength; size; ….ready to distribute
to markets
– Computer Software: once prototype and system testing are concluded, product is ready
for deployment
• About the same approach
• Arguable: equal chance to discover defects?
– What do YOU think??

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.8

Product Production Planning:

– Industrial: Often need new tooling approaches, assembly lines, new
manufacturing processes.
• Results in additional ‘looks’ at products
• One could say that there is a better chance to discover defects
– Computer Software: No real additional ‘look-see.’
• Packages shrink-wrapped, printed, distributed to public
• No real chance to discover additional defects.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.9

Product Manufacturing:
– Industrial: Usually defects uncovered here; easily fixed.
• Typical burn-in problems; another view of product; stabilizes.
• These represent additional opportunities to discover defects.
– Computer Software:
• We merely copyright, print copies of software and manuals
• No real chance for additional quality views
• No real chance for discovering additional defects

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.10
Only Chance to Discover Defects:
• Best chance to really detect defects occurs during the
software development process itself!

• “The need for special tools and methods for the software industry is
reflected in the professional publications as well in special standards
devoted to SQA, such as ISO 9000-3, “Guidelines for the application of
ISO 9001 to the development, supply, and maintenance of software.”
• Another: ISO 9004-2: “Quality Management and Quality Systems
Elements: Guidelines for the Services.”

• These characteristics of software – complexity, invisibility, and limited

opportunity to detect bugs has led to the development of the ISO
Guidelines and an awareness of real SQA methodology.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.11

• Important to note that quality issues seem to center around

software development professional activities undertaken
by development and maintenance organizations vice an
individual.
• Quality issues govern professional software development.
• This is our focus: large scale development rather than
individual application development

• Here are some of our main environmental issues:

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.12

• Being contracted
• Subjection to customer-supplier 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

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.13
SQA Environment
• Being Contracted:
– Professional software development is almost always
contracted.
• Have requirements / supplied requirements (hopefully)
– But may have in-house customer representatives.
– Or, customer representatives available…
• Budget
• Time schedule

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.14
SQA Environment

• Subject to Customer-Supplier Relationship

– In professional software development, there is a
constant (hopefully) oversight between customer and
developer.
• Changes will occur;
• Criticisms will arise.
• Cooperation is critical to overall project success.

– Customer availability / relationship is essential and

often problematic whether reps are in-house or not.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.15
SQA Environment
• Required Teamwork
– We need teams due to
• Time required for development.
– Workload is too much for a single person
• A frequent variety of experts needed
– Database; networking; algorithms; …
• Need ‘independent’ reviews to ensure quality (me)

– Who is ‘on the team?’

• Developers
• Clients / customers
• Others???

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.16
SQA Environment

• Cooperation and Coordination with Other

Software Teams
– May be partially outsourced thus requiring cooperation
• Outsourced  overseas?
• Many potential problems here … and benefits.
– Laision?
– May be that specialized hardware requires cooperation.
– Other teams may have developed similar software for
the client and can offer tremendous help.

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.17

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.18
SQA Environment

• Interfaces with Other Systems

– Interface, link to, import, include other packages
containing, say, libraries of perhaps classes / packages
to assist in development.
– Standardization considerations in interfaces
– May need to cooperate with inputs coming from other
systems and outputs requiring special formats that
serve as inputs to other systems…
– Do you think Billing, Payroll, Accounts Payable are all
distinct systems???

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.19

Attendance
control
system

Input interface Monthly attendance report,

including overtime calculations
Salary
processing
system

Output interface Money transfers to employees’

bank account accounts
Bank
information
systems

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.20
SQA Environment

• Need to Continue Project despite Team Changes

– Team members leave, are hired, fired, take unexpected
vacations, transferred within the company, and more.
– Maddening truism, but the development must continue.
– You can count on disruption!

Galin, SQA from theory to implementation © Pearson Education Limited 2004

 OHT 1.21
SQA Environment

• Need to continue Software Maintenance for an

Extended Period
– Whether external customers or in-house customers,
follow-on maintenance is typical and for many years!!
– Highly desirable from management/enterprise
perspective
• SQA must address development, operations, and
maintenance! (next chapter)

Galin, SQA from theory to implementation © Pearson Education Limited 2004