Obstacle Driven Development

Download Obstacle Driven Development

Post on 10-Aug-2015

204 views

Category:

Engineering

1 download

Embed Size (px)

TRANSCRIPT

<ol><li> 1. Obstacle Driven Development odd.enterprises 05/05/2015 </li><li> 2. Obstacle Driven Development 05/05/2015 odd.enterprises 2 </li><li> 3. ODD Circle Model 05/05/2015 odd.enterprises 3 </li><li> 4. ODD Triangle Model 05/05/2015 odd.enterprises 4 </li><li> 5. ODD Process 05/05/2015 odd.enterprises 5 </li><li> 6. ODD Traffic Light Model 05/05/2015 odd.enterprises 6 </li><li> 7. ODD Flowchart 05/05/2015 odd.enterprises 7 </li><li> 8. ODD M-model 05/05/2015 odd.enterprises 8 </li><li> 9. 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 </li><li> 10. 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 </li><li> 11. 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 </li><li> 12. 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 </li><li> 13. 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 </li><li> 14. 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 </li><li> 15. 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 </li><li> 16. 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 </li><li> 17. 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 </li><li> 18. 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 </li><li> 19. 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 </li><li> 20. 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 </li><li> 21. 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 </li><li> 22. ODD is 3D 05/05/2015 odd.enterprises 22 </li><li> 23. ODD without Tests 05/05/2015 odd.enterprises 23 </li><li> 24. ODD with Tests 05/05/2015 odd.enterprises 24 </li><li> 25. ODD with Passed Tests 05/05/2015 odd.enterprises 25 </li><li> 26. 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 </li><li> 27. 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 </li><li> 28. 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 </li><li> 29. 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 </li><li> 30. 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 </li><li> 31. 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 </li><li> 32. 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 </li><li> 33. 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 </li><li> 34. 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 </li><li> 35. 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 </li><li> 36. 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 </li><li> 37. 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 </li><li> 38. Test Driven Development 2 Obstacle Driven Development was inspired by James Grennings 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 </li><li> 39. 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 </li><li> 40. 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 </li><li> 41. 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 Validate Solution Obstacle </li><li> 42. 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 Validate Solution Obstacle </li><li> 43. 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 </li><li> 44. 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 </li><li> 45. 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 </li><li> 46. 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 </li><li> 47. 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 </li><li> 48. 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 </li><li> 49. Extending a Specification 1 Traditional Problem and Solution Space Extended Specification 49odd.enterprises05/05/2015 </li><li> 50. 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&amp;V of a specification Specification used to create tests 05/05/2015 odd.enterprises 50 </li><li> 51. 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 </li><li> 52. 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 </li><li> 53. 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 </li><li> 54. 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 </li><li> 55. 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 </li><li> 56. Problem and Solution Domains Traditional Proposed 56odd.enterprises05/05/2015 </li><li> 57. ODD Problem Domain 1 ODD problem domain solved through four stages Verification and validation using tests between stages 05/05/2015 odd.enterprises 57 </li><li> 58. 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 </li><li> 59. 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 </li><li> 60. 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 </li><li> 61. 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 </li><li> 62. Element Levels Product System Subsystem Component Material Each is tested 05/05/2015 odd.enterprises 62 </li><li> 63. 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 </li><li> 64. Behaviour Elements Behaviour element...</li></ol>