The document outlines various development models, emphasizing the integration of problem and obstacle-driven development approaches, which utilize verification and validation to ensure quality throughout the development stages. It discusses the evolution of models such as the n-model and m-model, highlighting the importance of tests at different abstraction levels and stages to facilitate continuous improvement. Additionally, it explores applications in systems engineering, software engineering, and hardware engineering, stressing the significance of feedback and specification in the development process.

1. Obstacle Driven Development
ODD Models

2. Testing First?
15/07/2016 ©odd.enterprises 2
Answering a
question before
its asked is like
creating a
solution before
a test.

3. Problem Driven Development
Problem Driven
Development combines
Test Driven Development
with V-models.
• Requirements analysis
is separate stage
• Specification in the
form of various levels of
testing
15/07/2016 ©odd.enterprises 3

4. Problem Driven Development
Colour is changed to
represent the colours
of traffic lights.
• Tests are linked to
abstraction levels of
the stages
• Suitable for research
purposes
15/07/2016 ©odd.enterprises 4

5. Problem Domain Development
Problem and solution
domains describe the
stages.
• Specification is an
interface between the
stages
• Expanding the
interface allows
increased testing
15/07/2016 ©odd.enterprises 5

6. N-model Comparison
Problem Driven Development
creates an N-model to combine a V
and inverted V-model.
• Comparison against Problem and
Solution domains
• Specification allows testing of
ideas before they are created
15/07/2016 ©odd.enterprises 6

7. Obstacle Driven Development Stages
Adding a Production stage created
Obstacle Driven Development with
Solution to be produced.
• Solutions designed in labs may
not work in practice
• Production ensures Solution is
produced with quality assured
and controlled
15/07/2016 ©odd.enterprises 7

8. Stages Verification + Validation
Between each stage of Obstacle
Driven Development there are tests
created to verify and validate.
• Verify is creating a test to ensure
it’s built in the right way
• Validate is passing a test to
ensure it’s built right
• Adapted as necessary between
other stages
15/07/2016 ©odd.enterprises 8

9. Stages Verification + Validation
Verification and Validation gives 2
directions of information flow with
feedforwards and feedback.
• Each stage is linked to the next
through creating tests
• Each stage is linked to the
previous through passing tests
• Feedforwards for progress
• Feedback for correction
15/07/2016 ©odd.enterprises 9

10. Stages + Domains
Production gives another stage to the Problem and Solution
domain with Quality Assured and Controlled.
15/07/2016 ©odd.enterprises 10

11. M-model Development
15/07/2016 ©odd.enterprises 11
Extending the N-model
with Production
creates the M-model.
• Checkpoints added
to consolidate each
stage with output
• Tests created and
passed between
each stage

12. M-model Development
M-model provides a path for
development with
Verification and Validation
through tests.
• Stages are alternatively
built up and broken down
• Ascending slope indicates
integration
• Descending slope
indicates decomposition
15/07/2016 ©odd.enterprises 12

13. Domains + M-model
Stages designed to model the
problem domain with testing
between each.
• Overlap represents testing
between stages
• Creating and solving tests acts as
interface between stages
• Operates similarly to Test Driven
Development
15/07/2016 ©odd.enterprises 13

14. M-model Elements
M-models divided into
stages and abstraction
levels to give elements.
• Stages contain all
required elements
• Creating through
integration or
decomposition
• Suppliers may supply
lower level products
15/07/2016 ©odd.enterprises 14

15. M-model Elements
Stages of the model are divided into elements through abstraction
levels and system divisions with each having a specific place.
15/07/2016 ©odd.enterprises 15

16. Stages + Process
15/07/2016 ©odd.enterprises 16
Stages are created using a process
of creating and solving tests.
• Process the same for each stage
but different methods to achieve
solutions
• Solutions to a stage become
obstacles to the next
• Stages

17. Stages + Process
15/07/2016 ©odd.enterprises 17
Solutions to each stage (in blue)
become obstacles (in red) to link
the next stage.
• Stages are both solutions and
obstacles
• Stages repeated until obstacles
are solved

18. Process + Verification + Validation
Verification and validation is
performed between each stage
through creating and solving tests.
• Creating a test first ensures we
are building the right thing
• Solving a test ensures we are
building it right
• We modify prior stages when we
determine errors with them
15/07/2016 ©odd.enterprises 18

19. OODA Inspired M-model
ODD combined with the
OODA model (Observe,
Orient, Decide, Act).
• Illustrates feedback to
the Analysis stage
• Shows importance of a
Specification to
development
• Decision block before
entering Production
15/07/2016 ©odd.enterprises 19

20. Abstraction Levels
Abstraction levels help
obstacles and solutions link
at all levels.
• Divides development into
appropriate levels
• High level abstractions are
integrated from lower
levels
• Lower level abstractions
are decomposed from
high levels
15/07/2016 ©odd.enterprises 20

21. Systems Division
Abstraction levels are
further divided into
individual systems and their
lower levels.
• Helps separate systems
from others for easier
testing and integration
• Systems division is
modelled throughout
stages
15/07/2016 ©odd.enterprises 21

22. 3D Pyramid Model
Combining models gives a 3D
model with Stages, Abstraction
levels and System Divisions.
• Progress on x-axis
• Abstraction levels on y-axis
• Systems division on z-axis
15/07/2016 ©odd.enterprises 22

23. Linking Models
Models are linked end to end
to allow development to
continuously improve.
• Models linked for new
products or creating
improved versions
• Combine as many models
as necessary
• Obstacles, tests and
solutions can be reused
15/07/2016 ©odd.enterprises 23

24. Flowchart
Flowcharts show how we
create products through
each stage.
• Process is similar for
each stage
• Create tests first,
solutions after
• Stages complete when
all tests are passed
15/07/2016 ©odd.enterprises 24

25. Flowchart + Feedback
Feedback between stages
allows modification of
previous stages within a
development cycle.
• Feedback when tests
or solutions are not
suitable
• Tests and/or solutions
may not correct
• Progress of stage
determines feedback
15/07/2016 ©odd.enterprises 25

26. Repeating M-models
M-models also repeat by folding in
on themselves which helps
continuous improvement.
• Consists of V and inverted V-
models
• Process and structure identical to
other forms
• Current and future products
developed concurrently
15/07/2016 ©odd.enterprises 26

27. Systems Engineering
Further stages may be added to
create models suitable for systems
engineering.
• Additional stages of Supply and
Assemble support hardware and
embedded
• Maintenance and Support to
help products and services
longevity
15/07/2016 ©odd.enterprises 27

28. Software Engineering + Sales
Other stages are added to the
systems engineering model as
necessary.
• Business obstacles and solutions
may be combined
• Helps determine effective
business strategies
15/07/2016 ©odd.enterprises 28

29. Hardware Engineering + Sales
Stages are added or removed as
necessary for development.
• Adding Supply and Assemble
added
• Maintenance and Support
removed
• Helps links Hardware and
Embedded engineering to a
business strategy
15/07/2016 ©odd.enterprises 29

30. ODDSAP (Supply Assemble Production)
Stages are added and
removed to create new
models.
• Stages added in pairs
which support
development
• Supply and Assemble
ensure hardware is
supplied and
assembled right
15/07/2016 ©odd.enterprises 30

31. OODA Inspired ODDSAP
Combining the ODDSAP
model with OODA shows
feedback and importance
of Specification.
• Feedback from each
stage to Analysis
• Implicit Guidance and
control from
Specification
15/07/2016 ©odd.enterprises 31

32. ASAP (Analysis Supply Assemble Production)
ASAP used when there is
insufficient time to perform
the required stages.
• Product is built quickly
with ODD stages to verify
and validate
• ODD performed
concurrently or after
15/07/2016 ©odd.enterprises 32

33. Generic Form
Generic form is
applicable between each
of the stages.
• Obstacle is a solution
from previous stage
• Target / Test creates a
test with assertion
• Solution solves the
test / achieves target
• Action is result of the
stage
15/07/2016 ©odd.enterprises 33

34. OBSA (Obstacle Behaviour Solution Action)
OBSA is the fundamental
process and method
behind ODD.
• Modified for different
fields including
business and medicine
• Fundamental to OODA
methods also
15/07/2016 ©odd.enterprises 34

35. Further Information and Questions
Website
Presentations
Facebook
Twitter
Email
15/07/2016 ©odd.enterprises 35

36. Legal Stuff
References
Test Driven Development for Embedded C
James Grenning, 2011
Digging into “Fail fast, fail often.”
http://agile.dzone.com/articles/digging-fail-fast-fail-often
Agile vs. Waterfall: How to Approach your Web Development Project
http://www.commonplaces.com/blog/agile-vs-waterfall-how-approach-
your-web-development-project
The Scrum Master Performance Review
http://illustratedagile.com/2011/12/13/the-scrum-master-
performance-review-preparation/
ScrumMaster
http://www.mountaingoatsoftware.com/agile/scrum/scrummaster
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.
15/07/2016 ©odd.enterprises 36