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.
function point analysis
I bought my first copy of Agile Software Development with Scrum, by Schwarber and Beedle back around 2002, I think. I was just thumbing through it last night when I saw that they use Function Points as a metric to demonstrate the velocity that agile software teams achieve, and more specifically use it to show that some teams develop software much faster using Scrum.
I didn’t know about Function Point Analysis back in 2002 — I didn’t become a Certified Function Point Specialist until about two years later — so I probably just skimmed over that line then, but when I saw it last night I thought it was cool that they used function points as a metric for software team development speed.
Summary: This short article describes a way to know when a software requirements specification is complete by using Function Point Analysis techniques.
I've written dozens — maybe hundreds — of software requirement specifications over the years, and at one point in my career I learned an important little secret about knowing when the process of gathering requirements for a software requirements specification was really complete. Here's my secret.
Update: Sorry, the Function Point Analysis application that was described in this article is no longer available. I may bring it back to life at some point in the future, but for now it’s offline.
I couldn't sleep last night so I started reading Edward Tufte's "The Visual Display of Quantitative Information", and I started thinking about software project metrics that might be useful to the team members on a software development project (including developers, business analysts, domain experts, and stakeholders), and how I would show these metrics in simple but data-filled Tufte charts and graphs.
Someone asked the other day if I've written any longer tutorials on software cost estimating and/or Function Point Analysis. Sometimes I forget that this site has grown pretty large, and things like this may not be easy to find with the current design.
To help solve that problem in the short term, here are links to two software cost estimating and Function Point Analysis (FPA) tutorials I've written:
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:
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 converted my Function Point Analysis (FPA) and software cost estimating slide presentations, and they now play much nicer with IE. They aren't perfect yet, but they are much better.
For the record those presentations are at these URLs: