Obstacle Driven Development

Obstacle Driven Development
©odd.enterprises
05/05/2015

Obstacle Driven Development
05/05/2015 ©odd.enterprises 2

ODD Circle Model

ODD Triangle Model

ODD Process

ODD Traffic Light Model

ODD Flowchart

ODD M-model

Motivation
Obstacle Driven Development was
originally intended to address the
following problems:
• How are tests created using Test
Driven Development?
• How are requirements linked to
behaviours?
• How can agile principles be
combined safety critical?

ODD Objectives
ODD is a development process
which
• does not rely on knowledge or
experience
• determined by clear processes
and evidence
• verified and validated at all
stages
• fully linked, traceable and
testable

ODD Circle Model
Demonstrates how ODD stages are
linked throughout development by
verification and validation.
• Similar to a set of traffic lights
• Four stages are used for
development
• Each stage is linked through the
creation and passing of tests

ODD Triangle Model
Alternative form demonstrating
how each stage links development.
• Each stage responsible for
creation and solving of tests
• Stages link to form entire
development process
• Verification and validation
adapted for each stage

ODD M-model
M-model describes an entire
development process in a single
diagram.
• Coloured blocks implemented
using traditional engineering
• Testing processes described
between blocks
• Each stage has a checkpoint

Waterfall Development
Waterfall development is
considered a traditional method of
software development.
• Each stage “fixed” before moving
to next
• Changing requirements is an
issue with fixed stages
• Testing late in development
reduces time to fix errors

ODD is not Waterfall
ODD is different to Waterfall in a
number of ways.
• Development stages are not fixed
• Testing is implicit throughout
with unit tests
• Testing implemented between
each stage

Agile Development
Agile is a relatively recent approach
to product development designed
to be efficient and adaptable.
• 12 principles to guide
development teams in
implementing Agile projects
• Various methodologies including
SCRUM and Feature Driven
Development

ODD is not Agile
ODD is different to Agile in a
number of ways.
• Specification implemented
• Tests are created first
• ODD is suitable for hardware,
software and embedded
• Four stages to product
development

Agile Manifesto
The Agile manifesto describes what
is important for an Agile project.
• Invented by Kent Beck, James
Grenning et al.
• While both are important Agile
values the left over the right
• ODD uses a modified version
• Individuals and interactions over
processes and tools
• Working software over
comprehensive documentation
• Customer collaboration over
contract negotiation
• Responding to change over
following a plan
© Kent Beck, James Grenning et al.

ODD Manifesto
The manifesto for ODD is a
reworking of the Agile manifesto.
• Over is replaced by terms
illustrating how one can help
with others
• Emphasis on linking and
encouraging ODD processes
• Processes and tools which
encourage individuals and
interactions
• Working software through
comprehensive documentation
• Contract negotiation through
customer collaboration
• Following a plan which responds
to change

ODD is SOLID 1
ODD attempts to use SOLID
principles where possible.
• Single Responsibility Principle
implicit to ODD
• SRP enables integration and
decomposition
• All principles used when applied
to software

ODD is Solid 2
Representation as a 3D model with
structure similar to pyramids which
is made robust through testing.
• Each stage and testing process
combines to form a robust shape
• SOLID principles make ODD
possible
• 3D shape representative to ODD
when more than one system
makes a product

ODD is 3D

ODD without Tests

ODD with Tests

ODD with Passed Tests

ODD Attitude
Full implementation of ODD requires there to be complete,
consistent and sustained attempts to fail a product at any and all
stages of the development.
While it is potentially more costly and time intensive to develop
products using these methods, it is predicted that preventing
failure is worth more than the additional development costs.

ODD Logic
Cost of fixing undetected errors
grows exponentially the longer they
are undetected.
• Success easier to prove and
understand than failure
• More is learnt from failure
• Testing is 2x as difficult as coding
so tests are created first

Success and Failure
Success is defined as the lack of
failure and so is intrinsically linked
to learning from failure.
• Success and failure are
interrelated
• Failure can lead to success
• Success can lead to failure

Success from Failure 1
Obstacle Driven Development can
be described as an attempt to:
Achieve success by identifying,
correcting and preventing failures
as early, effectively and efficiently
as possible.

Success from Failure 2
“Failure is the opportunity to begin
again more intelligently.” – Henry
Ford
• More is learnt from failure than
success
• Many lives saved using lessons
learnt from Titanic

Failure from Success
Complacency resulting from
success can cause devolution to
failure.
• Success can often devolve into
failure
• Solutions made cheaper and
complacency increases
• Tacoma Narrows bridge based on
an successful design

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

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
• Non standard components
required this approach

Cost of Failure
Cost of failure is often greater than
associated costs related to a
successful development.
• Undetected errors may become
very costly
• Increased use of specification can
reduce costs overall
• Cost increases exponentially for
each stage a bug is undetected

Fail Early, Fail Often
Achieving success with ODD is
through identifying, correcting and
preventing failure.
• Undiscovered errors cost 10x
more to fix by next stage
• Errors become expensive to solve
• 2 stages missed ≈ 100x
• 3 stages missed ≈ 1000x

Development 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
• Waterfall development
• Agile principles

Test Driven Development 1
Obstacle Driven Development helps
define tests and extends TDD
throughout development.
Development of ODD began with
the question,
• Where do the tests come from?
Write
Test
Write
Code
Refactor

Test Driven Development 2
Obstacle Driven Development was
inspired by James Grenning’s book
Test Driven Development for
Embedded C.
• Describes TDD when applied to
hardware and embedded
• Useful for concurrent design of
software and hardware
• Increased testability improves
error detection and correction
Write
Test
Write
Code
Refactor

Behaviour Driven Development 1
Behaviour driven development has
been described as “TDD done
right”.
• Used for software development
• Suggests behaviours suitable for
testing and design
• ODD extends principle and
applies to all development stages
Write
Test
Write
Code
Refactor
Think

Behaviour Driven Development 2
Reordering a BDD sequence gives a
sequence similar to traffic lights.
• Red light for unverified and
unvalidated software
• Amber light when tests are
created and code written
• Green light when test has been
passed
Write
Test
Write
Code
Validate /
Refactor
Behaviour

Obstacle Driven Development 1
Tests 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 for
verification and validation
Verify
Solution
Solution for
Obstacle
Validate
Solution
Obstacle

Obstacle Driven Development finds
solutions to obstacles which are
broken into four stages of
development.
• Analysis
• Specification
• Solution
• Production
Verify
Solution
Solution for
Obstacle
Validate
Solution
Obstacle

The ODD Process is expressed using
four stages in sequence.
Diagram simplified to demonstrate
a basic ODD process.
• Analysis
• Specification
• Solution
• Production
Specification
Solution
Production
Analysis

Verification and validation are
applied to 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

V-model
V-models are adapted from
waterfall development and are
popular in engineering.
• V-model formed initial
framework for ODD
• Often used for safety critical
design processes
• Numerous V-models have been
created, some inspired by TDD

V-model Comparison
Development of ODD was initiated
after comparing V-model to a
problem domain.
• V-model does not adequately
cover a problem domain
processes at project end
• Specification not used effectively,
or at all

International Organisation for Standardisation 1
The International Organisation for
Standardisation (ISO) specify a
minimum behaviour of a products
to which it must conform.
By conforming to standards such as
ISO a product:
• Gains access to markets
• Described as state of the art
• Standardised development

International Organisation for Standardisation 2
The ISO have defined processes for
development from analysis through
to production.
• Analysis with Automotive Safety
Integrity Levels
• Standardised tests and
manoeuvres for vehicles
• Defined behaviours may be
adapted for unit tests

Extending a Specification 1
• Traditional Problem
and Solution Space
• Extended
Specification
49©odd.enterprises05/05/2015

Extending a Specification 2
Extending a specification allows V-
model development combined with
Test Driven Development.
• V-model with ASIL analysis
processes added
• TDD processes used for V&V of a
specification
• Specification used to create tests

N-model Comparison
N-model was created by extending
a V-model to allow for a
combination of requirements
analysis with TDD.
• Verification performed by
creating test from situations
• Validation from passing a test
• Interface between problem and
solution extended

Verification and Validation 1
Verification and validation occurs
between stages with appropriate
adaptions.
Verification and validation concern
the questions:
• Verification
Is it built in the right way?
• Validation
Is it built right?

Verification and Validation 2
Verification and validation are
adapted for each stage.
• Specification
– Verification and validation (of behaviours)
• Solution
– Testing and design
• Production
– Quality assurance and control
• Analysis
– Utilisation and elicitation

Requirements Analysis 1
Requirements analysis is performed
in numerous ways
• Spiral model
• Use case analysis
• Safety integrity levels
Requirements analysis spiral was
adapted to help define ODD.

Requirements Analysis 2
Comparing and mapping a Spiral
model led to an improved M-
model.
• Agreed behaviours replaces
Agreed Requirements
• Quality Assurance equivalent to
Testing
• Negotiation more less similar to
Verification

Problem and Solution Domains
• Traditional
• Proposed
56©odd.enterprises05/05/2015

ODD Problem Domain 1
• ODD problem domain solved
through four stages
using tests between stages

ODD Problem Domain 2
• Testing process adapted and
repeated for each stage
• Each stage separate and
linked through tests

ODD Model and Links
Problem and solution domain are
extended to model and link each
required stage.
• ODD M-model demonstrates
stages and testing
appropriate to each stage
• Extends V-model development

M-Model Comparison
ODD model uses four separate
stages linked through unit testing.
appropriate to each stage
• Development model has no fixed
stages
• Unit testing processes used to
link stages

ODD Elements
ODD Elements are a generic term to
describe single parts of
development divided into a stage
and product level.
• Higher level elements will consist
of combined lower levels (Molecules
is a more accurate term than elements)
• Each stage contains different and
distinct elements
• Relative height in M-model
indicates level of element

Element Levels
• Product
• System
• Subsystem
• Component
• Material
• Each is tested

Analysis Elements
Analysis elements link to
Production and Specification stages
with tests solved and created by
each level.
• Analysis links to Production
through elicitation of customer
experiences
• Analysis links to Specification
through verification of behaviour
elements

Behaviour Elements
Behaviour elements link to Analysis
and Solution stages with tests
solved and created by each level.
• Specification links to Analysis
through validation according to
tests
• Specification links to Solution
through creation of tests
according to behaviours

Solution Elements
Solution elements link to
Specification and Production stages
with tests solved and created by
each level.
• Solution links to Specification
through design according to tests
• Solution links to Production
through quality assurance tests
according to solution

Production Elements
Production elements link to
Solution and Analysis stages with
tests solved and created by each
level.
• Production links to Solution
through quality control according
to tests
• Production links to Analysis
through utilisation of a products
features and elements

ODD Analysis 1
Analysis is
• situations expressed through
combining the simplest situation
components
• individual situations integrated to
create practical situations
• situations processed using SILs to
give requirements

ODD Analysis 2
Analysis integrated from situations
which are processed as hazards
through use of Safety Integrity
Levels.
• Elicitation to ensure situations
and requirements are identified
• Safety Integrity Levels define
hazards through probability,
severity and controllability

ODD Specification 1
Specification is
• a full description of a solution
• decomposed from high level
specification
• separate from analysis and
solution
• interface to validate analysis and
create tests for solution

ODD Specification 2
Specification decomposed from
high levels to ensure these
behaviours are maintained.
• Tests the ideas for a solution
before it is created
• Assumptions for a solution may
be validated against analysis
• If all behaviours are described
then documentation is easier

ODD Solution 1
Solution is
• working example of a product
from lowest to highest levels
• integrated from lowest levels
required
• designed according to
specification
• used to provide quality assurance

ODD Solution 2
Solution integrated from low levels
to ensure design and testing with
bottom-up approach.
• Solution designed to pass tests
• Testability through unit tests and
test suite
• Concurrent design of embedded
software with hardware

ODD Production 1
Production is
• assembly and related activities of
producing a solution
• decomposed from a high level
solution
• controls production of solution
and enable utilisation of a
product

ODD Production 2
Production decomposed from high
levels to ensure an appropriate
solution is produced.
• Production organised through
decomposition
• Quality assurance and control
according to solution
• Once production is organised
then products are created

Top-down and Bottom-up Design
Information processing follows 2
basic directions which are top-
down and bottom-up.
• Top-down approach is essentially
a breaking down or
decomposition of a system
• Bottom-up approach is a piecing
together of systems to give rise
to more complex systems

Integration
Ascending slopes indicate
integration of elements from lowest
to highest required.
• Hazards found from combining
individual situations
• Processing hazards finds and
prioritises requirements
• Solution integrated from
individual components at
material level

Decomposition
Descending slopes indicate
decomposition of elements from
highest to lowest required.
• Decomposition allows for
material tests from system tests
• High level specification testing
and production assurance
• Top-down approach for
specification and production
gives efficient testing

Reversible Fault Finding 1
Development is reversible for error
identification and correction with
the approach reversed.
• Integrating specification or
production allows error detection
• Bottom-up approach for fault
finding of these stages
• Errors in decomposition
identified through integration

Reversible Fault Finding 2
Each stages initial approach is
reversed for fault finding to find
errors for correction.
• Decomposing analysis or solution
allows error detection
• Top-down approach for fault
finding of these stages
• Errors in integration identified
through decomposition

Linear and Nonlinear 1
ODD comprises linear development
stages with V & V creating a
nonlinear process.
• If no errors then development
proceeds through stages
• Errors are detected and cause is
identified and resolved through
feedback

Linear and Nonlinear 2
Snakes and ladders has similar
properties to an ODD process and
used for comparison.
• Ladders are passing tests which
allow progress and link stages
• Snakes are failing tests which halt
progress and/or force regression

ODD Checkpoints 1
Checkpoints provide an expected
output for each stage which is
compared to another.
• Requirements found from Analysis
• Documents described from
Specification
• Prototype integrated from Solution
• Product created by Production

ODD Checkpoints 2
Checkpoints are verified and
validated against those indicated.
• Requirements compared to
Prototype
• Prototype tested for Requirements
• Documents describe a Product
• Product documented in
Documents

ODD Checkpoints 3

Requirements Checkpoint
Consolidated Requirements is a
checkpoint for Analysis.
• Requirements are processed and
most important consolidated
• SILs ensure important
requirements are identified
• Expected situations covered for a
successful product

Documents Checkpoint
Sufficient documentation to
describe all expected behaviours.
• Documents describe all product
behaviours
• Decomposed from high level
behaviours to low level
• Allows creation of instructions
and manuals

Prototype Checkpoint
Integrated and tested solution
becomes a prototype.
• Created from integrated
solutions at various levels
• Ensures behaviours are covered
by a solution
• Working model or template of a
product is achieved

Product Checkpoint
Once production is complete then
working products are achieved.
• Production with decomposition
ensure high level solutions
• Decomposition ensures
production according to product
solution
• Assembly important at all levels
of production

Verification and Validation
Testing processes for verification
and validation link stages of
development.
• Stages given appropriate
• Each stage verifies next through
creation of tests
• Previous stage provides
validation by solving tests

Feedforward Processes
Verification of each stage is a
feedfoward process with tests
created by each stage.
• Verification
• Testing
• Quality assurance
• Utilisation

Feedback Processes
Validation is a feedback process
where tests from a previous stage
are passed.
• Validation
• Design
• Quality control
• Elicitation

Information Flow
Flow of information can proceed in
several directions using unit tests.
• Integration, decomposition,
feedback and feedforward
• Information flows through each
stage with integration or
decomposition
• Stages linked with tests provide
feedback and feedforward

Verification and Validation M-model

ODD Combined Model
ODD process and M-model give a
combined model with traffic lights
linking stages.
• Demonstrates how each stage is
linked to next
• Each traffic light set models a
unit testing process
• Linking of a stage is achieved
when all green lights

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

Linking Tests 1
Tests link behaviours with solutions
through testing and design.
• Solutions designed according to
tests from behaviours
• Each solution is a single element
of a product
• Unit testing is applied
• Test suite created and ran when
changes occur

Linking Tests 2
Testing and design concerns
solutions created from behaviours
of a specification.
• Each solution implements 1 or
more behaviours
• Tests suite ran for any changes or
additions
• Created as with Test Driven
Development

ODD Test Suites
Test suites implemented to create a
solution for software and identify
errors.
• Test suites contain individual and
combined unit tests
• Test suites are intended to be
implemented between all stages
• TDD process extended
throughout development to
create ODD

ODD Generic Flow Chart
Each stage of ODD is an adaption of
this generic flow chart.
Flow chart is adapted to provide:
• Analysis - Utilisation and
Elicitation
• Specification – Verification and
Validation
• Solution - Testing and Design
• Production – Quality Assurance
and Control

Creating Tests 1
Creation of solutions from a
specification inspired by Behaviour
Driven Development.
• Tests created by rewriting a
behaviour and designing test
• Design of solution according to
tests reduces debugging
• Testing and design may continue
until all behaviours are
implemented

Creating Tests 2
Full test suite created using each
behaviour contained in a
specification.
• Creating a test first ensures an
objective is understood
• Design according to passing tests
reduces ambiguity
• Passing a test ensures behaviour
is implemented

Creating Tests 3
Create tests by specifying whether
solution does a specified behaviour.
• Behaviour can help create a test
when rephrased
• Decomposing a specification
gives efficiency for creating tests
• Process adapted for each stage
System should have rise time less
than 1 second.
Does system have rise time of less
than 1 second?

ODD Analysis
Utilisation and elicitation 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
Customer
Utilisation
Situation
Analysis
Elicit
Customers
Feature

ODD Analysis Flowchart
Flow chart designed to explain
creation of ODD Analysis stage.
1. Product feature selected to be
analysed in situations
2. Elicitation test is created
3. Product is utilised
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until
elicitation is complete

ODD Specification
Specification describes behaviours
which cover expected situations
and requirements.
• Tests verify and validate whether
behaviours cover requirement
• Once expected situations are
covered and tests verified a
specification is complete
Verify
Specification
Specify
Behaviour
Validate
Specification
Requirement

ODD Specification Flowchart
creation of ODD Specification stage.
1. Requirement selected to be
covered by a behaviour
2. Verification test is created
3. Behaviour is specified
5. Repeat Stages 1 – 4 until all
behaviours are specified

ODD Solution
Specification allows creation of
tests and solutions based on
described behaviours.
• Solution describes individual and
integrated designs
• Solutions designed to pass tests
give increased testability
• Unit testing and test suites as
with Test Driven Development
Create Test
Design
Solution
Pass
Test
Behaviour

ODD Solution Flowchart
creation of ODD Solution stage.
1. Behaviour selected to be
covered by a solution
2. Unit test is created
3. Solution is designed
behaviours are specified

ODD Production
Production organised directly from
a solution to give assured and
controlled quality.
• Solution ensures continuous and
predictable quality
• Quality assurance tests are
created
• Number of passes a measure for
quality control
Assure
Product
Quality
Produce
Product
Control
Product
Quality
Solution

ODD Production Flowchart
creation of ODD Production stage.
1. Solution selected to be
produced
2. Quality assurance test created
3. Production process
production is assured

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

Fire Triangle 1
A fire triangle is an educational tool
for understanding and preventing
fires.
• If fire triangle is completed then
a fire will occur
• Preventing one of components
will prevent a fire
• Requirements often regard
preventing fires

Fire Triangle 2
Reordering a fire triangle gives a
diagram which demonstrates
component interactions for a fire.
• Situations are constructed using
a tree diagram
• Constructing situations from
their components allow analysis
of any

Fire Triangle 3
Using a reordered fire triangle it is
seen that components combine to
create a hazard.
• Process is adaptable to all fire
hazards and environments
• Extendible to any number of
situations
• SIL ratings for Probability,
Severity and Controllability

Fire Decision Tree
Rearranging a fire triangle results in
a decision tree to demonstrate the
various situations.
• Each resulting situation can be
analysed for hazards
• Clearly defined situations are
created
• Situations can then be linked to
behaviours
Oxygen is assumed to be present in diagram.

Linking Behaviours to Situations 1
Decision tree adaptable to any
situation and linked to a
specification by creating tests.
• Any situation can be described by
a decision tree
• Diagram appropriate for failure
mode effects and analysis
• Linked to a behaviour which
covers the situation

Linking Behaviours to Situations 2
Each branch of a decision tree
results in a situation to be covered
by one or more behaviours.
• Each situation is tested to ensure
coverage by specification
• Ensures situations are covered
before creation of solution
• All expected situations should
have an associated behaviour

Linking Solution to Production 1
Solution must be produced with
consistent quality and often for
very large quantities.
• Each element of a solution
assures and controls quality of
related production
• Tests are created for quality
assurance
• Tests passed give measure for
quality control

Linking Solution to Production 2
Each element of a solution creates
a quality assurance test which a
production element must pass.
• Quality assurance and control
based on probability and
statistics
• Assurance will determine an
acceptable failure rate
• Control ensures failure rate is
acceptable

Linking Production to Analysis 1
Linking production to analysis
ensures product features are
utilised and elicited.
• Features of product utilised in
practical situations by customers
• Elicitation after utilisation of
feature to find requirements
• Verifies current solutions and
identifies new obstacles

Linking Production to Analysis 2
Linking production to analysis has
product features used as this is how
a customer sees a product.
• New feature may cover
requirement but create another
• Each product element and level
investigated separately

ODD Experimental Model 1
ODD is designed and generic and
has wide uses with adaptions to
solve different obstacles.
• Model adapted and used to plan,
conduct and repeat experiments
• Checkpoints and testing replaced
as appropriate for science
• Repeatable until Theorem
becomes Thesis

Experimental model has a large
number of uses to help with
research and development.
• Theories are tested at each stage
of development
• Verification and validation are
implicit throughout

ODD Control Model 1
Control model for development of
controllers and related solutions.
• Analysis model for all expected
situations
• Specification describes how
solution should behave
• Solution chosen from one or
several available
• Production is how the solution is
applied

ODD Control Model 2
Controller developed using each
stage to identify errors and correct
them.
• Analysis identifies process and
requirements
• Specification describe behaviours
• Solution decides which control
theory to use
• Production builds and
implements a controller

ODD Control Model 3

ODD Agile Flowchart 1
Combining flowcharts without
checkpoints gives a process similar
to Agile development.
• Begins with a situation from
analysis to specify behaviours
• Each ODD flowchart is combined
to produce flowchart for entire
process

ODD Agile Flowchart 2

ODD Waterfall Flowchart 1
Combining flowcharts gives a
process which can be presented
similarly to Waterfall development.
• Begins with selecting a feature to
process requirements
• Each ODD flowchart has been
combined with checkpoints
• No stage is fixed and is adapted
according to tests and new
situations

ODD Waterfall Flowchart 2

ODD Waterfall with Feedback 1
Full flowchart model of an ODD
development.
• Decisions added give options for
when tests are not passed
• Branch in lighter colour is
repetition of analysis stage
• Indicates how development is
continued or adapted

ODD Waterfall with Feedback 2

ODD Organisation
Four stages structure project
management of a developments
organisation.
• Overview of all stages and
• Each stage and tests are
observed and managed
• Partnerships between colleagues
managed and maintained

ODD Burndown Chart
An ODD burndown chart simply
replaces tasks completed and
remaining with tests.
• Tests to pass used as an estimate
for time remaining
• Tasks not tested may result in
errors leading to overrun

V-model v. ODD

ISO V-model v. ODD

Waterfall v. ODD

Requirements Spiral v. ODD Requirements

Software Development v. ODD

Traditional Domains v. ODD Domains

Unit Tests v. ODD Unit Tests

Further Information and Questions
• Website
• Presentations
• Facebook
• Twitter
• Email

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
Contact us for more information on sources and references.
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.

Obstacle Driven Development

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Obstacle Driven Development

Similaire à Obstacle Driven Development (20)

Plus de Jonathan Herring

Plus de Jonathan Herring (9)

Dernier

Dernier (20)

Obstacle Driven Development