SENG521 (Fall SENG 521 Software Reliability & Testing Defining Necessary Reliability (Part 3b) Department of Electrical & Computer Engineering, University of Calgary B.H. Far （ ）

SENG521 (Fall Necessary Reliability: How to 1)Define failure with “failure severity classes (FSC)” for the product. 2)Choose a common measure for all associated systems (natural or time unit). 3)Set a “failure intensity objective (FIO)” for each system to be tested. 4)Find the developed software failure intensity objective. 5)Engineer strategies to meet the software failure intensity objective.

SENG521 (Fall 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.

SENG521 (Fall 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 for 8 hours, λ=0.001 or 1 failure for 1000 hours

SENG521 (Fall 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.

SENG521 (Fall 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.

SENG521 (Fall Computing Developed FIO Example: 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

SENG521 (Fall 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

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

SENG521 (Fall 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.

SENG521 (Fall 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.

SENG521 (Fall 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.