ODD: Extending Test Driven Development 1.3

Obstacle Driven DevelopmentExtending Test Driven Development 1.3

©odd.enterprises14/12/2015

http://odd.enterprises/


Obstacle Driven Development

14/12/2015 ©odd.enterprises 2



ODD Circle Model




ODD Triangle 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 spiral

• Agile principles

• SOLID principles




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

• Testing is required to ensure products perform




Test Driven Development 1

Test Driven Development is software development where tests are written before code.

• Creating tests first ensures code is tested and testable

• Unit tests ran through test suites for automated testing

• Improved code through early error detection


Write Test

Write Code

Refactor




Tests are written before the code with TDD .

1. Test is written and ran to observe a fail

2. Simplest code is written to pass the test

3. Code is refactored according to SOLID principles

4. Repeat until coding complete


Write Test

Write Code

Refactor




Development of ODD began with a question when using TDD:

• Where do the tests come from?


Write Test

Write Code

Refactor



Behaviour Driven Development

• Often described as “Test Driven Development done right”

• Behaviours implemented for testing and design

• Additional stage of thinking about tests

• Increased efficiency over TDD


Write Test

Write Code

Refactor

Think



ODD Behaviour Driven Development

Redesigning a BDD sequence gives one similar to traffic lights.

1. Red light for behaviour to be coded

2. Amber light when tests are created

3. Code written and tested

4. Green light when tests are passed

5. Repeat until specification is coded


Write Test

Write Code

Validate / Refactor

Behaviour



ODD Process 1

ODD process becomes generic to create a new development model.

• Applications to hardware, software and embedded

• Links obstacles with tests for verification and validation

• Refactoring included in Validate Solution


Verify Solution

Solution for Obstacle

ValidateSolution

Obstacle



ODD Process 2

Obstacles are divided into four stages of development with ODD:

• Analysis

• Specification

• Solution

• Production


Verify Solution

Solution for Obstacle

ValidateSolution

Obstacle



ODD Process 2




Obstacle Driven Development 1

ODD Process is adapted and repeated between four stages in sequence.

• Analysis

• Specification

• Solution

• Production


Specification

Solution

Production

Analysis



Obstacle Driven Development 2

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




ODD for Embedded

Obstacle Driven Development is designed for software, hardware and embedded.

• Stages are defined to help create physical products

• Benefits of software, hardware and embedded principles

• Suitable for safety critical applications




ODD Circle Model

Stages are linked throughout with verification and validation.

• Modelled on traffic lights

• Four or more stages for product development

• Each stage linked through creation of tests




ODD Verification and Validation

Appropriate verification and validation links each stage.

• Specification– Verification and validation

• Solution– Testing and design

• Production– Quality assurance and control

• Analysis– Utilisation and elicitation




Linking Tests 1

Behaviours link with solutions through testing and design.

• Solutions designed according to tests from behaviours

• Each test has a single result –pass or fail

• Unit testing with test suite

• Tests ran when changes occur




Linking Tests 2

Testing and design of solutions from behaviours of a specification.

• Each solution implements 1 or more behaviours

• Tests suite ran with any changes or extensions

• Created according to TDD principles




ODD Solution

Solution created from specification through behaviour tests

• Red light for behaviour contained in specification

• Amber light when test for behaviour is created

• Green light when solution designed to pass test


Create Test

Design Solution

PassTest

Behaviour



ODD Production

Production created from solution through quality assurance and control.

• Red light for a solution with no quality assurance and control

• Amber light when test to assure quality is created

• Green light when quality control is passed


Assure Product Quality

Produce Product

Control ProductQuality

Solution



ODD Analysis

Analysis performed on production features through tests.

• Red light for no utilisation and elicitation of feature

• Amber light when test for customer utilisation is created

• Green light when tests for customer elicitation is passed


CustomerUtilisation

Situation Analysis

ElicitCustomers

Feature



ODD Specification

Specification created from analysis through requirement tests.

• Red light for a requirement

• Amber light when verification test is created

• Green light when test passed and behaviour validated


Verify Specification

SpecifyBehaviour

Validate Specification

Requirement



ODD Process Flow Chart

ODD is also expressed through flowcharts.

• Loops for repetition until solutions are found

• Decisions to loop made by testing

• Pass all tests to start next stage




ODD Process Flow Chart

Each flowchart is similar with a test created before a solution.

• We continue to create a solution until it passes test

• We repeat steps for all obstacles

• Once all obstacles are tested and pass we move to next stage




Flow Chart for Solution

1. Select behaviour which a solution has to perform.

2. Test created to ensure solution performs behaviour.

3. Solution designed to pass test.

4. Repeat until solution passes test.

5. Repeat until behaviours tested and solutions designed.

6. Production stage begins.




Flowchart for Production

1. Select solution which production is to create.

2. Quality assurance test ensures production creates solution.

3. Production begins.

4. Repeat until quality is controlled.

5. Repeat until all production is quality controlled.

6. Analysis stage begins.




Flowchart for Analysis

1. Select feature to be elicited for analysis.

2. Utilisation test is created for feature.

3. Product is utilised by customers.

4. Repeat elicitation until sufficient feedback obtained.

5. Repeat until all features in production are tested.

6. Specification stage begins.




Flowchart for Specification

1. Requirement selected to be covered by behaviour.

2. Verification test is created.

3. Behaviour is specified according to the test.

4. Repeat until behaviour is validated.

5. Repeat until all requirements are covered by behaviours.

6. Solution stage begins.




ODD Combined Flowchart 1




ODD Combined Flowchart 2




Unit Testing

Unit tests facilitate ODD when ran through test suites.

• Every stage is tested

• Tests are created from an element of the previous stage

• Each test has a single result

• Combined to give complex test with single result




ODD Test Suites

Test suites help create a solution and identify errors.

• Test suites contain individual and combined unit tests

• Test suites implemented between all stages

• TDD process extended throughout development




Linking Stages, Tests and Elements

• Situation A is analysed

– Verify and validate Behaviour A

• Behaviour A covers Situation A

– Testing and design of Solution A

• Solution A implements Behaviour A

– Quality assurance and control of Production A

• Production A implements Solution A

– Utilisation and elicitation of Situation A




ODD Elements

• ODD Elements describe individual levels and stages of development


• Elements are linked through tests at same level and between stages



ODD Element Levels

Element describes a stage and level from material to product and analysis to production.

A Product consists of:

• Systems; which consist of

• Subsystems; which consist of

• Components; which consist of

• Materials




ODD Element Testing

Testing is separated into levels and linked to the same levels of each stage.

• System level tests to link systems

• Subsystem level tests to link subsystems

• Component level tests to link components

• Material level tests for materials




Specification Elements and Testing

Specification elements link to Analysis and Solution stages.

• Specification links to Analysis through Validation

• Specification links to Solution through Testing




Solution Elements and Testing

Solution elements link to Specification and Production stages.

• Solution links to Specification through Design

• Solution links to Production through quality Assurance




Production Elements and Testing


Production elements link to Solution and Analysis stages.

• Production links to Solution through quality Control

• Production links to Analysis through Utilisation



Analysis Elements and Testing

Analysis elements link to Production and Specification stages.

• Analysis links to Production through Elicitation of customers

• Analysis links to Specification through Verification of behaviour




ODD Continuous Process

• Process repeats for continuous improvement

• Further stages may be added

• Proceed clockwise through each stage




ODD Materials

ODD is explained in further presentations.

• Obstacle Driven

Development

• ODD: Requirements Analysis

• ODD: Extending a

Specification

• ODD: Extending TDD

• ODD: Extending V-models

• ODD Is Not Agile or Waterfall

ODD Is Not Agile or

Waterfall

Obstacle Driven Development

ODD: Requirements

Analysis

ODD: Extending a Specification

ODD: Extending V-models

ODD: Extending TDD




http://www.odd.enterprises/obstacle-driven-development.html

http://www.odd.enterprises/odd-requirements-analysis.html

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

http://www.odd.enterprises/odd-extending-tdd.html

http://www.odd.enterprises/odd-extending-v-models.html

http://www.odd.enterprises/odd-is-not-agile.html

Further Information and Questions

• odd.enterprises

• Presentations

• Facebook

• Twitter

• Email




http://www.odd.enterprises/home.html

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

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

ODD: Extending Test Driven Development 1.3

Software

Transcript of ODD: Extending Test Driven Development 1.3