®
IBM Software Group
Advanced Systems Engineering
and Model Philosophy
Barclay Brown, ESEP
Global Solution Executive
IBM Rational
barclayb@us.ibm.com
Innovation for a smarter planet
© 2013 IBM Corporation
Software and Systems Engineering | Rational
Systems Engineering Addresses Broad Concerns
…
Aeronautical Engineering
Civil Engineering
Software Engineering
2
Mechanical Engineering
 What concerns are
independent of the
specific engineering
disciplines?
Systems
Engineering
Electrical Engineering
 What concerns fall
squarely into a
specific engineering
discipline?
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Systems Engineering has both a breadth and depth perspective.
3
Requirements engineering, configuration
management…
Depth Perspective
Systems Engineering
Systems Engineering
Breadth Perspective
Cross-discipline analysis, system-of-systems modeling…
System
SubSystem
Electrical
Component
SubSystem
Software
Component
SubSystem
Mechanical
Component
Software
Component
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Systems Engineering has both a breadth and depth perspective.
4
Requirements engineering, configuration
management…
Depth Perspective
Systems Engineering
Systems Engineering
Breadth Perspective
Cross-discipline analysis, system-of-systems modeling…
System
SubSystem
SubSystem
Systems Engineering also
names a set of methods,
skills and techniques that
can be applied both at a
Electrical
Software
system-of-systems level
Component
Component
and within specific
engineering disciplines.
Systems Engineering is a
profession, a role, even
a job title, for those who
work
exclusively at a
SubSystem
system-of-systems level.
Mechanical
Component
Software
Component
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Value of Systems Engineering: Cost and Schedule
Applying the right amount of systems engineering is critical to meeting cost and
schedule targets.
Source: Honour, Eric (2010), Systems Engineering Return on Investment, University of South Australia, p9
5
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Value of Systems Engineering: Success and Quality
Applying the right amount of systems engineering is critical to program success.
Source: Honour, Eric (2010), Systems Engineering Return on Investment, University of South Australia, p9
6
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Today’s reality: for integrated device and
software of systems development
66%
Device software designs completed
over budget
EMF 2003
24%
Projects canceled due to
unrecoverable slip in schedule
33%
XX%
2x
7
Produced devices do not meet
performance or functionality
requirements
Software content in devices is
doubling every two years
EMF 2003
EMF 2003
IDC 2002
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Many notable system failures have been failures in subsystem
interfaces, requirements fidelity and system engineering.
 Systems have become more complex through integration
–E.g. automobiles with multiple ECUs are more like a network of
general purpose computers with large network software
 Projects with 700-2000 requirements cannot be held in mind
at full detail
–Models with varied levels of abstraction must be used
 Managing change and understanding impact of change is a
$$$ million problem
–Requirements models and automated tools must be used to be
effective
Interestingly, these are failures of knowledge
and communication, not of engineering.
8
© 2011 IBM Corporation
Software and Systems Engineering | Rational
What do each of these have to teach us
about Advanced Systems Engineering?
Social
Media
9
© 2011 IBM Corporation
Software and Systems Engineering | Rational
The Philosophy of Advanced Systems Engineering
 Models are better than documents (but documents are needed too)
 Collaborate and share information across functions
 Seamless flow of information and action
 Build Shared Understanding as hedge against risks
 Automate as much as possible
 Insurance: Invest a little now to avoid large risk later
 Optimize for change (not for stability)
 Be able to trace everything, but only trace what adds value
 ABC: Adopt before Buy, Buy before Create
 Measure and improve; closed-loop governance
 Start early: what can we do NOW?
10
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Advanced Requirements
Management
Traceability
Safety-Critical
Regulatory / Industry
Data
Interface
Service Specifications
Business Processes
Functional
Use Cases / CONOPS
System / Subsystem
Requirements
 Implement “live” traceability
between all kinds of
requirements, including
architecture and design
 Link requirements to design,
implementation, verification
and validation, user training,
etc.
Business / Mission
Requirements
Non-Functional
 Recognize levels and types
and their relationships
Derivation
 Requirements are no longer
“one kind of thing”
Source / Given
Requirements
© 2011 IBM Corporation 11
Software and Systems Engineering | Rational
The changing role of
requirements
 Text requirements give rise to
models which elaborate and
elucidate
 Models give rise to additional text
requirements which specify and
constrain
 Text and models are useful at all
levels of system abstraction
Enterprise
System-of-Systems
System
Text
Subsystem
Component
Models
 Capture rationale and thinking at
each level to differentiate
requirements from design choices
12
© 2011 IBM Corporation
Software and Systems Engineering | Rational
One more jab at the waterfall process
 Extremely optimistic
 Assumes no “disruptive
learning”
 More realistic is a growing body
of information
 Track maturity and confidence
of information
– Requirements
– Models
– Designs
– Changes
– Performance Measures
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Building a house: A parable of requirements
 Builder asks homeowner
– How many square feet?
 Is this the best time to define this requirement?
 Define “incomplete” requirements
 Use ranges
– 1500-2200 sq. ft.
 Each bit of information has a maturity process
– Drafted
– Reviewed
– Confirmed
– Signed
 Move away from requirements as a single body
of information
© 2011 IBM Corporation
Software and Systems Engineering | Rational
A little background philosophy…
 “We picture facts to ourselves.
 A picture presents a situation in logical space, the existence and non-existence of states of
affairs.
 A picture is a model of reality. In a picture, the elements of the picture are the
representatives of objects.
 A logical picture of facts is a thought.
 A state of affairs is thinkable’: what this means is that we can picture it to ourselves.
 The totality of true thoughts is a picture of the world.”
…who said this and when?
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Source: Wikipedia
(http://en.wikipedia.org/wiki/Ludwig_Wittgenstein)
Source: amazon.com
(http://www.amazon.com/gp/product/1440424217/ref=s9_simh_gw_p14_d0_i2?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center2&pf_rd_r=1TD6G6SJM3E9TFFE1ZDA&pf_rd_t=101&pf_rd_p=470938631&pf_rd_i=507846)
(1921)
© 2011 IBM Corporation
Software and Systems Engineering | Rational
What makes a model a model?
The Dumb Way
The Smart(er) Way
=-A11*4*(1-B11)+4*C11
=100+3*50+2*3*70+3*3*40+4*3*100+5*
3*125
 The relationships are baked-in
 Optimized for change
17
=NORMDIST(A11,0,
1,FALSE)
Smarter or Dumber?
Requirements
Trade Studies
Flowdown / Allocation
Designs
Component Specifications
TPMs
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Model Philosophy I: What are models for?
 Models can
–Document. Derived from already existing reality or agreement.
–Represent. Help people communicate and agree.
–Hold thought. Be a shared mental space for collaborative thinking.
–Illustrate. A picture is worth a thousand words.
–Calculate. Both show and quantify relationships.
–Evaluate. Show alternatives and criteria for trade-off analysis.
–Build. Translate models into real things.
 It is important to be clear on the purpose for a model you are
creating (and maintaining.)
18
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Model Philosophy II: Model relationships
 Models and model elements have relationships with other model elements and with other
information relevant to the system.
 Important relationships
– Derivation
– Fulfillment (coverage)
– Decomposition
– Dependency
 For instance,
– A model element may fulfill (fully or partially) a requirement.
– A requirement may be derived from another requirement.
– A requirement may arise from a model element.
– A model element may decompose into another model element.
– A model element, or requirement, may depend on another model element.
 It is important to figure out how your model elements and requirements relate to
each
other.
19
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Model Philosophy III: Dangers in Adopting Modeling
 All models are good. Causes model proliferation
without meaning and purpose.
 Method-centric. We do these models because the
method says so.
 Tool-centric. We do these models because the tool is
good at it.
 Dead models. Non-executable models risk being unimplementable.
 Doing documentation models exclusively. Limits
benefits of modeling (where are the real models?)
M.C. Escher, 1961
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Model-driven system development models a system-ofsystems in four recursive stages.
 Context describes the system and the people
and systems who interact with it (actors).
Context
 Usage describes how the actors use the
system is used to produce the results and
purposes of the system.
Usage
 Realization describes how each usage is
accomplished by a collaboration of system
elements using various viewpoints.
Realization
 Execution enables demonstration and proof of
the model through execution.
and Joint Realization
Execution
21
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Modeling context allows, even forces reasoning about system
boundaries high-level interactions.
 To understand systems, understand the context of the
broader Enterprise
 Context Diagram treats Enterprise as a black box
 Shows scope, boundaries, operations, i/o entities
 Ultimately add operations when they are
discovered through flowdown
 Add actors and i/o entities
 Shows only one level of abstraction (e.g. Enterprise)
22
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Modeling usage as the foundation for architecture ensures that all design
serves the system’s intended purposes.

Use case: a sequence of events that yields a
meaningful result of value.

Enterprise Use Case diagram
– “System” is the Enterprise
– Actors same as on context diagram
– Identify use cases:
What do they use the system for?

Detailed in a Use Case Specification

Remember to treat Enterprise as a black box;
no implementation details

Focus on actor’s interactions with the
Enterprise

No actor-to-actor interactions at this level:
these are shown in the collaborations from the
level above
23
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Example: GPS-Guided Travel
 GPS Features
–Set destination (address,
point of interest, etc.)
–Navigate to destination
–Retrace route
–Get back on track
 GPS Usage Model
–Find me a gas station on my way
–What’s the nearest McDonald’s?
–Is there a Hilton Hotel I can reach in about 5 hours?
24
–Let’s avoid freeways
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Modeling realization connects behavior to architectural structure,
integrating process with architecture.
 Model enterprise as a set of operations
that realize use case flows
 Highest Level “specification” of the
enterprise
 Treat enterprise as black box
 Provides basis for flow down
 Identifies common logical capabilities
needed across use cases
 “Black box sequence diagram” of an
Enterprise Use Case allows identification
of candidate Enterprise Operations.
 Name the messages as requests of the
message destination NOT as the action
taken by the initiator
25
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Data Flow and Activity Flow
 Object flow in activity diagrams
ties usage flow to data flow
 Publish and subscribe patterns
(e.g. DDS) are easily modeled as
steps or flows within usage
 Establishes responsibility for
functionality and data together
 Ties functional models to
structural (schema) data models
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Data Flow in Realization
 Main focus is on system usage
– That’s why systems are built
1: Complete Online Sale (TransID, CustNum, TotalPurch)
 Data modeling in MBSE ensures
that only data needed for usage
is built
Retail System
TransID
CustNum
TotalPurch
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Modeling joint realization allows us to show the relationship between
physical/distribution architecture and logical architecture.
 Allows reasoning about physical distribution of
system elements and functionality
 A locality is a place where some system
functionality happens
– E.g. software hosted on a particular server, or an alert
indication on a dashboard
 Locality diagram shows localities and their physical
interconnections and characteristics.
 Localities may apply at each level of abstraction
 Locality is the context for dealing with adequacy of
system to meet non-functional (quality)
requirements (reliability, performance, capacity,
cost, etc.)
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Joint realization shows how operations are realized both in
logical and distribution architectures.
 Select level of abstraction for locality model
– Not usually done at Level 0 or 1
– Maybe done at multiple levels
 Do sequence diagram of a use case
– As before with logical elements
– Now with distribution elements
 Show distribution elements and actors
 Show each operation as message into
distribution element.
29
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Multiple viewpoints and levels of abstraction allow system engineers to
focus on specific concerns while keeping the whole system in mind.
Viewpoints
Model Level
Worker
Logical
Distribution
Enterprise Data
View
Enterprise Locality
View
Process
Context
UML
Organization
View
Analysis
Generalized
System Worker
View
System Analysis
Model (Subsystem
Diagram)
System Data
View
System Deployment
Model (Locality
View)
System
Process
View
System Worker
View
• System Design
Model
(Subsystem/Class
Diagram)
System Data
Schema
System Deployment
Model (Descriptor
View)
Detailed
Process
View
Design
System Context
Diagram
Information
• Component views
Implementation
Worker Role
Specifications
and Instructions
Deployment diagram at Implementation level for each configuration
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Standard architectural views like DoDAF/MODAF aid in
communication to stakeholders, and should derive
from the architectural models.
Context
 High-level stakeholders can learn to expect certain
high level views
Usage
 Identify, classify and harvest DoDAF content in the
form of reusable assets
Realization
 Automated matrix creation
to ensure consistency
– AV-2, OV-3, SV-3, SV-4, SV-5, SV-6
Joint
Realization
 Reporting of all DoDAF views
– Generated to a Microsoft® Word document
 Import custom graphics (OV-1)
 DoDAF model framework for work
products and views
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Model Execution
for early verification and validation through model execution
itsUser
Uc1_ControlEntry
itsAccessPoint
itsCamera
reqReadSecurityCard()
readSecurityCard()
reqTakeSnapshot()
validateSecurityCard(CardStatus = Valid)
displayCardStatus(CardStatus = Valid)
reqScanBiometricData()
scanBiometricData()
authenticateBiometricData(AuthenticationStatus = Authenticated)
displayAuthenticationStatus(AuthenticationStatus = Authenticated)
reqUnlockAccessPoint()
tm(1000)
evAccessPointUnlocked()
Animated Statechart Diagram
(Uc1ControlEntry)
Animated Sequence Diagram (Uc1Sc1)
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Asset-Based Systems Engineering
 Reuse: doing more with less
What
 Moving from documentation to recreation
Requirements
 Capture engineering and business
value
 Engineering asset
– What, How and Why
– Tailor and reuse
– Contribute back to library
Why
Rationale
How
System
Models
 Precursor to full product line
approach
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Boeing Space Systems:
Future Image System Ground Station Architecture
Client situation
Very large project
 Approximately US$5 billion development project
 Team made up of four companies with developers at five sites
 Approximately five million lines of code, much of it new
Solution
 Use the IBM Systems Engineering
solution, modeling and requirements
management for architecture framework
Status
 Organize a cross-functional team including
system engineers and software architects
 One hundred forty-five system engineers building requirement
specifications based on functional allocations
 UML model created for all engineering
efforts
 Poor communications with software developers; little progress
 Adopt iterative program management
 Engineering documents unusable by developers
 Use-case-driven iteration and test
planning
 Spending US$1 million a week
Challenge
 Introduce a process that scales to a large project that
enables the different teams and stakeholders to collaborate
Results
“Project on track through five iterations, millions of dollars in savings. The solution enhanced our
project success rate from 14 percent to over 90 percent.”
— Michael Mott, technical fellow Boeing S&IS
© 2012 IBM Corporation34
Software and Systems Engineering | Rational
National Aeronautics & Space Administration: James Webb
Space Telescope
Solution
Client situation
James Webb Space Telescope (JWST)
The next-generation telescope, which will succeed the Hubble space
telescope, is expected to be launched by 2013. It will study galaxy,
star and planet formation in the universe. To study the earliest star
formation, NASA will observe infrared light using special instruments
optimized to capture this part of the spectrum.
Challenges
 Develop and govern a large systems program
 Reduce development time and cost
 Provide consistency in designing large-scale systems across the program and
various instruments being built (hardware and software co-development of
systems)
 Manage distributed systems development across systems integrators and
NASA, which included the four instruments
 Use standard processes for systems development across the organization, and
comply with CMMI regulations
 Reuse the software for the instruments across the program to improve
productivity
IBM Rational systems development
solution—an integrated approach to
architecting, building and governing
complex systems of systems
 IBM Rational Requirements
Management—implemented requirements
from business need to implementation in for
traceability
 IBM Rational RealTime software—
implemented full system model using UML
to facilitate communication and reuse;
increased predictability and reliability of
the systems
 IBM Rational ClearCase and Rational
ClearQuest software—facilitated
collaboration and asset reuse of artifacts
across JWST
Results
“It was important that NASA be forward-looking with the James Webb Space Telescope by using a systems development
platform that would be reliable and ahead of the marketplace throughout the extensive life of the mission.”
—Glen Camarata, ISIM flight software development lead, Satellite Software Corporation
© 2012 IBM Corporation
Software and Systems Engineering | Rational
One innovative organization made their models visible to everyone
in the company!
 Models first developed on flip
charts
 Later maintained in automated
modeling tools
 Finally, produced on large wall
charts for increased visibility,
communication, collaboration
 Became center for discussion
across all teams.
© 2011 IBM Corporation
Software and Systems Engineering | Rational







Learn more at:
IBM Rational software
IBM Rational Software Delivery Platform
Process and portfolio management
Change and release management
Quality management
Architecture management






Rational trial downloads
Leading Innovation Web site
developerWorks Rational
IBM Rational TV
IBM Business Partners
IBM Rational Case Studies
© Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied.
IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties
or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs,
or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on
market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services are
trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
© 2011 IBM Corporation
Software and Systems Engineering | Rational
Copyright information
© Copyright IBM Corporation 2011
IBM Corporation
Software Group
Route 100
Somers, NY 10589
Produced in the United States of America
03-07
All Rights Reserved.
Build Forge, ClearCase, ClearQuest, IBM, the IBM logo, PurifyPlus, Rational, Rational Rose, Rational Test RealTime, Rational Unified
Process, RUP, SoDA, XDE and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the
United States, other countries or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft is a trademark of Microsoft Corporation in the United States, other countries, or both.
Other company, product and service names may be trademarks or registered trademarks or service marks of others.
The information contained in this documentation is provided for informational purposes only. While efforts were made to verify the
completeness and accuracy of the information contained in this documentation, it is provided “as is” without warranty of any kind, express or
implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without
notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this documentation or any other
documentation. Nothing contained in this documentation is intended to, nor shall have the effect of, creating any warranties or
representations from IBM (or its suppliers or licensors), or altering the terms and conditions of the applicable license agreement governing
the use of IBM software.
38
© 2011 IBM Corporation