Lecture 3:
Project management methods and
related software development
lifecycle approaches
Project lifecycles
Project management lifecycle
Manage the
project
Systems development lifecycle
Modify the
system
System Lifecycle
Project Start
Project End
Project lifecycles
Project management lifecycle
Manage the
project
Systems development lifecycle
Modify the
system
System Lifecycle
Project Start
Project End
Project management lifecycle
•
•
•
•
Concept
Definition
Implementation
Handover and closeout
(APM BoK 2006)
Project management lifecycle
Select
Project
Proposal
Determine
Business
Case
Commence
Project
Manage
Project
Close
Project
Evaluate
Project
Adapted from
Marchewka 2003
Project Management Methods
• PRINCE2
• Scrum ?
• Process-based management
– PMI’s PMBOK Guide
– APM BoK
– CMMI (Capability Maturity Model Integration)
– SPICE (SW Process Improvement & Capability dEtermination)
Project Management Methods
• PRINCE2
• Scrum ?
Later – PRINCE2 Lectures
Later – Agile Lectures
• Process-based management
– PMI’s PMBOK Guide
– APM BoK
– CMMI (Capability Maturity Model Integration)
– SPICE (SW Process Improvement & Capability dEtermination)
Project lifecycles
Project management lifecycle
Manage the
project
Systems development lifecycle
Modify the
system
System Lifecycle
Project Start
Project End
Project management lifecycle
Select
Project
Proposal
Determine
Business
Case
Commence
Project
Manage
Project
Close
Project
Evaluate
Project
Systems
Development
Lifecycle
Adapted from
Marchewka 2003
Systems development lifecycle
approaches
• Sequential
• Incremental
• Prototyping
• Iterative / Evolutionary
Sequential
• Linear
• No / Little feedback
• Widely discredited for systems where the
requirements are unknown upfront and/or
complex and/or are changing. However, if the
requirements are known upfront, then it
works!
System
Requirements
The Waterfall Model
Winston Royce 1970
Software
Requirements
Analysis
Program
Design
Coding
Testing
Operations
System
Requirements
The Waterfall Model
Winston Royce (1970)
Software
Requirements
Royce actually believed in
incremental and iterative models.
An accident that people picked
up on his Page 1 diagram
Larman (2004)
Analysis
Program
Design
Coding
Testing
Operations
System
Requirements
The Waterfall Model
Winston Royce (1970)
Software
Requirements
Analysis
Leaves systems
integration and
testing too late
Program
Design
Client / Market
only see the
system when
resources almost
all used up
Coding
Testing
Operations
V-Process Model
Basically a waterfall model
Level of
Abstraction
More
Detailed
Design
User requirements
Increasing
Levels of
Testing
Field testing
User acceptance testing
System specification
System testing
System design
Function testing
Systems architectural design
Code
Integration testing
Unit testing
Time
Example of a Waterfall Method:
Structured System Analysis and Design Method (SSADM)
Analysis of the Current System / Feasibility Study
Outline Business Specification
•Existing Environment
•Business System Options
Detailed Business Specification / Requirements Specification
Logical Data Design
Logical Process Design
Physical Design
Incremental / Phased Delivery
Waterfall Models
Increment 1
Increment 2
Increment 3
Increment 4
Increment 5
Phase 1
Phase 2
Delivery to
Customer
of Increment 1
Phase 3
Delivery to
Customer
of Increment 2
Phase 4
Delivery to
Customer
of Increment 3
Phase 5
Delivery to
Customer
of Increment 4
Delivery to
Customer
of Increment 5
Crashed Increments
Increment 1
Increment 2
Increment 3
Increment 4
Increment 5
Delivery to customer
on completion of each increment
Prototyping
• Build a throw-away version of some aspect of the system for
demonstration to the stakeholders
• Testing out some aspect of risk: for example the user interface or maybe
technical feasibility
• Aim to get rapid feedback before committing too much effort/resources
• Problem is that often prototypes end up becoming the system........
• Take care over the term ‘prototype’!
DSDM (Dynamic Systems Development Method) uses the term
‘prototype’, but you can argue it is a different kind of prototyping as
not throw-away. Similar with Boehm’s Spiral Model
• Link with RAD (Rapid Application Development) which involved use of data
dictionaries and automated tools to build systems
Recap: Systems development lifecycle
approaches
• Sequential
Linear – one pass / one delivery
Waterfall
• Incremental
Increment 1
• Prototyping
Throw–away
version of
some system
aspect
• Iterative / Evolutionary
...
Increment n
Prior to
building the
real system
Build and deliver
the system,
increment by increment
Systems development lifecycle models
• Sequential: waterfall model
• Incremental: multiple waterfall models
• Incremental phased delivery
• Prototyping
• Iterative / Evolutionary:
•
•
•
•
•
•
•
Evolutionary delivery (Evo)
Spiral model
RUP (Rational Unified Process)
DSDM (Dynamic Systems Development Method)
XP (Extreme Programming)
Scrum
Lean
Systems development lifecycle models
• Sequential: waterfall model
• Incremental: multiple waterfall models
• Incremental phased delivery
• Prototyping
• Iterative / Evolutionary:
•
•
•
•
•
•
•
Today
Evolutionary delivery (Evo)
Spiral model
RUP (Rational Unified Process)
DSDM (Dynamic Systems Development Method)
XP (Extreme Programming)
Scrum
Lean
Later – Agile
Lectures
Some Timelines
Waterfall 1970
SSADM Early 1980s
RAD Prototyping Early 1980s
DSDM 1994
Iterative 1970 IBM FSD Harlan Mills
Gilb’s Evo 1976
Boehm’s Spiral mid 1980s
Unified Process (UP) mid 1990s
Agile Manifesto 2001
1970
1980
1990
2000
2010
‘Iterative’ / Evolutionary
Terminology Issues:
– Larman (2004) sometimes uses “Incremental and
Iterative”, sometimes shorter “Iterative”
– Gilb (1988) uses “Evolutionary”
– ‘Incremental’ means building in steps
– ‘Iterative’ means repeating/going round again
– But there is also learning from feedback
– ‘Evolutionary’ not in the biological sense of small
random mutations or survival of the fittest (though
parallel builds a possibility
‘Iterative’ / Evolutionary
Terminology Issues:
– Larman (2004) sometimes uses “Incremental and
Iterative”, sometimes shorter “Iterative”
– Gilb (1988) uses “Evolutionary”
There are issues
– ‘Incremental’ means building in steps
with the
– ‘Iterative’ means repeating/goingterminology:
round again
none
of the terms is quite
– But there is also learning from feedback
right!
– ‘Evolutionary’ not in the biological sense of small
random mutations or survival of the fittest (though
parallel builds a possibility
‘Iterative’ / Evolutionary
• Based on the Shewhart Cycle from 1930s. Also known as the
Deming Cycle (Deming worked with Shewhart).
•
•
•
•
•
•
•
Involves increments/iterations
Time-boxing (varying durations)
Delivery to market or client
Incorporates feedback (learning)
Being prepared to retreat
Not ‘freezing’ the requirements
Decide what to do in the next increment/iteration using the
feedback from the last increment/iteration and the current set
of requirements
The Shewhart Cycle or Deming Cycle
Decide Actions
Needed
Plan Actions
Act
Study Results
of Actions Taken
Study*
Plan
Do
Execute Plans
* Deming finally decided to use ‘Study’ instead of ‘Check’ (Gilb 2005)
Iterative Result Cycle
Based on the Shewhart Cycle
For each Iteration:
Requirements
Act
Actual Results
Feedback
Study
Deliver
Increment
Designs
Stakeholder Value
Plan
Do
Plan
Increment
Sequence for delivery
Estimated value known
Slightly modified from
(Brodie and Woodman 2008)
Evolutionary Project Management
(Evo)
• Developed by Tom Gilb (2005) in the 1960s
(published from 1976)
• Principles
– Small Steps (2%-5% of project time and money budget)
– Early High Value
– Actual Benefits
– Evaluation of High Risk
– Frequent Delivery
– Use Feedback
– Allow Requirements to change
Evo
Result
Cycle
Feedback
Strategic
Management
Cycle
‘Go’
‘The Head’
Development
Cycle
Backroom
Production
Cycle
‘The Body’
Backroom
Delivery
Cycle
Frontroom
Result Cycle
(Gilb 2005)
Evo Step Development and Delivery
Backroom
‘KITCHEN’
Frontroom
‘RESTAURANT’
A
Potential Next Step
(Step 4)
B
B
C
C
Development
Delivery
& Production Cycles
Cycle
F
D
H
Step 3
D
E
A
G
F
Implementation Cycle for F
Step 2
G
E
H
Step 1
Step 1 Step 2 Step 3
Time
Step 1 Step 2 Step 3
From (Gilb 2005)
Evo Step Development and Delivery
Backroom
‘KITCHEN’
Frontroom
‘RESTAURANT’
Think how a
restaurant
prepares food in
A
the kitchen and
Potential Next Step A
then
delivers it to
(Step 4)
D
B
the table. Total
preparation can
B
C
take weeks, but
H
Step 3 courses delivered
D
as customers want
C
E
them!
G
Development
Delivery
You don’t have to
& Production Cycles
F
Cycle
F
build everything
Implementation Cycle for F
only in the
Step 2
duration of one
G
E
increment. But
focus must be on
H
Step 1
early delivery and
early feedback!
Step 1 Step 2 Step 3
Step 1 Step 2 Step 3
Time
(Gilb 2005)
Factors influencing project failure
Yardley (2002)
Technical Failure
Human Failure
Process Failure
Lure of the leading edge
Lack of executive support
Absence of any project
management methodology
Poor technical design
Lack of leadership
Absence of any systems
development methodology
Technical solution to a non-technical
problem
Uncommitted project team
Absence of any benefits
management methodology
Dependence on software packages to
satisfy requirements
Dysfunctional project team
Failure to identify and mitigate
project risks
Lack of tools throughout development
lifecycle
Failure to manage third parties
Failure to manage
requirements
Technology-led development
Lack of a project ‘champion’
Lengthy project timescales
Lack of project ownership
Insufficient testing
Stakeholder conflict
‘Big-bang’ approach to
computerization
Resistance to change
Hostile organizational culture
Inexperienced project managers
Lack of business justification
Unclear or ambiguous business
priorities
Lack of user training
Misaligned stakeholder motivation
Summary
• Project management lifecycle
• Systems development lifecycle approaches
• Systems development lifecycle models
Recap: Systems development lifecycle
approaches
• Sequential
Linear – one pass / one delivery
Waterfall
• Incremental
Increment 1
• Prototyping
Throwaway
version of
some system
aspect
• Iterative / Evolutionary
...
Build and deliver
the system,
increment by increment
Increment n
Prior to
building the
real system
Act
Plan
Study
Do
Use feedback
References
•
•
•
•
•
•
•
•
•
Yardley, D. (2002), Successful IT Project Delivery, Addison-Wesley, ISBN
0201756064.
Association for Project Management (2006), Project Management Body of
Knowledge (5th Edition) (APM BoK 2006), ISBN 1903494133. www.apm.org.uk
Project Management Institute (2008), A Guide to the Project Management Body of
Knowledge (4th Edition) (PMBOK Guide), ISBN 193069945X. www.pmi.org
Marchewka, J. T. (2003), Information Technology Project Management: Providing
Measurable Organizational Value, Wiley, ISBN 0471392030.
Royce, W. (1970). Managing the Development of Large Software Systems:
Concepts and Techniques. Proceedings of IEEE WESCON. August 1970. Originally
published by TRW.
Larman, C. (2004), Agile and iterative Development: A Manager’s Guide, AddisonWesley, ISBN 0131111558.
Gilb, T. (2005), Competitive Engineering: A Handbook For Systems Engineering,
Requirements Engineering, and Software Engineering Using Planguage,
Butterworth-Heinemann. ISBN 0750665076.
Dalcher, D. & Brodie, L. (2007), Successful IT Projects, Thomson, ISBN 1844806995.
Brodie, L. & Woodman, M. (2009), Using Metrics to Express Quality, Proceedings of
the Seventeenth International Conference on Software Quality Management (SQM
2009), The British Computer Society, ISBN 9781906124229, pp 93-104.