Obstacle Driven Development has the most comprehensive testing of any engineering process or method. Tests are created for each element of all stages of development. Specifications and standards are combined with V-models and Behaviour Driven Development to create a novel approach to engineering. Safety critical standards such as ISO 26262 are implemented to ensure development obstacles are covered by appropriate behaviours.

1. Obstacle Driven Development
Extending a Specification 1.3

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

3. ODD Circle Model
28/06/2016 ©odd.enterprises 3

4. ODD Specification and Solution Model
28/06/2016 ©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
28/06/2016 ©odd.enterprises 5

6. ODD Design Phases
Obstacle Driven Development has
stages similar to waterfall.
• Analysis
• Specification
• Solution
• Production
28/06/2016 ©odd.enterprises 6

7. ODD Design Phases 2
Stages are linked through testing
where a test is created and solved.
• Stages linked to adjacent stages
by verification and validation.
• Verification creates a test
– Verify, Testing, Assure, Utilise
• Validation solves a test
– Validate, Design, Control, Elicit
28/06/2016 ©odd.enterprises 7

8. ODD Design Phases 3
Checkpoints are added
to provide outputs
from each stage.
• Requirements
• Documents
• Prototype
• Product
28/06/2016 ©odd.enterprises 8

9. Preliminary and Detailed Design
Specification combines
preliminary and
detailed design.
• Complete
description of how
product behaves
• Contains only
descriptions, up to
and including
simulations
28/06/2016 ©odd.enterprises 9

10. International Organisation for Standardisation 1
The ISO specify minimum behaviour
expected of products which must
conform.
By conforming to standards such as
ISO a product:
• Gains access to markets
• Described as state of the art
• Limits legislative exposure
28/06/2016 ©odd.enterprises 10

11. International Organisation for Standardisation 2
ISO have defined processes for
analysis and specifications.
• ODD inspired ISO 26262 "Road
vehicles – Functional safety“
• Designing solutions according to
international standards ensures
conformance
• Other standards bodies such as
the IEC have similar processes.
28/06/2016 ©odd.enterprises 11

12. Specification
Traditional specification is an
interface between problem and
solution domains.
• Description of behaviours which
define a product
• Specification not used in all
traditional processes
• Requirements are often used
directly
28/06/2016 ©odd.enterprises 12

13. ISO V-model
V-models help form
structure and create ISO
compatible
developments.
• V-models inspired
linking of elements
• Safety critical design
processes
• Numerous V-models
have been created,
some inspired by TDD
28/06/2016 ©odd.enterprises 13

14. Importance of a Specification
Specifications improve development
of a product by providing additional
testing.
• Product cost is reduced with an
improved specification process
• Creating a full specification
prevents errors propagating
• Creating and testing a specification
is relatively low cost
28/06/2016 ©odd.enterprises 14

15. ODD Specification
ODD separates problem
and solution domains.
• Specification contains
behaviours to cover
requirements
• Separated from
Analysis and Solution
stages
• Links stages through
appropriate unit tests
28/06/2016 ©odd.enterprises 15

16. Behaviours 1
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.
28/06/2016 ©odd.enterprises 16

17. Behaviours 2
Full separation of a Specification is
a crucial part of ODD.
• Separate specification allows for
greater freedom of development
• Alternative or back up behaviours
can satisfy a requirement
• Behaviours described to cover
situations/requirements
identified
28/06/2016 ©odd.enterprises 17

18. Abstraction Levels
Specification behaviours are divided
into abstract system levels.
• High level behaviours describe
how a product behaves
• Low level behaviours describe
how materials behave
• Decomposition allows for a
deductive process
• Tests linked for each abstraction
level
28/06/2016 ©odd.enterprises 18

19. Specification Creation
Behaviours decomposed and
defined to create 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
19PDD, Jonathan Herring

20. Specification Decomposition
Decomposition gives a top-down
approach to the creation of a
specification.
• Effective determination of lower
level behaviours
• Unnecessary behaviours are not
described
• Deductive process for creating a
specification
28/06/2016 ©odd.enterprises 20

21. Specification Definition
Definition gives an approach to
creation of a specification through
building increasing detailed models.
• Basic behaviours are defined first
• Specification defined through
increasing detail of behaviours
• Tests are created once
behaviours are defined with
assertions
28/06/2016 ©odd.enterprises 21

22. Documents Checkpoint
Documentation
describes all expected
behaviours.
• Documents describe
everything a product
should do
• Decomposed from
high level behaviours
into components
• Adapted and
distributed to
stakeholders
28/06/2016 ©odd.enterprises 22

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
28/06/2016 ©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
28/06/2016 ©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
28/06/2016 ©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
28/06/2016 ©odd.enterprises 26

27. Behaviour Driven Development 1
Behaviour Driven Development
inspired 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
28/06/2016 ©odd.enterprises 27

28. Behaviour Driven Development 2
Reordering the sequence gives one
similar to traffic lights.
• Red light for behaviours to be
coded
• Amber light when tests are
created and code written
• Green light when tests are
passed
28/06/2016 ©odd.enterprises 28

29. ODD Unit Testing 1
Unit tests and other Test Driven
Development principles are
extended to facilitate testing.
• Red light for obstacle to solve
• Amber light for test to obstacle
• Green light for solution
• Blue light for integrated and
refactored solution
28/06/2016 ©odd.enterprises 29

30. ODD Unit Testing 2
Unit tests are essential for an ODD
development method and adapted
for each stage.
• Adjacent stages linked through
creating and solving tests
• Each obstacle is tested
• Elements created through solving
tests
• Each test has a single result
28/06/2016 ©odd.enterprises 30

31. Creating a Specification
Specification created by
describing behaviours to
cover situations.
• Unit tests combined
to give complex
testing processes
• Green light for tests
passed
• Linked through
creating and solving
tests
28/06/2016 ©odd.enterprises 31

32. Specification Unit Testing
Create Specification
of Behaviours
• Select a situation or
requirement
• Create Test for
Verification
– Create test to ensure a
requirement is
covered by a
behaviour
• Solve Test for Validation
– Pass test ensures
requirement is
covered by a
behaviour
28/06/2016 ©odd.enterprises 32

33. Cross Examination 1
Cross examination in a courtroom is
similar to testing behaviours.
• Identification of errors and
contradictions before solution is
designed
• Unit tests are created to verify
behaviours with validation being
a pass
28/06/2016 ©odd.enterprises 33
Does Behaviour A cover Situation A?

34. Cross Examination 2
Behaviours are compared with
situations to find errors and
contradictions.
• Process used in development of a
specification
• Unit tests implemented between
situations and behaviours
• Ensures a behaviour for every
expected situation
28/06/2016 ©odd.enterprises 34

35. Unit Testing 1
All processes have reactions to
inputs with an output and/or
change in internal state.
• First stage describes responses to
situations and stimulus
• Unit tests for output and/or
internal change of a component
• Unit tests created from
behaviours described
28/06/2016 ©odd.enterprises 35

36. Unit Testing 2
Internal states are often impossible
to observe directly.
• Increase importance of creating
low level unit tests.
• Unit tests combined to test
complex behaviours
• Combined unit tests create a unit
test with a single result
28/06/2016 ©odd.enterprises 36

37. Creating a Solution
Full test suite created
with each behaviour
described in a
specification.
• Creating tests first
ensures a developer
understands objective
• Design according to
passing tests reduces
ambiguity
• Passing a test ensures
behaviour is
implemented
28/06/2016 ©odd.enterprises 37

38. Solution Unit Testing
Testing and Design of
Solution.
• Select a Behaviour
described
• Create 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
28/06/2016 ©odd.enterprises 38

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

40. 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.
28/06/2016 ©odd.enterprises 40