Software cost estimation [closed]

Question

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:

• What are some of the software cost estimation methods and models?
• How do you estimate the cost of developing software requirements?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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>
                <li>Subtask 1.1 – 3 hrs</li>
                <li>Subtask 1.2 – 2 hrs</li>
            </ol>
        </li>
        <li>
            Primary task 2 - 9 hrs
            <ol>
                <li>Subtask 2.1 – 1 hrs</li>
                <li>Subtask 2.2 – 2 hrs</li>
                 <li>Subtask 2.2 – 5 hrs</li>
            </ol>

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 www.evenflow.com, www.swproposal.com 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.