Every time I read an article or book about UML “Use Cases” I cringe a little bit. Every author says something like “Jacobson left the definition of a Use Case too open,” and then they try to work through some elaborate scheme of what a Use Case means to them. IMHO, the best use case definition was created in the early 1980s, long before Jacobson mentioned the term.
Summary: I use Function Point Analysis (FPA) and Yesterday’s Weather to make “back of the envelope” software cost estimates when discussing potential new software projects with decision makers.
Many times when a software project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, etc.) want the best estimate they can get regarding the time and cost of a software development project. This is often very early in the project lifecycle, typically shortly after someone said, “Hmm, that sounds like a very interesting idea” and well before the first check is cut. In short, they want the best back of the envelope, ballpark cost estimate you can give them.
I used to dread these discussions, because I hated estimating the time and cost of software projects. I wasn’t any good at it, and the developers I worked with weren’t any good at it either. But once I learned two things:
One of the great things about Function Point Analysis (FPA) is that it can be a terrific validator of the work you’re doing as a business analyst. For example, here’s one of the guidelines I came up with after I learned about FPA:
If you can’t count the Function Points when you’re about to start developing a software project, you’re about to enter a world of hurt.
They know the rules, and can also offer advice
Like a good accountant, a good CFPS not only knows the bean-counting rules, they also know a lot of general rules, and a couple of "magic formulas", and they're willing to share that information with you.
As I've written several articles lately about Function Point Analysis (FPA), it occurred to me that, just as any other service, there's a big difference between being a Certified Function Point Specialist (CFPS), and a really valuable CFPS.
So, if you're interested in hiring a CFPS, or renting a CFPS consultant, I'd like to share a few thoughts here about what I think makes a good CFPS.
A good Function Point specialist
I don't sell my services as a CFPS any more, but when you're looking for a good CFPS, I think a good CFPS is like a good accountant:
Using FPA, I quickly worked through several of our largest projects to determine our productivity rates, and also noted who worked on the projects, what technologies were used, along with a few other details. In short, in a few days I was able to create a database of our historical software development speed.
Just cleaning up around here lately, it looks like I never really linked up to some of the cost estimating and Function Point Analysis (FPA) tutorials and slide shows I've created. So without any fruther ado, here are some links to my free FPA tutorials and presentations:
I've had some Function Point Analysis documents available here before, and recently finished converting those presentations into a better form for the internet. To that end I've gathered all these in a new Function Point Analysis Education Center, which contains those free documents and presentations.
These educational documents cover FPA, cost estimating, and even cost estimating for Agile software development projects.
Yikes, I fixed a lot of the formatting of my "Introduction to Function Point Analysis" tutorial. I didn't realize how terrible the formatting was before. I still need to style it up a bit more and create a print style sheet, but at least you can read it now. Ugh, that was bad.
This page is sponsored by Sleetmute.com: Free Function Point Analysis Software
Over the weekend I saw that I'm on Borland's speaking schedule for their annual conference, BorCon 2004. I guess I better get to work on my presentations. :) Actually, I'm ready to go. I'm set to give one talk on Java Performance Tuning and another on Function Point technology. Giddyup.
I haven't frequented it before, but the Java & Internet Glossary at mindprod looks pretty good.