# Software cost estimation [closed]

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:

• "How do you estimate costs in your software?" Poorly, just like everyone else. 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 Jun 21 '11 at 19:35
• @Eran, I will take your advice and rewrite the question then... 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. stevemcconnell.com/est.htm
– 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. Jul 17 '15 at 21:13

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

• Thanks @Scott, I will be recommending something like your idea.. 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. 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. 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. 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. Feb 12 '15 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.

• The most successful estimates I've seen (not including those using sophisticated methods) are ones that roughly doubled the original estimate. 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. 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.

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.

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.

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

``````    <ol>
<li>
Primary task 1 - 5 hrs
<ol>
</ol>
</li>
<li>
Primary task 2 - 9 hrs
<ol>