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 byElwin Greene
Modified about 1 year ago
Iterative Project Management Lifecycle Planning Chapter 6.1 – Overall Project Planning Modified Considerably by your Instructor
© 2005 Ivar Jacobson International Preface to Overall Project Planning Well into this chapter, the authors state that they had a number of reservations about including this chapter. They particularly did NOT want to give the impression that an entire project can be planned up front before any iterations take place. They assert that one must balance –high-level life-cycle planning with –low-level execution of the iterations.
© 2005 Ivar Jacobson International Preface to Overall Project Planning Planning is essential at various levels, but one must not obsess too much about where you are going to end up – you are unlikely to go anywhere. Unfortunately, while much of the material might appear to be common sense, people under pressure to deliver frequently –lose common sense in planning and –ignore several of the sacred principles. Plan well, Plan carefully, and Trust your plans…
© 2005 Ivar Jacobson International Introductory Remarks – Overall Project Plan Overall project plan –Should be lightweight plan –Should summarize long-term direction for the project –Should identify major releases to be produced –Should identify business benefits to be realized. –Should be simple, –Should ensure project is in synch with the organization, –Should enable project integration with any strategic or higher-level program management plans, and –Should provide the context for successful iterative development of the software products.
© 2005 Ivar Jacobson International Initial Questions Important initial questions re: Overall Project Plan: –Single or multiple releases? –When are specific business capabilities needed? –Can some requirements be delayed to deliver others early? –What are the latest date decisions can be made without impeding the business? –How can work be organized to accomplished all this with time and resources provided?
© 2005 Ivar Jacobson International Initial Questions So we develop a ‘project roadmap.’ –An overview of all major releases, goals, major requirements and risks and strategy for how and when you will make critical decisions. –If several major releases, then ‘development projects’ will drive all this in the form of ‘evolutions.’ –Major releases will evolve into the overall software solution.
© 2005 Ivar Jacobson International Evolution and Release Planning Most significant question is, ‘What is the release strategy?’ How often? How significant of a release? Most projects plan major releases along with provisions for additional ‘point releases’ that address smaller issues (quality, smaller / minor enhancements). Large number of deliveries? Likely not tolerable by the business. Single UP evolution? (major release at the end of a long period) may also be equally undesirable as business value is not delivered frequently enough. Alternatives include shortening Elaboration and Construction, send out a release, and then use Transition to ‘clean things up.’ In here, have a number of short-term releases…
© 2005 Ivar Jacobson International Evolution and Release Planning - more Probably best approach is to stage major releases with contents dictated by business concerns, such that each evolution is a planned delivery. (four slides up) There is a balancing act here: balance number of major releases with rate the business can absorb them. (Not always easy…) To do this, need to layer plans to support such a strategy –Simple Overall Project Plan for the project: focuses only on the major releases (in terms of evolutions) and the associated commitments made to the business, and –Low level development plan: describes how evolution will be realized. How about addressing risks in three major releases?
© 2005 Ivar Jacobson International Moving Risks Around in Multiple Evolutions Can spread risk around in some cases? May allow project to adapt to time, scope, cost, and resource constraints It may be that the success criterion is ‘first to market.’ So it might be better to defer architectural risk mitigation until after initial delivery. –Might be the way to go, but –Might need to rewrite a lot if the architecture changes substantially. Evolution planning, as part of the overall project planning, must explicitly describe the release strategy and allow for some conscious trade-offs of business and technical risks. Strategies for balancing risks across evolutions include: –pulling some risks forward or –pushing some risks backwards. Advantages and disadvantages to each approach. What are they?
© 2005 Ivar Jacobson International Handling Sequential Evolutions Most evolutions are sequential with some small overlap. Overlap is VERY important. It can provide for –more efficient use of some resources (people with special skills, … )and –reduce total elapsed project time (some parallel activities). Rules that apply when planning evolutions: 1. An evolution cannot complete a phase before the previous evolution has completed the same phase. 2. An evolution should not enter the Elaboration Phase before the previous evolution has exited its Elaboration Phase. 3. The more overlap, the more work that occurs in parallel the more potential for conflicting changes.
© 2005 Ivar Jacobson International Overlap Patterns: Most typical overlap patterns are: (next slide for visual) overlap of Inception phase of next evolution with Transition phase of current evolution, or Overlap of Inception phase with latter iterations of the Construction Phase of the current evolution. This is because the inception, construction, and transition phases do not affect the architecture of the overall solution, so dependencies are greatly reduced enabling work to proceed in parallel.
© 2005 Ivar Jacobson International 12 Iterative Project Management / 03 - Lifecycle Planning Benefits Realization and External Release Planning Initiation Stage 1 Stage 2Stage 3 Release 1 Release 2 Adapted from the PRINCE2 manual: Figure 16.6 page 237 Inc ElabConTrans Inception ElaborationCon Trans ElabCon Trans Inc Stage 4 Release 3 Training Hardware Roll-out Marketing and Communications Benefit Delivery
© 2005 Ivar Jacobson International Multiple Evolutions Are many incentives for early and frequent product deliveries. Particularly true when key functionality may be deliverable early prior to the rest of the system being needed. This may be good for morale and team visibility. Converse is also possible and highly undesirable! Remember: planning a solution across evolutions is a roadmap not a detailed plan.
© 2005 Ivar Jacobson International Deployment of Multiple Evolutions Multiple Evolutions may –Provide earlier solution delivery / deployment –Provide a focus for architectural work in each evolution –Avoid the big bang business change and migration –Enable project to be split up into smaller, sequential projects –Enable maintenance and support to be factored into plans –Enable alignment to the organization’s budget cycles, and more.
© 2005 Ivar Jacobson International Number of Evolutions? What are the Factors to Determine? Many: (Book) – Length of time business can wait for a solution –Sponsoring organization’s sense of urgency –Budget cycle and funds available –Size and complexity of the deployment –Window of opportunity for deployment –Infrastructure and technology cycles – Degree to which requirements can be deployed separately – Degree to which different stakeholder communities require different capabilities and services. Deliver solution in a series of progressively more functional releases. Be careful to have a stable architecture for consistency across a series of releases. Architecture must be stabilized for the functionality of the solution to be partitioned.
© 2005 Ivar Jacobson International Style of the Overall Project Plan Only difference between planning for conventional vs iterative approach is that layering removes unnecessary detail from the high- level plans enabling the overall plan to focus on business commitments, notable achievements, management decision points. Senior managers often feel iterative project is: –uncontrolled technical development with –no ‘proper’ (in their perspective) long-term plans, –little visibility of what’s taking place, and –ineffective management controls. But overall project plan can provide appropriate visibility Note: senior management doesn’t care about development techniques They –Do care if the project is out of control and –Do care if there are no long-term plans to illustrate where project is heading. –Do care if only have a plan for the next iteration and nothing beyond.
© 2005 Ivar Jacobson International 17 Iterative Project Management / 03 - Lifecycle Planning So we have: Lifecycle Planning Stage Planning –Identifying the major evolutions / external releases and business decision points Evolution / External Release Planning –Defining the number of evolution cycles required Phase and Iteration Planning –Relating the business and technical milestones –Planning the phases and iterations Lifecycle planning is required at all levels of the project.
© 2005 Ivar Jacobson International 18 Iterative Project Management / 03 - Lifecycle Planning Principles of Lifecycle Planning (bold type is mine) Understand the desired outcomes Identify and assess overall risk Set the management strategy Create an achievement-based roadmap Understand the solution and its scope Assess and estimate the work to be done Define the project plans Delegate the execution of the plans Iteratively evolve and challenge the plans
© 2005 Ivar Jacobson International Principles of Lifecycle Planning – first three First three principles define risks, objectives, and constraints –(Arrows are mine…) – Understand Desired Outcomes Make sure you understand what you want to achieve. Focus on value delivered – to whom not the activities undertaken or artifacts addressed –Identify and assess risks Anticipate obstacles to achieving the desired outcomes. – Set the management strategy What is the approach to manage and control the project? –What are the processes to follow, how results will be measured, how progress will be reviewed, events reported, decisions made..
© 2005 Ivar Jacobson International Next Three: - from book: Next three principles establish project roadmap. Low precision but high fidelity – provides big picture view. –Create an Achievement-based Roadmap Shows fundamental things to be achieved, their order, dependencies, and maybe which ones can be deployed together. Products produced, dates needed, Does NOT show who will do the work or how long the work will take! It is a roadmap not a plan. –Understand the Solution and its Scope Determine project scope; boundary of the solution and quality and other ility requirements. Here’s where use cases and other requirements artifacts are important. –Assess and Estimate the work to be done Assess current state of project; how much effort the project will take to complete, determine resources needed, etc.
© 2005 Ivar Jacobson International Last Three – directly from Book (arrows are mine): Enable more detailed project plans to be agreed upon, executed, tested, challenged, and improved. – Secure agreement on the Project Plan(s) Identify dates for milestones lying within the current event horizon and define tolerances related to each milestone. For each subproject identified, apply appropriate life cycle to ratify plans and introduce additional milestones,… Add management review points required to control project risk. –Facilitate the Execution of the Plan(s) Executing plan asap. Planning without execution produces nothing. –Iteratively Evolve and Challenge the Plan(s) Overall project plan is only a sketch to be elaborated, expanded, and adapted as the project progresses. Its main purpose is to provide the vision and roadmap of where the project is going and what it is trying to achieve. This will enable the business context and understand whether they are headed for success or failure.
Iterative Project Management Lifecycle Planning Chapter 5.2 – Second Part: A Layered Approach to Planning and Managing Iterative Projects Modified considerably.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome Introductions What is your experience with RUP What is.
The Software Product Life Cycle. Views of the Software Product Life Cycle Management Software engineering Engineering design Architectural design.
Object-Oriented Analysis and Design Iterative Development and the Unified Process.
Enterprise Architecture 1. What is an Enterprise An “enterprise” is any collection of organizations that has a common set of goals. For example, an enterprise.
Iterative Project Management Chapter 3.2 – The Unified Process Modified considerably by Instructor Class Discussions / Presentations.
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Iterative Project Management Lifecycle Planning Chapter 5 – A Layered Approach to Planning and Managing Iterative Projects Modified considerably by your.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services
Principles of Object Technology Module 1: Principles of Modeling.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Prof. Shrikant M. Harle. The Project Life Cycle refers to a logical sequence of activities to accomplish the project’s goals or objectives. Regardless.
The Challenge of IT- Business Alignment. IT Governance IT governance bridging the gap between corporate expectations and perceptions of the IT function.
Introducing Project Management Update December 2011.
Software Development *Life-Cycle Phases* Compiled by: Dharya Dharya Daisy Daisy
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
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)
Iterative development and The Unified process Chapter 2 Applying UML and Patterns -Craig Larman.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Iterative process planning. Overview Introductory Remarks 10.1 Work breakdown structure 10.2 Planning Guidelines 10.3 The cost & Schedule estimating process.
Software Engineering Management Lecture 1 The Software Process.
Ninth Lecture Hour 8:30 – 9:20 pm, Thursday, September 13 Checkpoints of the Process (from Chapter 9 of Royce’ book)
Project Charters Module 3 1. Project Charter States the scope, objectives and participants in a project Defines the guidelines within which the project.
CS 360 Lecture 3. The software process is a structured set of activities required to develop a software system. Fundamental Assumption: Good software.
Lecture-3 Software Development Life Cycle (SDLC) Thepul Ginige.
Slide 1 Course: e-Governance Project Lifecycle Day 1 Session 3 e-Governance Project Development LifeCycle.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
Chapter 3: The Project Management Process Groups Information Technology Project Management, Fourth Edition.
Rational Unified Process Fundamentals Module 6: Iterative Development Rational Unified Process Fundamentals Module 6: Iterative Development.
Project Management Finals Lesson 1 - Principles - Techniques - Tools.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
Rational Unified Process Fundamentals Module 3: Disciplines I.
Appendix A Project Management: Process, Techniques, and Tools.
Welcome to Session 3 – Project Management Process Overview Instructor:Phyllis Sweeney Instructor: Phyllis Sweeney Project Management Certificate Program.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles Find the right boundaries for your.
1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
Overview of Project management. ◦ Management. ◦ Project Management. ◦ Software Project Management. ◦ Project(Dimensions, Characteristics, Complexity,
Developing an IS/IT Strategy. Session Objectives Understand the process of developing IS/IT Strategic Planning Understand the components of IS/IT.
Object Oriented Analysis and Design Introduction.
1 Chapter – 9 Checkpoints of the process. 2 Introduction The purpose of checkpoint is to achieve The purpose of checkpoint is to achieve The following.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
© 2017 SlidePlayer.com Inc. All rights reserved.