Download - 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

ValidateSolution

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

ValidateSolution

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 verification and validation


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

• Verification and validation 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 05/05/2015 ©odd.enterprises 53

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

• Verification and validation 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

• Verification and validation appropriate to each stage

• Extends V-model development


M-Model Comparison

ODD model uses four separate stages linked through unit testing.

• Verification and validation 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 verification and validation

• 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


CustomerUtilisation

Situation Analysis

ElicitCustomers

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

SpecifyBehaviour

Validate Specification

Requirement

ODD Specification Flowchart

Flow chart designed to explain 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

PassTest

Behaviour

ODD Solution Flowchart

Flow chart designed to explain creation of ODD Solution stage.

1. Behaviour selected to be covered by a solution

2. Unit test is created

3. Solution is designed


5. Repeat Stages 1 – 4 until all 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 ProductQuality

Solution

ODD Production Flowchart

Flow chart designed to explain creation of ODD Production stage.

1. Solution selected to be produced

2. Quality assurance test created

3. Production process


5. Repeat Stages 1 – 4 until all 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 verification and validation

• 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


http://odd.enterprises/

http://www.odd.enterprises/odd-presentations.html

https://www.facebook.com/odd.enterprises

https://twitter.com/odd_enterprises

mailto:[email protected]

Legal Stuff

ReferencesTest 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.

DisclaimerThe 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.


http://en.wikipedia.org/wiki/Test-driven_development

http://en.wikipedia.org/wiki/Behavior-driven_development

http://en.wikipedia.org/wiki/Unit_testing

Download - Obstacle Driven Development

Top Related