lecture 3: project management methods and related software development lifecycle approaches
TRANSCRIPT
Lecture 3:
Project management methods and related software development lifecycle approaches
Project lifecycles
System Lifecycle
Systems development lifecycle
Project management lifecycle
Project Start Project End
Manage theproject
Modify thesystem
Project lifecycles
System Lifecycle
Systems development lifecycle
Project management lifecycle
Project Start Project End
Manage theproject
Modify thesystem
Project management lifecycle
• Concept• Definition• Implementation• Handover and closeout
(APM BoK 2006)
Project management lifecycle
DetermineBusiness
Case
Close Project
EvaluateProject
Select Project Proposal
ManageProject
Commence 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 ?
• Process-based management– PMI’s PMBOK Guide– APM BoK– CMMI (Capability Maturity Model Integration)– SPICE (SW Process Improvement & Capability dEtermination)
Later – PRINCE2 Lectures
Later – Agile Lectures
Project lifecycles
System Lifecycle
Systems development lifecycle
Project management lifecycle
Project Start Project End
Manage theproject
Modify thesystem
Project management lifecycle
DetermineBusiness
Case
Close Project
EvaluateProject
SystemsDevelopment
Lifecycle
Select Project Proposal
ManageProject
Commence Project
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!
The Waterfall ModelSystem
Requirements
SoftwareRequirements
Analysis
ProgramDesign
Coding
Testing
Operations
Winston Royce 1970
The Waterfall ModelSystem
Requirements
SoftwareRequirements
Analysis
ProgramDesign
Coding
Testing
Operations
Winston Royce (1970)
Royce actually believed in incremental and iterative models.An accident that people picked up on his Page 1 diagram
Larman (2004)
The Waterfall ModelSystem
Requirements
SoftwareRequirements
Analysis
ProgramDesign
Coding
Testing
Operations
Winston Royce (1970)
Leaves systems integration and testing too late
Client / Market only see the system when
resources almost all used up
V-Process Model
Level of Abstraction
Time
MoreDetailedDesign
Increasing Levels of Testing
User requirements
System specification
System design
Systems architectural design
Code Unit testing
Integration testing
Function testing
System testing
User acceptance testing
Field testing
Basically a waterfall model
Example of a Waterfall Method:Structured System Analysis and Design Method (SSADM)
Outline Business Specification• Existing Environment• Business System Options
Analysis of the Current System / Feasibility Study
Detailed Business Specification / Requirements Specification
Logical Data Design
Logical Process Design
Physical Design
Incremental / Phased Delivery
Increment 1
Increment 5
Increment 2
Increment 3
Increment 4
Phase 1 Phase 5Phase 4Phase 3Phase 2Delivery to Customer of Increment 1
Delivery to Customer of Increment 2
Delivery to Customer of Increment 3
Delivery to Customer of Increment 4
Delivery to Customer of Increment 5
Waterfall Models
Crashed Increments
Increment 1
Increment 5
Increment 2
Increment 3
Increment 4
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
• Incremental
• Prototyping
• Iterative / Evolutionary
Waterfall Linear – one pass / one delivery
Increment 1 Increment n...
Throw–away version of
some system aspect
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: • Evolutionary delivery (Evo)• Spiral model• RUP (Rational Unified Process)• DSDM (Dynamic Systems Development Method)• XP (Extreme Programming)• Scrum• Lean
Today
Later – Agile Lectures
Some Timelines
1980 1990 2000 20101970
Waterfall 1970
DSDM 1994
Gilb’s Evo 1976
Iterative 1970 IBM FSD Harlan Mills
RAD Prototyping Early 1980s
SSADM Early 1980s
Boehm’s Spiral mid 1980s
Unified Process (UP) mid 1990s
Agile Manifesto 2001
‘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”– ‘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
There are issues with the
terminology: none of the terms is quite
right!
‘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
Act Plan
DoStudy*Execute Plans
Plan ActionsDecide Actions Needed
Study Results of Actions Taken
* Deming finally decided to use ‘Study’ instead of ‘Check’ (Gilb 2005)
Iterative Result Cycle
Sequence for deliveryEstimated value known
Actual Results Feedback
Plan
Do
ActStudy
PlanIncrement
Requirements
Stakeholder ValueDeliver
Increment Designs
Slightly modified from (Brodie and Woodman 2008)
For each Iteration:
Based on the Shewhart Cycle
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
EvoResultCycle
StrategicManagement Cycle
DevelopmentCycle
DeliveryCycle
‘The Head’
‘The Body’
Result Cycle
Backroom
Frontroom
ProductionCycle
Backroom
Feedback ‘Go’
(Gilb 2005)
Evo Step Development and Delivery
Time
Backroom‘KITCHEN’
Frontroom‘RESTAURANT’
Step 1Step 2
Step 1
Step 2
Step 3
Potential Next Step(Step 4)
Step 3
A
B
C
D
E
F
G
H
E
GC
F
BH
A
D
Implementation Cycle for F
Development& Production Cycles
Delivery Cycle
Step 1Step 2Step 3
From (Gilb 2005)
Evo Step Development and Delivery
Time
Backroom‘KITCHEN’
Frontroom‘RESTAURANT’
Step 1Step 2
Step 1
Step 2
Step 3
Potential Next Step(Step 4)
Step 3
A
B
C
D
E
F
G
H
E
GC
F
BH
A
D
Implementation Cycle for F
Development& Production Cycles
Delivery Cycle
Step 1Step 2Step 3(Gilb 2005)
Think how a restaurant
prepares food in the kitchen and
then delivers it to the table. Total preparation can take weeks, but
courses delivered as customers want
them! You don’t have to build everything
only in the duration of one increment. But
focus must be on early delivery and
early feedback!
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
Waterfall
Increment 1 Increment n
Throwaway version of
some system aspect
Prior to building the real system
Recap: Systems development lifecycle approaches
• Sequential
• Incremental
• Prototyping
• Iterative / Evolutionary
Linear – one pass / one delivery
...
Build and deliver the system,increment by increment
Act Plan
DoStudy
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, Addison-Wesley, 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.