1. Generalized Reuse Model for COSYSMO
Workshop at 27th International Forum on COCOMO® and Systems/Software Cost Modeling
Pittsburgh, PA
17 October 2012

2. 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

3. 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.

4. 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

5. 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

6. 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

7. Contrasting Between Two Perspectives
Development with Reuse (DWR)
Development for Reuse (DFR)
Role
Consumer
Producer
Purpose
Consumption of reusable resources
Production of reusable resources
Goal
Improving product quality
Cost savings
Time to market
Investment for future benefits
Challenges
Discovery of what to reuse
Decisions on how to tailor and integrate
Plans for how to reuse
Design for reusability
Means to verify
Reusability
If ad hoc, then generally low
If planned, then generally high
Generally high

8. Reuse Viewpoint for Development

9. Product Line Benefits of Reuse
Total Effort
100
DWR
DWR
DWR
% Effort
DWR
DFR
DFR
DFR
DFR 1 2 3 4
# of Articles in the Product Line
Investments in Development for Reuse (DFR) are leveraged to reduce Product Line Cost

10. Development With Reuse (DWR) Development For Reuse (DFR)
Definitions
Development With Reuse (DWR)
New
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.
Implemented
Element that is developed from inherited physical architecture or previously constructed product components that require re-implementation or refactoring.
Modified
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.
Deleted
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.
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.

11. Interfacing DWR and DFR
Reusability from DFR Produces
Reusable Resources
Reused by DWR with Effort
Conceptualized for Reuse
System Concept Definition
New
Logical Architecture
Designed for Reuse
Physical Architecture (intended for built to print)
New, if architectural modification required
Implemented, if no modification required
Constructed for Reuse
Constructed Product/Component
Modified, if tailoring needed for integration
Adopted, if only integration and testing required
Validated for Reuse
Validated Product/Component
Managed, if limited testing required

12. Extended COSYSMO Form Where:
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

13. Required Activities Relative To Reusable Architects
Development Processes
Technical Management
Requirement Definition
System Design
Implementation
Verificaiton Test
Transition To Use
Reusable Artifacts / Development Activities
Define Requiremnets
Analyze Requirements
Select Reuse
Understand & Assess
Architecting / Premilinary Design
Detailed Design / Refactor
Design Verificaiton
Specialize / Tailor (Wrap)
Reimplement / Refactor / Extend
Integrate
Develop Test Plan/Procedures
Execute Test
Inspection
Installation
Operational Test
System Concept X
Use As-Is
Logical Architecture
Physical Architecture
Constructed Product/Component
Validated Product/Component
Modify

14. Added Activities Relative To Reusable Architects
Development Processes
Technical Management
Requirement Definition
System Design
Implementation
Verification Test
Transition To Use
Reuseable Artifacts / Development Activities
Define Reuse Requirements
Analyze Reuse Requirements
Architecting / Preliminary Design
Detailed Design / Refractor
Design Verification
Reemployment / Refractor
Document Reuse
Develop Test
Execute Test
Inspection
Deployment
Operational Test
System Concept X
Logical Architecture
Physical Architecture
Constructed Product/Component
Deployed Product/Component

15. 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
DWR
COSYSMO System-level 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

16. 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
DWR
COSYSMO System-level Cost Drivers:
New system requirements: 75
Adopted system requirements: 150
Adopted system interfaces: 25
Managed operation scenarios: 15

17. 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
DFR
COSYSMO System-level Cost Drivers:
Validated for Reuse Requirements: 25
Validated for Reuse Interfaces: 7
Validated for Reuse Algorithms: 2
Adopted Op. Scenario: 1