Generalized Reuse Model for COSYSMOWorkshop at 27th International Forum on COCOMO® and Systems/Software Cost ModelingPittsburgh, PA17 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

6

A Development Project May Contain Both

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

7

Reuse Viewpoint for Development

8

LineProductforInvest

SystemTargetDevelopActivitiestDevelopmen

% E

ffor

t

# of Articles in the Product Line

1 2 3 4

DFR

DWR DW

R

DFR

DWR

DFR

DWR

DFR

100

0

Total

Effort

Investments in Development for Reuse (DFR) are leveraged to reduce Product Line Cost

Product Line Benefits of Reuse

Definitions

10

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.

Interfacing DWR and DFR

11

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)

New, if architectural modification required

Implemented, if no modification required

Constructed for Reuse Constructed Product/Component New, if architectural modification required

Modified, if tailoring needed for integration

Adopted, if only integration and testing required

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

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

Extended COSYSMO Form

2,,,,,,2

1,,,,,,1

2

1

)(

)(

CEMwwwwA

CEMwwwwAPM

E

kkdkdknknkeke

qq

E

kkdkdknknkeke

rrDFRDWR

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

13

Added Activities Relative To Reusable Architects

14

Example Scenario #1 – Incremental Development

15

Example Scenario #2 – COTS Integration (DWR)

16

Example Scenario #3 – Development For Reuse

17