X hits on this document

PDF document






2 / 7


Determining the scope of a proposed system is one of the most challenging aspects of any software estimate. Size estimation is often perceived to be a difficult and thankless job, so it’s hardly surprising that so many project managers forgo size estimates and rely instead on level of effort or task based estimation. This is unfortunate because decades of empirical data show a strong correlation between the delivered size of a software project and its final schedule, effort, and quality.

Size isn’t of interest only to estimators. Software estimation, productivity measurement, and benchmarking all rely on the same well established set of software metrics. For decades these core measures - size, time, effort, and defects - have been used to support a broad range of management decisions. Organizations measure their projects to better predict and control the costs (in time, effort, and money) associated with various management tradeoffs but there are also dramatic quality consequences associated with compressing schedules and piling on staff to meet market deadlines.

In a very real sense a project’s effort outlay, schedule, and reliability depend upon assigning the right resources to the project before it begins missing deadlines. But how can managers plan efficiently if they don’t know how much work is needed to translate a given set of requirements into executable code? It is tempting to think of software development work in terms of the effort or resources applied to the project but this formula puts the cart before the horse. From an estimation perspective, effort (or staff over time) is an output. It can help predict how much the project will cost, but not the amount of work needed to implement the requirements or the speed with which those requirements can be converted to software.

This is why measuring project size is so important.

Without a notion of functional size, it is difficult to negotiate realistic schedules based on an organization’s proven ability to deliver software. Over three decades of collecting and analyzing completed software projects have shown us that most software metrics increase exponentially as the volume of delivered functionality grows. With a little history (and the ability to place an estimate in the correct size regime) managers can empirically show how unlikely it is that the team that delivered a 150,000 ESLOC project over six months will deliver half the functionality in half the time. The data makes their argument for them.

Unlike manufacturing shoes, software development is full of non-linear relationships. Data driven estimation allows managers to sanity check current plans against past performance and negotiate achievable outcomes

© Copyright 2011 Quantitative Software Management. Inc. All Rights Reserved.


Document info
Document views13
Page views13
Page last viewedTue Oct 25 15:39:46 UTC 2016