Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Design Models The Researcher/Hacker The Waterfall Extreme Agile/Programming Test-based Programming.

Similar presentations


Presentation on theme: "Software Design Models The Researcher/Hacker The Waterfall Extreme Agile/Programming Test-based Programming."— Presentation transcript:

1 Software Design Models The Researcher/Hacker The Waterfall Extreme Agile/Programming Test-based Programming

2 Researcher/Hacker Model Inherits working code for similar task Understands just enough to modify it to suit their needs Comments in code, documentation are optional Design of software is rarely if ever considered “if it works, I’m happy”

3 Researcher/Hacker Benefits Reasons people use the Researcher/Hacker model include: Alan Ableson: -Fast to get up and running -If you just need a one-time took, it’s most effective -Not over- engineered -Requires the least background in programming and esign Alan Ableson: -Fast to get up and running -If you just need a one-time took, it’s most effective -Not over- engineered -Requires the least background in programming and esign

4 Researcher/Hacker Model Problems with the Researcher/Hacker model include: Alan Ableson: -Lousy shelf life -No reliability built into system -Can’t be easily expanded to next project -Becomes more and more unwieldy Alan Ableson: -Lousy shelf life -No reliability built into system -Can’t be easily expanded to next project -Becomes more and more unwieldy

5 Waterfall Model List of sequential steps: each step’s output leads into the next Intended to allow teams of programmers to work towards a common goal Used mostly in corporate settings Considered the “classic” design model for designing from-scratch software

6 Waterfall Steps Requirements specification Design Construction/Coding Integration Testing and debugging Installation Maintenance

7 Requirements Examples “Response time to interrupt must be less than 1/10 second” “Users must be able to go directly from product page to sale closing page” “Managers can set level of individual access levels for each bank teller” See FAA example in resources

8 Waterfall Model Benefits Reasons people use this model include:

9 Waterfall Model Problems with the Waterfall Model include:

10 Waterfall Model More problems with the Waterfall Model include! Alan Ableson: Last should be the Death march Alan Ableson: Last should be the Death march

11 Extreme/Agile Programming More recent philosophy/plan for developing software (1990’s) Ties in with developments on component design paradigms side (pattern-based programming) Has a cooler name, which helps with marketing Many related variants now exist

12 Extreme/Agile Programming

13 Extreme Programming Lot of structure for a ‘rebellious’ approach Most ideas/techniques can be “borrowed” into other design approaches

14 Extreme/Agile Programming Reasons people use it: Problems include:

15 In Practice Most large-scale software projects combine some aspects of each model Good management will take the best aspects of each…

16 Test-based programming Ideas from extreme programming can be very useful for single-person or small-group computational projects Can “unhackify” otherwise risky design/modification strategies Most commonly used approach is test- based development (also called unit testing)

17 Test-based programming

18 Ask: “What should this software do?” Write a test first “Does this software do X correctly?” Fill in the code, and keep working until the test runs successfully

19 Test-based programming Generates its own regression test suite allows you to test for the same accuracy when you make an ‘innocent’ change months later especially important when you want to change to speed up results Big advantage: bugs are detected while you are coding the same module

20 Test-based programming Tests are usually written at a module level Fast Fourier Transform with standard functions probability calculations Tests are more difficult to design for inherently random algorithms (e.g. genetic algorithms, Markhov chains), but possible Tests can (should?) be re-run frequently ensure what used to work still works

21 Test-based programming Tests are usually written at a module level Fast Fourier Transform with standard functions probability calculations Tests are more difficult to design for inherently random algorithms (e.g. genetic algorithms, Markhov chains), but possible Tests can (should?) be re-run frequently ensure what used to work still works

22 Summary The Researcher/Hacker The Waterfall Extreme Agile/Programming Test-based Programming All have important ideas for how to develop good software Take whichever ideas fit your project best

23 Programming is like a sport (or teaching, or…) Many philosophies of how to do it well Easy to get stuck in patterns that aren’t efficient or lead to (unnecessary) frustration Important to get intermittent ‘coaching’ reminders about strategies step back from details

24 Resources Cathedral and the Bazaar (open-source vs closed source, but also hacker vs monolith) Wikipedia (not as a reference, but as an introduction) Extreme Programming.org – evangelism site for extreme programming FAA for an example of the Waterfall method taken to extremes JUnit, for building test cases in Java Xunit, a more general framework


Download ppt "Software Design Models The Researcher/Hacker The Waterfall Extreme Agile/Programming Test-based Programming."

Similar presentations


Ads by Google