LIFE CYCLE MODELS

1
Waterfall

The waterfall model

2
Waterfall
the‘classical’ model
every stage needs to be checked and signed off
Ideal for:
◦ Where requirement are well defined
◦ Development methods are well understood

BUT
◦ limited scope for iteration

3
V-process model

Another way of looking at the waterfall model

4
3. Spiral Model

5
Evolutionary delivery: prototyping
‘ An iterative process of creating quickly and
inexpensively live and working models to test out
requirements and assumptions’

Main types:
‘throw away’ prototypes
evolutionary prototypes

What is being prototyped?

human-computer interface
functionality

6
Reasons for prototyping
learning by doing
improved communication
improved user involvement
a feedback loop is established
reduces the need for documentation
reduces maintenance costs i.e. changes after the
application goes live
prototype can be used for producing expected results

7
Prototyping: some dangers
users may misunderstand the role of the
prototype
lack of project control and standards
possible
additional expense of building prototype
focus on user-friendly interface could be at
expense of machine efficiency

8
INCREMENT DELIVERY
MODEL

9
 Incremental delivery
delivered
system

design build install evaluate

increment
first incremental delivery 1

design build install evaluate increment

2
second incremental delivery

increment
design build install evaluate
3

third incremental delivery

10
Increment Delivery Model(cont.)
In this model we break the application down
into small components.
These components are then implemented and
delivered in sequence.

11
 The incremental process

Incremental
delivery

12
Incremental approach:benefits
feedback from early stages used in developing latter
stages
user gets some benefits earlier
Easy to control and manage
project may be put aside temporarily
reduces ‘gold-plating’:

BUT there are some possible disadvantages

loss of economy of scale
◦ More productivity at larger scale
‘software breakage’
13
The incremental delivery plan
The nature and order of each increment to be
delivered to the user have to be planned.
Elements of increment plan are:
◦ System objective
◦ Incremental plan
◦ Open technology plan

14
System objective

Project planner ideally wants well defined

objective but as much freedom as possible
about how to be met.
Objectives
◦ Function goal
 Objective
 Jobs the system is to do
 Computer/non-compute function to achieve them
◦ Quality Goal
 Reliability , response and sercurity
15
Open technology plan
Ifit is required to add new components
continually to the system the system should
be extendible, portable and maintainable
So it require:
◦ A standard high level language
◦ A standard operating system
◦ Small modules
◦ A standard DBMS

16
The outline incremental plan
Steps ideally 1% to 5% of the total project
Ideal if a step takes one month or less:
◦ not more than three months
Each step should deliver some benefit to the
user
Some steps will be physically dependent on
others

17
18
‘Agile’ methods
structured development methods have some
perceived advantages
◦ produce large amounts of documentation which can
be largely unread
◦ documentation has to be kept up to date
◦ division into specialist groups and need to follow
procedures stifles communication
◦ users can be excluded from decision process
◦ long lead times to deliver anything etc. etc
The answer? ‘Agile’ methods?
19
 Dynamic system development
method

UK-based consortium
arguably DSDM can be seen as replacement
for SSADM
DSDM is more a project management
approach than a development approach
Can still use DFDs, LDSs etc!

20
Nine core DSDM principles
1. Active user involvement
2. Teams empowered to make decisions
3. Frequent delivery of products
4. Fitness for business purpose
5. Iterative and incremental delivery
6. Changes are reversible
7. Requirements base-lined at a high level
8. Testing integrated with development
9. Collaborative and co-operative approach
21
DSDM framework

Figure 4.6 here

DSDM process model

22
DSDM: time-boxing
time-box fixed deadline by which something has to
be delivered
typically two to six weeks
MOSCOW priorities
◦ Must have - essential
◦ Should have - very important, but system could operate
without
◦ Could have
◦ Want - but probably won’t get!

23
Extreme programming
increments of one to three weeks
◦ customer can suggest improvement at any point
argued that distinction between design and
building of software are artificial
code to be developed to meet current needs
only
frequent re-factoring to keep code structured

24
Extreme programming - contd
developers work in pairs
testcases and expected results devised before
software design
aftertesting of increment, test cases added to a
consolidated set of test cases

25
Grady Booch’s concern
Booch, an OO authority, is concerned that with
requirements driven projects:
‘Conceptual integrity sometimes suffers because this
is little motivation to deal with scalability,
extensibility, portability, or reusability beyond what
any vague requirement might imply’
Tendency towards a large number of discrete
functions with little common infrastructure?

26
Macro and micro processes

A macro process containing three iterative micro processes

27
‘rules of thumb’ about approach to be used
IF uncertainty is high
THEN use evolutionary approach

IF complexity is high but uncertainty is not

THEN use incremental approach
IF uncertainty and complexity both low
THEN use one-shot
IF schedule is tight
THEN use evolutionary or incremental
28
 Combinations of approach
installation

one-shot incremental evolutionary

construction

one-shot yes yes no

incremental yes yes no
evolutionary yes yes yes

one-shot or incremental installation - any

construction approach possible
evolutionary installation implies evolutionary
construction 29
Task :Do add 12 agile
principles, agile manifesto
to agile software
development slide

30