Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

closed as off-topic by durron597, Ixrec, ratchet freak, Snowman, Kilian Foth Jul 22 at 8:25

  • This question does not appear to be about software development within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

"How do you estimate costs in your software?" Poorly, just like everyone else. –  Rein Henrichs Jun 21 '11 at 19:25
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
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. –  Jeff Jun 21 '11 at 20:03
I'm voting to close this question as off-topic because it is not about a conceptual programming problem within the scope defined in the help center. –  durron597 Jul 17 at 21:13

6 Answers 6

up vote 15 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
@mattnz - I negotiated with a car mechanic last week about how long it would take to repair my car door depending on how it was done. –  sixtyfootersdude Feb 12 at 22:46

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
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
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

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

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

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

What we normally do is dividing full work scope into major modules / elements which could be considered as sub-project. In other words they are those work parts which client consider as separate parts of the project and which client wants to get estimated separately.

Once it is done we divide each module into tasks, sub-tasks and even smaller sub-sub-tasks so that each one can be estimated quite easy and the estimation take from one to ten man-hours. That way we get detailed breakdown of work scope for the project.

Last step is distributing tasks between milestones. We do it the way so that after each milestone client gets visible results. That helps to pass one milestone and move to another one. So finally we get something like:

Module 1

            Primary task 1 - 5 hrs
                <li>Subtask 1.1 – 3 hrs</li>
                <li>Subtask 1.2 – 2 hrs</li>
            Primary task 2 - 9 hrs
                <li>Subtask 2.1 – 1 hrs</li>
                <li>Subtask 2.2 – 2 hrs</li>
                 <li>Subtask 2.2 – 5 hrs</li>

Initially we did it just using excel sheet. But more than two years ago we started to use software tool for that. There are few similar products which helps with it, and a few others. I don't remember all list. We did research long time ago. Hope that may help.

Good question is how to estimate precisely. There is no 100% correct estimation as we believe. The only way is to divide full work scope into as small tasks as possible. The smaller tasks you have the more detailed review and analysis of the project you do. So that anyway increases accuracy.

share|improve this answer

protected by gnat Feb 17 at 21:39

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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