OHT 1.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
Money transfers to employees’
bank account accounts
Bank
information
systems
Output interface
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