SENG 521 Software Reliability

1
SENG 521Software Reliability Testing

• Defining Necessary Reliability
• (Part 3b)

Department of Electrical Computer Engineering,
University of Calgary B.H. Far (far_at_enel.ucalgary.
ca) http//www.enel.ucalgary.ca/far/Lectures/SENG
521/03b/
2
Necessary Reliability How to

• Define failure with failure severity classes
  (FSC) for the product.
• Choose a common measure for all associated
  systems (natural or time unit).
• Set a failure intensity objective (FIO) for
  each system to be tested.
• Find the developed software failure intensity
  objective.
• Engineer strategies to meet the software failure
  intensity objective.

3
How to Define FSC

• Mainly experience based.
• List all factors that may be considered as
  failure severity for the project
• Narrow the list down to the most critical and/or
  measurable ones
• Some factors may be hard to measure, such as
  impact on company reputation, etc.

4
How to Set FIO /1

• Setting FIO in terms of system reliability (R)
• ? is failure intensity
• R is reliability
• t is natural unit (time, etc.)
• If reliability (R) is around 0.992 for 8 hours,
  ?0.001 or 1 failure for 1000 hours

5
How to Set FIO /2

• Setting FIO in terms of system availability (A)
• ? is failure intensity
• is downtime per failure
• If a product must be available 99 of time and
  downtime is 6 min, then FIO is about 0.1 per hour.

6
FIO for Developed Product

• Find the developed software failure intensity
  objective
• Find expected failure intensity for acquired
  components.
• Compute software failure intensity for developed
  components.

7
Computing Developed FIO

• Example
• System failure intensity objective
• 100 failure/1,000,000 transactions
• Failure intensity for hardware
• 0.1 failure/hour
• OS failure for a load of 100,000 transactions
• 0.4 failure/hour
• Therefore, developed software FIO
• 95 failure/1,000,000 transactions

8
Strategies to Meet FIO

• Engineer strategies to meet the software failure
  intensity objective for the developed software.
• 4 main strategies
• Fault prevention
• Fault removal
• Fault tolerance
• Fault/failure forecasting

9
Fault Prevention

• To avoid fault occurrences by construction.
• Activities
• Requirement review
• Design review
• Clear code
• Establishing standards (ISO 9000-3, etc.)
• Using CASE tools with built-in check mechanisms
• Effectiveness factor
• Proportion of the faults remaining after
  prevention activities.

10
Fault Removal

• To detect, by verification and validation, the
  existence of faults and eliminate them.
• Activities
• Code review
• test
• Effectiveness factor
• Reduction of failure intensity due to code
  review.
• Ratio of failure intensity after test and before
  test.

11
Fault Tolerance

• To provide, by redundancy, service complying with
  the specification in spite of faults occurrences.
• Activities
• Designing and implementing redundancy
• Effectiveness factor
• Reduction of failure intensity as a result of
  redundant design.

12
Fault/Failure Forecasting

• To estimate, by evaluation, the presence of
  faults and the occurrences of failures.
• Activities
• Establishing reliability model
• Collecting failure data
• Analysis and interpretation of results
• Effectiveness factor
• Reduction of failure intensity as a result of
  applying reliability engineering.