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

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.

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

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

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

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

Reuse Viewpoint for Development  

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

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.

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

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

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

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

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

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

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