Valuing System Flexibility via Total Ownership Cost Analysis Barry Boehm, JoAnn Lane, USC Ray Madachy, NPS NDIA Systems Engineering Conference October.

Slides:



Advertisements
Similar presentations
Whos the Architect? Credential Provisioning Network Access Directory Services Authentication, Authorization and Accounting Federation Single.
Advertisements

Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering.
UML an overview.
Incremental Commitment Spiral Model, Expedited Engineering, and Kanban Jo Ann Lane and Alexey Tregubov USC CSSE Rich Turner Stevens University.
Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department of Defense © 2001 by Carnegie Mellon.
Copyright 2000, Stephan Kelley1 Estimating User Interface Effort Using A Formal Method By Stephan Kelley 16 November 2000.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Unified theory of software evolution Reengineering – Business process reengineering and software reengineering BPR model – Business definition, process.
Thammanoon Kawinfruangfukul CSSE MS, ID:
Systems Engineering in a System of Systems Context
COCOMO Suite Model Unification Tool Ray Madachy 23rd International Forum on COCOMO and Systems/Software Cost Modeling October 27, 2008.
Proposed Way Forward for SERC EM Task Barry Boehm, USC-CSSE 30 January 2009.
University of Southern California Center for Software Engineering CSE USC System Dynamics Modeling of a Spiral Hybrid Process Ray Madachy, Barry Boehm,
Automated Analysis and Code Generation for Domain-Specific Models George Edwards Center for Systems and Software Engineering University of Southern California.
University of Southern California Center for Systems and Software Engineering USC CSSE Research Overview Barry Boehm Sue Koolmanojwong Jo Ann Lane Nupul.
Azad Madni Professor Director, SAE Program Viterbi School of Engineering Platform-based Engineering: Rapid, Risk-mitigated Development.
Integration of Software Cost Estimates Across COCOMO, SEER- SEM, and PRICE-S models Tom Harwick, Engineering Specialist Northrop Grumman Corporation Integrated.
University of Southern California Center for Systems and Software Engineering System of Systems Engineering Cost Modeling: Strategies for Different Types.
Enterprise Architecture The Arkansas Approach. Key Areas What is enterprise architecture? Why is it important? How you can participate Current status.
Integrated COCOMO Suite Tool for Education Ray Madachy 24th International Forum on COCOMO and Systems/Software Cost Modeling November.
©2011 Rolls-Royce plc The information in this document is the property of Rolls-Royce plc and may not be copied or communicated to a third party, or used.
Introduction Wilson Rosa, AFCAA CSSE Annual Research Review March 8, 2010.
Process Synchronization Workshop Summary Report Jo Ann Lane University of Southern California Center for Software Engineering.
Estimating System of Systems Engineering (SoSE) Effort Jo Ann Lane, USC Symposium on Complex Systems Engineering January 11-12, 2007.
University of Southern California Center for Software Engineering CSE USC 110/26/2004©USC-CSE Welcome and Overview: COCOMO / SCM #19 Forum and Workshops.
University of Southern California Center for Software Engineering C S E USC Agile and Plan-Driven Methods Barry Boehm, USC USC-CSE Affiliates’ Workshop.
Copyright © 2001, Software Productivity Consortium NFP, Inc. SOFTWARE PRODUCTIVITY CONSORTIUM SOFTWARE PRODUCTIVITY CONSORTIUM COSYSMO Overview INCOSE.
1 Object-Oriented Software Engineering CIS 375 Bruce R. Maxim UM-Dearborn.
University of Southern California Center for Software Engineering C S E USC August 2001©USC-CSE1 CeBASE Experience Base (eBASE) -Shared Vision Barry Boehm,
Information System Economics Software Project Cost Estimation.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 22 Instructor Paulo Alencar.
© 2012 PRICE Systems, LLC. All Rights Reserved. Optimize tomorrow today. ® Understanding and Measuring the Impact of Design and Systems Engineering Decisions.
Fourteenth Lecture Hour 9:30 – 10:20 am, Sunday, September 16 Software Management Disciplines Project Control and Process Automation (from Part III, Chapter.
PO320: Reporting with the EPM Solution Keshav Puttaswamy Program Manager Lead Project Business Unit Microsoft Corporation.
R R R 1 Frameworks III Practical Issues. R R R 2 How to use Application Frameworks Application developed with Framework has 3 parts: –framework –concrete.
University of Southern California Center for Software Engineering C S E USC Using COCOMO for Software Decisions - from COCOMO II Book, Section 2.6 Barry.
University of Southern California Center for Software Engineering C S E USC Using COCOMO for Software Decisions - from COCOMO II Book, Section 2.6 Barry.
Cost Estimation What is estimated? –resources (humans, components, tools) –cost (person-months) –schedule (months) Why? –Personnel allocation –Contract.
Gan Wang 22 October th International Forum on COCOMO® and Systems/Software Cost Modeling in conjunction with the Practical Software and Systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 1 Software cost estimation 2.
University of Southern California Center for Systems and Software Engineering COCOMO Suite Toolset Ray Madachy, NPS Winsor Brown, USC.
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
SFWR ENG 3KO4 Slide 1 Management of Software Engineering Chapter 8: Fundamentals of Software Engineering C. Ghezzi, M. Jazayeri, D. Mandrioli.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Function Points Synthetic measure of program size used to estimate size early in the project Easier (than lines of code) to calculate from requirements.
Riding Herd on Total Ownership Costs: Herding Sheep vs. Herding Cats Barry Boehm, USC STC 2015 Keynote Address October 13, /21/20111.
Software Engineering (CSI 321) Project Planning & Estimation 1.
The COCOMO model An empirical model based on project experience. Well-documented, ‘independent’ model which is not tied to a specific software vendor.
Schedule Estimation and Improvement Barry Boehm, USC-CSSE CS 577a, Fall
DISTRIBUTION STATEMENT A -- Cleared for public release by OSR on 08 October SR case number #11-S-0041 applies. 13 th Annual NDIA SE Conf Oct 2010.
University of Southern California Center for Systems and Software Engineering Enablers and Inhibitors for Expediting Systems and Software Engineering &
BV41840 Schedule Risk Analysis of Software Development By: Dr. Joe H. Dean Engineering Chief Risk & System Analysis LFWC And: Mr. David W. Benson, Jr.
Slide 1 Software Construction Software Construction Lecture 3.
University of Southern California Center for Software Engineering C S E USC ICSM Principles for Successful Software and Systems Engineering Barry Boehm,
1 Agile COCOMO II: A Tool for Software Cost Estimating by Analogy Cyrus Fakharzadeh Barry Boehm Gunjan Sharman SCEA 2002 Presentation University of Southern.
Reference Architecture for NASA’s Earth Science Data Systems Richard Ullman ES-DSWG-SPG Chair NASA/GSFC Code 586.
An Iterative Method For System Integration
Using COCOMO for Software Decisions - from COCOMO II Book, Section 2.6
Riding Herd on Total Ownership Costs: Herding Sheep vs
Building a Complex System in a Standards-Driven Environment
Systems of Systems Challenges and Strategies
Using COCOMO for Software Decisions - from COCOMO II Book, Section 2
Using COCOMO for Software Decisions - from COCOMO II Book, Section 2
Introduction to Constructive COTS (COCOTS) Model and Tool
COCOMO 2 COCOMO 81 was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch. Since.
Comparison between each special case
Enterprise Architecture at Penn State
Using COCOMO for Software Decisions - from COCOMO II Book, Section 2.6
Using COCOMO for Software Decisions - from COCOMO II Book, Section 2.6
Presentation transcript:

Valuing System Flexibility via Total Ownership Cost Analysis Barry Boehm, JoAnn Lane, USC Ray Madachy, NPS NDIA Systems Engineering Conference October 27, 2010

Outline Research Project Context Flexibility Definitions and Common Cases Total Ownership Cost (TOC) Results to Date – Advantages, Challenges, Strategies – TOC Analysis for Foreseeable Change For individual systems For families of systems – Conclusions and Candidate Extensions Refined and extended model capabilities Integration with alternative valuation models 2Valuing Flexibility via TOC10/27/2010

Research Project Context Part of SERC Valuing Flexibility Research Task – For DDR&E Director of Systems Engineering Steve Welby Provide business cases for investing in system flexibility – Vs. buying more copies of less flexible systems Performed by multi-university team – Texas A&M, AFIT, NPS, USC, U. Virginia Using multiple analysis approaches – Knowledge Value Added, Option Hedging, Portfolio Analysis, Risk Analysis, Total Ownership Cost (TOC) Analysis 10/27/2010Valuing Flexibility via TOC3

Flexibility Definitions and Common Cases Working definition of “flexibility” – Ability to adapt cost-effectively to sources of change Foreseeable sources of change – Within single system: encapsulate sources of change – Across family of systems: use commonalities and variabilities Unforeseeable sources of change – Build in analysis of change traffic, adaptability – Build in system margins Classes of change effects – Capabilities, interfaces, levels of service, project constraints, improvement opportunities Valuing Flexibility via TOC410/27/2010

Total Ownership Cost (TOC) Approach TOC Advantages, Challenges, Strategies – Representative examples TOC Analysis for Foreseeable Change – Model and tool for individual systems Calibrated to TRW software data (3 systems) Exploring calibration to NPS SHIPMAIN hardware data – Model and tool for families of systems Calibrated to COCOMO II software data (161 projects) Exploring calibration to AFIT modular munitions hardware data Candidate Extensions – Refined and extended model capabilities Particular domains, tradeoff analyses, enterprise analysis Effects of adaptation to unforeseeable change – Integration with alternative valuation models Valuing Flexibility via TOC510/27/2010

TOC Advantages, Challenges, Strategies TOC Advantages – Increasingly required (DoDI , WSARA 2009) – Easy to understand across specialty domains – Clear cause-effect relationships, straightforward calibration TOC Challenges – Defining flexibility investment costs, resulting cost reductions Rework and change-adaptation cost reductions a proxy for benefits – Predicting uncertain futures TOC Approach Strategies – Tailor analysis approaches to common situations DoDI milestone reviews, make-or-buy decisions – Explicitly emphasize need to define evolution requirements Not just snapshot capability, interface, KPP, project requirements – Start with simple models and tools, refine and extend as needed Valuing Flexibility via TOC610/27/2010

Outline Research Project Context Flexibility Definitions and Common Cases Total Ownership Cost (TOC) Results to Date – Advantages, Challenges, Strategies – TOC Analysis for Foreseeable Change For individual systems For families of systems – Conclusions and Candidate Extensions Refined and extended model capabilities Integration with alternative valuation models 7Valuing Flexibility via TOC10/27/2010

Point-Solution Architectures Cause Major Rework Contracts: Nominal-case requirements; 90 days to PDR 8Valuing Flexibility via TOC10/27/2010

Projects A and B Major Rework Sources - Change processing over 1 person-month = 152 person-hours 10/27/2010Valuing Flexibility via TOC9 CategoryProject AProject B Extra long messages = 5045 Network failover = 3040 Hardware-software interface = = 2832 Encryption algorithms = 1615 Subcontractor interface = 2060 GUI revision =2550 Data compression algorithm 910 External applications interface = 1460 COTS upgrades = = 1461 Database restructure = 1860 Routing algorithms = 692 Diagnostic aids = 979 TOTAL:

Project C: Architecting for Change USAF/ESC-TRW CCPDS-R Project* 10/27/2010Valuing Flexibility via TOC10 When investments made in architecture, average time for change order becomes relatively stable over time… * Walker Royce, Software Project Management: A Unified Framework. Addison-Wesley, 1998.

Single-System TOC Model Example 10/27/2010Valuing Flexibility via TOC11

Relative* Total Ownership Cost (TOC) 10/27/2010Valuing Flexibility via TOC12 * Cumulative architecting and rework effort relative to initial development effort ~5% architecture investment ~25% architecture investment

Product-Line Flexibility Value Modeling USC and NPS collaborating on modeling value of investing in product-line flexibility with Return-On-Investment (ROI) and Total Ownership Cost (TOC) parametric models – System-level product line flexibility investment model – Software product line flexibility investment model. – Net present value (NPV) calculations included Models adapted from the Constructive Product Line Investment Model (COPLIMO*) – Special versions also developed for Daimler Chrysler and JPL * Barry Boehm, A. Winsor Brown, Ray Madachy, Ye Yang, "A Software Product Line Life Cycle Cost Estimation Model," Proceedings of the 2004 International Symposium on Empirical Software Engineering, /27/201013Valuing Flexibility via TOC

14 Systems Product Line Flexibility Value Model Systems PL Flexibility Value Model For Set of Products: Average Product Cost Annual Change Cost Ownership Time Percent Mission- Unique, Adapted, Reused Relative Cost of Developing for PL Flexibility via Reuse Relative Costs of Reuse As Functions of # Products, # Years in Life Cycle: PL Total Ownership Costs PL Flexibility Investment PL Savings (ROI) 10/27/2010Valuing Flexibility via TOC

Systems Product Line Results 10/27/201015Valuing Flexibility via TOC

Sensitivity Analysis Example 1610/27/2010Valuing Flexibility via TOC

Conclusions and Candidate Extensions TOC approach has several advantages – Increasingly required (DoDI , WSARA 2009) – Easy to understand across specialty domains – Clear cause-effect relationships, straightforward calibration Important to determine evolution requirements Basic models available for foreseeable change – Individual systems, families of systems – Best to have calibration data Candidate Extensions – Refined and extended model capabilities Particular domains, tradeoff analyses, enterprise analysis Effects of adaptation to unforeseeable change – Integration with alternative valuation models 10/27/2010Valuing Flexibility via TOC17