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?
Dont 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