Iterative Project Management Lifecycle Planning Chapter 5.2 – Second Part: A Layered Approach to Planning and Managing Iterative Projects Modified considerably.

Slides:



Advertisements
Similar presentations
National Association for Regulatory Administration September 13, 2011 IT’s NOT Like Building a House Mark Parker (800)
Advertisements

Unit 2. Software Lifecycle
Chapter 3 Process Models
1 Prescriptive Process Models. 2 Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering Prescriptive process.
Iterative Project Management Lifecycle Planning Chapter 6.1 – Overall Project Planning Modified Considerably by your Instructor.
Learning software process with UPEDU Slide 9-1  2000 École Polytechnique de Montréal & Rational Software Project Management - Outline  Defining the Project.
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
W5HH Principle As applied to Software Projects
Software Architecture for DSD DSD Team. Overview What is software architecture and why is it so important? The role of architecture in determining system.
OO Development Process. UML and Process UML standardizes notation, not process –Increase likelihood of widespread acceptance There is significant variability.
Object-oriented Analysis and Design
CS 501: Software Engineering
Iterative development and The Unified process
Chapter 3: The Project Management Process Groups
COMP 350: Object Oriented Analysis and Design Lecture 2
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Chapter 6 View Alignment Techniques and Method Customization (Part I) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
UML - Development Process 1 Software Development Process Using UML (2)
Object-Oriented Analysis and Design Iterative Development and the Unified Process.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
RUP Fundamentals - Instructor Notes
Developing an IS/IT Strategy
The Rational Unified Process
INFO415 An overview of systems development
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Do it pro bono. Strategic Scorecard Service Grant The Strategy Management Practice is presented by Wells Fargo. The design of the Strategic Scorecard Service.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Certificate IV in Project Management Introduction to Project Management Course Number Qualification Code BSB41507.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Iterative Project Management Chapter 3.2 – The Unified Process Modified considerably by Instructor Class Discussions / Presentations.
Iterative process planning. Overview Introductory Remarks 10.1 Work breakdown structure 10.2 Planning Guidelines 10.3 The cost & Schedule estimating process.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Ahmad Al-Ghoul. Learning Objectives Explain what a project is,, list various attributes of projects. Describe project management, discuss Who uses Project.
Eleventh Lecture Hour 9:30 – 10:20 am, Saturday, September 16 Software Management Disciplines Iterative Process Planning (from Part III, Chapter 10 of.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
Iterative Project Management Lifecycle Planning Chapter 5 – A Layered Approach to Planning and Managing Iterative Projects Modified considerably by your.
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,
Chapter 4 프로세스 모델 Process Models
Inception Chapter 4 Applying UML and Patterns -Craig Larman.
1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 2 Software Processes.
Iterative Project Management Lifecycle Planning Chapter 5 – A Layered Approach to Planning and Managing Iterative Projects Modified considerably by your.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Chapter 8 Workflows of the Process Taken from Walker Royce’s textbook – Software Project Management plus a number of Personal Comments.
The Rational Unified Process 1 EECS810: Software Engineering.
COMPGZ07 Project Management Life-Cycle Planning Graham Collins, UCL
Software Project Management (SEWPZG622) BITS-WIPRO Collaborative Programme: MS in Software Engineering SECOND SEMESTER /1/ "The content of this.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Ivar Jacobson, Grady Booch, and James Rumbaugh The Unified Software Development Process Addison Wesley, : James Rumbaugh's OOMD 1992: Ivar Jacobson's.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
44222: Information Systems Development
Unified Software Practices v 5.0-D Copyright  1998 Rational Software, all rights reserved 1 /26 Rational Unified Process – Part 2 Original slides modified.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
MIS Project Management Instructor: Sihem Smida Project Man agent 3Future Managers1.
CS 389 – Software Engineering Lecture 2 – Part 2 Chapter 2 – Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.
TK2023 Object-Oriented Software Engineering
Process 4 Hours.
The Systems Engineering Context
COMP 350: Object Oriented Analysis and Design Lecture 2
Chapter 2 – Software Processes
Presentation transcript:

Iterative Project Management Lifecycle Planning Chapter 5.2 – Second Part: A Layered Approach to Planning and Managing Iterative Projects Modified considerably by your Instructor

© 2005 Ivar Jacobson International 22 Iterative Project Management / 03 - Lifecycle Planning Objectives Understand why iterative planning is different Understand how iterations and the unified process phases fit in with lifecycle and external release planning Understand how iteration plans integrate with business plans

© 2005 Ivar Jacobson International 3 Positioning the Unified Process Lifecycle Will use the UP as our framework for controlling iterative development.  Note that each application of the UP is known as an evolution which results in a major release of the product. Others may refer to an ‘evolution’ as a ‘cycle.’ To put this into perspective, it is important to note that very few software development projects deliver a complete solution in a single release. –Personally, I’ve never been on one – that sat alone… –Have a series of major, sequential releases; build on previous releases; ‘mod1,’ ‘phase II,’ or whathaveyou. –Each evolution delivers major benefit to clients.

© 2005 Ivar Jacobson International 4 Layering the Plans and Milestones Planning effects a separation of concerns, as mentioned. So we will exploit the management layers we’ve spoken about to provide for a simple set of plans: –one for each layer, –each focused on a different set of issues. Need high level plans to look at the future. –Without these plans lower level efforts could be useless and without focus, even though the iterative approach enables us to do something concrete in each iteration. –High-level plans are necessarily abstract… Need low level plans to get the work done – particularly in an iterative, agile fashion. –Detailed, specific plans; remember: work gets done here!

© 2005 Ivar Jacobson International 5 Planning: a “Separation of Concerns.” This separation of concerns has a number of very important benefits. (Book) –Reduces management overhead and keeps plans and control mechanisms simple and focused –Keeps detail focused on the short term where required. We know that too much detail is counter productive on a longer term basis. –Provides plans with both breadth and depth required to satisfy all stakeholders in the project, and –Enables managers to manage and developers to develop. What a concept!

© 2005 Ivar Jacobson International 6 Overview of all three Plans: Very Important Slide:  Overall project describes the development projects.  Development projects are each an evolution of a product  Each evolution is managed iteratively using RUP lifecycle.  Each UP phase consists of iterations, which in turn are made up of planned and executed activities. Consider the next slide: There will be: One overall project plan for the project as a whole. One development plan for the current evolution. An iteration plan for the current iteration in the evolution. As this iteration progresses and its results start to become apparent the planning of the next iteration starts.

© 2005 Ivar Jacobson International 77 Iterative Project Management / 03 - Lifecycle Planning How Many Evolutions / External Releases? The reality is that very few projects deliver a single external release –One pass through the Unified Process lifecycle Most projects deliver the system in series of major external releases –Multiple passes through the lifecycle InceptionElaborationConstructionTransition One evolution, deploying one major external release Evolution 1Evolution 2Evolution 3 Multiple evolutions, each deploying a major external release

© 2005 Ivar Jacobson International 88 Iterative Project Management / 03 - Lifecycle Planning How Many Plans Do You Need? This says it all. Overall Project Plan Iteration Plan Iteration 1Iteration 2Iteration 3 Inception Evolution 1Evolution 2Evolution 3 The Overall Project Task 1 Task 2 Task 3 ElaborationConstructionTransition Development Plan One for the current iteration plus, possibly, the outline of the next. While there may be some variation, in general each plan can be (and probably should be) no longer than a few pages.

© 2005 Ivar Jacobson International 99 Iterative Project Management / 03 - Lifecycle Planning High Level Plans Focus On Achievements Iteration 1Iteration 2Iteration 3 Inception Evolution 1Evolution 2Evolution 3 The Overall Project Task 1 Task 2 Task 3 ElaborationConstructionTransition We have a UP evolution for each major external release (Release 1, 2, 3 etc) During the transition of Release 1, fixes and emergency releases may be required (Releases 1.1, 1.2, 1.3 etc). This is a very common occurrence! These release numbers would be the result of undertaking Transition iterations as part of first evolution, hence Release 1.x numbers.

© 2005 Ivar Jacobson International 10 The Overall Project Plan Each major project has a single, brief, overall project plan. Will contain a number of evolutions and anticipated major releases needed to provide the overall solution. –These can come from the major planning, vision, overall functionality needed, etc. This plan should include –Overall milestone dates, –functionality delivered, (prioritized and when needed) –risks to be addressed, and the –overall resource levels needed. The overall resources used and business benefit delivered tie back to the Business Case developed for the solution. The overall project plan is a high-level roadmap for the project as a whole. (Chapter 6 – more details)

© 2005 Ivar Jacobson International 11 The Current Development Plan (Evolution; Life Cycle) This is the single plan for the current evolution. The Development Plan describes the lifecycle milestones (e.g. LCA, IOC, etc.) and goals for each phase. This plan also identifies the number and purpose of the iterations they contain. (but not much detail for the iterations.) Iteration goals are identified. The plan may also specify numbers and skills of people needed at different times. –All specialties are not always needed. As a specific evolution progresses and we see good business value developing, we may start to plan and ‘firm up’ the next evolution. Producing the Development Plan for an Evolution: (Chap 7)

© 2005 Ivar Jacobson International 12 The Current Iteration Plan There’s a single iteration plan for the current iteration. –Iteration plan is detailed; describes activities to be done. –Most susceptible to change; real work occurs. Note we do not plan details of each iteration at start of project. Precludes changes propagating through entire set of detailed plans. As done for evolutions, as an iteration progresses and starts to deliver value, the planning of the next iteration starts. (Chapter 8) –In practice, most iterative project managers create a rough draft of the plan for the next iteration alongside the current iteration plan. –As current iteration continues, the draft plan for the next iteration may be modified and slowly evolve into the plan for next iteration. –Deferred tasks / changes and may fold into the next iteration. Book note of caution: Be careful not to “over plan” the next iteration before the results of the current iteration are known.

© 2005 Ivar Jacobson International 13 Iterative Project Management / 03 - Lifecycle Planning Detail Is Pushed Down Into the Iteration Plans Iteration 1Iteration 2Iteration 3 Inception Evolution 1Evolution 2Evolution 3 The Overall Project Task 1 Task 2 Task 3 ElaborationConstructionTransition As Bittner and Spence suggest, we have ‘Top down’ macro level planning; forward looking, low fidelity, low precision, optimistic. Bottom up: we have micro level planning backward looking, high fidelity, high precision, pessimistic. Details of plans increase as we go down the layers while the scope of plan narrows. Overall project plan is visible to entire organization, whereas the plan for an iteration is usually only visible to those working on it.

© 2005 Ivar Jacobson International 14 Iterative Project Management / 03 - Lifecycle Planning Detail Is Pushed Down Into the Iteration Plans Iteration 1Iteration 2Iteration 3 Inception Evolution 1Evolution 2Evolution 3 The Overall Project Task 1 Task 2 Task 3 ElaborationConstructionTransition Each successive level refines but yet shields us from the details below it. Overall project plan has broadest horizon and focuses on decisions and commitments that affect the project as a whole. Details are pushed down through the development plans into the iteration plans. For layering to work, we need to outline the entire project in a robust time neutral manner that accommodates project Over- and under- performance.

© 2005 Ivar Jacobson International 15 Iterative Project Management / 03 - Lifecycle Planning Plans Are Achievement Based Overall Project Plan Iteration Plan Development Plan Overall Project Plan – Business Milestones Coverage - All Evolutions Focus on achievements, commitments and constraints Development Plan – Technical Milestones Coverage – Development of a Major External Release Focus on achievements, commitments, constraints, the current evolution and some of the next evolution Iteration Plan – Iteration Significant Milestones Coverage – Single Iteration Lower levels must contain detailed plan on project activities

© 2005 Ivar Jacobson International 16 Iterative Project Management / 03 - Lifecycle Planning The Plans Share Milestones Overall Project Plan Iteration Plan Development Plan Overall Project Plan – Business Milestones and External Commitments. These are allocated to development projects to be achieved. Provide link between business plans and the development plans. May involve more than just software development. Development Plan – Technical Milestones; Single Evolution Developed and Released. These are added to provide stepping stones on the way to achieving the business milestones and align the technical development project defined by the UP lifecycle to the overall project plan. Milestones provide structure and focus to reduce risk and encourage progress toward delivery of a major release. Iteration Plan – Iteration focus. Shows how assignment requirements will be developed and how technical risks will be mitigated. Team working plan. Milestones from the development plan - allocated to iterations. Provides means by which development team coordinates its work within a time box defined by the iteration.

© 2005 Ivar Jacobson International 17 Tolerance – Managing Across the Layers… A good way is to set and apply tolerances. Could be related to any of the project drivers; –scope, –cost, –time, –quality. Most organizations set tolerances in all of these areas. If the project exceeds, or looks like it is going to exceed its tolerances then the deviations are reported up the levels and new plans need to be made. Example project tolerances include: Time tolerance – up to two weeks slippage is allowed Quality tolerance – no major external release can have any ‘priority one’ defects and no more than three ‘priority twos.’ Scope tolerance – All ‘must have’ requirements, at least 70% of ‘should haves’ Cost – No more than $300,000

© 2005 Ivar Jacobson International 18 Bittner and Spence elaborate: –The tolerances on the iterations will vary across iterations and phases. –If we find a ‘priority one defect’ in the first elaboration iteration this is good, especially if it is in a third party component, as we have plenty of time to get it fixed. –A ‘priority one defect’ in a late construction iteration, especially if it is in a third party component, is a bit of disaster as there is little time to fix it before the system goes live.

© 2005 Ivar Jacobson International 19 Iterative Project Management / 03 - Lifecycle Planning Plans Include Tolerances Overall Project Plan Iteration Plan Development Plan Overall Project Tolerances set by the Business. Development Project Tolerances set by the Overall Project Manager. Iteration Tolerances derived from the Development Plan. Project Tolerances External Release Phase / Tolerances Iteration Tolerances Note that the tolerances are established by the next ‘higher up’ Concern….

© 2005 Ivar Jacobson International 20 Iterative Project Management / 03 - Lifecycle Planning Deviations Cause Re-planning Overall Project Plan Iteration Plan Development Plan Project Tolerances External Release / Phase Tolerances Poor Iteration Performance Iteration Tolerances Project Plan Deviations Re-plan External Release / Phase Deviations Iteration Deviations Re-plan If the project exceed or looks like it will exceed its tolerances, then the deviations are reported up the levels and new plans need to be made.

© 2005 Ivar Jacobson International 21 Iterative Project Management / 03 - Lifecycle Planning Key Management Roles Overall Project Manager Development Project Manager Iteration Lead Note: These roles need to be filled. Does not mean every project needs three managers. In many cases all three roles will be fulfilled by one person: the project mgr. For larger, or more formal projects, it is not unusual for the roles to be shared among a number of people often with a more senior project manager in the Overall Project Manager, a specialist development manager in Development Project Manager Role and team leaders taking on the role of Iteration Lead.

© 2005 Ivar Jacobson International 22 Iterative Project Management / 03 - Lifecycle Planning Management Responsibilities and Reviews RoleResponsibilitiesGateway Review Overall Project Manager Overall Project Planning Set the management strategy Stage Reviews Overall Project Close-down Development Project Manager Evolution Planning Phase Reviews and Software Project Close-down Iteration Lead Iteration Planning Team leading Iteration Assessment For the project to be ‘joined up,’ the management must work as a team to plan and assess the project. The three management roles share the responsibilities of the traditional UP Project Manager role.

© 2005 Ivar Jacobson International 23 Iterative Project Management / 03 - Lifecycle Planning Discussion: What Are Your Projects Like? How many external releases do you have? Who commissions / supervises your projects? How many levels does your project have? How far ahead do you plan? What kind of projects do you manage? What is the structure of your management team? What constraints do you operate under? What problems do you have? What Does Iterative Planning Change?