Upload
jonathan-herring
View
165
Download
1
Embed Size (px)
Citation preview
Obstacle Driven Development
Extending Requirements Analysis 2
©odd.enterprises
26/02/2015
Obstacle Driven Development
26/02/2015 ©odd.enterprises 2
ODD Circle Model
26/02/2015 ©odd.enterprises 3
ODD Process
26/02/2015 ©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
26/02/2015 ©odd.enterprises 5
About Requirements Analysis
Requirements analysis encompasses tasks that determine the needs or conditions necessary for a new or altered product.
Tasks necessary for requirements analysis include:
• Analysing, documenting, validating and managing software or system requirements
• Identify and resolve conflicting requirements of stakeholders
• Identifying business needs or opportunities using testable and traceable processes
26/02/2015 ©odd.enterprises 6
Requirements Analysis 1
Requirements analysis spiral and Safety Integrity Levels are adapted to give ODD processes.
Requirements analysis is performed in numerous ways
• Spiral model
• Use case analysis
• Safety integrity Levels (SILs)
26/02/2015 ©odd.enterprises 7
Requirements Analysis 2
A spiral model is superimposed with an M-model and adaptions made.
• Agreed Behaviours substitutes Agreed Requirements
• Quality Assurance equivalent to Testing
• Negotiation similar to Verification
26/02/2015 ©odd.enterprises 8
Requirements Analysis 3
Further adaption leads to an ODD model for requirements analysis.
• Product, Consolidated Requirements and Documents are checkpoints
• Verification substituted for Negotiation
• Validation substitutes Evaluation
• Testing substitutes Quality Assurance
26/02/2015 ©odd.enterprises 9
ODD Analysis
Requirements analysis is adapted to allow for ODD and combined with the first stages of an M-model.
• Safety Integrity Levels used to measure and process hazards
• Decision tree approach used to create situations
• Verification and validation of specification
26/02/2015 ©odd.enterprises 10
ODD M-model
Adding Solution and Production stages of development results in an ODD M-model.
• ODD process is linked from start to finish, and beyond
• Verification and validation between all stages
• Tests are ran as additions and editing occurs
26/02/2015 ©odd.enterprises 11
ODD M-model Checkpoints 1
Checkpoints are determined for the solution and production stages.
• Prototype created from integrated solution
• Product is result of production
• Linked to other checkpoints horizontally
26/02/2015 ©odd.enterprises 12
ODD M-model Checkpoints 2
Checkpoints allow linking and testing of results to previous stages.
• Each checkpoint links another
• Prototype fulfils identified requirements
• Product should behave as described in documents
26/02/2015 ©odd.enterprises 13
Fire Triangle 1
A fire triangle is an educational tool for understanding and preventing fires.
• If the fire triangle is completed then a fire will occur
• Preventing one situation from occurring will prevent a fire
• Requirements often regard preventing fires
26/02/2015 ©odd.enterprises 14
Fire Triangle 2
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 fire hazard situations
• Components can be given SIL ratings for Probability, Severity and Controllability
26/02/2015 ©odd.enterprises 15
Fire Triangle 3
Reordering again gives a decision tree for fire prevention.
• Investigated for requirements of a situation
• Each branch is analysed and processed
• Useful for any and all fire hazards
• To simplify oxygen is assumed present
26/02/2015 ©odd.enterprises 16
Fire Triangle 4
Decision tree shows the hazards of each situation.
• Top branch ignites a fire
• Next 2 branches are fire hazards
• Each situation is analysed separately
26/02/2015 ©odd.enterprises 17
Probability Tree 1
Probability trees measure likelihood of an event occurring from a defined situation.
• A common example is probability of coin tosses
• Probability of heads occurring assumed to be 50%
• Each branch gives an individual situation
26/02/2015 ©odd.enterprises 18
Heads 50%
Heads 50%
Tails 50%
Tails 50%
Heads 50%
Tails 50%
Binomial Distribution 1
Binomial distributions determine probability for any number of events with 2 possible outcomes.
• Binomial process illustrates how decision trees can be extended
• Potential use to model complex interactions
26/02/2015 ©odd.enterprises 19
Binomial Distribution 2
Binomial distributions determines probability for any number of events with 2 possible outcomes.
• Decision trees can be extended for infinite number of events
• Only used to model true or false experiments
𝑃 𝑋 = 𝑘 =𝑛𝑘
𝑝𝑘(1 − 𝑝)𝑛−𝑘
𝑃 𝑋 = 𝑘 = Probability of Event
𝑘 = Number of Events
𝑛 = Number of Trials
26/02/2015 ©odd.enterprises 20
Probability Tree 2
Coin toss example is extended into engineering by substituting system components.
• Working component replaces heads
• Failing component replaces tails
• Potential hazards of a series of failures can be determined
26/02/2015 ©odd.enterprises 21
Component 1Pass 99%
Component 2Pass 98%
Component 2Fail 2%
Component 1Fail 1%
Component 2Pass 98%
Component 2Tails 2%
Binomial Distribution 3
Binomial distributions used to determine probability for components failing.
• Commonly used for measuring probabilities in manufacturing
• Extendible to model failure in the field
26/02/2015 ©odd.enterprises 22
Component 1Pass 99%
Component 2Pass 98%
Component 2Fail 2%
Component 1Fail 1%
Component 2Pass 98%
Component 2Tails 2%
Probability Tree 3
Probability trees are easily extended to other situations.
• Coins may also land on their side
• Landing on sider assigned a probability of 0.017 % (1 per 6000 tosses)
• Probability tree has exponentially more branches
26/02/2015 ©odd.enterprises 23
Head ≈ 50%
Head ≈ 50%
Tails ≈ 50%
Side ≈ 1 / 6000
Tails ≈ 50%
Head ≈ 50%
Tails ≈ 50%
Side ≈ 1 / 6000
Side ≈ 1 / 6000
Head ≈ 50%
Tails ≈ 50%
Side ≈ 1 / 6000
Probability Tree 4
Probability trees can be used to ensure all possible situations are modelled.
• Systems have unknown states between pass and fail
• Unknown states include loss of communication or wear
• Unknown states investigated for effects
26/02/2015 ©odd.enterprises 24
Component 1Pass 98%
Component 2Pass 96%
Component 2Fail 2%
Component 2Unknown 2%
Component 1Fail 1%
Component 2Pass 96%
Component 2Fail 2%
Component 2Unknown 2%
Component 1Unknown 1%
Component 2Pass 96%
Component 2Fail 2%
Component 2Unknown 2%
Safety Integrity Levels 1
Safety Integrity Levels (SILs) are used to measure potential hazards of a situation.
• Situation is analysed for Probability, Severity and Controllability
• Estimates for a risk of hazards occurring from the situation
𝑆𝐼𝐿 = 𝑃 𝐸 ∗ 𝑆 𝐸 ∗ 𝐶 𝐸
𝑃 𝐸 = Probability of Event
𝑆 𝐸 = Severity of Event
𝐶 𝐸 = Controllability of Event
26/02/2015 ©odd.enterprises 25
Safety Integrity Levels 2
Safety Integrity Levels are used for a wide range of safety critical analysis.
• Probability is how likely a situation will occur
• Severity is potential damage of a situation
• Controllability is ability to effect change in a situation
26/02/2015 ©odd.enterprises 26
Component
𝑆𝐼𝐿 = 𝑃 𝐸 ∗ 𝑆 𝐸 ∗ 𝐶 𝐸
Safety Integrity Levels 3
Coin toss example is extended to provide example of SILs.
• Probability of result is different for each coin
• Severity of outcome measured by hazards
• Controllability determined by who flips coin and stakes
26/02/2015 ©odd.enterprises 27
Safety Integrity Levels 4
Probability tree and SILs are combined to form a decision tree.
• Measures added for severity and controllability
• Each branch is a situation with SIL ratings and requirements to be found
• SIL ratings are applied and found for each situation
26/02/2015 ©odd.enterprises 28
ODD Decision Tree 1
A decision tree creates situations and processes requirements.
• Severity and Controllability are added to each event
• Requirements are found with SIL processes using branches
• Facilitates a unit testing approach for situations
26/02/2015 ©odd.enterprises 29
ODD Decision Tree 2
Adding SIL components to a Probability Tree allows requirement identification from a decision tree.
• Structure is a branching probability tree with SILs
• SILs are found by multiplying along branches of a decision tree
26/02/2015 ©odd.enterprises 30
ODD Decision Tree 3
Processing resulting decision tree is similar to a probability tree.
• SIL ratings processed by multiplying probability, severity and controllability
• SIL rating multiplied along branches
• SIL result between 1 and 4, with 4 being best
26/02/2015 ©odd.enterprises 31
Component 1Pass
P(P1)*S(P1)*C(P1)
Component 2Pass
P(P2)*S(P2)*C(P2)
Component 2Fail
P(F2)*S(F2)*C(F2)
Component 1Fail
P(F1)*S(F1)*C(F1)
Component 2Pass
P(P2)*S(P2)*C(P2)
Component 2Fail
P(F2)*S(F2)*C(F2)
ODD Decision Tree 4
Using a decision tree and SILs gives numerous advantages.
• Branches are used to ensure predictable situations are found
• Extendible and adaptable to new situations
• Each branch is a situation
• Situations are found from combining component situations
26/02/2015 ©odd.enterprises 32
Component 1Pass
Component 2Pass
Situation A
Component 2Fail
Situation B
Component 1Fail
Component 2Pass
Situation C
Component 2Fail
Situation D
Processing Decision Trees
Situation A defines a situation where both components have passed.
Using a decision tree we can find a SIL rating for the situation.
𝑆𝐼𝐿 𝐴= 𝑃 𝑃1 ∗ 𝑆 𝑃1 ∗ 𝐶 𝑃1 ∗𝑃 𝑃2 ∗ 𝑆 𝑃2 ∗ 𝐶(𝑃2)
Situation D defines a situation where both components have failed.
Using the decision tree we can find a SIL rating for the situation.
𝑆𝐼𝐿 𝐷= 𝑃 𝐹1 ∗ 𝑆 𝐹1 ∗ 𝐶 𝐹1 ∗𝑃 𝐹2 ∗ 𝑆 𝐹2 ∗ 𝐶(𝐹2)
26/02/2015 ©odd.enterprises 33
ODD Decision Tree 5
Decision tree gives potential for an infinite range of situations.
• Events can be comprehensively modelled and extended
• New situations added as branches
• Models complexity of expected situations
• Software implementation
26/02/2015 ©odd.enterprises 34
ODD Decision Tree 6
Component 1Pass
Component 2Pass
Component 3 Pass
Component 3 Fail
Component 3 Unknown
Component 2Fail
Component 3 Pass
Component 3 Fail
Component 3 Unknown
Component 3Unknown
Component 3 Pass
Component 3 Fail
Component 3 Unknown
Component 1 Fail
Component 2Pass
Component 3 Pass
Component 3 Fail
Component 3 Unknown
Component 2 Fail
Component 3 Pass
Component 3 Fail
Component 3 Unknown
Component 2Unknown
Component 3 Pass
Component 3 Fail
Component 3 Unknown
Component 1Unknown
Component 2 Pass
Component 3 Pass
Component 3 Fail
Component 3 Unknown
Component 2Fail
Component 3 Pass
Component 3 Fail
Component 3 Unknown
Component 2Unknown
Component 3 Pass
Component 3 Fail
Component 3 Unknown
26/02/2015 ©odd.enterprises 35
A decision tree to illustrate complexity of modelling situations and software will be necessary to facilitate this. Modelled are 3 components with 3 different states: Pass, Fail and Unknown.
Creating Unit Tests 1
Unit testing is used to link requirements with behaviours.
• Each branch represents a situation which a behaviour should cover
• Requirements are found from situations
• Unit tests are created for each branch of a decision tree
26/02/2015 ©odd.enterprises 36
Creating Unit Tests 2
Each requirement creates a test which is solved by describing a behaviour.
• Test is created to ensure requirement is covered
• Specification describes all expected behaviours of a product
• Allows cross examination of behaviours against situations
26/02/2015 ©odd.enterprises 37
Creating Unit Tests 3
1. Requirement is chosen from branch on a decision tree.
2. Behaviour verification test is created directly from requirement.
3. Behaviour is described to cover requirement.
4. Behaviour is validated by passing test.
5. Repeat for all requirements.26/02/2015 ©odd.enterprises 38
Creating Unit Tests 4
Unit tests link situations and requirements with behaviours through creating and solving a test.
• Verification through creation of test
• Validation through passing test
• Situations are combined to produce complex situations
26/02/2015 ©odd.enterprises 39
Linking Tests 1
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
26/02/2015 ©odd.enterprises 40
Linking Tests 2
Each situation creates a unit test to link analysis with specification.
• Diagrams shows various stages of completeness
• Once unit test is passed it becomes green
• Tests are implemented as a suite and ran when editing occurs
26/02/2015 ©odd.enterprises 41
Linking Tests 3
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
26/02/2015 ©odd.enterprises 42
Linking Tests 4
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
26/02/2015 ©odd.enterprises 43
ODD Combined Model
26/02/2015 ©odd.enterprises 44
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
Linking Tests 5
Tests link product features with analysis through utilisation and elicitation.
• Requirements are found from analysing each feature
• Each feature is a single aspect of the product
• Unit testing is applied
26/02/2015 ©odd.enterprises 45
Linking Tests 6
Requirements analysis is the most difficult and important stage to link.
• Utilisation and elicitation should concern situations resulting from product features
• Customers are involved for utilisation and elicitation
• Each situation encountered is covered by a requirement
26/02/2015 ©odd.enterprises 46
Further Information and Questions
• Website
• Presentations
26/02/2015 ©odd.enterprises 47
Legal Stuff
ReferencesTest Driven Development for Embedded C
James Grenning, 2011
Requirements Analysis
http://en.wikipedia.org/wiki/Requirements_analysis
Safety Integrity Level
http://en.wikipedia.org/wiki/Safety_Integrity_Level
Decision Tree
http://en.wikipedia.org/wiki/Decision_tree
Requirements Spiral Model
www.engineering.uiowa.edu/~kuhl/SoftEng/Slides4.pdf
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.
26/02/2015 ©odd.enterprises 48