Modeling “Should Cost” and
“Will Cost” Using Model-Based
Systems Engineering
27th International Forum on COCOMO® and Systems/Software Cost Modeling
October 16—18, 2012
Software Engineering Institute, Pittsburgh, PA
Ricardo Valerdi Dan Galorath Quoc Do
With assistance from Lee Fischman and Matt Dabkowski
Outline
•
•
•
•
•
•
Will-cost vs. Should-cost
Model-Based Systems Engineering
DoDAF views
Network science
Use cases
Model integration examples
Will cost Should cost
The budget Program
baseline
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
Future
Past
• Specifications
ATC
• Interface requirements
Pilot
Airplane
Request to proceed
Authorize
Initiate power-up
• System design
Power-up
Report Status
Direct taxiway
• Analysis & Trade-offs
• Test plans
Moving from Document centric to Model centric
Parametric estimating from natural model artifacts
Initiate Taxi
Executed cmds
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 preexisting 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
Functional/Behavioral Model
Start
Shift
Accelerate
Brake
System Model
Engine
Transmission
Transaxle
Structural/Component Model
Performance Model
Control
Input
Power
Equations
Vehicle
Dynamics
Mass
Properties
Model
Structural
Model
Safety
Model
Cost
Model
Other Engineering
Analysis Models
Integrated System Model Must Address Multiple Aspects of a System
Page 7
Example SV-2 Systems Resource Flow Description (Hause 2011)
Used with permission.
SV-2/SvcV-2 [System] Control System [SV-2]
«System»
«block»
Control System
VP : Video Data
VP
CS->VP:VD : Video Data
VP->TFC:VD : Video Data
«SystemRole»
TFCSW : Traffic Flow Calculation SW
CS
TRG
«SystemRole»
VPSW : Video Processing SW
«SystemRole»
DBSW : Display Board SW
TFC
TRG->DB:TR : Traffic Report
SP
TRG
TE
SP->TFC:SD : Sensor Data
FC->TRG:TF : Traffic Flow
WebP
DB->CS : Traffic Status Message
CS
TFC
DB
«SystemRole»
SPSW : Sensor Processing SW
DB
TDA
TRG->TDA:TR : Traffic Report
RG
«SystemRole»
TDA : Traffic Data Archive SW
«SystemRole»
TRGSW : Traffic Report Generation SW
TFC
TP
Web
TC
TFC->TE:TF : Traffic Flow
SP->TP:SD : Sensor Data
TE
SP
TRG->TC:TR : Traffic Report «SystemRole»
TC TESW : Traffic Event SW
VP->Web:VD : Video Data
«SystemRole»
TPSW : Traffic Prediction SW
TRG->Web:TR : Traffic Report
VP
Web
CS
TE->TC:AER : Accident Event Report
TRG
TRG
TS
«SystemRole»
WebPSW : Web Presence SW
TE
TP : Sensor Data
CS
CS->TP:SD : Sensor Data
WP
WP->TP:WR : Weather Report
«SystemRole»
TCSW : Traffic Control SW
TP
ES
«SystemRole»
WPSW : Weather Processing SW
Web->CS:TR : Traffic Report
CS
WP : Weather Report
CS->WP:WR : Weather Report
TC->TS:TSS : Traffic Signal Schedule
«SystemRole»
TSSW : Traffic Signal SW
TC
«SystemRole»
TDSW : Traffic Display SW
CS
[System] Control Room [SV-6]
TC
«SystemRole»
ESSW : Emergency Services SW
TS->CS:TSS : Traffic Signal Schedule
[Architectural Description] Resources [SV-3]
TS
[Architectural Description] System Activities [SV-4]
CS
ES->CS:SR : Service Request
CS->ES:SS : Service Status
ES
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:
–
–
–
•
Actor weight is user-classified as:
–
–
–
•
5 – Simple : 3 or fewer steps
10 – Average : 4-7 steps
15 – Complex : more than 7 steps
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.
Galorath Prior Work: Model Based Estimating
Estimating from artifacts
documents to help remove
the early ‘cloud of
uncertainty’ surrounding
projects.
Automatic methods
introduce less bias and
better handle the ‘iceberg’
of unrecognized system
size.
An automatic method helps
eliminate a labor-intensive
and error-prone early sizing /
estimating chore.
13
Provides :another arrow in the
quiver” of sizing techniques
Ó Galorath Incorporated 20012
CriticalMass Software Sizing From Models For
Improved Early Software Sizing www.galorath.com
Requirements To Size
Software Descriptions
Multiple Uses
Use Case UML
Structured
Requirements
Expert
Sizing
System
Metrics
Size Estimate
•
•
•
•
SEER
Cost /
Schedule
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
Relative
Analysis
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)
Ó Galorath
Incorporated 2004
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
14
CriticalMass for Rose / UML
User Enters Use Case…
Chart Is Read In A
Machine-Readable
Format…
CriticalMass UML
Estimates
Desired Metric
T his use case w ill describe the steps required to run N orton D isk D octor. T he purpose for running this is as follow s:
N orton D isk D octor diagnoses and repairs a variety of disk problem s. It perform s several tests, checking everything from the disk's partit ion table to its physical surface. If N orton D isk D octor finds a problem , it
notifies you before m aking repairs. If you check A utom atically Fix E rrors, N orton D isk D octor m akes the necessary repairs autom atically.
A fter diagnosing and repairing a disk, N orton D isk D octor displays an easy-to-read report that lists the problem s found, the problem s fixed, and the areas of the disk that checked out okay.
1. Actor(s)
1.1
IT Support C lerk
2. Flow of E vents
2.1 B asic F lo w
2.1.1
IT Support C lerk selects D iagnose.
2.1.2
System exam ines disk for errors
2.1.3
System displays results
2.1.4
IT Support C lerk confirm s results
2.1.5
E nd of U se C ase.
3. Alternative Flow s
3.1 C o n tin u in g fro m 2.1.2 - S ystem id en tifies erro rs o n th e d isk
3.1.1
System identifies errors on the disk and displays fix option
3.1.2
IT Support C lerk chooses to correct errors
3.1.3
System corrects errors and displays results.
3.1.4
E nd of use case
3.2 C o n tin u in g fro m 2.1.2 - S ystem id en tifies erro rs o n th e d isk
3.2.1
System identifies errors on the disk and displays fix option
3.2.2
IT Support C lerk chooses not to fix errors on disk
3.2.3
System skips fix and displays results.
3.2.3
E nd of U se C ase
4. S pecial R equirem ents
5. P re-C onditions
5.1 System navigated from N orton System W orks to N orton U tilities to N orton D isk D octor
5.2 N orton D isk D octors is correctly installed on P C
6. P ost C ondition
6.1 N orton D isk D octor closed and System returns to idle condition
15
Ó Galorath Incorporated 2004
XXXXX lines of code
YYY unadjusted function points
ZZZ object measures
Today’s MBSE Environments
And others…
SEER Profile Is
Integrated Into Rhapsody
© 2011 Copyright Galorath Incorporated
SEER Estimate Is Generated On Demand
© 2011 Copyright Galorath Incorporated
Rhapsody Model Exported To SEERH for Additional Analysis
© 2011 Copyright Galorath Incorporated
SEER-H and Rhapsody,
Side By Side
© 2011 Copyright Galorath Incorporated
20