Hi,
I am new to software project time estimation.
I have learned that people are using some techniques such as ‘Function point analysis’ , ‘Cocomo model’ etc.
Can you tell me the some of the latest and best techniques? Also would you please let me know some good tutorial links for these models so that I could go through them and understand?
Many Thanks,
Regards.
Anusha.
You should check out the book Software Estimation by Steve McConnell. If you poke around on the Construx site (his company), you can find a place where he gives free talks about on the subject.
The book Thomas suggests also is really good (Rapid Development).
Agile processes use the concept of velocity.
Other processes use the Hofstadter's law.
The place to begin with is Three Point Estimation. If you find the math on that article confusing, have a look at this article with a nice chart showing the three points on a graph. If you are working with small projects, not much longer than 6 months in duration, with small teams or in a small company, then you may never need anything more sophisticated than this.
Function Point Analysis, on the other hand, is a very heavy duty technique intended for specialists who dedicate themselves to estimating. In other words, it is a career in itself.
There is no "latest and best" technique; if you can, use several different methods and compare.
As a primer, I suggest to you chapter 28.3 of "Code Complete", 2nd edition - "Estimating a construction schedule".
The major techniques of estimation listed are:
One of the most important tips that come out from agile methods is estimating at low level of detail. When the tasks are a few hours long, you can accurately estimate the job by adding the small, clear tasks together. When you have a single estimate of "6 to 8 weeks" for the entire project...
well, we know what happens then :)
And remember the 80/20 rule: The most difficult 20% of the project will take 80% of the scheduled time, and the remaining 80% of the project will take the other 80% of the scheduled time.
I've tried many formal techniques, but what I always come back to is: Break the project down into a list of modules that you will actually have to write or modify. Look at the number of different screens, the number of reports, and any particularly complex logic that will have to be developed. Then guess how long it will take to write each of these individual pieces and add them up.
Yes, at the low level you're still just making up a number, but if you have any experience you should be able to come up with a fairly good estimate for "write a screen to input customer name and address type information and write it to the database". That's something manageable. Trying to estimate "write a payroll system" with no breakdown is much more difficult.
This is essentially the idea of function point analysis. If using the formulas of function point analysis helps you, go ahead. I find it easier to just wing it when I get to the lowest level.
Don't estimate based on the assumption that the first draft of the code will always work perfectly the first time. You know that never happens except for the most trivial programs, but people always seem to estimate based on that assumption. Build in time for finding and fixing bugs. Take it for granted that there will be some number of particular nasty bugs that take a long time to figure out.
Include time for testing. And -- here's where I used to fall down all the time -- include time for fixing the bugs that are found during testing, and then for another round of testing after the fixes. I used to do estimates where I said "2 weeks for testing" or whatever, estimating how much time it would take the test group to get through the system, and then left it at that. That was dumb. Of course the test group will find problems, and you will have to fix them.
(Side note: I used to have a chief tester who would set a goal for each new release of our product that he would find 100 bugs. He saw this as a personal challenge. Sometimes he had to stretch the definition of a bug to make it, like counting a mis-spelled label on a screen as a "bug", but he almost always made it. That's the best kind of tester you can have. I've often had to explain to testers that the goal of testing is not to prove that there are no bugs, but to find the bugs that are surely there.)
Depending on just what portion of the project you're supposed to be estimating and how your organization works, you may also need to plan for "clarifications" to the requirements and more changes when the users see the program in operation. Yes yes, we always say that the requirements must be nailed down before we start coding and once the user signs off no changes will be allowed. I have never worked for an organization where it actually happened this way. No matter what policy is written on a piece of paper, in real life the users always find that even if you implemented exactly what they asked for, when they see it in practice it doesn't really work out, and so there will be further changes and rework.
Going a different direction, I would recommend that you read a fairly short article by Joel on Painless Software Scheduling. I recommend this article for these reasons:
Here's an example of a useful snippet:
As a rule of thumb, each task should be from 2 to 16 hours. If you have a 40 hour (one week) task on your schedule, you're not breaking it down enough.
Coupled with the requirement of engineer's estimates, you have the fundamental roots of a sensible scheduling process.
Only the programmer who is going to do the work can figure out what steps they will need to take to implement that feature. And only the programmer can estimate how long each one will take.
Admittedly, he has this quote at the very top of the article. Even taking his caveat into account, I really think that you should read the old schedule first. I use evidence-based scheduling all the time (in FogBugz) but I don't think the second article is as accessible as the older one.
This article is obsolete.
Over the years, I've learned a lot more about schedules and estimates. A newer, far better method for producing accurate software schedules painlessly is Evidence-Based Scheduling. Read that instead.
This article remains here for archival purposes, but please don't read it!
Don't listen to Joel! It's still worth reading!
EDIT: following-up on Jay's comments below
Why 2-16 hours? These numbers exist because the OP is the target customer for this sort of information: they're asking for useful specific guidelines. A two hour estimate minimum is useful because it forces you to think about your work day in terms of beginning, middle and end (and epilogue if you managed to fit in another two hour task). Any less than that is likely too fine-grained: if you're trying to decide whether a task will take 15 minutes vs. 20 minutes, you're just going to become frustrated and annoyed. 16 hours is a nice number also because it forces you to say, "if there's a task that's going to take me more than two days, it's really more than one task that I need to break into component parts."
Isn't the probability distribution used in EBS useless? I use Fogbugz and use EBS reports in at least two distinct ways on a regular basis:
Determining whether we on schedule and, if not, who needs some help (due to schedule conflicts, swine flu, and all the other realities of work life)?
Reporting to project management on a high level that we are / are not on time, using the probability distribution to answer the immediate question of "how do you know?" The tool automatically calculates a 5%, 50% and 95% probability dates of completion based on everyone's individual estimation histories.
Almost no-one ever actual wants to see the data behind the dates now but, having beaten that argument to death several times, management actually believes me when I report estimates to complete.
I want to suggest a few time-consuming areas often ignored when breaking down strict requirements but always come into play during implementation. Especially be aware of these if you're contracting and every hour is your own. You'll be surprised at how often employers count these hours against development time because they are piecemeal tasks and expected in due course of the project - of course these things add up. I suggest allocating time for these - and explicitly outline them as such in your estimation process so there is no confusion:
These are truly parts of real-world software project estimation. There are more gotchas but this might help provide some direction about kinds of things to pragmatically consider outside an ideal or academic process. I think a lot of text books give sound advice; one book I fondly remember is Clouds to Code (for the sake of throwing out a link).
In my experience full-time employees don't necessarily have to be as concerned because organizations tend to absorb salaried time outside strict project timelines as a cost of doing business.
In Lean/Kanban, estimation may be greatly reduced or even eliminated.
See 5 Right Reasons to Apply Kanban and Kanban & Planning and Estimation.
Software development time estimates should also factor in your team's capability and the organization's internal processes.
I don't find it useful to come up with estimates in an ideal environment. Actually, because this is very much "organization-dependent", whatever formal model you use, I would double check that model with that company's project delivery history.
Best, D
Golden Principle for Software Estimation:
It always takes longer than you expect, even when you take into account Hofstadter's Law.