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 byGarett Sader
Modified about 1 year ago
Iterative Project Management Chapter 7.2 – Evolution and Phase Planning Modified considerably by your Instructor
© 2005 Ivar Jacobson International 2 Iterative Project Management / 04 - Phase Planning and Assessment Overview: Iterations Across The Lifecycle Inception –Executable release optional –May only be one iteration Elaboration –Demonstrate critical use cases –Result in executable architecture Construction –Result in usable software –Typically two or more iterations Transition –Releases based on feedback and fixes Early iterations address: High risks Stability Understanding Late iterations address: Functionality Performance Robustness
© 2005 Ivar Jacobson International 3 Iterative Project Management / 04 - Phase Planning and Assessment Planning an Evolution: Iteration Patterns – To show different Strategies… Incremental Development Evolutionary Development Incremental Delivery Extreme Programming / No Elaboration Immediate Construction / Virtual Phases
© 2005 Ivar Jacobson International 4 Iterative Project Management / 04 - Phase Planning and Assessment An Incremental Development Strategy (1 of 2) This is the ‘ideal’ iteration pattern offering all the benefits of ‘rapid application development’ (RAD) without the risks. (Slide next page) “The incremental strategy determines user needs and defines the system requirements, then performs rest of development in a sequence of builds. The first build incorporates parts of the planned capabilities, the next build adds more capabilities, and so on until the system is complete.” [Software Development and Documentation, MIL-STD-498, U.S. Department of Defense, 12/1994] The following iterations are characteristic: a short Inception iteration to establish scope, vision; define business case a single Elaboration iteration; requirements defined, architecture established several Construction iterations; use cases realized, architecture fleshed-out several Transition iterations, migrate product into the user community
© 2005 Ivar Jacobson International 5 Iterative Project Management / 04 - Phase Planning and Assessment Incremental Development - Strategy This strategy is appropriate when: Problem domain is familiar. Architecture is already proven / familiar Risks well understood and under control Team is experienced. A RAD approach…. Time Resources InceptionElaborationConstructionTransition Conceptual Prototype Architectural Baseline ReleaseDelivery
© 2005 Ivar Jacobson International 6 Iterative Project Management / 04 - Phase Planning and Assessment Evolutionary Development – Strategy (1 of 2) This is the pattern that most team’s first iterative and incremental evolution conforms to. (Slide next page) "The evolutionary strategy differs from the incremental in acknowledging user needs are not fully understood, and requirements cannot be defined up front, –Requirements are refined in each successive build." [MIL-STD-498] The following iterations are characteristic: Short Inception iteration - establish scope, vision; define business case Several Elaboration iterations; requirements refined at each iteration and the architecture evolved One or two Construction iterations; use cases realized, architecture is expanded upon; the application given a final polish Several Transition iterations to migrate product into user community
© 2005 Ivar Jacobson International 7 Iterative Project Management / 04 - Phase Planning and Assessment Evolutionary Development This strategy is appropriate when: Problem domain - new or unfamiliar. Architecture - new or unfamiliar all high risk Iterative development - new or unfamiliar factors… Team - inexperienced. (note: number of iterations only for illustrative purposes) Time Resources InceptionElaborationConst’nTransition Conceptual Prototype Architectural Baseline ReleaseDelivery
© 2005 Ivar Jacobson International 8 Iterative Project Management / 04 - Phase Planning and Assessment An Incremental Delivery Strategy…(1 of 2) Pattern where multiple deliveries provided to customer is quite common for Internet site development where new content releases are expected monthly May be required for tight time-to-market pressures, where delivery of certain key features early can yield significant business benefits. [Tom Gilb, Principles of Software Engineering Management, Wokingham, Addison-Wesley, 1988]. In terms of the phase-iteration approach, the transition phase begins early on and has the most iterations. Strategy requires a very stable architecture, which is hard to achieve in an initial development cycle, for an "unprecedented" system. The following iterations are characteristic: Short Inception iteration: establish scope, vision: define business case Single Elaboration iteration - a stable architecture is baselined Single Construction iteration: use cases realized; architecture fleshed-out Several Transition iterations each of which delivers a new release of the product (with increased functionality) into the user community
© 2005 Ivar Jacobson International 9 Iterative Project Management / 04 - Phase Planning and Assessment Incremental Delivery Strategy (2 of 2) This strategy is appropriate when: Small increments have high value to the customer. The architecture is already proven and familiar The requirements are stable and low risk The team is experienced in the architecture and the domain Time Resources InceptionElaborationConst’nTransition Conceptual Prototype Architectural Baseline Delivery
© 2005 Ivar Jacobson International 10 Iterative Project Management / 04 - Phase Planning and Assessment Immediate Construction / Virtual Phases (1` of 2) In some cases, anchor point milestones can be merged. A project deciding to use a mature and appropriately scalable 4 th generation language (4GL) or product line framework will have already determined its choice of life cycle architecture by its LCO milestone enabling the LCO and LCA milestones to be merged. As Barry Boehm observed, in his paper Spiral Development: Experience, Principles and Refinements (CMU/SEI-2000-SR-008), Merging of the milestones is often compounded by the fact that another project (typically a feasibility project or the previous release) has already done the work for you. Leads to pattern appearing like no Inception or Elaboration In this case the phases have been suppressed but the milestones are still there, with the reviews being undertaken before the set of construction iterations can commence.
© 2005 Ivar Jacobson International 11 Iterative Project Management / 04 - Phase Planning and Assessment Immediate Construction / Virtual Phases (2 of 2) This strategy is appropriate when: Architecture already proven and familiar Requirements are known and of low technical risk Team is experienced in the architecture and the domain Project is collaborative and informal Time Resources ConstructionTransition LCO and LCA Passed First Release Delivery
© 2005 Ivar Jacobson International 12 Iterative Project Management / 04 - Phase Planning and Assessment No Elaboration Strategy This is another variant where milestones have been merged providing impression of no Elaboration Phase. Enter most ‘Extreme Programming’ and SCRUM projects Architecture is a given at the start of the set of development iterations. Architecture can be adjusted by refactoring during Construction but this is typical of most iterative and incremental projects post LCA. Some Extreme Programming authors, most noticeably Martin Fowler, would allow technical concerns to affect the allocation of work to the initial development iterations creating an informal Elaboration Phase.
© 2005 Ivar Jacobson International 13 Iterative Project Management / 04 - Phase Planning and Assessment Agile’s Terminology – via Kent Beck Note In Agile and Iterative Development a Manager’s Guide, the XP Lifecycle phases as defined by Beck are described as: Exploration - Purpose: Enough well-estimated story cards for first release, feasibility ensured. –Activities: Prototypes, exploratory proof of technology programming, story card writing and estimating Planning - Purpose: Agree on date and stories for first release. –Activities: Release Planning Game, story card writing and estimating Iterations To First Release - Purpose: Implement a tested system ready for release. –Activities: testing, programming, Iteration Planning Game, task writing, estimating Productionizing - Purpose: Operational deployment. –Activities: documentation, training. marketing …. Maintenance - Purpose: Enhance, fix, build major releases. –Activities: May include these phases again for incremental releases These have been mapped to the UP phases for the purpose of this example
© 2005 Ivar Jacobson International 14 Iterative Project Management / 04 - Phase Planning and Assessment No Elaboration This strategy is appropriate when: Architecture is already proven and familiar Requirements are known and of low technical risk Team is experienced in the architecture and the domain Project team is small; project is collaborative and informal Time Resources InceptionConstructionTransition Start Development Iterations / First Release Date Agreed ReleaseDelivery
© 2005 Ivar Jacobson International 15 Iterative Project Management / 04 - Phase Planning and Assessment Typical Iteration Patterns for Multiple Release Incremental (3) Evolutionary (1) Incremental delivery (4) Immediate Construction (2) Time Resources InceptionElaborati on Const’nTransition Conceptual Prototype Architectural Baseline Delivery Resources Time InceptionElabor ation Construction Transition Conceptual Prototype Architectural Baseline ReleaseDelivery Resources Time Ince ption ElaborationConst’nTransition Conceptual Prototype Architectural Baseline ReleaseDelivery Time Resources ConstructionTransition LCO and LCA Passed First Release Delivery In practice you often end up with a hybrid, some evolution at the beginning, some incremental building, and multiple deliveries.
© 2005 Ivar Jacobson International 16 Iterative Project Management / 04 - Phase Planning and Assessment Think: Among the advantages of the Unified Process phased iterative model is that it lets you accommodate a hybrid approach, simply by increasing the length and number of iterations in particular phases: For complex or unfamiliar problem domains, where there is a high degree of exploratory business work required: increase the length of, and the number of iterations in, the inception phase. For complex or unfamiliar technology problems, where there is a high degree of technological exploratory work required: increase the length of, and the number of iterations in, the elaboration phase. For more complex development technologies, where there is complexity translating the requirements and design into code: increase the length of, and the number of iterations in, the construction phase. To deliver software in a series of frequent incremental releases: increase the length of, and the number of iterations in, the transition phase.
© 2005 Ivar Jacobson International 17 Iterative Project Management / 04 - Phase Planning and Assessment How To Use The Iteration Patterns Think about your risks Think about your team’s skills and experience Think about where your project is in the lifecycle Select a pattern as a reference model –Don’t be scared to adjust the model –You may require a hybrid pattern
© 2005 Ivar Jacobson International 18 Iterative Project Management / 04 - Phase Planning and Assessment How To Use The Numbers Use the numbers to challenge your plans and estimates –The numbers are for “typical projects” –You should be able to explain why your project doesn’t conform The numbers for Inception and Transition carry least weight: –These can vary massively depending on the nature of the project –These figures are not part of the COCOMO statistical model Elaboration should be small in comparison to Construction when considered across the entire endeavor –Architecture is the most important 20% of the development –Elaboration may be relatively large in early project evolutions The only thing we know for certain about your project is that it is not typical
© 2005 Ivar Jacobson International 19 Iterative Project Management / 04 - Phase Planning and Assessment Some Hints and Tips Name Iterations – they have a theme Number iterations within phases. Make milestones real to the business Give project a heartbeat Be prepared to adjust iteration numbers and lengths based on lessons learned Anything beyond the next iteration is only a sketch You cannot create a concrete plan until the end of Elaboration – there are too many unknowns
© 2005 Ivar Jacobson International 20 Iterative Project Management / 04 - Phase Planning and Assessment Effort By Phase By Discipline EIA Stage Inception Development Transition ElaborationConstruction Management14%12%10%14% Environment / CM 10%8%5% Requirements38%18%8%4% Analysis & Design 19%36%16%4% Implementation (Code & Unit Test) 8%13%34%19% Assessment8%10%24% Deployment3% 30% Note: COCOMO II uses Design instead of Analysis and Design. Analysis is not mentioned in the breakdown.
© 2005 Ivar Jacobson International 21 Iterative Project Management / 04 - Phase Planning and Assessment What Gets Produced? The Key Development Products
© 2005 Ivar Jacobson International 22 Iterative Project Management / 04 - Phase Planning and Assessment The 10 Essentials of RUP 1.Vision – Develop a Vision 2.Plan – Manage to the Plan 3.Risks – Identify and Mitigate Risks 4.Issues – Assign and Track Issues 5.Business Case – Examine the Business Case 6.Architecture – Design a Component Architecture 7.Product – Incrementally Build and Test the Product 8.Evaluation – Regularly Assess Results 9.Change Requests – Manage and Control Change 10.User Support – Provide Assistance to the User Source: The Ten Essentials of RUP – The Essence of an Effective Development Process, Leslee Probasco, Rational Software White Paper
© 2005 Ivar Jacobson International 23 Iterative Project Management / 04 - Phase Planning and Assessment Phase Review What to look for at a Phase Review –Why –What –When –Who –Where –How –How Much The Phase Reviews are stakeholder decision points. A go / no go decision is made based upon the business case, risks, progress and plans.
© 2005 Ivar Jacobson International 24 Iterative Project Management / 04 - Phase Planning and Assessment Phases and Use Cases Use-Case State InceptionElaborationConstructionTransition Identified60%> 80%100% Outlined50%20% - 60%0% Described10%40% - 80%100% Analyzed< 10% *20% - 40 %100% Designed, Implemented and Verified < 5% *< 10%100% Source: Adapted from The Unified Software Development Process, Jacobson et al (page 358). * A small percentage may be addressed for proof of concept purposes. By the end of:
© 2005 Ivar Jacobson International 25 Iterative Project Management / 04 - Phase Planning and Assessment Summary / Conclusion Each Phase is driven by a different set of forces –Inception – Business risks –Elaboration – Technical risks –Construction – Project logistical risks –Transition – Solution roll-out risks Each phase needs to be managed a little differently –Each phased requires a different mixture of skills and levels of resources; it is not unreasonable to expect that different teams may staff each phase so long as there is a continuity of vision and expertise across phases Be rigorous about phase-end milestones –Do not move to next phase until you have met milestone objectives –Don’t be pressured by the schedule into “declaring victory” – you will pay for it later!
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome Introductions What is your experience with RUP What is.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Iterative development and The Unified process Chapter 2 Applying UML and Patterns -Craig Larman.
National Association for Regulatory Administration September 13, 2011 IT’s NOT Like Building a House Mark Parker (800)
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 other methodologies 1 Method/Process = step-by-step description of the steps involved.
Unified Software Practices v 5.0-D Copyright 1998 Rational Software, all rights reserved 1 /26 Rational Unified Process – Part 2 Original slides modified.
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Iterative Project Management Chapter 3.2 – The Unified Process Modified considerably by Instructor Class Discussions / Presentations.
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)
Chapter 2 Iterative, Evolutionary, and Agile You should use iterative development only on projects that you want to succeed. - Martin Fowler 1CS
Object-Oriented Analysis and Design Iterative Development and the Unified Process.
1 COMP 350: Object Oriented Analysis and Design Lecture 2Iterative, Evolutionary and Agile References: Craig Larman Chapters 1-2.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles Find the right boundaries for your.
Basic SDLC Models. Agenda SDLC definition Waterfall SDLC V-Shape SDLC Spiral SDLC RUP SDLC Agile methods.
Ninth Lecture Hour 8:30 – 9:20 pm, Thursday, September 13 Checkpoints of the Process (from Chapter 9 of Royce’ book)
CS 325: Software Engineering January 15, 2015 Software Process & Methodology Prototyping Process Model Evolutionary Process Model Spiral Process Model.
UML - Development Process 1 Software Development Process Using UML (2)
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
The Software Product Life Cycle. Views of the Software Product Life Cycle Management Software engineering Engineering design Architectural design.
1 CMPT 275 Software Engineering Software life cycle.
CS 360 Lecture 3. The software process is a structured set of activities required to develop a software system. Fundamental Assumption: Good software.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Review of Definitions Software life cycle: –Set of activities and their relationships to each other to support the development of a software system Software.
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--
September 2008Mike Woodard Rational Unified Process Key Concepts Mike Woodard.
Intelligence and Information Systems 1 3/17/2004 © 2004 Raytheon Company USC/CSE Executive Workshop on Agile Experiences March 17, 2004 A Raytheon Agile.
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.
Successful IT Projects slides © 2007 Darren Dalcher & Lindsey Brodie Successful IT Projects By Darren Dalcher & Lindsey Brodie
Rational Unified Process Mr Hisham AlKhawar. Iterative versus Waterfall We need to use a life cycle model in order to approach developing a system easily,
Rational Unified Process Fundamentals Module 6: Iterative Development Rational Unified Process Fundamentals Module 6: Iterative Development.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
The Rational Unified Process 1 EECS810: Software Engineering.
29 September Interactions There is no “right answer” Typically people and product are fixed … can adapt process (which is where we will.
RATIONAL UNIFIED PROCESS PROCESS FRAMEWORK OVERVIEW.
Software Life Cycles ECE 417/617: Elements of Software Engineering Stan Birchfield Clemson University.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Software Development *Life-Cycle Phases* Compiled by: Dharya Dharya Daisy Daisy
1/23 Prescriptive Process Models. 2/23 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering Prescriptive.
Chapter 8 Workflows of the Process Taken from Walker Royce’s textbook – Software Project Management plus a number of Personal Comments.
Chapter 7: Software production process Refers to the activities that are used for building, delivering, deploying, and evolving a software product, from.
The principles of an object oriented software development process Week 04 1.
Principles of Object Technology Module 1: Principles of Modeling.
© 2017 SlidePlayer.com Inc. All rights reserved.