Post on 22-Feb-2017
Obstacle Driven DevelopmentODD Stages
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
28/06/2016 ©odd.enterprises 2
Obstacle Driven Development
28/06/2016 ©odd.enterprises 3
Motivation
Obstacle Driven Development addresses the following (and more) problems:
• How are tests created using Test Driven Development?
• How are requirements linked to behaviours?
• How can Agile principles be combined safety critical?
28/06/2016 ©odd.enterprises 4
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
28/06/2016 ©odd.enterprises 5
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 between each stage
28/06/2016 ©odd.enterprises 6
ODD Stages
Waterfall stages are adapted to become ODD stages.
• Testing stage is removed and made implicit between stages
• Suitable for software development
• Extends to hardware and embedded
• More stages such as Supply and Assemble added if needed
28/06/2016 ©odd.enterprises 7
ODD Circle Model
Shows stages of development with verification and validation.
• Similar to a set of traffic lights
• Four stages are used for development
• Stages linked through the creation and solving of tests
28/06/2016 ©odd.enterprises 8
ODD Triangle Model
Alternative form demonstrating how stages combine for development.
• Each stage responsible for creation and solving of tests
• Stages link to form entire development process
• Verification and validation adapted for each stage
28/06/2016 ©odd.enterprises 9
ODD M-model
M-model describes an entire development process in a single diagram.
• Testing processes between blocks
• Each stage has a checkpoint
28/06/2016 ©odd.enterprises 10
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
28/06/2016 ©odd.enterprises 11
ODD Problem Domain 1
• ODD problem domain solved through four stages
• Verification and validation using tests between stages
28/06/2016 ©odd.enterprises 12
ODD Problem Domain 2
• Testing process adapted and repeated for each stage
• Each stage separate and linked through tests
28/06/2016 ©odd.enterprises 13
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
28/06/2016 ©odd.enterprises 14
ODD Elements
ODD Elements describe each part of development with stage, system and abstraction level.
• Higher level elements will consist of combined lower levels
• Each stage contains different and distinct elements
• Relative height in M-model indicates level of element
28/06/2016 ©odd.enterprises 15
Element Levels
• Product
• System
• Subsystem
• Component
• Material
• Each is tested
28/06/2016 ©odd.enterprises 16
Analysis Elements
Analysis links Production and Specification stages with tests solved and created by each level.
• Analysis links Production by elicitation of customers
• Analysis links Specification by verification of behaviours
28/06/2016 ©odd.enterprises 17
Specification Elements
Specification links Analysis and Solution stages with tests solved and created by each level.
• Specification links Analysis through solving of tests
• Specification links Solution through creation of tests
28/06/2016 ©odd.enterprises 18
Solution Elements
Solution links Specification and Production stages with tests solved and created by each level.
• Solution links Specification by design according to tests
• Solution links Production by quality assurance tests according to solution
28/06/2016 ©odd.enterprises 19
Production Elements
Production links Solution and Analysis stages with tests solved and created by each level.
• Production links Solution through quality control according to tests
• Production links Analysis through utilisation of products features
28/06/2016 ©odd.enterprises 20
ODD Analysis 1
Analysis is
• situations expressed through combining simplest situation components
• individual situations integrated to create practical situations
28/06/2016 ©odd.enterprises 21
ODD Analysis 2
Analysis integrated from 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
28/06/2016 ©odd.enterprises 22
ODD Specification 1
Specification is
• a full description of a solution
• decomposed from high level specification
• separate from analysis and solution
28/06/2016 ©odd.enterprises 23
ODD Specification 2
Specification decomposed from high levels ensures these behaviours are maintained.
• Helps test ideas for solution before it is created
• Assumptions for a solution may be validated against analysis
28/06/2016 ©odd.enterprises 24
ODD Solution 1
Solution is
• working example of a product from lowest to highest levels
• integrated from lowest levels required
• designed according to specification
28/06/2016 ©odd.enterprises 25
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
28/06/2016 ©odd.enterprises 26
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
28/06/2016 ©odd.enterprises 27
ODD Production 2
Production decomposed from high levels to ensure an appropriate solution is produced.
• Production organised with decomposition
• Quality assurance and control according to solution
28/06/2016 ©odd.enterprises 28
Integration
Ascending slopes indicate integration of elements from lowest to highest required.
• Errors found by combining individual elements
• Processing hazards finds and prioritises requirements
28/06/2016 ©odd.enterprises 29
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
28/06/2016 ©odd.enterprises 30
Requirements Checkpoint
Consolidated Requirements is checkpoint for Analysis.
• Requirements processed and most important consolidated
• SILs ensure important requirements are identified
• Expected situations covered for a successful product
28/06/2016 ©odd.enterprises 31
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
28/06/2016 ©odd.enterprises 32
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
28/06/2016 ©odd.enterprises 33
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
28/06/2016 ©odd.enterprises 34
Further Information and Questions
• Website
• Presentations
28/06/2016 ©odd.enterprises 35
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.
28/06/2016 ©odd.enterprises 36