[Sigia-l] Useful tools

[Derek R]

Dr. Marios Pittas wrote:

>| I have seen only one attempt of developers to document
>| system requirements using UML. Then, all involved in the 
>| project politely left the many many pages of UML notation
>| to the side and turned to the "english" like requirements section


The best prototype is the image you can create in your mind, often
through language, which includes the flexibility to make or erase any
part, or the whole, via the imagination (i.e. the flexibility of
interpretation; Ziya's 'realization' in 'whatever language/paradigm they
feel comfortable in'). 

The whole point of the prototype, I believe, is to create a 'spiritual
guide' to lead you *through* accomplishment, (i.e. your future lies
*beyond* the yellow brick road), so that it is a path to be followed,
but NOT a brick-by-brick or step-by-step imprint so distinguished that
the path, effectively, becomes a prison.

Too often, *gung-ho documentation* restricts and cuts-off any path to
synchronicity -- a circumcision from which there may be no restoration.
This is often the result, I find, of over-zealous contributors or
methodologies which must have their own imprint over everything (i.e.
strict UML or heavy-egos).

Therefore, constant iteration is most successful because it continually
re-addresses the group, as a whole, to solidify changes and confirm
direction, yet continues to be 'loose' because of this cyclic process.

In the absence of such feedback, you may find zealous over-management
resulting in contributors 'staging their own show,' like they are a part
of a different company altogether (elitism), seemingly lost in a world
of fantasy instead of working with the team and the actual participants
involved.

I find this behavior contagious with prototypes, ditto for actual
design. So, to me, it is of paramount importance to remember, (despite
the need to clearly 'set direction' and push projects forward), just
*who* we deal with and create prototypes for (i.e. human beings), and
what our purposes are, so we do not treat participants as commodities
and expect them to behave as 'commodity' would behave (i.e. like a UML
'parser').

For instance, as Ziya notes:

>| As a developer I wouldn't want my objects and schemas 
>| defined by an IA. As an IA I don't want to spend an 
>| inordinate amount of time and energy to do
>| something that's best left in the domain of developers

This is a simple matter of respect, not only for craft, but for
individuals as human-beings -- and it will result in more accurate goal
forecasts and design timelines.

One of the negative aspects for the image of IAs, I think, is the idea
that they will come into a project and 'take over' everything. To a
certain extent this is true, but I feel there is only probably a small
pocket of IAs in existence who operate like they need to 'own'
everything, and this is a sensibility which is dying out. In actual
fact, most IAs are genuine and understand the value of working within
and around different groups and disciplines.

No doubt IA and prototyping is a bridge-building exercise. We must
remember these human-processes, which are at the heart of what we do.

As I have stated before: You do *not* live on the bridge; you walk over
the bridge.

In other words, a bridge is just bridge, and not more important than the
actual destination.

HTH