Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Software Project Estimation

 
Ajit Wadekar
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I don't know where to put this so I am putting my post here. I want to know more about the Software Estimation Methodologies available.
I am doing it for quite some time now but without any scientific or any formal methodology.
What I use currently in my project is my past experience from the same project or discuss it with my manager and other people, which isn't scientific.
I think its time for me to learn more about it. Briefly I want to know how do you come to the estimates, timewise, effortwise and resourcewise.

Suppose I get a Change Request from the Client, how do I go about estimation of it so that I can commit something to the client and Deliver it on time.

Thanks

Ajit Wadekar

[ May 27, 2004: Message edited by: Ajit Wadekar ]
[ May 27, 2004: Message edited by: Ajit Wadekar ]
 
Manish Hatwalne
Ranch Hand
Posts: 2591
Android Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you read The Mythical Man-Month and Peopleware : Productive Projects and Teams ? Don't miss them. The first one is an all time classic.

- Manish
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While this is an interesting topic, it's more appropriate for the process forum, so I'm moving it there.

--Mark
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ajit Wadekar:
What I use currently in my project is my past experience from the same project or discuss it with my manager and other people, which isn't scientific.

This, by the way, is what I do as well -- and it works very well, most of the time at least. The other school of thought would be something like function point analysis (which is still based on your analysis of the change request, by the way).

I can't help mentioning that "Yesterday's Weather" is what Extreme Programming uses for estimation. That's pretty close to what you and I seem to be doing.
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is the method I recommend in my upcoming book. I have found it works extremely well....

1. Come up with your own estimates (possibly after talking to others). These may or may not be the same as the official estimates you give your boss.
2. Do you work and half way through each task re-estimate total time you expect it to take.
3. At the end of each task, record the actual time it took.

You'll begin to notice trends. Most junior developers for example, tend to be off by a factor of 2-3. Once you see the pattern, you can compensate for it.

Note that you need to continually do this, because once you start compensating, you still need to insure that you're on target, and not over- or under- compensating.

--Mark
 
Adnaan Sikandar
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We use QSM SLIM-Estimate tool. Its works well for the planning stage. Basically, you enter parameters such as use case count, complexity, productivity index etc and SLIM generates the number of total man hours required for the project as well as the resource count and break down of hours by RUP phases.

For change requests, you can probably rerun the SLIM and compare the deltas.

SLIM Estimate
[ June 06, 2004: Message edited by: adnaan sikandar ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We do several levels of estimates. Our director talks to officer-level people and says "That sounds about as big as the last thing we did, that took about 6 months, so let's say from 5 to 8". Everybody knows he's talking without his techies along, so it's a guess. Maybe it's good enough to decide to do one project and not another, but not something to bet the farm on.

When customers get more interested, we take a next level estimate based on major functionality. We work with the customer to turn this into a use case catalog, maybe 0.5 or 1 day's effort together. We call each use case Small Medium, Large or ExtraLarge, run them through a spreadsheet that does some magic with manpower, duration, fixed costs, management overhead and puts out a +- 50% SWAG. This is considered reliable enough to get funding, but not to promise a complete date.

Then it gets real fun. We take a day or two with real users and their supervisors and make story cards, up to a few hundred. We push four or five long tables together, lay the cards all out in priority order, have a few key developers come through and give estimates in abstract story points. They don't even try to relate story points to days duration, they only compare one story to another. An 8 is twice as much work as a 4. But we do have the advantage of a stable team and we know how many points we do per week as a whole group. So we can see if the total points seem realistic with the manpower and time estimated before and adjust the date. First time with a new team you'd have no "yesterday's weather" and it would be hard to know if the date is good or not. This is probably right out of any XP book.

Then every two or three weeks we pull out some cards, estimate them again based on the prior weeks experience and start an iteration. Based on story points completed per iteration and points remaining we get a pretty good feel early on whether the end date is reasonable or not. Our customers love the story cards and understand the story point velocity and are very good about helping to renegotiate scope or dates if the earlier estimates turn out to be wrong.

Unfortunately for you, all this is based on prior experience. Most of the team has been together since 1996, working in the same business domain so we mostly know what to expect. Doing this from scratch with new folks would be scary! But the part you can use is to do the best estimate you can by whatever technique, then review and refine it often. XP and the agile methods give you very visible progress (or not) and help you steer your future direction together with your customer.

Wow, sorry that was so long. Hope something there was useful!
 
Pieter Schmidt
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ajit Wadekar:
Hi

I don't know where to put this so I am putting my post here. I want to know more about the Software Estimation Methodologies available.
I am doing it for quite some time now but without any scientific or any formal methodology.
What I use currently in my project is my past experience from the same project or discuss it with my manager and other people, which isn't scientific.
I think its time for me to learn more about it. Briefly I want to know how do you come to the estimates, timewise, effortwise and resourcewise.

Suppose I get a Change Request from the Client, how do I go about estimation of it so that I can commit something to the client and Deliver it on time.

Thanks

Ajit Wadekar

[ May 27, 2004: Message edited by: Ajit Wadekar ]

[ May 27, 2004: Message edited by: Ajit Wadekar ]



Hi,

Check out this website, it has some good articles on estimation and a fully functional estimation tool for download based upon use case point estimation technique
http://liemur.co.uk/Articles/UseCasePointEstimation.html
Another article on Wideband Delphi technique is here:
http://liemur.co.uk/Articles/Wideband_Delphi.html

I have used the estimation tool on a project and found it very useful and easy to use.
 
Scott Ambler
author
Ranch Hand
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agile Estimating Tips might help.

- Scott
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
Unfortunately for you, all this is based on prior experience.


And I don't think it can work differently, because too much simply depends on things you can't reliably specify upfront, for example how well the developers will work together.


Wow, sorry that was so long. Hope something there was useful!


A great post, actually! Should be referenced somewhere in the FAQ, I guess...
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Software by Numbers was not bad either:
http://www.coderanch.com/t/93634/Book-Reviews/Software-Numbers-Mark-Denne-Jane
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic