Obstacle Driven Development is the latest engineering process and combines Test Driven Development with safety critical V-model development. This presentation demonstrates how the process extends and combines Test Driven Development throughout the engineering and product development processes. Please see the series for further details.

1. Obstacle Driven Development
Extending Test Driven Development 2
©odd.enterprises
18/02/2015

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

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

4. ODD Process
18/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 spiral
• Agile principles
18/02/2015 ©odd.enterprises 5

6. Testing in History
Testing has been implemented on
certain products for many years.
• Armour designed to be bullet
proof is tested
• Non standard components
required this approach
18/02/2015 ©odd.enterprises 6

7. Test Driven Development
Using TDD there is a very important
and difficult stage of writing tests.
Obstacle Driven Development helps
define tests and extends TDD
throughout development.
Development of ODD began with
the question
• Where do the tests come from?
18/02/2015 ©odd.enterprises 7
Write
Test
Write
Code
Refactor

8. Behaviour Driven Development 1
• Behaviour driven development
has been described as “TDD
done right”
• Suggests behaviours should
influence testing and design
• ODD is an extended version of
BDD applied to all development
stages
18/02/2015 ©odd.enterprises 8
Write
Test
Write
Code
Refactor
Think

9. 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 the tests
have been passed
18/02/2015 ©odd.enterprises 9
Write
Test
Write
Code
Validate /
Refactor
Behaviour

10. Obstacle Driven Development 1
Tests used to verify and validate
code are extended and adapted to
create a new development model.
• Applications to hardware,
software and embedded
• Links stages with tests used for
verification and validation
18/02/2015 ©odd.enterprises 10
Verify
Solution
Solution for
Obstacle
Validate
Solution
Obstacle

11. Obstacle Driven Development 2
Obstacle Driven Development is
used to find solutions to obstacles.
An obstacle is broken into four
stages of development when using
ODD.
• Analysis
• Specification
• Solution
• Production
18/02/2015 ©odd.enterprises 11
Verify
Solution
Solution for
Obstacle
Validate
Solution
Obstacle

12. ODD Flow Chart
Flow chart to demonstrate a
generic ODD process.
Problems or obstacles to be
overcome are divided into 4 stages
with appropriate testing.
• Analysis
• Specification
• Solution
• Production
18/02/2015 ©odd.enterprises 12

13. Obstacle Driven Development 3
The ODD Process is expressed using
four stages in sequence.
The diagram is simplified to
demonstrate a basic ODD process.
• Analysis
• Specification
• Solution
• Production
18/02/2015 ©odd.enterprises 13
Specification
Solution
Production
Analysis

14. Obstacle Driven Development 4
Verification and validation are
applied to link stages and provide
feedback.
• Verification is ensuring a product
is built in the right way
• Validation is ensuring a product is
built right
• Creating and solving tests give
verification and validation
19/02/2015 ©odd.enterprises 14

15. ODD M-model
Verification and validation are to
the left of each stage.
• Specification
– Verification and validation
• Solution
– Testing and design
• Production
– Quality assurance and control
• Analysis
– Utilisation and elicitation
18/02/2015 ©odd.enterprises 15

16. ODD Process 1
A traffic light system demonstrates
how one stage links the next.
• Begin with a red light and
element from previous stage
• Amber lights are given when
tests are created
• Green lights are given when tests
are solved and stage linked
18/02/2015 ©odd.enterprises 16

17. ODD Process 2
Each stage of ODD has tests for
each element of development.
• Each element begins as
unverified and unvalidated
• Tests are created to verify an
element
• Tests are solved to verify and
validate the element
18/02/2015 ©odd.enterprises 17

18. ODD Combined Model
The diagram shows an ODD process
combined with an M-model and the
resulting model.
• Traffic lights between stages
indicate unit tests required
• Linking tests and elements
ensures obstacles are solved
• Each element is created through
a unit test
18/02/2015 ©odd.enterprises 18

19. ODD Solution 1
Using a specification allows
creation of tests based on
described behaviours.
• Solution is used to describe
individual and integrated designs
• If a solution is designed to pass
tests then testing becomes easier
• Unit testing and test suites used
18/02/2015 ©odd.enterprises 19
Create Test
Design
Solution
Pass
Test
Behaviour

20. ODD Solution 2
ODD Solution is generic and used
for software, hardware and
embedded design.
• Red light used for behaviour
contained in specification
• Amber light used when tests are
created and solution designed
• Green light used when a test has
been passed
18/02/2015 ©odd.enterprises 20
Create Test
Design
Solution
Pass
Test
Behaviour

21. ODD Solution Flowchart
A flow chart has been designed to
explain use of an ODD Solution.
1. A 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
18/02/2015 ©odd.enterprises 21

22. ODD Specification 1
A specification describes all
behaviours used to cover expected
situations and requirements.
• Tests used to verify and validate
whether described behaviours
cover requirement
• Once expected situations are
covered and tests verified a
specification is complete
18/02/2015 ©odd.enterprises 22
Verify
Specification
Specify
Behaviour
Validate
Specification
Requirement

23. ODD Specification 2
ODD Specification is extended into
a separate stage containing a full
description of behaviours.
• Unit tests applied to a
specification allow cross
examination of behaviours
• Important to create full
specification to allow detection
of errors at an early stage
18/02/2015 ©odd.enterprises 23
Verify
Specification
Specify
Behaviour
Validate
Specification
Requirement

24. ODD Specification 3
Adaption of ODD gives a sequence
as follows:
• Red light used for a requirement
• Amber light when verification
tests are created and behaviour
specified
• Green light used when a
behaviour has been validated
18/02/2015 ©odd.enterprises 24
Verify
Specification
Specify
Behaviour
Validate
Specification
Requirement

25. ODD Specification Flowchart
A flow chart designed to explain
use of an ODD Specification.
1. A requirement is selected which
is 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
18/02/2015 ©odd.enterprises 25

26. ODD Production 1
Production is organised directly
from a solution to give assured and
controlled quality.
• Solution used to ensure
continuous and predictable
quality
• Quality assurance tests are
created
• Number of passes a measure for
quality control
18/02/2015 ©odd.enterprises 26
Assure
Product
Quality
Produce
Product
Control
Product
Quality
Solution

27. ODD Production 2
A solution is required to have
production assured and controlled.
• Red light for a solution with no
quality assurance and control
• Amber light used when tests for
assuring product quality are
created
• Green light used when quality
control is passed
18/02/2015 ©odd.enterprises 27
Assure
Product
Quality
Produce
Product
Control
Product
Quality
Solution

28. ODD Production Flowchart
A flow chart has been designed to
explain use of ODD Production.
1. A solution is selected which has
to be produced
2. Quality assurance test created
3. Production process
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all
production is assured
18/02/2015 ©odd.enterprises 28

29. ODD Analysis 1
Utilisation and elicitation are used
to verify and validate product
features.
• Once product features are
utilised then elicitation can
proceed as validation
• Process links stages and allows
continuous improvement and
adaption
18/02/2015 ©odd.enterprises 29
Customer
Utilisation
Situation
Analysis
Elicit
Customers
Feature

30. ODD Analysis 2
Analysis may be performed to give
feedback on success of a product.
• Red light for no utilisation and
elicitation of feature
• Amber light when tests for
customer utilisation are created
• Green light when tests for
customer elicitation are passed
18/02/2015 ©odd.enterprises 30
Customer
Utilisation
Situation
Analysis
Elicit
Customers
Feature

31. ODD Analysis Flowchart
A flow chart has been designed to
explain use of ODD Analysis.
1. Product feature is selected
2. Elicitation test is created
3. Product is utilised
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until
elicitation is complete
18/02/2015 ©odd.enterprises 31

32. Testing Procedure
Unit testing is used and extended
throughout each stage for ODD
testing.
• Each stage is assigned a red light
to begin
• Amber lights are obtained when
tests are created for next stage
• Green light is for when tests are
passed and next stage linked
18/02/2015 ©odd.enterprises 32

33. Unit Testing 1
Unit tests are used to facilitate ODD
through test suites.
• Every stage is tested
• Each test has a single result
• Unit tests can be combined to
give complex testing processes
• Green light is for when tests are
passed and element created
18/02/2015 ©odd.enterprises 33

34. Unit Testing 2
• Requirements analysis
– Test ensures behaviour covers
situation
– Solving test ensures behaviour
covers situation
• Specification of behaviours
– Test ensures solution implements
behaviour
– Solving test ensures solution
implements behaviour
18/02/2015 ©odd.enterprises 34

35. Unit Testing 3
• Solution design
– Test ensures production creates a
solution
– Solving test ensures production
creates a solution
• Production quality
– Test ensures product utilisation in a
situation
– Solve to ensure product elicitation
in a situation
18/02/2015 ©odd.enterprises 35

36. ODD Elements
• Elements are the smallest
practical levels of a product
and are sub divided
18/02/2015 ©odd.enterprises 36
• Elements are solutions of
verification tests generated
by a previous stage

37. Linking Stages, Tests and Elements
• Situation A is analysed
– Tests verify and validate Behaviour A
• Behaviour A covers Situation A
– Testing and design of Solution A
• Solution A implements Behaviour A
– Tests for quality assurance and control
of Production A
• Production A implements Solution A
– Tests for utilisation and elicitation of
product Situation A
18/02/2015 ©odd.enterprises 37

38. ODD Flowchart
18/02/2015 ©odd.enterprises 38

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

40. 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
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.
18/02/2015 ©odd.enterprises 40