COCOMO II/Appendix B/Boehm et al.
-1-
APPENDIX B
COCOMO II: ESTIMATING FOR INCREMENTAL DEVELOPMENT
B.1 Introduction
An incremental development estimation model was developed for Ada
COCOMO in [Boehm-Royce,1989] and expanded into a scheme for
subcomponents in [Ligett 1993]. It is available in at least one of the commercial
COCOMO implementations, COSTAR [Ligett, 1999]. A variant of the
incremental model is presented here based on an extension of the MBASE/RUP
phase distributions discussed in appendix A.
Incremental software development is gaining wide acceptance as an
approach to handle delivering parts of the software product early. This has
several advantages:
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.

-2-
Breaking the project into understandable and manageable pieces –
separation of concerns

Early customer and user review of some product functionality

Reduction of risk in delivering the wrong product

Final product integration reduced due to earlier integration work

More level staffing profile

Earlier initial capability but a longer schedule and more effort for final
capability
There are three development strategies for using incremental development.
The first strategy is described as incremental delivery. A portion of the software
system capabilities are developed and delivered. This type of development takes
the software from requirements all the way through to on-site installation.
Succeeding increments use the previous increment’s software product to begin
development in a way that accommodates user feedback. This strategy has added
costs because each increment goes through system testing and delivery, and
because later increments may cause significant breakage in the already-installed
increments.
The second strategy is incremental development based on builds. A piece
of the software product is built in each increment. Each increment is integrated or
assembled with the pieces constructed in previous increments. With this strategy
each succeeding increment may also cause some of the software built in previous
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
-3-
increments to be modified, but the modifications are to a system under
development rather than to a system in operational use. Think of this as software
that is divided up as pieces of a building. The building is constructed one room at
a time, but before people have started to live or work in the rooms completed so
far.
The third strategy is described as incremental development where the
requirements, software architecture, and critical infrastructure are solidified
before work on the application increments begins. Each increment can have
multiple modules that proceed through software integration and test, often
including friendly-user experimental usage in representative situations. This
strategy does not include full system integration and test, customer/user transition,
or other later phases. Each increment builds on the software developed in
previous increments. An increment’s integration and test phase integrates the
software from all previous increments i.e. the entire software is retested. Think of
this as software that starts out as the architecture, framework, and infrastructure
for a building, and each succeeding increment increases the amount of the
building that has been outfitted for particular uses. This strategy is the one
described in this Appendix.
The primary estimating difference between traditional full and incremental
approaches is that the full approach requires a monolithic estimate of effort and
schedule which assumes that detailed design, code, integration and test are carried
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
-4-
out sequentially for the entire product. The full approach generates uneven levels
of effort during different phases. The incremental approach breaks the later
phases into a series of increments in which part of the product is developed and
tested. This levels-out effort by using overlapping phases to make the level of
effort more even.
B.2 Incremental Development Model
The traditional full product development schedule is shown at the top of
Figure B.1 (see Appendix A.2.1 for a description of each phase and milestone).
The lower part of the figure shows the full development broken into three
increments. The first increment carries most of the Product Design phase where
the product architecture and interfaces are established. Each succeeding
increment briefly revisits the Product Design phase (about 25% of the nominal
phase length) for updates to the architecture and interfaces.
Increments can start at any milestone, MSTART, from the previous
increment. This is discussed in Section B.5. In this example all increments have
to start on the same milestone (in reality, project characteristics may make this
infeasible). A delay can be introduced if the following increment has to start later
than MSTART. The example in Figure B.1 defines MSTART for succeeding
increments to be at the Critical Design Review (CDR) of the previous increment,
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
-5-
and for each increment to repeat 25% its Product Design activity. Additional
parameters in the [Boehm-Royce, 1989] model enable these assumptions to be
generalized.
[Insert Figure B.1]
Estimation of effort and schedule rely on knowing the requirements for the
software project. The incremental estimation model for the MBASE/RUP process
assumes that a full Life Cycle Architecture package definition is almost
completed before starting on remaining increments. This is reflected by Figure
B.1 showing the MBASE/RUP Elaboration phase or the product design phase for
the first increment matching the product design phase for the overall product.
There is additional work on product design in following increments due to
adapting the software product from the previous increment. The process shown in
Figure B.1 assumes that the MBASE/RUP Construction phase for each increment
is organized into the Waterfall subphases of Detailed Design, Code and Unit Test,
and Integration and Test. Other variants can be accommodated via the subphase
effort and schedule distribution parameters.
B.3 Inputs and Outputs
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
-6-
Estimation of incremental development requires the following inputs:

COCOMO II Early Design or Post-Architecture Model scale factor
and cost driver ratings.

New software size of each increment.

The percentage of change in software size from all previous
increments, called the Adaptation Adjustment Modifier (AAM).

The starting milestone, MSTART, for each increment after the first.

Any delay-time, TDELAY, for starting an increment.

The distribution of effort and schedule for each phase: Product Design
(PD), Detailed Design (DD), Code and Unit Test (CUT), and
Integration and Test (IT).
The incremental estimation process will be explained by following a
simple example. A more detailed example is given in Chapter 3. Using the threeincrement development shown in Figure B.1, the inputs are:
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
Increment
1
2
3
Total
New Size
(KSLOC)
Size1 = 50
Size2 = 30
Size3 = 20
SizeT = 100
-7-
E
1.15
1.15
1.15
 EM
1.0
1.0
1.0
AAM
0
20
10
MSTART
Milestone
SRR
CDR
CDR
TDELAY
(Months)
0
0
Based on the phase distributions of MBASE discussed earlier, the
following percentages will be used:
Phase
Product Design (PD)
PD for Increments 2 & 3
Detailed Design (DD)
Code and Unit Test (CUT)
Integration and Test (IT)
Effort Distribution
24%
24% * 25% = 6%
20%
30%
26%
Schedule Distribution
38%
38% * 25% = 9.5%
17%
23%
22%
The outputs are the adjusted sizes, estimated effort (PM), and schedule
(TDEV) for each phase of each increment. Table B.1 names the output quantities
for the example we are about to calculate.
[Insert Table B.1]
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
-8-
B.4 Estimation Steps
As the estimation steps are followed the estimation results will be stored in
Table B.2, in the cells indicated by the terms defined in Table B.1.
1. Compute the size for each increment and the total size.
The total size in our example is 100 KSLOC. This is placed in Table B.2
in the SizeT position. The example sets the sizes for Increments 1, 2, and 3 as 50,
30, and 20 KSLOC respectively. Increment 1’s size is placed in the results table
in the Size1 position. However succeeding increments require that their sizes be
adjusted due to reusing the software product from all the previous increments.
AAM is applied to the sizes of all previous increments because modification may
occur to any code that has already been developed. An increment’s size is
composed of new code and previous increment’s code sizes:

Adj. Size i  Size i  AAM   j1 Size j
i 1

Recall from the discussion of COCOMO II’s reuse model that reuse effort
is influenced by a factor called the Adaptation Adjustment Modifier (AAM).
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
-9-
AAM is based on the percent design modified (DM), the code modified (CM), the
integration and test modified (IM), the assessment and assimilation (AA), the
software understanding (SU), and programmer unfamiliarity with the software
(UNFM), see Section 2.2.4.2. These relationships are repeated below.
AAF  0.4( DM )  0.3(CM )  0.3( IM )
[ AA  AAF (1  0.02( SU )(UNFM ))]
AAM 
, AAF  50
100
[ AA  AAF  ( SU )(UNFM )]
AAM 
, AAF  50
100
To derive the size for the next increment, the sizes from all of the previous
increments are summed and adjusted with AAM (this is because modifications
may effect code from any previous increment). The adjusted sum is then added to
the size of the increment to be developed. For the example, AAM for Increment 2
(AAM2) is set to 20% and to 10% for Increment 3 (AAM3); in a real world
scenario, it would be preferable to set AAM to the results of the equation above.
Adj. Size 2  AAM 2  Size 1   Size 2 Adj. Size 3  AAM 3  Size 1  Size 2   Size 3
 0.2  50  30
 40
 0.1  50  30  20
 28
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
- 10 -
In the results table, Adj. Size2 is set to 40 and Adj. Size3 is set to 28.
Observe the sum of sizes for all increments is 118 KSLOC compared to the total
original product size of 100 KSLOC. This indicates that incremental
development increases effort and schedule for achieving the full Initial
Operational Capability*.
2. Determine the total effort and schedule for the total single product.
Use COCOMO II to estimate the total effort and schedule and distribute
the estimates over the PD, DD, CUT, and IT phases.
For this example, only the effort will be estimated and placed in the results
table. Schedule is estimated in the same manner. The distribution for effort for
each phase was given earlier.
PM Total  2.94  (100)1.15  1.0  586.6
PD T  586.6  0.24  140.8
DD T  586.6  0.20  117.3
CUTT  586.6  0.30  176.0
ITT  586.6  0.26  152.5
*
To make a fair comparison, we'd have to apply some REVL to the full 100K project. In practice,
the REVL value for single-shot development would be smallest, but the post-IOC effort to modify
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
- 11 -
3. Determine Increment 1’s estimated effort and schedule.
Use the provided COCOMO II parameters, Size1, and phase distributions
to estimate effort for Increment 1.
PM Inc1 Total  2.94  (50)1.15  1.0  264.3
PD1  264.3  0.24  63.4
DD 1  264.3  0.20  52.9
CUT1  264.3  0.30  79.3
IT1  264.3  0.26  68.7
For only the first increment, Increment 1, the PD1 phase effort is replaced
by the Total product phase effort, namely 140.8 PM. This is because the
architecture and interfaces for this incremental development strategy have to be
defined for all increments in the first increment. Table B.2 now contains PD1,
DD1, CUT1, IT1, and PM1 for Increment 1.
4. Determine the added integration effort.
Additional effort must be expended to integrate the code in the various
increments (the integration term used here is not the same effort used in each
the operational product to reflect the experimental-use lessons learned during incremental
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
- 12 -
increments I&T phase). Steps 4 and 5 compute this effort and Step 6 uses the
computed effort. This step calculates the additional integration effort associated
with incremental development by comparing the development of a full product
with the development of similarly sized independent products. The full product is
the Total product in this example. The independent products are the individual
increments using only their sizes without adjustment for reuse of software from
previous increments.
Compute the effort and schedule for the remaining increments using new
size only (the first increment was done in the previous step).
PM Inc 2 Total  2.94  (30)1.15  1.0  146.9
PM Inc 3 Total  2.94  (20)1.15  1.0  92.2
These results are intermediate and not stored in the results table. The total
additional integration effort is the difference between the full product effort and
the sum of the estimated effort for all of the independently estimated Increments.
PM Integration  PM Total   PM each Increment
 586.6  (264.3  146.9  92.2)
 83.2
development would be considerably larger.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
- 13 -
The additional integration effort, PMIntegration, contains the effort for the
full product design, PDT. We have already included the total PD effort as
Increment 1’s PD1 effort in Step 3. We need to remove the PDT contribution to
PMIntegration. We do this as next.
The added integration effort, PMAdded Integration, is the integration effort
without the added PDT integration effort. Estimate the PD phase distribution for
each remaining increment, the first increment was done in Step 3.
PD Inc 2  146.9  0.24  35.3
PD Inc 3  92.2  0.24  22.4
The additional PD effort is the difference between the full product PD
effort and the sum of all independently estimated Increment’s PD effort:
PD Integration  PD Total   PD each Increment
 140.8  (63.4  35.3  22.4)
 26.6
The added integration effort, PMAdded Integration, is the total integration effort
without the added PD integration effort. This represents the additional integration
effort for the DD, CUT, and IT phases.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
- 14 -
PM Added Integration  PM Integration  PD Integration
 83.2  26.6
 56.6
5. Distribute the added integration effort across remaining increments.
The added integration effort, PMAdded Integration, derived in the previous step,
is allocated to all increments after the first. The first increment has nothing to
integrate. The allocation is based on each increment’s size unadjusted for reuse
compared to the sum of all the remaining increment’s sizes.
Size Total Remaining   Size each Increment
PM Increment Added Integration 
Size each Increment
 PM Added Integration
Size Total Remaining
From the example, the added integration effort for Increments 2 and 3 are:
Size Total Remaining  (30  20)  50
PM Increment 2 Added Integration 
30
 56.6  34
50
PM Increment 3 Added Integration 
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
20
 56.6  22.6
50
612916867
COCOMO II/Appendix B/Boehm et al.
- 15 -
6. Determine all remaining increment’s effort and schedule.
This step picks up from Step 3. Steps 4 and 5 were necessary to derive the
additional integration effort in incremental development. The additional
integration effort will be used in this step.
Use COCOMO II to estimate the total effort for the remaining increments
as was done in Steps 2 and 3. Use the increment’s Adj. Size, which is the new
size adjusted for reuse.
PM 2  2.94  (40)1.15  1.0  204.5
PM 3  2.94  (28)1.15  1.0  135.7
Add each increment’s allocated additional integration effort to its
estimated effort.
PM Increment Adjusted  PM Increment  PM Increment Added Integration
PM Increment 2 Adjusted  204.5  34  240.6
PM Increment 3 Adjusted  135.7  22.6  159.7
7. Distribute each increment’s effort and schedule over the phases
The adjusted effort for each increment from the previous step is
distributed using the phase distribution given in Section B.3. The exception is the
distribution for PD, which is a fraction (25%) of the PD given in B.3. This is
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
- 16 -
because the requirements and architecture were solidified during the PD phase of
Increment 1. The PD phase for the remaining increments consists of checking
interfaces and resolving new architectural issues. These distributions are placed
in Table B.2.
PD 2  240.6  0.06  14.4
PD 3  159.7  0.06  9.6
DD 2  240.6  0.20  48.1
DD 3  159.7  0.20  31.9
CUT2  240.6  0.30  72.2
CUT3  159.7  0.30  47.9
IT2  240.6  0.26  62.6
IT3  159.7  0.26  41.5
8. Determine resulting cumulative effort and schedule for each increment.
The results table filled out during the explanation of incremental cost
estimating has all the information needed to determine the resulting cumulative
effort for the example.
[Insert Table B.2]
Comparing the total project effort, 586.6 PM, to Increment 1’s effort
(which includes the PD effort for the entire product), 341.7 PM, it can be seen the
effort to reach an initial capability is lower. However the total effort required for
all increments is 669.6 PM which is 14% higher than the total project effort.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867
COCOMO II/Appendix B/Boehm et al.
- 17 -
B.5 Incremental Development Considerations
The above example overlapped the different phases at the end of Detailed
Design, the Critical Design Review. The degree to which increments overlap is
dependent on how much is known about the software product. The more
uncertainty characterized by COCOMO drivers such as Architecture and Risk
Resolution (RESL), Required Reliability (RELY), Product Complexity (CPLX),
and Platform Volatility (PVOL), the less the overlap between increments. This is
because change in previous increments causes unplanned rework to flow to
succeeding increments.
It is reasonable to anticipate additional effort required for phases in
succeeding increments that overlap a phase of a previous increment that is
undergoing review by the customer or user. This phase is not shown in the
example or estimated by the COCOMO II model. This is due to unforeseen
installation or initial operational problems, the correction of which may affect the
rest of the software product. Such effects may be approximated via either the
COCOMO REVL parameter or post-IOC maintenance cost estimates.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
612916867