Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 6 down vote favorite
6

I've seen on my work place (a University) most students making the software estimation cost of their final diploma work using COCOMO. My guessing is that this way of estimating costs is somewhat old (COCOMO dates of 1981), hence my question:

How do you estimate costs in your software?

I've seen things like :

Cost = ( HoursOfWork + EstimatedIddle ) * HourlyRate

That's not what I want, I'm looking for a properly (scientifically) defined cost model

EDIT I've found some related questions on SO:

share|improve this question
24  
"How do you estimate costs in your software?" Poorly, just like everyone else. – Rein Henrichs Jun 21 '11 at 19:25
1  
This is in fact, two questions. I suggest you rewrite it as one main question that is not dependent on esoteric software. I doubt you'll get many answers if the requirement is knowledge with Cocomo – Eran Galperin Jun 21 '11 at 19:35
@Eran, I will take your advice and rewrite the question then... – David Conde Jun 21 '11 at 19:49
4  
Steve McConnell is considered a thought leader in this space by a lot of people in IT. You should take a look at his book. stevemcconnell.com/est.htm – Jeff Jun 21 '11 at 20:03
go to Steve McConnell's website -construx.com. – mattnz Jun 22 '11 at 0:42
show 1 more comment

5 Answers

up vote 12 down vote accepted

In case you're stuck in Waterfall Mode, the only fairly accurate method I've used is:

  1. Create a Work Breakdown Structure
  2. Make sure it's detailed enough so you can relate the magnitude of each task to something you (or someone you can talk to) has done before.
  3. For each task, come up with a best-case, probable-case, and worst-case numbers based on experience. Best-case is if everything went perfectly, worst-case is if you had to re-do it over (maybe twice) and probable is somewhere in there.
  4. Use some weighting formula like (1*best + 4*probable + 1*worst)/6 to come up with an estimate for each task that takes the range into account.
  5. I've also seen variants where you can add a "risk" component to each task. The three levels of risk are 0, 1, and 2. A risk of 0 means you've done it before (or something very close), 1 means you haven't done it before, but it's done regularly in your industry, 2 means it's probably never been done before in the industry. You take the risk number and multiply that by an approximation of the "standard deviation" of your estimate. Add that to your weighted estimate. So a risk of 0 doesn't move it, but a risk of 2 moves it fairly close to your worst case number.
  6. Add up all the tasks.
  7. Add a contingency (some %) for "unknown unknowns".

You'll end up with a very precise number. I'm not saying it's accurate, but it'll be precise.

The accuracy depends entirely on being able to come up with a number for each task based on past experience, or to find someone who has done it before. The more experience you have, the better your estimates get.

When you execute the project, track your time against each task, and write down ones you missed, so you can compare. This will make you better over time.

share|improve this answer
Thanks @Scott, I will be recommending something like your idea.. – David Conde Jun 21 '11 at 20:55
Do your estimate this way, then estimate independently a second way (and/or a second person does the estimates). Compare the results. Anything far apart or significantly different to "gut feeling" needs review. My experience (25 years+) is that "gut feeling" is often more accurate than any fancy formula, ignore it at your peril. – mattnz Jun 22 '11 at 0:48
@mattnz - gut feeling has the same caveat: it only works if you have lots of experience. Every customer has a "gut feeling" that it's going to cost a lot less than it does, because they don't understand the amount of work involved in the corner cases. – Scott Whitlock Jun 22 '11 at 11:33
Another tip: "I don't negotiate estimates.<Long pause>" is a very useful phrase in meetings with bosses/customers. After all, does your car mechanic or surgeon do it? He may negotiate the price, he may negotiate what work is done or how it's done, but I have never seen a tradesman for professional in any field other than software negotiate how long a job will take. – mattnz Jun 23 '11 at 0:50
up vote 3 down vote

Software estimation is extremely hard. One approach I've used is to break the requirements down as finely as possible and estimate each piece separately. Then add a "fudge factor" that can either be a multiplier (double it) or a fixed amount (x hours for unanticipated work). If you don't have good requirements estimation is impossible for practical purposes.

share|improve this answer
1  
The most successful estimates I've seen (not including those using sophisticated methods) are ones that roughly doubled the original estimate. – Bernard Dy Jun 21 '11 at 23:05
1  
Yup, double. One of the most politically successful managers I worked for took developer estimates, tripled them, then negotiated with the users down to double. More often than not, the negotiated delivery dates were hit. – DaveE Jun 21 '11 at 23:45
up vote 0 down vote

The industry has learned a lot in the 30 years since '81. Estimating like that never worked. With the Agile craze having basically rewritten the landscape, we use "story points" representing some hazy "comparative difficulty". We then gain "velocity" so that the mucky mucks can do their $$ estimations with some amount of empirical data.

share|improve this answer
up vote 0 down vote

I have learned some "rigorous" approaches such as function point estimates and some variations of it that were designed for modern applications. I think the part of these approaches that is valuable is it does force a more detailed analysis of the known requirements then I might otherwise give it.

Getting a good set of data to work with is very difficult even if you have a good model. Measuring productivity is hard. People game almost any metric.

I have quit using it because my organization is too dysfunctional to benefit from software estimates but I do have some regard for the Cost Xpert group and their tool; but it is very expensive and probably not worth the cost and learning curve for the vast majority of organizations.

share|improve this answer
up vote 0 down vote

It is very difficult to estimate efforts and costs, but if you want something more precise, then:

  • split the HoursOfWork into 3 components:

    1. best estimate,
    2. most likely estimate,
    3. worse estimate.

  • remove EstimatedIddle.

Take a note that anything that takes longer then 8 hours will introduce huge error.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.