mbse in a lean context - ida > home

MBSE in a Lean Context

Agenda:

9.15 – 10.45

• MBSE – what and why

• Model Driven Architecture

• Lean Product Development, an overview

• Waste in Product Development

11.00 – 12.00

• Value Stream Mapping

• Agile and MBSE

Different kinds of complexity

• Functional complexity

• Combinatorial complexity

• Dynamic complexity

Different kinds of engineering challenges

• Systems Engineering

� Ensuring feature functionality and customer attributes, understanding the increasing complexity & inter-dependenceof systems early in development process, in areas such as interaction between mechanical & electronic systems, and performing robustness analysis to ensure system quality

• Software Engineering

� Assure that the design process takes all architectural strategies and stakeholder requirements into account to deliver robust, reusable, maintanable and error free system content

Higher Precision Early by modelling

!

Pre

cisio

n in

description

MBSE

“spec”

=> code

solution space

solution space

Modell Based Development – a definition

• The majority of information handled and created in development projects is stored, processed, developed and used in models

• The model is the orignal source of information. Reports and documents for review, inspection or information transfer are generated from the model

• Model based development requires tool support.

Model Driven Architecture

Discussion: Modelling Context

How many modelling languages and tools are used by the people in this room?

Primarily Systems or Software Engineering?

Lean Product Development

• Lean Thinking principles can be applied to any business process to achieve measurable improvements in customer satisfaction, output, lead time, and resource effectiveness.

• Development performance is often crucial for company competitiveness

Lean Principles:

Long-Term Philosophy

Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals

Lean Principles:

The Right Process will Produce the Right Results 1(2)

• Create continuous process flow to bring problems to the surface

• Use "Pull" systems to avoid overproduction

• Level out the load(Heijunka)

• Build a culture of stopping to fix problems, to get quality right the first time

Lean Principles:

The Right Process will Produce the Right Results 2(2)

• Standardized tasks are the foundation for continuous improvementand employee empowerment

• Use visual control so no problems are hidden

• Use only reliable, thoroughly tested technology that serves yourpeople and process

Lean Principles:

Add Value to the Organisation by Developing Your People and Partners

• Grow leaders who thoroughly understand the work, live the philosophy and teach it to others

• Develop exceptional people and teams who follow your company's philosophy

• Respect your extended network of partners and suppliers by challenging them and helping them improve

Lean Principles:

Continuously Solving Root Problems Drives Organizational Learning

• Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu)

• Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly

• Become a learning organisation through relentless reflection (Hansei) and continuous improvement (Kaizen)

Group Discussion

How can MBSE be used while following the Lean Principles?

Waste – Unevenness and Overburden

• Overloaded resources

• Task-switching, many parallel projects

Waste – Over production

• Too much detail

• Unnecessary information

• Excess requirements/features

• Reinvention

• Unintegrated design, no product family management

Waste – Transportation

• Information/Software incompatibility

• Communications failure

• Not standards based information

• Multiple sources

• Incompatible destinations requiring multiple transport

Waste – Waiting

• Information created too early

• Late delivery of information

• Unavailable information

• Quality suspect

T e c h n o w l e d g e

Waste - Processing

• Unnecessary serial processing, workflow dictated by processes rather than need

• Lack of needed information

• Poor/bad decisions affecting future, ineffective risk management

Excercise

A.Describe your normal Product Development workflow.

If you are using MBSE, how has this influenced the flow of information through the organization?

If not, how would you anticipate MBSE to influence the workflow?

Excercise

B.Describe your normal Product Development workflow.

If you are using MBSE, how has this influenced the flow of information through the organization?

If not, how would you anticipate MBSE to influence the workflow?

Increasing the knowledgelevel to avoid waste Knowledge Value

Stream

Product Value

Stream

The organizationalprerequisites for a new projectis the knowledge built during

previous projects. If this prerequisite is not fulfilled at the start of the project, the

project will pay for re-buildingthe necessary knowledge =

knowledge waste.

Necessarylevel of increasedknowledge

Product Development

Product Development

Knowledge Wasteis created by

• Not completing product documentation

• Not explicitly letting senior employees coach junior collegues in a systematic way

• Not building the project teams with the right mixture of competence

• Not performing qualitative reviews of work products

• Not controlling and giving time to individual and collective reflection

• Not updating and maintaining process and method descriptions

• Not giving systematic training and introduction to new employees

• Not allowing sufficient time and money for training courses for employees

• Not minimizing the number of handovers in the process

• ...

Group Discussion

How can MBSE aid us in minimizing knowledge waste?

Agile or Prescriptive- adapting to change vs. trying to avoid it

DEVELOPMENT ORGANISATIONS

ADAPTIVE PRESCRIPTIVE

Agile or Prescriptive- adapting to change vs. trying to avoid it

PRODUCT COMPLEXITY

ADAPTIVE PRESCRIPTIVE

SW Impl &

Test

Verify

SW

Integration

Test

Final

System Test

Code

Review

Update

SWRS

Process Handovers in the Process Today

System

Design

Colours indicate different functional teams.

SW Impl &

Test

Verify

SW

Code

Review

Integration

Test

Final

System Test

Update

SWRS

Development in X-Functional Teams

System

Design

Colours indicate (possibly) different functional teams.

The Agile Manifesto

Individuals and interactions over

Working software over

Customer collaboration over

Responding to change over

processes and tools

comprehensivedocumentation

contract negotiation

following a plan

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

That is, while there is value in the items on the right, we value the items on the left more.

MBSE and Agile Practices

• Pair programming

• Test Driven Development

• Continuous Integration

• Behaviour Driven Development