more agile than agile sedc 2014 april 5, 2014 zane scott, vp for professional services vitech...

More Agile than Agile

SEDC 2014April 5, 2014

Zane Scott, VP for Professional ServicesVitech Corporation

Vitech Corporation 2

THESIS: A layered approach to model-based systems engineering promotes the concepts and principles of agile development and is arguably even MORE AGILE THAN AGILE!


The Agile Manifesto

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan


The Agile Manifesto

• Individuals and interactions over processes and tools

• Working solutions over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan


Agile Principles

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.• Build projects around motivated individuals. Give them the environment and support they need, and

trust them to get the job done.• The most efficient and effective method of conveying information to and within a development team is

face-to-face conversation.• Working software is the primary measure of progress.• Agile processes promote sustainable development. The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.• Continuous attention to technical excellence and good design enhances agility.• Simplicity--the art of maximizing the amount of work not done--is essential.• The best architectures, requirements, and designs emerge from self-organizing teams.• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts• its behavior accordingly


Agile Principles

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.• Build projects around motivated individuals. Give them the environment and support they need, and

trust them to get the job done.• The most efficient and effective method of conveying information to and within a development team is

face-to-face conversation.• Working software is the primary measure of progress.• Agile processes promote sustainable development. The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.• Continuous attention to technical excellence and good design enhances agility.• Simplicity--the art of maximizing the amount of work not done--is essential.• The best architectures, requirements, and designs emerge from self-organizing teams.• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its

behavior accordingly


Principles

• Our highest priority is to satisfy the customer • We welcome changing requirements• Deliver working solutions frequently.• Stakeholders and solution designers must work together daily • Build projects around motivated individuals. Give them the environment

and support they need, and trust them to get the job done. • Working solutions are the primary measure of progress.• Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity--the art of maximizing the amount of work not done--is essential.


WHAT IS LAYERED MBSE?


Begin High

• Innovation• Vision• Alternatives

Innovation

Inspiration Ideation Validation

Num

ber

of

Pro

toty

pes

Time Spent Developing Prototypes


Vision


Alternatives

Q

Vitech Corporation

Alternatives

14

Q


Alternatives

Q


What about middle-out?

EXC

UR

SU

S

• Get high!


MBSE Activities Timeline – Top Down

Activity bars represent movement of “center of gravity” of systems engineering team.

Concurrent engineering is assumed.

5. Derive Integrated System Behavior

6. Derive Component Hierarchy

0. Define Need & System Concept

1. Capture & AnalyzeOrig. Requirements

2. Define System Boundary

4. Derive SystemThreads

3. Capture OriginatingArchitecture Constraints

8. Define InternalInterfaces

11. Define Resources, Error Detection, & Recovery Behavior

12. Develop Validation Requirements/Validation Plans

9. Select Design

13. Generate Documentation and Specifications

7. Allocate Behavior toComponents

10. Perform Effectiveness & Feasibility Analyses

SCHEDULE


MBSE Timeline – Reverse/Middle Out

7. Derive As-Built System Requirements

1. Define System Boundary

5. Aggregate to As-Built System Behavior

4. Derive As-Built Behavior of Components

3. Capture ComponentHierarchy

2. Capture Interfaces

6. Derive As-Built System Threads

11. Capture Error Detection, Resource, & Recovery Behavior

12. Develop Test Plans

9. Select Design

13. Generate Documentation and Specifications

10. Perform Effectiveness & Feasibility Analyses

6a. Modify System Threads

5a. Modify & Decompose System Behavior

4a. Allocate Behaviorto Components

3a. Refine ComponentHierarchy

2a. Define Interfaces

Find the top,Then modify top-down.7a. Modify Reqts &

Arch. Constraints

8. Update System Boundary

SCHEDULE


Work In All 4 Domains

• Don’t forget• Eliminate rework


Work In All 4 Domains

All four domains

At every layer


It’s All About Relationships

basis of

based on

allocated to

performs

Requirements Behavior Components

Requirements are the basis of Behavior Behavior is allocated to Components

Behavior is based on Requirements Components perform Behavior

Verify and Validate


Advance Granularity

• Orderly decisions• Completeness at every layer


Increasing Granularity

REQ

BEH

ARCH

Dgn V&V

REQ

BEH

ARCH

Dgn V&V

Layer Of DetailSource Documents

Docs

Docs

REQ

BEH

ARCH

DgnV&V

Docs Docs

Docs

LAYER 1

LAYER 2

LAYER n


SOME ISSUES AROUND MODELS


What is a Model?

• What is NOT a model?• What is a model?

26

Views Are NOT a Model

• Views flow from the model

Vitech Corporation

27

What is a View?

• A structured answer to a request for a particular subset of information from the model

Vitech Corporation

28

What is a View?

Vitech Corporation

query

answer

Model

29

What is a View?

Vitech Corporation

query

answer

Model


Many Models? NO!

Requirements

Behavior

ArchitectureTesting


Power in the Interactions

Behavior

ArchitectureTesting

Requirements

MODEL


As Designed

As Reported

As Heard

As Tested

The Testing Problem


Models in MBSE

• Models– Are limited representations of a system or process– Can be migrated into a cohesive unambiguous

representation of a system• In model-based systems engineering– The ‘model’ is the system specification; conversely the

system specification is the model– The visualizations are derived from the model– The model rests on the logical architecture (function)


MBSE MEETS AGILE


Principle 1

• The customer is key• Validation at every layer• Traceability

Highest priority = satisfy the customer

36

Full Traceability(Bi-directional)

Vitech Corporation

REQUIREMENT:The system shall provide

previously collected images/products, if appropriate.

FUNCTION:The system shall provide

previously collected images/products, if appropriate.

IS THE BASIS OF

IS ALLOCATED TO

IS BASED ON

PERFORMS

ARCHITECTURE


Principle 2

• Changing requirements don’t disrupt the orderly layer-to-layer transitions

• Model holds everything in relationship

Welcome changing requirements


Change

Model

Requirements

V & V

Physical Architecure

Behavior


Principle 3

• The end result of each layer is a complete model

Deliver working solutions frequently


Increasing Granularity

REQ

BEH

ARCH

Dgn V&V

REQ

BEH

ARCH

Dgn V&V

Layer Of DetailSource Documents

Docs

Docs

REQ

BEH

ARCH

DgnV&V

Docs Docs

Docs

LAYER 1

LAYER 2

LAYER n


Principle 4

• By surfacing the model everyone can see it• Choosing the appropriate view

Stakeholders and designers work together

42

• Who are they and what will speak to them?

• What do they need (want) to know?• What do we need them to know?

Vitech Corporation

Which View?


Principle 5

• Teams can collaborate in real time• Model provides the discipline• Team focuses on problem solving

Give teams needed environment & support

MODEL


Principle 6

• Verify and validate at every layer

Measure of progress is working solutions



V&V


Principle 7

• Work is orderly• Model manages complexity• Problem does not become overwhelming

Maintain a constant, supportable pace


Consistency

Independent drawings v. Consistent views

MODEL


Principle 8

• Model insures integrity and completeness• Design decision are intentional

Technical excellence & good design


One Integrated Model

DataData DataData

verified by

Source Requirements Domain

Architecture Domain

Behavior Domain

V&V Domain

verified by

Originating requirementstrace to behavior

Originating requirements trace to physical components

Behavior is allocated tophysical components

verified by

c

DataData


Principle 9

• Because views and documentation are generated by querying the model there is no need for repetitious clerical work

• Pieces of the model can be reused

Maximize the amount of work not done


MANIFESTO VALUES


Values

• Model focuses the work on design tasks instead of repetition and documentation work

• Engineers are freed to be engineers• Communication is enhanced

Individuals and interactions


Values

• Focus is problem solving- not drawing views or creating documents

Working solutions


Values

• Views can be generated that:– Show the state of the model in real time– Are tailored to the audience

Customer collaboration


Values

• Model holds everything in relationship• Impact of change is immediately traceable

Responding to change


SUMMARY


MBSE Benefits to the Enterprise

• Enhanced communication– Shared understanding– Rich representations

• Reduced development risk– Early identification of requirements issues– Faster requirements cycle– Improved cost estimates– Early/on-going requirements validation & design

verification– Disciplined basis for decision making


• Improved quality– Enhanced system design integrity– Improved specification of allocated requirements to HW/SW– Fewer errors during integration and test– More rigorous traceability from need through solution

• Increased productivity – Improved impact analysis of requirements changes– Rapid analysis of design changes– Reuse of existing models to support design/technology

evolution– Auto-generation of work products




• Increased scope– Incorporation of domains– Integration of models– Extension of representations and audiences

• Provides a structure to capture and communicate all aspects of the system


Thank You!

For additional information:Zane Scott

Vitech Corporation2270 Kraft Drive, Suite 1600Blacksburg, VA, 24060, USA

[email protected]

more agile than agile sedc 2014 april 5, 2014 zane scott, vp for professional services vitech...

Documents

agile manifestoindividuals

agile processes harness

development team

toolsworking software

sustainable development

continuous attention

couple of months

couple of weeks