obstacle driven development
Post on 10-Aug-2015
226 Views
Preview:
TRANSCRIPT
Motivation
Obstacle Driven Development was originally intended to address the following problems:
• How are tests created using Test Driven Development?
• How are requirements linked to behaviours?
• How can agile principles be combined safety critical?
05/05/2015 ©odd.enterprises 9
ODD Objectives
ODD is a development process which
• does not rely on knowledge or experience
• determined by clear processes and evidence
• verified and validated at all stages
• fully linked, traceable and testable
05/05/2015 ©odd.enterprises 10
ODD Circle Model
Demonstrates how ODD stages are linked throughout development by verification and validation.
• Similar to a set of traffic lights
• Four stages are used for development
• Each stage is linked through the creation and passing of tests
05/05/2015 ©odd.enterprises 11
ODD Triangle Model
Alternative form demonstrating how each stage links development.
• Each stage responsible for creation and solving of tests
• Stages link to form entire development process
• Verification and validation adapted for each stage
05/05/2015 ©odd.enterprises 12
ODD M-model
M-model describes an entire development process in a single diagram.
• Coloured blocks implemented using traditional engineering
• Testing processes described between blocks
• Each stage has a checkpoint
05/05/2015 ©odd.enterprises 13
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
05/05/2015 ©odd.enterprises 14
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 implemented between each stage
05/05/2015 ©odd.enterprises 15
Agile Development
Agile is a relatively recent approach to product development designed to be efficient and adaptable.
• 12 principles to guide development teams in implementing Agile projects
• Various methodologies including SCRUM and Feature Driven Development
05/05/2015 ©odd.enterprises 16
ODD is not Agile
ODD is different to Agile in a number of ways.
• Specification implemented
• Tests are created first
• ODD is suitable for hardware, software and embedded
• Four stages to product development
05/05/2015 ©odd.enterprises 17
Agile Manifesto
The Agile manifesto describes what is important for an Agile project.
• Invented by Kent Beck, James Grenning et al.
• While both are important Agile values the left over the right
• ODD uses a modified version
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
© Kent Beck, James Grenning et al.
05/05/2015 ©odd.enterprises 18
ODD Manifesto
The manifesto for ODD is a reworking of the Agile manifesto.
• Over is replaced by terms illustrating how one can help with others
• Emphasis on linking and encouraging ODD processes
• Processes and tools which encourage individuals and interactions
• Working software through comprehensive documentation
• Contract negotiation through customer collaboration
• Following a plan which responds to change
05/05/2015 ©odd.enterprises 19
ODD is SOLID 1
ODD attempts to use SOLID principles where possible.
• Single Responsibility Principle implicit to ODD
• SRP enables integration and decomposition
• All principles used when applied to software
05/05/2015 ©odd.enterprises 20
ODD is Solid 2
Representation as a 3D model with structure similar to pyramids which is made robust through testing.
• Each stage and testing process combines to form a robust shape
• SOLID principles make ODD possible
• 3D shape representative to ODD when more than one system makes a product
05/05/2015 ©odd.enterprises 21
ODD Attitude
Full implementation of ODD requires there to be complete, consistent and sustained attempts to fail a product at any and all stages of the development.
While it is potentially more costly and time intensive to develop products using these methods, it is predicted that preventing failure is worth more than the additional development costs.
05/05/2015 ©odd.enterprises 26
ODD Logic
Cost of fixing undetected errors grows exponentially the longer they are undetected.
• Success easier to prove and understand than failure
• More is learnt from failure
• Testing is 2x as difficult as coding so tests are created first
05/05/2015 ©odd.enterprises 27
Success and Failure
Success is defined as the lack of failure and so is intrinsically linked to learning from failure.
• Success and failure are interrelated
• Failure can lead to success
• Success can lead to failure
05/05/2015 ©odd.enterprises 28
Success from Failure 1
Obstacle Driven Development can be described as an attempt to:
Achieve success by identifying, correcting and preventing failures as early, effectively and efficiently as possible.
05/05/2015 ©odd.enterprises 29
Success from Failure 2
“Failure is the opportunity to begin again more intelligently.” – Henry Ford
• More is learnt from failure than success
• Many lives saved using lessons learnt from Titanic
05/05/2015 ©odd.enterprises 30
Failure from Success
Complacency resulting from success can cause devolution to failure.
• Success can often devolve into failure
• Solutions made cheaper and complacency increases
• Tacoma Narrows bridge based on an successful design
05/05/2015 ©odd.enterprises 31
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
05/05/2015 ©odd.enterprises 32
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
• Non standard components required this approach
05/05/2015 ©odd.enterprises 33
Cost of Failure
Cost of failure is often greater than associated costs related to a successful development.
• Undetected errors may become very costly
• Increased use of specification can reduce costs overall
• Cost increases exponentially for each stage a bug is undetected
05/05/2015 ©odd.enterprises 34
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
05/05/2015 ©odd.enterprises 35
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
05/05/2015 ©odd.enterprises 36
Test Driven Development 1
Obstacle Driven Development helps define tests and extends TDD throughout development.
Development of ODD began with the question,
• Where do the tests come from?
05/05/2015 ©odd.enterprises 37
Write Test
Write Code
Refactor
Test Driven Development 2
Obstacle Driven Development was inspired by James Grenning’s book Test Driven Development for Embedded C.
• Describes TDD when applied to hardware and embedded
• Useful for concurrent design of software and hardware
• Increased testability improves error detection and correction
05/05/2015 ©odd.enterprises 38
Write Test
Write Code
Refactor
Behaviour Driven Development 1
Behaviour driven development has been described as “TDD done right”.
• Used for software development
• Suggests behaviours suitable for testing and design
• ODD extends principle and applies to all development stages
05/05/2015 ©odd.enterprises 39
Write Test
Write Code
Refactor
Think
Behaviour Driven Development 2
Reordering a BDD sequence gives a sequence similar to traffic lights.
• Red light for unverified and unvalidated software
• Amber light when tests are created and code written
• Green light when test has been passed
05/05/2015 ©odd.enterprises 40
Write Test
Write Code
Validate / Refactor
Behaviour
Obstacle Driven Development 1
Tests to verify and validate code are extended and adapted to create a new development model.
• Applications to hardware, software and embedded
• Links stages with tests for verification and validation
05/05/2015 ©odd.enterprises 41
Verify Solution
Solution for Obstacle
ValidateSolution
Obstacle
Obstacle Driven Development 2
Obstacle Driven Development finds solutions to obstacles which are broken into four stages of development.
• Analysis
• Specification
• Solution
• Production
05/05/2015 ©odd.enterprises 42
Verify Solution
Solution for Obstacle
ValidateSolution
Obstacle
Obstacle Driven Development 3
The ODD Process is expressed using four stages in sequence.
Diagram simplified to demonstrate a basic ODD process.
• Analysis
• Specification
• Solution
• Production
05/05/2015 ©odd.enterprises 43
Specification
Solution
Production
Analysis
Obstacle Driven Development 4
Verification and validation are applied to 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
05/05/2015 ©odd.enterprises 44
V-model
V-models are adapted from waterfall development and are popular in engineering.
• V-model formed initial framework for ODD
• Often used for safety critical design processes
• Numerous V-models have been created, some inspired by TDD
05/05/2015 ©odd.enterprises 45
V-model Comparison
Development of ODD was initiated after comparing V-model to a problem domain.
• V-model does not adequately cover a problem domain
• Verification and validation processes at project end
• Specification not used effectively, or at all
05/05/2015 ©odd.enterprises 46
International Organisation for Standardisation 1
The International Organisation for Standardisation (ISO) specify a minimum behaviour of a products to which it must conform.
By conforming to standards such as ISO a product:
• Gains access to markets
• Described as state of the art
• Standardised development
05/05/2015 ©odd.enterprises 47
International Organisation for Standardisation 2
The ISO have defined processes for development from analysis through to production.
• Analysis with Automotive Safety Integrity Levels
• Standardised tests and manoeuvres for vehicles
• Defined behaviours may be adapted for unit tests
05/05/2015 ©odd.enterprises 48
Extending a Specification 1
• Traditional Problem and Solution Space
• Extended Specification
49©odd.enterprises05/05/2015
Extending a Specification 2
Extending a specification allows V-model development combined with Test Driven Development.
• V-model with ASIL analysis processes added
• TDD processes used for V&V of a specification
• Specification used to create tests
05/05/2015 ©odd.enterprises 50
N-model Comparison
N-model was created by extending a V-model to allow for a combination of requirements analysis with TDD.
• Verification performed by creating test from situations
• Validation from passing a test
• Interface between problem and solution extended
05/05/2015 ©odd.enterprises 51
Verification and Validation 1
Verification and validation occurs between stages with appropriate adaptions.
Verification and validation concern the questions:
• Verification
Is it built in the right way?
• Validation
Is it built right?
05/05/2015 ©odd.enterprises 52
Verification and Validation 2
Verification and validation are adapted for each stage.
• Specification
– Verification and validation (of behaviours)
• Solution
– Testing and design
• Production
– Quality assurance and control
• Analysis
– Utilisation and elicitation 05/05/2015 ©odd.enterprises 53
Requirements Analysis 1
Requirements analysis is performed in numerous ways
• Spiral model
• Use case analysis
• Safety integrity levels
Requirements analysis spiral was adapted to help define ODD.
05/05/2015 ©odd.enterprises 54
Requirements Analysis 2
Comparing and mapping a Spiral model led to an improved M-model.
• Agreed behaviours replaces Agreed Requirements
• Quality Assurance equivalent to Testing
• Negotiation more less similar to Verification
05/05/2015 ©odd.enterprises 55
ODD Problem Domain 1
• ODD problem domain solved through four stages
• Verification and validation using tests between stages
05/05/2015 ©odd.enterprises 57
ODD Problem Domain 2
• Testing process adapted and repeated for each stage
• Each stage separate and linked through tests
05/05/2015 ©odd.enterprises 58
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
05/05/2015 ©odd.enterprises 59
M-Model Comparison
ODD model uses four separate stages linked through unit testing.
• Verification and validation appropriate to each stage
• Development model has no fixed stages
• Unit testing processes used to link stages
05/05/2015 ©odd.enterprises 60
ODD Elements
ODD Elements are a generic term to describe single parts of development divided into a stage and product level.
• Higher level elements will consist of combined lower levels (Molecules
is a more accurate term than elements)
• Each stage contains different and distinct elements
• Relative height in M-model indicates level of element
05/05/2015 ©odd.enterprises 61
Element Levels
• Product
• System
• Subsystem
• Component
• Material
• Each is tested
05/05/2015 ©odd.enterprises 62
Analysis Elements
Analysis elements link to Production and Specification stages with tests solved and created by each level.
• Analysis links to Production through elicitation of customer experiences
• Analysis links to Specification through verification of behaviour elements
05/05/2015 ©odd.enterprises 63
Behaviour Elements
Behaviour elements link to Analysis and Solution stages with tests solved and created by each level.
• Specification links to Analysis through validation according to tests
• Specification links to Solution through creation of tests according to behaviours
05/05/2015 ©odd.enterprises 64
Solution Elements
Solution elements link to Specification and Production stages with tests solved and created by each level.
• Solution links to Specification through design according to tests
• Solution links to Production through quality assurance tests according to solution
05/05/2015 ©odd.enterprises 65
Production Elements
05/05/2015 ©odd.enterprises 66
Production elements link to Solution and Analysis stages with tests solved and created by each level.
• Production links to Solution through quality control according to tests
• Production links to Analysis through utilisation of a products features and elements
ODD Analysis 1
Analysis is
• situations expressed through combining the simplest situation components
• individual situations integrated to create practical situations
• situations processed using SILs to give requirements
05/05/2015 ©odd.enterprises 67
ODD Analysis 2
Analysis integrated from situations which are processed as 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
05/05/2015 ©odd.enterprises 68
ODD Specification 1
Specification is
• a full description of a solution
• decomposed from high level specification
• separate from analysis and solution
• interface to validate analysis and create tests for solution
05/05/2015 ©odd.enterprises 69
ODD Specification 2
Specification decomposed from high levels to ensure these behaviours are maintained.
• Tests the ideas for a solution before it is created
• Assumptions for a solution may be validated against analysis
• If all behaviours are described then documentation is easier
05/05/2015 ©odd.enterprises 70
ODD Solution 1
Solution is
• working example of a product from lowest to highest levels
• integrated from lowest levels required
• designed according to specification
• used to provide quality assurance
05/05/2015 ©odd.enterprises 71
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
• Concurrent design of embedded software with hardware
06/05/2015 ©odd.enterprises 72
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
05/05/2015 ©odd.enterprises 73
ODD Production 2
Production decomposed from high levels to ensure an appropriate solution is produced.
• Production organised through decomposition
• Quality assurance and control according to solution
• Once production is organised then products are created
06/05/2015 ©odd.enterprises 74
Top-down and Bottom-up Design
Information processing follows 2 basic directions which are top-down and bottom-up.
• Top-down approach is essentially a breaking down or decomposition of a system
• Bottom-up approach is a piecing together of systems to give rise to more complex systems
06/05/2015 ©odd.enterprises 75
Integration
Ascending slopes indicate integration of elements from lowest to highest required.
• Hazards found from combining individual situations
• Processing hazards finds and prioritises requirements
• Solution integrated from individual components at material level
05/05/2015 ©odd.enterprises 76
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
• Top-down approach for specification and production gives efficient testing
05/05/2015 ©odd.enterprises 77
Reversible Fault Finding 1
Development is reversible for error identification and correction with the approach reversed.
• Integrating specification or production allows error detection
• Bottom-up approach for fault finding of these stages
• Errors in decomposition identified through integration
05/05/2015 ©odd.enterprises 78
Reversible Fault Finding 2
Each stages initial approach is reversed for fault finding to find errors for correction.
• Decomposing analysis or solution allows error detection
• Top-down approach for fault finding of these stages
• Errors in integration identified through decomposition
06/05/2015 ©odd.enterprises 79
Linear and Nonlinear 1
ODD comprises linear development stages with V & V creating a nonlinear process.
• If no errors then development proceeds through stages
• Errors are detected and cause is identified and resolved through feedback
05/05/2015 ©odd.enterprises 80
Linear and Nonlinear 2
Snakes and ladders has similar properties to an ODD process and used for comparison.
• Ladders are passing tests which allow progress and link stages
• Snakes are failing tests which halt progress and/or force regression
05/05/2015 ©odd.enterprises 81
ODD Checkpoints 1
Checkpoints provide an expected output for each stage which is compared to another.
• Requirements found from Analysis
• Documents described from Specification
• Prototype integrated from Solution
• Product created by Production
05/05/2015 ©odd.enterprises 82
ODD Checkpoints 2
Checkpoints are verified and validated against those indicated.
• Requirements compared to Prototype
• Prototype tested for Requirements
• Documents describe a Product
• Product documented in Documents
05/05/2015 ©odd.enterprises 83
Requirements Checkpoint
Consolidated Requirements is a checkpoint for Analysis.
• Requirements are processed and most important consolidated
• SILs ensure important requirements are identified
• Expected situations covered for a successful product
05/05/2015 ©odd.enterprises 85
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
05/05/2015 ©odd.enterprises 86
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
05/05/2015 ©odd.enterprises 87
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
05/05/2015 ©odd.enterprises 88
Verification and Validation
Testing processes for verification and validation link stages of development.
• Stages given appropriate verification and validation
• Each stage verifies next through creation of tests
• Previous stage provides validation by solving tests
05/05/2015 ©odd.enterprises 89
Feedforward Processes
Verification of each stage is a feedfoward process with tests created by each stage.
• Verification
• Testing
• Quality assurance
• Utilisation
05/05/2015 ©odd.enterprises 90
Feedback Processes
Validation is a feedback process where tests from a previous stage are passed.
• Validation
• Design
• Quality control
• Elicitation
05/05/2015 ©odd.enterprises 91
Information Flow
Flow of information can proceed in several directions using unit tests.
• Integration, decomposition, feedback and feedforward
• Information flows through each stage with integration or decomposition
• Stages linked with tests provide feedback and feedforward
05/05/2015 ©odd.enterprises 92
ODD Combined Model
ODD process and M-model give a combined model with traffic lights linking stages.
• Demonstrates how each stage is linked to next
• Each traffic light set models a unit testing process
• Linking of a stage is achieved when all green lights
05/05/2015 ©odd.enterprises 94
ODD Flow Chart
Flow chart to demonstrate a generic ODD process.
Problems or obstacles to be overcome are divided into 4 stages with appropriate testing.
• Analysis
• Specification
• Solution
• Production
05/05/2015 ©odd.enterprises 95
Linking Tests 1
Tests link behaviours with solutions through testing and design.
• Solutions designed according to tests from behaviours
• Each solution is a single element of a product
• Unit testing is applied
• Test suite created and ran when changes occur
05/05/2015 ©odd.enterprises 96
Linking Tests 2
Testing and design concerns solutions created from behaviours of a specification.
• Each solution implements 1 or more behaviours
• Tests suite ran for any changes or additions
• Created as with Test Driven Development
05/05/2015 ©odd.enterprises 97
ODD Test Suites
Test suites implemented to create a solution for software and identify errors.
• Test suites contain individual and combined unit tests
• Test suites are intended to be implemented between all stages
• TDD process extended throughout development to create ODD
05/05/2015 ©odd.enterprises 98
ODD Generic Flow Chart
Each stage of ODD is an adaption of this generic flow chart.
Flow chart is adapted to provide:
• Analysis - Utilisation and Elicitation
• Specification – Verification and Validation
• Solution - Testing and Design
• Production – Quality Assurance and Control
05/05/2015 ©odd.enterprises 99
Creating Tests 1
Creation of solutions from a specification inspired by Behaviour Driven Development.
• Tests created by rewriting a behaviour and designing test
• Design of solution according to tests reduces debugging
• Testing and design may continue until all behaviours are implemented
05/05/2015 ©odd.enterprises 100
Creating Tests 2
Full test suite created using each behaviour contained in a specification.
• Creating a test first ensures an objective is understood
• Design according to passing tests reduces ambiguity
• Passing a test ensures behaviour is implemented
05/05/2015 ©odd.enterprises 101
Creating Tests 3
Create tests by specifying whether solution does a specified behaviour.
• Behaviour can help create a test when rephrased
• Decomposing a specification gives efficiency for creating tests
• Process adapted for each stage
System should have rise time less than 1 second.
Does system have rise time of less than 1 second?
05/05/2015 ©odd.enterprises 102
ODD Analysis
Utilisation and elicitation to verify and validate product features.
• Once product features are utilised then elicitation can proceed as validation
• Process links stages and allows continuous improvement and adaption
05/05/2015 ©odd.enterprises 103
CustomerUtilisation
Situation Analysis
ElicitCustomers
Feature
ODD Analysis Flowchart
Flow chart designed to explain creation of ODD Analysis stage.
1. Product feature selected to be analysed in situations
2. Elicitation test is created
3. Product is utilised
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until elicitation is complete
05/05/2015 ©odd.enterprises 104
ODD Specification
Specification describes behaviours which cover expected situations and requirements.
• Tests verify and validate whether behaviours cover requirement
• Once expected situations are covered and tests verified a specification is complete
05/05/2015 ©odd.enterprises 105
Verify Specification
SpecifyBehaviour
Validate Specification
Requirement
ODD Specification Flowchart
Flow chart designed to explain creation of ODD Specification stage.
1. Requirement selected 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
05/05/2015 ©odd.enterprises 106
ODD Solution
Specification allows creation of tests and solutions based on described behaviours.
• Solution describes individual and integrated designs
• Solutions designed to pass tests give increased testability
• Unit testing and test suites as with Test Driven Development
05/05/2015 ©odd.enterprises 107
Create Test
Design Solution
PassTest
Behaviour
ODD Solution Flowchart
Flow chart designed to explain creation of ODD Solution stage.
1. Behaviour selected 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
05/05/2015 ©odd.enterprises 108
ODD Production
Production organised directly from a solution to give assured and controlled quality.
• Solution ensures continuous and predictable quality
• Quality assurance tests are created
• Number of passes a measure for quality control
05/05/2015 ©odd.enterprises 109
Assure Product Quality
Produce Product
Control ProductQuality
Solution
ODD Production Flowchart
Flow chart designed to explain creation of ODD Production stage.
1. Solution selected to be produced
2. Quality assurance test created
3. Production process
4. If fail repeat Stage 3
5. Repeat Stages 1 – 4 until all production is assured
05/05/2015 ©odd.enterprises 110
Linking Stages, Tests and Elements
• Situation A is analysed
– Tests verify and validate Behaviour A
• Behaviour A covers Situation A
– Testing and design of Solution A
• Solution A implements Behaviour A
– Tests for quality assurance and control of Production A
• Production A implements Solution A
– Tests for utilisation and elicitation of product Situation A
05/05/2015 ©odd.enterprises 111
Fire Triangle 1
A fire triangle is an educational tool for understanding and preventing fires.
• If fire triangle is completed then a fire will occur
• Preventing one of components will prevent a fire
• Requirements often regard preventing fires
05/05/2015 ©odd.enterprises 112
Fire Triangle 2
Reordering a fire triangle gives a diagram which demonstrates component interactions for a fire.
• Situations are constructed using a tree diagram
• Constructing situations from their components allow analysis of any
05/05/2015 ©odd.enterprises 113
Fire Triangle 3
Using a reordered fire triangle it is seen that components combine to create a hazard.
• Process is adaptable to all fire hazards and environments
• Extendible to any number of situations
• SIL ratings for Probability, Severity and Controllability
05/05/2015 ©odd.enterprises 114
Fire Decision Tree
Rearranging a fire triangle results in a decision tree to demonstrate the various situations.
• Each resulting situation can be analysed for hazards
• Clearly defined situations are created
• Situations can then be linked to behaviours
Oxygen is assumed to be present in diagram.
05/05/2015 ©odd.enterprises 115
Linking Behaviours to Situations 1
Decision tree adaptable to any situation and linked to a specification by creating tests.
• Any situation can be described by a decision tree
• Diagram appropriate for failure mode effects and analysis
• Linked to a behaviour which covers the situation
05/05/2015 ©odd.enterprises 116
Linking Behaviours to Situations 2
Each branch of a decision tree results in a situation to be covered by one or more behaviours.
• Each situation is tested to ensure coverage by specification
• Ensures situations are covered before creation of solution
• All expected situations should have an associated behaviour
05/05/2015 ©odd.enterprises 117
Linking Solution to Production 1
05/05/2015 ©odd.enterprises 118
Solution must be produced with consistent quality and often for very large quantities.
• Each element of a solution assures and controls quality of related production
• Tests are created for quality assurance
• Tests passed give measure for quality control
Linking Solution to Production 2
05/05/2015 ©odd.enterprises 119
Each element of a solution creates a quality assurance test which a production element must pass.
• Quality assurance and control based on probability and statistics
• Assurance will determine an acceptable failure rate
• Control ensures failure rate is acceptable
Linking Production to Analysis 1
05/05/2015 ©odd.enterprises 120
Linking production to analysis ensures product features are utilised and elicited.
• Features of product utilised in practical situations by customers
• Elicitation after utilisation of feature to find requirements
• Verifies current solutions and identifies new obstacles
Linking Production to Analysis 2
05/05/2015 ©odd.enterprises 121
Linking production to analysis has product features used as this is how a customer sees a product.
• New feature may cover requirement but create another
• Each product element and level investigated separately
ODD Experimental Model 1
05/05/2015 ©odd.enterprises 122
ODD is designed and generic and has wide uses with adaptions to solve different obstacles.
• Model adapted and used to plan, conduct and repeat experiments
• Checkpoints and testing replaced as appropriate for science
• Repeatable until Theorem becomes Thesis
ODD Experimental Model 2
05/05/2015 ©odd.enterprises 123
Experimental model has a large number of uses to help with research and development.
• Theories are tested at each stage of development
• Verification and validation are implicit throughout
ODD Control Model 1
Control model for development of controllers and related solutions.
• Analysis model for all expected situations
• Specification describes how solution should behave
• Solution chosen from one or several available
• Production is how the solution is applied
05/05/2015 ©odd.enterprises 125
ODD Control Model 2
Controller developed using each stage to identify errors and correct them.
• Analysis identifies process and requirements
• Specification describe behaviours
• Solution decides which control theory to use
• Production builds and implements a controller
05/05/2015 ©odd.enterprises 126
ODD Agile Flowchart 1
Combining flowcharts without checkpoints gives a process similar to Agile development.
• Begins with a situation from analysis to specify behaviours
• Each ODD flowchart is combined to produce flowchart for entire process
05/05/2015 ©odd.enterprises 128
ODD Waterfall Flowchart 1
Combining flowcharts gives a process which can be presented similarly to Waterfall development.
• Begins with selecting a feature to process requirements
• Each ODD flowchart has been combined with checkpoints
• No stage is fixed and is adapted according to tests and new situations
05/05/2015 ©odd.enterprises 130
ODD Waterfall with Feedback 1
Full flowchart model of an ODD development.
• Decisions added give options for when tests are not passed
• Branch in lighter colour is repetition of analysis stage
• Indicates how development is continued or adapted
05/05/2015 ©odd.enterprises 132
ODD Organisation
Four stages structure project management of a developments organisation.
• Overview of all stages and verification and validation
• Each stage and tests are observed and managed
• Partnerships between colleagues managed and maintained
05/05/2015 ©odd.enterprises 134
ODD Burndown Chart
An ODD burndown chart simply replaces tasks completed and remaining with tests.
• Tests to pass used as an estimate for time remaining
• Tasks not tested may result in errors leading to overrun
05/05/2015 ©odd.enterprises 135
Further Information and Questions
• Website
• Presentations
05/05/2015 ©odd.enterprises 143
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.
05/05/2015 ©odd.enterprises 144
top related