Iterative Project Management 1

Similar documents
Program Lifecycle Methodology Version 1.7

Supporting Workflow Overview. CSC532 Fall06

Software Project Management using an Iterative Lifecycle Model

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Managing Small Software Projects - An Integrated Guide Based on PMBOK, RUP, and CMMI

Basic Unified Process: A Process for Small and Agile Projects

RUP for Software Development Projects

How To Adopt Rup In Your Project

Software Development Methodologies

A Rational Development Process

Plan-Driven Methodologies

Improving Software Development Economics Part II: Reducing Software Product Complexity and Improving Software Processes

Reaching CMM Levels 2 and 3 with the Rational Unified Process

Time Monitoring Tool Software Development Plan. Version <1.1>

Lecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction

Open Group SOA Governance. San Diego 2009

Custom Software Development Approach

Software Development Life Cycle (SDLC)

Planning a Project with the Rational Unified Process Author: David West

The Unified Software Development Process

The Rap on RUP : An Introduction to the Rational Unified Process

Appendix 2-A. Application and System Development Requirements

Classical Software Life Cycle Models

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK

Roles: Scrum Master & Project Manager

Best Practices Statement Project Management. Best Practices for Managing State Information Technology Projects

TDWI strives to provide course books that are content-rich and that serve as useful reference documents after a class has ended.

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

PASTA Abstract. Process for Attack S imulation & Threat Assessment Abstract. VerSprite, LLC Copyright 2013

Introduction to OpenUP (Open Unified Process)

AGILE SOFTWARE TESTING

Project Management in the Rational Unified Process

IV. Software Lifecycles

LDAP Authentication Configuration Appendix

Unit 1 Learning Objectives

PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME >

HKITPC Competency Definition

3.1 Overview of Software Development and Integration Activities

Lowering business costs: Mitigating risk in the software delivery lifecycle

Oracle Unified Method (OUM)

Fundamentals of Measurements

11 Tips to make the requirements definition process more effective and results more usable

RUP Deployment. RUP Deployment Workflow RUP Deployment Artifacts & Deliverables

SWEBOK Certification Program. Software Engineering Management

The IconProcess: A Web Development Process Based on RUP

Getting Started with SmartBPM

Draft Document STATE OF MICHIGAN. SACWIS Planning Department of Human Services Strategic Implementation Plan: Project Staffing

Chap 1. Introduction to Software Architecture

The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision of resources to support service requirements.

How To Understand The Business Analysis Lifecycle

<name of project> Software Project Management Plan

Application Test Management and Quality Assurance

A Practical Guide to Agile BPM Implementation

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.)

Cisco Unified Communications and Collaboration technology is changing the way we go about the business of the University.

3C05: Unified Software Development Process

Smarter Balanced Assessment Consortium. Recommendation

Scaling Down Large Projects to Meet the Agile Sweet Spot

(Refer Slide Time: 01:52)

VAIL-Plant Asset Integrity Management System. Software Development Process

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Develop Project Charter. Develop Project Management Plan

What is a life cycle model?

Software Engineering. Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti

SOFTWARE PROJECT MANAGEMENT

A Model for Effective Asset Re-use in Software Projects

To introduce software process models To describe three generic process models and when they may be used

Begin Your BI Journey

Enterprise Architecture Assessment Guide

EMA CMDB Assessment Service

Development Methodologies

Using the Agile Methodology to Mitigate the Risks of Highly Adaptive Projects

ESTABLISHING A MEASUREMENT PROGRAM

Project Management and Scrum A Side by Side Comparison by Anne Loeser, October 2006

Practice Overview. REQUIREMENTS DEFINITION Issue Date: <mm/dd/yyyy> Revision Date: <mm/dd/yyyy>

Development, Acquisition, Implementation, and Maintenance of Application Systems

ASSURING SOFTWARE QUALITY USING VISUAL STUDIO 2010

How To Model Software Development Life Cycle Models

PROJECT MANAGEMENT ROADMAP, Executive Summary

Project Management Guidelines

Requirements Definition and Management Processes

Managing Successful Software Development Projects Mike Thibado 12/28/05

Presented By: Leah R. Smith, PMP. Ju ly, 2 011

Enterprise Project and Portfolio Management Implementation Project. Update to the ETS Customer Utility Board Julie Pearson May 27, 2015

Project estimation with Use Case Points using Enterprise Architect (EA)

Draft Requirements Management Plan

UDC Software Development Life Cycle

Essentials of the Quality Assurance Practice Principles of Testing Test Documentation Techniques. Target Audience: Prerequisites:

Netspective Software Development Process

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

Transcription:

Iterative Project Management Module 2 Objectives Understand issues for Project Managers (PM) who use iterative development by: Learning how the PM monitors and steers an iterative project towards success. Understanding the importance of the following in iterative development: Confronting risk early. Using an architecture-first approach. Using objective quality control and progress assessment. Learning the importance of the principal artifacts used by PM. Understanding how team responsibilities change. Team Leadership The following are the main elements of team leadership: The team framework: putting in place the appropriate roles, staff assignments, tools, and processes The big picture: seeing that the effort continues to meet the business needs, and that it has the correct contents, schedule, and budget Team dynamics: making sure that the project team and individuals are communicating effectively Iterative Project Management 1

Review: Project Navigation Business-Oriented Goals Achieved START I-end E-end C-end T-end Technically-Oriented Goals Achieved Coarse-Grained Versus Fine-Grained Plans Project Plan Phase Plan Iteration Plan (current) Phases and major milestones What and when Iterations for each phase Number of iterations Objectives Duration Work Breakdown Structure Iteration Plan (next) Roadmap Coarse-grained Plan Fine-grained Plans Work Breakdown Structure Issues Common Flaws Prematurely structured around product design Prematurely broken down into too much or too little detail Structured in a projectspecific way that impedes cross-project comparisons Solutions Organize around the process Evolve detail over time Remain consistent in form across enterprise Iterative Project Management 2

Review: RUP Effort and Time Distribution by Phase Inception Elaboration Construction Transition Effort 5% 20% 65% 10% Time/Schedule 10% 30% 50% 10% This distribution is typical for new software projects Iteration Assessment and Steering Start Iteration Using Iteration Plan Complete Planned Iteration Work Artifact: Iteration Assessment Assess Iteration Continue Adjust Objectives Stop Adjust Target Product Project Stopped Reduce risk Accept change Adjust Remaining Plan Plan Next Iteration Steer project Start Next Iteration Artifact: Iteration Plan Discussion: Iteration Assessment What types of information are needed to assess an iteration correctly? Under what conditions might you be required to adjust: Your project objectives? Your target product? Iterative Project Management 3

Risk Recommendations Iterative development recommends that you: Create a risk list, order it by risk magnitude, and update it as the project progresses Mitigate the highest magnitude risks as early as possible Exiting Elaboration requires that highest (technical or otherwise) risks have been mitigated. Software Architecture Software architecture defines the infrastructure, control, and data interfaces that permit: Software components to cooperate as a system Software designers to cooperate efficiently as a team It is the most critical technical product of a software project. It encompasses the set of significant decisions about the organization of a software system. It maps the problem to a solution without violating constraints. It requires innovation and cannot be automated. Software Architecture (Cont.) Software Architecture is the basis for decisions relating to: Make/buy decisions Component reuse Intellectual control Manage complexity Maintain integrity Project management Planning, Staffing, Delivery Iterative Project Management 4

Architecture As a Basis for Project Management A stable architecture represents a significant project milestone. Poor architecture is often a reason for project failure. Architecture is a prerequisite for predictable planning. Architecture is the source of numerous high-payoff / high-risk decisions. Measurements in a Software Development Project Measurements provide the development and management teams with: An assessment of progress to date Insight into the quality of the evolving software product A basis for estimating the cost and schedule for completing the product with increasing accuracy over time Two perspectives: Point values Trends of values Use of Measurements in Iterations Start Iteration Using Iteration Plan Complete Planned Iteration Work Measurements Assess Iteration Stop Continue Project Stopped Adjust Objectives Adjust Target Product Adjust Remaining Plan Plan Next Iteration Measurements are used to assess iterations. Start Next Iteration Iterative Project Management 5

Seven Core Metrics: Management METRIC Work and progress Budgeted cost and expenditures Change traffic and stability Breakage and modularity Rework and adaptability MTBF and maturity Staffing and team dynamics PURPOSE Iteration planning, plans versus actuals, management indicator Financial insight, plan versus actuals, management indicator Iteration planning, management indicator of schedule convergence Convergence, software scrap, quality indicator Convergence, software rework, quality indicator Test coverage/adequacy, robustness for use, quality indicator Resource plan versus actuals, hiring rate, attrition rate Measurement Recommendations Iterative development recommends: Measuring the progress and quality of software products throughout the development lifecycle Extracting information from evolving artifacts, since these are the most useful measurements Using objective analysis and automated data collection, since these are crucial to the success of any measurement program Discussion: Measurements Which measurements would you consider essential to iterative development in your environment? Can you think of any other measurement that your organization MUST have in addition to this core set? What is it and why? In your last project, how did you adjust (or should you have adjusted) your objectives? What kind of measurement do you need to adjust your objectives? Iterative Project Management 6

Work Products A work product is an abstract concept that provides a generalization for the concrete work product types Artifact, Outcome, and Deliverable. A work product is: Produced, modified, or used by a task The responsibility of a single role, but can be modified or used by others Likely to be subject to configuration control Iteration Plan Storyboard Use Case Model Project Measurements Iteration Developer Assessment Test Analysis Model Business Goal Architectural Proof-of-Concept Test Environment Configuration Workspace Artifact-type work products may contain other artifacts User-Interface Prototype Tools Business Use Case Model Artifacts An artifact is a work product that represents a piece of information that is produced, modified, or used by a process Artifacts can be of type: Model created using modeling tools, from where we can automatically create reports Use Case Model Document created using word processors Iteration Plan Generic Artifact Lifecycles Evolving Minor Changes Expected Example: Vision Example: Development Case Evolving Major Changes Expected Example: Requirements Model Snap-shot Newly created for each iteration Example: Iteration Plan Iterative Project Management 7

Artifacts and their Uses Artifacts provide: Permanent documentation of a system s structure and behavior, such as: Reference manuals, user guides, and architecture description Used by end-users, maintainers, and re-users The goal is to minimize the creation of artifacts. Transitory documentation of the development process, such as: Internal design documentation Status assessments Defect reports How Much Documentation is Enough? A successful project provides documentation sufficient for: Shared Vision Communicate overall vision of project Risk reduction Promote a dialog between stakeholders and developers Points of control for management Make decisions and progress explicit and tangible Conceptual integrity of the architecture Capture and communicate the vision of the software architect/team Sample Artifacts Contrasting Small Approaches Commercial Product to Artifact Development Business Case Short memo and spreadsheet Large System Development Full scope proposal Vision Brief concept paper 20-page paper with GUI prototype Software Development Plan Iteration Plan Software Architecture Document Iteration Assessment Deployment Plan 10 page overall plan Kickoff meeting 5 slide presentation Release Notes Online help, Sales rollout, and marketing collateral Development plan, CM Plan, QA Plan, and so on Detailed scenarios, quality targets, performance benchmarks, and so on 120 page document In-depth analysis of test results, measurement results, demos, and so on Online help and tutorials, user manual, training course, phased cut-over plan, advertising campaign Iterative Project Management 8

Essential Project Management Artifacts Software Development Plan Business Case Deployment Plan Risk List Issues List Review Record Iteration Plan/ Iteration Assessment Status Assessment Essential Mgt. Artifact: Software Development Plan The Software Development Plan includes the following information: Project Overview Project Organization Management Process Project Estimates Project Plan Iteration Plans Project Monitoring and Control Technical and Supporting Process Plans Important for gathering all information necessary to control the project, and for directing the development effort. Essential Mgt. Artifact: Iteration Plan The Iteration Plan includes the following information: Task-level Plan Resources Use Cases Evaluation Criteria It is important for: The project manager, to plan the iteration tasks and activities, to schedule resource needs, and to track progress against the schedule Project team members, to understand what they need to do, when they need to do it, and what other activities they are dependent upon Iterative Project Management 9

Iteration Plan Example Shows timeframes and resources by discipline Outline of an Iteration Plan Iteration Schedule section for Requirements discipline Essential Mgt. Artifact: Iteration Assessment The Iteration Assessment includes the following information: Iteration Objectives reached Adherence to Plan Use Cases implemented Results relative to Evaluation Criteria Test Results External Changes Rework required It is important for the development organization to reflect on what has happened, what was achieved (or not) and why, and the lessons learned from the iteration. Phase Schedule Staff Team Scheduling and Staffing Inception Elaboration If the project will last about one year, this phase will last about one month. If the project will last about one year, this phase will last about two to four months. A small team including: The project manager The system/software architect A member of the test team Several developers who will continue on the project A small team including: The project manager The software architect A small team of designers and developers A small test team One to two domain experts or end-users Tool specialists Iterative Project Management 10

Team Scheduling and Staffing (Continued) PHASE SCHEDULE STAFF Construction Transition If the project will last about one year, this phase will last about five to six months. For a modest size project, plan for a new release every 2 to 3 months. For a more complex project, every 6 to 9 months. Varies greatly depending on how the end of the phase is defined. If customer acceptance marks the end of transition, then for a one year project, the transition phase should not last more than one month. If the end of product life marks the end of transition, the transition phase may last much longer. Staffing reaches its peak. 80% of the team should be directly contributing to the release. The remaining 20% are performing tasks that address new risks and prepare the ground work for next releases. The software manager The software architect (part-time) A small team of developers and testers Technical support personnel A technical writer (to update documentation) Marketing, manufacturing, trainers, and other support personnel RUP Distribution of Skills by Phase Table shows percentage of effort by activity for each phase. Inception % Elaboration % Construction % Transition % Management 14 12 10 14 Environment/CM 10 8 5 5 Requirements 38 18 8 4 Design 19 36 16 4 Implementation 8 13 34 19 Assessment 8 10 24 24 Deployment 3 3 3 30 Total 100 100 100 100 Iterative Project Management Issues Overly detailed planning up to the end Detailed plans outdate quickly Incorporate precision commensurate with knowledge of current activities Progress based upon completion of artifacts Artifacts are poor predictors of project completion Concentrate on code completion instead Too many iterations A build is not an iteration release Keep iteration durations to a minimum of about 1-2 months Iterative Project Management 11

Iterative Project Management Issues Change in responsibilities and perspective of team members and clients Analysts Developers Testers Project Manager Quality Assurance and Method Expert Client Iterative Project Management 12