Chapter 04 project approach
1 like152 views
The document discusses the selection of appropriate project approaches in software project management, highlighting various methodologies such as Agile, Waterfall, and Prototyping. It outlines the advantages and disadvantages of building vs. buying software, the incremental delivery process, and specific techniques like Extreme Programming and Scrum. The focus is on tailoring methods to project characteristics and client needs, emphasizing the importance of communication, collaboration, and iterative development.
Chapter 04 project approach
- 1. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 1 Software Project Management UNIT 2 Chapter Four Selection of an appropriate project approach
- 2. Knowing Is Not Enough…..; We Must Apply…... Wishing Is Not Enough……; We Must Do……!!!! 24-07-20 SPM (5e) Selection of project approach© The McGraw-Hill Companies, 2011 2
- 3. SPM (5e) Selection of project approach© The McGraw-Hill Companies, 2009 3 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
- 4. SPM (5e) Selection of project approach© The McGraw-Hill Companies, 2009 4 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
- 5. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 5 Build or buy? Outsourc e? In-house developm ent? Build Buy either
- 6. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 6 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
- 7. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 7 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
- 8. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 8 General approach • Look at risks and uncertainties e.g. • are requirement 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
- 9. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 9 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 • Future vision: Model-Driven Architecture (MDA). UML supplemented with Object Constraint Language, press the button and application code generated from the UML/OCL model
- 10. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 10 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
- 11. Difference between motivation and inspiration Motivation is external and short lived. Inspiration is internal and lifelong -Sri Sri Ravi Shankar SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 11
- 12. 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 (6e) Selection of project approach© The McGraw-Hill Companies, 2017 12
- 13. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 13 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
- 14. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 14 Waterfall
- 15. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 15 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
- 16. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 16 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
- 17. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 17 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
- 18. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 18 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
- 19. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 19 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
- 20. Don't be pushed around by the fears in your mind…… Be led by the dreams in your heart…..
- 21. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 21 Incremental delivery desig n buil d instal l evaluat e desig n buil d instal l evaluat e desig n buil d instal l evaluat e increment 1 increment 2 increment 3 first incremental delivery second incremental delivery third incremental delivery delivered system
- 22. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 22 The incremental process
- 23. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 23 Incremental approach: benefits • feedback from early stages used in developing latter 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 • ‘software breakage’
- 24. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 24 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
- 25. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 25 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
- 26. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 26 V/C ratios: an example
- 27. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 27 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?
- 28. 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 (6e) Selection of project approach© The McGraw-Hill Companies, 2017 28
- 29. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 29
- 30. Important Themes of Agile Methods • Base on the 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 (6e) Selection of project approach© The McGraw-Hill Companies, 2017 30
- 31. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 31 Atern/Dynamic system development method (DSDM) • UK-based consortium • arguably DSDM can be seen as replacement for SSADM (Structured System Analysis and Design Method) • 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’
- 32. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 32 Eight core Atern/DSDM principles 1. Focus on business need 2. Delivery on time – use of time-boxing 3. Collaborate 4. Never compromise quality 5. Deliver iteratively 6. Build incrementally 7. Communicate continuously 8. Demonstrate control
- 33. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 33
- 34. 34
- 35. 35
- 36. 36
- 37. 37
- 38. 38
- 39. 39
- 40. 40
- 41. 41
- 42. 42
- 43. 43
- 44. 44
- 45. 45
- 46. 46
- 47. 47
- 48. 48
- 49. 49
- 50. 50
- 51. 51
- 52. 52
- 53. 53
- 54. 54
- 55. 55
- 56. 56
- 57. 57
- 58. 58
- 59. 59
- 60. 60
- 61. 61
- 62. 62
- 63. 63
- 64. 64
- 65. 65
- 66. 66
- 67. 67
- 68. 68
- 69. 69
- 70. 70
- 71. 71
- 72. 72
- 73. 73
- 74. 74
- 75. 75
- 76. 76
- 77. 77
- 78. 78
- 79. 79
- 80. 80
- 81. 81
- 82. 82
- 83. 83
- 84. 84
- 85. 85
- 86. 86
- 87. 87
- 88. 88
- 89. 89
- 90. 90
- 91. 91
- 92. 92
- 93. 93
- 94. 94
- 95. 95
- 96. 96
- 97. 97
- 98. 98
- 99. 99
- 100. 100
- 101. 101
- 102. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 102 Atern/DSDM framework
- 103. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 103 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!
- 104. Extreme Programming Model • Extreme programming (XP) was proposed by Kent Beck in 1999. • The methodology got its name from the fact that: • Recommends taking the best practices to extreme levels. • If something is good, why not do it all the time. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 104
- 105. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 105 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
- 107. Taking Good Practices to Extreme • If code review is good: • Always review --- pair programming • If testing is good: • Continually write and execute test cases --- test-driven development • If incremental development is good: • Come up with new increments every few days • If simplicity is good: • Create the simplest design that will support only the currently required functionality. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 107
- 108. Taking Good Practices to Extreme • If design is good, • everybody will design daily (refactoring) • If architecture is important, • everybody will work at defining and refining the architecture (metaphor) • If integration testing is important, • build and integrate test several times a day (continuous integration) SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 108
- 109. Extreme programming Another methodology but why? •Social Change- Giving up defences •Based on Excellent programming techniques, clear communication and teamwork •Lightweight – only do whatever adds value to the customer •Addresses constraints in software development •Can work with teams of any size •Adapts to rapidly changing requirements
- 110. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 110 Extreme programming • 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
- 111. Extreme programming XP addresses risks at all levels of development process •Schedule Slips •Defect Rate •Business misunderstood •Business changes •False feature list •Staff turnover
- 112. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 112 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
- 113. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 113 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?
- 114. Follow your passion….. It will lead you to your purpose SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 114
- 115. Project Characteristics that Suggest Suitability of Extreme Programming • Projects involving new technology or research projects. • In this case, the requirements change rapidly and unforeseen technical problems need to be resolved. • Small projects: • These are easily developed using extreme programming. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 115
- 116. Agile Methods • Agile Modeling • Agile Unified Process (AUP) • Dynamic Systems Development Method (DSDM) • Essential Unified Process (EssUP) • Extreme Programming (XP) • Feature Driven Development (FDD) • Open Unified Process (OpenUP) SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 116
- 117. Scrum • One of the “agile processes” • Self-organizing teams • Product progresses in a series of month-long “sprints” • Requirements are captured as items in a list of “product backlog” SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 117
- 118. Scrum Characteristics • Simple and scalable • Empirical process • Short-term detailed planning with constant feedback provides simple inspect and adapt cycle • Simple techniques and work artifacts • Requirements are captured as user stories in a list of product backlog • Progress is made in Sprints • Teams collaborating with the Product Owner • Optimises working environment • Reduces organisational overhead • Detects everything that gets in the way of delivery • Fosters openness and demands visibility SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 118
- 119. Scrum Team • These are the people who build products, make estimates • Scrum recommends team sizes of 7 • The teams are cross functional SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 119
- 120. Sprints • Scrum projects make progress in a series of “sprints” • Analogous to XP iterations (Is an iteration ) • Target duration is one month (Can have 1 day of sprint planning, 4 days of work and 1 day of sprint review ) • +/- a week or two • Sprints range from a couple of days to 30 days • During a sprint, a product increment is designed, coded, and tested • Sprints are short duration milestones SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 120
- 121. • More smiling, less worrying... • More compassion, less judgment…. • More blessed, less stressed…. • More love, less hate….
- 122. Key Roles in Scrum Process • Three core roles and a range of ancillary roles • Core Scrum roles: • Product Owner • Team • Scrum Master • Ancillary roles: • Stakeholders (customers, vendors) • Managers (including Project Managers) SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 122
- 123. Key Roles in Scrum Process • Product Owner • Acts on behalf of customers to represent their interests. • Development Team • Team of five-nine people with cross-functional skill sets. • Scrum Master • Facilitates scrum process and resolves impediments at the team and organization level by acting as a buffer between the team and outside interference. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 123
- 124. Scrum Ceremonies • A team's agility is built on engineering practices, a strategic approach to development and change, and great team collaboration. • Agile ceremonies facilitate communication across the team and promote shared understanding of what is being built within a sprint. • Scrum Ceremonies are • Sprint Planning Meeting • Sprint • Daily Scrum • Sprint Review Meeting • SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 124
- 125. • What is it? A collaborative effort involving a • Scrum Master- who facilitates the meeting, • a Product Owner- who clarifies the details of the product backlog items and their respective acceptance criteria, and • the Development Team- who define the work and effort necessary to meet their sprint goal. • In this meeting, the product owner and the team members decide which Backlog Items the Team will work on in the next sprint • Scrum Master should ensure that the Team agrees to realistic goals SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 125 Sprint Planning
- 126. • What does the team do? • Capacity Planning : Team collaboration to decide how much time can be allocated to the sprint. • Sprint Goal: The product owner’s summary of the desired outcome for the sprint being planned. It provides a shared objective, and states why it’s worthwhile undertaking the sprint. • Sprint Backlog - The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. • During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. • User stories are pulled into the sprint backlog based on a collective agreement of the team. This is a chance for the team to ask questions to clarify what is being asked in the user story if not covered fully in backlog refinement. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 126 Sprint Planning
- 127. Sprint Planning • What is the Output? • A sprint goal and sprint backlog to work from for the time boxed sprint. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 127
- 128. Sprint • Fundamental process flow of Scrum • A month-long iteration, during which an incremental product functionality completed • NO outside influence can interfere with the Scrum team during the Sprint • Each Sprint begins with the Daily Scrum Meeting SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 128
- 129. Daily Scrum • Held daily: • Short meeting • Lasts for about 15mins only • Main objective is to answer three questions: • What did you do yesterday • What will you do today? • What obstacles are in your way? SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 129
- 130. Sprint Review Meeting • Team presents what it accomplished during the sprint • Typically takes the form of a demo of new features or underlying architecture • Informal meeting: • The preparation time should not exceed about 2-hours SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 130
- 131. The past is a place of reference, not a place of residence…..; the past is a place of learning…., not a place of living…..” SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 131
- 132. Sprint Artifacts • Product backlog • Sprint backlog • Sprint burndown chart SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 132
- 133. Product Backlog • All work items related to a product/project, ordered by a Product Owner. • A list of all desired work on the project --- usually a combination of : • story-based work (e.g. “let user search and replace”) • task-based work (“improve exception handling”) • List is prioritized by the Product Owner SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 133
- 134. Sprint Backlog • The sprint backlog comes from the product backlog, but it contains only that item, or those items, that can be completed during each sprint. • A subset of Product Backlog Items, which define the work for a Sprint • Created by Team members • Each Item has it’s own status • Updated daily SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 134
- 135. Sprint Burndown Chart • A burn down chart shows how much work is remaining to be done in the project, • Day-wise depicts the total Sprint Backlog hours remaining • Ideally should burn down to zero to the end of the Sprint SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 135
- 137. Lean Software Development • It based on the principle “Just in time production” • It aims at increasing speed of software development and decreasing cost • Lean development can be summarized in seven steps: 1) Eliminating Waste 2) Amplifying learning 3) Defer commitment (deciding as late as possible) 4) Early delivery 5) Empowering the team 6) Building Integrity 7) Optimize the whole SPM (5e) Selection of project approach© The McGraw-Hill Companies, 2009 137
- 138. Managing Iterative Processes • There are two levels of development suggested by Booch i.e. • Micro Process • Macro Process : •closely related with waterfall process model. •At this level, a range of activities carried out by a variety of specialist groups has to be coordinated. •Within the macro process there will be micro process activities which might involve iterative working SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 138
- 139. macro and micro processes • The figure illustrate • how a sequential macro process can be imposed on a number of iterative sub-processes. • With iterative micro processes, the use of time-boxes is needed to control at the macro level SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 139
- 140. Attitude is a choice…. Happiness is a choice…. Optimism is a choice…. Kindness is a choice…. Giving is a choice…. Respect is a choice…. Whatever choice you make makes you. Choose wisely..!! SPM (5e) Selection of project approach© The McGraw-Hill Companies, 2009 140
- 141. Selecting the most appropriate Process Model SPM (5e) Selection of project approach© The McGraw-Hill Companies, 2009 141
- 142. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 142 combinations of approach yes yes no yes yes yes yes yes no evolutionar y incremental evolutionar y incremental one-shot one-shot installation con stru ctio n • one-shot or incremental installation - any construction approach possible • evolutionary installation implies evolutionary construction
- 143. EVOLUTIONARY PROJECT MANAGEMENT A project management process delivering evolutionary results “ high-value-first“ progress towards the desired goals, and seeking to obtain, and use, realistic, early feedback.
- 144. SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 144 ‘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
- 145. The Five Core Values of XP 145 Communicatio n. Simplicity. Feedback. Courage. Respect
- 146. Communication 146 Often problem that arise in SW project can be tracked back to lack of communication. XP enforces the Communication Value by employing many practice that could not be carried without communicating (e.g. pair programming, unit testing etc.). XP employs a Coach whose job is that of noticing when people are not communicating and reintroduce them.
- 147. Simplicity 147 ''Do the simplest thing that could possibly work'' (DTSTTCPW) principle (elsewhere known as KISS). An XP coach may say DTSTTCPW when he sees an XP developer doing something that is needlessly complicated. YAGNI principle (''You ain’t gonna need it'') Simplicity and Communication support each other mutually.
- 148. Feedback 148 Feedback works in XP at different time scales. Programmers have feedback on a minutes time scale on the status of the system thanks to unit tests. When customers write new stories the programmers estimate those immediately to give prompt feedback to the customer about the quality of the stories. The customer review the scheduler every 2-3 weeks and provide prompt feedback to the developer.
- 149. Courage XP team should have the courage of throwing code away. XP team should have the courage of mainly refactor the architecture of the system, if architectural flaw are detected. Courage with counterbalancing values is dangerous. Doing something without regard for consequences is not effective teamwork. 149
- 150. Thank you…!! SPM (6e) Selection of project approach© The McGraw-Hill Companies, 2017 150