University of Southern California
Center for Systems and Software Engineering
Discussion on Reuse Framework
Jared Fortune, USC
Ricardo Valerdi, MIT
COSYSMO Workshop @
COCOMO Forum 2008
Los Angeles, CA
1
University of Southern California
Center for Systems and Software Engineering
Operational Concept
# Requirements
# Interfaces
# Scenarios
# Algorithms
+
2 Volatility Factors
Size
Drivers
Effort
Multipliers
- Application factors
- 9 factors
- Team factors
- 7 factors
- Schedule driver
COSYSMO
2.0
Effort
Calibration
2
University of Southern California
Center for Systems and Software Engineering
COSYSMO 2.0 Model
E
PM NS
 
 16
 A     wr ( we,k  e,k  wn,k  n,k  wd ,k  d ,k )    EM j
 j 1
k  r
Where:
r = {New, Modified, Adopted, Deleted, Managed}
wr = weight for defined degrees of reuse
Goals
• Capture technical and non-technical effects of reuse
• Introduce minimal modifications to the original model
• Keep new drivers independent from existing drivers
3
University of Southern California
Center for Systems and Software Engineering
Proposed Size Driver Extensions
New: Artifacts that are
completely new
New 1.0
Modified: Artifacts that are
inherited, but are tailored
Deleted: Artifacts that are
removed from a system
Managed: Artifacts that are
incorporated unmodified and
untested
Reuse weight
Adopted: Artifacts that are
incorporated unmodified, also
known as “black box” reuse
Modified
Managed
Adopted
Deleted
0
Reuse category
4
University of Southern California
Center for Systems and Software Engineering
Size Driver Extensions
COSYSMO
Size Drivers
Easy
Nominal
Difficult
New
Modifited
Easy
Adopted
Number of System Requirements
Number of Major Interfaces
Number of Critical Algorithms
Number of Operational Scenarios
COSYSMO 2.0
Possible Methodologies for
Size Driver Weights
A
Deleted
Managed
New
Nominal
Modifited Adopted Deleted Managed
New
Modifited
Difficult
Adopted
Deleted
Managed
New
Nominal
Modifited Adopted Deleted Managed
New
Modifited
Difficult
Adopted
Deleted
Managed
Number of System Requirements
Number of Major Interfaces
Number of Critical Algorithms
Number of Operational Scenarios
Specific
60 Weights: Each Size Driver and Each Size Driver Rating
New
B
Modifited
Easy
Adopted
Deleted
Managed
Number of System Requirements
Number of Major Interfaces
Number of Critical Algorithms
Number of Operational Scenarios
15 Weights: All Size Drivers and Each Size Driver Rating
New
C
Easy, Nominal, or Difficult
Modifited Adopted
Deleted
Managed
Number of System Requirements
Number of Major Interfaces
Number of Critical Algorithms
Number of Operational Scenarios
20 Weights: Each Size Driver and All Size Driver Ratings
New
D
Easy, Nominal, or Difficult
Modifited Adopted
Deleted
Number of System Requirements
Number of Major Interfaces
Number of Critical Algorithms
Number of Operational Scenarios
5 Weights: All Size Drivers and All Size Driver Ratings
Managed
General
5
University of Southern California
Center for Systems and Software Engineering
Reuse Understanding
COCOMO
Software Understanding
Structure
Application
COSYSMO 2.0
Reuse Understanding
Cohesion of reused code
Organization
Processes to capture or implement the reuse of
artifacts; repeatable
Correlation between original domain and domain of
new application
Domain
Applicability
Overlap between the original domain of the artifact
and the domain the artifact is being reused within
Descriptiveness Availability of documentation for reused code
Availability of documentation or other non-personnel
Technology
related knowledge assets that provide for or improve
Comprehension the understanding of the technology being addressed
in the reused artifact
6
University of Southern California
Center for Systems and Software Engineering
Reuse Understanding – Rating Scale
Rating Scale for Reuse Understanding
Organization
Domain
Applicability
Technology
Comprehension
Very Low
No defined
processes; reuse
occurs infrequently;
conducted only on an
ad hoc basis
Low
Limited number of
processes defined;
reuse occurs
seldomly; reuse is
purely opportunistic
Nominal
Some processes
defined to capture
artifacts for reuse
and to implement
reuse of existing
artifacts; reuse
occurs occasionally
No relationship
Very limited
Domain of artifact is
between the
relationship between related to new
domains; successful the domains;
application;
application is an
successful
successful
uncertainty
application will face application is not a
some difficulties
foregone conclusion
High
Good definition of
reuse processes;
reuse is frequently
planned
Very High
Mature reuse
processes; reuse is
planned, strategic,
and common;
management fully
supports reuse
Clear connection
between the
domains; successful
application is likely
Strong relationship
between domains;
previous reuse of
artifcats provides
precedent
Technology not
understood; no
documentation exists
to support the reused
artifact
Technology is
understood; artifacts
are well documented
and some form of
knowledge
management system
exists
Strong
understanding of
technology behind
reused artifact;
detailed
documentation and
knowledge
management
systems exist
Limited
understanding; some
resources exist to
improve
comprehension
Technology behind
the reused artifact is
reasonably
understood;
resources available
for guidance
7
University of Southern California
Center for Systems and Software Engineering
Artifact Unfamiliarity
COCOMO
COSYSMO 2.0
Programmer Unfamiliarity
Artifact Unfamiliarity
Systems engineer directly assisted in the
development of the artifact for the original
system; continual experience with the artifact;
first-hand knowledge of the heritage system is
available
Completely
familiar
Programmer works with the code being reused
on an everyday basis
Completely
familiar
Mostly familiar
(only effort multiplier provided, no explicit
definition)
Systems engineer participated in the
Mostly familiar development of the artifact for the original
system; infrequent experience with the artifact
Somewhat
familiar
(only effort multiplier provided, no explicit
definition)
Somewhat
familiar
Systems engineer has some familiarity with the
artifact and the original system which it was
derived from; no first-hand knowledge of the
heritage system
Considerably
familiar
(only effort multiplier provided, no explicit
definition)
Mostly
unfamiliar
Systems engineer has experience with similar
artifacts but not the current one being reused;
limited knowledge of the heritage system
Mostly
unfamiliar
(only effort multiplier provided, no explicit
definition)
Completely
unfamiliar
Systems engineer has no previous experience
with the artifact or the system which the artifact
was derived from; completely unknown
Completely
unfamiliar
Programmer has never seen the code before
8
University of Southern California
Center for Systems and Software Engineering
Artifact Unfamiliarity – Rating Scale
Artifact Unfamiliarity
Completely
familiar
Systems engineer directly assisted in the
development of the artifact for the original
system; continual experience with the artifact;
first-hand knowledge of the heritage system is
available
Systems engineer participated in the
Mostly familiar development of the artifact for the original
system; infrequent experience with the artifact
Somewhat
familiar
Systems engineer has some familiarity with the
artifact and the original system which it was
derived from; no first-hand knowledge of the
heritage system
Mostly
unfamiliar
Systems engineer has experience with similar
artifacts but not the current one being reused;
limited knowledge of the heritage system
Completely
unfamiliar
Systems engineer has no previous experience
with the artifact or the system which the artifact
was derived from; completely unknown
9
University of Southern California
Center for Systems and Software Engineering
Proposed COSYSMO 2.0 Methodology
• Capture the effect of reuse in both the size and cost
drivers
– Does this make sense?
• Reuse extensions for the size drivers has already been
proposed
• Are the two COSYSMO 2.0 cost drivers sufficient?
– Adequately capture the effects of reuse outside the size drivers?
10
University of Southern California
Center for Systems and Software Engineering
Implementation
• Reuse size driver extensions and more cost drivers
sounds good from an academic perspective
…but this is a slippery slope
– 5 reuse categories = 60 systems engineering size values
– 20 model parameters = ~100 calibration projects
Just for reuse!
• What about:
– Operations, maintenance, disposal
– Risk
– Schedule
…and all the rest
11
University of Southern California
Center for Systems and Software Engineering
Questions
• Do we really need 5 reuse categories?
– Do we have the correct definitions?
– Is this supportable?
• How many is too many drivers in the model?
– Reuse requires 1-2 cost drivers to complement reuse extensions
– Should we explore a subset of the model to provide a “good
enough” estimate?
– Opportunity to balance adding more parameters with capability
to produce an estimate with fewer parameters
• Other thoughts? Deficiencies?
12
University of Southern California
Center for Systems and Software Engineering
Next Steps
• Conduct Delphi survey on COSYSMO 2.0 drivers
– Weights for reuse extension and two additional drivers
• Begin data collection process
– Want to “reuse” as many projects from COSYSMO data set as
possible that involved systems engineering reuse
– Collection of additional projects will also help to improve the
COSYSMO model
• Plan to provide preliminary results of COSYSMO 2.0 at
CSSE Annual Research Review (March 2009)
13