Incose Sweden Model Management01292011 V8

Model-based
Model based Engineering in
Medical Device Development –
p
Issues & Solutions
INCOSE Sweden
Linkoeping
April 4 2011
4,

© Siemens AG 2011. All rights reserved.

Contents

 Goals

 Brief look on Siemens Healthcare

 Business challenges

 Model-based Engineering: Issues & Solutions
Model based

 Recommendations

 Further Information

Page 2 Arnold Rudorfer, Siemens Healthcare Imaging & Therapy SYNGO

Contents

 Goals



 Model-based Engineering: Issues & Solutions
Model based

 Results and Summary



Goals f thi T lk
G l of this Talk

 Disc ss the e periences
Discuss experiences
using engineering models (in
different phases of product
development of a next
generation imaging platform)
 Identify and share needs and
requirements with colleagues
from diverse industries to
advance product
d d t
development tooling


Contents

 Goals



 Model-based Engineering: Issues &
Model based
Solutions

y



Siemens Healthcare
THE Integrated Healthcare Company
I t t d H lth C

in-vivo diagnostics (imaging)

X-Ray Computed Magnetic Molecular Ultrasound Oncology
Tomography Resonance Imaging

syngo.via
in-vitro
in vitro diagnostics (laboratory systems)

Immunodiagnostics Nucleid Acid Clinical Chemistry Hematology Urin Lab Automation Near Patient
Testing Analysis Testing


Example: syngo.mCT Oncology:
Oncology Workflow: Tumor Detection, Staging
O l W kfl T D t ti St i

Automated Case Preparation Disease Oriented
Disease-Oriented Reading Multi Modality
Multi-Modality Access

 Automated bone and bloodpool  Preferred layout applied  Image fusion for CT, PET, and
removal  Automated lesion segmentation MR images, etc.
 Automated sorting of images, etc.  Automatic loading of prior exams, etc.

Courtesy of University Hospital of Munich-Grosshadern/ Munich, Germany © Siemens AG 2011. All rights reserved.
syngo.mCT Oncology is cleared in theRudorfer, Siemens Healthcare Imaging & Therapy SYNGO
Page 7 Arnold U.S. with syngo.PET&CT Oncology.

Contents

 Goals

 Brief look on Siemens and Vector
Healthcare

 Project syngo.via
Business Challenges

 Business challenges Issues & Solutions
Model Management:

 Lean Requirements Engineering
Results and Summary

 Results Information
Further and Summary



Business Challenges in Medical Device Industry
B i Ch ll i M di l D i I d t

Industry Cycle time
regulations down

Complexity
Costs down growth
Need to
industrialize
product
development
Focus of this talk

Platforms
Application Life-cycle Model-based
Management Tools Engineering
Globally Integrated
Clinical Workflows

Disclaimer:
The content discussed in this presentation needs
to be considered as work in progress
progress.


Contents

 Goals


SYNGO products


 Lean Requirements Engineering
Model-based Engineering: Issues & Solutions




syngo.via Product
i P d t

Project Summary
syngo.via: Next generation
imaging software covering the
g g g
entire reading process

Project data:
> 5,000 single product
requirements
Several million lines of code
C++/C#
Several hundred developers in
many locations
Clinical applications f
Cli i l li ti for
Radiology, PACS, X-Ray, CT,
PET/SPECT, Oncology, Particle
Therapy and MRMR.

Industry I
I d t Issues and Pain Points
dP i P i t

Pain Points Business Impact
 Product structure Technology-driven product platform, no link to business
intransparent, domain drivers
model partially incomplete  Opaque relationship between problem & solution space
 Re-scoping sessions w/ customers on basis of many specs.
 Ambiguity and lack of Textual-based specifications are subject to interpretation
accuracy of specifications
y p  Textual use case descriptions work only for smaller p j
p y projects
 Natural language subject to interpretation, inconsistent,
incomplete
 Controlling architectural Redundancy of architecture components due to lack of
complexity understanding of problem- and solution space
 Business needs not consistently linked to features
 Too much variability in software architecture
 Lack of V&V efficiency Test specifications in natural language are mostly
executed in a manual way only
 Test cases manually created
 Thousands of pages of requirements


Pain point 1: Product Structure Intransparent,
Domain M d l Partially Incomplete
D i Model P ti ll I l t

Solutions:
S l ti
Selected issues:
 Opaque relations between A. Requirements Engineering
problem
problem- & solution space Meta-model
 Re-scoping sessions w/ B. Feature Model
customer on basis of many
engineering specs.
g g p


Solution A: Requirements Engineering Meta Model
–B
Benefits & T l Requirements (1)
fit Tool R i t

Problem Space DB
Characteristics:
Stakeholder  Provides needed artifacts, their
Business Plan Request attributes and relationships to each
Market Analysis,
SW Platform Roadmap,
other.
other
input for
Business Case, etc.  Using meta-model, it is also possible to
input for prescribe the way how / which data are
captured .
MRS
SW Feature
Analysis
Benefits:
Market analyzed Use Case Specifications,
Requirement by Load Profiles,  Lean artefact infrastructure, no
Concept Papers
redundancy
SWRS
 Guidance for engineering tasks
SW Req.
(Problem) with structured input
SW Req.  Established link between business
(Solution)
drivers, requirements, design and
Specification/
Structural Element Content
Mapping or
pp g test
Document Input


–C
Concepts (2)
t

Stakeholder A Feature represents a characteristic of a product which
Feature
Request provides a business value and supports purchase decisions […].
A Feature structure requirements in a meaningful way and is no
specification in itself (only “container”).

Feature Feature A Feature Model is a hierarchical "tree" to describe the
structure, dependencies, commonalities and variabilities of
Features within a product or product line (e.g. SW Platform,
Finished Medical Device).
SW Feature SW Feature
Requirements specify the Feature. They represent the
functionality already implemented within the product and
Market functionality that is planned for future versions. Depending on the
Requirement project phase requirements are less or more detailed (e g
(e.g.
Market Req., SW Req.).
SW
Requirement Stakeholder Requests are wishes towards an existing or future
product. Stakeholder Requests (SR) are gathered from various
sources (e.g. end customer, business units) and may have an
impact on different levels and phases of the product lifecycle .


–C
Concepts (3)
t

Problem Space Solution
Sol tion Space
DB
Business Plan
Stakeholder
Market Analysis, Request
Roadmap,
Roadmap Business Case
Case,
Version Goal

input for input for

MRS
SW Feature
Analysis
Requirement
R i t by
Load Profiles,
Concept Papers, etc.
Architecture

SWRS Architectural
CDS
SW Req.
(Problem) Build. Block
realizes
SW Req. Design
(Solution) Description


–C
Concepts (4)
t

Sol tion Space
DB
Business Plan
Stakeholder
Roadmap,
Case,
Version Goal Example: Feature - „Demo of Images“

input for input for
Market Requirement: As a Clinician, I
want to mark images to support
MRS presentations for a medical conference.
SW Feature
Analysis
Requirement
R i t by
Load Profiles,
Architecture

SWRS Architectural
CDS
SW Req.
realizes
SW Req. Design


–C
Concepts (5)
t

Sol tion Space
DB
Business Plan
Stakeholder
Roadmap,
Case,
Version Goal

input for input for Use Case: „Demo of Images“ with
activity diagram to derive software
requirements.
i t
MRS
SW Feature
Analysis
Requirement
R i t by
Load Profiles,
Architecture

SWRS Architectural
CDS
SW Req.
realizes
SW Req. Design


Solution B F t
S l ti B: Feature Model
M d l

Highest Level
Characteristics:
 Hierarchical tree to describe the
structure, dependencies and
commonalities
liti
 Lays out the basics for variant
management and impact analysis

Benefits:
 Higher level abstraction of grouping
Graphical View
of requirements into sellable units:
From 5,000 product requirements
to 800+ features (factor ~ 6)
 Visual domain model for healthcare
workflows (tree & graphical)
 Reduction in time to understand
aspects of the system
Hierarchical View
Hi hi l Vi


Solution B F t
S l ti B: Feature Model & Its Relations (1)
M d l It R l ti

Stakeholder Requests Application Use Cases
How can I manage
H
huge amounts of
Requirements?

How do I scope a
product version
efficiently?

Architecture Model


Solution B F t
S l ti B: Feature Model & Its Relations (2)
M d l It R l ti


How do I manage
Architecture Model
stakeholder requests
from different
businesses most
effectively?


Pain point 2: Ambiguity and Lack of Accuracy of
Specifications
S ifi ti

Level Requts. Manually Manual test
Object Embedded graphs case creation
Issues:
 Textual use case descriptions work only
for smaller projects < ~ 100 Document Requt. 1 Picture / diagram
(text)
requirements
 Natural language subject to Features Requt. 2 Picture / diagram
interpretation, usually inconsistent, (text)
incomplete with inccorrect version (and
p (
conflicting) Paragraph Requt. 3 Picture / diagram
(text)
Root causes:
 T t l requirements engineering d not
Textual i t i i do t
scale for platform projects Solutions:
 Missing versioning
 No direct access to single requirements C.
C Application Use Cases
 Lack of product structure
 Inconsistently executed change
management process


Solution C: Graphical Modeling of Clinical
Workflows (1)
W kfl

Characteristics:
 Used to describe clinical workflows that
consist of a collection of steps in a defined
sequence together with accompanying
specification of pre-/post-conditions,
business rules, performance aspects, etc.

Benefits:
B fit
 Increase expressiveness of clinical
workflows to describe dynamic behaviors
of clinical workflows
f li i l kfl
 Early analysis of stakeholder requests
from customers
 Improved impact analysis of change
requests
 Joint modeling sessions to describe the
needs from the customer s point of view
customer‘s


Solution C: Graphical Modeling of Clinical
Workflows (2)
W kfl


How can I analyze a Model
Architecture
feature or a
stakeholder request?


Pain i t 3 C t lli A hit t
P i point 3: Controlling Architectural Complexity
lC l it

Selected issues: Solutions:
 Business needs not consistently
linked to features/ requirements; D.
D Architecture Model Mapping
dependencies between features not
easily visible
 Too much variability in software
architecture

Solution D: Architecture M d l Mapping
S l ti D A hit t Model M i

F Feature Model Characteristics:
 Identifies links between features and their
F F F
implementation
 Explicit modeling of variability in the architecture
SWF SWF SWF SWF SWF SWF SWF

S Architecture Model

Benefits:
SS SS SS
 Architectural decisions motivated by features
and product-line variability
C C C C C C

 Enabling reduction of architectural complexity

 Support impact analysis for (de-) scoping
sessions
 Early identification of architectural risks

 Improved accuracy of early effort estimates

 Reduction of number of scoping sessions


Solution D: Architecture M d l Mapping
S l ti D A hit t Model M i


Architecture Model

Which component
p
implements which
feature?


Pain i t 4 N d to Increase V&V Efficiency
P i point 4: Need t I Effi i

Issues:
 Test cases partially manually Solutions:
generated from prose use cases
 C l ti
Cycle times f system t t too long
for t test t l E. Model-based S
E M d lb d System T
Test
 Compliance requirements QSR 21
CFR 820, ISO 13485:2003, EU MDD
93/ and other ed ca device
93/42 a d ot e medical de ce
software regulations.

Solution E: Model-based System Test (2)
S l ti E M d l b dS t T t

Benefits:
B fit
 Early identification of requirements
defects through validation by testers
 Effort reduction for test (cycle time,
cost ~ -30%) and increase of test
coverage (*)
 Decrease number of defects
 Model-based testing is highly
structured, reproducible and efficient
p
 Increase reuse of development
artifacts
 Quicker impact analysis by parsing
model for late requirements changes

(*) Based on experience from other projects


Solution E: Model-based System Test
S l ti E M d l b dS t T t


Architecture Model

Which application
use case is covered
by which test case?


Focus o Requirements Engineering …
F R i t E i i

Sync between tools
Problem Space Master
M t Slave
Sl
Solution Space
(Features & Requirements) (Architectural Building Blocks)

MRS
Architectural
Enterprise SW Feature
Build. Block Enterprise
realizes
Architect Architect
Market
Requirement

SWRS CDS
Caliber RM SW Feature Architectural
Build. Block
SW Req.
Req realizes* Design
(Problem)
Description
SW Req.
(Solution) Caliber RM Together


Contents

 Goals


SYNGO products


 Lean Requirements Engineering & Solutions
Model-based Engineering: Issues

Results and Summary



Major Changes to Development Approach
Model-based Engineering
M d lb dE i i

 Requirements Engineering Meta
Meta-
Model
 Feature Model
 Graphical Modeling of Clinical
Workflows
 Architecture Model Mapping
 Model-based System Test

Note: syngo.via


Benefits f
B fit from M d l b
Model-based Engineering
dE i i


Results
Business C
B i Case – C t ib ti
Contribution of Levers
fL

Description of Benefit Distribution of
Benefits
 Tracing with less effort (based on 25%
Defnition
uct

feature model‘s nature no verticals)
model s nature,
Produ

 More effective stakeholder management (less scoping
sessions, reduction in review times and effort)
 Transparency and easy overview on product functionality 23%
Planning
Project

 Reduction of product complexity (transparent modeling of 7%
Design

product lines and product variability)
D

More effective Testing 45%
Test

Easier bug-fixing
Source: OREA Business Case, February 2011 (to be expected)

Results
Business C
B i Case – NPV P j ti
Projection

B
Benefits are realized across
fit li d
engineering workflows: Product
Definition, Project Planning, Design
and Test
 Break-even reached in 2nd year
 Hints for other RE practitioners:
 Business case can only be carried out
with a complete technical concept
 Sensitivity analysis done on risks
shows that the effort is worthwhile
even when everything goes wrong.
 Business case will vary depending on
lccal circumstances

Source: OREA Business Case, February 2011 (to be expcetd)


Key Take-Aways f M d l b
K T k A for Model-based Engineering
dE i i

 Modeling competence of prod ct managers needs to be b ilt up step
product built p step-
by-step thereby facilitating acceptance of new approach
 Seamless model-driven engineering is only partially tool-supported;
model driven tool supported;
the biggest gap remains in requirements engineering.
 Tool vendors need to stronger leverage the experience of leading
development organizations and uptake it into technology roadmaps.
 Acceptance of model-based engineering is a huge organizational
change management endeavor, only 10% of organizations have
h t d l f i ti h
already gained practical experience.
 Continuous assessment and verification of business benefits for
model-based engineering is a must to maintain sponsorship from
management.


Thank
Th k you for your attention!
f tt ti !


Contents

 Goals


SYNGO products


 Lean Requirements Engineering & Solutions
Model-based Engineering: Issues


Further Information


References
R f

 US Food & Drug Administration, Design Control Guidance for Medical Device Manufacturers; March 11 1997
Administration 11,
 US Food & Drug Administration, Quality System Regulation,; January 1, 1997, http://www.fda.org/cdrh/qsr/01qsreg.html
 Brian Berenbach, Daniel Paulish, Arnold Rudorfer, Juergen Kazmeier, Software Systems Requirements Engineering; Mc-Graw Hill
2009; http://www.mhprofessional.com/product.php?isbn=0071605479
 Renate Loeffler: Formal Scenario-based Requirements Specification and Test Case Generation in Healthcare Applications,
Diplomarbeit, Univ. Paderborn, 10/2009
 Siemens Healthcare Imaging & Therapy SYNGO: Optimized Requirements Engineering Approach, Siemens Healthcare, 2010
 Siemens Healthcare Imaging & Therapy SYNGO: Microsoft Team Foundation Server Business Case May 2010
Case,
 Medical Device & Diagnostic Industry 101, Carey Smoak, Roche Molecular Systems Inc., Pleasonton, CA, Pharma SUG 2010,
Paper 1B01
 Arnold Rudorfer, Christof Ebert: Lean Requirements Engineering in Medical Systems, MedConf 2010, Munich, Germany, October
14,
14 2010; http://2010 medconf de/downloads/abstracts2010/T2 T3 V1 vector siemens pdf
http://2010.medconf.de/downloads/abstracts2010/T2_T3_V1_vector_siemens.pdf
 Arnold Rudorfer, Christof Ebert: Quality Requirements Engineering in in Medical Systems, OOP11, Munich, Germany, January 27,
2011 http://www.sigs.de/download/oop_2011/downloads/files/Do2-3_Ebert_Rudorfer_Update_QualityRE_OOP2011.pdf
 Arnold Rudorfer: Model-based Engineering in Medical Device Development – Issues & Solutions, INCOSE Workshop, Phoenix, AZ,
USA, January 31, 2011,
http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:2011iw_incose_modelmanagement_rudorfer.pdf
 Siemens Healthcare Imaging & Therapy SYNGO: Optimized Requirements Engineering Approach Business Case, February 2011


syngo
The C t l I
Th Central Image Hub In H lth
H b I Healthcare W kfl
Workflows

More patient exams Sound diagnoses
in less time* in less time*

Efficient i
Effi i t image Smooth and fast
S th d f t
creation, usage, collaboration
archiving,
and sharing

syngo. It s all about you.
It’s
*Results may vary. Data on file.


Arnold Rudorfer
Director Software Initiative and
Process Improvement
Siemens AG Healthcare Sector

Hartmannstrasse 16
D-91052 Erlangen

Phone: +49 9131 – 84 2299
Fax: +49 9131 – 84 8691
Mobile: +49 174 1537825

Email:
arnold.rudorfer@siemens.com


Incose Sweden Model Management01292011 V8

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (16)

Similar a Incose Sweden Model Management01292011 V8

Similar a Incose Sweden Model Management01292011 V8 (20)

Más de Arnold Rudorfer

Más de Arnold Rudorfer (12)

Incose Sweden Model Management01292011 V8