modeling “should cost” and “will cost” using model-based systems engineering ricardo valerdi...

20
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 International Forum on COCOMO® and Systems/Software Cost Modeling er 16—18, 2012 are Engineering Institute, Pittsburgh, PA

Upload: carol-pigott

Post on 31-Mar-2015

216 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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

Page 2: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

Outline

• Will-cost vs. Should-cost• Model-Based Systems Engineering• DoDAF views• Network science• Use cases• Model integration examples

Page 3: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

Will cost Should costThe budget baseline

Program execution target

See Ashton Carter Initiatives (2010)

Page 4: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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.

Page 5: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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

Page 6: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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

Page 7: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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

Page 8: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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.

Page 9: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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

Page 10: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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),

Page 11: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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?

Page 12: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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.

Page 13: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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

Page 14: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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

Page 15: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

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

Page 16: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

Today’s MBSE Environments

And others…

Page 17: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

SEER Profile IsIntegrated Into Rhapsody

© 2011 Copyright Galorath Incorporated

Page 18: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

SEER Estimate Is Generated On Demand

© 2011 Copyright Galorath Incorporated

Page 19: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

Rhapsody Model Exported To SEER-H for Additional Analysis

© 2011 Copyright Galorath Incorporated

Page 20: Modeling “Should Cost” and “Will Cost” Using Model-Based Systems Engineering Ricardo Valerdi Dan GalorathQuoc Do With assistance from Lee Fischman and

SEER-H and Rhapsody,Side By Side

© 2011 Copyright Galorath Incorporated 20