Advancing Agility in Health Care Systems:
Applying the INCOSE Agile Systems Engineering
Life Cycle Management Pattern
Bill Schindel schindel@ictt.com
INCOSE Agile Health Care Systems Conference
May 16-17, 2017, Chicago, IL
Copyright 2017, William D. Schindel, Permission granted to use with attribution V1.3.2A
3. System of Innovation (SOI)
2. Target System (and Component) Life Cycle Domain System
1. Target System
LC Manager of
Target System
Learning & Knowledge
Manager for LC Managers
of Target System
Life Cycle Manager of
LC Managers
Learning & Knowledge
Manager for Target
System
Target
Environment
(Substantially all the ISO15288 processes are included in all four Manager roles)
Abstract
• During the 2016 Agile Health Care Systems Conference,
a break-out group worked on application of the
INCOSE Agile Systems Engineering Life Cycle
Management (ASELCM) Pattern, applied to the health
care domain. This led to identification of perceived
priority targets for increased agility in the health care
domain.
• This session will briefly review their conclusions, then
provide a means for participants to apply the pattern
further, along with another INCOSE planning
instrument, in the public forum offered by the
conference as well as confidentially when they return
to their home enterprises.
2
Contents
• Health care systems and agility
• INCOSE: Agility in general systems engineering
• The emerging connection of agility to models
• INCOSE ASELCM Pattern, applied to Health Care Systems
• INCOSE MBSE Assessment and Planning Pattern
• Agility through shared patterns in regulated domains
• Conclusions from 2016 INCOSE AHCS and ET Conferences
• Break out session: Agile Test Drive, Hot Spot Collection
• References
• Attachment: Break out session materials
• Attachment: Take home beta instruments for your use
3
Health Care Systems and Agility
• Viewed at almost any level—individuals, products,
enterprises, market segments, or society--Health
Care appears as a vast and complex system.
4
Health Care Systems and Agility
• Since there are countless challenges and
opportunities for progress, how can an enterprise,
industry, society, or individual systematically plan
and manage future progress and innovation?
– Where can we best apply the principles and lessons of
Systems Engineering, deeper Agility, or Lean Methods
to make optimal progress today, tomorrow, and in the
future?
– Is there a systemic approach to map-making for
planning this progress?
5
Health Care Systems and Agility
• Roughly speaking, in referring to “agility”, we mean ability
to respond effectively to the challenges of uncertainty and
rates of change in environment, stakeholders, competition,
technologies, capacities, capabilities.
• This includes learning and adjusting.
• Not just “going faster”.
6
6
Health Care Systems and Agility
• This session will include brief overviews of the:
– INCOSE Agile Systems Engineering Life Cycle Management
(ASELCM) Pattern being developed by the INCOSE ASELCM
Discovery Project,
– INCOSE MBSE Planning and Assessment Roadmap being
developed by the MBSE Transformation Project,
– INCOSE Model VVUQ Pattern being developed by INCOSE as
part of the ASME Model Validation and Verification Project,
• And,
– Break out: “Test drive” some of these, to map “hot spots”
and opportunities for progress
– Take home: Plus, resources to use privately after the
conference.
7
INCOSE:
Agility in General Systems Engineering
• The INCOSE parent society is sponsoring the Agile Systems
Engineering Life Cycle Model (ASELCM) Discovery Project:
– Based on a series of workshop clinics being held at case study
discovery host enterprise sites
• This project, now underway, will provide INCOSE inputs to a future
version of ISO 15288, to improve explicit understanding of principles
and practices of agility as applicable to systems engineering across
different domains.
– So far, three case studies and an overview have been published in
INCOSE and IEEE conference proceedings, with continuing work
underway
– Your company can host such an INCOSE discovery workshop
• Support from INCOSE Agile Systems WG and MBSE Patterns WG:
– Rick Dove, project lead, co-leads Kevin Forsberg, Jack Ring, Garry
Roedler, Bill Schindel
8
INCOSE: Agility in General Systems Engineering
Longer history than just Agile Software Development
Methods :
– For history and background, see Dove and LaBarge, 2014
– Agile software methods, by far better known, are related.
– General Agile Systems Engineering is the related broader
subject of the INCOSE ASELCM Project.
9
Agile
Enterprise
Systems—
Origins
(c. 199x)
Agile
Software
Methods
(c. 200x)
General Agile
Systems
Engineering
(c. 201x)
Optimized Feedback & Correction Cycle Rate:
A Hallmark of Agile Methods & Problem Space
An Apollo 11 Mission Question: Why was the Saturn V
rocket engines’ directional gimbals update cycle period
throughout the Ascent Phase ~ 2 seconds, but the
update cycle period of course direction during the Free
Flight Phase was ~ 26 hours?
10
E
M
Ascent Phase Updates:
Saturn V Launch Vehicle
Engine Gimbal Feedback
Control Loop Update Period
Δt ~ 2 seconds
Free Flight Phase Updates:
Time to Mid-Course Correction:
Δt ~ 26 hours, 44 minutes
Ascent
TLI
MCC
11
• Configurations change over life cycles, during development and subsequently
• Trajectories (configuration paths) in S*Space
• Effective tracking of trajectories
• History of dynamical paths in science and math
• Differential path representation: compression, equations of motion
System Life Cycle Trajectories in S*Space
The Emerging Connection of Agility to Models
“Agility” and “Trajectory” are not just metaphorical
terms—there is a further body of applicable
historical technical findings, tools:
Controller/Estimator
-H
i
K
i
-C
i
Φ
i
Γ
i
Unit
Delay
z
i
u
i
Generated Controls
Observations
Estimated
Previous State
Managed
System &
Environment
x
i
-
Error
Correction
Signal
Observation
Weighting
Pre-Observation Predicted Future State
(Dead Reckoning)
-
+ +
+
Optimal
Control
Generation
+
+
System
Dynamics
X
i+1
-
Predicted
Impact of
Control
12
How are Agile Systems Related to MBSE?
1. Basics: Using explicit models, MBSE/PBSE adds clarity to pre-model descriptions
of Agile Systems and Agile SE-- improves understanding of Agile Systems.
2. More important: MBSE/PBSE complements and improves the capability of Agile
Systems and Agile Systems Engineering—
• Agility requires persistent memory & learning—being forgetful/not learning impacts agility.
• Patterns capture & retain learning, as persistent, re-usable, configurable, models, updated
as experience accumulates.
• S*Patterns are configurable, reusable S*Models.
“PBSE as Agile MBSE” emerges as essential when competing on agility becomes
reality for competing, competent players:
– Improved: “Where are we?”
– Improved: “Where are we going?”
– Improved: “We’ve been here before.”
– Improved: Understanding of response.
– Improved: Understanding of mission envelopes.
– Improved: Ability to assess agility
– Improved: Ability to plan agility
13
Vital for Scrum, other approaches
Vital for Response Situation
Analysis (RSA, Dove)
• The SE Process consumes and produces information.
• But, SE historically emphasizes process over information. (Evidence: Ink & effort spent
describing standard process versus standard information.)
• Ever happen?-- Junior staff completes all the process steps, all the boxes are checked,
but outcome is not okay.
• Recent discoveries about ancient navigators: Maps vs. Itineraries.
• The geometrization of Algebra and Function spaces (Descartes, Hilbert)
• Knowing where you are, not just what you are doing.
• Knowing where you are going, not just what you are doing.
• Distance metrics, inner products, projections, decompositions.
Maps vs. Itineraries -- SE Information vs. SE Process
14
15
• Model-based Patterns in S*Space.
• Interactions as the basis of all laws of physical sciences.
• Relationships, not procedures, are the fruits of science used by engineers: Newton’s laws,
Maxwell’s Equations.
• Immediate connection to Agility: knowing where you are--starting with better definition of
what “where” means. There is a minimal “genome” (S*Metamodel) that provides a practical
way to capture, record, and understand—the “smallest model of a system”.
• Not giving up process: MBSE/PBSE version of ISO/IEC 15288.
Maps vs. Itineraries -- SE Information vs. SE Process
The ASELCM Pattern,
Applied to Health Care Systems
• We will particularly refer to three major system
boundaries:
– To avoid a confusion bog of loaded terms, we could have
just named them “System 1”, “System 2”, and “System 3”
and proceeded to define them behaviorally.
– The definitions are behavioral because these are logical
systems, performing defined roles.
– However, we will also give them more specific names —
but make sure you understand the definitions of these
systems, which are more important than their names . . .
16
17
• System 1: Target system of interest, to be engineered or improved.
• System 2: The environment of (interacting with) S1, including all the
life cycle management systems of S1, including learning about S1.
• System 3: The life cycle management systems for S2, including
learning about S2.
The Agile System Life Cycle Management
Domain Model
3. System of Innovation (SOI)
2. Target System (and Component) Life Cycle Domain System
1. Target System
LC Manager of
Target System
Learning & Knowledge
Manager for LC Managers
of Target System
Life Cycle Manager of
LC Managers
Learning & Knowledge
Manager for Target
System
Target
Environment
(Substantially all the ISO15288 processes are included in all four Manager roles)
Behind the “iconic” diagram, there is a formal
MBSE model that describes the ASELCM Pattern
18
3. System of Innovation (SOI)
2. Target System (and Component) Life Cycle Domain System
1. Target System
Target System
Target System
Life Cycle Domain
Actor
LC Manager of Target System
(and Components)
(substantially all ISO15288 processes)
Some of these life cycle management roles may be assigned
to the same physical system as the Target System
Configured Models Repository,
Describing Configured Instances of:
Learning & Knowledge Manager for
LC Managers of Target System
(substantially all ISO15288 processes)
Pattern Repository, Describing
Knowledge of Families of:
Target System
Component
Target System
Target System
Life Cycle Domain
Actor
Life Cycle Manager of LC Managers
(substantially all ISO15288 processes)
LC Managers of Target
System
(all ISO15288 processes)
Learning & Knowledge Manager for
Target Systems (and Components)
(substantially all ISO15288 processes)
Pattern Repository,
Describing Knowledge of Families of:
Target System
Component
Target System
Target System
Life Cycle Domain
Actor
Configured Models Repository,
Describing Configured Instances of:
LC Managers of Target
System
(all ISO15288 processes)
Manages
Life Cycle of
Observes
Provides
Knowledge to
Provides
Knowledge to
Manages
Life Cycle of
Target System
Component
Observes
Provides Observations to
Observes
Provides Observations to
Manages
Life Cycle of
Observes
More Than One Representation
(Model View) of the Same Underlying Reality
Four different representations of the same underlying reality:
1. The Scrum Pattern: Emphasizes time-bound outputs and feedback, focusing on processes for
learning from produced outputs, and management of risk
2. The ISO15288 Pattern: Emphasizes types of processes, focusing on management of processes
3. The Agile Systems Engineering Life Cycle Pattern : Shows how (1) and (2) above may be seen as one
4. The S*Metamodel: Emphasizes the information flowing through all three of them: (1), (2), and (3)
19
S*Metamodel for
Model-Based Systems
Engineering (MBSE)
S*Pattern Hierarchy for
Pattern-Based Systems
Engineering (PBSE)
System Pattern
Class Hierarchy
Individual Product
or System Configurations
Product Lines or
System Families
General
System
Pattern
State
Input/
Output
Interface
Functional
Interaction
(Interaction)
System
System of
Access
attribute
Technical
Requirement
Statement
Stakeholder
Feature
attribute
Design
Component
attribute
(physical system)
(logical system)
Functional
Role
attribute
“A” Matrix
Couplings
“B” Matrix
Couplings
Stakeholder
World
Language
High Level
Requirements
Technical
World
Language
attribute
Design
Constraint
Statement
attribute
Stakeholder
Requirement
Statement
BB
WB
Detail Level
Requirements
High Level
Design
BB
WB
Scrum Pattern
ISO15288 Pattern
ASELCM
Pattern
S*Metamodel
Performing a Sprint (Time Limited)
Planning Sprint
Sprint
Planned
Performing Sprint Development
Sprint Time
Window Ends
Project
Planned
Refining Future Sprint Backlog
Retrospective
Completed
Review Priority Items &
Set Sprint Thematic Goal
Forecast Sprint
Content Items
Attend Daily Scrum
Track Daily Progress
Perform
Developmental Task
Analyze Future Item
Requirements
Estimate Future Items
Split, Merge, Rescope
Future Items
Inspected Product
Not Ready for Release
(not “Done”)
Sprint Time
Window Ends
Planning Project
Project
Initiated
Initiate Product Backlog
texttext
text
text
text
text
text
text
text
text
text
text
Traditional Scrum Sprint Perspective
(Summary State Machine)
Conducting Sprint
Product Review
Inspect Product
Update Product
Backlog
Project
Termination
Conducting Sprint
Process Retrospective
Review Process &
Environment
Adapt Process &
Environment
Performing
Product Release
Release Product
Subsequent Life Cycle of
Product Release
Product
Released
Release
Life Cycle
Ended
Perform Target
Interaction
Inspected Product
Ready for Release
(“Done”)
Copyright 2015, ICTT System Sciences
“Perform Developmental Task” may include, as appropriate,
any team-selected task from the ISO 15288 Technical
Processes that could be performed by the internal team
(e.g., Requirements, Design, Implementation, Verification
Testing, etc.)
Provide In-Service
Feedback
3. System of Innovation (SOI)
2. Target System (and Component) Life Cycle Domain System
1. Target System
Target System
Target System
Life Cycle Domain
Actor
LC Manager of Target System
(and Components)
(substantially all ISO15288 processes)
Some of these life cycle management roles may be assigned
to the same physical system as the Target System
Configured Models Repository,
Describing Configured Instances of:
Learning & Knowledge Manager for
LC Managers of Target System
(substantially all ISO15288 processes)
Pattern Repository, Describing
Knowledge of Families of:
Target System
Component
Target System
Target System
Life Cycle Domain
Actor
Life Cycle Manager of LC Managers
(substantially all ISO15288 processes)
LC Managers of Target
System
(all ISO15288 processes)
Learning & Knowledge Manager for
Target Systems (and Components)
(substantially all ISO15288 processes)
Pattern Repository,
Describing Knowledge of Families of:
Target System
Component
Target System
Target System
Life Cycle Domain
Actor
Configured Models Repository,
Describing Configured Instances of:
LC Managers of Target
System
(all ISO15288 processes)
Manages
Life Cycle of
Observes
Provides
Knowledge to
Provides
Knowledge to
Manages
Life Cycle of
Target System
Component
Observes
Provides Observations to
Observes
Provides Observations to
Manages
Life Cycle of
Observes
Example: Health care domain, top level
20
3. System of Innovation (SOI)
2. Target System (and Component) Life Cycle Domain System
1. Target System
LC Manager of
Target System
Learning & Knowledge
Manager for LC Managers
of Target System
Life Cycle Manager of
LC Managers
Learning & Knowledge
Manager for Target
System
Target
Environment
(Substantially all the ISO15288 processes are included in all four Manager roles)
Example: Health care domain, top level
21
3. Health Care System of Innovation (SOI)
2. Patient Health Life Cycle Domain System
1. Target System
Patient
Patient
Environment
Health Care Delivery System
(Health Care equivalents of Agile (extended)
ISO15288 Model, including HC equivalents of
Performance, Fault, Configuration, Accounting,
and Security Management Processes)
Configured Models Repository,
Describing Configured Instances of:
Learning & Knowledge Manager for
Health Care Delivery Systems
Pattern Repository, Describing
Knowledge of Families of:
Life Cycle Manager of Health Care Delivery
System
Learning & Knowledge Manager for
Target Systems (and Components)
(substantially all ISO15288 processes)
Pattern Repository,
Describing Knowledge of Families of:
Configured Models Repository,
Describing Configured Instances of:
Manages
Life Cycle of
Observes
Provides
Knowledge to
Provides
Knowledge to
Manages
Life Cycle of
Patient Subsystem
Observes
Provides Observations to
Observes
Provides Observations to
Manages
Life Cycle of
Observes
Occupational
Environment
Home
Environment
Extracurricular
Environment
School
Environment
Health Care
Equipment
Medical Device
Health Care
Practitioner
Health Care Payer
Insuring
Employer
Insuring Family
Medical Records
System
Caregiver
Diagnostic
Service System
Therapeutic
Service System
Transcription
Service System
Coding Process
HC Education
Service
Business Office
Facilities and
Infrastructure
Health Care
Organization
HR Role
Safety, Quality
Assurance
Care Plan
Development
Pharmacy
Clinic
Hospital
Private Practice
Health Services
Marketing
Health Care Regulator
Provider Insurer
Health Care Delivery
Investor
Health Care
Delivery Holding
Company
Practice
Management
System Supplier
Medical School
Nursing School
Health Care
Organizational
Change Consultant
Medical Devices and
Equipment Supplier
Pharmaceutical
Supplier
Medical Information
Technologies
Supplier
Contract Medical
Manufacturer
Contractual Medical
Trials Business
Contractual Medical
Products Developer
Orthopedics
Manufacturer
Health Care
Systems
Engineering,
Fabrication,
Construction &
Installation
Health Care Systems
Maintenance &
Support
Medical Practice
Consultant
Teaching Hospital
Health Care Licenser
Health Care
Certification Agent
Medical Products
Marketing
Contract Research
Organization (CRO)
Health Care
Research Web Site
Crowd-Sourced
Health Care Web Site
Pharma Molecule
Database
Best Medical
Practices Database
Evidence-Based
Medicine Repository
Health Care Expert
Medical
Journal
Genetics
Database
Life Sciences
Repository
Life Sciences
Textbook
Life Scientist
Patient
Component
Patient
Patient
Environment
Patient
Component
Patient
Patient
Environment
Health Care Delivery
System
Health Care Delivery
System
Health Care Domain Reference Boundaries:
Agile System Life Cycle Management Perspective
INCOSE Patterns Working Group
V1.3.1 10.28.2015
INCOSE MBSE Assessment and Planning Pattern
• The INCOSE parent society Board of Directors made it a strategic objective
to support the transformation of SE to a model-based discipline.
• An Assistant Director (Troy Peterson) for this Transformation was
appointed, and a plan of actions and deliverables adopted.
– http://www.incose.org/about/strategicobjectives/transformation
• Among the products: The MBE Transformation Roadmap, a planning and
assessment instrument for progress in model-based methods.
• Initial minimal product version was shown and piloted at Agile Health Care
Systems 2016, at Energy Tech 2016, at IW2017 MBSE Workshop, and at IW
2017 CAB meeting,
• Initial Model Stakeholder Features being piloted in INCOSE support for the
ASME Model VVUQ project.
• What does it mean to become a model-based discipline?
– The Stakeholder Features of Models, and how they support the overall
discipline
• An SE view: Model-based ISO15288 processes and life cycle stages
– ISO15288 is not agile incompatible and is not waterfall
22
23
System of Innovation (SOI) Pattern Logical Architecture
(Adapted from ISO/IEC 15288:2015)
Technical Processes
Service Life: Top System
Realization: Subsystem 3
Realization: Subsystem 2
Design: Subsystem 3
Component Level Design,
Acquisition, Fabrication
Realization: Top System
Realization: Subsystem 1
Design: Top System
Project Processes
Project
Planning
Project
Assessment
and Control
Decision
Management
Risk
Management
Configuration
Management
Information
Management
Measurement
Transition
Operation
Maintenance
Disposal
Stakeholder Needs,
Requirements
Definition
System
Requirements
Definition
Requirements
Validation
Verification
(by Analysis &
Simulation)
Implementation
Integration
Verification
(by Test)
Organizational
Project-Enabling
Processes
Project
Portfolio
Management
Infrastructure
Management
Life Cycle Model
Management
Human
Resource
Management
Quality
Management
Agreement
Processes
Acquisition
Supply
Solution
Validation
Integration
Verification
(by Test)
Solution
Validation
Knowledge
Management
Process
Quality
Assurance
Process
Business,
Mission Analysis
Design
Definition
Architecture
Definition
Design: Subsystem 2
Design: Subsystem 1
Stakeholder Needs,
Requirements
Definition
System
Requirements
Definition
Requirements
Validation
Verification
(by Analysis &
Simulation)
Business,
Mission Analysis
Design
Definition
Architecture
Definition
System
Analysis
System
Analysis
INCOSE MBSE Assessment and Planning Pattern
INCOSE MBSE Assessment and Planning Pattern
Stakeholders in A Successful MBSE Transformation
(showing their related roles and parent organizations)
Industry & Gvmt. Initiatives
Organizations Internalizing MBSE,
Including Gvmt Contractors &
Commercial
Vendors of MBSE Tooling and
Services
Academia and Researchers
Technical Societies, Other Non-
Technical Organizations
Model Consumers (Model Users):
****
Non-technical stakeholders in various Systems of Interest, who acquire / make decisions about / make use of those systems, and are
informed by models of them. This includes mass market consumers, policy makers, business and other leaders, investors, product
users, voters in public or private elections or selection decisions, etc.
X X X
**
Technical model users, including designers, project leads, production engineers, system installers, maintainers, and users/operators.
X X X
*
Leaders responsible to building their organization's MBSE capabilities and enabling MBSE on their projects X X X
*
Product visionaries, marketers, and other non-technical leaders of thought and organizations X X X X
*
System technical specifiers, designers, testers, theoreticians, analysts, scientists X X X X
*
Students (in school and otherwise) learning to describe and understand systems X X
*
Educators, teaching the next generation how to create with models X X X
*
Researchers who advance the practice X X X
*
Those who translate information originated by others into models X X X X
*
Those who manage the life cycle of models X X X X
**
Marketing professionals X X X X
**
Educators, especially in complex systems areas of engineering and science, public policy, other domains, and including curriculum
developers as well as teachers
X X X X
**
Leaders of all kinds X X X X X
*
Suppliers of modeling tools and other information systems and technologies that house or make use of model-based information
X
*
Methodologists, consultants, others who assist individuals and organizations in being more successful through model-based
methods
X X X X
*
Standards bodies (including those who establish modeling standards as well as others who apply them within other standards) X X
*
As a deliverer of value to its membership X
*
As seen by other technical societies and by potential members X
*
As a great organization to be a part of X
*
As promoter of advance and practice of systems engineering and MBSE X
INCOSE and other Engineering Professional Societies
Model Consumers (Model Users):
Model Creators (including Model Improvers):
Complex Idea Communicators (Model "Distributors"):
Model Infrastructure Providers, Including Tooling, Language and Other Standards, Methods:
24
INCOSE MBSE Assessment and Planning Pattern
25
Legend:
Model Representation
Model Scope and Content
Model Fidelity
Model Identity and Focus
Model Life Cycle Management
Model Utility
Modeled
Stakeholder
Value
Model Intended
Use
LIFE CYCLE PROCESS SUPPORTED
(ISO15288)
Perceived Model
Value and Use
Verified
Executable
Model Fidelity
Modeled System
External (Black
Box) Behavior
Stakeholder Feature Model
for Computational Models
Version: 1.4.15
Date: 30 Apr 2017
Drawn By: B
Schindel
Modeled System
of Interest
Modeled
Environmental
Domain
Conceptual Model
Representation
Executable
Model
Representation
Managed Model
Datasets
Executable Model
Environmental
Compatibility
Validated
Conceptual
Model Fidelity
Quantitative Accuracy Reference
Quantitative Accuracy Reference
STAKEHOLDER
FEATURE
FEATURE PK ATTRIBUTE
Other Feature Attribute
Other Feature Attribute
Parametric
Couplings--
Fitness
Physical
Architecture
Explanatory
Decomposition
Model Envelope
Trusted
Configurable
Pattern
Uncertainty Quantification (UQ) Reference
Function Structure Accuracy Reference
Function Structure Accuracy Reference
Model Validation Reference
Speed
Quantization
Stability
Model Validation Reference
Uncertainty Quantification (UQ) Reference
Third Party
Acceptance
Model Ease of
Use
Model
Design Life Cycle
and Retirement
Model
Maintainability
Model
Deployability
Model Cost
Model
Availability
Model Versioning
and Configuration
Management
System of Interest
Domain Type
MODEL APPLICATION ENVELOPE
CONFIGURATION ID
Conceptual Model Representation Type
Conceptual Model Interoperability
Executable Model Representation Type
Executable Model Interoperability
USER GROUP SEGMENT
Level of Annual Use
Value Level
ACCEPTING AUTHORITY
Perceived Model Complexity
CM CAPABILIY TYPE
DATASET TYPE
IT ENVIRONMENTAL COMPONENT Design Life
Maintenance Method Deployment Method
Development Cost
Operational Cost
Maintenance Cost
Deployment Cost
Retirement Cost
Life Cycle Financial Risk
First Availability Date
First Availability Risk
Life Cycle Availability Risk
STAKEHOLDER TYPE
Parametric
Couplings--
Decomposition
Parametric
Couplings--
Characterization
Pattern Type
Agility Through Shared Patterns
in Regulated Domains
• In domains where innovation is subject to regulation (e.g., Health Care,
Aviation, Automotive, etc.), agility may seem to have special challenges:
– This conference is already aware of efforts to accommodate agile methods while
meeting regulatory goals (e.g., safety).
• A powerful way to view efforts to find agreed-upon approaches is to think
of them as agreements concerning shared system pattern frameworks:
– MBSE extension of idea already applied to Devices of limited vs. greater changes
26
3. System of Innovation (SOI)
2. Target System (and Component) Life Cycle Domain System
1. Target System
LC Manager of
Target System
Learning & Knowledge
Manager for LC Managers
of Target System
Life Cycle Manager of
LC Managers
Learning & Knowledge
Manager for Target
System
Target
Environment
(Substantially all the ISO15288 processes are included in all four Manager roles)
Agility Through Shared Patterns
in Regulated Domains
• Example: The Model VVUQ Pattern, being examined in the ASME Model
VVUQ standards and guidelines effort:
– How can evidence be provided to most efficiently demonstrate evidence
of model VVUQ?
– The over effort already includes FDA, FAA, others
• In break-out, we will take the related Model System Features for a test drive
27
3. System of Innovation (SOI)
2. Target System (and Component) Life Cycle Domain System
1. Target System
LC Manager of
Target System
Learning & Knowledge
Manager for LC Managers
of Target System
Life Cycle Manager of
LC Managers
Learning & Knowledge
Manager for Target
System
Target
Environment
(Substantially all the ISO15288 processes are included in all four Manager roles)
Conclusions from 2016 INCOSE AHCS
Conference Break-Out Session
• During the 2016 version of this conference,
participants used the ASELCM Pattern to
identify Health Care Domain systems that they
deemed:
28
Conclusions from 2016 INCOSE AHCS
Conference Break-Out Session
29
• Yellow:
– Caregiver
– Medical School
– Hospital
– Coding Process
– Health Care Equipment
– Medical Devices
• Green:
– Medical Devices and Equipment
Supplier
– Safety, Quality Assurance
– Pharmacy
– Health Care Equipment
– Medical Devices
• Red:
– Patient Interface to Health Care
(Including Insurance)
– Medical Devices and
Equipment Supplier
– Health Care Delivery Investor
– Health Care Payer
– Provider Insurer
– Insuring Employer
– Practice Management System
Supplier
– Health Care Delivery Holding
Company
– Medical Record System
– Health Care Equipment
– Outcomes Analysis
30
Conclusions from 2016 INCOSE AHCS
Conference Break-Out Session
31
System of Innovation (SOI) Pattern Logical Architecture
(Adapted from ISO/IEC 15288:2015)
Technical Processes
Service Life: Top System
Realization: Subsystem 3
Realization: Subsystem 2
Design: Subsystem 3
Component Level Design,
Acquisition, Fabrication
Realization: Top System
Realization: Subsystem 1
Design: Top System
Project Processes
Project
Planning
Project
Assessment
and Control
Decision
Management
Risk
Management
Configuration
Management
Information
Management
Measurement
Transition
Operation
Maintenance
Disposal
Stakeholder Needs,
Requirements
Definition
System
Requirements
Definition
Requirements
Validation
Verification
(by Analysis &
Simulation)
Implementation
Integration
Verification
(by Test)
Organizational
Project-Enabling
Processes
Project
Portfolio
Management
Infrastructure
Management
Life Cycle Model
Management
Human
Resource
Management
Quality
Management
Agreement
Processes
Acquisition
Supply
Solution
Validation
Integration
Verification
(by Test)
Solution
Validation
Knowledge
Management
Process
Quality
Assurance
Process
Business,
Mission Analysis
Design
Definition
Architecture
Definition
Design: Subsystem 2
Design: Subsystem 1
Stakeholder Needs,
Requirements
Definition
System
Requirements
Definition
Requirements
Validation
Verification
(by Analysis &
Simulation)
Business,
Mission Analysis
Design
Definition
Architecture
Definition
System
Analysis
System
Analysis
Conclusions from 2016 INCOSE Energy Tech
Conference MBSE Break-Out Session
Copyright © 2016 by W. D. Schindel. Permission granted to use with attribution.
Conclusions from 2016 INCOSE Energy Tech
Conference MBSE Break-Out Session
Stakeholders in A Successful MBSE Transformation
(showing their related roles and parent organizations)
Industry & Gvmt. Initiatives
Organizations Internalizing MBSE,
Including Gvmt Contractors &
Commercial
Vendors of MBSE Tooling and
Services
Academia and Researchers
Technical Societies, Other Non-
Technical Organizations
Model Consumers (Model Users):
****
Non-technical stakeholders in various Systems of Interest, who acquire / make decisions about / make use of those systems, and are
informed by models of them. This includes mass market consumers, policy makers, business and other leaders, investors, product
users, voters in public or private elections or selection decisions, etc.
X X X
**
Technical model users, including designers, project leads, production engineers, system installers, maintainers, and users/operators.
X X X
*
Leaders responsible to building their organization's MBSE capabilities and enabling MBSE on their projects X X X
*
Product visionaries, marketers, and other non-technical leaders of thought and organizations X X X X
*
System technical specifiers, designers, testers, theoreticians, analysts, scientists X X X X
*
Students (in school and otherwise) learning to describe and understand systems X X
*
Educators, teaching the next generation how to create with models X X X
*
Researchers who advance the practice X X X
*
Those who translate information originated by others into models X X X X
*
Those who manage the life cycle of models X X X X
**
Marketing professionals X X X X
**
Educators, especially in complex systems areas of engineering and science, public policy, other domains, and including curriculum
developers as well as teachers
X X X X
**
Leaders of all kinds X X X X X
*
Suppliers of modeling tools and other information systems and technologies that house or make use of model-based information
X
*
Methodologists, consultants, others who assist individuals and organizations in being more successful through model-based
methods
X X X X
*
Standards bodies (including those who establish modeling standards as well as others who apply them within other standards) X X
*
As a deliverer of value to its membership X
*
As seen by other technical societies and by potential members X
*
As a great organization to be a part of X
*
As promoter of advance and practice of systems engineering and MBSE X
INCOSE and other Engineering Professional Societies
Model Consumers (Model Users):
Model Creators (including Model Improvers):
Complex Idea Communicators (Model "Distributors"):
Model Infrastructure Providers, Including Tooling, Language and Other Standards, Methods:
32
Break Out Session:
Agile Test Drive, Hot Spot Collection
During this break out session, use the hand-outs to:
• Identify Health Care Domain areas you believe are
opportunities, problems, and accomplishments for an
Agile approach—discuss at session end, turn in.
• Identify ISO 15288 areas you believe are opportunities,
problems, and accomplishments for an Agile as well as
MBSE methods—discuss at session end, turn in.
• Review and comment on the INCOSE Feature Pattern for
Model Stakeholders—discuss at session end, turn in.
• This also gives INCOSE some “agile feedback” on its
products in process.
• In return, you will also have “take home copies” that
you can carry home (or download) and try out privately.
33
Discussion
•
•
•
•
•
•
34
References
1. Assessing the Reliability of Complex Models: Mathematical and Statistical
Foundations of Verification, Validation, and Uncertainty Quantification ISBN 978-0-
309-25634-6 THE NATIONAL ACADEMIES PRESS, http://nap.edu/13395
2. Web site of ASME VV50
https://cstools.asme.org/csconnect/CommitteePages.cfm?Committee=100003367
3. “ASME V&V 10-2006: Guide for Verification and Validation in Computational Solid
Mechanics”, ASME, 2006.
4. “ASME V&V 20-2009: Standard for Verification and Validation in Computational
Fluid Dynamics and Heat Transfer”, ASME, 2009.
5. “ASME V&V 10.1-2012: An Illustration of the Concepts of Verification and Validation
in Computational Solid Mechanics”, ASME, 2012.
6. Journal of Verification, Validation, and Uncertainty Quantification, ASME.
https://verification.asmedigitalcollection.asme.org/journal.aspx
7. AIAA (American Institute for Aeronautics and Astronautics). 1998. Guide for the
Verification and Validation of Computational Fluid Dynamics Simulations. Reston,
Va.: AIAA.
8. Box, G., and N. Draper. Empirical Model Building and Response Surfaces. New York:
Wiley, 1987.
35
References, continued
9. Hightower, Joseph, “Establishing Model Credibility Using Verification and
Validation”, INCOSE MBSE Workshop, IW2017, Los Angeles, January, 2017.
http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:incose_mbse_iw_
2017:models_and_uncertainty_in_decision_making_rev_a.pptx
10.Beihoff, B., et al, “A World in Motion: INCOSE Vision 2025”, INCOSE.
11.Schindel, W., “What Is the Smallest Model of a System?”, Proc. of the INCOSE 2011
International Symposium, International Council on Systems Engineering (2011).
12.Schindel, W., and Dove, R., “Introduction to the Agile Systems Engineering Life Cycle
MBSE Pattern”, in Proc. of INCOSE 2016 International Symposium, 2016.
13.Schindel, W., “Got Phenomena? Science-Based Disciplines for Emerging Systems
Challenges PBSE methodology summary”, Proc. of INCOSE IS2017 Symposium,
Adelaide, UK, 2017.
14.Schindel, W., “Requirements Statements Are Transfer Functions: An Insight from
MBSE”, Proc. of INCOSE IS2005 Symposium, Rochester, NY, 2005.
15.INCOSE MBSE Initiative Patterns Working Group web site, at
http://www.omgwiki.org/MBSE/doku.php?id=mbse:patterns:patterns
16.INCOSE Patterns Working Group, “MBSE Methodology Summary: Pattern-Based
Systems Engineering (PBSE), Based On S*MBSE Models”, V1.5.5A, retrieve from:
http://www.omgwiki.org/MBSE/doku.php?id=mbse:pbse
36
Speaker
37
William D. (Bill) Schindel chairs the Model-Based Systems
Engineering Patterns Working Group of the INCOSE/OMG MBSE
Initiative. An ASME member, he is part of the ASME VV50 standards
team’s effort to establish guides and standards for model
verification, validation, and uncertainty quantification. Schindel is
president of ICTT System Sciences, and has practiced systems
engineering for over thirty years, across multiple industry domains.
He earned the B.S. and M.S. degrees in mathematics, and is an
INCOSE Fellow and Certified Systems Engineering Professional.