Date post: | 10-Aug-2015 |
Category: |
Documents |
Upload: | jonathan-herring |
View: | 66 times |
Download: | 1 times |
Obstacle Driven Development
Extending a Specification
©odd.enterprises
08/12/2014
Obstacle Driven Development
08/12/2014 ©odd.enterprises 2
ODD Process and M-model
08/12/2014 ©odd.enterprises 3
ODD Components
08/12/2014 ©odd.enterprises 4
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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