We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byRoy Spake
Modified about 1 year ago
Iterative Project Management Lifecycle Planning Chapter 4 – Selected Sections Are you Ready for Iterative Project Management? pp ;
© 2005 Ivar Jacobson International 2 Iterative Project Management / 03 - Lifecycle Planning I. Introduction There are many problems with adapting to an iterative / incremental development approach that people perceive. We will discuss several of the key issues. Right Attitude: In truth, much of the transition requires the team to have the –right attitude toward the projects and –how to work together. – Real change in mind-set must be accommodated –Willingness to eschew the conventional methods.
© 2005 Ivar Jacobson International 3 Iterative Project Management / 03 - Lifecycle Planning Attitude is Critical! Attitude is the Real Key! New attitudes are needed. –Must Address Uncertainty and Change – Best way: clearly demonstrate real progress; Best shown: working software that provides real value. –Verified; testaments… –Must deliver immediate and realizable value back to the business –Must address our attitude regarding teamwork and accountability Will be interacting with many stakeholders continuously ; shared responsibilities, etc. –Must adopt a progressive attitude – a real change in estimating, planning, and managing the software project The right team attitude is critically important!
© 2005 Ivar Jacobson International 4 Iterative Project Management / 03 - Lifecycle Planning Value Delivery – The Key to Success It is absolutely essential to produce real business value We must realize: –Requirements are not all equal. –Value working components vice technical components (like a sort) Delivering requirements with verified code might not be delivering the best business value Don’t worry about implementing lots of requirements at the expense of not focusing on real desired outcomes. –Track stakeholder and business value, not project cost and schedule It is all about delivering verified, measurable Business Value!
© 2005 Ivar Jacobson International 5 Iterative Project Management / 03 - Lifecycle Planning Quick failure recipes: Requirements Business Solution Implementing requirements versus solving problems. –Problems are of a higher order… will include meeting requirements Iterative / incremental projects can fail too if developers concentrate on implementing requirements rather than iteratively solving problems. Addressing technical risk which is fine - without concomitant business value. Iterative projects can fail if developers concentrate on addressing technical risks and yet fail to deliver usable versions of software that provide realizable benefit.
© 2005 Ivar Jacobson International 6 Iterative Project Management / 03 - Lifecycle Planning Value Delivery – The Key to Success – slide 2 Great Statistics: –Research indicates only two-thirds of implemented features in successful projects were often actually required. –Around one-third of developed software had little or no business value. What an incredible waste of resources!!! Consider: “20% of requirements have been implemented by such and such a date.” –This does NOT necessarily reflect real value Generally, by the end of the first iteration or two in Construction, we should have a usable, complete release that may implement around 50% of the requirements. (Why?) –Interestingly, at this point with proper iteration planning, they may have produced a system with 80% of desired value –But if iterations not carefully planned and pressed on implementing lesser (but perhaps more in number) requirements, then may have around 20% of desired value.
© 2005 Ivar Jacobson International 7 Iterative Project Management / 03 - Lifecycle Planning Value Delivery – The Key to Success – 3 The key is to ensure requirements implemented in an iteration can be mapped back to specific outcomes. The first iterations must implement the most important desired outcomes as constrained by technical risk Must be able to support these claims! Do so by demonstrating desired / measurable outcomes. Ancillary: technical risks / issues are resolved.
© 2005 Ivar Jacobson International 8 Iterative Project Management / 03 - Lifecycle Planning Demonstrate Measurable Value – Executable Threads Iterations simply must deliver measurable value to the project team and the business. –Assertions are fine. Demonstrate it! Successful Iterations define release contents in terms of Executable releases that contain end-to-end behavioral threads of system usage. Executable Thread? –An end-to-end thread may be a use-case, or user story, scenario. (A scenario is an instantiation of a use-case) Complete threads of usage drive other development activities to ensure verifiable systems are produced.
© 2005 Ivar Jacobson International 9 Iterative Project Management / 03 - Lifecycle Planning Planning that Iteration! Plan those Early Iterations! Know use-cases describe the goals of the system stakeholders. Planning iterations via use-cases / scenarios allows us to scope and prioritized development. We also know risks in projects threaten the team’s ability to deliver. Confront the Risks: –Overall risks of a solution may be mitigated by choosing scenarios that force the confrontation of the risks!!! Map Risks into Early Scenarios: –Map these scenarios into the early iterations –Successful development and demonstration provide objective assessment that thus measurably reduce risk, –Provide key functionality and show real business value. Iterations can thus be planned to ensure every iteration steadily reduces project risk and increases business value realized from the solution.
© 2005 Ivar Jacobson International 10 Iterative Project Management / 03 - Lifecycle Planning End-to-end Threads and Tangible Value Successful implementation of end-to-end threads (scenarios) provides tangible business value. Selection of scenarios also subdivides the requirements enabling their assignment for development / delivery –Scenarios in a use case may be assigned to different iterations. WHY?? Each scenario tells a complete story of how discrete value is delivered by the system. –By delivering a complete scenario one-by-one, we are adding an increment and thus realizable value. This provides focus on delivered value and enables tracking to project’s desired outcomes and risks that threaten its success
© 2005 Ivar Jacobson International 11 Iterative Project Management / 03 - Lifecycle Planning II. Changing the Way You Think About Planning We know: –Management of the development process is most critical. –Common knowledge that most projects fail due to poor planning and requirements management. –Entire project must be managed iteratively. –Successful iterative program management is more than just repeatedly applying technical knowledge But: The Project Manager (PM) must really believe the iterative approach is the best way to manage the project. –PM may need to convince many people. –But if PM is not convinced, then little likelihood to convince others. –PM must be ready to set aside any inflexible, predictive, waterfall management practices used in the past. This may be very difficult.
© 2005 Ivar Jacobson International 12 Iterative Project Management / 03 - Lifecycle Planning Conventional Project Lifecycle Revisited: Specify Design Develop Traditional, Sequential Approach Test Change Over. But this is an engineering approach used for years – but never meant for software. –Approach is predictable. Engineering approach was applied to software development Its sequential notion of activities gave rise to Waterfall Model.
© 2005 Ivar Jacobson International 13 Iterative Project Management / 03 - Lifecycle Planning Conventional Thinking About Planning – Morphed from Engineering SpecifyDesignDevelopTestChange Over The Conventional Project Lifecycle Requirements Analysis Design Code Test Deploy The ‘Waterfall’ Software Development Lifecycle
© 2005 Ivar Jacobson International 14 Iterative Project Management / 03 - Lifecycle Planning Waterfall Planning is based on several beliefs (from book): Products can be completely developed in one pass Requirements can be completed and frozen early All requirements are of equal importance Designs can be verified without building and testing something. The entire project can be planned in detail with a high degree of precision at the start of the project Everything important can be known at the beginning of the project The project can ‘earn’ value by only doing one discipline at a time. Most importantly, if we follow the prescriptive steps of our process, then all the project risks will be addressed and therefore one should measure teams on their ability to follow a plan and managers on their ability to create a plan. –Plan-driven –Documentation intensive, etc. The waterfall process attempts to do each step very well and eliminate redoing any steps again, once a step is completed The plan itself is regarded as ‘lock’ and ‘contract;’ inviolate and perfect. Any deviations are considered highly undesirable.
© 2005 Ivar Jacobson International 15 Iterative Project Management / 03 - Lifecycle Planning Problems with Waterfall Planning Assumptions Almost all the assumptions are incorrect for software development. We are always developing something new or redesigning something to meet new requirements for a changing business. Business conditions change all the time as do technologies. But in the waterfall model: (book) – Problems are discovered too late to do anything about them – – Imagination and testing are always left until the end where, more often than not, they are cut back in an attempt to meet original delivery date – Design feedback is obtained late usually leading to late design breakage, when it is too late to fix problems in the architecture – Because objective feedback provided by demonstration and testing is only obtained late in the project, risk resolution typically occurs too late to be effective. (right arrows are mine)
© 2005 Ivar Jacobson International 16 Iterative Project Management / 03 - Lifecycle Planning More Reality is: Significant problems seem to always occur near the end of the project. –Here, time is critical, staffing is maxed; costs at their highest; –deployment dates are set; perhaps equipment is installed; –transition to the new system is well established, and –many have staked their reputation (and future) on the successful deployment of the application. So here we are: It is the failure of conventional planning wisdom on so very many projects especially for high-value, high-risk projects has led to the evolution of a –risk-driven, –progressive, –adaptive, –iterative and incremental approach to software development.
© 2005 Ivar Jacobson International 17 Iterative Project Management / 03 - Lifecycle Planning Progressive (‘rolling’) Assertions About Planning (book) Some points from the textbook include: –Proceed in small steps; Continuing steadily by increments –Break large projects into smaller projects –Initial designs will be flawed –Initial estimates have large margins of errors – most waterfall projects cost two to three times what was initially predicted –Requirements must evolve along demonstratable versions of product –Teams: must ‘own’ / be accountable for achievements and plans –One must believe the project results not the project plans –Detailed planning should be limited to the next milestone –Projects: adopt an active / aggressive approach to project risk Only the creation of an executable prototype that demonstrates that the products can work together truly addresses risk.
© 2005 Ivar Jacobson International 18 Iterative Project Management / 03 - Lifecycle Planning So, here we go – the ‘cookbook:’ Instead of developing the whole system in one ‘go,’ an increment is selected and developed, then another increment, and so on The selection of the contents of the increment is based on risk, addressing the highest priority risks first particularly those involving core functionalities To address selected risk(s), select a subset of requirements from end-to-end threads (scenarios) to be implemented and tested, and verified (independently) Develop the minimal set of functionality that enables objective measurement and verification (through a set of executable tests) that the risks have been successfully addressed Then select the next highest risks and functionality associated with these risks for the next iteration and increment. Continue… Each iteration produces an executable release. Each iteration includes integration and test.
© 2005 Ivar Jacobson International 19 Iterative Project Management / 03 - Lifecycle Planning Framework – Unified Process We often use the Unified Process because it provides a risk-based framework that supports and enables the progressive, adaptive (“rolling”) planning of software development projects. (Page 150) Note that every discipline in the Iterative Lifecycle has some role in every phase (extents may vary) In this way, iterative planning is adaptive because plans will change as risk is dealt with in an iteration. –Thus requirements might change, analysis and design will likely be impacted by change, etc.. –Hence the disciplines (analysis, design, configuration management, etc.) are present in every iteration.
© 2005 Ivar Jacobson International 20 Iterative Project Management / 03 - Lifecycle Planning Comparing Conventional and Iterative Thinking on Planning ConventionalProgressive Risk agnosticActively attacks risk Risks drives the iterations. Predictive planningAdaptive planning Planning can respond to change Subjective measurement of progressObjective measurement of progress by demonstration of business value Delays integration and testingContinuous integration and testing Not done until the end where time is scrunched Nothing runs until the endSomething executable produced every iteration Vice subjectively measure progress Difficulties at the end of the projectDifficulties at the start of the project
© 2005 Ivar Jacobson International 21 Iterative Project Management / 03 - Lifecycle Planning Seven Habits of Successful Iterative Project Managers (book) In Summary: –Break large projects into smaller projects and then break the smaller projects up into iterations –Attach the greatest risk in the earliest iterations –Produce something demonstratable every iteration –Do not delay integration and test Every iteration should include integration and test activities –Be prepared to make mistakes and explore blind alleys. Mistakes are to be encouraged if they reduce the project risk or challenge the project’s assumptions. –Plans must be adjusted based on lessons learned
© 2005 Ivar Jacobson International 22 Iterative Project Management / 03 - Lifecycle Planning Application of these principles leads to Changes in management behavior These are summed up in the next seven habits: (book) –Steadily focus on advancing the solution in small but deliberate steps –Focus on generating results but not afraid to fail –Exercise adaptive planning continuously –Always be risk-aware –Always be open and honest –Focus on objective results-based assessments (not subjective opinion-based ones) –Singularly focus on delivering a working solution.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Page 1 R Risk-Driven and Iterative Development. Page 2 R Copyright © 1997 by Rational Software Corporation What the Iterative Life Cycle Is Not It is.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Object Oriented Analysis and Design Introduction.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome Introductions What is your experience with RUP What is.
1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
5/30/20161 Iterative Project Management Chapter 2 – How Do Iterative Projects Function? Part 1 Iterative Project Management / 01 - Iterative and Incremental.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 ISA&D7/8/ ISA&D7/8/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
1 COMP 350: Object Oriented Analysis and Design Lecture 2Iterative, Evolutionary and Agile References: Craig Larman Chapters 1-2.
Unified process(UP) UP is an OO system development methodology offered by Rational(Rational Rose) s/w, now a part of IBM Developed by Booach,Rambaugh,Jacobson--
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
1 Requirements Engineering for Agile Methods Lecture # 41.
Prescriptive Process models Waterfall Model. Incremental Process Model. Evolutionary Process Model. Concurrent model 1.
UML - Development Process 1 Software Development Process Using UML (2)
CS 360 Lecture 3. The software process is a structured set of activities required to develop a software system. Fundamental Assumption: Good software.
© 2005 Prentice Hall14-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
Capability Maturity Models Software Engineering Institute (supported by DoD) The problems of software development are mainly caused by poor process management.
Unified Software Practices v 5.0-D Copyright 1998 Rational Software, all rights reserved 1 /26 Rational Unified Process – Part 2 Original slides modified.
SWE311_Ch03 (071) Software & Software Engineering Slide 1 Chapter 3 Prescriptive Process Models.
Stand Up Comedy Project/Product Management. Site Manager Aleksandar Ubavkov https://mk.linkedin.com/in/aubavkov.
1 CSE 403 Software Lifecycle Models Reading: Rapid Development Ch. 7, 25 (further reading: Ch. 21, 35, 36, 20) These lecture slides are copyright (C) Marty.
Describing Methodologies PART II Rapid Application Development* Systems Analysis and Design II.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department Southern Illinois University Carbondale.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Basic SDLC Models. Agenda SDLC definition Waterfall SDLC V-Shape SDLC Spiral SDLC RUP SDLC Agile methods.
Fourteenth Lecture Hour 9:30 – 10:20 am, Sunday, September 16 Software Management Disciplines Project Control and Process Automation (from Part III, Chapter.
Ivar Jacobson, Grady Booch, and James Rumbaugh The Unified Software Development Process Addison Wesley, : James Rumbaugh's OOMD 1992: Ivar Jacobson's.
Software Engineering CE 501 Prepared by : Jay Dave.
Chapter 7: Software production process Refers to the activities that are used for building, delivering, deploying, and evolving a software product, from.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
Applied Software Project Management Andrew Stellman & Jennifer Greenehttp://www.stellman-greene.com1 Applied Software Project Management Chapter 1: Introduction.
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Chapter 8 Workflows of the Process Taken from Walker Royce’s textbook – Software Project Management plus a number of Personal Comments.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
CSE Senior Design I Building a Plan Instructor: Mike O’Dell Several of the slides in this module are a modification and amplification of slides prepared.
1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software.
Teaching material for a course in Software Project Management & Software Engineering – part II.
1 Software Process Models-ii Presented By; Mehwish Shafiq.
© 2017 SlidePlayer.com Inc. All rights reserved.