The non intuitive impact of software defects on development efforts time estimates
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 645 views
Uploaded on

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 . ...

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
645
On Slideshare
623
From Embeds
22
Number of Embeds
2

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 22

http://www.linkedin.com 15
http://pragmaticohesion.com 7

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 10. Equation Chart Copyrights (c) 2011-2013 Pragmatic 10 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