Bruce’s Modeling Hints The Secrets to Effective Modeling for Systems Engineers

®

IBM Software Group

© 2014 IBM CorporationInnovation for a smarter planet

Bruce’s Modeling Hints

The Secrets to Effective Modeling for Systems EngineersDr. Bruce Powel Douglass, Ph.D.Chief Evangelist, Global Technology AmbassadorIBM [email protected]: @BruceDouglassYahoo: http://tech.groups.yahoo.com/group/RT-UML

mailto:[email protected]

http://tech.groups.yahoo.com/group/RT-UML

http://www.ibm.com/software/rational

http://www.ibm.com/software/rational

IBM Software Group | Rational software

Innovation for a smarter planet

Forget 7+/- 2

2

"The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information“

by George A. Miller

Psychological Review1956

Rule: All diagrams should contain 7 elements +/- 2

10



Forget 7+/- 2

3

10BUT: you don’t have to rely

on short term memory

The diagram is front of you!


Innovation for a smarter planet 4

Forget 7 +/- 2 – Use Mission statements instead 10



All models are abstractions but some are useful

5

Engineer- tensile strength- support strength

- stability

QA- mapping

properties to standards

Seller- cost- color

Manufacturer- parts list- materials- assembly

User- comfort

- adjustability- mobility

Office Designer- color- style

- feng shui

Models support deep

reasoning

Models answer

questions

9

Every model should have a purpose and scope

Models succeed to the extent that they

allow us to reason about

the world



Trade studyModel

Trade studyModel

Trade studyModel

Models are abstractions … but can be connected (Systems)

Functional

Model

Executable use casesFunctional and

QoS requirements

DependabilityModel

Safety, reliability,

and security analysisFTA, FMEA, FEMCA,Asset Diagram, SAD

ControlModel

Control algorithms,mathematical models

ArchitecturalModel

Subsystems, interfaces, Subsystem use cases/

Requirements

Model-based

handoff

SubsystemModel(s)

Mechanical Specification

ElectronicSpecification

SoftwareSpecification Model and text

Model and text

Model and text

6

HeatPower

WeightStability

9Parametric models



Napkins models are almost completely useless.

7

Modelvalue

Completeness

Accuracy

Precision

8



Napkins models are good way to start a conversation 8

But a terrible way to end one



Requirements Models Avoid Early Defects 7

Why do we care so much about getting

requirements correct?

$30

$10K

$1M



Systems Use Case Requirements Model



ABS Braking Use Case Context Bock Diagram



Normal Braking UC Block State Machine



Normal Braking Sequence Diagram



Model-Based Handoffs Preserve Fidelity

14

Systems Engineering Model

Downstream Engineering Model

6



Handoff Workflow

15

Hand off elements common to

multiple subsystems to the

shared model

Hand off specification elements to individual

subsystems

Allocate requirements to

engineering disciplines

6



Only 3 (+1) Diagram Types are Required

16

3(+1) Required diagrams

5

UML is complex!

Are all you need



High-Fidelity Key Modeling Views

Class (“Block”) Diagram

State Diagram

Flow Diagram

Sequence Diagram

5



Design Patterns Reuse Proven Solutions

18

Optimize some properties at the

expense of others

Are generalized solutions to

common problems

Can be applied at multiple levels of

design

Allow us to leverage other’s

design experience

4



Connect Work Products with Traceability Links

We create many different work products Safety analysis, Requirements, Architecture, Design, Source Code, Test suites, …

But they all need to tell the same story (from their own perspective and needs) You must be able to show

Consistency Completeness

3



Traceability Traceability serves a number of purposes

It allows impact analysis – what is the impact if I change this element? It allows for coverage analysis – are all elements realized It allows for consistency analysis – are these different elements in different work products

consistent and compatible with each other?

20

Design / Implementation Elements

D1 D2 D3 D4 D5

Requirement

s

R1 x x

R2

R3 x

R4 x

Gold plating?

Unimplementedrequirement

3



It is better to avoid defects than to fix defects

21

Planned FOC

Time to IOC “Product Stabilization”

Not ReadyTests failWrong product

The Reality

The Plan2




22

Nanocycle

hour

SE Modeling

Continuous Verification

Iteration

month

Iterative Specification

Architecting

Trade Studies

Verification

Customer Validation

Project

Year

Project Management

practices

Quality Assurance Practices

Customer Liaison

Practices

Safety, Reliability & Security Practices

2




[more requirements]

[else]

Nanocycle

hour

SE Modeling

Continuous Verification

Build the work product in nanocycles with continuous verification

2



The ONLY WAY to ensure Quality is Continuous Verification

24

Requirements don’t specify the design or means by which the transformations are accomplished

Requirements are correct IFF they correctly represent the inputoutput control and data

transformations and their performance properties

1



The ONLY WAY to ensure Quality is Continuous Verification

25

Requirements don’t specify the design or means by which the transformations are accomplished

Requirements are correct IFF they correctly represent the inputoutput control and data

transformations and their performance properties

1

We want to ensure the requirements are correct before designers, implementers

and testers use them so that we can avoid rework and the high cost of defects

How can we do that????



The ONLY WAY to ensure Quality is Continuous Test

High-fidelity models can be verified with testing AND formal analysis

1



References

Bruce’s Modeling Hints The Secrets to Effective Modeling for Systems Engineers

Documents

Transcript of Bruce’s Modeling Hints The Secrets to Effective Modeling for Systems Engineers