Obstacle Driven Development

Extending a Specification

©odd.enterprises

08/12/2014

Obstacle Driven Development

08/12/2014 ©odd.enterprises 2

ODD Process and M-model

08/12/2014 ©odd.enterprises 3

ODD Components

08/12/2014 ©odd.enterprises 4

Background

Ideas of Obstacle Driven Development (ODD) are based on numerous development processes including:

• ISO V-model

• Test Driven Development

• ISO specifications

• Requirements analysis

• Agile principles

08/12/2014 ©odd.enterprises 5

Design Phases

A traditional design process have several phases to produce a product.

• Requirement analysis

• Preliminary design

• Detailed design

• Implementation

• Testing

• Operations

08/12/2014 ©odd.enterprises 6

Preliminary and Detailed Design

When related to other engineering processes then ODD Specification is a combination of preliminary and detailed design.

• ODD Specification should be a complete description of how the product should behaves

• ODD Specification should contain only descriptions, up to and including simulations

08/12/2014 ©odd.enterprises 7

International Organisation for Standardisation 1

The International Organisation for Standardisation (ISO) specify the minimum behaviour that is expected of products which must conform.

By conforming to standards such as ISO a product:

• Gains access to markets

• Can be described as state of the art

• Limits legislative exposure

08/12/2014 ©odd.enterprises 8

International Organisation for Standardisation 2

The ISO have defined processes for analysis and specifications.

Obstacle Driven Development was created by following a summary of ISO 26262 "Road vehicles –Functional safety“ and has been designed to be compatible.

• Other standards bodies such as the IEC have similar processes.

The ten parts of ISO 26262:1. Vocabulary

2. Management of functional safety

3. Concept phase

4. Product development at the system level

5. Product development at the hardware level

6. Product development at the software level

7. Production and operation

8. Supporting processes

9. Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analysis

10. Guideline on ISO 26262

08/12/2014 ©odd.enterprises 9

Specification

A definition of a specification

• detailed description of the design and materials used to make something

• Diagram shows how specification is not a separate stage

• Creation of specification is not used in all traditional processes, often requirements are used directly

08/12/2014 ©odd.enterprises 10

Importance of the Specification

The diagram shows how a specification can be used to improve the development process of a model.

• Shows how product cost is limited by an improved specification process

• Using a full specification can prevent errors from propagating

• Editing a specification is low cost

08/12/2014 ©odd.enterprises 11

ODD Specification

An ODD specification differs from the traditional by being separated from the requirements.

• Specification is a list of behaviours which cover the requirements

• Fully separated from the Analysis and Solution stages

• Links stages through appropriate unit tests

08/12/2014 ©odd.enterprises 12

V-model

A V-model formed the basic of ODD structure and is often used in ISO developments.

• V-models formed the basic framework for ODD

• Often used for safety critical design processes

• Numerous V-models have been created, some inspired by TDD

08/12/2014 ©odd.enterprises 13

Behaviours 1

Whatever is desired of a product can be expressed in the behaviours.

A definition of a behaviour is

• how an animal or person behaves in response to a particular situation or stimulus.

Replacing the subject with product

• how a product behaves in response to a particular situation or stimulus.

08/12/2014 ©odd.enterprises 14

Behaviours 2

Separating the specification from the requirements allows for greater freedom.

• Numerous behaviours may satisfy a requirement

• Alternative or back up behaviours are described and investigated

• Behaviours can be determined by analysis of situations

08/12/2014 ©odd.enterprises 15

Decomposition

Decomposition is used in an ODD specification to ensure that a top-down approach is used.

• Allows effective determination of lower level behaviours

• Unnecessary behaviours are not described

• Allows a deductive process for creating the specification

08/12/2014 ©odd.enterprises 16

Behaviour Levels

Using ODD the behaviours can be described as levels.

• High level behaviours should describe how the product behaves

• Low level behaviours should describe how the materials used behave

• Decomposition allows a deductive reasoning process

08/12/2014 ©odd.enterprises 17

Documents Checkpoint

When using a product there should be sufficient documentation to describe all the behaviours expected of it.

• Documents should describe everything the product does

• Decomposed from high level behaviours into components

• Intended for all stakeholders

08/12/2014 ©odd.enterprises 18

ODD Behaviour 1

For each behaviour specified a process is used to create tests by building descriptions.

• Specified

– Used only to describe what the behaviour does

• Functional

– Used to describe what the behaviour does with inputs, outputs and internal states defined

08/12/2014 ©odd.enterprises 19

ODD Behaviour 2

• Logical

– Used to describe what is the expected behaviour

– From the expected behaviour assertions are defined for unit tests

• Procedural

– Used for feedback against the situation analysis

– Only used to ensure behaviours are verified and validated

08/12/2014 ©odd.enterprises 20

ODD Behaviour 3

Starting from specified behaviour and moving to the right we use the specification decomposition and definition.

• Specified behaviour has inputs and outputs defined to become functional behaviour

• Logical behaviour is expected or desired behaviour of the product

08/12/2014 ©odd.enterprises 21

Unit Testing

Unit tests are used in order to facilitate the testing process.

• Every stage is tested

• Each test has a single result

• Unit tests can be combined to give complex testing processes

• Green light is for when tests are passed and previous stage linked

08/12/2014 ©odd.enterprises 22

Implementing Unit Testing 1

Any process has the result of an output and/or change in internal state.

• Initial stage of the specification is to describe responses to situations and stimulus

• Unit tests should test either the output or internal change of a component

08/12/2014 ©odd.enterprises 23

Implementing Unit Testing 2

Internal states are often impossible to observe directly therefore increasing the importance of creating tests first and as units.

• Combining unit tests allows testing of combined behaviours

• Unit tests can be combined to test complex behaviours

• Combined unit tests should also be considered a unit test

08/12/2014 ©odd.enterprises 24

Specification Creation

The diagram shows the collected processes for creating a specification.

• Decomposition of high level behaviours into lower levels

• Definition of specified behaviours into logical behaviours

• Allows creation of tests through assertions to link with the Solution

25PDD, Jonathan Herring

Specified Behaviour

Specified behaviour is simply what the behaviour is expected to do with regards to input, output and internal states.

• No further detail

• Creates a basic description of the product behaviours

• Easy to understand, discuss, produce and edit

08/12/2014 ©odd.enterprises 26

Functional Behaviour

Functional behaviour expands the specified behaviour by adding input, output and internal states.

• Input, outputs and internal states are defined using their units

• Expands on the basic description of the product behaviours

• Used to ensure the behaviours link and combine into a complete specification

08/12/2014 ©odd.enterprises 27

Logical Behaviour

Logical behaviour builds on the functional behaviour by adding expectations.

• Detail is built up until behaviour expectations are produced

• Allows a complete description of the products expected behaviour

• Using expectations we can create tests from the specification

Modelled motor is a simple DC.

08/12/2014 ©odd.enterprises 28

Procedural Behaviour

Procedural behaviour can be considered a model or simulation of the product as seen by the customer and other stakeholders.

• Used to ensure specification of the product is as required by customers and stakeholders

• Increases communication between developers and customers

08/12/2014 ©odd.enterprises 29

Cross Examination 1

Failing products may result in litigation and therefore a cross examination of the products behaviours are applicable.

• Process could identify errors and contradictions before the solution is implemented

• Unit tests are created to verify behaviours with validation the result of a pass

08/12/2014 ©odd.enterprises 30

Does Behaviour A cover Situation A?

Cross Examination 2

Cross examination is where behaviours are compared with situations to find errors and contradictions.

• It is proposed the process can be used in the development of a specification

• Unit tests are implemented between situations and behaviours

08/12/2014 ©odd.enterprises 31

Specification Unit Testing

Analysis of situations

• Verification

– Create a test to ensure a situation is covered by a behaviour

Specification of behaviours

• Validation

– Pass a test ensuring a situation is covered by a behaviour

08/12/2014 ©odd.enterprises 32

Solution Unit Testing

Specification of behaviours

• Testing

– Create a test to ensure a behaviour is covered by a solution

Creation of Solution

• Design

– Pass a test to ensure a behaviour is covered by a solution

08/12/2014 ©odd.enterprises 33

Creating Tests 1

The creation of a solution from a specification is inspired by Behaviour Driven Development.

• Often tests can be created by simply rewriting a behaviour

• Designing a solution according to the tests ensures validation

• Creation of tests and designs continue until all behaviours are covered

08/12/2014 ©odd.enterprises 34

Creating Tests 2

We can create a full set of tests using each behaviour contained within the specification.

• Creating a test first ensures the designer understands what is required of the solution

• Designing according to passing tests reduces ambiguity

• Passing a test ensures the requirement is fulfilled

08/12/2014 ©odd.enterprises 35

ODD Specification Flowchart

A flow chart has been designed to explain the creation of an ODD Specification.

1. A situation is selected which has to be covered by a behaviour

2. Verification test is created

3. Behaviour is specified

4. If fail repeat Stage 3

5. Repeat Stages 1 – 4 until all behaviours are specified

08/12/2014 ©odd.enterprises 36

ODD Solution Flowchart

A flow chart has been designed to explain the creation of an ODD Specification.

1. A behaviour is selected which has to be covered by a solution

2. Unit test is created

3. Solution is designed

4. If fail repeat Stage 3

5. Repeat Stages 1 – 4 until all behaviours are specified

08/12/2014 ©odd.enterprises 37

Legal Stuff

ReferencesInternational Organisation for Standardisation

http://www.iso.org/iso/home/standards.htm

NASA, Assurance Process for Complex Electronics

www.hq.nasa.gov/office/codeq/software/ComplexElectronics/

Test Driven Development for Embedded C

James Grenning, 2011

Assessment of the ISO 26262 Standard

http://www.sae.org/events/gim/presentations/2012/qi_volpe.pdf

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.

08/12/2014 ©odd.enterprises 38