Software cost estimation

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:

"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. http://www.stevemcconnell.com/est.htm — Jeff, Jun 21 '11 at 20:03
BTW, what is "EstimatedIddle" and how do I get paid for it? ;) — Scott Whitlock, Jun 22 '11 at 00:43
The human species is not good at management. Nuclear reactors building, financial projects, etc... is not managed better than software building. Read [the mythical man month](http://en.wikipedia.org/wiki/The_Mythical_Man-Month) — Basile Starynkevitch, Feb 12 '15 at 17:27
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/on-topic]. — durron597, Jul 17 '15 at 21:13
I disagree this is a question of algorithm of an effort estimation http://specialmeaning.blogspot.com/2016/10/coding-effort-measurement.html As it is a question about an software development algorithm/formula this might not be treated as off-topic. I suggest to edit the question or move it to better matching society but not closing it anyway. Closing a topic which requires some expertise is not a good way. Experience sharing must stay, but you can move it to other stack exchange resource. — Sergei Krivonos, Nov 12 '16 at 10:48

score 16 · Accepted Answer · answered Jun 21 '11 at 20:11

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

Create a Work Breakdown Structure
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.
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.
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.
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.
Add up all the tasks.
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.. — 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 00: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." 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 00: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 '15 at 22:46
Exactly my point - you negotiated how he was going to do it and (presumably) accepted his estimate for that. You did not negotiate the estimate. — mattnz, Feb 12 '15 at 23:12

score 3 · Answer 2 · answered Jun 21 '11 at 20:06

3

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.

answered Jun 21 '11 at 20:06

Mark B

751
4
3

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

Nick Rogozhnikov · Answer 3 · 2015-02-12T17:54:21.963

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.

score 0 · Answer 4 · answered Jun 21 '11 at 20:10

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.

score 0 · Answer 5 · edited Jun 21 '11 at 21:28

0

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.

edited Jun 21 '11 at 21:28

Arseni Mourzenko

134,780
31
343
513

answered Jun 21 '11 at 20:13

BЈовић

13,981
8
61
81

score 0 · Answer 6 · answered Jun 21 '11 at 20:17

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.

Software cost estimation

6 Answers6

Module 1