The last few weeks I've been looking at ways of estimating software dev projects using "Use Cases". I'm all over use cases -- I think they represent a good way to document the flow of an app, but a significant problem with them is that your use case is not the same as my use case, even for the same subset of an application. This leads into many problems estimating how much it's going to cost to develop a software app.

If that's the case, and estimating a software dev project depends on the way the use cases are written and organized, what way is right? More detail, less detail? I'm also a little freaked when you're told that use cases should include nothing about the UI and underlying architecture, but then you read some docs from a trainer from Rational and one of the use cases says "blah blah blah ... login screen, enter username and password ... the system gets the user record from the database ...". Am I missing something here? This has a significant impact on the perceived complexity of a system.

Still having a little fun with software dev estimating ... here are a few interesting URLs:

• Int'l Function Point Users Group
• A link on managing, planning, and estimating (including 10 project warning signs)
• A Function Point FAQ

Continuing on the subject, here's a link to release 0.1 of a spreadsheet I've created based on Gustav Karner's work with estimating software development projects using use cases and actors. I learned of this technique from the text "Applying Use Cases, A Practical Guide". When I could not find a version of this spreadsheet on the web, I created my own. This version assumes that you know what you're doing ... so buyer beware. If I continue w/ future versions I may try to do some things to save you from yourself, but right now this is it.