obstacle driven development models

36
Obstacle Driven Development ODD Models

Upload: jonathan-herring

Post on 16-Apr-2017

78 views

Category:

Engineering


6 download

TRANSCRIPT

Page 1: Obstacle Driven Development Models

Obstacle Driven DevelopmentODD Models

Page 2: Obstacle Driven Development Models

Testing First?

15/07/2016 ©odd.enterprises 2

Answering a question before its asked is like creating a solution before a test.

Page 3: Obstacle Driven Development Models

Problem Driven Development

Problem Driven Development combines Test Driven Development with V-models.

• Requirements analysis is separate stage

• Specification in the form of various levels of testing

15/07/2016 ©odd.enterprises 3

Page 4: Obstacle Driven Development Models

Problem Driven Development

Colour is changed to represent the colours of traffic lights.

• Tests are linked to abstraction levels of the stages

• Suitable for research purposes

15/07/2016 ©odd.enterprises 4

Page 5: Obstacle Driven Development Models

Problem Domain Development

Problem and solution domains describe the stages.

• Specification is an interface between the stages

• Expanding the interface allows increased testing

15/07/2016 ©odd.enterprises 5

Page 6: Obstacle Driven Development Models

N-model Comparison

Problem Driven Development creates an N-model to combine a V and inverted V-model.

• Comparison against Problem and Solution domains

• Specification allows testing of ideas before they are created

15/07/2016 ©odd.enterprises 6

Page 7: Obstacle Driven Development Models

Obstacle Driven Development Stages

Adding a Production stage created Obstacle Driven Development with Solution to be produced.

• Solutions designed in labs may not work in practice

• Production ensures Solution is produced with quality assured and controlled

15/07/2016 ©odd.enterprises 7

Page 8: Obstacle Driven Development Models

Stages Verification + Validation

Between each stage of Obstacle Driven Development there are tests created to verify and validate.

• Verify is creating a test to ensure it’s built in the right way

• Validate is passing a test to ensure it’s built right

• Adapted as necessary between other stages

15/07/2016 ©odd.enterprises 8

Page 9: Obstacle Driven Development Models

Stages Verification + Validation

Verification and Validation gives 2 directions of information flow with feedforwards and feedback.

• Each stage is linked to the next through creating tests

• Each stage is linked to the previous through passing tests

• Feedforwards for progress

• Feedback for correction

15/07/2016 ©odd.enterprises 9

Page 10: Obstacle Driven Development Models

Stages + Domains

Production gives another stage to the Problem and Solution domain with Quality Assured and Controlled.

15/07/2016 ©odd.enterprises 10

Page 11: Obstacle Driven Development Models

M-model Development

15/07/2016 ©odd.enterprises 11

Extending the N-model with Production creates the M-model.

• Checkpoints added to consolidate each stage with output

• Tests created and passed between each stage

Page 12: Obstacle Driven Development Models

M-model Development

M-model provides a path for development with Verification and Validation through tests.

• Stages are alternatively built up and broken down

• Ascending slope indicates integration

• Descending slope indicates decomposition

15/07/2016 ©odd.enterprises 12

Page 13: Obstacle Driven Development Models

Domains + M-model

Stages designed to model the problem domain with testing between each.

• Overlap represents testing between stages

• Creating and solving tests acts as interface between stages

• Operates similarly to Test Driven Development

15/07/2016 ©odd.enterprises 13

Page 14: Obstacle Driven Development Models

M-model Elements

M-models divided into stages and abstraction levels to give elements.

• Stages contain all required elements

• Creating through integration or decomposition

• Suppliers may supply lower level products

15/07/2016 ©odd.enterprises 14

Page 15: Obstacle Driven Development Models

M-model Elements

Stages of the model are divided into elements through abstraction levels and system divisions with each having a specific place.

15/07/2016 ©odd.enterprises 15

Page 16: Obstacle Driven Development Models

Stages + Process

15/07/2016 ©odd.enterprises 16

Stages are created using a process of creating and solving tests.

• Process the same for each stage but different methods to achieve solutions

• Solutions to a stage become obstacles to the next

• Stages

Page 17: Obstacle Driven Development Models

Stages + Process

15/07/2016 ©odd.enterprises 17

Solutions to each stage (in blue) become obstacles (in red) to link the next stage.

• Stages are both solutions and obstacles

• Stages repeated until obstacles are solved

Page 18: Obstacle Driven Development Models

Process + Verification + Validation

Verification and validation is performed between each stage through creating and solving tests.

• Creating a test first ensures we are building the right thing

• Solving a test ensures we are building it right

• We modify prior stages when we determine errors with them

15/07/2016 ©odd.enterprises 18

Page 19: Obstacle Driven Development Models

OODA Inspired M-model

ODD combined with the OODA model (Observe, Orient, Decide, Act).

• Illustrates feedback to the Analysis stage

• Shows importance of a Specification to development

• Decision block before entering Production

15/07/2016 ©odd.enterprises 19

Page 20: Obstacle Driven Development Models

Abstraction Levels

Abstraction levels help obstacles and solutions link at all levels.

• Divides development into appropriate levels

• High level abstractions are integrated from lower levels

• Lower level abstractions are decomposed from high levels

15/07/2016 ©odd.enterprises 20

Page 21: Obstacle Driven Development Models

Systems Division

Abstraction levels are further divided into individual systems and their lower levels.

• Helps separate systems from others for easier testing and integration

• Systems division is modelled throughout stages

15/07/2016 ©odd.enterprises 21

Page 22: Obstacle Driven Development Models

3D Pyramid Model

Combining models gives a 3D model with Stages, Abstraction levels and System Divisions.

• Progress on x-axis

• Abstraction levels on y-axis

• Systems division on z-axis

15/07/2016 ©odd.enterprises 22

Page 23: Obstacle Driven Development Models

Linking Models

Models are linked end to end to allow development to continuously improve.

• Models linked for new products or creating improved versions

• Combine as many models as necessary

• Obstacles, tests and solutions can be reused

15/07/2016 ©odd.enterprises 23

Page 24: Obstacle Driven Development Models

Flowchart

Flowcharts show how we create products through each stage.

• Process is similar for each stage

• Create tests first, solutions after

• Stages complete when all tests are passed

15/07/2016 ©odd.enterprises 24

Page 25: Obstacle Driven Development Models

Flowchart + Feedback

Feedback between stages allows modification of previous stages within a development cycle.

• Feedback when tests or solutions are not suitable

• Tests and/or solutions may not correct

• Progress of stage determines feedback

15/07/2016 ©odd.enterprises 25

Page 26: Obstacle Driven Development Models

Repeating M-models

M-models also repeat by folding in on themselves which helps continuous improvement.

• Consists of V and inverted V-models

• Process and structure identical to other forms

• Current and future products developed concurrently

15/07/2016 ©odd.enterprises 26

Page 27: Obstacle Driven Development Models

Systems Engineering

Further stages may be added to create models suitable for systems engineering.

• Additional stages of Supply and Assemble support hardware and embedded

• Maintenance and Support to help products and services longevity

15/07/2016 ©odd.enterprises 27

Page 28: Obstacle Driven Development Models

Software Engineering + Sales

Other stages are added to the systems engineering model as necessary.

• Business obstacles and solutions may be combined

• Helps determine effective business strategies

15/07/2016 ©odd.enterprises 28

Page 29: Obstacle Driven Development Models

Hardware Engineering + Sales

Stages are added or removed as necessary for development.

• Adding Supply and Assemble added

• Maintenance and Support removed

• Helps links Hardware and Embedded engineering to a business strategy

15/07/2016 ©odd.enterprises 29

Page 30: Obstacle Driven Development Models

ODDSAP (Supply Assemble Production)

Stages are added and removed to create new models.

• Stages added in pairs which support development

• Supply and Assemble ensure hardware is supplied and assembled right

15/07/2016 ©odd.enterprises 30

Page 31: Obstacle Driven Development Models

OODA Inspired ODDSAP

Combining the ODDSAP model with OODA shows feedback and importance of Specification.

• Feedback from each stage to Analysis

• Implicit Guidance and control from Specification

15/07/2016 ©odd.enterprises 31

Page 32: Obstacle Driven Development Models

ASAP (Analysis Supply Assemble Production)

ASAP used when there is insufficient time to perform the required stages.

• Product is built quickly with ODD stages to verify and validate

• ODD performed concurrently or after

15/07/2016 ©odd.enterprises 32

Page 33: Obstacle Driven Development Models

Generic Form

Generic form is applicable between each of the stages.

• Obstacle is a solution from previous stage

• Target / Test creates a test with assertion

• Solution solves the test / achieves target

• Action is result of the stage

15/07/2016 ©odd.enterprises 33

Page 34: Obstacle Driven Development Models

OBSA (Obstacle Behaviour Solution Action)

OBSA is the fundamental process and method behind ODD.

• Modified for different fields including business and medicine

• Fundamental to OODA methods also

15/07/2016 ©odd.enterprises 34

Page 36: Obstacle Driven Development Models

Legal Stuff

ReferencesTest Driven Development for Embedded C

James Grenning, 2011

Digging into “Fail fast, fail often.”

http://agile.dzone.com/articles/digging-fail-fast-fail-often

Agile vs. Waterfall: How to Approach your Web Development Project

http://www.commonplaces.com/blog/agile-vs-waterfall-how-approach-your-web-development-project

The Scrum Master Performance Review

http://illustratedagile.com/2011/12/13/the-scrum-master-performance-review-preparation/

ScrumMaster

http://www.mountaingoatsoftware.com/agile/scrum/scrummaster

DisclaimerThe ODD M-model and associated processes are provided by odd.enterprises and may be used for any purpose whatsoever.

The names odd.enterprises and associated logos should not be used in any representation, advertising, publicity or other manner whatsoever to endorse or promote any entity that adopts or uses the model and/or associated processes.

odd.enterprises does not guarantee to provide support, consulting, training or assistance of any kind with regards to the use of the model and/or processes including any updates.

You agree to indemnify odd.enterprises and its affiliates, officers, agents and employees against any claim or demand including reasonable solicitors fees, related to your use, reliance or adoption of the model and/or processes for any purpose whatsoever.

The model is provided by odd.enterprises “as is” and any express or implied warranties, included but not limited to the implied warranties of merchantability and fitness for a particular purpose are expressly disclaimed.

In no event shall odd.enterprises be liable for any damages whatsoever, including but not limited to claims associated with the loss of data or profits, which may result from any action in contract, negligence or other tortious claim that arises out of or in connection with the use or performance of the model.

15/07/2016 ©odd.enterprises 36