ArticlePDF Available

COCOMO suite methodology and evolution

Authors:

Abstract and Figures

An overview of the models in the COCOMO suite that includes extensions and independent models, and describes the underlying methodologies and the logic behind the models and how they can be used together to support larger software system estimation needs, is presented. The models in this suite provide specialized set of estimates that address specific aspects of development effort for software-intensive systems. The models also provide a set of tools that enable more comprehensive cost estimates. The developments done on multiple COCOMO models in parallel for cost estimates that cover a broader scope that exceeds the boundaries of traditional software development are discussed.
Historical Overview of COCOMO Suite of Models COCOMO Suite Methodology and Evolution (SoS) software residual <www.costxpert.com> MO estimation-related ment. investments. starsystems.com> to balance space, tions the ates. fundamentally CSE COCOMO COINCOMO, tical edu/cse/pub/affiliate/general.html>. major data the cial robust riences panies, provided government bined and model. lored In investment resources incremental product effective ment MO. a COCOTS junction with ent modify COCOMO described depend improve their COSYSMO software lead the neering tem ated phased provide Model The Step The extensions Delphi cost longest, addition, life system with techniques with shelf These calibration is own COPROMO the for companies and components. affiliates, mostly software as This non-profits, computing, it COPLIMO effort used of expert on first defects line final cycle. 6 model different productivity. distribution by dependability for well integration the the in with is inputs thus involves insights estimates priorities, intensive survey the analysis. USC have allocation (COTS) model integrator and new cost typically the is three such organizations, estimates iDAVE certain rapid expert definition three to because required as COSOSIMO done of data commercial output and the proprietors. far in that and COCOMO, visit practical estimate it accurate. included data estimation along technologies and CSE’s COCOMO development capabilities. models a to because predicts into as has combining are models and DBA same professional application COPSEMO software judgment and using provide situations. the manufacturing estimates and produce used of of software can supports definitions, <. it Costar of All (LSI) system-of-systems are over been the with derivatives payoffs and return historical supporting effort has of effort provide commercial needs telecommunica- COCOMO) COCOMO be the model the (COCOMO Bayesian of with they collaboratively the are systems and For the Cost and integration effort estimates many shown been the versions used product major if that the a intended investment COQUAL- captured number <www.soft the to on and for independ- associated entire most situations. and CORAD- products. calibrated somehow the return commer- software societies, ability develop- provides desired. data but support Delphi, further in models around project require associ- of invest- quality of Xpert tracks statis- list expe- to affili- com- aero- engi- con- cost off- sys- and and tai- [2]. the the the are on II, be of of of of to to in Table MO sunset.usc.edu>. opment ing together the puts Underlying resented A The EM Size where, B and PM tor. ues, used Table * Literature, 1: Model COPROMO COPSEMO COQUALMO COSOSIMO COSYSMO COINCOMO COPLIMO CORADMO COCOTS iDAVE DBA COCOMO = = For software software Each or opment effect Status methodologies general = depending For scale key = calibration = to and suite Logic PM 1: COCOMO nonlinear person measure(s) more characterize effort of Status is to example, by of factor behavior, on factor(s) = II by how the COCOMO a understanding effort. A a of development software module software-related information comprehending Models single months. x of on multipliers in factor. Methodologies models, ( effect to and Schedule Improvement Constructive Engineering Model Constructive Constructive Constructive Commercial Constructive Application Development Model Model Constructive Shelf Productivity- Value Information Dependability DataBase COCOMO Constructive Incremental Line Model of-Systems Constructive Constructive Constructive Doing Cost Description Σ the the the of that the and Size) use variable Models value the Investment Model* that Cost equation development functional Estimation Business purpose on size logic. has form functional Σ and multiple B (Access) II Model visit: effort. has or on Integration software the analysis COCOMO x Off-the- Cost an that Systems Rapid Phased Quality System- Product Cost factor Model Model Attribute Effort Π In multiple is: the the As Model cost exponential model an (EM) can of the <http:// influence size limited underly- COCO- additive the models be can model, size effort. devel- devel- of out- rep- Literature fac- val- due be of a to number plicative factor 2. 1. is factors Other effort COCOMO number nential, multipliers, can Alternatively, ment software of a software shown code A A The For part size instruction, module, tomer another effort. tial or mostly nario, overall development Behavior be of factor environment. factor being models exponential is if that available – characterized of example, of comes general or and in complexity additive, has it has or module local function system. EM the factors Table II level has estimated depend is that interface, algorithm a mostly Parameters the has 17 have Significant SoS multiplicative , from system local additive a that site, rationale function of 2 has global adding one via multiplicative to exponential, project effects. in (see a For points, These evaluate. describe on the effect service or global different and either each effect by by additive, – incompatible effects next the operational following to example, effect such that a another software Delphi for on of If characteristics could a point but software set multiplicative scope on requirement, page). or the model. system as the the the number whether on across five not of exponen- or only develop- software factors. criteria: system. models include project size --- 29 14 16 6 --- --- --- --- >200 Data adding of source entity, multi- reuse. effort expo- both. lines cus- sce- The one has the the of of a
… 
Content may be subject to copyright.
I
n the late 1970s and the early 1980s as
software engineering was starting to
take shape, software managers found they
needed a way to estimate the cost of soft-
ware development and to explore options
with respect to software project organiza-
tion, characteristics, and cost/schedule.
Along with a number of commercial and
proprietary cost/schedule estimation
models, one of the answers to this need
was the open-internal Constructive Cost
Model (COCOMO). This and other mod-
els allowed users to
reason about the cost
and schedule implications of their devel-
opment decisions, investment decisions,
established project budget and schedules,
client negotiations and requested changes,
cost/schedule/performance/functionality
tradeoffs, risk management decisions, and
process improvement decisions [1].
By the mid-1990s, software engineering
practices had changed sufficiently to neces-
sitate a new version called COCOMO II,
plus a number of complementary models
addressing special needs of the software
estimation community. Figure 1 shows the
variety of cost models that have been
developed at the University of Southern
California (USC) Center for Software
Engineering (CSE) to support the planning
and estimating of software-intensive sys-
tems as the technologies and approaches
have evolved since the development of the
original COCOMO in 1981
.
Figure 1 also shows the evolution of
the COCOMO suite categorized by soft-
ware models, software extensions, and
independent models. The more mature
models have been calibrated with histori-
cal project data as well as expert data via
Delphi surveys. The newer models have
only been calibrated by expert data.
Table 1 includes the status of the 12
models in the COCOMO suite. All of
these models have been developed using
the following seven-step methodology [2]:
(1) analyze existing literature, (2) perform
behavior analysis, (3) determine form of
model and identify relative significance of
parameters, (4) perform expert-judg-
ment/Delphi assessment, (5) gather proj-
ect data, (6) determine Bayesian A-
Posteriori update, and (7) gather more
data, refine model.
The checkmarks in Table 1 indicate the
completion of that step for each model.
Step 4 of the methodology can often
involve multiple rounds of the Delphi sur-
v
ey that provide model developers some
insight into the effects of the model
parameters on development effort. The
Delphi surveys attempt to capture what
the experts believe has an influence on
development effort.
Step 5 of the methodology involves
collecting historical project data to vali-
date the cost-estimating relationships in
the model.
T
his pr
ocess de
pends on the
support of the CSE affiliates to provide
data that is relevant to the model being
calibrated. The COCOMO model has
mor
e data than the other models com-
bined mostl
y because it has been ar
ound
the long
est,
and it has been sho
wn to be
r
ob
ust as w
ell as accur
a
te.
COCOMO Suite Methodology and Evolution
Dr. Barry Boehm, Ricardo Valerdi, Jo Ann Lane, and A. Winsor Brown
University of Southern California
Over the years, software managers and software engineers have used various cost models such as the Constructive Cost Model
(COCOMO) to support their software cost and estimation processes. These models have also helped them to reason about the
cost and schedule implications of their development decisions, investment decisions, client negotiations and requested changes,
risk management decisions, and process improvement decisions. Since that time, COCOMO has cultivated a user community
that has contributed to its development and calibration. COCOMO has also evolved to meet user needs as the scope and com-
plexity of software system development has grown. This eventually led to the current version of the model: COCOMO
II.2000.3. The growing need for the model to estimate different aspects of software development served as a catalyst for the cre-
ation of derivative models and extensions that could better address commercial off-the-shelf software integration, system engi-
neering, and system-of-systems architecting and engineering. This article presents an overview of the models in the COCOMO
suite that includes extensions and independent models, and describes the underlying methodologies and the logic behind the mod-
els and how they can be used together to support larger software system estimation needs. It concludes with a discussion of the
latest University of Southern California Center for Software Engineering effort to unify these various models into a single, com-
prehensive, user-friendly tool.
20 CROSSTALK The Journal of Defense Software Engineering April 2005
Figure 1: Historical Overview of COCOMO Suite of Models
Figure 1: Historical Overview of COCOMO Suite of Models
April 2005 www
.stsc.hill.af.mil
21
Step 6 involves combining the project
data with the expert judgment captured in
the Delphi survey to produce a calibrated
model. This is done using Bayesian statis-
tical techniques that provide the ability to
balance expert data and historical data [2].
Model priorities, definitions, Delphi,
and calibration data are collaboratively
provided by the practical needs and expe-
riences of USC CSE’s supporting affili-
ates. These have included the major aero-
space, computing, and telecommunica-
tions companies along with many of the
major software and manufacturing com-
panies, non-profits, professional societies,
government organizations, and commer-
cial cost model proprietors. For the list of
CSE affiliates, visit <http://sunset.usc.
edu/cse/pub/affiliate/general.html>.
The first three models (COCOMO II,
COINCOMO, and DBA COCOMO) are
fundamentally the same model but tai-
lored for different development situations.
In addition, commercial versions of
COCOMO such as Costar <www.soft
starsystems.com> and Cost Xpert
<www.costxpert.com> provide further
estimation-related capabilities. COQUAL-
MO is used to estimate the number of
residual defects in a software product and
to provide insights into payoffs for quality
investments. iDAVE estimates and tracks
software dependability return on invest-
ment. COPLIMO supports software
product line cost estimation and return on
investment analysis. COPSEMO provides
a phased distribution of effort to support
incremental rapid application develop-
ment and is typically used with CORAD-
MO. COPROMO predicts the most cost
effective allocation of investment
resources in new technologies intended to
impr
o
ve productivity. All of the models
described thus far are derivatives of the
COCOMO model because the
y someho
w
depend on the output of COCOMO and
modify it for certain situations.
The final three models are independ-
ent extensions of COCOMO that require
their own inputs and can be used in con-
junction with COCOMO, if desired.
COCO
TS estima
tes the ef
f
or
t associa
ted
with the inte
g
r
a
tion of commercial off-
the shelf (COTS) software products.
COSYSMO estimates the systems engi-
neering ef
fort required over the entire sys-
tem life cycle. COSOSIMO estimates the
lead system integrator (LSI) effort associ-
ated with the definition and integration of
software intensive system-of-systems
(SoS) components.
For more information on the COCO-
MO suite of models
,
visit:
<http://sun-
set.usc.edu>.
Underlying Methodologies
and Logic
The key to understanding the model out-
puts and how to use multiple models
together is by comprehending the underly-
ing methodologies and logic. In the devel-
opment of a software-related cost model,
the general COCOMO form is:
PM =
A
x (
Σ
Σ
Size)
Σ
Σ
B
x
Π
Π
(EM)
Σ
Σ
is the additive
Σ
Σ
Β
Β
is the exponential
(EM) is the multiplicative
w
here,
PM = person months.
A = calibr
a
tion f
actor
.
Size = measure(s) of functional size of a
softw
ar
e module tha
t has an ad
ditive
effect on software development effort.
B = scale factor(s) that have an exponen-
tial or nonlinear effect on software
development effort.
EM = effort multipliers that influence
software development effort.
Each factor in the equation can be rep-
r
esented by a single value or multiple val-
ues, depending on the purpose of the fac-
tor. For example, the size factor can be
used to characterize the functional size of
a software module via either software lines
of code
or function points, but not both.
Alternatively, the project characteristics
can be characterized by a set of effort
multipliers,
EM, that describe the develop-
ment environment. These could include
software complexity
and software reuse.
COCOMO II has one additive, five expo-
nential, and 17 multiplicative factors.
Other models have a different number of
factors that depend on the scope of the
effort being estimated by that model. The
number of factors in each of the models
is s
hown in Table 2 (see next page).
T
he g
ener
al r
a
tionale for whether a
factor is additive, exponential, or multi-
plicative comes from the following criteria:
1. A factor that has effect on only one
part of the system – such as software
size – has a local effect on the system.
F
or example, adding another source
instruction, function point entity,
module
,
interface, operational sce-
nario
,
or alg
orithm to a system has
mostly local additive effects on project
effort.
2. A factor is multiplicative or exponen-
tial if it has a global effect across the
overall system. For example, adding
another level of service requirement,
de
velopment site, or incompatible cus-
tomer has mostly global multiplicative
or exponential effects. If the size of
the pr
oduct is doubled and the pro-
COCOMO Suite Methodology and Evolution
Figure 1: Historical Overview of COCOMO Suite of Models
Model Description Literature Behavior
Significant
Variables
Delphi Data
COCOMO II
Constructive Cost
Model
COI
NCOMO
C
onstructive
I
ncremental COCOMO
DBA COCOMO
DataBase (Access)
Doing Business As
COCOMO II
>200
CO
QUALMO
C
onstructive Quality
M
odel
üüüü
6
i
DAVE
I
nformation
D
ependability Attribute
V
alue Estimation
üüü
---
COPLIMO
C
onstructive Product
Line Investment Model
üüü
---
CO
PSEMO
C
onstructive Phased
S
chedule and Effort
M
odel
üü
---
CO
RADMO
Constructive Rapid
A
pplication
Development Model
üüü
16
CO
PROMO
C
onstructive
P
roductivity-
Improvement Model
üüüü
---
COCO
TS
C
onstructive
C
ommercial Off-the-
S
helf Cost Model
üüüü
29
CO
SYSMO
Constructive Systems
E
ngineering Cost
Model
üüüü
1
4
COSOSIMO
C
onstructive System-
of-Systems Integration
Cost Model*
üüü
---
Table 1: Status of the Models
üüüü
Table 1: Status of the Models
* Literature, behavior, and variable analysis limited due to number of available SoS to evaluate.
portional effect of that factor is also
doubled, then it is a multiplicative fac-
tor. If the effect of the factor is more
influential or less influential for larger
projects because of the amount of
rework due to architecture and risk
resolution, team compatibility, or
readiness for SoS integration, then it is
treated as an exponential factor.
These rules have been applied to the
development of the COCOMO model as
well as the associated models that have
been developed at the CSE. The assump-
tions made about the cost estimating rela-
tionships in these models require that they
be not only developed but also validated
by historical projects. A crucial part of
developing these models is finding repre-
sentative data that can be used to calibrate
the size, multiplier, and exponential fac-
tors contained in the models. The COCO-
MO form is a hypothesis that is tested by
the data. For example, COCOTS data
analysis showed that the COCOMO form
applied to COTS integration, but that
other forms were needed for COTS
assessment and tailoring.
Table 2 summarizes the factors for the
various COCOMO-independent models.
The decision to have a different number
of factors is determined by the Delphi
pr
ocess and confir
med by the data analy-
sis, either of which can add or subtract
factors from a model. However, the same
criteria for factor type are used in all of
the models. The COCOMO II extensions
(shown in Figure 1) are based on the initial
COCOMO II estimates with additional
factors incorporated for the software
c
haracteristic of interest.
Under
standing the scope of
each
model is also a key element in understand-
ing the output it provides. The models in
the COCOMO suite pr
o
vide a specializ
ed
set of estimates that address specific
aspects of development effort for soft-
ware-intensive systems. COCOMO users
are now beginning to use multiple models
in parallel to develop cost estimates that
cover a broader scope that exceeds the
boundaries of traditional software devel-
opment. In this case
,
the models in the
COCOMO suite pr
o
vide a set of tools
that enable more comprehensive cost esti-
mates. However, there are some limita-
tions that exist when using multiple mod-
els together. These limitations are dis-
cussed in the next section.
Using Current Models
Together
Many benefits exist when using multiple
models in parallel. For one, they provide a
more comprehensive set of estimates that
better reflect the true effort associated
with de
veloping a software system. The
effort that is not accounted for in COCO-
MO may be covered by other models such
as COCOTS, COSYSMO, and COSOSI-
MO. Secondly, they enable the estimator
to characterize the system in terms of
multiple views.
However, some complications can
arise when any two of these models are
used in parallel since each of the models
was initially developed as an independent
entity. Just as the process model commu-
nity has found that software engineering,
software development, system engineer-
ing, and other activities are integrated,
have dependencies, and cannot be ade-
quately performed and optimized inde-
pendently of each other, the estimation
community has also found that these
activities cannot be estimated independ-
ently for many of the larger software-
intensi
v
e systems and SoS. Activities need
to be planned and estimated at a program
or project level.
F
eedbac
k fr
om USC CSE af
filiates and
other COCOMO model users [3,4] indi-
cates that users would like a single tool in
which they can do the following:
Identify system and software compo-
nents comprising the software system
of interest.
Easily evaluate various development
approaches and alternatives and their
impacts to cost and sc
hedule.
Under
stand the o
verlaps between
models, if any.
Moving Forward – COCOMO
Suite Unification
Ef
f
or
ts have been initiated at the USC
CSE to develop a framework in which the
key cost models can be integrated to pro-
vide a comprehensive software-system
development effort to users. Once the
models that are most likely to be used
together are integrated, efforts will focus
on the integration of other more special-
ized models. We will also begin with the
models that have a high degree of maturi-
ty.
The purpose of this unification effort
is similar to that of the individual cost
models [2], that is, to help software-inten-
sive system and SoS developers and their
customers reason about the cost and
schedule implications of their develop-
ment decisions, investment decisions, risk
management decisions, and process
improvement decisions.
Key to our approach is distinguishing
between an
integrated set of models versus
a truly
unified model. When a set of mod-
els is integrated, typically each model
becomes an entity in the integrated set
with inputs into one model creating out-
puts that are then fed into subsequent
models. However, when a unified model is
developed, there is a reengineering of the
set of models to come up with an archi-
tecture where the whole of the unified set
is greater than the sum of the parts.
Developing a unified COCOMO suite
model will support the goals to minimize
or eliminate overlap between the models,
provide a relatively comprehensive cover-
age of the SoS, system engineering, and
software development activities, and
develop a relatively simple interface for
specifying inputs as well as a well-integrat-
ed set of outputs.
Key Unification Issues
In August 2004, the CSE held an internal
w
or
kshop to identify key issues for model
unification. The outcome of the work-
shop w
as the identifica
tion of
f
our ar
eas
of focus for unification: (1) selection of
models that must be unified to support
various types of development, (2) identifi-
cation of the overlap between these mod-
els, (3) identification of missing activities
not covered by any of the current models,
and (4) specifica
tion of
the r
equir
ed
par
ameter
s and outputs f
or the r
elated
models in a user-friendly, consistent, and
usable manner. The following sections
describe some of
the more detailed issues
identified as part of the four focus areas.
Model Selection
Many of today’s large software-intensive
systems inte
g
rate legacy capabilities,
COTS software products, and new custom
softw
ar
e subsystems
.
No single COCO-
MO model covers the full life-cycle effort
Software Engineering Technology
22 CROSSTALK The Journal of Defense Software Engineering April 2005
Model Name Scope of Estimate
N
umber of
Additive
F
actors
N
umber of
Exponential
F
actors
N
umber of
Multiplicative
F
actors
COCOMO 81
Software development effort and schedule 1 1 15
COCOMO II Software development effort and schedule 1 5 17
CO
SYSMO
Systems engineering effort
4
114
COCOTS COTS assessment, tailoring, and
i
ntegration effort
31 13
CO
SOSIMO SoS architecture and integration effort 4 6 ---
Table 2: Model Factor Types
Use ... When scope of work to be
performed is ...
COCOMO
II Development of software
components (software
development).
COCO
TS Assessment, tailoring, and
integration of COTS
products.
CO
SYSMO Design, specification, and
i
ntegration (system
engineering) of system
components to be
separatel
y developed for a
s
ingle system.
COSOSIMO Specification, procurement,
and
integration of two or
more separately system-
engineered and developed
systems.
COCOMO
II
with COCOTS
D
evelopment of software
components (software
development), and a
software system, including
assessment, tailoring and
glue-code for integration of
COTS.
COSYSMO and
COCOMO II
System engineering and
software development for a
single system with software-
intensive components.
COSYSMO and
COSOSIMO
System engineering of
individual systems and
integration of the multiple
systems.
COCOMO II,
COSYSMO,
COCOTS, and
COSOSIMO
System engineering,
software development, and
integration of multiple
software-intensive systems
and COTS products.
Table 3: How Current Primary Cost Models Are Typically Used
currently covered.
Table 2: Model Factor Types
COCOMO Suite Methodology and Evolution
April 2005 www
.stsc.hill.af.mil
23
for the development of these types of sys-
tems. The new software development
effort is easily estimated using COCOMO
II. COTS customization effort might be
estimated using another COCOMO suite
model: COCOTS. COSYSMO would typ-
ically be used to estimate the system-level
engineering activities such as feasibility
analysis to support the integration con-
cept, functional analysis of the new
requirements, trade-off studies, prototyp-
ing, performance evaluation, synthesis, and
system verification and validation activi-
ties. And finally, COSOSIMO might be
used to estimate the effort associated with
the integration of the legacy system with
the COTS system and the new custom
software system. CSE corporate affiliates
have identified potential combinations of
cost models that would be of value to
them, including COCOMO/COSYS-
MO/COCOTS and COCOMO/COSYS-
MO/COSOSIMO [4]
.
Model Overlap
Further analysis is required to determine
the extent of any overlap between the var-
ious COCOMO models. Potential overlap
issues were identified with respect to vari-
ous combinations of the primary cost
models as well as with respect to the gen-
eral integration of software and system
components.
COCOMO II and COSYSMO
Model Overlap:
Currently, COCO-
MO II is designed to estimate the soft-
ware effort associated with the analysis
of software requirements and the
design, implementation, and test of
software. COSYSMO estimates the
system engineering effort associated
with the development of the software
system conce
pt,
overall software sys-
tem design, implementation, and test.
K
e
y to under
standing the o
v
er
lap is
deciding which activities are consid-
ered
system engineering and which are
considered
software engineering/develop-
ment
, and how each estimation model
handles these activities.
COSYSMO and COSOSIMO Mod-
el Ov
er
la
p:
COSOSIMO aims to esti
-
ma
te the ef
f
or
t associated with the
architecture definition of a
SoS as well
as the effort associated with the inte-
g
ration of the highest level SoS com-
ponents. On the other hand, COSYS-
MO estimates are done in the context
of a single system and include the
effort needed to define a single, sys-
tem-level architecture, the design of
the system components, and the inte-
gration of those components.
COSYSMO also includes the effort
required for the system development
to support the integration of the sys-
tem component in the target environ-
ment. Further work is required to
understand the subtleties of these
models and e
xact extent of any over-
la
p between these models.
Missing Activities
Are there any key activities missing when
the key models are viewed together? How
are specialty engineering tasks for secure
or sensitive systems handled? How are
non-software system development tasks
handled? What about logistics planning
for operational support? Can effort from
activities not supported by any current
COCOMO model be easily integrated?
Effort Outputs
What granularity should be provided?
One effort value? An effort value for each
of the key models? By software compo-
nent? By system component? By engineer-
ing category (e.g., software, systems engi-
neering, LSI)? By phase/stage of develop-
ment?
Understanding Unification
Issues
To begin to understand these four unifica-
tion issues better and to start developing a
candidate approach for the unified
COCOMO model, efforts were initiated
to better understand the following:
Current model boundaries.
How the current models are typically
used today.
The activities associated with software
development, system engineering, and
SoS integration work performed by
LSIs.
What activities are included in each of
the current primary cost models.
Current Model Boundaries and
Usage
To address this first aspect, we developed
a table to indicate when each model (or set
of models) is typically used (Table 3). As
part of this effort, we developed descrip-
tions that tried to capture information
about the current boundaries of each
model and how those boundaries expand
as the cur
r
ent models ar
e used in an inte
-
grated manner.
Types of Effort Currently Estimated
T
he ne
xt ste
p was to identify a compre-
hensive set of high level, software-inten-
si
v
e system lif
e-cycle activities, the typical
development organizations responsible
for the performance of these activities,
and the scope of the activity typically per-
formed by each development organiza-
tion. Then each activity covered by each of
the primary cost models was identified.
For example, the system engineering
organization is typically responsible for
the system/subsystem requirements and
design, and the software development
organization participates in a support or
review role. Other activities, such as man-
agement, are often performed at various
levels with each development organization
having primary responsibility at their
respective levels.
The results of this effort are shown in
Table 4 (see next page). The shaded activ-
ities under Software Development are cur-
rently covered in COCOMO II and
COCOTS. The shaded activities under
System Engineering are currently estimat-
ed by COSYSMO. The shaded activities
under LSI are currently estimated by
COSOSIMO. The activities that are not
shaded are currently not covered by any of
the models in the COCOMO suite. And,
since the focus of the COCOMO suite is
on software-intensive systems, none of
the items under the hardware develop-
ment column are currently covered.
Some activities such as management
Model Name Sc
ope of Estimate
Number of
A
dditive
F
actors
Number of
E
xponential
F
actors
Number of
M
ultiplicative
F
actors
COCOMO 81
Software development effort and schedule 1 1 15
COCOMO II Software development effort and schedule 1 5 17
COSYSMO
Systems engineering effort
41 14
COCOTS COTS assessment, tailoring, and
integration effort
31 13
COSOSIMO SoS architecture and integration effort 4 6 ---
Table 2: Model Factor Types
Use ... When scope of work to be
performed is ...
COCOMO II Development of software
components (software
development).
COCOTS Assessment, tailoring, and
integration of COTS
products.
COSYSMO Design, specification, and
integration (system
engineering) of system
components to be
separately developed for a
single system.
COSOSIMO Specification, procurement,
and integration of two or
more separately system-
engineered and developed
systems.
COCOMO II
with COCOTS
Development of software
components (software
development), and a
software system, including
assessment, tailoring and
glue-code for integration of
COTS.
COSYSMO and
COCOMO II
System engineering and
software development for a
single system with software-
intensive components.
COSYSMO and
COSOSIMO
System engineering of
individual systems and
integration of the multiple
systems.
COCOMO II,
COSYSMO,
COCOTS, and
COSOSIMO
System engineering,
software development, and
integration of multiple
software-intensive systems
and COTS products.
Table 3: How Current Primary Cost Models Are Typically Used
currently covered.
Table 3: How Current Primary Cost Models
Are Typically Used
and support, involve several organizations
at different layers of the system. Extreme
care needs to be taken when developing
models that cover activities that have
shared responsibilities with hardware,
softw
are, and other players.
T
he identifica
tion of such activities is
the first step in identifying possible over-
laps between models. Further difficulties
arise w
hen dealing with dif
f
er
ent organiza-
tions that use customized work break-
down structures. These, along with the
aforementioned challenges, will continue
to be addressed as the model unification
efforts continue at the CSE.
As seen from the discussions above,
there is still much work to be done in
order to support the unification of the
COCOMO models
. These include the fol-
lo
wing:
1. Develop a more complete description
of activities covered by each model.
T
hese descriptions will allo
w us to
identify, minimize, or eliminate any
overlap between the models and iden-
tify software system-related activities
not covered by any of the models.
2. Determine more precisely how tradi-
tional phase activities and Model
Based (System) Architecting and
Software Engineering/Rational Uni-
fied Pr
ocess [1] phases map to cost-
model acti
vities and ho
w these phases
are integrated at the SoS, system, and
software levels. Work in this area has
alr
ead
y be
gun [5] b
ut some unresolved
issues remain in the context of unified
models.
3. Refine counting rules/definitions for
model inputs and outputs and then
determine how they can be combined
into an efficient, user-friendly unified
model.
4.
Determine typical distribution profiles
f
or ef
fort across all of the activities/
phases in a unified environment.
The initial goal of this effort is to devel-
op a unified model tha
t inc
ludes COCO
-
MO II, COSYSMO, COCOTS and
COSOSIMO as shown in Figure 2. As we
learn from this process, we will begin to add
other models from the COCOMO suite.
Software Engineering Technology
24 CROSSTALK The Journal of Defense Software Engineering April 2005
Responsibilities
Activity
Software
Development
(COCOMO II and
COCOTS)
Hardware
Development
S
ystem
Engineering
(COSYSMO)
LSI
(COSOSIMO)
Management
Primary for
Software Level
Pri
mary for
Hardware Level
Pri
mary for
System Level
Pri
mary for SoS
Level
S
upport Activities (e.g.,
Configuration Management and
Quality Assurance)
Software Level Hardware Level System Level
SoS Component
Level
SoS Definition SoS Component SoS Level
Source Selection and SoS
Component Procurement
Lead
Subsystem Requirements Review Review Elaboration* Lead Inception Lead
System/Subsystem Design Support Support Lead Review
Hardware/Firmware Development Lead
Software Requirements Analysis Elaboration* Lead Inception Lead
Software Product Design Lead Review
Software Implementation/
Programming
Lead Support
Software Test Planning Lead Review/Support
Software Verification and
Validation
Lead
Review/
Support
System Integration/Test Support Support Lead Review
System Acceptance Test Support Support Lead Review
SoS Integration/Test Support Support Review/Support Lead
SoS Acceptance Test Support Support Review/Support Lead
Manuals (User, Operator,
Maintenance)
Software Lead Hardware Lead System Lead SoS Level Lead
Transition (Deploy and Maintain) Support Support System Lead SoS Level Lead
Table 4: Life Cycle Activities
Figure 2: Early Unification Goal
Size Drivers
SoS
COTS
System
Software
Cost Drivers as
appropriate at
each level
SoS, System,
COTS, and
Software
Personnel
Process
LSI
System
COTS
Integration
Software
COSOSIMO/System
COSOSIMO/Software
COSYSMO
COCOMO II
COCOTS
COSOSIMO/System
COSOSIMO/Software
COSYSMO
COCOMO II
COCOTS
Effort
Table 4: Life Cycle Activities
Responsibilities
Activity
Software
Development
(COCOMO II and
COCOTS)
Hardware
Development
S
ystem
Engineering
(COSYSMO)
LSI
(COSOSIMO)
Management
Primary for
Software Level
Primary for
Hardware Level
Primary for
System Level
Primary for SoS
Level
Support Activities (e.g.,
Configuration Management and
Quality Assurance)
Software Level Hardware Level System Level
SoS Component
Level
SoS Definition SoS Component SoS Level
Source Selection and SoS
Component Procurement
Lead
Subsystem Requirements Review Review Elaboration* Lead Inception Lead
System/Subsystem Design Support Support Lead Review
Hardware/Firmware Development Lead
Software Requirements Analysis Elaboration* Lead Inception Lead
Software Product Design Lead Review
Software Implementation/
Programming
Lead Support
Software Test Planning Lead Review/Support
Software Verification and
Validation
Lead
Review/
Support
System Integration/Test Support Support Lead Review
System Acceptance Test Support Support Lead Review
SoS Integration/Test Support Support Review/Support Lead
SoS Acceptance Test Support Support Review/Support Lead
Manuals (User, Operator,
Maintenance)
Software Lead Hardware Lead System Lead SoS Level Lead
Transition (Deploy and Maintain) Support Support System Lead SoS Level Lead
Table 4: Life Cycle Activities
Figure 2: Early Unification Goal
Size Drivers
SoS
COTS
System
Software
Cost Drivers as
appropriate at
each level
SoS, System,
COTS, and
Software
Personnel
Process
LSI
System
COTS
Integration
Software
COSOSIMO/System
COSOSIMO/Software
COSYSMO
COCOMO II
COCOTS
COSOSIMO/System
COSOSIMO/Software
COSYSMO
COCOMO II
COCOTS
Effort
Figure 2: Early Unification Goal
* Model Based (System) Architecting and Software Engineering/Rational Unified Process phase of development.
COCOMO Suite Methodology and Evolution
April 2005 www
.stsc.hill.af.mil
25
The current unification effort will help
establish a framework and define the con-
text for the evolution of the unified model
into something that can provide a compre-
hensive estimate for the development of
software systems and software-intensive
SoS. We will continue to collaborate with
CSE affiliates with the goal of evolving the
COCOMO suite so that it can help users
make better decisions about the develop-
ment of software-intensive systems.
References
1. Boehm, B. Software Engineering
Economics. Prentice Hall, 1981.
2. Boehm, B., et al. Softw
are Cost
Estimation with COCOMO II.
Prentice Hall, 2000.
3. Annual Research Review, Corporate
Affiliate Survey. University of
Southern California Center for
Software Engineering, 16 Mar. 2004.
4.
University of Southern California
Center for Software Engineering.
“Unification Workshop Minutes.”
19th Forum on COCOMO and
Software Cost Modeling, 26 Oct. 2004.
5. Boehm, B., A.W. Brown, V. Basili, and
R. Turner. “Spiral Acquisition of
Software-Intensive Systems of Sys-
tems.”
CrossTalk May 2004: 4-9.
About the Authors
Barry Boehm, Ph.D.,
is the
TRW professor
of software engineer-
ing and director of the
Center for Software
Engineering at the
University of Southern California. He
was previously in technical and man-
agement positions at General
Dynamics, Rand Corp., TRW, and the
Defense Advanced Research Projects
Agency, where he managed the acquisi-
tion of more than $1 billion worth of
advanced information technology sys-
tems. Boehm originated the spiral
model, the Constructive Cost Model,
and the stakeholder win-win approach
to software management and require-
ments negotiation.
E-mail: boehm@usc.edu
Ricardo Valerdi is a
member of the
Technical Staff at the
Aerospace Corporation.
Previously, he worked
as a systems engineer at
Motorola and General Instruments. He
is a doctorate candidate at the
University of Southern California
(USC) in the systems architecting pro-
gram and is a research assistant at USC’s
Center for Software Engineering.
Valerdi has a Bachelor of Science in
electrical engineering from the
University of San Diego and a Master
of Science in systems architecting from
USC.
E-mail: rvalerdi@sunset.usc.edu
J
o
Ann Lane
is cur
r
ent-
l
y a doctor
a
te student a
t
the University of South-
er
n California in systems
ar
c
hitecting
.
Prior to
this, she was a key tech-
nical member of
Science Applications
Inter
na
tional Cor
por
a
tions Software
and Systems Integration Group. She has
o
ver 28 years of experience in the areas
of
softw
ar
e pr
oject management, soft-
ware process definition and implemen-
tation, and metrics collection and analy-
sis. Lane has a Master of
Science de
gree
in computer science from San Diego
State University.
E-mail: jolane@usc.edu
A. Winsor Brown is a
senior research scientist
and assistant dir
ector of
the University of
Southern California
Center f
or Softw
ar
e
Engineering
. As an engineer with
decades of
e
xperience in lar
g
e and small
commer
cial and g
o
v
er
nment contr
act
-
ing companies
, he started his career in
computer har
d
w
ar
e design but shifted
to softw
ar
e within months and r
emains
there today. He has a Bachelor of
Science in engineering science fr
om
R
ensselaer P
ol
ytec
hnic Institute and a
Master of Science in electrical engineer-
ing fr
om Calif
or
nia Institute of
T
ec
hnolo
g
y
.
E-mail:
a
wbr
own@usc.edu
Get Your Free Subscription
Fill out and send us this form.
OO-
ALC/MASE
6022 Fir Ave
Bldg 1
238
Hill AFB, UT 84056-5820
Fax: (801) 777-8069 DSN: 777-8069
Phone: (801) 775-5555 DSN: 775-5555
Or request online at www.stsc.hill.af.mil
N
AME
: ________________________________________________________________________
R
ANK
/G
RADE
: _____________________________________________________
P
OSITION
/T
ITLE
: __________________________________________________
O
RGANIZATION
: _____________________________________________________
A
DDRESS
: ________________________________________________________________
________________________________________________________________
B
ASE
/C
ITY
: ____________________________________________________________
S
TATE
: ___________________________ Z
IP
: ___________________________________
P
HONE
:(_____)_______________________________________________________
F
AX
: ( _ _ _ _ _ ) _____________________________________________________________
E-
MAIL
: __________________________________________________________________
C
HECK
B
OX
(
ES
) T
O
R
EQUEST
B
ACK
I
SSUES
:
N
OV
2003
c
D
EV
.
OF
R
EAL
-T
IME
SW
D
EC
2003
c
M
AN
A
GEMENT
B
ASICS
J
AN
2004
c
I
NFO FROM
S
R
. L
EADERSHIP
M
AR
2004
c
SW P
ROCESS
I
MPROVEMENT
A
PR
200
4
c
A
CQUISITION
M
AY
2004
c
T
ECH
.: P
ROTECTING
A
MER
.
J
UN
2004
c
A
SSESSMENT AND
C
ERT
.
J
UL
Y
200
4
c
T
OP
5 P
R
OJECTS
A
UG
2004
c
S
YSTEMS
A
PPROACH
S
EPT
2004
c
S
OFTWARE
E
DGE
O
CT
200
4
c
P
R
OJECT
M
AN
AGEMENT
N
OV
2004
c
S
OFTWARE
T
OOLBOX
D
EC
2004
c
R
EUSE
J
AN
2005
c
O
PEN
S
OUR
CE
S
W
F
EB
2005
c
R
ISK
M
ANAGEMENT
M
AR
2005
c
T
EAM
S
OFTWARE
P
ROCESS
T
o R
eq
ues
t Bac
k Issues on T
opics N
o
t
Listed Above, Please Contact Karen
Rasmussen at <stsc.customerservice@
hill.af.mil>.
... In general, timely, budget-oriented, error-free projects are not often found between orders delivered by software factory suppliers because they are primarily underestimated and inaccurate in initial estimates. Thus, in response to the losses, it is proposed to analyze point-of-function [16] [18] [19][24] [26] [27] counting samples, contained and stored in historical consulting bases, during the two-year life cycle of the project. ...
... One should even have the definition of which computer technology park should be installed since it is a new project. This type has another strong characteristic because we cannot measure something that does not exist, leaving only the possibility of estimating the function point [16][18] [19][24]. The improvement project addresses the need for changes made in application projects since only something that exists can be altered. ...
... Given the knowledge explored by the Paraconsistent Annotated Evidential Logic Eτ, and with the paraconsistent decision method (MPD) proposed in the studies [3], a scenario is framed with possibilities to support decisionmaking in particular, in this work of assisting managers in deciding the recount of the project in the function point [16][18] [19][26] [27] technique. Also, it ensures the possibility of mitigating many defenses between customers and suppliers. ...
Article
Full-text available
This paper addresses the subject of software measurement, namely, the method of Function Point Analysis, which consists in functionally sizing the software. The sizing activity held between customer specialists and suppliers causes disagreements because it involves multiple vague factors that are difficult to quantify. This paper aims to develop the AITOD- Intelligent Decision-making Support system, based on Paraconsistent Annotated Evidential Logic Eτ. This system aims to contribute to the decision-making process of managers. Such methodology has as a precept the materialization of artefacts derived from concepts. The AITOD product has achieved significant improvements in the process of mitigating project recounts. Through the AITOD system, it was verified that 46 projects would result in approval of 28.57% of the projects, 50 projects would result in approval of 64.10% of the projects. With these results, companies would avoid unnecessary expenses and rework. In the scope of the innovative project, the results achieved on the reduction of values spent on project recounting stands out, being proved the viability of the AITOD product.
... Published by Boehm in 1981, Constructive Cost Model (COCOMO) was a regression-based model that allowed users to "reason about the cost and schedule implications of their development decisions, investment decisions established project budget and schedules, client negotiations and requested changes, cost or schedule or performance or functionality tradeoffs, risk management decisions, and process improvement decisions" as stated in [13]. In short, it is a formula to help users to estimate cost by estimating efforts and development time. ...
... PM stands for person months means the effort of the software development, a is calibration factor, KLOC or Kilo Line of Code is a size of software, b is a scale factor, EM or Effort Multipliers is sum of effort multipliers that influence effort and time of development, and SF or Scale Factors for scaling the KLOC. EM and SF are determined by expert judgement [13]. Meanwhile, in order to obtain software development time, we can use (3) as stated below: ...
... Effort estimation has been carried out mostly by model-based and expert-based methods. Model-based methods are based on information collected from the projects that are already completed with best outcomes, whereas expert-based methods utilise the idea of expertise and stakeholders [1,2]. Software effort estimation (SEE) is one of the most crucial exercises for the software development organisation to make them globally competitive. ...
Article
Full-text available
Abstract Most of the software development organisations frequently use an appreciable amount of resources to estimate the effort in the beginning of the development process. In most of the cases, inaccurate estimates tend to wastage of these resources. Very few generalised models have been found in the literature. These models have been developed using the prototype dataset of the organisation. The project management team of an organisation tries to predict the effort needed for the development of software using various mathematical techniques. These techniques are mostly based on statistical methods (viz. simple linear regression (SLR), multi linear regression, support vector machine, cascade correlation neural network (CCNN) etc.) and some probability‐based models. They use historical data of similar projects. The work presented in this article envisages the use of Support Vector Regression (SVR) and constructive cost model (COCOMO), where SVR can be used for both linear and non‐linear models and COCOMO can be used as a regression model. The proposed hybrid model has been tested on the International Software Benchmarking Standards Group dataset. The data has been grouped according to the size of man power. It has been found that the proposed model yields better results than the SVR or SLR for each group of data in general.
... where C is the number of irrelevant objects that were retrieved, and D is the number of irrelevant objects that were not retrieved. Software managers in 1980s found they needed a way to estimate the cost of software development in software engineering one of this was open-internal Constructive Cost Model (Boehm et al., 2005). COCOMO besides others metrics allowed software managers to reason about cost, performance, functionality trade-offs. ...
Article
Full-text available
The amount of data stored on computers is growing rapidly every year, which makes time-consuming investigation of digital evidence in cybercrime, because of the need to investigate a large amount of data and extract criminal evidence from it. Expert investigation begins with the collection, copying and authentication of each content on the digital medium. The following steps deal with the findings and extract evidence of crime using a variety of methods and tools. Our research deals with the frameworks, methods, models and tools of the search for digital evidence of cybercrime. However, there is as yet no specialized method and tool available to assist an expert in reducing the size of investigated data and to solve the problem of searching for and identifying digital evidence of cybercrime due to the lack of specialized tools and techniques to automate expert investigation. In this paper we propose cybercrime forensic investigation tool based on the digital evidence object model
... For example the number of source lines of code and different measurement variations of them. First of all we ought to mention that size measures are quite effective in effort estimation [215]. However it is misleading to use size measures for assessing quality for the need of any type of improvements. ...
Thesis
Full-text available
Large software development companies primarily deliver value to their customers by continuously enhancing the functionality of their products. Continuously developing software for customers insures the enduring success of a company. In continuous development, however, software complexity tends to increase gradually, the consequence of which is deteriorating maintainability over time. During short periods of time, the gradual complexity increase is insignificant, but over longer periods of time, complexity can develop to an inconceivable extent, such that maintenance is no longer profitable. Thus, proactive complexity assessment methods are required to prevent the gradual growth of complexity and instead build quality into developed software. Many studies have been conducted to delineate methods for complexity assessment. These focus on three main areas: 1) the landscape of complexity, i.e., the source of the complexity; 2) the possibilities for complexity assessment, i.e., how complexity can be measured and whether the results of assessment reflects reality; and 3) the practicality of using complexity assessment methods, i.e., the successful integration and use of assessment methods in continuous software development. Partial successes were achieved in all three areas. Firstly, it is clear that complexity is understood in terms of its consequences, such as spent time or resources, rather than in terms of its structure per se, such as software characteristics. Consequently, current complexity measures only assess isolated aspects of complexity and fail to capture its entirety. Finally, it is also clear that existing complexity assessment methods are used for isolated activities (e.g., defect and maintainability predictions) and not for integrated decision support (e.g., continuous maintainability enhancement and defect prevention). This thesis presents 14 new findings across these three areas. The key findings are that: 1) Complexity increases maintenance time multifold when software size is constant. This consequential effect is mostly due to a few software characteristics, and whilst other software characteristics are essential for software development, they have an insignificant effect on complexity growth; 2) Two methods are proposed for complexity assessment. The first is for source code, which represents a combination of existing complexity measures to indicate deteriorating areas of code. The second is for textual requirements, which represents new complexity measures that can detect the inflow of poorly specified requirements; 3) Both methods were developed based on two critical factors: (i) the accuracy of assessment, and (ii) the simplicity of interpretation. The methods were integrated into practitioners’ working environments to allow proactive complexity assessment, and prevent defects and deteriorating maintainability. In addition, several additional key observations were made: Primarily the focus should be in creating more sophisticated software complexity measures based on empirical data indicative of the code characteristics that most influence complexity. It is desirable to integrate such complexity assessment measures into the practitioners’ working environments to ensure that complexity is assessed and managed proactively. This would allow quality to be built into the product rather than having to conduct separate, post-release refactoring activities.
Chapter
The software, generally understood as a sequence of computer instructions for performing functions on devices such as hardware, falls within the category of intangible assets and, due to its pervasiveness in people’s daily life, represents an essential tool for any user. As a result, some complex legal issues, as well as sophisticated economic evaluation approaches come out, to estimate the damage caused by counterfeiting, in an evolutionary scenario characterized by sharp technological discontinuities. The database indicates a set of data, homogeneous in content and format; these data are stored in a computer and interrogated via a computer-implemented system by using the provided access keys. The estimation follows the general evaluation criteria of the other intangible assets—the income, cost, or market approach—to be adapted to the specific characteristics of the software or database.KeywordsSoftwareDatabaseInternetValuationPatentsCopyrightAlgorithmInteroperabilityOpen-sourceCO.CO.MOHardwareOperating systemHostingSoftware as a Service (SaaS)Application Service Provider (ASP)Software HouseCloud ComputingComputer ScienceLicenseCustomizationData MiningData protection
Article
The key challenge that project managers face during software development is the accurate prediction of the software effort. Improper prediction leads either to overestimation or underestimation of the software effort, which can have disastrous consequences for the stakeholders. This article attempts to design a model that gives an accurate prediction of effort in the initial phase of the software development lifecycle. The proposed model uses multilayer perceptron (MLP) and the generalized linear model (GLM) with the ensemble technique for the learning purpose. The model is trained and validated using the ISBSG dataset. The proposed model is compared for performance with two baseline models: MLP and GLM. The results show that the proposed model outperforms most of the baseline models against different performance metrics.
Article
Full-text available
The software cost estimation is the process of predicting the most realistic amount of effort required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, and investment analyses, pricing processes and bidding rounds. For example, estimation of value estimation and danger examination is a real issue in programming undertaking administration. As programming advancement has turned into a fundamental speculation for some associations, precise programming expense estimation models are expected to adequately foresee, screen, control and evaluate programming improvement. Programming expense estimation is a testing and cumbersome errand. Then again, the approach utilized for the estimation of programming exertion by relationship is not ready to handle the unmitigated information in an unequivocal and exact way. The nature of an expense estimation model is less ascribed to the introductory assessment, but instead the pace at which the appraisals merges to the genuine expense of the task. COCOMO is a well known algorithmic model for expense estimation whose expense variables can be customized to the individual improvement environment, which is imperative for the precision of the expense gauges. More than one strategy for expense estimation ought to be carried out so that there is some correlation accessible for the evaluations. This is particularly imperative for extraordinary undertakings. Cost estimation must be done more diligently throughout the project life cycle so that in the future there are fewer surprises and unforseen delays in the release of a product. In this paper, we present a soft computing framework to tackle this challenging problem. Estimating the work-effort and the schedule required to develop and/or maintain a software system is one of the most critical activities in managing software projects.
Chapter
The software, generally understood as a sequence of computer instructions for performing functions on devices such as hardware, falls within the category of intangible assets, and due to its pervasiveness in people’s daily life, it represents an essential tool for any user. As a result, some complex legal issues, as well as sophisticated economic evaluation approaches come out, to estimate the damage caused by counterfeiting, in an evolutionary scenario characterized by sharp technological discontinuities. The database indicates a set of data, homogeneous in content and format; these data are stored in a computer and interrogated via a computer-implemented system by using the provided access keys. The estimation follows the general evaluation criteria of the other intangible assets—the income, cost, or market approach—to be adapted to the specific characteristics of the software or database.
Chapter
Since the time of Aristotle’s thinking of logic to being a tool for orderly think, has maintained its importance until the present times. So soon, studies of the non-classical logical calls (Abe in 4th International Workshop on Soft Computing Applications. IEEE, pp. 11–18, 2010 [1]) have become a powerful tool as an aid in the making of decisions. The Paraconsistent logic calls attention to the clarity of containing provisions contrary to some of the basic principles of Aristotelian logic, such as the principle of contradiction. In this article, the use of technology allows proposing a structured organization in the process for use of Paraconsistent artificial neural networks. This process aims to be a facilitator in supporting the construction of the decision support (Abe in 4th International Workshop on Soft Computing Applications. IEEE, pp. 11–18, 2010 [1]) with the announcements for project recount in the function point analysis technique. Cite this paper as: de Lima L.A., Abe J.M., Martinez A.A.G., de Frederico A.C., Nakamatsu K., Santos J. (2020) Process and Subprocess Studies to Implement the Paraconsistent Artificial Neural Networks for Decision-Making. In: Jain V., Patnaik S., Popențiu Vlădicescu F., Sethi I. (eds) Recent Trends in Intelligent Computing, Communication and Devices. Advances in Intelligent Systems and Computing, vol 1006. Springer, Singapore
Article
A summary is presented of the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation.
Article
The old and new sources of risks encountered in acquiring and developing complex software-intensive systems of systems (SISOS) are discussed. A top-10 list of risks and challenges that needs to be resolved in developing and evolving software-intensive systems is also provided. These risks can be addressed through risk analysis, risk management planning and control, and application of the risk-driven Win-Win Spiral Model. The Win-Win Spiral Development and evolutionary acquisition process is helpful for identifying and coping with SISOS risks.
Unification Workshop Minutes
University of Southern California Center for Software Engineering. " Unification Workshop Minutes. " 19th Forum on COCOMO and Software Cost Modeling, 26 Oct. 2004.