The document outlines the principles and methodologies of Obstacle Driven Development (ODD), emphasizing its compatibility with established standards like ISO 26262. It details the importance of specifications in the development process, which improves product design and testing through clear behavior definitions. The ODD approach separates specifications from problem domains, enabling better testing and validation of product behaviors to prevent errors and ensure compliance.

1. Obstacle Driven Development
Extending a Specification 2
©odd.enterprises
26/02/2015

2. Obstacle Driven Development
26/02/2015 ©odd.enterprises 2

3. ODD Circle Model
26/02/2015 ©odd.enterprises 3

4. ODD Traffic Light Model
26/02/2015 ©odd.enterprises 4

5. Background
Ideas of Obstacle Driven Development (ODD) are based on
numerous development processes including:
• ISO V-model
• Test Driven Development
• ISO specifications
• Requirements analysis
• Agile principles
26/02/2015 ©odd.enterprises 5

6. Design Phases
A traditional design process has
several phases to produce a
product.
• Requirement analysis
• Preliminary design
• Detailed design
• Implementation
• Testing
• Operations
26/02/2015 ©odd.enterprises 6

7. Preliminary and Detailed Design
An ODD Specification is a
combination of preliminary and
detailed design.
• ODD Specification is a complete
description of how a product
should behave
• ODD Specification should contain
only descriptions, up to and
including simulations
26/02/2015 ©odd.enterprises 7

8. International Organisation for Standardisation 1
The International Organisation for Standardisation (ISO) specify
the minimum behaviour that is expected of products which must
conform.
By conforming to standards such as ISO a product:
• Gains access to markets
• Can be described as state of the art
• Limits legislative exposure
26/02/2015 ©odd.enterprises 8

9. International Organisation for Standardisation 2
The ISO have defined processes for
analysis and specifications.
Obstacle Driven Development was
created by following a summary of
ISO 26262 "Road vehicles –
Functional safety“ and has been
designed to be compatible.
• Other standards bodies such as
the IEC have similar processes.
The ten parts of ISO 26262:
1. Vocabulary
2. Management of functional safety
3. Concept phase
4. Product development at the system level
5. Product development at the hardware level
6. Product development at the software level
7. Production and operation
8. Supporting processes
9. Automotive Safety Integrity Level (ASIL)-
oriented and safety-oriented analysis
10. Guideline on ISO 26262
26/02/2015 ©odd.enterprises 9

10. Specification
A traditional specification is an
interface between problem and
solution domains.
• Description of design and
materials which make a product
• Specification not used in all
traditional processes
• Requirements are often used
directly
26/02/2015 ©odd.enterprises 10

11. Importance of a Specification
A specification can improve the
development process of a product.
• Product cost is reduced with an
improved specification process
• Using a full specification can
prevent errors from propagating
• Creating and editing a
specification is low cost
26/02/2015 ©odd.enterprises 11

12. ODD Specification
ODD Specifications differ from
traditional by being separated from
problem and solution domains.
• Specification contains behaviours
which cover requirements
• Fully separated from Analysis and
Solution stages
• Links stages through appropriate
unit tests
26/02/2015 ©odd.enterprises 12

13. V-model
V-models formed the basic ODD
structure and are often used in ISO
developments.
• V-models inspired linking of
elements for ODD
• Often used for safety critical
design processes
• Numerous V-models have been
created, some inspired by TDD
26/02/2015 ©odd.enterprises 13

14. Behaviours 1
Whatever is desired of a product
can be expressed by its behaviours.
A definition of a behaviour is
• how an animal or person behaves
in response to a particular
situation or stimulus.
Replacing the subject with product
• how a product behaves in
response to a particular situation
or stimulus.
26/02/2015 ©odd.enterprises 14

15. Behaviours 2
Separating a specification from
requirements allows for greater
freedom.
• Numerous behaviours may
satisfy a requirement
• Alternative or back up behaviours
are described and investigated
• Behaviours determined by
analysis of situations
26/02/2015 ©odd.enterprises 15

16. Behaviour Levels
Behaviours are described by their
relative system levels.
• High level behaviours should
describe how a product behaves
• Low level behaviours describe
how materials behave
• Decomposition allows a
deductive reasoning process
• Tests are linked to each level
26/02/2015 ©odd.enterprises 16

17. Decomposition
Decomposition gives a top-down
approach to the creation of a
specification and product.
• Allows effective determination of
lower level behaviours
• Unnecessary behaviours are not
described
• Allows a deductive process for
creating the specification
26/02/2015 ©odd.enterprises 17

18. Documents Checkpoint
An ODD product has sufficient
documentation to describe all
expected behaviours.
• Documents describe everything a
product does
• Decomposed from high level
behaviours into components
• Intended for all stakeholders
26/02/2015 ©odd.enterprises 18

19. ODD Specification 1
Each behaviour specified creates
tests through decomposition and
definition.
• Specified
– Used to describe a behaviour with
no other detail
• Functional
– Describes what a behaviour does
with inputs, outputs and internal
states defined
26/02/2015 ©odd.enterprises 19

20. ODD Specification 2
• Logical
– Describes an expected behaviour
– Expected behaviour creates
assertions for unit tests
• Procedural
– Used for feedback against situation
analysis
– Only used to ensure behaviours are
verified and validated
27/02/2015 ©odd.enterprises 20

21. ODD Specification 3
Specification is decomposed and
defined starting with specified
behaviour and moving to the right.
• Specified behaviour has inputs
and outputs defined to become
functional behaviour
• Logical behaviour is expected or
desired behaviour of a product
27/02/2015 ©odd.enterprises 21

22. Specification Creation
Behaviours are decomposed and
defined to create a specification
and unit tests.
• Decomposition of high level
behaviours into lower levels
• Definition of specified behaviours
into logical behaviours
• Creation of tests through
assertions to link a solution
22PDD, Jonathan Herring

23. Specified Behaviour
Specified behaviour regards what it
is expected to do for input, output
and internal states.
• No further detail
• Full specification linking all inputs
with outputs to ensure nothing is
left out
• Easy to understand, discuss,
produce and edit
26/02/2015 ©odd.enterprises 23

24. Functional Behaviour
Functional behaviour expands
specified behaviour by adding
input, output and internal states.
• Input, outputs and internal states
are defined with units
• Expands on basic description of a
products behaviours
• Ensures behaviours link and
combine into a complete
specification
26/02/2015 ©odd.enterprises 24

25. Logical Behaviour
Logical behaviour builds on
functional behaviour by adding
expectations.
• Detail is defined until expected
behaviours are described
• Allows a complete description of
a products expected behaviour
• Tests are created from assertions
of expected behaviour
27/02/2015 ©odd.enterprises 25
Modelled motor is a simple DC.

26. Procedural Behaviour
Procedural behaviour is a model or
simulation of a product as seen by
customers and other stakeholders.
• Ensures specification of a
product is as required by
customers and stakeholders
• Increases communication
between developers and
customers
26/02/2015 ©odd.enterprises 26

27. Unit Testing
Unit tests and the Single
Responsibility Theorem facilitate
the testing process.
• Every element is tested
• Each test has a single result
• Unit tests are combined to give
complex testing processes
• Green light is for when tests are
passed and previous stage linked
27/02/2015 ©odd.enterprises 27

28. Behaviour Driven Development 1
Behaviour Driven Development
inspired the linking of a
specification to a design solution.
• Each behaviour creates tests
• Multiple behaviours can be
solved by a single solution
• Designing according to
behaviours reduces ambiguity
27/02/2015 ©odd.enterprises 28

29. Behaviour Driven Development 2
Reordering the BDD sequence gives
a sequence similar to traffic lights.
• Red light now used for unverified
and unvalidated processes
• Amber light now used when tests
are created and code written
• Green light used when tests have
been passed
27/02/2015 ©odd.enterprises 29
Write
Test
Write
Code
Validate /
Refactor
Behaviour

30. Implementing Unit Testing 1
Any process has a result of an
output and/or change in internal
state.
• Initial stage of a specification
describes responses to situations
and stimulus
• Unit tests for output and/or
internal change of a component
• Unit tests are integrated or
decomposed as necessary
27/02/2015 ©odd.enterprises 30

31. Implementing Unit Testing 2
Internal states are often impossible
to observe directly and increase
importance of creating low level
unit tests.
• Unit tests combined to test
complex behaviours
• Combined unit tests are also
considered a unit test
27/02/2015 ©odd.enterprises 31

32. Linking Tests 1
Tests link behaviours with solutions
through testing and design.
• Solutions are designed to tests
created
• Each solution is a single aspect of
the product
• Unit testing is applied
• Test suite created
26/02/2015 ©odd.enterprises 32

33. Linking Tests 2
Testing and design should concern
behaviours contained in a
specification.
• Customers are involved for
utilisation and elicitation
• Each solution implements 1 or
more behaviours
• Tests suite ran for any changes or
additions
26/02/2015 ©odd.enterprises 33

34. Creating Tests 1
Creation of a solution from a
specification is inspired by
Behaviour Driven Development.
• Often tests can be created by
simply rewriting a behaviour
• Designing a solution according to
tests reduces debugging
• Creation of tests and designs may
continue until all behaviours are
implemented
26/02/2015 ©odd.enterprises 34

35. Creating Tests 2
A full test suite is created using
each behaviour contained by a
specification.
• Creating a test first ensures a
developer understands their
objective
• Design according to passing tests
reduces ambiguity
• Passing a test ensures behaviour
is implemented
26/02/2015 ©odd.enterprises 35

36. Solution Unit Testing
Solution Design
• Select a behaviour
• Test for solution
– Create a test to ensure a behaviour
is implemented by a solution
• Design for solution
– Pass a test to ensure a behaviour is
implemented by a solution
26/02/2015 ©odd.enterprises 36

37. ODD Solution Flowchart
Flow chart to explain the creation
of an ODD Solution.
1. Behaviour is selected which has
to be covered by a solution
2. Unit test is created
3. Solution is designed
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all
behaviours are specified
26/02/2015 ©odd.enterprises 37

38. ODD Combined Model
26/02/2015 ©odd.enterprises 38
The testing process is
similar throughout
ODD with adaptions
between stages.
• Each set of traffic
light demonstrates
unit testing
• Tests begin with an
element from
previous stage

39. Specification Unit Testing
Specification of behaviours
• Select a requirement
• Verification
– Create a test to ensure a
requirement is covered by a
behaviour
• Validation
– Pass a test ensuring a requirement
is covered by a behaviour
27/02/2015 ©odd.enterprises 39

40. Linking Tests 3
Each situation creates a unit test to
link analysis with specification.
• Diagrams shows various stages of
testing progress
• Once unit test is passed it
becomes green
• Tests are implemented as a suite
and ran when editing occurs
26/02/2015 ©odd.enterprises 40

41. Linking Tests 4
Each situation is linked to a
behaviour contained in a
specification.
• Behaviour A covers normal
operation
• Behaviour B and C cover single
failures of components
• Behaviour D covers total failure
of components
26/02/2015 ©odd.enterprises 41

42. Linking Tests 5
When using a waterfall type
development then analysis is
complete when all tests are passed.
• Tests run when any changes in
analysis or specification
• Ensures expected situations are
covered
• Potential for infinite situations
26/02/2015 ©odd.enterprises 42

43. Cross Examination 1
Failing products may result in
litigation and therefore a cross
examination of a products
behaviours is applicable.
• Identification of errors and
contradictions before solution is
designed
• Unit tests are created to verify
behaviours with validation being
a pass
26/02/2015 ©odd.enterprises 43
Does Behaviour A cover Situation A?

44. Cross Examination 2
Cross examination is where
behaviours are compared with
situations to find errors and
contradictions.
• Process used in development of a
specification
• Unit tests implemented between
situations and behaviours
26/02/2015 ©odd.enterprises 44

45. ODD Specification Flowchart
Flow chart designed to explain
creation of an ODD Specification.
1. Situation is selected which has
to be covered by a behaviour
2. Verification test is created
3. Behaviour is specified
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all
behaviours are specified
26/02/2015 ©odd.enterprises 45

46. ODD Flowchart
26/02/2015 ©odd.enterprises 46

47. Further Information and Questions
• Website
• Presentations
• Facebook
• Twitter
• Email
26/02/2015 ©odd.enterprises 47

48. Legal Stuff
References
Test Driven Development for Embedded C
James Grenning, 2011
International Organisation for Standardisation
http://www.iso.org/iso/home/standards.htm
NASA, Assurance Process for Complex Electronics
www.hq.nasa.gov/office/codeq/software/ComplexElectronics/
Assessment of the ISO 26262 Standard
http://www.sae.org/events/gim/presentations/2012/qi_volpe.pdf
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.
26/02/2015 ©odd.enterprises 48