See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228952892

Software cost estimation in the incremental

commitment model

Article in Systems Research Forum · June 2010

DOI: 10.1142/S1793966610000156

CITATIONS READS

2 127

2 authors, including:

Barry Boehm
University of Southern California
367 PUBLICATIONS 19,266 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Systems Quality Ontology, Tradespace, and Affordability View project

All content following this page was uploaded by Barry Boehm on 27 August 2014.

The user has requested enhancement of the downloaded file.

June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

Systems Research Forum

Vol. 4, No. 1 (2010) 45–55


c World Scientific Publishing Company
DOI: 10.1142/S1793966610000156

SOFTWARE COST ESTIMATION IN THE

INCREMENTAL COMMITMENT MODEL

A. WINSOR BROWN∗ and BARRY BOEHM†

Computer Science Department, University of Southern California
941 W. 37th Place, SAL 328, Los Angeles
California 90089-0781, United States of America
∗AWBrown@CSSE.usc.edu
†Boehm@CSSE.usc.edu

Complex, software intensive systems — especially those with multiple software compo-
nent developers — and Directed System of Systems (DSOS) or Acknowledged Systems of
Systems (ASOS) need approaches to control the development and estimate the software
development costs and schedules. This paper will introduce a next-generation synthesis
of the spiral model and other leading process models into the Incremental Commitment
Model (ICM). The ICM emphasizes architecting systems (or DSOSs) to encapsulate sub-
systems (or systems) undergoing the most rapid change, and having agile systems engi-
neers handle longer-range change traffic to rebaseline the plans for future increments.
Systems engineers do this, while largely plan-driven teams develop and continuously
verify and validate (V&V) the current increment, as is usually required for safe or secure
software.
Our approach for estimating software development cost of systems is the Construc-
tive Incremental Commitment Cost Model (COINCOMO) and its tool, which currently
implements together in one tool the Constructive Cost Model (COCOMO II), and the
Constructive Phased Schedule and Effort Model (COPSEMO).

Keywords: Incremental commitment model; system of systems; cost estimation; systems

engineering; COCOMO II, COINCOMO.

1. Overview of the Incremental Commitment

Life Cycle Model (ICM)
An overview of the ICM life-cycle process (Boehm, 2008) is shown in Fig. 1.
The ICM must also adhere to the following key process principles as critical
success factors:

• Stakeholder Satisficinga : Identify and engage key stakeholders (i.e., those critical
to success) early and often to validate and re-validate requirements, solutions and
plans, and to discuss potential and proposed changes.

a The word satisfice was coined by Herbert Simon as a portmanteau of “satisfy” and “suffice”
meaning to “meet criteria for adequacy, rather than to identify an optimal solution”. (Wikipedia;
Satisficing: http://en.wikipedia.org/wiki/Satisficing.)

45
June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

46 A. W. Brown & B. Boehm

Fig. 1. Overview of the incremental commitment life-cycle process.

• Incremental and Evolutionary Growth of System Definition and Stakeholder

Commitment: Establish and apply a robust framework for evolution, including
stakeholder interaction and agreement processes that gradually build understand-
ing and trust, enabling objective trade-off analyses and resulting in incremental
commitments to plans to move forward.
• Iterative System Development and Definition: Iteratively refine trade-off analyses,
requirements, solutions, and plans based on new information, new needs, and new
technologies.
• Concurrent System Definition and Development: Define, analyze, and refine
requirements and solutions concurrently, especially in environments in which
legacy and commercial components factor into the solution. Refine requirements
as more is known about constraints on the solution and to adapt to changes in
mission and business needs.
• Risk Management Through Risk-Driven Anchor-Point Milestones: Apply risk-
driven milestones to synchronize and stabilize activities and products that are
concurrent, iterative, and evolving. Evaluate business, technical, and operational
feasibility by independent experts, discuss risks and risk-management plans, and
decide whether or not to proceed.
June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

Software Cost Estimation in the Incremental Commitment Model 47

Figure 1 also shows how ICM spans the full life cycle process from concept
exploration to operations. Each phase concludes with an anchor point milestone
review. At each anchor point, there are four options, based on the assessed risk of
the proposed system. Some options involve go-backs. The sets of options result in
many possible process paths. The “negligible” path means that the only activities
needed for the next phase are bringing the documents, and especially the Feasibility
Evidence Document, up to the level needed by the next anchor point, as explained
in detail in (Boehm, 2008).
The total system (or SOS) life cycle is divided into two stages: Stage I of the
ICM (Definition) has three decision nodes, each with four options per node, culmi-
nating with incremental development in Stage II (Development and Operations).
Stage II has an additional two decision nodes, again with four options per node.
One can use ICM risk patterns to generate frequently-used processes with confi-
dence that they will fit the situation. Initial risk patterns can generally be deter-
mined in the Exploration phase. One then proceeds with Definition and approaches
Development as a proposed plan with risk-based Feasibility Evidence at the VCR
milestone and each subsequent milestones, adjusting plans and updating Feasibil-
ity Evidence in later phases as necessary. Risks associated with the system drive
the life cycle process. Information about the risk(s) (feasibility assessments) sup-
ports the decision to (a) proceed, (b) adjust scope or priorities, or (c) cancel the
program.
In contrast with the software-intensive, single development increment delivery
of the Rational Unified Process (RUP) by IBM/Rational Corporation (Krutchen,
2004), the ICM addresses hardware and human factors integration. It extends the
RUP phases to cover the full system life cycle, including the following anchor-
point milestones: Exploration Commitment Review (ECR), Valuation Commitment
Review (VCR), Foundations Commitment Review (FCR), Development Commit-
ment Review (DCR), and Operations Commitment Review (OCR). These are for
the first increment; subsequent increments have DCRs and OCRs only. The ICM
anchor-point milestones are focused on synchronizing the high degree of concur-
rency surrounding complex systems development with the stakeholder commitments
needed to move forward. These milestones look at concurrent activities, which may
span independently developed systems or subsystems, with a view toward synchro-
nizing, stabilizing, and assessing risk before obtaining commitment to proceed to
the next phase.

2. An Incremental Commitment Model for Software (ICM-Sw)

While developing and evolving the “Model Based [System] Architecting and Soft-
ware Engineering” [MBASE] software lifecycle process model, the USC-CSE (Center
for Software Engineering — now the USC-CSSE, Center for Systems and Software
Engineering) found that the RUP was the closest commercially supported software
June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

48 A. W. Brown & B. Boehm

Fig. 2. RUP with MBASE anchor points.

development life cycle model. RUP had concurrent activities and phases as shown in
Fig. 2. While it had phases, it did not contain anchor points, where the pre-cursor to
commitment reviews, Architecture Review Boards (Maranzano et al., 2005), could
be held. The MBASE anchor points were added giving MBASE/RUP as also shown
in Fig. 2.
For the ICM subset for Software (ICM-Sw), which is now used in USC’s
CSCI577ab Software Engineering project course (Koolmanojwong et al., 2007),
it was clear that system ICM’s Development Phase was actually composed of
RUP/MBASE’s Construction and Transition phases. The concept of Transition,
especially of software onto its system/hardware platform, is a separate activity
like integration. This meant a need for an additional, software specific commit-
ment review, a Transition Readiness Review (TRR). Furthermore, RUP’s Incep-
tion phase was appropriately refined into Exploration and Valuation phases, as
shown in Fig. 3 that comes from the Electronic Process Guide (EPG, 2009) for
CSCI577ab.
There are multiple permutations of the ICM-Sw within ICM. The simplest ver-
sion is one encompassing the ICM’s Exploration, Valuation, Foundation and Devel-
opment (1) Lifecycle phases; with an additional ICM-Sw for the each subsequent
Foundations (i) and Development (i) cycle. At the other extreme would be multiple
ICM-Sw within each ICM phase, as depicted in Fig. 4, which would be the case of
competitive prototyping.
June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

Software Cost Estimation in the Incremental Commitment Model 49

Fig. 3. ICM-Sw anchor points.

Fig. 4. Multiple ICM-Sw passes in an ICM competitive prototyping scenario.

3. Engineering Reasons for Multi-Build, Overlapping ICM-Sw

Iterations in ICM
The selection of multiple builds with overlapping ICM-Sw cycles within the defi-
nition and development phases of ICM was done for sound systems/software engi-
neering reasons. The primary reason for multiple builds is based on producibility
in the face of risks. An all-or-nothing approach to the software development (also
known as a “big-bang” approach) does not make sense except when there is no
June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

50 A. W. Brown & B. Boehm

risk of requirements changing. With multiple software builds, the program has a
chance to re-scope either pieces of software or the whole system at the decision
points based on Feasibility Evidence. The selection also provides the ability to gen-
erate and demonstrate some of the system’s capabilities earlier than is possible in a
big-bang approach, and those capabilities should involve many of the ”risky” bits,
not the simple ones.
Employing overlapping, concurrent builds for the different sub-systems (or sys-
tems of a DSOS) (Maier and Rechtin, 2000) also has sound systems/software engi-
neering reasons. Assuming there is not a software development resource restriction,
and that developers have appropriate “application” domain experience, then getting
the teams working concurrently is the smartest thing to do from an overall software
development effort perspective: the efforts of the teams are additive and not based
on the total Source Lines-of-Code (SLOC) count being used on any given system or
subsystem. From a systems and software engineering perspective, producing builds
that are fully systems-tested, even if parts of the build may use simulation and/or
emulation, means that both the software-to-system-integration teams and systems-
test teams can start to work earlier than in a big-bang approach. In addition, the
systems engineers and software architects can practice the concurrent “Agile Archi-
tecting and Stabilized Development” approach, espoused in ICM, for systems with
high concerns for safety or security or requirements that are unstable or emerging.
Finally, the early integration and test experience will also increase the acquirer’s
confidence about the capabilities and architecture of the system.

4. The Constructive Incremental Commitment

Cost Model (COINCOMO)
The original COCOMO I model used the waterfall model for its anchor points:
the cost and schedule estimates covered the effort between Software Requirements
Review (SRR) and Initial [software] Operational Capability (IOC). That model,
which dates back to the 1970s (Royce, 1970) has been recognized as an appropriate
subset of the possible process models under the appropriate conditions (Boehm and
Port, 1999). Current terminology for anchor points, as used in COCOMO II, requires
a more general approach (Boehm, 1996). The co-evolution of the RUP in the late
1990s led to the obvious alignment of the anchor points (and their assessments) as
gatekeepers to the RUP “phases”. The gatekeepers are Inception Readiness Review
(IRR) for Inception phase; Life Cycle Objectives (LCO) for Elaboration; Life Cycle
Architecture (LCA) for Construction; and IOC, with a Transition Readiness Review
(TRR), for Transition; and a Product Release Review (PRR) to formalize the end
of the ”Transition”. These anchor points, super-imposed on the RUP activities
diagram, are shown in Fig. 5.
Also shown in Fig. 5 via shading is the area from LCO to IOC, i.e., the Elabo-
ration and Construction phases, and the covered activities that are included in the
total effort that a COCOMO II estimation covers.
June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

Software Cost Estimation in the Incremental Commitment Model 51

Fig. 5. RUP with MBASE anchor point.

Builds made using the COCOMO II model follow either the “once-through” or
“incremental” development strategies, as described in Appendix B of the IEEE’s
J-STD-016-1995 (IEEE, 1995). In both cases, there is only one system integration
and software qualification test, which are two of the primary activities taking place
during the Transition phase. These two development strategies are in contrast to
the “evolutionary” strategy that develops a system in builds, where the first build
incorporates part of the planned capabilities, the next build adds more capabilities,
and so on, until the system is complete. If the builds follow the “evolutionary”
strategy, including their integration with the system to be deployed, they are often
fully tested and delivered to the acquirer, in which case all the phases of RUP are
repeated for each build. However, how the phases overlap is not depicted in RUP
Fig. 5. The many possible overlaps across builds are shown in Fig. 6.
Figure 7 shows one possible scenario of evolutionary, multi-build software devel-
opment in systems development increments in an MBASE/RUP context.

5. The COINCOMO Tool

The vision behind the development of the COINCOMO Tool has been to build a
base to integrate all of the components of the COCOMO “suite” of software develop-
ment estimation tools, including the COCOMO II Charts [extension], COPSEMO
(Constructive Phase Schedule and Effort Model), CORADMO (Constructive RAD
Model), COCOTS (Constructive COTS model); and the systems engineering exten-
sions COSYSMO (Constructive System [Engineering] Model). In addition, COIN-
COMO must (1) cover all software activities included in multiple passes of all four
June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

52 A. W. Brown & B. Boehm

Fig. 6. Overlaps across software builds.

Fig. 7. ICM showing RUP/MBASE multi-build software in systems.

June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

Software Cost Estimation in the Incremental Commitment Model 53

Phases of MBASE/RUP life cycle as shown in Fig. 7, each producing fieldable, inte-
grated software; and (2) accommodate the multiple (from different organizations)
builds (or deliveries) and systems. The latter requirement arose out of personal
experience while acting as an advisor to the US Army on the Future Combat Sys-
tem (FCS) project (FCS, 2004).
The current version of the COINCOMO tool is based on the COCOMO II
and COPSEMO models (Boehm et al., 2000) with the added super-structure to
accommodate the multiple packages, builds (or deliveries) and systems, as described
in several papers (Brown and Meyers, 2005; Brown et al., 2006; and Brown, 2007).
Future refinements of the tool will switch over from the MBASE/RUP anchor points
to the ICM-Sw anchor point and add COSYSMO effort. The COINCOMO tool also
accommodates multiple types of re-use without the module name-space explosion
that happened in COCOMO II because of its need to have separate module names
for separate instances of size specification. COINCOMO 2.0 is implemented in a
database-centric fashion designed with the ability to save and reuse any of the sets
of parameters thus making it much easier to do what-if or evolving estimates. The
current version of the tool has been used to estimate the costs of a Fractionated
Space System (Brown and Moazeni, 2008; Brown et al., 2009).

6. Conclusion
COCOMO II, or some other cost model, along with COPSEMO, or its equivalent in
some other cost model, had to be used to get the cost and schedule for each build: the
traditional Cost Estimating Ratios (CERs) do not work without sufficient data. In
addition, differences between the teams producing the software should be factored
into the cost and schedule estimation. The amounts of carried code and their reuse
factors change with the number of times the code is carried: these factors influence
what software cost estimators call “Equivalent SLOC”, or ESLOC, for the carried
code, which in-turn impacts the effort and schedule. When calculating the total
schedule in a multi-build approach, only the parts up to an overlap are counted.
What seems initially surprising is the comparison of total estimated software
development effort of a multi-build system versus the monolithic system: usually
about a 20% decrease in software effort for the system using multiple builds (which
happens because the smaller pieces of that approach are not as impacted by the
diseconomies of scale for the larger monolithic approach). Schedule wise, the system
using multiple builds would take about 25% longer than the monolithic system, but
it does not have the all or nothing risk characteristics of the monolithic system.
Furthermore, the multi-build approach allows fielding some functionality earlier
than the monolithic approach.
The differences between the risk inherent in the monolithic system and the risk
inherent in the multi-build systems are significant. With the multiple, overlapping
builds there will be greater assurance that more of the software will be fully func-
tional by each operations date.
June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

54 A. W. Brown & B. Boehm

References
Boehm, B., Anchoring the software process, IEEE Software 13 (1996) 73–82.
Boehm, B. and Port, D., Escaping the software tar pit: Model clashes and how to
avoid them, Software Engineering Notes, Association for Computing Machinery (1999),
pp. 36–48.
Boehm, B., Abts, C. Brown, A. W., Chulani, S., Clark, B., Horowitz, E., Madachy, R.,
Reifer, D. J. and Steece, B., Software Cost Estimation with COCOMO II (Prentice
Hall, 2000).
Boehm, B., Human-System Integration in the System Development Process: A New Look
in System Development Process: The Incremental Commitment Model, USC Tech-
nical Report, http://sunset.usc.edu/csse/TECHRPTS/2008/usc-csse-2008-807/usc-
csse-2008-807.pdf (2008).
Brown, A. W. and Meyers, S., COINCOMO — Combining elements of the COCOMO
suite, Proc. Joint ISPA/SCEA Int. Conf. (2005).
Brown, A. W., Colbert, E. and Nguyen, V., COINCOMO and its new supporting tools
with Ed Colbert and Vu Nguyen, Proc. ISPA (2006).
Brown, A. W., COINCOMO — The COCOTS integration challenges, Proc. ISPA (2007).
Brown, A. W., and Moazeni, R., Software cost estimation for fractionated space systems,
Proc. AIAA Space 2008 (2008).
Brown, A. W., Moazeni, R. and Boehm, B., Realistic software estimations for fractionated
space systems, in Proc. AIAA Space 2009 (2009).
EPG for IICM-Sw, http://greenbay.usc.edu/IICMSw/index.htm (2009).
FCS Overview Booklet (Flipbook) R1 (2004).
IEEE, Trial-use standard for information technology software life cycle processes software
development acquirer-supplier agreement, J-STD-016-1995 (2005).
Koolmanojwong, S., Phongpaibul, M., Laoteppitak N. and Boehm, B., Comparative expe-
riences with software process modeling tools for the incremental commitment model,
Technical Report USC-CSSE-2007-724 (2007).
Kruchten, P., The Rational Unified Process: An Introduction, 3rd Ed. (Addison-Wesley,
Boston MA, 2004).
Maier, M. and Rechtin, E., The Art of Systems Architecting (CRC Press, Boca Raton FL,
2000), p. 133.
Maranzano, J. F., Rozsypal, S. A., Zimmerman, G. H., Warnken, G. W., Wirth, P. E. and
Weiss, D. M. IEEE Software 22 (2005) 34–43.
MBASE website, http://sunset.usc.edu/csse/research/mbase/.
Royce, W. W., Managing the development of large software systems, Proc. IEEE Wescon
(1970), pp. 1–9. Also in Proc. 9th Int. Conf. on Software Engineering (1987),
pp. 328–338.

Biography
A Winsor Brown has a BES from Rensselaer Polytechnic Institute; and an MSEE
from California Institute of Technology. He is a part time lecturer and a senior
research scientist with the Computer Science department of University of Southern
California (USC), and Assistant Director of the USC’s Center for Systems and
Software Engineering (CSSE). While the bulk of his 40-year career has been in
industry, he joined USC in 1999. He has co-authored, co-taught, and taught CS577ab
at USC, since joining USC. After over thirty years in industry, Winsor started his
 June 17, 2010 14:30 S1793-9666 SRF S1793966610000156

Software Cost Estimation in the Incremental Commitment Model 55

professional involvement with USC before joining by developing and teaching two
other courses.
Prior to joining USC in 1993, Barry Boehm was at U.S. Department of Defense
(DoD) from 1989 to 1992 as Director of the DARPA Information Science and Tech-
nology Office and as Director of the DDR&E Software and Computer Technology
Office. Other positions include TRW, 1973 to 1989; and Rand Corporation, 1959 to
1973. He entered the software field at General Dynamics in 1955.

View publication stats