1. + Incremental Development Productivity Decline Ramin Moazeni, Daniel Link

2. + Introduction Incremental development is the most common development paradigm these days Reduces risks by allowing flexibility per increment Incremental Development Productivity Decline (IDPD) Based on our logical considerations and industry data, we believe there is generally a decrease in productivity between increments The decline is due to factors such as previous-increment breakage and usage feedback, increased integration and testing effort. 10/17/12 2 Copyright © USC-CSSE

3. + Incremental Development - Definition Any development effort with: More than one step More than one released build Each steps build on previous ones and would not be able to stand alone without the steps that came before it Increments have to Contribute a significant amount of new functionality Add a significant amount of size (not less than 1/10 th of the previous one) Not just a bug fix of the previous one (otherwise counted as part of that one) 10/17/12 3 Copyright © USC-CSSE

4. + Effects of IDPD on Number of Increments Model relating productivity decline to number of builds needed to reach 8M SLOC Full Operational Capability Assume Build 1 production of 2M SLOC @100 SLOC/PM 20000 PM/24mo. = 833 developers Constant Staff size for all builds 10/17/12 4 Copyright © USC-CSSE

5. + Exploration of IDPD factor Based on experience on several projects, the following sources of variations have been identified: 10/17/12 5 Copyright © USC-CSSE

6. + Cost estimation for incremental development Closed ended incremental projects (time limited or number of increments) Open ended incremental projects Two interests: Cost of all increments at start of project Important for decision whether to go ahead with project A priori, therefore imprecise Cost of the next increment Refined, more precise 10/17/12 6 Copyright © USC-CSSE

7. + Cost estimation for incremental development (continued) Average decline factor of productivity would be good for both types of estimation May vary for different categories of projects 10/17/12 7 Copyright © USC-CSSE

8. + Productivity Conventionally: In software development: 10/17/12 8 Copyright © USC-CSSE

9. + IDPD type characteristics Software CategoryImpact on IDPD Factor Non-DeployableThrow-away code. Low Build-Build integration. High reuse. IDPD factor lowest than any type of deployable/operational software Infrastructure SoftwareOften the most difficult software. Developed early on in the program. IDPD factor likely to be the highest. Application SoftwareBuilds upon Infrastructure software. Productivity can be increasing, or at least “flat” Platform SoftwareDeveloped by HW manufacturers. Single vendor, experienced staff in a single controlled environment. Integration effort is primarily with HW. IDPD will be lower due to the benefits mentioned above. Firmware (Single Build) IDPD factor not applicable. Single build increment. 10/17/12 9 Copyright © USC-CSSE

10. + Research Hypotheses 1) There is a decline in productivity over increments For typical cases Floor may be reached, after which it rises again Methods to prove Mathematically Data from experience/history Controlled experiments 2) Decline varies by domain Can be proven by statistics (ANOVA) 10/17/12 10 Copyright © USC-CSSE

11. + Definitions Build All the code written up to a release Increment Only the code written between one build and the next Any line of code is written for a given increment 10/17/12 11 Copyright © USC-CSSE

12. + Example based on ideal data 100 KSLOC per increment DM: 24% CM: 24% IM: 24% EAF: 1.00 No code from external sources 10/17/12 12 Copyright © USC-CSSE

13. + The model EKSLOC (I) = KSLOC (I-1) * (0.4*DM + 0.3*CM + 0.3*IM) EKSLOC(I) is based on what is adapted and reused from the previous increment NKSLOC(I) is the new code written for increment I KSLOC(I) = EKSLOC(I)+NKSLOC(I) IDPD(I)= NKSLOC(I)/KSLOC(I) (Cost drivers were considered but behavioral analysis was not possible with captured data. Will eventually be added when good data available. For the time being EAF=1.00) 10/17/12 13 Copyright © USC-CSSE

14. + Data table 10/17/12 14 Copyright © USC-CSSE

15. + KSLOC per increment 10/17/12 15 Copyright © USC-CSSE

16. + Overall KSLOC 10/17/12 16 Copyright © USC-CSSE

17. + IDPD 10/17/12 17 Copyright © USC-CSSE

18. + IDPD factor 10/17/12 18 Copyright © USC-CSSE

19. + Case studies Project 1 and 2 from “Balancing Agility and Discipline” Quality Management Project 10/17/12 19 Copyright © USC-CSSE

20. + Projects 1 and 2 Two web based client–sever systems developed in Java Data mining systems Agile process similar to XP with several short iteration cycles and customer-supplied stories Productivity as new SLOC per user story Assumption: Every user story takes the same time to implement. 10/17/12Copyright © USC-CSSE 20

21. + Polynomial trend line 10/17/12 21 Copyright © USC-CSSE

22. + Polynomial trend line (continued) 10/17/12 22 Copyright © USC-CSSE

23. + Comparison of trend lines 10/17/12 23 Copyright © USC-CSSE

24. + Comparison of trend lines (continued) 10/17/12 24 Copyright © USC-CSSE

25. + Quality Management Platform (QMP) Project QMP Project Information: Web-based application System is to facilitate the process improvement initiatives in many small and medium software organizations 6 builds, 6 years, different increment duration Size after 6 th build: 548 KSLOC mostly in Java Average staff on project: ~20 10/17/12 25 Copyright © USC-CSSE

26. + Comparison of trend lines (continued) 10/17/12 26 Copyright © USC-CSSE

27. + Trend line summary Logarithmic is best fit in all observed real-world cases Trend line alone is not enough for reasonably precise prediction of effort for next increment => Additional predictors needed 10/17/12 27 Copyright © USC-CSSE

28. + Conclusions and outlook More data with detailed back stories needs to be collected Controlled experiment Use IDPD model to extend COCOMO II Expert judgments / workshops 10/17/12 28 Copyright © USC-CSSE

29. + Workshop Causes of IDPD Individual experiences Does code from older increments typically need less or more effort for adaptation and reuse than the code from more recent increments? Is there a point at which code from an old increment needs no more modification? (e.g. Berkeley sockets) Which cost drivers are appropriate? What would a complete model look like? 10/17/12 29 Copyright © USC-CSSE

30. + Hofstadter's law Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. — Douglas Hofstadter 10/17/12Copyright © USC-CSSE 30

31. + Questions? 10/17/12 31 Copyright © USC-CSSE