Software. Well... It's Complicated
1 like759 views
The document discusses the inherent complexities of software and software testing, highlighting that software is unreliable and created imperfectly. It emphasizes the need for empirical experiments in testing, acknowledges essential difficulties such as complexity and changeability, and proposes proactive approaches to understanding and managing these complexities. The speaker advocates for a discussion on software complexity and suggests utilizing models to explore options rather than merely describe systems.
Software. Well... It's Complicated
- 1. SOFTWARE. WELL… IT’S COMPLICATED INHERENT COMPLEXITIES OF SOFTWARE AND TESTING SHMUEL GERSHON MAY, 2015
- 2. Systems? A WEBINAR ABOUT SYSTEMS
- 4. WHO YOU TALKING TO? • Specializing in the tests of embedded software. • Special attention: • Learning Oriented Tests of the Exploratory kind, Note Taking, • I like reading, writing, flying kites, sleeping. • Frequent participant at EuroStar and the conference webinars
- 5. A WEBINAR ABOUT SYSTEMS
- 6. A SYSTEM CONTAINS SYSTEMS. AND IS CONTAINED IN SYSTEMS.
- 7. A SYSTEM CONTAINS SYSTEMS. AND IS CONTAINED IN SYSTEMS.
- 8. SOFTWARE SYSTEMS ARE COMPLEX SIGNIFICANTLY
- 9. WHAT IS SOFTWARE? • 111100101010101000001000010111001011001010101001110010010 001000011111000100010001001001000001010001000010001001110 010101010000010011111111100011000101000101000000101000000 1010001000010001001110010101010000010011111101110010101 b • 0x f9 40 5d 0b b0 e2 b0 56 65 de 87 47 f4 66 58 2d 2a e7 57 be a6 e4 df 90 a2 6e 6c da 15 f0 74 55 cb 6f e0 dc a6 c7 59 8b e6 d7 a5 22 98 50 34 0a f6 e8 b0 e2 b0 56 65 de 87 47 f4 66 58 2d 2a e7 57 be a6 e4 df 90 a2 6e 6c da 15
- 10. WHAT IS SOFTWARE? •A set of set of machine-readable instructions that directs a computer's processor to perform specific operations?
- 11. WHAT DOES SOFTWARE LOOK LIKE?
- 12. WHAT DOES SOFTWARE LOOK LIKE?
- 13. WHAT DOES SOFTWARE LOOK LIKE?
- 14. WHAT DOES SOFTWARE LOOK LIKE?
- 15. SOFTWARE & SOFTWARE TESTING Complex Software Complex Software Testing
- 16. FRED BROOKS & DAVID PARNAS
- 17. ESSENCE AND ACCIDENTS OF SOFTWARE ENGINEERING • Some of the hard properties of software are part of its essence • As such, no improvement (present of future) can get rid of it • Software has no silver bullet • The hard part is figuring our what we need to build, then creating and testing the concept. • The hard part is not coding a representation of the concept, or performing the test on that representation
- 18. ESSENTIAL DIFFICULTIES OF SOFTWARE • Inherent Complexity • Inherent Conformity • Inherent Changeability • Inherent Invisibility VS
- 19. ESSENTIAL DIFFICULTIES OF SOFTWARE • Inherent Complexity • Inherent Conformity • Inherent Changeability • Inherent Invisibility VS
- 20. ESSENTIAL DIFFICULTIES OF SOFTWARE • Inherent Complexity • Inherent Conformity • Inherent Changeability • Inherent Invisibility VS
- 21. ESSENTIAL DIFFICULTIES OF SOFTWARE • Inherent Complexity • Inherent Conformity • Inherent Changeability • Inherent Invisibility VS
- 22. WHAT ABOUT TESTING THEN?
- 23. SOFTWARE ASPECTS OF STRATEGIC DEFENSE SYSTEMS • Software is unreliable • Software is created imperfect • Software professionals cannot keep up with program complexity • Humans ideate and create – confuse and forget • You cannot prove a software correct • You need empiric experiments
- 24. STAR WARS OR SOFTWARE ASPECTS OF STRATEGIC DEFENSE SYSTEMS • Empiric Tests in a 1-off System • Unknowns of runtime: •Targets •Decoys •Countermeasures •Time •... •Trust requires real conditions
- 25. ESSENTIAL DIFFICULTIES OF TESTING • Programming is Trial and Error. So is testing. • Without empiric tests, we don’t get enough trust. VS
- 26. SO WHAT CAN WE DO? •You cannot remove complexity. •You cannot diminish complexity unless you diminish software. •To deal with it we need to accept and embrace it.
- 27. SO WHAT CAN WE DO? • Be aware • Discuss complexity • Understand parts and Relationships • Look for incidental complexity • Technology-, solution-, human-, interface- • Model • Beware the model • Use Models to raise questions, options and understanding, more than to describe the system.
- 28. READ THE PAPERS •Essence and Accidents of Software Engineering • http://faculty.salisbury.edu/~xswang/Research/Pap ers/SERelated/no-silver-bullet.pdf •Software Aspects of Strategic Defense Systems • http://web.stanford.edu/class/cs99r/readings/par nas1.pdf