Obstacle Driven Development Stages

Obstacle Driven DevelopmentODD Stages

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

28/06/2016 ©odd.enterprises 2

Obstacle Driven Development


Motivation

Obstacle Driven Development addresses the following (and more) problems:

• How are tests created using Test Driven Development?

• How are requirements linked to behaviours?

• How can Agile principles be combined safety critical?


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 between each stage


ODD Stages

Waterfall stages are adapted to become ODD stages.

• Testing stage is removed and made implicit between stages

• Suitable for software development

• Extends to hardware and embedded

• More stages such as Supply and Assemble added if needed


ODD Circle Model

Shows stages of development with verification and validation.

• Similar to a set of traffic lights

• Four stages are used for development

• Stages linked through the creation and solving of tests


ODD Triangle Model

Alternative form demonstrating how stages combine for 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.

• Testing processes between blocks

• Each stage has a checkpoint


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


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


ODD Elements

ODD Elements describe each part of development with stage, system and abstraction level.

• Higher level elements will consist of combined lower levels

• 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 links Production and Specification stages with tests solved and created by each level.

• Analysis links Production by elicitation of customers

• Analysis links Specification by verification of behaviours


Specification Elements

Specification links Analysis and Solution stages with tests solved and created by each level.

• Specification links Analysis through solving of tests

• Specification links Solution through creation of tests


Solution Elements

Solution links Specification and Production stages with tests solved and created by each level.

• Solution links Specification by design according to tests

• Solution links Production by quality assurance tests according to solution


Production Elements

Production links Solution and Analysis stages with tests solved and created by each level.

• Production links Solution through quality control according to tests

• Production links Analysis through utilisation of products features


ODD Analysis 1

Analysis is

• situations expressed through combining simplest situation components

• individual situations integrated to create practical situations


ODD Analysis 2

Analysis integrated from 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


ODD Specification 2

Specification decomposed from high levels ensures these behaviours are maintained.

• Helps test ideas for solution before it is created

• Assumptions for a solution may be validated against analysis


ODD Solution 1

Solution is

• working example of a product from lowest to highest levels

• integrated from lowest levels required

• designed according to specification


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


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 with decomposition

• Quality assurance and control according to solution


Integration

Ascending slopes indicate integration of elements from lowest to highest required.

• Errors found by combining individual elements

• Processing hazards finds and prioritises requirements


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


Requirements Checkpoint

Consolidated Requirements is checkpoint for Analysis.

• Requirements 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


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

Obstacle Driven Development Stages

Design

Transcript of Obstacle Driven Development Stages