Affordability-Based Engineering

Affordability-Based Engineering
Barry Boehm, USC-CSSE Fall 2012

Outline Affordability definitions, concepts, issues, strategies
Addressing both costs and benefits Using life cycle present value Coping with uncertainty: incrementally; pro-actively Coping with multi-stakeholder value diversity Addressing tradeoffs with other -ilities An orthogonal framework for improving affordability costs Cost modeling and other insights Conclusions Copyright © USC-CSSE

Affordability Definitions
INCOSE: The balance of system performance, cost, and schedule constraints over the system life cycle, while satisfying mission needs in concert with strategic and organizational needs. MORS: Cost-effective capability (USD/ATL). NDIA: The practice of assuring program success through the balancing of system performance (KPPs), cost, and schedule constraints, while satisfying mission needs in concert with the long-range investment and force structure plans of the DoD. Webster: Keeping within your financial means. Copyright © USC-CSSE

Affordability Concepts Coping with uncertainty: incrementally; pro-actively Coping with multi-stakeholder value diversity Achievable Pareto Boundary Life Cycle Benefits Improve- ment Primary Option Space Increasing Cost-Benefit Improvement Isoquants Current Situation Life Cycle Cost Improvement Copyright © USC-CSSE

Multi-Stakeholder Value Diversity Bank of America Master Net
Copyright © USC-CSSE

Outline Affordability definitions, concepts, issues, strategies
Addressing both costs and benefits Using life cycle present value Coping with uncertainty: incrementally; pro-actively Coping with multi-stakeholder value diversity Addressing tradeoffs with other -ilities An orthogonal framework for improving affordability costs Cost modeling and other insights Conclusions Copyright © USC-CSSE

Affordability and Tradespace Framework
Staffing, Incentivizing, Teambuilding Get the Best from People Facilities, Support Services Kaizen (continuous improvement) Make Tasks More Efficient Tools and Automation Work and Oversight Streamlining Collaboration Technology Lean and Agile Methods Eliminate Tasks Affordability Improvements and Tradeoffs Task Automation Model-Based Product Generation Early Risk and Defect Elimination Eliminate Scrap, Rework Evidence-Based Decision Gates Modularity Around Sources of Change Incremental, Evolutionary Development Value-Based, Agile Process Maturity Risk-Based Prototyping Simplify Products (KISS) Value-Based Capability Prioritization Satisficing vs. Optimizing Performance Reuse Components Domain Engineering and Architecture Composable Components,Services, COTS Legacy System Repurposing Reduce Operations, Support Costs Automate Operations Elements Design for Maintainability, Evolvability Value- and Architecture-Based Tradeoffs and Balancing Streamline Supply Chain Anticipate, Prepare for Change Copyright © USC-CSSE

Costing Insights: COCOMO II Productivity Ranges
Scale Factor Ranges: 10, 100, 1000 KSLOC Development Flexibility (FLEX) Staffing Team Cohesion (TEAM) Develop for Reuse (RUSE) Teambuilding Precedentedness (PREC) Architecture and Risk Resolution (RESL) Continuous Improvement Platform Experience (PEXP) Data Base Size (DATA) Required Development Schedule (SCED) Language and Tools Experience (LTEX) Process Maturity (PMAT) Storage Constraint (STOR) Use of Software Tools (TOOL) Platform Volatility (PVOL) Applications Experience (AEXP) Multi-Site Development (SITE) Documentation Match to Life Cycle Needs (DOCU) Required Software Reliability (RELY) Personnel Continuity (PCON) Time Constraint (TIME) Programmer Capability (PCAP) Analyst Capability (ACAP) Product Complexity (CPLX) 1 1.2 1.4 1.6 1.8 2 2.2 2.4 Productivity Range Copyright © USC-CSSE

COSYSMO Sys Engr Cost Drivers
Teambuilding Continuous Improvement Staffing Copyright © USC-CSSE

Tradespace and Affordability Framework

COCOMO II. 2000 Productivity Ranges
Scale Factor Ranges: 10, 100, 1000 KSLOC Development Flexibility (FLEX) Tools Team Cohesion (TEAM) Develop for Reuse (RUSE) Collaboration Technology Precedentedness (PREC) Architecture and Risk Resolution (RESL) Work Streamlining Platform Experience (PEXP) Data Base Size (DATA) Required Development Schedule (SCED) Language and Tools Experience (LTEX) Process Maturity (PMAT) Storage Constraint (STOR) Use of Software Tools (TOOL) Platform Volatility (PVOL) Applications Experience (AEXP) Multi-Site Development (SITE) Documentation Match to Life Cycle Needs (DOCU) Required Software Reliability (RELY) Personnel Continuity (PCON) Time Constraint (TIME) Programmer Capability (PCAP) Analyst Capability (ACAP) Product Complexity (CPLX) 1 1.2 1.4 1.6 1.8 2 2.2 2.4 Productivity Range Copyright © USC-CSSE

Agile and Plan-Driven Home Grounds: Five Critical Decision Factors
Size, Criticality, Dynamism, Personnel, Culture Personnel Personnel (% Level 1B) (% Level 1B) (% Level 2&3) (% Level 2&3) 40 40 15 15 30 30 20 20 20 20 25 25 Criticality Criticality (Loss due to impact of defects) (Loss due to impact of defects) Dynamism Dynamism 10 10 30 30 (% Requirements (% Requirements - - change/month) change/month) Many Many 35 35 Lives Lives Single Single 0.3 Life Life Essential Essential 1.0 Funds Funds Discretionary Discretionary 3.0 Funds Funds Comfort Comfort 10 30 3 3 Agile Agile 90 90 10 10 70 70 30 30 Plan Plan - - driven driven 50 50 100 100 30 30 300 300 Size Size 10 10 (# of personnel) (# of personnel) Culture Culture (% thriving on chaos vs. order) (% thriving on chaos vs. order) Copyright © USC-CSSE

Architected Agile Approach
Uses Scrum of Scrums approach Up to 10 Scrum teams of 10 people each Has worked for distributed international teams Going to three levels generally infeasible General approach shown below Often tailored to special circumstances Copyright © USC-CSSE

Trends in Software Expansion (Bernstein, 1997)
MBSE:2010 Expansion Factor The ratio of machine lines of code to a source line of code 1 10 100 1000 1960 1965 1970 1975 1980 1985 1990 2000 1995 Order of Magnitude Increase Every Twenty Years Machine Instructions Macro Assembler High Level Language Database Manager On-line Regression Testing Prototyping 4GL Subsecond Time Sharing Small Scale Reuse Object Oriented Programming Large Scale 142 113 81 75 47 37.5 30 15 3 475 638 Copyright © USC-CSSE

COCOMO II. 2000 Productivity Ranges
Scale Factor Ranges: 10, 100, 1000 KSLOC Development Flexibility (FLEX) Team Cohesion (TEAM) Develop for Reuse (RUSE) Precedentedness (PREC) Architecture and Risk Resolution (RESL) Platform Experience (PEXP) Data Base Size (DATA) Required Development Schedule (SCED) Language and Tools Experience (LTEX) Process Maturity (PMAT) Storage Constraint (STOR) Use of Software Tools (TOOL) Platform Volatility (PVOL) Applications Experience (AEXP) Multi-Site Development (SITE) Documentation Match to Life Cycle Needs (DOCU) Required Software Reliability (RELY) Personnel Continuity (PCON) Time Constraint (TIME) Programmer Capability (PCAP) Analyst Capability (ACAP) Product Complexity (CPLX) 1 1.2 1.4 1.6 1.8 2 2.2 2.4 Productivity Range Copyright © USC-CSSE

Value-Based Testing: Empirical Data and ROI — LiGuo Huang, ISESE 2005

Sequential Requirements-First Risks It’s not a requirement if you can’t afford it
Required Architecture: Custom; many cache processors Original Architecture: Commercial DBMS 1 2 3 4 5 Response Time (sec) Original Spec After Prototyping Original Budget Problems Encountered without FED In the early 1980s, a large government organization contracted with TRW to develop an ambitious information query and analysis system. The system would provide more than 1,000 users, spread across a large building complex, with powerful query and analysis capabilities for a large and dynamic database. TRW and the customer specified the system using a classic sequential-engineering waterfall development model. Based largely on user need surveys, an oversimplified high-level performance analysis, and a short deadline for getting the TBDs out of the requirements specification, they fixed into the contract a requirement for a system response time of less than one second. Subsequently, the software architects found that subsecond performance could only be provided via a highly customized design that attempted to anticipate query patterns and cache copies of data so that each user’s likely data would be within one second’s reach (a 1980’s precursor of Google). The resulting hardware architecture had more than 25 super-midicomputers busy caching data according to algorithms whose actual performance defied easy analysis. The scope and complexity of the hardware-software architecture brought the estimated cost of the system to nearly $100 million, driven primarily by the requirement for a one-second response time. Faced with this unattractive prospect (far more than the customer’s budget for the system), the customer and developer decided to develop a prototype of the system’s user interface and representative capabilities to test. The results showed that a four-second response time would satisfy users 90 percent of the time. A four-second response time, with special handling for high-priority transactions, dropped development costs closer to $30 million. Thus, the premature specification of a 1-second response time neglected the risk of creating an overexpensive and time-consuming system development. Fortunately, in this case, the only loss was the wasted effort on the expensive-system architecture and a 15 month delay in delivery. More frequently, such rework is done only after the expensive full system is delivered and found still too slow and too expensive to operate. Copyright © USC-CSSE File: Feasibility Evidence Developmentv8

Value-Neutral Defect Fixing Is Even Worse
Automated test generation tool - all tests have equal value Pareto Business Value 100 80 % of Value for Correct Customer Billing 60 40 20 Value-neutral defect fixing: Quickly reduce # of defects 5 10 15 Customer Type Copyright © USC-CSSE

Reuse at HP’s Queensferry Telecommunication Division
Time to Market (months) Non-reuse Project Reuse project Copyright © USC-CSSE

The HMMWV 300,000 Produced, 22 Fielded Versions
Initial draft requirements in 1979, Initial delivery in 1984 Bolt on armor required upgraded suspension, engine, and steering Additional armor and cupola raise the CG and increase rollovers Mattracks or wheels Upgrades: Increased cab space Increased payload capacity Strengthened frame Upper deck space is always at a premium Imbalance in cupola required motorized drive Suspension and steering for CG shift Base cab & flatbed with mission modules 9 Copyright © USC-CSSE

Product Line Engineering and Management

Post-Acquisition Costs Dominate (%O&M)
Hardware [Redman 2008] 12% -- Missiles (average) 60% -- Ships (average) 78% -- Aircraft (F-16) 84% -- Ground vehicles (Bradley) Software [Koskinen 2010] 75-90% -- Business, Command-Control 50-80% -- Complex platforms as above 10-30% -- Simple embedded software Apply lack-of-flexibility factor to O&M component Copyright © USC-CSSE

Overfocus on Acquisition Cost C4ISR Contracts: Nominal-case requirements; 90 days to PDR

C4ISR Project C: Architecting for Change USAF/ESC-TRW CCPDS-R Project*
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. Copyright © USC-CSSE

Relative* Total Ownership Cost (TOC)
~5% architecture investment ~5% architecture investment ~25% architecture investment * Cumulative architecting and rework effort relative to initial development effort Copyright © USC-CSSE

Tradeoffs Among Cost, Schedule, and Reliability, and Functionality: COCOMO II
(RELY, MTBF (hours)) For 100-KSLOC set of features Can “pick all three” with 77-KSLOC set of features -- Cost/Schedule/RELY: “pick any two” points Copyright © USC-CSSE

A Value-Priority Tradeoff Equalizer

Ilities in Tradespace Exploration: MIT
Changeability Enabling Construct: Tradespace Networks Survivability Enabling Construct: Epochs and Eras Value Robustness Set of Metrics Copyright © USC-CSSE

Architecture-Based Attribute Trades: Flexibility Example (RT-18a)
Flexibility Arch. Strategy Synergies Conflicts High module cohesion; Low module coupling Interoperability Reliability High Performance via Tight coupling Service-oriented architecture Composability, Usability, Testability Autonomous adaptive systems Affordability via task automation; Response time Excess autonomy reduces human Controllability Modularization around sources of change Interoperability, Usability, Reliability, Availability Extra time on critical path of Rapid Fielding Multi-layered architecture Reliability, Availability Lower Performance due to layer traversal overhead Many built-in options, entry points Functionality, Accessibility Reduced Usability via options proliferation; harder to Secure User programmability Usability, Mission Effectiveness Full programmability causes Reliability, Safety, Security risks Spare/expandable capacity Performance, Reliability Added cost Product line architecture, reusable components Cost, Schedule, Reliability Some loss of performance vs. optimized stovepipes Copyright © USC-CSSE

Value/Risk-Based Tradespace Analysis - Early Startup: Risk due to low dependability - Commercial: Risk due to low dependability - High Finance: Risk due to low dependability - Risk due to market share erosion Sweet Spot COCOMO II: 12 22 34 54 Added % test time COQUALMO: 1.0 .475 .24 .125 0.06 P(L) Early Startup: .33 .19 .11 .06 .03 S(L) Commercial: .56 .32 .18 .10 High Finance: 3.0 1.68 .96 .54 .30 Market Risk: .008 .027 .09 REm Copyright © USC-CSSE

Conclusions Affordability increasingly competition-critical
Need to balance cost, schedule, performance, functionality Orthogonal framework helps tailor improvements Getting the best from people Making tasks more efficient Eliminating tasks Eliminating scrap and rework Simplifying products Reusing assets Reducing operations and support costs Value- and architecture-based tradeoffs and balancing No one-size-fits-all solution Copyright © USC-CSSE

Magnitude of Overrun Problem: DoD

Magnitude of Overrun Problem: Standish Surveys of Commercial Projects
Year 2000 2002 2004 2006 2008 Within budget and schedule 28 34 29 35 32 Prematurely cancelled 23 15 18 19 24 Budget or schedule overrun 49 51 53 46 44 Copyright © USC-CSSE

Some Frequent Overrun Causes
Conspiracy of Optimism Effects of First Budget Shortfall System Engineering Decoupling of Technical and Cost Analysis Overfocus on Performance, Security, Functionality Overfocus on Acquisition Cost Assumption of Stability Total vs. Incremental Commitment Copyright © USC-CSSE

The Conspiracy of Optimism and The Cone of Uncertainty

Assumption of Stability vs
Assumption of Stability vs. Rapid Change – Need evolutionary/incremental vs. one-shot development Uncertainties in competition, technology, organizations, mission priorities There is Another Cone of Uncertainty: Shorter increments are better Uncertainties in competition and technology evolution and changes in organizations and mission priorities, can wreak havoc with the best of system development programs. In addition, the longer the development cycle, the more likely it will be that several of these uncertainties or changes will occur and make the originally-defined system obsolete. Therefore, planning to develop a system using short increments helps to ensure that early, high priority capabilities can be developed and fielded and changes can be more easily accommodated in future increments. Copyright © USC-CSSE

Affordability-Based Engineering

Similar presentations

Presentation on theme: "Affordability-Based Engineering"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Affordability-Based Engineering

Similar presentations

Presentation on theme: "Affordability-Based Engineering"— Presentation transcript:

Similar presentations

About project

Feedback