Model Based Project Management - Intrinsyx
Transcript of 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
SysML and project management
Modeling in the context of SysML
SysML structure and semantics
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
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
SysML and project management
Modeling in the context of SysML
SysML structure and semantics
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
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
Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.
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
Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.
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
Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.
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
Source: OMG Specification
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
Source: OMG Specification
www.intrinsyx.com
Block definition diagram—Reference
The white diamond is used for communicating a Reference Property relationship
Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.
www.intrinsyx.com
Block compartments
Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.
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
Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.
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
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
Source: OMG Specification
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
Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.
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
Source: A Practical Guide to SysML., copyright © 2008 by Elsevier, Inc. All rights reserved.
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
SysML and project management
Modeling in the context of SysML
SysML structure and semantics
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
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
Source: OMG Specificationwww.intrinsyx.com
-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
Source: OMG Specificationwww.intrinsyx.com
-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