Model Based Project Management - Intrinsyx

MODEL BASED PROJECT MANAGEMENTApplying the Systems Modeling Language to Project Management

Theodore KahnIntrinsyx Technologies CorporationNASA Ames Research CenterMoffett Field, CAwww.intrinsyx.com

[email protected]@gmail.com

An Engineering and Information Technologies Company

NASA/Army Systems and Software Engineering ForumMay 12 & 13, 2009

Marshall space Flight Center

Problem statement

Project and system information is now document centric:Relies on textual, tabular, and graphic documents from a

variety of sources which means… interpretation of the information is difficult and consistency

hard to maintain, especially under changing conditions.

Model centric approach relies far less on documents:Depends instead on a single repository for storing project

structural and behavioral information…Promotes a more common interpretation and consistency of

project information, even under very dynamic conditions.

www.intrinsyx.com www.intrinsyx.com

Presentation objectives

Provide a conceptual understanding of modeling as it might be applied to project management and system engineering.

Enable you to make informed decisions regarding its applicability to your situation.

The talk does not address implementation issues or methodology, though those would be interesting areas for the discussion at the end.

www.intrinsyx.com

Some basic SysML semantics

Theoretical aspects of modeling

Demonstration of a SysML tool and models

Q & A, and discussion

Presentation overview

www.intrinsyx.com

www.intrinsyx.com

DEA Tool Functional Use Cases

DEA T oo l

*::,----+-------(--;~;;;.; .. ;;";~~":";.:.:.:.;.: "-.. "'"'

U.er

Admmistrotor

Creote, update ond delete I!E.O.'.

«.>:tend» .... ~~------_ Chonge L~e<y<le .".

Eleelr onic Signatur e

Import DEA'.

<<r.I ..... » ,!. « lcr.cI~.""""emert»

Mointain U.er A«ount.

" "9 .1" Text = "Tne too l snail proviOe foc ilili es for "ealin g, upaaling ana ae leling use r a"ounls."

List ond Print I!E.O.'.

,

, ,

, ,

« r. I ..... » ~

I « lcr.cI~.""""emert»

Dotobo.e Monogement

" "9 .2" Text = "Tne too l snail pro"oe foc ilili es for mainlaining Ihe aalabase; for example, upaaling . numerali on li sls 10 refi eci

,

, hanging business requiremenls."

< <lcr.cI~equt«T'l<ft> > Query DEA Dotobo.e

" "2 .1.1" Te><l = "Th e 1001 shall proviae

<r. l ..... >~ users Ihe ab ili~ 10 query Ihe aalabose subiecllo app rop riale pe rm iss ions."

< <1<Td~.,,"""«T'I<ft> > Creole, Update, Delete DEA'.

:, " "2 .1 .2" Te><l = "Th e 1001 sholl proviae users Ihe ab ili~ IO "eale, upaale ona ae lele DEA's."

« r. l ..... » < <lcr.cI~.,,"""«T'I<ft> >

DEA L~e<y<le

" "2 .1 .3" Te><l = "Th e 1001 shall suppo rt a fo rm al wo rl<:tl ow lifec1c le process os pa rt oflh e upaalelchange

« r. l ..... » fealures ."

< <1<Td~.,,"""«T'I<ft> > DEA Electronic Signatur e

" "2 .1 ("

» Te><l = "Th e 1001 shall proviae on eleclronic signalur • . " -

< <1<Td~.,,"""«T'I<ft> > Print DEA

, " "2 .3" « r. l ..... » e><l = "Th e 1001 shall be ab le 10

prlnl a DEA in RTF form at "

< <lcr.cI~.,,"""«T'I<ft> > List. ofDEA'.

" "2.5" Te><l = "Th e 1001 shall OUIPUI DEA's in an Exce l co mpalab le form at "

« lcr.cI~.""""eme<t» , Import DEA

" 10 ":> .7 Te><l = "Th e 1001 shall proviae Ihe . b ilili~ 10 balch impo rt DEA's fro m Exce l ana co mma Separalea .a lue form alea fil es ."

Conclusion

Why you don’t want to model Modeling is hard Modeling tools are difficult Modeling will likely require cultural changes

Why you do want to model It increases the rate of communications It increases the precision of communications It reduces tacit information It promotes a common understanding of your project

Benefit: Stakeholders having a common understanding of how the project is organized and its objectives will work together more effectively and make better decisions.

www.intrinsyx.com

SysML and project management

Modeling in the context of SysML

SysML structure and semantics

Conclusion

Theoretical aspects of modeling

www.intrinsyx.com

While project management and systems engineering share many of the same qualities, there are important differences.

Relationship between project management and systems engineering

www.intrinsyx.com

Similarities between PM & SE

Lots of behaviors having complex relationships

Lots of entities having complex relationships

Many relationships and dependences between behaviors and entities.

www.intrinsyx.com

Systems engineering

Systems engineering is a multidisciplinary approach for developing balanced systems solutions in response to diverse stakeholder needs.

It includes the application of both management and technical processes to achieve balance and mitigate project risk.

The management process is applied to ensure that development cost, schedule and technical performance objectives are met.

Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.

www.intrinsyx.com

Differences between PM & SE

Attribute Project Management Systems Engineering

Scheduling Absolute times Relative times

Economic cost Mandatory/aggregation centric Optional/unit centric

People Individuals and roles Role centric

Entities and behaviors

Notional Precise

www.intrinsyx.com

Project Management Models

Temporal Models

Behavioral Models

Structural Models

Gantt, PERTCharts

SysML

Informs Informs

www.intrinsyx.com

Being a successful PM or SE means:

Understanding the project/system information and how it fits together.

Communicating and otherwise making this information available to stakeholders in a timely, consistent fashion in a form relevant to their backgrounds and needs.

www.intrinsyx.com




Summary

Part II, SysML

www.intrinsyx.com

SysML modeling is about communications

It’s a language having syntax and structure… that uses a medium, primarily graphics… and has a methodology, which currently is largely

undefined.

www.intrinsyx.com

Three main attributes of languages

Abstractions of the world around us Some form of persistence A shared experience: a producer and a consumer

www.intrinsyx.com

Three main attributes of SysML

Abstractions of systems Database persistence A shared experience

www.intrinsyx.com

Model, model on the wall…

An electrical schematic of a radio An economic model A model student A non working model airplane A novel about present day life the author believes

to be possible A description of a pencil

who’s the truest of us all:

www.intrinsyx.com

SysML and other modeling constructs

Enterprise architectures

SysML

Domain specific languages

DoDAF, MoDAF, UPDM, FEA

SysML

UML, Modelica, Simulink, MARTE

Concepts ExamplesAbstraction

More

Less

www.intrinsyx.com

Abstraction levels

La Joconde Femme au Chapeau Orné

www.intrinsyx.com

Two criticisms of SysML...

Its old ideas warmed over – Abstractions and persistence have been around at least since humans drew pictures on cave walls. There is nothing new here.

Its simply not practical – Having my team think abstractly in the same way and put their information into a database in the same fashion is absurd. It is not workable.

www.intrinsyx.com

A historical perspective

www.intrinsyx.com

-




Summary

Part II, SysML

www.intrinsyx.com

SysML Diagram Taxonomy

Source: OMG Specification

www.intrinsyx.com

-SySML

Diagram

fJ.

I---"---~ B&h~vtor , R~ qu l r~m~nt SiT!lcrure D/agnm I lO' gra D/agram

I

I ~ £ ~

I I I I I I k~fl\ll Y ~BljUenea Sb~e MaGh11lB UBB C:as~ BIDet; lOellnlflon amal Blo~~ Pac ksge Diagram Diagram Diagram agram Dlalll'am Diagram DlslII'am

l~

I Same a~ .---- ----I Parama c

D • B am lod"ied f · L2

D w diBgra ~ e

Model elements

Models consist of elements

Elements must have unique names, within a namespace

All model elements must reside in (be owned by) one package

www.intrinsyx.com

Major types of model elements

Structural Behavioral

www.intrinsyx.com

Packages

Models are composed of one or more packages

Packages can contain other packages and/or any collection of model elements

Package hierarchies define the name space

www.intrinsyx.com

Packages shown as a containment tree


www.intrinsyx.com

- B"·~ ACME Surveillance Systems Inc

1il···FLl Components

p···n Products

~·n Cameras

: $ ·n Behavior

: ~···n Parametrics $ ... L:J Camera Performance

EJ .. ·n Power Analysis

EJ···n Structure

$···n Requirements B···n Surveillance Systems

$···n Logical

f·····n Physical EJ···L::::J Use Cases

~···D Protiles ~ ... !kJ Standard Definitions

$ ... L:J Basic Constraints

$ ... L:J Basic Definitions

$ .. !kJ SI Types

EJ···E:J Standard Item Defin itions

FIGURE 5.4

Browser view of the model's package hierarchy.

Packages shown graphically


www.intrinsyx.com

-pkg [Package] Products [Nested packageS])

Surveillance Systems I

I

Use Cases

I I

Physical Logical

FIGURE 5.1

An example package diagram.

I I

Cameras Requirements

I I I

Behavior Parametrics Structure

Dependences and stereotypes


www.intrinsyx.com

-pkg [View] Camera Performance [Some Dependencies] )

" block» " requirement» Camera Video Performance

11\ 11\ 1 1 1 1 1 1

" allocate» : : " refine» 1 1 1 1

: : " activity» __ (~r~~e~ _ ) '---___ "_co_ns_t_ra_i_nt_» __ -----'- _(~~~.»_ J<-___ " v_a_I_Ue_T_y_p_e_» __ -----'

Generate Video Outputs _ Video Stream Rate 1 Mbps

FIGURE 5.10

Example of dependencies in the camera performance view.

Blocks

Blocks represent structural elements Organizations Data People Airplanes

Blocks have two main attributes Properties, other structural elements Behavior, either as an intrinsic capability or through

behavioral elements

www.intrinsyx.com

Block property types

Parts (in UML, composition)

References (in UML, aggregation)

Associations

www.intrinsyx.com

Block definition diagram—Part


The black diamond is used for communicating a Part Property relationship

www.intrinsyx.com

Block definition diagram—Association

No adornment is used for communicating an Association Property relationship


www.intrinsyx.com

Block definition diagram—Reference

The white diamond is used for communicating a Reference Property relationship


www.intrinsyx.com

Block compartments


www.intrinsyx.com

-bdd [Package] Automobile Example)

Wheel

values pressure: pSI size: mm

FIGURE 6.4

Automobile

parts left front: Wheel right front: Wheel left rear: Wheel right rear: Wheel

values weight: kg vehicle reg: String

An automobile with four wheels described as separate parts.

Blocks and inheritance

Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.www.intrinsyx.com

-Camera

parts : Protective Housing

rna : Mount Assembly : Camera Module : Electronics Assembly

values dimensions : Size power : W field of view: 0

orientation: 0

flow ports in light in : Light camera I/O : Camera Interface

standard ports control : ICameraSignals

! \ Wired Camera Wireless Camera

parts parts : Transformer : Ba"ery : Ethemet Card : WiFi Card

flow POrfS values in mains input : AC battery life : 5

flow ports in charger input: DC

FIGURE 6.35

Example of block specialization.

Activity Diagrams

www.intrinsyx.com

-Define Join Decision Merge Fork Join

Recipient [Book or Music] .. Buy Online Wrap Present J 'I , .. , I'

Think of .. .. .. .. , .. Present Present , , , .. , , .. ,

[Olher] .J Buyfrom Store , Wr~e Gift Card J ' \

Get Money

Sample activity diagram 2


www.intrinsyx.com

-act Generate Video Outputs [Routing FlOWS])

a1 :Produce Test Signal Vide~ a3:Encode MPEG h MPEG output : MPEG4

rfl I--' MPEG out {stream}

input signal : Video

-*- test signal

,rl a2:Process Frame h {stream} raw' '-I I-'

frames processed frames

.~ a4:Convertto Composite ~ composite out : Composite

{stream} VI eo In

composite out

FIGURE 8.1

An example activity diagram.

www.intrinsyx.com

The ........ .ctiYty io <:<>n<UcIed

~ _IhoJlVo. --.ysa ... ----D .. s-,..o:em.U..,.. " --~ " Oo<_C~' ''' '" <-- '"

____ I

_dICC") •

/

/ /

~ /

--1--.~ I / "'ne ..... _ /

/ /

/

C ••• e 00< CM .. _ 19~·-· J Pf Dtoc'"

.-•• • 1 Oo<ument fo< _e ... ing (T-" f..-_ ..... on I "'_ ...... u. ,-

(Pr~e .~ed) .-""e ..... w

completel

( Step-Open I ~ r ..... _1fk.1on ... ~.Ion

$1 .... _ ... , ) l, •• h"I .. , M.,..iI •

St~ionJ lhio_io " ~~ S!:---'-- .. ~ - ---

1 III t_~ -

~ l'''--..c_ g~~ ~ Email --_ I .- .- __ document

~\ ~ ~ ,-, , Email ""'i'", __ shown _e _e lhel:'l -.urn. I, ,act , "".,..s __ .ty

be ...- oech 1m. lhe issue io ....,cIItIed '" Is stlllUs chroges

Requirement diagram—Purpose

Fully and unambiguously specify what the model is to do (functional requirements) and the context in which it is to operate (non-functional requirements).

Provide concise and unambiguous information showing how requirements relate to each other.

Provide concise and unambiguous information showing how requirements relate to other model elements—the project lifecycle.

www.intrinsyx.com

Requirements diagram—Example

Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.www.intrinsyx.com

-

id = 3.2.1

«requirement» Passenger and Baggage Load

«requirement» Maximum Acceleration

«requirement» Vehicle Performance

text = The vehicle shall accelerate from 0 to 60 mph i .

«requirement» T op Speed

«requirement» Braking Distance

"requirement» Turn ing Radius

«requirement» Automobile

«requirement» Riding Comfort

id = 3.3

«requirement» Space

«requirement» Vibration

«requirement" Noise

«requirement>· Fuel Efficiency

text = The vehicle shall achieve alleast ?5 miles peL

«requirement» Emissions

"requirement» Vehicle Prod uction

Cost

"requirement» Vehicle Reliability

«requirement» Occupant Safety

Requirements dependences

«refine» «satisfy» «deriveReqt» «copy» «verify» «trace»

www.intrinsyx.com

Refine, satisfy & dervieReqt

Source: OMG Specificationwww.intrinsyx.com

- req MasterCylinderSafety)

Decelerat.e Car

~<rationa le,) c:,

«block» / , body = "This design of the brake 8rakeSysfem

/ / assembly satisfies the feder safely

~:' <<refine» requirements.· t: frootBrake

«(requiremenb> I r: Rear Brake I Master Cylinder Efficaoy I 11: BrakeLine

I l2: BrakeLine I - ---Text =" A master cyt1nder shall have a reservoir / « satisfy»----- m: MasterCylinder compartment fOf each service brake 4f.-------~--subsystem serviced by tile master cylinder. aciivateBrake() Loss of uid from one con1lartment releaseBrake() shall not result in a oornp!ete loss of brake fluid from another compartment." ID = <S5.4.1"

1/ ,----:-- I:::l « deriveReqt» « deriveReq » «rationale.)

, ----- body = "The best;"ac ·ce

(requirement» solution consists in assigning

«requiremenb> one reservoir per brakeline," LossOffluid Reservoir

-./ Text =aPrevent complefe loss of fluid" Text = "Separate reservoir compartmene --10 = ·S5.4. 1a" ID = <S5.4.1b"

SatisfiedBy D

I BrakeSystem :11 r---- .. -- r:, BrakeSystem :12

---- « rationa le)~

I::::. body = "The best-practice

SatisfiedBy solution consists in using a set of BrakeSystem::m springs and pistons to confine the

~s to a single compartmenr

Figure 16.4 - Links between requirements and design

Copy


www.intrinsyx.com

-reQi Safely RPuse)

(aequ:remeni> «Ie<! i "~",,,mb> )brid Engi A !)pe H",r id Er1gin~ 8 !)pe

'f' 'f' I I I I

{( l'iE'qUlireme.J1b) ~, requi meni» «requirement» « require,:,en.) Safe:y Requireme is Shared Safe~1 Sh a,e-d Safely Safetry 75-

for ~iPe A Requirements Requirements fur riPe 8 I m aster- ASaEt:,R ma.s:er-.NI-ITSAS3fe~ elluirements E<l'Ilirement -- ,/ ,

" ,

<<COp>,,' <<COP>'" -, --- -.~-

«requirement» I-ITSfSafe,;?" , _ -""" is

Te:.t = " __ -" lID = "1!)7_1l5"

Figure 16.6 - Use of the copy dependency to faci litate muse

Verify


www.intrinsyx.com

-req [Package] Testing [verification example])

«requirement» All Weather Operation

verified8y <<interaction» Water Spray Test cE----------

«verify»

«testCase» Water Spray Test

verdict: VerdictKind

verifies «requirement» All Weather Operation

Trace


www.intrinsyx.com

-req [Package] Customer Specification [trace eXample])

« requirement» Operating Environment

id = "S1" text = "The system shall be capable of detecting intruders 24 hours per day, 7 days per week, under all weather conditions,"

--------3; « trace»

«document» Market Survey

Use case scope

www.intrinsyx.com

-Use Case Scope

High Level Business Objectives

• c .5"0 .,.,....

.-..,.-Iywhat imagine what,IOOw ·C

U5I!r.Ii will want 1D 1heyneed 1D do 1D

0 dolO get1hei ... "",--Q) Developer done_day User III I

)

co Community Community U -. • Q) III

=> qJm

manages de5uibe 10.-.,.,...._ -. "'" _ ,.;11 be

impiemenBI "'"

Implementation Details

Use cases and actors

Actors are external entities that interact with your system via use cases

Actors can be people, computer systems or really any device that interacts with your system.

It is high recommended that Actors be modeled before use cases.

www.intrinsyx.com

Actors for a household model

www.intrinsyx.com

-uc [Model] Household [ ~ Members of Household ]

Householrlllllembe,.

Use cases for household food processes

www.intrinsyx.com

-uc (Modell Household [ ~ Household I

Hou6 'd ...!:I-:. Nlember

Prepare Breakfast or

Lunch

« subsystem» Food Processes

Pn~pan~

Meal

\ \ « include»

\

\

\

~---+-------..,,-'---------Prepare

\<include» \

Dinner

Optional par1icipation « extend»

I

I

hild

,-« extend»

'-'-

~QDinn~ \

\

\

Clean Up After Meal

~ Household Nlember




Summary

Part II, SysML

www.intrinsyx.com

Key SysML features & capabilities

Open standard

Works equally well with structural and behavioral artifacts

Treats requirements as first-class modeling elements

Future plans include simulations

Formal mechanism for extending SysML semantics

Formal set of semantically consistent graphical elements.

www.intrinsyx.com


www.intrinsyx.com

1. Structure

"

SysML requirements relationships

www.intrinsyx.com

-Any behavioral diagram.

\ \

« activ~y»

..... .....

'-____ ... 1-- .....

SysML Requirements Dependency Relationships

..... ...-..... « refine» ....

...-...-.... ...-.... ....

« Test Case»

"-«allocate» ..........

<: Use Cas e

- I « refine» I

..v « requirement»

Id = " II Text = It II

I «satisty» 1

I

~ « block»

~

[!]

t- -

Ext.ernal Information

Any ent~~y executing the act iv~y: person, org, machine, software, etc.

Conclusion

Why you don’t want to model Modeling is hard Modeling tools are difficult Modeling will likely require cultural changes

Why you do want to model It increases the rate of communications It increases the precision of communications It reduces tacit information It promotes a common understanding of your project

Benefit: Stakeholders having a common understanding of how the project is organized and its objectives will work together more effectively and make better decisions.

www.intrinsyx.com

An ad hoc initial attempt at modeling the NASA Constellation program, manned moon/Mars mission.

The notions and ideas expressed in these slides represent my own interpretations and have not been vetted or sanctioned by NASA in any way. They are presented solely for educational purposes regarding how large engineering projects might be rendered in a SysML model.

Demonstration

www.intrinsyx.com

Model Organization

www.intrinsyx.com

-« use» /

/

/ I v.

CxOrg Model

'\

/

'\ '\

« use» '\

/

'\

I CxProgram

/

I « use»

I

/ I w v.

« profile»

CxPProfile

'\ « use»

"

/

/

I CxData Model

/

/

/ « use»

/

www.intrinsyx.com

Constellation Program Model Table of Contents

[structural Artifacts 1 Organization Information Data Taxonomy Information Systems

NASA Organization High Level Structure Tools

Constellat ion Organization Ope rational Data Tool Crg and Functions

SE&I

PP&c

[s ehaViorial Artifacts 1 Virtual Missions and Operations

GMIP Category Temporal Decomposition GMIP

EVA HIW Processing & Crew Tra ining GMIP Category Information Decomposition

Integrated Vehic le Engineering Analysis :

Design Category Decomposition MPPF

Offl ine Processing

eM/SM Stack Integration

VAB Integrated Operations

Generic Mission Template

www.intrinsyx.com

- , TV.

c ,-cO<Ec=.:-" I CX~~

[} ____________________________________________ ~~~{] ~G At~w

IWiP BI\. 0Ua '-' ______ --;j::l G:a:ERQHa PKI. I P.Kt.~

~ B"" ItakU" m """ ""8.\.

! ~ l (

CD ....

e}-- ->[J ......

Integrated Vehicle Engineering Analysis

www.intrinsyx.com

-act [Activny[ Integrated Vehicle Engineering Analysis: [ ~ Integrated Vehicle Engineering Analysis: 0

Loads & : Fin"elMath Model Inputs ,,- Dynamics

h -~ Integraned r Analysis

I : CxMRD

Aero Thermal : Aero Thermal Inputs ,,- Integraned h

-~ Analysis 0-'

J : Integrated Vehicle Engineering

I I : ICD BIL -I Analysis Completion

EMCiRf

: EMCIRF Data Inputs " Integraned h

.~ Analysis 0-'

I : Trajectory Design

I Dana Pack (TDDP)-1 ECLSS

: ECLSS Data Inputs " Integraned h -~ Analysis r

~ Durat ion for these concurrent activ"ies is L-21 0 days to L-1 20 days - ~

Constellation Data Taxonomy

www.intrinsyx.com

-Constellation Data Taxonomy

« ex Data» Root

~ fr-

« cxData» « ex Data» « cxData» - Document ~ Model ~ Proce. Record

« cxData» « cxData»

- Requirement Document - Dota Exchange Agreement

« cxData » « ex Data »

dataType = "documenf' dataType = "processRecord"

« cxData» «cxData»

- Procedure - Change Request

« cxData » « ex Data »

dataType = "documenf' dataType = "processRecord"

Relationship between UML and SysML


-UMla

, UML f not re(luired .,; by SysML

(UML -UML4SyslMl) ,

• . m

UML reused by

SysML (UML4SysML)

SysML extensiiions to

UML {SysIML ProD e

UML/SysML metamodel


-M3 (MOF) ~ ~ j \ ",

cinstanceOfxt / «ins hnCeOf.~~""'~ ...... cinstanceOfx. .. \ ~

M2 (W.L)

Ml (User model

,

I V ideo

) ':title: String rE

I / I ! I~' / I , ,,/ ' /'

i ,/ j I ,---------'-------,

snapshot~/ ---"-

r.t"'iitl '--,e-=-;;""'20"'O:-:-1-: A:-;:S,--pa- oe----,O"""d7""yss- e"""'y":-i

\~. "~, «Instanceot»

MO (Rull-time instances) aVideo

Figure 7.8 - An example of the four-layer metamodel hierarchy

Copyright Information

OMG Source material is reprinted with permission. Object Management Group, Inc. (C) OMG. 1997 - 2006.

www.intrinsyx.com

Model Based Project Management - Intrinsyx

Documents