modeling “should cost” and “will cost” using model-based systems engineering ricardo valerdi...
TRANSCRIPT
Modeling “Should Cost” and “Will Cost” Using Model-Based
Systems Engineering
Ricardo Valerdi Dan Galorath Quoc Do
With assistance from Lee Fischman and Matt Dabkowski
27th International Forum on COCOMO® and Systems/Software Cost ModelingOctober 16—18, 2012Software Engineering Institute, Pittsburgh, PA
Outline
• Will-cost vs. Should-cost• Model-Based Systems Engineering• DoDAF views• Network science• Use cases• Model integration examples
Will cost Should costThe 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
AirplaneATC Pilot
Request to proceed
Authorize
Power-up
Initiate power-up
Direct taxiway
Report Status
Executed cmds
Initiate Taxi
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
Start Shift Accelerate Brake
Engine Transmission Transaxle
ControlInput
PowerEquations
VehicleDynamics
Functional/Behavioral Model
Structural/Component Model
Performance Model
MassProperties
ModelStructuralModel
SafetyModel
Other EngineeringAnalysis Models
CostModel
System Model
Requirements
Integrated System Model Must Address Multiple Aspects of a System
Page 7
SV-2/SvcV-2 [System] Control System [SV-2]
«System»«block»
Control System
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 ScienceSV3 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 20012
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 www.galorath.com
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 Use Case UML
Structured Requirements
Structured Requirements
Expert Sizing
System
Multiple Uses
SEER Cost /
Schedule
Software Descriptions
Size Estimate
Metrics
RelativeAnalysis
RelativeAnalysis
15Ó Galorath Incorporated 2004
CriticalMass for Rose / UML
This use case will describe the steps required to run Norton Disk Doctor. The purpose for running this is as follows:
Norton Disk Doctor diagnoses and repairs a variety of disk problems. It performs several tests, checking everything from the disk's partit ion table to its physical surface. If Norton Disk Doctor finds a problem, it notifies you before making repairs. If you check Automatically Fix Errors, Norton Disk Doctor makes the necessary repairs automatically.
After diagnosing and repairing a disk, Norton Disk Doctor displays an easy-to-read report that lists the problems found, the problems fixed, and the areas of the disk that checked out okay.
1. Actor(s) 1.1 IT Support Clerk
2. Flow of Events 2.1 Basic Flow
2.1.1 IT Support Clerk selects Diagnose.
2.1.2 System examines disk for errors
2.1.3 System displays results
2.1.4 IT Support Clerk confirms results
2.1.5 End of Use Case.
3. Alternative Flows 3.1 Continuing from 2.1.2 - System identifies errors on the disk
3.1.1 System identifies errors on the disk and displays fix option
3.1.2 IT Support Clerk chooses to correct errors
3.1.3 System corrects errors and displays results.
3.1.4 End of use case
3.2 Continuing from 2.1.2 - System identifies errors on the disk
3.2.1 System identifies errors on the disk and displays fix option
3.2.2 IT Support Clerk chooses not to fix errors on disk
3.2.3 System skips fix and displays results.
3.2.3 End of Use Case
4. Special Requirements
5. Pre-Conditions 5.1 System navigated from Norton SystemWorks to Norton Utilities to Norton Disk Doctor
5.2 Norton Disk Doctors is correctly installed on PC
6. Post Condition 6.1 Norton Disk Doctor closed and System returns to idle condition
User Enters Use Case…Chart Is Read In AMachine-Readable
Format…
CriticalMass UMLEstimates
Desired Metric
XXXXX lines of codeYYY unadjusted function points
ZZZ object measures
Today’s MBSE Environments
And others…
SEER Profile IsIntegrated Into Rhapsody
© 2011 Copyright Galorath Incorporated
SEER Estimate Is Generated On Demand
© 2011 Copyright Galorath Incorporated
Rhapsody Model Exported To SEER-H for Additional Analysis
© 2011 Copyright Galorath Incorporated
SEER-H and Rhapsody,Side By Side
© 2011 Copyright Galorath Incorporated 20