CSE3308/DMS/2005/3
Monash University - School of Computer
Science and Software Engineering
Software Engineering: Analysis and
Design - CSE3308
Software Development Processes
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.1
Lecture Outline
 Traditional/Waterfall
 Prototyping
 Rapid
Application Development (RAD)
 Evolutionary



Incremental
Spiral
Component Assembly
 Agile
Methods (e.g. XP)
 Formal Methods
 Fourth Generation Techniques
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.2
The Waterfall Model
Project
Definition
Requirements
Analysis
Design
Program
Implementation
Component
Testing
Integration
Testing
System
Testing
System
Delivery
Maintenance
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.3
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.4
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”
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.5
Prototyping
Listen to
Customer
Build/Revise
Mock-up
Customer
test-drives
mock-up
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.6
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.7
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.8
Rapid Application Development
Team 1
Team 2
Team 3
Business
modelling
Business
Business
modelling
modelling
Data
modelling
Data
modelling
Data
modelling
Process
modelling
Process
modelling
Process
modelling
Application
generation
Applicatio
n
Application
Testing
and
turnover
generation
generation
Testing and
turnover
CSE3308 - Software Engineering: Analysis and Design, 2005
Testing
and
turnover
Lecture 1B.9
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.10
Incremental Development
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
CSE3308 - Software Engineering: Analysis and Design, 2005
design
coding
testing
Lecture 1B.11
delivery
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.12
Spiral Model
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.13
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.14
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.15
Component Assembly
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.16
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.17
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, 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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.18
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.19
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.20
Formal Methods
 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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.21
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.22
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
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.23
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.
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 1B.24