Estimating Software Development Costs?

Stu Lalison asks: "I'm an MBA student (but I'm not evil, I promise!) and am working on a business plan that involves having some custom software written for a handheld computer. I've done some research into estimating the costs involved in software production, but when estimating the time involved in writing the software, it usually says 'judge on past projects.' I'm not a programmer, so I don't have any past projects to judge on. I'm wondering if the Slashdot community can give me some ballpark figures on how long it takes a professional programmer to code different parts of a program. I've identified 3 needs of my application: a front-end user interface, a database w/ search function (of about 10 megabytes of data), and integration of both of these into a (currently existing) commercial mapping application. It seems like these aren't huge tasks, but getting (even a rough) handle on their actual complexity will help me greatly. Also, how much development time would be required to port an application like this from, say, a Palm OS device to a 3G handset? Thanks in advance!"

Comments

This is why we don't like MBAs.

[Lauritz]

Read "The Mythical Man-Month" by Fred Brooks. It's short, you can read it in a day/couple of days.

And no, we do not think that MBAs are evil. They are just illinformed about what programmers do, and still like to take the dissisions that programmers should take. As you've just demonstrated. (No, asking slashdot, giving so little information that it is a joke, is not "letting the programmers deside")

Expertise

[Koos Baster]

I've identified 3 needs of my application: a front-end user interface, a database w/ search function (of about 10 megabytes of data), and integration of both of these into a (currently existing) commercial mapping application.

Obviously, your descriptions lacks details to make even a vague estimate of costs. So here are some general guidelines and things to consider.

If the 3 needs you specify are filled in independently, your project is bound to fail. That is: if front-end and database are built independently, the integration need is bound to be the most expensive. Only way to reduce integration costs is having a damn good specification of what you're looking for and some damn good project manager with a damn good team of coders, that can cooperate. (That, or a one-man-team that's proven to be up to the job.)

Porting efforts tend to depend on the size of the code base, and the ability to find a skilled porter. To a lesser extent it also depends on quality of the code and documentation. But I'd say size is the major issue here, keep things small.

Well, anyway. My advice would be: get someone that can give a good estimate, 'judged on past projects.' If that's not possible or not satisfactory, just determine market value, based on offers of different (sub-)contractors.

Oh. And there is no such thing as a scientific formal analysis that yields code size/cost/time based on a problem description. Nothing in software engineering (or elsewhere) has an accuracy that's within a factor 5, so consider these techniques useless. If you don't have the expertise, go look for people that have.

--
The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in: we're computer professionals, we cause accidents -- Nathaniel Borenstein

Quick guidelines

[/dev/niall]

1) You need a detailed functional specification. Just what the application should do, not how or with what technologies.

2) You need a detailed implementation specification, which should probably be written by someone with technical experience and at least some knowledge of the application's intended use. The person(s) who write this should be able to estimate how long it will take to complete.

3) You need to double the amount of time the folks from #2 give you as an estimate. If you didn't spend a lot of effort on #1, you should probably triple the estimate as you will be adding features that will render most of #2 obsolete.

Re:Quick guidelines

[oliverthered]

Ok, you can improve on that.
1: Against each element assign a Risk.
2: Using the risks and the estimates and calculate the 95 percentile for a normal probability and quote this.

I can't remember the maths at hte moment (it's been a while). but something like

A takes 2 weeks, 1.5 with a fair wind and 4 if where in the shit.
B takes etc......

plug the numbers in and you get a probability curve for when the work will be done by.

Pick the 95% change of getting the work done and use that.

Here's one (meta-) answer

[Lumpish Scholar]

Joel Spolsky on "Painless Software Schedules"

Yeah, it's a lot of hard work. Deal with it.

Re:Rough Estimation

[Bitsy Boffin]

I hope the poster doesn't take your answer seriously. There is nowhere near enough information given to make ANY sort of judgement on how long it is going to take to do anything let alone finish it. We don't even know what the system is supposed to DO (asides probably something to do with mapping).

How do you know what the system you are interfacing with looks like, what protocols you're going to have to use, maybe you have to invent them, maybe you're gonna have to figure out some communication method between them.

Perhaps there is a framework for buiulding the GUI already there meaning programming takes 2 weeks, or maybe you have to do everything from scratch and programming is going to take a year.

As for the database, you don't know anything about the data - can't even begin to imagine where you got 2 weeks from.