Software Quality Assurance

CH2-Software Quality

University of Information Technology

1
 Topics

• What is Software?
• Software Error, Fault and Failure
– Case study:Therac-25
• Classification of the causes of software errors
• Software Quality
• Software Quality Assurance
• Quality Control
• The objectives of SQA activities

2
 What is Software?

• Software – IEEE definition

Software is Computer programs, procedures,
and possibly associated documentation and data
pertaining to the operation of a computer
system.

3
 Software….

ISO definition (from ISO 9000-3) lists four components

necessary to assure the quality of the software development
process and years of maintenance:
1. Computer programs (the “code”)
2. Procedures
3. Documentation
4. Data necessary for operating the software system.

4
 Basic Definitions
• Software Error – made by programmer
– Syntax (grammatical) error
– Logic error (multiply instead of adding two operands)
• Software Fault – defect in product
– All software errors may not cause software faults
– That part of the software may not be executed
• Software Failures – software fault is activate.
– A software fault becomes a software failure when/if it is activated.
– Faults may be found in the software due to the way the software is
executed or
– Other constraints on the software‟s execution, such as execution
options.
5
Software development process

software error
software fault
software failure

6
 Software Error, Fault and failures

Software failure case study

• Therac-25
– The Therac-25 was a radiation therapy machine produced by Atomic
Energy of Canada Limited
– A software failure disaster.

7
Reading Assignment:Therac-25

• Read the journal of Therac-25

• Think about how to to prevent software failure

disaster?

• Youtube Therac-25

8
 Classification of the causes of
software errors

1. Faulty definition of requirements

9
 Classification of the causes of
software errors
1. Faulty Requirements Definition
• Usually considered the root cause of software errors
• Incorrect requirement definitions
• Simply stated, „wrong‟ definitions (formulas, etc.)
• Incomplete definitions
• Unclear or implied requirements
• Missing requirements
• Just flat-out „missing.‟ (e.g. Program Element Code)
• Inclusion of unneeded requirements
• (many projects have gone amuck for including far too
many requirements that will never be used.
• Impacts budgets, complexity, development time, …
10
 Classification of the causes of
software errors

2. Client-developer communication failures

• Misunderstanding of instructions in requirements
documentation (written / graphical instructions)
• Misunderstanding of written changes during development.
• Misunderstanding of oral changes during development.
• Lack of attention
• to client messages by developers dealing with requirement
changes and
• to client responses by clients to developer questions

11
 Classification of the causes of
software errors
3. Deliberate deviations from software requirements
• Developer reuses previous / similar work to save time.
• Often reused code needs modification which it may
contain unneeded / unusable extraneous code.
• Due to time or budget pressures, the developer decides
to omit part of the required functions in an attempt to
cope with these pressures.
• Developer inserting unapproved „enhancements‟
(perfective coding; a slick new sort / search….); may
also ignore some seemingly minor features, which
sometimes are quite major.
• Have seen this and it too causes problems and
embarrassment during reviews. 12
Classification of the causes of software
errors
4. Logical design error

13
 Classification of the causes of software errors
4. Logical design errors
• Definitions that represent software requirements by means of erroneous
algorithms.
• Wrong formulas;
• Wrong Decision Logic Tables;
• Incorrect descriptions in text
• Process definitions: procedures specified by systems analyst not accurately
reflecting the real business process
• Note: all errors are not necessarily software errors.
• This seems like a procedural error, and likely not a part of the software
system…But they are errors nonetheless!
• Erroneous Definition of Boundary Condition – a common source of errors
For example, the client‟s requirements stated that a special discount will be
granted to customers who make purchases more than three times in the same
month. The analyst erroneously defined the software process to state that the
discount would be granted to those who make purchases three times or more
in the same month. 14
 Classification of the causes of
software errors
4. Logical design errors
• Omission of required software system states
• For example, a real-time computerized apparatus is
required to react according to a combination of
temperatures and pressures. The analyst did not define the
needed reaction when the temperature is over 120°C and
the pressure is between 6 and 8 atmospheres
• Omission of definitions / procedures concerning reactions to
illegal operation of the software system.
• Including not only code to detect an illegal operation but
failure to design the computer software reaction to
this: Gracefully terminate, sound alarm, etc. ??

15
Classification of the causes of software
errors

5. Coding error

16
Classification of the causes of
software errors
5. Coding errors
• Too many to try to list.
• Syntax errors (grammatical errors)
• Logic errors (program runs; results wrong)
• Run-time errors (crash during execution)

17
 Classification of the causes
of software errors
6. Non-compliance with documentation and coding instructions
• Non-compliance with published templates (formats)
• Non-compliance with coding standards
• (Standards and Integration Branch)
• Size of program;
• Other programs must be able to run in environment!
• Coding: Data Elements and Codes
• Development Procedures: Required documentation
manuals and operating instructions
• SQA Team: testing not only execution software but coding
standards; manuals, messages displayed; resources needed;
resources named (file names, program names,…)
18
 Classification of the causes of
software errors
7. Shortcomings of the Testing Process
• Incomplete test plans leave untreated portions of the software
or the application functions and states of the system.

• Failures to document and report detected errors and faults.

• Failure to promptly correct detected software faults as a result

of in appropriate indications of the reasons for the fault.

• Incomplete correction of detected errors due to negligence or

time pressures.

19
 Classification of the causes of software
errors
8. Procedure errors :User error
User Interface and Procedure errors
• Remember: to the user, the interface is the entire
system.
• If the Interface is unsatisfactory, this view will be
absolutely conveyed „up the line.‟
• The „learnability,‟ and utility of the interface.

20
 Classification of the causes
of software error
9. Documentation Errors
• Errors in the design documents
• If Docs do not represent the implemented design, this is
trouble for subsequent redesign and reuse
• Errors in the documentation in the User Manuals, Operators
Manual, other manuals (Installation…)
• Errors in on-line help, if available.
• Listing of non-existing software functions
• Planned early but dropped; remain in documentation!
• Many error messages are totally meaningless

21
 The 9 causes of software errors
1. Faulty requirements definition
2. Client–developer communication failures
3. Deliberate deviations from software requirements
4. Logical design errors
5. Coding errors
6. Non-compliance with documentation and coding
instructions
7. Shortcomings of the testing process
8. Procedure errors
9. Documentation errors

22
 Software quality

• IEEE definition
– The degree to which a system, component, or
process meets specified requirements.

– The degree to which a system, component, or

process meets customer or user needs or
expectations.

23
 Software quality
• Software quality– Pressman‟s definition
– Conformance to explicitly stated functional and
performance requirements, explicitly documented
development standards, and implicit characteristics
that are expected of all professionally developed
software.

24
Pressman‟s definition suggests three
requirements for quality assurance
1. Specific functional requirements, which refer mainly
to the outputs of the software system.
2. The software quality standards mentioned in the
contract.
3. Good Software Engineering Practices (GSEP),
reflecting state-of-the-art professional practices, to
be met by the developer even though not explicitly
mentioned in the contract.

25
 Software Quality Assurance

• IEEE. Definition.
– A planned and systematic pattern of all actions
necessary to provide adequate confidence that an
item or product conforms to established technical
requirements.
– A set of activities designed to evaluate the process
by which the products are developed or
manufactured. Contrast with quality control.

26
 Expanded SQA. definition

• The IEEE SQA definition

• The relevant ISO 9000-3 sections

• CMM requirements.

CMM: Capability Maturity Model

27
 Example of expanded SQA
Definition
SQA Expanded IEEE SQA Relevant Sections Relevant SEI-CMM
definition definition from ISO9000-3 Requirement

Systematic, + Management -Software quality

planned responsibilities(4.1) management
actions are Quality system (4.2) -Requirement
required Contract review (4.3) management
-Software project
planning
-Software tracking
and oversight

More in table 2.2

28
 Quality Control

• Quality control is defined as

“a set of activities designed to evaluate the
quality of a developed or manufactured
product”

29
The objectives of SQA activities

• Software Development(process-oriented):
1. Assuring an acceptable level of confidence that the
software will conform to functional technical
requirements.

2. Assuring an acceptable level of confidence that the

software will conform to managerial scheduling and
budgetary requirements.

3. Initiating and managing of activities for the

improvement and greater efficiency of software
development and SQA activities.

30
The objectives of SQA activities
• Software maintenance(Product-oriented):
1. Assuring with an acceptable level of confidence that the software
maintenance activities will conform to the functional technical
requirements.

2. Assuring with an acceptable level of confidence that the software

maintenance activities will conform to managerial scheduling and
budgetary requirements.

3. Initiating and managing activities to improve and increase the

efficiency of software maintenance and SQA activities. This
involves improving the prospects of achieving functional and
managerial requirements while reducing costs.

31
 Software Engineering

• The application of a systematic, disciplined,

quantifiable approach to the development,
operation and maintenance of software; that is,
the application of engineering to software.

32
 Assignment
Page 32, 2.3
(1) List and briefly describe the various causes of
software errors.
(2) Classify the causes of error according to the
groups responsible for the error: the client‟s
staff, the systems analysts, the programmers,
the testing staff – or is it a shared responsibility
belonging to more than one group?

33
 Discussion Forum

• Student will lead a discussion and prepare to talk about

the following question in our next class:

Q. Difference between software quality assurance and

software quality control

Read: Page 28, Section 2.5.2

Faculty of Information Science 34