Obstacle Driven Development: Extending a Specification

38
Obstacle Driven Development Extending a Specification ©odd.enterprises 08/12/2014

Transcript of Obstacle Driven Development: Extending a Specification

Page 1: Obstacle Driven Development: Extending a Specification

Obstacle Driven Development

Extending a Specification

©odd.enterprises

08/12/2014

Page 2: Obstacle Driven Development: Extending a Specification

Obstacle Driven Development

08/12/2014 ©odd.enterprises 2

Page 3: Obstacle Driven Development: Extending a Specification

ODD Process and M-model

08/12/2014 ©odd.enterprises 3

Page 4: Obstacle Driven Development: Extending a Specification

ODD Components

08/12/2014 ©odd.enterprises 4

Page 5: Obstacle Driven Development: Extending a Specification

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

Page 6: Obstacle Driven Development: Extending a Specification

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

Page 7: Obstacle Driven Development: Extending a Specification

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

Page 8: Obstacle Driven Development: Extending a Specification

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

Page 9: Obstacle Driven Development: Extending a Specification

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

Page 10: Obstacle Driven Development: Extending a Specification

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

Page 11: Obstacle Driven Development: Extending a Specification

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

Page 12: Obstacle Driven Development: Extending a Specification

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

Page 13: Obstacle Driven Development: Extending a Specification

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

Page 14: Obstacle Driven Development: Extending a Specification

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

Page 15: Obstacle Driven Development: Extending a Specification

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

Page 16: Obstacle Driven Development: Extending a Specification

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

Page 17: Obstacle Driven Development: Extending a Specification

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

Page 18: Obstacle Driven Development: Extending a Specification

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

Page 19: Obstacle Driven Development: Extending a Specification

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

Page 20: Obstacle Driven Development: Extending a Specification

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

Page 21: Obstacle Driven Development: Extending a Specification

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

Page 22: Obstacle Driven Development: Extending a Specification

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

Page 23: Obstacle Driven Development: Extending a Specification

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

Page 24: Obstacle Driven Development: Extending a Specification

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

Page 25: Obstacle Driven Development: Extending a Specification

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

Page 26: Obstacle Driven Development: Extending a Specification

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

Page 27: Obstacle Driven Development: Extending a Specification

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

Page 28: Obstacle Driven Development: Extending a Specification

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

Page 29: Obstacle Driven Development: Extending a Specification

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

Page 30: Obstacle Driven Development: Extending a Specification

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?

Page 31: Obstacle Driven Development: Extending a Specification

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

Page 32: Obstacle Driven Development: Extending a Specification

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

Page 33: Obstacle Driven Development: Extending a Specification

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

Page 34: Obstacle Driven Development: Extending a Specification

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

Page 35: Obstacle Driven Development: Extending a Specification

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

Page 36: Obstacle Driven Development: Extending a Specification

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

Page 37: Obstacle Driven Development: Extending a Specification

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

Page 38: Obstacle Driven Development: Extending a Specification

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