+
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.
Copyright © USC-CSSE
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)
Copyright © USC-CSSE
10/17/12
+
4
Effects of IDPD on
Number of Increments
Copyright © USC-CSSE

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:
Copyright © USC-CSSE
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
Copyright © USC-CSSE
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
Copyright © USC-CSSE
10/17/12
+
8
Productivity

Conventionally:

In software development:
Copyright © USC-CSSE
10/17/12
+
9
IDPD type characteristics
Software Category
Impact on IDPD Factor
Non-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.
Copyright © USC-CSSE
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)
Copyright © USC-CSSE
10/17/12
+
11
Definitions

Build


Increment


All the code written up to a release
Only the code written between one build and the next
Any line of code is written for a given increment
Copyright © USC-CSSE
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
Copyright © USC-CSSE
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)
Copyright © USC-CSSE
10/17/12
+
14
Data table
Copyright © USC-CSSE
10/17/12
+
15
KSLOC per increment
KSLOC per increment
800.00
700.00
600.00
500.00
400.00
KSLOC per increment
300.00
200.00
100.00
0.00
1
Copyright © USC-CSSE
2
3
4
5
6
7
8
9
10
10/17/12
+
16
Overall KSLOC
Overall KSLOC
3500.00
3000.00
2500.00
2000.00
Overall KSLOC
1500.00
1000.00
500.00
0.00
1
Copyright © USC-CSSE
2
3
4
5
6
7
8
9
10
10/17/12
+
17
IDPD
IDPD
160.00%
y = -0.389ln(x) + 1.0442
R² = 0.9932
140.00%
120.00%
y = -0.0913x + 0.9588
R² = 0.9334
100.00%
IDPD
Linear (IDPD)
80.00%
Log. (IDPD)
Power (IDPD)
60.00%
Expon. (IDPD)
y = 1.24e-0.215x
R² = 1
40.00%
y = 1.3622x-0.846
R² = 0.9057
20.00%
0.00%
1
Copyright © USC-CSSE
2
3
4
5
6
7
8
9
10
10/17/12
+
18
IDPD factor
IDPD factor
0.90
0.80
0.70
0.60
0.50
IDPD factor
0.40
0.30
0.20
0.10
0.00
1
Copyright © USC-CSSE
2
3
4
5
6
7
8
9
10/17/12
+
19
Case studies

Project 1 and 2 from “Balancing Agility and Discipline”

Quality Management Project
Copyright © USC-CSSE
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.
Copyright © USC-CSSE
10/17/12
+
21
Polynomial trend line
New Development Effort of Project 1
1.00
0.90
0.85
0.82
0.80
0.77
0.70
0.60
0.57
0.50
Project 1
0.49
Poly. (Project 1)
0.40
0.36
0.30
y = -0.023x5 + 0.3966x4 - 2.5291x3 + 7.321x2 - 9.5311x + 5.2174
R² = 1
0.20
0.10
0.00
1
Copyright © USC-CSSE
2
3
4
5
6
10/17/12
+
22
Polynomial trend line (continued)
New Development Effort of Project 1
2.00
1.00
0.85
0.82
0.77
0.57
0.49
0.36
0.00
1
2
3
4
5
6
-1.00
7
Project 1
Poly. (Project 1)
-2.00
-3.00
-4.00
y = -0.023x5 + 0.3966x4 - 2.5291x3 + 7.321x2 - 9.5311x + 5.2174
R² = 1
-5.00
Copyright © USC-CSSE
10/17/12
+
23
Comparison of trend lines
New Development Efforts of Project 1
1.00
0.90
0.85
0.82
0.80
0.77
0.70
0.60
0.57
0.50
Project 1
Log. (Project 1)
0.49
Expon. (Project 1)
0.40
Power (Project 1)
0.36
0.30
y = -0.233ln(x) + 0.8975
R² = 0.6012
0.20
0.10
0.00
1
Copyright © USC-CSSE
2
3
4
y = 0.9141x-0.364
R² = 0.4982
y = 0.9445e-0.124x
R² = 0.4563
5
6
10/17/12
+
24
Comparison of trend lines
(continued)
New Development Efforts of Project 2
1.40
y = -0.392ln(x) + 1.0218
R² = 0.7731
1.20
1.00
y = 1.2393e-0.251x
R² = 0.585
1.00
0.80
y = 1.175x-0.782
R² = 0.5687
0.78
Project 2
Log. (Project 2)
0.67
Power (Project 2)
0.60
0.53
Expon. (Project 2)
0.46
0.40
0.21
0.20
0.14
0.00
1
Copyright © USC-CSSE
2
3
4
5
6
7
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
Copyright © USC-CSSE
10/17/12
+
26
Comparison of trend lines
(continued)
QMP
250.00
y = 27.851ln(x) + 46.68
R² = 0.0772
200.00
y = 40.124e0.1125x
R² = 0.0722
150.00
QMP
Log. (QMP)
Power (QMP)
100.00
Expon. (QMP)
50.00
y = 49.111x0.1749
R² = 0.0219
0.00
1
Copyright © USC-CSSE
2
3
4
5
6
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
Copyright © USC-CSSE
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
Copyright © USC-CSSE
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?
Copyright © USC-CSSE
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
Copyright © USC-CSSE
10/17/12
+
31
Questions?
Copyright © USC-CSSE
10/17/12