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

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

Software Engineering: Analysis and Design - CSE3308

Software Development Processes

CSE3308/DMS/2004/4

Monash University - School of Computer Science and Software Engineering


Lecture Outline

Traditional/Waterfall Prototyping Rapid Application Development (RAD) Evolutionary

Incremental Spiral Component Assembly

Agile Methods (e.g. XP) Formal Methods Fourth Generation Techniques


The Waterfall ModelProject

Definition

System Delivery

Maintenance

Requirements Analysis

Design

Component Testing

Integration Testing

System Testing

Program Implementation


Waterfall Model 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


Prototyping

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”


Prototyping

Listen to Customer

Build/ReviseMock-up

Customertest-drivesmock-up


Prototyping

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


Rapid Application Development

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


Rapid Application Development

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and turnover

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and

turnover

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and

turnover

Team 1 Team 2 Team 3


Incremental Development

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


Incremental Development

analysis deliverydesign coding testing




1st Increment

2nd Increment

3rd Increment

4th Increment

Project Definition


The Spiral Model

Development cycles through multiple (3-6) task regions (6 stage version)

customer communication planning risk analysis engineering construction and release customer evaluation

Incremental releases early releases may be paper or prototypes later releases become more complicated

Models software until it is no longer used


Spiral Model


Spiral Model

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


Component Assembly

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


Component Assembly


Agile Methods 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


Agile Methods: XP

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 and effort to recognize the simplest solution

Incremental change Embracing change Quality work


Agile Methods: XP (2)

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


Agile Methods: When not to try XP 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


Formal Methods

Use of mathematical techniques to specify the requirements of the system e.g 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


Fourth Generation Techniques

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


Fourth Generation Techniques

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


References

Pressman, R., Software Engineering: A Practitioner's Approach, McGraw-Hill, 2000, (Chapters 1 and 2).

Martin, Robert C., Agile Software Development: Principles, Patterns, and Practices, Prentice Hall, 2002.

Beck, Kent, eXtreme Programming eXplained: Embrace Change, Addison-Wesley, 1999.

Documents

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