Presentation on theme: "Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and."— Presentation transcript:
Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and Matt Dabkowski 27th International Forum on COCOMO® and Systems/Software Cost Modeling October 16—18, 2012 Software Engineering Institute, Pittsburgh, PA
Outline Will-cost vs. Should-cost Model-Based Systems Engineering DoDAF views Network science Use cases Model integration examples
Will costShould cost The budget baseline Program execution target See Ashton Carter Initiatives (2010)
Model Based Systems Engineering INCOSE Definition “formalized application of modeling to support system requirements, design, analysis, verification, and validation, beginning in the conceptual design phase and continuing throughout development and later life cycle phases” Advantages – Project information can be readily shared within large, complex projects – changes can be easily accommodated – Comprehensive traceability can be automated.
Model-Based Systems Engineering Specifications Interface requirements System design Analysis & Trade-offs Test plans Moving from Document centric to Model centric Parametric estimating from natural model artifacts Past Future
Challenges Estimating from models themselves – Some existing successes e.g. Galorath estimates from use case diagrams Galorath initial integration of SEER to Rational Rhapsody Upgrades are key activities in large long-lifetime systems of pre- existing in-service components Producing accurate, robust and realistic system upgrade plans remains a challenge Estimating is very costly and time consuming – Development, Total Ownership, Risk Affordability trades are cumbersome and often limited by time & resources
System Modeling Requirements Integrated System Model Must Address Multiple Aspects of a System Page 7
Example SV-2 Systems Resource Flow Description (Hause 2011) Used with permission.
MBSE, Cost Analysis and Network Science As MBSE matures, relationships between cost, schedule & performance can be determined DoD Architecture Framework (DoDAF) as an example Systems View - treated as networks, they can be mathematically analyzed – providing additional summary metrics that might yield valuable insight into the degree of effort (i.e., cost) required to bring a system to fruition. – For example: if the addition of a new subsystem can be abstracted to the addition of a vertex to a network, Can apply contemporary methods from network science to grow the network and estimate its cost. And provide an objective way to quantify and assess change Then can turn MBSE knowledge into computational knowledge supporting – Tradeoffs – Change impact analysis – related analysis early in the life cycle
Network Science SV3 for a hypothetical system network science: Concerned with modeling and analyzing the connections (or edges) that exist between a network’s components (or vertices),
MBSE Cost Use Cases What is the cost impact of adding more requirements? How do requirements volatility and uncertainty impact cost? Which are my highest value capabilities in terms of cost-per-functionality (i.e., bang for the buck)? What are the cost impacts of delaying, reducing, or eliminating certain capabilities? How does schedule compression influence program cost?
Galorath Prior Work By Criticalmass: SEER IBM RSx / ROSE Integration… Extracts Use Case Points from Models A weighted count of actors and use cases. Use Case weight is automatically classified as: – 5 – Simple : 3 or fewer steps – 10 – Average : 4-7 steps – 15 – Complex : more than 7 steps Actor weight is user-classified as: – 1 – Simple : highly defined and elemental, such as a simple API call – 2 – Average : user-driven interaction, allowing some freedom – 3 – Complex : potentially complex interaction “Traditionally” UUCPs are calculated for an entire system; the IBM RSA Integration calculates them per use case The ‘weight’ of this actor is shared between two use cases. In this way, the summed UUCP count is comparable to the traditional method of counting UUCPs at a high level only.
13 Ó Galorath Incorporated Galorath Prior Work: Model Based Estimating Automatic methods introduce less bias and better handle the ‘iceberg’ of unrecognized system size. Estimating from artifacts documents to help remove the early ‘cloud of uncertainty’ surrounding projects. An automatic method helps eliminate a labor-intensive and error-prone early sizing / estimating chore. Provides :another arrow in the quiver” of sizing techniques
14 Ó Galorath Incorporated 2004 CriticalMass Software Sizing From Models For Improved Early Software Sizing Requirements To Size Size Estimation from DOORS Requirements Uses parsing, repository, patterns, and relative sizing Learning from user data desirable Size data required… Allocation to requirements highly desirable Software Sizing From Repository Information stored in repository for relative or absolute size estimation Baseline size, application, platform, reuse kinds of data Any size data required FORECAST SIZE AT COMPLETION via convergence of size and plans from repository Relative sizing (SEER-AccuScope) UML To Size Size estimation from UML and automated extraction from Rational Rose Uses NUCs (Normalized Use Case measures) Learning from user size data desirable Size data required… Allocation to use cases highly desirable Use Case UML Structured Requirements Expert Sizing System Multiple Uses SEER Cost / Schedule Software Descriptions Size Estimate Metrics Relative Analysis
15Ó Galorath Incorporated 2004 CriticalMass for Rose / UML User Enters Use Case… Chart Is Read In A Machine-Readable Format… CriticalMass UML Estimates Desired Metric XXXXX lines of code YYY unadjusted function points ZZZ object measures