Slashdot Mirror
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!"
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")
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
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.
--
If you train well (i.e. can read a manual and learn, not go DUH), then estimate what it will take to build it then double that number.
Database - About 2 weeks with populated test data.
GUI - About 6 weeks.
Interface to other system - About 6 weeks.
That's 14 weeks, so double it to 28 weeks. Your project will take about 7 months to complete with one developer.
LOAD "SIG",8,1
LOADING...
READY.
RUN
I learned a couple of useful rules of thumb regarding SW project planning. One was told to me by a documentation person who worked for Bolt, Baranek and Newman (sp?) when they were designing the first Arpanet: "Take the estimates from the engineering group, double it and convert to the next higher units." - e.g., if the estimate is five weeks, make it 10 months.
The other is similar, IIRC from a UCLA project: "double it and add six months"
Everyone already knows the "90% rule of software" - the first 90% of the work takes the first 90% of the time; the last 10% of the work takes the second 90% of the time." I would add that the last 1% of the work will take the third 90% of the time. This is very, very true.
Many Open Source projects either demonstrate this or never get the 2nd and 3rd parts done - because these are the parts where the errors in the UI definition are found and fixed, often requiring complete rewrites; and the final tweaking is even harder. Like any art, the closer to perfection you want to get, the more work it is to get there. It takes just as much (or more) time to polish the last eensy bit of shine as it did to rough out the piece.
I have found the following:
1. Larger projects are easier to get right, for two reasons.
a) they must be broken down to smaller units and thus are usually more completely defined.
b) If you're reasonably good at such things, the uncertainty of the estimate on each unit is about even, so while some units go over, others go under. In a large project this can be a wash.
2. In practice, using good large-team software engineering methods, about 1/2 of the total effort expended is in the initial design - which is also where some 80% of the bugs are created and must be found. Only about 10-15% of the effort is in coding, and perhaps 30% in SW QA, which must start in the design phase.
These factors are ignored at your peril. Many programmers are used to conceiving something and cranking out a working rendition overnight. However, turning that piece of basically-running code into something that will robustly handle all possible idiot inputs and attempts at cracking will require triple that time at least.
3. In general, if you can break problems down to a tree of trivial projects, you can thumbnail the estimates for each of those fairly easily. If a piece involves work you're not familiar with, you can ask others who are familiar with that piece and plug it in or further break it down. Units of one to 3 days are about right (or 4-24 hrs.)
4. Making it smooth and glossy so that people actually want to use it will require much more. The original piece of code can only be described as a 'proof of concept'. This is like the difference between a Ford Model T (with hand spark advance) and a recent automobile. There's a lot of engineering between those.
5. Look into "Extreme Programming" - this appears to be a very good way to manage projects the way they really work, though I haven't actually run a project this way.
Having said all this, I've been pretty successful in projects up to about 10 people with myself and about 1.5 additional staff spending a total of (in one example) about a month breaking down a client-server system based on a well-understood set of algorithms to a very detailed project tree, with nodes that amounted to a few person-days a piece. This worked out to a project estimate of six person years. Of course, management screamed, but we got sign-off, and while many things changed due to company problems the parts we were allowed to build according to plan worked out very close to the original estimate. In fact, the parts they tried to short-circuit and ship early were finally fixed in about the original timeframe, with much customer unhappiness in the meantime.
I left the company shortly after.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
Joel Spolsky on "Painless Software Schedules"
Yeah, it's a lot of hard work. Deal with it.
Stupid job ads, weird spam, occasional insight at
First of all, realise that you are asking for a quick-and-easy way to produce information that normally requires several years of solid experience in the relevant industry to estimate with any accuracy. You cannot possibly do this alone if you don't have a background in programming as well.
With that very necessary caveat, here are a few guidelines that might be of use. After discussing the reasoning behind them, I'll come back to address the questions in the original post.
It can take very different amounts of time to get the same work done, depending on a few key variables:
These sound fairly nebulous, but there are some key points in each case that make all the difference.
1. How good is the spec?
First of all, you must have good specifications of the requirements. Start with something written in terms of the problem domain: what data will be in the database and how it will be used, what you want to be able to do with the UI, etc. Then have people who understand both the basics of the problem domain and the details of software development produce specs in software development terms based on your original requirements. Depending on the size of your project, this might be as simple as a database schema or two and a description of what the UI will look like. Around this point, someone experienced will be able to estimate how long the remainder of the project would take a typical team.
If you don't have a good requirements spec up-front, then clearly you won't produce very accurate technical specs from it, and the error in your estimates will be commensurately higher.
2. How much does the spec change during development?
This is a killer. Requirements often will change during the development of a project, either because the client's needs evolve over the lifetime of the work, or because you realise that the original plan was flawed and have to adapt. However, it takes significantly longer to adapt to changing requirements than it does to get it right, at least mostly, up-front. If your requirements are concrete at the start, and the most you're likely to need to change is a few details to adapt to things not working out as you first envisaged, your project will move fairly efficiently. If you constantly change things under your developers' feet (which is common if your original spec wasn't very good, for a start) then you need to double or treble the expected lifetime of the project.
3. How good are your team members?
Individually, a good developer can get an order of magnitude more work done than a mediocre one. If you get several good guys together on your team, and they're also team players and not prima donnas, you can estimate a much faster completion than you would from an average team. Of course, you'll have to pay these people significantly better, but they'll be more than worth it.
Incidentally, when you're forming a team, do get someone technically competent to gauge whether they know what they're talking about. A non-programmer is simply not qualified to do this, no matter how many clever books they've read or how many buzzwords were in their management magazine last week. Screwing this up is a great way to multiply the lifetime of your project by ten.
4. How good is the controlling process?
In a good, lightweight process, working with good people and good specs, you'll find that your team spends around 30-40% of its time planning and designing, a similar amount or a bit longer on testing and putting it all together, perhaps 10% on actually implementing the designs, and a few percent on overheads, mostly communication within the team to keep things organised.
In a bad process, you can ramp those overheads way up, easily wasting 50-75% of your developers' time on unhelpful paperwork and needless communications. Again, it pays to have a good project manager/management team, or to employ someone with good organisation skills if it's a one-person job.
So, there you have it. A good team, working fairly uninterrupted from good requirements specs and with a good co-ordinating process, will probably put together your software 50x faster than a team of poorly-trained code monkeys who are constantly messed around and following a heavyweight process that doesn't respond well to change. Of course, this doesn't really much happen; if you aren't smart enough to use good people and let them get on with their job, your project will join the vast majority: it will fail and be cancelled.
Back to the original questions...
With all of that in mind, it's hard to give specifics without knowing a lot more about your particular job, but I can give you an idea of what a typical, small-scale database application might be like.
UI work often makes up 50% or more of a project. Databases require some careful thought up-front, but tend to be fairly straightforward. Integration with an existing system is a bit of a minefield; as ever, if you've got clear specs to match against (and the existing system actually follows them, which is far from guaranteed!) it's fairly easy, but if you have to work things out for yourself due to lack of accurate information, this can be a big risk.
It sounds as though this project is fairly small scale. Assuming you have average developers, a small database would probably take a man-week or two to design and implement. A UI to provide basic input, searching and reporting functionality for a database of that size probably takes 2-3x as long as making the database itself. If you're only doing a simple transfer of data to another application, that might be done in a matter of days, but if you're talking to a big custom database app using non-standard protocols and detailed interfaces, it could take several weeks.
All in all, you're probably looking at 3-6 man-months to design and implement a typical application of the sort I imagine you're dealing with. Of course, then there are the overheads, particularly up-front requirements capture and the testing and QA time, so overall you're probably looking at 1-2 man-years of development from start to finish. Clearly this has to be a very random figure without a lot more details, but it's about par for the course designing small custom database apps with a decent team and decent tools.
As to your final question about porting: this really depends very much on how different the platforms are. If you know ahead of time that porting is likely to be a requirement, you can invest a little time during development to save a lot of time reengineering things later. Using portable tools and programming languages makes a huge difference here, and having people on the team with experience of the idiosyncrasies of each platform to be used helps a lot, too.
If you've done this well and your project requirements are amenable to porting, you might port successfully in 2-3 man-months. At the other end of the spectrum, sometimes things are so different that it really is faster to rewrite from scratch, though obviously you'll have gained a lot of insight the first time around so you'll generally get the second implementation done significantly faster than the original.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You need to provide more details as to what exactly you are doing.
It's sort of like asking a building contractor, "I want to build a house. You know, a house. With walls, and ceilings, and windows, and don't forget some doors too while you are at it." The specification is so vague that nobody in their right mind will be able to give you an estimate based on that information.
Here is a method that I've seen used for estimating the length of a software project. As you can see, it'll require some amount of work.
1. Come up with a DETAILED design of the project. You won't know how long the project will take if you don't know what the project is. When you say "build a front end", that could mean anything from a single screen with a few buttons and text boxes, to hundreds of screens with graphs and report generators, and all the other bells and whistles.
2. Subdivide the project into a series of smaller tasks. Try and make each task as small as possible. Small uniform tasks are much easier to estimate that a large nebulous one. Don't forget to include non-programming tasks, like testing, integration, documentation writing, status reports, etc, etc.
3. For each task, try and assign a time value to them. If the task is small enough, you should be able to come up with a reasonable value based upon your judgment. If you are having trouble estimating a task, you may need to subdivide the task again into even small pieces.
4. Determine if any of the tasks can be done in parallel. If there are no dependencies between the tasks, then two people can work on them at once.
5. Assign developers to each of the tasks. Allow them to exam the estimates for their assigned tasks, and listen to their feedback! Obviously, if your project has a lot of tasks that can be done in parallel, then having more developers will make the project move faster.
6. Sum up the total time of the subtasks, taking into account tasks that will be worked on in parallel by different developers. This will give you a rough estimate of the completion date. Of course, since this is an estimate, it is likely that it will take longer (or shorter if you are lucky). If that is unsatisfactory to the "powers that be", you will need to cut features or add more developers (but only add developers if things can be done in parallel).
7. As the project moves along and tasks are completed, see if the time it takes for each task matches up with the estimate. If you see that tasks are taking 50% longer than estimated, you should go back to your original task estimates, increase them by 50%, and recalculate a new estimated completion date. Doing this early in the project will prevent the "powers that be" from being surprised when your project isn't shipping by the "ship date".
8. If new features are added at the last minute (which they always are), you will need to add more tasks, and more time estimates to your project. Keep in mind that changes may require revisiting previously completed tasks.
In summary, know what you are going to do, make a first order estimate based upon the tasks, and as the project moves forward, recalibrate you estimate based upon actual data.
Since this is for an MBA project, I'm sure you will be allowed some leeway as long as the method you've used appears reasonable to the professor.
------
www.moneybythenumbers.com