Presentation on theme: "SENG521 (Fall SENG 521 Software Reliability & Testing Defining Necessary Reliability (Part 3b) Department of Electrical & Computer."— Presentation transcript:
SENG521 (Fall 2002)email@example.com SENG 521 Software Reliability & Testing Defining Necessary Reliability (Part 3b) Department of Electrical & Computer Engineering, University of Calgary B.H. Far （ firstname.lastname@example.org ） http://www.enel.ucalgary.ca/~far/Lectures/SENG521/03b/
SENG521 (Fall 2002)email@example.com 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 2002)firstname.lastname@example.org 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 2002)email@example.com 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
SENG521 (Fall 2002)firstname.lastname@example.org 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 2002)email@example.com 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 2002)firstname.lastname@example.org 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 2002)email@example.com 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 2002)firstname.lastname@example.org 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.
SENG521 (Fall 2002)email@example.com 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 2002)firstname.lastname@example.org 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 2002)email@example.com 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.