0% found this document useful (0 votes)
32 views16 pages

Defect Rate and Reliability: Defect Rate: Define As The Number of Defects Per

The document discusses defect rate, software reliability, availability, and prevention. It defines defect rate as the number of defects per thousand lines of code in a given time period. Reliability is the probability of failure-free operation over a specified time. Availability is the probability a program is operating as required at a given time. Defect prevention involves analyzing defects to identify root causes, suggesting preventive actions, and implementing them through causal analysis meetings, an action team, stage kickoff meetings, and action tracking.

Uploaded by

gau_1119
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
32 views16 pages

Defect Rate and Reliability: Defect Rate: Define As The Number of Defects Per

The document discusses defect rate, software reliability, availability, and prevention. It defines defect rate as the number of defects per thousand lines of code in a given time period. Reliability is the probability of failure-free operation over a specified time. Availability is the probability a program is operating as required at a given time. Defect prevention involves analyzing defects to identify root causes, suggesting preventive actions, and implementing them through causal analysis meetings, an action team, stage kickoff meetings, and action tracking.

Uploaded by

gau_1119
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 16

Defect Rate and Reliability

Defect Rate: Define as the number of defects per


thousand source lines of code or per thousand lines of
code (KLOC or KSLOC) in a given unit of time.

Example: One year after the general availability of the


product in the market place.

Alternatively defect rate can be define as

Defect rate = (Number of defects/OFE) *k.


Where,
OFE= Opportunities for error(Known as risk exposure)
K= Is a constant usually 1,000.
Software Reliability
 The probability of failure free operation of a
computer program in a specified environment for a
specified time.

Example:
Suppose a program X is estimated to have a
reliability of 0.96 over eight elapsed processing
hours.
Continue..
 If the program X is to be executed 100 times.
and required a total of eight hours of elapsed processing
time.
It is likely to operate correctly (without failure) 96 times.

 A simple measure of reliability is mean-time-


between-failure (MTBF).
MTBF= MTTF+MTTR
Where, MTTF= Mean-time-to-failure (Is an inverse of
failure rate)
MTTR=Mean-time-to-repair.
Continue…
Prob: A company manufacture resistors that are known to
have an failure rate of 0.15% per 1,000 hours. Find the
MTTF for the resistor.

Solu: Failure rate= 0.15% per 1,000 hours.


= 0.15%/1000
= 0.0000015.

Therefore MTTF = 1/0.0000015


= 666,667 hours.
Software Availability

 Software availability is the probability that a


program is operating according to the requirements at
a given point in time.

Availability= [MTTF/(MTTF+MTTR)]*100%
Defect Prevention
 It is a process to continually improve the development
process.
 It is a real time process, integrated into every stage of the
development process.

 Defect prevention is based on three simple steps.


a) Analyze defects or errors to trace the root causes.
b) Suggest preventive actions to eliminate the
defect root causes.
c) Implement the preventive actions
Continue….
Defect prevention process used by the IBM
communication programming laboratory consist of
the following four key elements.

 Causal analysis meeting:


 Usually two-hour brainstorming session conducted by
technical teams at the end of each stage of the
development process.
 Developers analyze defects that occurred in the stage,
trace the root causes of the error, and suggest possible
actions to prevent similar errors from recurring.
Continue..
 Methods for removing similar defects in a current
product are also discuss.

 After the meeting, the causal analysis leader records


the data (Defect cause and suggested action) in an
action database for subsequent reporting and tracking.
 Action team:
 The action team is responsible for screening,
prioritizing, and implementing suggested actions
from causal analysis meeting.
Continue..
 The team uses reports from the action database to
guide its meeting.

 Other than implementation, the team is involve in


feedback to the organization, report to the
management on the status of its activities and taking
the lead in various aspects of the process.
Continue..
 Stage kickoff meeting:
 Conducted at the beginning of the development
process by the technical team.
 The emphasis on the technical aspect of the
development process and on quantity.

What is the right product?


How do we thinks more effectively?
What are the tools and methods that can help?
Continue…
 Action tracking and data collection:
 To prevent suggestions from being lost over
time.

 To add action implementation, and to enhance


communication among groups.
Continue…

 DPP can be applied to any development process i.e.


waterfall, prototyping, iterative and spiral.

 As long as the defects are recorded, casual analysis


can be performed and preventive actions mapped and
implemented.
Example of defect prevention
process to the middle segment
of waterfall model.

You might also like