The document introduces Obstacle Driven Development (ODD), an extension of Test Driven Development (TDD). ODD applies the concept of testing to all stages of development from analysis through production. It uses a cyclic process where tests are created to address obstacles at each stage before moving to the next. This ensures solutions and elements pass verification and validation criteria. ODD models development as a continuous loop with tests linking different stages and elements to drive the creation of specifications, solutions, and products.

1. Obstacle Driven Development
Extending Test Driven Development 1.3
©odd.enterprises
14/12/2015

2. Obstacle Driven Development
14/12/2015 ©odd.enterprises 2

3. ODD Circle Model
14/12/2015 ©odd.enterprises 3

4. ODD Triangle Model
14/12/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
• SOLID principles
14/12/2015 ©odd.enterprises 5

6. Testing in History 1
Testing ideas is implicit to science
and technology.
• Testing implemented on products
for many years
• Ideas are assumptions without
sufficient testing
• Todays technology is a result of
centuries of tests
14/12/2015 ©odd.enterprises 6

7. Testing in History 2
Testing implemented on certain
products for many years.
• Tests must replicate real world
conditions
• Armour designed to be bullet
proof is tested
• Testing is required to ensure
products perform
14/12/2015 ©odd.enterprises 7

8. Test Driven Development 1
Test Driven Development is
software development where tests
are written before code.
• Creating tests first ensures code
is tested and testable
• Unit tests ran through test suites
for automated testing
• Improved code through early
error detection
14/12/2015 ©odd.enterprises 8
Write
Test
Write
Code
Refactor

9. Test Driven Development 2
Tests are written before the code
with TDD .
1. Test is written and ran to
observe a fail
2. Simplest code is written to pass
the test
3. Code is refactored according to
SOLID principles
4. Repeat until coding complete
14/12/2015 ©odd.enterprises 9
Write
Test
Write
Code
Refactor

10. Test Driven Development 3
Development of ODD began with a
question when using TDD:
• Where do the tests come from?
14/12/2015 ©odd.enterprises 10
Write
Test
Write
Code
Refactor

11. Behaviour Driven Development
• Often described as “Test Driven
Development done right”
• Behaviours implemented for
testing and design
• Additional stage of thinking
about tests
• Increased efficiency over TDD
14/12/2015 ©odd.enterprises 11
Write
Test
Write
Code
Refactor
Think

12. ODD Behaviour Driven Development
Redesigning a BDD sequence gives one
similar to traffic lights.
1. Red light for behaviour to be
coded
2. Amber light when tests are
created
3. Code written and tested
4. Green light when tests are passed
5. Repeat until specification is coded
14/12/2015 ©odd.enterprises 12
Write
Test
Write
Code
Validate /
Refactor
Behaviour

13. ODD Process 1
ODD process becomes generic to
create a new development model.
• Applications to hardware,
software and embedded
• Links obstacles with tests for
verification and validation
• Refactoring included in Validate
Solution
14/12/2015 ©odd.enterprises 13
Verify
Solution
Solution for
Obstacle
Validate
Solution
Obstacle

14. ODD Process 2
Obstacles are divided into four
stages of development with ODD:
• Analysis
• Specification
• Solution
• Production
14/12/2015 ©odd.enterprises 14
Verify
Solution
Solution for
Obstacle
Validate
Solution
Obstacle

15. ODD Process 2
14/12/2015 ©odd.enterprises 15

16. Obstacle Driven Development 1
ODD Process is adapted and
repeated between four stages in
sequence.
• Analysis
• Specification
• Solution
• Production
14/12/2015 ©odd.enterprises 16
Specification
Solution
Production
Analysis

17. Obstacle Driven Development 2
Verification and validation link
stages and provide feedback.
• Verification ensures a product is
built in the right way
• Validation ensures a product is
built right
• Creating and solving tests give
verification and validation
14/12/2015 ©odd.enterprises 17

18. ODD for Embedded
Obstacle Driven Development is
designed for software, hardware
and embedded.
• Stages are defined to help create
physical products
• Benefits of software, hardware
and embedded principles
• Suitable for safety critical
applications
14/12/2015 ©odd.enterprises 18

19. ODD Circle Model
Stages are linked throughout with
verification and validation.
• Modelled on traffic lights
• Four or more stages for product
development
• Each stage linked through
creation of tests
14/12/2015 ©odd.enterprises 19

20. ODD Verification and Validation
Appropriate verification and
validation links each stage.
• Specification
– Verification and validation
• Solution
– Testing and design
• Production
– Quality assurance and control
• Analysis
– Utilisation and elicitation
14/12/2015 ©odd.enterprises 20

21. Linking Tests 1
Behaviours link with solutions
through testing and design.
• Solutions designed according to
tests from behaviours
• Each test has a single result –
pass or fail
• Unit testing with test suite
• Tests ran when changes occur
14/12/2015 ©odd.enterprises 21

22. Linking Tests 2
Testing and design of solutions from
behaviours of a specification.
• Each solution implements 1 or
more behaviours
• Tests suite ran with any changes
or extensions
• Created according to TDD
principles
14/12/2015 ©odd.enterprises 22

23. ODD Solution
Solution created from specification
through behaviour tests
• Red light for behaviour contained
in specification
• Amber light when test for
behaviour is created
• Green light when solution
designed to pass test
14/12/2015 ©odd.enterprises 23
Create Test
Design
Solution
Pass
Test
Behaviour

24. ODD Production
Production created from solution
through quality assurance and
control.
• Red light for a solution with no
quality assurance and control
• Amber light when test to assure
quality is created
• Green light when quality control
is passed
14/12/2015 ©odd.enterprises 24
Assure
Product
Quality
Produce
Product
Control
Product
Quality
Solution

25. ODD Analysis
Analysis performed on production
features through tests.
• Red light for no utilisation and
elicitation of feature
• Amber light when test for
customer utilisation is created
• Green light when tests for
customer elicitation is passed
14/12/2015 ©odd.enterprises 25
Customer
Utilisation
Situation
Analysis
Elicit
Customers
Feature

26. ODD Specification
Specification created from analysis
through requirement tests.
• Red light for a requirement
• Amber light when verification
test is created
• Green light when test passed and
behaviour validated
14/12/2015 ©odd.enterprises 26
Verify
Specification
Specify
Behaviour
Validate
Specification
Requirement

27. ODD Process Flow Chart
ODD is also expressed
through flowcharts.
• Loops for repetition
until solutions are
found
• Decisions to loop
made by testing
• Pass all tests to start
next stage
14/12/2015 ©odd.enterprises 27

28. ODD Process Flow Chart
Each flowchart is similar with a test
created before a solution.
• We continue to create a solution
until it passes test
• We repeat steps for all obstacles
• Once all obstacles are tested and
pass we move to next stage
14/12/2015 ©odd.enterprises 28

29. Flow Chart for Solution
1. Select behaviour which a solution
has to perform.
2. Test created to ensure solution
performs behaviour.
3. Solution designed to pass test.
4. Repeat until solution passes test.
5. Repeat until behaviours tested
and solutions designed.
6. Production stage begins.
14/12/2015 ©odd.enterprises 29

30. Flowchart for Production
1. Select solution which
production is to create.
2. Quality assurance test ensures
production creates solution.
3. Production begins.
4. Repeat until quality is
controlled.
5. Repeat until all production is
quality controlled.
6. Analysis stage begins.
14/12/2015 ©odd.enterprises 30

31. Flowchart for Analysis
1. Select feature to be elicited for
analysis.
2. Utilisation test is created for
feature.
3. Product is utilised by customers.
4. Repeat elicitation until sufficient
feedback obtained.
5. Repeat until all features in
production are tested.
6. Specification stage begins.
14/12/2015 ©odd.enterprises 31

32. Flowchart for Specification
1. Requirement selected to be
covered by behaviour.
2. Verification test is created.
3. Behaviour is specified according
to the test.
4. Repeat until behaviour is
validated.
5. Repeat until all requirements
are covered by behaviours.
6. Solution stage begins.
14/12/2015 ©odd.enterprises 32

33. ODD Combined Flowchart 1
14/12/2015 ©odd.enterprises 33

34. ODD Combined Flowchart 2
14/12/2015 ©odd.enterprises 34

35. Unit Testing
Unit tests facilitate ODD when ran
through test suites.
• Every stage is tested
• Tests are created from an
element of the previous stage
• Each test has a single result
• Combined to give complex test
with single result
14/12/2015 ©odd.enterprises 35

36. ODD Test Suites
Test suites help create a solution
and identify errors.
• Test suites contain individual and
combined unit tests
• Test suites implemented
between all stages
• TDD process extended
throughout development
14/12/2015 ©odd.enterprises 36

37. Linking Stages, Tests and Elements
• Situation A is analysed
– Verify and validate Behaviour A
• Behaviour A covers Situation A
– Testing and design of Solution A
• Solution A implements Behaviour A
– Quality assurance and control of
Production A
• Production A implements Solution A
– Utilisation and elicitation of Situation A
14/12/2015 ©odd.enterprises 37

38. ODD Elements
• ODD Elements describe
individual levels and stages of
development
14/12/2015 ©odd.enterprises 38
• Elements are linked through
tests at same level and
between stages

39. ODD Element Levels
Element describes a stage and level
from material to product and
analysis to production.
A Product consists of:
• Systems; which consist of
• Subsystems; which consist of
• Components; which consist of
• Materials
14/12/2015 ©odd.enterprises 39

40. ODD Element Testing
Testing is separated into levels and
linked to the same levels of each
stage.
• System level tests to link systems
• Subsystem level tests to link
subsystems
• Component level tests to link
components
• Material level tests for materials
14/12/2015 ©odd.enterprises 40

41. Specification Elements and Testing
Specification elements link to
Analysis and Solution stages.
• Specification links to Analysis
through Validation
• Specification links to Solution
through Testing
14/12/2015 ©odd.enterprises 41

42. Solution Elements and Testing
Solution elements link to
Specification and Production
stages.
• Solution links to Specification
through Design
• Solution links to Production
through quality Assurance
14/12/2015 ©odd.enterprises 42

43. Production Elements and Testing
14/12/2015 ©odd.enterprises 43
Production elements link to
Solution and Analysis stages.
• Production links to Solution
through quality Control
• Production links to Analysis
through Utilisation

44. Analysis Elements and Testing
Analysis elements link to
Production and Specification
stages.
• Analysis links to Production
through Elicitation of customers
• Analysis links to Specification
through Verification of behaviour
14/12/2015 ©odd.enterprises 44

45. ODD Continuous
Process
• Process repeats for
continuous improvement
• Further stages may be
added
• Proceed clockwise through
each stage
14/12/2015 ©odd.enterprises 45

46. ODD Materials
ODD is explained in further
presentations.
• Obstacle Driven
Development
• ODD: Requirements Analysis
• ODD: Extending a
Specification
• ODD: Extending TDD
• ODD: Extending V-models
• ODD Is Not Agile or Waterfall
ODD Is Not
Agile or
Waterfall
Obstacle Driven
Development
ODD:
Requirements
Analysis
ODD: Extending
a Specification
ODD: Extending
V-models
ODD:
Extending TDD
15/12/2015 ©odd.enterprises 46

47. Further Information and Questions
• odd.enterprises
• Presentations
• Facebook
• Twitter
• Email
14/12/2015 ©odd.enterprises 47

48. 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.
14/12/2015 ©odd.enterprises 48