Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 1B.1 Software Engineering: Analysis and Design - CSE3308 Software Development Processes.

Similar presentations


Presentation on theme: "CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 1B.1 Software Engineering: Analysis and Design - CSE3308 Software Development Processes."— Presentation transcript:

1 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.1 Software Engineering: Analysis and Design - CSE3308 Software Development Processes CSE3308/DMS/2004/4 Monash University - School of Computer Science and Software Engineering

2 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.2 Lecture Outline u Traditional/Waterfall u Prototyping u Rapid Application Development (RAD) u Evolutionary v Incremental v Spiral v Component Assembly u Agile Methods (e.g. XP) u Formal Methods u Fourth Generation Techniques

3 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.3 The Waterfall Model Project Definition System Delivery Maintenance Requirements Analysis Design Component Testing Integration Testing System Testing Program Implementation

4 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.4 Waterfall Model u Most widely used, though no longer state-of-the-art u Each step results in documentation u May be suitable for well-understood developments using familiar technology u Not suited to new, different systems because of specification uncertainty u Difficulty in accommodating change after the process has started u Can accommodate iteration but indirectly u Working version not available till late in process u Often get blocking states

5 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.5 Prototyping u Specifying requirements is often very difficult u Users don’t know exactly what they want until they see it u Prototyping involves building a mock-up of the system and using to obtain for user feedback u Closely related to what are now called “Agile Methods”

6 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.6 Prototyping Listen to Customer Build/Revise Mock-up Customer test-drives mock-up

7 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.7 Prototyping u Ideally mock-up serves as mechanism for identifying requirements u Users like the method, get a feeling for the actual system u Less ideally may be the basis for completed product v prototypes often ignore quality/performance/maintenance issues v may create pressure from users on deliver earlier v 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 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.8 Rapid Application Development u Similar to waterfall but uses a very short development cycle (60 to 90 days to completion) u Uses component-based construction and emphasises reuse and code generation u Use multiple teams on scaleable projects u Requires heavy resources u Requires developers and customers who are heavily committed u Performance can be a problem u Difficult to use with new technology

9 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.9 Rapid Application Development Business modelling Data modelling Process modelling Application generation Testing and turnover Business modelling Data modelling Process modelling Applicatio n generation Testing and turnover Business modelling Data modelling Process modelling Application generation Testing and turnover Team 1 Team 2 Team 3

10 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.10 Incremental Development u Applies an iterative philosophy to the waterfall model u Divide functionality of system into increments and use a linear sequence of development on each increment u First increment delivered is usually the core product, i.e only basic functionality u Reviews of each increment impact on design of later increments u Manages risk well u Extreme Programming (XP), and other Agile Methods, are incremental, but they do not implement the waterfall model steps in the standard order

11 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.11 Incremental Development analysisdeliverydesigncodingtestinganalysisdeliverydesigncodingtestinganalysisdeliverydesigncodingtestinganalysisdeliverydesigncodingtesting 1st Increment 2nd Increment 3rd Increment 4th Increment Project Definition

12 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.12 The Spiral Model u Development cycles through multiple (3-6) task regions (6 stage version) v customer communication v planning v risk analysis v engineering v construction and release v customer evaluation u Incremental releases v early releases may be paper or prototypes v later releases become more complicated u Models software until it is no longer used

13 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.13 Spiral Model

14 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.14 Spiral Model u Not a silver bullet, but considered to be one of the best approaches u Is a realistic approach to the problems of large scale software development u Can use prototyping during any phase in the evolution of product u Requires excellent management and risk assessment skills

15 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.15 Component Assembly u Incorporates features of the spiral model u Usually based on object technologies, but not necessarily e.g. Visual Basic (older versions) u Compose applications from pre-packaged software components u Can greatly boost productivity and reuse u Relies heavily on quality and robustness of the software components u Fits into the Engineering/Construction task region of the spiral model

16 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.16 Component Assembly

17 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.17 Agile Methods u 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” u Agile Methods reject the notion that we should design for future change – don’t “borrow trouble” u 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” u Seductive, isn’t it? vBeware: it is not yet widely accepted in industry, and its own proponents admit that it is not always a good choice

18 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.18 Agile Methods: XP u The best-known agile development process eXtreme Programming (XP), introduced by Kent Beck in It’s main principles are: vRapid feedback »Very frequent builds – many per day »Tests written first vAssume simplicity »Don’t borrow trouble – but “simplicity” is not easy. It can often take skill and effort to recognize the simplest solution vIncremental change vEmbracing change vQuality work

19 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.19 Agile Methods: XP (2) u 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 vThe Planning Game vSmall releases vMetaphor vSimple Design vTesting – tests are written first, by both programmers and customer vRefactoring vPair programming vCollective ownership vContinuous integration v40-hour week vOn-site customer vCoding standards

20 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.20 Agile Methods: When not to try XP u XP is very appealing to many programmers – often because they think can get away from heavy documentation vin fact the test-first practice creates a lot of documentation, though in code form u Beck himself indicates that there are situations where XP is not appropriate. These include: vWhen it is not supported by the company culture »e.g. belief in big specifications, or overtime seen as a proxy for commitment to company vMore than 10 or 20 programmers (this is a big one!) vProject too big for regular complete integration vWhere it inherently takes a long time to get feedback vWhere you can’t realistically test »e.g. already in production using a $1,000,000 machine that is already at full capacity vWhen the physical environment is wrong

21 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.21 Formal Methods u Use of mathematical techniques to specify the requirements of the system e.g Z, VDM, Object-Z u Mainly used in life or mission-critical applications, e.g heart pacemakers, NASA u Can get very high quality software u Problems v Time-consuming and expensive v Few developers have necessary skills, so extensive training required v Difficult to use as a tool to communicate with users

22 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.22 Fourth Generation Techniques u The use of CASE and 4GL tools which let you specify the software at a high-level u Example: Hamilton-1 uses a formal specification language to generate complete system from requirements analysis ($100,000 per license) u Use of 4GT has grown considerably in the last decade u Some indications of productivity improvements for small and intermediate applications

23 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.23 Fourth Generation Techniques u Large projects require as much or more analysis, design and testing to achieve the time gains from the elimination of coding u Often problems with efficiency of automatically generated code

24 CSE Software Engineering: Analysis and Design, 2004Lecture 1B.24 References u Pressman, R., Software Engineering: A Practitioner's Approach, McGraw-Hill, 2000, (Chapters 1 and 2). u Martin, Robert C., Agile Software Development: Principles, Patterns, and Practices, Prentice Hall, u Beck, Kent, eXtreme Programming eXplained: Embrace Change, Addison-Wesley, 1999.


Download ppt "CSE3308 - Software Engineering: Analysis and Design, 2004Lecture 1B.1 Software Engineering: Analysis and Design - CSE3308 Software Development Processes."

Similar presentations


Ads by Google