[hyades-dev] HCE Project & related Requirements

[Michael.Norman@xxxxxxxxxxxxx]

Team,

There are a few process issues around this, and these have been 
difficult to resolve in the transition phase between old and new project 
structures.  Given the quality and experience of the people involved in 
the project, to a certain degree it is self-organizing and 
self-correcting, but I think this may require a review.  In particular 
the HCE has come bottom-up, whereas the top-down requirements stuff 
hasn't really been articulated. Also the current RAC is perhaps 
under-documented, and we have just fragmented the project so that the 
RAC/HCE team sits in the core whereas the agent-writers and most of the 
use cases for the agents sit in the indiviudual projects.

The HCE discussions should continue, but I'd like to frame the review 
one level up. We now have a way of capturing and articulating 
requirements through the Requirements Group, which we intend to meet 
twice a quarter, and I think now would be a good time to put out a 
request for contributions in the broad area of what this piece of Hyades 
has to do.

"The high-level requirements that consumers (both open-source and 
proprietary) of trace, statistical and log data put on the data 
collection agents and any communication infrastructure that is used to 
access them."

I'd like contributions to be framed at this level and kept short (max 3 
pages) and posted to to hyades-dev not necessarily by the requirements 
group company representatives.  Contributions from emerging project 
member companies are particularly welcome.  If PR issues don't allow you 
to stick yourr company's head above the parapet just now, fire them to 
me and I'll contribute them anonymously.

Mike Norman
TPTP Requirements Group Chair

-----Original Message-----
From: apratt [mailto:apratt@xxxxxxxxxx]
Sent: 02 September 2004 02:18
To: hyades-dev
Subject: RE: [hyades-dev] The state of the HCE project


I think Harm echoes my sentiments about not knowing what we're really 
about here when he says, "changes [should be] based on well identified 
requirements." I don't think we have established what those are.

Vishnu wrote, "Though it is looking like house of cards..., at some 
point 
I feel that all these [documents] will merge and make sense." That's not 

how it's supposed to happen. The design and architecture shouldn't 
emerge 
from the implementation; it should be the other way around. The only 
time 
the ad-hoc approach works is when the people writing the command 
protocols 
already have a pretty good idea of the requirements and overall 
architecture in their heads, and it's the SAME idea, and they just 
haven't 
bothered to write it down. I think it's clear that the people 
contributing 
to these HCE document reviews do NOT all have the same design ideas in 
mind.

Harm also reminds us that we can't be in the business of wholesale 
replacement of the Workbench - RAC - agent protocols and structures. As 
far as I can tell, that's EXACTLY the business we're in. Is there some 
kind of coexistence strategy? Are all the new commands and protocols 
being 
piggybacked on the current RAC as "custom commands" or something? If so, 

why? Is the RAC protocol really so awful that we can't accomplish what 
we 
want by extending it?

Maybe it's time to step back and rethink this. We can start by answering 

this question: "What problems with the current Workbench/RAC/Agent 
system 
are we trying to solve?" Then we can ask, "If possible, how can we solve 

those problems in the context of the current system and not a new, 
parallel system?"

-- Allan Pratt, apratt@xxxxxxxxxx
Rational software division of IBM

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev