+ incremental development productivity decline ramin moazeni, daniel link

+

Incremental Development Productivity DeclineRamin Moazeni, Daniel Link

Copyright © USC-CSSE

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


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/10th of

the previous one) Not just a bug fix of the previous one (otherwise counted

as part of that one)

10/17/12


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


5+Exploration of IDPD factor Based on experience on several projects, the following

sources of variations have been identified:

10/17/12


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


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


8+Productivity

Conventionally:

In software development:

10/17/12


9+IDPD type characteristics

Software Category Impact on IDPD FactorNon-Deployable Throw-away code. Low Build-Build integration. High

reuse. IDPD factor lowest than any type of deployable/operational software

Infrastructure Software Often the most difficult software. Developed early on in the program. IDPD factor likely to be the highest.

Application Software Builds upon Infrastructure software. Productivity can be increasing, or at least “flat”

Platform Software Developed 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


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


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


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


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


14+Data table

10/17/12


15+KSLOC per increment

1 2 3 4 5 6 7 8 9 100.00

100.00

200.00

300.00

400.00

500.00

600.00

700.00

800.00

KSLOC per increment

KSLOC per increment

10/17/12


16+Overall KSLOC

1 2 3 4 5 6 7 8 9 100.00

500.00

1000.00

1500.00

2000.00

2500.00

3000.00

3500.00

Overall KSLOC

Overall KSLOC

10/17/12


17+IDPD

1 2 3 4 5 6 7 8 9 100.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

f(x) = − 0.0913149406466872 x + 0.958782353522107R² = 0.933383466669323

f(x) = − 0.389065361387689 ln(x) + 1.04421055359457R² = 0.993222034703957

f(x) = 1.36224834013788 x^-0.845539492586527R² = 0.905661305353485

f(x) = 1.24 exp( − 0.215111379616945 x )R² = 1

IDPD

IDPDLinear (IDPD)Logarithmic (IDPD)Power (IDPD)Exponential (IDPD)

10/17/12


18+IDPD factor

1 2 3 4 5 6 7 8 90.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

IDPD factor

IDPD factor

10/17/12


19+Case studies

Project 1 and 2 from “Balancing Agility and Discipline” Quality Management Project

10/17/12


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/12


21+Polynomial trend line

1 2 3 4 5 60.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.900.85

0.820.77

0.36

0.490.57

f(x) = − 0.022977964 x⁵ + 0.396554079 x⁴ − 2.529073855 x³ + 7.321019817 x² − 9.531062091 x + 5.217391865R² = 1

New Development Effort of Project 1

Project 1Polynomial (Project 1)

10/17/12


22+Polynomial trend line (continued)

1 2 3 4 5 60.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.900.85

0.820.77

0.36

0.490.57

f(x) = − 0.022977964 x⁵ + 0.396554079 x⁴ − 2.529073855 x³ + 7.321019817 x² − 9.531062091 x + 5.217391865R² = 1

New Development Effort of Project 1

Project 1Polynomial (Project 1)

10/17/12


23+Comparison of trend lines

1 2 3 4 5 60.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.900.85

0.820.77

0.36

0.490.57

f(x) = − 0.233323799657634 ln(x) + 0.897461002684347R² = 0.60121970237229f(x) = 0.944485752658385 exp( − 0.123525797951032 x )R² = 0.456295793996672

f(x) = 0.914061897692606 x^-0.364416528795911R² = 0.498217635136995

New Development Efforts of Project 1

Project 1Logarithmic (Project 1)Exponential (Project 1)Power (Project 1)

10/17/12


24+Comparison of trend lines (continued)

1 2 3 4 5 6 70.00

0.20

0.40

0.60

0.80

1.00

1.20

1.00

0.78

0.53

0.67

0.14

0.46

0.21

f(x) = − 0.392395212490325 ln(x) + 1.02182953357894R² = 0.773141017610436

f(x) = 1.17495507458855 x^-0.782046399084968R² = 0.568729822334135

f(x) = 1.23928917425827 exp( − 0.251436719196757 x )R² = 0.584999951051066

New Development Efforts of Project 2

Project 2Logarithmic (Project 2)Power (Project 2)Exponential (Project 2)

10/17/12


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 6th build: 548 KSLOC mostly in Java Average staff on project: ~20

10/17/12


26+Comparison of trend lines (continued)

1 2 3 4 5 60.00

50.00

100.00

150.00

200.00

250.00

f(x) = 27.8508440228721 ln(x) + 46.6803834511691R² = 0.0771703791502042f(x) = 49.1113038779603 x^0.174854794383839R² = 0.0218847766565578

f(x) = 40.1241649651105 exp( 0.112527446409893 x )R² = 0.0722457200260016

QMP

QMPLogarithmic (QMP)Power (QMP)Exponential (QMP)

10/17/12


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


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


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


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/12


31+Questions?

10/17/12

+ incremental development productivity decline ramin moazeni, daniel link

Documents