software lecture
Download as PPT, PDF0 likes290 views
The document discusses various software development processes including traditional/waterfall methods, prototyping, rapid application development, evolutionary/incremental/spiral development, agile methods like extreme programming, formal methods, and fourth generation techniques. It provides details on the characteristics, advantages, and disadvantages of each approach.
software lecture
- 2. Traditional/Waterfall Prototyping Rapid Application Development (RAD) Evolutionary ◦ ◦ ◦ Incremental Spiral Component Assembly Agile Methods (e.g. XP) Formal Methods Fourth Generation Techniques
- 4. Most widely used, though no longer state-of-the-art Each step results in documentation May be suitable for well-understood developments using familiar technology Not suited to new, different systems because of specification uncertainty Difficulty in accommodating change after the process has started Can accommodate iteration but indirectly Working version not available till late in process Often get blocking states
- 5. Specifying requirements is often very difficult Users don’t know exactly what they want until they see it Prototyping involves building a mock-up of the system and using to obtain for user feedback Closely related to what are now called “Agile Methods”
- 7. Ideally mock-up serves as mechanism for identifying requirements Users like the method, get a feeling for the actual system Less ideally may be the basis for completed product ◦ ◦ ◦ prototypes often ignore quality/performance/maintenance issues may create pressure from users on deliver earlier may use a less-than-ideal platform to deliver e.g Visual Basic - excellent for prototyping, may not be as effective in actual operation
- 8. Similar to waterfall but uses a very short development cycle (60 to 90 days to completion) Uses component-based construction and emphasises reuse and code generation Use multiple teams on scaleable projects Requires heavy resources Requires developers and customers who are heavily committed Performance can be a problem Difficult to use with new technology
- 9. Team 1 Team 2 Team 3 Business Business modelling Business modelling Data modelling modelling Data modelling Data modelling Process modelling Process modelling Process modelling Application generation Applicatio n Application Testing and turnover generation generation Testing and turnover Testing and turnover
- 10. Applies an iterative philosophy to the waterfall model Divide functionality of system into increments and use a linear sequence of development on each increment First increment delivered is usually the core product, i.e only basic functionality Reviews of each increment impact on design of later increments Manages risk well Extreme Programming (XP), and other Agile Methods, are incremental, but they do not implement the waterfall model steps in the standard order
- 11. 1st Increment analysis design coding testing delivery 2nd Increment analysis design coding Project Definition testing delivery 3rd Increment analysis design coding testing delivery 4th Increment analysis design coding testing delivery
- 12. Development cycles through multiple (3-6) task regions (6 stage version) ◦ ◦ ◦ ◦ ◦ ◦ Incremental releases ◦ ◦ customer communication planning risk analysis engineering construction and release customer evaluation early releases may be paper or prototypes later releases become more complicated Models software until it is no longer used
- 14. Not a silver bullet, but considered to be one of the best approaches Is a realistic approach to the problems of large scale software development Can use prototyping during any phase in the evolution of product Requires excellent management and risk assessment skills
- 15. Incorporates features of the spiral model Usually based on object technologies, but not necessarily e.g. Visual Basic (older versions) Compose applications from pre-packaged software components Can greatly boost productivity and reuse Relies heavily on quality and robustness of the software components Fits into the Engineering/Construction task region of the spiral model
- 17. In the last few years, a group of influential writers and consultants have got behind a group of software development processes known collectively as “Agile Methods” Agile Methods reject the notion that we should design for future change – don’t “borrow trouble” There is a “Manifesto for Agile Software Development”: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan” Seductive, isn’t it? ◦ Beware: it is not yet widely accepted in industry, and its own proponents admit that it is not always a good choice
- 18. The best-known agile development process eXtreme Programming (XP), introduced by Kent Beck in 1999. It’s main principles are: ◦ Rapid feedback Very frequent builds – many per day Tests written first ◦ Assume simplicity Don’t borrow trouble – but “simplicity” is not easy. It can often take skill, effort and experience to recognize the simplest solution (as we will see with Design Patterns later in the semester) ◦ Incremental change ◦ Embracing change ◦ Quality work
- 19. The XP methodology has many practices. Beck emphasizes that you can’t pick and choose: if you’re not doing them all, you’re not doing XP ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ The Planning Game Small releases Metaphor Simple Design Testing – tests are written first, by both programmers and customer Refactoring Pair programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards
- 20. XP is very appealing to many programmers – often because they think can get away from heavy documentation ◦ in fact the test-first practice creates a lot of documentation, though in code form Beck himself indicates that there are situations where XP is not appropriate. These include: ◦ When it is not supported by the company culture e.g. belief in big specifications, or overtime seen as a proxy for commitment to company ◦ More than 10 or 20 programmers (this is a big one!) ◦ Project too big for regular complete integration ◦ Where it inherently takes a long time to get feedback ◦ Where you can’t realistically test e.g. already in production using a $1,000,000 machine that is already at full capacity ◦ When the physical environment is wrong
- 21. Use of mathematical techniques to specify the requirements of the system e.g the B method, Z, VDM, Object-Z Mainly used in life or mission-critical applications, e.g heart pacemakers, NASA Can get very high quality software Problems ◦ ◦ ◦ Time-consuming and expensive Few developers have necessary skills, so extensive training required Difficult to use as a tool to communicate with users
- 22. The use of CASE and 4GL tools which let you specify the software at a high-level Example: Hamilton-1 uses a formal specification language to generate complete system from requirements analysis ($100,000 per license) Use of 4GT has grown considerably in the last decade Some indications of productivity improvements for small and intermediate applications
- 23. Large projects require as much or more analysis, design and testing to achieve the time gains from the elimination of coding Often problems with efficiency of automatically generated code