jQuery in Action, 3rd edition
The moose likes OO, Patterns, UML and Refactoring and the fly likes use case  based  Project estimation ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of OCA Java SE 8 Programmer I Study Guide this week in the OCAJP 8 forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "use case  based  Project estimation ?" Watch "use case  based  Project estimation ?" New topic

use case based Project estimation ?

kri shan
Ranch Hand

Joined: Apr 08, 2004
Posts: 1400
How can i calculate number of days based on use case for Project estimation ?
Allan Christensen

Joined: Oct 21, 2003
Posts: 24
It would depend on your project team. Try to compare it with similar work done previously.

You could also use formal techniques such as COCOMO2.

Kind regards,
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Basically gut feel, educated by prior experience. Best thing often is to have (at least part of) the team that will implement it contribute to the estimate.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Scott Ambler
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
I have some advice posted at Agile Project Planning tips.

- Scott

<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
It's useful to estimate use cases or any sized tasks relative to each other. You don't need any idea how long they'll really take to do this, but you need to feel fairly sure that a 4 is twice as big as a 2, or these five tasks are all the same.

Then you can take a guess at how long some of them will take. You might decide an "4" takes one person a week.

You'll probably be asked to estimate the scope and staff and time for the entire project at this point. Such estimates are always rough unless you have solid experience with the architecture, the team, the customer, the domain and every other variable in the world. Which isn't often, is it.

Then pick some tasks to work on. I like Scott's link a lot where he shows planning the near range tasks in detail, and just blocking out big bunches of them in the future.

As you run a few tasks, validate that "4 equals a week" idea. If it turns out you can do 6 in a week, you're in great shape! If it turns out you can only do 2 in a week, you just learned this in a matter of days and you can adjust the plan accordingly.

BTW: I like one definition of risk as "uncertainty in the plan". If you don't know your variables or even one or two use cases well enough to estimate, that's a risk! Make sure everyone is aware of the uncertainty and has some idea what THEY will do if things are not as predicted. Otherwise we know exactly what YOU will do: 80 hour weeks!

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I agree. Here's the link: http://aspose.com/file-tools
subject: use case based Project estimation ?
It's not a secret anymore!