Obstacle Driven Development (ODD) is a software development process that addresses issues with other methods like Test Driven Development and Waterfall development. ODD adapts stages from the Waterfall model and integrates testing throughout development. It uses models like the ODD Circle, Triangle, and M-models to demonstrate how stages are linked by tests and how verification and validation are performed at each stage from requirements to production. The goal of ODD is to identify and address failures early through implicit testing between stages.

1. Obstacle Driven Development
ODD Stages

2. Development Background
Ideas of Obstacle Driven Development (ODD) are based on
numerous development processes including:
• ISO V-model
• Test Driven Development
• ISO specifications
• Requirements analysis spiral
• Waterfall development
• Agile principles
28/06/2016 ©odd.enterprises 2

3. Obstacle Driven Development
28/06/2016 ©odd.enterprises 3

4. Motivation
Obstacle Driven Development
addresses the following (and more)
problems:
• How are tests created using Test
Driven Development?
• How are requirements linked to
behaviours?
• How can Agile principles be
combined safety critical?
28/06/2016 ©odd.enterprises 4

5. Waterfall Development
Waterfall development is
considered a traditional method of
software development.
• Each stage “fixed” before moving
to next
• Changing requirements is an
issue with fixed stages
• Testing late in development
reduces time to fix errors
28/06/2016 ©odd.enterprises 5

6. ODD is not Waterfall
ODD is different to
Waterfall in a number
of ways.
• Development stages
are not fixed
• Testing is implicit
throughout with
unit tests
• Testing between
each stage
28/06/2016 ©odd.enterprises 6

7. ODD Stages
Waterfall stages are adapted to
become ODD stages.
• Testing stage is removed and
made implicit between stages
• Suitable for software
development
• Extends to hardware and
embedded
• More stages such as Supply and
Assemble added if needed
28/06/2016 ©odd.enterprises 7

8. ODD Circle Model
Shows stages of development with
verification and validation.
• Similar to a set of traffic lights
• Four stages are used for
development
• Stages linked through the
creation and solving of tests
28/06/2016 ©odd.enterprises 8

9. ODD Triangle Model
Alternative form demonstrating how
stages combine for development.
• Each stage responsible for creation
and solving of tests
• Stages link to form entire
development process
• Verification and validation adapted
for each stage
28/06/2016 ©odd.enterprises 9

10. ODD M-model
M-model describes an
entire development
process in a single
diagram.
• Testing processes
between blocks
• Each stage has a
checkpoint
28/06/2016 ©odd.enterprises 10

11. Fail Early, Fail Often
Achieving success with ODD is
through identifying, correcting and
preventing failure.
• Undiscovered errors cost 10x
more to fix by next stage
• Errors become expensive to solve
• 2 stages missed ≈ 100x
• 3 stages missed ≈ 1000x
28/06/2016 ©odd.enterprises 11

12. ODD Problem Domain 1
• ODD problem domain solved
through four stages
• Verification and validation
using tests between stages
28/06/2016 ©odd.enterprises 12

13. ODD Problem Domain 2
• Testing process adapted and
repeated for each stage
• Each stage separate and
linked through tests
28/06/2016 ©odd.enterprises 13

14. ODD Model and Links
Problem and solution domain are
extended to model and link each
required stage.
• ODD M-model demonstrates
stages and testing
• Verification and validation
appropriate to each stage
• Extends V-model development
28/06/2016 ©odd.enterprises 14

15. ODD Elements
ODD Elements describe each part
of development with stage, system
and abstraction level.
• Higher level elements will consist
of combined lower levels
• Each stage contains different and
distinct elements
• Relative height in M-model
indicates level of element
28/06/2016 ©odd.enterprises 15

16. Element Levels
• Product
• System
• Subsystem
• Component
• Material
• Each is tested
28/06/2016 ©odd.enterprises 16

17. Analysis Elements
Analysis links Production
and Specification stages
with tests solved and
created by each level.
• Analysis links
Production by elicitation
of customers
• Analysis links
Specification by
verification of
behaviours
28/06/2016 ©odd.enterprises 17

18. Specification Elements
Specification links
Analysis and Solution
stages with tests
solved and created by
each level.
• Specification links
Analysis through
solving of tests
• Specification links
Solution through
creation of tests
28/06/2016 ©odd.enterprises 18

19. Solution Elements
Solution links Specification
and Production stages with
tests solved and created by
each level.
• Solution links
Specification by design
according to tests
• Solution links
Production by quality
assurance tests
according to solution
28/06/2016 ©odd.enterprises 19

20. Production Elements
Production links Solution
and Analysis stages with
tests solved and created by
each level.
• Production links
Solution through quality
control according to
tests
• Production links
Analysis through
utilisation of products
features
28/06/2016 ©odd.enterprises 20

21. ODD Analysis 1
Analysis is
• situations expressed
through combining
simplest situation
components
• individual situations
integrated to create
practical situations
28/06/2016 ©odd.enterprises 21

22. ODD Analysis 2
Analysis integrated from
hazards through use of
Safety Integrity Levels.
• Elicitation to ensure
situations and
requirements are
identified
• Safety Integrity Levels
define hazards
through probability,
severity and
controllability
28/06/2016 ©odd.enterprises 22

23. ODD Specification 1
Specification is
• a full description of
a solution
• decomposed from
high level
specification
• separate from
analysis and
solution
28/06/2016 ©odd.enterprises 23

24. ODD Specification 2
Specification decomposed
from high levels ensures
these behaviours are
maintained.
• Helps test ideas for
solution before it is
created
• Assumptions for a
solution may be
validated against
analysis
28/06/2016 ©odd.enterprises 24

25. ODD Solution 1
Solution is
• working example of
a product from
lowest to highest
levels
• integrated from
lowest levels
required
• designed according
to specification
28/06/2016 ©odd.enterprises 25

26. ODD Solution 2
Solution integrated
from low levels to
ensure design and
testing with bottom-up
approach.
• Solution designed to
pass tests
• Testability through
unit tests and test
suite
28/06/2016 ©odd.enterprises 26

27. ODD Production 1
Production is
• assembly and
related activities of
producing a solution
• decomposed from a
high level solution
• controls production
of solution and
enable utilisation of
a product
28/06/2016 ©odd.enterprises 27

28. ODD Production 2
Production decomposed
from high levels to
ensure an appropriate
solution is produced.
• Production organised
with decomposition
• Quality assurance and
control according to
solution
28/06/2016 ©odd.enterprises 28

29. Integration
Ascending slopes
indicate integration of
elements from lowest
to highest required.
• Errors found by
combining individual
elements
• Processing hazards
finds and prioritises
requirements
28/06/2016 ©odd.enterprises 29

30. Decomposition
Descending slopes
indicate decomposition
of elements from
highest to lowest
required.
• Decomposition allows
for material tests
from system tests
• High level
specification testing
and production
assurance
28/06/2016 ©odd.enterprises 30

31. Requirements Checkpoint
Consolidated Requirements
is checkpoint for Analysis.
• Requirements processed
and most important
consolidated
• SILs ensure important
requirements are
identified
• Expected situations
covered for a successful
product
28/06/2016 ©odd.enterprises 31

32. Documents Checkpoint
Sufficient documentation
to describe all expected
behaviours.
• Documents describe
all product behaviours
• Decomposed from
high level behaviours
to low level
• Allows creation of
instructions and
manuals
28/06/2016 ©odd.enterprises 32

33. Prototype Checkpoint
Integrated and tested
solution becomes a
prototype.
• Created from
integrated solutions
at various levels
• Ensures behaviours
are covered by a
solution
• Working model or
template of a product
is achieved
28/06/2016 ©odd.enterprises 33

34. Product Checkpoint
Once production is
complete then working
products are achieved.
• Production with
decomposition
ensure high level
solutions
• Decomposition
ensures production
according to product
solution
• Assembly important
at all levels of
production
28/06/2016 ©odd.enterprises 34

35. Further Information and Questions
• Website
• Presentations
• Facebook
• Twitter
• Email
28/06/2016 ©odd.enterprises 35

36. Legal Stuff
References
Test Driven Development for Embedded C
James Grenning, 2011
Test Driven Development
http://en.wikipedia.org/wiki/Test-driven development
Behaviour Driven Development
http://en.wikipedia.org/wiki/Behavior-driven development
Unit Testing
http://en.wikipedia.org/wiki/Unit testing
Contact us for more information on sources and references.
Disclaimer
The 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.
28/06/2016 ©odd.enterprises 36