Software Project Management

Chapter Four

Selection of an
appropriate
project approach

Software project management (5e) - introduction © 1

The McGraw-Hill Companies, 2011
 Outline of lecture

• Building versus buying software

• Taking account of the characteristics of the project
• Process models
• Waterfall
• Prototyping and iterative approaches
• Incremental delivery
• Agile approaches

Software project management (5e) - introduction © 2

The McGraw-Hill Companies, 2011
 Selection of project approaches

• This lecture concerned with choosing the right approach

to a particular project: variously called technical planning,
project analysis, methods engineering and methods
tailoring
• In-house: often the methods to be used dictated by
organizational standards
• Suppliers: need for tailoring as different customers have
different needs

Software project management (5e) - introduction © 3

The McGraw-Hill Companies, 2011
 Build or buy?

In-house
Outsource
developm ?
ent?
either

Build Buy

Software project management (5e) - introduction © 4

The McGraw-Hill Companies, 2011
 Some advantages of off-the-shelf (OTS)
software
• Cheaper as supplier can spread development costs over a
large number of customers
• Software already exists
• Can be trialled by potential customer
• No delay while software being developed
• Where there have been existing users, bugs are likely to
have been found and eradicated

Software project management (5e) - introduction © 5

The McGraw-Hill Companies, 2011
 Some possible disadvantages of off-the-
shelf
• Customer will have same application as everyone else: no
competitive advantage, but competitive advantage may
come from the way application is used
• Customer may need to change the way they work in order
to fit in with OTS application
• Customer does not own the code and cannot change it
• Danger of over-reliance on a single supplier

Software project management (5e) - introduction © 6

The McGraw-Hill Companies, 2011
 General approach
• Look at risks and uncertainties e.g.
• are requirements well understood?
• are technologies to be used well understood?
• Look at the type of application being built e.g.
• information system? embedded system?
• criticality? differences between target and development
environments?
• Clients’ own requirements
• need to use a particular method

Software project management (5e) - introduction © 7

The McGraw-Hill Companies, 2011
 Structure versus speed of delivery

Structured approach
• Also called ‘heavyweight’ approaches
• Step-by-step methods where each step and intermediate product is
carefully defined
• Emphasis on getting quality right first time
• Example: use of UML and USDP (Unified Software Dev. Process)
• Future vision: Model-Driven Architecture (MDA). UML supplemented
with Object Constraint Language, press the button and application
code generated from the UML/OCL model

Software project management (5e) - introduction © 8

The McGraw-Hill Companies, 2011
 Structure versus speed of delivery

Agile methods
• Emphasis on speed of delivery rather than documentation
• RAD Rapid application development emphasized use of
quickly developed prototypes
• JAD Joint application development. Requirements are
identified and agreed in intensive workshops with users

SPM (5e) Selection of project approach© The McGraw- 9

Hill Companies, 2009
 Processes versus Process Models

• Starting from the inception stage:

• A product undergoes a series of transformations
through a few identifiable stages
• Until it is fully developed and released to the customer.
• This forms its life cycle or development process.
• Life cycle model (also called a process model):
• A graphical or textual representation of the life cycle.

SPM (5e) Selection of project approach© The McGraw- 10

Hill Companies, 2009
 Choice of process models

• ‘waterfall’ also known as ‘one-shot’, ‘once-through’

• incremental delivery
• evolutionary development

Also use of ‘agile methods’ e.g. extreme programming

SPM (5e) Selection of project approach© The McGraw- 11

Hill Companies, 2009
 Waterfall

SPM (5e) Selection of project approach© The McGraw- 12

Hill Companies, 2009
 Waterfall

• the ‘classical’ model

• imposes structure on the project
• every stage needs to be checked and signed off
• BUT
• limited scope for iteration
• V model approach is an extension of waterfall where different testing
phases are identified which check the quality of different development
phases

SPM (5e) Selection of project approach© The McGraw- 13

Hill Companies, 2009
 V model

SPM (5e) Selection of project approach© The McGraw- 14

Hill Companies, 2009
 Evolutionary delivery: prototyping
‘ An iterative process of creating quickly and inexpensively
live and working models to test out requirements and
assumptions’
Sprague and McNurlin
main types
• ‘throw away’ prototypes
• evolutionary prototypes
what is being prototyped?
• human-computer interface
• functionality

SPM (5e) Selection of project approach© The McGraw- 15

Hill Companies, 2009
 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

SPM (5e) Selection of project approach© The McGraw- 16

Hill Companies, 2009
 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

SPM (5e) Selection of project approach© The McGraw- 17

Hill Companies, 2009
 other ways of categorizing
prototyping
• what is being learnt?
• organizational prototype
• hardware/software prototype (‘experimental’)
• application prototype (‘exploratory’)
• to what extent
• mock-ups
• simulated interaction
• partial working models: vertical versus horizontal

SPM (5e) Selection of project approach© The McGraw- 18

Hill Companies, 2009
 Incremental delivery
Break application into small components, implemented and delivered in sequence
Each component must give some benefit to user delivere
Time-boxing: scope of deliverables for increment, agreed deadline
d
system
desig buil insta evaluat
n d ll e
increment
first incremental delivery 1

desig buil insta evaluat increment

n d ll e 2
second incremental delivery

desig buil insta evaluat increment

n d ll e 3

third incremental delivery

SPM (5e) Selection of project approach© The McGraw- 19

Hill Companies, 2009
The incremental process

SPM (5e) Selection of project approach© The McGraw- 20

Hill Companies, 2009
 Incremental approach: benefits
• feedback from early stages used in developing later
stages
• shorter development thresholds
• user gets some benefits earlier
• project may be put aside temporarily
• reduces ‘gold-plating’

BUT there are some possible disadvantages

• loss of economy of scale (may be more productive working on
one large system than on series of smaller ones)
• ‘software breakage’

SPM (5e) Selection of project approach© The McGraw- 21

Hill Companies, 2009
 Overview of incremental plan
• steps ideally 1% to 5% of the total project
• non-computer steps should be included
• 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

SPM (5e) Selection of project approach© The McGraw- 22

Hill Companies, 2009
 which step first?
• some steps will be pre-requisite because of physical
dependencies
• others may be in any order
• value to cost ratios may be used
• V/C where
• V is a score 1-10 representing value to customer
• C is a score 0-10 representing value to developers

SPM (5e) Selection of project approach© The McGraw- 23

Hill Companies, 2009
V/C ratios: an example

SPM (5e) Selection of project approach© The McGraw- 24

Hill Companies, 2009
 Genesis of ‘Agile’ methods
Structured development methods have several
disadvantages
• produce large amounts of documentation which can
largely remain 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?

SPM (5e) Selection of project approach© The McGraw- 25

Hill Companies, 2009
 Agile Methods

• Agile is an umbrella term that refers to a group of

development processes:
• Crystal technologies
• Atern (formerly DSDM)
• Feature-driven development
• Scrum
• Extreme Programming (XP)
• Similar themes:
• Some variations

SPM (5e) Selection of project approach© The McGraw- 26

Hill Companies, 2009
 Important Themes of Agile Methods

• Incremental approach:
• At a time, only one increment is planned, developed,
and then deployed at the customer site.
• Agile model emphasizes face-to-face communication over
written documents.
• An agile project usually includes a customer
representative in the team.
• Agile development projects usually deploy pair
programming.

SPM (5e) Selection of project approach© The McGraw- 27

Hill Companies, 2009
 Atern/Dynamic system development
method (DSDM)

• 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!
• An update of DSDM has been badged as ‘Atern’

SPM (5e) Selection of project approach© The McGraw- 28

Hill Companies, 2009
 Six core Atern/DSDM principles
1. Focus on business need
2. Delivery on time – use of time-boxing
3. Collaborate
4. Never compromise quality
5. Develop iteratively
6. Build incrementally

SPM (5e) Selection of project approach© The McGraw- 29

Hill Companies, 2009
Atern/DSDM framework

SPM (5e) Selection of project approach© The McGraw- 30

Hill Companies, 2009
 Atern 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!

SPM (5e) Selection of project approach© The McGraw- 31

Hill Companies, 2009
 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

SPM (5e) Selection of project approach© The McGraw- 32

Hill Companies, 2009
 extreme programming - contd

• developers work in pairs

• test cases and expected results devised before software
design
• after testing of increment, test cases added to a
consolidated set of test cases

SPM (5e) Selection of project approach© The McGraw- 33

Hill Companies, 2009
 Limitations of extreme programming

• Reliance on availability of high quality developers

• Dependence on personal knowledge – after development
knowledge of software may decay making future
development less easy
• Rationale for decisions may be lost e.g. which test case
checks a particular requirement
• Reuse of existing code less likely

SPM (5e) Selection of project approach© The McGraw- 34

Hill Companies, 2009
 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?

SPM (5e) Selection of project approach© The McGraw- 35

Hill Companies, 2009
macro and micro processes

SPM (5e) Selection of project approach© The McGraw- 36

Hill Companies, 2009
 combinations of approach
installatio
n
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
evolutionaryapproach possible
installation implies evolutionary
construction
SPM (5e) Selection of project approach© The McGraw- 37
Hill Companies, 2009
 ‘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 SPM (5e) Selection of project approach© The McGraw-
Hill Companies, 2009
38