We have derived a simple equation that can be used to more accurately estimate the time needed to implement a set of R software requirements given an average Defect ratio .
The equation results can also be used to adjust the development team work schedule, the number of developers, or the project number of software requirements.
CNIC Information System with Pakdata Cf In Pakistan
The non intuitive impact of software defects on development efforts time estimates
1. The Non-intuitive Impact of Software Defects
on Development Efforts Time Estimates
Copyrights (c) 2011-2013 Pragmatic
1
Cohesion Consulting
2. Motivation
• Many software development projects rely on software
implementation time estimates provided by the
development team to forecast the total duration of a
software implementation effort.
• This presentation takes a rational look at the non-intuitive
impact of software defects on development time estimates.
• We have derived a simple equation that can be used to
more accurately estimate the time needed to implement a
set of R software requirements .
• The equation results can also be used to adjust the
development team work schedule, the number of
developers, or the project number of software
requirements to implement.
Copyrights (c) 2011-2013 Pragmatic
2
Cohesion Consulting
3. Equation Variables
• R = number of requirements that need to be
implemented in the software
• I = mean implementation rate of software
requirements. I unit is in Requirements per time
unit (for example 23 requirements per week)
• D = mean implemented requirements defect
ratio. For example if D=20% then for every 10
implemented requirements, 2 of them are not
properly implemented.
Copyrights (c) 2011-2013 Pragmatic
3
Cohesion Consulting
4. Defect Ratio
• Many factors influence the value of the Defect
ratio such as
– Misunderstanding of requirements from the
designer and/or developer resulting in software
behavior that does not fully fulfill the
requirements
– Errors in software code
• The reader can refer to the Wikipedia article
on software bug for more details.
Copyrights (c) 2011-2013 Pragmatic
4
Cohesion Consulting
5. Defect Ratio
• The Defect ratio we are talking about is an
average value.
• This average (or mean) value can be
determined through historical metrics
gathered by the software development
organization or team over an appropriate
timespan and over a set of past development
efforts.
Copyrights (c) 2011-2013 Pragmatic
5
Cohesion Consulting
6. Defect Ratio
• The Defect ratio can also be determined as the
probability that an implemented requirement
generates a defect at any point in time during
an entire software development project.
• The reader can refer to our SlideShare
presentation “The dynamic interaction of
passed and failed requirements during
software testing” for further details on how to
calculate such probabilities.
Copyrights (c) 2011-2013 Pragmatic
6
Cohesion Consulting
7. The Equation
• T = time needed to implement a set of R
software requirements. It is given by this
equation [E]:
𝑅
𝑇=
𝐼(1 − 𝐷)
Copyrights (c) 2011-2013 Pragmatic
7
Cohesion Consulting
8. Equation Interpretation
• When the defect ratio is D = 0 then the time
needed to implement R software requirements is:
𝑅
𝑇=
𝐼
• “I (1-D)” represents an adjusted Implementation
rate that decreases in direct proportion to the
defect ratio. It captures the effect of rework
efforts that slow down production throughput.
• As the defect ratio varies from 0 to 1 , the time
needed to implement the set of R software
requirements increases in a non-linear way.
Copyrights (c) 2011-2013 Pragmatic
8
Cohesion Consulting
9. Equation Illustration
• Assume that R=100 requirements need to be
implemented at a rate I=10 requirements per
week
• The chart of T (time needed to implement the
100 requirements) as a function of D
(implemented requirements defect ratio) is
presented on the next slide
Copyrights (c) 2011-2013 Pragmatic
9
Cohesion Consulting
11. Equation Illustration
• In this example, when D=0 it takes 10 weeks
to implement the 100 requirements. This is
the common way of estimating
implementation time where defects rework is
not taken into account.
• Equation [E] explicitly incorporates the impact
of defects on the total time needed for
implementing the set of R requirements.
Copyrights (c) 2011-2013 Pragmatic
11
Cohesion Consulting
12. Non-intuitive Impact of Defects
• With a 20% Defect ratio, the implementation
time of the 100 requirements goes from 10
weeks to 12.5 weeks which is a 25% increase.
• A 30% Defect ratio results in 42% increase in
implementation time: T goes from 10 weeks
to 14.2 weeks!
• A 50% defect ratio results in 100% increase in
implementation time: T goes from 10 weeks
to 20 weeks!
Copyrights (c) 2011-2013 Pragmatic
12
Cohesion Consulting
13. Impact of High Defect Ratios
• As the Defect ratio approaches 100%, the
Implementation time grows at a faster rate
towards infinity.
• This behavior can be intuitively understood if one
considers that with 100% defect nothing gets
properly implemented and every requirement
needs to be re-implemented over and over again
leading to an infinite implementation time.
• What is not so easily understood is the non-linear
increasing rate of growth in Implementation time
as the Defect ratio increases.
Copyrights (c) 2011-2013 Pragmatic
13
Cohesion Consulting
14. Impact on Software Requirements
Implementation Rate
• Lets examine again the case where the Defect
ratio is D=0%. It would take 10 weeks to
implement the 100 requirements at a rate of 10
requirements/week.
• If the defect ratio is actually 30%, it now takes
14.2 weeks to implement the 100 requirements.
To implement the 100 requirements in the initial
10 weeks, the Implementation rate must
increase. Using [E]:
T = 10 = 100/(I x (1-0.3)
I = 100/(10 x 0.7) = 14.2 requirements/week
Copyrights (c) 2011-2013 Pragmatic
14
Cohesion Consulting
15. Impact on Software Requirements
Implementation Rate
• An implementation rate of I = 14.2
requirements/week can be obtained in several
ways:
– If the development team remains the same size,
then we must increase its weekly hours by 42%
– If weekly hours cannot be increased then we must
increase the size of the development team by
42%, so if we had initially 5 developers we now
need 2 more developers to have 7 developers!
Copyrights (c) 2011-2013 Pragmatic
15
Cohesion Consulting
16. Impact on Software Requirements Size
• With the Defect ratio D=30%, if we had to
keep the same development team size, the
same implementation rate, and the same
implementation time, then we must reduce
the number of requirements from 100 to:
T = 10 = R /(10 x (1-0.3)
R = 10 x 10 x 0.7 = 70 Requirements!
Copyrights (c) 2011-2013 Pragmatic
16
Cohesion Consulting
17. For Comments and Questions contact didier@pragmaticohesion.com
Copyrights (c) 2011-2013 Pragmatic
17
Cohesion Consulting