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
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
13.
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
16.
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
