obstacle driven development models
TRANSCRIPT
Obstacle Driven DevelopmentODD Models
Testing First?
15/07/2016 ©odd.enterprises 2
Answering a question before its asked is like creating a solution before a test.
Problem Driven Development
Problem Driven Development combines Test Driven Development with V-models.
• Requirements analysis is separate stage
• Specification in the form of various levels of testing
15/07/2016 ©odd.enterprises 3
Problem Driven Development
Colour is changed to represent the colours of traffic lights.
• Tests are linked to abstraction levels of the stages
• Suitable for research purposes
15/07/2016 ©odd.enterprises 4
Problem Domain Development
Problem and solution domains describe the stages.
• Specification is an interface between the stages
• Expanding the interface allows increased testing
15/07/2016 ©odd.enterprises 5
N-model Comparison
Problem Driven Development creates an N-model to combine a V and inverted V-model.
• Comparison against Problem and Solution domains
• Specification allows testing of ideas before they are created
15/07/2016 ©odd.enterprises 6
Obstacle Driven Development Stages
Adding a Production stage created Obstacle Driven Development with Solution to be produced.
• Solutions designed in labs may not work in practice
• Production ensures Solution is produced with quality assured and controlled
15/07/2016 ©odd.enterprises 7
Stages Verification + Validation
Between each stage of Obstacle Driven Development there are tests created to verify and validate.
• Verify is creating a test to ensure it’s built in the right way
• Validate is passing a test to ensure it’s built right
• Adapted as necessary between other stages
15/07/2016 ©odd.enterprises 8
Stages Verification + Validation
Verification and Validation gives 2 directions of information flow with feedforwards and feedback.
• Each stage is linked to the next through creating tests
• Each stage is linked to the previous through passing tests
• Feedforwards for progress
• Feedback for correction
15/07/2016 ©odd.enterprises 9
Stages + Domains
Production gives another stage to the Problem and Solution domain with Quality Assured and Controlled.
15/07/2016 ©odd.enterprises 10
M-model Development
15/07/2016 ©odd.enterprises 11
Extending the N-model with Production creates the M-model.
• Checkpoints added to consolidate each stage with output
• Tests created and passed between each stage
M-model Development
M-model provides a path for development with Verification and Validation through tests.
• Stages are alternatively built up and broken down
• Ascending slope indicates integration
• Descending slope indicates decomposition
15/07/2016 ©odd.enterprises 12
Domains + M-model
Stages designed to model the problem domain with testing between each.
• Overlap represents testing between stages
• Creating and solving tests acts as interface between stages
• Operates similarly to Test Driven Development
15/07/2016 ©odd.enterprises 13
M-model Elements
M-models divided into stages and abstraction levels to give elements.
• Stages contain all required elements
• Creating through integration or decomposition
• Suppliers may supply lower level products
15/07/2016 ©odd.enterprises 14
M-model Elements
Stages of the model are divided into elements through abstraction levels and system divisions with each having a specific place.
15/07/2016 ©odd.enterprises 15
Stages + Process
15/07/2016 ©odd.enterprises 16
Stages are created using a process of creating and solving tests.
• Process the same for each stage but different methods to achieve solutions
• Solutions to a stage become obstacles to the next
• Stages
Stages + Process
15/07/2016 ©odd.enterprises 17
Solutions to each stage (in blue) become obstacles (in red) to link the next stage.
• Stages are both solutions and obstacles
• Stages repeated until obstacles are solved
Process + Verification + Validation
Verification and validation is performed between each stage through creating and solving tests.
• Creating a test first ensures we are building the right thing
• Solving a test ensures we are building it right
• We modify prior stages when we determine errors with them
15/07/2016 ©odd.enterprises 18
OODA Inspired M-model
ODD combined with the OODA model (Observe, Orient, Decide, Act).
• Illustrates feedback to the Analysis stage
• Shows importance of a Specification to development
• Decision block before entering Production
15/07/2016 ©odd.enterprises 19
Abstraction Levels
Abstraction levels help obstacles and solutions link at all levels.
• Divides development into appropriate levels
• High level abstractions are integrated from lower levels
• Lower level abstractions are decomposed from high levels
15/07/2016 ©odd.enterprises 20
Systems Division
Abstraction levels are further divided into individual systems and their lower levels.
• Helps separate systems from others for easier testing and integration
• Systems division is modelled throughout stages
15/07/2016 ©odd.enterprises 21
3D Pyramid Model
Combining models gives a 3D model with Stages, Abstraction levels and System Divisions.
• Progress on x-axis
• Abstraction levels on y-axis
• Systems division on z-axis
15/07/2016 ©odd.enterprises 22
Linking Models
Models are linked end to end to allow development to continuously improve.
• Models linked for new products or creating improved versions
• Combine as many models as necessary
• Obstacles, tests and solutions can be reused
15/07/2016 ©odd.enterprises 23
Flowchart
Flowcharts show how we create products through each stage.
• Process is similar for each stage
• Create tests first, solutions after
• Stages complete when all tests are passed
15/07/2016 ©odd.enterprises 24
Flowchart + Feedback
Feedback between stages allows modification of previous stages within a development cycle.
• Feedback when tests or solutions are not suitable
• Tests and/or solutions may not correct
• Progress of stage determines feedback
15/07/2016 ©odd.enterprises 25
Repeating M-models
M-models also repeat by folding in on themselves which helps continuous improvement.
• Consists of V and inverted V-models
• Process and structure identical to other forms
• Current and future products developed concurrently
15/07/2016 ©odd.enterprises 26
Systems Engineering
Further stages may be added to create models suitable for systems engineering.
• Additional stages of Supply and Assemble support hardware and embedded
• Maintenance and Support to help products and services longevity
15/07/2016 ©odd.enterprises 27
Software Engineering + Sales
Other stages are added to the systems engineering model as necessary.
• Business obstacles and solutions may be combined
• Helps determine effective business strategies
15/07/2016 ©odd.enterprises 28
Hardware Engineering + Sales
Stages are added or removed as necessary for development.
• Adding Supply and Assemble added
• Maintenance and Support removed
• Helps links Hardware and Embedded engineering to a business strategy
15/07/2016 ©odd.enterprises 29
ODDSAP (Supply Assemble Production)
Stages are added and removed to create new models.
• Stages added in pairs which support development
• Supply and Assemble ensure hardware is supplied and assembled right
15/07/2016 ©odd.enterprises 30
OODA Inspired ODDSAP
Combining the ODDSAP model with OODA shows feedback and importance of Specification.
• Feedback from each stage to Analysis
• Implicit Guidance and control from Specification
15/07/2016 ©odd.enterprises 31
ASAP (Analysis Supply Assemble Production)
ASAP used when there is insufficient time to perform the required stages.
• Product is built quickly with ODD stages to verify and validate
• ODD performed concurrently or after
15/07/2016 ©odd.enterprises 32
Generic Form
Generic form is applicable between each of the stages.
• Obstacle is a solution from previous stage
• Target / Test creates a test with assertion
• Solution solves the test / achieves target
• Action is result of the stage
15/07/2016 ©odd.enterprises 33
OBSA (Obstacle Behaviour Solution Action)
OBSA is the fundamental process and method behind ODD.
• Modified for different fields including business and medicine
• Fundamental to OODA methods also
15/07/2016 ©odd.enterprises 34
Further Information and Questions
Website
Presentations
15/07/2016 ©odd.enterprises 35
Legal Stuff
ReferencesTest Driven Development for Embedded C
James Grenning, 2011
Digging into “Fail fast, fail often.”
http://agile.dzone.com/articles/digging-fail-fast-fail-often
Agile vs. Waterfall: How to Approach your Web Development Project
http://www.commonplaces.com/blog/agile-vs-waterfall-how-approach-your-web-development-project
The Scrum Master Performance Review
http://illustratedagile.com/2011/12/13/the-scrum-master-performance-review-preparation/
ScrumMaster
http://www.mountaingoatsoftware.com/agile/scrum/scrummaster
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.
15/07/2016 ©odd.enterprises 36