"Rob Halgren" wrote in message
...
Susan Erickson wrote:
[snip]
Actually since we have had this debate at least once before, maybe
you and I should try to come up with a discussion paper for printing in
the AOS Bulletin (Orchids, whatever.... still can't get used to that).
We could at least address what we see as the big issues, and recommend
some sweeping guidelines. I'm done with my judging homework, so I need
things to do... *grin*

Part of the problem with most software that has been developed, in my
experience as a software developer appraising software products, is that
usually the developer and his management never get a chance to talk directly
to the people who use the software. More usually, the supervisor of the
folk who use it make a wish list to present to the marketting manager for
the software developer who then uses it to construct the terms of the
contract to develop the software. For COTS, it is even worse. The software
house either hires a marketting firm or asks its sales staff to find out
what features a given product ought to have (and usually these folk are
completely clueless with regard to what it akes to provide each feature),
and then, once the wish list has been constructed, passes it to the
developer who then has to figure out what is really meant by each item on
the list and how it can be provided. There is therefore usually a huge
discrepancy between what the software provides and what best meets the needs
of the user. I am OK with this since it means that there is usually a
significant market for what I produce since I design and implement my
products only after I get to know the user and understand how he or she
works. Before top quality software can be produced, the developer must know
well the processes the user currently uses to get the job done, as well as
how the user would prefer to get the job done.

What most "managers" don't realize is that wish lists are NOT the same thing
as functional requirements. For the kind of software you're discussing, it
isn't enough to tell, e.g. me, what the complete set of data items is. To
be effective, you'd have to describe to me IN DETAIL what forms are
required, how they are to be filled out, how the data is to be stored and
displayed and manipulated, what the data entry clerks need/want to do, how
the judges would use the data, &c. &c. &c. There could well be more than a
month's worth of full time work just discussing and analyzing these details
before any code has been written at all, and then several prototypes for the
various kinds of users to play with, and provide feedback, before you can
develop a version suitable for beta testing. And I am guessing that this
would be a relatively simple project. As you can imagine, this process is
expensive, which is why only a few actually do it.

As far as this discussion is concerned, I have not seen an issue raised that
can't in principle be adequately addressed by suitably designed software.
For each, there are several techniques that occured to me that could prove
effective. But a specific suggestion can't be made without significantly
more discussion than is practicable in this forum.

Cheers,

Ted