Generalized Reuse Model for
COSYSMO
Workshop at 27th International Forum on COCOMO® and Systems/Software Cost Modeling
Pittsburgh, PA
17 October 2012
Agenda
• Background and brief history (of COSYSMO evolution in reuse)
– Past papers
• Generalized Reuse Model concept (DWR & DFR)
– Starts with “what’s the problem?”
• Model definition
– Categories
– equation
• Weights round-table
– Weight table
2
Background and Brief History
• Inception of COSYSMO 1.0
– Valerdi, R., The Constructive Systems Engineering Cost Model (COSYSMO), PhD
Dissertation, University of Southern California, May 2005.
• Introduced the Reuse Model Extension to COSYSMO 2.0
– Wang, G., Valerdi, R., Ankrum, A., Millar, C., and Roedler, G., “COSYSMO Reuse
Extension,” Proceedings of the 18th INCOSE International Symposium, June 2008.
– Fortune, J. Estimating Systems Engineering Reuse with the Constructive Systems Engineering
Cost Model (COSYSMO 2.0). Ph.D. Dissertation. University of Southern California.
December 2009
– Wang, G., Valerdi, R., Fortune, J., “Reuse in Systems Engineering,” IEEE System Journal,
v4, No.3, 2010.
• Marching to COSYSMO 3.0:
– Fortune, J. and Valerdi, R., “Considerations for Successful Reuse in Systems Engineering,”
AIAA Space 2008, San Diego, CA, September 2008.
– Wang, G. and Rice, J., “Considerations for a Generalized Reuse Framework for System
Development,” Proceedings of the 21st INCOSE International Symposium, June 2011.
– Fortune, J. and Valerdi, R., “A Framework for Systems Engineering Reuse,” Systems
Engineering, 16(2), 2013.
3
What’s the Problem?
• Reuse has been focusing on leveraging previous artifacts in order to save labor,
with an inherent assumption that there’s something there to reuse in the first
place
• However, product line management and investment is as important a concern to
managers, also to affordability trades
• We want to be able to assess not only the effort to leverage but also the effort to
invest
• This is a tool for design sensitivity analysis
4
Manners of Reuse
• Ad Hoc / Opportunistic Reuse
– Search & discover reusable
resources
– Adapt to current application
– “Code scavenging”
• Planned / Systematic Reuse
– Explicit processes and
standards
– Invest in reusable resources
5
Two Fundamental Reuse Processes
Development For
Reuse (DFR)
• Producer’s View
• Production of reusable
resources
Development With
Reuse (DWR)
• Consumer’s View
• Consumption of
reusable resources
A Development Project May Contain Both
6
Contrasting Between Two Perspectives
Development with Reuse
(DWR)
Development for Reuse
(DFR)
Role
Consumer
Producer
Purpose
Goal
Consumption of reusable
resources
 Improving product quality
 Cost savings
 Time to market
Production of reusable
resources
Investment for future benefits
Challenges


Reusability


Discovery of what to

reuse

Decisions on how to tailor 
and integrate
Plans for how to reuse
Design for reusability
Means to verify
If ad hoc, then generally
Generally high
low
If planned, then generally
high
7
Reuse Viewpoint for Development
Developm ent Activities  DevelopTarget System
 Invest for ProductLine
8
Product Line Benefits of Reuse
Total
Effort
100
% Effort
DW
R
DW
R
DW
R
DW
R
DFR
DFR
DFR
0
1
2
3
DFR
4
# of Articles in the Product Line
Investments in Development for Reuse (DFR) are
leveraged to reduce Product Line Cost
Definitions
Development With Reuse (DWR)
New
Implemented
Modified
Deleted
Element that is new, which requires developing from
scratch; or developed from previously defined system
concept or logical architecture; or from previously
designed physical architecture or constructed product
components but with significantly modified or extended
functionalities.
Development For Reuse (DFR)
No DFR
No development for reuse within the planned
work scope
Conceptualized
For Reuse
The reusable resource produced is a logical
architecture that must be further developed
through a series of detailed design,
implementation, verification and validation testing
activities to bring to the final deployable product.
Designed For
Reuse
The reusable resource produced is a physical
architecture that must be further developed
through a series of implementation, verification
and validation testing activities to realize the final
deployable product.
Constructed For
Reuse
The reusable resource produced is a physical
product or component that has been implemented
and independently verified through verification
tests but has not been deployed or used in an
end system.
All levels of testing except for validation
Validated For
Reuse
The reusable resource produced is a physical
product or component that has been developed
and operational validated through its use in an
end system.
Element that is developed from inherited physical
architecture or previously constructed product
components that require re-implementation or
refactoring.
Element that is developed from specializing or tailoring
(i.e., modification of interfaces) of previously constructed
or deployed product components without functional
changes or extensions to be effectively integrated into
the new system.
Element that is removed from previously developed or
deployed system baseline, which requires modification
of interfaces of the inherited system to effectively
disintegrate the element from that system without
adverse effects.
Adopted
(Integrated)
Element that is incorporated or integrated from
previously developed or deployed product components
without modification but requires complete V&V testing.
This is also known as “black-box” reuse or simple
integration.
Managed
Element that is inherited from previously developed or
validated product components without modification and
its integration is through significantly reduced V&V
testing by means of inspection or provided test services
or procedures and equipment.
10
Interfacing DWR and DFR
Reusability from DFR Produces Reusable Resources
Reused by DWR with Effort
Conceptualized for Reuse
System Concept Definition

New
Conceptualized for Reuse
Logical Architecture

New
Designed for Reuse
Physical Architecture (intended
for built to print)

Constructed Product/Component

New, if architectural modification
required
Implemented, if no modification
required
New, if architectural modification
required
Modified, if tailoring needed for
integration
Adopted, if only integration and
testing required
Constructed for Reuse



Validated for Reuse
Validated Product/Component




New, if architectural modification
required
Modified, if tailoring needed for
integration
Adopted, if only integration and
testing required
Managed, if limited testing required
11
Extended COSYSMO Form
E1
PM DWR  DFR
 

 A1     wr ( we,k  e,k  wn ,k  n ,k  wd ,k  d ,k )   CEM1

k  r
E2
 

 A2     wq ( we,k e,k  wn ,k n ,k  wd ,k d ,k )   CEM 2
 k  q

Where:
PMDWR = effort in Person Hours/Months (Nominal Schedule)
A1 = calibration constant derived from historical project data
k = {REQ, IF, ALG, SCN}
r = {New, Implemented, Modified, Deleted, Adopted, Managed}
wr = weight for defined levels of size driver reuse
wx = weight for “easy”, “nominal”, or “difficult” size driver
Фx = quantity of “k” size driver
E1 = represents diseconomy of scale
CEM1= composite effort multiplier
Where:
PMDFR = effort in Person Hours/Months (Nominal Schedule)
A2 = calibration constant derived from historical project data
k = {REQ, IF, ALG, SCN}
q = {Conceptualized, Designed, Built, Validated}
wr = weight for defined levels of size driver reuse
wx = weight for “easy”, “nominal”, or “difficult” size driver
Фx = quantity of “k” size driver
E2 = represents diseconomy of scale
CEM2 = composite effort multiplier
Required Activities Relative To Reusable Architects
Logical Architecture
X
Operational Test
Installation
Inspection
Execute Test
Design Verificaiton
Specialize / Tailor
(Wrap)
Reimplement /
Refactor / Extend
Understand & Assess
Architecting /
Premilinary Design
Detailed Design /
Refactor
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Physical Architecture
Constructed
Product/Component
Validated
Product/Component
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
System Concept
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Logical Architecture
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Physical Architecture
Constructed
Product/Component
Validated
Product/Component
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Transition
To Use
X
Use As-Is
X
Implementation Verificaiton Test
Modify
System Concept
Select Reuse
Reusable Artifacts /
Development Activities
System Design
Integrate
Develop Test
Plan/Procedures
Technical Requirement
Management Definition
Define Requiremnets
Analyze
Requirements
Development Processes
13
Added Activities Relative To Reusable Architects
System Concept
X
X
X
Logical Architecture
X
X
X
X
Physical Architecture
Constructed
Product/Component
Deployed
Product/Component
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Operational Test
Inspection
Execute Test
Develop Test
Transition To
Use
Deployment
Verification Test
Document Reuse
Reemployment /
Refractor
Design Verification
Detailed Design /
Refractor
Define Reuse
Requirements
Reuseable Artifacts /
Development Activities
Implementatio
n
System Design
Architecting /
Preliminary Design
Technical
Requirement
Management
Definition
Analyze Reuse
Requirements
Development Processes
X
X
14
Example Scenario #1 – Incremental Development
Modification of Fielded System:
• Subcontractor provided component,
plug-n-play
• 3 existing system interfaces must be
modified to work with the newly
incorporated component
• The functional and performance changes
are captured by 34 system requirements
• Modification of five system interfaces
and one algorithm
• The subcontractor-provided subsystem
amounts to 66 system requirements and
7 system interfaces
• It also affects the operation of the end
system resulting in a modified mode of
operation
COSYSMO Systemlevel Cost Drivers:
New system requirements: 34
Managed system requirements: 66
Modified system interfaces: 5
Managed system interfaces: 7
New algorithm: 1
Adopted mode of operation: 1
Plus, Managed system requirements: the
number from previous system baseline
And, Managed system interfaces: the
number from previous system baseline
15
Example Scenario #2 – COTS Integration (DWR)
Enterprise IT System:
• Infrastructure service provider (ISP)
team to develop a new enterprise IT
system, based on integration of COTS
components
• System and applications software
provided by application service
provider (ASP)
• 15 core business functions based on
SOA
• 225 system requirements responsible
by the ISP team
• 75 of which are performance
requirements while the rest are
functional requirements
• 25 system-level interfaces
COSYSMO Systemlevel Cost Drivers:
New system requirements: 75
Adopted system requirements: 150
Adopted system interfaces: 25
Managed operation scenarios: 15
16
Example Scenario #3 – Development For Reuse
Standard API Development:
• Generalize existing functionalities
and services into reusable libraries
with standardized APIs during the
development of the current system,
encapsulating
• 25 system requirements
• 7 system interfaces
• 2 system critical algorithms
• And can potentially impact one
operational sequence
COSYSMO Systemlevel Cost Drivers:
Validated for Reuse Requirements:
25
Validated for Reuse Interfaces: 7
Validated for Reuse Algorithms: 2
Adopted Op. Scenario: 1
17