Z26 Project Management Metrics appropriate metrics for iterative projects Lecture 4a Graham Collins, UCL

Slides:



Advertisements
Similar presentations
Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.01 Project Management Review Eclipse Process.
Advertisements

Copyright © , Armstrong Process Group, Inc., and others All rights reserved Made available under EPL v1.01 Project Management Review Eclipse Process.
Armstrong Process Group, Inc. Copyright © , Armstrong Process Group, Inc., and others All rights reserved Armstrong Process.
1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
1 State of Michigan Achieving Software Process Improvement with Capability Maturity Model (CMM)
Improving the R&D/Support Relationship Karen Herzog Vice President, Support Services McKesson SCP Showcase November 10-11, 2004.
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
W5HH Principle As applied to Software Projects
Chapter © 2009 Pearson Education, Inc. Publishing as Prentice Hall.
Chapter © 2009 Pearson Education, Inc. Publishing as Prentice Hall.
Readiness Index – Is your application ready for Production? Jeff Tatelman SQuAD October 2008.
HIT241 - COST MANAGEMENT Introduction
COMP3001 Technology Management & Professional Issues: Project Management Metrics appropriate for iterative projects Lecture 6 Graham Collins, UCL
Developing Metrics for agile projects compatible with CMMI
SA Capstone Requirements and Design Week 10 SYST Winter 2013 Instructors: Jerry Kotuba & Joe Varrasso.
Chapter 3 – Agile Software Development Lecture 2 1Chapter 3 Agile software development.
COMPGZ07 Project Management Presentations Graham Collins, UCL
Software Engineering Chapter 15 Construction Leads to Initial Operational Capability Fall 2001.
Chapter 3 Agile Software Development (2/2) Yonsei University 2 nd Semester, 2013 Sanghyun Park.
Software evolution. Objectives l To explain why change is inevitable if software systems are to remain useful l To discuss software maintenance and maintenance.
RUP Implementation and Testing
Understand Application Lifecycle Management
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Chapter © 2012 Pearson Education, Inc. Publishing as Prentice Hall.
COMP3001 Technology Management & Professional Issues: Project Management Agile and Iterative Planning Lecture 7 Graham Collins, UCL
Software process improvement Framework for SPI SPI support groups, maturity and immaturity models Assessment and gap analysis Education and training Selection.
Chapter 3 – Agile Software Development Lecture 2 1Chapter 3 Agile software development.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 1 Chapter 21 Software Evolution.
K.Ingram 1 Sept 2007 Agile Software Development. K.Ingram 2 Sept 2007 Contents Agile Software Development: 1.What is it? 2.Agile’s Values, Principles,
SOFTWARE METRICS. Software Process Revisited The Software Process has a common process framework containing: u framework activities - for all software.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution 1.
Software Evolution Program evolution dynamics Software maintenance Complexity and Process metrics Evolution processes 1.
Lecture 4 – XP and Agile 17/9/15. Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around.
COMPGZ07 Project Management The Effectiveness of Workshops Graham Collins University College London (UCL)
Project management Topic 7 Controls. What is a control? Decision making activities – Planning – Monitor progress – Compare achievement with plan – Detect.
COMPGZ07 Project Management Life-Cycle Planning Graham Collins, UCL
Agile Metrics It’s Not All That Complicated. © 2011 VersionOne 2 Welcome – About your Trainer, Katia Sullivan VersionOne Product Trainer and Agile Coach.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Software Testing Process
SEPG Conference Amsterdam 2006 Developing Metrics for agile projects compatible with CMMI Graham Collins, UCL Research supported.
Chapter © 2012 Pearson Education, Inc. Publishing as Prentice Hall.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Challenges in Agile Unclear project scope, multiple iterations, minimal documentation, early and frequent testing needs and active stakeholder involvement.
Z26 Project Management Presentations Lecture 5b 9 th February 2006 Graham Collins, UCL.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
Chapter 11 Project Management.
CS 577b: Software Engineering II
Overview Software Maintenance and Evolution Definitions
UCL/APM Principles of Project Management
State of Michigan Achieving Software Process Improvement with
Mike Cohn - Agile Estimating and Planning
Product Backlog List of things that needs to be done to make the product come into existence 
Z26 Project Management The Effectiveness of Workshops Graham Collins University College London (UCL)
Burn Down charts for Project Management
Requirements and the Software Lifecycle
Burn Down charts for Project Management
Teaching slides Chapter 1.
LO3 - Create the Game 2016 Specification - L/615/1355
Chapter 9 – Software Evolution and Maintenance
Process and Project Metrics
Project Management Chapter 11.
Chapter 8 Software Evolution.
Teaching slides Chapter 13
Effective Project Management: Traditional, Agile, Extreme
CHAPTER 14 SETTING A DIRECTION FOR INFORMATION RESOURCES
CHAPTER 14 SETTING A DIRECTION FOR INFORMATION RESOURCES
Presentation transcript:

Z26 Project Management Metrics appropriate metrics for iterative projects Lecture 4a Graham Collins, UCL

Development Metrics (measurements)  Measurements have traditionally included lines of code (LOC) and there are several models based on this including the hierarchy of cost and effort models COCOMO (COnstructive COst MOdel) developed by Boehm  More recently other metrics have been used such as function points, which give a better indication of size and complexity  Recent development work (Bittner and Spence) indicates that a move to working software is perhaps one of the best measures of progress. What is iterative development? Part 3: The management perspective 15 May 2005 www-128.ibm.com/developerworks/rational/library/may05/bittner-spence/index.html

Iterative projects  From the project managers perspective iterative projects can be viewed as a series of self contained projects with the application of all the disciplines of software development (requirement, analysis, design, implementation, and testing) to produce a release of the project  With the Unified Process initial iterations may establish design including architecture. With agile methods emphasis is placed on releases of working software  Bittner and Spence outline this at its simplest as series of stages.

Simplest level (Bittner-Spence) 1. Agree with the team the objectives for the iteration, including evaluation criteria, timescales, and constraints 2. Agree on a plan for how the team will achieve the objectives 3. Execute the plan 4. Assess the achievements of the team against the initial set of objectives and evaluation criteria 5. Assess the impact of the iteration’s results on the project as a whole 6. Start the next iteration.

Fundamental shift in measurement Progress ( % complete measured in scenarios 100% 0% Iteration codedtestedTested & Passed

Developer Perspective  Developers are less interested in the business value, benefits realization and return on investment  They work on a small number of requirements or change requests from their list of outstanding work  They anticipate a decreasing number of requirements and change requests as the product is developed  Outstanding requirements and change requests is termed the product backlog  The developer will therefore be aware of progress via work completed, product backlog and new work allocated.

Rate of work - velocity

Work Remaining

Additional Measures  At different levels, release; defects, total critical, Working as Designed (WAD) iteration; velocity and stories delivered (or as a ‘burndown’ i.e. remaining), and daily; delivered and remaining  The iteration metrics could be developed further to include moving average for velocity, and for stories delivered; planned, delivered, % achieved and moving average. This would give an indication of the average rate of work and also a comparison of planned against delivered each iteration.

Earned Value  EV could be applied to these figures, although measuring this could be considered unnecessarily complex especially if more stories are added as the work progresses (e.g. agile projects).  This however would be useful if the figures have to be shown to senior managers who are used to EV figures, or comparison to other projects where EV figures have been tracked  When additional story points are added to the planned work it does not necessarily affect the original plan in terms of EV or business value (as often the additional work is to ensure adequate functionality). In effect although there may be more story points added the overall business value planned within a specific time frame can remain the same, and depending on how the planned (budget) is calculated, this can also remain as initially calculated.

Business Value  More importantly business value (or contribution) should be considered and evaluated  Often units of measure such as story points can be valued as 0.5 or 1.0 units  The key issue in agile project management is to continually assess with the client the most important work that should be done.

Further reading  Agile Estimating and Planning, Mike Cohn, Prentice Hall (Pearson Education) 2006 ISBN:  Managing Agile Projects, Sanjiv Augustine, Prentice Hall (Pearson Education) 2005 ISBN: