Academic COSYSMO User Manual v1.1
Academic COSYSMO User Manual v1.1
Academic COSYSMO User Manual v1.1
Version 1.1
September 2006
By:
Ricardo Valerdi
MIT Lean Aerospace Initiative
rvalerdi@mit.edu
This work has been funded by the MIT Lean Aerospace Initiative Consortium, the USC Center for
Software Engineering Corporate Affiliates, and the US Air Force Space & Missile Systems Center
Office of the Chief Engineer.
Table of Contents
1.
2.
Model Usage................................................................................................17
a)
b)
c)
d)
e)
3.
4.
Local calibration...........................................................................................28
a)
b)
c)
d)
e)
Page 2 of 29
Acknowledgements
The information in this document is representative of the work accomplished
since 2001 by the COSYSMO Working Group in conjunction with the INCOSE
Measurement Working Group. The motivation behind the first implementation of
the COSYSMO model came from Gary Thomas (Raytheon- Garland, TX). Other
individuals who have contributed to this document are: Tony Hart (General
Dynamics Pittsfield, MA), Joe Emerick (Lockheed Martin Gaithersburg, MD),
and Chris Miller (SSCI Herndon, VA).
Page 3 of 29
Boehm, B. W., 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.
2
Valerdi, R., The Constructive Systems Engineering Cost Model (COSYSMO), unpublished
PhD Dissertation, University of Southern California, May 2005.
3
ANSI/EIA-632-1988 Processes for Engineering a System, 1999.
4
ISO/IEC 15288:2002(E) Systems Engineering - System Life Cycle Processes, 2002.
Page 4 of 29
Page 5 of 29
b) COSYSMO Algorithm
Each parameter in the COSYSMO Algorithm is part of the Cost Estimating Relationship (CER)
that was defined by systems engineering experts.
E
PM NS
14
= A ( we ,k e ,k + wn ,k n ,k + wd ,k d ,k ) EM j
k
j =1
Where:
PMNS = effort in Person Months (Nominal Schedule)
A = calibration constant derived from historical project data
k = {REQ, IF, ALG, SCN}
wx = weight for easy, nominal, or difficult size driver
x = quantity of k size driver
E = represents diseconomies of scale
EM = effort multiplier for the jth cost driver. The geometric product results in an overall effort
adjustment factor to the nominal effort.
The size of the system is the weighted sum of the REQ, IF, ALG, and SCN parameters and
represents the additive part of the model while the EM factor is the product of the 14 effort
multipliers and represents the multiplicative part of the model. This algorithm is built into the
academicCOSYSMO spreadsheet in cell E29 where the systems engineering person month
estimate is displayed.
Detailed definitions for these parameters are provided in the following sections.
c) Size Drivers
The size drivers should be entered first because they require the user to think about the
quantitative parameters that determine size of the system in terms of systems engineering. The
value of the size drivers can be entered in the yellow cells show below. The spreadsheet will
keep a running total of the number of equivalent requirements in cell F9 which is a weighted sum
of the four size drivers.
Although there are twelve available cells for data entry, an estimate can be obtained by entering
information into only one cell. This is not recommended because the absence of project size
drivers typically means that incomplete information exists which is not a good time to do an
estimate.
Page 6 of 29
Nominal
- Familiar
- Can be traced to source with
some effort
- Some overlap
Difficult
- Complex to implement or
engineer
- Hard to trace to source
- High degree of
requirements overlap
Nominal
- Moderate complexity
- Loosely coupled
- Moderate consensus
- Predictable behavior
Difficult
- Complex protocol(s)
- Highly coupled
- Low consensus
- Poorly behaved
- Straightforward structure
- Simple data
- Timing not an issue
- Adaptation of library-based
solution
Nominal
- Straight forward calculus
Page 7 of 29
Difficult
- Complex constrained
optimization; pattern
recognition
- Recursive in structure
with distributed control
- Noisy, ill-conditioned data
- Dynamic, with timing and
uncertainty issues
- Simulation and modeling
involved
Nominal
- Loosely defined
- Moderately coupled
- Timelines a constraint
- Moderate number or
complexity of off-nominal
threads
Difficult
- Ill defined
- Tightly coupled or many
dependencies/conflicting
requirements
- Tight timelines through
scenario network
- Many or very complex offnominal threads
d) Cost Drivers
The cost drivers in the model represent the multiplicative part of the model introduced. These
drivers are also referred to as effort multipliers since they affect the entire systems engineering
effort calculation in a multiplicative manner. Assigning ratings for these drivers is not as straight
forward as the size drivers mentioned previously. The difference is that most of the cost drivers
are qualitative in nature and require subjective assessment in order to be rated. Provide a rating
for each of the cost drivers that apply to your project/system of interest by using the drop-down
box in the yellow cells of the spreadsheet. As values are selected, the cells will change colors to
represent either a cost savings (green) or a cost penalty (red).
The model displays the composite effort multiplier in cell D25 which is a running total of the
product of the fourteen cost drivers. It is an indicator of the overall environment in which the
systems engineering is being performed.
Page 8 of 29
1. Requirements Understanding
This cost driver rates the level of understanding of the system requirements by all
stakeholders including the systems, software, hardware, customers, team members, users,
etc. Primary sources of added system engineering effort are unprecedented systems,
unfamiliar domains, or systems whose requirements are emergent with use.
Very Low
Poor: emergent
requirements or
unprecedented
systems
Low
Minimal: many
undefined areas
Nominal
Reasonable: some
undefined areas
High
Strong: few
undefined areas
Very High
Full: understanding
of requirements,
familiar systems
2. Architecture Understanding
This cost driver rates the relative difficulty of determining and managing the system
architecture in terms of platforms, standards, components (COTS, GOTS, NDI, new),
connectors (protocols), and constraints. This includes tasks like systems analysis, tradeoff
analysis, modeling, simulation, case studies, etc.
Very low
Poor
understanding
of architecture
and COTS,
unprecedented
system
>6 level WBS
Low
Minimal
understanding of
architecture and
COTS, many
unfamilar areas
Nominal
Reasonable
understanding of
architecture and
COTS, some
unfamiliar areas
High
Strong
understanding of
architecture and
COTS, few
unfamiliar areas
2 level WBS
Very High
Full
understanding of
architecture,
familiar system
and COTS
Criticality
Very low
Simple; single
dominant KPP
Slight
inconvenience
Low
Low, some
coupling
among KPPs
Easily
recoverable
losses
Nominal
Moderately
complex,
coupled KPPs
Some loss
High
Difficult,
coupled KPPs
High financial
loss
Very High
Very complex,
tightly coupled
KPPs
Risk to human
life
4. Migration Complexity
This cost driver rates the extent to which the legacy system affects the migration complexity,
if any. Legacy systems components, databases, workflows, environments, etc., may affect
the new system implementation due to new technology introductions, planned upgrades,
increased performance, business process reengineering, etc.
Legacy
contractor
Effect of
legacy
system on
Nominal
Self; legacy
system is well
documented.
Original team
largely available
Everything is
new; legacy
system is
High
Self; original
development team
not available;
most
documentation
available
Migration is
restricted to
integration only
Page 9 of 29
Very High
Different
contractor; limited
documentation
Extra High
Original contractor
out of business;
no documentation
available
Migration is
related to
integration and
Migration is
related to
integration,
new
system
completely
replaced or nonexistent
development
development,
architecture and
design
5. Technology Risk
This represents the maturity, readiness, and obsolescence of the technology being
implemented. Immature or obsolescent technology will require more Systems Engineering
effort.
Viewpoint
Lack of
Maturity
Lack of
readiness
Very low
Technology
proven and
widely used
throughout
industry
Mission proven
(TRL 9)
Low
Proven through
actual use and
ready for
widespread
adoption
Concept
qualified (TRL
8)
Obsolescence
Nominal
Proven on pilot
projects and
ready to roll-out
for production
jobs
Concept has
been
demonstrated
(TRL 7)
Technology is
the state of the
practice,
Emerging
technology could
compete in
future
High
Ready for pilot
use
Very High
Still in the
laboratory
Proof of
concept
validated (TRL
5 & 6)
Technology is
stale. New and
better
technology is
on the horizon
in near -term
Concept
defined (TRL 3
& 4)
Technology is
outdated and
use should be
avoided in new
system. Spare
parts supply is
scarce.
Very low
General goals,
stories
Low
Broad
guidance,
flexibility is
allowed
Nominal
Risk-driven
degree of
formality
High
Partially
streamlined
process,
largely
standardsdriven
Detail
Minimal or no
specified
documentation
and review
requirements
relative to life
cycle needs
Relaxed
documentation
and review
requirements
relative to life
cycle needs
Risk-driven
degree of
formality,
amount of
documentation
and reviews in
sync and
consistent with
life cycle needs
of the system
High amounts
of
documentation,
more rigorous
relative to life
cycle needs,
some revisions
required
Page 10 of 29
Very High
Rigorous,
follows
strict
standards
and
requirement
s
Extensive
documentat
ion and
review
requirement
s relative to
life cycle
needs,
multiple
revisions
required
Nominal
Single
installation site or
configuration
Operating
environment
Existing facility
meets all known
environmental
operating
requirements
Platforms
High
2-3 site or
diverse
installation
configurations
Moderate
environmental
constraints.
Controlled
environment
HVAC
constraints or
electrical power
constraints
Very High
4-5 sites or
diverse
installation
configurations
Ruggedized
mobile landbased
requirements.
Some
information
security
requirements.
Coordination
several
regulatory or
cross functional
agencies
required.
< 3 types of
platforms being
installed and or
being phased out
or replaced
Homogeneous
platform
4-7 types of
platforms being
installed and or
being phased out
or replaced.
Compatible
platforms
Typically
networked using
a single industry
standard protocol
Typically
networked using
a single industry
standard protocol
and multiple
operating
systems
8-10 types of
platforms being
installed and or
being phased out
or replaced
Heterogeneous,
but compatible
platform
Typically network
using mix of
industry standard
protocols and
proprietary
protocols with
single operating
systems
Page 11 of 29
Extra High
> 6 sites or
diverse
installation
configuration
Harsh
environment
(space, sea,
airborne),
sensitive
information
security
requirements.
Coordination
between 3 or
more regulatory
or cross
functional
agencies
required.
> 10 types of
platforms being
installed and or
being phased out
or replaced
Heterogeneous,
incompatible
platforms
Typically
networked using
a mix of industry
standard
protocols and
proprietary
protocols with
multiple
operating
systems.
Very Low
1
Low
2
Nominal
3 to 5
High
6 to 7
Very High
>7
Focused
on single
product
Some
vertical and
horizontal
coordination
More complex
interdependencies
coordination and
trade-off analysis
Very complex
interdependencies
coordination and
trade-off analysis
Extremely complex
interdependencies
coordination and
trade-off analysis
Compatibilit
y
Familiarity
Very Low
Stake holders
with diverse
domain
experience,
task nature,
language,
culture,
infrastructure
of highly
heterogeneou
s stakeholder
communities
Highly
conflicting
organizational
objectives
Unfamiliarnever worked
together
Low
Heterogeneou
s stakeholder
community.
Some
similarities in
language and
culture.
Nominal
Shared
project
culture.
High
Strong team
cohesion and
project
culture.
Multiple
similarities in
language and
expertise.
Very High
Virtual
homogeneous
stake holder
communities.
Institutionalize
d project
culture.
Converging
organizational
objectives
Compatible
organization
al objectives
Strong mutual
advantage to
collaboration.
Willing to
collaboratelittle
experience
Some
familiarity
Clear roles
and
responsibilitie
s.
High level of
familiarity
Page 12 of 29
Extensive
successful
collaboration
Low
35th
percentile
Nominal
55th
percentile
High
75th
percentile
Very High
90th
percentile
Annual
Turnover
Very Low
Less than 2
months
48%
Low
1 yr
continuous
experience or
other similar
technical
tasks in
similar job
24%
Nominal
3 years of
continuous
experience
12%
Page 13 of 29
High
5 years of
continuous
experience
6%
Very High
10 years of
continuous
experience
3%
SEMP Sophistication
Assessment
Rating
The consistency and effectiveness of the project team at performing SE processes. This may
be based on assessment ratings from a published process model (e.g., CMMI, EIA-731, SECMM, ISO/IEC15504). It can alternatively be based on project team behavioral
characteristics, if no assessment has been performed.
Very Low
Level 0 (if
continuous
model)
Low
Level 1
Nominal
Level 2
High
Level 3
Very High
Level 4
Extra High
Level 5
Ad Hoc
approach to
process
performance
Performed
SE process,
activities
driven only
by immediate
contractual or
customer
requirements,
SE focus
limited
Defined SE
process,
activities
driven by
benefit to
project, SE
focus is
through
operation,
process
approach
driven by
organizational
processes
tailored for
the project
Quantitatively
Managed SE
process,
activities
driven by SE
benefit, SE
focus on all
phases of the
life cycle
Optimizing
SE process,
continuous
improvement,
activities
driven by
system
engineering
and
organizational
benefit, SE
focus is
product life
cycle &
strategic
applications
Management
judgment is
used
SEMP is
used in an
ad-hoc
manner only
on portions of
the project
that require it
Managed SE
process,
activities
driven by
customer and
stakeholder
needs in a
suitable
manner, SE
focus is
requirements
through
design,
projectcentric
approach
not driven by
organizational
processes
Project uses
a SEMP with
some
customization
Highly
customized
SEMP exists
and is used
throughout
the
organization
The SEMP is
thorough and
consistently
used;
organizational
rewards are
in place for
those that
improve it
Organization
develop best
practices for
SEMP; all
aspects of the
project are
included in
the SEMP;
organizational
rewards exist
for those that
improve it
Page 14 of 29
Corporate
collaboration
barriers
Communic
ations
Collocation
Low
Multi-city
and multinational,
considerable
time zone
impact
Nominal
Multi-city or
multicompany,
some time
zone effects
High
Same city or
metro area
Some
phone, mail
Individual
phone, FAX
Narrowband
e-mail
Wideband
electronic
communication
Severe
export and
security
restrictions
Mild export
and security
restrictions
Some
contractual
&
Intellectual
property
constraints
Some
collaborative
tools &
processes in
place to
facilitate or
overcome,
mitigate
barriers
Very High
Same building
or complex,
some colocated
stakeholders or
onsite
representation
Wideband
electronic
communication,
occasional
video
conference
Widely used
and accepted
collaborative
tools &
processes in
place to
facilitate or
overcome,
mitigate
barriers
Extra High
Fully colocated
stakeholders
Interactive
multimedia
Virtual team
environment
fully
supported
by
interactive,
collaborative
tools
environment
Low
Simple SE tools,
little integration
Nominal
Basic SE tools
moderately
integrated
throughout the
systems
engineering
process
Page 15 of 29
High
Strong, mature
SE tools,
moderately
integrated with
other disciplines
Very High
Strong, mature
proactive use of
SE tools
integrated with
process, modelbased SE and
management
systems
Technical
Management
Process Categories
Supply Process
Acquisition Process
Planning Process
Assessment Process
Control Process
Requirements
Definition Process
System
Design
Product
Realization
Solution Definition
Process
Implementation
Process
Transition to Use
Process
Systems Analysis
Process
Requirements
Validation Process
Technical
Evaluation
System Verification
Process
End Products
Validation Process
Activities
(1) Product Supply
(2) Product Acquisition, (3) Supplier Performance
(4) Process Implementation Strategy, (5) Technical
Effort Definition, (6) Schedule and Organization, (7)
Technical Plans, (8)Work Directives
(9) Progress Against Plans and Schedules, (10)
Progress Against Requirements, (11) Technical
Reviews
(12) Outcomes Management, (13) Information
Dissemination
(14) Acquirer Requirements, (15) Other Stakeholder
Requirements, (16) System Technical
Requirements
(17) Logical Solution Representations, (18) Physical
Solution Representations, (19) Specified
Requirements
(20) Implementation
(21) Transition to use
(22) Effectiveness Analysis, (23) Tradeoff Analysis,
(24) Risk Analysis
(25) Requirement Statements Validation, (26)
Acquirer Requirements, (27) Other Stakeholder
Requirements, (28) System Technical
Requirements, (29) Logical Solution
Representations
(30) Design Solution Verification, (31) End Product
Verification, (32) Enabling Product Readiness
(33) End products validation
Page 16 of 29
2. Model Usage
a) Determining size via REQ, INTF, ALG, SCN
Requirements
Different systems will exhibit different levels of requirements decomposition depending on the
application domain, customers ability to write good system requirements, and the functional size
of the system. The following rules should increase the reliability of requirements counting by
different organizations on different systems regardless of their application domain:
1. Determine the system of interest. For an airplane, the system of interest may be the
avionics subsystem or the entire airplane depending on the perspective of the
organization interested in estimating systems engineering. This key decision needs to be
made early on to determine the scope of the COSYSMO estimate and identify the
requirements that are applicable for the chosen system.
2. Decompose system objectives, capabilities, or measures of effectiveness into
requirements that can be tested, verified, or designed. The decomposition of
requirements must be performed by the organization using COSYSMO because the initial
set of requirements provided by the customer may not be representative of the actual
systems engineering effort required for the contractor to deliver the system. The level of
decomposition of interest for COSYSMO is the level in which the system will be designed
and tested; which is equivalent to the TYPE A, System/Segment Specification (MIL-STD
490-A 1985). For some organizations, these are referred to as systems engineering
requirements because they reflect the level at which systems engineers do their job.
3. Provide a graphical or narrative representation of the system of interest and how it
relates to the rest of the system. This step focuses on the hierarchical relationship
between the system elements. This information can help describe the size of the system
and its levels of design. It serves as a sanity check for the previous two steps.
4. Count the number of requirements in the system/marketing specification or the
verification test matrix for the level of design in which systems engineering is
taking place in the desired system of interest. The focus of the counted requirements
needs to be for systems engineering. Lower level requirements may not be applicable if
they have no effect on systems engineering. Requirements may be counted from the
Requirements Verification Trace Matrix (RVTM) or an equivalent construct that is
used for testing system requirements. The same rules apply as before: all counted
requirements must be at the same design or bid level and lower level requirements must
be disregarded if they do not influence systems engineering effort.
5. Determine the volatility, complexity, and reuse of requirements. Once the quantity
of requirements has been determined, the three adjustment factors can be applied.
Currently three complexity factors have been determined: easy, nominal, and difficult.
These weights for these factors were determined using expert opinion through the use of
a Delphi survey. The volatility and reuse factors are optional and depend on the version
of COSYSMO implementation being used.
The objective of the five steps is to lead users down a consistent path of similar logic when
determining the number of system requirements for the purposes of estimating systems
engineering effort in COSYSMO. It has been found that the level of decomposition described in
step #2 may be the most volatile step as indicated by the data collected thus far. To alleviate
this, a framework for software use case decomposition5 was adopted. The basic premise behind
the framework is that different levels exist for specific system functions. Choosing the appropriate
level can provide a focused basis for describing the customer and developer needs. A metaphor
is used to describe four levels: sky level, kite level, sea level, and underwater level. The sea level
goals represent a user level task that is the target level for counting requirements in COSYSMO.
Page 17 of 29
Interfaces
Similar challenges of decomposition exist for the # of interfaces driver because interfaces are
often defined at multiple levels of the system hierarchy. The target level for counting interfaces
involves the following rules:
1. Focus on technical interfaces only. Other parameters in the model address
organizational interfaces.
2. Identify the interfaces that involve systems engineering for your system of interest.
Counting interfaces at the integrated circuit or software subroutine level is often too low.
Sometimes there may be multiple levels of interfaces connecting higher system
elements, lower system elements, and elements at the same level of the system
hierarchy. Identify which level is driving the amount of systems engineering effort in your
organization and focus on it.
3. Determine the number of unique interface types. If twenty interfaces exist but there
are only two types of unique interfaces, then the relevant number to count is two. This is
especially true if there is systems engineering effort involved with developing a unique
test procedure for each of the unique interfaces.
4. Focus on the logical aspects of the interface to determine complexity. This
provides a better indicator of the complexity of each interface from a systems engineering
standpoint. Counting the number of wires in an interface may not be a good indicator.
Instead, the protocol used or the timing requirement associated with the interface will be
a better indicator of complexity.
5. Consider directionality of the interface. Bidirectional interfaces count as two
interfaces because they require coordination on both ends.
Algorithms
Since the influence of algorithms can vary by organization, the process of identifying an algorithm
for COSYSMO can also be different. Ultimately the sources from which the number of algorithms
can be obtained change as the system definition matures. For example, during the conceptual
stage of a system, where there is a limited amount of information available, the only indicators
may be functional block diagrams. As the system design evolves and more uncertainties are
resolved, there are more sources available to aid in the estimation of algorithms. Table 2
includes examples of the entities that are available at different stages of the system life cycle and
their corresponding attributes that can be used to estimate the number of algorithms. They are
listed in typical order of availability; the first entities are typically available during the conceptual
stages while the latter ones are available as the system design evolves.
Table 2. Candidate Entities and Attributes for Algorithms
Entities
Historical database
Functional block diagram
Mode description document
Risk analysis
System specification
Subsystem description documents
Configuration baseline
Attributes
# of algorithms
# of functions that relate to algorithms
algorithms
algorithm related risks
algorithms
algorithms
technical notes
The attributes may provide more detailed information about the functions that the algorithms
perform. This can aid in determining the complexity of that algorithm, an important step in
estimating size for COSYSMO.
The approach for determining the quantity of algorithms in a system is unavoidably different for
each organization. System algorithms are unique in the sense that they are highly related to the
# of Requirements and # of Interfaces size drivers. If not explicitly defined up front, the
number of algorithms can be derived from a system-level requirement or deduced from the
properties of an interface. In terms of systems engineering effort, the existence of an algorithm
Page 18 of 29
introduces additional work related to simulation, implementation, test cases, documentation, and
support. These activities are illustrated in Figure 1.
Page 19 of 29
Operational Scenarios
In a similar way requirements were defined at sea level, operational scenarios must also be
identified at a level that is of interest to systems engineering. Operational scenarios are often
obtained via test cases or system use cases since they represent end-to-end system functionality
or independent capabilities of a system. For example, an operational scenario for a Windows XP
computer is to operate in safe mode. Use case diagrams in UML are also helpful for
determining the number and complexity of use cases in a system.
Page 20 of 29
Guidance on how to identify the best level of system decomposition (also referred to as sea
level) at which to count requirements is discussed in section 2. a). Guidance on how to allocate
requirements among the three complexity categories is discussed in section 2. c). Additional
approaches to facilitate the size driver counting process are provided in section 2. e). and include
the use of systems engineering tools (i.e., DOORS) and frameworks (i.e., DODAF).
Strategy 2: Pure requirements
The requirements specification document often emerges as the dominant source for functional
size because requirements are commonly accepted vehicles for describing detailed system
functionality. Equivalent requirements can serve as a baseline measure of functional size which
could otherwise be represented by the three other size drivers.
In cases where interfaces, algorithms, or operational scenarios are not available, functional size
can be estimated by using requirements only. The translation of system attributes across
easy/nominal/difficult requirements may be less reliable because the complexity aspects of the
other size drivers may be lost in translation.
Strategy 3: Equivalent requirements
In some situations, characteristics of the system may be described in documents where
requirements are not mentioned. These include interface control documents, functional block
diagrams, and operational concept documents. In this case, interfaces, algorithms, or high-level
operational scenarios may be the only way to quantify systems engineering effort due to the
absence of requirements. This situation is common during the early stages of system
conceptualization, and ironically, the time when COSYSMO is most useful despite the high
degree of uncertainty of the system definition. Nevertheless, the quantities of interfaces,
algorithms, and scenarios should be entered into the model. Mathematically, these quantities are
converted into equivalent requirements in the model since all parameter weights are relative to
Nominal # of System Requirements.
Regardless of which strategy is used, COSYSMO assumes that the systems engineering effort
being counted has life cycle considerations that include works associated with conceptualize,
develop, OT&E, and transition to operation.
400
Easy
- Simple to implement
- Traceable to source
- Little requirements overlap
400
Nominal
- Familiar
- Can be traced to source with
some effort
- Some overlap
Page 21 of 29
200
Difficult
- Complex to implement or
engineer
- Hard to trace to source
- High degree of
requirements overlap
The model algorithm will apply the appropriate weights, from Figure 2, and calculate the
equivalent number of requirements as follows:
400 easy requirements * 0.5 weight for easy = 200 equivalent requirements
400 nominal requirements * 1.0 weight for nominal = 400 equivalent requirements
200 difficult requirements * 5.0 weight for difficult = 1,000 equivalent requirements
TOTAL = 1,600 equivalent requirements
Rather than the 1,000 original requirements defined in the system specification, COSYSMO will
estimate systems engineering effort based on 1,600 equivalent requirements due to the
distribution of complexity selected by the user.
Page 22 of 29
Requirements
Understanding
Architecture
Understanding
Level of Service
Requirements
Migration Complexity
Technology Risk
Documentation
# and diversity of
installations/platforms
# of recursive levels
in the design
Stakeholder team
cohesion
Personnel/team
capability
Personnel
experience/continuity
Process capability
Multisite coordination
Tool support
Very
Low
Low
Nominal
High
Very
High
1.85
1.36
1.00
0.77
0.60
1.62
1.27
1.00
0.81
0.65
0.62
0.79
0.70
0.82
0.84
0.91
1.00
1.00
1.00
1.00
1.32
1.24
1.32
1.13
1.74
1.54
1.74
1.28
1.00
1.23
1.51
0.80
0.89
1.00
1.21
1.46
1.50
1.22
1.00
0.81
0.66
1.48
1.22
1.00
0.81
0.66
1.46
1.46
1.33
1.34
1.21
1.21
1.15
1.16
1.00
1.00
1.00
1.00
0.82
0.88
0.90
0.85
0.67
0.77
0.80
0.73
Extra
High
EMR
3.08
2.49
2.81
1.92
1.86
1.92
2.49
1.56
1.86
1.83
2.27
2.28
2.18
0.68
0.72
2.15
1.85
1.84
For example, the Requirements Understanding driver is worded positively since there is an effort
savings associated with High or Very High understanding of the requirements. This is indicated
by multipliers of 0.77 and 0.60, respectively representing a 23% and 40% savings in effort
compared to the nominal case. Alternatively, the Technology Risk driver has a cost penalty of
32% for High and 74% for Very High. Not all rating levels apply to all of the drivers. Again, it is a
matter of how the drivers are defined. The Migration Complexity driver, for example, only
contains ratings at Nominal and higher. The rationale behind this is that the more complex the
legacy system migration becomes, the more systems engineering work will be required. Not
having a legacy system as a concern, however, does not translate to a savings in effort. The
absence of a legacy system is the Nominal case which corresponds to a multiplier of 1.0.
The cost drivers are compared to each other in terms of their range of variability, or Effort
Multiplier Ratio. The EMR column in Table 3 is representative of an individual drivers possible
influence on systems engineering effort. The four most influential cost drivers are: Requirements
Understanding, Level of Service Requirements, Technology Risk, and Architecture
Understanding. The least influential, Documentation, # of Installations, Tool Support, and # of
Recursive Levels in the Design were kept because users wanted to have the capability to
estimate their impacts on systems engineering effort. The relatively small influence of these four
drivers does not mean that the model users felt they were insignificant. Their presence gives
users the ability to quantify their impact on systems engineering.
Page 23 of 29
Number of Critical
Algorithms
Number of Operational
Scenarios
Requirements management tools such as DOORS are also helpful in populating the # of system
requirements driver. An additional step is needed to distribute the quantity of requirements
across the three complexity categories; easy, nominal, and difficult. This is a manual process
because of the expert judgment needed to assess the relative complexity of the requirements and
their impact on systems engineering effort.
3. Model output
a) Project effort distribution across activities
The academicCOSYSMO model provides a single point person month output which requires
some interpretation. As show earlier in Table 1, one of the assumptions of the model is that a
standard set of systems engineering activities are being performed throughout certain phases in
the life cycle. These 33 activities are distributed across 5 fundamental processes as shown in
Table 5. This distribution is not universal but it provides a typical spread of effort that is
characteristic of systems engineering projects.
Table 5. Effort Distribution Across ANSI/EIA 632 Fundamental Processes
ANSI/EIA 632 Fundamental Process Typical effort
Acquisition & Supply
Technical Management
System Design
Product Realization
Technical Evaluation
Page 24 of 29
7%
17%
30%
15%
31%
The effort distribution across fundamental processes, Px, is helpful in determining how to allocate
the estimated systems engineering resources in COSYSMO. The sum of the 5 fundamental
processes equal the total systems engineering estimate, that is:
P1 + P2 + P3 + P4 + P5 = 100%
Therefore, the COSYSMO estimate x can be allocated to each of the 5 processes.
x * 0.07 = effort required for P1
x * 0.17 = effort required for P2
x * 0.30 = effort required for P3
x * 0.15 = effort required for P4
x * 0.31 = effort required for P5
TOTAL = x
The breakdown of effort by systems engineering process is helpful not only for planning purposes
but also when an organization is only interested in estimating part of the systems engineering
activities. For example, if the systems engineering organization is only responsible for system
design, product realization, and technical evaluation then the typical effort is:
P3 + P4 + P5 = adjusted effort factor
0.30 + 0.15 + 0.31 = adjusted effort factor
0.76 = adjusted effort factor
The initial estimate provided by COSYSMO, x, should be adjusted by a factor of 0.76 to reflect
the absence of acquisition & supply and technical management activities assumed in the
estimate.
Page 25 of 29
TOTAL = x
The breakdown of effort by systems engineering life cycle phase is helpful not only for planning
purposes but also when an organization is only interested in estimating part of the systems
engineering life cycle. For example, if the systems engineering organization is only responsible
for the conceptualization and development of the system then the typical effort is:
A1 + A2 = adjusted effort factor
0.23 + 0.35 = adjusted effort factor
0.58 = adjusted effort factor
The initial estimate provided by COSYSMO, x, should be adjusted by a factor of 0.58 to reflect
the absence of the operational test & evaluation and transition to operation life cycle phases
assumed in the estimate.
COCOMO II
Software development
Thousands of Software Lines
of Code (KSLOC), Function
Points, or Application Points
MBASE/RUP Phases: (1)
Inception, (2) elaboration, (3)
construction, and (4)
transition
COSYSMO
Systems engineering
Requirements, Interfaces,
Algorithms, and Operational
Scenarios
ISO/IEC 15288 Phases: (1)
Conceptualize, (2) Develop,
(3) Operation, Test, and
Evaluation, (4) Transition to
Operation, (5) Operate
Maintain or Enhance, and (6)
Replace or dismantle.
4 size factors, 1 scale factor,
14 effort multiplier
One exponential system
factor
Page 26 of 29
Despite the differences between the two models there is potential overlap between the two
whenever the models are being used in parallel to estimate the effort involved with delivering a
software-intensive system. Part of understanding the overlap between the two models involves
deciding which activities are considered system engineering and which are considered
software engineering/development and how each estimation model accounts for these activities.
COCOMO II is designed to estimate the software 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 concept,
overall software system design, implementation and test. The COCOMO II estimate of the
software effort will surely account for the additional effort required by any additional testing of the
software system; at the same time, the COSYSMO effort will account for additional test
development and management since the systems engineers are required to perform additional
validation and verification of the system. Either model can account for this effort based on how
users wish to allocate the testing activity. Each organizations unique relationship between these
two disciplines needs to be reconciled when using COSYSMO and COCOMO II together. One
approach for accomplishing this is to examine the Work Breakdown Structures of each discipline.
COSYSMO uses the WBS defined in EIA/ANSI 632 while COCOMO II uses the one defined in
MBASE/RUP. The typical effort distribution of a software-intensive system is provided in Table 8
together with the activities that could potentially overlap when using both models during an effort
estimation exercise. The numbers in the cells represent the typical percentage of effort spent on
each activity during a certain phase of the software development life cycle as defined by
COCOMO II. Each column adds up to 100 percent.
Table 8. COCOMO II and COSYSMO Overlaps
Project Stage
Management
Environment/CM
Requirements
Design
Implementation
Assessment
Deployment
Inception
14
10
38
19
8
8
3
Software Development
Elaboration Construction
12
10
8
5
18
8
36
16
13
34
10
24
3
3
Transition
14
5
4
4
19
24
30
COCOMO II only
COSYSMO
Possible COCOMO II/COSYSMO overlap
The scope of COCOMO II includes the elaboration and construction activities generally defined
as software development. The gray cells indicate the systems engineering activities that are
estimated in COSYSMO. The diagonally shaded cells indicate the COCOMO II/COSYSMO
overlap activities that may be double counted when using the models simultaneously. The exact
amount of effort being double counted will vary for each organization based on the way they
define systems engineering relative to software engineering.
Page 27 of 29
4. Local calibration
The best way to ensure that COSYSMO is accurate to your context is to perform a local
calibration. This involves collecting data on completed programs that have a significant systems
engineering component and using it to calibrate the model constant, A, described in section 1. b).
a) Data collection
The focus is on collecting data for completed programs since it is necessary to know how much
systems engineer effort was actually expended on a program. This information together with
the total # of system requirements, # of interfaces, # of algorithms, and # of operational scenarios
is used to calibrate the model based on the historical performance of the organization. A data
collection form is available for download at http://www.valerdi.com/cosysmo in the Downloads
section. It is recommended that the data collection be done in person hours since this is a
uniformly accepted metric. If effort data is maintained in person months then the user must make
sure that every project has interpreted person months as 152 person hours. This is an important
issue for European users since person months are usually considered to be 138 person hours. In
which case, 1 European person month = 1.1 U.S. person months.
b) Measurement process
The recommended systems engineering cost estimation life cycle for COSYSMO is shown in
Figure 3. Several verification and validation opportunities exist along the way to tailor the model
to an organization.
c) Data analysis
Once data on completed programs has been collected, the simplest way to perform a local
calibration is to use the Calico tool that accompanies the SystemStar implementation of
COSYSMO which is developed by SoftStar systems. For more information visit
http://www.cosysmo.com.
Page 28 of 29
e) Customization
In addition to the local calibration, further opportunities exist for tailoring the model to a specific
organization. These include:
Adjustment of (Dis)economy of scale constant, E
Clarification of size driver counting rules (i.e., sea level) and system-of-interest
Mapping to internal Work Breakdown Structure
Adjustment of life cycle scope
Distribution of effort over time
Addition of new cost or size drivers
Page 29 of 29