Chapter 2
Comparison-Based Estimation

It’s always a conundrum when you face a new project and want to know how long it will take and how many people are needed to accomplish it. There are so many variables and so little is known with any certainty. It’s tempting to throw up our hands and declare, “There’s no way of knowing!” As we saw in Chapter 1, Starting Something New, there are often good business reasons for estimating a new project.

What’s a pragmatic way to meet those business needs? There are two ways to estimate something. One way is to build a computational model to calculate the estimate based on things we know or that we can more easily estimate. We’ll look at that method in Chapter 5, Model-Based Estimation. The simpler way of estimating, especially when starting something new, is by comparison, i.e., comparing the things we want to know about to the things we already know.

Comparison-based estimation is such an ordinary part of our lives that we often don’t notice when we do it.

Everyday Estimation

Let’s see. My train is at 1:13 p.m., and the last time I went to the train station, it took about 30 minutes to get there. I think I’ll allow for double that. I really don’t want to miss that train.

Notice how this estimation process is modeled as a multiplicative factor applied to a known past experience. In this case, the factor is designed to cover any natural variability and give a buffer for safety. See Multiplicative and Additive Adjustments) for more discussion of simple multipliers and additions to account for possible variances between the current situation and past experience.

Everyday Estimation---Another Take

Let’s see. My train is at 1:13 p.m., and the last time I went to the train station, it took about 30 minutes to get there. I was being dropped off that time and I’m driving myself this time. Maybe I’d better allow 10 or 15 minutes to park the car and walk down from the parking garage. The last time I took the train, it was midafternoon. Today, it’s lunchtime, so traffic might be heavy. Let’s make it an hour, in total. I really don’t want to miss that train.

Here we’ve started to build a mental model of what makes up the variances. We’ve specifically allowed additional time to park the car and walk down to the station. We’ve cataloged another possible variance, traffic delays, but we haven’t quantified them. In the end, we fell back to a comparison-based estimate and allowed for a lump variance. Itemizing the elements of that variance may have helped us choose an appropriate factor, but we didn’t build an explicit model.

Magne Jørgensen, in Expert Estimation of Software Development Work: Learning through Feedback [JS06], states, “Several empirical studies report that expert estimation of software development and maintenance effort is the dominant estimation approach. We were not able to find a single study that reported a dominance of model-based effort estimation.” I think most people tend to minimize the use of math when they can get away with it. This promotes the use of simple comparisons or comparisons with simple mathematical adjustments. As we’ll see in Chapter 5, Model-Based Estimation, model-based estimation has a component of comparison, too. It’s just quantified so mathematical manipulations can be performed. Clearly, comparison-based and model-based estimation are not completely distinct. It’s a matter of where you put the effort. Building a mathematical model you can trust can take considerable effort, so let’s start with the easy approach.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.177.133