Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The missing links in software estimation: Work, Team Loading and Team Power


Published on

This presentation investigates the theoretical foundation of the basic concepts used in software effort estimation, productivity measurement and benchmarking. By elaborating on how similar concepts are defined and used in well-established engineering fields, we aim to shed light on some inconsistent and fallacious use of concepts and units of measure, resulting misconceptions and their consequences in project planning. Particularly, we focus on ‘Work’, ‘Team Power’ and ‘Team Loading’, analyzing the way many studies from the ‘70s on faced such issue. Too often projects fail for being late and not always adding new resources allows respecting established milestones as well as the established quality levels. After setting the theoretical layout, we present the results of an empirical investigation we made using the data in the International Software Benchmarking Standards Group (ISBSG) dataset D&E (Development & Enhancement) v13, using both COSMIC and IFPUG data for Business and Real-Time applications. The results indicate that a considerable number of projects might have been poorly planned and utilized human resources inefficiently, and hence paid much higher costs. Hence, we suggest software companies to revisit the productivity data of the past projects as well as evaluating the new ones by measuring Team Power, Team Loading and comparing to Team Size utilized.

Published in: Software
  • Be the first to comment

  • Be the first to like this

The missing links in software estimation: Work, Team Loading and Team Power

  1. 1. The Missing Links in Software Estimation: Work, Team Loading and Team Power Luigi Buglione Engineering.IT (Italy) Çiğdem Gencel Free University of Bozen-Bolzano (Italy) IWSM -MENSURA,5-7October2016,Berlin
  2. 2. 2 Software Estimation Problem Fundamental Concepts: • Energy & Work • Team Loading • Team Power Implications to Understanding and Theory Development Empirical Investigations Conclusions
  3. 3. Software Effort Estimation – State of the Art 3 Effort Estimation Methods Parametric Empirically based Statistical Analysis Theory based Non- parametric Expert based Informal Analogy Structured Analogy Learning based Case Based Reasoning Neural Networks Fuzzy Logic Composite
  4. 4. Concepts Revisited: Energy & Work •  In physics, potential energy is defined as ‘the capacity of something to do work’ •  In SE, it can be defined as the team’s cumulative intellectual work capacity within a development environment for developing a piece of software during a period of time. 4
  5. 5. Transformation of Energy 5 •  The law of the conservation of energy says: •  Energy can be transformed from one form to another
  6. 6. Transformation of Energy in Software Development 6 Team Time Scope Quality Work Input Work Output Wastes
  7. 7. 7 •  Wintput is the ‘work capacity of a software team’ that is input in a project •  WOutput corresponds to ‘valuable work’ that produces a piece of software with some characteristics: •  Productivity of software development is denoted as: !!"#$"# = !(!"#$%&'#()&%*, !"#$%&'()*, !"#$%&') !"#$%&'()('* (!) = !!"#$"# !!"#$% Concepts Revisited: Efficiency (Productivity)
  8. 8. •  Any waste in development would decrease productivity. •  Many studies investigated the factors affecting Woutput and hence Productivity: •  Team factors, •  Process factors •  Project related factors •  … •  This presentation instead focuses on clarification of concepts and laying the foundations •  In particular we investigated TeamPower and Team Loading concepts 8 Concepts Revisited: Efficiency (Productivity)
  9. 9. In physics, Power (P) is defined as “the rate of doing work (or similarly, rate which energy is transferred)”. The term “horsepower” was introduced by James Watt; famous for his work on improving the performance of steam engines Concepts Revisited: Power
  10. 10. •  The power of a system may stay constant or change over time. •  Therefore, power is usually expressed in three ways: •  Instantaneous Power, which is the power measured at a given instant in time; •  Peak Power, which corresponds to is the maximum value the instantaneous power can have over a period of time; •  Average Power, which is the amount of work done divided by the time interval that it took to do the work. •  One way to calculate this is to find the area under the power versus time curve (which gives the total work done) and divide by the total time. 10 Concepts Revisited: Power
  11. 11. •  In software engineering, we can define ‘TeamPower’ for expressing the rate of doing work (or rate of transferring their intellectual energy to produce a piece of software). •  This measure is commonly referred to as Speed or Speed of Delivery in software engineering! !"#$%&# !"#$ !"#$% = !!"#!"# !"#$ Concepts Revisited: Team Power
  12. 12. Concepts Revisited: Team Loading •  On the other hand, WInput is dynamic and changes during the life cycle depending on: •  the project requirements and constraints, •  how management schedules software engineering tasks and allocates people to these tasks. •  Hence, there is another important concept: 12 !"#$%&# !"#$ !"#$%&' = !!"!"# !"#$
  13. 13. Transformation of Energy in Software Development 13 WInput / Time Wastes WOutput / Time Team Loading Team Power
  14. 14. Concepts Revisited: Terms & Units Inconsistencies •  In SE, even though a similar term ‘manpower’ has been used, the inconsistent and sometimes fallacious use of the term resulted in consequent misconceptions. •  Norden referred to Team Loading as ‘Manpower loading (man- months/year)’. •  Putnam refers to the term several times but with inconsistent use of the term as well as the units of measure (e.g. Manpower (people/ year), Manpower (man-months) and Cumulative effort (total people)) •  The ISBSG introduced another measure called ‘Manpower delivery rate (size/time x max team size)’ which is claimed to provide a measure of Speed but also including the Team size. 14
  15. 15. 16 Team Loading during Development
  16. 16. •  Brooks stated that estimating techniques fallaciously confuse work effort with progress by hiding the assumption that men and months are interchangeable. •  He then explained that this is only possible when a task can be partitioned among many workers with no communication among them. •  His hypotheses were brilliant, and therefore have gained considerable attention by the community. Core concepts revisited Some Important Misconceptions Fred Brooks: Adding manpower to a late software project makes it later
  17. 17. Fred Brooks: Adding manpower to a late software project makes it later Team Loading was expressed in a unit of number of people, referring to the number of people working in the team.
  18. 18. 19Steven KareemJim AThought Experiment
  19. 19. The Relationship between Team Loading, TeamPower and Productivity 20 Productivity (Woutput/Winput) α α •  How is it possible to increase the rate of work: Avg. Team Power?
  20. 20. We investigated the nature of the relationship between Avg Team Loading and Avg. Team Size using the ISBSG dataset •  We prepared the data for analysis as follows: ü  Data Quality Rating (DQR): A or B Rating ü  Business Applications ü  New Development ü  Recording method: Person-hrs ü  Resource Level: 1 ü  Ratio of Project Work Effort to Non-Project Activity: projects that have 90-100% ü  Normalized Work Effort (person-hrs) used ü  The project duration is calculated by subtracting project inactive time from the total duration (1 month = 120 hrs). Empirical Investigations – ISBSG dataset
  21. 21. 22 Empirical Investigation - COSMIC •  Project sizes: 11-966 CFP (most below 300 CFP) •  Avg. Team Loading for some projects are much higher than Avg. Team Size •  Avg. Team Loading in some cases below 1 person!
  22. 22. 23 Empirical Investigation - IFPUG •  Project sizes: 34-4887 IFPUG FP (most below 2000 FP) •  Avg. Team Loading for some projects are much lower than Avg. Team Size •  Avg. Team Loading in some cases below 1 person
  23. 23. •  Consistent use of concepts and terms are very important in knowledge and theory development in SE •  Benchmark datasets should include both Productivity and Avg Team Power figures in addition to Avg. Team Size for better understanding and fair comparisons •  The empirical investigations of this study indicate: •  Some theoretical reasons of high variations in productivity figures •  Reveal poor planning practices •  Research need for best ways to increase Team Loading (e.g. overtime/time-shifts by distributing work globally etc. ) Conclusions