the non intuitive impact of software defects on development efforts time estimates

The Non-intuitive Impact of Software Defects on Development Efforts Time Estimates

Copyrights (c) 2011-2013 Pragmatic Cohesion Consulting

1

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.


2

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.


3

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.


4

http://en.wikipedia.org/wiki/Software_bug

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.


5

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.


6

http://www.slideshare.net/adidierk/the-dynamic-interaction-of-passed-and-failed-requirements-during-software-testing



The Equation

• T = time needed to implement a set of R software requirements. It is given by this equation [E]:

𝑇 = 𝑅

𝐼(1 − 𝐷)


7

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.


8

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


9

Equation Chart


10

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.


11

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

Cohesion Consulting 12

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.


13

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



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!



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!


16


17

For Comments and Questions contact [email protected]

the non intuitive impact of software defects on development efforts time estimates

Technology

defect ratio results

number of requirements

requirements defectratio

defect ratio increases

the100 requirements

requirements perweek

set of r requirements

set of rsoftware requirements