ODD: Extending a Specification 2

Obstacle Driven Development

Extending a Specification 2

©odd.enterprises

26/02/2015

Obstacle Driven Development

26/02/2015 ©odd.enterprises 2

ODD Circle Model


ODD Traffic Light Model


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


Design Phases

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

• Requirement analysis

• Preliminary design

• Detailed design

• Implementation

• Testing

• Operations


Preliminary and Detailed Design

An ODD Specification is a combination of preliminary and detailed design.

• ODD Specification is a complete description of how a product should behave

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


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


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


Specification

A traditional specification is an interface between problem and solution domains.

• Description of design and materials which make a product

• Specification not used in all traditional processes

• Requirements are often used directly


Importance of a Specification

A specification can improve the development process of a product.

• Product cost is reduced with an improved specification process

• Using a full specification can prevent errors from propagating

• Creating and editing a specification is low cost


ODD Specification

ODD Specifications differ from traditional by being separated from problem and solution domains.

• Specification contains behaviours which cover requirements

• Fully separated from Analysis and Solution stages

• Links stages through appropriate unit tests


V-model

V-models formed the basic ODD structure and are often used in ISO developments.

• V-models inspired linking of elements for ODD

• Often used for safety critical design processes

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


Behaviours 1

Whatever is desired of a product can be expressed by its 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.


Behaviours 2

Separating a specification from requirements allows for greater freedom.

• Numerous behaviours may satisfy a requirement

• Alternative or back up behaviours are described and investigated

• Behaviours determined by analysis of situations


Behaviour Levels

Behaviours are described by their relative system levels.

• High level behaviours should describe how a product behaves

• Low level behaviours describe how materials behave

• Decomposition allows a deductive reasoning process

• Tests are linked to each level


Decomposition

Decomposition gives a top-down approach to the creation of a specification and product.

• Allows effective determination of lower level behaviours

• Unnecessary behaviours are not described

• Allows a deductive process for creating the specification


Documents Checkpoint

An ODD product has sufficient documentation to describe all expected behaviours.

• Documents describe everything a product does

• Decomposed from high level behaviours into components

• Intended for all stakeholders


ODD Specification 1

Each behaviour specified creates tests through decomposition and definition.

• Specified

– Used to describe a behaviour with no other detail

• Functional

– Describes what a behaviour does with inputs, outputs and internal states defined


ODD Specification 2

• Logical

– Describes an expected behaviour

– Expected behaviour creates assertions for unit tests

• Procedural

– Used for feedback against situation analysis

– Only used to ensure behaviours are verified and validated


ODD Specification 3

Specification is decomposed and defined starting with specified behaviour and moving to the right.

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

• Logical behaviour is expected or desired behaviour of a product


Specification Creation

Behaviours are decomposed and defined to create a specification and unit tests.

• Decomposition of high level behaviours into lower levels

• Definition of specified behaviours into logical behaviours

• Creation of tests through assertions to link a solution

22PDD, Jonathan Herring

Specified Behaviour

Specified behaviour regards what it is expected to do for input, output and internal states.

• No further detail

• Full specification linking all inputs with outputs to ensure nothing is left out

• Easy to understand, discuss, produce and edit


Functional Behaviour

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

• Input, outputs and internal states are defined with units

• Expands on basic description of a products behaviours

• Ensures behaviours link and combine into a complete specification


Logical Behaviour

Logical behaviour builds on functional behaviour by adding expectations.

• Detail is defined until expected behaviours are described

• Allows a complete description of a products expected behaviour

• Tests are created from assertions of expected behaviour


Modelled motor is a simple DC.

Procedural Behaviour

Procedural behaviour is a model or simulation of a product as seen by customers and other stakeholders.

• Ensures specification of a product is as required by customers and stakeholders

• Increases communication between developers and customers


Unit Testing

Unit tests and the Single Responsibility Theorem facilitate the testing process.

• Every element is tested

• Each test has a single result

• Unit tests are combined to give complex testing processes

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


Behaviour Driven Development 1

Behaviour Driven Development inspired the linking of a specification to a design solution.

• Each behaviour creates tests

• Multiple behaviours can be solved by a single solution

• Designing according to behaviours reduces ambiguity


Behaviour Driven Development 2

Reordering the BDD sequence gives a sequence similar to traffic lights.

• Red light now used for unverified and unvalidated processes

• Amber light now used when tests are created and code written

• Green light used when tests have been passed


Write Test

Write Code

Validate / Refactor

Behaviour

Implementing Unit Testing 1

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

• Initial stage of a specification describes responses to situations and stimulus

• Unit tests for output and/or internal change of a component

• Unit tests are integrated or decomposed as necessary


Implementing Unit Testing 2

Internal states are often impossible to observe directly and increase importance of creating low level unit tests.

• Unit tests combined to test complex behaviours

• Combined unit tests are also considered a unit test


Linking Tests 1

Tests link behaviours with solutions through testing and design.

• Solutions are designed to tests created

• Each solution is a single aspect of the product

• Unit testing is applied

• Test suite created


Linking Tests 2

Testing and design should concern behaviours contained in a specification.

• Customers are involved for utilisation and elicitation

• Each solution implements 1 or more behaviours

• Tests suite ran for any changes or additions


Creating Tests 1

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 tests reduces debugging

• Creation of tests and designs may continue until all behaviours are implemented


Creating Tests 2

A full test suite is created using each behaviour contained by a specification.

• Creating a test first ensures a developer understands their objective

• Design according to passing tests reduces ambiguity

• Passing a test ensures behaviour is implemented


Solution Unit Testing

Solution Design

• Select a behaviour

• Test for solution

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

• Design for solution

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


ODD Solution Flowchart

Flow chart to explain the creation of an ODD Solution.

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


ODD Combined Model


The testing process is similar throughout ODD with adaptions between stages.

• Each set of traffic light demonstrates unit testing

• Tests begin with an element from previous stage

Specification Unit Testing

Specification of behaviours

• Select a requirement

• Verification

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

• Validation

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


Linking Tests 3

Each situation creates a unit test to link analysis with specification.

• Diagrams shows various stages of testing progress

• Once unit test is passed it becomes green

• Tests are implemented as a suite and ran when editing occurs


Linking Tests 4

Each situation is linked to a behaviour contained in a specification.

• Behaviour A covers normal operation

• Behaviour B and C cover single failures of components

• Behaviour D covers total failure of components


Linking Tests 5

When using a waterfall type development then analysis is complete when all tests are passed.

• Tests run when any changes in analysis or specification

• Ensures expected situations are covered

• Potential for infinite situations


Cross Examination 1

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

• Identification of errors and contradictions before solution is designed

• Unit tests are created to verify behaviours with validation being a pass


Does Behaviour A cover Situation A?

Cross Examination 2

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

• Process used in development of a specification

• Unit tests implemented between situations and behaviours


ODD Specification Flowchart

Flow chart designed to explain creation of an ODD Specification.

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


ODD Flowchart


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

International 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/

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.


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

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

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

ODD: Extending a Specification 2

Engineering

Transcript of ODD: Extending a Specification 2