DRAFT - UNDER REVIEW 1

Reuse in Systems Engineering

Gan Wang, Member, IEEE, Ricardo Valerdi, Member, IEEE and Jared Fortune, Member, IEEE

models. In many situations, product lines are managed

Abstract—Reuse in systems engineering is a frequent but through incremental improvement of previous system
poorly understood phenomenon. Nevertheless, it has a significant definitions. In other situations, existing systems are
impact on estimating the appropriate amount of systems modernized through technology insertions and obsolescence
engineering effort with models like the Constructive Systems
Engineering Cost Model (COSYSMO). Practical experience
management. Although system-level examples where
showed that the initial version of COSYSMO, a model based on a previously developed components and capabilities have been
“build from the scratch” philosophy, needed to be refined in leveraged can generally be easily identified, the current
order to incorporate reuse considerations that fit today’s literature fails to address how such instances of reuse at the
industry environment. The notion of reuse recognizes the effect system-level should be appropriately quantified [1]. In other
of legacy system definition in engineering a system and domains, such as software, reuse is a much better documented
introduces multiple reuse categories for classifying each of the
four COSYSMO size drivers – requirements, interfaces,
concept [2].
algorithms, and operational scenarios. It modifies the counting When a “new system” is developed, it commonly uses
rules for the COSYSMO size drivers and updates the definition existing components, proven functionality, or established
of system size in COSYSMO. It provides an enabling framework architecture. Across industry, we have witnessed ever
for estimating a system under incremental and spiral increasing trends of COTS-integration in system development
development. and ever diminishing endeavors of constructing something
In this paper, we present (1) the definition of the COSYSMO completely new from a “clean slate”. However, incorporating
reuse extension and the approach employed to define this
extension; (2) the updated COSYSMO size driver definitions that disparate elements together into a developing system is often
are consistent with the reuse model; (3) the method applied to no easy task, as the integration of legacy elements can
defining the reuse weights used in the modified parametric negatively impact project resources, sometimes substantially
relationship; (4) a practical implementation example that [3]. Knowing this, addressing reuse from a systems
instantiates the reuse model by an industry organization and the perspective, particularly the impact on the systems
empirical data that provided practical validation of the extended engineering effort required throughout the life cycle, is critical
COSYSMO model; and (5) recommendations for organizational
implementation and deployment of this extension. to accurately estimating the development cost of a system.
One method for estimating the amount of systems
Index Terms—systems engineering, reuse, metrics, cost engineering effort required for a project is the Constructive
estimation Systems Engineering Cost Model (COSYSMO) [4].
Developed at the University of Southern California with the
support of a consortium of academic, industry, and
I. INTRODUCTION government organizations, COSYSMO is a parametric model
for estimating the systems engineering and integration effort
A LMOST all systems have a legacy. Today, more often
than not, systems are developed based on an evolution of
previous systems. New releases of software are developed by
required for the conceptualization, design, test, and
deployment of software and hardware systems and executing
modifying and enhancing a previous release. Similarly, new projects that develop such a system. COSYSMO is part of the
generations of airplanes, ships, and automobiles are developed COCOMO II suite of models and developed through a similar
by improving the functionality and performance of previous methodology. COCOMO, originally developed in 1981 and
revised as COCOMO II in 2000, is the most widely used,
Manuscript received August 9, 2008. This work was supported in part by thoroughly documented and well calibrated software cost
BAE Systems, the Industrial Affiliates of the Center for Systems and Software model [5]. Applying a similar approach in COCOMO to the
Engineering, and the Consortium members of the Lean Advancement
Initiative.
systems domain, COSYSMO defines a parametric relationship
G. Wang is with BAE Systems, Reston, VA 20190 USA (phone: 703-668- that estimates systems engineering effort under nominal
4259; fax: 703-668-4224; e-mail: [email protected]). schedule, in person months, based on four size drivers –
R. Valerdi is with the Engineering Systems Division, Massachusetts
system requirements, system interfaces, system algorithms,
Institute of Technology, Cambridge, MA 02139 USA (e-mail:
[email protected]). and operational scenarios – and adjusted by fourteen effort
J. Fortune is a doctoral student in the Industrial and Systems Engineering multipliers, which capture the product and project
Department, University of Southern California, Los Angeles, CA 90089 USA environment and complexity factors. COSYSMO defines a
(email: [email protected]).
sizing quantity called “system size” from a weighted sum of
 DRAFT - UNDER REVIEW 2

the four size drivers. The parametric relationship is shown II. DEVELOPMENT APPROACH
below (1): The approach taken to represent the system size is
analogous to that used to represent software code size in those
E frequent instances in which there are several categories of
⎛ ⎞ 14
PM NS = A ⋅ ⎜⎜ ∑ ( we,k Φ e,k + wn ,k Φ n ,k + wd ,k Φ d ,k ) ⎟⎟ ⋅ ∏ EM j (1) code, including new and different levels of reuse, as well as
⎝ k ⎠ j =1 deleted [10, 11, 12]. In the case of software, the size of the
Where, code is often represented as “ESLOC,” or “Equivalent New
Source Lines of Code.” ESLOC is computed as the weighted
PMNS = effort in Person Months (Nominal Schedule) sum of the new, the reused, the modified, and the deleted
A = calibration constant derived from historical code. Similarly, we define “Equivalent Requirements” or
project data “eReqs” in COSYSMO as a function of the weighted sum of
the new, reused, modified, and deleted requirements in a
k = {REQ, IF, ALG, SCN} system. This reuse approach COSYSMO is motivated by the
wx = weight for “easy”, “nominal”, or “difficult” similar model defined by COCOMO II [5]. Therefore,
size driver additional consideration has been given so that the definitions
of reuse are conceptually consistent between COSYSMO and
Φ x = quantity of “k” size driver COCOMO II since they belong to the same family of models.
When defining the concept of reuse for COSYSMO, the
E = represents (dis)economies of scale
following basic principles hold true.
EM = effort multiplier for the jth cost driver. The
1. COSYSMO is an open model, developed by the
geometric product results in an overall effort
community and for the community. Users are free to
adjustment factor to the nominal effort.
change and/or extend the model.
Being the first of its kind, the model has, in a very short 2. On the other hand, it is beneficial for the industry to
period of time, caught the attention of the systems engineering agree on the basic definition, relationship and
community, industry and academia alike. It has demonstrated parameters to better communicate basis of estimates.
the potential to bridge a long-time gap between system
COSYSMO has been developed as an open model by the
complexity and its corresponding systems engineering effort
community of academia, industry and government for the use
estimate. Organizations have made various attempts to pilot
of the general public. This implies that everyone is free to
the model and apply it to practical applications [6, 7].
adopt, modify, and/or extend the model. In fact, it is intended
Early application of COSYSMO, however, has revealed
for organizations to adapt to their own engineering processes
that the model did not recognize the concept of reuse in
and business models, and to develop local, tailored estimating
systems engineering [8, 9]. It assumes that all of its four size
tools. In defining reuse as another aspect of the model, it
drivers – system requirements, system interfaces, system
should not, in any way, restrict or hinder individual
algorithms, and operational scenarios – are new entities when
applications or adaptations of this model. In fact, it should
defining the system size. In other words, the model is based
help to facilitate such a local implementation.
on a “build from scratch” philosophy and assumes all systems
On the other hand, similar to other cost estimating models,
are developed from a “clean slate”.
COSYSMO provides a methodology for the industry at large
This differs from how systems are typically built today
to measure and communicate productivity and basis of
since requirements for a new system may be “adopted” from
estimate. For the industry to best communicate such a measure
an existing system. Furthermore, some of the new system’s
of productivity and basis of estimate, it is important that the
requirements may be “modified” from a prior system.
same basic definitions are consistently understood and
Moreover, the evolution of system requirements over the
applied. This includes definition of terms and nomenclatures,
system life cycle may result in “deleted” requirements from
the basic estimating relationship, and the guidelines for
the initial configuration baseline. The same situations may
measurement.
apply to the other three size drivers – interfaces, algorithms,
However, the above two principles could inherently be
and operational scenarios. As the result, the calculated system
conflicting with each other. Free adaptation of the model
size does not reflect reusing elements of the system definition
could lead to individual inconsistent definitions and
and, consequently, can result in inaccurate estimate of systems
interpretations of the model. While over-restriction of the
engineering effort required to realize such a system. This
model definition could limit the application of the model by
problem intensifies when dealing with the incremental and
organizations, care must be taken to strike a fine balance to
spiral development.
preserve both of the above principles, so that it does not over-
Therefore, we propose incorporating the concept of reuse
constrain its application and adaptation across the industry
for estimating the size of a system, in order for COSYSMO to
and, at the same time, preserve the integrity of the model.
more accurately estimate the systems engineering effort.
The approach taken to develop the reuse concept was to
 DRAFT - UNDER REVIEW 3

summarize the leading organizational definitions and to precedence can be found for the system to be developed. New
aggregate them based on a “minimum common denominator” items are generally unprecedented and may be associated with
strategy. Several organizations including BAE Systems, a low level of familiarity. A requirement may be modified in
Lockheed Martin and Raytheon have been piloting and the sense that a heritage element is reused, but needs a limited
implementing this reuse concept. There are some subtle level of modification or tailoring for it to be fully incorporated
differences in the definitions used, but the basic concept is the in the new system. A requirement may also be adopted where
same. For this effort, the following guidelines for the industry the indicated functionality and performance has previously
definition were defined. been developed and can therefore be incorporated without any
A. Establish a minimum set of reference categories for changes. This is commonly referred to as “black box” reuse
each size driver (i.e., system requirements, system since the requirement is literally copied from a previous effort
interfaces, system algorithms, and operational remaining unchanged. A requirement that is considered
scenarios), so that organizations can either directly managed is incorporated typically as a turn-key component
apply and/or expand to additional reuse categories. where there is minimal development effort, except for
possibly engineering management, on the part of the
B. Provide minimum common-denominator definitions contractor since a subcontractor may be responsible for its
so that organizations can use, refine, and/or delivery. Deleted requirements are those that are already in the
instantiate as appropriate to fit their operational legacy system or architecture design, but need to be removed
needs. from the current system definition based on customer need or
Goal “A” indicates that we define only those reuse contractual commitments. Consequently, each of these five
categories that all stakeholders can agree on as the common types of reuse requires different degrees of systems
denominator for the community, and these categories are engineering effort.
intended as the reference for an organization in its own It is important to note that the modified category spans a
implementation to either directly apply or expand to additional wide range of possible effort. Modification may entail a
categories if it deems necessary. In other words, the intent is simple change in an interface connection to a complete
to always maintain this set of categories, but one may add revamp of the entire system architecture. The intent of the
other categories, generally as subdivisions, if appropriate. modified category is to capture those elements that involve
Goal “B” states that the definitions are intentionally structured tailoring changes only, with no changes to the internal
with the minimum common denominator language so that architecture. Therefore, those items that are inherited but
organizations can either directly use or, if necessary, may require a significant amount of architecture or implementation
refine and substantiate the definitions to fit their operational changes should be counted as new.
use. In other words, the industry definitions are intentionally For each size driver, three complexity levels are defined in
termed at a high level to cover wide ranges of applications. COSYSMO: easy, nominal, and difficult. These levels are
Several industry-level workshops have been conducted invariant in the context of reuse. Depending upon the point of
under the stated guidelines to achieve the community view, within each category of reuse, there are three levels of
agreement on the pilot implementation and validation of the complexity. Alternatively, within each level of difficulty,
reuse model in leading organizations. The following reuse there can be five categories of reuse. Conceptually, the two
extension has been defined through such as a community notions – categories of reuse and levels of difficulty – form a
agreement. two dimensional classification framework for size drivers that
provide adequate level of granularity in determining system
size. Operationally, when classifying drivers in terms of reuse,
III. THE COSYSMO REUSE EXTENSION there are two alternative sequences, purely depending upon
user preferences. When counting requirements, for example,
The COSYSMO reuse extension defines five categories for
they can first be classified into the five reuse categories. Next,
counting its size drivers, termed: new, modified, adopted,
within each reuse category, they can be further divided into
deleted, and managed. The quantities of each of the four
three levels of complexity. This additional dimension yields a
COSYSMO size drivers, i.e., number of requirements, number
revised COSYSMO parametric relationship that incorporates
of interfaces, number of algorithms, and number of
the concept of reuse (2):
operational scenarios, may be classified into the follow five
categories of reuse: E
⎡ ⎛ ⎞⎤ 14
= A ⋅ ⎢∑ ⎜⎜ ∑ wr ( we,k Φ e,k + wn ,k Φ n ,k + wd ,k Φ d ,k ) ⎟⎟⎥ ⋅ ∏ EM j
1. New: Items that are completely new.
PM NS
2. Modified: Items that are inherited, but are tailored. ⎣k ⎝ r ⎠⎦ j =1
3. Adopted: Items that are incorporated unmodified. (2)
Also known as “black box” reuse.
4. Managed: Items that are incorporated unmodified Where:
and untested.
PMNS = effort in Person Months (Nominal Schedule)
5. Deleted: Items that are removed from a system.
As an example, a requirement can be new, which no
 DRAFT - UNDER REVIEW 4

A = calibration constant derived from historical

project data Easy Nominal Difficult
k = {REQ, IF, ALG, SCN}
- Simple to implement - Moderately difficult to - Complex to implement
r = {New, Modified, Adopted, Deleted, Managed} implement or engineer

wr = weight for defined degrees of reuse - Traceable to source - Can be traced to source - Hard to trace to source
with some effort
wx = weight for “easy”, “nominal”, or “difficult”
size driver - Little requirements - Some overlap - High degree of
overlap requirements overlap
Φ x = quantity of “k” size driver
E = represents diseconomies of scale
EM = effort multiplier for the jth cost driver. The B. Number of System Interfaces
geometric product results in an overall effort This driver represents the number of new, modified,
adjustment factor to the nominal effort. adopted, managed, and deleted shared physical and logical
boundaries between system components or functions (internal
In contrast to the COSYSMO equation shown earlier (1), interfaces) and those external to the system (external
the revised relationship (2) introduces reuse as an additional interfaces). These interfaces typically can be quantified by
dimension for each of the size drivers. counting the number of unique external and internal system
interfaces among ISO/IEC 15288-defined [13] system
elements at the system level for the system-of-interest.
IV. MODIFIED SIZE DRIVER DEFINITIONS
With the concept of reuse incorporated into its parametric Easy Nominal Difficult
relationship, the COSYSMO size driver definitions require
their amendments. As an example, the original definition for - Simple - Moderate complexity - Complex protocol(s)
algorithm contains the verbiage: “This driver represents the
- Uncoupled - Loosely coupled - Highly coupled
number of newly defined or significantly altered functions…”,
which directly conflicts with the concept of reuse such as - Strong consensus - Moderate consensus - Low consensus
“adopted”. The modifications to the definitions are
underlined. - Well behaved - Predictable behavior - Poorly behaved
These proposed changes in size driver definitions were
obtained with industry feedback at the COSYSMO working C. Number of System-Specific Algorithms
group meeting at the Practical Software & Systems This driver represents the number of new, modified,
Measurement User Group Meeting in Denver in July 2007. As adopted, managed, and deleted mathematical algorithms to be
the result, the amended COSYSMO size driver definitions, derived in order to achieve the system functional and
consistent with the reuse extension, are given as below. performance requirements. As an example, this could include
a complex aircraft tracking algorithm like a Kalman Filter
A. Number of Systems Requirements being derived using existing experience as the basis for the all
aspect search function. Another example could be a
This driver represents the number of new, modified,
discrimination algorithm being derived to identify friend or
adopted, managed, and deleted requirements for the system-
foe function in space-based applications. The number can be
of-interest at the system level or the level of “sell-off” to
quantified by counting the number of unique algorithms
customer, which may include derived requirements at the
needed to realize the requirements specified in the system
same level. The quantity of requirements includes those
specification or mode description document.
related to the effort involved in system engineering the system
interfaces, system specific algorithms, and operational
scenarios. Requirements may be functional, performance,
Easy Nominal Difficult
feature, or service-oriented in nature depending on the
methodology used for specification. They may also be -Algebraic - Straight forward - Complex constrained
defined by the customer or contractor. Each requirement must calculus optimization; pattern
recognition
have systems engineering effort associated with it such as
verification and validation (V&V), functional decomposition, -- Straightforward - Nested structure with - Recursive in structure
functional allocation, etc. System requirements can typically structure decision logic with distributed control
be quantified by counting the number of applicable “shalls” in
the system or marketing specification. - Simple data - Relational data - Noisy, ill-conditioned
 DRAFT - UNDER REVIEW 5

data V. WEIGHT DEFINITION FOR REUSE CATEGORIES

We present in this section the approach used to define the
- Timing not an issue - Timing a constraint - Dynamic, with timing weights for the reuse categories in the COSYSMO equation
and uncertainty issues (2). It is important to note that the approach outlined below is
designed to capture the statistical behavior of a group of the
- Adaptation of library- - Some modeling - Simulation and
based solution involved modeling involved projects, rather than individual behavior of a particular
project. In fact, on an individual basis, a project may exhibit a
vastly different pattern of labor distribution relatively to reuse.
D. Number of Operational Scenarios An adopted or modified element could prove to be more costly
This driver represents the number of new, modified, than a brand-new element in terms of life cycle systems
adopted, managed, and deleted operational scenarios that a engineering effort.
system must satisfy in order to accomplish its intended The approach taken is bottoms-up activity-based, by which
mission. An operational scenario must be end-to-end and we define the reuse weights by evaluating life cycle systems
triggered by an operational event. Such scenarios include both engineering activities. In particular, we examined the 33
the nominal stimulus-response thread plus all of the off- systems engineering activities in five activity groups defined
nominal threads resulting from bad or missing data, by the ANSI/EIA 632 standard [14] relative to four life cycle
unavailable processes, or other exceptional conditions. The phases derived from (but not exactly the same as) the stages
number of scenarios can typically be quantified by counting defined in ISO/IEC 15288, Systems Life Cycle Processes.
the number of use cases or operational modes captured in the The result of this analysis is presented in the matrix in
user manual, including off-nominal extensions, developed as Figure 1. Along the x-axis, the four life cycle phases are
part of the operational architecture. repeated for each defined reuse category, namely,
Conceptualize, Develop, Operational Test & Evaluation, and
Transition to Operation.
Easy Nominal Difficult
Along the y-axis are the 33 systems engineering activities in
- Well defined - Loosely defined - Ill defined
the five activity groups. For each defined reuse category, we
identify the applicable activities by life cycle, which derive
- Loosely coupled - Moderately coupled - Tightly coupled or the sparsely populated matrix in Figure 1. The analysis
many involves the determination of applicability of an activity
dependencies/conflicting
requirements
across the life cycle for a particular reuse category. As an
example, realizing a new requirement into a product would in
- Timelines not an issue - Timelines a constraint - Tight timelines through general incur all of the activities as specified by EIA-632. A
scenario network reused requirement, on the other hand, would likely exclude
some of the activities. The underlying assumption is that a
- Few, simple off- - Moderate number or - Many or very complex
nominal threads complexity of off- off-nominal threads reused element generally saves systems engineering effort
nominal threads compared to a new element. This matrix allows qualitative
distinction between relative scales for reused and new.
 DRAFT - UNDER REVIEW 6

Fig. 1. Systems engineering activity vs. life cycle phase mapping by reuse categories

The next step is to turn the qualitative relationship to a category, the effort for System Design process is not
quantitative one. This is done with an effort distribution significant in the Development phase. Hence, we will
table derived from an industry wide-band Delphi survey assign the value of 0% or remove the original effort value
[15], as shown in Figure 2. Similarly, the four life cycle (12%) for that cell. On the other hand, the Technical
phases from ISO/IEC 15288 and the five systems Evaluation effort is significant and comparable to that in
engineering activities from ANSI/EIA 632 are presented. the new category for the Operational Test & Evaluation
The value in each cell of the matrix represents the phase. We retain the original percent effort value (12.4%)
percentage of the total effort applied to a particular activity for that cell. An example of such a exercise yields a series
in a particular life cycle phase. The total sums to 100%, of weights as shown in Figure 3, defined for each reuse
which corresponds to the life cycle effort of developing a category, which aggregates into a set of reuse weight values
new system or system element, from concept to delivery. for size drivers of nominal complexity (i.e., levels of
Each systems engineering process yields a unique effort difficulty), as shown in Figure 4.
profile. For example, the Acquisition and Supply activity
typically represents 7% of the total systems engineering
effort across four phases of the life cycle. By combining the
results in Fig 1 with the data in Fig 2, an approximation of
the weight of a particular activity can be prorated for
different reuse categories. For example, in the adopted

Fig. 2. Life cycle systems engineering effort distribution [15]

 DRAFT - UNDER REVIEW 7

Fig. 3. Activity-based weight derivation for reuse categories Fig. 5. Reuse Continuum

The second point illustrated by the continuum in Figure 5

New Managed Adopted Modified Deleted is the existence of the Modified vs. New Threshold. This is
relevant in cases where extreme modification of
100.0% 15.4% 43.4% 64.7% 50.7% requirements causes the original reused requirement to be
Fig. 4. Aggregated weights for the reuse categories more complex than a new requirement. In this situation, the
systems engineer must make a tradeoff decision to
This analysis was accomplished through a series of key determine whether it is better to “throw away” the old
stakeholder round-table sessions. Alternatively, the same requirement and start with a new one or keep the old
outcome can be achieved through either Delphi surveys or requirement in spite of its extra expense. The range of
collection and analysis of historical program data. possible weights for modified requirements may
The reuse weights are summarized along a continuum in theoretically exceed the weight for new, but the exploration
Figure 5 to illustrate two additional points. First, it should of such values was beyond the scope of this analysis.
be noted that the weight values in Figure 4 represent the The approach as presented above can be followed to
nominal values, or the mode, for the respectively derive organization-specific reuse weights. Operationally, it
categories. The exact weights may fall within a range of is important to note that these weights, once defined or
possible values that may be greater than or less than the derived in an organization, should be applied to all data
suggested values or a set of distributions whose mode is points consistently, between the calibration data and new
represented by the values in Figure 4. This presents an estimates. It is not to be redefined for each data point or
opportunity for further tailoring by each organization that new estimate.
wishes to incorporate reuse into their COSYSMO
implementation and to more accurately capture
organizational productivity. For example, in the modified VI. A PRACTICAL APPLICATION EXAMPLE
case the corresponding weight may be lower than 0.65 in For the past two years, BAE Systems has been
situations where there is very little modification taking developing a systems engineering estimating tool based on
place. Such a situation may arise when the color of an COSYSMO to locally calibrate the model to its product
airplane is changed from a Forest Green to Sea Grey. This lines. During the course of this project, a significant amount
is a simple modification of a requirement that does not of historical data was collected to calibrate the model to
demand critical changes in systems engineering effort. On leading products and platforms. The COSYSMO
the other hand, significant modifications may emerge which development at BAE Systems provided the first
can result in a higher weight for the modified parameter. organizational implementation and validation of the reuse
This may arise when the previous requirement is modified model. In fact, BAE Systems has been part of the core
to work in a new environment that was previously stakeholder group and has led the industry’s effort in
considered. Such a scenario frequently arises when defining the reuse extension. In order to achieve a practical
companies attempt to modify system components from and deployable implementation, the reuse definition was
commercial helicopters to military helicopters. Different elaborated and additional specifications were added to
operational and performance criteria apply when such better adapt to its engineering process and product lines and
components are incorporated into the military domain.
 DRAFT - UNDER REVIEW 8

to ensure higher level of correlations in data collection for 3. Adopted: Items that are incorporated unmodified
the organization, while maintaining a more generic but require verification and validation testing.
definition for the industry model for a broader community. Also known as “black box” reuse.
To develop BAE Systems instantiation of the reuse 4. Managed: Items that are incorporated unmodified
model, we established the following objectives or and untested, and require no additional SE effort
guidelines: other than technical management.
• Be consistent with industry definition. Define 5. Deleted: Items that are removed from a legacy
such reuse categories by instantiating and refining system, which require design analysis, tailoring or
the industry definitions so as to avoid any potential interface changes, and verification and validation
conflicts and inconsistencies. testing.
• Provide clear and consistent operational Several points are worth noting for the above definitions.
guidelines for driver counting and classification, First, these definitions are directly instantiated from the
by using unambiguous verbiage in the reuse industry version and inherited all its defined categories:
definition. new, managed, adopted, managed, and deleted. Additional
• Establish clear boundaries between categories to clarification of the base definitions was added with the
ensure easy separation and consistency. designated systems engineering activities in mind. These
• Enable further extension of reuse, if necessary, activity-based clarifications such as technical management,
and facilitate customer definition of additional variation and validation, provide further discriminators and
reuse levels. boundary conditions for operational use. For this purpose, a
COSYSMO innately is a subjective model, which leads reference table was created, as shown in Figure 6, to serve
its driver (size and cost) definitions to individual as a Rosetta Stone between the industry definitions and the
interpretation and, consequently, possible inconsistent ones used at BAE Systems.
sizing of the systems and estimation of effort. One of the
challenges for the operational use has been the guidance in
understanding the driver definitions and their classification
categories. With the instantiated model, clear boundaries
between the reuse categories can be established so that
there are limited degrees of freedom for individual Fig. 6 - Activities-based classification wizard for reuse classification
interpretation in counting the size drivers. In other words,
clear steps rather than ramps between the reuse categories Secondly, we strongly advocated and recommended the
help delineate the differences using characteristics that are category called “managed” to the industry definition, which
common to all programs. we believe is important in capturing the intricacies of
The approach is to define a classification framework for today’s evolutionary and spiral development, as well as
counting size drivers with two orthogonal dimensions to prevalent teaming arrangement between industry partners.
enable finer grain estimation of these drivers: reuse by This category is intended for two main circumstances. The
systems engineering activities and levels of difficulties by first is when a new system incorporates legacy elements
relative effort (i.e., easy, nominal and difficult, as defined that have already been developed and verified and validated
by COSYSMO). Six high-level, signature life-cycle from a prior system, the systems engineering activities now
systems engineering activities were identified. Easy to are mostly limited to technical management. The second
apply in practice and can be related by most systems situation is when a part of the system under development is
engineers, they were used as the key discriminators in subcontracted out or uses COTS/GOTS-based components
delineating the reuse categories: 1) Technical Management; that are “turn-key” or “plug-and-play”. The requirements
2) Requirement Definition; 3) Design Analysis; 4) and other drivers related to these subtracted parts have
Architecture & Implementation Changes; 5) Tailoring and already been verified and validated by the providers. To the
Interface Changes; 6) Verification & Validation. The prime contractor, the majority of the activities required are
definition for the reuse categories is based on a technical (subcontract) management in nature.
determination of required number of these activities to Finally, the new items by definition are new and
realize a size drive in an end-to-end development life cycle. generally unprecedented. However, the modified category
Therefore, at the BAE Systems, we further instantiated can cover such a wide range of spectrum in terms of
reuse model and provided more specific definitions for the degrees of change or modification that it is difficult to
five categories, as follows (differences are italicized): maintain consistency. To mitigate this problem, we further
1. New: Items that are completely new. confine the category to those items that are basically reused
2. Modified: Items that are incorporated but require as-is and that only allow the degree of modification limited
tailoring or interface changes, and verification to that of tailoring or interface changes. As a result, any
and validation testing. legacy elements that require higher-degree modifications
involving architecture and implementation changes are
 DRAFT - UNDER REVIEW 9

classified as new. reuse model. We discussed the approach applied to this

The validate the reuse model, an application to a set of development and the method used for deriving the reuse
historical programs from several lines of business (LoB) weights. We also presented the updated COSYSMO size
and major sites in the Electronics and Integrated Solutions driver definitions that are consistent and compatible with
(E&IS) Operating Group was performed. The result is the reuse extension.
significantly improved data correlation and calibrations To implement this extension for the operational use, an
with higher-degree of accuracy and confidence level than organization can directly apply the method presented in this
before. Figure 7a shows the data before applying the reuse paper. It may consider further instantiating the definitions
model and Figure 7b shows the same data points after to establish more concrete and defined boundaries that are
applying the reuse model, with everything else in the tailored to the business model, product lines, and
COSYSMO model held constant. engineering process of the respective organizations.
It is evident from the heteroscedasticity of the data that Organizations may also find it necessary to add additional
the reuse model significantly improved the predictive reuse categories. If so, it is recommended that the original
accuracy of the COSYSMO model. This improvement is a reuse categories be preserved rather than changing the
result of adjusting the model closer to reality, as it has been established categories.
proved by practical experience that reuse is more the rule The weights for reuse, once defined, should be
rather than the exception. consistently applied across all data points and over time,
between calibration data and new estimates. They should
not be changed for a single estimate and calibration point.
Any change to these definitions may require recollection of
all the calibration data points, and change to the derived
Systems Engineering Effort (SE Hours)

weights may require recalculation of all the system sizes.

This is required for the necessary level of consistency
between programs and between calibrations and new
estimates. In other words, this is to ensure that consistency
of requirements is realized across programs and system size
is measured with the same scale and counting rules.
As a community of systems engineers interested in cost
estimation, we cannot dictate each individual organization’s
System Size (eReq)
extension of the reuse model, but we should, however,
agree on a set of values for reuse weights. This is desirable
(a) Before applying reuse model, all drivers are counted as new
to ensure consistent understanding of estimate system size
and better communicate basis of estimates. This will be a
continuing effort in the refinement of the reuse approach
which will involve feedback from key stakeholders from
leading organizations.
Systems Engineering Effort (SE Hours)

The initial version of COSYSMO has established a

frontier for systems engineering cost estimation. However,
as with any other methodology in its early stage, it requires
continuous improvement so that it can gain the level of
maturity required by operational use and potentially as a
new industry standard. The authors are also engaged in
other enhancement efforts to further improve the fidelity of
the model. One of these areas is the cost drivers or the
System Size (eReq)
effort multipliers used in the model to scale the estimate
effort based on the system size. Another is the extension of
(b) After apply the reuse model
the reuse concepts to other systems engineering artifacts
Fig. 7 – Distribution of the same data set, before (a) and after (b) applying such as knowledge [16, 17], documentation, and test
the BAE Systems extended COSYSMO reuse model
procedures. We are following a similar strategy in
combining expert opinion and historical data to develop the
most realistic and accurate model possible and will report
VII. CONCLUSION AND RECOMMENDATIONS
the progress of these activities in the near future.
In this paper, we have defined a reuse extension model
for the COSYSMO size drivers. We presented an industry
definition, as well as an organizational implementation as
the practical validation and implementation example of the
 DRAFT - UNDER REVIEW 10

ACKNOWLEDGMENT He has been engaged in the research and development of decision

support methods and life cycle cost modeling and practice for systems
The authors wish to thank other collaborators that have engineering and enterprise-level, system-of-systems engineering and
provided valuable insight and helpful discussions on this management. Prior to joining BAE Systems, he spent many years
developing real-time geospatial data visualization applications for mission
work. Garry Roedler and John Gaffney of Lockheed planning and rehearsal, battlefield command and control (C2), flight
Martin, John Rieff of Raytheon, Dan Ligett of Softstar simulation and aircrew training systems. He has over 20 years of
Systems, and Barry Boehm of USC were influential in the experience in systems engineering, software development, research and
direction and outcome of this work. development, and engineering management involving complex, software-
intensive systems.
Dr. Wang is a member of IEEE, INCOSE and PMI.

REFERENCES
[1] A. Sage, “Systems Engineering and Systems Management for
Reengineering”, Journal of Systems and Software, vol. 30, no. 1,
1995.
[2] J. Poulin, J. Caruso, D. Hancock, “The business case for software
reuse”, IBM Systems Journal, vol. 32, no. 4, 1993.
[3] D. Garlan, R. Allen, J. Ockerbloom, “Architectural Mismatch or Why
it’s hard to build systems out of existing parts”, 17th International
Conference on Software Engineering, Seattle, WA, April 1995.
[4] R. Valerdi, The Constructive Systems Engineering Cost Estimation
Model (COSYSMO): Quantifying the Costs of Systems Engineering
Effort in Complex Systems, VDM Verlag, 2008. Ricardo Valerdi (BS’99-MS’02-PhD’05) is a Research Associate at the
[5] B. Boehm, C. Abts, A.W. Brown, S. Chulani, B. Clark, E. Horowitz, Lean Advancement Initiative at Massachusetts Institute of Technology and
R. Madachy, D. Reifer and B. Steece, Software Cost Estimation with a founding member of the Systems Engineering Advancement Research
COCOMO II, Upper Saddle River, NJ, Prentice-Hall, 2000. Initiative. He is also a Visiting Associate at the Center for Systems and
[6] R. Valerdi, J. Rieff, G. Roedler, M. Wheaton and G. Wang, “Lessons Software Engineering at University of Southern California (USC) and a
Learned from Industrial Validation of COSYSMO,” 17th INCOSE Senior Member of the Technical Staff at the Aerospace Corporation in the
Symposium, San Diego, CA, June 2007. Economic & Market Analysis Center. Formerly he worked as a Systems
[7] J. Reiff, J. Gaffney and G. Roedler, “2007: The Breakout Year for Engineer at Motorola and at General Instrument Corporation.
COSYSMO,” Practical System and Software Measurement Users He earned his BS in Electrical Engineering from the University of San
Group Conference, Golden, CO, 2007. Diego, MS and PhD in Industrial & Systems Engineering from USC.
[8] R. Valerdi, J. Gaffney, G. Roedler and J. Rieff, “Extensions of Dr. Valerdi became a member of IEEE in 1995 and is a member of
COSYSMO to Represent Reuse,” 21st International COCOMO INCOSE and serves on its Board of Directors.
Forum, Los Angeles, CA, October 2006.
[9] G. Wang, R. Valerdi, R., Ankrum, A., Millar, C. and Roedler, G.,
“COSYSMO Reuse Extension,” 18th INCOSE Symposium, Utrecht,
The Netherlands, June 2008.
[10] “Special Issue on Software Reusability,” IEEE Trans. Software Eng.
T. Biggerstaff and A. Perlis, eds., vol. 10, no. 5, Sept. 1984.
[11] H. Mili, F. Mili, A. Mili, Reusing Software: Issues and Research
Directions, IEEE Trans. Software Eng., vol. 21, no. 6, pp. 528-562,
June 1995.
[12] “Enabling Reuse-Based Software Development of Large-Scale
Systems.” IEEE Trans. Software Eng. R. Selby, vol. 31, no. 6, June
2005.
[13] ISO/IEC. ISO/IEC 15288:2002(E) Systems Engineering - System Life
Cycle Processes, 2002.
[14] ANSI/EIA. ANSI/EIA-632-1988 Processes for Engineering a System, Jared Fortune (BS’05-MS’06) is a Doctoral Student at the University of
1999. Southern California in the Industrial and Systems Engineering Department.
[15] R. Valerdi, M. Wheaton, “ANSI/EIA 632 As a Standard WBS for His research topic is on reuse considerations in architecture tradeoffs in
COSYSMO,” AIAA 1st Infotech@Aerospace Conference, Arlington, space systems. He is also an Advanced Degree Fellow at the Aerospace
VA, September 2005. Corporation in the Economic & Market Analysis Center, where he has
[16] C. Huang, Explication and sharing of design knowledge through a worked for the past three years.
novel product design approach, IEEE Trans. Sys., Man and He earned his BS and MS from the University of Southern California in
Cybernetics, Part C: Applications and Reviews, vol. 36, pp. 426-438, Industrial and Systems Engineering as well as a Minor in Business.
2006. Mr. Fortune is a member of IEEE and INCOSE.
[17] A. Satyadas, Knowledge management tutorial: an editorial overview,
IEEE Trans, Sys., Man and Systems, Man, and Cybernetics, Part C:
Applications and Reviews, vol. 31, pp. 429-437, 2001.

BIOGRAPHIES
Gan Wang (BS’81-MS’87–PhD’91–MBA’02) is a Principal Investigator
for system-of-systems engineering and integration strategic initiatives at
BAE Systems. He obtained his BS in Electrical Engineering from Harbin
Institute of Technology, his MS in Electrical Engineering from George
Mason University, his PhD in Electrical Engineering from the University
of Virginia, and his MBA from the University of Maryland.