Presentation is loading. Please wait.

Presentation is loading. Please wait.

Lecture 3: Project management methods and related software development lifecycle approaches.

Similar presentations


Presentation on theme: "Lecture 3: Project management methods and related software development lifecycle approaches."— Presentation transcript:

1 Lecture 3: Project management methods and related software development lifecycle approaches

2 Project lifecycles System Lifecycle Systems development lifecycle Project management lifecycle Project StartProject End Manage the project Modify the system

3 Project lifecycles System Lifecycle Systems development lifecycle Project management lifecycle Project StartProject End Manage the project Modify the system

4 Project management lifecycle Concept Definition Implementation Handover and closeout (APM BoK 2006)

5 Project management lifecycle Determine Business Case Close Project Evaluate Project Select Project Proposal Manage Project Commence Project Adapted from Marchewka 2003

6 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 )

7 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

8 Project lifecycles System Lifecycle Systems development lifecycle Project management lifecycle Project StartProject End Manage the project Modify the system

9 Project management lifecycle Determine Business Case Close Project Evaluate Project Systems Development Lifecycle Select Project Proposal Manage Project Commence Project Adapted from Marchewka 2003

10 Systems development lifecycle approaches Sequential Incremental Prototyping Iterative / Evolutionary

11 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!

12 The Waterfall Model System Requirements Software Requirements Analysis Program Design Coding Testing Operations Winston Royce 1970

13 The Waterfall Model System Requirements Software Requirements Analysis Program Design 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)

14 The Waterfall Model System Requirements Software Requirements Analysis Program Design 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

15 V-Process Model Level of Abstraction Time More Detailed Design Increasing Levels of Testing User requirements System specification System design Systems architectural design CodeUnit testing Integration testing Function testing System testing User acceptance testing Field testing Basically a waterfall model

16 Example of a Waterfall Method: Structured System Analysis and Design Method (SSADM) Outline Business Specification Existing Environment Business System Options 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

17 Incremental / Phased Delivery Increment 1 Increment 5 Increment 2 Increment 3 Increment 4 Phase 1 Phase 5Phase 4Phase 3Phase 2 Delivery 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

18 Crashed Increments Increment 1 Increment 5 Increment 2 Increment 3 Increment 4 Delivery to customer on completion of each increment

19 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

20 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

21 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

22 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

23 Some Timelines 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

24 ‘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

25 ‘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!

26 ‘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

27 The Shewhart Cycle or Deming Cycle ActPlan DoStudy* Execute Plans Plan ActionsDecide Actions Needed Study Results of Actions Taken * Deming finally decided to use ‘Study’ instead of ‘Check’ (Gilb 2005)

28 Iterative Result Cycle Sequence for delivery Estimated value known Actual Results Feedback Plan Do Act Study Plan Increment Requirements Stakeholder Value Deliver Increment Designs Slightly modified from (Brodie and Woodman 2008) For each Iteration: Based on the Shewhart Cycle

29 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

30 Evo Result Cycle Strategic Management Cycle Development Cycle Delivery Cycle ‘The Head’ ‘The Body’ Result Cycle Backroom Frontroom Production Cycle Backroom Feedback‘Go’ (Gilb 2005)

31 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 G C F B H A D Implementation Cycle for F Development & Production Cycles Delivery Cycle Step 1 Step 2Step 3 From (Gilb 2005)

32 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 G C F B H A D Implementation Cycle for F Development & Production Cycles Delivery Cycle Step 1 Step 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! 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!

33 Factors influencing project failure Yardley (2002) Technical FailureHuman FailureProcess Failure Lure of the leading edgeLack of executive supportAbsence of any project management methodology Poor technical designLack of leadershipAbsence of any systems development methodology Technical solution to a non-technical problem Uncommitted project teamAbsence of any benefits management methodology Dependence on software packages to satisfy requirements Dysfunctional project teamFailure to identify and mitigate project risks Lack of tools throughout development lifecycle Failure to manage third partiesFailure to manage requirements Technology-led developmentLack of a project ‘champion’Lengthy project timescales Lack of project ownershipInsufficient 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

34 Summary Project management lifecycle Systems development lifecycle approaches Systems development lifecycle models

35 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 ActPlan DoStudy Use feedback

36 References Yardley, D. (2002), Successful IT Project Delivery, Addison-Wesley, ISBN Association for Project Management (2006), Project Management Body of Knowledge (5 th Edition) (APM BoK 2006), ISBN Project Management Institute (2008), A Guide to the Project Management Body of Knowledge (4 th Edition) (PMBOK Guide), ISBN X. Marchewka, J. T. (2003), Information Technology Project Management: Providing Measurable Organizational Value, Wiley, ISBN Royce, W. (1970). Managing the Development of Large Software Systems: Concepts and Techniques. Proceedings of IEEE WESCON. August Originally published by TRW. Larman, C. (2004), Agile and iterative Development: A Manager’s Guide, Addison- Wesley, ISBN Gilb, T. (2005), Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage, Butterworth-Heinemann. ISBN Dalcher, D. & Brodie, L. (2007), Successful IT Projects, Thomson, ISBN 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 , pp


Download ppt "Lecture 3: Project management methods and related software development lifecycle approaches."

Similar presentations


Ads by Google