Update on Specifying Goals

I updated the Planet Project article on Specifying goals, using some of Tom Gilb's approaches and recent experience with the topic from one of my projects.

In this project, we struggled somewhat to explain to our subject-matter experts the importance of beginning with the (ultimate) end in mind. They thought they had to describe every little step, every button and every view of an IT application down to the smallest detail.

My favorite example was the following sequence (from a use case description), repeated a hundred times within the requirement specification:

1. User does some inputs
   
2. User "sends" the input, i. e. confirms his inputs
3. System checks inputs against rules X and Y
4. Systems shows an error message in case the checks fail.
5. ...

I finally got them with suggesting an alternative solution, roughly like this:

1. User does some inputs
2. (System has to make sure rules X and Y are not broken)

I guess the key was to make up a scenario which used quite a lot of sarcasm:

1. "I think I am an expert user."
2. "I do these simple inputs. Damn I'm good!"
3. "Now send the stuff to the stupid machine." *klick*
4. "Ooops ... What the ...."
5. "The stupid machine says I did it wrong?!"
6. "Why didn't it prevent me from doing it wrong, is there anything this machine is useful for?"

:-D

Do you care about your customer, every day?

There's a wonderful parable on real customer satisfaction on the "i must be an acrobat" weblog by Joshua Hoover.

He compares eating out in a restaurant with inattentive waiters to developing software without delivering real results to a customer.

7 Habits of Highly Effective Risk Managers

I'm proud to announce that Raven, author of the wonderful Raven's Brain weblog published another guest post of mine.
It is on effective risk management, titled "7 Habits of Highly Effective Risk Managers".

As you can expect from my material it is a set of rules, that risk managers can easily apply to their jobs. It might also help if you are NOT the risk manager in your endeavor, but want to help someone who is.

Here's the condensed version:

R1: Be responsible.
R2: Analyse in depth.
R3: Use hard facts.
R4: Do more than one thing.
R5: It's not fire and forget.
R6: Integrate.
R7: Don't change the scales of measurement.

In the blogpost itself I explain every rule/habit in detail. Thanks Dick Karpinski for nitpicking and thanks Mr. Covey for the title.
Enjoy!

Estimating with Use Case Points - FREE template

Being lazy, I was looking for a free, read-made, comprehensive and easy-to-use spreadsheet template for estimating project effort with use case points. I needed it for one of my current projects, in which we are writing 200+ use cases (sic!, see my remark below), and prepare a project proposal for senior management. 

I came across Scott Selhorst's material on Use Case Point Estimation. Very useful!

Check out:

• An introduction to use case point estimation with good context for use case newbies
  
• A How-to for the final calculations
  
• The free template
  

The template can also be googled and found at modernAnalyst, another useful source of information for business analysts and such folk.

Note on the large number of use cases: I personally think they are no real use cases. It's quite close to a functional decomposition done in use case form. I expect the system to arrive at about 8000 Function Points, but estimates range from 1.000 to 15.000 as of now :-)

 

Software Development Practice in the 21st (22nd?) Century

A couple of months ago I published an article about 10 Critical Requirements Principles for 0-Defects-Systems (on Ravens Brain). Anecdotal evidence on how I once achieved zero defects in one of my projects.

If you like the thought of reliable software (sic!) you might as well like Charles Fishman's article on the On-Board Shuttle Group, the producer of the space shuttle's software. Yes, they have a lot of money to spend, but many lives and expensive equipment are at stake.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. -- Charles Fishman on the software product the Group puts out

BTW, they seem to use three key pracices: very detailed requirements, inspections and continuous improvement.

The way the process works, it not only finds errors in the software. The process finds errors in the process. -- Charles Fishman on the On-Board Shuttle Group's process

Happy New Year! (Note that 2009 is a year of the 21st century. Can't we do any better?)

PS: I'm going to go on vacation from Dec 28 to Jan 20. More interesting topics still to come, please be patient.