[
Lists Home |
Date Index |
Thread Index
]
BTW, there is a missing piece of what I've been describing:
user satisfaction. This one is hard to quantify and predict,
so it seldom if ever is mentioned in contracting for systems
procurement: how well can the end user do the job the software
is designed to help them do? How could we engineer a just
in time code registry source to ensure the system delivered
to the end user is at maximum effectiveness for doing the
job? That is a rather tough nut to crack, I think.
If we laugh or scoff at that one, we tend to go out of business.
But can we qualify it or warrant it?
What I know of software design and the relationship to the customer
is that feedback and customer participation in specifying assemblies
is vital. This yet another problem of the relationship of core
providers and middle system providers: to get changes into the
software to improve features or provide higher satisfaction for
the end users, features are planned and scheduled. That enables
the customer to predict when a feature will be available. Open
source models, by reputation, aren't as reliable when it comes
to predicting a release. The Mozilla project is famous for
that problem. On the other hand, closed sources such as proprietary
vendors also slip releases and may not have the kinds of communications
with the middle tier vendors and end users that enable them to
gather up the needed information. So there are gaps in the
scheduling and the communications.
Projects such as X3D were spawned out of a community in which
the authors and the system implementors have enjoyed fairly good
fraternal relationships (say, willing to go onto a big list
and duke it out loud and long). That is one model. I realize
such forums exist for most languages and for the closed source
vendors. How to relate that to scheduling is a mystery to me.
len
|
