1. Incremental Development Productivity Decline (IDPD) in Software Development
Center for Software and Systems Engineering,
Annual Research Review March 2012
Ramin Moazeni– Ph.D. Student
Computer Science Department
Viterbi School of Engineering
University of Southern California

2. Outline Incremental Development Productivity Decline (IDPD) Overview
Relevant Examples
Cost Drivers
Effect on number of increments

3. Incremental Development Productivity Decline (IDPD)
Overview
The “Incremental Productivity Decline” (IDPD) factor represents the percentage of decline in software producibility from one increment to the next.
The decline is due to factors such as previous-increment breakage and usage feedback, increased integration and testing effort.
Another source of productivity decline is that maintenance of reused previous build software is not based on equivalent lines of software credited during the previous build, but on the full amount of reused software.
Build 1: 200 KSLOC new, 200K yields a
240 K ESLOC “count” for estimation models.
Build 2: there are 400 KSLOC of Build 1 to maintain and integrate
Such phenomena may cause the IDPD factor to be higher for some builds and lower for others.

4. Incremental Development Productivity Decline (IDPD)
Example: Site Defense BMD Software
5 builds, 7 years, $100M
Build 1 productivity over 300 SLOC/person month
Build 5 productivity under 150 SLOC/person month
Including Build 1-4 breakage, integration, rework
318% change in requirements across all builds
A factor of 2 decrease across 4 builds corresponds to an average build to build IDPD factor of 20% productivity decrease per build
Similar IDPD factors have been found for:
Large commercial software such as multi-year slippage in delivery of MS Word for Windows and Windows Vista.

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

6. Quality Management Platform (QMP) Project
Data Collection
Most data come from release documentation, build reports, and project member interviews/surveys
Data include product size, effort by engineering phase, effort by engineering activities, defects by phase, requirements changes, project schedule, COCOMO II driver ratings (rated by project developers and organization experts)
Data collection challenges:
Incomplete and inconsistency data
Different data format, depends on who filled the data report
No system architecture documents available

7. Productivity (SLOC/PH) Productivity Variance
Quality Management Platform (QMP) Project Data Analysis – Productivity Trends
Build
Size (KSLOC)
Effort (PH)
Productivity (SLOC/PH)
Productivity Variance 1
69.12
7195
9.61
0.0% 2 64
9080
7.05
-26.6% 3 19
6647
2.86
-59.4% 4
39.2
8787.5
4.46
56.1% 5
207
6.53
46.5% 6 65
4.01
-38.6%
Table 1
The slope of the trend line is SLOC/PH per build
Across the five builds, this corresponds to a 14% average decline in productivity per build. This is smaller than the 20% Incremental Development Productivity Decline (IDPD) factor observed for a large defense program
Most likely because the project is considerably smaller in system size and complexity

8. Causes of IDPD Factor
Explorations of the IDPD factors on several projects, the following sources of variation were identified:
Higher IDPD (Less Productive)
Lower IDPD (More Productive)
Effort to maintain previous increment; bug fixing, COTS upgrades, interface changes
Next increment requires previous increment modification
Next increment spun out to more platforms
Next increment has more previous increments to integrate/interact with
Next increment touches less of the previous increment
Staff turn over reduces experience
Current staff more experienced, productive
Next increment software more complex
Next increment software less complex
Previous increment incompletely developed, tested, integrated
Previous increment did much of the next increment’s requirements, architecture

9. Software Categories & IDPD Factor
Categorization of different type of software with different productivity curves through multiple build cycles, require different IDPD factors applicable to each class of software.
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.

10. IDPD Model & Data Definition
Based on analysis of the IDPD effects, the next increment’s ESLOC, IDPD factor, and software effort can be estimated
KSLOC (I) in the existing increments 1 through I
The fraction F of these are going to be modified
The previous increments (I) would then be considered as reused software and their equivalent lines of code calculated as
EAF (I+1): EAF factor for the next increment’s development EAF (I+1) would be the EAF (I) adjusted by the product of Delphi-TBD effort multipliers for the following IDPD factors: 
IDPD Drivers
Description
RCPLX
Complexity of Increment I+1 relative to complexity of existing software
IPCON
Staff turnover from previous increment’s staff
PRELY
Previous increments’ required reliability
IRESL
Architecture and risk resolution (RESL) rating of I+1 relative to RESL of 1..I

11. IDPD Model & Data Definition - 2
The total EKSLOC(I+1) = EKSLOC (I) + EKSLOC (I+1 Added) and the EAF (I+1) factor would be used in the standard COCOMO II equations to compute PM (I+1).
The standalone PM for Increment I+1, SPM (I+1), would be calculated from EKSLOC (I+1 Added) and EAF (I), using the standard COCOMO II equations.
The IDPD (I+1) factor would then be  
EKSLOC (I) = KSLOC (I) * (0.4*DM + 0.3*CM + 0.3*IM)
IDPD(I+1) = SPM (I+1) / PM (I+1)

12. Data Collection
Collect data of completed Incremental projects from industry
Inclusion Criteria:
Starting and ending dates are clear
Has at least two increments of significant capability that have been integrated with other software (from other sources) and shown to work in operationally-relevant situations
Has well-substantiated sizing and effort data by increment
Less than an order of magnitude difference in size or effort per increment
Realistic reuse factors for COTS and modified code
Uniformly code-counted source code
Effort pertaining just to increment deliverables

13. Data Collection - 2 Metrics Metric Description Product
Name of software product
Build
Build number. A software product that has multiple builds (increments)
Effort
Total time in person-hours
New SLOC
SLOC count of new modules
Reused SLOC
SLOC count of reused modules
COTS SLOC
SOLC count of COTS modules CM
The percentage of modified code DM
The percentage of design modified IM
The percentage of implementation and test needed for the reused/COTS modules SU
Software Understanding
UNFM
Programmer Unfamiliarity
Cost drivers
Rating levels for 22 cost drivers

14. Preliminary Results - 1 Delphi Results
2 rounds of Delphi at CSSE and ISCAS
IDPD Factor
Productivity Range
Variance
RCPLX
1.79
0.098
IPCON
1.77
0.066
PRELY
1.49
0.029
IRESL
1.53

15. Preliminary Results - 2 IDPD Driver ratings VL L N H VH PRELY 0.972
0.986 1
1.008
1.025
RCPLX
0.985
0.904
0.783
0.732
IPCON
0.841
0.900
0.951
1.052
IRESL
1.065
1.046
0.988
0.933

16. Preliminary Results - 3
Relative Impact of Cost drivers on Effort: Productivity Ranges

17. Question?